Die Technik entwickelt sich vom Primitiven über das Komplizierte zum Einfachen. (Antoine de Saint-Exupéry)

Transkript

1 1 1 Einleitung Die Technik entwickelt sich vm Primitiven über das Kmplizierte zum Einfachen. (Antine de Saint-Exupéry) Nach der Lektüre dieses Kapitels können Sie die flgenden Fragen beantwrten: Warum gibt es dieses Buch? Was ist mdellbasiertes Systems Engineering (Vgelperspektive)? Welcher Zusammenhang besteht zwischen den Sprachen OMG SysML TM und UML TM? Wie verhält sich der Inhalt dieses Buchs zu verwandten Themen wie beispielsweise CMMI TM, ReqIF, Mdelica der dem V-Mdell? 1.1 Vrweg»Früher war alles viel einfacher. Da knnte man nch mit einer Handvll Leute etwas auf die Beine stellen. Heute sind es schnell hundert Leute, die man braucht, um ein rdentliches System zu entwickeln. Und die kriegen dann meist nichts auf die Reihe... Denk dch nur mal an das Prjekt P08/15. Dabei sind drt Experten aus allen Bereichen vertreten...«slche der ähnliche Feierabendmnlge höre ich immer häufiger. Als Geschäftsführer eines Beratungsunternehmens treffe ich viele Persnen aus den unterschiedlichsten Branchen. Der Tenr ist aber gleich. Wran liegt das? Ganz einfach: am Frtschritt. Wir sind an einem Punkt angekmmen, an dem kmplexe und verteilte Systeme gefrdert werden, die vn kmplexen und verteilten Organisatinen entwickelt werden. Die herkömmlichen Entwicklungsmethden sind aber nch nicht bereit, diese ausreichend schnell und in einem akzeptablen Kstenrahmen zur Verfügung zu stellen.»früher war alles besser!«wechselstimmung

2 2 1Einleitung»Frtschritt ist unaufhaltsam.«vn Bits zu Objekten Wir können nicht erwarten, immer frtschrittlichere, größere, bessere Systeme zu entwickeln und dabei weiterhin dieselben Werkzeuge einzusetzen. Die Vrgehensweisen, Mdellierungssprachen, Entwicklungsumgebungen und Rllen wie der Systems Engineer müssen an dem Frtschritt teilhaben und sich ebenfalls weiterentwickeln. In der Sftwareentwicklung ist dieser Weg an einem Beispiel deutlich zu sehen. Angefangen bei Lchkarten über Assembler, przedurale Prgrammiersprachen bis hin zu den bjektrientierten Sprachen kennen die Entwicklungswerkzeuge immer größere Bausteine (vn Bits bis Klassen/Objekte). Sie erleichtern s die Beschreibung kmplexer Systeme. Der Weg zur nächsten Generatin ist bereits eingeschlagen: Die grafische Unified Mdeling Language (UML TM ) der dmänenspezifische Sprachen (DSL) werden zunehmend verwendet, um Sftwaresysteme zu entwickeln, und mit diesen Sprachen werden immer mehr Aufgaben gelöst, die vrher mit herkömmlichen Prgrammiersprachen erledigt wurden (Abb. 1.1). Abbildung 1.1 Steigende Abstraktin der Prgrammiersprachen Abstraktin Grafische Mdellierungssprachen (z.b. UML) Objektrientierte Sprachen Assembler Przedurale Sprachen Generierung =3 Systems Engineering Das Gesamtsystem ist mehr als die Summe seiner Bausteine. Die Wechselwirkungen zwischen den Elementen können kmplex und schwer kntrllierbar sein. Das führt dazu, dass Vrgehensmdelle und Ntatinen benötigt werden, um effektiv diese Systeme entwickeln zu können. Ansnsten werden die Ksten der Entwicklung in naher Zukunft in keinem Verhältnis zum akzeptablen Preis der Prdukte stehen. Das Systems Engineering (Systementwicklung 1 ) setzt sich schn länger mit dieser Prblematik auseinander. Die Entwick- 1 Eigentlich bevrzuge ich deutsche Begriffe. Mit Systems Engineering mache ich eine Ausnahme, da dieser Begriff auch im deutschsprachigen Raum geläufiger ist als die Übersetzung.

3 1.1 Vrweg 3 lung grßer Systeme, bei der viele unterschiedliche Disziplinen beteiligt sind, erfrdert ganzheitliche Sichtweisen. Als lsgelöst vm spezifischem Detailwissen werden die Anfrderungen und Strukturen des Systems betrachtet, der gesamte Lebenszyklus vn der Idee bis zur Entsrgung geplant, um insgesamt ein System zu entwickeln, das den Wünschen aller Beteiligten entspricht. Im Systems Engineering frdert der Frtschritt einen Paradigmenwechsel: vm dkumentenzentrierten zum mdellbasierten Systems Engineering (MBSE). Das Mdell wird zur Quelle aller relevanten Infrmatinen. Um gleich einem gängigen Missverständnis vrzugreifen: Die Dkumente sllen nicht verschwinden. Nur sind sie nicht mehr die Quelle der Infrmatinen, sndern eine Sicht auf das Mdell, beispielsweise autmatisch erzeugt vn einem Mdellierungswerkzeug. Die Mdellierungssprachen OMG Systems Mdeling Language (OMG SysML TM ) und UML spielen in diesem Szenari natürlich eine wichtige Rlle. Die Sftwareentwicklung kann viel vm Systems Engineering lernen. Zum Nehmen gehört aber auch ein Geben. Umgekehrt kann das Systems Engineering auch vn der Sftwareentwicklung lernen. Werkzeuge und Methden zur Mdellierung sind hier schn sehr weit entwickelt. Die UML ist eine Mdellierungssprache aus diesem Umfeld. Sie hat sich als weltweiter Standard etabliert. Dem Systems Engineering fehlte bisher eine standardisierte Mdellierungssprache. Das wird sich durch die neue SysML 2 ändern. Sie basiert auf der UML und wird vn führenden Unternehmen aus der Systems-Engineering-Branche einschließlich des Internatinal Cuncil n Systems Engineering (INCOSE) unterstützt. Mdellbasiertes Systems Engineering (MBSE) Vneinander lernen UML ) S. 201 SysML ) S. 309 INCOSE ) S Passt das Buch zu mir? Dieses Buch wird Sie interessieren und für Sie sehr hilfreich sein, wenn Sie... die Mdellierungssprache SysML lernen wllen, Systeme beschreiben, spezifizieren und entwickeln, mit kmplexen Systemen arbeiten, Systems Engineering mit SysML durchführen wllen, Systeme mit gemischten Disziplinen beispielsweise Sftware und Hardware entwickeln, 2 Krrekter wäre die Bezeichnung OMG SysML TM. Ich werde aber in diesem Buch häufig die Kurzfrm SysML verwenden.

