Tag Archives: OPC

OPC UA Makes Process Observer Archetype Possible

Integration

Usually modern manufacturing automation systems consist of numerous different IT systems located at business management/operation and process control levels. It is a broad class of application domains where business IT and control systems are converged to make a large whole with the aim of improving performance as a result of the macro optimization and synergy effect. This domain is called Industrial IT. Frequently the systems are distributed geographically among multi-division organizations.

To deploy the above-mentioned convergence the systems have to be integrated – they must interoperate. After integration the systems should make up a consistent system, i.e. each subsystem (as a component) must communicate with the others. The final information architecture is strongly dependent on organization, culture, type of technology and target industrial process. Communication is necessary for exchanging data for production state analysis, operation actions scheduling, supervisory control and task synchronization in the process as a large whole.

To make up a consistent system as an ultimate result of the integration process the following architectures can be applied:

  • Peer to peer: manually created point-to-point links to meet short-term ad hoc objectives.
  • All in one: a product dedicated to both functions: process control and business management.
  • Process Observer: a consistent, homogenous real-time representation of the process control layer.
Process Observer

Fig. 1 Process Observer Archetype

Process Observer (Fig. 1) is a kind of a virtual layer, which is a “big picture” of the underlying process layer composed of unit data randomly accessible by means of a unified and standardized interface. It allows the process and business management systems, using international standards of data exchange to share data from plant floor devices. Process Observer is like a bridge connection between the plant-floor control and the process and business management levels.

Thereby, the structure of the links becomes systematic and the existing functionality of the upper layers is preserved. Using the Process Observer archetype the number of links between components can be substantially reduced and, what is very important it is a linear function of the number of nodes.

Now, the links can be used to gather the process data in a unified, standardized way (see fig.2).

Process Observer archetype greatly reduces the whole complexity and decreases interdependence by decoupling application associations and underlying communication routes. Additionally, it allows applying systematic design methodology and building information architecture independently of the underlying communication infrastructure.

Process Observer Deployment

Implementation

The Process Observer concept has been implemented in the CommServer™ software family. That communication server is optimized for applications in distributed process control systems. To provide a consistent sole representation of a distributed real-time process at the upper layer boundary – according to the model – the CommServer™ has to implement unique functionality, provide redundancy and optimize utilization of underlying communication infrastructure.

CommServer-Process Observer Implementation

Fig 2. CommServer-Process Observer Implementation

Functionality

Communication

To meet scalability and open connectivity requirements, the CommServer™ exposes the OPC Unified Architecture (OPC UA) to be consumed by upper layer applications. One of the main objectives of using the OPC UA is to provide a uniform bridge between digital plant-floor devices and systems providing services at the process and business management level. At the very beginning, this bridge was invented as a translator between vendor specific languages (protocols) used by the devices for data access and a widely accepted one – OPC. Therefore, each OPC UA server has to be equipped with a vendor specific component called DataProvider that implements selected protocol and communication infrastructure management functions. Popularity of the OPC UA standard grows, but still many applications do not support it. For that reason, another member of the family, DataPorter™ offers SQL and XML connectivity (Fig 2).

Process Simulation

CommServer™ does not only play the role of a translator and communication engine. Offering the possibility of creating simulators and publishing simulation data in the same way as the process data, the final process representation can be complemented by directly unavailable information obtained by processing current and historical values. To commence factory approval tests of any system, we need to build a testing environment. Using simulators instead of communication drivers, it is possible to seamlessly switch between production and test environments reducing the cost by order of magnitude.

Resource Monitoring

In a production environment, monitoring and management of the recourses that make up the information processing and communication infrastructure is often of the same importance as access to the real time process data. CommServer™ allows for publishing data gathered from the active network devices in the same way as the process data.

Server to Server Interactions

It is a scenario using interactions in which one Server acts as a Client of another Server. In the presented architecture it is implemented using a dedicated OPC Classic or OPC UA DataProvider. Server to Server interactions allow for the development of servers that: exchange data with each other on a peer -to-peer or vertical hierarchy basis to offer redundancy, aggregation, concentration or layered data access management.

