See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/325697962

ISO 26262 Functional Safety Standard and the impact in Software lifecycle

Technical Report · October 2017

DOI: 10.13140/RG.2.2.12486.16963

CITATION READS
1 7,440

1 author:

Alabbas Alhaj Ali

Frankfurt University of Applied Sciences
8 PUBLICATIONS   7 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Safety Standards View project

Safety Critical Systems View project

All content following this page was uploaded by Alabbas Alhaj Ali on 11 June 2018.

The user has requested enhancement of the downloaded file.

JOURNAL OF UNIVERSITY OF APPLIED SCIENCES , VOL. 1, NO. 11, NOVEMBER 2017 1

ISO 26262 Functional Safety Standard and the

impact in Software lifecycle
Alabbas Alhaj Ali

Abstract— Due to the increased regulation of adopting a The standard is applicable only for vehicles with a weight
standardized set of safety standards in industries, it was in- less than 3500 kg [1], [2], [5], [6] and according to ISO
evitable that the Automotive industry had to develop international 26262 Road Vehicles Functional Safety [6] the standard pro-
standards that focus on critical safety components. That’s why
the ISO 26262, which provides a guidance in the form of vides regulations and recommendations throughout the product
requirements and processes, had been introduced in November development process, from conceptual development through
2011. Most of the modern vehicles are equipped with embedded decommissioning. It details how to assign an acceptable risk
electronic systems which include: lots of Electronic Controller level to a system or component and document the overall
Units (ECUs), electronic sensors, signals, bus systems, and coding. testing process. In general, ISO 26262:
It is a challenge of the automotive industry to test, validate and
identify potential risks of software and hardware failures in such • Provides and supports an automotive safety life cycle
a complex system. The goal of ISO 26262 is to provide an unifying (management, development, production, operation, ser-
safety standard for all automotive E/E systems. In this paper we vice, decommissioning).
introduce the component of the standard related to Software • Outlines an automotive-specific risk-based approach (au-
Safety and the impact of the standard in the software life cycle.
tomotive safety integrity levels).
Index Terms— ISO 26262, Automotive, functional safety, safety • Helps in avoiding unreasonable residual risk.
standard, Software Safety, Software life cycle. • Can be used to validate and confirm safety levels.
• Provides requirements for relations with suppliers.

I. I NTRODUCTION Figure 1 shows that the standard consists of several parts as

following [1], [2], [6]:

I SO is a derivative of IEC 61508, the generic functional

safety standard for electrical and electronic (E/E) systems.
The draft of the standard was published in June 2009 and
• Part 1: Vocabulary
• Part 2: Management of functional safety
• Part 3: Concept Phase
because the public draft of the standard is published the • Part 4: Product development at the system level
standard is conceded to be state of the art which is the highest • Part 5: Product development at the hardware level
level of development of a device or process at a particular time • Part 6: Product development at the software level
[5]. In November 2011, ISO 26262 Road Vehicles Functional • Part 7: Production and Operation
Safety [6] was published as a formal ISO standard. • Part 8: Supporting processes
The main focus of the standard is to insure functional safety, • Part 9: Automotive Safety Integrity Level (ASIL)
which ISO 26262 has dened as the absence of unreasonable • Part 10 : Guidelines on ISO 26262
risk due to hazards caused by malfunctioning behaviour of
E/E systems [6] . The functional safety ensures that all of A. Automotive Safety Lifecycle
the electrical and electronic systems (such as: power supplies,
sensors, communication networks, actuators, etc) functions The ISO 26262 automotive safety lifecycle describes the
correctly. entire production lifecycle. This includes the need for a safety
Implementing the standard, one must start right from the manager, the development of a safety plan, and the definition
beginning of planning a new component in the car (Item). of confirmation measures, including: safety review, audit and
That ensures a high level of safety build in the component. The assessment. These requirements are intended to be used for
standard interferes with all levels of product development in a the development of the E/E systems and elements [5].
system, including: the management, development, production, In this paper we are going to focus on the product develop-
operation, and documentation. ment on the software level, which includes: the system defini-
tion, system design, safety assessment and safety validation.
While other standards add additional requirements to the
development process, ISO 26262 will add more than that
B. Automotive Safety Integrity Level (ASIL)
to the production life cycle of automotive hardware-software
systems. This standard will act as a framework that impacts ISO 26262 replaces SILs with ASILs (Automotive Safety
integrated requirements traceability, risk management, valida- Integrity Levels). ASILs are determined at the beginning of the
tion, verification, documentation and collaboration throughout development process (concept phase). ASILs are designed to
the systems engineering V model life cycle process. specify the measures required to avoid unreasonable residual
risk. The ASIL asks the question, If a failure arises, what will
Prof. Wagner happen to the driver and associated road users? [5]
JOURNAL OF UNIVERSITY OF APPLIED SCIENCES , VOL. 1, NO. 11, NOVEMBER 2017 2

