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?

Text File Dumps of Configuration and Source -- A Useful New Tool

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

An offshoot of this work was that we were able to make DBDOC generate the same values as ABB compilers in the cases where we found the CFG files do not have the documented default values. Two examples are S28 of FC80 and S2 of FC 225. The documentation says each has a default value 2, but Composer and WinCAD compile a value of 0.

At the moment, you need to compare and interpret these text files manually, but look for DDBOC to do more automatically in the future.

The following example occurred this past week, and was something of a mystery to track down. DMPCFG proved its value as part of the solution.

Example 1: Mismatch Between CLD/CAD Files and the Module Load File.

A client was concerned at the failure of the blocks shown here (8120, 9498) to display live data in Hyperview.  As you can see, other blocks on the same sheet were showing live data without incident.  They speculated that the cause might have something to do with the fact that one of the blocks was an AOLDB, a new block type. 

DBDOC Analysis:

In fact, the block type issue was a red herring.  DBDOC does in fact support the newest block types added to Composer.   The fact that the values of the specifications were shown correctly was evidence for that.

The actual problem was almost certainly that the configuration in the module did not match the CLD, and the CLD is of course what is used to generated DBDOC's graphical representation of the CLD diagram.  We expected that most likely, for some reason, blocks 8120 and 9498 did not exist in the module, but that they were present in the CLD.

In order to verify this, we had a look at the DMPCFG files from the CFG (loaded into the module), and the CLD (used by DBDOC).  Surprisingly, they showed the exact opposite of what we were expecting!

CFG DMPCFG File -- 8120 and 9498 are present!

Block 8120 FC48 S1=9498 S2=16 S3=0.0 S4=50.0 S5=20.4 S6=-99.0 S7=1.0 S8=2.0 S9=2.0  

Block 9498 FC96 S1=5 S2=1254 S3=9497 S4=9.223E+018 S5=9.223E+018 S6=9.223E+018

And in the CLD DMPCFG file, 8120 and 9498 were absent. 

So then, how did 8120 and 9498 get into the CLD diagram displayed in Hyperview?  And why weren't they in the module at the time when live data was being requested and the screenshot taken?

DMPCFG File Comparison

It's clear from the contents of the DMPCFG files provided by the client, that at the point the DMPCFG files were created, the CFG did have blocks 8120 and 9498, while the CLD did not.

Left: CFG (with block 8120), Right: Source CLD (without 8120) 

Left: CFG (with block 9498), Right: Source CLD (without 9498, and with new blocks 9499 and 9501) 

What Actually Happened

This is what the sequence of events turned out to be:

1. By October, a CLD with block 8120 FC 48 and block 9498 FC 96 had been compiled into a CFG that was loaded into the module.
2. This same CLD was built by DBDOC into the October M14 file shown, where blocks 8120 and 9498 are present.
3. The CLD was changed to have blocks 8120 and 9498 removed, and blocks 9499 (a new DAANG block) and 9501 added.
4. A new M14 file was built in November, which was not being used when the problem was noticed.  However, it was this DBDOC build that generated the DMPCFG files in the comparison above, since at that moment, the CLD no longer had blocks 8120 and 9498. It had not yet been recompiled, so the CFG file remained unchanged as shown blocks 8120 and 9498.
5. Later, the CLD without blocks 8120 and 9498 was compiled, and the resulting CFG loaded into the module.
6. Finally, the October M14 was accidentally viewed in Hyperview, instead of the newest November one, leading to the CLD "NO CONN" screenshot first noted, as Hyperview attempted to fetch live data for blocks that no longer existed in the module.

Of course, one might ask, what caused the client to accidentally view the second most recent DBDOC M14 file, instead of the most recent one?

It turns out, when Hyperview opens an M14 specified with '*' (most users do this, because it's supposed to allow the most recent build to be opened automatically), it checks the File Creation date, which can be changed to the current date by copying the file.  This is what happened with the M14s in question -- they were copied, and the less recent of them received a newer File Creation timestamp, and thus was erroneously opened by Hyperview as the most recent M14.

We are changing Hyperview to instead look at the File Modified time for this purpose, and this modification will be seen in DBDOC 10.7.  Hopefully this will protect clients from this problem in the future.

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.