ISO 26262 “Road vehicles – Functional safety” automotive electrical and/or electronic (E/E/PE) systems, with far-reaching implications for associated software systems. It discusses the assignment of Automotive Safety Integrity Levels (ASILs) and the development of safety-critical software to fulfil the resulting requirements.
There is an ever-widening range of automotive electrical and/or electronic (E/E/PE) systems such as adaptive driver assistance systems, anti-lock braking systems, steering and airbags, and increasing levels of integration and connectivity. The result is a necessity for exacting functional safety development processes, from requirements specification, design, implementation, integration, verification, validation, and through to configuration.
The second edition of ISO 26262 was released in 2018, having first been published in 2011 in response to this explosion in automotive E/E/PE system complexity and the associated risks to public safety. ISO’s official documentation indicates that the third edition of ISO 26262 is under development, but specific timelines for its release are not provided.
ISO 26262 second edition provides detailed industry specific functional safety guidelines to produce all software for automotive systems and equipment, whether it is safety critical or not.
The illustration above, excerpted from the standard, outlines all 12 parts of ISO 26262. The highlighted sections represent part 4 (system level) and part 6 (software level) which are particularly pertinent to software developers.
The depicted lifecycle that can be distilled into eight core objectives:
Functional safety addresses risk management in a piece of equipment or a system.
Functional safety development processes aim to identify potentially harmful conditions. The harmful conditions are classified according to the severity and mitigated using safety mechanisms to avoid or reduce the impact of an incident such that the response is proportionate to the risk.
In practice, functional safety relies on active systems that can implement risk control measures in response to potentially dangerous situations. Central locking serves as a good example. If a vehicle is involved in an accident and there is a danger of fire, the safety goal will be to ensure that the driver and passengers can get out. Conversely, under normal circumstances the safety goal will be for the door to remain closed when the vehicle is in motion.
ISO 26262 is applicable to both circumstances. It defines processes that are necessary for the safe design and maintenance of automotive software. The standard breaks the processes down into activities and tasks, the thoroughness of which varies in proportion to the criticality of the software.
According to the abstract for ISO 26262, it “…describes a framework for functional safety to assist the development of safety-related E/E systems. This framework is intended to be used to integrate functional safety activities into a company-specific development framework.” The idea is to provide a common foundation for all stakeholders to apply best practice and achieve continuous improvement – not to mandate those things. That leaves room for flexibility and manoeuvre.
Although conformance with the standard is not mandatory, acceptance of the standard is so widespread that non-conformance would be a major commercial obstacle for automotive products. OEMs (vehicle manufacturers) do have an obligation to ensure the safety of their products with due diligence, and the industry in general acknowledges ISO 26262 to represent best practice in achieving that. In turn, OEMs usually enforce conformance throughout their supply chain.
ISO 26262 defines several hazard classifications levels, known as ASILs (Automotive Safety Integrity Levels). In practice, these ASILs are attributes of the safety goals derived from hazard analysis.
The development of safety-critical systems with higher ASIL ratings, such as ASIL D functions like automatic braking, involves more rigorous verification and validation activities compared to lower ASIL functions, such as in-car entertainment systems with limited safety relevance (typically ASIL A or QM). These additional safety measures ensure a higher degree of confidence in the system’s ability to operate reliably under all relevant conditions. In ISO 26262, ASILs are assigned to individual safety functions rather than to entire systems or components. The determination of each ASIL is based on a combination of the likelihood of the hazardous situation occurring (“exposure”), the potential harm it could cause (“severity”), and the driver’s ability to avoid the harm (“controllability”).
ASILs are assigned as properties of each individual safety function at the item level, where an item is defined as a “system or combination of systems, to which ISO 26262 is applied, that implements a function or part of a function at the vehicle level”.
The acronym ASIL stands for Automotive Safety Integrity Level. The term “ASIL level” therefore expands to “Automotive safety integrity level level”. That’s obviously wrong!
Three properties of the hazardous events associated with a safety function dictate its ASIL assignment.
The standard uses several tables to represent the relationships between these properties, but they are easier to visualize when represented in a single ISO 26262 ASIL table.
| Severity | Exposure | Controllability | |||
|---|---|---|---|---|---|
| C1 | C2 | C3 | C4 | ||
| S0 | E1 | QM | QM | QM | QM |
| E2 | QM | QM | QM | QM | |
| E3 | QM | QM | QM | QM | |
| E4 | QM | QM | QM | A | |
| S1 | E1 | QM | QM | QM | QM |
| E2 | QM | QM | QM | QM | |
| E3 | QM | QM | QM | A | |
| E4 | QM | QM | A | B | |
| S2 | E1 | QM | QM | QM | QM |
| E2 | QM | QM | QM | A | |
| E3 | QM | QM | A | B | |
| E4 | QM | A | B | C | |
| S3 | E1 | QM | QM | QM | A |
| E2 | QM | QM | A | B | |
| E3 | QM | A | B | C | |
| E4 | A | B | C | D | |
| S0 denotes lowest and S3 highest severity of an accident | |||||
| E0 denotes lowest and E4 highest exposure | |||||
| C0 denotes best and C3 worst controllability | |||||
The standard specifies development process checks and safety measures to avoid an unreasonable residual risk proportionate to the ISO 26262 ASIL classification. ASIL A, B, C and D apply where the risk associated with a hazardous event requires safety measures, and the QM (“Quality Management”) level where it does not. ASIL D represents the most hazardous and hence demanding level so that the overhead involved in producing a safety critical ASIL D system (e.g. automatic braking) is significantly greater than that required to produce an ASIL A system with few safety implications (e.g. the in-car entertainment system).
The illustration below shows “Table 7: Methods for the verification of software unit design and implementation” which is typical of the tables in ISO 26262 that specify the processes required for compliance throughout the development lifecycle. The higher the ASIL, the more demanding the processes.
Table 7
Decomposition is usually performed to take advantage of reduced complexity, cost, time, labour and tools. Decomposition of the different ASIL ratings throughout the item can occur over different systems, elements, and components, working down through the systems, subsystems, software, and hardware. Typically performed manually, ASIL decomposition must result in redundant safety requirements allocated to design elements of sufficient technical independence.
There are many international standards for automotive systems and automotive software development. This is not a comprehensive list.
ISO 26262 is based on the industry agnostic functional safety standard IEC 61508. Although there is much in common between the two standards, ISO 26262 implicitly acknowledges pre-existing best practice in the automotive industry, its terminology, and its high-volume output compared to most safety-critical sectors.
Many of the practices adopted by IEC 61508 and its derivatives can are rooted in the commercial and defence avionics industries. The RTCA Inc. series standards such as DO‑178 have proven that adherence to a structured set of best practices results in large scale reliable systems that protect public safety. Although ISO 26262 even in its original form was a relatively recent innovation, this history is significant because the establishment of functional safety standards elsewhere gave rise to a sophisticated industry providing support for their effective application. Consequently, the automotive industry benefits from established and proven tools and techniques predating ISO 26262 itself, including the LDRA tool suite.
ISO/IEC 15504 “Information technology – Process assessment”, otherwise known as Software Performance Improvement and Capability dEtermination (or SPICE) consists of a set of technical standards that collectively form a framework to measure the maturity of software development processes. It is focused on software quality, unlike ISO 26262’s focus on functional safety.
A domain specific version of SPICE, Automotive Software Performance Improvement and Capability determination (Automotive SPICE, or colloquially ASPICE) was conceived by European car manufacturers to fulfil that same purpose in the automotive sector. ASPICE remains conformant with ISO/IEC 15504’s successor, the ISO330XX standard series.
The ISO 26262 standard takes a slightly different perspective. By focusing on functional safety in the automotive sector, it also promotes the development of high-quality software but with the specific aim of ensuring that developments are adequately safe, with due consideration of the risk involved should they fail.
Clearly there is overlap between the scope of ASPICE and that of ISO 26262, but it is possible to comply with both concurrently.
The quality management system standard ISO/TS 16949 was developed to meet the requirements and expectations of automotive manufacturers and the supplier industry. The focus is on continuous improvement, fault prevention and minimising rejects in the supply chain. It is a supplement to the ISO 9001 standard and contains the basic requirements for quality management systems in the automotive industry.
There is some overlap between ISO 26262 and ISO/TS 16949, but for the most part they are complementary to each other because ISO/TS 16949 applies to corporate processes, and ISO 26262 is product focused.
The Classic Platform is AUTOSAR’s established solution for embedded systems with hard real-time and safety constraints. Traditionally, software development for automotive applications was completed in isolation by OEMs or their suppliers. This led to a lot of duplicated effort amongst players in the automotive sector, prolonged development cycles, and a lack of commercial flexibility especially when updates to either hardware or software were required. The Classic Platform addresses those deficiencies by providing a clearly defined layer of abstraction.
The Adaptive Platform is AUTOSAR’s solution for high-performance computing ECUs to build safety-related systems for use cases such as highly automated and autonomous driving. It is complementary to the AUTOSAR Classic Platform, and not a replacement for it.
The purpose of the Foundation standard is to enforce interoperability between the AUTOSAR platforms. It contains requirements and technical specifications common to the AUTOSAR platforms – for example, communications protocols.
The Classic and Adaptive platforms each dictate technological characteristics for the development environment, including coding standards, RTOSes, communications protocols and so on. Adherence to either AUTOSAR platform standard does not in itself imply compliance with ISO 26262, and so they need to be considered concurrently. The AUTOSAR Technical Briefing concurrently in one seamless entity can help address a potential project management lifecycle.
ISO/SAE 21434:2021 “Road vehicles — Cybersecurity engineering” describes an automotive security engineering process. It is complementary to ISO 26262 and focuses on cybersecurity risks in the development of automotive electronics. The standard requires the implementation of cybersecurity best practices throughout development, production, and operation.
ISO 26262 remains pertinent today, but because it was introduced before the emergence of the connected car it does not specifically address the risks associated with connectivity unless they present a risk to safety. ISO/SAE 21434 is therefore complementary to ISO 26262.
ISO/SAE 21434 effectively replaced Technical briefing – SAE J3061 and ISO 26262? They’re made for each other. The two international standards differ a little in style in that SAE J3061 related the security processes and ISO 26262 safety processes to each other, and ISO/SAE 21434 decouples them.
From a software perspective, the ISO/SAE 21434 standard does little more than ratify the document it replaces. However, both ISO/SAE 21434 and SAE J3061 present a worthy set of goals for software developers to achieve, and the lack of detail affords flexibility on how they are achieved.
The LDRA tool suite helps ease the path to compliance by automating the required validation and verification work and by providing traceability throughout the life cycle, complete with evidential artefacts such as the ISO 26262 compliance matrix shown below.
A key element of ISO 26262:4 is the practice of allocating technical safety requirements in the system design specification and developing that design further to derive an item integration and testing plan. It applies to all aspects of the system including software. Hardware and software development practices are subdivided later in the lifecycle.
The relationship between the system-level processes outlined in ISO 26262-4 and the software-specific sub-phases detailed in ISO 26262-6 is often illustrated using a V-model. While this model effectively captures the structured flow of development and validation, it is important to note that ISO 26262 does not mandate its exclusive use.
The diagram below also illustrates how the LDRA tool suite and other tools fit into the ISO 26262 development process.
Each of these sub-phases is detailed further in ISO 26262 and a sequence of tables shows how particular techniques are to be applied to compliant developments depending on the assigned ASIL. As an example, the illustration below shows an adapted version of table 9 from ISO 26262:2018-6. The higher the ASIL, the more comprehensive and hence more demanding the structural coverage data required.
Part 4 gives consideration to software development in the context of the system design for the product as a whole. The products of this design phase potentially include CAD drawings, spreadsheets, textual documents and many other artefacts. The management of the status of each of those elements and maintaining traceability between them and subsequent phases can cause a project management headache.
The ideal tools for requirements management depends largely on the scale of the development. If there are few developers in a local office, a simple spreadsheet or word processor document may suffice. Bigger projects, perhaps with contributors in geographically diverse locations, are likely to benefit from an Application Lifecycle Management (ALM) tool.
Part 6 section 5 is omitted from the V mode diagram above for good reason. It focuses on planning and preparing for software development and so is arguably before the establishment of the model itself. However, it includes defining how the objectives of the subsequent hands-on development phases (like design, implementation, integration, and testing) will be achieved and so has a major impact on the detail of each of the subsequent sections that are represented in the diagram.
Decisions made at this time will likely impact the extent to which the development process can be automated, and that can have a major bearing on overhead.
Part 6 section 6 involves the derivation and documentation of software requirements based on the system requirements. The TBmanager component of the LDRA tool suite helps by automatically maintaining the connections between the requirements, development, and testing artefacts and activities.
The sequential nature of the process defined by ISO 26262 can seem simplistic at first sight. In theory, if the example V-model is adhered to, then the requirements will never change, each phase will follow in sequence, and tests will never throw up a problem.
Consider what happens if there is a code change in response to a failed integration test, or where there is a change in a customer requirement. Such scenarios can quickly lead to situations where the traceability between the products of software development fails if the integrity of each development phase and the artefacts generated by them are not maintained. A sequence of similar issues can ultimately lead to a situation where the completed project does not fulfil functional, functional safety, or cybersecurity requirements.
For that reason, ISO 26262:2018 incorporates the principle of bidirectional traceability, requiring ongoing maintenance and integrity of the artefacts generated by each phase of the development lifecycle.
Adherence to this principle ensures not only that the delivered system accurately reflects the requirements of the stakeholders but also confirms that there is no superfluous code within the system – important from both a safety and security perspective.
The TBmanager component of the LDRA tool suite establishes traceability policy between requirements and tests cases of different scopes, which facilitates test coverage assessment. It can show the impact of failed test cases and requirements changes, and gaps in requirements coverage (pictured).
Traceability matrices and related artefacts generated by the tool suite are evidence of compliance to ISO 26262.
There are many tools available for the generation of the software architectural design, with graphical representation of that design an increasingly popular approach.
The TBvision component of the LDRA tool suite contributes to the verification of the design by reference to the control and data flow analysis of the code derived from it. It provides graphical representations of the relationship between code components for comparison with the intended design.
One of the key design principles is to ensure “Loose coupling” or “Strong Cohesion” between software components. For designers with no model-based tools or simulation tools, it is challenging to verify the coupling and provide the required evidence. LDRA tool suite’s capability to perform Data coupling analysis and Control coupling analysis is a great aid to for verifying these design principles when the code is available. ISO 26262:6 §8 Software unit design and implementation – coding guidelines
The table below shows the coding and modelling guidelines from the standard. They are designed to make the resulting code more reliable, less prone to error, easier to test, and/or easier to maintain. Automating the relevant checks using the LDRA tool suite is far more efficient, less prone to error, repeatable, and demonstrable than manual review.
Part 6 highlights the MISRA coding guidelines language subsets as being appropriate for use in ISO 26262 compliant applications.
Establishing appropriate project guidelines for coding, architectural design and unit implementation are clearly three discrete tasks but software developers responsible for implementing the design need to be mindful of them all concurrently. For example:
The LDRA tool suite provides metrics to ensure compliance with the standard such as complexity metrics as a product of interface analysis, cohesion metrics evaluated through data object analysis, and coupling metrics via data and control coupling analysis.
Dynamic analysis techniques (involving the execution of some or all of the code) are applicable to unit, integration and system testing. The TBvision and TBrun components of the LDRA tool suite provide appropriate facilities. Unit testing focuses on particular software procedures or functions in isolation, whereas integration testing confirms the fulfilment of safety and functional requirements when units are working together.
Part 6 tables list techniques and metrics for performing unit and integration tests on target hardware. Fault injection and resource tests further prove robustness and resilience and, where applicable, back-to-back testing of model and code helps to prove the correct interpretation of the design.
In addition to showing that the software functions correctly, these tests can incorporate structural (code) coverage analysis. In conjunction with the coverage of requirements at the software unit level, structural coverage analysis provides the necessary data to evaluate the completeness of testing and to demonstrate that there is no unintended functionality.
Metrics recommended by ISO 26262 and provided by the LDRA tool suite include functional, call, statement, branch and MC/DC coverage. Unit and system test facilities can operate in tandem, so that (for instance) TBvision can generate coverage data for most of the code base through dynamic system tests, with the remainder accessed using TBrun unit tests.
The LDRA tool suite integrates with several different model-based development tools. “Back-to-back” testing involves first developing and verifying design models. Code is then generated by the development tool, instrumented by the LDRA tool suite, and executed in either Software in the Loop (SIL or host) mode, or Processor In the Loop (PIL or target) mode. Structural coverage reports are generated from the resulting data.
The LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to demonstrate both the structural coverage analysis and programming rules checking capabilities of the tool suite itself in accordance with ISO 26262. In addition, associated documentation for the development and verification of the product is provided, including plans, procedures, and expected results.
Like many other safety critical standards including IEC 61508, IEC 62304, and EN 50128, ISO 26262 references the need for due consideration of response timing for time-critical applications, and memory constraints.
For time-critical functions, ISO 26262 requires that timing constraints should be included within the software safety requirements. Both the worst-case execution time (WCET) at the code level and the response time at the system level are to be considered, and there is reference to “appropriate scheduling properties”.
The WCET of a computational task is the maximum length of time that the task could take to execute in a specific environment. Hard real-time systems need to satisfy stringent timing constraints imposed by the nature of the functions they fulfil. Unfortunately, it is not possible in general to calculate definitive upper bounds on execution times for programs.
There are further complications in the case of multicore processors. The use of additional cores results in resources being shared between them. Time-related delays occur as users wait for access.
These interference channels cause the execution-time distribution to spread. Instead of a tight peak, the distribution of execution times becomes wide with a long tail.
This page presents a practical, compliant approach to addressing this problem. It involves the optimisation of system configuration by means of interference research through measured execution times using the TBrun component of the LDRA tool suite supported by the optional TBwcet module.
ISO 26262 (second edition) defines best practices for developing functionally safe automotive E/EE/PE systems, structured around an illustrative V-model with strong emphasis on bidirectional traceability. This ensures each development phase aligns accurately with the previous one. The standard introduces Automotive Safety Integrity Levels (ASILs) to categorize risk, with higher ASILs requiring more rigorous development and validation activities, detailed in summary tables throughout the standard.
The LDRA tool suite is highly effective in meeting these demands, especially in the sector-specific form of the LDRA Productivity Package for Automotive (below).
It provides automated support for traceability, code analysis, and testing, with the It helps manage the increasing complexity and documentation overhead associated with higher ASILs, making it easier for teams to demonstrate compliance with ISO 26262.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707