Laufen sicherheitskritische Avioniksysteme unter Linux?

Keines der Avioniksysteme, an denen ich gearbeitet habe, hat Linux oder ein anderes Betriebssystem für Verbraucher verwendet. Es gibt ein paar Hauptprobleme.

An erster Stelle steht das Praktische. Die meisten sicherheitskritischen Avioniksysteme beinhalten einen Regelkreis und haben daher eine Echtzeitanforderung. Das bedeutet, dass es nicht nur wichtig ist, einen Prozess auszuführen und eine Antwort zu erhalten, sondern Sie müssen die Antwort innerhalb einer streng kontrollierten Zeitvorgabe erhalten. Jeder kritische Softwareprozess in einem Flugzeug ist so geplant, dass Sie einen stabilen Regelkreis haben. Dazu benötigen Sie ein Echtzeit-Betriebssystem, und Linux ist keines.

Zweitens ist die Notwendigkeit einer Zertifizierung. Software, die in einem Luftfahrzeug verwendet wird, muss so entwickelt werden, dass sie das entsprechende Development Assurance Level (DAL) für die zugehörige Gefahrenstufe erfüllt. Sicherheitskritische Systeme müssen das DAL-Level „A“ erfüllen. Jedes von Ihnen verwendete Betriebssystem muss dieselbe DAL erfüllen wie die darauf ausgeführte Funktion. Diese Anforderungen sind in RTCA DO-178C definiert . Linux wurde nicht nach diesem Standard entwickelt. Es gibt nur wenige Betriebssystem-/Software-Entwicklungsplattformen, die zertifiziert werden können. Green Hills, Wind River und LynxOS sind die wenigen mir bekannten Systeme, die die Anforderungen erfüllen.

Es gibt auch eine weitere Einschränkung, da die Zertifizierung eine sehr strenge Versionskontrolle erfordert. Avionik wird noch viele Jahre im Einsatz sein und jede Änderung daran muss ebenfalls zertifiziert werden. Im Allgemeinen gibt es keinen triftigen Grund, das Betriebssystem auf einem alten Gerät zu aktualisieren, und in vielen Fällen können Sie dies nicht tun, ohne die Hardware zu aktualisieren (was ein größerer Aufwand ist, den niemand haben möchte). Wenn ich also ein altes Gerät aktualisiere, muss ich die „neue“ Software erstellen, damit sie auf der aktuell im Produkt vorhandenen Version des Betriebssystems ausgeführt werden kann. Das könnte eine 15 oder 20 Jahre alte (oder ältere) Plattform sein. Ein sich schnell entwickelndes Betriebssystem wie Linux würde sich negativ auf den langfristigen Produktsupport auswirken.

Die kurze Antwort lautet, dass keine sicherheitskritischen Avioniksysteme, die mir bekannt sind, Linux verwenden, und die Systeme mit der höchsten Kritikalität verwenden oft überhaupt kein kommerzielles Betriebssystem. Linux wird jedoch in anderen sicherheitskritischen Anwendungen wie dem Space X Falcon 9 und medizinischen Anwendungen verwendet. Eine detailliertere Erklärung ist schwierig, ohne zu sehr in die Tiefe zu gehen, da die Frage so etwas wie die Frage ist: "Sind moderne Flugzeugzellen aus Nanomaterialien hergestellt?", Wobei eine detaillierte Erklärung die Vor- und Nachteile des Materials stellenweise abdecken müsste wo der Einsatz am sinnvollsten und am wenigsten sinnvoll ist, Unterschiede bei den Herstellern und eine Übersicht, was stattdessen verwendet wird, etc. Ich werde versuchen, all diese Punkte prägnant mit Links zu weiterführenden Informationen abzudecken.

Laut diesem FAA-BerichtAb 2001 waren einige der wichtigsten Betriebssysteme für zertifizierte Avionik VRTX, LynxOS, PSOS, VxWorks und Eneas OSE, obwohl unkritische Avionik manchmal andere Systeme wie Windows NT verwendet. (Ja, LynxOS basiert auf Unix und Linux wird als "Unix-ähnlich" angesehen, aber es gibt viele Unterschiede zwischen den beiden, genauso wie ein Linux dem BSD-basierten Mac OS X nicht ähnlich ist). Die kritischsten Systeme verwenden jedoch überhaupt kein kommerzielles Betriebssystem. Sie stellen fest: "Mit den heute verfügbaren Beweisen kann im Allgemeinen festgestellt werden, dass COTS-Produkte normalerweise nicht die Anforderungen für Kritikalitätssoftware der Stufe A erfüllen." Laienhaft ausgedrückt bedeutet dies, dass die meisten Avionikgeräte, die mit Software von Drittanbietern entwickelt wurden, von VxWorks bis Linux, nicht ausreichend getestet und analysiert wurden, um in etwas Kritisches wie ein Landesystem eingebaut zu werden. TCAS-Einheit oder kritische Anzeigeeinheit. Das hat sich jedoch wahrscheinlich in den mehr als 10 Jahren seit der Erstellung des Berichts geändert. Hier ist ein neueresArtikel zur Verwendung von Echtzeitbetriebssystemen in der Avionik .

