AUTOSAR and ISO26262: A new approach to vehicle network design and automotive safety

Technology News | October 15, 2014

By eeNews Europe

Today’s safety standards enable closer technical collaboration across the automotive industry with the added benefit of reducing costs and development times, and the opportunity to limit miscommunication of technical specifications. This article looks at some of the detail of ISO26262 and AUTOSAR, and how they are supporting each other as automotive OEMs look to increase the use of embedded software components.

ISO26262 – what is it?

ISO 26262 is a derivative of the more generally applied IEC 61508 functional-safety standard for electrical and electronic systems for road vehicles. It addresses specifically automotive electronic and electrical safety-related systems, and is applicable throughout the design, development, and manufacturing cycle, as well as for relationships between automotive companies and their suppliers. ISO26262 is targeted at vehicles up to 3500Kg in weight, and seeks to minimize the potential hazards caused by malfunctioning or failure of the embedded electronic and electrical systems. The standard uses the concept of “ASIL” (Automotive Safety Integrity Level) to classify the safety requirements of each and every subsystem in the vehicle – these are graded from A (least critical) to D (most critical); it also defines a concept of “QM” (Quality Managed) for items that might not be safety relevant or have a very low potential for impacting overall system safety.

The automotive supply ecosystem is changing rapidly to adopt the concepts of ISO26262, and demonstration of compliance is increasingly being mandated by manufacturers in their RFQs (Request for Quotes). Proving compliance is not straight-forward and a collection of proof-point artefacts is typically produced and delivered with the supplied product to demonstrate that ISO26262 requirements have been addressed. The requirements specifically for software developers and software tool suppliers are specified in part 6 of the ISO26262 standard – often a software delivery will be “out of context” of the overall automotive system being proven. Components developed in isolation from their final destination system are allowed for in ISO26262 and are so called “Safety Elements out of Context” (SEooC).

For an embedded software developer, the ISO26262 requirement covers many different points in the product lifecycle, these include: requirements capture, coding, and development; test strategy design; test execution; system documentation; and assembling a set of documentation and evidence that can demonstrate that a repeatable and reliable process has been followed.

Safety concerns

The ASIL classification of in-vehicle components in turn defines how much effort must be put into ensuring safety and reliability. ASIL A requires less effort that ASIL D. If the car radio fails, it is annoying, so a Quality Management (QM) classification may be appropriate. If the steer-by-wire system fails, it could have catastrophic consequences, and failsafe operation is expected with built-in redundancy; this expectation ties into an ASIL D designation. For each safety-related item, the impact of failure is considered, along with the controllability of the system, and the probability of exposure of a failure to the driver during normal operation of the vehicle (note that even high probability events would be extremely rare; on the order of one failure per one million hours of operation). The degree to which each of these factors ties in with the ASIL classification is given in Table 1 below.

Table 1: ASIL classification and in-car examples.

The ASIL classification for a complete system may be broken down into individual hardware and software elements, and in practice there will be a mixture of ASIL classifications in any given system. In theory, an ECU’s entire software system must be developed to the highest ASIL level determined for any of the component elements – the chain is only as strong as its weakest link. This can overload the development effort significantly because even non-safety related software would need to be developed to the highest ASIL level. A technique called ASIL-decomposition offers a solution to this problem, such that individual software functions are developed in isolation to lower ASIL requirements, but additional functional redundancy is introduced so that an overall higher level of safety integrity is met.

Software development
Applying a safety mindset to the software development process means starting early in the cycle. Defining the failure modes and effects of the software should be approached in the same way as it would be for a hardware component. Each vehicle function and supporting software component definition needs to be traceable and linked back to a formal requirement specification, and have its own test plan, with defined expected results. Regression testing will typically be used to ensure that new features added do not break previously implemented and safety-approved functionality.

For safety-critical items, a failure-mode effects analysis will also be completed. In any production vehicle, software will come from many different sources including open source communities, third-party suppliers, as well as in-house developed software functions. Part of the validation plan will include the integration, test, and license compliance of all assembled components. It is typically the Tier 1 supplier who will take responsibility for this, but the obligations cascade through the supply chain of software and hardware organizations.

How far can the developer trust the development tools such as software compilers and automated test tools being used on the project? How are these tools certified to meet the requirements of ISO26262? ISO26262 uses the concept of an overall “Tool Confidence Level” (TCL) to rate the confidence factor in specific tools used, with TCL1 being high confidence in the tool, with lower levels of confidence for TCL2 and TCL3. A TCL1 tool can be used in the development of safety systems “as-is” while lower confidence tools require additional testing or augmentation depending on the ASIL level of the system being created, which must be provided either by the tool developer or the organization using the tool.

