Design Considerations for Distributed Real-Time DEVS

Design Considerations for Distributed Real-Time DEVS1

Young K. Cho Bernard P. Zeigler Hyup J. Cho Hessam S. Sarjoughian

Suvrajeet Sen System & Industrial Engineering Department University of Arizona, Tucson, AZ 85721-0104 Email: [email protected]

Arizona Center for Integrative Modeling & Simulation Electrical & Computer Engineering Department University of Arizona, Tucson, AZ 85721-0104 Email: {ykcho|zeigler|hjcho|hessam}@ece.arizona.edu URL: http://www.acims.arizona.edu ABSTRACT This paper concerns the development of the DEVS methodology in real time, distributed form. The research aims to develop a framework in which distributed realtime systems can be designed through DEVS-based modeling and simulation, and then migrated with minimal additional effort to be executed in real-time distributed environments. We target application of such a framework to design of embedded systems based on event-based control. Here we review previous developments in DEVS methodology and recent developments in real time, distributed system middleware and outline some extensions needed to realize the real-time, distributed DEVS framework. KEYWORDS: DEVS, real-time systems, distributed systems, CORBA, middleware

1

INTRODUCTION

Real-time systems design connotes an approach to software design in which timeliness is as important as the correctness of the outputs [17][18]. Timeliness of response does not necessarily imply speed -- although, this may be important -- as much as predictability of response and reliable conformance to deadlines. Realtime systems usually have periodic tasks, such as monitoring of processes. They must accept input events that come from the external real world (through sensors) and respond with outputs such as commands sent to real world actuators. Often real-time considerations must be made for embedded systems, in which control is exerted though software modules built into, and distributed 1

throughout, operational systems such as aircraft, nuclear reactors, chemical power plants and automated houses. Performance estimation and design to meet performance requirements are crucial in real-time systems. Performance analysis often concerns schedulability, checking of the task schedule for feasibility or conformance with the required timing constraints. In distributed networked systems, quality of service (QoS) characteristics of the network, such as the timely delivery of events between system components, must necessarily be included in performance evaluation. 1.1

Linking Real-time Execution to Simulation

Real-time considerations enter into the world of modeling and simulation in various ways. A real-time simulation is a real-time system where some portion of the environment or portions of the real-time system itself, are realized by simulation models [10]. When a simulation model interacts with a surrounding environment, such as software modules, hardware components or human operators, the simulator must handle external events from its environment in a timely manner [2]. More generally, interfacing of abstract models with real world processes requires that the logical time base of the simulation be synchronized as closely as possible to the clock time of the underlying computer system [8]. Work related to realtime simulation and control includes early research in DEVS-Scheme [8], the extension of the Discrete Event System Specification (DEVS) formalism to the DEVS Real-time Formalism [2] and its application to process control [9]. Current projects include PORTS: A Parallel, Optimistic, Real-Time Simulation [10], OPERA (Operators Training Distributed Real-Time Simulation)

This research is partially supported by NSF Grant EIA-9975050 SPEED-CS.

[11] and Ptolemy (Concurrent Discrete Event Simulation) [14][15]. In this paper we discuss the development of Distributed Real-Time DEVS as an extension of previous DEVS research related to real-time simulation [2][8][9]. The major objective in developing Distributed RTDEVS is to establish a framework in which the distributed real-time systems can be designed through DEVS-based modeling and simulation, and then migrated with minimal additional effort to be executed in real-time distributed environments, a design methodology suggested in [3] and reviewed in [4]. The target application area is that of embedded system design based on event-based control [4].

2

Layered Design Approach

To address real-time design issues in the context of embedded system, event-based control we adopt a layered approach to software design in which there is a separation of concerns underlying the layers. The network, or lowest layer in Figure 1, represents the actual physical hardware, computers, cables, routers, etc. The second, or real-time middleware layer, refers to newly emerging software that provides services to mediate the communication among nodes in the network with some degree of assured performance levels [5]. For example, the middleware might be configured to assure a tolerably small degree of jitter (while not necessarily reducing the average latency to zero), thus supporting good event-based control. Finally, the event-based control layer provides the constructs needed to design and implement event-based control as discussed above. Note that without this separation of concerns, one has much greater difficulty in layering makes it possible to reuse the software developed at the layers , or indeed to purchase off-the-shelf software if that is available. 2.1

