Open Platform Communications

from Wikipedia, the free encyclopedia

Originally the acronym OPC stood for OLE for Process Control and was the name for standardized software interfaces that were supposed to enable data exchange between applications from different manufacturers in automation technology. As a result of the ongoing development of these interfaces and the associated decrease in the relevance of the OLE object system, the standard was renamed Open Platform Communications in November 2011 . That is why the term OPC is mostly used today. The current specification of OPC is called OPC Unified Architecture (OPC UA).

Emergence

OPC is the attempt to give industrial bus systems and protocols a universal possibility for communication. The standard was created by the OPC Task Force, an amalgamation of various large companies in the automation industry such as Fisher-Rosemount , Intellution and Siemens , after they realized the effort involved in adapting the numerous manufacturer standards to individual control and monitoring infrastructures.

Shortly after the publication of the OPC Specification Version 1.0 in August 1996, the OPC Foundation was founded, which is responsible for the maintenance and dissemination of the standard to this day. It now includes 625 (as of October 14, 2018) companies.

Today, OPC is the standard for manufacturer-independent communication in automation technology. The certification software OPC Compliance Test , which is made available to OPC members free of charge, ensures compatibility. The manufacturers of OPC servers can use it to test their servers during development. This software tests the complete OPC functionality, simulates malfunction of a client and checks all error codes. In addition, logical tests, stress and performance tests are carried out. This series of tests covers more tests than can be achieved with a normal client. After the test has been passed, the manufacturers can send the results to the OPC Foundation and receive the Compliance Tested certificate . It is recommended that you only buy servers that have this certificate.

operation area

OPC is used where sensors, regulators and controls from different manufacturers form a common network. Without OPC, two devices required precise knowledge of the communication options of the other in order to exchange data. Extensions and exchanges are correspondingly difficult. With OPC it is sufficient to write an OPC-compliant driver exactly once for each device. Ideally, this is already provided by the manufacturer. An OPC driver can be integrated into control and monitoring systems of any size without major adjustment effort.

OPC is divided into various sub-standards that can be implemented independently of one another for the respective application. OPC can thus be used for real-time data (monitoring), data archiving, alarm messages and recently also for direct control (command transmission).

Older specifications

OPC is divided into the following specifications:

  • OPC DA (Data Access): Specification for the transmission of real-time values ​​via OPC ( DCOM based). The current state of the specification is 3.0. OPC DA was the first OPC specification.
  • OPC AE (Alarms and Events): Specification for the transmission of alarms and events (Alarms & Events).
  • OPC HDA (Historical Data Access): Specification for the transmission of historical values.
  • OPC DX (Data eXchange): Specification for direct communication between OPC servers.
  • OPC Command: Specification for the execution of commands (= commands).
  • OPC XML DA: Specification for XML-based transmission of real-time values. This specification is the forerunner of OPC UA. Since it became known early on that a DCOM-independent specification in the form of OPC UA was planned, OPC XML DA servers spread only slightly.

Current specification

The OPC Unified Architecture ( OPC UA ) specification replaces all previous specifications (OPC DA, OPC HDA, OPC A / E) regardless of platform and DCOM. The core elements of this specification were adopted in early 2009 for final coordination as the IEC standard (IEC 62541). Only the event models for "OPC UA Alarms" and "OPC UA Discovery" are still available as a concept.

So far, the specifications have only been made available to members of the OPC Foundation. In addition, it was decided in May 2015 to make the specification and certain stacks of OPC UA available to non-members as open source.

functionality

For communication between the applications, OPC currently mainly uses Microsoft's DCOM technology ( Distributed Component Object Model ) . Thanks to DCOM, it is transparent for OPC applications whether the data exchanged via OPC comes from an application in its own address space, from an external, local process or from a computer connected remotely via TCP / IP. As is customary in DCOM, the transmission and access speeds are hardly slowed down by unnecessary administrative effort. The communication paths are shown in the following figure:

Representation of the data exchange

DCOM makes (compiled) functions and objects accessible to other applications. The OPC standard now defines certain DCOM objects, i. H. the functions / interfaces that an OPC subscriber must provide (via DCOM) in order to be able to exchange data with other OPC applications. The exact specifications required for an implementation can be freely downloaded from the OPC Foundation website.

Very few OPC servers and OPC clients available on the market are certified by the OPC Foundation, as this process costs money. The largest cost block is the annual membership fee to the OPC Foundation. The tool for your own certification of an OPC server is available free of charge as part of membership. The list of certified servers / clients can be found on the OPC Foundation website. There is free software for debugging the communication between client and server, which can be used as a sniffer between the communication partners.

The first web service- based interface was created with OPC XML-DA . The functionality is similar to the normal data access interface, which is the first and still most important interface in OPC. With the web service, OPC is also available on other platforms such as B. Linux available. With web service toolkits such as gSOAP , EasySoap ++, Qt etc. for C / C ++ or Java , OPC XML-DA clients and servers can be developed very quickly. As a first step, many manufacturers of OPC servers have developed adapters which simply map OPC XML-DA calls to the existing COM OPC DA servers. In contrast to DCOM, web services use port 80 ( HTTP ), which also makes it easier to communicate through firewalls or to tunnel data traffic ( SSH ).

OPC Unified Architecture describes a new generation of OPC servers. This specification is still in development and is intended to standardize the previous specifications Data Access, Alarm & Events, Historical Data Access, Data eXchange, Batch and Security. There will only be one address space with objects that contain values, send alarms, have a history and can be interconnected as with DX. The previously quite different browse interfaces are replaced by standardized browsing. This new specification no longer describes a COM interface, but a WSDL (Web Services Description Language), which can be converted to COM and various web service protocols, which ensures portability. Increased importance is also attached to scalability and security.

Criticisms

OPC is based (apart from a few specifications) on Microsoft's DCOM specification. In the best case, communication across the boundaries of firewalls or domains is possible using so-called OPC tunnels. These software products convert the OPC communication into "normal" TCP / IP communication, transport it over the network and convert the TCP / IP communication back into OPC communication in the target computer. This makes the general configuration much easier.

However, OPC can communicate across routers and firewalls without an OPC tunnel, even if the server and client are not in the same domain. The authentication takes place via the local user table. Disadvantage: To do this, there must be an identical local user on both end devices (server and client) under which the OPC or DCOM communication is processed (server and client must run under this user). The password must also be identical. However, this proves extremely impractical in many scenarios.

Furthermore, it is useful or even necessary to restrict the DCOM communication ports; this is possible via a Windows registry entry. The number of ports required depends on the application itself.

literature

  • Frank Iwanitz, Jürgen Lange: OPC: Basics, Implementation and Use. Hüthig Verlag, Heidelberg ISBN 3-7785-2903-X .
  • Udo Enste, Jochen Müller: Data communication in the process industry. Oldenbourg Industrieverlag, ISBN 978-3-8356-3116-8 .
  • Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag, ISBN 978-3-540-68898-3 (English).

See also

Web links