Wirtschaftlichkeit der modellbasierten Entwicklung

Transkript

1 Workshop Hot-Spots der Software-Entwicklung Wirtschaftlichkeit der modellbasierten Entwicklung 14. Dezember 2010 Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy BICC-NET Bavarian Information and Communication Technology Cluster Florian Deißenböck Martin Fritzsche Daniel Méndez Fernández

2 Inhaltsverzeichnis 1 Einleitung 3 2 Teilnehmerliste 4 3 Programm 5 4 Bewertung wirtschaftlicher Potentiale modellbasierter Entwicklung Manfred Broy 6 5 Kosten und Nutzen der modellbasierten Entwicklung eingebetteter Softwaresysteme im Automobil Ergebnisse einer globalen Studie Sascha Kirstan 10 6 Unter welchen Bedingungen modellbasierte Software-Entwicklung Vorteile bringt ein Bericht aus 11 Jahren Erfahrung Stefan Teuchert 27 7 Nutzenpotentiale in der Anwendung einer modellbasierten Architekturentwicklung Martin Wechs 43 8 Modellbasierte Entwicklung eingebetteter Software Vom Stand der Technik zu neuen Möglichkeiten Bernhard Schätz 52 2

3 1 Einleitung Neben klassischer, manueller Softwareentwicklung wird in Unternehmen zunehmend verstšrkt modellbasierte Entwicklung eingesetzt. Diese gilt als einer der HoffnungstrŠger zur Beherrschung von Kosten und KomplexitŠt in der Entwicklung softwareintensiver Systeme. Diese Hoffnungen werden durch Erfolgsgeschichten von Werkzeugherstellern gestÿtzt, die von Kosteneinsparungen in der Entwicklung und von Verbesserungen in der QualitŠt der erstellten Software berichten. Ziel des Workshops ãwirtschaftlichkeit der modellbasierten EntwicklungÒ ist es, zum besseren grundsštzlichen VerstŠndnis des Themas modellbasierter Entwicklung beizutragen. Dabei wird der Einsatz der modellbasierten Entwicklung motiviert und u.a. die aktuelle Praxis auf Basis einer globalen Studie sowie Erfahrungsberichten dargestellt. Es sollen im Workshop Best Practices offen ausgetauscht und das Potenzial modellbasierter Entwicklung diskutiert werden. Themen des Workshops sind daher unter anderem: Motivation des Einsatzes und Einsatzgebiete der modellbasierten Entwicklung Positive und negative Erfahrungen von Unternehmen bei der Verwendung modellbasierter Entwicklung Auswirkungen des Einsatzes modellbasierter Entwicklung auf Wirtschaftlichkeit und Qualität 3

4 2 Teilnehmerliste Wolfgang Bäcker, Siemens Erwin Beck, Siemens Klaus Beetz, Siemens Andreas Bogner, BMW Group Markus Breitenberger, Autoliv Dr. Michael Breu, Arctis Prof. Dr. Dr. h.c. Manfred Broy, Technische Universität München Dr. Florian Deißenböck, Technische Universität München Karlheinz Dörner, MAN Roland Eckert, EADS Dr. Herbert Ehler, Technische Universität München Alexander Eichinger, Infineon Josef Ernst, Siemens Martin Fritzsche, Technische Universität München Steffen Fuhrmann, BMW Group Rudolf Hauber, Hood Tobias Hauzeneder, Dynalogic Siegfried Hörfarter, Berner & Mattner Wolfgang Jekeli, BMW Group Gabriele Käsberger-Hoschek, EADS Olaf Kaudelka, EADS Sascha Kirstan, Altran Technologies Sascha Kovacevic, Audi Albert Kreitmeyr, Audi Dr. Andreas Lapp, Bosch Sevil Lillyan, Trivadis Hans-Dieter Maier, Hood Daniel Méndez Fernández, Technische Universität München Christian Otto, Berner & Mattner Markus Prison, Altran Technologies Marco Prucha, msg systems ag Johannes Reitzner, msg systems ag Klaus Sattler, Siemens Dr. Bernhard Schätz, fortiss Florian Schinagl, Art of Quality Ulrich Scholtze, coopt Martin Schönung, Ingenieurbüro für Mechatronik Joachim Terasa, coming Stefan Teuchert, MAN Dr. Stephan Thesing, Eurocopter Hans-Jürgen Thönnißen, ESG GmbH Peter Untermann, Art of Quality Hermann Wacker, Cassidian Dr. Martin Wechs, BMW Group Josef Wernke, Eurocopter Dr. Klaus Peter Wershofen, Siemens Markus Zormaier, ESG GmbH 4

5 3 Programm 13:40 Bewertung wirtschaftlicher Potentiale modellbasierter Entwicklung Manfred Broy, Technische Universität München 14:05 Kosten und Nutzen der modellbasierten Entwicklung eingebetteter Softwaresysteme im Automobil Ergebnisse einer globalen Studie Sascha Kirstan, Altran technologies 15:10 Kaffee-Pause 15:30 Unter welchen Bedingungen modellbasierte Software-Entwicklung Vorteile bringt ein Bericht aus 11 Jahren Erfahrung Stefan Teuchert, MAN Nutzfahrzeuge 16:15 Nutzenpotentiale in der Anwendung einer modellbasierten Architekturentwicklung Martin Wechs, BMW Group 17:00 Kaffee-Pause 17:15 Modellbasierte Entwicklung eingebetteter Software Vom Stand der Technik zu neuen Möglichkeiten Bernhard Schätz, fortiss 18:00 Abschlussdiskussion 18:30 Empfang 5

6 4 Bewertung wirtschaftlicher Potentiale modellbasierter Entwicklung Manfred Broy Modellbasierte Entwicklung Wirtschaftliche Bewertung Manfred Broy Software & Systems Engineering Technische Universität München Institut für Informatik Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering 6

7 Herausforderungen Entwicklung ES Anforderungen Architektur Automatisierung & Werkzeugunterstützung Codegenerierung Testautomatisierung Komplexitätsbeherrschung Arbeitsteilige Entwicklung Qualitätssicherung Kosten Wiederverwendung Produktlinien Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Hoffnungsträger MBSE Modellbasiertes Software & Systems Engineering Höhere Systematik und Vereinheitlichung Angemessene Abstraktion Bessere Modularisierung Stärkere Automatisierung Analyse Generierung Höhere Qualität Gezielteres Lieferantenmanagement Einfachere Wiederverwendung Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering 7

8 MBSE Modellbas. Software & Systems Eng. Modellierung wesentlicher Systemaspekte Daten Schnittstellen(verhalten) Zustand Architektur nichtfunktionale Eigenschaften Sichten Funktionssicht Logische Komponentenarchitektursicht Technische Sicht Qualitätssicht Beziehungen zwischen Artefakten Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Wesentliche Gesichtspunkte MBSE Durchgängigkeit Erzeugung von Teilmodellen aus gegebenen Modellen Nutzung der Modelle über gesamten Lebenszyklus Werkzeugunterstützung Artefaktemodell Automatisierung: Analyse und Generierung Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering 8

9 Bewertung - Kosten/Nutzen Kosten und Aufwände Schulung Mitarbeiter Aufbau Werkzeugketten Overhead durch Modellierung Vorteile Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Schlüsselthemen für hohen Nutzen Entwicklung mit hoher Systematik erforderlich Basis durchgängige Modellierung Frontloading frühe Fehlerreduktion Kostenreduzierung Automatisierung Wiederverwendung Geeignete Abstraktionen Trennung logische und technische Sichten Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering 9

10 5 Kosten und Nutzen der modellbasierten Entwicklung eingebetteter Softwaresysteme im Automobil Ergebnisse einer globalen Studie Sascha Kirstan Studie Kosten und Nutzen der modellbasierten Entwicklung eingebetteter Softwaresysteme im Automobil" Präsentation der wesentlichen Studienergebnisse für den Hotspot modellbasierte Softwareentwicklung TU München 14 Dezember 2010 Sascha Kirstan Altran Technologies Bernhard Wicki - Str München Public void Int i=0; While (i!=0)

