ISO 26262 Functional Safety Requirement Types

Author: Nabile Khoury | Date: February 22, 2021

  • Automotive E/E safety systems have found suitable development guidance in the ISO 26262 standard
  • Any system and software development must follow a requirement engineering process
  • This article explains the requirement types according to ISO 26262 Functional Safety

With the aim to provide technical coherence, reliability and safety, requirements engineering is the process for defining, documenting and managing requirements. In the 90s, the IEEE provided a general definition of requirements engineering with five phases: elicitation, analysis, specification, verification and management. Within each industry, requirements engineering has been adapted to the specific domain of application and its constraints but these phases are still reflected. In the automotive industry, the growing complexity of E/E systems and the increasing amount of safety related functions motivated OEMs and suppliers to define a system development approach that focuses on mitigating the safety risks inherent to these systems while achieving their intended functionality. ISO 26262, on behalf of Functional Safety defines a dedicated requirement engineering process with different phases. In this article, we’ll describe the relevant aspects of each phase illustrated with examples.

Requirements as blueprints to start an ISO 26262 distributed development

Distributed development between OEMs and suppliers is very common in the automotive. For the supplier selection, the OEM’s “Request-For-Quotation” must include at least two things: a formal request to comply with the ISO standard and the list of safety goals* or a set of relevant high-level safety requirements that the supplier will agree on. On an abstraction level, the OEM requirements describe the “What” and the supplier activities will implement the “How”. In the planning activities, roles, responsibilities, work products, selected methods and tools are captured and assigned to each stakeholder in a document called the “Development-Interface-Agreement” (DIA) which will drive the execution of the distributed development.

ISO 26262 requirement phases on system and software levels

We can identify four stages or levels in the ISO 26262 requirements process:

1) Safety Goals in ISO 26262 chapter 3

Safety goals (SG) are specified during the “Concept” phase and identify the high-level safety requirements resulting from two tasks:

Item definition: The task identifies the system, the intended functions and it answers whether they can present any risks or hazards to the vehicle occupants. Questions include:

Example of Item definition: Battery Management System (BMS)
Example of Item definition: Battery Management System (BMS)

Example of HARA and ASIL determination (partial) : Battery Management System
Example of HARA and ASIL determination (partial) : Battery Management System

Hazards analysis and risks assessment (HARA) and ASIL determination: If the item is new, a HARA must be performed otherwise an impact analysis of the existing item shall determine which activities need to be modified. From the operation situations and the operation modes, the HARA analyzes which malfunctioning can result in hazardous events. Adequate hazard analysis techniques like FMEA or HAZOP can be used to support this task. Then a normative approach for evaluating the risks based on the impact factors of Severity, Probability of Exposure and Controllability determine the ASIL rating of the hazard events and contribute to enunciate the safety goals ultimately assigned with the ASIL rating. A safety goal is defined for one or multiple hazard events. A common safety goal will take the highest ASIL rating of the hazard events. 

SG1: “The battery protection function shall avoid a battery fire in charging and operating modes (ASIL D)”

2) Functional Safety Requirements in ISO 26262 chapter 3

In this “Concept” phase, one or multiple Functional Safety Requirements (FSR) are derived from each SG. FSRs define safety mechanisms and other safety measures to minimize the risks. Preliminary architecture assumptions and function decomposition are made at this level to identify which subsystems to assign to which safety function. Concepts of time tolerance, safe state and degradation are relevant aspects of the FSRs. Questions about internal or external factors that influence the controllability and external measures to mitigate the risks will also be answered. Analysis techniques like FMEA and FTA can support this task. It’s recommended to use natural language to express these requirements (including drawings). ASIL ratings are inherited or decomposed according ISO 26262-9 Clause 5 from the SGs and assigned to the FSRs. 

Example of preliminary architecture : Battery Management System
Example of preliminary architecture : Battery Management System
Example of Functional safety requirements: Battery Management System
Example of Functional safety requirements: Battery Management System

