Annex J
(informative)
Example of SRESW realisation

J.1 Description of example

In Annex J the process steps for realizing the SRESW of an SRP/CS for PL r d are presented. The SRP/CS
is interfaced with the machine equipment. It ensures

— the acquisition of information sent by the various sensors,

— the processing required to operate the power control elements taking into account the safety
requirements, and

— the piloting of the power control elements.
The function diagram of this application’s SRESW is as shown in Figure J.1.

J.2 Application of V-model of software safety lifecycle

Table J.1 presents the development activities, their corresponding verification steps, and the related
documentation. These activities follow the V-model of software safety lifecycle according to Figure 14a..

J.3 Verification of software specification at different levels (i.e. SDS, SSDS, MDS)

As part of the software safety lifecycle according to Figure 14a, the verification activities at each level of the software specifications consists in reading the specifications so as to verify that all the sensitive points are properly described. The following should be considered when verifying each software function:

a) limiting the cases of erroneous interpretation of the software specifications;

b) avoiding gaps in the specifications resulting in an unknown behaviour of the SRP/CS;

c) precisely defining conditions for activation and de-activation of functions;

d) precisely guaranteeing that all the possible cases are handled;

e) consistency tests;

f) the different parameterizing cases;

g) the reaction following a failure.

J.4 Example of programming rules

In general it should be possible to identify the software version. Modifications should be documented with author, date and type of modification. Concerning the programming rules the following rules can be differentiated.

a) Programming rules at level of the program structure

The programming should be structured so as to display a consistent and understandable general skeleton allowing the different processing to be easily localized. This implies

1) use of templates for typical program or function blocks,

2) partitioning of the program into segments in order to identify main parts corresponding to “inputs”, “processing” and “outputs”,

3) comments on each program section in the source of the program to facilitate the updating of the comment in case of modification,

4) description of the role a function block has when calling this block,

5) that memory location should be used only by one single kind of data type and be marked by unique labels, and

6) that the working sequence should not depend on variables such as a jump address calculated at runtime of the program, conditional jumps being authorized.

b) Programming rules regarding the use of variables

— The activation or de-activation of any output should take place only once (centralized conditions).

— The program should be structured such that the equations for updating a variable are centralized.

— Each global variable, input or output should have a mnemonic name explicit enough and be described by a comment within the source.

c) Programming rules at level of a function block

1) Function blocks that have been validated by the supplier of the SRP/CS should be used. It should be checked that the assumed operating conditions for these validated blocks correspond to the conditions of the program..

2) The size of the coded block should be limited to the following guideline values:

— parameters – maximum eight digital and two integer inputs, one output;

— in function code – maximum 10 local variables, maximum 20 Boolean equations.

3) The function blocks should not modify the global variables.

4) Each value should be compared to expected pre-set benchmarks to ensure its validity.

5) The input parameters of a function block should be checked for inconsistencies.

6) Each fault code should be accessible and allow a clear identification of the original fault.

7) The fault codes and the state of the block after fault detection should be described by comments.

8) The resetting of the block or the restoration of a normal state should be described by comments.