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!

How to Add a Whole Function Block to the Watch Window in One Simple Step.

Using Watch Window has just been made much easier in DBDOC 10.6. Right-click on a function block and you will see all sorts of new things:

 

 

Pretty easy, eh?

 

For a control problem, you start with the M/A Station and go from there.

 

 

Double-click on the source (hyperlinked on S1), to get to the source of the PV after you have created the group (ACI Inj Station).

 

Right-click on that M/A Station to add PV, SP and CO to it. Of course, you will want to delete the CO of this block as the PV is already there.

 

What is implemented is our best guess of what you will want:

• output
• wired inputs
• analog values only for analog functionality like M/A Station and Analog Transfers

and course you can add additional blocks one by one if you need them.

 

Try it. You will like it!

How To Provide Remote DCS Support Without Compromising System Security

Critical DCS Support Aspects

There are times in the life of a DCS system that timely access to operating data is critical for maintenance of reliable operation. Sites have only a few DCS specialists, whose time is severely limited. Even the most critical systems do not have 24/7 resident specialists available.

INFI 90 Has Read-Only Access (via DBDOC)

INFI 90 systems are fortunate, because remote read-only access to live DCS data is possible by way of DBDOC. The DCS specialists can examine a plant situation in the most timely manner possible. They can respond faster, diagnose problems from anywhere and guide people at the plant through fault-finding and problem resolution immediately rather than adversely affecting the plant (and the public) with the delay time needed for them to get to the plant.

Read-only access protected by a VPN (Virtual Private Network) allows immediate plant support, increasing the reliability of the plant output, as well as its profitability and safety. Reliablility, profitability and safety gains - things worth working for.

How Safe is the Plant VPN?

Competent IT techniques protect access to salary, accounts payable, and accounts receivable data. All manner of plant technical and operating data is just as well protected. VPN technology is critical to the operation of companies.

What if somebody can see the data? DBDOC's read-only access guarantees that no changes can be made to the DCS.

Decrees About Access From Outside

Decrees have been made in some operations that there shall be no access to the plant data from outside the process network. On-site action is required to resolve problems, even if it takes the support personnel too long to get there to do the job. Valid performance requires far more people than are available or can reasonably be trained to the level needed.

 Should Prohibiting External Access be Reviewed?

It will take disasters caused by ill-considered decrees limiting access for support purposes to force the re-examination of such policies. More likely, fingers will be pointed at various people, none of them culpable.

DBDOC has created the ability to do immediate and effective read-only trouble-shooting remotely for INFI 90 systems. The people using DBDOC read-only access know that it helps them make their plants safer and more reliable.

Chinese Language and PGP Support - New in DBDOC 10.6

DBDOC's first pass at Chinese language support was implemented in 2007, but we did not include Chinese language support for Composer, nor for PGP graphics.  In DBDOC 10.6, Chinese language support for Composer and PGP is now implemented.

Composer Sheets

PGP Graphics Descriptions

PGP Graphics


Audit Window showing where a tag is used



Text Select on graphics works on Chinese text, too!


So why not search for the text in the project?





What does it mean?



This was the easiest blog that I have ever written! Enjoy. (But our people did a massive amount of work to make it work this well.)

How Safe Is Your System From These 56 Dangers (That Your Infi 90 Tools May Never Warn You About)?

Why 56?  That is the current number of types of serious configuration errors that DBDOC routinely detects and reports.  An example of one of these issues is explained in detail later in this article.  Your system almost certainly harbors a few of these significant errors.

Read on for a review of DBDOC's ever expanding integrity management capabilities.

Since the beginning, DBDOC has been helping users find and fix system configuration issues. However, understanding and navigating the somewhat arcane log files involved was always something of an ordeal for most DBDOC users. The more intrepid among you might recognize this sort of log content, and breathe a sigh of relief that there is now an easier way. And if you've never worried about these issues before, you will see that it's now far easier than it used to be.

Dealing with errors DBDOC found (the "old" way):

Viewing issues these days, inside the interactive Error Browser:

It has taken us a dozen years, but we have finally created a system to manage these "issues". We called it Error Browser, but you can think of it as Integrity Browser, because some people take exception to using bad words. We could run a poll or survey on a new name, but the spectrum of perspectives ranges from clear to rose-tinted:

• some people that say DBDOC found an issue, and they fixed it and saved a lot of grief,
• some people that say DBDOC found an issue, but they did not fix it, and it hurt them,
• some people that say they do not have any issues,
• some people that say if their INFI 90 tools say there is no problem, there is no problem.

We run into all the above and more.

The Error Browser makes it extremely easy to view and manage errors.

Anyhow, the Error Browser was invented to give you the ability to view issues very easily, access integrated documentation to explain them, study them and mark them as "starred," "reviewed," or "hidden" (and combinations).

You can the share the work of reviewing errors among a group of users.

The next enhancement was to allow sharing of the "starred" and "reviewed" status among members of your DCS team. This also happened to solve the problem of working on more than one computer as yourself, or working on the data on your laptop. It synchronizes nicely if you connect and have new error data information.

However, I have been told that people do not have time to study the "issues" we raise, even once. So now we have made it even easier:

New in 10.6: Error Markers right on documents alert you to the presence of errors.

DBDOC Version 10.6 has "Error Markers" that show, as well as we have managed so far, where
issues exist. This means that, when you get to a configuration CLD or CAD sheet with issues, you will see the error markers.  Simply mousing over an error marker will immediately tell you something about the problem it is flagging.

A fabulous client asked: "I want to know if it is possible to turn on and off the error markers. Some areas may get quite cluttered if there are multiple error markers for a block."

Yes, indeed, on the View menu. But we suggest letting people see them, because the idea is to add our diagnostics to your trouble-shooting approach.

Some examples may be helpful.   Below are examples (from actual systems) of two of the 56 types of serious errors DBDOC detects.  DBDOC also detects on hundreds of other less serious sorts of issues, some of which are cosmetic, and some of which are generally not serious, but should be evaluated on a case by case basis.

Error Example: The Case of The Broken Timer

So here you are. You expect a timer to be working (Block 3103 in the image), but it is not. What do you see (ignore my orange oval for a moment)?



There are two warning triangles on the sheet! What could they be telling you? Click on the first one to see what it is telling you.




What? Didn't Composer flag that sort of thing? I dunno, maybe it did. Click on the second one (because it is trivial and might add some context to the issue).



Now, to get more information, you can right-click on the text [FC86] above the ETIMER Block 3102, or on the ETIMER Block itself (new in 10.6) and get access both to our "thumbnail sketch" and also to the Function Code PDF documentation.

I circled another way to get to the PDF documentation. However, our sketch is enough here.

Anyway, looking back at the misconfigured ADAPT Block 3095, you can see that it is adapting S3 (the Time units spec) of Block 3102, which is illegal. 

S5 is the Timer reset value of Block 3102, which is what it should be adapting, i.e. S3 of ADAPT Block 3095 should be 5.

The point of this is that the issue pops into view when you get to the problem sheet. Of course, you should have already gone through the issues we identified and hidden ones you found to be inconsequential. But the error markers put the issues we have found right in front of you..

Error markers are the latest enhancement to integrity management for INFI 90. You need them to step on problems before they step on you, your plant and the people in your path.

Four New Ways to Select and Search for Text On Graphics and Configuration

We've always wished we could copy and paste or search for text direct from graphics and configuration.  With DBDOC 10.6, it's now possible.

Here are four new easy ways to get text directly from graphics and configuration:

1. Right-click on any text (for example a tag name) and search for it directly:

2. Right-click on a function block hotspot (new in 10.6), and search for the function block text, or look up the associate function code documentation:

 

 

 

3. Even on a graphic, any text can now be accessed via right-click:

 

 

 

 

4. If there is text associated with a hotspot, it will be automatically loaded into the search/copy buffer for you:

 

 

Once you have the text, you can

• Look it up in the DBDOC help
• Do a full text search of your project for it
• Do a database search for it
• Find topics with that name

or just copy it and paste it somewhere else useful. 

Try it out.  This new feature is long overdue, but better late than never.

Four common scenarios (such as very large DBDOC builds) that will benefit from NEW sibling projects.

Sibling projects! Strange term. What does it mean?

New in DBDOC 10.6, the new "sibling projects" framework allows you to include configuration information from related projects in your build, without including all the documents and graphics from that project.

Here are a number of use cases:

1. Multiple Composer (and WinCAD) Projects - Build separate projects, each with the local console and still have the benefit of DBDOC checking for the existence and type of the imported blocks and tags from others projects. Relevant to people with multiple plants that have interconnections. Makes full checking possible without combining the projects into one DBDOC build, thereby including much more than is wanted for Unit 3 or Recaust area.
2. Huge Systems - We have some systems that are so big that they cannot be built into a single DBDOC project anyhow. This feature allows each large project to check blocks sourced in the other projects properly for the first time.
3. Development Projects - Build a small development project for one or more modules with the main project as a sibling project. This will give you full checking of imported blocks and tags from the rest of the system while making your limited build very quick.
4. AutoCAD Systems - Now, by building sibling projects, your build may be able to include all the AutoCAD files for an area, instead of a compromise being required because you would be building too much into one project.
5. Integrity Check for New Work - Now, you can give a contractor MASTER.DB from the main project (or projects) and let the error checking serve you so you get a tighter project done for you.

Upsides:

1. Faster, Smaller DBDOC Builds
2. DBDOC Builds Focused on Plant Areas
3. Cross-Checking Huge Projects
4. Including More AutoCAD Files
5. Integrity Check for New Work

Downsides:

1. Iteration might be necessary if interacting changes are simultaneously brought into your DBDOC builds. That is, if Project A imports new blocks from Project B, you might not pick them up when you do the first build, because the checking is done against the old build. The workaround is to build projects with changed configurations before the ones that have not changed, or rebuild if you have messages you do not expect to see.
2. "Stub modules" might have to be taken into account where some form of a module configured in another project is included in the one being built. This has been done in projects in the past where references were needed, but the actual configuration that had been cloned was not the master one.
3. Right now, our PCUMAP feature needs a full plant build to show all interactions. We intend to remove that limitation. For now, to get the full PCUMAP feature, just continue building the Composer (or WinCAD) projects without worrying about tags and graphics.
4. You need to open up the small projects with Hyperview to look at the details. The point of sibling projects is to have a nice plant focus to the DBDOC project, while ensuring interactions among projects are cross-checked. 

 

Operating / Conversion Parameters:

 

To make the feature easily available to people, we made the following decisions:

 

1. We include existing files as sibling projects as the default
2. If you have individual projects plus a plant master project, do not include the plant master project as a sibling
3. You must build projects individually, because master.db file is not available to any other project when a build is going on
4. You should review any blocks with external sources to make sure you need them now and to mark them not to have live data fetched

How to Define a Sibling Project - Single Large Project

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects all in a single large plant DBDOC project.

 

Create a new project for Loop 1. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is selected. Go ahead and build.

 

Any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now create projects for the others, one at time. Mark the previously created small projects as siblings, plus the large one, until you have done the last one.

 

When all small projects are created, use BuildPlus / Tools / Project Options / Define Blocks With External Sources to de-select the large project. From now on, each small project will check the others.

 

How to Define a Sibling Project - Existing Decoupled Small Projects

 

Suppose you have Loop 1, Loop 2, Loop 3, Loop 4, Loop 7 and Loop 9 Composer projects in their own individual project. You might also have a single large plant DBDOC project.

 

Open up the project for Loop 1 in BuildPlus. Include the consoles and databases only for Loop 1. At the "sibling project" query, make sure the the large project is NOT selected, but that the other small projects are marked as "siblings". Go ahead and build.

 

Again, any blocks that are not found in the local Loop 1 project will be looked for in the sibling project or projects. Thus, both imported blocks and tags from other projects will be resolved properly and you will not have to resolve numerous "no source" messages.

 

Now modify the other projects in the same way. When you are done, you will find that "no source" messages may have disappeared. Also, if they have, you can be confident in the fact that DBDOC has probably found the PV, SP and MA blocks for station tags properly. This will be an improvement of significance.

 

How to Set Up a Development Project

 

Although not a "Holy Grail" in INFI 90, we have often been asked to support DBDOC builds for development work. Now it can be done reasonably.

 

In the case of work being done in the main Composer project, the development DBDOC project would involve the following:

• Build the main project excluding the modules under development to keep on top of imported blocks and tags from the development work
• Build only the modules being worked on in the development project, using the same Composer project and use the main project as the sibling
• Rebuild the main project with the development project as sibling if this is useful.

If the Composer work is being done in a separate project, simply make it into a DBDOC project with the main project as its sibling project.

 

The Biggest Systems in the World

 

When multiple projects exist that cannot be built within the limitation of about 20,000 documents and 2 GB DBDOC M14 file size, the technique is trivial and very valuable. Simply mark the other projects as siblings. Most "no source" messages will disappear and you will be left with the errors that could bite you.