Exploring the World of Functional Safety: What’s New and Emerging
Joe Wlad from Verocel, along with David Barnett and Bob Leigh from Real-Time Innovations (RTI), dive into how ISO 26262 compliance works with approved software components for road vehicles.
These days, software plays a crucial role in innovation across all industries, especially in automotive applications. Cars have evolved from using software just for basic diagnostics to incorporating advanced information, entertainment systems, and even autonomous driving features.
Modern vehicles now come with tens of millions of lines of code that manage everything from engine and transmission controls to braking, steering, and even diagnostic data across various subsystems. This shift has pushed car designers to think about safety in a comprehensive way that includes system, hardware, and software design.
To ensure safety, the automotive industry uses ISO 26262 as its standard for functional safety in electronic systems that include both hardware and software. One challenge they often face is how to incorporate commercial off-the-shelf (COTS) software that might not have a verified safety history into a system that needs ISO 26262 approval.
ISO 26262 is made up of ten parts and covers all aspects of the safety lifecycle for electric and electronic automotive systems. The core sections, parts three to seven, concentrate on product development stages from concept and design to production.
The standard outlines objectives for each general requirement, like initiating product development at the software level. It also specifies inputs (such as a safety plan), activities (like planning for product development at the software level), and outputs (for instance, a software verification plan).
To be ISO 26262 compliant, all sections of the standard must be addressed according to the appropriate Automotive Safety Integrity Level (ASIL). The structure of ISO 26262 allows each major development phase—design, validation, and assessment—to be conducted independently. This means that once a hardware or software component is approved, the approval can be reused in different systems. Specifically, parts 8-12 and 8-13 detail the requirements for approving software and hardware components, respectively.
Part six of ISO 26262 is a core requirement process but does not cover supporting processes like functional safety management, configuration management, and change management. While it doesn’t prescribe any specific software development model (like agile or iterative), it’s often convenient to document requirements as though the software is designed in a waterfall model. The first step in developing ISO 26262 compliant software is to kick off a safety plan and a software verification plan, supported by other process plans defined in parts two and eight.
After these initial activities, the next step is specifying the software safety requirements, closely linked to the safety concept and overall system design. System and hardware limitations and requirements significantly influence software constraints and should be considered during this phase.
An ideal candidate for ISO 26262 approval would have a well-defined, transparent interface with any system or hardware design. This doesn’t mean every software component will fit any system or hardware, but that any limitations or conditions are clear to an integrator. For example, memory and CPU constraints would be specific requirements if necessary.
The outputs from this phase include a detailed software requirements specification, an enhanced hardware-software interface specification, and the results of software verification activities.
