Systems Engineering Trends

Donnerstags in 5 Minuten für Ingenieure und Entscheider: Systems Engineering ohne Hype, dafür mit Tiefgang

FallbeispielFunktionale SicherheitModellierung & MBSE

Case Study: Wie Bosch es geschafft hat, FMEA-Aufwand mit AbRA drastisch zu reduzieren

Ich bin immer auf der Suche nach Beispielen, wie MBSE einen echten Mehrwert schaffen kann. Florian Beer, Chief Software Architect ADAS bei Bosch, zeigte dies beim MBSE Summit am praktischen Beispiel. Dazu nutze er Tatsache, dass Meetings, und ganz besonders FMEA-Workshops, bei vielen Entwicklern unbeliebt sind. Der Fokus auf einen konkreten Anwendungsfall und Pain Point machten diese Initiative zum Erfolg. Den zugrundeliegenden Ansatz AbRA hat er bei Open-MBEE veröffentlicht.

Florian Beer, Chief Software Architect ADAS, Robert Bosch GmbH

Florian Beer wurde als Keynote Speaker zum MBSE Summit dieses Jahr in Traunkirchen eingeladen. Er begann seinen Vortrag mit einer Wahrheit, die viel zu oft ignoriert wird: MBSE wird als träge und unflexibel wahrgenommen, insbesondere von Menschen, die aus der Softwareentwicklung kommen.

MBSE ist ein Tanker, Software ist ein Speedboat

Florian Beer

Dieser Eindruck stammt insbesondere vom Erfolg agiler Methoden in der Softwareentwicklung. Doch agile Ansätze lassen sich nicht so ohne weiteres auf MBSE übertragen: Agilität funktioniert gut mit kleinen Teams, doch für komplexe Produkte steigt die Teamgröße zwangsläufig. Außerdem sind Fehler in der Softwareentwicklung „billig“. Im Gegensatz dazu können Fehler in der Systementwicklung, mit teuer Hardware und Elektronik, teuer sein und zu langen Verzögerungen führen.

Insbesondere erfordern komplexe Systementwicklungen eine dokumentierte Architektur. Diese müssen alle Projektteams verstehen und verinnerlichen. Doch diese haben häufig ihre eigene Sprache, was zum Ignorieren der Architektur führen kann.

Große Softwareprojekte brauchen auch etwas mehr Struktur, haben aber mit Hilfe von Package-Management, gemeinsamen Standards und anderen Techniken diese Probleme weitgehendst gelöst.

Konkrete Anwendungsfälle führen zur Akzeptanz

Wie können wir nun mit MBSE eine Architektur entwickeln, die tatsächlich genutzt wird? Diese muss immer aktuell sein und helfen, konkrete Herausforderungen zu lösen: Wir brauchen eine kontinuierliche Architektur.

Bei der kontinuierlichen Architektur besteht die Architektur aus Bausteinen. Teams haben die Verantwortung, diese syntaktisch korrekt und innerlich semantisch konsistent zu halten. Der Architekt hingegen fordert die äußere semantische Konsistenz ein. Hier hilft, funktionierende Praktiken aus der Softwareentwicklung wie Unit Tests, Integrationstests und Continuous Integration (CI) auf das MBSE zu übertragen. Pull-Requests stellen ebenfalls einen möglichen Schritt in Richtung Agilität dar.

AbRA: Architecture-based Risk Analysis

Für sicherheitsrelevante Produkte nach IEC 61508 oder branchenspezifischen Derivaten müssen bestimmte Analysen bezüglich der Zuverlässigkeit durchgeführt werden. Dazu gehören bspw. FMEA oder FTA. Doch diese zu erstellen und zu reviewen ist mühselig und oft mit erheblichen Aufwänden verbunden.

Das Ziel von MBSE sollte sein, eine Architektur zu schaffen, die wirklich zählt

Florian Beer

Dazu hat Florian Beer zusammen mit Jürgen Sauler unter dem Namen Architecture-based Risk Analysis (AbRA) entwickelt und bei Open-MBEE veröffentlicht. (AbRA verdient eigentlich einen eigenen Artikel). Ziel von AbRA ist es, Failure Modes direkt in der Architektur zu verankern.

AbRA-Typen, die es ermöglichen, Artefakte für FMEA direkt in der Architektur zu verankern. Quelle: Open-MBEE

Initial muss das Projektteam in eine gute Architektur investieren, doch dieser Ansatz hat enorme Vorteile für das Projekt. Die Arbeitslast für den Entwurf der Analyse wird besser auf die verschiedenen Teammitglieder verteilt und das Review der FailureModes sind im Rahmen derArchitekturpflege mit AbRA deutlich effizienter. Dadurch kann notwendige die Anzahl von großen Meetings reduziert werden, ohne dass das Analyseergebnis an Qualität verliert. Die Arbeit muss zwar immer noch gemacht werden, aber in einem wesentlich angenehmeren (und sinnvolleren) Kontext.

…und damit hat Bosch deutlich Effizienz gehoben, denn beim FMEA Workshop eine Produktarchitektur zu erstellen, die bereits existiert bzw. kurz darauf noch mal in Doppelarbeit „nachgezogen“ wird macht nun wirklich wenig Sinn

Jan Zutter bei LinkedIn

Gleichzeitig hat sich der Nutzen der Architektur für die Teams drastisch erhöht, was zu einer kontinuierlichen Pflege der Architektur durch die Teams führt. Auch wenn es dabei primär um die FailureModes geht, profitiert die gesamte Architektur von dieser „Crowd-Maintenance“. Durch die Vorverlagerung der Failure-Analyse kommen auch Probleme mit der Architektur bezüglich funktionaler Sicherheit früher ans Licht.

Fazit

Florian Beer hat schön gezeigt, wie eine MBSE-Strategie zu konkreten Anwendungsfällen führen kann, die den Teams einen echten Nutzen bringt und dadurch auch gelebt wird. Konkret kann mit AbRA bei Bosch auf die Risikoanalyse deutlich effizienter gestaltet und der Aufwand von FMEA-Workshops reduziert werden. Gleichzeitig erkannten damit die Teams den Nutzen der Architektur und führten die erforderliche Pflege der Architektur selbstständig durch.

Durch die Veröffentlichung von AbRA können auch andere Teams von dieser Arbeit profitieren.

Michael Jastram

Creator and Author of SE-Trends