– 34 – Ingenieurspiegel 1 | 2012

ment zu folgen, jedoch früh-zeitig im Entwicklungsprozess abstrakte Systemmodelle zu erzeugen, welche die unter-schiedlichen Aspekte eines Sys-tems umfassend repräsentie-ren bzw. spezifi zieren. So kön-nen z.B. das Nutzungsverhal-ten, das funktionale Verhalten verschiedener Applikationen, die physische Architektur und die signaltechnischen Schnitt-stellen im selben Modell be-schrieben und dargestellt wer-den. Dies wird im Bild 2 durch einen Würfel symbolisiert, der eine Betrachtung des Gesamt-systems aus unterschiedlichen Blickrichtungen zulässt. Ein im Rahmen von MBRE erzeugtes Systemmodell kann also eine bislang in natürlicher Sprache aufwändig formulierte System-spezifi kation prinzipiell erset-zen. Es wird erwartet, dass sich insgesamt eine Methodologie erarbeiten lässt, mit welcher sich der Entwicklungsprozess von Kabinensystemen künftig noch besser beherrschen und vereinfachen lässt.

An dieser Stelle sei erwähnt, dass im Umfeld der modell-basierten Entwicklung folgen-de Begriffl ichkeiten fest defi -niert sind: Eine Methodologie besteht aus einer Sammlung von dazugehörigen Prozes-sen, Methoden und Werkzeu-gen (Tools). Sie stellt sozusa-gen das Rezept für die Anwen-dung von Prozessen, Methoden und Tools bei der Entwicklung dar [3]. Der Prozess ist eine lo-gische Abfolge von Aufgaben, die bewältigt werden müssen, um ein bestimmtes Ziel zu er-reichen. Er defi niert, „was“ er-ledigt werden soll. Die Metho-de liefert dem Prozess zu und defi niert, „wie“ etwas gemacht

erkennung von möglichen Feh-lern im Entwicklungsprozess kann das so genannte Model-Based-Requirements-Enginee-ring (MBRE) eingesetzt werden. Dieses verknüpft den textba-sierten und durch ein Anforde-rungsmanagementsystem ge-kennzeichneten RBE-Ansatz mit dem des Model-Based Systems Engineering (MBSE) [3]. Letzte-res nutzt so genannte forma-le Sprachen, wie beispielswei-se SysML oder UML [4], welche standardisiert sind und die Mo-dellierung von komplexen Sys-temen erlauben. Bild 2 stellt schematisch dar, wie sich Me-thoden der einfachen, form-losen Projektabwicklung, der Pfl ichten- und Lastenheft-ba-sierten Entwicklung, des RBE und des MBRE in Abhängig-keit von zunehmender System-komplexität und des damit ein-hergehenden Projektmanage-ment- und Entwicklungsauf-wandes einordnen und einset-zen lassen.

Kerngedanke von MBRE ist es, den Prinzipien des RBE mit sei-nem Anforderungsmanage-

te etablierte Systematik des Re-quirements-Based Engineering (RBE) [2] unterstützt die Ent-wickler in ihren Abläufen bei der Erstellung der textbasier-ten Systemspezifi kation. Jedoch lässt sich Text in Schriftform nicht wie ein Modell simulieren und automatisiert auf Konsis-tenz und Richtigkeit testen.

Zur einfacheren und effi zienten Beherrschung von hardware- und softwarebasierten kom-plexen Systemen und zur Früh-

Komplexität beherrschen: Methodologie für die modellbasierte Entwicklung von KabinensystemenAngesichts der komfortab-len Ausstattung heutiger Flug-zeugkabinen vergisst man sehr leicht, dass sich hinter der In-nenverkleidung komplexe tech-nische Systeme verbergen, de-ren Zuverlässigkeit und Sicher-heit beim Betrieb des Flugzeugs und seiner Kabine oberste Prio-rität haben (Bild 1).

