Road Vehicles Functional Safety Part1: Glossary

Road Vehicles Functional Safety Part1: Glossary

ISOTC22/SC3Nxxx/BL10

(replaces N350/BL9)

Date:2007-11-30

ISO/WD26262-1

ISOTC22/SC3/WG16

Secretariat:DIN/FAKRA

Road vehicles— Functional safety— Part1: Glossary

Véhicules routiers— Sécurité fonctionnelle— Partie1: Glossaire

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

ISO/WD26262-1

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO's member body in the country of the requester:

[Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of the Copyright Manager of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the working document has been prepared.]

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

ContentsPage

Foreword......

Introduction......

1Scope......

2Normative references......

3Terms......

3.1„A“ Samples

3.2„B“ Samples

3.3„C“ Samples

3.4„D“ Samples

3.5Absolute frequency

3.6Acceptable risk......

3.7Acceptance test

3.8Alive counter

3.9Allocation

3.10Application software

3.11Approval

3.12Architectural metrics

3.13Architecture concept

3.14Assembly instructions

3.15Assessment

3.16Assessment of functional safety

3.17Audit

3.18Automatic test case generation

3.19Automotive-Safety-Integrity-Level (ASIL)

3.20ASIL decomposition

3.21Availability

3.22Averting danger

3.23Baseline

3.24Black-box test

3.25Bus guardian

3.26Calibration data

3.27Cascading failures

3.28Certification

3.29Change......

3.30Change during development

3.31Change during release

3.32Code-based development

3.33Code generator......

3.34Common cause failure (CCF)

3.35Common mode failures

3.36Compensation

3.37Complex of loads

3.38Component

3.39Component off the shelf/Commercial off the shelf (COTS)......

3.40Component parts qualification

3.41Computer-aided tools

3.42Configuration

3.43Configuration data

3.44Configuration item

3.45Configuration management......

3.46Confirmation measures......

3.47Constraint

3.48Control of faults

3.49Control plan

3.50Controllability

3.51Controlled dangerous hardware failure

3.52Controlled fault

3.53Criteria for test completion

3.54Criteria for test termination

3.55Critical failure

3.56Critical failure coverage

3.57Critical hardware failure

3.58Criticality

3.59Criticality analysis

3.60Cumulated operating time......

3.61Danger......

3.62Defective......

3.63Degradation

3.64Degraded operating state

3.65Dependent failures

3.66Derivative

3.67Derived safety requirements

3.68Software Design phases

3.69Detected potentially dangerous hardware failure indicated to the driver

3.70Detection time span for latent faults

3.71Development interface agreement (DIA)......

3.72Diagnostic coverage

3.73Disengageable, directly

3.74Disengageable, not directly

3.75Disjunctive situation

3.76Display concept

3.77Distributed development......

3.78Diverse redundancy......

3.79Diversity......

3.80Driving situation

3.81Dual point failure

3.82Dual point fault

3.83E/E system

3.84E/E system architecture

3.85Electronic components......

3.86Element......

3.87Embedded software

3.88Emergency operation

3.89Emergency operation time

3.90Environmental conditions

3.91Error......

3.92Evaluation

3.93Event tree analysis (ETA)

3.94Executable code

3.95Exposure situation

3.96External failure

3.97External measure

3.98External risk reduction facilities

3.99Fail safe

3.100Failure

3.101Failure mode

3.102Failure mode and effects analysis (FMEA)

3.103Failure rate or  rate

3.104Fault

3.105Fault/Error detection

3.106Fault tolerance

3.107Fault tolerant time span

3.108Fault tree analysis (FTA)

3.109Field monitoring......

3.110First sample

3.111Formal notation

3.112Formal verification

3.113Freedom from of interference

3.114Freedom from of interference of software

3.115Frequency

3.116Function......

3.117Functional architecture

3.118Functional concept......

3.119Functional requirement

3.120Functional safety

3.121Functional safety concept

3.122Functional safety requirement

