COrrect development of reAl-time Embedded systems in UML

Deliverables

The UVE tool (UML Verification Environment) serves to check functional and dynamic properties of the Omega kernel model - structure, behaviour and the order of the object communication - combining them into (temporal logic) formulas. It can be applied at the design and implementation phases for the component verification when real-time constraints are not yet specified. In cases where this makes sense, requirements can refer to the number of steps in the model execution, thus achieving a kind of discrete time. The most elements of the UML object-oriented features in class diagrams and state machines, a subset of C++, a subset of CTL, LSCs, parameterised environment, tuning verification parameters are covered by this tool set. A more detailed description is published in [STMW04]. The main functionality of UVE is the following: Verification of a set of temporal logic formulas (defined via the provided patterns): check of reachability, invariance, liveness, safety etc. Verification of LSCs: a compliance check between specifications and a design. Sequence diagrams generation: as witness-paths for properties reachability and existential LSCs; as counterexamples - error-paths - for so called invariant properties such as, e.g., universal LSCs. Results visualization with symbolic timing diagrams (STDs) and LSCs. Verification of requirements under different kinds of assumptions, restricting the non-determinism of the environment or of the system behaviour (e.g., not yet implemented parts). UVE consists of two components: Rhapsody-based, RUVE: the development was started in the AIT-WOODDES project and has been extended within the OMEGA project with respect to several features: extending the supported UML set in particular regarding object-oriented elements, extending the formulisation of properties (e.g. introducing LSC specifications) as well as improving the verification engine using optimisation and abstraction techniques; XMI based - XUVE - developed in the OMEGA project. In addition to the features covered by RUVE, XUVE adds the following functionality: The semantics defined in OMEGA with non-determinism between concurrent regions in state-charts and non-determinism between enabled transitions; OMEGA Action Language (in addition to C++) with extended constructs for non-deterministic choice and concurrency; Two possibilities of the fine-tuning and invocation of the verification process: using the Rhapsody graphical interface or from a command line without a UML tool. The tool-set has been partially extended with the means to derive symmetry property of the whole model from the properties of its parts. This tool-extension is intended to be used to reduce verification complexity as well as for the verification of unbounded models.