11 Kurze Vorstellung Vorstellung Sascha Kirstan Überblick: Studium der Informatik mit Nebenfach BWL an der TU München Praktikant und Diplomand bei Arthur D. Little Aktuell: Externer Doktorand am Lehrstuhl von Prof. Dr. Dr. Manfred Broy (TU München) für Altran Technologies Erfahrungen mit der modellbasierten SW-Entwicklung: Erstellung einer Diplomarbeit mit dem Thema Wirtschaftlichkeit der MBSE in der Automobilindustrie Entwicklung einer Fensterhebersteuerung mittels Matlab/ Simulink/Stateflow bei einem deutschen Automobilhersteller 2 Beitrag der Studie Die Studie beschreibt die Auswirkungen der modellbasierten Entwicklung auf Kosten, Zeit und Qualität und gibt Handlungsempfehlungen für Automobilhersteller (OEMs) und Zulieferer. 1 Gründe für und Erfahrungen mit MBSE n Einsatzkriterien n Klassisch entwickelte Funktionen n Meinungsbild zu Problemen mit MBSE n Positive Erfahrung n Negative Erfahrung n Erfüllte Erwartungen der Studienteilnehmer Beschreibung des Verbreitungsgrades der MBSE und Quantifizierung der Effekte n Anforderungsanalyse n SW-Architektur n SW-Design n Implementierung n Testen n Gesamtsicht über alle Entwicklungsphasen Identifikation von Potentialen in der MBSE n Modellbasierte Anforderungsmodellierung n Modellbasierte Architekturentwicklung n AUTOSAR n Modellbasiertes Testen Entwurf von Handlungsempfehlungen n Entwicklungsaktivitäten n Know How Aufbau Welche Gründe sprechen für MBSE? Wie wirkt sich MBSE entlang des Entwicklungsprozesses auf die Wirtschaftlichkeit aus? Welche Potentiale gibt es im Bereich MBSE? Was ist zu tun? 3 11

12 Herkunftsländer der Studienteilnehmer Bei den Teilnehmer der Studie handelt es sich um international anerkannte Experten. Herkunftsländer der Studienteilnehmer Deutschland Frankreich Finnland England Österreich Kanada USA Dänemark Italien Schweden Liechtenstein Japan Indien Brasilien Verantwortlichkeitsbereiche: n Führungskräfte: Geschäftsführer, Leiter Elektrik/Elektronik, Abteilungsleiter und Teamleiter n Experten aus der Serienentwicklung n Experten aus den Forschungsabteilungen der Unternehmen 4 Einordnung der Studie in ein Gesamtbild Die durchgeführte Studie ist Teil einer ausführlichen Betrachtung der Wirtschaftlichkeit der modellbasierten SW-Entwicklung (MBSE) im Rahmen einer Dissertation am Lehrstuhl Software & Systems Engineering der Technischen Universität München. 1 Aufstellen einer Theorie Identifikation von Unterschieden im Entwicklungsprozess zwischen klassischer und modellbasierter SW- Entwicklung Auswirkungen dieser Unterschiede auf die Wirtschaftlichkeit analysieren 2 Durchführung von Fallstudien Erstellen von Leitfadenfragebögen und vorbereiten der Datenauswertung Durchführung von Expertengesprächen Auswerten der Ergebnisse Gewählte Vorgehensweise 3 Kostenmodellerstellung Erstellung eines analytischen Kostenmodells Erstellung eines qualitativen Kostenmodells Durchführung von Validierungsgesprächen 5 Überprüfung der Aussagekraft des Kostenmodells mit Studiendaten Füllen des analytischen Kostenmodells mit Studiendaten Überprüfung der Aussagen des Kostenmodells mit realen Projektdaten 4 Studiendurchführung Durchführung einer globalen Studie, in der Automobilhersteller, Zulieferer und Engineeringfirmen befragt werden Durchführung von Expertengesprächen bzgl. des qualitativen Kostenmodells 5 12

13 Threads to Validity Folgende Faktoren beeinflussen die Ergebnisse der Studie Einflussfaktoren auf die Aussagekraft der Studienergebnisse 1 Angabe der Teilnehmer sind nur Schätzungen 2 Anzahl beantworteter Fragebögen 3 4 Automobilhersteller und Zulieferer denken in Stückkosten: Wert der Software oftmals unbekannt Arbeitsteiligkeit zwischen OEM und Zulieferer sorgt dafür, dass Teilnehmer nicht immer den gesamten Fragebogen beantworten konnten 5 Ergebnisse sind eventuell durch den gewählten Entwurf des Fragebogens beeinflusst 6 Inhalt 1 Ergebnisse globale Studie - Aktuelle Situation 2 Ergebnisse globale Studie - Aussagen entlang des Entwicklungsprozesses 3 Ergebnisse globale Studie - Handlungsempfehlungen 13

14 Einsatzkriterien Die Beweggründe für den Einsatz der modellbasierten SW-Entwicklung sind vielfältig. Die Entwicklung von Funktionen mit hoher Komplexität, die Verbesserung der Produktqualität und kürzere Entwicklungszeiten sind die drei wesentlichen Einsatzkriterien der MBSE. Einsatzkriterien für eine modellbasierte Softwareentwicklung* 1 Neue Funktion mit hoher Komplexität wird entwickelt Kein entscheidender Grund 1,5% Starker Grund 28,8% Sehr starker Grund 69,7% 2 Erhöhung der Produktqualität 1,6% 28,1% 70,3% 3 Kürzere Entwicklungszeit und damit früherer Time-to-Market-Zeitpunkt 4,9% 31,1% 63,9% 4 Die Wiederverwendung der Funktion in andere Baureihen ist geplant 6,5% 30,6% 62,9% 5 Kosteneinsparungen in der Softwareentwicklung 6,1% 43,9% 50% 6 Wettbewerbsdifferenzierende Funktion mit hohem Innovationspotential 9,8% 45,9% 44,3% 7 Trend bzw. Hype in der Branche hin zur modellbasierten SW-Entwicklung 17,2% 50% 32,8% 8 Entwicklung von sicherheitskritischen Funktionen 27,6% 50% 22,4% 9 Geschwindigkeitsoptimierte Funktionen 50,9% 41,5% 7,5% 10 Entwicklung von Funktionen mit hohen Laufzeit- und Speicheranforderungen 53,8% 41,5% 7,5% *Sortiert nach starkem und sehr starkem Grund 8 Einsatzzeitraum nach Phasen und Zeitabschnitten sortiert Fokus der modellbasierten Entwicklungsaktivitäten liegt aktuell in der Funktionsmodellierung und der Codegenerierung. Einsatzzeitraum SW-Design (Funktionsmodellierung) Implementierung (Codegenerierung) 50% 40% 30% 20% 10% 0% 3% 1,5% 28,4% 44,8% 22,4% 50% 40% 30% 20% 10% 0% 4,5% 4,5% 31,3% 41,8% 17,9% Testen 50% 40% 30% 20% 10% 0% 46,3% 22,4% 13,4% 13,4% 4,5% Legende: Nicht geplant Geplant < 1 Jahr 1-4 Jahre 5-10 Jahre > 10 Jahre 9 14

15 Meinungsbild zu Problemen mit der modellbasierten SW-Entwicklung Hohe Einführungskosten und eine zunehmende Abhängigkeit von Werkzeugherstellern sind die größten Herausforderungen bei einer modellbasierten Entwicklung. Meinung bzgl. modellbasierter Entwicklung untergliedert Hohe Einführungskosten Lange Lernzeiten Fehlende Durchgängigkeit im Prozess Effizienzgewinn durch die gesamte modellbasierte SW-Entwicklung ist zu gering 0 0,5 1 1,5 2 2,5 3 Verlagerung von Know-How Werkzeuge sind noch nicht ausgereift Werkzeugunterstützung zu gering Erforderliche Modelle nicht vorhanden Abhängigkeit vom Werkzeughersteller 0 = kein Hindernis 1 = geringes Hindernis 2 = mittleres Hindernis 3 = großes Hindernis 10 Erfüllte Erwartung der Studienteilnehmer Die Erwartungen der Studienteilnehmer bezüglich der modellbasierten SW- Entwicklung sind deutlich erfüllt. 30% 25% 20% 15% 10% 5% 0% Erfüllte Erwartungen Legende: 0 = nicht erfüllt 5 = erfüllt 10 = vollständig erfüllt Ø = 6, Erläuterung n Die Erwartungen der Studienteilnehmer sind erfüllt. Bei 68% der Befragten sind die Erwartungen sogar übererfüllt. n Die Studienteilnehmer weisen jedoch daraufhin, dass es noch ein deutliches Optimierungspotential gibt, welches genutzt werden muss, um die modellbasierte Entwicklung noch effizienter einsetzen zu können. Positiv Negativ n Verständlichkeit und Kommunizierbarkeit n Simulationen n Automatisierung (z.b. Codegenerierung) n Extrem hohe Einführungskosten n Abhängigkeit vom Werkzeughersteller n Keine wirklich durchgängige Toolkette à Viele zusätzliche Skripte notwendig 11 15

