S ys temanalys en und Debugging- Konzepte für Automotive Embedded S ys teme

Transkript

1 S ys temanalys en und Debugging- Konzepte für Automotive Embedded S ys teme Februar 2008 Referent: Prof. Dr. J.Wietzke Korreferent: Prof. Dr. K.Kasper

2 Inhalt 1. Einleitung Systembeschreibung Problemdarstellung 2. Systemanalysen und Debugging-Konzepte Fehlerkategorien und bereits bekannte Debugging- Werkzeuge Realisierung eigener Debbugging-Konzepte und Analyse-Tools 3. Fazit und Ausblick 2

3 1.1. Systembeschreibung - Hardware S chematische Darstellung der Geräte in einem Automotive E mbedded S ystem 3

4 1.1. Systemberschreibung Betriebssystem QNX Q uelle: Q NX Neutrino brochure 4

5 1.1. Systembeschreibung - Software ICM-Framework und Komponentenmodell - Komponente oder log. Device in einem eigenen Prozess - Kommunikation über Message-Queues im Shared Memory - Watchdog überwacht Komponenten mittels Trigger-Semaphore im Komponenten- Kontext 5

6 1.2. Problemdarstellung Kein Source-Debugging während der Laufzeit möglich Zeitliche Blockierung von Komponenten Zuordnung (Attach) zeitgleich nur zu einer Komponente (Prozess) möglich Verwendung von alternativen Debugging-Werkzeugen 6

7 Systemanalysen und Debugging-Konzepte 7

8 2.1. Fehlerkategorien und Debugging-Tools typische Laufzeitfehler in Embedded Systemen Logik Hängen/Einfrieren abnormale Terminierung Speicher Performance bereits bekannte Debugging-Werkzeuge Source-Debugger Code-Profiling-Tools der IDE System- und Prozess-Informationen: Analyse-Tools der IDE oder QNX-Konsolenprogramme Kernel-Event-Tracer, Memory-/Core-Dumping 8

9 2.3. Realisierung eigener Debugging- Konzepte und Analyse-Tools Umgehung der Verwendung der Analyse- und Debugging- Tools der IDE Komplexität Overhead Q NX Ins trumented Kernel, Q uelle: Q NX Mementics brochure Watchdog-Erweiterung innerhalb der zu testenden Software Monitorähnliche, leichtgewichtige Programme zur Erfassung von System- und Prozess-Informationen 9

10 Watchdog-Erweiterung Watchdog-Service: Überwachung der Komponenten innerhalb der zu testenden Software Ziel Watchdog-Erweiterung: Fehlerbehandlung einleiten 10

11 Watchdog-Erweiterung Bedingung: Zuordnung von applikationsinternen Komponenten-Namen zu PID/TID Erstellung einer Thread-Table innerhalb der Applikation ComponentName pid tid TunerComponent MainDispatcher MostIO_Thread

12 Watchdog-Erweiterung Mögliche Fehlerbehandlungs-Maßnahmen: Warnmeldung: Component XY hangs! (bisher) Fehlerursachen-Forschung Restart der hängenden Komponente (versteckter WD) System in Off-Zustand schalten (sichtbarer WD) 12

13 Watchdog-Erweiterung Bestimmung der Fehlerursache Terminierung oder Einfrieren/Hängen der Komponente? -> bei Terminierung: Auswertung des Corefiles mittels GDB Ist Komponente tatsächlich Fehlerverursacher? -> bei hängender Komponente: Überprüfung der prozessanteiligen CPU-Auslastungen Prozessinformationen abfragen (und/oder evtl. Kernel-Event- Trace starten) Terminierung der hängenden Komponente Auswertung Prozessinformationen (, Kernel-Trace) und Corefile 13

14 Watchdog-Erweiterung Bestimmung der prozessanteiligen CPU-Auslastung QNX-Konsolenprogramm hogs eigene Implementierung zur Messung der CPU- Auslastung 14

15 Watchdog-Erweiterung Prozessinformationen abfragen Konsolenprogramm pidin Kernel-Event-Trace: Overhead und Komplexität 15

16 Watchdog-Erweiterung Terminierung der hängenden Komponente Erzeugung eines Corefiles mit Memory-Dump bei abnormaler Terminierung und im Hintergrund laufenden Dumper Auswertung des Corefiles mittels GDB 16

17 Messung der Leerlauf-Leistung Realisierung als zyklisches Konsolen-Programm Verwendung von Clock-IDs CLOCK_REALTIME: Posix-Standarduhr CLOCK_MONOTONIC: System-Uhr Threadspezifische Clock-IDs Idle-Thread ist Main-Thread von Prozessmanager (Prozess 1) Verwendung der Funktion ClockTime: Liefert die Zeit in Nanosekunden, die der Thread bisher an CPU-Zeit zugeteilt bekommen hat 17

18 Messung der Leerlauf-Leistung Berechnung durch zyklischen Vergleich von zugeteilter CPU- Zeit zu einem Zeitintervall Leerlauf: idle =100 end idletime start idletime / end systemtime start systemtime Auslastung: load =100 end systemtime start systemtime end idletime start idletime / end systemtime start systemtime Erweiterung: Datensammlung und grafische Darstellung 18

19 2.3.3 Ermittlung von Systemund Prozess-Informationen Zyklische Ausgabe unter Verwendung des QNX- Konsolenprogramms pidin: 19

20 2.3.3 Ermittlung von Systemund Prozess-Informationen Alternativ: eigene Implementierung durch Auslesen des /proc-verzeichnisses Device-Control-Kommandos 20

21 Heap-Memory-Analyse Innerhalb der zu testenden Software realisiert, zeigt Prozess/Thread-abhängige Balance zwischen Allokationen und Deallokationen aktueller Verbrauch an dynamischen Speicher Gesamtanzahl Gesamtgröße bisher Gesamtanzahl Gesamtgröße bisher aktuelle Größe Name PID bisheriger TID Allocs angeforderter Speicher (in Byte) bisheriger De- Allocs zurückgegebener Speicher (in Byte) Heapsegment (in Byte) HMI Grafic_Thread *... Erweiterung der Thread-Table Überladung der new/delete-operatoren und einfache Verwendung der Malloc-Debug-Library: mallinfo 21

22 3. Fazit und Ausblick Umgehung der komplexen Debug- und Analyse-Tools der Entwicklungsumgebung Watchdog-Erweiterung: liefert mind. Anhaltspunkt für Fehlerursache zukünftig: prozess- und interessensabhängige Auswertung Kernel-Trace Erweiterbarkeit der eigenen Analyse-Programme 22

23 Vielen Dank für Ihre Aufmerks amkeit! Noch Fragen? 23