scispace - formally typeset

Book ChapterDOI

Real–Time Teaching with Java: JPR3

25 Oct 2004-Lecture Notes in Computer Science (Springer)-pp 246-255

TL;DR: A development platform built around a digital railroad scale–model: JPR 3 (Java Platform for Realtime Railway Research), which serves as a research platform for postgraduate students, thanks to the possibilities offered by the scale– model.

AbstractThis paper describes a development platform built around a digital railroad scale–model: JPR 3 (Java Platform for Realtime Railway Research) The laboratory equipment and software aims to achieve two goals: help and motivate students of real–time systems and as support for postgraduate students Students find the scale–model really challenging and are very motivated by it; thus it’s easy for them to really learn and practice all the concepts of real–time systems But it’s not only for students use: it also serves as a research platform for postgraduate students, thanks to the possibilities offered by the scale–model Java has been chosen as the programming language codify the platform and the implementation of the system is described in this work

Topics: Real time Java (59%), Java (55%)

Summary (2 min read)

1 Introduction

  • Many do not provide adequate laboratory platforms to exercise the software skills necessary to build physical real–time systems.
  • Plus the fact that students can see it work in a real– time operating system, the result is a complete “real–time experience” for them.
  • But in the process of real–time learning, the railway scale–model is also of great help, not only because its a real, physical system, but also because it motivates the students, who find it very challenging.

2 The Platform at the Laboratory

  • This section presents a brief description of the equipment present at the laboratory, focusing on the railroad scale–model and the software control platform.
  • The railroad scale–model has been developed around a commercial system designed and built by Märklin[3].
  • Figure 1 shows a panoramic view of the railroad platform once finished.

2.1 The Digital Model Railroad

  • Märklin commercialises beautiful all–time locomotives and all kind of accessories to simulate a real railway network.
  • So the transmission speed is set to a very low value and every command is sent several times to ensure its correctly received.
  • The scale–model can be manually operated by means of the Märklin 6021 Control Unit, the core of the Märklin Digital System.
  • The architecture should be distributed, so different clients (such as an automatic control module or a web client) could make use and monitor the mock–up.

3 Real–Time Characterisation of the Scale–Model

  • The greatest time constraint imposed by the scale–model is due to the communication system.
  • As said before, the Märklin Digital System provides a great advantage (there are practically no wires) but at a great cost (the communication is noisy, commands are sent several times and it works at a very low speed).
  • Commands such as stop and start have a greater priority over the rest.
  • The other important time constraint is imposed by a simple fact: locomotives do not have to crush!.
  • The authors say may be to mean that they only know that some locomotive has stepped through one reed contact in a given direction, thus it is only known that the locomotive is somewhere over the track.

4 Java Implementation Issues

  • Once the architecture of the application was finally defined and the server–side finished, it was time to test it.
  • At that time, the authors chose the solution proposed by Timesys[6]: a modification of the Linux Kernel and an implementation of the Virtual Machine over it.
  • When the initial creation and configuration step is over, every component shown in Fig. 3 runs in it’s own thread (whether real or non real–time one).
  • This was necessary to ensure that high–priority commands are executed nearly when they are send to the component.
  • Besides the circular buffer, the server also follows an observer pattern [8] to notify every client of the state of mock–up.

5 A Practical Exercise

  • The laboratory has been used in courses such as Concurrent Programming and Real-Time Systems.
  • An example of practical exercise is carried out by the students starting from the following requirements specification.
  • This train must be stopped when standing on s11 reed contact if the train B has not stood on s1 reed contact.
  • Each train must be implemented as RealtimeThreads.
  • The exercise allows to practice the different topics reviewed during the course as concurrent programming, scheduling schemes, fault tolerance, etc . . . 2.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

