Pascal Gula

B Eliane Fourgeau

AUTOSAR methodology and tools applied on two OEM use-cases

Keywords: AUTOSAR Methodology, OEM Use-Case, Verification & Validation, AUTOSAR Builder tool, ECLIPSE Framework

This paper presents an implementation of the AUTOSAR methodology based on two usecases, each of them are derived from an OEM need, as follows: 1) Set up of a collaborative exchange process between OEM and suppliers for the development of AUTOSAR applications.

2) Integration of AUTOSAR software components in a conventional EE architecture The role and contribution of authoring and configuration tools used in the AUTOSAR methodology will be presented and illustrated for both use cases; in particular, the paper will highlight the added value of these tools according to the process by showing their strengths and weaknesses. Mechanisms which have been used to connect proper links and to improve consistency between the various description files which are generated at each step of the AUTOSAR methodology, but also between these description files themselves and the vehicle data; the paper will describe the intrinsic merits of the technology which has been used to develop the tool suite, based on the upcoming Eclipse Framework.

Introduction

The industrial selection of a new standard in a company, and the likelihood of a wide deployment, is often preceded by an overwhelming work performed on several dedicated pilot projects. Indeed, processes have to be set up, and then refined. Furthermore new migration paths have to be found and new use-cases may even arise. To support these important and complex steps and meet operational requirements, new tools must be introduced. The choice of such tools is fundamental, since they have to smoothly introduce and to handle new concepts and to be open enough to cope with all other legacy tools and/or data entries. Such a choice happens when OEMs introduce AUTOSAR in their pilot and/or series projects.

The AUTOSAR standard architecture offers the ability to set up new business models between OEMs and providers. Following the first use-case, OEMs have the opportunity to design their ECU from a set of functions chosen among the offer from different providers. This way, the OEM concerns will be software components verification and validation. For the second use-case, OEMs issues are dedicated to ECU integration steps and the migration from legacy processes to match the AUTOSAR methodology. This is the case for example, when a system is composed of legacy vehicle communication matrix which should be used as input to AUTOSAR system configuration.

In this paper, we will strive to analyse the dedicated contribution and value proposition of an open and integrated AUTOSAR tool suite to both use-case implementations. Furthermore, built on the experience gained with a major French OEM, PSA, we will show how specifically the Geensys' AUTOSAR Builder suite implements the above development paradigms. In the first use-case, we will emphasize the need to validate multi-vendor software component deliveries by checking their individual & combined conformity to specifications (from both an xml description and an AUTOSAR implementation viewpoint). In the second use-case, we will highlight the need for the toolset to cope with the integration of legacy descriptions, ease the port/migration of a complete set of ECU functions; eventually we will stress the need for the tools to scale to the level of complexity required by automotive embedded applications.

The AUTOSAR concepts and methodology

AUTOSAR is an international organization whose aim is to provide an open standard to enhance the development of E/E embedded systems. It is composed of all the actors of the automotive industry, mostly OEMs & Tier1s (which are driving the development), tool provider, engineering companies, semiconductor and compiler manufacturer. The goals of AUTOSAR are to control the complexity and increase the quality of E/E systems. To fulfil these goals, AUTOSAR bases its development method on three pillars:

-standardized interfaces -a standardized software architecture -a standardized description and configuration process AUTOSAR also defines a methodology which provides all the major steps that compose the development of an embedded system. This methodology is summarized on Figure 1. What is important to point out is the complete independence of the software application with regards to hardware definition and constraints (thanks to the Virtual Function Bus concept). This means that a complete application could be developed without knowing the final mapping to the ECUs composing the vehicle topology. This also implies that Software Components will now be able to be relocated and composed seamlessly at mapping phase. It also alleviates the exchange of software component implementations and variant handling when it comes to design distributed crossplatform functions.

Collaborative exchange between OEM/Provider of AUTOSAR SWC

This first use-case focuses on a new business model enabled by the AUTOSAR standard software architecture, which consists of the development and delivery to an OEM of unitary software components coming from (potentially different) providers.

Traditionally, for a given ECU project, the car manufacturer used to collaborate with a given Tier1 supplier on the complete ECU implementation. With AUTOSAR, software components can now be viewed as COTS that can be integrated by another player, potentially a third party integrator. However, this new approach, which is truly flexible, implies the set up of a stringent verification and validation phase. The exchange between the OEM and his suppliers will be based upon specifications, in the form of AUTOSAR standardized descriptions, and the resulting deliveries will be composed of a complete AUTOSAR software component (SWC) description and its implementation (in C language most of the time).

To validate the AUTOSAR conformity of the resulting SWC composition, AUTOSAR Builder is providing static verification functionalities and conformity checks; this is performed by the AUTOSAR Builder SCVT (Software Component Verification Tool) plugin. This verification is done in a two steps:

-AUTOSAR xml conformance check -AUTOSAR code conformance check

The first conformance is dealing with pure AUTOSAR description. A first xml description strictly focusing on the VFB description of the SWC is provided by the OEM, it describes the application component type with its ports (required/provided) , and its related interfaces. The supplier(s) will then refine this SWC description adding behavioural details including runnables definition, data access for those runnables, events that trigger runnables, etc… These additional descriptions must comply with certain constraints, intrinsic to the AUTOSAR metamodel, specific to the project or the OEM needs. The AUTOSAR Builder SCVT plug-in comes with a standard set of rules that meet AUTOSAR constraints and is easily extensible to additional user-specific rules.

