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

SAFETY MANUAL
D oc N umber T8094
I ssue 27 – June 2013
Page 44 of 103
3.11.4 Application Development
The application program development shall follow a structured approach and follow the
principles defined in para. 2.2.1.5. The stages defined in the following sub-sections
shall additionally be applied for safety related applications.
3.11.4.1 Partitioning the Application
It is impractical and unnecessary to apply the same degree of rigorous development
and testing to all functions within the Application where some of those functions are not
safety related.
The identification of safety functions is, in part, dependent on the specific safety
philosophy. Examples of non-safety may include status indication, data reporting and
sequence of events. It is important to establish that these elements are not safety
related. For example, some safety cases rely on human intervention and therefore the
correct operation of status indication.
The safety related elements shall be implemented within separate programs to
those of non-safety related elements. Where information passes between these
elements, it shall be arranged that the direction of flow is from safety relevant to
non-safety relevant only.
3.11.4.2 Defensive Measures
In defining the Application the programmer must consider the potential sources of error
and apply reasonable defensive programming techniques. Where values are received
from other programs or external communications interfaces, the validity of the values
should be checked where possible. Similarly, values received from input interfaces
should be checked where possible. In many cases, it will also be possible to monitor
permutations of data, inputs and plant operating modes to establish the plausibility of
the information and program measures to ensure safe responses in case of
implausible conditions.
Safety related functions shall be latched when in their tripped state to prevent
intermittent field faults from removing the trip condition. The application
software shall be written to ensure that safety related functions are in their safe
state during system startup.
3.11.4.3 Testable Blocks
Each safety-related software block shall be 100% testable. A 100% testable block is
the application logic that belongs to one safety function. Such functions could be:
• Burner flame supervision including temperature, air/gas pressure monitoring,
etc.
• Burner gas-to-air ration control/supervision
• Parts or whole of the start-up sequence of a batch reactor
The fewer the number of inputs, outputs and signal paths, the fewer the number of
permutations that require testing. However, a single safety function should not be split
into separate blocks; such a division is likely to lead to the introduction of errors during
maintenance activities.
The interaction between the individual software blocks shall be minimised. Where
interaction is necessary, it should be kept as simple as possible, for example a single
shutdown initiation signal.