Im Gartner Hype Cycle for Emerging Technologies haben Plattformen für das Internet der Dinge den Gipfel der überzogenen Erwartungen – Peak of Inflated Expectations – fast erreicht. Trotzdem existiert bisher keine allgemein gültige Definition für einen IoT-Sensor oder ein IoT-Sensor-System. Eine Internet-Suche mit der Zeichenfolge ‚IoT Sensor‘ bringt zwar zigtausend Treffer, verdeutlicht aber auch das breite Technologie- und Anbieterspektrum in diesem Bereich. In einigen Foren werden beispielsweise die Begriffe ‚Smart Sensor‘ und ‚IoT Sensor‘ miteinander verknüpft, obwohl auch ein ‚Smart Sensor‘ je nach Sichtweise sehr unterschiedliche Eigenschaften besitzen kann. Bei den IoT-Sensor-Systemen reichen die Beispiele vom ‚Body Sensor Network for Healthcare Systems‘ über ‚Industrial Wireless Sensor Networks for Data Collection‘ bis hin zur nahezu unüberschaubaren Vielfalt spezieller Lösungen diverser Anbieter für vertikale Märkte. 

Standards, wie die IEEE-1451-Sammlung mit ihren verschiedenen Substandards, sind aus IoT-Sicht offenbar veraltet und daher in diesem Bereich praktisch ohne Relevanz. Noch nicht einmal die durchaus brauchbaren Ideen des IEEE-1451.4-basierten Transducer Electronic Data Sheet (TEDS) finden in IoT-Anwendungen bisher irgendeine Beachtung. Ein Grund dafür dürften auch die völlig unterschiedlichen Innovationsgeschwindigkeiten im Internet der Dinge und der IEEE als internationales Standardgremium sein. Ein Versuch, über ein neu zu gründendes Anbieterkonsortium einen entsprechenden IoT-Sensor-Standard zu schaffen, ist 2016 offensichtlich über die Verbreitung einer Pressemeldung nicht hinausgekommen.

Eine Orientierung zu universellen Smart Sensors, wenn auch in einer sehr frühen Phase, bietet der AMA Verband für Sensorik e. V. in Deutschland. In der Mitte des Jahres 2018 erschienenen Studie ‚Sensor Technologien 2022‘ beschreiben die Autoren die Funktionseinheiten eines Smart Sensor und liefern Beispiele, wie sich ein solcher Sensor grundsätzlich realisieren lässt. Die AMA-Sicht lässt sich mit minimalen Erweiterungen durchaus als Vorlage (Template) für einen generischen IoT-Sensor nutzen. Die AMA setzt sich in der Studie auch mit der Bedeutung und den Funktionen eines Embedded-Systems in smarten Sensoren auseinander.

Das AMA-Dokument geht davon aus, dass die gesamte Firmware eines Smart Sensors im Rahmen eines konventionellen Embedded-Software-Entwicklungsprozesses erstellt wird. Das setzt voraus, dass der Zusammenhang zwischen den Sensoreingangsvariablen (Sensor Element Input) und dem gewünschten Ausgangswertebereich beim Entwicklungsbeginn vollständig bekannt ist und von den beteiligten Software-Entwicklern auch für ein Embedded-System codiert werden kann. Hinsichtlich einfacher Sensorelemente, zum Beispiel Temperatur, Luftfeuchte, Druck und einer überschaubaren Sensor-Fusion mag diese Vorgehensweise noch funktionieren. Für zukünftige smarte Sensoren, die aus den Rohdaten verschiedener Sensorelemente mit Hilfe deskriptiver und prognostizierender Datenanalysen oder neuronaler Netze quasi in Echtzeit komplexe Zustände und Muster sicher erkennen und daraus Ausgangswerte ableiten sollen, hingegen nicht. Aufgrund der Komplexität entstehen dann Sensoren, die lediglich Rohdaten mit Hilfe geeigneter Protokolle direkt an Edge- oder Cloud-Systeme weitergeben (Sensor-to-Cloud-Lösungen mit einem Sensor-Daten-Streaming). Die eigentliche Informationsgewinnung wird in andere Ebenen verlagert, weil dort leistungsfähige Rechnerplattformen und entsprechende Services zur Verfügung stehen. Das setzt allerdings entsprechend schnelle Kommunikationsverbindungen (Ethernet, 4G, in Zukunft 5G), eine leistungsfähige Energieversorgung und einen kontinuierlichen Ausbau der Internetbandbreite voraus. Ein gravierender Nachteil ist, dass die aus den Sensordaten gewonnenen Informationen nicht direkt an der Kommunikationsschnittstelle des Embedded-Systems zur Verfügung stehen, sondern in der Edge beziehungsweise Cloud. Des Weiteren ist dieses Verfahren nicht für zeitkritische Sensordatenauswertungen geeignet.