The tool reports all errors/warnings found and helps the user to check and correct them easily by pointing directly to the error in the corresponding file. The second step deals with the implementation of the SWC itself. Indeed, the code implementation of a SWC is written after its behaviour has been described (definition of runnables, data accesses, events,…) but before its actual allocation on an ECU has been done. This powerful mechanism provided by the VFB concept is actually enabled by the RTE (Run-Time Environment) which is the implementation part of the VFB. This first RTE code generation, so called "contract phase", is a step where all required headers to compile the application SWCs are produced. SCVT enables the user to validate this code implementation by comparing it to its corresponding AUTOSAR xml description. This way, the overall coherence can be verified, e.g. to check if runnables have proper names, if data accesses have corresponding and valid RTE macro defined, etc… The second use-case is embracing a wider scope. It relates to the development of a complete ECU application compliant with the AUTOSAR methodology. The summary of the major steps is the following:

1. description of all SWCs at VFB level 2. description of topology and communication matrix 3. mapping and ECU extract 4. configuration of BSW To implement all these steps, it is essential that the AUTOSAR toolset supports legacy descriptions produced by other tools or other means. For such a project, many of the data already exist (K-Matrix data for instance), or are produced externally to the AUTOSAR ECU project itself (i.e. functional descriptions, …). The issue is really for the tool to be capable of importing, with all the required transformations if necessary, data required to properly configure the ECU.

1 -For the description of SWCs, formal documents or model-based design tools can be used to describe the higher level specification and/or functional part of the modules. An AUTOSAR tool chain should provide the user with two development alternatives at least: 1 -ability to design SWCs directly, 2 -import legacy data and provide ad hoc transformation algorithms. In our precise case, the migration was done by creating an external script that generated an AUTOSAR xml description of a subset of the SWCs. This xml description is then imported normally in the tool and later refined.

2 -Concerning the description of the topology and the communication matrix, we find exactly the same concerns. However there is a discrepancy when we look at the maturity of formal design of both parts. On the one hand, the descriptions of topologies are often not standardized; but on the other hand, vehicle system messages are formally described (in proprietary or standard formats). Again, it seems compulsory to give users the ability to import and populate the communication matrix description, with all legacy data from all interacting networks. Figure 4: AUTOSAR Builder AAT This is a mechanism provided by AUTOSAR Builder through its "scripting" functionality. Using a formal description of the signal as input, it was possible to write a transformation algorithm that maps data on AUTOSAR signals, then to the corresponding PDU and frames and to set relevant properties. That way, the migration gets fully automated. In our precise case, more than 2000 signals were imported automatically. Considering a manual description of those parameters, it would have taken several days or even weeks to reach the same result (it is moreover an error-prone activity).

3 -The mapping and ECU extract focus on the extraction of all data of an AUTOSAR description which are mapped to a particular ECU. Obviously, when a whole system is described, only a subset of its SWCs is mapped on an ECU. The same holds true for the signals exchanged from or to this ECU.

Results from this step are used as the basis for the last step, which is the ECU configuration phase.

4 -This configuration is done by the integrator of the ECU which, in the case reported herein, is actually performed by the OEM. However, this responsibility only concerns a subset of the modules, i.e. the upper part of the basic software (BSW) architecture; the other part is left to the BSW and hardware platform provider.

Figure 5: AUTOSAR Builder GCE Looking more precisely at the AUTOSAR configuration, one can find out that some module parameter descriptions contain elements that are already provided by the ECU extract description (as inputs). This means that some parts of configuration can be automatically generated. AUTOSAR Builder comes with a generic configuration editor (GCE) which has been designed to provide some of the above facilities and offers the same "scripting" functionality as the authoring tool. For example, a complete COM stack can be pre-configured thanks to the description that can be found on the ECU extract, so that only significant configuration is performed. Moreover, the users could easily develop or use additional automation required by their process flow and deal with vendor specific parameters.

An open, Eclipse-based AUTOSAR tool technology

To enable its integration within a legacy process, AUTOSAR Builder is providing extensibility mechanisms such as "scripting".

Conclusion

Through this analysis of two exemplary use-cases, we have been stressing out the importance for an AUTOSAR platform foundation to have built-in extensibility mechanisms, to meet the needs of customer for replacing dedicated parts of their processes by a corresponding implementation that matches the AUTOSAR methodology. Main criteria to choose the tools that support the above-mentioned use cases are as follows:

-conformant to the AUTOSAR standard metamodel and concepts -open to external tools -customizable through the extension of existing functionalities -extensible, including the creation of custom automation features

The above criteria are key factors that influenced and drove the definition of the AUTOSAR Builder architecture, in such a way that it becomes eligible for supporting various commercial off-the-shelf or dedicated tools to build a complete and consistent tool chain.

The AUTOSAR Builder platform components are continuously enhanced to provide new automation features, with focus on the creation of a constantly growing library (pluglets, generation templates, predefined AUTOSAR application descriptions...) that will ease customer adoption of the AUTOSAR process and facilitate operational implementation on industrial projects. The AUTOSAR Builder Suite will include new features like graphical configuration and VFB simulation to increase its overall usability and performance, but also the depth of possible usecases implemented between the different stakeholders of AUTOSAR projects.

Acknowledgement

The authors would like to thank the contribution of Bertrand Delord from PSA for his useful and constructive comments.

Glossary

Figure

  Figure 1: AUTOSAR Methodology

Figure

  Figure 2: Xml Conformance

Figure

  Figure 3: Xml and C Conformance

  They are realized through an open underlying architecture called AUTOSAR Tool Development Kit, alias ATDK. This enabling technology is the common basis for all Eclipse-based AUTOSAR Builder tools. It encompasses EMF-based implementations of AUTOSAR metamodel releases 2.0, 2.1, and soon 3.0, and a number of related services including AUTOSAR XSD conform serialization, rule-based validation, tree-based viewers, form-based and graphical editing, and template-based target code and documentation generation. An easy to understand Java-based scripting/plug-let environment enables users to add domain-specific tool behaviours ranging from of custom file formats import & export to guided and automated BSW configuration.

