Wietzke / Tran Automotive Embedded Systeme

Effizfientes Framework - Vom Design zur Implementierung
2005
ISBN: 978-3-540-28305-8
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 445 Seiten

Reihe: Xpert.press

Die Entwicklung hochkomplexer automotiver Infotainmentsysteme bestehend aus einer Headunit und weiteren Komponenten wie Audio- und Videoelementen, Kommunikationseinheiten, Navigationssystemen und Sensorik erfordert solides Domänenwissen und umfassendes Know-how im Software-Engineering. Das vorliegende Buch gibt eine fundierte Darstellung der softwareseitigen Implementierung dieser Komponenten innerhalb eines komplexen Frameworks. Im ersten Teil des Buches werden wichtige Grundlagen zu Eingebetteten Systemen und den für diese Systeme charakteristischen Methoden des Software-Engineerings vermittelt. Insbesondere werden dabei die Themen Speichermanagement und Systemperformance sowie grundlegende Mechanismen von Betriebssystemen betrachtet. Im zweiten Teil wird eine konkrete, objektorientierte Implementierung eines Frameworks dargestellt. Diese Implementierung zeigt die Umsetzung besonders effizienter Sychronisations- und Kommunikationsprozesse innerhalb einer kompakten und hochperformanten Systemarchitektur.

Herr Professor Wietzke leitet den Bereich Technische Informatik an der FH Darmstadt mit dem Schwerpunkt Eingebettete Systeme. Zuvor hat er in der Industrie bei Bosch, Blaupunkt und Harman/Becker verantwortlich im Bereich Radio/Navigationssysteme gearbeitet. Die Infotainment-Systeme, die sich im Maybach, im Audi A8, im Porsche, im BMW 5er und 7er, in der E-Klasse und einigen anderen Luxus-Limousinen befinden, enthalten seine Navigationssysteme.

Autoren/Hrsg.

Wietzke, Joachim

Tran, Manh Tien

Inhaltsverzeichnis

