Rockwell Automation T8094 8000 Series TMR System Safety Manual - Manual (Page 67)

SAFETY MANUAL
D oc N umber T8094
I ssue 27 – June 2013
Page 46 of 103
3.11.6 Program Testing
Even with a small number of inputs, it is possible to reach a point where the number of
tests becomes unreasonable. Eliminating impossible or unlikely scenarios should be
used to reduce the number of logic path tests that need to be performed. The
selection of what constitutes a scenario that does not require testing can be performed
only after a suitable hazard analysis.
The scenarios should include possible plant conditions, sequences of plant conditions,
system conditions (including partial power conditions, module removal and fault
conditions).
Where it is not possible to define a representative suite of test cases, all permutations
of input conditions, i.e. all possible states on all possible inputs, shall be exercised.
Where the logic includes memory or timing elements, additional tests shall be defined
to exercise all the possible sequences of input permutations leading to their operation.
All safety-related functions shall be tested and the results of the tests recorded.
The tests shall include the system scan time, fault detection time, fault reaction
time and throughput delay for shutdown logic. The system scan time, including
Peer-to-Peer Communications where appropriate, shall be less than ½ PST
E
.
Functional testing of all safety related programs is considered to be 100% if:
• All inputs are exercised through their entire allowable range
• All outputs are exercised through their entire program determined range
• All logic paths are exercised
• All timers have been tested regarding their timing characteristics without
changing timing parameters
• All combinatorial permutations of digital signals, with the exception of 100%
tested function blocks, are tested, including fault states.
• All combinatorial permutations of analogue signals, with the exception of
100% tested function blocks, are tested within the safety accuracy
granularity.
• All timing properties of each safety loop have been verified
3.11.6.1 Cross Reference Checking
While the aim shall be to minimise the coupling and dependencies between individual
programs, there will inevitably be occasions where, for example, a variable is used
within two or more programs. It is important to ensure that any application program
changes that affect these interactions do not jeopardise the functional safety.
The TMR system Toolset includes two cross-reference check tools. One of these
verifies the source cross-references, the other the compiled code cross-references.
Once the application program baseline has been established, these tools shall
be used following application modification. The identified interdependent
programs shall then be re-tested. Whenever a program modifies a shared
variable all programs that use that same variable shall be re-tested.
3.11.6.2 Code Comparison
After each phase of modification to the application as a whole, the TMR system
code comparison and run-time code version checker utilities shall be used to
identify those programs that have changed. Any program identified as having
undergone change, other than compiled variable addresses, shall be re-tested.