EN 50271:2018

SLOVENSKI STANDARD
01-oktober-2018
1DGRPHãþD
SIST EN 50271:2010
(OHNWULþQHQDSUDYH]DRGNULYDQMHLQPHUMHQMHYQHWOMLYLKSOLQRYVWUXSHQLKSOLQRYDOL
NLVLND=DKWHYHLQSUHVNXVL]DQDSUDYHVSURJUDPVNRRSUHPRLQDOLGLJLWDOQR
WHKQRORJLMR
Electrical apparatus for the detection and measurement of combustible gases, toxic
gases or oxygen - Requirements and tests for apparatus using software and/or digital
technologies
Elektrische Geräte für die Detektion und Messung von brennbaren Gasen, giftigen
Gasen oder Sauerstoff - Anforderungen und Prüfungen für Warngeräte, die Software
und/oder Digitaltechnik nutzen
Appareils électriques de détection et de mesure des gaz combustibles, des gaz toxiques
ou de l'oxygène - Exigences et essais pour les appareils utilisant un logiciel et/ou des
technologies numériques
Ta slovenski standard je istoveten z: EN 50271:2018
ICS:
13.230 Varstvo pred eksplozijo Explosion protection
29.260.20 (OHNWULþQLDSDUDWL]D Electrical apparatus for
HNVSOR]LYQDR]UDþMD explosive atmospheres
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 50271
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2018
ICS 13.320 Supersedes EN 50271:2010
English Version
Electrical apparatus for the detection and measurement of
combustible gases, toxic gases or oxygen - Requirements and
tests for apparatus using software and/or digital technologies
Appareils électriques de détection et de mesure des gaz Elektrische Geräte für die Detektion und Messung von
combustibles, des gaz toxiques ou de l'oxygène - brennbaren Gasen, giftigen Gasen oder Sauerstoff -
Exigences et essais pour les appareils utilisant un logiciel Anforderungen und Prüfungen für Warngeräte, die Software
et/ou des technologies numériques und/oder Digitaltechnik nutzen
This European Standard was approved by CENELEC on 2017-11-06. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50271:2018 E
Contents
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 6
4 Design principles . 8
4.1 Basic requirements . 8
4.1.1 General . 8
4.1.2 Analogue/digital interface . 8
4.1.3 Numerical errors . 8
4.1.4 Measuring operation . 8
4.1.5 Special state indication . 8
4.2 Displays . 9
4.2.1 General . 9
4.2.2 Indication of messages . 9
4.2.3 Indication of measured values . 10
4.3 Software.10
4.3.1 General . 10
4.3.2 Re-used or commercial operating systems . 11
4.3.3 Software requirements . 11
4.3.4 Requirements for software documentation . 12
4.3.5 Requirements for the software development process . 12
4.4 Hardware .20
4.5 Digital data transmission between components of apparatus .20
4.6 Test routines .20
4.7 Instruction manual .22
4.8 Additional requirements for compliance with SIL 1 .23
5 Test of the digital unit .24
5.1 General .24
5.2 Verification of functional concept .25
5.3 Performance test .25
Annex A (normative) Hardware-software integration test .27
A.1 Functional testing/Black-box testing .27
A.2 Equivalence class test with boundary value analysis .27
Annex ZY (normative) Significant changes between this European Standard and
EN 50271:2010 .29
Annex ZZ (informative) Relationship between this European standard and the essential
requirements of Directive 2014/34/EU aimed to be covered .31
Bibliography .32

