Topics In Demand
Notification
New

No notification found.

Blog
Taking the Effort Out of Generating HMI Graphics

February 24, 2017

676

0

ARC believes end users could potentially realize significant cost savings through auto generation of DCS HMI graphics based on standard objects using information from engineering and design software.  End users typically spend thousands of hours creating HMI graphics for every project.  A good sized project could easily require thousands of graphics.  Not having a strategy for replicating standard graphics from project to project can result in 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 and end users can do to automate and simplify the generation and management of HMI graphics.

End users are moving towards a strategy where they want their graphics to look the same, regardless of the control system.  Ideally, you shouldn’t have to spend a lot of money recreating graphics if you switch from one supplier to another.  Some end users have developed standard HMI graphic libraries used across the 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 piping and instrumentation diagrams (P&IDs).  The Exxon Mobil “It Just Happens” initiative, for example, is working on using cause & effects matrices to program safety systems directly. This involves using the master document to program the logic solver automatically, which eliminates human involvement, human error, and the need to validate the human input.  This will be a significant time and resource saver.  If “master” smart P&IDs were used in a similar way to develop the graphics, this would similarly avoid a lot of error and effort.  Why create the process design depiction for the P&IDs and then do it again for the HMI graphics?  This would be another significant time and resource saver.

Many end users have already been working with suppliers to create standard building blocks that could be connected to create a screen of graphics, but this is only an incremental improvement over the way things are done today.  Creating standard building blocks that could be connected to create a screen requires participation by engineers to create the details of the standard building blocks.  Plus, this requires creating the P&ID representations on the screens separate from the actual P&ID developments.

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. 

Multiple Versions of the Truth

A fair number of HMI packages now support importing AutoCAD or SVG graphics.  The challenge is that once the graphic is imported, it’s done. It’s a one-time deal. Since the P&ID depictions and HMI depictions are not identical, multiple versions of the truth are created. They exist in different file types and have some common parts. 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 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 become out of synch and changes (like adding I/O points) can have commercial implications.  

Where We Stand Today

ARC has written extensively about auto generating documentation and simplifying DCS configuration.  Most of this activity has centered on integration with Intergraph INtools and SmartPlant Instrumentation.  Many suppliers offer integration with Intergraph solutions to make the DCS configuration process easier but, to our knowledge, no supplier offers 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. Some of this functionality promised the ability to auto generate HMI graphics from INtools and SmartPlant Instrumentation, which are widely used 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, not for auto generating HMI graphics.

It will be 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 might create problems. Operators need to be part of the graphic design process, or buy in and acceptance will be poor.  Usability would also likely to be compromised.

“Reprinted with permission, original blog was posted here?”. You may also visit here? for more such insights on the Operational Technology trends.

About ARC Advisory Group (www.arcweb.com): Founded in 1986, ARC Advisory Group is a Boston based leading technology research and advisory firm for industry and infrastructure.

For further information or to provide feedback on this article, please contactakanagali@arcweb.com

About the Author:

Larry O’Brien

Vice President, Research

Larry is responsible for providing oversight in ARC’s research into process automation markets, including process automation systems, process safety systems, plant asset management systems, intelligent device management strategies, and field networks.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.