Wie wird Gerätesteuerungssoftware auf Qualität geprüft?

Ich habe an zertifizierter Software in einem anderen Bereich gearbeitet (und etwas weniger streng); Das Prinzip wäre hier ähnlich.

Grundsätzlich wird die Zertifizierungsstelle sicherstellen wollen, dass eine ordnungsgemäße Risikoanalyse auf dem System durchgeführt wurde – sowohl Software als auch Hardware – und Risiken gemindert wurden, um ein bestimmtes Maß an Zuverlässigkeit zu erreichen.

Die Behörde hat keine Programmierer, um den Code tatsächlich zu überprüfen. Sie überprüfen die Anforderungen, die Testabdeckung und die Aufzeichnungen, dass alle Verfahren befolgt wurden. Der gesamte Code muss auf die Anforderungen zurückverfolgbar sein, die dazu geführt haben, dass er geschrieben wurde, Tests, die ihn abdecken, es muss Aufzeichnungen geben, dass er überprüft wurde, dass alle Tests bestanden wurden. Alle Anforderungen müssen ihre Tests haben, dann müssen diverse Stresstests, explorative Tests, die Testpläne überprüft werden. Es wird auch verschiedene statische Prüfungen und Richtlinien geben, die befolgt werden müssen. Es ist eine riesige Menge an Papierkram, um sicherzustellen, dass Risiken nicht übersehen wurden.

Und dann ist die erforderliche geschätzte mittlere Zeit zwischen Ausfällen für kritische Systeme so wahnsinnig niedrig – IIRC für kritische Systeme muss die mittlere Zeit zwischen kritischen Ausfällen (geschätzt) mindestens 10⁹ Stunden betragen – dass es einfach keine Möglichkeit gibt, dies durch Tests allein nachzuweisen. Nicht einmal die Hardware wird diese Zuverlässigkeit haben – sie ist hunderttausend Jahre alt. Das System muss also so ausgelegt sein, dass es ausfallsicher ist und auf ein Backup umschalten kann, und dann ist die mittlere Zeit zwischen dem Ausfall aller Systeme während eines einzelnen Flugs das, was über dem Ziel liegt.

Es gibt also ein Verfahren, aber der Hersteller tut es und die Zertifizierungsstelle überprüft nur, ob es befolgt wurde.

Der sicherheitskritische Code wird tatsächlich normalerweise in C oder manchmal in C++ oder Ada geschrieben. Allerdings darf sicherheitskritischer und jeder andere Code in harter Echtzeit nur unter Verwendung von statischem Speicher geschrieben werden. Dies eliminiert eine große Klasse von Problemen, für die C-Code normalerweise bekannt ist, und die Einfachheit von C erleichtert die statische Überprüfung – und die Hersteller kritischer Software haben leistungsstarke, fortschrittliche Tools dafür –, also ist es eigentlich ziemlich gut geeignet.

Der Code ist eigentlich immer noch ziemlich hässlich. Es wird bei den Tests stark gehämmert, aber wenn gefundene Probleme behoben werden, ist es vorzuziehen, kleinere Änderungen vorzunehmen, um zu vermeiden, dass andere Teile beschädigt werden, die die Tests bereits bestanden haben, was zu seiner Hässlichkeit beiträgt. Niemand denkt, dass es perfekt ist, aber darum geht es nicht. Auch die Hardware ist nicht perfekt, daher sind Backups, Failsafes und Failover darauf ausgelegt, beide Arten von Ausfällen zu bewältigen.

Und beachten Sie, dass das aktuelle Boeing-Problem eigentlich ein Problem mit den Anforderungen ist. Das Trimmsystem kann zum Beispiel weglaufen, wenn der Schalter klemmt, was bei mechanischen Schaltern immer ein Risiko darstellt, daher muss ein Trennschalter vorhanden sein, um ihn zu trennen. Und den öffentlichen Informationen nach zu urteilen, scheint es, dass derjenige, der dieses System entwickelt hat, argumentiert hat, dass dieser Trennschalter ausreicht, um auch den Ausfall des Neuzugangs zu bewältigen, so dass das System nicht als kritisch angesehen wurde und die Fehlererkennung nicht in den Anforderungen für enthalten war Es. Aber dabei haben sie offenbar die beteiligten menschlichen Faktoren unterschätzt – spezifische Details werden Gegenstand der Analyse in der Untersuchung sein, und das ist es, was normalerweise so lange dauert.

