ISO 19014-4:2020
(Main)Earth-moving machinery — Functional safety — Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system
Earth-moving machinery — Functional safety — Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system
This document specifies general principles for software development and signal transmission requirements of safety-related parts of machine-control systems (MCS) in earth-moving machinery (EMM) and its equipment, as defined in ISO 6165. In addition, this document addresses the significant hazards as defined in ISO 12100 related to the software embedded within the machine control system. The significant hazards being addressed are the incorrect machine control system output responses from machine control system inputs. Cyber security is out of the scope of this document. NOTE For guidance on cybersecurity, see an appropriate security standard. This document is not applicable to EMM manufactured before the date of its publication.
Engins de terrassement — Sécurité fonctionnelle — Partie 4: Conception et évaluation du logiciel et de la transmission des données pour les parties relatives à la sécurité du système de commande
Le présent document spécifie les principes généraux applicables aux exigences en matière de développement de logiciel et de transmission des signaux des parties relatives à la sécurité des systèmes de commande de la machine (MCS) dans les engins de terrassement et leur équipement tels que définis dans l'ISO 6165. De plus, le présent document traite des phénomènes dangereux significatifs tels que définis dans l'ISO 12100 en rapport avec les logiciels intégrés dans le système de commande de la machine. Les phénomènes dangereux significatifs traités sont les réponses incorrectes du système de commande de la machine aux entrées du système de commande de la machine. La cybersécurité n'est pas couverte par le présent document. NOTE Voir une norme appropriée relative à la sécurité pour des recommandations à propos de la cybersécurité. Le présent document n'est pas applicable aux engins de terrassement fabriqués avant la date de sa publication.
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19014-4
First edition
2020-07
Earth-moving machinery —
Functional safety —
Part 4:
Design and evaluation of software and
data transmission for safety-related
parts of the control system
Engins de terrassement — Sécurité fonctionnelle —
Partie 4: Conception et évaluation du logiciel et de la transmission
des données pour les parties relatives à la sécurité du système de
commande
Reference number
ISO 19014-4:2020(E)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO 19014-4:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2020
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 19014-4:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Software development . 4
4.1 General . 4
4.2 Planning . 5
4.3 Artifacts . 6
4.4 Software safety requirements specification . 7
4.5 Software architecture design . 8
4.6 Software module design and coding . 8
4.7 Language and tool selection . 9
4.8 Software module testing .10
4.9 Software module integration and testing .11
4.10 Software validation .12
5 Software-based parameterization .12
5.1 General .12
5.2 Data integrity .13
5.3 Software-based parameterization verification .13
6 Transmission protection of safety-related messages on bus systems .13
7 Independence by software partitioning .14
7.1 General .14
7.2 Several partitions within a single microcontroller .15
7.3 Several partitions within the scope of an ECU network .16
8 Information for use .17
8.1 General .17
8.2 Instruction handbook .17
Annex A (informative) Description of software methods/measures .18
Annex B (normative) Software validation test environments .31
Annex C (informative) Data integrity assurance calculation.34
Annex D (informative) Methods and measures for transmission protection .36
Annex E (informative) Methods and measures for data protection internal to microcontroller .38
Bibliography .40
© ISO 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 19014-4:2020(E)
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 of 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 www .iso .org/
iso/ foreword .html.
This document was prepared by ISO/TC 127, Earth-moving machinery, Subcommittee SC 2, Safety,
ergonomics and general requirements, in collaboration with the European Committee for Standardization
(CEN) Technical Committee CEN/TC 151, Construction equipment and building material machines - Safety,
in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This first edition of ISO 19014-4, together with other parts in the ISO 19014 series, cancels and replaces
ISO 15998:2008 and ISO/TS 15998-2:2012, which have been technically revised.
The main changes compared to the previous documents are as follows:
— additional requirements for software development,
— requirements for software-based parametrization development,
— requirements for transmission of safety related messages on a communication bus, and
— requirements for software validation and verification of machine performance levels.
A list of all parts in the ISO 19014 series can be found on the ISO website.
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.
iv © ISO 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 19014-4:2020(E)
Introduction
This document addresses systems comprising any combination of electrical, electronic, and
programmable electronic components [electrical/electronic/programmable electronic systems (E/E/
PES)] used for functional safety in earth-moving machinery.
The structure of safety standards in the field of machinery is as follows.
Type-A standards (basis standards) give basic concepts, principles for design, and general aspects that
can be applied to machinery.
Type-B standards (generic safety standards) deal with one or more safety aspect(s), or one or more
type(s) of safeguards that can be used across a wide range of machinery:
— type-B1 standards on particular safety aspects (e.g. safety distances, surface temperature, noise);
— type-B2 standards on safeguards (e.g. two-hands controls, interlocking devices, pressure sensitive
devices, guards).
Type-C standards (machinery safety standards) deal with detailed safety requirements for a particular
machine or group of machines.
This document is a type-C standard as stated in ISO 12100.
This document is of relevance, in particular, for the following stakeholder groups representing the
market players with regard to machinery safety:
— machine manufacturers (small, medium, and large enterprises);
— health and safety bodies (regulators, accident prevention organisations, market surveillance etc.).
Others can be affected by the level of machinery safety achieved with the means of the document by the
above-mentioned stakeholder groups:
— machine users/employers (small, medium, and large enterprises);
— machine users/employees (e.g. trade unions, organizations for people with special needs);
— service providers, e. g. for maintenance (small, medium, and large enterprises);
The above-mentioned stakeholder groups have been given the possibility to participate at the drafting
process of this document.
The machinery concerned and the extent to which hazards, hazardous situations, or hazardous events
are covered are indicated in the Scope of this document.
When requirements of this type-C standard are different from those which are stated in type-A or
type-B standards, the requirements of this type-C standard take precedence over the requirements of
the other standards for machines that have been designed and built according to the requirements of
this type-C standard.
© ISO 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 19014-4:2020(E)
Earth-moving machinery — Functional safety —
Part 4:
Design and evaluation of software and data transmission
for safety-related parts of the control system
1 Scope
This document specifies general principles for software development and signal transmission
requirements of safety-related parts of machine-control systems (MCS) in earth-moving machinery
(EMM) and its equipment, as defined in ISO 6165. In addition, this document addresses the significant
hazards as defined in ISO 12100 related to the software embedded within the machine control system.
The significant hazards being addressed are the incorrect machine control system output responses
from machine control system inputs.
Cyber security is out of the scope of this document.
NOTE For guidance on cybersecurity, see an appropriate security standard.
This document is not applicable to EMM manufactured before the date of its publication.
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 6750-1, Earth-moving machinery — Operator's manual — Part 1: Contents and format
ISO 12100:2010, Safety of machinery — General principles for design — Risk assessment and risk reduction
ISO 13849-1, Safety of machinery — Safety-related parts of control systems — Part 1: General principles
for design
ISO 19014-1, Earth-moving machinery — Functional safety — Part 1: Methodology to determine safety-
related parts of the control system and performance requirements
1)
ISO 19014-2:— , Earth-moving machinery — Functional safety — Part 2: Design and evaluation of
hardware and architecture requirements for safety-related parts of the control system
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 12100, ISO 19014-1, ISO 13849-1
and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
1) Under preparation. Stage at the time of publication: ISO/DIS 19014-2:2020.
© ISO 2020 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 19014-4:2020(E)
3.1
bus system
subsystem used in an electronic control system for the transmission of messages (3.6)
Note 1 to entry: The bus system consists of the system unit (sources and sinks of information), a transmission
path/transmission medium (e.g. electrical lines, fiber-optical lines, radio frequency transmission) and the
interface between message source/sink and bus electronics (e.g. protocol application specific integrated circuit,
transceivers).
3.2
encapsulated bus system
bus system (3.1) comprising a fixed number or a predetermined maximum number of bus participants
connected to each other through a transmission medium with well-defined and fixed performance/
characteristics
3.3
failure of peer communication
situation in which the communication peer is not available
3.4
unintended message repetition
situation in which the same message (3.6) is unintentionally sent again
3.5
message repetition
situation in which the same message (3.6) is intentionally sent again
Note 1 to entry: This technique of resending the same message addresses failures such as message loss (3.10).
3.6
message
electronic transmission of data
Note 1 to entry: Transmitted data can include user data, address, or identifier data and data to ensure
transmission integrity.
3.7
ECU
electronic control unit
electronic device (electronic programmable controller) used in a control system on earth-moving
machinery
[SOURCE: ISO 22448:2010, 3.3, modified — The admitted terms "ECM" and "electronic control module"
have been removed.]
3.8
reaction time
time from the detection of a safety-related event until the initiation of a safety reaction
3.9
artifact
work products that are produced and used during a project to capture and convey information
3.10
message loss
unintended deletion of a message (3.6) due to a fault of a bus participant
2 © ISO 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 19014-4:2020(E)
3.11
incorrect sequence
unintended modification of the sequence of messages (3.6) due to a fault of a bus participant
Note 1 to entry: Bus systems (3.1) can contain elements with stored messages (first-in, first-out (FIFOs), etc.) that
can modify the correct sequence.
3.12
message falsification
unintended modification of messages (3.6) due to an error of a bus participant or due to errors on the
transmission channel
3.13
message retardation
unintended delay or prevention of the safety function, caused by an overload of the transmission path
by normal data exchange or by sending incorrect messages (3.6)
3.14
alive counter
accounting component initialised with “0” when the object to be monitored is created or restored
Note 1 to entry: The counter increases from time t–1 to time t as long as the object is alive. Finally, the alive
counter shows the period of time for which the object has been alive within a network.
3.15
black box testing
testing of an object that does not require knowledge of its internal structure or its concrete
implementation
3.16
partition
resource entity allocating a portion of memory, input/output devices, and central processing unit usage
to one or more system tasks (3.21)
Note 1 to entry: The partitions can be assigned to one or more subsystems within the microcontroller network.
3.17
software partitioning
software fault (3.26) containment method consisting of assigning resources to specific software
components with the intention of avoiding the propagation of a software fault to multiple partitions (3.16)
3.18
software component
one or more software modules (3.19)
[SOURCE: ISO 26262-1:2018, 3.157, modified — The word "units" has been replaced with "modules".]
3.19
software module
independent piece of software that can be independently tested and traced to a specification
Note 1 to entry: The software module is an indivisible software component.
3.20
software partitions
runtime environment with separate system resources assigned
3.21
system task
runtime entities that are executed within the resource budget of partitions (3.16) and with different
priorities
© ISO 2020 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 19014-4:2020(E)
3.22
independence of software
exclusion of unintended interactions between software components, as well as freedom from impact on
the correct operation of a software component resulting from errors of another software component
3.23
operational history
operating data about a software component or a software module (3.19) during its time in service
3.24
maximum cycle time
static time to access a communication bus between nodes at a bus or node level
Note 1 to entry: The application of a time-triggered protocol ensures this cycle time is not exceeded.
3.25
maximum response time
fixed time assigned to a system activity to exchange globally-synchronised messages (3.6) on a bus in a
time-triggered architecture
3.26
software fault
incorrect step, process, or data definition in software which causes the system to produce
unexpected results
3.27
impact analysis
documentation that records the understanding and implications of a proposed change
3.28
configuration management process
task of tracking and controlling changes to the artifacts (3.9) in the development process
3.29
constant transmission of messages
situation in which the faulty node continually transmits messages (3.6) that compromises the operation
of the bus
3.30
blocking access to the data bus
situation in which the faulty node does not adhere to the expected patterns of use and makes excessive
demands of service, thereby reducing its availability to other nodes
4 Software development
4.1 General
The main objective of the following requirements is to achieve software reliability by means of
readable, understandable, testable, and maintainable software. This clause gives recommendations for
the design of software and the subsequent related testing. The avoidance of software faults shall be
considered during the entire software development process.
Where an existing software component has been developed to a previous standard and demonstrated
through application usage and validation to reduce the risk to as low as reasonably practicable, there
shall be no requirement to update the software life cycle documentation at the software module level.
Machine control software shall comply with the safety requirements of this clause. In addition, the
machine control software shall be designed and developed according to the principles of ISO 12100:2010
for relevant but not significant hazards which are not dealt with by this document.
4 © ISO 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 19014-4:2020(E)
4.2 Planning
A plan shall be developed to define the relationship between the individual phases of the software
development and the related artifacts.
Appropriate methods and measures from Table 3 through Table 9 shall be selected for software
development according to the machine performance level required (MPLr).
The MPLr of the system may be achieved by adding, in parallel, two systems of a lower performance
level. When adding in parallel (according to ISO 19014-2), the software can be developed in each system
to the lower MPLr requirements. This is only allowable when there are no common cause failures
between the two systems.
The suitability of the selected methods or measures to the application shall be justified and shall be
made at the beginning of each planned development phase. For a particular application, the appropriate
combination of methods or measures shall be stated during development planning. Methods or
measures not listed in Table 3 through Table 9 may be used.
Figure 1 — Software development V-model
Figure 1 is a representation of one possible design method (V-model). Any organized, proven
development process that meets the requirements of this document may be used for the software
development.
When selecting methods and measures, in addition to manual coding, model-based development may
be applied where the source code is automatically generated from models.
With each method or measure in the tables, there is a different level of provision for each performance
level. Table 1 indicates the requirements.
Table 1 — Software safety requirements specification
Symbol Software safety requirements specification
+ The method or measure shall be used for this MPLr.
In case this method or measure is not used, the related rationale shall be documented during the
safety planning phase.
o The method or measure may be used for this MPLr.
– The method or measure is not suitable to meet this MPLr.
© ISO 2020 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 19014-4:2020(E)
Methods and measures corresponding to the respective MPLr shall be selected. Alternative or
equivalent methods and measures are identified by letters after the number. At least one of the
alternatives or equivalent methods and measures marked with a “+” shall be selected, in which case,
providing a rationale is not required. An example of this is Table 2.
Table 2 — Example software safety requirements specification
Method/measure MPLr = a MPLr = b, c MPLr = d MPLr = e
1.a Measure 1 + + – –
1.b Measure 2 + + + +
1.c Measure 3 + + + +
In this case,
— one measure from Measure 1, Measure2 or Measure 3 shall be fulfilled for MPLr = a, b, c;
— one measure from Measure2 or Measure 3 shall be fulfilled for MPLr = d, e;
— otherwise, a rationale shall be provided about the unspecified alternative method/measure to
satisfy the requirement of the standard for the specific MPLr.
Rationale or justification shall be provided if other equivalent methods or measures are used instead of
the listed methods or measures.
If a software component has any impact on different safety functions with a different MPLr, then the
requirements related to the highest MPLr shall apply.
If the software contains safety-related and non-safety-related components, then the overall embedded
software machine performance level achieved (MPLa) shall be limited to the software component with
the lowest MPLa; this requirement does not apply when adequate independence between the software
components can be demonstrated in accordance with Clause 7.
When reusing a software component that is intended to be modified, an impact analysis shall be
performed. An action plan shall be developed and implemented for the overall software life cycle, based
on the result of the impact analysis, to ensure that the safety goals are met.
4.3 Artifacts
Once the individual phases of software development plan have been determined, the artifacts shall be
defined for each phase to be carried out. Other phases and related artifacts can be added by distributing
the activities and tasks. Taking into account the extent and complexity of the project, all artifacts in the
individual phases shown in Figure 1 may be modified.
NOTE It is common to combine individual phases if the method/measure used makes it difficult to clearly
distinguish between the phases. For example, the design of the software architecture and the software
implementation can be generated successively with the same computer-aided development tool, as is done in the
model-based development process.
As part of the software development process, the artifacts shall be:
a) documented according to the outcomes expected from the planned phases;
b) modified as a consequence of an impact analysis, and only the impacted software shall be
regression tested;
c) subject to a configuration management process.
6 © ISO 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 19014-4:2020(E)
The first artifact applicable to the process is the software development plan. The subsequent artifacts,
defined by the plan, shall include:
— design specification and related verification report, for each software design phase (descending
branch of the V-model in Figure 1);
— test specification and related test report, for each software (SW) testing phase (rising branch of the
V-model in Figure 1);
— executable software.
4.4 Software safety requirements specification
The software safety requirements specification shall describe requirements for the following, if
relevant:
— functions that enable the system to achieve or maintain a safe state;
— functions related to the detection, indication, and handling of faults by the safety-related parts of
control systems (SRP/CS);
— functions related to the detection, indication, and handling of faults in the software;
— functions related to the online and offline tests of the safety functions;
NOTE 1 An online test is performed while the system being tested is in use. An offline test is performed
while the system being tested is not in use.
NOTE 2 An example of an online test would be checking for faults in the steering system while driving the
machine. An example of an offline test would be checking for faults in the steering system prior to allowing
machine movement.
— functions that allow modifications of safety-related software parameters;
— interfaces with functions that are not safety-related;
— performance and response time;
— interfaces between the software and the hardware of the electronic control unit.
Appropriate method or measures shall be selected from Table 3 to meet the specified MPLr.
Table 3 — Software safety requirements specification
Method/measure Reference MPLr MPLr MPLr MPLr
= a = b, c = d = e
1. Requirements specification in natural language A.1 + + + +
2. Computer aided specification tools A.2 o o o +
3.a Informal methods A.3 + + + –
3.b Semi-formal methods A.4 + + + +
3.c Formal methods A.5 + + + +
4. Forward traceability between the system safety re- o o o +
quirements and the software safety requirements
A.6
5. Backward traceability between the software safety o o o +
requirements and the system safety require
...
NORME ISO
INTERNATIONALE 19014-4
Première édition
2020-07
Engins de terrassement — Sécurité
fonctionnelle —
Partie 4:
Conception et évaluation du logiciel et
de la transmission des données pour
les parties relatives à la sécurité du
système de commande
Earth-moving machinery — Functional safety —
Part 4: Design and evaluation of software and data transmission for
safety-related parts of the control system
Numéro de référence
ISO 19014-4:2020(F)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO 19014-4:2020(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 19014-4:2020(F)
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Développement de logiciel . 4
4.1 Généralités . 4
4.2 Planification . 5
4.3 Artefacts . 6
4.4 Spécification des exigences relatives à la sécurité du logiciel . 7
4.5 Conception de l’architecture du logiciel . 8
4.6 Conception et codage des modules logiciels . 8
4.7 Choix du langage et des outils . 9
4.8 Essais des modules logiciels .10
4.9 Intégration et essais des modules logiciels .11
4.10 Validation du logiciel .12
5 Paramétrage fondé sur le logiciel .13
5.1 Généralités .13
5.2 Intégrité des données .13
5.3 Vérification du paramétrage fondé sur le logiciel .13
6 Protection de la transmission de messages relatifs à la sécurité sur les systèmes bus .14
7 Indépendance par partitionnement du logiciel .15
7.1 Généralités .15
7.2 Plusieurs partitions dans un microcontrôleur unique .16
7.3 Plusieurs partitions dans le domaine d’application d’un réseau d’UCE .17
8 Informations pour l’utilisation .18
8.1 Généralités .18
8.2 Notice d’instructions .18
Annexe A (informative) Description des méthodes/mesures du logiciel .19
Annexe B (normative) Environnements d’essais de validation d’un logiciel .33
Annexe C (informative) Calcul de l’assurance d’intégrité des données .36
Annexe D (informative) Méthodes et mesures de protection de la transmission .38
Annexe E (informative) Méthodes et mesures de protection des données internes au
microcontrôleur .40
Bibliographie .42
© ISO 2020 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 19014-4:2020(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/ directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/ brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 127 Engins de terrassement, sous-
comité SC 2 Sécurité, ergonomie et exigences générales en collaboration avec le Comité européen
de Normalisation (CEN) Comité Technique CEN/TC 151, Machines de génie civil et de production de
matériaux de construction – Sécurité, selon avec l’Accord de coopération entre l’ISO et le CEN (Accord de
Vienne).
Cette première édition de l’ISO 19014-4, conjointement avec les autres parties de la série ISO 19014,
annule et remplace l’ISO 15998:2008 et l’ISO/TS 15998-2:2012 qui ont fait l’objet d’une révision
technique.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— les exigences supplémentaires pour le développement de logiciel,
— les exigences pour le développement du paramétrage fondé sur le logiciel,
— les exigences pour la transmission de messages relatifs à la sécurité sur un bus de communication et
— les exigences pour la validation du logiciel et la vérification des niveaux de performance de la
machine.
Une liste de toutes les parties de la série ISO 19014 peut être trouvée sur le site internet de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ members .html.
iv © ISO 2020 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 19014-4:2020(F)
Introduction
Le présent document établit des recommandations pour les systèmes combinés de composants
électriques, électroniques et électroniques programmables [systèmes électriques/électroniques/
électroniques programmables (E/E/PES)] qui sont utilisés pour la sécurité fonctionnelle dans les
engins de terrassement.
La structure des normes de sécurité dans le domaine des machines est la suivante.
Les normes de type A (normes fondamentales de sécurité), contiennent des notions fondamentales, des
principes de conception et des aspects généraux relatifs aux machines.
Les normes de type B (normes génériques de sécurité) traitent d’un ou de plusieurs aspects de la
sécurité ou d’un ou de plusieurs types de moyens de protection valables pour une large gamme de
machines:
— normes de type B1, traitant d’aspects particuliers de la sécurité (par exemple distances de sécurité,
température superficielle, bruit);
— normes de type B2, traitant de moyens de protection (par exemple commandes bimanuelles,
dispositifs de verrouillage, dispositifs sensibles à la pression, protecteurs).
Les normes de type C (normes de sécurité par catégorie de machines) traitent des exigences de sécurité
détaillées s’appliquant à une machine particulière ou à un groupe de machines particulier.
Le présent document est une norme de type C telle que définie dans l’ISO 12100.
Le présent document est notamment pertinent pour les groupes de parties prenantes suivants
représentant les acteurs du marché pour ce qui concerne la sécurité des machines:
— fabricants de machines (petites, moyennes et grandes entreprises);
— organismes de santé et de sécurité (autorités réglementaires, organismes de prévention des risques
professionnels, surveillance du marché, etc.)
D’autres peuvent être affectés par le niveau de sécurité des machines obtenu au moyen du document
par les groupes de parties prenantes mentionnés ci-dessus:
— utilisateurs de machines/employeurs (petites, moyennes et grandes entreprises);
— utilisateurs de machines/salariés (par exemple syndicats de salariés, organisations représentant
des personnes ayant des besoins particuliers);
— prestataires de services, par exemple sociétés de maintenance (petites, moyennes et grandes
entreprises);
Les groupes de parties prenantes mentionnés ci-dessus ont eu la possibilité de participer à l’élaboration
du présent document.
Les machines concernées et l’étendue des phénomènes dangereux, situations dangereuses ou
événements dangereux couverts sont indiquées dans le Domaine d’application du présent document.
Lorsque des exigences de la présente norme de type C sont différentes de celles énoncées dans les
normes de type A ou les normes de type B, les exigences de la présente norme de type C ont priorité
sur celles des autres normes pour les machines ayant été conçues et fabriquées conformément aux
exigences de la présente norme de type C.
© ISO 2020 – Tous droits réservés v
---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 19014-4:2020(F)
Engins de terrassement — Sécurité fonctionnelle —
Partie 4:
Conception et évaluation du logiciel et de la transmission
des données pour les parties relatives à la sécurité du
système de commande
1 Domaine d'application
Le présent document spécifie les principes généraux applicables aux exigences en matière de
développement de logiciel et de transmission des signaux des parties relatives à la sécurité des
systèmes de commande de la machine (MCS) dans les engins de terrassement et leur équipement tels
que définis dans l’ISO 6165. De plus, le présent document traite des phénomènes dangereux significatifs
tels que définis dans l’ISO 12100 en rapport avec les logiciels intégrés dans le système de commande de
la machine. Les phénomènes dangereux significatifs traités sont les réponses incorrectes du système de
commande de la machine aux entrées du système de commande de la machine.
La cybersécurité n’est pas couverte par le présent document.
NOTE Voir une norme appropriée relative à la sécurité pour des recommandations à propos de la
cybersécurité.
Le présent document n’est pas applicable aux engins de terrassement fabriqués avant la date de sa
publication.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 6750-1, Engins de terrassement — Manuel de l'opérateur — Partie 1: Présentation et contenu
ISO 12100:2010, Sécurité des machines — Principes généraux de conception — Appréciation du risque et
réduction du risque
ISO 13849-1, Sécurité des machines — Parties des systèmes de commande relatives à la sécurité — Partie 1:
Principes généraux de conception
ISO 19014-1, Engins de terrassement — Sécurité fonctionnelle — Partie 1: Méthodologie pour la
détermination des parties relatives à la sécurité des systèmes de commande et les exigences de performance
1)
ISO 19014-2:—, Engins de terrassement — Sécurité fonctionnelle — Partie 2: Conception et évaluation
des exigences de matériel et d’architecture pour les parties relatives à la sécurité du système de commande
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l’ISO 12100, ISO 19014-1,
l’ISO 13849-1 ainsi que les suivants s’appliquent.
1) En préparation. Stade au moment de la publication: ISO/DIS 19014-2:2020.
© ISO 2020 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO 19014-4:2020(F)
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
3.1
système bus
sous-système utilisé dans un système de commande électronique pour la transmission de messages (3.6)
Note 1 à l'article: Le système bus se compose de l’unité système (sources et récepteurs d’information), d’un trajet
de transmission/support de transmission (par exemple des lignes électriques, des lignes en fibres optiques,
transmission par radio fréquence) et de l’interface entre la source/le récepteur de message et l’électronique de
bus (par exemple, circuit intégré à application spécifique de protocole, émetteurs-récepteurs).
3.2
système bus encapsulé
système bus (3.1) comprenant un nombre fixe ou un nombre maximal prédéterminé des nœuds du bus qui
sont connectés l’un à l’autre par un support de transmission ayant des performances/caractéristiques
bien définies et fixes
3.3
défaillance de l’homologue de communication
situation dans laquelle l’homologue de communication n’est pas disponible
3.4
répétition de message non prévue
situation dans laquelle le même message (3.6) est renvoyé de manière accidentelle
3.5
répétition de message
situation dans laquelle le même message (3.6) est renvoyé intentionnellement
Note 1 à l'article: Cette technique de renvoi du même message permet de remédier à des défaillances telles que la
perte du message (3.10).
3.6
message
transmission électronique de données
Note 1 à l'article: Les données transmises peuvent comprendre des données d’utilisateur, une adresse ou des
données d’identificateur et des données pour assurer l’intégrité de la transmission
3.7
ECU
unité de commande électronique
dispositif électronique (dispositif de commande électronique programmable) utilisé dans un système
de commande sur des engins de terrassement
[SOURCE: ISO 22448:2010, 3.3, modifiée — Les termes admis «ECM» et “module de commande
électronique” ont été supprimés.]
3.8
temps de réaction
délai entre la détection d’un événement relatif à la sécurité et l’initiation d’une réaction de sécurité
3.9
artefact
produits du travail qui sont produits et utilisés au cours d’un projet pour capturer et transmettre des
informations
2 © ISO 2020 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 19014-4:2020(F)
3.10
perte de message
suppression imprévue d’un message (3.6) en raison d’un défaut d’un nœud du bus
3.11
séquence incorrecte
modification imprévue d’une séquence de message (3.6) en raison d’une défaillance d’un nœud du bus
Note 1 à l'article: Les systèmes bus (3.1) peuvent contenir des éléments avec des messages stockés (premier entré,
premier sorti (FIFO), etc.) qui peuvent modifier la séquence correcte.
3.12
déformation de message
modification imprévue d’un message (3.6) en raison d’une erreur d’un nœud du bus ou en raison
d’erreurs sur le canal de transmission
3.13
retard de message
délai imprévu ou prévention de la fonction de sécurité, causés par une surcharge du trajet de
transmission par l’échange normal de données ou l’envoi de messages (3.6) incorrects
3.14
compteur de maintien en activité
composant de comptage initialisé à «0» lorsque l’objet à surveiller est créé ou restauré
Note 1 à l'article: Le compteur incrémente du temps t–1 au temps t tant que l’objet est en activité. Finalement, le
compteur de maintien en activité indique la durée pendant laquelle l’objet a été en activité au sein d’un réseau.
3.15
essai à la boîte noire
essai d’un objet qui n’exige pas de connaître sa structure interne ou sa mise en œuvre concrète
3.16
partition
entité de ressource attribuant une portion de la mémoire, des dispositifs d’entrée/sortie et de
l’utilisation d’une unité centrale à une ou plusieurs tâches du système (3.21)
Note 1 à l'article: Les partitions peuvent être assignées à un ou plusieurs sous-systèmes du réseau de
microcontrôleurs.
3.17
partitionnement de logiciel
méthode de confinement d’un défaut logiciel (3.26) qui consiste à assigner des ressources à des
composants de logiciel spécifiques dans le but d’éviter la propagation du défaut logiciel à plusieurs
partitions (3.16)
3.18
composant de logiciel
un ou plusieurs modules logiciels (3.19)
[SOURCE: ISO 26262-1:2018, 3.157, modifié — Le terme «unités» a été remplacé par «modules».]
3.19
module logiciel
partie indépendante d’un logiciel qui peut être soumise à l’essai de manière indépendante et suivie en
fonction d’une spécification
Note 1 à l'article: Le module logiciel est un composant de logiciel indivisible.
3.20
partitions de logiciel
environnement d’exécution auquel sont assignées des ressources système distinctes
© ISO 2020 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO 19014-4:2020(F)
3.21
tâche système
entités d’exécution qui sont exécutées dans le cadre du budget de ressources des partitions (3.16) et
avec des priorités différentes
3.22
indépendance de logiciel
exclusion des interactions non prévues entre les composants de logiciel, ainsi qu’absence d’impact sur le
fonctionnement correct d’un composant de logiciel résultant d’erreurs d’un autre composant de logiciel
3.23
historique de fonctionnement
données relatives au fonctionnement d’un composant ou d’un module logiciel (3.19) pendant sa durée
de service
3.24
temps de cycle maximal
temps statique pour accéder à un bus de communication entre nœuds au niveau d’un bus ou d’un nœud
Note 1 à l'article: L’application d’un protocole «TTP» (time-triggered protocol ou à déclenchement temporel)
permet de s’assurer que ce temps de cycle n’est pas dépassé.
3.25
temps de réponse maximal
temps fixe assigné à une activité système pour échanger des messages (3.6) synchronisés globalement
sur un bus dans une architecture de type «à déclenchement temporel»
3.26
défaut logiciel
étape, processus ou définition de données incorrect(e) dans un logiciel qui amène le système à produire
des résultats inattendus
3.27
analyse d’impact
documentation qui contient des renseignements sur la signification et les répercussions d’une
modification proposée
3.28
processus de gestion de la configuration
tâche qui consiste à suivre et à contrôler les changements apportés aux artefacts (3.9) dans le processus
de développement
3.29
transmission constante de messages
situation dans laquelle le nœud défectueux transmet continuellement des messages (3.6) qui
compromettent le fonctionnement du bus
3.30
blocage d’accès au bus de données
situation dans laquelle le nœud défectueux ne respecte pas les schémas d’utilisation prévus et engendre
un trop grand nombre de demandes de service, réduisant ainsi sa disponibilité pour d’autres nœuds
4 Développement de logiciel
4.1 Généralités
Le principal objectif des exigences détaillées ci-dessous est d’obtenir un logiciel fiable qui soit lisible,
compréhensible, vérifiable et maintenable. Le présent article donne des recommandations relatives à la
conception d’un logiciel et les essais qui en découlent. La prévention des défauts logiciels doit être prise
en compte tout au long du processus de développement du logiciel.
4 © ISO 2020 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 19014-4:2020(F)
Lorsqu’un composant de logiciel existant a été développé conformément à une norme antérieure et
qu’il a été démontré par l’utilisation et la validation qu’il réduit le risque à un niveau aussi bas que
raisonnablement possible, il ne doit y avoir aucune exigence de mettre à jour la documentation du cycle
de vie du logiciel au niveau du module logiciel.
Les logiciels de commande des machines doivent être conformes aux exigences de sécurité du
présent article. De plus, les logiciels de commande de la machine doivent être conçus et développés
conformément aux principes de l’ISO 12100:2010 pour les phénomènes dangereux pertinents mais non
significatifs qui ne sont pas traités par le présent document.
4.2 Planification
Un planning doit être établi pour définir la relation entre les phases individuelles de développement du
logiciel et les artefacts connexes.
Les méthodes et mesures appropriées du Tableau 3 au Tableau 9 doivent être choisies pour le
développement du logiciel conformément au niveau de performance requis de la machine (MPLr).
Le MPLr du système peut être atteint en ajoutant, en parallèle, deux systèmes d’un niveau de
performance inférieur. Lors de la mise en parallèle (selon l’ISO 19014-2), le logiciel peut être développé
dans chaque système pour répondre aux exigences du MPLr inférieur. Cela n’est permis que lorsqu’il
n’existe pas de défaillances de cause commune entre les deux systèmes.
L’adéquation des méthodes ou des mesures choisies à l’application doit être justifiée et doit être
effectuée au début de chaque phase de développement prévue. Pour une application particulière, la
combinaison appropriée des méthodes ou des mesures doit être spécifiée pendant la planification du
développement. Il est permis d’utiliser des méthodes ou des mesures qui ne sont pas énumérées du
Tableau 3 au Tableau 9.
Figure 1 — Développement du logiciel — Modèle en V
La Figure 1 est une représentation d’une méthode de conception possible (modèle en V). Tout processus
de développement organisé et reconnu qui répond aux exigences du présent document peut être utilisé
pour le développement d’un logiciel.
Lors du choix des méthodes et des mesures, outre le codage manuel, un développement fondé sur un
modèle peut être appliqué lorsque le code source est automatiquement généré à partir de modèles.
© ISO 2020 – Tous droits réservés 5
---------------------- Page: 10 ----------------------
ISO 19014-4:2020(F)
Pour chaque méthode ou mesure figurant dans les tableaux, il existe un niveau de disposition différent
pour chaque niveau de performance. Le Tableau 1 indique les exigences.
Tableau 1 — Spécification des exigences relatives à la sécurité du logiciel
Symbole Spécification des exigences relatives à la sécurité du logiciel
+ La méthode ou la mesure doit être utilisée pour ce MPLr.
Si cette méthode ou mesure n’est pas utilisée, la justification correspondante doit être documentée
pendant la phase de planification de la sécurité.
o La méthode ou la mesure peut être utilisée pour ce MPLr.
– La méthode ou la mesure n’est pas adéquate pour satisfaire à ce MPLr.
Les méthodes et mesures correspondant au MPLr respectif doivent être choisies. Des méthodes et
mesures subsidiaires ou équivalentes sont définies par des lettres qui suivent le nombre. Au moins l’une
des méthodes et mesures subsidiaires ou équivalentes marquées d’un «+» doit être choisie, auquel cas il
n’est pas exigé de fournir une justification. Le Tableau 2 en contient un exemple.
Tableau 2 — Exemple de spécification des exigences relatives à la sécurité du logiciel
Méthode/mesure MPLr = a MPLr = b, c MPLr = d MPLr = e
1.a Mesure 1 + + - -
1.b Mesure 2 + + + +
1.c Mesure 3 + + + +
Dans ce cas,
— une mesure de la Mesure 1, Mesure 2 ou Mesure 3 doit être respectée pour MPLr = a, b, c;
— une mesure de la Mesure 2 ou Mesure 3 doit être respectée pour MPLr = d, e;
— dans le cas contraire, une justification doit être fournie au sujet de la méthode ou de la mesure
subsidiaire non précisée pour satisfaire à l’exigence de la norme relative au MPLr en question.
Une justification doit être fournie si d’autres méthodes ou mesures équivalentes sont utilisées au lieu
des méthodes ou mesures énumérées.
Si un composant de logiciel a un impact sur différentes fonctions de sécurité avec un MPLr différent, les
exigences relatives au MPLr le plus élevé doivent s’appliquer.
Si le logiciel contient des composants liés à la sécurité et d’autres non liés à la sécurité, le niveau de
performance atteint de la machine (MPLa) global du logiciel intégré doit alors être limité au composant
de logiciel ayant le plus petit MPLa; cette exigence ne s’applique pas lorsque l’indépendance adéquate
entre les composants de logiciel peut être démontrée conformément à l’Article 7.
Lors de la réutilisation d’un composant de logiciel destiné à être modifié, une analyse d’impact doit
être effectuée. Un plan d’action doit être élaboré et mis en œuvre pour l’ensemble du cycle de vie du
logiciel, sur la base des résultats de l’analyse d’impact, afin de s’assurer que les objectifs de sécurité
sont atteints.
4.3 Artefacts
Une fois les phases individuelles du plan de développement de logiciel déterminées, les artefacts doivent
être
...
FINAL
INTERNATIONAL ISO/FDIS
DRAFT
STANDARD 19014-4
ISO/TC 127/SC 2
Earth-moving machinery —
Secretariat: ANSI
Functional safety —
Voting begins on:
2020-04-02
Part 4:
Voting terminates on:
Design and evaluation of software and
2020-05-28
data transmission for safety-related
parts of the control system
Engins de terrassement — Sécurité fonctionnelle —
Partie 4: Conception et évaluation du logiciel et de la transmission
des données pour les parties relatives à la sécurité du système de
commande
ISO/CEN PARALLEL PROCESSING
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 SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/FDIS 19014-4:2020(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO 2020
---------------------- Page: 1 ----------------------
ISO/FDIS 19014-4:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2020
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 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/FDIS 19014-4:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Software development . 4
4.1 General . 4
4.2 Planning . 5
4.3 Artifacts . 6
4.4 Software safety requirements specification . 7
4.5 Software architecture design . 8
4.6 Software module design and coding . 8
4.7 Language and tool selection . 9
4.8 Software module testing .10
4.9 Software module integration and testing .11
4.10 Software validation .12
5 Software-based parameterization .12
5.1 General .12
5.2 Data integrity .13
5.3 Software-based parameterization verification .13
6 Transmission protection of safety-related messages on bus systems .13
7 Independence by software partitioning .14
7.1 General .14
7.2 Several partitions within a single microcontroller .15
7.3 Several partitions within the scope of an ECU network .16
8 Information for use .17
8.1 General .17
8.2 Instruction Handbook .17
Annex A (informative) Description of software methods/measures .18
Annex B (normative) Software validation test environments .31
Annex C (informative) Data integrity assurance calculation.34
Annex D (informative) Methods and measures for transmission protection .36
Annex E (informative) Methods and measures for data protection internal to microcontroller .38
Bibliography .40
© ISO 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/FDIS 19014-4:2020(E)
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 of 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 www .iso .org/
iso/ foreword .html.
This document was prepared by ISO/TC 127, Earth-moving machinery, Subcommittee SC 2, Safety,
ergonomics and general requirements, in collaboration with the European Committee for Standardization
(CEN) Technical Committee CEN/TC 151, Construction equipment and building material machines - Safety,
in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This first edition of ISO 19014-4, together with other parts in the ISO 19014 series, cancels and replaces
ISO 15998:2008 and ISO/TS 15998-2:2012, which have been technically revised.
The main changes compared to the previous documents are as follows:
— additional requirements for software development,
— requirements for software-based parametrization development,
— requirements for transmission of safety related messages on a communication bus, and
— requirements for software validation and verification of machine performance levels.
A list of all parts in the ISO 19014 series can be found on the ISO website.
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.
iv © ISO 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/FDIS 19014-4:2020(E)
Introduction
This document addresses systems comprising any combination of electrical, electronic, and
programmable electronic components [electrical/electronic/programmable electronic systems (E/E/
PES)] used for functional safety in earth-moving machinery.
The structure of safety standards in the field of machinery is as follows.
Type-A standards (basis standards) give basic concepts, principles for design, and general aspects that
can be applied to machinery.
Type-B standards (generic safety standards) deal with one or more safety aspect(s), or one or more
type(s) of safeguards that can be used across a wide range of machinery:
— type-B1 standards on particular safety aspects (e.g. safety distances, surface temperature, noise);
— type-B2 standards on safeguards (e.g. two-hands controls, interlocking devices, pressure sensitive
devices, guards).
Type-C standards (machinery safety standards) deal with detailed safety requirements for a particular
machine or group of machines.
This document is a type-C standard as stated in ISO 12100.
This document is of relevance, in particular, for the following stakeholder groups representing the
market players with regard to machinery safety:
— machine manufacturers (small, medium, and large enterprises);
— health and safety bodies (regulators, accident prevention organisations, market surveillance etc.).
Others can be affected by the level of machinery safety achieved with the means of the document by the
above-mentioned stakeholder groups:
— machine users/employers (small, medium, and large enterprises);
— machine users/employees (e.g. trade unions, organizations for people with special needs);
— service providers, e. g. for maintenance (small, medium, and large enterprises);
The above-mentioned stakeholder groups have been given the possibility to participate at the drafting
process of this document.
The machinery concerned and the extent to which hazards, hazardous situations, or hazardous events
are covered are indicated in the Scope of this document.
When requirements of this type-C standard are different from those which are stated in type-A or
type-B standards, the requirements of this type-C standard take precedence over the requirements of
the other standards for machines that have been designed and built according to the requirements of
this type-C standard.
© ISO 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 19014-4:2020(E)
Earth-moving machinery — Functional safety —
Part 4:
Design and evaluation of software and data transmission
for safety-related parts of the control system
1 Scope
This document specifies general principles for software development and signal transmission
requirements of safety-related parts of machine-control systems (MCS) in earth-moving machinery
(EMM) and its equipment, as defined in ISO 6165. In addition, this document addresses the significant
hazards as defined in ISO 12100 related to the software embedded within the machine control system.
The significant hazards being addressed are the incorrect machine control system output responses
from machine control system inputs.
Cyber security is out of the scope of this document.
NOTE For guidance on cybersecurity, see an appropriate security standard.
This document is not applicable to EMM manufactured before the date of its publication.
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 6750-1, Earth-moving machinery — Operator's manual — Part 1: Contents and format
ISO 12100:2010, Safety of machinery — General principles for design — Risk assessment and risk reduction
ISO 13849-1, Safety of machinery — Safety-related parts of control systems — Part 1: General principles
for design
ISO 19014-1, Earth-moving machinery — Functional safety — Part 1: Methodology to determine safety-
related parts of the control system and performance requirements
1)
ISO 19014-2:— , Earth-moving machinery — Functional safety — Part 2: Design and evaluation of
hardware and architecture requirements for safety-related parts of the control system
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 12100, ISO 19014-1, ISO 13849-1
and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
1) Under preparation.
© ISO 2020 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/FDIS 19014-4:2020(E)
3.1
bus system
subsystem used in an electronic control system for the transmission of messages (3.6)
Note 1 to entry: The bus system consists of the system unit (sources and sinks of information), a transmission
path/transmission medium (e.g. electrical lines, fiber-optical lines, radio frequency transmission) and the
interface between message source/sink and bus electronics (e.g. protocol application specific integrated circuit,
transceivers).
3.2
encapsulated bus system
bus system (3.1) comprising a fixed number or a predetermined maximum number of bus participants
connected to each other through a transmission medium with well-defined and fixed performance/
characteristics
3.3
failure of peer communication
situation in which the communication peer is not available
3.4
unintended message repetition
situation in which the same message (3.6) is unintentionally sent again
3.5
message repetition
situation in which the same message (3.6) is intentionally sent again
Note 1 to entry: This technique of resending the same message addresses failures such as message loss (3.10).
3.6
message
electronic transmission of data
Note 1 to entry: transmitted data can include user data, address, or identifier data and data to ensure transmission
integrity.
3.7
ECU
electronic control unit
electronic device (electronic programmable controller) used in a control system on earth-moving
machinery
[SOURCE: ISO 22448:2010, 3.3, modified — The admitted terms "ECM" and "electronic control module"
have been removed.]
3.8
reaction time
time from the detection of a safety-related event until the initiation of a safety reaction
3.9
artifact
work products that are produced and used during a project to capture and convey information
3.10
message loss
unintended deletion of a message (3.6) due to a fault of a bus participant
2 © ISO 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/FDIS 19014-4:2020(E)
3.11
incorrect sequence
unintended modification of the sequence of messages (3.6) due to a fault of a bus participant
Note 1 to entry: Bus systems (3.1) can contain elements with stored messages (first-in, first-out (FIFOs), etc.) that
can modify the correct sequence.
3.12
message falsification
unintended modification of messages (3.6) due to an error of a bus participant or due to errors on the
transmission channel
3.13
message retardation
unintended delay or prevention of the safety function, caused by an overload of the transmission path
by normal data exchange or by sending incorrect messages (3.6)
3.14
alive counter
accounting component initialised with “0” when the object to be monitored is created or restored
Note 1 to entry: The counter increases from time t–1 to time t as long as the object is alive. Finally, the alive
counter shows the period of time for which the object has been alive within a network.
3.15
black box testing
testing of an object that does not require knowledge of its internal structure or its concrete
implementation
3.16
partition
resource entity allocating a portion of memory, input/output devices, and central processing unit usage
to one or more system tasks (3.21)
Note 1 to entry: The partitions can be assigned to one or more subsystems within the microcontroller network.
3.17
software partitioning
software fault (3.26) containment method consisting of assigning resources to specific software
components with the intention of avoiding the propagation of a software fault to multiple partitions (3.16)
3.18
software component
one or more software modules (3.19)
[SOURCE: ISO 26262-1:2018, 3.157, modified — The word "units" has been replaced with "modules".]
3.19
software module
independent piece of software that can be independently tested and traced to a specification
Note 1 to entry: The software module is an indivisible software component.
3.20
software partitions
runtime environment with separate system resources assigned
3.21
system task
runtime entities that are executed within the resource budget of partitions (3.16) and with different
priorities
© ISO 2020 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/FDIS 19014-4:2020(E)
3.22
independence of software
exclusion of unintended interactions between software components, as well as freedom from impact on
the correct operation of a software component resulting from errors of another software component
3.23
operational history
operating data about a software component or a software module (3.19) during its time in service
3.24
maximum cycle time
static time to access a communication bus between nodes at a bus or node level
Note 1 to entry: The application of a time-triggered protocol ensures this cycle time is not exceeded.
3.25
maximum response time
fixed time assigned to a system activity to exchange globally-synchronised messages (3.6) on a bus in a
time-triggered architecture
3.26
software fault
incorrect step, process, or data definition in software which causes the system to produce
unexpected results
3.27
impact analysis
documentation that records the understanding and implications of a proposed change
3.28
configuration management process
task of tracking and controlling changes to the artifacts (3.9) in the development process
3.29
constant transmission of messages
situation in which the faulty node continually transmits messages (3.6) that compromises the operation
of the bus
3.30
blocking access to the data bus
situation in which the faulty node does not adhere to the expected patterns of use and makes excessive
demands of service, thereby reducing its availability to other nodes
4 Software development
4.1 General
The main objective of the following requirements is to achieve software reliability by means of
readable, understandable, testable, and maintainable software. This clause gives recommendations for
the design of software and the subsequent related testing. The avoidance of software faults shall be
considered during the entire software development process.
Where an existing software component has been developed to a previous standard and demonstrated
through application usage and validation to reduce the risk to as low as reasonably practicable, there
shall be no requirement to update the software life cycle documentation at the module level.
Machine control software shall comply with the safety requirements of this clause. In addition, the
machine control software shall be designed and developed according to the principles of ISO 12100:2010
for relevant but not significant hazards which are not dealt with by this document.
4 © ISO 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/FDIS 19014-4:2020(E)
4.2 Planning
A plan shall be developed to define the relationship between the individual phases of the software
development and the related artifacts.
Appropriate methods and measures from Table 3 through Table 9 shall be selected for software
development according to the machine performance level required (MPLr).
The MPLr of the system may be achieved by adding, in parallel, two systems of a lower performance
level. When adding in parallel, the software can be developed in each system to the lower MPLr
requirements (according to ISO 19014-2). This is only allowable when there are no common cause
failures between the two systems.
The suitability of the selected methods or measures to the application shall be justified and shall be
made at the beginning of each planned development phase. For a particular application, the appropriate
combination of methods or measures shall be stated during development planning. Methods or
measures not listed in Table 3 through Table 9 may be used.
Figure 1 — Software development V-model
Figure 1 is a representation of one possible design method (V-model). Any organized, proven
development process that meets the requirements of this document may be used for the software
development.
When selecting methods and measures, in addition to manual coding, model-based development may
be applied where the source code is automatically generated from models.
With each method or measure in the tables, there is a different level of provision for each performance
level. Table 1 indicates the requirements.
Table 1 — Software safety requirements specification
+ The method or measure shall be used for this MPLr.
In case this method or measure is not used, the related rationale shall be documented during the safety
planning phase.
o The method or measure may be used for this MPLr.
– The method or measure is not suitable to meet this MPLr.
© ISO 2020 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/FDIS 19014-4:2020(E)
Methods and measures corresponding to the respective MPLr shall be selected. Alternative or
equivalent methods and measures are identified by letters after the number. At least one of the
alternatives or equivalent methods and measures marked with a “+” shall be selected, in which case,
providing a rationale is not required. An example of this is Table 2.
Table 2 — Example software safety requirements specification
Method/measure MPLr = a MPLr = b, c MPLr = d MPLr = e
1.a Measure 1 + + – –
1.b Measure 2 + + + +
1.c Measure 3 + + + +
In this case,
— one measure from Measure 1, Measure2 or Measure 3 shall be fulfilled for MPLr = a, b, c;
— one measure from Measure2 or Measure 3 shall be fulfilled for MPLr = d, e;
— otherwise, a rationale shall be provided about the unspecified alternative method/measure to
satisfy the requirement of the standard for the specific MPLr.
Rationale or justification shall be provided if other equivalent methods or measures are used instead of
the listed methods or measures.
If a software component has any impact on different safety functions with a different MPLr, then the
requirements related to the highest MPLr shall apply.
If the software contains safety-related and non-safety-related components, then the overall embedded
software machine performance level achieved (MPLa) shall be limited to the software component with
the lowest MPLa; this requirement does not apply when adequate independence between the software
components can be demonstrated in accordance with Clause 7.
When reusing a software component that is intended to be modified, an impact analysis shall be
performed. An action plan shall be developed and implemented for the overall software life cycle, based
on the result of the impact analysis, to ensure that the safety goals are met.
4.3 Artifacts
Once the individual phases of software development plan have been determined, the artifacts shall be
defined for each phase to be carried out. Other phases and related artifacts can be added by distributing
the activities and tasks. Taking into account the extent and complexity of the project, all artifacts in the
individual phases shown in Figure 1 may be modified.
NOTE It is common to combine individual phases if the method/measure used makes it difficult to clearly
distinguish between the phases. For example, the design of the software architecture and the software
implementation can be generated successively with the same computer-aided development tool, as is done in the
model-based development process.
As part of the software development process, the artifacts shall be:
a) documented according to the outcomes expected from the planned phases;
b) modified as a consequence of an impact analysis, and only the impacted software shall be
regression tested;
c) subject to a configuration management process.
6 © ISO 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/FDIS 19014-4:2020(E)
The first artifact applicable to the process is the software development plan. The subsequent artifacts,
defined by the plan, shall include:
— design specification and related verification report, for each software design phase (descending
branch of the V-model in Figure 1);
— test specification and related test report, for each software (SW) testing phase (rising branch of the
V-model in Figure 1);
— executable software.
4.4 Software safety requirements specification
The software safety requirements specification shall describe requirements for the following, if
relevant:
— functions that enable the system to achieve or maintain a safe state;
— functions related to the detection, indication, and handling of faults by the safety-related parts of
control systems (SRP/CS);
— functions related to the detection, indication, and handling of faults in the software;
— functions related to the online and offline tests of the safety functions;
NOTE 1 An online test is performed while the system being tested is in use. An offline test is performed
while the system being tested is not in use.
NOTE 2 An example of an online test would be checking for faults in the steering system while driving the
machine. An example of an offline test would be checking for faults in the steering system prior to allowing
machine movement.
— functions that allow modifications of safety-related software parameters;
— interfaces with functions that are not safety-related;
— performance and response time;
— interfaces between the software and the hardware of the electronic control unit.
Appropriate method or measures shall be selected from Tabl
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.