European foreword
This document (EN 50271:2018) has been prepared by CLC/SC 31-9, “Electrical apparatus for the
detection and measurement of combustible gases to be used in industrial and commercial potentially
explosive atmospheres”, of CLC/TC 31, “Electrical apparatus for potentially explosive atmospheres”,
and by CLC/TC 216 “Gas detectors”.
The following dates are fixed:
• latest date by which this document has to be (dop) 2018-12-15
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2021-06-15
conflicting with this document have to
be withdrawn
This document supersedes EN 50271:2010.
The State of the Art is included in Annex ZY “Significant changes between this European Standard
and EN 50271:2010” which lists all changes to EN 50271:2010.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association and covers essential requirements of EU Directive
2014/34/EU.
For the relationship with EU Directive see informative Annex ZZ, which is an integral part of this
document.
Introduction
This European Standard specifies minimum requirements for functional safety of gas detection
apparatus using software and/or digital technologies and defines criteria for reliability and avoidance of
faults. Functional safety is that part of the overall safety which is related to the measures within the
gas detection apparatus to avoid or to handle failures in such a manner that the safety function will be
ensured.
Gas detection apparatus will fail to function if dangerous failures occur. The aim of this European
Standard is to reduce the risk of dangerous equipment failures to levels appropriate to typical
applications of such apparatus.
Failure to function will also occur if such apparatus are not selected, installed or maintained in an
appropriate manner. In some applications failures of this type will dominate the functional safety
achieved. Users of gas detection apparatus will therefore need to ensure that selection, installation
and maintenance of such apparatus are carried out appropriately. Guidance for the selection,
installation, use and maintenance of gas detection apparatus are set out in EN 60079-29-2 and
EN 45544-4, respectively.
This European Standard does not include requirements for operational availability which will need to
be considered separately.
Regarding the requirements for the software development process, this European Standard specifies
a practical approach to comply with the requirements of EN 61508-3 for SIL 1 without using this
generic standard.
This European standard also specifies additional optional requirements for compliance with SIL 1 in
low demand mode operation. The following apparatus or gas detection systems are not fully covered
by this standard:
– apparatus at SIL 1 when the apparatus or gas detection system contains functionality not covered
by EN 50271
– apparatus at SIL 1 high demand mode operation
– apparatus at SIL 2 and SIL 3;
For such apparatus or gas detection systems the European standard EN 50402 should be used
instead of EN 50271. EN 50402 includes all requirements of EN 50271.
1 Scope
This European Standard specifies minimum requirements and tests for electrical apparatus for the
detection and measurement of combustible gases, toxic gases or oxygen using software and/or digital
technologies.
This European Standard is applicable to fixed, transportable and portable apparatus intended for use
in domestic premises as well as commercial and industrial applications and their software-controlled
safety related accessories.
This European Standard does not apply to external sampling systems which are not accessories, or to
apparatus of laboratory or scientific type, or to apparatus used only for process control purposes.
This European Standard supplements the requirements of the European Standards for the detection
and measurement of flammable gases and vapours (e.g. EN 60079-29-1, EN 60079-29-4, EN 50194-
1, EN 50194-2), toxic gases (e.g. EN 45544 series, EN 50291-1, EN 50291-2) or oxygen (e.g.
EN 50104).
NOTE 1 These European Standards will be mentioned in this European Standard as “metrological standards”.
NOTE 2 The examples above show the state of the standardization for gas detection apparatus at the time of
publishing this European Standard. There may be other metrological standards for which this European Standard
is also applicable.
This European Standard is a product standard which is based on the EN 61508 series. It covers part
of the phase 10 “realisation” of the overall safety life cycle defined in EN 61508-1.
Additional requirements are specified if compliance with safety integrity level 1 (SIL 1) according to the
EN 61508 series is claimed for fixed or transportable apparatus for low demand mode of operation.
They can also be applied to portable apparatus which are able to perform an automatic executive
action.
It is recommended to apply this European Standard for apparatus used for safety applications with
SIL-requirement 1 instead of EN 50402. However, the technical requirements of EN 50271 and
EN 50402 are the same for SIL 1.
NOTE 3 For apparatus used for safety applications with SIL-requirements higher than 1 EN 50402 is applicable.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
EN 50402:2017, Electrical apparatus for the detection and measurement of combustible or toxic gases
or vapours or of oxygen - Requirements on the functional safety of gas detection systems
EN 60079-29-1:2016, Explosive atmospheres - Part 29-1: Gas detectors - Performance requirements
of detectors for flammable gases
EN 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 1: General requirements
EN 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related
systems
EN 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 3: Software requirements
EN 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 4: Definitions and abbreviations
EN 61508-5:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 5: Examples of methods for the determination of safety integrity levels
EN 61508-6:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
EN 61508-7:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems - Part 7: Overview of techniques and measures
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 60079-29-1:2016 and the
following apply.
3.1
digital unit
part of an electrical apparatus in which data is processed digitally. Analogue-digital(A/D)-converters
and digital-analogue(D/A)-converters as interfaces to analogue units of the apparatus belong to the
digital unit
3.2
special state
all states of the apparatus other than those in which monitoring of gas concentration and/or alarming is
intended, for example the special states of warm-up, calibration mode or fault condition
[SOURCE: EN 60079-29-1:2016, 3.5.4]
3.3
software
intellectual creation comprising the programs, procedures, rules and associated documentation
pertaining to the operation of the digital unit
3.4
failure
termination of the ability of a functional unit to provide a required function or operation of a functional
unit in any way other than as required
[SOURCE: EN 61508-4:2010, 3.6.4, mod.]
3.5
parameters
settings by the manufacturer or user which affect the operation of the apparatus, e.g. changing of the
alarm set points or measuring ranges. Parameter options are included in the hardware and/or software
during design of the apparatus. Changes of parameter settings are not modifications of the software.
In the software several different levels of permission to read or to change parameters may exist
3.6
specified range of input values
range of analogue input values corresponding to the digital output range of an A/D-converter or range
of digital input values corresponding to the analogue output range of a D/A-converter. The minimum
and maximum digital values of the converter are not to be considered to be within the specified range
because minima and maxima correspond to stuck-at faults which have to be detected by the
apparatus (see 4.1.4)
3.7
defined range of input values
range of input values defined by the manufacturer of the apparatus to be valid; the defined range is a
sub-range of the specified range of input values
3.8
output data
result of the digital data processing, which is used for driving the output interfaces
Note 1 to entry: Output interfaces may be analogue or digital displays, analogue or digital outputs and/or alarm
indicators or relays.
3.9
output signal
analogue or digital signal which is available at an output interface
3.10
measured value
processed measured signal including physical unit (e.g. % LEL). A measured value may be formed
from a single signal or a combination of several measured signals. The combined measured signals
may represent different physical units, e.g. gas concentration and temperature
3.11
smallest deviation of indication
value which is determined by the applicable metrological standards. In metrological standards the
allowed tolerances for deviation of indication during type testing are given. If there are different
requirements for the tolerances in different applicable metrological standards the smallest tolerance is
the “smallest deviation of indication”
Note 1 to entry: The smallest deviation of indication is basis for the required resolution of measured signals
which use digital transmission and data processing to meet the requirements of the metrological standards when
using digital technologies
[SOURCE: EN 50402:2017, 3.22]
3.12
message
indication on a display which gives an information about the status of the apparatus (e.g. alarm,
special state, warning)
3.13
software component
part of the program that consists of one or several software modules and that can also interact with
other such constructs
3.14
software module
construct that consists of subroutines and/or data declarations and that can also interact with other
such constructs
3.15
safety function of a gas detection apparatus
any function (inclusive from gas sampling to output of the gas detection apparatus) implemented by
the gas detection apparatus which is related to safety as defined by the manufacturer
4 Design principles
4.1 Basic requirements
4.1.1 General
The metrological standards define performance requirements for gas detection apparatus which have
direct implications on the digital units and software which may be used in such apparatus. This
subclause specifies basic requirements to digital units and software to fulfil the metrological standards.
4.1.2 Analogue/digital interface
The relationship between corresponding analogue and digital values shall be unambiguous. The
output range shall be capable of coping with the defined range of input values. Input values outside
the specified range of the converter shall not result in a valid measured value. A/D- and D/A-converter
quantisation steps shall be chosen so that the requirements in 4.1.3 for the accuracy of data
representation will be fulfilled. The design shall take into account the maximum possible A/D- and D/A-
converter errors.
NOTE This assessment need not include environmental interferences to the A/D- or D/A-converters, e.g.
temperature variation, since environmental testing is covered by the metrological standards.
Outputs at the limits of the specified range of D/A-converters shall result in output signals which are
described as fault signal by the manufacturer.
4.1.3 Numerical errors
Deviations of measured values arising from quantisation, rounding and calculation errors shall be
estimated assuming worst case conditions.
These worst case conditions shall be evaluated in detail. For example, nonlinear behaviour of the
sensor signal with gas concentration, ageing of sensors, varying sensitivities for different gases and
signal variation with temperature, pressure or humidity shall be taken into consideration.
The estimated deviation of measured values shall not be greater than 50 % of the smallest deviation
of indication.
NOTE The deviation of measured values arising from the digital unit will be typically much lower than 50 % of
the smallest deviation of indication. Deviations arising from other sources (e.g. sensor) are expected to be
dominant.
4.1.4 Measuring operation
During data processing the digital unit shall automatically control the specified input data range and
handle range violations. The minimum and maximum digital values of the converter shall not be
considered to be within the specified range in order to detect stuck-at faults.
The software design and verification shall guarantee that range violations for internal and output data
do not occur. Otherwise the digital unit shall automatically control the allowed data ranges and handle
range violations.
During measuring operation, the maximum overall time of four successive updates of the measured
value and all safety relevant output signals shall not exceed the response time t90 of the apparatus or,
for alarm only apparatus, the minimum time to alarm.
NOTE This timing requirement may not be applied to output signals which are explicitly claimed by the
manufacturer to be not safety-relevant.
4.1.5 Special state indication
4.1.5.1 General
It shall not be possible for any interface to an external device to adversely affect a safety function of
the apparatus without the apparatus entering a special state.
NOTE This includes both hardware and software interfaces.
4.1.5.2 Fixed and transportable apparatus
a) Control units
While a special state is present within the entire gas detection apparatus (i.e. control unit and
external sensors or transmitters) this shall be continuously indicated by a signal. This signal shall
be transmittable except when the apparatus is intended to be used in domestic premises only.
Signals provided for indicating that the entire gas detection apparatus is in the special state “fault”
shall be such that they de-energize when the special state occurs and also on power loss. In the
case of deactivation of alarm devices, e.g. for calibration purposes, it is not required to indicate a
special state by a transmittable signal if the alarm devices are automatically re-enabled within
15 min.
b) Gas detection transmitters intended to be used with control units
The special state “calibration” shall be transmitted to the control unit continuously or the
measured value shall be transmitted during calibration. All other special states shall be
transmitted to the control unit continuously. The test routine according to 4.6 c) is excluded.
c) All other apparatus
A special state shall be continuously indicated by a signal. This signal shall be transmittable
except when the apparatus is intended to be used in domestic premises only. Signals provided for
indicating that the apparatus is in the special state “fault” shall be such that they de-energize
when the special state occurs and also on power loss. In the case of deactivation of alarm
devices, e.g. for calibration purposes, it is not required to indicate a special state by a
transmittable signal if the alarm devices are automatically re-enabled within 15 min.
In the case of digital data transmission, the term “continuously” is used with the meaning: continually,
at the rate at which the output signal is updated (see 4.1.4).
4.1.5.3 Portable apparatus
The special state “fault” shall be continuously indicated by an optical and audible signal. It is permitted
that the audible signal can be silenced.
If it is not possible to show an indication in all possible fault situations the normal operation of the
apparatus shall be confirmed by a periodic optical and audible output signal (commonly called alive
signal or confidence signal). The time interval between two signals shall not exceed 60 s.
EXAMPLE: A sudden breakdown of battery voltage cannot be indicated without implementing a second
independent power supply.
The special state “warm-up” shall be indicated by an optical and/or audible signal.
The special states “calibration mode” and “parameterization mode” shall be indicated by an optical
signal.
4.2 Displays
4.2.1 General
If a display is provided the requirements of 4.2.2 and 4.2.3 apply.
4.2.2 Indication of messages
If it is intended to indicate messages on a display:
a) it shall be possible to display all active messages simultaneously or a consolidated signal shall be
generated (e.g. indicating lights for alarms or fault) and a consolidated message shall be
displayed. It shall be possible to interrogate all active messages;
b) a unique message shall be provided for each individual gas alarm;
c) if no special state is activated, it shall be possible to interrogate the measured values of all gas
sensors.
If a message includes another subsidiary message (e.g. exceeding the 2nd alarm threshold includes
exceeding the 1st alarm threshold) it is sufficient to show the message of higher priority. After
cancelling the higher order message the subsidiary message shall remain if the reason for its
activation still exists.
It is recommended that the manufacturer defines an appropriate set of messages in order to enable
the user an easy identification of alarms, special states, etc.
4.2.3 Indication of measured values
For measured values the displayed unit of measurement and any related sign shall be unambiguous.
Any under-range or over-range measurements shall be clearly indicated according to the requirements
of the metrological standards.
4.3 Software
4.3.1 General
This clause specifies minimum requirements for the software development process which are based
on EN 61508-3. Alternative procedures are permitted provided that the applicable requirements of
EN 61508-3 are fulfilled. Compliance through “proven in use” (Route 2s of EN 61508-3) shall not be
used.
NOTE This standard specifies minimum requirements and does not give additional recommendations (in the
tables of EN 61508-3 and in EN 50402:2017 marked as “R”).
In general, software will consist of device software and, if applicable, an operating system and libraries
(e.g. mathematical functions).
The requirements of this clause shall be applied to the entire software. A distinction between safety-
related and non safety-related software is not made.
New operating systems shall be developed according to 4.3.3 to 4.3.5. Re-used or commercial
operating systems shall comply with 4.3.2.
New device software and libraries shall be developed according to 4.3.3 to 4.3.5.
Bought or re-used software modules which were previously developed according to 4.3.3 to 4.3.5 or
commercial libraries which are only available as object code shall be qualified (see 4.3.5.3.2).
Bought or re-used software modules which are relevant for the basic gas detection functionality (signal
chain from sensor to safety relevant output(s)) or the effectiveness of the test routines (according to
4.6) which were not developed according to 4.3.3 to 4.3.5 shall be treated as new code (Route 3s
according to EN 61508-3, 7.4.2.13). All other bought or re-used software modules shall be qualified
(see 4.3.5.3.2).
Only the requirements of 4.3.3, 4.3.4 a)-e), g), h) and 4.7 shall be applied to software for
parameterization of the gas detection device, which is running on external devices (e.g. PC) on
request and under control of an authorized user for a short period of time.
4.3.2 Re-used or commercial operating systems
4.3.2.1 Requirements
Re-used or commercial operating systems may be integrated without applying 4.3.3 to 4.3.5 if the
following requirements are fulfilled:
a) quasi-real time capability for compliance with the requirements of 4.1.4;
b) it shall not be possible for the user to modify the configuration of the operating system;
c) no automatic update-function for the operating system;
d) upgrades of the operating system shall only be possible under the control of the manufacturer of
the apparatus;
e) if the program is executed from volatile memory the entire software shall be fully loaded at start-
up of the apparatus. In special states which are entered by a deliberate action of the user (e.g.
modification of parameters) loading of further modules is permitted;
f) functional safety is validated to be at least SIL 1 according to EN 61508-3 or the operating system
is used with the restrictions according to 4.3.2.2.
It is pointed out that, according to 4.3.5.9, in case of modification of the operating system the impact
on the device software shall be assessed and, if necessary, modification and validation procedures
shall be performed.
4.3.2.2 Use of operating systems without validation of functional safety
An operating system without validation of functional safety is permitted to be used if the following
requirements are fulfilled.
a) The device software has a logical and temporal monitoring of program sequence.
b) The monitoring equipment according to 4.6 d) is triggered by the device software only (that is, the
device software operates the hardware IO ports and watchdog directly, without using the
operating system).
c) Output ports which are part of the safety function are exclusively driven by the device software.
However, functions of the operating system may be used if the correct settings of the output ports
are verified by the device software.
d) Input ports which are part of the safety function are read by the device software. However,
functions of the operating system may be used if the correctness of the read data are verified by
the device software.
e) The test routines according to 4.6 shall be performed by the device software or hardware.
NOTE 1 If the state of switching outputs is monitored by the device software, functions of the operating system
may be used both for driving and reading back the switching output.
NOTE 2 For digital data transmission between spatially separated components of apparatus the requirements of
4.5 apply. The device software verifies the transmitted information thus enabling the detection of side effects (e.g.
corruption) caused by the operating system of the transmitter or receiver.
4.3.3 Software requirements
a) It shall be possible for the user to identify the installed software version, for example by marking
on the installed memory component, in (if accessible) or on the apparatus or by showing it on the
display during power up or on user command.
b) It shall not be possible for the user to modify the software function. It shall be impossible to
change the program code under any operating conditions. Upgrades shall only be possible under
the control of the manufacturer.
c) Parameter settings shall be checked for validity. Invalid inputs shall be rejected. An access barrier
shall be provided against parameter changing by unauthorized persons, e.g. it may be integrated
by an authorization code in the software or may be realized by a mechanical lock. Parameter
settings shall be preserved after apparatus switch-off, after disconnection of the power supply and
while passing through a special state.
Parameters controlling the calibration of the apparatus shall not be updated before the
calibration/adjustment routine is finished successfully. It shall be possible for the user to abort the
calibration/adjustment routine.
NOTE 1 If zero and span adjustment are carried out independently in separate routines, each parameter
may be updated individually after the respective routine is finished successfully.
d) Control or status bits shall be explicitly set or re-set in each program cycle.
NOTE 2 This may not be possible for all control and status bits (e.g. for latched alarms). Additional
measures for detecting corruption are described in 4.8, requirement 4).
4.3.4 Requirements for software documentation
The software documentation shall include:
a) designation of the apparatus to which the software belongs;
b) unambiguous identification of program version;
c) if applicable, version the operating system;
d) if applicable, versions of libraries;
e) any software modification provided with the date of change and new identification data;
f) documentation of the software development process (modification included, if applicable)
according to 4.3.5;
g) source code;
h) functional description;
i) software structure (e.g. flow chart, Nassi-Shneiderman diagram).
4.3.5 Requirements for the software development process
4.3.5.1 General
The software development shall be carried out according to the model described in Figure 1.
Figure 1 — Model of the software development process
It shall be ensured by suitable measures that
a) during development of the software
b) and for all modifications on the basis of an impact analysis
all applicable phases are processed and documented. For each software version, it shall be possible
to identify all parts of the software (software-documentation included) with respect to their version and
to identify the relationship between all parts unambiguously. That is, all parts of the software and all its
documentation shall be held under configuration management.
NOTE 1 The application of these measures ensures in conjunction with the requirements for the software
documentation according to 4.3.4 that the applicable requirements of EN 61508-3 to the configuration
management of the software are fulfilled for the purpose of this European Standard.
The results of each phase of the software development process shall be verified for consistency with
the input of the phase and for correctness as regards content. The results of each phase and the
verification shall be reviewed and approved by a second person. The results of each phase, the
results of the tests and the related verification shall be documented and held under configuration
management.
This verification includes the requirement that the test plans developed in individual phases of the
software development process shall be assessed with respect to their suitability and completeness.
NOTE 2 These tests and assessments include in conjunction with further regulations described in the following
clauses the applicable requirements of EN 61508-3 for software verification.
NOTE 3 Configuration management can be achieved by use of a suitable tool or by specification of appropriate
procedures.
Coding-guidelines shall be used in the coding phase. These shall
c) be used for the development of the entire software;
d) describe programming techniques to be used;
e) proscribe the use of unsafe language constructs;
f) specify procedures for source code documentation.
The documentation of each source code module shall contain at least the following:
g) legal entity (for example company, author(s));
h) intended use;
i) for each function/procedure, its inputs and outputs, their pre- and post-conditions, and their effect
on global state.
j) history of versions.
4.3.5.2 Specification of the requirements for the software
The requirements for the software shall be specified for each interface, including: hardware
components, human interfaces, communication interfaces. A concept for detection and handling of
faults on all these hardware components and interfaces shall be defined.
NOTE 1 The interfaces to the hardware include also the interfaces to devices which are not part of the
apparatus.
The requirements for the software shall be complete and unambiguous and shall be documented in
sufficient detail in natural language. Where practical, graphical schemes, tables, mathematical
formulas etc. may be used for the sake of precision.
It shall be possible to identify each requirement for the software unambiguously.
Each requirement for the software shall be traceable to a requirement for the apparatus.
A plan for validating the software shall be developed based on the specified requirements for the
software. The objective of the validation is to demonstrate that all specified requirements for the
software are satisfied.
NOTE 2 Parts of this validation will demonstrate that certain requirements of the metrological standards that
apply to the functionality of the apparatus are fulfilled.
Validation shall be carried out with the apparatus and therefore also includes the interaction of
hardware and software. Validation shall be carried out by means of a functional/black-box-test of the
apparatus (see 4.3.5.8).
The validation plan shall include at least the following:
a) test methods and test cases for each specified requirement for the software;
b) environmental conditions;
c) tools (for example test gases);
d) pass / fail criteria.
4.3.5.3 Software architecture
4.3.5.3.1 Architecture
The software architecture shall be designed based on
a) hardware architecture;
b) specification of the requirements for the software (see 4.3.5.2).
The software architecture shall
c) define a structured and modular design;
d) ensure that software modules have a clearly defined interface to other modules;
e) specify each interaction between software and hardware;
f) define measures for detection and handling of hardware faults.
The design of the software architecture and the software design (see 4.3.5.4) shall be carried out in a
structured manner. This includes a systematic approach including at least the following steps:
g) decomposition step by step of the software function into manageable software components;
h) assignment of data structures to the software components;
i) definition of the interfaces between the software components;
j) if applicable, selection of the operating system (see 4.3.1);
k) if applicable, selection of libraries (see 4.3.1).
The software architecture shall allow for tracing each requirement for the software from 4.3.5.2 to its
implementation in the software design according to 4.3.5.4.
The hardware-software integration tests shall be specified based on the software architecture (see
4.3.5.7).
4.3.5.3.2 Tools and coding standards
Suitable, matching tools including languages, compilers, and, if used, tools for the configuration
management and automatic testing tools shall be selected. The availability of the tools over the whole
lifetime of the apparatus shall be considered.
The suitability of the tools for code generation (for example code generator, compiler) and of external
or re-used software (for example libraries) shall be assessed. At least the following criteria shall be
considered:
a) range of functions and performance;
b) operating experience;
c) updates, release notes;
d) error lists;
e) references;
f) publications related to the tool (for example tests or validation by a third party);
g) experience with similar products of the manufacturer;
h) market presence of the manufacturer.
NOTE 1 This assessment may be omitted if EN 61508 (or similar safety standard) certified tools are used.
Changing the version of the tools for code generation during the lifetime of the apparatus should be
avoided because otherwise the suitability has to be re-assessed.
The programming language and the coding standards shall support measures to avoid systematic
faults and foster predictable program execution. This can be achieved by applying the following
criteria.
Requirements for the programming language (by using coding standards, if necessary):
i) suitability for the application;
j) complete, unambiguously defined or restricted to unambiguously defined properties;
k) contain features that facilitate the detection of programming mistakes;
l) block structure.
The language should be user- or problem-orientated rather than processor/platform machine-
orientated. Widely used languages or their subsets are preferred to special purpose languages.
Low-level languages, in particular assembly languages, present problems due to their
processor/platform machine-orientated nature. Therefore, assembly languages should only be used
for tasks with low complexity. Any use of assembly language shall be justified explicitly in the software
documentation.
The programming language and the use of coding standards, if necessary, shall support
m) restriction of access to data in specific software modules (encapsulation);
n) further measures for fault avoidance, for example avoidance of unsafe constructs.
If the programming language allows unsafe constructs, their use shall be avoided by definition of a
subset. This subset shall be defined in coding standards.
NOTE 2 MISRA-C is an example of a language subset for the programming language C.
The use of the following unsafe constructs shall be avoided by the coding standards:
o) unconditional jumps excluding subroutine calls;
p) recursions;
q) dynamic variables or objects;
r) multiple entries or exits of loops;
s) multiple entries of subprograms or blocks;
t) implicit variable initialisation or declaration;
u) data of variable types (for example “void” in C);
v) equivalences of variables (for example “unions” in C), if write access occurs at more than one
place of the program;
w) automatic type conversion.
Pointer shall only be used as far as absolutely necessary.
Subprograms and blocks shall have one exit only.
4.3.5.4 Software design
The software design shall be carried out in a structured manner (see 4.3.5.3). It shall be possible to
demonstrate the implementation of each requirement for the software from 4.3.5.2.
The software design shall adhere to the following rules which shall be included i
...