VDA TRS: 15 Methoden für die Software-Risikoanalyse
Software bestimmt heute einen Großteil der Fahrzeugfunktionen, vom Spurhalteassistenten bis zum Over-the-Air-Update. Viele Entwicklungsteams sichern diese Funktionen trotzdem ausschließlich über das FMEA-Formblatt ab und erweitern es so lange, bis es Dinge wie Timing-Effekte, Wechselwirkungen zwischen Steuergeräten und Angriffe von außen trägt, für die es aber eigentlich nie gebaut wurde.
Der VDA benennt das Problem inzwischen selbst. In der Einleitung des neuen Gelbbands heißt es sinngemäß, die FMEA zeige bei softwareinduzierten Risiken methodische Grenzen und die Vorgaben der IATF engten die methodische Offenheit zusätzlich ein.
Nach dem Lesen dieses Fachbeitrags wissen Sie, was der VDA TRS enthält, wie sein Phasenmodell die Methodenwahl steuert und wie Sie den Band pilotieren, ohne Ihr bestehendes FMEA-Handbuch umzuschreiben.
Was ist der VDA TRS?
Der Band trägt den Titel „Technische Risikoanalyse von softwarebasierten Funktionalitäten“ und ist im November 2025 als Gelbband des VDA QMC in erster Ausgabe erschienen. Die englische Fassung folgte im Dezember 2025. Dabei handelt es sich um einen ersten Entwurf, der zur Kommentierung freigegeben ist. Der Inhalt ist noch nicht final und wird ausdrücklich als unverbindliche Empfehlung formuliert.
Der TRS versteht sich als Ergänzung. Er verweist auf das AIAG/VDA FMEA-Handbuch, die VDA-Reifegradabsicherung, ISO 26262, ISO/SAE 21434 und Automotive SPICE und ersetzt keines dieser Regelwerke. Neu ist, dass ein VDA-Band die Grenzen der FMEA für Software offen anspricht und daraus die Konsequenz zieht, dass es für Software mehr braucht als eine Methode.
Fünfzehn Methoden in vier Familien
Kern des Bandes ist ein Werkzeugkasten aus fünfzehn Methoden. Für die Praxis lassen sie sich in vier Familien ordnen (siehe Bild 1).
- Ursachenbasiert (induktiv): FMEA, FMEA-MSR, FMEDA, HAZOP und SWIFT. Die Analyse startet bei einer Fehlerursache oder einer Abweichung und verfolgt sie bis zur Wirkung. Die FMEDA ist laut Band auf reine Software nur sehr begrenzt anwendbar.
- Ereignisbasiert: FTA, ETA und CCA. Die FTA sucht von einem unerwünschten Ereignis aus rückwärts nach Ursachen, die ETA verfolgt ein auslösendes Ereignis vorwärts zu seinen möglichen Folgen, die CCA sucht gemeinsame Ursachen, die Redundanzen aushebeln.
- System und Architektur: ATAM, STPA, CPA und DRBFM. Diese Methoden betrachten Zielkonflikte, Wechselwirkungen und die Kritikalität von Funktionen über das Gesamtsystem.
- Safety und Security: HARA, SOTIF und TARA, verankert in ISO 26262, ISO 21448 und ISO/SAE 21434.
Fünfzehn Methoden bedeuten nicht fünfzehn Analysen pro Projekt. Der Band will die Frage beantworten, welche Methode zu welchem Zeitpunkt die richtige Antwort liefert.
Das Phasenmodell: Methode passend zur Phase wählen
Kapitel 5 unterscheidet vier Phasen des Produktlebenszyklus und bewertet in Tabelle 5-1 für jede Methode, wie relevant sie in welcher Phase ist, von + (niedrig) bis ++++ (sehr hoch). Damit wird aus dem Werkzeugkasten eine Auswahlhilfe (siehe Bild 2).
Konzeptphase
Erste Risikoidentifikation auf Ebene der Funktionskonzepte. Am höchsten bewertet sind HARA und TARA für Safety und Security, SOTIF für Risiken aus der Sollfunktion selbst, STPA für die Steuerungsstruktur, ATAM für die ersten Architekturentscheidungen und CPA, um kritische Funktionen früh zu priorisieren. Auch die FMEA ist hier bereits hoch bewertet.
Designphase
Die Architektur steht im Mittelpunkt. Die höchste Bewertung erhalten DRBFM für Design- und Änderungsentscheidungen sowie HAZOP und SWIFT, die Abweichungen an Schnittstellen und Parametern mit Leitworten oder Was-wäre-wenn-Fragen systematisch abfragen. Hoch bewertet sind außerdem ATAM, CPA, FTA, SOTIF, TARA, FMEA und FMEA-MSR. Hier übernimmt die FMEA ihre bekannte Rolle.
Implementierung und Test
Risiken entstehen jetzt aus der konkreten Umsetzung und aus der Integration mehrerer Teilsysteme. Hoch bewertet sind HAZOP und SWIFT, etwa mit Leitfragen wie „Was, wenn eine Schnittstelle nicht wie spezifiziert arbeitet?“. FMEA, FTA, DRBFM, CPA und TARA liefern mittlere Beiträge.
Wartung
Im Feld geht es darum, die Integrität laufender Systeme zu schützen, etwa bei Over-the-Air-Updates oder V2X-Kommunikation. DRBFM wird bei jeder Änderung und jedem Update erneut angewendet, ETA und FTA analysieren Ereignisketten und die Ursachen von Feldproblemen.
Wichtig ist die Rückkopplung. Erkenntnisse aus späteren Phasen fließen in frühere zurück, das Risikobild reift über den gesamten Lebenszyklus. Iteration ist im TRS die Regel und keine Ausnahme.
Was bleibt und was der TRS ergänzt
Für Ihre bestehende Organisation ändert der Band weniger, als der Umfang vermuten lässt. Aus unserer Sicht bleibt:
- Das AIAG/VDA FMEA-Handbuch (2019) bleibt über die kundenspezifischen Anforderungen der OEM verbindlich.
- Die Anforderungen der IATF 16949 gelten unverändert.
- ISO 26262 und ISO/SAE 21434 bleiben der Rahmen für Safety und Security.
- Die Reifegradabsicherung (RGA) bleibt das Rückgrat der Meilensteine, der Band verweist ausdrücklich auf sie.
Der TRS ergänzt eine phasengesteuerte Methodenwahl vom Konzept bis zur Wartung, eine Einteilung der Software-Risiken in funktionale Risiken, Safety- und Security-Risiken, Zuverlässigkeits- und Verfügbarkeitsrisiken, Performance-Risiken sowie Integrations- und Kommunikationsrisiken, dazu Akzeptanzkriterien und eine Klassifizierungslogik. Kapitel 6 beschreibt, wie Risikoanalysen entlang der Integrationskette zwischen Kunde und Lieferant übernommen, bewertet und konsolidiert werden. Kapitel 7 liefert vier Fallbeispiele: ATAM am Spurhalteassistenten, ETA am OTA-Update, CPA an der Verkehrszeichenerkennung und HAZOP an einer Türöffner-App. Dazu kommt ein Ablaufschema zur Methodenwahl in einem sicherheitsrelevanten Projekt.
Drei Muster, die Sie vermeiden sollten
Den TRS als neue FMEA-Norm lesen
Wer den Band als nächsten FMEA-Standard versteht und daraufhin das eigene Handbuch umschreibt, verliert Zeit und Stabilität. Nutzen Sie den TRS als Methodenwahl für Software. Ihre FMEA bleibt dort, wo sie funktioniert.
Eine Methode für alle Phasen
Eine einzige Methode über alle vier Phasen zu ziehen, widerspricht der Logik des Bandes. Die Konzeptphase braucht andere Werkzeuge als die Wartung. Orientieren Sie sich an den Bewertungen in Tabelle 5-1.
Auf die finale Fassung warten
Wer erst piloten will, wenn der Band final ist, hat keinen Einfluss mehr auf den Inhalt. Die Kommentierungsphase ist der richtige Zeitpunkt für einen Pilot. Erfahrungen und Unklarheiten können Sie direkt an den VDA QMC zurückmelden.
Beispiel
Angelehnt an das OTA-Fallbeispiel des Bandes (Kapitel 7.1.2) zeigt ein vereinfachtes Beispiel, wie die Methodenwahl über die Phasen wandert. Betrachtet wird die Funktion „Software-Update eines Steuergeräts over the air“.
- Konzept: Die HARA fragt, welche Gefährdung entsteht, wenn ein Update während der Fahrbereitschaft startet oder abbricht. Die TARA fragt, wie ein Angreifer manipulierte Software einschleusen könnte. Die STPA modelliert die Steuerungsstruktur aus Backend, Gateway, Steuergerät und Fahrer und findet unsichere Steuerbefehle, etwa eine Freigabe zum Flashen bei zu niedriger Bordnetzspannung.
- Design: Die FMEA analysiert die Software-Komponente Update-Manager. Ein DRBFM bewertet die Designentscheidung für ein Konzept mit Primär- und Backup-Partition. Ergänzend prüft eine CCA, ob ein gemeinsamer Fehler im Bootloader beide Partitionen zugleich treffen kann.
- Implementierung und Test: Ein SWIFT-Workshop geht die Update-Abläufe mit Was-wäre-wenn-Fragen durch: Was, wenn das Update abbricht? Was, wenn die Bordnetzspannung während des Flash-Vorgangs einbricht? Was, wenn das Backend eine falsche Softwareversion ausliefert?
- Wartung: Im Feld läuft das Update auf vielen Fahrzeugen. Die ETA startet beim auslösenden Ereignis „OTA-Update wird gestartet“ und verfolgt die Pfade über Download, Integritätsprüfung, Installation und Neustart. Wie im Beispiel des Bandes liegen die größten Risiken nicht im Download, sondern in Installation und Neustart. Jede spätere Änderung der Update-Logik durchläuft ein DRBFM.
Zusammen ergeben diese Fragen ein Risikobild, das über den Lebenszyklus nachvollziehbar bleibt.
Fazit
Die FMEA bleibt der Anker der technischen Risikoanalyse. Für Software ist sie notwendig, aber nicht hinreichend. Prüfen Sie im nächsten Softwareprojekt je Phase, welche Methode die offene Frage beantwortet und starten Sie den Pilot, solange Ihre Rückmeldungen noch in den Band einfließen können.
Sie möchten den VDA TRS in einem Pilotprojekt erproben oder Ihre Software-Risikoanalyse neu aufstellen?
Wir unterstützen Sie bei der Methodenwahl und moderieren die Analysen im Team. Sprechen Sie uns an: www.dietz-consultants.com
Autor: Winfried Dietz, CEO Dietz Consultants GmbH
Winfried Dietz ist CEO der Dietz Consultants GmbH und begleitet seit über 30 Jahren Entwicklungsorganisationen weltweit bei der Einführung und Reifung der FMEA-Methodik. Er ist Trainer, Autor und Referent für FMEA nach AIAG-VDA. Mehr von der FMEA-Quick-Tip-Reihe finden Sie auf LinkedIn.