Cas d'étude avionique du projet MERgE : un exemple de ...

19e Congrès de Maîtrise des Risques et Sûreté de Fonctionnement - Dijon 21-23 octobre 2014

CAS D’ETUDE AVIONIQUE DU PROJET MERgE : UN EXEMPLE DE CHAINE D’OUTILS INTEGREE POUR LES ETUDES DE SECURITE

MERgE AVIONICS USE CASE: EXAMPLE OF AN INTEGRATED SAFETY TOOLCHAIN

Authors: Frédérique Vallée Javier Fernandez Briones Mohamed Bakkali All4tec Space Applications Services NV/SA Massy, France Zaventem, Belgium [email protected] [email protected] [email protected]

Résumé Cet article présente les résultats intermédiaires des travaux réalisés dans le cadre du projet européen ITEA2 MERge. Un focus est fait sur le use case du domaine aérospatial pour lequel une nouvelle chaîne d’outil est développée pour couvrir les besoins habituels du domaine en termes de disponibilité et sécurité. L’article pose le problème et montre les facilités d’intégration et les bénéfices de l’approche innovante proposée. Mots clés : Chaîne d’outils pour la disponibilité ; Applications spatiales ; Disponibilité et sécurité du logiciel ; MERgE; ITEA2

Summary This papers presents the preliminary results of the work undertaken in the context of the MERgE ITEA2 research project on its aerospace use case. It shows how a new tool chain has been introduced in order to cover the current avionics dependability and safety practices, highlighting the integration easiness and the benefits of this innovative approach. Keywords: Dependability tool chain; Space applications; Software Dependability and Safety; MERgE; ITEA2

Work Context

The MERgE Project

MERgE stands for "Multi-Concerns Interactions System Engineering". Within the "Engineering support" theme of ITEA2 roadmap, the purpose of this project is to develop and demonstrate innovative concepts and design tools addressing in combination the "Safety" and "Security" concerns, targeting the elaboration of effective architectural solutions. In a variety of application domains (e.g. avionics, telecommunications, transportation, automotive, energy industry), engineering methods and practices, engineering support tools, and architectural solutions are available to answer demanding safety or security requirements. Such methods, tools, and architectural solutions can be enforced by domain specific standards and certification processes. The MERgE consortium is composed of companies and universities form France, Belgium and Finland as described in Figure 1.

Communication 3C-4 sur 7


Figure 1. MERgE consortium

Many research projects such as MBAT or CRYSTAL have already been focused on the validation of complex embedded systems but MERgE aims particularly to bring a system engineering solution for Combined Safe & Secure system design. MERgE aims also to answer the limitations in IMOFIS and CESAR by addressing the security requirements along with the safety requirements.

The main technical innovation of the project is the application of state of the art design tools tailorisation capabilities and "multi concern engineering" core technologies to the issue of interactions of "Safety" and "Security" concerns as well as other concerns like "Performance" or "Timing" in the design process.

Use cases in the aerospace, telecommunications, energy, automotive and transportation industry domains will demonstrate: the usability of such concepts and tools to support combined multi-concerns, in particular safe & secure system design; the role of such tools for early assessment of candidate architectures, including in particular architectural disruptions, based on innovative "Safe and Secure" run-time support; the acceptability of the concepts and tooling by system architects, safety experts and security experts; the flexibility of the tooling to adapt to different application domains and other concerns.

A short term impact is expected in terms of adoption of the proposed tools by the domains represented in the project, dealing with critical systems. It is also foreseen that the "multi-concerns" core technologies will have a range of applications in other domains, submitted to less critical, but still multiple, constraints.

In the medium term, availability of such innovative tool support for critical systems is regarded as a key enabler for the evolution of engineering practices and methodologies.

The aerospace use case of the MERgE project is provided by the Belgium Company Space Applications Services NV (SASNV).

The SASNV problematic

One of the solutions offered by SASNV is the development and deployment of avionics on-board software for aerospace systems. The current process and tool chain used to support these activities have several limitation to support product qualification. For these reasons, in the scope of the MERgE project, SASNV aims to enhance the dependability and safety aspects of the system during the development of avionics on-board software.

SASNV is currently using a set of tools to support the software development activities performed across different projects. The following list presents the tools currently used at the Avionics and Embedded System Team:

IBM Rational DOORS, used during the Requirement Baseline, Technical Requirements and Validation Activities (Test Cases definition). MagicDraw and Cameo DataHub, used during Requirement Baseline (Use Cases), Software Architecture Design and Software Component Design. VectorCAST, used during the Verification Activities (Unit and Integration Test). Virtual Machine Development Environment, used during the Implementation Activities.