4 4 1Einleitung ein ganzheitliches Mdell erstellen wllen, in dem Elemente nachvllziehbar zusammenhängen (Traceability), einen durchgängigen Weg vn der Systemidee zum Systemdesign kennenlernen wllen. Werkzeugkasten SYSMOD Wenn Sie sich nicht in den bigen Punkten wiederfinden, fragen Sie mich, b das Buch für Sie wertvll sein könnte. Ich freue mich über eine vn Ihnen: tim@larus.de. Sie lernen in diesem Buch einen Werkzeugkasten kennen, mit dessen Hilfe Sie einen Weg vn der Idee eines Systems zur Architektur finden. Die Ergebnisse halten wir in detaillierten und aussagekräftigen Mdellen fest. Die Mdellierungssprache ist SysML. Der Werkzeugkasten heißt SYSMOD abgeleitet vn Systemmdellierungsprzess bzw. Systems Mdeling Prcess Was bietet mir das Buch? In diesem Buch finden Sie: den Werkzeugkasten SYSMOD zur Systementwicklung vn der Systemidee zur Systemarchitektur, Steckbriefe zu den Werkzeugen, die Sie individuell zu einem Gesamtvrgehen zusammensetzen können das Buch gibt Ihnen einen Standardweg vr, eine Beschreibung der SysML und UML, eine Einführung in das Systems Engineering, Randntizen beispielsweise über Variantenmanagement, funktinale Architekturen, Simulatin, Testen und Mdellierungsmuster, Best Practices zu SysML und SYSMOD Wie ist das Buch entstanden? Und danke! UML hne Sftware Die Idee zu diesem Buch hatte ich im Jahr 2003 bekmmen. Zu dieser Zeit hatte ich viele Seminare und Beratungseinsätze zum Thema Analyse und Design mit der UML. Der Teilnehmerkreis knzentrierte sich auf Sftwareentwickler vm Prgrammierer bis zum Prjektleiter. In einem Seminar hatte sich allerdings ein außergewöhnlicher Teilnehmerkreis zusammengefunden: Ingenieure, z. B. Nachrichtentechniker, aber kein einziger Sftwareentwickler. Sie planten ein grßes Prjekt, das Sftware, aber auch bauliche Maßnahmen, Hardware und andere Disziplinen beinhaltete. In der Schulung habe ich den Sftwareaspekt reduziert und

5 1.1 Vrweg 5 die Analyse- und Designtechniken allgemeiner erläutert. Für die Teilnehmer hat sich hieraus eine hervrragende Vrgehensweise für ihr Prjekt ergeben. Diese Teilnehmerknstellatin war ab dann kein Einzelfall mehr. Es flgten weitere Seminare, Wrkshps und Beratungsaufträge, in denen keine Sftwareentwickler, sndern Ingenieure aus anderen Disziplinen teilnahmen, die Analyse und Design mit der UML für ihre Arbeit kennenlernen wllten. In mir keimten zunehmend Fragestellungen, Ideen und weiterführende Überlegungen auf: Wie viel Sftware enthält eigentlich die UML? Wie beschreibe ich Anfrderungen mit der UML? Wie gehe ich mit hybriden Systemen um? Mir wurde langsam bewusst, dass die Sprache UML und die Vrgehensweise in vielen Bereichen unabhängig vn Sftware eingesetzt werden kann. Der Blick über den Tellerrand hinaus hat mich zur Disziplin Systems Engineering geführt. Hier knnte ich mich mit meinen Gedanken gut einrdnen. Der Zufall wllte es, dass ich in der Zeit durch meine Arbeit in der OMG an der UML2 angesprchen wurde, b ich die Entwicklung der SysML unterstützen könnte. Das passte hervrragend in meine aktuellen Überlegungen, und ich habe sfrt zugesagt. Seitdem bin ich aktiv an der Entwicklung vn SysML beteiligt und Kautr der SysML-Spezifikatin. Die allgemeine Vrgehensweise in Analyse und Design, das Systems Engineering und die Mdellierungssprache SysML das Msaik wurde vllständig. Das Bild, das sich daraus ergeben hat, möchte ich Ihnen in diesem Buch darstellen. Die passenden Msaiksteine knnte ich nur finden, da meine Ideen in vielen Diskussinen mit meinen Kunden und Partnern reifen knnten. Dafür ein grßes Dankeschön! Besnders erwähnen möchte ich Reiner Dittel, Marc Enzmann, Ulrich Lenk und Rbert Karban, Andreas Peukert swie Dr. Rudlf Hauber und weitere Mitglieder aus dem INCOSE MBSE Challenge Team SE^2 3. Vielen Dank auch an Jesk Lamm vn der Firma Bernafn für die zahlreichen Diskussinen und das gemeinsame Entwickeln der Methdik zu funktinalen Architekturen für Systeme (FAS) [58]. Die kreativen Auseinandersetzungen in der SysML-Arbeitsgruppe der OMG mit sehr kmpetenten Mdellierern und Systemingenieuren haben mich grße Schritte vrangebracht. Mein be- Systems Engineering und SysML OMG ) S. 201 Danke, Kunden und Partner! Danke, SysML! 3 Im Rahmen der MBSE-Initiative vn INCOSE haben sich weltweit Challenge Teams zur Weiterentwicklung des MBSE gebildet. Die Ergebnisse des SE^2-Teams finden Sie auf der Webseite mbse.gfse.de.

6 6 1Einleitung Danke, se! Danke, Verlag! Danke, Richard! Danke, Reviewer! Danke, Pavel Hruby! Danke, Leser! snderer Dank gilt Cnrad Bck, Sanfrd Friedenthal, Bran Selic, Alan Mre und Rger Burkhart. Sehr wichtig für meine fachliche und persönliche Weiterentwicklung sind die Umgebung und die Freiräume, die mir meine Firma se Innvative Infrmatik GmbH gibt. Vielen Dank an meine Kllegen und ganz besnders an Bernd Oestereich für die Unterstützung. Einige Abbildungen in diesem Buch wurden freundlicherweise vn der se Innvative Infrmatik GmbH zur Verfügung gestellt. Ein grßes Lb und Dankeschön an den dpunkt.verlag. Vr allem natürlich an Christa Preisendanz! Es ist immer eine Freude, mit Richard M. Sley zu kmmunizieren. Vielen Dank für das fantastische Geleitwrt. Ohne ein fachliches Review kann ein Buch keine ausreichende Qualität erreichen. Der Blick vn außen ist wichtig. Vielen Dank besnders an Wlfgang Krenzer vn IBM Autmtive Industry und Andreas Krff vn ARTiSAN Sftware Tls GmbH für die Reviews der 1. Auflage dieses Buchs. Ich möchte auch Pavel Hruby für die hervrragende UML- Visi-Schablne danken ( Sie wird übrigens auch für die ffizielle UML- und SysML-Spezifikatin verwendet. Vielen Dank natürlich auch an Sie, dass Sie dieses Buch gekauft haben und sich für das Thema interessieren. An Ihrem Feedback bin ich sehr interessiert. Schreiben Sie mir: Wie lese ich das Buch? Lesen und Nachschlagen Einleitung SYSMOD Randntizen Das Buch besteht aus zwei Teilen: Kapitel 1 und Kapitel 2 sind zum durchgängigen Lesen, Kapitel 3 und flgende sind primär zum Nachschlagen geeignet. Sie befinden sich gerade in Kapitel 1. Hier erfahren Sie etwas über das Buch selbst beispielsweise diese Anleitung zum Lesen swie einführende Grundlagen zum Thema Systems Engineering, SysML und UML. Sie können dieses Kapitel auch überspringen und direkt in Kapitel 2 einsteigen. In Kapitel 2 beschreibe ich das Vrgehen SYSMOD, um die Anfrderungen an ein System zu erfassen, zu mdellieren und eine Architektur abzuleiten, die den gestellten Anfrderungen genügt. Die Ergebnisse des Vrgehens werden mit SysML mdelliert. Am Ende vn Kapitel 2 streife ich weitere Themen, die für das Vrgehen wichtig sind, wie beispielsweise funktinale Architekturen, Variantenmanagement und Mdellmanagement.

7 1.1 Vrweg 7 In Kapitel 4 und Kapitel 3 erläutere ich die Mdellierungssprachen UML und SysML. Da SysML auf der UML aufbaut, stehen im SysML-Kapitel nur die erweiternden Elemente. Im UML-Kapitel erläutere ich entsprechend nur die Sprachelemente, die auch in SysML verwendet werden. Beide Kapitel stellen als insgesamt den SysML-Sprachumfang dar. Die Abgrenzung zeigt Ihnen deutlich, was die UML leistet und was die SysML ergänzt. In Kapitel 5 beschreibe ich die Spracherweiterungen (Steretypen), die das in Kapitel 2 beschriebene Vrgehen SYSMOD benötigt. Sie gehören nicht zu den Sprachstandards SysML und UML. Am Seitenrand stehen Zwischenüberschriften zur besseren Orientierung und Querverweise mit Seitenangaben zu Zusatzinfrmatinen, die für das Verständnis des Absatzes hilfreich sind. UML und SysML Prfil SYSMOD Steretyp ) S. 299 Seitenrand Whin geht der Weg? Mit SysML hat die UML ihr Ausbreitungsgebiet weiter vergrößert. Ausgehend vn einer reinen Mdellierungssprache zur Sftwareentwicklung über die Geschäftsprzessmdellierung [61] nun zur Mdellierungssprache des Systems Engineering. Whin führt dieser Weg? Es scheint, dass die UML auf dem besten Weg ist, zur Lingua franca der Mdellierung zu werden. Das Ptenzial hat sie. Die UML ist erweiterbar und smit an spezifische Bedürfnisse anpassbar. Sie ist internatinal verbreitet, erprbt und anerkannt. Und hinter ihr steht die OMG ein internatinal agierendes Knsrtium, dem führende IT-Firmen angehören. Auch wenn ich ein starker Verfechter der UML bin und sie derzeit in ihrer Rlle knkurrenzls sehe, glaube ich nicht, dass sie die Lingua franca der Mdellierung wird. Ich denke (und hffe), dass dies keine Sprache erreichen wird. Eine gewisse Vielfalt ist ntwendig. Die UML legt aber die Saat für künftige Mdellierungssprachen, was dazu führt, dass sie sich im Kern ähneln und in gewissen Grenzen kmpatibel sind. Die Zukunft wird einen grßen Bedarf an Mdellierungssprachen bringen. Unsere Systeme, die wir entwickeln, werden immer kmplexer. Die Mdellierungssprachen erlauben es mir, mich auf verschiedenen Abstraktinsebenen zu bewegen. Je abstrakter ich werde, dest einfacher erscheint mir das System. Ein guter Mdellierer beherrscht die Kunst, auf abstrakter Ebene knkret zu werden. Ausbreitung der UML Lingua franca? Kmpatible Sprachfamilie