Figure 6 :

 6 Figure 6: AUTOSAR TDK Architecture


P Bieber

J P Blanquart

G Durrieu

D Lesens
email: david.lesens@astrium.eads.net

J Lucotte

F Tardy

M Turin

C Seguin

E Conquet
email: eric.conquet@esa.int

Integration of formal fault analysis in ASSERT: Case studies and lessons learnt

Keywords: Dependability, Space, Formal Methods

The ASSERT European Integrated Project (Automated proof-based System and Software Engineering for Real-Time systems; EC FP6, IST-004033) has investigated, elaborated and experimented advanced methods based on the AltaRica language and support tool OCAS for architecture and fault approach propagation description analysis, and integrated in the complete ASSERT process. The paper describes lessons learnt from three case studies: safety critical spacecraft, autonomous deep exploration spacecraft, and civil aircraft.

Introduction

Dependability engineering is based on an appropriate combination of fault prevention, removal, tolerance and analysis techniques. The former three ones received a lot of attention in advanced engineering processes and methods. Conversely in the industrial practice, fault analysis is still largely based, with poor tool support, on tedious and error prone intellectual investigation of possible fault propagation paths. This is then used as input to detailed analyses (such as fault trees or quantitative dependability computation), generally with some tool support, or simply documented, for instance in failure modes, effects and criticality analysis reports. The ASSERT European Integrated Project (Automated proof-based System and Software Engineering for Real-Time systems; EC FP6, IST-004033) has investigated, elaborated and experimented advanced methods based on the AltaRica language and support tool OCAS for architecture and fault approach propagation description analysis, and integrated in the complete ASSERT process. The paper presents first the concepts studied when performing an early fault propagation analysis of an on board system. Then, it presents how the concept and analysis can be supported by AltaRica models and the associated tools. An illustration on the ATV system is given on the next part. Finally, the paper describes first lessons learnt from three case studies (safety critical spacecraft, autonomous deep exploration spacecraft, and civil aircraft). This sample of real cases of critical embedded systems enables to highlight a variety of architecture and dependability requirements. Moreover, they address different scenarios of use of fault propagation models: specification of fault detection isolation and recovery architectures, dependability assessment of architectures, comparison of architectures. This last part discusses first the benefits and limitations of the AltaRica language and tools for each targeted scenario. Then it deals with process issues: clarification of the various dependability modelling levels (from functional system view to physical one); links with the other methods and tools of the complete process (links with engineering and validation models such as AADL or UML, and with means to ensure and maintain consistency such as model transformation techniques).

Fault propagation analysis for on board systems

At system level, dependability analysis is certainly one of the most difficult tasks required by customer according to the criticality of the system. The objectives are to identify the possible faults, their effects at subsystem and system level, specify the protection mechanisms, design a robust architecture fault tolerant, design the fault detection isolation and recovery (FDIR) mechanisms and implement them correctly in the on-board software, define operations with ground segment to cope with all identified failure cases and validate them. According to the criticality of the feared failure condition, the system shall be tolerant to 1 or 2 faults. The proof of this requirement is very difficult due to hidden common cause failure. Thus dependability requirements and on ground system architectures will be different for aeronautic and space domain. Nevertheless, early fault propagation analysis will, in both cases, cope with the set of concepts that is presented below.

Failure condition

In Aeronautic, it is defined the important concept of Failure Condition (FC) which could apply to space activity to analyse the dependability (reliability and safety of a system).

The failure condition refers to a combination of failures modes applied to functions of the system under study. We considered the following generic failure modes of functions: total loss, partial loss and erroneous behaviour. The FC may also include conditions that describe the current mode of the system. The FC may be permanent or transient.

Failure modes

We will then define the following failure types for propagating failures in the system: Fail loss: the function is lost; it does not deliver its service, for electrical system its behaviour may be: no power, no signal, inactive…; for data, its behaviour may be: no answer, no valid data, erroneous data but associated with health status not OK. Fail erroneous: the function is alive, but delivers an incorrect service: data is erroneous but no immediate mean permits to detect the failure or error state. Software error will be in this category except if an exception is raised with processing stop, in such case we will use the fail_loss type. Fail_loss is detected immediately, but Fail_erroneous can be detected if a failure detector is implemented (e.g. threshold detector, comparison with a prediction, voter when at least 3 instances are provided…).

Failure detectors have false alarm rate and limited coverage ratio: if failure is detected, fail erroneous type is not propagated to other functions, either the failure is corrected else the fail_loss type will replace fail_erroneous type; if failure is not detected fail_erroneous type is propagated; but if false alarm is detected, the function is declared lost while it is correct. These kinds of failure modes are often identified when analysing fault propagation in computer based system and were more widely discussed in [START_REF] Mcdermid | A Development of Hazard Analysis to aid Software Design[END_REF]. Fail permanent: the failure remains permanent if no action is taken: the possible actions may be restart power, reset system, or reconfigure; the actions are part of on board FDIR or maintenance operations. Fail transient: the failure occurs from time to time but does not affect the behaviour of the system permanently; for space electronics, EMC susceptibility and SEU are the main cause of transient failures. For software, it may be a real time problem occurring with a low probability (overload, resource conflict…). Fail transient will propagate inside the system except if filtering mechanisms are implemented (repetition, protection, masking…), but if the failure affects remanent data, fail_transient will propagate as fail_permanent.

