Reprinted from Technical Papers on the Development of Embedded Electronics
by Vector

Here I would like to highlight some of the most interesting ideas from the set of articles by Vector. This is 3 of 7 posts on this topic.

Design and Analysis of Functionally Safe Hardware in an EBS

Derivation

With the publication of ISO 26262 “Road vehicles – Functional safety”, the automotive industry, its development processes, and resulting products are subject to explicit safety requirements for the first time. Manufacturers don’t just have to evaluate a portion of the system during the particular development phase but rather must evaluate the whole system throughout its life cycle. The hardware development is accompanied by extensive requirements and effort in the form of prescribed hardware safety evaluations and specific safety case documents. The following describes an efficient methodology that supports an iterative design/analysis process and has been integrated into the model-based PREEvision system engineering tool. In addition to presenting the methodology and tool support based on ISO 26262, a specific application is explained involving safety evaluations for a newly developed electronic braking system (EBS).

Functional Safety in the Hardware Context

The activities and work products demanded by ISO 26262 [1] are extensive and, despite the very well-structured and prepared standard, are often difficult to introduce into existing processes and tool chains [2]. The standard describes two different design phases for product development at the hardware level according to Part 5: The hardware architectural design consists of hardware components and describes an abstracted and functional view of a preliminary hardware design. The hardware detailed design, in contrast, is made up of hardware parts and represents a refinement of the hardware components at the level of electronic schematics. In the following, these will be referred to simply as hardware designs and hardware elements.

Required safety evaluations regarding the analysis of random hardware failures are based on statistical failure information and are described in Part 5 Clause 8 for the “Evaluation of the hardware architectural metrics”. In turn, this evaluation is composed of the “single-point fault metric” and the “latent-fault metric” and enables conclusions to be drawn about the robustness of the hardware design.

This evaluation is complemented by the “Evaluation of safety goal violations due to random hardware failures” described in Clause 9, which represents probabilistic safety analyses. Two different evaluations can be applied here:

“Evaluation of Probabilistic Metric for random Hardware Failures (PMHF)”, which requires a global analysis of the design, and “Evaluation of each cause of safety goal violation”, frequently referred to as the FRC method, which represents an individual classification of single hardware elements.

Procedure for Hardware Safety Evaluation

Model-based environments are particularly well-suited for supporting safety evaluations required by ISO 26262 in iterative and collaborative development projects. Hardware designs based on specific libraries are modeled with deposited failure information. The model information enables the demanded safety evaluations to be carried out with the support of a database and thus with significantly less effort [3].

A continuously updated display of the calculated evaluation results supports the iterative approach for different development phases. This simplifies goal-oriented design changes. Automated report documents enable an overview of the development progress to be obtained at any time and decrease the documentation effort.

Failure Library

Statistical information regarding failures of hardware elements, such as failure rates, failure modes and failure rate distributions among failure modes, are administered in a failure library. The failure library is typically populated from recognized industry sources such as Siemens Norm SN 29500 and can be easily expanded to include empirical knowledge from company-internal databases. Failure information that has been added can be reused in different hardware designs by different development teams.

Integrated Modeling

At the beginning, safety goals with their associated automotive safety integrity level (ASIL) are derived from a hazard analysis and risk assessment (HARA) of the complete system and stored at the requirements level. A refinement is carried out using functional and technical safety requirements, which can be iteratively updated. It is also necessary to define safety mechanisms with specific values for the diagnostic coverage with respect to residual faults and latent faults.

For modeling of the hardware design, the functional and technical safety concepts can be realized in the form of the hardware architectural design, 1 (a), and the hardware detailed design, 1 (b). The hardware elements including failure information which are deposited in the library can be dropped directly to the appropriate diagram 1 (c).

Traceability and Design Optimization

Because the failure information of the hardware elements is transferred from the failure library, consistent and traceable results are guaranteed, 2 (a). The engineer is relieved of having to maintain the data and can focus on the analysis and optimization of the design in terms of its functional safety. Thus, the effects of newly introduced safety mechanisms or additional hardware elements on the evaluations can be analyzed.

Hardware Safety Evaluations

Several editors are available for the model-based application of safety evaluations. These can be used to provide a structured and prepared display of the evaluation results while offering different perspectives of the evaluations.

