6) Testarchitektur mit Sicherheitsfokus
Tests sind keine Feature-Screens, sondern Betriebsexperimente mit klarer Beweisabsicht.

  • Systemtests gegen Worst-Case-Profile: Ressourcen-Engpässe, Failover, degradierte Netze, Clock-Drift, korruptes I/O.

  • Sicherheitsnetze: Canary-Checks, Watchdogs, Safe-States. Nicht nur implementieren, sondern prüfen und loggen.

  • HIL/SIL von Sprint 0: Simulationen und echtzeitnahe Loops laufen früh; synthetische Störungen sind Standardfälle.

  • Für ML/LLM: Guardrail-Tests, kontradiktorische Inputs, „don’t guess“-Policies, Messung von Abstinenz (wie oft lehnt das System Eingaben ab) und Klarheitsmetriken.

7) Veränderung kontrollieren: Change Impact und Architektur-Runway
Jede Änderung bewertet, welche Evidenzen veralten und welche Regressionen zu erwarten sind. Dazu dient ein gemeinsamer Katalog:

  • Komponententyp: safety-kritisch, sicherheitsrelevant, unkritisch.

  • Abhängigkeitstiefe: direkte vs. transitive Nutzer.

  • Nachweisabhängigkeiten: welche Tests/Analysen müssen wiederholt werden?

  • Release-Gates: Schwellenwerte, ab denen eine Änderung ein höheres Freigabeniveau triggert.

Die Architektur-Runway hält Platz für bevorstehende Änderungen (z. B. Einführung einer neuen Sensorfamilie), damit Partitionen, Schnittstellen und Datendomänen vorbereitet sind – bevor Features darauf aufsetzen.

MVP für sicherheitskritische Systeme: Minimum Verifiable Product

„MVP“ wird oft mit „Schnell was zeigen“ verwechselt. In regulierten Umgebungen ist das gefährlich. Was zählt, ist ein Minimum Verifiable Product – ein Inkrement, das eine Ende-zu-Ende-Fähigkeit inklusive evidenzfähigem Safety- und Security-Nachweis enthält. Es muss klein sein, aber alle Schichten enthalten:

  • Fachliche Dünnschicht: eine reale Nutzerreise oder Betriebsaufgabe

  • Technische Dünnschicht: Sensor/Aktor, Verarbeitung, Speicherung, Oberflächen oder Interfaces

  • Nachweis-Dünnschicht: Hazard/Threat-Referenzen, Testfälle, Logs, SBOM, Signaturen, Reviewer-Freigaben

  • Betriebs-Dünnschicht: Monitoring/Observability im Zielkontext (auch offline), Rollback und Fallback

Beispielhafte Struktur für ein MVP-Inkrement:

  • Ziel: Detektiert einen spezifischen Fehlerzustand an einer Baugruppe und initiiert einen sicheren Fallback.

  • Eingrenzung: Ein Sensortyp, ein Fahrzeug-/Luftfahrzeugmodus, definierte Umweltbedingungen.

  • Architektur: Safety-Kern bildet die Erkennungslogik deterministisch ab; optionaler ML-Pfad liefert zusätzliche Sensitivität, ist aber strikt über einen Adapter mit Confidence- und Rate-Limits eingebunden; Fallback ist heuristisch belegbar und permanent verfügbar.

  • Evidenz: Datensatzreferenz (Version und Herkunft), Evaluationsreport inkl. Fehlalarms- und Ausfallraten, Timing-Messungen, HIL-Testprotokolle, SBOM und signierte Build-Provenance, Audit-Log der Reviewer.

  • Betrieb: On-prem Deployment-Script, Air-Gap-kompatible Artefaktlieferung, Konfigurations-Checksumme, Betriebs-Runbook.

Ein solches MVP kann man verantwortungsvoll in begrenzte Betriebsumgebungen bringen, Telemetrie sammeln (unter Einhaltung von Datenschutz/Souveränität) und den Safety Case Sprint für Sprint verdichten.

Agil heißt auch: Souveränität ernst nehmen