Was bedeuten RTOS und COTS?

Ein wichtiges Konzept ist hier ein Echtzeitbetriebssystem oder RTOS. Kurz gesagt, ein RTOS bietet Garantien dafür, dass der Software die geplante Rechenzeit nicht ausgeht, Nachrichten zwischen Teilen der Software in kurzer Zeit weitergegeben werden, der Speicher nicht ausgeht und andere wichtige Aufgaben garantiert statt funktionieren gut unter normalen Bedingungen und dann unter ungewöhnlichen Bedingungen brechen. Normale Betriebssysteme können solche Garantien nicht geben. Diese Garantien oder akzeptable Ersatzstoffe sind für die Zertifizierung der meisten Avionik erforderlich.

Ein weiteres wichtiges Konzept ist der Unterschied zwischen internen und kommerziellen Standardsystemen (COTS). Kommerzielle Standardsysteme sind öffentlich verfügbar und werden nicht stark für jeden Hersteller angepasst. Dieser Artikel bietet eine gute Zusammenfassung der Vor- und Nachteile von kommerziellen und hauseigenen Betriebssystemen. Viele hochkritische Avionikgeräte haben aufgrund der damit verbundenen Vorteile immer noch die Kernsoftware im eigenen Haus entwickelt.

Erfüllt Linux die Zertifizierungsanforderungen?

Ja, Linux ist nicht "FAA-zertifiziert", aber tatsächlich ist kein RTOS "FAA-zertifiziert" oder "erfüllt DO-178C". DO-178C enthält Ziele, die die Avionik-Systemingenieure erfüllen müssen, um ihre gesamte Avionik-Software zu zertifizieren (die Ziele umfassen unter anderem Audits, Tests, Sicherheitsanalysen und das Schreiben von Anforderungen). Das Beste, was der OS-Anbieter tun kann, ist also, "DO-178C-fähige" Software bereitzustellen oder die DO-178C-Richtlinien zu befolgen. Beachten Sie, dass DO-178C verschiedene Sicherheitsstufen anerkennt, was also unter DO-178C für ein Wartungssystem zertifizierbar ist, ist möglicherweise nicht unter DO-178C für eine kritische Anzeigeeinheit zertifizierbar. Das Problem mit Linux ist nicht, dass Linux nicht „unter DO-178C zertifiziert“ ist, sondern dass es aufgrund der unten aufgeführten Herausforderungen schwierig ist, es zu zertifizieren. Es' Es ist zwar möglich, ein System unter Linux zu zertifizieren, dies könnte jedoch aufgrund der zusätzlichen Analyse, Sicherheitsmaßnahmen und Dokumentation, die erforderlich wären, insbesondere für die kritischsten Avionik, unerschwinglich schwierig sein. Einige dieser Herausforderungen und alternative Compliance-Methoden werden in beschriebendieser FAA-Bericht .

Vor- und Nachteile von Linux

Es gibt Vorteile bei der Verwendung von Linux, die teilweise mit anderen kommerziellen Systemen geteilt werden. Mehr Mitarbeiter werden bereits Erfahrung mit Linux haben, und das Betriebssystem wurde mit mehr Fachwissen und Zeit entwickelt, als die meisten Unternehmen zur Verfügung haben. Kommerzielle Systeme haben auch einen viel niedrigeren Aufkleberpreis als hauseigene Software. Kommerzielle Systeme sind auch anpassungsfähiger und ermöglichen Änderungen an der Hardware und Raum für zukünftiges Wachstum, ohne zum Reißbrett zurückkehren zu müssen. Die Tools für die Arbeit mit der Software sind weiter entwickelt, und sie haben möglicherweise auch eine längere Servicehistorie, die Vertrauen in die Software schafft.

Hier sind einige der Probleme, mit denen Linux in einem Avioniksystem konfrontiert ist, wenn es mit einem RTOS konkurriert, aus diesem FAA-Bericht :

