ISO/FDIS 19014-4

Earth-moving machinery — Functional safety — Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system

This document specifies general principles for software development and signal transmission requirements of safety-related parts of machine-control systems (MCS) in earth-moving machinery (EMM) and its equipment, as defined in ISO 6165. In addition, this document addresses the significant hazards as defined in ISO 12100 related to the software embedded within the machine control system. The significant hazards being addressed are the incorrect machine control system output responses from machine control system inputs. Cyber security is out of the scope of this document. NOTE For guidance on cybersecurity, see an appropriate security standard. This document is not applicable to EMM manufactured before the date of its publication.

Engins de terrassement — Sécurité fonctionnelle — Partie 4: Conception et évaluation du logiciel et de la transmission des données pour les parties du système de commande relatives à la sécurité

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: Not Published
• ICS: 53.100 - Earth-moving machinery
• Technical Committee: ISO/TC 127/SC 2 - Safety, ergonomics and general requirements
• Drafting Committee: ISO/TC 127/SC 2/WG 24 - Control system functional safety
• Current Stage: 5000 - FDIS registered for formal approval
• Start Date: 05-Feb-2026
• Completion Date: 09-Jan-2026

Relations

• Consolidates: prEN ISO 19014-4 - Earth-moving machinery - Functional safety - Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system (ISO/DIS 19014-4:2025)
• Effective Date: 12-Feb-2026
• Revises: ISO 19014-4:2020 - Earth-moving machinery — Functional safety — Part 4: Design and evaluation of software and data transmission for safety-related parts of the control system
• Effective Date: 09-Sep-2023

Overview

ISO/FDIS 19014-4 is the fourth part of the ISO 19014 series addressing the functional safety of earth-moving machinery. Specifically, this standard defines the general principles for the design and evaluation of software and data transmission in the safety-related parts of machine-control systems (MCS) used in earth-moving machinery (EMM), as categorized by ISO 6165. Its primary focus is on establishing reliable, robust software development processes and safe signal transmission for those machine-control system components that contribute directly to machinery safety. The standard excludes cybersecurity, which must be addressed using specialized security standards.

Key Topics

Software Development Best Practices

• Requirements Specification: Guidance on documenting software safety requirements necessary for maintaining a safe operating state in EMM control systems.
• Development Planning: Structured planning covering all phases of the software lifecycle, ensuring the avoidance of software faults and robust documentation (artifacts).
• Module and Architecture Design: Recommendations for readable, testable, and maintainable coding, and verification that software modules behave correctly as prescribed by the architecture.
• Testing and Validation: Emphasis on practical testing techniques and environments, ensuring each software module and integrated software system meet defined safety requirements.
• Traceability: Methods for ensuring traceability between software requirements, design artifacts, and test results to facilitate verification, validation, and future maintenance.

Data Transmission Reliability

• Signal Transmission Requirements: Methods to ensure the integrity of safety-related messages exchanged between electronic control units (ECUs) over various bus systems.
• Fault Handling: Requirements aimed at the detection, indication, and management of faults related to both software and data transmission, such as unintended message repetition or loss.
• Partitioning and Independence: Guidance on software partitioning to prevent fault propagation, promoting independence among software components where safety and non-safety functions coexist.

Hazard Mitigation

• Risk Reduction Focus: The standard directly addresses significant hazards arising from incorrect control system output responses to machine inputs, in alignment with ISO 12100.
• Exclusions: While functional safety and associated hazards from embedded software are included, cybersecurity, and machines manufactured before the standard’s publication, are out of scope.

Applications

ISO/FDIS 19014-4 is essential for:

• Machine Manufacturers: Ensuring new designs of earth-moving machinery comply with globally recognized functional safety software and data transmission criteria.
• Software Engineers and Integrators: Developing, coding, and validating control system software for EMM, with clear guidelines for safety-critical application domains.
• Health and Safety Regulators: Benchmarking industry practices and evaluating compliance of manufacturers’ machine-control systems with international functional safety requirements.
• Maintenance and Service Providers: Supporting safe modifications and maintenance of safety-related software based on robust lifecycle documentation and established artifact management.

This standard is relevant to all stakeholders involved in the design, development, and operation of earth-moving machines-from initial engineering to operational safety and compliance in regulated markets.

Related Standards

• ISO 6165: Covers the basic definition and classification of earth-moving machinery.
• ISO 12100: General principles for machine design, risk assessment, and risk reduction.
• ISO 19014 Parts 1 and 2: Address overall methodology and hardware/architecture requirements for functional safety in EMM control systems.
• ISO 6750-1: Specifies contents and format for operator’s manuals for earth-moving machinery.
• ISO 13849-1: Framework for the design and integration of safety-related parts of machine control systems in broader machinery contexts.

For concerns related to cybersecurity in earth-moving machinery, reference to dedicated security standards is strongly recommended to ensure holistic risk coverage.

---

Keywords: Earth-moving machinery, functional safety, control system software, safety-related messaging, ISO 19014-4, EMM, machine control, safety standards, software development, data transmission integrity, risk reduction, ISO standards, heavy equipment safety

Standards Content (Sample)

