Modeling and Validation of a SoftwareArchitecture for the Ariane-5 Launcher�

Iulian Ober1, Susanne Graf2, and David Lesens3

1 Toulouse University, GRIMM/ISYCOM laboratory��

IUT-B 1 pl. Brassens BP 73, 31703 Blagnac, Franceiulian.ober@imag.fr

2 VERIMAG2, av. de Vignate, 38610 Gieres, France

susanne.graf@imag.fr3 EADS SPACE Transportation

66, route de Verneuil - BP 3002, 78133 Les Mureaux Cedex - Francedavid.lesens@space.eads.net

Abstract. We present the modeling and validation experimentsperformed with the IFx validation toolset and with the UML profiledeveloped within the IST Omega project, on a representative space ve-hicle control system: a model of the Ariane-5 flight software obtainedby manual reverse engineering. The goal of the study is to verify func-tional and scheduling-related requirements under different task architec-ture assumptions. The study is also a proof of concept for the UML-basedvalidation technique proposed in IFx.

1 Introduction

Model-driven engineering is making its way through the habits of software de-signers and developers, pushed forward by the increasing maturity of modelinglanguages and tools. This paradigm promotes a complete re-foundation of soft-ware engineering activities on the basis of models, as well as the use of automatictools for most post-design activities. In this context, the software model is thecentral artifact which gathers different aspects ranging from the requirements tosoftware architecture, to component behavior, etc.

More recently, the trend is extending beyond software development activities,to system design. For this activity, which traditionally employed rather ad-hocmodels, the community is currently seeking new formalisms, like SysML [19] orarchitecture description languages (ADLs). In the end, this adds new aspects(environment, hardware architecture, process and thread mappings, etc.) to thecentral artifact which becomes the system model.

The use of such heterogeneous models is justified by the complexity of currentsystems which have to satisfy tightly interwoven functional and non-functionalrequirements.� This work has been partially financed by the OMEGA IST project.

�� Work performed while at VERIMAG.

R. Gorrieri and H. Wehrheim (Eds.): FMOODS 2006, LNCS 4037, pp. 48–62, 2006.c© IFIP International Federation for Information Processing 2006

Modeling and Validation of a Software Architecture 49

In this paper we discuss the case of such a complex system, the control soft-ware of the Ariane-5 launcher, which is typical for the space vehicle controldomain. Applications in this field typically involve a time driven part which im-plements the attitude and orbit control loop, and an asynchronous, event drivenpart, which performs mission management tasks. The different sub-systems shareresources like busses and other spacecraft equipment.

The current practice, which consists in using cyclic sampling of asynchronousevents and a Rate Monotonic Scheduling (RMS) policy [17], offers static crite-ria for deciding schedulability, and can offer correctness by construction (undersome additional hypotheses) for other properties like exclusive access to sharedresources. However, this policy proves to be very inflexible under demandingreactivity constraints or under processor overloads.

Consequently, more dynamic solutions are sought by system designers, like us-ing fixed priority preemptive scheduling outside the sufficient (but not necessary)schedulability conditions of RMS. Such solutions rely on automatic verificationmethods, which have to take into account some functional aspects of the system.

In this paper, we describe a study in which the Omega UML profile [5, 10](defined within the IST Omega project1) is used for modeling both functionaland architectural aspects of a representative subset of the Ariane-5 system. Wediscuss the verification of both functional and scheduling-related requirementswith the IFx toolset [18] which implements the profile.

1.1 A Short Introduction to Omega UML and the IFx Tool

Omega UML is a profile targeting the design of real-time systems. The profilesupports a large subset of the operational concepts of UML: classes, with mostof their relationships (associations, composition, generalization), features (at-tributes, operations) and behavior descriptions (state machines). Actions, whichare used to describe the effect of operations and of state machine transitions,are written in a syntax compliant with the UML action semantics. The languagecontains imperative constructs like assignments, operation calls, object creation,signal exchange, etc.

The description of concurrent systems is supported by means of active classes.Instances of active classes define a partition of the object space into activitygroups, each group having its own thread of control, and functioning in run-to-completion steps. Communication is possible inside or between groups, byexchanging asynchronous signals and by calling operations. The execution modelis an extension of the semantics implemented by the Rhapsody UML tool.

Detailed descriptions of Omega UML execution model can be found in [5].On top of the concepts mentioned above, the Omega profile also defines a set oftime-related constructs [10].

IFx2 [18] is a toolset providing simulation and model-checking functionalitiesfor Omega UML models. It is built on top of the IF environment [4], and provides

1 http://www-omega.imag.fr2 http://www-if.imag.fr/IFx

50 I. Ober, S. Graf, and D. Lesens

a compiler of UML models to IF specifications. Models may be edited with anyXMI-compatible editor3.

