Softwareentwicklung eingebetteter Systeme
Grundlagen, Modellierung, Qualitätssicherung
Published on 30. November 2005
XII, 232 pages
978-3-540-27522-0 (ISBN)
Description
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.
More details
Other editions
Additional editions
Book
04/2005
Springer
€56.99
Shipment within 10-15 days
Content
Einleitung.- Motivation.- Klassifikation, Charakteristika.- Anwendungen, Beispiele und Branchen.- Begriffsdefinitionen.- Besondere Herausforderungen.- Nebenläufige Systeme.- Echtzeit und Echtzeitbetriebssysteme.- Echtzeitsysteme.- Ereignissteuerung versus Zeitsteuerung.- Aufbau und Aufgaben von Betriebssystemen.- Scheduling.- Beispiele für Echtzeitbetriebssysteme.- Programmierung eingebetteter Systeme.- Der Einsatz von C++ für eingebettete Systeme.- Der Einsatz von Java für eingebettete Systeme.- Ereignisbasierter Ansatz am Beispiel Esterel.- Zeitgesteuerter Ansatz am Beispiel Giotto.- Softwareentwurf eingebetteter Systeme.- Statecharts.- Die Unified Modelling Language (UML).- Hybride Systeme und hybride Automaten.- Hardware Software Co-Design.- Sicherung der Softwarequalität eingebetteter Systeme.- Motivation und Begriffe.- Zuverlässigkeit, Verfügbarkeit, Sicherheit, Risiko.- Risikomanagement.- Qualitätsmodelle.-Softwaremetriken.- Testen.- Manuelle Prüftechniken.- Verifikation
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.
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.