3.123Functional test

3.124Hardware component......

3.125Hardware development

3.126Hardware failure......

3.127Hardware-in-the-loop test (HiL)

3.128Hardware part

3.129Hardware safety requirements

3.130Hardware-software interface (HSI)

3.131Harm

3.132Hazard

3.133Hazard analysis

3.134Hazard analysis and risk assessment

3.135Hazardous event

3.136Impact anaylsis

3.137Independence

3.138Independent department

3.139Independent failures

3.140Independent person

3.141Informal notation

3.142Informal verification

3.143Inheritance

3.144Initial ASIL......

3.145Initial situation......

3.146Inspection......

3.147Internal failure

3.148Item

3.149Item definition

3.150Latent critical failure

3.151Latent failure

3.152Latent fault

3.153Latent failure prevention mechanism

3.154Latent fault prevention mechanism

3.155Latent potentially dangerous hardware failure

3.156Latest ASIL

3.157Level of independence

3.158Lifecycle......

3.159Lifetime......

3.160Main function

3.161Maturity of development subject

3.162Mechanism, detection/control

3.163Mechatronic system

3.164Memory corruption

3.165Model-based software development

3.166Model-based testing

3.167Model-in-the-loop test (MiL)

3.168Modification = change of an item in use

3.169Monitoring

3.170Monitoring coverage (MC)

3.171Multiple failure

3.172Multiple point failure

3.173Multiple point fault

3.174New development

3.175Non-functional hazards......

3.176Operating mode

3.177Operating situation

3.178Operating system

3.179Part

3.180Partial release......

3.181Partitioning

3.182Perceived fault

3.183Plain item

3.184Potentially dangerous hardware failure

3.185Preliminary hazard analysis

3.186Primary component

3.187Probability of dangerous failure

3.188Probability of exposure

3.189Process

3.190Process requirements

3.191Processor-in-the-loop test (PiL)

3.192Product development

3.193Product labelling

3.194Product release......

3.195Product release report

3.196Production monitoring

3.197Production plan

3.198Production resources

3.199Project

3.200Project plan

3.201Proven in use credit

3.202Random hardware failure

3.203Random hardware fault

3.204Redundancy

3.205Redundancy concept......

3.206Reference system......

3.207Regression strategy

3.208Regression testing......

3.209Relative frequency

3.210Reliability......

3.211Remaining risk

3.212Request for quotation (RFQ)

3.213Requirement

3.214Residual fault

3.215Residual risk......

3.216Review

3.217Risk

3.218Risk analysis

3.219Risk assessment

3.220Risk evaluation

3.221Risk limit

3.222Role......

3.223Safe failure

3.224Safe fault

3.225Safe hardware failure

3.226Safe state

3.227Safety......

3.228Safety architecture

3.229Safety architectural metrics

3.230Safety assessor

3.231Safety audit

3.232Safety barrier

3.233Safety case

3.234Safety culture

3.235Safety goal

3.236Safety integrity

3.237Safety integrity level

3.238Safety measure

3.239Safety mechanism

3.240Safety plan

3.241Safety-related

3.242Safety-related characteristic

3.243Safety-related component

3.244Safety-related data

3.245Safety-related element

3.246Safety-related function/system

3.247Safety-related hardware

3.248Safety-related software

3.249Safety-related special characteristic

3.250Safety requirement

3.251Safety review

3.252Safety validation......

3.253Sample

3.254Semaphore

3.255Semi-formal notation

3.256Semi-formal verification

3.257Service history data......

3.258Service life

3.259Service notes (maintenance and repair)

3.260Severity

3.261Single fault

3.262Single point failure

3.263Single point fault

3.264Software

3.265Software architecture

3.266Software build

3.267Software component

3.268Software configuration

3.269Software development

3.270Software function......

3.271Software-in-the-loop test (SiL)

3.272Software item

3.273Software library

3.274Software partition

3.275Software partitioning

3.276Software-related hardware resource

