DBDOC 10.5.1: What's in it?

DBDOC 10.5.1 has made its appearance this summer, with some major updates to our support for SPlus and PGP graphics, as well as completely reworked 800xA support.  Database tag records are now much clearer and complete than ever before.  And with the addition of Error Data Sharing, the first example of data sharing support for Hyperview users is now complete.


Improved Database Tag Records

One of the first changes you might notice upon upgrading to DBDOC 10.5.1 (download here), is the completely reworked presentation of database tag records in the Hyperview browser.

For historical reasons, tag records displayed in Hyperview used to look like this:

 

 

And now they look like this, which is a lot easier to read:

 

Complete Tag Information from Operate IT and SPlus

In addition, ALL data is now extracted from Operate IT (PPB and 800xA) XML database files, and are now be usefully displayed (and searchable) within DBDOC.  Previously only a limited subset of tag attributes was extracted by DBDOC and presented in the Hyperview browser.

Before:

After:

Error Sharing
 

Another change you might notice, if you were introduced to the Error Browser in the last release, is the appearance of a new checkbox list on the left hand side of the browser window.  This is a list of users on your system who are sharing their error stars and checks, which you can choose to display in your Error Browser.  This makes it easy to review errors collaboratively.   It is planned for future releases to include shared bookmarks, annotations, Watch Window groups, and Watch Window data.  

 

 

 

To participate in error data sharing, use the new Sharing tab of the Options dialog to register for sharing in a specified Shared Data Folder.  Usually the name of the Shared Data Folder will be supplied in the project file, so all you have to do to start sharing is hit OK to register.

 

 

Extended Support for SPlus and PGP Graphics
 

If you have SPlus or PGP graphics, you will notice substantial developments in DBDOC's support for these formats.  Support has been extended past the initial support of systems converted from Conductor VMS systems to include consoles converted from Conductor NT and Process Portal B. Live controller data has been added.

Extended and Reworked Support for 800xA Graphics

The support for 800xA has been completely reworked to make use of data extracted by programs from Assistance Système LD Inc. (ASSYST) giving better images, access to controller data and text searching on graphics, and eliminating the numbers and arrows seen in earlier versions using the previous approach to extracting these graphics for DBDOC.

Other Updates

In addition to the major developments described above, 10.5.1 delivers plenty of minor bug fixes and
improvements.  More DBDOC error types have now been converted to display in the Error Browser.  Live data (notably in the Watch Window) can now be requested every 100ms.  Go To Use right-click navigation in Hyperview now places system uses before DBDOC generated documents.  Timestamp labels can now be hidden in the Watch Window.   CIUMon logging has been improved in many ways.  Command line support for importing DBDOC projects has been implemented, making it much easier to migrate the DBDOC build system to a new computer.  And many more small changes which you may or may not encounter but which increase DBDOC's robustness and usefulness in specific situations.

If you haven't already, take a moment to download DBDOC 10.5.1 and upgrade your system.

Managing Errors with the Error Browser: Function Generator errors

DBDOC has noted CHECK messages for over a decade.  Errors are classified with a CHECK severity (as opposed to ERROR) when many or most of them will not actually cause a process problem, yet certain circumstances exist where they could.   ERROR severity errors should be investigated and corrected first, and then CHECK severity errors can be addressed.

One example of a CHECK error is "X coordinates out of order for F(x)", which is DBDOC's check on the order of the X coordinates in FC 1, F(x) Function Generator block.

The X coordinates (the even numbered specs from S2 to S12 for a Function Code 1 block) must be in ascending order for the block to work properly. Essentially, linearization is done stepwise, with only one pair of coordinates involved. However, many of these blocks have inconsequential errors where the output is flat, or there are minor round-off errors, or the blocks are simply not used. Some have the errors outside the design range of the calculation. It's important to identify the particular situations where an actual problem is present.


Suggested process for analyzing CHECK errors with the Error Browser

Below we work through this process in a system with 39 such errors. We will walk through the steps of figuring out which of these are potential process-affecting errors, and which can be safely hidden and ignored. This can only be determined in the context of each specific site

We open the Error Browser, set Show these errors to "All," set  Group by to "Severity" and then by to "Error Name," and press Rebuild Tree.  The tree now shows all the different types of errors in the system, organized by their severity.