Security Service, Trader Service, Query Service, Licensing Service, Properties Service, Time Synchronization Service, Collection Management Service, and Startup Service. Ability to operate in real trying to formulate and disentangle the control and network response issues just mentioned. Moreover, the time imposes additional stringent requirements on services that are not part of the CORBA standard. Operating in real time implies not necessarily speed, but consistency or predictability, of response, as measured for example, by small jitter. Real-time object-oriented middleware attempts to provide parameterized objects that can be composed to provide quality of service guarantees to application layer software. The ACE/TAO extension of CORBA is being developed to demonstrate the feasibility of using CORBA for real-time applications versus direct socket level programming [5][16].

Real-Time Middleware

Middleware is software that simplifies the use of network technology in applications. Middleware provides services such as for sending message packets from one node to another that would otherwise have to be programmed from scratch, e.g., at the socket level. CORBA (Common Object Request Broker Architecture) is an open standard for middleware promulgated by the Object Management Group (OMG), a consortium of over 700 companies [6]. CORBA is rapidly gaining acceptance in the market place with vendors providing maturing products to support it. A wide and extensive variety of services are defined in CORBA 2.0 including: Lifecycle Service, Naming Service, Event Service, Persistent Object Service, Concurrency Control Service, Transaction Service,

Event-Based Control

Real Time Middleware Network

Figure 1 Layers in distributed event-based control

2.2

DEVS-Based System Design

The principles of separation of concern and reuse suggest further extending the layered architecture as illustrated in Figure 2. Here we stratify event-based control (as depicted in Figure 1) into 3 layers: – 1) event-based control per se, 2) the DEVS modeling formalism in which event-based control can be specified and implemented, and 3) the environment in which DEVS models can be simulated and executed in real time.

3

Review of DEVS/CORBA

The Distributed RTDEVS environment is being developed as an extension of the DEVS/CORBA simulation environment [7]. We therefore review the design of DEVS/CORBA as a basis for consideration of the extension to real-time capability.

The DEVS formalism focuses on the changes of variable values – discrete events – and generates time segments that are piecewise constant. In essence the formalism defines how to generate events and their times of occurrence. DEVS has a well-defined concept of system modularity and component coupling to form composite models. It enjoys the property of closure under coupling which justifies treating coupled models as components and enables hierarchical model composition constructs. In the DEVS formalism one must specify 1) basic models from which larger ones are built, and 2) how these models are connected together in hierarchical fashion. There are two major classes in object-oriented implementations of DEVS from which all user-defined models can be developed − atomic and coupled. The atomic class realizes the basic level of the DEVS formalism, while the coupled model embodies DEVS hierarchical model composition constructs.

• •

Basic models may be coupled in the DEVS formalism to form a coupled model. A coupled model, tells how to couple (connect) several component models together to form a new model. A coupled model template captures the following information: • • • •

Event-Based Control

The next state is computed on the basis of the present state, the input port and value of the external event, and the time that has elapsed in the current state. the confluent transition function which specifies how the system changes state when an input is received at the same time that an internal event is scheduled. the output function which generates an external output just before an internal transition takes place.

the set of its components the set of input ports through which external events are received the set of output ports through which external events are sent the coupling specification consisting of:


DEVS




Simulation/Execution

Real Time Middleware




Network

Figure 2 Further layer refinement

A basic model information: • • • • • •

template

captures

the

following

the set of input ports through which external events are received the set of output ports through which external events are sent the set of state variables and parameters the time advance function which controls the timing of internal transitions the internal transition function which specifies to which next state the system will transit after the time given by the time advance function has elapsed the external transition function which specifies how the system changes state when an input is received.

the external input coupling connects the input ports of the coupled model to one or more of the input ports of the components the external output coupling connects the output ports of the components to one or more of the output ports of the coupled model internal coupling connects output ports of components to input ports of other components

