atp edition Einsatz robotergeführter Patientenliegen (Vorschau)
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
FIGURE 1: Old (A)<br />
and new (B)<br />
communication<br />
concept in OPC UA<br />
FIGURE 3: Delay for an OPC UA request-response<br />
FIGURE 2: OPC UA proxy server<br />
FIGURE 4: Average delay on Raspberry and Android<br />
uses pure HTTP only in combination with the XML<br />
encoding, which is currently not supported by the<br />
OPC UA Java stack.<br />
Typically XMPP uses also a binary TCP transport mechanism<br />
– but with the necessity to use a base64 encoding<br />
in order to wrap the binary data into an XML container.<br />
This and the additional hop over the XMPP server (on the<br />
same PC) make XMPP slower than OPC.TCP. In comparison<br />
to HTTPS this approach is faster – which may be<br />
because it re-uses previously established connections.<br />
XMPP can be used in two secure modes: XMPP-SSL uses<br />
a (deprecated) approach by applying a SSL connection to<br />
the XMPP server, while XMPP-SEC uses an XMPP internal<br />
mechanism to provide a secured transport (with endto-end<br />
encrypted body). Both approaches have a similar<br />
delay in this scenario. XMPP-BOSH uses a BOSH based<br />
transport. BOSH itself uses an HTTP-long polling approach.<br />
The communication over base64+XMPP+BOSH<br />
has the highest latency – but also the ability to work over<br />
HTTP proxies, NATs and firewalls.<br />
The approach using WebSockets (WS) transports the<br />
data like native OPC.TCP – but with the bidirectional<br />
communication strategy. This results in a similar delay<br />
during the communication: The unsecure approaches<br />
need 0.25 ms WS compared to 0.21 ms OPC.<br />
TCP; the secure approach WS (SSL) is also comparable<br />
to OPC.TCP (SEC) with enabled signing and encryption<br />
mechanisms.<br />
2.2 Platform comparison<br />
In this scenario an Android device (Samsung Galaxy<br />
Tab S2) or a Raspberry Pi was used as an example for a<br />
field device gateway on an embedded device. While the<br />
Raspberry was connected using a 1Gbit LAN, the Android<br />
device was connected over a Wi-Fi access point<br />
in the same LAN. In the case of XMPP the XMPP server<br />
was installed on the PC. The results in Figure 4 give an<br />
approximation of the expected delay:<br />
Usually the embedded device was used as the local<br />
instance (which receives requests from the PC in the<br />
role of a remote/cloud instance). In some cases also the<br />
“backward-direction” was tested (marked with “BW”)<br />
<strong>atp</strong> <strong>edition</strong><br />
7-8 / 2014<br />
37