Durch eine stark zunehmende Funktionsvielfalt bei modernen Kabinenmanagementsystemen [1], welche beim Kabinenbe-trieb für die Steuerung aller Ka-binensysteme zuständig sind, stellt deren Entwicklung noch immer eine große Herausfor-derung dar. Ein rein auf Text-dokumenten beruhendes Vor-gehen bei der Spezifi kation ge-rät an seine Grenzen, wenn es das komplexe Zusammenwir-ken aller Subsysteme im Pro-zess zu beschreiben gilt. Even-tuelle Fehler, die zu einem frü-hen Zeitpunkt bei der System-spezifi kation potenziell gesche-hen, können zu Verzögerungen und damit verbundenen Folge-kosten führen, wenn sie erst in der Testphase der Systeminteg-ration erkannt werden. Die heu-

Bild 1: Komfortable Flugzeugkabine mit komplexen technischen Sys-temen hinter der Innenverkleidung. Foto: Airbus Operations GmbH

Bild 2: Einsatz geeigneter Produktentwicklungsmethoden in Abhän-gigkeit von der Systemkomplexität und des Entwicklungsaufwandes

– 36 – Ingenieurspiegel 1 | 2012

werden soll. Ein Tool ist ein In-strument, dessen Einsatz eine im Rahmen eines Prozesses be-stehende Aufgabe vereinfacht und effi zienter gestaltet [3]. Es geht also übergeordnet um eine Methodologie für die künf-tige Entwicklung von Kabinen-systemen, wo Prozesse analy-siert und zum Einsatz kommen-de Methoden und Werkzeuge ausgewählt, aufeinander ab-gestimmt und auf Eignung er-probt werden müssen.

Zu Beginn eines jeden Projek-tes ist es wichtig, die System-komplexität und den erwarte-ten Entwicklungsaufwand ab-zuschätzen. Aus diesen beiden vorrangigen Parametern ergibt sich der Projektraum mit einer für die Projektbearbeitung an-gemessenen geeigneten Me-thode (Bild 2). Bei steigender Systemkomplexität und zu-nehmendem Entwicklungsauf-wand ist ein erfolgreicher Pro-jektverlauf nur durch den Ein-satz defi nierter Prozesse, ange-messener Methoden und mit den passenden Tools sicher-zustellen. Die richtige Einord-nung eines Entwicklungsvorha-bens stellt daher für die Projekt-leitung eine ernstzunehmen-de Herausforderung dar. Die versehentliche Einordnung in eine einfachere Kategorie kann leicht dazu führen, dass das Pro-jekt unbeherrschbar wird. Bei einer zu hohen Einstufung kön-nen die Aufwände für das Pro-jektmanagement schnell mehr Zeit und Geld verbrauchen als sich durch das Projektergebnis rechtfertigen lässt.

Die Entwicklung von Kabinen-systemen hat sich auf Basis des RBE bereits als herausfordernd erwiesen, sodass aktuell un-tersucht wird, ob sich der be-stehende Entwicklungsprozess durch Einsatz der Methode des MBRE verbessern lässt. Wie in Bild 3 dargestellt ist, folgt die-ser Entwicklungsprozess dem in der Luftfahrtindustrie etab-lierten V-Modell [3]. Dieses or-ganisiert den Prozess in ver-schiedene Phasen und defi niert

auch die für die Qualitätssiche-rung wichtigen Validierungs- und Verifi kationsaktivitäten, d.h. die in der jeweiligen Pha-se durchzuführenden System-tests und Entwicklungsüber-prüfungen. Im linken, grau ge-zeichneten Ast des V-Modells in Bild 3 ist dargestellt, wie heute Kabinensysteme nach der RBE-Methode entwickelt werden: In der ersten Phase wird das Top Level System Requirement Do-cument (TLSRD, eine Anforde-rungsspezifi kation, ein Lasten-heft) erstellt, welches die An-forderungen formuliert, „was“ das System leisten muss. In ei-ner zweiten Phase leitet sich davon das System Require-ment Document (SRD, eine Sys-temspezifi kation, ein Pfl ich-tenheft) ab, welches in na-türlicher Sprache beschreibt, „wie“ das System diese Anfor-derungen erfüllt. Aus der Pha-se des Systementwurfs resul-tiert schließlich die Purchaser Technical Specifi cation (PTS),