• Partitionierung: Wenn zwei Programme unabhängig voneinander laufen sollen, muss nachgewiesen werden, dass ein Programm ein anderes nicht durch gemeinsam genutzte Speicherstruktur, Caches, Board-Unterstützung und Firmware, Fehler, Interrupts usw. stören kann.

• Worst-Case-Ausführungszeit: Beim Desktop-Computing ist es in Ordnung, wenn ich meinen PC mit zu vielen Anfragen oder ungewöhnlichen Bedingungen auf einmal verlangsamt und das System langsamer wird oder einige Programmschritte überspringt. In der Avionik ist dies aus offensichtlichen Gründen nicht akzeptabel. Der Lieferant müsste dies entweder durch Modelle der CPU, des Speichers usw. oder durch strenge Labortests und Timing-Analysen überprüfen. Beides ist umso schwieriger, je komplexer Ihre Hard- und Software ist.

• MCDC-Abdeckung: Tests der kritischsten Avionik (Level A) erfordern die Ausführung von genügend Codezeilen und Entscheidungsbedingungen, um den MCDC-Codeabdeckungsstandard zu erreichen, der zwischen „jede Codezeile ausführen“ und erschöpfenden Tests jeder Kombination von Bedingungen liegt. Bei einigen Betriebssystemen wie Linux kann es äußerst schwierig sein, sie gründlich genug zu testen, um diesen Standard zu erfüllen.
• Dokumentation: Strenge Analysen und Belastungstests erfordern eine Menge Dokumentation zum Innenleben des Betriebssystems
• Sicherheitsüberlegungen: Linux hat von Natur aus mehr Sicherheitsprobleme als eine schlanke, interne Anwendung. Diese Sicherheitsfragen werden insbesondere im Militär immer wichtiger
• toter und unerreichbarer Code: Für die Zertifizierung ist es normalerweise erforderlich, die vielen ungenutzten Funktionen von Linux sorgfältig zu deaktivieren und sicherzustellen, dass sie nicht in Ihre Software eingreifen können

Andere sicherheitskritische Branchen

Was ist mit ähnlichen sicherheitskritischen Branchen? Der Space X Falcon verwendet Linux in einigen seiner Flugcomputer ( Quellen ). Basierend auf diesem Interview scheint Space X zukünftiges Wachstum, Verfügbarkeit, kurze Zykluszeiten und Fachwissen über die Einfachheit und Robustheit der Eigenentwicklung in diesem Bereich zu stellen. Beachten Sie, dass die Flugsteuerungscomputer des Space X Falcon nicht direkt analog zu einer LRU in typischer moderner Avionik sind, sodass wahrscheinlich zusätzliche Arbeit oder eine ungewöhnliche Architektur erforderlich wäre, um Linux für typische Avionikanwendungen zum Laufen zu bringen.

Linux kommt auch in vielen sicherheitskritischen medizinischen Anwendungen zum Einsatz, allerdings nicht ohne ähnliche Probleme wie in der Luftfahrt. Ich empfehle die Lektüre von Wind Rivers „Choosing Linux for Medical Devices“ oder diesen Artikel über die Nachteile von Linux in sicherheitskritischen medizinischen Anwendungen.

Ich nehme an, Sie sprechen von der wichtigsten Avionik wie Flugführung, Autopilot, Fly-by-Wire oder Displays. Andere Flugzeugsysteme könnten grob als sicherheitskritisch angesehen werden, sind aber keine typischen Beispiele für sicherheitskritische Geräte, wie zertifizierte elektronische Flightbags, Konnektivitätslösungen und Wartungssoftware. Diese sind aufgrund der hohen Komplexität und weniger strengen Sicherheitsüberlegungen manchmal besser für eine Linux-Anwendung geeignet.

Beachten Sie, dass ich kein Experte auf diesem Gebiet bin und mein Rat den Rat eines Zertifizierungsspezialisten nicht ersetzt.

Scheinbar nutzen Piloten inzwischen zumindest manchmal Tablets für Checklisten .

Wenn diese Tablets Android-Geräte sind (die meisten von ihnen ), dann führen sie einen Linux-Kernel aus. Android verwendet weniger Standard-Linux-Stack, verwendet aber immer noch den Linux-Kernel. Checklisten sind sicherheitskritisch, denke ich. Apple- und Windows-Tablets verwenden unterschiedliche Kernel, nicht Linux.

