Sensoren sind die wesentlichen Datenquellen in der Automatisierung und damit die Basis einer Industrie 4.0. Für die Sensorik hat sich in der Fabrik-Automation IO-Link als weltweiter Kommunikationsstandard etabliert. Um die Sensor-Daten per IO-Link zur Verfügung stellen zu können, benötigt der Sensorhersteller allerdings ein IO-Link Master Device, zumeist in Form eines IP67-Feldgerätes, das seine Daten auf die Feldbus-Protokolle abbildet. Der Systemumfang skaliert über die Anzahl der unterstützten Feldbus-Protokolle und die Hardware-Varianten. Mittlerweile werden an die Komponenten allerdings weitere Anfor­derungen gestellt: Oft erwarten die Kunden einen vorhandenen Web- oder OPC-UA-Server mit ‚IO-Link OPC UA Com­panion Profile‘, Möglichkeiten des Firmware-Update und mittlerweile auch eine sichere Datenübertragung; alles Anforderungen, die den notwendigen Systemumfang erhöhen.

Die Hardware-Struktur des IO-Link Device mit integriertem Edge Gateway in einem 60 mm x 200 mm großen IP67-Gehäuse.

© Hilscher

Generell werden die Daten der Feldebene an der Steuerung oder am Feldbus-Netzwerk abgegriffen. Über die Programmierschnittstelle oder den integrierten OPC-UA-Server stellt die Steuerung ihre Daten zur Verfügung – aber eben nur diese und nicht spezielle Diagnosedaten der Peripheriekomponenten oder gar der unterlagerten Sensorik. Erst ein Edge Gateway, eingebunden im Netzwerk direkt vor der Steuerung, kann alle zyklischen Echtzeit-Daten mitlesen. Zudem kann das Edge Gateway über azyklische Dienste des Feldbus-Protokolls oder über eine zukünftige, durchgängige OPC-UA-Kommunikation auf Feldgeräte und die Sensorik zugreifen. Das Edge Gateway kann so alle relevanten Prozessdaten filtern und mit Metadaten ergänzen. Diese Prozessinformationen können dann zum ERP- und MES-System oder über entsprechende Konnektoren unter Einhaltung der Security-Standards in die Cloud des Anwenders übertragen werden.

Daneben gibt es aber auch Gerätedaten und Daten, die den Netzwerk-Status betreffen, die primär der Diagnostik und Wartung des Systems dienen. Diese sollten Geräte- und Hersteller-übergreifend, Netzwerk-spezifisch und abhängig von der gewählten Systemarchitektur aggregiert werden. Es macht Sinn und bietet weitere Optionen zur ‚ownership of data‘, wenn diese bereits im Edge Gateway separiert und in einem globalen Edge Portal dargestellt werden. Dies erfolgt nach Freigabe des ‚data owners‘ und eingeschränkter Sicht des OEMs auf seine eigenen Geräte beziehungsweise des Betreibers auf alle Geräte in seiner Maschine oder seiner Anlage. So entwickelt die Systemsicht für jeden Beteiligten einen Mehrwert. Ist es doch im Servicefall interessant zu wissen, welche Geräte mit welcher Firmware betroffen sind, und auch, um zur Diagnose oder zum Firmware-Tausch remote auf diese Geräte zugreifen zu können. Zudem könnten Funktionserweiterungen durch Laden spezieller Module realisiert und die Geräte-Entwicklung optimiert werden. Der Anlagenbauer hat außerdem Interesse an einer möglichen Hersteller-übergreifende Konfiguration der Anlage, dem Anzeigen des Geräte- und Netzwerk-Status oder dem automatischen Führen eines Systemlogbuchs bis hin zur Abbildung der Peripheriekomponenten als digitalen Zwilling.