16 Inhalt 2 Ergebnisse globale Studie - Aussagen entlang des Entwicklungsprozesses 2.1 SW-Design (Erstellung des Funktionsmodells) 2.2 Implementierung (Codegenerierung) 2.3 Gesamtsicht SW-Design - Modellierungsgrad Matlab/Simulink/Stateflow wird von der klaren Mehrheit der Studienteilnehmer zur Funktionsmodellierung eingesetzt und ist das quasi defacto Werkzeug in der Modellierung. Verwendete Modellierungswerkzeuge Modellierter Prozentanteil der Funktion 100% 90% 80% 92% 70% 60% 29% 50% 40% 30% 71% 20% 10% 1,5% 0% n Matlab/Simulink/Stateflow n Scade 4,5% 6% 6% n Statemate n UML-Rhapsody n Ascet n Andere n Modelliert n Nicht modelliert Folgerung: Es wird ein Großteil der gesamten Funktionalität modelliert. Firmen mit großer Erfahrung bzw. langen Einsatzzeiträumen in der modellbasierten Entwicklung modellieren bis zu 100% der gesamten Funktionalität

17 SW-Design Überblick Test auf Modellen Tests auf Modellen werden von der Mehrheit der Studienteilnehmer intensiv eingesetzt. Je intensiver Tests auf Modellen (RCPs, Modellreviews und MiL-Tests) durchgeführt werden, desto höher ist der Testabdeckungsgrad auf Modellebene. Rapid Control Prototyping Modellreviews 25% 20% Legende: 0 = Gar nicht 5 = teilweise 10 = intensiv 50% 40% 41,8% 15% 10% Ø = 5,3 30% 20% 26,9% 26,9% 5% 0% % 0% 4,5% Gar nicht >10 Modellsimulationen (MiL-Tests) Abdeckungsgrad der Testverfahren vs. Intensität der Tests 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Legende: 0 = Gar nicht 5 = teilweise 10 = intensiv ρ = 0,31 ρ = 0,68 100% 80% 83% 86% 84% Ø = 8 60% 68% 66% 40% 20% 0% 13% Modellreviews MiL-Tests n Geringe Intensität n Mittlere Intensität n Hohe Intensität 14 SW-Design Auswirkung der Testaktivitäten auf die Anzahl gefundener Fehler im Modultest Der Mehraufwand für MiL-Tests zeigt sich in einer geringeren Anzahl gefundener Fehler im Modultest. Auswirkungen von MiL-Tests auf die Anzahl gefundener Fehler im Modultest 20% 10% 0% -10% -20% -30% -40% -50% -60% -70% -80% -17% ρ = -0,28 Ø = -42% ± 25% -35% -35% Gar nicht Gering Teilweise -43% Intensiv Intensität MiL-Test n Durch die frühere Testmöglichkeit mittels MiL- Tests gegenüber einer klassischen Entwicklung werden weniger Fehler im Modultest gefunden, weil sie bereits auf Funktionsmodellebene behoben wurden. n Klarer Trend zu sehen, dass je intensiver MiL- Tests durchgeführt werden, desto weniger Fehler werden im Modultest gefunden. n Delta zwischen Teilnehmern, die es nicht verwenden und Teilnehmern, die es intensiv verwenden, ist absolut 26%. Sowohl bei den Modellreviews als auch bei der Durchführung von RCPs im SW-Design konnten keine Auswirkungen zwischen der Intensität und der Anzahl gefundener Fehler im Modultest gefunden werden. Grund dafür ist, dass die Studienteilnehmer selbst bei geringer Intensität von ähnlichen Veränderungen berichtet haben wie die Teilnehmer mit hoher Intensität

18 SW-Design Veränderungen von Kosten und Zeit Der Front-loading-Effekt ist in den betrachteten Kennzahlen zu sehen. Mit Anstieg des Modellierungsgrades steigen die Kosten und die benötigte Zeit. Veränderung der Kosten Veränderung der Zeit 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% -10% -20% Ø = 37% ± 48% ρ = 0,16 100% 90% 80% 70% Ø = 25% ± 35% ρ = 0,14 60% 50% 36,5% 40% 39,4% 30% 32% 33% 20% 23,3% 10% 15% 0% -10% -20% Modellierungsgrad -30% <30% 30%-60% >60% SWD <30% 30%-60% >60% Modellierungsgrad SWD Folgende Gründe sind für Datenschwankungen verantwortlich: - Intensität der Testaktivitäten im SW-Design - Gewisse Teilnehmer berichten sogar von Kostenersparnissen, weil sie früher Fehler finden und diesen Aspekt mit in die Kostenveränderung einrechnen 16 SW-Design Auswirkung Modellierungsgrad und Tests auf Funktionsmodellen auf die Gesamtsicht Ein hoher Modellierungsgrad und intensive Tests auf Funktionsmodellen wirken sich positiv auf die Gesamtkosten und die Produktqualität aus. 10% 0% -10% -20% -30% -40% -50% -60% Modellierungsgrad und Testintensität vs. Gesamtkosten 0% Ø = -24% ± 19% ρ = -0,36-15% -28,5% <30% 30%-60% >60% Intensität* 1,4 1,2 1 0,8 0,6 0,4 0,2 0 Modellierungsgrad und Testintensität vs. Produktqualität Ø = 0,8 ± 0,45 ρ = 0,31 Interpretation und zusätzliche Erkenntnisse 0,68 0,88 0 Intensität* <30% 30%-60% >60% n Je höher der Modellierungsgrad und die Testintensität auf Funktionsmodellen ist, desto stärker fallen die Gesamtkosten. Klarer Trend in den Durchschnittswerten zu sehen, der durch den Korrelationskoeffizienten unterstützt wird. n Je höher der Modellierungsgrad und die Testintensität auf Funktionsmodellen ist, desto höher sind die Verbesserungen in der Produktqualität. Klarer Trend in den Durchschnittswerten und im Korrelationskoeffizient zu sehen. * Durchschnittswert aus Modellierungsgrad und Testintensität 17 18

19 Inhalt 2 Ergebnisse globale Studie - Aussagen entlang des Entwicklungsprozesses 2.1 SW-Design (Erstellung des Funktionsmodells) 2.2 Implementierung (Codegenerierung) 2.3 Gesamtsicht Implementierung - Codegenerierung Die Implementierung zeichnet sich durch einen hohen Grad an Automatisierung aus. Bei den Angaben der Teilnehmer sind Schwankungen im generierten Code von 5% bis 100% zu sehen. Informationen zur Codegenerierung Prozentanteil der Funktionalität, die generiert wird σ = 0,26 73% σ = Standardabweichung Anteil übernommene Statik aus dem SW-Design σ = 0,2 92% Anteil übernommene Dynamik aus dem SW-Design σ = 0,21 89% 0% 20% 40% 60% 80% 100% 120% n Im Schnitt werden 73% der Funktionalität generiert. 40,3% der Teilnehmer berichten sogar von einem 90%-100% Anteil der Funktionalität, die generiert wird. n Einige Studienteilnehmer erzeugen einen geringen Anteil Code. Gründe dafür sind, dass sie einen geringen Modellierungsgrad im SW-Design oder fehlendes Know-How in der Generierung haben oder sie generierten mit bereits bestehendem Code kombinieren

