ISO 26262-6:2018

INTERNATIONAL ISO
STANDARD 26262-6
Second edition
2018-12
Road vehicles — Functional safety —
Part 6:
Product development at the software
level
Véhicules routiers — Sécurité fonctionnelle —
Partie 6: Développement du produit au niveau du logiciel
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Requirements for compliance . 2
4.1 Purpose . 2
4.2 General requirements . 2
4.3 Interpretations of tables . 3
4.4 ASIL-dependent requirements and recommendations . 3
4.5 Adaptation for motorcycles . 4
4.6 Adaptation for trucks, buses, trailers and semi-trailers. 4
5 General topics for the product development at the software level .4
5.1 Objectives. 4
5.2 General . 4
5.3 Inputs to this clause . 5
5.3.1 Prerequisites . 5
5.3.2 Further supporting information . 5
5.4 Requirements and recommendations . 5
5.5 Work products . 7
6 Specification of software safety requirements . 7
6.1 Objectives. 7
6.2 General . 8
6.3 Inputs to this clause . 8
6.3.1 Prerequisites . 8
6.3.2 Further supporting information . 8
6.4 Requirements and recommendations . 8
6.5 Work products .10
7 Software architectural design .10
7.1 Objectives.10
7.2 General .10
7.3 Inputs to this clause .10
7.3.1 Prerequisites .10
7.3.2 Further supporting information .10
7.4 Requirements and recommendations .11
7.5 Work products .16
8 Software unit design and implementation .16
8.1 Objectives.16
8.2 General .17
8.3 Inputs to this clause .17
8.3.1 Prerequisites .17
8.3.2 Further supporting information .17
8.4 Requirements and recommendations .17
8.5 Work products .19
9 Software unit verification .19
9.1 Objectives.19
9.2 General .19
9.3 Inputs to this clause .20
9.3.1 Prerequisites .20
9.3.2 Further supporting information .20
9.4 Requirements and recommendations .20
9.5 Work products .24
10 Software integration and verification .24
10.1 Objectives.24
10.2 General .24
10.3 Inputs to this clause .24
10.3.1 Prerequisites .24
10.3.2 Further supporting information .25
10.4 Requirements and recommendations .25
10.5 Work products .28
11 Testing of the embedded software .28
11.1 Objective .28
11.2 General .28
11.3 Inputs to this clause .28
11.3.1 Prerequisites .28
11.3.2 Further supporting information .28
11.4 Requirements and recommendations .29
11.5 Work products .30
Annex A (informative) Overview of and workflow of management of product development
at the software level .31
Annex B (informative) Model-based development approaches .36
Annex C (normative) Software configuration.40
Annex D (informative) Freedom from interference between software elements .46
Annex E (informative) Application of safety analyses and analyses of dependent failures at
the software architectural level .48
Bibliography .57
iv © ISO 2018 – All rights reserved

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles Subcommittee, SC 32,
Electrical and electronic components and general system aspects.
This edition of ISO 26262 series of standards cancels and replaces the edition ISO 26262:2011 series of
standards, which has been technically revised and includes the following main changes:
— requirements for trucks, buses, trailers and semi-trailers;
— extension of the vocabulary;
— more detailed objectives;
— objective oriented confirmation measures;
— management of safety anomalies;
— references to cyber-security;
— updated target values for hardware architecture metrics;
— guidance on model based development and software safety analysis;
— evaluation of hardware elements;
— additional guidance on dependent failure analysis;
— guidance on fault tolerance, safety related special characteristics and software tools;
— guidance for semiconductors;
— requirements for motorcycles; and
— general restructuring of all parts for improved clarity.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
A list of all parts in the ISO 26262 series can be found on the ISO website.
vi © ISO 2018 – All rights reserved

