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
Frequently Asked Questions
ISO 25119-3:2010 is a standard published by the International Organization for Standardization (ISO). Its full title is "Tractors and machinery for agriculture and forestry - Safety-related parts of control systems - Part 3: Series development, hardware and software". This standard covers: 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).
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).
ISO 25119-3:2010 is classified under the following ICS (International Classification for Standards) categories: 35.240.99 - IT applications in other fields; 65.060.01 - Agricultural machines and equipment in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 25119-3:2010 has the following relationships with other standards: It is inter standard links to ISO 25119-3:2018. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 25119-3:2010 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
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 2010
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.
© 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
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
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
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.
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.
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
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
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
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.
⎯ 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
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.
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
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.
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 integration test plan/hardware subsystem test plan;
e) hardware system integration test specification;
f) hardware system integration test results/hardware subsystem test results.
10 © ISO 2010 – All rights reserved
7 Software
7.1 Software development planning
7.1.1 Objectives
The objective is to determine and plan the individual phases of software development. This includes the
process of software development itself, which is described in this clause, as well as the necessary supporting
processes described in ISO 25119-4:2010, Clause 10.
7.1.2 General
Figure 4 illustrates the process for developing software. In the following paragraphs and tables, each box in
the diagram is explained in detail.
Appropriate techniques/measures should be selected according to the required SRL. Given the large number
of factors that affect software safety integrity, it is not possible to give an algorithm for combining the
techniques and measures that are correct for any given application. For a particular application, the
appropriate combination of techniques or measures should be stated during safety planning, with appropriate
techniques or measures being selected according to the requirements in 7.1.4.
7.1.3 Prerequisites
The prerequisites in this phase are
⎯ the required SRL as determined by the AgPL for each safety function to be realized,
r
⎯ the project plan (including system development plan),
⎯ the system verification plan,
⎯ the technical safety concept,
⎯ the system design specification, and
⎯ the safety plan.
7.1.4 Requirements
7.1.4.1 Phase determination
For the software development process, it shall be determined which phases of software development (see
Figure 4) are to be carried out. The extent and complexity of the project shall be taken into account. The
phases can be carried out according to Figure 4, without modification, or individual phases can be combined,
if all work products of the combined phases are generated.
NOTE It is common to combine individual phases if the method 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.
Other phases can be added by distributing the activities and tasks.
EXAMPLE The application of data can be inserted as a separate phase before the safety validation of the electronic
control unit. The safety validation of the ECU can be conducted differently depending on the distribution of the functions —
as a test of particular ECU or as a test of the combined control network. It could be conducted at the test location of the
component systems or at the laboratory vehicle.
7.1.4.2 Process flexibility
Activities and tasks may be moved from one phase to another.
7.1.4.3 Process timetable
A timetable shall be set up showing the relationship between the individual phases of the software
development and the product development process including the integration steps at machine level.
7.1.4.4 Applicability
After the software safety requirement specification has been completed according to Table 1, it should be
determined which software safety requirements shall be applied to which integration steps.
7.1.4.5 Supporting processes
Supporting processes shall be planned and implemented as part of the software development process:
a) the work products shall be documented according to ISO 25119-4:2010, Clause 12;
b) changes to the software shall be dealt with according ISO 25119-4:2010, Clause 10;
c) the work products shall be subject to the configuration management process.
NOTE Supporting process b), above, includes a strategy for dealing with the different branches of the software that
result from changes, including the merging of these branches.
7.1.4.6 Phases of software development
For each phase of software development, the selection of the appropriate development methods and
measures, the corresponding tools, and the guidelines for the implementation of the methods, measures and
tools shall be carried out according to the SRL.
These selections shall be justified with regard to the appropriateness to the application area, and shall be
made at the beginning of each development phase.
When selecting methods and measures, it needs to be kept in mind that, in addition to manual coding,
model-based development can be applied in which the source code or the object code is automatically
generated from models.
NOTE The selection of coordinated methods and measures offers the possibility of reducing the complexity of
software development.
12 © ISO 2010 – All rights reserved
Key
result
verification
validation
a
The first of the two numbers separated by a slash refers to this part of ISO 25119 and the second to Clause 7.
Figure 4 — Software development V-model
7.1.4.7 Using the tables
For every development method and measure, Tables 1 to 6 present an entry for each of the four SRL, using
either the symbol “+” or “o”:
+ the method or measure shall be used for this SRL, unless there is reason not to, in which case that
reason shall be documented during the planning phase;
o there is no recommendation for or against the use of this method or measure for this SRL.
In a table, an “o” may appear to the right of a “+”. This means a more rigorous measure or technique is
available for the same SRL.
Methods and measures corresponding to the respective SRL shall be selected. Alternative or equivalent
methods and measures are identified by letters after the number. At least one of the alternative or equivalent
methods and measures marked with a “+” shall be selected.
If a special method or measure is not listed in the tables, this does not mean that such a method or measure
may not be used. If an unlisted method or measure is substituted for one listed in the table, it shall be one that
has an equivalent or higher value.
7.1.5 Work products
The work product applicable to this phase is the software project plan resulting from 7.1.4.2 to 7.1.4.4 (see
also ISO 25119-4:2010, Clause 6).
7.2 Software safety requirements specification
7.2.1 Objectives
The first objective is to derive the software safety requirements, including the SRL, from the technical safety
requirements.
The second objective is to verify that the software safety requirements are consistent with the technical safety
concept.
7.2.2 General
The software safety requirements specification should be derived from the requirements of the technical
safety concept of the system, and labelled as software safety requirements. At least the following should be
taken into account:
a) adequate implementation of the technical safety concept in the software;
b) system configuration and architecture;
c) design of the E/E/PES system hardware;
d) response times of the safety functions;
e) external interfaces, such as communication;
f) physical requirements and environmental conditions as far as they affect the software;
g) requirements for safe software modification.
NOTE Iterations are required between the hardware and software development of the system. During the process of
further specifying and detailing the software safety requirements and the software architecture, there may be
repercussions on the hardware architecture. For this reason, close cooperation between the hardware development and
the software development is necessary.
7.2.3 Prerequisites
The following are the prerequisites for the software safety requirements specification:
⎯ software project plan according to 7.1.4.2 to 7.1.4.4;
⎯ technical safety concept according to 5.4.3;
⎯ hardware categories according to 6.5.
7.2.4 Requirements
7.2.4.1 Software safety requirements specification methods
The software safety requirements specification shall be in accordance with Table 1.
14 © ISO 2010 – All rights reserved
Table 1 — Software safety requirements specification
a
Technique/measure Subclause SRL=B SRL=1 SRL=2 SRL=3
1 Requirements specification in natural
7.2.4.1.1 + + + +
language
a
7.2.4.1.2 o o
2a Informal design methods + +
2b Semi-formal design methods 7.2.4.1.3 o o + +
2c Formal design methods 7.2.4.1.4 o o + +
3 Computer-aided specification tools 7.2.4.1.5 o o + +
4a Inspection of software safety
ISO 25119-1:2010, 3.28 + + + +
a
requirements
4b Walk-through of software safety
ISO 25119-1:2010, 3.56 + + o o
requirements
See 7.1.4.7 for instructions on the use of this and the other tables.
a
Appropriate techniques/measures shall be selected according to the SRL. Alternative or equivalent techniques/measures are
indicated by a letter following the number. Only one of the alternative or equivalent techniques/measures need be satisfied.
NOTE 1 Ways of modelling which possess a complete syntax definition and a complete semantic definition with calculus are
summarized in item 2c. Formal methods admit to formal verification and automatic test case generation. Examples include state
machines connected to formal verification.
NOTE 2 Ways of modelling which possess a complete syntax definition and a semantic definition without calculus are summarized
in item 2b. Examples include structured analysis/design and graphic ways of modelling, such as UML class diagrams or block diagrams.
NOTE 3 In case of model-based development with code generation, the methods and measures for software architectural design
have to be applied to the functional model, which will serve as the basis for code generation.
7.2.4.1.1 Requirements specification in natural language
7.2.4.1.1.1 Aim
The specification requirements shall be introduced in natural language (i.e. ordinary spoken and written).
7.2.4.1.1.2 Description
The software safety requirements specification shall include a description of the problem in natural language,
and if necessary, further informal methods, such as figures and diagrams.
7.2.4.1.2 Informal design methods
7.2.4.1.2.1 Aim
To express a complete concept, a natural language shall be used.
7.2.4.1.2.2 Description
Informal methods shall provide a means of developing a description of a system at some stage in its
development, i.e. specification, design or coding, typically by means of natural language, diagrams, figures,
etc.
7.2.4.1.3 Semi-formal design methods
7.2.4.1.3.1 Aim
Semi-formal design methods shall express a concept, specification or design unambiguously and consistently,
so that some mistakes and omissions can be detected.
7.2.4.1.3.2 Description
Semi-formal methods for software design shall be used to provide a means of developing a description of a
system at some stage in its development, i.e. specification, design or coding.
EXAMPLE Data flow diagrams, finite state machines/state transition diagrams.
The description shall in some cases be analysed by machine or animated to display various aspects of the
system behaviour. Animation shall give extra confidence that the system meets the requirements.
7.2.4.1.4 Formal design methods
7.2.4.1.4.1 Aim
The development of software in a way that is based on mathematics shall include formal design and formal
coding techniques.
7.2.4.1.4.2 Description
Formal methods shall provide a means of developing a description of a system at some stage in its
specification, design or implementation. The resulting description is in a strict notation that shall be subjected
to mathematical analysis to detect various classes of inconsistency or incorrectness. Moreover, the
description shall in some cases be analysed by machine with a rigour similar to the syntax checking of a
source program by a compiler, or animated to display various aspects of the behaviour of the system
described. Animation shall give extra confidence that the system meets the real requirement as well as the
formally specified requirement, because it improves human recognition of the specified behaviour.
A formal method shall generally offer a notation (normally some form of discrete mathematics being used), a
technique for deriving a description in that notation, and various forms of analysis for checking a description
for different correctness properties.
7.2.4.1.5 Computer-aided specification tools
7.2.4.1.5.1 Aim
To facilitate automatic detection of ambiguity and completeness, formal specification techniques shall be used.
7.2.4.1.5.2 Description
The technique shall produce specifications in the form of a database that can be automatically inspected to
assess consistency and completeness. The specification tool shall animate various aspects of the specified
system for the user. In general, the technique supports not only the creation of the specification but also of the
design and other phases of the project life cycle.
7.2.4.2 Non-safety–related functions
If functions additional to the safety functions are carried out by the E/E/PES, these shall be specified, or
reference shall be made to their specifications.
16 © ISO 2010 – All rights reserved
If the requirements specification includes both the functional requirements and the safety requirements, the
latter should be clearly identified as such.
7.2.4.3 Level of detail
The software safety requirements specification shall contain enough detail to implement the safety function in
the software.
7.2.4.4 Consistency
The software safety requirements shall be retraceable and consistent with the specifications of the system
safety requirements and the system architecture.
7.2.4.5 Hardware and software co-dependency
The software safety requirements specification shall specify the safety-related dependencies between the
hardware and the software, if relevant.
7.2.4.6 Software safety requirements specification
The software safety requirements specification shall describe software safety 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 in the ECU, sensors, actuators and
communication system.
⎯ Functions related to the detection, indication and handling of faults in the software itself (self-supervision
of the software
...
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 2010
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
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
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
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.
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.
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
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
Figure 1 — Structuration des exigences de sécurité
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
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é.
⎯ 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
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 externes à l'unité d'observation;
⎯ l'alimentation.
Les interfaces situées entre les modules de l'unité d'observation, les interfaces d'autres systèmes et les
fonctions dans la machine ainsi que les interfaces utilisateur doivent être spécifiées.
Les restrictions et conditions marginales de l'unité d'observation doivent être spécifiées. Cela s'applique en
particulier aux valeurs externes pour toutes les conditions ambiantes dans toutes les phases du cycle de vie.
6 Matériel
6.1 Objectifs
L'objectif est de définir les architectures de matériel acceptables pour les systèmes de commande relatifs à la
sécurité.
6.2 Généralités
L'amélioration de la structure du matériel des parties relatives à la sécurité du système de commande peut
fournir des mesures permettant d'éviter, de détecter ou de tolérer les défauts. Les mesures pratiques peuvent
inclure la redondance, la diversité et la surveillance.
En général, les critères de défaut suivants doivent être pris en compte.
⎯ Si, en conséquence d'un défaut, des composants supplémentaires sont défectueux, le premier défaut et
tous les défauts suivants sont considérés comme étant un seul défaut.
⎯ Deux défauts isolés ou plus ayant une cause commune sont considérés comme étant un seul défaut
(désigné défaillance de cause commune).
⎯ L'occurrence simultanée de deux défauts indépendants est considérée comme étant très improbable.
6.3 Conditions préalables
Les conditions préalables sont le niveau AgPL , déterminé pour chaque fonction de sécurité à réaliser par le
r
matériel.
6.4 Exigences
Le processus de développement du matériel doit commencer au niveau du système où les fonctions de
sécurité et les exigences associées sont identifiées (voir Figure 2).
L'analyse de sécurité du matériel doit être utilisée pour identifier l'AgPL pour chaque fonction de sécurité du
r
système (voir l'ISO 25119-2).
Le concepteur doit grouper les fonctions dans des architectures appropriées (catégorie de matériel) avec les
MTTF , DC et CCF associés.
dc
Le système peut être subdivisé en sous-systèmes pour faciliter le développement.
Chaque phase du cycle de développement doit être vérifiée.
8 © ISO 2010 – Tous droits réservés
Légende
résultat
vérification
validation
a
Le premier chiffre correspond à la présente partie de l'ISO 25119, le deuxième, séparé par une barre oblique, à
l'Article 6.
Figure 2 — Développement de matériel — Modèle en V
La procédure de conception de l'architecture du système de matériel est la suivante.
a) Choisir une catégorie de matériel (ISO 25119-2:2010, Annexe A).
b) Identifier l'environnement de fonctionnement du composant et le niveau de contrainte.
c) Choisir les composants.
d) Calculer et vérifier que le MTTF atteint le niveau requis (ISO 25119-2:2010, Annexe B).
dC
e) Déterminer et vérifier que la DC atteint le niveau requis (ISO 25119-2:2010, Annexe C).
f) Considérer la CCF (ISO 25119-2:2010, Annexe D).
g) Considérer les défaillances systématiques (ISO 25119-2:2010, Annexe E).
h) Considérer d'autres fonctions de sécurité (ISO 25119-2:2010, Annexe F).
NOTE L'itération peut être nécessaire pour les étapes ci-dessus.
6.5 Catégories de matériel
Les parties relatives à la sécurité des systèmes de commande doivent être conçues conformément aux
exigences de l'une ou de plusieurs des cinq catégories spécifiées dans l'ISO 25119-2:2010, Annexe A.
Lorsqu'une fonction de sécurité est réalisée par une combinaison intégrée de plusieurs catégories de matériel,
le niveau AgPL de la fonction de sécurité qui en résulte est limité par la catégorie de matériel globale,
comprenant les MTTF , DC, SRL, CCF, etc. (voir Figure 3).
dc
Pour déterminer le SRL global, voir 7.3.4.7.
Légende
I dispositif d'entrée (par exemple détecteur) S entrée du signal d'interconnexion
l
L logique S sortie du signal d'interconnexion
O
O dispositif de sortie (par exemple actionneur) M surveillance
TE équipement d'essai Cat catégorie de matériel
OTE sortie de l'équipement d'essai
Figure 3 — Système intégré avec AgPL maximal pour la catégorie 2
6.6 Produits fabriqués
Les produits fabriqués suivants sont applicables au processus de conception du matériel:
a) plan d'essai de validation de sécurité du matériel;
b) spécification d'essai de validation de sécurité du matériel;
c) résultats d'essai de validation de sécurité du matériel;
d) plan d'essai d'intégration du système de matériel; plan d'essai du sous-système de matériel;
e) spécification d'essai d'intégration du système de matériel;
f) résultats d'essai d'intégration du système de matériel; résultats d'essai du sous-système de matériel.
10 © ISO 2010 – Tous droits réservés
7 Logiciel
7.1 Planification de développement du logiciel
7.1.1 Objectifs
L'objectif est de déterminer et de planifier les phases individuelles de développement du logiciel. Cela
comprend le processus de développement du logiciel lui-même, qui est décrit dans le présent article, ainsi
que les processus de prise en charge nécessaires décrits dans l'ISO 25119-4:2010, Article 10.
7.1.2 Généralités
La Figure 4 illustre le processus de développement du logiciel. Dans les paragraphes et tableaux suivants,
chaque boîte dans l'organigramme est expliquée en détail.
Il convient de sélectionner des techniques/mesures appropriées conformément au SRL requis. Étant donné le
grand nombre de facteurs qui affectent l'intégrité de la sécurité du logiciel, il n'est pas possible de donner un
algorithme pour la combinaison des techniques et des mesures qui sont correctes pour une application
donnée. Pour une application particulière, la combinaison appropriée des techniques ou des mesures doit être
spécifiée pendant la planification de la sécurité, avec les techniques ou les mesures appropriées choisies
conformément aux exigences de 7.1.4.
7.1.3 Conditions préalables
Pour cette phase, les conditions préalables sont:
⎯ le SRL requis tel que déterminé par le niveau AgPL pour chaque fonction de sécurité à réaliser;
r
⎯ le plan de projet (comprenant le plan de développement du système);
⎯ le plan de vérification du système;
⎯ le concept de sécurité technique;
⎯ la spécification de conception du système;
⎯ le plan de sécurité.
7.1.4 Exigences
7.1.4.1 Détermination des phases
Pour le processus de développement du logiciel, les phases de développement du logiciel doivent être
déterminées (voir Figure 4). L'étendue et la complexité du projet doivent être prises en compte. Les phases
peuvent être effectuées conformément à la Figure 4, sans aucune modification, ou bien les phases
individuelles peuvent être combinées, si tous les produits fabriqués des phases combinées sont générés.
NOTE Il est courant de combiner les phases individuelles si la méthode 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.
D'autres phases peuvent être ajoutées en distribuant les activités et les tâches.
EXEMPLE L'application des données peut être insérée comme une phase séparée avant la validation de la sécurité
de l'unité de commande électronique. La validation de la sécurité de l'unité de commande électronique peut être effectuée
différemment en fonction de la distribution des fonctions — comme un essai des unités de commande électronique
particulières ou comme un essai du réseau de commande combiné. Elle pourrait être effectuée sur l'emplacement de
l'essai des systèmes de composants ou au niveau du véhicule du laboratoire.
7.1.4.2 Flexibilité du processus
Les activités et les tâches peuvent être déplacées d'une phase à l'autre.
7.1.4.3 Planning du processus
Un planning doit être établi, montrant la relation entre les phases individuelles de développement du logiciel et
le processus de développement du produit, y compris les étapes d'intégration au niveau de la machine.
7.1.4.4 Applicabilité
À l'issue de la spécification relative à l'exigence de sécurité du logiciel conformément au Tableau 1, il convient
de déterminer les exigences de sécurité du logiciel qui doivent être appliquées aux étapes d'intégration.
7.1.4.5 Processus de prise en charge
Les processus de prise en charge doivent être planifiés et mis en œuvre dans le cadre du processus de
développement du logiciel:
a) les produits fabriqués doivent être documentés conformément à l'ISO 25119-4:2010, Article 12;
b) les modifications apportées au logiciel doivent être traitées conformément à l'ISO 25119-4:2010,
Article 10;
c) les produits fabriqués doivent être soumis au processus de gestion de la configuration.
NOTE Le point b) ci-dessus comprend une stratégie pour traiter les différentes branches du logiciel résultant des
modifications, y compris la fusion de ces branches.
7.1.4.6 Phases de développement du logiciel
Pour chaque phase de développement du logiciel, les méthodes et les mesures de développement
appropriées, les outils correspondants et les lignes directrices pour la mise en œuvre des méthodes, des
mesures et des outils doivent être choisis conformément au SRL.
Ces choix doivent être justifiés en fonction de l'adéquation au domaine d'application, et doivent être effectués
au début de chaque phase de développement.
Lors du choix des méthodes et mesures, il est nécessaire de prendre en compte le fait que, outre le codage
manuel, un développement fondé sur le modèle peut être appliqué, dans lequel le code source ou le code
objet est automatiquement généré par les modèles.
NOTE Le choix des méthodes et mesures coordonnées offre la possibilité de réduire la complexité du
développement du logiciel.
12 © ISO 2010 – Tous droits réservés
Légende
résultat
vérification
validation
a
Le premier chiffre correspond à la présente partie de l'ISO 25119, le deuxième, séparé par une barre oblique, à
l'Article 7.
Figure 4 — Développement du logiciel — Modèle en V
7.1.4.7 Utilisation des tableaux
Pour chaque méthode et mesure de développement, les Tableaux 1 à 6 présentent une entrée pour chacun
des quatre SRL, au moyen des symboles «+» ou «o»:
+ la méthode ou la mesure doit être utilisée pour ce SRL, à moins qu'il n'existe une raison pour ne
pas le faire, auquel cas la raison doit être documentée pendant la phase de planification;
o il n'existe pas de recommandation pour ou contre l'utilisation de cette méthode ou mesure pour
ce SRL.
Dans un tableau, un «o» peut apparaître à la droite d'un «+». Cela signifie qu'une méthode ou technique plus
rigoureuse est disponible pour le même SRL.
Les méthodes et mesures correspondant au SRL 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ée d'un «+» doit être choisie.
Si une méthode ou mesure spéciale n'est pas répertoriée dans les tableaux, cela ne signifie pas qu'une telle
méthode ou mesure ne puisse pas être utilisée. Si une méthode ou une mesure non répertoriée dans le
tableau est substituée à une méthode ou mesure répertoriée, il doit s'agir d'une méthode ou mesure ayant
une valeur équivalente ou plus élevée.
7.1.5 Produits fabriqués
Le produit fabriqué applicable à cette phase est le plan de projet du logiciel, résultant de 7.1.4.2 à 7.1.4.4 (voir
également l'ISO 25119-4:2010, Article 6).
7.2 Spécification relative aux exigences de sécurité du logiciel
7.2.1 Objectifs
Le premier objectif est de déduire les exigences de sécurité du logiciel, y compris le SRL, à partir des
exigences de sécurité technique.
Le second objectif est de vérifier que les exigences de sécurité du logiciel correspondent au concept de
sécurité technique.
7.2.2 Généralités
Il convient que la spécification relative aux exigences de sécurité du logiciel soit déduite des exigences du
concept de sécurité technique du système et marquée en tant qu'exigences de sécurité du logiciel. Il convient
de prendre en compte au moins les éléments suivants:
a) mise en œuvre adéquate du concept de sécurité technique dans le logiciel;
b) configuration et architecture du système;
c) conception du matériel du système E/E/PES;
d) temps de réponse des fonctions de sécurité;
e) interfaces externes, telles que la communication;
f) exigences physiques et conditions environnementales dans la mesure où elles affectent le logiciel;
g) exigences pour une modification sécurisée du logiciel.
NOTE Des itérations sont nécessaires entre le développement du matériel et du logiciel du système. Au cours du
processus de spécification et de détail des exigences de sécurité du logiciel, et de l'architecture du logiciel, il peut y avoir
des répercussions sur l'architecture du matériel. Pour cette raison, une coopération étroite entre le développement du
matériel et le développement du logiciel est nécessaire.
7.2.3 Conditions préalables
Les conditions préalables à la spécification relative aux exigences de sécurité du logiciel sont les suivantes:
⎯ plan de projet du logiciel, conformément à 7.1.4.2 à 7.1.4.4;
⎯ concept de sécurité technique, conformément à 5.4.3;
⎯ catégories de matériel, conformément à 6.5.
7.2.4 Exigences
7.2.4.1 Méthodes de spécification relative aux exigences de sécurité du logiciel
La spécification relative aux exigences de sécurité du logiciel doit être conforme au Tableau 1.
14 © ISO 2010 – Tous droits réservés
Tableau 1 — Spécification relative aux exigences de sécurité du logiciel
a
Technique/mesure Paragraphe SRL=B SRL=1 SRL=2 SRL=3
1 Spécification des exigences en langage
7.2.4.1.1 + + + +
naturel
a
7.2.4.1.2 o o
2a Méthodes de conception informelles + +
2b Méthodes de conception semi-formelles 7.2.4.1.3 o o + +
2c Méthodes de conception formelles 7.2.4.1.4 o o + +
3 Outils de spécification assistée par ordinateur 7.2.4.1.5 o o + +
4a Inspection des exigences de sécurité du
ISO 25119-1:2010, 3.28 + + + +
a
logiciel
4b Revue informelle des exigences de sécurité
ISO 25119-1:2010, 3.5
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...