See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261281435

SeMo-TS: Testing OPC UA server models in

simulated environments

Conference Paper · October 2012

DOI: 10.1109/IECON.2012.6389444

CITATIONS READS

0 31

4 authors, including:

Sebastian Lehnhoff Mathias Uslar

OFFIS e.V. OFFIS e.V.
134 PUBLICATIONS 459 CITATIONS 177 PUBLICATIONS 678 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

European Liaison on Electricity Committed Towards long-term Research Activities for Smart Grids
(ELECTRA IRP) View project

Monitoring and Management System for Smart Distribution Networks View project

All content following this page was uploaded by Mathias Uslar on 30 July 2015.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
 SeMo-TS: Testing ope UA Server Models In
Simulated Environments
Sebastian Rohjans, Sebastian Lehnhoff and Mathias Uslar
R&D Division Energy
OFFIS - Institute for Information Technology
Escherweg 2, 26121 Oldenburg, Germany
Email: {rohjans.lehnhoff.uslar}@OFFIS.de
Abstract-The advent of the ope Unified Architecture (UA)
extends the scope of standardized (industrial) automation. Until
now, ope standards have only been applied in the context of
industrial automation. The ope UA however, enables applica­
tions in various domains, e.g., the power domain aiming at the
implementation of smart grids. Among other things, smart grids
pursue the goal of realizing an automated overall energy system.
Referring to the ope UA standard, which has been identified
as a suitable solution, the power domain can benefit from the
experiences in industrial automation. Deploying an ope UA
architecture in the field, previously requires extensive testing
in simulative environments. In this contribution, a test suite for
simulated ope UA servers and clients is introduced. Investigating
the state of the art motivates the need for a software tool fostering
the validation of developed ope UA server models in order to
ensure their reliable operation in the field.
I. INTRODUCTION
Classic OPC standards have been the state of the art in
industrial automation for years [1]. They are dealing with read­
ing, writing, and monitoring of process data (OPC Data Access
(DA)), sending messages in consequence of certain events and
alarms (OPC Alarms & Events (AE)), and accessing historical
data (OPC Historical Data Access (HDA)). However, due to
the continuous development in the IT-sector, Classic OPC is
outdated today for various reasons [2]. The ten most significant
disadvantages are listed by Lange et al. [1] comprising, e.g.,
discontinuation of COMIDCOM, which is the basic technol­
ogy of Classic OPC, use of Classic OPC limited on Windows
platforms, and low-performance OPC communication via Web
Services. OPC Unified Architecture (UA) aims at overcoming
the serious shortcomings that exist. OPC UA realizes a server­
client architecture following the Service-oriented Architecture
(SOA) paradigm. The standard consist of l3 specifications. In
order to facilitate the deployment of OPC UA, a major concern
is the compatibility to existing and widely spread Classic OPC
solutions. Therefore, concepts like wrappers and proxies are
provided [3].
Besides the modeling of information, communication ser­
vices are of major interest. Both, services and data models
are defined in an abstract way and are mapped onto specific
technologies. Thus, an OPC UA system can be applied with
suitable technologies for specific use cases. Moreover, UA
systems can be used on different layers from information
978-1-4673-2421-2/12/$31.00 ©2012 IEEE
Plamen M. Rusinov
BTC Business Technology Consulting AG
Escherweg 5, 26121 Oldenburg, Germany
Email: plamen.rusinov@btc-ag.com
management to field layers in control systems [4]. For this
reason, the scope of application of OPC UA is significantly
extended compared to Classic OPe. Generally, OPC UA can
be applied in any domain providing an appropriate data model.
One domain, which is now within the scope of OPC UA is
the power sector with its so called smart grids [5].
Smart grids serve as a representative example for a very
complex system including information exchange on many
different levels. Data must be collected from small devices
like meters but also from complex systems like Supervisory
Control and Data Acquisition (SCADA) [6]. The application
of OPC UA to complex systems requires the operation of a
range of simple to rather complex servers under various non­
functional requirements, e.g., in terms of performance and
security [7], [8]. One key issue of building a communication
architecture, which has a high degree of complexity and
analyzing it in terms of the afore mentioned requirements is
simulation [9]. Thus, commonly before devices and systems
are realized as OPC UA servers, there is a need for simulating
their behavior in a proper simulation environment. In this
paper and for the context of complex OPC UA systems, SeMo­
TS (Server Model - Testing Suite) is presented as a testing
suite for simulated OPC UA servers. The tool is capable
of managing different servers including their configurations
and modifying their data models. Furthermore, clients can be
realized in order to test the simulated servers.
The remainder of this contribution is structured as follows:
Section II provides an introduction of OPC UA focusing on
data modeling and UA servers. The state of the art is presented
in Section III containing popular Software Developing Kits
(SDK) in Section III-A and development tools in Section
III-B. The SeMo-TS approach is introduced in Section IV
and evaluated in Section V. Finally, Section VI concludes the
contribution and provides a brief outlook at future work.
II. OPC UNIFIED ARCHITECTURE
The main objective of OPC UA is the integration of in­
formation and devices in enterprises beyond the boundaries
of single systems riO]. Thereby, OPC UA is mainly covering
two important issues [11]. On the one hand, the modeling of
information provided by servers and consumed by clients. On
2845
 XML Web Services
