Von Spezifikationsmodellen zu Anforderungen
Modellbasiertes Arbeiten ist ein Weg, um mit mit der steigenden Komplexität umzugehen. Doch im Team erfolgreich modellbasiert zu arbeiten ist nicht leicht. Insofern ist es oft hilfreich, Anstöße aus der Praxis zu bekommen. Im heutigen Gastbeitrag berichtet Carsten Pitz, wie Spezifikationsmodelle helfen, die Brücke von den Anforderungen in die Modellierungswelt zu schlagen.
Gastbeitrag von Carsten Pitz
Ich hatte vor kurzem einen interessanten Gedankenaustausch mit einem System Verifizierer/Zertifizierer in der Luftfahrt. Der Aufhänger war, dass die DO-331 zwischen Spezifikationsmodellen und Designmodellen unterscheidet. Mein Diskussionspartner kannte nur Designmodelle. So startete eine intensive Diskussion von der ich sehr viel gelernt habe und mich zu diesem Beitrag inspiriert hat.
DO-331 definiert Regeln für DO-178C und DO-278A konformes MBSE.
https://www.apt-research.com/wp-content/uploads/2017/05/MBSESSS_DO-331_Alford_Hendrix.pdf
Was sind Spezifikationsmodelle?
Nach meiner Interpretation sind Spezifikationsmodelle nichts Neues. Für mich führen als Beispiele
- die Sichten NAV (NATO All View), NCV (NATO Capability View) und NOV (NATO Operational View) der NAFv3,
- die Schichten Strategic und Operational des UAF,
- die Schichten Operational Analyses und System Analyses von Arcadia
- als auch auch die Schritte Analyse the Problem und Despribe System Idea and System Objectives der SysMod
- oder auch die Operational Architecture meines Ansatzes
allesamt zu Spezifikationsmodellen.
Wozu Spezifikationsmodelle?
Alle diese Sichten hinterfragen das Was und führen zu einer Spezifikation des zu entwickelnden Systems. Bei der Spezifikation geht es nicht um das Wie, es geht ausschließlich um das Was. Das Was ergänzt durch unter welchen Randbedingungen und in welcher Güte. Randbedingungen sind z.B. Witterungsbedingungen. Unter Güte subsummiere ich z.B. Reaktionszeiten oder Regelgenauigkeit. Aber auch das RAM aus RAMS (Reliability, Availability, Maintainabilty, Safety) zähle ich zur Güte. Gerade bei sicherheitskritischen Systemen müssen die Randbedingungen und die Güte sauber definiert sein.
Entsprechend spezifizieren Spezifikationsmodelle für sicherheitskritische Systeme Verhalten. Verhalten ist die Basis für Gefährdungsanalysen (hazard analysis). Zum Anderen liefert die Risikobewertung (risk assessment) die einzuhaltenden Randbedingungen und notwendige Güte. Dieses Wechselspiel zwischen den Rollen System Architekt (spezifizieren) und Functional Safety Engineer (Gefahren analysieren und Risiko bewerten) muss meines Erachtens dem 4-Augen-Prinzip unterliegen. Ich schätze als System Architekt das 4-Augen-Prinzip. Auch, da bei einer offenen Diskussion mit dem Functional Safety Engineer häufig Verbesserungspotentiale offensichtlich werden.
Eine kleine Anmerkung: Die im Teaserbild gezeigte Bremse besteht aus zwei unabhängigen Bremsen in einem Gehäuse. Sprich 2-mal 2 Geberkolben mit jeweils einem Bremsbelag. Also insgesamt 4 Geberkolben und 4 Bremsbeläge. Die Auslegung ist derart, dass wenn eine (Teil-)Bremse ausfällt, die andere (Teil-)Bremse immer noch genügend Bremsleistung liefert das Rad jederzeit zu überbremsen. Gibt mir ein gutes Gefühl 😉
Carsten Pitz
Spezifikationsmodell ist ein Anforderungsdokument
So ist ein Spezifikationsmodell zugleich ein Anforderungsdokument. Ob jetzt eine Sammlung von Anforderungen als Teilmodell (z.B. als finiter Zustandsautomat) belassen wird oder die im Zustandsautomat z.B. als Transitionsbedingungen dargestellten Anforderungen in textuelle Anforderungen umgewandelt werden hängt vom Projektkontext ab. CIL4Sys und auch ich habe gute Erfahrungen gemacht textuelle Anforderungen per model2text Transformation aus dem Modell zu generieren.
Ich hoffe das dieser Beitrag regt auch zum Denken und zur Diskussion an.
Bildquelle: Carsten Pitz
