Suchen

Das kognitive Internet der Dinge – Einstieg in eine neue Ära

Seite: 2/2

Firma zum Thema

Per Engineering muss erst eine vernünftige Wissensbasis geschaffen werden

Im Rahmen des Embedded Software Engineering (ESE) geht es eben um Engineering – nicht nur um das fertige, mit dem Internet vernetzte Produkt. Doch auch in dieses, speziell in das Konzipieren und Fertigen Internet-fähiger Geräte, fließen kognitive Themen ein. Die Design- und Build- Phasen mögen in der öffentlichen Wahrnehmung nicht ganz so prominent sichtbar sein, sind aber für die „Maker“ des „Things“ interessant.

Professionelles Engineering startet heute mit den Anforderungen. Diese werden typisch von Menschen erstellt und bestehen oft aus Freitext. Warum also nicht die kognitive Sprachanalyse gegen solche unstrukturierten Anforderungsdokumente laufen lassen, um grundsätzliche Dinge erst einmal sicherzustellen: dass z.B. gegebene Pflichtanforderungen erfüllt sind, die formulierten Anforderungen keine Widersprüche enthalten, nicht mehrmals gleiche Anforderungen formuliert werden, und so weiter. Je komplexer Anforderungsdokumente werden, desto interessanter wird die maschinelle Prüfung – und kognitive Systeme „verstehen“ Inhalte und könnten sogar ermitteln, in welchem emotionalen Zustand der Verfasser die Dokumente verfasst hat. Praktisch relevant ist aber, dass Prüfschritte über unstrukturierte Texte, die früher nur durch Menschen gesichert werden konnten, nun algorithmisch abgesichert werden können.

Wenn man vom Design in die Phase der Produktion (Build) kommt, spielt das kognitive Internet der Dinge eine andere Rolle. Ein Kernaspekt hier ist der Bereich der Qualitätssicherung z.B. mit Kameras. Die Technologie an sich ist nicht neu und gab es grundsätzlich schon in den 90er Jahren. Allerdings ist inzwischen Rechenleistung deutlich günstiger geworden, so dass solche Verfahren heute relativ leicht auf neue Anforderungen trainiert werden können. Die Technologie ist dahinter ist heute Deep Learning. Aktuell wird diese Technologie bereits eingesetzt, um z.B. Fehler in der Bestückung von Platinen zu erkennen - es kann geprüft werden, ob jedes Bauteil korrekt und am richtigen Platz sitzt. Wenn Rechenleistung auch in Zukunft weiter günstiger wird, lässt sich ihre Anwendbarkeit auch auf andere Anwendungsgebiete ausweiten. So könnte ein automatisiertes System etwa anhand von Videodaten während eines Lackiervorgangs Probleme feststellen, die dann direkt, und nicht erst mit aufwendiger Nacharbeit, behoben werden kann.

Was macht ein „Ding“ zu einem IoT-Gerät?

Wann sprechen wir bei einem Ding von etwas, dass zum „Internet der Dinge" gehört? Die Grundarchitektur des Internet of Things ist eigentlich ganz einfach: Das “Ding“ ist mit dem Internet verbunden; eingehende Informationen muss es nicht zwingend lokal verarbeiten, die Daten werden typisch in der Cloud ausgewertet, beispielsweise in Form von Regeln oder Analytics. Die daraus resultierenden Ergebnisse können meist selbst wieder über das Internet abgerufen werden – beispielsweise via Smartphone-App. Soweit zumindest die Theorie.

In der Praxis sind IoT-Protokolle allerdings stark auf Messaging ausgelegt, z.B. unter Ausnutzung von MQTT (Message Queue Telemetry Transport) für die M2M-Kommunikation. Außerdem verursacht das Senden von großen Datenmengen (wie etwa hochauflösende Bilder oder Videos) aufgrund der notwendigen Bandbreite noch relativ hohe Kosten. Hinzu kommt, dass die Kommunikation aus Gründen der Datensicherheit heute immer abgesichert werden muss, also authentifiziert und verschlüsselt. Für ein Heizkörperthermostat, das vielleicht fünf Mal am Tag seine Temperatur an einen Server schickt, und das vom Smartphone aus eingestellt werden kann, ist das noch ein vertretbarer, überschaubarer Aufwand. Jedoch für komplexere Things, wie ein Schweißroboter oder ein „Connected Car“, sind solche Ansätze nicht tragfähig.

