Automatic Verification of Component-Based Real-Time CORBAApplications∗

Gabor Madl Sherif Abdelwahed Gabor Karsai{gabe,sherif,gabor}@isis.vanderbilt.edu

Institute for Software Integrated SystemsVanderbilt University, Nashville, TN, 37205

Abstract

Distributed real-time embedded (DRE) systems of-ten need to satisfy various time, resource and fault-tolerance constraints. To manage the complexity ofscheduling these systems many methods use Rate Mono-tonic Scheduling assuming a time-triggered architecture.This paper presents a method that captures the reac-tive behavior of complex time- and event-driven systems,can provide simulation runs and can provide exact char-acterization of timed properties of component-basedDRE applications that use the publisher/subscriber com-munication pattern. We demonstrate our approach onreal-time CORBA avionics applications.

1. Introduction

Computing systems are increasingly distributed,real-time and embedded (DRE) and must operate un-der highly unpredictable conditions. Component-basedmiddleware provides a means to manage the complex-ity of designing these systems. To deal with the com-plexity of analyzing DRE systems we need to raisethe abstraction level from the implementation to sys-tem models that capture crucial concepts of the systemsuch as structure, behavior, environment and the prop-erties the system must satisfy.

In this paper we present a solution that captures thereactive behavior of event-driven systems and can au-tomatically verify quantitative dense time properties.Our approach is not limited to periodic systems andcan be used with any component-based event-drivensystem that uses the publisher/subscriber communica-tion pattern.

∗ This work is sponsored in part by NSF ITR project ”Founda-tions of Hybrid and Embedded Software Systems”

The Boeing Bold Stroke DRE architecture [30] isused at Boeing to develop mission-critical avionics ap-plications that control weapons systems on a commonplatform. It is built on the real-time CORBA open mid-dleware standard and has been successfully deployedin several military systems. We chose this platform todemonstrate that our approach is feasible for real-lifesystems. We use the Uppaal verification tool [28] forthe analysis. We map the ESML application models tothe Uppaal timed automata [24] using graph transfor-mations implemented by theGraphRewritingAndTrans-formation (GReAT) language [1].

This paper is organized as follows: Section 2 ex-plains the modeling language of the component-basedapplications, Section 3 explains the Boeing Bold Strokearchitecture, Section 4 gives a brief overview of ourapproach, Section 5 gives a formal description of thetimed automata and the scheduling problem, Section 6illustrates the key concepts that we have used in mod-eling the scheduling, Section 7 demonstrates the ver-ification of an example application and Section 8 dis-cusses the related work on the field. We end by draw-ing conclusions and discussing future directions.

2. The Embedded Systems Model-ing Language (ESML)

ESML [22] is a modeling language for embeddedsystems that tries to overcome a few shortcomings ofUML [21], such as the lack of a component model, inter-action modeling, component and system configuration,etc. ESML models are automatically transformed intothe Analysis Interchange Format (AIF) that is used toexchange models between tools of different vendors.

ESML is based on Real-Time Event Channel tech-nology defined in the CORBA [26] specification, imple-mented in TAO [17], and also related to the CORBAComponent Model [27]. In this model, components are

Figure 1. Periodic event-driven control push -data pull processing

complex objects that encapsulate multiple instances ofdifferent classes. The interaction between instances ofdifferent components is modeled with ports. Ports areinterfaces for reaching classes inside the components.

The method invocations follow the traditional syn-chronous blocking call-return semantics, where onecomponent executes a method invocation on anothercomponent. The event propagation mechanism followsa non-blocking asynchronous publisher/subscriber se-mantics supported by event channels. When the pub-lisher pushes an event to the event channel the sub-scribed components will be notified.

To allow the modeling of time-driven tasks, compo-nents can receive notifications from special predefinedcomponents, called Timers. Timers publish events witha constant period. These events periodically initiate theprocessing of data read from physical devices, but theprocessing of the data is usually not synchronized toclocks but triggered by events.

