Scholz Softwareentwicklung eingebetteter Systeme

Grundlagen, Modellierung, Qualitätssicherung
2005
ISBN: 978-3-540-27522-0
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 240 Seiten

Reihe: Xpert.press

Eingebettete Systeme übernehmen komplexe Steuerungs- und Regelungsaufgaben für technische Systeme. Ihre Funktionalität wird durch das Zusammenspiel von Spezialhardware, Standardprozessoren, Peripherie und Software realisiert. Oft liegt der Schwerpunkt auf Hardware-Aspekten. Tatsächlich spielt der Softwareentwurf eine mindestens genauso wichtige Rolle beim Entwurf dieser Systeme. Hier setzt das Buch an und liefert einen guten Überblick über das Thema. Klassifikationen und Themen wie Nebenläufigkeit, Echtzeit und Echtzeitbetriebssysteme bilden die Grundlagen. Die Programmierung eingebetteter Systeme wird mit C++, Java sowie an den Beispielen von Esterel und Giotto erläutert. Ausgewählte Softwareentwurfstechniken wie Statecharts, hybride Systeme, UML und Hardware-Software Co-Design werden ausführlich vorgestellt. Eingebettete Systeme finden oft in sicherheitskritischen Bereichen Einsatz. Die Sicherung der Softwarequalität ist daher von zentraler Bedeutung und bildet einen weiteren wichtigen Teil des Buches.

Autoren/Hrsg.

Scholz, Peter

Inhaltsverzeichnis

