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!

Summary

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.

DBDOC 10.7 -- Download Your DBDOC Update Today!

We are delighted to announce the release of DBDOC 10.7, with a variety of upgrades, bug fixes, and new features.  A few of the major improvements are noted below.  For more information, please see What's New and the Release Notes.

Built-In PDF Files

If your system contains PDF file documentation, you will be happy to learn that PDFs are now first-class citizens in DBDOC, built directly into the M14 like other document types.  They can be viewed right inside of Hyperview, links to blocks and tag references are made automatically, and they can be searched like other documents.

Links to external PDF documentation are still supported, too.

See Built-In PDF Files and More! PDF File Support in DBDOC 10.7 for more information.

Configuration Change History Support

DBDOC 10.6.1 introduced the creation of DMPCFG files for both the .CFG files and the CLD and CAD sheets automatically when you do a DBDOC build.   DBDOC 10.7 introduces automatic archiving of the files from both the CLD / CAD sheets and the compiled or saved CFG files. When you do your DBDOC build, your DMPCFG files will now be archived with the error files. Also, the last build you did before installing 10.7 will be archived. Thus, you will start with a base for comparison of the last build you did with DBDOC 10.6.1 and the first with DBDOC 10.7.

See Configuration Change History Support in DBDOC 10.7 for more information.

Improved S+ and 800xA PG2 Graphics and MicroStation Drawings.

Display of S+ graphics has been significantly improved. Symphony Plus graphics rendering has been greatly improved. Splines, background colors, lines, etc. which previously were not drawn, now appear, and previously handled elements are now drawn more accurately.  The user can now also specify the path to their Symphony Plus image files in Wizard so that Hyperlink can find and use the correct image specified in a graphic. S+ and 800xA live data display sizing has also been improved. MicroStation drawings have improved text display, rendering and remove duplicate search hits.

Improved Error Detection

Processing has been extended to check more blocks for continuous exception reports.  The use of PID and APID blocks with derivative gain combined with inputs from discontinuous input blocks is reported.

See examples of these errors and the problems they cause here.

"Lost Project" Recovery

DBDOC 10.7 can recover "lost" projects. A feature to recover "lost" projects has been added to BuildPlus, allowing project recovery if are inadvertently "lost" due to a change in UAC level on a machine or a user's privilege level.

There's more...

For more information, please see What's New and the Release Notes, or follow this blog, where we will be illustrating new features and DBDOC capabilities regularly.

Click here to get your DBDOC 10.7 Update now!

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.

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: Reads the Manual and Checks Your Specs.

DBDOC is unique in giving you significant help in finding integrity issues in your system. Every INFI 90 system in the world would benefit from improving operational safety and reliability. Our Error Browser and Error Marker development was designed to make it possible to manage errors and improve the integrity of your systems.

Here you see our much loved copy of the function code manual, dog-eared and duct-taped. You've probably read it too, but possibly not as intensely as we have.

Based on studying the documentation and the experiences of our clients, we added new tests for function block specifications that violate the documentation in ways that seem significant. Read on to see what we found.

We reviewed test data for 229 systems around the world, and found 1160 new errors of note in 77 systems involving 33 function codes - 15 errors per system. Of course, this means that 68% of the systems had none of the specification errors we looked for. It also means that over 1/3 of the systems had these new errors Composer did not find, but that DBDOC will.

I expect this will be the most boring blog I ever write. Holy Understatements, Batman!

Here are example of errors found in various specification values for various function codes from real systems. Some could bite!  All are now reported by DBDOC in the Error Browser.

FC35 - 45 instances in 21 systems

• Module 5,65,02 Block 133 FC35 S2 value 005 is out of the valid range [000,102]

FC36 - 15 instances in 4 systems

• Module 5,26,05 Block 6441 FC36 S9 value 9 is out of the valid range [0,8]
• Module 7,101,06 Block 5800 FC36 S10 value -1 is out of the valid range [0,1]

FC45 - 22 instances in 6 systems

• Module 2,48,02 Block 854 FC45 S2 value 20 is out of the valid range [0,2]

FC50 - 1 instance in 1 system

• Module 3,01,04 Block 4082 FC50 S1 value -1 is out of the valid range [0,1]

FC69 - 9 instances in 4 systems

• Module 32,04,05 Block 3285 FC69 S2 value 5 is out of the valid range [0,2]

FC80 - 61 instances in 26 systems

• Module 2,78,02 Block 2151 FC80 S6 value 39 is out of the valid range [1-3 or 5-8]
• Module 2,15,05 Block 2039 FC80 S17 value 246 is out of the valid range [0,7]
• Module 1,11,02 Block 2494 FC80 S23 value 5 is out of the valid range [0,4]

FC82 - 4 instances in 3 systems

