Monday, December 19, 2016

Has Recent Work Introduced Errors?

You may have read this analysis of the errors DBDOC found that had been introduced into a client system over four years.

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:
  1. How many errors that could hurt the plant are acceptable?
  2. Why were these errors not in front of the DCS team for evaluation?
  3. How could these errors, all breaking the rules, yield a clean Composer compile?
  4. 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.

Two of these errors are shown below. It is absolutely clear that S2 of block 1060 and S1 of block 1066 both should be 1062, not 2450. The value 2450 is residual from the working logic that was cloned into this logic. This is typical of a class of error made again and again by Composer users.

The block index for the prototype MSDRVR FC 129 Block 1062, centre of a wonderful set of beautiful functioning logic. The highlights show the four extra TSTALM block errors, so there are six of each. Not one of the errors was found when the work was done, compiled by Composer or loaded by the user.

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!


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.


  1. 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.

  2. Thanks, Andrew. You have validated our overkill on errors:

    1. 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.