a.-B k!iJ
Jsov~W&/l~ OF ARCHITECTURE
ELSEVIER
Journal of Systems
Architecture
42 (I 996) 477-487
HyperReal: A modular control architecture for HRT systems ’ Flavio De Paoli *, Francesco Tisato, Carlo Bellettini Dipudmenro
di Scienre dell’lnformazione,
Uniuersitir
degli Srudi di Milano,
Via
Comelico
39,
20135
Miho,
Italy
Abstract This paper describes the basic ideas of the HyperReal project. It is centered on the definition of architectural abstractions to design modular RT systems. Basic components are reactive agents manipulating data and connectors supporting interactions among agents. Such components are not aware of control strategies, which are managed by a controller. The controller relies on a time-driven model of control, and separates planning and dispatching of actions. Plans are associated with virtual clocks that support the explicit management of time. The architectural abstractions allow designers to fully control the temporal behavior of the system and to reuse components to fit different application-oriented control models. Keywords:
Real-time;
Objects;
Planning;
Embedded
systems
1. Introduction The HyperReal (HR) project is centered on the definition of architectural abstractions [l] which
permit designing, analyzing and implementing complex systemsby addressing modulari@, conjiguration, and control issuesthat are not addressedin an
I Corresponding author. Email:
[email protected] ’ The paper is based on a previous work that appeared in the Proceedings of the 7th Euromicro Workshop on Real-Time Systems, Odense, Denmark, June 14-16, 1995. The work is partially supported by Esprit Projects n.20.592 (OMI/MODES), and x20.575 (OMI/CORE). 1383-7621/0165-6074/96/$15.00 PII Sl383-7621(96)00035-5
Copyright
0 1996 Elsevier
integrated way by conventional languagesand platforms. Though the HyperReal approachis expected to be of use in different application areas, the project focuses primarily on embeddedand Hard-Real-Time (HRT) systems, for both conceptual and practical reasons.First, these systemsstressissuesrelated to control, timing, communication and configuration. Second, they provide market opportunities for lightweight platforms that support the development of embedded applications without relying on standard operating systems. For these application areas, the classical separation between application software and operating systems vanishes,becausefeatures that are usually dealt
Science B.V. All rights reserved.
478
F. Dr Paoli et ul./Journal
of Systems Architecture
with by the operating system become a major concern of an application. We like to stress that the aim of the HyperReal project is not to devise new approaches, but it is to integrate, as much as possible, well-known approaches from different areas into a coherent architectural framework based on a complete set of elementary abstractions. The set of architectural abstractions is defined following three guidelines: Separation of concerns, which means that each abstraction deals with a specific issue only; Completeness, which means that the set of the abstractions provides everything that is needed to design, analyze and implement a real system; Minimality, which means that the basic abstractions are as few and as simple as possible, both for concepts and implementation. Separation of concerns is addressed by identifying a set of system components, each focusing on specific issues: controllers, agents, connectors, and configurators. Controllers are in charge of managing the execution of the system activities by defining plans and by dispatching commands to other components according to the time-line defined by virtual clocks. Reactive agents encapsulate data and operations implemented as atomic actions triggered by commands. Connectors provide abstract communication channels among agents. Agents and connectors are not aware of why and when they execute their actions, nor they explicitly control the actions of other components; these tasks are in charge to controllers. Agents and connectors are not even aware of the existence of other components; they interact with the environment through an interface consisting of ports characterized by protocols. With the term environment we mean anything outside a component (i.e., other components). Finally, configurators are in charge of managing the system topology by creating components and by establishing bindings among them.
Completeness is addressed by representing through suitable abstractions,visible at the programming level, all the concepts that are neededto define
42 11996) 477-487
a system, and its behavior. In particular, scheduling policies and time management, which are usually hidden inside the kernel or inside the language runtime support, get full visibility at the application level. Minimality is addressedby choosing a time-driven control model as primitive and by building other control models(e.g., concurrent and event-driven) on top of it. The time-driven model has been chosenas primitive since HyperReal is focused on RT and HRT systems. The rest of the paper presentsthe control model adopted in HyperReal (Section 2); the definition of agents, connectors and controllers (Section 3); issues about system configuration (Section 4). Section 5 relates HyperReal to the state of the art and summarizes project status and future work.
2. The control model Traditional programs implement algorithms as sequencesof statementsthat specify the logical flow of control. The presenceof I/O statementschangesthe actual execution of programs, since they require to synchronize with the environment that reacts with unpredictable delay. Hence, the actual flow of control is usually managedby the kernel of the operating system according to some hidden policy. As a consequence,programmerscannot have a fully deterministic control on the execution of their programs. Such an approach is suitable to both sequential and concurrent programming, but it is not appropriate for real-time programming, where the capability of controlling and monitoring the systemevolution is mandatory. Some systems adopt the solution of adding primitives to influence the kernel policies. Such an approach is unsuitable becauseit moves the problem from controlling the execution of a program, to controlling the execution of the whole operating system. The presenceof system-dependent
F. De Paoii
et ul./
Journal
of Sy.stem.s
time-sharing mechanisms increases the complexity, reduces the portability and interdicts formal verification. In particular, it makes the approach unsuitable for embedded applications. The HR approach considers a program as a set of reactive components and a controller, which is also part of the program. The model assumes components that export operations to be executed on request. To control their execution, the controller may adopt either an event-driven approach or a time-driven approach. An event-driven model assumes that the controller reacts to events, generated either by the environment or by system components, by issuing commands to components us soon us possible. A time-driven approach assumes that the commands are scheduled in a timeline and that the controller issues them to components at the right time [2]. The event-driven model is suitable to programming reactive systems, while the time-driven model is suitable to programming deterministic systems. Since real-time systems need both reacting to external stimuli and scheduling activities in advance, any effective model must accommodate both situations. This could be accomplished by adopting either the event-driven model or the time-driven model as the primitive model, and building the complementary model on top of it. In the former case the presence of a scheduled command signals an event. In the latter an event schedules a command [3,4]. In HyperReal, a time-driven model has been adopted to design and implement the controllers, because it is more suitable and natural for real-time systems. To model the concept of time the virtual clock abstraction is introduced. A virtual clock defines a virtual time, i.e., a monotonic set of integer values. The rute of a virtual clock defines the number of virtual time units for each unit of the “real” reference time. A rate of 1 states that a virtual clock advances at the same speed as the reference “real” clock. There may be several virtual clocks in a system. A virtual clock can be controlled by a set of primitives:
Architecture
42 (19961477-487
479
setRate: sets the clock rate; restart: sets to zero the current time of the clock and starts it; stop: suspends the advancement of the clock; resume: starts the clock from its current time; getTime: returns the current time of the clock. The behavior of a system is defined by plans that are defined as collections of actions associated with a validity interval: (action, [after, before]). The validity interval states that an action has to be started not before the lower bound of its interval, and has to be completed not later than the upper bound. An action holds the information about the command that has to be issued, and other information for scheduling such as precedence constraints, worst case execution time and criticality. A plan is associated with a virtual clock on which the validity intervals of the actions are defined. Control actions can be included in a plan to control the controller itself. For example, the restarting of a clock can be inserted as an action in a plan. Within a plan two kinds of actions can be scheduled: persistent actions and transient actions. Transient actions are removed from the plan after their completion. Conversely, persistent actions are left on the plan, but marked as served. Persistent actions support the planning of periodic tasks: to reschedule a plan, it suffices restarting the associated clock at the end of a period and marking as unserved all the actions belonging to the plan. Transient actions support asynchronous events handling: an asynchronous event causes an “on the fly” planning of actions that become indistinguishable from the already scheduled.
3. Components It is widely accepted that the definition of autonomous computing modules is the right approach to design effective software systems. There is a
480
F. De Pnoli
et d/Journal
of Systems Architecture
variety of examples of languages and systems supporting such an approach: for example, Objects and Actors [5]. In HyperReal, apart from the controller components, there are two kinds of components: agents and connectors. Agents are computing modules similar to those defined in any object-based model, while connectors define a new class of components to support the communication among agents [6,7]. Components are interfaced with each other and with the environment by means of ports. Both agentsand connectors are identified by a global name. In this section we sketch the definition of ports, agents, connectors and controllers. For more details the reader can refer to 181. 3.1. Components
inter&ace:
Ports
The interface of a component consists of one or more porrs. A port is a structure defining a collection of pins, and a prorocol. There are two major classes of pins: data pins carrying on data and control pins carrying on control signals. Data pins allow a component to exchange data with other components. There are input data pins and output data pins supporting read and write operations, respectively. Each pin is characterized by a type that defines the kind of data it can carry on. Operations on data pins do not imply either synchronization or control passing. The controller is in charge of giving the control, according to synchronization constraints, to the componentsthat perform read and write operations. Control pins are split in two classes:input conrrol pins, used by the environment to trigger the execution of an operation of a component, and outpur control pins, usedby a component to notify an event to the environment. The protocol defines the legal sequenceof actions to be performed on pins. For instance, a port of a simple client in a client-server systemmay consist of
42 (1996) 477-487
an output data pin for issuing commands, an input data pin for receiving results, an output control pin through which the client notifies the environment that a command has been sent, and an input control pin through which the environment notifies the client about the arrival of a result. The protocol should state that sending commands and receiving results are executed in a loop, that sending a data through the output data pin should be followed by a signal through the output control pin, and that a command through the input control pin should be followed by a data input through the input data pin. A protocol could be specified in different ways. For example, in a declarative way by meansof preand post-conditions associated with actions, as in Eiffel 193,or by means of a finite-state automaton that defines the right sequenceof actions to interact with a communication channel, according to common techniques for specifying network protocols [lO,lll. The formal definition of ports as a collection of typed pins and protocols has the double advantage of both supporting the composition of componentswith a clean and easy-to-use mechanism, and addressing the problem of formal verification of properties. 3.2. Computing
agents
An agent is a component defining, in a local name space, a set of data and operations, and interacting with the environment through a set of ports. Local data and operations can be defined by classicalconstructs for sequential programming extended by operations on ports. An agent is a reactive component, i.e., it may have its own thread of control, but its operations are executed only on requestsgeneratedby the environment. An agent is not aware of the other components and of the control policy adopted by the system. It can only sendand receive control signalsthrough the control pins, and exchange data through the data
F. De Paoli et al./Journal
@‘Systems Architecture
pins, but it cannot understand who its counterparts are. The mapping from input control pins to operations is called the agent behavior. Simplest agents define their behavior statically by associating each operation with an input control pin. More complex agents may exhibit dynamic behaviors. In this case, an agent behavior can be modeled as a finite state automaton whose states correspond to different pinoperation mappings [ 121. Operations are atomic. It means that only one operation at a time can be active, and that an operation cannot be pre-emptied to execute another operation of the same agent (note that this does not imply that an agent cannot be pre-emptied by the environment). No suspensiue primitives are allowed inside an operation: an agent suspends itself only by completing an operation. Suspensive primitives are avoided mainly because they would change the object behavior (i.e., how it will react to external stimuli) without showing it outside (i.e., to the controller). Suspensive mechanisms can be simulated by splitting a sequential procedure including suspensive operations into
signalOnData!
42 11996) 477-487
481
several atomic actions. This solution has the double advantage of keeping the control outside actors and of simplifying the implementation of the run-time support for agents, which does not require a context-switch mechanism. 3.3. Connectors Connectors are the logical channels exploited by agents to exchange data. They define the communication protocols that agents are requested to conform. The connector theory should fulfil some requirements of expressiveness and analytic capability [6]. The abstraction we propose can accommodate common cases of architectural interaction, such as procedure call, pipe, event broadcast, and shared variables, as well as complex dynamic interactions. Through the definition of protocols, the theory supports a fine-grained definition of the connector behavior. A connector corresponds to a layer in the ISO/OSI reference model. The ports of the connector correspond to Service Access Points, and the interaction between connectors and agents models
Legend:
@TV)
Fig. 1. A client-server system.
Port A
Data pin
A
Control
pin
482
F. De Puoli
et al./
Journal
of Systems
the services provided by the layer, which are independent from the underlying communication subsystem. According to the ISO/OSI model a connector is an inherently distributed component composed of several peer enfiries, one for each node it connects. For example, Fig. 1 illustrates an example of a client-server system, where the ports of the Client and the Server are plugged into the corresponding ports of a connector. The Client-server connection is specified by a connector that defines two ports: a client-side port PortC and a server-side port PorfS. PortC defines an input data pin (request), an output data pin (answer), two input control pins (getData and putData), an output control pin (dataAvailable), and a protocol stating that the right sequenceis
1. 2. 3. 4. 5.
receive a command on the pin getData; get data from the pin request; receive a command on the pin putData; put a result into the pin answer; signal the environment by the pin dataAvailable.
Architecture
42 (1996)
477-487
PortS defines the same set of pins as the Client port, and a protocol stating that the right sequenceof actions is
1. 2. 3. 4. 5.
receive a command on the pin putData; put a result into the pin request; signal the environment by the pin dataAvailable; receive a command on the pin getData; get data from the pin answer.
In other terms, the protocols state that the client sendsa request first, and that server handles a request and returns a result, as expected. The structure of an entity is similar to the one of an agent, with two major differences. First, it is a private sub-componentof a connector, i.e., it is not visible outside the connector as an autonomouscomponent identified by a global name. Second, it communicateswith the peer entities of the sameconnector through messagepassingprimitives provided by the underlying communication subsystem. The ex-
Legend: @xv)
Fig. 2. The scheme of an HyperReal
Port A Data pin A Control pin
controller.
F. De Paoli et ul./Jourml
oj’System.s Architecture
ample assumes an underlying transport layer that provides send and receive primitives, and that signals at the receiving site on messagearrival (this is modeled by the output control pin signalOnData, that is associatedwith the connector). 3.4. Controllers
The controller component is in charge of scheduling actions, and of controlling their execution as components’ operations; These tasks are accomplished by two sub-components:the planner and the dispatcher. The interface of the controller is composed of input control pins and data pins to let the planner monitor signals and system status, and output control pins to let the dispatcher issue the commandsto the components.Fig. 2 sketchesthe overall architecture of the controller. The dispatcher sub-componentnotifies the planner about idle processorsby the free function and receives a valid action by the dispatch function. The dispatcher makesan executed in two steps:it signals the out control pin mentioned in the action, and then gives the control to the signaled actor (e.g., in a multithread environment resume the thread of the actor). The planner sub-component is customizable by defining a logical planner and a scheduler. The logical planner specifies what the system is expected to do, i.e., its logical behavior and the temporal constraints it must satisfy. This is done by defining plans either statically or dynamically (as consequenceof events), and by controlling the rates of the virtual clocks. The scheduler defines how to achieve the correct application behavior, i.e., it must find a feasible schedule (called current plan). The scheduler’s inputs are the plans defined by the logical planner and the knowledge of the hardware architecture of the system (e.g., the number of available processorin a multiprocessor system, and the mapping of components to nodes in a distributed environment).
42 (1996)
477-487
483
A simple way of programming the logical planner is to define at initialization time a set of plans that represents cyclic tasks and a set of templates of plans, i.e., of static definitions of the reactions to internal and external events. When an event occurs, the logical planner instantiatesthe actions of a template by recalculating their time bounds, and inserts them into an existing plan. Another possibility is to monitor the state of the system via input data pins and, when an event arrives, to acquire information useful for taking planning decisions.If the system is fully deterministic, i.e., there is no need to react to events, the logical planner could be an off-line component that defines a static set of plans. The scheduler allows the programmer to define the scheduling policy. The implemented policy can range from a pure, non-deterministic choice among the valid dispatchableactions (that is, actions with a validity interval including the current time of the associatedvirtual clock), to a more complex policy that implements robust strategiesbased on guarantee, rejection and recovery policies [13]. In the former case, the assumption is that the logical planner is able to define plans so that the possibly remaining conflicts are not critical for the correct execution of a system. In this case, the scheduler does not need to perform any scheduling analysis, thus the current plan may include only the next action to be executed. In the latter case, the scheduler needsto hold in the current plan the actions whose execution can be guaranteed to meet the timing constraints. When a free signal arrives, if the scheduler recognizes that the action completed earlier than expected, it may consider the feasibility of resubmitting some previous discarded actions to the guaranteepolicy actuator. In this way it is possible to deal with high variance in action execution time, or highly pessimistic estimate of the worst caseexecution time. Consider the example presented in Fig. 1. For easinessof description, we deal with a logical planner programmed by meansof the definition of tem-
484
F. De Pnoli et ul./Journal
c?f‘Systrms Architecture
plates, and with a scheduler that applies a non deterministic choice among the valid actions. In this case the actions can be characterized only by a validity interval and a pair (component ident@er, control pin), where control pin is a pin belonging to a port exported by the component. According to the protocol discussed in Section 3.3, a correct behavior for this system could be defined in different ways. A possible solution is to define the behavior of the system by means of one template:
T=
((Client, Portstart, [1,2]), (Connector, PortC.getData, [2,3]), (Connector, PortS.putData, [5,6]), (Server, PortquestionReady, [7,1 l]), (Connector, PortS.getData, [ 12,13]), (Connector, PortC.putData, [15,16]), (Client, Port.getAnswer, [17,18])}.
This is an example of pure time-driven deterministic control. If actions in P are defined persistent it is sufficient to add a control action that restarts the virtual clock and resets the plan itself so that the plan describes the behavior of the system until it is stopped. When the first action is executed, Client’s pin Portstart is signaled and the method mapped to that pin is executed. That method formulates somehow a request and puts it into the data pin Portrequest to make it available to the linked pin of Connector. After putting the request, it signals the pin PortdataAvailable to communicate outside that there is a request. In this case, the controller ignores that signal, since actions have already been scheduled. After the completion of the Client’s method, the controller signals the Connector’s pin PortC.getData, without checking incoming signals. In the same way, the controller dispatches the other actions. Another possible solution is to define several
42 (1996)
477-487
templates, each composed of one action. When a signal arrives, the logical planner instantiates the corresponding template by inserting the next action into a plan.
T, = {(Client, Port.start, [current-time + 1, current-time + 21)) T2 = {(Connector, PortC.getData, [current-time, current-time + l])} T3 = ((Connector, PortS.putData, [current-time, current-time + 11)) T4 = {(Server, PortquestionReady, [current-time, current-time + 43)) T, = {(Connector, PortS.getData, [current-time, current-time + 11)) T6 = {(Connector, PortC.putData, [current-time, current-time + 11)) T, = {(Client, Port.getAnswer, [current-time, current-time + l])}
This is an example of event-driven control. In this case the logical planner uses transient actions. For example, when the Client signals the Port.dataAvailable, the planner instantiates the template T2, that states that the controller can immediately signal the connector’s pin PortC.getData and that the corresponding action must terminate within one unit of time of the virtual clock. In the same manner, the controller deals with other system signals. Time-driven control assumes a deterministic execution of components’ methods, that is, it is assumed that the planner knows in advance how long the execution of the methods takes. Such a hypothesis may not hold in a distributed environment where communication delay may not be predictable. In such cases, it is not possible to pre-schedule all the activities. In the example in Fig. 1, it is possible to define a planner that makes plans for the nodes reacting to signals sent by the underlying communi-
F. De Pad
et al./Journal
cation system, represented by the signalOnData trol pins.
of Systems
con-
Architecture
42 11996)
477-487
485
able. The model allows the designersto encapsulate such dependenciesand to accommodatethem within a well-defined context.
4. System configuration As a system is composedof independentcomponents that are not aware of the presenceof the others, the system configuration becomes a programmingin-the-large activity. In traditional systems, the instantiation of computing modules and the establishment of bindings among them is usually performed directly by the software components.Therefore, the configuration information is spreadover the components as programming-in-the-smallconcern (e.g., the creation of processesand socketsin UNIX is embedded into the C code of a program). Therefore, the software componentscan be hardly reused and the configuration management at run-time, which is mandatory for reliable, self-adaptive systems,is made difficult by the programming paradigm since it does not support in a natural way a global run-time representation of a system configuration. In HyperReal the configuration is performed by a configurafor that managesthe creation of components as instances of agents and connectors, the allocation of components to computing nodes and the binding between the ports of the components. A configurator defines a global name space for the components. Ports and pins are identified by a pair, (component name, port name), and a tuple, (component name, port name, pin name), respectively. In a configured system the data pins of a component’s port are bound to the data pins of another component’s port (typically agentsare bound to connectors). Control pins are instead linked to the controller. Note that the implementation of the primitives supporting creation, allocation and binding is system dependent. This is not a weaknessof the proposed model, since some system dependency is unavoid-
5. Conclusions The paper has outlined the main elements of the proposed HyperReal software architecture: first, the time-driven model of control, based on atomic actions performed by reactive components.Second, the modularity, basedon well-defined interfaces through which the components interact. The novelty of the approach does not rely on the definition of new mechanisms,but on the way they are associatedwith specific abstractions that can be combined to build systemsin a clean and flexible way. The time-driven model of control is widely used in Hard-Real-Time systems, since they are basically periodic systemsthat perform actions according to a pre-defined schedule.For instance, MARS [14] has a totally deterministic periodic behavior. On the other side, atomic actions can be found in ESTEREL [15], which is basically event-driven. In real life systems, both event-driven and timedriven paradigms should be supported, as they meet different requirementsthat coexist in the sameapplication. It is the case of Spring [ 161,MARUTI [17] and REX [18], where processescan be either sporadic (i.e., activated by external events) or periodic (i.e., activated on a timing basis). Separationbetween programming-in-the-smalland programming-in-the-large has been widely recognized as a major issue [19]. HyperReal introduces a conjigurator component that manages the system configuration through specific abstractions.From this point of view, HyperReal is very close to REX [20], which introduces components communicating through typed ports and a separate configuration language for instantiating and binding components. The assumptionof connectors as first-class com-
486
F. De P&i
et al./Journa!
of’Systrm.s
ponents modeling communication channels and defining communication protocols derives from recent work in the area of software architecture [6,7]. HyperReal differs from existing paradigms in that it allows to manage not only configuration, but also control at the programming-in-the-large level. The key issue is the separation among different kinds of interaction, while traditional paradigms intermix them all. For instance, the procedure-call paradigm intermixes data exchange, command issuing and control passing. An entry-call, in an Ada rendezvous, specifies data exchange and command issuing, whereas control passing is up to the implementation of the run-time support. In any case, the actual flow of control depends in part on the invocation of communication and synchronization primitives spread throughout the code, and in part on the underlying system. In HyperReal all the control related issues, including the management of time, are made visible as abstractions (events, virtual clocks and plans) to a controller component. As shown, this approach permits to reuse components, to define a wide range of application-oriented control disciplines, to manage timing in a precise way, and to ensure that the time-driven and event-driven approach may coexist. The HyperReal project derives from previous work in the area of RT systems [211. Current work deals with some prototype implementations based on a variety of existing platforms and technological supports. The current implementation of the HyperReal model is described in [22]. Such experiments allow understanding how the proposed model can be used to specify and design application, how portability can be improved by defining a common platform on top of existing systems, and whether the set of abstractions is complete by implementing a platform as a micro kernel on a bare machine [23]. Hardware-software codesign is a promising research area. The idea is that agents, being modeled as state automata, may model hardware components too; and that the management of the time through
Architecture
42 (1996)
477-487
well-defined abstractions allows to emulate the temporal behavior of a system in a host environment. In the near future, we plan to define an architectural language based on the abstractions presented in this paper. The objective is to provide a formal definition of the proposed architectural abstractions and to provide the designer tools in order to effectively design in the HyperReal style.
References [ll
D. Garlan and M. Shaw, An introduction to software architecture, in: V. Ambriola and G. Tortora. eds., Advances in Sojiware Engineering and Knowledge Engineering, Vol. I (World Scientific Publishing Company, 1993). [21 J. Stankovic, Misconceptions about real-time computing, 1EEE Computer 21(10) (1988) 10-19. [31 L. Nigro and F. Tisato, Timing as a programming-in-the-large issue, Proceedings of the Joint Modular Lunguuges Conjb-ence (Ulm, Germany, September 28830. 1994). [4] F. Tisato and F. DePaoli, On the duality between event-driven and time-driven models, Proceedings of the 13th Workshop on Distributed Computer Control Systems (Toulouse, France, September 27-29, 1995). [5] G. Agha, Actors: A Model of Concurrent Computation in Distributed Systems (Artificial Intelligence Series, MIT Press, 1986). [6] R. Allen and D. Garlan, Formalizing architectural connection, Proceedings of the 16th Internutionul Conference oj Sojbvare Engineering (Sorrento, Italy, 1994). [7] M. Shaw, Procedure calls are the assembly language of software interconnection: Connectors deserve first-class status, Proceedings of the Workshop on Studies on Soj?ware Design ( 1993). [81 F. DePaoli and F. Tisato, Architectural abstractions for realtime software, Proceedings of the Asia-Pacific Sojivure Engineering Cortj&ence (IEEE, Brisbane, Australia, December 6-9, 1995). 191 B. Meyer, Systematic concurrent object-oriented programming, Communiccrtion of the ACM 36(9) (1993) 56-80. [IO] S. Budkowsky and P. Dembinski, An introduction to Estelle: A specification language for distributed systems, Computer Networks and ISDN Systems 14 (1987) 3-23. [I 11L. Logrippo, M. Faci and M. Haj-Hussein, An introduction to LOTOS: Learning by examples, Compufer Networks und ISDN Systems 23 (1992) 3255342.
F. De Paoli
et d/Journal
of Systems Architecture
[I21 J. Rumbaugh and M. Blama, Object-Orienred Modeling and Design (Prentice Hall, 199 1). [ 131 K. Ramamritham, Dynamic Priorify Scheduling in Real-Time Systems (Mathai Joseph, ed., Prentice Hall, 1996). [14] A. Damm, J. Reisinger, W. Schwab1 and H. Kopetz, The real-time operating system of MARS, Operaring Systems Reuiews (July 1989) 141-157. [15] F. Boussinot and R. De Simone, The ESTEREL language, Proceedings c$rhe IEEE 79(9) (1991) 1293- 1303. [ 161 J.,Stankovic, The spring kernel: A new paradigm for real-time systems, IEEE &Mare (May 1991) 62-72. [17] 0. Gudmundsson, D. Mose, K. Ko, A. Agrawala and S. Tripathi, MARUTI, An environment for hard real-time applications, in: A. Agrawala, K. Gordon and P. Hwang, eds., Mission Critical Operating Systems (10s Press, 1992). 1181 T.P. Baker and G.M. Scallon, An architecture for real-time software systems, IEEE .%&are (May 1986) 50-58. [19] F. DeRemer and H. Kron, Programming-in-the-large versus programming-in-the-small, IEEE Transacrion on Sofiware Engineering 2(2) (June 1976). [20] J. Magee, J. Kramer, M. Sloman and N. Dulay, An overview of the REX software architecture, Int. Report, Department of Computing, Imperial College, London. [21] L. Nigro and F. Tisato, RTO+ + : A framework for building hard-real-time systems, Journal of Object Oriented Programming 2(6) ( 1993) 5 l-63. [22] M. Agnoli, A. Poli, A. Verdino and F. Tisato, HyperReal one: The implementation, the environment and an example, Proceedings of the 7th Euromicro Workshop on Real-Time Sysrems (Odense, Denmark, June 14-16, 1995).
42 (1996)
1231 P.D. Varhol, 119-128.
477-487
Small
kernels
487 hit it big, Byte
(January
1994)
Francesco Tisato received the Laurea degree in electronic engineering from Politecnico di Milano, Italy, in 1969. Since 1990, he has been a Full Professor of Sistemi per 1’Elaborazione delle Informazioni at the Department of Information Sciences, Universita di Milano. His activities, both as a researcher and as a professional, are focused on software architectures. In particular, he is involved in research projects on object-oriented approaches to the design, implementation, and verification of hard real-time systems, on software architectures for cooperative systems, and on environments for distance learning. Flavio De Paoli received the laurea degree in Electronic Engineering and a Ph.D. in Computer Science from the Politecnico of Milano, in 1985 and 1991, respectively. In 1989, he worked as a visiting researcher at the Hewlett-Packard Laboratories in Palo Alto, CA, USA. In 1992, he was a Temporary Professor of Computer Science at Politecnico di Milano, Italy. Since 1993 he is an Assistant Professor of Computer Science at Department of Information Science, University of Milan. His current research interests include software engineering, programming languages, distributed systems, real-time systems, and cooperative systems. He is a member of ACM and the IEEE Computer Society. Carlo Bellettini received the laurea degree in Electronic Engineering from the Politecnico di Milano, Milan, Italy in 1992. Since 1993 he has been a Ph.D. student in Computer Science at the Universita di Milano, Milan, Italy. His main research interests are in real-time systems, with particular reference to analysis of specification in high level Petri Nets and object-oriented design approaches.
