OPC Unified Architecture

The use of PC- and software-based automation systems in industrial automation rapidly increased since the early nineties. Especially, Windows-based PCs are used for visualization and control purposes. One of the major efforts for the development of standardized automation software in the past years was the access to automation data in devices where an uncountable number of different bus systems, protocols, and interfaces are used.

A similar problem for software applications did exist for the access to printers, where in old DOS days, every application needed to write its own printer drivers for all supported printers. Windows solved the printer driver problem by incorporating printer support into the operating system. This one printer driver interface served all applications that needed printer access. And these printer drivers are provided by the printer manufacturer and not by the application developers.

Since vendors of Human Machine Interface (HMI) and Supervisory Control and Data Acquisition (SCADA) software had similar problems, a task force initiated by the companies Fisher-Rosemount, Rockwell Software, Opto 22, Intellution, and Intuitive Technology was founded in 1995. The goal of the task force was to define a Plug&Play standard for device drivers providing a standardized access to automation data on Windows-based systems.

The result was the OPC Data Access specification released after short time in August 1996. The nonprofit organization that is maintaining this standard is the OPC Foundation. Nearly all vendors providing systems for industrial automation became member of the OPC Foundation. The OPC Foundation was able to define and adopt praxis relevant standards much quicker than other organizations. One of the reasons for this success was the reduction to main features and the restriction to the definition of APIs using the Microsoft Windows technologies Component Object Model (COM) and Distributed COM (DCOM). The focus on important features and the use of base Windows technologies allowed a quick adoption of the standard for the addressed use case.

As a result of the experience from product developments, multi-vendor demonstrations, and interoperability workshops, version two of the OPC Data Access specification was introduced in 1998. Based on this version, a large number of products implemented the standard. OPC Data Access version two is still the most important interface for OPC products.

The fundaments of OPC UA are data transport and information modeling. Compared to Classic OPC, the data transport was changed to state-of-the-art, platform-independent, secure, and reliable technologies and the capabilities to model information are highly improved. In Classic OPC, only “pure” data is provided, for example, the temperature measured by a temperature sensor. The only information available to understand the semantic of the provided data is the tag name and some rudimentary information like the engineering unit of the measured value. OPC UA provides more powerful possibilities exposing the semantic of the provided data. In addition to the data provided by Classic OPC, it allows exposing information like that the measured temperature is provided by a specific type of sensor device and allows to expose in a type hierarchy what kind of devices are supported. Thereby, OPC UA clients can get the information that they are dealing with the same kind of device at different places. By exposing much more semantics, OPC UA servers allow clients to process highly sophisticated tasks by interpreting the semantic of the provided data. That includes the automated integration of data provided by an OPC UA server as well as engineering an OPC UA server from a generic OPC UA client.

In Chap. 2 you learned the concepts of modeling information in OPC UA. In this chapter we will tighten your knowledge by looking at a concrete example showing how to apply the concepts. We will start with a simple scenario only exposing data similar to Classic OPC. Then we will go forward by adding type information, multiple references, etc. to demonstrate the full power of information modeling in OPC UA. This already shows a way of how to migrate existing Classic OPC applications to OPC UA with respect to the modeling. However, in Chap. 10, we talk about more details on how to migrate from Classic OPC to OPC UA.

In the example, we target an application scenario typical for Classic OPC applications. However, in the second part of this chapter we will generalize the example by looking at some general best practices on how to model information in OPC UA. In the example, we will not consider standard Information Models other than using types of the base Information Model. In Chap. 4, we will introduce standard Information Models. When modeling your information, you should consider using those Information Models and extend them rather than creating your own Information Model from scratch when this is appropriate in your domain.

The notation used in the example to expose details on the Information Model is described in Appendix A of this book. The Appendix does not only describe the notation but also discusses its relation to UML.

In this chapter, the base Information Model of OPC UA is introduced. This model provides the foundation for OPC UA information modeling and is always used as foundation to define additional Information Models. We will also look at the extensions of this model defined by the OPC UA specification. Those extensions are used to define a standard way to represent capabilities and diagnostic information of an OPC UA server in its Address Space and how specific information for current data, historical data, state machines, programs, alarms, and conditions are modeled. Depending on your application you should use those extensions (for example, in the case of Data Access) or you must use them (for example, in the case of Historical Data where it is required to provide certain information). Finally, we take a look at what standard Information Models are currently in development by other organizations based on OPC UA. Maybe there are already activities in your domain that you can use or should join.

