Software Safety Concept – this is how it could work

Which analyses are useful? A case study

Authors: Dr. Thomas Liedtke, Kugler Maag CIE GmbH, Christian Bayer, Elektrobit Automotive GmbH

Contribution – Embedded Software Engineering Congress 2018

In this paper, we present the experiences gained in defining and creating a Software Safety Concept. Safety analyses in software development are (with a few exceptions) primarily performed at the software architecture level. Remaining residual risks can be deemed sufficiently small by applying the recommended measures of ISO 26262 [1] Volume 6: Product development at software level during the further course of development. Our Software Safety Concept focuses on the Software Requirements Specification level and the Architectural Design level. We present the four different safety analyses carried out in a real customer project, describing their purpose, the experiences gained, and typical findings.

1. Motivation – Project and Task Definition

For a driver assistance function, an OEM faced the challenge of optimizing and industrializing an existing software algorithm. The algorithm served two customer-facing functions in a safety-critical context. Through decomposition, an ASIL-B (D) classification was achieved at the system level. A technical safety concept (TSC) focused on the software component (SW-C) to be developed and served as the basis for software development. A platform (hardware and software) with a corresponding safety manual provided the necessary execution environment.

Elektrobit Automotive GmbH (EB) was commissioned to demonstrate the necessary safety measures for the software component to meet the requirements of the Technical Security Concept (TSK). Furthermore, EB was involved in the software development process at the requirements, architecture, and testing levels. Kugler Maag CIE's safety expertise was brought in for external consultation.

From the OEM's perspective, a document titled "Software Safety Concept" should explain which safety mechanisms were implemented, why they were implemented, and how they ensure safety. The document should serve to identify and document the necessary safety mechanisms. The external assessment team wanted the document expanded to include the safety analyses and the safety rationale for the project, ultimately to justify the software's release.

Accordingly, the project, with its Software Safety Concept, looks to the central document when it comes to approvals or the evaluation of new change requests for the project.

2. Software Safety Concept

Since a separate Software Safety Concept is not a work product specified in ISO 26262 [1], its scope and content first had to be defined.

The purpose of the Software Safety Concept is, firstly, to evaluate the mapping of the Safety Requirements to the architecture and, secondly, to provide significant evidence for the Safety argument through the selection and results of safety analyses performed.

Accordingly, the SW safety requirements (which essentially concerned the handling of safety-relevant and non-safety-relevant sensors and signals), the derived SW architecture and the traceability matrix formed the basis of the analysis, which was iteratively examined and adapted.

The original plan was to develop the software in two sub-components with different ASIL ratings. However, the mixing of signals with different ASIL allocations could not be justified, and freedom from interference could not be adequately demonstrated. Consequently, it was decided that all software components must be developed according to the same ASIL rating.

Safety analyses in software are usually performed at the architecture level due to their effectiveness. For further software development, the ASIL-oriented requirements of ISO 26262 [1] should provide the necessary assurance to minimize remaining systematic errors.

3. Safety analyses

Safety analyses were conducted to investigate the following questions:

• Are the security requirements consistent, complete, and understandable both internally and externally? → Systematic TSK analysis
• What are the critical safety mechanisms? Are they being developed with appropriate measures to ensure sufficient safety? → Requirements FMEA (Failure Mode and Effect Analysis [2])
• Is the architecture sufficiently secure (in the sense of being fully logically described), complete, and consistent? → Architecture HAZOP (Hazard and Operational Analysis [3])
• Analysis and identification of which basic errors can lead to top-level failures → Fault tree analysis (FTA)

See Figure 1 (PDF).

3.1 Systematic TSK Analysis

The OEM's technical safety concept consisted of approximately 1000 database entries and included definitions, system descriptions, relevant input and output signals, as well as the required 40 or so functional safety requirements. This may sound manageable at first, but the requirements were nonetheless impressive due to...

• nested conditions
• Some documents contain several footnotes with further conditions, exceptions, references to signal tables and definitions within the document.

The project team decided to conduct a systematic requirements analysis together with the OEM. The goal was to create a shared understanding and to modify customer requirements in case of misunderstandings or identified shortcomings.

The discussions with the OEM in numerous meetings were recorded and the results documented. Any necessary changes to customer requirements were tracked until the changes were submitted to EB in the form of new customer requirements.

Lessons Learned:

• The complexity of the requirements was underestimated; the results of an initial TSK review with requirements derivation had to be discarded.
• Many implicit assumptions were explicitly documented and terminology clarified.
• Contradictions were uncovered and resolved.