In general, it makes sense to hide CHECK errors and other errors less severe than ERROR errors (e.g. COSMETIC, INTERNAL).  They will then be out of your way while you focus on the ERROR severity errors.  When you are ready, come back to the CHECK errors, and identify those that could cause problems.  In this example, it took me about a minute to analyze the 39 " X coordinates out of order" errors and identify the single one of those that was actually a cause for concern.

Here is an Error Browser procedure to follow for this error type, and generally speaking, for any other CHECK severity error:

1. Set Show these errors to "All," set  Group by to "Severity" and then by to "Error Name," and press Rebuild Tree.
2. Select the error type of interest, in this case "X coordinates out of order for F(x)".
3. Mark them all as Hidden.
4. When you have time, walk through each error, checking if the block it refers is actually used.  If it used, Star it.
5. Mark the errors that you have walked through as Reviewed.  Now they are both Reviewed and Hidden, and need not be further worried about.

Analyzing the starred error is outside this minute, of course.


Marking the "X coordinates out of order for F(x)" errors as Hidden

Click on the "X coordinates out of order for F(x)" in the tree to select all errors of that type, then click on the Hide icon to hide them.  This will get them out of your way until you are ready to walk through them in detail.  Because they are CHECK errors, they are unlikely to be causing any problems, but a few of them might be.

 

 

Walking through the errors, checking which problem blocks are actually used

 

Click on the first "X coordinates out of order for F(x)" message. You will see both the message details in the lower panel of Error Browser, and the function generator block it pertains to on the CLD in the main browser window.

• The block index shows that the F(x) block in question is used in only one place (that is, it is not imported anywhere else) [green].
• Links to complete documentation of the message are available [purple].
• The specifications [blue] are there to examine. The problem with the specifications [red] is evident. The X coordinates (even numbered specs) are decreasing, not increasing. This block will give an output of 0.8 for all inputs less than 120.0, and 23.2 for inputs more that 120.0. It doesn't work.

But you do not care, because the F(x) output is not used.  If it were used, there would be more than one entry in the Block Index.

Arrow down through all the error messages of this type, and all but one will turn out to be unused.

 

 

 

 

The F(x) block with "X coordinates out of order" that is actually used

Only one block with this error is actually used in the process.  You can see (below) that it is used because more than one item (the block source, as well as its use) show up in the Block Index.

The output value is wrong in the input range from 5.0 to 10.0. Like the negative side, it is supposed to rise linearly from 1.0 at 5.0 to 3.0 at 10.0. Instead, the output jumps from 1.0 to 3.0 when the input reaches 5.0. Analysis of the logic using the FC 16 multiply block is needed to determine how adversely this will affect the process. However, if you consider that the output is 3.0 for all values of input other than from -10.0 to 10.0 (by design), it is clear that 25% of the design effect is missing. Furthermore, one can worry about the effect of the step function in the output, something that DBDOC also has flagged.

 

Click on the Star to mark the problem error. You can also Unhide it. Now you can Rebuild Tree, which shows up whenever the Error Browser presentation would change. I also changed to show "Active" errors instead of "All", which makes all the Hidden errors not show up in the tree.
 

 

 

 

What is the error? You must be curious by now.

 

The messed up number feeds an adapt block that affects the overall gain of an APID block controlling a tag called 2LIC-459 "GREEN OIL TOWER REFLUX DRUM". The error means that there is no gradual ramping of the overall gain from 1.0 to 3.0, which might be nasty. On the other hand, GREEN OIL TOWER might no longer be used at all, or perhaps never installed, or whatever. DBDOC makes it all as easy as A, B, C.

• A - The Function Generator Block 4008 is flawed, making a step change in the value where it should be smoothly changing.  This feeds into Multiply Block 4010.
• B - The bad output from Multiply Block 4010 is fed into the Adapt Block 4011.
• C - The bad value is set into S11 of APID Block 4016.
• D - As a result, APID Block 4016 has a step change in overall gain in part of its operating range.
• E - The output signal generated will jump if the error (my guess) exceeds 5.0.
• F - Control of 2LIC-459 will be dicier than it should be, because control signals will be more extreme than designed.

 

 

 

Displaying the actual F(x) Block function, with live data

 

As an aside, DBDOC will show you the actual F(x) Block function, with its live data (but not here, because I do not have the plant data). You turn it on by right-clicking the output block number [A]  and selecting the live function graph feature [B]. Double-click on the graph [C] to dismiss it.

 

 

 

Getting more information: Help links in the Error Browser

This is as good a place as any to mention the fully featured help that is built into Error Browser, from the purple highlights above.
 

 

