Wie in Unterkapitel 4.2 und 4.3 gezeigt, lassen sich die Ursachen fehlender Generalisier-barkeit in drei Kategorien gliedern: Ursachen, die sich vermeiden lassen; Ursachen, die sich direkt überprüfen lassen und Ursachen, die sich weder vermeiden noch direkt überprü-fen lassen. Für die ersten beiden Kategorien werden in Unterkapitel 4.2 bereits konkrete Vermeidungs- bzw. Überprüfungsmaßnahmen definiert. Problematisch gestaltet sich aller-dings die Überprüfung der Ursachen, die in die dritte Kategorie (C) fallen. Eine Lösungs-möglichkeit besteht in der Überprüfung der Auswirkungen dieser Ursachen, d.h. der hie-raus resultierenden fehlenden Generalisierbarkeit selbst. Der Vorteil an dieser Möglichkeit besteht darin, dass hierdurch nicht nur die Ursachen der Kategorie C überprüft werden, sondern ebenfalls gleichzeitig die Ursachen der anderen Kategorien. Falls beispielsweise eine Vermeidungsmaßnahme nicht korrekt implementiert wurde und eine Ursache trotz durchgeführter Maßnahme noch immer vorliegt, wird deren Auswirkung ebenfalls berück-sichtigt. Zusätzlich werden auch Ursachen überprüft, die bisher noch nicht bekannt sind bzw. die im Rahmen des Fehlerbaums aus Unterkapitel 4.1 nicht identifiziert werden.
Hierdurch ist ebenfalls die Problematik, dass dieser Fehlerbaum keinen Anspruch auf Voll-ständigkeit besitzt, gelöst.
Es ist möglich, durch die Überprüfung der Auswirkungen auf die anderen Methoden zur Vermeidung bzw. direkten Identifikation der Ursachen zu verzichten. Allerdings wird dies im vorgestellten Vorgehen nicht empfohlen, da der Aufwand in der Änderung des gelern-ten Modells aufgrund fehlender Generalisierbarkeit geringer ist, wenn die Ursachen früher im Entwicklungsprozess identifiziert werden. Abbildung 5-1 verdeutlicht das hieraus resul-tierende, stufenweise Vorgehen.
Abbildung 5-1: Gesamtansatz
Um die Auswirkungen der Ursachen bzw. die fehlende Generalisierbarkeit direkt zu über-prüfen, werden zwei Methoden genutzt: Die Überprüfung von funktionalen Anforderungen auf der einen Seite und die Überprüfung von Anforderungen hinsichtlich der Robustheit des gelernten Modells auf der anderen Seite. Funktionale Anforderungen stellen Anforde-rungen an das Verhalten eines gelernten Modells unter festgelegten Bedingungen dar.237 Ein Beispiel hierfür stellt im Rahmen einer Fußgängerdetektion die Anforderung dar, dass ein Objekt eine Ausdehnung von maximal 250 cm besitzt, um als Fußgänger klassifiziert zu werden. Durch ihren Funktionsbezug sind funktionale Anforderungen problem- bzw.
aufgabenspezifisch. Im Rahmen einer konventionellen Programmierung werden diese An-forderungen im Vorfeld an das zu entwickelnde Modul gestellt und hierauf basierend die Implementierung durch den Programmierer vorgenommen. Anschließend wird die Erfül-lung dieser Anforderungen durch das entwickelte Modul überprüft. So sieht es ebenfalls die anforderungsbasierte Vorgehensweise des V-Modells, welches von der ISO 26262 ge-fordert wird, vor. 238 Wie bereits diskutiert, besteht diese Notwendigkeit der Funktionsspe-zifikation im Rahmen gelernter Modelle nicht mehr, da die notwendige Funktionalität im-plizit durch die Trainingsdaten spezifiziert wird.239 Für die Überprüfung der Generalisier-barkeit werden diese funktionalen Anforderungen dennoch benötigt und auch Salay und Czarnecki240 fordern die Aufstellung dieser Anforderungen. Problematisch hierbei ist, dass ML vor allem dann eingesetzt wird, wenn Aufgabenstellungen nicht komplett spezifizier-bar sind.241 Zudem ist es möglich, dass die Aufstellung der funktionalen Anforderungen, auch wenn sie von Experten vorgenommen wird, unvollständig ist. Natürlich existiert das
237 Vgl. Balzert, H.: Nichtfunktionale Anforderungen (2011), S. 109.
238 Siehe Abschnitt 2.1.2.
239 Siehe Unterkapitel 3.2.
240 Salay, R.; Czarnecki, K.: Using Machine Learning Safely in Automotive Software (2018).
241 Vgl. Salay, R.; Czarnecki, K.: Using Machine Learning Safely in Automotive Software (2018), S. 7.
Kategorie A:
Ursachen, die während des
Entwicklungsprozesses vermieden werden
können.
Kategorie B:
Ursachen, deren Existenz direkt überprüfbar ist.
Kategorie C:
Ursachen, deren Existenz nicht direkt
überprüfbar ist.
Qualität der Daten, Methoden
und Prozesse sicherstellen
Direkte Überprüfung von
Ursachen
Überprüfung von Auswirkungen
Problem der möglichen Unvollständigkeit der funktionalen Anforderungen auch bei bishe-rig eingesetzten konventionell programmierten Modellen. Allerdings wird zusätzlich zu deren Überprüfung ein gewachsenes Testkollektiv verwendet, um alle möglichen in der Realität vorkommenden Situationen zu überprüfen und hierdurch eine mögliche unvoll-ständige Spezifikation zu kompensieren.242 Da zum Training von gelernten Modellen mög-lichst viele, realitätsnahe Daten zu nutzen sind, ist es sinnvoll, dieses erwähnte Testkollek-tiv zum Training des Modells heranzuziehen. Hierdurch steht es jedoch nichtmehr zur Eva-luation zur Verfügung. Selbst wenn dieses Testkollektiv nicht zum Training genutzt wird, enthält diese Testdatensammlung nicht die neuen Gefahren, die bei der Nutzung neuer Funktionalitäten, die durch gelernte Modelle möglich werden, auftreten (siehe schraffierte Fläche der Abbildung 5-2). Daher ist es nicht möglich, diesen bestehenden Ansatz zu nut-zen, um einer möglichen unvollständigen Spezifikation zu begegnen.
Abbildung 5-2: Benötigte Testkollektive im Vergleich
Unter anderem bedingt durch die vorgestellte Problematik der Unvollständigkeit funktio-naler Anforderungen ist es notwendig, die Überprüfung der fehlenden Generalisierbarkeit durch die Überprüfung von Anforderungen hinsichtlich der Robustheit des gelernten Mo-dells zu ergänzen.243 Hierdurch werden Anforderungen, die implizit mit Generalisierbar-keit verbunden werden, explizit überprüft, um hierdurch eine umfassendere Überprüfung der Generalisierbarkeit zu erreichen als alleine durch das Testen der funktionalen Anforde-rungen. Bei konventionell programmierten Modellen ist eine solche Überprüfung nicht erforderlich, da die Generalisierbarkeit und deren implizite Anforderungen durch die ex-plizite Umsetzung der funktionalen Anforderungen gegeben ist und zusätzlich ein
242 Vgl. Singer, C.: Dissertation, Entwicklung von Testauswahlmethoden (2015).
243 Weitere Gründe der Notwendigkeit für Robustheitsanforderungen werden in Unterabschnitt 5.4 vorge-stellt.
Gewachsenes Testkollektiv für konventionelle Programmierung (bisherige Funktionalität)
Benötigtes Testkollektiv für konventionelle Progarmmierung (bisherige Funktionalität)
Benötigtes Testkollektiv ML (bisherige Funktionalität)
Benötigtes Testkollektiv ML (neue Funktionalität)
senes Testkollektiv eingesetzt wird. Ein Beispiel einer solchen impliziten Anforderung stellt die korrekte Funktionalität eines gelernten Modells dar, auch wenn einzelne Datens-ätze aus dem Training entfernt wurden. Diese impliziten Anforderungen haben zum Ziel, die These der Generalisierbarkeit des gelernten Modells zu widerlegen, wodurch sie die Robustheit des Modells auf Änderungen fokussieren. Die zentrale Frage im Aufstellen dieser Robustheits-Anforderungen lautet daher „Wie ist es möglich, das gelernte Modell durch Testfälle oder Änderungen im Entwicklungsprozess so zu stören, so dass falsche Vorhersagen getroffen werden?“
Die Forschungsfrage „Wie ist es möglich diesen Ursachen strukturiert zu begegnen?“ (sie-he Unterkapitel 1.2) wird da(sie-her wie folgt beantwortet:
Durch ein vierstufiges Vorgehen ist es möglich, den Ursachen fehlender Generalisierbar-keit strukturiert zu begegnen. Diese Stufen sind:
1. Sicherstellung der Qualität der Daten, Methoden und Prozesse 2. Direkte Überprüfung von Ursachen
3. Überprüfen von funktionalen Anforderungen 4. Überprüfen von Robustheitsanforderungen
Der Gesamtansatz trägt dazu bei, das Verhalten des gelernten Modells auch bei unbekann-ten Situationen besser einzuschätzen, da die Generalisierung die Extrapolation von Wissen auf unbekannte Bereiche darstellt. Hierdurch wird der Zielsetzung der ISO/ PAS 21448 nachgekommen, die in Abbildung 5-3 dargestellt ist.
Abbildung 5-3: Reduktion der möglichen Fehler gemäß ISO/ PAS 21448244
244 ISO: ISO/ PAS 21448 (2019), S. 8.
Durch die Überprüfung der funktionalen Anforderungen und deren Generalisierbarkeit in nicht durch Daten abgedeckte Bereiche wird bei Bestehen der funktionalen Anforderung der Bereich 4, der bekannten und sicheren Szenarien, vergrößert. Durch Aufdecken der Verletzung funktionaler Anforderungen und anschließender Verbesserung des Modells wird der Bereich 3, der unbekannten unsicheren Szenarien, verkleinert. Die Analyse der Robustheit des Modells vergrößert bei Bestehen der Robustheitsanforderung den Bereich 1, da beispielsweise durch die Veränderungen der Vorverarbeitung der Daten ein breiterer Bereich an Szenarien abgedeckt wird, in denen sicheres Verhalten vorliegt. Bei Verletzung der Robustheitsanforderungen werden Fälle des Bereich 3 aufgedeckt und durch die an-schließende Verbesserung des Modells oder Einschränkung des Betriebsbereichs dieser Bereich verkleinert.