atp edition Einsatz robotergeführter Patientenliegen (Vorschau)

JOHANNES SCHMITT, THOMAS GOLDSCHMIDT, PHILIPP VORST, ABB Forschungszentrum
The targeted scenario focuses on automation
systems where an application (or service) in
the cloud has to communicate and interact
with field devices on a site (for example a building
or plant). With “the cloud” we denote a
data centre with infrastructure for cloud computing [6],
connected to the Internet or a private network. One or
more of the following exemplary applications can be
assumed:
Remote control: As long as requirements like delay
constraints and reliability are met, a remote logic in
the cloud can be used to control elements on site.
The advantages of a cloud-based approach are the
global view of aggregating the information of multiple
sites and virtually unlimited CPU power based
on scalable infrastructure. Another benefit is the
easy integration of mobile devices like smartphones.
Cloud historian: A data historian in the cloud is of
special interest when a virtually infinite amount
of data should be stored and/or data should be stored
securely in a remote location because of (legal)
data backup requirements.
Service platform: The cloud type “Platform as a
Service” (PaaS) provides a modular software concept
and common interfaces as a basis for additional
services, to obtain an extensible system architecture.
The advantage of a cloud is the flexibility
to provide virtually unlimited resources for the
services which process the data obtained from the
devices.
OPC UA defines a meta-data model and interfaces to the
data model. Using an OPC UA based communication
between the cloud and a site provides full access to the
information of the OPC UA server(s) at the site. Without
any media breach like mapping or protocol conversion,
a cloud application can make use of the functionality
of the OPC UA server on the site. As OPC UA is powerful
in terms of extensibility of its data model and semantic
self-description of the information, this approach
is flexible and future proof.
A cloud application needs an OPC UA client in order
to access the data provided by an OPC UA server deployed
locally at a site or building. As a major extension to
its predecessor OPC, OPC UA provides binary or XMLencoded
messages over TCP or HTTP(S) [1]. This makes
OPC UA routable, platform-independent and much more
flexible – especially for Internet-based or cloud-based
applications [2]. Since OPC UA uses a client-server based
communication concept, the client starts the connection
to the server (“A” in Figure 1). Following this communication
principle, OPC UA has to cope with firewalls, dynamic
IP-addresses, NATs and client-lookup strategies.
The common approach of the protocols XMPP and
WebSockets is to establish the connection from the
local-side and re-use this existing connection from the
cloud-side in order to access services [4] behind firewalls
(as depicted in Figure 1 with “B”). While XMPP
follows an asynchronous message-queue based principle
using an intermediate message broker, WebSockets
are employed for synchronous direct calls.
1. CONCEPT / PROTOTYPE DESIGN
We have extended the client-server principle of the OPC
UA stack by mechanisms which allow for bidirectional
communication. This extension enables a cloud to local-side
communication over a previously established
local to cloud-side connection (as depicted in Figure 1
with “B”).
As another extension we developed a prototype for
an “OPC UA proxy server” which provides transparent
access (for example for other cloud applications) to multiple
client-side OPC UA servers through the cloud-side
OPC UA client (comparable to the concept of an aggregating
server [3], but without replication). This proxy
server concept aims to provide a central point for communication
in the cloud for both the OPC UA servers
connecting to the cloud and the cloud applications
requiring access to the information on the OPC UA servers.
The prototyped OPC UA proxy server shown in
Figure 2 provides multiple mechanisms to manage the
atp edition
7-8 / 2014
35