Profile: SOAP-HTTP WS-SC UA XML
Binary encoded Web Services
Profile: SOAP-HTTP WS-SC UA Binary
Native Binary
�
Profile: UA-TCP UA A Binary

I I
]I
t
UAXML UA Binary

:
I
WS Secure Conversation
JI UA Secure Conversation

II
It
SOAP 1.2 UA TCP

HTTP/HTTPS
I TCPIIP

Fig. 1. Technology mappings of ope UA

Node A Node B
Reference 1
Attributes Attributes

Reference 2

/-
l

Reference 3 eference 5
Fig. 3. Object hierarchy of a basic ope UA server
c�
r-N-o-d-e -
Attributes

Reference4 I name or a unique Node/d. Further attributes are related to the

specific node classes. In Figure 3 the nodes are depicted as

Fig. 2. ope UA node model [II] part of a basic server. In Part 3 [14] of the specification, the
main classes are specified as follows:

• Objects structure the Address Space.

the other hand, the services applied for the communication be­ • ObjectTypes define the semantics of Objects and complex

tween servers and clients. Since, the focus of this contribution ObjectTypes structure interconnected nodes like Variables

is the testing of server models, the data modeling is of higher and Methods.

interest. However, services are also briefly introduced in the • A Variable is a Node that contains a value. Two different

following but for the sake of conceptual clarity not considered types of Variables exist:

in detail. Variables that are the target Node for a HasProperty

The principle of OPC VA is to provide a small set of Reference are called Properties. Properties describe
easy-to-use services. The services are grouped with respect the characteristics of a Node.
to their functionalities [12]. They are defined in a technology Variables that are representing the content of Objects
independent way. To make them applicable, technology map­ are called Data Variable.
pings are specified [l3]. Figure 1 illustrates these mappings. In • VariableTypes define the semantics of Variables and com­
particular, the mappings on the different layers can be divided plex VariableTypes as well as the structure of intercon­
into Internet-based communication (VA XMLlSOAP/HTTP) nected nodes e.g. sub-variables.
and real-time communication (VA Binary/uA TCPITCPIIP). • Methods define the signature of methods which can be
If future use cases require mappings to novel technologies, executed via OPC VA interfaces.
these can easily be realized and specified. • DataTypes specify user-defined data types which can be
The realized information modeling concept allows meta data used in the context of Variables. This also includes the
annotation so that instead of simple data, semantically enriched encoding so that clients can send a request to a server
information can be exchanged. The abstract information model at runtime in order to get the encoding of a user-defined
can be used in combination with both, standardized models data type which can then be used.
and vendor-specific models. This yields a high level of in­ • ReferenceTypes define the semantics of References link­
teroperability because the data cannot only be exchanged in ing the nodes. Each Reference is assigned to a Reference­
an interoperable way but also with clearly defined semantics. Type. Beside the various predefined ReferenceTypes, e.g.
OPC VA provides a meta model that can be used in order to inheritance and compositions, user-defined ReferencTypes
define specific information models. This meta model is called can be defined.
Address Space [14]. • Views define a certain part of the Address Space in order
Figure 2 illustrates the Address Space in a simplified man­ to provide a reasonable selection of nodes to the user.

