Configuration Change History Support in DBDOC 10.7

Archived Text File Dumps of Configuration and CLD / CAD Source

DBDOC now reports the specifications that make up the configuration of an INFI 90 system in text files we termed "DMPCFG".  We use these dumps to cross-check DBDOC handling of the CLD and CAD files, verifying that we handle the CLDs and CAD sheets the same as the ABB compilers Composer and WinCAD (and DOS CADEWS and SLAD).

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.  Read about them here.

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.

Changes from Date to Date

The simple application of the DMPCFG file archives is comparison and documentation of changes in blocks and specifications from any DBDOC build dates. The following examples show how any differences will be clear.

This example shows the changes made in a module in the space of three months. Having them available like this will allow them to be cross-checked against the management of change documentation. The symbol "<" indicates the old value, with ">" showing the new blocks and specs.

Comparison of May 8 to Sept 14, 2016 - Module 6,50,05

< Block 531 FC80 S1=3646 S2=5 S3=3493 S4=5 S5=0 S6=5 S7=6.0 S8=0.4 S9=1.0 ...
> Block 531 FC80 S1=3646 S2=5 S3=3493 S4=5 S5=0 S6=5 S7=6.0 S8=5.0 S9=1.0 ...

< Block 796 FC30 S1=5    S2=0  S3=0.0 S4=250.0 S5=300.0 S6=-10.0 S7=0.1
> Block 796 FC30 S1=4706 S2=17 S3=0.0 S4=6.0   S5=10.0  S6=-1.0  S7=1.0

< Block 797 FC30 S1=5    S2=0  S3=0.0 S4=11.0   S5=100.0  S6=-10.0 S7=1.0
> Block 797 FC30 S1=4708 S2=18 S3=0.0 S4=1E+006 S5=1E+006 S6=0.0   S7=1.0

< Block 3546 FC6 S1=5    S2=11.0 S3=-1.0
> Block 3546 FC6 S1=2003 S2=2.0  S3=0.0

< Block 3886 FC37 S1=1    S2=1
> Block 3886 FC37 S1=4714 S2=4719

< Block 4049 FC2 S1=961.0
> Block 4049 FC2 S1=1565

< Block 4050 FC15 S1=4048 S2=4049 S3=1.0 S4=-1.0
> Block 4050 FC15 S1=4710 S2=4056 S3=1.0 S4=-1.0

< Block 4051 FC2 S1=274.4
> Block 4051 FC2 S1=1000

< Block 4052 FC17 S1=4050 S2=4051 S3=1.0
> Block 4052 FC17 S1=4721 S2=7    S3=1.0

< Block 4053 FC2 S1=0.0
> Block 4053 FC2 S1=1.065

< Block 4055 FC9 S1=4052 S2=4120 S3=4054 S4=0.0 S5=0.0
> Block 4055 FC9 S1=5    S2=5    S3=0    S4=0.0 S5=0.0

< Block 4056 FC16 S1=2003 S2=4055 S3=2.0
> Block 4056 FC16 S1=4722 S2=4049 S3=1.0

< Block 4062 FC80 S1=4057 S2=4056 S3=4058 S4=4060 S5=4059 S6=5 ...
> Block 4062 FC80 S1=4057 S2=4713 S3=4058 S4=4060 S5=4059 S6=5 ...

< Block 4075 FC80 S1=4069 S2=5    S3=4070 ... S28=3061 S29=0    S30=0 S31=60.0
> Block 4075 FC80 S1=4069 S2=4053 S3=4070 ... S28=3061 S29=4716 S30=0 S31=60.0

< Block 4120 FC68 S1=0 S2=1.26 S3=0.74 S4=0.84 S5=0 S6=5
> Block 4120 FC68 S1=0 S2=21.5 S3=12.5 S4=12.5 S5=0 S6=5

< Block 4581 FC16 S1=4580 S2=6 S3=1.0
> Block 4581 FC16 S1=4580 S2=6 S3=0.05

