Interoperables IoT
Koppeln von Echtzeitelementen
Das IoT fordert, dass interoperable, integrierte und eng zusammengehörige Geräte in Funktions-Clustern zusammenwirken. Dies ist einfach, wenn die Kopplung mit losen Timing-Beschränkungen erfolgt. Bei embedded-Echtzeitsystemen, wie sie für Industrie 4.0 benötigt werden, sieht die Sache anders aus.
Dieser Beitrag untersucht Probleme bei der Kopplung von eingebetteten Echtzeit-elementen unter besonderer Berücksichtigung der Kopplung über das Internet. Protokolle wie MQTT, Twisted Engine von Python, Jini (inzwischen Apache River), Node.js und PBOs werden mit ihren Vor- und Nachteilen vorgestellt. Ziel dessen ist die Beschleunigung der Entwicklung eines offenen Standards und eines Lenkungsgremiums.
Wenn es möglich ist, dass Geräte mittels eines etablierten Kommunikationsstandards über das Internet kommunizieren und dieser Standard Vorbote von Industrie 4.0 und IoT ist, warum sollte es dann nicht auch möglich sein, IoT-Geräte ohne den Umweg über eine proprietäre Cloud-Lösung mit anderen zu koppeln? Wir können jede Bluetooth-basierte Maus mit jedem Laptop verbinden. Genauso sollte es möglich sein, jedes hinreichend beschriebene IoT-Gerät mit jedem Smartphone zu verbinden, ohne dazu auf eine proprietäre Lösung zurückgreifen zu müssen. Beide Enden der Verbindung müssten wissen, wie sie miteinander kommunizieren können, auch wenn die Geräte in verschiedenen Subnetzen im selben oder einem anderen physischen Netzwerk und unabhängig von den verwendeten physischen Medien arbeiten. Das hieße uneingeschränkte Interoperabilität.
Dieser Artikel entstand, weil es keinen offenen und allgemein akzeptierten Standard und keine Spezifikation dafür gibt, wie physikalische Endgeräte in TCP/IP-basierten Netzwerken interagieren können, um Möglichkeiten der Verknüpfung, vielleicht sogar der selbstständigen Verknüpfung zu komplexeren Echtzeitsystemen zu schaffen. Der Artikel soll die Entwicklung eines nicht-proprietären, offenen Standards einläuten und die Möglichkeit für die Entwicklung eines offenen Standards aufzeigen, auf dessen Grundlage jeder oder jede beliebige Gruppe Dienste implementieren kann, über die Geräte unterschiedlicher Hersteller miteinander interagieren können, ohne ein »geschlossenes« System zu benötigen.
In [1] wird geschätzt, dass »aus der Integration, Speicherung, Analyse und Präsentation von IoT-Daten« allein 2015 rund 5,7 Mrd. Dollar erlöst wurden. Für mich klingt das nach einem heftigen Eingriff in die Privatsphäre und einer Marketing-Goldgrube. Mit anderen Worten: Es ist ein gutes Geschäft, das System geschlossen zu halten. Im Gesagten schwingt zudem mit, dass eine solche Geräte-Geräte-Kopplung von den Unternehmen bewerkstelligt werden muss – nicht von Ihnen! Genau das wird eintreten, wenn wir nichts unternehmen. Dieses Szenario ist die Antithese zu meinem Artikel.
In diesem Artikel werden Ausschnitte aus den Forschungsergebnissen und Frameworks für verschiedene Technologien und Techniken aus unterschiedlichen Quellen untersucht. Ich habe Technologien ausgewählt, die mich vor dem Hintergrund des angestrebten Ziels faszinieren. Es gibt noch viel mehr zu beachten, als ich hier in der Kürze erläutert habe. Das ist nicht mehr als ein Anfang, auf dem andere aufbauen können. Im Weiteren erläutere ich in meinem Artikel, was meiner Meinung nach für Kommunikation und Sicherheit benötigt wird. Dann befasse ich mich damit, was für Echtzeitsysteme erforderlich ist, um dann abschließend einige konkrete Implementierungen unter die Lupe zu nehmen, die schon sehr weit sind, aber nicht alle von uns geforderten Merkmale aufweisen.
Konnektivität sowie Erkennung von Geräten und Netzwerken
Die Probleme der Interkonnektivität sind nicht neu [2]. Schon das Open Systems Interconnection Model (OSI) aus den frühen 1980er Jahren war ein erster Versuch, das Konnektivitätsproblem anzugehen; es hat uns gute Dienste geleistet, aber das Problem der Erkennung von Geräten und Netzwerken ist nach wie vor ungelöst.
Die Association for Computing Machinery (ACM) hat zu diesem Thema umfangreich geforscht. Die untersuchten Anwendungen sind breit gefächert und reichen von der Fahrzeugvernetzung bis hin zu stationären, netzwerkfähigen Speichergeräten [3]. Auf der 2012 in Helsinki abgehaltenen ACM-Konferenz gab es Vorträge zum Thema »Fog Networking« [4], und die Princeton University beteiligt sich aktiv an der Entwicklung dieses Konzepts. »Fog« wurde als Bild für das Konzept einer Wolke auf Bodenhöhe gewählt – was eine weitaus umfassendere Konnektivität auf niedrigerem Niveau ermöglicht. Diese Forschung und die Beschäftigung mit dem softwaredefinierten Networking (SDN) [5] könnten durchaus den Rahmen schaffen, den wir letztendlich nutzen werden. Während die theoretische Grundlagenarbeit läuft, kommen jedoch weiterhin proprietäre Lösungen auf den Markt. Was gibt es für den Pragmatiker?
Der Universal Serial Bus (USB) dient als Inspiration für die Erkennungsproblematik. Diese erfolgt zum Teil über hinreichend spezifizierte »Klassen« von Geräten [6]. Dadurch kann nahezu jedes Gerät einfach an nahezu jeden Host angebunden werden. Sobald ein Gerät definiert ist, kann seine Grundfunktionalität für die Nutzung durch eine beliebige Plattform entwickelt werden.
Ein USB-Host übernimmt die Rolle des Gerätekoordinators. Die in [7] implizierten IIoT-Dienste sind Cloud-Dienste, die im Wesentlichen wie Hosts agieren. Die zwingende Notwendigkeit eines Hosts ist jedoch problematisch. Dadurch sah sich das USB Implementers Forum, Inc. veranlasst, USB On-The-Go einzuführen, damit USB-Geräte »sowohl mit USB-Peripheriegeräten als auch direkt miteinander kommunizieren können, wenn kein PC verfügbar ist« [8]. Dasselbe brauchen wir auch für das IoT: eine Kopplung, die direkt von Gerät zu Gerät oder über einen Host oder beides erfolgt
Sicherheit
Themen und Lösungen für die IoT-Sicherheit sind überschaubar. Am häufigsten wird der Advanced Encryption Standard (AES) 128 eingesetzt. Es gibt Grund zu der Annahme, dass jeder ernsthafte Einsatz von IIoT eine Verschlüsselung erfordert. Stellen Sie sich eine Fabrik mit IoT-gekoppelten Geräten vor, die versehentlich oder mit böswilliger Absicht per Mittelmannangriff attackiert werden. Da die meisten IoT-Geräte ihre Verbindungen drahtlos herstellen (z. B. Bluetooth, WiFi, Funk- Modem, LoRa), müssen Verschlüsselung und Authentifizierung Bestandteil eines neuen Standards sein. [9] untersucht einige der damit verbundenen Probleme.
Echtzeitanforderungen
Stewart beschreibt die Anforderungen an eingebettete Echtzeitsysteme [10]. Industrie 4.0 und das IIoT erfordern eine gewisse Echtzeit-Performance, wenn unsere Maschinen und Fabriken auf diese Art gesteuert werden sollen.
Stewart et al. entwickelten ein Framework zur Unterstützung komponentenbasierter Software in einer Abstraktion, die sie Port Based Object (PBO) nannten [11]. Ihr Ziel war die Entwicklung wiederverwendbarer Echtzeit-Softwarekomponenten. IoT-Geräte kann man sich auch als wiederverwendbare Softwarekomponenten vorstellen. Die Logik dahinter ist Folgende: Wenn wir die Interface-Konzepte von Stewart auf das IoT anwenden, hätten wir ein Framework, auf dessen Basis ein Cyber-Physical-System (CPS) entstehen könnte. Da das PBO-Konzept ausgereift ist, sind die Untersuchung seiner Einführung sowie die Gründe, die für und gegen sie sprechen, äußerst ergiebig. Kern dieses Konzepts bildet die Notwendigkeit der Darstellung von Echtzeit-Performance. Im Folgenden werden die Bedingungen erläutert, die das Stewartsche Framework adressiert.
- Koppeln von Echtzeitelementen
- Unabhängige Prozesse
- Verschiedene Frameworks
- Weitere Forschungsprojekte und Protokolle