3 levels of redundancy

Using the Process Observer archetype with only one common component responsible for interconnecting plant floor devices and process and business managements systems creates a single point of failure. To overcome it and eliminate the risk the proposed solution offers tree levels of redundancy to increase availability. They can be applied independently according to an appropriate analysis and assessment of the risk.

  • Hardware: To provide true fault tolerant systems redundant hardware can be used. This solution provides the same processing capacity after a failure as before. We have two options: boxes and components redundancy. The first one is achieved by using a primary server and a backup server. We can also use fault-tolerant hardware designed from the ground by building multiples of all critical components, such as CPUs, memories, disks and power supplies into the same computer in order to ensure reliability. In the event one component fails, another takes over the communication without skipping a beat. The fact of switching from one server to the other should be transparent for the clients.
  • Communication paths: To increase availability the CommServer™ assures redundancy of “data transmission paths”. It is designed to recover from a communication path failure by detecting the failed route and switching to another one if available. Paths redundancy improves robustness, because the same remote unit can be reached using different physical layers to eliminate single point failure dependency. The server is responsible for the selection of a route to transfer the data and to control availability of inactive paths. Duplication of the communication paths may be costly, because data transfer over distributed networks is usually not for free. The crucial feature of paths redundancy is the provision of the path multiplication without the necessity of transferring the same data over the network many times and controlling backup path availability at the same time.
  • Signals: For reliability, this feature allows to define replicated signals. Thus, if one signal fails, a second one is available as one OPC tag. To determine whether a fault has occurred (fault detection) and which one signal is affected (fault isolation) two methods are available: source and statistical ones. Source detection relays on information about signal quality received from a plat floor device. Statistical methods use the confidence level as an interval estimate of a population parameter.

Optimal communication

Engaging of an intermediate component as a driver for plant-floor devices is a middleware archetype used worldwide in thousands of applications.
But to provide a consistent sole representation of a distributed real-time process at the upper layer boundary – according to the model – the CommServer™ has to implement
unique features optimizing utilization of the underlying communication infrastructure:

  • Multi-Protocol Capability: many protocols can be implemented as DataProvider components and plugged-in and utilized simultaneously;
  • Multi-Medium Capability: any physical layer technology can be used to start building a communication stack;
  • Multi-Channel Connectivity: numerous independent communication routes can be activated simultaneously to gather raw process data;
  • Adaptive Retry Algorithm: each protocol retries to acquire data after a communication error, but adapting the number of retries to current conditions allows to increase greatly the whole bandwidth;
  • Adaptive Sampling Algorithm: is responsible for adjusting the plant floor devices sampling rate according to the current process state;
  • Optimal Transfer Algorithm: is responsible for minimizing the difference between the individual process data update rate as required by clients and the current sampling rate of process control units.

Related articles

OPC UA Makes Smart Utility Distribution Systems Possible

Most of us don’t give much thought to the major utilities until one or more do not work or price goes up. In Poland 15% to 20% of generated heat is lost in transit from the manufacturer (Combined Heat & Power plants) to consumers, which gives a value of hundreds of millions of euro a year for several biggest national networks. In most cases, nonrenewable conventional fossil fuel must be used up in order to produce that heat, i.e. natural resources must be depleted and the environment must be polluted.

Following the concept of smart grids, more and more companies decide to start working on smart utility distribution systems (gas, water, chilly water, or even oil) to improve the performance and availability, and enable the consumers to monitor consumption and have effect on its economical use.

An example is the heating system of Warsaw that is the largest centralized district heating system in Poland and one of the largest in the world. Through the district heating network common for the whole city area, it provides heat to almost 19 thousand buildings in Warsaw, thus satisfying ca. 80% of the demand. This municipal heating system consists of almost 1700 km of network. Power transmitted from the sources amounts to ca. 5200 MW. Ca. 10000 GWh of heat is supplied to the consumers via the heating network.

Important components of the heating system that are involved in heat transmission to the customers are (read full case study):

  • Water pumping stations
  • Consumer exchanger substation
  • Heat chambers