20 Implementierung Verwendete Testverfahren Auf Codeebene finden trotz Codegenerierung intensive Tests mittels Codereviews und SiL-Tests statt. PiL-Tests haben eine deutlich geringere Bedeutung. Intensität des Einsatzes von Codereviews Intensität des Einsatzes von Simulationen auf Codeebene (SiL-Tests) 60% 50% 40% 30% 20% 10% 0% Legende: 0 = Gar nicht 5 = teilweise 10 = intensiv Ø = 6, % 60% 50% 40% 30% 20% 10% 0% Legende: 0 = Gar nicht 5 = teilweise 10 = intensiv Ø = Intensität des Einsatzes von Simulationen auf Prozessorebene (PiL-Tests) Codeabdeckungsgrad der Simulationen 50% 40% 30% 20% 10% 0% Legende: 0 = Gar nicht 5 = teilweise 10 = intensiv Ø = 4, % 72% 56% 0% 20% 40% 60% 80% n Codereviews n SiL-Tests n PiL-Tests 20 Implementierung Veränderung Kosten und Zeit Aufgrund der Automatisierung sind hohe Kosten- und Zeiteinsparungen zu sehen. Anhand der Durchschnittswerte leitet sich ein Trend ab, dass mit Anstieg des generierten Codes die benötigten Kosten und Zeit in der Implementierung sinken. Veränderung der Kosten in der Implementierung Veränderung der Zeit in der Implementierung 0% -10% -20% -30% -40% -50% -60% -70% -80% -90% 20% Ø = -45% ± 36% ρ = -0,27 ρ = -0,29 Ø = -46% ± 31% 10% 0% -10% -27% -20% -30% -26% -46% -40% -48% -50% -47% -50% -60% -70% -80% -90% Anteil generierter -100% 50% 51%-69% Code 50% 51%-69% Anteil generierter Code Interpretation und zusätzliche Erkenntnisse n Die Intensität der generierten Dokumentation hat keinen Einfluss auf die Kosten und die Zeit in der Implementierung. n Korrelation der Testaktivitäten mit den Entwicklungskosten hat keinen Einfluss ergeben. Dies ist der Fall, obwohl insbesondere Codereviews sehr zeit- und damit kostenintensiv sind

21 Inhalt 2 Ergebnisse globale Studie - Aussagen entlang des Entwicklungsprozesses 2.1 SW-Design (Erstellung des Funktionsmodells) 2.2 Implementierung (Codegenerierung) 2.3 Gesamtsicht Gesamtsicht Kosten- und Zeitveränderung Die Frontloadingeffekte der modellbasierten Entwicklung sind deutlich in den relativen Kostenveränderungen der einzelnen Entwicklungsphasen im Vergleich zu einer klassischen Entwicklung zu sehen. Relative Kosten- und Zeitveränderungen durch die modellbasierte Softwareentwicklung entlang der einzelnen Entwicklungsphasen und in Gesamtsicht K: + 23% Z: + 18% Anforderungsanalyse Testfälle Validierung Steuergerätetest Durchschnitt Gesamtkostenund Zeitveränderung 0% -5% K: + 10% Z: + 6% K: + 37% Z: + 25% SW- Architektur SW-Design Testfälle Verifikation Testfälle SW-SW Integrationstest SW-HW- Integrationstest K: - 9% Z: - 12% -10% -15% -20% -25% -30% -27% Legende: K = Kosten Z = Zeit Implementierung K: - 46% Z: - 45% -35% -40% -36% n Kosten n Zeit 23 21

22 Einfluss des Grades der Modellbasierung auf die Gesamtkosten Die Kosteneinsparungen steigen mit dem Grad der Modellbasierung an Grad der Modellbasierung vs. Gesamtkosten 0% -10% -20% -30% -40% -50% -24% Ø = -29% ± 17% ρ = -0,3-26% -30% -32% n Trend in den Kosten zu sehen, dass mit umfassender modellbasierter Entwicklung die Gesamtkosten sinken. Je höher die Anzahl Entwicklungsphasen ist, in denen modellbasiert entwickelt wird, desto höher sind die Gesamteinsparungen. n Gründe: Hohe Durchgängigkeit im Entwicklungsprozess erhöht Effizienz in der Entwicklung und hilft Fehler, beim Übergang von einer in die andere Entwicklungsphase zu vermeiden. n Zeigt sich auch in der Produktqualität: Teilnehmer mit einem hohem Grad in der Modellbasierung berichten von deutlich höheren Verbesserungen. -60% Anzahl Phasen Einsatz MBSE 24 Top Einflussfaktoren auf die Wirtschaftlichkeit Nach Durchführung der Auswertung konnten wir folgende acht Faktoren identifizieren, die die Wirtschaftlichkeit der modellbasierten Softwareentwicklung beeinflussen und sie nach ihrem Einfluss auf die Wirtschaftlichkeit bewerten. Einflussfaktoren auf die Wirtschaftlichkeit der modellbasierten Softwareentwicklung Hoch Hoher Modellierungsgrad der Funktionsmodelle und ein hoher Anteil generierter Code Intensive Testaktivitäten auf Funktionsmodellebene (MiL-Tests, Modellreviews und RCP) Hohes Know-How der Mitarbeiter sowohl im Bereich MBSE als auch im SW-Engineering Hohe Durchgängigkeit im Entwicklungsprozess Umfassender Einsatz der modellbasierten Softwareentwicklung Hoher Innovationsgrad der zu entwickelnden Funktion Sicherheitsrelevanz der zu entwickelnden Funktion (kritische Funktionen rentabler) Domäne der zu entwickelnden Funktion (Im Infotainmentbereich kaum eingesetzt) Ein hoher Modellierungsgrad der Funktionsmodelle und ein hoher Anteil generierter Code, intensive Testaktivitäten auf Funktionsmodellebene und das Know-How der Mitarbeiter sind die wesentlichen Einflussfaktoren auf die Wirtschaftlichkeit der modellbasierten SW-Entwicklung

23 Inhalt 1 Ergebnisse globale Studie - Aktuelle Situation 2 Ergebnisse globale Studie - Aussagen entlang des Entwicklungsprozesses 3 Ergebnisse globale Studie - Handlungsempfehlungen Überblick über eine Auswahl identifizierter Handlungsempfehlungen Aus den Studienergebnissen konnten u.a. folgende Handlungsempfehlungen abgeleitet werden. 1 MBSE umfassend d.h. über mehrere Entwicklungsphasen einsetzen 2 Anforderungen formaler beschreiben und insbesondere bei innovativen Funktion RCP verwenden 3 Formalisierung des Architekturentwurfs 4 Vollständige Modellierung der Funktionalität in einem Funktionsmodell 5 Know - How in Modellierung und Simulation aufbauen bzw. stärken 27 23

24 Ausblick: Grade der Modellbasierung Klassifizierung der Modellbasierung anhand verschiedener Stufen. Stufe 0 Klassische Entwicklung: Keine Modelle und ad hoc Entwicklung Grad der Modellbasierung Aktueller Einsatzgrad Stufe 1 Stufe 2 Stufe 3 In isolierten Feldern werden Modelle eingesetzt, jedoch keine Durchgängigkeit, keine Systematik und die Relation der Modelle ist unbekannt Modelle werden insbesondere in der Funktionsmodellierung eingesetzt, jedoch nur Durchgängigkeit zwischen SW-Design und Implementierung, Systematik in der Entwicklungsmethodik wird erarbeitet und ad hoc Ansätze wie Modelle in Beziehung stehen Modelle werden neben der Funktionsmodellierung auch in anderen Entwicklungsphasen verstärkt eingesetzt, Durchgängigkeit im Entwicklungsprozess erhöht sich, eine Systematik in der Entwicklungsmethodik und ad hoc Ansätze wie Modelle in Beziehung stehen sind vorhanden Zukunft Stufe 4 Modelle werden intensiv von Anforderungsanalyse bis Testen eingesetzt, Durchgängigkeit im Entwicklungsprozess, Modelle stehen zu einander in Beziehung, Relation der Modelle ist bekannt und Systematik in der Entwicklungsmethodik vorhanden Hypothese: Je höher der Grad der Modellbasierung, desto höher sind die möglichen Einsparungen 28 Ansprechpartner bei Altran Dr. Jens Zimmermann Solution Manager Software Verantwortlich für die Studie Tel. +49 (0) Jens.Zimmermann@altran.com Sascha Kirstan Doktorand Verantwortlich für die Studiendurchführung und -auswertung Tel. +49 (0) Sascha.Kirstan@altran.com 29 24

25 30 Backup Definition MBSE Für unser Verständnis von modellbasierter Entwicklung müssen folgende Kriterien erfüllt sein: Benutzung einer schwach verbundenen Werkzeugkette Benutzung von Modellen in verschiedenen Entwicklungsphasen Modelle haben unterschiedliche Sichten Aktivitäten werden mittels Werkzeugen auf dem Modell durchgeführt Generierung von Code und anderen Artefakten aus dem Modell 31 25

26 26