Figure 1 illustrates the periodic event-driven modelused in ESML. The TimerDriven component is sub-scribed to the Timer and receives notifications peri-docially. This will trigger the execution of an actionencapsulated in the component. This action will pub-lish events to the EventDriven component. When theEventDriven component is notified about the avail-ability of data it will issue a remote method call onits receptacle to the facet of the TimerDriven com-ponent to retrieve that data. This approach separatesthe flow of control from the flow of data and allowsfine-grain scheduling and the incorporation of qualityof service (QoS) properties that allow fine-tuned con-figuration of the system for optimal performance [17].

3. The Boeing Bold Stroke architecture

The Boeing Bold Stroke architecture is acomponent-based execution framework built ontop of the ACE/TAO real-time CORBA imple-mentation [29] and uses the publisher/subscribercommunication pattern. It uses a proprietary com-ponent model called PRISM [30], which emulatesthe CORBA Component Model (CCM) [27]. WhileCCM allows components to be dynamically cre-

Figure 2. The Boeing Bold Stroke executionframework

ated and connected, PRISM follows a typical prac-tice in safety/mission-critical systems and employs astatic component allocation and configuration pol-icy by creating and connecting components onlyin the system initialization phase. Stateful com-ponents can support dynamic reconfiguration bychanging behavior based on the system mode set-tings.

Bold Stroke is event-driven, although driven byTimers. Figure 2 shows the physical model of the BoldStroke execution framework. Components contain ac-tions that are the smallest units of processing. BoldStroke uses priority-based scheduling, actions that havethe same priorities are scheduled non-preemptively ina priority band (sometimes referred to as rate group)based on their sub-priorities and preemptive schedul-ing is used between priority bands. An action has anassigned priority and sub-priority (importance) valuefor every event channel it is subscribed to. If two ac-tions have the same sub-priority they will be ordered orscheduled non-deterministically according to the con-figuration. Every action has a measured worst-case ex-ecution time in the given scenario in which it is used.Actions can be initiated by two ways; method invoca-tions and event propagations. The scheduling strategyis also configurable and uses Rate Monotonic Schedul-ing by default.

A priority band is implemented by three threads;the dispatcher (work) thread which executes all the ac-tions initiated by event propagations, the interval time-out thread which simply pushes timeout events at pre-defined intervals, and the ORB thread which contin-ually processes inputs from the Object Request Bro-ker (ORB), executing actions initiated by method in-vocations. This is the implementation of the ThreadPool policy for multi-threading in which a fixed num-ber of threads are generated in the server at the ini-tialization phase to service all incoming requests. Thisapproach offers scalable applications with low latency

times for small duration requests [10].Facet-initiated actions (that were initiated by a re-

mote method invocation) inherit the Quality of Serviceexecution semantics from the invoking component anddo not interact with the runtime scheduler thereforewe do not distinguish them from the invoking action inthe scheduling perspective. The smallest unit of schedul-ing is an event-initiated action together with all the re-mote method calls it can invoke. Since facet-initiated ac-tions can also call other actions using remote methodcalls the complete call chain is an acyclic graph withthe event-initated action as root element. We call thissmallest unit of scheduling an invocation unit.

An executing action may initiate actions on otherpriority bands, otherwise known as cross rate actions.All processing inside a priority band needs to finishwithin the fixed execution period of the Timer assignedto the band. This periodicity divides processing intoframes. A priority band failing to complete outputsprior to the start of the next frame is said to be ina frame overrun condition, meaning that the band didnot meet its completion deadline or frame time.

4. Approach

The presence of Timers in the Bold Stroke archi-tecture is an attempt to increase the analyzability ofthe system by turning it into a time-triggered archi-tecture. This effort is also reflected in the terminology(rate group, Rate Monotonic Scheduling). Many meth-ods assume a time-triggered architecture and try to an-alyze the scheduling of the Bold Stroke architecture byperforming Rate Monotonic Analysis. This approach iswidely accepted for fixed priority scheduling.

The Boeing Bold Stroke architecture is driven byTimers, however the system itself is event-driven. As-suming a time-triggered architecture may introduceanomalies in some cases. The main reason behind thisis the reactive behavior of the system; certain ac-tions (e.g. identifying targets) will be invoked whenexternal events - coming from the environment non-deterministically as sensor values - are triggered. Ac-tions are not invoked by Timers but by other actionsif certain constraints are satisfied, and since the eventflow can change the invocations might be aperiodic.Even if we assume that actions have constant execu-tion times an action can publish an event anytime be-tween the execution time and the deadline, since it canwait for other executing processes and the initiationof processes depends on external (non-deterministic)events. The semantics for conditional event triggeringand the propagation of missed deadlines is also inex-pressible by this approach. This makes it hard to iden-

