VDA TRS: 15 Methods for Software Risk Analysis

The VDA acknowledges that reaches methodological limits when it comes to software-induced risks. Since November 2025, the yellow volume "Technical Risk Analysis of Software-Based Functionalities" has provided a toolbox of fifteen methods. We show you how to use it without restructuring your established approach.

Software now determines a large share of vehicle functions, from lane keeping assist to over-the-air updates. Even so, many development teams safeguard these functions exclusively through the FMEA form and keep extending it until it is expected to cover timing effects, interactions between ECUs and external attacks. It was never built for that.

The VDA now names the problem itself. The introduction of the new yellow volume states, in essence, that FMEA shows methodological limits for software-induced risks and that the IATF requirements further restrict methodological openness.

After reading this article, you will know what the VDA TRS contains, how its phase model guides the choice of method and how to pilot the volume without rewriting your existing FMEA manual.

What is the VDA TRS?

The volume is titled "Technical Risk Analysis of Software-Based Functionalities" and was published in November 2025 as the first edition of a VDA QMC yellow volume. The English version followed in December 2025. It is a first draft released for comment. The content is not yet final and is explicitly worded as a non-binding recommendation.

The TRS sees itself as a supplement. It refers to the AIAG/VDA FMEA Handbook, VDA Maturity Level Assurance, ISO 26262, ISO/SAE 21434 and Automotive SPICE and replaces none of these frameworks. What is new is that a VDA volume openly addresses the limits of FMEA for software and draws the conclusion that software needs more than one method.

Fifteen methods in four families

At the core of the volume is a toolbox of fifteen methods. For practical use, they can be grouped into four families (see Figure 1).

Cause-based (inductive): FMEA, FMEA-MSR, FMEDA, HAZOP and SWIFT. The analysis starts with a Failure Cause or a deviation and follows it through to its effect. According to the volume, FMEDA is of very limited use for pure software.
Event-based: FTA, ETA and CCA. FTA works backwards from an undesired event to find its causes, ETA follows an initiating event forwards to its possible consequences, and CCA looks for common causes that defeat redundancies.
System and architecture: ATAM, STPA, CPA and DRBFM. These methods examine trade-offs, interactions and the criticality of functions across the entire system.
Safety and security: HARA, SOTIF and TARA, anchored in ISO 26262, ISO 21448 and ISO/SAE 21434.

Figure 1: The fifteen methods of the VDA TRS, grouped into four families (DC classification).

Fifteen methods do not mean fifteen analyses per project. The volume sets out to answer which method delivers the right answer at which point in time.

The phase model: matching the method to the phase

Chapter 5 distinguishes four phases of the product life cycle and, in Table 5-1, rates how relevant each method is in each phase, from + (low) to ++++ (very high). This turns the toolbox into a selection aid (see Figure 2).

Concept phase

Initial risk identification at the level of functional concepts. The highest ratings go to and TARA for safety and security, SOTIF for risks arising from the intended function itself, STPA for the control structure, ATAM for the first architecture decisions and CPA to prioritise critical functions early on. is already rated high here as well.

Design phase

The architecture is the focus. The highest ratings go to for design and change decisions, and to HAZOP and SWIFT, which systematically query deviations at interfaces and parameters using guide words or what-if questions. ATAM, CPA, , SOTIF, TARA, and are also rated high. This is where takes on its familiar role.

Implementation and testing

Risks now arise from the concrete implementation and from integrating several subsystems. HAZOP and SWIFT are rated high, for example with guiding questions such as "What if an interface does not work as specified?". , , , CPA and TARA make medium contributions.

Maintenance

In the field, the task is to protect the integrity of running systems, for example during over-the-air updates or V2X communication. is applied again for every change and every update, while ETA and analyse event chains and the causes of field problems.

Feedback is essential. Findings from later phases flow back into earlier ones, and the risk picture matures over the entire life cycle. In the TRS, iteration is the rule, not the exception.

Figure 2: The phase model of the VDA TRS with the highest-rated methods per phase (based on Table 5-1).

What stays and what the TRS adds

For your existing organisation, the volume changes less than its scope might suggest. From our point of view, the following remains:

The AIAG/VDA FMEA Handbook (2019) remains binding through the OEMs' customer-specific requirements.
The requirements of IATF 16949 apply unchanged.
ISO 26262 and ISO/SAE 21434 remain the framework for safety and security.
Maturity Level Assurance (MLA) remains the backbone of the milestones, and the volume explicitly refers to it.

The TRS adds a phase-driven choice of method from concept to maintenance and a classification of software risks into functional risks, safety and security risks, reliability and availability risks, performance risks, and integration and communication risks, along with acceptance criteria and a classification logic. Chapter 6 describes how risk analyses are adopted, assessed and consolidated along the integration chain between customer and supplier. Chapter 7 provides four case studies: ATAM applied to lane keeping assist, ETA to an OTA update, CPA to traffic sign recognition and HAZOP to a door opener app. It also includes a flow chart for selecting methods in a safety-relevant project.

Three patterns to avoid

Reading the TRS as a new FMEA standard

If you treat the volume as the next standard and rewrite your own manual accordingly, you lose time and stability. Use the TRS to choose methods for software. Your stays where it works.

One method for all phases

Applying a single method across all four phases contradicts the logic of the volume. The concept phase needs different tools than maintenance. Use the ratings in Table 5-1 as your guide.

Waiting for the final version

If you wait to pilot until the volume is final, you no longer have any influence on its content. The comment phase is the right time for a pilot. You can report experiences and open questions directly to the VDA QMC.

Example

Based on the OTA case study in the volume (Chapter 7.1.2), a simplified example shows how the choice of method shifts across the phases. The function under consideration is "over-the-air software update of an ECU".

Concept: HARA asks what hazard arises if an update starts or aborts while the vehicle is ready to drive. TARA asks how an attacker could inject manipulated software. STPA models the control structure of backend, gateway, ECU and driver and identifies unsafe control actions, such as a release to flash when the vehicle electrical system voltage is too low.
Design: FMEA analyses the software component Update Manager. A DRBFM evaluates the design decision for a concept with a primary and a backup partition. In addition, a CCA checks whether a common failure in the bootloader can hit both partitions at the same time.
Implementation and testing: A SWIFT workshop goes through the update sequences with what-if questions: What if the update aborts? What if the vehicle electrical system voltage drops during flashing? What if the backend delivers the wrong software version?
Maintenance: In the field, the update runs on many vehicles. ETA starts with the initiating event "OTA update is started" and follows the paths through download, integrity check, installation and restart. As in the volume's example, the greatest risks lie not in the download but in installation and restart. Every later change to the update logic goes through a DRBFM.

Together, these questions produce a risk picture that remains traceable across the life cycle.

Conclusion

remains the anchor of technical Risk Analysis. For software, it is necessary but not sufficient. In your next software project, check for each phase which method answers the open question, and start the pilot while your feedback can still be incorporated into the volume.

Would you like to trial the VDA TRS in a pilot project or set up your software risk analysis anew?

We support you in choosing methods and facilitate the analyses in your team. Get in touch: www.dietz-consultants.com

Author: Winfried Dietz, CEO Dietz Consultants GmbH
Winfried Dietz is CEO of Dietz Consultants GmbH and has supported development organisations worldwide in introducing and maturing the FMEA methodology for more than 30 years. He is a trainer, author and speaker on FMEA according to AIAG-VDA. You can find more from the FMEA Quick Tip series on LinkedIn.