Es gibt viele Checklisten-Apps für Android-Geräte . Ich nehme an, jemand benutzt sie.

Der Kernel ist der Kern des Betriebssystems eines Computers, der die vollständige Kontrolle über alle anderen Teile behält. Wie die Verkabelung für ein Verkehrsflugzeug.

Um einige Missverständnisse über Linux zu klären, die sich auf viele der gegebenen Antworten beziehen.

Linux ist KEIN "kommerzielles" Betriebssystem. Es steht jedem frei, es herunterzuladen und nach Belieben zu hacken. (Einige Unternehmen packen es mit einer Menge Apps als Distribution oder „Distribution“ zusammen und erheben Gebühren für die Unterstützung des Pakets).

Linux ist KEIN monolithischer Build mit vielen überflüssigen Funktionen. Der Linux-Kernel-Kern ist schlank und gut genug, um auf Smartwatches und vielen anderen eingebetteten Geräten installiert zu werden. Den Schnickschnack liefern eine Vielzahl optionaler Kernel-Module. Wenn Sie Ihren Linux-Kernel für die Installation erstellen, wählen Sie aus, welche Module Sie möchten und ob Sie sie in einem einzigen Blob mit dem Kern zusammenrollen (schnell) oder als separate Blobs darum hängen möchten (betrieblich flexibel).

Linux ist KEIN "Userland"-Betriebssystem. Dazu müssen Sie eine Schnittstellenschicht wie GNU oder Android hinzufügen. Es wird ausgiebig in eingebetteten Anwendungen verwendet, wo die Ingenieure des Unternehmens die oben beschriebenen Dinge getan haben.

Linux ist nicht unsicherer als jedes andere Betriebssystem. In der Tat betrachten viele es als eines der sichersten. Es ist das Userland-Bit, in dem Distributionen wie Android schrecklich schief gehen, während sich eine weitere Reihe neuer Exploits auf Hardware-Designfehler konzentriert.

Linux kann so stabil und unterstützbar sein, wie Sie es möchten. Ein Unternehmen für Avionik-Betriebssysteme kann einen bestimmten Kernel-Build zwanzig Jahre und länger unterstützen und den unerbittlichen Strom von Fortschritten einfach ignorieren, es sei denn, und bis es für ein Upgrade oder ein neues Produkt genutzt werden muss. Ein gegebener Tweak kann oft auf Ihren alten Build "zurückportiert" werden, sodass Sie sich nicht mit dem vollständigen Upgrade befassen müssen.

Linux bietet verschiedene Echtzeit-Optimierungen, wenn Sie sie verwenden möchten. Möglicherweise ist keine für die Kernflugsteuerung vollständig zufriedenstellend, aber die offene Lizenzierung bedeutet, dass Sie im Prinzip nichts daran hindern können, die Ärmel hochzukrempeln und selbst daran zu feilen. Sie können Ihren Code dann wieder in den Linux-Quellbaum einspeisen und andere können ihn dann verwenden und weiter verbessern.

Abgesehen davon ist es eine Menge Arbeit, Linux an Ihr gegebenes Hardware-/Softwareregime anzupassen, und die offene Lizenzierung macht es schwierig, hohe Lizenzgebühren zu verlangen. Daher ist es für spezialisierte Softwarehäuser ebenso schwierig, davon ihren Lebensunterhalt zu verdienen. Sofern ein Avionikhaus also nicht die Kosten für die Anpassung seines eigenen Betriebssystems aufwenden möchte, findet es nur kommerziell lizenzierte Angebote, die von den Spezialisten erhältlich sind.

Letzteres ist der Hauptgrund, warum Linux selten oder nie in der Avionik auftaucht und warum alle anderen Probleme nicht angesprochen werden.

Auf der anderen Seite, wenn Sie Consumer- und kommerzielle Low-End-Drohnen einbeziehen, ist Linux bereits beliebt, wenn nicht sogar dominant. Es besteht kein Zweifel, dass es sich in den kommenden Jahren in der Nahrungskette stetig nach oben arbeiten wird.

Wird Linux für sicherheitskritische Anwendungen verwendet? Nein Ja. Vielleicht. Geduld mit mir ...

Die USS Umwalt verwendet Linux für ihre umfangreichen Datenanforderungen und LynxOS für eingebettete harte Echtzeitanwendungen, die in diesem Artikel beschrieben werden .