tify vulnerable points in the system, because the im-pact of a single component failure is undetectable.

In this paper we present a solution that captures theevent-driven nature of theBoeingBold Stroke systemandcan be used to verify timed properties of aperiodic sys-tems. We show that timed automata [2] as a compu-tational model can describe asynchronous event pass-ing as well as time constraints. It has the necessary toolsupport [7] [28] and does not need to be extended tohandle quantitative dense time features like SPIN [31].Timed automata has a nice graphical representationthat makes the graph transformations suitable. Sev-eral model-checking tools use automata theory - usu-ally with some extensions - as a computational model.A few examples are Hytech [19], Kronos [7] and Up-paal [28]. We chose the Uppaal model-checker toolwhich is widely used [13] [16] [12] for schedulabilityanalysis and model checking. We map the ESML appli-cation models to the Uppaal timed automata [24] us-ing graph transformations and prove system propertiesby checking the generated timed automata. The graphtransformation has been implemented in the GraphRewriting and Transformation (GReAT) language [1].The GReAT tool uses the Generic Modeling Environ-ment (GME) [25] and allows users to specify graphtransformations in a graphical form.

5. Problem Description

The system under consideration in this paper con-sists of a set of dynamics tasks (invocation units). Eachtask is attributed with its worst case execution time(WCET), deadline (DL), and priority (PID) specification.With respect to timing analysis, computation tasks canbe represented by a generic timed automaton model.The task mode is composed of four states: Idle, Ready,Executing, and Timeout. Initially tasks start at an Idlestate and are triggered (Idle → Ready) by events whichmay be received from other tasks or at regulars inter-vals from a Timer. If the task is scheduled for execution- according to the given scheduling policy - the transi-tion (Ready → Executing) will be triggered. After exe-cution, the task may also initiate other tasks by send-ing the corresponding event1. The task will move to ablocking Timeout state if the deadline is exceeded.

Tasks are executed based on a given scheduling pol-icy which determines at a given time the eligibility of a“ready” task to proceed for execution. In other words,the scheduling policy is responsible for triggering thetransition (Ready → Executing). When this transition

1 In general, this may occur during the execution state. How-ever, for non-preemptive scheduling the event would not haveany effect until the task terminates

Figure 3. Generic timed automata model for theTask, Scheduler and Timer

is enabled, the automaton has to take this transitionwith no time delay. For static scheduling, the policycan be represented by a vector that indicates the eli-gibility of tasks for execution. A task can move to Ex-ecuting from Ready only if no higher priority task canmake a similar transition at the same time.

The above task model and scheduling policy can berepresented as timed automata. A timed automaton isa state machine equipped with clock and data (inte-ger) variables, with precise formal definition [2] [24],tool support [7] [28] and is widely used [4] [11] [3] [13][16] [12] for schedulability analysis and model check-ing. Since the focus of this paper is the application oftimed automata we refer the reader to these sourcesfor a more formal definition of the timed automata.Transitions in a timed automaton can have guards andreset operations on clock and data variables. Transi-tions are enabled if the corresponding guard evaluatesto True. An enabled transition can execute instanta-neously while resetting certain variables to new valuesaccording to the underlying reset assignments. Statesin timed automata can be associated with an invari-ant that determines the validity of clock assignment inthe state. The system can be in a given state only ifthe underlying invariant is True.

Figure 3 shows a generic timed automata model fora set of time- and event-driven tasks and the under-lying scheduler based on the above description. In thisfigure a task can be initiated by another task or a timer(or both).

The scheduler will move to a committed state if anyof the tasks will be eligible for execution. Time can-not pass in this location: the scheduler must take anenabled transition with no time delay. Transitions willbe enabled based on the scheduling policy. When tak-

Figure 4. Generic model of an invocation unit

