1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Nasa: Boeing umging…

Totalschaden

  1. Thema

Neues Thema Ansicht wechseln


  1. Totalschaden

    Autor: Safsec 11.02.20 - 18:33

    Wenn der Entwicklungsprozeß tatsächlich so einfach gestrickt war, wie ihn Mulholland beschrieb, dann sind die Steuersysteme aus Safety-Sicht ein Totalschaden. Er beschreibt einen Entwicklungsprozeß, der nur Qualitätsmanagement-Aspekte für nicht sicherheitsrelevante Systeme berücksichtigt.

    Die Standards zur Entwicklung sicherheitsrelevanter Systeme sind schon lange etabliert und kein Hexenwerk, sei es z.B. ISO 26262 im Autombil-, EN 50126/8/9 im Bahn- oder DO-178 im Luftfahrtbereich. Selbst wenn es keine Norm für die Raumfahrt geben sollte, dann hätte er sich dort bedienen können und das geht dann (in groben Schritten) so:
    1. Es muß ein Sicherheitsplan aufgestellt werden, der detailliert beschreibt mit welchen organisatorischen Maßnahmen die Umsetzung etwaiger Sicherheitsziele gewährleistet werden soll und was das Projekt unter "Sicherheitskultur" versteht.
    2. Aus einer Gefahrenanalyse und Risikobewertung werden die Sicherheitsziele abgeleitet.
    3. In einem Sicherheitskonzept wird dargelegt, wie die Sicherheitsziele technisch erreicht werden sollen.
    4. Das Sicherheitskonzept muß in der Systemarchitektur umgesetzt werden.
    5. Die Umsetzung der Systemarchitektur und der darunter liegenden Ebenen ist weit mehr als das Aufstellen von ein paar Anforderungen und dem Schreiben des Codes. Vielmehr wird das Gesamtsystem in Subsysteme zerlegt und für jedes Subsystem wird eine Hardware-Architektur und eine Software-Architektur erstellt. Die Architektur stellt dabei eine genaue Beschreibung der Funktionen, ihrer Schnittstellen, Abhängigkeiten und Zusammenhänge dar inklusive der Begründung für gewisse Entwurfsentscheidungen.
    6. Die Architektur muß auf jeder Ebene bzw. für jedes Subsystem mittels qualitativer und quantitativer Safety-Analysen (FMEA, FTA,...) verifiziert werden.
    7. Sämtliche oben genannten Dokumente müssen zur Verifizierung jeweils einem Review unterzogen werden, nicht nur der Code.
    8. Anhand der Anforderungs- und Architektur-Dokumenten auf den verschiedenen Ebenen bzw. Subsystemen müssen Funktions- und Integrationstests ebenfalls für diese Ebenen und Subsysteme spezifiziert und durchgeführt werden. Wenn man die Dokumente nach seiner Beschreibung aber nicht hat, dann kann man da auch nichts testen. Es müssen zudem noch weitere Tests gemacht werden, die ich hier nicht alle aufführen will. Entscheidend ist hierbei die Frage nach der Testabdeckung. "66% bei Flug getestet" ist ein kompletter Witz.
    9. Auch die Tests müssen (idealerweise von den Architekten) einem Review unterzogen werden.
    10. Es muß ein Sicherheitsnachweis erstellt werden, der die Einhaltung der organisatorischen und technischen Sicherheitsmaßnahmen bestätigt und bewertet. Dabei muß eine korrekte Argumentationslinie aufgezeigt werden.
    11. Unabhängige Gutachter müssen sich das Ganze von außen ansehen und Ihre Überzeugung von der Gewährleistung der Sicherheit in einem Gutachten darlegen.
    12. Die Tests müssen zudem in verschiedenen Stufen ablaufen. Wenn ein unbemannter Test fehlgeschlagen ist und solche eklatanten Mängel offenbart hat, dann ist vollkommen klar, daß er nach Beseitigung der Mängel erst mal wiederholt werden muß, bevor man darüber nachdenkt Menschen damit ins All zu schicken. Allein zu sagen "Erst danach werde über die Notwendigkeit eines neuen Testflugs entschieden" zeigt schon, daß sie mit der Entwicklung vollkommen überfordert sind und nicht wissen was sie tun.

    Mann, die sollten lieber Leute ran lassen, die das besser im Griff haben. Bei der dargelegten Inkompetenz von Boing und der Komplexität der Sache braucht es eher mehr als zwei Jahre, in jeder Position fähige Leute und einen Haufen Geld, um zu einem so sicheren System zu kommen, daß damit nicht nur Hasardeure fliegen wollen.

  2. Re: Totalschaden

    Autor: Frank Wunderlich-Pfeiffer 11.02.20 - 18:44

    Der Fairness wegen sollte man Mulholland hier zugestehen, dass er lediglich in einer Pressekonferenz auf eine Journalistenfrage geantwortet hat und dabei niemals mehr tun konnte, als den Prozess sehr grob zu umreißen. Die Nasa hat eine lange Geschichte mit sehr detaillierten und umfangreichen Beschreibungen von Prozeduren zur Softwareentwicklung. Einer der Kommentatoren hier hat seinen Beitrag nach einem der Standards benannt. Siehe auch:

    https://ntrs.nasa.gov/search.jsp?R=19980227975

    Frank Wunderlich-Pfeiffer (Twitter: @FrankWunderli13) - als freier Journalist bei Golem.de unterwegs - Raumfahrt Podcast (nach einem Jahr Zwangspause wieder da!) http://countdown-podcast.de/

  3. Re: Totalschaden

    Autor: Safsec 11.02.20 - 19:16

    Ja, vielen Dank für die Ergänzung. Die NASA hat da schon sehr viel Erfahrungen gesammelt und sichere Vorgehensweisen entwickelt. Hätte Mulholland erwähnt, daß Boing sich an diese Vorgehensweisen gehalten hätte und sie trotz aller Sorgfalt leider ein Detail (wegen einer nicht vorhersehbaren Verquickung der Gegebenheiten) übersehen hätten, dann wäre ich nicht so enttäuscht.

    Leider legt er hier eine irreführende Vereinfachung des auf die Sicherheit ausgerichteten Entwicklungsprozesses dar und zeigt mit seiner Einstellung "Erst danach werde über die Notwendigkeit eines neuen Testflugs entschieden", daß er Safety nicht verstanden hat.

    Solche Tests zum Nachweis der Sicherheit sind keine Versuche, bei denen man etwas über das Verhalten herausfinden will oder Fehler finden will, sondern solche Tests sollen bestätigen, daß alles wie vorgesehen funktioniert. Das hat der Test nicht gezeigt, also muß er wiederholt werden.

    Mulholland könnte man weiter zugestehen, daß er nicht der einzige ist, der beim Thema Safety noch dazulernen muß, wenn es nicht so traurig wäre. Im europäischen Bahn- und Luftfahrtbereich habe ich da in den vergangenen Jahren durchweg positive Erfahrungen gesammelt, der Automobilbereich ist gerade in einer Lernphase, aber Boing ist für mich seit dem 737-Max Desaster vollkommen unten durch.

  4. Re: Totalschaden

    Autor: Frank Wunderlich-Pfeiffer 11.02.20 - 19:44

    Ich hatte bei der Pressekonferenz zumindest den Eindruck gewonnen, dass sich Mulholland dem allen vollständig bewusst ist, dabei aber den formalen Prozess einhalten will und muss. Vor einer Entscheidung muss wenigstens die Untersuchung erst einmal abgeschlossen sein.

    Selbst wenn es jetzt schon einen Konsens darüber gäbe (Das ist möglich. Vergessen wir nicht, dass Boeing schon 410mio Dollar dafür zurückgelegt hat), könnte Mulholland diese Entscheidung nicht vorzeitig und eigenmächtig als Antwort auf eine Journalistenfrage verkünden.

    Frank Wunderlich-Pfeiffer (Twitter: @FrankWunderli13) - als freier Journalist bei Golem.de unterwegs - Raumfahrt Podcast (nach einem Jahr Zwangspause wieder da!) http://countdown-podcast.de/

  5. Re: Totalschaden

    Autor: Safsec 11.02.20 - 21:46

    Ok, daß er erst die Untersuchungen abwarten muß kann ich auch verstehen. Es kann ja auch niemand ernsthaft Interesse daran haben, daß sie scheitern. Ich hoffe sie bekommen die Kurve und ich hoffe auch, daß sich auch in Europa mehr bzgl. der Raumfahrt tut. Es hat mich nur aufgewühlt, als ich es gelesen habe.

  6. Re: Totalschaden

    Autor: captain_spaulding 12.02.20 - 10:40

    Was du da beschreibst ist ein Prozess, den Boing so ähnlich auf jeden Fall auch hat. Auch haben sie sicher haufenweise Dokumente dazu und auch die passenden Reviews.
    Sie haben sicher auch einen Audit gemacht und in einer Excel-Liste alles auf grün gesetzt.

    Es ist eben ein grundsätzliches Problem von Sicherheitsprozessen. Der Prozess mag sicher sein, aber das sagt über die Software die dabei rauskommt nicht ausreichend viel aus.
    Es kommt nämlich immer Zeitdruck dazu, auch weil eben ein Großteil der Entwicklungszeit in Safety-Prozesse gesteckt wird statt in die Software. Da sind den Entwicklern dann z.B. Bugs bekannt die aber nirgends offiziell aufgefallen sind. Das passiert auch mit 100% Test-Coverage. Aber die Entwickler werden 3 mal überlegen sich die Arbeit zu machen sich darum zu kümmern wenn eigentlich prozessmäßig alles ok ist.
    Ich kann mir auch nicht vorstellen dass bei Boeing niemandem aufgefallen ist dass der Sensor nicht redundant ist oder MCAS Mist ist. Es hat wahrscheinlich nur niemand als Problem dokumentiert und somit war der Prozess ok.

  7. Re: Totalschaden

    Autor: minnime 12.02.20 - 13:03

    Das zeigt doch aber eher, dass der Przess nicht ok ist. Wenn mir ein Fehler auffällt und ich melde den aufgrund irgendwelcher Formalitäten nicht, dann ist es gerade der Prozess der falsch läuft.

  8. Re: Totalschaden

    Autor: maci23 13.02.20 - 09:32

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Das zeigt doch aber eher, dass der Przess nicht ok ist. Wenn mir ein Fehler
    > auffällt und ich melde den aufgrund irgendwelcher Formalitäten nicht, dann
    > ist es gerade der Prozess der falsch läuft.

    Ich denke das genau umgekehrt läuft.
    Den Programmierern fällt eine Fehler auf, er meldet ihn, doch die Verantwortlichen streichen ohne wieder, denn das sprengt den Zeitplan.
    Die Verantwortlichen sehen immer nur $-Zeichen in den Augen. Zeit ist schließlich Geld.
    Dazu kommt das die Politik, besonders unter Trump, Druck macht.

  9. Re: Totalschaden

    Autor: GrischaGoebel 13.02.20 - 10:08

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------

    > Ich kann mir auch nicht vorstellen dass bei Boeing niemandem aufgefallen
    > ist dass der Sensor nicht redundant ist oder MCAS Mist ist. Es hat
    > wahrscheinlich nur niemand als Problem dokumentiert und somit war der
    > Prozess ok.


    Ich denke die haben den Sensor nicht redundant aufgebaut weil sie die FAA angelogen haben und die Redundanz zu Fragen geführt hätte.
    Offiziell konnte das System die Piloteneingabe nicht überlagern und die Höhenruder nur deutlich weniger verstellen, als das tatsächlich der Fall war. Dadurch war das System sicherheitstechnisch nicht relevant genug um den Sensor redundant auszuführen (es gab einen zweiten Sensor, dessen Daten wurden aber nicht verarbeitet soweit ich weiß. Selbst das war noch zu auffällig).
    Hätte man die Redundanz jetzt angewendet, hätte die FAA zurecht gefragt: Moment mal! Ihr sage uns das System ist sicherheitstechnisch nicht relevant, weil es bei einer Fehlfunktion jederzeit durch den Piloten überstimmt werden kann, setzt hier aber Ressourcen ein um es Redundant zu bauen? Das passt nicht.

    Wenn mit so ein Mangel auffallen würde, dann würde ich nicht vergessen diesen in ein Dokument zu schreiben. Außerdem ist das ein Punkt der schon ganz weit oben im Prozess nach der FMEA definiert wird. Aber wenn die FMEA schon von falschen Tatsachen ausgeht ist es kein Wunder.

  10. Re: Totalschaden

    Autor: captain_spaulding 13.02.20 - 19:21

    Du denkst also dass es wirklich niemand wusste?

  11. Re: Totalschaden

    Autor: zilti 15.02.20 - 15:04

    GrischaGoebel schrieb:
    --------------------------------------------------------------------------------
    > Dadurch war das System sicherheitstechnisch nicht relevant genug um
    > den Sensor redundant auszuführen (es gab einen zweiten Sensor, dessen Daten
    > wurden aber nicht verarbeitet soweit ich weiß. Selbst das war noch zu
    > auffällig).

    Jein, welcher Sensor verwendet wurde, hing davon ab, welche Seite des Cockpits als "Pilotenseite" eingestellt war.

    > Hätte man die Redundanz jetzt angewendet, hätte die FAA zurecht gefragt:

    Gar nichts hätte die FAA gefragt, die hat das ja so gut wie gar nicht kontrolliert.

  12. Re: Totalschaden

    Autor: Olliar 19.02.20 - 11:04

    zilti schrieb:
    --------------------------------------------------------------------------------
    > GrischaGoebel schrieb:
    > ---------------------------------------------------------------------------
    > > Dadurch war das System sicherheitstechnisch nicht relevant genug um
    > > den Sensor redundant auszuführen (es gab einen zweiten Sensor, dessen
    >> Daten
    > > wurden aber nicht verarbeitet soweit ich weiß. Selbst das war noch zu
    > > auffällig).
    >
    > Jein, welcher Sensor verwendet wurde, hing davon ab, welche Seite des
    > Cockpits als "Pilotenseite" eingestellt war.

    Ah!
    Das erklärt, warum eine andere Quelle sagte, dass die nicht genug Kabel(kanalvolumen) hatten,
    beide Sensoren zeitgleich auszuwerten.
    Boa. Da sind ja echte Kriminelle zugange, keine Volldeppen.

    Und: Es hätte Geld viel gekostet die Software entsprechend aufzubohren.
    Evtl. wäre der Speicher enggeworden...
    Das hätte ja alles getestet werden müssen.

    Ich finde, bei Boeing sollten ein paar Leute für 3x 348 Jahre
    in den miesesten Knast der USA und enteignet werden.


    > > Hätte man die Redundanz jetzt angewendet, hätte die FAA zurecht gefragt:
    >
    > Gar nichts hätte die FAA gefragt, die hat das ja so gut wie gar nicht
    > kontrolliert.

    Jo. aber so war man sicher das sie wirklich nicht fragen und konnte die vomn Airbus und den Aktionären vorgegebenen Termine halten...

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. AKDB Anstalt für kommunale Datenverarbeitung in Bayern, München, Regensburg
  2. DREWAG - Stadtwerke Dresden GmbH, Dresden
  3. Schaeffler Paravan Technologie GmbH & Co. KG, Schorndorf
  4. ERGO Group AG, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Homeschooling-Report: Wie Schulen mit der Coronakrise klarkommen
