Interested in linking to "Securing Your OPC Classic Control System"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
This article describes two independent techniques for ensuring strong security in systems using OPC Classic technology. This first creates zone-based defenses using OPC-aware firewalls. The second takes advantages of improvement in the Windows operating system to managing OPC accounts and permissions. Both security techniques are available and proven for use in today's control systems.
OPC Classic – The World's Leading Industrial Integration Standard
Formerly known as OLE for Process Control, (where OLE stood for Object Linking and Embedding), OPC Classic was developed in 1996 in response to a demand for standard methods to allow different control systems to interface with each other. Today it has grown to be the world's leading technology for integrating different automation products.
No single industrial communications standard has achieved the widespread acceptance across so many different verticals, industries and equipment manufacturers as OPC Classic. It is used to interconnect an amazing variety of industrial and business systems, ranging from Human Machine Interface (HMI) workstations, Safety Instrumented Systems (SIS) and Distributed Control Systems (DCS) on the plant floor, to enterprise databases, ERP systems and other business-oriented software in the corporate world.
The reason for OPC's wide spread popularity has been simple – it is the only truly universal interface for communicating with diverse industrial devices and applications, regardless of manufacturer, software or protocols used in the control system. Before OPC Classic was developed, developers had to create specific communications drivers for each control system they wished to connect with. For example, one HMI vendor developed over 200 drivers for different DCS and PLC systems in the pre-OPC days. Now they focus their efforts on a single optimized OPC driver for their product, which then communicates to other OPC servers designed and sold by the manufacturers of the other control products.
For the end user, a significant advantage of using OPC is not having to directly deal with the control device's internal architecture. In other words, integration teams can work with named items (or groups of items) across multiple product lines, instead of dealing with raw register locations (e.g. 40020 or N7:2) and data types (e.g. 32-bit integer or IEEE floating point). This allows for an easier job when adding or changing control systems, such as when migrating from a proprietary protocol to an Ethernet-based protocol.
Most engineers soon found using OPC saved significant time during configuration, as compared to using traditional communications technologies. The result of all this is that it is rare to find an industrial facility today that isn't using OPC for some portion of its system integration strategy.
What is OPC Classic Anyway?
The term "OPC Classic" refers to all OPC standards prior to the new OPC-Unified Architecture (OPC-UA) standard. This includes the most popular specifications such as OPC Data Access (OPC DA), OPC Alarms and Events (OPC A&E) and OPC Historical Data Access (OPC HDA).
What sets OPC Classic apart from the emerging OPC-UA standards is that OPC Classic is based on Microsoft's Distributed Component Object Model (DCOM) technology. DCOM in turn, is the culmination of a number of other technologies including Component Object Model (COM) and Object Linking and Embedding (OLE). All these technologies use a network protocol called Remote Procedure Call (RPC) to connect over a typical Ethernet/TCPIP industrial network.
One of the important things to understand about OPC is it is an Application Programming Interface (API) and not an "on the wire" protocol. Instead the underlying DCOM and RPC technologies are the real "protocols". OPC is at a higher level of abstraction than true communications protocols such as Ethernet, TCP/IP or RPC.
All OPC technology is based on a client/server architecture where computers run software that makes them either a client or a server (or both in some cases). The OPC server is a software application that gathers information from a device (such as PLC, DCS or SCADA controller) using that device's native protocols (such as Modbus or PROFIBUS). The server then provides access to this data via COM objects and method calls, allowing multiple OPC clients to indirectly read and write to the field device via the OPC server.
An OPC client is an application that accesses the data held by OPC servers. An HMI package may contain an OPC client that allows it to access data provided by an OPC server application resident on another computer. The HMI package could also act as an OPC server, allowing other OPC clients to access the data it has aggregated either directly from field controllers or from other OPC servers.
To illustrate this client-server architecture, imagine a simple system with three basic components designed for controlling the water level in a tank:
• A Modbus-capable PLC performing the actual control functions
• An OPC platform that contains an OPC server and a Modbus protocol driver
• A HMI for operator access to the control system
The HMI will need to be able to write the set point in the controller, read the current water level, and monitor the controlled output (the pump) and alarms. If the HMI needs to read a value from the PLC, it sends a request via an OPC API call and the server translates this into a Modbus message for communications to the PLC. When the desired information returns from the PLC to the OPC server, it then translates that back to OPC for transmission to the HMI.