Engineering of Distributed Control Systems

nullpitΔίκτυα και Επικοινωνίες

23 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

91 εμφανίσεις

Engineering of Distributed Control Systems


Martin Hoffmann
1
, Lorenz Hundt
1
,

Harry Hengster
2
, Mathias Muehlhause
3


1
Univ. of Magdeburg, Center Distributed Systems at IAF

Universitaetsplatz 2, 39106 Magdeburg / Germany

martin.hoffmann@ovgu.de; lorenz.hun
dt@ovgu.de

2

Schneider Electric GmbH, Automation Business Unit, System Consistency

Steinheimer Straße 117, 63500 Seligenstadt / Germany

harry.hengster@de.schneider
-
electric.com

3

Institut für

Automation und Kommunikation e.V. Magdeburg (ifak)

Werner
-
Heisenberg
-
Str. 1, 39106 Magdeburg / Germany

mathias.muehlhause@ifak.eu

Abstract

Current situation in industry is characterised by a strong trend towards distributed automation systems based on
int
elligent devices and intelligent decision making. Connectivity required to interact also in heterogeneous
geographically distributed communication environments

resulting in Virtual Automation Networks


VAN.


This paper presents solutions which are

part o
f the Engineering of the

homonymous
European IST NMP Integrated
Project “VAN". The focus of the engineering is the development of an approach and providing a technical solution used
for a seamless integration of engineered information for devices in Distri
buted Control Systems (DCSs) used in the VAN
Project. Therefore the VAN project has specified a common engineering workflow for a seamless vertical and horizontal
transfer of engineering information along the automation pyramid. For this, a UML based infor
mation model is
developed to cover the functional, topological and network requirements on the engineering and their relation between
each other at detailed level. The details of the engineering are derived from the VAN protocol specifications, which are
b
ased on the OSI Reference ASE model.

[1]. This approach is described in detail in [2]. Therefore, this paper’s focus is
to specify common engineering concept for automation systems as well as for their devices in distributed and
heterogeneous networks. For

this, the use of established IT technologies is in focus to ease a meltdown between office
and automation network technology. Two concepts regarding this objective are presented. First is the engineering of
distributed networks and transfer of engineered
information into devices using a vendor independent tool. The second
concept described explains how engineering information of distributed networks can be transferred and reused by using
TCI [3] and the FDT/DTM [4] technology. Furthermore, this paper descr
ibes, how smart devices can be configured
using web services in a secure way to start their application functionality. Using both concepts, new possibilities of
sharing engineering information of different enterprises can be realised. This results in reduc
ed costs during engineering,
configuration and maintenance of a plant.

Keywords

Virtual Automation Networks, Heterogonous Networks, Web Services, FDT/DTM, TCI

1

Introduction

The background for developing new ways in engineering is given by the EU project “
Virtual
Automation Networks” (VAN). The objectives of the VAN project are the result of one of the
leading trends in industrial communication


the penetration by IT standards. Due to their origin in
the office world, these technologies have to be extended

to meet industrial requirements. The
communication infrastruc
ture becomes more and more heterogeneous, ranging from wired to
wireless networks with specific transition technologies to connect different communication domains
and techniques.

Within the VA
N, project solutions for the usage of LANs and WANs


public and private, wired
and wireless


forming Virtual Automation Networks (VANs) for application in industrial domains
will be investigated and developed. The vision of VAN is an open, universal, sea
mless multivendor
networking solution, which is able to link worldwide distributed automation components from the
single sensor in one factory plant to remote machinery in decentralised plants. One aspect, that has
to be considered, is an engineering proc
ess, which has to meet all requirements of these new
aspects. The engineering of just one plant is no longer adequate for a VAN comprising parts of
several enterprise networks with several distributed communication components.

A main scenario of a VAN is s
hown in the figure aside. It points out the definition of VAN
domains, network segments with VAN capabilities. The VAN domains can contain both office
networks and industrial networks. This connection can be realized via public communication
environments,
which can be wired and wireless. Regarding engineering of a VAN the application
and system configuration of the decentralised automation systems

