Meta-Event Description Language for Realtime Corba

Meta-Event Description Language for Realtime CorbaSerge MidonnetEcole Sup´e rieure d’Ing´e nieurs en Informatique et G´e nie des T´e l´e communications, 1Rue du port de Valvins77210Avon,FranceInstitut Gaspard-Monge-Universit´e de Marne la Vall´e e,5,boulevard Descartes,Champs sur Marne,77454Marne-la-Valle Cedex2,FranceABSTRACTAsynchronous programming model is widely used in real time applications.In a CORBA real-time sys-tem,requests may be triggered by the occurrence of asynchronous eful System Events can come from external sources(such as hardware interrup-tions)or from internal program logic.These requests will then be propagated towards a distant Servant in order to be treated as a Servant operation.An asyn-chronous call to a Real-Time Servant Operation is a real-time event.Even if a wide range of applications can benefit from this language,this paper presents the application of MEDL for fault-detection and fault-handling of during the invocation of real-time oper-ations using SORBET.KEY WORDSReal-time Systems,Real-time CORBA,Event Pro-gramming,Specification and Description Languages. 1IntroductionReal-time is one aspect of quality of service which has recently been taken into account in JAVA[1] and in CORBA thanks to two specifications;Real-Time CORBA[2]and Dynamic Scheduling[3].The Real-Time Specification for JAVA(RTSJ)enables real-time applications to choose from different real-time event traffic models(periodic or sporadic),to associate temporal constraints,called release param-eters,with real-time threads and to test their feasibil-ity.The Real-Time Specification for JAVA does not support any particular aperiodic server technology. The Real-Time CORBA Specification provides an ab-straction for distributed real-time programming as an end-to-end schedulable entity termed distributable thread.The RT-CORBA Specification defines a stan-dard for CORBA system implementations that sup-port end-to-end predictability,but does not attempt to address more advanced issues such as resource management or temporal fault tolerance.The aim of the RT-SORBET research project is to implement our research results using the Real-Time JAVA Spec-ification and thus to prove them to be workable. Real-Time Java technology has matured consid-erably since its inception with appropriate tools, methodology and technology.Its prime advantages; portability,type safety,and syntax can be brought to realtime and embedded systems as well.So more and more commercial products are beginning to adopt Java technology to develop real-time components,[4] reports that more than3000people have used the RTSJ reference implementation(RI)from Timesys, a commercial RTSJ compliant JVM i.e.JamaicaVM from AICAS[5],[9]or other free implementations such as Jrate[6]and[7]Flex[8]to create application prototypes.In this paper we propose a tool based on RTSJ specifications,capable of incrementing the produc-tivity and maintenance of real-time systems which interact closely with the physical ing this tool we can clearly separate the interpretation of ex-ternal stimula from the logic of the application. 1.1An asynchronous worldThe real-world can be modeled as an asynchronous system.RT applications interact closely with the real-world(real-time embedded systems,real-time sensors,etc...),so every RT programming environ-ment has to provide support for event handling and asynchronous control transfer.RTSJ(Real-Time Specification for Java)provides the support for asynchronous transfer of control in real-time Java applications.Due to its dependency on the real-world,a great part of a real-time application code is dedicated to handling incoming signals.Often the meaning of those events depends on previously received signals. We introduce the concept of meta-event,which stands for“an event that encapsulates a sequence of events”and the Meta-Event Description Language and tools for meta-event description and Java code generation.With SORBET,we use a standard CORBA IDL to specify the application’s interface and we used MEDL to modelize the application’s temporal behavior by a rational expression which describes the inter-relation between events.1.2Paper organisationThe remainder of the paper is organised as follows: Section1gives a general introduction to the asyn-chronous programming model and its implementa-tion in Java;in Section2we introduce the concept of meta-event by an example and in Section3we ex-plain the language’s structure and how to define a meta-event;in Section4we discuss the result of the compilation process;Section5summarizes the results we have obtained and presents how they can be used to improve the construction of a real-time based ap-plication.2Asynchrony in Realtime Java The Realtime Java specification generalises Java’s mechanism for event handling and asynchronous transfer of control.The Asynchrony section of RTSJ contains classes that:•Provide mechanisms for binding internal and ex-ternal events to a program logic.The program will execute as the event occurs.•Provide an alternative approach for interruptinga schedulable object,using asynchronous trans-fer of control(ATC).The RTSJ ATC model is integrated with the Java exception handling fa-cility.•Provide mechanisms for the asynchronous termi-nation of threads.In this section we focus our attention on RTSJ’s event model.As an extension to the classic event model for Java,an event is represented by the non-abstract class javax.realtime.AsyncEvent.An instance of this class is an object corre-sponding to the possibility of an aynchronous event occurence.On the other hand,the class javax.realtime.AsyncEventHandler is an abstract class that represents the action to be taken when an event occurs.An AsyncEvent can befired by the application logic or can be bound to a happening external to the JVM,such as a software signal or a hardware inter-rupt(this case is very frequent in RT systems).The invocation of the fire()method on an AsyncEvent corresponds to the occurence of the event.An AsyncEventHandler subclass embodies the code which executes when a particular event occurs. The handler can embody the code in two differents ways(according to the same pattern used to embody the code of a normal Java thread):•by subclassing the AsyncEventHandler class and by implementing the abstract handleAsyncEvent()method with the action code.•by implementing the ng.Runnable interface infilling in the run()method with the required logic,then creating the AsyncEventHandler instance using the con-structor which takes the Runnable interface as parameter.With this mechanism handlers inherit from other hierachies,not necessarily from AsyncEven-tHandler.To bind a handler to an event,the addHandler(AsyncEventHandler h)method of AsyncEvent is used.This kind of association is any-to-any,thus we can have several handlers attached to the same event and,at the same time,a handler can be attached to several differents events.2.1Threads and handlersWhen fire()method is called on an event object, the run()method of each registered handler is scheduled(not executed!)with the guarantee that multiple calls will be serialized and that there will be,at most one execution for each handler.There are two types of RTSJ handler:Bound and Unbound Handler.The execution style depends on the type of handler:Unbound Handlers In this case the handler is dy-namically bound to the execution context at the moment it is triggered.This solution does not require a dedicated thread for each handler’s in-stance but introduces non-determinism(a vari-able execution time)in the handler execution.The AsyncEventHandler class implements the Schedulable and Runnable interfaces.Bound Handlers The BoundAsyncEventHandler class is a subclass of the AsyncEventHandler abstract class which implements the event’s handler.In this case the handler is permanently bound to a realtime thread.A BoundAsyncEventHandler encapsulates aRealtimeThread from the moment of the for-mer’s creation.The real-time thread is added to the scheduler’s timeline.This approach should be used by handlers which cannot tolerate the time loss caused by the dynamic binding.This situation can lead to a scheduler overload as there may be a large number of threads.2.2Specifying time parameters forhandlersAs handlers have the same structure as real-time threads,the class AsyncEventHandler provides con-structors with references to SchedulingParameters, ReleaseParameters and MemoryParameters.If no parameter is provided during the handler creation(or a dummy constructor is used),the associated thread inherits real-time parameters from its parent thread. Scheduling parameters specify a thread priority or importance.Handlers are scheduled with respect to their priority with the same procedure as a real-time thread.Memory parameters specifications are relevant only in the case in which a lot of heavy objects are created during the handler execution.The RTSJ specification describes a Peri-odic,a Sporadic and an Aperiodic thread traffic model.In order to specify this traf-fic model,we use PeriodicParameters; AperiodicParameters(subclasses of ReleaseParameters)or SporadicParameters (subclass of AperiodicParameters).These parame-ters contain a set of associated time values and fault handlers.The associated time values are set accord-ing to the traffic model.A Periodic traffic model is characterized by;thefirst activation time Offset; the Period;the Cost and the Deadine.A Sporadic traffic model is characterized by;its inter-arrival time;its Cost and its Deadline.An Aperiodic traffic model is characterized by;its Cost and its Deadline. The CostOverrun handler is triggered when a thread overruns its allocated execution duration value(the Cost value).The DeadlineMiss handler is triggered when a thread misses its deadline.The handler is triggered by an external source,so the traffic model of the thread,which is bound to the handler,is imposed by the timing model of the event’s source.For example if the event is triggered by a periodic thread of period T1,the event oc-curs periodically,so the handler periodicity equals T1.The RTSJ specifications provide a method createReleaseParameters()for the AsyncEvent classes which enables the handler’s programmer to ac-cess at its worst case value.(the estimation is based upon the analysis of the release parameters of the thread associated to the event).This method returns a ReleaseParameter object which has to befilled in before being sent on to the handler’s constructor.3The SORBET Meta-Event Description LanguageThe meta-event concept arose from the need to control and identify situations characterized by the happening of a series of”simple”events.This series is expressed using a Description Language,which is based on rational expressions.The meta-event itself is an event(subclass of AsyncEvent)to which it is possible to attach han-dlers.The handlers are scheduled when the rational condition described in the Event Description is satis-fied.Two entities are always attached to a meta-event:•the suppliers,or the base events which are used to describe thefire condition for the meta-event•the consumers,or the handlers,attached to the meta-eventSo the meta-event can be considered by a series of suppliers as a proxy of consumers(fig.1).The fun-damental difference with the proxy model is that the meta-event controls an internal state that records all past suppliers’solicitations and activates consumers only when the conditions described in the ME de-scription are reached.SuppliersFigure1:Meta-Event’s Architecture3.1An example scenarioLet us introduce a typical scenario in which the con-cept of a meta-event can be simply understood.We have already seen that any implementation of the RTSJ can signal,via an AsyncEvent,the situation in which a realtime thread has overrun its costs or missed its deadline.According to the theory of real-time systems, it is clear that a cost overrun condition is a good indicator of a future missed deadline.Let us consider a set of realtime periodic operation threads,τ1,τ2,τ3,we use the concept of meta-event in order to design a fault-prediction system.Thus we create a meta-event that will be launched if there are three consecutive cost overruns byτ3,or two byτ2.The handler associated with this meta-event will take some preventive action such as de-scheduling the two threads,increasing their cost and then rescheduling them if possible.Another kind of meta-event occurs in the criti-cal situation whereτ3reaches twice times the cost overrun and thenτ2does the same thing.In this case,there is a precedence relation between these base events.In this situation drastic action must be taken in order to prevent missing deadline situations,such as a deadline increment forτ2andτ3.With SORBET-MEDL,both of the previous situ-ations can be easily described by a logical relation-ship between base events.If we call co1,co2,co3the cost overrun events and dm1,dm2,dm3the deadline missed events,respectively associated withτ1,τ2and τ3,we can define the two meta-events by the following expressions:•((co3TIMES3)OR(co2TIMES2))for thefirst meta-event•((dm3TIMES2)THEN dm2))for the secondmeta-eventThe result of the compilation of the Descriptionfile for those meta-events is two Java classes that map each described event.The generated classes take as constructor parameters the reference to each base sig-nal and each meta-event handler.In the next section we will be presented the formal grammar of SORBET-MEDL.4The languageThe language that we use to describe a meta-event has been designed to be easy to use and to learn. Such as with Corba IDL or QDL[10][11]a compiler generates implementation skeletons Java classes. The Descriptionfile is divided into two main sec-tions:declarations and definitions.4.1Language DeclarationsThe aim of the declaration section is the generation via a command-line option of empty skeletons for sup-pliers and consumers classes.So the programer can clearly see all the classes which must be coded.The import and package directives have the same meanings as in Java:all generated classes will be put into the specified package,while the import directive will be copied onto all the generated meta-event classes to ensure correct cross-package instance of suppliers and consumers.4.2Language DefinitionsThe semantics of a meta-event generally involves three entities:the instances of base events called here suppliers,the instances of meta-event’s handlers (called consumers)and the expression of thefire con-dition.Each of these elements has to be defined in the meta-event definition statement.For suppliers’and consumers’instances we use the classic type:instance_name declaration statement. For thefire condition expression,the language of-fer a set of operators that maps the most commonly used relationships between base events and/or com-posite expressions:AND,OR,THEN,TIMES.The first two operators can be compared with gates in a logic network where the signals are the events.The last two operators introduce timing relationships be-tween their operands.Let us explain in detail the meaning of each of these terms:e1AND e2is verified if e1and e2are already ver-ified.The space of sequences matched by this rule is:[(e1,e2),(e2,e1)].No temporal rela-tionship is required between e1and e2.e1OR e2is verified if either e1or e2is verified.Again,this operator does not use any temporal relationship between its operands.e1THEN e2means that e2requires one occurrence of e1in order to be verified.This operator clearly introduces the relation of temporal prece-dence between two expressions or base suppliers.e1TIMES n is verified if the expression e1has itera-tively been satisfied n times.Note that this op-erator(TIMES)authorizes an expression on itsleft hand side and an integer on its right handside e.g.(e1AND e2)TIMES2.The grammar permits multiple definitions of events in the same compilation unit.Every base event(sup-plier)and every handler(consumer)instance can be seen only in the compilation unit in which they are declared.The grammar permits multiple definitions of events in the same compile unit,because every base event (supplier)and every handler(consumer)instance has the limited scope of the event in which they are de-clared.Events{MetaEvent1,MetaEvent2};/*base events*/Suppliers{CostOverRun,DeadLineMiss};/*handlers*/Consumers{COHandler,DLMHandler};/*definition of MetaEvent1*/MetaEvent MetaEvent1{Supplier CostOverRun:co2,CostOverRun:co3; Consumer COHandler:c1;EventCondition((co3TIMES3)OR(co2TIMES2)); };/*definition of MetaEvent2*/MetaEvent MetaEvent2{Supplier DeadLineMiss:dm2,DeadLineMiss:dm3; Consumer DLMHandler:h1;EventCondition((dm3TIMES2)THEN dm2);};The listing shows the complete meta-event specifica-tions for the above example scenario.// empty class to be filled// by the programmer// empty class to be filled// by the programmer// empty class to be filled// by the programmer// empty class to be filledrtme.example.MetaEvent1+ MetaEvent1 (CostOverRunEvent co3,CostOverRunEvent co2,COHandler c1 )+ activate()+ deactivate()+ MetaEvent2 (DeadLineMissedEvent dm3,DeadLineMissedEvent dm2,DLMHandler c1 )+ activate()+ deactivate()rtme.example.MetaEvent2 rtme.exemple.CostOverRunEvent rtme.exemple.DeadLineMissedEventrtme.exemple.DMLHandlerrtme.exemple.COHandler// by the programmer<<generated classes>>Figure2:Compilation output5The compilation outputEach meta-event described in the compilation unit is mapped into a Java class.Each generated class has the same name as the meta-event described in the SORBET-MEDL specifications and has a sin-gle constructor to whom we pass all suppliers’and consumers’references.Each of those parameters is mandatorily typed with the class specified in the event’s definition.To avoid mistakes in the case where the meta-event uses multiple references to the same supplier type, each parameter has the same name of the instance defined in the event specification.Seefigure 2. Where the compilation output for2meta-events is given.5.1Sequence detector implementa-tionsA meta-event must be ready for a call from any or all of its suppliers.A handler(subclass of AsyncEventHandler)is created for each supplier and bound to its respective event.Note that this series of handlers is encapsulated and therefore is invisible from the exterior.There are two possible design solutions for the in-ternal handlers.The choice between them depends onthe implementation of the sequence of detectors:via a classic transition table(1)or via a runtime based on internal events’propagation(2).The compiler uses the second solution as default implementation.To choose the transition table option,the user needs to specify--transition-table in the command-line. In the next paragraph we describe these two solu-tions.Transition table implementation The transition table is generated by the compiler from the meta-event’s logic expression.In this classic approach, the sequence detector can be viewed as a lexical scanner in which events are tokens.The advan-tages of this solution are:•a self-contained class,that doesn’t requirean external library.•a constant execution time for each inter-nal handler associated with the event’s sup-plier.The drawbacks are:•this solution can lead to state explosionwith complex logic conditions.•the memory size necessary for the generatedclass is variable.Internal propagation of events In this solution we use a runtime library, org.sorbet.realtime.rtme.detectors.This package provides a class for each operator in the event condition specification:AndDetector,OrDetector,ThenDetector, TimesDetector,Each class implements the IDetector interface and acts like a logic gate.Input signals are represented by expression’s operands and the output signals become the input at the upper-level expression.The entire expression is mapped onto a logic net-work in which every node of the Abstract Pars-ing Tree(APT)corresponds to a detector of the appropriate class.The IDetector interface pro-vides methods for the linking of nodes and facil-itates the communication between them,using respectively the registerSource()method and the handle()method.The reference of the upper-level gate is trans-mitted to the current gate by its constructor.At this point the upper-level gate reference registers as source using the registerSource method.Thus each gate is linked both to itspredecessors and to its successor.A single gate signals that its condition is satisfiedby calling the handle()method on the upper-level node.Base events are handled by special detectors,instances of SignalDetector(which inherits from AsyncEventHandler).On the other hand,a meta-event signals that its condition is satisfied by calling the external handler’sfire method(meta-event consumers).To avoid the propagation of signals for expressions that are already verified,the IDetector interface provides the reconnect() and disconnect()methods.Consider,for ex-ample,the expression s1AND s2:if the received signal sequence is s1,s1,s2,there is no reason to continue accepting s1after itsfirst occurence, accordingly the s1.disconnect()method is called at this point.All connections are restablished when the global fire condition is satisfied.The pros of this solution are mainly scalability and modularity.It is simple to connect new com-ponents by adding new detector classes.without entering into the compiler’s implementation to modify the transition table’s generation process.We consider this to be a great advantage and we plan to add more detectors to the next compiler’s version.Conversly,the execution duration of the sup-plier’s event handler is variable,due to a non-deterministic chain of method calls between de-tectors.In any case,it is possible to estimate the cost of each SignalDetector by a worst-case analysis.6Conclusions and future chal-lengesIn this paper was have explored the concept of meta-event and the SORBET framework’s contribution to real-time systems engineering.The principle contri-bution of our work is the separation of application logic from signal interactions.This separation en-ables us to make real-time applications more modular and thus more scalable.We hope to have shown just how powerful a solution based on meta-events can be.There is still a lot of work to be done.( s1 AND s2 ) THEN s3THENANDs3s1s2Transition Table0123s1s2s311 3 1 32 23 3 Fire2 0Sequence DetectorSuppliersConsumersSignalDetectorFigure 3:Different implementations of a meta-eventOur aim in the future is to extend the framework with the following features:•The creation of a new structure in the language which maps transitions between states and there related actions.•The performance improvement of the sequence detection system •The addition of new operands to the runtime•The addition of worst-case analysis method forthe cost determination of the meta-eventInformation,documentation and dis-tribution versions are available athttp://igm.univ-mlv.fr/~midonnet/SORBET-MEDL .Since SORBET-MEDL is an open-source project,we encourage developers and researchers to download the code and to contact us with comments,questions,and add-ons.References[1]G.Bollela et al.”The Real-Time Specificationfor JAVA”,Addison-Wesley Publishing Compant,195pages,Jan 15,2000.[2]Object Management Group Real-time CORBA,OMG Document orbos/99-03-32ed.,March 1999[3]Object Management Group Dynamic Scheduling,OMG Document orbos/99-03-32ed.,March 1999[4]C.D.Locke.”Real-time Java moving to the main-stream”.RTC Journal,January 2004.[5]/jamaica.html[6]A.Corsaro, D.C.Schmidt.”Evaluating real-time java features and performance for real-time embedded systems”.In Proceedings 8th Real-Time and Embedded Technology and Applica-tions.IEEE Computer Society,September 24-27,2002.[7]/M.Rinard et al.,”FLEX Com-piler Infrastructure.”http://www.fl/Harpoon/,2002.G.Bollella, B.Delsart,R.Guider, C.Lizzi,F.Parain ”Mackinac:Making HotSpotReal-Time”.Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’05)pp.45-54.[10]P.Pal,J.Loyall,R,Schantz,J.Zinsky,R.Shapiro,J.Megquier.”Using QDL to specifyQoS Aware Distributed (QuO)”in Proceedings of the Third IEEE International Symposium on Object-Oriented Real-Time Distributed Comput-ing,Anne:2000[11]P.Narasimhan,T.A.Dumitras,A.M.Paulos,S.M.Pertet,C.F.Reverte,J.G.Slember andD.Srivastava.”MEAD:Support for Real-Time Fault-Tolerant CORBA”.Concurrency and Com-putation:Practice and Experience,vol.17,no.12,2005,pp.1527-1545;Copyright 2005John Wi-ley and Sons。