1;Vorwort;6
2;Inhaltsverzeichnis;8
3;Die Listings;16
4;Abbildungsverzeichnis;22
5;1 Einleitung;25
6;Teil I Bausteine eines Embedded Frameworks;29
6.1;2 Ein Infotainment-System;31
6.1.1;2.1 Die Headunit;32
6.1.2;2.1 Die Headunit;32
6.1.3;2.2 Geräte/Devices im System;33
6.1.4;2.3 Begriffsklärung: Was ist ein Framework;34
6.1.5;2.4 Fokus unserer Framework-Betrachtungen;35
6.2;3 Anforderungen an ein Embedded Automotive Framework;37
6.2.1;3.1 Verteilte Entwicklung;37
6.2.2;3.2 MVC, Organisationen;37
6.2.3;3.3 Speicheranforderungen;39
6.2.4;3.4 Startzeiten;39
6.2.5;3.5 Menüwechselzeiten;40
6.2.6;3.6 Konfiguration versus Dynamik;40
6.2.7;3.7 Datenfluss/Kontrollfluss/Zustandssteuerung;40
6.3;4 Betriebssysteme;41
6.3.1;4.1 Prozesse, Tasks, Threads;42
6.3.2;4.2 Der Scheduler;43
6.3.2.1;4.2.1 Präemptive Prioritätssteuerung;43
6.3.2.2;4.2.2 Round-Robin;43
6.3.2.3;4.2.3 Prioritäts-Inversion, Prioritäts-Vererbung;43
6.3.2.4;4.2.4 Task-Switch, Kontextwechsel;44
6.3.3;4.3 Zusammenspiel mit der MMU;44
6.4;5 Design-Rules und Konventionen;45
6.4.1;5.1 Namenskonventionen;46
6.4.2;5.2 Shared-Verzeichnisse, Libraries;46
6.4.3;5.3 Eigene Definitionen im Shared;46
6.4.3.1;5.3.1 Standard-Typen;46
6.4.3.2;5.3.2 Alignment;47
6.4.3.3;5.3.3 Little-Endian, Big-Endian;48
6.4.3.4;5.3.4 Zahlengrenzen;49
6.4.3.5;5.3.5 Const Definitionen;49
6.4.3.6;5.3.6 Eigene Assertions;50
6.4.3.7;5.3.7 Exceptions und Signale;51
6.4.3.8;5.3.8 Eigene Ausgaben;51
6.5;6 Speicherverwaltung;53
6.5.1;6.1 Statische Speicherverwaltung;55
6.5.2;6.2 Dynamische Speicherverwaltung;55
6.5.3;6.3 Start-Up-Strategien;57
6.5.4;6.4 Speicherbedarf und kleine Pittfalls;57
6.5.4.1;6.4.1 Welche Variable wo?;57
6.5.4.2;6.4.2 Alternative Strategie 1: Späte Konstruktion;60
6.5.4.3;6.4.3 Alternative Strategie 2: Späte Initialisierung;62
6.5.4.4;6.4.4 Alternative Strategie 3: Lokale statische Variablen;63
6.5.4.5;6.4.5 Speicherort von Konstanten;64
6.5.4.6;6.4.6 Speicherbedarf eines einfachen Objekts;67
6.5.4.7;6.4.7 Speicherbedarf eines einfachen Objekts mit virtueller Methode;68
6.5.4.8;6.4.8 Speicherbedarf eines Objekts einer abgeleiteten einfachen Klasse;70
6.5.4.9;6.4.9 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Methode;72
6.5.4.10;6.4.10 Speicherbedarf eines Objekts einer abgeleiteten Klasse mit virtueller Basis-Methode;74
6.5.4.11;6.4.11 Mehrfachvererbung und Pittfall;76
6.5.4.12;6.4.12 Speicherbedarf dynamischer Variablen;79
6.5.4.13;6.4.13 Schlechte Parameterübergabe;80
6.5.4.14;6.4.14 Probleme mit dem Kopierkonstruktor;81
6.5.4.15;6.4.15 Probleme mit dem Zuweisungsoperator;81
6.5.4.16;6.4.16 Schlechte Rückgaben;81
6.5.4.17;6.4.17 Padding-Probleme;83
6.5.4.18;6.4.18 Alignment-Probleme, Endian-Probleme;84
6.5.4.19;6.4.19 Speicherfragmentierung;84
6.5.4.20;6.4.20 Vektoren, STL;85
6.6;7 Embedded Speicherkonzepte, spezielle Muster;87
6.6.1;7.1 Statische Variablen;87
6.6.1.1;7.1.1 Reihenfolge der Konstruktoren;87
6.6.2;7.2 Quasi-statische Allokation aus festem Pufferspeicher;90
6.6.2.1;7.2.1 Anlegen eines statischen Puffers;91
6.6.2.2;7.2.2 Placement-new;91
6.6.2.3;7.2.3 Makros zur Allokation;92
6.6.3;7.3 Allokator;94
6.6.3.1;7.3.1 Statische Allokation;97
6.6.3.2;7.3.2 Dynamische Allokation mit temporärem Heap;99
6.6.3.3;7.3.3 Object-Pool-Allokation;102
6.6.4;7.4 Datencontainer;106
6.6.5;7.5 Gemeinsam benutzte Objekte (Shared-Objects);106
6.6.6;7.6 Referenzzähler (reference counting);107
6.6.7;7.7 Garbage-Collection;109
6.6.8;7.8 Die Captain-Oates Strategie;109
6.6.9;7.9 Speicherlimit;110
6.6.10;7.10 Partieller Fehler (Partial Failure);111
6.6.11;7.11 Fazit;111
6.7;8 Prozesse und POSIX-Threads;113
6.7.1;8.1 Prozesse;114
6.7.1.1;8.1.1 Der Lebenszyklus eines Prozesses;114
6.7.1.2;8.1.2 Prozesszustände;115
6.7.1.3;8.1.3 Zombies;116
6.7.1.4;8.1.4 Bestandteile;116
6.7.1.5;8.1.5 Prozess mit fork erzeugen;117
6.7.1.6;8.1.6 Prozess mit exec erzeugen;118
6.7.1.7;8.1.7 Prozess mit spawn erzeugen;120
6.7.1.8;8.1.8 Prozessvererbung;121
6.7.1.9;8.1.9 Prozessattribute;121
6.7.1.10;8.1.10 Über Prozessgrenzen hinweg;122
6.7.2;8.2 Threads;123
6.7.2.1;8.2.1 Erzeugung von POSIX-Threads;123
6.7.2.2;8.2.2 Allgemeine Gestaltung eines Threads in eingebetteten Anwendungen;124
6.7.2.3;8.2.3 Thread-Attribute;125
6.7.2.4;8.2.4 Über Threadgrenzen hinweg;128
6.7.2.5;8.2.5 Thread-spezifische Daten;130
6.7.2.6;8.2.6 Thread-Träger und Thread-Objekte;132
6.7.3;8.3 Designentscheidung;142
6.8;9 Inter-Prozess-Kommunikationskanäle, IPC;145
6.8.1;9.1 Pipe;145
6.8.2;9.2 FIFO, Named-Pipe;149
6.8.3;9.3 Socket, local;149
6.8.4;9.4 Socket-Verbindung zwischen Prozessoren;151
6.8.5;9.5 Message-Queues;158
6.8.5.1;9.5.1 System V Message-Queues;158
6.8.5.2;9.5.2 POSIX Message-Queues;158
6.8.6;9.6 QNX-Message;161
6.8.7;9.7 Shared-Memory;161
6.8.8;9.8 Shared-Memory gegen Überschreiben sch utzen;168
6.8.9;9.9 Zeitverhalten;173
6.8.10;9.10 Designentscheidung und prinzipielle Implementierung;174
6.9;10 Gemeinsame Nutzung von Code;175
6.9.1;10.1 DLLs;175
6.9.2;10.2 Shared-Code;175
6.9.3;10.3 Designentscheidung und prinzipielle Implementierung;176
6.10;11 Synchronisierungsmechanismen für Prozesse und Threads;177
6.10.1;11.1 Semaphore;177
6.10.2;11.2 Unbenannter Semaphor;181
6.10.3;11.3 Benannter Semaphor;184
6.10.4;11.4 Mutex, rekursiver Mutex;185
6.10.5;11.5 Mutex-Guard;191
6.10.6;11.6 Signale;192
6.10.7;11.7 Bedingungsvariablen (Condition Variables);192
6.10.8;11.8 Zeitverhalten;201
6.10.9;11.9 Deadlock, Livelock und Prioritätsinversion;201
6.10.10;11.10 Zusammenfassung;206
6.11;12 Kommunikation per Events;207
6.11.1;12.1 Wichtige Event-Typen;208
6.11.1.1;12.1.1 Signal-Events;208
6.11.1.2;12.1.2 Events mit Cookies;209
6.11.1.3;12.1.3 Call-Events;209
6.11.1.4;12.1.4 Timer-Events;209
6.11.1.5;12.1.5 Change-Events (Notifikation - Das Hollywood-Prinzip);210
6.11.2;12.2 Realisierungen von Events;210
6.11.2.1;12.2.1 Einfache Events;210
6.11.2.2;12.2.2 C-Strukturen;211
6.11.2.3;12.2.3 Funktionszeiger;213
6.11.2.4;12.2.4 Event-Klassen und Objekte;214
6.11.2.5;12.2.5 Zeiger auf Event-Objekte verschicken;216
6.11.2.6;12.2.6 Events am Beispiel von MOST;219
6.11.3;12.3 Designentscheidung und prinzipielle Implementierung;220
6.12;13 Event-Verarbeitung;221
6.12.1;13.1 Queues;221
6.12.1.1;13.1.1 Externe Queue;223
6.12.1.2;13.1.2 Interne Queue;228
6.12.1.3;13.1.3 System-Queue;229
6.12.1.4;13.1.4 Queue mit verbesserter Inversions-Eigenschaft;229
6.12.2;13.2 Dispatcher;235
6.12.2.1;13.2.1 Der System-Dispatcher;235
6.12.2.2;13.2.2 Der lokale Dispatcher;236
6.12.2.3;13.2.3 Signalisation im Dispatcher;237
6.12.2.4;13.2.4 Registrierung im Dispatcher;237
6.12.3;13.3 Synchrone Events;238
6.13;14 Zustandsautomaten;239
6.13.1;14.1 Motivation;239
6.13.2;14.2 Kommunikation;240
6.13.3;14.3 Automaten;241
6.13.4;14.4 Statechart-Elemente;241
6.13.5;14.5 Probleme mit Statecharts und Ersatzl osungen;245
6.13.6;14.6 Implementierung dynamischen Verhaltens;247
6.13.6.1;14.6.1 Definition der Events;248
6.13.6.2;14.6.2 Implementierung der Aktionen;249
6.13.7;14.7 Implementierung der Statecharts;250
6.13.7.1;14.7.1 Implementierung durch Aufzählung für Zustände und Unterzustände;250
6.13.7.2;14.7.2 Zustandsmuster (State-Pattern);255
6.13.7.3;14.7.3 Verbesserte Aufzählungsmethode;264
6.13.8;14.8 Implementierung nach Samek;270
6.14;15 Externer Kommunikationskanal: MOST-Bus;277
6.14.1;15.1 Der synchrone Kanal;278
6.14.2;15.2 Der asynchrone Kanal;279
6.14.3;15.3 Der Kontrollkanal;279
6.14.4;15.4 Geräte/Devices im Framework;279
6.14.4.1;15.4.1 Logische Geräte, Modelle;281
6.14.4.2;15.4.2 Methoden;282
6.14.4.3;15.4.3 Properties;282
6.14.4.4;15.4.4 MOST-Adressierung;283
6.14.4.5;15.4.5 Adressierungsbeispiele;289
6.14.4.6;15.4.6 MOST-Events, prinzipielle Dekodierung des Headers;290
6.14.4.7;15.4.7 MOST-Events, prinzipielle Dekodierung der Daten;292
6.14.4.8;15.4.8 MOST-Konstanten;293
6.14.4.9;15.4.9 MOST-Probleme;295
7;Teil II Das Framework;298
7.1;16 Das Framework;299
7.2;17 OS-Grundmechanismen;301
7.3;18 Komponentenarchitektur;303
7.3.1;18.1 Event-Handler und Event-Formate;305
7.3.2;18.2 Implementierung von Schnittstellen, Proxy und Handler;309
7.3.3;18.3 Komponentenarchitektur;311
7.3.3.1;18.3.1 Komponentenkontext und Daten im Shared-Memory;312
7.3.3.2;18.3.2 Erzeugung der Kontexte;319
7.3.3.3;18.3.3 Main-/Admin-Task;324
7.3.3.4;18.3.4 Signale, Mechanismen über den Kontext;326
7.3.3.5;18.3.5 Komponenten-Dispatcher;332
7.3.3.6;18.3.6 Softtimer und Timer-Manager;334
7.3.3.7;18.3.7 Registrierung;342
7.3.3.8;18.3.8 Die Basisklasse AComponentBase und das Zusammenspiel mit der Umgebung;343
7.3.4;18.4 Zusammenfassung;351
7.4;19 Main-Dispatcher-Komponente;355
7.4.1;19.1 Dispatcher-Receiver;355
7.4.2;19.2 Dispatcher-Main-Thread;360
7.5;20 Modell-Komponenten, logische Geräte;365
7.5.1;20.1 Aufgaben des logischen Geräts;366
7.5.2;20.2 Was erwartet die HMI von einem logischen Gerät?;367
7.5.3;20.3 Zustände des Geräts;369
7.5.4;20.4 Gültigkeit der Daten;370
7.5.5;20.5 Kommunikationsanforderung;371
7.5.6;20.6 Struktur eines logischen Geräts;371
7.5.7;20.7 Datencontainer versus Event-Prinzip;371
7.5.8;20.8 Architektur eines Datencontainers;373
7.5.8.1;20.8.1 Struktur des Datencontainers;374
7.5.8.2;20.8.2 Lesezugriffe der HMI;380
7.5.8.3;20.8.3 Versenden eines HMI-Befehls;381
7.5.8.4;20.8.4 Menge der erlaubten High-Level-Aktionen;382
7.5.8.5;20.8.5 Abstrakte Klasse ADataContainerAccessor;383
7.5.9;20.9 MOST-Codec;387
7.5.9.1;20.9.1 Vorbereitung;387
7.5.9.2;20.9.2 Einfache Implementierung eines MOST-Decoders;391
7.5.9.3;20.9.3 Objektorientierter Ansatz;394
7.5.9.4;20.9.4 Objekte zur Kompilierzeit;396
7.5.9.5;20.9.5 Konstante Objekte zur Dekodierung der MOST-Nachrichten;398
7.5.10;20.10 Zusammenfassung;411
7.6;21 HMI-Komponente;413
7.7;22 Persistenz-Controller und On/Off-Konzepte;415
7.8;23 Codegenerierung;419
7.8.1;23.1 Erstellen der XML-Eingabe-Dateien;419
7.8.2;23.2 Erzeugen des Quellcodes;421
7.8.3;23.3 Übersicht der erzeugten Dateien;422
7.8.4;23.4 Übersetzen des Quellcodes;428
7.9;24 Sonstige Aspekte;429
7.9.1;24.1 Internes non-MOST-Device, Beispiel Mediaplayer;429
7.9.2;24.2 Internes MOST-Device, Beispiel Tastatur;429
7.9.3;24.3 Treiber im Framework;430
7.9.4;24.4 Einfaches Debugging-Konzept;430
7.9.5;24.5 Überlastverhalten des Systems;432
7.9.6;24.6 Anmerkungen zur Komplexität und zum Testing;433
7.10;25 Anhang;435
7.10.1;25.1 Timer und Zeitmessung;436
7.10.1.1;25.1.2 Timeout;438
7.10.2;25.2 Socket;438
7.10.2.1;25.2.1 InetAddr;438
7.10.2.2;25.2.2 CSockAcceptor;439
7.10.2.3;25.2.3 CSockConnector;442
7.10.2.4;25.2.4 CSockStream;444
7.10.3;25.3 Keyboard;446
7.10.4;25.4 Shared-Memory;448
7.10.5;25.5 CBinarySemaphore;456
7.10.6;25.6 Extern const;463
8;Literatur;465
9;Index;467

