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.