We have built a number of tools and techniques which support the verification of UML models with the help of the interactive theorem prover PVS. The PVS tool itself has been developed by SRI and is freely available (see http://pvs.csl.sri.com). In the context of the Omega project, we have developed the following: A translation from XMI to PVS, using the intermediate SUML format A translation of a subset of OCL to PVS, also via SUML A set of general PVS theories that define the semantics of the Omega kernel language The TLPVS framework which provides a set of theories and strategies on top of PVS to enable the proof of temporal logic properties. A set of PVS theories that allows compositional verification. The main idea is that users of the PVS-based tools start by importing an XMI file of a concrete UML model. Via the intermediate SUML format, the XMI file is translated into a representation of the UML model in the typed higher-order logic of PVS (point 1). This model may include OCL specifications (as comments), which are translated separately into PVS (point 2). Alternatively, the user may express specifications directly in the specification language of PVS. The generated PVS files representing the concrete model are imported by general PVS theories that define the semantics of UML models (point 3). This defines the set of all runs of the UML model and the user can start proving properties about these runs using the PVS proof checker, which requires experienced users. To obtain a more convenient framework for the proof of properties expressed in Temporal Logic, the TLPVS package has been developed (point 4). It includes powerful strategies that reduce the amount of user interaction. Moreover, scalability is addressed by means of generic theories that allow compositional verification of a component-based design (point 5). The five ingredients of our approach are explained in more detail below. 1) XMI to PVS We have implemented a tool that translates a subset of UML, in the XMI format, to the input language of the theorem prover PVS. To simplify the implementation of our tools, we defined an intermediate format called SUML (simple UML). Our current implementation translates two XMI dialects, namely of Rhapsody and ArgoUML, to SUML. There is also a translator from SUML to PVS. The tools are available at http://homepages.cwi.nl/~jacob/uml2pvs.html 2) OCL to PVS The OCL tool implements a translation of a subset of OCL constraints into the input language of the theorem prover PVS via the SUML format. In order to avoid implementing a three-valued logic within the framework of PVS, we have defined a sound translation of OCL into a two-valued logic. The OCL tool is available at http://www.informatik.uni-kiel.de/~mky/omega/suml.html 3) Semantics of the Omega kernel language The semantics of the Omega kernel language has been implemented in the typed logic of the interactive theorem prover PVS. We have defined the meaning of basic class diagrams where the behaviour of objects is described by state machines. These reactive objects may communicate by means of asynchronous signals and synchronous operation calls. Explicit timing has been realized via local clocks and an urgency predicate on transitions. The PVS theories are available on http://www.cs.ru.nl/~hooman/STTTpvs.html 4) TLPVS TLPVS is a PVS implementation of a linear temporal logic verification system that has been further developed in Omega. The system includes a set of theories defining a temporal logic, a number of proof rules for proving soundness and response properties, and strategies, which aid in conducting the proofs. In addition to implementing a framework for existing rules, we have derived new methods, which are particularly useful in a deductive LTL system. Special attention has been paid to the verification of systems with unbounded number of processes. TLPVS is available at http://www.wisdom.weizmann.ac.il/~verify/tlpvs/ 5) Compositional verification We have defined a general PVS framework to support compositional verification. The focus is on the level of components, concentrating on parallel composition and hiding. To be able to formalize intermediate stages during the top-down design of a system, we have constructed a framework where specifications and programming constructs can be mixed freely. Compositional proof rules for parallel composition and hiding have been formulated in PVS and the tool has also been used to prove the soundness of these rules.

Within the Omega project, VERIMAG has developed the IFx toolset for timed verification, simulation and scheduling analysis of Omega-UML models. The approach that was chosen is to reuse the timed validation techniques that VERIMAG developed for dynamic communicating timed automata extended with data and actions, as well as the already existing IF toolbox which implements state-of-the-art validation and verification techniques (see http://www-verimag.imag.fr/~async/IF/). A more detailed description focusing on the IF language - including extensions made, can be found there as well. The main functionalities provided by IF/IFx are: Simulation allows the user to interactively explore a model's execution graph. The user may perform operations that are similar to those offered by advanced debuggers: step by step execution, inspection of the system state, conditional breakpoints, scenario rewind/replay, manual resolution of non-determinism, control of scheduling policy and time related parameters, etc. Verification of simple consistency conditions like deadlocks, timelocks and satisfaction of state invariants. Verification of dynamic and timing properties using the model-checkers provided by the IF tool. The properties may be expressed within the UML editor by means of the following notations provided by the Omega UML profile; observer classes: classes with special state machines reacting to events and conditions occurring in the system execution timing constraints: constraints on durations between system events Finally, verification techniques implemented in the tool allow performing scheduling analysis, by specifying scheduling objectives (e.g., deadlines) as properties to be verified (observers). Other types of functionality, like comparing models modulo simulation and bisimulation relations, are also available in tools connected to IF. The architecture of the IF/IFx toolset is depicted below; . The upper part shows the UML tools specific to IFx, while the lower part shows the components of the IF toolset, including some modules developed in the OMEGA project (in blue). The main components of IFx (in addition to the IF toolset), are: The UML-to-IF translator, which takes as input a UML model stored in XMI format. The model may use standard UML constructs and extensions defined by the Omega profile: actions written in the Omega action language, timing annotations and observers expressing model properties. The translator generates an IF specification corresponding to the UML model, according to the Omega semantics. The UML front-end provides an interface specifically targeted at UML modellers for the IF validation tools. The interface hides IF and the details of translation and presents simulation and verification result in the vocabulary of the initial UML model. The interface supports all compilation and simulation features mentioned before, and offers customisable views on the analysed system. The tool has been applied on three of the Omega case studies: On the Ariane-5 case study (EADS), to statically validate the well-formedness of the model, to prove 9 safety properties of the flight regulation and configuration components, and to analyse the schedulability under the assumption of fixed priority pre-emptive scheduling policy. On the MARS case study (NLR), to prove 4 safety properties and to discover reactivity limits of some system components and fine-tune their behaviour in order to improve reactivity. On this case study, we have also applied compositional verification, which is partly supported by the tool through the existence of simulation checkers, minimization with respect to bisimulation and abstraction. On the Sensor Voting a Monitoring case study (IAI), to prove 4 safety properties and timing properties. The IF/IFx tool is freely distributed on the web (either through the Omega webpage or

The case study is a flight control mechanism that implements "sensor voting" and "sensors monitoring" operations in a typical flight control system. The main role of a Flight Control Computer of an aircraft is to implement control loops based on computations of Command values to Servo actuators controlling the air vehicle surfaces. These computations are parameterised by the actual values provided periodically by different sensors installed in the air vehicle. This system is critical and requires a very high reliability in presence of hardware faults. For achieving this reliability, we realize the avionics system using a triple redundancy of the different Sensors and Flight Control Computers. Evaluation summary: On the basis of this case study, IAI has used and done some evaluation of three tools developed in Omega. For this evaluation, the case study has been tailored: Using Play Engine (Weizmann Institute): The case study has been reduced and simplified for fitting the tool limitations and the case study version that was used on the LSC Play engine consists of one channel and three sensors. Using RUVE (OFFIS): In order to run the tool with our case study we needed to seriously simplify the model and reduce it to only 4 statecharts and 12 classes focusing in this way on the non real time issues in the model. Using IF (Verimag): With the IF tool, we wanted to verify time related properties of our case study. In order to do so, we have modelled the timing aspects of the system with Rational Rose, as using Rhapsody posed problems with the export of the action language part and also with the timed annotations. The model used for timed verification is based on the same state machines, but the functionality (in particular the voting mechanism, including the health monitor) has been omitted; on the other hand, all objects are active, and here we have taken into account two CPUs. The model was extended with timing specifications: we defined time triggered actions and time consuming activities of variable duration.

Live sequence charts (LSCs) is a powerful extension of the classical message sequence charts, allowing specification of behavioural requirements for complex reactive systems in a rigorous yet intuitive manner, using a visual language. This result deals with extending LSCs and adapting them for use in an object-oriented UML-based approach, mainly to deal with time and with symbolic-instances. The time extensions allow a scenario to refer to time and to react to it. A discrete clock object is introduced which generates 'tick' events, this clock object can be used in assignments (for time-stamping) and in time dependent conditions - allowing specification of complex timed requirements. The LSC language has also been extended with symbolic instances. A symbolic instance, associated with a class rather than with an object, and parameterised by a variable or other expression, may stand for any object that is an instance of the class. This allows specification of object-oriented systems where objects may be dynamically created and destroyed and the number of objects is apriori unknown. It also allows specifying requirements for objects with dynamically changing relations and is thus not restricted to a static object model.

The Play-In/Play-Out approach is a method for capturing and executing scenario-based behavioural requirements. This result deals with applying the method and supporting tools to several industrial case studies, and with extending the method and tools with verification and synthesis capabilities. The Play-Engine tool supports a scenario-based approach for specifying and executing behavioural requirement of complex reactive systems. Scenarios are specified using the language of live sequence charts (LSCs). The tool supports a convenient way to capture requirements (Play-In) by playing them in using a graphical user interface (GUI), and a rather surprising and powerful method (Play-Out) for executing the requirements directly. An extension of this approach called smart play-out uses verification methods to execute the scenarios directly, and also supports methods for analysing the scenarios for consistency and satisfaction of given behavioural properties. The Play-Engine has been applied to successfully to several case-studies in the OMEGA project: The voting and monitoring subsystem by the Israeli Aircraft Industry (IAI), the MARS model by NLR, and the Depannage telecom service by FTRD. A methodology for synthesizing state-chart models from scenario-based requirements has also been developed. The requirements are given in the language of live sequence charts (LSCs), and may be played in directly from the GUI, and the resulting state-charts are of the object-oriented variant, as adopted in the UML and OMEGA. The synthesis methodology is not fully automatic but rather relies on user interaction and expertise to allow more efficient synthesis algorithms. A major obstacle that requires additional research efforts is the high computational complexity of the synthesis algorithms, currently preventing scaling of the synthesis approaches to very large systems.

The FTR&D application is a telecommunication service built on top of an embedded platform and using a large number of service components. The complete application developed for OMEGA is a service called Depannage. This service allows a user (the subscriber) to make a phone call and ask for help from a doctor, the fire brigade, a car maintenance service, etc. The Depannage service should locate an available service provider according to the request and as close as possible to the location of the (mobile) caller and connect the caller to the provider. FTR&D used during the project a set of techniques in order to build the application by a step-by-step approach. First, we describe a high level specification of the service and component behaviour, including the behaviour of the communication between these components. This description includes timed constraints. Then the consistency of this high level specification is validated with respect to end-to-end requirements. This analysis is made with live sequence charts (LSCs), the Play-Engine tool and simulation/animation. In a second step, model-checking techniques are used with the Play-Engine tool in order to formally verify some requirements. The Play-Engine tool using the smart play-out extension allows executing and verifying scenario-based models with timed constraints. The complexity of verification and the current restrictions on the LSC subset supported by smart play-out implied identifying parts of the model focusing on complex and/or critical behaviours and applying verification to these parts rather than to the entire model. Once these first steps done, a more complete model (with all the potential behaviours, including creation and destruction of objects) is elaborated using the Rose CASE tool. This model is then exported to the IF/IFx tool and it is validated with respect to some requirements expressed by observers. Evaluation summary Application of LSCs and animation with Play-Out: The wish to specify components in a reusable way requires that the component specification should be done independently of any embedding architecture. Such specification corresponds to a universal LSC describing how the component will react to events coming from its provided ports and how (and when) this component will act on its required ports. For the system, the complete application, the specification should be enhanced by universal LSCs describing the communications between these components. Such LSCs could include time constraints and delays on the communication. The end-to-end requirements are expressed by existential LSCs and will be validated during the simulation/animation of the model. Our experience in OMEGA showed that LSCs and the Play-Engine tool allow a convenient way for specifying and executing high level requirements that seems well suited to the telecommunication domain. Application of smart play-out to timed verification: The model checking tools allows formal verification of the expressed requirements. In order to use the model checking tools, currently some restrictions need to be made on the model: no symbolic instances, only one parameter for each signal. We have also to restrict verification on parts of the model in order to avoid state-explosion. It means that we have to focus our work on the more critical part of the behaviour. We can then verify that all possible executions of the model satisfy the specified requirements. The Smart Play-Out approach allows executing all the execution paths while searching for the satisfaction of a property (an existential LSC). This approach has been applied successfully to the Depannage model. Research to extend the LSC subset supported by smart play-out and to improve scalability is a central direction that will be pursued beyond the OMEGA project. Application of the IF/IFx tool for formal specification and verification of complete systems. The objectives of our work with the IF/IFx tool were to make a formal verification of a more complete model. The model developed here includes more complex behaviours corresponding to the call termination. It involves the creation and destruction of objects and more complex message exchange patterns. In this model, we introduce also another behaviour that has not been completely described with the LSC tool. We were very satisfied by the use of the OMEGA/IF approach for the modelling and verification of our application. The main characteristics of telecommunication models and their properties could easily be modelled: non- determinism, different kinds of message exchanges, time constraints and timers, etc. The verification techniques are complete and efficient: simulation, exhaustive simulation and observer verification.

Define a subset of UML suitable for safety-critical applications, which is rich enough to express such modelling entities of UML used in real-time applications, as active objects, dynamic object creation and destruction, dynamically changing communication topologies, combinations of synchronous and asynchronous communication, and shared memory usage through object attributes. We provide an executable semantics suitable for the formal verification of temporal properties with existing model-checking tools. For the OMEGA Kernel Model, we have chosen, like the considered CASE tools, a relatively complete subset of the operational part of UML, where the static structure of the system is described in terms of a class diagram with only a few restrictions, where associations between classes express inclusion or accessibility. In particular, like the standard profile, we distinguish between active and passive classes, but with a particular interpretation: the behaviour of an active class and all the classes owned or created by it, represent a mono-threaded behaviour, executing request in a run-to-completion fashion. This notion of activity group is also used in Rhapsody, and is similar to the notion of process in SDL or capsule in ROOM. Communication between objects is either via asynchronous signals or via synchronous operation calls, where we distinguish between primitive operations, which are executed by the calling thread and normal operations which are scheduled by the active object of the activity group. The behaviour of the system is described by means of an explicit imperative action language, which can be used in combination with a form of state machine notation for describing transition systems extended with data, communication and object creation.

The object constraint language (OCL) is the established language for specifying of properties of objects and object structures. Recently an extension of OCL has been proposed for the specification of messages sent between objects. We present a generalization of this extension, which allows additionally specifying causality constraints. From a pragmatic point of view, such causality constraints are needed to express, for example, that each acknowledgment must be preceded by a matching request, which is frequently required by communication protocols. Our generalization is based on the introduction of histories into OCL. Histories describe the external behaviour of objects and groups of objects. Moreover, to reason compositionally about the behaviour of a complex system we distinguish between local specifications of a single object and global specifications describing the interaction between objects. These two types of specifications are expressed in syntactically different dialects of OCL. Our notion of compositionality, which is formalized in this paper by a compatibility predicate on histories, allows the verification of models during the early stages of a design. This method is supported by a prototype tool available under the terms of the General Public License.

UML 1.4 includes no support for real-time, but a profile for Scheduling Performance and Time (called SPT profile) had been defined, including some extensions for the expression of timing properties, mainly in the form of tag values. We have defined a real-time profile that respects the SPT profile, which takes over most of its basic concepts, defines a concrete syntax where this is missing and specifies the usage. Also, contrary to the SPT where time constraints are mainly expressed at instance level, the Omega real-time profile enables time constraints at class level: - We have introduced the notions of timer and clock, as they exist in other modelling formalism and as they have been introduced in UML 2.0. Timers can be set and deactivated and cause a "timeout event" after a specified duration and clocks can be set and deactivated, and when active, they count the duration since they have been set for the last time. This allows the definition of time dependent behaviour by means of new primitives in the action language. - We provide syntactic access to semantic level events. A semantic level event is a state change in the underlying dynamic semantic. Each syntactic construct may have to 0, 1 or more semantic level events associated. With a state of an enter and an exit event is associated, with a signal transmission, a send, a receive and a consume event. A syntax is defined for identifying all state changes. An event can be defined as a class stereotyped event with predefined parameters depending on their type (all events have an occurrence time, a send-signal event has a sender, a receiver, a signal type, signal type depending parameters) and possibly user defined attributes. Moreover, there are means to refer to different occurrences of an event in a given execution or prefix of it. - Expressions of the type duration which can be used in time constraints can be defined simply using arithmetic expressions on clocks and the occurrence time attribute of different events (this is the access to time and duration used in OCL, see below and in observers, see next item), by a set of predefined duration expressions. - Time constraints may be arbitrary Boolean expressions depending on time and duration expressions, but we consider only linear constraints in all our tools. Time constraints can occur. -- In the form of guards in state machines and observers. -- Conditions in LSC. -- OCL constraints. -- Explicit time constraints or constraint patterns associated with different UML construct, as they are foreseen in SPT (WCET associated with methods, minDelay, maxDelay associated with channels, "..."); notice that such derived constraints are presently not implemented in the tools, they have to expressed using the basic means for expression of time constraints. - We have introduced observers mainly as a means for expressing complex time constraints using a UML operational syntax, accessible to the user. They are defined as stereotyped of state machines, where transitions are triggered by semantic level event occurrences (they can be identified using explicitly defined event instances or by using an event matching clause as in the definition of a corresponding event class). An observer allows expressing constraints on the order and/or timing of occurrence of semantic level events and is a means to define dynamic properties depending on time or not. Observers have proven to be well accepted by users. They express safety properties in the form of acceptors (an execution leading to an error state represents an error trace). In addition, observers can express assumptions (a sequence leading to an invalid state is "not to be considered"). - Finally, some minimal concepts have been introduced to define scheduling constraints and general scheduling policies.

The case study is the Medium Altitude Reconnaissance System (MARS), software that controls a photo camera embedded in a fighter aircraft. The experiments with the OMEGA tools have concentrated on the self-monitoring functions of the system. The system performs asynchronous data acquisition from the avionics data bus (altitude data and navigation data), while performing cyclical internal processing of the hardware failure detection (data bus controller Built-In-Test status). The data bus status monitoring functions involve functional as well as time-dependent system behaviour. The system environment (namely the data bus controller and data sources) exhibits non-deterministic functional and timing properties. The verification and validation activities comprised application of the OMEGA tools to the case study model in the series of verification experiments. The objective of these experiments was to evaluate the following aspects of the application of the new OMEGA technologies in the industrial context: relevance to the case study domain; applicability to the issues of the industrial software development; usability in the industrial setting; OMEGA tools in the industrial software development lifecycle. The most important issue of this case study was related to verification of the model with non-deterministic environment. The main source of non-determinism lied in the fact that the data sources were independent, unsynchronised, provided cyclical data with non-deterministic timing jitter (bounded to ±10ms), and had a possibility of non-deterministic data loss. The UVE tool An untimed version of the case study UML model has been developed in the Rhapsody tool and verified with the UVE tool. The tool provides possibility to specify the non-deterministic external stimuli to drive the system model behaviour. The tool allows verification of safety and liveness properties of a UML model, and provides facilities to specify assumptions on the model behaviour as well as on the environment (external stimuli). The IF/IFx tool: A timed version of the UML model has been developed and verified with the IF/IFx tool. The tool allows a more realistic modelling of time dependent behaviour in the self-monitoring components, as well as a more explicit environment modelling. The latter is possible as the tool provides support for non-deterministic behaviour in a closed UML model, including timing non-determinism. Several timing properties have been specified and verified using observers. The academic partners experimented successfully alternative more compositional models allowing obtaining more general verification results using compositional verification and abstraction. They showed also the usefulness of the combined use of all the validation tools developed in the project, including the proving based ones

The EADS ST case study presents the Flight Software of the European Ariane 5 Launcher and focuses on relevant real time behaviours. The objective of this Ariane 5 Flight Software is to control the launcher mission from lift-off to payload release. This software operates in a completely automatic mode and has to handle both the external disturbances and the hardware different failures that may occur during the flight. This case study presents the most relevant points required for such an embedded application and focuses on the real time critical behaviour. EADS ST software merges in the same processor asynchronous behaviours (stage ignition and release, failure isolation and recovery) and cyclical synchronous behaviours (control/command of the vehicle, failure detection). The main difficulty in this case study was the combination of cyclic and acyclic behaviour, which leads to an explosion of the state space (caused by the execution of several thousands of cycles along the lifetime of the acyclic behaviour which takes around 1 hour). This has called to the application of some abstraction techniques: Properties of the acyclic part have been initially verified by abstracting away the cyclic part manually. In order to verify properties, which involved both the acyclic and the cyclic part, we had to artificially reduce the duration of the mission from around 1h to around 1 minute. However, the relevant behaviours of both parts are fully preserved by this abstraction. Another particular issue raised by the case study was the validation the scheduling policy used by the launcher software, which is based on a fixed-priority pre-emptive scheme. This has necessitated the construction of a model of the scheduler as well as the capturing of scheduling objectives by UML observers. Evaluation of results: EADS ST has developed its UML model under the Rational Rose tool and has then used the IFx/IF tools (semantics checker, simulator, model-checker) in order to validate it. The great strength of the used tools is their compatibility with the OMEGA semantics and then the taking into account of the real time behaviour. The simulator has allowed correcting several errors in the model (mainly unexpected deadlocks), which have not been detected by manual revue. As the cost of a specification error during the validation phase is very high, these techniques have already proved their great interests. All the properties have been exhaustively proven correct. The model-checker allows increasing importantly our confidence in the model.

We have developed a formal model of components in the OMEGA subset of UML. The main rationale of the OMEGA component model is to provide additional structuring and abstraction mechanisms, which allow an object-oriented modelling discipline and the application of formal techniques based on "interfaces". At the CWI we are currently (in the context of various national and international projects) developing implementations of extensions of the OMEGA component model with mobile channels. Mobile channels allow a clear separation of concerns between communication and coordination, on the one hand, and computation, on the other hand. Furthermore, they provide a powerful mechanism for the exeogenous coordination of components in dynamic reconfigurable networks.

Searching for OpenAIRE data...

Deliverables

Share this page

Download