have to be engineered as well as
the overall application of the VAN domains including the network transitions [
5].

The paper proceeds with a description of the device architecture necessary to be part on a VAN,
followed by a description of the information, which has to be handled during engineering process.
For this, two possible approaches are described. A propos
al of technologies used to realise the
approaches is described before a synopsis concludes the paper.


Figure
1
: Virtual Automation Network

2

Device Architecture

To obtain the integration of devices into a VAN, a common architectur
e for devices is necessary.
This architecture presents a set of generic objects that are mandatory and optional respectively, for a
VAN device to fulfil its communication function within a VAN. Normally only a subset of these
objects will be part of a real

VAN device. To eliminate adaptability problems, VAN products are
not restricted to these functional objects. Adding non
-
VAN object is allowed to use and integrate
this architecture into other communication concepts.


Figure
2
: VA
N Device Architecture

In general, each VAN device, categorised in profiles and conformance classes, realises two main
functions. First, its functionality within the automation application which is provided by one or
more application tasks and second its co
nnectivity to a VAN network. A VAN device comprises
three major main components to implement this functionality. These are:



the VAN network technology layer,



the VAN communication stack, which provides connectivity to a VAN network together with
network te
chnology layer



and the application layer that defines the access points of an automation application to
communication components shown in
Figure
2
.

All components contain a combination of objects from standard tech
nologies and VAN specific
technology. Further, some objects are based on standard technologies with an adaptation to VAN
requirements. For the VAN architecture, the runtime object model of IEC 61158 type10 is used, but
also other object models could be use
d if they are conform to the VAN communication stack. All
devices with integrated VAN object model are able to interact with each other by using the VAN
infrastructure.

Further, devices with other communication technologies can also be integrated in a VAN
-
Domain
by using a VAN Proxy Device (VAN
-
PD). Therefore, it is possible for the responsible engineer to
interact with any kind of communication device within the VAN, independent from its geographical
location and the vendor of a device.

For a uniform con
figuration and for diagnosis purposes, the device architecture specifies a set of
Application Service Elements (ASEs) as defined in the ISO/OSI reference model and the
harmonised specification format of industrial communication standards in the IEC 61158 s
eries and
the IEC 61784 series. The ASE is used as a top layer access point for configuration and diagnosis
data. Every ASE is composed of two parts:



their class specification, which defines the attributes of the class



and their service specification, whi
ch defines the services that are provided by the ASE.

To access the objects within the ASE, Web Services are used as a common access and
communication technology. Thus, for every ASE a
get
service and a
set
service is defined
respectively. The Web Service

technology is a state of the art approach for communication in
heterogeneous network environments, to connect objects implemented on different platforms, and
to provide a built
-
in approved security mechanism. Another advantage of Web Services is that it
a
llows communication across firewalls that are necessary to connect different industrial sites and in
-
between different companies. Within the VAN environment, the main use for Web Services is
restricted for administration requirements (e.g. configuration, d
iagnosis), for an end
-
to
-
end
connection establishment and finally for the tunnelling of data.

Addressing within a VAN

All VAN devices obtain a unique VAN name within their VAN domain to guarantee their
accessibility within VAN.
General aspects within this

context are:



The VAN domain is a name based domain (similar to a URL) with a unique name space. This
provides easier handling than an IP based addressing for the engineer.



The naming conventions within a VAN domain shall conform to the DNS unique indicat
or and
to IEC 61158 type 10 [12] naming definitions to avoid naming conflicts.



Each VAN device has a unique name according to the defined naming conventions.



Address resolving in a VAN with sub domains and communication paths with different IP
-
subnets is

done by DNS [6] service.

These mentioned naming conventions and the ASE model for the VAN protocols access are
essential aspects of the engineering concept.

3

VAN Engineering Concept