Failure transition and failure rate

Failures are introduced in the system as events which modify the state of the system. The natural state transitions of any item are: This latter transition is introduced in order to show the possibility that an erroneous system be further lost, but the reverse transition is impossible: a system already lost cannot return alive without a corrective action as recovery. For each failure event, we will have to provide the failure rate and the probability law (generally exponential); in this example fail_erroneous has a probability 1E-5 and fail_loss has a probability 1E-4.

4. Failure analysis

The concept of FC can be used for safety analysis (see aeronautic standard): each feared FC is generally specified with a severity, a quantitative objective and a qualitative objective. The analysis will consist to search all failure cases which have the consequence to raise the FC. This search may be obtained by FMEA starting from the failure and going to the effects, or by fault trees starting from the feared FC and searching all failure cases. The severity category of each FC will identify all functions involved in each category, and may have impact on architecture for partitioning software between categories. The concept of FC can be used for reliability analysis: a system, sub-system or equipment is specified with a reliability figure for a given time period: the whole mission, or part of it. The FC will be quantitatively evaluated taking into account failure rates, and architecture redundancies.

AltaRica implementation of the fault propagation analysis

AltaRica is a dependability language issued from LaBri (Laboratoire Bordelais de Recherche en Informatique) and industrial partners. AltaRica has been conceived to formally specify the behavior of critical systems in failure conditions and use these dependability specifications with tools. Several Dependability tools can process AltaRica models: symbolic simulators, model-checkers, fault tree generators, sequence generators, AltaRica graphical modelers, etc. There are many of such tools. Beyond them, CECILIA workshop covers most of these functionalities through its modules like OCAS and ARBOR.

In this section, we briefly introduce the features of the language and of the tools that were used for ASSERT purpose. The interested reader may find more details in [START_REF] Arnold | The AltaRica formalism for describing concurrent systems[END_REF].

AltaRica models

An AltaRica model is a hierarchy of interconnected "nodes". Each node has typed interfaces ("flows"), internal nominal or error "states" and a behaviour (a constraint automata) that results from "assertions" and "transitions" laws. The interface types usually record the failure modes that can be propagated by a flow. For instance, the node of the figure 2 By default, different event names depict independent events (as in fault-trees). One can nevertheless group events thank to the synchronisation feature.

Among other things, this feature enables the modelling of common cause failures.

Analysis of AltaRica models

During ASSERT, we mainly used three functions provided by OCAS: the interactive simulation, the fault-tree generation and the sequence generation. The simulation mode of OCAS tool enables the injection of failures and then computes the resulting effects. It permitted to debug the models and give a graphical view of failure propagation in the system. The fault tree and the sequence generations implement top down investigations. Starting from a FC, they extract respectively a tree or the set of sequences of events length that lead to the FC. The fault-tree generation is applicable only when the event ordering does not impact the FC reachability. The sequence generation is applicable in any case and enable to investigate some temporal aspect of failure propagation.

Illustration: ATV (Automated Transfer Vehicle)

ATV GNC architecture

The ATV is a spacecraft that is in charge of transporting cargo for the International Space Station (ISS). The analysis described in this section is limited to the Rendez-Vous phase when the ATV docks on the ISS, and it addresses only GNC sub-system and software. The Altarica approach could also deal with interaction of the GNC sub-system with other subsystems as power, thermal, propulsion, docking…but the study is concentrated on software behaviour in presence of hardware failures and software errors. The GNC architecture of ATV is described in figure 3. It is rather complex, it includes a pool of 3 fault tolerance computers (FTC) in charge of the nominal and survival GNC function running in the Flight Application Software (FAS: 3 instances of the same code in each computer) and a proximity flight safety function (PFS) limited to Collision Avoidance Manoeuver (CAM) triggered during the last Rendezvous phases in case of GNC failure. The Propulsion Drive Electronics (PDE) are dual duplex (4 equipments), and a large number of redundant sensors are used:

• Gyrometers : 4 equipments able to measure angular speed along 2 axis • Accelerometers : 3 equipments able to measure each acceleration along 3 axis • GPS : 2 equipments able to provide vehicle position and speed • Star tracker : 2 equipments able to provide accurate vehicle attitude

• Videometer : 2 equipments able to provide relative distance to the ISS • Goniometer (RDV sensor) : 2 equipments able to provide angular deviation during rendez-vous The FAS processes all these inputs data in the GNC function and delivers the PDE commands. But in order to insure the failure detection, it exists to other independent functions :

• the Flight Control Monitoring (FCM) which monitors the trajectory with videometers and goniometers • the Gobal Measurement System (GMS) which insures the navigation update from star trackers and GPS The FTC is a triplex system with votes provided in the FTC management layer (FML), if discrepancies are detected between the 3 FAS instances, the erroneous FTC is masked; in case of a second failure, the FTC pool is disabled, and the PFS takes control of GNC function to perform the CAM. A red button is provided to the ISS crew to start the CAM. The PFS is not completely independent of the nominal GNC, because it uses the same gyrometers but in coarse mode, with independent sun sensors for attitude update. The PFS is architectured with 2 computers (MSU), the first is master the second is slave, the master-slave switch will give control to the second one if the first is detected failed and the CAM continues. After completion of the CAM, the vehicle is pointed toward sun and the control is returned to the FTC which are restarted. Communication between FTC, sensors and PDE is insured via 4 MIL 1553 bus on which are allocated the equipments. This communal resource will introduce common mode failures between functions, and allocation of equipments on the 1553 bus is not trivial. One FTC computer will be the master of the 1553 bus with possible reallocation in case of failure of this computer.

ATV GNC Altarica model

