vers une approche de l’iso 26262 basée sur les modèles

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

Vers une approche de l’ISO26262 basée sur les modèles avec AltaRica Toward a model-based approach of ISO26262 using AltaRica

Florent MEURVILLE Valeo – GEEDS 2 rue André Boulle 94046 Créteil Cedex

Loïc QUERAN Dassault Systèmes 120 rue René Descartes 29280 Plouzané

Nicolas BELLON Dassault Systèmes 10 rue Marcel Dassault 78140 Vélizy

Résumé:

L’objectif de cet article est de montrer qu’AltaRica, largement utilisé aujourd’hui dans différents domaines tels que l’aéronautique, le ferroviaire, et le nucléaire notamment afin de démontrer que les objectifs de sécurité sont atteints, a un intérêt dans le domaine automobile et plus particulièrement dans le contexte de l’ISO26262 grâce à certaines adaptations. Une des grandes particularités de l’ISO26262 par rapport à d’autres standards sécuritaires est le besoin de calculer des métriques d’architecture qui permettent de valider/vérifier le concept de sécurité. Ce calcul des métriques tel que présenté dans l’ISO26262 Part 5 Annex E à un niveau de modélisation très bas de type schéma électrique n’est pas possible avec AltaRica. Cependant, grâce à une technique éprouvée par Valeo depuis plusieurs années, il est possible d’étendre ce calcul des métriques à des niveaux d’abstractions supérieurs pour lesquels un modèle AltaRica de plus haut niveau peut alors être construit. Après avoir résolu les problèmes du calcul de la métrique latente pour laquelle la modélisation de la perception du conducteur est nécessaire, nous montrerons à l’aide d’un exemple concret que le calcul des métriques tel que défini par ISO26262 est maintenant une réalité avec AltaRica. Abstract: The goal of this article is to show that AltaRica that is used today in different domains such as aeronautics, railways, nuclear to demonstrate that safety objectives are reached could also be used in the automotive industry and particularly in the context of ISO26262 thanks to small modifications. One of the main particularities of ISO26262 compared to other safety standards is the need to calculate specific architectural metrics to validate / verify the safety concept. The calculation as showed in ISO26262 Part 5 Annex E at a very low level of modeling such as an electrical schematic is not possible with AltaRica. Nevertheless, thanks to an alternative technique used for more than 5 years in Valeo, it is possible to extend these metrics at higher abstractions levels for which it is possible to build an AltaRica model. After having solved the problematic of calculating the latent metrics with the modeling of the driver perception it will be demonstrated with a concrete example that calculation of metrics as defined in the ISO26262 is now a reality in AltaRica.

1. Introduction

Published in 2011, the ISO26262 standard [1] is divided into 9 normative parts, to which is attached a tenth informative part [2]. This new standard defines more than 500 requirements applicable to the design of Electrical / Electronic systems embedded in road vehicles. In a competitive market, the actors must transform the inevitable challenges represented by such an amount of constraints into an opportunity to design more efficiently systems as safe as intended. The ITEA2 SAFE project has made it possible to adapt both the traditional safety analysis methods and the model-based approaches backed by AltaRica to these new requirements.

2. A brief introduction to ISO26262 and its main concern during the design phase After the initiation of the safety lifecycle, the hazard analysis and risk assessment is performed during the concept phase. The risk assessment is based on the item’s functional behavior and consists in evaluating its potential hazardous events with regards to the probability of exposure, the severity and the controllability. This last criterion is original and reflects the ability of the driver to control the hazardous situation. Together, these parameters (exposure + severity + controllability) determine the ASILs (Automotive Safety Integrity Level) of the hazardous events: ASIL A being the less critical whereas ASIL D represents the most critical. The hazardous events enable then to identify the safety goals which are the top level safety requirements for the item to be developed. Safety goals inherit the highest ASIL determined for the hazardous events that are assigned to them. The hazard and risk analysis is a fundamental step: the safety goals that it defines are the roots from which are derived the safety requirements to functional and technical levels. Once the main architectural assumptions and safety goals are known, a safety concept at functional level is built to provide an appropriate level of confidence. In the vision proposed by the ISO26262, this concept results in functional safety requirements derived from the safety goals and allocated to the functional blocks identified in the preliminary architectural assumptions. Also the warning and degradation concepts must be specified. Conventional safety analyses techniques (e.g. FMEA, FTA ...) have to be performed at this level to help verifying/improving the design.

