ISO/PAS 8926:2024 – Functional safety of Road vehicles – Use of pre-existing software architectural elements

The International Organization for Standardization (ISO) recently published ISO/PAS 8926:2024 which describes a framework for functional safety to enable the use of pre-existing software architectural elements which are not originally developed in accordance with the ISO 26262:2018 series.

In the following interview with Saylee Shimpi and Mehdi Tavakoli, INVENSITY’s software development and safety experts, we look at the newly published standard and discuss its background, the scope, and details of it, as well as the shortages of ISO 26262 when it comes to safe usage of pre-existing software architecture elements in the development.

INVENSITY: Let’s start with the most basic question: What is a pre-existing software architecture element (PSAE) and what is the importance of these architectures? Can you provide some examples?

Saylee: Sure, basically the PSAEs are components or aspects of a software (SW) that, as the name suggests, already exist before starting a new project. These could include modules, frameworks, design patterns, data models, interfaces, or architectural styles. They are an integral part of SW architecture because they act as building blocks that can be reused to speed up development. For the automotive industry some relevant examples are AUTOSAR (AUTomotive Open System ARchitecture), which is a standardized software architecture used for automotive electronic control units (ECU), or perhaps Linux, which is used by many automotive manufacturers and suppliers as the foundation for their in-vehicle infotainment systems. Similarly, Advanced Driver-Assistance Systems are currently increasingly using Linux for processing sensor data, executing real-time algorithms, and coordinating vehicle control functions. Other examples include Model-Driven Development (MDD) Tools, such as MATLAB/Simulink, and of course, IBM Rational Rhapsody, which provide pre-existing architectural frameworks and modeling environments that are customized for automotive software development.

INVENSITY: What are the challenges that the OEMs and suppliers face when it comes to using pre-existing software architecture elements, especially when it comes to safety?

Mehdi: Well, even though these architecture elements offer a lot of benefits in automotive applications, it remains a big challenge to ensure safety of these pre-existing architectures. It is mostly because although the ISO 26262, the international standard for functional safety in the automotive industry, provides a framework for managing safety-related risks throughout the development lifecycle, it does not fully cover all aspects of safety assurance for pre-existing software.

INVENSITY: Can you elaborate more on that? How does ISO 26262 address safety of software development in general and what are the focus points?

Mehdi: Well, ISO 26262 provides different approaches for developing a safe software. Context development (Part 6) defines criteria and processes to ensure safety within specific contexts and focuses on software development considerations.

Another approach is proven in use argument (Part 8.14) which proves software safety through real-world performance and reliability data collected from field deployments. Software safety element out of context (Part 10) addresses the use of software components in non-standard environments and provides guidelines to ensure safety. In addition, the qualification of software components (Part 8.12), provides requirements to assess this qualification for their suitability for re-use in items developed in compliance with the ISO 26262.

One of the primary limitations of ISO 26262 in this context is that it focuses on compliance with formal software processes and does not provide specific guidance on the evaluation of pre-existing software. The standard offers processes for the development of new software but lacks clear directives for assessing the safety and reliability of existing codebases.

Saylee: What I can add is the verification strategy prescribed by ISO 26262, which is not adequately defined to address the complexity of pre-existing software architectures. Legacy codebases often contain complex interdependencies and undocumented functionalities which makes it challenging to apply conventional verification techniques effectively. Another concern is the management of software changes during and after the qualification process. ISO 26262 does not provide clear solutions for addressing modifications to pre-existing software which leads to uncertainty regarding how changes may impact the system’s safety.

INVENSITY: How does ISO 26262 define the verification strategy and what are the activities recommended by this standard? How should these be adapted for legacy codebases?

Saylee: ISO 26262 recommends different verification activities for software development, including unit testing, integration testing, software integration testing, software/hardware integration testing, and software validation testing. These activities ensure that software functions correctly and meets safety requirements throughout its development lifecycle.