The studied Altarica model is a simplification of this ATV architecture, and may include errors, the failure rates are not representative of the real ATV, it was provided only for the purpose of evaluation. The higher level functional view (described in figure 3) is represented with external interfaces (sensors and commands); failure events are introduced for all external interfaces and each internal function. The links between functions are green in absence of error, red in case of loss of the function and blue in case of erroneous behaviour. Simulations can then be conducted by "injecting" failure events on inputs or functions. For instance, we study failure modes related with the GPS system used during proximity phase. GPS loss is simple to detect via the GPS health status, and this failure mode will not be analysed in detail. GPS erroneous data is a possible failure mode to be considered and it is not detected internally by GPS receivers. It will be simulated by injecting the fail_erroneous event on one GPS receiver instance of the model. According to the model, the discrepancy between both GPS data is detected (by node valid_gps described in figure 4) and GPS system is declared lost. Then either this failure is blocked by GNC which will continue to control ATV without GPS data, or the failure propagates through GNC function (the output of GNC is equal to lost) and function FCM using independent sensors will detect the GPS failure and will invalidate all GNC commands. In the second case, the GNC health status (HS) is now incorrect and transmitted to PFS to start the CAM manoeuvre.

Figure 4: View of the FAS application Given a Failure Condition, OCAS sequence generator or fault-tree generator are used to compute the set of minimal scenarios of failure events that lead to this FC. For instance, we looked at the following FC of the ATV GNC sub-system:

• "Lost (resp. Erroneous) primary command " named PrimLoss (resp. PrimErr), This FC is reached when the output of node valid_com is equal to lost (resp. erroneous).

•

"Lost (resp. Erroneous) primary and backup command " names Prim&BLoss (resp. Prim&BErr). This FC is reached when the output of node merge_com is equal to lost (resp. erroneous).

Scenarios were computed in a few seconds by OCAS. The following table summarizes the results we have obtained. The first column indicates the safety result type : 1 for the number of single failure leading to the failure condition, 2 for double failures and so on, proba is the probability of occurrence of the failure condition, time is the amount of time needed by the tools to compute the minimal scenarios leading to the failure condition. The remaining columns provide the results for the four FC considered.

Results

Prim

Using this table, we can check that no single failure leads to the Loss of primary and backup command and no double failure leads to erroneous primary and backup command. Thise model can also be used in order to identify the segregation requirements between the various functions, to associate failure rate objectives with component failure modes and to associate Development Assurance Levels with software implemented components.

The model is extended with a description of the hardware architecture and of the allocation of functional components onto this architecture. The hardware architecture is described using altarica nodes that model CPU, buses, ... The allocation of functions on resources of the hardware architecture is described by grouping failure events of functions and resources. For each resource, a common cause failure group is added that simultaneously triggers the failure event of the resource and the failure events of all the functions supported by this resource. This model allows assessing the impact of hardware failures on functions and data flows in order to know whether the hardware architecture contains sufficient redundancy to support the functions, whether an allocation breaks segregation principles, …

Lessons Learnt

Case-studies Lessons Learnt

During the last year of the ASSERT project, the Altarica language and toolset was experimented on several case-studies called Pilot Projects:

• Astrium Space Transportation ATV GNC System • Dassault Aviation Flight Control System • Astrium Satellites Pleiades Spacecraft level FDIR System, • GTI6 studied a temporal redundancy scheme proposed by CNES.

Pilot Projects felt that the Altarica language and associated tools were simple to understand and use. Onera organised for ASSERT industrial partners a one-day tutorial session on model based safety assessment with Altarica and associated tools. This limited training seemed to be sufficient for starting the dependability modelling and assessment activities.

Dassault Aviation case-study showed that once a model of a system under design is built it is easy to perform safety assessment and comparisons of various modifications of the initial design. Dassault studied 5 variants of the Flight Control System.

Astrium Satellites would have liked to be able to describe components that include some parameterization in order to build more generic descriptions of the systems. This is currently not supported by the Altarica language.

The temporal redundancy case-study showed that it was possible to model with Altarica transient failure modes that are much more frequent in the Space domain than permanent failures.

The interactive simulation tool is very interesting both to assess the failure propagation in a functional model and also to assess the impact of hardware components failures at the functional level. Fault tree and Sequence generation tools are efficient. But to be applicable, fault tree generation requires the model to be static (i.e. the chronology of failures has no importance). It could be possible to control the edition of Altarica nodes and models in order to be sure to produce models that can be analysed with the fault-tree generator.

Pilot projects also noticed that, in the space industry, the generation of fault-trees or sequences that combine a big number of failures is not necessarily required to obtain dependability results. In such a context, it might be more valuable to support the generation of FMECA (Failure Modes Effect and Criticality Assessment) tables that is a cumbersome task in industrial projects. These tables detail the effect at a component level and at the system level of all single failures. The table also defines the severity of the failures. Cecilia OCAS offers today a rudimentary tool that generates FMECA tables from an Altarica model. This tool is currently being improved by Dassault Aviation in order to consider its use on space industry projects.

Integration of failure propagation models into model based development process

The decomposition of failure propagation models into, on one hand, a functional model that is independent of the underlying hardware and, on the other hand, a hardware architecture and an allocation model is consistent with one of the principles of model-based design. One limitation of the tested approach is that services offered by the operating system or the middleware layer such as communication, memory or time management are not modelled.

These services are particularly important for Space domain applications that tries to cope with transient failures. Onera has developed approach that includes these services in the scope of the models used to perform safety assessments but, due to the lack of time, the approach could not be tested on industrial case-studies.

