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.
No comments:
Post a Comment