Reliability of Systems Audrius Grinys

Software safety lifecycle requirements in 61508 standard part 3

Software safety validation planning

Objective: To develop a plan for validating the software safety.

Scope: PES; Software system.

Inputs (information required): Software safety requirements specification.

Outputs (information produced): Software safety validation plan.

7.3.2 Requirements for the software safety validation planning (CEI/IEC 61508 – 3)

7.3.2.1 Planning shall be carried out to specify the steps, both procedural and technical, that
will be used to demonstrate that the software satisfies its safety requirements (see 7.2).
XP programming not contains any documentation for the software safety validation.
Developers software validate in their mind. It should be documented.

7.3.2.2 The plan for validating the software safety shall consider the following:
a) details of when the validation shall take place;
b) details of those who shall carry out the validation;
c) identification of the relevant modes of the EUC operation including:
 preparation for use including setting and adjustment,
 start up; teach; automatic; manual; semi-automatic; steady state of operation,
 re-setting; shut down; maintenance,
 reasonably foreseeable abnormal conditions;
d) identification of the safety-related software which needs to be validated for each mode of
EUC operation before commissioning commences;
e) the technical strategy for the validation (for example analytical methods, statistical tests
etc. (see 7.3.2.3);
f) In accordance with (e), the measures (techniques) and procedures that shall be used for
confirming that each safety function conforms with (1) the specified requirements for the
software safety functions (see 7.2), and (2) the specified requirements for software safety
integrity (see 7.2);
g) specific reference to the specified requirements for software safety (see 7.2);
h) the required environment in which the validation activities are to take place (for example
for tests this would include calibrated tools and equipment);
i) the pass/fail criteria (see 7.3.2.5);
j) the policies and procedures for evaluating the results of the validation, particularly
failures.
In this case also XP programming not documented in software safety validation planning
field. It should be documented.

NOTE These requirements are based on the general requirements of 7.8 of part 1.

1
Reliability of Systems Audrius Grinys

7.3.2.3 The technical strategy for the validation of safety-related software (see table A.7 —
software safety validation) shall include the following information:
a) choice of manual or automated techniques or both;
b) choice of static or dynamic techniques or both;
c) choice of analytical or statistical techniques or both.
In XP programing these strategy should be documented.

7.3.2.4 As part of the procedure for validating safety-related software, the scope and
contents of the planning for validating the software safety shall be reviewed with the
assessor or with a party representing the assessor, if required by the safety integrity level
(see 8.2.12 of part 1). This procedure shall also make a statement concerning the presence
of the assessor during testing.
In XP programing these strategy should be documented. In XP documentation not contain
with software validation.

7.3.2.5 The pass/fail criteria for accomplishing software validation shall include:
a) the required input signals with their sequences and their values;
b) the anticipated output signals with their sequences and their values;
c) other acceptance criteria, for example memory usage, timing and value tolerances.
In XP programing these strategy should be documented.

2
Reliability of Systems Audrius Grinys

Software design and development - Software module testing

Objective: To verify that the requirements for software safety (in terms of the required
software safety functions and the software safety integrity) have been achieved – to show
that each software module performs its intended function and does not perform unintended
functions.

Scope: Software modules.

Inputs (information required): Software module test specification; Source Code listing; Code
review report.

Outputs (information produced): Software module test results; Verified and tested software
modules.

7.4.7 Requirements for software module testing (CEI/IEC 61508 – 3)

NOTE 1. See also tables A.5, B.2, B.3 and B.6.

NOTE 2. Testing that the software module correctly satisfies its test specification is a
verification activity - see also 7.9. It is the combination of code review and software module
testing that provides assurance that a software module satisfies its associated specification,
ie it is verified.

7.4.7.1 Each software module shall be tested as specified during software design (see 7.4.5).
Actually XP agrees with it. To test modules, XP uses Unit Tests (unit testing is a procedure
used to validate that individual units of source code are working properly.). These are
automated tests that test the code. Every testing step in XP should be documented.

7.4.7.2 These tests shall show that each software module performs its intended function and
does not perform unintended functions.
In this case XP also agrees, but all test steps shoul be documented.

NOTE 1 This does not imply testing of all input combinations, nor of all output combinations.
Testing all equivalence classes (C.5.7 of part 7) or structure based testing (C.5.8 of part 7)
may be sufficient. Boundary value analysis (C.5.4 of part 7), control flow analysis (C.5.9 of
part 7) or sneak circuit analysis (C.5.11 of part 7) may reduce the amount of test cases to an
acceptable number. Analysable programs (C.2.7 of part 7) make the requirements easier to
fulfil.
NOTE 2 Where the development uses formal methods (C.2.4 of part 7), formal proofs (C.5.13
of part 7) or assertions (C.3.3 of part 7), such tests may be reduced in scope.
NOTE 3 Statistical evidence may be used as well (see annex D of part 7).

7.4.7.3 The results of the software module testing shall be documented.

In XP programming no documentation exist for testing, so we need to add documentation for
testing and results of testing.

3
Reliability of Systems Audrius Grinys

7.4.7.4 The procedures for corrective action on failure of test shall be specified.
In XP programming no documentation exist for testing, so we need to add documentation for
testing and specify all failures that occurs during testing.