The OPC Connection

With all the expanded connectivity that the new OPC UA offers, expect a sharp increase in OPC’s penetration of plants, says Randy Kondor.

OPC UA (Unified Architecture) represents the OPC Foundation’s most recent set of specifications for process control and automation system interconnectivity known as OPC, an industrial communication standard that enables manufacturers to use data to optimize production, make operation decisions quickly and generate reports.

OPC UA unifies the existing OPC specifications. It enables plants to replace the existing reliance on DCOM with web services. It also introduces the concept of objects, which enables people, in a range of roles at the plant, to access the same data in different ways. This enables them to produce a variety of reports and analytical calculations without having to cobble together data from many different sources.

When OPC was first released in 1996 it was an acronym for “OLE for Process Control”, and was restricted to the Windows operating system. OPC is now available on other operating systems and enjoys significant adoption outside of process control. So, the original name (OLE for Process Control) is no longer appropriate and OPC changed from an acronym to a word. Thus, OPC no longer stands for anything (OPC is just OPC).

OPC enables plants to automate the transfer of data from a control system (PLC, DCS, analyzer, etc) to an industrial software application (HMI, Historian, Production system, Management system, etc). OPC is typically found in Level 3 networks and higher.

Thus, OPC transfers process control data between the Control (Level 2) network and the Operations/ Manufacturing (Level 3) network. It also exchanges data between the Operations/Manufacturing network and the Business (Level 4) network.

Instead of DCOM (see below), OPC UA relies on web services for its data transportation. OPC UA also uses objects to help with data description. Even though these are major additions and modification to OPC, OPC UA will be backwards compatible with older products through the use of “wrappers”.

All this will ensure that OPC UA will be even better suited to penetrate the entire plant enterprise. With all the new connectivity that OPC UA offers, one new challenge, however, will be system security.

Starting with DCOM

The first form of OPC – OPC Data Access 1.0 (OPC DA 1.0) – used Microsoft’s DCOM as the data transportation mechanism. Data moved between OPC applications on different computers using DCOM. At the time, DCOM was an outstanding choice because it provided a working communication infrastructure complete with all the necessary security services (authentication, authorization, and encryption).

Thousands of vendors were already using DCOM because it was a relatively versatile API (application programming interface). DCOM was a clear winner at the time, but while it provided a reliable communication backbone for OPC, it did have several challenges.

First, DCOM configuration eludes automation personnel who do not take time to learn it. DCOM is actually very predictable and not difficult to configure. While there are training classes that explain DCOM configuration in detail, most people do not take the time to learn it and so DCOM’s behavior frustrates them. Consequently, automation personnel needlessly experience problems when connecting two computers and configuring firewalls. Nevertheless, knowledgeable users can easily configure DCOM in a matter of minutes.

Second, many programmers assume that network communication will occur without any data loss. This assumption leads them to create products that are highly susceptible to data loss and communication timeouts. As a result, end-users might sometimes experience a delay in application responses and complain to their vendors.

However, since the programmers fail to understand DCOM’s behavior, they often incorrectly blame DCOM for poor application behavior, which further promotes the false myth that DCOM is unreliable. Again, informed programmers are easily able to compensate for data loss and are able to make DCOM work reliably, and in a way that end-users would expect.

The third problem is DCOM does not work through NAT (network address translation). Thus, DCOM fails in the rare cases that communication must occur between two private networks that are separated by a public network. Such is the case when two plants attempt communication over the internet. NAT is sometimes used inside industrial facilities, but this is often unnecessary as a firewall would suffice.

The fourth problem is DCOM is proprietary to Microsoft. This makes OPC difficult (to impossible) for vendors to port to non-Windows operating systems. While some vendors are able to embed Windows directly on their own controller (PLC, DCS, analyzer, etc) hardware, others are unable to do this. Also, companies that use non- Windows operating systems (UNIX/Linux, VMS, etc) are having a difficult time importing OPC data into their applications.

Enter web services

OPC UA uses web services instead of DCOM for data transportation. This is the change that most end-users will notice immediately. Two of the biggest advantages for web services are ease of communication between networks and independence from specific operating systems. The challenge for the plant itself will be the implementation of security to keep the data safe.