Communication 7C-4 sur 10


During the system development phase, functional safety requirements are then refined into technical safety requirements based on assumptions on the technical architecture. Technical safety requirements identify in particular the safety mechanisms that allow the system to prevent one or more failures from violating a safety goal either directly or in combination with other independent failures. As for the functional safety concept, this activity is supported by conventional safety analyses techniques. Once the technical requirements are defined and allocated to the technical blocks, the technical safety concept is established. For integrity levels of the highest criticality (C and D), the use of simulation is also highly recommended to check the design (ISO26262 Part 4 Clause 7.4.8.1 Table 3_2a [1]), which should not be confused with physical tests on prototypes (ISO26262 Part 4 Clause 7.4.8.1 Table 3_2b [1]). The technical concept aims to ensure a consistent decomposition of the system into subsystems with controlled interfaces, each subsystem being testable in isolation and the integration of subsystems itself being checked and tested. Finally, hardware and software safety requirements are derived from technical requirements with the help of safety analyses and allocated to hardware and software detailed design. Also, for random hardware failures, the ISO26262 Part 5 [1] adds constraints to the design by defining three quantitative metrics for each safety goal whose targets are ASIL dependent:

The Single-Point Fault Metric (SPFM), which can informally be defined as the proportion of safety related random hardware faults that do not directly lead to the violation of a safety goal.

The Latent Fault Metric (LFM), which can informally be defined as the proportion of latent safety related random hardware

faults whose presence is either detected by a safety mechanism or perceived by the driver before the violation of a safety goal occurs.

The Probabilistic Metric for random Hardware Failure (PMHF) which can be informally defined as the residual risk of violating a

safety goal due to single-point faults, residual faults, and plausible dual-point faults (multiple-point faults > 2 can be also be considered if relevant).

These metrics are part of the evidence that the design complies with the safety goals. The overall quantitative targets assigned at top level of the architecture are in a first step distributed to the different elements of the technical architectural when building the safety concept. Then, in a second step, when the implementation of safety requirements is complete, metrics are verified and rebuilt up to the top level architecture. If some of the targets are not reached, the detailed design has to be reworked. That is why performing this verification of metrics as early as possible is crucial to avoid ‘last-minute’ modifications that are often error prone.

3. A first analysis of what could be done or not be done using AltaRica before the ITEA2 SAFE project

AltaRica is a language that was developed at the end of the 1990s to model event-driven complex systems. It is often used to perform model-based safety analyses. Numerous articles have already been published on AltaRica. The specification of AltaRica Data Flow [4] is an interesting introduction. The objective in this section is only to highlight which activities in the context of the ISO26262 [1] could benefit from AltaRica, and to pinpoint some limits either in the language or in current tools. The following figure is proposed by the ISO26262 standard [1]. The sections to which AltaRica could be related most easily are outlined by a red frame. This does not mean however that AltaRica could not help for example to build tests (5.10, 6.9 …).

Figure 1. Applicability of AltaRica to ISO 26262 Safety Lifecycle [1]



Obviously, the core benefits of AltaRica models are obtained in the definition of functional and technical safety concepts (3.8, 4.6). The models shall be developed to check whether the safety goals that result from the hazard analysis and risk assessment (3.7) are covered. In a traditional analysis, the safety cases, made up of many spreadsheets or textual documents, or to specialized tools such as fault tree analyzers or FMEA tools, are often hard to develop and relatively fragile. Maintaining the consistency of these analyses with concurrent changes in functional or technical designs may be challenging. The inconsistencies in textual documents are not necessarily obvious. On the contrary, the intrinsic consistency of AltaRica models is checked automatically and, provided that the language can express well-formed problems, an AltaRica model is a convincing and easily verifiable means to demonstrate a safe design: current tools can exhaustively simulate sequences of faults, which may be economically not feasible manually by human operator. Models can even be simulated with the injection of faults that sometimes cannot be tested physically. The Figure 2 illustrates this type of simulation in the context of an industrial use case of an electrical steering column actuation system (made of 4 wheels sensors, 3 ECUS and 1 actuator) proposed by Valeo.