Model checking is based on efficient forward state-space exploration methodsfor timed automata. Timed safety properties may be expressed as observers,which are described in the sequel. Generated diagnostic traces can be analyzedby simulation. In order to scale to complex models, IF supports optimization andabstraction in several ways: by “exact” static optimizations (like dead variablefactorization and dead code elimination), by partial-order reduction, by dataabstraction (static slicing). More details can be found in [18].

2 The Ariane-5 Software

The Ariane-5 flight software controls the launcher’s mission from lift-off to pay-load release. It operates in a completely autonomous mode and has to handleboth external disturbances (e.g. wind) and different hardware failures that mayoccur during the flight.

This case study takes into account the most relevant points required forsuch an embedded application and focuses on the real time critical behavior byabstracting from complex functionality (like control algorithms) and implemen-tation details, such as specific hardware and operating system dependencies.Nevertheless, it is fully representative of an operational space system. The typi-cal characteristic of such systems is that they implement two kinds of behavior:

– Cyclic synchronous algorithms. These are principally the control/commandalgorithms (in the sequel they are called GNC for Guidance, Navigation andControl). The algorithms and their reactivity constraints are defined by thecontrol engineers based on discretization of continuous physical laws.

– Aperiodic, event driven algorithms. These algorithms manage the missionphases and perform particular tasks when the spacecraft changes from onepermanent mode to another (engine ignition and stop, stage release, etc.),or when hardware failures occur (alternative or abortion manoeuvres).

The software components implementing this functionality are physically de-ployed on a single processor4 and share a common bus for acquiring sensor dataand sending commands to the equipment.

The proof of correctness of the mission management components can be madeby (almost completely) abstracting from the control algorithms. In an earlierexperiment, we have used an SDL model of the mission management in order toverify this kind of properties [3].

The correctness of control algorithms concerns two issues: their numericalcomputation, and their concurrency behavior. The numerical correctness is notconsidered here. For the concurrency, the proof of correctness is usually doneusing the synchrony hypothesis. The synchronous approach makes verification3 Rational Rose and I-Logix Rhapsody have been tested used in the OMEGA project.4 In fact, a set of replicated processors, but this is out of the scope of our case study.

Modeling and Validation of a Software Architecture 51

using a non-timed semantics much simpler. The non-timed semantics just as-sumes that all entries are available when the computation cycle starts and theresults of the computation are made available at the end of each cycle. Thereexist results stating sufficient conditions under which such a synchronous designcan be implemented in a distributed and/or multi-threaded environment [20].However, in this case study the sufficient conditions do not hold in all cases, andthe satisfaction of the synchrony hypothesis must be verified.

Therefore, in this case study we have considered more particularly the problemof verifying that a low-level software architecture (a task model), together witha set of other non-functional assumptions (worst case execution times, arrivalmodel), satisfy the reactivity constraints imposed on the software and ensurethe synchrony hypothesis for the cyclic algorithms.

The current practice for ensuring such non-functional constraints consistsin using an RMS-based scheduler. Asynchronous events are sampled with thefrequency of the smallest cycle. The schedulability of this architecture can bedecided statically, under the assumption that relevant values for WCET of taskscan be provided. Moreover, in the current solution, the exchange of data betweenthe different tasks or between a functional task and the bus are allowed only inpredefined time slots at the beginning and at the end of each task’s cycle (evenif the computation finishes earlier in the cycle). Consequently, mutual exclusionbetween writes in the exchange memory is satisfied by construction, and withno possibility for priority inversion.

On the other hand, this architecture is very inflexible in the followingcircumstances:

– when some acyclic events need shorter reaction time than the basic cycle(which is in fact the case for the Ariane-5 system),

– when some cyclic algorithm needs more recent measurement data, that hasto be acquired during the cycle (also the case in the Ariane-5 system),

– when an algorithm needs a longer time than the pre-assigned slot, for in-stance in case of high CPU load (this feature, not required today, will becomemandatory for future highly autonomous space systems).

In the case of Ariane-5, the software designers have used a more flexible archi-tecture, which is still based on fixed priority preemptive scheduling, but whichviolates some of the RMS assumptions mentioned above in order to ensure bet-ter reactivity (reads and writes during the cycle, triggering of asynchronous codeduring a cycle). Nevertheless, such an architecture has to be formally validatedwith respect to the non-functional requirements concerning timing, schedulingand mutual exclusion. This is the main objective of our case study.

3 The Verification Model

The UML model used for verification has been built manually from the exist-ing software code, by a team from EADS Space Transportation. Its functional

52 I. Ober, S. Graf, and D. Lesens

decomposition is independent of the task architecture; it is structured around6 objects implementing the main categories of functionality, each defined by asingleton active class. They are:

– Acyclic: the main mission management object, which handles the start of theflight sequence and the switching from one phase to another. Its behavioris described by a state machine reacting to event receptions from the GNCalgorithms (e.g., end of thrust detection) or from the environment, and totime conditions (e.g., time window protections ensuring that the treatmentassociated to an external event is performed within a predefined time windoweven in case of failure of the event detection mechanism).

– A set of specific objects which handle the acyclic management activitiesrelated to a particular launcher stage. They react to events received fromAcyclic or to internal time constraints. In the study, we considered onlytwo stages: EAP (lateral booster) and EPC (main stage of the Ariane 5launcher).

– Cyclics: This object manages the activation of the cyclic control/commandalgorithms (GNC). The algorithms are executed in a predefined order, de-pending on the current state of the launcher, which is tracked by the Acyclicclass. Its state machine appears in an example later on in Fig. 3. We considerin more detail two of the algorithms activated by Cyclics, each implementedby a separate object: Thrust Monitor, responsible for the monitoring of theEAP thrust, and Guidance Task, which has the particularity that its acti-vation frequency is lower than that of the other GNC algorithms.

In order to validate the software, a part of the environment needs to bemodeled. In our case, it includes two kinds of spacecraft equipment – Valvesand Pyrotechnic commands (the model includes possible hardware failures), theexternal environment – namely the ground control centre, as well as abstractionsof parts of the software which are not described in the model (such as: a numericalalgorithm or the 1553MIL bus allowing the communication between the mainsoftware and the equipment).

3.1 Capturing Functional and Timing Requirements

Using Omega UML, requirements can be formalized by means of observers, andverified against the design model. In this section, we discuss briefly the conceptsand we give an example of how they are put to work in the Ariane-5 model.More detail on observers can be found in [18].

Observers are special objects which monitor the execution of the model andgive verdicts when a requirement is satisfied or violated. Observers may havetheir own local memory (attributes), and their behavior is described by a statemachine, in which some states are labeled with the stereotypes <<success>>or <<error>> providing verdicts. The monitoring of model execution is doneby observing events like signal outputs, operation calls or returns, state changes,

Modeling and Validation of a Software Architecture 53

etc., or by observing the state of the system, like attribute values, contents ofqueues, states of the state machines, etc. 5

We take for example the following property:

Property P1. The launcher shall not lift-off if an anomaly is detected duringthe Vulcain engine ignition. In case of lift-off abort, the valves shall all be closedwithin 2 seconds and the pyrotechnic commands shall not be ignited.

An anomaly on the Vulcain ignition corresponds, in our modeling of the en-vironment, to a Valve object entering the Failed Open state. This failure shallbe detected by the software, which shall then abort the lift-off and secure thelauncher. Thus, this property is expressed more precisely as follows:If any instance of the Valve class enters one of the states Failed Open orFailed Close, then:

– All the instances of the Pyro class shall never enter the state Ignition done.– 2 seconds after the valve failure, all instances of the Valve class shall be in

state Close or Failed Close, and then remain in this state forever.

This property is based on a pure black-box view of the software. Neverthe-less, since several components are involved in aborting the lift-off, the designershave completed the property with the requirement that the internal events Re-quest EAP Preparation and Request EAP Release are never emitted.

Fig. 1 shows how this property can be expressed using a timed observer: eachtime an Open command is received by some valve v, the observer tests whetherv reaches the state Failed Open.

If this premise holds, the observer enters state aborted, in which Pyro ob-jects entering state Ignition done, as well as emissions of the signals Re-quest EAP Preparation and Request EAP Release are prohibited. After 2 secondsfrom entering state aborting, the observer goes to the inner state aborted in which,additionally, Valves entering the state Open or Failed Open are also prohibited.

