Per OPC UA oder MQTT vom Sensor in die Cloud

Per OPC UA oder MQTT werden die Informationen rückwirkungsfrei in die Cloud übertragen. Hilscher

Hinter den Begriffen I4.0 und IoT verbergen sich zwei konkrete Forderungen: Allen voran Automatisierungsgeräte an eine Cloud anzubinden und alle Geräte miteinander zu vernetzen. Dabei steht der Begriff Cloud stellvertretend für die verschiedenen Ausprägungen wie private Cloud, öffentliche Cloud oder daraus resultierende Mischformen. Also hat nicht jede Cloud zwangsweise etwas mit dem Internet zu tun und in der Fabrikautomation werden sinnvollerweise private Clouds oder
Hybridformen verwendet.

Der zweite Aspekt betrifft die Feld­geräte: Sie sollen Informationen generieren, die über die reinen E/A-Daten hinausgehen, etwa Diagnose-, Analyse- oder Zustandsdaten. Diese in einer einheitlichen Semantik in Objekten zusammengefassten Informationen sollen von Cloud-Applikationen ausgewertet werden können. Speziell der Semantik kommt eine große Bedeutung zu. Daher besteht auch das Ziel, einen einheitlichen Standard zu definieren. Die so generierten und standardisierten ‚Big Data‘ bilden die Basis für alle weiteren Dienste und Geschäfts­modelle, beispielsweise vorbeugende Wartung, Warenflusskontrolle oder Prozessoptimierung.

IoT-Kommunikation beginnt im Sensor

Mögen die Diskussionen über die Umsetzung von Industrie 4.0 noch so kontrovers sein. Einigkeit besteht darin, dass die Daten, aus denen Mehrwert generiert werden soll, in den Sensoren der Feldgeräte entstehen. Auch in Bezug auf die IoT-Kommunikation gibt es mit OPC UA und MQTT vielversprechende Kandidaten für einen Konsens. Aber wo beginnt die IoT-Kommunikation und wie werden die Daten vom Feldgerät in die Cloud übermittelt: Sollen die Daten wie gewohnt per Real-Time-Ethernet in einen Datensammler oder eine Steuerung transportiert werden und von dort in eine Cloud? Oder gelangen die Informationen direkt vom Feldgerät per OPC UA oder MQTT über ein Edge-Gateway in die Cloud?

Aus der Sicht von Hilscher beginnt die IoT-Kommunikation bereits im Feldgerät. Per TCP/IP-Kanal erfolgt sie ohne Rückwirkungen auf die Echtzeit-Eigenschaften parallel zur Real-Time-Ethernet-Kommunikation über das gleiche physikalische Medium. Dabei gelangen die Big Data ohne Umweg in ein Edge-Gateway beziehungsweise direkt in die Cloud. Um dem Anspruch einer einheitlichen Semantik gerecht zu werden, muss bereits im Feldgerät ein Objektmodell etabliert sein, um eine homogene Informationsstruktur vom Sensor bis in die Cloud sicherstellen zu können. Idealerweise ist die Objektdarstellung unabhängig vom benutzten Echtzeitprotokoll und bereits in der Kommunikationseinheit des Geräts implementiert.

Bestandsanlagen nicht vergessen

Mit dem Engineering Tool netX Studio erfolgt der ‚Build-Prozess‘ des Geräte-Images. Hier wird auch festgelegt, welche Daten per OPC UA oder MQTT in die Cloud gesendet werden sollen. Hilscher

Trotz aller Euphorie: Die Bestandsanlagen dürfen nicht vergessen werden. Denn die IoT-Kommunikation wird sich nur sukzessive in der Fabrikautomatisierung etablieren. Die Durchdringung erfolgt dabei über neuartige Cloud-Applikationen von ‚oben nach unten‘ und zum anderen durch IoT-fähige Feldgeräte von ‚unten nach oben‘. Ein IoT-Gerät muss daher neben der IoT-Kommunikation zusätzlich auch einen Upgrade-Pfad für die unzähligen Be­standsanlagen bereitstellen. Neu in der Fabrikautomation ist, dass der Anlagenplaner auch über die Security und Privacy seiner Feldgeräte nachdenken muss. In vielen Fällen mag die Standard-Security der firmeneigenen IT-Infrastruktur ausreichen. Ob weitere Sicherheits­mechanismen erforderlich sind, muss wohl überlegt sein und sinnvoll in das Anlagenkonzept integriert werden. Idealerweise bringt bereits das Feldgerät grundlegende Security-Mechanismen mit.

IoT-Upgrade für Feldgeräte

Um eine marktgerechte Lösung für I4.0 und IoT zu liefern, hat Hilscher seine DIL-32-Kommunikationsbaugruppen netIC weiterentwickelt und mit zentralen IoT-Funktionen ausgestattet. Der IoT-fähige Kommunikationsbaustein basiert auf dem Multiprotokoll-Chip netX52. Bei der Konzeption der Lösung wurde darauf geachtet, dass trotz hoher Flexibilität bei der Funktionalität eine einfache Handhabung bei der Implementierung sichergestellt ist.

