Funktionale Dekomposition

In der dritten Phase werden die Funktionen des Gesamtsystems auf Subsysteme initial heruntergebrochen, mit dem Ergebnis einer meist hierarchischen Subsystemspezifikation mit wohldefinierten Schnittstellen. Ergänzt wird diese durch die Spezifikation zusätzlich benötigter Hilfssysteme.

Die in den Anforderungen an das Gesamtsystem definierten Funktionen werden auf Subsysteme verteilt. Die Granularität der Unterteilung hängt hierbei stark von der Komplexität des Systems ab. Einhergehend mit der Zerlegung erfolgt die Definition wohldefinierter Schnittstellen.

Neben der Betrachtung des Gesamtsystems werden in dieser Phase Hilfssysteme (engl. Enabling Systems) spezifiziert, die nicht Teil des ausgelieferten Systems sind, jedoch aber für dessen Entwicklung notwendig sind.

Wichtig ist, hervorzuheben, dass Relationen zwischen Komponenten, also zwischen Hilfs- und Subsystemen, sehr unterschiedlicher Natur sein können. Hier können Energieflüsse (z. B. Strom, Hydraulik, Druckluft), Informationsflüsse (z. B. Daten), Kraftflüsse und Materialflüsse wirken.

Abbildung 3 zeigt ein Beispiel für eine solche Zerlegung. Hierbei ist hervorzuheben dass Komponenten auch als Datenquellen agieren können. Als Datenquellen werden Sub- oder Hilfssysteme verstanden, die Daten für die Entwicklung und/ oder für den Betrieb liefern und somit maßgeblich die Funktionalität der KI-Komponenten beeinflussen.

Die Entscheidung, welches Subsystem KI-basiert ist, kann entweder mithilfe von Erfahrungen während der initialen funktionalen Dekomposition getroffen werden oder während des Entwicklungszyklus, in dem die Verfeinerung der initialen Dekomposition vorgesehen ist. Wichtig ist, zu beachten, dass die Entscheidung, KI zu verwenden, Teil des Lösungsansatzes und nicht Teil der Anforderungen ist. Zusätzlich kann sich während der Entwicklung die Notwendigkeit ergeben, dass weitere Hilfssysteme oder Subsysteme hinzugezogen werden müssen. Ebenso können Komponenten wegfallen, falls diese nachweislich nicht mehr benötigt werden. Es ist daher wichtig zu erwähnen, dass die erste funktionale Dekomposition nicht final ist. Sie wird für die ersten Iterationen des Vorgehens genutzt und sollte anschließend angepasst werden. Die funktionale Dekomposition unterstützt die genaue Zweckbestimmung von sowohl klassischen Komponenten, wie mechanischen und elektrischen Systemen, als auch von KI-basierten Komponenten.

 

Leitfragen

  • Welche Subsysteme übernehmen welche Funktionen?
  • Welche Hilfssysteme werden für die Entwicklung der Subsysteme benötigt?
  • Welche Funktion kann voraussichtlich von einer KIKomponente übernommen werden?
  • Welche Datenquellen gibt es für das Training, das Testen und den Betrieb der KI-Komponenten?

Ergebnisse

  • (Hierarchische) System- und Hilfssystemspezifikation
  • Verortung der Datenquellen und Datensätzefür Training, Test und Laufzeit der KI-Sub- bzw. KI-Hilfssysteme
  • Definition der Schnittstellen zwischen Subsystemen und Hilfssystemen
  • Schematische Darstellung der Entwicklungsumgebung

 

→ Zur nächsten Phase von PAISE® Komponentenspezifikation und Checkpoint-Strategie

← Zurück zur vorherigen Phase von PAISE® : Anforderungen & Lösungsansatz

Schematische Darstellung des Systemmodells für die zu entwickelnde Digi-Plattform des TableSort
Schematische Darstellung des Systemmodells

Gemäß den oben genannten Anforderungen soll das Gesamtsystem, die folgenden Funktionen erfüllen:

  • Extrahieren der Daten vom TableSort
  • Evaluierung der Verteilung der Ventilauslastung
  • Ausgabe der Ergebnisse an ein beliebiges Anzeigegerät

