Komponentenspezifikation & Checkpoint-Strategie

Die Komponentenspezifikation leitet sich in erster Instanz aus den Anforderungen an das Gesamtsystem und aus dem Systemmodell ab. Es werden konkrete Anforderungen an die Subsysteme erstellt und mögliche komponentenspezifische Lösungsansätze erdacht. Diese Lösungsansätze werden während der Phase des Entwicklungszyklus überprüft und weiterentwickelt werden.

Checkpoints dienen zur Synchronisation des Entwicklungsstands aller Komponenten sowie zum Testen des Zusammenspiels der Subsysteme innerhalb des Gesamtsystems. Zu diesem Zweck findet hier eine (Teil-)Integration der Subsysteme statt, mit entsprechenden Verifizierungs- und Validierungstests bezüglich der Anforderungen an das Gesamtsystem. Da die Entwicklung jedes Subsystems ein eigenes Vorgehen erlaubt, ist ein unterschiedlich schneller Fortschritt je Komponente zu erwarten. Nicht alle Komponenten müssen aktiv an jedem Checkpoint teilnehmen.

Bei der Festlegung, wann und nach welchen Kriterien ein Checkpoint stattfindet, können unterschiedliche Strategien verfolgt werden. Obwohl auch eine klassische Meilensteinplanung möglich ist, die viele Vorteile hinsichtlich der Planbarkeit birgt, wird ein agileres Konzept empfohlen. Der Unterschied von Checkpoints zu formalen Meilensteinen ist, dass nicht zwingend ein definierter Entwicklungsstand vorgegeben werden muss. Hinsichtlich der Checkpoint-Planung sind folgende Strategien möglich:

Die featurebasierte Strategie:

Ein bestimmtes Feature oder eine bestimmte Anforderung sollen bis zum nächsten Checkpoint umgesetzt werden. Diese Strategie orientiert sich an der Umsetzung der sogenannten „User Story“ im agilen Vorgehensmodell SCRUM. Wichtig ist, dass während der Entwicklung nur Designentscheidungen getroffen werden, die zur Umsetzung des Features und zur Erreichung eines Minimalproduktes (Minimum Viable Product) notwendig sind. So werden schlussendlich Kosten bei Umentscheidungen gespart.

Die reifegradbasierte Strategie:

Ein Checkpoint ist immer dann erreicht, wenn mindestens zwei Subsysteme einen bestimmten Reifegrad erworben haben. Reifegrade können hier z. B. sein:

  • Vorläufige Analyse (Proof of Concept)
  • Sicherstellen von Grundfunktionalitäten
  • Erfüllung der Leistungsmetriken (KPI)
  • Leistungssteigerung/-optimierung
  • Optimierung der Nutzerfreundlichkeit

Je nach Anwendungsfall können die Reifegrade weiter spezifiziert und unterteilt werden. Sie stellen somit Zwischenziele auf dem Weg zum fertigen Produkt dar.

Die zeitbasierte Strategie:

Ein Checkpoint ist zu einem regelmäßigen Zeitpunkt erreicht, z. B. immer nach einer Woche. Hier besteht die Herausforderung, dass die Arbeitspakete bis zum nächsten Checkpoint so gewählt werden, dass dann eine (Teil-)Integration mit allen Neuerungen möglich ist. Da jedoch nicht alle Komponenten zusammen an einem Checkpoint teilnehmen müssen, sind auch hier verschiedene Zeitintervalle je Komponente möglich.

Sowohl bei der Verfolgung einer Strategie als auch bei der Kombination verschiedener Strategien ist es wichtig, dass im Verfeinerungsschritt der jeweils nächste Checkpoint klar definiert wird. Dazu gehören die Fragen, welche Subsysteme an der (Teil-)Integration teilnehmen und wann ein Checkpoint erreicht ist.

 

Leitfragen

  • Welche komponentenspezifischen Lösungsansätze sollen verfolgt werden?
  • Welche Informationen stehen dem KI-Subsystem als Eingabe zur Verfügung (Feature-Vektor)?
  • Welche Güte muss das KI-Subsystem erreichen und wie erfolgt der Nachweis?
  • Welche Datengüte muss zu welchem Checkpoint vorliegen, damit die KI-Subsystem-Entwicklung voranschreiten kann? Wie erfolgt der Nachweis der Güte?

Ergebnisse

  • Dokumentation aller initialen Spezifikationen
  • Dokumentation der Strategie für die Checkpoints

→ Zur nächsten Phase von PAISE®: Entwicklungszyklus

← Zurück zur vorherigen Phase von PAISE®: Funktionale Dekomposition

 

Schematische Darstellung des zeitlichen Ablaufs der Subsystementwicklung zusammen mit den drei definierten Zwischenzielen

Die in der funktionalen Dekomposition beschriebenen Subsysteme werden in dieser Phase genauer spezifiziert. Die Spezifizierung wird im folgenden Entwicklungszyklus weiter verfeinert oder falls nötig geändert. Im Detail sollen zur Umsetzung die folgenden Technologien zum Einsatz kommen:

Zum Trainieren des ML-Modells müssen Anlagedaten versuchsabhängig persistiert werden. Für den hier vorliegenden Fall der Schüttgutsortierung werden nur 1-D Signale aufgezeichnet. Daher wird hier eine Zeitreihendatenbank verwendet.