< Block 4582 FC6 S1=4581 S2=200.0 S3=-5.0
> Block 4582 FC6 S1=4581 S2=10.2  S3=4.2

New blocks added:

> Block 4706 FC7 S1=4707 S2=0.115
> Block 4707 FC6 S1=1063 S2=2800 S3=0.0
> Block 4708 FC166 S1=796 S2=2 S3=5 S4=1 S5=9.223E+018 S6=-9.223E+018 S7=1.0 S8=1
> Block 4710 FC17 S1=4056 S2=4052 S3=0.5
> Block 4711 FC17 S1=4050 S2=4051 S3=1.0
> Block 4712 FC15 S1=5 S2=5 S3=1.0 S4=-1.0
> Block 4713 FC30 S1=4711 S2=117 S3=0.0 S4=5.0 S5=9999 S6=-9999 S7=0.5
> Block 4714 FC12 S1=4076 S2=1.07 S3=-9999
> Block 4716 FC35 S1=3886 S2=0 S3=2.0
> Block 4717 FC2 S1=21.5
> Block 4718 FC2 S1=12.5
> Block 4719 FC62 S1=0 S2=1 S3=0 S4=0 S5=0 S6=4719 S7=0 S8=2
> Block 4720 FC9 S1=4717 S2=4718 S3=4719 S4=0.0 S5=0.0
> Block 4721 FC30 S1=4720 S2=43 S3=10.0 S4=25.0 S5=-9999 S6=9999 S7=0.5
> Block 4722 FC3 S1=3546 S2=1 S3=0.0 S4=2.0

What Next?

This is a respectable first step, but of course these are text files, generated during a DBDOC build, and not nearly as accessible as they could be.  We would like to see support for interactive viewing and browsing of Management of Change information from right inside the Hyperview browser.

Andrew McKeown of Oji Fibre Solutions in New Zealand suggested:

• My biggest need is around Management of Change. Knowing what has changed between each snap-shot build is an important part of managing and reconciling or even tracing changes between successive builds or across a period of time.  My contention was always that if you have the information about what is there then we should do something about seeing what has changed in detail.
• My contention now is that you could build this into the M14 by changing the file contents so that the differences could be seen in the MoC list [showing] the change and also the hyperlink to the CAD sheet and Block.

As far as comparing from version to version arbitrarily, Andrew also sets the bar very high:

• The trick then becomes what do you choose as the previous version to compare to [with] CFG and EWS CFG as sources plus the previous versions of the same.
• Archiving files for comparisons to previous versions for an ad-hoc datetime difference is all well and good but you need to make this interface easy for the user.

We concur, and are starting on this and more now. The ideas of our clients will help us.  There was a time when the errors DBDOC found during builds were available only via build-level log files, but now the Hyperview Error Browser makes this information highly accessible, and links it effortlessly into graphics and configuration.  There isn't any reason why Management of Change information, changed specs and so on, couldn't be presented in Hyperview in an analogous fashion.

Would this be useful to you?

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.

 



Are Dated Design Compromises Affecting Your HMI and History Data Precision?

I got busy in the purported Christmas break and wrote a bunch of blogs.  This blog is a roadmap through several related areas. Read on to

• learn if you are overloading the exception report generation of nodes
• verify under-utilization and improve your console and history data
• automatically detect and report exception report delays

Most systems worry about the above, and most were configured a decade or two ago. Learn if you can get much more out of what you have.

For many INFI 90 systems, the power of the modern NIS21/NPM22 hardware capability will allow you to get much more precise data to consoles and history systems.

If you have DBDOC, you can find out, for every PCU / node that you think is heavily loaded, if it really is. Heavy loading is 50% to 90%, overloading above that.  This is how to do it:

Monitoring Node Communication CPU Load

If you find the communication CPU usage in the 10% range, you are not getting enough out of INFI 90 and are not giving operators, managers and engineers data that is good enough.  You can do better:

Improved Tag and History Data Precision in INFI 90 Systems

There is also a design for you to be able to permanently and validly measure whether you ever get delayed or lost exception reports.  If you find you have nodes in the 50% or greater node communication CPU usage, you should worry about this.

