358 – Der menschliche Faktor (bei Unglücken)

12 Responses to 358 – Der menschliche Faktor (bei Unglücken)

1. Thomas P. says:

   December 29, 2020 at 00:43

   Eine etwas unkonventionelle aber trotzdem sehr hörenswerte Episode.

   Danke für die Begleitung durch ein nicht immer leichtes Jahr 2020 und für das tolle Gewinnspiel mit dem Kalender.

   Bleibt gesund und macht weiter so.

   Viele Grüße
   Thomas

2. Markus says:

   December 29, 2020 at 10:04

   Wir brauchen ja mal ein bisschen Abwechslung :-)

3. Köbs says:

   December 31, 2020 at 19:12

   Cooler Talk beim rC3.
   War schön zu sehen das vieles was man hier hört so schön von dir zusammengesetzt wurde.

   Wer es nicht gesehen hat: https://media.ccc.de/v/rc3-851876-models_in_science_opportunities_mechanisms_limitations

4. Martin says:

   January 4, 2021 at 22:00

   Klasse Episode, die mich dieses Jahr bei einem langen Weihnachts-Spaziergang begleitet, danke!

5. Andreas says:

   January 7, 2021 at 18:39

   Danke für eine weitere interessante Folge. Da ich momentan sicherheitsrelevante Software schreibe, habe ich auch ein paar Ergänzungen:

   – Es ist ein gängiger Fall, dass sicherheitrelevante Systeme einen “fail-safe state” haben. Das heißt, es gibt einen “Aus-Zustand”, der inhärent als sicher gilt. Beispiel kann die Eisenbahn sein, zumindest in den meisten Konfigurationen: “Traktion abschalten” und “Türen schließen” sind (normalerweise) sichere Zustände. Mit Systemen bei denen es keinen sicheren Zustand gibt, kenne ich mich nicht aus; sie werden meines Wissens als “mission-critical” (zusätzlich zu “safety-critical”) bezeichnet.

   – Der Sicherheitsnachweis für software-intensive Systeme wird meines Wissens immer auch auf Basis von Checklisten (zumindest abstrakt gesprochen) geführt, z.B. nach IEC 61508, die für viele Bereiche maßgeblich ist. Der Nachweis der “inhärenten Systemsicherheit” auf Basis von geeigneten Untersuchungen des Source Codes ist (leider?) noch nicht möglich, etwa durch formale Verifikation, auch weil das System ja immer noch aus anderen (mechanischen, elektrischen, elektronischen) Teilen besteht mit denen die Software interagiert. Der Nachweis erfolgt also immer (?) auf Basis von Belegen zu einem geeigneten Entwicklungsprozeß.

6. Roger Butenuth says:

   January 13, 2021 at 21:15

   Die Notlandung in Wien ohne Sprit kann man glaube ich durchaus als menschliches Versagen verbuchen, auch wenn die Ursprungsursache (Fahrwerk) Technik war: Der Copilot hat den Piloten auf den mangelnden Sprit hingewiesen. Genug Zeit zum Denken und etliche Flughäfen zum Landen auf dem Weg hätte es auch gegeben.

   Quelle: https://de.wikipedia.org/wiki/Hapag-Lloyd-Flug_3378

7. Wolfgang Klenk says:

   January 16, 2021 at 14:07

   Dein Begriff von “Komplexität”: Bin nicht ganz einverstanden mit deiner Aussage, umfangreichen Software-Systeme würde generell Komplexität anhaften, weil es immer wieder zu emergentem Verhalten kommt. Andere (z.B. Gerhard Wohland) würden solche Systeme als “kompliziert” definieren, aber niemals als “komplex”. Sind denn automatisch alle Systeme, bei denen geschlampt wurde, wo Inkompetenz vorlag oder bewußt technische Risiken oder “technical debt” eingegangen wurde, etwa “komplex” ? Kann sich der schlampige oder imkompetente Architekt rausreden, wenn sein Haus beim gerinsten Erdstoss in sich zusammen fällt, dass Statikberechnungen halt ein sehr “komplexes” Themenfeld ist? Wohl kaum.

