EN 50271:2010

SLOVENSKI STANDARD
01-september-2010
1DGRPHãþD
SIST EN 50271:2002
(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:2010
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
June 2010
EUROPÄISCHE NORM
ICS 13.320 Supersedes EN 50271:2001

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  Elektrische Geräte für die Detektion
et de mesure des gaz combustibles, und Messung von brennbaren Gasen,
des gaz toxiques ou de l'oxygène - giftigen Gasen oder Sauerstoff -
Exigences et essais pour les appareils Anforderungen und Prüfungen
utilisant un logiciel et/ou des technologies für Warngeräte, die Software
numériques und/oder Digitaltechnik nutzen

This European Standard was approved by CENELEC on 2010-06-01. 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 Central Secretariat 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 Central Secretariat 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, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2010 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 50271:2010 E
Foreword
This European Standard was prepared by SC 31-9, Electrical apparatus for the detection and
measurement of combustible gases to be used in industrial and commercial potentially explosive
atmospheres, of Technical Committee CENELEC TC 31, Electrical apparatus for potentially explosive
atmospheres. It was submitted to the formal vote and approved by CENELEC as EN 50271
on 2010-06-01.
This document supersedes EN 50271:2001.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN and CENELEC shall not be held responsible for identifying any or all such patent
rights.
The State of the Art is included in Annex ZY “Significant changes between this European Standard
and EN 50271:2001”.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2011-06-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2013-06-01
This European Standard has been prepared under a mandate given to CENELEC by the European
Commission and the European Free Trade Association and covers essential requirements of
EC Directive 94/9/EC. See Annex ZZ.
__________
- 3 - EN 50271:2010
Contents
Introduction . - 4 -
1 Scope . - 5 -
2 Normative references . - 5 -
3 Terms and definitions . - 7 -
4 Design principles . - 8 -
4.1 Basic requirements . - 8 -
4.2 Displays . - 10 -
4.3 Software. - 10 -
4.4 Hardware . - 19 -
4.5 Digital data transmission between components of apparatus . - 19 -
4.6 Test routines . - 20 -
4.7 Instruction manual . - 21 -
4.8 Additional requirements for compliance with SIL 1 . - 22 -
5 Test of the digital unit . - 22 -
5.1 General . - 22 -
5.2 Verification of functional concept . - 23 -
5.3 Performance test . - 23 -
Annex A (normative) Hardware-software integration test . - 25 -
A.1 Functional testing/Black-box testing . - 25 -
A.2 Equivalence class test with boundary value analysis . - 25 -
Annex ZY (informative) Significant changes between this European Standard and
EN 50271:2001 . - 27 -
Annex ZZ (informative) Coverage of Essential Requirements of EC Directives . - 28 -

Figure
Figure 1 – Model of the software development process . - 12 -

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
assured.
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.
It is recommended to apply this European Standard for apparatus used for safety applications with
SIL-requirement 1 instead of EN 50402 because EN 50402 is designed for the assessment of more
complex gas detection systems with SIL-requirements greater than 1. However, the technical
requirements of EN 50271 and EN 50402 are the same for SIL 1.

- 5 - EN 50271:2010
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. Additional requirements are specified if compliance with safety integrity level 1 (SIL 1)
according to EN 61508 series is required for low demand mode of operation.
NOTE 1 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 2 For fixed apparatus used for safety applications with SIL-requirements higher than 1 EN 50402 is applicable.
This European Standard is applicable to fixed, transportable and portable apparatus intended for use
in domestic premises as well as commercial and industrial applications.
This European Standard does not apply to external sampling systems, 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 50241-1, EN 50241-2,
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 3 These European Standards will be mentioned in this European Standard as "metrological standards".
NOTE 4 The examples above show the state of the standardisation 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 EN 61508 series. It covers part of
the phase 9 "realisation" of the overall safety life cycle defined in EN 61508-1.
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.
EN 45544-1 Workplace atmospheres – Electrical apparatus used for the direct detection
and direct concentration measurement of toxic gases and vapours –
Part 1: General requirements and test methods
EN 45544-2 Workplace atmospheres – Electrical apparatus used for the direct detection
and direct concentration measurement of toxic gases and vapours –
Part 2: Performance requirements for apparatus used for measuring
concentrations in the region of limit values
EN 45544-3 Workplace atmospheres – Electrical apparatus used for the direct detection
and direct concentration measurement of toxic gases and vapours –
Part 3: Performance requirements for apparatus used for measuring
concentrations well above limit values
EN 45544-4 Workplace atmospheres – Electrical apparatus used for the direct detection
and direct concentration measurement of toxic gases and vapours –
Part 4: Guide for selection, installation, use and maintenance
EN 50104 Electrical apparatus for the detection and measurement of oxygen –
Performance requirements and test methods

EN 50194-1 Electrical apparatus for the detection of combustible gases in domestic
premises – Part 1: Test methods and performance requirements
EN 50194-2 Electrical apparatus for the detection of combustible gases in domestic
premises – Part 2: Electrical apparatus for continuous operation in a fixed
installation in recreational vehicles and similar premises – Additional test
methods and performance requirements
EN 50241-1 Specification for open path apparatus for the detection of combustible or
toxic gases and vapours – Part 1: General requirements and test methods
EN 50241-2 Specification for open path apparatus for the detection of combustible or
toxic gases and vapours – Part 2: Performance requirements for apparatus
for the detection of combustible gases
EN 50291-1 Electrical apparatus for the detection of carbon monoxide in domestic
premises – Part 1: Test methods and performance requirements
EN 50291-2 Electrical apparatus for the detection of carbon monoxide in domestic
premises – Part 2: Electrical apparatus for continuous operation in a fixed
installation in recreational vehicles and similar premises including
recreational craft – Additional test methods and performance requirements
EN 50402:2005 + A1:2008 Electrical apparatus for the detection and measurement of combustible or
toxic gases or vapours or of oxygen – Requirements on the functional
safety of fixed gas detection systems
EN 60079-29-1:2007 Explosive atmospheres – Part 29-1: Gas detectors – Performance
requirements of detectors for flammable gases (IEC 60079-29-1:2007,
mod.)
EN 60079-29-2 Explosive atmospheres – Part 29-2: Gas detectors – Selection, installation,
use and maintenance of detectors for flammable gases and oxygen
(IEC 60079-29-2)
EN 61508-1:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 1: General requirements
(IEC 61508-1:1998 + corr. May 1999)
EN 61508-2:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 2: Requirements for
electrical/electronic/programmable electronic safety-related systems
(IEC 61508-2:2000)
EN 61508-3:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 3: Software requirements
(IEC 61508-3:1998 + corr. Apr. 1999)
EN 61508-4:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 4: Definitions and abbreviations
(IEC 61508-4:1998 + corr. Apr. 1999)
EN 61508-5:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 5: Examples of methods for the determination of
safety integrity levels (IEC 61508-5:1998 + corr. Apr. 1999)
EN 61508-6:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 6: Guidelines on the application of IEC 61508-2 and
IEC 61508-3 (IEC 61508-6:2000)
EN 61508-7:2001 Functional safety of electrical/electronic/programmable electronic safety-
related systems – Part 7: Overview of techniques and measures
(IEC 61508-7:2000)
- 7 - EN 50271:2010
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 60079-29-1:2007 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 take place, for
example warm-up, maintenance mode (configuration, calibration, etc) or fault condition
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
[EN 61508-4:2001, 3.6.4, mod.]
3.5
parameters
settings by the manufacturer or user which effect the operation of the software, e.g. changing of alarm
thresholds or measurement units. Parameter options are included in the software during design of the
apparatus. Changes of parameter settings are not modifications of the software
3.6
specified range of input values
range of input values corresponding to the conversion range of the A/D- or D/A-converter
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
part 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 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 measurement 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 “minimum deviation of indication”.
The minimum 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
[EN 50402:2005, 3.21, mod.]
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
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 may not include environmental interferences to the A/D- or D/A-converters, e.g. temperature variation.
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, the influence of the sensing
principle such as non-linear behaviour of the signal or ageing of sensors, varying sensitivities for
different gases and signal variation with temperature, pressure or humidity shall be taken into
consideration.
- 9 - EN 50271:2010
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 control automatically the specified input data range and
handle range violations. Zero and full scale 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 control automatically the allowed data ranges and handle
range violations.
During measuring operation, the maximum overall time of four successive updates of the output
signals shall not exceed the response time t 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 Fixed and transportable apparatus
a) Control units
While a special state is present within the gas detection system (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 signalling that the entire gas detection system is in the special state "fault"
shall use the idle current principle.
b) Gas detection apparatus (transmitters) intended to be used with control units
A special state of the gas detection apparatus shall be transmitted to the control unit
continuously.
c) Apparatus having self-contained sensors
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 signalling that the entire apparatus is in the special state "fault" shall use the idle current
principle.
NOTE 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.2 Portable apparatus
The special state "fault" shall be continuously indicated by an optical and acoustic signal.
NOTE 1 It may be possible to silence the acoustic signal.
NOTE 2 It will not be possible to show an indication in all possible fault situations without implementing an emergency path,
e.g. to detect sudden breakdown of battery voltage without second independent power supply. However it is possible to indicate
the normal operation of the apparatus by a periodic optical and acoustical output signal (commonly called alive signal or
confidence signal).
The special state "warm-up" shall be indicated by an optical and/or acoustic signal.
The special states "calibration mode" and "parametrisation 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.
nd
alarm threshold includes
If a message includes another subsidiary message (e.g. exceeding the 2
st
exceeding the 1 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.
NOTE 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.
4.3 Software
4.3.1 General
This clause defines 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.
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. Re-used or
commercial software modules (e.g. libraries) shall be qualified (see 4.3.5.3.2).
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, only the
requirements of 4.3.3, 4.3.4 a)-h) and 4.7 shall be applied.