8 8 1Einleitung Weiterführende Referenzen 4 Die Hmepage zum Buch und MBSE-Blg: SYSMOD als Eclipse-Prcess-Framewrk-Mdell: Beispielmdelle nline: Kfz-Zugangssystem: example.mdel-based-systems-engineering.cm Teleskpprjekt: mbse.gfse.de Direkter Kntakt: tim@larus.de Beratung, Trainings, Prjektarbeit: Systems-Engineering@se OMG TM Hauptseite OMG SysML TM INCOSE, Gesellschaft für Systems Engineering e.v.

9 1.2 Systems Engineering Systems Engineering Jede Disziplin und jede Branche hat ihre eigenen Methden. Sei Unterschiedliche es die Sftwareentwicklung, die Hardwareentwicklung, die Mechanik, das Bauwesen, die Psychlgie und s weiter. Diese Ab- unterschiedliche Disziplinen, grenzungen funktinieren gut, slange man in einem Prjekt innerhalb einer Disziplin bleibt. Bei disziplinübergreifenden Prjek- Methden ten wird es schwieriger. Zwischen den Methden der jeweiligen Disziplinen müssen Schnittstellen geschaffen und aufeinander abgestimmt werden. Das Prjektmanagement steht dann der Herausfrderung gegenüber, die Besnderheiten aller Disziplinen zu berücksichtigen. Die vielen Witze über die Eigenarten vn Physikern, Ingenieu- Unterschiedliche ren, Infrmatikern, Mathematikern & C. machen deutlich, dass Charaktere bei interdisziplinären Prjekten unterschiedliche Welten aufeinanderstßen 4. Missverständnisse und Knflikte sind vrprgrammiert. Die Sftwareentwickler überlegen sich beispielsweise eine Gute Einzellösung, neue leistungsfähige Architektur. Diese benötigt allerdings mehr schlechte Speicherressurcen. Das fällt erst sehr viel später bei der Integratin mit der Zielhardware auf. Die Hardwareentwickler sehen eine Gesamtlösung Möglichkeit, die Hardware ausreichend mit Speicher zu erweitern. Das Prblem scheint gelöst. Aber nch viel später stellt man fest, dass die erweiterte Hardware keinen Platz mehr im Gehäuse hat, da die Gehäusedesigner vn der Änderung nicht infrmiert wrden sind. Die erhöhte Wärmeentwicklung der Hardware wird die gefrderten Grenzwerte überschreiten. Jede Disziplin hat in ihrem Bereich die bestmögliche Lösung eingearbeitet. Die Summe der besten Einzellösungen ist aber nicht immer die beste Lösung für das Gesamtsystem. 1+1 ergibt als 3. Die Entwicklung disziplinenspezifischer Sub- 1+1=3 systeme wird gut beherrscht. Aber das»+«erhöht die Kmplexität und führt zu vielfältigen Prblemen. Allzu häufig fehlt in Prjekten die verantwrtliche Rlle für die Summenbildung, als die ganzheitliche, systemweite Sicht. Dabei gibt es hierfür bereits 4 Ein Maschinenbauer, ein Chemiker und ein Infrmatiker fahren in einem Aut durch die Wüste. Plötzlich bleibt das Aut stehen, und die drei beginnen über die Ausfallursache zu streiten. Der Chemiker:»Sicher ein unvermuteter Entrpiezuwachs im Mtrraum!«Der Maschinenbauer:»Blödsinn, es ist einfach der Keilriemen gerissen der der Zündverteiler hat sich verabschiedet!«... usw.... usw.... Bis es dem Infrmatiker zu dumm wird:»ist dch egal, wir steigen einfach aus und wieder ein, dann wird s schn wieder laufen.«

10 10 1Einleitung Was bedeutet kmplex? bewährte Methden und Strategien. Die Disziplin des Systems Engineering beschäftigt sich seit über 50 Jahren mit diesem Thema.»Das ist ganz schön kmplex!«das haben Sie bestimmt schn einmal gesagt. Was meint man eigentlich damit? Was bedeutet kmplex? Es gibt nch ein ähnliches Wrt: kmpliziert. Ist es dasselbe? Nein! Etwas Kmplexes muss nicht kmpliziert sein. Die flgende Definitin geht auf Gerg Klaus zurück [56]. Definitin Die Kmplexität bezieht sich auf die Anzahl und Art der Beziehungen zwischen Elementen in einem System. Die Kmpliziertheit bezieht sich auf die Anzahl der unterschiedlichen Elemente. Essenzielle Kmplexität Gemäß dieser Definitin sind viele Systeme kmplex und hybride Systeme zusätzlich kmpliziert. Das ist die Kernherausfrderung des Systems Engineering. Der Umgang mit der Kmplexität zielt primär nicht darauf, sie zu reduzieren, sndern sie einfach erscheinen zu lassen. Systeme besitzen eine essenzielle Kmplexität, die in der Natur des Systems liegt [7]. Sie kann nicht reduziert werden, hne den Systemzweck zu verändern. Schlechte Lösungen können eine unnötige technische Kmplexität einführen, die im Rahmen des Systems Engineering der disziplinenspezifischer Betrachtungen reduziert werden kann Was ist Systems Engineering? Allgemeinbegri Definitin System Sicherlich haben Sie schn einmal vn der Disziplin Systems Engineering gehört. Und wenn nicht, kmmt der Begriff Ihnen vermutlich nicht fremd vr. Swhl System als auch Engineering sind bekannte Allgemeinbegriffe. In Kmbinatin hat auch jeder eine gewisse Vrstellung, was diese Disziplin ausmacht. Diese Vrstellungen sind nur ft sehr verschieden. Was verstehen Sie unter einem System? Ein Flugzeug? Ein Aut? Eine Lagerverwaltung? Ein Navigatinssystem? Eine Textverarbeitungssftware? Ihr Laptp? Ein Unternehmen? Alle Beispiele sind krrekt.

