1.0 Einleitung
Das industrielle Internet der Dinge (IIoT) besteht aus vernetzten Geräten, die Systeme bilden, welche Daten überwachen, sammeln, austauschen und analysieren können, um intelligentere und schnellere Geschäftsentscheidungen für Industrieunternehmen zu ermöglichen. Die Vorteile der Anwendung von IIoT-Ansätzen auf industrielle Geschäftsprobleme sind enorm, da selbst eine geringe prozentuale Verbesserung in Bezug auf Effizienz, Zeit, Kapitalaufwand und Vermögensallokation zu erheblichen Einsparungen und/oder Umsatzsteigerungen führt. IIoT-Lösungen haben solche prozentualen Verbesserungen bereits unter Beweis gestellt. Die Implementierung
einer IIoT-Lösung erfordert jedoch ein Verständnis ihrer Architektur und ihres Designs. Der Zweck dieses Dokuments ist es, dieses Verständnis für IIoT-Überwachungssysteme zu vermitteln. Beachten Sie, dass IIoT-Systeme sowohl zur Überwachung als auch zur Steuerung eingesetzt werden können. Von den beiden Anwendungsfällen ist die Überwachung in der Regel einfacher einzurichten und zu warten. Zu den
unmittelbaren Vorteilen der IIoT-Überwachung gehören: Fernalarmkontakte bei bestimmten Zuständen, Verlaufsverfolgung und der Wegfall des Zeit- und Arbeitsaufwands für manuelle Überprüfungen. Der Rest dieses Dokuments beginnt mit einer konzeptionellen Architektur für IIoT-Überwachungslösungen in Abschnitt 2.0. Die konzeptionelle Architektur bietet einen Rahmen für die Beschreibung der Optionen für die Designarchitektur, die in Abschnitt 3.0 detailliert beschrieben werden. Eine Auswahlhilfe für die Entscheidung zwischen den Optionen finden Sie in Abschnitt 4.0. Die Übersicht über das Omega
Link-Ökosystem und die Produktlinie in Abschnitt 5.0 zeigt eine Instanziierung der Designarchitektur. Abschnitt 5.0 enthält eine kurze Einleitung in das Thema Edge-Computing, das auf die Verwendung von IIoT für die Steuerung im Vergleich zur Überwachung zurückkommt. Das Thema IIoT-Sicherheit ist von großer Bedeutung. Eine detaillierte
Erörterung dieses Themas wird
in einem
anderen Dokument behandelt, aber wir bieten eine Zusammenfassung der architektonischen Leitlinien im Anhang. Die vorgestellten konzeptionellen und Design-Architekturen (sowie das Omega Link-Ökosystem von Omega) integrieren Sicherheit als wesentlichen Bestandteil ihrer Strukturen. 2.0 Konzeptionelle Architektur 2.1 Überblick Die konzeptionelle Architektur für eine IIoT-Lösung ist in Abbildung 2.1 dargestellt. Ein System wird von einem oder mehreren
Sensoren
überwacht. Das
System und die Sensoren befinden sich vor Ort. Die Informationen dieser Sensoren werden über das Konnektivitätselement an einen Standort außerhalb des Unternehmens in der Cloud gesendet. Wir bezeichnen Daten, die vom Konnektivitätselement zur Cloud übertragen werden, als „Northbound“-Kommunikation und Daten, die vom Konnektivitätselement zu den Sensoren übertragen werden, als „Southbound“-Kommunikation. 2.2 Elemente 2.2.1 Cloud Die Cloud ist der externe Speicher- und Analyseort für die von den Sensoren kommenden
Daten. Sie bietet
auch einen sicheren Benutzerzugriff auf diese Daten, in der Regel über die Anmeldung im Webbrowser. Im Gegensatz zur Speicherung vor Ort, die in der Regel auf den Zugriff an diesem Standort beschränkt ist, sind Cloud-Speicherung und -Analyse über das Internet verfügbar. Der Internetzugang ermöglicht es dem Benutzer oder den
Benutzern,
über einen Desktop-Computer, ein Tablet oder ein Mobiltelefon aus der Ferne auf diese Daten zuzugreifen. Fortgeschrittene Analysen (z. B. maschinelles Lernen) sind ebenfalls verfügbar. 2.2.2 Konnektivität Die sichere Übertragung der Informationen zwischen den
Sensoren und der Cloud
ist die
Aufgabe des Elements „Konnektivität”. Wie im nächsten Abschnitt zu sehen sein wird, ist dieses Element aufgrund der Vielzahl der verfügbaren Optionen und der beteiligten Unterelemente komplex. Ungeachtet der Komplexität bleibt die Aufgabe dieselbe: die sichere Übertragung von Daten. Abbildung 3.1 enthält weitere Details zu den Funktionen Cloud,
Konnektivität
und Sensoren.
Weitere Erläuterungen finden Sie in den folgenden Unterabschnitten. 2.2.3 Sensoren Sensoren dienen dazu, den Zustand des Systems zu erfassen. Das Ziel der IIoT-Lösung besteht darin, die von den Sensoren gesammelten wichtigen Daten in die Cloud zu übertragen, damit sie von Benutzern, die sich nicht am Standort des Systems befinden, weiter analysiert und für Entscheidungen genutzt werden können. 3.2 Sensoren Eines zeigt einen Sensor, der mit einer Mobilfunkverbindung gekoppelt ist und einen direkten Zugriff auf die Cloud ermöglicht. Das andere zeigt eine Sensor-/Transmitter-Kombination, die über eine drahtlose Verbindung eine Verbindung zu einem Gateway herstellt. 3.2.1 Kabelgebunden vs. kabellos Aus Sicht der IIoT-Lösungsarchitektur ist die Unterscheidung zwischen kabelgebundenen und kabellosen Sensoren das wichtigste Merkmal. Die Ausgänge von kabelgebundenen Sensoren können entweder analog oder digital sein. Bei analogen
Sensoren müssen
weiter oben in der Kette Mittel zur Umwandlung der Daten in ein digitales Format für die Übertragung verfügbar sein. Bei digitalen Sensoren muss das Protokoll für die Datenübertragung bekannt sein und von der Konnektivitätslösung unterstützt werden (was wir als „Southbound“-Verbindung bezeichnen). Das digitale Protokoll umfasst sowohl die physischen Komponenten (Kabel, Stecker) als auch das Softwareprotokoll. Weitere Einzelheiten finden Sie im Abschnitt „Konnektivität: Protokolle”. Bei drahtlosen Sensoren sind die Daten ähnlich wie bei
kabelgebundenen Sensoren
mit digitalen Ausgängen bereits konvertiert, sodass Protokolle für das Senden und Empfangen der Informationen festgelegt werden müssen. Darüber hinaus umfassen die physischen Komponenten die Fähigkeit zur drahtlosen Übertragung und zum drahtlosen Empfang. 3.2.3 Arten
der
Sensorik Sensoren erfassen eine Vielzahl von
physikalischen, chemischen, biologischen und nuklearen Phänomenen über eine Reihe von Mechanismen oder Modalitäten. Aus architektonischer Sicht sind die Erfassungsmodalitäten weniger wichtig als die Art und Weise, wie die Informationen vom Sensor zur Cloud gelangen. 3.3 Cloud Die Cloud besteht aus vier Hauptkomponenten: a. Ein Hub , der eine sichere Verbindung zum lokalen System, zur Telemetrie und zur Geräteverwaltung herstellt. Ein Hub ermöglicht die Fernkommunikation zu und von den lokalen Systemen, bei Bedarf über mehrere Standorte
hinweg. Er verwaltet in der Regel
alle Aspekte der Kommunikation,
einschließlich Verbindungsmanagement, sicherer Kommunikationspfad sowie Geräteauthentifizierung und -autorisierung. Außerdem setzt er Verbindungs- und Durchsatzkontingente durch. Telemetriedaten und andere
Nachrichten von Geräten werden
in die Cloud eingegeben, und der Nachrichtenaustausch wird vom Hub vermittelt. b. Speicher zur Aufbewahrung der Daten c. Verarbeitung zur Analyse der Daten d. Bedienerschnittstelle und Visualisierung zur Übermittlung der Analyseergebnisse an den Endbenutzer, in der Regel über eine Webbrowser-Oberfläche,
im Falle von Alarmkontakten jedoch per E-Mail, SMS und/oder Sprachanruf. 1. Sensoren zur Cloud: Der Formfaktor einer
einzelnen Sensor-/Mobilfunk-Einheit ermöglicht eine direkte Verbindung zur Cloud vom Standort aus. 2. Sensoren zum Gateway zur Cloud : Die typischste Konfiguration umfasst ein Gateway (siehe nächster Abschnitt), das die Verbindung zwischen den Sensoren und der Cloud herstellt. Das Gateway verfügt in der Regel über kabelgebundene und kabellose
Verbindungsoptionen. Die drahtlose Option ist in der Regel ein Sensor/Transmitter in Form einer einzelnen Einheit, wie in Abbildung 3.1 dargestellt. 3. Sensoren an Transmitter an Empfänger an Gateway an Cloud: Diese Konfiguration ist typisch für ältere Installationen, bei denen bereits
Transmitter und Empfänger vorhanden
sind und/oder
bei denen eine erhebliche Anzahl von kabelgebundenen Sensoren in einiger Entfernung vom Gateway installiert ist. Ein Gateway kann die Daten im Rahmen der Übertragung auch transformieren. Es unterstützt sichere Kommunikationsprotokolle, die Authentifizierungs- und Autorisierungsinformationen enthalten. Ein Gateway unterscheidet sich von einem Router dadurch, dass es eine aktive Rolle bei der Verwaltung des Zugriffs und des Informationsflusses spielt. Gateways können entweder in Form von Hardware oder Software
instanziiert werden.
3.5.3 Software-Gateways Software-Gateways werden auf PCs installiert. Die Software kann im Vordergrund oder Hintergrund ausgeführt werden und bietet die gleichen Northbound- und Southbound-Kommunikationsverbindungen wie das Hardware-Gateway, wobei die physischen Schnittstellen
vom PC bereitgestellt
werden. Softwarebasierte Gateways können Bedienerschnittstellen für den Zugriff auf die visuelle Sensorkonfiguration und die Anzeige von Sensordaten bereitstellen. Da das Software-Gateway auf einem PC läuft, kann es die lokale Speicherung und Visualisierung von Daten ermöglichen. Ein Fernzugriff ist ebenfalls möglich, wenn die IT-Abteilung einen sicheren Zugriff von außen auf das interne Netzwerk mit dem PC erlaubt. In diesem Fall kann das lokale Software-Gateway die Cloud-Ebene überflüssig machen. 3.6 Konnektivität: Protokolle 3.6.1 Überblick Die Übertragung von Daten über die IIoT-Lösung erfordert die Verwendung von Protokollen. Diese Protokolle müssen klar definiert, sicher und idealerweise dem Industriestandard
entsprechend sein.
Protokollspezifikationen
können einige oder alle der folgenden Punkte umfassen: physikalische Eigenschaften von Steckverbindern und Verkabelung, Aufbau eines Kommunikationskanals, Format der über diesen Kanal gesendeten Daten. Das OSI-Modell (Abbildung 3.6.1 unten) beschreibt das Protokoll als eine Reihe von Schichten, wobei jede Schicht eine bestimmte Funktion hat. 3.6.2 Northbound: Gateway zur/von der Cloud Für die Schnittstelle zwischen dem Gateway und der Cloud stehen mehrere Standardprotokolle zur Verfügung. Einige
gängige Protokolle sind unten zusammen
mit einem zusammenfassenden Diagramm definiert. Hypertext Transfer Protocol (HTTPS) ist das Protokoll des World Wide Web, das für Anfrage-/Antwort-Interaktionen vorgesehen
ist. Das „S“ in „HTTPS“ steht für „Secure“ (sicher). HTTP ist textbasiert und daher recht ausführlich, aber einfach zu implementieren. Advanced Message Queueing Protocol (AMQP) ist ein verbindungsorientiertes, bidirektionales
Multiplex-Protokoll zur Nachrichtenübertragung mit integrierter, kompakter Datenkodierung. Im Gegensatz zu älteren Protokollen wie HTTP wurde AMQP für IIoT-Verbindungen zur Cloud entwickelt. MQ Telemetry Transport (MQTT). MQTT ist ein leichtgewichtiges
Client-Server-Übertragungsprotokoll für Nachrichten. MQTT ist aufgrund seines kompakten Code-Speicherplatzes und der geringen Nachrichtenrahmengrößen für IIoT-Geräte nützlich. Constrained Application Protocol
(CoAP ). Das Constrained Application Protocol ist ein datagrammbasiertes Protokoll, das über eine Transportschicht wie UDP implementiert werden kann. CoAP kann als kompakte Version von HTTP betrachtet werden, die für die Anforderungen des IIoT
entwickelt wurde. 3.6.3 Southbound: Gateway
zu/von Sensoren Ähnlich wie bei den Northbound-Protokollen gibt es auch für die Southbound-Verbindung zwischen dem Gateway und den Sensoren viele Optionen. Zu diesen Optionen gehören die zuvor aufgeführten Northbound-Protokolle. Aufgrund der Einschränkungen der Geräte und der lokalen Gegebenheiten, wie z. B. bereits eingesetzte Produktionssysteme und Netzwerke, handelt es sich jedoch in der Regel um selbst entwickelte oder von einem einzelnen Anbieter für seine Produkte festgelegte De-facto-Standards. Beispiele hierfür sind: Zigbee, Bluetooth, WiFi, USB, SimpliciTI. Diese Protokolle decken verschiedene Bereiche des OSI-Stacks ab. Zigbee beispielsweise spezifiziert die Netzwerkschicht und darüber liegende Schichten, während WiFi nur die Datenverbindungsschicht
und die physikalische
Schicht spezifiziert. Diese Trennung der Funktionen ermöglicht auch eine gewisse Mischung und Kombination von Protokollen. 5.0 Das Omega Link IIoT-Ökosystem Das Omega Link IIoT-Ökosystem ist eine Instanziierung der IIoT-Designarchitektur, wie unten dargestellt. Wie zu erwarten, gibt es drei Schichten: Cloud, Konnektivität (über Gateways) und Sensoren.
Für Gateways gibt es mehrere
Optionen, sowohl Hardware (von Omega und Avnet) als auch Software (OEG). Sensoren sind in verschiedenen Formfaktoren mit kabelgebundenen und kabellosen Verbindungen erhältlich. Es werden sichere Standardprotokolle verwendet, einschließlich Authentifizierung und Autorisierung zwischen Schichten und Geräten. Die Protokolle nutzen AMQP und SimpliciTI, um eine Plug-and-Play-Einrichtung mit Ökosystem-kompatiblen Produkten zu ermöglichen. 6.0 Referenzen Microsoft Azure IoT-Referenzarchitektur, Version 2.1, 26.09.2018. http://www.steves-internet-guide.com/internet-protocol-suite-explained/
http://www.steves-internet-guide.com/iot-messaging-protocols/ https://www.postscapes.com/internet-of-things-protocols/
Anhang A. IIoT-Sicherheit IIoT-Lösungen müssen
vertrauenswürdig sein, um Daten und Informationen mit Integrität
bereitzustellen, da sie kritische Systeme und Umgebungen
überwachen und messen.
Dieses Vertrauen wird durch die Gewährleistung der Sicherheit des Systems gegen Bedrohungen überprüft. Die Bedrohungsmodellierung ist der beste Ansatz für die Entwicklung von Sicherheitslösungen. Anhand einer typischen IIoT-Lösungskonfiguration lassen sich mehrere Zonen identifizieren (Abbildung A.1). Die Grenzen dieser Zonen sind die Stellen, an denen Daten und Informationen von einem Lösungselement zu einem anderen übertragen werden. Bedrohungen richten sich gegen die Grenzen dieser Zonen. Für die Bedrohungsanalyse kann das STRIDE-Modell verwendet werden, das Bedrohungen in die folgenden Kategorien einteilt (siehe Tabelle unten). Eine detaillierte Erläuterung der Verwendung des
STRIDE-Modells würde den Rahmen dieses Leitfadens sprengen. Die Sicherheit einer IIoT-Lösung sollte jedoch mit dieser Methode oder einer gleichwertigen Methode für jede der in Abbildung A.1 dargestellten Zonen überprüft werden.
Was sind Schrittmotoren und Steuerungen? – Omega Engineering Einleitung zu Schrittmotoren