Perhaps the biggest technical advantage for web services is that they enable OPC to communicate over a single port using a protocol that most firewalls will allow to pass by default. This should make it easier for integrators to setup a system for communication between networks. Many firewalls are already configured to let web traffic pass across port 80, and so IT can open the ports necessary to implement OPC communication.

Previously, DCOM required multiple ports to establish communication. While this was possible to configure, a significant portion of automation personnel did not take the time to learn how to do it. Nevertheless, opening port 80 opens communication for a plethora of applications (not just those that are needed for operations), so emphasis on security will be required immediately.

Since web services are not bound to any specific operating system, vendors will have an easier time implementing OPC servers on their automation hardware and non-Windows operating systems. In fact, vendors are already working on PLCs that include an embedded native OPC Server that does not require anexternal computer.

However, this implementation might not be as simple as it seems because an automation application (HMI, Historian, APC, etc) typically requires a PC anyway. Nevertheless, it would be possible to have a PLC communicate with a software application using OPC without requiring an intermediate computer that uses Windows.

Object orientation

Classic OPC has a fairly simple data model, with each of the OPC specifications handling a different aspect of the data. For example, the OPC DA (Data Access) specification communicates real-time values; the OPC HDA (Historical Data Access) specification communicates archived values; and the OPC A&E (Alarms and Events) specification communicates various process and system events – such as a temperature that exceeds a pre-specified limit).

In addition, classic OPC implements each specification separately; essentially in a different executable. Thus, it is time-consuming for people to match item names with real-time data and item names with historical data. Even worse, automated applications may not be able to do it at all.

In contrast, OPC UA provides a unified data model. Thus, when an application uses OPC UA to send, say, a temperature reading, the receiver is able to retrieve the real-time value, any associated historical values, and even alarms and events. All this data is available from pointing at a single OPC item. The OPC server is able to associate all the data together so that the OPC client does not need to redo the association work.

In DCOM-based OPC, an end-user interested in a pressure reading would have had to point to the OPC DA server to look at the real-time value; point to an OPC HDA server to trend the pressure over the past shift; and if they wanted to take a look at associated events, they would have to point to the OPC A&E server.

But with OPC UA, the end-user can simply point to a pressure reading, view its real-time value, look at the past shift’s trend (historical data), and view all the associated events by connecting to a single OPC UA server.

OPC UA also provides the ability to create more complex objects. For example, one could create a pump that is composed of various temperature, level, pressure, flow, and vibration readings. Included would be the history of all values as well as a picture of the pump. One could even associate P&ID schematic diagrams and maintenance orders. This presents a powerful mechanism for integrators from various companies to share data without having to recreate it in their different proprietary software applications.

Updated features

As OPC evolved over the years, the OPC Foundation provided constant updates and improvements to the specifications. OPC UA continues this tradition. After consulting end-users, integrators, and vendors, the OPC Foundation decided on various additions to the specifications to handle the most common challenges, which is why OPC UA includes mechanisms to quickly inform users of broken communication, identify lost data, and even provide for redundancy.

OPC UA uses a poll-report-by-exception mechanism, i.e. the OPC client polls the OPC server for changes, which in turn responds with any data changes. A failure to respond would immediately tell the OPC client that the communication is no longer active. In addition, updates can come as quickly as the polling itself. However, unlike common protocols that must poll each point individually and consume precious bandwidth, OPC UA enables the OPC server to respond with any data that changed.

Thus a single efficient poll can bring back a large amount of data that includes all the changes in the process as well as the health of the OPC server itself. By contrast, before OPC UA, DCOM communication sent all changes to the OPC client by exception. Thus, an OPC client did not have to poll the OPC server periodically.

While this was efficient, many programmers overlooked the possibility that no updates would be received when communication breaks. As a result, the OPC client would wait for updates that would never arrive. Various companies overcame these difficulties, but some did not and blamed DCOM instead.

OPC UA also enables an easier implementation of redundancy. OPC UA servers can update a set of clients. By contrast, DCOMbased OPC servers could only update OPC clients that explicitly subscribed to the data. In addition, since the OPC client can easily tell when communication with an OPC server fails (as above), the OPC client can now quickly failover to a standby OPC server. In DCOM-based implementations, most vendors relied on third-party OPC redundancy applications that cost them additional funds.

Creating compatibility

The OPC Foundation has promised to supply the industry with two simple software applications that will enable people to quickly convert their DCOM-based OPC products to OPC UA. These software applications, called “wrappers”, will ensure that any new OPC UA product will communicate with an existing DCOM-based OPC product.