Wer in Europa baut, muss Souveränität nicht als politische Parole, sondern als Systemeigenschaft verstehen:

  • On-Prem statt Cloud-Zwang: Build-, Test- und Observability-Stacks müssen lokal oder in kundeneigenen Umgebungen lauffähig sein – ohne Funktionsverlust gegenüber der Public-Cloud-Variante.

  • Datenhoheit: Datenspeicher, Feature Stores, Modellartefakte liegen in kontrollierten Domänen. Transferpfade sind minimal, verschlüsselt und nachvollziehbar.

  • Abhängigkeiten kapitalisieren, nicht externalisieren: Fremd-APIs (z. B. für KI) sind in regulierten Kernen tabu oder streng isoliert. Wenn generative Komponenten verwendet werden, dann mit kontrollierten Modellen, Offline-Inferenz, eigenen Vektorspeichern und strikter Governance (Policy-Checks, Audit Trails).

Für AI/LLM-Komponenten gilt: Agenten brauchen Observability und Governance wie jedes andere Subsystem. Telemetrie, Policy-Enforcement, Auditierbarkeit und Offline-Betrieb sind Pflicht. Ohne diese Eigenschaften ist eine Zulassungsdiskussion faktisch nicht führbar.

Organisationsmuster: Wie Teams so arbeiten können

  • Rollen
  • Technical Owner pro Produktlinie: hütet die Kohärenz von Architektur, Evidenz und Delivery. Nicht zu verwechseln mit dem Product Owner; oft ergänzen sich beide.
  • Feature Teams entlang der Partitionen, nicht entlang kurzlebiger Services. Jedes Team verantwortet wiederverwendbare Artefakte und deren Evidenz.
  • System-Engineering-/QA-Chapter: unterstützt mit Methoden, Testarchitektur, Toolchains, Review-Standards. Keine Elfenbeintürme, sondern Enabler.
  • Zeremonien
  • Evidence Review (jede 1–2 Wochen): Fokus auf Nachweis-Deltas, nicht auf Demos. „Welche Belege sind neu? Welche Annahmen sind gefallen? Welche Risiken haben wir gesenkt?“
  • Change-Impact-Klinik: Querschnittsrunde, um bevorstehende Änderungen durch die Evidenz- und Abhängigkeitsmatrix zu ziehen.
  • Retrospektive mit Metriken: Lead Time for Changes, Mean Time to Evidence (von Commit bis akzeptierter Nachweis), Anteil abstinenter Entscheidungen bei LLM/ML-Komponenten, Rebuild-Reproduzierbarkeit.
  • Metriken
  • Mean Time to Evidence statt nur Lead Time: Wie schnell erzeugt eine Änderung die notwendigen Belege?
  • Repro-Score: Anteil der Builds/Experimente, die deterministisch reproduzierbar sind.
  • Evidence Coverage: Anteil der Anforderungen/Hazards mit vollständigem Trace von Code zu Test zu Log zu Signatur.
  • Abstinenz- und Fallback-Rate bei AI: Anteil der Fälle, in denen das System korrekt „nein“ sagt und auf deterministische Pfade fällt.

Typische technische Trade-offs

  • Microservices vs. modularer Monolith
  • Microservices bieten Teamautonomie, verkomplizieren aber End-to-End-Traceability, Latenz und Testbarkeit. Für Safety-Kerne ist ein modularer Monolith mit klaren Adaptern oft überlegen. Services bleiben an der Peripherie.
  • Dynamische vs. statische Kopplung
  • Dynamisches Linking vereinfacht Updates, erhöht aber die Nachweis-Last bei Abhängigkeitswechseln. In Safety-Kernen: statisch und minimal. In der Peripherie: dynamisch, aber mit SBOM und strengen Gates.
  • Reaktive Events vs. deterministische Kontrollflüsse
  • Events skalieren, aber verschleiern Ursachenketten. Für Nachweise sind deterministische Kontrollflüsse mit klarer Protokollierung vorzuziehen, ergänzt um Events für Monitoring/Telemetrie.
  • KI/ML inline vs. über Adapter
  • Inline-ML erhöht nicht-deterministisches Verhalten. Besser: ML/LLM über Adapter mit Confidence-Grenzen, Rate-Limits, mensch-in-der-Schleife-Kanälen und sicheren Defaults. Für kritische Entscheidungen immer ein deterministischer Pfad.

Ein exemplarischer Lebenszyklus für ein Inkrement