27 6 Unter welchen Bedingungen modellbasierte Software-Entwicklung Vorteile bringt ein Bericht aus 11 Jahren Erfahrung Stefan Teuchert Unter welchen Bedingungen modellbasierte Entwicklung Vorteile bringt Ein Bericht aus 11 Jahren Erfahrung MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

28 Content History Development Process 03 Common Engineering Data Backbone 04 Model Types 05 Toolchain MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember History 1926: 1924: Omnibus Erster Serien-Lkw mit "Riesenluftbereifung" der MAN. 1932: Damals stärkster Diesel Lkw MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

29 History 40 Tons, 40 C, 18% Down-Hill Grade, 10km length And how do you brake? MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember History BrakeMatic Hardware getrieben / starke Komponentensicht Komponenten orientierte Optimierung und (zu) wenig Fokus auf die Funktion Hohe Komplexität es sind sehr viele (HW-) Komponenten notwendig Hohe funktionale Abhängigkeit zwischen den Komponenten die Teilfunktionen sind auf den Komponenten stark verteilt Funktionale Integration auf der Ebene der Bus-System welche CAN-Signale benötigt die Zulieferer-Komponente Lösungsorientiert was war eigentlich die Anforderung für die Lösung? MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

30 Electronic System Architecture Life-Cycle Development Phone TBM DOOR L CC Radio HU MFL I-CAN DTCO LGS DOOR R Mirror L C HMI LSS KSM Mirror R DICO EDC M-CAN PTM ZBR T-CAN LDK ACC EBS/ESP ECAS TipMatic NOx I EHLA RE NOx II AC20 DM VA TPM VSM AdBlue DM HA-L HVA HDS DM HA-R ZFR MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Content History Development Process 03 Common Engineering Data Backbone 04 Model Types 05 Toolchain MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

31 Separation Function / Component Function 1.1 Vehicle Function 1 Function 1.2 Function 1.3 Function 1.4 Function 1.5 Function x.1 Vehicle Function x Function x.3 Function x.4 Function- Level ECU 1 Actuator 1 Sensor 1 ECU x Actuator x Sensor x Component- Level Vehicle-System MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember EE Development Process Requirements Validation- Test Function- Specification System-Test Architecture- Design Modul-Test Information in ASAM MSR Structure (XML-based) Function- Design Coding Unit-Test Information in ASAM MSR Structure (XML-based) Common Engineering Data Backbone MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

32 EE Development Process Function Oriented, Requirement Based Anforderungsgetrieben Frühes Definieren und Abstimmen der Anforderungen (Front Loading) Striktes Trennen zwischen Anforderung und Lösung Reverse Engineering der Anforderungen der bestehenden Funktionen Funktionsorientiert Trennung zwischen Hardware und Funktion Komplette funktionale Beschreibung des Fahrzeugs (Vehicle Function Catalog) Integration auf Funktions-Ebene (nicht auf Component-Level) Architektur-Entwurf Definition der benötigten Komponenten im System Mapping der Funktionen auf die Komponenten Definition der Kommunikations-Matrizen Datendurchgängigkeit Hohe Datentransparenz und Durchgängigkeit Common Engineering Data Backbone Eine Datenbank für alle Entwickler MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember EE Entwicklungsprozess Aufwandsverteilung Validation- Test Requirements System-Test Function- Specification Architecture- Design Function- Design Coding Modul-Test Unit-Test 40-45% 15-20% 40% Entwicklungs-Aufwand MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

33 Content History Development Process 03 Common Engineering Data Backbone 04 Model Types 05 Toolchain MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Common Engineering Data Backbone Project- / Process- / Workflow-Management (easee) FDM TDM MDM FRM CDM SDM VDM easee.edm Oracle data base FDM: TDM: MDM: CDM: FRM: SDM: VDM: easee: Function-Data-Management Test-Data-Management Model-Data-Management Calibration-Data-Management Fault- / Requirement-Management Service-Data-Management Vehicle-Data-Management electronic Automotive System Engineering Environment MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

34 FDM - Function Data Management Requirements Vehicle Functions Functions (virtual/real) Vehicle Systems ECU s Software Hardware Architecture Virtual-, CAN-, LIN-, Analog, Digital Signals Parameters Models, Source-Code MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember FDM Meta Model Function View VEHFCN: brakematic REQ: /Variant;Version FCN: f_brakematicoperation REQ: /Variant;Version FCN: f_endurancebrakectr... Component View VEH-CONFIG: TGX REQ: /Variant;Version ECU:PTM /Variant;Version REQ: /Variant;Version HW: PTM/Variant;Version REQ: /Variant;Version SW: PTM/Variant;Version REQ: /Variant;Version FCN: f_brakematicoperation SIG: /Variant;Version PARAM: /Variant;Version REQ: /Variant;Version ECU: EDC MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

35 Traceability PRJ: Comfort_Optimization/Variante;Version Release: A-Muster FKN: cruisecontrol_i/variante;version REQ: cruisecontrol/variante;version FZG-KONFIG: truck/variante;version SG:EDC /Variante;Version SW: EDC/Variante;Version FKN: SIG: /Variante;Version ISSUE: cruisecontrol_i/variante;version PARAM: /Variante;Version REQ: /Variante;Version TCYCLE: cruisecontrol_i/variante;version MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Content History Development Process 03 Common Engineering Data Backbone 04 Model Types 05 Toolchain MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

36 Off emergencyoff ttebastate / BASE: 0 ttebastatein - / BASE: 0 tipswebaactivation / BASE: 0 tipswebaactivationout - / BASE: igni ti onoff standby eng inestandby cl ampoff 15_1 f_aebssignaladaption / BASE: 0 f_xbrchecksumeba / BASE: 0 f_activationeba / BASE: 6 f_checkeba / BASE: 6 f_decelerationcalculationeba / BASE: 6 f_diageba / BASE: 0 f_targetdetection / BASE: clampoff15_2 ACCsens / EMERGENCY_BRAKE_ASSIST: 0 - ACCsens_Sensor_CAN / BASE: 0 PTM / EMERGENCY_BRAKE_ASSIST: 0 ttebastateout / BASE: 0 CAN4 / BASIS: 1 CAN2 / BASIS: 0 - tipswebaactivationin / BASE: 0 CAN1 / BASIS: 0 f_arbextbrakereq / BASE: 3 f_recordeba / BASE: igni ti onon cl ampo n15_1 eng inestartup eng ineactive eng ineshut Down cl ampon15_2 INSTRUMENT / BASE: 0 - INSTRUMENT_I_CAN / BASE: 0 ZBR / EMERGENCY_BRAKE_ASSIST: 0 ZBR_I_CAN / BASE: 0 ZBR_T_CAN / BASE: postcrash i nmotion f_displayeba / BASE: 5 EBS / KNORR_EMERGENCY_BRAKE_ASSIST: 0 EBS_T_CAN / -BASE: 0 m_ebc1 / EBS_TX_KB: 1 m_ebc2 / EBS_TX: 0 m_ebc5 / EBS_TX: 1 m_vdc2 / EBS_TX: 3 m_xbr / EBS_RX_KB1: 0 normalmotion f_directionindicatorctrl / BASIS: 0 1 pr ecrash MAN Model-Types I Nutzen / Aufwand Vehicle System State Model Vehicle System Level Nutzen klare System-Zustände deutlich verbesserte Funktions-Architektur Simulation von Zustandsübergängen Mittlerer Einmalaufwand Grad der Nutzung in allen Baureihen Einspar-Potential hoch System Architecture Model System Level I_CAN / BASE: 0:I_CAN / BASE: 0 Nutzen Einfache Zuordnung Funktion/Komponente Modellbasierter Architektur-Entwurf Berechnung von Prozessor-Auslastungen Berechnung von Buslasten Timing Analysen des Funktions-Verhaltens Mittlerer Aufwand Grad der Nutzung bei allen Systemen Einspar-Potential mittel MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember MAN Model-Types II Nutzen / Aufwand Vehicle Function Model Vehicle Function Level Function Model Virtual Function Level Real Function Level Nutzen/Aufwand Simulation des Verhaltens Überprüfung der Anforderungs-Vollständigkeit Meta-Beschreibung der Vehicle Function für den Test Erstellungsaufwand ist hoch Grad der Nutzung in alle komplexen Vehicle Functions Einspar-Potential hoch Nutzen/Aufwand Simulation des Teilverhaltens Überprüfung der Anforderungs-Vollständigkeit Meta-Beschreibung der Function für den Test Erstellungsaufwand Modell / Code gering automatische Code-Generierung möglich keine formalen Codier-Fehler Grad der Nutzung für alle bei MAN entwickelten Funktionen Einspar-Potential hoch MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

