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.
Der Programmcode "wo" .. ? Autsch! Der Dativ ist dem Genitiv sein Tod ;)
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.
Sofern diese redundanten Systeme alle vom gleichen Hersteller und vom gleichen Typ stammen, stimmt Kolas Aussage.
>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...
Zumal es in 10.000m recht wenig GSM oder UMTS Sender gibt, die man nutzen könnte.
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.
Was ich damit sagen will...uns Schweizern passiert es häufig, dass wir Hochdeutsch mit Schweizer Grammatik sprechen :D
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
@ Bartli >perfektes Schweizerdeutsch. Das klingt mir nach einem Oxymoron ;-) http://de.wikipedia.org/wiki/Oxymoron MFG Falk
@ 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.
Ja, in der Automobilindustrie ist C erlaubt, das mit dem ASM/C meinte ich nur im Flugbereich. War etwas unglücklich ausgedrückt..
> Und im Space Shuttle vverwenden sie Pascal. Da habe ich andere Infos ;-) "The software for the Shuttle computers is written in a high-level language called HAL/S, somewhat similar to PL/I. It is specifically designed for a real time embedded system environment." http://www.bernd-leitenberger.de/space-shuttle.shtml http://en.wikipedia.org/wiki/Space_Shuttle http://en.wikipedia.org/wiki/HAL/S
Hallo, wie wird den eigentlich der durchschnitt dann berechnet? Mechanisch? Gruß Peter
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.
Mal ne Frage: Was nützt ein dreifach reduntantes System, wenn es zu einer Störung in der Koordinierung dieser Systeme kommt? :-)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.