Generally speaking, the task of the “smart distribution” is to support all processes that will make improvement in its operational performance possible. Therefore, with the aim of optimizing processes, the solution should provide:

  • Availability management
  • Costs management

Usually the above tasks are contradictory to some extent, e.g. when minimizing the cost we cannot ignore the consumer’s needs.

Optimization is a method of determining the best (optimal) solution. It is a search for an extreme of a certain function from the point of view of a specific criterion (index) (e.g. cost, temperature, time, etc.).

The selection of the indexes depends on many factors, but in any case we need real time and historical data gathered from highly distributed process control devices (PLC, distributed I/O, meters, etc.) to provide optimal process control. In the example described above up to 500 000 values is expected to be measured for this purpose.

In order to make a design and analysis of such an elaborate system possible, it is necessary to distribute certain function groups that are logically relevant to each other, using the compound system concept. A well-defined functionality boundary must be a distinguishing feature of each system of that type. To perform their functions, those systems must communicate creating mutual links.

To fulfill the above requirements of Smart Utility Distribution Systems we need the following subsystems:

  • Optimization: supervisory and optimal control of the real-time processes
  • Telemetry: remote control and data acquisition
  • Repository: database management systems to archive process data

To make this architecture deployable and, next, maintainable some critical issues must be addressed:

  • Openness – components communication is based on a common open standard
  • Unified data access – real-time, historical and metadata must be available to all clients using a common publishing mechanism
  • Complex data – with the goal to protect data integrity, complex process data must be supported
  • Security – the strategic nature of these systems requires appropriate security protection against malicious attack
  • Internet technology – it is obvious that Internet technology must be used on the data transportation level between the systems even if we are going to build a separated private network

In my opinion, the only answer to the question how to meet these requirements is OPC Unified Architecture (OPC UA). It is a set of specifications for the development of software connected such systems as ERP, SAP, GIS, MES or process control systems. These systems are designed for information exchange and they are used for the control and supervision of real-time industrial processes. OPC UA defines the infrastructure modeling concept in order to facilitate the exchange of process data. The whole architecture of the new standard improves and extends the previous OPC (now called classic) capabilities in the field of application security, stability, event tracking and data management, thus improving interoperability of the distributed architecture components.

OPC UA permits easier cooperation and data exchange between the process control and business management layers. It is designed so as to support a wide range of devices from the lowest level with PLCs to the distributed systems dealing with IT management in an enterprise.

It is worth noting that OPC UA technology is based on services and objects. For more than one decade the software authors have been using solutions based on objects and services but those solutions have never been transferred directly to industrial applications. OPC Unified Architecture has become the first standard close to the technological process that is of a dual nature, both object oriented (Object Oriented Architecture – OOA) and service oriented (Service Oriented Architecture – SOA).

The application of the OPC Unified Architecture standard as a foundation for the proposed architecture will enable us to:

  • Standardize communication between component systems
  • Create a consistent information model that is available to all systems and illustrates the system structure
  • Create a database model (metadata) based on a OPC UA information model, thus giving applications that use Repository access not only to process data but also to metadata describing the system objects
  • Provide open solutions, i.e. the possibility of free connection of the next components in the future
  • As OPC UA is Internet technology it could be used to build even global solution

The OPC UA standard allows us to get an open, interoperable and scalable architecture, thus making the development of the infrastructure and its use for other tasks in the future possible. As the proposed architecture is based on the open connectivity standards it provides a framework for the integration of highly distributed “islands of automation” with top-level applications employing the artificial intelligence idea to optimal control of the Distribution Network as a whole.

See also

OPC UA – Specifications

Introduction

OPC Unified Architecture (OPC UA) is described in a layered set of specifications broken into parts. It is purposely described in abstract terms and only in selected parts coupled to existing technology on which software can be built. This layering is intentional and helps isolate changes in OPC UA from changes in the technology used to implement it.

The OPC UA specifications are organized as a multi-part document combined in the following sets:

  • Core specification
  • Access type specification
  • Utility specification