37 MAN Model-Types III Nutzen / Aufwand Base Software Realtime Model Component Level Nutzen/Aufwand Meta-Beschreibung des Timing-Verhaltens der Base Software Überprüfung des Timings von (Vehcile) Functions Überprüfung von Rechenzeit und Prozessor- Auslastung Erstellungsaufwand ist mittel Grad der Nutzung für alle bei MAN entwickelten ECU s Einspar-Potential hoch Test Model Unit Test Level Integration Test Level System Test Level Nutzen/Aufwand bei exakter Beschreibung der Test-Basis nicht notwendig bei Änderung der Test-Basis ist der Änderungs- Aufwand des Test-Modells zu hoch Grad der Nutzung wird nicht mehr genutzt Einspar-Potential negativ MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Content History Development Process 03 Common Engineering Data Backbone 04 Model Types 05 Toolchain MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

38 CEDB - Master of the Development Process Common Engineering Data Backbone MSRSW (MDX, FSX, ARX) MSRSW (MDX), MSRREP, TDX (MAN) MSRSW (CDF 2.0) A2L ODX MSRSW (MDX, CDF 2.0) ODX Development environment EOL database Calibrationtool Testenvironment Aftersalesdatabase Matlab/Simulink Matlab/Simulink TargetLink ControlDesk ASM CalDesk EmbeddedValidator EmbeddedTester MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Interface FDM Authoring Environment Generic Interface FDM Authoring Environment (XMetaL) MSRSW (FSX) (XML) MSRSW (FSX) (XML) (PDF) MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

39 Interface FDM Function Development Environment Generic Interface FDM Matlab/Simulink (MathWorks) TargetLink model (dspace) MSRSW (MDX) (XML) Local Data Dictionary (dspace) MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Unit-Test - Overview Unit Test MIL Model in the Loop Model Test Floating point SIL Software in the Loop C-Code test Fixed point PIL Processor in the Loop Target Processor and Compiler Runtime, Memory MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

40 Unit-Test - Formal Test - Quality Gate for all Test-Activities FDM Embedded Tester TDM TDX (MAN) Report Analysis Unit Test II - Formal Testing MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Unit-Test - Functional Test - FDM MDX (ASAM) Test-Authoring Environment (Eclipse, AXE, TVE) Runtime Environment Test-Object (Model) Embedded Tester TDM Reporting TDX (MAN) MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

41 Software-Generation Application diagnosticsmanager get-functions tasks, function-call put-functions OSEK (OIL) / OS Flash XCP microkernel errormemory UDS CAN-module middleware signal data base LINmodule LINlayer HWmodule CANlayer EEPROM microc FDM platform hardware : from FDM generated : hand-code : automatic code-generation MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember Schnittstelle Integration-Test TDM EW-Umgebung Virtual Integration Test (Function) Virtual Function Requirement Requirement FDM diagnosticsmanager Application tasks, function-call get-functions put-functions OSEK (OIL) / OS Integration Test (ECU) ECU middleware signal data base errormemory CAN- Flash LINlayekernel microlayer HWmodule XCP UDS EEPROM LINmodule microc CAN-module platform hardware MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

42 Thank you very much for your attention! Stefan Teuchert Electric/Electronic Systems Vehicle Dynamic, Comfort and Driver Interaction Functions MAN Nutzfahrzeuge AG MAN Nutzfahrzeuge AG Stefan Teuchert 14. Dezember

43 7 Nutzenpotentiale in der Anwendung einer modellbasierten Architekturentwicklung Martin Wechs Technische Universität München Nutzenpotentiale in der Anwendung einer modellbasierten Architekturentwicklung Martin Wechs, BMW Group HSE 2010/3 Hot-Spots der Software-Entwicklung 2010/ , TUM, Garching 43

44 1 Technische Universität München Inhalt Einleitung Integrierter modellbasierter Ansatz Durchgängiger Architekturentwicklungsprozess Nutzenpotenziale Fazit 2 Technische Universität München Einleitung Ca. 40% der Fahrzeugkosten entstehen durch Elektrik/Elektronik. Die Software stellt 50-70% der Entwicklungskosten eines Steuergerätes dar (ECU = electronic control unit). Fahrzeuge im Premiumsegment enthalten bis zu 100 ECUs, die über eine Vielzahl von Bussystemen (e.g. CAN, FleyRay, MOST, LIN, ) miteinander kommunizieren. Steigende Systemfunktionalität und -komplexität Wachsende Vernetzung im Fahrzeug Schnelle Hardware-Zyklen mit einhergehenden Cost-Downs E36 E65 F01 44

45 Erfassung nichtfunktionaler Anforderungen Erfassung nichtfunktionaler Anforderungen Funktionale Analyse Funktionale Analyse Architektur vorlage Architektur vorlage Funktionales Design Funktionales Design Modellbasierte Absicherung Modellbasierte Absicherung Ausleitung HW/SW Ausleitung HW/SW Festlegung Kundenfunktion Systemintegration Systemabnahme Festlegung Kundenfunktion Systemintegration Systemabnahme 1 Technische Universität München Das Zielbild Formale Modellierungsprache Integrierte Werkzeugumgebung Durchgängige Prozesse & Methoden Schnelle Entwicklungszyklen RunTime Verifikation T arget- annotation Verifikation Downsizing Verifikation C lustering + + Ausleitung Verifikation T es tfall- Gen. Code- Gen. 1 Technische Universität München Zielbild: Formale Modellierungssprache Formale Modellierungsprache Integrierte Werkzeugumgebung Durchgängige Prozesse & Methoden Schnelle Entwicklungszyklen RunTime Verifikation T arget- annotation Verifikation Downsizing Verifikation C lustering + + Ausleitung Verifikation T es tfall- Gen. Code- Gen. 45

46 2 Technische Universität München Abstraktionsebenen in der Architekturmodellierung Anforderungen Feature Architektur Logische Architektur Technische Architektur ECU ECU ECU ECU ECU Design und Umsetzung 3 Technische Universität München Abstraktionsebenen in der Architekturmodellierung Feature Architektur Logische Architektur Technische Architektur Sub-Unit Channel Clustering Network Feature Tree Feature Dependency Cluster Allocation Feature Bus Automaton State Transition ECU Hardware Topology 46

47 1 Technische Universität München Zielbild: Durchgängige Prozesse und Methoden Formale Modellierungsprache Integrierte Werkzeugumgebung Durchgängige Prozesse & Methoden Schnelle Entwicklungszyklen R unt ime Verifikation T arg et- annotation D owns izing Verifikation Verifikation Festlegung Festlegung KundenKundenfunktion funktion C lus tering Funktionale Funktionale Analyse Analyse + Erfassung Erfassung nichtfunktionaler nichtfunktionaler Anforderungen Anforderungen Funktionales Funktionales Design Design Modellbasierte Modellbasierte Absicherung Absicherung + Ausleitung Ausleitung HW/SW HW/SW SystemSystemintegration integration SystemSystemabnahme abnahme Architektur Architektur vorlage vorlage Verifikation T es tfall- G en. C ode- G en. 4 Technische Universität München Durchgängiger ArchitekturEntwicklungsprozess 47

48 Erfassung nichtfunktionaler Anforderungen Funktionale Analyse Architektur vorlage Funktionales Design Modellbasierte Absicherung Ausleitung HW/SW Festlegung Kundenfunktion Systemintegration Systemabnahme 1 Technische Universität München Zielbild: Nutzenpotentiale Formale Modellierungsprache Integrierte Werkzeugumgebung Durchgängige Prozesse & Methoden Schnelle Entwicklungszyklen RunTime Verifikation T arget- annotation Verifikation Downsizing Verifikation C lustering + + Ausleitung Verifikation T es tfall- Gen. Code- Gen. Technische Universität München Zielbild: Stellhebel Nutzen Teil 1 48

