Warum wir anders über den Systemkontext nachdenken müssen

Kein System existiert im Vakuum. Daher ist eine wichtige Aufgabe des Systemarchitekten, den Kontext des Systems festzulegen. Dies ist nicht neu, und wird auch seit Jahrzehnten praktiziert. Neu ist, dass es nicht mehr reicht, den Kontext anfangs einmal abzuschätzen. Statt müssen moderne Systeme mit einem Kontext umgehen können, der sich zur Laufzeit erheblich verändern kann. Das erfordert neue Ansätze in der Entwicklung.

Systemgrenze und Kontextgrenze

Ein System ist immer in eine Umgebung eingebettet. Ohne diese Umgebung kann das System nicht betrachtet werden. Das ist der Kontext, dazu gehören sowohl materielle Dinge wie Benutzer, Energieversorgung oder Umgebungstemperatur, sowie auch immaterielle wie Vorschriften oder physikalische Gesetze.

Unser System hat in der Regel eine klare Grenze: Die Räder gehören zum System „Auto“, die Straße hingegen nicht. Die Straße ist Teil des Kontext, und zwar ein sehr relevanter Teil. Das Problem für uns ist, dass der Kontext nicht irgendwo aufhört: Auch der Mond ist Bestandteil des Kontextes, allerdings kaum ein relevanter Teil. Daher wurde traditionell der Begriff der Kontextgrenze eingeführt, die den relevanten vom nicht-relevanten Teil des Kontextes abgrenzt.

Der Kontext eines Fahrzeugs

Doch hier stoßen wir schon auf das Problem mit modernen Systemen. Bleiben wir bei einem Auto. Wenn es um die Entwicklung eines Fahrwerks geht, reicht es uns, die Mindestanforderungen an den Kontext zu stellen. Die Straße muss also bestimmte Eigenschaften haben, wie Beschaffenheit, Temperatur, Steigung, usw.

Wenn wir jedoch ein autonomes Fahrzeug entwickeln, dann reicht dies – zumindest heute – bei weitem nicht aus. Moderne autonome Fahrzeuge arbeiten mit hochgenauem Kartenmaterial. Der Kontext ist also nicht mehr eine allgemeine Straße, sondern eine bestimmte Straße. Die Eigenschaften dieser Straße setzen sich aus den in der Karte gespeicherten Informationen zusammen, die mit Echzeitdaten kombiniert werden.

Hinzukommt, dass der relevante Kontext sich kontinuierlich verändert. Bei der Entwicklung wurden lediglich Anforderungen an das Kartenmaterial gestellt. Der Gesamtkontext wird zur Laufzeit definiert, wenn das Kartenmaterial dem Fahrzeug zur Verfügung gestellt wird. Der relevante Kontext verändert sich kontinuierlich, je nachdem, wo sich das Fahrzeug befindet, wie es sich gerade bewegt, und was die Fahrzeugsensoren an Information liefern.

Der relevante Kontext moderner System verändert sich kontinuierlich im Betrieb

Der traditionelle Ansatz funktioniert bei so einem System nicht mehr zufriedenstellend: Die Gefahr, kontextbedingt Fehler zu machen ist groß, und der Aufwand wäre enorm.

Ist Machine Learning die Antwort?

Um bei autonomen Fahrzeugen zu bleiben: Diese nutzen typischerweise Machine Learning, um die Steuerlogik zu erstellen. Damit haben wir – zumindest kurzfristig – die Kontextfrage aus dem Weg geschafft. Allerdings zeigt sich jetzt schon, dass dies langfristig kein praktikabler Ansatz ist. Denn die Daten, die zum Trainieren des Systems herangezogen wurden, müssen ja auch im Einsatz relevant sein. Wir müssen den Kontext kontinuierlich auswerten, um sicher zu sein, dass das trainierte System in einem relevanten Kontext arbeitet. Und dies muss auch nachgewiesen werde können: Sowohl für die Compliance, als auch aus ethischen Gründen. Daher wird zur Zeit auch diskutiert, für die Compliance die Trainingsdaten mit einzubeziehen.

Kontext und Anforderungen

Zurück zur Systementwicklung. Der Kontext ist wichtig, denn wir können die korrekte Funktion nur dann garantieren, wenn der Kontext stimmt. Wenn zum Beispiel die zulässige Umgebungstemperatur für unser Auto von -15°C bis 45°C festgelegt wurde, dann ist nicht garantiert, dass es bei -20°C auch anspringt.

Die Erfüllung von Anforderungen kann nur in einem validen Kontext garantiert werden.

Hier wird es für moderne Systeme interessant: Da sich der Kontext im Betrieb kontinuierlich verändert, kann es sein, dass – je nach Kontext – bestimmte Anforderungen nicht mehr erfüllt werden. Das wollen wir auf jeden Fall verhindern.

Anforderungen und Kontext zur Laufzeit auswerten

Ein möglicher Weg ist es, Anforderungen und Kontext zur Laufzeit auszuwerten. Die Theorie hinter diesem Ansatz stellte ich hier bereits unter dem Namen WRSPM vor.

Konkret könnte eine Anforderung lauten: „Das Fahrzeug muss sich in einem sicheren Fahrmodus befinden“.

Diese Anforderung kann unterschiedlich erfüllt werden. Konkret hier zwei Möglichkeiten:

1. Genaues Kartenmaterial UND Autonomer Modus ERGIBT Sicheres Fahren
2. Beliebiges Kartenmaterial UND Manueller Modus ERGIBT Sicheres Fahren

Das System kann nun zur Laufzeit die Anforderungen kontinuierlich auswerten. Wenn plötzlich – durch einen Kontextwechsel – die Anforderung nicht mehr erfüllt ist, muss zur Laufzeit eine andere Konstellation gefunden werden, um die Anforderung zu erfüllen. Konkret kann das System die Kontrolle an den Fahrer geben, wenn es den Bereich des genauen Kartenmaterials verlässt.

Fazit

Der Systemkontext ist wichtig, das wussten wir schon immer. Doch traditionell wurde dieser während der Entwicklung festgelegt und verfeinert und war dann zur Laufzeit konstant. Das muss sich ändern, um komplexe Systeme in einer riesigen Umgebung betreiben zu können. Und das bedeutet, dass die Systeme sich zur Laufzeit selbst darum kümmern werden, dass die wichtigen Anforderungen auch umgesetzt werden.