Note that the testing of the premise done by the observer corresponds tothe universal quantification appearing textually in the premise of the propertyP1 (“any instance of the Valve class”). Such a universal quantification wouldalso have to be used in a state logic formula, had we used a temporal logic forformalizing the properties. However, to the best of our knowledge, no majormodel checking tool based on LTL or CTL supports directly this kind of firstorder logic in the specification of state formulas. For example, in UPPAAL [14],the same property could be expressed either by using a helper (observer) au-tomaton which synchronizes with any Valve entering Ignition done, or by usingquantifier elimination (that only works under the restriction that the set of ob-jects is known in advance – which is generally not true in Omega UML or IF

5 A formal discussion of the expressivity of observers is out of scope. We note that: (1)observers are used to express linear timed safety properties, which may combine stateor event-based atomic propositions, and (2) observers embed general algorithms,therefore their termination (hence also their satisfaction) is undecidable in general.For practical applications, we do not view this as a limitation.

54 I. Ober, S. Graf, and D. Lesens

ok

aborting

aborted

not_yet

aborted

not_yet

/ t.set(0)

[ t >= 2000 ]

ko<<error>>

match accept ::EADS::Environment::Valves::Open() by v

[ v @ Open ][ v @ Failed_Open ]

[ v.EPC.EAP.Pyro1 @ Ignition_done orv.EPC.EAP.Pyro2 @ Ignition_done orv.EPC.EAP.Pyro3 @ Ignition_done ]

match send ::EADS::Signals::Request_EAP_Preparation()

match send ::EADS::Signals::Request_EAP_Release()

[ (v.EPC.EVBO @ Open or v.EPC.EVBO @ Failed_Open) or(v.EPC.EVVCH @ Open or v.EPC.EVVCH @ Failed_Open) or(v.EPC.EVVCO @ Open or v.EPC.EVVCO @ Failed_Open) or(v.EPC.EVVGH @ Open or v.EPC.EVVGH @ Failed_Open) or

(v.EPC.EVVP @ Open or v.EPC.EVVP @ Failed_Open) ]

liftoff_aborted_right

v : Valvet : Timer

<<Observer>>

Fig. 1. Property p1

specifications). This supports our claim that observers are a flexible formalismfor expressing common event or state-related timed safety properties.

Consider another property, required by electrical constraints on the hardware:

Property P2. The software shall not send two Open commands to the samevalve at less than 50ms of interval.

P2 constrains the distance between pairs of events concerning a same instance ofclass Valve. The particularity of this property is that it concerns any consecutivepair in the series of commands sent by the software to a (any) Valve. This kindof property is typically easier to specify with a temporal logic.

Nevertheless, we show in Fig. 2 an observer which uses non-determinism topick each particular occurrence of an event pair at a time and either verify thetime distance, or skip to the next one (as the model checker explores all alterna-tives, all pairs are eventually verified)6. In state initial, the observer waits for acommand to be sent to any Valve, stores the reference of the concerned Valve inv1 and proceeds to state nondet. (This behavior ensures universal quantificationover the set of valves, in the same way as in P1). In state nondet, it choosesnon-deterministically whether to proceed by verifying the timing of the nextcommand sent to the same valve, or to return to initial and wait for anothercommand to (any) Valve.

The rest of the observer tests a simple timed safety condition: the next com-mand sent to the Valve v1 does not come before 50ms. The clock t is used to

6 The observer presented here is not optimal in the required verification time/memory.

Modeling and Validation of a Software Architecture 55

valve_not_abused

t : Timer

v1 : Valve

v2 : Valve

<<Observer>> initial

wait

KO<<error>>

nondet

OK<<success>>

match invoke ::EADS::Environment::Valve::Open() on v1[ true ]

[ true ] / t.set(0)

[ t >= 50 ] / t.reset()

match invoke ::EADS::Environment::Valve::Open() on v2[ v1 <> v2 ][ v1 = v2 ]

Fig. 2. Property p2

measure 50ms. In state wait, other commands may come, but they cause anerror only if they concern the valve v1. If more than 50ms elapse without error,the observer reaches a success state and considers the property verified for thisparticular events occurrence pair.

Stereotyping the OK state with <<success>> allows also to make modelchecking more efficient: after the observer has reached OK, the execution ofthe (system, observer) pair cannot lead to KO anymore, and may safely beignored.

3.2 Scheduling Constraints and Objectives

As mentioned before, the main focus in this study is on validating a particu-lar task architecture based on fixed priority preemptive scheduling, in order tocheck that is satisfies several conditions concerning schedulability and mutuallyexclusive access to the bus.

In the architecture that we consider, the hypotheses of RMS [17] are notsatisfied, as asynchronous events need to be handled as soon as they arrive.Another difficulty in using RMS-like schedulability decision criteria is that theexecution time of the cyclic tasks varies a lot depending on the current flightphase. Fig. 3 shows the state machine of the control cycle, on which we cansee that the worst case execution time of this cycle is around 64ms, while thebest case is 37ms and the average measured by simulation is around 42ms. Onecannot simply consider at each cycle the worst case execution time (of sporadicand cyclic tasks), as this would lead to a huge over-approximation of resourceoccupation and to the conclusion that the system is non schedulable. We alsorelax in some cases the requirement that reads and writes are done only in thebeginning and in the end of each task’s cycle. Therefore, the access to the busis not mutually exclusive by construction.

The technique we adopt for proving these constraints is to take into accountthe functional behavior of the system and its impact on resource consumption.

Assigning priority levels to activities. The priorities were assigned just as in theRMS solution from which we started, according to the relative responsivenessrequired from an activity. Three levels of priority are used:

56 I. Ober, S. Graf, and D. Lesens

