Tag Archives: Data Access

IoT versus SCADA/DCS Data Acquisition Patterns

Introduction

The term Internet of Things (IoT) is used in a variety of contexts where it is often misunderstood, because it can be replaced by other terms much better describing the matter we deal with or the definitions are not compliant with each other. Let me remind you about the very beginning of this term life.

That ‘Internet of Things’ Thing

The phrase “Internet of Things” started its life as the title of a presentation made in 1999 and aimed at explaining a new idea of radio frequency identification (RFID) in the context of the supply chain performance. It is clear that it doesn’t mean that someone has any right to control how others use the phrase, but my point is that a precise term definition is important for working together on: common rules, architecture, solutions, requirements, capabilities, limitations, etc. In practice having a common definition it is possible to check a selected technology, solution or product capabilities against requirements of the application entitled to use this term.

The main goal of this article is to contribute to the community work aimed to distinguish the IoT applications domain features. The main challenge faced up is to narrow the definition to make it unambiguous and meaningful.

In most publications I know the term IoT can be simply replaced with the following well-known terms:

  • SCADA – Supervisory Control and Data Acquisition
  • DCS – Distributed Control Systems

and the text still will be perfectly OK. In this context the “sensor” term plays the role of the “thing” and the nodes network is a synonym of the Internet. No one usually takes care whether we are talking about the temperature sensor in a bedroom or in a boiler drum in a power plant except that in case of a power plant sometimes the prefix Industrial is added. To make our life easier let’s forget about the “I” (Industrial) prefix at all because it doesn’t change the most important application domain features.

To illustrate the further discussion let me provide examples that can be recognized as SCADA/DCS and IoT applications respectively.

SCADA/DCS example

Let’s assume that an OPC UA Server exposes 123456 values representing the crude oil refining process. Using SCADA on top of this server we can monitor and manually control the process. Using DCS it is possible to implement a supervisory control algorithm to provide macro optimization.

For this scenario we can apply the following work-flow:

  • The server instantiates an OPC UA Information Model for the crude oil refining process.
  • All plant floor devices equipped with sensors are fetching data representing the current process state (for example the flow meter #A-4321 supporting the Modbus RTU communication protocol) and are waiting for data requests coming from the server communication engine.
  • The communication engine embedded in the server polls all plant floor devices including the flow meter #A-4321 to recover the current process state.
  • Finally, the OPC UA Server exposes the data (updates value attributes of the relevant variable nodes, e.g. #A-4321 object representing the virtual flow meter #A-4321) in his Address Space Management component (i.e. in the Address Space instantiated according to the Information Model of the crude oil refining process).
  • OPC UA Clients connected to this server are updated in a standardized way.

Note in this scenario that the OPC UA Client and OPC UA Server can establish connection over the Internet using any existing transport protocol, e.g. HTTP, HTTPS, TCP, UDP, AMQP. Selection of the transport protocol between the client and server is negotiated and limited by the OPC UA specification. To get more read OPC Unified Architecture – Main Technological Features.

You can use the server I have exposed many years ago to test this scenario. The instruction how to connect is included in the following document:

http://www.commsvr.com/Products/OPCUA/OPCUAServers/OPCUAADIServer.aspx

IoT example

Do you think a box (or even pack) of cigarettes could be the “thing”. It has a bar-code, so it is the source of data. Is it the sensor – NO because the bar-code reader (industrial scanner) is the sensor in this case. Can we recognize the bar-code reader as the “thing” – again the answer is NO if the goal is to provide a GLOBAL cigarettes tracking system. The same applies to drugs for example. Is it an IoT solution – my answer is YES, no doubts. Is it SCADA/DCS –the answer is NO, because the server (undelaying communication engine) cannot poll all possible places spread over the world where the box could appear. There are two reasons:

  • It is impractical or even impossible to manage such a huge set of addresses.
  • The server doesn’t know when to poll because the relevant data appear as an event instead of a process state value.

Assuming that the server is interested or even allowed to collect product data of one vendor only – not all codes fetched by any bar-code reader are relevant to the server.

Is the “thing” smart – I don’t think we can call the bar-code something smart. Is it controllable – NO.

The most interesting observation is that we can recognize this use case as an IoT application, but we have not mentioned OPC, AMQP, MQTT, SOA, Internet, WI-FI, wireless, Modbus, etc. at all, but only that we have important mobile data and the solution is globally scoped. It is good because we can check the available technology capabilities against this application requirements. As I have said selected communication technology is not the goal, but we must know how it scales to applications like this.

Now, let’s replace the word GLOBAL by LOCAL (for example cash desks farm in a shop) and the same application is no longer an IoT deployment, isn’t it? It is true even if the cash desks are interconnected using the IP protocol (e.g. Intranet)!

Sometimes it is stressed that any IoT application must guarantee a high level of robustness, but importance of the sensor and data robustness requirement is applicable to many kind of applications, e.g. controlling an airplane engine during flight. The same engine could be monitored and tracked after landing in any airport using the local WI-FI by uploading archival data to a central advanced analytic system (like the cigarettes box bar-code). Is it IoT? It isn’t during the flight, but the solution is life sensitive. After landing it is IoT, but the reliability of the data and data transfer is not so important, isn’t it?

IoT Paradigms

My proposal of the Internet of Things definition is as follows:

Internet of Things is all about:

  • mobile data fetching – how to gather the data from mobile devices (things);
  • mobile data subscription – how to transfer the data over the Internet to a place where it could be processed;
  • mobile data processing – how to integrate the data into a selected application to improve process behavioral performance.

Data fetching is related to a variety of last mile communication technologies, for example RFID, WI-FI, VHF, Bluetooth, etc. Subscription could be supported using messaging systems, e.g. AMQP, MQTT, etc. A good candidate for leveraging data consumption is for example OPC Unified Architecture.

Referring to previous examples, the data fetching process looks very similar in both cases – we have a data source and a sensor coupled together at some point in time responsible for sampling the data. Analyzing the examples from the application functionality point of view we cannot compare them because there are no requirements defined at all – only very general descriptions are provided. It looks like application capabilities are not relevant to the term definition. It is the reason why the terms SCADA, DCS and IoT are used interchangeably neglecting the fundamental differences between the following data acquisition patterns:

  • Data polling–continuous checking of the sensors to see what state they are in, usually in multipoint or multidrop communication (a communication engine with multiple devices attached that share the same line) by sending a message to each device, one at a time, asking each to respond and send new data.
  • Data subscription– senders of messages containing the process data fetched by the sensor, called publishers, do not prepare the messages to be sent directly to specific receivers, called subscribers, but instead they categorize published messages into topics without knowledge of which subscribers, if any, may receive the message. Similarly, subscribers express interest in one or more topics and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

It is worth stressing that in both cases reusability of the fetched data is assured. In data polling scenario the server coupled with the communication engine may be connected to by many clients at the same time. In data subscription scenario the publisher is responsible for multicasting the data to all attached subscribers directly or indirectly using a broker.

To deploy the IoT scenario:

  • the mobile data must be sent over the Internet (or Intranet) using messages;
  • the payload of these messages is consumed asynchronously by a server (e.g. OPC UA Server) responsible for exposing it in an address space;
  • the applications (e.g. OPC UA client) process the exposed data to reach selected key performance indicators (KPI).

It is required that the messages payload is formatted in a standardized way to be factored on the fetching site and meaningfully consumed by the analytic application (e.g. OPC UA client).

Data Acquisition patterns

In the above discussion the application functionality has been excluded as a factor, which can be used to recognize IoT applications. Now let’s analyze the impact of the data acquisition pattern on the application behavioral model.

Using data polling we must deal with the synchronous data acquisition pattern. In this case the application must follow the interactive behavioral model, because it actively polls the data source for more information by pulling data from a sequence that represents the process state in time. Such behavior is represented by an iterator, which is used to iterate through a data stream. The application is active in the data retrieval process – it controls the pace of the retrieval by sending the request messages at its own convenience. This enumeration pattern is synchronous, which means that the application might be blocked while polling the data source. Such polling pattern is similar to visiting the books shop and checking out a book. After you are done with the book, you pay another visit to check out another one. If the book is not available you must wait, but you may read what you selected.

On the other hand, in the reactive behavioral model, the application is offered more information by subscribing to a data stream, and any update is handed to it from the source. The application is passive in the data retrieval process: apart from subscribing to the source data stream, it does not actively poll the source, but merely react to the data being pushed to it. In this case, the application will not be blocked by waiting for the source to update. This is the push pattern employed by IoT. It is similar to joining a books club in which you register your interest in a particular genre, and books that match your interest are automatically sent to you as they are published. You do not need to wait but you must read what you get. Employing a push pattern is helpful in many scenarios, especially if data is available asynchronously as events.

The push model implemented by IoT requires additional resources responsible for multicasting the pushed data to all subscribers. This functionality may be accomplished by a middleware fulfilling the broker role or supported by the network infrastructure, e.g. IP multicast.

The fundamental differences between the interactive and reactive behavioral model must obviously impact the final application functionality, for example:

  • process controllability;
  • data destination discoverability;
  • maintainability.

Using data polling the request message may also contain data to control the state of a selected actuator. In this case the response message usually contains positive or negative acknowledge that can be used by the application as a condition selecting further activity. For example in case of communication disruption the request message may be resent. In case of actuator failure an alarm may be raised. In case of the pushing data scenario it is hard to implement remote control functionality in a similar way because the communication path is like a one-way route.

 

In interactive behavioral model the communication engine must have all information including addressing in advance to properly prepare request messages. The messages must be self-contained to be used by the network routing mechanism. In case of reactive behavioral model the application doesn’t know the source of data in advance. Therefore the sensors responsibility is to format the message and push it to an appropriate distribution channel. In this case the messages are not self-contained, because the information carried by them is only indirectly used by the routing mechanism.

For the polling data scenario configuration modification may be required after replacing the sensor if the data sources are not isomorphic for the data acquisition process. On the other hand the pushing data scenario requires that any replacement or modification of the data source must not need any modification of the application configuration.

Conclusion

From the above discussion we can derive the following dependency models:

Interactive applications (e.g. SCADA, DCS):
  • The application engine depends on the synchronous data acquisition engine – data is observed as a stream of entities.
  • The acquisition engine depends on the process devices (sensors or actuators), which it must know in advance.
Reactive applications (e.g. IoT):
  • The application engine depends on the asynchronous data acquisition engine – data is observed as a stream of events.
  • The data source depends on the data distribution channel.
  • The asynchronous acquisition engine depends on the distribution channel.
  • The data source and acquisition engine are associated by the data distribution channel proprietary mechanism.

There is a well suited open source project to start prototyping with this scenario.

https://github.com/mpostol/OPC-UA-OOI

Advertisements

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 Complex Data Processing Possible

From the definition, the Industrial IT domain is an integrated set of ICT systems. System integration means the necessity of the information exchange between them (the nodes of a common domain). ICT systems are recognized as a typical measure of processing information. The main challenge of deploying an Industrial IT solution is that information is abstract – it is knowledge describing a situation in the selected environment, e.g. temperature in a boiler, a car speed, an account balance, etc. Unfortunately machines cannot be used to process abstraction. It is also impossible to transfer abstraction from one place to another.

Fortunately, there is a very simple solution to address that impossibility, namely the information must be represented as binary data. In consequence, we can usually use both ones as interchangeable terms while talking about ICT systems. Unfortunately, these terms must be distinguished in the context of further discussion on the complex data, because before stepping forward we must be aware of the fact that the same information could have many different but equivalent representations – different binary patterns. For example, having interconnected system A and system B, system A can use one representation, but system B another one. Moreover, to integrate them, the transferred stream of bits may not resemble any of the previous ones. It should be nothing new for us, as it is obvious that the same information written as a text in regional newspapers in English, German, Polish, etc. does not resemble one another.

To understand a newspaper we must learn the appropriate language. To understand the binary data we must have defined a data type – a description how to create an appropriate bits pattern. Simplifying, the data type determines a set of valid values and rules needed to assign the information (understand the data) to a selected bits pattern. Therefore, to make two systems interoperable, apart from communication, they should be prepared – integrated to be able to consume data from each other, and so communication is only a prerequisite for interoperability.

The type is usually not enough to make the data meaningful. Referring to the above example the newspaper name (i.e. the location where the information came from) and timestamp (a single point in time when the information was valid) are attributes of the text that is representation of the information.

To have a similar ability to add common attributes to the representations of many information entities at the same time the complex data types must be used. Complex in this context means that the data type must additionally define a relationship between the components of the binary data, i.e. how to selectively get a component of the complex data.

The OPC UA offers two well-known and widely used relationships:

  • Arrays – components are indexed and all components must have a common data type.
  • Structures – components are named and components may have different data types.

Anyway, indexes and names must be unambiguous, and a complex data type has the responsibility to provide a precise definition of them, i.e. selectors of the components.

The complex data has a very important feature, namely all components are considered to be consistent with one another. For example, if we need to represent time at least three components must be distinguished: hour, minute, and second. In this case, even if there is no need to add any attribute to the binary data it must be consistent, i.e. it has to represent information in a single point in time. Other criteria for describing the data consistency could also be applied.

On the other hand using complex data simplifies data integrity if there is a need to store or transfer it. If intermediaries are present, the initial data creator and the ultimate consumer need to trust those intermediaries to help provide end-to-end data integrity, because each hop is processed separately. Thus, using complex data it can be processed and transferred as one item what finally mitigates any risk of integrity compromising.

Using the data type definitions to describe information exposed by a server allows:

  • Development against type definition.
  • Unambiguous association of the information with the data.

Having defined types in advance, clients may provide dedicated functionality, e.g. displaying the information in the context of specific graphics.

Typical scenarios can be recognized when we can define appropriate complex data types in advance. The OPC UA offers a variety of standard types ready to be used in common cases. If this out of the box set is not capable of fulfilling more demanding needs users may define custom data types. The OPC UA allows servers to provide data type definitions. The type definitions may be abstract, and may be inherited by new types to reflect polymorphism. They may be of generic use or they may be application domain specific. Custom types must have a globally unique identifier, which can be used to identify the authoring organization responsible for that type definition.

If the data publisher – an OPC UA server is not running in an environment capable of creating the complex data there must be taken special precaution to fabricate it if required. An example of this scenario is a standalone OPC UA server pooling data from plant floor devices using a custom protocol, e.g. MODBUS. If that is the case the protocol used to gather process data is usually not data complex aware. Reading and writing the data is accomplished using REQUEST/RESPONSE frame pairs. Moreover, one request can be used to read a set of values that has the same simple type only. The fabrication is an operation that uses group of requests to gather components and embeds them into a single value of a selected complex data type. It is optional server capability.

Related articles

Continue reading

OPC UA Makes Highly Distributed Network Control Systems Possible

Integration

Nowadays, to be on edge, modern manufacturing automation systems have to be involved. Usually they consist of numerous different IT systems located at business management/operation and process control levels. It is broad class of applications domain where business IT and control systems are converged to make a large whole with the aim to improve performance as the result of the macro optimization and synergy effect. This domain is called Industrial IT. Frequently the systems are distributed geographically in multi-division organizations.

To deploy the mentioned above convergence the systems have to be integrated – must interoperate with each other. From integration we should expect improved performance as a result of synergy and macro optimization effects.

After integration the systems should make up a consistent system, i.e. each subsystem (as a component) must communicate with each others. The final information architecture is strongly dependent on organization, culture, type of technology and target 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.

Vast majority of enterprises declare that difficulties with the integration of the existing systems are the most important obstacle to expand the process control and business management support. Other major integration problems are diversification of the existing systems, their quantity and non-unified data architecture.

Integration process results in Large Scale Distributed Network Control Systems (LSDNCS). Systems belonging to this class are usually created in a multi-step integration process. To succeed, the process has to be governed by a well-defined information and communication architecture.

Integration Models

System integration means necessity of the information exchange. To exchange information we need an association between components. Going further, to instantiate association, i.e. to make the component interoperable, we need at the same time a common:

  • information representation –  a language (data type),
  • underlying communication infrastructure – a transport (protocol + medium),

We must be aware that establishing an association we are actually building information architecture – system structure. It is worth stressing that selection of the architecture development has a great impact on the final robustness, maintainability, expandability, dependability, functionality, and last but not least implementation costs.

Generally we have three possibilities:

Peer to peer approach: Common integration practice is to achieve short-term ad-hoc objectives by manually creating/proprietary dedicated point-to-point links between the subsystems everywhere it is useful (see fig. 1). Using randomly this approach we can establish numerous independent links ((k+n)(n+k-1)/2 where k, n – number of business and process control components appropriately). The number rapidly grows, e.g. it is equal 1770 links for n=10 ; k=50, and finally we have to deal with rapidly growing complexity leading to the communication chaos, which is difficult to be maintained.

In this model the information and communication architectures are closely coupled. This approach is very popular, but adversely affects all of the solution features.

Peer to peer approach

Fig. 1

Totalitarian approach: One option to overcome the communication chaos problem is to use an “all in one” product dedicated to both functions: process control and business management (see presentation). Usually, it is provided as one complex, total system – let’s call it a supper-system. Most of the MES (Manufacturing Execution System) vendors offer theirs products as a panacea for all problems of the chaotic system integration.

Actually supper-system does not solve the problem, it only hides it under a not transparent cover and makes the solution very difficult to expand and vendor related forever.

In this model the system distribution is reduced, and as a consequence many associations can be instantiated on the same platform without necessity to communicate. This model reduces complexity by reducing communication needs.

If strictly observed it could be a dead end.

Process Observer approach: The Process Observer is a consistent, homogenous real-time representation of the process control layer. It is a kind of the 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 (see presentation). It allows sharing data from plant floor devices by the process and business management systems, using international standards of data exchange. 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. Now, they can gather the process data in a unified, standardized way (see fig.2).

Using the Process Observer archetype the number of links between components can be substantially reduced and, what is very important is a linear function of the number of nodes.

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

Fig. 2

Fig. 2

Related articles

Real-Time Communication for Large Scale Distributed Control Systems (Proceedings of the International Multiconference on Computer Science and Information Technology pp. 849–859 ISSN 1896-7094)

Process and business layers robust integration (white paper)

Communication management in the Process Observer Archetype (Proceedings of the 16th conference “Polish Teletraffic Symposium 2009”)

Large Scale Distributed Process and Business Management Integration (Proceedings of the 14th International Congress of Cybernetics and Systems of WOSC)

OPC UA Makes Global Security Possible

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. Security is a fundamental aspect of computer systems, in particular those dedicated to enterprise and process management. 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 also Internet as a public network to establish interoperability. Depending on the environment and application requirements, the communication services must provide different protections measures to make the solution secure, therefore OPC UA specification must offer scalability.

We can observe rapid development of globally scoped applications for domains like health, banking, safety, etc. The globalization process is also observed in control engineering. The secure transfer of process control data over the Internet must, therefore, be addressed as the most important prerequisite of this kind of applications.

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 includes independent reviews of all aspects of security starting from the design of in-depth security provided by the specification (which is built and modeled 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 the OPC UA eBook).

Security is a “collaboration” of technology and rules describing how to apply this technology to improve protection of a system/network against malicious users. To deploy security the following functionality must be provided:

  • Authentication – to identify users and software;
  • Authorization – to limit the activity to that granted to the user or application;
  • Data integrity – to protect the data from being corrupted;
  • Data encryption – to protect information from being accessed by any unauthorized user or application;
  • Digital signature – to determine the data source.

From the list above we can conclude that authentication is a basic component that decides about the quality and robustness of security. Authentication is a process of recognition and confirmation of the identity of someone or something. It is used not only for deploying security. For example applications (including operating systems) use authentication to determine the execution context.

Generally speaking, authentication can be done on the basis of:

  • something you must know
  • something you must have

Username and password is something you know and must keep secrete (at least the password, but it is recommended both).

A certificate is an example of something you must have – no secret information is contained therein. Any certificate is a digitally signed record of identification data.

To use knowledge for authentication you must distribute it (distribute secret) everywhere the identity is confirmed (e.g. hundred of services use credentials to define the execution context).

The certificate is confirmed by the certificate issuer, i.e. Certificate Authority (CA). It is one single point where it is verified and, therefore, it is much easier to protect authentication process against abusing it. We must keep this fact in mind when considering whether use or neglect Public Key Infrastructure (PKI), which is all about issuing, distributing, using, and revoking of certificates.

To summarize, using PKI we can benefit from two very important capabilities offered by it:

  • Certificates may be distributed without limits; on the other hand it is almost impossible to      control distribution propagation of secret knowledge as there is no evidence of its existence;
  • It is much easier to control the validation process of something if it is not distributed over      many places.

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.

More readings:

OPC UA vs OPC Classic -Security and Communication comparison
http://www.isssource.com/

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