Software Verification and Validation for Automotive Functional Safety

Software Verification and Validation for Automotive Functional Safety

Software verification and validation (V&V) has existed for a long time. When software controls were introduced into industrial settings, people quickly realized that they would need to ensure that those programs would perform to their specifications. Industrial standards for performance monitoring evolved from that need. However, in the modern automotive manufacturing environment, and most especially as Software-Defined Vehicles come to the forefront, software verification, and validation processes for automotive functional safety become far more important. These processes are vital to functional safety compliance.

In automotive functional safety, software V&V is no longer for performance monitoring only. These two independent program evaluation processes are of critical importance. For one thing, embedded software is far more prevalent and complex than ever before. These days there simply are no automobiles without software; all new vehicles are software-defined. And there should be no embedded software onboard those vehicles without ISO 26262: 2018-compliant verification and validation to safeguard against, among other things, “foreseeable misuse, incomplete input data, incomplete update of the software tool, [and] use of prohibited combinations of configuration settings.”

We’re going to look briefly at software verification and validation-relevant parts of the ISO standard, as well as some common problems and questions LHP has encountered in the past.

Table of Contents

• The safety-critical state of the art
• ISO 26262, Part 6 and Part 8
• Part 6
• Part 8
• Why does verification confirm the implementation of requirements?
• Why does validation ensure the embedded design functions correctly?
• What verification and validation methods are recommended and best comply with ISO 26262?
• How can the process be tailored and customized for different OEMs and suppliers?

The safety-critical state of the art

The complexity and sheer volume of program code running onboard modern vehicles has increased immensely. For example, modern automotive engineering includes autonomous driving technology, increased interconnectivity between vehicles and their surroundings, and Advanced Driver Assistance Systems (ADAS). Features like ADAS and other autonomous technology of modern Software-Defined Vehicles (SDVs) mean that the software-defined devices and systems in vehicles are considered safety-critical. It seems likely that these features specifically will be the subject of further government regulation in both the European and North American markets in the future.

For automakers and their suppliers, especially those involved in producing SDVs or their components, Functional Safety (the ISO 26262 standard) is the state-of-the-art. This does not necessarily mean a generic dictionary definition, such as, “highest level of development reached at any particular time.” State-of-the-art in functional safety is the current and accepted best practice using stable and accessible technology, not necessarily the highest-technology answer to any problem. Therefore, while functional safety compliance may not yet be technically required by law, you could certainly say that it is a strongly encouraged practice.

Process and development methodology plays an important role in addressing the challenges facing modern automotive suppliers and manufacturers. In the next section, we will look at how the two most salient sections of ISO 26262 can affect manufacturers in terms of software verification and validation, and how LHP’s approach to these essential processes can benefit your software methodology. This will show how LHP can help our clients to meet challenges like the added complexity of the vehicles themselves, as well as the increasing industry-wide demands for both high quality and high productivity that manufacturers and their suppliers face.

ISO 26262, Part 6 and Part 8

Source: ISO 26262-6: 2018 (International Organization for Standardization [ISO], 2018).

Each of the twelve parts of ISO 26262 opens with a section for normative references and a link to the International Electrotechnical Commission’s (IEC) Electropedia, which provides specific working definitions for the terminology used in the standard.

ISO 26262 provides a terminology list in Part 1. From there, we know that verification is a “determination whether or not an examined object meets its specified requirements.” Also, in Part 1 there is a terminology entry for safety validation, which states, “assurance, based on examination and tests, that the safety goals (3.139) are adequate and have been achieved with a sufficient level of integrity.” The double-v diagram shows Part 6 of ISO 26262 is concerned with verification. Part 8, “supporting processes,” has language regarding both the validation and qualification of tools for use. The double-v process model is a bit like a map and a bit like a timetable, showing process development step by step, with markers to indicate what parts of the standard would govern each step of the development.

Part 6