11 1.2 Systems Engineering 11 Definitin Ein System ist ein vn Menschen erstelltes Artefakt, bestehend aus Systembausteinen, die gemeinsam ein Ziel verflgen, das vn den Einzelelementen nicht erreicht werden kann. Ein Baustein kann aus Sftware, Hardware, Persnen der beliebigen anderen Einheiten bestehen (nach [73]). Diese Definitin des Systembegriffs ist bewusst sehr allgemein gehalten. Sie können im Sinne des Systems Engineering auch an sehr grße Systeme denken. Beispielsweise an das Luftfahrtverkehrssystem, bestehend aus Flughäfen und Luftfahrtverkehrsstraßen. Bei der Größenbetrachtung des Systems müssen Sie deutlich zwischen der Größe des realen Systems und der Größe des Systemmdells unterscheiden. Das Luftfahrtverkehrssystem ist real deutlich größer als ein Aut. Wenn wir die zugehörigen Systemmdelle betrachten, kann es umgekehrt sein. Es ist abhängig vn der Detaillierungstiefe der Mdelle. Das Aut können wir beispielsweise bis zur letzten Schraube mdellieren. Im Systemmdell des Luftfahrtverkehrssystems verwenden wir aber als kleinste Einheiten beispielsweise Flugzeuge und Flughäfen. Dieses Beispiel ist übrigens ein typisches System f Systems (SS). Jetzt kennen Sie den ersten Teil des Begriffs Systems Engineering. Der zweite Teil der englische Begriff Engineering steht allgemein für eine Disziplin, die Methden und Werkzeuge strukturiert einsetzt, um ein Prdukt zu entwickeln. Zusammengesetzt beschreibt der Begriff Systems Engineering Methden, um erflgreich Systeme zu entwickeln. Grße Systeme Mdellgröße vs. Systemgröße SS ) S. 192 Definitin Engineering Definitin Systems Engineering Definitin Das Systems Engineering ist ein interdisziplinärer Ansatz und knzentriert sich auf die Definitin und Dkumentatin der Systemanfrderungen in der frühen Entwicklungsphase, die Erarbeitung einer Systemarchitektur und die Überprüfung des Systems auf Einhaltung der gestellten Anfrderungen unter Berücksichtigung des Gesamtprblems: Betrieb, Zeit, Test, Erstellung, Ksten & Planung, Training & Wartung und Entsrgung (nach [73]).

12 12 1Einleitung Metadisziplin Abbildung 1.2 Disziplinen des Systems Engineering Das Systems Engineering integriert alle Disziplinen und beschreibt einen strukturierten Entwicklungsprzess vm Knzept über die Prduktins- bis zur Betriebsphase und abschließend wieder die Außerbetriebnahme des Systems. Es werden swhl die technischen als auch die wirtschaftlichen Aspekte betrachtet, um ein System zu entwickeln, das den Benutzerbedürfnissen entspricht. Diese ganzheitliche Denkweise schließt beispielsweise auch Lösungen zu Prblemen ein, die erst durch die Einführung eines neuen Systems entstehen. pkg [package] SysML-Buch [Systems-Engineering-Aufgaben] Systems Engineering Prjektmanagement Risikmanagement Requirements Engineering Requirements Management Systemarchitektur Systemverifikatin Systemvalidierung Systemintegratin Abbildung 1.2 zeigt Aufgabenbereiche des Systems Engineering in Paket Frm eines SysML-Paketdiagramms. Die einzelnen Bereiche wer- ) S. 296 den jeweils nur auf Systemebene betrachtet und tauchen nicht in die Details einer Disziplin ein. Die Knzepte des Systems Engineering findet man in den spezifischen Disziplinen wieder. Die Art und Weise, Prbleme zu frmulieren und Lösungswege zu entwickeln, weist hier viele Parallelen auf, die im Systems Engineering allgemein beschrieben sind.

13 1.2 Systems Engineering 13 Knzeptin Entwicklung Prduktin Betrieb Wartung Entsrgung Abbildung 1.3 Lebensphasen eines Systems Systems Engineering betrachtet den gesamten Lebenszyklus eines Systems. Abbildung 1.3 zeigt die im Standard ISO/IEC definierten Phasen eines Systems [73]. Das Lebensphasenmdell beschreibt die zeitlichen Abschnitte Entwicklung, Realisierung, Nutzung und Entsrgung. Eine Herausfrderung in der Entwicklung vn Systemen liegen darin, dass in der Entwicklungsphase Entscheidungen getrffen werden müssen, deren Flgen erst in späteren Phasen wirksam werden. In den späteren Lebensphasen besteht aber nur nch wenig Einfluss auf die Systemeigenschaften. Daraus leiten sich wichtige Fragen ab, die wir uns in der Entwicklungsphase stellen müssen, z. B.: Systemlebensphasen Welche Prbleme löst das System? Welche Prbleme erzeugt das System? In welchem Umfeld wird das System eingesetzt? Wie lange sll das System eingesetzt werden? Wie wird das System durch einen Nachflger ersetzt? Angenmmen Sie entwickeln einen Flugzeugantrieb auf Basis einer neu entdeckten Substanz als Treibstff. Neben der reinen Antriebsentwicklung müssen Sie auch klären, wie die Tanksysteme auf den Flughäfen aussehen müssen. Kann der Antrieb nach herkömmlichen Methden entsrgt werden der sind eigene Entsrgungssysteme ntwendig? Welche Auswirkungen haben die Abgase auf Mensch und Natur? Und viele weitere Fragen sind zu beantwrten. Der Prblemlösungszyklus beschreibt den Weg vm Auftreten des Prblems bis zur Lösung [41]. Die grbe Struktur besteht aus drei Schritten, die nicht nur linear, sndern auch mit Rückkpplungen durchlaufen werden: Beispiel Prblemlösungszyklus 1. Aktuelle Situatin beschreiben und das zu erreichende Ziel frmulieren 2. Lösungsmöglichkeiten erarbeiten 3. Beste Lösung auswählen Was s einfach und selbstverständlich klingt, wird in der Praxis nicht immer s gelebt. Allzu ft wird beispielsweise Punkt 1 ausge-