8. Markus says:

   January 17, 2021 at 11:16

   Softwaresysteme einer bestimmten Größe sind auf jeden Fall kompliziert. Das ist glaube ich unbestritten. Auch ohne technical debt. Einfach aufgrund der Freiheitsgrade aller verwendeten Komponenten. Ich glaube aber auch, dass viele auch komplex sind, in dem Sinne, dass die Wirkmechanismen und “Hidden Paths” nicht bekannt sind und auch nicht in ihrer Gesamtheit sein können. Und dann gibt es auch noch komplett unkennbare Komplexitäten durch Bugs, bspw. dass Dinge die eigentlich voneinander isoliert sein sollten doch Einfluss haben. Und bei hochasynchronen und verteilten Systemen ist die Komplexität ja auch fast direkt erkennbar. Deshalb wird ja auch so viel Aufwand in Monitoring und Metriken gesteckt. Man muss das System regelrecht beobachten um mitzubekommen wo sich Probleme abzeichnen die später vielleicht zu einem Gesamtversagen führen.

9. Stephan says:

   January 22, 2021 at 02:10

   Schöne Abwechslung. Zum Thema Software-Komplexität: Man überlege mal, wie viele Zeilen Code moderne Software-System haben – und jede von denen ist zumindest in dem Kontext einmalig. Andere technische Systeme mögen mehr Einzelteile haben, aber die sind oft in immer gleiche Komponenten verbaut.

   Ein anderer Punkt, der mir zu kurz kam: Ja, wir akzeptieren beim Autoverkehr einige Tausend Tote pro Jahr. Aber wir würden es nicht akzeptieren, wenn ein Schützenverein einmal im Jahr auf Treibjagd durch die Fußgängerzone geht und auch nur ein paar hundert Passanten erschießen würde. Es kommt nicht nur auf die Zahl der zu erwartenden Opfer an, sondern vor allem auch dafür, was man im Gegenzug für das Risiko bekommt. Beim Auto also sehr weitgehende individuelle Mobilität.

   Und zum Thema TCAS: Da gibt es schon Common Mode Failures mit ATC. Wenn der Transponder ausfällt, dann funktioniert weder TCAS noch sieht der Controller das Flugzeug noch auf dem Schirm (zumindest nicht an aktueller Position). Und wenn ich mich richtig erinnere, dann war das Unglück über Überlingen der Anlass, weltweit einheitlich dem TCAS den Vorzug vor den Lotsenanweisungen zu geben – vorher war das in verschiedenen Ländern verschieden geregelt.

10. Markus says:

    January 22, 2021 at 12:56

    > Es kommt nicht nur auf die Zahl der zu erwartenden Opfer an, sondern vor allem auch dafür, was man im Gegenzug für das Risiko bekommt.

    sehr guter Punkt, ja!

    > Wenn der Transponder ausfällt, dann funktioniert weder TCAS noch sieht der Controller das Flugzeug noch auf dem Schirm

    Ist das echt so? Dass das auf der gleichen Technologie (Mode A/C/S) beruht ist klar, aber ist das echt das gleiche Gerät (sodass dann beides ausfällt?). Aber selbst wenn das so ist, ist es ja trotzdem kein 100% Overlap der Failure Modes und schützt immer noch gegen viele Szenarien.

11. Stephan says:

    January 23, 2021 at 02:09

    Ja, das ist der gleiche Transponder. Aber auch klar: Der Controller hat ja den (E-)strip (oder, bei stripless, die selben Informationen sonstwo), und weiß, dass das Flugzeug in seinem Luftraum ist, und er hat den Piloten auch am Radio. Also ist nicht alles verloren – dann muss er den Flieger halt nach procedural rules separieren. Dann springt der Abstand von 3 Meilen auf 10 Minuten, aber im Prinzip ist das immer noch sicher.

    Als ich in der Branche gearbeitet habe, war ich zuerst etwas überrascht, wie “normal” die Prozesse für die Software waren. Aber nach und nach habe ich gesehen, dass da halt viele verschiedene Schichten existieren, die normalerweise jede für sich für die Sicherheit sorgen. Angefangen bei der Routenplanung mit Medium Term Conflict Prediction, über die Lotsen, unterstützt durch STCA, wenn alles schief geht das TCAS, und die Piloten selbst gucken ja auch noch.

12. Stephan says:

    February 12, 2021 at 02:07

    Ach ja, kurzer Nachtrag: ACAS/TCAS setzt meinem Wissen nach einen Mode-S-Transponder voraus, und war auch einer der Treiber für für die schnelle Durchsetzung dieser Technologie bei den kommerziellen Airlines – in den USA gab es da wohl auch relativ früh ein FAA-Mandat. Wikipedia sagt, dass TCAS auch Mode-C-Signale empfangen kann – dann aber wohl nur einseitig (d.h. das Mode-S-TCAS sieht Mode-C-Transponder, aber nicht umgekehrt). Ich bin mir auch nicht sicher, ob das so stimmt…

This site uses Akismet to reduce spam. Learn how your comment data is processed.