ISO 26262 Functional Safety Requirement Types
欢迎使用Markdown编辑器
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:
- 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)
What is the item (system / subsystem) to develop, its functional purpose, the operating environment, the operational modes and constraints?
Was a similar system developed in the past? What are potential failure modes (any records from the past?) and their consequences?
What are the interfaces and interaction with other items, driver?
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)”
- 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:
What measure does the system need to take in order to detect, indicate and control the fault?
Is another electronic control unit, power supply, or communication device involved in the measure?
How should this measure be implemented? (e.g. processing sensor signal)?
How does the HW or SW element achieve or maintain a safe state? In which time tolerance? What if it fails to? What will be the emergency action?
How will the HW or SW element be prioritized against conflicting safety mechanisms? How will the element prevent latent fault? On-board test during power-up? Periodic testing during operation?
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
- 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:
Software architecture requirements describe the structure and relationships of the software components and contribute to create the software architecture. The software architecture serves as a backbone for the implementation of the software requirements. They can also express constraints about performance and robustness of a software element (sometimes called non-functional 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.
Software safety requirements focus on the safety-related functionalities to satisfy the technical safety requirements and avoid critical system situations which may lead to hazards or serious faults. (E.g.: safe execution of a nominal function, maintaining a safe state, detecting indicating and mitigating potential faults, management of time-critical operations and fault tolerances, etc.)
Software requirements specify the non-safety software functions and are derived from the intended functions for which the HARA analysis resulted in a no ASIL rating (QM requirements).
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.
