FprEN ISO 19014-4

SLOVENSKI STANDARD
oSIST prEN ISO 19014-4:2019
01-julij-2019

Stroji za zemeljska dela - Funkcijska varnost - 4. del: Načrtovanje in ocenjevanje

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-

Erdbaumaschinen - Sicherheit - Teil 4: Gestaltung und Beurteilung von Software und

Engins de terrassement - Sécurité - 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

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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

Foreword ........................................................................................................................................................................................................................................iv

Introduction ..................................................................................................................................................................................................................................v

1 Scope ................................................................................................................................................................................................................................. 1

2 Normative references ...................................................................................................................................................................................... 1

3 Terms and d efinitions .................................................................................................................................................................................... 1

4 Software development .................................................................................................................................................................................... 4

4.1 Planning ........................................................................................................................................................................................................ 4

4.2 Artifacts ......................................................................................................................................................................................................... 6

4.3 Software safety requirements specification .................................................................................................................. 7

4.4 Software architecture design ...................................................................................................................................................... 7

4.5 Software module design and coding .................................................................................................................................... 8

4.6 Language, library, and tool selection.................................................................................................................................... 9

4.7 Software module testing ..............................................................................................................................................................10

4.8 Software module integration and testing .....................................................................................................................11

4.9 Software validation ..........................................................................................................................................................................12

5 Software-based parameterization ..................................................................................................................................................13

5.1 General ........................................................................................................................................................................................................13

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 ....................................................................................................................................15

7.1 Several partitions within a single microcontroller ...............................................................................................15

7.2 Several partitions within the scope of an ECU network ...................................................................................16

Annex A (informative) Description of software methods/measures ...............................................................................17

Annex B (normative) Software validation test environments ................................................................................................30

Annex C (informative) Data integrity assurance ...................................................................................................................................33

Annex D (informative) Methods and measures for transmission protection .........................................................34

Annex E (informative) Methods and measures for data protection internal to microcontroller .......36

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

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

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

Any trade name used in this document is information given for the convenience of users and does not

For an explanation on the meaning of ISO specific terms and expressions related to conformity

assessment, as well as information about ISO's adherence to the WTO principles in the Technical

Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information

— Earth-moving machinery – Functional Safety – Part 1: Risk assessment methodology to determine

— Earth-moving machinery – Functional Safety – Part 2: Design and Evaluation of Safety-Related

— Earth-moving machinery – Functional Safety – Part 3: Environmental Testing Requirements

— Earth-moving machinery – Functional Safety – Part 4: Design and evaluation of software and data

— Earth-moving machinery – Functional Safety – Part 5: Table of Performance Levels

This International Standard addresses systems comprising any combination of electrical, electronic,

and programmable electronic components [electrical / electronic / programmable electronic systems

Type-A standards (basis standards) give basic concepts, principles for design and general aspects that

Type-B standards (generic safety standards) deal with one or more safety aspect(s), or one or more

— 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

Type-C standards (machinery safety standards) deal with detailed safety requirements for a particular

This part of ISO 19014 specifies general principles for software development and signal transmission

requirements of safety-related parts of machine-control systems (MCS) in earth-moving machinery

For the purposes of this document, the terms and definitions in ISO 19014-1 and ISO 13849-1 along

Subsystem used in an electronic control system for the transmission of safety-related messages; 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, RF transmission) and the interface between message

Bus system 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/

order in which data has been sent changed during transmission, i.e. the data is not received in the same

Electronic transmission including user data, an address and data to ensure transmission integrity.

Maximum permissible number of senders and receivers that are engaged in the message exchange as

Time from the detection of a safety-related event until the initiation of a safety reaction.

Error due to a fault of a bus participant, whereby old, non-up-to-date messages are repeated at an