Before looking at those standard Information Models, we start this chapter by considering how to handle standard Information Models. What is defined by an OPC-UA-based Information Model, how you can actually define such a model, and what mechanisms are built into OPC UA allowing servers and clients to work simultaneously with different Information Models?

The OPC UA Services are defining the data communication on application level. Services are methods used by an OPC UA client to access the data of the Information Model provided by an OPC UA server. Similar to Classic OPC, where the OPC specifications just defined Application Programming Interface (APIs) bet?ween applications, the Services define the communication interface between UA applications. The definition of the Services is independent of the transport protocol and the programming environment that is used to develop an OPC UA application. This is the fundamental difference to Classic OPC where the definition of the APIs was bound to a specific transport mechanism – Microsoft Component Object Model (COM).

The independence of the transport protocol and the programming environment requires an abstract definition of the Services. This abstract definition [UA Part 4] can be applied to different transport mechanisms (see Chap.6) defining the representation of the Services on the wire [UA Part 6] and to different implementations of the transport mechanisms in OPC UA Stacks (see Sect. 6.5) in different programming languages. The language specific APIs for the application development are defined by the OPC UA Stacks based on the abstract UA Service definition.

When considering developing applications it soon comes to the question which technology to use for the implementation. There are often many different technology options from which one has to be selected. In some cases it is preferable to apply a matured technology and in other cases innovation is more important. However, when developing a standard, the technology question is not easy to answer if you intend to satisfy everyone in the community. For some people performance and reliability are more important than security, for others this is vice-versa. Another issue that has to be considered for answering the technology question is what happens when a technology retires? Technologies are provided and maintained for certain platforms like operating systems. When new versions of such platforms are provided then sometimes older technologies are replaced by newer ones. The backward compatibility is thereby not always given!

In order to be open for future technologies and to provide certain interoperabi?lity between OPC UA products the working group decided to define services (see Chap. 5) and concepts in an abstract manner and to specify a technological mapping for implementation. The specified mappings address three tasks necessary for exchanging data between OPC UA applications: data encoding, securing the communication, and transporting the data. This is illustrated in Fig. 6.1. OPC UA applications in general can be separated into several functional layers. There are layers for the application logic, for accessing other components (i.e., interfaces) and there are several layers responsible for encoding, security, and transport which can be composed to a so-called stack. Stacks are mostly generic components separated from the real application since they can be reused by many other applications. Reference [UA Part 6] defines for each of the stack’s layer two technologies that can be used for implementation. However, technology evolves and additional technology mappings might be added in the future. In order to develop an OPC UA compliant product (see Chap. 12) at least one of the specified technologies for each layer has to be implemented.

The topic “security” gained a lot in importance in the automation domain in the past years although it is still very controversially discussed.

In the IT world, this topic has already been very important for a long time caused by many publications and articles about security incidents of hackers that tried to intrude into systems of banks or credit card organizations. IT-administrators feared that the same could happen to their system and CEOs feared that the customers would not trust the company anymore. Therefore companies decided to invest more money in security measures to resist those attackers. Soon people realized that not only banks and credit card organizations were affected but also any organization that is somehow dependent on distributed IT systems were affected. Excellent examples for that can be found in the field of industrial automation. Today's production processes of manufacturing companies are mostly based on IT systems. Production requests are initiated by Enterprise Resource Planning (ERP) systems, the execution of the process is managed by Manufacturing Execution Systems (MES), special HMIs used to for supervisory of the pro?cess, and the documentation of results, quality, and resource consumption are highly dependent on IT systems. And most of these systems do not act in an isolated environment anymore but have interconnections with systems from other areas within a plant, other sites of an organization or even from other organizations (e.g., supply chain). There are companies that have sites all around the world that are interconnected over the Internet. A security incident in such organizations could cause more than only a financial damage. Attacks on a chemical plant for example could also harm the environment and humans as well, which makes it to an attractive target for sabotage and terroristic activities.

When you intend to develop an application based on OPC UA you first have to think about what it should do by specifying the requirements and the functionality. Having that in mind you normally start designing the architecture of your application. Thereby certain design goals (e.g., portability, performance, or security) have to be agreed upon before first architectural concepts are developed. In this chapter, we will take a look at OPC UA from the design perspective and introduce a potential application scenario. We expect that this scenario will be applied by many application vendors. The main design goal thereby is the reuse of components and artifacts.