Ein wichtiger Aspekt ist das Thema Security: Auch beim Edge Portal ist dies eine zentrale Anforderung. Deshalb ist Security eine System-übergreifende Funktion, die das Einbringen, Updaten oder Austauschen aller Systemgeräte und die zugehörige Zertifikatsver­waltung beherrschen muss. Gerade dieser Punkt zeigt, dass die Systemlösung eine aus ­Software und Hardware aufeinander ab­gestimmte Technologieplattform be­nötigt.

Das Chip-Set des IO-Link Master

Eingebaute Diagnose­funktionen im smart IO-Link Transceiver.

© Hilscher

Das Chip-Set für den IO-Link Master besteht bei der Hilscher-Lösung aus dem Multiprotokoll-Controller netX 90 und dem smarten IO-Link Transceiver netIOL. 

Dabei zeichnet sich das Chip-Set durch seine Kompaktheit und den hohen Integrationsgrad aus, was zu einer deutlichen Reduzierung von Bauelementen und der Komplexität führt. Eine achtkanalige IO-Link-Masterbaugruppe Class A plus zusätzlichem digitalen Eingang lässt sich so in einem nur 30 mm breiten Gehäuse mit einseitiger Leiterkartenbestückung realisieren.

Der netX 90 hat zwei M4-Kerne und teilt die Software in einen Kommuni­kations- und Applikationsteil auf. Während die Kommunikation als skalierbare Standard-Firmware für Ethernet/IP, Ethercat und Profinet zur Verfügung steht, kann der OEM-Kunde den Appli­kationsteil weitgehend selbst gestalten. Über eine SPI-Schnittstelle werden bis zu vier IOL-Transceiver mit jeweils vier Kanälen bedient. Dabei steuert und überwacht der Rechenkern des netIOL die Ein- und Ausgänge und führt das Fehlerhandling des IO-Link-Protokolls selbstständig aus. Damit wird an jedem IO-Link-Port die kürzeste Zykluszeit des IO-Link-Protokolls von 400 µs erreicht.

Die Edge Connectivity

Die Edge Connectivity im IO-Link Master Device wird durch den zusätzlichen Einsatz des Netzwerk-Controllers netX 4000 erreicht. Auch er verfügt über zwei Rechenkerne: Eine 400 MHz R7 ist zum schnellen Einlesen und Filtern von Echtzeit-Daten aus der Ethernet-Kommunikation nötig; auf dem 600 MHz A9 Dual Core läuft ein gehärtetes Linux mit der Edge-Software. 

Funktional arbeiten IO-Link-Master und Edge Gateway völlig unabhängig voneinander. In einem Gehäuse aufgebaut, ergeben sich weitere Kostenvorteile und vereinfachen die I4.0-Integration sowohl für den OEM als auch für den Anlagenbetreiber. Optional lässt sich das Gerät nachrüsten, durch Tausch des IO-Link Master Device gegen die kompatible, integrierte Gateway-Lösung.

Der smarte IO-Link Transceiver

Der IO-Link-Transceiver enthält vier IO-Link-Kanäle mit jeweils einem Ausgangsstrom von 200 mA. Dieser kann durch einen externen FET auf 2 A verstärkt werden. Alternativ lässt sich dieser Kanal als ein digitaler Ausgang oder Eingang des Typs 1, 2 oder 3 konfigurieren. Zum Schalten der Sensorversorgung L+ ist ein weiterer Gate-Treiber vorhanden. Zusätzlich hat jeder Kanal einen weiteren digitalen Eingang und einen Gate-Treiber. Damit lässt sich der Transceiver auch als universelles IO mit bis zu acht Ein- oder Ausgängen und vier geschalteten L+-Versorgungen betreiben. Die Absicherung der Sensorversorgungen und digitalen Ausgänge erfolgt über individuell programmierbare Strombegrenzungen der Gate-Treiber.

Eine vollständige galvanische Trennung lässt sich mit einem 4-Kanal-SPI-Isolator – etwa für eine Class-B-IO-Link-Schnittstelle erreichen. Alle Ströme und Spannungen der Aus- und Eingänge sowie die Chip-Temperatur an den vier Ausgangstreibern werden gemessen und vom integrierten Prozessor überwacht. Über SPI ausgelesen, stehen sie im Informationsmodel des OPC-UA-Servers allgemein zur Verfügung. Die Zustände der Ein- und Ausgänge beziehungsweise deren Fehlerzustand wird an einer LED-Matrix mit bis zu sechs LEDs pro Kanal angezeigt. Aktuell setzt der Transceiver den Einsatz des netX 90 mit seinem integrierten RISC-Controller zur schnellen SPI-Kommunikation voraus.

Die lokale Konfiguration des Edge Gateways oder des IO-Link Master Device erfolgt mittels Mobile Device, App und Bluetooth-Kommunikation. Entsprechend der konfigurierten Rechte wird die Bluetooth-Kommunikation über eine Blinkfolge am Mobile Device eingeschaltet und über eine blaue LED angezeigt. Diese ist in Form und Größe eines M8-Steckers auf­gebaut und ermöglicht auf einfache Weise den Einsatz in einem IP67-Metallgehäuse.

Für die Konfiguration der IO-Link-Sensoren steht ebenfalls eine App zur Verfügung.

Security by Design

Die Bausteine netX 90 und netX 4000 bieten eine Hardware-basierte Root-of-Trust, auf der Mechanismen wie Secure Boot aufsetzen. Basierend auf modernsten kryptografischen Algorithmen und Schlüsselgrößen – RSASSA-PSS bis zu 4096 Bit, ECDSA bis zu 512 Bit – ermöglicht Secure Boot die Integritäts- und Authentizitätsprüfung jeder einzelnen Software, die auf dem System gestartet wird. Da der Secure-Boot-Vorgang vollständig Hardware beschleunigt ist, werden die Geräte immer noch dem ‚Fast Start Up‘ des Profinet beziehungsweise dem ‚QuickConnect‘ des Ethernet/IP gerecht. Vertrauliche Informationen und vorinstallierte X.509-Zertifikate, welche an die eindeutige Chip-ID des netX gebunden sind, werden sicher in einem TPM-Chip gespeichert. Dies ermöglicht eine sichere und authentifizierte M2M-Kommunikation basierend auf fälschungssicheren Geräte-Identitäten.

Die Bausteine netX 90 und 4000 verfügen über Hardware-basierte Barrieren zwischen den Rechnerkernen. Auf diese Weise ist eine zusätzliche Schutzschicht eingezogen, die verhindert, dass sich Angriffe von einem Core auf den anderen ausbreiten. Das IP67-System wird mit einem ein-gebetteten SSL/TLS-Stack geliefert, der eine gesicherte IIOT-Kommunikation auf Basis von OPC UA oder MQTT Security ermöglicht. Trotz der Komplexität von SSL/TLS lässt sich durch den Einsatz zahlreicher kryptographischer Hardware-Beschleuniger eine hohe Performance erreichen.

Die Basis: Microsoft Azure IoT

Microsoft Azure IoT dient als Basis der Edge-Technologie. Grundlage der Entscheidung für diese Plattform sind folgende Aspekte:

• Damit die Datenhoheit beim Gateway-Betreiber liegt, sollten die Gerätedaten von den Prozessdaten bereits im Edge Gateway getrennt behandelt werden. Während die Prozessdaten durch entsprechende Konnektoren in unterschiedliche IT/Cloud-Plattformen geliefert werden, erfolgt die allgemeine Verwaltung der Geräte durch eine zentrale, in der Public Cloud bereitgestellte Lösung.
• Die Edge-Plattform sollte eine offene, einfache und gut dokumentierte Schnittstelle bekommen, die grundsätzlich jedem OEM ermöglicht, seine Geräte an die Plattform anzubinden, auch wenn dabei keine netX-Technologie zum Einsatz kommt.
• Die modulare Software-Architektur des Edge Gateways sollte auf Basis von Docker-kompatiblen Containern erfolgen, die aus einer zentralen Stelle einfach auf den Geräten bereitgestellt werden können.
• Die Basistechnologie auf den Edge Gateways sollte als Open Source frei erhältlich sein und den Einsatz von OPC UA so einfach wie möglich gestalten.

