Reference Documentation Impementation Reference V&V

Detail Requirement Description Category Remark/ Status

Document Name Terms Clause Subclause Input Output Document Name Tagging V&V Method used V&V Reference V&V Result V&V Result Reference
EN 50128 : 2011 Software Testing 6.1 6.1.4.1 Tests performed by other parties if - All necessary System, Hardware and Software Documents:
fully documented and complying with the following Documentation as specified in the Software - Software Test Specification
requirements, may be accepted by the Verifier. Verification - Software Test Report
Plan. - Software Integration Test Specification
- Software Integration Test Report
EN 50128 : 2011 6.1.4.2 Measurement equipment used for testing shall be - - Software/Hardware Integration Test Specification
calibrated appropriately. Any tools, hardware or - Software/Hardware Integration Test Report
software, used for testing shall be shown to be suitable - Software Component Test Specification
for the purpose - Software Component Test Report

EN 50128 : 2011 6.1.4.3 Software testing shall be documented by a Test -

Specification and a Test Report, as defined.

EN 50128 : 2011 6.1.4.4 Shall document some points mentioned in Section -

6.1.4.4

EN 50128 : 2011 6.1.4.5 A Test Report shall be produced as mentioned in Section -

6.1.4.5

EN 50128 : 2011 Software Verification 6.2 6.2.4.1 A Software Verification Plan shall be written, under the - All necessary System, Hardware and Software Documents:
responsibility of the Verifier, on the basis of Documentation. - Software Verification Plan
the necessary documentation - Software Verification Report(s)
- Software Quality Assurance Verification Report

EN 50128 : 2011 6.2.4.2 The Software Verification Plan shall describe the -
activities to be performed to ensure proper
verification and that particular design or other
verification needs are suitably provided for.

EN 50128 : 2011 6.2.4.3 The Software Verification Plan shall describe the Software Verification Plan.
activities to be performed to ensure proper
verification and that particular design or other
verification needs are suitably provided for.

EN 50128 : 2011 6.2.4.4 During development (and depending upon the size of the Software Verification Plan.
system) the plan may be sub-divided into a
number of child documents and be added to, as the
detailed needs of verification become clearer.

EN 50128 : 2011 6.2.4.5 The Software Verification Plan shall document all the Software Verification Plan.
criteria, techniques and tools to be used in the
verification process. The Software Verification Plan shall
include techniques and measures chosen from Table A.5,
Table A.6, Table A.7 and Table A.8. The selected
combination shall be justified as a set satisfying 4.8, 4.9
and 4.10.

EN 50128 : 2011 6.2.4.6 The Software Verification Plan shall describe the Software Verification Plan.
activities to be performed to ensure correctness
and consistency with respect to the input to that phase.
These include reviewing, testing and integration.

EN 50128 : 2011 6.2.4.7 In each development phase it shall be shown that the Software Verification Plan.
functional, performance and safety
requirements are met.

EN 50128 : 2011 6.2.4.8 The results of each verification shall be retained in a Software Verification Plan.
format defined or referenced in the Software
Verification Plan.

EN 50128 : 2011 6.2.4.9 The Software Verification Plan shall address mentioned Software Verification Plan.

EN 50128 : 2011 6.2.4.10 A Software Quality Assurance Verification Report shall be -

written, under the responsibility of the
Verifier, on the basis of the input documents from 6.2.2

EN 50128 : 2011 6.2.4.11 Once the Software Verification Plan has been Software Quality Assurance Verification Report.
established, verification shall address some points
mentioned

EN 50128 : 2011 6.2.4.12 Any Software Verification Reports shall be written, under -
the responsibility of the Verifier, on the
basis of the input documents. These reports can be
partitioned for clarity and convenience, and shall follow
the Software Verification Plan. The requirement in
EN 50128 : 2011 6.2.4.13 6.2.4.13
Each refers Verification
Software to the Software Verification
Report Reportsas
shall document -
mentioned

EN 50128 : 2011 Software Valitdation 6.3 6.3.4.1 The Software Validation activities shall be developed and - All system, hardware and software Documents:
performed, with their results evaluated, bya Validator documentation as specified in this European - Software Validation Plan
with an appropriate level of independence as defined in Standard. - Software Validation Report(s)
5.1. - Software Validation Verification Report