The first set specifies core capabilities of OPC UA. Those core capabilities define the concept and structure of the Address Space and the services that operate on it. The access type set applies those core capabilities to specific models of data access. Like in OPC Classic, there are distinguished: Data Access (DA), Alarms and Conditions (A&C) and Historical Access (HA). A new access mode is provided as a result of introducing the programs concept and aggregation mechanisms. This set also specifies the UA server discovery process. Those mechanisms are not directly dedicated to support data exchange, but play a very important role in the whole interoperability process.

The core set contains the following specifications:

  • Part 1 – Overview and Concepts: presents the concepts and overview of OPC Unified Architecture.
  • Part 2 – Security Model: describes the model for securing interactions between OPC UA clients and servers.
  • Part 3 – Address Space Model: describes an object model that servers use to expose underlying real-time processes to create an OPC UA connectivity space.
  • Part 4 – Services: specifies the services provided by OPC UA servers.
  • Part 5 – Information Model: specifies information representations – types that OPC UA servers use to expose underlying real-time processes.
  • Part 6 – Mappings: specifies transport mappings and data encodings supported by OPC UA.
  • • Part 7 – Profiles: introduces the concept of profiles and defines available profiles that are groups of services or functionality.

The access type set contains the following specifications:

  • Part 8 – Data Access: specifies the use of OPC UA for data access.
  • Part 9 – Alarms and Conditions: specifies the use of OPC UA support for accessing alarms and conditions.
  • Part 10 – Programs: specifies OPC UA support for accessing programs.
  • Part 11 – Historical Access: specifies the use of OPC UA for historical access. This access includes both historical data and historical events.

The utility specification parts contain the following specifications:

  • Part 12 – Discovery: introduces the concept of the Discovery Server and specifies how OPC UA clients and servers should interact to recognize OPC UA connectivity.
  • Part 13 – Aggregates: describes ways of aggregating data.

Overview and Concepts

This part describes the goal of OPC UA and introduces the following models to achieve it:

  • Address Space and information model to represent structure, behavior, semantics, and infrastructure of the underlying real-time system.
  • Message model to interact between applications.
  • Communication models to transfer data over the network.
  • Conformance model to guarantee interoperability between systems.
  • Security model to guarantee cyber security addressing client/server authorization, data integrity and encryption.

Security Model

This part describes the OPC UA security model. OPC UA provides countermeasures to resist threats that can be made against the environments in which OPC UA will be deployed. It describes how OPC UA relies upon other standards for security. The proposed architecture is structured in an application layer and a communication layer. Introduced security policies specify which security mechanisms are to be used. The server uses security policies to announce what mechanisms it supports and the client – to select one of those available policies to be used when establishing the connection.

Address Space

There is no doubt that information technology and process control engineering have to be integrated to benefit from macro optimization and synergy effect. To integrate them, we must make systems interoperable. It causes the necessity of exchanging information, but to exchange information, it has to be represented as computer centric (saveable in a binary memory) and transferable (a stream of bits) data. According to the specification, a set of objects that an OPC UA server makes available to clients as data representing an underlying real-time system is referred to as its Address Space. The breaking feature of the Address Space concept allows representing both real process environment and real-time process behavior – by a unique means, mutually understandable by diverse systems.

Services

The OPC UA services described in this part are a collection of abstract remote procedure calls that is to be implemented by the servers and called by the clients. The services are considered abstract because no particular implementation is defined in this part. The part Mappings describes more specific mappings supported for implementation. Separation of the service definition and implementation allows for harmonization with new emerging technologies by making new mappings.

Information Model

To make the data exposed by the Address Space mutually understandable by diverse systems, the information model part standardizes the information representation as computer centric data. To promote interoperability, the information model defines the content of the Address Space of an empty OPC UA server. This content can be used as a starting browse point to discover all information relevant to any client. Definitions provided in this part are considered abstract because they do not define any particular representation on the wire. To make the solution open for new technologies, the representation mappings are postponed to the part Mappings. The solution proposed in this model is also open to defining vendor specific representations.

Mappings

