See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/341255792

CENELEC EN 50128: Railway Applications -Communication, signaling and

processing systems, Software for railway control and protection systems

Conference Paper · May 2020

CITATION READS

1 23,144

1 author:

Abdullah Abdullah
Frankfurt University of Applied Sciences
1 PUBLICATION 1 CITATION

SEE PROFILE

All content following this page was uploaded by Abdullah Abdullah on 08 May 2020.

The user has requested enhancement of the downloaded file.

 CENELEC EN 50128: Railway Applications - Communication,
signaling and processing systems, Software for railway control and
protection systems
Abdullah Abdullah, 1271375

High Integrity Systems (M.Sc.)

Frankfurt University of Applied Sciences

Abstract— In modern times regulating processes and legal of railway systems [3]. The abbreviation EN stands for
frameworks are based on certification standards in almost every European Norms. The CENELEC standards are accepted
field.These standards help in providing reliability, availability, as EN. All member countries are bound to comply them
maintainability and safety (RAMS) to any project where they
are applied.CENELEC EN 50128 is one such European safety and are expected to give them the status of a national stan-
standard used for development of software for railway related dard without any alternation.CENELEC’s National Members
applications.It describes a set of requirements that must be met are the National Standardization Bodies (NSBs) of the 28
by the development, provision and maintenance of safetyrelated European Union countries, the Former Yugoslav Republic
software for railway control and monitoring systems. In this of Macedonia, Serbia and Turkey plus three countries of
document, I have attempted to describe the railway applications
standard CENELEC EN 50128 and its software development the European Free Trade Association (Iceland, Norway and
life cycle. Switzerland). There is one member per country [4].

I. INTRODUCTION II. P URPOSE AND S COPE

Ensuring a high level of railway safety is a very complex This European Standard specifies the process and techni-
task. Different safety standards are implemented for building cal requirements for the development of software for pro-
a railway system as shown below in Figure 1. grammable electronic systems for use in railway control and
protection applications. It is aimed at use in any area where
there are safety implications. These systems can be im-
plemented using dedicated microprocessors, programmable
logic controllers, multiprocessor distributed systems, larger
scale central processor systems or other architectures [6].
This European Standard is applicable exclusively to soft-
ware and the interaction between software and the system
of which it is part. This European Standard is not relevant
for software that has been identified as having no impact
on safety, i.e. software of which failures cannot affect any
identified safety functions. It applies to all safety related
software used in railway control and protection systems, in-
cluding application programming, operating systems, support
tools,firmware [6].
Fig. 1. Normative Context [1]. This European Standard also addresses the use of pre-
existing software and tools. Such software may be used, if the
CENELEC is the European Committee for Electro- specific requirements on pre-existing software and for tools
technical Standardization. Its is a nonprofit organization un- are fulfilled. Software developed according to any version of
der Belgian law, based in Brussels. AREMA is its American this European Standard will be considered as compliant and
counterpart. The members are the national electrotechnical not subject to the requirements on pre-existing software.This
standardization bodies of most European countries [2]. European Standard is not intended to be retrospective [6].
CENELEC EN 50128 identifies a process for creating soft-
III. F UNDAMENTAL P RINCIPLES
ware for railway applications and identifies the resources
which need to be mobilized in order to achieve the set level The following fundamental principles apply in developing
of assurance [1]. a high integrity system:
50128 standard was prepared by subcommittee 9XA of 1) Top-down design method
CENELEC technical committee 9X. It is part of a group of 2) modularity
standards which address the safety and reliability concerns 3) Verification after each development step
 4) Use of certified software modules and software module 50128 states that requirements should have the fol-
