BS 50128

No. Description Pg
1. EN 50129:2003, talks about safety related electronic system for signaling, it 9
also addresses approval process for individual systems which can exist within
the overall railway control and protection system.
2. Software safety integrity levels where 0 is the lowest and 4 the highest one. 9
The higher the risk resulting from software failure, the higher the software
safety integrity level will be.
3. The required techniques and measures for software safety integrity levels 0-4 9
are shown in the normative tables of Annex A.
4. The system safety requirements specification identifies all safety functions 10
allocated to software and determines their system safety integrity level.
5. Figure 1 (pg 11, page 24 and 25 for Figure 3 and 4) 10
Section a: Chapter 7.2 and 7.3
- Software Requirements Specification (safety strategy & safety integrity
level)
Section b: Chapter 7.4 and 7.5
- Design, develop and test the software
Section c: Chapter 7.6
- Integrate the software with hardware and verify functionality
Section d: Chapter 7.7 and 9.1
- Accept and deploy
Section e: Chapter 9.2
- Maintenance during operational life
6. Software Development: 10
Chapter 6.1 Testing
Chapter 6.2 Verification
Chapter 6.3 Validation
Chapter 6.4 Assessment
Chapter 6.5 Quality Assurance
Chapter 6.6 Modification and Change control
7. The standard does not mandate the use of software development lifecycle. If 10
needed, refer to Figure 3 and 4 or Chapter 7.1
8. Programmable electronic systems for use in railway control and protection 12
applications
9. The standard applies primarily to new development and major modification. 12
For minor changes, refer to Chapter 9.2
10. Annex A shall be used to assist in the selection of techniques and measures 18/19
appropriate to the software safety integrity level. If the table stated HR (Highly
Recommended) but is not used in the SIL, justify and document.
11 Objective, roles and responsibilities Chapter 5 19
- Individual needs to understand their roles and responsibilities (Annex B)
- Competency (Annex B)
12 Figure 2 illustrates the chart organization related to SIL 0 to 4 20
13 Chapter 6.5 23
(a) Lifecycle model (development of software) shall be selected and detailed
in software quality assurance plan Refer to Figure 3
(b) The lifecycle model shall take into account the possibility of iterations in
and between phases
 (c) Software Quality Assurance Plan, Software Verification Plan, Software
Validation Plan and Software Configuration Management Plan shall be drawn
up at the start of the project and maintained throughout the software
development life cycle.
14 Each document shall be traceable 23
15 Chapter 7.3.4.7 23
Except for documents relating to pre-existing software, each document shall
be written according to the following rules:
- It shall contain or implement all applicable conditions and requirements of
the preceding document with which it has a hierarchical relationship
- It shall not contradict the preceding document
16. Chapter 6: Software Assurance Requirement 25/27
(a) Testing Ascertain the behavior or performance against the corresponding 28/29
test specification (input/output documents) 30/35
(b) Verification Examine and arrive at a judgement based on evidence that
output items of a specific development phase fulfil the requirements and plans
with respect to completeness, correctness and consistency (input/output
documents).
- In each development phase, functional, performance and safety requirements
are met.
- Software Requirement Verification (Chapter 7.2.4.22)
- Software Architecture and Design Verification (Chapter 7.3.4.41, 7.3.4.42)
- Software Components Verification (Chapter 7.4.4.13)
- Software Source Code Verification (Chapter 7.5.4.10)
- Integration Verification (7.6.4.13)
(c) Validation Demonstrate that the processes and their outputs are such that
the software is of the defined software safety integrity level, fulfils the software
requirements and is fit for its intended application (input/output documents)
(d) Assessment To evaluate that the lifecycle processes and their outputs are
such that the software is of the defined software safety integrity levels 1-4 and
is fit for its intended application. (For SIL 0 requirement must be fulfilled
with certificate stating it compliance to EN ISO 9001, no assessment will be
required) (Input/output documents).
(e) Software Quality Assurance Ensure the software quality is achieved
(input/output documents)
(f) Modification and change control To ensure that the software perform as
required, preserving the software integrity and dependability when modifying
the software (input/output documents).
17 Software Requirements Chapter 7.2 40
- To describe a complete set of requirements for the software meeting all
system and safety requirement and provide a comprehensive set of documents
for each subsequent phase.
- To describe the overall software test specification
- IEC 9126 series: Software properties
(a) functionality
(b) robustness and maintainability
(c) safety
(d) efficiency
(e) usability
(f) portability
18 Architecture and Design Chapter 7.3 42
- To develop a software architecture that achieves the requirement of the
software
- To identify and evaluate software/hardware interactions for safety
- Choose a design method
- Design a software for SIL
19 Component Design Chapter 7.4 48
- Develop software component design that achieves the requirement of the
software design specification to the extent required by software safety integrity
level
20 Component implementation and testing Chapter 7.5 51
- Achieve software which is analyzable, testable, verifiable and maintainable
21 Integration Chapter 7.6 52
- To carry out software and software/hardware integration
- To ensure both are performing under their intended functions
22 Overall Software Testing/Final Validation Chapter 7.7 54
- Ensure compliance with the software specification, emphasizing on the
functional and safety aspects according to SIL
23 Application data typically take the form of parameter values or descriptions 56
(identify, type, location, etc) of external objects. Application algorithms may
take the form of e.g. function block diagrams, state charts and relay ladder
diagrams, which determine the desired response of the system according to its
inputs, its current state and specific parameter values.
24 Software Deployment and Maintenance Chapter 9 63
Deployment Chapter 9.1
- Ensure software performs as required, meet SIL and dependability when it is
deployed
(9.1.4.8) In case of incremental deployment , it is highly recommended for SIL
3 and 4, and recommended for SIL 1 and 2, that the software is designed to
include facilities which assure that activation of incompatible versions of
software components is excluded.
(9.1.4.10) A rollback procedure (i.e., capability to return to the previous
release) shall be available when installing a new software release.
25 Software Maintenance Chapter 9.2 64
- Ensure software performs as required, preserving the required SIL and
dependability when making corrections, enhancements or adaptations to the
software itself.
- For any software safety integrity level, the supplier shall, before starting work
on any change, decide whether the maintenance actions are to be considered
as major or minor or whether the existing maintenance methods for the system
are adequate. The decision shall be justified and recorded by the supplier and
shall be submitted to the Assessors evaluation.
- Maintenance to follow ISO/IEC 90003 Minimum level