Figure 2. High level view of Valeo ESCL system model being simulated with fault injection

But the initial status is quite paradoxical. Whereas AltaRica can appear as an advanced approach to carry out safety analyses, its application even to the simple example in the ISO26262 Part 5 Annex E [1], proves to be difficult. For example, the safety mechanisms are “technical solutions implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state” [1]. Modeling these mechanisms is common practice in AltaRica. But the safety mechanisms are not semantically identified as such, and are sometimes a consequence of a redundant architecture rather than implemented by a specific component. And the ISO26262 provides a guideline [2] that specifies in Part 10 Figure B.4 how the safety mechanism could be translated in a fault tree. By the way, the proposed fault tree is most probably a mistake (dual point fault with diagnostic should be X% of B instead of 1-X%), the correct target being specified for instance in ARP4761 Annex K [5]. Anyway, it remains that safety mechanisms have to be modeled with ISO26262 expected result in mind. Beyond the design of safety concepts, AltaRica should also enable the definition, allocation and traceability of requirements to support the sections 5.6 and 8.6 of the ISO26262 [1]. But as it is shown later, there is no explicit support for requirements in AltaRica. And even if requirement support is added, what is the consistency of these requirements with the concurrent approach of an AltaRica model? The computation of the architectural metrics which is a crucial step for the safety concept verification is also a problem even for the trivial example of the ISO26262 Part 5 Annex E [1], which is reused throughout this article and illustrated in Figure 3 (partially) and later in Figure 6 (completely). A micro-controller acquires inputs from three sensors I1, I2 and R3, and actuates on two valves I61 and I71. Two safety goals are defined and the exact results that shall be obtained are specified in two tables. But how to model the elementary hardware parts of the electronic schematic in AltaRica? More importantly, do we have to model them at this level of detail in a technical safety concept?

4. An alternative method permitting metrics scalability between different abstraction levels The calculation of metrics at hardware part level and more especially the single-point fault metric and the latent fault metric as specified and illustrated in the ISO26262 Part 5 Annex E [1] is too complex and is not suiting well the constraints of automotive industry (L’Hostis, 2013 [6]). Therefore an alternative calculation method was developed by Valeo and tested successfully on several projects for the last 5 years. The goal of this paper is not to fully explain the method (see L’Hostis, 2013 [6] for more details) but to highlight the main particularities that could be then of interest for an implementation in AltaRica.



4.1 Step 1: Re-arrange the detailed hardware schematics into functional blocks The basic idea of the method is that hardware parts are implemented in order to realize functionalities. Therefore, any kind of detailed design can be re-arranged into functional blocks which represent the architecture as follows:

Figure 3. Example of the ISO26262 Part 5 Annex E detailed design re-arranged into functional blocks

Here, for the illustration of the alternative method, we have performed some reverse engineering because, in real life, the architecture with functional blocks is defined by the system engineer prior to the HW detailed design.

The main advantage of such functional block architecture is that it can be understood by everybody and weaknesses can quickly be identified. Of course, several re-arrangements are possible. It would depend on the granularity needed during metrics calculation meaning that, if metrics targets are not reached, a refinement might be necessary.

Functional blocks have failure modes that are called in Valeo “basic events” because they are also used to calculate the PMHF using FTA. As an example, for the functional block ‘Output F1’ that commands the Valve 2 in Figure 3, the basic events are ‘No command possible’ and ‘Spurious command’.

These basic events are defined for all functional blocks and are then used for the calculation of the metrics. 4.2. Step 2: Define failure rate for the basic events. At this stage, we have 2 possibilities depending on where we are in the development phase of the safety-related product:

In a first step, an allocation of the basic event failure rates is possible early in the concept phase from anterior designs with similar functional blocks.

In a second step when the hardware schematic inside functional blocks is sufficiently detailed, the basic event failure

rates can be derived from an Electronic FMEA results performed by a hardware analyst. Electronic FMEA is not new on itself. It is only a kind of FMEA focusing on electronic hardware parts. References to similar FMEA methods can be found into the standards MIL-STD-1629A [7] and ARP4761 Annex G [5]. In an Electronic FMEA, each failure mode of a hardware Part has a failure rate coming from reliability databases and failure modes distribution database. Then, the effects of all hardware Parts (resistors, ICs …) failure modes are systematically analyzed considering the effects at the outputs of their associated functional block (basic events) as follows:

Functional block

HW Part id.

HW Part failure rate (FIT)

HW Part failure mode

Part failure mode distribution (%)

Part failure mode failure

rate (FIT)

Effect at functional block output (basic event)

Output F1 T71 5 open circuit 50 2.5 No command possible

short circuit 50 2.5 Spurious command

Table 1. Example of Electronic FMEA that can be performed by an hardware designer

At this end of the Electronic FMEA analysis, a synthesis with all functional block basic events and their cumulated failure rate from hardware Parts failure modes contributors will be provided to the person in charge of the metrics calculation (analogy can be done with FMES in ARP4761[5]).

From reliability database

From failure modes distribution database

From HW schematics

Automatic calculation

Real added value analysis performed by

the HW designer



4.3. Step 3: Classify each basic event and calculate SPF, RF, LF failure rates for each safety goal. For each safety goal, the basic events must be classified following the explicit following flowchart with also the calculation of the Single-Point Fault (SPF), Residual Faults (RF) and Latent Multiple Point Fault (MPF, Latent) failures rates:

Figure 4. Flowchart explaining basic events classification and how failure rates contributing to SPFM and LFM are calculated.

4.4. Step 4: Determine the sum of safety-related failure rates and calculate the final architectural metrics for each safety goal.

Having performed Step 3 is not enough to calculate the architectural metrics. To complete the calculation it is necessary to calculate the sum of failure rates of the safety-related elements

HWSR,

and, here, important clarifications must be done.

At hardware part level, if one of the failure modes of a hardware part is safety-related, then the hardware part is safety-related and the complete failure rate of the hardware part is considered when calculating

HWSR, .

But, at another abstraction level such as functional block level, it cannot be the same because otherwise the sum of failure rates

of the safety-related elements will be over-estimated and therefore SPFM and LFM will be artificially increased!

It can be easily highlighted in the figure below. The functional block ‘B1’ in the example is safety-related because at least one of its basic events violates the safety goal of interest. Therefore if we considerer all failure rates of its basic events (safety-related or not) in the calculation it would be overestimated compared to the same calculation performed at HW part level.

Figure 5. The transfer of the sum of failure rate of the safety-related elements from hardware part level to another abstraction level is complex

HWSR,

Blo

ck B

1



So, if we want to calculate the architectural metrics (SPFM & LFM) at different abstraction levels than hardware part

level, we need to consider only the failure rate of the basic events that are safety-related BESR, to be conservative!

Following formulas are then used:

BESR

HWSR

RFSPF

simplifiedSPFM

,

,

1

HWSR

RFSPF

BESR

HWSR

LatentMPF

simplifiedLFM

,,

,,

1

{1} SPFM

{2} LFM

Simplified Single Point Fault Metric formula at higher abstraction level than hardware part

Simplified Latent Point Fault Metric formula at higher abstraction level than hardware part

HWSR

RFSPF

, and

HWSR

LatentMPF

,, are the same whatever the abstraction level considered.

4.5. Conclusions

This alternative method is pessimistic and will never increase artificially the metrics. One of its main advantages is to allow a better prioritization of tasks for the architectural metrics calculation with also the capability to perform some activities at different abstraction levels independently and earlier in the development phase. Although the calculation is conservative, in state of the art designs it is very rare that architectural metrics calculated at functional block level are not reaching the targets whereas, when performing the same calculation at hardware part level, the targets are reached. When architectural metrics are not reached at functional block level, it is possible to recalculate the accurate sum of failure rates of safety-related elements from the Electronic FMEA results. It is fastidious manually but could be transparent for the user when performed by a tool. Also the PMFH can be calculated at functional block level (basic events) and linked with architectural metrics calculations results to verify the overall consistency.

5. Implementation in AltaRica In support of the use case defined by Valeo in the European ITEA2 project SAFE, Dassault Systèmes has implemented 2 improvements in its model-based safety assessment tool Safety Designer:

A first Metrics Calculator plug-in that provides the capability to compute architectural metrics. A second Requirements plug--in that provides the capability to define, derive, allocate and trace safety requirements.