Real–Time Teaching with Java: J P R
3 ?
Diego Alonso and Juan A. Pastor and arbara
´
Alvarez
diego.alonso@upct.es
Universidad Polit´ecnica de Cartagena (Spain)
Abstract. This paper describes a development platform built around a
digital railroad scale–model: J P R
3
(Java Platform for Realtime Railway
Research). The laboratory equipment and software aims to achieve two
goals: help and motivate students of real–time systems and as support for
postgraduate students. Students find the scale–model really challenging
and are very motivated by it; thus it’s easy for them to really learn
and practice all the concepts of real–time systems. But it’s not only
for students use: it also serves as a research platform for postgraduate
students, thanks to the possibilities offered by the scale–model. Java has
been chosen as the programming language codify the platform and the
implementation of the system is described in this work.
1 Introduction
Although many undergraduate courses in computer engineering acquaint stu-
dents with the fundamental topics in real–time computing, many do not pro-
vide adequate laboratory platforms to exercise the software skills necessary to
build physical real–time systems. The undergraduate real–time systems course
at Technical University of Cartagena is practical and carries out in a laboratory
with a Digital Model Railroad Platform, where students can apply the real–time
concepts explained at class [
1] and see them work in a real enviorment.
Thanks to the Real–Time Extension [2], Java now offers a wonderful API for
real–time systems’ teaching, because there is a clear relation between real–time
concepts and Java objects. Plus the fact that students can see it work in a real–
time operating system, the result is a complete “real–time experience” for them.
Also, Java has been chosen because students are already familiar to it, since
Java is studied during the first courses. This way, they can focus on applying
real–time techniques rather than in learning a new programming language.
But in the process of real–time learning, the railway scale–model is also of
great help, not only because its a real, physical system, but also because it
motivates the students, who find it very challenging. The total length of the
track plus the complexity added by the possibility of using the turnouts, results
?
This work was supported in part by the Spanish Ministry of Education (with ref-
erence ACF2000–0037–IN) and the Regional Government of Murcia (S´eneca Pro-
grammes with reference PB/8/FS/02)

2
in a complex circuit to control in which problems with several levels of difficulty
(and risk) can be simulated.
This paper is organised in five more sections. Section 2 gives a complete
description of the laboratory equipment, both hardware (Sect. 2.1) and software
(Sect. 2.2). In Sect. 3 the real–time problems related to the mock–up are outlined,
and the Java implementation of the server–side of J P R
3
is described in Sect. 4.
An example of a real practice is presented in Sect. 5. Finally, Sect. 6 summarised
the content of the paper and outlines future plans for JP R
3
.
2 The Platform at the Laboratory
This section presents a brief description of the equipment present at the labora-
tory, focusing on the railroad scale–model and the software control platform. The
railroad scale–model has been developed around a commercial system designed
and built by arklin[3]. Specifically, it is based on the arklin Digital System.
Figure 1 shows a panoramic view of the railroad platform once finished.
Fig. 1. Overview photograph of the scale–model
On the other side, the control architecture is run on a normal Intel Pentium
computer, placed next to the scale–model and connected to it by an RS–232
serial wire.

3
2.1 The Digital Model Railroad
arklin commercialises beautiful all–time locomotives and all kind of accessories
to simulate a real railway network. The railroad scale–model placed at the lab-
oratory is formed by the following elements and accessories:
? Five digital locomotives, capable of moving in both directions and with spe-
cial functions, such as play the bell, turn–on the lights, or even throw smoke.
? Sixteen digital turnout switches (where three tracks join) with manual and
automatic control.
? Six digital semaphores, which are only passive elements, i.e., the locomotive
doesn’t stop by itself if the semaphore is in red.
? Twenty one double reed contact sensors to manage and control the position
of the different locomotives in the mock–up.
? Around a hundred railway tracks, both straight and curved, that make up
our particular railway network.
The arklin Digital System uses the tracks as power and control lines for all
elements present in the scale–model, so the number of wires is minimum and new
elements can be easily added. Moreover, it uses the centre of the tracks as the
main conductor line, so the polarity of the signal is independent of the direction
of the movement of the locomotives. But this kind of communication, based on
friction, has a great drawback: it’s very noisy. So the transmission speed is set to
a very low value and every command is sent several times to ensure its correctly
received.
All the active elements of the scale–model (turnouts, semaphores and loco-
motives) have a unique identification number and carry a device to decode the
control commands that travel by the tracks. Because of the noise in the system,
each decoder needs to decode, at least, three times the same command for it
to proceed with it. This non-desired feature greatly increases the latency of the
system.
The reed contacts are placed before and after every turnout around the mock–
up, in order to monitor the traffic on the railroad. Each reed contact is really
composed by two switches, which are activated depending on the direction of
the locomotive that is stepping through it. To get the state of the reed contacts,
three arklin S88 Decoders are used. Each one provides a reading of the status
of up to eight reed contacts, resulting in a total of sixteen sensors.
The scale–model can be manually operated by means of the arklin 6021
Control Unit, the core of the arklin Digital System. This module is in charge
of both converting the control orders to electric signals, that are transmitted
through the rails, and of reading the state of the arklin S88 Decoders. Finally,
to be able to control the scale–model with a computer, a module that provides
a RS–232 serial interface with the Control Unit is used (see Fig. 2).