Standard-Laptop-Linux ist ein User Space-Betriebssystem: Es wartet, bis ein Benutzer mit der Maus klickt, eine Taste drückt oder eine Ausgabe generiert, und ergreift dann Maßnahmen. Es können viele Programme geöffnet sein oder auch nicht. Benutzereingaben sind für das Betriebssystem ein statistisches Ereignis: Sie können in der nächsten Minute erfolgen oder auch nicht.

Vergleichen Sie das mit einem digitalen Regelkreis. Es läuft auf einem Prozessor und verwendet Speicher, nur Standard-Computerhardware. Aber sie unterscheiden sich von Desktop-Software dadurch, dass sie:

• sind eingebettet ;
• Haben Sie eine Reihe vordefinierter Aufgaben;
• Strenge zeitliche Beschränkungen haben;
• In einer Endlosschleife laufen. Am Ende des Programms springt es zurück zum Anfang und durchläuft die Routine erneut, dies wäre ein Iterationsrahmen.

Die Software muss bei jeder Iteration Eingaben lesen und Ausgaben generieren, und ein Iterationsframe läuft für eine festgelegte Zeitspanne. Ein hartes Echtzeitsystem ist ein System, bei dem zeitgesteuerte Antworten deterministisch sein müssen: Was immer es tut, muss innerhalb einer Software-Iteration abgeschlossen werden. Wenn der Regelkreis mit 100 Hz läuft, dauert ein Iterationszyklus 10 ms, und die Hardware muss schnell genug sein, um sicherzustellen, dass der gesamte Prozess jedes Mal innerhalb der Zeit abgeschlossen werden kann.

Diese Regelkreise sind im Allgemeinen nicht riesig und haben im Allgemeinen keine Anzahl von Fenstern zwischen 1 und 100 geöffnet. Kleine und schnelle Programme und eine begrenzte Anzahl von Fenstern, das sind Betriebssysteme für sicherheitskritische Programme und Echtzeitschleifen sind dafür gemacht. Was großartig ist, früher gab es dafür kein O/S und der Code musste in Assembler oder schlechter geschrieben werden. E/A-Aufrufe waren hardwarespezifisch und daher nicht von einem Chipsatz auf einen anderen übertragbar.

Hier kommen die Echtzeit-O/S wie VxWorks, LynxOS und einige andere ins Spiel. Sie sind Unix-basierte, POSIX-kompatible O/S. Die Hardwareschicht wird für den Programmierer unsichtbar gemacht, der über eine Reihe von Entwicklungswerkzeugen verfügt, um höhere Computersprachen mit Standard-E/A-Aufrufen und Zeitsteuerungsroutinen zu verwenden. Sie sind skalierbar: Sie können mit einem Betriebssystem beginnen, das einfach bootet und dann sofort Ihre kreuzkompilierte Binärdatei mit einer an der Timer-Schnittstelle festgelegten Rate ausführt. Oder Sie können den Kernel neu konfigurieren und ein paar Benutzer-Interrupts einbauen, die auf Tastaturen oder eingehende RS-232-Daten achten, alles bis zum Programmierer, der auch über ein umfangreiches Toolkit für Timing und I/O verfügt.

VxWorks kann teuer sein (wird aber gut unterstützt), und es gibt jetzt einige Open-Source-Alternativen, die auf dem Linux-Kernel basieren, wie Xenomai , RTLinux und Xilinx . Einige davon versuchen, alle Dienste für Desktop-Anwendungen verfügbar zu machen und haben nur einen Interrupt-Timer, der sein Bestes tut, um die Aufgabe gleichmäßig laufen zu lassen, selbst wenn ein Textverarbeitungsprogramm eine Rechtschreibprüfung startet. Andere sind schwer skalierbar, genau wie VxWorks, aber Open Source, und der Support kann eine Herausforderung darstellen. Soweit ich weiß, waren sie noch nicht auf dem Mars, VxWorks schon.

Kann es für sicherheitskritische Avionik verwendet werden: ja, wenn harte Echtzeit skalierbar und gemäß den für alle Avionik geltenden Standards getestet. Soweit ich weiß, ist noch nichts an Bord von Flugzeugen, aber das kann nur eine Frage der Zeit sein.

Es besteht wirklich keine Notwendigkeit, ein kommerzielles Betriebssystem für die Avionik zu haben.

Avioniksoftware wird in der Regel für bestimmte Hardware entwickelt – es gibt keine generische Hardwareplattform, die von vielen Anbietern für den Massenmarkt hergestellt wird.

Avionik interagiert nicht mit vielen anderen Systemen oder Hardware.

