Your system depends on TSTQ to detect problems. Are these tests actually working?

I have taken the time to show and explain some of the many things that DBDOC checks for (and Composer does not). I believe there is no better tool for configuring INFI 90 than Composer, way ahead of WinCAD and DOS CADEWS. However, we have found that many errors exist "in the wild" and cannot stomach ignoring them.

One very common and pernicious error situation is when TSTQ blocks test the quality of signals that don't have quality. The test always succeeds, and this success allows whatever condition the test was designed to detect to go undetected. This is potentially dangerous, since the intention of some responsive action resulting from the detection of bad quality on a signal is silently thwarted.

To highlight problems of this sort, DBDOC checks to make sure that TSTQ block inputs actually can be bad quality, and reports errors when they are not. DBDOC also draws lines with quality in blue, making visual confirmation easy.

The following examples are from a system where DBDOC detected 82 instances of TSTQ being used to test signals without quality.

Overview:

In this first example, a signal called "LP EXT TO LP STM" is brought into the system to use in control. The TSTQ error found by DBDOC will cause bad quality on this signal to put part of the control loop into Manual, but leave part in Auto (not the designer's intention!).

Take a look at this image:

[A] Error message presented by DBDOC Error Browser

TSTQ 1SLPPC904@MI Module 1,02,02 Block 1668 tests Module 1,02,02 Block 1610 (FC 7), which does not have quality.

Clicking on the error in the Error Browser calls up the problem TSTQ block [1668].

[B] TSTQ block that is offending us

Input S1 is blue, showing that the signal can have bad quality. Input S2 is black, showing that the signal cannot carry quality ([E] on the second image shows where the quality was inadvertently stripped out).

[C] Intended action on bad quality of the second input

Bad quality is supposed to put the controller 1SLPPC904 "LP EXT PRESS CONT" in Manual Lock, but will not.

[D] Controller that is not handled correctly

Tag 1SLPPC904 "LP EXT PRESS CONT" will keep on in Auto, even if the input is bad.

As a contrast, here is a situation where bad quality is handled correctly, and will successfully trigger a controller to switch into manual.

[E] The Square Root function block that removes quality

The output of the square root block [1610], like all calculation and operation blocks, strips the quality attribute from the signal.

[F] Working action

Bad quality on the input correctly, with a 15 second delay, does cause an intended action.

[G] Intended action

After the delay, bad quality will put part of the control loop into Manual Lock.

[H] Controller that is handled correctly

Tag 1SLPFC904 "LP EXT TO LP STM HDR CONT" will be put into Manual if the input is bad.

Ramifications

Only 81 more of these TSTQ errors to analyze. Signals are never bad quality until they go bad quality. At that point, the plant is depending on the logic to protect it, and these error situations typically thwart the intent of the logic.