A coupled model can be expressed as an equivalent basic model in the DEVS formalism. This follows from the fact that the formalism is closed under coupling. (Expressing a coupled model as an equivalent basic model captures the means by which the components interact to yield the overall behavior.) Such a basic model can itself be employed in a larger coupled model as required for hierarchical model construction. Closure under coupling implies that when networking DEVS components, one CORBA interface will suffice for all model classes, namely that for basic model components. Execution of a coupled DEVS model is mediated by coordinator and simulator servers (Figure 3). The coordinator server is assigned the coupled model with the premise that simulator servers for its model’s components have already been established and registered with the CORBA naming service. To find the appropriate servers for the components specified by its coupled model, the coordinator employs the CORBA naming server. Then to reduce the potential bottleneck at the coordinator, the coupling information available to the coordinator is downloaded and distributed to each simulator server. This

allows simulators to exchange messages bearing inputs and outputs without mediation by the coordinator. Each simulator server keeps track of the time-of-last-event, tL and time-of-next-event, tN of its assigned DEVS component. Using the parallel DEVS simulation protocol, execution proceeds through iteration of a basic cycle (Figure 4) as controlled by the coordinator server. The interaction between coordinator and simulators can be implemented in CORBA by suitable interface definitions and implementations. The interface that a simulator presents to a coordinator can be expressed in an IDL definition. For example, a simulator can be told to start up (by invoking its component’s initialize method). It can respond to a request for the time-of-next-event of its component (by querying for its component’s timeAdvance). It can receive a global time-of-next-event, determine if its component is imminent, and if so, return its component’s output (otherwise returning null). Finally, it can be sent its component’s input and told to determine and apply the appropriate version of its component’s transition function (or none). The coordinator issues these method invocations in the correct order to implement an iteration of the simulation cycle.

data messages

Simulator

Simulator

(ModelServer)

Genr

Simulator

(ModelServer) in

Proc

out

out

Coord (GPT)

start Start Objects - Initialize ORB - Register to CORBA Name Server

start

start

start

findObject() Initialize each model - Locate simulators - Download coupling information to each simulator

informCoupling() initializeDevsTime() SimulationCycle()

Simulation Cycle - ComputeInputOutput - WrapDeltFunc() - nextTN()

DEVS Cycle

Figure 4 Sequential Representation of Simulation Cycle inDevs/Corba

-

Coordinator must ensure that messages exchanges among basic models are delivered in real-time (i.e., delivery within deadline) no matter where the models are located on the network. Coordinator must also be able to schedule high priority threads first.

-

Components in RTDEVS/CORBA will be running asynchronously. Coordinator no longer keeps synchronization between all components. Coordinator helps each component model to initialize. After initialization, it will keep its role as interface with the external environment.

-

Time service guarantees that consistent readings of a global clock no matter where the reading is done in a distributed system. The simulators must use such a time service to stay in synchronization with each other.

-

Each model component will be running on a separate thread and will go through its own DEVS Cycle interacting along with other model components. Atomic model can perform two kinds of scheduling, one is for periodic event processing and the other is reactive. For periodic event processing, the model will arrange its own schedule set for the event. For reactive event processing, the model will try to process the event within the deadline. Therefore, this must be scheduled according to the deadline of the event.

-

Handling of confluent inputs (multiple event arriving at the same model at the same time) may be problematic. In the Parallel DEVS Protocol,

(ModelServer) ariv

ModelServer1 ModelServer2 ModelServer3 (Genr) (Proc) (Transd)

Transd

solved

Network Control messages

CORBA Name Server

Coord

Devs/Corba Interfaces

GPT

DEVS models

Coordinator

Figure 3 Devs/Corba Client/Server Model

4

Modifying DEVS/CORBA to implement RTDEVS/CORBA

Design considerations for extending DEVS/CORBA to support real-time in the RTDEVS/CORBA environment (Figure 5), include: -

Simulator must execute the associated atomic model in real-time. This model usually handles two kinds of events: one is a periodic event and the other is a reactive event. The simulator must be able to schedule and process these events in real-time.

the model must process all simultaneously arriving events as a collection (bag). Network latency and jitter may make it difficult to know when all messages for a given time have been received.

Coord (GPT)

ModelServer1 (Genr)

ModelServer2 ModelServer3 (Transd) (Proc)

start Start Objects - Initialize ORB - Register to Corba Name Server

start

start

start