EN 50128 : 2011 6.3.4.2 Validation shall be documented with, at least, a Software -

Validation Plan and a Software Validation Report.

EN 50128 : 2011 6.3.4.3 A Software Validation Plan shall be written, under the -
responsibility of the Validator, on the basis of
the input documents.

EN 50128 : 2011 6.3.4.4 The Software Validation Plan shall include a summary Software Validation Plan
justifying the validation strategy chosen.

EN 50128 : 2011 6.3.4.5 The Software Validation Plan shall identify the steps Software Validation Plan
necessary to demonstrate the adequacy of any Software
Specification in fulfilling the safety requirements set out
in the System Safety Requirements Specification.

EN 50128 : 2011 6.3.4.6 The Software Validation Plan shall identify the steps Software Validation Plan
necessary to demonstrate the adequacy of the
Overall Software Test Specification as a test against the
Software Requirements Specification

EN 50128 : 2011 6.3.4.7 Software Validation Report shall be written, under the -
responsibility of the Validator, on the basis of
the input documents.

EN 50128 : 2011 6.3.4.8 The results of the validation shall be documented in the Software Validation Report
Software Validation Report.

EN 50128 : 2011 6.3.4.9 The Validator shall check that the verification process is Software Validation Report
complete.

EN 50128 : 2011 6.3.4.10 The Software Validation Report shall fully state the Software Validation Report
software baseline that has been validated.

EN 50128 : 2011 6.3.4.11 The Validation Report shall clearly identify any known Software Validation Report
deficiencies in the software and the impact
these may have on the use of the software.

EN 50128 : 2011 6.3.4.12 A Software Validation Verification Report shall be -

written, under the responsibility of the Verifier, on
the basis of the input documents from 6.3.2.

EN 50128 : 2011 6.3.4.13 Once the Software Validation Plan has been established, Software Validation Verification Report
verification shall address that the Software Validation
Plan meets the general requirements for readability and
traceability in 5.3.2.7
to 5.3.2.10 and in 6.5.4.14 to 6.5.4.17 as well as the
specific requirements in 6.3.4.4 to 6.3.4.6,

EN 50128 : 2011 6.3.4.14 Once the Software Validation Report has been Software Validation Verification Report
established, verification shall address that the Software
Validation Report meets the general requirements for
readability and traceability in
5.3.2.7 to 5.3.2.10 and in 6.5.4.14 to 6.5.4.17 as well as
the specific requirements in 6.3.4.8 to 6.3.4.11
and 7.7.4.7 to 7.7.4.11,

EN 50128 : 2011 6.3.4.15 The Validator shall be empowered to require or perform -

additional reviews, analyses and tests.

EN 50128 : 2011 6.3.4.16 The software shall only be released for operation after -
authorisation by the Validator

EN 50128 : 2011 6.3.4.17 Simulation and modelling may be used to supplement -

the validation process.
EN 50128 : 2011 Software assessment 6.4 6.4.4.1 The assessment of the software shall be carried out by an - 1) System Safety Requirements Specification 1) Software Assessment Plan
Assessor who is independent as 2) Software Requirements Specification 2) Software Assessment Report
described in 5.1.2.6 and 5.1.2.7. 3) All other documents necessary to carry out the 3) Software Assessment Verification Report
assessment process.

EN 50128 : 2011 6.4.4.2 Software with a Software Assessment Report from -

another Assessor does not have to be an object
of a new assessment. The assessor shall check that the
software is fit for its intended use within the intended
environment, and that the former assessment stated the
software has achieved a safety integrity level at least
equal to the required level

EN 50128 : 2011 6.4.4.3 The Assessor shall have access to all project-related -
documentation throughout the development process.

EN 50128 : 2011 6.4.4.4 Software Assessment Plan shall be written, under the -
responsibility of the Assessor, on the basis
of the input documents from 6.4.2. Where appropriate,
an existing documented generic Software Assessment
Plan or procedure may be used. The requirement in
6.4.4.5 refers to the Software Assessment Plan.

