Hallo,
mal eine Frage an die Programmierer unter euch. Als täglicher
PC-Benutzer ist es einem ja geläufig, daß Software zahlreiche Fehler
enthält. Sicherlich kann man einiges verbessern, wenn mehr Aufwand in
das Testen gesteckt wird, aber gibt es sowas wie 100% fehlerfreie
Software?
Vor kurzem habe ich nämlich von einem Bekannten mit Schrecken erfahren,
daß zum Beispiel ein Airbus A320, mit dem ich vor kurzem in den
Ski-Urlaub geflogen bin, von zahlreichen Computern und ihrer Software
total abhängig ist! Also ich meine jetzt nicht das
Inflight-Entertainment oder die Navigationsbildschirme, sondern die
Steuerung von dem Flugzeug! Der Pilot bedient nicht etwa über das Steuer
direkt die Klappen, so wie das auch heute noch beim Auto üblich ist
(direkte mechanische Verbindung + hydraulische Unterstützung), sondern
bedient über den Steuerknüppel nur Potis, die dann elektrische Signale
an einen Computer senden. Dieser prüft, ob die Steuerbefehle überhaupt
sinnvoll sind, rechnet noch ein bißchen rum und gibt dann einen
elektrischen Befehl an den hydraulischen Stellmotor, der die Klappen in
die richtige Stellung bringt. Das müsst ihr euch mal vorstellen, es gibt
keine einzige mechanische Verbindung mehr, nicht mal über Hydraulik. Das
hätte ich nicht gedacht.
Mal ein paar Fragen an euch:
1. Kann man fehlerfreie Software schreiben? Ist sowas überhaupt
Flugzeugtauglich? Ich habe mal gelesen, daß im Flugzeug bewußt nur
ältere, aber dafür als zuverlässig bekannt eingesetzte Techniken
verwendet werden?!
2. Was passiert, wenn sich so ein Steuerungscomputer mal aufhängt oder
verrechnet? Dann kann das Flugzeug doch gar nicht mehr gesteuert werden
und stürzt ab, oder wie muß ich mir das vorstellen? Gibt es im Cockpit
einen großen roten Reset-Knopf?! Wie lange dauert das Booten, was ist,
wenn das kurz vor der Landung passiert?
3. Was ist, wenn mal der Strom ausfällt, ein Stecker abfällt oder oder
oder? Kann so ein Flugzeug heute ohne Strom noch fliegen? Jedenfalls
wird mir jetzt langsam klar, warum Handys an Bord verboten sind.
Mir ist schon klar, daß das irgendwie gehen muß, sonst würden die Teile
ja reihenweise vom Himmel fallen, was sie aber nicht tun, oder habe ich
meinen Bekannten irgendwie falsch verstanden? Ich würde es ja hoffen.
Es grüßt euch der Erwin.
In der C't gibts einen sehr interessanten Artikel zum A380:
Fliegendes Rechnernetz
IT-Technik an Bord des Airbus A380
Report,Flugzeugtechnik,Airbus A380, computerbasierte Flugzeugtechnik,
IT-System, Netzwerkbetrieb,
c't 17/05, Seite 84
Leider ist der Artikel online nicht kostenfrei. Kostet 0,90 Euro. Falls
interesse besteht:
http://www.heise.de/ct/inhverz/search.shtml?T=a380&Suchen=suchen&nm=0
[i] Das müsst ihr euch mal vorstellen, es gibt
keine einzige mechanische Verbindung mehr, nicht mal über Hydraulik.
[/i]
Das wird auch in absehbarer Zeit in Autos der Fall sein. FlexRay macht
´s möglich .
Zumindest, wenn man den zahlreichen Artikeln in "Automotive" & Co traut.
Grüße,
David
Die neuen Airbus Flugzeuge haben alle ein sog. "Fly by Wire" System -
exakt wie du beschrieben hast werden die Anweisungen des Piloten nur
über Sensoren an einen PC gegeben, der die Daten auf Plausibilität prüft
und diese anschließend an Stellmotoren weitergibt. Das System ist
dreifach redundant ausgelegt, es gibt also drei voneinander unabhängige
Systeme von unterschiedlichen Herstellern, die sich gegenseitig
kontrollieren.
Die Vorteile liegen natürlich auf der Hand:
- einfachere Steuerung (z.B. automatisches Austrimmen) für den Piloten
- Sicherere Flugzeuge, da ein Pilot das Flugzeug z.B. nicht mehr
überziehen kann (das Flugzeug also nicht in einen Strömungsabriss
bringen kann, was zum Trudeln führen würde)
Meines Wissens gab es bei diesem System bisher keinerlei
schwerwiegendere Probleme noch irgendwelche Unfälle, die auf dieses
System zurückzuführen sind. Im Gegenteil - es hilft, den häufigsten
Fehler beim Fliegen zu minimieren: menschliches Versagen.
Nichts desto trotz: Sollten die drei PCs tatsächlich gleichzeitig
versagen, liese sich das Flugzeug nicht mehr steuern.
Viele Grüße
Steffen
> 1. Kann man fehlerfreie Software schreiben? Ist sowas überhaupt> Flugzeugtauglich? Ich habe mal gelesen, daß im Flugzeug bewußt nur> ältere, aber dafür als zuverlässig bekannt eingesetzte Techniken> verwendet werden?!
Die fly-by-wire Technik des A320 ist nun rund 20 Jahre alt und hat sich
nach anfänglichen Schwierigkeiten und Nachbesserungen (leider mit
Blutzoll) bewährt und als zuverlässig erwiesen. Die Nachfolger von
Airbus bauen alle auf dieser Technik auf.
Garantiert fehlerfreie Software ist kaum möglich. Es gibt eine Art
"Norm" für Software in der Luftfahrt, die DO-178. Diese definiert
verschiedene Software-Levels von A bis E, mit extrem strengen (A) bis
keine (E) Anforderungen an die Software-Qualität. Welcher Level
gefordert ist, richtet sich danach, welche Gefährdung ein Fehler
anrichten kann. Für Software auf Rechnern, die direkt in die Flugführung
eingreifen, kommen natürlich nur die höchsten Level in Betracht, während
für das Inflight-Entertainment wohl E ausreichend sein dürfte (kein
Einfluß auf die Flugsicherheit). Die Hersteller von Flugzeugen
definieren meistens eigene Anforderungen über die DO-178 hinaus, da
diese weniger konkrete Forderungen enthält, sondern hauptsächlich eine
Art Qualitätsmanagement für die exakte Definition von Anforderungen,
Schnittstellen und Verifikation der Software implementiert.
> 2. Was passiert, wenn sich so ein Steuerungscomputer mal aufhängt oder> verrechnet? Dann kann das Flugzeug doch gar nicht mehr gesteuert werden> und stürzt ab, oder wie muß ich mir das vorstellen?
Zum Software-Level A gehört beispielsweise, daß man sich gerade nicht
auf die Fehlerfreiheit der Software verläßt. Stattdessen wird dreifache
Redundanz mit "dissimilarity" und "independance" gefordert. Das bedeutet
zum Beispiel, es werden drei Rechner mit drei verschiedenen Prozessoren,
drei verschiedenen Programmiersprachen, drei verschiedenen Compilern und
drei verschiedenen Programmierern nach dem gleichen Pflichtenheft gebaut
und in das Flugzeug installiert. Die Kraft, die an der Klappe wirkt, ist
dann der "Durchschnitt" der drei Ausgabewerte dieser Rechner. So ist ein
Fehler, der zu einem Totalausfall führt, extrem unwahrscheinlich. Wenn
sich ein Rechner aufhängt oder verrechnet, wird er von den anderen
beiden überstimmt. Selbstverständlich sind alle Rechner mit mehrfacher
Stromversorgung versehen und auch räumlich an verschiedenen Orten im
Flugzeug eingebaut.
> Gibt es im Cockpit einen großen roten Reset-Knopf?!
Im Cockpit eines Flugzeugs sind grundsätzlich alle Sicherungen
erreichbar, d.h., man kann beliebige Systeme und Instrumente kurzzeitig
abschalten und wieder einschalten (Reset).
> 3. Was ist, wenn mal der Strom ausfällt, ein Stecker abfällt oder oder> oder? Kann so ein Flugzeug heute ohne Strom noch fliegen?
Nein, heutzutage brauchen alle wesentlichen Systeme Strom. Es gibt an
Bord aber mehrfache Redundanz, so hat jedes Triebwerk einen Generator,
der alleine das Bordnetz versorgen könnte. Dazu kommt eine dritte
Turbine mit Generator (APU), die zusätzlich bei Bedarf gestartet werden
kann (sie dient normalerweise dazu, das Flugzeug am Boden mit Strom,
Druckluft und Hydraulikdruck zu versorgen, wenn die Triebwerke nicht
laufen). Außerdem gibt es wie im Auto noch eine Batterie, und der A320
kann zusätzlich noch über einen hydraulisch angetriebenen Generator
Notstrom erzeugen. Manche Flugzeuge haben auch eine R.A.T., eine Art
kleines Windrad, das an der Rumpfunterseite ausgefahren werden kann und
ebenfalls das Hydrauliksystem versorgt und einen Generator antreibt. Ein
echter Stromausfall ist damit quasi ausgeschlossen.
Übrigens läßt sich der A320 trotzdem noch rein mechanisch landen, dies
wurde während der Flugerprobung nachgewiesen. Denn das Seitenruder und
die manuelle Trimmung funktionieren nach wie vor mechanisch, und beide
Komponenten reichen aus, um eine ausreichend lange Landebahn anzusteuern
und sicher zu landen.
Weshalb gibt es (fast) keine fehlerfreie Software ?
1)Die Anforderungen und das Problem stimmen nicht ueberein.
2)Die Anforderunegn und die Loesung passen nicht ueberein.
3)Die Software ist nicht aus einem Guss und die Nahtstellen der
verschiedenen Teile passen nicht aufeinander.
Wie erreicht man das ?
1)Das Problem wurde nicht richtig erkannt
2)Die Aufgabenstellung wurde nicht richtig definiert.
3)Die Aufgabenstellung wuerde nachtraeglich geaendert
So etwa. Daraus kann man folgern, dass einfache Programme fehlerfrei zu
schreiben einfach ist, aber komplexe Programme schwierig werden.
Der Programmcode wo am fehlerfreisten ist der vom Space Shuttel mit
einer Fehlerrate von 0,1% pro Tausend Programmzeilen.
Windows XP hat als vergleich ca 8% pro Tausend Programmzeilen.
Diese 3-fach redundaten Auslegung mit unterschiedlichen Technologien und
Algorithmen hört sich zwar gut an, bringt aber wenig. Untersuchungen
haben gezeigt, dass die Denkfehler (eher Denkschwächen) von Menschen an
denselben Stellen auftreten.
Die Entwicklung bugfreier Software ist nicht möglich, da schon die
Compiler selbst nicht fehlerfrei sind.
Man kann Softare mit verschiedenen Szenarien so testen, dass man z. B.
sagen kann, dass sie zu 99% fehlerfrei ist.
Wird so übrigens auch bei mechanischen und elektrischen System an Board
von Flugzeugen gemacht. 100% Fehlerfreiheit ist nicht möglich und man
kalkuliert von vorne herein ein, dass bestimmte Komponenten kaputt gehen
werden. Durch redundante Installation versucht man diesem Problem dann
zu begegnen.
Dummerweise haben aber auch die Fluggesellschaften ein Mitspracherecht
und hier ist es so, dass teilweise auf den Einbau redundanter Systeme
aus Kostengründen verzichtet wird, wenn diese nicht vorgeschrieben sind.
Eine bestimmte Absturzwahrscheinlichkeit mit einer bestimmten Opferzahl
und aller dadurch resultierender Kosten (Versicherung etc.) ist auf die
Lebenszeit eines Flugzeugs hochgerechnet günstiger, als wenn man die
gesamte Flotte mit bestimmten, teuren Installationen ausstattet.
Sicher glaube ich das. Ich kann mal daheim auf der Festplatte von meinem
alten Rechner schauen, da hatte ich Unterlagen von Untersuchungen
darüber.
Einfaches Besipiel: Egal, ob ich die Fakultät rekursiv oder Iterativ
berechne, die größten Fehlerquellen sind Überläufe des Ergebnisses und
ungültige Argumente.
>Einfaches Besipiel: Egal, ob ich die Fakultät rekursiv oder Iterativ>berechne, die größten Fehlerquellen sind Überläufe des Ergebnisses und>ungültige Argumente.
Das sind beides Fehler die der Programmierer zu verantworten hat. Ein
Programmierer mit fundiertem Fachwissen wird sofort erkennen das er auf
beides achten muß. Ungültige Argumente fängt er mit aktiven Code schon
am Beginn seiner Blackbox ab und meldet einen Fehler zurück. Den
Überlauf bei den Berechnung wird er im Falle der Fakultät ebenfalls am
Anfang abfangen können, denn das maximal gültige Argument um ein noch
gültiges Resultat zu erzeugen, lässt sich auf dem Papier exakt
vorrausberechnen. Dazu muß man natürlich Kenntnisse der Mathematik
besitzen und der Programmierer muß auch willens sein sowas zu
berücksichtigen. Im Grunde sind exakt diese Vorrausüberlegungen die
Programmierung einer Software, also die vorherige Planung. Die
Codierung, das Reinhämmern des Programmes, ist schon keine
Programmierung mehr, auch wenn beides öffters miteinander verwechselt
wird.
Ergo: beide Argumente sind im Falle dieses Threads irrelevant. Denn bei
solch redundanten Systemen ist es eben nunmal so das 3 verschiedene
Teams mit 3 unterschiedlichen Werkzeugpaletten auf 3 unterschiedlichen
Hardwareplattformen 3 komplette unterschiedliche Lösungen erarbeiten.
Es ist also logisch und auch praktisch erwiesen das dann Fehler sehr
unwahrscheinlich an in allen 3 Systemen an der gleichen Stelle
auftreten. Das kann im Grunde nur passwieren wenn die Vorgaben an die 3
Teams schon einen grundsätzlichen Denkfehler enthielt, sprich
antagonistische Forderungen an die Software existieren.
Gruß Hagen
> Der Programmcode wo am fehlerfreisten ist der vom Space Shuttel mit> einer Fehlerrate von 0,1% pro Tausend Programmzeilen.
Dennoch hat der Space Shuttle fünf Computer für die Flugsteuerung, die
sich gegenseitig überwachen...
Ich war mal eine Zeit lang im militärischem Sektor als Softi tätig.
Dort gab es ebenfals extrem strenge Auflagen.
Zusätzlich schrieb der Auftraggeber diverse sachen vor, wie z.B.
Entwicklungsumgebung, Programmiersprache, Verbot von oo(!!!),
Quellcodeauslieferung, extreme (Europalettenweise!!!) Lasten und
Pflichtenhefte,...
Die Programentwicklung lief unter umständen mehrere Jahr(zehnt)e!!! und
frei nach dem Motto, "Never change a running system" wurde altberwertes
(getestetes und für gut befundenes) auch weiter verwendet. So ist es
kein wunder, das als vorraussetzung manchmal 10-20 Jahre alte Hardware
oder ebensoalte aber eben bewerte Softwaretools benutz werden müssen!
und mal so unter uns, welcher Programmieranfänger (ja sogar studierter
Informatiker, Ing,...) kann heute nach dem Studium Programmieren (ich
meine richtig) und wenn, dann meinst nur mit den Modesprachen (möglichst
viel OO) mit viel Overhead. Ganz zu schweige das sie etwas von "sicherem
Programmieren" wissen! Welcher neuling kann denn noch die Urväter wie
Fortran, C, Ada und co? Ja gut, vielleicht so etwas C... Aber sonst?
Basic ? ;-)
Auch eben die Codierrichtlinien sind wirklich extrem streng.
Und das testen... fängt an mit Codeanalyse auf einhaltung der
Codierrichtlinien, diversen Test (von einzelnen Modulen) - Blackbox -
Whitebox ..., Feldversuche/einsatz,...
und dann macht der auftraggeber noch einmal das selbe...
Fehler sind hier natürlich nicht ausgeschloss, aber wenn dann im Einsatz
einer gefunden wird (nahezu (aber nicht 100%ig) ausgeschlossen das es
etwas wie ein Bufferoverflow ist) dann ist es leider so, das es ein
fehler im Design ist, und somit wieder neu angesetzt werden muss.
Bei den Systemen wird meines Wissens sowohl die Software als auch die
Hardware von verschiedenen Firmen unabhängig voneinander entwickelt und
gebaut. Sie arbeiten sogar auf unterschiedlichen Prozessorarchitekturen.
> Der Programmcode wo am fehlerfreisten ist der vom Space Shuttel mit> einer Fehlerrate von 0,1% pro Tausend Programmzeilen.
"Prozent" ist eine Relative Angabe und heißt "pro Hundert". Daher ergibt
es keinen Sinn, von "Prozent pro Tausend" zu sprechen.
> aber gibt es sowas wie 100% fehlerfreie Software?
Es gibt wohl Möglichkeiten zur Validierung von Software, also allgemein
zu beweisen, daß sie keinen Fehler enthält. Leider ist das für
nicht-triviale Programme praktisch nicht machbar.
> Der Pilot bedient nicht etwa über das Steuer direkt die Klappen, so wie> das auch heute noch beim Auto üblich ist (direkte mechanische> Verbindung + hydraulische Unterstützung),
Was denkst du, welche Chancen der Pilot hat, mit der bloßen Hand so ein
großes Flugzeug sicher zu landen, wenn die Hydraulik ausfällt? Außerdem
ist ein nicht unerheblicher Anteil der Abstürze auf Pilotenfehler
zurückzuführen. Aus demselben Grund will man ja auch im Auto die
mechanische Kopplung entfernen. Das System kann einerseits genauer die
Situation beurteilen und die Steuerung perfekt daran anpassen,
andererseits kann es auch Dinge, die der Fahrer direkt nicht kann (z.B.
einzelne Räder gezielt abbremsen, um bei Schleudergefahr das Fahrzeug zu
stabilisieren).
> Ich habe mal gelesen, daß im Flugzeug bewußt nur> ältere, aber dafür als zuverlässig bekannt eingesetzte Techniken> verwendet werden?!
Kann ich mir gut vorstellen. In der Raumfahrt ist das die gängige
Praxis. Einerseits sind die alten Systeme oft weniger empfindlich,
andererseits kennt man sie sehr genau. Sie sind nicht unbedingt
fehlerfrei, aber man kennt die Fehler.
> Jedenfalls wird mir jetzt langsam klar, warum Handys an Bord verboten> sind.
Ja? Ich kann dir den Hauptgrund sagen: Damit man das teure
Satellitentelefon an Bord benutzen muß. Oder ist dir schon mal der
Rechner abgestürzt, wenn du in seiner Nähe telefoniert hast?
>Ich kann dir den Hauptgrund sagen: Damit man das teure>Satellitentelefon an Bord benutzen muß.
Nein.
Man ist nicht einfach in der Lage, zu 100% auszuschließen, dass ein
Mobiltelefon nicht doch die Elektronik des Flugzeugs stören könnte.
Daher werden diese Geräte verboten, und man hat sich somit rechtlich auf
eine klare Schiene gestellt.
Warum gibt es dann unterschiedliche IC-Versionen?
Einmal die normale und dann noch die military/aeronautic/medical?
Die Benutzung der normalen Version für den anderen Zweck wird seitens
der Hersteller ausgeschlossen.
Mal ganz abgesehen von atmosphärischen Störungen in 10km Höhe und
Röntgenstrahlung und...
ausserdem ist ein mechanisches System wesentlich anfälliger
(Materialermüdung, Verschleiss usw.)
Da sind mir ein paar Drähte wesentlich lieber als. z. B. ein Seilzug
"Meines Wissens gab es bei diesem System bisher keinerlei
schwerwiegendere Probleme noch irgendwelche Unfälle, die auf dieses
System zurückzuführen sind. "
Da fällt mir ganz spontan der Unfall eines Lufthansa Airbus in Polen
ein, der mit Rückenwind landen musste. Man ist bei Airbus davon
ausgegangen, dass der Pilot nur bremsen darf, wenn alle Räder auf dem
Boden sind und die Software hat entsprechend alle Bremsvorgänge
unterbunden, solange nicht alle Räder auf dem Boden waren.
Tatsächlich nutzen aber die Piloten in solchen Situationen, wo das
Flugzeug sehr lange schwebt und nicht wirklich runter will, die Bremsen
auch der einzelnen Räder sobald dieses Rad Kontakt hat, um das Flugzeug
langsam runterzubremsen. Da das hier von der elektronik verhindert
wurde, ist das Flugzeug dann über die Landebahn hinausgeschossen und in
einen Wall geknallt.
Davon abgesehen ist so ein Flugzeug viel weniger sicherheitskritisch als
z. B. ein Auto. Wenn z. B. das Seitenruder ausfällt, kann das mit
Querruder kompensiert werden, fällt das Höhenruder aus, mit den
Triebwerken usw. usf. Dazu kommt, dass Experten am Steuerknüppel sitzen,
die solche Situationen regelmässig trainieren.
Da ist ein Auto viel problematischer. Wenn da bei 200 die Lenkung
ausfällt, ist nichts zu kompensieren.
Gruss
Axel
@ Peter Loeschnig
>ausserdem ist ein mechanisches System wesentlich anfälliger>(Materialermüdung, Verschleiss usw.)>Da sind mir ein paar Drähte wesentlich lieber als. z. B. ein Seilzug
;-)
Du bist witzig.
Schau dir mal die Ausfälle im Automobilbau an. Da ist die Elektronik
führend.
Ebenso ist man im Flugzeugbau SEHR vorsichtig gewesen, als man
Elektronik an sensible Sachen wie Steuerung etc. rangelassen hat. Fly by
Wire klingt zwar schön, ist aber praktisch mit vielen Problemen
verbunden.
Materialermüdung bei hydraulischen Systemen ist nicht das grosse Thema.
Stichwort Wartung und vorbeugendes Wechseln von Bauteilen.
@Axel
>Davon abgesehen ist so ein Flugzeug viel weniger sicherheitskritisch als>z. B. ein Auto.
???
Nun dass dort 100-500 Leute drin sitzen und sich ggf. 10km über der
Erdoberfläche aufhalten. Wobei die meisten Probleme bei Start und
Landung auftreten.
> Wenn z. B. das Seitenruder ausfällt, kann das mit>Querruder kompensiert werden, fällt das Höhenruder aus, mit den>Triebwerken usw. usf. Dazu kommt, dass Experten am Steuerknüppel sitzen,>die solche Situationen regelmässig trainieren.
Sicher, aber das sind nicht die Flugphasen in denne die meisen Probleme
auftreten.
>Da ist ein Auto viel problematischer. Wenn da bei 200 die Lenkung>ausfällt, ist nichts zu kompensieren.
Und wie ist es bei einem 200 Tonnen Flugzeug das mit 250 km/h landet?
Seitenwind? Böen? Turbulenzen von vorausfliegenden Flugzeug?
MFG
Falk
Ein Auto kann ueberhaupt nicht mit einem Flugzeug verglichen werden. Das
Flugzeug bewegt sich als relativ steifes Objekt fluiddynamisch in einem
kompressiblen Medium. Das ist nicht wirklich gefaehrlich solange der
Boden genuegend weit weg ist. Ein Auto auf der anderen Seite hat eine
starke Kopplung zum Untergrund, und schon 100ms Unachtsamkeit koennen
das Aus bedeuten. Die Umgebung ist fuer das Auto sehr viel wichtiger,
und die kann von einem Computer schlecht ueberblickt werden.
Will sagen, dass auch das sicherste Auto mit der optimalen Steuerung und
Bodenhaftung verloren ist wenn ich mit zu viel Geschwindigkeit in eine
Kurve gehe. Die Kurve ist da. Der Kurvenradius ist vorgegeben, daneben
ist Pampa. Die Physik sagt nun, dass das Auto bei 80 nicht rumkommt. Da
kann ein Computer auch nichts machen. Und tschuess.
@ Nilp
>ist Pampa. Die Physik sagt nun, dass das Auto bei 80 nicht rumkommt. Da>kann ein Computer auch nichts machen. Und tschuess.
Ja eben. Das Problem ist der Mensch, welcher nicht vernünfig fährt. Das
lässt sich mit verdammt viel HighTec zwar ewas dämpfen, ist aber IMHO
der falsche Weg.
MFG
Falk
"Und wie ist es bei einem 200 Tonnen Flugzeug das mit 250 km/h landet?
Seitenwind? Böen? Turbulenzen von vorausfliegenden Flugzeug?"
Wie ich bereits schrieb: Die Piloten trainieren solche Situationen
regelmässig, wobei natürlich auch der Ausfall der verschiedensten
Systeme simuliert wird.
Dagegen ist beim durchschnittliche Autofahrer schon der Ausfall der
Bremse ein sicherer Crash. Statt einfach die Handbremse zu benutzen,
fährt der das Ding irgendwo gegen.
Und in 10km Höhe ist das sowieso unkritisch. Wenn da Elektronik
ausfällt, hat man viiieeeel Zeit zu reagieren oder neu zu booten.
Gruss
Axel
@ Axel
>Dagegen ist beim durchschnittliche Autofahrer schon der Ausfall der>Bremse ein sicherer Crash. Statt einfach die Handbremse zu benutzen,>fährt der das Ding irgendwo gegen.
Stimmt.
>Und in 10km Höhe ist das sowieso unkritisch. Wenn da Elektronik>ausfällt, hat man viiieeeel Zeit zu reagieren oder neu zu booten.
Vor allem mitten über dem Atlantik. Da bekommt das Wort "booten" mal
ganz schnell eine neue Bedeutung ;-)
MfG
Falk
Also um eine Software 100%ig zu beweisen bedarf es einiger Mathematiker
die sonst nix zu tun haben :-P
Das einzige Programm was komplett mathematisch bewiesen wurde ist soweit
ich weiß Fortran77, dazu wurden ein paar Jahre benötigt.
Software wird i.d.R. systematisch getestet und innerhalb der
vorgestecken Rahmenbedingungen abgenommen.
Beispiel Programmbeweis:
Pseudocode:
i := 1;
while 1<n do
i:= i+1;
Vorbedingung P={n€N}
Nachbedingung Q={(i,n € N)&(i=n)}
(ähm, keine mathematischen Symbole, sorry :-P )
Partielle Korrektheit:
{P} Init {I}
{I&B} K {I}
{I&-B} => {Q}
{n€N} i:=1 {i <= n}
{(i<=n)&(i<n)} i:=i+1 {i<=n} da i+1<n => i<=n
{(i<=n)&(i>=n)} => {(i,n€N)&(i=n)}
QED
Terminierung:
{I&B} => t > 0
{I&B} T:=t;k {t < T}
{I&-B} => {t <= 0}
Totale Korrektheit:
t = Variante = n-i
{(i<=n)&(i<n)} => n-i>0
{(i<=n)&(i<n)} t:=n-i; i:=i+1 {n-(i+1)<n-i}
{(i<=n)&(i>=n)} => {(i,n € N)&(i=n} => {n-i<=0}
Mit der partiellen Korrektheit zusammen folgt aus obigem die totale
Korrektheit des Programms.
Rekursionen sind vieeeel schöner, doch bissle zu Tippintensiv :-P
Man kann sagen, das für den mathematischen Beweis eines
durchschnittlichen Programms von 5.000 Zeilen Quelltext ca. 8.000 Seiten
DIN-A4 für den Beweis notwendig sein dürften :-P
Selbst bei Medizingeräten wird ein solcher Aufwand nie betrieben.
Von daher ist es kein Wunder, wenn der Busfahrer an jeder Haltestelle
die Zündung ausmacht und wieder an damit die Elektronik wieder
funktioniert :-P
Er hat ja keinen Resetknopf auf dem Amarturenbrett :-P
Viel Spaß beim finden der angewandten Regeln :-P
>>Der Programmcode "wo" .. ?>>Autsch!>>Der Dativ ist dem Genitiv sein Tod ;)
Möglicherweise ist der Poster Schweizer (ich auch)..."Der Programmcode
wo.." ist perfektes Schweizerdeutsch.
Nilp wrote:
> Das Flugzeug bewegt sich als relativ steifes Objekt fluiddynamisch in> einem kompressiblen Medium. Das ist nicht wirklich gefaehrlich solange> der Boden genuegend weit weg ist.
Meine Rede - das Gefährlichste beim Flugzeugabsturz sind die letzten 10m
:-)))
schnellweg
Ich will nochmal zur eigentlichen Fragestellung kommen. Um
sicherzustellen, dass eine Software zu 100% fehlerfrei ist, muß sie auch
zu 100% getestet sein. Allerdings steigt mit der Anzahl der
Freiheitsgrade in den Eingaben die Anzahl der möglichen Eingaben rapide
an. Und so ist man schnell an dem Punkt angelangt, wo nur noch die
eigentliche Funktionalität und Reaktionen auf bekannte Fehler getestet
werden können. Wenn diese Tests bestanden sind, kann die Software 100%
bugfrei sein, es kann aber auch jeder nicht berücksichtigte Fehler in
den Eingaben zum Versagen führen.
Gruß Jörg
@Falk Brunner
> Du bist witzig.> Schau dir mal die Ausfälle im Automobilbau an. Da ist die Elektronik> führend.
habe mir eben die ADAC Pannenstatistik angesehen (möchte gerade ein Auto
kaufen):
was da unter 35 % allgemeine Elektrikfehler (klingt viel) steht, hat
aber nur wenig mit Elektronik zu tun:
Batterie defekt, entladen....no na
Generator defekt (denke mal, wenn man beim Service gespart hat)
Antriebsriemen gerissen (wieder eine Servicegeschichte)
Anlasser blockiert (= eigentlich Mechanik)
Kabel gelöst
Sicherung durchgebrannt (immer diese Bastler)
wirkliche Elektronikfehler sind eher selten, obwohl in der
Automobilindustrie ein hoher Preisdruck vorhanden ist.
Peter
@ Joerg Wolfram:
Schau mal ein paar Posts weiter oben vom "Programmbeweiser" :-P
Ansonsten gibt es einige Bücher die sich mit systematischem Testen
auseinandersetzen.
Im Anforderungsprofil sowie Lastenheft sollte sowieso genau festgelegt
sein unter welchen Rahmenbedingungen die Software läuft.
Und was Bedienungsfehler angeht, so sollte man einfach bei den Eingaben
passende "Filter" vorsehen die genau die festgelegten Rahmenbedingungen
definieren, sonst nichts !
Und ganz ehrlich, der Prozessor ist von Menschen entwickelt und gebaut
worden, die Gluelogic darum auch und dann kommen neuerdings überall
Betriebssysteme und Bibliothekn usw. zum Einsatz, da gibt es inzwischen
sooo viele Zwischenschichten das es wirklich seehr erstaunlich ist das
überhaupt Flugzeuge fliegen :-P
>Und in 10km Höhe ist das sowieso unkritisch. Wenn da Elektronik>ausfällt, hat man viiieeeel Zeit zu reagieren oder neu zu booten.
Genau, bravo: Ausfall -> Böhe -> Flugzeug kippt -> Taumeln -> Fliegkraft
...
wenn man Glück hat bricht der Rumpf nicht gleich sondern nur die Flächen
und man ist binnen 3 sek durch den Druckunterschied bewusstlos.
Fazit: nicht mal 1 km der 10 und alle Passagiere verloren.
Beim Auto ist es das selbe Scenario nur das es dort maximal um 5 statt
500 Passagiere geht.
Problemetik bei den Autos ist das die Hersteller nicht so viel Geld zur
Verfügung haben um tests in den selben Grössenordnungen wie bei
Flugzeugen durchführen zu können.
> Vorbedingung P={n€N}> Nachbedingung Q={(i,n € N)&(i=n)}
Und u.U. trotz eines Beweises schon einen Absturz verursacht!
> Es gibt wohl Möglichkeiten zur Validierung von Software, also allgemein> zu beweisen, daß sie keinen Fehler enthält.
Nein, Rice-Myhill-Shapiro-Theorem
> Dagegen ist beim durchschnittliche Autofahrer schon der Ausfall der> Bremse ein sicherer Crash. Statt einfach die Handbremse zu benutzen,> fährt der das Ding irgendwo gegen.
Schon mal ausprobiert was passiert wenn man bei 100 die Handbremse
zieht?
Zur Not tut's auch ein Brett und ein Spielzeugauto. Einmal Vorderräder
blockieren, einmal die Hinterräder.
Um auch mal meinen Senf dazu zugeben:
@Kola
Die Teilung in verschiedene Gruppen hat schon sehr großen Einfluss. Wie
schon gesagt, selbst Compiler haben Fehler. Deshalb nimmt man auch
verschiedene. Auch die Hardware hat Fehler.. deshalb nimmt man auch hier
verschiedene. Und der Mensch macht die größten Fehler, deshalb
verschiedene Programmierer. Es gibt einfach Programmierer die immer die
gleichen Fehler machen. Oder der eine sichert nur einfach ab, der andere
komplizierter .... Möglichkeiten gibt es viele. Das ist im übrigen auch
Vorgabe bei z.B. ABS Systemen im Auto, kommt also nicht nur im Flugzeug
vor. Außerdem werden Programmiersprachen eingesetzt, die eine gewisse
Fehlerüberprüfung schon mitbringen (etwas unglücklich formuliert), ASM
ist verboten, ebenso wie bsp. C (nach meiner Kentniss).
Warum gibt es verschiedene Versionen von ICs? Ganz einfach, die ICs sind
dafür getestet. Fällt ein Medizinisches System aus und haben nicht alle
ICs Med tauglichkeit, ist der IC Hersteller aus dem Schneider wenn da
der Fehler lag. Außerdem hat z.B. das Militär Temperaturbereich von
-55°C, Automotive "nur" -40°, Consumer 0°C. Die "astronomie" Versionen
werden oft in älteren Herstellungsprozessen hergestellt (gröbere
Strukturen etc.) Das kostet alles Geld.
Und das in Flugzeuge nicht Sicherheitsrelevante Dinge eingebaut werden
um kosten zu sparen ist schlicht Schwachsinn. Wahrscheinlich ist das bei
Banana Airlines so, aber nicht bei normalen Fluglinien. Sonst dürfen die
garnicht auf vielen Airports landen, den die schreiben die
Sicherheitskriterien vor. So kam es schon vor, das RUssische Maschinen
ewigkeiten in Frankfurt standen, weil ein redundantes Teil kaputt war
und die Fluglinie kein Geld hatte. Die bekommen halt keine
Starterlaubniss.
Ich denke ein Softwarebug (nix grobes, eher in der Art Faktor 1 + Faktor
2 an Tag X mit Faktoren 10-1000 ... also wahrscheinlichkeit < 1/100000)
ist im Flugzeug nix schlimmes. So ein Airbus kann sehr gut segeln und in
der Zeit in die Software neu gestartet, zur Not auch das ganze System.
Bis komplettes Drive-by-Wire ins Auto kommt werden noch ein paar Jahre
vergehen (und Flexray ist da nicht der Heilsbringer).
> Christian Ulrich:> Genau, bravo: Ausfall -> Böhe -> Flugzeug kippt -> Taumeln -> Fliegkraft> ...
So ein Quatsch! Schon was von Selbststabilisierender Aerodynamik im
Flugzeug gehört? So einfach kippt kein Flugzeug.. (vielleicht ein
Chinesisches ;)
@ arc
>Schon mal ausprobiert was passiert wenn man bei 100 die Handbremse>zieht?>Zur Not tut's auch ein Brett und ein Spielzeugauto. Einmal Vorderräder>blockieren, einmal die Hinterräder.
Handbremse anziehen != blockieren!
Du solltest vielleicht mal ein Fahrsicherheitstraining besuchen.
MFG
Falk
> Handbremse anziehen != blockieren!
Eben! Das stimmt nur bei niedrigen Geschwindigkeiten und meist
rutschiger Fahrbahn. Zieh einfach mal bei 130 die Handbremse und schau
was passiert. Aber lass dich von der Verzögerung nicht in den Gurt
drücken g
(ca. 3-5% wenn du Glück hast)
> Das ist im übrigen auch> Vorgabe bei z.B. ABS Systemen im Auto, kommt also nicht nur im Flugzeug> vor. Außerdem werden Programmiersprachen eingesetzt, die eine gewisse> Fehlerüberprüfung schon mitbringen (etwas unglücklich formuliert), ASM> ist verboten, ebenso wie bsp. C (nach meiner Kentniss)."
In der Automobilindustrie wird C benutzt. Man muss sich dabei an die
MISRA-Guidelines halten, aber da sind z.B. Pointer durchaus erlaubt.
Wenn wir hier schon beim Beweisen von Programmfehlern/Korrektheit sind,
hier ein kleiner Induktionsbeweis:
1) Jede Software enthält mindestens einen Fehler
2) Jede Software lässt sich um mindestens eine Anweisung kürzen
=> Daraus beweisen wir durch Induktion:
Jede Software lässt sich auf eine fehlerhafte Anweisung reduzieren ;)
SCNR,
/Ernst
Sehrwitzig ⌂⌂ wrote:
> Nilp wrote:>> Das Flugzeug bewegt sich als relativ steifes Objekt fluiddynamisch in>> einem kompressiblen Medium. Das ist nicht wirklich gefaehrlich solange>> der Boden genuegend weit weg ist.>> Meine Rede - das Gefährlichste beim Flugzeugabsturz sind die letzten 10m> :-)))>> *schnellweg*
Its not the fall that hurts, its when you hit the ground oder so :D
Hallo,
ich habe bis vor zwei Jahren Sicherheitstechnik für Automobilindustrie
gemacht (Grundlagen für Rückhaltesysteme/el. Rückhaltesysteme /
Gasgeneratorsysteme für Airbags) und mache seitdem Sicherheitstechnik
für Industrieautomatisierung.
Was mir bei dem Wechsel vor zwei Jahren aufgefallen ist, war das die
Industrie in Sachen Normierung und Vorschriften wie Sicherheitsgeräe zu
entwickeln sind weit voraus ist.
Damals hat nur Mercedes ein ausfühliches Lastenheft vorlegen können, das
bestimmte Designrules und Programmierrichtlinien beinhaltete (wohl aus
Ihrer Erfahrung mit der Bremse in der E-Klasse); woh auch ein Grund
dafür ist, das das wenigste am Auto tatsächlich Sicherheitsrelevant ist.
In der der Industrie gibt es eine Norm (IEC61508) nach der wir die
ganzen Produktlebenszyklus behandeln müssen - also von der Planung bis
zur Verschrottung eines Produktes. Dort gibt es detailierte Anweisungen
wie Software für Sicherheitsanwendungen auszusehen hat (angefangen vom
CPU Test, bei dem jeder Assemblerbefehl auf korekkte Funktion überprüft
wird, über zyklische RAM und ROM Test bis hin zu allerlei Diversitäten,
Mehrkanaligkeiten,...).
Jede Maßnahme wird nach ihrer Effektivität bewertet, und somit bekommt
man am Schluß eine Aussage wie gut evtl. Fehler erkannt werden.
Meist ist nämlich ein Fehler gar nicht das Problem, sondern mit welcher
Wahrscheinlichkeit entdecke ich diesen Fehler. Während der Entwicklung
werden Reviews der Software und Hardware durchgeführt, und zwar mit
Leuten aus anderen Abteilungen um die systematischen Fehler zu
minimieren. Natürlich werden auch automatische Test z.B. mit Tessi
gemacht.
Zusammen mit einer Hardware FMEA, einer Bewertung über das "wie" und
"wer" der Entwicklung (z.B. hat der Entwickler bereits Erfahrung mit
Sicherheitsgeräten, ...) und noch ein paar sonstigen Dingen egibt sich
dann durch Formeln eine Zahl, die einem Sicherheits Integritätslevel
(SIL) entspricht. Dieser SIL Level Qualiifiziert dann ein Produkt für
einen bestimmten Einsatz.
Es werden während dieser ganzen Zeit der Entwicklung "Tonnen" Papier für
den TÜV oder BIA erzeugt, die dann bei regelmäßigen Treffen besprochen
werden.
Zur Zertifizierung schließlich kommen Mitarbeiter vom TÜV, und schreiben
Hardwar und Softwarfehlerversuche vor, um das Verhalten des Gerätes zu
testen. Neben diesen Test findet natürlich mit dem TÜV ein Review über
alle sicherheitskritischen Bereiche des SW und HW statt (der TÜV hat
sämtlichen Sourcecode, Schaltpläne und Layouts).
Wie schon oben von jemandem erwähnt, haben auch Compiler und andere
Tools Fehler, so dass bei uns das beste Argument "betriebsbewährt" ist -
also nix mit ständigen Updates.
Das Gerät das ich mit zu betreuen habe ist im Prinzip nix anderes wie
ein "inteligentes" Relais das "sicher" eine Maschine abschalten kann (da
sind 3x AVR Mega88 und 2x M16C drin), wenn z.B. ein Not-AUS gedrückt
wurden.
Wenn ich mir den Aufwand vorstellen den wir für diese einfache Aufgabe
treiben, dann wird das bei den Flugzeugen noch viel mehr sein.
Klar wird es versteckte, systematische Fehler geben, denn ich bin auch
der Meinung wie einer meiner Vorredner, das jeder Entwickler seine
eignen Fehler in eine Maschine baut.
Wenn ich mir aber den Typ vorne am "Lenkrad" des Fliegers ansehe, da
wird mir schon mehr bange, da ist die Ausfallrate doch deutlich höher,
oder ?
Gruß
Alexander
@Alexander Heckmayr
Interessant .. da ich auch in dem Bereich tätig bin (speziell Bremsen)
kann ich nur sagen das wir extrem umfangreiche Lastenhefte haben. FMEA
ist normal. Lass dir mal ein Lastenheft für ein ABS oder gar Airag
Steuergerät geben, das ist schon extrem umfangreich und detailiert.
Das Problem in der Automobilindustrie ist nicht das es keine Normierung
gibt, das Problem ist, jeder hat seine eigenen. Das Problem ist aber oft
auch die Art und Weise wie programmiert wird. Wenn ich nur die
grafischen Entwicklungstools sehe, die dann dermaßen schlechten
Quelltext machen. Da wird einem schlecht. Manchmal frage ich mich wie so
in Auto überhaupt so gut funktionieren kann bei dem Schrott der
teilweise drin ist. Kosten spielen eine große Rolle .. was bringt z.B.
zwei verschiedene Prozessoren die sich gegenseitig überwachen bla bla
bla, wenn auch Kostengründen ein redundanter Spannungswandler oder ein
redundante Endstufe gestrichen wird? Der Kostendruck ist in Industrie
und Luftfahrt bei weitem nicht so stark.
Das Auto hat zudem einen riesen Sicherheitsvorteil (zumindest noch).
Selbst wenn alles ausfällt. Ich kann immernoch hydraulisch bremsen bzw.
ohne Servo lenken. Das ist mehr Sicherheit als jede Elektronik liefern
kann. Das sieht im Flugzeug etwas anders aus..
Außerdem ist der Volkswirtschaftliche Schaden durch ein Industrieunfall
(bsp. Chemieindustrie) oder bei einem Flugzeugabsturz weitaus höher als
bei einem Auto. Stürzt ein Airbus ab, ist der Imageschaden für Airbus
enorm, fällt das ABS aus und baut man ein Unfall nimmt davon keiner
Notiz.
So mackaber es auch ist, aber Sicherheit kostet Geld und davon hat
bekanntlich jeder zu wenig.. wo spart man also? Leider ..
@Alexander Heckmayr
Wie hoch ist denn die geschätzte Lebensdauer des Gerätes mit den M16Cs?
Laut Datenblatt von Renesas hält der Flashspeicher nur 10 Jahre.
@Kola
> Diese 3-fach redundaten Auslegung mit unterschiedlichen> Technologien und Algorithmen hört sich zwar gut an, bringt> aber wenig. Untersuchungen haben gezeigt, dass die Denkfehler> (eher Denkschwächen) von Menschen an denselben Stellen> auftreten.
Würde ich nicht so sehen. Wenn du zwei Programmierern zwei gleiche
Aufgaben gibst, kommen oft schon bei relativ einfachen Problemen zwei
sehr verschiedene Quelltexte heraus. Nimmt man dann noch zwei
verschiedene Programmiersprachen und Hardware-Architekturen, steigt die
Diversität noch weiter. Natürlich gibt es immer die "Klassiker" wie
Überläufe etc., die sich aber wiederum beim Verifizieren recht gut
erkennen lassen.
@Katzeklo
> Wird so übrigens auch bei mechanischen und elektrischen> System an Board von Flugzeugen gemacht. 100% Fehlerfreiheit> ist nicht möglich und man kalkuliert von vorne herein ein,> dass bestimmte Komponenten kaputt gehen werden. Durch> redundante Installation versucht man diesem Problem dann> zu begegnen.
Genauso ist es. Beispiele: Zwei Triebwerke, drei Funkgeräte, 4
unabhängige Stromquellen, Navigation über VOR/DME, INS und GPS, jedes
einzelne Navigationssystem ist dabei mehrfach vorhanden.
> Dummerweise haben aber auch die Fluggesellschaften> ein Mitspracherecht und hier ist es so, dass teilweise auf> den Einbau redundanter Systeme aus Kostengründen verzichtet> wird, wenn diese nicht vorgeschrieben sind.
Klar haben die Käufer ein Mitspracherecht bei der Ausstattung, wenn sie
einen Flieger bestellen. Und zwar nicht nur bei der Farbe der
Sitzpolster, sondern auch bei der Installation bestimmter Systeme im
Cockpit. Allerdings ist die gesetzlich vorgeschriebene
Mindestausstattung wirklich ausreichend für einen sicheren Flugbetrieb.
Es hängt ja auch viel davon ab, ob ein Flugzeug Kurzstrecke fliegt oder
nach ETOPS regelmäßig lange Strecken über den Atlantik fliegt.
> Eine bestimmte Absturzwahrscheinlichkeit mit einer> bestimmten Opferzahl und aller dadurch resultierender> Kosten (Versicherung etc.) ist auf die Lebenszeit eines> Flugzeugs hochgerechnet günstiger, als wenn man die> gesamte Flotte mit bestimmten, teuren Installationen> ausstattet.
So hart es klingt, aber das ist ÜBERALL und IMMER so. Man kann die
Aussattung beliebig weit treiben, aber irgendwann ist vor lauter
Ausstattung kein Platz mehr in der Kabine frei für Passagiere und 100%
Sicherheit ist dennoch nicht erreicht. Daß die zivile Verkehrsluftfahrt
zu den sichersten Verkehrsmitteln überhaupt gehört, beweist doch, daß
die aktuellen Zulassungsvorschriften für Verkehrsflugzeuge streng genug
sind und keineswegs einen faulen Kompromiß darstellen.
@Rolf Magnus
> Was denkst du, welche Chancen der Pilot hat, mit der> bloßen Hand so ein großes Flugzeug sicher zu landen, wenn> die Hydraulik ausfällt?
Die aktuellen Fly-by-wire-Systeme bauen zusätzlich auf die ohnehin
vorhandenen unabhängigen drei Hydrauliksysteme auf und erhöhen damit
erstmal nur die Komplexität und damit Ausfallwahrscheinlichkeit des
Gesamtsystems. Es wird zwischen Steuerhorn und Ruder außen am Flügel
einfach ein zusätzliches Glied eingefügt. Daher kam wohl die
ursprüngliche Befürchtung.
> Außerdem ist ein nicht unerheblicher Anteil der Abstürze> auf Pilotenfehler zurückzuführen.
Und genau da soll das Fly-by-wire-System ansetzen: Die Komplexität der
Flugzeug-Steuerung wird erhöht, die Sicherheit verringert sich. ABER:
Durch die Entlastung, Unterstützung und letztendlich auch Kontrolle des
Piloten durch das System wird wieder ein Sicherheitsvorteil erreicht,
und Airbus geht davon aus, daß das Gesamtergebnis deutlich positiv ist.
Boeing zieht mit den aktuellen Fliegern nach, wenn auch nicht ganz so
konsequent, so daß man Fly-by-wire heute wohl als Stand der Technik
ansehen muß.
@Katzeklo
> Man ist nicht einfach in der Lage, zu 100% auszuschließen,> dass ein Mobiltelefon nicht doch die Elektronik des Flugzeugs> stören könnte. Daher werden diese Geräte verboten, und man hat> sich somit rechtlich auf eine klare Schiene gestellt.
Genauso ist es. Allerdings ist es heute die vorherrschende
Expertenmeinung, daß Mobiltelefone in der Kabine oder im Cockpit
tatsächlich keine Störungen verursachen. Die Abschirmung der Avionik und
der Kabelbäume ist mehr als ausreichend und viel besser als beim
heimischen PC. Es gab zwei oder drei bisher ungeklärte Zwischenfälle mit
"seltsamen" Elektronikfehlern im Flug, bei denen sich später
herausgestellt hat, daß ein Passagier unerlaubt ein Mobilfunkgerät in
Betrieb hatte. Ob da wirklich ein Zusammenhang bestanden hat, darf aber
angezweifelt werden.
@Peter Loeschnig
> ausserdem ist ein mechanisches System wesentlich> anfälliger (Materialermüdung, Verschleiss usw.)> Da sind mir ein paar Drähte wesentlich lieber als> z. B. ein Seilzug
Das ist ein weit verbreitetes Vorurteil. Eine einfache mechanische
Steuerung mit einem Seilzug, die selbstverständlich mit ausreichender
Sicherheit dimensioniert sein muß, ist an Zuverlässigkeit kaum zu
überbieten - und wenn, dann bestimmt nicht mit Elektrik. Was sollte
daran kaputt gehen? Ein wichtiger Punkt ist, daß die Seile, Umlenkrollen
und alle Verbindungen wie Kauschen und Spannschlösser bei den
regelmäßigen Wartungen ganz einfach optisch kontrolliert werden können.
Darüber hinaus gibt es für die Verschleißteile festgelegte
Betriebszeiten, bei denen sie grundsätzlich ausgetauscht werden, auch
wenn sie noch gut aussehen. Versuch mal, einem Steuergerät oder
Kabelbaum von außen anzusehen, ob es/er die nächsten 50 Flugstunden noch
zuverlässig durchhält. Die Umgebungsbedingungen im Flugzeug (extreme und
schnelle Temperaturschwankungen, Luftdruck, Vibration, verschiedenste
aggressive Flüssigkeiten, elektromagnetische Felder verschiedenster
Frequenzen mit hohen Feldstärken) sollte man nicht unterschätzen!
@Axel
> Man ist bei Airbus davon ausgegangen, dass der Pilot> nur bremsen darf, wenn alle Räder auf dem Boden sind> und die Software hat entsprechend alle Bremsvorgänge> unterbunden, solange nicht alle Räder auf dem Boden> waren.
Das macht auch Sinn und ist bei ALLEN größeren Verkehrsflugzeugen so.
Bei Airbus wird über zwei Sensoren, die das Einfedern beider
Hauptfahrwerke erkennen, vom "air" in den "ground"-Modus umgeschaltet,
wodurch verschiedene Systeme (Reverser, ground spoiler, Radbremsen) erst
freigeschaltet werden. Die "air/ground"-Logik ist selbstverständlich
redundant und verhindert größeres Ungemach. Man stelle sich nur mal vor,
man würde bei starkem Seitenwind mit leichter Schräglage aufsetzen (was
normal ist) und dann "einseitig" bremsen - der schwere Unfall wäre
vorprogrammiert.
> Tatsächlich nutzen aber die Piloten in solchen> Situationen, wo das Flugzeug sehr lange schwebt> und nicht wirklich runter will, die Bremsen> auch der einzelnen Räder sobald dieses Rad Kontakt> hat, um das Flugzeug langsam runterzubremsen.
Nein. Mit der Radbremse gebremst wird erst, wenn alle Räder am Boden
angekommen sind. Bei solchen Wetterlagen wird das Flugzeug bewußt in den
Boden geflogen (d.h. etwas härtere Landung), um ein langes Ausschweben
zu vermeiden.
> Da das hier von der elektronik verhindert wurde,> ist das Flugzeug dann über die Landebahn> hinausgeschossen und in einen Wall geknallt.
Der Unfall hatte wie die meisten Flugunfälle mehrere Ursachen. Die
wichtigste war eindeutig, daß mehrere zwingende Voraussetzungen für eine
sichere Landung nicht gegeben waren, die Piloten aber trotzdem nicht
durchstarteten (mehr würde jetzt zu weit führen). Die
"air/ground"-Logik, die in diesem Fall tatsächlich zu spät umschaltete,
war nur ein beitragender Faktor - sie wurde nach dem Unfall auch
überarbeitet. Sie ist, wie gesagt, in ähnlicher Form auch in allen
Verkehrsflugzeugen vorhanden.
> Davon abgesehen ist so ein Flugzeug viel weniger> sicherheitskritisch als z. B. ein Auto. Wenn z. B. das> Seitenruder ausfällt, kann das mit Querruder kompensiert> werden
Das sehe ich anders! Dein Auto kannst du am Straßenrand ausrollen
lassen. Die passive Sicherheitstechnik ermöglicht dir ziemlich hohe
Überlebenschancen, wenn du mit defekter Lenkung einen Abflug machst. Im
Flugzeug kann sich jedes kleine Problem zu einem massiven Notfall
entwickeln, weil du dich in einer unnatürlichen und lebensfeindlichen
Umgebung aufhältst und ein halbwegs funktionierendes Gerät brauchst, um
wieder sicher auf den Erdboden zurückkehren zu können. Ein Brand im Auto
ist kein großes Problem, rechts ranfahren, aussteigen, wegrennen. Was
machst du im Flugzeug?
Deshalb sind die Zulassungsvorschriften für Flugzeuge auch DEUTLICH
strenger als für Fahrzeuge.
Ein ausgefallenes Seitenruder ist bei der Landung ein großes Problem,
ein ausgefallenes Querruder kann nur bedingt mit dem Seitenruder
kompensiert werden! Ein Ausfall in der primären Steuerung ist nicht ein
Problem, das man mal eben kompensiert, sondern der Grund, eine
Luftnotlage zu erklären und sofort zu landen.
> fällt das Höhenruder aus, mit den Triebwerken usw. usf.
Das halte ich für ein Gerücht. Ein ausgefallenes Höhenruder ist eine
ziemlich hoffnungslose Situation, die man maximal mit der Trimmung
retten kann, wenn diese noch funktioniert. Daß Captain Al Haynes seine
defekte DC 10 halbwegs kontrolliert innerhalb eines Flughafenzaunes hat
einschlagen lassen können, war ein Glücksfall und hat trotzdem viele
Menschenleben gekostet.
> Dazu kommt, dass Experten am Steuerknüppel sitzen,> die solche Situationen regelmässig trainieren.
Solche Situationen eher nicht.
@ 433MHz-Frager
> Und ganz ehrlich, der Prozessor ist von Menschen> entwickelt und gebaut worden, die Gluelogic darum auch> und dann kommen neuerdings überall Betriebssysteme und> Bibliothekn usw. zum Einsatz, da gibt es inzwischen> sooo viele Zwischenschichten das es wirklich seehr> erstaunlich ist das überhaupt Flugzeuge fliegen :-P
Diese Zwischenschichten gibt es natürlich in den kritischen Rechnern im
Flugzeug nicht. Bei redundanter Auslegung dürfen natürlich auch nicht
die gleichen Bibliotheken oder Betriebssysteme genutzt werden, sonst
wäre der ganze Aufwand ja für die Katz. Und ein 10 bis 20 Jahre alter
Prozessor ist auf der ganzen Welt sehr ausführlich getestet worden, so
daß er mit ziemlich großer wahrscheinlichkeit entweder fehlerfrei ist,
oder aber alle Fehler bekannt sind und berücksichtigt werden können.
@opacer
> Und das in Flugzeuge nicht Sicherheitsrelevante Dinge> eingebaut werden um kosten zu sparen ist schlicht Schwachsinn.> Wahrscheinlich ist das bei Banana Airlines so, aber nicht> bei normalen Fluglinien. Sonst dürfen die garnicht auf> vielen Airports landen, den die schreiben die> Sicherheitskriterien vor.
Die Sicherheitskriterien werden von der europäischen EASA
vorgeschrieben, orientieren sich an internationalen Abkommen und werden
hierzulande von dem Luftfahrtbundesamt kontrolliert - das natürlich auch
"ramp checks" auf den Flughäfen durchführt. Innerhalb der ICAO-Staaten
dürfte ein ziemlich hoher und einheitlicher Sicherheitsstandard
garantiert sein.
@opacer
Ich hatte nicht mit Bremsen oder so zu tun, sondern mit
Rückhaltesystemen (Sicherheitsgurte) und vereinzelt Aibags, und da dort
die Elektronik noch nicht so verbreitet war, war es schwierig dazu
Lastenhefte zu bekommen (ausser von Mercedes, sonst teilweise nicht mal
die grundlegenden Elektronikrichtlinien); wobei vieles wohl auch mit der
Kommunikation innerhalb verschiedener Abteilungen der Hersteller zu tun
hat. Da wir nur die Grundlagen dazu erarbeitet haben wurde wohl auch
nicht so viel Wert gelegt uns da was zu geben (Beispiele: Opel,
Jaguar(Ford), BMW, VW,...).
Ansonsten war es auch bei uns so, die Elektronik wurde als "nicht
sicherheitskritisch" angesehen, da es immer noch ein mechanisches Backup
gibt. Aus technischer Sicht ist das zwar kritisch zu sehen; jedoch viel
billiger.
Wie du richtig sagst ist der Kostendruck in der Industrie nicht so hoch.
Was bei mir aber regelmäßig die Frage aufwirft, warum diverse
Steuergeräte bei Autos so dermaßen teuer sind (wenn man weiß was drin
ist, und wieviel der Hersteller beim Zulieferer dafür bezahlt).
@Martin (Gast)
Unser Gerät hat ca eine MTBF con etwa 50 Jahren (lt. Rechnung), wobei
dieser Wert als solcher nix sagt, da die ganze Rechnung auf den
Ausfallwahrscheinlichkeiten der Bauteile beruht (FIT Wert), und diese
"statistischen" Angaben auch nur für einen Zeitraum von 10 Jahren.
Eine Anlage besteht jedoch aus mehreren Komponenten, und um die
Ausfallwahrscheinlichkeit der Anlage zu berechnen werden die MTBF Werte
der Komponeten zusammengerechnet. Da man dabei insgesammt auf einen Wert
unter 10 Jahren kommt, ist dann auch alles OK.
Der MTBF Wert hat auch nichts mit den gefahrbringenden Ausfällen zu tun,
dieser Wert ist deutlich aufwändiger zu berechnen, und abhängig von der
Art der Sicherheitsfunktion.
MTBF ist letztlich nichts anderes als ein Maß der Anzahl und Art der
Bauteile im Gerät (ein relais im Gerät, und der Wert wird schlecht, auch
wenn das Relais keine Sicherheitsfunktion hat).
Noch zum Thema Mobilfunk im Flugzeug: Ich habe mal einen Vortrag von
einem Mitarbeiter der Bodenseewerke Gerätetechnik gehört. Zu dem Thema
meinte er, dass die EMV-Belastung, die die Flugsteuerrechner zum
abstürzen bringen könnte, mit Mühe in einem französischen Speziallabor
mit unglaublichem Energiebedarf erreicht werden kann.
Irgendwo meine ich auch mal gehört zu haben, dass die Mobilfunkbetreiber
es nicht so gerne sehen, wenn 100 - 300 Mobiltelefone ständig und
gleichzeitig die Zellen wechseln.
@ werbinich
>So ein Quatsch! Schon was von Selbststabilisierender Aerodynamik im>Flugzeug gehört? So einfach kippt kein Flugzeug.. (vielleicht ein>Chinesisches ;)
Bei nem Papierflieger und nem grossen und leichten Segelflieger stimm
ich dir da voll und ganz zu.
Alles andere ist ohne Steuerung verloren definitiv !
Und schon gar keine hunderte Tonnen Schwere Pasagiermaschiene...
Ohne Triebwerke ist mit genügend Höhe noch was machbar, siehe z.b.
Landung Space Shuttle das ding is auch bloss n Stein mit Höhen Seiten
und Queerruder...
Aber ohne Steuerung wird das ding in kürzester Zeit in ein Trudeln
übergehen und die G-Kräfte zerreissen es.
Ich behaupte einfach, das ein Flugzeug mal bestimmt 5 minuten zeit hat
ohne das was schlimmes passiert. Vielleicht nicht grade in einer
extremen Schlechtwetter Lage, aber bei normalem Wetter und normaler
Höhe. Und auch ein Airbus stabilisiert sich selber. Nicht so stark wie
ein Segelflieger der ohne Steuerung schöne Kreise drehen kann, aber für
eine Zeit reicht es.
Die Aerodynamik eines SpaceShuttles kann man garnicht mit einem Flugzeug
vergleichen. Ich stimme dir da zu, wenn die Steuerung garnicht mehr
geht, sprich totalausfall der nicht durch einen "Reset" behoben worden
ist, dann gute Nacht. Aber dann müssten schon einige Systeme komplett
ausfallen. Die Wahrscheinlichkeit ist sehr gering (aber trotzdem da).
>Irgendwo meine ich auch mal gehört zu haben, dass die Mobilfunkbetreiber>es nicht so gerne sehen, wenn 100 - 300 Mobiltelefone ständig und>gleichzeitig die Zellen wechseln.
Naja, ich behaupte mal, in einer Großstadt werden es mehr sein.
"Aber ohne Steuerung wird das ding in kürzester Zeit in ein Trudeln
übergehen und die G-Kräfte zerreissen es."
Also ein Airbus sicher nicht. Der ist richtig schön konventionell
aufgebaut. Der würde wahrscheinlich sogar alleine aus dem Trudeln wieder
rauskommen, wenn die Lenkung neutral steht und genug Platz ist.
Der Space Shuttle ist schon etwas anderes.
Gruss
Axel
"Aber ohne Steuerung wird das ding in kürzester Zeit in ein Trudeln
übergehen und die G-Kräfte zerreissen es."
Das ist bei modernen Kampfjets so, denn diese lassen sich ohne
Flugkontrollsystem so gut wie überhaupt nicht fliegen.
Christian Ulrich wrote:
> @ werbinich>>>So ein Quatsch! Schon was von Selbststabilisierender Aerodynamik im>>Flugzeug gehört? So einfach kippt kein Flugzeug.. (vielleicht ein>>Chinesisches ;)>> Bei nem Papierflieger und nem grossen und leichten Segelflieger stimm> ich dir da voll und ganz zu.> Alles andere ist ohne Steuerung verloren definitiv !>> Und schon gar keine hunderte Tonnen Schwere Pasagiermaschiene...> Ohne Triebwerke ist mit genügend Höhe noch was machbar, siehe z.b.> Landung Space Shuttle das ding is auch bloss n Stein mit Höhen Seiten> und Queerruder...>> Aber ohne Steuerung wird das ding in kürzester Zeit in ein Trudeln> übergehen und die G-Kräfte zerreissen es.
Das ist doch Quatsch.
Passagiermaschinen fliegen mit relativ grosser V-Form in
den Tragflächen. Alleine dieses V stabilisiert das Ding
um die Längsachse, daß es nur so eine Freude ist. Ich weiss
zwar nicht, wo genau diese Maschinen normalerweise ihren
Schwerpunkt haben, ich denke aber mal der ist weit vor dem
Neutralpunkt. Und damit stabilisiert das Leitwerk wie verrückt.
Ohne Sturmböen und ohne Ausschlag auf den Steuerflächen fliegt
das Ding mit Sicherheit eine gewisse zeitlang von alleine gerade
aus weiter bzw. mit minimalen Kursabweichungen verursacht durch
Luftströmungen. Es ist aerodynamisch noch nicht mal sehr schwer
eine Tragfläche so auszulegen, dass der Flieger aus einer kleinen
Störung heraus wieder selbst mit den Tragflächen in die
Horizontale geht. Entweder man benutzt ein grosses V oder aber
man macht eine aerodynamische Schränkung hinein. Eine aerodynamsiche
Schränkung hat noch den zusätzlichen Vorteil, dass die Maschine
sich beim Überziehen gutmütiger verhält, weil die Strömung
zunächst an den Tragflächenspitzen abzureissen beginnt. Damit
sinkt der Auftrieb kontinuierlich, die Maschine nickt nach vorne
und holt wieder Fahrt auf.
Erst dann, wenn man mit dem Schwerpunkt weit nach hinten geht,
bis kurz vor den Neutralpunkt, fängt die Sache an kitzlig zu
werden. Die Flieger werden dann immer schwieriger zu steuern
aber auch immer wendiger, weil die Windfahneneffekte durch
das Leitwerk immer kleiner werden. Sprich: So ein Teil will
tatsächlich ständig gesteuert werden.
Sorry. Aber das ist bei den Grossen auch nicht anders als bei den
Kleinen. Die Physik macht da keinen Unterschied. Und Physik
lässt sich nun mal nicht überlisten.
Hm, die Diskussion ist ja ziemlich interessant. Nun wieder zurück zur
Eingangsfrage.
Die Frage an sich ist sinnlos und hat keinen Nutzen.
Eine 100% korrekte Software benötigt eine 100% korrekte Hardware,
logisch. Eine 100% korrekte Hardware benötigt eine 100% korrekte Physik
als Umwelt. Es gibt aber keine 100% exakt definierte Physik das ist
bewiesen ! Ergo: keine 100% exakte Physik bedeutet keine 100% exakte
Hardware und somit keine 100% exakte/korrekte Software.
Nun weiter: es ist bewiesen das es niemals eine Sofwtare geben kann die
zu 100% eine andere Software überwachen bzw. simulieren kann. Das ist
ein Unding. Ergo: auch eine Maßnahme wie "Redundanzen" und
"Überwachungen" wird niemals zu einer absolut sauber laufenden
Software/Hardware führen.
Fazit: 100% korrekt funktionierende Software ist unmöglich, selbst wenn
der Programierer keinen einzigsten Fehler gemacht hat.
Gruß Hagen
Aber Redudanz macht es wesentlich sicherer weil sich die eh schon sehr
geringen Ausfallwahscheinlichkeiten dann nochmal multiplizieren. Klar
ist das du so auch nie auf 0% kommst, aber wie sagt man so schön beim
Bund: Verluste sind einkalkuliert.
Hab mal gelesen das die Absturzwahrscheinlichkeit beim Space Shuttle bei
ungefähr 10 Jahren liegt( Berechnung von 198x) und ich würde sagen das
stimmt ziehmlich gut mit der Realität überein (leider).
Man muß hier sehr mit den Begriffen aufpassen. Jedes Bauteil mehr, ob
wichtig oder unwichtig, erhöht die Wahrscheinlichleit, das die Schaltung
"ausfällt" (sprich ein Bauteil einen Fehler hat) . Will man eine
möglichst niedrige Ausfallwahrscheinlichkeit, dann alles einkanalig,
ohne Redundanz, um Bauteile zu sparen.
Die entscheidende Frage ist jetzt aber die nach der Wahrscheinlichkeit
eines gefährlichen Ausfalles, oder eines Fehlers, der nicht erkannt
wird; da kann Redundanz - an der richtigen Stelle eingesetzt - durchaus
helfen.
Das mit der Frage nach 100% Fehlerfreiheit geht ja schon fast ins
philosophische. Wie definiert man Fehler ? Liegt nicht meist schon in
der Aufgabenstellung (oder in der Auswahl der Mittel) der Fehler ?
Wie oft ist eine Aufgabe von nur durchschnittlicher Komplexität so genau
spezifiziert, das man genau zwischen richtig und falsch entscheiden kann
?
Jeder von uns der schon Normen, Spezifikationen, Lastenhefte, etc.
durchgelsen hat wird sicher schon die ein oder andere Unklarheit
entdeckt haben.
(Das errinnert mich an Douglas Adams, der bereits Deep Thougth die
Antwort auf all unsere Fragen finden ließ: 42 :-))
<< Meines Wissens gab es bei diesem System bisher keinerlei
schwerwiegendere Probleme noch irgendwelche Unfälle, die auf dieses
System zurückzuführen sind. Im Gegenteil - es hilft, den häufigsten
Fehler beim Fliegen zu minimieren: menschliches Versagen. >>
na das muss man ja auch nicht alles wissen. Wen es unbedingt nach Wissen
dürstet, der liest halt nach ... http://www.bfu-web.de
oder www.faa.gov.
Die steht alles, was direkt zu Schäden geführt hat. Was nicht drin steht
sind solche Sachen wie z.B eine 747 -300 der beim Landeanflug (auf
Michigan??) alle Instrumente ausgefallen sind. Grund: Im Bug befanden
sich 2 Kabeltrommeln, die sich bei der Landung verschoben und einen
internen Stromkreis bildeten, der den Ausfall aller Systeme bewirkte.
Es muss also nicht immer die französiche EMV-Folterkammer sein.
In der Nähe von Kyritz (bei Berlin) gib es einen Punkt, an dem, wenn man
ihn überfliegt, aus unerfindlichem Grund die elektronischen Tankanzeigen
ausfallen.
Ja, Flugzeuge haben eine Eigenstabilität. Um ein Flugzeug zum Absturz zu
bringen, muss man es schon sehr ärgern (Kunstflug- und Militärmaschinen
ausgenommen, die sind absichtlich instabiel gebaut)
Ein Ing im Automobilbau hat mir mal gesagt: Autos dürfen nicht von
Computern gefahren werden, weil Computer keine Verantwortung übernehmen
dürfen. Computer dürfen nur dann ans Steuer, wenn der Mensch sich so
verantwortungslos verhalten hat, dass er die Kontrolle über das Fahrzeug
längst verloren hat. 98% der Autounfälle ließen sich verhindern, wenn
die Fahrerassistenzsysteme nicht erst eingreifen dürften, wenn es zu
spät ist.
>Außerdem werden Programmiersprachen eingesetzt, die eine gewisse>Fehlerüberprüfung schon mitbringen (etwas unglücklich formuliert), ASM>ist verboten, ebenso wie bsp. C (nach meiner Kentniss).
Das ist definitiv falsch. Weder die DO-178B noch die Airbus-Prozesse
verbieten den Einsatz von C oder ASM. Für den A380 kann ich keine
Aussage treffen, aber im A400M werden Teile der Level-A-Software in C
implementiert sein, beim Barracuda
(http://de.wikipedia.org/wiki/Barracuda_%28UCAV%29) waren es 98%, der
Rest ASM.
Bei den Handys im flugzeug. Ist auch das Problem das relative viele
Handy-Masten das Handy hören und das gibt Probleme. Zwischen Handy und
Handymast darf maximal 34.88 Km liegen sonst sind die Laufzeit
verschiebung zu groß.
> Das ist definitiv falsch. Weder die DO-178B noch die Airbus-Prozesse> verbieten den Einsatz von C oder ASM.
Hochsprachen werden sogar bevorzugt, während der Einsatz von Assembler
auf ein notwendiges Minimum beschränkt werden muß (Hardware-nahe
Funktionen, Zeitkritisches). Grund ist wahrscheinlich die einfachere
Validierbarkeit von in Hochsprachen geschriebenen Algorithmen. Wobei man
natürlich zusätzlich die benutzte Entwicklungsumgebung zertifizieren
muß.
Übrigens wird die Optimierung des Compilers nicht eingeschaltet!
> Mal ne Frage: Was nützt ein dreifach reduntantes System, wenn es zu> einer Störung in der Koordinierung dieser Systeme kommt? :-)
Man muß natürlich aufpassen, daß es keinen "single point of failure"
gibt, sonst hat man die Redundanz selbst ausgehebelt. Also müssen die
Überwachungsinstanzen selbst redundant sein, oder man führt die
redundanten Signale so spät wie möglich zusammen - beispielsweise könnte
man ein Ruder in drei Teile splitten, die getrennt angesteuert werden,
dann wird aerodynamisch gemittelt. Oder man verbaut mehrere Aktuatoren
(muß man ja meist sowieso) für ein Ruder und läßt so den mechanischen
Durchschnitt bilden.
> Zwischen Handy und Handymast darf maximal 34.88 Km liegen sonst sind> die Laufzeit verschiebung zu groß.
Deshalb baut man die Gegenstation dann gleich mit ins Flugzeug ein.
Oliver Döring wrote:
> Übrigens wird die Optimierung des Compilers nicht eingeschaltet!
Da hätte ich mir früher an die Stirn getippt.
Seit AVR-GCC4 kann ich das aber nun voll und ganz verstehen.
Peter
