Vehicle Engineering Processes

Introduction

While it may not seem directly related to cybersecurity, remember that software bugs are usually the source of many vulnerabilities and exploits.

Like other industries, such as aerospace or medical equipment, where product defects can put human lives at risk, the automotive industry has a high standard for electronics and software quality to minimize bugs and defects. These standards already introduce many software best practices, which overlap with the recently developed cybersecurity standards.

This lesson gives an overview of the existing standards widely used in automotive software development and the newly introduced cybersecurity standards and regulations.

AutomotiveSPICE

AutomotiveSPICE is an automotive-specific adaptation of the ISO/IEC 15504 standard (and subsequent standards) for Software Process Improvement and Capability Determination (SPICE), a set of technical standards documents for the computer software development process and related business management functions. German Association of Automotive Industry VDA Quality Management Center develops this framework.

ASPICE level compliance and assessment is often (not always!) requested by OEMs to ensure software quality from suppliers and be used as an internal quality assurance tool. ASPICE process capability level, similar to SPICE, is rated from level 1 to level 5 for each development, whereas most major OEMs today will require levels 2 to 3 from their suppliers.

The latest version of ASPICE includes cybersecurity-related activities (based on ISO/SAE 21434 but in more detail about traceability) into its assessment model. Therefore it is beneficial to be aware of any requirements in the latest ASPICE model and existing ASPICE implementation within an organization when developing the Cybersecurity Development Lifecycle.

For engineers, AutomotiveSPICE requires a detailed software development process, a granular breakdown of requirements and design activities/documentation, and bi-directional traceability between requirements, implementation, and testing. In addition, supporting functions such as Quality Assurance, Project Management, Configuration Management, and Purchasing may be involved. At higher levels of ASPICE compliance, all processes must be documented, and the METHOD to improve the processes must be in place and followed.

The following AutomotiveSPICE Reference and Assessment Model r3.1 diagram shows the areas assessed under an ASPICE audit.

Reference: https://www.automotivespice.com/

Functional Safety

Functional Safety for Road Vehicles, as described in ISO 26262, is an engineering process standard that represents the best practices when designing safety-related functions performed by an E/E system in a road vehicle. Any function whose malfunction could cause a safety hazard for a human would be considered a safety-related function.

For example, the unintended acceleration of the vehicle caused by the malfunctioning software of the Electronic Throttle Control System may be a MAJOR functional safety hazard. In contrast, the injury caused by malfunctioning a load sensor in the pinch-protection system of self-folding seats may be a minor function safety hazard.

Note that the safe state is not necessarily “safe” in all circumstances (there is another standard for that)."

Functional Safety considers likely human errors, systematic errors, hardware failures, and operational/environmental stress and responds to an error by reaching a predictable state (safe state). Note that the safe state is not necessarily “safe” in all circumstances (another standard exists for that).

ISO 26262 describes a method for rating the level of safety risk of an item (vehicle function) whose malfunction could lead to a hazard. The Automotive Safety Integrity Level, or ASIL level, is rated from A to D, with ASIL-D representing the highest hazard level and ASIL-A the lowest. A development process and assessment similar to the ASPICE process is applied for all systems with any ASIL rating, except with a target focus on safety-related items.

Major safety-critical systems have strict requirements to design with multiple redundancy and fault detection throughout the critical path, where any electronic or software malfunction could lead to potential hazard(s). In addition to this, the standard requires rigorous rounds of design review and validation at different levels using recommended methods.

At a glance, one may find the wording and structure of ISO 21434:2021 very similar to that of ISO 26262:2018. This is due to having many overlapping members on the authoring committee and the fact that the industry is already familiar with ISO 26262 since the first edition released in 2011 (even earlier with IEC 61508 since the late 90s). However, one should not assume when encountering two similarly worded terms that they are the same. For example, a “TARA” can be performed at the vehicle, item, or component levels, but the OEM explicitly performs a HARA at the vehicle level.

Furthermore, while ISO 26262 is so widely applied that you can’t get away with not adhering to its requirements in court, Functional Safety has never been mandated by regulation (wow, really?), and no consensus has been reached within the industry on the assignment of safety levels for various standard components.