Functional Safety und Systems Engineering – Munich Open Space

Funktionale Sicherheit und Systems Engineering sind zwei wichtige Themen der Entwicklung mechatronischer Systeme. Bisweilen als schwer und prozesslastig empfunden, sind beide Themen im Kern gar nicht so schwer zu greifen. Einen wunderbaren Austausch dazu bot am vergangenen Wochenende die Konferenz Munich Open Space.

In diesem Beitrag gibt’s 7 Erkenntnisse zur Funktionalen Sicherheit und 10 Erkenntnisse zum Systems Engineering, und ein paar Impressionen des Munich Open Space. Veranstalter war Colin Hood, der in der Systems & Requirements Engineering Community seit dreißig Jahren eine feste Größe ist.

An drei Konferenztagen mit dem jeweiligen Fokus auf Functional Safety, Requirements Engineering und Systems Engineering konnten wir im kleinen Kreis von unter 30 Leuten unsere Erfahrungen und Wissen zusammenwerfen und von den anderen lernen. Das Open Space Format, über das ich schon nach dem PM Camp Dornbirn berichtete, war auch hier sehr hilfreich, um genau die Agenda entstehen zu lassen, die den Teilnehmern den größten Nutzen bot.

In den 45 Minuten, die eine Session jeweils dauert, ist auf jeden Fall genug Zeit, ein Stück weit in die Tiefe zu tauchen, aber gleichzeitig sich auch nicht zu lange in einem einzelnen Aspekt festbeißen.

Die Agenda der „Un-Konferenz“ entsteht direkt am Morgen, wenn die Teilnehmer ihre Sessionvorschläge einbringen. Dabei kann eine Dynamik entstehen, bei der Teilnehmer versuchen, Themen nicht nur in nacheinander folgenden Sessions zu gruppieren, sondern gleich mehrere Vorschläge in einer Session zusammenzufassen. Besonders Ingenieuren ist wohl eigen, dass sie ständig Information strukturieren und vereinheitlichen wollen. Widerstehe diesem Drang. Zwei Teilnehmer können scheinbar das gleiche Thema auf zwei sehr unterschiedliche Weisen führen, und haben vielleicht verschiedene Facetten im Kopf. Wenn genügend Zeitfenster frei sind, kann es sehr wertvoll sein, die Sessions separat stehen zu lassen.

Open Space zu Functional Safety

Thema des Tages: Funktionale Sicherheit, auf gut Englisch Functional Safety, also auch alles rund um ISO 26262, IEC 61508 und alle verwandten Standards.

Aus der Agenda für den Open Space Funktionale Sicherheit möchte ich exemplarisch die drei Themen herausgreifen, die ich vorgeschlagen hatte:

1. Agile und Functional Safety: Zunächst mag es so aussehen, dass agile Entwicklung und das vermeintlich strikte Vorgehen für Funktionale Sicherheit nicht gut zusammen passen. Passt aber doch.
2. Functional Safety – Funktion oder Mindset: Was ist zielführender – eine Abteilung mit Spezialisten für Funktionale Sicherheit oder das Functional-Safety-Mindset für alle?
3. Modellierung und Simulation in der Functional Safety: Was bringt Modellierung und Simulation für die Belange der Funktionale Sicherheit?

Dabei ist klar, dass ich nicht als Privatperson da war, sondern weil wir bei Elektrobit Automotive Consulting genau diese Themen bearbeiten.

7 Erkenntnisse zur Funktionalen Sicherheit

1. Functional Safety sieht inkrementelles Vorgehen vor. Deshalb gibt es ja die ganzen unterschiedlichen Work Products.
2. Artefakte – also „Work Products“ der Funktionale Sicherheit gehören ins Scrum-Backlog. Da sie wichtig fürs Produkt sind und zum lauffähigen, sprich zertifizierten, System dazugehören, sind sie wie normale Tasks oder User Stories zu behandeln.
3. Scrum ist teilweise strikter als die meisten Prozesse, in denen Funktionale Sicherheit entsteht: Während eines Sprints werden keine Anforderungen geändert.
4. Funktionale Sicherheit klappt dann, wenn sich jeder im Entwicklungsprozess bewusst wird, dass man das nicht nachträglich drauf setzt. Funktionale Sicherheit bedeutet in erster Linie saubere, dokumentierte Entscheidungen und Entwicklung, und das kann und soll jeder machen.
5. Funktionale Sicherheit als Alleinaufgabe einer Stabsabteilung oder eines Beauftragten zu sehen führt zu großen Reibungsverlusten. Funktionale Sicherheit ist jedermanns Sache.
6. Beim Modellieren und Simulieren gilt: „A fool with a tool is still a fool.“ Ohne eine Vorstellung, was man erreichen will, wird es nichts helfen und man verzettelt sich.
7. Für jedes Softwaretool braucht es ein Anwendungskonzept. Wildes rummachen mit Tools ist nicht hilfreich, wenn hinten etwas nachvollziehbares rauskommen soll.

Funktionale Sicherheit ist kein Hexenwerk. Es ist lediglich ungewohnt, wieder ganz sauber entwickeln zu müssen und Entscheidungen sauber vorzubereiten und zu dokumentieren. Wie das geht, kann man aber lernen.

