Generating HMI Graphics Can Be Effortless and Less Costly

Overview

The traditional approach to executing process automation system projects typically involves a high degree of customization, including custom engineering.  It’s also rife with interdependencies between different engineering disciplines.  But with the wide range of advanced technologies available today, many of the customization steps required to engineer a DCS project can now be automated, if not eliminated, and interdependencies between disciplines greatly reduced or simplified.

This was the approach ExxonMobil lobbied for with its “It Just Happens” initiative presented several years ago at the ARC Industry Forum in Orlando.  This initiative has led to new forms of single-channel intelligent I/O, standard cabinets, and a virtualized environment for DCS engineering.  Many suppliers have stepped up over the past few years to offer these new approaches to automation, which have been rapidly adopted in the marketplace.

But where else can we simplify to drive out unnecessary cost?  Here’s an idea; end users invest quite a lot of money generating HMI graphics for both new projects and their ongoing modernization/migration efforts.  ARC believes that auto generation of DCS HMI graphics based on standard objects using information from engineering and design software (including intelligent piping & instrumentation diagrams), could yield significant cost savings.  End users spend thousands of hours creating HMI graphics for every project.  A good-sized project can create thousands of graphics.  Without a strategy for replicating standard graphics from project to project, end users often face a significant amount of needless rework.  What about recreating graphics when you migrate to a new process automation system from a new supplier? Sometimes, the pain of recreating graphics cannot be avoided, but there are many things the industry, automation suppliers, and end users could do to automate and simplify HMI generation and management of HMI graphics. 

Increasingly, end users want their graphics to look the same, regardless of the control system.  Ideally, they shouldn’t have to spend a lot of money recreating graphics when switching from one supplier to another.  Some end users have developed standard HMI graphic libraries used across multiple suppliers with which they have an agreement. 

Auto Generate, Auto Update

Many users would like to be able to auto generate HMI graphics directly from smart P&ID diagrams.  The ExxonMobil “It Just Happens” initiative, for example, presents the notion of using cause & effects matrices to program safety systems directly. With this approach, the company could use the master document to program the logic solver automatically.  This eliminates the human involvement, human error, and need to validate the human input.  This approach will save a significant amount of time and resources.

Now consider that if “master” smart P&IDs could be used in a similar way to automatically generate the HMI graphics depicting the process design; end users could save significant time and resources, while eliminating a potential source of errors.

Many end users are already working with suppliers to create standard building blocks that can be connected to create a screen of graphics.  However, this only represents an incremental improvement.  Creating the details of the standard building blocks requires engineering resources.  It also does not eliminate the need to recreate the P&ID representations on the screens separate from the actual P&ID development. 

Using the actual P&ID depictions for the HMI screens would be like using a common database.  Some end users envision that the perfect solution would include synchronizing the actual P&IDs with the HMI screens so that every time someone made a change to the P&IDs, the HMI graphics would be updated almost automatically. 

Avoiding Multiple Versions of the Truth

A fair number of today’s HMI packages support importing AutoCad or SVG graphics.  The challenge here is that once the graphic is imported, it’s done. It’s a one-time deal. This can (and does) result in multiple versions of the truth, since P&ID depictions and HMI depictions are not identical. While they have some common parts, they exist in different file types.

P&IDs alone are not enough to build the HMI or the control scheme, especially for complex control loops.  The tag list or I/O database is the most critical document in a large automation project for the sake of efficiency. It is common to have different database tools and different database versions at the engineering firm, the end user site, and the control system integrator site.  These databases often get out of sync, and changes often have commercial implications, like adding I/O points.  

Operator Involvement Critical

ARC has written extensively about auto generating DCS configuration and associated documentation.  Most of this activity has centered around integration with Intergraph InTools and SmartPlant Instrumentation.  Many suppliers offer integration with Intergraph solutions to simplify DCS configuration.  But, to our knowledge, no supplier supports auto generation of HMI graphics based on information from Intergraph applications. Many suppliers offer unidirectional communication between Intergraph and DCS applications, and some suppliers offer bidirectional communication between Intergraph and DCS applications. Some of this functionality promised the ability to auto generate HMI graphics from InTools, which is a de facto standard in the process industries. 

Most of the bidirectional communication seems to have been focused on updating asset information and the state of the plant design between the DCS and the engineering and design tools, but not for auto generating HMI graphics. It’s important to keep the operators in the loop when it comes to HMI graphics design. Auto generating anything that the operators will intimately get to know could create problems without their direct input. Operators need to be part of the graphic design process or usability is likely to suffer and acceptance will be poor.

Recommendations

ARC believes it is only a matter of time before the technologies discussed in this report become commercialized.  Many large end user organizations are already developing their own technologies that facilitate auto generation of HMI graphics for DCSs.  The more forward-thinking suppliers will work closely with end users to develop solutions that meet their requirements and can also be effectively productized.  Demand for auto generation of HMI graphics from plant engineering software will only increase as the level of migration and modernization activity begins to accelerate.  Many end users will create common graphics design standards because of these large modernization projects. 

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: DCS, HMI, Graphics, P&IDs, ARC Advisory Group.