4
SERIAL
INTERFACE
TRANSF.
UNIT
CONTROL
SENSOR
DECODER
RS−232
VIDEO SIGNAL
SERVER
Fig. 2. Diagram of the configuration of the scale–model
2.2 The Software Platform: JP R
3
The software design of the J P R
3
was started following a four view design ap-
proach [
4][5]. The initial development of the platform was guided by three ob-
jectives:
1. The application has to run in a host system that doesn’t make use of the
Real–Time Java extension. The user has to be able to configure whether the
Real–Time API has to be used or not.
2. The architecture has to be modular and easily extendable, so new features
could be added (such as the use of some video camera or a simulator of the
mock–up).
3. The architecture should be distributed, so different clients (such as an au-
tomatic control module or a web client) could make use and monitor the
mock–up.
With all these objectives in mind, the application was developed following
the schema shown in Fig. 3. This paper presents only the, what is called, server–
side of the application, which is, after all, the only that really has real–time
constraints.
To control the elements of the mock–up, the arklin Serial Interface pro-
vides several commands to send to the Control Unit. Section 3 presents all the
issues related to the implementation of the communication with the scale–model,
which, as we will see, is not trivial. The available implemented control commands
are:
Stop the mock–up Start the mock–up
Change turnout track Read reed contacts
Manage semaphores Use locomotives functions
Change locomotive speed Change locomotive direction

5
Fig. 3. Architecture overview
3 Real–Time Characterisation of the Scale–Model
The greatest time constraint imposed by the scale–model is due to the commu-
nication system. As said before, the arklin Digital System provides a great
advantage (there are practically no wires) but at a great cost (the communica-
tion is noisy, commands are sent several times and it works at a very low speed).
Moreover, a small unknown delay has to be introduced between two consecutive
commands, because, otherwise, the last command could be lost in its way and
thus completely ignored by the Control Unit.
Although the available set of commands is reduced, as seen in last section,
it is obvious that not all commands have the same priority. Commands such as
stop and start have a greater priority over the rest. Indeed, the emergency-stop
or stop-all order has to executed at fast as possible, to avoid collision between
locomotives. Also the scale–model ignores all commands until the start one has
been received, making the sending of other commands useless.
The other important time constraint is imposed by a simple fact: locomotives
do not have to crush!. This desirable objective means in practice that there has
to be a free track between two locomotives. In this case, the word track groups
all tracks between two reed contacts. As said in Sect. 2, there’s a reed contact
sensor before and after every turnout element of the mock–up, and they are the
only available source of information to know where a locomotive may be. We say
may be to mean that we only know that some locomotive has stepped through
one reed contact in a given direction, thus it is only known that the locomotive
is somewhere over the track.
Having said that, the safety condition for the system is the following: the
frequency of the reading of the state of the reed contacts has to ensure that no
locomotive could have activated two different reed contacts between two consec-
utive readings. So, given the maximum locomotive speed and the shortest track

Citations
More filters