A set of additional tools is used also to support additional activities associated with specific projects.

The current toolchain used at SASNV presents the following drawbacks: Safety analyses (SFTA, SFMECA and HSIA), required by the space industry standards are currently performed manually. There is no tool available to support any sort of automation of the analysis. Also, there is no automatic traceability between the safety analysis and the new software requirements derived from the analysis. The implementation phase is currently performed by manual coding from the software architecture and component design. There is no trace between the features implemented and the software design. Some verification activities such as: static analysis, dynamic analysis, worst case scenario, schedulability analysis, memory profiling, coding standard compliance are performed manually and are not integrated in the toolchain. The validation activities are currently performed manually in the form of list of test cases. The tool Vector CAST could allow to automate black box testing. Also there is no element available to perform verification and validation elements at the software architecture design level. The current situation impacts the reliability aspects of the product and as a consequence impact directly in the capabilities of the company to address more complex systems.

The SASNV Use Case In order to verify that the research performed in the project has a significant impact, SASNV provides the software component 'OBCP Engine’ currently under development to be used as a playground. The OBCP engine is a on-board software component in charge of controlling and managing the configuration of the spacecraft subsystems across different phases of a mission. The artifacts available for this software component are the following: technical requirements, software architecture design, source code, test cases, dependability and safety analysis, traceability tables.

Mission Context

Future space missions will demand increased flexibility and performance. This is especially the case for exploration spacecraft which will rendezvous and dock with a variety of spacecraft, perform cargo and crew transportation, as well as long duration missions and support in orbit assembly.



Building on the success and heritage of the ATV spacecraft, the European Space Agency follows an evolutionary approach towards future vehicles. The Advanced Re-entry Vehicle (ARV) was initially proposed as a successor to the ATV that would provide cargo download capability, and that would later evolve to transport crew. The focus has later changed towards an ATV derived concept, a derivative of the ATV Service Module that would support transportation, in orbit assembly and other missions. This concept originates from the activities regarding the service module and the docking system of the ARV. These elements are generic and can be used not only in combination with a re-entry capsule, but also with arbitrary cargo containers or station modules, or to carry out in orbit servicing missions. The reference concept for the mission maintains some of the capabilities of the ATV, and improves or introduces some new ones. The vehicle will be able to carry a cargo container or pressurized module to the ISS, and it will provide power and thermal control to its payload. At the end of its mission, the vehicle will be able to separate from the module and re-enter the atmosphere autonomously for disposal. One of the key novel capabilities required by future flexible spacecraft is the ability to perform operations using automation systems which are flexible enough to cost effectively accommodate the planned and unplanned future missions. These systems shall support different levels of automation, from fully automated operations triggered from ground, to crew monitoring and overriding of the automatic functions.

OAS overview

The OAS is the set of on-board computerised functions that manage the spacecraft operations. It corresponds to a subset of the spacecraft software functions and the hardware platforms that support them. While the traditional approach to avionics and on-board software considers a partition of the computerised elements based on individual subsystems (e.g. EPS) or functions (e.g. GNC, TM/TC), the OAS concept proposes a holistic view of the hardware and software components that support mission operations. This makes it possible to design and build systems that can more easily evolve and adapt with the spacecraft to support future missions. The concept of an OAS is originally defined in the context of the Advanced Re-entry Vehicle (ARV), a European space transportation system derived from ATV that would provide the capability for round-trip space transportation. In a first step the ARV would transport cargo to and from the ISS, and later a manned vehicle would follow. The OAS is conceived to support the evolution of the mission from cargo delivery to and from the ISS, to manned transport to the ISS and future destinations. The capability to adapt in a cost-effective way to new scenarios is critical for future transportation and exploration missions, and it is in general useful for any kind of spacecraft. Spacecraft operations involve ground controllers, on-board automation and crew (if present). The approach to operations as a whole allows a better understanding of the interactions among them. This is crucial in operations with the human in the loop, for instance whenever the crew has the capability to override automatic functions. The objective of the OAS activities is to develop a system with emphasis on the most critical functions in terms of feasibility, performance, criticality, robustness and ability to transition from an unmanned to a manned vehicle. For practical purposes the functions of the Operations Avionics Subsystem can be divided in two areas:

Mission and Vehicle Management (MVM). Cockpit Display System (CDS).