A major concern raised by the Pilot Projects with respect to Altarica is related with the effort involved in building the failure propagation models and the possible inconsistencies between Altarica models and other models that are developed according to ASSERT process or, more generally, a model-based development process.

To limit the effort of building dependability models, Onera proposed to develop libraries of Altarica nodes that can be reused from one project to the other. This approach works well for families of systems that do not differ too much. But if a new technology appears and new associated failure modes have to be considered then the old library of components can no longer be used.

To avoid possible inconsistencies with other models developed in the context of ASSERT, Onera investigated a tool that generates an Altarica model from a model described in the AADL language [START_REF] Dumas | Vers la Génération de Modèles de Sûreté de Fonctionnement[END_REF]. The tool is based on model transformation technique. It extracts from the AADL model, the functional architecture, the hardware architecture and the allocation. The property declarations in the AADL model is used to associate an AADL process with the name of an Altarica node in the existing libraries, this node will be used to generate the Altarica model of the functional architecture.

To be able to generate the behaviour of Altarica nodes an alternative solution could consist into translating AADL code written following the Error Annex standard into Altarica. This seems feasible as LAAS investigated a similar approach during the first phase of the ASSERT project. In this case, the Altarica code might be much more complex than the one we have presented in this report.

Finally we would like to state that integration of dependability models in a model-based process is not limited to tools and languages interoperation. More fundamentally, the integration should define the role of the various kinds of analysis and their relationships.

Figure 1 :

 1 Figure 1: Failure transition

Figure 2 :

 2 Figure 2: Example of AltaRica node

Figure 3 :

 3 Figure 3: AltaRica model Top-level view of ATV architecture

Figure 5 :

 5 Figure 5: View of the hardware architecture

  has one output 0 and two inputs I1 and I2 that can propagate either correct or lost values as defined in section 2. The assertions indicate the computation formulae of output and local variables, which often consist in the description of flows values from states possible values. In the example of the figure2, the assertion states that the output flow O has a correct value when the node status is correct and all its inputs are correct. Else, the output is lost. The transitions describe the node's state changes under specific conditions, which follow event occurrences. In the example below, the loss event can trigger the transition only if the function is not already lost.

	node COMPUTATION_Function2
	flow
	O:COMPUTATION_FailureType:out;
	I1:COMPUTATION_FailureType:in;
	I2:COMPUTATION_FailureType:in;
	state
	Status:COMPUTATION_FailureType;
	event
	Loss,
	trans
	not(Status = lost) |-Loss ->
	Status:= lost;
	assert
	O = case {
	((Status = correct) and
	(I1 = correct) and
	(I2 = correct)) : correct,
	else lost
	};
	init
	Status:= correct;
	extern
	law (<event Loss>) = "exp 1e-4";
	.

Table 1 :

 1 ATV Dependability Assessment Results

			Prim&B Prim	Prim&B
		Loss	Loss	Err	Err
	1	8	0	0	0
	2	13	28	33	0
	3	70	622	142	510
	4	0	2756	235	3120
	proba 8. 1e-5 2.8 1e-9 8.7 1e-9 2.3 1e-12
	time	0.03 s	4.37 s	0.21 s	5.11 s


A Patrice Boulle

B Marie-Line Valentin

C Anthony Inard

A multi-model process for managing project complexity

Keywords: meta-model, multi-models, model transformation, UML

Developments of large software systems have to face an exponential increase in volume and complexity of the requisite knowledge, tighter time constraints and a continual growing number of stakeholders. Current solutions are based on breaking down the system or software components and equipments in smaller pieces in order to be able to handle them, but the side effect of this approach is to dilute the synthetic vision. This paper presents a model centric process supported by tools. This process is based on a multi-model approach for managing synthetic views and making project information available to all stakeholders, with an appropriate view and presentation.

Introduction

Today, companies developing large software or system engineering projects (aeronautics, space, defense, automotive…) have to deal with an exponential increase in volume and complexity of the requisite knowledge, tighter time constraints, and a continuously growing number of participants. Companies answer by a methodological reinforcement based on analytic breakdown, which strongly separates system components but dilutes the synthetic vision. This synthetic vision relies most often on synthesis capabilities and personal performance of Systems Engineers. Tools often propose a centralized data management based on document structure. This approach encounters several difficulties: • Data centralization does not suppress source multiplicity but increases duplication and then, inconsistency risks. • Data synchronization between database and sources are difficult and often impossible to achieve. Information is often incomplete or insufficiently verified. • Impacts of changes are difficult to estimate when the analyst needs to compile multiple sources of information. This paper presents a model centric process supported by tools, which is implemented in different application domains such as Air Traffic Control (EUROCONTROL), Aeronautics (Airbus) or Automatic Railway System. This process is based on a multi-model approach for managing synthetic views and making project information available to all stakeholders, with an appropriate view and presentation. The objectives of the process are the following:

• Urge project members to structure and formalize their knowledge and their system view by the means of connected models (Requirements, Architecture, Component, Deployment, Interface / Communication and Equipment / Execution Platform), • Support teamwork by sharing and synchronizing relevant information, • Produce adapted models that contain linked information necessary for a specific task, • Manage dependencies and consistency between the different models, especially when their development lifecycles are different, • Establish and evaluate impacts and costs linked to changes, • Produce an up-to-date status of the project developments. The process is supported by a prototype tool named MME for Multi-model Editor developed by SYSALYS. The concepts used by each type of stakeholder are defined through meta-models. MME provides import, export and filtering capabilities, which support merging, linking and "gluing" information coming from various documents or models produced by different tools.

In this article, for each issue identified in a multimodel approach, we describe the process to handle the issue and illustrate it with the support of the MME tool.

Multi sources of information and Metamodel definition