DRAFT
International
Standard
ISO/DIS 19014-4.2
ISO/TC 127/SC 2
Earth-moving machinery —
Secretariat: ANSI
Functional safety —
Voting begins on:
Part 4: 2025-07-25
Design and evaluation of software
Voting terminates on:
2025-09-19
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
ICS: 53.100
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 19014-4.2:2025(en)
DRAFT
ISO/DIS 19014-4.2:2025(en)
International
Standard
ISO/DIS 19014-4.2
ISO/TC 127/SC 2
Earth-moving machinery —
Secretariat: ANSI
Functional safety —
Voting begins on:
Part 4:
2025-07-25
Design and evaluation of software
Voting terminates on:
2025-09-19
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
ICS: 53.100
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2025
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: [phone]
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 19014-4.2:2025(en)
ii
ISO/DIS 19014-4.2:2025(en)
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 .4
4.3 Artifacts .6
4.4 Software safety requirements specification .7
4.5 Software architecture design .7
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 Verification of the safety requirements and/or protective/risk reduction measures .11
5 Software-based parameterization .12
5.1 General . 12
5.2 Data integrity . 12
5.3 Software-based parameterization verification . 13
6 Transmission protection of safety-related messages on bus systems .13
7 Independence by software partitioning .15
7.1 General . 15
7.2 Several partitions within a single microcontroller . 15
7.3 Several partitions within the scope of an ECU network .17
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 .30
Annex C (informative) Data integrity assurance calculation .33
Annex D (informative) Methods and measures for transmission protection .35
Annex E (informative) Methods and measures for data protection internal to microcontroller .37
Annex ZA (informative) Relationship between this European Standard and the essential
requirements of Regulation (EU) 2023/1230 aimed to be covered .39
Bibliography .40

iii
ISO/DIS 19014-4.2:2025(en)
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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 second edition of ISO 19014-4 cancels and replaces the first edition (ISO 19014-4:2020), which has been
technically revised.
The main change is as follows:
— referenced standards have been dated.
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/DIS 19014-4.2:2025(en)
Introduction
This document addresses systems comprising any combination of electrical, electronic, and programmable
electronic components [electrical, electronic, and 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:2010.
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);
— consumers (in case of machinery intended for use by consumers).
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 the requirements of this type-C standard are different from those 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.

v
DRAFT International Standard ISO/DIS 19014-4.2:2025(en)
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:2022. In addition, this document addresses the significant hazards as
defined in ISO 12100:2010 related to the software embedded within the machine control system. The
significant hazards being addressed include 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:2019, 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:2023, Safety of machinery — Safety-related parts of control systems — Part 1: General principles
for design
ISO 19014-1:202X, Earth-moving machinery — Functional safety — Part 1: Methodology to determine safety-
related parts of the control system and performance requirements
ISO 19014-2:202X, 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 given in ISO 12100:2010, ISO 19014-1:202X,
ISO 13849-1:2023 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

ISO/DIS 19014-4.2:2025(en)
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
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, such as first-in, first-out (FIFOs) etc.,
that can modify the correct sequence.

ISO/DIS 19014-4.2:2025(en)
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
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

ISO/DIS 19014-4.2:2025(en)
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 compromise 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, it is not
required 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.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 (MPL ).
r
The MPL of a system is the lower of the MPL of the hardware and software.
a a
ISO/DIS 19014-4.2:2025(en)
The MPL of the system may be achieved by adding, in parallel, two systems of a lower performance level.
r
When using parallel add (according to ISO 19014-2:202X), the software can be developed in each system to
the lower MPL requirements. This is only allowable when there are no common cause failures between the
r
two systems.
The suitability of the selected methods or measures to the application shall be justified. Justification 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 MPL .
r
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 MPL .
r
– The method or measure is not suitable to meet this MPL .
r
Methods and measures corresponding to the respective MPL shall be selected. Alternative or equivalent
r
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.

ISO/DIS 19014-4.2:2025(en)
Table 2 — Example software safety requirements specification
Method/measure MPL = a MPL = b, c MPL = d MPL = e
r r r r
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 MPL = a, b, c;
r
— one measure from Measure2 or Measure 3 shall be fulfilled for MPL = d, e;
r
— otherwise, a rationale shall be provided about the unspecified alternative method/measure to satisfy
the requirement of the standard for the specific MPL .
r
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 MPL , then the
r
requirements related to the highest MPL shall apply.
r
If the software contains safety-related and non-safety-related components, then the overall embedded
software machine performance level achieved (MPL ) shall be limited to the software component with
a
the lowest MPL . This requirement does not apply when adequate independence between the software
a
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.
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.
ISO/DIS 19014-4.2:2025(en)
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 is checking for faults in the steering system while driving the machine. An
example of an offline test is 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 MPL .
r
Table 3 — Software safety requirements specification
Method/measure Reference MPL = MPL = MPL = MPL = e
r r r r
a b, c d
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 requirements
6.a Walk-through of software safety requirements A.7 + + + –
6.b Inspection of software safety requirements A.8 + + + +
NOTE The detailed description of these methods/measures is in Annex A.
4.5 Software architecture design
Software architecture that describes the hierarchical structure of all the safety-related software components
of each safety control system (SCS) shall be developed based on the software safety requirements.
Appropriate methods or measures shall be selected from Table 4 to meet the specified MPL .
r
ISO/DIS 19014-4.2:2025(en)
Table 4 — Software architecture design
MPL =
r
Method/measure Reference MPL = a MPL = d MPL = e
r r r
b, c
1.a Informal methods A.3 + + + –
1.b Semi-formal methods A.4 + + + +
1.c Formal methods A.5 + + + +
2. Computer-aided design tools A.9 o o o +
Cyclic behaviour, with guaranteed maximum cycle
3.a o o + +
time
3.b Time-triggered architecture A.10 o o + +
Event-driven, with guaranteed maximum response
3.c o o + +
time
Forward traceability between the software safety
4. requirements specification and the software architec- o o o +
ture
A.6
Backward traceability between the software architec-
5. ture and the software safety requirements specifica- o o o +
tion
6.a Walk-through of software architecture A.7 + + + –
6.b Inspection of software architecture A.8 + + + +
NOTE The detailed description of these methods/measure is in Annex A.
4.6 Software module design and coding
The objectives of this phase of software development are:
— specifying, in detail, the behaviour of the safety-related software modules that are prescribed by the
software architecture;
— generating readable, testable, and maintainable software modules (e.g. manual code, model, etc.);
— verifying that the software architecture has been fully and correctly implemented.
Appropriate methods or measures shall be selected from Table 5 to meet the specified MPL . There is no
r
requirement to review auto-generated code.