Introduction
The ISO 26262 series of standards is the adaptation of IEC 61508 series of standards to address the
sector specific needs of electrical and/or electronic (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 components.
Safety is one of the key issues in the development of road vehicles. Development and integration of
automotive functionalities strengthen the need for functional safety and the need to provide evidence
that functional safety objectives are satisfied.
With the trend of increasing technological complexity, software content and mechatronic
implementation, there are increasing risks from systematic failures and random hardware failures,
these being considered within the scope of functional safety. ISO 26262 series of standards includes
guidance to mitigate these risks by providing appropriate requirements and processes.
To achieve functional safety, the ISO 26262 series of standards:
a) provides a reference for the automotive safety lifecycle and supports the tailoring of the activities
to be performed during the lifecycle phases, i.e., development, production, operation, service and
decommissioning;
b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive
Safety Integrity Levels (ASILs)];
c) uses ASILs to specify which of the requirements of ISO 26262 are applicable to avoid unreasonable
residual risk;
d) provides requirements for functional safety management, design, implementation, verification,
validation and confirmation measures; and
e) provides requirements for relations between customers and suppliers.
The ISO 26262 series of standards is concerned with functional safety of E/E systems that is achieved
through safety measures including safety mechanisms. It also provides a framework within which
safety-related systems based on other technologies (e.g. mechanical, hydraulic and pneumatic) can be
considered.
The achievement of functional safety is influenced by the development process (including such
activities as requirements specification, design, implementation, integration, verification, validation
and configuration), the production and service processes and the management processes.
Safety is intertwined with common function-oriented and quality-oriented activities and work
products. The ISO 26262 series of standards addresses the safety-related aspects of these activities and
work products.
Figure 1 shows the overall structure of the ISO 26262 series of standards. The ISO 26262 series of
standards is based upon a V-model as a reference process model for the different phases of product
development. Within the figure:
— the shaded “V”s represent the interconnection among ISO 26262-3, ISO 26262-4, ISO 26262-5,
ISO 26262-6 and ISO 26262-7;
— for motorcycles:
— ISO 26262-12:2018, Clause 8 supports ISO 26262-3;
— ISO 26262-12:2018, Clauses 9 and 10 support ISO 26262-4;
— the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number
of the particular part and “n” indicates the number of the clause within that part.
EXAMPLE “2-6” represents ISO 26262-2:2018, Clause 6.
Figure 1 — Overview of the ISO 26262 series of standards
viii © ISO 2018 – All rights reserved

INTERNATIONAL STANDARD ISO 26262-6:2018(E)
Road vehicles — Functional safety —
Part 6:
Product development at the software level
1 Scope
This document is intended to be applied to safety-related systems that include one or more electrical
and/or electronic (E/E) systems and that are installed in series production road vehicles, excluding
mopeds. This document does not address unique E/E systems in special vehicles such as E/E systems
designed for drivers with disabilities.
NOTE Other dedicated application-specific safety standards exist and can complement the ISO 26262 series
of standards or vice versa.
Systems and their components released for production, or systems and their components already under
development prior to the publication date of this document, are exempted from the scope of this edition.
This document addresses alterations to existing systems and their components released for production
prior to the publication of this document by tailoring the safety lifecycle depending on the alteration.
This document addresses integration of existing systems not developed according to this document and
systems developed according to this document by tailoring the safety lifecycle.
This document addresses possible hazards caused by malfunctioning behaviour of safety-related E/E
systems, including interaction of these systems. It does not address hazards related to electric shock,
fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar
hazards, unless directly caused by malfunctioning behaviour of safety-related E/E systems.
This document describes a framework for functional safety to assist the development of safety-
related E/E systems. This framework is intended to be used to integrate functional safety activities
into a company-specific development framework. Some requirements have a clear technical focus to
implement functional safety into a product; others address the development process and can therefore
be seen as process requirements in order to demonstrate the capability of an organization with respect
to functional safety.
This document does not address the nominal performance of E/E systems.
This document specifies the requirements for product development at the software level for automotive
applications, including the following:
— general topics for product development at the software level;
— specification of the software safety requirements;
— software architectural design;
— software unit design and implementation;
— software unit verification;
— software integration and verification; and
— testing of the embedded software.
It also specifies requirements associated with the use of configurable software.
Annex A provides an overview on objectives, prerequisites and work products of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 26262-1, Road Vehicles — Functional Safety — Part 1: Vocabulary
ISO 26262-2:2018, Road Vehicles — Functional Safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and
decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-
oriented and safety-oriented analyses
3 Terms and definitions
For the purposes of this document, the terms, definitions and abbreviated terms given in
ISO 26262-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at https: //www .iso .org/obp.
4 Requirements for compliance
4.1 Purpose
This clause describes how:
a) to achieve compliance with the ISO 26262 series of standards;
b) to interpret the tables used in the ISO 26262 series of standards; and
c) to interpret the applicability of each clause, depending on the relevant ASIL(s).
4.2 General requirements
When claiming compliance with the ISO 26262 series of standards, each requirement shall be met,
unless one of the following applies:
a) tailoring of the safety activities in accordance with ISO 26262-2 has been performed that shows
that the requirement does not apply; or
b) a rationale is available that the non-compliance is acceptable and the rationale has been evaluated
in accordance with ISO 26262-2.
2 © ISO 2018 – All rights reserved