EN 50128 : 2011 6.4.4.5 The Software Assessment Plan shall include the following -
scope:
a) aspects with which the assessment deals;
b) activities throughout the assessment process and their
sequential link to engineering activities;
c) documents to be taken into consideration;
d) statements on pass/fail criteria and the way to deal
with non-conformance cases;
e) requirements with regard to content and form of the
Software Assessment Report.

EN 50128 : 2011 6.4.4.6 A Software Assessment Verification Report shall be -

written, under the responsibility of the Verifier,
on the basis of the input documents from 6.4.2.

EN 50128 : 2011 6.4.4.7 Once the Software Assessment Plan has been Software Assessment Verification Report.
established, verification shall address
a) that the Software Assessment Plan meets the general
requirements for readability and traceability in 5.3.2.7 to
5.3.2.10 and in 6.5.4.14 to 6.5.4.17 as well as the specific
requirements in 6.4.4.5,
b) the internal consistency of the Software Assessment
Plan.

EN 50128 : 2011 6.4.4.8 The Assessor shall assess that the software of the system -
is fit for its intended purpose and
responds correctly to safety issues derived from the
System Safety Requirements Specification

EN 50128 : 2011 6.4.4.9 The Assessor shall assess if an appropriate set of -

techniques from Annex A, suitable for the
intended development, has been selected and applied in
accordance to the required safety integrity level.

EN 50128 : 2011 6.4.4.10 The Assessor shall assess the configuration and change -
management system and the evidences
on its use and application.

EN 50128 : 2011 6.4.4.11 The Assessor shall review the evidence of the -
competency of the project staff according to Annex B
and shall assess the organisation for the software
development according to 5.1.

EN 50128 : 2011 6.4.4.12 For any software containing safety-related application -

conditions, the Assessor shall check for noted deviations,
non-compliances to requirements and recorded non-
conformities if these have an impact
on safety, and make a judgment whether the justification
from the project is acceptable. The result shall be stated
in the assessment report.

EN 50128 : 2011 6.4.4.13 The Assessor shall assess the verification and validation -
activities and the supporting evidence

EN 50128 : 2011 6.4.4.14 The Assessor shall agree the scope and contents of the -
Software Validation Plan. This agreement
shall also make a statement concerning the presence of
the Assessor during testing.

EN 50128 : 2011 6.4.4.15 The Assessor may carry out audits and inspections (e.g. -
witnessing tests) throughout the entire development
process. The Assessor may ask for additional verification
and validation work.

EN 50128 : 2011 6.4.4.16 -

A Software Assessment Report shall be written under the
responsibility of the Assessor.
Requirements from 6.4.4.17 to 6.4.4.19 refer to the
Software Assessment Report.
EN 50128 : 2011 6.4.4.17 The Software Assessment Report shall meet the -
requirements of the Software Assessment Plan
and provide a conclusion and recommendations.

EN 50128 : 2011 6.4.4.18 The Assessor shall record his/her activities as a -

consistent base for the Software Assessment
Report. These shall be summarised in the Software
Assessment report.

EN 50128 : 2011 6.4.4.19 The Assessor shall identify and evaluate any non- -
conformity with the requirements of this European
Standard and judge the impact on the final result. These
non-conformities and their judgments shall be listed
in the Software Assessment Report.
 Reference
Document Name Terms Clause Subclause
EN 50128 : 2011 Software Quality Assurance (SQA) 6.5 6.5.4.1

EN 50128 : 2011 6.5.4.2

EN 50128 : 2011 6.5.4.3

EN 50128 : 2011 6.5.4.4

EN 50128 : 2011 6.5.4.5

EN 50128 : 2011 6.5.4.6

EN 50128 : 2011 6.5.4.7

EN 50128 : 2011 6.5.4.8

EN 50128 : 2011 6.5.4.9

EN 50128 : 2011 6.5.4.10

EN 50128 : 2011 6.5.4.11

EN 50128 : 2011 6.5.4.12

EN 50128 : 2011 6.5.4.13

EN 50128 : 2011 6.5.4.14

EN 50128 : 2011 6.5.4.15

EN 50128 : 2011 6.5.4.16

EN 50128 : 2011 6.5.4.17

EN 50128 : 2011 Modification and change control 6.6 6.6.4.1

EN 50128 : 2011 6.6.4.2

EN 50128 : 2011 Support tools and languages 6.7 6.7.4.1

 Support tools and languages 6.7

