KI in Embedded Software Wenn das Test-Orakel schweigt

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

KI in Embedded Software führt klassische Tests in die Sackgasse. Warum herkömmliche Traceability nicht mehr reicht, saubere Testdaten Pflicht sind und „metamorphes Testen“ den Karren aus dem Qualitätssumpf zieht.

Künstliche Intelligenz wird immer häufiger ein wichtiger Teil von Embedded-Systemen - vom Fahrerassistenzsystemen bis zum medizinischen Diagnosegerät. Doch mit der neuen Intelligenz kommt eine neue Unsicherheit: Was passiert, wenn das System „lernt“, aber nicht mehr zuverlässig erklärt, warum es welches Ergebnis erzeugt? Wie können wir sicher sein, dass das neuronale Netz korrekt entscheidet, ob ein Sensorwert auffällig ist oder ein MRT-Bild einen Tumor zeigt? Und was nützt jetzt noch ein Zertifikat wie der ISTQB® Certified Tester Foundation Level?

In sicherheitskritischen Bereichen wie Automotive, Pharma oder Medizintechnik sind beispielsweise das Management von Risiken, die Nachvollziehbarkeit (Traceability) und die Wiederholbarkeit von Ergebnissen regulatorisch gefordert. Aber wie geht das in einem System, das weniger auf Logik als vielmehr auf Daten basiert? Und dessen Ergebnisse letztlich von Wahrscheinlichkeiten und Gewichtungen abhängen? Vor allem dann, wenn es ein „lernendes“ System ist?

Die dunkle Seite der KI – Qualität ohne Determinismus?

Die spezifischen Qualitätsprobleme KI-basierter Embedded-Systeme sind vielfältig und komplex. Nicht-Determinismus bedeutet, dass ein- und dasselbe System mit den identischen Eingaben unterschiedliche Ausgaben erzeugt. Das Testorakel, das ein bestimmtes Ergebnis eindeutig vorhersagt, existiert so nicht mehr. In der Industrieautomation kann dies dazu führen, dass ein Bilderkennungssystem mal einen Fehler erkennt, beim nächsten Mal aber nicht. Wie lässt sich hier prüfen, ob das System es zumindest gut genug macht?

„Das System funktioniert“ wird zur Wahrscheinlichkeitsaussage. Klassische QS-Fragen wie „Erfüllt das System die Spezifikation?“ greifen zu kurz, wenn die Spezifikation selbst unscharf ist.

• Robustheit: Wie stabil bleibt das Modell bei Störungen oder Rauschen?

• Transparenz: Ist nachvollziehbar, warum das System entscheidet, wie es entscheidet?

• Fairness: Bevorzugt das Modell unbeabsichtigt bestimmte Datenmuster? (Verzerrung / Bias)

• Vertrauen: Ist das System verlässlich genug, um es in sicherheitskritischen Anwendungen einzusetzen?

Diese Fragen sind nicht nur philosophisch, sondern konkret:

Beispielsweise wird eine KI zur Erkennung von Brustkrebs vorwiegend oder sogar ausschließlich mit MRT-Bildern von Frauen trainiert, wie gut ist also ein durchaus möglicher Tumor der Brust bei einem Mann erkennbar? In einer Embedded-Kamera für Qualitätskontrolle kann eine minimale Veränderung der Beleuchtung zu völlig anderen Entscheidungen führen und damit zu Fehlausschuss oder gar Sicherheitsrisiken.

Auch die sogenannte Konzeptdrift stellt ein Problem dar: verändert sich die Realität mit der Zeit (oder wird auch nur das Wissen über die Realität besser), aber das trainierte Modell bleibt statisch, dann werden die Vorhersagen zunehmend unzuverlässig – im Embedded Umfeld kann das Leben kosten.

Solides Test-Knowhow und darauf aufbauendes Spezialwissen

Bevor man sich den spezifischen Herausforderungen des KI-Testens widmen kann, muss das Fundament stimmen. KI-Testing baut zwingend auf klassischem Software-Test-Wissen auf – ohne dieses Fundament ist eine erfolgreiche Qualitätssicherung KI-basierter Systeme nicht möglich.

Der ISTQB ® Certified Tester Foundation Level vermittelt dieses grundlegende Wissen: Testprinzipien, strukturierte Testprozesse, verschiedene Teststufen und -arten, Testmanagement sowie der Einsatz von Werkzeugen. Entwickler und Tester lernen hier, wie man Testfälle systematisch entwirft, Fehler klassifiziert und Testaktivitäten in den Entwicklungsprozess integriert.