findObject() Initialize each model - Locate simulators - Download coupling information to each simulator

informCoupling() InitializeTimeWithSystemClock() execute()

Execution Cycle - ComputeInputOutput - WrapDeltFunc() - nextTN()

loop

loop

loop

Figure 5 Sequential Representation of Real-Time execution (RTDEVS/CORBA)

5

CONCLUSIONS

This paper has outlined some of the considerations needed to extend the DEVS/CORBA modeling and simulation environment to operate in real time (RTDEVS/CORBA). To support the design methodology for real-time embedded systems based on event-based control, the environment must be further extended to support the development and implementation of event-based control models expressed in the DEVS formalism. A challenging issue for research is the mapping of real-time constraints imposed by application requirements into suitable settings for the underlying real-time CORBA middleware.

REFERENCES [1] S. Pinker, How the mind works, W.W. Norton, New York, NY, 1997. [2] J.S. Hong, and T.G. Kim, “Real-time Discrete Event System Specification Formalism for Seamless Realtime Software Development,” Discrete Event Dynamic Systems: Theory and Applications, vol 7, pp. 355-375, 1997. [3] B.P. Zeigler, T.G. Kim, and H. Praehofer, “DEVS Framework for Modelling, Simulation, Analysis, and Design of Hybrid Systems,” in Hybrid II, Lecture

Notes in CS, P. Antsaklis and A. Nerode, Editors. Springer-Verlag, Berlin, pp. 529-551, 1996. [4] B.P. Zeigler, T.G. Kim, and H. Praehofer, Theory of Modeling and Simulation. 2 ed., Academic Press, New York, NY, 2000. [5] T.H. Harrison, et al., “The Design and Performance of a Real-time CORBA Event Service,” IEEE J. on Selected Areas in Communications, 1999. [6] R. Orfali and D. Harkey, Client/Server Programming with Java and CORBA. : Wiley Computer Publishing, New York, NY, 1997. [7] D. Kim, S.J. Buckley, and B.P. Zeigler. “Distributed Supply Chain Simulation in a DEVS/CORBA Execution Environment,” in WSC. 1999, Phoenix. [8] B. P. Zeigler and J. Kim, “Extending the DEVSScheme Knowledge-Based Simulation Environment for Real-Time Event-Based Control,” IEEE Trans. On Robotics and Automation, vol. 9, no. 3, pp. 351356, June 1993. [9] S. M. Cho and T. G. Kim, “Real-Time DEVS Simulation: Concurrent, Time-Selective Execution of Combined RT-DEVS Model and Interactive Environment,” SCSC'98, pp. 410-415, Reno, Nevada, 1998. [10] K. Ghosh, et al., “PORTS: A Parallel, Optimistic, Real-Time Simulator,” 1994 Workshop on Parallel and Distributed Simulation, pp.24-31, July 1994. [11] T. Uslander, “OPERA: A CORBA-based Architecture Enabling Distributed Real-Time Simulation,” Proceedings of ISORC’99, May 1999. [12] D. C. Schmidt, et al., “The Design of the TAO RealTime Object Request Broker,” Computer Communications, Elsivier Science, vol. 21, no. 4, April 1998. [13] A. Kanevsky, et al., “Real-Time Extensions to the Message-Passing Interface (MPI),” January 1997. [14] E. A. Lee, “Modeling Concurrent Real-Time Processes using Discrete Events,” UCB/ERL Memorandum M98/7, March 1998. [15] S. A. Edwards, “The Specification and Execution of Heterogeneous Synchronous Reactive Systems,” Ph.D. Thesis, University of California, Berkeley, May 1997. (http://ptolemy.eecs.berkeley.edu/papers/97/sedwards Thesis/) [16] C. O’Ryan, et al., “Applying a Scalabe CORBA Events Service to Large-scale Distributed Interactive Simulation,” Proceedings of the 5th Workshop on Object-oriented Real-Time Dependable Systems, Montery, CA, November 1999. [17] Phillip A. Laplante, Real-time systems: Design and Analysis, 2nd Ed. IEEE Press, Piscataway, NJ, 1997. [18] C.M. Krishna and K.G. Shin, Real-time systems, McGraw-Hill, New York, 1997.