3) Technical Safety Requirements in ISO 26262 chapter 4

Technical Safety Requirements (TSR) define which safety mechanisms to implement to satisfy the FSRs. TSRs are allocated to item elements obtained from the refinement of the preliminary architecture and progressively identify hardware (HW) and software (SW) parts. The TSRs are also called system requirements and introduce more and more HW and SW technical terms.

Inqueries for building safety mechanisms to define the TSRs:

One particular set of requirements specified at this stage is the Hardware and Software Interface (HSI). HSIs are fundamental to guaranty the later system integration and system verification. The HSI characteristics are for instance operating modes of the hardware parts, hardware configuration parameters, hardware resources that will support the software execution, software partitioning feature, hardware diagnostic feature implemented in the software (e.g watchdog, etc.) 

Besides the functional aspects, the following characteristics will also have an influence on the EE elements and must be considered: behavioral and reaction towards physical influences such as temperature, voltage, vibration, electro-magnetic compatibility, aging effects, maintenance, etc.

Example of Technical safety requirements: Battery Management System
Example of Technical safety requirements: Battery Management System
Example of Hardware-Software Interface requirements
Example of Hardware-Software Interface requirements

 

 

4) Software Requirements in ISO 26262 chapter 6

Software requirements are the result of a transformation process of the TSRs allocated to software parts and the HSIs into a set of requirements used to develop the software functions. In parallel, hardware requirements are also derived to develop the hardware elements. Software requirements describe the static and dynamic aspects of the software elements. The software elements are software components, software units and software interfaces identified during the software architectural design phase. The transformation process typically results into 3 categories of software requirements:

Note: In order to manage the architecture complexity and hence meet the safety requirements, ISO 26262 recommends architecture design principles such as abstraction, modularity, encapsulation, hierarchical structure, cohesion within software components, etc. For this purpose, a suitable notation must be used. The experience has shown that the AUTOSAR architecture standard is a good candidate to fulfil the ISO requirements as it supports most of them.

Both safety and non-safety requirements are functional (behavioral) requirements. They describe the capabilities of the software element to act in its operating situations and express a specific reaction to a certain input stimulus. Each of these requirements needs to refer to a software component or unit and to one or multiple software interfaces defined in the software architecture.

Example of Software safety requirements
Example of Software safety requirements

During the software requirements phase, the ASIL rating of the parent TSR(s) is inherited or decomposed. When an ASIL level is assigned to the requirements, the subsequent software design and testing phases must select appropriate software development methods according to the recommendation tables in the standard. These methods must be supported with guidelines and qualified tools which have to be planned at the initiation phase of the software project.

Which development process for non-safety requirements?

Safety and non-safety requirements can live together in the same safety item or element but with the condition of a total absence of interference according to ISO 26262-9 Clause 6. To implement the non-safety requirements, the same ISO 26262 methods applied for the safety requirements can be used and this is actually highly recommended.

Conclusion

To achieve the functional safety of an E/E system, the ISO 26262 development process proceeds through systematic analysis tasks to identify and classify functions as more or less safety critical, specifies safety requirements to mitigate the risks and gives recommendations regarding corresponding state-of-the art methods for development and verification. With a methodological approach, the development requirement phases answer conceptual and technical questions to elaborate the system architecture including hardware and software parts, and allocates functional and safety mechanisms to each part in order to implement the E/E system.

One important aspect of the requirements engineering process is the requirements management. This is a topic we’ll discuss in an upcoming article featuring ISO 26262 requirements engineering.

The Author:

Nabile Khoury studied Electronics and Computer Science at the University “Conservatoire National des Arts et Métiers” in Paris. From 2010 to 2016, he worked in automotive companies, mainly in the powertrain department of the French car maker PSA Peugeot Citroën, as software engineer specialized in Model-Based Development involving AUTOSAR and ISO 26262 compliant processes. He then joined BTC Embedded Systems AG where he currently works as a Senior Pilot Engineer in Paris/France.

Connect with me on linkedin.com/in/nabilekhoury