A System Without DBDOC - Analysis I

This is the first of a series summarizing the severe errors found by DBDOC at INFI 90 sites that do not have our product for system integrity protection. Be assured that there are more errors in this system than the ones shown here, but this article highlights some of the glaring ones. The system has 5723 configuration sheets at a large power plant. This site gets no warning from its existing tools about the errors described below!  DBDOC, however, would be able to alert it to all of them.

Adapt Block Cloning Errors

There are two adapt block cloning errors, caused by failure to change S2 to match cloned logic. Two subsystems are not adapted, even though they look like they are.

[S2 of block 6115 should be 6116, not 5116]        [S2 of block 7814 should be 7815, not 1115]

TSTALM Cloning Errors

There are nine multiple TSTALM situations. Every one of these comes from S1 not being changed when logic was cloned. Fourteen actions can happen mysteriously when they should not, triggered by the prototype logic instead of the new logic. Even worse, fourteen actions do not happen when they should, because the cloned logic is not being tested.

[S1 of block 3130 should be 3122, not 2920]

Why fourteen? One instance was cloned badly six times.

TSTQ Block Inputs Without Quality to Test

There are 209 inputs to TSTQ blocks being tested that do not have quality to test. In addition, quality is being tested on 10 AO/L blocks that do not have quality on their input signal. Three of these flawed tests control the manual interlock of control loops, so the loop will not go into Manual when the quality is bad.

[Analog Transfer block 4307 FC 9 does not have quality to test]

It is disconcerting that a number of the errors flagged look like OR and TSTALM block outputs are being handled incorrectly by being inputs to TSTQ blocks, instead of being OR'd with the outputs.

REDAI Blocks Used Without Being Tested for Quality

There are 46 instances where REDAI blocks can synthesize bad quality, but the value is then used whether or not it is bad. The first one I checked can be bad quality but still control a "FD AIR MASTER" control loop.

The one shown here is kind of cute, if you like scary productions. Good engineering was undone.

[Analog Transfer block 1835 FC 9 does not have quality to impart to the AO/L block and tag]

Function Block Errors

Among the function generator blocks, there are

• four that change from slope 1:3 to 1:1 instead of clamping
• four that change from slope 4:1 to 1:1 instead of clamping
• two that change from slope 7:1 to 1:1 instead of clamping
• three that with slope 1:1 that also do not clamp

[The large equal value (X,Y) pairs mean that the output rises at the same slope as the input]

Too Few Inputs
One 8 input Qualified OR block has four inputs, but needs seven to trigger it. It ain't gonna happen!

[Qualified OR block 7273 FC 36 will be a 1 if S9 (value 7) of the 4 inputs are value "1"]

Rung Block Errors

Two rung blocks ignore an input without documentation. If a test is in progress, too bad!

[S3 value 20 of FC 111 block 5026 means that value of "TTY TEST IN PROGRESS" is wiped out]

One rung block tests vibration limits, but does not disable the result on bad quality, as designed.

[S6 value 0 of FC 111 block 2606 means that value of  the test quality block is ignored]

Other Errors

There are 29 DAANG and AO/L blocks giving continuous exception reports.

There are 15 DAANG block tags that are designed to show some or all of 2nd and 3rd high and low alarms that will not do that.

One MA Station has type 5, not defined. Another has its initial mode after startup value set to 0, also not defined.

Summary

339 errors are outlined above. This is 339 errors more than the site knows about. What risks do these errors represent to the site? Why do these errors exist undetected? Should this system even be running?

DBDOC 10.7: Now Detects Unitialized Rung Stacks

We always have our eyes out for new error situations that DBDOC can detect and protect you from.

At a training session recently, we happened to notice a FC 111 rung block with mysterious output [1] (blue). This made no sense, because the logic is OUTPUT = (S13 OR S14 OR S15 OR S16) AND S17, but none of S13-16 are [1] (blue), so the output shouldn't be [1], but it is. We verified the specifications, which matched what the CLD showed.

There are actually two different reported errors on this particular block, as you can see from the presence of two error markers.  There is also an unreported error, which we will describe for completeness.

Rung block spec is wired but unused

The first (reported) error is reported as follows:

Rung block spec is wired but unused [ERROR 124]

Rung block Module 9,25,05 Block 7660 S12 is wired (block 3006) but unused by S2 value 000[92505F2A.CAD]

S2 is the operation that acts on input S12, but S2 is 0, which means ignore the input, and instead use the value from the top of the stack.  It may well be unintentional that S2's value be ignored.

Operation on an unwired input

There is actually another error which is not reported, because it makes no difference to the output:

The specs S2-S11 are operations on inputs S12-S21.  Some of these inputs (S16, S18-21) are unwired, and their corresponding operations are 0, as expected, except for S16.  S16 is unwired, but S6 is 12, not 0.   So to correct this error, S6 should be changed from 12 to 0.  However, the outcome is the same whether or not this "error" is corrected, so DBDOC doesn't report it.

New in 10.7: Rung stack not initialized

There is also another problem, the second reported error, which is the one causing the unexpected [1] output:

Rung stack not initialized [ERROR 306]

Rung block Module 9,25,05 Block 7660 logic invalid because S3 is an OR operation[92505F2A.CAD]

This is a type of error newly detected in DBDOC 10.7.  It is capable of causing a significant system error.

How these rung blocks work is that each operation is carried out in order, and the result of each operation is placed on the stack.  The next operation is typically an AND or OR with the current input and whatever is on the stack (i.e. the result of the previous operation).

1. In this case, the first operation is S2 (0) performed on input S12.  0 means use the value from the stack, i.e. ignore the actual input value S12.  As it happens, the uninitialized stack value is [1]!   But in any case S2 accomplishes nothing.
2. The next operation is S3 (12) performed on input S13.  This means OR the input S13 with the value on top of the stack.  Well, the value on top of the stack is [1], so the result of this operation is always [1], regardless of whatever S13 is.  So this operation is also pointless.
3. Similarly, S4 and S5 also OR their corresponding inputs with [1], yielding [1] on top of the stack.
4. Finally, S7 is 11, which means AND the input ([1] in this case) with the top of the stack (current top of stack is guaranteed to be [1]), for an inevitable [1] final output, regardless of the values of S2-S5.

The basic problem here is that the stack was not initialized. The logic would make sense if S2 was 10 (PUT) instead of 0.  S2=10 would mean put the value of S12 ([0]) onto the stack.  Then the next operation, S3 (12), would OR [0] with the value of S13, yielding the value of S13, instead of a guaranteed [1].  

(Technically, S3 could be 10 (PUT) instead (if S2 was actually meant to be ignored), hence the error message complaining that S3 is OR.  And either S2 or S3 could also be an 11 (AND) with no change in result).

The important thing is that the stack needs to be initialized sensibly with a PUT (x0) or an AND (x1) before it is used, or there will be unexpected results. 

Enjoy these examples from real systems.  DBDOC Version 10.7 and beyond will detect this uninitialized stack problem if you happen to have it lurking in your system.

Some details for those not familiar with DBDOC:

• Blue lines show a signal that carries the quality attribute.
• A white box shows value [0] whereas a blue box shows value [1].
• DBDOC presents the rung logic as a little ladder diagram.
• The little "top hat" symbol means a change from [0] to [1], triggering a [1] for one cycle.
• Specs can be moved in DBDOC to get them out of the way.
• The warning triangle shape is an Error Marker, informing you of a DBDOC message.
• The yellow box is a data tip telling you about the Error Marker.

These examples come from power plants in Delaware, Pennsylvania, Michigan and Wales. Where the logic was not used, the question can be asked if that was caused by inability to commission it.