1;Vorwort;6
2;Inhaltsverzeichnis;10
3;1 Einleitung;14
3.1;1.1 Motivation;14
3.2;1.2 Klassifikation, Charakteristika;16
3.3;1.3 Anwendungen, Beispiele und Branchen;19
3.4;1.4 Begriffsdefinitionen;21
3.5;1.5 Logischer Aufbau eingebetteter Systeme;23
3.5.1;1.5.1 Kontrolleinheit;25
3.5.2;1.5.2 Regelstrecke;28
3.5.2.1;1.5.2.1 Peripherie;29
3.5.2.2;1.5.2.2 Digital/Analog-Wandler;30
3.5.2.3;1.5.2.3 Analog/-Digital-Wandler;31
3.5.2.4;1.5.2.4 Sensoren;32
3.5.2.5;1.5.2.5 Aktuatoren;34
3.5.3;1.5.3 Benutzerschnittstelle;34
3.6;1.6 Softwareentwicklung eingebetteter Systeme;35
3.6.1;1.6.1 Motivation;35
3.6.2;1.6.2 Begriffsklärung;36
3.6.3;1.6.3 Entwurf;36
3.7;1.7 Besondere Herausforderungen;37
3.8;1.8 Zusammenfassung;38
4;2 Nebenläufige Systeme;40
4.1;2.1 Einführung;41
4.1.1;2.1.1 Multitasking;42
4.1.2;2.1.2 Multithreading;42
4.1.3;2.1.3 Prozesssynchronisation und -kommunikation;44
4.2;2.2 Grundlegende Modelle für die Nebenläufigkeit;45
4.3;2.3 Verteilte Systeme;47
5;3 Echtzeit, Echtzeitsysteme, Echtzeitbetriebssysteme;52
5.1;3.1 Echtzeitsysteme;52
5.2;3.2 Ereignissteuerung versus Zeitsteuerung;54
5.3;3.3 Echtzeitbetriebssysteme;55
5.3.1;3.3.1 Aufbau und Aufgaben von Betriebssystemen;56
5.3.2;3.3.2 Betriebssystemarchitekturen;57
5.3.3;3.3.3 Echtzeitfähige Betriebssysteme;58
5.3.4;3.3.4 Zeitgeber und Zugriffsebenen auf Zeit;63
5.3.5;3.3.5 Prozesse;66
5.3.6;3.3.6 Multitasking und Scheduling;67
5.3.7;3.3.7 Scheduling in Echtzeitbetriebssystemen;70
5.3.8;3.3.8 Speicherverwaltung;72
5.4;3.4 VxWorks als Beispiel eines Echtzeitbetriebssystems;74
5.4.1;3.4.1 Das Laufzeitsystem;76
5.4.2;3.4.2 Exkurs: Der POSIX Standard;76
5.4.3;3.4.3 Das I/O-Subsystem von VxWorks;77
5.4.4;3.4.4 Unterstützung verteilter Systeme in VxWorks;77
5.4.5;3.4.5 VxWorks Entwicklungswerkzeuge;77
5.5;3.5 Weitere Beispiele eingebetteter Betriebssysteme;79
5.5.1;3.5.1 Symbian OS;80
5.5.2;3.5.2 Palm OS;81
5.5.3;3.5.3 Windows CE;82
5.5.4;3.5.4 QNX;83
5.5.5;3.5.5 Embedded Linux;85
5.6;3.6 Zusammenfassung;86
6;4 Programmierung eingebetteter Systeme;88
6.1;4.1 Der Einsatz von C/C++ für eingebettete Systeme;90
6.2;4.2 Embedded C++;91
6.2.1;4.2.1 Einschränkung: Das Schlüsselwort „mutable“;93
6.2.2;4.2.2 Einschränkung: Ausnahmebehandlung;93
6.2.3;4.2.3 Typidentifikation zur Laufzeit;94
6.2.4;4.2.4 Namenskonflikte;94
6.2.5;4.2.5 Templates;94
6.2.6;4.2.6 Mehrfachvererbung und virtuelle Vererbung;94
6.2.7;4.2.7 Bibliotheken;95
6.2.8;4.2.8 EC++ Styleguide;95
6.3;4.3 Der Einsatz von Java für eingebettete Systeme;96
6.3.1;4.3.1 Java 1;98
6.3.1.1;4.3.1.1 Personal Java;98
6.3.1.2;4.3.1.2 Embedded Java;99
6.3.2;4.3.2 Java 2 (J2ME);100
6.3.2.1;4.3.2.1 Connected Device Configuration (CDC);101
6.3.2.2;4.3.2.2 Connected Limited Device Configuration (CLDC);102
6.3.3;4.3.3 JavaCard;103
6.3.4;4.3.4 Echtzeiterweiterungen für Java;106
6.3.4.1;4.3.4.1 Real- Time Core Erweiterung;108
6.3.4.2;4.3.4.2 Real Time Specification for Java (RTSJ);108
6.3.5;4.4 Synchrone Sprachen;111
6.3.6;4.5 Ereignisbasierter Ansatz am Beispiel von Esterel;112
6.3.6.1;4.5.1 Historie;113
6.3.6.2;4.5.2 Hypothese der perfekten Synchronie;113
6.3.6.3;4.5.3 Determinismus;117
6.3.6.4;4.5.4 Allgemeines;118
6.3.6.5;4.5.5 Parallelität;119
6.3.6.6;4.5.6 Deklarationen;119
6.3.6.7;4.5.7 Instruktionen;122
6.3.6.8;4.5.8 Beispiel: Die sogenannte ABRO-Spezifikation;124
6.3.6.9;4.5.9 Semantik;124
6.3.6.10;4.5.10 Kausalitätsprobleme;125
6.3.6.10.1;4.5.10.1 Logische Korrektheit;126
6.3.6.10.2;4.5.10.2 Konstruktive Semantik;128
6.3.6.11;4.5.11 Codegenerierung und Werkzeuge;129
6.3.7;4.6 Synchrone Datenflusssprachen am Beispiel von Lustre;131
6.3.7.1;4.6.1 Datenfluss und Clocks;132
6.3.7.2;4.6.2 Variablen, Konstanten und Gleichungen;133
6.3.7.3;4.6.3 Operatoren und Programmstruktur;133
6.3.7.4;4.6.4 Assertions (Zusicherungen);135
6.3.7.5;4.6.5 Compilation;135
6.3.7.6;4.6.6 Verifikation und automatisches Testen;137
6.3.7.7;4.6.7 Lustre im Vergleich zu Signal;138
6.3.8;4.7 Zeitgesteuerter Ansatz am Beispiel von Giotto;138
6.3.9;4.8 Zusammenfassung;149
7;5 Softwareentwurf eingebetteter Systeme;152
7.1;5.1 Modellierung eingebetteter Systeme;153
7.2;5.2 Formale Methoden;154
7.3;5.3 Statecharts;155
7.4;5.4 Die Unified Modeling Language (UML);158
7.5;5.5 Der Ansatz ROOM;164
7.5.1;5.5.1 Softwarewerkzeuge und Umgebung;164
7.5.2;5.5.2 Einführung;165
7.5.3;5.5.3 Echtzeitfähigkeit;167
7.6;5.6 Hardware/Software-Codesign;168
7.7;5.7 Die MARMOT-Methode;174
7.8;5.8 Hybride Systeme und hybride Automaten;177
7.8.1;5.8.1 Einleitung;177
7.8.2;5.8.2 Spezifikation hybrider Systeme;180
7.9;5.9 Zusammenfassung;184
8;6 Softwarequalität eingebetteter Systeme;186
8.1;6.1 Motivation;186
8.2;6.2 Begriffe;187
8.3;6.3 Zuverlässigkeit eingebetteter Systeme;191
8.3.1;6.3.1 Konstruktive Maßnahmen;195
8.3.1.1;6.3.1.1 Einsatz redundanter Hardware;195
8.3.1.2;6.3.1.2 Einsatz redundanter Software;196
8.3.2;6.3.2 Analytische Verfahren;197
8.3.3;6.3.3 Stochastische Abhängigkeit;199
8.3.4;6.3.4 Gefahrenanalyse;199
8.4;6.4 Sicherheit eingebetteter Systeme;201
8.4.1;6.4.1 Testen;203
8.4.1.1;6.4.1.1 Überblick;203
8.4.1.2;6.4.1.2 Ausgewählte Testverfahren;204
8.4.2;6.4.2 Manuelle Prüftechniken;208
8.4.3;6.4.3 Formale Verifikation;209
8.5;6.5 Zusammenfassung;212
9;7 Vorgehensmodelle und Standards der Entwicklung;214
9.1;7.1 Das Wasserfall-Modell;214
9.2;7.2 Das V-Modell;215
9.3;7.3 Das V-Modell XT;218
9.3.1;7.3.1 Grundlagen;219
9.3.2;7.3.2 Anwendung des V-Modell XT;220
9.3.3;7.3.3 Zielsetzung und Aufbau des V-Modell XT;221
9.3.3.1;7.3.3.1 V- Modell XT als Weiterentwicklung des V-Modells 97;222
9.3.3.2;7.3.3.2 Zielsetzung des V-Modells XT;223
9.3.3.3;7.3.3.3 Grenzen des V-Modells XT;223
9.3.4;7.3.4 V-Modell XT Produktvorlagen;224
9.3.5;7.3.5 V-Modell XT Werkzeuge;224
9.3.5.1;7.3.5.1 Der V- Modell XT Projektassistent;225
9.3.5.2;7.3.5.2 V- Modell XT Editors;225
9.4;7.4 Die ROPES-Methode;225
9.5;7.5 Der OSEK-Standard;226
9.6;7.6 AUTOSAR;228
9.7;7.7 Zusammenfassung;230
10;8 Schlussbemerkungen;232
11;Literaturverzeichnis;236
12;Sachverzeichnis;242

Leseproben

6 Softwarequalität eingebetteter Systeme (S.173)

Der Qualität von eingebetteter Software eine besondere Bedeutung zuzumessen, ist eine lohnenswerte Investition. Dies belegen zahlreiche Beispiele, bei denen fehlerhafte Software zu Schädigungen von Maschinen oder gar Menschen geführt hat. Einige prominente Fälle, wo Softwarefehler zu massiven Konsequenzen geführt haben, schildern wir daher in diesem Kapitel, bevor wir dann zentrale Begriffe der Softwarequalität diskutieren. Um die Softwarequalität überprüfen zu können, sind spezielle Prüftechniken erforderlich. Wir geben zunächst eine Übersicht über derzeit mögliche Prüftechniken und schildern dann ausgewählte Vertreter etwas näher. 

  Die Qualitätssicherung eingebetteter Systeme, gerade auch in der Automobiltechnik oder Avionik ist eine schwierige aber gleichwohl dringend erforderliche Entwicklungsaufgabe. Nach diesem Kapitel sollte der Leser die beiden Begriffe Zuverlässigkeit und Sicherheit sowie die damit in Bezug stehenden Begriffe verstanden haben und Verfahren zu ihrer Herstellung kennen.

6.1 Motivation

Ein „eindrucksvolles" Beispiel für einen Softwarefehler ist die Bruchlandung eines Airbus A-320 auf dem Warschauer Flughafen am 14. September 1993: Ein Lufthansa-Airbus fängt bei der Landung in Warschau Feuer. Bei dem Unfall sterben zwei Menschen, 54 werden verletzt. Ursache war eine Fehlkonstruktion des Sensors zur Erkennung der Bodenberührung: Im „Flight Mode" ließ sich die zum Bremsen notwendige Schubumkehr nicht einschalten. Hier handelte es sich um keinen Pilotenfehler, sondern 6 um falsche Entwurfsentscheidungen der Konstrukteure und Software-Ingenieure.

Ein anderes Beispiel, wo ein Softwarefehler beinahe zu einer Katastrophe geführt hatte, war die Landung einer in einer „Sojus"- Kapsel zurückgekehrten ISS-Mannschaft im Jahre 2003. Nach russischen Angaben führte ein Softwarefehler zu einem absturzartigen Wiedereintritt, bei dem ein vom Computer falsch berechneter Eintrittswinkel zu einer übermäßigen Hitzeentwicklung geführt hat. Einer der wohl bekanntesten Repräsentanten für mangelnde Softwarequalität ist der Absturz bzw. die ferngelenkte Zerstörung der europäischen Trägerrakete Ariane 5 auf ihrem Jungfernflug am 4. Juni 1996 in Kourou. Die Rakete war mit vier Satelliten bestückt. Etwa 37 Sekunden nach dem Start erreichte die Ariane 5 eine Horizontalgeschwindigkeit von mehr als 32.768 internen Einheiten. Die in der Programmiersprache Ada realisierte Konvertierung dieses Wertes in eine vorzeichenbehaftete Integer-Variable führte daher zu einem Überlauf, der nicht abgefangen wurde, obwohl die Hardware redundant ausgelegt war. Da es sich hier jedoch um einen reinen Softwarefehler handelte, blieb diese Redundanz wirkungslos.

Folglich wurden Diagnosedaten zum Hauptrechner geschickt, die dieser als Flugbahndaten interpretierte, so dass dieser unsinnige Steuerbefehle generierte. Die Rakete drohte daraufhin zu bersten und musste ferngelenkt gesprengt werden, um größeren Schaden aufgrund der noch niedrigen Höhe zu vermeiden. Interessanterweise war die Software von der Ariane 4 wiederverwendet worden und hatte dort auch problemlos funktioniert. Der Gesamtschaden belief sich auf 500 Millionen US-Dollar.