libraries lowing attributes: completeness, consistency, accuracy,
5) clear documentation unambiguous, understandability, and verifiability.
6) verifiable documents 2) Architecture Specification Phase: Keeping software
7) Test the software on the target hardware(validation) requirements specification as a base, this stage aims
to develop a software architecture that would aim to
IV. S AFETY I NTEGRITY L EVELS (SIL S ) achieve these requirements and evaluate the signifi-
EN 50128 standard uses SIL as a measure of reliability cance of hardware/software interactions for safety. The
and/or risk reduction. For different standards there exists purpose of the architecture specification is to analyze
different levels of safety.For EN 50128 there exists 5 levels the feasibility and options for achieving the stated SIL.
of safety as described below with SIL 4 the most dependable 3) Design and Development Phase: This stage involves
and SIL 0 the least. : designing and implementing the software that meets
• SIL 0: No safety requirements the stated SIL, and selects a suitable set of tools to
• SIL 1: Low safety requirements assist during verification, validation, assessment and
• SIL 2: Medium safety Requirements maintenance.
• SIL 3: High safety requirements 4) Software/Hardware Integration Phase: The purpose of
• SIL 4: Very high safety requirements the software/hardware integration phase majorly aims
that the software and hardware interact correctly to
Now the question remains as to what level of safety needs
perform the specified functions and meet the specified
to be applied. Well the answer is simple, it depends on the
SIL and safety requirements.
risk associated with the software being used in the system.
5) Validation Phase: This phase aims to determine
In case the risk is higher, high SIL level can be applied or
whether or not the integrated system complies with
vice versa. However if measures have been implemented to
specified functional, performance, safety, reliability,
prevent software failures or preventing the software to reach
and security requirements and achieves the stated SIL.
an unsafe state then in that case SIL level cab be reduced.
6) Assessment Phase: The purpose of the software assess-
Evaluation of the SIL of a software application is based
ment phase is to determine whether or not the software
on:
lifecycle processes and resulting products meet the
• The use of audits: is quality-assurance (QA) effectively
stated SIL.
employed on the project? 7) Maintenance Phase: The purpose of this phase is to
• Reviewing the plans (software QA plan, testing plan,
evaluate products of a given phase, to ensure correct-
verification and validation (VV) plan, etc.); ness and consistency with respect to the products and
• Reviewing the elements produced (documents, source
standards provided to that phase as appropriate for the
code, generation chain for the executable, data produc- stated SIL [3].
tion process, test scenarios and results, safety assess- All the above points have been summarised in figure
ment (e.g.Software Error Effect Analysis (SEEA)), etc.); 2.
• Formulation of comments and potential non- The left side or top down branch of the figure con-
conformities; sists of the development activities/processes: System
• Formulation of an assessment in the form of an evalu-
Definition and applications condition stage pertains to
ative report [1]. defining the system, sub system, and functions with
V. SOFTWARE DEVELOPMENT LIFE CYCLE SIL at the base of definitions.
After definitions are identified, requirement specifica-
EN 50128 does not explicitly specifies a particular soft- tions are taken into considerations with the focus of
ware development methodology, however it recommends V- achieving the defined functions with SIL targets.
model as a software development lifecycle. The standard Appointment of system requirements stage caters to
identifies seven life cycle phases: requirements specifica- the distribution of roles and responsibilities to the
tion, architecture specification, design and development, team members in accordance with their experience and
software/hardware integration, validation, assessment, and competencies.
maintenance. However, two activities are ongoing throughout Now begins the design and implementation stage
these life cycle phases which are, verification and quality as- which leads to the manufacture of the product/software
surance. The standard assumes that the software development with required SIL levels of all the safety functions.
life cycle begins after system-level functional, performances The right side or the bottom up branch consists of
safety, reliability, and security requirements have been allo- installation, assembly,receipt and operation.
cated to software [3]. Installation involves integrating the developed software
The seven stages of the SDLC are as follows: with the hardware and system verification stage verifies
1) Requirements Specification Phase: This stage com- that the installed software works as required.
prises of identification and decomposition of the Acceptance stage validates the software against the
system-level requirements allocated to software. EN system requirements. The ”V” here represents that

2
 what all actually got designed or implemented is • Identification, where applicable, of external risk reduc-
in compliance with the requirements.In other words tion facilities.[7].
acceptance phase is validated against development Redundant or back up risk reduction measures can be a
phases. combination of system design, procedures and external fa-
cilities. In these cases, the safety function can be performed
by devices having SILı́s lower than the one required to the
safety function, provided that the required independence and
functional diversity can be demonstrated [7]
After SILs have been identified further stages as discribed
by the V model can proceed further.However each stage will
aim to fulfill the requirements as set by the SIL identification
process described above. The allocation of SILs can therefore
be seen as an appropriate means to specify and design
a safe system. Verification at the overall system level of
compliance with the SIL assigned to safety functions should
be performed considering both the reliability of those sub-
systems and equipment involved in the safety function, and
the alternative measures available, which reduce the residual
risk of an accident.
Fig. 2. The V-model in CENELEC
VII. CENELEC 50128: V ERSION 2001 VERSUS
VI. A N EXAMPLE/EXPERIENCE : COPENHAGEN VERSION 2011
METRO
CENELEC 50128:2001 The structure of the 2001 version
Copenhagen is first automatic and driverless Danish metro. of CENELEC 50128 is shown in Figure 3. It should be
Here we will discuss about how SILs were determined for noted that in this version of the standard, clause 17 describes
the metro system and then once SILs are determined how the management of the software settings. This section was
further development can go on according to the standard. added to the initial draft. Therefore it does not respect
For approval of the whole metro system Denmark govern- the same structure as clauses 816 and is very difficult
ment relied on a proven German approval procedure called to implement. Clause 16 introduces the basic concepts of
BOStrab. BOStrab calls for compliance with the orders of software maintenance, whilst still being orientated toward
the Technical Supervisory Authority, and with the ”generally bug correction. In this version, it should be noted that there
accepted rules of technology” (GARTs). is a low degree of common activities (tests, verifications,
For the Copenhagen Metro, the European Standards for etc.)[1].
Railway Applications EN 50126,EN 50128, and ENV 50129
were assigned to act as GARTs for the safety assessment.
These standards were supplemented with other standards
such as fire standards. All safety activities and generation
of the safety documentation were performed according to
these standards.
The safety assessment of the Copenhagen Metro includes
the assessment of safety function / system / sub-system /
component specific allocations of Safety Integrity Levels
(SIL).The overall SIL for the entire Metro was kept to be
four with the aim of having as low risk as reasonably possible
. Hazard and Risk analyses and classification was performed
to identify adequate lower-level SILs to sub-systems and/or
safety functions.
Based on the results of the risk assessment process, the Fig. 3. CENELEC 50128:2001
safety integrity requirements were derived. [1]
In accordance with the standard following approach was
followed for the Copenhagen Metro SIL Assignment: CENELEC 50128:2011 identifies a process for creating
• Functional Analysis of the overall Metro to identify all software for railway applications, and identifies the resources
safety related functions. which need to be mobilized in order to achieve the set
• Identification of the required level of safety / SIL level of assurance. It introduces new requirements such as
assignment to safety related functions. separation between the generic software and the settings data,
• Assignment of each safety related function to safety certification of the tools, the need to document and the need
systems. to stay abreast of maintenance and the rollout of new versions

