Lipstick on Modbus

That’s how some users have come to view OPC, at least in its current incarnation. OPC UA is on the horizon, or just over it somewhere. Will the maladies some have experienced with COM / DCOM-based OPC be addressed in the next release? There may be hope, but users should be vocal and vigilant with their suppliers.

What was once “OLE for Process Control” (a curious, nested acronym; OLE = “Object Linking and Embedding”) is morphing into a panacea for integration across the enterprise. Is the standard being developed likely to be a product for “process control” as we know it, or aimed at business-system services such as SAP or Maximo? Can OPC UA be all things to all people?

What Modbus gave us, and what continues to be useful today, is a standard for mapping values to a table in a standard format. Modbus also provided a command set or protocol for moving this data, in this case from a “slave” to a “master.” It must have been easy and cheap to set up one’s operating system to emulate a Modbus master or slave, because nearly everyone seems to have one. Modbus was ubiquitous by the 1990s and remains so today. Most of us are still using it.

Some people are ripping out their early OPC implementations and reverting to Modbus. The “process control” properties of OPC, or lack thereof, have been known to cause issues, depending on the platform and the demands. Said one user, “I have people who would rather take a flogging than maintain an OPC installation. It has been an ugly experience.” 

One of the annoying things we’ve experienced is the phenomenon of “Departed on Holiday,” or “DOH!” Without any warning, the OPC server stops updating. Maybe you can program a “watchdog timer”—if you can find a place to “write” in the server and “read back” to the client. But even if you detect a disconnect, there are no provisions for restarting the interface. Some savvy person is needed to get the thing going again. If you’re doing process control, this is not a good thing.

Another tricky thing about process control is initialization. When I came to Lima, Ohio, in 1983, the Standard Oil refinery there had banned cascade control. The heart of the refinery ran on Foxboro “H-line” 10-50 mA controllers. Foxboro H-Line accommodated cascade, but with analog electronics, aligning a cascade master with its slave—matching the master’s output to the inner loop’s setpoint—had to be done manually by the operator. While our current OPC DA standard has a “status” associated with each signal, one has to quite deliberately “map” this value from one client to the host or vice-versa. While Foundation fieldbus signals innately support bumpless initialization through handshaking signal statuses, you will have a potentially rocky experience if setpoints are passed via OPC.

My business-network historian vendor has developed a nifty little applet that ideally runs on the same node as the DCS OPC server. No COM or DCOM configuration is needed in this case. It runs great, but only after some tribulation. Initially, half or more of the thousands of points being “polled” were rejected by the DCS OPC server. After days of tinkering and troubleshooting, someone noticed that browsing to a tag populated fields with “all caps”—no lowercase characters. Sure enough, when the polled tags were changed to “all caps,” all the configured points started happily writing away. Said our developer contact at the historian vendor, “This is not part of the spec.” Like Modbus and some other protocols, OPC had become a “standard” without any independent testing or certification.

OPC UA promises to cure many of these ills, and there even may be some independent third-party certification. But what about “process control,” you know, the “PC” of “OPC”? When we need tight integration between process control systems—passing setpoints or tuning constants to a turbine governor or anti-surge controller, for example—is OPC up to the task? Those of us pushing the supplier community for native Fieldbus HSE are not likely to be satisfied with an implementation that depends on OPC or any OS-dependent interposing “mapping.” HSE was what users wanted to address high-level system integration, but instead, our supplier community chose to deliver “openness” via OPC. In practice, is this any great improvement over Modbus?

Users in the Middle East and elsewhere are anxious for major suppliers to provide systems and devices with native HSE capability. I think they will be dismayed if it is delivered via OPC. Perhaps we would all be better served if HSE was used for the “PC”—process control—and OPC thereafter stood for “Other than Process Control”—historians, ERP, simulators, etc.