Zur Cloud und zurück

In einer IoT-Umgebung soll in Zukunft für jedes Feldgerät eine virtuelle Repräsentanz entstehen, um neue Geschäftsmodelle wie zum Beispiel vorbeugende Wartung, Warenflusskontrolle oder auch Prozessoptimierung zu ermöglichen. Bei genauerer Betrachtung erkennt man, dass sich für Feldgeräte zwei konkrete Forderungen hinsichtlich Hardware und Software ableiten lassen. Allen voran ist eine IoT-Kommunikation zwischen Feldebene und Cloud herzustellen, wobei der Begriff Cloud stellvertretend für verschiedene Formen zentraler Datenhaltung steht. Nicht jede Cloud hat zwangsweise etwas mit dem Internet zu tun, und in der Fabrikautomation geht der Trend hin zu lokalen Clouds und Hybridlösungen.

Eine zweite Forderung besteht darin, bereits in den Feldgeräten Informationen zu generieren, die über reine E/A-Daten hinausgehen, wie beispielsweise Diagnose-, Analyse- oder Zustandsdaten des Gerätes. Die so angereicherten Informationen sollen dann in Objekten mit einer einheitlichen Semantik zusammengefasst und von Cloud-Applikationen ausgewertet werden können und die Basis für alle weiterführenden Dienste und Geschäftsmodelle darstellen.

IoT-Kommunikation beginnt im Feldgerät

Der Nutzen der Cloud steigt mit der Qualität und mit der Menge der verfügbaren Daten, die dort zu erfassen sind, wo sie anfallen, also im Sensor der Feldgeräte. Für die IoT-Kommunikation vom Feldgerät in die Cloud gibt es vielversprechende Protokolle, wobei sich mit OPC UA und MQTT bewährte Technologien anbieten.

Aber wo genau 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 bis in einen Datensammler oder eine Steuerung geschickt werden und von dort weiter in eine Cloud? Oder gelangen die Informationen direkt vom Feldgerät per OPC UA oder MQTT über ein Edge-Gateway in die Cloud?

Hilscher vertritt den Standpunkt, dass die IoT-Kommunikation bereits im Feldgerät beginnt. Sie erfolgt parallel zur Real-Time-Ethernet-Kommunikation über das gleiche physikalische Medium. Dabei gelangen die Informationen an der SPS vorbei über ein Edge-Gateway oder auch direkt in die Cloud. Um eine homogene Datenstruktur vom Feldgerät bis in die Cloud zu ermöglichen, muss bereits im Feldgerät ein Objektmodell etabliert sein. Idealerweise ist diese Objektdarstellung unabhängig vom benutzten Echtzeitprotokoll und bereits in der Kommunikationseinheit des Gerätes, beispielsweise einem Embedded-Modul, implementiert.

Aktuelle Feldgeräte sind oft noch nicht für diese Anforderungen ausgelegt und die IoT-Kommunikation wird sich erst sukzessive in der Fabrikautomatisierung etablieren, entweder per neuartiger Cloud-Applikation von „oben nach unten“ oder durch IoT-fähige Feldgeräte von „unten nach oben“. Ein IoT-fähiges Gerät muss daher neben der IoT-Kommunikation auch einen Upgrade-Pfad für Bestandsanlagen bereitstellen.

IoT-fähiges Embedded-Modul für Feldgeräte

Um Kunden eine IoT-fähige Lösung für Embedded-Systeme zu bieten, hat Hilscher seine DIL-32-Kommunikationsbaugruppe Net-IC weiterentwickelt und mit den zentralen IoT-Funktionen ausgestattet. Das Modul basiert auf dem Multiprotokoll-Chip Net-X52 und bietet dem Gerätehersteller bestmögliche Flexibilität bei gleichzeitig einfachster Handhabung.

Neben Real-Time-Ethernet-Kommunikation beinhaltet das Net-IC IOT sowohl einen integrierten OPC-UA-Server als auch einen MQTT-Client. Über den TCP/IP-Kanal des Real-Time-Ethernet-Protokolls (zum Beispiel Profinet, Ethernet/IP) ist an der SPS vorbei der Zugriff auf die Daten des Feldgerätes möglich. Dies kann entweder durch einen beliebigen OPC-UA-Client im Ethernet-Netzwerk geschehen, oder die Daten werden per Push-Mechanismus an einen vom Anwender frei konfigurierbaren MQTT-Broker gesendet.

Protokollunabhängige Objekt-Schnittstelle

Das Kernstück des Net-IC IOT ist die Netproxy-Technologie von Hilscher. Jedes Netzwerksystem bietet spezifische Dienste an, die der Anwender in der Regel selbst in seiner Applikation programmieren muss. Das erfordert ein tiefes Verständnis der Funktionsweise des jeweiligen Netzwerksystems und verursacht mit jedem neuen Netzwerk zusätzlichen Aufwand in der Applikationssoftware. An diesem Punkt setzt die Netproxy-Technologie an, deren Grundgedanke die Schaffung einer geräteorientierten Objekt- und Dienstschnittstelle zwischen Applikationen und Kommunikation ist. Diese Abstraktionsschicht versteckt die Komplexität der unterschiedlichen Netzwerkprotokolle und ermöglicht mit wenigen, einfachen Diensten den zyklischen beziehungsweise azyklischen Datenaustausch. Der Gerätehersteller muss nur noch diese generische Objekt-Schnittstelle in seine Applikation einbinden, und Netproxy setzt die Objekte selbstständig in entsprechende Netzwerkdienste um. Damit kann der OEM seine Anwendung komplett losgelöst von protokollspezifischen Anforderungen erstellen und erhält ein echtes Multiprotokollgerät.