ing the transition it will send out an event scheduling atask for execution from a set of ready tasks. The sched-uler moves to the wait (initial) state if no task is readyfor execution. The scheduling policy is encoded in threefunctions: Add(w, i) which increases the current prior-ity level when taski becomes ready, Sub(w, i) which de-creases the current priority level when taski becomesready, and Enable(w, i) which evaluates to True if theith task is eligible for execution. For example, in a sim-ple index based priority scheme, Add(w, i) = w + 2i−1,Sub(w, i) = w − 2i−1, and Enable(w, i) = 2i−1 ≤ w <2i. Other scheduling schemes can be established bydefining appropriate formulas for the above three func-tions.

In this paper we consider the problem of deciding theschedulability of a given set of tasks with both event-and time-driven interactions. The timed automata for-mulation of the problem in effect translates the schedu-lability problem into a reachability problem in whichthe set of tasks are schedulable if the Timeout stateis not reachable in any of the task timed automata, inother words all tasks are completed before their respec-tive deadlines.

6. Generic modeling of the event-flow

Figure 4 shows the generic model of an invocationunit. This model is the extension of the generic timedautomaton model shown on Figure 3. Since the Up-paal timed automata semantics is unambigous (theautomata executes on the Uppaal virtual machine)we have formally defined our model by giving Figure 4

and using the Uppaal timed automata execution se-mantics [24]. In the following we give an informal de-scription of the model to explain how the key concepts,such as concurrency, asynchronous thread invocation,inter-process communication (IPC) and non-preemptivescheduling are represented in the model.

The inactive location corresponds to the Idle loca-tion of the generic automaton, the frameOverrun loca-tion corresponds to the Timeout location. The Ready lo-cation of the generic timed automaton model is repre-sented by two states (schedule and waitForExecution) inorder to express that the enabled transition to the Ex-ecuting location has to be taken when the transitionis enabled. To model the event passing we modeledthe Executing location by three locations (executing,publish and dispatch). This timed automaton has twoclocks (clock 1 and clock 2) working at the same rate.Attributes can be local (pid, deadline, wcet) andglobal (execute).

Concurrency: This timed automaton type mayhave multiple instances. These instances can communi-cate with each other using synchronizations or sharedglobal variables. The execute variable is used to re-strict that only one action can execute in the prior-ity band at any given time. It acts as a global flag thatis set everytime an action starts executing and resetwhen it finishes the execution.

Asynchronous thread invocation/IPC: When apublisher pushes an event the subscribed componentswill be eligible for execution. We model this by syn-chronizing the publish → dispatch transition of thepublisher with the inactive → schedule transition ofthe subscribed components.

Non-preemptive scheduling: The priority-basedscheduling is encoded in the guard condition of theschedule → executing transition. Urgent locations(schedule) are simple constructs in Uppaal to expresstime constraints. When a location is urgent, time can-not pass in that location. If no transitions are en-abled at that time the system is deadlocked. This isalso true for committed locations (publish, dispatch,frameOverrun), but their outgoing transitions have tobe taken first. In other words, transitions belongingto committed locations have preference, while this isnot the case for urgent locations. In this particularexample we can use these constructs to describe thefact that we want invocation units to publish beforeany rescheduling happens. We can also formalize clockconstraints (invariance) for the locations. These areshown next to the locations on Figure 4. When the con-straint is violated a transition has to occur otherwisethe timed automaton is deadlocked. In the schedulestate every timed atomaton checks whether higher sub-

priority invocation units are eligible for execution, ifyes they move in to the waitForExecution state. If thereare multiple highest sub-priority invocation units onewill be chosen non-deterministically. Whenever an in-vocation unit finishes the execution it broadcasts anevent (wakeup) to all the timed automata. This willforce them to check the guard conditions again.

7. Case study: Timed analysis of a BoldStroke application

In this section we show a case study on how we usethe modeling concepts desribed in Section 6 to verifya Bold Stroke application shown on Figure 5. This ap-plication is driven by a single Timer therefore it cor-responds to a single rate group/priority band. Eachcomponent contains exactly one event-initiated actiontherefore when we refer to the scheduling of the compo-nents we mean the scheduling of the invocation units(the event-initiated action together with the recepta-cle calls).

