A System Without DBDOC - Analysis II

This analysis focuses on the 219 errors in this site where TSTQ blocks test blocks inappropriately. There are 209 inputs to TSTQ blocks being tested that do not have quality to test. In addition, quality is being tested on ten AO/L blocks that do not have quality on their input signal.  I began this analysis in the earlier article: A System Without DBDOC - Analysis I and continue it here. Keep in mind that this is a running power plant!

TSTQ Testing Blocks Without Quality

To keep this brief, the images will show the block being tested. Be confident that it is feeding a TSTQ block input and that the intended protection for the plant is simply not present. Also, you might not be familiar with the feature of DBDOC that shows lines that can carry quality in blue, to contrast with lines that cannot carry quality in black.

Engineering Errors

It turns out that, in this system, somebody did not get the point about the TSTQ block. Half of the errors show places where the logic state of a function block is [1] in the alarm condition, but that state is fed into a TSTQ block instead of affecting the process by being input to an OR operation directly. 

TSTALM Block 8272 output does not have quality (note that it is a black line).  Therefore the TSTQ Block 8917 that tests it will never trigger due to this signal.  Nor will it trigger due to the actual situation the system designer presumably wanted to detect: that of TSTALM Block 8272 being [1].

The two instances of testing the low output (H//L Block 9763) are just as incorrect. The result should be OR'd, not tested for quality.

In these and similar situations, operational issues will fail to be detected as intended. There are 105 instances where a TSTQ tests a TSTALM [FC69] block, which does not have quality.  There two instances where a TSTQ Block tests a H//L [FC12]  block N+1, which also does not have quality

Blocks Not Propagating Quality

A common misconception is that AO/L [FC 30] and DO/L [FC 45] blocks are guaranteed to show bad quality. In fact, they only propagate the quality attribute. Thus, if the input to the block does not have the quality attribute, there will be no quality to test.

There are seven instances where a TSTQ tests an AO/L block, which is not propagating quality, and three instances where a TSTQ tests a DO/L block, which is not propagating quality.

A Sublime Example

Here is a sublime example of a class of error that occurs again and again. Good engineering is clutched from the jaws of victory! Here, TSTQ and REDAI blocks validly synthesize a picture of two versions of COMPENSATED GAS FLOW. However, the use of Transfer [FC9] Block 1835 destroys the quality chain, so bad quality will not be detected by the process. The problem would not have existed if a REDAI block had been used instead to propagate this signal.

More Flawed Quality Tests

In all the following instances, quality is checked to no end, and the actual quality information is lost.  In most cases, simply testing the input to the function block whose output is being tested would solve the problem and allow a bad quality signal to be detected and acted upon.

• 2 instances - TSTQ tests F(x) [FC1] which does not have quality
• 2 instances - TSTQ tests A [FC2], which does not have quality
• 2 instances - TSTQ tests H/L LIM [FC6], which does not have quality
• 2 instances - TSTQ tests SQRT [FC7], which does not have quality
• 20 instances - TSTQ tests T [FC9], which does not have quality
• 8 instances - TSTQ tests SUM(K) [FC15], which does not have quality
• 23 instances - TSTQ tests [NOT FC33], which does not have quality
• 3 instances - TSTQ tests S R [FC34], which does not have quality
• 33 instances - TSTQ tests OR (2-Input) [FC39], which does not have quality
• 1 instance   - TSTQ tests OR (4-Input) [FC40], which does not have quality
• 1 instance   - TSTQ tests REMSET [FC68], which does not have quality
• 4 instances - TSTQ tests M/A MFC/P [FC80], which does not have quality
• 1 instance   - TSTQ tests TRIG [FC171], which does not have quality

Conclusion

This analysis show a plant operating with hundreds of errors DBDOC has detected by flagging TSTQ block inputs that do not have quality to test. Half of them are especially worrisome because they show incorrect engineering that was never detected, i.e. it was the original intention to test a signal, not the quality of the signal, in the first place.  Was there a FAT (Factory Acceptance Test)? If so, it missed them all.

System Integrity — DBDOC Detects Bad TSTALM Blocks

DBDOC is unique in giving you significant help in finding integrity issues in your system. Every INFI 90 system in the world will benefit from improving safety, reliability and operation with DBDOC's Integrity Plus approach. Our Error Browser and Error Marker development was designed to make it possible to manage errors and improve the integrity of your systems.

 

In August 2014, we showed examples of detectable TSTALM errors from one system, but we continue to find this error being made. We have been reporting it for a decade, since 2006. DBDOC is the only valid way to identify this problem.

 

We report Function Code 69 TSTALM blocks that test the same block and mode. This usually happens when a TSTALM block is copied without S1 the specification that tells what block is being tested being made to match the new block numbers. Any of these TSTALM problems could have an adverse affect on a plant.

 

I did a review of test data for 228 systems around the world:

• 22 had no TSTALM blocks - basically small systems averaging 1219 sheets each.
• 206 systems had 3 or more - average size was 4022 sheets.
• 90 had from one to 111 multiple TSTALM messages - average 8.2 errors.

The three systems with the largest number of messages looked like this:

• 111 errors - 114 actions missed, 114 actions falsely triggered
• 100 errors - 10 actions missed, 10 actions falsely triggered, 96 duplications
• 84 errors - 84 actions missed, 84 actions falsely triggered

 

Holy Crossfire, Batman! This is from http://holysmokesbatman.com/directory.

 

The problem is that good logic gets cloned to do the same job again and again. The block numbers get changed and the changes compile cleanly. However, S1 must be changed when the logic is cloned in the same module, because the cloned value of S1 is guaranteed to be the only block in the module that is wrong. The failure to do this is not caught by Composer or WinCAD compilers, so the error does not get corrected.

 

Let's start with an example. Here is our message, as shown in Error Browser, with the good stuff circled in green:

 

 

 

Block 2614 is clearly expected to be asserted when block 2609 is put into Auto mode.

 

DBDOC shows you the block index for block 2609, which you see here with the green highlight for the intended and correct logic.

 

 

 

  

What do you make of the purple, red and blue highlighted references? Click on each of them to go to the TSTALM block that is strangely testing block 2609.

 

 

 

 

 

S1 of block 2115 (purple) obviously should be 2111, not 2609.

S1 of block 2365 (red) obviously should be 2361, not 2609.

S1 of block 2490 (blue) obviously should be 2486, not 2609.

 

Count the errors:

• Blocks 2116, 2366 and 2491 will be asserted when MSDVDR block 2609 goes into automatic mode - three errors.
• Blocks 2116, 2366 and 2491 will NOT be asserted when MSDVDR blocks 2111, 2361 and 2480 respectively go into automatic mode - three more errors

 

Six errors for the price of one! Good value from DBDOC, eh?

 

Composer should be made to set the value of S1 to -1 when a TSTALM FC 69 block is placed on a page. The illegal value should force the user to enter one that would work.

 

Note also that the warning triangles (Error Markers) are in front of you when you get to the dysfunctional logic, so you can see right away that there is possibly a problem. The two messages they show are:

 

Tested block on different page (which should be a clue), and

TSTALM block tests subsequent block, which means they are out of natural sequence.

 

I have found as many as seven such duplications (that is, 14 errors) that came from the cloning of a single set of functioning blocks. Clearly, this error can be made and missed. DBDOC can find it for you.

 

When you review these using DBDOC Error Browser, you simply hide any that are of no consequence. You flag ones like this that affect the process. When they are fixed, they will disappear from the diagnostics. If you create such an error, it will show up as a new error, highlighted in yellow.

 

DBDOC helps improve your system integrity.

Serious Function Code Generator Errors Your INFI 90 Tools Won't Warn You About (And How to Protect Your System)

DBDOC Integrity Plus system is unique in giving you significant help in finding integrity issues.  Every INFI 90 system in the world will benefit from improving safety, reliability and operation. Even a tiny glitch like an incorrectly parameterized function generator could have an adverse affect.

DBDOC reports F(x) Blocks that have non-ascending X coordinates. If successive X coordinates are in descending order, the block does not do what you think. This applies to all controller versions so far as we know, so tell us if some firmware or modern module solves the problem, of course.

My check of test data showed 132 of 136 sites had this issue. This is 97% of a range of systems from small to huge around the world. DBDOC is the only tool that will identify this problem

Here is the message, as shown in Error Browser:

This is what it looks like on the CLD.

The X coordinates are, in order, 100.0, 20.0, 0.0, -4192.0, -4192.0, -4192.0. The calculation goes (likely), like this:

• If input is less than S2, which is 100.0, output is S3, which is 5.0.
• Done!

Perhaps, it goes like this by trying to establish a line segment that works first:

• Start with S2. Read S4. S4 is less than S2, so throw S2 away
• Start with S4. Read S6. S6 is less than S4, so throw S4 away
• Start with S6. Read S8. S8 is less than S6, so throw S6 away
• Start with S8. Read S10. S10 is less than S8, so throw S8 away
• Start with S10. Read S12. S12 is less than S10, so throw S10 away
• Start with S12. Output is S13 which is 0.0.
• Done!

What it does not do is turn the numbers around, at least not in firmware we know about.

 

Actually, we have had both the results above reported to us. Here is my speculation about the calculation:

• If input is less than S2, which is 100.0, output is S3, which is 5.0. This gives the first result of 5.0 for the output.
• If input is greater than S2, then it is greater than S4, S6, S8, S10 and S12, so make the output S13 or 0.0.
• If the input drops below S2, perhaps the output stays at 0.0.

What we really need is some experimentation to tell that reports not only the specifications but also the module type and firmware revision.

 

Some examples from actual systems:

 

X coordinates out of order for F(x) Module 1,04,04 Block 1680

 

  ( S2, S3) 650.0 1.171

  ( S4, S5) 600.0 1.156

  ( S6, S7) 550.0 1.147

  ( S8, S9) 500.0 1.131

  (S10,S11) 450.0 1.124

  (S12,S13) 400.0 1.108

 

Output is either 1.171 or 1.108. Neither is correct over the working input range.

 

X coordinates out of order for F(x) Module 40,31,04 Block 9860

 

  ( S2, S3) 41.0 5.0

  ( S4, S5) 35.0 0.0

  ( S6, S7) 35.0 0.0

  ( S8, S9) 35.0 0.0

  (S10,S11) 35.0 0.0

  (S12,S13) 35.0 0.0

 

Output is 5.0 or 0.0, but is never what is intended.

Reviewing these errors with the Error Browser:

 

When you review these using DBDOC Error Browser, you can simply hide the ones that are of no consequence. You star ones like this that affect the process. When they are fixed, they will disappear from the diagnostics. If such an error is created in the configuration, it will show up as a new error, highlighted in yellow.

 

DBDOC helps make your system do what you want. This is Integrity Plus and you will be happy you have it!