In this scenario, we assume that we have to develop an OPC UA client and a server. Both client and server will have application logic covering functionality tailored to concrete use cases. For example, the server has to access special data sources (e.g., data bases, devices, or other applications) or the client has to be integ?rated into another application (e.g., in a MES application). But they will also have application logic covering common functionality like managing connections, creating and processing OPC UA messages as well as securing them. Since we defined reuse as our main design goal it would make sense to separate use-case-specific and common functionality when designing the architecture. The common part can be further divided into two parts: the higher level functions like managing connections and processing Service messages and lower level functions like encoding, securing, and transmitting messages. The part providing the higher level functions can be considered as a Software Development Kit (SDK) and the part with the lower level functions can be represented by a protocol stack. The client and server applications are layered on top of the SDK.

We mentioned several times in this book that OPC UA is designed in a generic manner and can therefore be applied in a diverse range of applications running at various locations within an organization's network. Figure 9.1 shows an example of an environment in which OPC UA is used in various ways. In this scenario, OPC UA servers are running on controllers of the Control Network, on Batch systems in the Operations Network, and are applied for MES application as a part of the production planning. Furthermore, an ERP system uses an OPC UA client as an interface for consuming services in the Corporate Network. In addition, there are not only different applications involved but also different platforms. The controllers require real-time operating systems, the Batch systems as well as the MES might be Windows-based and the ERP system might be deployed on UNIX platforms. Besides the possibility to run OPC UA on different platforms, it can also be used for applying different architectural concepts at system level. In our example, several architectural concepts can be identified such as redundancy (Batch servers), server-chaining (MES and Batch), or server aggregation (Batch and OPC UA servers running on the controllers ).

The Classic OPC standard, especially the OPC DA interface, is very successful. It is implemented in more than 15,000 products and used in a huge installed base. This makes the mapping of COM based OPC interfaces to OPC UA an important task, allowing the installed base to profit from the advantages of OPC UA and to provide OPC vendors an easy migration {XE “Migration”} strategy.

OPC UA keeps the successful concepts of Classic OPC. This was an important design goal of OPC UA. It allows the mapping between OPC UA and existing standards. Classic OPC can be mapped to OPC UA without loosing information. Mapping from OPC UA to Classic OPC is possible but may lead to loss of information.

The mapping is the base for proxies and wrappers (see chap. 11) used to translate the different standards from and to OPC UA. A proxy allows Classic OPC clients to access UA server and a wrapper allows UA clients to access Classic OPC servers. But the mapping is also important for the migration of existing OPC products to OPC UA. It enables existing OPC information to be exposed with OPC UA to use the advantages of the reliable and secure communication features of OPC UA without the need to support new features. They can be added over time in an iterative development and improvement process.

Based on the experience from several projects to integrate OPC UA in existing OPC products, it is much more efficient and from a product point of view less error-prone to integrate OPC UA directly into an existing product, since the OPC DA interface hides normally information that is useful to implement OPC UA.

OPC UA provides migration strategies for different requirements and levels of OPC UA adoption. The first level does not require changes in existing products. Wrappers and proxies provided by the OPC Foundation are able to translate the different Classic OPC interfaces to OPC UA and vice-versa. This level is appropriate for integrating the installed base of OPC products and legacy products into OPC UA communication networks. This migration strategy is explained more detailed in the next sections.

For OPC product vendors, the other levels of migration are more important. The second level uses the mappings described in the previous chapter to expose the same features as in the existing products with OPC UA. This does not require any changes on internal interfaces to access information of a system exposed with Classic OPC today. The advantage over the use of wrappers is a higher performance, fewer limitations, and less maintenance efforts by avoiding an additional wrapper software layer. From a product point of view, this is not much more effort than using the integration of the wrappers. This level allows OPC products already to profit from all enhancements regarding the reliable and secure communication between distributed systems.

In an iterative development and improvement process, it is easy to add additional features supported by OPC UA. A good example is the support of the new feature Methods. For adding this feature to an OPC UA Data Access server, it is only necessary to support the Method NodeClass with the Properties to describe the input and output arguments of a Method and the Call Service to enable a client to call the provided Methods. Since OPC UA is flexible and extensible, more and more features can be added over time.