3.2 Requirements FMEA

An FMEA at the requirements level had the following objectives:

• As part of the risk analysis, it should uncover potential inconsistencies (internal and external) in the safety mechanisms at an early stage.
• The criticality of each security mechanism should be evaluated and documented.
• The documented knowledge base should be increased, and the flow of communication with the customer and the associated necessary knowledge transfer should be promoted.

The analysis sessions each started based on the negated requirements. These were evaluated in two directions:

1. Cause of error: What errors can lead to a violation of safety requirements?
2. Impact of failure: What possible failures can occur? It turned out that the combinations can become complex, which is why a standardized risk assessment was created. See Figure 2 (PDF).

In several sessions, combinations of errors and their effects were evaluated. Typical findings related to previously unconsidered complex combinations and types of errors (long or short duration of exposure, unstable situation, etc.). Requirements were adjusted accordingly based on these findings.

Lessons Learned:

• Important knowledge transfer for the further course of the project
• Time-consuming clarification discussions revealed ambiguous interpretations of requirements, so these were refined.

3.3 Architecture-HAZOP

All diagrams (including components and sequences) should be systematically questioned. For this purpose, a suitable set of questions with HAZOP keywords [3] was created for each type of diagram.

The process proceeded iteratively in the following phases:

1. Identification of the design elements for which the analysis is to be performed.
2. Determining the deviations: Applying the HAZOP keywords to all elements of a diagram.
3. Analysis of deviations regarding cause, effect and possible violation of a requirement
4. Definition of new requirements for missing measures and application of measures
5. Allocation and implementation of new requirements for the security architecture or component
6. Transmission of user requirements to the HW/SW boundary condition
7. Design update → new iteration starting at step 1

Examples of possible keywords for a component diagram include:

• • Completeness:
    • Component missing – Memory partition missing – Interface missing – Connector missing – …
  • Quantitatively:
    • Contains more: Memory partition unintentionally includes additional components – incorrect number of associations – …
    • Contains less: Memory partition does not include all components – …

Sequence and activity diagrams also include additional keywords, such as for timing and sequence.

Lessons Learned:

• Typical findings mostly related to testability (e.g., how can the given sequence be tested?) and completeness (how can the complete execution of a loop be verified).
• The diagrams became more coherent and consistent as the analysis progressed, thus making the architecture more valuable.

3.4 Fault Tree Analysis (FTA)

In order to avoid only bottom-up conclusions about possible sources of error, a fault tree analysis was created based on the levels of Software Safety Requirements and Safety Architecture.

Minimal cut sets were established and analyzed. Dependencies between different safety mechanisms were identified. Fault trees were developed in several collaborative sessions involving safety experts and architects.

Lessons Learned:

• Although the top-level events were found very quickly, deriving them from the safety mechanisms to individual single events proved difficult.
• The FTA analysis provided a good overview of possible combinations of failure causes and the effect of safety mechanisms.

4 Summary

Creating a software safety concept helped to understand the scope of the project. It now forms the central document, containing essential evidence for the safety argument. When new customer requirements arise, it enables the team to efficiently conduct impact analyses on existing safety mechanisms.

The effort required for the safety analyses was initially underestimated. The following table provides an overview of the duration, effort, and benefits:

	TSK Analysis	FMEA	HAZOP	FTA
Length of time	3 months	3 months	12 months	2 months
Expense	6 person-months	1.5 person months	8 person-months	2 person months
To use	7% of the TSK revised by the OEM (including clarifications, new and removed requirements)	Criticality of safety mechanisms as input for further preventive and analytical measures in development	High quality of the diagrams and architecture, diverse input for test strategy	Independence of the safety mechanisms

 Table 1: Overview of the effort required for safety analyses

literature

[1] ISO 26262 Road vehicles – Functional safety 1^st edition (2011)

[2] VDA Volume 4: Product and Process FMEA (2009)

[3] HAZOP Studies on Systems Containing Programmable Electronics Part 2 General Application Guidance. Ministry of Defense. Defense Standard 00-58, (2000)

Download the article as a PDF

---

Our training courses & coaching sessions

Do you want to bring yourself up to date with the latest technology?

Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.

Training & coaching on the other topics in our portfolio can be found here. here.

---

Quality, Safety & Security – Expertise

Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.

To the specialist information

You can find expertise on other topics in our portfolio here. here.