ISO 26262 Part 6 is dedicated to the responsibilities of manufacturers and suppliers in terms of software development. There are chapters detailing the specifications, safety requirements, and architectural design of the software, i.e., the design and implementation of different systems. Additionally, some sections describe specific requirements for verification and validation testing and documentation for traceability.

Part 8

Part 8 of the ISO 26262 standard details the obligations for the ancillary processes required for implementing software developments and designs. Part 8 deals with software tool qualifications and the obligation for software tools to be certified and endorsed by a globally known third party. Part of this tool qualification process is proving, and documenting, that any known defects in the tool have already been mitigated and won’t affect the verification or validation test results. This part of the standard also calls out the validation requirements for a developer’s software to be compliant.

Why does verification confirm the implementation of requirements?

Interestingly, the IEC Electropedia definition and the ISO definition of verification differ slightly. We can see the differences here:

It might also be interesting that ISO further breaks verification into formal and semi-formal, depending on the type of notation being used. One other deviation to observe is that the IEC states they use the ISO 9000: 2005 standard as their source for this definition, so while it is more detailed, the IEC’s definition may not be as specific to automotive functional safety as the example from ISO is. Both these definitions, at any rate, are concerned with a tool or system meeting formal requirements.

Verification includes testing the software and system to the requirements, auditing them for quality, and having experts review them to confirm that they conform to design specifications. In other words, verification testing is to ensure that the program or device works as intended and that there is traceability and a document trail that demonstrates that the software is compliant. The design has to conform to the requirements of the specification.

Why does validation ensure the embedded design functions correctly?

Validation, again per the IEC Electropedia, is “confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.” So, this is testing to show that the specified requirements for a particular software tool or device are in line with the needs of the customer. The end product has to function properly. Validation testing on the finished product must confirm that the safety-specific design goals for the product are robust and sufficient, and that the product will function as it should.

The two independent processes of verification and validation work together to reduce risk.

What verification and validation methods are recommended and best comply with ISO 26262?

Here are some of the questions the standard requires software developers – for both suppliers and manufacturers – to consider when producing code to be used in a Software-Defined Vehicle.

Verification variables: ISO 26262 recommends a suite of methods for software V&V, and these can differ based on whether the software’s architectural design is under verification, or on the intended use of the software units themselves, for example. In some cases, the results derived from one step or method can affect the use of a subsequent one. These methods can include walk-throughs, inspections of the design or function, formal and semi-formal verification, code analysis, simulation of dynamic behavior, prototype generation, and many others. The best way to know exactly which methods are mandated by ISO 26262 for your organization’s projects is to contact LHP’s functional safety experts. They will partner with you to create a custom package based on the unique needs of your engineering staff and situation.

ABCs of risk: verification, validation, and the Automotive Safety Integrity Level (ASIL): Certain verification or validation methods can be more highly or less highly recommended for use during development, depending on the risk classification rating of the feature that the software or system will control or produce.

ISO 26262 classifies the risk on a four-point alphabetical scale. The severity, exposure, and controllability of a possible failure in a given feature are analyzed and assessed; these produce the ASIL rating of a feature. While this blog offers only a simple overview, these are some examples of how the standard would assign ASIL value to some features when performing verification of software architecture. Even ASIL “A” is not without consequence, but we can see how the systems involved become more critical as the scale ascends:

An illustration of the way ASIL works together with V&V methods could go as follows: in verifying software architecture, ISO recommends a walkthrough for features at ASIL B, and strongly recommends it for features at ASIL A, but for ASIL C and D this method is not needed.

However, another method, prototype generation, is not required for ASIL A and B, but ISO 26262 shows it is recommended for features at ASIL C, and strongly recommends prototype generation for features that come in at ASIL D.

How can the process be tailored and customized for different OEMs and suppliers?

LHP provides custom-tailored risk identification and hazard assessment, as well as expert verification and validation assistance, as part of a suite of solutions in a custom LHP Functional Safety package. A consultation, training package, or full-suite solution from LHP reduces risk to your organization by avoiding rework, tailoring solutions to your needs, and finding the swiftest and surest path to ISO 26262 compliance.