Tag Archives: ua servers

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 – 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