Anforderungen & Lösungsansatz

Beschreibung

In dieser Phase werden die Anforderungen an das Gesamtsystem analysiert und mögliche Lösungsansätze zur Umsetzung definiert.

Aus den Anforderungen an das Produkt werden hier erstmals Ideen zu möglichen Lösungsansätzen abgeleitet. Dies findet noch auf der High-Level-Ebene statt. In dieser Phase können sich auch mehrere Lösungsansätze ergeben, die hinsichtlich ihrer Realisierbarkeit bewertet werden.

Im weiteren Entwicklungsprozess wird dann zunächst an dem Ansatz gearbeitet, der am realistischsten erscheint, und dieser weiter verfeinert. Wenn die Entscheidung getroffen wird, KI-basierte Lösungsansätze zu verwenden, müssen in dieser Phase in Zukunft auch Anforderungen aus gesetzlichen Regulierungen berücksichtigt werden. Beispiele für solche zusätzlichen Anforderungen sind Dokumentationspflichten, wie z.B. konzeptionelle Entscheidungen bezüglich Verfahren zur Sicherstellung der Datenhoheit, Datenverwaltung, Datenerfassung- und Datenaufbereitung oder die Einführung eines Risikomanagementsystems.

Leitfragen

Welche Risiken für Schäden an Mensch und Umgebung müssen berücksichtigt werden?
Auf Basis welcher Daten soll das System Erkenntnisse liefern oder Entscheidungen treffen?
Wer soll die Rechte an den Daten haben?
Zu welchem Zeitpunkt soll aus Daten gelernt werden?
Soll die KI aktiv Prozesse steuern können?
Für welche Anforderungen kann KI ein Lösungsansatz sein?
Ist ein gesteigertes Maß an Nachvollziehbarkeit (Erklärbarkeit) der KI-Anwendung gewünscht/nötig?

Ergebnisse

Priorisierte Systemanforderungen
Anforderungen an den Entwicklungsprozess
Auswahl des am realistischsten erscheinenden Lösungsansatz für das Gesamtsystemätze
Feststellung des Nutzens und Schwerpunkts der KI im Lösungsansatz und dem Projekt
Erste Risikobewertung des Systems
Einordnung des Systems nach Autonomiegrad
Vertragliche Regelungen für Datennutzung

→ Zur nächsten Phase von PAISE®: Funktionale Dekomposition

← Zurück zur vorherigen Phase von PAISE®: Ziele & Problemverständnis

Tablesort – Anwendungsfall Produktion

Anzeige des Systemzustandes auf einem Bildschirm

Welche Anforderungen soll das Gesamtsystem erfüllen?

Die grundlegende Systemanforderung ist, im laufenden Betrieb zu erkennen, ob einzelne Ventile auf der Ventilleiste übermäßig beansprucht werden. Wird eine übermäßige Beanspruchung er-kannt, soll der Anlagenbediener darüber in Kenntnis gesetzt werden. Im Detail lassen sich hieraus die folgenden Anforderungen an das System ableiten:

Erkennung, ob die Ventile auf der Leiste ungleichmäßig beansprucht werden. Dies erfolgt durch das Training eines Maschinellen Lernverfahrens auf einem Datensatz gleichverteilter Schüttgü-ter. Bei dem ML-Verfahren soll es sich um ein unüberwachtes Lernverfahren handeln, d.h. es soll lediglich erkennen, ob sich die Anlage in einem “normalen” oder “abnormalen” Zustand be-findet.
Ausgabe der Ventilbeanspruchung mindestens alle 5 Sekunden
Der Hinweis an den Bediener erfolgt durch eine Web-Applikation. Der Zugriff auf die Applikati-on soll geräteübergreifend möglich sein.
Der Zugriff auf die Anlagedaten erfolgt über OPC-UA im laufenden Betrieb.
Zur Entwicklung der ML-Pipeline sowie zum Testen neuer Verfahren soll es möglich sein, in die Applikation historische Daten einzuspielen.

Welchen Autonomiegrad soll das zu entwickelnde System haben?

Das System ist ein Assistenzsystem, welches Informationen an den Bediener übermittelt und die-ser auf Basis der Empfehlung des Assistenzsystems eine Entscheidung trifft.

Welche Risiken für Schäden an Menschen und Umgebung müssen berücksichtigt werden?

Auf Grund des geringen Autonomiegrades ergeben sich keine Risiken beim Einsatz der Software.

Gibt es Risiken für den Fall dass die Anwendung ausfällt?

Nein, dann ist nur einfach der Ausgangszustand wieder vorherrschend.

Für welche Anforderung kann ML ein Lösungsansatz sein?

Zur Erkennung, ob die Ventile auf der Leiste ungleichmäßig beansprucht werden

Auf Basis welcher Daten soll das System Informationen geben oder Entscheidungen treffen?

Die Daten bestehen aus Sensorwerten und unterliegen keiner besonderen Vertraulichkeitsstufe.

Zu welchem Zeitpunkt soll aus Daten gelernt werden?

Die Erstellung der Architektur des ML-Verfahrens sowie das Trainieren erfolgt offline. Das Lernen erfolgt ebenfalls vor der Inbetriebnahme und nicht im laufenden Betrieb.

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

← Zurück zur vorherigen Phase von PAISE® am Beispiel TableSort: Ziele & Problemverständnis

Notbremssystem – Anwendungsfall Mobilität

Im Rahmen dieser Phase wird erarbeitet, dass das System so zuverlässig arbeiten soll, dass es kritische Situationen ohne das Eingreifen von Fahrerin oder Fahrer zu 99 Prozent sicher auflösen kann.

Schäden können sowohl durch falsch-negative Auslösung eintreten (keine Vermeidung des Auffahrunfalls) sowie durch falsch-positive Auslösung (Unfälle durch unnötiges Notbremsen) entstehen. Das System soll nicht während der Fahrt weiterlernen, sondern nur im Bedarfsfall durch Hersteller-Updates bei jährlichen Wartungsterminen aktualisiert werden.

Das System verfügt über eine hohe Autonomie über die Längsführung des Fahrzeugs, um Fahrerin oder Fahrer bei mangelnder Aufmerksamkeit zu unterstützen und es verlässt sich nicht darauf, dass Fahrende selbst rechtzeitig bremsen. Umgekehrt können Fehlauslösungen in der Regel durch die Fahrenden nicht mehr rechtzeitig abgebrochen werden. Die reguläre Fahraufgabe (Distanzregelung, Querführung) hingegen übernimmt das System nicht. Es besteht die Einschätzung dass KI für die Objekterkennung und die Distanzschätzung genutzt werden kann, aber auch, dass für die Zulassung eine ausführliche Nachvollziehbarkeit der Ergebnisgüte gegeben sein muss.

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

← Zurück zur vorherigen Phase von PAISE® am Beispiel Notbremssystem: Ziele & Problemverständnis