Künstliche Intelligenz eingebettet

Durch Spamfilter in E-Mail-Programmen und den Sprachassistenten von Amazon, Apple, Google, Microsoft sowie anderen Anbietern sind Produkte mit integrierten Algorithmen aus dem Umfeld der künstlichen Intelligenz (KI) nach und nach zu Massenanwendungen geworden. Die Entwicklung der KI wird von Forschern inzwischen sogar als Universaltechnologie angesehen und hinsichtlich der zu erwartenden Auswirkungen auf eine Stufe mit den Erfindungen der Dampfmaschine, Elektrizität und dem Verbrennungsmotor gestellt. Nicht nur selbstfahrende LKW und PKW, sondern praktisch alles, was mindestens einen Microchip enthält, wird in Zukunft auch KI-basierte Funktionen besitzen. Gleiches gilt für Anwendungssoftware: Jede Smartphone-App, PC-Tabellenkalkulation oder Enterprise-IT-Anwendung beinhaltet früher oder später KI-Algorithmen – in vielen Fällen ist das sogar schon längst Stand der Technik. Diese Entwicklung wird auch die Eigenschaften von Sensoren nachhaltig verändern. 

Der gegenwärtige Stand der Technik für IoT-Sensor-Systeme ist, die Sensordaten mit Hilfe spezieller Protokolle wie REST, MQTT, CoAP und LWM2M per Internet als Stream an eine Cloud zu übermitteln und dort weiter zu verarbeiten. Solche Sensor-to-Cloud-Applikationen mit herkömmlichen Sensoren sind weltweit inzwischen millionenfach im Einsatz. In der Cloud stehen je nach Plattformanbieter unterschiedliche Services zur Verfügung, um aus den Sensordaten die gewünschten Informationen zu gewinnen. Dabei kommen auch Machine-Learning- und Deep-Learning-Algorithmen zum Einsatz, um beispielsweise Sensorrohdaten zu klassifizieren. Die Ergebnisse, also die Ausgabedaten eines Klassifizierungsalgorithmus, werden per Internet vielfach an ein IoT-Device geschickt, das sich in nächster Nähe zur Sensordatenquelle befindet. Ein typisches Beispiel wäre eine Sensor-Aktor-Kombination in einem Cyber-Physical-System der Gebäudeautomatisierung, bei dem sich Sensor und Aktor im gleichen Gebäude befinden, der benutzte KI-Algorithmus eines Cloud-Service aber auf einem einige tausend Kilometer entfernten Server. Sowohl Sensor als auch Aktor sind zum Beispiel per 4G-Mobilfunk mit dem Internet verbunden. Wenn man sich nun vorstellt, dass als Sensorelement ein 32x32-Bit-RGB-Image-Sensor dient, um zehn verschiedene Objekte mit Hilfe des Klassifizierungsalgorithmus sicher zu identifizieren und die Umgebung entsprechend dem identifizierten Objekt zu beeinflussen, wird sehr schnell deutlich, dass für jede Objekt-Erkennung insgesamt 32x32x3 Bits = 3072 Bits plus Protokoll-Overhead vom Sensor an die Cloud übertragen werden, obwohl das diskrete Ergebnis, also eine Objekt-ID aus dem Bereich 1 bis 10, sich mit Hilfe von 4 Bits darstellen lässt. Wir haben es also hier mit einem konzeptionell bedingten 768-fachen Netto-Daten-Overhead pro Transaktion zu tun. Die insgesamt sehr ineffiziente Nutzung des Übertragungskanals ist in diesem Sensor-to-Cloud-Beispiel deutlich erkennbar.

