ResilientSOA
Resiliente Architekturen für Kognitive Systeme

Kognitive Systeme teilen ihre Umgebung mit weiteren Teilnehmern wie Menschen, Tieren und anderen Systemen. Der Kernstück der sicheren Bewegungsplanung ist daher das Problem der Erkennung von Teilnehmern und der Vorhersage künftigen Verhaltens in realistischen Szenarien.

Zur Wahrnehmung ihrer Umgebung bestehen kognitive Systeme aus einer enormen Anzahl von Sensoren, die eine Reihe verschiedener Daten über einen bestimmten Zeitraum generieren. Diese Daten beinhalten Unsicherheiten, die vom System abzuschätzen sind, um die physische Welt zu beherrschen und mit ihr zu interagieren. In diesem Zusammenhang spielen resiliente Architekturen eine wichtige Rolle, indem sie die Infrastruktur für kognitive Systeme schaffen, Daten korrekt klassifizieren und dadurch neue Lösungen bereitstellen. Forscher haben in den letzten vier Jahrzehnten entsprechende Architekturen untersucht und vorgeschlagen, die bei einer Vielzahl an Ansätzen das Ziel haben, die kognitiven Fähigkeiten des Systems wie Wahrnehmung und logisches Denken durch Safety Contracts zu beherrschen.

Resiliente Softwarearchitektur

Bei CPS sind die kognitiven Fähigkeiten typischerweise in der MAPE-K-Feedbackschleife (Monitor-Analyze-Plan-Execute over a shared Knowledge) enthalten. Die Integration und die Organisation der Komponenten zur Ausführung des Zyklus wird durch das selbstanpassende Verhalten der Architektur ermöglicht. Insbesondere bei verteilter Adaptierung muss die Architektur definieren, wie Informationen und ihre Verarbeitung in Komponenten organisiert wird und wie der Informationsfluss zwischen den Komponenten abläuft. Die Entwicklung resilienter Architekturen bringt damit die folgenden Herausforderungen mit sich:

• ADAPTIERUNG: Resiliente Architekturen müssen in Bezug auf ihre Dienste und Fähigkeiten dynamisch sein. Einerseits können sich Dienste über einen Zeitraum entwickeln, d. h. neue Dienste werden gebildet, während andere entfallen. Andererseits werden Fähigkeiten durch Informationen beschrieben, die im Laufe der Zeit variieren und damit eine adaptive Klassifizierung durch die Architektur erfordern.
• REPRÄSENTATION: Eine weitere Herausforderung besteht darin, ob die Fähigkeit direkt durch den eingebetteten Prozess unterstützt wird oder stattdessen durch die Architektur bereitgestellt wird. Entwicklungsentscheidungen beeinflussen, welche Fähigkeiten aus Erfahrung erlernt werden und welche auf spezialisierten Diensten beruhen.
• OPTIMIERUNG: Die Architektur zielt darauf ab, die optimale Konfiguration für ein bestimmtes Problem zu finden. Dies erfordert die kombinatorische Optimierung von Diensten – und das ist generell schwierig. Daher müssen wir bei einem bestimmten Optimierungsproblem die richtige Dienstkonfiguration für einen bestimmten Zeitraum ausführen.

In dieser Richtung wurden bereits einige Anstrengungen unternommen. Mögliche Fehler während der Erfassungsphase können jedoch nicht wiederhergestellt werden und die Quantifizierung von Unsicherheiten ist noch ein ungelöstes Problem.

Resiliente Knoten im Blickpunkt

In unserem letzten Blog, ResilientSOA, haben wir die Dienstorchestrierung durch eine periodische Rekonfiguration der Knoten beschrieben. Jeder Knoten hat eine bekannte Schnittstelle, die auf Basis eines Zustandsautomats ausgeführt wird; dadurch haben Entwickler nur die Möglichkeit, vorgegebene Zustände zu ändern, zum Beispiel inaktive/aktive Zustände. In diesem Blog werden die Begriffe Knoten und Dienst gleichbedeutend verwendet.

Zustände werden in Primär- und Übergangszustände unterteilt. Je nach gewählter Strategie des Service-Managers werden Übergangszustände durch einen Befehl im Primärzustand erreicht, wobei das Ergebnis des Übergangszustands eine positive oder negative Antwort ist, je nachdem, ob der Knoten einen neuen Primärzustand erreicht hat oder nicht.

AKTIVER ZUSTAND: Der Knoten wird ausgeführt und ist in der Lage, seine Fähigkeiten zur Erfüllung eines Contracts bereitzustellen. Die Verantwortung zur Verwaltung der Knotenfähigkeiten und Validierung der Contract-Anforderungen liegt beim Manager. Wenn diese Anforderungen nicht erfüllt werden, kann der Manager den Knoten je nach Reaktionszeit deaktivieren oder abschalten.