This part defines mappings between abstract definitions contained in the specification (e.g. in the parts: Information Model, Services, Security Model) and technologies that can be used to implement them. Mappings are organized into three groups: data encodings, security protocols and transport protocols. Different mappings are combined together to create stack profiles.

Profiles

This part describes the OPC UA profiles as groups of services or functionality that can be used for conformance level certification. Individual features are grouped into conformance units, which are further grouped into profiles. All OPC UA applications shall implement at least one stack profile and can only communicate with other OPC UA applications that implement the same stack profile. Servers and clients will be tested against the profiles. Servers and clients must be able to describe which of the features they support.

Data Access

This part describes the information model associated with the Data Access (DA) mode. It particularly includes an additional definition of variable types and a complementary description of Address Space objects. This part also includes additional descriptions of node classes and attributes needed for DA, as well as DA specific usage of services to access process data.

Alarms and Conditions

This part describes the representation of events and alarms in the OPC UA Address Space and introduces the concepts of condition, dialog, acknowledgeable condition, confirmable condition and alarm. To expose above information, it extends the information model defined in other parts and describes alarm specific uses of services.

Programs

This part extends the notion of methods and introduces the concept of programs as a complex, stateful functionality in a server or underlying system that can be invoked and managed by a OPC UA client. The provided definitions describe the standard representation of programs as part of the OPC Unified Architecture information model. The specific use of services is also discussed.

Historical Access

This part describes an extension of the information model associated with Historical Access (HA). It particularly includes additional and complementary definitions of the representation of historical time series data and historical event data. Additionally, this part covers HA specific usage of services to detect and access historical data and events.

Discovery

The main aim of this part is to address the discovery process that allows the clients to first find servers on the network and then find out how to connect to them. This part describes how UA clients and servers interact to exchange information on resources available on the network in different scenarios. To achieve this goal, there are introduced the concepts of a discovery server that is a placeholder of global scope information and a local discovery server, whose main task is to manage information vital to local resources. Finally, this part describes how to discover UA applications when using common directory service protocols such as UDDI and LDAP.

Aggregates

This part specifies the information model associated with aggregates and describes how to compute and return aggregates like minimum, maximum, average etc. Aggregates can be used with base (live) data as well as historical (HA) data. This part also addresses the aggregate specific usage of services.

Related articles

OPC Unified Architecture – Main Technological Features

Introduction

One of the main goals of the OPC Unified Architecture is to provide a consistent mechanism for the integration of process control and management systems. It is assumed that it should be robust and the implementation should be platform independent. In this section I will examine technologies and paradigms used as a foundation for the development of the OPC UA standard and discuss their impact on the final result.

Service Oriented Architecture

At the very beginning of a new solution development, we must address a question about its fundamental paradigms and architecture. OPC Classic is based on the functionality provided by an operating system and is actually an instruction on how to use the functionality to interconnect participants of the data exchange. This was recognized as one of the drawbacks making the lifetime of the OPC Classic standard dependent on the lifetime of the technology it is based on.

Observing continuous evolution of the IT domain, it seems that finding a solution that will guarantee an unlimited lifetime is a real challenge. However, decupling the solution from any base technology increases the chance of it surviving the disappearance of the base technology from the market. Developing services and deploying them using a Service Oriented Architecture (SOA) is the best way to utilize IT systems to meet this challenge. A service differs from an object or a procedure because it is defined by messages that it exchanges with other services. SOA defines the way in which services are deployed and managed. Using a SOA approach increases reuse, lowers overall cost, and improves the ability to rapidly change and evolve systems, whether old or new.

To make systems interoperable, any even brilliant idea is not enough. We need a data transfer technology, however – when defining data exchange in context of messages – we do not need to bother with the different technologies used by the participants as long as they can absorb the messages.

Today, an ideal platform for the SOA concept implementation is Web Service technologies. They represent the most widely adopted distributed computing standards in industry history. Web Services are a set of standards based on XML (eXtensible Markup Language) and developed by W3C (World Wide Web Consortium). Those standards are generally marked with a WS-*** symbol. Because the WS-* standards are developed without any initial assumption concerning the underlying system platform they are implemented on, they therefore must precisely define what must be on the “wire”.

