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

October 16, 2014 // By Andrew Patterson, Mentor Graphics
Today’s vehicles contain multiple complex electronic systems, which can cause serious harm if they fail, potentially with resulting lawsuits and much financial loss and brand damage to the manufacturer. Cross-industry safety standards have emerged and are gradually being implemented fully or in part. These standards affect the entire supply chain, and the implications specifically of ISO26262 and AUTOSAR are considered in this article.

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

Design category: