OLE for Process Control

OLE for Process Control ( OPC) was the original name for standardized software interfaces, which should enable the exchange of data between applications of different manufacturers in the automation industry. Due to the progressive development of these interfaces and the concomitant decrease in the relevance of the OLE object system is now only the designation OPC, without referring to an acronym used. The current generation of OPC called OPC UA (OPC Unified Architecture).

Formation

OPC is an attempt to give industrial bus systems and protocols, a universal way of communication. Was created by the standard of the OPC Task Force, a consortium of several major companies in the automation industry such as Fisher -Rosemount, Intellution and Siemens after it was realized how much effort had caused the adaptation of numerous manufacturers standards to individual control and monitoring infrastructure.

Shortly after the release of the OPC Specification Version 1.0, the OPC Foundation was established in August 1996, which is responsible today for the maintenance and dissemination of standards. Now you belong 448 (as of: January 8, 2008) in companies.

Today, OPC is the standard for multivendor communication in automation technology. The certification of software OPC Compliance Test, which is made ​​available to the OPC - free to members, ensures compatibility. The manufacturer of OPC servers can use it to test their server during development. This software tests the complete OPC functionality, simulated misconduct of a client and checked all the error codes. In addition, even logical testing, stress and performance testing to be performed. This series of tests covers more tests than can be achieved with a normal client. After passing the test, the manufacturer may send the results to the OPC Foundation and received the certificate Compliance Tested. It is advisable to buy only servers that have this certificate.

Area of ​​application

OPC is used, where sensors, controllers and controllers from different manufacturers form a common, flexible network. Without OPC, two devices that are needed to exchange data precise knowledge about the communication possibilities of the opponent. Extensions and exchange design accordingly difficult. With OPC, it is sufficient to write for each device only once an OPC - compliant driver. Ideally, this is already provided by the manufacturer. An OPC driver can be integrated without any major adaptation work in any size control and monitoring systems.

OPC is divided into several sub- standards that can be implemented independently for the respective application. OPC can thus be used for real- time data ( monitoring), data archiving, alarm messages and now also directly to control ( command transmission ).

Specifications

OPC is divided into the following specifications:

  • OPC DA (Data Access ) specification for the transmission of real-time values ​​via OPC (DCOM -based). Current state of the specification is 3.0. OPC DA was the first OPC specification.
  • OPC A / E ( Alarms and Events ): Specification for transmission of alarms and events ( Alarms & Events ).
  • OPC HDA ( Historical Data Access ) specification for the transmission of historical values ​​.
  • OPC Command: Specification for executing commands ( commands = ).
  • OPC XML DA: Specification for XML-based transmission of real- time values. This specification is the precursor of OPC UA. Since it was early known that a DCOM - independent specifications in the form of OPC UA is planned, OPC XML DA server widespread low.
  • OPC UA ( Unified Architecture ), a specification should implement all previous specifications (OPC DA, OPC HDA, OPC A / E) platform and DCOM independent. The core elements of this specification were adopted in early 2009 for a final vote as an IEC standard (IEC 62541 ). Only the event models for " OPC UA Alarms" and " OPC UA Discovery " are so far ahead as a concept.

Operation

For communication between the OPC applications currently used mainly Microsoft's DCOM technology ( Distributed Component Object Model). Thanks DCOM it is transparent for OPC applications, whether the exchanged via OPC data from an application in its own address space, a third party, local process or from a remotely via TCP / IP -connected computers are used. The transfer and access speeds are doing DCOM usual barely slowed down by unnecessary bureaucracy. The communication paths are shown in the following image:

DCOM makes other applications (compiled ) functions and objects accessible. The OPC standard now defines certain DCOM objects, that is, the features / interfaces that must be provided ( via DCOM ) available to an OPC participants to exchange data with other OPC applications. The data necessary for an implementation of exact specifications can be freely downloaded on the side of the OPC Foundation.

The least available on the market OPC server and OPC client are certified by the OPC Foundation, as this process costs money. The largest cost is the annual membership fee to the OPC Foundation. The tool for laboratory certification of an OPC Server is available free of charge as part of the membership. The list of certified servers / clients can be found on the side of the OPC Foundation. To debug the communication between client and server, there is free software that installs itself as a sniffer between the communication partners.

With OPC XML -DA, the first web - based interface was created. The functionality is similar to the normal data access interface, which is the first and still most important interface in OPC. With the web OPC is also available on other platforms such as Linux. With Web services toolkits such as gSOAP, Easy Soap , Qt, etc. for C / C or Java you can very quickly develop OPC XML -DA client and server. Many manufacturers of OPC servers have emerged as a first step adapter which simply reflect the OPC XML -DA calls on the existing COM OPC DA server. Unlike DCOM use web port 80 (HTTP ), which also makes it easier to communicate through firewalls or to tunnel traffic (SSH).

OPC Unified Architecture describes a new generation of OPC servers. This specification is still in development and is the specifications previously developed Data Access, Alarms & Events, Historical Data Access, Data eXchange, Batch and Security unify. There will be only one address space with objects that contain values ​​, send alerts, have a history and can be interconnected as in DX. The hitherto quite different browse interfaces are replaced by a single browsing. This new specification does not describe a more COM interface, but rather a WSDL (Web Services Description Language ), which can be reacted according to the COM and various web service protocols, whereby the portability is ensured. Also, is amplified placed on scalability and security value.

Criticisms

OPC is based (with a few specifications) on Microsoft's DCOM specification. A communication through the firewall boundaries or domains is possible in the best case using a so-called OPC - tunnel. These software products convert the OPC communication in "normal" TCP / IP communication to, transport them over the net and walk in the target machine again in the TCP OPC communication to. This considerably simplifies the overall configuration.

However, OPC can also without OPC tunnel communicate through routers and firewalls, even if not on the server and client in the same domain. Authentication is performed using the local user table. Disadvantage: These on both devices ( server and client), an identical local user must exist under which the OPC and DCOM communications are handled (server and client have to run as that user ). Also, the password must be identical. This turns out in many scenarios, however, be extremely impractical.

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

Object Linking and Embedding Stress testing Secure Shell Fieldbus BACnet
616224
de