The WS-* standards are the basic foundation for OPC UA but, using them alone, would not be enough to reach the expected data throughput performance in industrial applications. The OPC UA suite of protocols, therefore, expands the WS-* standards by defining a few proprietary ones that can be used alternatively. OPC UA messages may be encoded as an XML text or in binary format for efficiency purposes. They may be transferred using multiple underlying transports, for example TCP or SOAP over HTTP. Clients and servers that support multiple transports and encodings will allow end users to make decisions about tradeoffs between performance and XML Web Services compatibility at the time of deployment, rather than having these tradeoffs determined by the OPC vendor at the time of product definition.

Object Oriented Information Model

To make systems interoperable, the data transfer mechanism must be associated with a consistent information representation model. OPC UA uses an object as a fundamental notion to represent data and activity of an underlying system. The objects are placeholders of variables, events and methods and are interconnected by references. This concept is similar to well-known object oriented programming (OOP) that is a programming paradigm using “objects” – data structures consisting of fields, events and methods – and their interactions to design applications and computer programs. The OPC UA Information Model provides features such as data abstraction, encapsulation, polymorphism, and inheritance.

The OPC UA object model allows servers to provide type definitions for objects and their components. Type definitions may be abstract, and may be inherited by new types to reflect polymorphism. They may also be common or they may be system-specific. Object types may be defined by standardization organizations, vendors or end-users.

The Information Model is a very powerful concept, but it is abstract and hence, in a real environment, it must be implemented in terms of bit streams (to make information transferable) and addresses (to make information selectively available). To meet this requirement, OPC UA introduces a Node notion as an atomic addressable entity that consists of attributes (value-holders) and references (address-holders of coupled nodes). The set of Nodes that an OPC UA Server makes available to clients is referred to as its Address Space, which enables representation of both real process environment and real-time process behavior. The Address Space is described in depth in the OPC UA eBook.

Each of the previous OPC Classic specifications defined their own address space model and their own set of services. OPC UA unifies the previous models into a single integrated Address Space with a single set of services.

Abstraction and Mapping

Interoperability of systems can be achieved if communicating parties are able to interchange streams of bits and assign to these streams the same meaning without any ambiguity. Unfortunately, the representation of information on the wire, and communication protocols are subject to continuous evolution, if not revolution nowadays. This could be dangerous for any long term initiatives. Because it is impossible to stop the progress of technology changes, some other precaution must be undertaken to keep the specification alive within a long term horizon. It is achieved by clear separation of definitions provided by the specification from their actual implementation. It makes OPC UA seamlessly portable from one technology to another. Mappings defined in the specification sets forth how to implement an OPC UA feature using a specific technology. For example, the mapping for OPC UA binary encoding specifies how to serialize OPC UA data structures as sequences of bytes.

Additionally, separation of the definition and implementation makes the solution more flexible and scalable thanks to a free (to a certain degree) selection of technologies appropriate for the current communicating parties needs. Unfortunately, it may cause an adverse interoperability issues, because the interconnected systems must be able to use the same communication mechanism. This is partially overcome by the definition of profiles and negotiation mechanism.

Security

Security is a fundamental aspect of computer systems, in particular those dedicated to enterprise and process management. Especially in this kind of application, security must be robust and effective. Security infrastructure should also be flexible enough to support a variety of security policies required by different organizations. OPC UA may be deployed in diverse environments; from clients and servers residing on the same hosts, throughout hosts located on the same operation network protected by the security boundary protections that separate the operation network from external connections, up to applications running in global environments using public network infrastructure. Depending on the environment and application requirements, the communication services must provide different protections to make the solution secure, therefore OPC UA specification must offer scalability.

OPC UA Security is concerned with the authentication of clients and servers, the authorization of users, the integrity and confidentiality of their communications and the auditing of client server interactions. To meet this goal, security is integrated into all aspects of the design and implementation of OPC UA Servers and Clients. The OPC Foundation has also addressed the security issues that arise from implementation. This include independent reviews of all aspects of security starting from the design of in-depth security provided by the specification (which is built and model on the WS* specifications); to the actual implementation provided by the OPC Foundation. The OPC Foundation has chosen to use industry standard security algorithms and industry standard security libraries to implement OPC UA Security (see OPC UA eBook).