The MVM function covers the overall vehicle control, including the high-level failure and configuration management and the procedure automation. It is in charge of providing automation capabilities that include monitoring and analysis of telemetry and system states, decision support, and execution of decisions and plans. It represents the functions common to manned and unmanned missions. The CDS is in charge of providing capabilities to the crew for the control and monitoring of the spacecraft by interacting with the automation. The related functionalities apply, naturally, only to manned missions.

On board Control Procedure (OBCP) At the core of the OAS lies an On-Board Control Procedure (OBCP) engine whose capabilities and interfaces are defined in accordance with the ECSS-E-ST-70-01C standard on Spacecraft On-board Control Procedures. The procedure engine is one of the building blocks defined by ESA’s avionics and software reference architecture. OBCPs are procedures run by a software engine on-board a spacecraft and that can be easily loaded, executed and also replaced without modifying the remainder of the on-board software. They increase spacecraft autonomy, for instance in deep-space missions, and their modifiability and fault handling properties make them a useful alternative to traditional on-board software in certain scenarios. For the purposes of the OAS project OBCP is developed as a service that can be used by another component of the on-board software. For instance, the OBCP engine can be used by applications present in the MVM or CDS. The communication of the OAS with other subsystems is based on the Spacecraft On-board Interface Services (CCSDS SOIS) specification. This ensures interoperability with external building blocks. SOIS improves the spacecraft flight segment data systems design and development process by defining generic services that simplify the way flight software interacts with hardware and enables interoperability and reusability.



Method

The set of activities performed during the MERgE project consists in overcoming the limitations on the avionics software development process and tool chain by proposing new tools or processes. The new set of elements is tested using the use case demonstrator ‘OBCP Engine’.

Model-Based Safeyt Analysis (MBSA)

Model-Based Safety Analysis relies on the idea that SA activities can follow the design process in a parallel flow using the system architecture as a common basis. The system model is used to capture the overall architecture and the interactions between its components. Then this abstract view of the system may be enriched with safety information using dedicated annotations in order to describe possible dysfunctional behaviors.

Model-based Safety Analysis refers to the system level models that enable to simulate the behavior of complex systems, as well as to use various analysis techniques supporting the engineering process within a common model-based design environment. Convenient frameworks, such as the Eclipse Modeling Tool project, are available to capture model information and to provide different dedicated analysis views. They offer facilities to customize models, perform validation according to meta-model conformance and/or domain specific rules, write transformation modules towards dedicated formal languages to permit further analysis with other SA tools.

All4Tec has proposed its tool Safety Architect (SA) in the MeRge project in order to perform MBSA. In the following section we describe our SA methodology and we position it in the system engineering development life-cycle.

Safety Architect methodology

The underlying methodology used in the tool Safety Architect© is based on the new approaches recently developed for improving the design of very complex systems or of systems of systems. This approaches are notably supported by system engineering associations such as INCOSE (The International Council on Systems Engineering) or AFIS (Association Française d’Ingénierie Système) in France.

One of the main innovations of these associations is to propose a decomposition of the complex systems into “block-systems” on which a specific life cycle is applied and which is sufficiently simple to be manage by a system engineering team.

A block-system is decomposed into elementary components. The input of the block-system design is its “needs” and the development life cycle produces at the end the needs of each of the components. When a component is too complex, it is considered as a block-system and follows a new block-system development life cycle. The approach is recursive until the components are simple enough to follow a more classical development life cycle.

From a safety point of view, the objective of the block-system life cycle is to transform the system safety requirements that are expressed as feared events in the needs into components safety requirements. Therefore FMEA and Failure Tree Analysis (FTA) are necessary.

Two FMEA are necessary: one “functional FMEA” to define the functional safety concept to be applied on the block-system and one “physical safety concept” to demonstrate how the block-system architecture will fulfil its safety requirements. This is expressed in Figure 2:

Figure 2. Safety Analysis in the block system development life-cycle

Adaptations needed for the SASNV use case In the context of the MeRge project, the tool SA must be adapted to comply with SASNV needs. The main aspects to handle are:

Needs analysisRequirements

writing

Functional

design

Physical

design

Integration

Qualification

Components

reception

Verification

validation Changes Dependability Traceability Optimisation

Test means

preparation

Physical

FMEA

Functional

FMEA

System FE

Components FE



Doors integration Magic Draw integration FMECA adaptations HSIA management

This aspects and their progress are described here after.

Work Performed and Main Results

SA training All4Tec began with a streaming presentation to show the tool to SASNV. The goal for SASNV is to get expertise on how to use the tool.