ISO/DIS 19014-4.2:2025(en)
Table 5 — Software module design and coding
Method/measure Reference MPL MPL = MPL = d MPL = e
r r r r
b, c
= a
1.a Informal methods A.3 + + – –
1.b Semi-formal methods A.4 + + + +
1.c Formal methods A.5 + + + +
2. Computer aided design tool A.9 o o o +
3. Use of design and coding standards o + + +
4. No unstructured control flow in programs in higher
o o + +
b
level languages
b
5. Limited automatic type conversion o o + +
A.11
b
6. Limited use of interrupts o o o +
b
7. Limited use of pointers o o o +
8. Limited use of recursion o o o +
b
9.a Dynamic variables or objects without online check A.12 o o – –
b
9.b Dynamic variables or objects with online check A.13 o o + +
10. Software module size limit + + + +
11. One entry/one exit point in subroutines and func-
o + + +
b
tions
A.14
12. Fully defined interface o + + +
13. Information hiding/encapsulation o o + +
14. Software complexity control o o o +
15. Structured design or coding A.15 o + + +
16. Defensive design or code A.16 o o o +
a
17. Use of trusted/verified software elements A.17 o o o O
18. Forward traceability between the software safety
A.6 o o o +
requirements specification and the software design
19.a Walk-through of software design, source code or
A.7 + + + –
both
19.b Inspection of software design, source code or both A.8 + + + +
NOTE The detailed description of these methods/measures is in Annex A.
a
The use of trusted and verified software elements is highly recommended.
b
These methods or measures are not always applicable for graphical modelling notations used in model-based development.
4.7 Language and tool selection
The safety integrity of the software being developed can be directly affected by the programming language
selected, the tools used during development and testing, and the use of existing, trusted, verified software
modules. Appropriate methods or measures shall be selected from Table 6 to meet the specified MPL .
r
Table 6 — Language and tool selection
Method/measure Reference MPL = a MPL = MPL = d MPL = e
r r r r
b, c
1. Suitable programming language A.18 + + + +
2. Language subset support A.19 o o o +
3.a Tools and translators with increased confidence from A.20 o + + +
use or validation
3.b Certified tools and certified translators A.21 o + + +
NOTE The detailed description of these methods/measures is in Annex A.

ISO/DIS 19014-4.2:2025(en)
4.8 Software module testing
The objective of software module testing is to verify that the designed and implemented software modules
correctly fulfil the software safety design. In this phase, a procedure for testing the software modules
against their requirements shall be produced and the tests shall be carried out in accordance with that
procedure.
For a systematic approach to software module testing, the use of appropriate tools for test management
and test automation supports the work-intensive and error-prone tasks in software module testing. The
availability of support tools encourages a more exhaustive approach to both normal and regression testing.
For easier verification, validation, assessment, and maintenance, all data, decisions, and rationale should be
documented throughout the software project. Documentation on the software modules should include:
— testing performed;
— decisions and their rationale;
— problems and their solutions.
NOTE Data recording is important for the maintenance of computer systems as the rationale for certain decisions
made during the development project is not always known by the maintenance engineers.
Appropriate methods or measures shall be selected from Table 7 to meet the specified MPL . Software
r
module testing may be executed in different environments, for example:
— model-in-the-loop tests;
— software-in-the-loop tests;
— processor-in-the-loop tests;
— hardware-in-the-loop tests.
Table 7 — Software module testing
Method/measure Reference MPL = MPL = MPL = MPL =
r r r r
a b, c d e
1. Boundary value analysis A.22 o o + +
2. Control flow analysis A.23 o o + +
3. Data flow analysis A.24 o o + +
4. Test case execution from boundary value analysis A.25 o o o +
5. Functional/black box testing (including fault insertion (FI)
A.26 + + + +
testing)
6.a Structure test coverage (entry points) o + – –
6.b Structure test coverage (statements) A.27 o + + -
6.c Structure test coverage (branches) o + + +
a
7. Equivalence classes and input partition testing A.28 o o + +
8. Test case execution from model-based test case generation A.29 o o o +
a
9. Response timings and memory constraints testing o + + +
a
10. Performance requirements testing A.30 o + + +
a
11. Avalanche/stress testing o o o +
NOTE The detailed description of these methods/measures is in Annex A.
a
The tester may choose not to perform this test method, but shall perform it at the integration level, when required.