Journal ArticleDOI
TL;DR: One tool for detecting failures in applications is developed, which avoids code with dead-locks and race-conditions, into the Internet and the results show that many assignments may benefit from the output of the tool.
Abstract: Tools that allow detecting programming faults are useful for both docents, who may test submitted exercises, and students, who may use these tools in advance. In this article the authors develop one tool for detecting failures in applications. In many cases there are previous tools that may be readapted to be used in an educational scope. This article integrates of one of these tools, which avoids code with dead-locks and race-conditions, into the Internet. The tool integrated is JPF (Java Path Finder) and it is accessed from a Java EE web frontend which carries out the exercise assessment. The article deals with the definition of the module and its evaluation on a realistic scenario. The results show that many assignments may benefit from the output of the tool.

2 citations


Journal ArticleDOI
TL;DR: This article aims to address how to integrate a core validation tools for concurrent-C as a web application, allowing you to be accessible through the Internet.
Abstract: Tools for computer-aided teaching and learning provide multiple benefits from the point of view of teaching because it allows emphasizing or illustrating certain issues that are sometimes difficult to emphasize without such type of support. This is exactly the case for the tools to detect if there is any type of problem in a concurrent-C program. These tools provide interfaces that can complement the information given by a compiler with additional information about different types of race conditions and memory leaks that appear in the code. This article aims to address how to integrate a core validation tools for concurrent-C as a web application, allowing you to be accessible through the Internet. This tool has been evaluated in an existing programming course, which has shown to be able to provide additional information useful to the learner and the teacher. There have also been a number of performance measures to establish operational limits designed tool within a course that teaches concurrent-C programming.

References
More filters

Book
01 Jan 1994
TL;DR: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns, which most experienced OOP designers will find out they've known about patterns all along.
Abstract: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they've known about patterns all along. It's just that they've never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.

22,753 citations


"Real–Time Teaching with Java: JPR3" refers methods in this paper

  • ...Besides the circular buffer, the server also follows an observer pattern [ 8 ] to notify every client of the state of mock–up....

    [...]


Book
05 Apr 2009
TL;DR: Applied Software Architecture gives an overview of software architecture basics and a detailed guide to architecture design tasks, focusing on four fundamental views of architecture--conceptual, module, execution, and code.
Abstract: "Designing a large software system is an extremely complicated undertaking that requires juggling differing perspectives and differing goals, and evaluating differing options. Applied Software Architecture is the best book yet that gives guidance as to how to sort out and organize the conflicting pressures and produce a successful design." -- Len Bass, author of Software Architecture in Practice. Quality software architecture design has always been important, but in today's fast-paced, rapidly changing, and complex development environment, it is essential. A solid, well-thought-out design helps to manage complexity, to resolve trade-offs among conflicting requirements, and, in general, to bring quality software to market in a more timely fashion. Applied Software Architecture provides practical guidelines and techniques for producing quality software designs. It gives an overview of software architecture basics and a detailed guide to architecture design tasks, focusing on four fundamental views of architecture--conceptual, module, execution, and code. Through four real-life case studies, this book reveals the insights and best practices of the most skilled software architects in designing software architecture. These case studies, written with the masters who created them, demonstrate how the book's concepts and techniques are embodied in state-of-the-art architecture design. You will learn how to: * create designs flexible enough to incorporate tomorrow's technology; * use architecture as the basis for meeting performance, modifiability, reliability, and safety requirements; * determine priorities among conflicting requirements and arrive at a successful solution; and * use software architecture to help integrate system components. Anyone involved in software architecture will find this book a valuable compendium of best practices and an insightful look at the critical role of architecture in software development.

654 citations


"Real–Time Teaching with Java: JPR3" refers methods in this paper

  • ...The software design of the JPR(3) was started following a four view design approach [4][5]....

    [...]


