This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
OPC Unified Architecture (OPC UA) is a machine to machine communication protocol for industrial automation developed by the OPC Foundation. Distinguishing characteristics are:
Although developed by the same organization, OPC UA differs significantly from its predecessor, Open Platform Communications (OPC). The Foundation's goal for OPC UA was to provide a path forward from the original OPC communications model (namely the Microsoft Windows-only process exchange COM/DCOM) that would better meet the emerging needs of industrial automation.
After more than three years of specification work and another year for a prototype implementation, the first version of the Unified Architecture was released in 2006.
The current version of the specification is on 1.04 (22 Nov 2017). The new version of OPC UA now has added publish/subscribe in addition to the client/server communications infrastructure.
Although the original binding to COM/DCOM helped OPC to distribute well, it had several drawbacks:
These drawbacks along with a number of other considerations pushed the decision to develop a new and independent stack for OPC UA, which replaces COM/DCOM. The main characteristics of this communication stack were:
This communication stack reflects the beginning of various innovations. The OPC UA architecture is a service-oriented architecture (SOA) and is based on different logical levels.
OPC Base Services are abstract method descriptions, which are protocol independent and provide the basis for OPC UA functionality. The transport layer puts these methods into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented.
The OPC information model is a so-called Full Mesh Network based on nodes. These nodes can include any kind of meta information, and are similar to the objects of object-oriented programming (OOP). A node can have attributes for read access (DA, HDA), methods that can be called (Commands), and triggered events that can be transmitted (AE, DataAccess, DataChange). Nodes hold process data as well all other types of metadata. The OPC namespace contains the type model.
Client software can verify what Profiles a server supports. This is necessary to obtain information, if a server only supports DA functionality or additionally AE, HDA, etc. Additionally, information can be obtained about whether a server supports a given profile. New and important features of OPC UA are:
At the OPC UA DevCon in October 2006 in Munich the first prototypes were presented live. Various UA Servers have been shown on a Beckhoff programmable logic controller and an embedded test board from Euros. The Beckhoff PLC is based on Windows XP Embedded and the embedded controller is based on the real-time operating system Euros. The company Embedded Labs Ltd demonstrated an OPC UA Server based on their own C++ UA Stack executing on a single chip ARM microcontroller with 64kB RAM. In October 2012 the German Fraunhofer-Application Center IOSB-INA and the Institute for industrial Information Technologies (inIT) showed that an OPC UA server is scalable down to 15 kB RAM and 10 kB ROM and therefore usable at chip level.
OPC UA supports two protocols. http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.This is visible to application programmers only via changes to the URL. The binary protocol is opc.tcp://Server and
The binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, SOAP and HTTP required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall.
The Web Service (SOAP) protocol is best supported from available tools, e.g., from Java or .NET environments, and is firewall-friendly, using standard HTTP(S) ports.
Binary is supported by all implementations, while only .NET implementation supports SOAP.
The OPC UA specification is a multi-part specification and consists of the following parts:
In contrast to the COM-based specifications, the UA specifications are not pure application specifications. They describe typically UA internal mechanisms, which get handled through the communication stack and are normally only of interest for those that port a stack to a specific target or those that want to implement their own UA stack.
The OPC UA application developers code against the OPC UA API and therefore mainly use API documentation. Nevertheless, part 3, 4, and 5 may be of interest for application developers.
The OPC UA protocol specification consists of 14 documents for a total of 1250 pages. Due to this complexity, existing implementations are usually incomplete. In addition, the existence of several serialization formats, as well as the possibility of selectively implementing certain services such as PubSub, eventually lead to a great heterogeneity of the OPC UA connection points. Under these conditions, it is finally difficult to develop client applications that are independent of the specific implementation of each server. In this sense, OPC UA does not achieve its promise of ensuring good interoperability of systems. This can be seen typically in factory and infrastructure projects integrating various PLC technologies, each delivered with a different and limited implementation of the OPC UA protocol.
The specification is still evolving, the last specification document volume 14 is dated February 6, 2018, while the first publication of the standard OPC UA dates from 2006.
As a result, despite considerable marketing efforts to support its adoption, OPC UA may be considered at this stage as a standardization attempt rather than an established standard.
The architecture of a UA application, independent of whether it is the server or client part, is structured into levels.
Some parts equalize to the former COM Proxy/Stubs and get provided by the OPC Foundation. The portability level is new; it simplifies porting the UA ANSI C stack to other target platforms. A port layer for Windows and Linux is also provided by the OPC Foundation.
UA Security consists of authentication and authorization, encryption and data integrity via signatures. For Web Services the WS-SecureConversation gets used and is therefore compatible to .NET and other SOAP implementations. For the binary variant, the algorithms of WS-SecureConversation have been followed and also converted to a binary equivalent. This is named as UA Secure Conversation.
There is also a mixed version where the code is binary, but the transport layer is SOAP. This is a compromise between efficient binary coding and firewall-friendly transmission. Binary coding always requires UA Secure Conversation. The authentication uses X.509 certificates exclusively. It relies on the application developer to choose which certificate store the UA application gets bound to. For instance, it is possible to use the public key infrastructure (PKI) of an Active Directory.
The OPC UA standard defines 25 built-in data types:
|Built-in type||C/C++ equivalent||Details||NodeId type|
|Boolean||bool||0/1 (true or false)||0 (numeric)|
|SByte||int8_t||-128 to 127|
|Byte||uint8_t||0 to 255|
|Int16||int16_t||-32768 to 32767|
|UInt16||uint16_t||0 to 65535|
|Int32||int32_t||-2147483648 to 2147483647|
|UInt32||uint32_t||0 to 4294967295|
|Int64||int64_t||-9223372036854775808 to 9223372036854775807|
|UInt64||uint64_t||0 to 18446744073709551615|
|Float||float||IEEE single precision (32 bit) floating point value|
|Double||double||IEEE double precision (64 bit) floating point value|
|String||uint8_t* / std::string||3 (string)|
|DateTime||int64_t||number of 100 nanosecond intervals since 1/1/1601 (UTC)|
|GUID||implementation dependent||16-byte number used as a unique identifier||4 (GUID)|
|ByteString||(same as String)||5 (byte string)|
|XmlElement||(same as String)|
|NodeId||namespace index and NodeId type|
|ExpandedNodeId||(similar to NodeId)|
|QualifiedName||namespace index and string|
|LocalizedText||string and a locale indicator|
|NumericRange||string (e.g. "0:4,1:5" for [0..4][1..5] array)|
|Variant||(built-in data types only)|
|ExtensionObject||scalars of any type|
|DataValue||a composite of a value, timestamps and status code|
|DiagnosticInfo||detailed error/diagnostic information|
The .NET implementation uses ANSI C for the lower levels and implements the rest natively in .NET. That means only the handling of the socket and the Message-Chunking gets integrated from the ANSI C stack. De-serialization takes place directly in .NET and therefore gets converted directly into .NET structures and objects. This provides better performance than de-serializing into a C structure first and then copying the data to a .NET structure afterwards.
Various stacks for Java were being developed.[ when? ] Similar to .NET, there are principally three variants:
Alternatively, there is the simple variant to only support the WebService protocol. For that, a SOAP Toolkit that supports WS-Security is needed.
Rust for OPC UA provides an API and samples for implementing OPC UA client and servers up to embedded profile level. This includes support for encryption, subscriptions and the default node set.
Topcua is a Tcl binding to OPC UA client and server. It provides several operations to manage and communicate using the OPC UA implementation. It is available on common POSIX and Windows platforms.
IEC 62541is a standard for OPC Unified Architecture.
|IEC/TR 62541-1||2016||OPC Unified Architecture - Part 1: Overview and Concepts|
|IEC/TR 62541-2||2016||OPC Unified Architecture - Part 2: Security Model|
|IEC 62541-3||2020||OPC Unified Architecture - Part 3: Address Space Model|
|IEC 62541-4||2020||OPC Unified Architecture - Part 4: Services|
|IEC 62541-5||2020||OPC Unified Architecture - Part 5: Information Model|
|IEC 62541-6||2020||OPC Unified Architecture - Part 6: Mappings|
|IEC 62541-7||2020||OPC Unified Architecture - Part 7: Profiles|
|IEC 62541-8||2020||OPC Unified Architecture - Part 8: Data Access|
|IEC 62541-9||2020||OPC Unified Architecture - Part 9: Alarms and Conditions|
|IEC 62541-10||2020||OPC Unified Architecture - Part 10: Programs|
|IEC 62541-11||2020||OPC Unified Architecture - Part 11: Historical Access|
|IEC 62541-12||2020||OPC unified architecture - Part 12: Discovery and global services|
|IEC 62541-13||2020||OPC Unified Architecture - Part 13: Aggregates|
|IEC 62541-14||2020||OPC unified architecture - Part 14: PubSub|
|IEC 62541-100||2015||OPC Unified Architecture - Part 100: Device Interface|
In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space, which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction, typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.
In computing, serialization or serialisation is the process of translating a data structure or object state into a format that can be stored or transmitted and reconstructed later. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of object-oriented objects does not include any of their associated methods with which they were previously linked.
SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to provide extensibility, neutrality, verbosity and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) designed to facilitate the communication of systems that are deployed on diverse platforms. CORBA enables collaboration between systems on different operating systems, programming languages, and computing hardware. CORBA uses an object-oriented model although the systems that use the CORBA do not have to be object-oriented. CORBA is an example of the distributed object paradigm.
Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication between software components on networked computers. DCOM, which originally was called "Network OLE", extends Microsoft's COM, and provides the communication substrate under Microsoft's COM+ application server infrastructure.
Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.
Open Platform Communications (OPC) is a series of standards and specifications for industrial telecommunication. An industrial automation task force developed the original standard in 1996 under the name OLE for Process Control. OPC specifies the communication of real-time plant data between control devices from different manufacturers.
OPeNDAP is an acronym for "Open-source Project for a Network Data Access Protocol," an endeavor focused on enhancing the retrieval of remote, structured data through a Web-based architecture and a discipline-neutral Data Access Protocol (DAP). Widely used, especially in Earth science, the protocol is layered on HTTP, and its current specification is DAP4, though the previous DAP2 version remains broadly used. Developed and advanced by the non-profit OPeNDAP, Inc., DAP is intended to enable remote, selective data-retrieval as an easily invoked Web service. OPeNDAP, Inc. also develops and maintains zero-cost (reference) implementations of the DAP protocol in both server-side and client-side software.
The OPC Data Access Specification is the first of a group of specifications known as the OPC Classic Specifications.
This group of standards, created by the OPC Foundation, provides COM specifications for communicating data from devices and applications that provide historical data, such as databases. The specifications provides for access to raw, interpolated and aggregate data.
Inductive Automation is a supplier of web-based industrial automation software based in Folsom, California, US. The Ignition SCADA platform is the company's main product line.
Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime. The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separated from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Type conversion casting between different interfaces of an object is achieved through the
QueryInterface method. The preferred method of "inheritance" within COM is the creation of sub-objects to which method "calls" are delegated.
Sercos III is the third generation of the Sercos interface, a standardized open digital interface for the communication between industrial controls, motion devices, input/output devices (I/O), and Ethernet nodes, such as PCs. Sercos III applies the hard real-time features of the Sercos interface to Ethernet. It is based upon and conforms to the Ethernet standard. Work began on Sercos III in 2003, with vendors releasing first products supporting it in 2005.
Project Darkstar was an open-source MMOG middleware solution written in Java. Project Darkstar began as a personal project of Jeff Kesselman in 1999. It later became a research project at Sun Microsystems, and aimed to "help developers and operators avoid a range of serious, yet typical, problems associated with massive scale online games, virtual worlds, and social networking applications today, including zone overloading, data corruption, and server underutilization."
OPC is used by automation professionals for secure data transfer and process control. One OPC specification from the OPC Foundation is OPC Xi . OPC Xi defines a .NET interface with the combined functionality of OPC DA, HDA, AE and a rather simple data model. OPC Unified Architecture in comparison allows the same functionality, including a .NET interface and a similar data model to OPC DA, HDA, and AE, but also supports platform independence and optionally complex information modeling capabilities.
Avro is a row-oriented remote procedure call and data serialization framework developed within Apache's Hadoop project. It uses JSON for defining data types and protocols, and serializes data in a compact binary format. Its primary use is in Apache Hadoop, where it can provide both a serialization format for persistent data, and a wire format for communication between Hadoop nodes, and from client programs to the Hadoop services. Avro uses a schema to structure the data that is being encoded. It has two different types of schema languages; one for human editing and another which is more machine-readable based on JSON.
Ignition is an Integrated Software Platform for SCADA systems released by Inductive Automation in January 2010. It is based on an SQL Database-centric architecture. Ignition features cross platform web based deployment through Java Web Start technology. The Ignition platform has three main components: the Ignition Gateway, the Designer, and runtime clients. Independent modules provide separate functionality in any or all of the platform components. Ignition SCADA modules provide features such as: Real-Time Status Control, Alarming, Reporting, Data Acquisition, Scripting, Scheduling, MES, and Mobile support.
WAMP is a WebSocket subprotocol registered at IANA, specified to offer routed RPC and PubSub. Its design goal is to provide an open standard for soft real-time message exchange between application components and ease the creation of loosely coupled architectures based on microservices. Because of this, it is a suitable enterprise service bus (ESB), fit for developing responsive Web applications or to coordinate multiple connected devices in the IoT.