ISO/DIS 19014-4.2:2025(en)
TTabablele 7 7 ((ccoonnttiinnueuedd))
Method/measure Reference MPL = MPL = MPL = MPL =
r r r r
a b, c d e
12. SW module interface testing A.31 o o o +
13 Back-to-back comparison testing A.32 o o + +
14. Forward traceability between the software module design
A.6 o o o +
and the module test specifications
NOTE The detailed description of these methods/measures is in Annex A.
a
The tester may choose not to perform this test method, but shall perform it at the integration level, when required.
4.9 Software module integration and testing
The objectives of this phase of software development are:
— integrating the software modules into software components throughout the embedded software of the
safety control system;
— verifying that the software requirements are correctly realized by the embedded software.
In this phase, the particular integration steps are tested against the software safety requirements. The
interfaces between the software modules and between software modules and components are also tested.
The steps of the integration and the tests of the software components shall directly correspond to the
hierarchical software architecture.
Appropriate methods/measures shall be selected from Table 8 to meet the specified MPL . However, the
r
tester may choose not to apply a test method or measure at the integration level, but shall apply the method
or measure at the module level, when required.
Software module integration testing may be executed in different environments, for example:
— model-in-the-loop tests;
— software-in-the-loop tests;
— processor-in-the-loop tests;
— hardware-in-the-loop tests.
Table 8 — Software module integration and testing
Method/measure Reference MPL = MPL = MPL = MPL = e
r r r r
a b, c d
1. Functional/black box testing (including fault insertion
A.26 + + + +
(FI) testing)
2. Equivalence classes and input partition testing A.28 o o + +
3. Response timings and memory constraints o + + +
4. Performance requirements testing A.30 o + + +
5. Avalanche/stress testing o o o +
6. Back-to-back comparison testing A.32 o o + +
7. Forward traceability between the software architecture
A.6 o o o +
design and the integration test specifications
NOTE The detailed description of these methods/measures is in Annex A.
4.10 Verification of the safety requirements and/or protective/risk reduction measures
The objective of this phase of software development is showing that the software safety requirements are
correctly realized by the embedded software.

ISO/DIS 19014-4.2:2025(en)
Testing shall be the main verification method for software. Animation and modelling may be used to
supplement the verification activities.
The software shall be exercised by simulation of:
— input signals present during normal operation;
— anticipated occurrences;
— undesired conditions requiring system action.
The effectiveness of the test procedures, and of any other measures used, shall be evaluated against the
safety requirements specifications on conclusion of the verification process.
Appropriate methods/measures shall be selected from Table 9 to meet the specified MPL .
r
Table 9 — Software validation
Method/measure Reference MPL = a MPL = MPL = d MPL =
r r r r
b, c e
1.a Machine network test B.1 + + + +
1.b Hardware-in-the-loop test B.2 + + + +
1.c Machine level test B.3 + + + +
2. Forward traceability between the software safety
requirements specification and software verification o o o +
(including data verification) plan
A.6
3. Backward traceability between the software ver-
ification (including data verification) plan and the o o o +
software safety requirements specification
NOTE The detailed description of these methods/measures is in Annex B.
The test method shall be carried out as specified in Annex B.
5 Software-based parameterization
5.1 General
Software-based parameterization refers to the possibility of adapting the software system to different
requirements, after completion of development, by changing parameters in order to modify the functionality
of the software. Software-based parameterization of safety-related parameters shall be considered part of
the SRP/CS. They shall be described in the software safety requirements specification.
Software-based parameters include:
— variant coding (e.g. country code, left-hand/right-hand steering);
— system parameters (e.g. value for low idle speed, engine characteristic diagrams);
— calibration data (e.g. machinery specific, limit stop for throttle setting).
5.2 Data integrity
The integrity of data used for parameterization shall be maintained, and unauthorized modifications shall
be prevented. This shall be achieved by applying methods or measures to control:
— the range of valid inputs;
— data corruption before and after transmission;
— the errors from the parameter transmission process;
...