Homeschooling-Report
Wie Schulen mit der Coronakrise klarkommen

Lösungen von Open Source bis kommerzielle Lernsoftware, HPI-Cloud und Lernraum setzen Schulen derzeit um, um ihre Schüler mit Aufgaben zu versorgen - und das praktisch aus dem Stand. Wie läuft's?
Ein Bericht von Stefan Krempl

  1. Kinder und Technik Elfjährige CEO will eine Milliarde Kinder das Coden lehren
  2. IT an Schulen Intelligenter Stift zeichnet Handschrift von Schülern auf
  3. Mädchen und IT Fehler im System

Next-Gen: Welche neue Konsole darf's denn sein?
Next-Gen
Welche neue Konsole darf's denn sein?

Playstation 5 oder Xbox Series X: Welche Konsole besser wird, wissen wir auch noch nicht. Grundüberlegungen zur Hardware und den Ökosystemen.
Ein IMHO von Peter Steinlechner

  1. Elektroschrott Kauft keine kleinen Konsolen!
  2. IMHO Porsche prescht beim Preis übers Ziel hinaus

Disney+ im Test: Ein Fest für Filmfans
Disney+ im Test
Ein Fest für Filmfans

Wir haben Disney+ vor dem Deutschlandstart getestet und sind begeistert. Das Abo ist perfekt für Familien mit Schulkindern. Filmfans können sich über Bonusmaterial freuen, das Amazon Prime Video, Netflix und Sky gar nicht kennen.
Ein Test von Ingo Pakalski

  1. Disney+ The Mandalorian gibt es in Deutschland im Wochenturnus
  2. Rabatte für Disney+ Disney erlaubt Aussetzen des vergünstigten Jahresabos
  3. Netflix-Konkurrenz Disney+ für Telekom-Kunden ein halbes Jahr gratis

  1. Coronakrise: Autobranche will Lockerung der CO2-Ziele
    Coronakrise
    Autobranche will Lockerung der CO2-Ziele

    Die Autoindustrie will mit Blick auf die Corona-Pandemie keine Erhöhung der CO2-Vorgaben und fordert offenbar die Aussetzung von Strafzahlungen.

  2. Golem Akademie: "IT-Sicherheit für Webentwickler" als Live-Webinar
    Golem Akademie
    "IT-Sicherheit für Webentwickler" als Live-Webinar

    Wegen der Corona-Pandemie findet unser Workshop zur IT-Sicherheit für Webentwickler nicht als Präsenzseminar, sondern im Netz statt: in einem Live-Webinar Ende April mit Golem.de-Redakteur und IT-Sicherheitsexperte Hanno Böck.

  3. Recht auf Vergessenwerden: Französisches Gericht kassiert Strafe gegen Google
    Recht auf Vergessenwerden
    Französisches Gericht kassiert Strafe gegen Google

    Im Streit um das sogenannte Recht auf Vergessenwerden hat das oberste Verwaltungsgericht in Frankreich ein altes Urteil gegen Google widerrufen.


  1. 07:59

  2. 07:00

  3. 14:42

  4. 13:56

  5. 13:00

  6. 12:07

  7. 18:41

  8. 15:02