Neben der Real-Time-Ethernet-Kommunikation beinhaltet der netIC IOT sowohl einen OPC-UA-Server als auch einen MQTT-Client. Über den TCP/IP-Kanal des Real-Time-Ethernet Protokolls (zum Beispiel Profinet oder Ethernet/IP) kann an der Steuerung vorbei auf die Daten des Feldgeräts zugegriffen werden. Dies kann entweder von einem beliebigen OPC-UA-Client aus geschehen oder die Daten werden per Push-Mechanismus vom IoT-Modul an einen MQTT-Broker gesendet, den der Anwender frei konfigurieren kann. Durch das flexibel konfigurierbare Pinning können bestehende Feldgeräte mit IoT-Kommunikation ausgestattet werden. Für solch ein Upgrade gibt es einen Pin-kompatiblen Mode zum NIC 50-RE-Modul mit UART-Host-Schnittstelle. Ein OEM erspart sich damit ein neues Hardware-Design. Der Entwickler muss lediglich die Softwareapplikation um das generische Objektmodell erweitern.

Bei Neuentwicklungen lässt sich netIC IOT über eine 50 MHz schnelle SPI-Schnittstelle an den Host-Prozessor anbinden. Damit ist der Gerätehersteller für Industrie 4.0/IoT gerüstet, bei gleichzeitiger Investitionssicherheit seiner Produktentwicklung. Er selbst kann entscheiden, wann und für welche Daten er OPC UA oder MQTT in seinem Produkt aktiviert.

Protokollunabhängige Objekt-Schnittstelle zur Applikation

Die geräteorientierte Objektschnittstelle Net Proxy kapselt die spezifischen Eigenschaften der Kommunikationssysteme. Hier erfolgt auch die Definition der Objektmodelle in einheitlicher Semantik. Hilscher

Ein weiteres Kernstück des netIC IOT ist die Net-Proxy-Technologie: Jedes Ethernet-System bietet spezifische Dienste an, die der Anwender in der Regel selbst in seiner Applikation ausprogrammieren muss. Das erfordert ein tiefes Verständnis der Funktionsweise des jeweiligen Netzwerksystems und verursacht mit jedem weiteren Netzwerk zusätzlichen Programmieraufwand in der Applikationssoftware.

An diesem Punkt setzt die Net-Proxy-Technologie an. Deren Grundgedanke ist die Ausbildung einer geräteorientierten Objekt- und Dienstschnittstelle zwischen Applikationen und Kommunikation. Diese Abstraktionsschicht ‚versteckt‘ sowohl die Komplexität als auch die unterschiedlichen APIs der Netzwerk-Protokolle und stellt einfache und vor allem einheitliche Dienste für den zyklischen wie auch azyklischen Datenaustausch zur Verfügung. Der Gerätehersteller braucht nur noch diese generische Objekt-Schnittstelle in seine Applikation einzubinden. Damit kann der OEM seine Anwendung losgelöst von protokollspezifischen Anforderungen erstellen und erhält ein echtes Multiprotokoll-fähiges Gerät. Net-Proxy liefert auch die Antwort auf den Wunsch nach einer einheitlichen Semantik. Sobald sich eine allgemeine Definition auf dem Markt herausgebildet hat, lässt sich diese nachimplementieren.

Das intelligente Engineering-Werkzeug netX Studio unterstützt Gerätehersteller beim Erstellen des Endgeräts. Mithilfe des Tools erstellt der Entwickler die Objekt­bibliothek für seine Gerätefamilie und das spezifische Objektmodell für sein Produkt. Durch die Vergabe von Attributen erfolgt das Mapping der einzelnen Objekte auf das Kommunikationsprotokoll zum größten Teil automatisch. Bei der Gerätekonfiguration gibt der OEM auch diejenigen Objekte frei, die für die IoT-Kommunikation über OPC UA oder MQTT oder für seinen produktspezifischen Webserver vorgesehen sind. Als Resultat liefert das Tool ein downloadfähiges Image und die gerätespezifische EDS-Datei für sein Gerät sowie eine Headerdatei für die Anbindung an die Applikationssoftware. Dabei deckt das Engineering-Werkzeug alle Themen für die erfolgreiche Inbetriebnahme ab. Der Endkunde nutzt für die finalen Anpassungen, wie die Konfiguration des MQTT-Brokers, eine einfache Webserver-Schnittstelle.

Cloud und Security – passt das zusammen?

Die Anbindung eines Feldgeräts an eine Cloud birgt durchaus Risiken. Ein zentraler Punkt bei der Betrachtung von I4.0 und IoT ist daher die IT-Sicherheit. Generell greifen die Sicherheitskonzepte der IT-Infrastruktur. Zusätzlich sind speziell für die Industrie weiterführende Ansätze in der Diskussion, etwa der Einsatz von TPM-Chips (Trusted Platform Module), wie sie bereits in Laptops, PDAs oder in der Mobilfunk-Welt zum Einsatz kommen.

Für Hilscher sind IoT-Kommunikation und Sicherheit eng miteinander verknüpft. Deshalb kann der netIC IOT zukünftig um Sicherheitsmechanismen wie ‚Secure Boot‘ erweitert werden. Im ersten Schritt lässt sich per SPI-Schnittstelle ein TPM-1.2-Chip anbinden, mit der Option später auf TPM 2.0 zu wechseln. Die Technologie befindet sich noch in einer generellen Evaluierungsphase mit dem Ziel, erste Sicherheitsfunktionen für netIC IOT Ende 2016 präsentieren zu können.

(sk)