Suchen

Künstliche Intelligenz mit gesundem Menschenverstand umsetzen

| Autor / Redakteur: Rainer Duwe * / Sebastian Gerstl

Künstliche Intelligenz (KI) steht derzeit in allen Marktsegmenten hoch im Kurs. Besonders autonome Fahrzeuge und Systeme setzen auf KI. Hier stellt sich jedoch auch die Frage nach möglichen Grenzen. Über KI, gesunden Menschenverstand und den DDS-Standard.

Firmen zum Thema

Künstliche Intelligenz wird immer zugänglicher und findet in immer mehr Bereichen praktische Anwendung. Aber ist es immer sinnvoll, künstliche Intelligenz einzusetzen? Und welche Rolle haben Datenaustausch und Konnektivitätsstandards dabei zu spielen?
Künstliche Intelligenz wird immer zugänglicher und findet in immer mehr Bereichen praktische Anwendung. Aber ist es immer sinnvoll, künstliche Intelligenz einzusetzen? Und welche Rolle haben Datenaustausch und Konnektivitätsstandards dabei zu spielen?
(Bild: Gerd Altmann/gemeinfrei / Pixabay )

Das Thema ethische Entscheidungen ist eng mit der KI verknüpft. Denn autonome Systeme und insbesondere autonome Fahrzeuge müssen mit ihrem Umfeld und den Menschen interagieren. Während sich viele Situationen antrainieren und mit KI vorausberechnen lassen, entstehen jedoch auch immer wieder Situationen, in denen das autonome Fahrzeug (menschliche) Hilfe von außen benötigt, weil alle erlernten Situationen und Algorithmen ins Leere laufen.

Ein Beispiel ist hier ein autonomes Fahrzeug beim ungeregelten Linksabbiegen, d. h. ohne Abbiegespur oder Ampelregelung. Dieses ungeregelte Linksabbiegen stellt eine unerwartet komplexe und schwierige Aufgabe dar. Deshalb bekommen beispielsweise Paketdienstfahrer in den USA oftmals Routen „nur rechts herum“ vorgegeben. Auch Baustellen oder schlicht verkehrswidrig parkende Fahrzeuge und andere Engstellen können die Algorithmen vor „unberechenbare“ Herausforderungen stellen. Solange noch ein Fahrer an Bord ist, kann dieser eingreifen. Aber was machen voll autonome Fahrzeuge der Stufe 5?

Solange die Welt noch nicht aus perfekt programmierten autonomen Fahrzeugen in einer Smart City mit weitreichender C2X-Kommunikation besteht (und das wird vermutlich noch sehr lange sein), erfordert es gesunden Menschenverstand – in Form von Tele-Operations oder ähnlichen Remote-Eingriffen. Hierzu benötigt man offene und dennoch zuverlässige und sichere Konnektivitätskonzepte.

Der Weg zum vollautonomen System

Die Entwicklungsprojekte der klassischen OEMs und Tier-1 waren noch vor zwei bis drei Jahren oft auf Einzelaspekte fokussiert: Infotainment, von einfachen Assistenzsystemen zu autonomen Systemen der Stufe 3 und 4 oder einfache Backend-Kommunikation vom Fahrzeug in die Cloud. Auf dem Weg zum vollautonomen System wurde sehr schnell deutlich, dass diese separaten Ansätze nicht wirklich zielführend sind und auch nicht alle neuen Anforderungen, wie zum Beispiel Tele-Operations, abdecken. Neben der reinen funktionalen Software-Applikationsentwicklung stellte sich heraus, dass auch leistungsfähige Test- und Simulationslösungen eingebunden werden müssen. Die für neue autonome Fahrzeuge erforderlichen Hunderttausende oder Millionen Testkilometer lassen sich nicht auf unseren Straßen „erfahren“.

Erforderlich ist hier eine durchgängige Konnektivität, die schnell komplex wird. Einfache Protokolle oder auch SOA-Ansätze (Serviceorientierte Architektur) stellten sich als nicht ausreichend heraus. Neue, durchgängige Ansätze für ein „System of Systems“ versprechen deutlich bessere und schnellere Realisierungen hin zum vollautonomen Fahrzeug der Stufe 5. Eine komplexe Lieferkette verschärft zudem die umfangreichen technischen Herausforderungen. Wie integrieren OEMs die Komponenten, die von Tier 1- und Tier 2-Lieferanten bereitgestellt werden, effizient?

Standardbasierte Lösung

Um die Integration in die gesamte Lieferkette zu erleichtern und die Anforderungen an hohe Leistung und Belastbarkeit zu erfüllen, ist eine auf Standards basierende Interoperabilität erforderlich. Eine komponentenspezifische Integrationslogik erhöht den Overhead und beeinträchtigt die Ausfallsicherheit. Peer-to-Peer-Interoperabilität ist erforderlich. Auf Standards basierende COTS-Lösungen bieten das geringste Risiko und eine geringere Haftung für OEMs und Tier-1-Unternehmen im Gegensatz zu selbst erstellten Lösungen.

So wurde die AUTOSAR Adaptive Spezifikation (Release 18.10) 2018 um den Data Distribution Service (DDS), einen offenen Standard der Open Management Group (OMG), erweitert. ROS ist ein beliebtes Open-Source-Projekt, das häufig in der Forschung und in PoC-Anwendungen im Automotive-Bereich zum Einsatz kommt. Die Abstraktionsschicht der ROS2-Middleware (RMW) basiert auf DDS (RTI Connext und andere).

Der Data Distribution Service basiert auf einem datenzentrischen Pub/Sub-Ansatz. Er wurde seit 2004 kontinuierlich weiterentwickelt und ergänzt. Eine Erweiterung ist das DDS-Security-Plug-In, das feingranulare Sicherheit auf Datenebene ermöglicht.

