By John Rezabek, contributing editor
Thats 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 ones 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 weve experienced is the phenomenon of Departed on Holiday, or DOH! Without any warning, the OPC server stops updating. Maybe you can program a watchdog timerif 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 youre 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 slavematching the masters output to the inner loops setpointhad 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 capsno 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 systemspassing setpoints or tuning constants to a turbine governor or anti-surge controller, for exampleis 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 PCprocess controland OPC thereafter stood for Other than Process Controlhistorians, ERP, simulators, etc.