Systems Engineering Camp

Das Systems Engineering Camp wurde von der GfSE veranstaltet, der „Gesellschaft für Systems Engineering e. V. – German Chapter of INCOSE“. Auch beim Systems Engineering Camp habe ich für Elektrobit Automotive Consulting drei Sessions vorgeschlagen und durchgeführt:

1. Wertbeitrag oder Theater: Ist das, was wir im Systems Engineering tun, tatsächlich nützlich und fürs Produkt notwendig?
2. Ausführbare Spezifikation – Modellierung und Simulation: Möglichkeiten und Erfahrungen aus 10 Jahren Arbeit mit Organisationen aller Couleur.
3. Systems Engineering Bullshit Bingo: Spaß im Systems Engineering. Welche Phrasen hören wir immer wieder?

10 Erkenntnisse zum Systems Engineering und Architekturen

Aus diesen Sessions und den anderen – siehe Foto der Agenda – blieben mir einige Kernaussagen hängen:

1. Der Systems Engineer ist der Dirigent Jazz-Musiker in der Combo, der zur richtigen Zeit die richtigen Experten aus den verschiedenen Fachgebieten einbindet, um das bestmögliche System zu entwickeln. Der Systems Engineer muss nicht alle Antworten selbst haben, sondern transportiert die Systemidee in die Fachbereiche.
2. Es ist zu unterscheiden, welche Aktivitäten im Systems Engineering tatsächlich Wertbeitrag liefern und was Theater ist. Dazu empfehle ich ausdrücklich das Buch Zurück an die Arbeit von Lars Vollmer.
3. Was Wertbeitrag und was Theater ist, kann von Projekt zu Projekt, von Organisation zu Organisation verschieden sein. Beispiel: Reports für die Abarbeitung von Requirements kann Theater sein, oder nützlich.
4. 75% aller niedergeschriebenen und verwalteten Anforderungen sind Prozess-Theater und können ohne Einschränkungen eliminiert werden. Colin Hood sagt dazu: „Wenn du aufgeschrieben hast, was das System tun soll, hör auf.“
5. Sage genau, welche Architektur du meinst/bearbeitest/vorschlägst: Systemarchitektur, Funktionale Architektur, Software-Architektur, Hardware-Architektur oder eine ganz andere.
6. Wer schon frühzeitig modelliert und simuliert, weiß früher, ob die funktionale Architektur funktioniert. Das predige ich seit über einem Jahrzehnt mit MATLAB und Simulink.
7. Vorsicht vor unüberlegter Modellierung und unbedachter Simulation. Nur wer weiß, was die Frage ist, kann gut modellieren. Siehe auch Erkenntnis 5. Da gibt es übrigens eine ganze Dissertation dazu zu lesen.
8. Nehmen wir uns nicht ganz so ernst im Systems Engineering – eine Runde Bullshit Bingo gibt befreiendes Lachen. Und achten wir auf das, was wir im Projektalltag sagen, fordern, tun.
9. Was Bullshit-Begriffe sind und was nicht, hängt von der jeweiligen Organisation ab. Adjektive und Akronyme sind immer heiße Kandidaten für hohle Phrasen.
10. Der Unterschied zwischen Mitarbeit und Konfrontation beim Erstellen der Architektur liegt in präzisen Formulierungen. Es ist ein Unterschied, ob ich in der Systemarchitektur einen CAN-Transceiver vorsehe oder CAN-Kommunikation.

Und das sind nur die Dinge, die hängen blieben, es gab noch viel mehr.

Bonus: Regeln für Systems Engineering Bullshit Bingo

1. Nimm einen Zettel beliebiger Größe, und trage dort 5 x 5 Felder ein.
2. In jedes Feld kommt ein Begriff, ein Akronym, eine Redewendung, die eine hohle Phrase darstellt oder einfach zu oft oder falsch gebraucht wird.
3. Nehme an einer Projektdiskussion oder einer Besprechung teil und höre genau zu.
4. Jedes mal, wenn einer der Begriffe vorkommt, kreuze das passende Feld an.
5. Sind fünf Begriffe in einer vertikalen, horizontalen oder diagonalen Reihe markiert, rufe „Bingo“.

Unsere Beispiele sind oben im Foto zu sehen. Als Diskussion haben wir einfach eine emuliert und hatten dabei viel Spaß.

Im konkreten Fall hatten wir in 2 Teams unsere Begriffe an zwei Seiten einer großen Stellwand gepinnt und dann gegeneinander gespielt. Besonders interessant war dabei, wie unterschiedlich teilweise die Begriffswelten der Teams waren.

Open Space – offen und doch zielgerichtet

Was sind Deine Erfahrungen mit Systems Engineering, oder mit Open Space Konferenzen? Lass es die anderen Leser und mich wissen und kommentiere unten!

Impressionen

Einige Impressionen des Munich Open Space, bei dem sich jeden Tag zwischen 20 und 30 Interessierte, Experten trafen.

Alle Fotos: Joachim Schlosser Fotografie, Claudia Bösewetter.

Offenlegung: Ich nahm an der Veranstaltung als Mitarbeiter von Elektrobit Automotive Consulting teil. Dieser Artikel ist keine offizielle Verlautbarung, sondern stellt meine persönliche Meinung dar.