BGY

SRI_Upstream_1

/ SRI.SRI_upstream()

EAP_Calculate_aiming

QDP_Calculate_aiming

SRI_Upstream_2

Control_Predict_state_vector SRI_Down

stream

Decide_EAP_Separation

Navigation_performed

Interpolation_performed

Calculate_attitude

EAP phase QDP phase

EAP phase

QDP phase

Start_Minor_Cycle

Guidance_ran

/ BGY.Perform_BGY()

[ fasvol<>2 ] / Control.Calculate_EAP_aiming() [ fasvol=2 ] / Control.Calculate_QDP_aiming()

/ Control.Predict_EAP_state_vector() / Control.Predict_QDP_state_vector() / SRI.SRI_downstream()

Synchro() / begin minor_cycle:=minor_cycle+1 end

/ Attitude.Calculate_Attitude()

[ fasvol=2 ] /Thrust_Monitor.Decide_EAP_Sepa

ration()

[ fasvol<>2 ]

[ minor_cycle<guidance_period ][ minor_cycle>=guidance_period ] / begin

minor_cycle:=0;Guidance_Task!Start_Guidance_cycle() end

/ Data_tables.Interpolate()

[ minor_cycle=6 ] / Navigation.Flight_Protection()

[ minor_cycle=2 ] / Navigation.Perform_Navigation()[ minor_cycle<>2 and minor_cycle<>6 ]

5ms

2ms

2ms

10ms

5ms

5ms 0..5ms

20ms10ms

5ms

10ms

Fig. 3. Statechart of the Control cycle with unitary execution times

– Functions of the Regulation components have highest priority. They are spo-radic and take about 2 to 5 ms each time a command is executed (open avalve, ignite a pyrotechnic command, etc.)

– Functions of the Navigation-Control components have medium priority. Theyare periodic, with a period of 72ms and take 37 to 64ms to execute dependingon the current phase of the flight and other parameters.

– Functions of the Guidance components have lowest priority. They executeevery 576ms. One of the goals of scheduling analysis was to determine howmuch processor time they can take in each cycle in order for the system toremain schedulable.

Activities that are on the same priority level are handled by the same runtimetask, that is without overlapping.

Modeling the task architecture in Omega UML. Scheduling policies and resourceconsumption can be modeled using the lower level constructs of the Omegaprofile: objects which manipulate clocks and do the resource bookkeeping. Inparallel with the Ariane-5 study, we developed a reusable model library for theIFx tool, which provides support for different types of schedulers.

The Scheduling library contains basically two kinds of classes organized intwo hierarchies:

– Task classes used to annotate the user model with requests for executiontime. Requests are parameterized with a duration, and depending on thescheduling policy, with information like priority, deadline, etc. Instances ofTask classes can be shared by several objects.

– Scheduler classes are used to model the different scheduling policies. Eachcreated Task has to be associated with a Scheduler. Subsequently, every timea Task requires processing time, it will communicate with its Scheduler inorder to determine the actual time of finish, based on the task duration and

Modeling and Validation of a Software Architecture 57

on the state of the Scheduler (i.e. the scheduling policy and the charge atthat moment).

For modeling the behavior of the fixed priority preemptive scheduler in timedautomata constructs, we use the scheme proposed in [9].

Scheduling objectives are modeled by observers. They are:

– The Navigation-Control (NC) functions must terminate within the 72mscycle and the Guidance functions within the 576ms cycle.For the NC functions, this property is formalized in the observer in Fig. 4, bythe fact that the Cyclics component receives the signal Synchro, which signi-fies the beginning of a cycle, only in the states Start Minor Cycle, Wait Startor Abort. If a cycle does not finish in time, the Cyclics component is in anintermediate computation state when the next Synchro is received and thisproperty is violated.The observer expressing the analogous property for the Guidance functionis similar.

– The application uses a 1553 MIL bus. In this protocol, all data transfersare performed under the supervision of a bus controller (the main on-boardcomputer in the case of the Ariane 5 case study). The software componentsread and write data in an exchange memory which is transferred via the busto the equipment (also called remote terminal) at specific time frames (thisprocess is called low-level transfer). The consistency condition for bus readsand writes is that the software components do not read or write the busduring the low-level transfer time frames. (calls to read and write operationsdo not occur while the Bus is in Transfer state).

wait

match send ::EADS::Signals::Synchro() to c

KO_NC_cycle_is_schedulable

<<error>>

[ c @ Start_Minor_Cycle or c@ Wait_Start or c @ Abort ]

[ not( c @ Start_Minor_Cycle or c@ Wait_Start or c @ Abort ) ]

Fig. 4. Scheduling objective: the control cycle finishes in time

4 Ariane-5 Verification Results

