UA Bundle SDK .NET  2.4.2.373
 All Classes Namespaces Functions Variables Enumerations Enumerator Properties Events Modules Pages
Motivation for OPC UA

The first and still most successful Classic OPC standard—OPC Data Access—was designed as interface to communication drivers, allowing a standardized read and write access to current data in automation devices. The major use case was HMI and SCADA systems accessing data from different types of automation hardware and devices from different vendors using one defined software interface supplied by the hardware vendor. Standards following later like OPC Alarm & Events and OPC Historical Data Access were also designed to access information provided by SCADA systems.

With the successful adoption of OPC in thousands of products, OPC is used today as standardized interface between automation systems in different levels of the automation pyramid. It is even used in a lot of areas where it was not designed for, and there are many more areas where manufacturers want to use a standard like OPC but are not able to use it because of the COM dependency of OPC or because of the limitations for remote access using DCOM.

OPC XML-DA was the first approach of the OPC Foundation to maintain successful features of OPC but to use a vendor and platform neutral communication infrastructure. There are several reasons why just creating Web Service versions of the successful OPC specification did not cover the requirements for a new OPC generation. One reason was the poor performance of XML Web Service compared with original COM version. Furthermore, using different XML Web Service stacks caused interoperability problems.

But besides the issue of platform independence, the OPC member companies brought forward the requirement to expose complex data and complex systems, removing the limitations of Classic OPC.

The OPC Unified Architecture was born out of the desire to create a true replacement for all existing COM-based specifications without losing any features or performance. Additionally it must cover all requirements for platform-independent system interfaces with rich and extensible modeling capabilities being able to describe also complex systems. The wide range of applications where OPC is used requires scalability from embedded systems across SCADA and DCS up to MES and ERP systems. The most important requirements for OPC UA are

  • Communication between distributed systems
    • Reliability by
      • Robustness and fault tolerance
      • Redundancy
    • Platform-independence
    • Scalability
    • High performance
    • Internet and firewalls
    • Security and access control
    • Interoperability
  • Modeling Data
    • Common model for all OPC data
    • Object-oriented
    • Extensible type system
    • Meta information
    • Complex data and methods
    • Scalability from simple to complexmodels
    • Abstract base model
    • Base for other standard data models

The requirements can be grouped into the ones for the communication between distributed systems being able to exchange information and the requirements for modeling of data describing a system and the available information.

Classic OPC was designed as device driver interface. OPC is used as system interface today; therefore, the reliability for the communication between distributed systems is very important. Since network communication is not reliable by definition, robustness and fault-tolerance are the important requirement, including redundancy for high availability. Platform-independence and scalability is necessary to be able to integrate OPC interfaces directly into the systems running on many different platforms. To replace proprietary communication, an important requirement is always high-performance in intranet environments. But also internet communication through firewalls must be possible out of the box, which makes security and access control another important requirement. And first and foremost the interoperability between systems from different vendors is still the most important requirement.

Modeling of data was very limited in Classic OPC and needed to be enhanced by providing a common, object-oriented model for all OPC data. This model must include an extensible type system to be able to offer meta information and to describe also complex systems. The availability of methods provided and described by servers and callable by clients is a powerful feature needed to make OPC flexible and extensible. Complex data is required to support the description and consistent transport of complex data structures. It was an important requirement to enhance the modeling capabilities, but it was equally important to support simple models with simple concepts. For this reason it is required to have a simple and abstract but extensible base model to be able to scale from simple to complex models.

In addition to the functional requirements for a new OPC generation, the initial group of over 40 representatives defining the requirements and use cases for OPC Unified Architecture was not only composed of OPC members. Other standardization organizations like IEC and ISA interested in using OPC as transport mechanism for their information were involved in the early design process. In this group the OPC Foundation defines HOW to describe and transport data, and the collaborating organizations define WHAT data they want to describe and transport depending on their information model.

Another important design goal was to allow an easy migration to OPC Unified Architecture to protect the investment in the very successful Classic OPC standards and to build upon the large installed base of OPC.

To continue the OPC introduction you can read Introduction to OPC UA.