PROJET
Norme
internationale
ISO/DIS 19014-4.2
ISO/TC 127/SC 2
Engins de terrassement — Sécurité
Secrétariat: ANSI
fonctionnelle —
Début de vote:
Partie 4: 2025-07-25
Conception et évaluation du logiciel
Vote clos le:
2025-09-19
et de la transmission des données
pour les parties du système de
commande relatives à la sécurité
Earth-moving machinery — Functional safety —
Part 4: Design and evaluation of software and data transmission
for safety-related parts of the control system
ICS: 53.100
CE DOCUMENT EST UN PROJET DIFFUSÉ
POUR OBSERVATIONS ET APPROBATION. IL
EST DONC SUSCEPTIBLE DE MODIFICATION
ET NE PEUT ÊTRE CITÉ COMME NORME
INTERNATIONALE AVANT SA PUBLICATION EN
TANT QUE TELLE.
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
Ce document n’a pas été rédigé par le Secrétariat central de l’ISO.
ÉTABLIR S’ILS SONT ACCEPTABLES À DES
FINS INDUSTRIELLES, TECHNOLOGIQUES ET
COMMERCIALES, AINSI QUE DU POINT DE VUE
DES UTILISATEURS, LES PROJETS DE NORMES
INTERNATIONALES DOIVENT PARFOIS ÊTRE
TRAITEMENT PARALLÈLE ISO/CEN
CONSIDÉRÉS DU POINT DE VUE DE LEUR
POSSIBILITÉ DE DEVENIR DES NORMES
POUVANT SERVIR DE RÉFÉRENCE DANS LA
RÉGLEMENTATION NATIONALE.
LES DESTINATAIRES DU PRÉSENT PROJET
SONT INVITÉS À PRÉSENTER, AVEC LEURS
OBSERVATIONS, NOTIFICATION DES DROITS
DE PROPRIÉTÉ DONT ILS AURAIENT
ÉVENTUELLEMENT CONNAISSANCE
ET À FOURNIR UNE DOCUMENTATION
EXPLICATIVE.
Numéro de référence
ISO/DIS 19014-4.2:2025(fr)
ISO 19014-4:2025(fr)
ISO TC 127/SC 2
ISO/DIS 19014-4.2:2025(fr)
Date : 2025-07-11
Engins de terrassement — Sécurité fonctionnelle — Partie 4 :
Conception et évaluation du logiciel et de la transmission des
données pour les parties du système de commande relatives à la
sécurité
Étape DIS
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2025
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
Type de document :  Erreur ! Source du renvoi introuvable.
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
Sous-type de document :  Erreur ! Source du renvoi introuvable.
ISO copyright office
Stade du document :  Erreur ! Source du renvoi introuvable.
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève Langue du document :  Erreur ! Source du renvoi introuvable.
Tél.: [phone]
E-mail: [e-mail]
Erreur ! Source du renvoi introuvable.
Web: www.iso.org
Publié en Suisse
ii
ISO 19014-4:2025(fr)
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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone : [phone]
E-mail : [e-mail]
Website : www.iso.org
Publié en Suisse
iii
ISO #####-#:####(fr)
Sommaire
Page
Avant-propos . v
Introduction . vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Développement de logiciel. 5
4.1 Généralités . 5
4.2 Planification . 5
4.3 Artefacts . 7
4.4 Spécification des exigences relatives à la sécurité du logiciel . 8
4.5 Conception de l’architecture du logiciel . 9
4.6 Conception et codage des modules logiciels . 9
4.7 Choix du langage et des outils . 10
4.8 Essais des modules logiciels . 11
4.9 Intégration et essais des modules logiciels. 12
4.10 Vérification des prescriptions de sécurité et/ou mesures de prévention/réduction du
risque . 13
5 Paramétrage fondé sur le logiciel. 14
5.1 Généralités . 14
5.2 Intégrité des données . 14
5.3 Vérification du paramétrage fondé sur le logiciel . 15
6 Protection de la transmission de messages relatifs à la sécurité sur les systèmes
bus . 15
7 Indépendance par partitionnement du logiciel . 17
7.1 Généralités . 17
7.2 Plusieurs partitions dans un microcontrôleur unique . 18
7.3 Plusieurs partitions dans le domaine d’application d’un réseau d’ECU . 19
8 Informations pour l’utilisation . 20
8.1 Généralités . 20
8.2 Notice d’instructions . 20
(informative) Description des méthodes/mesures du logiciel . 21
(normative) Environnements d’essais de validation d’un logiciel . 36
(informative) Calcul de l’assurance d’intégrité des données . 39
(informative) Méthodes et mesures de protection de la transmission . 41
(informative) Méthodes et mesures de protection des données internes au
microcontrôleur . 43
Annexe ZA (informative) Relation entre la présente Norme européenne et les exigences
essentielles concernées du Règlement (UE) 2023/1230 . 45
Bibliographie. 46

iv
ISO 19014-4:2025(fr)
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’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner
l’utilisation d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à
l’applicabilité de tout droit de propriété revendiqué à cet égard. À la date de publication du présent
document, l’ISO n’avait pas reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa
mise en application. Toutefois, il y a lieu d’avertir les responsables de la mise en application du présent
document que des informations plus récentes sont susceptibles de figurer dans la base de données de
brevets, disponible à l’adresse www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne
pas avoir identifié tout ou partie de tels droits de propriété.
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é ISO/TC 127, Engins de terrassement, sous-comité SC 2, Sécurité, ergonomie et exigences
générales, en collaboration avec le comité technique CEN/TC 151, Machines de génie civil et de
production de matériaux de construction — Sécurité, du Comité européen de normalisation (CEN),
conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord de Vienne).
Cette deuxième édition de l’ISO 19014-4 annule et remplace la première édition (ISO 19014-4:2020),
qui a fait l’objet d’une révision technique.
La principale modification est la suivante :
— les normes de référence ont été datées.
Une liste de toutes les parties de la série ISO 19014 se trouve sur le site Web 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/fr/members.html.

