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.
DBDOC is the only tool I have that provides a back stop for any errors that I introduce. I recently added a new input block for an off-module value. It went in okay. Two days later I was phoned and sent details of a value that was no longer changing and was confusing the operators. The process engineer's go to tool was DBDOC. An error marker was noted on the CAD sheet and all of this info sent to me. A frozen exception report had been created by my work due to a second import of the same off-module value. An easy fix once found but this should have been picked up by the native ABB/Bailey tools we have. DBDOC to the rescue yet again. Thanks.
ReplyDeleteThanks, Andrew. You have validated our overkill on errors:
ReplyDelete1. Report them so that you have a chance to fix them before they cause problems.
2. Back them up with Error Markers, so that they are visible when somebody is trouble-shooting or fault-finding or simply engineering.
We focus on errors as well as navigation simply because no competent engineer could stomach the errors that Composer and WinCAD do not detect.