INAKTIVER ZUSTAND: Der Knoten wurde konfiguriert und wartet darauf, ausgeführt zu werden. Der Manager verwendet spezifische Dienste, um den Status des Knotens abzufragen und den Knoten aktivieren oder bereinigen zu lassen, unabhängig davon, ob die Konfiguration die Contract-Anforderungen erfüllt oder nicht.

UNKONFIGURIERTER ZUSTAND: Der Knoten wurde angelegt und wendet sich an den Manager für den Registrierungsprozess. Der Knoten hat Namen, Typ und Fähigkeiten über den Registrierungsdienst bereitzustellen. Danach werden spezifische Dienste zur Verwaltung des Knotens und Überprüfung seines Status erstellt.

FINALISIERT: Das ist der letzte Zustand vor der Löschung. Unterschiedliche Gründe können zur Finalisierung des Knotens führen, z. B. Redundanz, Nichtbeantwortung oder Degradierung.

Anwendungsfall: mobiler Roboter

In einem Projekt betrachtet das Fraunhofer-Institut für Kognitive Systeme IKS einen mobilen Roboter in der Lagerlogistik, bestehend aus einer Kamera und einem LIDAR. Zusätzlich zu den geforderten Tätigkeiten wie Pick&Place interagiert das System mit der physischen Welt in sicherheitskritischen Umständen, bei denen viele Probleme auftreten können. Falls zum Beispiel ein unbekanntes Objekt (Out-of-Distribution) vor das System positioniert wird, ist die Kamera nicht in der Lage, es zu erfassen, und nur die restlichen Sensoren können Informationen bereitstellen.

Die Architektur muss daher den Output aller Sensoren berücksichtigen, um Beziehungen zwischen den Daten zu klassifizieren, Unsicherheiten zu erkennen und mögliches Verhalten vorherzusagen. Mit unserem Ansatz führt jeder Knoten eine Fähigkeit über einen Contract aus und der Manager validiert und assoziiert die Zuverlässigkeit konsequent mit den aktuellen Daten.

Anpassungsfähigkeit als Hauptvorteil

Ein Hauptvorteil dieser Konfiguration für Cyber-Physical Systems ist ihre Anpassungsfähigkeit. Die Architektur kann sich selbst an die aktuelle Lage anpassen und beliebige Dienste aktivieren oder deaktivieren, wenn die bereitgestellten Daten nicht zufriedenstellend sind.

Eine Systemkonfiguration auf Basis einer serviceorientierten Architektur ist darüber hinaus skalierbar und benutzerfreundlich, da die Dienste problemlos durch neue Versionen ersetzt und zu Redundanzzwecken dupliziert werden können. Ein weiterer wichtiger Vorteil ist die Resilienz der Architektur durch die Laufzeit-Validierung der Safety Contracts. Diese Eigenschaft garantiert ein sicheres Systemverhalten, weil alle Daten innerhalb einer sicheren Operational Design Domain abgegrenzt sind und kontinuierlich durch den Service-Manager überwacht werden.

Im Screencast auf der linken Seite sehen wir einen Festo Robotino, der sich in der Webots-Simulationsumgebung bewegt. Der Lidar-Sensor und die Messungen des Convolutional Neuronal Networks (CNN) werden in einem Rviz-Datenvisualisierungstool auf der rechten Seite bzw. am unteren Rand angezeigt. Der Status jedes Knotens – CNN, Lidar und Steuerung – ist einer bestimmten Farbe zugeordnet und wird oben im Screencast durch grafisch dargestellt. In diesem Zusammenhang entspricht Blau dem »unkonfigurierten« Zustand, Hellgrün dem »inaktiven« Zustand und Dunkelgrün dem »aktiven« Zustand.

Zu Beginn der Simulation werden die Knoten gestartet und gehen vom »unkonfigurierten« in den »aktiven« Zustand über. Nach einiger Zeit wird das CNN vom Manager aktiviert und ist in der Lage, ein besseres Verständnis der Umgebung zu vermitteln, indem es beispielsweise die Kisten im Regal klassifiziert. Die Kartons werden mit einem grünen Rahmen gekennzeichnet, wenn die Objekte in der Distribution sind, und mit einem roten Rahmen, wenn sie nicht in der Distribution sind.

Dieses Vorhaben wurde im Rahmen des Projekts Unterstützung des thematischen Aufbaus des Instituts für Kognitive Systeme durch das Bayerische Staatsministerium für Wirtschaft, Landesentwicklung und Energie gefördert.