4.1 Validation Methodology

In the context of the IFx toolset, the validation of UML models means performingseveral activities, which range from simple syntactic and static semantic checkingto dynamic property verification, with the goal of improving the model andits conformance to its requirements. These activities are supported by differenttools. The standard workflow used also in this case study is summarized below7.7 A more detailed description can be found in [4].

58 I. Ober, S. Graf, and D. Lesens

1. The translation phase consists in invoking the uml2if compiler. Standardstatic checks are performed (name and type checks, checking of well formed-ness constraints).

2. The simplification phase consists in the application of static analysis andabstraction methods implemented in IF:– in the early validation phases we use mainly methods fully preserving

verification results (such as dead variable / dead code analysis and clockreduction)

– in the later phases (verification), we use in addition methods leadingto over approximations such as abstractions of variables or clocks, orrelaxation of urgency constraints.

3. The simulation phase consists in exploring the model by a mixture of interac-tive, guided and random simulation which allows usual debugging tasks likesaving and reloading a played scenario, stepping back and forward throughit, inspecting the system state, inserting conditional breakpoints, etc.

4. The model-checking phase is the main validation phase, in which the productspace of the relevant part of the model and of a set of observers is searchedfor absence of error states, while avoiding the parts of the graph reachableonly via success states.In this phase, there are 2 possibilities for handling time: discrete or symbolic.With discrete time, time progress is represented by a tick transition commonto all processes, and this representation allows the use of more expressivetime constraints. In case of the symbolic representation of time, a DBM isassociated with each system state, like in the timed-automata based toolsKronos [22] and Uppaal [14]. The symbolic representation leads in mostexamples to much smaller state spaces.

5. the IF toolset implements a number of other verification techniques. Themost interesting ones are comparison of models and minimization of modelswith respect to simulations and bisimulations. Minimization has been usedin our case study to extract most general properties with respect to anobservation criterion, given by a set of observable events (see in [3, 4]).

4.2 State Explosion and Use of Abstractions in Ariane-5

The duration of a basic cycle of the cyclic behavior of the Ariane-5 flight soft-ware is 72 ms. Each basic cycle contains several hundreds of steps. As theacyclic behavior uses some timers also to measure long durations, when com-posed with the cyclic behavior, every state reached through these steps is a newglobal system state. This quickly leads to an explosion, especially in the case ofAriane-5, where the footprint of a system state is quite large (see also §4.3).

In order to cope with the complexity of the model, we had to apply moreevolved abstraction and reduction techniques which need a good understand-ing of both the functioning of the system and the verification and abstractiontechnology.

Modeling and Validation of a Software Architecture 59

Compositional Abstraction. We have applied this well known technique whichconsists in the verification of properties of a subsystem, by replacing the otherparts of the system — which play here the role of an environment — by asimpler descriptions representing an abstraction. The variable abstractions im-plemented in IF were not sufficient for the Ariane-5 model and we have builtmanual abstractions, which were still relatively simple, by using the existing de-composition of the system into a cyclic and an acyclic part and the clear interfacebetween them.

To illustrate this, we take the example of the safety properties related only tothe acyclic part (flight program and error handling). To prove their correctness,the cyclic GNC part has been abstracted by eliminating all the internal behaviorand by sending messages (flight phase change commands) at arbitrary momentsrather than at the precise time points computed by the concrete GNC. Thisrepresents clearly an abstraction and it was sufficient to show the satisfaction ofall the properties of the asynchronous part (see [18, 3] for an older experienceconcerning this part). Note also that such an abstraction can in principle beconstructed automatically.

Reduction of the duration of the flight phases. In order to validate the propertiesrelated to schedulability and concurrent bus access, we have used an alternativereduction without behavioral abstraction. As mentioned before, a huge sourceof state explosion is the difference of the time scale between the asynchronousand the cyclic behavior.

Asynchronous events are rare, and the system is working without occurrenceof any asynchronous events during a large number of basic cycles (called stablephases). Moreover, most of the output of the cyclic part is irrelevant for thetiming properties to be verified. Thus, it is sufficient to perform the proof on afunctional abstraction of the cyclic part with a mission duration much greaterthan the basic cycle, but much shorter than the real mission duration.

In stable phases, all executions of the basic cycle in the cyclic part are identicalwith respect to the properties to be verified, in particular to the schedulabilityof all tasks in all relevant cycles, and to the observation of a certain time windowfor the commands sent from the synchronous to the asynchronous part (stablephases are outside this time window).

This suggests that it is sufficient to verify a reduced model, obtained by adrastic reduction of the overall flight duration, being careful to make sure thatonly stable phases are shortened, whereas all the critical transition phases arefully explored. The transition phases are defined by the flight phases defined inthe acyclic part and by the occurrence of exception events. Exception events canoccur at any time, but the correctness of the software must only be guaranteed for2 exceptions for the entire flight, which means that it is enough to make the stablephases long enough to allow the occurrence of 2 exceptions with subsequentstabilization.