Avionik wird normalerweise als eine Anwendung ausgeführt, sodass kein Timesharing oder im Fall von RTOS ein garantierter Taktzyklusplan erforderlich ist.

Dies sind die Hauptzwecke eines Betriebssystems im Gegensatz zu einem einfachen Bootstrap-Loader, der eine Anwendung lädt und startet – das Betriebssystem ermöglicht mehrere Hardwareplattformen, mehrere Treiber und Dienstprogramme für Disc-/Flash-Speicher, Timesharing mit anderen Anwendungen und Peripheriegeräten wie Netzwerken. Was die Avionik tun muss: mit dem Display, externen Sensoren und Steuertasten interagieren – muss kein Betriebssystem beinhalten.

Ein eingebettetes Betriebssystem ist für ein dediziertes Gerät praktisch, insbesondere wenn die eingebettete Anwendung Webdienste für externen Zugriff und Steuerung veröffentlichen soll. Es ist jedoch langsamer zu laden (könnte ein Faktor für die Avionik sein) und verbraucht mehr Ressourcen als eine dedizierte App, die von einem Bootstrap-Loader gestartet wird.

Aufgrund des umfangreichen Zertifizierungszyklus läuft die Avionik in der Regel nicht auf dem neuesten und besten Stand und hat auch keinen kurzen Aktualisierungszyklus für die Hardware.

Keines der hier ausgetauschten Argumente ist völlig falsch, aber ich würde mir wünschen, dass sich einige Teilnehmer etwas mehr Mühe geben würden, ihre Argumente abzuwägen.

Die wahren Schlagworte für die Luftfahrt sind Echtzeit und Sicherheit .

Natürlich steht in der Luftfahrt die Sicherheit an erster Stelle und wenn etwas passieren muss, muss es meistens sofort passieren und dem Piloten beweisen, dass die Arbeit erledigt ist.

Bevor man etwas zertifizieren kann, muss man es verifizieren und validieren – das kann nervig werden. Und deshalb mögen das die meisten nicht.

Linux ist nicht zu komplex, um in der Luftfahrt getestet und eingesetzt zu werden - aber die Desktop-Variante ist es. Linux ist in seinem Software-Design recht gut für den Einsatz in der Luftfahrt geeignet, wie die meisten Posix-konformen Software. Das Schöne an Linux ist, dass jede Komponente darauf ausgelegt ist, genau eine Aufgabe zu erledigen und diese optimal (im Gegensatz zu Windows). Für die Luftfahrt würden Sie niemals eine komplexe, hochmoderne Software wie für einen Desktop verwenden. Sie würden nur die Elemente implementieren und testen, die Sie wirklich brauchen. Und es gibt Echtzeit-Implementierungen von POSIX-ähnlichen Systemen wie zum Beispiel QNX - und ihre Software-Architektur ist Linux sehr ähnlich.

Die Echtzeit-Perspektive: Einmal verlor Microsoft einen Wettbewerb bei einem Stahlhersteller, weil sie nicht erklären konnten, wie man eine 50-Tonnen-Stahlstange handhabt, die sich mit 6 m/s bewegt, mit einer Software, die mit einer Latenz von 500 ms reagiert. Zu diesem Zeitpunkt könnte die Stange die nächste Wand um etwa 3 m durchbohrt haben ...

Diese einfache Tatsache gilt umso mehr für die Luftfahrt.

Ein weiteres Argument ist, dass die Luftfahrtindustrie konservativ ist – die meisten Dinge, die am besten fliegen, sind mehr als 10, oft 40 Jahre alt.

Und in diesem Bereich wird oft geglaubt, man könne mit Open-Source-Software kein Geld verdienen – was nicht stimmt. So viele proprietäre (und zuverlässige) Instrumente laufen auf Software aus den neunziger Jahren, dh viele Geldautomaten laufen immer noch auf Windows NT-Derivaten. Will sagen: Viele Instrumentenhersteller sind nicht bereit, den Quellcode ihrer gut gepflegten Software zu veröffentlichen.

Andererseits: Wenn Boeing Open-Source-Software für ihre 737MAX verwendet hätte, wäre es mit einer gewissen Wahrscheinlichkeit nicht zu den Unfällen gekommen.

Und nun, da sind Sie: Es geht darum, in einer akzeptablen Zeit zu testen.

Nein, mehr testen und noch mehr testen.... Und dann landet man vielleicht bei luftfahrttauglicher Software. Und dafür wäre ein Echtzeit-Derivat einer POSIX-Software eine gute, wenn nicht sogar die ideale Wahl.