Here is another summary analysis of the important errors introduced into a different system over five years. DBDOC makes this sort of analysis trivial if you have backups of systems before and after work is done. Here are questions that should be asked:
- How many errors that could hurt the plant are acceptable?
- Why were these errors not in front of the DCS team for evaluation?
- How could these errors, all breaking the rules, yield a clean Composer compile?
- Should Composer have caught them?
Duplicate ADAPT Blocks and Multiple TSTALM Blocks
There are ten errors that result from the failure of Composer to force a cloned ADAPT or TSTALM block to have S2 or S1 set to -1 when the block is cloned.
Some Function Blocks are Defaulted as Disabled
This error message shows that one lag function was not enabled when it was added. The effect would show up as inexpicable unintended excursions that are supposed to be smoothed out. Clearly, the default should be to be enabled, not disabled.
Specification out of Range
What does this block do?
We could guess. Why should we have to? Why is this not an error in Composer, as the only legal values are 0, 1 or 2?
TSTQ Tests Block With No Quality
The work being analyzed has only two errors where a block is being tested for quality when it does not have quality to test. Only two!
First, note how the blocks with quality, shown by DBDOC as blue lines, lose that attribute when they go through logic blocks. Here, the cost of the one second lag function is the loss of quality for the pressure signal.
So, bad quality on the pressure signal will not be detected. What is it supposed to do? Simply put the FLOW CONTROL STATION into Manual. Oops!
Summary
There are fourteen potentially significant errors documented here, with many more less severe not mentioned. They should not have been made, and they should have been caught.