- 11 - EN 50271:2010
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.
NOTE 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 is 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 unauthorised persons, e.g. it may be integrated
by an authorisation code in the software or may be realised 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 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.
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-Schneidermann 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.
Software requirement
Validation
specification
Software – Integratio n Hard-
architecture ware - Softwar e
Software – Software -
design test
Coding
Figure 1 – Model of the software development process

- 13 - EN 50271:2010
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 and 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.
NOTE 2 This 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 3 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.
Coding standards 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 Software requirements specification
The software requirements shall be specified for each interface, including: hardware devices, human
interfaces, communications interfaces. A concept for handling faults on all these interfaces shall be
defined.
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.

The requirements for the software shall be specified for each interface to the hardware. A concept for
detection and handling of hardware faults shall be defined.
NOTE 1 The interfaces to the hardware include also the interfaces to the periphery.
A plan for validating the software shall be developed based on the specified requirements for the
software. 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) software requirements specification (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 software requirement from 4.3.5.2 to its
implementation in the software design according to 4.3.5.4.

- 15 - EN 50271:2010
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.
NOTE 2 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.
NOTE 3 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.
NOTE 4 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 5 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, if write access occurs at more than one place of the program.
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 software requirement from 4.3.5.2.
The software design shall adhere to the following rules which shall be included in the software
developers programming standard:
a) decomposition of the software components into systems of software modules;
b) specification of the functionality of the software modules;
c) specification of data structures and assignment to the software modules; this specification shall
be consistent with the functional requirements of the apparatus, complete and free of
contradictions;
d) definition of unambiguous interfaces between the software modules;
e) design of the software modules;
f) specification of test methods and test cases for each software module (specification of module
testing, see 4.3.5.6);
g) specification of test methods and test cases for the entire software (specification of software
integration test, see 4.3.5.6).
The software design shall be carried out according to the following rules:
h) the software modules shall be decoupled as far as possible and all interactions are explicit;
i) suitable limitation of module size;
j) each interface of a software module shall only contain only those parameters which are
necessary for its function;
k) compose the software module control flow using structured constructs, that is sequences,
iterations and selection;
l) keep the number of possible paths through a software module small;
m) avoid complex branching;
- 17 - EN 50271:2010
n) avoid complicated calculations as basis for branching or loop conditions;
o) software modules shall usually communicate with other software modules via their interfaces -
where global or common variables are used:
1) they shall be well structured;
2) they shall be declared in one central module;
3) access shall be controlled;
4) their use shall be justified in each instance;
5) competing write- and read-access by parallel running processes shall be avoided;
p) multiple calls (for example by interrupts) of subprograms which are not re-entry capable shall be
avoided.
4.3.5.5 Coding
The source code shall
a) be readable, understandable, and testable;
b) implement the design of the software modules (see 4.3.5.4);
c) satisfy the requirements of the coding standards (see 4.3.5.3.2);
d) implement each software requirement from 4.3.5.2.
It shall be verified for each software module by a tool-based static code analysis and, if necessary, by
supplementary measures that the coding standards (see 4.3.5.3.2) are satisfied.
4.3.5.6 Software test
The software test consists of software module tests and an integration test.
...