Der Daten-Overhead und andere Gründe haben dazu geführt, dass sich neben den Sensor-to-Cloud- inzwischen Sensor-to-Edge-Lösungen beziehungsweise das Fog Computing etablieren. Dabei wird für Sensoren, Aktoren und andere Devices innerhalb einer lokalen Umgebung ein spezielles Rechnersystem (Edge Gateway) installiert, das für alle Devices direkt, also ohne Internetzugriff, erreichbar ist. Auf dem Edge Gateway kommen die gleichen Machine-Learning- und Deep-Learning-Algorithmen wie in der Cloud zum Einsatz. Die Analyse und Auswertung beziehungsweise Bewertung der IoT-Sensordaten, zum Beispiel mit Hilfe des statistischen Lernens (Klassifizierung, Regression, Vorhersage von Wahrscheinlichkeiten, neuronale Netze zur Datenklassifikation) erfolgen dann nicht in der weit entfernten Cloud, sondern in direkter Nähe der Datenquellen.

Durch einen KI-Algorithmus werden Sensoren in die Lage versetzt, die Sensorrohdaten der Sensorelemente mit Hilfe eines Machine-Learning-Modells oder neuronalen Netzwerks in Echtzeit zu bewerten und eine bestimmte Information am Ausgang zu liefern.

 

© SSV Software Systems

Klassifizierungs- und Regressions-Algorithmen sind etablierte Bestandteile des überwachten (Supervised) Machine Learning und des Deep Learning im Zusammenhang mit Convolutional Neuronal Networks (CNNs oder auch ConvNets, damit sind sogenannte ‚neuronale Faltungsnetzwerke‘ gemeint) sowie Binarized Neuroural Networks (BNNs). Diese Algorithmen lassen sich auch direkt in einen IoT-Sensor einbetten und ohne eine Verbindung zu Cloud und Edge Gateway nutzen. Bei CNNs ist allerdings zu berücksichtigen, dass durch die tiefe Verschachtelung (CNN Hidden Layer) dieser künstlichen Neuronen-Netzwerke zum Teil beachtliche Rechner-Ressourcen im Embedded-System des IoT-Sensors benötigt werden. Deep Convolutional Neuronal Networks mit zahlreichen Hidden Layers, wie sie zum Beispiel von Google und Co. mit TensorFlow zur Bild- und Spracherkennung genutzt werden, sind zum gegenwärtigen Zeitpunkt für den direkten Einsatz in Sensoren ungeeignet. Ebenfalls weniger für den direkten Sensoreinsatz geeignet ist das unüberwachte (Unsupervised) Machine Learning. Die dafür zur Verfügung stehenden Algorithmen versuchen in den Eingabedaten bisher unbekannte Muster zu erkennen. Diese automatische Segmentierung (Clustering) kann aber bei der Vorbereitung des Praxiseinsatzes eines KI-basierten IoT-Sensors eine wichtige Rolle spielen. 

Als Fazit lässt sich festhalten: Die Sensorik ist IoT-bedingt stark im Umbruch. Allgemeingültige Spezifikationen wären für die Sensor-Hersteller wie auch -Anwender dringendst erforderlich. Es reicht allerdings nicht aus, bestehende Smart-Sensor- und Sensor-to-Cloud-Lösungen einfach zum Standard zu erklären. Dringend erforderlich ist das Einbeziehen weiterer Themen, wie die künstliche Intelligenz und eine dem Stand der Technik entsprechende Security.

Autor:
Klaus-Dieter Walter ist Mitglied der Geschäftsführung bei SSV Software Systems.