ner. It mainly consists of a set of nodes being connected by In [15], Girbea et al. present generalized algorithms for
certain references. The nodes are grouped in classes based the automatic generation of Address Space structures. The ap­
on their meanings. Each class of nodes includes attributes proach includes the description of a generalized Address Space
describing them in detail. General attributes are for example generation scheme, specialized algorithms for the generation

2846
of different Address Space elements, and adding additional ope UA Server
Server
references. The algorithms can be applied independently from Application

the used information model. Mahnke et al. [11] list the basic
principles of information modeling with OPC UA as follows:

• Using object-oriented techniques including type hierar­

chies and inheritance.
• Type information is exposed and can be accessed the
same way as instances.
• Full meshed network of nodes allowing information to
be connected in various ways.
• Extensibility regarding the type hierarchies as well as the
types of references between nodes.
opeUA Server API
• No limitation on how to model information in order to
OPCUA Rsp .. Notif""
R" Pub'"
allow an appropriate model for the provided data by Communication M,. M,. M,. M,.
Stack

i 1 i 1
allowing various extension mechanisms.
• OPC UA information modeling is always done on the
From ope ToOPC From ope ToOPC
server-side. The model can be accessed and modified UAClient UAClient UAClient UAClient

from OPC UA clients but an OPC UA client is not

required to have an integrated OPC UA information Fig. 4. OPC UA server structure [16]

model.

Since, information modeling is realized on server-side,

codes, which facilitate the development of OPC UA
it plays a key role in terms of testing UA servers. The
applications. Besides the fully supported .NET and C/
architecture of UA servers with their major components is
C++, also a Java version is under development and
illustrated in Figure 4. Similarly to the clients, the servers
currently in a beta stadium. Furthermore, a toolkit-API
have an Application Programming Interface (API) used to
is provided implementing easy-to-use UA functionalities.
send and receive services (requests and responses) to and from
• Unified Automation C++ SDK2: The SDK provided by
clients. The API is an internal interface isolating the code
Unified Automation contains a server and a client SDK.
of the server-application from the UA communication stack.
Both are based on a shared C++ library. The whole SDK
However, the server-applications are more complex compared
is developed based on the ANSI-C stack from the OPC
to the client-applications. Real objects are physical (e.g.,
Foundation. The aim is to enable the development of
devices) or virtual (e.g., software) components. Furthermore,
portable UA servers and clients. Moreover, an included
they include the Address Space with its nodes and views.
tool is capable of creating information models with the
Monitored items are created by clients, which then can monitor
according source codes.
certain nodes of the Address Space respectively the real objects
• Prosys OPC UA Java SDK3: This SDK is based on the
represented by the nodes.
Java stack provided by the OPC Foundation. New Java
III. STATE OF THE ART: TOOL SUPPORT FOR DEVELOPING applications can be added to the basic stack. The client
OPC UA SERVERS AND AVAILABLE SDKs SDK enables OPC UA service calls and the server SDK
allows the development of complete applications without
In order to present the state of the art, existing SDKs have
many efforts due to the provision of all UA services and
to be considered, on the one hand and available developing
data types.
tools are analyzed, on the other hand. 4
• OPC Toolbox Unified Architecture : Softings OPC UA
A. Software Development Kits Toolbox comprises libraries, functional classes, and sam­
ple codes fostering the development of UA applications.
The SDKs are the basis for developing OPC UA appli­
A well tailored interface can be implemented in order
cations for both, servers and clients. The application of the
to realize UA functionalities like Address Space manage­
abstract OPC UA specifications is based on communication
ment, creating, deleting, and modifying objects, and the
stacks and SDKs. The core communication is covered by the
management of events as well as methods. Thereby, the
stacks and the SDKs provide server and client applications
toolbox is platform independent, component based, and
with interfaces in order to use the stacks. The following list
portable. It provides the development of embedded OPC
provides an overview on the most prominent SDKs for UA
products for process control systems and devices.
application development:

• OPC Foundation .NET SDKl: The OPC Foundation

offers a collection of libraries, applications, and source
I hup:llopcfoundation.org/Default.aspx/Ol_aboutlUA.asp?MID=
AboutOPC#Code
2http://www.unified-automation.com/sdk-overview.htm
3http://www.prosysopc.com!opc-ua-java-sdk.php
4http://www.softing.com!home/enlindustrial-
automation/products/opc/news/20 1 Oil00729-opc-unified-architecture-for­
windows-and-embedded-systems.php?navanchor=30 I 0224

2847

B. Developing Tools
Tools, which focus on the development of Address Spaces
and thus on server models are already existing. They either
generate source code or Extensible Markup Language (XML)
files both implementing the information models. The three
predominant software solutions are:
• .NET Model Compilers: This tool aims at generating
source code from XML and Comma-Separated Values
(CSV) files, which contain the node definitions of the
information model. However, it is not possible to modify
the XML files with the tool. The code generation is based
on templates, which can be customized manually. The
resulting source code is compliant to the .NET SDK.
• UAModeler from Unified Automation6: The UAMod­
eler is also aiming at the generation of source code.
XML files in combination with according filters serve as
input. A significant feature of the software is a Graphical
User Interface (GUI) for the node management. Thus,
information models can be designed graphically, which
yields an easier way of development.
• OPC UA Address Space-Designer from C AS7: The
Address Space Designer generates XML files compliant
to a .NET code generator. The tool is not as intuitive
as the UAModeler but also provides a robust solution.
However, it includes graphical modeling capabilities.
IV. SEMo-TS: UA SERVER MODEL TESTING S UITE
Referring to the state of the art, the SDKs provide a
suitable basis for developing UA applications. However, the
scope of the introduced tools dealing with the design and
development of information models does not include testing of
the generated models. This gap is to be closed by SeMo-TS,
which provides a set of server and client wrappers in order
to foster the validation of the generated information models
based on simulated servers and clients.
The following basic principles were considered for the
development of SeMo-TS:
• UA server as well as UA client applications including
their creation, modeling, and management within an
integrated graphical interface will be considered.
• The proposed software contains so called wrappers in
order to use Classic OPC applications. The aim is to
open, modify, and save as many different applications as
possible. Furthermore, new server and client applications
can be created and edited on the fly.
• The OPC DA information model serves as basic UA in­
formation model. However, the software must be capable
of handling other information models. Especially those
models have to be considered, which specify mappings
to established information models in aspired application
domains, e.g., for the power domain IEC 61970/61968
5http://www.commsvr.com/OPC-Helplhtml/9c908037-0f24-4f6b-955c­
de27c5b8248a.htm
6http://www.unified-automation.com/uamodeler.htm
7http://www.commsvr.com/Products/OPCUAlUAModelDesigner.aspx
2848
� . ..
Menu I
. I I
I XML editing area I
Ciont
� �
tall toplls!
E,I
''''''_II
Client 1 I List of running UA applications
Client 2
Client 3
So�
I
Server 1
Server 2
Server 3
Fig. 5. SeMo-TS main frame
COlmnon Information Model (CIM) [17], IEC 61850
[18], Electronic Device Description Language (EDDL)
[19], Field Device Tool (FDT) [20], and IEC 61131-3
programmable controllers [21].
• MS Visual Studio is chosen as development environment
in order to apply C# and .NET technologies.
• The prototype is intended to be used on machines with
Windows based operating systems but should become
platform independent in future.
• Existing toolkits and SDKs have been investigated and
the .NET SDK including the Quickstarts provided by the
OPC Foundation meets the requirements best.
Figure 5 shows the graphical interface of the main frame
being the starting point for using SeMo-TS. All functionalities
can be applied from here. Besides the common menu bar,
the XML editing area and the overview on UA applications
are of major concern. The applications are organized by
the ClientServerManager, which allows access to editable
elements of the applications. These elements can be modified
by the XML Visualisator that is illustrated in Figure 6. This
component allows the modification of the underlying XML
files for configuration and information models.
Clients and servers can either be loaded by binaries of
existing clients/servers or created from scratch. In the latter
case the template file Quickstarts. Template. Client. Conjig.xml
is used by default for clients and the template file Quick­
starts. Template. Server. Conjig.xml is used for servers. Both files
are provided by the OPC Foundation's Quickstarts. Clients are
used to access the functionalities of the servers and thus, they
are not focused by SeMo-TS but serve as part of the testing
procedures. For servers, binaries or configuration XML files
can be additionally selected.
The most valuable part of SeMo-TS is the management of
server configurations and server information models including
their simulation. The configuration is managed within the
XML editor. There, for instance, values for namespaces,
security settings, timeouts, and address information can be set.
 V. EVALUATION

