Address Space Analysis for Middleware Application based on OPC UA

11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
Address Space Analysis for Middleware Application
based on OPC UA
Simona-Anda GHERASIM, Vasile G. GAITAN, Adrian M. GAITAN,
Elisabeta TATULESCU, Daniel SIMION, Mihai F. URSULEANU
”Stefan cel Mare” University of Suceava,
str.Universitatii nr.13, RO-720229 Suceava
[email protected]
II.
Abstract — One of the most difficult requirements of
applications in automation industry is data transfer. This data
transfer is done through a middleware. The researchers have
studied various solutions for the transfer of information to be
provided in a reliable manner by another application. This paper
presents a middleware architecture made for monitoring and
controlling industrial processes.
Keywords - address space; informational model; hierarchical
types; middleware application; OPC specifications.
I.
ADDRESS SPACE IN THE OPC SPECIFICATIONS
Address space is the virtual address area which can be
assigned to a user, network host, a peripheral device or other
logical or physical entity, or separate programs to run.
OPC uses a client-server approach for information
exchange. An OPC server encapsulates the process information
sources and makes them valid for the defined interfaces. OPC
clients connect to the OPC server and can access and process
the data provided. Data processing and production applications
can be: either client or server [5].
INTRODUCTION
A. OPC DA
In the OPC DA specification, the server objects are able to
navigate and to identify any object in the hierarchy of address
space.
One of the most important tasks which can be performed by
a client in order to read data is monitoring the changes
occurring on the server. For this continuous monitoring, the
client defines an update rate. This is used to verify the values
that change cyclically. After this update rate, the server sends to
the clients only the values that have been changed.
With the continued need for large scale production of
various products, researchers have developed a range of
equipment and automation applications. In the industrial
automation, the data exchange between applications (or
applications and peripherals) has an important role. Because of
that, researchers have tried different solutions for the exchange
of information to be made in a reliable manner by another
application.
Starting from applications based on COM / DCOM, the
most important specifications for data exchange automation
industry, have been provided by the OPC Foundation. Thus,
OPC Foundation released a series of specifications, such as:
OPC Data Access (OPC DA), OPC Historical Data Access
(OPC HDA), OPC Alarm & Events (OPC A&E), OPC Unified
Architecture (OPC UA), OPC eXpress Interface (OPC XI). The
last two specifications made a shift from old technology based
on COM / DCOM to a service-oriented architecture, providing
data in a platform independent manner [1] [2].
OPC UA specification unifies previously specifications in a
single address space, able to deal with current data, alarms and
events, as well as historical data and events. A remarkable
improvement is address space model, in which suppliers may
provide a rich and extensible data model using object oriented
techniques. Thus, the great interest in advanced modeling
capacity in many areas leads to initiatives of standardizing
information models based on OPC UA.
Specifications mentioned above are widely accepted in
industry and already implemented by any system of automated
industry [3] [4].
B. OPC HDA
The only difference between OPC HDA and the classic OPC
(DA), is on OPC Historical Data Access that provides access
to the stored data. In OPC DA specification, data acquisition is
made in real time, but in OPC HDA data are stored in a
database first.
Historical archives of the HDA contain data information
from the simple to the more complex details.
Navigating into the server address space is made through a
specialized object, named OPCHDABrowser.
C. OPC A&E
The main functionality of the OPC A&E is the transmission
of alarms and events from different event sources.
Data acquisition from alarms and events is achieved in two
stages: creating an EventServer object and receiving events
messages by this object.
D. OPC XML-DA
In the OPC XML-DA specification, the COM/DCOM
83
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
technology was replaced by HTTP/SOAP and web services.
For information exchange, the functionality was reduced to
a minimum set of methods from the classic OPC.
Eight methods were needed to cover the key features of
OPC DA. These methods are: GetStatus, Read, Write, Browse,
GetProperties, Subscribe, SubscriptionPolledRefresh and
SubscriptionCancel.
E. OPC UA
OPC UA unifies all existing specifications, without loss of
features or performance, even with the addition of still
unimplemented features.
A wide range of applications where OPC is used, require
scalability for embedded systems, such as: SCADA, DCS,
MES and ERP systems.
III.
REQUIREMENTS FOR OPC UA SPECIFICATION
Figure 1 Nodes and References between them
We can identify two types of requirements imposed to the
OPC UA specification: communication requirements for
distributed systems and data modeling requirements for
describing a system and its specific information.
Depending on the communication between distributed
systems, the application based on OPC UA has to be reliable,
robust and fault tolerance, has to be platform independent,
scalable and redundant to observe the condition of high
availability. Also, the application must be high performance in
Intranet environments, interoperable, the security and access
control must be very safe, and also Internet communication
through firewalls has to be possible.
The platform independence and scalability needs to be able
to integrate OPC interfaces, even while running on different
platforms.
As for data modeling, the application based on OPC UA
should have a common design for all OPC data: to be object
oriented and to allow scalability from simple models to
complex models. This model should include extensibility types
of system to be able of providing meta-information and
describing also complex systems.
Finally, the application must have an abstract base model,
which can be any time a base for other standard data models.
Another important design goal was to enable an easy
migration to OPC Unified Architecture to protect the most
successful investment classic standard OPC [1][2][3].
IV.
These concepts are instances or different types of data.
Attributes are used to describe nodes and depending on
NodeClass, a Node can have different sets of attributes. Fig. 1
illustrates these concepts. Nodes 1, 2 and 3 contains sets of
attributes; links between nodes are carried by References
(1..6).
There are common attributes to several units. These
attributes are detailed in following table.
NodeId identifies uniquely a Node on the server and is the
most important concept to address information. The server
returns NodeIds which access or query address space and the
client uses NodeId to call the specific node.
A node can have several alternative NodeIds used for
addressing. The standard node identifier, NodeID can be
acquired by reading the NodeId attribute, even if the Node was
accessed from a node alternative.
Table I
COMMON ATTRIBUTES NODES OF OPC UA[2]
Attributes
NodeId
NodeClass
BrowseName
THE BASIC CONCEPTS OF OPC UA MODEL
DisplayName
Concepts of the OPC UA are Nodes and References
between them. Nodes may belong to different NodeClasses,
depending on their purpose.
Description
WriteMask
UserWriteMask
Description
Node ID is unique identifier of Node within the
OPC UA server and is used to address a node in the
OPC UA Services.
NodeClass is a list identifying the class of nodes
of current node (or object method).
BrowseName identifies the node that navigates
OPC UA server.
Node contains the name that should be used to
display the name of a user interface. Therefore, it is
located.
This optional attribute contains a textual
description of the location of a node.
It is optional and specifies which attributes of a
Node can be written (writable) or modified by OPC
UA client.
It is optional and specifies which attributes of a
node can be modified by a user connected to server.
BrowseName is used only for surfing and not intended to
84
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
display the name of a node.
DisplayName and Description are used for localization.
Theoretically, a reference is the relationship between exactly
two nodes. Therefore, it is uniquely identified by: source
reference node, target node, reference types and the semantic
reference.
In practice, the server may put a reference in one direction
only, and may indicate a reference to another node in the OPC
UA server or absent one. So, we can say that a reference is like
a pointer which indicates a pervious node and the latter one
holds the NodeId for the next node. This can be seen in Figure
2.
properties, reference types are displayed as nodes in the
address space. This allows customers to take advantage of
information about the references used by OPC UA server
nodes to access the server's address space [3][4][5].
V.
SCENARIO
Our scenario presents a network architecture using
embedded systems for client-server approach and middleware
OPC for information transfer.
The application developed for this case study was based on
achieving client applications for embedded systems. OPC client
was ported on embedded systems using eBox-2300SX and
PDX089T using NET Compact Framework2.0/3.5 and
Windows Embedded CE 6.0 platforms.
This application was developed to allow monitoring and
controlling industrial processes. For this reason, it was called
MCPI[6].
A. The MCPI application Architecture
The MCPI application is an executable software module
containing embedded objects. MCPI is being part of a complex
architecture of SCADA applications, presented in Fig. 4.
MCPI Architecture
Figure 2 References, seen as pointers to Nodes
Objects:
OPC-DA
OPC-AE
OPC-HDA
x.dll
There are two types of references, such as: symmetrical and
asymmetrical references. An asymmetric reference is
represented by an arrow indicating direction, for example a
reference type "has-parent" or "is-child-of" showing parent or
child node. The symmetrical reference, however, is represented
by a double arrow pointing both directions. An example is "issibling-of". In asymmetric references the direction is very
important, while in the symmetrical ones, it does not matter.
Graphic
Objects
Non-Graphic
Objects
z.dll
Objects:
Paterns
y.dll
MCPI.exe – MCPI application with embedded base objects
OPC AE
server
AEServer.exe
OPC HDA
server
HistServer.exe
Report
Generator.exe
gpDAServer.exe - OPC data server
Component acquisition interface
Component acquisition – Objects dictionary, Acquisition cycle,
Networks manager -gpcc_ODV.dll
Database
Component acquisition interface
ASCII.dll
Figure 3 Basic reference types hierarchy
ModBus.dl
l
CANOpen
USB.dll
MBus.dll
Sim.dll
Local
Industrial
Network
A reference cannot be accessed directly, but indirectly
through a node. It also cannot contain attributes or properties
and cannot be represented by a node. Finally, references are
used to expose the semantic differences in how nodes are
accessed. In conclusion, OPC UA specification has defined a
set of ReferenceTypes. Some of them are used in fundamental
areas, for example, to describe a type of hierarchy. To manage
these types of references, they were organized in a hierarchy.
Although references are nodes and do not have attributes or
Figure 4 SCADA System Architecture
MCPI application objects are objects embedded in OPC
type, object type templates, graphics and non-graphical.
MCPI application has two modes: edit and execution.
Editing mode allows implementing or modifying the project.
This work mode can be made when the application is decoupled
85
11th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 17-19, 2012
from the server. In the execution mode, the application is
running with the new changes made during editing mode.
Figure 6 OPC object Architecture
Root Directory (project) does not appear in the address
space tree structure of the project. It will be managed internally
to ensure a uniform structure of the management of project
objects.
VI.
CONCLUSION
The address space is a remarkable improvement of the OPC
Unified Architecture, to the old specifications. Through this
model, providers may expose a rich and extensible data model
using object oriented techniques.
Application developed for the case study, consists in an
OPC client ported on the embedded system eBox-2300SX.
Application development presented in Chapter V will
continue with performing different tests to analyze the network
overload performance and data traffic. Also, we will try to use
the proposed architecture with RFID tags and readers to make a
complete inventory of existing products from a different
container or warehouse, with lower costs.
Figure 5 Scenario Architecture
B. The MCPI application context
The basic components are MCPI application project, objects
and connections. The project is a group of independent or
interconnected objects, represented by the executable software
module. User task is to create, configure and connect objects
together.
The user creates projects (MCPI distinct applications) to
perform certain tasks and also can open and close the project
without affecting other projects running in parallel.
Each object can be configured by the user through the setup
window parameters, so an object can have multiple
functionalities.
OPC type objects are the only ones that can be connected to
OPC servers. Once created an OPC object, it can be connected
to any other objects from the same project. These objects can be
graphical displays and control objects through which the user
can access the process values.
This is the usual mode of communication with physical
devices in the process. If necessary, it can be developed internal
communication application objects (for serial communication,
Ethernet, wireless – with specific interfaces).
Each object has a BaseObject interface and may have an
optional OPC interface or a specific one.
The Address space of a project consists in all objects being
part of a project. The only exception is represented by graphical
objects. They are managed only as a display information items
at the window level [7].
In conclusion, the project is a set of objects and
connections, and it’s most important task is to manage the
entire list of objects linked or independent.
In a project, objects are grouped in folders. Each object has
a unique name in its directory and the directories will have a
unique name at the project level. The project will be a tree
structure of directories, subdirectories and objects.
ACKNOWLEDGMENT
This work was supported by the project "Knowledge
provocation and development through doctoral research
PRODOCT - Contract no. POSDRU/88/1.5/S/52946 ", project
cofounded from European Social Fund through Sectorial
Operational Program Human Resources 2007-2013.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
86
Frank Iwanitz, Jurgen Lange. OPC Fundamentals, Implementation and
Application, . Heidelberg - Huthig: 2nd rev. Edition, ISBN 3-7785-28831, 2002.
Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm. OPC
Unified Architecture, Springer – Verlag Berlin Heidelberg, 2009.
OPC-Foundation. OPC UA Specification: (Part 1-11) – Concepts.
Version 1.00,. July 28, 2006.
OPC-Foundation. OPC UA Specification: (Part 1-11) – Concepts.
Version 1.00,. July 28, 2006.
OPC-Foundation. OPC UA Specification: Part 3 – Address Space Model.
Version 1.00. July 28, 2006.
Găitan Gheorghiţă Vasile, Dănilă M. G., Robu M. G., Găitan N. C.
MCPI – a HMI Application for Monitoring and Controlling Industrial
Processes. . Suceava-Romania: The 9th International Conference on
Development and Application Systems, ISSN 1844-5020, pp.32-37.,
2008.
Simona-Anda GHERASIM, Vasile Gheorghiţă GĂITAN, Daniel
SIMION, Address Space Modeling for a New Generation of Middleware
- A Review, . Universitatea „Ştefan cel Mare” Suceava, România:
Seminarului Ştiinţific naţional „Sisteme Distribuite”, 2011.