Earth-moving machinery -- Functional safety

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

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

Status
Published
Publication Date
07-Jul-2020
Current Stage
5060 - Close of voting Proof returned by Secretariat
Start Date
29-May-2020
Completion Date
28-May-2020
Ref Project

RELATIONS

Buy Standard

Standard
ISO 19014-4:2020 - Earth-moving machinery -- Functional safety
English language
40 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 19014-4:2020 - Engins de terrassement -- Sécurité fonctionnelle
French language
42 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/FDIS 19014-4 - Earth-moving machinery -- Functional safety
English language
40 pages
sale 15% off
Preview
sale 15% off
Preview

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

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

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

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.