Note 1 to entry : This activity can cause a hazardous disturbance of the receiver (e.g. signaling “access door

Unintended modification of the sequence of messages due to a fault of a bus participant.

Note 1 to entry Bus systems can contain elements with stored messages (FIFOs, etc.) that can modify the correct

Unintended modification of messages due to an error of a bus participant or due to errors on the

Unintended delay or prevention of the safety function, caused by an overload of the transmission path

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.

Test of an object that does not require knowledge of its internal structure or its concrete implementation.

Resource entity allocating a portion of memory, I/O devices and CPU usage to one or more tasks.

Note 1 to entry The partitions can be assigned to one or more subsystems within the microcontroller network.

Software fault containment method consisting of assigning resources to specific software components

with the intention of avoiding the propagation of a software fault to multiple partitions.

Identification of a memory location or a peripheral device as an offset from another address.

Independent piece of software that can be independently tested and traced to a specification

Runtime entities that are executed within the resource budget of partitions and with different priorities.

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.

Operating data about a component or a software module during its time in service.

Usage scope of components or software modules that characterizes their behavior during the operating

Note 1 to entry The application of a Time-Triggered Protocol ensures this cycle time is not exceeded.

Fixed time assigned to a system activity to exchange globally-synchronised messages on a bus in a

An incorrect step, process, or data definition in software which causes the system to produce

Documentation that records the understanding and implications of a proposed change.

The task of tracking and controlling changes to the artifacts in the development process.

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.

The main objective of the following requirements is to achieve software reliability by means of readable,

A plan shall be developed to define the relationship between the individual phases of the software

Appropriate methods and measures shall be selected for software development according to the 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.

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 area 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

The first number in this and the other toned boxes signifies the part of ISO 19014, while the second

number, separated from the first by a slash, signifies the clause number of that part, (e.g. “4/4.4” signifies

NOTE This figure is a representation of one possible design method (V-Model). Any organized, proven

development process that meets the requirements of ISO 19014 can be used for the software development

When selecting methods and measures, in addition to manual coding, model-based development can be

With each method or measure in the tables, there is a different level of recommendation for each

In case this method or measure is not used, the related rationale shall be documented during the

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,

— one measure from Measure 1, Measure2 or Measure 3 shall be fulfilled for MPLr= a, b, c;

— otherwise, a rationale shall be provided about the unspecified alternative method/measure to

If a method or measure is not listed in the tables, it may be used; however rationale or justification is

If a software component has any impact on different safety functions with a different MPLr, then the

If the software contains components with different MPLa, or safety-related and non-safety-related

components, then the overall embedded software MPLa shall be limited to the software component

with the lowest MPLa, unless adequate independence between the software components can be

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 lifecycle documentation at module level. When the

previously utilized software component is modified, an impact analysis shall be performed. An action

plan shall be developed and implemented for the overall software lifecycle, based on the result of the

Taking into account the extent and complexity of the project, all artifacts in the individual phases

shown in Figure 1 may be modified. 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

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

b) modified as a consequence of an impact analysis, and only the impacted software shall be

The first artifact applicable to the process is the software development plan. The subsequent artifacts,

— design specification and related verification report, for each SW design phase (descending branch

— test specification and related test report, for each SW testing phase (rising branch of the V-model in

The software safety requirements specification shall describe software safety requirements for the

— functions related to the detection, indication, and handling of faults by the SRP/CS;

— functions related to the detection, indication, and handling of faults in the software;

Note 1 An online test is performed while the system being tested is in use. An offline test is performed

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

— interfaces between the software and the hardware of the electronic control unit.

Appropriate method or measures shall be selected from Table 1 to meet the specified MPLr.

Software architecture that describes the hierarchical structure of all the safety-related software

components of each SCS shall be developed based on the software safety requirements. Appropriate

— specifying, in detail, the behavior of the safety-related software modules that are prescribed by the

— generating readable, testable, and maintainable 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 3 to meet the specified MPLr. There is

If any trusted and verified software elements are available, it is highly recommended.

These methods or measures are not always applicable for graphical modelling notations used in model-based