5.1 The Metrics Calculator Plug-in. To validate this new functionality the example from ISO26262 Part 5 Annex E [1] was modeled as follows:

Figure 6. ISO26262 Part 5 Annex E example modeled in Safety Designer



Also the Metrics Calculator plug-in cannot work on any AltaRica model and some additional constructs are necessary:

As described before in Figure 4 when classifying multiple-point faults as detected, perceived or latent the Driver has to be taken into account. Therefore, this external element of interest has to be added in the AltaRica model because it is needed to calculate the latent fault metric.

The Safety mechanisms have to be modeled to fit with their expected behavior.

By nature, a safety mechanism might fail to detect or control a failure because: - The hardware supporting this safety mechanism itself fails (modeled here by ‘stuck_at 0’ and ‘stuck_at_1’ events)

and therefore it cannot perform the job that it was supposed to do OR - The safety mechanism is not perfect and can only detect or control a portion of the failure (diagnostic coverage).

In this last case the ‘Non_Detection’ event of Figure 7 represents the non detection portion of the safety mechanism which is translated by a « constant » probability law with a 10% parameter (meaning that the portion of failure detected is 90%).

Figure 7. Example of events modeling for a safety mechanism

To get more information about the AltaRica code content, please refer to the chapter 8.2.7 of [3].

Add laws for the probability of occurrence of events or derive them automatically from Electronic FMEA results for failure events.

As explained above, the architectural metrics plug-in cannot work on any AltaRica model. The events used in the model shall comply with the hypothesis of the ISO26262: - They shall either have a constant failure rate for failure events, which leads to exponential probability distribution,

which can be inspected periodically or tested during a mission, or - They shall represent a percentage of failure on request, using the « constant » probability law, for example in the

case of diagnostics, detection or perception events. For failure events, exponential probability distributions can early in the design phase use estimated reachable values from similar designs. Then, when hardware implementation is known, they can be derived from Electronic FMEA results as highlighted in the following method now. The method leads to create first the reliability data for each hardware part which is used in the design. An example is shown in the Figure 8 for a resistor with its failure modes and its failure rates associated as defined in the ISO26262 Part 5 Annex E example [1]:

Figure 8. Reliability data of a resistor with 2 FITs used for R64

Then, the failure modes of the hardware parts are related using a FMEA construct to their effects on the higher level (equivalent to the Electronic FMEA from Valeo). These effects are simply the failure modes of the functional block which represents the AltaRica component failures events as shown in Figure 9.

Figure 9. Failure modes of AltaRica component SM3_F2 have their failure rates resulting from Electronic FMEA result

Now, the link between low level electronic design and AltaRica failure events is established. The failure rates used with exponential probability laws in AltaRica models are then automatically computed from the FMEA results using the Failure Rate Bank as shown hereafter.

Figure 10. Automatic computation of failure rates used in exponential probability law using the Failure Rate Bank



Add a “Coverage Type” attribute to each event to allow architectural metrics calculation.

A “Coverage Type” attribute has to be added by the analyst to mark the AltaRica events as ‘No Coverage’, ‘Diagnostic’, ‘No diagnostic’, ‘Detected’, or ‘Perceived’. This attribute is only visible when the Metrics Calculator plug-in is activated.

Figure 11. Example of coverage definition types for AltaRica events in SM3_F2

The screenshot in Figure 11 applies to the AltaRica component that models the safety mechanism SM3_F2 which protects the Output _1_F2 of the micro-controller in the example of Figure 6. The ‘Diagnostic’ attribute will then be used for calculating the single-point fault metric. The ‘Detected’ and ‘Perceived’ attributes will then be used for calculating the latent fault metrics.

Computation of the different metrics with results presentation.

As soon as an AltaRica model is defined including the ‘Coverage Type’ attributes for events, the architectural metrics can be computed. For each safety goal, the total of safety-related, the sum of residual and single point failure rates and the sum of latent failure rates are displayed. The resulting metrics are compared with the targets that are depending on the ASIL level of the safety goal as defined in ISO26262 Part 5 Tables 8.4.5 and 8.4.6 [1]. The non-compliances to these targets are also outlined. The calculation type in the report indicates whether the results are exact according to the ISO26262 Part 5 [1] methodology or only based on a partial analysis at functional block level (which might be pessimistic if not linked to Electronic FMEA or exact if linked to Electronic FMEA):

