Warum kippen Raketen nicht um?
Martin Imlau
Moin!
Mal ne Frage eines Laien:
Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
noch sehr niedrig ist, doch recht hoch sein.
MfG Martin
Michael Himsolt
"Martin Imlau" <MIm...@tramp.in-berlin.de> writes:
Z.B. sind die Triebwerke schwenkbar, und ein Steuerungssystem
sorgt dafuer, dass jede Bewegung sofort ausgeglichen wird.
Z.B. wird das beim Space Shuttle verwendet; sowohl
Haupttriebwerke als auch die Feststoffraketen (d.h. deren Duesen)
sind schwenkbar.
Oder man verwendet fest montierte Triebwerke und kleine
Zusatztriebwerke, die schraeg montiert sind (d.h. der Schub geht
ein bisschen zur Seite), und mit denen man Bewegungen
gegensteuern kann. Das ist einfacher, weil die Triebwerke fest
montiert sind und man keine aufwendige Hydraulik zum Schwenken braucht.
Michael
Gernot Zander
Hi,
in de.sci.raumfahrt Martin Imlau <MIm...@tramp.in-berlin.de> wrote:
> Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
> ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
> Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
> Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
> noch sehr niedrig ist, doch recht hoch sein.
Das wird natürlich geregelt, indem die Düsen schwenkbar sind.
Das kann man bei Nahaufnahmen des Shuttle-Starts sehr gut sehen,
wo die - bevor voller Schub gegeben wird - einmal in alle Richtungen
durchbewegt werden.
Früher wurde das mit einem Kreisel geregelt, heute macht das
der Rechner, schätze ich (wobei der seine Daten vermutlich auch
nur von einem Kreisel holt).
mfg.
Gernot
--
<hi...@gmx.de> (Gernot Zander)
Es ist leichter, draußenzubleiben, als herauszukommen.
Andreas Winckler
Martin Imlau wrote:
> Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
> ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
> Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
> Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
> noch sehr niedrig ist, doch recht hoch sein.
Grundsätzlich gibt es dafür mehrere Möglichkeiten:
-> Veränderung der Richtung des Schubvektors. Dies geschieht
üblicherweise durch Schwenken der Triebwerke. Aber auch feststehende
Triebwerke können z.B. durch Sekundäreinspritzung von Treibstoff in die
Düse die Richtung des Schubvektors beeinflussen. Bei den Boostern der
der Titan III wird das unter anderem benutzt.
-> aerodynamische Steuerflächen an der Rakete. Funktioniert nur ab einer
bestimmten Geschwindigkeit und ist daher als alleiniges Steuersystem nur
für sehr schnell beschleunigende Raketen geeignet. Der Vorteil ist
allerdings, daß sich Steuerflächen technisch einfach relisieren lassen.
Wird hauptsächlich bei kleinen Raketen z.B. für militärische Zwecke oder
Höhenforschungsraketen verwendet.
-> Kreiselkräfte. Es gibt auch die Möglichkeit einen Kreisel mit der
Achse in Flugrichtung in die Rakete einzubauen. Die Kreiselmomente
halten dann die Rakete gerade. Ist recht einfach zu realisieren, läßt
allerding nur einen senkrechten Start und Flug zu.
-> Steuerdüsen. Funktioniert genauso wie die Steuerdüsen eines
Raumschiffs. Der technische Aufwand ist allerdings recht hoch,
insbesondere wenn die beim Start noch sehr schwere Rakete gesteuert
werden soll. Aus diesem Grund werden Steuerdüsen üblicherweise erst in
Oberstufen eingesetzt, wenn das zu bewegende Gewicht (bzw.
Trägheitsmoment) sehr viel geringer ist und aerodynamische Steuerflächen
nicht mehr funktionieren.
AW
Michael Himsolt
Andreas Winckler <andreas....@studbox.uni-stuttgart.de> writes:
> -> Steuerdüsen. Funktioniert genauso wie die Steuerdüsen eines
> Raumschiffs. Der technische Aufwand ist allerdings recht hoch,
> insbesondere wenn die beim Start noch sehr schwere Rakete gesteuert
> werden soll. Aus diesem Grund werden Steuerdüsen üblicherweise erst in
> Oberstufen eingesetzt, wenn das zu bewegende Gewicht (bzw.
> Trägheitsmoment) sehr viel geringer ist und aerodynamische Steuerflächen
> nicht mehr funktionieren.
Haben nicht Sojus (A-2) oder Atlas Steuerduesen ? Das wuerde eher
dauer sprechen, dass Steuerduesen einfach zu handhaben sind (weil
das recht alte Raketendesigns sind), und zumindest bis zu
mittlerer Groesse einsetzbar sind.
Andere Variante: Ich erinnere mich, dass die sowjetische N1 (also
deren "Mondrakete") zur Steuerung einfach in den Duesen auf der
Seite den Schub reduziert hat, um einem Kippen (nach der anderen
Seite) entgegenzuwirken. Wenn man 42 Triebwerke hat, kann man das
machen 8-).
Michael
--
Michael Himsolt http://www.fmi.uni-passau.de/~himsolt
Andreas Winckler
Michael Himsolt wrote:
> Haben nicht Sojus (A-2) oder Atlas Steuerduesen ? Das wuerde eher
> dauer sprechen, dass Steuerduesen einfach zu handhaben sind (weil
> das recht alte Raketendesigns sind), und zumindest bis zu
> mittlerer Groesse einsetzbar sind.
Steuerdüsen haben soweit ich weiß alle großen Trägerraketen, auch die
Ariane V. Bei älteren Modellen sind das z.T. Kaltgasdüsen, zwar einfach
aber sehr ineffizient (Isp ca. 80s). Um aber eine vollgetankte Rakete
vom Start weg zu stabilisieren braucht man sehr große Schubkräfte und
die sind mit Steuerdüsen schwer aufzubrigen.
Da z.B. die Hauptstufe der Ariane V nur ein Triebwerk hat (und keine
Steuerflächen), braucht man nach dem Absprengen der Booster zwingend
Steuerdüsen für die Steuerung um die Längsachse. Um die beiden anderen
Achsen läßt es sich jedoch wesentlich besser durch Schwenken des
Hauptriebwerks steuern. Steuerdüsen sind also erst in den Oberstufen
und/oder in großen Höhen richtig sinnvoll.
> Andere Variante: Ich erinnere mich, dass die sowjetische N1 (also
> deren "Mondrakete") zur Steuerung einfach in den Duesen auf der
> Seite den Schub reduziert hat, um einem Kippen (nach der anderen
> Seite) entgegenzuwirken. Wenn man 42 Triebwerke hat, kann man das
> machen 8-).
:-)
AW
Dr. Peter Kittel
In article <385.444T21...@tramp.in-berlin.de> "Martin Imlau" <MIm...@tramp.in-berlin.de> writes:
>
>Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
>ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
>Schub wird, relativ punktförmig, am unteren Ende erzeugt.
Die anderen haben es ja schon beantwortet, aber nur als Bekraeftigung:
Genau das war angeblich am Anfang das Problem bei der V2. Sie kippte
zwar nicht direkt um, wurde jedoch schon kurz nach dem Start
unmanoevrierbar. Man hat dann herausgefunden, dass man die Lageregelung,
also den Schwenkbereich der Duesen, wesentlich groesser ausfuehren
musste.
--
Best Regards, Dr. Peter Kittel // http://www.pios.de of PIOS
Private Site in Frankfurt, Germany \X/ office: peterk @ pios.de
Michael Himsolt
pet...@combo.ganesha.com (Dr. Peter Kittel) writes:
> Die anderen haben es ja schon beantwortet, aber nur als Bekraeftigung:
> Genau das war angeblich am Anfang das Problem bei der V2. Sie kippte
> zwar nicht direkt um, wurde jedoch schon kurz nach dem Start
> unmanoevrierbar. Man hat dann herausgefunden, dass man die Lageregelung,
> also den Schwenkbereich der Duesen, wesentlich groesser ausfuehren
> musste.
Wobei die V2 noch ein recht eigenes Steuerungssystem hatte: nicht
die Duese war schwenkbar, sondern es gab direkt unter der Duese
noch 4 kleine Ruder die *in den austretenden Strahl* hineinragten
und so die austretenden Gase umlenkten.
ckoehler
he, Martin, das ist eine Frage der Balance, außerdem kommt es relativ häufig
vor, das so ein Ding "umkippt" . Die erste Ariane 5 z. B.
Martin Imlau schrieb in Nachricht
<385.444T21...@tramp.in-berlin.de>...
Moin!
Mal ne Frage eines Laien:
Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
noch sehr niedrig ist, doch recht hoch sein.
MfG Martin
Philipp Mergenthaler
ckoehler <ckoe...@metronet.de> wrote:
> he, Martin, das ist eine Frage der Balance, außerdem kommt es relativ häufig
> vor, das so ein Ding "umkippt" .
"Relativ häufig" sieht man das vielleicht im Fernsehen, weil's
spektakulärer als ein normaler aussieht...
> Die erste Ariane 5 z. B.
Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
20 Grad) und zerbrach durch die aerodyn. Belastung.
> Martin Imlau schrieb in Nachricht
> <385.444T21...@tramp.in-berlin.de>...
> Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
> ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
> Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
> Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
> noch sehr niedrig ist, doch recht hoch sein.
Zu dem, was die anderen schon geschrieben haben, könnte man vielleicht
noch hinzufügen, daß die "offensichtliche Analogie" zu einem Bleistift,
den man auf dem Finger balanciert (die sich viele Leute vorstellen),
falsch ist. Sobald der Bleistift ein bisschen kippt, wirken Gravition
und die vom Finger ausgeübte Kraft nicht mehr genau in seiner Längsachse,
sondern leicht schräg, so daß die Rotation verstärkt wird. Bei einer
Rakete schiebt das Triebwerk aber immer in Längsachse (wenn's nicht
gerade ausgeschwenkt ist). Man braucht aber natürlich trotzdem eine
Möglichkeit, Seiten- und Fahrtwind und evtl. Ungenauigkeiten im Triebwerk
auszugleichen und den Kurs zu ändern.
Tschuess, Philipp
--
P. Mergenthaler, un...@rz.uni-karlsruhe.de | Wer halb gebildet, ist der
Tel.: 0721/694532 | schoenste Narr.
Klosterweg 28 / I609, 76131 Karlsruhe | (Weiss jemand, von wem das ist?)
http://www.uni-karlsruhe.de/~un1i/ |
Andreas Vogel
Philipp Mergenthaler wrote:
> > Die erste Ariane 5 z. B.
>
> Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
> Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
> 20 Grad) und zerbrach durch die aerodyn. Belastung.
AFAIK wurde die Selbstzerstoerung aktiviert... passierte das vor oder nach dem
Zerbrechen?
Und weiss jemand wie der Selbstzerstoerungsmechanismus funktioniert?
Gruss
Andreas.
Chris Huebsch
Andreas Vogel wrote:
>
> Philipp Mergenthaler wrote:
>
> > > Die erste Ariane 5 z. B.
> >
> > Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
> > Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
> > 20 Grad) und zerbrach durch die aerodyn. Belastung.
Es waren keine falschen Daten, sondern Fehler im Programm. Das liegt an
schlechter Arbeit der Informatiker.
> AFAIK wurde die Selbstzerstoerung aktiviert... passierte das vor oder nach dem
> Zerbrechen?
> Und weiss jemand wie der Selbstzerstoerungsmechanismus funktioniert?
Ich glaube die aktivieren einfach den Windows95 Rechner, der da einebau
ist. ;)
bye
Chris
--
public class chu extends ChrisHübsch implements TUChemnitz {
String email = "mailto:c...@informatik.tu-chemnitz.de";
URL homepage = new URL("http://www.tu-chemnitz.de/~chu");
Talk talkto = new Talk("c...@argus.csn.tu-chemnitz.de");
}
Andreas Winckler
Chris Huebsch wrote:
> Es waren keine falschen Daten, sondern Fehler im Programm. Das liegt an
> schlechter Arbeit der Informatiker.
Für die Ariane V wurden aus 'Kostengründen' die Flugdatenrechner und die
Software der Ariane IV verwendet. Man ging davon aus, daß die ja erprobt
seien und deshalb einwandfrei funktionieren würden.
Leider treten beim Start der Ariane V höhere Beschleunigungen auf und
der entsprechende Rechner und alle seine backup-System waren für
niedrigere Werte ausgelegt. Bei einer Rakete nimmt ja durch die
abnehmende Masse die Beschleunigung im Laufe des Fluges zu. Nach einigen
Sekunden sind dadurch alle Rechner zur Flugbahnregelung mit einem
Overflow-Error ausgestiegen. Im Steuerrechner des Triebwerks war dann
nur noch ein Programm aktiv, welches vor dem Start das Haupttriebwerk
durch schwenken in die Endlagen ausrichtet und genau das hat es dann
auch gemacht.
Das schlimmst an dem Absturz war jedoch, daß einige Ingenieure die
Verantwortlichen vorher darauf hingewiesen haben, daß die betreffenden
Rechner und Programme nie komplett getestet wurden. Ein Prüfstand und
umfangreiche Tests hätten Millionen von Mark gekostet. Der Fehler wäre
aber aufgefallen und man hätte am Ende sehr viel Geld gespart!
AW
Michael Himsolt
Andreas Vogel <andrea...@student.uni-ulm.no.spam.de> writes:
> Philipp Mergenthaler wrote:
>
> > > Die erste Ariane 5 z. B.
> >
> > Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
> > Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
> > 20 Grad) und zerbrach durch die aerodyn. Belastung.
>
> AFAIK wurde die Selbstzerstoerung aktiviert... passierte das vor oder nach dem
> Zerbrechen?
Ich weiss die Antwort nicht, aber 20 Grad Fehlstellung duerfte
zum Zerbrechen fuehren ... die aerodynamischen Kraefte sind in
der Anfangsphase eines der Hauptprobleme. Z.B. ist die
Challenger(i.e. der Shuttle) damals nicht durch die Explosion
zerrissen worden, sondern *zerbrochen* weil sie nicht mehr im
richtigen Anstellwinkel war.
> Und weiss jemand wie der Selbstzerstoerungsmechanismus funktioniert?
Wenn ich mich recht erinnere, haben die Feststoffraketen des
Space Shuttle Sprengladungen an den "Nahtstellen" zwischen den
Segmenten, so dass sie dort zerbrechen. Das stoppt effektiv die
Rakete, so dass sie nicht unkontrolliert wesiss nicht wohin
fliegt.
Wichtig ist dass Truemmer moeglichst auf unbewohntes Gebiet
(Ozean) fallen, weil sie dort weniger Schaden anrichten.
Michael
Jan Lukoschus
Andreas Vogel wrote:
>
> Philipp Mergenthaler wrote:
>
> > > Die erste Ariane 5 z. B.
> >
> > Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
> > Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
> > 20 Grad) und zerbrach durch die aerodyn. Belastung.
>
> AFAIK wurde die Selbstzerstoerung aktiviert... passierte das vor oder nach dem
> Zerbrechen?
In den Fernsehbildern war damals recht deutlich zu sehen, dass erst das
obere Drittel abbrach und dabei nahezu pulverisiert wurde. Danach ist
dann die untere Stufe (per Selbstzerstoerung) in einem Feuerball
aufgegangen. Dazwischen lag geschaetzt zwar nur etwa eine halbe Sekunde,
die Reihenfolge war aber eindeutig zu erkennen.
Jan.
Joerg Rodemann
Chris Huebsch (c...@informatik.tu-chemnitz.de) wrote:
> Andreas Vogel wrote:
> > Philipp Mergenthaler wrote:
> > > > Die erste Ariane 5 z. B.
> > >
> > > Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von
> > > falschen
> > > Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
> > > 20 Grad) und zerbrach durch die aerodyn. Belastung.
> Es waren keine falschen Daten, sondern Fehler im Programm. Das liegt an
> schlechter Arbeit der Informatiker.
Jein. Soweit ich das richtig in Erinnerung habe (dummerweise hab ich den
ESA-Bericht verliehen und nicht mehr wiederbekommen), war das wie folgt:
1.) ein Programm zu Lageregelung VOR dem Start wurde ohne Ueberpruefung
von der Ariane 4 uebernommen.
2.) dieses Programm lief bei der Ariane 4 noch einige Zeit nach dem Start
weiter, damit die Wiederaufnahme des Countdowns nach einem kurzfristigen
Abbruch schneller moeglich ist.
3.) dieses 'feature' wurde bei Ariane 5 nicht mehr benoetigt, aber dennoch
benutzt.
4.) dieses Lageregelungssystem wurde nicht mit der flacheren Trajektorie
der Ariane 5 getestet.
5.) zur Sicherheit wurden zwei identische Lageregelungssysteme mitgefuehrt,
als Fehlerfall war nur ein Hardwarefehler vorgesehen.
Soweit zur Vorgeschichte, nun zu dem, was waehrend des Starts geschah:
6.) die flache Ariane 5-Trajektorie fuehrt zu groesseren x-Werten als
vorgesehen, es tritt ein Overflow-Fehler auf
7.) da die Philosophie Fehler=Hardware-Defekt verwendet wurde, versuchen
beide Systeme an das andere zu uebergeben und schalten sich ab.
8.) beide Systeme schreiben eine Fehlermeldung auf den _Daten_-Bus.
9.) Fehlermeldung wird als Flugdaten interpretiert und fuehren zu einer
falschen Bahnkorrektur
10.) Bahnkorrektur droht die Rakete zu zerreissen und loest die Selbst-
Zerstoerung aus. (Nein, ich weiss leider nicht genau, ob schon vor dem
Zerbrechen oder erst danach.)
Alles in allem eine recht interessante Mischung von ungluecklichen Umstaenden.
Ob die Programmierer solche Fehler immer verhindern koennen, erscheint mir
fraglich...allerdings scheint hier teilweise schlampig gearbeitet worden zu
sein. (Nur Test der Komponenten, nicht ihr Zusammenspiel. Reuse von Software
ohne die Randbedingungen zu Ueberpruefen...alles in allem deutet das fast
Richtung Management.) Ein Hauptproblem ist wohl, das eine riesige Zahl von
Disziplinen in der Software zusammenkommt und in der Regel die Schnittstellen
nicht genau genug spezifiziert sind.
Sollte jemand eine Url zu dem ESA-Report haben, moege er sie mir doch bitte
zukommen lassen. Ich fand den sehr interessant. Sollte ich oben Fehler rein-
gebracht haben, bitte ich um Entschuldigung und erbitte eine Korrektur.
Gruesse
Joerg
--
rode...@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rode...@hlrs.de | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5836 | Visualization Department, Office: 0.296
Fax: ++49-(0)711-682-357 | Allmandring 30a, D-70550 Stuttgart, Germany
Wolfgang Wohlers
Moin!
>Philipp Mergenthaler wrote:
>
>> > Die erste Ariane 5 z. B.
>>
>> Nein. Der Compter schwenkte die Triebwerke voll aus (aufgrund von falschen
>> Daten); daraufhin stellte sie sich schräg zur Flugrichtung (mehr als
>> 20 Grad) und zerbrach durch die aerodyn. Belastung.
>
>AFAIK wurde die Selbstzerstoerung aktiviert... passierte das vor oder nach dem
>Zerbrechen?
>Und weiss jemand wie der Selbstzerstoerungsmechanismus funktioniert?
Das ganze ist ein Lehrbeispiel fuer schlechte Informatikerarbeit. Im
Rahmen meiner Hiwitaetigkeit fuer einen Info-Lehrstuhl habe ich ein
paar Dinge gelesen. Die Sache war wohl so, dass durch den hohen
Anstellwinkel Teile der Rakete (ein Booster) abgerissen wurde, das hat
dann den Selbstzerstoerungsmechnismus aktiviert.
Gerhard Huebner
>Wie wird eigendlich verhindert, das Raketen beim Start umkippen? Immerhin
>ich so eine Rakete ja sehr lang (bei einem geringen Durchmesser) und der
>Schub wird, relativ punktförmig, am unteren Ende erzeugt. Da dürft die
>Gefahr den abkippens zur Seite gerade beim Start, wenn die Geschwindigkeit
>noch sehr niedrig ist, doch recht hoch sein.
Bei einfachen, ungelenkten Raketen wird die Starbeschleunigung so hoch
gewaehlt, dass die aerodynamische Stabilisierung sofort nach dem Verlassen
der Startvorrichtung greift, d.h. die Rakete ist dann schnell genug, damit
die Stabilisierungsflossen bei einem "Abkippen" ein entsprechendes
aerodynamisches Gegendrehmoment erzeugen.
Kann eine Rakete nicht schnell genug beschleunigen, weil strukturelle
Belastungsgrenzen dies verhindern bzw. die Mannschaft an Bord nicht mehr als
eine Handvoll "g" aushaelt, so wird die Rakete durch ein Flugregelungssystem
stabilisiert. Die Steuerung der Rakete erfolgt hierbei ueber eine Aenderung
des Schubvektors, weil bei der geringen Stargeschwindigkeit die
aerodynamischen Ruder noch keine Wirkung haben.
Das Flugregelungssystem erfasst die Kippbewegungen der Rakete mit Hilfe von
Beschleunigungsmessern und vergleicht die daraus errechnete Lage mit dem
Sollwert und veraendert dementsprechend die Richtung des Schubes, um
Abweichungen fruehzeitig zu korrigieren.
Der Schubvektor kann wie folgt geaendert werden:
1.) Schwenken des Triebwerks
2.) Schubsteigerung/Verringerung einzelner Triebwerke
3.) Asymmetrische Injektion eines zusaetzlichen Massenstroms ins Triebwerk
4.) Strahlruder in der Raketenduese
5.) Zusaetzliche Steuerduesen
Hinweis: Das Anbringen von Duesen am Kopf der Rakete anstelle vom Heck
verbessert nicht notwendigerweise die Stabilitaet. Abgesehen von den vielen
technischen Problemen, die entstehen, wenn der heisse Strahl an der
Aussenhaut der Rakete entlanglaeuft, koennen dadurch Schwingungen um die
Querachsen nicht gedaempft werden. Ausserdem: wenn Du einen Besenstiel
balancierst, brauchst Du verhaeltnismaessig wenig Kraft, um Stoerungen zu
kompensieren, also kann man die Triebwerke getrost "unten" lassen.
Dipl.-Phys. Gerhard Huebner __
Institute of Astronautics \ \____ "Not a plucky hero
--------------------------------===>--____> until one reaches
Technische Universitaet Muenchen /_/ the Great Wall"
Tel.: +49-89-289-16015, Fax: 16004
http://www.lrt.mw.tu-muenchen.de/personen/ghuebner/ghuebner.html
Joerg Rodemann
Philipp Mergenthaler (un...@rz.uni-karlsruhe.de) wrote:
> Aus dem Bericht der Untersuchungskommision,
> http://www.cnes.fr/actualites/news/rapport_501.html (engl. u. franz.):
Danke fuer die Url. Ein Bericht, den sich jeder Software Ingenieur mal
in Ruhe zu Gemuete fuehren sollte.
Tschuess
Joerg Rodemann
Andreas Winckler (andreas....@studbox.uni-stuttgart.de) wrote:
> Solche Fehler lassen sich nur dadurch verhindern in dem man alles immer
> und immer wieder unter möglichst realistischen Bedingungen simuliert.
Ja, allerdings spielen die Kosten auch eine Rolle, abgesehen davon: wer
testet die Simulationen? Wer stellt alle moeglichen Testsituationen
zusammen? Bei externem Input wird das ganze noch schwieriger. Aber welchem
Testaufwand ist ein Verlust des Systems guenstiger? Alles in allem ein
sehr komplexes Problem der heutigen Zeit. Zumal das Software Engineering
eine sehr junge Wissenschaft ist im Gegensatz zu den klassischen Ingenieurs-
Wissenschaften.
> Wie das ganze ablief deutet eindeutig in Richtung Management! Wenn ich
> mich richtig erinnern kann stand das auch im Abschlußbereicht der
> Untersuchungskomission. Von Seiten der Verantwortlichen wurde nämlich
> damals klar entschieden, daß keine ausgiebigen Tests mit dem kompletten
> Flugsteuerungssystem durchgeführt werden. Der dafür notwendige Prüfstand
> wurde als 'zu teuer' abgelehnt.
Jepp. Allerdings ist hier noch ein Kuriosum am Rand recht interessant. Die
Anforderungen an das Laufzeitsystem machten es unmoeglich, alle Konver-
tierungen von float nach int zu ueberpruefen (haette die Systemlast hoch-
getrieben). Deshalb wurde bewusst in Kauf genommen, dass einige dieser
Variablen unchecked blieben. Laut Bericht, war im nachhinein nicht mehr
feststellbar, warum ausgerechnet die unglueckliche x-Koordinate darunter
war. Tja, oh Wunder der Realtime-Anforderungen...
Gruesse
Andreas Winckler
Joerg Rodemann wrote:
>
> Philipp Mergenthaler (un...@rz.uni-karlsruhe.de) wrote:
> > Aus dem Bericht der Untersuchungskommision,
> > http://www.cnes.fr/actualites/news/rapport_501.html (engl. u. franz.):
>
> Danke fuer die Url. Ein Bericht, den sich jeder Software Ingenieur mal
> in Ruhe zu Gemuete fuehren sollte.
Ich hab's gelesen, der Bericht gibt mir sehr zu denken. Insbesondere
deshalb weil ich selbst Software in Ada programmiere und ich immer
dachte genau diese Fehler wären in Ada einfach vermeidbar.
AW
Joerg Rodemann
Ada (insbesondere Ada-95) ist eine geniales Hilfsmittel zur Software-Ent-
wicklung insbesondere im sicherheits-relevanten Bereich. Wesentlich besser
geeignet jedenfalls aus diese "Hardware-nahen" Sprachen wie C++. (Zumal
C++ bei geringerer Vielfalt einen dickeren Standard hat/haben wird als
Ada-95.) Nun, bevor einer der typischen Flame-Wars entsteht, hier meine
Einschaetzung, warum der Fehler auch von Ada nicht abgefangen wurde.
- Genau genommen wurde der Fehler vom Ada-Laufzeitsystem gefunden:
es wurde gemaess Standard eine Exception ausgeloest.
- Weiterhin verhielt sich diese Exception genau gemaess Standard:
wenn eine nicht vom Programmierer behandelte Exception auftritt,
wird sie an das Betriebssystem weitergegeben. Das weitere Verhalten
ist aus Ada's Sicht undefiniert.
Meines Erachtens liegt das Problem in folgenden zwei Punkten:
1.) Wurde die Exception nicht vom Programmierer abgefangen (was mit
der ungluecklichen Auswahl der zu checkenden Variablen zusammen-
haengt. Alle zu pruefen war zeitlich zu teuer.)
2.) Die Betriebsumgebung behandelte jede auftretende Exception als
Hardware-Fehler und verhinderte nicht, dass die Fehlermeldung auf
den Datenbus gelangt.
Von daher trifft Ada keine Schuld: Punkt 1 ist eine Notwendigkeit, die
sich aus dem Echtzeit-Verhalten ergibt. Eine Bestimmung der Orientierung
beim Start darf nun mal erst nicht im Orbit oder sonstwo abgeschlossen sein.
Allerdings sind das nur vordergruendig die Ursachen gewesen. Tieferliegend
sind eher folgende Fragen zu stellen:
a) Wie kann man ueberhaupt implementationsabhaengige Einschraenkungen
der Software sauber erkennen, dokumentieren und evtl. automatisch
pruefen?
b) Wie soll sich das System im Fehlerfall ueberhaupt verhalten?
Gerade der Punkt b) duerfte in allen Bereichen knifflig sein. Ist es sinn-
voller, das System abschalten und auf das Ersatzsystem zu wechseln --- in
der Hoffnung, dass es ein spontaner Hardware-Fehler ist? Oder soll lieber
mit den alten Daten weiter "geschaetzt" werden? Vor allem zu diesem Punkt
wird es nie eine allgemeingueltige Antwort geben...hoffentlich. Man stelle
sich das Auto vor, in dem sich das ABS ueber einen General Protection
Failure beschwert. ;)
Jedenfalls habe ich eine Riesenrespekt vor den Leuten, die solche Software-
Projekte wirklich angehen und bewaeltigen. Die Wahl der Sprache kann zwar
hilfreich sein, ist aber kein entscheidendes Kriterium.
Gruesse
Joerg
P.S.: Fuer die, die mit Ada wenig anfangen koennen, empfehle ich die
Seiten http://www.adahome.com/ (DIE Ada-Seite schlechthin) oder
http://www.ada-deutschland.de/
Andreas Winckler
Joerg Rodemann wrote:
> Ada (insbesondere Ada-95) ist eine geniales Hilfsmittel zur Software-Ent-
> wicklung insbesondere im sicherheits-relevanten Bereich.
Absolut richtig.
> Von daher trifft Ada keine Schuld.
Richtig, die Sprache stellt sehr mächtige Tools für Fehlerbehandlung zur
Verfügung. Wenn die Programmierer sie nicht nutzen, aus welchen Gründen
auch immer ist es deren Schuld!
> a) Wie kann man ueberhaupt implementationsabhaengige Einschraenkungen
> der Software sauber erkennen, dokumentieren und evtl. automatisch
> pruefen?
> b) Wie soll sich das System im Fehlerfall ueberhaupt verhalten?
>
> Gerade der Punkt b) duerfte in allen Bereichen knifflig sein. Ist es sinn-
> voller, das System abschalten und auf das Ersatzsystem zu wechseln --- in
> der Hoffnung, dass es ein spontaner Hardware-Fehler ist? Oder soll lieber
> mit den alten Daten weiter "geschaetzt" werden? Vor allem zu diesem Punkt
> wird es nie eine allgemeingueltige Antwort geben...hoffentlich. Man stelle
> sich das Auto vor, in dem sich das ABS ueber einen General Protection
> Failure beschwert. ;)
Genau diese Entscheidungen sind es, die das Programmieren vom Software
Engineering unterscheiden. Aber aus eigener Erfahrung mit Ada95 weiß
ich, daß man sich genau darum kümmern muß und Ada bietet die
Möglichkeiten das zu tun. Es wurde auch getan, nur eben nicht bei allen
Variablen. Die betreffenden Variablen nicht abzusichern war eine
typische Kozesionsentscheidung, wie sie bei Softwareprojekten dauernd
vorkommt. Fatal war eben nur, daß das fertige System nicht ausreichend
getestet wurde.
> Jedenfalls habe ich eine Riesenrespekt vor den Leuten, die solche Software-
> Projekte wirklich angehen und bewaeltigen.
Ich auch!
> Die Wahl der Sprache kann zwar
> hilfreich sein, ist aber kein entscheidendes Kriterium.
Da bin ich anderer Meinung, denn mit der Programmiersprache entscheided
man sich auch für eine Philosophie. Ada95 ist ohne Zweifel die beste
Sprache für solche Anwendungen die es momentan gibt. Nur 'Idiotensicher'
ist Ada eben auch nicht und Fehler können leider immer passieren.
AW
Pierre Bernhardt
-----BEGIN PGP SIGNED MESSAGE-----
In message <356AE4...@studbox.uni-stuttgart.de>
Andreas Winckler <andreas....@studbox.uni-stuttgart.de> wrote:
>Joerg Rodemann wrote:
>>
>> Philipp Mergenthaler (un...@rz.uni-karlsruhe.de) wrote:
>> > Aus dem Bericht der Untersuchungskommision,
>> > http://www.cnes.fr/actualites/news/rapport_501.html (engl. u. franz.):
>>
>> Danke fuer die Url. Ein Bericht, den sich jeder Software Ingenieur mal
>> in Ruhe zu Gemuete fuehren sollte.
>
>Ich hab's gelesen, der Bericht gibt mir sehr zu denken. Insbesondere
>deshalb weil ich selbst Software in Ada programmiere und ich immer
>dachte genau diese Fehler wären in Ada einfach vermeidbar.
Gabs da denn schon Ada?
--
CosmicStars : |
Pierre Bernhardt -------------------=====#(*)===---
mailto:f36...@hrz.uni-paderborn.de --------===(*)#==----
http://hrz.uni-paderborn.de/~f36354/index.html | :
PGP-Key available: Sent an E-Mail with subject GET PGPKEY
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
iQCVAwUBNWudSEgeA2Y8aaBVAQGiQwP/a/z4iJMSn4v7kSc4QBkJ+DrPe22e6tc0
yNaFgyq0tCKUEgkNjMjV7HSmpDX9acN8dT8JCp9D1TfWZ+Mk/ZbFeocRTrrHvgxg
MAnB1L3QGViHVGRcNV1cYQIb3HhB9onAP8WxEMMXW2enbiRT4dspWTLuxaXwO2Aq
rc88BKR0q0Q=
=qs8f
-----END PGP SIGNATURE-----
Joerg Rodemann
Pierre Bernhardt (f36...@hrz.uni-paderborn.de) wrote:
> In message <356AE4...@studbox.uni-stuttgart.de>
> Andreas Winckler <andreas....@studbox.uni-stuttgart.de> wrote:
> >Ich hab's gelesen, der Bericht gibt mir sehr zu denken. Insbesondere
> >deshalb weil ich selbst Software in Ada programmiere und ich immer
> >dachte genau diese Fehler wären in Ada einfach vermeidbar.
> Gabs da denn schon Ada?
Klar, Ada entstand Ende der Siebziger auf Wunsch der US Militaers (DoD).
Erste Compiler gab es meines Wissens so um 1981 herum, offiziell Standard
wurde diese Sprache 1983 (Mil-Std) und aufgrund einer Policy zur vor-
geschriebenen Sprache fuer die Militaers. Ausnahmen waren nur mit mehr
oder minder schwerwiegenden Gruenden erlaubt. 1987 wurde diese Sprache
auch ISO-standardisiert. Bereits in dieser Version (Ada-83) beinhaltete
die Sprache ein Modul-Konzept, ein strenges Typsystem, Ausnahmebehandlung,
generische Bibliotheken (vgl. templates in C++) und Hilfsmittel fuer mehrere
Kontrollfluesse (Tasking mittels Rendezvous-Konzept).
Gerade letztere Features machte diese Sprache sehr komplex und auf den
damaligen Mikrocomputern nicht lauffaehig. Bei den meisten wurde
die Sprache als Sprach-Monster belaechelt, das zu nichts gut war...dabei
war diese Sprache ihrer Zeit weit voraus. 1995 wurde schliesslich ein neuer
Standard festgelegt, das heutige Ada. Hinzukamen insbesondere weitere
Features fuer Multiprocessing (Schutz von Daten bei Shared Memory ohne
aktives Rendezvous) und eine Erweiterung des Typ-Systems in Richtung
Objekt-Orientierung. Ada war somit die erste ISO-standardisierte objekt-
orientierte Sprache.
Das sog. Ada-Mandat, das die Verwendung von Ada im militaerischen vorgab ist
1996 weitgehend weggefallen, allerdings scheint sich Ada trotzdem bei der
Luftfahrtindustrie zunehmender Beliebtheit zu erfreuen. Dies duerfte an
dem strengen Typ-Konzept und auch dem guten Modul-System liegen. Ausserdem
sind inzwischen einige sehr gute Compiler fuer div. Plattformen erhaeltlich.
Im Bereich der Embedded systems scheint nur C noch weiter verbreitet zu sein.
Das allseits beliebte C++ hingegen krankt derzeit an einem immer noch nicht
verabschiedeten ISO-Standard und nur eingeschraenkt funktionierenden
Compilern. Auf Exoten-Hardware ist meines Erachtens auf absehbare Zeit nicht
mit C++ zu rechnen. Dies duerfte daran liegen, dass --- obwohl sprachlich
weniger Moeglichkeiten als Ada --- die Sprache aus Gruenden der Abwaerts-
kompatibilitaet sehr komplex geworden ist (Der Standard ist laenger als der
von Ada-95), zudem scheinen mir exception-handling und templates noch nicht
sehr ausgereift.
So, dies als kleiner Exkurs in die Software-Ecke. Er schien mir angemessen,
da diese Sprache doch recht haeufig im Bereich Raum- und Luftfahrt anzutreffen
ist. Ich hoffe, es entsteht keiner der klassischen Sprach-Kriege. Wer sich
weiter dafuer interessiert, moege sich bitte unter
http://www.adahome.com
http://www.ada-deutschland.de/
umsehen oder einen Blick in die Gruppe comp.lang.ada werfen. Falls eine
weitere Diskussion erwuenscht ist, sollten wir uns wohl nach c.l.a. oder
auf email verlagern um die Newsgruppe nicht mit off-topic-Diskussionen zu
ueberschuetten. Im Moment hab ich das Follow-Up noch unveraendert gelassen.
Freundliche Gruesse
Joerg