This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
OPC Unified Architecture, with its core technology and architecture, introduces many new and improved possibilities of implementation compared to Classic OPC. The UA stack is described in detail followed by an introduction to the different UA stack variants for the different programming languages and target platforms. The implementation of UA components based on the UA stack is also elaborated. The combination of OPC Classic and OPC UA supports portability and embedding in target systems with different embedded operating systems. The most commonly used stacks variants are C/C++, .NET and Java. The Java stack is discussed in detail as Java programming language is used in android development for this project.
4.1 OPC UA Stack
An OPC UA client or server implements a wide variety of functionalities depending on the types and tasks. For example, an OPC UA client can be part of a process control system, visualization or MES application. The majority of software in these client applications is used for the graphical display, management of data, analysis of data, and for controlling different processes. OPC UA servers vary by their communication protocols used for reading and writing the data from and to the processes. The majority of software in server applications is for managing the data to be read and written, implementing and configuring the communication drivers. Both OPC UA client and server applications provide functionality that maps the data to messages for OPC UA client-server communication and prepares the data for transport. This functionality that all OPC UA components have in common is encapsulated in a set of libraries referred to as the OPC UA stack. The stack makes sure that the data is represented and transferred as OPC messages in compliance with the specification. This central core of all OPC UA clients and servers thus ensures maximum interoperability between any OPC UA components. An OPC UA stack can implement one or more stack profiles. At the interface between an OPC UA application and the stack is a (non-standardized) API that hides the details of stack contents from the OPC UA application. The API depends on the concrete development environment and programming language, such as C++, C# or Java. There are three OPC UA stack variants: ANSI, C# / .NET and Java. The interface between an OPC UA application and the stack can differ substantially from one development environment to the next; for example, in terms of data types. Java does not support unsigned integer data types. To be able to use unsigned integers in an OPC UA application, the Java API needs to translate them to integer types first.
4.2 Mapping in Layers
OPC UA communication is based on exchanging messages. The OPC UA stacks offer different security levels for securely exchanging messages between OPC UA client and server the data to be transferred is mapped as a message in a frame using the OPC UA stackââ‚¬â„¢s defined data formats, provided with security features, and transmitted/received as a telegram. The encoding of the data and its formats, the data security and the data transport have been implemented as the following three software layers in the OPC UA stack:
Data Encoding Layer
Security Protocol Layer
Transport Protocol Layer
The representation and implementation of Data Encoding, Security Protocol and Transport Protocol in a concrete technology or physical protocol is referred to as mapping.
At the Data Encoding layer, the data structures to be passed on the OPC UA stack through the server API are encoded and/or serialized as messages. The messages received are decoded/ deserialized at this software layer, converted to OPC data and methods, and exposed to the OPC UA client. UA specification defines two types of encoding:
OPC UA XML.
OPC UA Binary.
They specify how the messages are structured and how the data is encoded using the XML schema or binary schema. OPC UA Binary data encoding has been developed for areas with very demands on data throughput. As opposed to OPC UA XML where data is encoded in text format based on an XML schema, which is inefficient from a performance point of view, OPC UA binary was developed with a focus on encoding data with very little overhead. The ratio of payload to message length is correspondingly very high, which has a positive effect on the transfer factor of payload per unit of time. Another key aspect in designing OPC UA Binary was to make the encoding and decoding process very fast. Due to its high performance, OPC UA Binary is the preferred encoding for OPC UA communication links in automation. OPC UA servers that provide access to field buses, PLCs and field devices or are even embedded in intelligent devices as well as OPC UA clients that are part of a HMI/SCADA or MES application will typically implement the OPC UA Binary encoding.
The text based OPC UA XML encoding represents an OPC UA message as an XML element in a SOAP telegram. The advantages of the OPC UA XML encoding are reliability and easy processing using standard XML parsers. This is because it has been defined on basis of the generic XML specifications of World Wide Web Consortium W3C. OPC UA XML will therefore be used in applications at the enterprise level, such as Enterprise Resource Planning (ERP) systems, where the focus is less on performance aspects then on a high degree of interoperability because the W3C standards are widely used in that area. In connection with designing vertical integration concepts, there may well be applications, e.g. MES systems that have implemented OPC UA Binary for communication with underlying OPC UA servers at the factory level and, at the same time, support OPC UA XML for communication with higher-level ERP systems. Only the .NET stack comprises both encodings.
In Security Protocol layer of the OPC UA stack, there are two types of security protocols provided by OPC UA. These protocols are:
The WS-Secure Conversation protocol specifies how to secure messages that are transferred with the SOAP XML protocol. According to the WS-Security specification, all communication parties share the same order to encrypt the messages they exchange and provide a secure communication channel. For signing the XML elements in the messages and encrypting them, WS-Secure Conversation builds on the XML Signature and XML encryption specifications
OPC UA Secure Conversation is a binary derivative of WS Secure Conversation which is a binary security for communication. OPC UA Secure Conversation ensures secure communication by providing a binary transport connection. Combined with the OPC UA binary encoding, this approach achieves a much more efficient communication than WS-Secure Conversation. It has been designed for use by communication participants with limited buffers. The OPC UA messages are split up into message chunks small enough to fit into even limited data buffers .The security features derived from WS-Secure Conversation are applied to all message chunks.
The Transport Protocol layer sends the messages on the write. It serializes the data and transmits it via Ethernet using a defined protocol. Two protocols are provided as transports: The UA Binary protocol, which is a binary, TCP protocol and a Web Services (SOAP) based protocol. The API of the OPC UA stack is protocol independent and the transport protocol to be used is selected based on the URL that is passed as a parameter: opc.tcp://Server for the binary protocol and http://Server for the Web Services protocol.
4.3 OPC UA stack in three variants
The OPC Foundation provides three different implementations of the OPC UA stack:
While all APIs support the same functionality, they have different limitations depending on the programming language used. The .NET variant of the OPC UA stack is used for creating OPC UA components for the Microsoft .NET platform. The ANSI C version provides the basis primarily for applications written in C/C++. It allows designing OPC UA components with increased performance demands and reduced memory requirements.
The platform specific code is encapsulated in a separate porting layer that can be adapted to a specific platform. The Java OPC UA stack allows developing OPC UA components for Java Virtual Machine (JVM) or different operating system platforms. It has been designed specifically for use with thin clients in Web environments or enterprise software.
The Java technology was originally developed with a goal to provide a platform independent programming environment for a wide variety of network devices and embedded systems and to enable the simple development of object oriented, high performance code that can be executed on any hardware and software platform. Java consists of the software platform on which the Java code is executed which is called the Java Virtual Machine (JVM). Portability is the main feature of Java a Java program written and compiled on e.g. a Windows XP computer can be executed on any platform that has a JVM available, just write the Java code once, compile it and run it anywhere.
4.3.2 Pure Java Implementation
An OPC UA Java client or server application developer can thus bind to the pure Java Stack and rely on the fact that all OPC UA service requests and responses will be correctly serialized, secured and transported to/from OPC UA counterparts. The pure Java Stack implements all security features defined by the OPC UA specification i.e. messages may be signed or and signed encrypted. Developing OPC UA Java applications on top of the pure UA Java Stack enables true platform independence. As any Java application, an OPC UA Java client or server may be written and compiled once and ran on any platform that provides a Java Virtual Machine (JVM). The pure Java reference implementation was tested successfully on Windows XP and Linux. The pure Java Stack provides an interface for both client and server application level components to connect to. The interfaces are easy to use and provide a straightforward way to connect to the stack and to utilize services such as publishing and finding endpoints and security profiles as well as passing the various service requests and responses. The client interface enables both a blocking and a non-blocking way to initiate service requests and the server on the other hand groups the service sets and thus only leaves the implementation of the individual services to the application level code. The pure Java Stack will evenly distribute the processing responsibilities to available CPUs and thus utilize resources in an effective way. This will significantly improve the performance and decrease the latency of OPC UA applications while computing environments are moving to next generation multi core architectures.
The primary objective of OPC Unified Architecture (UA) is to provide a standard that allows servers to provide real-time process data, environment metadata and even non-process data to clients in a unique and platform-independent way. To meet this objective, each server instantiates and maintains an address Space that is a collection of information to be exposed to clients. Address Space consists of Nodes and References. The main role of the Nodes is to expose the underlying process state as a selected, well-defined piece of information. The information could be complex; therefore the Nodes can be interconnected by References to represent the Nodes relationship and, finally construct the underlining process information architecture ââ‚¬" process metadata. To create Address Space OPC UA server must instantiate all Nodes and interconnect them by means of References. Using the Nodes instances by means of a well-defined set of services clients get access to data representing the state of a selected part of the underlying process. Nodes are divided into classes.
The Variable class is used to represent the values ââ‚¬" has a Value Attribute. To be used as the real-time process state representation, the value of the Value Attribute must be bound with a real data source, e.g. an analog signal.
The Method class represents functions that can be called by the clients connected to the server. In this case the real-time process bindings are responsible for convening the Parameters current values, invoking the represented function and returning the execution result. Both classes are the main building blocks that allow the server to couple the exposed Address Space with the current state and behavior of the underlying process.
Therefore, to maintain this coupling, there must be established a connection to physical plant floor devices used to transfer real-time process data. The methods of Nodes binding with real-time process data are vendor specific. Nodes management functionality on the client part is standardized by the OPC UA Service Model as a set of services. Access to the values representing the current process state is provided by the Read/Write functions. The client can also be informed about changes of the process state using data change notifications. Invoke and event notification functionalities allow clients to use the method to implement the functionality presented above, we need to use three coupled function classes:
This diagram shows the association between the function classes mentioned above. In this archetype, the Process Link is responsible for transferring real-time process data up and down. The Nodes Management function class couples the real-time process data with appropriate Nodes instances representing process metadata and provides a homogeneous picture created this way to OPC UA Services that finally expose it to all connected clients.
Real-time process data is obtained from plant floor control devices controlling the process locally. The Process Link function class gets access to those devices using the underlying communication infrastructure and vendor specific protocols .ss