Datenbus und DDS-Standard

Ein Datenbus ist die disruptive Netzwerktechnologie der vierten Generation. Bei einem Datenbus geht es darum, ein System in Bezug auf Daten auszudrücken und Zustandsänderungen an den Daten zu beobachten. Herkömmliche Systeme hingegen kommunizieren Daten über Nachrichten und die Daten werden nachrangig. Da es sich bei IIoT-Systemen um Daten handelt, ist es sinnvoll, die Systeme über Daten und nicht über Nachrichten zu integrieren.

Der Datenbus bietet eine „Single Source of Truth“ und stellt den einzigen Weg dar, um große, komplexe Systeme zu bauen. Datenbanken verhindern zwar Daten-Korruption, aber es geht immer um historische Daten. Der Datenbus hingegen garantiert aktuelle Daten, Timing, Raten, Zuverlässigkeit, Sicherheit – wobei es um zukünftige Daten geht.

Zum Vergleich: Ein Unternehmenssystem würde nie ohne Datenbank implementiert werden. Genauso sollte ein IIoT-System nicht ohne Datenbus implementiert werden.

Der offene DDS-Standard implementiert einen gemeinsam genutzten Datenbus, der eine beliebige Sprache, ein beliebiges Gerät oder einen beliebigen Transport verbindet. Er versteht Datentypen und teilt sie allen Teilnehmern mit. Dabei ist er über Millionen von Datenpfaden skalierbar, erzwingt Millisekunden-Timing, gewährleistet Zuverlässigkeit, unterstützt Redundanz und filtert Informationen selektiv. Jeder Pfad kann Unicast, Multicast, Open Data oder vollständig sicher sein.

Wichtig ist eine Architektur ohne Server. Denn mit einem Server ergeben sich alle möglichen Einschränkungen hinsichtlich Ort, Schnelligkeit, Startup-Reihenfolge, Single Point of Failure, Performance-Flaschenhals uvm.

Dem Applikationsentwickler ermöglicht eine datenzentrierte Architektur das einfachere und flexiblere Gestalten von Programmen. Ein Vorteil der datenbankzentrierten Architektur in verteilten Anwendungen besteht darin, dass das Design ein hohes Maß an Zuverlässigkeit, Leistung und Skalierbarkeit erreicht, besonders wenn die DDS-Implementierung, wie bei RTI Connext, keine Server/Broker benötigt und es somit keinen Single Point of Failure gibt.

Auswahlkriterien

Bild 1: Beispiel für eine autonome Fahrzeugsystemarchitektur. RTI Connext DDS integriert hier alle Komponenten und Frameworks.
Bild 1: Beispiel für eine autonome Fahrzeugsystemarchitektur. RTI Connext DDS integriert hier alle Komponenten und Frameworks.
(Bild: RTI)

Während es eine Reihe von DDS-Anbietern und Open-Source-Projekten gibt, unterscheiden sich deren Implementierungen jedoch erheblich in Leistungsfähigkeit und Qualität. Zu den Auswahlkriterien für eine Anbieterentscheidung sollten u. a. hoher Datendurchsatz und geringe Latenz durch Datenverteilung mit hoher Bandbreite zählen, auch für Daten, die die maximale MTU-Größe des Netzwerks überschreiten. Der Umfang der Quality of Service (QoS) sowie zusätzliche Services und Komponenten können die Standard-Angebote für Tele-Operation und andere Szenarien erweitern. Trotz aller Unterschiede bei den Implementierungen stellen die Anbieter durch regelmäßige Tests die Interoperabilität sicher. Umfang und Leistungsfähigkeit der Entwicklungs- und Analyse-/Debugging-Werkzeuge sind ebenfalls anbieterspezifisch und sollten in die Auswahlkriterien mit einfließen.

Über den Standard hinaus bietet RTI einen Sicherheitszertifizierungspfad für Entwickler. Damit können sie die strengen Anforderungen von ISO 26262 ASIL-D erfüllen, ohne benutzerdefinierte Netzwerkcodes und Zertifizierungsartefakte zu erstellen, und Risiko, Zeit und Projektkosten senken.

Marktsegment Gesundheitswesen

Bild 2: Beispiel für eine IIoT-Architektur im Gesundheitswesen. Eine Gruppe von Systemen einschließlich klinischer Geräte, Informations- und Unternehmenssysteme sowie Datenbanken sind miteinander verbunden.
Bild 2: Beispiel für eine IIoT-Architektur im Gesundheitswesen. Eine Gruppe von Systemen einschließlich klinischer Geräte, Informations- und Unternehmenssysteme sowie Datenbanken sind miteinander verbunden.
(Bild: RTI)

Vor ähnlichen Herausforderungen stehen Marktsegmente wie das klinische Gesundheitswesen. Es gibt immer mehr und immer ältere Patienten, stetig weniger Ärzte und Krankenhauspersonal und immer höhere Kosten. Die Covid-19-Pandemie zeigt deutlich, dass neue Strukturen erforderlich sind. Medizin-Roboter, Tele-Diagnose, Entscheidungsunterstützung sowie verbundene und autonome Geräte werden zunehmend nahe am Patienten zu sehen sein.

Diese Systeme greifen künftig auch verstärkt autonom in die Behandlung ein. Der Schutz der Patientendaten, der Schutz vor Cyberangriffen und eine zuverlässige, hochverfügbare Konnektivität sind hier die Schlüsselanforderungen. DDS-basierte Systeme verbreiten sich auch hier erfolgreich.

* Reiner Duwe ist Sales Manager EMEA bei RTI in München.

(ID:46667109)