04.08.2014 Aufrufe

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!