49 Technische Universität München Zielbild: Stellhebel Nutzen Teil 2 Technische Universität München Fazit Ein modellbasierter Ansatz in der E/E Architekturentwicklung hat wesentliche Nutzenpotentialle, insbesondere durch Effizienzsteigerung Qualitätssteigerung Reduktion der externen Entwicklungskosten Wesentliche Voraussetzungen hierfür sind jedoch Änderung und Disziplin im Prozess bzgl. Front-Loading, da hier die Weichen gestellt werden Durchgängige IT-Entwicklungsumgebung, die insbesondere Performant ist, Ein mächtiges Versions- und Variantenmanagement mitbringt, Einen verteilten Entwicklungsprozess (OEM - intern / Tier 1) unterstützt Einen Befüllungsstand von ca. 70% mit Qualitativ hochwertigen Daten. 1. Es bedarf einer konzertierten Aktion und enormer Anstrengungen bis der Eingangspotentialwall überwunden ist. 2. Die Einführung muss aufgrund von Produktentwicklungszyklen und dem notwendigen Änderungsprozess über einen Zeitraum von 7-10 Jahren geplant sein. 49

50 0 Technische Universität München Vielen Dank für Ihre Aufmerksamkeit! Fragen? 50

51 51

52 8 Modellbasierte Entwicklung eingebetteter Software Vom Stand der Technik zu neuen Möglichkeiten Bernhard Schätz!"#$%%&'()$*+$,-.+/)01%2.3,$).3$&$4$+$*,56(+$7$ 8"7,5+'.#,#$*,9$0:.)1,;2,;21<.=)3$.,!>3%)0:1$)+$.!"#$%&"#'()*+(%",-.+*$/0# (9:02;*0 G"+H''(6IAB!J(9:02;*0 52

53 50)(7+.0'G*+()*+(7*2;01'2;*0(801M*+'1#F#( 9:02;*0! I*'*44'2;.,*+ "!"#$%&'#$"()%&*"+'&,-,(./%#$"% " 0123(45+6"+78%9(:8;"+% " I*GN+)*+#(M"A(B.O*+1'2;*0(9101'#*+15A(G:+( P1+#'2;.,J(7+.0'&"+#(50)(7*2;0"4"61*('*1#( Q.05.+(CDDR! 7;*A*0'2;-*+&503#S(L"+'2;506(50)( /0# ('",-.+*10#*0'1M*+(%O'#*A*(G:+( #*2;01'2;*(50)(B*#+1*B412;*(K0-*0)506*0 C -.+/)01%2.3,$).3$&$4$+$*,5"=/'*$C,E$*'2(?"*#$*2.3$. A B=CD?"E&,-,(6"+(G"7H.$. F 2%G"%6<%H'6=C-%"%3(IJ:J(2%,+&"73(B8+=''"+&"3(K%1=,8&%C"%, F K%H"%&"<+6=C-%"%3(IJ:J(."#$8%&93(L?"9,+&9ML?"9,+=%&93(K%1=+C8N9 A B=CD?"E&,-,(6"+(9$0:."%"3)$ F O?8P=+C3(IJ:J(QD"&#$"+7"'#$+-%9<%H3(:8%67+"&,"%7"'#$+-%9<%H F R"+,"&?<%H3(IJ:J(Q"%'=+"%3(Q,"<"+H"+-,"3(:<''" A B=CD?"E&,-,(6"+(F2.1@".'%)+H+ F >+5S"%I<G8#$'3(IJ:J(B=C1=+,3(K%1=,8&%C"%, F R"+T"#$,<%H'I<G8#$'3(IJ:J(L?"9,+=%&'#$"(Q,87&?&,-,3(268DN*"+(!"CD=C8, A B=CD?"E&,-,(6"+(L%,G&#9?<%H F U<?&"1"+9"V"3(IJ:J(!)##%$/'*$3(2%G"%6<%H'1<%9N=%"% F O+=6<9,?&%&"%3(IJ:J(2<'',8V<%H3(0-%6"+*8+&8%,"%! I"7J%$K)+H+(*$#21@".,#2*0:,-).('+;,L".,!"#$%%$.,2.#,M$*1;$232.+$*(+<+;2.3 TUM/fortiss, B.Schätz - Architekturmodelle im Automotive Software Engineering 4 53

54 Systemspezifikation Türsteuergerät Sachnummer: Version: 1.0 Stand: Autor: Frank Houdek Systemspezifikation Türsteuergerät Systemspezifikation Türsteuergerät Sachnummer: Version: 1.0 Stand: Autor: Frank Houdek Systemspezifikation Türsteuergerät 3 Komponentenbeschreibung 3.1 Position im Fahrzeug 16 3 KOMPONENTENBESCHREIBUNG Je ein TSG wird in der Fahrer- und Beifahrertür eingebaut (siehe Abbildung 2). Abbildung 3 zeigt sche- TSG Abbildung 2: Position des TSG im Fahrzeug. matisch die Anordnung der Bedienelemente, die dem TSG zugeordnet sind. 3.2 Schnittstellen Das TSG wird über drei Steckleisten mit seiner Umgebung verbunden. Stecker S1: 24-polige Steckerleiste. Über diesen Stecker werden alle Sensoren und Aktoren innerhalb der Tür angeschlossen. Stecker S2: 49-polige Steckerleiste. Über diesen Stecker werden alle Sensoren und Aktoren außerhalb der Tür, d.h. im Fahrzeuginnenraum (z.b. Sitztaster), im Fahrzeugrahmen (z.b. Außenspiegel) und in der zugehörigen Fondtür angeschlossen. Stecker S3: 8-polige Steckerleiste. Über diesen Stecker erfolgt die Stromversorgung sowie die Ankopplung an den Innenraumbus (CAN Bus). Nachfolgend werden die einzelnen Schnittstellen detailliert beschrieben Stecker S1: Türelemente 29 FKIND SICH In Kindersicherung in zugehöriger Fondtür (nicht belegt bei Version Stand Autor Freigabe 1.0 Die Kontaktierung ist durchgängig F. Houdek mit versilberten 0.63mm Kontakten im Macro Tripplelock System Cabriolet und Coupé) auszuführen. Abbildung 4 zeigt das Steckerbild. Tabelle 1 beschreibt die Belegung des Steckers im Überblick. Sach-Nr Seite 1 von FT LICHT Out Ausstiegsleuchte in zugehöriger Fondtür (nicht belegt bei Cabriolet und Coupé) 31 FB LICHT Out Beleuchtung der Bedienelemente der zugehöriger Fond- 3 Komponentenbeschreibung 3.1 Position im Fahrzeug Systemspezifikation Türsteuergerät 11 Fortsetzung der Tabelle von vorhergehender Seite Anschluß Bezeichnung In/Out Beschreibung 3 FF BEWEG In Scheibenbewegung des Fensters in zugehöriger Fondtür (nicht belegt bei Cabriolet und Coupé) 4 SITZ HOR In Sitztaster Sitz vor/zurück 5 SITZ V In Sitztaster Sitzfläche vorne heben/senken 6 SITZ H In Sitztaster Sitzfläche hinten heben/senken 7 SITZ S In Sitztaster Schalung enger/weiter 8 SITZ W In Sitztaster Lehnenwinkel steiler/flacher 9 SPOS HOR In Sitzposition Ist Wert Sitz vor/zurück 10 SPOS V In Sitzposition Ist Wert Sitzfläche vorne heben/senken 11 SPOS H In Sitzposition Ist Wert Sitzfläche hinten heben/senken 12 SPOS S In Sitzposition Ist Wert Schalung enger/weiter 13 SPOS W In Sitzposition Ist Wert Lehnenwinkel steiler/flacher 14 SP HOR In Spiegeltaster horizontal (nur belegt bei Fahrertür) 15 SP VERT In Spiegeltaster vertikal (nur belegt bei Fahrertür) 16 SP LR In Spiegelwahlschalter (nur belegt bei Fahrertür) 17 SP MOT H1 Out Spiegelmotor horizontal 18 SP MOT H2 Out Spiegelmotor horizontal 19 SP MOT V1 Out Spiegelmotor vertikal 20 SP MOT V2 Out Spiegelmotor vertikal 21 FF MOTOR1 Out Ansteuerung des Fensterheber Motors in der zugehörigen Fondtür (nicht belegt bei Cabriolet und Coupé) 22 FF MOTOR2 Out Ansteuerung des Fensterheber Motors in der zugehörigen Fondtür (nicht belegt bei Cabriolet und Coupé) 23 SP POS H In Spiegelposition horizontal 24 SP POS V In Spiegelposition vertikal 25 FF UNTEN In Fenster der zugehörigen Fondtür ist unten (nicht belegt bei Cabriolet und Coupé) 26 FF OBEN In Fenster der zugehörigen Fondtür ist oben (nicht belegt bei Cabriolet und Coupé) 27 FT OFFEN In Zugehörige Fondtür offen (nicht belegt bei Cabriolet und Coupé) 28 FT GRIFF In Griffleiste der zugehörigen Fondtür angehoben (nicht belegt bei Cabriolet und Coupé) tür (nicht belegt bei Cabriolet und Coupé) 32 SMOT HOR1 Out Ansteuerung Sitzmotor Sitz vor/zurück 33 SMOT HOR2 Out Ansteuerung Sitzmotor Sitz vor/zurück Version Stand Autor Freigabe F. Houdek 34 SMOT V1 Out Ansteuerung Sitzmotor Sitzfläche vorne heben/senken Sach-Nr Seite von SMOT 49 V2 Out Ansteuerung Sitzmotor Sitzfläche vorne heben/senken Tabelle wird auf der nächsten Seite fortgesetzt Systemspezifikation Türsteuergerät Version Stand Autor Freigabe F. Houdek Sach-Nr Seite 16 von KOMPONENTENBESCHREIBUNG Je ein TSG wird in der Fahrer- und Beifahrertür eingebaut (siehe Abbildung 2). Abbildung 3 zeigt sche- TSG Abbildung 2: Position des TSG im Fahrzeug. matisch die Anordnung der Bedienelemente, die dem TSG zugeordnet sind. 3.2 Schnittstellen Das TSG wird über drei Steckleisten mit seiner Umgebung verbunden. Stecker S1: 24-polige Steckerleiste. Über diesen Stecker werden alle Sensoren und Aktoren innerhalb der Tür angeschlossen. Stecker S2: 49-polige Steckerleiste. Über diesen Stecker werden alle Sensoren und Aktoren außerhalb der Tür, d.h. im Fahrzeuginnenraum (z.b. Sitztaster), im Fahrzeugrahmen (z.b. Außenspiegel) und in der zugehörigen Fondtür angeschlossen. Stecker S3: 8-polige Steckerleiste. Über diesen Stecker erfolgt die Stromversorgung sowie die Ankopplung an den Innenraumbus (CAN Bus). Nachfolgend werden die einzelnen Schnittstellen detailliert beschrieben Stecker S1: Türelemente 29 FKIND SICH In Kindersicherung in zugehöriger Fondtür (nicht belegt bei Version Stand Autor Freigabe 1.0 Die Kontaktierung ist durchgängig F. Houdek mit versilberten 0.63mm Kontakten im Macro Tripplelock System Cabriolet und Coupé) auszuführen. Abbildung 4 zeigt das Steckerbild. Tabelle 1 beschreibt die Belegung des Steckers im Überblick. Sach-Nr Seite 1 von FT LICHT Out Ausstiegsleuchte in zugehöriger Fondtür (nicht belegt bei Cabriolet und Coupé) 31 FB LICHT Out Beleuchtung der Bedienelemente der zugehöriger Fond- Systemspezifikation Türsteuergerät 11 Fortsetzung der Tabelle von vorhergehender Seite Anschluß Bezeichnung In/Out Beschreibung 3 FF BEWEG In Scheibenbewegung des Fensters in zugehöriger Fondtür (nicht belegt bei Cabriolet und Coupé) 4 SITZ HOR In Sitztaster Sitz vor/zurück 5 SITZ V In Sitztaster Sitzfläche vorne heben/senken 6 SITZ H In Sitztaster Sitzfläche hinten heben/senken 7 SITZ S In Sitztaster Schalung enger/weiter 8 SITZ W In Sitztaster Lehnenwinkel steiler/flacher 9 SPOS HOR In Sitzposition Ist Wert Sitz vor/zurück 10 SPOS V In Sitzposition Ist Wert Sitzfläche vorne heben/senken 11 SPOS H In Sitzposition Ist Wert Sitzfläche hinten heben/senken 12 SPOS S In Sitzposition Ist Wert Schalung enger/weiter 13 SPOS W In Sitzposition Ist Wert Lehnenwinkel steiler/flacher 14 SP HOR In Spiegeltaster horizontal (nur belegt bei Fahrertür) 15 SP VERT In Spiegeltaster vertikal (nur belegt bei Fahrertür) 16 SP LR In Spiegelwahlschalter (nur belegt bei Fahrertür) 17 SP MOT H1 Out Spiegelmotor horizontal 18 SP MOT H2 Out Spiegelmotor horizontal 19 SP MOT V1 Out Spiegelmotor vertikal 20 SP MOT V2 Out Spiegelmotor vertikal 21 FF MOTOR1 Out Ansteuerung des Fensterheber Motors in der zugehörigen Fondtür (nicht belegt bei Cabriolet und Coupé) 22 FF MOTOR2 Out Ansteuerung des Fensterheber Motors in der zugehörigen Fondtür (nicht belegt bei Cabriolet und Coupé) 23 SP POS H In Spiegelposition horizontal 24 SP POS V In Spiegelposition vertikal 25 FF UNTEN In Fenster der zugehörigen Fondtür ist unten (nicht belegt bei Cabriolet und Coupé) 26 FF OBEN In Fenster der zugehörigen Fondtür ist oben (nicht belegt bei Cabriolet und Coupé) 27 FT OFFEN In Zugehörige Fondtür offen (nicht belegt bei Cabriolet und Coupé) 28 FT GRIFF In Griffleiste der zugehörigen Fondtür angehoben (nicht belegt bei Cabriolet und Coupé) tür (nicht belegt bei Cabriolet und Coupé) 32 SMOT HOR1 Out Ansteuerung Sitzmotor Sitz vor/zurück 33 SMOT HOR2 Out Ansteuerung Sitzmotor Sitz vor/zurück Version Stand Autor Freigabe F. Houdek 34 SMOT V1 Out Ansteuerung Sitzmotor Sitzfläche vorne heben/senken Sach-Nr Seite von SMOT 49 V2 Out Ansteuerung Sitzmotor Sitzfläche vorne heben/senken Tabelle wird auf der nächsten Seite fortgesetzt Systemspezifikation Türsteuergerät Version Stand Autor Freigabe F. Houdek Sach-Nr Seite 16 von 49 5"=/'*$$.+/)01%2.3,)7,F':*;$23C,-.+/)01%2.3(J*";$(( B1+2$%%$,-.+/)01%2.3W(.-%H"?(6<+#$(1"$?"%6"(2+#$&,"9,<+C=6"??"(=6"+(1"$?"%6"(X<,I<%H YJ :"&'D&"?(B=CD=%"%,"%'D"I&Z98N=%W(4"$?"%6"([=C-%"%9=%I"D," \J :"&'D&"?(Q;',"C'D"I&Z98N=%W(4"$?"%6"(2+#$&,"9,<+"7"%" ]J :"&'D&"?(KCD?"C"%N"+<%HW(4"$?"%6"(Q&#$,"%&%,"H+8N=% ^J :"&'D&"?(B=CD=%"%,"%"%,G<+1W(4"$?"%6"(B=%'&',"%I8%8?;'" _J :"&'D&"?(`"?"8'"D?8%<%HW(4"$?"%6"(O?8%H"%"+&"+<%H aj :"&'D&"?(27'&#$"+<%HW(4"$?"%6"(!"',8<'?"&,<%H bj :"&'D&"?(Q;',"CG8+,<%HW(4"$?"%6"(c<8?&,-,'8%8?;'" dj :"&'D&"?(Q;',"C&%,"H+8N=%W((4"$?"%6"(L%,G<+1'8<,=C8N'&"+<%H TUM/fortiss, B.Schätz - Architekturmodelle im Automotive Software Engineering 5 N$)(J)$%,OC,I"7J".$.+$.(J$;)P1'@". N)(:$*C,Q.'#$R2'+$,!"#$%%$(e(.=6"??&"+<%H(+"T"9N"+,(,"#$%&'#$"(05'<%H A O+=7?"CW(4"$?"%6"(B=%I"D,"(6"+(2%G"%6<%H'6=C-%" A B=%'"f<"%IW(B"&%"(8%H"C"''"%"(.=6"??&"+<%H(6"+(2%G"%6<%H'1<%9N=%8?&,-, TUM/fortiss, B.Schätz - Architekturmodelle im Automotive Software Engineering 6 54