Monitoring Exception Report Performance

Have you tried any of these techniques?  It would be very interesting to hear your experiences.

DBDOC and Spare Blocks

Sometimes, you have to find a spare block and the spare blocks / boneyard sheets have not been maintained.   DBDOC can make this task systematic and as easy as possible. We plan to add a feature one day to directly identify unused blocks, which will be even nicer.  Keep those cards and letters coming, folks!

Start with the Table of Contents - Miscellaneous Indices chapter.  Click on Function Codes.  In the Index to all Function Codes, click on the Function Code 30 entry to get to the list of all FC 30 blocks in your system.

You are now at a list of all the FC 30 blocks in the system.  Scroll down the list until you get to the module you want, in this case, Loop 11, PCU 10, Module 2 (Module 11,10,02 in DBDOC terms) and click on the highlighted entry to call up that block.  You will see the block in the CLD or CAD sheet, usually with a line showing it is (probably) used.  If you turn on "attributes" with the "A" key, you will see if the block has a tag. You should, at least for a start, assume that it is used if it has a tag or if it has an output reference.

The example shows that the first block is tagged "1-TI-2241" and that it has a line carrying its value someplace to boot.  Probably used, eh?

Now you simply walk through the FC 30 blocks with the "L" key ("shift L" to go up).  The same functionality is given by  andin the icons.

When you get to one that has no line and no tag, you have found a candidate spare block.

Clicking on the block number (1501) brings up the index of all the places in the world where this block is purported to be used, hopefully only its source right here.  This one certainly seems to be unused.

It makes sense to be satisfied that you have a good enough DBDOC build that you can count on the fact the block is not used.  For example, it is possible that it is imported by some other project, and you did not build all the projects together in your DBDOC build.  If that could be the case, you should do further analysis.

However, no other tools can get you this far this fast.  We are always ready to help you be sure you have a good DBDOC build that resolves everything.  You have a candidate spare block and it really did not take very long.

What do you do if you walk right through Module 11,10,02 without finding a spare?  You can go back through the blocks and click on the output block number, looking for blocks that are not used in any graphics.  Although these might be in your history system, you can go after that usage and perhaps find that the block can be re-purposed with no problem.

When you are walking through the blocks checking for how they are used, the key sequence is easy enough to do semi-automatically:

• click on output block number
• back-space to get back to the function code index
• type "L" (or "l") to get to the next linked block and repeat

There are, of course, other ways to do this.  It is very nice when all spare blocks get put into boneyard pages.  However, that is not always the case.  When you have to find one and see how it is used or not, this DBDOC technique will certainly help you.

Function Code Quantity

A client wrote:
     "Can DBDOC tell me how many Function Code 156s we have in our project?"

The answer is:
     For sure!  Let us count the ways. 

1.  In DBDOC Hyperview, under Miscellaneous Indices, click Function Codes and then Function Code 156. This will give you a list of all of the blocks in your system that are function code 156. The blocks are numbered, so you can just scroll to the end of the list for a count.

2.  FC156.dbf in the Exports subfolder has all the FC156 blocks and all the specs, even the compiled input block numbers (and FCnnn.dbf has the same thing for the FC nnn blocks).

3.  File FCLIST.TXT in the build folder lists all the function codes used in the project and how many of each that there are.

4.  The MHD Module Info section of a module will tell you how many are in that module.  This can make module CPU loading possible to estimate.

5.  MASTER.DB is an SQLite database that has all the Function Code information and a lot more. SQLite tools will allow you to open the file, examine the records and do queries.

The bottom line is that DBDOC has a great deal of capability built in that most of our users never find, so they do not tap the resource they have available.  We have tried to do things that are not possible easily with existing tools, if they are possible at all.

Happily, one more site is now turned on to the capability.  

Over the last half year, I have presented Advanced DBDOC workshops and Hyperview training sessions totalling 23 days at 13 sites.  Without exception, the DCS teams found a mess of useful things in DBDOC that they had not guessed were provided.