logo slogan

Getting to Grips with ISO DIS 26262
V19 i2 January 2010

 

Chris Hills, CTO, Phaedrus Systems


Introduction


While the new draft automotive safety standard, ISO DIS 26262 is still only at discussion stage, anyone who is developing systems for the automotive area needs to get to grip with the standard. And this is no light task. As David Ward’s excellent introduction to the standard (in Safety Systems, 19 (1) Sept 2009) pointed out, the standard comes in ten volumes, has over 350 pages and there are more than 550 requirements. It is not clear that anyone can carry this detail around in their head, let alone transmit it accurately to a development team.


The draft standard is already beginning to have an influence on the industry. Tools suppliers are announcing products that “Conform” and there is anecdotal evidence of companies looking for some form of compliance with 26262 from their suppliers.


Overview


ISO 26262 covers “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 IEC 61508, the normal base standard aimed more at industrial equipment and process plant produced as one-offs or in very low numbers. Production is seen in the context of the automotive safety lifecycle (management, development, production, operation, service, decommissioning).
The standard also has a different approach to SILs, using 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.


Requirements capture


In applying 26262 it is clearly vital to identify which of the 550 requirements are relevant. You can download the standard from the BSI web site, though a complete set will set you back £200.00 unless your organisation is already a BSI member. You then have to wade through and come to terms with it.


An alternative approach is to use 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. RiskCATs will also provide a calculation of the ASIL, using either Risk Graph or Probability methods.


Other features make life easier, for example, when working with the standard it is important to understand the terminology, and for any term defined in the standard clicking on the term retrieves the definition. Equally it is possible to select measures by key word, life cycle or function using or/and criteria and a simple click of the mouse pulls up the relevant part of the standard, with the measure highlighted.


The measures can be annotated, both directly within RiskCAT and by hyperlinks to project documentation. All selections can be output in rtf format (and can include the notes) to produce check lists.


RiskCAT can be used to explore different scenarios, providing greater understanding of the implications of different options when implementing a system. Each version can be saved, and can be returned to and revised, or rolled back.


Requirements Tracking


After identifying the requirements, it is also necessary to ensure that the system being developed complies with them. A Requirements Traceability Matrix is a simple and visible way of demonstrating that the requirements are satisfied in all the relevant parts of the design, source code and test documents is important. It achieves traceability and provides evidence for developers, safety auditors and customers that every requirement has been satisfied. But producing a Traceability Matrix for a set of detailed documents can be a tedious, laborious, error prone and time consuming job.


DocTrace is a tool which offers a simple and easy approach to tracing the relations between documents and their detailed contents. Using Trace Markers in the document(s) which are at the origin of the requirements and reference markers in documents that relate to them, DocTrace automates the production of a Requirements Traceability Matrix. This shows the traceability or coverage of requirements throughout the set of project documents. Project documents covered by DocTrace include requirement specifications, design specifications, program source code, test specifications and test reports.


DocTrace identifies inconsistencies or errors that may occur, such as missing references in design, test or code documents to requirements, combinations of document and trace markers that are repeated and trace markers that don’t have design, code or test cross-references.


Working together


Using RiskCAT to identify requirements and DocTrace to track that they are satisfied in the project can reduce project overhead significantly, leaving more time to concentrate on the implementation. Both tools are part of the special pricing offer that Phaedrus Systems is making to members of the SCSC.