• Module 3,02,20 Block 1992 FC82 S5 value 30 is out of the valid range [0,2]
• Module 2,12,06 Block 15 FC82 S15 value 179 is out of the valid range [0,1]

FC83 - 501 instances in 4 systems

• Module 11,30,15 Block 463 FC83 S1 value 65 is out of the valid range [0,63]

FC84 - 5 instances in 4 systems

• Module 2,20,02 Block 6641 FC84 S2 value 10 is out of the valid range [0,1]
• Module 2,20,02 Block 6641 FC84 S2 value 10 is out of the valid range [0,1]

FC86 - 1 instance in 1 system

• Module 2,104,10 Block 1882 FC86 S6 value 013 is out of the valid range [000,101]

FC95 - 36 instances in 5 systems

• Module 1,62,03 Block 979 FC95 S7 value 2 is out of the valid range [0,1]
• Module 1,53,02 Block 9062 FC95 S12 value 7 is out of the valid range [0,1]

FC110, FC111, FC112 - 24 instances in 10 systems

• Module 5,12,04 Block 4015 FC110 S1 value 20 is out of the valid range [0,3]
• Module 5,23,02 Block 56 FC111 S1 value 10 is out of the valid range [0,3]
• Module 7,09,03 Block 4140 FC112 S1 value 10 is out of the valid range [0,3]

FC123 - 12 instances in 1 system

• Module 4,07,06 Block 3793 FC123 S7 value 22 is out of the valid range [0,11]
• Module 4,07,06 Block 3793 FC123 S8 value 22 is out of the valid range [0,11]

FC124 - 6 instances in 2 systems

• Module 5,33,03 Block 3194 FC124 S11 value 120 is out of the valid range [00,22]
• Module 5,33,03 Block 3194 FC124 S13 value 60 is out of the valid range [00,22]

FC126 - 3 instances in 1 system

• Module 1,14,11 Block 8501 FC126 S2 value 115 is out of the valid range [0,2]

FC129 - 92 instances in 33 systems

• Module 1,15,02 Block 3405 FC129 S7 value 003 is out of the valid range [000,111]
• Module 1,15,06 Block 3133 FC129 S8 value 1000 is out of the valid range [000,111]
• Module 1,20,05 Block 7810 FC129 S9 value 002 is out of the valid range [000,111]
• Module 1,23,03 Block 3995 FC129 S10 value 1000 is out of the valid range [000,111]
• Module 5,15,04 Block 2559 FC129 S11 value 20002 is out of the valid range [0000,2222]
• Module 1,44,04 Block 2509 FC129 S13 value 0003 is out of the valid range [0000,2222]
• Module 1,24,03 Block 1808 FC129 S14 value 222 is out of the valid range [000,142]
• Module 1,04,03 Block 3993 FC129 S15 value 23 is out of the valid range [0,1]
• Module 3,54,04 Block 7764 FC129 S19 value 5 is out of the valid range [Any or All of 0,1,2,3]

FC132 - 64 instances in 14 systems

• Module 1,01,15 Block 1346 FC132 S3 value 2 is out of the valid range [0,1]
• Module 1,60,02 Block 448 FC132 S3 value 4 is out of the valid range [0,1]
• Module 11,26,04 Block 1106 FC132 S3 value 7 is out of the valid range [0,1]
• Module 34,46,03 Block 8150 FC132 S10 value 78 is out of the valid range [0,5]
• Module 1,03,04 Block 1211 FC132 S13 value 50 is out of the valid range [0,5]
• Module 2,01,02 Block 244 FC132 S16 value 150 is out of the valid range [0,5]

FC136 - 28 instances in 3 systems

• Module 1,07,03 Block 1258 FC136 S16 value 3.0 is out of the valid range [0.0, 1.0, 2.0]

FC140 - 34 instances in 4 systems

• Module 10,02,07 Block 1076 FC140 S4 value 8078 is out of the valid range [00,11]
• Module 7,103,02 Block 3250 FC140 S5 value 212 is out of the valid range [0,63]

FC143 - 1 instance in 1 system

• Module 1,20,09 Block 8872 FC143 S1 value 3 is out of the valid range [0,2]

FC149 - 60 instances in 10 systems

• Module 5,41,02 Block 232 FC149 S3 value 8 is out of the valid range [0,1]
• Module 11,01,04 Block 161 FC149 S11 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S12 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S13 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S14 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S15 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S16 value 5 is out of the valid range [0,2]
• Module 11,01,04 Block 161 FC149 S17 value 5 is out of the valid range [0,2]

FC151 - 6 instances in 3 systems

• Module 1,65,05 Block 4531 FC151 S6 value 4532.0 is out of the valid range [0.0,127.0]
• Module 2,30,03 Block 7180 FC151 S7 value 3 is out of the valid range [0,1]

