|
UA specifies a flexible information model and a multi-platform secure
communication. This makes UA a good base for the implementation of interface
standards and there are collaborations with e.g. FDI, PLCopen,
ISA95, MDIS, …
The OPC UA specification defines a
wide range of features that don’t necessarily have to be implemented, a
specific server may only implement a subset of the specified profiles. The UA specification
chapter 7 defines the profiles and conformance units.
· UA Servers replacing Classic OPC servers.
Such
servers are implemented with features and an information model as simple as
such of Classic OPC servers. The UA specification defines how Classic OPC
features are mapped to UA.
The development of such servers doesn’t need to be more complex than the
development of Classic OPC servers.
· UA Server for
Collaboration Interfaces.
Such servers are implemented with features and an information model specific
to the collaboration specification.
· Application
specific UA Servers.
The information model and the implemented features (profiles) are application
specific.
Many off-the-shelf UA clients will not be able to properly access such UA
servers.
How is
the situation for UA clients?
UA clients
can determine the UA server capabilities and information model. However, the
development of UA clients that can work with any UA server is unreasonably
complex. To simplify the situation UA clients are likely developed for
specific types of UA servers.
· UA Servers replacing Classic OPC servers.
Wrapper
servers can be used to enable existing Classic OPC client applications to
access such UA servers.
The UA wrapper can be external or built into the client application. Advosol
offers UA wrappers as an add-on for its Classic OPC client components. This
allows UA servers to be accessed thru the familiar Classic OPC interface,
without external wrapper servers.
· UA Server for
Collaboration Interfaces.
The clients are implemented for the specific information model. Such clients
are better considered clients for the specific collaboration interface than
UA clients. This situation can be compared to HTTP and Email clients that
both base on the TCP/IP specification.
· Application
specific UA Servers.
The clients are application specific.
OPC UA as a replacement for Classic OPC DA
UA servers that replace Classic OPC servers have a simple node structure that
reflects the hierarchical organization of OPC DA servers. DA-only UA clients
ignore node references that go beyond a hierarchical tree structure.
With these restrictions the UA server and client development is significantly
simplified and what’s often the biggest concern, the DCOM communication, is
eliminated.
For client
developers Advosol offers multiple solutions:
- Add-on options for the Classic OPC
(DCOM) .Net client components:
· The UA Option for
OPCDA.NET extends the OPCDA.NET client component with UA server
access capability. Applications
developed for classic OPC DA can access UA servers through the same API.
· The UA Option for
OPCHDA.NET extends the OPCHDA.NET historian client component with UA
server access capability. Applications
developed for classic OPC HDA (Historical Data Access) can access UA servers
through the same API.
· The UA Option for
OPCAE.NET extends the OPCAE.NET client component with UA server
access capability. Applications
developed for classic OPC AE (Alarms and Events) can access UA servers
through the same API.
- Wrapper Servers:
· Instead of updating
existing Classic OPC clients, a converter server is added. This approach has
the advantage that the existing classic OPC clients don’t have to be
modified.
Advosol offers the COMtoUA converter server with easy to use
configuration tools.
|