Using such a reduction of the real duration of the mission, the reachable statespace for the entire flight could be explored, and all the properties could befinally validated.

60 I. Ober, S. Graf, and D. Lesens

4.3 Results and Figures

In this section, we show the efficiency of the applied reductions. The table inFig. 5 shows the verification time and the cardinality of the state space, usingdead variable and partial order reductions, while using different mission dura-tions (but always respecting the required stabilization times).

Mission duration Nr of states Nr of transitions Verif. time (min)7 s 51 324 54 697 03:3015 s 161 956 171 734 12:0622 s 303 496 321 206 11:3330 s 463 932 490 901 22:5837 s 658 981 696 031 34:53

Fig. 5. Complexity for different mission durations (all properties combined)

For the comparison, we have used a model with all the properties (observers)enabled simultaneously. There is no state explosion caused by the parallel com-position of all properties, since properties are not completely independent.

A discussion is necessary as the figures presented here may seem low comparedto other known examples in explicit state or symbolic model checking, whichrange beyond 107 states. One must consider the following:

– The Ariane-5 model (after UML translation) consists of 77 types of IF pro-cesses, each having (many) variables of complex types, and sometimes havingdynamically created instances. The footprint of the system state is slightlyvariable, with an average of 10KB.In our view, one cannot compare the 106 order of magnitude of Ariane-5(for the largest exploration, shown in Fig. 5), with results obtained on othersystems, which may have higher combinatorics but smaller footprints. It isunfortunately impossible to propose this model as a basis for benchmarking,due to confidentiality reasons related to its industrial nature.

– Given that the (approximately) 6GB of Ariane’s 658981 states have beenexplored on a machine with only 1GB of RAM, we see this as evidence ofthe efficiency of the sharing algorithms [4] of the IF exploration platform.

– Another characteristics of the state spaces obtained here is that they arevery narrow and deep (almost a vertical string). This is not because theexample is sequential by nature: concurrency is present in this model andthe combinatorics is potentially very big. The linear form of the state spacesindicates the efficiency of the partial order reduction of the IF platform.

5 Comparison to Other Approaches, Discussion andFuture Work

Discussion of related work. There exist already a number of tools proposed forthe validation of UML models by translating a subset of UML into the input

Modeling and Validation of a Software Architecture 61

language of some existing validation tool [16, 15, 13, 7, 21, 6, 2, 1] to mention onlya some of the relevant work in the context of real-time and embedded systems.