FC156 - 5 instances in 4 systems
Module 1,18,03 Block 6438 FC156 S19 value 32 is out of the valid range [0,1]

• Module 3,03,02 Block 7284 FC156 S20 value 40 is out of the valid range [0,1]
• FC166 - 8 instances in 3 systems

Module 4,05,07 Block 3697 FC166 S2 value 120 is out of the valid range [0,2]

• Module 3,01,04 Block 3807 FC166 S8 value 32767 is out of the valid range [0,1]
• FC182 - 19 instances in 1 system
• Module 1,07,14 Block 56 FC182 S1 value 000 is out of the valid range [001-009, 020-124, 040-041, 064]

FC190 - 6 instances in 3 systems

• Module 2,32,07 Block 2280 FC190 S2 value 7200 is out of the valid range [1,6553]

FC216 - 61 instances in 10 systems

• Module 1,09,07 Block 8172 FC216 S3 value 19 is out of the valid range [1,16]
• Module 20,38,07 Block 650 FC216 S4 value 051 is out of the valid range [000-109, 010-113, 020-125, 040-144, 060-161, 099-199]
• Module 1,03,04 Block 1428 FC216 S5 value 2 is out of the valid range [0,1]
• Module 6,60,08 Block 162 FC216 S11 value 0 is out of the valid range [16,24]

FC222 - 1 instance in 1 system

• Module 1,09,02 Block 1023 FC222 S2 value 1022 is out of the valid range [0000-1209, 0010-1115, 0210-1214, 0300-1302, 0400-1400, 0500-1500, 0900-1900]

FC224 - 18 instances in 4 systems

• Module 1,09,02 Block 1048 FC224 S2 value 1047 is out of the valid range [0,2]
• Module 1,09,02 Block 1048 FC224 S3 value 1046 is out of the valid range [0,255]

FC226 - 8 instances in 2 systems

• Module 20,10,31 Block 8358 FC226 S3 value 10 is out of the valid range [0,4]

FC247 - 4 instances in 2 systems

• Module 1,13,04 Block 953 FC247 S5 value 5 is out of the valid range [1-4 or 6-8]

Holy Complications, Batman! A number of expressions in http://holysmokesbatman.com/directory apply. DBDOC helps improve your system's integrity.

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.

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.

DBDOC 10.6.1— Ready for Download

DBDOC 10.6.1 is now available. Download it here.  There are major improvements to usability in a couple of areas, new features, new error checking and a variety of minor fixes and additional conveniences for users.

Read on for a quick overview of some of the highlights of DBDOC 10.6.1, or see the complete release notes here.

Watch Window Performance & Usability

As we gain experience with Watch Window use patterns, we are honing this tool to better meet the needs of the most prolific users.  There are some important improvements in this release that greatly improve Watch Window performance and responsiveness in highly loaded situations with groups containing large numbers of blocks.  In addition, the ability to hide and restore entire Watch Window groups has been added.  This allows you to define and configure a group, and set it aside so that it doesn't clutter up the interface when it's not needed.  It can be restored (with all of its setup) at any time.  Last, but not least, there is now a command line switch for specifying default date format in the Watch Window, so that if you are DDMM, you don't have to look at MMDD.

 

 

HTML Support (Available in the International Version)

We have been moving the Hyperview browser toward full Unicode support in all documents for some time now.  Unicode characters are supported on graphics and most Hyperview tools. The last step in the journey is the complete implementation of HTML-based Hyperview text display.  This support is substantially enhanced in DBDOC 10.6.1: documents are more faster, scroll better, behave better, and there have been numerous small improvements. HTML support will continue to be expanded in upcoming releases.

New Feature: Detect Module Load Changes

A major new feature involves the creation of .dmpcfg files, text dumps of CFG files from the project and the same information from the DBDOC compile. They allow comparison of current and historical module load images. If you archive the files, you will be able to analyze specification and logic changes over whatever time intervals you choose. This feature applies both the the CLD / CAD logic and the compiled CFG files.

New Errors Detected

Some new error types are now detected by DBDOC, and viewable in the Error Browser.  Errors are reported for non-functioning lead/lag, rate limiter and integrator blocks. Duplicate local OREFs are also now flagged, as they can cause a problem for Composer and WinCAD. Segment control blocks are checked for violations. The most important checking involves reports on numerous violations of the limits on specifications. Fully two-thirds of sites we checked had such errors.

And More...

• Numerous improvements have been made in handling S+ and 800xA graphics, including support for the Welcome_dall graphic and for the SetFont function.
• Support for AutoCAD 2016 is now included.
• Support for the 2015 single­ volume function code manual and other two volume versions has been added.
• Top level symbol locations are now shown in the Audit Window for Conductor NT and PPB.

See the 10.6.1 Release Notes for information on the many upgrades and improvements in DBDOC 10.6.1

Download DBDOC 10.6.1

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!