A model driven process aims at representing in models all the project information and links which exist between them [START_REF] Breton | Model-Driven Process Engineering[END_REF]. This information is contained in documents, which most often have different formats. For example, a use case and its actors can be defined in a UML model but conditions, steps, alternatives and traceability links towards the requirements can remain outside the model, in an external document although they constitute also essential data for the project.

Figure 1: Exchange Model Context

If the reference is a UML model or a database, the structure and, to a certain extent, the semantics of information is defined with precision; that is not always the case if the reference is a text or a proprietary tool file. The first thing to do is to draw up the list of the documents which contain the project data, to describe for each one the information it contains and to clarify the links between information defined in the different documents. Information, which is repeated in several documents, must be highlighted, in order to determine where it is defined (origin of the definition) and where it is referred to or made more precise. This activity results in the elaboration of the meta-model.

The data and their relationships modelling in a metamodel is an essential activity for the mastering of the models. At this stage, it is not necessary to clarify all the data and the internal links but it is essential to focus on the data shared by several documents and the links between the data located in different documents.

For example, the functional requirements have to be traced in the other models and thus have to be extracted and referred to in the other models of the project. On the other hand, the additional data which is necessary to be added in order to be able to simulate and to validate the model at a given phase of the development (for example, during system design) should not be exported to the next development phase (in the same example, to the software specification). The border between "private" data to a given activity or a given user profile is not easy to determine, and that's why the meta-model has to be updated throughout the project life cycle, each time new documents, new links… have to be taken into account. The review of the meta-model allows to highlight implicit data, links which are not obvious or redundancies / ambiguities in the definitions.

Importing and Exporting data

The model provides a picture of the essential data of the project and the links between these data. The data have to be extracted from the documents or the files in which they are defined or referred to, in order to present them in a view, which complies to the meta-model. For example, a system requirement is defined in the system design model and can be referred to in test cases, in change requests or in the software component which implements it. Each model can bring precision on a shared data. MME provides filtering functions, which make it possible to create a subset starting from a reference model according to various criteria (direct selection or advanced search). It is for example possible to extract from the system design model, the use cases, the requirements and the interfaces associated with a software function, in order to create an autonomous and self-sufficient software specification model. Thus the software team responsible for this function development gets a sub-model initialised with the only necessary information. In the same way, starting from the exchange model, it is possible to extract the use cases and the system requirements in order to initialise the validation model. A UML/XMI export tool in MME allows the creation of a UML 2 model with the adequate profiles. Vice versa, a UML/XMI import tool allows the importation in the exchange model of the modifications done in a sub-model. The separation of the reference model in an assembly of sub-models adapted to a specific activity makes it possible to control complexity, to specify in the meta-model the useful information for each activity and to reveal the shared data.

Traceability management

The traceability management is an essential activity of a model driven process. The definition of the links, which exist between the major data of the project, is performed in the meta-model. The traceability can be initialised automatically by the import tools but has to be completed explicitly by the various teams. For example, the traceability between a functional requirement and a more specific software requirement, a software use case or a software architecture component has to be established explicitly.

It is important to control the traceability links by specifying them in the meta-model, in order to avoid an anarchistic proliferation of the links. But it should be also possible to create "free" links between data, which are not linked in a meta-model, for the purpose of annotation as an example. The users should be able to establish and extract easily the traceability links, for example:

• To retrieve the system requirements which are not covered by a software element or a validation test, • To assess the impact analysis of a modification (impacted use case, interfaces, components or test cases) • To obtain relevant metrics on a modification cost. It should be noted that during the iterative cycle, it is necessary to synchronise the traceability links and to indicate the obsolete links. A component of the architecture model can refer to a requirement of the software model. In this case, the user can create the link by a simple drag&drop. MME allows to link data which are not linked in their meta-model by means of undifferentiated links. These links are very useful to manage annotation models associated with a model. MME provides various tools in order to display or to follow the links. It also provides queries to generate traceability matrixes and manage duplicated data. The traceability management helps to clarify the links existing between documents of different formats, to be able to analyse the impact of a modification by going all over the chain of links. Since the traceability information is defined at the level of the exchange model, it does not pollute the documents themselves.

Collaborative modelling

Project model elements are shared by different participants and in different activities. Each participant may have his/her own view on shared data. Shared data may be duplicated in different models or documents. Each activity may have its own lifecycle. It is mandatory to manage and to synchronize the shared data modifications. A change control process needs to be implemented in order to master modifications of shared data avoiding concurrent access. For example, the system design model defines the software components architecture, the responsibilities of each software component, the interfaces and the interaction between components. Software components may be realised by different teams. The validation model is built from the requirements and the use cases of the system design model. The system design model is connected to its submodels (software components models and validation model) but the sub-models are not connected. If a software team needs to modify a shared data or a responsibility, the modification has to be propagated to the system design model and, possibly, to the validation model. To avoid anarchic modifications, each model should be defined with an "exchange area". When a shared data needs to be modified or to be added, it is moved in the "exchange area", so the modification is traced and is local to the submodel. When the system model and the sub-models need to be synchronized, the tool analyses the exchange area of the sub-models and proposes a set of correction. Note that the system team may take into account new requirements. The modifications are propagated to the sub-models. The synchronisation process may be iterative, each team can analyse the impact of the corrections using traceability links and estimate modification cost. When the corrections are approved, the sub-models are updated in two phases:

• The modifications are propagated to the submodels, new data are added, modified data are updated and marked as modified and removed data are marked but are not deleted. Data that depend from updated or deleted data are also marked using traceability in order to make easier the impact analysis. This process is realised by MME • The model is updated by the responsible team using the update marks. Obsolete data and marks are manually deleted. • Merge models, for example two software components are merged because they share common responsibilities • Split a model in several models in order to master its complexity, for example if a software component is split in two components, the interfaces of the new components need to be defined and have to be propagated to the clients of the split components. MME provides simple and easy to use mechanisms for model transformation.

• an export function allows to save the data contained in structured tables or spreadsheets, using the current version of the meta-model, • an import function creates a model from the tables or the spreadsheets using the new version of the meta-model. Complementary scripts may be necessary to modify the tables. Model transformation provided by MME should be improved in future versions [START_REF] Jezequel | A MDA approach to model and implement transformations[END_REF]. Model evolution and adaption are critical issues, because, in a model centric approach, the exchange model has to evolve in order to take into account new data and new project participants. Model transformation is necessary when developments of a project are reused in a different context.

Conclusion

A first feedback of operational implementations shows that the multi-model process allows a better communication between teams: each participant works with his/her own tools or languages but can share a subset of the information he/she manages with other teams by the means of integration models. The tool provides an efficient support to modifications propagation among the different views. Above all, this approach allows to build multiple and consistent views of the system and thus to recover the control of the overall system. MME is the result of a long experience in modelling and is currently used to develop large models. The next step will be to industrialize the prototype tool MME in order to provide a robust and durable support to the elaborated process. The envisioned way is to develop MME in the frame of the open source engineering framework TopCased [START_REF] Pantel | The TOPCASED project -a Toolkit in OPen source for Critical Applications and SystEms DesignDocument Actions " 10. Glossary API: Application Programming Interface ATM: Air Traffic Management MME: Multi-Model Editor UML: Unified Modeling Language XMI: XML Metadata Interchange XML: eXtensible Markup Language[END_REF].

  the documents allows the detection of lacks, ambiguities and redundancies. It also makes it possible to propose modifications of the textual documents contents and format, in order to improve the presentation and to facilitate information extraction.The MME tool provides a meta-model editor, which allows in a simple way the definition of the project meta-model. Each data is defined with its properties and its links. The compilation of the meta-model generates the body of a MME editor associated with the meta-model and also the related documentation.

Figure 2 :

 2 Figure 2: Meta Model

Figure 3 :

 3 Figure 3: Model editor corresponding to the "MetaSystem" meta-model

  To build and update the model, it is necessary to implement mechanisms of extraction and filtering from the various documents or files. These documents or files have various formats: the files produced by tools such as UML editors follow an XMI representation which allows a quite easy extraction and a simple filtering; other tools with a proprietary format provide an API which makes it possible to export relevant information, with more or less significant development. The importation of essential data contained in the documents is a critical phase of a model driven process. The implementation of the import function may require complex developments and generally requires the development of a corresponding export function in order to be able to re-synchronize the documents with updated information. The resulting model can be considered as a high level model or an exchange model, which contains the essential data with their links. MME provides tools which allow to import data starting from the documents developed with standard text editors (word, excel…) and editors providing an XML output (UML/XMI). It is also possible with MME to create extraction scripts, which use the tools API.

Figure 4 :

 4 Figure 4:Importation and exportation of a model using a spreadsheet (figure provided by courtesy of EUROCONTROL) The exchange model can be modified directly in MME (by adding, removing or modifying items of model if the corresponding meta-model permits it). Then the export functions provided by MME allow the propagation of modifications into the source documents. The UML/XMI export function makes it possible to create a model UML starting from the exchange model. For example, starting from the extraction of the relevant data from the system design model contained in the exchange model, it is possible to initiate a validation model by inserting the necessary data in it [2].

Figure 5 :

 5 Figure 5: Creation and Synchronisation of models through the Exchange Model

Figure 6 :

 6 Figure 6: Links between models (figure provided by courtesy of EUROCONTROL)

Figure 7 :

 7 Figure 7: Filtering model (figure provided by courtesy of EUROCONTROL)

  Figure 8: Sub-models structure

Figure 9 :

 9 Figure 9: Extraction and Analysis of the sub-model exchange areas.

  to create and update the model of the project, and thus to be able to use alternative editors for the model information. A graphic modelling language such as UML is complex and requires a good level of training. It can be preferable to provide the participants who are not familiar with UML, a view of the model, which is appropriate to them, using for example a text editor or a calculation sheet. In the same way, to create or update a model UML, it can be interesting for the participants to publish their contributions in pre-formatted documents (table or sheet). The creation and the update of the model and the UML diagrams are performed by specific importation tools starting from the meta-model. The import/export functions really make the m polymorph and able to be presented, at least partially, in various formats adapted to the skill and the activity of each participant.

	G
	whatever the selected development cycle is
	(incremental, iterative, etc), a growing number of
	data coming from different sources are integrated in
	the exchange model. The model must take into
	account information from new stakeholders
	(integration, quality, certification, validation, user
	support…) On the basis of a reference model, it
	should be possible to extract the most adapted views
	for a given type of user, for a development phase, for
	a delivery or for an activity. The objective is to show
	only relevant information, by reorganising them if
	necessary but while guaranteeing the total
	consistency of the model.
	A monolithic exchange mo
	of the project is centralised is useful to provide a
	global view of the project, but it is not adapted to
	perform a specific activity (validation, verification of
	the traceability…) It is necessary to separate the
	model in consistent sub-models easiest to manage,
	and ensure that the modifications performed in the
	sub-models are propagated towards the reference
	model.
	MME a
	same session. MME provides mechanisms, which
	make it possible to separate a model in a set of
	models. The links and the shared data are defined in
	the meta-model, so that the data can be defined in a
	model but referred in other models.