There are two main contributing components that determine the TCL – these are “Tool Impact” (TI) and “Tool Error Detection” (TD). The resulting Tool Confidence Level is determined from these two parameters.

The Tool Error Detection (TD) is graded from TD1 to TD3. TD1 means there is a high degree of confidence in the tool’s ability to detect a defect in the software function; whereas TD3 is used in cases where not all behaviour scenarios are investigated by the development and test tools, so error and bug detection is not guaranteed. In the case that the software compiler introduces a problem, there needs to be a high probability that this can later be detected to ensure a TCL1 rating. Table 2 shows the relationship between these parameters.

Table 2: Deriving Tool Confidence Level (TCL) from impact and error detection capabilities.

Software tool providers can also provide a wide range of additional artefacts to demonstrate conformance of their tools and processes to ISO26262. These can include:

A description of features, functions, and technical properties (intended purpose, inputs and expected outputs, environment and functional constraints)

A product user manual

Environment required for safe operation of the software tool

Description of expected behavior of tool under anomalous operating conditions (if applicable)

Description of known bugs, safeguards, workarounds

Information on how an incorrect tool output would be detected

How to review and analyze tool output

How to perform tests on the tool itself

Software tool providers can submit their products for validation and testing by approved independent industry bodies, who will cover a wide range of use cases and provide a formal report on reliability and suitability for the intended tool task. Tool suppliers can also present historical evidence, relating to proven reliable use in practice. In the case of very complex tools (such as compilers) there can sometimes be too many use cases to exhaustively test every option as part of an ISO26262 process, so proof of successful history becomes very important.

The impact of AUTOSAR on ISO26262

AUTOSAR provides a means for standardizing ECU interface definition and allows an engineer to make use of standardized, re-usable software layers and components that need to exist in every automotive ECU. It also provides a consistent repeatable ECU design methodology, which helps to support the requirements of ISO26262. The AUTOSAR standard is hardware independent, so a clear line is drawn between the application software and hardware platform that forms the ECU. The application developer can specify the details of individual vehicle functions in the application software without worrying about underlying software services and interfaces that are covered by AUTOSAR. In the past, software and hardware had been very tightly integrated hindering portability and re-use (Figure 1).

Figure 1: ECU with and without the AUTOSAR standardization layer.

If a large automotive enterprise is considering a move to AUTOSAR, this can be used as a catalyst for further change within the organization. Other changes needed to support ISO26262 can be introduced at the same time, such as a new tooling workflow, setting up new supply chains, and introducing safety concept reviews to assist with ISO26262 conformance. However the changes are implemented, adopting an AUTOSAR methodology requires learning and training time, as engineers become familiar with the new concepts. The cost savings and efficiency benefits will follow later, even on subsequent projects. The standardized AUTOSAR interface allows designers and developers to focus on producing differentiating functional behaviour while the standard software layers that need to exist in every ECU are called out in the AUTOSAR standard. These include the Operating System (OS), Basic Software Services (BSW), and the Run-Time Environment (RTE) which allow ECU software functions to be assembled into a single on-device executable binary.

Table 3: Benefits of an AUTOSAR methodology in support of ISO26262.

Typically, an AUTOSAR stack is developed by a third party as a collection of SEooC, allowing the enterprise to focus on the overall safety of their system while relying on the specification as well as the competence of the supplier to provide a stack appropriate for use in a certified system.

For some time to come, many vehicles will have mixed technology networks with some ECUs making use of AUTOSAR run-time ECUs, while other ECUs are based on legacy software and hardware. Gradually, AUTOSAR is being introduced in to more and more vehicles, and the associated, well-defined AUTOSAR methodology will help manufacturers and suppliers meet the requirements of ISO26262.

Conclusion

The impact of ISO26262 means that we can all expect to drive safer and more reliable vehicles, knowing that designers and developers have considered the impact of safety and reliability for the many electrical, electronic, and software components in a modern vehicle. Having repeatable and reliable processes in place which have open audit trails and traceability back to formal requirements are an essential part of current software development and test practices. Embedded software and tool providers such as Mentor Graphics will continue to support the industry efforts to adopt and make the most out of AUTOSAR and ISO26262 in the many years ahead.

About the author

Andrew Patterson is business development director for the Mentor Graphics Embedded Software Division, specializing in the automotive market. Prior to Mentor, Andrew spent over 25 years in the design automation market specializing in a wide range of technologies, automotive simulation model development, virtual prototyping, and mechatronics. Currently, he is focused on working on embedded software strategy at Mentor, working with Linux, AUTOSAR and other domains operating on a wide range of host silicon platforms. Andrew holds a masters degree in Engineering and Electrical Sciences from Cambridge University, UK.