Book
30 Mar 2009
TL;DR: An introduction to Real-Time System Design and real-Time system programming in the Smal Programmin and the Larg Reliability and Fault Toleranc Exceptions and Exception Handlin Concurrent Programmin.
Abstract: Introduction to Real-Time System Designing Real-Time System Programming in the Smal Programmin gin the Larg Reliability and Fault Toleranc Exceptions and Exception Handlin Concurrent Programmin Shared Variable-Based Synchronization and Communication Message-Based Synchronization and Communicatio Atomic Actions, Concurrent Processes and Reliabilit Resource Contro Real-Time Facilitie Schedulin Distributed System Low-Level Programmin The Execution Environmen A Case Study in Ada

629 citations


Book
01 Jan 2002
TL;DR: This chapter discusses the architecture of the Java Virtual Machine, the Real-Time Java Platform, and the implementation of the RTSJ, which aims to provide an easy-to-understand guide to real-time Java programming.
Abstract: Preface. Introduction. 1. Landscape. Java Technology and Real Time. Real-Time Programming Requirements. Java and Embedded Real Time. Definition of Real Time. Precision of Measurement. Consistency. Utility Function Curve. Java's Problem Domain. Real-Time Java's Problem Domain. Summary. 2. Architecture of the Java Virtual Machine. Write Once, Run Anywhere: Maybe. JVM Components. Class Loading. Bytecode Interpreter. Security Manager. Garbage Collector. Thread Management. Input/Output. Graphics. Interpreter Implementation. Standard Interpreter. Optimized Interpreter. JIT. Snippets. Compilation to Independent Process. Native Methods. Compilation to a Native Method. Compilation to the JIT Interface. 3. Hardware Architecture. Worst-Case Execution of One Instruction. Worst-Case Scenario. Practical Measures. Management of Troublesome Hardware. Managing Demand Paging. Managing DMA. Managing Cache. Managing Address Translation Cache. Managing Interrupts. Effects on the JVM. 4. Garbage Collection. Reference Counting. Basic Garbage Collection. Mark and Sweep. Defragmentation. Copying Collectors. Incremental Collection. Incremental Garbage Collection in Practice. Generational Garbage Collection. Intergenerational References. Large Object Store. Real-Time Issues. 5. Priority Scheduling. Scheduling Terms. Execution Sequences. Preemption. The Seductive Charm of Nonpreemptive Scheduling. Fixed versus Dynamic Priority. Priority Inversion. Why 32 Priorities? Problems with Priority Scheduling. 6. Scheduling with Deadlines. Underlying Mechanism. Scope of the Scheduler. Some Systems. Earliest Deadline First (EDF). Least Laxity. Periodic Scheduling. Aperiodic Servers. Handling Overload. Timing Is Usually Probabilistic. 7. Rate Monotonic Analysis. Theorems. Liu and Layland's Theorem. A Graphical Approach. Lehoczky, Sha, and Ding's Theorem. Restrictions. Independent Tasks. Deadlines Equal to Periods. Multiprocessor Systems. 8. Introduction to the Real-Time Java Platform. A Brief History of Real-Time Java. Major Features of the Specification. Threads and Scheduling. Garbage Collection. Asynchronous Event Handlers. Asynchronous Transfer of Control. Memory Allocation. Memory Access. Implementation. RTSJ Hello World. 9. Closures. The Language Construct. Java Closures. Closure Structure. Closures in the RTSJ. Limitations of Closures. Readability. Local Variables. Constructors. Nesting. 10. High-Resolution Time. Resolution. The "clock". HighResolutionTime Base Class. Absolute Time. Relative Time. Rational Time. 11. Async Events. Binding a Happening to an Event. Basic Async Event Operation. Async Events without Happenings. Time Triggering. Fault Triggering. Software Event Triggering. Implementation Discussion. 12. Real-Time Threads. Creation. Scheduling. Inversion Handling. Fixed Priority. Feasibility. Periodic Threads without Handlers. Feasibility Analysis. Periodic Threads with Handlers. Interactions with Normal Threads. Changing the Scheduler. 13. Non-Heap Memory. The Advantage of Non-Heap Memory. The Allocation Regimes. Rules. Mechanisms for Allocating Immortal Memory. Mechanisms for Allocating from Scoped Memory. Allocation Time. Creating Scoped Memory. Allocation Mechanisms. Finalizers. Using Nested Scoped Memory. The Scope Stack (Tree). The DAG. Practical Use of Nested Scopes. Every Nested Scope Involves Two Memory Areas. Pitfalls. Using executeInArea. Using Standard Classes. Using Shared Scoped Memory. The Scope Stack Revisited. Scope Portals. Fine Print. Quick Examples. 14. Non-Heap Access. Interaction with Scheduler. Rules. Samples. Final Remarks. Notes. 15. More Async Events. Async Events and the Scheduler. The createReleaseParameters Method. Bound Async Event Handlers. Async Event Handlers and Non-Heap Memory. No-Heap Event Handlers vs. No-Heap Threads. Scheduling. Minimum Interarrival Time. Async Event Handlers and Threads. Special Async Events. 16. Reusing Immortal Memory. Using Fixed-Object Allocators. Carrier Objects. Limitations. Recycling RT Threads. Recycling Async Event Handlers. 17. Asynchronous Transfer of Control. Thread Interrupt in Context. Asynchronous Interrupt Firing. The Timed Class. The interrupt Method. The fire Method. In Summary. Replacement Rules. Rules for Async Exception Propagation. Oblivious catch. Nonmatching doInterruptible. Matching doInterruptible. Internals. Application Handling for Asynchronous Interrupts. Noninterruptible Code. Special Issues for Synchronized blocks. Legacy Code. Use of ATC for Thread Termination. 18. Physical Memory. Physical and Virtual Memory. Physical Memory Manager. Memory Type. Removable Memory. Immortal Physical Memory. Scoped Physical Memory. 19. Raw Memory Access. Security. Peek and Poke. Get/Set Methods. Mapping. The RawMemoryFloatAccess Class. 20. Synchronization without Locking. Principles of Wait-Free Queues. Constructors. Common Methods. The Wait-Free Write Queue. Methods. Sharing the Wait-Free Queue. The Wait-Free Read Queue. The Extra Constructor. Methods. The Wait-Free Double-Ended Queue. Methods. No-Wait Queues and Memory. Implementation Notes. 21. Recommended Practice. Powerful and Easy-to-Use Features of the RTSJ. Real-Time Threads. Periodic Threads. Asynchronous Event Handlers. High-Resolution Time. Happenings. Very Powerful and Dangerous Features of the RTSJ. Simple. Leaky. Viral. Very Powerful and Finicky Features of the RTSJ. Scoped Memory. No-Heap Asynchronous Event Handlers. No-Heap Real-Time Threads. Asynchronously Interrupted Exceptions. Selection of Priorities. Index.