Fig. 1. Overview of ISO/DIS 26262.

Figure 2 shows the performance of the hazard analysis

leading to ASIL. After the item is defined, the hazard analysis
and risk assessment are done leading to ASIL. The risk of
each hazardous event is evaluated on the basis of:
• Frequency of the situation (combination of the probability
of exposure).
• Impact of possible damage (the possible outcomes sever-
ity if a critical event occurs).
• Controllability (the possible controllability by a driver).
The ASIL does not address the technologies used in the
system; it is purely focused on the harm to the driver and Fig. 2. ASIL, Automotive Safety Integrity Level
other road users [1], [5].
ASILs are classified in classes of A, B, C or D with D
representing the most safety critical processes [1], [2], [5], [6], C. Product Development System Level
[7]. This classification helps in determining the test methods
needed to validate the system regarding to the requirements. The product development starts with initialization of product
Once the ASIL is determined, a safety goal for the system development at the system level that includes the hardware
is formulated. Safety Goals are top-level safety requirements and the software. In this level the abstract system is designed
based on the results of the hazard analysis and risk assessment. and the technical system requirements and technical safety
A potential hazard may lead to more than one safety goal requirements are defined. This will lead to the system item
and thus the functional safety concept which composes of the integration and integration testing, the safety validation and
functional safety requirement is defined. system safety assessment is defined.
JOURNAL OF UNIVERSITY OF APPLIED SCIENCES , VOL. 1, NO. 11, NOVEMBER 2017 3

5) Functional Safety Assessment: Assess the functional

safety that is achieved by the item.
6) Release for Production: In this part, the development
of the item is finished and the product has released the
specification criteria so that the release for production is
identified. The release for production confirms that the item
complies with the requirements for functional safety at vehicle
level. The documentation shall include:
• The name and signature of the person in charge of release.
• The version/s of the released item.
• The configuration of the released item.
• References to associated documents.
• The release date.
Fig. 3. Example of Functional Safety Requirement

D. Product Development Software Level

1) Specification of the Technical Safety Requirements: ISO 26262 addresses the software development and soft-
The objective of this section is to develop the technical ware lifecycle more specifically. The standard interferes with:
safety requirements, which refine the functional safety concept
• Initiation of product development at the software level.
considering the preliminary architectural design and to verify
• Derivation of software safety requirements from the sys-
that the technical safety requirements comply to the functional
tem level (following from part 4) and their subsequent
safety requirements. In this section the item functional safety
verification.
requirements and the system level technical safety require-
• Software architectural design.
ments are fetched down to the allocation of hardware and
• Software unit design and implementation.
software elements.
• Software unit testing.
2) System Design: In this step the overall system, including
• Software integration and testing.
the technical safety concept, is designed to confirm with the
• Verification of Software safety.
functional requirements and the technical safety requirements
specification. It is very important during the design to have 1) Initiation of Product Development at Software Level:
bidirectional traceability between System design and Technical Figure 3 [6], [7] shows the reference V-Model for the software
safety requirements specification. development regarding to the standard.
3) Item integration and testing: While designing the sys- 2) Specification of Software Safety Requirements: Specify
tem, we end up with different parts (Sub-systems) that com- the software safety requirements which are derived from
pose the overall system that leads us to the integration testing. technical safety concept (including their ASIL) and the system
The testing verifies that the obtained product is complying with design specification. Detail hardware-software requirements
each safety requirement and that the design has been correctly and verify that the software safety requirements are consistent
implemented. with the technical safety concept and the system design speci-
The integration is done through phases. Each phase is fication. The specification of the software safety requirements
associated with specific tests performed and in each phase considers constraints of the hardware and the impact of these
all the functional and technical safety requirements shall be constraints on the software.
tested at least once. The Software Safety Requirements should include :
Figure 3 shows examples of the functional safety require- • Requirements for addressing error detection (e.g., plau-
ment associated with ASIL. In each phase the requirement sibility checks, detection of data errors, control flow
should be checked. monitoring).
4) Safety Validation: This step is important in order to • Requirements for addressing error handling (e.g., static
provide evidence that the safety goals are correct, complete, recovery mechanisms, graceful degradation, correcting
and fully achieved at the vehicle level and that safety concepts codes for data).
are appropriate for the functional safety of the item. The • Specifies verification requirements (Includes control flow
validation of safety goals should be applied to the item analysis, data flow analysis, inspections, etc.).
integrated at the vehicle level, which will include all the 3) Software Design: Develop an abstract software archi-
item components, such as: E/E system, software, hardware, tectural design that realizes the software safety requirements
elements of other technologies, external measures [5], [6], and verify the software architectural design achieving bi-
[7]. The validation plan should include: directional traceability. The design should commit to applying
• The configuration of the item. design principles, in order to achieve modularity, encapsula-
• Validation test procedures for each safety goal with tion, and minimum complexity.
pass/fail criteria. The software architectural design includes all the software
• Scope of the application (e.g., configuration, environmen- components in a hierarchical structure, which realizes the
tal conditions, driving situations, etc). restricted size of SW components and the interfaces and their
JOURNAL OF UNIVERSITY OF APPLIED SCIENCES , VOL. 1, NO. 11, NOVEMBER 2017 4