3
 of the software [1]. This version introduces the concept of (Reliability, Availability, Maintainability and Safety), not just
software assurance (SwA), which is targeted at developing reliability. It would be more useful if the standard provides
a software package with a level of error which is as low as the guidance on how to assemble and present adequate
possible, based on a skill evaluation, Quality Assurance, veri- evidence or proof that a system is safe and reliable [3].
fication, validation, and independent evaluation. It introduces
X. C ONCLUSION
a total separation between the data and the software of the
application, which is then called the generic software. One of Requirements and the development process provided by
the important points in the new version of CENELEC 50128 the Standard EN50128 discussed in this paper are no
is the addition of clause 9, which is devoted to the oversight different from other safety standards used for developing
of the softwares maintenance and deployment[1]. Figure 4 safety critical systems. However, when it comes to the
illustrates the structure of the 2011 version of CENELEC identification and definition of roles and competencies of
50128. A project evaluated as conforming to the 2011 version the team members the standard strives to make the best
also conforms to the 2001 version, but not vice versa. allocation.Other unique difference which adds to its strength
is that software and the corresponding embedded systems
must be certified by a government agency only. Standard also
promotes a common approach for assessing railway software
applications among different nations.The challenges faced by
the European Railway Authorities are considerably decreased
by this unified approach of adopting one standard for all.
R EFERENCES
[1] Boulanger, J.-L., CENELEC 50128 and IEC 62279 standards. John
Wiley Sons, 2015.
[2] “CENELEC Wikepedia,” https://en.wikipedia.org/wiki/European Com-
mittee for Electrotechnical Standardization, 2015, [Online; accessed
Nov-2019].
[3] Herrmann, D. S., “Cenelec en 50128, railway applications,” In Software
Safety and Reliability: Techniques, Approaches, and Standards of Key
Industrial Sectors, pp. 83–99, 2000, iEEE Computer Society, Los
Alamitos, California
[4] “CENELEC Members,” https://www.cenelec.eu/dyn/www/f?p=WEB:5,
2019, [Online; accessed Nov-2019].
Fig. 4. CENELEC 50128:2011 [5] CENELEC, E., “50128-railway applications-communication, signalling
and processing systems-software for railway control and protection
[1] systems,” Book EN, vol. 50128, 2012.
[6] “EN 50128 URL,”http://standards.globalspec.com/std/1678027/cenelec-
VIII. STRENGTHS en-50128, 2019, [Online; accessed Nov-2019]
[7] “EN 50128 URL,”http://http://www.railway-
The major technical strength of the standard is the guid- research.org/IMG/pdf/043.pdf, 2019, [Online; accessed Nov-2019]
ance provided by the techniques and measures to use to
achieve specified SILs. The techniques and measures are
grouped by lifecycle phase and activity. Each technique
or measure is given a code prescribing its use for a
given SIL:M-mandated, HR-Highly recommended, R- Rec-
ommended, NR-Not Recommended, F- Forbidden. This stan-
dard allows developers to select the lifecycle model and soft-
ware development methodology that is appropriate for their
application. The standard specifies the informational content
and types of documents to be developed while leaving the
document outline and format to developers. The standard
supports the use of electronic and hard copy documentation,
so it is readily available for inspection [3].
IX. AREAS OF IMPROVEMENT
There is no provision to estimate software failure proba-
bility in this standard. Calculation of software failure is done
using FTA (fault tree analysis) and FMECA (Failure mode,
effects and criticality analysis). Without the estimation of
software failure, it becomes almost impossible to find out
the software failure probability in a system. However, it is
easy to estimate the probability of failure from the non-
software causes. EN 50128 addresses the totality of RAMS

View publication stats