The evaluation of SeMo-TS is based on use cases. There­

fore, the field of smart grids was chosen as the area of
<?x!nIversOon="l.O"eocoding="utf-S"?>
-<Applicati<>OCoo figurabon xmkls:xSl="hHp://www.w3.org/2001/XMlSchema�;nst.mce"
application. In order to identify representative use cases,
=::�:�:���;:::::::��: ::::�::;:: �::�,!8:':;�!��;����n.IISd"
xmkls: s2 ="htlp://opdoundlltlon.org/UA/SDK/COM/Configurlltlon.IIsd"
xmkls="hnp://opdoundatlon.org/UMSDK/Conflguratlon.lCsd">
. abon Name >d qApp ioc anonN ame>
their selection is based on requirements for smart grid ICT­
<Applic
<ApplicationUri><Jm:localhost:UASOK:O"t"AccessClientqApplicationUri>
<Produ<;tUri>hHp:/lopcfoundatlon. org/UASDK/OataAccessCLlentqProdu<;tUn> architectures as specified in [22]. In [7], Claassen et al. and
<ApplicationType>cLienC l qApplicabonType>
- <5ect.-ityC oo figuration>
-<Applic ationCe,tilicate> in [8], Lehnhoff et al. provide different use cases for the
<5toreType>f)irectoryq5toreType>
<5torePatil>%CommOnApplicatlonDlltll%\OPC Foundlltlon\CertiflCllteStoreS\MlIchineOefllultqStorePatil>
<5uti)l!ctName>Qu;ckstart Olltll ACCeSS ClientqSutiJectName> application of OPC VA in smart grids. The considered use
qApplic atlO nCe'tllicate>
-<TrustedPeerCe'tllicates>
<5toreTy�>WlndowsqStoreTy�> cases are representative examples that satisfy the specified
<5torePatil>locaIMlIchlne\UA ApplicationsqStorePatn>
</TrustedPeerCe,tllicates>
qSec t.-ityCoo !ig.wabon > requirements. One of the use cases is explicitly focusing on
<Transportcooligurations / >
+ <TransportQuotas>
- <C Iient coo figuration> a complex system architecture including different types of
dlefaultSessionTimeout>60000qDefaultSessKKlTimeout>
- <wellKr\o w �scoveryurts>
<ua:Strmg >opc. 1cp://{O} :'IS'IOqua:Stnng> servers. All of the provided servers are simulated systems.
OO ���DS"""' '- .. � Listing 2 shows an exemplary XML file for a server providing
a weather service.

Fig. 6. SeMo-TS XML editing area The use case is based on the original use case "Distributed
Energy Ressource Controller Produces Distribution Powerflow
Forecast" [23], which handles load forecasting of distributed

The simulation has to be implemented in MS Visual Studio and energy networks by using data from different sources like load

creating new simulations requires its installation. The structure history, weather forecasts, and energy price trends. The system

of the server class is shown in Listing 1. A Visual Studio functionalities are distributed among different modules, each

solution is selected in the first step and the ModelDesign of which can be seen as an independent component and is

XML is recompiled in the second step. The ModelDesign implemented as VA client or server, respectively.

XML contains the information about the server information In a first step all servers and clients were imported by SeMo­

model. The resulting executable file is started automatically TS. Then, both the configurations of the servers and their

as the final step of the process. With the current prototype, information models have been modified in order to simulate

the simulated behavior of the modeled elements must also be realistic changes. Moreover, new severs have been added to

implemented in Visual Studio and is part of the server. the system and existing ones have been replaced by new ones
providing different capabilities. In general, all servers and
public Server( string solutionFi le , string model File , string
clients are simulated compliant to realistic behaviors.
config File)

<?xml version=" 1.0" encoding="utf -S" ?>

this .ConfigFilename = conf ig File;
<ModelDesign xmIns:nsO =" http: II opcfoundati 0n .org IUAI"
this .ModelFile = modelFile;
xmlns: xsi =" http: IIwww.w3.org 1200 I IXMLSchema- in stance"
this . Solution File = so lution File;
xmlns:ns l =" http: //opcfoundation .0rg/SmartGridl
RebuildCSProject();
WeatherService" xmlns:uax=" http: II opcfoundation.org/UA
1200S/02/Types.xsd" xmlns:xsd=" http: //www.w3.org/20011
public void RebuildCSProject()
XMLSchema" TargetNamespace=" http: II opcfoundation.org I
( SmartGrid I WeatherService" xmlns=" http: II opcfoundati 0n .
if ( So lutionFile == null) return;
org IUAIModelDesign.xsd">
Process modelBuild = new Process ();
<Namespaces>
modelBuild. Starllnfo .File Name = Path.GetDirectory Name(
<Namespace Name="OpcU a" Prefix="Opc.Ua" X mINamespace="
ModelFile) + "\\ BuildDesign.bat";
http: II opcfoundation.org IUA/200S/02/Types.xsd">
modelBuild. Starllnfo. U se ShellExecute = false;
http: II opcfoundation.org IUAI
modelBuild. Start ();
<I Namespace>
modelBuild.WaitForExit();
<Namespace Name="WeatherService" Prefix=" SmartGrid.
Process msBuild = new Process ();
WeatherService ''>http: //opcfoundation.org I SmartGrid I
msBuild. Starllnfo.File Name = @"c:\ Windows\Microsoft.NET
WeatherService
\ Framework\ v3.5\MSBuild.exe";
<I Namespace>
mSBuild.Startlnfo .Arguments = "\"" + SolutionFile +
<I Namespaces>
\"1 t: rebuild Ip: Configuration=Debug Ip: Platform =\"
<ObjectType SymbolicName=" ns I :WeatherForecastType"
anycpu\"";
BaseType=" nsO: BaseObjectType">
msBuild. Starllnfo. U se ShellExecute = false;
<Children>
msBuild. Startlnf o .Redire ctStandardOutput = true;
<Varia bI e SymbolicName=" ns I: Region ID" WriteAccess=" I "
msBuild. Start ();
DataType=" nsO: Stri ng" I>
string output = msBuild.StandardOutput.ReadToEnd();
<Variable SymbolicName=" ns I :Temperature" WriteAccess=
msBuild.WaitForExit();
" I" DataType=" nsO:Double" ValueRank=" Array"
if ( msBuild.ExitCode != 0)
ArrayDimensions="24" I>
( <Variable SymbolicName=" ns I :Humidity" WriteAccess=" I"
MessageBox.Show( output, "Compiling not su ccessfull");
DataType=" nsO:Double" ValueRank=" Array"
re t II rn;
ArrayDimensions="24" I>

"
<Variable SymbolicName=" ns I :A irPressure" WriteAccess=
string execFile = Path.GetDirectory Name(ModeIFile) +
" I" DataType=" nsO:Double" ValueRank=" Array"
\\ bin \\ Debug\\ " + Path.GetFile NameWithoutExtension(
ArrayDimensions="24" I>
ConfigFilename).Replace( "Config", "exe");
<V aria bI e SymbolicName="ns I:WindSpeed" WriteAccess=" I
InitExec( execFile);
" DataType=" nsO:Double" ValueRank=" Array"
ArrayDimensions="24" I>
<Variable SymbolicName=" ns l :CloudCover" WriteAccess="
Listing 1. Implementation of the server class I" DataType=" nsO:Double" ValueRank=" Array"
ArrayDimensions="24" I>

2849
 <I Chi Idren >
<IObjectType>
<ObjectType SymbolicName=" ns I :WeatherForecas tsType"
BaseType=" nsO:BaseObjeclType">
<Chi Idren>
<Object SymbolicName=" ns l :WeatherForecas t l "
TypeDefi ni ti 0 n =" ns I :WeatherForecas tType">
<BrowseName>Wealher Forecasl #1</BrowseName>
<IObjecl>
</Chi l dren>
<IObjectType>
<Object SymbolicName=" ns I :WeatherForecasts"
TypeDefi ni Ii 0 n =" ns I :WealherForecaslsType">
<BrowseName> WealherForecas Is<1 BrowseName>
<References>
<Reference Islnvers e =" true">
<ReferenceType>nsO:0 rgani zes<IReferenceType>
<Targell d>n sO:Objeels Fo I derd TargelId>
<I Reference>
<IReferences>
<IObject>
<IModelDesign>
Listing 2. Server design example for weather forecasting
Based on feedback received from VA application developers
and modeling as well as simulation experts, it can be stated
that SeMo-TS is an easy-to-use prototype implementation of
a testing suite for VA applications. Server models can be
modified reliably and simulated environments can be created
in a simple way in order to prepare server models for field
operations.
VI. CONC LUS IONS
The OPC VA was introduced as communication standard
with a broad scope of application. The way information model­
ing is realized on server-side has been elaborated. Furthermore,
the state of the art in terms of SDKs and developing tools
in the context of OPC VA systems has been discussed. A
gap within this tool landscape was identified. In particular,
complex VA system architectures require simulation of single
VA components in advance. However, appropriate software is
not available so far. Therefore, SeMo-TS was introduced as a
testing suite for VA servers including their data models. The
tool was finally evaluated by implementing and simulating typ­
ical use cases from the power domain and receiving feedback
from experts.
The proposed prototype is a first step towards a powerful
testing framework. However, it has some shortcomings that
have yet to be addressed. Modifying servers can not be realized
during run-time, thus the servers have to be recompiled and
restarted and are not available in the meantime. Due to the
fact that the ModelDesign XML from the OPC Foundation is
used SeMo-TS has to react on changes in the ModelDesign
in order to stay compliant. In general, the concept relies on
Quickstarts provided by the OPC Foundation and therefore, it
is depending on them to a certain degree.
The next steps include the integration of simulations and
further automation of currently manual parts. Especially the
integration of simulation functionalities is an important ben­
efit. The pursued goal is to have a selection of pre-loaded
simulations that can be linked with single objects in the server
data model.
2850
View publication stats
For instance, simulating measured values randomly within
a given range. Furthermore, new simulation behaviors should
be definable in order to continuously extend the capabilities.
The long-term goal is to provide a comprehensive simulation
framework that enables the development, management, and
simulated testing of OPC VA applications.
REFERENCE S
[I] J. Lange, F. lwanitz, and T . J. Burke, OPC: From Data Access to Unified
Architecture, 4th ed. HUthig, 2010.
[2] F. Iwanitz and J. Lange, OPC: Grundlagen, Implementierung und
Anwendung. HUthig, 2005.
[3] T. Hannelius, M. Salmenpera. and S. Kuikka, "Roadmap to adopting
OPC UA," in 6th IEEE International Conference on Informatics, 2008,
2008, pp. 756-761.
[4] O. Sande, M. Fojcik, and R. Cupek, "OPC UA Based Solutions for
Integrated Operations," Computer Networks, pp. 76-83, 2010.
[5] NIST, "NIST Framework and Roadmap for Smart Grid lnteroperability
Standards," 2010.
[6] H. Farhangi, "The Path of the Smart Grid," IEEE Power and
Energy Magazine, vol. 8, no. 1, pp. 18-28, 2010. [Online]. Available:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?amumber=5357331
[7] A. Claassen, S. Rohjans, and S. Lehnhoff, "Application of OPC UA for
the Smart Grid," in Innovative Smart Grid Technologies (ISGT) Europe
2011, 2011.
[8] S. Lehnhoff, S. Rohjans, M. Uslar, and W. Mahnke, "OPC Unified
Architecture: A Service-Oriented Architecture for Smart Grids," in
ICSE
2012 International Workshop on Software Engineering Challenges for
the Smart Grid. IEEE, 2012.
[9] S. SchUtte, S. Scherfke, and M. Troschel, "Mosaik : A Framework
for Modular Simulation of Active Components in Smart Grids," in
2011 IEEE First International Workshop on Smart Grid Modeling and
Simulation (SGMS), 2011, pp. 55-60.
[l0] T. Hadlich, "Providing device integration with OPC UA," IEEE Interna­
tional Conference on Industrial Informatics, 2006, pp. 263-268, 2006.
[11] W. Mahnke, S.-H. Leitner, and M. Damm, OPC Unified Architecture.
Springer, 2009.
[12] OPC Foundation, "OPC Unified Architecture Specification Part 4: Ser­
vices - Release 1.01," 2009.
[13] -- , "OPC Unified Architecture Specification Part 6: Mappings -
Release 1.00," 2009.
[l4] -- , "OPC Unified Architecture Specification Part 3: Address Space
Model - Release 1.01," 2009.
[15] A. Girbea, R. Demeter, and F. Sisak, "Automatic address space genera­
tion for an OPC UA server of a flexible manufacturing system," in
6th
IEEE International Symposium on Applied Computational Intelligence
and Informatics (SACI), 2011. lEEE, 2011, pp. 483-488.
[l6] OPC Foundation, "OPC Unified Architecture Specification Part 1:
Overview and Concepts - Release 1.01," 2009.
[17] S. Rohjans, M. Uslar, and H.J. Appelrath, "OPC UA and CIM: Seman­
tics for the smart grid," in
Transmission and Distribution Conference
and Exposition, 2010 IEEE PES, 2010, pp. 1-8.
[18] S. Lehnhoff, W. Mahnke, S. Rohjans, and M. Uslar, "lEC 61850 based
OPC UA Communication - T he Future of Smart Grid Automation," in
17th Power Systems Computation Conference (PSCC'll), 2011.
[l9] R. Huang, "Research on OPC UA based on electronic device descrip­
tion," 3rd IEEE Conference on Industrial Electronics and Applications,
2008., pp. 2162-2166, 2008.
[20] D. Grossmann and K. Bender, "OPC UA based field device integration,"
SICE Annual Conference, 2008, pp. 933-938, 2008.
[21] OPC Foundation and PLCopen, "OPC UA Information Model for lEC
61131-3 - Release 1.00," 2010.
[22] S. Rohjans, C. Danekas, and M. Uslar, "Requirements for Smart Grid
ICT Architectures," in 3rd IEEE PES Innovative Smart Grid Technolo­
gies (ISGT) Europe Conference, 2012.
[23] Electric Power Research Institute, "Distributed Energy Resource Con­
troller Produces Distribution Powerflow Forecast Version 1.1," 2010.