Preparing for ISO 26262   By Chris Hills & Dr Gunter Gloee

Chris Hills, of Phaedrus Systems and member of MISRA-C and Guenter Gloee, of CAT Software Tools, have been looking at the draft of the new ISO standard for automotive systems.

 

A new standard – ISO/IEC 26262 DIS - Road Vehicles, Functional Safety is now out for discussion through the ISO and national standards’ bodies. While one expert in the field has suggested that formal ratification is a long way off (“not in my working life-time”) it is still a significant step forward for safety and any one who is working in systems for the automotive sector should be aware of the standard, its contents and the implications for system development and the product life-cycle.

So why do we need a standard? Nobody is knowingly going to build unsafe systems, are they? The argument is the same for the whole area of safety critical systems: a common standard should provide an agreed and objective measure on how safe a system will be in service. As part of this, a standard also provides a standard vocabulary to describe the elements of a system and their relationships.

 

 

Starting point

For electrical/electronic systems, the starting point is normally IEC 61508- Functional safety of electrical/electronic/programmable electronic safety-related systems. This, like all the standards in this area, is a multi-volume document, most parts of which were ratified in 1998. Within 61508 a key element is the concept of Safety Integrity Level (SIL). SILs range from SIL 1 (lowest) to SIL 4 (highest) and are indicators of Probability of Failure on Demand (PFD) with SIL1 being highest PFD (0.1 - 0.01) and SIL 4 lowest (.0001 – 0.00001) or, if you prefer, their inverse the Risk Reduction Factor where SIL 4 has the highest RRF (10,000 - 100,000) and SIL 1 the lowest.

Other sectors have developed their own standards based on 61508, for example the nuclear industry has 60880, 61513 and 62138 and the railway industry uses 50128. Now the automotive industry, including automotive manufacturers and national research centres from Austria, France, Germany, Italy, Japan, Sweden, the UK, and the USA, has created 26262.

Ten volumes make up the standard (Table 1), which is designed for “safety-related systems that include one or more E/E (electrical/electronic) systems and that are installed in series production passenger cars with a maximum gross weight up to 3.5t.” Since the standard is focused on series production cars, it includes, as part 7, requirements for the production of systems, something not found in 61508, which is aimed more at industrial equipment and process plant, which are normally one-off or very low numbers. Production is seen in the context of the automotive safety lifecycle (management, development, production, operation, service, decommissioning).

SILs

The standard has set up a different approach to SILs, using instead ASILs (Automotive Safety Integrity Levels.) To make the difference clear, ASILs run from A (lowest) to D (highest) and there is no one-to-one matching between 61508 SILs and 26262 ASILs. The approximate correspondence between SILs and ASILs is that ASIL A is approximately SIL 1, ASIL B is approximately SIL 2, ASIL C falls between SIL 2 and SIL 3 and ASIL D is approximately SIL 3. There is no equivalent in 26262 to SIL 4.

Development model
Parts 3 to 6 in the standard cover the development process, from concept (Part 3), through system level (Part 4), hardware development (Part 5) and software development (Part 6). The standard uses a V model for system development with hardware and software development also following their own V models. Table 2 shows the phases recommended for software development. For each phase of the development (Clause in the standard) there is a standard structure of Objectives, General, Inputs, Requirements and recommendations and Work Products (which normally form the inputs to the next phase). It is the Requirements and recommendations that are the core of the standard. An example is:

 

An example from Part 6 is: 5.4.8 The criteria to be considered when selecting a suitable 
         modelling or programming language are:

         a) an unambiguous definition;

         EXAMPLE Syntax and semantics of the language
         
         b) the support for embedded real time software and runtime error handling; and
         
         c) the support for modularity, abstraction and structured constructs.
         Criteria that are not sufficiently addressed by the language itself shall be covered 
          by the corresponding guidelines, or by the development environment.
         
         NOTE 1 The selected programming language (such as ADA, C, C++, Java, Assembler or a 
         graphical modelling language) is to fulfil the criteria given in 5.4.6. Usually 
         programming or modelling guidelines are necessary to fulfil these criteria.
         
         NOTE 2 Assembly languages can only be used for those parts of the software where the
         use of high-level programming languages is not appropriate. Examples are low-level 
         software with interfaces to the hardware, interrupt handlers and time-critical algorithms. 

 

