Sicherheitskritische Software entwickeln
Determinismus mit oder trotz KI/ML
Künstliche Intelligenz (KI) und Machine Learning (ML) revolutionieren sicherheitskritische Embedded-Software. Entwickler müssen lernen, KI und ML zu nutzen, ohne die Functional-Safety-Prozesse zu beeinträchtigen.
Ganz ähnlich wie es vor einigen Jahren bei Open-Source-Software war, eröffnen KI (Künstliche Intelligenz) und ML (Machine Learning) ganz neue Horizonte für sicherheitskritische Embedded-Software. Diese Techniken haben ein Umdenken in Bezug darauf angestoßen, wie wir Menschen Informationen verarbeiten, Daten analysieren und Entscheidungen fällen. Wer in seiner beruflichen Tätigkeit mit sicherheitskritischer Software zu tun hat, muss wissen, wie sich die enormen Möglichkeiten von KI und ML nutzen lassen, ohne die Functional-Safety-Prozesse und -Zertifizierungen ungünstig zu beeinflussen.
Jobangebote+ passend zum Thema
Wie definiert man KI und ML?
Angesichts des Hypes und der Unklarheiten, die hauptsächlich im Zusammenhang mit generativen KI-Techniken um das Thema KI/ML entstehen, lohnt sich die Suche nach einer allgemeingültigeren Definition der Begriffe, die sämtliche potenziellen Fähigkeiten für die Entwicklung sicherheitskritischer Software abdecken.
Das Oxford English Dictionary (OED) definiert KI als »die Fähigkeit von Computern oder anderen Maschinen, intelligentes Verhalten zu zeigen oder zu simulieren, sowie das damit zusammenhängende Studiengebiet«.
Bei KI wird zwischen zwei Arten unterschieden:
- Schwache KI hat überragende Fähigkeiten für diejenige Aufgabe, für die sie trainiert wurde, jedoch fehlt ihr eine allgemeine, mit der von Menschen vergleichbare Intelligenz.
- Starke KI hat dagegen eine echte, menschenähnliche Intelligenz.
Machine Learning (maschinelles Lernen) wird vom OED wie folgt definiert: »Die Fähigkeit von Computern zum Lernen und zur Anpassung, ohne dass explizite Anweisungen befolgt werden. Stattdessen werden Algorithmen und statistische Modelle zum Analysieren von Daten und zum Ziehen von Schlussfolgerungen aus darin enthaltenen Mustern verwendet.« Anders ausgedrückt, geht es bei ML also um die Schaffung starker KI-Systeme, die durch Erfahrung lernen und besser werden können.
KI und ML auf dem Vormarsch
Man könnte argumentieren, dass konventionell programmierte und deterministische Softwareanwendungen, wie sie schon seit Jahrzehnten in Gebrauch sind, in die Gruppe der schwachen KI fallen. Das Flight-Management-System eines Flugzeugs oder ein elektronisches Steuergerät in einem Auto etwa sind für die deterministische Ausführung bestimmter Aufgaben konzipiert und erledigen diese üblicherweise sehr gut.
Ebenso könnte man die automatische Testvektorerzeugung als eine Art schwache KI bezeichnen, denn sie leitet Modultests aus bestehendem Code her und leistet damit die in der Definition erwähnte Simulation von intelligentem Verhalten. Wie Bild 1 verdeutlicht, würde das manuelle Ausarbeiten und Ausführen dieser Tests ein erhebliches Maß an Fähigkeiten und Intelligenz erfordern, wogegen automatisierte Prüf-Tools diese ebenso umfassend wie effizient erledigen.
KI-gestützte Werkzeuge zur Softwareentwicklung stellen ganz klar eine Art von KI dar, die stärker ist als die von konventionellen Anwendungen. Assistenten wie etwa Microsoft Copilot, Amazon CodeWhisperer und Google Gemini Code Assist bieten Möglichkeiten zur Vereinfachung von Entwicklungsaufgaben, die traditionell von Menschen erledigt werden. In Bild 2 ist zu sehen, wie ChatGPT zur Ausgabe eines bestimmten Programmabschnitts aufgefordert wird, und welches Ergebnis daraufhin erscheint.
Die Einfachheit, mit der auf diese Art Code generiert werden kann, mag Zweifel an seiner Nützlichkeit heraufbeschwören. Klar ist aber, dass der Einsatz von KI-Programmier-Tools umso mehr zunehmen wird, je besser die Sprachmodelle und Techniken werden.
Starke KI stellt eine größere Herausforderung für die etablierte Ordnung sicherheitskritischer Anwendungen dar. Traditionelle Garantien für Zuverlässigkeit, Safety und Security resultieren aus einem vorsichtigen Umgang mit Veränderungen und einer strikten Rückverfolgbarkeit der Anforderungen. Starke KI stellt diese Konzepte in Frage, und zwar durch Geschwindigkeit und einen irgendwie eingeschränkten Einblick in die Interna der Trainingsdaten und Sprachmodelle. Außerdem verspricht sie fortschrittlichere Embedded-Systeme, die prinzipbedingt sicherer sind als solche, die auf traditionellere Weise entwickelt wurden.
Beispiel: KI in Medizingerätesoftware
Die US-amerikanische Behörde für Lebensmittel- und Arzneimittelsicherheit (Food and Drug Administration, FDA) hat proaktiv die Verwendung KI/ML-basierter »Software as a Medical Device« (SaMD) gefördert, die »gesperrte« Algorithmen verwendet – also solche, die als Reaktion auf konsistente Eingaben stets konsistente Ergebnisse liefern. Weniger klar ist dagegen, wie mit der Entwicklung adaptiver Algorithmen umgegangen werden soll. Diese reagieren auf Lernresultate und ändern gegebenenfalls ihre Ergebnisse aufgrund dieser Erkenntnisse. Dieser Verzug hat die Hersteller in eine Warteschleife zwischen KI/ML-Innovationen und dem potenziellen Verstoß gegen FDA-Richtlinien wie der Norm IEC 62304 gebracht, mit Anwendungen, die möglicherweise andere Ergebnisse liefern als im ursprünglich genehmigten Zustand.
Vielversprechend ist dagegen ein genauerer Blick auf die Vorschriften für Medizingeräte. Das SaMD-Risikokategorisierungs-Framework des International Medical Device Regulators Forum (IMDRF) bietet einen systematischen Ansatz zur Klassifizierung der Risiken von Software, die für medizinische Zwecke vorgesehen ist. Er hilft Regulierungsbehörden, Herstellern und anderen Beteiligten, die entsprechenden behördlichen Anforderungen zu bestimmen und sicherzustellen, dass die entwickelte Software die erforderlichen Sicherheits- und Effektivitätsstandards erfüllt.
Gemäß diesem Framework kann die vorgesehene Verwendung eines SaMD – ob KI/ML-basiert oder nicht – anhand der Auswirkungen auf den Patienten klassifiziert werden (Tabelle). In der Tabelle steht „I“ für das geringste und „IV“ für das höchste Risiko. Die Auswirkung beruht auf Faktoren wie dem vorgesehenen Verwendungszweck der Software, der Bedeutung der von der Software gelieferten Information für das Fällen medizinischer Entscheidungen sowie den möglichen Konsequenzen eines Softwarefehlers.
Das IMDRF-Framework hilft dabei, SaMD in verschiedene Risikoklassen oder -kategorien einzuteilen, die den Grad der behördlichen Kontrolle und der an die Software gestellten Anforderungen bestimmen. Da diese Klassifizierung unabhängig von der zur Erstellung der Software verwendeten Methodik ist, kann sie auch auf SaMD angewendet werden, die sich auf KI-/ML-basierte Techniken stützen.
KI/ML in sicherheitskritischen Anwendungen
Wenn überhaupt, gibt es nur wenige sicherheitskritische Systeme, die vollständig auf KI/ML basieren. Meist werden die Ausgaben der KI/ML-basierten Softwarekomponenten in konventionell entwickelte Anwendungen eingebunden – sei es im selben System oder in einem anderen Gerät.
Aus diesem Grund ist es folgerichtig, die von der Norm IEC 62304 propagierten Prinzipien der Bereichstrennung auszuweiten. Dieses Konzept siedelt KI/ML-Algorithmen in besonderen Domains an und befähigt Domains, die KI/ML-generierte Daten entgegennehmen, die damit verbundenen Risiken einzudämmen.
Wie Bild 3 zeigt, können bestehende Taint-Analysis-Tools die von KI/ML-Komponenten kommenden Daten prüfen und validieren. Mithilfe solcher Tools wissen Entwickler konsumierender Softwareelemente über die plausiblen Datenbereiche Bescheid und können ihre Software so entwickeln, dass ankommende und abgehende Daten einer Plausibilitätsprüfung unterzogen werden – unabhängig davon, ob es um eine KI/ML-Domäne geht oder nicht.
Nicht den Anschluss verpassen
KI/ML-basierte Systeme werden bereits zum Schreiben von Code und zur Ausführung innovativer Funktionen auf sicherheitskritischen Plattformen eingesetzt.
Da die meisten, wenn nicht sogar alle diese Komponenten eingebettet in konventionell entwickelte Software verwendet werden, bieten sich Chancen zur Risikoeindämmung, entweder in Form konventionell entwickelter, deterministischer Software oder durch Einbindung von Menschen. Bestehende Best Practices, insbesondere im Zusammenhang mit Risikoanalysekonzepten und Domänentrennung, lassen sich hier vorteilhaft einsetzen.
Der Autor
Mark Pitchford
verfügt über mehr als 30 Jahre Erfahrung in der Softwareentwicklung für technische Anwendungen. Er hat an vielen bedeutenden industriellen und kommerziellen Projekten in Entwicklung und Management sowohl in Großbritannien als auch international mitgearbeitet. Seit 2001 arbeitet er mit Entwicklungsteams, die eine konforme Softwareentwicklung in sicherheitskritischen Umgebungen erreichen wollen, und arbeitet dabei mit Standards wie DO-178, IEC 61508, ISO 26262, IIRA und RAMI 4.0.
Pitchford erhielt seinen Bachelor of Science von der Trent University in Nottingham und ist seit mehr als 20 Jahren zugelassener Ingenieur. Heute arbeitet er als technischer Spezialist bei LDRA.
mark.pitchford@ldra.com
Lesen Sie mehr zum Thema
