Tag des Systems Engineering

1 - Inhaltsverzeichnis [Seite 6]
2 - Vorwort [Seite 8]
3 - Modellbasierte Systementwicklung 1 [Seite 12]
4 - Werkzeuge für den Schmied funktionaler Architekturen [Seite 14]
4.1 - 1 Einleitung [Seite 14]
4.2 - 2 Methode zur Erstellung funktionaler Architekturen [Seite 15]
4.3 - 3 Beispiel [Seite 16]
4.4 - 4 Automatische Erstellung funktionaler Architekturen [Seite 16]
4.5 - 5 Verknüpfung mit existierenden funktionalen Modellen [Seite 21]
4.6 - 6 Diskussion, Schlussfolgerungen und Ausblick [Seite 22]
4.7 - 7 Danksagung [Seite 23]
4.8 - Literaturverzeichnis [Seite 23]
5 - Qualitätssicherung für modellbasierte Entwicklungsansätze [Seite 24]
5.1 - 1 Modelle und Modellqualität [Seite 24]
5.2 - 2 Unternehmensmodelle - Inhalte, Zusammenhänge, Darstellungsmittel [Seite 25]
5.3 - 3 Qualität von Modellen [Seite 25]
5.3.1 - 3.1 Qualitätskriterien und Messgrößen [Seite 26]
5.3.2 - 3.2 The Decision Model - Ein Ansatz mit integrierten Qualitätskriterien [Seite 28]
5.4 - Literaturverzeichnis [Seite 28]
6 - Modellbasierte Systementwicklung 2 [Seite 30]
7 - Hierarchie von Entwurfsentscheidungen im modellbasiertenEntwurf komplexer Systeme [Seite 32]
7.1 - 1 Einleitung [Seite 32]
7.2 - 2 Entwurfssprachen im modellbasierten Entwurf [Seite 32]
7.3 - 3 Analyse von Entwurfsalternativen [Seite 35]
7.3.1 - 3.1 Auswahl von Bauteilen [Seite 36]
7.3.2 - 3.2 Auswahl von Subsystemen [Seite 37]
7.3.3 - 3.3 Generierung von Analysemodellen [Seite 39]
7.4 - 4 Zusammenfassung [Seite 41]
7.5 - Literaturverzeichnis [Seite 42]
8 - Modellbasierte Systementwicklung 3 [Seite 44]
9 - Modellbasierter Systementwurf mit dem PrEMISE-Modell [Seite 46]
9.1 - Abkürzungen [Seite 46]
9.2 - Einführung [Seite 47]
9.2.1 - Teambasierter Systementwurf [Seite 47]
9.2.2 - Modellbasierte Systementwicklung [Seite 48]
9.2.3 - PrEMISE [Seite 48]
9.2.4 - Gliederung [Seite 48]
9.3 - Verfügbare Normen [Seite 49]
9.3.1 - ISO 10303 (STEP) [Seite 49]
9.3.2 - ECSS Normen [Seite 49]
9.3.3 - SysML [Seite 49]
9.4 - Das PrEMISE-Modell [Seite 49]
9.4.1 - Systemkomponenten [Seite 49]
9.4.2 - Datenaustausch [Seite 50]
9.4.3 - Vergleich mit verfügbaren Normen [Seite 50]
9.5 - Implementierung [Seite 51]
9.6 - Anwendung [Seite 52]
9.6.1 - Raumfahrt [Seite 52]
9.6.2 - Luftfahrt [Seite 53]
9.6.3 - Automotive [Seite 53]
9.7 - Zusammenfassung und Ausblick [Seite 54]
9.8 - Literaturverzeichnis [Seite 55]
10 - Modellbasierte Konzipierung eines hybriden Energiespeichersystems für ein autonomes Schienenfahrzeug [Seite 56]
10.1 - 1 Einleitung [Seite 56]
10.2 - 2 Handlungsfeld: Frühzeitige Systemmodellierung [Seite 57]
10.2.1 - 2.1 Systems Modeling Language - SysML [Seite 58]
10.2.2 - 2.2 CONSENS [Seite 59]
10.3 - 3 Modellbasierte Konzipierung eines hybriden Energiespeichersystems(HES) mit CONSENS [Seite 61]
10.3.1 - 3.1 Anwendungsbeispiel: Hybrides Energiespeichersystem (HES) des RailCabs [Seite 61]
10.3.2 - 3.2 Modellbasierte Konzipierung des HES [Seite 62]
10.4 - 4 Zusammenfassung [Seite 64]
10.5 - Literaturverzeichnis [Seite 65]
11 - Vorgehensmethodik 1 [Seite 66]
12 - Nachhaltige Entscheidungsfindung im Systems Engineering [Seite 68]
12.1 - 1 Einführung [Seite 68]
12.2 - 2 Das Rubikonmodell der Handlungsphasen [Seite 69]
12.3 - 3 Das Gruppendynamische Modell nach Tuckman [Seite 70]
12.4 - 4 Entscheidungen im Systems Engineering [Seite 71]
12.5 - 5Nachhaltige Entscheidungsfindung [Seite 73]
12.6 - 6 Der Entscheidungsprozess im Systems Engineering [Seite 75]
12.7 - Literaturverzeichnis [Seite 77]
13 - Systemmodellierung im Fokus von Generic Systems Engineering [Seite 78]
13.1 - 1 Bewältigung der Komplexität mit System Engin [Seite 78]
13.2 - 2 SE hat seinen Ursprung im Systemdenken in Kopplung mit demingenieurmäßigen Handeln [Seite 79]
13.3 - 3 SE war vielfältigen Wandlungen unterworfen [Seite 80]
13.4 - 4 SE hat das Potential für ein generelles Denkmodell undVorgehenskonzept zur Problemlösung [Seite 81]
13.5 - 5 SE braucht als Basis ein transparentes Systemmodell [Seite 83]
13.6 - 6 Roboterdesign mit erweitertem GSE-Ansatz [Seite 84]
13.7 - 7 Zusammenfassung und Ausblick [Seite 86]
13.8 - Literaturverzeichnis [Seite 87]
14 - Vorgehensmethodik 2 [Seite 88]
15 - Herausforderungen und Lösungen bei der Durchführung von asymmetrischen Prozessverbesserungsprojekten [Seite 90]
15.1 - 1 Einleitung [Seite 90]
15.1.1 - Warum Prozessverbesserung? [Seite 90]
15.1.2 - Welche Voraussetzungen sollten für erfolgreiche Prozessverbesserungsprojekteerfüllt sein? [Seite 91]
15.1.3 - Welche Prozessreifegradmodelle werden genutzt und wo liegen derenAnsatzschwerpunkte? [Seite 92]
15.1.4 - Was versteht man unter Prozessreifegraden? [Seite 92]
15.2 - 2 Zwei Praxisbeispiele für Prozessverbesserungsprojekte [Seite 93]
15.2.1 - Elektrik/Elektronik-Entwicklung eins Nutzfahrzeug OEMs [Seite 93]
15.2.2 - Software-Entwicklung eines Sonderfahrzeugbauers [Seite 94]
15.3 - 3 Herausforderungen und gelebte Lösungen [Seite 95]
15.3.1 - Fehlbesetzung einer Rolle [Seite 95]
15.3.2 - Fehlendes Commitment bei den Mitarbeitern [Seite 96]
15.3.3 - Auswahl der von der Prozessverbesserung erfassten Bereiche [Seite 97]
15.3.4 - Keine Bereitstellung der Ressource Zeit durch die Stakeholder der einzelnenProzesse [Seite 98]
15.4 - Fazit [Seite 99]
15.5 - Literaturverzeichnis [Seite 99]
16 - Contract Based Design: A Means to Assure Interoperability in Complex Distributed Systems [Seite 100]
16.1 - 1 Introduction [Seite 100]
16.1.1 - 1.1 The Risks of "Complex" Design [Seite 101]
16.1.2 - 1.2 Hidden Links [Seite 101]
16.1.3 - 1.3 State-of-the-Art Save System Engineering Methods [Seite 101]
16.1.4 - 1.4 Save Systems Architectures [Seite 102]
16.1.5 - 1.5 Complex Systems Design Issues [Seite 103]
16.2 - 2 Contract Based Design [Seite 104]
16.3 - 3 Ariane 5 Failure [Seite 106]
16.3.1 - 3.1 Contracts for the Inertial Reference System [Seite 107]
16.3.2 - 3.2 Contracts at a TechnicalPerspective [Seite 110]
16.4 - 4 Conclusions [Seite 110]
16.5 - References [Seite 111]
17 - Modell des Einsatzsystems der Fregatte F125 [Seite 112]
17.1 - 1 Kontext der Aufgabe [Seite 112]
17.1.1 - 1.1 Fregatte F125 [Seite 112]
17.1.2 - 1.2 Einsatzsystem der Fregatte F125 [Seite 113]
17.2 - 2 Aufgabenstellung [Seite 113]
17.2.1 - 2.1 Methodische Vorgaben der ES-Entwicklung [Seite 113]
17.2.2 - 2.2 Aufgabenbeschreibung [Seite 114]
17.3 - 3 Realisierung des ES-Modells [Seite 114]
17.3.1 - 3.1 Ausgangsbasis [Seite 114]
17.3.2 - 3.2 Struktur des Modells [Seite 115]
17.3.3 - 3.3 Ergebnis [Seite 116]
17.3.4 - 3.4 Werkzeuge [Seite 116]
17.4 - 4 Ergebnisbewertung und Ausblick [Seite 116]
18 - Requirements Engineering [Seite 118]
19 - Requirements: ReqIF, Formal description with DSLs and a traceability approach for Eclipse [Seite 120]
19.1 - 1 Introduction [Seite 120]
19.1.1 - 1.1 The research project VERDE [Seite 120]
19.1.2 - 1.2 Structure of this paper [Seite 121]
19.2 - 2 The Requirements Interchange Format "ReqIF" [Seite 122]
19.3 - 3 Requirements Modeling Framework (RMF) [Seite 122]
19.3.1 - 3.1 Eclipse as a platform [Seite 122]
19.3.2 - 3.2 Scope [Seite 123]
19.3.3 - 3.3 Structure [Seite 123]
19.4 - 4 Domain-specific languages and requirements [Seite 124]
19.4.1 - 4.1 Domain-Specific Languages [Seite 125]
19.4.2 - 4.2 Integrated Tooling [Seite 126]
19.4.3 - 4.3 Traceability [Seite 127]
19.5 - 5 Conclusion and Future Plans [Seite 128]
19.6 - References [Seite 129]
20 - Verbesserung der Qualität von Anforderung und Test bei komplexen Systemen durch Reverse Engineering [Seite 130]
20.1 - 1 Problembeschreibung [Seite 130]
20.2 - 2 Stand der Technik [Seite 131]
20.3 - 3 Industrielle Anwendung [Seite 132]
20.4 - 4 Lösungsvorschlag [Seite 133]
20.5 - 5 Evaluierung im industriellen Kontext [Seite 135]
20.6 - 6 Fazit und Ausblick [Seite 138]
20.7 - Literaturverzeichnis [Seite 138]
21 - MBSE und RBE:Ergänzung und kein Widerspruch [Seite 140]
21.1 - 1 "Model-Based-SE" heute noch nicht vollständig umgesetzt [Seite 140]
21.2 - 2 Abgrenzung [Seite 141]
21.2.1 - a) Funktionale Analyse und Architektur [Seite 141]
21.2.2 - b) Physikalische Architektur [Seite 141]
21.2.3 - c) Schnittstellen Architektur [Seite 142]
21.3 - 3 Nachverfolgbarkeit (Tracebility) [Seite 142]
21.3.1 - 3.1 Verwendete Modellierungsmetho [Seite 142]
21.3.2 - 3.2 Verbindung von Modellelemente zu Anforderungen [Seite 143]
21.3.3 - 3.3 Verlinkung von Anforderungen über die Hierarchieebenen [Seite 144]
21.4 - 4 Ableitung von Testfällen [Seite 145]
21.5 - 5 Berücksichtigung von Safety Aspekten [Seite 145]
21.6 - 6 Dokumentationserzeugung [Seite 147]
21.7 - 7 Anforderungen an die Toolumgebung [Seite 148]
21.8 - 8 Ausblick [Seite 149]
21.9 - Literaturverzeichnis [Seite 149]
22 - Agile Systementwicklung 1 [Seite 150]
23 - Entscheidungsstrategien zur Festlegung und Priorisierung von Änderungen [Seite 152]
23.1 - 1 Entscheidungen in der modernen Produktentwicklung [Seite 152]
23.2 - 2 Lösungsansätze zum Umgang mit Entscheidungen [Seite 153]
23.2.1 - 2.1 Entscheidungen beim Umgang mit Änderungen [Seite 153]
23.2.2 - 2.2 Entscheidungsgremien [Seite 153]
23.2.3 - 2.3 Agile Methoden [Seite 154]
23.2.4 - 2.4 Entscheidungsstrategien [Seite 154]
23.2.5 - 2.5 Forschungsfragen und Zielstellung [Seite 154]
23.3 - 3 Untersuchung von Entscheidungsstrategien mittels Simulation [Seite 155]
23.3.1 - 3.1 Anforderungen an das Simulationsmodell [Seite 155]
23.3.2 - 3.2 Beschreibung der Änderungssituation [Seite 156]
23.3.3 - 3.3 Simulation der Entscheidungsstrategien [Seite 156]
23.3.4 - 3.4 Parameter der Simulation und ihre Variation [Seite 157]
23.3.5 - 3.5 Auswertung der Simulationsergebnisse [Seite 157]
23.4 - 4 Ergebnisse der Simulationen [Seite 158]
23.5 - 5 Diskussion und Ausblick [Seite 160]
23.6 - Danksagung [Seite 161]
23.7 - Literaturverzeichnis [Seite 161]
24 - Agile vs. Waterfall: What is the Best for your Development Project? [Seite 162]
24.1 - 1 Introduction [Seite 162]
24.2 - 2 Waterfall [Seite 163]
24.3 - 3 Agile [Seite 164]
24.4 - 4 Comparison [Seite 165]
24.5 - 5 Questionnaire [Seite 167]
24.6 - 7 Conclusions [Seite 169]
24.7 - References [Seite 169]
25 - Agile Systementwicklung 2 [Seite 170]
26 - Agiles Projektmanagement für Systeme im regulatorischen Umfeld [Seite 172]
26.1 - 1 Einleitung [Seite 172]
26.2 - 2 Motivation [Seite 173]
26.3 - 3 Das Umfeld [Seite 173]
26.4 - 4 Die Herausforderungen [Seite 175]
26.5 - 5 Hart, aber agil - Agilität trotz starrer Rahmenbedingungen [Seite 176]
26.5.1 - 5.1 Das Problem mit den Iterationen [Seite 176]
26.5.2 - 5.2 Das Iterationsergebnis [Seite 176]
26.5.3 - 5.3 "Agile Projekte dokumentieren nicht!" [Seite 177]
26.6 - 6 Regulatorische Anforderungen an eine normgerechteProduktentwicklung [Seite 177]
26.7 - 7 Iteratives agiles Prototyping von Systemen [Seite 180]
26.7.1 - 7.1 Kombination von Software- und Hardware-Entwicklung als Herausforderung [Seite 180]
26.7.2 - 7.2 Erkennen und minimieren der Projektrisiken als Treiber für agiles Vorgehen [Seite 180]
26.7.3 - 7.3 Regelmäßiges und zeitnahes Feedback durch zyklische Pre-Integrationsphasen [Seite 181]
26.7.4 - 7.4 Feedback zum Vorgehen von den Projektbeteiligten [Seite 182]
26.8 - 8 Fazit und Ausblick [Seite 182]
26.9 - Literaturverzeichnis [Seite 183]
27 - Expeditionsmitglieder gesucht! Agile Wege in hierarchischen Unternehmen [Seite 184]
27.1 - 1 Einführung: Selbstorganisation und agilePrinzipien [Seite 184]
27.1.1 - 1.1 Anwendungsbereich und Grundprinzipien agiler Arbeitsformen [Seite 185]
27.2 - 2 Hindernisse in hierarchischen Unternehmen [Seite 188]
27.3 - 3 Lösungsansätze: Expeditionen mit Hilfe der System-Landkarte [Seite 189]
27.3.1 - 3.1 Persönliche Kompetenz [Seite 190]
27.3.2 - 3.2 Inhaltlicher Kontext [Seite 191]
27.3.3 - 3.3 Sozialer Kontext [Seite 191]
27.3.4 - 3.4 Organisatorischer Kontext [Seite 192]
27.4 - Literaturverzeichnis [Seite 193]