Security mechanisms can be provided by diverse communication layers. Transport-level security is a solution limited to point-to-point messaging. In this case messages can be protected by establishing a secure connection (association) between two hosts using for example Transport Layer Security (TLS) or IPSec protocols. But, if intermediaries are present when using a secure transport, the initial sender and the ultimate receiver need to trust those intermediaries to help provide end-to-end security, because each hop is secured separately. In addition, to explicit trust of all intermediaries, other risks such as local storage of messages and the potential for an intermediary to be compromised must be considered. Thus, using only transport security limits the richness of the security solution to transport-specific features. OPC UA is a session centric communication. Hence, a security association must survive beyond a single transport connection.

To meet the above requirements, the OPC UA security architecture is defined as a generic solution that allows implementation of the required security features at various places in the application architecture. The OPC UA security architecture is structured in an application layer and a communication layer atop the transport layer.

The routine work of a client application and a server application to transmit plant information, settings, and commands is done in a session in the application layer. The application layer also manages user authentication and user authorization. OPC UA Client and Server applications identify and authenticate themselves with X.509 Certificates. Clients pass a user identity token to the OPC UA Server. The OPC UA Server authenticates the user token. Applications accept tokens in any of the following three forms: username/password, an X.509v3 certificate or a WS-SecurityToken

A session in the application layer communicates over a secure channel that is created in the communication layer and relies upon it for secure communication. All of the session data is passed to the communication layer for further processing. The secure channel is responsible for messages integrity, confidentiality and applications authentication.

OPC UA uses symmetric and asymmetric encryption to protect confidentiality as a security objective. OPC UA relies upon the site cyber security management system to protect confidentiality on the network and system infrastructure, and utilizes the Public Key Infrastructure to manage keys used for symmetric and asymmetric encryption. OPC UA uses symmetric and asymmetric signatures to address integrity as a security objective.

Profiles

OPC UA is designed to support a wide range of servers, from plant-floor PLCs to enterprise servers. Those servers are characterized by a variety of sizes, performance, execution platforms and functional capabilities. Therefore, OPC UA defines a comprehensive set of capabilities, of which servers may implement a subset of. These subsets are referred to as Profiles, and servers may claim conformance to them. Clients can then discover the Profiles for a server, and tailor their interactions with that server based on the Profiles. Client also contain Profiles which allow end user the ability to match up server profiles to client profiles, making it easier to ensure that diverse client and servers will interoperate. Servers can also discover these client profiles and could tailor their response to the client based on the client profile.

Robustness

OPC UA is designed to provide robustness of published data. The major feature of all OPC UA Servers is the ability to publish data and event notifications. OPC UA provides mechanisms for clients to quickly detect and recover from communication failures associated with transfers without having to wait for long timeouts provided by the underlying protocols.

The design of OPC UA ensures that vendors can create redundant clients and redundant servers in a consistent manner. Redundancy may be used for high availability, fault tolerance and load balancing. Generally we can distinguish redundancy of: servers/clients, communication paths and signals. Although the specification provides support only for client/server redundancy, product vendors can incorporate all kinds of redundancy into the framework proposed by the specification. For example, a server can establish wireless connection as the means of recovery from cable connection failure or a server can use many data sources bound to a variable to provide continuous updating of the variable value even if one of the sensors has been damaged.

OPC UA requires a stateful model as the next feature that increases the solution robustness. State information is maintained inside an application session. Examples of state information are subscriptions, user credentials and continuation points for operations that span multiple requests.

Sessions are defined as logical connections between clients and servers. What is worth stressing, each session is independent of the underlying communications protocols. Failures of these protocols do not automatically cause the session to terminate. Sessions terminate based on a client or server request, or based on inactivity of the client.

More readings

More you can find in the eBook at:

OPC UA eBook