678 / 973
The anomalies found however also indicate common techniques used, when parts of the
plant are running during late commissioning stages, to modify software avoiding spurious
trips. That is, a trip function is disabled to prevent an unwanted trip, modified on-line, but not
fully restored. Particular vigilance is needed for changes made once parts of the plant are
running.
Techniques can be applied to standard library function blocks to ensure that some forces are
self-revealing, via alarms. Other forces applied to fail-safe signals communicated between
logic solvers can be more difficult to make self-revealing, and specific test procedures may
be required to ensure such forces are removed.
ii)
Safety function seriously flawed: will only partly work or work too late
This group of anomalies in particular highlights the challenges in managing changes post
logic-solver FAT. Whether due to revisions in design documentation, or due to
commissioning changes, each phase of change brings with it an increased risk of introducing
errors. Examples of this group of serious anomalies include:
•
Part of logic missing – particularly a risk for complex logic with multiple inputs or
outputs.
•
Trip settings incorrect.
•
Timer periods incorrect.
•
Incorrect instrument range – usually introduced due to changes.
Strong management of change and verification procedures can prevent such errors being
introduced. Furthermore, the management of safety logic solver vendor competence
becomes a further challenge through multiple revisions of design documents where different
software engineers modify the original logic. It’s recommended to test each change made
post-FAT, rather than relying solely on the final validation testing to reveal errors.
iii)
Wrong signal connected / tag number discrepancy
Using the wrong signal in a safety function could have serious consequences. However,
experience has shown that tag number discrepancies revealed by code reviews are rarely
due to the wrong signal being connected. Rather, this highlights errors in the design
documents not corrected in as-built documentation. Such discrepancies go to the heart of
management of change procedures. Changing any tag number at any time during a project
can lead to this problem, and the importance of keeping design documents updated in line
with commissioning red-line mark-ups is evident. Global time differences between the
design authority and the commissioning team, along with 7 day working on site, can slow the
speed of response to site queries, leading to changes being made without master
documents being corrected, or worse, the wrong signal being connected.
iv)
Safety function will not work in certain circumstances
This rather general group of anomalies highlights the importance of considering wider logic
issues:
•
A maintenance override has been configured, when not permitted. Connecting the
override enable software parameter to an “override prohibited” tag is a technique to
explicitly prohibit overrides and avoid accidental re-enabling of overrides.
•
The precedence of two sets of competing logic incorrect.