welche dem Systemhersteller die genauen Vorgaben für die Hardware- und Software-Im-plementierung liefert. Der lin-ke, blau dargestellte Ast des V-Modells zeigt unter MBRE, dass während der Phase des Syste-mentwurfs das SRD und die PTS durch ein Systemmodell ersetzt werden, was in Bild 3 durch das bereits eingeführte Würfelsym-bol dargestellt wird. Dieses Sys-temmodell wird in der forma-len Beschreibungssprache Sys-ML/UML [4] formuliert. Beson-ders in dieser Phase des Syste-mentwurfs können Systemmo-

delle Gewinn bringend einge-setzt werden. Entsprechende Werkzeuge (Tools) müssen da-her den Übergang vom text-basierten TLSRD zum System-modell in SysML/UML inklusive des aus dem RBE-Ansatz über-nommenen Anforderungsma-nagements unterstützen. Ist dieser Schritt vollzogen, so be-steht ein weiterer Vorteil in der Ausführbarkeit des Systemmo-dells. Das bedeutet, dass es mit seinen Funktionen und Schnitt-stellen simuliert und getestet werden kann. Dies ist auch im Zusammenwirken mit anderen umgebenden Systemen mög-lich, zu denen Umgebungsmo-delle bereits existieren. Man spricht daher auch von einer ausführbaren Spezifikation (Exec. Spec. = Executable Spe-cifi cation). Durch diese Tests in der Spezifi kationsphase kön-nen Fehler rechtzeitig vor der Systemintegration (vgl. Bild 3, rechter Ast des V-Modells) er-kannt werden.

Schließlich besteht eine weitere Möglichkeit darin, dass sich neu zu entwickelnde Systemkom-ponenten und Applikationen mit bereits real existierenden Hardwarekomponenten ver-binden und testen lassen. Auf diese Weise ist ein Rapid Pro-totyping möglich, was beispiel-haft im Bild 3 rechts dargestellt ist. Dort wurde real existieren-de Hardware in Form eines Ka-binensystem-Bedienpanels an das Applikationsmodell für die Lichtsteuerung in der Flugzeug-kabine angebunden und getes-tet.

Das Institut für Flugzeug-Kabi-nensysteme an der Technischen Universität Hamburg-Harburg arbeitet daran, mit der Metho-de des MBRE die Möglichkeiten zur Entwicklung von Kabinen-systemen zu verbessern. Dabei wird untersucht, welche Werk-zeugketten für die Anforde-rungsspezifi kation und für die Modellierung und Simulation von Systemen eingesetzt wer-den können und wie Validie-rungs- und Verifi kationstechni-ken in Verbindung mit Model-len und bei der Hardware-In-tegration vorteilhaft zur Fehle-rentdeckung und Qualitätssi-cherung genutzt werden kön-nen. Eine möglichst universell einsetzbare und handhabbare Methodologie, die sich in den heute bestehenden Kabinen-system-Entwicklungsprozess eingliedern lässt, die Übergän-ge zwischen den Entwicklungs-phasen verbessert und Aufwän-de, Zeit und Kosten reduziert, ist dabei das Ziel.

Ralf God und Hartmut HintzeInstitut für Flugzeug-Kabinen-systeme, TU Hamburg-Harburg

Referenzen

[1] Rosenberg B.: Cabin Ma-nagement Systems,

Avionics Magazine, Mai 2010, S. 26.

[2] C. Ebert.: Systematisches Requirements Engineering, 3. Aufl ., 2010

dpunkt.verlag GmbH.

[3] Estefan J.A.: Survey of Mo-del-Based Systems Enginee-ring (MBSE) Methodologies, INCOSE MBSE Initiative,

Mai 2008.

[4] Weilkiens T.: Systems Engi-neering mit SysML/UML, 2. Aufl . 2008

dpunkt.verlag GmbH.

Bild 3: Von RBE zu MBRE: Der modellbasierte Ansatz erlaubt die Ein-bindung realer Hardware zur Validierung des Systemdesigns