Like IFx, most of these tools are based on existing model-checkers such asSPIN [12] (in [16, 15]) or COSPAN [11] (in [21] for non-timed systems, andKronos [22] (in [2]) or Uppaal [14] (in [13, 6]) for the verification of systems withtiming constraints. Also the translation into proof-based frameworks, such asPVS (e.g. in [1]) or B, has been proposed.

With respect to the expressivity of the UML profile accepted, the IFx frame-work goes beyond other existing ones, as it handles a rich subset of UML, includ-ing inheritance and dynamic object creation and powerful timing features. Mostof the cited UML validation tools are restricted to static systems, fitting exactlythe model of the underlying model-checker. Also, they usually handle propertieswritten in the property language proposed by the underlying model-checker. TheOmega UML profile proposes observers for this purpose.

The IFx tool does not push forward the theoretical boundaries of existing veri-fication technology. However, the tool presents a unique combination of featureswhich prove to be very efficient in fighting scalability problems encounteredin practice. It includes and combines the on-the-fly exploration of SPIN, thesymbolic representation of time constraints of Kronos and Uppaal, the bisimula-tion based reduction techniques of Aldebaran [8], and adds verification-targetedoptimizations based on static analysis, as well as support for industry-backedstandards like SDL and UML.

Experience showed that the combination of these techniques allows to obtainfeedback very rapidly on most models without much remodeling and adaptationeffort by the user. Positive verification results required, for the bigger examples,some effort to find an appropriate property preserving abstraction and to applyit manually – which is a common limitation of major model-checking tools.

The model structuring concepts present in IF allow to limit the overheadinduced by the translation a rich user level formalism like UML, and also makethe translation more flexible. Consequently, we plan on moving towards UML2.0 and to system-oriented formalisms like AADL, which are better suited formodeling architectural and non-functional problems in the space vehicle controldomain.

References

[1] T. Arons, J. Hooman, H. Kugler, A. Pnueli, and M. van der Zwaag. Deductiveverification of UML models in TLPVS. In Proceedings UML 2004, pages 335–349.LNCS 3273, 2004.

[2] Vieri Del Bianco, Luigi Lavazza, and Marco Mauri. Model checking UML speci-fications of real time software. In Proceedings of 8th International Conference onEngineering of Complex Computer Systems. IEEE, 2002.

[3] M. Bozga, D. Lesens, and L. Mounier. Model-Checking Ariane-5 Flight Program.In Proceedings of FMICS’01 (Paris, France), pages 211–227. INRIA, 2001.

[4] M. Bozga, S. Graf, I. Ober, I. Ober, and J. Sifakis. The IF toolset. In SFM-04:RT4th Int. School on Formal Methods for the Design of Computer, Communicationand Software Systems: Real Time, LNCS, June 2004.

62 I. Ober, S. Graf, and D. Lesens

[5] W. Damm, B. Josko, A. Pnueli, and A. Votintseva. Understanding UML: A formalsemantics of concurrency and communication in real-time UML. In Proc. of the1st Symposium on Formal Methods for Components and Objects (FMCO 2002),volume 2852 of LNCS Tutorials

[6] A. David, O. Moller, and W. Yi. Formal verification UML statecharts with realtime extensions. In Proceedings of FASE 2002 (ETAPS 2002), vol. 2306 of LNCS.Springer-Verlag, April 2002.

[7] M. del Mar Gallardo, P. Merino, and E. Pimentel. Debugging UML designs withmodel checking. Journal of Object Technology, 1(2):101–117, August 2002.

[8] J.-C. Fernandez, H. Garavel, A. Kerbrat, L. Mounier, R. Mateescu, and M.Sighireanu. CADP - a protocol validation and verification toolbox. In ComputerAided Verification, 8th Int. Conf. CAV ’96, vol. 1102 of LNCS, 1996.

[9] E. Fersman, L. Mokrushin, P. Pettersson, and W. Yi. Schedulability analysisusing two clocks. In 9th International Conference on Tools and Algorithms forthe Construction and Analysis of Systems (TACAS), volume 2619 of LNCS, 2003.

[10] S. Graf, I. Ober, and I. Ober. Timed annotations in UML. Int. Journal onSoftware Tools for Technology Transfer, Springer Verlag, 2006. (In print. Availableon Springer On-line at http://dx.doi.org/10.1007/s10009-005-0219-x).

[11] Z. Har’El and R. P. Kurshan. Software for Analysis of Coordination. In Conferenceon System Science Engineering. Pergamon Press, 1988.

[12] G. J. Holzmann. The model-checker SPIN. IEEE Trans. on Software Engineering,23(5), 1999.

[13] A. Knapp, S. Merz, and C. Rauh. Model checking timed UML state machinesand collaborations. In 7th Intl. Symp. Formal Techniques in Real-Time and FaultTolerant Systems (FTRTFT 2002), volume 2469 of LNCS, September 2002.

[14] K.G. Larsen, P. Petterson, and W. Yi. UPPAAL: Status & Developments. InO. Grumberg, editor, Proceedings of CAV’97 (Haifa, Israel), volume 1254 ofLNCS, pages 456–459. Springer, June 1997.

[15] D. Latella, I. Majzik, and M. Massink. Automatic verification of a behavioralsubset of UML statechart diagrams using the SPiN model-checker. Formal Aspectsof Computing, (11), 1999.

[16] J. Lilius and I.P. Paltor. Formalizing UML state machines for model checking. InRumpe France, editor, Proceedings of UML’1999, volume 1723 of Lecture Notesin Computer Science. Springer-Verlag, 1999.

[17] C. L. Liu and J. W. Leyland. Scheduling algorithms for multiprogramming in ahard real-time environment,. JACM, 20(1):46–61, 1973.

[18] Iulian Ober, Susanne Graf, and Ileana Ober. Validating timed UML modelsby simulation and verification. Int. Journal on Software Tools for TechnologyTransfer, Springer Verlag, 2006. (In print. Available on Springer On-line athttp://dx.doi.org/10.1007/s10009-005-0205-x).

[19] SysML Partners. SysML specification v. 0.9 draft (10 jan. 2005). Available athttp://www.sysml.org/artifacts.htm.

[20] D. Potop-Butucaru, B. Caillaud, and A. Benveniste. Concurrency in synchronoussystems. In Formal Methods in System Design 2005, LNCS. Springer Verlag, 2005.

[21] Fei Xie, Vladimir Levin, and James C. Browne. Model checking for an executablesubset of UML. In Proceedings of 16th IEEE International Conference on Auto-mated Software Engineering (ASE’01). IEEE, 2001.

[22] S. Yovine. Kronos: A verification tool for real-time systems. Springer Interna-tional Journal of Software Tools for Technology Transfer, 1(1-2), December 1997.