ACTORS AND COLOURED PETRI NETS IN THE DEVELOPMENT LIFE CYCLE OF DISTRIBUTED REAL TIME SYSTE

ACTORS AND COLOURED PETRI NETS IN THE DEVELOPMENT LIFE CYCLE OF DISTRIBUTED REAL TIME SYSTEMS Giancarlo Fortino, Libero Nigro, Francesco PupoDipartimento di Elettronica Informatica e SistemisticaUniversità della Calabria, I-87036 Rende (CS) - ItalyEmail: {g.fortino,l.nigro,f.pupo}@unical.itAbstract: This paper describes an actor-based framework for the development of distributed real-time systems which centres on a holistic approach to the fulfilment of application functional and temporal requirements through an application tuneable operating software in the form of a reflective scheduling structure. The framework makes it possible to prototype and execute a specification of a given system by Coloured Petri Nets in order to verify behavioural and timing constraints. The methodology favours a smooth transformation of an analysed system to a design and implementation in popular object-oriented languages like C++ and Java.Keywords: actors, modularity, timing constraints, Coloured Petri Nets, temporal analysis.1. INTRODUCTIONIn the last years many efforts have been devoted to an exploitation of modularisation and more general software engineering principles in the real-time area, e.g., (Bergmans and Aksit, 1996) (Ren et al., 1996). The main difficulty is concerned with a selection of suitable abstractions which can favour modularisation without impairing fundamental aspects of real time design such as time management (scheduling) and control of the underlying physical architecture. Conventional solutions, e.g., based on plain sequential object-oriented mechanisms or built on top of standard, possibly stripped-down, Operating Systems relying on over-killing concurrent facilities (e.g., scheduling driven by priority and pre-emption) can be inadequate for real time since they can be lacking of essential abstractions (e.g., concurrency) or cannot be able of guaranteeing a time-predictable environment.This work claims that an integrated approach based on user-defined scheduling and selected real time abstractions can be the basis for a predictable and modular architecture for time critical systems. A methodology is proposed for distributed real-time systems which is based on an adaptation of the Actor model (Agha, 1986) with a reflective and time-driven scheduling structure (Kirk et al., 1997) (Nigro and Pupo, 1997).The methodology defines a full system development life cycle. Specification and verification activities are supported by Coloured Petri Nets (CPN) (Jensen, 1992) (Nigro and Pupo, 1998) which allow a formal description of the basic building components.Property analysis, e.g., checking that timing constraints are met, rests on prototype execution and simulation. The CPN model can be iteratively evaluated during a development as more precise timing information is available from the final target architecture. The approach ensures a smooth transition from system analysis to design and implementation in popular object-oriented languages.2. A MODULAR APPROACH TO REAL TIMEPROGRAMMINGIn the proposed approach (Kirk et al., 1997) (Nigro and Pupo, 1997) a system is decomposed into a collection of subsystems linked one to another by a (possibly deterministic) communications network. A subsystem is the unit of programming in-the-large. Timing constraints can be local and/or global. An interaction policy is required in general at the system level in order for the subsystems to correctly co-operate in the fulfilment of system-wide timing constraints.A subsystem is structured as a group of actors plus a control machine (see Fig. 1) which is in charge of message scheduling and dispatching. Actors are the basic building blocks in-the-small. They interact one to another by buffered messages. To help modularisation and time predictability, a variant of the Actor model (Agha, 1986) is actually adopted. Actors are modelled as finite state machines which implement functional behaviour only, i.e., message services. Processing a message consists of a state transition and the execution of an atomic action. At most a single message can be under processing in an actor at a given time. As in the Actor model three basic operations are provided:•new, for the creation of new actors. The data component of an actor includes as attributes a set of acquaintances, i.e., the known actors (including itself) to which messages can be sent•send, for transmitting an asynchronous message to a destination actor. The message can carry data values.The sender continues immediately after a send•become, for changing the actor current state. Each state defines a specific behaviour, i.e., a particular way to react to expected messages. The processing of an unexpected message can be postponed by storing it in data or state.Actors are not aware of timing aspects. All of this improves reusability since actors can be used according to different application timing scenarios (Nigro and Tisato, 1996). Timing constraints are handled within reflective actors which act as schedulers in the control machine. A scheduler is a filter (Bergmans and Aksit, 1996) which transparently captures local or network originated messages and apply to them scheduling actions. Scheduler is also responsible of translating, with the help of application actors, from the external network message format into the local format of the subsystem address space.Actors are concurrent units. Concurrency is ensured, in a subsystem, by message processing interleaving. The Controller component of the control machine repeats a control loop where a message at a time is selected from the Message Plan according to a control strategy, and dispatched to the relevant application actor. The latter provides the service requested by the message and can in turn generate new local or network messages. Local generated messages and incoming network messages are eventually scheduled by the Scheduler component by applying suitable time clauses (Ren et al., 1996) (Nigro and Pupo, 1997). After that the Controller loop is repeated and so forth.The control machine can be customised through programming. First of all, the Scheduler actor can be replaced to reflect special application-dependent requirements. In addition, messages can be scheduled in the Message Plan according to different timing schemes and Real Time Clock systems. For example, a time validity interval [t min, t max] can be attached to each message m to express the constraint that m can’t be dispatched before t min and should not be dispatched after t max to avoid a timing violation. In this case, the selection process of the Controller should be based on a Earliest Deadline First (EDF) strategy. In a more soft real time context, messages could simply be timestamped by their dispatch time in a timeline to achieve a control strategy where messages should be delivered as soon as the dispatch time has expired. Minimum timestamp would guide the message selection process of the Controller. Other solutions are possible.Connection to the controlled environment (e.g., an industrial plant) rests on terminator actors which have an interface to an I/O device driver and another to regular actors to which normal messages can be transmitted to. As often is the case, terminator actors are periodic and can be driven by a scheduler which provide periodic time clauses.3. A CAN BASED CRUISE CONTROL EXAMPLE The following describes a CAN based distributed cruise control system (Luqi, 1993) whose goal is, when enabled, to keep a car at a goal_speed by acting on the throttle. CAN (Kirk, 1995) is a priority bus capable of ensuring deterministic transmission times for both high and low priority messages (Tindell et al., 1995). It can operate in hostile physical environments and require a preliminary design phase of assigning priority to network messages during which each message receives a unique identifier used to resolve conflicts during simultaneous attempts to transmissions.The example system is partitioned into four subsystems: Motion, Driver, Cruise and Operator. Each subsystem is composed of one actor and associated control machine. Operator is used to Init (i.e., making ready to run), Start (i.e., triggering into execution) and Stop (i.e., making no operating, for safety reasons) the system. Cruise hosts the control system. Motion reads the speed from a speedometer and acts upon the throttle. Driver senses the buttons Set and Resume, respectively used by the driver to engage cruising at the current speed and to resume cruising to a previously goal_speed set. Driver is also sensitive to each use of the Brake and the Accelerator.Motion includes speed (float), slope (float) and throttle (float) data attributes. Cruise has attributes such as speed (float), goal_speed (float), throttle (float) and accelerator (float).The behaviour of the entire system is periodic. The basic period p1 is dictated by speed sensor technology. In the following a frequency of 10 readings/sec is assumed, corresponding to a p1=100 ms.The overall periodic behaviour is ensured by having the system which is initialised and started “synchronously” by the Operator (the character of CAN as a network with a “virtual zero” transmission time, when comparing the time granularity of the application (ms) with the effective transmission time of a typical control packet (e.g., 130 µs), should be noted) and by ensuring that Motion and Driver are internally periodic.Although Brake, Set, Resume and Accelerator are naturally sporadic sources of messages, for the purposes of the example, also considering the physical dynamics of thesystem, they are polled periodically with a period p2 of 1 s.Therefore, both Motion and Driver use a local Read message for maintaining the reading process.In response to the Read message, Motion and Driver sample the external environment for reading respectively the Speed (Motion), Set (Driver), Resume (Driver), Brake (Driver) and Accelerator (Driver). Motion/Driver will send to Cruise the just read quantity through a suitable Speed ,Set , ... message. Normally, Driver will find only one external condition verified per period. Indeed, the use of Set is mutually exclusive with Resume and so forth. The sensed condition is transferred to Cruise by an inter-subsystem message.As a consequence of a Read message, two transactions or threads of control (chains of causally connected messages)are respectively started in Motion and Driver. The thread originating into Motion is composed of the Speed message sent to Cruise, followed by the Throttle message generated by Cruise toward Motion. The second thread ends in the Cruise subsystem since any sensed variable affects only the Cruise state (e.g., enabling/disabling cruising).For safety reasons, Brake or Accelerator , which can disengage cruising, are to be handled with a tight deadline of 1 ms measured since the capture time. On the other hand, during cruising the throttle is required to be acted within a 100 ms deadline. Similarly, a stop command from the operator is expected to be managed within 1 ms. Figure 2 summarises the timing requirements of critical threads.Figure 2: Timing requirements of critical threads.Figure 3: Cruise actor functional behaviour.Object Oriented Analysis (OOA) methods like Shlaer-Mellor, OMT ... can directly be used for visualisation purposes of static structure and dynamic behaviour of actors. Figure 3 summarises the State/Event/Action model of the cruise actor. It should be self-explanatory.3.1 Ensuring real-timenessDifferent factors, local + global, contribute to ensuring the real-timeness of an actor system. In the small, message responses (actions) in actors must have a bounded execution time. Therefore some constructs should be avoided (e.g., recursion, loops without bounded iterations,dynamic data structures ... ). In the large, an adequate interaction policy among the various control machines must be designed which depends on the application requirements and the assumptions of the adopted communications network. For the cruise example over CAN, an interaction policy results from a priority assignment to network messages and a suitable choice of the time clauses within the schedulers. The following message priority ordering is assumed( Stop , Init , D_OkInit , M_OkInit, C_OkInit, Start , Brake ,Accelerator , Speed , Throttle , Set , Resume ).Figure 4 summarises the time clauses embodied by the different schedulers, in Java syntax. m denotes a “just sent message”. Scheduling uses time validity intervals for messages (see section 2). m.cause() denotes the message whose processing generated m . m.iTime() returns the invocation time of m . now() returns the current time.Figure 4: Scheduler time clauses.It is worth noting that the Cruise subsystem acts as a global supervisor and is strictly reactive. In addition, timing information such as p1 and p2 are fed to the scheduler actors during initialisation.4. COLOURED PETRI NETS AND VALIDATIONACTIVITIESComponents of the described actor framework (actors,subsystems, schedulers, control machines, network interfaces and protocols, ...) can be formally described by Coloured Petri Nets (CPN) (Jensen, 1992) to enable validation activities (Jensen, 1994). The aim is to build a system specification which can be executed in order to test both functional and temporal properties (Nigro and Pupo,1998). CPNs can be used in the context of Design/CPN (Jensen et al., 1996) which favours the specification of a complex system by modularising it into subnets (pages )structured hierarchically.The following shows some components of a CPN model for the cruise control example. Fig. 5 is the topmost level page in the model. It represents the more abstract view of the system and consists of the four subsystems linked to one another by CAN. Each high-level component is modelled by a substitution transition and in turn is Hierarchically Substituted (HS) in a subpage containing the specialisationdetails. The substitution operation is accomplished by a binding between sockets in the super page and corresponding ports in the subpage. Fig. 6 depicts a CAN subnet. NBufIn is a port-place linked to all the output socket-places in the various subsystems. It is used to broadcast a network message. The token-message list in NBufIn contains, at any moment, the set of sent messages ranked by priority, waiting to be transmitted by CAN. Transition CANarb models the arbitration process. The highest priority message is actually selected by CANarb only when the network is idle. Transition CANTransmodels the message broadcast and its transmission delay.Figure 5: Top level CPN model for the Cruise system.Figure 6: The CAN subnet Fig. 7 shows the Cruise subsystem subnet. It includes the control machine, the Cruise actor and the input/output interfaces to CAN.The list of the expected external messages is carried by the token in the ExpMsgs place. A CAN message is actually received by the transition FromCAN which translates and appends it to the local generated message list (place CMPIn). An output network message is transmitted by ToCAN transition which inserts it ranked into the message list of NBufIn place of the CAN net (NBufIn and ToNetP are mirroring places). The scheduler subnet applies the time clauses of the Cruise subsystem according to Fig. 4. The controller subnet implements message selection and dispatching operations of the control machine. Selection is based on the EDF strategy. The Cruise actor subnet is shown in Fig. 8. The model embodies the State/Event/Action diagram of Fig. 3. It generates CAN messages through the CAToNet place which mirrors ToNetP1 output place of Fig. 7. The time-consuming activity (action) is implemented by transition CruiseAct which is in charge of accepting an incoming message and processing it by suitable arc inscriptions (ML functions) which update the actor internal status and attributes.4.1 Temporal analysisDesign/CPN allows both informal and formal analysis methods to be applied to an achieved system model. Informal analysis can be based on model simulation (specifications testing (Ghezzi et al., 1991)), i.e., by providing an initial marking and then by tracing one or more possible resulting behaviours. By observing these behaviours the analyst can realise whether or not the specified system meets functional or temporal requirements.Formal analysis consists in defining general properties of the net model which reflect special types of desirable (or undesirable) behaviours of the specified system, and then using the specification to formally prove (or disprove) such properties. For this purpose the occurrence graph (OG) method (Jensen, 1994) can be used. An OG is a directed graph which has a node for each reachable marking and an arc for each occurring binding element. An arc links the node of the marking in which the associated binding element occurs to the node of the marking resulting from the occurrence. All standard properties like absence of dead markings, reachability and boundedness analysis ... can be checked on the OG. It is worthy of note that the OG may become very large, even for relatively small nets, that it cannot possibly be generated even with the most powerful computer. Another limitation is dependency from the initial marking: each possible initial marking may originate a different occurrence graph.Functional analysis of the Cruise system was conducted by using a simple mathematical model for the motion model (Luqi, 1995) and by tracing the causally connected messages of every thread at the Design/CPN graphical user-interface, e.g., by a step-by-step simulation.From the temporal point of view Design/CPN doesn’t provide specific analysis techniques. However, the general support for functional analysis together with a primitive time notion, ensured by a global clock, can be used toachieve a timing analysis framework for actor systems (Nigro and Pupo, 1998). Transitions can be assigned a delay. Tokens are timestamped by transition fire times. Generated tokens are frozen in the output places until the system clock gets advanced to their timestamp. At any instant the system clock is advanced to the token timestamp representing the minimum time increment in the whole CPN model. The timestamp of a token can be modified by a transition predicate or an arc inscription. This was exploited in the realisation of the control machine subnet where, in general, the selection of the next dispatch message from the Plan can require an update of the system clock to the lower bound of the message time validity interval.The frozen behaviour of generated tokens is compatible with the simulation of a distributed system. Different actors into different subsystems/processors are capable of concurrent execution. However, the simulated CPN clock is always augmented by the minimum timestamp thuspreserving its chronological advancement.Figure 7: The Cruise subsystem subnet.Figure 8: The Cruise actor subnet.Besides querying the OG for standard properties, specific ML functions can be introduced for checking non standard properties. One such a function can capture the verification of a temporal property in positive ornegative form, e.g., one like the following: “is it always true that for each instance of a given transition firing (representing, e.g., the beginning of a thread) there always (as the OG state space allows) exists an instance of the corresponding transition firing (modelling, e.g., the end of the thread) such that the time distance between them is less than a fixed time interval (e.g., deadline of thread execution) ?” The negative form of a property can be more immediate. In this case the existence of a single occurrence of a searched event that contradicts the property is sufficient to assert that the property doesn't hold.For the temporal analysis of the Cruise system, the actor transitions were annotated by an estimation of worst-case-action-execution-times, which were 40 msec for the Motion, 0.4 msec for the Cruise and 10 msec for the Driver. The system was then studied by generating its OG for a simulation period where significant activity occurs, e.g., by ensuring that when cruising is enabled multiple and conflicting threads are interleaved.Fig. 9 exemplifies an ML check function that verifies the deadline of cruising under automatic control. For simplicity, the transmission of message data is disabled, thus focusing on temporal aspects only. Similar functions can be written for checking the deadline of a Brake or Stop message.fun CruiseDeadln(): Arc list =PredAllArcs(fn a =>if ((ArcToTI(a) = TI.MotionActor'MotionAct 1)andalso(StripTime(Mark.MotionActor'PSNet 1 (DestNode(a))) =((1,(Speed,0.0))!!empty))) thennull(PredArcs( EntireGraph, fn b =>if ArcToBE(b) = Bind.MotionActor'MotionAct(1,{msg=Throttle,slope=0.0,speed=0.0,throttle=0.0,value=0.0})then ((OccurrenceTime(b)-OccurrenceTime(a))<100.0)andalso (DestNode(b)>DestNode(a))else false, 1))else false)Figure 9: Cruise control deadline checking function. CruiseDeadln() tries to build a list with instances of the MotionAct transition of Motion actor corresponding to the generation of a Speed message (beginning of thread) which are followed by a causally connected instance of the MotionAct transition corresponding to a Throttle processing (termination of the thread) which doesn’t fulfil the deadline. The function always returns an empty list, thus the property is satisfied.The CPN model supports incremental development according to a spiral system life cycle (Verber et al., 1997). As the temporal information (message processing times) become more precise, i.e., the project is tuned to the target physical architecture, system timeliness can be re-checked and requirements possibly adjusted to ensure guaranteed schedulability. The key point is that the CPN model closely mirrors the design and implementation models. Conclusions drawn from the analysis model can directly be interpreted at the more low level stages of development.6. CONCLUSIONSThis paper describes a computational model based on actors which makes it possible to develop distributed real-time systems. The model favours time-predictability and relies on non-preemptive light-weight concurrency.A distributed system can be formalised by Coloured Petri Nets (CPNs) in order to support functional and temporal validation activities. Ensuring predictability at the system-level strongly depends on the adopted communications network.Directions of current work cover an application of the actor framework and CPN modelling to challenging distributed measurement (Grimaldi et al., 1998) and multimedia systems (Fortino et al., 1998) over Internet.ACKNOWLEDGEMENTWork carried out under the financial support of the Ministero dell'Università e della Ricerca Scientifica e Tecnologica (MURST) in the framework of the Project "Methodologies and Tools of High Performance Systems for Distributed Applications".REFERENCESAgha, G. (1986). Actors: A model for concurrent computation in distributed systems, MIT Press.Bergmans, L. and M. Aksit (1996). Composing synchronisation and real-time constraints. J. of Parallel and Distributed Computing, September.Grimaldi, D., L. Nigro, and F. Pupo (1998). Java based distributed measurement systems. To appear on IEEE Trans. on Instrumentation and Measurement.Fortino G. and L. Nigro (1998). QoS centred Java and actor based framework for real/virtual teleconferences. Proc. of SCS EuroMedia98, Leicester (UK), pp. 129-133.Jensen, K. (1992). Coloured Petri Nets - Basic concepts, analysis methods and practical use. Vol. 1: Basic concepts. EATCS Monographs on Theoretical Computer Science. Springer-Verlag.Jensen, K. (1994). Coloured Petri Nets - Basic concepts, analysis methods and practical use. Vol. 2: Analysis methods. EATCS Monographs on Theoretical Computer Science. Springer-Verlag.Jensen, K., S. Christensen, P. Huber and M. Holla. (1996). Design/CPN. A reference manual. Computer Science Department, University of Aarhus. Online: http://www.daimi.aau.dk/designCPN/.Kirk, B. (1995). Real time protocol design for Control Area Networks. Proc. of Real Time Systems’95, pp. 251-268. Kirk, B., L. Nigro and F. Pupo (1997). Using real time constraints for modularisation. Proc. of Joint Modular Languages Conference, Springer-Verlag, LNCS 1204, pp. 236-251.Luqi (1993). Real-time constraints in a rapid prototyping language. Computer Languages, 18(2), pp.77-103.Nigro, L. and F. Pupo (1997). A modular approach to real time programming using actors and Java. Proc. of 22nd IFAC/IFIP Workshop on Real Time Programming, Lyon, 15-17 September, pp. 83-88.Nigro, L. and F. Pupo (1998). Using Design/CPN for the schedulability analysis of actor systems with timing constraints. Proc. of Workshop and Tutorial on Practical use of Coloured Petri Nets and Design/CPN, University of Aarhus, Aarhus Denmark, 8-12 June.Nigro L. and F. Tisato (1996). Timing as a programming in-the-large issue. Microprocessors and Microsystems, 20(4), pp. 211-223.Ren, S., G. Agha and M. Saito (1996). A modular approach for programming distributed real-time systems. J. of Parallel and Distributed Computing, Special issue on Object-Oriented Real-Time Systems.Tindell K., A. Burns and A.J. Wellings (1995). Analysis of hard real-time communications. Real-Time Systems, 9(2), pp.147-171, September.Verber D., M. Colnaric, A.H. Frigeri and W.A. Halang (1997). Object orientation in the real-time system lifecycle. Proc. of 22nd IFAC/IFIP Workshop on Real Time Programming, Lyon, 15-17 Sept. 1997, pp. 77-82.。