Prinzipien und Komponenten eingebetteter Systeme

Transkript

1 1 Prinzipen und Komponenten Eingebetteter Systeme (PKES) (12) Softwareentwicklung für eingebettete Geräte Sebastian Zug Arbeitsgruppe: Embedded Smart Systems

2 2 Veranstaltungslandkarte Fehlertoleranz, Softwareentwicklung Mikrocontroller Architekturen Sensoren Scheduling Arithmetik Anwendungen Aktoren Kommunikation Energieversorgung

3 3 Literaturhinweise Peter Marwedel, Eingebettete Systeme Springer 2008 Karsten Berns, Bernd Schürmann, Mario Trapp Eingebettete Systeme - Systemgrundlagen und Entwicklung eingebetteter Software Vieweg+Teubner (Quelle der Grafiken, sofern nicht anders vermerkt)

4 4 Fragestellungen an diese Veranstaltung Welche Herausforderungen ergeben sich insbesondere für die Entwicklung von eingebetteten Geräten? Beschreiben Sie den V-Prozess bei der Softwareentwicklung. Welcher Grundidee folgt die modellgetriebene Softwareentwicklung? Welche Herausforderungen ergeben sich aus dem Ansatz? Nennen Sie die Ebenen der modellgetriebenen Softwareentwicklung. Sie haben im Rahmen der Vorlesung Assembler und C programmiert sowie eine Demo zum Einsatz von Simulink gesehen. Welche Vorund Nachteil ergeben sich aus den Ansätzen. Begründen Sie Ihre Aussagen anhand von Beispielen. Welche Parameter bestimmen das effektive Testen? Wie ist das allgemeine Vorgehen beim Testen? Was ist der Unterschied zwischen Verifikation und Validierung? Welches Grundproblem löst der JTAG Standard? Welche Testmechanismen lassen sich damit umsetzen?

5 5 Motivation - Mautsystem Starttermin, 31. August 2003 scheitert wegen: - Fehlfunktionen der OBU - Fehlenden Messbrücken und Automaten - Software Fehler in den Terminals - Maut-Terminals mit zu geringem Sprachunterstützung - Schwierigkeiten bei der Systemintegration Als neuer Termin wurde der 2. November 2003 festgesetzt Anfang November 2003 sind 86 Fehler im Mautsystem dokumentiert und die Einführung auf unbestimmte Zeit verschoben seit 1. Januar 2006 läuft das System mit der vollen Funktionalität. Die Bundesregierung bezifferte den Ausfall bereits budgetierter Einnahmen auf mindestens 156 Millionen Euro pro Monat.

6 6 Herausforderung Softwareentwicklung für ES Ausfälle oder Fehlfunktionen sind in sicherheitskritischen Anwendungen nicht tolerabel häufig fehlende Wartbarkeit - Zugang schwierig (PKW Rückrufaktionen vs. geringwertige Güter) - Zugang nicht erwünscht Doppelte Herausforderung für eingebettete Geräte (Software/Hardware) Heterogene Struktur (Reaktive Ebene, Steuerungsebene, Leitebene) Versionen (Featuremanagment) Interdisziplinäre Teams -> Der Software/Hardware-Entwicklungsprozess braucht eine übergreifende Steuerung

7 7 Ausgangspunkt Eingebettete Systeme - Systemgrundlagen und Entwicklung eingebetteter Software Im Fokus standen die Hardware, die Sensorik und Aktuatorik, sowie die Entwicklung der benötigten Regler, Filter und Berechnungsmodelle. Software wurde letztlich nur als notwendiges Hilfsmittel gesehen den letzten kleinen Schritt Die Entwicklung eingebetteter Software war in der Wahrnehmung also keine Aufgabe des Softwareengineerings, sondern beispielsweise eine Teilaufgabe der Regelungstechnik oder des Maschinenbaus. Forumeintrag Die einzige Wahrheit liegt im Code, alles andere ist nur inkonsistente Dokumentation.

8 8 Wie machen wir Komplexität handhabbar? Hardwarenähe Abstraktionen Simulink C, C++ Assembler Betriebssysteme HAL-Libraries Register Programmiersprachen Frameworks Aber: Lücke zwischen der Definition der Anforderungen, der Implementierung und der Validierung

9 9 V-Prozess Funktionsspezifikation Systemspezifikation