Figure 12. Detailed architectural metrics results for safety goal 2

A detailed justification is provided for each safety goal, as shown in Figure 12. This detailed view provides all the information as defined in the ISO26262 Part 5 Annex E [1]. In order to help the designer to improve the design, the results can be displayed at hardware part level (if linked to Electronic FMEA) or at functional block level. Moreover the results are sorted according to their relative contribution to each architectural metric. Therefore, it is easier to identify AltaRica components which would need a new design.



Some complementary information concerning the Metrics Calculator plug-in. The detailed architectural metrics results are obtained automatically from a cut-set analysis. Events marked as ‘Diagnostic’ failures in these cut-sets identify the safety mechanisms and their diagnostic coverage. From this cut set analysis, the single point fault metric can be derived. The latent fault metric however cannot be obtained in such a simple way. In order to model latent faults, the perception by the driver must also be modeled. For the sake of clarity, let us take the example of the lamp L1 of Figure 6 which is perceived by the driver when lit on the instrument cluster. On this lamp, two instantaneous events have been added: the first one is used to specify that the lamp is lit when it is powered up, the second one is more artificial. The Driver model is essentially made up of transitions that correspond to instantaneous events which model the driver’s perception. These transitions are synchronized with the second instantaneous event in the lamp. The synchronization follows a constant probability law with a parameter which is the failure of perception rate. However complex this may seem, it provides a relatively simple method to model this perception even in the case of a component with a degraded mode deeply nested in a hierarchy of components. The computation of the latent fault metric by the Metrics calculator, however, does not depend on this modeling methodology. The algorithm simulates each safety-related failure and determines whether at least one transition associated to an instantaneous event tagged as perception or detection can be fired. Also, with the introduction of requirements in Safety Designer, the computation of architectural metrics can be launched in one click, the safety goals being explicitly modeled with an unambiguous semantic. When the AltaRica model of a technical safety concept is available, the impact of changes in the technical safety concept is automatically taken into the computation of metrics, which is an important benefit when compared to spreadsheet-like approaches provided in other tools. Finally, the last metric that must be computed is the Probabilistic Metric for Random Hardware Failures (PMHF). Although the definition in the ISO26262 standard [1] is slightly unclear (maximum or average), it can be easily obtained from a safety concept developed in AltaRica. In Safety Designer, minimal cut sets that violate a safety goal are generated by exhaustive simulation until a maximum order of cut sets is reached. The results can be imported in a fault tree analysis tool such as Dassault Systèmes’ Aralia Fault Tree Analyzer. In this latter tool, the PMHF is the maximum of the unconditional failure intensity through the vehicle lifetime. If residual faults or single point faults exist, the PMHF should be close to the

HWSR

RFSPF

,

used for the SPFM calculation.

5.2 Some words about the Requirement plug-in. Requirements and their traceability throughout the project life cycle are often, if not always, a key element in safety analyses. But there is no default explicit support for requirements in AltaRica. This support has been introduced in Safety Designer. The requirements can either be imported from an external CSV file or manually created in Safety Designer as illustrated in Figure 13 . Derivation links can be created and the requirements associated to a composite component can be allocated to a specific sub-component.

Figure 13. Safety requirements associated to the ISO26262 Part 5 Annex E example

In Figure 13, a formal description of the safety goal is available. This description is associated with the state of an observer component that supports the visualization of the safety goal during simulation. Many safety requirements may be associated to AltaRica code. We propose to store the requirements in an extern clause using terms to enable consistency checking of the formal description of the requirements. These requirements can be traced by Dassault Systèmes’ Reqtify tool, which can connect a number of sources of requirements including Doors or Enovia. However, the integration of these requirements in the industrial use case provided by Valeo in the ITEA2 SAFE project shows that requirements in formal models are still a challenging problem. One of the difficulties is that the complete set of formally expressed requirements should suffice to demonstrate that the safety concept is valid. While offering the capability to check these formal requirements by simulation, AltaRica also provides this demonstration in a different format, hence with the risk of discrepancies.