107 citations


"Real–Time Teaching with Java: JPR3" refers background in this paper

  • ...to be able to configure the kind of threads it would use (normal Java threads or RealtimeThreads [7])....

    [...]

  • ...The goal was 7 to be able to configure the kind of threads it would use (normal Java threads or RealtimeThreads [7])....

    [...]

  • ...Each train must be implemented as RealtimeThreads....

    [...]


01 Jan 1999
Abstract: Policy Abstract Policy

83 citations


Frequently Asked Questions (2)
Q1. What contributions have the authors mentioned in the paper "Real–time teaching with java: jpr" ?

This paper describes a development platform built around a digital railroad scale–model: JPR ( Java Platform for Realtime Railway Research ). The laboratory equipment and software aims to achieve two goals: help and motivate students of real–time systems and as support for postgraduate students. Java has been chosen as the programming language codify the platform and the implementation of the system is described in this work. 

The authors ’ ve already started up a number of activities to extend its functionalities. Emphasiseese, the authors wish to emphasize the following ones: design of a simulator of the mock–up ( so students could test their control strategies without using the real mock–up ), use of video cameras to carry out visual supervision and control of the locomotives ( cameras can also be placed inside the locomotives ) and, finally, make it a real distributed application by using a communication middleware, such as CORBA and/or RMI. Although the authors have chosen a particular implementation of the Virtual Machine, they also plan to test JPR3 with other implementations of the JVM and real–time operating systems.