As a result, there is no need to contemplate whether or not one should wait for OPC UA products, since DCOM-based OPC products can continue to be implemented today and future OPC UA products will communicate with the old software. Using wrappers will ease the transition from the old to the new technology.

Two wrappers will be available: one for OPC clients and the other for OPC servers. The first wrapper will convert a DCOMbased OPC server to an OPC UA server. Thus, an OPC UA client will be able to connect to the existing DCOM-based OPC server without any changes. The second wrapper will convert a DCOMbased OPC client to an OPC UA client. So an existing DCOMbased OPC Client application (such as an HMI) will be able to communicate with an OPC UA Server that could be purchased a year from now.

Wrappers will also tunnel OPC to places where DCOM-based OPC can’t penetrate on its own. For example, when an OPC client and server are separated by NAT (network address translation), DCOM cannot make the connection. However, by converting the DCOM-based call to OPC UA at the source, and converting it back from OPC UA to DCOM at the destination, the call will transport the required data. Tunneling will likely be the first form of OPC UA implementation as OPC UA products begin to emerge.

Security challenge

OPC UA introduces an object model to industrial data, and web services will enable the OPC applications to transport the data across firewalls, networks, and the internet. And plant-floor data will finally find its way to the Business LAN and enable a variety of applications to benefit from the newly available data.

Hence an HMI will be able to pass equipment events to the maintenance system; an historian will be able to pass calculations to various engineering systems; and inventory management systems will be easily able to obtain production figures directly from automation equipment.

And a CMMS (computer maintenance management systems) or EAMS (enterprise asset management systems) such as Maximo, Indus, IFS, and Ivara will be able to obtain equipment condition data so they can implement a CBM (conditions based maintenance) program. And ERP applications such as SAP, and Oracle will be able to obtain inventory information, or even send production orders without any manual intervention.

But because OPC UA makes it relatively easy for a multitude of applications to connect with each other, the new challenge for automation personnel will be to secure their systems from the unwanted connections from people and applications that will become far more common.

However, importantly, unlike IT systems, automation systems are responsible for plant production and safety, therefore, security should quickly rise to the forefront. Automation personnel will have to learn how to secure their systems in a way that still enables them to provide access to those who need it.

It remains to be seen how vendors will enable their applications with the three pillars of secure connectivity: authentication, authorization, and encryption. Various products that are already in the planning stages still do not include the necessary facilities for proper security. These applications use “security by obscurity,” which essentially relies on a hacker’s inability to understand how a system works to make it behave inappropriately. Both process and attitudes toward security will have to change.

While there will certainly be a challenge for companies implementing OPC UA in ensuring their data is secure from unauthorized access, given all the promise that OPC UA holds, most industries will experience a sharp increase in OPC’s penetration of their plants.

-------------------------------------------------------------------

Bridging the Engineering-IT Divide

OPC can help establish common ground and reduce friction between two traditional ‘enemies’ in the plant.

Engineering and IT (information technology) evaluate and respond to computer system issues in ways that are repeatedly at odds. Nowhere is this more evident and disruptive than in plant process control and automation. Regular dust-ups between the two camps on the shop floor reveal characteristics and approaches that are strikingly dissimilar on both career and personal levels.

One suspects the other of holding different values and approaches to life and work, or at least of “just not getting it”. Their adversarial positions are not only deeply rooted; they are actually growing daily as the respective responsibilities of Engineering and IT concerning control and security straddle both their worlds. In truth, what they are not getting is each other’s perspective.

The age of the two professions is actually symbolic of these dissimilarities. Engineering is a mature profession, whereas IT is a young calling. The continuous bickering hints accurately at a generation gap. Give or take a leap year, engineers are predominantly the Baby Boomers, while Generation X dominates the IT world. Many engineers began their careers while the IT guys were learning the alphabet.

Differences in work-ethic, company loyalty, terminology, spending habits, and general approach to life itself make each generation shake its head in disbelief. “They just don’t get it,” each says of the other. While not the key drivers of conflict, this describes the two vehicles on collision course and the point of impact is the intersection of Control and Security.

Automation altercations