Leseproben

4 Betriebssysteme

In frühen Embedded Systemen war kein Betriebssystem notwendig. Das Gerät basierte auf einer einfachen Hauptschleife, die nacheinander Bedienelemente abfragte und entsprechende Gerätefunktionen ansteuerte. Wegen zunehmender Funktionalitäten, sich ändernder Hardware-Plattformen und wegen der hohen Anforderungen an gefühlte Bedienbarkeit kam man bereits früh zur Notwendigkeit von Betriebssystemen, die eine scheinbare Parallelität erlaubten, so dass nun, wenn z.B. in einer Applikation auf eine Tastatureingabe gewartet wird, eine andere inzwischen weiterarbeiten kann. Betriebssysteme organisieren die

•  quasi parallele Abarbeitung verschiedener Prozesse oder Threads;
•  sie verwalten Hardware- und Software-Ressourcen;
•  sie kapseln und abstrahieren Hardware-Funktionen und Schnittstellen;
•  sie stellen zum Teil standardisierte Services zur Verfügung, wie z.B. Speicherverwaltung, Kommunikations-Schnittstellen, Lader, Fehlerroutinen, Synchronisations- und Kommunikationsmethoden. Im Zusammenhang mit der Framework-Diskussion im automotiven Umfeld sind gleichzeitig einige Betriebssysteme in der Diskussion. Diese Verknüpfung ist zunächst einmal unglücksselig, da die Begriffe Framework und Betriebssystem eigentlich verschiedene Schichten betreffen. Durch das Paket WinCE, das Betriebssystem und Framework fast untrennbar verbindet, kommt es zur Vermischung der Begriffe. Auch ein GUI-Builder (Graphical User Interface) wie Photon für QNX vermischt Framework und OS-Schichten.

