679 / 975
Figure 2: basic software structure of a simple instrumented function
•
The first block, block 1 interfaces with the input module connected to the field sensor
•
Block 2 provides interface to the HMI system for the sensor element, reporting the
measured value. It subjects the measurement to signal conditioning, and generates
a trip output if the measurement exceeds the trip set point. It may also incorporate
latch and override facilities.
•
Block 3 represents logic where one signal may be combined with others. This could
consist of voting logic, or a logical AND/OR operation, and time delays.
•
Block 4 provides interface to the HMI system for the output element, such as a
shutdown valve. It may also incorporate latch or possibly override facilities.
•
Block 5 interfaces with the output module, translating a boolean 0 or 1 into typically
0V or 24V outputs.
2.3
Analysis of Code Review results
It’s useful to review the types of errors, flaws and anomalies found in application software.
In the following sections, the errors are broken down into 8 categories, starting with the most
serious.
Apart from the most serious errors, many of the anomalies described below would not be
detected by simple proof testing, or even by rigorous stress testing.
i)
Safety function will not work at all
This category of anomalies, clearly the most serious, is fortunately one of the rarest. For a
safety instrumented function to not work at all, a serious breakdown in processes must have
occurred – implying that design verification, testing and/or validation have completely failed
at some point. Many of the errors in this category point to commissioning or brownfield
changes where logic is forced or disabled, probably post validation, to prevent unwanted
shutdowns. Examples of software forces include:
•
Software force applied to I/O driver or communications blocks.
•
Trip function switched off on the software function block.
•
Temporary logic inserted into the application software to defeat logic.
Self-revealing bypasses (such as Maintenance Override switches) should always be
preferred, and any forces, no matter how temporary, must be logged in order to ensure they
are removed. It has to be recognised that during testing or plant start-up phases,
maintenance override switches may not provide sufficient bypass facilities. For this reason
it’s essential that design, commissioning, operations and modification procedures
incorporate auditable procedures for the implementation of software forces, enabling such
forces to be removed later.