Die Hilscher-Lösung orientiert sich an der ‚Microsoft Azure IoT Reference Architecture‘ mit dem Einsatz der ‚Azure IoT Edge Services‘ und diverser Azure Services und SDKs. Sie ist eine hybride Cloud- und Edge-IoT-Lösung für das Gerätemanagement und die Datenintegration im industriellen Internet der Dinge. Sie besteht aus einem zentralen cloudbasierten Gerätemanagement im Edge Portal und der dezentralen Datenverarbeitung im Edge Gateway.

Die Public Cloud wird in Rechenzentren der Microsoft-Azure-Region West-Europa gehostet.

Das Edge Gateway

Die Software-Architektur und das Zusammenspiel zwischen Edge Gateway und Portal.

© Hilscher

Das Gateway basiert auf einem gehärteten Linux-Betriebssystem mit einer Sammlung von Diensten, die eine intelligente Edge-Lösung bereitstellt. Betriebssystemspezifische Funktionen zur Konfiguration des Gateways werden über einen Gateway-Configuration-Service abstrahiert. Die IoT-Edge-Dienste ermöglichen die bidirektionale Kommunikation zwischen den Edge Gateways und dem zentralen Edge Portal. Unter Einhaltung von Sicherheitsstandards wird das Gateway mit Hilfe des Edge Agent befähigt, Docker-kompatible Software-Module zu empfangen, auszuführen und die Ergebnisse zu kommunizieren. Diese Module lassen sich durch die Edge Runtime zu produktiven Daten-Pipelines verknüpfen, die effizient und voneinander unabhängig über einen lokalen Nachrichtenbroker kommunizieren. Ein Software-Modul definiert lediglich die Ein- und Ausgänge seiner Nachrichten, anschließend können diese per Konfiguration in eine spezielle Reihenfolge zusammengeführt werden.

Das Edge Portal

Das Edge Portal verbindet und verwaltet die Feldgeräte von einer zentralen ­Stelle aus. Es ermöglicht die Überwachung und Konfiguration der Geräte sowie die ­Funktionserweiterungen des Edge Gateways durch Ausrollen und Ausführen von Docker-kompatiblen Software-Modulen. Zur Netzwerk-Diagnose stellt Hilscher ein Modul zur Verfügung, weitere Module können durch den OEM oder Third Partys erstellt werden. Das Portal ist eine offene und flexible White-Label-Plattform, die auf das Corporate Design des OEMs angepasst oder um zusätzliche Funktionalitäten unter Verwendung der REST API und SDKs erweitert werden kann.

Die Technologie-Plattform

Die Technologie-Plattform, umgesetzt in eine Systemlösung

© Hilscher

Die netField-Technologie-Plattform hat zum Ziel, dem OEM zu ermöglichen, seine Komponenten mit einem überschaubaren Aufwand und möglichst geringer Time-to-Market in eine Industrie-4.0-gerechte Systemlösung zu überführen. Aufbauend auf der Basistechnologie bringt der OEM seine speziellen Anforderungen und sein Know-how ein und differenziert sich so im Markt. Die eingesetzte Chiptechnologie garantiert eine lange Lieferverfügbarkeit.

Bereits heute sind die Technologien TSN und OPC UA berücksichtigt. Die Umsetzung oder Integration in das System erfolgt, sobald die Spezifikationen stabil und umfänglich standardisiert sind.

Autor:
Hans-Jürgen Hilscher ist Geschäftsführer der ­Hilscher-Gesellschaft für Systemautomation.