Trotzdem sollten die weitgehend üblichen Betriebssysteme erwähnt werden.

Es sind: 
       VxWorks, das sehr erprobt und geeignet in der kleinen Multithread- Umgebung ist, für das es aber noch nicht viel Erfahrung in Multiprozess-Systemen gibt. In ähnlicher Weise ist I-Tron einzuordnen, das sehr häufig in japanischen Systemen eingesetzt wird.

Mit mächtigeren Prozessoren wie dem SH4 von Hitachi und dem Power- PC von Motorola und anderen kommen die Möglichkeit und die Forderung nach Multiprozess-OS auf. Hier greift im Moment QNX, dessen Entwicklungsumgebung (Momentics) allerdings speziell bei großen Projekten viele Schwächen haben. Die Stärken von QNX sind die Echtzeitorientierung und die POSIX-Konformität. WinCE kommt immer wieder in die Diskussion mit der Vorstellung eines Standards, genauso oft stellt sich aber auch heraus, dass die Verquickung von Framework und Betriebssystem bei WinCE von den Entwicklern nicht geliebt wird. Auch sind die Einschränkungen im Framework noch so groß, dass am Ende im Wesentlichen nur der OS-Teil genutzt und ein eigenes Framework drumherum implementiert wird. Dafür ist es dann aber zu aufwändig und teuer.

Die richtige Design-Entscheidung scheint deshalb hier zu sein, sich vom OS zu abstrahieren und mehrere Betriebssysteme zu unterstützen. Die vorgestellten Implementierungen werden deshalb in der Regel auf VxWorks, QNX und Windows lauffähig sein, dies zwingt auch wieder dazu, sich nicht zu sehr auf Spezialitäten nur eines Betriebssystems einzulassen. In späteren Kapiteln wird gezeigt, wie Programme wahlweise unter QNX, Windows und Linux laufen können, solange man sich bei der Auswahl der Betriebssystem-Mittel beschränkt. Deshalb werden wir hier auf Betriebssysteme nicht weiter eingehen, nur drei notwendige Begriffe kurz erläutern und später in den Implementierungsbeispielen von Betriebssystem-Funktionalität