Diese Grundlagen sind nicht optional – der Foundation Level ist bewusst als Zulassungsvoraussetzung für die AI-Testing-Zertifizierung definiert. Denn erst mit solidem Verständnis klassischer Qualitätssicherung können die zusätzlichen Komplexitäten KI-basierter Systeme gemeistert werden. Wer die fundamentalen Testprinzipien nicht beherrscht, wird an den probabilistischen und selbstlernenden Eigenschaften von KI-Systemen scheitern. Leider verstauben aber viele dieser Zertifikate in der Personalakte. Was als Risikoorientiertes Testen bezeichnet wird, ist häufig nur "Dokumentations-Scheinsicherheit": Man nutzt eine Software-FMEA, weil man glaubt, die Regulatorik schreibe diese Methode vor. Das Ergebnis sind oft komplexe Tabellenkalkulationen, in denen Risiken beinahe reflexhaft durch die Maßnahme "Testen" auf "Grün" herabgestuft werden. Die potenziellen Probleme die KI-Komponenten mit sich bringen, werden nicht angemessen berücksichtigt.

Das heißt den Papier-Tiger füttern, aber nicht Risiken managen. Die IEC 62304 fordert ein angemessenes Risikomanagement, gibt aber die Methode bewusst frei (siehe Annex E). Besonders bei der Integration von KI-Komponenten stoßen starre FMEAs mit den immer gleichen generischen Maßnahmen an ihre Grenzen.

Daher ist eine verbesserte Teststrategie zwingend notwendig:

Gezielte Skalierung: Ein wirksames Risikomanagement nutzt die initiale Einstufung, um Test-Tiefe und -Breite exakt dort zu skalieren, wo die kritischen Risiken liegen. Zudem werden neben den dynamischen Tests auch statische Tests als mögliche Maßnahmen betrachtet, das beinhaltet weit mehr als nur Code-Reviews.

KI-spezifische Validierung: Bei nicht-deterministischen Systemen reicht Standard-Testing nicht aus. Was der Lehrplan zum ISTQB Certified Tester Foundation Level beschreibt, ist ein Fundament auf dem aufbauend passende Techniken wie beispielsweise metamorphes Testen angewendet werden müssen.

Neben der Durchführung der Tests ist auch die sorgfältige Auswahl der Testdaten im Fokus. Sie müssen eine echte Unabhängigkeit zu den Trainingsdaten wahren und von Anfang an - ebenso wie die Trainingsdaten - sorgfältig ausgewählt und vorbereitet werden.

Faktenbasierte Bewertung: Die finale Risikostufe ist nicht automatisch "Grün", sondern muss das Ergebnis einer echten Nachbetrachtung nach der Durchführung der Maßnahmen sein.

Qualität von Anfang an – Daten-Souveränität

Large Language Models werden mit Hilfe von Daten trainiert, diese sind mühsam zu beschaffen und für die Nutzung vorzubereiten. Oft werden diese Daten von Anfang an zum Training genutzt, Auswirkungen beobachtet und die Daten schrittweise selektiert und präpariert. Und die Testdaten? Das wird leider selten von Anfang an mitgedacht, am Ende sind womöglich nur noch bereits genutzte Trainingsdaten verfügbar - das Testen ist kontaminiert, die Testergebnisse nicht mehr verlässlich. Daher müssen ausreichend große Datenmengen als Trainingsdatensatz, Validierungsdatensatz und als Testdatensatz bereitgestellt und vorbereitet werden. Der Validierungsdatensatz dient zur Evaluierung und dem nachfolgenden Tuning des Modells, der Testdatensatz für den Test des dann abgestimmten Modells. Sollte das nicht möglich sein, gibt es Techniken wie das Kombinieren von Trainings- und Validierungsdatensatz, wiederholtes Splitting und Kombinatorik, um immer wieder unterschiedlich getunte Modelle zu ermöglichen. Der Testdatensatz muss jedoch in jedem Fall davon getrennt bleiben und darf nur für den eigentlichen Test und nicht etwa auch für das Tuning verwendet werden.

Auch die Datenqualität ist ein großes Problem, den sie bestimmt ganz stark, ob es eine Verzerrung (bias) der Daten gibt, diese beruht darauf, dass Daten unvollständig, unausgewogen, unfair, wenig vielfältig oder doppelt sind (siehe Lehrplan zum Certified Tester AI Testing (CT-AI)). Diese mangelnde Datenqualität kann besonders dann unentdeckt bleiben, wenn die gleichen Data Scientists sowohl Trainings- und Validierungdaten als auch Testdaten beschaffen und vorbereiten. Daher ist hier eine Risikoabschätzung der unterschiedlichen Qualitätsprobleme für alle Daten nötig. Gerade in der Medizintechnik ist der größte Anzahl an vorhandenen Daten nur über eine vergleichsweise geringe Anzahl von Daten mit deutlichen Verzerrungen hinsichtlich biologischem Geschlecht, Altersstrukturen und anderen Merkmalen vorhanden - vor allem trifft dies bei den öffentlich verfügbaren Datensätzen zu. Wünschenswert wäre hier, bewusst mit zwei unterschiedlichen Testdatensätzen zu testen, einmal bewusst sehr fair (z.B. geschlechtergerecht), zum anderen bewusst entsprechend der Verteilung, mit der das System auch nach der Validierung weiter lernt. Beispielsweise MRT-Bilder zur Bestimmung von Brusttumoren in einem Schritt "gerecht/fair" auf verschiedene Altersklassen, Geschlechter, sowie andere Merkmale aufzuteilen und damit zu testen. Und außerdem auch mit einer Verteilung der Daten wie sie vermehrt vorkommen - beispielsweise mit einem überwiegenden Anteil von MRT-Bildern von Frauen zwischen 50 und 70 Jahren.

