BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY IN SYSTEMS

Automotive Systems

Compliance with ISO 26262 Causing Headaches? Here’s help.

The vast increase in the software content of automobiles along with stringent requirements for safety and reliability has added complexity to the process of development and compliance with standards. Any serious operation will require tools to track development and document compliance.

BY MARK RICHARDSON, LDRA

  • Page 1 of 1
    Bookmark and Share

Article Media

Software code is a major component of any car or truck in production today and when that code works, vehicles can parallel park themselves, automatically adjust speeds, and switch from electric to gas power in an instant. When code fails, however, tragedy can occur. In one recent example, faulty electronic throttle source code was blamed for causing unintended acceleration, leading to a wrongful death suit.

As a result of the injuries or deaths caused by these types of events and because of the cost of litigation, governments, automakers, and consumers are now placing a much greater emphasis on safety. Safety has become a significant factor in the development of automobile systems and, with the ever increasing use of E/E/PE systems in areas such as driver assistance, braking and steering systems and safety systems, this significance is set to increase.

Guidelines for Assessing Risk

The ISO 26262 standard provides detailed industry-specific guidelines for the production of all software for automotive systems and equipment, whether it is safety critical or not. It also provides a risk-management approach including the determination of risk classes, known as automotive safety integrity levels (ASILs) which are similar in nature to the safety integrity levels (SILs) specified in the IEC 61508 standard.

The four levels of ASILs (A-D in ISO 26262) specify the necessary safety measures for avoiding an unreasonable residual risk, with D representing the most stringent level. The ASIL is a property of a given safety function, not a property of the whole system or a system component. Each safety function in a safety-related system needs to have an appropriate ASIL assigned with the risk of each hazardous event evaluated based on the following attributes:

• Frequency of the situation (or “exposure”)

• Impact of possible damage (or “severity”)

• Controllability

The values that are determined for these three attributes, then in turn, determine the appropriate ASIL that is assigned for a given functional defect. This then determines the overall ASIL for that safety function.

ISO 26262 translates these safety levels into safety-specific objectives that must be satisfied during the development process. An assigned ASIL therefore determines the level of effort required to show compliance with the standard. So, the effort and expense of producing a system critical to the continued safe operation of an automobile (e.g., a steer-by-wire system) is necessarily higher than that required to produce a system with only a minor impact in the case of a failure (e.g., the in-car entertainment system).

Part 4 of ISO 26262 focuses on the product development at the system level and part 6 relates to the product development at the software level. A handy illustration from Wikipedia shows how the scope of these documents maps onto the familiar “V” model (Figure 1).

Figure 1
You can map the scope of the ISO 26262 part 4 and part 6 onto the familiar V development model.

Now that the risk is known, what steps are needed to demonstrate compliance to the ISO 26262 Functional Safety Standard? There’s an industry mantra that quickly sums up what’s needed:

• Say what you do

• Do what you say

• Show what you did (i.e., show that you met the objectives for the specific ASIL)

Say What You Do

In short, you must describe your processes in your plans. This requires the initial creation of a Software Project Plan (SPP), essentially a sub-plan of the Overall Project Plan (OPP), which addresses the software-related requirements of ISO 26262. The SPP needs to cover all the sub-clauses and activities defined to satisfy all the applicable sub-clause requirements. Any activities that are not required for all ASILs can be tailored out per ISO 26262-2. The SPP should include at least the following five sections:

1. Introduction

2. Software Description

3. Software Lifecycle

4. Other Considerations

5. Software Lifecycle Environment

Subsequently, each of these sub-sections has a series of steps that it must follow to achieve compliance and safe practice. Table 1 outlines the steps required and defines the expected content for each step. Figure 2 provides a snapshot of how the SPP looks when fleshed out.

Figure 2
Here’s an extract from an SPP Template specifying the design and coding guidelines.

Table 1
After creating a Software Project Plan, you need to detail each step per these components.

Clearly, proper process involves tracking a lot of details. Traditionally, companies managed these artifacts with Excel spreadsheets that they would update as work was completed. However, with the increased complexity of software development, such methodologies are prone to creating errors. Modern software tools can capture these requirements, add placeholders for the various artifacts that will need to be produced, and automatically update process status as code, tests, etc. are completed. For compliance, this process also automatically documents updates throughout the software development lifecycle, removing a significantly time-consuming step in the certification process.

Do What You Say

Once you’ve outlined your processes in the SPP, you need to follow them.  Both the SPP and OPP are approved by the relevant regulatory oversight body. It is important to collect and collate evidence that the processes were followed. Often, it can help to use software tools that provide process compliant templates for documents identified in the SPP.

Be aware that the SPP specifies that a “Design and coding guidelines” document is required. Any violations need to be corrected, but in case of undecidable rules (MISRA-C: 2012) or specific instances where a deviation from a non-mandatory rule is needed, then a justification needs to be added. 

In addition, as you’re implementing your plan, you always need to track that you’ve adjusted your processes to the risk levels associated with that piece of software. Table 2 outlines the risk levels and shows how effectively tools can help implement the necessary compliance checks:

Table 2
The complexity of software has made software test tools a necessity. Here you see the potential efficiency gains that can be made in gaining compliance for specific programming requirements.

Show What You Did

The third step: document what you did. In this step, you must ensure you can show consistent reviewed data, provide checklists for the required document content, and show impeccable record keeping for your document reviews. Tools, such as the LDRA tool suite, neatly dovetail with the LDRA Certification Management System, as a review and analysis management system that helps record review attendance, provide checklists for all SPP defined reviews and document process reviews (Figure 3). Tools that manage change control, track issues through resolution, and provide records of process compliance can save companies thousands of hours of documentation effort and up to 50 percent of their process costs.

Figure 3
The LDRA Certification Management System enables companies to organize their compliance process, providing compliance plans, process checklists, and problem reports to help you manage certification planning, development, verification, and regulatory activities.

A tools-based methodology can be used to cost-effectively manage an ISO 26262 compliant product development life cycle. The methodology must be based on a compliance management system that provides a roadmap to help manage the software planning, development, verification, and regulatory activities.

Using this roadmap, development teams can walk through the fully compliant plans, document checklists, transition and peer review checklists, standards and other required lifecycle documents, such as requirement specifications. When expanded to include deterministic software verification tools, the compliance management system can also streamline verification processes, further reducing hundreds of hours of documentation effort and achieve up to 50 percent reduction of planning costs.

LDRA
San Clemente, CA

(855) 855-5372
www.ldra.com