The INS and GPS components are both subscribedto the same event channel. When the Timer pushesan event both components will be notified. These twocomponents correspond to two time-driven invocationunits. Since both components receive the same events,they will be eligible for execution at the same time.The scheduler will choose one component according tothe scheduling algorithm while the other must wait un-til the first finishes execution.

The AIRFRAME component is subscribed to bothtime-driven components. The semantics of handling theevents is configurable. If we assume AND semantics thenthe component has to wait until all events have ar-

Figure 5. Bold Stroke application model

rived for which the component is subscribed. If we as-sume OR semantics, any event can trigger the compo-nent’s execution. In this particular example OR seman-tics is assumed, because the AIRFRAME component up-dates its state if any of the INS or GPS componentshave new data. When the AIRFRAME component is ex-ecuted, it calls back to the INS and GPS componentsusing a remote method call and publishes an event tothe DISPLAY component after it has made the neces-sary computations. The DISPLAY component will callback into the AIRFRAME component during its execu-tion - in order to display the new data.

7.1. Decomposition rules for the executionpaths

We claim that the non-preemptive scheduling of Bold-Stroke applications can be verified without explicitlymod-eling the buffering of the event channel. In order to showthis, we have to check the properties of the call chains.We already defined the call chains for remote methodcalls when we introduced the concept of the invocationunit. In that context, the call chain is an acyclic graphwith the event-initated action as root element. We candefine call chains for the event-flow as well. In a singlepriority band, the Timer will publish events to the sub-scribed components. These components will also pub-lish events etc. There are no cycles in the event flow,otherwise we would end up in a loop that can possi-bly execute forever. The call chain of the event flow ina priority band can be represented as a directed graphforest with the Timers as roots of the trees. The ver-tices correspond to invocation units, the edges corre-spond to the published events. The trees can be con-nected to each other, but the whole graph is acyclic.The event flow graph for this example is shown on Fig-ure 6.

Figure 6. The event flow represented as a Di-rected Acyclic Graph (DAG)

The AIRFRAME component can receive events fromboth the INS and GPS components, therefore it is morecomplex than the other components. Since the num-ber of vertices and the number of edges is finite, we

can define a finite number of execution paths on thisevent flow, that is a path from the root element toa leaf. We need to decompose the AIRFRAME compo-nent to get the execution paths. If we assume OR se-mantics for receiving the events the event flow can bedecomposed into the execution paths depicted on Fig-ure 7.

Figure 7. The execution paths assuming OR se-mantics

The main idea used in the decomposition is thatwe keep track of the event channel buffer in the stateof the timed automata. For every event received thecomponent publishes at most one event in any of itsPublishPorts. We keep track of the events received inthe state of the timed automata. This allows us to ex-press AND semantics for receiving the events as well.Figure 8 shows this scenario. This rule is shown onlyto demonstrate that different semantics can also be ex-pressed.

Figure 8. The execution paths assuming AND se-mantics

The dotted line denotes synchronization between thecorresponding timed automata. We force the automatato start executing at the same time. This constraint -together with the guards on the transitions that con-trol when the automaton is scheduled for execution -will enable the set of timed automata for execution ifall of them are eligible. Since the component executesonly once - unlike with the OR semantics - we allowsending out only one event.

7.2. Analysis using timed automata

We model each invocation unit on these call chainsby a timed automaton. In this example - assuming ORsemantics for receiving the events - we will have a net-work of 6 timed automata representing the 4 compo-nents. The event-flow corresponds to Figure 7. Thetime-driven invocation units will be represented as asingle timed automaton while the event-driven invoca-tion units will be represented by two concurrently ex-ecuting timed automata.

Figure 9 shows the Uppaal models for the exampleapplication shown on Figure 5. These models extendthe generic model of the invocation unit introduced insection 6.

7.3. Verification

In the previous sections we have shown how tomodel the non-preemptive scheduling of component-based real-time CORBA applications. The timed prop-erties of the model can be checked by the Uppaal ver-ification tool. Uppaal uses a subset of the Computa-tional Tree Logic (CTL) [5] temporal logic to formalizestatements about the system models. Note that modelchecking is a formal proof that the model satisfies thedesired properties.

To show that the system is correct we checked thatthe system is deadlock-free by using the following Up-paal macro:

A[] not deadlock

We also need to show that all invocation unitsmeet their deadlines. We claim that this requiresno additional checking of properties. We have setthe frameOverrun location to be committed to re-duce the state space. However, we also introduceda nice side-effect in the system using this con-straint. Whenever a timed automaton reaches theframeOverrun location time cannot pass in that au-tomaton. Since we cannot leave that location, thiswill deadlock the system. If the above reachabil-ity macro evaluates to true, we have proved that thereare no deadlocks in the system and every action al-ways finishes the execution before the deadline. We alsoprove that every published event is properly con-sumed in the system and the event channels operatewith limited buffer size.

In the previous section we have described a systemwith correct deadlines. Figure 10 shows a slightly dif-ferent scenario in which we set the deadline of theAIRFRAME component to 32 ms. The deadlock is de-

tected and a short trace is produced automatically byUppaal. The simulation runs help us finding the causeof the frame overrun by simulating the execution tracethat lead to the fault.

Figure 10. Detected deadlock with the shortesttrace

Additional timed properties can also be checked be-cause all the time and dependencies are captured inthe models. We claim that our verification can be usedto verify the correctness of non-preemptive schedulingand pinpoint components that have frame overrun con-ditions. Our results show that the deadline is not thefunction of the period and using slower Timers mayproduce the same properties in the system allowingbetter resource allocation and performance gain.

7.4. Performance

The example used in the case study turned out to beanalyzable and correct. In order to find the limitationson the size of analyzable systems we have carried out aseries of performance tests on a hyperthreaded machinewith a 3.4GHz Pentium 4 processor and 1GB RAM. Weused the generic timed automata model shown on Fig-ure 4. We have assigned 1 unit of time as WCET to allautomata and we allowed non-deterministic schedul-ing between the automata to increase the state space.This simple system was introduced solely to measurethe performance. We checked the system for deadlockusing the methods shown in section 7.3.

In the first series of tests we verified applications inwhich the event flow can be represented as a balancedtree. This case turned out to be exponential propor-

Figure 9. The network of timed automata for the Bold Stroke apllication shown on Figure 5

tional to the number of components. Then we havebuilt a simple path of components consisiting of a sin-gle action that publishes to only one component. Thissystem was easily analyzable (it took less than one sec-ond) even for 63 components. Our results show that ifwe limit non-determinism and the branching of eventpaths the system will be simpler to analyze. As part ofout future work we would like to conduct research onhow to speed up the verification process.

8. Related work

The DARPA MoBIES (Model-Based Integration ofEmbedded Systems) program - started in 2000 - fo-cuses on integrating physical application domains withmodel-based design, composition and analysis of em-bedded software. The key objectives are to increasedependability, productivity while reducing the costs ofdevelopment and analysis of automatically generatedembedded system software. These objectives drive thedevelopment of domain-specific embedded software de-sign tools to the target environment that allow the evo-lution of correct-by-construction code generation tech-nologies. Within the context of the MoBIES program,researchers from multiple institutions have been work-ing together to produce an end-to-end tool-chain withthe Boeing Bold Stroke DRE architecture as the mainapplication domain. Results of the research on BoldStroke scheduling and verification are the AIRES, Ca-dena and Time Weaver - TimeWiz R© tools.

The AIRES tool extracts system-level depen-dency information from the application models, in-cluding event- and invocation-dependencies, and con-structs port- and component-level dependency graphs.Various polynomial-time analysis tasks are sup-ported such as checking for dependency cycles as wellas forward/backward slicing to isolate relevant com-ponents [14]. It performs real-time analysis [15] usingRate Monotonic Analysis techniques [23].

The Cadena [18] framework is an integrated envi-ronment for building and analyzing CORBA Compo-nent Model (CCM) based systems. Its main function-alities include CCM code generation in Java, depen-dency analysis and model-checking with dSPIN [9], anextension of the SPIN model-checker [20]. The empha-sis of verification in Cadena is on software logical prop-erties. The generated transition system does not repre-sent time explicitly and requires the modeling of logi-cal time that does not allow quantitative reasoning.