Update: Der Artikel über den jüngsten B38M-Absturz (ET-302) verlinkt auf ein FAA-Dokument FAA and Industry Guide to Product Certification , das einen Überblick über den gesamten Prozess gibt. Es geht nicht speziell um Software, aber der allgemeine Prozess gilt immer noch dafür.

Jegliche Software, die auf zertifizierten Geräten läuft, muss RTCA DO-178C befolgen .

Dies ist ein ziemlich komplexer und teurer Prozess, der Audits speziell mit der Zertifizierungsbehörde (FAA, EASA) während des gesamten Produktlebenszyklus umfasst, einschließlich Inspektionen von Anforderungen, Design, Implementierung und Tests.

Jeder entwickelte Code wird streng als Geschäftsgeheimnis gehütet, daher ist es sehr unwahrscheinlich, dass Sie jemals den tatsächlichen Produktcode sehen werden, es sei denn, Sie arbeiten für ein Unternehmen, das die Software tatsächlich entwickelt, oder sind Prüfer der Zertifizierungsstelle.

Ein Großteil des sicherheitskritischen Codes wird entweder in Assembly (zielspezifisch), C, C++ oder Ada entwickelt.

Gibt es ein Verfahren für die Qualitätssicherung des Herstellercodes einer Fluggesellschaft?

DO-178C erfordert die Entwicklung eines strengen und komplexen Qualitätssicherungsprozesses. Dies wird größtenteils sowohl von internen Auditoren als auch von QA-Ingenieuren gehandhabt, die nicht nur die Softwaredesigner mit unterschiedlichen Hüten sind. Es wird auch von designierten Zertifizierungsbeauftragten gehandhabt, die Audits durchführen, Dokumente zur Einreichung von Zertifizierungen prüfen und ungelöste Fehler-/Problemberichte genehmigen. Viele Unternehmen scheinen Standards wie ISO-9000 oder CMMI zu befolgen .

Dieser QA-Prozess muss Audits umfassen, wie in der FAA-Verordnung 8110.49A erläutert, sogenannte „Stage of Involvement“-Audits. Diese finden während des gesamten Entwicklungslebenszyklus statt, nicht nur am Endprodukt, und decken alles ab, von der Frage, ob Ihre Planung angemessen ist, ob die Anforderungen mit dem Code übereinstimmen, oder ob Ihre Tests den Standards entsprechen.

Wird jemand bei der FAA zu Boeings privatem Github-Konto eingeladen?

Was tatsächlich bei der FAA eingereicht wird, ist begrenzt, zum Teil, weil das Hauptziel der FAA während der Zertifizierung darin besteht, sicherzustellen, dass das Flugzeug mit einem qualitativ hochwertigen Prozess entwickelt wurde. Die FAA verlässt sich stark auf die internen Prüfer und Zertifizierungsbeauftragten, die Zugang zum Kodex und den Anforderungen haben. Die FAA sieht viele High-Level-Berichte wie TSO-Einreichungen, eine Zusammenfassung der Softwareleistung, Systemsicherheitsanalysen usw. Sie sehen auch eine Liste aller offenen Fehlerberichte, die das Cockpit tatsächlich betreffen. Schließlich ist die FAA in begrenztem Umfang an den Flugtests des Flugzeugs beteiligt.

Die FAA überprüft selten den tatsächlichen Code. Wie selectstriker2 in seiner/ihrer Antwort betonte, gelten viele Flugzeugcodes als Geschäftsgeheimnisse, und einige Überlegungen wie Exportkontrollen können zutreffen. Sogar Avioniklieferanten und Flugzeugentwickler zögern, zu viele Daten miteinander zu teilen, um den Diebstahl von Geschäftsgeheimnissen zu verhindern.

Ich kann keine einzige Patentanmeldung finden, die auch nur erwähnt, in welcher Sprache sie geschrieben ist