Doors integration

SASNV must define the requisites for the integration of DOORS with SA so that All4Tec can enable such integration. This activity is not yet finished.

Magic Draw integration

SASNV has done a roundtrip analysis process to examine how their architectural models in Magic Draw could be moved into Safety Architect for analyses and which architectural improvements resulting from such analyses should be incorporated back into Magic Draw. SASNV has shown the current modelling approach to All4tec and All4tec has examined how to create SA-ready architectural models in MagicDraw to SASNV.

Figure 3. Architecture representation imported in Safety Architect Papyrus is pointed out as an enabler for the integration between Magic Draw and Safety Architect. The use of multiple operational modes is seen as a potential mismatch between the SASNV and SA modelling approaches.

Failure Mode Effects and Criticality Analysis (FMECA) Adaptations

SASNV needs SFMECA analyses to be performed according to ECSS standards. For that reason, All4tec will need to include new fields to specify SFMECA attributes (failure cause, criticality, failure detection remarks, compensation, etc.). Other fields may also be useful for knowledge management. Safety Architect gives the possibility to define the dysfunctional behaviour of each elementary block (see examples given by Figures 4 and 5) and automatically generates fault tress for each hazard identified on the systems outputs. An example of fault tree provided by Safety Architect is described in Figure 6.

Figure 4. First example of dysfunctional modelling

Figure 5. Second example of dysfunctional modelling

Main function with a barrier that elimnates the sensor errors

Hazard

Hazard Sensor with a filter



Figure 6. Explained Fault tree

The tool Safety Architect is able to automatically generate FMEA tables as shown in Figure 7 but these tables do not meet the SASNV requirements.

Figure 7. Generated FMEA table

SASNV objective is to be able to quickly rank the residual risks with 3 criteria that are: severity, probability of occurrence and ease of detection. The ranking is obtained with the following formula: Rank = Severity * Probability * Detection where the figures for each element of the product are defined in the tables given in Figures 8, 9 and 10.

Figure 8. Severity Ranking

Figure 9. Probability Ranking

Figure 10. Detection Ranking

Ranking Effect

1 None

2 Very Minor

3 Minor

4 Very Low

5 Low

6 Moderate

7 High

8 Very High

9 Hazardous with warning

10 Hazardous without warning

Severity

Ranking Category

1 Incredible

3 Improbable

5 Remote

7 Occasional

9 Probable

10 Frequent

Probability Ranking Detection

1 Almost Certain

2 Very High

3 High

4 Moderately High

5 Moderate

6 Low

7 Very Low

8 Remote

9 Very Remore

10 Absolute Uncertainly

Detection



The specification of SASVN needs have been written and the implementation into Safety Architect is in progress.

Hardware/Software Interface Analysis (HSIA) This analysis may be included to the Safety Architect portfolio with an implementation based on hardware interfaces. It needs further study. This work has now been specified and is still under investigation.

Conclusion

The MERgE project is aiming at providing methods and tools able to deal with safety and security aspects in the context of model driven engineering.

The MERgE project will continue in its work of tool chain definition and improvement. More especially for the Aerospace use case, there is still a lot of work to do in order to reach the following objectives:

Applicability of the proposed tool chain to the Aerospace context. Coverage of the current avionics dependability and safety practices. Integration easiness of new processes and tools. Assessment of the benefits acquired during the activity.

Bibliography ECSS-E-ST-70-01C: ECSS Space Engineering. Spacecraft On-Board Control Procedures. ECSS-Q-80-03: ECSS Space Engineering. Method and Techniques to Support the Assessment of Software Dependability and Safety. ECSS-Q-HB-80-03A: ECSS Space Engineering. Software Dependability and Safety. Outil Safety Achitect – www.all4tec.net Safety Architect© : Un outil d’analyse de risques s’inscrivant dans les processus d’ingénierie de systèmes complexes - Revue Génie Logiciel – n° 98 - septembre 2011 Projet CESAR - www.cesarproject.eu Projet CRYSTAL - www.crystal-artemis.eu Projet IMOFIS - http://www.imofis.org Projet MBAT - http://www.mbat-artemis.eu Projet MeRGE - http://www.merge-project.eu AFIS website: http://www.afis.org INCOSE website: http://www.incose.org


http://www.all4tec.net/

http://www.merge-project.eu/

http://www.incose.org/

Cas d'étude avionique du projet MERgE : un exemple de ...

Documents

Transcript of Cas d'étude avionique du projet MERgE : un exemple de ...