Wie man Software durch Prüfung von Invarianten zuverlässiger macht

25. August 2009, 10:37 Uhr | Stephan Grünfelder
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Wie man Software durch Prüfung von Invarianten zuverlässiger macht

In diesem Fall kann man sich ein eigenes Assert-Makro schreiben, das immer übersetzt wird. Es sichert wichtige Systemparameter zur Diagnose des Fehlers und führt das System dann in den sicheren Abschaltzustand. Auch hybride Designs sind denkbar, wenn keine Gefährdung von einem unerwarteten Programmfehler ausgeht, aber trotzdem hohe Anforderungen an die Software-Integrität vorliegen. Solche Systeme sind etwa Erdbeobachtungs-Satelliten. Sind die Daten des künstlichen Erdtrabanten falsch, so ist dadurch niemand in Gefahr. Eine Weltraum-Mission kostet etliche Millionen Euro, die Erwartungshaltung an die Güte der Daten ist also sehr hoch, obwohl die Gefahr eines Bitkippers im RAM oder eines vorübergehenden CPU-Fehlers im Orbit besonders hoch ist. Die Software muss also robust gegen solche strahlungsbedingten Fehlerquellen sein. Typischerweise ist daher missionskritische Software gespickt mit Zusicherungen, die die verschiedenen Fehlertypen – je nach Beschaffenheit des Fehlers – unterschiedlich behandeln:

  • Fehler selbstständig korrigieren, aber die Bodenstation über die Korrektur informieren;
  • autonom einen Neustart vornehmen und dabei Post-Mortem-Information zur Erde senden;
  • das System anhalten und in einem „gesicherten Modus“ auf weitere Instruktionen von der Bodenstation warten.

passend zum Thema

Die meisten Fehler lassen sich einer der folgenden drei Klassen zuordnen:

  • erkannte unplausible Daten, die selbstständig korrigiert werden konnten (z.B. durch Polynom-Codes oder erneute Datenübertragung nach einem Paritätsfehler);
  • erkannte Fehler, die nicht korrigiert werden können, die aber durch einen Neustart beseitigt werden können (z.B. irreparabler Datenfehler durch temporäre Über-/Unterspannung);
  • erkannte schwere Fehler, die auch durch einen Neustart nicht behoben werden können (z.B. wenn ein RAM-Test einen Adressierungsfehler findet).

Die wenigsten eingebetteten Systeme werden, wie der Satellit, ein Team von Fachkräften haben, das Tag und Nacht die Daten der Firmware überwacht. Wenn Ihr System auch keine „Bodenstation“ hat, die darauf wartet, Daten der Firmware zu analysieren, so könnten Sie doch im Wartbarkeits-Design daran denken,

  • über ein Modem eine SMS an eine Wartungs-Hotline zu senden,
  • für das Service-Personal einen Eintrag in einen nicht-flüchtigen Speicher zu machen,
  • den Benutzer mit einer Meldung auf die Fehlersituation aufmerksam zu machen.

Für die Erkennung dieser Situationen, wie gesagt, bieten sich Zusicherungen an.

Datenkapselung und Maskierung von Fehlern

Nun steht sauberes Software-Design – Stichwörter „Datenkapselung“, „Kohäsion“, „Modularität“ – im Widerspruch zur Testbarkeit im eingangs definierten Sinn. Moderne Programmiersprachen unterstützen den Programmierer weitgehend im sauberen Design, etwa durch Objektorientiertheit. Objektorientiertes Design macht einen Software-Test von Natur aus schwerer, weil der Zugriff auf interne Daten im Regelfall verwehrt bleibt. Die Maskierung von Fehlern wird also begünstigt, und beim Modultest muss man sich mit Tricks behelfen [4].

Umso wichtiger ist es daher bei objektorientiertem Design, bei Software mit hohem Integritätsanspruch, innerhalb der OO-Klassen Zusicherungen für diese versteckten Größen anzubringen.

Bjarne Stroustrup, Erfinder von C++, meinte in einem Interview [2], dass man bei Klassen nur dann Attribute für die Außenwelt unsichtbar machen sollte, wenn man deren Gültigkeit durch Invarianten prüfen kann. Eine Invariante ist eine Formel, die angibt, ob das Objekt gültig ist. In diese Formel finden die Werte der (versteckten) Attribute des Objekts Eingang. Im Falle einer Klasse, die besetzte und freie Speicherpartitionen eines Dual-Port-RAM verwaltet, könnte dies zum Beispiel die Summe der besetzten und freien Partitionen sein. Die muss immer konstant sein. Ist dies nicht der Fall, dann stimmt etwas nicht.


  1. Wie man Software durch Prüfung von Invarianten zuverlässiger macht
  2. Testbarkeit und Robustheit
  3. Wie man Software durch Prüfung von Invarianten zuverlässiger macht
  4. Wie man Software durch Prüfung von Invarianten zuverlässiger macht
  5. Wie man Software durch Prüfung von Invarianten zuverlässiger macht

Jetzt kostenfreie Newsletter bestellen!