Unterstützt wird der Gerätehersteller durch das intelligente Engineering-Werkzeug Net-X-Studio, das ihn durch den kompletten „Build-Prozess“ seines Endgeräts führt. Mithilfe des Tools erstellt der OEM die Objekt-Bibliothek für seine Gerätefamilie, das spezifische Objektmodell für sein Produkt sowie das Mapping auf das Kommunikationsprotokoll. 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 Web-Server vorgesehen sind. Dabei deckt das Engineering-Werkzeug alle relevanten Inhalte und Themen für die erfolgreiche Inbetriebnahme ab. Der Endkunde nutzt für die finalen Anpassungen, wie beispielsweise die Konfiguration des MQTT-Brokers, eine einfache Webserver-Schnittstelle.

Netproxy ist die geräteorientierte Objektschnittstelle zwischen Kommunikation und Applikation. Hilscher

Mit Net-IC IOT zum IoT-fähigen Feldgerät

Was muss nun ein Gerätehersteller in Bezug auf Hardware und Software vorsehen, um der steigenden Nachfrage nach IoT-fähigen Feldgeräten zu begegnen? Dabei liegt der Fokus neben kompletten Neuentwicklungen auch auf dem IoT-Upgrade bestehender, Net-IC-basierender Geräte.

Für beide Fälle bietet sich der kompakte, 10 mm flache DIL-32-Kommunikationsbaustein Net-IC IOT an, da er dem Gerätehersteller ein großes Maß an Flexibilität bei gleichzeitig einfacher Handhabung bietet. Das Pinning des Net-IC IOT ist flexibel konfigurierbar, und der Gerätehersteller kann im Engineering-Tool unterschiedliche Betriebsarten definieren. Neben einem nahezu freien, kundenspezifischen Arrangement der DIL-32-Signale gibt es für den schnellen Einstieg zwei vordefinierte Modi. Einerseits einen zum aktuellen NIC 50-RE Pin-kompatiblen Modus mit der bekannten UART-Schnittstelle zum Host-Prozessor und andererseits ein angepasstes Pinning mit einer 50 MHz schnellen SPI-Host-Schnittstelle und zusätzlichen Sync-Signalen. Damit lässt sich ein bestehendes Net-IC-basierendes Gerät um IoT-Funktionen erweitern, ohne weitere Änderungen an der Hardware vorzunehmen. Bei neuen Multiprotokollgeräten erfolgt die Anbindung des Net-IC IOT an den Host-Prozessor über die 50 MHz schnelle SPI-Schnittstelle.

In beiden Fällen ist es  allerdings erforderlich, die Softwareapplikation auf dem Host-Prozessor um die generische Objektschnittstelle Netproxy zu erweitern. Als Transportmechanismus nutzt man das bewährte Cif-X-Toolkit und erweitert es um die neue Netproxy-Abstraktionsschicht. Damit reduziert sich die Schnittstelle zur Applikation auf ein reines Lesen und Schreiben von Objekten, und zwar unabhängig vom benutzten Real-Time-Ethernet-Protokoll. In der Integrationsphase wird der Kundenapplikation das Objektmodell durch entsprechende Header-Dateien bekannt gemacht, welche automatisch im Build-Prozess durch das Engineering-Tool entstehen.

Da alle netzwerkspezifischen Informationen und die Verwaltung des Objektmodells in das Net-X-Gerät verlagert werden, kommt dem Build-Prozess mithilfe des Engieering-Tools Net-X-Studio ein hoher Stellenwert zu. Um Geräteherstellern eine hohe Flexibilität zu ermöglichen, ist der Build-Prozess modular aufgebaut. Anhand von Net-X-Studio lässt er sich in fünf verschiedene Phasen aufteilen, nämlich Definition der Objekt-Bibliothek, Erstellen der spezifischen Applikation (Instanziierung der Objekte), Kommunikationseinstellungen und Mapping, Produkt- und Herstellerangaben sowie die Net-IC-spezifische Konfiguration (zum Beispiel DIL-32-Pinning).

Mit dem intelligenten Engineering-Tool Net-X-Studio erfolgt der Build-Prozess in fünf Phasen. Hilscher