Test-Knowhow erweitern

Und wie wird nun getestet? Leider in allzu vielen Firmen so wie immer schon. Die Anforderungen werden erarbeitet und sobald eine Traceability von Testfällen zu diesen Anforderungen nachgewiesen werden kann, wurde vermeintlich genug getestet.

Risikoorientiertes Testen bedeutet bei der Nutzung von KI-Komponenten aber nicht "mehr testen", sondern passend zu den spezifischen Risiken der KI auch die Skalierung in der Testbreite anpassen. Das heißt, dass Testtechniken zum Einsatz kommen müssen, die besonders gut für das nicht-deterministische Verhalten funktionieren, wie beispielsweise metamorphes Testen. Dieses Verfahren bewertet das Test-Orakel nicht mehr auf absoluten berechenbaren Ausgangswerten abhängig von definierten Eingangswerten, sondern über entsprechende Vorhersagen von Ergebnissen.

Ein Beispiel für metamorphes Testen ist die Variation von Bildern in kleinen Schritten, z.B. durch unterschiedliche Beleuchtungen oder Rauschen - eine Intensitäts-Transformation. Auch geometrische Transformationen wie beispielsweise die Rotation eines Bildes oder Spiegelungen dürfen das Ergebnis nicht verändern. Zudem gibt es noch Änderungen von Merkmalen des Inputs, die keinerlei Änderungen auf das Ergebnis haben dürfen, das können in manchen Fällen Artefakte sein oder das Hinzufügen / Ändern von Metadaten wie beispielsweise Patienten-IDs auf einem Bild. Diese dürfen beispielsweise eine Diagnose keinesfalls beeinflussen.

Es gibt also viele Merkmale, die den Input bestimmen (beispielsweise das MRT-Bild), die keine (signifikanten) Auswirkungen auf den Output (der Diagnose) haben sollen. Diese Relationen zwischen einer Eingabe, den möglichen Varianten und der erwarteten Ausgabe muss frühzeitig von Data Scientists und Entwicklungsteams definiert werden - am besten zusammen mit den Menschen, die das später testen.

Metamorphes Testen funktioniert gut, wenn es einen gut beschreibbaren Ausgangstestfall mit einem klaren Ergebnis gibt. Es ist aber auch anwendbar, wenn es nur eine Reihe von ähnlichen Testfällen mit ähnlichen Ergebnissen gibt. Gerade bei großen Datenmengen oder bei weniger gut vorhersagbaren Algorithmen können erst eine Reihe von Tests ausgeführt, die Ergebnisse dann verglichen und Relationen hergeleitet werden, um darauf aufbauend Vorhersagen für weitere Testfälle zu ermöglichen.

Bereits 2014 wurden Untersuchungen veröffentlicht, die zeigen, dass mit nur drei bis sechs verschiedenen MRs mehr als 90 % der Fehlerzustände aufgedeckt werden können im Vergleich zu Verfahren auf der Grundlage eines traditionellen Testorakels.

Metamorphes Testen ist eines der Testverfahren, die im ISTQB Lehrplan Certified Tester AI Testing gelehrt werden und die unabdingbar für die Entwicklung und die Qualitätssicherung von Embedded Software mit KI-Komponenten ist.

EU AI Act fordert Qualitätssicherung

Die Medizintechnik ist nur eine von vielen Branchen, in der KI-Komponenten eingeführt werden, für die der EU AI Act gilt - und zwar meist als Hochrisiko-KI, gelegentlich sogar als nicht-akzeptabel. Also sind Sicherheit, Transparenz und Assessments, die die Konformität nachweisen, aber vor allem auch die Qualitätssicherung ein absolutes Muss. Die kontinuierliche Weiterbildung der Entwicklungsteams im Sinne des lebenslangen Lernens ist damit wichtiger den je. Und: Qualitätssicherung muss mit der ersten Idee der Umsetzung von KI in Embedded Software mit am Tisch sitzen, Risiken abschätzen und mit risikoorientierter Strategie und erweiterten Testverfahren dafür sorgen, dass das Produkt echte Marktreife hat.

 (sg)

* *Maud Schlich ist Inhaberin von The Qualitters und Coach für Software-Testing sowie Prozessoptimierung.

(ID:50830586)