14 14 1Einleitung lassen der in Punkt 2 nur eine Lösung betrachtet. Das Vrgehen in diesem Buch beginnt mit der Frmulierung des Ziels der Systementwicklung (Abschnitt 2.3). Die Analyse und die Architektur des Systems in einem Mdell unterstützen die Betrachtung unterschiedlicher Varianten, sdass die ptimale Lösung ausgewählt werden kann (siehe auch Abschnitt ) Systems-Engineering-Przesse Einen guten Überblick über einen Systems-Engineering-Przess liefert das SIMILAR-Przessmdell [1]. Es ist eine Abkürzung und steht für flgende Aufgaben: State the prblem Investigate alternatives Mdel system Integrate Launch the system Assess perfrmance Re-evaluate Im Einzelnen bedeuten die Aufgabenbereiche: Anfrderungsmdell erstellen (State the prblem) Am Anfang der Systementwicklung steht die Beschreibung der Aufgabe. Nur zu einer gut gestellten Aufgabe kann man auch eine gute Lösung finden. Fehler in dieser Phase können sehr kstspielig werden, swhl finanziell als auch für das Ansehen. Die Aufgabenstellung definiert, was das System leisten bzw. welche Anfrderungen das System erfüllen sll. Der Systems Engineer beschäftigt sich mit Anfrderungen auf Systemebene. Das Anfrderungsmdell beschreibt auf der betrachteten Ebene nicht die Lösung. Dies würde die Möglichkeit verbauen, alternative Lösungen zu evaluieren. SYSMOD- Zickzackmuster ) S. 182 Alternative Lösungen prüfen (Investigate alternatives) Eine wichtige Aufgabe des Systems Engineers ist es, alternative Knzepte zu prüfen und gegeneinander abzuwägen. Leider wird diese Aufgabe ft vernachlässigt. Der menschliche Drang, sich auf nur eine Lösung zum Prblem zu knzentrieren, verdeckt den

15 1.2 Systems Engineering 15 Blick darauf, dass eine alternative Lösung gegebenenfalls besser geeignet ist. Der Systems Engineer entwirft basierend auf dem Anfrderungsmdell als nicht nur eine Systemarchitektur, sndern üblicherweise auch alternative Architekturen. Hiermit können verschiedene Lösungswege gegeneinander abgewgen werden. Selten wird es eine eindeutige Lösung geben, die alle Vrteile in sich vereint. Es müssen als verschiedene Kriterien und Priritäten betrachtet werden. Typische Aspekte sind beispielsweise Ksten, Größe, Gewicht, Entwicklungszeit, Time-t-Market und Risiken. Aus den Systemmdellen werden Parameter abgeleitet, um die ntwendigen Aspekte unmittelbar sichtbar, vergleichbar und am Mdell messbar zu machen. SysML bietet hierzu beispielsweise das Zusicherungsdiagramm an (Abschnitt 4.6). Systemmdell erstellen (Mdel system) Mdelle werden bereits beim Abwägen der alternativen Lösungsmöglichkeiten erstellt. Jetzt wird das Mdell der ausgewählten Lösung detailliert. Die Mdellierung mit SysML ermöglicht eine gute Verflgbarkeit (Traceability) vn Aspekten, beispielsweise die Umsetzung einer Anfrderung (siehe Erfüllungsbeziehung in Abschnitt 4.3.4). System einbetten (Integrate) Das System wird nicht alleine dastehen und einem Selbstzweck dienen. Es wird in eine Umgebung eingebettet und mit dieser Umgebung interagieren. Die Einbettung wird in dieser Aufgabe betrachtet. Sie beinhaltet beispielsweise die Definitin der Systemschnittstellen. System implementieren (Launch the system) Das System wird gemäß dem spezifizierten Architekturmdell erstellt und in Betrieb genmmen. Die Mdelle aus den vrherigen Schritten geben Implementierungsanfrderungen für die Sftware, Hardware, Mechanik usw. vr. Technische Messwerte prüfen (Assess perfrmance) Das lauffähige System wird getestet und vermessen. Die Werte müssen den gestellten Anfrderungen entsprechen. Der Zusam-

16 16 1Einleitung menhang zwischen Test- und Anfrderungsmdell wird in SysML mit der Prüfbeziehung hergestellt (Abschnitt 4.3.6). Prjektergebnisse überprüfen (Re-evaluate) Risikmanagement Diese Aufgabe steht übergreifend über allen anderen Aktivitäten. Ergebnisse aus dem Przess werden kritisch geprüft und bewertet. Als Knsequenz werden die gewnnenen Erkenntnisse als Rückkpplung wieder in den Przess eingegeben. Ein weiteres Themenfeld des Systems Engineering, das nicht Teil der Abkürzung SIMILAR ist, ist das Risikmanagement bzw. psitiver frmuliert das Vrsrgemanagement. Um in einem Prjekt ein gutes Risikmanagement betreiben zu können, ist ein allgemeines Grundverständnis aller Beteiligten ntwendig: Die Prjektmitarbeiter sind in ihrer Arbeit nicht abslut perfekt, und die Prjektleiter können nicht zaubern. Dinge gehen einfach schief. Das ist der Nrmalzustand. Das Risikmanagement srgt dafür, dass ptenzielle Risiken identifiziert und Maßnahmen definiert werden, um das Risik zu minimieren bzw. das Prblem bei Eintritt des Risikfalls zu lösen. Es ist Teil der Entscheidungsprzesse im Prjekt und bedarf regelmäßiger Bebachtung, um den Eintritt eines prgnstizierten Risikfalls auch rechtzeitig zu entdecken und entsprechend zu reagieren Der Systems Engineer Bindeglied Organigramm Der Systems Engineer ist das Bindeglied zwischen den einzelnen ftmals sehr unterschiedlichen Disziplinen eines Prjekts. Er denkt systemweit unabhängig vn Sftware, Hardware der anderen spezifischen Gesichtspunkten. Organisatrisch ist die Systems-Engineering-Disziplin häufig ähnlich einer Stabsstelle eingerdnet. Sie berichtet direkt an die Gesamtprjektleitung, die wiederum direkt mit den anderen Entwicklungsabteilungen kmmuniziert. Der Systems Engineer ist nicht der Vermittler zwischen Prjektleitung und den Entwicklungsabteilungen. Er legt die Architektur des Systems fest und muss in der Lage sein, sich mit den unterschiedlichen Entwicklungsabteilungen fachlich auseinanderzusetzen, und nicht nur die Rlle des Bebachters und Nachrichtenüberbringers spielen. Insbesndere ist er auch mit Entscheidungsbefugnissen ausgestattet. Laut INCOSE sllten 20 30% des gesamten Prjektbudgets in das Systems Engineering fließen [73].

17 1.2 Systems Engineering 17 In vielen Prjekten fehlt die in Abbildung gezeigte Organisatinseinheit Systems Engineering. Ihre Aufgaben werden vn der Gesamtprjektleitung und den einzelnen Entwicklungsabteilungen wahrgenmmen. bdd [package] Systems Engineering [Organigramm] Systems Engineering «reprts t» Gesamtprjektleitung Implizites Systems Engineering Abbildung 1.4 Organisatrische Einrdnung des Systems Engineering «reprts t» Sftware Hardware Mechanik... Auch wenn die Gesamtprjektleitung inhaltlich in der Lage wäre, die Aufgaben des Systems Engineering zu übernehmen, fehlt neben den Leitungsaufgaben die ntwendige Zeit. Die Entwicklungsabteilungen kmmunizieren explizit nur mit ihren unmittelbaren Nachbardisziplinen, zu denen Schnittstellen existieren. Dadurch ist zwar ein gewisser Weitblick vrhanden, aber keine ganzheitliche Systemsichtweise. Das führt zu den in der Praxis bebachtbaren Prblemen, dass leicht der Überblick über kmplexe Systeme verlren geht. Ein häufiges Szenari ist, dass die Disziplin, die (meist) histrisch bedingt im Unternehmen dminiert, die Aufgaben des Systems Engineering übernimmt. Spätestens sbald andere Disziplinen an Bedeutung zunehmen, entstehen in dieser Knstellatin Knflikt- und Missverständnisptenziale, beispielsweise ein Maschinenbauer mit einer zunehmend dminierenden Sftwaredisziplin. Die Entwicklungsabteilungen des Prjekts lösen Teilprbleme des Gesamtprblems. Jede Teillösung ist Auswahl aus einer Menge mehrerer Lösungsvarianten. Die Auswahlkriterien sind hne die Rlle des Systems Engineers geprägt vn der jeweiligen Disziplin. Wechselwirkungen zwischen den Lösungsvarianten der Histrische Strukturen Gesamtlösung fkussieren 5 Die Abbildung zeigt ein Organigramm in UML-Ntatin. Näheres zur Geschäftsprzessmdellierung mit UML finden Sie in [61].

