1 July 2002

Combining PC control and HMI

By Murray A. McKay

A better system is the end result, but each road has different bumps.

Integrating PC-based control with human-machine interface (HMI) technology can benefit a plant floor system. However, before you decide on PC-based control, there are many things you should consider, especially when using a soft programmable logic controller (PLC) to command the I/O.

Among benefits, PC-based control easily integrates with other tasks, including data logging and manufacturing execution systems. It also runs on nonproprietary hardware.

There are three strategies to integrate a PC-based control system with an HMI: Treat the PC running the control application as if it were a PLC; integrate using standard PC interfaces; or integrate using application programming interfaces (APIs).

Each approach has advantages and disadvantages. Also, a PC-based control engine and the HMI may not support the same subset of integration options. Therefore, it is important to involve vendors to make sure the control engine and HMI support the strategy you prefer.

Strategy 1: Treat PC like PLC

The simplest strategy is to make the PC-based controller emulate a hardware PLC. To do this, install an interface port of a type found on a PLC (i.e., Ethernet, Profibus, DeviceNet, etc.) in the PC, then run a cable from the interface port to the HMI. This strategy’s main advantage is nothing special needs to be done for the HMI to talk to the PC-based control engine—it thinks it is talking to a PLC.

It is also possible to connect a non-PC-based HMI panel to a PC-based control system. Because the control engine and HMI are running on different PCs, the control engine timing will be very stable, and interprocess security will be very strong.

This strategy will not work in all cases, however. Make sure the control engine can talk to an HMI via a PC interface port. Don’t assume that because the vendor’s other products all support HMI interfaces through a certain type of port, their PC-based control product also supports the port.

A disadvantage of this strategy is it doesn’t take full advantage of the strengths of PC-based control. It ignores the fact that there is already a PC with plenty of spare CPU cycles that could be running the HMI. It also slows communication from RAM mailbox speeds down to the interface port speed. Another disadvantage is the added cost of the interface port.

Strategy 2: Use standard interfaces

The second approach, using standard PC interfaces, is a common strategy for integrating a PC-based control system with an HMI. By far the most commonly used standard interface is OLE for process control (OPC).

OPC, a collaborative effort of Microsoft and a number of controls vendors, uses standard Windows mechanisms to communicate between servers (software or devices that have data) and clients (software or devices that want data). Most PC-based control engines can act as OPC servers. Almost all commercial HMI software packages can act as OPC clients and poll data from the PC-based control engine OPC server.

It is not difficult to set up OPC connections between control engines and HMI packages from different vendors. It is also possible to get “middleware” packages that automatically insert OPC server tags into databases at configured times or events.

OPC can communicate between a PC-based control engine and a PC-based HMI system running on the same or a different PC. It is not possible to use OPC to connect to a non-PC-based HMI. OPC setup is simple if the control engine and HMI are running on the same PC. It usually just involves telling the control engine and HMI to use OPC and then configuring the tags.

The control engine and HMI run in the same login session, so no security settings need to be configured. The disadvantage of running the control engine and HMI on the same PC is they have to share resources, slowing both.

There is an extra layer of complexity if the control engine and HMI are running on different PCs. OPC clients and servers can talk across a PC LAN using Windows’ distributed component object model (DCOM) if you configure DCOM on both the computers and set up security permissions so the control engine and HMI are allowed to talk to each other.

While this is not difficult to set up, you may need to set up a Windows administrator-level log-in, so work with the information technology department.

Once DCOM is configured, the HMI can browse the control engine’s tag list as if they were running on the same PC. The main advantage of running the control engine and HMI on different PCs is the applications have their own CPU and memory, so each will run faster and smoother.

OPC has a couple of different performance constraints. First, the OPC server may impose limits on how often it will update tag values. OPC allows a client to request data updates down to once per millisecond, but the rate the server grants is implementation dependent. In practice, update times less than 100 milliseconds are unusual.

Similarly, the OPC client (HMI system) may impose limitations on how frequently data is requested from the OPC server. Finally, some OPC servers bog down when very large numbers of tags (tens of thousands) are requested too frequently. For most HMI applications, OPC is fast enough.

Strategy 3: Use APIs

The third strategy for integrating PC-based control applications and HMI systems is to use an API. An API is simply a documented set of functions the code can call or be called by. Most PC-based control engines have an API allowing the engineer to write a dynamic link library or component object model object in a standard computer language, such as C++, Basic, etc., and then invoke that code with the PC-based control engine program.

This is one of the big strengths of PC-based control—allowing the user to integrate any PC-based hardware into the control system. Use this mechanism to integrate the PC-based control engine into any HMI system.

The big advantage of using APIs is that there are no bounds to what is possible. The big disadvantage is again that there are no bounds, forcing the engineer to do it all by himself. It will be necessary to write all of the Windows code to communicate between the control engine and the HMI system.

Make sure the code does not interfere with the control engine operation or cause the control engine’s program scan to get too long. Also, ensure the code does not contain any memory leaks or cause resource deadlocks that might crash the computer. An experienced Windows programmer can do this, but it is a lot more effort than the other strategies.

If the control engine and HMI are running on the same PC, keep in mind they share the PC resources, potentially limiting their performance. The main areas of resource sharing are memory, communications ports, files, and CPU cycles.

For optimum performance, both the control engine and HMI should run out of physical (nonvirtual) RAM. Ask vendors how much RAM each application needs, add the operating system requirements, and make sure the PC has at least that much. Some control engines and HMI systems require communications ports that are under their exclusive control.

Do not assume the control engine and HMI can share communications ports. Most control engines do not need to access files at run time. If the control engine needs to access files, ensure that no other applications are accessing those files, or the control engine may slow or lock up.

Applications prioritized

All the applications share the CPU according to their priority. The control engine usually runs at a higher priority than other user applications. If the control engine runs at too high a scan rate, it causes the other applications to run slowly. Remedy this by reducing the control engine scan rate or by going to a multiprocessor system.

Unless the control engine is running under a real-time kernel, it will run at a lower priority than the operating system. This means device drivers (video, disk, etc.) can interrupt the control engine, causing slow or erratic scan rates. Minimize this by using the latest versions of video drivers and by limiting disk access as much as possible.

PC-based control applications should respond to events as quickly as possible. This makes them suited to run under workstation-class operating systems (Windows NT Workstation, Windows 2000 Professional, etc.). HMI systems are able to handle large amount of data at high average transaction rates, making them suited to run under server-class operating systems (Windows NT Server, Windows 2000 Server, etc.).

HMI systems can usually run on workstation-class operating systems with restrictions on number of operator stations. PC-based control engines may or may not be able to run on server-class operating systems.

If you decide to run the control engine and HMI on the same PC, check with your vendors to make sure the HMI and control engine can run under the same operating system version.  IC

Murray A. McKay is a consulting applications engineer for Siemens Energy & Automation. Based in Memphis, he has a B.S.E.E. from Rensselaer Polytechnic Institute and has worked for Siemens for 12 years, most of the time on PLCs, HMIs, and communications systems. His address is Murray.McKay@sea.siemens.com.