6. Conclusions Model-based approaches of safety analyses convey different promises, among which reuse, consistency and easier change impact analysis. But, in spite of their existence for more than 10 years now, they are still not recognized in applicable safety standards such as ARP 4761 [5]. ISO26262 [1] is not an exception and favors traditional analyses such as FMEA and FTA. It also grants a key role to requirements, which are a paradigm that does not perfectly fit with behavioral models of safety, and defines metrics by their computation methods which are somehow influenced by their tractability with a spreadsheet editor. For all these reasons, the application of AltaRica to the development of ISO26262 safety concepts is not trivial. Nevertheless, as a main result of this article, a new method was developed that provides a clear border between high level AltaRica models and low level electronic design. This new method makes possible to use high level AltaRica components during the first phases of a project (from estimated reachable values), then to perform the computation of metrics down to the electronic parts design when it is available. As metrics are constraining a lot the design, it is really crucial to estimate them very early in the development to be able to anticipate quickly the necessary design modifications. Moreover, several safety goals can be addressed at the same time with a same model. Therefore if a modification is done to improve the metrics for one safety goal, the possible negative impact on other safety goals will be automatically highlighted when re-computing the metrics. Also, the safety concept can be simulated as requested by the ISO26262.That makes it possible for safety reviewers who are not ‘AltaRica experts’ to easily inject faults in the model and verify if it is behaving as expected. Moreover the presentation of the detailed results for architectural metrics is similar to what is expected in the ISO26262 and therefore the review of results is also easy. Other concepts, such as requirements, are not explicitly supported and would deserve a shared extension of AltaRica. This topic is not especially dedicated to ISO26262 but could also concern other safety standards. The tentative to use formal expression for safety requirements has shown that it was not trivial. It is a big step for automotive industry and would need further research activities.

7. Acknowledgment

This work was supported by contribution of all the partners of the SAFE project consortium. This SAFE project in running the framework of the ITEA2, EUREKA cluster program Σ! 3674. The work has been funded by the German Ministry for Education and Research (BMBF) under the funding ID 01IS11019, and by the French Ministry of the Economy and Finance (DGCIS).

8. References

[1] International Organization for Standardization: ISO 26262 Road vehicles - Functional safety. Part 1 to 9 (2011) [2] International Organization for Standardization: ISO 26262 Road vehicles – Guideline Part 10 (2012) [3] SAFE Deliverable D331a2 : Proposal for extension of meta-model for error failure and propagation analysis;

https://itea3.org/project/workpackage/document/download/1557/10039-SAFE-WP-3-SAFED331a2.pdf [4] AltaRica Data Flow Language Specification – Version 2.1, A. RAUZY (2013) ;

http://www.lix.polytechnique.fr/~rauzy/altarica/AltaRica%20Datat-Flow%20Specification%20-%20Version%202-1.pdf [5] SAE ARP4761: Guideline and Methods for conducting the safety assessment process on civil airborne systems and

equipments. (1996) [6] S. L’Hostis ; « Architectural metrics calculation – an efficient approach »; SIA – Journée d’étude : Sécurité fonctionnelle

éléctronique automobile : ISO26262 : où en sommes-nous ? ; 20 Novembre 2013. [7] MIL-STD1629A : Military Standard, Procedure for Performing a Failure Mode, Effect and Criticality Analysis (1980)

9. Glossary ECU : Electronic Control Unit SPFM : Single-Point Fault Metric LFM : Latent Fault Metric PMHF : Probabilistic Metric for Random Hardware Failure SPF : Single Point Fault RF : Residual Fault MPF : Multiple Point Fault LF : Latent Fault FMEA : Failure Mode and Effect Analysis EFMEA : Electronic FMEA FMEDA : Failure Mode Effect and Diagnostic Analysis SR : Safety Related FIT : failure in time HW : Hardware FTA : Fault Tree Analysis DC : Diagnostic Coverage


https://itea3.org/project/workpackage/document/download/1557/10039-SAFE-WP-3-SAFED331a2.pdf

http://www.lix.polytechnique.fr/~rauzy/altarica/AltaRica%20Datat-Flow%20Specification%20-%20Version%202-1.pdf

vers une approche de l’iso 26262 basée sur les modèles

Documents