3.277Software-related system resource

3.278Software resources

3.279Software safety acceptance test

3.280Software tool

3.281Software unit

3.282Specification

3.283Staff

3.284Standard component

3.285Supplier

3.286Switch-off

3.287System......

3.288System design

3.289System development

3.290System-FMEA

3.291System function

3.292System specification

3.293Systematic failure

3.294Systematic hardware failure

3.295Target parameter

3.296Task

3.297Technical safety concept

3.298Technical safety requirement

3.299Test criterions

3.300Test/inspection devices

3.301Software Test phases

3.302Testing

3.303Testing notes

3.304Time to repair

3.305Timely reaction

3.306Tolerable risk

3.307Tool

3.308Traceability

3.309Traceable

3.310Validation......

3.311Validation goal

3.312Validation level

3.313Validation plan

3.314Variant

3.315Vehicle

3.316Vehicle configuration......

3.317Vehicle manufacturer

3.318Vehicle testing

3.319Verifiability

3.320Verification

3.321Verification during design

3.322Verification during test

3.323Verification plan

3.324Walkthrough

3.325Warning and degradation concept

3.326White-Box-Test

3.327Work product

4Abbreviations......

List of figuresPage

Figure0.1— Overview of ISO WD 26262-1 to -9

List of tablesPage

Table 4.1°– Abbreviations

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IECDirectives, Part2.

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75% of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO262621 was prepared by Technical Committee ISO/TC22, Road vehicles, Subcommittee SC3, Electrical and electronic equipment.

ISO26262 consists of the following parts, under the general title Road vehicles— Functional safety:

Part1: Glossary

Part 2: Management of functional safety

Part 3: Concept phase

Part 4: Product development: system level

Part 5: Product development: hardware level

Part 6: Product development: software level

Part 7: Production and operation

Part 8: Supporting processes

Part 9: ASIL- and safety-oriented analyses

Normative paragraphs are part of the normative content.

Informative paragraphs are for information only.

Introduction

This International Standard ISO WD°26262 is the adaptation of IEC°61508 to meet needs specific to the application sector of E/E systems within road vehicles.

This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software elements that provide safety-related functions.

Safety turns out to be one of the key issues of future automobile development. New functionality in the area of driver assistance but also in vehicle dynamics control and active and passive safety systems increasingly touches the domain of safety engineering. Future development and integration of these functionalities will even strengthen the need of safe system development processes and the possibility to show evidence that all reasonable safety objectives are met.

With the trend of increasing complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and E/E random hardware failures. This International Standard includes guidance to avoid these risks by feasible processes.

System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (for example: mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic etc).While this International Standard is concerned with E/E safety-related systems, it may also provide a framework within which safety-related systems based on other technologies may be considered.

This International Standard:

-Provides an automotive safety lifecycle (engineering, production, operation, maintenance, decommissioning) and supports tailoring the necessary activities during these lifecycle phases according to the E/E system's development category (new development, derivate, modification, reuse);

-Provides an automotive specific risk-based approach for determining risk classes (Automotive safety integrity levels, ASIL);

-Uses automotive safety integrity levels (ASIL) for specifying the item's necessary safety requirements for achieving an acceptable residual risk;

-Provides requirements for confirmation measures to ensure a sufficient and acceptable level of safety is achieved.

Functional safety is influenced by the engineering process (including such activities as requirements specification, design, implementation, configuration, verification, integration, and validation), the production and maintenance processes, as well as the management processes and human resources and responsibilities.

Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. This International Standardaddresses the safety-related issues of the development activities.

Figure 0.1 shows the overall structure of this International Standard.

The shaded "V"s represent the relations between parts 3, 4, 5, 6 and 7. This International Standard is based upon a V-Model as a reference process model for the different phases of system, hardware and software development.

©ISO2007– All rights reserved / 1

ISO/WD26262-1

Figure0.1— Overview of ISO WD 26262-1 to -9