v
ISO #####-#:####(fr)
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 et
électroniques programmables (E/E/PES)] qui sont utilisés pour la sécurité fonctionnelle dans les engins
de terrassement.
Dans le domaine de la sécurité des machines, les normes sont articulées de la façon 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:2010.
Le présent document concerne, en particulier, les groupes de parties prenantes suivants représentant
les acteurs du marché en 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 partenaires peuvent être concernés par le niveau de sécurité des machines atteint à l’aide du
document par les groupes de parties prenantes mentionnés ci-dessus :
— utilisateurs de machines / employeurs (petites, moyennes et grandes entreprises) ;
— utilisateurs de machines / employés (par exemple, syndicats, organisations pour les personnes
ayant des besoins spéciaux) ;
— prestataires de services, par exemple, pour la maintenance (petites, moyennes et grandes
entreprises) ;
— consommateurs (dans le cas de machines destinées à l’utilisation par les consommateurs).
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, situations ou événements dangereux couverts
sont indiquées dans le domaine d’application du présent document.
vi
ISO 19014-4:2025(fr)
Lorsque les exigences de la présente norme de type C sont différentes de celles des normes de type A ou
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.
vii
ISO 19014-4:2025(fr)
Engins de terrassement — Sécurité fonctionnelle — Partie 4 :
Conception et évaluation du logiciel et de la transmission des
données pour les parties du système de commande relatives à
la sécurité
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:2022. De plus, le présent document traite des phénomènes dangereux significatifs tels
que définis dans l’ISO 12100:2010 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 comprennent 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:2019, 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:2023, Parties des systèmes de commande relatives à la sécurité — Partie 1 : Principes
généraux de conception
ISO 19014-1:202X, Engins de terrassement — Sécurité fonctionnelle — Partie 1 : Méthodologie pour la
détermination des parties du système de commande relatives à la sécurité et les exigences de performance
ISO 19014-2:202X, Engins de terrassement — Sécurité fonctionnelle — Partie 2 : Conception et évaluation
des exigences de matériel et d’architecture pour les parties du système de commande relatives à la sécurité
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l’ISO 12100:2010, l’ISO 19014-1:202X,
l’ISO 13849-1:2023 ainsi que les suivants s’appliquent.
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
ISO 19014-4:2025(fr)
— IEC Electropedia : disponible à l’adresse https://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 de 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é — 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é
ISO 19014-4:2025(fr)
3.9
artefact
produits du travail qui sont produits et utilisés au cours d’un projet pour capturer et transmettre des
informations
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 messages (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, tels que 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 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)
ISO 19014-4:2025(fr)
[SOURCE : ISO 26262-1:2018, 3.157, modifié — Le mot « 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
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
ISO 19014-4:2025(fr)
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.
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 n’est pas exigé 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 de machine requis (MPL ).
r
Le MPL d’un système est le plus faible entre le MPL du matériel et du logiciel.
a a
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 l’utilisation de l’ajout parallèle (conformément à l’ISO 19014-2:202X), 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. Une justification
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.
ISO 19014-4:2025(fr)
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 satisfait 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.
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 MPL .
r
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 MPL = a MPL = b, c MPL = d MPL = e
r r r r
1.a Mesure 1 + + – –
1.b Mesure 2 + + + +
1.c Mesure 3 + + + +
ISO 19014-4:2025(fr)
Dans ce cas :
— une mesure de la Mesure 1, Mesure 2 ou Mesure 3 doit être respectée pour MPL = a, b, c ;
r
— une mesure de la Mesure 2 ou Mesure 3 doit être respectée pour MPL = d, e ;
r
— 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 MPL en question.
r
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 de machine obtenu (MPL ) global du logiciel intégré doit alors être limité au composant de
a
logiciel ayant le plus petit MPL . Cette exigence ne s’applique pas lorsque l’indépendance adéquate entre
a
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 définis pour chaque phase à réaliser. D’autres phases et artefacts connexes peuvent être ajoutés en
répartissant les activités et les tâches. Compte tenu de l’étendue et de la complexité du projet, tous les
artefacts des phases individuelles présentées à la Figure 1 peuvent être modifiés.
NOTE Il est courant de combiner les phases individuelles si la méthode/mesure utilisée rend difficile la
distinction claire entre les phases. Par exemple, la conception de l’architecture du logiciel et la mise en œuvre du
logiciel peuvent être générées successivement avec le même outil de développement assisté par ordinateur, comme
c’est le cas dans le processus de développement fondé sur le modèle.
Dans le cadre du processus de développement du logiciel, les artefacts doivent être :
a) étayés par des documents en fonction des résultats attendus des phases prévues ;
b) modifiés à la suite d’une analyse d’impact, et seul le logiciel concerné doit être soumis à un essai de
régression ;
c) soumis à un processus de gestion de la configuration.
Le premier artefact applicable au processus est le plan de développement du logiciel. Les artefacts
ultérieurs, définis par le plan, doivent inclure :
— les spécifications de conception et le rapport de vérification connexe, pour chaque phase de
conception du logiciel (branche descendante du modèle en V à la Figure 1) ;
— les spécifications d’essai et le rapport d’essai correspondant, pour chaque phase d’essai du logiciel
(SW) (branche montante du modèle en V à la Figure 1) ;
ISO 19014-4:2025(fr)
— le logiciel exécutable.
4.4 Spécification des exigences relatives à la sécurité du logiciel
La spécification des exigences relatives à la sécurité du logiciel doit décrire les exigences portant sur les
éléments suivants, le cas échéant :
— fonctions permettant au système de réaliser ou maintenir un état de sécurité ;
— fonctions relatives à la détection, à l’indication et au traitement des défauts par les parties des
systèmes de commande relatives à la sécurité (SRP/CS) ;
— fonctions relatives à la détection, à l’indication et au traitement des défauts dans le logiciel ;
— fonctions relatives aux essais en ligne et hors connexion des fonctions de sécurité ;
NOTE 1 Un essai en ligne est réalisé pendant que le système soumis à l’essai est en cours d’utilisation. Un essai
hors connexion est réalisé pendant que le système soumis à l’essai n’est pas en cours d’utilisation.
NOTE 2 Un exemple d’essai en ligne est la vérification des défauts dans le système de direction pendant la
conduite de la machine. Un exemple d’essai hors connexion est la vérification des défauts dans le système de
direction avant d’autoriser la machine à bouger.
— fonctions qui permettent de modifier des paramètres du logiciel relatifs à la sécurité ;
— interfaces avec des fonctions qui ne sont pas liées à la sécurité ;
— performance et temps de réponse ;
— interfaces entre le logiciel et le matériel de l’unité de commande électronique.
Les méthodes ou les mesures appropriées doivent être choisies dans le Tableau 3 pour satisfaire au MPL
r
spécifié.
Tableau 3 — Spécification des exigences relatives à la sécurité du logiciel
Méthode/mesure Référence MPLr = MPLr = b MPLr = MPL = e
r
a , c d
1. Spécification des exigences en langage naturel A.1 + + + +
2. Outils de spécification assistée par ordinateur A.2 o o o +
3.a Méthodes informelles A.3 + + + –
3.b Méthodes semi-formelles A.4 + + + +
3.c Méthodes formelles A.5 + + + +
4. Traçabilité directe entre les exigences de sécurité du
o o o +
système et les exigences de sécurité du logiciel
A.6
5. Traçabilité rétrospective entre les exigences de sécurité
o o o +
du système et les exigences de sécurité du logiciel
6.a Revues informelles des exigences de sécurité du logiciel A.7 + + + –
6.b Inspection des exigences de sécurité du logiciel A.8 + + + +
NOTE Les descriptions détaillées de ces méthodes/mesures sont présentées à l’Annexe A.
ISO 19014-4:2025(fr)
4.5 Conception de l’architecture du logiciel
L’architecture d’un logiciel décrit la structure hiérarchique de tous les composants du logiciel relatifs à la
sécurité de chaque système de commande de sécurité (SCS). Elle doit être développée sur la base des
exigences relatives à la sécurité du logiciel. Les méthodes ou les mesures appropriées doivent être
choisies dans le Tableau 4 pour satisfaire au MPLr spécifié.
Tableau 4 — Conception de l’architecture du logiciel
MPLr = b,
Méthode/mesure Référence MPLr = a MPLr = d MPLr = e
c
1.a Méthodes informelles A.3 + + + –
1.b Méthodes semi-formelles A.4 + + + +
1.c Méthodes formelles A.5 + + + +
2. Outils de conception assistée par ordinateur A.9 o o o +
Comportement cyclique, avec temps de cycle
3.a o o + +
maximal garanti
3.b Architecture de type « à déclenchement temporel » A.10 o o + +
Déclenché par événement, avec un temps de réponse
3.c o o + +
maximal garanti
Traçabilité directe entre la spécification des
4. exigences de sécurité du logiciel et l’architecture du o o o +
logiciel
A.6
Traçabilité rétrospective entre l’architecture du
5. logiciel et la spécification des exigences de sécurité o o o +
du logiciel
6.a Revues informelles de l’architecture du logiciel A.7 + + + –
6.b Inspection de l’architecture du logiciel A.8 + + + +
NOTE Les descriptions détaillées de ces méthodes/mesures sont présentées à l’Annexe A.
4.6 Conception et codage des modules logiciels
Les objectifs de cette phase de développement du logiciel consistent à :
— spécifier en détail le comportement des modules logiciels relatifs à la sécurité qui sont spécifiés par
l’architecture du logiciel ;
— générer des modules logiciels lisibles, vérifiables et maintenables (par exemple code manuel, modèle,
etc.) ;
— vérifier que l’architecture du logiciel a été totalement et correctement mise en œuvre.
Les méthodes ou les mesures appropriées doivent être choisies dans le Tableau 5 pour satisfaire au MPLr
spécifié. Il n’est pas exigé d’examiner le code généré automatiquement.
Tableau 5 — Conception et codage du module logiciel
Méthode/mesure Référence MPLr MPLr = b, c MPLr = d MPLr = e
= a
ISO 19014-4:2025(fr)
1.a Méthodes informelles A.3 + + – –
1.b Méthodes semi-formelles A.4 + + + +
1.c Méthodes formelles A.5 + + + +
2. Outil de conception assistée par ordinateur A.9 o o o +
3. Utilisation des normes de conception et de codage o + + +
4. Pas de flux de commandes non structuré dans les
o o + +
b
programmes en langages de plus haut niveau
b
5. Conversion de type automatique limitée o o + +
A.11
b
6. Utilisation limitée des interruptions o o o +
b
7. Utilisation limitée des pointeurs o o o +
8. Utilisation limitée de la récursivité o o o +
b
9.a Variables ou objets dynamiques sans vérification en ligne A.12 o o – –
b
9.b Variables ou objets dynamiques avec vérification en ligne A.13 o o + +
10. Limite de la taille du module logiciel + + + +
11. Un point d’entrée/un point de sortie dans les sous-
o + + +
b
programmes et les fonctions
A.14
12. Interface entièrement définie o + + +
13. Dissimulation/encapsulation de l’information o o + +
14. Contrôle de la complexité du logiciel o o o +
15. Conception ou codage structuré(e) A.15 o + + +
16. Conception ou codage défensif(ve) A.16 o o o +
a
17. Utilisation d’éléments logiciels de confiance/vérifiés A.17 o o o O
18. Traçabilité directe entre la spécification des exigences
A.6 o o o +
relatives à la sécurité du logiciel et la conception du logiciel
19.a Revues informelles de la conception du logiciel, du code
source ou
A.7 + + + –
des deux
19.b Inspection de la conception du logiciel, du code source ou des
A.8 + + + +
deux
NOTE Les descriptions détaillées de ces méthodes/mesures sont présentées à l’Annexe A.
a
L’utilisation d’éléments logiciels de confiance et vérifiés est fortement recommandée.
b
Ces méthodes ou mesures ne s’appliquent pas toujours aux notations de modélisation graphique utilisées dans le développement fondé sur un
modèle.
4.7 Choix du langage et des outils
L’intégrité de la sécurité du logiciel en cours de développement peut être directement affectée par le
langage de programmation choisi, les outils utilisés pendant le développement et les essais, et l’utilisation
de modules logiciels existants, de confiance et vérifiés. Les méthodes ou les mesures appropriées doivent
être choisies dans le Tableau 6 pour satisfaire au MPL spécifié.
r
ISO 19014-4:2025(fr)
Tableau 6 — Choix du langage et des outils
MPL = b,
Méthode/mesure Référence MPLr = a r MPLr = d MPLr = e
c
1. Langage de programmation approprié A.18 + + + +
2. Prise en charge d’un sous-ensemble de langage A.19 o o o +
3.a Outils et traducteurs ayant une confiance accrue A.20 o + + +
résultant de l’utilisation ou de la validation
3.b Outils certifiés et traducteurs certifiés A.21 o + + +
NOTE Les descriptions détaillées de ces méthodes/mesures sont présentées à l’Annexe A.
4.8 Essais des modules logiciels
Les essais des modules logiciels ont pour objectif de vérifier que les modules conçus et mis en œuvre
répondent correctement à la conception de sécurité du logiciel. Dans cette phase, une procédure d’essai
des modules logiciels par rapport à leurs exigences doit être élaborée et les essais doivent être réalisés
conformément à cette procédure.
Pour une approche systématique des essais du module logiciel, l’utilisation d’outils appropriés pour la
gestion et l’automatisation des essais vient à l’appui de ceux qui demandent beaucoup de travail et qui
sont propices aux erreurs. La disponibilité d’outils d’assistance favorise une approche plus exhaustive à
la fois des essais normaux et des essais de régression.
Pour faciliter la vérification, la validation, l’évaluation et la maintenance, il convient que toutes les
données, décisions et justifications soient documentées dans le projet du logiciel. Il convient que la
documentation concernant les modules logiciels comprenne :
— les essais réalisés ;
— les décisions et leurs justifications ;
— les problèmes et leurs solutions.
NOTE L’enregistrement des données est important pour la maintenance des systèmes informatiques, car les
ingénieurs de maintenance ne connaissent pas toujours les justifications de certaines décisions prises pendant le
projet de développement.
Les méthodes ou les mesures appropriées doivent être choisies dans le Tableau 7 pour satisfaire au MPLr
spécifié. Les essais des modules logiciels peuvent être exécutés dans différents environnements, par
exemple :
— modèle dans les essais de communication en boucle ;
— logiciel dans les essais de communication en boucle ;
— processeur dans les essais de communication en boucle ;
— matériel dans les essais de communication en boucle.
Tableau 7 — Essais des modules logiciels
Méthode/mesure Référence MPL = MPL = b MPL = MPL =
r r r r
a , c d e
ISO 19014-4:2025(fr)
1. Analyse de valeur limite A.22 o o + +
2. Analyse du flux de commandes A.23 o o + +
3. Analyse du flux de données A.24 o o + +
4. Exécution d’essai élémentaire à partir de l’analyse de
A.25 o o o +
valeur limite
5. Essais fonctionnels/à la boîte noire (y compris les essais
A.26 + + + +
avec insertion de défauts)
6.a Couverture de l’essai de structure (points d’entrée) o + – –
6.b Couverture de l’essai de structure (instructions) A.27 o + + -
6.c Couverture de l’essai de structure (branches) o + + +
a
7. Classes d’équivalence et essais des partitions d’entrée A.28 o o + +
8. Exécution d’essai élémentaire issue de la génération
A.29 o o o +
d’essai élémentaire fondée sur un modèle
9. Essais des chronologies des réponses et des contraintes de
o + + +
a
mémoire
A.30
a
10. Essais des exigences de performances o + + +
a
11. Essais d’avalanche/de contrainte o o o +
12. Essais d’interface du module logiciel A.31 o o o +
13 Essais comparatifs dos à dos A.32 o o + +
14. Traçabilité directe entre la conception du module logiciel
A.6 o o o +
et les spécifications des essais du module
NOTE Les descriptions détaillées de ces méthodes/mesures sont présentées à l’Annexe A.
a
La personne chargée de l’essai a le choix de ne pas appliquer cette méthode d’essai, mais elle doit l’appliquer au niveau de
l’intégration, lorsque cela est exigé.
4.9 Intégration et essais des modules logiciels
Les objectifs de cette phase de développement du logiciel consistent à :
— intégrer les modules logiciels dans les composants de logiciel jusqu’au logiciel intégré du système de
commande de sécurité ;
— vérifier que les exigences relatives au logiciel sont correctement satisfaites par le logiciel intégré.
Dans cette phase, les étapes d’intégration particulières sont vérifiées par rapport aux exigences de
sécurité du logiciel. Les interfaces entre les modules logiciels et entre les modules logiciels et les
composants de logiciel
...