EN 50128 : 2011 6.7.4.2

EN 50128 : 2011 6.7.4.3

EN 50128 : 2011 6.7.4.4

EN 50128 : 2011 6.7.4.5

EN 50128 : 2011 6.7.4.6

EN 50128 : 2011 6.7.4.7

EN 50128 : 2011 6.7.4.8

EN 50128 : 2011 6.7.4.9

EN 50128 : 2011 6.7.4.10

EN 50128 : 2011 6.7.4.11

EN 50128 : 2011 6.7.4.12

 Detail Requirement Description

All the plans shall be issued at the beginning of the project and updated during the lifecycle.

The organisations taking part in the software development shall implement and use a Quality
Assurance System compliant with EN ISO 9000, to support the requirements of this European Standard.
EN ISO 9001 certification is highly recommended.
A Software Quality Assurance Plan shall be written, under the responsibility of the Verifier, on the
basis of the input documents from 6.5.2.

A Software Quality Assurance Plan shall be written and shall be specific to the project. It shall
implement the requirements of 6.5.4.5.

As a minimum, the following items shall be specified or referenced in the Software Quality Assurance
Plan.
a) Definition of the life-cycle model
b) Documentation structure.
c) Documentation control
d) Tracking and tracing of deviations.
e) Methods, measures and tools for quality assurance according to the allocated safety integrity levels
(refer
to Annex A).
f) Justifications, as defined in 4.7 to 4.9, that each combination of techniques or measures selected
according to Annex A is appropriate to the defined software safety integrity level.

Quality assurance activities, actions, documents, etc. required by all normative sub-clauses of this
European Standard shall be specified or referenced in the Software Quality Assurance Plan and tailored
to the specific project.

A Software Quality Assurance Verification Report shall be written, under the responsibility of the Verifier,
on the basis of the input documents from 6.5.2.
Once the Software Quality Assurance Plan has been established, verification shall address:
a) that the Software Quality Assurance Plan meets the general requirements for readability and
traceability in 5.3.2.7 to 5.3.2.10 and in 6.5.4.14 to 6.5.4.17 as well as the specific requirements in 6.5.4.4
to 6.5.4.6,
b) the internal consistency of the Software Quality Assurance Plan.

Each planning document shall have a paragraph specifying details about its own updating throughout the
project: frequency, responsibility, method.

Each software document and deliverable shall be placed under configuration control from the time of its
first release.

Changes to all items under Configuration Management Control shall be authorised and recorded.

In addition to software development, the Configuration Management System shall also cover the
software development environment used during the full lifecycle

The supplier shall establish, document and maintain procedures for control of the external suppliers,
including
– methods and relevant records to ensure that software provided by external suppliers adheres to
established requirements. Previously developed software shall be assured to be compliant with the
required software safety integrity level and dependability. New software shall be developed and
maintained in conformity with the Software Quality Assurance Plan of the Supplier or with a specific
Software Quality Assurance Plan prepared by the external supplier in accordance with the Software
Quality Assurance Plan of the Supplier,
– methods and relevant records to ensure that the requirements provided to the External Supplier are
adequate and complete

Traceability to requirements shall be an important consideration in the validation of a safety-related

system and means shall be provided to allow this to be demonstrated throughout all phases of the
lifecycle.
Within the context of this European Standard, and to a degree appropriate to the specified software
safety integrity level, traceability shall particularly address
a) traceability of requirements to the design or other objects which fulfil them,
b) traceability of design objects to the implementation objects which instantiate them,
c) traceability of requirements and design objects to the tests (component, integration, overall test) and
analyses that verify them.

In special cases, e.g. pre-existing software or prototyped software, traceability may be established after
the implementation and/or documentation of the code, but prior to verification/validation. In these
cases,
it shall be shown that verification/validation is as effective as it would have been with traceability over all
phases.
Objects of requirements, design or implementation that cannot be adequately traced shall be
demonstrated to have no bearing upon the safety or integrity of the system.