OPC UA combines the functionality of OPC DA, OPC HDA, and OPC A&E, and introduces additional features like historical Events and Methods. Not every OPC UA application will support all the functionality of OPC UA. For example, a server running on an embedded device may not provide any historical information or may even not be able to support subscriptions. Some servers are able to track changes in their Address Space, others not. The same is true for clients. For example, some clients will only deal with current data, others will only subscribe to Events. To handle OPC UA applications with different functionalities, OPC UA introduces Profiles.

Profiles define the functionality of an OPC UA application. A Profile can be used by vendors for marketing (“my product supports these features”) and as decision support for customers (“I need a product supporting these features”). To verify that an application really supports a Profile there are test cases defined for the features of a Profile. Independent testing authorities will test the applications and create signed Software Certificates for the application. Those Certificates contain information about the supported Profiles.

Profiles are not only used as human-readable announcement, but information about the supported Profiles is also exchanged between OPC UA applications. This allows applications to reject connections when their counterpart does not support required Profiles. It also illustrates the features supported by an application and allows other applications to only use those features and not try to use features that are not supported.

In the following section we will introduce the different building-blocks for Profiles and explain the different kinds of Profiles. Afterwards we will look at client- and server-related Profiles as well as transport- and security-related Profiles. Finally we will describe the certification process of how you can get signed Software Certificates.

One of the requirements for OPC UA was to maintain or even enhance the performance of Classic OPC. Performance in this context does not only mean speed of communication, it also means less load and resource requirements on the target system. It was an important lesson learned with the adoption of OPC XML-DA in embedded systems where processing XML messages was a problem for those not optimized for string handling.

OPC UA must scale from small embedded systems up to enterprise systems with different requirements regarding speed and type of transferred data. In embedded systems, where smaller pieces of data must be transferred in short time intervals, the performance and minimal system load is the most important requirement. In enterprise systems, where structured data must be processed in a transaction- and event-based manner, the efficient handling of structured data is more important than the absolute speed of data transfer. OPC UA uses different transport technologies to cover all these requirements and to ensure the scalability of OPC UA. For embedded systems and UA products used in an automation environment, the preferred transport mechanism will be the optimized UA TCP protocol with binary encoding. For enterprise systems, the preferred mechanism may be Web Services using binary or XML encoding.

There are more performance relevant aspects than only the different transport and encoding mechanisms implemented by the UA Stacks. The application layer, the integration of the application with the UA Stacks, and the way how the application layer can access the provided data has much more impact to the performance than the UA Stacks. If the data source is in a device connected via a serial link to a PC running the OPC UA server, the performance bottleneck will be always the serial connection and not the OPC UA communication.

OPC Unified Architecture (OPC UA) is the new standard for data communication in process automation and beyond, provided by the OPC Foundation. It is expected that OPC UA will replace the very successful Microsoft-DCOM-based specifications of the OPC Foundation (DA, HDA, and A&E) over the next few years as OPC UA unifies all the functions provided by those specifications. Because of its platform-independence and use of state-of-the-art Web service technology (see Chap. 6) it is expected that OPC UA will be applied in an even wider range of industries and applications, compared to Classic OPC. It can be deployed on devices, DCS, MES and ERP systems. The small set of easy-to-use services (see Chap. 5) allows accessing the unified address space in a reliable and secure manner (see Chap. 7). By using binary encoding on the wire OPC UA is a high-performance solution, significantly faster than XML data exchange (see Chap. 13).

OPC UA not only addresses data communication but also information modeling (see Chap. 2). With its rich address space model, it allows high-value metadata exposure and thus provides significantly more information than before. For this purpose, OPC UA uses object-oriented concepts and allows a full-meshed network of nodes related by multiple types of references. There is a high interest in these capabilities in many domains and there are already projects to standardize information models based on OPC UA. Examples of such activities are FDI where a common field device description is targeted and common activities with PLCopen (Industrial Control), MIMOSA (Maintenance Information – ERP and above), and S95 (Production Information – MES) (see Chap. 4).

With its profiles (see Chap. 12) OPC UA scales well from small servers to highly sophisticated systems. Small servers only providing simple functionality are able to run on limited hardware, exposing only a small set of simple data. Highly sophisticated servers are able to expose a large amount of complex information and to support complex functionality like querying the address space (see Chap. 9).

Nevertheless, some people are complaining that “Everything is so complicated” in OPC UA. Therefore, in the next section we will take a look at this objection against OPC UA. Finally, there is an outlook examining how OPC UA may be applied in the market and what is missing in it, to improve it even further.