©ISO2007– All rights reserved / 1

ISO/WD26262-1

Road vehicles— Functional safety— Part1: Glossary

1Scope

This International Standard is applicable to safety-related systems, which include one or more E/E systems, and which are installed in road vehicles in the classes M, N, and O[1]), but not in vehicles for drivers with disabilities.

This International Standard addresses possible hazards caused by mal-functional behaviour of E/E safety-related systems. This International Standard does not address such hazards as electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy, and such other hazards not resulting from the primary functions of road vehicles. This International Standard does also not address the nominal performance level of E/E systems, even if dedicated functional performance standards exist (for example active and passive safety systems, brake systems, ACC, etc).

Additional requirements for vehicles for the transport of hazardous goods are not covered by this International Standard[2]).

This part of the International Standard specifies the glossary.

2Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 3779Road vehicles – Vehicle identification number (VIN)

ISO 3833Road vehicles – Types – Terms and definitions

ISOWD26262 (all parts), Road vehicles – Functional safety

70/156/EG,Richtlinie des Rates vom 6. Februar 1970 zur Angleichung der Rechtsvorschriften der Mitgliedstaaten über die Betriebserlaubnis für Kraftfahrzeuge und Kraftfahrzeuganhänger

3Terms

For the application of all parts of this International Standard the following terms are valid:

Legend:

Term: term from one of the Parts of BL10

Definition: definition from one of the Parts of BL10

Term/Definition: term/definition proposed to be deleted (term/definition not included in BL10 any more)

Term: please check if this term is necessary, otherwise to be deleted

Definition: two or more definitions for one term; the deviation is marked red

Definition: definition from before BL10

Term: definition missing or to be reworked

Term: re-introduce this definition although not included in BL10 and delete similar definition although included in BL10 (e.g. traceability – traceable)

3.1„A“ Samples

Functional models with limited suitability for driving with constraints regarding temperature and voltage, dimensions etc. Basic functions are implemented according to requirements specification and can be tested in the testbed under test conditions. The reliability of parts is dimensioned for test operation guaranteeing technical functions. There is no requirement demanding the existence of safety functions.

3.2„B“ Samples

Samples with suitability for driving guaranteeing sufficient operational safety for first trials in the testbed an in the vehicle. The reliability of parts is dimensioned for driving operation on a test area. Safety functions are completely implemented.

3.3„C“ Samples

Electronic control unit built by production tools with constraints close-to-production. All requirements forfunction, reliability and interference resistance shall be complied with. No technical constraints are allowed for C samples and use without restrictions in the vehicle is guaranteed. The reliability of parts is dimensioned for driving operation on the road.

3.4„D“ Samples

Electronic control unit built by production tools with production constraints. The electronic control units are completely applicable.

NOTED samples become production parts through quality release.

3.5Absolute frequency

Number of values observed being equal to a predefined value or belonging to a set of predefined values.

3.6Acceptable risk

Risk accepted in a certain context according to valid societal moral concepts.

3.7Acceptance test

Test conducted in an operational environment to determine whether a system satisfies its acceptance criteria (i.e. initial requirements and current needs of its users) and to enable the customer to determine whether to accept the system

NOTEThis includes requirements formulated implicitly as well as explicitly

3.8Alive counter

WD 26262-6: Counting component initialised with 0 when the object to be monitored is created. The counter increases from time t-1 to time t as long as the object is alive. Finally, the alive counter shows the period of time for which the object has been alive within a network.

WD 26262-6/BL10: Counting component initialised with 0 when the object to be monitored is created. The counter increases from time t-1 to time t as long as the object is alive. Finally, the alive counter shows the period of time for which the object has been alive within a network

3.9Allocation

WD 26262-3: Process of assigning requirements to architectural elements.

WD 26262-3/BL10, WD 26262-9/BL10:Process of assigning requirements to architectural elements

3.10Application software

Software realising defined functionalities of a set of features and adapted for a specific vehicle use.

