Automation systems built using GE’s Industrial Internet Control System (IICS) technology
are comprised of applications distributed on different hardware platforms and unified with
a common information backbone. This backbone uses the OPC Unified Architecture (OPC
UA) framework. OPC UA is a secure, platform-independent, scalable, and object-oriented
architecture for representing and communicating information.
By using OPC UA, information can be modeled so that applications can inherently derive
its meaning and consequently make better decisions based on that meaning. This
enables applications to gain intelligence that can lead to new and exciting outcomes in
data management.
In addition, OPC UA provides a mechanism to protect the confidentiality and integrity of
information and to determine whether applications are trustworthy--a fundamental need
of the Industrial Internet.
This paper will provide an overview of the OPC UA and how it is used within IICS to
generate beneficial outcomes for customers.
2 of 20 OPC UA: The Information Backbone of the Industrial Internet2
2 OPC UA Overview
OPC UA is a specification developed and
maintained by the OPC Foundation. The
mission of the OPC Foundation is to manage
a global organization in which users, vendors,
and consortia collaborate to create data
transfer standards for secure and reliable
interoperability in industrial automation.
The OPC UA specification is composed of
several parts. Parts 1 through 5 form the
basic concepts of OPC UA and are defined
independently of the implementation.
These parts describe the Security Model,
Address Space Model, Information Model and
Services used for OPC UA applications. The
Services and Security Model are described
with abstract definitions that can be mapped
to specific implementations.
Part 6 defines mappings of the abstract
specifications in Parts 1 through 5 to
technologies used for implementation. This
includes technologies for implementing
data encoding, security protocols, and
transport protocols necessary to create a
real application.
Part 7 breaks down the features of OPC UA
into conformance units. A set of conformance
units define a profile. An OPC UA application
should be built to comply with one of the
defined profiles based on requirements of
the application and the resources available
on the device that will host the application.
This allows scaling OPC UA so it can be
deployed on small devices that comply with
a profile with a small set of conformance
units to very large devices that comply with a
profile with a large set of conformance units.
OPC UA: The Information Backbone of the Industrial Internet 3 of 20
Parts 8 through 11 extend the basic concepts
in Parts 1 through 5 to cover the functionality
found in OPC Classic. This covers Data Access,
Alarms & Conditions, and Historical Data
Access. These parts describe extensions to the
OPC UA Information Model associated with the
OPC Classic functionalities; e.g. Part 8 describes
the information model for Data Access.
There are other parts to the specification.
The organization of the specification allows
it to evolve with new parts to address new
and emerging requirements. For instance, an
important extension to the specification is
Part 14 – PubSub. This extension addresses
use cases for controller-to-controller
communication, public subscriptions, and
integration with message brokers.
The remainder of this section will explain
how the specification came to be and its
core concepts.
2.1 The Emergence of OPC UA
2.2 What is OPC UA?
In the mid-‘90s, the OPC Foundation published three separate
specifications referred to collectively as OPC Classic. Included in
OPC Classic are specifications for Data Access, Alarm & Events,
and Historical Data Access. OPC Classic was quickly adopted
as a mechanism to abstract industrial specific protocols into a
standardized interface that allowed software like HMI/SCADA to
communicate with a range of devices. This enabled the seamless
integration of automation products from different vendors into one
system. But, OPC Classic had drawbacks, such as dependence on
Microsoft COM/DCOM technology, three separate data models, and
limited protection against unauthorized data access. As industrial
automation evolved, these and other drawbacks made it clear that
OPC Classic had to be replaced.
The replacement of OPC Classic started with the initial release of
OPC UA in 2006. OPC UA was created to remove the limitations
imposed by OPC Classic, e.g. dependence on Microsoft technology,
and to address emerging requirements for security, communication
across firewalls, and support of complex data structures. Where
OPC Classic had separate data models that made it difficult
to connect different types of information, OPC UA unified all
information into a single AddressSpace. Beyond unification of data,
OPC UA features a service-oriented architecture that integrates all
the functionality of OPC Classic into one extensible framework-making it ideal for the Industrial Internet’s information backbone.
OPC UA specifies how information is
modeled and communicated in a system
like the Industrial Internet. It specifies
abstract services that can be implemented
in language-specific APIs and mapped to
different communication stacks. Keeping
the service definitions abstract allows OPC
UA to be extended over time to new and
emerging technologies without changing
the underlying design. It also specifies
an AddressSpace model that provides a
standard way for servers to represents data
in an object-oriented manner to clients.
At its core, the OPC UA architecture defines
clients and servers as interacting partners
where clients consume information that
servers provide.
4 of 20 OPC UA: The Information Backbone of the Industrial Internet
Figure 1 - OPC UA Client
2.3 The OPC UA Client
IICS client applications, such as analytics
and human-machine interfaces, fulfill
specific use cases that bring benefit to
end-users. For example, the humanmachine interface might request all the
information required to display a report
or to trend related process variables in a
chart. These client applications use OPC
UA as the infrastructure to interact with
servers to access information required by
the use cases.
Figure 1 illustrates this interaction pattern
where client applications make requests
to the OPC UA Client API. The OPC UA
Communication Stack then translates
these requests into messages that are
sent to the server through the underlying
communication framework. The server
processes the received requests and
sends a response back to the OPC UA
Communication Stack on the client. The
OPC UA Communication Stack then delivers
it to the client application through the OPC
UA Client API.
OPC UA: The Information Backbone of the Industrial Internet 5 of 20
OPC UA clients can subscribe to receive
notifications when an event occurs or
when a data value changes. In this case,
the events and data values are referred
to as monitored items. The server will
monitor these items and send notifications
to the client in response to a publish
request message from the client. This is
the preferred method for clients to receive
cyclical updates of variable values.
2.4 The OPC UA Server
OPC UA servers expose information for
clients to find and consume. The collection
of information that servers make available
to clients is called the AddressSpace. The
AddressSpace standardizes how objects
are represented. These objects are defined
in terms of variables, methods, and their
relationships to other objects as shown in
Figure 3.
The OPC UA AddressSpace unifies the
three classic data models (Data Access,
Alarm & Events, and Historical Data Access)
into one information model. This unification
makes it easy to connect the dots between
data values that are read to events that are
raised based on those data values.
Figure 2 - OPC UA Server
6 of 20 OPC UA: The Information Backbone of the Industrial Internet
Loading...
+ 14 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.