• Compliance with the expected results.

• Coverage of the software safety requirements.
• A pass or fail criteria.

II. C ONCLUSION
ISO 26262 ensures the safety of the E/E systems and
programmable electronic devices in road vehicles based on the
functional safety concept. The hardware safety requirements
and software safety requirements are determined based on the
technical safety concept. The standard also covers production
and operation of the system through to its decommissioning.
The standard is well constructed and documented but the
Fig. 4. Reference V Model for the Software Development
concept of safety, availability and reliability are mixed up,
which leads to multiple interpretations and misunderstandings.
interactions. The architectural design should be validated and
verified using ASILs (Appendix I). A PPENDIX I
The safety analysis should be applied to the software archi- S OFTWARE V ERIFICATION OF A RCHITECTURAL D ESIGN
tecture to identify and confirm safety-related characteristics The software architectural design shall be verified by using
and to support specification of the safety mechanisms [6]. the following software architectural design verification meth-
4) Software Unit Design and Implementation: Specify the ods:
software units in accordance with the software architectural
design and the associated software safety requirements. The
specification of the software units should describe the func-
tional behaviour and internal design. Specify design principles
to apply in order to achieve robustness, testability, and sim-
plicity. The coding standards have to be enforced to confirm:
• Correct execution order.
• Interface consistency.
• Correct data/control flow.
• Simplicity.
• Readability and comprehensibility.
• Robustness.
• Change suitability.
• Testability.
5) Software Unit Testing: Demonstrate that the software
units satisfy their specification and do not contain undesired
functionality. To evaluate the completeness of test cases and ACKNOWLEDGMENT
to demonstrate that there is no unintended functionality, the
Technology has made it easier for the students to learn with
coverage of requirements at the software unit level should
new devices, but nothing can come close to the experience
be determined and the structural coverage shall be measured
of being taught by a teacher like you. Thank you Prof. Dr.
in accordance with the metrics listed. The test environment
Matthias F. Wagner.
should be as close as possible to the target environment.
6) Software integration and Testing: Integrate the software
components and demonstrate that the software architectural R EFERENCES
design is correctly realized by the embedded software. Soft- [1] Martin Hillenbrand , Funktional Sicherheit nach IOS 26262 in der
Konzeptphase der Entwicklung von Elektrik/Elektronik Architkturen von
ware integration test should demonstrate [6], [7]: Fahryeugen, KIT Scientific Publishing. 2012.
• Compliance with the architectural design and the HW/SW [2] Patrik Sternudd, Unambiguous requirements in Functional Safety and ISO
interface. 26262: dream or reality? , UPPSALA UNIVERSITY . December 2011.
[3] Chris Hobbs, Embedded Software Development for Safety-Critical Sys-
• Correct implementation of the functionality. tems, CRC Press . 20150720.
• Robustness. [4] Mark Vernacchia, Galen Ressler, Padma Sundaram , System Safety
• Sufficiency of the resources to support the functionality. Process Applied to Automotive High Voltage Propulsion Systems, ISSC
Tutorial . August 2015.
7) Verification of Software Safety Requirements: Demon- [5] National Instruments , What is the ISO 26262 Functional Safety Standard,
strate that the embedded software fulfills the software safety http://www.ni.com/white-paper/13647/en/ . Apr 03, 2014.
[6] International Organization for Standardization, International Standard
requirements and embedded software satisfies its requirements 26262: Road vehicles Functional safety , International Standard. First
in the target environment.The results of the software safety edition. Nov. 2011.
requirements’ verification shall be evaluated in accordance [7] LDRA, ISO 26262 the Emerging Automotive Safety Standard,
https://goo.gl/GeJhdu . Nov 01, 2017.
with [6], [7]:

View publication stats