3.11Approval

Tbd.

3.12Architectural metrics

Metrics for the assessment of the efficiency of the architecture concerning safety

3.13Architecture concept

Specifies the basic components and their interaction necessary for fulfilling the functional requirement and safety requirement as architecture requirements. The architecture concept is developed during concept phase.

3.14Assembly instructions

Documentation describing the installation of components or parts and the safety-related items that can be affected during installation.

WD 26262-4/BL10:Documentation of the safety-related parts or functions that can be affected during installation

WD 26262-7/BL10:documentation describing the installation of components or parts. In this part the focus is on safety-related items that can be affected during installation

3.15Assessment

WD 26262-2: Independent check of product characteristics.

WD 26262-2/BL10: Independent examination of product characteristics

3.16Assessment of functional safety

Investigation, based on evidence, to judge the functional safety achieved by one or more E/E safety-related systems, other technology safety-related systems or external risk reduction facilities

To be discussed:

Check based on proof for evaluating functional safety which is achieved by one or more E/E systems, safety-related systems of different technologies or external facilities for risk reduction.

3.17Audit

An independent examination of the safety life cycle processes and their outputs to confirm required attributes.

WD 26262-2/BL10: Examination of process implementation

3.18Automatic test case generation

WD 26262-4: The tool-driven creation of test cases during the preparation of testing.

WD 26262-4/BL10:The tool-driven creation of test cases during the preparation of testing

3.19Automotive-Safety-Integrity-Level (ASIL)

WD 26262-3 (8th ISO): One of four classes to specify the item's necessary safety requirements for achieving an acceptable residual risk with D representing the highest and A the lowest class.

NOTEThe main difference between ASIL of ISO WD 26262 and SIL of IEC 61508 is that the ASIL does not represent a probabilistic target value of the item [IEC 61508-4, definitions 3.5.6, 3.5.2, IEC 61508-1, tables 2 and 3].

WD 26262-3/BL10: One of four classes to specify the item's necessary safety requirements for achieving an acceptable residual risk with D representing the highest and A the lowestclass

NOTEThe main difference between ASIL of ISO WD 26262 and SIL of IEC 61508is that the ASIL does not represent a probabilistic target value of the item[IEC 61508-4, definitions 3.5.6, 3.5.2, IEC 61508-1, tables 2 and 3].

3.20ASIL decomposition

When a functional safety requirement is to be satisfied through a combination of derived functional safety requirements, including redundancy, the allocation of the ASIL from the higher level requirement or goal to the derived requirements is called ASIL decomposition

WD 26262-3/BL10, WD 26262-9/BL10: Part of the design process in order to duplicate and allocate requirements including their ASILs among redundant sub-systems/system elements/components

3.21Availability

Capability of a product to be in a state, to execute the function required under given conditions at a certain time or in a given period, supposing the required external resources are available.

3.22Averting danger

Possible actions to avert danger or to control a hazard.

3.23Baseline

WD 26262-8: Formally released version of a configuration, which is used as a basis for further development and marks a certain state of work which itself may not be changed any more.

WD 26262-8/BL10, WD 26262-9/BL10: Formally released version of a configuration, which is used as a basis for further development and marks a certain state of work which itself may not be changed any more

3.24Black-box test

Black-box testing means checking that the outputs of a unit to be tested, given certain inputs, comply with the functional specification of the unit. There, the term black box indicates that the internal implementation of the unit being executed is not examined by the tester.

WD 26262-6/BL10: Tests of a test object that do not require knowledge of its internal structure or its implementation

3.25Bus guardian

WD 26262-6: Independent component between a node and the bus that allows its node to transmit on the bus only when it is allowed to do so.

NOTEThe guardian must know when its node is allowed to access the bus, which is difficult to achieve in an event-triggered system but is conceptually simple in a time triggered system.

WD 26262-6/BL10: Independent component between a node and the bus that allows its node to transmit on the bus only when it is allowed to do so