Dabei gehören der TableSort und das Anzeigegerät zum Supersystem, befinden sich also außerhalb der Systemgrenzen des zu entwickelnden Gesamtsystems. Abbildung 1 zeigt skizzenhaft das Systemmodell. Relationen zwischen den Systemen sind durch gerichtete Pfeile dargestellt, die anzeigen, in welche Richtung ein Austausch stattfindet. Die Art der übertragenen Information ist in den jeweiligen gelben Kästen enthalten. Schnittstellen sind als hellgrüne Kästen skizziert.

Die drei oben aufgeführten Funktionen des Gesamtsystems werden durch die folgenden Sub-systeme bedient:

  • IoT-Hub: Extrahieren der Daten vom TableSort
  • ML-Subsystem: Evaluierung der Verteilung der Ventilauslastung
  • Applikation: Ausgabe der Ergebnisse an ein Anzeigegerät

Wie in Phase 2 "Lösungsansatz" definiert, wird das ML-Modell nur während der Entwicklung und der Wartung trainiert. Dies erfordert die Speicherung von akkumulierten Trainings- und Test-datensätzen, welche in dedizierten Experimenten, also Betrieb unter kontrollierten Bedingungen, gewonnen werden. Die Speicherung der Trainings- und Testdaten findet in einer Daten-bank statt, die nur während der Entwicklung und Wartung zum Einsatz kommt.

Während des regulären Betriebs des TableSort werden die Daten zur Laufzeit abgegriffen und direkt ausgewertet. Es findet keine Zwischenspeicherung statt.

Hier nicht dargestellt ist die Hardware-Architektur, auf der die digitale Plattform läuft. Möglich ist eine Installation in einer Cloud-Umgebung oder on premise auf einem handelsüblichen PC.

 

→ Zur nächsten Phase von PAISE® am Beispiel TableSort: Kompontentenspezifikation und Checkpoint-Strategie

← Zurück zur vorherigen Phase von PAISE® am Beispiel TableSort: Anforderungen & Lösungsansatz

Schematische Beschreibung des Systemmodells für das Beispiel Notbremssystem
Schematische Beschreibung des Systemmodells für das Beispiel Notbremssystem

Die Dekomposition ergibt das in der Abbildung (links) gezeigte Ergebnis.

Im Detektor werden in den von der Kamera aufgenommenen Bildern Objekte identifiziert. Im Entscheider wird eine Einschätzung der Distanz- und Relativgeschwindigkeit der Objekte vorgenommen und darauf basierend eine Entscheidung zur Notbremsung getroffen. Fällt diese Entscheidung entsprechend aus, wird ein Auslösesignal an die Bremssteuerung gesendet, die die hydraulisch-mechanische Bremsauslösung überwacht. Die Bremse ist nicht mehr Teil des ausgelieferten Gesamtsystems, sondern wird über eine vordefinierte Schnittstelle mit der Bremssteuerung verbunden.

Der Detektor und der Entscheider sind KI-basierte Subsysteme. Die Montageposition der Kamera am Auto soll über ein KI-basiertes Hilfssystem optimiert werden. Weiterhin sollen Daten von der Kamera, sobald diese verfügbar ist, in einer internen Datenbank gespeichert werden, um Trainingsdaten für die Entwicklung des Detektors verfügbar zu machen. Da jedoch die Kamera nicht von Anfang an zur Verfügung steht, wird der Detektor zunächst auf Basis von synthetisierten Kamerabildern und mit einem extern verfügbaren Datensatz von Verkehrssituationen namens „Cityscapes“ entwickelt. Der Cityscapes-Datensatz wird ebenso bei der Entwicklung des Entscheiders eingesetzt. Im dargestellten Beispiel sind „Kamera“, „Interne Datenbank“, „Synthese von Kamerabildern“ und „Datenbank mit Cityscapes-Datensatz“ Datenquellen.

→ Zur nächsten Phase von PAISE® am Beispiel Notbremssystem: Komponentenspezifikation und Checkpoint-Strategie

← Zurück zur vorherigen Phase von PAISE® am Beispiel Notbremssystem: Anforderungen & Lösungsansatz

 

Zuück zur interaktiven Grafik in der Gesamtübersicht

Schulungen

Sie würden gern von unseren Expert*innen mehr über PAISE® oder ähnliche Themen lernen? Dann stöbern Sie in unserem Schulungskatalog nach einem passenden Angebot.