The VAN engineering concept, detailed in [2], defines a continuous interf
ace between
functional
aspects
covered by modelling and a planning phase in a plant lifecycle and
implementation

aspects
covered by configuration, commissioning and a production phase of an engineering life cycle. The
result is a seamless engineering proce
ss for DCS between all phases of a life cycle without the loss
of information. With this focus, a generic UML [9] model considering all functional, topology and
network aspects is developed. For specific engineering projects, the model is used to derive
in
stances with all necessary information needed for one project. From that point forward the
instance is

part of one entire project. Thus, the VAN Instance Model represents the information
necessary for the engineering of one VAN system. It contains the
syst
em design

including the



definition

of the
quality of service

(QoS) for the communication connections



connection

information

of the related VAN domains



references

to separated VAN device descriptions, which has to be defined by the vendor for
every VAN devi
ce

Engineering Tool Architecture and Information Handling

For the validation of the engineering concept, a VAN engineering tool concept is specified and
implemented prototypically. To distinguish
functional

and
implementation

aspects, which are
mandatory b
ecause of the current range of engineering tools with its restricted functionality, two
components, as part of an engineering software tool, have defined activities:



the
VAN

Engineering Client System

(VAN
-
ECS) to cover all network related aspects of the
co
mplete automation system.



the

VAN Engineering Client Device

(VAN
-
ECD), which is used for the configuration and
commissioning of a single VAN device.

The
VAN
-
ECS

does not know all the details on devices and configuration. It is used mainly for
modelling an
d planning the complete automation system. The VAN
-
ECS is needed to have an
overview of the complete VAN network topology and to select a communication device that has to
be configured. The interface between VAN
-
ECS and VAN
-
ECD is shown in
Figure
4
.

The
VAN
-
ECD

is used for the engineering a single VAN device. The VAN
-
ECD does not have the
information about the complete automation system, but it has detailed information for the
automation component to be engineered
and the communication relations of this automation
component.

A VAN
-
ECD is used mainly during configuration and commissioning, phases and it is typically
covered by a vendor specific

engineering tool.


Figure
3
: Engineering Clien
ts

The configuration of communication devices is typically provided by vendor specific engineering
tools. For VAN engineering the enhanced VAN
-
ECD tool is able to extract the VAN relevant
planning data to the automation component. The basic information pro
vided in the planning data is
used as a basis for the configuration. The completed configuration data is then managed by the
corresponding VAN
-
ECD for each device in an independent repository. The configuration and
commissioning is usually performed in par
allel for different automation components. Therefore,
engineering activities on the different automation components of the automation system have to be
coordinated and synchronised. This can be regulated either by conventions, like operating
procedures or
it can be supported by version management tools using a check
-
in and check
-
out
mechanism. There are commercial tools available that cover these features and can manage data for
different tools.


Figure
4
: Distributed Engineering

Following this two
-
tool architecture, engineered system information and device configuration is
handled separately but not independently from each other.

To engineer a device in a distributed control system, the device has to be a member of the VAN
domain
, with its specifications and services. Therefore, a VAN specific engineering tool that
provides and supports functionality for the engineering process must be developed.

The VAN engineering tool, therefore, should cover all engineering phases of the VAN
system.
Further, it can cover the role of the VAN
-
ECS, VAN
-
ECD or both. The automation applications are
engineered using existing proprietary tools.

Figure
5

represents two types of device configuration using two
different communication channels.
The dedicated tool and the VAN
-
ECD are shown as separate entities in order to show the two
different communication channels of the architecture [
Figure
2
]. The final VAN system wil
l
integrate the new VAN features into the existing solution to provide an easy and reliable integration
into in the existing systems. Currently, existing engineering tools and devices typically make up
automation systems, which are connected by dedicated
fieldbus technologies. For configuration the
dedicated tool is directly connected to its device by a dedicated fieldbus. It is important to note, that
a VAN device is a physical device enhanced to integrate VAN capabilities. For this reason, if a
dedicated