In years gone by the roles of IT and Engineering were clearly identified. IT presided over the business computers and networks. These were based on standard architectures and standard equipment that were available from a variety of vendors. On the other hand, Engineering controlled the systems for automation and control, which were typically propriety in nature.

Nowadays, the domains of both have become intertwined and the lines are blurred because PCs have successfully infiltrated the automation world. In addition, as economic forces compel corporations to increase efficiency, more information must seamlessly pass between the business and automation networks.Suddenly, Engineering must work with IT to set up standardsbased networks, computers, and operating systems.

Business networks abound with users (people), and network resources (printers, drives, faxes, computers, etc). Consequently, information security is one of IT’s key foundations. Imagine the commotion when an unauthorized person receives access to the CEO’s email. IT has nightmares about this. So IT systems have implemented security that limits people’s access to information based on various parameters, such as their user accounts, passwords, positions, physical locations, etc. Accordingly, the attitude of IT is typically to lock down information from everyone and then provide it only when absolutely necessary.

On the other hand, the engineer’s automation networks are traditionally far smaller, with only a few trusted users, who use proprietary systems. Engineers could easily achieve protection from the outside world with “security by obscurity”. So they would typically provide access to everyone and not worry about individual user access. But as standards-based hardware, firmware, and software have successfully penetrated automation systems, it has become easier to access production information thus elevating concerns about information access security.

Call the helpdesk?

Of course, standards-based systems come with built-in security features that are turned on by default. Indeed, engineers must now ensure that their plant networks are protected and compliant with federal, industrial, or even company cyber-security regulations and requirements. Engineers, who typically lack the cyber-security training, must configure security whether they like it or not. After struggling in vain they give up and grudgingly call IT for help. IT rolls its eyes: “Engineers! They just don’t get it.” More conflict.

As IT is called in to the cyber-security rescue, they treat the automation networks as they would their business networks, since they lack plant-floor production environment knowledge. Dynamic addressing (meant for large networks) wreaks havoc in the pedantic automation world where the network topology remains static for years. And frequent reboots (typical for PCs and Windows) have devastating effects in real-time systems built for 24x7 production. “Don’t worry,” says the newly minted IT kid who is used to his transactional systems in the business world. “It’s just like email,” they add, “you’ll catch up!”

But of course, if production data is not captured in real-time it is gone forever. If the PC was rebooting at 2:00 am during an automated patch update, it will stop collecting data. Never again will anyone know what the vessel pressure was at 2:03 am just before the turbine shutdown. Did the relief valve open because the turbine stopped or was it the other way around? What was the root-cause? How can we conduct our post-mortem analysis? Who is responsible for the five hours of lost downtime? How can we ensure this doesn’t happen again? The engineer shakes his head: “IT! They just don’t get it.”

When control and security concerns overlap and the two sides disagree, they are often not even aware enough of one another’s perspective problems to be equipped to ask investigative questions. The bone of contention is frequently related to the systems they supervise: Engineering in production, and IT in business.

IT personnel know how to set up secure systems that are built with authentication, authorization, and encryption in mind. They are able to capture information on who, where, when, and why anyone was accessing systems to determine what happened in the event of a problem.

Engineers, on the other hand, understand the unique requirements of real-time systems as they affect operations and production. At the point where they converge, Engineering and IT find conflict and their lack of cooperation adversely affects the entire enterprise.

Crossing over

Driven by technology, the IT-Engineering convergence continues to affect control and security systems where they overlap. The contentious and disputed area of intersection between Engineering and IT is also where OPC lives and works.

OPC is a global industrial connectivity standard that enables process control and manufacturing applications to communicate with each other using an interoperable, reliable, and secure connection. OPC is meant to provide the bridge between IT security concerns and systems engineering requirements for realtime process control and automation.

The key to make these systems interoperate is to teach IT personnel and engineers how to speak each other’s language. They must learn the key TLAs (three letter acronyms) to transform misunderstandings into meaningful and productive conversations.

Employee frustration destroys communication and builds information silos. It is possible to turn people and relationships around completely once they begin to understand each other. The result is a united assault on the problem, not on one another. There is no doubt that Engineering and IT can finally be on the same page in security, process control, and automation. I see this on a regular basis. It is cool to see that look of “Ah-ha! I get it now. And I see you understand too.”

-------------------------------------------------------------------

Randy Kondor is President of the OPC Training Institute (wwwopcti.com), the world’s largest OPC training company.