Integration of remote HMIs

That new pump skid just installed has its own HMI. What should you expect to see on that screen, and how should it interface with the larger control system?

By Matt Willmott March 12, 2014

Even with the increasing use of integrated process control and safety systems, it is still often difficult to define and create a completely homogenous system. The main reasons for this are:

  • Intelligent control devices are ever more pervasive within smaller equipment packages
  • These packages, including their associated unit control panels, are often purchased independently of the main control system, and
  • A local HMI (human-machine interface) is delivered as an integral part of a packaged control system.

The issue then arises as to how to integrate these remote HMIs into the overall automation system philosophy to maximize the value they can bring to operations.

Who set HMI objectives?

First, it is worth noting that remote HMIs are often designed with different objectives than those of the main HMI in the central control room, which is geared toward maintaining stable plant operations. This should drive simplification into the displays by removing unnecessary detail and rationalizing alarms to the absolute minimum to enable better management of abnormal operating situations.

On the other hand, the objectives of remote HMIs are often more toward enabling better equipment start-up, maintenance, and troubleshooting. As such, additional details may be required in the HMI displays, with far more local alarms required to help to determine equipment issues.

With these differences in objectives, it is quite reasonable for the functional design of remote HMIs to deviate from what would be considered best practices for a control room HMI. These deviations should also be balanced with a certain level of commonality between both HMI systems. For example, if an operator who is very familiar with an HMI display on the main system has the occasional need to use the remote HMI, it should not appear foreign to him or her.

For some years, it has been common practice on projects to duplicate the layout of HMI displays from packaged equipment HMIs on the main DCS. This practice is somewhat inefficient and imposes an additional lifecycle burden on the overall facility, as changes will always need to be made in both systems to keep the displays in sync with each other.

Using a different approach

As an alternative approach to specifying independent, stand-alone HMI systems and then interfacing them to the main control system, a different method can be applied to the problem to alleviate the project and lifecycle issues this course brings with it. The alternative method takes the main control room HMI and distributes it to the field to meet the remote HMI objectives of each package.

This distributed approach can be achieved in a number of different ways, depending upon the project and package requirements. This first strategy is to create self-contained remote HMI systems that exist as independent nodes within the overall HMI system. These remote nodes would contain everything required in a remote HMI system, including:

  • Standard and custom operator displays
  • Point alarming
  • Trending
  • Events, and
  • Local historian.

However, instead of creating an interface between the remote and main HMIs, the remote HMI can simply be joined to the main system as a peer node. As a peer node, it can then seamlessly exchange point data, alarms, history, and displays with the main system without the need to be configured twice.

An example of this capability exists within the Honeywell Experion family of systems, which includes a lightweight HMI optimized for small systems, as would be required by packaged control systems, along with a full-scale integrated control and safety system (ICSS) designed to meet the requirements of medium to very large installations. Both systems share a common infrastructure known as distributed system architecture, which allows point information, alarms, and history to be shared across system nodes without requiring any duplication of configuration.

Bringing in new problems

However, as previously mentioned, there are pitfalls to this approach if the different objectives of the remote and main control room HMI systems are not taken into consideration during configuration. One of the main problems the integrated approach can bring is the unwanted proliferation of alarms in the main HMI that are really only needed at the remote HMI level. As such, careful consideration should be given to the grouping of alarming into different asset groups to allow certain asset notifications to be available only at the remote HMI. Other asset groups may also be shared across both remote and main HMIs, thus providing a well-defined subset of alarms to be repeated to the operator in the main control room.

This approach would also allow a different set of shared asset groups to be defined for a centralized engineering and maintenance HMI, which could provide a deeper level of remote package information to maintenance personnel. Accordingly, a well-defined asset model is required on such a system to enable the appropriate alarming and data access to remote and central operations as well as remote and central maintenance and troubleshooting.

Consideration should also be given to the use of common displays between remote and main HMIs. It has been well documented by various human factor experts within process industries, such as the Abnormal Situation Management (ASM) Consortium, that HMI displays within a control room environment need to follow certain best practices when it comes to the use of color and contrast. However, as remote HMIs are often located in plant environments, the appropriate levels of color and contrast for an indoor setting may not be suitable for outdoors. In these situations, rather than having to create one set of displays for use indoors and another set for outdoor use, there are technologies that can create multiple views of the same display within an HMI. This allows simple switching to different colors and contrasts as are appropriate for the situation. For example, an outdoor display can be adjusted for full daylight viewing or for nighttime as required.

Going mobile

As a final thought, with the ever-increasing use of secure Wi-Fi mesh networks within processing facilities, the requirement for remote HMI systems can also be met by mobile HMIs, which effectively eliminate the need for a fixed permanent installation. Tools are available with many large-scale control systems to extend coverage to provide a local HMI for operators and maintenance personnel at any local package within the facility, without requiring dedicated HMI equipment. With this solution, the same degree of discrimination can be applied to alarms and display information for selected personnel and operations as with the remote HMI system.

Matt Willmott is a system engineering solutions manager for Honeywell Process Solutions.

Key concepts:

  • Systems and devices that include embedded HMIs can create challenges for integration into larger control system environments.
  • Tools are available that can help rationalize the needs of a control system and a remote device such that they perform together seamlessly.
  • Mobile HMI solutions can often eliminate the problem entirely.

ONLINE

For more information, visit:

www.honeywellprocess.com

www.asmconsortium.net 

Read more on HMIs below.