Zu Beginn eines neuen Projekts erstellt der Gerätehersteller das Objektmodell für sein Gerät beziehungsweise seine komplette Gerätefamilie. Neben den typischen Objekt-, Element- und Variablen-Definitionen können an dieser Stelle auch sogenannte „Label“ und „Attribute“ vergeben werden. Die Attribute beschreiben das Verhalten beziehungsweise die Informationsrichtung des Objekts und erlauben somit ein automatisches Mappen auf das gewünschte Kommunikationsprotokoll. Mit Labeln legt der Gerätehersteller fest, über welche Schnittstelle ein Objekt sichtbar sein soll, das heißt ob es nur über den Real-Time-Ethernet-Kanal von der SPS gelesen werden kann oder ob es auch über OPC UA, MQTT oder den Webserver zur Verfügung steht. Damit lassen sich schon im Feldgerät die vorhandenen Informationen klar zwischen normaler Echtzeit-Kommunikation und neuen Industrie-4.0-Anwendungen aufteilen.

Danach instanziiert der Hersteller die erforderlichen Objekte für sein spezifisches Gerät und wählt dabei aus der zuvor definierten Objektbibliothek aus. Die damit eindeutig beschriebene Schnittstelle zwischen der Kommunikationseinheit und der Applikationssoftware dient als Basis für das automatische Generieren der gerätespezifischen Header-Datei.

Nachdem alle applikativen Definitionen für das Gerät vorgenommen wurden, erfolgen die Kommunikations-Einstellungen. Zum einen kommt es jetzt zur Auswahl und Grundkonfiguration des Real-Time-Ethernet-Systems, derzeit Profinet I/O oder Ethernet/IP, und zum anderen legt man fest, ob zusätzlich per OPC UA und/oder MQTT kommuniziert werden soll. Die Objekte, auf die per IoT-Kommunikation zugegriffen werden kann, wurden in der Objektdefinition per Label eindeutig gekennzeichnet. In diesem Schritt findet auch das Mapping der protokollunabhängigen Objekte auf die protokollspezifischen Dienste und Services des Real-Time-Ethernet-Protokolls statt. Durch die bereits definierten Attribute geschieht die Verknüpfung automatisch. An dieser Stelle aktiviert der Gerätehersteller auch den integrierten Webserver mit zugehöriger Benutzerverwaltung, der als Diagnose- und Bedienschnittstelle für den Endkunden dient.

Der nächste Schritt dient der Verwaltung von produkt- und herstellerspezifischen Angaben, wie zum Beispiel Produktnamen, Artikelnummern, Revisionsstand sowie protokollspezifische Vendor-IDs. Unter anderem dienen diese Informationen zur automatischen Erzeugung der spezifischen Gerätebeschreibungsdatei.

Im abschließenden Schritt kann der Gerätehersteller die hardwarespezifischen Einstellungen des Net-IC IOT vornehmen, das heißt die Auswahl des gewünschten DIL-32-Pinning sowie die zugehörige Konfiguration, wie zum Beispiel die Schieberichtung der Ein-/Ausgangsdaten an der SSIO-Schnittstelle. Hier wird zukünftig auch die Anbindung eines TPM-Chips für erweiterte Sicherheitsmechanismen ermöglicht.

Mit Net-X-Studio lässt sich das DIL-32-Pinning des netIC IOT individuell festlegen. Hilscher

Am Ende des Build-Prozesses erhält der Gerätehersteller ein downloadfähiges Image für das Net-IC IOT, die notwendigen Header-Dateien für die Integration in seine Softwareapplikation sowie eine spezifische Gerätebeschreibungsdatei für die Inbetriebnahme. Damit ist der Gerätehersteller bestens für Industrie 4.0 beziehungsweise IoT gerüstet und hat gleichzeitig Investitionssicherheit für seine Produktentwicklung. Er entscheidet im Build-Prozess selbst, wann und für welche Daten er die OPC-UA- beziehungsweise MQTT-Funktion in seinem Produkt aktiviert.

Security und Privacy für Feldgeräte

Ein weiterer Aspekt bei der Betrachtung von Industrie 4.0 und IoT ist, dass der Anlagenplaner auch über Security und Privacy für seine Feldgeräte nachdenken muss. In vielen Fällen ist das Sicherheitskonzept der firmeneigenen IT-Infrastruktur ausreichend. Ob weitere Sicherheitsmechanismen erforderlich sind, muss gut überlegt sein. In jedem Fall ist es sehr wichtig, diese sinnvoll in das Anlagenkonzept zu integrieren. Idealerweise besitzt bereits das Feldgerät beziehungsweise das Kommunikationsmodul grundlegende Security-Mechanismen. Speziell für die Industrie sind weiterführende Ansätze in der Diskussion, wie zum Beispiel der Einsatz von TPM-Chips (Trusted Platform Module), die bereits in der Laptop-, PDA- oder Mobilfunk-Welt zum Einsatz kommen.

Für Hilscher sind IoT-Kommunikation und Sicherheit eng miteinander verknüpft, daher ist Net-IC IOT zukünftig um weiterführende Sicherheitsmechanismen erweiterbar, wie zum Beispiel das „Secure Boot“. Diese Technologie befindet sich noch in einer generellen Evaluierungsphase mit dem Ziel, erste Sicherheitsfunktionen auf Basis TPM 1.2 für netIC IOT bis zum Ende des Jahres präsentieren zu können.

(pet/ah)