Post on 08-Oct-2020
1
A TOOLSET IN JAVA2 FOR MODELLING, PROTOTYPING ANDIMPLEMENTING COMMUNICATING REAL-TIME STATE
MACHINES1
Giancarlo Fortino Libero Nigro
Laboratorio di Ingegneria del SoftwareDipartimento di Elettronica Informatica e SistemisticaUniversità della Calabria, I-87036 Rende (CS) – Italy
Email: {g.fortino,l.nigro}@unical.it
Abstract - This paper proposes an approach to the development of real-time systems which
depends on Communicating Real-Time State Machines (CRSM’s) as the specification
language, and on a customisable actor kernel for prototyping, analysis and implementation of
a modelled system. CRSM’s offer an intuitive and distributed specification of a system in
terms of a collection of co-operating state machines interacting to one another through timed
CSP-like I/O commands. On the other hand, the underlying actor framework provides a time-
sensitive scheduling structure which can be tuned to CSRM’s in order to support temporal
validation through assertions on the recorded time-stamped event histories. The approach
can be practically used through a graphical environment (jCRSM) which was achieved in
Java2. The toolset facilitates editing, testing and implementation in Java of CRSM systems.
Novel in the proposed methodology is a seamless system development life cycle where the
specification, analysis, design and implementation phases are glued together by a common
representation of machines in terms of actors. The paper exemplifies the use of CRSM’s by
means of examples.
Keywords: Timing constraints, finite state machines, actors, executable specifications,
temporal analysis through assertions, prototyping, graphical tools, Java.
1. INTRODUCTION
It is widely recognised that the design of real-time systems strongly demands for the adoption
of language notations and mechanisms which enable formal specification of and reasoning
about system behaviour (Ghezzi, et al., 1991) (Gerber and Lee, 1992) (Shaw, 1992) (Nielsen,
1Work carried out under the financial support of the Ministero dell'Università e della Ricerca Scientifica eTecnologica (MURST) in the framework of the Project "Methodologies and Tools of High PerformanceSystems for Distributed Applications".A preliminary version of this paper was presented at 24th IFAC/IFIP Workshop on Real Time Programming(WRTP’99), Proceedings pp. 87-92.
2
et al., 1998). Formal tools are required in order to capture the timing constraints existing on
the functional responses the system generate to react to external stimuli. The usefulness of a
formal notation is enhanced by the possibility of supporting validation activities which can help
guaranteeing the correctness of the timing behaviour. Besides, the specification language
should be clearly linked to subsequently design and implementation phases in order not to be
too abstract and far from the final system construction.
This paper proposes a methodology supported by a toolset which is based on Communicating
Real Time State Machines (Shaw, 1992) as the specification language and on a customisable
actor kernel (Kirk, et al., 1997) (Nigro and Pupo, 1998) which serves both for prototyping,
simulation and concrete implementation of a CRSM model. CRSM’s offer an intuitive and
distributed specification of a real time system in terms of a collection of co-operating state
machines interacting to one another through CSP-like I/O commands which are extended to
permit the expression of timing constraints. CRSM’s are transformed into actors which can be
orchestrated by a time dependent runtime support which can be specialised through
programming. An original contribution of the approach is a deployment of a system life cycle
which enables incremental development and rests on a common representation of a system
which is operated for prototyping and temporal analysis on the development host and for real
time execution on the target platform. Java is used as the implementation language for a
CRSM system.
Temporal properties are verified by means of checking assertions on the time stamped event
histories recorded during prototyping (Shaw, 1997). Assertions follows the Real Time Logic
(Jahanian and Mok, 1986) language which views a computation as a sequence of event
occurrences. They are very versatile. The user has no need to consult the whole history of
event occurrences. Instead he/she can concentrate on assertion programming and let the
prototyping tool do the required checking of the temporal properties. However, assertion
checking cannot be viewed as an exhaustive verification tool but only as a specification testing
(Ghezzi, et al., 1991).
The developed toolset –jCRSM- provides facilities for the graphical editing of machines and
systems, for exporting and reusing library machines in different projects, for debugging a
system, for the automatic generation of Java code which can be compiled and executed within
3
or out of the environment. jCRSM allows also to import predefined Java classes which can
connect, through interfaces to native methods, to pre-existing driver software controlling
sensor or actuator devices. jCRSM was achieved using Java2 on a Windows 95 platform. The
implementation is totally portable on any platform which enables Java development. Moreover,
the compiled code of a CRSM system executes on any platform which supports the java
runtime environment (jre), i.e., runtime bytecode interpreter and Java Virtual Machine (JVM).
The paper is structured as follows. Section 2 gives an overview to CRSM’s, to the
specification of timing constraints and to the role played by assertions for temporal analysis.
An example is furnished to clarify the application of CRSM modelling concepts to a typical
control system. Section 3 summarises a customisable actor kernel which provides the runtime
representation of a CRSM specification. Details of a mapping from machines and assertions on
actors and a proposed Java programming style are given in section 4. Section 5 describes a
control machine for the execution of CRSM’s. Both the prototyping/simulation and the real-
time operation modes are discussed. Section 6 highlights the main features of the developed
toolset (jCRSM) in Java2 supporting graphical modelling and temporal checking of CRSM’s.
Finally, some remarks about the practical use of jCRSM and guidelines of continued research
are given in the conclusions.
2. COMMUNICATING REAL-TIME STATE MACHINES
CRSM’s were designed as an executable specification language (Shaw, 1992), which rely on a
distributed model of concurrency and synchronous one-to-one communications. A system
specification is closed, i.e., machines are introduced to model both the computer system and its
controlled environment. The CRSM’s of system are linked to one another by unidirectional
typed channels where IO is modelled directly after CSP (Hoare, 1985).
2.1 Guarded commands
A CRSM is as a timed state machine with one start state and one or more halt states, where
timing constraints can be involved in every state transition. A state transition is described by a
guarded command with a timing constraint: G→C [τ]. The guard G is made up of state
variables of the CRSM. It must be true (the default value if the guard is missing) for enabling
the command. The command can be computational (e.g., expressing an internal processing or a
physical activity performed on an interface object like a sensor or an actuator) or an IO. An IO
4
command is an input, e.g., Ch(v)?, or output, e.g., Ch(expr)!, operation on a channel. When
both the CRSM’s involved in a communication over a channel are ready (rendezvous), the
couple of IO commands is satisfied with a simultaneous state change in both machines, the
resultant assignment v:=expr, and the two CRSM’s which resume concurrent execution.
Command execution is atomic.
2.2 Timing constraints
The timing constraint is typically a timing interval [tmin,tmax], tmin≤tmax, which expresses the
possible rendezvous times for an IO or the possible duration times for an internal command.
The time interval can degenerate to a single time value. The default timing interval for an IO
command is [0,∞] which means that a CRSM is ready for a communication at any time the
partner is. A rendezvous is only possible at any time in the intersection of the intervals
associated to the two matching IO commands. An impossible rendezvous can introduce a
deadlock for a CRSM in the case the IO command is the only command out of the current
state.
2.3 Timers
A global time notion is provided in a system of CRSM’s and is available through the rt
variable. Each machine M has a companion real-time clock machine, with a timer channel,
which acts as a time server. A command like timer ?[y] allows M to set a timeout to occur
after y time units from the current time. These facilities can be used, for example, to program a
periodic behaviour.
2.4 An example
Figure 1 portrays a simple steam boiler process control system. A sensor S periodically
samples the pressure and sends it to the controller C. When the controller detects the pressure
exceeds a given high_pressure value, it commands the opening of a valve V which is kept open
until the pressure decreases under a low_pressure value. The CRSM’s S, C and V are linked by
three channels: Sensor Channel (SC), Open Valve (OV) and Close Valve (CV). SC carries as
data a sampled pressure value. OV and CV are pure synchronisation channels.
Timing attributes of the system are: the sensor period p, the reading time s of the sensor, the
open/closing time v of valve. The controller is provided of the high_pressure and low_pressure
5
values. For simplicity, some transitions are inscribed by chains of consecutive commands
(separated by /) which have associated hidden states. The sensor machine takes the real time
value at the beginning of each cycle (state S0). Then it samples the pressure, engages a
communication with the controller, takes again the current time, waits for the completion of
the period and, finally, returns to the home state S0. Other details of the three machines should
be self-explanatory.
Timing requirements are associated to sensor periodicity and valve deadline. For the system to
behave correctly, the sensor period should not be overflowed (with some tolerance).
Moreover, from the detection of a critical pressure the control system should open the valve
within a deadline d. These properties must be verified through analysis of the system
behaviour.
2.5 Time stamped event histories and assertions
The evolution of a CRSM system is represented by the history of its transition firings. From
time to time one transition is chosen from the set of enabled and ready transitions on the basis
of the Earliest-Time-First strategy. Ties are broken non deterministically. Transition firing
advances the system time of the minimum quantity. For each channel event a copy of the
channel transmitted data and the occurrence time of the event are recorded on the so called
Time stamped Event History (TEH) (Shaw, 1997) associated to the channel:
e0(d0)@t0 e1(d1)@t1 e2(d2)@t2 …
where the first event was e0 with the data value d0 and occurred at (@) time t0 and so forth.
The history of transition firings can be generated by executing the specification and explored
through assertions. For instance, the deadline upon the opening of the valve could be
expressed by the assertion in Figure 2, using the assertion language proposed in (Raju and
Shaw, 1994). It is supposed that the period p of the pressure sensor covers a pressure reading
and the causally connected opening/closing of the valve, i.e., p≥s+v.
The function time() returns the occurrence time of an instance of a channel event. In the
example the latest events of OV and SC channels are checked. More in general, assertion
6
specifications exploit the operations time(Channel,index) and value(Channel,index) which are
based on the Real Time Logic formalism (Jahanian and Mok, 1986). value(Channel,index)
returns, if exists, the data value associated to the occurrence of the channel event specified by
index. A negative index counts back on the TEH starting from the most recent event. A
positive index is counted up from the first event in the history. A non existing entry is signalled
by the time/value function which returns –1. For simplicity, the type-checking issues of the
value function are temporarily ignored.
The deadline assertion of Figure 2 can also be written as in Figure 3 (delayed assertion). Here
the triggering channel event is changed to SC which carries a critical pressure value causing the
opening of the valve. The assertion is actually checked d time units after being triggered.
The assertion requires the value of the deadline d and the critical level of pressure
high_pressure. The general support of delayed assertions necessitates of the timer facility. In
this work the viewpoint of assertion checkers as a special kind of CRSM machines is adopted
thus achieving maximal flexibility. Figure 4 sketches a special CRSM associated to the
assertion in Figure 3. The when clauses behaves as a guard and specialises in intercepting a
rendezvous on the triggering channel SC (see later in this paper for an implementation). The
special character of an assertion machine derives from it not being active part of the modelled
system. It does not have channels for exchanging communications with other machines. The
assert checking code typically annotates the evaluation of the boolean expression on a text file.
Figure 5 shows an assertion which controls the quality of sensor periodicity by ensuring that
each pressure reading occurs after a time which is the period +/- a given tolerance e. Since
assertions are normally triggered by channel events, the property can be checked in an
equivalent form by evaluating the difference in time of two consecutive communications upon
the channel SC.
Assertions can also cope with safety conditions. As an example, Figure 6 shows an assertion
which checks that when the pressure value lies in the interval [low_pressure..high_pressure]
the valve has been opened. This is achieved by controlling that the sampled pressure value is
preceded by the opening of the valve and that if a most recent closing valve event exists it
temporally precedes the opening valve event.
7
In Figure 1, the SC output command in the Sensor machine has been (implicitly) flagged by the
default time window [0,∞]. In reality, in order to guarantee sensor periodicity, the rendezvous
has to take place in the time interval [0,p-s+e] where 0 refers to the instant immediately after
the time the machine entered the (hidden) state following the pressure reading. Obviously,
checking the quality of sensor periodicity through the assertion in Figure 5 furnishes
information also on the correctness of rendezvous times on SC without incurring in a possible
deadlock involving the Sensor and Controller machines.
A prototyping environment for specifying and testing properties of a system of CRSM’s has
been previously described in (Raju and Shaw, 1994). In this paper a Java2 graphical
environment is proposed which relies on a mapping of CRSM’s on to real time actors. The
goal is to exploit an actor kernel which supports prototyping and testing of timing properties
and serve also as the final implementation level, thus linking the specification to concrete
development. Java 2 is also used for the final implementation of a modelled system.
3. A CUSTOMISABLE ACTOR KERNEL
In (Kirk, et al., 1997) (Nigro and Pupo, 1998) an actor framework (Agha, 1986) is proposed
for the development of distributed and predictable real-time systems. The approach favours a
fulfilment of application requirements through a holistic integration of an application and its
operating software, i.e., a programmer-defined scheduling algorithm. An actor system with
timing constraints can be formalised by Coloured Petri Nets and its properties (functional and
temporal) checked using simulation and occurrence graphs (Nigro and Pupo, 1999).
Actors are modelled as finite state machines. Asynchronous message passing represents the
basic communication paradigm. The arrival of a message triggers a state transition and the
execution of an action (message processing). Actions are atomic. The execution of an action,
besides the modifications to the internal data state of the actor, can generate new messages
toward acquaintances (including the sender actor). At the end of current message processing
the actor is ready again to receive the next message.
Predictable time behaviour rests on the light-weight nature of actors. They have no internal
threads. Pre-emption and conventional mutual exclusion mechanisms are avoided. Within a
8
community of actors allocated to the same physical processor, concurrency is achieved by
action interleaving, i.e., by orchestrating message scheduling and dispatching among the
various actors.
For modularity reasons, a control machine concept is introduced which hides the control
engine, i.e., the basic message scheduling, dispatching and controlling activities. The control
engine uses a single thread of control which dynamically hosts the execution of the actions of
the controlled actors. The control machine has the following sub-components: Scheduler,
Message Plan, Controller and Real-Time Clock. Messages are transparently filtered by the
Scheduler which applies to them a suitable control policy which is driven by timing constraints
enforcement. The Scheduler schedules “just sent messages” on the Message Plan. The
Controller is responsible of message selection from the Message Plan and message dispatching
to the relevant actor. The Real-Time Clock provides the time notion to the control machine
and application actors. Time can be virtual for prototyping purposes.
The key point is that Scheduler and Controller are actors themselves. They can be customised
through programming. A specific architecture of the control machine, e.g., Message Plan
organisation, directly follows from the adopted timing model. For example, messages can be
scheduled on the Message Plan according to timing validity intervals [tmin,tmax], tmin≤tmax,
which specify possible delivery times. In this case, message selection and dispatching is
regulated by an Earliest-Deadline-First strategy. Other solutions are possible. In this paper an
organisation is proposed which is suited to the support of CRSM’s. Both a virtual time and
real time control machines were implemented respectively for prototyping/simulation and real
execution of a CRSM model.
4. MAPPING CRSM’s ON ACTORS
CRSM’s can be mapped on actors by means of a self-driving model. The following summarises
the mapping and assumes Java as the target programming language.
The base class RT provides a discrete time model and the member function rt() which returns
the current system time (a long).
The Actor base class provides the common services for actors, e.g., the non-blocking send
operation, the become operation for changing the actor state, the (abstract) handler for
9
responding to an incoming message. A CRSM-actor class extends Actor and captures through
a redefinition of the handler method exactly the CRSM life cycle, i.e., the machine transition
diagram.
Internal commands, timers and channels are uniformly transformed into messages. A machine-
actor sends to itself all the messages corresponding to the enabled guarded commands for the
transitions out of current state. One of this message will be (possibly) chosen and delivered by
the control machine and the others de-scheduled.
4.1 Mapping machines on actors
Figure 7 shows a Java actor class for the Sensor machine portrayed in Figure 1. The Sensor
class has a method initialise() which is used instead of the constructor to initialise the actor
state. Initialise() creates the internal command ic and the timer timer by specifying itself (this)
as the destination actor. Then it sets the initial state (S0) and sends to itself the internal
command for beginning a reading period. States from S0_1_0 to S0_4_0 are hidden states on
the transition S0-S0. They serve the purposes of supporting the execution of chained
commands. As one can see from Figure 7, the answer to a message consists in executing an
action corresponding to the message, e.g., an internal command action, then making a state
change which is followed by the self-send of all the messages which can bring the machine out
to a next state and so forth (proposed set of messages). PressureSensor is a driver class. Its
static method reading() returns the current pressure value. During prototyping the method can
simply read from the keyboard or from an archived file of real pressure readings.
The collection of messages an actor understands is pre-allocated and reused during the lifetime
of the machine in order to avoid dynamic memory allocation/deallocation operations. Also the
data carried by a channel is pre-allocated (e.g., the SCDataContainer) before the actor is
conducted into execution, and repeatedly reused (filled before a communication).
4.2 Message classes
The Message base class provides common attributes for messages: the destination (target)
actor, the carried data (an Object[]), the occurrence time, and bookeeping pointers (next,
prior, ring …) useful to insert/extract the message into/from one or more message lists. The
TimedMessage class extends Message by a time window [tmin,tmax]. A timer can directly be
10
programmed as an instance of a TimedMessage. The InternalCommand class extends
TimedMessage by a duration interval [dmin,dmax]. The Channel class extends TimedMessage
and provides the channel abstraction. It hosts the following information:
• the identity of the channel sender/receiver actors
• two time windows associated respectively to the sender and the receiver
• status information for indicating the readiness of the sender/receiver to a rendezvous
• a Rendezvous inner class, derived from TimedMessage, two instances of which, outRV and
inRV, are pre-allocated in the channel for communicating the rendezvous respectively to
the sender and the receiver. The two Rendezvous instances have a link to the Channel
object
• the channel transmitted data, inherited from Message base class, as an Object[], i.e., an
array of objects. For generality, each item in the array is in turn an array of basic Java
types. The transmitted data are actually copied into the data field of the inRV message
from which they can be received by the destination machine following a rendezvous
• the time stamped event history, teh, i.e., an instance of the TEH class
• the size of the time stamped event history
• the list of assertions to be checked at each channel event occurrence.
The set method allows to set the time window of an internal command or a timer. It is
overloaded to allow the specification of single time intervals. The in/out methods of the
Channel class correspond respectively to the input (?) and output (!) operations on a channel.
The out() method receives the transmitted channel data as an Object[]. Following a channel’s
in() invocation, the receiver can access the transmitted channel value through the data field in
the inRV message. It is worthy of note that the runtime type information coming with objects
allows a type-safe access to the received information.
4.1 Mapping assertions on actors
Assertion checkers have in general a life cycle and can exploit the timer facility for
implementing delayed assertions. Assertion checkers can be embedded in the control machine
(see also the next section) for an early intercept of a message under dispatching and the
evaluation of the triggering conditions. As a consequence, an assertion checker can be
11
programmed as an actor following the style suggested in Figure 7. Figure 8 shows the code of
an actor for the delayed deadline assertion of the steam boiler example (Figures 3 and 4).
The assertion-actor admits two states. In the first one (S0) the triggering event (the SC
message) is sensed. After that the status is changed to S0_1_0 and the pressure value of the
most recent SC event is retrieved from the SC’s teh data structure (actually the pressure value
is got from index 0 in the Object[] value at the –1 position in the SC’teh). Finally, a timer is set
to fire after d time units. The timer is received (fired) in the state S0_1_0 where the actor
changes its status back to S0 and then executes the assertion checking code. The assertion
code is naturally coded as an internal command directly following the arrival of the timer firing
event. For simplicity, an explicit internal command which is self-sent, scheduled and dispatched
to the assertion checker actor is not used, since there is no need, in this case, for the
specification of an action duration. All of this reflects the basic assumption that assertion
checkers serve for temporal assessment during prototyping of a CRSM specification model.
They are not part of the final system code.
The code listing in Figure 8 makes use of the AssertionsWriter class whose assert static
method writes on a text file the boolean result of the assertion, along with the value of current
time and a string which describes the checked assertion.
The Java code in the Figures 7 and 8 can be generated automatically from the graphical
modelling of CRSM machines (see later in this paper the jCRSM toolset).
4.2 System configuration
The configuration of a CRSM system, e.g., performed in the main() method of a Java
application class, consists in building the machine-actors, then making the channel objects
along with bindings, for each channel, to the sender and receiver. After that, actors are
initialised by invoking the initialise method. The constructor of the Channel class allows the
expression of the initial binding, i.e., the identity of channel’s sender/receiver. The binding
operation can be re-executed dynamically by using the Channel rebind method. Finally, the
Controller method of the control machine is launched (see the next section).
12
5. CRSM’s EXECUTION MODES
Figure 9 illustrates the architecture of a control machine tailored to prototyping and testing of
a system of CRSM’s. The organisation can be slightly refined to become the runtime control
machine for real execution.
The Scheduler actor takes as input the “just sent messages” generated by the last activated
machine and schedules them on the Message Plan which is ranked by the tmin attribute and
then by the tmax attribute of the message time intervals. An internal command is scheduled
according to the timing window [0,∞]. A ready for rendezvous channel has the scheduling
window [t1,t2]=[t1sender,t2sender]∩[t1receiver,t2receiver]. A timer is scheduled according to its expire
time, i.e., the time interval is [texpire_time, texpire_time]. In reality all the above intervals are relative
to the time the machine which generated the associated command entered its current state. If tE
denotes the entering time of such a state, the relative scheduling window [t1,t2] is converted
into the absolute window [tE+t1+δ, tE+t2+δ] where δ is the dwell-time (Shaw, 1992), i.e., a
minimum time a machine (under simulation and prototyping) is supposed to remain in a state.
The organisation of the Message Plan purposely avoids dynamic memory
allocation/deallocation operations by having that messages act themselves as the nodes of the
Plan list. Insert/remove operations reduce to pointer adjustments. The set of proposed
messages by a machine are linked to one another in a ring to facilitate de-schedule operations
(see below).
The controller selects from the Plan the next message according to the Earliest-Time-First
strategy. The message with the minimum tmin is chosen. However, to be selected, the time
interval [t1,t2] of a ready-to-commit rendezvous message must be active (rt is within the
interval) and its margin, t2-rt, the minimum. When multiple choices are possible, the controller
selects non deterministically. The chosen message is time stamped with the current value of rt
(occurrence time). Pending messages in the Message Plan directed to the same selected
machine are de-scheduled. As a side effect, the de-schedule operations can inactivate a
previously set timer. Finally, the message is dispatched. If the chosen message is a channel, the
transmitted value along with the message time stamp are copied into the channel time stamped
event history. The two contained rendezvous messages are then delivered in two consecutive
control cycles.
13
Prototyping execution of CRSM’s is complemented by the collection of Assertion Checkers
which have an early access to the under dispatching message.
Figure 9 clarifies the message handling from scheduling to selection and dispatching. However,
from the control point of view, it is the Controller which carries the steps of the control loop.
At each iteration, the Controller gives the Scheduler the chance to schedule the “just sent
messages”. Then it proceeds with the selection of the next message and the de-schedule of
deactivated messages. After that the Controller activates, in the case the message is a channel
event, all the Assertion Checkers which registered with the channel. The handler method of an
assertion is launched with the channel message as an argument. After assertion checking, the
selected message (separately the component messages inRV and outRV for a channel message)
is eventually dispatched to the destination actor. At the end of the message handler in the
actor, the control loop is resumed for a new iteration.
It is worth noting that the control machine concept enables a smooth transition from the
prototyping mode to the real execution mode. First of all, the machine-actors do not need any
change when operated under prototyping or real execution. The only differences concern the
time management.
During prototyping the system is handled under simulation. The “real time” rt is advanced of a
discrete amount by the controller just after the selection process. In particular, if the selected
message corresponds to an internal command with duration interval [d1,d2], then rt is
incremented of an amount d, d1≤d≤d2. For worst-case-analysis, rt is augmented of d2. If the
message is a rendezvous with absolute time interval [t1,t2], then rt is incremented of a quantity
t, t1≤t≤t2.
On the other hand, in the real operation of the system on the target architecture rt advances
automatically and there is no need to take in account a dwell-time in states. If required, the
Controller waits for the rt to be increased up to the tmin value of the most imminent message.
However, in both operating modes, the selection strategy of the Controller is the same.
14
6. AN OVERVIEW OF THE jCRSM TOOLSET
The jCRSM tool set was designed to assist the developer by automating the many tasks which
normally are carried out manually and are error-prone. These tasks are concerned with the
graphical editing of machines and systems together with the required topological checks, the
automatic generation and compilation of Java code for machines and systems, the monitoring
of the runtime behaviour of a CRSM system through debugging and prototyping. In addition,
the generated Java code for a system can be handled externally to the environment for
customisation and upload on the target real-time architecture. The features of jCRSM can be
activated by menus. The most common ones are also available for rapid access at the command
toolbar (file operations, code generation/compilation, debugging/prototyping and so forth) and
the editing tool bar (see Figure 10).
The graphical editor of jCRSM permits the specification of a system and its component
machines. It is possible to switch between the two modelling levels by clicking respectively on
a machine name or a system name in the tree structured navigator tool (Figure 10) which
shows at any moment all the opened files. A system project is mapped on a Java package. All
the relevant class files belong to the same subdirectory of jCRSM\Systems main directory. The
CRSM directory holds the common base classes for actors, messages, control machines and
the like.
Figure 10 portrays a system level specification for the steam boiler control system. It shows the
involved machines, the interconnection channels and two assertion machines respectively
associated to valve deadline (Figure 3) and sensor periodicity (Figure 5). Assertion channels
are dashed. Trigger channels are dashed and black. It is possible to hide all the assertion
components in a system model.
6.1 Editing
jCRSM facilitates the development of real-time systems by supporting a flexible concept of a
machine. A machine can be defined in isolation and exported as a library component. It can
then subsequently be imported and reused into different projects. To enforce this component-
based architectural design, a CRSM machine is featured with structural (encapsulated data
environment), behavioural (state machine) and interface (i/o ports) properties. Structural
properties refer to the local data a machine requires as a support to its computational activities
15
(e.g., internal command actions). jCRSM permits to associate local data (name, type and
replication factor) to a machine and to clarify those items which need a value through a
parameter of the initialize() method. The dynamics of a machine is captured within its state
machine. Ports have a mode (input/output), a status (connected/unconnected), and a type (an
aggregate of basic Java types, each item coming with a possible replication factor, i.e., an
array). The design of the state machine is based on I/O commands referring to local (possibly
unconnected) ports. The specification of a machine can thus be saved (in the Java serialization
format) on disk and then reused in different applications. In a particular system configuration,
channels are established as interconnections between compatible ports of couple of machines.
Ports belong to the graphical level of machine modelling. They are resolved, at the code
generation phase, to the interconnection channels. Ports are selected for choice when making a
channel. To exemplify, on the destination machine, jCRSM automatically proposes only the
subset of ports which are mode and type compatible with the output port chosen on the sender
machine.
The jCRSM editor enforces a “by-example” style in the construction of guarded commands
during the behavioural specification of a machine. A transition can be flagged by a chain of
guarded commands. For each command, the user is assisted in making the boolean expression
representing the guard (true by default), the command itself (i.e., an internal command, a timer
or an I/O command) and the timing constraint (time interval). To exemplify, for a typed output
port (i.e., the transmitter side of a channel) the user anticipates the aggregate type during port
specification. When building the output command, the data environment is proposed from
which the user can select data items suitable for making the expressions which constitute the
command value. All of this helps minimising errors in the formation of commands. The
specification of a timer reduces to furnishing the firing time. An internal command is directly
coded as a Java algorithm which manipulates the machine data. In addition, a machine can
import pre-existing Java classes whose methods can be part of internal commands. An internal
command is required to be time bounded. Therefore, dynamic data structures, unbounded
loops and so forth should be avoided.
Figure 11 shows the Controller machine model for the steam boiler control system (Figure 1)
along with details of the guarded command on the transition C1-C2.
16
The modelling phases of an assertion machine are similar to those of regular machines. The
code of an assertion is roughly equivalent to an internal command. To support delayed
assertions, an assertion machine can rely on the construction of a state machine and make use
of the timer facility (see Figure 8). A distinguished feature of an assertion machine is the
specification of the triggering channel which provides the when clause and the access to other
consulting channels for querying the time stamped event histories.
6.2 Java code generation
Besides the semantic controls which are performed during the construction of a model (e.g.,
the compatibility of the ports linked by a channel), a system model can be further checked for
inconsistencies in the interconnection topology (e.g., some ports are still unconnected). Other
checks are performed within each machine where, for example, it is controlled that
unreacheable states are not introduced. A checked system can be automatically transformed
into a Java application by generating the code for the regular and assertion machines and for
the configurer which is responsible of making a CRSM system able to execute either under
prototyping or real time operation. The generated Java code can be compiled from within
jCRSM by invoking the available Java compiler on the host platform.
Figure 12 shows a portion of the generated Java code for the Controller machine. The Java
code of machines can be separately generated and compiled or the “compile-all” option in the
Build menu is chosen which builds the whole system or reports errors from the Java compiler.
6.3 Debugging and prototyping
The class files of a project constitute the representation of the CRSM specification which can
be executed for functional and temporal analysis. Functional analysis can be assisted by the
debug tool. It allows to set breakpoints on selected machine states and to watch changes
affecting significant variables on the watches window. It becomes possible to execute the
system one-transition-at-a-time, under virtual time and debug mode, or run the system until the
next breakpoint, after that the watch window shows the new values got by the observed
variables. The debug tool was found very useful for setting external conditions and visually
tracing at the jCRSM graphical user-interface the functional reactions of the system, i.e., the
logical chain of transitions and state changes induced by the external stimuli. For example, for
the steam boiler control system it was traced that after a critical pressure reading, simulated by
17
reading from the keyboard a value exceeding high_pressure, it effectively follows a reaction
which eventually ends by opening the valve. The debug tool relies on Java reflection, e.g., the
ability of getting control of the data members of a generic class.
Of course, for a real-time system the quantitative analysis of temporal behaviour is of utmost
importance. Toward this jCRSM enables system prototyping with assertion checking. A
simulation control machine is initialized by the configurer to animate system execution.
Prototyping parameters are the simulation period and the dwell-time. The simulation period
establishes a simulated time amount during which the system activity is monitored. The choice
of this time amount is critical in that the developer has to “guarantee” that sufficient and
significant system behaviour (e.g., multiple and interfering reactions) really occurs to drive the
assertions.
jCRSM prototyping is capable of generating two text files: the trace file and the assert file.
The former records the whole history of event occurrences. This information can be explored
as a support to functional reactions analysis too. The assert file is concerned with assertion
checking only. A description of the sensed assertion, the occurrence time and the boolean
result of the check are reported. The assert file can be used to guide, iteratively, the adjustment
of the timing constraints in the case of recorded violations.
The simple steam boiler control system was prototyped for demonstration purposes assuming
the millisecond as the time unit and the following time quantities: pressure reading s=500,
valve opening/closing v=300, dwell-time=1, sensor period=1000, tolerance on the sensor
period e=5, valve deadline=10, simulation period=104 (equivalent to 10 sensor periods). Figure
13 portrays the assert file recorded when 3 times during the simulation the pressure goes
beyond the critical level. It shows that both the valve deadline and the sensor period are always
satisfied. Moreover, the trace file (not shown for brevity) confirms that the opening of the
valve following a critical pressure occurs in 3 time units which correspond to 3 state changes
(or dwell-times), one in the Sensor and two in the controller (transitions C0-C1 and C1-C2).
7. CONCLUSIONS AND ON-GOING WORK
This paper proposes a methodology for the development of real time systems which is based
on the Communicating Real-time State Machines (CRSM’s) formal specification language
18
(Shaw, 1992). A modelled system is made executable by mapping it on an actor framework
characterised by a customisable message-based runtime support and associated constraint-
directed scheduling, which favour timing predictability (Nigro and Pupo, 1999). Novel in the
proposed approach is a seamless development life cycle, where the actor representation serves
both for prototyping and simulation of the specification and for the final system
implementation. Thus the risks of distortions during the transformation from analysis to design
and implementation are minimised.
A Java2 toolset (jCRSM) was achieved which simplifies, through visual programming, the
specification, code generation and prototyping of a system. Java is also used as the target
implementation language for a CRSM system, thus ensuring maximal portability while keeping
interoperability with native existing software. Since Java is normally unpredictable, care is used
in avoiding dynamic memory operations within actors and the runtime support. Moreover,
actor concurrency is based on message interleaving and atomic actions, and not on Java
threads and related synchronization mechanisms and built-in scheduling.
A key feature of CRSM’s is its focus on the specification of timing constraints since the early
stages of a development. The jCRSM approach enables prototyping and verification of a
modelled system through assertions on the recorded time stamped event occurrences.
Prototyping and assertions permit to check and possibly adjust timing constraints iteratively
during a project. As already pointed out in (Raju and Shaw, 1994) the assertions method is
obviously limited: it is a test not a property proof. Thus it can reveal temporal violations but
can’t prove they are impossible. For this kind of conclusions, exhaustive methods based on the
construction of the time reachability tree (TRT) which systematically enumerates all the
possible execution states in which a system could find itself at runtime, should be used instead.
Unfortunately such a construction is often intractable in practical cases. This is due to the high-
level character of the programming language CRSM’s use for specifying actions and related
data. Only in the special cases of small systems which depend on variables with a restricted
range of values would the construction of the TRT be possible. On the other hand, the TRT
could allow formal analysis of temporal requirements and also of other general properties of a
CRSM system like checking for the possibility of deadlocks in groups of machines.
19
The CRSM timing model can be related to that offered by well-known object-oriented design
methods and tools like Statemate (Harel and Politi, 1998), ROOM (Selic, et al., 1994) and the
latest UML-RT (Selic and Rumbaugh, 1998). Although such methods are equipped of
powerful visual mechanisms for specifying structural and behavioural aspects of complex real-
time systems organised as collections of co-operating state machines, they offer limited support
to the specification and verification of timing constraints. Normally, only the possibility of
constraining an activity to the passage of a time amount (something like setting a timer) is
provided. Recently (Hermeling, et al., 1999), some constructs for specifying timing constraints
in UML-RT have been proposed for the purposes of analysing system reactions to external
stimuli according to end-to-end timing constraints.
On-going work is geared at extending the jCRSM toolset in order to broaden its applicability
to large systems. In particular, the concept of a hierarchical decomposition of a machine,
borrowed from Statecharts (Harel and Politi, 1998) and available in the aforementioned object-
oriented methods, is felt fundamental to help designing complex machines. As a minimal
benefit, the feature could allow splitting a state machine into the two common macro-states
(subject to decomposition) separately dealing with normal and exceptional behaviour.
Decomposition should conveniently be accompanied by aggregation and compositionality
mechanisms for building library components consisting of group of interconnected and
configured machines.
Another extension concerns an explicit handling of distribution issues. Although the CRSM
method allows to take into account the network transmission times of messages when
attaching the timing constraints to matching I/O commands, it is believed that making an
explicit reference to network structures and protocols would improve system specification,
prototyping, code generation, configuration and code upload activities, stressing further the
main goal of jCRSM of narrowing the final implementation to the specification of a system.
Experience is in progress with the use of the priority based CAN bus (CAN, 1992).
Finally, prosecution of the research aims also to applying jCRSM to the development of real
life process control systems.
20
Acknowledgments
The authors are grateful to Giovanni Gambaro and Giuseppe De Sio for their contribution to
the prototype implementation of jCRSM, and to Brian Kirk and Francesco Pupo for the helpful
comments on a preliminary draft of this paper.
REFERENCES
Agha G. (1986). Actors: A model for concurrent computation in distributed systems. MIT
Press.
CAN (1992). Road Vehicles – Interchange of Digital Information – Controller Area Network
(CAN) for High Speed Communication. ISO DIS 11898.
Gerber R. and I. Lee (1992). A layered approach to automating the verification of real-time
systems. IEEE Trans. on Software Eng., 18(9), pp. 768-784, September.
Ghezzi C., D. Mandrioli, S. Morasca and M. Pezzè (1991). A unified high-level Petri net
formalism for time-critical systems. IEEE Transactions on Software Eng., 17(2), pp. 160-
172, February.
Harel D. and M. Politi (1998). Modeling reactive systems with statecharts. McGraw-Hill.
Hermeling M., O. van Roosmalen and B. Selic (1999). Timing constraints and object-oriented
design. Proc. of 24th IFAC/IFIP Workshop on Real Time Programming (WRTP’99), pp.
15-20.
Hoare C.A.R. (1985). Communicating Sequential Processes. Prentice-Hall International.
Jahanian F. and A. Mok (1986). Safety analysis of timing properties in real-time systems. IEEE
Trans. on Software Eng., 12(9), pp. 890-904.
Kirk B., L. Nigro and F. Pupo (1997). Using real time constraints for modularisation. Lecture
Notes in Computer Science, 1204, Springer-Verlag, pp. 236-251.
Nielsen B., S. Ren and G. Agha (1998). Specification of real-time interaction constraints. Proc.
of First Int. Symposium on Object-Oriented Real-Time Computing, IEEE Computer
Society.
Nigro L. and F. Pupo (1998). A modular approach to real-time programming using actors and
Java. Control Engineering Practice, 6(12), pp. 1485-1491, December.
Nigro L. and F. Pupo (1999). Schedulability analysis of real time actor systems using Coloured
Petri Nets. To appear in Advances in Petri Nets series of Lecture Notes in Computer
Science, in the special volume Concurrent Object-Oriented Programming and Petri Nets
(Agha, De Cindio and Rozenberg Eds.)
21
Raju S. and A. Shaw (1994). A prototyping environment for specifying, executing and
checking Communicating Real-Time State Machines. Software-Practice and Experience,
24(2), pp. 175-195.
Shaw A. (1992). Communicating Real-Time State Machines. IEEE Trans. on Software Eng.,
18(9), pp. 805-816.
Shaw A. (1997). Time-stamped event histories: a real-time programming object. Proc. of 22nd
IFAC/IFIP Workshop on Real-Time Programming (WRTP’97), Lyon, 15-17 September,
pp. 97-100.
Shaw A. and A. Rupp (1996). Real-time programming with time-stamped histories. TR#UW-
CSE-96-05-02, Dept. of Computer Science and Eng., U. of Washington.
Selic B., G. Gullekson and P.T. Ward (1994). Real-time Object Oriented Modeling, John
Wiley.
Selic B. and J. Rumbaugh (1998). Using UML for modelling complex real-time systems.
http://www.ObjecTime.com/otl/technical, ObjecTime Limited.
22
List of figures
Figure 1. Steam boiler control system.
when OV {assert( time(OV,-1)–time(SC,-1) ≤ d );
}
Figure 2. Deadline assertion for the steam boiler.
when SC+d {if( value(SC,-1)>high_pressure ){
long trigger_time=time(SC,-1);long opening_time=time(OV,-1);assert( opening_time≥trigger_time && opening_time≤trigger_time+d );
}}
Figure 3. Delayed deadline assertion.
S
SC(pressure) OV
CV
SYSTEM
C V
pressure≥high_pressure→ OV !
CONTROLLER
SC(pressure) ?
pressure<low_pressure
→CV !
pressure <high_pressure→skip [0]
C0
C1
C2
SC(pressure)?
sample(pressure)[s] /SC(pressure) ! / y:=rt-y [0] /timer ? [p-y] / y:=rt [0]
y:=rt
S0
SENSOR
Closed Open
OV? / open_valve [v]
CV ? / close_valve [v]
VALVE
23
Figure 4. Scheme of a CRSM-assertion checker.
when SC {long previous=time(SC,-2), current;if( previous!=-1 ) {
current=time(SC,-1);assert( current-previous≥p-e && current-previous≤p+e );
}}
Figure 5. Assertion checking sensor periodicity.
when SC{double pressure=value(SC,-1);long t0=time(SC,-1), t1=time(OV,-1), t2=time(CV,-1);if( low_pressure≤pressure && pressure≤high_pressure ) {
assert( t1!=-1 );assert( t0>t1 && t1>t2 );
}
Figure 6. A safety assertion for the valve.
when SC→timer ?[d] /assertion check as in Fig. 3
S0
ValveDeadlineAssertion
24
package steamboiler;import CRSM.*;
public class Sensor extends Actor{private final byte S0=0, S0_1_0=1, S0_2_0=2, S0_3_0=3, S0_4_0=4; //internal statesprivate double pressure;private long y, p, s;private Channel SC;private TimedMessage timer, ic;private Object[] SCDataContainer= { new double[1] }; //pre-allocated SC’s datapublic void initialise( long p, long s, Channel SC ){
this.p=p; this.s=s; this.SC=SC;timer=new TimedMessage (this); ic=new InternalCommand(this);y=RT.rt(); become(S0); send( ic.set(s) );
}//initialisepublic void handler( Message m ){
switch( currentStatus() ){case S0: if( m==ic ) {
// internal command actionpressure=PressureSensor.reading();//state changebecome(S0_1_0);//self-send of exiting command-messages (proposed set)((double[])SCDataContainer[0])[0]=pressure;send( SC.out( SCDataContainer ) );
}; break;case S0_1_0: if( m==SC.outRV ) {
become(S0_2_0);send( ic.set(0);
}; break;case S0_2_0: if( m==ic ) {
y=y-RT.rt();become(S0_3_0);send( timer.set(p-y) );
}; break;case S0_3_0: if( m==timer ) {
become(S0_4_0);send( ic.set(0) );
}; break;case S0_4_0: if( m==ic ) {
y=RT.rt();become(S0);send( ic.set(0) );
}}//switch
}//handler}//Sensor
Figure 7. A Java Sensor actor class.
25
package steamboiler;import CRSM.*;
public class ValveDeadlineAssertion extends Actor{private final byte S0=0, S0_1_0=1; //internal statesprivate double pressure_value, high_pressure;private long d; //valve deadlineprivate Channel SC, OV;private TimedMessage timer;public void initialize( long d, double high_pressure, Channel SC, Channel OV ){
this.d=d; this.high_pressure=high_pressure; this.SC=SC; this.OV=OV;timer=new TimedMessage(this); become(S0);
}//initializepublic void handler( Message m ){
switch( currentStatus() ){case S0: if( m=SC ){
pressure_value=(double[])(SC.teh.value(0,-1))[0];become( S0_1_0 );send( timer.set( d ) );
}; break;case S0_1_0: if( m==timer ) {
become( S0 );if( pressure_value>high_pressure ){
long trigger_time=SC.teh.time(-1);long opening_time=OV.teh.time(-1);AssertionsWriter.assert( RT.rt(), “Valve deadline assertion”,opening_time>=trigger_time && opening_time<=trigger_time+d );
}}
}//switch}//handler
}//ValveDeadlineAssertion
Figure 8. An actor class for the ValveDeadlineAssertion.
26
Figure 9. Control machine architecture for CRSM’s.
Message Plan
ControllerScheduler
CRSM-Actors
select/deschedule
schedule
dispatchjust sent messages
Control Machine
Real-TimeClock
TEHs
AssertionCheckers
assertions
27
Figure 10. Steam boiler control system under jCRSM.
28
Figure 11. Controller state machine and guarded command on the transition C0-C1.
29
Figure 12. Java code for the Controller machine.
30
Figure 13. Assert file generated by prototyping the steam boiler.