The failure data table according to ISO 26262 contains the safety goals to be analyzed, the safety-related classifications as well as the failure information annotated in the library. Information regarding a potential direct violation of the safety goal and a potential violation in combination with other independent failures is given. The failure modes can be classified in the context of the safety goal directly in the editor or automatically using a qualitative fault tree analysis (FTA).

The “Evaluation of the hardware architectural metrics” is performed for one or more safety goals. For the “Evaluation of each cause of safety goal violation” at the level of the hardware element, a ranking into a failure rate class and a specific diagnostic coverage is considered. Target values are derived from the ASIL of the safety goals and their fulfillment is highlighted graphically, 2 (b).

The evaluation of a PMHF is supported by a qualitative and quantitative fault tree analysis. For this, the calculation of a probability as a worst-case estimate for occurrence of the top-level event in the fault tree, as the violation of the safety goal to be assessed, is provided. The determination of average probabilities (footnote: this corresponds numerically to the “Conditional failure intensity”, thus the probability of failure at time T on condition of freedom from failure at time T₀. As worst-case, the system lifetime can be set as T-T₀ = Lifetime.) from the failure rates is achieved using a customizable latency time T. Additionally, the qualitative analysis of the fault tree using minimal cut sets enables the definition of design constraints.

Reports

The effort associated with the documentation requirements of ISO 26262 is not trivial. The model-based approach offers significant benefits here as well.

For safety evidence, it is possible to generate review reports during the design phase as well as documents for argumentation of the “safety case” after finalization of the hardware design. These can also be used for a possible certification of the hardware. Automated creation of the safety case documents is possible at any time during development. These documents give an indication of the current status of the hardware safety of the system.

EBS as an Example Scenario

This example involves the safety evaluation for a brake-by-wire (BBW) electronic braking system currently under development. For display purposes, the evaluation is limited to the redundant power supply of the EBS, 3. Among other things, the focus here is on the interfaces between requirements, architecture, design and their derivation with deductive safety analyses.

The safety goal SAF_REQ_1 “The average probability of loss of BBW auxiliary energy shall be less than 3^-09/h” was derived from the HARA. The functional safety concept provides the power supply to the adjacent EBS-Actuator system element primarily via terminal KL30_2. In case of need, the ALT selector switch can be used to switch to the secondary power supply VP1. This is used as cold redundancy to increase availability and is switched on in emergency operation.

Application of the integrated concepts yielded the fault tree shown in Figure 4a. The top-level event occurs if “Undetected loss of VP2”, “Loss of VP2 and loss of cold standby (VP1 or ALT)” or “Loss of cold standby (VP1 or ALT) in emergency operation” occurs. Through the minimal cut set analysis, the budgets for the occurrence probabilities of the individual minimal cut sets were assigned and the safety requirements (functional and technical) and design constraints shown in 4 were derived. For multiple-point faults (cut set order greater one), the permissible budgets of the individual faults can be determined and the degradation and emergency operation characteristics (maximum duration and warning concept) can be specified, 4 (c).

Conclusion

All hardware safety evaluations demanded by ISO 26262 are fully sup-ported in a single integrated solution. This eliminates additional work and error sources caused by inconsistent data sources, a change of tools and tool breaks. The library approach unburdens the engineers to carry out design and analysis and provides a high level of reusability. Effects of hardware design modifications or introduction of safety mechanisms are instantly observable in the evaluation results. This shortens the optimisation cycles drastically. Thanks to the collaboration support, distributed teams can jointly drive the design and analysis and implement changes faster and more reliably.

The model-based combination of hard-ware safety evaluations with other work products of ISO 26262 is possible and desirable. This enables automated checks of work products for formal complete-ness and consistency as well as auto-mated generation of reports, including the safety case.

References

1. International Organization for Standardization, ISO 26262 Standard, Road vehicles – Functional safety (2011)
2. Adler, N.; Otten, S.; Schwär, M.; Müller-Glaser, K.: Managing Functional Safety Processes for Auto-motive E/E Architectures in Integrated Model-Based Development Environments. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(1), pp. 103 – 114, doi:10.4271/2014-01-0208 (2014)
3. Adler, N.; Otten, S.; Cuenot, P.; Müller-Glaser, K.: Performing Safety Evaluation on Detailed Hard-ware Level according to ISO 26262. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 6(1): pp. 102 – 113, doi:10.4271/2013-01-0182 (2013)