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.