ISO TC 22/SC 3 N - University of Leeds
WORKING DRAFT© ISO 2007 – All rights reservedISO/WD 26262-1 63Part 1: GlossaryRoad vehicles — Functional safetyVéhicules routiers — Sécurité fonctionnelle — Partie 1: GlossaireRoad vehicles — Functional safety — Part 1: GlossaryE2007-11-30(20) PreparatoryISOISO International Standard2007xxx/BL10ISO 26262ISO 26262-1ISO/WD 26262-1 DIN/FAKRAElectrical and electronic equipmentRoad vehicles16322 2Überschrift 2;h2;2Überschrift 1;Anlagenüberschrift1 + Before: 0 pt;Anlagenüberschrift1;h1;Heading 1 - nonum;Titre 1 Car; Car Car 0 CR10STD Version 2.210 4P:\EG-3-Proj\FuSi\3_FuSi_Partner\4_Standardisierung\ISO\TC22-SC3-WG16\WD 26262\19 Baseline 10\N350-03_WD_26262-1_First_Draft_basis_for_BL10.doc ISO TC 22/SC 3 N xxx/BL10
(replaces N350/BL9)
Date: 2007-11-30
ISO/WD 26262-1
ISO TC 22/SC 3/WG 16
Secretariat: DIN/FAKRA
Road vehicles — Functional safety — Part 1: Glossary
Véhicules routiers — Sécurité fonctionnelle — Partie 1: 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.
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.
Contents Page
Foreword xi
Introduction xiii
1 Scope 1
2 Normative references 1
3 Terms 2
3.1 „A“ Samples 2
3.2 „B“ Samples 2
3.3 „C“ Samples 2
3.4 „D“ Samples 2
3.5 Absolute frequency 2
3.6 Acceptable risk 3
3.7 Acceptance test 3
3.8 Alive counter 3
3.9 Allocation 3
3.10 Application software 3
3.11 Approval 3
3.12 Architectural metrics 3
3.13 Architecture concept 3
3.14 Assembly instructions 3
3.15 Assessment 4
3.16 Assessment of functional safety 4
3.17 Audit 4
3.18 Automatic test case generation 4
3.19 Automotive-Safety-Integrity-Level (ASIL) 4
3.20 ASIL decomposition 4
3.21 Availability 5
3.22 Averting danger 5
3.23 Baseline 5
3.24 Black-box test 5
3.25 Bus guardian 5
3.26 Calibration data 5
3.27 Cascading failures 6
3.28 Certification 6
3.29 Change 6
3.30 Change during development 6
3.31 Change during release 6
3.32 Code-based development 6
3.33 Code generator 7
3.34 Common cause failure (CCF) 7
3.35 Common mode failures 7
3.36 Compensation 7
3.37 Complex of loads 8
3.38 Component 8
3.39 Component off the shelf/Commercial off the shelf (COTS) 8
3.40 Component parts qualification 8
3.41 Computer-aided tools 8
3.42 Configuration 8
3.43 Configuration data 8
3.44 Configuration item 9
3.45 Configuration management 9
3.46 Confirmation measures 9
3.47 Constraint 9
3.48 Control of faults 9
3.49 Control plan 9
3.50 Controllability 10
3.51 Controlled dangerous hardware failure 10
3.52 Controlled fault 10
3.53 Criteria for test completion 10
3.54 Criteria for test termination 10
3.55 Critical failure 10
3.56 Critical failure coverage 10
3.57 Critical hardware failure 10
3.58 Criticality 10
3.59 Criticality analysis 11
3.60 Cumulated operating time 11
3.61 Danger 11
3.62 Defective 11
3.63 Degradation 11
3.64 Degraded operating state 11
3.65 Dependent failures 11
3.66 Derivative 12
3.67 Derived safety requirements 12
3.68 Software Design phases 12
3.69 Detected potentially dangerous hardware failure indicated to the driver 12
3.70 Detection time span for latent faults 12
3.71 Development interface agreement (DIA) 13
3.72 Diagnostic coverage 13
3.73 Disengageable, directly 14
3.74 Disengageable, not directly 14
3.75 Disjunctive situation 14
3.76 Display concept 14
3.77 Distributed development 14
3.78 Diverse redundancy 15
3.79 Diversity 15
3.80 Driving situation 15
3.81 Dual point failure 15
3.82 Dual point fault 15
3.83 E/E system 15
3.84 E/E system architecture 15
3.85 Electronic components 15
3.86 Element 16
3.87 Embedded software 16
3.88 Emergency operation 16
3.89 Emergency operation time 16
3.90 Environmental conditions 16
3.91 Error 16
3.92 Evaluation 16
3.93 Event tree analysis (ETA) 16
3.94 Executable code 17
3.95 Exposure situation 17
3.96 External failure 17
3.97 External measure 17
3.98 External risk reduction facilities 17
3.99 Fail safe 17
3.100 Failure 17
3.101 Failure mode 17
3.102 Failure mode and effects analysis (FMEA) 18
3.103 Failure rate or ( rate 18
3.104 Fault 19
3.105 Fault/Error detection 19
3.106 Fault tolerance 19
3.107 Fault tolerant time span 20
3.108 Fault tree analysis (FTA) 20
3.109 Field monitoring 20
3.110 First sample 20
3.111 Formal notation 20
3.112 Formal verification 20
3.113 Freedom from of interference 21
3.114 Freedom from of interference of software 21
3.115 Frequency 21
3.116 Function 21
3.117 Functional architecture 21
3.118 Functional concept 22
3.119 Functional requirement 22
3.120 Functional safety 22
3.121 Functional safety concept 22
3.122 Functional safety requirement 22
3.123 Functional test 23
3.124 Hardware component 23
3.125 Hardware development 23
3.126 Hardware failure 23
3.127 Hardware-in-the-loop test (HiL) 23
3.128 Hardware part 23
3.129 Hardware safety requirements 23
3.130 Hardware-software interface (HSI) 24
3.131 Harm 24
3.132 Hazard 24
3.133 Hazard analysis 24
3.134 Hazard analysis and risk assessment 24
3.135 Hazardous event 24
3.136 Impact anaylsis 25
3.137 Independence 25
3.138 Independent department 25
3.139 Independent failures 25
3.140 Independent person 25
3.141 Informal notation 25
3.142 Informal verification 26
3.143 Inheritance 26
3.144 Initial ASIL 26
3.145 Initial situation 26
3.146 Inspection 26
3.147 Internal failure 27
3.148 Item 27
3.149 Item definition 27
3.150 Latent critical failure 27
3.151 Latent failure 27
3.152 Latent fault 27
3.153 Latent failure prevention mechanism 27
3.154 Latent fault prevention mechanism 27
3.155 Latent potentially dangerous hardware failure 28
3.156 Latest ASIL 28
3.157 Level of independence 28
3.158 Lifecycle 28
3.159 Lifetime 28
3.160 Main function 28
3.161 Maturity of development subject 28
3.162 Mechanism, detection/control 28
3.163 Mechatronic system 28
3.164 Memory corruption 28
3.165 Model-based software development 29
3.166 Model-based testing 29
3.167 Model-in-the-loop test (MiL) 29
3.168 Modification = change of an item in use 29
3.169 Monitoring 29
3.170 Monitoring coverage (MC) 29
3.171 Multiple failure 30
3.172 Multiple point failure 30
3.173 Multiple point fault 30
3.174 New development 30
3.175 Non-functional hazards 30
3.176 Operating mode 30
3.177 Operating situation 31
3.178 Operating system 31
3.179 Part 31
3.180 Partial release 31
3.181 Partitioning 31
3.182 Perceived fault 31
3.183 Plain item 32
3.184 Potentially dangerous hardware failure 32
3.185 Preliminary hazard analysis 32
3.186 Primary component 32
3.187 Probability of dangerous failure 32
3.188 Probability of exposure 32
3.189 Process 32
3.190 Process requirements 33
3.191 Processor-in-the-loop test (PiL) 33
3.192 Product development 33
3.193 Product labelling 33
3.194 Product release 33
3.195 Product release report 33
3.196 Production monitoring 33
3.197 Production plan 34
3.198 Production resources 34
3.199 Project 34
3.200 Project plan 34
3.201 Proven in use credit 35
3.202 Random hardware failure 35
3.203 Random hardware fault 35
3.204 Redundancy 35
3.205 Redundancy concept 35
3.206 Reference system 35
3.207 Regression strategy 36
3.208 Regression testing 36
3.209 Relative frequency 36
3.210 Reliability 36
3.211 Remaining risk 36
3.212 Request for quotation (RFQ) 36
3.213 Requirement 36
3.214 Residual fault 36
3.215 Residual risk 36
3.216 Review 36
3.217 Risk 37
3.218 Risk analysis 37
3.219 Risk assessment 37
3.220 Risk evaluation 37
3.221 Risk limit 37
3.222 Role 37
3.223 Safe failure 37
3.224 Safe fault 37
3.225 Safe hardware failure 37
3.226 Safe state 38
3.227 Safety 38
3.228 Safety architecture 38
3.229 Safety architectural metrics 38
3.230 Safety assessor 38
3.231 Safety audit 38
3.232 Safety barrier 38
3.233 Safety case 38
3.234 Safety culture 39
3.235 Safety goal 39
3.236 Safety integrity 39
3.237 Safety integrity level 39
3.238 Safety measure 39
3.239 Safety mechanism 39
3.240 Safety plan 40
3.241 Safety-related 41
3.242 Safety-related characteristic 41
3.243 Safety-related component 41
3.244 Safety-related data 41
3.245 Safety-related element 41
3.246 Safety-related function/system 41
3.247 Safety-related hardware 41
3.248 Safety-related software 41
3.249 Safety-related special characteristic 41
3.250 Safety requirement 42
3.251 Safety review 42
3.252 Safety validation 42
3.253 Sample 42
3.254 Semaphore 42
3.255 Semi-formal notation 42
3.256 Semi-formal verification 42
3.257 Service history data 43
3.258 Service life 43
3.259 Service notes (maintenance and repair) 43
3.260 Severity 43
3.261 Single fault 43
3.262 Single point failure 43
3.263 Single point fault 43
3.264 Software 43
3.265 Software architecture 44
3.266 Software build 44
3.267 Software component 44
3.268 Software configuration 44
3.269 Software development 44
3.270 Software function 44
3.271 Software-in-the-loop test (SiL) 45
3.272 Software item 45
3.273 Software library 45
3.274 Software partition 45
3.275 Software partitioning 46
3.276 Software-related hardware resource 46
3.277 Software-related system resource 46
3.278 Software resources 46
3.279 Software safety acceptance test 46
3.280 Software tool 47
3.281 Software unit 47
3.282 Specification 47
3.283 Staff 48
3.284 Standard component 48
3.285 Supplier 48
3.286 Switch-off 48
3.287 System 48
3.288 System design 48
3.289 System development 48
3.290 System-FMEA 49
3.291 System function 49
3.292 System specification 49
3.293 Systematic failure 49
3.294 Systematic hardware failure 49
3.295 Target parameter 49
3.296 Task 49
3.297 Technical safety concept 50
3.298 Technical safety requirement 50
3.299 Test criterions 50
3.300 Test/inspection devices 50
3.301 Software Test phases 50
3.302 Testing 51
3.303 Testing notes 51
3.304 Time to repair 51
3.305 Timely reaction 51
3.306 Tolerable risk 51
3.307 Tool 51
3.308 Traceability 51
3.309 Traceable 51
3.310 Validation 52
3.311 Validation goal 52
3.312 Validation level 52
3.313 Validation plan 52
3.314 Variant 52
3.315 Vehicle 52
3.316 Vehicle configuration 52
3.317 Vehicle manufacturer 52
3.318 Vehicle testing 53
3.319 Verifiability 53
3.320 Verification 53
3.321 Verification during design 53
3.322 Verification during test 53
3.323 Verification plan 53
3.324 Walkthrough 54
3.325 Warning and degradation concept 54
3.326 White-Box-Test 54
3.327 Work product 54
4 Abbreviations 54
List of figures Page
Figure 0.1 — Overview of ISO WD 26262-1 to -9 xiv
List of tables Page
Table 4.1°– Abbreviations 58
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/IEC Directives, Part 2.
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.
ISO 26262-1 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment.
ISO 26262 consists of the following parts, under the general title Road vehicles — Functional safety:
← Part 1: 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 Standard addresses 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.
[pic]
Figure 0.10>= 1 "A." — Overview of ISO WD 26262-1 to -9
Road vehicles — Functional safety — Part 1: Glossary
Scope
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.
Normative 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 3779 Road vehicles – Vehicle identification number (VIN)
ISO 3833 Road vehicles – Types – Terms and definitions
ISO WD26262 (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
Terms
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)
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.
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 „C“ Samples
Electronic control unit built by production tools with constraints close-to-production. All requirements for function, 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.
4 „D“ Samples
Electronic control unit built by production tools with production constraints. The electronic control units are completely applicable.
NOTE D samples become production parts through quality release.
5 Absolute frequency
Number of values observed being equal to a predefined value or belonging to a set of predefined values.
6 Acceptable risk
Risk accepted in a certain context according to valid societal moral concepts.
7 Acceptance 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
NOTE This includes requirements formulated implicitly as well as explicitly
8 Alive 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
9 Allocation
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
10 Application software
Software realising defined functionalities of a set of features and adapted for a specific vehicle use.
11 Approval
Tbd.
12 Architectural metrics
Metrics for the assessment of the efficiency of the architecture concerning safety
13 Architecture 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.
14 Assembly 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
15 Assessment
WD 26262-2: Independent check of product characteristics.
WD 26262-2/BL10: Independent examination of product characteristics
16 Assessment 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.
17 Audit
An independent examination of the safety life cycle processes and their outputs to confirm required attributes.
WD 26262-2/BL10: Examination of process implementation
18 Automatic 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
19 Automotive-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.
NOTE The 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 lowest class
NOTE The 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].
20 ASIL 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
21 Availability
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.
22 Averting danger
Possible actions to avert danger or to control a hazard.
23 Baseline
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
24 Black-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
25 Bus 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.
NOTE The 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
NOTE The 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.
26 Calibration data
WD 26262-6: Data which will be resolved after the software build in the development process or at runtime (operation). Calibration data shall not contain executable or interpretable code.
Calibration data includes:
Parameters: value for low idle speed, engine characteristic diagrams;
Vehicle specific parameter (adaption values): e.g. limit stop for throttle valve;
Variant coding: country code, left- hand / right-hand steering.
WD 26262-6/BL10: Data which will be resolved after the software build in the development process or at runtime (operation). Calibration data shall not contain executable or interpretable code.
Calibration data includes:
← Parameters: value for low idle speed, engine characteristic diagrams;
← Vehicle specific parameter (adaption values): e.g. limit stop for throttle valve;
← Variant coding: country code, left- hand / right-hand steering
27 Cascading failures
Failure of an item or component that causes other item(s) or component(s) to fail. Cascading failures are dependent failures that are not common cause failures.
WD 26262-5/BL10, WD 26262-9/BL10: Failure of an element of an item causing other element(s) of that item to fail. Cascading failures are dependent failures that are not common cause failures
[pic]
28 Certification
Check of compliance of characteristics with a generally valid regulation (e. g. guidelines and standards) by an independent assessor and confirmation of compliance by an accredited certification authority.
29 Change
Rearrangement of a system or subsystem under development by the manufacturer.
30 Change during development
Alteration of a system/subsystem under development by the producer.
NOTE Changes take place for example in order to remove faults, to enhance capability or other attributes or to adapt the system/subsystem to new operating conditions, etc
31 Change during release
WD 26262-3: Alteration of a system/subsystem under development with available partial releases by the producer.
NOTE Changes take place for example in order to remove faults, to enhance capability or other attributes or to adapt the system/subsystem to new operating conditions, etc.
WD 26262-3/BL10: Alteration of a system/subsystem under development with available partial releases
NOTE Changes take place for example in order to remove faults, to enhance capability or other attributes or to adapt the system/subsystem to new operating conditions, etc.
32 Code-based development
WD 26262-6: Development paradigm for software-based systems, in which the source code is implemented manually based on usually textual defined requirements.
NOTE This approach is often named ‘traditional’ development to distinguish it from model-based software development.
WD 26262-6/BL10: Development paradigm for software-based systems, in which the source code is implemented manually based on usually textual defined requirements
NOTE This approach is often named ‘traditional’ development to distinguish it from model-based software development.
33 Code generator
Code generators are compilers which translate models of a high-level graphical language into source code of an imperative programming language, thereby potentially eliminating or automating several software development and verification activities. Code generators are used in the implementation phase of the model-based approach to software development.
34 Common cause failure (CCF)
Result of one or more events which trigger synchronous failures of two or more separate channels in a multi-channel system resulting in a system failure without the existence of functional dependence.
To be discussed:
Dependent failures of two or more items or components resulting from a single specific event or root cause.
WD 26262-4: Dependent failures of two or more items or components resulting from a single specific event or root cause.
WD 26262-5: Failures of two or more items or components resulting from a single specific event or root cause.
WD 26262-4/BL10: Dependent failures of two or more items or components resulting from a single specific event or root cause
WD 26262-5/BL10, WD 26262-9/BL10: Failures of two or more elements of an item resulting from a single specific event or root cause
[pic]
35 Common mode failures
Common cause failures of items or components that fail in the same manner.
WD 26262-9/BL10: Common cause failures where elements fail in the same manner
36 Compensation
Comparison in order to detect and eliminate discrepancies between various values.
37 Complex of loads
Set of data to calculate the lifetime of a component part; based on amplitude and frequency of stress on component parts during operation with loads changing over time.
38 Component
One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components
WD 26262-4/BL10: A component is a non-system level, non-elementary, logically and technically separable element. A component consists of parts and is itself a part of a system
WD 26262-4/BL10, WD 26262-5/BL10: is a non-system level, non-elementary, logically and technically separable element. A component consists of parts and is itself a part of a system
39 Component off the shelf/Commercial off the shelf (COTS)
Commercial component provided by third party suppliers that can be used to a large extent without adaptation to operation conditions.
40 Component parts qualification
Activity to prove the adequacy of a part to fulfil specified requirements, taking the complex of loads acting on a component into account. Qualification can be achieved in several ways: test, proven in use, or analysis. These methods can be used individually or in combinations, whichever is appropriate for a given case.
41 Computer-aided tools
Computer aided tools are software based tools
WD 26262-9/BL10: Tools that are made of software and which are used to develop electronic control units
42 Configuration
WD 26262-8: A consistent and complete collection of configuration items.
WD 26262-8/BL10, WD 26262-9/BL10: A consistent and complete collection of configuration items
43 Configuration data
WD 26262-6: Data which will be resolved during software build. Configuration data shall not contain executable or interpretable code.
Configuration data includes:
← Pre-processor instructions;
← Software build scripts (e.g. XML configuration files).
NOTE Configuration data control the software build. Only code and/or data being selected by configuration data can be included in the executable code.
WD 26262-6/BL10: Data which will be resolved during software build. Configuration data shall not contain executable or interpretable code
Configuration data includes:
← Pre-processor instructions;
← Software build scripts (e.g. XML configuration files).
NOTE Configuration data control the software build. Only code and/or data being selected by configuration data can be included in the executable code.
44 Configuration item
An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process
WD 26262-8/BL10, WD 26262-9/BL10: Uniquely identifiable part of hardware and software, their documentation and general conditions for their development
45 Configuration management
A discipline applying technical and administrative direction and surveillance to:
← Identify and document the functional and physical characteristics of a configuration item
← Control changes to those configuration items
← Record and report change processing and implementation status
46 Confirmation measures
Total of reviews, audits and assessments
47 Constraint
WD 26262-3: Limiting condition/confinement.
WD 26262-3/BL10: Limiting condition / confinement
48 Control of faults
No violation of safety goals despite faults.
49 Control plan
WD 26262-7: Documentation of the planned control measures, methods and tools within manufacturing to ensure that all safety-related characteristics of the production process, the product or its components are within predefined limits in order to ensure functional safety. Such methods and measures can be for example audits, process monitoring, and testing.
WD 26262-7/BL10: Documentation of the planned control measures, methods and tools within manufacturing to ensure that all safety-related special characteristics of the production process, the product or its components are within predefined limits in order to ensure functional safety. Such methods and measures can be for example audits, process monitoring, and testing
50 Controllability
Avoidance of a specified harm or damage through timely reactions of the persons involved; constitutes one of the basic parameters for hazard analysis and risk assessment.
WD 26262-3/BL10: Avoidance of a specified harm or damage through timely reactions of the persons involved; constitutes one of the basic parameters for hazard analysis and risk assessment
51 Controlled dangerous hardware failure
The controlled dangerous hardware failures form a subset of the potentially dangerous hardware failures. These failures are prevented from leading directly to the violation of a safety goal by a safety barrier.
52 Controlled fault
WD 26262-5: Fault whose potential of subsequent error or failure to violate a safety goal is prevented by the use of a safety mechanism.
NOTE A controlled fault is therefore a multiple point fault.
WD 26262-5/BL10: Fault whose potential of subsequent error or failure to violate a safety goal is prevented by the use of a safety mechanism
NOTE A controlled fault is therefore a multiple point fault.
53 Criteria for test completion
WD 26262-6: The conditions that define if the test is passed, i.e. the state in which a test is completed.
WD 26262-6/BL10: The conditions that define if the test is passed, i.e. the state in which a test is completed
54 Criteria for test termination
WD 26262-6: The requirements, i.e. points in time or conditions, for terminating a test before completion.
WD 26262-6/BL10: The requirements, i.e. points in time or conditions, for terminating a test before completion
55 Critical failure
A failure that is assessed as likely to result in injury to persons, significant material damage or other unacceptable consequences.
56 Critical failure coverage
Proportion of critical failures which is detected/mitigated and hence does not impose any hazard
57 Critical hardware failure
Hardware failure, which leads directly to the violation of a safety goal.
58 Criticality
WD 26262-3: The potential of a system/hardware/software element to create a hazard.
WD 26262-3/BL10: The potential of a system/hardware/software element to create a hazard
WD 26262-9/BL10: Potential for a system/hardware/software element to contribute to the violation of any safety requirement allocated to this element when deviating from its specified functionality
59 Criticality analysis
WD 26262-3: Activity of determining the criticality of a system/hardware/software element when deviating from its specified functionality.
WD 26262-3/BL10: Activity of determining the criticality of a system/hardware/software element when deviating from its specified functionality
WD 26262-9/BL10: Activity of determining the criticality of a system/hardware/software element
60 Cumulated operating time
Addition of operating times of a number of particular identical items.
61 Danger
State from which damage/harm might potentially emerge.
62 Defective
Label for an item with fault status.
NOTE Do not use: faulty.
63 Degradation
WD 26262-3: Intentional limitation of a required function due to a failure during operation.
WD 26262-3/BL10: Intentional limitation of a required function due to a failure during operation
64 Degraded operating state
The state in which, full functionality of the item is not available due to a failure, but, basic requirements including those required for ensuring safety are met.
65 Dependent failures
Failures whose probability of the coincident occurrence cannot be expressed as the simple product of the unconditional probabilities of each of them:
P (Failure A AND Failure B) # P (Failure A) * P (Failure B), where P denotes the probability of failure
NOTE 1 Dependent failures are either common cause failures or cascading failures.
NOTE 2 To focus on practical concern, only the case where P (Failure A AND Failure B) > P (Failure A) * P (Failure B) is meaningful regarding the purpose of the analysis of dependent failures.
WD 26262-5/BL10: failures whose probability of the coincident occurrence cannot be expressed as the simple product of the unconditional probabilities of each of them
P (Failure A AND Failure B) ≠ P (Failure A) x P (Failure B), where P denotes the probability of failure
NOTE 1 Dependent failures are either common cause failures or cascading failures.
NOTE 2 For the analysis of dependent failures, it is only the case where P (Failure A AND Failure B) > P (Failure A) × P (Failure B) that is relevant.
WD 26262-9/BL10: P (Failure A AND Failure B) P (Failure A) * P (Failure B) where P denotes the probability of failure
66 Derivative
WD 26262-3: An item that has already been completely developed and is already being used, which is to be used without any modifications in a new vehicle configuration or under changed environmental conditions.
WD 26262-3/BL10: An item that has already been completely developed and is already being used, which is to be used without any modifications in a new vehicle configuration or under changed environmental conditions
67 Derived safety requirements
Additional safety requirements resulting from the development processes, which may not be directly traceable to higher-level requirements
68 Software Design phases
The phases on the left side of the reference phase model are called design phases. They include the following phases:
← Software safety requirements specification;
← Software architecture and design;
← Software unit design and implementation.
WD 26262-6/BL10: The phases on the left side of the reference phase model (see figure 4.1) are called design phases
They include the following phases:
← Specification of software safety requirements;
← Software architectureal design;
← Software unit design and implementation.
69 Detected potentially dangerous hardware failure indicated to the driver
This is a subset of potentially dangerous hardware failures. These failures are either detected by technical means leading to an indication to the driver or they are detected by the driver himself.
70 Detection time span for latent faults
Duration between the occurrence of a fault in the E/E system and Control system and its detection
WD 26262-4/BL10: Time interval between the occurrence of a multi-point fault and its detection
71 Development interface agreement (DIA)
Agreement between vehicle manufacturer and supplier in which the responsibilities for activities and work products are laid down.
72 Diagnostic coverage
The diagnostic coverage specifies the efficiency of the diagnostic measures to detect critical hardware failures. Quantitatively, it can be defined as "fractional decrease in the probability of dangerous hardware failures resulting from the operation of the automatic diagnostic tests"
WD 26262-5: proportion of a hardware component failure rate that is covered, taking into account the safety mechanism(s) implemented.
NOTE 1 Diagnostic coverage can be assessed with regard to residual faults or to latent multiple point faults that may occur in a component.
NOTE 2 The definition may be represented in terms of the following equations:
[pic]
WD 26262-5/BL10: proportion of a hardware element failure rate that is covered, taking into account the safety mechanisms implemented
NOTE 1 Diagnostic coverage can be assessed with regard to residual faults or with regard to latent multiple point faults that may occur in a hardware element.
NOTE 2 The definition may be represented in terms of the following equations.
[pic]
73 Disengageable, directly
System execution with direct redirection to a safe state if the system or a subsystem does not receive energy addition any more.
74 Disengageable, not directly
System execution with the safe state not reachable by disengaging energy addition directly.
NOTE After a failure occurs at least a constrained functionality (emergency operation) shall be maintained for a specified time (emergency operation time), so that the failure is detected and displayed and the driver can change the state to a constantly safe state.
75 Disjunctive situation
WD 26262-3: Mutually exclusive situations where the occurrence of any one of them automatically implies the nonoccurrence of the other for one vehicle. Two mutually exclusive situations cannot both occur simultaneously for one vehicle.
WD 26262-3/BL10: Mutually exclusive situations where the occurrence of any one of them automatically implies the nonoccurrence of the other for one vehicle. Two mutually exclusive situations cannot both occur simultaneously for one vehicle
76 Display concept
Total information about the respective system conditions in the vehicle received by the driver or other occupants. This may comprise visual, acoustic, haptic information etc. (e. g. information on door looking, windows, AC, seats, radio).
77 Distributed development
Development of a system with shared development responsibility between supplier and vehicle manufacturer for the entire system or for subsystems.
78 Diverse redundancy
Different and independent physical methods or design approaches adopted in different channels of a redundant system to avoid simultaneous common mode failures of more than one channel
79 Diversity
Different and independent solutions fulfilling the same task.
NOTE Examples include diverse programming, testing or diverse hardware.
80 Driving situation
WD 26262-3: Scenario that may occur while a vehicle is in use – moving or stationary.
WD 26262-3/BL10: Scenario that may occur while a vehicle is in use – moving or stationary
81 Dual point failure
WD 26262-5/BL10: multiple Point Failure which leads directly to the violation of a safety goal, resulting from the combination of two independent faults (Dual Point Faults)
82 Dual point fault
WD 26262-5/BL10: multiple Point Fault which can lead to the violation of the safety goal in combination with one independent fault
83 E/E system
An electrical/electronic system that consists of electrical and/or electronic elements, including programmable electronic elements, power supplies, sensors and other input devices, data highways and other communication paths, and actuators and other output devices.
WD 26262-4/BL10: An electrical/electronic system that consists of electrical and/or electronic elements, including programmable electronic elements, power supplies, sensors and other input devices, data highways and other communication paths, and actuators and other output devices
84 E/E system architecture
WD 26262-6: Representation of the structure of the electrics/electronics system of a vehicle which allows identifying building blocks, their boundaries and relations. The E/E system architecture contains the allocation of functions to E/E components (electronic control units, sensors and actuators) and the assignment of these functions to hardware and software, including interfaces.
WD 26262-6/BL10: Representation of the structure of the electrical/electronic system of a vehicle which allows identification of building blocks, their boundaries and relations. The E/E system architecture contains the allocation of functions to E/E components (electronic control units, sensors and actuators) and the assignment of these functions to hardware and software, including interfaces
85 Electronic components
WD 26262-5: Hardware primary component (e.g. resistor, semi-conductor, IC, microprocessor).
86 Element
Sub-units of systems or items on an arbitrary level of detail.
87 Embedded software
WD 26262-6/BL10: The fully-integrated software associated with a single hardware element, normally a micro-controller
88 Emergency operation
WD 26262-3 (8th ISO): Functionality to ensure transition to a permanent safe state, such as degraded operation mode.
WD 26262-3/BL10: Functionality to ensure transition to a permanent safe state, such as degraded operation mode
89 Emergency operation time
WD 26262-4: Duration between the occurrence of a fault and the transition to a permanent safe state, in which at least the functionality specified as an emergency operation, such as degraded functionality, is required.
WD 26262-4/BL10: Duration between the occurrence of a fault and the transition to a permanent safe state, in which at least the functionality specified as an emergency operation, such as degraded functionality, is required
90 Environmental conditions
WD 26262-3: Physical or other constraints under which an item is used.
WD 26262-3/BL10: Physical or other constraints under which an item is used
91 Error
A discrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.
NOTE An error can arise as a result of a fault within the system, sub-system or component being considered.
See source REF1.
92 Evaluation
Systematic determination to what extent an item fulfils the criterion to be specified by the user.
93 Event tree analysis (ETA)
Deductive method to structure consequences of events in graphical representations according to conditions. Representation is usually done as tree with branches for conditions like yes/no or passed/failed, if necessary with probabilities or as nets.
WD 26262-4/BL10: Deductive method to structure consequences of events in graphical representations according to conditions. Representation is usually done as tree with branches for conditions like yes/no or passed/failed, if necessary with probabilities or as nets
94 Executable code
WD 26262-6: Data which is native executable by the micro processor; this means that this data is executable without further interpretation.
WD 26262-6/BL10: Data which is native executable by the micro processor; this means that this data is executable without further interpretation
95 Exposure situation
WD 26262-3: Driving situation which may be hazardous in coincidence with the considered failure mode (used during hazard analysis for estimating the probability of exposure).
WD 26262-3/BL10: Driving situation which may be hazardous in coincidence with the considered failure mode (used during hazard analysis and risk assessment for estimating the probability of exposure)
96 External failure
Failure, which is external to the item.
97 External measure
WD 26262-3/BL10: See WD 26262-2-4.2.2.3
98 External risk reduction facilities
This refers to measures that reduce or mitigate the risks separated and distinct from and do not use, the item described in the system description or other technologies. External risk reduction measures include, for example, road characteristics like guardrails or tunnel fire-fighting systems. External risk reduction measures can be taken into account in the hazard analysis and risk assessment
99 Fail safe
Concept of product design aiming at reaching or keeping a safe state if a failure occurs.
100 Failure
The termination of the ability of a component, a sub-system or a system to perform a function as required.
See source REF2.
WD 26262-5/BL10: the termination of the ability of an element or an item to perform a function as required
NOTE Source: derived from IEC 60050
101 Failure mode
WD 26262-5: Manner in which a component, a sub-system or a system fails.
Source: derived from IEC60812 2nd edition 2006.
NOTE Each failure mode of an HW component can be classified as shown in the following figure:
[pic]
Failure mode distribution of an HW component
WD 26262-5/BL10: manner in which an element or an item fails
NOTE 1 See annex D for failure mode distribution of an HW element.
NOTE 2 Source: derived from IEC60812 - 2nd edition 2006.
102 Failure mode and effects analysis (FMEA)
A systematic bottom up method of identifying the failure modes of a system, item, or function and determining the effects on the next higher level. It may be performed at any level within the system (e.g., piece-part, function, blackbox, etc.)
WD 26262-4/BL10: A method to determine the severity of possible failure modes and to provide input information to the measures for risk reduction (IEC 60812:2006)
103 Failure rate or ( rate
WD 26262-4: Density of probability of failure divided by probability of survival for an electronic component.
NOTE Component hardware failure rate per hour.
WD 26262-5: The limit, if it exists, of the quotient of the conditional probability that the instant of a failure of a non-repaired item falls within a given time interval (t, t+(t) and the duration of this time interval, (t, when (t tends to zero, given that the item has not failed up to the beginning of the time interval.
NOTE 1 The instantaneous failure rate is expressed by the formula:
[pic]
where F(t) and f(t) are respectively the distribution function and the probability density of the failure instant, and where R(t) is the reliability function, related to the reliability R(t1,t2) by R(t) = R(0,t).
NOTE 2 An estimated value of the instantaneous failure rate can be obtained by dividing the ratio of the number of items which have failed during a given time interval to the number of non-failed items at the beginning of the time interval, by the duration of the time interval.
NOTE 3 In English, the instantaneous failure rate is sometimes called “hazard function”.
Source: IEC60050-151 Amd1.
WD 26262-4/BL10: WD 26262-5: Density of probability of failure divided by probability of survival for an electronic component
WD 26262-5/BL10: The limit, if it exists, of the quotient of the conditional probability that the instant of a failure of a non-repaired HW element falls within a given time interval (t, t+(t) and the duration of this time interval, (t, when (t tends to zero, given that the HW element has not failed up to the beginning of the time interval
NOTE 1 The failure rate is generally denoted as "λ ".
NOTE 2 The instantaneous failure rate is expressed by the formula:
[pic]
where F(t) and f(t) are respectively the distribution function and the probability density of the failure instant, and where R(t) is the reliability function, representing the probability of no failure before time t.
NOTE 3 An estimated value of the instantaneous failure rate can be obtained by dividing the ratio of the number of HW elements which have failed during a given time interval to the number of non-failed HW elements at the beginning of the time interval, by the duration of the time interval.
NOTE 4 The instantaneous failure rate is sometimes called “hazard function”.
NOTE 5 Source: derived from IEC60050-151 Amd1.
104 Fault
A fault is the cause of an error; it can either be systematic or random.
NOTE Do not use: defect, mistake.
WD 26262-5/BL10: Abnormal condition that may cause a reduction in, or loss of the capability of an element to perform a required function
NOTE 1 Source: derived from IEC 61508-4/Ed.2 CD.
NOTE 2 A fault may manifest itself as an error within the considered element and, if not controlled, the error may cause a failure.
NOTE 3 A fault may exist in every produced element. Such a fault would be a systematic fault and can for example be a design fault.
105 Fault/Error detection
Use of techniques and procedures aiming at detecting and displaying faults during item operation.
106 Fault tolerance
WD 26262-3 (8th ISO): Ability of a system to perform its required function in the presence of faults.
NOTE A fault tolerance of N means that any combination of N faults does not violate a safety goal.
WD 26262-3/BL10: Ability of a system to perform its required function in the presence of faults
NOTE A fault tolerance of N means that any combination of N faults does not violate a safety goal.
107 Fault tolerant time span
Period in which the vehicle function can be stressed with faulty signals before a hazardous state develops.
WD 26262-4: Period in which the vehicle function can be stressed with faults before a hazardous state develops.
WD 26262-4/BL10: Period in which the vehicle function can be stressed with faults before a hazardous state develops
108 Fault tree analysis (FTA)
Deductive method to determine and represent logical connections between components and subsystem failures resulting in a TOP event. In quantitative FTA the probability of occurrence of the TOP event may be calculated from the reliability data of components and subsystems.
WD 26262-4/BL10: Deductive method to determine and represent logical connections between components and subsystem failures resulting in a TOP event. In quantitative FTA the probability of occurrence of the TOP event may be calculated from the reliability data of components and subsystems
109 Field monitoring
Monitoring (analysis of the failure behaviour) of a product under real operating conditions (after product was offered to market).
110 First sample
Sample exclusively produced by facilities and measures intended for series production within corresponding conditions.
111 Formal notation
WD 26262-6: Description technique that does have both its syntax and semantics completely defined.
NOTE Examples include Mealy and Moore state machines.
WD 26262-6/BL10: Description technique that has both its syntax and semantics completely defined
NOTE Examples include Mealy and Moore state machines.
112 Formal verification
WD 26262-6: Formal verification refers to a formal mathematical proof for an algorithm or a specification against properties.
WD 26262-6/BL10: Formal verification refers to a formal mathematical proof of an algorithm or a specification against properties
113 Freedom from of interference
WD 26262-3: Absence of cascading failures between two or more elements with a common resource which otherwise could lead to the violation of a safety requirement.
NOTE 1 They may only affect each other if the superior element (with higher ASIL) fails, i.e. the inferior element (with lower ASIL) also fails. In case of the inferior element failing the superior element may not fail.
NOTE 2 Freedom of interference is a characteristic associated with criticality analysis.
WD 26262-3/BL10: Absence of cascading failures between two or more elements with a common resource which otherwise could lead to the violation of a safety requirement
NOTE 1 They may only affect each other if the superior element (with higher ASIL) fails, i.e. the inferior element (with lower ASIL) also fails. In case of the inferior element failing the superior element may not fail.
NOTE 2 Freedom of interference is a characteristic associated with criticality analysis.
WD 26262-9/BL10: Absence of cascading failure, between two or more elements or components of the same item, that could lead to the violation of a safety requirement allocated to this item
NOTE Examples include: (a) Element E1 is interference-free of element E2 if no failure of E2 can cause E1 to fail; (b) Element E3 interferes with E4 if there exists a failure of E3 that causes E4 to fail.
114 Freedom from of interference of software
WD 26262-6: Exclusion of unintended interactions between software components as well as freedom from impact on the correct operation of another software component resulting from design- and/or implementation errors of a software component as well as from hardware errors.
WD 26262-6/BL10: Exclusion of unintended interactions between software components as well as freedom from impact on the correct operation of another software component resulting from design- and/or implementation errors of a software component as well as from hardware errors
115 Frequency
WD 26262-3: Actual number (absolute frequency) or percentage (relative frequency) relating to all measured values/events of a basic population.
WD 26262-3/BL10: Actual number (absolute frequency) or percentage (relative frequency) relating to all measured values / events of a basic population
116 Function
Unambiguously defined partial behaviour of one or more electronic control units.
117 Functional architecture
Representation of the system showing its different components of hardware, software, communication links and other technology systems
WD 26262-4/BL10: Allocation of functions to electronic control units and classification into hardware and software, including communication
118 Functional concept
Specifies basic functions and their interactions necessary to achieve the desired behaviour as functional requirements. The functional concept is developed during the concept phase.
119 Functional requirement
WD 26262-3: Requirement for the intended function of the E/E system (when used as intended).
WD 26262-3/BL10: Requirement for the intended function of the E/E system (when used as intended)
120 Functional safety
Part of the overall safety relating to the Equipment under control and the control system which depends on the correct functioning of the E/E safety-related systems, and other technology systems.
121 Functional safety concept
Specification of the requirements of the implementation independent safety functionalities and their interaction necessary to achieve the safety goals. It is developed during concept phase
WD 26262-3/BL10: Specification of the requirements on the basic functionalities and their interaction necessary for achieving the safety goals. It is developed during concept phase
WD 26262-4/BL10: Specification of the requirements of the implementation independent safety functionalities and their interaction necessary to achieve the safety goals. It is developed during concept phase
122 Functional safety requirement
A description of a safety-related functionality that is intended to contribute to the fulfilment of a safety goal, including its safety integrity related attributes. The sum of the functional safety requirements constitutes the functional safety concept
NOTE 1 Safety measure executed by an E/E safety-related system, or by a safety-related system of a different technology, in order to achieve or maintain a safe state for the item taking into account a determined hazardous event.
NOTE 2 The distinction between functional safety requirements and technical safety requirements is essential for the basic understanding of the structuring of safety concepts in this International Standard. Functional safety requirements relate to what services shall be provided by the system architecture while technical safety requirements relate to how the services shall be provided.
WD 26262-3/BL10: Requirement to specify a safety mechanism or a safety measure including its safety-related attributes. The sum of the functional safety requirements constitutes the functional safety concept
NOTE 1 Safety requirement implemented by a safety-related E/E system or by a safety-related system of other technologies in order to achieve or maintain a safe state for the item taking into account a determined hazardous event.
NOTE 2 The distinction between functional safety requirements and technical safety requirements is essential for the basic understanding of the structuring of safety concepts in this International Standard.
WD 26262-4/BL10: Requirement to specify a safety measure to contribute to the fulfilment of a safety goal including its safety integrity-related attributes. The whole functional safety requirements constitute the functional safety concept
NOTE 1 Safety measure executed by an E/E safety-related system, or by a safety-related system of a different technology, in order to achieve or maintain a safe state for the item taking into account a determined hazardous event.
NOTE 2 The distinction between functional safety requirements and technical safety requirements is essential for the basic understanding of the structuring of safety concepts in this International Standard. Functional safety requirements relate to what services shall be provided by the system architecture while technical safety requirements relate to how the services shall be provided.
123 Functional test
Verification of one or more items to ensure compliance with the specified functional requirements.
WD 26262-4/BL10: Evidence of fulfilment of specified functional requirements by the partial behaviour of one or more items by dynamic testing
124 Hardware component
Unit, which might consist of several hardware parts, not partitioned further when under consideration.
NOTE Do not use: module, hardware module, hardware unit.
125 Hardware development
WD 26262-4: Sub-phase of product development process in which hardware is developed.
WD 26262-4/BL10: Sub-phase of product development in which the hardware is developed
126 Hardware failure
There are different kinds of hardware failures to be distinguished. These include random hardware failure, systematic hardware failure, dangerous hardware failure, potentially dangerous hardware failure, controlled dangerous hardware failure, latent potentially dangerous hardware failure, detected potentially dangerous hardware failure indicated to the driver and safe hardware failure.
127 Hardware-in-the-loop test (HiL)
WD 26262-6: For hardware-in-the-loop tests the entire electronic control unit is used as test environment.
WD 26262-6/BL10: For hardware-in-the-loop tests the electronic control unit is used as a test object and executed within an environment for closed loop control that can be simulated or be realised partly in hardware
128 Hardware part
WD 26262-5/BL10: basic element of the hardware
NOTE E.g. resistor, semi-conductor, IC, microprocessor.
129 Hardware safety requirements
Safety requirements applied to the hardware item.
WD 26262-5: Technical safety requirements applied to the hardware of system, sub-system or component.
WD 26262-5/BL10: Technical safety requirements applied to hardware
130 Hardware-software interface (HSI)
Interface, which provides services to the application software based on hardware devices. The hardware software interface includes all software managers of hardware devices (memory managers, input/output managers, etc).
WD 26262-5: HW/SW interface deals with:
a) HW devices of the component that are controlled by SW; and/or
b) HW resources that support execution of SW.
WD 26262-5/BL10: Hardware-software interface deals with:
← HW devices of a component that are controlled by SW,
← HW resources that support execution of SW,
← SW modules or services needed for the proper use of the hardware, such as drivers, timers, etc.
131 Harm
WD 26262-3 (8th ISO): Physical injury or damage to the health of people either directly or indirectly as a result of damage to property or to the environment.
WD 26262-3/BL10: Physical injury or damage to the health of people either directly or indirectly as a result of damage to property or to the environment
132 Hazard
WD 26262-3: Potential source of harm.
WD 26262-3/BL10: Potential source of harm
133 Hazard analysis
Structured method to determine Potential hazards
134 Hazard analysis and risk assessment
The entire procedure of determining and evaluating functional and non-functional risks of the item with regard to potential hazards/harm to individuals. The process consists of the steps situational analysis, hazard analysis and risk assessment
WD 26262-3/BL10: Method to determine an ASIL with regard to hazards/harm to individuals. The process consists of the steps situational analysis, hazard analysis and risk assessment
135 Hazardous event
WD 26262-3: Coincidence of the considered failure mode and the exposure situation in which this failure mode might lead to harm.
WD 26262-3/BL10: Coincidence of the considered failure mode and the exposure situation in which this failure mode might lead to harm
136 Impact anaylsis
WD 26262-3, WD 26262-8: Activity of determining which part of an item and which existing work products will be affected by a proposed change and determining its consequences.
WD 26262-3/BL10, WD 26262-8/BL10, WD 26262-9/BL10: Activity of determining which part of an item and which existing work products will be affected by a proposed change and determining its consequences
137 Independence
Two or more items are independent, if a failure of one of these items does not affect the functionality of the other item(s).
NOTE 1 Independence can be achieved by redundancy in physical separation (e.g. software on different hardware) or different algorithms.
NOTE 2 Independence is a characteristic associated with ASIL decomposition.
WD 26262-3/BL10, WD 26262-9/BL10: Characteristic of two or more elements that is given if no common resources are used or no common systematic failures exist
NOTE 1 Independence can be achieved by redundancy in physical separation (e.g. software on different hardware) or different algorithms.
NOTE 2 Independence is a characteristic associated with ASIL decomposition.
138 Independent department
Separate department not in contact with the departments in charge of activities taking place during a certain phase of the whole E/E or software safety lifecycle which is subject to assessment of functional safety or validation.
139 Independent failures
Failures whose probability of the coincident occurrence can be expressed as the simple product of the unconditional probabilities of each of them
140 Independent person
Separate person not involved in activities taking place during a certain phase of the whole E/E- or software safety lifecycle which is subject to assessment of functional safety or validation. This person also has no responsibility for these activities.
141 Informal notation
WD 26262-6: Description technique that does not have its syntax completely defined.
NOTE 1 An incomplete syntax definition implies that the semantics is also not completely defined.
NOTE 2 Examples include figures and drawings. Descriptions in natural language are not included.
WD 26262-6/BL10: Description technique that does not have its syntax completely defined
NOTE 1 An incomplete syntax definition implies that the semantics are also not completely defined.
NOTE 2 Examples include figures and drawings. Descriptions in natural language are not included.
142 Informal verification
WD 26262-6: Informal verification refers to verification techniques not regarded as semi-formal or formal verification techniques.
NOTE Examples include code inspections and model reviews.
WD 26262-6/BL10: Informal verification refers to verification techniques not regarded as semi-formal or formal verification techniques
NOTE Examples include code inspections and model reviews.
143 Inheritance
WD 26262-3: Passing attributes of requirements in an unchanged manner to the next level of detail during the development process.
WD 26262-3/BL10, WD 26262-9/BL10: Passing attributes of requirements in an unchanged manner to the next level of detail during the development process
144 Initial ASIL
The ASIL resulting from the hazard analysis and risk assessment and that is the starting point for ASIL decomposition.
145 Initial situation
WD 26262-3: Described driving situation used during risk assessment for estimating the frequency of risk occurrence.
146 Inspection
Method of improving product and process quality by means of a systematic verification of work products, which normally takes place before sign-off. For the inspection, the work product is checked by several assessors to see whether it complies with the requirements set for it. The inspection is organised and moderated by an inspection leader. The author of the work product participates in the inspection. An inspection is divided into six obligatory phases:
← Planning/entry check: Ensuring that the inspection order can be implemented;
← Kick-off meeting: Coordinating and agreeing on the planning of the inspection;
← Individual checking: Finding as many content errors as possible;
← Logging meeting: Documenting the discrepancies that were found in a standard form;
← Revision: Complete removal of errors;
← Conclusion/final check: Clarifying to what extent the inspection order has been met.
To be discussed: A review method for the systematically checking work products in order to detect violations of development guidellines and standards, faults, falsities and other problelms. During inspection the work product is checked by assessors for compliance with the requirements defined.
147 Internal failure
Failure, which is internal to the item.
148 Item
E/E system, Other technology system, their subsystems, components, or functions
WD 26262-3/BL10: E/E system (i. e. a product which can include mechanical components of different technologies) or a function which is in the scope of the development according to this standard
NOTE There can be only one item per development.
149 Item definition
WD 26262-3: Description of the item and its interfaces, as well as the functional requirements and the already known safety and reliability requirements.
WD 26262-3/BL10: Description of the item and its interfaces, as well as the functional requirements and the already known safety and reliability requirements
150 Latent critical failure
This is a subset of critical failures. These failures have not been detected yet by technical means or the driver.
151 Latent failure
Not yet detected, but detectable failure.
To be discussed: Failure within a system but without having any consequences yet.
152 Latent fault
Fault whose resultant error or failure is not perceived.
WD 26262-4/BL10: Fault whose subsequent error or failure is not detected
WD 26262-5/BL10: fault whose resultant error or failure is not perceived
153 Latent failure prevention mechanism
WD 26262-5: Mechanism implemented by E/E functions or components in order to detect error(s) or failure(s) so as to prevent latent failures from occurring; this mechanism leads to the system behaviour defined in the functional safety concept (e.g.. driver alert or switching the system in a safe state).
154 Latent fault prevention mechanism
WD 26262-5/BL10: mechanism implemented by E/E functions or components in order to detect and handle errors or failures so as to prevent fault from being latent; this mechanism leads to the system behaviour defined in the functional safety concept
155 Latent potentially dangerous hardware failure
This is a subset of potentially dangerous hardware failures. These hardware failures have not been detected yet by technical means or the driver.
156 Latest ASIL
The ASIL that has lastly been assigned. This is the ASIL to be considered in the criticality analysis.
157 Level of independence
Certain degree of objectivity during confirmation measures. Possible levels include independent person, independent team or independent department or company.
WD 26262-2/BL10: Certain degree of freedom from influence during confirmation measures. Freedom from influence is here related to management, resources and project timing
NOTE Possible levels include independent person, independent team or independent department or company.
158 Lifecycle
Activity over the whole time starting with the concept of a system and terminating with its decommissioning when the system is no longer available for use.
To be discussed: Time from concept to decommissioning of the item.
159 Lifetime
Time observed from the start of operation until the event of failure for an individual, not repairable item.
160 Main function
WD 26262-5: Part of the system, sub-system or component necessary and sufficient to meet the functional specification in nominal condition of operation (without any failure), without regard to meeting the safety requirements.
WD 26262-5/BL10: Function for which the safety goal has been defined
161 Maturity of development subject
Samples and trial variants, for example C-samples, D-samples, first samples, integration steps.
162 Mechanism, detection/control
Mechanism that allows to keep or to switch the system in a safe state before the controlled dangerous failure provokes the violation of the safety goal.
163 Mechatronic system
System consisting of mechanics, electronic, hardware and software.
164 Memory corruption
WD 26262-6/BL10: Unintended writing to memory of another partition
165 Model-based software development
WD 26262-6: Development paradigm for software-based systems, in which an executable, typically graphic, model of the system and its environment is created at an early stage of the development process. The executable model usually consist of three parts: the controller model, a model of the controlled system (vehicle model) and the model of the system's environment (environmental model) which are created at an early stage of the development process and simulated in combination. Then as the model of the controlled system and the environmental model are gradually replaced by the real system and its real environment as the development process continues, the functional model serves as the basis for implementing embedded software on the electronic control units by means of manual or automatic coding (code generation). The vehicle model and environmental model are collectively referred to as the plant model in control engineering.
WD 26262-6/BL10: Development paradigm for software-based systems, in which an executable, typically graphic, model of the system and its environment is created at an early stage of the development process. The executable model usually consists of three parts: the controller model, a model of the controlled system (vehicle model) and the model of the system's environment (environmental model) which are created at an early stage of the development process and simulated in combination. Then as the model of the controlled system and the environmental model are gradually replaced by the real system and its real environment as the development process continues, the functional model serves as the basis for implementing embedded software on the electronic control units by means of manual or automatic coding (code generation). The vehicle model and environmental model are collectively referred to as the plant model in control engineering
166 Model-based testing
WD 26262-6: Test process closely interlinked with model-based development, in which test cases are derived directly from the model-based representation of the requirements, usually with the assistance of a tool.
WD 26262-6/BL10: Test process closely interlinked with model-based development, in which test cases are derived directly from the model-based representation of the requirements and the model itself is utilised as a test object, usually with the assistance of a tool
167 Model-in-the-loop test (MiL)
WD 26262-6: If the software unit tests are executed at model level within a simulated environment, this is termed a model-in-the-loop test.
WD 26262-6/BL10: For model-in-the-loop test the model is used as a test object and executed within an environment for closed loop control that is simulated
168 Modification = change of an item in use
WD 26262-3: Alteration of a released (sub-) system by the manufacturer.
WD 26262-3/BL10: Alteration of a released (sub-) system by the manufacturer
169 Monitoring
Observation of the internal states, intermediate results, and outputs of a system or subsystem to ascertain its correct functioning.
170 Monitoring coverage (MC)
Architectural metrics.
171 Multiple failure
Failure which can lead directly to the violation of a safety goal, resulting from the combination of two or more independent faults (Multiple Point Faults)
172 Multiple point failure
WD 26262-5: Failure which can lead directly to the violation of a safety goal, resulting from the combination of two or more independent faults (Multiple Point Faults)
NOTE A Multiple Point Failure resulting from the combination of two independent faults (Dual Point Faults), can be called a Dual Point Failure.
WD 26262-5/BL10: Failure which leads directly to the violation of a safety goal, resulting from the combination of several independent faults (Multiple Point Faults)
173 Multiple point fault
WD 26262-5: Fault which can lead to the violation of the safety goal only in combination with other independent fault(s).
NOTE 1 A Multiple Point Fault which can lead to the violation of the safety goal in combination with one independent fault can be called a “Dual Point Fault”.
NOTE 2 Multiple Point Faults can be distinguished whether they are latent or perceived.
NOTE 3 A multiple point fault can occur in a safety mechanism or in the main function.
WD 26262-5/BL10: Fault which can lead to the violation of the safety goal only in combination with other independent faults
NOTE 1 Multiple Point Faults can be distinguished whether they are latent or perceived.
NOTE 2 A multiple point fault may result in a failure of a safety mechanism or a failure of the main function.
174 New development
WD 26262-3: Process of creating an item having a previously unspecified functionality, and/or a novel implementation of an existing functionality.
WD 26262-3/BL10: Process of creating an item having a previously unspecified functionality, and/or a novel implementation of an existing functionality
175 Non-functional hazards
WD 26262-3: Are those hazards which arise due to factors other than malfunction or incorrect functioning of the E/E system, safety-related systems of other technologies, and external risk reduction measures.
176 Operating mode
The set of tasks performed in order for an item to execute a required function.
NOTE Operating modes are for example: Powering-up, normal operation, powering-down, degraded operation, initialisation, diagnostic, reasonably foreseeable extraordinary operating conditions, and reasonably foreseeable misuse.
WD 26262-3/BL10: State in which an item executes a required function
NOTE Operating modes/system states are for example: Powering-up, normal operation, powering-down, degraded operation, emergency operation, initialisation, diagnostic, reasonably foreseeable extraordinary operating conditions, and reasonably foreseeable misuse.
177 Operating situation
WD 26262-3: Typical condition of use characterised by location/road type, dynamical driving state, vehicle state (endangered persons), environmental conditions (day/night, climate), and traffic situation.
WD 26262-3/BL10: Typical condition of use characterised by location/road type, dynamical driving state, vehicle state (endangered persons), environmental conditions (day/night, climate), and traffic situation
178 Operating system
The operating system is a software partition that supports the execution of tasks
179 Part
New definition needed, because term "component" is used at a higher integration level (Part: German: Bauteil, here "component part")
180 Partial release
Release for defined usage purposes at a time when not all safety-relevant parts are available.
181 Partitioning
At the system, hardware, or software level, it is the separation of functions to achieve independence between them, usually for fault containment and ease of verification and validation
WD 26262-6/BL10: At the system, hardware, or software level, it is the separation of functions, usually for fault containment and ease of verification and validation
NOTE Function "A" is partitioned from function "B" if function "B" cannot cause a failure in function "A".
182 Perceived fault
WD 26262-5: fault whose subsequent error or failure is perceived by the driver either
a) Directly through obvious limitation of system behaviour or performance; or
b) Because of a dedicated safety mechanism (such as a detection of the error and signalization by a driver alert on the instrument panel)
as defined in the functional safety concept.
WD 26262-5/BL10: fault whose subsequent error or failure is perceived by the driver either
a) directly through obvious limitation of system behaviour or performance; or
b) because of a dedicated safety mechanism (such as a detection of the error and signalisation by a driver alert on the instrument panel);
as defined in the functional safety concept.
183 Plain item
WD 26262-3: The item without safety mechanisms. The plain item is assessed in the hazard analysis and risk assessment.
WD 26262-3/BL10: The item without safety mechanisms. The plain item is assessed in the hazard analysis and risk assessment
184 Potentially dangerous hardware failure
A hardware failure only leading to the violation of a safety goal in combination with further independent failures is a potentially dangerous hardware failure. Potentially dangerous hardware failures can be distinguished whether they are latent or detected. NOTE This term is equivalent to "multiple failure" except the focus here is on hardware.
185 Preliminary hazard analysis
Execution during concept phase to detect hazards or risks within the concept or within suggested alternatives.
186 Primary component
WD 26262-8/BL10: Basic elements of the implemented hardware
NOTE 1 Primary components are for example resistors, transistors or integrated components of general purpose.
NOTE 2 Typically, primary components have no safety case on their own.
187 Probability of dangerous failure
Probability of occurrence of a failure, which will violate the safety goal. The probability is expressed in terms of per unit time.
188 Probability of exposure
WD 26262-3: Probability that a driving or operating situation exists, which may be hazardous in combination with a particular failure.
NOTE Human intervention is excluded in the evaluation of the probability of exposure (as human intervention is assessed separately in the parameter Controllability).
WD 26262-3/BL10: Probability that a driving or operating situation exists, which may be hazardous in combination with a particular failure
NOTE Human intervention is excluded in the evaluation of the probability of exposure (as human intervention is assessed separately in the parameter Controllability)”.
189 Process
Set of activities in relation or interaction with each other transforming prerequisites into results using resources.
NOTE 1 Prerequisites for one process usually are work products from other processes.
NOTE 2 Processes within an organisation are usually planned and executed under controlled conditions in order to create surplus value.
190 Process requirements
Sum of activities and measures to apply when developing a safety-relevant system in order to achieve a desired automotive safety integrity level.
191 Processor-in-the-loop test (PiL)
WD 26262-6: If the software unit tests are executed on the target processor within a simulated environment, this is termed a processor-in-the-loop test. If a processor emulator is used, this is also termed a processor-in-the-loop test.
WD 26262-6/BL10: For processor–in-the-loop test the software is used as a test object and executed on the target processor or a processor emulator within an environment for closed loop control that is simulated
192 Product development
WD 26262-4: Phase in the lifecycle. This phase can be divided into system development, hardware development and software development.
WD 26262-4/BL10: Phase in the lifecycle. This phase can be divided into system development, hardware development and software development
193 Product labelling
Labelling of products to indicate relevant information required for traceability and configuration management purposes. This may include production date, production batch, serial and part numbers, built-in identification code in software, etc.
WD 26262-4/BL10: Labelling of products to indicate the production date
WD 26262-7/BL10: labelling of products to indicate relevant information required for traceability and configuration management purposes. This may include production date, production batch, serial and part numbers, built-in identification code in software, etc
194 Product release
Marks the formal completion of E/E systems development and confirms that the product meets the requirements for functional safety required for vehicle series production. It requires confirmation of all necessary item properties and availability of the required documentation as per the technical specification
195 Product release report
WD 26262-7: Binding development completion and valid product documentation. Product release report describes all necessary item properties for vehicle purposes using technical specifications including valid documentation.
WD 26262-7/BL10: WD 26262-1: Binding development completion and valid product documentation. Product release report describes all necessary item properties for vehicle purposes using technical specifications including valid documentation
196 Production monitoring
Process to monitor the production of systems to ensure that the characteristics of components are in line with their specifications in the production process
WD 26262-7/BL10: Process to monitor the production of systems to ensure that the characteristics of components are guaranteed and in line with their specifications in the production process
197 Production plan
WD 26262-7: Documentation of the planned production steps, processes or facilities used for the manufacturing of a safety-related product or its components. For example manual assembly steps, software-download-equipment or automated machinery.
WD 26262-7/BL10: Documentation of the planned production steps, processes or facilities used for the manufacturing of a safety-related product or its components. For example manual assembly steps, software-download-equipment or automated machinery
198 Production resources
Resources required for manufacturing a product without themselves being part of the product. These include production means, measuring and test means, means of conveyance and storage, operating means.
199 Project
Unique process consisting of a set of coordinated and controlled activities with start and end dates. This process is executed to achieve a certain target fulfilling specific requirements including constraints on time, costs and resources.
200 Project plan
WD 26262-2: Set of informations and regulations valid for planning and executing a certain project. The project plan contains valid agreements specific to this project.
The content of the project plan may include the following:
← Project description;
← Valid activities for this project;
← Execution instructions for the project, i. e. project specific lifecycle;
← List of work products to be provided;
← Methods and tools chosen;
← Standards and guidelines determined; and
← Further project agreements.
WD 26262-2/BL10: A work product concerning management activities that will control and guide a project. The project plan defines dates, milestones, tasks, deliverables, and responsibilities
NOTE The content of the project plan may include the following:
← Project description;
← Valid activities for this project;
← Execution instructions for the project, i.e. project specific lifecycle;
← List of work products to be provided;
← Methods and tools chosen;
← Standards and guidelines determined; and
← Further project agreements.
201 Proven in use credit
Nature and extent of design and implementation measures of items that can be alleviated or suppressed due to proven in use argumentation.
202 Random hardware failure
Failure, occurring at a random time in field, that results from one or more of the possible degradation mechanisms in the hardware.
NOTE Manufacturing tolerances of hardware components cause these components to fail due to several degradation mechanisms after unpredictable operation times (random times). But, failure rates arising from these degradation mechanisms can be generally predicted with reasonable accuracy.
203 Random hardware fault
WD 26262-5/BL10: fault in hardware occurring random in time during operation
NOTE Manufacturing tolerances of hardware elements cause these elements to fail due to several degradation mechanisms after unpredictable operation times (random times). But, failure rates arising from these degradation mechanisms can be generally predicted with reasonable accuracy.
204 Redundancy
WD 26262-3: Adapted from IEC 61508-4: Existence of means, in addition to the means that would be sufficient for a functional unit to perform a required function or for data to represent information.
NOTE Duplicated functional components and the addition of parity bits are both instances of redundancy.
WD 26262-3/BL10: Adopted from IEC 61508-4: Existence of means, in addition to the means that would be sufficient for a functional unit to perform a required function or for data to represent information.
NOTE Duplicated functional components and the addition of parity bits are both instances of redundancy.
WD 26262-9/BL10: Adopted from IEC 61508-4: Existence of means, in addition to the means that would be sufficient for a functional unit to perform a required function or for data to represent information
205 Redundancy concept
Specifies parallel structures necessary for achieving safety goals, as architectural requirements. It is developed during the concept phase
206 Reference system
Item proven in use
207 Regression strategy
WD 26262-8/BL10: Verification strategy to assure that modification of software has not affected existing and previously verified software
208 Regression testing
Repeated testing of the software with unchanged test cases after changes have been made to the embedded software of the electronic control unit. A comparison of the previous results with the actual results shall be carried out in order to see whether the changes have caused unintended effects and whether the embedded software of the electronic control unit fulfils the specified requirements.
209 Relative frequency
Absolute frequency divided by the total number of values observed.
210 Reliability
Capability of an item to perform a required function under given conditions for a given period.
211 Remaining risk
NOTE See also „residual risk“ and „acceptable risk“.
212 Request for quotation (RFQ)
Entirety of manufacturers’ requirements regarding supplier’s delivery and performance. Basis for supplier’s quotation.
213 Requirement
WD 26262-3: Specified characteristics of an item under defined conditions.
WD 26262-3/BL10: Specified characteristics of an item under defined conditions
214 Residual fault
WD 26262-5: Fault which can lead to the violation of the safety goal, occurring in a component which is partly covered by safety mechanism(s) relevant for the Safety Goal being considered.
WD 26262-5/BL10: fault which by itself leads to the violation of a safety goal, occurring in a HW element which is partly covered by safety mechanisms relevant for the Safety Goal being considered
215 Residual risk
Risk remaining after the execution of protective measures.
216 Review
WD 26262-2: Formal checking of the results of a safety activity, where the level of detail is up to the reviewer.
WD 26262-2/BL10: Formal examination of the results of an activity, where the level of detail is up to the reviewer
217 Risk
WD 26262-3: Combination of probability of a harm/damage occuring and the severity of this damage.
WD 26262-3/BL10: Combination of probability of a harm/damage occurring and the severity of this damage
218 Risk analysis
A quantitative or qualitative analysis of the degree of adverse effects of a hazard, taking into consideration the probability of occurrence of the hazard, ability to mitigate the hazard, and severity of its consequences
219 Risk assessment
Entirety of the procedure containing risk analysis and risk evaluation.
220 Risk evaluation
Procedure based on risk analyis in order to determine if the acceptable risk is reached
221 Risk limit
Highest acceptable risk of a certain technical procedure or state.
NOTE In general, the risk limit cannot be determined quantitatively. It is usually described indirectly by safety-relevant specifications.
222 Role
Person independent description of participant requirements in a project organisation. These requirements include rights, obligations and tasks
223 Safe failure
Failure, which by itself, will not cause violation of a safety goal
WD 26262-5/BL10: Failure whose occurrence will not significantly increase the probability of violation of a safety goal
224 Safe fault
Fault, which by itself, will not cause violation of a safety goal
WD 26262-5/BL10: Fault whose occurrence will not significantly increase the probability of violation of a safety goal
NOTE 1 A single point fault, a residual fault or a dual point fault are not safe with respect to the considered safety goal.
NOTE 2 Faults which can lead to the violation of a safety goal only in combination with at least 2 other independent faults may be considered as safe faults in accordance with the safety concept.
225 Safe hardware failure
Hardware failure that affects a safety function, but does not violate the safety goal by itself. It will put, or has the potential to put, the safety-related system into a safe state
226 Safe state
State of the system without any unacceptable risk.
WD 26262-3/BL10: Mode of the system without any unacceptable risk caused by the system
NOTE In habitual language use, intended operational mode or switched-off modes are also typically referred to as “safe states".
WD 26262-5/BL10: state of the item without any unacceptable risk
227 Safety
Non-existence of non-acceptable risks.
228 Safety architecture
WD 26262-3: A set of components and their interaction to fulfil the safety requirements, including redundancy and independence concepts.
WD 26262-3/BL10: A set of components and their interaction to fulfil the safety requirements, including redundancy and independence concepts
229 Safety architectural metrics
WD 26262-5: Metrics for the assessment of the effectiveness of system architecture with respect to safety.
WD 26262-5/BL10: Metrics for the assessment of the effectiveness of the hardware architecture with respect to safety
230 Safety assessor
Person who carries out the functional safety assessment.
WD 26262-6/BL10: Person who carries out the functional safety assessment
231 Safety audit
Systematic and independent examination determining compliance of procedures to establish functional safety requirements with planned agreements as well as determining effective execution and adequacy to achieve specified targets.
232 Safety barrier
A safety barrier consists of measures to detect and control or only to control dangerous failures of E/E functions or components.
233 Safety case
Compilation of available work products supporting the safety of the item for all safety lifecycle phases.
NOTE The greater the evidence of safety, the stronger the safety case.
WD 26262-2/BL10: Argumentation why an item is safe supported by evidence compiled from work products of all safety activities during the whole lifecycle
234 Safety culture
WD 26262-2: Process and strategy to achieve functional safety together with measures for evaluation of the achieved state and measures for communication within the organisation.
WD 26262-2/BL10: Policy and strategy to achieve functional safety together with measures for evaluation of the achieved state and measures for communication within the organisation
235 Safety goal
WD 26262-3: Top-level safety requirement as a result of the hazard analysis and risk assessment. It leads to item characteristics needed to avert hazards or to reduce risk associated with the hazards to an acceptable level.
NOTE 1 The negation of a safety goal leads to the top event of further safety analyses (e.g. FTA).
NOTE 2 The existence of several safety goals for one item is possible.
WD 26262-3/BL10: Top-level safety requirement as a result of the hazard analysis and risk assessment. It leads to item characteristics needed to avert hazards or to reduce risk associated with the hazards to an acceptable level.
NOTE 1 The negation of a safety goal leads to the top event of further safety analyses (e.g. FTA).
NOTE 2 The existence of several safety goals for one item is possible.
236 Safety integrity
Likelihood of a safety-related system satisfactorily performing the specified safety functions under all the stated conditions within a stated period of time
237 Safety integrity level
Refer to Sec 3.19 Automotive safety integrity level “ASIL”
238 Safety measure
Activity or technical solution to avoid or control systematic faults and to detect or control random hardware failures and mitigate their harmful effects.
WD 26262-4/BL10: Activity or technical solution to avoid or control systematic faults and to detect or control random HW failures and mitigate their harmful effects
239 Safety mechanism
Measures implemented by E/E functions or components dedicated to detect and control or just to control dangerous failures in order to achieve or maintain a safet state for the item.
NOTE 1 The failure is either:
← Controlled by the safety mechanism which is able to switch or to maintain the system into a safe state; or
← Detected and indicated by the safety mechanism to the driver who is in this way able to control the consequence(s) as defined in the safety concept.
NOTE 2 Safety mechanisms are implemented within the item to ensure the proper operation of its safety functionality.
WD 26262-5: Mechanism implemented by E/E functions or components in order to achieve or maintain a safe state in case of failure of a component.
A safety mechanism may be implemented in order to detect and control, or just control, error(s) or failure(s) so as to prevent fault from having the potential to violate a safety goal by itself (i.e. prevent fault from being Single Point Fault or Residual Fault).
A safety mechanism may be implemented in order to detect and handle error(s) or failure(s) so as to prevent fault from being latent (latent fault prevention mechanism).
NOTE The safety mechanism is either
a) Able to switch to or maintain the system in a safe state by itself; or
b) Able to give indications to the driver who is in this way able to control the consequence(s) of the item failure,
as defined in the functional safety concept.
WD 26262-4/BL10: Measures implemented by E/E functions or components dedicated to detect and control or just to control dangerous failures in order to achieve or maintain a safe state for the item
NOTE 1 The failure is either:
← Controlled by the safety mechanism which is able to switch or to maintain the system into a safe state; or
← Detected and indicated by the safety mechanism to the driver who is in this way able to control the consequence(s) as defined in the safety concept.
NOTE 2 Safety mechanisms are implemented within the item to ensure the proper operation of its safety functionality.
WD 26262-5/BL10: Mechanism implemented by E/E functions or components in order to achieve or maintain a safe state in case of failure of an element.
A safety mechanism may be implemented in order to detect and control, or just control, errors or failures so as to prevent fault from having the potential to violate a safety goal by itself (i.e. prevent fault from being Single Point Fault or Residual Fault).
A safety mechanism may be implemented in order to detect and handle errors or failures so as to prevent fault from being latent (latent fault prevention mechanism).
NOTE The safety mechanism is either
a) able to switch to or maintain the system in a safe state by itself; or
b) able to give indications to the driver who is in this way able to control the consequences of the item failure,
as defined in the functional safety concept.
240 Safety plan
WD 26262-2: Documented set of timed measures, tools and events helping the introduction of organisational structure, responsibilities, procedures, measures, skills and tools. All in all, there is an assurance of an object fulfilling the safety requirements specified for a given contract or project.
WD 26262-2/BL10: A work product concerning safety management activities that will control and guide the safety activities of a project. The safety plan defines dates, milestones, tasks, deliverables, responsibilities and resources
NOTE The objective of a safety plan is to ensure that the developed system will meet all safety requirements.
241 Safety-related
Property of an element whose malfunction may lead to the violation of a safety goal or has adverse effects on safety
242 Safety-related characteristic
WD 26262-7: The safety-related conditions or requirements derived during the developing phase of the product, e.g. temperature range, date of expiry, fastening torque, production tolerance, and configuration.
243 Safety-related component
Each component, which in case of failure has the potential to contribute to the violation of a safety goal (by propagation).
WD 26262-5: Component which in case of failure has the potential to contribute to the violation of a safety goal (i.e. component whose failure may increase the probability of violation of a safety goal)
NOTE At least one fault that can occur in this component is not safe with regard to the considered safety goal.
244 Safety-related data
All data which may lead to the violation of a safety goal in case of a single fault or in combination with other failures.
245 Safety-related element
WD 26262-5/BL10: element which in case of failure has the potential to contribute to the violation of a safety goal (i.e. component whose failure may increase the probability of violation of a safety goal)
NOTE At least one fault that can occur in this component is a Single Point Fault, a Residual Fault or a Dual Point Fault with respect to the considered safety goal.
246 Safety-related function/system
All E/E functions/systems in the vehicle that could have adverse effects on safety.
247 Safety-related hardware
Hardware executing risk reducing functions in order to achieve or maintain a safe state for the system considering a determined dangerous event.
248 Safety-related software
Any piece of software that could potentially have adverse effects on safety when executing on its intended platform in a vehicle.
NOTE Do not use: safety critical or safety relevant.
249 Safety-related special characteristic
WD 26262-7/BL10: Any design characteristic for which reasonably foreseeable variation could impact, contribute or cause any potential degradation of functional safety. These safety-related conditions or requirements are derived during the developing phase of the product, e.g. temperature range, date of expiry, fastening torque, production tolerance, and configuration
250 Safety requirement
Precondition or an ability that an item shall fulfil to achieve the safety goals.
NOTE Do not use synonymous: requirement.
WD 26262-8/BL10, WD 26262-9/BL10: A requirement is a precondition or an ability that a system shall fulfil
251 Safety review
Activity to determine capability, adequacy and efficiency of the item in order to achieve determined targets.
A technical review is for example a design review.
252 Safety validation
Confirmation based on examination and provision of proof that the safety requirements needed to achieve the safety goals were fulfilled.
253 Sample
Material unit subjected to quality check in a special case or needed in case of a quality check.
254 Semaphore
WD 26262-6: Non-negative integer variable. Its value is decreased entering a critical program section and is incremented again leaving this section. Semaphores are used for synchronisation when several tasks access a common resource like e.g. a common data space.
WD 26262-6/BL10: Non-negative integer variable. Its value is decreased entering a critical program section and is incremented again leaving this section. Semaphores are used for synchronisation when several tasks access a common resource like e.g. a common data space
255 Semi-formal notation
WD 26262-6: Description technique that does have its syntax completely defined, but its semantics definition may be incomplete.
NOTE Examples include graphical modelling approaches such as UML use case diagrams, UML class diagrams, block diagrams and state charts. Structured methods like SADT are regarded as semi-formal notations.
WD 26262-6/BL10: Description technique that does have its syntax completely defined, but its semantics definition may be incomplete
NOTE Examples include graphical modelling approaches such as UML use case diagrams, UML class diagrams, block diagrams and state charts.
256 Semi-formal verification
WD 26262-6: Semi-formal verification refers to the simulation of an executable artefact.
WD 26262-6/BL10: Semi-formal verification refers to the simulation of an artefact that is described in a semi-formal notation and is executable
257 Service history data
Data logged during previous usage of an item including cumulated operating hours, all failures and in-service problems.
258 Service life
See 3.153 “Lifetime”
WD 26262-4/BL10: The observed time interval from completion of the manufacturing process to the instant of failure of an individual, non-repairable item
259 Service notes (maintenance and repair)
WD 26262-4, -7: Documentation of the safety-related characteristics that have to be controlled during service.
WD 26262-4/BL10: Documentation of the safety-related special characteristics that have to be controlled during service
WD 26262-7/BL10: Documentation of the safety-related special characteristics that have to be controlled during maintenance and repair
260 Severity
WD 26262-3: Measure of the expected degree of harm to an endangered individual in a specific situation.
WD 26262-3/BL10: Measure of the expected degree of harm to an endangered individual in a specific situation
261 Single fault
Fault which can lead to the violation of the safety goal, occurring in a component which is not covered by any safety mechanism
262 Single point failure
Failure of the considered system, sub-system, or component which results from a single point fault and can therefore lead directly to the violation of a safety goal.
WD 26262-5/BL10: Failure of the considered element which results from a single point fault and therefore leads directly to the violation of a safety goal
263 Single point fault
WD 26262-5: Fault which can lead to the violation of the safety goal, occurring in a component which is not covered by any safety mechanism.
WD 26262-5/BL10: Fault which by itself leads to the violation of a safety goal, occurring in an HW element which is not covered by any safety mechanism
264 Software
Intellectual product consisting of programs, procedures, data and all corresponding descriptions which belong to the work of an electronic control unit.
265 Software architecture
Organisational structure of software elements according to their call dependence und corresponding interfaces.
266 Software build
WD 26262-6: Software generation process which will be finished with executable code for the desired target.
WD 26262-6/BL10: Software generation process which will be finished with executable code for the desired target
267 Software component
WD 26262-6: The implementation of one or more functions in software. A software component is a logically separable part of the software and consists of one or more software components and/or software units. Within the software architecture software components are realised by partitions and tasks.
NOTE It is necessary to distinguish between the following times at which embedded software may be configured: during build time, end of line programming, at first start up during production, during runtime (operation).
WD 26262-6/BL10: The implementation of one or more functions in software. A software component is a logically separable part of the software and consists of one or more software components and/or software units. Within the software architecture software components are realised by partitions and tasks
268 Software configuration
WD 26262-6: Characteristic of embedded software, which refers to the possibility of adapting this software system, after completing the development to different requirements by extending or reducing the functionality of its software.
WD 26262-6/BL10: Characteristic of embedded software, which refers to the possibility of adapting this software system, after completing the development to different requirements by extending or reducing the functionality of its software
NOTE It is necessary to distinguish between the following times at which embedded software may be configured: By using configuration data during build time and by using calibration data at end of line programming, at first start up during production, service or during runtime (operation).
269 Software development
WD 26262-4: Sub-phase of product development in which the software is developed.
WD 26262-4/BL10: Sub-phase of product development in which the software is developed
270 Software function
Call within software to which data is passed for processing, one or more results are returned and certain effects are triggered.
NOTE Software function does not mean the functionality of the electronic control unit or of the software of the electronic control unit, respectively. Function is usually meant in the sense of a programming language.
271 Software-in-the-loop test (SiL)
WD 26262-6: If the software unit tests are executed on a development system within a simulated environment, this is termed software-in-the-loop test.
WD 26262-6/BL10: For software-in-the-loop test the software is used as a test object and executed on a development system within an environment for closed loop control that is simulated
272 Software item
Consists of software only; the software item can consist of a larger software module.
273 Software library
The characteristics of software libraries are that they:
← possibly are already in use;
← were developed especially for use in several projects;
← are not necessarily available in source code;
← can be maintained and developed further by an external supplier;
← their release cycles are not synchronous with their own development cycle, so the version is frozen at a certain point in time in the project;
← there is restricted access to descriptions of the development process, documentation of the architecture, the source code and the documentation for errors that have occurred.
WD 26262-8/BL10: Is a collection of software components that is intended for reuse in different projects
NOTE The elements of a software library can be represented as software models, source code or object code including the corresponding documentation.
274 Software partition
WD 26262-6: A program, including code and data that is allocated to separated resources of a microcontroller. The operating system has control over these resources.
Software partitions have two aspects:
← Each software partition is an executable part of the embedded software with defined system resources assigned.
NOTE Resources can be e.g. memory, I/O devices, I/O bandwidths and CPU time.
← Between software partitions a fault containment technique prevents the propagation of failures in one software partition to any other software partition.
WD 26262-6/BL10: A program, including code and data that is allocated to separated resources of a microcontroller. The operating system has control over these resources
Software partitions have two aspects:
← Each software partition is an executable part of the embedded software with defined system resources assigned.
NOTE Resources can be e.g. memory, I/O devices, I/O bandwidths and CPU time.
← Between software partitions a fault containment technique prevents the propagation of failures in one software partition to any other software partition.
275 Software partitioning
WD 26262-6: Software partitioning is a fault encapsulation technique that prevents propagation of a failure in one software partition to any other software partition causing them to fail.
NOTE Software partitioning is not intended to protect against failure of each software partition but against their propagation. When applied to software, the intent of partitioning is to control the additional hazard that is created when a software partition shares its resources with other software partitions.
WD 26262-6/BL10: Software partitioning is a fault encapsulation technique that prevents propagation of a failure in one software partition to any other software partition causing them to fail
NOTE Software partitioning is not intended to protect against failure of each software partition but against their propagation. When applied to software, the intent of partitioning is to control the additional hazard that is created when a software partition shares its resources with other software partitions.
276 Software-related hardware resource
WD 26262-6: Hardware resources that are required by the software to operate. Typical software related hardware resources are CPU time, I/O devices (incl. bus systems, A/D-Converters, general purpose timer) and memory.
WD 26262-6/BL10: Hardware resources that are required by the software to operate. Typical software-related hardware resources are CPU time, I/O devices (incl. bus systems, A/D-Converters, general purpose timer) and memory
277 Software-related system resource
WD 26262-6: Software-related system resources consist of software related hardware resources and software resources.
WD 26262-6/BL10: Software-related system resources consist of software-related hardware resources and software resources
278 Software resources
WD 26262-6: Resources that are managed by the operating system. Typical software resources are all kind of handles e.g. for files, semaphores and tasks.
WD 26262-6/BL10: Resources that are managed by the operating system. Typical software resources are all kind of handles e.g. for files, semaphores and tasks
279 Software safety acceptance test
WD 26262-6: Testing conducted to enable an authorized entity to demonstrate that
← The safety-related part of the embedded software correctly fulfils all software safety requirements and is adequate to reach the safety goals; and
← The non-safety-related part of the embedded software has no unintended influence on safety-related functionality.
NOTE The software safety acceptance test is a part of the safety validation of the E/E system (WD 26262-4, chapter°8 “Safety validation”).
WD 26262-6/BL10: Testing conducted to enable an authorised entity to demonstrate that
← The safety-related part of the embedded software correctly fulfils all software safety requirements and is adequate to reach the safety goals; and
← The non safety-related part of the embedded software has no unintended influence on safety-related functionality.
NOTE The software safety acceptance test is a part of the safety validation of the E/E system (WD 26262-4, chapter°8 “Safety validation”).
280 Software tool
WD 26262-8-13-14: A tool realised fully in software.
WD 26262-8/BL10: Computer-aided means that is used to develop and maintain electronic control units and its software
WD 26262-9/BL10: A tool realised fully in software
281 Software unit
WD 26262-6: The smallest software component of the software architecture that can be subjected to stand-alone testing.
NOTE 1 In case of the C programming language a software unit could be a C function or a group of C functions. In case of a block diagram modelling language a software unit could be a subsystem of the model.
NOTE 2 In the C language this is typically a C source (.c)-file together with its header (.h) -file.
WD 26262-6/BL10: The smallest software component of the software architecture that can be subjected to stand-alone testing
NOTE 1 In case of the C programming language a software unit could be a C function or a group of C functions. In case of a block diagram modelling language a software unit could be a subsystem of the model.
NOTE 2 In the C language this is typically a C source (.c)-file together with its header (.h) -file.
282 Specification
A collection of requirements which, when taken together, constitute the criteria that define the functions and attributes of a system, or an item.
NOTE A specification may use many different formats and notations to record the requirements, including: natural language, diagrams, UML models, state transition diagrams, block diagrams, etc. (see formal specification and semi-formal specification). A specification can take the form of (tender) requirement specification or system specification.
WD 26262-4/BL10: A collection of requirements which, when taken together, constitute the criteria that define the functions and attributes of a system, or an item
NOTE A specification may use many different formats and notations to record the requirements, including: natural language, diagrams, UML models, state transition diagrams, block diagrams, etc. (see formal specification and semi-formal specification). A specification can take the form of (tender) requirement specification or system specification.
283 Staff
Umbrella term for all roles.
NOTE Do not use: employee.
284 Standard component
WD 26262-8: Logic components and integrated parts, COTS without ASIL capability.
WD 26262-9/BL10: Logic components and integrated parts, COTS without ASIL capability
285 Supplier
Manufacturer and trader of new and spare parts for motor vehicles.
NOTE Do not use: customer, contractor.
286 Switch-off
WD 26262-3: Emergency mode with immediate or controlled shut down characteristics.
WD 26262-3/BL10: Emergency mode with immediate or controlled shut down characteristics
287 System
Set of elements (at least sensor, controller, and actuator) in relation with each other according to design. An element of a system can be another system at the same time. Then, it is called subsystem which can be a controlling or controlled system or which can contain hardware, software and manual operations.
NOTE Do not use: partial system, actor.
288 System design
WD 26262-4: Phase in which the system specification and the technical safety concept are developed.
NOTE The activity performed in WD°26262-4 is called system design; the term architecture design is used exclusively for the activity performed in WD°26262-3.
WD 26262-4/BL10: Phase in which the system specification and the technical safety concept are developed
NOTE The activity performed in WD°26262-4 is called system design; the term architecture design is used exclusively for the activity performed in WD°26262-3.
289 System development
WD 26262-4: Sub-phase of product development where no distinction has been made yet between hardware and software.
WD 26262-4/BL10: Sub-phase of product development where no distinction has been made yet between hardware and software
290 System-FMEA
WD 26262-4: NOTE See failure mode and effects analysis.
WD 26262-4/BL10: NOTE See failure mode and effects analysis.
291 System function
WD 26262-4: Adapted from "Function": Unambiguously defined behaviour of a system.
WD 26262-4/BL10: Unambiguously defined behaviour of a system
292 System specification
WD 26262-4: Compilation of all requirements (technical safety requirements and non-safety requirements) at system level. No distinction is made between hardware and software at system level. This is specified in the system design phase.
WD 26262-4/BL10: Compilation of all requirements (technical safety requirements and non-safety requirements) at system level. No distinction is made between hardware and software at system level. This is specified in the System design phase
293 Systematic failure
Failure, related in a deterministic way to a certain cause, that can only be eliminated by a modification of the design or of the manufacturing process, operational procedures, documentation or other relevant factors
WD 26262-5/BL10: Failure, related in a deterministic way to a certain cause, that can only be eliminated by a modification of the design or of the manufacturing process, operational procedures, documentation or other relevant factors
294 Systematic hardware failure
Systematic failure of the hardware
295 Target parameter
Boundary value for the probability of a safety goal violation. Quantitative analysis shall show that this boundary value is not excedeed.
296 Task
WD 26262-6: Runtime entities which are executed within the resource budget of partitions. Each task has its own stack and priority.
NOTE A task is executed under the control of the scheduler according to the task priority assigned to it and the selected scheduling policy.
WD 26262-6/BL10: Runtime entities which are executed within the resource budget of partitions. Each task has its own stack and priority
NOTE A task is executed under the control of the scheduler according to the task priority assigned to it and the selected scheduling policy.
297 Technical safety concept
Sum of technical safety requirements to implement and to distribute the functional safety concept on system architecture. It is part of the system specification and is specified during system design.
WD 26262-3/BL10: Entirety of technical safety requirements to implement and to partition the functional safety concept on system architecture. It is part of the system specification and is specified during system design
WD 26262-4/BL10: Sum of technical safety requirements to implement and to distribute the functional safety concept on system architecture. It is part of the system specification and is specified during system design
298 Technical safety requirement
WD 26262-3, WD 26262-4: Requirements to be derived from associated functional safety requirements and to provide their technical implementation.
WD 26262-3/BL10, WD 26262-4/BL10: Requirements to be derived from associated functional safety requirements and to provide their technical implementation
299 Test criterions
WD 26262-4: Input for strip end control test specification of safety-related characteristics.
WD 26262-7: Characteristics to be verified during a test, typically a pass or fail criteria. In this chapter these criterions are inputs for end of line control test specification of safety-related characteristics
WD 26262-4/BL10: Input for strip end control test specification of safety-related special characteristics
WD 26262-7/BL10: Characteristics to be verified during a test, typically a pass or fail criteria. In this part these criterions are inputs for end of line control test specification of safety-related special characteristics
300 Test/inspection devices
Measuring means or other devices used in the production process to ensure product quality
301 Software Test phases
WD 26262-6: The phases on the right side of the reference phase model are called test. They include the following phases:
← Software unit testing;
← Software integration and testing;
← Software safety acceptance testing.
WD 26262-6/BL10: The phases on the right side of the reference phase model (see figure 4.1) are called test phases
They include the following phases:
← Software unit testing;
← Software integration and testing;
← Software safety acceptance testing.
302 Testing
Process of planning, preparing and executing the development subject under specified conditions in order to demonstrate the required behaviour and the non-existence of unwanted behaviour.
WD 26262-6/BL10: The process of exercising a system or system component to verify that it satisfies specified requirements and to detect errors (Ref. DO-178B)
WD 26262-1: Process of planning, preparing and executing the development subject under specified conditions in order to demonstrate the required behaviour and the non-existence of unwanted behaviour
303 Testing notes
WD 26262-4, -7: Hints for testing procedure of safety-related characteristics of a function.
WD 26262-4/BL10, WD 26262-7/BL10: Hints for testing procedure of safety-related special characteristics of a function
304 Time to repair
Period of time between the failure of a component and its transition into an operational state.
305 Timely reaction
WD 26262-2: Counter measure performed by a traffic participant to control a hazardous situation within a maximum allowable time span that may elapse.
306 Tolerable risk
See 3.6 “Acceptable Risk”
307 Tool
WD 26262-8-13-14: An implement, instrument, or device that provides a mechanical or mental advantage in performing a task.
WD 26262-8/BL10, WD 26262-9/BL10: An implement, instrument, or device that provides a mechanical or mental advantage in performing a task
308 Traceability
The origin, realisation and proof for a requirement are clearly described in the documentation.
309 Traceable
Having the property of traeability
Also see 3.261 "Traceability".
WD 26262-4/BL10: The requirement, design and evidence of correct implementation of a requirement are clearly described in the documentation
310 Validation
Confirmation based on examination and provision of proof that special requirements for a certain, intended use have been fulfilled.
311 Validation goal
WD 26262-4: Evidence that safety goals and technical safety requirements are complete and have been achieved.
WD 26262-4/BL10: Evidence that safety goals and technical safety requirements are complete and have been achieved
312 Validation level
Level at which a proof of fulfilment of certain requirements is given. These levels include: software level, hardware level, E/E system level, vehicle level.
313 Validation plan
Documented set of timed measures, tools and events needed for achieving the required validation.
314 Variant
In parallel to a basic version simultaneously produced and offered embodiment of a product.
315 Vehicle
Definition of the classifications M, N and O according to directive 70/156/EG
← M motor vehicle designed and built for the conveyance of passengers and having at least four wheels
← N motor vehicle designed and built for the forwarding of goods and having at least four wheels
← O trailer (including semitrailer).
NOTE Do not use: car.
316 Vehicle configuration
Labelled set of configuration elements (hardware, software, functions) fulfilling together a predefined task and defining a certain state of the (sub)system. A configuration is identified by name and version. Configurations can occur at any time during development and can include all types of configuration elements. The vehicle configuration is a certain configuration containing all configuration elements related to the vehicle project.
317 Vehicle manufacturer
A person, company or association responsible for the assembly of a vehicle into an operable unit and responsible for the uniqueness of the VIN (according to ISO 3779).
To be discussed: Natural or legal person who is responsible for design and production of a vehicle as well as for its offer to market.
318 Vehicle testing
WD 26262-4: Activity for providing evidence of the fulfilment of defined product characteristics under specified conditions of use like environmental conditions, handling etc. with the vehicle. There, the vehicle as well as sample parts in different states up to production state are used.
WD 26262-4/BL10: Activity for providing evidence of the fulfilment of defined product characteristics under specified conditions of use like environmental conditions, handling etc. with the vehicle. There, the vehicle as well as sample parts in different states up to production state are used
319 Verifiability
Possibility to confirm the fulfilment of specified requirements based on an examination and provision of an objective proof.
320 Verification
Confirmation based on examination and provision of an objective proof that the requirements specified have been fulfilled.
Verification proves this by
a) verification of the work products from design phases
NOTE 1 See verification during design.
b) testing during test and integration phases
NOTE 2 See Verification during test
WD 26262-6/BL10: Doing things right – evaluation of the correct implementation at hardware and software level. Occurs during the design phases where it is called verification during design and during the test phases where it is called testing
321 Verification during design
WD 26262-6: Verification that the specified requirements have been correctly implemented during a design phase. At the end of each design phase verification has to show that the requirements set for this design phase have been fulfilled.
WD 26262-6/BL10: Verification that the specified requirements have been correctly implemented during a design phase. At the end of each design phase verification has to show that the requirements set for this design phase have been fulfilled
322 Verification during test
Proof of the correct implementation of the requirements specified in a design phase. Therefore, at the end of the development phase the fulfilment of the specified requirements for the design phase shall be proven.
323 Verification plan
WD 26262-4: Planning of verification activities and specification of component and integration tests.
WD 26262-4/BL10: Planning of verification activities and specification of component and integration tests
324 Walkthrough
WD 26262-6: A systematic, informal verification method used to improve product quality. The developer explains the work product step by step to one or more assessors during a meeting. The objective is to create a common understanding of the work product and to identify any errors, defects, discrepancies or problems within the work product. A walkthrough is a less stringent form of an inspection.
WD 26262-6/BL10: A systematic, informal verification method used to improve product quality. The developer explains the work product step by step to one or more assessors during a meeting. The objective is to create a common understanding of the work product and to identify any errors, defects, discrepancies or problems within the work product. A walkthrough is a less stringent form of an inspection
325 Warning and degradation concept
WD 26262-3: Specification for how to alert the driver of potentially reduced functionality and specification how to provide this reduced functionality.
WD 26262-3/BL10: Specification for how to alert the driver of potentially reduced functionality and specification how to provide this reduced functionality
326 White-Box-Test
Tests designed utilizing the knowledge of internal structure of the test object
WD 26262-6/BL10: Tests of a test object whose internal structure and implementation are used
327 Work product
WD 26262-3: Result of the activities within a phase.
WD 26262-3/BL10: Result of the activities within a phase
Abbreviations
For the application of all parts of this International Standard the following abbreviations apply:
|Abbreviations |Meaning |Note |
|ACC |Adaptive Cruise Control |WD 26262-3/BL10, WD 26262-4/BL10 |
| | |WD 26262-3, -4 |
|AEC |Automotive Electronics Council |WD 26262-5/BL10 |
| | |WD 26262-5 |
|AIS |Abbreviated Injury Scale |WD 26262-3/BL10 |
| | |WD 26262-3 |
|ASIL |Automotive Safety Integrity Level |WD 26262-5/BL10 |
| | |all |
|BCI |Bulk Current Injection |WD 26262-5 |
|BIST |Built-In Self-Test |WD 26262-5/BL10 |
| | |WD 26262-5 |
|CBD |Code-Based Development |WD 26262-6/BL10 |
| | |WD 26262-6 |
|CCA |Common Cause Analysis |WD 26262-5/BL10 |
| | |WD 26262-5 |
|CCF |Common Cause Failure |WD 26262-3/BL10, WD 26262-5/BL10 |
| | |WD 26262-3, -5 |
|CMF |Common Mode Failure | |
|COTS |Component / Commercial Off The Shelf |WD 26262-5/BL10, WD 26262-6/BL10 |
| | |WD 26262-5, -6 |
|CPU |Central Processing Unit |WD 26262-5/BL10, WD 26262-6/BL10 |
| | |WD 26262-5, -6 |
|CRC |Cyclic Redundancy Check |WD 26262-5/BL10, WD 26262-6/BL10 |
| | |WD 26262-5, -6 |
|DC |Diagnostic Coverage |WD 26262-5/BL10 |
| | |WD 26262-5 |
|DC |Direct Current |WD 26262-5/BL10 |
|DFC |Dangerous Failure Coverage | |
|DIA |Development Interface Agreement |WD 26262-2/BL10, WD 26262-8/BL10, |
| | |WD 26262-9/BL10 |
| | |WD 26262-8 |
|DSC |Dynamic Stability Control |WD 26262-4/BL10 |
| | |WD 26262-4 |
|ECU |Electronic Control Unit |WD 26262-5/BL10, WD 26262-6/BL10 |
| | |WD 26262-5, -6 |
|EDC |Error Detection Codes |WD 26262-5/BL10 |
| | |WD 26262-5 |
|E/E |Electrical and/or Electronic and/or programmable electronic components | |
|E/E-System |Electrical and/or Electronic system |WD 26262-5/BL10 |
| | |WD 26262-5 |
| | |Do not use: E/E/PES |
|EMC |ElectroMagnetic Compatibility |WD 26262-5/BL10 |
| | |WD 26262-3, -5 |
|ESP |Electronic Stability Program |WD 26262-4/BL10 |
| | |WD 26262-4 |
|ETA |Event Tree Analysis |WD 26262-3/BL10 |
| | |WD 26262-3 |
|EUC |Equipment Under Control | |
|FHA |Functional Hazard Analysis |WD 26262-3/BL10 |
| | |WD 26262-3 |
|FMEA |Failure Mode and Effects Analysis |WD 26262-3/BL10; WD 26262-5/BL10 |
| | |WD 26262-3, -5 |
|FMECA |Failure Mode, Effects and Criticality Analysis | |
|FMEDA |Failure Mode, Effects and Diagnostics Analysis | |
|FTA |Fault Tree Analysis |WD 26262-3/BL10; WD 26262-5/BL10 |
| | |WD 26262-3, -5 |
|H&R |Hazard analysis and Risk assessment |WD 26262-3 |
|HAZOP |HAzard and OPerability analysis |WD 26262-3/BL10 |
| | |WD 26262-3 |
|HiL |Hardware-in-the-Loop |WD 26262-6 |
|HSI |Hardware Software Interface |WD 26262-5/BL10 |
|HW |HardWare |WD 26262-5/BL10 |
| | |WD 26262-5 |
|IC |Integrated Circuit |WD 26262-5/BL10 |
| | |WD 26262-5 |
|I/O |Input – Output |WD 26262-5/BL10 |
| | |WD 26262-5 |
|MBD |Model-Based Development |WD 26262-6/BL10 |
| | |WD 26262-6 |
|MBT |Model-Based Testing |WD 26262-6/BL10 |
| | |WD 26262-6 |
|MC |Monitoring Coverage | |
|MC/DC |Modified Condition Decision Coverage | |
|MiL |Model-in-the-Loop |WD 26262-6 |
|MMI |Man Machine Interface |Not: Man Machine Interaction |
|MMU |Memory Management Unit |WD 26262-6/BL10 |
| | |WD 26262-6 |
|MPU |Memory Protection Unit |WD 26262-6/BL10 |
| | |WD 26262-6 |
|N |Entwurfsphase | |
|OS |Operating System |WD 26262-5/BL10 |
| | |WD 26262-5 |
|PD |Product Development |WD 26262-4/BL10 |
| | |WD 26262-4 |
|PHA |Preliminary Hazard Analysis |WD 26262-3 |
|PiL |Processor-in-the-Loop |WD 26262-6 |
|QM |Quality Management |WD 26262-2/BL10, WD 26262-3/BL10 |
| | |WD 26262-2, WD 26262-3 |
|RAM |Random Access Memory | |
|RFQ |Request For Quotation |WD 26262-8/BL10, WD 26262-9/BL10 |
| | |WD 26262-8 |
|ROM |Read-Only Memory | |
|SADT |Structured Analysis and Design Technique | |
|SART |Structured Analysis / Real Time | |
|SiL |Software-in-the-Loop |WD 26262-6 |
|SIL |Safety Integrity Level | |
|SOP |Start Of Production |WD 26262-2/BL10, WD 26262-6/BL10 |
| | |WD 26262-6 |
|SRS |System Requirements Specification |WD 26262-2/BL10 |
| | |WD 26262-2 |
|SW |SoftWare |WD 26262-5/BL10 |
| | |WD 26262-5 |
|V&V |Verification and Validation |WD 26262-2/BL10 |
| | |WD 26262-2 |
Table 4.1°– Abbreviations
-----------------------
[1]) According to directive 70/156/EG:
-M Motor vehicles with at least four wheels used for the carriage of passengers;
-N Motor vehicles with at least four wheels used for the carriage of goods;
-O Trailers (including semi-trailers).
See also ISO 3833.
[2]) See "European agreement concerning the international carriage of dangerous goods by road" (ADR); Source of supply: United Nations (UN), Geneva, Switzerland.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- university of minnesota college of education
- university of minnesota school of social work
- wharton school of the university of pennsylvania
- cost of university of scranton
- university of sc student portal
- university of sc self service
- university of minnesota school of education
- university of scranton cost of attendance
- university of south florida college of medicine
- university of sc student email
- university of sc aiken
- university of minnesota masters of social work