Für diese Art von IoT-Geräten wird fast immer eine Vorverarbeitung am „Thing“ nötig. Der gängige Begriff ist dabei „Edge“, also die Verarbeitung am Rand des Internets. Diese Edge-Rechenleistung kann nur ein einfaches Filtering auf einem kleinen, lokalen Controller darstellen. Es kann aber auch bis hin zu leistungsstarken Servern reichen – oder im Falle von autonomen Autos zu Hochleistungssystemen von Firmen wie NVIDIA, die noch im Auto selbst die vollständige Objekterkennung und weitere visuelle Verarbeitungsschritte durchführen. Wie das letzte Beispiel schon anreißt: In vielen dieser Fälle braucht man schon alleine zum Erstellen von analytischen oder kognitiven Modellen eine umfassende Rechenleistung vor Ort. Das trainierte Modell - die Runtime – läuft dagegen auch auf einfacheren Systemen.

Natürlich braucht man einen Installationsmechanismus, aber die Sicherheitsanforderungen von IoT erfordern dies ohnehin. Ein anderer Aspekt ist auch, dass etwa Bilder oder gar Videos nicht über Messaging Protokolle, sondern über spezialisierte Medien-Protokolle übertragen werden.

Die Architektur für das kognitive IoT ist bereits vorhanden

Das Beispiel eines vernetzten Autos ist auch auf andere Fälle übertragbar, wie beispielsweise eine Qualitätssicherung auf Basis von Bildern in einer Produktion wird nie auf das Internet warten. Die einen treibenden Faktoren für das Edge sind also Latenz und Zuverlässigkeit. Die anderen sind die Möglichkeiten zur Verschlüsselung, Komprimierung und Filterung der Daten, bevor sie ins Internet wandern. Die Wahl des entsprechenden Edge-Device hängt von diesen Anforderungen ab. Ideal positioniert sind hier die Netzwerkhersteller: alles, was bereits auf der Ebene des Netzes erfolgen kann, erzeugt keine zusätzliche Systemlast. Das heißt, die Architektur für ein kognitives Internet der Dinge ist auch bereits da.

Wie kann man nun in die kognitive Welt starten? Großes Potential hierfür birgt das Erschließen von unstrukturierten Datenquellen. Deep Learning ist das aktuell größte Investment aller großen Softwarefirmen, weil eben Rechenleistung billiger und auch über die Cloud dynamisch abrufbar ist. Bereits heute sind eine große Zahl an Machine Learning Technologien in OpenSource verfügbar. Hinzu kommt, dass die Hardware vielfach in Smartphones, Autos und Smart Home Gateways häufig bereits da ist und über APIs für Dritte nutzbar gemacht wird.

Über agile Methoden kann man hier in einem iterativen Ansatz einsteigen. Viele reden hier von minimal „lebensfähigen“ Produkten (MVPs – Minimal Viable Products). Dieser Ansatz ist richtig. Was aber vielfach in dieser agilen Methodik vergessen wird ist, dass ein Mehrwert entstehen muss, dass die Technologie sicher ist und vor allem, dass sie auch sicher bleibt.

Viele Beispiele, die heute erscheinen, sind eher Tests der verfügbaren technischen Möglichkeiten von eher kleineren kognitiven Anwendungen wie etwa Spracheingabe – es geht noch weniger um vollständig durchdachte Lösungen, die einen echten Mehrwert beim Nutzer erzeugen.

Zudem sieht häufig, wenn agilen Methoden angewendet werden, dass diese häufig ein hohes Risiko für IoT-Geräte in Kauf nehmen: selbst wenn sie möglicherweise zehn Jahre oder länger mit dem Internet verbunden bleiben wird ihre Absicherung vernachlässigt, um sie so schnell wie möglich verwirklichen und auf den Markt bringen zu können. Es ist daher immer ratsam, auch in der agilen Welt Anforderungen präzise zu erfassen, die Komplexität der Gesamtlösung bereits zu Beginn vollständig zu dokumentieren sowie die Möglichkeiten der Änderbarkeit und Nachrüstbarkeit der Software insbesondere in den Sicherheitsrelevanten Bereichen wie Zertifikaten im Design zu berücksichtigen. Gerade bei Cloudbasierten Lösungen die darf der Datenschutz insbesondere in Hinblick auf die Privatsphäre des Endverbrauchers – dessen Angewohnheiten sich aus eingehenden Daten analysieren lassen – nicht unterschätzt werden. Hier gilt es, hier Szenarien für mögliche Angriffe und Cyberattacken vorauszuplanen und somit bereits im Vorfeld eine angemessene Abwehrreaktion parat zu haben.

Das Internet der Dinge ist ein wichtiger Spielplatz, der auch in Zukunft riesiges technologisches Potential beinhaltet. All das aufgeführte soll nicht den Enthusiasmus für dieses Feld bremsen; ganz im Gegenteil. Es soll vielmehr sicherstellen, dass die Freude eines internetfähigen Produkts lange anhält und Ihnen und Ihren Kunden den Erfolg bringt.

* Steffen Hartmaier ist IT-Architekt bei IBM Deutschland.

(ID:45003754)