Informative content, including notes and examples, is only for guidance in understanding, or for
clarification of the associated requirement, and shall not be interpreted as a requirement itself or as
complete or exhaustive.
The results of safety activities are given as work products. “Prerequisites” are information which shall
be available as work products of a previous phase. Given that certain requirements of a clause are
ASIL-dependent or may be tailored, certain work products may not be needed as prerequisites.
“Further supporting information” is information that can be considered, but which in some cases is not
required by the ISO 26262 series of standards as a work product of a previous phase and which may be
made available by external sources that are different from the persons or organizations responsible for
the functional safety activities.
4.3 Interpretations of tables
Tables are normative or informative depending on their context. The different methods listed in a table
contribute to the level of confidence in achieving compliance with the corresponding requirement. Each
method in a table is either:
a) a consecutive entry (marked by a sequence number in the leftmost column, e.g. 1, 2, 3), or
b) an alternative entry (marked by a number followed by a letter in the leftmost column, e.g. 2a, 2b, 2c).
For consecutive entries, all listed highly recommended and recommended methods in accordance with
the ASIL apply. It is allowed to substitute a highly recommended or recommended method by others
not listed in the table, in this case, a rationale shall be given describing why these comply with the
corresponding requirement. If a rationale can be given to comply with the corresponding requirement
without choosing all entries, a further rationale for omitted methods is not necessary.
For alternative entries, an appropriate combination of methods shall be applied in accordance with the
ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with
different degrees of recommendation for an ASIL, the methods with the higher recommendation should
be preferred. A rationale shall be given that the selected combination of methods or even a selected
single method complies with the corresponding requirement.
NOTE A rationale based on the methods listed in the table is sufficient. However, this does not imply a bias
for or against methods not listed in the table.
For each method, the degree of recommendation to use the corresponding method depends on the ASIL
and is categorized as follows:
— “++” indicates that the method is highly recommended for the identified ASIL;
— “+” indicates that the method is recommended for the identified ASIL; and
— “o” indicates that the method has no recommendation for or against its usage for the identified ASIL.
4.4 ASIL-dependent requirements and recommendations
The requirements or recommendations of each sub-clause shall be met for ASIL A, B, C and D, if not
stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal.
If ASIL decomposition has been performed at an earlier stage of development, in accordance with
ISO 26262-9:2018, Clause 5, the ASIL resulting from the decomposition shall be met.
If an ASIL is given in parentheses in the ISO 26262 series of standards, the corresponding sub-clause
shall be considered as a recommendation rather than a requirement for this ASIL. This has no link with
the parenthesis notation related to ASIL decomposition.
4.5 Adaptation for motorcycles
For items or elements of motorcycles for which requirements of ISO 26262-12 are applicable,
the requirements of ISO 26262-12 supersede the corresponding requirements in this document.
Requirements of ISO 26262-2 that are superseded by ISO 26262-12 are defined in Part 12.
4.6 Adaptation for trucks, buses, trailers and semi-trailers
Content that is intended to be unique for trucks, buses, trailers and semi-trailers (T&B) is indicated
as such.
5 General topics for the product development at the software level
5.1 Objectives
The objectives of this clause are:
a) to ensure a suitable and consistent software development process; and
b) to ensure a suitable software development environment.
5.2 General
The reference phase model for the development of software is given in Figure 2. Details concerning the
treatment of configurable software are provided in Annex C.
NOTE Within the figure, the specific clauses of each part of the ISO 26262 series of standards are indicated
in the following manner: “m-n”, where “m” represents the number of the part and “n” indicates the number of the
clause, e.g. “4-7” represents ISO 26262-4:2018, Clause 7.
Figure 2 — Reference phase model for the product development at the software level
4 © ISO 2018 – All rights reserved

