Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement

1. Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

2. Hinweis: Am Freitag entfällt die Vorlesung! (Projekttreffen IMMOS) • Hinweis: Nächsten Freitag entfällt die Vorlesung ebenfalls! (Tagung M4M – Methods for Modalities) • (Mittwoch findet sie aber statt!) (Übungsblattausgabe)

3. nächstes Übungsblatt …

4. SimuLink • Modellierung durch Datenflussdiagramm • jede „Leitung“ entspricht einer Variablen

6. Abstraktion • Hauptstärke von SimuLink besteht in der Möglichkeit, Blöcke zusammenzufassen • Abstraktion von Verhalten • baumartige Navigation • Parametrisierung • Modulbibliotheken • externe Erweiterungen • Codeanbindung • Modelltransformation und –entwicklung!

7. Beispiel: Fensterheber

8. Kurzüberblick über das IMMOS-Projekt • Projekttitel:IMMOS – Eine integrierte Methodik zur modellbasierten Steuergeräteentwicklung für den Automobilbereich • Laufzeit: Januar 2004 – Juni 2006 • Ziele:Definition einer integrierten Software-Entwicklungsmethodik für Steuergeräte im KFZ und Erprobung dieser Methodik durch die Entwicklung eines automobilen Demonstrators • Projektpartner:Fraunhofer FIRST, DaimlerChrysler AG, dSPACE GmbH, IT Power Consultants, FZi / Universität Karlsruhe, c-Lab / Universität Paderborn • Mittel: • 285 PM

9. modellbasierte Entwicklung • frühzeitige Erstellung eines ausführbaren Modells (Systemmodell) auf Grundlage der Anforderungen • Test und Erprobung auf Modellebene • Verfeinerung zum Implementierungs-modell • automatische Code-generierung für Hostund Target • automatischeTestgenerierung

10. Lastenheft formaleSpezifikation Formalisierung Virtueller Prototyp Prototyping Modellierung Systemmodell Testgenerierung Verifikation Testfälle Testgenerierung ZusätzlicherCode Verfeinerung Implementierungs- modell Testausführung Codegenerierung Target-Code Zielsystem Portierung Integration Aktivitäten und Artefakte

11. Modellierungsformalismen • herkömmliche Formalismen: Zustandsmaschinen, Diagramme, Petrinetze, StateCharts, Message Sequence Charts, ... • gut etabliert, Toolunterstützung vorhanden • Wildwuchs, Varianten, mangelnde Konstanz • Prognose: werden durch UML2.0 abgelöst werden • UML 2.0 • vereinigt verschiedene Arten von Diagrammen • extrem mächtig, sehr umfangreich zu lernen • fehlende Semantik, verschiedene Ausbaustufen • Matlab / Simulink / Stateflow • teilweise gut eingeführt und bekannt • limitierte Ausdrucksfähigkeit • nur eine Quelle • logische und algebraische Modelle, z.B. TLA, ASM/ASML, CSP • nahe an natürlichsprachlichen Formulierungen • Forschungsbedarf

12. Pause! „Bist du sicher, dass du kein Modell brauchst?“

13. Noch einer • Google „model cartoon“

14. Codegenerierung • Ziel: automatische Übersetzung von Modellen in ausführbaren (C-) Code • zwei kommerzielle Produkte verfügbar • Real Time Workshop (The MathWorks) • TargetLink (dSPACE GmbH) • Codegenerator ist „Compiler für Modelle“ • Wiederverwendung • schnelle Prototyp- undProdukterstellung • erhöhte Zuverlässigkeitgegen Programmierfehler • automatische Optimierungdes generierten Codes • Wie kann mansicherstellen, dass der generierte Codedas Erwartete leistet? Thanks for the slides: Daniela Weinberg Quelle: dSPACE GmbH

15. Prinzip

16. Beispiel • Schaltsystem mit Schwellwert 0.5 • physikalisches Modell (SimuLink) • Implementierungsmodell (TargetLink) • Äquivalenz?

17. generierter Code • Zweierpotenz-Skalierung; 128 * 2-8 = 0.5 Void switch_system(Void) { /* Switchswitch_system/switch_primitive */ if (Sa1_Input2_ >= 128 /* 0.5 */) { /* # combined # Outport: switch_system/OutputPort */ Sa1_OutputPort_ = Sa1_Input1_; } else { /* # combined # Outport: switch_system/OutputPort */ Sa1_OutputPort_ = Sa1_Input1_; } }

18. Codeabsicherung • Qualitätssicherung auf jeder Ebene notwendig! (c) generierter Code (d) Code Ausführung (a) Modell (b) Code- Generator Physical Model (floating - point) Compiler (Linker) Host PC Code generator C Code Target Implementation Model (fixed - point) Cross - compiler (Linker / Loader )

19. QS auf Modellebene • Modellierungsrichtlinien • Qualität des Implementierungsmodells ausschlaggebend für Qualität des generierten Codes • Richtlinien und Muster existieren (z.B. MathWorks Automotive Advisory Board - MAAB guidelines) • Toolunterstützung zur Umsetzung der Richtlinien • demnächst www.eGuidelines.de • Vorteile • Lesbarkeit • Wartbarkeit • Wiedervervendbarkeit • Testbarkeit

20. test output physical model MiL (physical model) implementation model MiL (impl. model) C code (host) test stimuli þ » ý SiL result comparison C code (target) PiL ECU modellbasierter Test • Simulation /Ausführung des Modells und generierten Codes in verschiedenene Entwicklungsphasen • MiL (Model in the Loop) • SiL (Software in the Loop) • PiL (Processor in the Loop) • HiL (Hardware in the Loop)

21. Code Requirements Modell Testsuite Requirements Code Modell UseCases Testsuite Szenarien für Testautomatisierung

22. Transformationsregeln Codegenerator Modellgenerator Modell Code Simulator Testfallgenerator Target Comparator Simulationsergebnisse Ausführungsergebnisse Absicherung von Codegeneratoren • Probleme • häufige Generationenfolge von Prozessoren und Codegeneratoren • Notwendigkeit zusätzlicher Absicherung • Ansatz in IMMOS • Validationssuite für Codegeneratoren • Graph-Transformationen als logische Basis

23. RHS LHS r 0.3 0.0 0.1 0.2 0.3 1.0 0.0 0.1 0.2 0.3 0.5 Im Beispiel test vectors test model Input1(t) Input2(t) test cases optimization test module test vector optimization rule test model model generator ModeSSa test vector generator Reactis, ET-Tool