Built-In PDF Files and More! PDF File Support in DBDOC 10.7

You all have PDF files, integral to the support of many systems. DBDOC now supports them in an unprecedented way.

DBDOC has supported viewing PDF files with a PDF viewer for many years. This has been very useful. However, this support lacked the full suite of features that are integral to DBDOC. The new support adds these critical features:

• You can search for text in all the PDF documents you build in at once. Conventional searching is limited to the document you have open.
• You can have links from the PDF file to tags in your DCS configuration. This means you can simply double-click on the tag name link and go to its source on a CLD or CAD sheet.
• You can also have links from the PDF file to other documents. Since DBDOC supports AutoCAD, Microstation, PDF files as well as your DCS configuration and graphics files, this can give you powerful inter-connections in your documention.

Let's look at the three ways that PDF files are now supported in DBDOC.

1. The new support to compile them into the M14
2. The existing support to link external files to be viewed by a PDF viewer
3. The existing support to the Function Code PDF file documentation from ABB

1. Compiling PDF files into the M14

You can now view and browse pdf files directly in Hyperview.  For most people, this support will simply replace the linking they used to do. DBDOC will be even more useful than it was. Searching, tag  and document links will be automatic. You will find it natural and satisfying.

2. Linking external PDF files to be viewed by a PDF viewer

So why would you link PDF files? One client has a very solid application involving maintenance orders. By linking fixed file names to the most recent version of the document, people get to the current version. When it is updated, the new version is linked, because the name has not changed.

This feature remains supported, so you can have very good access to the information in PDF files by compiling them, while supporting access to system-wide documents by name.

3. Supporting the Function Code PDF file documentation from ABB

DBDOC implements support for calling up the ABB Function Code PDF file information by a "right-click" on the function block image. The feature works for individual files, plus for one-volume and two-volume document sets.

Where do we go from here?

We are at the starting point in our development of this support. Your feedback about things we ought to think about will be very useful. The support is important to DCS systems supported by DBDOC.

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 Support Query: Importing the Wrong Value from an M/A Station Block

Dear Support:

I was wondering if you could explain this error to me.

Dear Client:

For sure.

One place block 3088 is used is as a block imported by an AI/L.

The exception report from an AO/L block looks like this:

• one byte - status bits, including H, L, Q
• one real - value of the AO/L

The exception report from a STATION block looks like this:

• one byte - status bits, including H, L, Q, Deviation
• three real values in this order
•     value of the PV (S1)
•     value of the SP (output N+1)
•     value of the CO (output N)

The AI/L block reads and supports the first two values - one byte, from which it gets the quality, and one real, which it imports as the value.

The message tells you that the value of the AI/L block imported equals that of the PV of the station block, something like 239 (S1), not the CO value of 46% (Block 3088), which is probably what is expected.

Please send the same screen shot, but also the AI/L block.




Dear Support:

The AI/L block

Dear Client:

As you see, the description PLANT AIR FLOW CONTROL OUTPUT just does not cut it. In fact, 46% would not be not high enough to trigger the 50% level in the subsequent H//L block, but the erroneously imported PV of 239 is.

You could insert an AO/L after the station block, to transmit the actual output value to the AI/L block.

However, a simpler way might be to put an H//L block on the page where the Station block 3088 exists and send the output of the H value to a DO/L, then import that DO/L here.

Does this now make sense?

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?

Output Spikes - Sharp as Tacks!

This does not look good!

Here is a warning about derivative gain from a site, highlighted in the Error Browser.

PID Module 1,06,02 Block 214 uses derivative with PV from discontinuous input Module 1,06,02 Block 140

You can see the error marker next to the PID block it concerns.

Dan Reynolds sent me the data from the control loop identified. Here is what it looks like with DBDOC WatchWindow at 250 ms.

Zooming in a bit, we see that Block 280, the output, suffers spikes from its railed value of -5.0%. Block 214 shows a value of +1.7408%, that is, 6.7408 above the -5.0% it should be. The exception reported input Block 140 changes each minute and drives these spikes (not all of which are picked up in the 250ms reporting interval, since they are so brief). You can be sure that, if the control output were in the 0 % to 100% range, large positive and negative spikes would be suffered every minute. Ouch!

Just as clearly, if this PID output were not driven to -5 %, the spikes would be bi-directional and still significant. The effect is purely caused by the value of Kd on S8 for Block 214, only 0.2, but enough to drive the output in a way that is not valid.

By the way, you should notice how any exception report input has steps in its value. The values for Module 1,06,02 Block 140 and Module 1,03,04 Block 1901 show these characteristic steps. See Monitoring Exception Report Performance for details.

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.