ISO 25119-3:2010
(Main)Tractors and machinery for agriculture and forestry — Safety-related parts of control systems — Part 3: Series development, hardware and software
Tractors and machinery for agriculture and forestry — Safety-related parts of control systems — Part 3: Series development, hardware and software
ISO 25119-3:2010 provides general principles for the series development, hardware and software of safety-related parts of control systems (SRP/CS) on tractors used in agriculture and forestry, and on self-propelled ride-on machines and mounted, semi-mounted and trailed machines used in agriculture. It can also be applied to municipal equipment (e.g. street‑sweeping machines). It specifies the characteristics and categories required of SRP/CS for carrying out their safety functions. ISO 25119-3:2010 is applicable to the safety-related parts of electrical/electronic/programmable electronic systems (E/E/PES). As these relate to mechatronic systems, it does not specify which safety functions or categories are to be used in a particular case. It is not applicable to non-E/E/PES systems (e.g. hydraulic, mechanic or pneumatic).
Tracteurs et matériels agricoles et forestiers — Parties des systèmes de commande relatives à la sécurité — Partie 3: Développement en série, matériels et logiciels
L'ISO 25119-3:2010 fournit des principes généraux pour le développement en série, les matériels et les logiciels des parties relatives à la sécurité des systèmes de commande (SRP/CS) utilisés sur les tracteurs et matériels agricoles et forestiers, sur les machines automotrices à conducteur porté et sur les machines portées, semi-portées et remorquées utilisées pour les équipements agricoles. Elle peut être également applicable aux équipements municipaux (par exemple machines de balayage des rues). Elle spécifie les caractéristiques et les catégories requises des SRP/CS pour réaliser leurs fonctions de sécurité. L'ISO 25119-3:2010 est applicable aux parties relatives à la sécurité des systèmes électriques/électroniques/électroniques programmables (E/E/PES). Dans la mesure où celles-ci sont liées aux systèmes mécatroniques, elle ne spécifie ni les fonctions de sécurité ni les catégories censées être utilisées dans un cas particulier. Elle n'est pas applicable aux systèmes non-E/E/PES (par exemple hydraulique, mécanique et pneumatique).
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 25119-3
First edition
2010-06-01
Tractors and machinery for agriculture
and forestry — Safety-related parts
of control systems —
Part 3:
Series development, hardware
and software
Tracteurs et matériels agricoles et forestiers — Parties des systèmes
de commande relatives à la sécurité —
Partie 3: Développement en série, matériels et logiciels
Reference number
ISO 25119-3:2010(E)
©
ISO 2010
---------------------- Page: 1 ----------------------
ISO 25119-3:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 25119-3:2010(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviated terms .2
5 System design .3
5.1 Objectives .3
5.2 General .3
5.3 Prerequisites.4
5.4 Requirements.4
6 Hardware .8
6.1 Objectives .8
6.2 General .8
6.3 Prerequisites.8
6.4 Requirements.8
6.5 Hardware categories .10
6.6 Work products .10
7 Software.11
7.1 Software development planning .11
7.2 Software safety requirements specification.14
7.3 Software architecture and design.18
7.4 Software module design and implementation.21
7.5 Software module testing.30
7.6 Software integration and testing .39
7.7 Software safety validation .41
7.8 Software-based parameterization.43
Annex A (informative) Example of agenda for assessment of functional safety at AgPL = e .46
Annex B (informative) Independence by software partitioning.48
Bibliography.57
© ISO 2010 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 25119-3:2010(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 25119-3 was prepared by Technical Committee ISO/TC 23, Tractors and machinery for agriculture and
forestry, Subcommittee SC 19, Agricultural electronics.
ISO 25119 consists of the following parts, under the general title Tractors and machinery for agriculture and
forestry — Safety-related parts of control systems:
⎯ Part 1: General principles for design and development
⎯ Part 2: Concept phase
⎯ Part 3: Series development, hardware and software
⎯ Part 4: Production, operation, modification and supporting processes
iv © ISO 2010 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 25119-3:2010(E)
Introduction
ISO 25119 sets out an approach to the design and assessment, for all safety life cycle activities, of
safety-relevant systems comprising electrical and/or electronic and/or programmable electronic components
(E/E/PES) on tractors used in agriculture and forestry, and on self-propelled ride-on machines and mounted,
semi-mounted and trailed machines used in agriculture. It is also applicable to municipal equipment. It covers
the possible hazards caused by the functional behaviour of E/E/PES safety-related systems, as distinct from
hazards arising from the E/E/PES equipment itself (electric shock, fire, nominal performance level of E/E/PES
dedicated to active and passive safety, etc.).
The control system parts of the machines concerned are frequently assigned to provide the critical functions of
the safety-related parts of control systems (SRP/CS). These can consist of hardware or software, can be
separate or integrated parts of a control system, and can either perform solely critical functions or form part of
an operational function.
In general, the designer (and to some extent, the user) will combine the design and validation of these
SRP/CS as part of the risk assessment. The objective is to reduce the risk associated with a given hazard (or
hazardous situation) under all conditions of use of the machine. This can be achieved by applying various
protective measures (both SRP/CS and non-SRP/CS) with the end result of achieving a safe condition.
ISO 25119 allocates the ability of safety-related parts to perform a critical function under foreseeable
conditions into five performance levels. The performance level of a controlled channel depends on several
factors, including system structure (category), the extent of fault detection mechanisms (diagnostic coverage),
the reliability of components (mean time to dangerous failure, common-cause failure), design processes,
operating stress, environmental conditions and operation procedures. Three types of failures are considered:
systematic, common-cause and random.
In order to guide the designer during design, and to facilitate the assessment of the achieved performance
level, ISO 25119 defines an approach based on a classification of structures with different design features and
specific behaviour in case of a fault.
The performance levels and categories can be applied to the control systems of all kinds of mobile machines:
from simple systems (e.g. auxiliary valves) to complex systems (e.g. steer by wire), as well as to the control
systems of protective equipment (e.g. interlocking devices, pressure sensitive devices).
ISO 25119 adopts a customer risk-based approach for the determination of the risks, while providing a means
of specifying the target performance level for the safety-related functions to be implemented by E/E/PES
safety-related channels. It gives requirements for the whole safety life cycle of E/E/PES (design, validation,
production, operation, maintenance, decommissioning), necessary for achieving the required functional safety
for E/E/PES that are linked to the performance levels.
© ISO 2010 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 25119-3:2010(E)
Tractors and machinery for agriculture and forestry —
Safety-related parts of control systems —
Part 3:
Series development, hardware and software
1 Scope
This part of ISO 25119 provides general principles for the series development, hardware and software of
safety-related parts of control systems (SRP/CS) on tractors used in agriculture and forestry, and on self-
propelled ride-on machines and mounted, semi-mounted and trailed machines used in agriculture. It can also
be applied to municipal equipment (e.g. street-sweeping machines). It specifies the characteristics and
categories required of SRP/CS for carrying out their safety functions.
This part of ISO 25119 is applicable to the safety-related parts of electrical/electronic/programmable electronic
systems (E/E/PES). As these relate to mechatronic systems, it does not specify which safety functions or
categories are to be used in a particular case.
It is not applicable to non-E/E/PES systems (e.g. hydraulic, mechanic or pneumatic).
2 Normative references
The following referenced documents are indispensable for the application 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 25119-1:2010, Tractors and machinery for agriculture and forestry — Safety-related parts of control
systems — Part 1: General principles for design and development
ISO 25119-2:2010, Tractors and machinery for agriculture and forestry — Safety-related parts of control
systems — Part 2: concept phase
ISO 25119-4:2010, Tractors and machinery for agriculture and forestry — Safety-related parts of control
systems — Part 4: Production, operation, modification and supporting processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 25119-1 apply.
© ISO 2010 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 25119-3:2010(E)
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
AgPL agricultural performance level
AgPL required agricultural performance level
r
CAD computer-aided design
Cat hardware category
CCF common-cause failure
DC diagnostic coverage
DC average diagnostic coverage
avg
ECU electronic control unit
ETA event tree analysis
E/E/PES electrical/electronic/programmable electronic systems
EMC electromagnetic compatibility
EUC equipment under control
FMEA failure mode and effects analysis
FMECA failure mode effects and criticality analysis
EPROM erasable programmable read only memory
FSM functional safety management
FTA fault tree analysis
HAZOP hazard and operability study
HIL hardware in the loop
MTTF mean time to failure
MTTF mean time to dangerous failure
d
MTTF mean time to dangerous failure for each channel
dC
PES programmable electronic system
QM quality measures
RAM random-access memory
SOP start of production
SRL software requirement level
SRP safety-related parts
SRP/CS safety-related parts of control systems
SRS safety-related system
UML unified modelling language.
2 © ISO 2010 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 25119-3:2010(E)
5 System design
5.1 Objectives
The objective is to define a development process for producing a design that fulfils the safety requirements for
the entire safety-related system.
5.2 General
Safety requirements constitute all requirements aimed at achieving and ensuring functional safety. During the
safety life cycle, safety requirements are detailed and specified in ever greater detail at hierarchical levels.
The different levels for safety requirements are illustrated in Figure 1. For the overall representation of the
procedure for developing safety requirements, see also 5.4. In order to support management of safety
requirements, the use of suitable tools for requirements management is recommended.
Key
result
verification
validation
a
The first of two numbers separated by a slash refers to the respective part of ISO 25119, and the second to the clause
in that document: 2/6 is ISO 25119-2:2010/Clause 6, 3/5 is ISO 25119-3:2010/Clause 5, and so on.
Figure 1 — Structuring of safety requirements
© ISO 2010 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 25119-3:2010(E)
5.3 Prerequisites
Before beginning system design, define the safety-related function requirements, application and operation
environment.
5.4 Requirements
5.4.1 Structuring safety requirements
The functional safety concept specifies the basic functioning of the safety-related system with which the safety
goals are to be fulfilled. The basic allocation of functional safety requirements to the system architecture is
specified by the technical safety concept in the form of technical safety requirements. This system architecture
is comprised of both hardware and software.
The hardware safety requirements refine and solidify the requirements of the technical safety concept.
Clause 6 describes how to specify the hardware requirements in detail.
The software safety requirements are derived from the requirements of the technical safety concept and the
underlying hardware. The requirements for the software defined in Clause 7 shall be taken into account.
This clause specifies the approach to be used in the specification of the safety concept requirements during
system design, thereby providing a basis for error-free system design.
5.4.2 Functional safety concept
5.4.2.1 General requirements of functional safety concept
Safety functions are normally identified during the system risk analysis, and the functional safety concept
document includes the functional safety requirements for the system.
The implementation for each safety concept requirement shall consider the following.
⎯ Feasibility
When listing functional safety requirements, attention shall be paid to the feasibility of the requirement,
considering constraints, such as available technology, as well as financial and time resources. The
persons in charge of implementation shall understand and accept the technical safety requirements.
⎯ Unambiguousness
The functional safety requirements shall be formulated as precisely and unambiguously as possible.
NOTE A functional safety requirement is unambiguously formulated when it permits only one interpretation by the
anticipated readers.
⎯ Consistency
Functional safety requirements shall not be self-contradicting (internal consistency), nor shall they
contradict other requirements (external consistency).
Analyses of the requirements and comparisons between different requirements are necessary to ensure
external consistency. This is a requirement management task.
⎯ Completeness
The functional safety concept shall take all relevant norms, standards and statutory regulations into
account.
4 © ISO 2010 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 25119-3:2010(E)
The functional safety concept shall take into account all relevant safety goals derived from the risk
analysis according to ISO 25119-2.
The completeness of the functional safety concept increases iteratively during system design. To ensure
completeness:
1) the version of the functional safety concept and the version of the relevant underlying sources shall
be specified;
2) the requirements from change management (see ISO 25119-4:2010, Clause 10) shall be met and,
for this reason, the functional safety requirements shall be structured and formulated to provide
support for a modification process;
3) the functional safety requirements shall be reviewed (see ISO 25119-4:2010, Clause 6).
The functional safety concept shall consider all phases of the life cycle (including production, customer
operation, servicing and decommissioning).
5.4.2.2 Specification of the functional safety concept
This clause presents the information that is required to be specified in the functional safety concept. The
functional safety concept may be derived from the machine failure scenarios evaluated during a risk analysis.
Each failure scenario description shall include the following:
⎯ environmental conditions (moving on an ice covered road, up-hill, down-hill, weather, etc.);
⎯ machine conditions (engine running, in-gear, standing still, etc.);
⎯ resulting AgPL;
⎯ safe state descriptions (engine stopped, valve off, transmission in park, continue function at reduced
performance, etc.).
5.4.3 Technical safety concept
5.4.3.1 General requirements of technical safety concept
The technical safety concept document includes the technical safety requirements for the system.
Each technical safety concept shall be associated (e.g. by cross-reference) with higher-level safety
requirements, which may be
⎯ other technical safety requirements,
⎯ functional safety requirements, or
⎯ safety goals and objectives.
NOTE Traceability can be greatly facilitated by the use of suitable requirement management tools.
Just as for the functional safety concept, the implementation of each technical safety concept requirement
shall take account of feasibility, unambiguousness, consistency and completeness.
© ISO 2010 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 25119-3:2010(E)
⎯ Feasibility
When listing technical safety requirements, attention shall be paid to the feasibility of the requirement
considering constraints, such as available technology, as well as financial and time resources. Those in
charge of implementation shall understand and accept the technical safety requirements.
⎯ Unambiguousness
The technical safety requirements shall be formulated as precisely and unambiguously as possible.
NOTE A technical safety requirement is unambiguously formulated when it permits only one interpretation by the
anticipated readers.
⎯ Consistency
Technical safety requirements shall not be self-contradicting (internal consistency), nor shall they
contradict other requirements (external consistency).
Analyses of the requirements and comparisons between different requirements are necessary to ensure
external consistency. This is a requirement management task.
⎯ Completeness
The technical safety concept shall take the following into account:
1) all safety objectives and functional safety requirements;
2) all relevant norms, standards and statutory regulations;
3) the relevant results from safety analysis tools (FMEA, FTA, etc.); the safety analysis provides
iterative support for the technical safety concept during system development.
The completeness of the technical safety concept increases iteratively during system design. To ensure
completeness:
4) the version of the technical safety concept and the version of the relevant underlying sources shall be
specified;
5) the requirements from change management (see ISO 25119-4:2010, Clause 10) shall be met and,
for this reason, the technical safety requirements shall be structured and formulated to provide
support for a modification process;
6) the technical safety requirements shall be reviewed (see ISO 25119-4:2010, Clause 6).
The technical safety concept shall consider all phases of the life cycle (including production, customer
operation, servicing and decommissioning).
5.4.3.2 Specification of the technical safety concept
5.4.3.2.1 General
The technical safety concept shall include hardware and software safety requirements sufficient for the design
of the unit of observation, and shall be determined in accordance with 5.4.3.1.
6 © ISO 2010 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 25119-3:2010(E)
5.4.3.2.2 States and times
The behaviour of the unit of observation, its modules and their interfaces shall be specified for all relevant
operating states, including
⎯ start-up,
⎯ normal operation,
⎯ shut-down,
⎯ restart after reset, and
⎯ reasonably foreseeable unusual operating states (e.g. degraded operating states).
In particular, failure behaviour and the required reaction shall be described exactly. Additional emergency
operation functions may be included.
The technical safety concept shall specify a safe state for each functional safety requirement, the transition to
the safe state, and the maintenance of the safe state. In particular, it shall be specified whether shutting off the
unit of observation immediately represents a safe state, or if a safe state can only be attained by a controlled
shut down.
The technical safety concept shall specify for each functional safety requirement the maximum time that may
elapse between the occurrence of an error and the attainment of a safe state (response time). All response
times for subsystems and sub-functions shall be specified in the technical safety concept.
If no safe state can be achieved by a direct shut down, a time shall be defined during which a special
emergency operation function has to be sustained for all subsystems and sub-functions. This emergency
operation function shall be documented in the technical safety concept.
5.4.3.2.3 Safety architecture, interfaces and marginal conditions
The safety architecture and its sub-modules shall be described. In particular, the technical measures shall be
specified. The technical safety concept shall separately describe the following modules (as applicable):
⎯ sensor system, separate for each physical parameter recorded;
⎯ miscellaneous digital and analogue input and output units;
⎯ processing, separate for each arithmetic unit/discrete logical unit;
⎯ actuator system, separate for each actuator;
⎯ displays, separate for each indicator unit;
⎯ miscellaneous electromechanical components;
⎯ signal transmission between modules;
⎯ signal transmission from/to systems external to the unit of observation;
⎯ power supply.
The interfaces between the modules of the unit of observation, interfaces to other systems and functions in
the machine, as well as user interfaces, shall be specified.
© ISO 2010 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 25119-3:2010(E)
Limitations and marginal conditions of the unit of observation shall be specified. This applies in particular to
extreme values for all ambient conditions in all phases of the life cycle.
6 Hardware
6.1 Objectives
The objective is to define acceptable hardware architectures for safety-related control systems.
6.2 General
Improving the hardware structure of the safety-related parts of a control system can provide measures for
avoiding, detecting or tolerating faults. Practical measures can include redundancy, diversity and monitoring.
In general, the following fault criteria should be taken into account.
⎯ If, as a consequence of a fault, further components fail, the first fault and all following faults are
considered to be a single fault.
⎯ Two or more separate faults having a common cause are regarded as a single fault (known as common
cause failure).
⎯ The simultaneous occurrence of two independent faults is considered highly unlikely.
6.3 Prerequisites
The prerequisite is AgPL , determined for each safety function to be realized by the hardware.
r
6.4 Requirements
The hardware development process shall begin at the system level where safety functions and associated
requirements are identified (see Figure 2).
The hardware safety analysis shall be used to identify the performance level (AgPL ) for each system safety
r
function (see ISO 25119-2).
The designer shall group functions into appropriate architectures (hardware category) with associated
MTTF , DC and CCF.
dC
The system may be broken down into subsystems for easier development.
Each phase of the development cycle shall be verified.
8 © ISO 2010 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 25119-3:2010(E)
Key
result
verification
validation
a
The first of two numbers separated by a slash refers to this part of ISO 25119 and the second to Clause 6.
Figure 2 — Hardware development V-model
The design procedure for the hardware system architecture is as follows.
a) Select a hardware category (see ISO 25119-2:2010, Annex A).
b) Identify the component operating environment and stress level.
c) Select components.
d) Calculate and verify that the MTTF meets the required level (see ISO 25119-2:2010, Annex B).
dC
e) Determine and verify that the DC meets the required level (see ISO 25119-2:2010, Annex C).
f) Consider CCF (see ISO 25119-2:2010, Annex D).
g) Consider systematic failures (see ISO 25119-2:2010, Annex E).
h) Consider other safety functions (see ISO 25119-2:2010, Annex F).
NOTE Iteration could be required for the above steps.
© ISO 2010 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO 25119-3:2010(E)
6.5 Hardware categories
The safety-related parts of control systems shall be designed in accordance with the requirements of one or
more of the five categories specified in ISO 25119-2:2010, Annex A.
When a safety function is realized by an integrated combination of multiple hardware categories, the resulting
safety function, AgPL, is limited by the overall hardware category: MTTF , DC, SRL, CCF, etc. (see Figure 3).
dC
To determine the overall SRL, see 7.3.4.7.
Key
I input device (e.g. sensor) S interconnecting signal input
I
L logic S interconnecting signal output
O
O output device (e.g. actuator) m monitoring
TE test equipment Cat hardware category
OTE output of test equipment
Figure 3 — Integrated system with maximum AgPL for category 2
6.6 Work products
The following work products are applicable to hardware design:
a) hardware safety validation test plan;
b) hardware safety validation test specification;
c) hardware safety validation test results;
d) hardware system in
...
NORME ISO
INTERNATIONALE 25119-3
Première édition
2010-06-01
Tracteurs et matériels agricoles et
forestiers — Parties des systèmes de
commande relatives à la sécurité —
Partie 3:
Développement en série, matériels
et logiciels
Tractors and machinery for agriculture and forestry — Safety-related
parts of control systems —
Part 3: Series development, hardware and software
Numéro de référence
ISO 25119-3:2010(F)
©
ISO 2010
---------------------- Page: 1 ----------------------
ISO 25119-3:2010(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2010
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2010 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 25119-3:2010(F)
Sommaire Page
Avant-propos .iv
Introduction.v
1 Domaine d'application .1
2 Références normatives.1
3 Termes et définitions .1
4 Termes abrégés .2
5 Conception du système.3
5.1 Objectifs .3
5.2 Généralités .3
5.3 Conditions préalables.4
5.4 Exigences.4
6 Matériel .8
6.1 Objectifs .8
6.2 Généralités .8
6.3 Conditions préalables.8
6.4 Exigences.8
6.5 Catégories de matériel.10
6.6 Produits fabriqués.10
7 Logiciel .11
7.1 Planification de développement du logiciel.11
7.2 Spécification relative aux exigences de sécurité du logiciel.14
7.3 Architecture et conception du logiciel .18
7.4 Conception et mise en œuvre du module du logiciel.21
7.5 Essai du module du logiciel .30
7.6 Intégration et essai du logiciel.39
7.7 Validation de sécurité du logiciel .41
7.8 Paramétrage fondé sur le logiciel.44
Annexe A (informative) Exemple de programme relatif à une évaluation de la sécurité
fonctionnelle au niveau AgPL = e .46
Annexe B (informative) Indépendance par partitionnement du logiciel.48
Bibliographie.57
© ISO 2010 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 25119-3:2010(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 25119-3 a été élaborée par le comité technique ISO/TC 23, Tracteurs et matériels agricoles et forestiers,
sous-comité SC 19, Électronique en agriculture.
L'ISO 25119 comprend les parties suivantes, présentées sous le titre général Tracteurs et matériels agricoles
et forestiers — Parties des systèmes de commande relatives à la sécurité:
⎯ Partie 1: Principes généraux pour la conception et le développement
⎯ Partie 2: Phase de projet
⎯ Partie 3: Développement en série, matériels et logiciels
⎯ Partie 4: Procédés de production, de fonctionnement, de modification et d'entretien
iv © ISO 2010 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 25119-3:2010(F)
Introduction
L'ISO 25119 établit une approche pour la conception et l'évaluation de toutes les activités relatives au cycle
de vie de sécurité des systèmes relatifs à la sécurité constitués de composants électriques et/ou
électroniques et/ou électroniques programmables (E/E/PES) utilisés sur les tracteurs agricoles et forestiers,
sur les machines automotrices à conducteur porté et sur les machines portées, semi-portées et remorquées
utilisées en agriculture. Elle est également applicable aux équipements municipaux. Elle couvre les éventuels
phénomènes dangereux dus au comportement fonctionnel des systèmes E/E/PES relatifs à la sécurité,
indépendamment des phénomènes dangereux dus à l'équipement E/E/PES lui-même (par exemple choc
électrique, incendie, niveau de performance nominal du E/E/PES dédié à la sécurité passive et active).
Les parties des systèmes de commande des machines concernées sont fréquemment prévues pour assurer
les fonctions critiques des parties relatives à la sécurité des systèmes de commande (SRP/CS). Ces parties
peuvent être constituées de matériels et de logiciels, elles peuvent être des parties isolées du système de
commande ou en faire partie intégrante, et elles peuvent soit assurer uniquement des fonctions critiques, soit
faire partie d'une fonction opérationnelle.
En général, le concepteur (et, dans une certaine mesure, l'utilisateur) associe la conception et la validation de
ces SRP/CS dans le cadre de l'appréciation du risque. L'objectif est de réduire le risque lié à un phénomène
dangereux donné (ou à une situation dangereuse) dans toutes les conditions d'utilisation de la machine. Cela
peut être réalisé en appliquant diverses mesures de prévention (aussi bien SRP/CS que non-SRP/CS) dans
le but final de réaliser une condition de sécurité.
L'ISO 25119 aborde la capacité des parties relatives à la sécurité à réaliser une fonction critique dans des
conditions prévisibles en cinq niveaux de performance. Le niveau de performance d'un canal contrôlé dépend
de plusieurs facteurs, tels que la structure du système (catégorie), l'étendue du mécanisme de détection de
défaut (couverture de diagnostic), la fiabilité des composants (temps moyen avant défaillance dangereuse,
défaillances de cause commune), le processus de conception, la contrainte en service, les conditions
environnementales et les procédures de fonctionnement. Trois types de défaillances sont considérées: les
défaillances systématiques, les défaillances de cause commune et les défaillances aléatoires.
Afin de guider le concepteur pendant la conception et faciliter l'évaluation du niveau de performance atteint,
l'ISO 25119 définit une approche fondée sur une classification de structures avec différentes caractéristiques
de conception et un comportement spécifique en cas de défaut.
Les niveaux et catégories de performance peuvent être appliqués aux systèmes de commande de tous les
types de machines mobiles, des systèmes simples (par exemple valves auxiliaires) aux systèmes complexes
(par exemple transmission par fil), ainsi qu'aux systèmes de commande d'équipements de protection (par
exemple dispositifs de verrouillage ou dispositifs sensibles à la pression).
l'ISO 25119 adopte une approche fondée sur le risque du client pour déterminer les risques, tout en
fournissant un moyen permettant de spécifier le niveau de performance cible pour les fonctions relatives à la
sécurité à mettre en œuvre par les canaux E/E/PES relatifs à la sécurité. Elle fournit les exigences pour tout le
cycle de vie de sécurité des E/E/PES (conception, validation, production, fonctionnement, maintenance,
démantèlement) nécessaires pour assurer la sécurité fonctionnelle requise pour les E/E/PES liés aux niveaux
de performance.
© ISO 2010 – Tous droits réservés v
---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 25119-3:2010(F)
Tracteurs et matériels agricoles et forestiers — Parties
des systèmes de commande relatives à la sécurité —
Partie 3:
Développement en série, matériels et logiciels
1 Domaine d'application
La présente partie de l'ISO 25119 fournit des principes généraux pour le développement en série, les
matériels et les logiciels des parties relatives à la sécurité des systèmes de commande (SRP/CS) utilisés sur
les tracteurs agricoles et forestiers, sur les machines automotrices à conducteur porté et sur les machines
portées, semi-portées et remorquées utilisées en agriculture. Elle peut être également applicable aux
équipements municipaux (par exemple machines de balayage des rues). Elle spécifie les caractéristiques et
les catégories requises des SRP/CS pour réaliser leurs fonctions de sécurité.
La présente partie de l'ISO 25119 est applicable aux parties relatives à la sécurité des systèmes
électriques/électroniques/électroniques programmables (E/E/PES). Dans la mesure où celles-ci sont liées aux
systèmes mécatroniques, elle ne spécifie ni les fonctions de sécurité ni les catégories censées être utilisées
dans un cas particulier.
Elle n'est pas applicable aux systèmes non-E/E/PES (par exemple hydraulique, mécanique et pneumatique).
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application 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 (y compris les éventuels amendements) s'applique.
ISO 25119-1:2010, Tracteurs et matériels agricoles et forestiers — Parties des systèmes de commande
relatives à la sécurité — Partie 1: Principes généraux pour la conception et le développement
ISO 25119-2:2010, Tracteurs et matériels agricoles et forestiers — Parties des systèmes de commande
relatives à la sécurité — Partie 2: Phase de projet
ISO 25119-4:2010, Tracteurs et matériels agricoles et forestiers — Parties des systèmes de commande
relatives à la sécurité — Partie 4: Procédés de production, de fonctionnement, de modification et d'entretien
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions données dans l'ISO 25119-1 s'appliquent.
© ISO 2010 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO 25119-3:2010(F)
4 Termes abrégés
Pour les besoins du présent document, les termes abrégés suivants s'appliquent.
AgPL niveau de performance agricole (agricultural performance level)
AgPL niveau de performance agricole requis (required agricultural performance level)
r
CAD conception assistée par ordinateur (computer-aided design)
Cat catégorie de matériel
CCF défaillance de cause commune (common-cause failure)
DC couverture de diagnostic (diagnostic coverage)
DC couverture moyenne de diagnostic (average diagnostic coverage)
avg
UCE unité de commande électronique
ETA analyse par arbre d'événements (event tree analysis)
E/E/PES systèmes électriques/électroniques/électroniques programmables (electrical/electronic/
programmable electronic systems)
CEM compatibilité électromagnétique
EUC équipement commandé (equipment under control)
AMDE analyse des modes de défaillance et de leurs effets
AMDEC analyse des modes de défaillance, de leurs effets et de leur criticité
EPROM mémoire morte reprogrammable (erasable programmable read-only memory)
FSM gestion de la sécurité fonctionnelle (functional safety management)
FTA analyse par arbre de panne (fault tree analysis)
HAZOP étude des phénomènes dangereux et de l'exploitabilité (hazard and operability study)
HIL matériel incorporé (hardware in the loop)
MTTF temps moyen avant défaillance (mean time to failure)
MTTF temps moyen avant défaillance dangereuse (mean time to dangerous failure)
d
MTTF temps moyen avant défaillance dangereuse pour chaque canal (mean time to dangerous failure
dC
for each channel)
PES système électronique programmable (programmable electronic system)
QM management (mesures) de la qualité (quality measures)
RAM mémoire vive (random-access memory)
SOP démarrage de la production (start of production)
SRL niveau d'exigence du logiciel (software requirement level)
SRP parties relatives à la sécurité (safety-related parts)
SRP/CS parties relatives à la sécurité d'un système de commande (safety-related parts of control
systems)
SRS système relatif à la sécurité (safety-related system)
UML langage de modélisation UML (unified modelling language)
2 © ISO 2010 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 25119-3:2010(F)
5 Conception du système
5.1 Objectifs
L'objectif est de définir un processus de développement pour la production d'une conception qui réponde aux
exigences de sécurité pour tout le système relatif à la sécurité.
5.2 Généralités
Les exigences de sécurité constituent toutes les exigences visant à réaliser et à assurer la sécurité
fonctionnelle. Pendant le cycle de vie de sécurité, les exigences de sécurité sont détaillées et spécifiées de
manière plus approfondie par niveaux hiérarchiques. Les différents niveaux relatifs aux exigences de sécurité
sont illustrés à la Figure 1. Pour la représentation globale de la procédure de développement des exigences
de sécurité, voir également 5.4. Afin de prendre en charge la gestion des exigences de sécurité, il est
recommandé d'utiliser des outils appropriés pour la gestion des exigences.
Légende
résultat
vérification
validation
a
Dans l'ensemble de ces boîtes, le premier chiffre correspond à la partie de l'ISO 25119, le deuxième, séparé par
une barre oblique, à l'article de la partie, par exemple, «2/6» signifie ISO 25119-2:2010, Article 6, «3/5» signifie
ISO 25119-3:2010, Article 5, et ainsi de suite.
Figure 1 — Structuration des exigences de sécurité
© ISO 2010 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO 25119-3:2010(F)
5.3 Conditions préalables
Avant de commencer la conception du système, définir les exigences de la fonction relative à la sécurité,
l'application et l'environnement de fonctionnement.
5.4 Exigences
5.4.1 Structuration des exigences de sécurité
Le concept de sécurité fonctionnelle spécifie le fonctionnement de base du système relatif à la sécurité avec
lequel les objectifs de sécurité doivent être atteints. L'affectation de base des exigences de sécurité
fonctionnelle à l'architecture du système est spécifiée par le concept de sécurité technique sous la forme
d'exigences de sécurité technique. Cette architecture du système comprend aussi bien des matériels que des
logiciels.
Les exigences de sécurité du matériel affinent et solidifient les exigences du concept de sécurité technique.
L'Article 6 décrit comment spécifier en détail les exigences du matériel.
Les exigences de sécurité du logiciel sont dérivées des exigences du concept de sécurité technique et du
matériel sous-jacent. Les exigences relatives au logiciel définies dans l'Article 7 doivent être prises en compte.
Le présent article spécifie l'approche à suivre dans la spécification des exigences du concept de sécurité
pendant la conception du système, fournissant ainsi une base pour la conception d'un système sans erreurs.
5.4.2 Concept de sécurité fonctionnelle
5.4.2.1 Exigences générales du concept de sécurité fonctionnelle
Les fonctions de sécurité sont normalement identifiées pendant l'analyse de risque du système, et le
document de concept de sécurité fonctionnelle contient les exigences de sécurité fonctionnelle pour le
système.
La mise en œuvre de chaque exigence de concept de sécurité doit considérer les éléments suivants.
⎯ Faisabilité
En répertoriant les exigences de sécurité fonctionnelle, il faut veiller à la faisabilité de l'exigence en
considérant les contraintes, telles que la technologie disponible, ainsi que les ressources financières et
temporelles. Les personnes en charge de la mise en œuvre doivent comprendre et accepter les
exigences de sécurité technique.
⎯ Caractère non ambigu
Les exigences de sécurité fonctionnelle doivent être formulées de façon aussi précise et non ambiguë
que possible.
NOTE Une exigence de sécurité fonctionnelle est formulée sans ambiguïté lorsqu'elle ne permet qu'une seule
interprétation par les lecteurs prévus.
⎯ Cohérence
Les exigences de sécurité fonctionnelle ne doivent pas être autocontradictoires (cohérence interne) ni
contredire d'autres exigences (cohérence externe).
L'analyse des exigences et les comparaisons entre différentes exigences sont nécessaires pour assurer
la cohérence externe. Il s'agit d'une tâche de gestion d'exigence.
⎯ Exhaustivité
Le concept de sécurité fonctionnelle doit prendre en compte toutes les normes et réglementations
statutaires pertinentes.
4 © ISO 2010 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 25119-3:2010(F)
Le concept de sécurité fonctionnelle doit prendre en compte tous les objectifs de sécurité pertinents issus
de l'analyse de risque conformément à l'ISO 25119-2.
L'exhaustivité du concept de sécurité fonctionnelle augmente itérativement pendant la conception du
système. Pour assurer l'exhaustivité:
1) la version du concept de sécurité fonctionnelle et la version des sources sous-jacentes pertinentes
doivent être spécifiées;
2) les exigences issues de la gestion des modifications (voir ISO 25119-4:2010, Article 10) doivent être
satisfaites et, pour cette raison, les exigences de sécurité fonctionnelle doivent être structurées et
formulées pour pouvoir prendre en charge un processus de modification;
3) les exigences de sécurité fonctionnelle doivent être revues (voir ISO 25119-4:2010, Article 6).
Le concept de sécurité fonctionnelle doit considérer toutes les phases du cycle de vie (comprenant la
production, l'opération du client, l'entretien courant et le démantèlement).
5.4.2.2 Spécification du concept de sécurité fonctionnelle
Le présent article présente les informations qui sont censées être spécifiées dans le concept de sécurité
fonctionnelle. Le concept de sécurité fonctionnelle peut être dérivé des scénarios de défaillance de la machine
évalués pendant l'analyse du risque.
Chaque description de scénario de défaillance doit inclure les éléments suivants:
⎯ conditions environnementales (déplacement sur une route verglacée, montée, descente, conditions
météorologiques, etc.);
⎯ conditions de la machine (moteur en marche, vitesse enclenchée, à l'arrêt, etc.);
⎯ niveau AgPL qui en résulte;
⎯ descriptions de l'état de sécurité (moteur arrêté, vanne arrêtée, transmission immobilisée, fonction
continue à performance réduite, etc.).
5.4.3 Concept de sécurité technique
5.4.3.1 Exigences générales du concept de sécurité technique
Le document de concept de sécurité technique contient les exigences de sécurité technique pour le système.
Chaque concept de sécurité technique doit être associé (par exemple par référence croisée) à des exigences
de sécurité de niveau supérieur qui peuvent être
⎯ d'autres exigences de sécurité technique,
⎯ des exigences de sécurité fonctionnelle, ou
⎯ des buts et objectifs de sécurité.
NOTE La traçabilité peut être grandement facilitée par l'utilisation d'outils de gestion d'exigence appropriés.
De même que pour le concept de sécurité fonctionnelle, la mise en œuvre de chaque exigence de concept de
sécurité doit considérer la faisabilité, le caractère non ambigu, la cohérence et l'exhaustivité.
© ISO 2010 – Tous droits réservés 5
---------------------- Page: 10 ----------------------
ISO 25119-3:2010(F)
⎯ Faisabilité
En répertoriant les exigences de sécurité technique, il faut veiller à la faisabilité de l'exigence en
considérant les contraintes, telles que la technologie disponible, ainsi que les ressources financières et
temporelles. Les personnes en charge de la mise en œuvre doivent comprendre et accepter les
exigences de sécurité technique.
⎯ Caractère non ambigu
Les exigences de sécurité technique doivent être formulées de façon aussi précise et non ambiguë que
possible.
NOTE Une exigence de sécurité technique est formulée sans ambiguïté lorsqu'elle ne permet qu'une seule
interprétation par les lecteurs prévus.
⎯ Cohérence
Les exigences de sécurité technique ne doivent pas être autocontradictoires (cohérence interne) ni
contredire d'autres exigences (cohérence externe).
L'analyse des exigences et les comparaisons entre différentes exigences sont nécessaires pour assurer
la cohérence externe. Il s'agit d'une tâche de gestion d'exigence.
⎯ Exhaustivité
Le concept de sécurité technique doit prendre en compte les éléments suivants:
1) tous les objectifs de sécurité et les exigences de sécurité fonctionnelle,
2) toutes les normes et réglementations statutaires pertinentes,
3) les résultats pertinents issus des outils d'analyse de sécurité (AMDE, FTA, etc.); l'analyse de sécurité
fournit un support itératif pour le concept de sécurité technique pendant le développement du
système.
L'exhaustivité du concept de sécurité technique augmente itérativement pendant la conception du système.
Pour assurer l'exhaustivité:
4) la version du concept de sécurité technique et la version des sources sous-jacentes pertinentes
doivent être spécifiées;
5) les exigences issues de la gestion des modifications (voir ISO 25119-4:2010, Article 10) doivent être
satisfaites et, pour cette raison, les exigences de sécurité technique doivent être structurées et
formulées pour pouvoir prendre en charge un processus de modification;
6) les exigences de sécurité technique doivent être revues (voir ISO 25119-4:2010, Article 6).
Le concept de sécurité technique doit considérer toutes les phases du cycle de vie (comprenant la production,
l'opération du client, l'entretien courant et le démantèlement).
5.4.3.2 Spécification du concept de sécurité technique
5.4.3.2.1 Généralités
Le concept de sécurité technique doit comprendre les exigences de sécurité du matériel et du logiciel
suffisantes pour la conception de l'unité d'observation, et doit être déterminé conformément à 5.4.3.1.
6 © ISO 2010 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 25119-3:2010(F)
5.4.3.2.2 États et temps
Le comportement de l'unité d'observation et de ses modules ainsi que leurs interfaces doivent être spécifiés
pour tous les états de fonctionnement pertinents, y compris
⎯ le démarrage,
⎯ le fonctionnement normal,
⎯ l'arrêt,
⎯ le redémarrage après réinitialisation, et
⎯ les états de fonctionnement inhabituels raisonnablement prévisibles (par exemple les états de
fonctionnement dégradés).
En particulier, le comportement de défaillance et la réaction requise doivent être décrits avec exactitude. Des
fonctions de fonctionnement d'urgence supplémentaires peuvent être incluses.
Le concept de sécurité technique doit spécifier un état de sécurité pour chaque exigence de sécurité
fonctionnelle, la transition vers l'état de sécurité et la maintenance de l'état de sécurité. En particulier, il doit
être spécifié si l'arrêt de l'unité d'observation représente immédiatement un état de sécurité, ou si un état de
sécurité ne peut être atteint que par un arrêt contrôlé.
Le concept de sécurité technique doit spécifier, pour chaque exigence de sécurité fonctionnelle, le temps
maximal susceptible de s'écouler entre l'occurrence d'une erreur et l'atteinte d'un état de sécurité (temps de
réponse). Tous les temps de réponse pour les sous-systèmes et les sous-fonctions doivent être spécifiés
dans le concept de sécurité technique.
Si aucun état de sécurité ne peut être atteint par un arrêt direct, un temps doit être défini pendant lequel une
fonction spéciale de fonctionnement d'urgence doit être maintenue pour tous les sous-systèmes et sous-
fonctions. Cette fonction de fonctionnement d'urgence doit être documentée dans le concept de sécurité
technique.
5.4.3.2.3 Architecture, interfaces et conditions marginales de sécurité
L'architecture de sécurité et ses sous-modules doivent être décrits. En particulier, les mesures techniques
doivent être spécifiées. Le concept de sécurité technique doit décrire séparément les modules suivants (le cas
échéant):
⎯ le système de détection, séparé pour chaque paramètre physique enregistré;
⎯ diverses unités d'entrée et de sortie numériques et analogiques;
⎯ le traitement, séparé pour chaque unité arithmétique/unité logique discrète;
⎯ le système d'actionnement, séparé pour chaque actionneur;
⎯ les afficheurs, séparés pour chaque unité d'indication;
⎯ divers composants électromécaniques;
⎯ la transmission de signal entre les modules;
⎯ la transmission de signal à partir/en direction des systèmes extern
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.