Siehe Welche Programmiersprachen werden für Geräte an Bord von Flugzeugen verwendet? . Ich verstehe Ihre Frustration, da es mir schwer gefallen ist, Technologien zu erforschen, die andere Unternehmen selbst verwenden.

Andere Punkte

DO-178 hat einige Stellen, an denen es sich auf die Verantwortung des zertifizierenden Unternehmens verlässt, obwohl finanzielle Anreize bestehen, Software zu produzieren, die „gerade gut genug“ ist. Beispielsweise geht die FAA davon aus, dass das Unternehmen über ein gutes Design (einschließlich menschlicher Faktoren), eine angemessene Ausbildung, starke Investitionen in die Qualitätssicherung mit begrenzten Abstrichen und keine absichtlichen Falschdarstellungen verfügt.

Am wichtigsten ist, dass die FAA darauf abzielt, sicherzustellen, dass der Softwareentwicklungsprozess wahrscheinlich nicht unerkannte Fehler produziert, nicht dass die Software selbst vollständig fehlerfrei ist. Viele Nachrichtenberichte über den jüngsten Absturz der 737 Max bezeichnen dies als "Delegation" oder sogar "Selbstprüfung", aber so hat die FAA die Avionik immer gehandhabt - sie können nicht alle Funktionen selbst erschöpfend testen und verlassen sich bei der Entscheidung weitgehend auf den Hersteller die Komplexität dessen, was sicher ist und was nicht. Während die FAA einige anerkannte Designstandards wie die TSOs hat, sind diese Standards sehr allgemein. In gewisser Weise macht dies Sinn – die FAA kann sich nicht in ein Katz-und-Maus-Spiel verwickeln lassen, bei dem sie ihre eigenen Designanforderungen für jede neue Variation oder jedes neue Feature in der Avionik aktualisieren muss.

Unter den anderen Zertifizierungsanforderungen, die für Ihre Frage gelten:

• Eine Sicherheitsanalyse mit Berechnungen oder Modellen, die zeigen, dass Probleme (z. B. ein unentdecktes Absenken der Nase unter 1000 Fuß AGL) nicht wahrscheinlicher auftreten, als es der Schweregrad erfordert. Diese Modelle basieren oft auf Redundanzniveaus und Fehlfunktionswahrscheinlichkeiten (z. B. fallen beide AOA-Sensoren nur einmal pro 10^-9 Flugstunden aus) (siehe ARP4761).
• Sowohl System- als auch Softwareanforderungen mit entsprechenden System- und Softwaretests. Als Analogie stellen Sie sicher, dass das Haus nicht nur nach Bauplänen gebaut wird, sondern dass die Baupläne für ein Haus sinnvoll sind. Dies bezieht sich auf den Punkt @ user71659, der angesprochen wurde, um das Design im Kontext des Flugzeugs zu validieren und nicht nur zu überprüfen, ob der Code fehlerfrei ist.
• Gründliche Tests, einschließlich Testen von Sicherheitsfunktionen gegen Sensorausfälle, Testen von Codezeilen auf ein MCDC-Abdeckungsniveau und strukturelle Abdeckungstests, um sicherzustellen, dass keine unbeabsichtigten Interaktionen auftreten
• Konfigurationsmanagement, einschließlich Änderungsprüfung und Problemverfolgung. Wenn Sie DO-178C folgen, können Sie eine ungeprüfte Codeänderung nicht zusammenführen oder einen Fehlerbericht ausblenden
• Tool-Qualifizierung, um sicherzustellen, dass die Build-Umgebung, automatische Tests usw. gut gestaltet und stabil sind. Siehe DO-330 für mehr.

Dies ist ein weites Thema und es gibt eine Vielzahl von Zertifizierungsdokumenten, die auf Ihre Frage zutreffen, einschließlich DO-178C, ARP4754A und ARP4761. Ganze Bücher wurden über Branchenpraktiken geschrieben. Wenn Sie also diese Frage im Detail verstehen möchten, würde ich vorschlagen, dass Sie eines aufgreifen (meine Anlaufstelle ist Leanna Riersons „Developing Safety Critical Software“).