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.

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.

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?

Alarm Management Needs Error Management

Does your system contain alarms that cannot actually ever occur?  Many do.

Alarm management focuses on understanding and controlling the alarms that can be generated in a system.  DBDOC provides techniques for walking through the configuration systematically to validate assumptions and look for problems. Effective alarm management is impossible without error management and configuration analysis.

Here are three example sets of alarms that do not work in a single powerplant configuration:

1. Intermittent failure caused by duplicated exception report imports
2. Detected failures to test blocks with quality
3. Problems that can be found by using DBDOC to walk through the configuration easily

If you do not manage your errors and use the tools DBDOC provides to audit the configuration, you will not be able to manage alarms. Even worse, you can spend a great deal of money fooling yourself about alarms.

Example 1 - Frozen Import Block Error

INFI 90 allows block values from one module to generate "exception reports" when the block value changes status or value. In the case of an analog exception report, the new value is transmitted when it changes by an amount that is specified as "significant".

If a an exception report block value is imported more than once into a module, only one of the import blocks works. The values of any other blocks importing the exception report block value will remain frozen. Furthermore, when an on-line configuration is done, a second import block will silently begin working (!) and the block that was working will freeze at its last value. This applies to both analog and digital exception reports.

DBDOC detects and reports this error. However, when the module is compiled using Composer, the error is not detected.

      Error: Frozen import block [093]

      Duplicate off-module reference (DI/L, DI/L) to Module 1,01,05 Block 1230: 1020324 and
      1020342 [1010536]

The source value above is imported in two places in one module. This instance on a spare block page might have the active connection.

The following shows the intended logic.

There is a 50/50 chance that the correct logic is not working at any time. Simply put, tags 0D0730 "COND RETURN TANK HIGH/LOW LEVEL" and 0D0727 "AUX DEA HIGH/LOW LEVEL" might alarm, but they might not. It is a crap-shoot!

Note: It would seem reasonable to assume that AI/L block 1675, now spare, actually started life feeding S3 of block 1676. The duplicate import situation was discovered and the logic changed properly to get both values of S3 from a single AI/L block somewhere in the past. The problem was that the spare block still can be the active one.

Example 2 - Test Quality of a block that does not have quality to test

Powerplant A has 7707 TSTQ blocks. These four input blocks give a binary [1] as a result if one or more of their inputs have bad quality. Actually, 8592 blocks are being tested in all. Of these, 316 do not have quality to test at all.

Here is one example of an alarm (and shutdown) that will not work, identified by the message here.

       Error: TSTQ tests block with no quality [063]

 
       TSTQ Module 4,05,03 Block 2273 tests Module 4,05,03 Block 6170 (FC 15), which does not
       have quality [4050378]

Obviously, the simple solution to the problem of no alarm on bad quality for 1 GROSS MW TRANSDUCER A is simply to test the quality of the input at IREF P1E0388A instead of the output of the fudge factor sum block 6170.

Example 3 - Misconfiguration of a DAANG Block

DBDOC also allows you to go looking for trouble. Walking through all instances of a Function Code will allow you to look for things that were missed long ago. This example shows bad quality that will not alarm.

DAANG blocks are powerful tools when configured competently. Powerplant A has 6227 of them, the second highest number we have seen in a single plant. I was curious to see how consistently programmed they were. The table shows how a value places on Specification S8 can set bad quality.

This plant uses this extensively. This example shows how the constant 32.0 is applied to S8 with the green highlights. When the raw signal is found by the TSTQ block to be bad quality, the DAANG block will be marked bad quality as intended.

The following example shows that undetected errors exist. The red highlights show that bad quality on this raw input will result in good quality being forced. Oops!

Being interested, I started walking through the 6227 DAANG blocks looking for this particular issue.  I got bored after 200, taking 16 minutes, about 5 seconds per block. I found (and flagged with DBDOC annotations) the following reality:

• 124 blocks with correct alarm configuration - setting 32.0 into S8
• 22 blocks incorrectly setting 1.0 into S8
• 1 block incorrectly setting 0.0 into S8
• 53 of the first 200 DAANG blocks did not set the quality attribute in this way.

The bottom line is that 12% of the first 200 DAANG blocks (all tagged, by the way) would not alarm on bad quality. I have no reason to think this is not representative, which suggests that perhaps 800 of these tags will not alarm on bad quality in this one system.

By contrast, I checked a system with 7980 DAANG blocks. There were no alarm errors in the first 150 instances, with all quality inputs being generated correctly. At least in this respect, good configuration work would make alarm analysis valid.

In a second system with 5084 DAANG blocks, I found that only 2042 of them used the S8 to set bad quality if needed. In fact, this simple walkthrough with DBDOC showed that that 60% of the blocks I sampled were fed from signals that had no quality to test, but did not reinsert bad quality. That could mean about 2000 simple errors - tag does not show bad quality when it should.

Error and Configuration Management Trump Alarm Management

Alarms cannot be managed if errors prevent them from working. DBDOC can be used to improve alarms both by looking at errors and by walking through the project carefully. Otherwise, any alarm analysis will be incomplete and unacceptable.

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.

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.

 



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!