18 18 1Einleitung Przesse einführen einzelnen Entwicklungsabteilungen bleiben unbemerkt. Das angewendete Teile-und-herrsche-Prinzip funktiniert nur, wenn jemand das Gesamtprblem im Fkus hat und dafür srgt, dass die Summe der besten Teillösungen die beste der möglichen Gesamtlösungen ergibt. Als erst herrschen, dann teilen. Das ist eine der Aufgaben des Systems Engineering. Die Einbettung des Systems Engineering in die Prjektstruktur zeigt, dass es nicht hne Unterstützung aller Abteilungen insbesndere des Managements eingeführt werden kann. Neben der rganisatrischen Veränderung ist es auch eine Änderung der Prjektkultur. Klare Regeln und für alle Stakehlder transparente Aufgabenbeschreibungen sind wichtige Werkzeuge bei der Einführung eines Entwicklungsprzesses. Es kann nur funktinieren, wenn es swhl vn ben (Management) als auch vn unten (Entwicklung) getrieben wird und man sich in der Mitte trifft bzw. sehr nahe kmmt. Tendenziell ist die Disziplin Systems Engineering auf dem Vrmarsch und wird zunehmend als eigenständige Organisatinseinheit und in Przessen realisiert Histrie des Systems Engineering Damals vr 5000 Jahren... 50er-Jahre Die Menschheit hat schn vr über 5000 Jahren Systeme entwickelt. Damals haben die Ägypter ihre impsanten Pyramiden gebaut. Vn Systems Engineering hat zu der Zeit nch niemand gesprchen. Auch wenn dies zum Teil bereits als Beginn der Disziplin angesehen wird, machen wir einen grßen Zeitsprung nach vrne zum Anfang des 20. Jahrhunderts und setzen drt die Geburtsstunde des Systems Engineering. Die industrielle Revlutin hat viele Systeme hervrgebracht, die eher mit dem Begriff des Systems Engineering verbunden werden: Auts, Flugzeuge, Maschinen. Den Ingenieuren war das Systems Engineering als eigenständige Disziplin aber nach wie vr fremd. Ein Chefingenieur war in der Lage, das gesamte System zu überblicken, und die Teildisziplinen knnten relativ autnm entwickelt werden, da die Schnittstellen einfach waren. Das heutige Systems Engineering hat sich Ende der fünfziger Jahre entwickelt. In dieser Zeit hat die Menschheit Systeme in Angriff genmmen, deren Kmplexität und Prjektdurchführung alles bisher Dagewesene übertrafen. Das Wettrennen der Weltmächte im Weltraum der das militärische Wettrüsten hat Prjekte ins Leben gerufen, die auf der einen Seite sehr kmplexe Systeme entwickeln mussten und auf der anderen

19 1.2 Systems Engineering 19 Seite gezwungen waren, schnell und erflgreich zu sein. Dieser immense Druck hat dazu geführt, dass Methden des Systems Engineering entwickelt wurden. Auch im kmmerziellen Bereich wurden die Systeme kmplexer und der Bedarf nach ganzheitlichen Methden größer. Aus dem Telekmmunikatinsbereich stammt beispielsweise eine frühe Publikatin vn Arthur Hall»Methdlgy fr Systems Engineering«vn 1962 [42]. Langsam, aber stetig ist die Bedeutung des Systems Enginee- ISO/IEC ring angewachsen. Es sind nicht mehr nur die Riesenprjekte aus der Luft- und Raumfahrt, sndern auch»gewöhnliche«prjekte, die die Techniken dieser Disziplin einsetzen. Im Jahre 2002 ist der Przessrahmen ISO/IEC [49] eingeführt wrden, der die Przesse entlang des Lebenszyklus eines Systems beschreibt. Damit ist das Systems Engineering auch frmal eine anerkannte Disziplin in der Entwicklung vn Systemen. Aufgrund der Histrie dminiert das klassische Systems Engineering nach wie vr in den USA und in den Dmänen Luftund Raumfahrt swie in militärischen Prjekten. Insbesndere die SysML hat dem Thema mdellbasiertes Systems Engineering (MBSE) grßen Vrschub geleistet. Ein Überblick über MBSE finden Sie in Abschnitt Internatinal Cuncil n Systems Engineering 1990 wurde in den USA die Organisatin Natinal Cuncil n Systems Engineering (NCOSE) gegründet. Die Ziele waren die Entwicklung und Förderung des Systems Engineering in den USA. Nur fünf Jahre später sind diese Ziele auf internatinale Ebene ausgedehnt wrden und aus NCOSE wurde das Internatinal Cuncil n Systems Engineering (INCOSE). Die über 9500 Mitglieder kmmen vrwiegend aus den USA (ca Mitglieder), Grßbritannien (ca. 820 Mitglieder) und Frankreich (ca. 510 Mitglieder). Aus Deutschland kmmen ca. 420 Mitglieder (Abb. 1.5). Zu den amerikanischen Mitgliedern gehören beispielsweise Mitarbeiter der Firmen NASA, Being und General Mtrs. Zu den deutschen Vertretern zählen Mitarbeiter der Firmen Siemens, BMW und se. INCOSE ist in sgenannte Chapters unterteilt. In Deutschland ist das lkale INCOSE-Chapter die Gesellschaft für Systems Engineering e.v. (GfSE). Weitere Infrmatinen zu INCOSE und der GfSE finden Sie auf den Webseiten und

20 20 1Einleitung Abbildung 1.5 INCOSE- Mitgliederverteilung (2005/2007/2013) Anzahl INCOSE-Mitglieder (2005/2007/2013) Feb 05 Jul 07 Sep USA Fran nkreich Grßbrita ritannien Niede erlande Süd dafrika Deutsc schland Israel Aus stralien Systems Engineering in Deutschland Implizites Systems Engineering Tendenz steigend Deutschland hat hinsichtlich erflgreicher Prduktentwicklung weltweit eine bedeutende Stellung. Die Vermutung liegt nahe, dass das Systems Engineering knsequent betrieben wird. Näher betrachtet ist aber festzustellen, dass zwar die methdischen Ansätze des Systems Engineering angewendet werden, die Disziplin bisher aber keine hervrgehbene Rlle einnimmt. Nur selten findet man explizit einen etablierten Systems-Engineering- Przess, eine Systems-Engineering-Abteilung der einen Systems Engineer entsprechend der ben genannten Definitin. Glücklicherweise steigen aber die Zahlen und Systems Engineering ist in Deutschland deutlich auf dem Vrmarsch. Mein persönlicher Eindruck aus einer Vielzahl vn Prjekten, die ich im Rahmen meiner Berater- und Trainertätigkeit kennengelernt habe, ist, dass es ein zunehmendes Bewusstsein für die Ntwendigkeit des Systems Engineering gibt. Eine Kennzahl, die meine Wahrnehmung untermauert, ist die deutlich steigende Zahl an Mitgliedern in der GfSE. Ihre Anzahl hat sich vn 2005 bis 2013 verdreifacht.