tool is able to use Ethernet based communication, it can access a VAN device directly to
provide the automation application required by the system. A proprietary engineering tool can be
connected to a proprietary controller by an Ethernet based fieldbus,
and it can up
-

or download the
configuration for the automation applications required in the system. If the controller integrates as
well as VAN functionalities, the configuration of those VAN functionalities is provided from the
VAN
-
ECD. In this case, the

VAN device is configured from two different channels, the VAN
communication channel and the dedicated communication channel, both using Ethernet as a
physical medium, as shown in
Figure
5
.

The communication VAN de
vice is only connected to one physical network, the Ethernet medium.
However, it is reached from two logical communication channels: one based on VAN technology
and one based on dedicated technology [7].



Figure
5
: Device Config
uration

4

VAN Engineering Prototype

For the architecture of the VAN Engineering, two different components of engineering tools are
required to configure, maintain and diagnose devices: the component for global engineering of a
DCS


the VAN
-
ECS; and the com
ponent for local engineering


the VAN
-
ECD. As previously
mentioned, both components can be realised by separate tools or integrated in one tool. To provide
a feasible solution for the VAN project, two concepts were developed and specified:



a stand
-
alone t
ool with VAN
-
ECS and VAN
-
ECD functionality



and an integrated concept with mainly VAN
-
ECD functionality

The first concept targets the development of a stand
-
alone VAN engineering tool, which is
independent from existing engineering tools available on the
market. The focus of the integrated
concept is to facilitate the enhancement of existing engineering tools. Only for the integrated
concept following standardised technologies are used:



TCI to call one engineering tool from another and for the transmission

of configuration data.



Furthermore, FDT/DTM technology for configuration and parameterisation of a VAN device

In the integrated concept, TCI is used to couple an engineering tool with a commissioning tool of a
specific device. The FDT technology is used
to integrate the
VAN Device DTM

and a
VAN
Communication DTM

according to the FDT/DTM specification. These two DTM elements are used
by the commissioning tool in order to perform the configu
ration of the ASEs, which are
implemented within a device, and to
realise the communication to the VAN devices via web
services.

Device Description for VAN

As described previously, VAN devices require new functionalities. For this purpose, enhanced
device architecture with integrated application services was presented. T
o cover all configuration
aspects a specification of a VAN Device Description (VAN
-
DD) is worked out. The VAN
-
DD is
XML
-
based and represents all ASEs for configuration of a VAN device. Further, the structure of
the VAN
-
DD specification is extendable to ens
ure, that new aspects can be integrated after project
termination. [8]. The separation from a device description, typically provided by the vendor (used
for configuration of automation application) and a device description used for VAN
Communication (also
provided by the vendor) is based on the concept of two communication
channels to configure one device.

Beside the advantage of better data handling it is not necessary to integrate VAN features into the
multiplicity of existing device description standard
s. The VAN
-
DD builds a bridge to use further on
these standards and only for VAN specific parameters the VAN
-
DD has to be used.

Prototypical Implementation

Based on the requirements and concepts, a prototypical implementation as part of a common
Industria
l Experimental Setup (IES) demonstrator will be realised at the end of the VAN project.
The utilizing engineering concept is visualised in the

Figure

6
.



Figure
6
: Tool Concept for VAN Eng
ineering

The stand
-
alone tool provides a VAN
-
ECS application frame for modelling VAN domains, its
connections and VAN devices in offline and online mode. The engineered information is saved as
an XML project file with a reference on the corresponding VAN
-
D
D instance file, a VAN
-
DD file
filled with parameters for a specific project, which provides instance configuration data for each
device. The VAN
-
ECD application frame allows configuration of each modelled device and,
through the use of
web services,

the t
ransfer of data to the distributed devices.

