Analysis: DBDOC Detects Four Years of Introduced Errors

This is a summary analysis of the important errors introduced into a system over four years. DBDOC makes this sort of analysis trivial if you have backups of systems before and after work is done. Here are questions you should ask.

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?

Error Browser Presentation

The builds of 2010 and 2014 versions of the Composer project show 49 significant errors that were left in the system after the work was commissioned. DBDOC shows "new" errors highlighted and allows you to focus on them. Old ones are important, too, but good work should not introduce new ones. After all, Composer is two decades old now and ought to be counted on to protect the users.

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 inexplicable unintended excursions that are supposed to be smoothed out. Clearly, the default should be to be enabled, not disabled.

Looking at two of these messages (for Blocks 3678 and 3679), it is absolutely clear that the plant is not protected by rate limiter blocks (FC8) that were inserted to limit the rate of change. The red warning triangle shows the one we clicked on above. The yellow triangle (called an error marker) would also be visible, and you would see when you got to the logic in your analysis or troubleshooting.

TSTQ Tests Block With No Quality

The work being analyzed has thirty-seven errors where a block is being tested for quality when it does not have quality to test. None of that logic does what it is intended to do.

First, the simple error is clear. Testing quality on an output if a FC 80 M/A MFC/P block simply makes no sense. It does not work. The green arrow shows the erroneous test being carries out.

However, as is often the case, finding bad work makes you look at the intent of the logic. What was intended here?

It appears that either U1 ID FAN SUC PRESS BQ or ID MASTER IN AUTO is supposed to replace ID MASTER DEMAND with 100.0. That will not happen!

Summary

There are forty-nine potentially significant errors documented here, with many more less severe not documented. They should not have been made, and they should have been caught.

50% of Systems Have Certain Function Blocks Unintentionally Disabled. Is Yours One of Them?

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 our most recent versions, we have added tests for three function blocks that are disabled by default.

• FC 3 - Lead / Lag - S2 defaults to 0 disabling the function
• FC 8 - Rate Limiter - S2 defaults to 0 disabling the function
• FC 166 - Integrator - S4 defaults to 0 disabling the function

For a function block to be disabled by default is horrific. Only three of the 200 types or so are (the rest are enabled by default). The hapless users put function blocks in place, but they do nothing that they were intended to do, because they are disabled. Now and forever, they are booby-trapped.

What do you think? Can there be any justification for most function blocks being enabled by default, with only these three exceptions?

Am I wrong? Are there other booby-traps we have missed? Please let us know.

In my review of test data for 228 systems around the world, I found

• Lead / Lag - 605 disabled in 83 systems
• Rate Limiter - 392 disabled in 86 systems
• Integrator - 50 disabled in 26 systems

In actuality, 75 systems had one of these; 42 systems had two and 8 hit the TriFecta! In total 125 of the 228 systems had one to three of these errors - 55% of them.

What about the "real world" - places where DBDOC checking has not been used yet? Here is what this test detected in a small power plant being worked on now by extremely competent people:

• Module 1,02,02 Block 8507 FC8 disabled by spec values
• Module 1,02,02 Block 9541 FC8 disabled by spec values
• Module 1,02,02 Block 10295 FC8 disabled by spec values
• Module 1,02,02 Block 11049 FC8 disabled by spec values
• Module 1,02,02 Block 11803 FC8 disabled by spec values

 

Holy Rate Unlimiter, Batman! http://holysmokesbatman.com/directory contains 350 actual sayings, perhaps the best being "Holy Time Bomb".

 

The 5 errors out of 152 Rate Limiter blocks show that only DBDOC can protect you from these problems.

 

Here are examples of each from real systems.

 

The objective of this FC 3 Lead/Lag block is to apply a time constant of 60 seconds to changes in the PV as applied to the APID control algorithm. This is not happening here because, unbeknownst to (or unnoticed by) the DCS specialist, the block is disabled and feeds the input directly to the output.

 

The first Rate Limiter example looked like it was booby-trapped in the sense that sometime in the future an unsuspecting body would put meaningful values on the limits and expect them to work. As you can see here, the negative going rate limit of 0.00333 per second presumably is intended to prevent larger drops in the value from affecting the process. However, the block does not function.

 

 

 

In the case of the integrator, it is S4 that is the trap. Clearly, nobody puts an integrator and tag into a system not intending to get data. This one will not get data because S4 is not wired to a constant value 1.

 

Only DBDOC can improve your system integrity by detecting these relatively common oversights.