Surprise! Your TSTALM Blocks may put random device drivers into override (or do even worse).

TSTALM blocks can easily be misconfigured when working logic is reused. The most common error is simply failing to change the input specification to get the status from a different block (i.e. S1 is accidentally left unchanged when the function block is copied and reused, and thus both old and new TSTALM test the old block, and nothing tests the new block). When this error is made, there are invariably two consequences:

1. Action that is intended to be taken does not happen when it should.
2. That very same action does happen when it should not.

This note analyzes just one of thirteen instances identified by DBDOC in a particular system where a TSTALM block tests a block that already has a TSTALM applied to it (in fact two of these errors are not a concern, because previous examination has shown that the incorrect action is not taken because the signals are unused).  The remaining eleven messages in fact indicate twenty actions that will not happen when they should, plus twenty places where the same action will happen when it should not.

Of course, a situation where a TSTALM block triggers one or more wrong actions, and where the designed TSTALM block fails to trigger the desired action, can be serious for any block type.

Example:

The TSTALM error is typically caused caused by the DCS worker failing to change specification S1 to match logic that is put onto a sheet and given new block numbers.  So the block is copied, but the TSTALM S1 is not changed to match the new block it is supposed to be testing.

Take a look at this image:

 

 

 

[A] Error Browser: Multiple TSTALM: Module 1,10,04 Block 3623 is tested multiple times

This error is selected in the error browser.  It indicates that more than one TSTALM block is testing Block 3623.  The Error Browser shows a total of thirteen errors of this type.

 

 

[B] TSTALM Block 3632 -- The working original

 

The MSDRVR (Block 3623) is being tested correctly for being in Auto or Manual because the TSTALM (Block 3632) shown has S1=3623, indicating that it tests MSDVDR Block 3623. 

 

 

[C] Intended action on block in Auto or Manual

If TSTALM (Block 3632) is put into Manual, its output at block 3633 will be 0. However, if TSTALM (Block 3632) is put into Auto, block 3633 will be set to 1.

 

 

[D] OR block with this result in it

 

Clearly documented "OVERRIDE TO DEFAULT", this action works in the prototype logic.  When TSTALM (Block 3632) is in Auto, the S25 override input into MSDRVR (Block 3623) will be set.

 

 

[E] The MSDRVR block Override input

 

The diagrammed MSDRVR (Block 3623) will be put into Override when it should be.

 

 

[F] Working action

 

Tag 1SLWHS806 "FLUSH WATER PUMP" will be put into Override if TSTALM (Block 3632) tests the  MSDRVR (Block 3623)as expected.

 

 

[G] Seven errors:  MSDRVR (Block 3623) is spuriously tested by SEVEN other TSTALM blocks.

 

The block index shows seven more TSTALM blocks responding to the status of tag 1SLWHS806 in a spurious and possibly dangerous fashion.

 

These seven  TSTALM blocks, each with their S1 set incorrectly to 3623, are displayed below.

Each of these seven TSTALM blocks will put some random MSDVDR into Override when the unrelated MSDRVR (Block 3623) is in Auto, and at the same time fail to put the expect block into Override when it should. 

 

Ramifications:

 

Some of the failed or unintended actions might be noticed. Others will not be until a problem arises. It is very likely that the cause of the sporadic operation will not be found if the problem actions or failed actions are noticed, because there is no expected logical connection between these unrelated blocks.

Your system depends on TSTQ to detect problems. Are these tests actually working?

I have taken the time to show and explain some of the many things that DBDOC checks for (and Composer does not). I believe there is no better tool for configuring INFI 90 than Composer, way ahead of WinCAD and DOS CADEWS. However, we have found that many errors exist "in the wild" and cannot stomach ignoring them.

One very common and pernicious error situation is when TSTQ blocks test the quality of signals that don't have quality. The test always succeeds, and this success allows whatever condition the test was designed to detect to go undetected. This is potentially dangerous, since the intention of some responsive action resulting from the detection of bad quality on a signal is silently thwarted.

To highlight problems of this sort, DBDOC checks to make sure that TSTQ block inputs actually can be bad quality, and reports errors when they are not. DBDOC also draws lines with quality in blue, making visual confirmation easy.

The following examples are from a system where DBDOC detected 82 instances of TSTQ being used to test signals without quality.

Overview:

In this first example, a signal called "LP EXT TO LP STM" is brought into the system to use in control. The TSTQ error found by DBDOC will cause bad quality on this signal to put part of the control loop into Manual, but leave part in Auto (not the designer's intention!).

Take a look at this image:

[A] Error message presented by DBDOC Error Browser

TSTQ 1SLPPC904@MI Module 1,02,02 Block 1668 tests Module 1,02,02 Block 1610 (FC 7), which does not have quality.

Clicking on the error in the Error Browser calls up the problem TSTQ block [1668].

[B] TSTQ block that is offending us

Input S1 is blue, showing that the signal can have bad quality. Input S2 is black, showing that the signal cannot carry quality ([E] on the second image shows where the quality was inadvertently stripped out).

[C] Intended action on bad quality of the second input

Bad quality is supposed to put the controller 1SLPPC904 "LP EXT PRESS CONT" in Manual Lock, but will not.

[D] Controller that is not handled correctly

Tag 1SLPPC904 "LP EXT PRESS CONT" will keep on in Auto, even if the input is bad.

As a contrast, here is a situation where bad quality is handled correctly, and will successfully trigger a controller to switch into manual.

[E] The Square Root function block that removes quality

The output of the square root block [1610], like all calculation and operation blocks, strips the quality attribute from the signal.

[F] Working action

Bad quality on the input correctly, with a 15 second delay, does cause an intended action.

[G] Intended action

After the delay, bad quality will put part of the control loop into Manual Lock.

[H] Controller that is handled correctly

Tag 1SLPFC904 "LP EXT TO LP STM HDR CONT" will be put into Manual if the input is bad.

Ramifications

Only 81 more of these TSTQ errors to analyze. Signals are never bad quality until they go bad quality. At that point, the plant is depending on the logic to protect it, and these error situations typically thwart the intent of the logic.

Coming soon: DBDOC 10.5.1, with NEW error sharing and improved SPlus/PGP and PG2 support

We're now in the home stretch for getting the next DBDOC release out the door.  DBDOC 10.5.1 includes major expansion of some of the new features introduced in DBDOC 10.5, as well as general bug fixes and feature improvements

There is good news for users of SPlus/PGP graphics.  As we receive feedback and gain experience from client systems using DBDOC 10.5,  support continues to be solidified, especially for systems converted from PPB and Conductor NT.

In addition, there is a whole new approach to 800xA graphics.  Using tools created for DBDOC by  ASSYST (included with your DBDOC installation) it's easy to extract more comprehensive PG2 or VB data for better integration of 800xA graphics into the DBDOC snapshot.

The other major new feature for DBDOC 10.5.1 is the introduction of error sharing.  Really this is just the first step along the road of allowing Hyperview users to share data in general.  Right now, each Hyperview user is relatively isolated, making independent annotation notes on projects, bookmarking significant items, creating and configuring Watch Window groups, and, as of DBDOC 10.5, managing and reviewing system errors in the new Error Browser.  The vision, however, is for all these activities to become more collaborative.  A whole group could take advantage of a predefined set of bookmarks, or view notes made by others.  It takes time to set up Watch Window groups, configured appropriately for monitoring particular situations.  Ideally these groups (and the data collected in them) could be easily shared among multiple users if desired.

So this is the direction Hyperview is heading, and the first example of this sort of sharing actually implemented is the sharing of error information, i.e. the stars and checks added to errors displayed in the Error Browser.

User data is shared via a shared folder accessible to multiple Hyperview users.  Usually this folder will be specified in BuildPlus, when a project is built, and will show up automatically in Hyperview.  To start sharing data with other users, all you need to do is "register" in this shared data folder.  Go to the Options menu in Hyperview, choose the Sharing tab, and (if a shared data folder has been built into your M14), just hit Apply and you're done.  If not, you can manually choose a data sharing folder.

 



When you open the Error Browser in 10.5.1, you will notice a new list on the left, listing all the users that have registered to share their error information.

 

By checking and the boxes next to the names of other users, you can cause their stars and checks to be displayed in your Error Browser.   By setting various filtering options, you have control over which errors you display.  For example, you could display only the errors starred or reviewed by a particular user.  Once the errors are displayed, you could select them all (for example) and hide them, or mark them as reviewed yourself.

 

This functionality is simple but powerful, because for the first time, it really makes it easy and convenient for groups of users to collaboratively review and manage errors.  A typical system will have hundreds of build errors, many of which are not serious in context, but all of which should be reviewed for safety.  The ability to split up and coordinate this error review process is extremely useful, and was requested by a number of early Error Browser users.

 

DBDOC 10.5.1 will be released and available within the next few weeks.  For an early look at the new features still under test, you can download DBDOC 10.5.1 Beta from the GMCL website.

DBDOC Visits the Peak District

Geoff and I are visiting clients in England for the next two weeks. On Monday we visited our first client, a cement works (Hope Works) in the Hope Valley, Derbyshire, a very pretty place. The villages are beautiful, set among large hills and occasional rock outcroppings rather than mountains. Of course, there are sheep everywhere. The weather was warm, approaching 28 degrees C with blue skies and sunshine as we started work in the morning.




The stone house is the B&B where we spent Sunday night. At several hundred years old it is an historic site, as the oldest of many similar ones are in the village. The ceilings are supported crosswise with large thick oak beams. In all very charming for our first night in England.

The sunshine, however, was not to last. By afternoon clouds had come up, and as we drove away in the late afternoon the rain started. Fog blurred the landscape and a picture of the rock outcroppings was not possible. The rain followed us to our next stopping place, Happy Guest Lodge at Warrington, Cheshire. Here we are today, with a day off, until we start visiting with clients for the rest of the week. Next week we will be visiting clients in the London area.

Keeping XP secure as Microsoft's support slowly ceases

Today, Microsoft released a patch fixing a potentially serious (although some at Microsoft have called it "overblown") security bug that allowed for remote code execution through Internet Explorer 6 through 11. In their initial advisory for the issue, they listed affected Windows versions without mentioning XP. With this patch, they've apparently decided that it's important to patch XP too for this one. But rather than cause for celebration for XP users, this should be one last wake-up call; coming mere weeks after XP was dropped from support, Microsoft decided to patch through this time, but they're making no promises that there'll be a next time.

Here at GMCL, most of our physical XP machines have been retired, and we do most of our testing for it in hardware-accelerated virtual machines (which combines running a 'real' install with the ability to quickly snapshot and revert as desired). But a few machines still linger for one reason or another, so how do we approach maintaining them? Well, here's a few thoughts on the subject that I've arrived at, which I think apply generally:

Don't delay on upgrading: Obvious, but deserves stating first. Practical realities may make it seem too difficult, and one might imagine oneself to be secure, but even if XP was very amenable to being secured (and, in many folks' opions including mine, it really isn't), it's going to be an increasingly huge target. And even if you have an air gap in theory, in practice air gaps are nearly impossible to fully maintain; as Paul Ferguson of Trend Micro wrote in his white paper "Toward a More Secure Posture for Industrial Control System Networks", in "practical and operational terms...physically separating networks is not functionally nor operationally feasible in the real world." So for any systems still running XP, it should not be if you upgrade or replace them, but when.

Drop IE for Chrome or Firefox, wherever and whenever possible: Microsoft's policy for Internet Explorer updates is to tie them to support for the OS version in question, so while Internet Explorer versions for Server 2003 and 2003 R2 will continue to get updates until 2015-07-13, those that shipped with XP aren't officially guaranteed to recieve any more updates after April 8th---as Microsoft representatives have explicitly stated, today's update is "an exception". But Google's Chrome browser and the Mozilla Foundation's Firefox both will support Windows XP, and thus provide security updates on it, past the April 8th drop-dead date. Google is intending to update Chrome for Windows XP until at least April 2015, and Mozilla currently has no plans to discontinue support. Both browsers have proven in the past to be more secure out-of-the-box than Internet Explorer, and although contemporary versions of IE have significantly improved in this area (and many others), those versions won't run on XP anyways.

You may well have internal sites or systems that rely on the older IE versions (especially if they involve ActiveX controls), but considering the web browser is perhaps the primary vector of infection, it is worth seriously evaluating the possibility of migration, and at very least using IE only in the specific instances you need to. In fact, for Google Chrome there is an official extension that can be installed on managed Chrome installations which allows you to specify automatic switching between IE and Chrome based on listed sites, thus allowing you to cordon off only specific internal sites to be browsed with IE.

Enabling Internet Explorer's Enhanced Security Configuration: To the degree that ditching Internet Explorer isn't an option (or that you truly prefer it as a browser), there's always the Enhanced Security Configuration. This is enabled by default on all versions of Windows Server, and can be enabled (piece by piece) on Windows XP. It beefs up security at the expense of some convenience--in fact, we've even run into some small bugs with the DBDOC Error Browser when ESC is enabled (relating to copy/paste). In this case, especially when XP is concerned, the convenience traded off seems potentially worth the added security, but that is indeed the classic dilemma.

Using the Enhanced Mitigation Experience Toolkit: Microsoft's EMET is a tool that hardens applications by preventing the kinds of behaviours and faults that are often exploited by malware. As such, it's quite useful for preventing unknown or unpatched vulnerabilities from being exploited. It's enabled per-application, so you can be granular and choosy with this one.

Uninstall anything you don't use: The converse of using the EMET to harden applications is to make sure any you don't actually need aren't there to be exploited. Alongside the news of the recent IE exploit, there's also an Adobe Flash exploit recently discovered in the wild. Many XP machines may have components like Flash and Java installed that they don't actually need for daily operations, and the machines in question will be safer without the additional attack surfaces lying in eager wait.

For anyone out there, what are your thoughts? Are you already working to upgrade? Is it out of your hands? Do you have any other suggestions for keeping XP as secure as possible as it sails well past its best-before date?

Try DBDOC on a Tablet: It Just Works!

Recently we brought a Surface Pro tablet into our office, and we've been pleasantly discovering that for the most part, DBDOC Just Works! Read on for more details.

 

 

Lets look at Hyperview, which is the most likely of the DBDOC programs to be used with a tablet.

First up, we have an option in Hyperview that happens to have prepared us for touchscreens entirely unintentionally. If you go into "Options..." you'll see in View the checkbox for "Large icon toolbar", which scales up the main buttons.
 

 

Who knew we were preparing for touchscreens all this time? It's nice to be forward-thinking by accident!

Most navigation works as you'd expect. Tap on the screen for left-click; long-press for a right-click, for example to call up a context menu on a block; scroll by flicking within a pane or by pressing down on a scrollbar and moving your finger. It can be a bit inconsistent sometimes, and we're investigating an issue where kinetic scrolling in the index pane stops working on some M14s, but in general it's quite fine with fingers or a stylus.

Selecting an area to zoom into can be a bit tricky with the touchscreen, although I've found it to be fairly reliable if I start first with a distinctly horizontal motion, then start moving my finger vertically as well. Otherwise, Windows sometimes interprets the motion as an attempt to drag the viewspace. With the stylus that comes with the Surface Pro, however, box selection seems to work without hassle.

If you're running Windows 8.1 on a relatively high-DPI device like the Surface Pro or a new high-end laptop, you may notice the fonts are a bit blurry. This is because Windows 8.1 by default scales up the UI element sizes when using a dense display, which is handy for keeping things readable (and for making it easier to touch interactive elements), but isn't done in a way that's terribly kind to applications built on the old standard Windows assumption of 96dpi. Right now, most third-party applications for Windows react in one of two ways: either upscaling with blurry fonts and other elements, or ignoring the scaling entirely. You can see this contrast with the current versions of Google Chrome and Mozilla Firefox for Windows, where the former looks the same as DBDOC does and the latter stays crisp but small in defiance of Windows' scaling settings.

If you haven't noticed this (in which case, sorry for pointing it out!) you can leave it as-is, but if you're looking to disable scaling globally, you can find the option in "Control Panel\Appearance and Personalization\Display". You can also disable in on a per-application basis by right-clicking on a shortcut or an EXE, going into its properties, and choosing "Disable display scaling on high DPI settings" from the Compatibility tab.

 

We're investigating and evaluating how we might hook DBDOC into the scaling functions of contemporary Windows, which will not only help with tablets like the Surface Pro, but also high-resolution desktop and laptop displays which are just now starting to edge into mainstream production; my own laptop has a resolution of 2560x1700 on a mere 13" screen!

Well, that's the rote details of the current state of running Hyperview on Windows 8/8.1 tablet, but what's the actual use? Well, we've imagined that it could be quite helpful carrying around a plant, looking at live data (if you're connecting in through a local network or VPN) or even just to be able to easily browse your graphics and CAD sheets while standing in front of the actual machinery they represent. You could use CIUMon Relay to pass on data from a running CIUMon instance, or even hook up a USB-to-serial adapter to your tablet and plug in directly to a CIU with your tablet. And the guts of Microsoft's Surface Pro and Surface Pro 2 are fairly hefty, so you could even run BuildPlus to generate M14s if need be.

We're just getting started on touchscreen and tablet support, so let us know what you would find useful and in what scenarios you can see using DBDOC on a tablet!

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.