ISO 26262 Software Compliance in the Automotive Industry

UNECE WP.29 Regulatory Requirements

The United Nations Economic Commission for Europe (UNECE) released regulatory requirements on June 23, 2020, where they outlined new processes and technologies that automotive manufacturers must incorporate into both their organization and vehicles. These regulations also apply to Tier 1 and Tier 2 suppliers of software and hardware components, including mobile services.

Vehicle manufacturers are required to put into the organizational structure a risk-based management framework for discovering, analyzing, and protecting against relevant threats, vulnerabilities, and cyberattacks.

The following categories require cybersecurity testing and passing inspections.

• Category M covers standard four wheel cars.
• Category N is for pickup trucks and vans.
• Categories L6 and L7 include electric cars and autonomous capabilities.

A passing grade on both organizational and vehicle WP.29 key requirements means that the manufacturer receives a certificate of compliance. New vehicles without this certificate cannot be sold in the EU after July 2024. Be aware that the United States does not participate or have its own similar regulations. However, the writing is on the wall.

Automotive Spice

Automotive Software Process Improvement and Capability Determination (ASPICE) provides a measurement framework for independent assessors to evaluate an organization’s capability for software development. Ensuring software safety and cybersecurity does not only lie within the technical engineering aspects of the development of the electronic system, but also requires the organization to incorporate processes and checks.

These processes and checks must include ways to track and monitor progress within all practices of the organization to ensure:

1. Safety and cybersecurity practices have been adopted.
2. Safety and cybersecurity requirements are being satisfied.

This is also one of the two key certification criteria for UNECE WP.29 on organizational cybersecurity capability.

Unsafe Scenarios

It’s brought to fruition other outgrowths from ISO 26262, like ISO/PAS 21448 more commonly referred to as SOTIF (safety of the intended functionality). SOTIF helps you analyze and prevent the misuse of the intended functionality where it creates an unsafe scenario. For example, your vehicle inadvertently shuts down while you’re driving it, due to an initiated software update.

Security vulnerabilities also pose unsafe scenarios. An attacker could use the car’s Wi-Fi connection to remotely exploit an exposed port. They could somehow work their way from the advanced in-vehicle infotainment (IVI) into taking control of, or influencing, safety-critical components like braking or steering due to sharing the same communications infrastructure.

The Role of Standards

Standards like SAE J3061, superseded by ISO/SAE 21434, specify that an initial Threat Analysis and Risk Assessment (TARA) be completed to assess potential threats related to operation, privacy, and other factors where a road user/driver can be impacted. If the risk for any threat is sufficiently high, then a cybersecurity process is necessary. There are various approaches to flushing out security vulnerabilities and requirements that mitigate the risks. Learn more about TARA and why your development team needs TARA.

Standards like UL 4600 now exist specifically for fully autonomous vehicle operation. This means that there is no human supervision, and the autonomy assumes full responsibility. This standard focuses on building a safety case for the deployment of SAE Level 4/5 vehicles, not on how to test safety of autonomous vehicles on public roads. That would involve a different standard.

These standards and others play a crucial role in safety and security for the automotive industry. OEMs carry the liability costs for delivering unsafe and insecure vehicles to the masses. To mitigate these risks, OEMs need to adopt and adhere to these standards. However, OEMs should mandate the same quality and adherence by their suppliers. A weakness in one component can undermine the safety and security of the entire system.

Building Custom Coding Standards

Working with some of its automotive OEMs, Parasoft has built custom coding standards that incorporate MISRA, AUTOSAR C++14, CERT, CWE, and other custom rules to be used by their suppliers. This ensures that the same level of quality software exists across the entire supply chain.

Parasoft C/C++test is a unified testing solution that includes unit testing and structural code coverage as part of its functionality. This solution for C/C++ software development supports a comprehensive set of hardware targets and development ecosystems that suppliers and OEMs can use with varying development infrastructures. C/C++test has been certified by TÜV SÜD for use on safety and security-critical systems. For ADAS and secure connected cars, C/C++test’s seamless integrations with SOAtest and Virtualize combine API testing with runtime application coverage and simulated virtual test beds.

Performing Hazard Analysis and Risk Assessment

In ISO 26262, a hazard analysis and risk assessment (HARA) needs to be performed on the system under development. Upon completion of the HARA an ASIL is assigned to the software component and there are levels A through D. Level A represents the lowest hazard assignment and Level D represents the highest hazard assignment. Meaning that the failure of a system with ASIL D assignment could be catastrophic.

There is also a quality management (QM) level assignment, which means that there is no safety requirement. ASIL is assigned by taking the severity of the injury times the probability of the failure times the controllability. The following table spells out each level for severity, exposure, and controllability.

Severity = What would be the impact or damage if the failure occurred?

Exposure = The frequency or probability that the failure would occur.

Controllability – The extent to which we can ensure that the event doesn’t happen.

There are several tables freely made available that provide help in determining the ASIL value. The table below is an example of one that’s much easier to read and shows the ASIL levels in colors based on severity, exposure, and controllability.

Active and Passive Safety

Roadside vehicles come with lots of safety systems, and some are considered active safety and others passive safety.

Active safety is used to refer to technology assisting in the prevention of a crash or accident. You have your traction control, anti-lock braking system, vision ADAS, and others.

Passive safety systems are to keep the passengers safe. For example, in case of a crash, you have airbags, and seatbelts. The electronic windshield wiper and instrument cluster are also passive safety systems.

Performing Test Verification and Validation of Software Unit Design and Implementation

Since the focus of this guide is software, it’s important to cover the test verification and validation methods recommended by the standard. For example, Table 7 captures verification methods 1a through 1k to be applied during unit design and implementation. Method 1h, “Static code analysis” is highly recommended for ASIL levels A through D.

The columns in Table 7 on the right show A to D ASIL levels. A single “+” symbol indicates recommended by the standard, a double “++” indicates highly recommended, and an “o” indicates no recommendation.

Other key methods of verification are done through dynamic analysis, for requirements-based testing and fault injection. ISO 26262 Table 8 for example has “Analysis of boundary values”.  This is a method for deriving a test case to flush out defects by means of proving inputs into the unit that are not just the min, mid, and max, but the boundaries outside the scope of its range, to see if the unit is robust enough to handle these outlier cases.

And Table 9 lists the recommended structural code coverage metrics to ensure test coverage, flush out dead code, and hidden defects.