The Change Management Process shall define at least the following aspects:
a) the documentation needed for problem reporting and/or corrective actions, with the aim of giving
feedback to the responsible management;
b) analysis of the information collected in the problem reports to identify its causes;
c) the practices to be followed for reporting, tracking and resolving problems identified both during the
development phase and during software maintenance;
d) the specific organisational responsibilities with regard to development and software maintenance;
e) how to apply controls to ensure that corrective actions are taken and that they are effective;
f) impact analysis of the effect of the changes on the software component under development or already
delivered;
g) impact analysis shall state the re-verification, re-validation and re-assessment necessary for the
change;
h) where multiple changes are applied, the impact analysis shall consider the cumulative impact;
i) authorisation before implementation.

All changes shall initiate a return to an appropriate phase of the lifecycle. All subsequent phases shall
then be carried out in accordance with the procedures specified for the specific phases in accordance
with the requirements in this European Standard.

* Software tools shall be selected as a coherent part of the software development activities
The selection of the tools in classes T2 and T3 shall be justified (see 7.3.4.12). The justification shall
include the identification of potential failures which can be injected into the tools output and the
measures to avoid or handle such failures.

All tools in classes T2 and T3 shall have a specification or manual which clearly defines the
behaviour of the tool and any instructions or constraints on its use.

For each tool in class T3, evidence shall be available that the output of the tool conforms to the
specification of the output or failures in the output are detected. Evidence may be based on the same
steps necessary for a manual process as a replacement for the tool and an argument presented if these
steps are replaced by alternatives (e. g. validation of the tool). Evidence may also be based on
a) a suitable combination of history of successful use in similar environments and for similar applications
(within the organisation or other organisations),
b) tool validation as specified in 6.7.4.5,
c) diverse redundant code which allows the detection and control of failures resulting in faults introduced
by a tool,
d) compliance with the safety integrity levels derived from the risk analysis of the process and procedures
including the tools,
e) other appropriate methods for avoiding or handling failures introduced by tools.

The results of tool validation shall be documented covering the following results:
a) a record of the validation activities;
b) the version of the tool manual being used;
c) the tool functions being validated;
d) tools and equipment used;
e) the results of the validation activity; the documented results of validation shall state either that the
software has passed the validation or the reasons for its failure;
f) test cases and their results for subsequent analysis;
g) discrepancies between expected and actual results.

Where the conformance evidence of 6.7.4.4 is unavailable, there shall be effective measures to control
failures of the executable safety related software that result from faults that are attributable to the tool.

The software or design representation (including a programming language) selected shall

a) have a translator which has been evaluated for fitness for purpose including, where appropriate,
evaluated against the international or national standards,
b) match the characteristics of the application,
c) contain features that facilitate the detection of design or programming errors,
d) support features that match the design method.
Where 6.7.4.7 cannot be fully satisfied, the fitness for purpose of the language, and any additional
measures which address any identified shortcomings of the language shall be justified and evaluated.

Where automatic code generation or similar automatic translation takes place, the suitability of the
automatic Translator for safety-related software development shall be evaluated at the point in the
development lifecycle where development support tools are selected.

Configuration management shall ensure that for tools in classes T2 and T3, only justified versions are
used.

Each new version of a tool that is used shall be justified (see Table 1). This justification may rely on
evidence provided for an earlier version if sufficient evidence is provided that
a) the functional differences (if any) will not affect tool compatibility with the rest of the toolset,
b) the new version is unlikely to contain significant new, unknown faults.
The relation between the tool classes and the applicable sub-clauses is defined within Table 1.
 Documentation
Category
Input
- All the documents available at each stage of the
lifecycle.

Software Quality Assurance Plan

-
Software Quality Assurance Verification Report

-
-

- 1) Software Quality Assurance Plan

2) Software Configuration Management Plan
3) All relevant design, development and analysis
documentation
4) Change Requests
5) Change impact analysis and authorisation

- Tools specification or manual.

-

-
-

-
Documentation Impementation Reference
Output Document Name
1) Software Quality Assurance Plan
2) Software Configuration Management Plan, if not
available at system level
3) Software Quality Assurance Verification Report
1) All changed input documents
2) Software Change records (see 9.2.4.11)
3) New Configuration records

Tools validation report (when needed see 6.7.4.4 or

6.7.4.6).
Tools validation report (when needed see 6.7.4.4 or
6.7.4.6).
pementation Reference V&V
Remark/ Status V&V Method V&V V&V V&V Result
Tagging
used Reference Result Reference