NOTE 1 Development approaches or methods from agile software development can also be suitable for the
development of safety-related software, but if the safety activities are tailored in this manner, ISO 26262-2:2018
6.4.5 is considered. However, agile approaches and methods cannot be used to omit safety measures or ignore
the fundamental documentation, process or safety integrity of product rigour required for the achievement of
functional safety.
EXAMPLE 1 Test Driven Development can be used to improve quality and testability of requirements.
EXAMPLE 2 Continuous integration based on an automated build system can support consistency of sub-
phases and facilitate regression tests. Such a build system typically performs code generation, compiling and
linking, static code analysis, documentation generation, testing and packaging. It allows, subject to tool chain
and tool configuration, repeatable and, after changes, comparable production of software, documentation and
test results.
NOTE 2 Cybersecurity can also be considered when developing the embedded software of a particular item,
see ISO 26262-2:2018, 5.4.2.3. In order to be able to develop software, specific topics are addressed in this clause
concerning the modelling, design and/or programming languages to be used, and the application of guidelines
and tools.
NOTE 3 Tools used for software development can include tools other than software tools.
EXAMPLE 3 Tools used for testing phases.
5.3 Inputs to this clause
5.3.1 Prerequisites
The following information shall be available:
— (none)
5.3.2 Further supporting information
The following information can be considered:
— qualified software tools available (see ISO 26262-8:2018, Clause 11);
— design and coding guidelines for modelling, design and programming languages (from an external
source);
— guidelines for the application of methods (from an external source); and
— guidelines for the application of tools (from an external source).
5.4 Requirements and recommendations
5.4.1 When developing the software of an item, software development processes and software
development environments shall be used which:
a) are suitable for developing safety-related embedded software, including methods, guidelines,
languages and tools;
b) support consistency across the sub-phases of the software development lifecycle and the respective
work products; and
c) are compatible with the system and hardware development phases regarding required interaction
and consistency of exchange of information.
NOTE 1 The sequencing of phases, tasks and activities, including iteration steps, for the software of an item
intends to ensure the consistency of the corresponding work products with the product development at the
hardware level (see ISO 26262-5) and the product development at the system level (see ISO 26262-4).
NOTE 2 The software tool criteria evaluation report (see ISO 26262-8:2018, 11.5.1) or the software tool
qualification report (see ISO 26262-8:2018, 11.5.2) can provide input to the tool usage.
5.4.2 The criteria that shall be considered when selecting a design, modelling or programming
language are:
a) an unambiguous and comprehensible definition;
EXAMPLE Unambiguous definition of syntax and semantics or restriction to configuration of the
development environment.
b) suitability for specifying and managing safety requirements according to ISO 26262-8:2018
Clause 6, if modelling is used for requirements engineering and management;
c) support the achievement of modularity, abstraction and encapsulation; and
d) support the use of structured constructs.
NOTE Assembly languages can be used for those parts of the software where the use of high-level
programming languages is not appropriate, such as low-level software with interfaces to the hardware, interrupt
handlers, or time-critical algorithms. However using assembly languages can require a suitable application or
tailoring of all software development phases (e.g. requirements of Clause 8).
5.4.3 Criteria for suitable modelling, design or programming languages (see 5.4.2) that are not
sufficiently addressed by the language itself shall be covered by the corresponding guidelines, or by the
development environment, considering the topics listed in Table 1.
EXAMPLE 1 MISRA C (see Reference [3]) is a coding guideline for the programming language C and includes
guidance for automatically generated code.
EXAMPLE 2 In the case of model based development with automatic code generation, guidelines can be applied
at the model level as well as the code level. Appropriate modelling style guides including the MISRA AC series can
be considered. Style guides for commercial tools are also possible guidelines.
NOTE Existing coding guidelines and modelling guidelines can be modified for a specific item development.
6 © ISO 2018 – All rights reserved

