Real–Time Teaching with Java: J P R
3 ?
Diego Alonso and Juan A. Pastor and B´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 M¨arklin[3]. Specifically, it is based on the M¨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
M¨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 M¨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 M¨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 M¨arklin 6021
Control Unit, the core of the M¨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 M¨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 M¨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 M¨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