21 1.3 Mdellbasiertes Systems Engineering (MBSE) 21 Mit zunehmender Bedeutung des Systems Engineering steigt auch die Anzahl der Aus- und Weiterbildungsangebte. Neben Beratungs- und Trainingsanbietern wie die Firma se listet die Webseite der GfSE 6 über 30 Hchschulangebte 7 auf. Ich arbeite aktuell gemeinsam mit der FH Campus02 aus Graz am berufsbegleitenden Masterstudiengang Systems Engineering Leadership 8. Er setzt auf den psitiven Erfahrungen des Masterstudiengangs Sftware Engineering Leadership 9 auf. Ziel ist es, die Studierenden für Führungsrllen im Systems Engineering zu befähigen. Aus- und Weiterbildung Systems Engineering Leadership 1.3 Mdellbasiertes Systems Engineering (MBSE) In many respects, the future f systems engineering can be said t be mdel-based. Schlüsseltechnlgie Das ist die Aussage vn INCOSE in ihrem Papier zur Visin 2020 [69]. Mdellierung ist eine Schlüsseltechnlgie zur Entwicklung kmplexer Systeme. Die Mdelle halten die Infrmatinen knsistent zusammen und ermöglichen verschiedene Sichten mit unterschiedlichen Abstraktinsebenen. Das ist ntwendig, da eine einzelne Persn die Kmplexität mit all ihren interdisziplinären Abhängigkeiten nicht mehr bewältigen kann. INCOSE definiert MBSE wie flgt: Definitin Mdellbasiertes Systems Engineering (MBSE) ist die frmalisierte Anwendung der Mdellierung, um die Aktivitäten zu Systemanfrderungen, Architektur, Analyse, Verifikatin und Validierung vn Beginn der knzeptuellen Architekturphase über die Entwicklung bis zu den späteren Phasen des Systemlebenszyklus zu unterstützen (nach [69]) Stand Februar

22 22 1Einleitung MBSE=SysML? Die Definitin klingt auf den ersten Blick eingängig. MBSE ist vereinfacht frmuliert, Systems Engineering mit einem Systemmdell. Auf den zweiten Blick stellt sich die Frage, was ein Mdell ist. Handelt es sich um ein SysML-Mdell? SysML wird in der Definitin vn INCOSE zu MBSE aber nicht erwähnt. MBSE ist weit mehr als SysML. SysML ist nur eine Sprache, die im MBSE eingesetzt wird. INCOSE definiert nicht den Begriff des Mdells. In SYSMOD definiere ich den Begriff des Systemmdells wie flgt: Definitin Das Systemmdell im Kntext des MBSE ist das Abbild eines realen der nch zu entwickelnden Systems, wbei mittels Abstraktin nur die für einen definierten Zweck relevanten Attribute berücksichtigt werden. Das Systemmdell ist gekennzeichnet durch die flgenden Eigenschaften: Das Systemmdell darf sich aus mehreren Repsitries zusammensetzen, muss aber in sich knsistent sein und sich nach außen wie ein einzelnes Mdell verhalten. Das Systemmdell erlaubt unterschiedliche Sichten auf die Infrmatinen. Das Systemmdell ist maschinell auswertbar und liegt in einer abstrakten Syntax vr, die explizit MBSE-Knzepte wie Anfrderungen der Systemarchitekturen unterstützt. Nach dieser Definitin ist ein einzelnes SysML-Mdell ein Systemmdell. Das Gleiche gilt für ein SysML-Mdell, das mit einem Anfrderungsmdell, einem UML-Mdell und einem CAD-Mdell verbunden ist. Ein Textverarbeitungsdkument ist kein Systemmdell, sndern nur eine mögliche Sicht auf ein Mdell. In den flgenden Abschnitten gebe ich Ihnen einen kurzen Überblick über eine Auswahl an Mdellierungssprachen im Umfeld vn MBSE Die Sprachen UML und OMG SysML UML Im Bereich der Sftwareentwicklung hat sich die Unified Mde- ) S. 201 ling Language (UML) als Mdellierungssprache etabliert. Es ist

23 1.3 Mdellbasiertes Systems Engineering (MBSE) 23 ein weltweiter Standard, der vn der Object Management Grup (OMG) spezifiziert wird. Die UML ist auch als ISO-Standard anerkannt (ISO/IEC 19501). Trtz zahlreicher Initiativen, die Przesse des Systems Engineering zu standardisieren (z. B. ISO/IEC 15288, EIA-632), hat sich bisher keine einheitliche Mdellierungssprache ergeben. Das führt zu erheblichen Reibungsverlusten in interdisziplinären Prjekten. Infrmatinen in Frm vn Mdellen können nur schlecht kmmuniziert werden, Missverständnisse treten auf, verschiedene Werkzeuge sind ntwendig und s frt. Im Jahr 2001 hat INCOSE sich zum Ziel gesetzt, die UML zu einer Standardsprache des Systems Engineering zu machen. Die UML erfüllt im Wesentlichen die Anfrderungen, ist verbreitet, an spezifische Bedürfnisse anpassbar, und es gibt eine Vielzahl an Mdellierungswerkzeugen, Literatur swie Beratungs- und Seminaranbietern. Aufgrund des in der UML integrierten Erweiterungsmechanismus (Steretypen) können neue Mdellierungsvkabeln definiert und smit die UML an bestimmte Dmänen und Disziplinen angepasst werden. Mit der Versin UML ist die Bandbreite der Einsatzmöglichkeiten gegenüber der UML1 nch größer gewrden (siehe z. B. [61]). Die Anpassung der UML für das Systems Engineering hat den Namen OMG Systems Mdeling Language (OMG SysML TM ) und basiert in der aktuellen Versin 1.4 auf der UML 2.5. Die wichtigsten Erweiterungen der SysML gegenüber der UML sind: OMG ) S. 201 Standard gesucht UML für Systems Engineering OMG SysML TM ) S. 309 Die Klassen der UML werden in SysML Systembausteine genannt, das Klassendiagramm Blckdefinitinsdiagramm. Das UML-Kmpsitinsstrukturdiagramm heißt in SysML internes Blckdiagramm. Für beide Diagrammfrmen sind etliche Erweiterungen definiert. Objektflüsse im internen Blckdiagramm Unterstützung der Enhanced Functinal Flw Blck Diagrams (EFFBD) und kntinuierlicher Funktinen durch Aktins- und Objektknten im Aktivitätsdiagramm. Zwei neue Diagrammarten: Anfrderungsdiagramm, Zusicherungsdiagramm Unterstützung des Datenfrmats ISO AP-233, um Datenaustausch zwischen verschiedenen Werkzeugen zu ermöglichen. 10 Ich verwende im Buch die Bezeichnung UML1 bzw. UML2 für die Versinen 1.x bzw. 2.x der UML. Wenn ich eine spezielle Versin anspreche, gebe ich sie vllständig an, beispielsweise UML 2.0. Wenn ich nur UML schreibe, meine ich die aktuellste Versin.