For the first IES demonstrator Step 7 is the chosen engineering tool [10]. It is used to read (relevant
parts) of the imported XML project file, including the assigned VAN
-
DD instance files provided by
the stand
-
alone tool, and this step adds missing information. Then the engineer triggers the TCI
call. The Automation Xplorer+ [11] on the other side receives the TCI call and instantiates, based
on the transferred information, the developed
VAN Device DTM
and
VAN

Communication DTM.
With the use of the integrated FDT frame application, it is then possible to edit or modify
(additional) attributes and to set these attributes via defined ASE by using
Web Services
. To realise
this integrated IES prototype, the data ex
changed between the VAN
-
ECD tools is also analysed [7].



Figure
7
: VAN Integrated Concept Prototype

5

Synopsis

The VAN project focuses on production and manufacturing processes in distributed control systems
using a heterogeneous
network structure. The typical communication device architecture was
enhanced with features necessary for communication in this environment. The needed features are
not supported by today’s available engineering tools on the market. The initiation of Virtu
al
Automation Networks enables a logical view on industrial automation applications in a
heterogeneous network environment. As previously mentioned existing tools provide only limited
support during the modelling and planning phases of complex and distribu
ted systems. Considering
these facts, the VAN project provides a concept and solutions to improve methods for modelling
and planning and provide a seamless integration into existing tools. Concepts were pointed out, that
can be used by an engineer to desig
n a heterogeneous network infrastructure and to configure the
used devices.

The provided solutions are oriented to a balance between well established technologies and tools
and new system components needed to provide the bridge between the industrial segm
ents. The
scope of engineering includes the development of prototypes that enhance existing tools and show
the interaction between different tools, including the tools with the VAN devices.

Therefore, the implementation of the TCI and FDT/DTM technology in
to wide spread dedicated
engineering tools will be prototypically realised to prove the benefits of the information model, the
resulted instance file (project file) and the handling of the VAN
-
DDs. If it is shown that the
implementation of FDT and TCI into

existing tools is a useful improvement, the components
developed in the VAN project can be integrated into existing tools and easy used to configure
devices in heterogeneous environments. The stand
-
alone solution also provides functionality to
integrate c
ommunication devices into a DCS in parallel with the engineering tools currently in use.

Acknowledgement

The paper has been supported by the “Virtual Automation Networks” project (FP6/2004/IST/NMP/2


016696 VAN)
funded by the European Community under the
“Information Society Technology” Programme (http://www.van
-
eu.eu). The
authors want to thank the whole VAN project team.

References

International Standard Organisation: ISO/IEC 7498: Open Systems Interconnection Reference Model, 1994

Deliverable D08.2
-
1 of

the VAN project “
Specification of engineering process
”, The VAN Consortium, June 2006

PROFIBUS International: PROFIBUS PROFINET Specification: Tool Calling Interface, Version 1.0, October 2006,
Order No: 2.602

IEC 62453 series CD2:
Field Device Tool Speci
fication
. Geneva, July 2007.

VAN project page,
http://www.van
-
eu.eu

RFC
-

Request for Comments; RFC 1034


Domain Names


Concepts and Facilities, RFC 1035


Domain Names


Implementation and Specification; RFC 2782


A DNS RR for specifying the location
of services (DNS SRV);
http://tools.ietf.org; March 2008

Deliverable D08.4
-
1 of the VAN project “
Engineering Tool Integration Concept and Tool Interfaces
”, The VAN
Consortium, July 2007

Deliverable D08.4
-
2 of the VAN project “Specification of object model
and tool interfaces for VAN engineering
platform", The VAN Consortium, October 2007

Object Management Group: UML 2.1.2 Superstructure Specification, 2007

Step 7 Engineering Application Software;
fhttp://www.automation.siemens.com/simatic/industriesoftware/
html_00/produkte/software
-
step7.htm, March 2008

Automation Xplorer+ Engineering Application Software; http://www.phoenixcontact.at/automatisierung/187_21494.htm,
March 2008

IEC 61158 Digital data communication for measurement and control
-

Fieldbus for use

in industrial control systems;
http://www.iec.ch; March 2008