Time Weaver (Geodesic) [8] is a component-basedframework that supports the reusability of componentsacross systems with different para-functional require-ments. It supports code generation as well as auto-

mated analysis. It builds a response chain model [23]of the system to verify timing properties. This model isused by real-time analysis tools such as the TimeWiz R©model-checker to build a task set that can be analyzedwith Rate-Monotonic Analysis techniques.

Several authors [4] [11] [3] [13] [16] [12] have pro-posed the use of model checking techniques and toolsfor dynamics analysis of real-time computation sys-tems. The underlying models are variants of the timedautomata model. Early work on this approach has beenreported in [6] which uses the HyTech tool to ana-lyze multi-tasking programs. A generic form to ana-lyze scheduling behavior based on the timed automatamodel was proposed in [13] for single processor schedul-ing using the Immediate Ceiling Priority protocol andthe Earliest Deadline First algorithm.

9. Conclusion and future directions

This paper presents a solution that capturesthe event-driven nature of component-based real-timeCORBA applications that use the publisher/subscribercommunication pattern. This approach captures the re-active behavior as well as the non-determinism presentin these systems and demonstrates that timed au-tomata can represent component interactions andasynchronous event passing allowing the verificationof quantitative dense time properties. The verifica-tion process can provide simulation runs and pinpointcomponents that fail to meet deadlines and cap-tures the propagation of failures in the system. Thisapproach allows finding the “bottlenecks” in the sys-tem that limit the performance of the verified sys-tem.

Our solution has been implemented using theGReAT graph transformation tool that allows auto-matic verification of the system models by providing atool-chain to the Uppaal model checker. As the per-formance tests show the state space explosion prob-lem can be managed by restricting the branching ofthe event flow between components. As part of our fu-ture work we would like to include the modeling ofpreemptive scheduling in the models as well as the ver-ification of dynamic scheduling algorithms. In orderto keep the models analyzable we want to exam-ine how to decrease the complexity of the verifica-tion.

References

[1] A. Agrawal, G. Karsai, and A. Ledeczi. An End-to-End Domain-Driven Development Framework. In Pro-ceedings of the 18th Annual ACM SIGPLAN Conference

on Object-Oriented Programming, Systems, Languages,and Applications (OOPSLA), Oct 2003.

[2] R.Alur andD.L.Dill. A theory of timedautomata. The-oretical Computer Science, 126(2):183–235, 1994.

[3] V. A. Braberman and M. Felder. Verification of Real-Time Designs: Combining Scheduling Theory with Au-tomatic Formal Verification. In Software Engineering-ESEC/FSE 99, pages 494–510, 1999.

[4] S.Bradley,W.Henderson, andD.Kendall. UsingTimedAutomata for Response Time Analysis of DistributedReal-Time Systems . In 24th IFAC/IFIP Workshopon Real-Time Programming WRTP 99, pages 143–148,1999.

[5] E. Clarke and E. Emerson. Design and synthesis of syn-chronisation skeletons using branching time temporallogic. Logic of Programs, LectureNotes inComputer Sci-ence, 131:52–71, 1981.

[6] J. Corbett. Timing Analysis of Ada Tasking Programs.IEEE Transactions on Software Engineering, 22:1–23,1996.

[7] C. Daws, A. Olivero, S. Tripakis, and S. Yovine. Thetool KRONOS. InProceedings of the DIMACS/SYCONworkshop on Hybrid systems III : verification and con-trol, pages 208–219. Springer-Verlag New York, Inc.,1996.

[8] D. de Niz and R. Rajkumar. Time Weaver: A Software-Through-Models Framework for Real-Time Systems. InProceedings of LCTES, 2003.

[9] C. Demartini, R. Iosif, and R. Sisto. dSPIN: A DynamicExtension of SPIN. In Proceedings of the 5th and 6th In-ternational SPIN Workshops on Theoretical and Prac-tical Aspects of SPIN Model Checking, pages 261–276.Springer-Verlag, 1999.

[10] M. Deshpande, D. C. Schmidt, C. O’Ryan, and D. Brun-sch. Design and Performance of Asynchronous MethodHandling for CORBA. In Proceedings of DistributedObjects and Applications (DOA), October/November2002.