Als zentraler IoT-Hub wird auf einen MQTT-Broker zurückgegriffen. Die einzelnen Nachrichten werden in Form von .json Dateien nach festem Schema (Identifier, Zeitstempel, Wert) übertragen.

Für die Entwicklung der Web-Applikation soll auf ein aktuelles Webframework zurückgegriffen werden und nach aktuellem Stand der Technik responsive sind. Neue Messdaten sollen in Form von „push“ Nachrichten auf die Oberfläche übertragen werden.

Hinsichtlich der ML-Aufgabe handelt es sich um eine klassische Anomalieerkennung. Daher sollen hier Standardbibliotheken wie Tensorflow oder PyTorch eingesetzt werden. Zur Erstellung der ML Verarbeitungspipeline soll auf das Framework von ML4P – Machine Learing 4 Production zurückgegriffen werden. Das letztendliche Deployment der Modelle erfolgt letztendlich über Container.

Checkpoints & Zwischenziele

Zur Umsetzung der Software, werden die folgenden Zwischenziele definiert:

  • Zwischenziel 1: Aufbau der Datenbank und des IoT Hubs sind abgeschlossen. Gelabel-te Versuchsdaten sind in der Datenbank vorhanden und werden zum Trainieren des ML-Modells bereitgestellt.
  • Zwischenziel 2: Eine erste Version der ML-Pipeline wurde in Betrieb genommen und mit einer ersten Web-Applikation verbunden. Die ML-Pipeline kann im laufenden Betrieb getestet werden.
  • Zwischenziel 3: Das Gesamtsystem wird aufgebaut und getestet, sodass ein 24/7 Betrieb möglich ist.

 

→ Zur nächsten Phase von PAISE® am Beispiel TableSort: Entwicklungszyklus

← Zurück zur vorherigen Phase von PAISE® am Beispiel TableSort: Funktionale Dekomposition

Folgende Tabelle stellt die Aspekte der reifegrad- und feature-basierten Strategie für die Checkpoints gegenüber:

 

Feature-basierte Strategie Reifegrad-basierte Strategie
Im Folgenden sind beispielhaft 2-3 Features für jede Komponente dargestellt, die innerhalb der ersten Entwicklungszyklen umgesetzt werden sollen. Ein Checkpoint findet statt, sobald eine Integration einer der weiterentwickelten Komponenten möglich ist. Im Folgenden sind exemplarisch ein paar Reifegrade des Gesamtsystems in Stichpunkten charakterisiert.
Kamera:
  • Erarbeitung geeigneter Spezifikationen (Auflösung, Bildfrequenz, etc.)
  • Beschaffung Prototyp
  • Bestimmung optimaler Einbau-Position
Proof of Concept:
  • Versuchsfahrzeug mit Kamera-Prototyp
  • Detektor und Entscheider wurden auf CityscapesDatensatz entwickelt
  • Bremseingriff über Serien-AEB-Schnittstelle
  • Testfahrten auf dem Versuchsplatz
Datensätze:
  • Auswahl Datensatz (Cityscapes)
  • Schnittstellen-Anbindung zum Detektor
  • Erhöhung Übereinstimmung mit Zielanwendung durch Synthetische Erzeugung neuer Kamerabilder
Umsetzung 70% der Anforderungen:
  • Umzug auf Kamera-Zielsystem
  • Noch kein embedded Rechner im Fahrzeug sondern dedizierte Recheneinheit auf dem Beifahrersitz
  • Einsatz des realen Zielfahrzeugs im Entwicklungsstadium
  • Testfahrten auf dem Versuchsplatz
Detektor:
  • Abgleich mit Kameraspezifikation
  • Schnittstellenanbindung an Entscheider
  • Verifizierung mit realen Kameradaten
Umsetzung 90% der Anforderungen:
  • Hardware- und Software in Zielarchitektur vorliegend
  • Performanz des Notbremssystems noch unbekannt
  • Tests im Realverkehr mit Sicherheitsfahrer
Entscheider:
  • Schnittstellenanbindung an Detektor
  • Verifizierung auf reale Daten des Detektors
Umsetzung 100% der Anforderungen
  • Fertig entwickeltes Gesamtsystem mit bekannter und den Anforderungen entsprechender Performanz
Bremssteuerung:
  • Erarbeitung geeigneter Spezifikation
  • Verifizierung der Bremsumsetzung auf dem Prüfstand
 

 

Bei der Behandlung des Beispiels in nachfolgenden Phasen wird die feature-basierte Strategie gewählt. Zu jedem Verfeinerungsschritt werden Ziele und Features für jede Komponente erarbeitet, die bis zum nächsten Checkpoint umgesetzt werden sollen.

Beispiele für die initialen Komponentenspezifikationen für die Komponenten „Datenbank mit Cityscapes-Datensatz" und „Detektor" sind jeweils auf den Seiten 20 und 24 im Zusammenhang mit den entsprechenden Vorgehensweisen während der Entwicklung ausgeführt.

→ Zur nächsten Phase von PAISE® am Beispiel Notbremssystem: Entwicklungszyklus

← Zurück zur vorherigen Phase von PAISE® am Beispiel Notbremssystem: Funktionale Dekomposition

 

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.