Table 1 — Topics to be covered by modelling and coding guidelines
ASIL
Topics
A B C D
a
1a Enforcement of low complexity ++ ++ ++ ++
b
1b Use of language subsets ++ ++ ++ ++
c
1c Enforcement of strong typing ++ ++ ++ ++
d
1d Use of defensive implementation techniques + + ++ ++
e
1e Use of well-trusted design principles + + ++ ++
1f Use of unambiguous graphical representation + ++ ++ ++
1g Use of style guides + ++ ++ ++
1h Use of naming conventions ++ ++ ++ ++
f
1i Concurrency aspects + + + +
a
An appropriate compromise of this topic with other requirements of this document may be required.
b
The objectives of topic 1b include:
— Exclusion of ambiguously-defined language constructs which may be interpreted differently by different modellers,
programmers, code generators or compilers.
— Exclusion of language constructs which from experience easily lead to mistakes, for example assignments in
conditions or identical naming of local and global variables.
— Exclusion of language constructs which could result in unhandled run-time errors.
c
The objective of topic 1c is to impose principles of strong typing where these are not inherent in the language.
d
Examples of defensive implementation techniques:
— Verify the divisor before a division operation (different from zero or in a specific range).
— Check an identifier passed by parameter to verify that the calling function is the intended caller.
— Use the “default” in switch cases to detect an error.
e
Verification of the validity of the underlying assumptions, boundaries and conditions of application may be required.
f
Concurrency of processes or tasks is not limited to executing software in a multi-core or multi-processor runtime
environment.
5.5 Work products
5.5.1 Documentation of the software development environment resulting from requirements 5.4.1
to 5.4.3 and C.4.1 to C.4.11.
6 Specification of software safety requirements
6.1 Objectives
The objectives of this sub-phase are:
a) to specify or refine the software safety requirements which are derived from the technical safety
concept and the system architectural design specification;
b) to define the safety-related functionalities and properties of the software required for the
implementation;
c) to refine the requirements of the hardware-software interface initiated in ISO 26262-4:2018,
Clause 6; and
d) to verify that the software safety requirements and the hardware-software interface requirements
are suitable for software development and are consistent with the technical safety concept and the
system architectural design specification.
6.2 General
The technical safety requirements are refined and allocated to hardware and software during
the system architectural design phase given in ISO 26262-4:2018, Clause 6. The specification of the
software safety requirements considers in particular constraints of the hardware and the impact
of these constraints on the software. This sub-phase includes the specification of software safety
requirements to support the subsequent design phases.
6.3 Inputs to this clause
6.3.1 Prerequisites
The following information shall be available:
— technical safety requirements specification in accordance with ISO 26262-4:2018, 6.5.1;
— technical safety concept in accordance with ISO 26262-4:2018, 6.5.2;
— system architectural design specification in accordance with ISO 26262-4:2018, 6.5.3;
— hardware-software interface (HSI) specification in accordance with ISO 26262-4:2018, 6.5.4; and
— documentation of the software development environment in accordance with 5.5.1.
6.3.2 Further supporting information
The following information can be considered:
— hardware design specification (see ISO 26262-5:2018, 7.5.1); and
— specification of non-safety-related functions and properties of the software (from an external
source).
6.4 Requirements and recommendations
6.4.1 The software safety requirements shall be derived considering the required safety-related
functionalities and properties of the software, whose failures could lead to the violation of a technical
safety requirement allocated to software.
NOTE 1 The software safety requirements are either derived directly from the technical safety requirements
allocated to software or are requirements for software functions and properties that, if not fulfilled, could lead
to a violation of the technical safety requirements allocated to software.
EXAMPLE 1 Safety-related functionality of the software can be:
— functions that enable the safe execution of a nominal function;
— functions that enable the system to achieve or maintain a safe state or degraded state;
— functions related to the detection, indication and mitigation of faults of safety-related hardware elements;
— self-test or monitoring functions related to the detection, indication and mitigation of failures in the
operating system, basic software or the application software itself;
— functions related to on-board and off-board tests during production, operation, service and
decommissioning;
— functions that allow modifications of the software during production and service; or
— functions related to performance or time-critical operations.
8 © ISO 2018 – All rights reserved

EXAMPLE 2 Safety-related properties include robustness against erroneous inputs, independence or freedom
from interference between different functionalities, or fault tolerance capabilities of the software.
NOTE 2 Safety-oriented analyses (see 7.4.10 or 7.4.11) can be used to identify additional software safety
requirements or provide evidence for their achievement.
6.4.2 Specification of the software safety requirements derived from the technical safety requirements,
the technical safety concept and the system architectural design in accordance with ISO 26262-4:2018,
6.4.1 and 6.4.3 shall consider:
a) the specification and management of safety requirements in accordance with ISO 26262-8:2018,
Clause 6;
b) the specified system and hardware configurations;
EXAMPLE 1 Configuration parameters can include gain control, band pass frequency and clock prescaler.
c) the hardware-software interface specification;
d) the relevant requirements of the hardware design specification;
e) the timing constraints;
EXAMPLE 2 Execution or reaction time derived from the required response time at the system level.
f) the external interfaces; and
EXAMPLE 3 Communication and user interfaces.
g) each operating mode and each transition between the operating modes of the vehicle, the system,
or the hardware, having an impact on the software.
EXAMPLE 4 Operating modes include shut-off or sleep, initialization, normal operation, degraded and
...