24 24 1Einleitung Explizites Herausstreichen vn UML-Elementen, die im Systems Engineering nicht benötigt werden, z. B. die sftwarelastigen Kmpnenten Warum nch eine»ml«? OMG SysML TM 1.0 OMG SysML 1.5 SysML/UML im Buch Berechtigt ist die Frage, b diese Erweiterungen überhaupt ntwendig gewesen sind, der anders gefragt:»warum nch eine Mdellierungssprache? Hätte man nicht einfach die UML verwenden können?«die UML ist zwar sehr mächtig, weist aber hinsichtlich des Systems Engineering entscheidende Defizite wie die fehlende Anfrderungsmdellierung auf. Ein weiterer Grund, der die Ntwendigkeit vn SysML begründet, ist die Tatsache, dass UML zum Teil sftwarelastig und stark vn der Objektrientierung geprägt ist, im Systems Engineering aber disziplinenneutral mdelliert wird. Die Verwendung der UML kann leicht zu Akzeptanzprblemen und Missverständnissen in der Prjektkmmunikatin führen. Die SysML ist im April 2006 in der Versin 1.0 vn der OMG als Standard angenmmen wrden. Etliche Hersteller unterstützen die Sprache. Hierzu gehören AR- TiSAN Sftware Tls, IBM, NMagic und Sparx Systems. TOPCASED 11 ist ein Beispiel für ein Open-Surce- Mdellierungswerkzeug. Eine aktuelle Übersicht über SysML- Mdellierungswerkzeuge finden Sie auf der Hmepage des Buchs unter Ein Jahr lang hat die Finalizatin Task Frce (FTF) am Feinschliff der Versin 1.0 gearbeitet. Im April 2007 ist OMG SysML TM 1.0 als ffizieller Standard der OMG verabschiedet und im September 2007 veröffentlicht wrden. Seitdem sind etliche Verbesserungen an der Sprache vrgenmmen wrden. Aktuell wird an der Versin 1.5 gearbeitet. Die Erhöhung der zweiten Versinsnummer zeigt, dass nur Fehler behben und kleinere Änderungen vrgenmmen werden. In der Versin 1.3 ist das Prtknzept der SysML auf Basis vn Erfahrungen aus dem praktischen Einsatz der SysML überarbeitet wrden. Die Versin 1.4 führt unter anderem ein überarbeitetes Knzept der Sicht ein, ermöglicht die Gruppierung vn beliebigen Elementen und bietet weitere Möglichkeiten für die Mdellierung vn Einheiten. Umfangreiche Änderungen der Sprache können erst mit der Versin 2.0 eingeführt werden, die derzeit nch nicht geplant ist. Das in Kapitel 2 beschriebene Vrgehen wendet die SysML an. Die Kapitel 3 und 4 beschreiben die Sprachen UML und SysML 11

25 1.3 Mdellbasiertes Systems Engineering (MBSE) 25 getrennt vneinander. Smit erfahren Sie, welche Elemente aus der UML stammen und welche Erweiterungen SysML einführt. In Summe beschreiben die Kapitel 3 und 4 den vllständigen Sprachumfang der SysML. Vn der UML stelle ich nur die SysMLrelevanten Teile vr. Das Kapitel 5 führt weitere Elemente in Frm eines Prfils (SYSMOD) ein, die im Rahmen des Vrgehens in diesem Buch verwendet werden. Das Kapitel 6 stellt das Zertifizierungsprgramm OMG Certified Systems Mdeling Prfessinal (OCSMP) vr und unterstützt bei der Vrbereitung zur Zertifizierungsprüfung. Prfil ) S BPMN Neben den Abläufen innerhalb eines (technischen) Systems sind auch die Przesse im Umfeld des Systems wichtig. Welche Arbeitsabläufe sind in der Entwicklung, in der Prduktin, im Betrieb und in der Entsrgung vn dem System ntwendig? In welche Abläufe bettet sich das System ein? Die Mdellierung dieser Abläufe ist das Feld der Geschäftsprzessmdellierung, einer Unterdisziplin des Geschäftsprzessmanagements (GPM) [78] 12. Statt technischer Systeme werden hier geschäftliche Systeme als Organisatinen mdelliert, entwickelt und ptimiert. Zwischen den beiden Disziplinen gibt es nicht nur Berührungspunkte, sndern auch viele Parallelen. Die Werkzeuge und Vrgehensweisen der Mdellierung sind sich auf abstrakter Ebene in vielen Bereichen ähnlich [61]. Die Mdellierungssprache der Geschäftsprzessmdellierung ist die Business Prcess Mdel and Ntatin (BPMN). Sie stellt einen standardisierten Satz grafischer Elemente bereit, um geschäftliche Abläufe zu mdellieren. Das ermöglicht einen besseren Austausch zwischen Menschen. Gleichzeitig ist BPMN nicht nur eine Ntatin, sndern auch ein frmales Mdell, sdass die Przesse auch ausgeführt werden können. Die BPMN ist wie die UML und SysML eine Mdellierungssprache der OMG. Etliche Mdellierungswerkzeuge zu SysML bieten auch die BPMN-Mdellierung an. Dadurch können Infrmatinen aus einem SysML- und einem BPMN-Mdell leicht miteinander verknüpft werden. Geschäftliche Abläufe Geschäftsprzessmdellierung SysML 12 engl. Business Prcess Management. (BPM) [79]

26 26 1Einleitung MATLAB/Simulink MATLAB TM (Matrix Labratry) ist eine prprietäre Entwicklungsumgebung und Prgrammiersprache zur Visualisierung, Berechnung und Prgrammierung mathematischer Ausdrücke. Die Anwendung wird vn der Firma The MathWrks entwickelt. Simulink TM ist eine Erweiterung vn MATLAB zur Mdellierung, Simulatin und Analyse dynamischer Systeme. Hierfür werden Blckschaltbilder verwendet. Stateflw ist eine Erweiterung, die die Mdellierung und Simulatin endlicher Zustandsautmaten ermöglicht. MATLAB/Simulink ist ein weitverbreitetes Werkzeug. Trtz seiner Fähigkeiten hat es den Nachteil, dass es ein prprietäres System ist und kein Standard wie beispielsweise SysML. Ein SysML-Mdellierungswerkzeug steht nicht in direkter Knkurrenz zu MATLAB. Auch wenn es Überschneidungen gibt, beispielsweise im Bereich der Zustandsmdellierung, ergänzen sich beide Umgebungen. SysML ist mächtiger im Bereich der Anfrderungsmdellierung und der Systemarchitektur, während MAT- LAB/Simulink im Simulatinsbereich seine Stärken hat. Wenn Sie beide Umgebungen einsetzen, benötigen Sie eine Werkzeugkette, um die Durchgängigkeit Ihrer Mdelle nicht zu verlieren. Entwicklungsumgebung und Sprache Simulatin SysML Mdelica Physikalische Mdelle SysML Mdelica ist eine Sprache zur Beschreibung physikalischer Mdelle. Sie kann in verschiedenen Bereichen wie beispielsweise Mechanik, Regelungstechnik und Elektrtechnik eingesetzt werden. Es gibt grafische Entwicklungsumgebungen zu Mdelica, um Simulatinsmdelle zu erstellen. Ähnlich wie es in MAT- LAB/Simulink möglich ist. Die Sprache Mdelica ist frei verfügbar. Verantwrtlich für ihre Entwicklung ist die Mdelica Assciatin. Das Open Surce Mdelica Cnsrtium (OSMC) bietet unter eine freie Umgebung für Mdelica an. SysML und Mdelica können sich gut ergänzen. Die Stärken der SysML liegen in der Beschreibung kmplexer Systeme. Die Stärken vn Mdelica liegen in der Analyse diskreter und kntinuierlicher zeitlicher Aspekte in kmplexen Systemen. Die SysML-Mdelica Transfrmatin Specificatin [37] standardisiert die Abbildung zwischen SysML- und Mdelica- Mdellen. Damit ermöglicht sie die kllabrative Anwendung beider Mdelle in einer Umgebung. Eine Werkzeugkette zwischen SysML und Mdelica ist in [55] beschrieben.