Case study: How Bosch managed to drastically reduce FMEA workload with AbRA

I am always on the lookout for examples of how MBSE can create real added value. Florian Beer, Chief Software Architect ADAS at Bosch, demonstrated this at the MBSE Summit using a practical example. He used the fact that meetings, and FMEA workshops in particular, are unpopular with many developers. The focus on a specific use case and pain point made this initiative a success. He published the underlying AbRA approach on Open-MBEE.

Florian Beer, Chief Software Architect ADAS, Robert Bosch GmbH

Florian Beer was invited as keynote speaker to the MBSE Summit this year in Traunkirchen invited. He began his presentation with a truth that is far too often ignored: MBSE is perceived as sluggish and inflexible, especially by people who come from a software development background.

MBSE is a tanker, software is a speedboat

Florian Beer

This impression stems in particular from the success of agile methods in software development. However, agile approaches cannot be easily transferred to MBSE: agility works well with small teams, but the team size inevitably increases for complex products. In addition, errors in software development are "cheap". In contrast, errors in system development, with expensive hardware and electronics, can be costly and lead to long delays.

In particular, complex system developments require a documented architecture. All project teams must understand and internalize this. However, they often have their own language, which can lead to the architecture being ignored.

Large software projects also need a little more structure, but have largely solved these problems with the help of package management, common standards and other techniques.

Concrete use cases lead to acceptance

So how can we use MBSE to develop an architecture that is actually used? It must always be up-to-date and help to solve specific challenges: We need a continuous architecture.

In continuous architecture, the architecture consists of building blocks. Teams are responsible for keeping them syntactically correct and internally semantically consistent. The architect, on the other hand, demands external semantic consistency. Here it helps to transfer functioning practices from software development such as unit tests, integration tests and continuous integration (CI) to the MBSE. Pull requests also represent a possible step towards agility.

AbRA: Architecture-based Risk Analysis

For safety-relevant products according to IEC 61508 or industry-specific derivatives certain analyses must be carried out with regard to reliability. These include, for example FMEA or FTA. However, creating and reviewing these is laborious and often involves considerable effort.

The aim of MBSE should be to create an architecture that really matters

Florian Beer

To this end, Florian Beer and Jürgen Sauler have developed the Architecture-based Risk Analysis (AbRA) and published at Open-MBEE. (AbRA actually deserves its own article). The aim of AbRA is to anchor failure modes directly in the architecture.

AbRA types that enable artifacts for FMEA to be anchored directly in the architecture. Source: Open-MBEE

Initially, the project team has to invest in a good architecture, but this approach has enormous advantages for the project. The workload for designing the analysis is better distributed among the various team members and the review of the failure modes is much more efficient as part of architecture maintenance with AbRA. As a result, the number of large meetings can be reduced without any loss of quality in the analysis results. The work still has to be done, but in a much more pleasant (and meaningful) context.

...and Bosch has thus significantly increased efficiency, because it really makes little sense to create a product architecture at the FMEA workshop that already exists or is "redrawn" shortly afterwards in duplicate work

Jan Zutter at LinkedIn

At the same time, the benefits of the architecture for the teams have increased dramatically, leading to continuous maintenance of the architecture by the teams. Even if this is primarily about the failure modes, the entire architecture benefits from this "crowd maintenance". By bringing forward the failure analysis, problems with the architecture in terms of functional safety also come to light earlier.

Conclusion

Florian Beer has shown beautifully how an MBSE strategy can lead to concrete use cases that bring real benefits to the teams and are therefore also put into practice. Specifically, with AbRA at Bosch, risk analysis can be made significantly more efficient and the time and effort required for FMEA workshops can be reduced. At the same time, the teams recognized the benefits of the architecture and carried out the necessary maintenance of the architecture independently.

By publishing AbRA, other teams can also benefit from this work.