Noname manuscript No. (will be inserted by the editor)
A case study in UML model-based dynamic validation: the Ariane-5 launcher software?
Iulian Ober1, Susanne Graf1, David Lesens2
1 VERIMAG 2, av. de Vignate 38610 Gi`eres, France e-mail: {iulian.ober,susanne.graf}@imag.fr 2 EADS SPACE Transportation 66, route de Verneuil - BP 3002 78133 Les Mureaux Cedex - France e-mail: [email protected]
The date of receipt and acceptance will be inserted by the editor
Abstract The aim of this paper is to show the use- 1 Introduction fulness of IFx, an extension of the IF validation toolset for timed and complex systems, for the validation of de- Model-driven engineering is making its way through the signs represented using the UML profile defined in the habits of software and system designers and developers, IST Omega project. pushed forward by the increasing maturity of modeling This demonstration is done on hand of a realistic case languages and tools. This paradigm promotes a com- study, a model of the Ariane-5 launcher software. In this plete re-foundation of software engineering activities on case study, we do not address the correctness of the con- the basis of models, as well as the use of automatic tools trol algorithms, which may be specified as global trans- for most if not all post-design activities like getting a actions and validated with the help of synchronous tools platform-specific implementation, generating and exe- such as Scade. We are rather interested in the expression cuting tests, deployment, etc. of non functional properties which allow to guarantee the In this context, the model of a software system (or correctness of this transactional view and their valida- of a system in general) gathers different views ranging tion on a model of the distributed architecture on which from the system requirements (in the form of use cases, the system is deployed. of static or dynamic properties that the system has to We provide examples of complex properties and their satisfy, etc.), to architecture, to behavior of individual expression by UML observer state-machines, where spe- components and/or subsystems, to platform-related in- cial attention is paid to the modelling of properties ex- formation (resources and their utilization), etc. Since the pressing time constraints and schedulability. Also, on model is central to the whole development process, it is hand of this example, a validation methodology is demon- essential for its designers and its users to be able to check strated which has been experimented already in a num- its correctness and coherence early in the development ber of real-life examples. cycle (i.e., before the availability of an implementation This case study is representative for systems in the on the target architecture and in the real environment) aerospace domain concerning the nature and complexity by providing models of the functional and non functional of the handled verification problems. aspects of software, architecture and environment. Code generation form the developed software model In the Omega project1, we have developed a UML was not part of this case study, but the obtained model profile adapted for modelling real-time and embed- is such that it can be refined into a complete model - ded systems [DJPV03,DJPV05,GOO03,GOO05] and including also all functional aspects - from which existing extended the IF validation toolset for real-time systems code generation techniques may be applied. [BFG+99,BGM02] for handling UML models, resulting in the tool IFx [OGO05]. IFx allows simulating an oper- ational UML system specification and verifying complex behavioral properties as defined by the Omega UML pro- file. ? This work has been partially financed by the OMEGA IST project 1 http://www-omega.imag.fr 2 Iulian Ober et al.
The Omega UML profile emphasizes operational The IFx validation toolset is described briefly in sec- models which can be further refined into complete mod- tion 2.2, and a more detailed description is available in els from which code can be generated. This profile rep- [OGO05]. resents an extension of the UML profile of Rhapsody2 with real time features, in particular with the notion of timed observers for the expression of requirements. 2.1 UML features supported by IFx and semantics The Omega UML profile has been used in several case studies by industrial users for modeling real-time The IFx toolset supports the constructs and the par- and embedded systems, and the IFx toolset has been ticular semantics of the Omega UML profile [OGO05, used for validating coordination and real-time aspects3. GOO05,DJPV03]. This section provides a small digest In this paper, we focus on the largest of these case of the features of this profile, necessary to understand studies: a model obtained by reverse-engineering of a the model of the Ariane-5 case study. representative part of the flight software of the Ariane-5 The architecture and the behavior of a system are launcher4. described using class diagrams, state diagrams and oper- The aim of the paper is to show on hand of the cho- ation specifications. Class diagrams may use most of the sen case study the usefulness of the IFx toolset for the concepts available in UML, such as: attributes, different validation of properties and design models provided in types of associations and generalization relationships. the the form of UML models conforming to the Omega State diagrams may be used to define the dynamic profile. behaviour of reactive classes; objects react either to Section 2 provides a short overview on the Omega asynchronous signals received from other objects, to con- UML profile and the IF validation toolset. Comment ditions (change events) or to operation calls. Operation by Susanne: oui je suis d’accord il faut inverser; il faut calls which are handled by the state machine associated aussi surtout racourcir ou ici ou dans la methodologie; with an object are called triggered operations in Omega car actuellement on raconte l’histoire deux fois. In sec- UML. The behavior associated with an operation that tion 3, we describe the the problem to be solved and is not triggered (called primitive operation) is described discuss the modeling and specification features of the by an action. Actions are written in a syntax compliant Omega UML profile used. Section 4 discusses the expres- with the UML action semantics, containing imperative sion of requirements concerning control-flow and timing constructs like assignments, operation calls, object cre- related aspects and section 5 discusses the IFx tool work- ation, signal exchange, etc. flow and the validation results for Ariane-5. In section 7, The profile supports the description of concurrent we show how our approach relates to other approaches and distributed systems by means of active classes. In- and finally, in section 8, we discuss some methodological stances of active classes define a partition of the sys- issues, on how results were obtained, what problems can tem objects; an active object together with its depen- be encountered and how they can be solved, and what dent passive objects are called an activity group. Each has to be done in order to really integrate the validation activity group has exactly one thread of control and approach into the development process. handles requests (operation calls and signals) coming from the other groups in a FIFO run-to-completion man- ner. Comment: [susanne: ca c’est pas vrai, la concur- 2 Preliminaries on the UML profile and the IFx rence existe meme sans signaux, simplement parce que toolset chaque class active a initialement un thread] Thus, con- currency is created by non-blocking requests (signals or In this section, we present the toolset and the UML pro- operations which do not send a return value) between file used for carrying out the Ariane-5 case-study. activity groups. Detailed descriptions of Omega UML profile can be This execution model is presented in more detail to- found in [DJPV03,DJPV05] for the general profile and gether with its motivations in [OGO05,DJPV03]. It cor- in [GOO03,GOO05] concerning the real-time aspects. In responds to a particular choice of semantics in the spec- section 2.1, we introduce only the features needed for the trum allowed by the UML standard [OMG03], and is an example where the main emphasis is on the expression extension of the execution model implemented by the of timing related requirements. Rhapsody tool. On top of the concepts mentioned above, the Omega 2 http://www.ilogix.com/rhapsody/rhapsody.cfm profile defines a set of time-related constructs [GOO05]. 3 a short overview on four of these case studies can be found There are basic concepts like timers and clocks for de- at http://www-omega.imag.fr/cs/cs.php 4 Ariane 5 is the European heavy-lift launcher, with pay- scribing time-driven behavior in an imperative style, as load capacity of 10,000 kg on dual launches into GTO (geo- well as a mechanism for defining duration constraints stationary transfer orbit). EADS SPACE Transportation, the which are declarative assumptions or requirements about European space transportation and orbital systems special- how system execution relates to time passing. Require- ist, is now single Prime Contractor for the Ariane 5 system. ments to be validated are expressed by UML state ma- A case study in UML model-based validation 3
Rose, chines, with stereotype <
period. Notice, that these algorithms as well as the
ECS ECS reactivity constraints are defined by the control engi- ECS ECS
ECS neers and come as an input for the software engineer. EPC EPC EPC EPC
EAP EAP – aperiodic, event- or datum-driven algorithms, corre-
EAP EAP EAP EAP
EAP EAP EAP EAP sponding mainly to the spacecraft mission manage- ment (motor ingnition and stop, stage release ...) or error recovery algorithms, which interact strongly seconds minutes milli -seconds hours with the control command algorithms.
Fig. 2 Ariane 5 mission. When designing the software architecture, the soft- ware engineer has to take into account a number of con- straints 3.1 Ariane 5 Launcher presentation 1. The application software has to be statically proven correct. The launcher is composed of 3 stages: EAP stage, EPC 2. In the case of Ariane-5, all parts of the application stage and ECS stage Comment by Susanne: surement a software will finally be executed on the same pro- racourcir, puisque redit par la suite cessor5 and share a common bus for aquiring sensor – EAP stage. The two EAP boosters are ignited a few data from and sending commands to a set of physi- seconds after the main stage. They deliver about 90% cally distributed equipments of the global thrust at lift-off and the duration of 3. their powder combustion is about two minutes. Then, In addition to these external constraints, there are they are separated from the main stage and fall down additional constraints which provide a kind of standard into the ocean. framework for solving the initial problem – EPC stage. It is the main stage and is mainly com- posed of a LOX/ LH2 tank and an engine, which 1. provides the main thrust during 8 minutes to reach The proof of the correctness of the implemented al- the target orbit. At switch off, the stage is discon- gorithms is done using a synchronous reactive view, that nected from the upper stage and falls down into the is under the assumption that at the beginning of each ocean. global cycle, all the data required by all the algorithms – ECS stage. The objective of this last propulsion stage activated in this cycle are available and that the outputs is to bring some additional energy to finetune the are produced at the end of the cycle. orbit and perform the payload release. The duration In a distributed architecture, several problems may of this stage is about 15 minutes. arrise for guaranteeing the above assumptions. The mission is composed of several phases (see figure – a data produced in a given cycle, may not be ready 2), each one corresponding more or less to the stabilized at the beginning of the next cycle because of a com- behaviour of a launcher stage. At the end of a permanent munication delay. working of the launcher, a transition is performed to – reach a new permanent working. In the case where the reactivity constraints are re- laxed enough Depending on the required reactivity, their 3.2 Case study description implementation may be integrated into the cyclic syn- chronous process or not. An embedded space software such as the one of the Ar- The software model contains 6 main classes, each iane 5 launcher consists of several modules which can having a single instance. To simplify the description, no have different, strongly interacting, types of behaviours. distinction will be made between classes and instances From the functional point of view, there are two main in the following description. types of functional behaviour: – Acyclic: It is the main class of the software. This – cyclic synchronous algorithms. These are principally class manages the start of the software and the flight the control/command algorithms (Guidance, Navi- sequence and the associated automaton. The transi- gation control,..) and some monitoring algorithms. tions of the automaton can be triggered They are obtained by discretisation of continuous 1. on event reception from the GNC algorithm (e.g. physical laws, that is, they have a specific period end of thrust detection) and phase; they receive their inputs at the start of their period and shall produce their output 5 in fact, a set of replicated processors, but this is out of before a given delay, not longer than their execution the scope of our case study A case study in UML model-based validation 5
2. on event reception from the environment 4 Capturing functional and non-functional 3. on timed conditions including time windows pro- requirements tection (allowing to assure that the treatment as- sociated to an external event will be performed at In the initial phases of a project, functional and non- coherent time, even in case of failure of the event functional requirements are captured through use cases, detection mechanism) through high-level activity diagrams, using domain- – EAP: This class manages the behaviour of the EAP specific notations or just informally. As the system model stage: ignition and release. The sequences described becomes more precise requirements can be refined, for- in this class are driven by events received from other malized and used for validating the design model. classes and by internal time constraints. Formalization of properties in the Omega UML – EPC : This class manages the behaviour of the EPC : framework is based on the concept of observer. Require- ignition, monitoring of correct working, alarm raising ments which are purely concerned with timing can also and stop. The sequences described in this class are be specified using a form of declarative constraints. In driven by events received from other classes and by this section we discuss (briefly) these concepts, and we internal time constraints. insist on how they can be put to work – with examples [IO]: il me semble que EPC est purement time-driven from the Ariane-5 model and some methodological hints. dans notre modle. Je me trompe? – Cyclics: This class manages the activation of the 4.1 Expressing complex behavioral requirements cyclical control command algorithms. These algo- rithms are related to navigation, guidance, control, Observers are special objects which monitor the execu- thermal control, etc. The algorithms are executed in tion of the model and give verdicts when a requirement is a predefined order (depending on the current state satisfied or violated. Observers may have their own local of the launcher, given by the Acyclic class). Its state memory (attributes), and their behavior, which has the machine appears in an example later on in Figure 9. purpose to give verdicts, is described by a special kind – Thrust Monitor: This is one of the algorithmic of state machine, in which some states may be labeled classes. It is responsible for the monitoring of the with the stereotypes success or error . EAP thrust. It is activated by the Cyclics class. Monitoring model execution is done either by observ- – Guidance Task: This is another algorithmic class ac- ing events like signal outputs, operation calls or returns, tivated by Cyclics. It has the particularity that its state changes, etc., or by observing the state of the sys- activation frequency is very low. In the real system, tem, like attribute values, contents of queues, states of it is implemented in a specific ADA task. the state machines, etc. In order to validate (by simulation or by proof) the In the following we discuss some of the properties software behaviour, a part of the environment is de- verified on the Ariane-5 example and alongside we give scribed. The environment can contain parts of the space- some methodological guidelines for writing observers. craft as defined in the spacecraft design, the physical Property 1. The software shall not send an Open com- environment (ground control centre, wind for an atmo- mand to an already open valve. spheric phase, other spacecraft behaviour, etc.), as well Valves are used in the main engine of the launcher as abstractions of parts of the software which are not to command the required thrust. Opening an already described in the model (such as: a numerical algorithm, opened valve is usually an error in the software logic. a bus protocol, etc). In our model, we have used the This is one of the simplest safety properties that may following environment elements: be expressed with an observer. It requires that a cer- tain condition never occurs during the system execution: – Ground: It is the main class of the model. This class, software sends Open command to valve v and v is open. representing the control centre, sends the start signal The only problem raised by this property, which comes toward the launcher (and its software). back in every other formalized requirement, is to relate – Bus: This class describes the behaviour of the 1553 the informal condition expressed above with some formal MIL bus allowing the communication between the event or condition occurring in the system. main software and the equipment. In our case, the sending of an Open command means – Valve: This class describes a specific type of equip- the call of the triggered operation Open defined in the ment. The hardware failures are modeled by an non- class Valve (from package Environment). The “match” deterministic choice in order to verify the correct clause visible in Figure 36 matches the invocations of management of such a failure by the flight software. – Pyro: This class describes another specific type of 6 Because the properties presented in this section are taken equipment. directly from the UML model developed with Rational Rose (v.7.0), they are not completely conforming to the UML stan- The multitasking policy and the CPU consumption dard. In particular, we note the use of a branch symbol in- of each function is also modeled (see details section 4.3). stead of a choice pseudo-state. 6 Iulian Ober et al.
<
<
initial [ v @ Open ]
<
nondet [ true ] Fig. 3 Property 1.
[ true ] / t.set(0) <
We complete thus the previous property in the following way: state machine that checks A <
<
match accept ::EADS::Environment::Valves::Open() by v additionally, Valves are required to remain closed (i.e. never reach the states Open or Failed Open).
[ v @ Open ] Property 4. If the lift-off is performed, all the valves [ v @ Failed_Open ] shall be opened, and the EAP stage shall be released on aborting <
not_yet tion), i.e. object entering state Ignition done. The sepa- match send ::EADS::Signals::Request_EAP_Preparation() ration on the EAP stage involves the ignition of Pyro2 and Pyro3 in a very precise timing. [ t >= 2000 ] This property can be broken into four separate ob- aborted servers which check that, if the Pyro1 object enters state match send ::EADS::Signals::Request_EAP_Release() Ignition done, then respectively:
[ (v.EPC.EVBO @ Open or v.EPC.EVBO @ Failed_Open) or – All the instance of the Valve class shall be in the (v.EPC.EVVCH @ Open or v.EPC.EVVCH @ Failed_Open) or (v.EPC.EVVCO @ Open or v.EPC.EVVCO @ Failed_Open) or Open state 2 seconds after, and then remain in this (v.EPC.EVVGH @ Open or v.EPC.EVVGH @ Failed_Open) or (v.EPC.EVVP @ Open or v.EPC.EVVP @ Failed_Open) ] state forever. – The instance Pyro2 of the class Pyro shall enter Ig- Fig. 6 Property 3. nition done in a predefined time window (relative to the start date H0). – The instance Pyro3 shall enter Ignition done in a An anomaly on the Vulcain ignition corresponds, in predefined time window (relative to the start date our modeling of the environment, to a Valve object en- H0). tering the Failed Open state. This failure shall be de- – The duration between the entry of Pyro2 in the state tected by the software, which shall then abort the lift-off Ignition done and the entry of Pyro3 in the state Ig- and secure the launcher. Thus, this property is expressed nition done shall also be in a predefined time win- more precisely as follows: dow. If any instance of the valve class enters one of the states We present in Figure 7 only the observer which Failed Open or Failed Close, then: checks the last of the four properties. – All the instances of the Pyro class shall stay forever Although this feature is not used in the Ariane-5 in the state Wait ignition. model, let us note that it is possible for very complex – 2 seconds after the valve failure, all instances of the properties to be described using a set of communicat- Valve class shall be in state Close or Failed Close, ing observers. Communication is then done by shared and then remain in this state forever. (public) observer attributes. This property is expressed in a purely black- box way. However, since several components are in- 4.2 Timing requirements volved in aborting the lift-off, the observation of the internal signals Request EAP Preparation and Re- For a real-time system like the Ariane-5 software, cer- quest EAP Release, which is supported in our frame- tain system requirements are concerned purely with the work, allows performing on the model level the equiva- timing of some events during the execution. This is the lent of a mixed white-box and black-box testing activity. case for example in the Property 2 introduced in section 8 Iulian Ober et al.
<
<
timeevents { match send ::EADS::Signals::Start(void) by g <
wait_ign_p [ t23 >= 10000 ] 3
[ g.Acyclic.EAP.Pyro3 @ Ignition_done ] 4.2.2 Property 2 as a local constraint Property 2 can [ t23 < 5000 ] <
10ms
/ Attitude.Calculate_Attitude() Calculate_ Interpolation_ Start_Minor_ attitude performed Cycle
Synchro() / begin minor_cycle:=minor_cycle+1 end / Data_tables.Interpolate() [ minor_cycle>=guidance_period ] / begin 5ms [ minor_cycle / BGY.Perform_BGY() 5ms [ minor_cycle=6 ] / Navigation.Flight_Protection() BGY 10ms [ minor_cycle=2 ] / Navigation.Perform_Navigation() [ minor_cycle<>2 and minor_cycle<>6 ] 20ms 2ms / SRI.SRI_upstream() SRI_Upstre EAP phase am_1 QDP phase Decide_EAP QDP phase _Separation 2ms 5ms EAP phase [ fasvol<>2 ] / Control.Calculate_EAP_aiming() [ fasvol=2 ] / Control.Calculate_QDP_aiming() EAP_Calculat QDP_Calculat [ fasvol<>2 ] e_aiming e_aiming [ fasvol=2 ] / Thrust_Monitor.Decide_EAP_Sepa / Control.Predict_EAP_state_vector() / Control.Predict_QDP_state_vector() ration() / SRI.SRI_downstream() 10ms Control_Predic 5ms 0..5ms t_state_vector SRI_Upstre SRI_Down am_2 stream Fig. 9 Statechart of the Control cycle with unitary execution times. Scheduling < < System Fig. 10 Scheduling library. – if another task j is waiting (with the highest pri- If a cycle does not finish in time, the Cyclics compo- ority after i), and if tj is not yet started, then tj nent is in an intermediate computation state when is set to 0. the next Synchro is received and this property is vi- olated. – The Guidance tasks have to finish within the 576ms 4.3.3 Modeling the scheduling objectives Scheduling cycle. This property is expressed with a similar ob- objectives are modeled using observers. As mentioned server. in section 4.3.1, there are three scheduling objectives: – The bus transfer windows have to be observed. This is formalized in a similar manner by the fact that – The control functions have to finish within the 72ms calls to Bus read and write operations do not occur cycle. This property is formalized in the observer in while the Bus is in a Transfer state. Figure 12, by the fact that the Cyclics component receives the signal Synchro, which signifies the begin- ning of a cycle, only in the states Start Minor Cycle, Wait Start or Abort. A case study in UML model-based validation 11 semantics (see [OGO05] for the details of the transla- tion). This phase performs simple static (syntactic and [ currentPrio = -1 ] idle semantic) checks of the UML model. One can discover FPPSExec(theTask,newD, newPrio) basic errors such as: [ d->getAt(newPrio) <> -1 ] / informal error "-- VIOLATED ASSERTION--" – syntax errors in actions – use of undefined or uninterpreted UML constructs FPPSExec(theTask,newD, newPrio) (e.g., unknown stereotypes or data types, some UML constructs or features not interpreted in the Omega [ currentPrio <> -1 ] / if(not started->getAt(currentPrio)) then begin t->getAt(currentPrio).set(0); started->getAt(currentPrio) profile, etc.) := true end endif – naming errors (e.g., use of undefined attributes, sig- nals, classes, etc.) – type errors (e.g. operation signature mismatch, etc.) – violations of other well formedness constraints (e.g., exec root class is not active, a class has several state ma- [ t->getAt(currentPrio) = d->getAt(currentPrio) ] / begin tasks->getAt(currentPrio)!FPPSRelease(); tasks->getAt(currentPrio) := null; chines, etc.) d->getAt(currentPrio) := -1; t->getAt(currentPrio).reset(); started->getAt(currentPrio) := false; currentPrio := self.getCurrentPrio() end 5.2 Static analysis [ d->getAt(newPrio) = -1 ] / begin self.insertNewTask(theTask, newD, newPrio); currentPrio := self.getCurrentPrio() end In this phase, the dfa tool is applied in order to analyze Fig. 11 Behavior of the fixed priority preemptive scheduler. the IF specification, simplify it and optimize it for veri- fication. Several types of transformations are possible: – State factorization introduces systematic reset in- structions for variables which are dead in a certain control state of the specification. In this way, it pre- wait vents the model checking tools to distinguish between execution states which differ only by values of dead match send ::EADS::Signals::Synchro() to c variables. This technique is very effective, given that it can be applied locally at control-state level, and [ c @ Start_Minor_Cycle or c @ Wait_Start or c @ Abort ] may collapse large (bisimulation equivalent) parts of the state graph. [ not( c @ Start_Minor_Cycle or c @ Wait_Start or c @ Abort ) ] This transformation is especially useful to reset clocks or counters which are not useful any more from < In the Ariane-5 case study, the usefulness of factor- an explicit or implicit environment) as shown later on. ization is limited due to the relatively small number of When properties are expressed by observers, the error loops in the system state graph. Comment by Susanne: analysis is usually done on-the-fly during the complete je ne comprends pas, la factorization est lie au nombre traversal of the state space — which requires to store de variables, non? p.e. on peut dire un peu plus sur ce only the states encountered during the traversal, but not qui etait util Nevertheless factorization was useful to au- the transitions — by signalling the non satisfaction of tomatically reset clocks which were not useful from some a property each time that an < Example: In the Ariane-5 model, the use of partial or- enabled (eager transitions) and to forbid that enabled der reduction was the key for constructing tractable transitions are disabled by time progress beyond the va- models. Without this reduction, even for flight pa- lidity of their guard (delayable transitions). rameters that yield the simplest behaviors, the com- In IFx, all timing constraints of the UML model are plete exploration of the state space did not succeed translated into constraints on clocks in the correspond- (it had more than 106 states, with a state size of ing IF model. IF allows two methods for representing about 10KB). By using partial order reduction of in- clock values during state space exploration which can be ternal steps, we reduced the size of the model by chosen independently of the exploration strategy: more than 3 orders of magnitude, that is, to about – symbolic or dense time representation: a state con- 1000 states for certain flight configurations. sists of an untimed state and a normalized constraint Depth first exploration is in most cases the recom- on clock values — represented by a so-called differ- mended strategy: it can be combined with partial ence bound matrix (DBM) — representing the the order reduction and it also allows often detecting values of the clocks at the point of time at which anomalous behaviors of the system very early (i.e. the state is entered, and how far time can progress after generating only a fraction of the state space). without any change of the set of enabled transitions. During exploration, the number of already generated Notice that the time unit has to be chosen in such a states and transitions as well as the “current depth” way that all relevant clock constraints, and therefore are displayed. also bounds in the DBMs can be expressed by integer Notice that in cases in which the depth grows very values. fast or is (almost) equal to the number of explored – discrete time representation: in this case, in each states, one can suspect that the system is diverging, state the clock variables have some (integer) value, i.e. that any transition execution leads to a new state and time progress is represented by tick events in- and there are no cycles. While this may be a normal creasing all clock values by 1. behavior, in most systems this is caused by an error due to the fact that some clock or counter is never Details on the two representations and how they com- reset, or that a process signal queue is getting flooded pare may be found in the literature on timed automata. by signals which are produced more often than they The advantage of the symbolic representation is that it are handled. The causes of such anomalies can of- leads often to much smaller models. When the occur- ten be discovered and eliminated by analyzing a few rence time constraints of some transitions depend on “deep” states. earlier measured time distances between events (that is clock differences), the use of the discrete representation – Breadth first exploration. The main advantage of is necessary as in this case the constraint on a successor this strategy is that it allows finding the shortest state may not be representable by a DBM. When the path to some property violation. However, it cannot symbolic states represent (close to) unit time progress be combined with partial order reduction and the intervals, the discrete representation is generally more generation of diagnostics traces is much more com- efficient. plex Comment by Susanne: le suivcant, je ne com- Notice that there are no simple guidelines depending prends pas – cannot be generated in a form amenable on the form of the model allowing to make always the to debugging and divergence problems can in not right choice. A general observation is that the presence of be detected and diagnosed early. Comment by Su- many eager transitions or the presence of “independently sanne: autre question: est-ce bien vrai que po ne peut evolving” clocks leads often to small symbolic states. No- pas etre appliquee? ou est-ce simplement bien plus tice that for the Ariane-5 model as well as other UML cher puisqu’il faut garder l’information normalement models verified with IFx, the symbolic time representa- seulement pour l’exploration courante pour tous les tion performed always bette, both in terms of state space etats non encore completement explores? size and generation time. 5.4.2 Representations for time The time model under- lying IF is that of timed automata [ACH+95], which are 5.5 Other verification techniques based on the use of clocks which can be reset to zero Several other techniques for property verification are and progress in states, all at the same rate. Thus, clocks available in IFx. We discuss here two of them: can be used for measuring the time progress between the event in which a given clock has been set and the – Verification by model minimization is an intuitive event in which it is measured. In order to enforce upper method for a non expert end-user. It consists in com- bounds on the time distance between events, a notion of puting a reduced graph (with respect to a given set urgency is needed. IF uses timed automata with urgency of observations) of the overall behavior of the speci- [BS97] which provides means to force the occurrence of fication. Such a model can be visually examined by transitions to the earliest time point at which they are the user. 14 Iulian Ober et al. Nevertheless, in order to obtain an abstract model, 0 {Valves}0 ?Open the complete state space must be stored in memory. If 11 this is possible, it can be minimized modulo a bisim- {Valves}1 ?Open ulation using Aldebaran (a tool connected to IFx {Valves}2 ?Open 10 [BFKM97]), and depending on the kind of bisimula- tion considered, the reduced graph strongly preserves {Valves}3 ?Open 3 different classes of properties (e.g., safety, absence of {Valves}4 ?Open 1 deadlocks, etc.). The set of observations must include all events relevant for the property being verified. 2 {EPC}0 !Ignition Example: The graph in figure 13 is the quotient 4 {Valves}3 ?Open {Valves}1 ?Open model of Ariane-5 with respect to branching bisimu- i 7 {Valves}4 ?Open {Valves}2 ?Open {Valves}0 ?Open lation [?], in which the only observable events are opening/closing the Epc valves, igniting the Epc {EAP}0 !Anomaly 8 stage and detecting anomalies. The branching structure and all safety properties in- {Valves}4 ?Close 9 volving these actions are preserved on the graph from i {Valves}3 ?Close 12 figure 13. It is easy to check by inspection on this ab- {Valves}2 ?Close stract model that if an Eap anomaly occurs, then all 13 {Valves}1 ?Close the valves are closed and afterwards an Epc anomaly 14 is signaled. Also, it is easy to check that the Epc {Valves}0 ?Close sends the Ignition signal only after all valves have 6 been (correctly) opened. {EPC}0 !Anomaly 5 – Verification of properties expressed by µ-calculus for- mulas. Alternation-free µ-calculus is a temporal logic which allows expressing properties depending on the Fig. 13 A minimal model generated with Aldebaran. branching structure of the system state graph. Its ex- pressive power is incomparable to that of observers (representing languages). It allows the expression of – existential abstraction consists in eliminating a set branching dependent properties such as “there is no of elements (variables, processes, messages) and all deadlock”, or fair liveness such as “after each A- statements changing their value, together with all transition, as long as no B-transition has occurred, those elements whose values may depend on some al- there exists always at least one successor from which ready eliminated element. This transformation leads a B-transition can be reached”. often to much smaller models as a smaller state space There exists extensions of the µ-calculus allowing is considered, but it may lead also to a huge over- the expression of time dependent constraints, but approximation of the behavior. Over-approximations this is not implemented in IF. Anyway, using µ- preserve the satisfaction of safety properties, but not calculus is non trivial, even for specialists. Moreover, their non-satisfaction (i.e. they may generate false in timed systems, liveness properties are replaced by negatives). In the case of non satisfaction of a prop- time-bounded safety properties for which the use of erty on an abstract model, nothing can be concluded, observers is almost always more convenient. Truely and one has to reconsider the choice of the abstrac- branching dependent properties, like the one above tion. IF does not (yet) provide support for this so- can only be expressed by modifying the model by called abstraction refinement process [?]. adding boolean variables coding the existence of a A related abstraction of timed systems consists in required execution as a part of the state. relaxing the urgency type of transitions, for example transforming eager transitions into delayable or even 5.6 Reduction techniques with weak property lazy ones. This leads to a state graph allowing more preservation behaviours but probably with much less states. – introducing priorities: when property preserving par- Until now, we have only considered methods preserv- tial order reduction does not eliminate enough ing both the satisfaction and the non satisfaction of a concurrency-induced non determinism, IF proposes set of properties: that is, for some set of properties, the the addition of priority rules forcing particular ex- application of a reduction technique will conclude that ecution orders for some conflicting transitions (for the original system satisfies the property if and only if a description, see [OGO05,GS04]). In the case that the reduced model does. IF allows also some reductions confluence can shown for the prioritized transitions in which only one of the two implications holds, that is using stronger methods than those underlying the IF properties are only weakly preserved. partial order reduction, strong property preservation A case study in UML model-based validation 15 is still guaranteed. Otherwise, only a subset of the Compositional Abstraction . We have applied this well possible behaviours is explored, and only the viola- known technique which consists in the verification of tion of safety properties are preserved by the reduced properties of a subsystem, by replacing the other parts of model. the system — which play here the role of an environment — by a simpler description representing an abstraction, Notice that the simultaneous use of both over- and that is, allowing more behaviours. Nevertheless, the sim- underapproximations is problematic as verification re- ple variable elimination implemented in IF did not suc- sults are then meaningless. Notice also that most models ceed Comment by Susanne: a-t-on essaye ?. We had to use some form of over approximations due to the non rep- manually provide abstractions, and in order to minimize resentation of “irrelevant details”. Thus, underapproax- the modelling effort, the existing decomposition of the imations as they are introduced by priorities have to system into a cyclic and an acyclic part, and the clear be used very carefully. When priority rules are however interface between them has been exploited: taken into account by the code production process, as this is for example the case in Rhapsody, then priorities are strictly property preserving with repsect to the code – Abstraction of the cyclic behavior. generation process and can be used to simplify models. To prove safety properties related only to the acyclic An example of using abstractions of this form is given part, that is the flight programm, the cyclic GNC in section 6.1. In the context of IF, where we are verifying part has been abstracted. This has been done by mostly timed systems, a common abstraction consists in eliminating all the internal behaviour of the cyclic loosening the timing constraints of a component of the part, and by sending the events generated by the system. For example, a transition which is taken in a GNC (flight phase change commands) at arbitrary strictly defined time condition may be rendered time- moments, rather than at an “optimal” time point nondeterministic by defining its urgency as lazy. This computed by the concrete GNC. This simplified GNC means that it can be delayed indefinitely instead of be- is clearly an abstraction, and it was sufficient to ing executed as soon as it is enabled. While this intro- show the satisfaction of all the properties of the duces new behaviors in the model, the state space may asynchonous part. Comment by Susanne: c’est fi- shrink by an important factor because of the symbolic nalement une abstraction qu’on saurait construire representation of time that is used. presque automatiquement?. Si je comprends bien on a utilise une elimination des time guards — affaiblir des gardes. cest clairement une abstraction — suivi d’une abstraction existentielle de tout le comporte- 6 Ariane-5 verification results ment interne de GNC, qu’on aurait pu obtenir au- tomatiquement, p.e. meme en applicant le slicing ? 6.1 Abstractions in Ariane-5 – Abstraction of the asynchronous behavior. Comment: [IO]: est-ce qu’on peut dire plus prcise- ment ce qu’on a fait avec a? je ne me rapelle Comment by Susanne: le problem que je vois ici, c’est plus si je l’avais utilis vraiment. [S]: oui ca serait qu’on a enumere tout un tas de techniques de reduction bien d’expliquer un peu en detail en quoi consiste mais finalement on a utilise encore d’autres. Sans expli- l’abstraction cation ca ne passe pas In this second step, the asynchronous part has been The duration of a basic cycle of the cyclic behavior abstracted. Also in this case, we mainly relaxed of the Ariane-5 flight software is about 100 ms. Each time constraints: The cyclic behavior received asyn- basic cycle contains about 100 steps. This implies that chronous events generated at a non deterministic the generated model will have a depth of about 3 600 time. No hardware failure can occur. Even if this ab- 000 steps for 1 hour mission, and 15 000 000 000 steps straction is not completely realistic (especially for a for a 6 months mission, etc ... CPU consumption point of view), it has allowed the Current tools do not allow to exhaustively explore detection and the correction of several errors in the state spaces of this size, even after application of the model. Comment by Susanne: la, on melange tout: previously presented automatic reduction techniques. In interdire l’occurrence de “fault events” est une sous order to cope with the complexity of the model, we had approximation, qui en effet p.e. utilise pour la de- to apply more evolved abstraction and reduction tech- tection d’erreur. Mais le melange avec l’abstraction niques which need a good understanding of both the (relacher des time constraints) fait qu’il peut s’agir functioning of the system and the verification and ab- de spurious errors; donc il faut argumenter pourquoi straction technology. Comment by Susanne: p.e. plutot on est content quand meme. dans les conclusions de la section: In our case study, ensuite on a bien du montrer des proprietes, ce qui the verification has been done by the designer with the est a priori impossible avec un melange de sur et sous guidance from the verification expert. ... approximations 16 Iulian Ober et al. We have also used an alternative reduction with- by Susanne: ici ca serait sympa si on pouvait dire has out behavioral abstraction, in order to show global been shown .... For a choice of a minimal duration of all correction of the software, which allows also checking phases which requires a good knowledge of the design, some global properties on the time points at which the we show phase by phase by starting with the first one, event exchanges between the cyclic and the acyclic part that: take place. Comment by Susanne: est-ce vrai? sinon il – after the expected stabilization time the system is faut dire pourquoi c’est bien, ca permet une simulation indeed stable, that means, nothing changes from one plus realist qui p.e. utilisee aussi pour une inspection cycle to the next; thus, only time progress (leading manuelle? c’est plus simple a construire ? autre? to the next phase change) or exceptions may lead to Reduction of the durations of the flight phases . new states. A huge source of state explosion is the difference of – In a similar way one has to validate on over approx- the timing scale between the asynchronous behaviour imation of the stabilisation time for all exceptions and the cyclic one. The cyclic behaviour deals with du- – then, the duration of the first phase can be reduced to rations of a few milliseconds, whereas the asynchronous the minimal stabilisation time plus the duration al- one deals with durations of several hours (and up to lowing two exceptions to occur and to stabilize again. some months for other types of missions like the ATV8 This allows to guarantee that all states that can be project). reached during the first flight phase with the orig- Comment by Susanne: ca ne me convainc pas, c’est inal flight durations, will also be reached using the plutot une justification pour l’abstraction de le partie cy- shorter duration. clique comme avant; j’essais une explication alternative – Now we can use a short first flight phase to verify the ci-dessous. est-elle correcte? stabilisation delay for the second phase, and so on, That means that asynchronous events are rare, and until the last one. the system is working without occurrence of any asyn- Using such a reduction of the real duration of the mis- chronous events during a great number of basic cycles. sion, the reachable state space for the entire flight could Moreover, most of the output of the cyclic part is irrel- be explored, and all the properties could been shown to evant for the properties to be verified. Thus, it is suffi- hold. Notice that the properties of the cyclic part were cient to perform the proof with a mission duration much taken unchanged, whereas the properties of the acyclic greater than the basic cycle, but shorter than the real part had to be adapted to take into account the reduced mission duration. duration of the different flight phases. That means that asynchronous events are rare, and the system is working without occurrence of any asyn- chronous events during a great number of basic cycles in 6.2 Results and figures what we call here “stable phases”. In such stable phases, all executions of the basic cycle in the cyclic part are In this section, we want to show the efficiency of identical with respect to the properties that we want to the applied reduction methods.Comment by Susanne: il verify: in particular, faudrait donc inclure des durees plus longues puis con- – the schedulability of all tasks in all relvant cycles clure que pour 50 minutes on n’y arrivera jamais? – the reactivity to exceptional events (such events do In order to test the tool, we performed the mission not occur in stable phases) time reduction by using different mission durations (but – the respect of a certain time window for the com- always respecting the required stabilisation times) Com- mands send from the synchronous to the asyn- ment by Susanne: est-ce que les duress utilisees sont vrai- chronous part (stable phases are outside this time ment suffisantes? j’aurai la tendance de dire que tant que window l’espace d’etat ne crois pas lineairement, il y des vrais nouveaux etats?. This suggests that the model can be reduced by dras- The table in Figure 14 shows the verification time tically reducing the overall flight duration, by being care- and the size of the explored model using live variable ful to make sure that only stable phases are shortened, and partial order reduction (why not slicing?) for a given whereas all the critical transition phases are fully ex- mission duration (which one?) and for the verification plored. The transition phases are defined by the flight of individual properties. The difference between the ex- phases defined in the acyclic part and by the occurrence plored state spaces is small, meaning that all properties of exceptions, where the correctness of the software has are of similar complexity. only to be guaranteed if there are not more than 2 ex- Comment by Susanne: je comprends bien qu’ici on ceptions over the entire flight. a utilise -live et -po, et la difference des taille vient de The correctnes of a chosen reduction of the duration la difference des tailles des observateur ou plutot du of the different phases can be shown als follows Comment produit? 8 Automated Transfer Vehicle A case study in UML model-based validation 17 est-ce que tu as une taille du modele sans observa- restricted to static systems, often described by state- teur? pour voir l’influence des proprietes charts. [DMY02b] considers a real-time UML fitting the je suppose aussi que les temps donnes sont des temps input language of Uppaal which is less expressive than de generation, et qu’on peut mentionner cette histoire de that of IF. temps de compilation qui est affreusement long dans les The tools described in [STMW04,AHK+04] are, like conclusions ours, based on the Omega profile, where the first one We have also tried to verify all the properties at the does not take into account timing extensions and the same time by running all observers in parallel with the second one is based on deductive verification with PVS model. The array in Figure 15 gives the same informa- and could been applied so far only to quite simple exam- tion as above for all properties verified at the same time ples (using a small, yet expressive, subset of the profile). and by varying the choice of the mission duration. Also, most of the tools proposed for the validation of Notice that the state explosion due to parallel com- UML models rely on the expression of properties to be position of all properties is less important that one could checked in some tool dependent formalism, in many cases expect, which means that the properties are not really some form of temporal logic which is difficult to handle independent. In fact, all the observers have just a few by system designers. This means also that the properties control statesand the state changes in different events to be validated are not really part of the model which is are due to events which are either identical or strictly bad from the methodological point of view. The Omega ordered in time. The state of most observers depends UML profile proposes the use of observers also on clocks. But looking more closely, the clocks of different observers are active in different model states. That is, the methodological guideline proposing com- 8 Conclusions and Future Work plex proeprties into more simple ones, has here relative little impact on the complexity of model-checking. Nev- In the Omega project, we have developed different types ertheless, the use of many small properties is of great of validation engines and used them in several case stud- importance for the understanding of properties. ies. The evaluation of the contributions of the different tools shows their complementarity: – The big advantage of the IF tool which is based on 7 Comparison to other approaches explicit state exploration combined with powerful re- duction techniques, turned out to be the fact that it There exist already a number of tools proposed allows to obtain feedback very rapidly on all models for the validation of UML models by translat- without much remodelling and adaptation effort by ing a subset of UML into the input language of the user. Obtention of positive verification results re- some existing validation tool [LP99a,LP99b,LMM99, quired in the case of the bigger examples some effort Kwo00,KMR02,SKM01,DMY02a,dMGMP02,XLB01, to find an appropriate property preserving abstrac- DMY02b,BLM02,STMW04,AHK+04] to mention only tion or approximation. In the case of the Ariane-5 a some of the relevant work in the context of real-time flight programme, this consisted .... and embedded systems. – The RUVE toolset [STMW04] working on the same Like IFx, most of these tools are based on existing profile is built upon a BBD-based symbolic model- model-checkers such as SPIN [Hol99] (in [LP99a,LP99b, checking engine. LMM99,SKM01]) or COSPAN [HK88] (in [XLB01] ) for – The third toolset handling the Omega profile untimed systems, and Kronos [Yov97] (in [BLM02]) or [AHK+04] translates a UML model into a set of ex- Uppaal [LPY97] (in [KMR02,DMY02b]) for the valida- pressions defining the set of executions of this model tion of systems with timing constraints. Also the transla- and defines a set of PVS strategies designed for help- tion into proof-based frameworks, such as PVS [SOR93] ing the user to accelerate the interactive verification (e.g. in [AHK+04]) or B (in [LMS02]), has been pro- with PVS of properties - expressed either in OCL posed. or in the expression language of PVS. The advan- From the point of view of the technology used, the tage of this tool is that positive verification results on IF tool includes and combines the on-the-fly exploration parameterized and infinite systems can be obtained. of SPIN and the symbolic representation of time con- Nevertheless, the experience with the case studies in straints of Kronos and Uppaal. It includes also the Omega showed that this kind of verification applies bisimulation based reduction techniques of Aldebaran best to abstract algorithms. The obtention of results [FGK+96]. is time consuming, and in general it is advisable to With respect to the expressivity of the UML pro- first validate a finite instance of the system with a file accepted, the framework presented here goes beyond model-checker before starting the proof process. the existing tools. IFx handles a rich subset of UML, An important problem with this tool is the readabil- including inheritence and dynamic object creation as ity of the expressions obtained by automatic trans- well as powerful timing features. Most other tools are lation from UML. This means in general that only 18 Iulian Ober et al. Property Number of states Number of transitions Proof duration liftoff aborted right 36037 38149 00:00:36 pyro not ignited twice 35988 38092 00:00:42 valve not abused 36082 38210 00:00:37 valve not close in close 36010 38114 00:00:44 valve not open in open 35998 38102 00:00:38 liftoff performed right1 46075 48713 00:00:49 liftoff performed right2 37897 40550 00:00:55 liftoff performed right3 37961 40632 00:01:12 liftoff performed right4 35986 38090 00:00:38 CPU not in error 35980 38084 00:00:53 G cycle is schedulable 36012 38116 00:00:48 NC cycle is schedulable 36380 38484 00:00:39 read write coherence 36618 38722 00:00:47 Fig. 14 State space size and times for the verification of safety properties Mission duration Number of states Number of transitions Proof duration 7 s 51 324 54 697 00:03:30 15 s 161 956 171 734 00:12:06 22 s 303 496 321 206 00:11:33 30 s 463 932 490 901 00:22:58 37 s 658 981 696 031 00:34:53 Fig. 15 State space size and times for different mission durations (all properties combined) small systems - or components of it - can be used for real-time systems. In Proceedings of Confer- verification. Which means that the decomposition of ence on Computer Aided Verification, CAV’02, the system must be done with respect to the proper- Copenhagen, LNCS. Springer Verlag, June 2002. + ties to be verified. BGO 04. Marius Bozga, Susanne Graf, Ileana Ober, Iu- This tool has not been applied to the schedulability lian Ober, and Joseph Sifakis. The IF toolset. In SFM-04:RT 4th Int. School on Formal Meth- problem of the Ariane-5 flight program Also, the user ods for the Design of Computer, Communica- has to come up with the necessary auxiliary invari- tion and Software Systems: Real Time, number ants 3185 in LNCS, June 2004. BLM02. Vieri Del Bianco, Luigi Lavazza, and Marco Mauri. Model checking UML specifications of References real time software. In Proceedings of 8th Inter- national Conference on Engineering of Complex + ACH 95. R. Alur, C. Courcoubetis, N. Halbwachs, Computer Systems. IEEE, 2002. T. Henzinger, P. Ho, X. Nicollin, A. Olivero, BS97. S. Bornot and J. Sifakis. Relating time progress J. Sifakis, and S. Yovine. The algorithmic anal- and deadlines in hybrid systems. In Interna- ysis of hybrid systems. Theoretical Computer tional Workshop, HART’97, Grenoble, LNCS Science, 138:3–34, January 1995. 1201, pages 286–300. Spinger Verlag, March AHK+04. T. Arons, J. Hooman, H. Kugler, A. Pnueli, 1997. and M. van der Zwaag. Deductive verifica- DJPV03. Werner Damm, Bernhard Josko, Amir Pnueli, tion of UML models in TLPVS. In Proceed- and Angelika Votintseva. Understanding UML: ings UML 2004, pages 335–349. LNCS 3273, A formal semantics of concurrency and com- Springer-Verlag, 2004. munication in real-time UML. In Frank BFG+99. M. Bozga, J.C. Fernandez, L. Ghirvu, S. Graf, de Boer, Marcello Bonsangue, Susanne Graf, J.P. Krimm, and L. Mounier. IF: An Inter- and Willem-Paul de Roever, editors, Proceed- mediate Representation and Validation Envi- ings of the 1st Symposium on Formal Methods ronment for Timed Asynchronous Systems. In for Components and Objects (FMCO 2002), vol- Proceedings of Formal Methods’99, Toulouse, ume 2852 of LNCS Tutorials, pages 70–98, 2003. France, number 1708 in LNCS. Springer Verlag, DJPV05. Werner Damm, Bernhard Josko, Amir Pnueli, September 1999. and Angelika Votintseva. A discrete-time uml BFKM97. M. Bozga, J.-C. Fernandez, A. Kerbrat, and semantics for concurrency and communication L. Mounier. Protocol verification with the in safety-critical applications. Science of Com- aldebaran toolset. Software Tools for Tech- puter Programming, 2005. (to appear). nology Transfer, 1:166–183, 1997. dMGMP02. Maria del Mar Gallardo, Pedro Merino, and BGM02. M. Bozga, S. Graf, and L. Mounier. IF-2.0: Ernesto Pimentel. Debugging UML de- A validation environment for component-based signs with model checking. Journal of Ob- A case study in UML model-based validation 19 ject Technology, 1(2):101–117, August 2002. statechart diagrams using the SPiN model- (http://www.jot.fm/issues/issue 2002 07/arti- checker. Formal Aspects of Computing, (11), cle1). 1999. DMY02a. Alexandre David, M. Oliver M¨oller, and Wang LMS02. N. Levy, R. Marcano, and J. Souquieres. Yi. Formal Verification of UML Statecharts From requirements to formal specification us- with Real-Time Extensions. In R.-D. Kutsche ing UML and B. In International Conference and H. Weber, editors, Fundamental Ap- in Computer Systems and Technologies, Comp- proaches to Software Engineering (FASE’2002), SysTech 2002. Sofia, Bulgaria, 2002. volume 2306 of LNCS, pages 218–232. Springer- LP99a. J. Lilius and I.P. Paltor. Formalizing UML state Verlag, April 2002. machines for model checking. In Rumpe France, DMY02b. Alexandre David, Oliver Mller, and Wang Yi. editor, Proceedings of UML’1999, volume 1723 Formal verification UML statecharts with real of Lecture Notes in Computer Science. Springer- time extensions. In Proceedings of FASE Verlag, 1999. 2002 (ETAPS 2002), volume 2306 of LNCS. LP99b. Johan Lilius and Ivan Porres Paltor. vUML: A Springer-Verlag, April 2002. tool for verifying UML models. In Proceedings FGK+96. Jean-Claude Fernandez, Hubert Garavel, Alain of 14th IEEE International Conference on Au- Kerbrat, Laurent Mounier, Radu Mateescu, and tomated Software Engineering. IEEE, 1999. Mihaela Sighireanu. Cadp - a protocol vali- LPY97. Kim Guldstrand Larsen, Paul Pettersson, and dation and verification toolbox. In Computer Wang Yi. Uppaal in a nutshell. STTT, 1(1- Aided Verification, 8th International Confer- 2):134–152, 1997. ence, CAV ’96, New Brunswick, NJ, volume OGO05. Iulian Ober, Susanne Graf, and Ileana Ober. 1102 of Lecture Notes in Computer Science, Validating timed UML models by simulation pages 437–440, 1996. and verification. STTT, Int. Journal on Soft- GOO03. Susanne Graf, Ileana Ober, and Iulian Ober. ware Tools for Technology Transfer, 2004, 2005. Timed annotations in UML. In Workshop Under press. on Specification and Validation of UML mod- OMG03. OMG. Omg unified modeling language speci- els for Real Time and Embedded Systems fication, version 1.5. Technical report, March (SVERTS 2003), a satellite event of UML 2003. available through http://www.omg.org/ 2003, San Francisco, October 2003, October cgi-bin/doc?formal/03-03-04. 2003. downloadable through http://www- SKM01. Timm Sch¨afer,Alexander Knapp, and Stephan verimag.imag.fr/EVENTS/SVERTS/. Merz. Model checking UML state machines and GOO05. Susanne Graf, Ileana Ober, and Iulian Ober. collaborations. Electronic Notes in Theoretical Timed annotations in UML. STTT, Int. Jour- Computer Science, 55(3):13 pages, 2001. nal on Software Tools for Technology Transfer, SOR93. N. Shankar, S. Owre, and J.M. Rushby. The 2005. under press. PVS proof checker: A reference manual (draft). GS04. Gregor G¨osslerand Joseph Sifakis. Priority sys- Technical report, Comp. Sci.,Laboratory, SRI tems. In Formal Methods for Components and International, Menlo Park, CA, 1993. Objects 2003, number 3188 in LNCS. Springer STMW04. Ingo Schinz, Tobe Toben, Christian Mru- Verlag, 2004. galla, and Bernd Westphal. The Rhapsody HK88. Z. Har’El and R. P. Kurshan. Software for Anal- UML Verification Environment. In Proceed- ysis of Coordination. In Conference on System ings of the 2nd International Conference Science Engineering. Pergamon Press, 1988. on Software Engineering and Formal Meth- Hol99. G. J. Holzmann. The model-checker SPIN. ods (SEFM 2004), pages 174–183, Bejing, IEEE Trans. on Software Engineering, 23(5), China, September 2004. IEEE. available at 1999. http://csdl.computer.org/comp/proceedings/sefm/2004/2222/00/22220174abs.htm. KMR02. Alexander Knapp, Stephan Merz, and Christo- XLB01. Fei Xie, Vladimir Levin, and James C. Browne. pher Rauh. Model checking timed UML state Model checking for an executable subset of machines and collaborations. In W. Damm UML. In Proceedings of 16th IEEE Interna- and E.-R. Olderog, editors, 7th Intl. Symp. For- tional Conference on Automated Software En- mal Techniques in Real-Time and Fault Tol- gineering (ASE’01). IEEE, 2001. erant Systems (FTRTFT 2002), volume 2469 Yov97. S. Yovine. Kronos: A verification tool for real- of Lecture Notes in Computer Science, pages time systems. Springer International Journal of 395–414, Oldenburg, Germany, September 2002. Software Tools for Technology Transfer, 1(1-2), Springer-Verlag. December 1997. Kwo00. Gihwon Kwon. Rewrite rules and operational semantics for model checking UML statecharts. In Bran Selic Andy Evans, Stuart Kent, edi- tor, Proceedings of UML’2000, volume 1939 of Lecture Notes in Computer Science. Springer- Verlag, 2000. LMM99. D. Latella, I. Majzik, and M. Massink. Auto- matic verification of a behavioral subset of UML