It is interesting to note that graphical modelling is acceptable.

 

Matching ASILs

Within the Requirements and recommendations are tables that match requirements to the different ASILs, ranging from “highly recommended for this ASIL”, through “recommended for this ASIL” to “no recommendation for or against its usage for this ASIL.”

In Table 9 of part 6 — Design principles for software unit design and implementation, for example, “Initialisation of variables” is highly recommended for all ASILs. “Limited use of pointers” is highly recommended for ASIL D, while for ASIL C and ASIL B it is only “recommended” and for ASIL A there is no recommendation. Table 9 also has a NOTE “For the C language, [MISRA C] covers many of the methods listed in Table 9.” “A NOTE is only for guidance in understanding, or for clarification of, the associated requirement and shall not be interpreted as a requirement itself.”

Industry uptake

One important element in the likely industry uptake of 26262, apart from the already strong support of the automotive manufacturers, is that in parallel to the work on the standard has been the development of AUTOSAR (AUTomotive Open System ARchitecture) an open software architecture for automotive applications. The intention is that AUTOSAR will provide a common software infrastructure, with standard interfaces, to make the development of software and systems modular, scaleable, transferable and reuseable. AUTOSAR starts from Software Components, each carrying out a specific function. These go through an AUTOSAR interface to the AUTOSAR runtime environment, including OS, drivers etc, and run on the underlying hardware. This approach decouples the applications and their hardware, making it easier, for example, to transfer applications to different hardware or to upgrade applications.

AUTOSAR also presumes a development methodology, which can be easily mapped into the methodology that is defined within the 26262 standard.

Reading and commenting
If you want a copy of the draft standard, you can download it from the BSI web site; although a complete set will set you back £200.00 unless your organisation is already a BSI member. For help in getting to grips with how the standard will have an impact on how you will need to work in future, you should consider using RiskCAT 26262. This is the latest in the family of tools for quality management of embedded systems and software from CATS in Germany. The tools are designed to provide system developers with a straightforward way of matching project requirements to the requirements of published safety standards.

Like all RiskCAT products, RiskCAT 26262 has a graphical front end for an embedded database, allowing the built-in copy of the standard to be annotated, searched or filtered. The search and filtering uses logical combinations of keywords, process elements and functions to determine, in seconds, the relevant parts of the standard for a specific project. An example might be to find, say, those elements that are “highly recommended” for meeting a specific ASIL in ISO 26262.

RiskCAT 61508, for the base IEC 61508 safety standard, and versions for nuclear and railway industries have been in use for many years. One major company in the automotive industry has said of RiskCAT 61508, “This tool saves us ten days every time we use it.”

Whether through RiskCAT or from the bare standard, you have until the end of October to look at 26262 if you want to make your views known to the BSI

 

Table 1: 26262 structure
ISO 26262 has ten parts
ISO 26262-1: — Road vehicles – Functional Safety — Part 1: Vocabulary
ISO 26262-1: — Road vehicles – Functional Safety — Part 2: Management of functional safety
ISO 26262-3: — Road vehicles – Functional Safety — Part 3: Concept phase
ISO 26262-4: — Road vehicles – Functional Safety — Part 4: Product development: system level
ISO 26262-5: — Road vehicles – Functional Safety — Part 5: Product development: hardware level
ISO 26262-6: — Road vehicles – Functional Safety — Part 6: Product development: software level
ISO 26262-7: — Road vehicles – Functional Safety — Part 7: Production and operation
ISO 26262-8: — Road vehicles – Functional Safety — Part 8: Supporting processes
ISO 26262-9: — Road vehicles – Functional Safety — Part 9: ASIL-oriented and safety-oriented analyses
ISO 26262-10: — Road vehicles – Functional Safety — Part 10: Guideline on ISO 26262

 

Table 2: Product development – Software

Initiation of product development at the software level
Specification of software safety requirements
Software architectural design
Software unit design and implementation
Software unit testing
Software integration and testing
Verification of software safety requirements

 

Table 3: Structure of each clause
Objectives
General
Inputs to this clause
Requirements and recommendations
Work products

 

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988