by Dipl. Ing. Frank Gerlach(frankgerlach.tai@gmx.de)
Stand vom 1.12.2025
Software nimmt in der modernen Welt immer mehr wichtige Rollen ein. Die korrekte Funktion hat vielfach lebenswichtige Bedeutung. Fehler können Menschenleben kosten. Folglich müssen Software-Ingenieure Antworten auf diese Herausforderungen finden. Beispiele dafür sind Fluglageregelung, ABS, Finanzsoftware, Eisenbahnsignalsysteme, Verschlüsselungstechnik. Diese Seite führt einige wichtige Ansätze auf.
Jäger 90/Eurofighter - braucht Software-Fluglageregelung, um auch nur geradeaus zu
fliegen. Grund: instabile Aerodynamik ermöglicht minimale Kurvenradien.
ABS: Anti-Blockier-System - Bremsvorgang durch Software geregelt. Ermöglicht
maximale, kontrollierte Notbremsleistung ohne Schleudern des KFZ oder
des Luftfahrzeugs auf der Landebahn.
European Train Control System - Software sichert Zugfahrt und ermöglicht Hochgeschwindigkeitsfahrt.
Wehen- und Herzschlagschreiber(Kardiotokograf) überwacht den kindlichen Herzschlag und
die Wehentätigkeit der Mutter. Software macht die Signalverarbeitung zur
Extraktion des schwachen Kinderherzschlags "unter" dem starken Herzschlag der Mutter.
FADEC - Full Authority Digital Engine Control: ein digitales, Software-getriebenes
Steuergerät interpretiert die Eingabe des Piloten und setzt sie in sichere
Treibstoffraten, Klappenstellungen usw, um. Weitere Eingaben kommen von Sensoren im
Triebwerk selbst. FADEC "managt" das Triebwerk, verhindert Überhitzung und hat
besonders beim Anfangssteigflug in mindestens 1000m über Grund eine lebenswichtige
Funktion für hunderte Passagiere und Flieger. Durch FADEC wird mindestens
ein Flugingenieur eingespart sowie ökonomisch und sicher geflogen.
Vielfach wird Software von informell und damit unzureichend ausgebildeten Entwicklern erstellt. Dies führt dann zu Algorithmen und Datenstrukturen, welche weit hinter dem Stand der Informatik- Wissenschaft zurückbleiben. Die Folge sind Sicherheitslücken, unnötige Laufzeit und Speicherbedarf sowie fehlerhafte Programmfunktion; "Anfängerfehler".
Viele Informatik-Probleme können abstrakt als Verarbeitung von Dateien durch Scanner und Parser aufgefasst werden. Dies ermöglicht die Nutzung mächtiger und gut erforschter Theorien(Scanner, Parser, Compiler, EBNF). Dabei braucht es nicht zwingend den Einsatz von Generatoren(lex, yacc, ANTLR usw.), sondern ein Grundverständnis für die Definition der Syntax und Grammatik von Dateien bzw. Netzwerkprotokollen. Handprogrammierte Scanner und Parser können extrem robust sein.
Ein sehr gefährliches Entwicklungsmuster, welches dem Angreifer mächtige und sehr schwer einschätzbare Eingriffsmöglichkeiten gibt. Aus diesem Grund sollte dieses Muster nur für interne Speicherung oder Übertragung eingesetzt werden.
Grammatiken sollten nur in absoluten Ausnahmefällen Turing-vollständig sein (z.B. Web-programmierung mit JavaScript oder Office-Makroprogrammierung), weil auch damit einem Angreifer quasi alle Tore offen- stehen. Turing-vollständige Datenstrukturen sind tatsächlich Programme und müssen unter sehr restriktiven Sicherheitsprüfungen ("Sandboxing") ausgeführt werden.
Überall in der Technik gilt, dass Systeme so einfach wie irgend möglich strukturiert sein sollten. Dies ermöglicht es dem Ingenieur und dem Wissenschafter, Seiteneffekte, Fehlerzustände und Fehlerpotential abzuschätzen. Zudem wird eine vollständige Testabdeckung möglich. Dies wird durch das Akronym KISS("Keep It Simple and Stupid") zusammengefasst.
Das V-Modell ist ein systematischer, strukturierter Ansatz zur Systementwicklung. Alle Anforderungen werden erfasst, eine Architektur davon abgeleitet und dann erst Module entwickelt. Ebenso wird auf verschiedenen Ebenen getestet, ob die Anforderungen alle eingehalten werden. Siehe auch ASPICE/ISO26262 in der KFZ-Entwicklung, DO-178 in der Luftfahrt, EN 50128 bei der Eisenbahn, IEC 62304 in der Medizintechnik.
Speichersichere Programmiersprachen wie Rust, Sappeur, Java, C#, Go können etwa 70% aller CVE-Exploits neutralisieren. Zudem melden sie während einer gründlichen Testphase die meisten Speicherfehler, anstatt den Speicher verdeckt zu beschädigen und schwer lokalisierbare Fehlerzustände zu erzeugen.
Starke Typisierung fördert viele Programmierfehler zum Zeitpunkt des Compilerlaufs zutage. Dies ist aus dem Gesichtspunkt der Sicherheit und Zuverlässigkeit immer zu bevorzugen. Damit scheiden viele "dynamisch typisierte" Sprachen wie JavaScript, Smalltalk, Perl, Python oder PHP aus. Empfehlenswert sind: Rust, Sappeur, TypeScript, Spark Ada, Modula-2, Java, C#.
Die Struktur eines Software-Systems("Architektur") muss dem zu lösenden technischen, physikalischen, chemischen, biologischen, finanziellen Problem angepasst sein. Die Erstellung einer solchen Architektur erfordert Software-Ingenieure mit Informatik-Grundausbildung und jahrzehntelanger Berufserfahrung.
| Name des Systems | Problem | Verbesserungsmöglichkeiten |
|---|---|---|
| 1. Unix Kernel | 1. Keine Speichersicherheit(Sprache C) 2. Zuviele Subsysteme im Kernel 3. Eine einzige Sicherheitslücke ermöglicht i.d.R. die vollständige Systemübernahme. |
A) Speichersichere Programmiersprache im Kernel(z.B.
Singularity OS,
Unisys MCP oder
Oberon OS) oder
B) Mikrokernel(z.B. seL4) |
| 2. Microsoft Windows | Ähnlich Unix-Kernel, nur noch schlimmer | siehe Unix Kernel |
| 3. SSL/TLS (Secure Sockets Layer) | 1. Enorme Komplexität (500 000 Zeilen C-Code), nicht-KISS 2. Keine speichersichere Sprache(C) 3. Mehrfache, katastrophale Sicherheitslücken bekannt geworden(z.B. HEARTBLEED) |
A) Trennung von Schlüsseltausch und Regelbetrieb(z.B.
MST) B) Rein symmetrische, einfache Verfahren wie Kryptomittel-Verteiler-Zentrale C) Speichersichere Programmiersprache nutzen |
| 4. Boeing MCAS | Anfängerfehler in der Auswertung der Anströmungs-Winkel-Sensoren. Sensor-Messwerte der zwei vorhandenen Sensoren wurden nicht gegeinander geprüft und damit der Sensorausfall nicht erkannt. Das V-Modell wurde offensichtlich nicht durchgeführt, sonst wäre bei einem Testfall auf Systemebene(HIL Test) der Konzeptionsfehler erkannt worden. | V-Modell tatsächlich exekutieren und ehrliche Testfälle, einschliesslich Sensorausfall, programmieren. |
| 5. Ariane V Erstflug | Überlauf einer Variable aufgrund höherer Beschleunigung in der größeren Rakete(nach Übernahme der Software aus Ariane IV) | Ausreichende System-/HIL-Test programmieren und durchführen. V-Modell ehrlich realisieren. |
| 6. V-22 Osprey | Mehrfache Abstürze des Senkrechtstarters aufgrund unreifer Software und anderer unreifer Systemkomponenten. Gewaltsame, übereilte Inbetriebnahme durch das U.S. Marine Corps. Mehr als 40 Tote ohne Feindwirkung. |
|
| 7. Boeing 767-300ER FADEC | Lauda Air Flight 004: Die Schubumkehr, welche vom FADEC kontrolliert wird, wurde bei großer Geschwindigkeit und Flughöhe ausgeführt. Möglicherweise ist dies auf einen Fehler in der FADEC-Software zurückzuführen. Folge war ein Strömungsabriss und anschliessender Sturzflug, welcher Leitwerke, Flügel und dann auch Rumpf mechanisch zerstörte. Vollständiger Verlust aller Insassen und des Fluggeräts. | Wegen unklarer Ursache schwer zu bestimmen. Möglicherweise V-Modell nicht ausreichend befolgt. |
| 8. Airbus A320-Familie ELAC | Der ELAC ist ein Rechner, welcher für die Ansteuerung von Höhen- und Querruder zuständig ist. Beim Flug 1230 von JetBlue kam es vermutlich durch Partikelstrahlung eines Sonnensturms zum Umkippen von mindestens einem Bit in einer wichtigen ELAC- Variable. Daraufhin kommandierte der ELAC einen Sinkflug. | Die vorhandenen Software-Entwickungsprozesse nach Do-178 und ARP4754 müssen erweitert werden: Jede operative Luftfahrt-/Raumfahrt-Hardware-Software-Kombination muss durch eine Strahlungsprüfung validiert werden. Dazu wird das Steuergerät im HIL-Test-Modus vor einen passenden Teilchenbeschleuniger(soll die Effekte des Sonnenwinds nachstellen) platziert und das Verhalten des Steuergeräts beobachtet. Durch eine vielfach höhrere Strahlungleistung kann die Prüfung in wenigen Tagen durchgeführt werden, da die höhere Leistung die Bitkipper wesentlich wahrscheinlicher macht. |
Statische Analyse von Quellcode kann einige Arten von Programmierfehlern unter idealen Umständen finden. So können unter idealen Umständen Indexfehler und arithmetische Überläufe vor dem Programmlauf erkannt werden. Auch wenn dies keine Patentlösung ist, stellt die statische Analyse ein wichtiges Werkzeug in der Systementwicklung dar. Beispiele sind PC-Lint, Coverity, PolySpace.
Durch radioaktive Strahlung, elektromagnetische Felder(z.B. von einem Radiosender), durch Alterung, chemische Korrosion, Vibration oder durch Hitze und Kälte können digitale System außer Tritt gebracht werden. Bei den oben genannten lebenswichtigen Systemen muss dies natürlich ausgeschlossen werden. Für alle denkbaren Szenarien gibt es Maßnahmen wie z.B. Faradaykäfige, Fehlerkorrekturcodes (ECC), Fehler-Erkennungs-Codes(CRC, HMAC) oder Mehrfach-Redundanz von Rechnern, Leitungen, Fühlern und Stellgliedern. Die denkbaren Ausfall-Szenarien müssen mit echten Bauteilen physikalisch nachgestellt werden, um die Reaktion von Software und Hardware zu prüfen. Dies geschieht auch regelmäßig in den oben genannten Industrien.
Kommentar auf The Register zu einem Artikel:
Details, Aerospace Software
It transpires:
1.) The problem was a bitflip, caused by solar storm radiation. For some hard to explain
reason, the affected variable in main memory was not protected by CRC, ECC or the like.
1.2) Protection is ideally done by hardware, but can also be done in software: Store
multiple copies of the variables and compare them upon each use. Handle deviation
in a proper way.
2.) The affected software controls the horizontal control surface. This means the aircraft
can potentially pitch up or down wildly, up to a breakup of the a/c structure.
3.) The software rollback again protects against solar storm particles.
Questions:
A) Shouldn't Airbus have found this problem in a HIL Test rig under simulated solar
radiation ? Particle beam accelerators do exist and are not expensive for a fleet of
thousands of aircraft. Needs to be done once for each release and all a/c.
Note: Control systems of this kind are typically programmed in Ada, C, C++ and execute
on a RTOS like Integrity-178, VxWorks, QNX or the like. Unixes or Windows do not
fit the bill, as they are not hard realtime capable. CPU could be an embedded version
of PowerPC, ARM or 680x0.
Note 2: software of this type is developed with the V-Model approach, which is vastly
different from the quick-and-dirty approach used for most beancounting and general
IT software.
See
https://di-fg.de/RobusteSoftware.html
Airbus does have a good history of faithfully executing the V-Model and this appears to be
an unfortunate exception. Nevertheless, they should now subject ALL of their
safety-critical control units to artificial particle beam while executing inside a HIL
test rig.
Weitere Dokumente zum Vorfall:
Safefly IB Times EASA-Anweisung Flug RevueFunktionale Sprachen wie LISP, HASKELL, SCHEME und einige andere arbeiten mit dem sog. Lambda-Kalkül. Die Idee ist dabei, Algorithmen nicht mittels imperativer Konstrukte auszurücken, sondern als eine Verschachtelung von "Lambda-Funktionen". Dies erlaubt in manchen Applikationsfällen einen sehr eleganten und damit leicht verständlichen Ausdruck des Algorithmus. Eine zentrale Idee des Lambda-Kalküls ist es, keine Variablen zu überschreiben, im Gegensatz zu den imperativen Ansätzen. Zudem werden idealerweise auch keine "Seiteneffekte" ausgelöst, sondern das Funktions-Konvolut berechnet.
In manchen Anwendungsfällen können funktionale Sprachen somit eine besser zu durchschauende Kodierung eines Algorithmus darstellen. Dies ist im Sinne eines einfacheren Code-Review gut für die Robustheit und Korrektheit eines Software-Systems.
Typischerweise brauchen funktionale Sprachen jedoch eine automatische Speicherverwaltung mit Garbage-Collector, was sie für Echtzeit-Anwendungen schwierig oder gar unmöglich macht.
Entgegen weit verbreiteter Vorurteile kann Software extrem hohe Zuverlässigkeit erzielen, sofern sie von fähigen Software-Ingenieuren und Fachexperten(z.B. Kardiologen, Frauenärzte, Testpiloten) entwickelt wird. Ausreichende Finanzierung, realistische Zeitpläne und fähige Manager sind ebenso vorausgesetzt. Software und digitale Systeme können genauso zuverlässig wie mechanische, analog-elektronische, hydraulische oder pneumatische Systeme sein. Durch Mehrfach-Redundanz von Steuerrechnern, Übertragungsleitungen und Sensoren sowie durch Fehlerkorrektur-Codes(z.B. ECC, CRC) kann die hardware-bedingte Ausfallrate zudem quasi beliebig klein gemacht werden. Wie jede Wissenschaft erfordert aber auch die Software-Entwicklung Fachleute und kann von Amateuren ohne Informatik-Studium nicht immer fachgerecht ausgeführt werden.