10 10 Modellorientierte Entwicklung Modellbasierte Entwicklung zielt auf die abstrakte Definition des Systems anstatt der Programmierung Modellierungselementen bilden das Verhalten, Eigenschaften usw. abstrahiert nach anstatt mit Variablen, Schleifen und Funktionsaufrufen zu arbeiten in Modellierungssprachen stehen Konstrukte wie Übertragungsfunktionen, Fouriertransformationen oder Zustandsautomaten zur Verfügung. Quellcode wird nicht mehr manuell geschrieben, sondern weitgehend automatisch generiert. Modelle stellen sowohl Implementierung als auch Dokumentation dar.

11 11 V-Prozess am Beispiel Überwachen unseres Labortisches Differentieller Roboter, 8Bit, Funktionsspezifikation Systemspezifikation UML Modell Komponenten, Interaktion, Zustandsmaschine Funktionale Beschreibung der Komponenten Programmierung

12 12 Welche Modellierungswerkzeuge kommen wo zum Einsatz? Strukturmodelle Interaktionsmodelle Verhaltensmodelle

13 13 Verhaltensmodellierung mit Simulink

14 14 Alternativen zur Modellierung eingebetteter Systeme Labview Source:

15 15 Alternativen zur Modellierung eingebetteter Systeme Xcos Source:

16 16 Herausforderung Codegenerierung Modelle ausführbar = Softwareentwicklung abgeschlossen? Probleme: Integration der Schnittstellen Datentypen und Speicherplatzanforderungen Zeitannahmen Verteilung auf mehrere Steuergeräte Häufig ist eine manuelle Nachbesserung notwendig!

17 17 Hälfte des Weges geschafft!? Funktionsspezifikation Systemspezifikation

18 18 Integrationstests Was testen? Chips auf einem Board, chipinterne Komponenten. Wie testen? Generelle Probleme: Komplexe Schaltungen erfordern ausführliche Tests. Große Mengen von Testdaten, Probleme mit sequentiellen Schaltungen, Auswertung schwierig. Probleme auf Board-Ebene: Isolation von Chips vom Rest der elektronischen Schaltungen, Anlegen von Testmustern an die Pins der Testkandidaten. Probleme auf Chip-Ebene: Isolation von Komponenten, Anlegen von Testmustern an die internen Strukturen, eklatant schlechtes Verhältnis von verfügbaren Pins zu Anzahl der internen Komponenten.

19 19 Grundprinzip A B C D Out Exp / A B C D X Out Anlegen eines Musters, das es erlaubt, einen bestimmten Fehler zu aktivieren und auf einem Pfad zum Ausgang zu propagieren. Kontrollierbarkeit: Kann ich einen bestimmten Fehler (Controllability) aktivieren? Beobachtbarkeit: Kann der Fehler am Ausgang erfasst und (Observability) signalisiert werden? Vollständigkeit Wurden alle Zustände erfasst? (Coverage)

20 20 Coverage Kombinatorische Schaltung 0 Sequentielle Schaltung 2 n Testmuster 0 2 n+m Testmuster n n m Zustände

21 21 Allgemeines Vorgehen 1. Erzeugung der Testmuster, 2. Anwendung der Testmuster, 3. Beobachtung des Systemverhaltens und 4. Vergleich der Ergebnisse Vorteil der modellgetriebenen Softwareentwicklung ist die vereinfachte Generierung von Vergleichsdaten. Fehlerinjektion Simulation Ausgaben Eingaben Fehlerinjektion Target Ausgaben

22 22 Praktische Umsetzung Wie bringt man Testmuster an die Eingänge, wie erfasst man die Ausgangsdaten intuitive Antwort Bed of Nails

23 23 Boundary Scan JTAG Standard (IEEE 1149) int. logic int. logic Testdaten Testergebnisse

24 24 On-Chip Debugging with Atmel 2560 JTAG (IEEE std Compliant) Interface with access to: all Internal Peripheral Units Internal and External RAM Internal Register File Program Counter EEPROM and Flash Memories Extensive On-chip Debug Support for Break Conditions, Including AVR Break Instruction Break on Change of Program Memory Flow Single Step Break Program Memory Breakpoints on Single Address or Address Range Data Memory Breakpoints on Single Address or Address Range Programming of Flash, EEPROM, Fuses, and Lock Bits through the JTAG Interface On-chip Debugging Supported by AVR Studio

25 25

26 26 Vortragsankündigung

27 27 Danke für das große Interesse und die hohe Motivation!