When dealing with legacy codebases, these verification activities may need adaptation. For example, legacy codebases often lack adequate documentation, have outdated technologies, and may not adhere to modern coding standards. As a result, verification activities may require additional effort and adjustments.

INVENSITY: How can our partners in this field achieve compliance with ISO 26262?

Mehdi: To achieve ISO 26262 compliance in automotive software development, there are different accepted ways that can be followed. Recognized safety standards and best practices, such as MISRA C for coding guidelines or AUTOSAR for automotive software architecture, help align the development process with ISO 26262 criteria.

Additionally, as a framework for software process assessment, Automotive SPICE (Software Process Improvement and Capability Determination) offers a structure for evaluating software development processes in the automotive industry.

In general, ISO 26262 is suitable to drive the design of a newly developed software component assigned with a specific ASIL and its integration within the rest of the system, but there is a need for clarification for the qualification of pre-existing software components, specifically the pre-existing software like Linux.

INVENSITY: So what efforts have been made to address this challenge and provide clarification?

Mehdi: To close this gap, the International Organization for Standardization (ISO) recently published ISO/PAS 8926:2024. It describes a framework for functional safety to enable the use of pre-existing software architectural elements which are not originally developed in accordance with the ISO 26262 series but intended to be integrated into safety-related embedded software.

Saylee: The standard tries to address this challenge at large by determining relevant criteria when using the PSAE as a safety-related element, identifying criteria inherent to the PSAE such as the need for external safety mechanisms to detect and control failures caused by the PSAE, and providing suitable evidence and arguments for use of the PSAE that can include applicable procedures and techniques.

Furthermore, the standard addresses the challenge by supporting the fulfillment of software safety requirements when using the pre-existing software architectural element and facilitating its integration as a safety-related element.

INVENSITY: Let’s dive deeper into the details and the content of the new standard. Can you elaborate more on that?

Mehdi: Sure, the standard contains 4 clauses and Annexes A and B, of which only clause 4 is normative. In this clause, ISO 8926 focuses on the classification of PSAEs, which is used to justify the tailoring of specific safety activities to mitigate the risk of integrating the PSAE in the target software architectural design. The classification is based on criteria that consider the possibility that the uncertainty related to the process applied to PSAE development may increase the likelihood of systematic faults; and the possibility that the complexity of the PSAE can make finding systematic faults more difficult.

In addition, the role of the classification and the dependencies with the target software architectural design is provided based on an impact analysis that analyses the PSAE through the operational context, existing safety-related documentation, and complexity and provenance risks.

Figure 1: Illustration of dependencies with the target software architectural design through impact analysis based on ISO 8926:2024

n subclauses 4.4.4 to 4.4.6, the standard offers details on procedures for evaluating the suitability of class II PSAEs (4.4.4), verifying their usage (4.4.5), and managing design changes (4.4.6). Additionally, the standard specifies work product requirements, applicable across all PSAE classes (4.5.1), as well as specific requirements for PSAE class II (4.5.2).

In Annex A, examples of PSAE including the implications of its use on functional safety are provided and Annex B introduces examples of complexity measures including complexity measures derived from ISO 26262-6 in B.2 as well as complexity measures using other published industry practices in B.3. These guidelines collectively provide a structured approach to ensure the quality and reliability of PSAEs in safety-critical applications.

INVENSITY: That is a lot of useful information, thank you for your insight. To wrap things up, how would you as safety and software experts use this new standard to cater to our partners’ challenges?

Saylee: Although the ISO standard is new to the industry, the expectation is that it brings along fundamental procedures that can solve previously overlooked challenges and provide unique solutions for them. We at INVENSITY use this new standard to its ultimate potential based on our expertise to offer our partners guidance on assuring the safe usage of PSAEs in their development.

Mehdi: As Saylee mentioned, using the standard as a tool or specification is not a challenge. The real challenge comes with using the same standard in different scenarios for different industries and still maintaining the same quality and safety of architecture. This is where we at INVENSITY come into play and offer our services to our partners.