[11] C. Ericsson, A. Wall, and W. Yi. Timed Automata asTask Models for Event-Driven Systems. In Proceedingsof RTSCA ’99, 1999.

[12] A. Fehnker. Scheduling a Steel Plant with Timed Au-tomata. InSixth InternationalConference onReal-TimeComputing Systems and Applications (RTCSA’99).IEEE Computer Society Press, 1999.

[13] T. Gerdsmeier and R. Cardell-Oliver. Analysis ofScheduling Behaviour using Generic Timed Automata.42, 2001.

[14] Z. Gu, S. Kodase, S. Wang, and K. G. Shin. A Model-BasedApproach toSystem-LevelDependencyandReal-Time Analysis of Embedded Software. In Proceedings ofReal-Time Applications Synopsium, 2003.

[15] Z. Gu, S. Wang, S. Kodase, and K. G. Shin. An End-to-End Tool Chain for Multi-View Modeling and Analysisof Avionics Mission Computing Software. In Proceed-ings of Real-Time Systems Synopsium, 2003.

[16] L. Halkjaer, K. Haervig, and A. Ingolfsdottir. Verifica-tion of the legOS Scheduler using Uppaal. In F. Corra-dini and P. Inverardi, editors, Electronic Notes in Theo-retical Computer Science, volume 39. Elsevier, 2000.

[17] T. H. Harrison, D. L. Levine, and D. C. Schmidt. TheDesign and Performance of a Real-Time CORBA EventService. In Proceedings of the 12th ACM SIGPLAN con-ference on Object-oriented programming, systems, lan-guages, and applications, pages 184–200. ACM Press,1997.

[18] J. Hatcliff, X. Deng, M. B. Dwyer, G. Jung, and V. P.Ranganath. Cadena:AnIntegratedDevelopment,Anal-ysis, and Verification Environment for Component-based Systems. In Proceedings of International Confer-ence on Software Engineering, 2003.

[19] T.A.Henzinger,P.-H.Ho, andH.Wong-Toi. HYTECH:A Model Checker for Hybrid Systems. InternationalJournal on Software Tools for Technology Transfer, 1(1–2):110–122, 1997.

[20] G. J. Holzmann. The SPIN model checker: Primer andreference manual. Addison Wesley, 2004. HOL g 03:11.Ex.

[21] J.Rumbaugh, I. Jacobson, and G. Booch. The UnifiedModeling Language Reference Manual. 1998.

[22] G. Karsai, S. Neema, A. Bakay, A. Ledeczi, F. Shi, andA. Gokhale. A Model-based Front-end to TAO/ACE.In Proceedings of the 2nd Workshop on TAO, 2002.

[23] M. H. Klein, T. Ralya, B. Pollak, and R. Obenza. APractitioners’ Handbook for Real-Time Analysis: Guideto Rate Monotonic Analysis for Real-Time Systems.Kluwer Academic Publishers, 1993.

[24] K. G. Larsen, P. Pettersson, and W. Yi. Uppaal in aNutshell. Int. Journal on Software Tools for TechnologyTransfer, 1(1–2):134–152, Oct. 1997.

[25] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nord-strom, and J. Sprinkle. ComposingDomain-SpecificDe-sign Environments. Computer, pages 44–51, Nov 2001.

[26] Object Management Group. Common Object RequestBroker Architecture (CORBA/IIOP). 2002.

[27] Object Management Group. CORBA ComponentModel. 2002.

[28] P. Pettersson and K. G. Larsen. Uppaal2k. Bulletin ofthe European Association for Theoretical Computer Sci-ence, 70:40–44, feb 2000.

[29] D. C. Schmidt, A. Gokhale, T. H. Harrison, andG. Parulkar. A High-Performance Endsystem Archi-tecture for Real-Time CORBA. IEEE CommunicationsMagazine, 14(2), 1997.

[30] D. C. Sharp and W. C. Roll. Model-Based Integrationof Reusable Component-Based Avionics Systems. InProceedings of the Workshop on Model-Driven Embed-ded Systems in RTAS 2003, May 2003.

[31] S.Tripakis andC.Courcoubetis. ExtendingPROMELAand SPIN for Real Time. In Proceedings of TACAS ’96,LNCS 1055, 1996.