Discussion:
Immer wieder Software-Fehler: Schiaparelli u.a.
(zu alt für eine Antwort)
Helmut Schellong
2017-01-29 11:23:00 UTC
Permalink
Raw Message
Es ist ja vor etwa 3 Monaten der Marslander Schiaparelli auf der
Mars-Oberfläche zerschellt.
Wegen Software-Fehler.
Der Fehler hat Ähnlichkeit mit dem Ariane5-Fehler.

Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Für ihn ist der Fehler etwas zum Schämen.

Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
wenn notwendige Überlegungen beim Programmieren unterlassen
werden, und ähnliche Vorkommnisse.

Im Internet kann man hämische Kommentare lesen:
"Der Betriebswirt ordnet an: jetzt ist der Lander fertig entwickelt."
Wie bei CSI aufgeschnappt: "Der Staatsanwalt sagt, wir sind jetzt fertig
mit unseren Tatort-Ermittlungen."

Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Olaf Kaluza
2017-01-29 11:42:31 UTC
Permalink
Raw Message
Post by Helmut Schellong
Einheiten [Feet] und [m] verwechselt wurden.
Für ihn ist der Fehler etwas zum Schämen.
Da hat er wohl Recht. Die Messgeraete in meiner Firma rechnen intern
immer mit physikalischen Basiseinheiten. Lediglich fuer die
Userausgabe kann dann jeder Firlefanz eingestellt werden.

Bin mal gespannt ob Trump bald eine neue Meile definiert. :-D
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
Damals konnte eine Einzelperson das komplette Projekt, also die
gesamte Software und wohl auch noch die Hardware durchschauen und
verstehen. Das geht heute nicht mehr. Es gibt viel mehr Spielraum fuer
Inkompetenz. Ausserdem Probleme? Was solls, wenn sich der Kunde zu
laut beschwert gibt es halt ein Firmwareupdate. :-)

Weisst du wann ich das erste mal dachte das es jetzt mit der
Menschheit bergab geht? Als ich ein Autoradio (von Sony) hatte, dass
auf der Front ein kleines Loch fuer einen Resettaster hatte.

Olaf
Thomas Koenig
2017-01-29 19:50:48 UTC
Permalink
Raw Message
Post by Olaf Kaluza
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
Damals konnte eine Einzelperson das komplette Projekt, also die
gesamte Software und wohl auch noch die Hardware durchschauen und
verstehen.
Das war ein ganz schön großes Team dabei... aber es waren auch
ungefähr 150 KB.

Interessanterweise hieß der Chef-Architekt der Software "Hal"...
https://en.wikipedia.org/wiki/J._Halcombe_Laning
Helmut Schellong
2017-01-29 21:07:12 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Das war ein ganz schön großes Team dabei... aber es waren auch
ungefähr 150 KB.
Ich weiß nicht, ob ~30 KB .obj oder .asm war, oder ob
~30 KB nicht ganz komplett war.
Kann sein, daß es ~30 KB CODE-Segment war und 150 KB Quelle.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-01-29 22:10:56 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Das war ein ganz schön großes Team dabei... aber es waren auch
ungefähr 150 KB.
Ich weiß nicht, ob ~30 KB .obj oder .asm war, oder ob
~30 KB nicht ganz komplett war.
Aus der vorher zitierten Quelle:

"it is correct to say that we landed on the moon with 152 Kbytes of
onboard computer memory."
Helmut Schellong
2017-01-30 11:58:46 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Das war ein ganz schön großes Team dabei... aber es waren auch
ungefähr 150 KB.
Ich weiß nicht, ob ~30 KB .obj oder .asm war, oder ob
~30 KB nicht ganz komplett war.
"it is correct to say that we landed on the moon with 152 Kbytes of
onboard computer memory."
Das bedeutet, daß ~30 KB CODE dort hinein passen
plus >100 KB Daten.

Es muß stets beachtet werden, was genau vorliegt.
Andernfalls kann man um leicht um 300% daneben liegen.

~30 KB: Vor langer Zeit hatte ich gelesen, daß es bei
Apollo >30 KB Assembler-Code gegeben haben soll.
Ich nahm dann an, dies waren ~30 KB binärer Code, also
keine Daten, und nicht die Quelle-Größe.

Die oben stehende Größe von 152 KB ist wohl einfach nur die
Hardware-Größe des Arbeitsspeichers, wobei sogar das noch
unsicher ist, weil Festplattenplatz inbegriffen sein kann.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-01-30 18:06:38 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Das war ein ganz schön großes Team dabei... aber es waren auch
ungefähr 150 KB.
Ich weiß nicht, ob ~30 KB .obj oder .asm war, oder ob
~30 KB nicht ganz komplett war.
"it is correct to say that we landed on the moon with 152 Kbytes of
onboard computer memory."
Das bedeutet, daß ~30 KB CODE dort hinein passen
plus >100 KB Daten.
Das steht alles in der Quelle drin, die ich zitiert habe.
Spekulieren ist bei der Erkenntnis manchmal wenig zielführend :-)
Hermann Riemann
2017-01-29 15:44:06 UTC
Permalink
Raw Message
Post by Helmut Schellong
Es ist ja vor etwa 3 Monaten der Marslander Schiaparelli auf der
Mars-Oberfläche zerschellt.
Wegen Software-Fehler.
Der Fehler hat Ähnlichkeit mit dem Ariane5-Fehler.
Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Für ihn ist der Fehler etwas zum Schämen.
Was hat das mit C oder irgendeiner anderen Programmiersprache zu tun?
Ist das nicht ein Organisations (design) Fehler?
Ein software fehlen wäre eher z.B. ein falsches Vorzeichen,
Verwechslung eines Variablennamens ..

In welcher Sprache ist logische exception handling verboten?
Post by Helmut Schellong
Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
Doch sie fangen einige Fehler ab, aber nicht alle.
Z.B. gibt es bei Fortran compiler, die Optionen haben,
um die Überschreitung von array Grenzen zu überprüfen.
Einer der häufigsten Fehler ist bei fortran
a[0] bei C a[Elementzahl]
Und in höheren Programmiersprachen kann man interpreter bauen,
die ihrerseits unsicher sind.
Post by Helmut Schellong
wenn notwendige Überlegungen beim Programmieren unterlassen
werden, und ähnliche Vorkommnisse.
Das ist menschlich.
Programmieren ähnelt der Gesetzgebung,
bei den die Anwendung nicht unbedingt immer ..

Beispiel
struct xy { short a; long b; } *c;
Ist a jetzt durch *(short *)c richtig adressiert?
Post by Helmut Schellong
"Der Betriebswirt ordnet an: jetzt ist der Lander fertig entwickelt."
Wie bei CSI aufgeschnappt: "Der Staatsanwalt sagt, wir sind jetzt fertig
mit unseren Tatort-Ermittlungen."
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
Möglicherweise schon.
Ich erinnere mich an Algol60 auf einer Siemens 2002.
Programm auf Lochstreifen, beim ersten Fehler blieb der Rechner einfach
stehen,
und man musste das ganze Programm nochmal eintippen.
Bei so was lernt man aufpassen.

Hermann
der an automatische Aufpasser denkt,
welche Programmlogik ( auch vage Formulierungen )
gegen Wissen bzw. Experimente überprüft,
die wahlweise C oder Maschinencode erzeugt.
--
http://www.hermann-riemann.de
Peter J. Holzer
2017-01-29 18:22:33 UTC
Permalink
Raw Message
Post by Hermann Riemann
Post by Helmut Schellong
Es ist ja vor etwa 3 Monaten der Marslander Schiaparelli auf der
Mars-Oberfläche zerschellt.
Wegen Software-Fehler.
Der Fehler hat Ähnlichkeit mit dem Ariane5-Fehler.
Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Ich glaube, Lesch verwechselt da was. Das war die Ursache bei einer
anderen Marssonde vor 20+ Jahren.

Bei Schiaparelli wurde offenbar die Rotationsgeschwindigkeit falsch
gemessen und/oder ausgewertet (die Pressemitteilung im November war
leider sehr vage, und offizielles Postmortem habe ich noch keines
gesehen).
Post by Hermann Riemann
Post by Helmut Schellong
Für ihn ist der Fehler etwas zum Schämen.
Was hat das mit C oder irgendeiner anderen Programmiersprache zu tun?
Manche Sprachen machen es leichter oder schwerer, bestimmte
Programmierfehler zu machen. Bei Schiaparelli wissen wir allerdings
weder, was der Fehler überhaupt war, noch in welcher Programmiersprache
der entsprechende Code geschrieben war. Also ist es müßig, darüber zu
spekulieren, und Helmut wollte wohl nur mal wieder einen Rant schreiben.
Post by Hermann Riemann
In welcher Sprache ist logische exception handling verboten?
Post by Helmut Schellong
Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
Doch sie fangen einige Fehler ab, aber nicht alle.
Z.B. gibt es bei Fortran compiler, die Optionen haben,
um die Überschreitung von array Grenzen zu überprüfen.
Einer der häufigsten Fehler ist bei fortran
a[0] bei C a[Elementzahl]
Das ist in so ziemlich jeder Programmierprache außer C Standard.

Es ist aber noch einiges mehr möglich. Ein geeignetes Typsystem kann
z.B. verhindern, dass man Längen und Feet und Metern addiert. (Das geht
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.

In C kann man sich da höchstens durch Krücken wie ungarische Notation
(die Apps-Variante, nicht die (ziemlich sinnlose) System-Variante)
helfen, oder durch haufenweise opake Typen und Hilfsfunktionen.
Post by Hermann Riemann
Post by Helmut Schellong
"Der Betriebswirt ordnet an: jetzt ist der Lander fertig entwickelt."
Wie bei CSI aufgeschnappt: "Der Staatsanwalt sagt, wir sind jetzt fertig
mit unseren Tatort-Ermittlungen."
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
Möglicherweise schon.
Nein, war man auch nicht. Lowell hat den Navigationscomputer zweimal
durch eine Fehlbedienung zum Absturz gebracht. Der Fehler war vorher
bekannt, aber das Management hat den Bugfix mit der Begründung
»Astronauten machen keine Fehler« verweigert (und ja, der Absturz hat
die Crew in Lebensgefahr gebracht. Die Rettung war nur weniger
dramatisch als bei Apollo 13).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2017-01-29 21:13:30 UTC
Permalink
Raw Message
... in welcher Programmiersprache
der entsprechende Code geschrieben war. Also ist es müßig, darüber zu
spekulieren, und Helmut wollte wohl nur mal wieder einen Rant schreiben.
Ich wollte noch eventuell eine meiner Meinung nach 100% sichere
Programmierung beispielhaft beschreiben; damit hier nicht
10 Woelfel hintereinander stehen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Markus Raab
2017-01-29 22:51:45 UTC
Permalink
Raw Message
Hallo,
Post by Peter J. Holzer
Post by Hermann Riemann
Doch sie fangen einige Fehler ab, aber nicht alle.
Z.B. gibt es bei Fortran compiler, die Optionen haben,
um die Überschreitung von array Grenzen zu überprüfen.
Einer der häufigsten Fehler ist bei fortran
a[0] bei C a[Elementzahl]
Das ist in so ziemlich jeder Programmierprache außer C Standard.
Wenn du Laufzeitüberprüfung meinst, vielleicht. Das hätte die Rakete aber
wohl auch nicht gerettet. Es statisch zu überprüfen ist sogar ein überaus
schwieriges Problem und nur mit Vereinfachungen (wie z.b. mit Iteratoren)
lösbar. Siehe z.b. Rust.
Post by Peter J. Holzer
Es ist aber noch einiges mehr möglich. Ein geeignetes Typsystem kann
z.B. verhindern, dass man Längen und Feet und Metern addiert. (Das geht
Ja, das kann auch das Typsystem von C:

struct feet { int feet; };
struct meter { int meter; };
int main () {
struct feet f;
struct feet m;
return f.feet + m.meter;
}

unit.c:6:19: error: ‘struct feet’ has no member named ‘meter’
return f.feet + m.meter;
Post by Peter J. Holzer
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.
Templates sind in dem Kontext nützlich um viele verschiedene Typen zu
generieren, haben aber nichts damit zu tun ob dieser Ausdruck funktioniert.
Für solche Ausdrücke ist simples Überladen von Operatoren ausreichend.
Post by Peter J. Holzer
In C kann man sich da höchstens durch Krücken wie ungarische Notation
(die Apps-Variante, nicht die (ziemlich sinnlose) System-Variante)
Wie soll eine Notation hier helfen? Da kann man ja trotzdem feet auf meter
zuweisen?
Post by Peter J. Holzer
helfen, oder durch haufenweise opake Typen und Hilfsfunktionen.
Das ist im Prinzip wie es in C++ funktioniert; nur sind die Hilfsfunktionen
nicht sichtbar weil Ihr Aufruf syntaktisch gleich wie die der Aufruf von
Standardoperatoren ist.

glg Markus
Helmut Schellong
2017-01-30 12:35:24 UTC
Permalink
Raw Message
Post by Markus Raab
Hallo,
[...]
[...]
Post by Markus Raab
Post by Peter J. Holzer
Es ist aber noch einiges mehr möglich. Ein geeignetes Typsystem kann
z.B. verhindern, dass man Längen und Feet und Metern addiert. (Das geht
struct feet { int feet; };
struct meter { int meter; };
int main () {
struct feet f;
struct feet m;
return f.feet + m.meter;
}
unit.c:6:19: error: ‘struct feet’ has no member named ‘meter’
return f.feet + m.meter;
Post by Peter J. Holzer
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.
[...]
[...]

Ich halte all das für absolut abenteuerlich und horrend unprofessionell.

Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben, sondern
nur primäre Einheiten des SI-Systems.
Wenn es [feet] aber doch gibt, dann müssen solche Werte (gegeben:...)
an frühestmöglicher Stelle in [m;dm;mm] umgewandelt werden.

Es ist auskömmlich, 32-Bit-Signed-Integer durchgehend mit der
Einheit [m/10] zu verwenden, bei Landeoperationen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Stefan Reuther
2017-01-30 16:42:01 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.
[...]
Ich halte all das für absolut abenteuerlich und horrend unprofessionell.
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben, sondern
nur primäre Einheiten des SI-Systems.
Wenn es [feet] aber doch gibt, dann müssen solche Werte (gegeben:...)
an frühestmöglicher Stelle in [m;dm;mm] umgewandelt werden.
Man mag zu Schurkenstaateneinheiten stehen wie man will, aber wenn die
Eingabe in Feet kommt und die Ausgabe in Feet erwartet wird, binde ich
mir dafür keine Konvertierung Imperial<>Metrisch mit den üblichen
Floating-Point-Rundungsfehlern ans Bein. Dann habe ich halt die exakten
Umrechnungsfaktoren 12 inch = 1 foot, 3 feet = 1 yard (und nicht den
nicht exakt darstellbaren Umrechnungsfaktor 30.48 cm = 1 foot).

Mit gescheiten Typsystemen kann man dann dafür sorgen, dass solche
Probleme - je nach Vorlieben - automatisch oder nur auf ausdrückliche
Anweisung durch eine Konvertierung aufgelöst werden.


Stefan
Thomas Koenig
2017-01-30 18:14:50 UTC
Permalink
Raw Message
Post by Stefan Reuther
Man mag zu Schurkenstaateneinheiten stehen wie man will, aber wenn die
Eingabe in Feet kommt und die Ausgabe in Feet erwartet wird, binde ich
mir dafür keine Konvertierung Imperial<>Metrisch mit den üblichen
Floating-Point-Rundungsfehlern ans Bein.
Interessanterweise haben die das bei den Apollo-Computern genau das
gemacht. Rechnung war metrisch, Ausgabe war Feet.

Ansonsten hatte ich mich auch schon gefragt, wie man mit einem Satz
wie "Nachdem die Entfernung von 50 Seemeilen auf unter 10000 Fuß
gefallen war" (so oder ähnlich aus einer Veröffentlichung zum
Landen von Apollo 12) überhaupt jemals heil da an- und wieder
wegkam.
Helmut Schellong
2017-01-30 18:44:49 UTC
Permalink
Raw Message
Post by Stefan Reuther
Post by Helmut Schellong
Post by Peter J. Holzer
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.
[...]
Ich halte all das für absolut abenteuerlich und horrend unprofessionell.
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben, sondern
nur primäre Einheiten des SI-Systems.
Wenn es [feet] aber doch gibt, dann müssen solche Werte (gegeben:...)
an frühestmöglicher Stelle in [m;dm;mm] umgewandelt werden.
Man mag zu Schurkenstaateneinheiten stehen wie man will, aber wenn die
Eingabe in Feet kommt und die Ausgabe in Feet erwartet wird, binde ich
mir dafür keine Konvertierung Imperial<>Metrisch mit den üblichen
Floating-Point-Rundungsfehlern ans Bein. Dann habe ich halt die exakten
Umrechnungsfaktoren 12 inch = 1 foot, 3 feet = 1 yard (und nicht den
nicht exakt darstellbaren Umrechnungsfaktor 30.48 cm = 1 foot).
Mit gescheiten Typsystemen kann man dann dafür sorgen, dass solche
Probleme - je nach Vorlieben - automatisch oder nur auf ausdrückliche
Anweisung durch eine Konvertierung aufgelöst werden.
Das ist eine seltsame Argumentation, die wohl kaum etwas mit den
realen Marslandern zu tun hat.

https://de.wikipedia.org/wiki/Fu%C3%9F_%28Einheit%29
https://de.wikipedia.org/wiki/Angloamerikanisches_Ma%C3%9Fsystem
https://upload.wikimedia.org/wikipedia/commons/e/eb/English_length_units_graph.svg

Die Grafik mit fast 40 Längenmaßen kann ersetzt werden durch '[vorsatz]m'.

Bei der Landung des Schiaparelli-Landers waren Ungenauigkeiten
von wenigen Prozent sicher irrelevant.
Gleitkomma-Ungenauigkeiten ebenso.

Unwahrscheinlich ist auch, daß Input und Output in [foot] irgendwo
verlangt war.
Falls doch, wäre wohl eine Verwechselung von Fuß und Meter
wegen Fehlens von Meter nicht möglich gewesen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-01-30 18:04:57 UTC
Permalink
Raw Message
Post by Helmut Schellong
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben, sondern
nur primäre Einheiten des SI-Systems.
[ ] Du hast schon Programme geschrieben, die sich mit
einzelnen Quanten oder Teilchen beschäftigen.
Claus Reibenstein
2017-01-30 18:37:12 UTC
Permalink
Raw Message
Post by Helmut Schellong
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben,
sondern nur primäre Einheiten des SI-Systems.
[ ] Du hast schon Programme geschrieben, die sich mit einzelnen
Quanten oder Teilchen beschäftigen.
Braucht man die für solche Missionen?

Gruß
Claus
Thomas Koenig
2017-02-01 19:50:27 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Post by Helmut Schellong
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben,
sondern nur primäre Einheiten des SI-Systems.
[ ] Du hast schon Programme geschrieben, die sich mit einzelnen
Quanten oder Teilchen beschäftigen.
Braucht man die für solche Missionen?
Helmuts Aussage war allgemein, nicht auf die Apollo-Missionen beschränkt.
Helmut Schellong
2017-02-01 21:21:10 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Claus Reibenstein
Post by Helmut Schellong
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben,
sondern nur primäre Einheiten des SI-Systems.
[ ] Du hast schon Programme geschrieben, die sich mit einzelnen
Quanten oder Teilchen beschäftigen.
Braucht man die für solche Missionen?
Helmuts Aussage war allgemein, nicht auf die Apollo-Missionen beschränkt.
Auf Schiaparelli beschränkt:
===========================================================================
Erstens sollte es Einheiten wie [feet] überhaupt gar nicht geben, sondern
nur primäre Einheiten des SI-Systems.
Wenn es [feet] aber doch gibt, dann müssen solche Werte (gegeben:...)
an frühestmöglicher Stelle in [m;dm;mm] umgewandelt werden.

Es ist auskömmlich, 32-Bit-Signed-Integer durchgehend mit der
Einheit [m/10] zu verwenden, bei Landeoperationen. <-- ***
===========================================================================
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-02-02 18:38:47 UTC
Permalink
Raw Message
Post by Helmut Schellong
Es ist auskömmlich, 32-Bit-Signed-Integer durchgehend mit der
Einheit [m/10] zu verwenden, bei Landeoperationen. <-- ***
Ich nehme an, du verwendst keine numerisch gebildeten Ableitungen
in deinen Programmen?
Helmut Schellong
2017-02-02 20:01:51 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Es ist auskömmlich, 32-Bit-Signed-Integer durchgehend mit der
Einheit [m/10] zu verwenden, bei Landeoperationen. <-- ***
Ich nehme an, du verwendst keine numerisch gebildeten Ableitungen
in deinen Programmen?
In denjenigen Programmen gibt es in etwa 160000 Zeilen
etwa acht Zeilen mit 'float' und 'double'.

scal= ((float)(ap->ist2-ap->ist1)*NS_ADC2)
/ (float)(ap->adc2-ap->adc1);
offs= ap->ist2/scal - (float)ap->adc2/NS_ADC2;
(INT4)((double)Kpz.A.as[g-1]*0.277615835207240221+0.5));

Falls Du so etwas als numerisch gebildete Ableitung bezeichnest.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Peter J. Holzer
2017-01-30 20:00:08 UTC
Permalink
Raw Message
Post by Markus Raab
Hallo,
Post by Peter J. Holzer
Post by Hermann Riemann
Doch sie fangen einige Fehler ab, aber nicht alle.
Z.B. gibt es bei Fortran compiler, die Optionen haben,
um die Überschreitung von array Grenzen zu überprüfen.
Einer der häufigsten Fehler ist bei fortran
a[0] bei C a[Elementzahl]
Das ist in so ziemlich jeder Programmierprache außer C Standard.
Wenn du Laufzeitüberprüfung meinst, vielleicht.
Ich nehme an, dass mein Vorposter das gemeint hat, und habe entsprechend
geantwortet.

Sollte es Fortran-Compiler geben, die das statisch machen, nehme ich
alles zurück und behaupte das Gegenteil.
Post by Markus Raab
Das hätte die Rakete aber wohl auch nicht gerettet.
Schon deshalb nicht, weil gar kein Array-Überlauf im Spiel war ;-).

Abgesehen davon kann "Programm killen und neu starten" durchaus auch
bei Echtzeitsystemen eine sinnvolle Strategie sein. Dann ist die
Komponente wenigstenss still und pfuscht nicht mit falschen Werten
dazwischen. (Praktisch wäre dann natürlich, wenn die redundante
Komponente nicht den gleichen Bug aufweist.)
Post by Markus Raab
Post by Peter J. Holzer
Es ist aber noch einiges mehr möglich. Ein geeignetes Typsystem kann
z.B. verhindern, dass man Längen und Feet und Metern addiert. (Das geht
struct feet { int feet; };
struct meter { int meter; };
int main () {
struct feet f;
struct feet m;
return f.feet + m.meter;
}
unit.c:6:19: error: ‘struct feet’ has no member named ‘meter’
return f.feet + m.meter;
Das Beispiel ist verkehrt herum, oder? Du willst verhindern, dass jemand
eine struct feet und eine struct meter addiert:

struct feet move (struct feet oldposition, struct meter distance) {
struct feet newposition;
newposition.feet = oldposition.feet + distance.feet;
return newposition;
}

Wenn der Programmierer dann die Fehlermeldung "'struct meter' has no member 'feet'"
bekommt, bessert er die Zeile hoffentlich nicht in

newposition.feet = oldposition.feet + distance.meter;

aus (das würde den Compiler ruhigstellen), sondern ihm fällt auf, dass
er feet und meter nicht addieren kann und schreibt

newposition.feet = oldposition.feet + distance.meter * FEET_PER_METER;
Post by Markus Raab
Wie soll eine Notation hier helfen? Da kann man ja trotzdem feet auf meter
zuweisen?
Ja, genauso, wie ich auch »oldposition.feet + distance.meter« schreiben
kann. Dein Trick mit den structs funktioniert auch nur, weil der
Programmierer gezwungen wird, feet und meter hinzuschreiben und im dabei
auffällt, dass da was nicht stimmen kann. Ist bei

float lnftMove(float lnftOldPosition, float lnmDistance) {
return lnftOldPosition + lnmDistance;
}

genau das gleiche: lnft* und lnm* sind inkompatibel und das fällt dem
Programmierer (hoffentlich) auf.
Post by Markus Raab
Post by Peter J. Holzer
sogar in Sprachen wie C++, allerdings muss man da ein ziemlich
kompliziertes Template-System aufbauen, damit z.B. Ausdrücke wie
»s = a/2 * t * t« richtig funktionieren.
Templates sind in dem Kontext nützlich um viele verschiedene Typen zu
generieren, haben aber nichts damit zu tun ob dieser Ausdruck funktioniert.
Für solche Ausdrücke ist simples Überladen von Operatoren ausreichend.
Ja, die Templates dienen natürlich dazu, die notwendigen Typen und
Überladungen on the fly zu generieren. Man könnte die natürlich auch
händisch definieren. Die Idee bei dem Template-System (ich verwende es
nicht und kenne es nur vom Hörensagen, weil ich nicht in C++
programmiere) ist offenbar, es dem Programmierer so einfach zu machen,
physikalische Einheiten in Programmen zu verwenden, dass er es auch
freiwillig tut.
Post by Markus Raab
Post by Peter J. Holzer
In C kann man sich da höchstens durch Krücken wie ungarische Notation
(die Apps-Variante, nicht die (ziemlich sinnlose) System-Variante)
helfen, oder durch haufenweise opake Typen und Hilfsfunktionen.
Das ist im Prinzip wie es in C++ funktioniert; nur sind die Hilfsfunktionen
nicht sichtbar weil Ihr Aufruf syntaktisch gleich wie die der Aufruf von
Standardoperatoren ist.
Das ist aber wichtig. »s = a/2 * t * t« ist nicht nur weniger zu tippen
als »s = mul__m_per_s2__s2(div__m_per_s2__unit(a, 2), sq__s(t))«,
sondern auch deutlich lesbarer.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-01 13:24:06 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Das ist aber wichtig. »s = a/2 * t * t« ist nicht nur weniger zu tippen
als »s = mul__m_per_s2__s2(div__m_per_s2__unit(a, 2), sq__s(t))«,
sondern auch deutlich lesbarer.
Für verschiedenste Dinge aus dem Problembereich werden
getypte Objekte nahe gelegt. Augenscheinlich nicht für
naturwissenschaftlich oder e-technisch "informierte" Formeln
in traditionellen Sprachen.

Warum sträuben sich fast alle Sprachentwickler, so etwas wie
Zahlen ausdrücklich für Repräsentationen vorzusehen und
Programmierern nahe zu legen, für Meter usw, nur Typen,
nicht aber den Typ verwischende Repräsentation zu verwenden?

Die Kunst bestünde darin, dem gut bezahlten Sprach-Fanatiker eine
den Status erhaltende Änderung in seiner programmiersprachlichen
Ausdrucksweise zu ermöglichen.

So dass sie nicht mehr auf die Idee kämen, oder gebracht würden,
es sei richtig und deshalb gut, dass, exemplarisch,

'A' == 65

Nicht mehr, weil eine Repräsentation, die nur normexegetisch
befügelt Richtung logischer Sonne fliegend begründet werden
kann (oder eben gegen die Marsoberfläche), die aber vielleicht
nur kopierte und nicht sehr nachdenkliche Tradition ist.

Dass diese Gleichung im Ausdrucksvorrat der Programmierer
weiter Bestand hat, statt für illegal erklärt und vom
compiler-Hersteller mit eineindeutiger, persistenter
Programmtransformation beseitigt zu werden, ist irgendwie
entlarvend.
Thomas Koenig
2017-02-01 19:52:53 UTC
Permalink
Raw Message
Peter J. Holzer <hjp-***@hjp.at> schrieb:

[Arraygrenzen überprüfen]
Post by Peter J. Holzer
Sollte es Fortran-Compiler geben, die das statisch machen, nehme ich
alles zurück und behaupte das Gegenteil.
Nur für einfache Fälle:

$ cat a.f90
program main
real, dimension(10) :: a
read (*,*) a(11)
end program main
$ gfortran a.f90
a.f90:3:15:

read (*,*) a(11)
1
Warning: Array reference at (1) is out of bounds (11 > 10) in dimension 1
Peter J. Holzer
2017-02-03 17:35:32 UTC
Permalink
Raw Message
Post by Thomas Koenig
[Arraygrenzen überprüfen]
Post by Peter J. Holzer
Sollte es Fortran-Compiler geben, die das statisch machen, nehme ich
alles zurück und behaupte das Gegenteil.
$ cat a.f90
program main
real, dimension(10) :: a
read (*,*) a(11)
end program main
$ gfortran a.f90
read (*,*) a(11)
1
Warning: Array reference at (1) is out of bounds (11 > 10) in dimension 1
Bei einer einfachen Schleife allerdings schon nicht mehr:

% cat a.90
program main
real, dimension(10) :: a
do i = 1, 11
a(i) = 3.14
end do
end program
% gfortran a.f90

(kein Output)

Zur Laufzeit kracht es allerdings dann:

% ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0 0xB7601D6E
#1 0xB76023C7
#2 0xB7729D1B
#3 0x8048549 in MAIN__ at a.f90:?
zsh: segmentation fault (core dumped) ./a.out

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Koenig
2017-02-03 19:02:33 UTC
Permalink
Raw Message
Post by Peter J. Holzer
% cat a.90
program main
real, dimension(10) :: a
do i = 1, 11
a(i) = 3.14
end do
end program
% gfortran a.f90
(kein Output)
% ./a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
Yep. Zum Glück gibt es die bewährten Optionen (sollte man sich für ein
erstes Übersetzen mal vornehmen :-)

$ gfortran -Og -g -Wall -Wextra -Werror -fmax-errors=1 -fcheck=all -fsanitize=address -finit-integer=-987654320 -finit-real=nan a.f90
$ ./a.out
At line 4 of file a.f90
Fortran runtime error: Index '11' of dimension 1 of array 'a' above
upper bound of 10

Error termination. Backtrace:
#0 0x400c80 in MAIN__
at /home/ig25/a.f90:4
#1 0x400da0 in main
at /home/ig25/a.f90:6
$

Damit findet man schon ein paar Fehler.
Helmut Schellong
2017-01-30 15:42:23 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Helmut Schellong
Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Ich glaube, Lesch verwechselt da was. Das war die Ursache bei einer
anderen Marssonde vor 20+ Jahren.
http://download.zdf.de/mp4/zdf/17/01/170122_sendung_lek/1/170122_sendung_lek_3296k_p15v13.mp4

Ab etwa 6:00 min.
Es wurde zwar in einem Atemzug erzählt, aber das mit
Fuß und Meter betraf wohl nicht Schiaparelli.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-01-30 16:28:03 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Post by Helmut Schellong
Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Ich glaube, Lesch verwechselt da was. Das war die Ursache bei einer
anderen Marssonde vor 20+ Jahren.
http://download.zdf.de/mp4/zdf/17/01/170122_sendung_lek/1/170122_sendung_lek_3296k_p15v13.mp4
Ab etwa 6:00 min.
Es wurde zwar in einem Atemzug erzählt, aber das mit
Fuß und Meter betraf wohl nicht Schiaparelli.
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
===============================================================================================
Gut einen Monat nachdem die ESA-Sonde Schiaparelli auf den Mars gestürzt ist
und dabei zerstört wurde, hat die Weltraumagentur den verantwortlichen Fehler
wohl gefunden. Ein überlasteter Sensor verfälschte wohl die Höhenmessung des
Geräts.

Der ESA-Lander Schiaparelli ist wohl wegen eines Messfehlers und daraus
resultierender falscher Berechnungen auf dem Mars abgestürzt. Das jedenfalls
ist das vorläufige Ergebnis einer Untersuchung, zu der die Europäische
Weltraumagentur nun Details veröffentlichte. Demnach lief den empfangenen
Daten zufolge anfangs alles nach Plan. Dann habe das für die Messung der
Eigendrehung zuständige IMU (Inertial Measurement Unit) aber ungefähr eine
Sekunde lang eine Messbereichsüberschreitung registriert, wodurch andere
Berechnungen überlastet worden seien. Als Konsequenz habe der Lander einen
negativen Wert für die geschätzte Höhe ermittelt. Schiaparelli habe sich dann
so verhalten, als sei er bereits gelandet, was angesichts einer tatsächlichen
Höhe von 3,7 Kilometern zum Absturz geführt habe.

Schiaparelli habe also viel zu früh den Fallschirm und einen der
Schutzschilde gelöst. Dieses fehlerhafte Verhalten sei im eigenen Simulator
exakt so reproduziert worden, teilten die Ingenieure nun mit. Bereits kurz
nach dem Absturz hatte es Hinweise auf einen Softwarefehler als Grund für das
vorzeitige Missionsende gegeben. Einen ausführlichen Bericht soll Anfang 2017
ein unabhängiges Untersuchungsteam vorlegen.

http://m.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress
===============================================================================================

Ich interpretiere das so, daß andere korrekte Meßergebnisse zur Höhe
des Landers über der Marsoberfläche, z.B. durch das Doppler-Radar, wegen
einer Limit-Überschreitung beim Trägheitsnavigationssystem (IMU) ignoriert
und sogar verfälscht wurden!
Die Höhenauswertung hat sich unberechtigt von der IMU 'stören' lassen.
Das deutet auf unklare, verwurschtelnde Programmierung hin.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Rainer Weikusat
2017-01-30 17:06:27 UTC
Permalink
Raw Message
Helmut Schellong <***@schellong.biz> writes:

[...]
Post by Helmut Schellong
Die Höhenauswertung hat sich unberechtigt von der IMU 'stören' lassen.
Das deutet auf unklare, verwurschtelnde Programmierung hin.
"Dem Enschinier ist nichts zu wirr".
[SCNR]
Helmut Schellong
2017-01-30 19:08:42 UTC
Permalink
Raw Message
Post by Rainer Weikusat
[...]
Post by Helmut Schellong
Die Höhenauswertung hat sich unberechtigt von der IMU 'stören' lassen.
Das deutet auf unklare, verwurschtelnde Programmierung hin.
"Dem Enschinier ist nichts zu wirr".
[SCNR]
Ja, es gibt programmierende Leute, die kaum Talent für
diese Tätigkeit haben.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-01-31 12:06:29 UTC
Permalink
Raw Message
Post by Helmut Schellong
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
===============================================================================================
[...]
http://m.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress
===============================================================================================
Ich interpretiere das so, daß andere korrekte Meßergebnisse zur Höhe
des Landers über der Marsoberfläche, z.B. durch das Doppler-Radar, wegen
einer Limit-Überschreitung beim Trägheitsnavigationssystem (IMU) ignoriert
und sogar verfälscht wurden!
Die Höhenauswertung hat sich unberechtigt von der IMU 'stören' lassen.
Das deutet auf unklare, verwurschtelnde Programmierung hin.
Ein wichtiger Punkt ist, daß geschrieben wurde, daß die ESA Anfang 2017,
also ungefähr zurzeit, einen genauen Bericht zu den Software-Fehlern
veröffentlichen wird.

Deshalb wurde wohl dieser Fehler bisher auch nicht in Wikipedia
aufgenommen, dort, wo der Ariane5-Fehler beschrieben ist.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-01-31 15:27:30 UTC
Permalink
Raw Message
Post by Helmut Schellong
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
===============================================================================================
http://m.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress
===============================================================================================
Ich interpretiere das so, daß andere korrekte Meßergebnisse zur Höhe
des Landers über der Marsoberfläche, z.B. durch das Doppler-Radar, wegen
einer Limit-Überschreitung beim Trägheitsnavigationssystem (IMU) ignoriert
und sogar verfälscht wurden!
Die Höhenauswertung hat sich unberechtigt von der IMU 'stören' lassen.
Das deutet auf unklare, verwurschtelnde Programmierung hin.
Übersetzung des ESA-Textes:
====================================================================================
23. November 2016
Am 19. Oktober nahm der Mars-lander beim Landen einen guten Verlauf.
Ein großes Datenvolumen vom Mars-lander zeigt beim Eintritt
in die Atmosphäre und beim Einsetzen des Bremsvorgangs exakt ein
Verhalten, wie es erwartet wurde.

Der Fallschirm löste normal aus, bei 12 km Höhe
und einer Sinkgeschwindigkeit von 1730 km/h.
Der Hitzeschild (vorne) wurde bei 7,8 km Höhe abgeworfen.

Als der Mars-lander am Fallschirm sank, funktionierte der
Doppler-Radar-Höhenmesser korrekt und seine Meßwerte wurden
in das Führungs-, Navigations- und Kontrollsystem eingetragen.
Jedoch trat eine Sättigung (Maximum-Messung) in der Trägheits-
meßeinheit (IMU) auf, kurz nach der Fallschirmauslösung.
Die IMU mißt die Rotations-Geschwindigkeit des Mars-landers.
Ihre Ausgaben waren wie erwartet, mit Ausnahme dieser Sättigung,
die etwa eine Sekunde lang anhielt, länger als erwartet.

Durch Verschmelzen dieser fehlerhaften Information in das Navigationssytem
hinein wurde als Folge eine negative Höhe geschätzt, also unterhalb der
Marsoberfläche.
Dies wiederum entfernte frühzeitig den Fallschirm und die hintere
Außenschale und löste insgesamt ein Verhalten aus, als ob der
Mars-lander bereits gelandet wäre.
In Wirklichkeit befand sich der Mars-lander noch in einer Höhe
von +3,7 km.
..............................................................................
Der Mars-lander zerschellte mit 540 km/h auf der Marsoberfläche.
====================================================================================

Ich erkenne nun weitere offensichtliche Fehler.
Das Konzept erscheint hinsichtlich der Prioritäten
falsch und unlogisch zu sein.
Plausibilität erscheint nach wie vor nachrangig bedacht worden zu sein.

http://diepresse.com/home/panorama/raumfahrt/5104965/Marslandung_Ab-dem-Zeitpunkt-lief-etwas-schief?direct=5123432&_vl_backlink=/home/panorama/raumfahrt/5123432/index.do&selChannel=

Es wird eine korrekte Höhenmessung ignoriert oder verworfen
und stattdessen grundlos eine Höhe geschätzt - geschätzt!
Bei einer negativen Höhe kann es keine Rotation geben!

Die Rotation in Sättigung war zudem nach einer Sekunde vorbei!
Dennoch wurden ohne Delay und Hinzuziehung verläßlicher Werte
existenzielle Maßnahmen ausgelöst.

Die Rotation ist doch grundsätzlich nachrangig oder gar irrelevant
für die diversen Zeitpunkte beim Absinken, hinsichtlich Fallschirm,
Hitzeschild, Hülle, Bremstriebwerke.

Eine Höhenmessung ist hier allein entscheidend.
Daraus ergibt sich auch die Sink-Geschwindigkeit.
Bei nicht zu frühem Versagen der Höhenmessung kann recht gut
extrapoliert werden.

Wieso wurde bei einer negativen Höhe der Fallschirm usw. entfernt?
Das hätte doch schon lange zuvor (1.1 km) geschehen sein müssen!

Ich habe doch das starke Gefühl, daß ich in der Industrie
/sicherer/ programmiert habe.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-01 13:00:23 UTC
Permalink
Raw Message
Post by Helmut Schellong
Das hätte doch
Fahrradkette, du Möchtegern-Prophet.


Aber, das Betrübliche an solchen technisch sich manifestierenden
Programm-Fehlern scheint, dass die Analyse durch die Organisation
halboffen bleiben könnte. Denn, abgleitet von Organisations-Verhalten
wie dem der Autofirma oder dem der FIFA oder dem der Stadtverwaltung,

- das kann Geschäftsgeheimnisse schützen,
- das kann betroffene Leute schützen,
- es ist bester Stoff für partikular argumentierende Journalisten,
- es war schon immer so™.

Eine Folge dieser klassisch unvollständigen Wahrheiten sehen wir
ja gerade, eine telegnostische Vorabanalyse von außen, wie man sie
im Politischen gern von Verschwörungstheoretikern hört. Oder
von Opportunisten. Womit im Ergebnis eine entspannte Korrektur
der Verfahren von beiden Seiten verhindert wird: die einen
mauern, die anderen treten. Dazwischen geht etwas kaputt.

Wir brauchen mehr und vor allem gute (gleichsam) Sozialarbeiter
in der Software-Herstellung.
Helmut Schellong
2017-02-01 15:13:58 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Das hätte doch
Fahrradkette, du Möchtegern-Prophet.
Das paßt nicht; ich hatte damit nicht prophetiert, sondern
einen massiven Mangel an Plausibilität festgestellt.

1 Eintritt in die Atmosphäre : 0 s | 121 km | 21000 km/h
2 Hitzeschild-Nutzung : 72 s | 45 km | 19000 km/h
3 Fallschirm-Auslösung : 201 s | 11 km | 1700 km/h
4 Hitzeschild-Abstoßung, Radar EIN : 241 s | 7 km | 320 km/h
5 Abstoßung Rückenschale+Fallschirm: 322 s | 1,2 km | 240 km/h
6 Bremsdüsen-Zündung : 323 s | 1,1 km | 250 km/h
7 Bremsdüsen AUS : 352 s | 2 m | 4 km/h
8 Aufsetzen : 353 s | 0 m | 10 km/h
9 Nach der Landung :353+n s | <=0 m | 0 km/h

Wenn die Navigation eine Höhe von <0 schätzt, nach einem Überlauf,
kann nicht deswegen die Rückenschale+Fallschirm abgestoßen werden,
da dies schon längst zuvor hätte passiert sein müssen!

Die 9 Landezustände können Fälle eines switch sein.
Zustand 9 kann nicht dafür zuständig sein, den Fallschirm abzuwerfen!
(Anders herum: welcher Zustand liegt denn vor? Wirklich schon 9?)
In allen Zuständen müssen jeweils Plausibilitäten geprüft werden.
Die Zustände sind zwingend streng monoton steigend 0...9.
Für jede Aktion müssen Flags gesetzt werden: Start+Vollzug+x
Ich würde auch zusätzlich rein mathematisch permanent eine Höhe
extrapolierend berechnen, auch als Alternative.
Bei Kapitulation in einem Zustand muß ein jeweiliger Ersatz-switch
aktiviert werden, mit einem Plan B.
Post by G.B.
Aber, das Betrübliche an solchen technisch sich manifestierenden
Programm-Fehlern scheint, dass die Analyse durch die Organisation
halboffen bleiben könnte. Denn, abgleitet von Organisations-Verhalten
wie dem der Autofirma oder dem der FIFA oder dem der Stadtverwaltung,
- das kann Geschäftsgeheimnisse schützen,
- das kann betroffene Leute schützen,
- es ist bester Stoff für partikular argumentierende Journalisten,
- es war schon immer so™.
Wir werden die nächsten Ergebnisse, durch eine unabhängige Kommission,
bald zur Kenntnis nehmen können.
Post by G.B.
Eine Folge dieser klassisch unvollständigen Wahrheiten sehen wir
ja gerade, eine telegnostische Vorabanalyse von außen, wie man sie
im Politischen gern von Verschwörungstheoretikern hört. Oder
von Opportunisten. Womit im Ergebnis eine entspannte Korrektur
der Verfahren von beiden Seiten verhindert wird: die einen
mauern, die anderen treten. Dazwischen geht etwas kaputt.
Wir brauchen mehr und vor allem gute (gleichsam) Sozialarbeiter
in der Software-Herstellung.
Kann sein, daß wirklich gute Leute, aber mit eigenen Meinungen und
leicht rebellischem Verhalten, unerwünscht sind.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-01 20:20:23 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by G.B.
Post by Helmut Schellong
Das hätte doch
Fahrradkette, du Möchtegern-Prophet.
Das paßt nicht; ich hatte damit nicht prophetiert, sondern
einen massiven Mangel an Plausibilität festgestellt.
Wenn man, im Zustand unvollständiger Information,
von einigen enthymematisch gegebenen Prämissen als
"feststellbaren" Dingen ausgeht, sagen wir z.B. der irgendwie™
im Nachhinein als im Vorhinein gefälligst vollständig
zu wissenden situativen Parameter, die sich ergeben
werden, dann ist das nicht nur Rückwärtsprophezeihung,
sondern auch der Stoff, aus dem Journalismus gemacht wird.
Möglichst plausibel. Dafür sind Tabellen gut.
Helmut Schellong
2017-02-01 21:54:52 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Post by G.B.
Post by Helmut Schellong
Das hätte doch
Fahrradkette, du Möchtegern-Prophet.
Das paßt nicht; ich hatte damit nicht prophetiert, sondern
einen massiven Mangel an Plausibilität festgestellt.
Wenn man, im Zustand unvollständiger Information,
von einigen enthymematisch gegebenen Prämissen als
"feststellbaren" Dingen ausgeht, sagen wir z.B. der irgendwie™
im Nachhinein als im Vorhinein gefälligst vollständig
zu wissenden situativen Parameter, die sich ergeben
werden, dann ist das nicht nur Rückwärtsprophezeihung,
sondern auch der Stoff, aus dem Journalismus gemacht wird.
Möglichst plausibel. Dafür sind Tabellen gut.
Es gibt einige Daten, die einen eindeutigen Schluß erlauben:
Den Fakt, daß der Lander mit etwa 540 km/h anstatt mit 10 km/h
die Oberfläche erreichte.
Die Information, daß eine negative Höhe geschätzt wurde, wegen
einer zuvor aufgetretenen Sättigung bei Rotationsdaten.
Die Information, daß wegen der Höhenschätzung der Zustand 9
angenommen wurde und deswegen der Fallschirm abgeworfen wurde.

Wie man es auch dreht und wendet (vorwärts, rückwärts, seitwärts),
in keinem Fall war es gerechtfertigt, im Zustand 4 des Landevorgangs
den Zustand 9 nicht festzustellen, sondern aufgrund einer Schätzung
einfach anzunehmen. Weiterhin war es nicht geplant, im Zustand 9
den Zustand 5 nachzuholen.
Man hatte dadurch einfach den geplanten Landevorgang ungerechtfertigt
mißachtet, ihn völlig unplausibel verwürfelt.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-01 22:54:41 UTC
Permalink
Raw Message
"Einige" Daten und ein "eindeutiger" Schluss schließen für
mich einander aus. Wie gesagt. Etwa so:

Es gibt einige unschöne Altlasten in C, deswegen ist die
Sprache eindeutig nicht zu rechtfertigen.
Post by Helmut Schellong
in keinem Fall war es gerechtfertigt, im Zustand 4 des Landevorgangs
den Zustand 9 nicht festzustellen,
Wow. Du kannst die Systemzustände des landers vom fernen
Schreibtisch aus nummerieren.
Helmut Schellong
2017-02-01 23:08:35 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
in keinem Fall war es gerechtfertigt, im Zustand 4 des Landevorgangs
den Zustand 9 nicht festzustellen,
Wow. Du kannst die Systemzustände des landers vom fernen
Schreibtisch aus nummerieren.
Nein, wieso?
Die ESA kann das aber, und deren Planungsdaten hatte ich gepostet.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-02 11:30:58 UTC
Permalink
Raw Message
Post by Helmut Schellong
deren Planungsdaten
noch so ein Plural, der "einige Daten" widerspiegelt
und gleichzeitig suggeriert, die noch ausstehende
Vervollständigung dieser Daten vorwegnehmen zu können.
Helmut Schellong
2017-02-02 13:03:16 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
deren Planungsdaten
noch so ein Plural, der "einige Daten" widerspiegelt
und gleichzeitig suggeriert, die noch ausstehende
Vervollständigung dieser Daten vorwegnehmen zu können.
Wenn ich 'Planungsdatum' geschrieben hätte, wäre ein
massives Mißverständnis vorprogrammiert gewesen.
Außerdem kommt es praktisch nie vor, daß nur ein
einziger Wert vorliegt.
Ein Datum besteht bereits aus mehreren Werten, also Daten.

Loading Image...

Die vorstehenden Daten sind ausreichend für Outsider.
25000 Werte und 50000 Zeilen muß ich nicht haben.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-03 08:18:35 UTC
Permalink
Raw Message
Post by Helmut Schellong
Ein Datum besteht bereits aus mehreren Werten, also Daten.
So wie ein Monatsgehalt aus mehreren Gehältern besteht.
Post by Helmut Schellong
http://exploration.esa.int/science-e-media/img/78/ExoMars2016_DescentInfographic_20160223.jpg
Die vorstehenden Daten sind ausreichend für Outsider.
Die vorstehenden Daten sind ausreichend für Spekulationen.

"Hätte müssen" auf dieser Grundlage macht die Prophetie aus,
im Unterschied zu einer weniger leimläufigen technischen Analyse.
Rainer Weikusat
2017-02-03 14:59:33 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Ein Datum besteht bereits aus mehreren Werten, also Daten.
So wie ein Monatsgehalt aus mehreren Gehältern besteht.
Post by Helmut Schellong
http://exploration.esa.int/science-e-media/img/78/ExoMars2016_DescentInfographic_20160223.jpg
Die vorstehenden Daten sind ausreichend für Outsider.
Die vorstehenden Daten sind ausreichend für Spekulationen.
"Hätte müssen" auf dieser Grundlage macht die Prophetie aus,
im Unterschied zu einer weniger leimläufigen technischen Analyse.
Zu konstatieren das "weil der Computer der Ansicht war, der Flugapperate
befeaende sich mehrere Kilometer unter der Marsoberflaeche, loeste er
den Abwurf des Fallschirms aus" eine Situation dartstellt, die nie
haette auftreten sollen, weil das Fluggeraet sich nicht in einer
solchen Situation befinden kann, ist nicht 'Prophetie'. Man nennt das
"gesunden Menschenverstand".
Peter J. Holzer
2017-02-03 18:00:34 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Zu konstatieren das "weil der Computer der Ansicht war, der Flugapperate
befeaende sich mehrere Kilometer unter der Marsoberflaeche, loeste er
den Abwurf des Fallschirms aus" eine Situation dartstellt, die nie
haette auftreten sollen, weil das Fluggeraet sich nicht in einer
solchen Situation befinden kann, ist nicht 'Prophetie'. Man nennt das
"gesunden Menschenverstand".
Zweifellos. Allerdings hat Helmut aus der dürftigen Pressemeldung noch
einiges mehr herausgelesen. So wie jeder, der das Endergebnis des
Fußballspiels im Radio gehört hat, genau weiß, welche Fehler der Trainer
gemacht hat, so weiß Helmut genau, welche Fehler die Programmierer
gemacht haben.

Und wenn die Fehlerursache gefunden und auf pressetauglichen Detailgrad
eingedampft ist, ist sie fast immer trivial. Die "das hat wirklich
niemand vorhersehen können"-Fehler sind eher selten. Meistens hat
irgendwer irgendwo was übersehen. Das zu vermeiden ist die große Kunst,
und ich nehme niemandem, der in einer Newsgroup groß das Maul aufreißt
ab, dass er das kann.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2017-02-03 20:13:24 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Rainer Weikusat
solchen Situation befinden kann, ist nicht 'Prophetie'. Man nennt das
"gesunden Menschenverstand".
Zweifellos. Allerdings hat Helmut aus der dürftigen Pressemeldung noch
einiges mehr herausgelesen. So wie jeder, der das Endergebnis des
Fußballspiels im Radio gehört hat, genau weiß, welche Fehler der Trainer
gemacht hat, so weiß Helmut genau, welche Fehler die Programmierer
gemacht haben.
Das stimmt nicht mal annähernd!
Das Endergebnis ist hier, daß der Lander mit etwa 540 km/h auf
dem Boden zerschellt ist, anstatt mit 10 km/h sanft aufzusetzen.
Daraus habe ich kein weiteres Wissen abgeleitet!

Mein Wissen stammt aus der Fehlerbeschreibung der ESA, die
sichere Fakten nennt.
Übersetzung des ESA-Textes:
===========================================================================
[...]
Durch Verschmelzen dieser fehlerhaften Information in das Navigationssytem
hinein wurde als Folge eine negative Höhe geschätzt, also unterhalb der
Marsoberfläche.
Dies wiederum entfernte frühzeitig den Fallschirm und die hintere
Außenschale und löste insgesamt ein Verhalten aus, als ob der
Mars-lander bereits gelandet wäre.
In Wirklichkeit befand sich der Mars-lander noch in einer Höhe
von +3,7 km.
.....................................................................
Der Mars-lander zerschellte mit 540 km/h auf der Marsoberfläche.
===========================================================================

Fakt: Es gab eine fehlerhafte Information.
Fakt: Deshalb wurde eine negative Höhe geschätzt.
Fakt: Deshalb wurde ein Zustand 'nach der Landung' angenommen.
Fakt: Deshalb wurde der Fallschirm abgeworfen.
Fakt: In Wirklichkeit lag dabei ein Zustand 'lange vor der Landung' vor.

Genau diese Fakten habe ich weiterführend erzählt.

Es ist erstaunlich, welcher Scheiß stattdessen über mich behauptet wird.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-04 07:41:59 UTC
Permalink
Raw Message
Post by Helmut Schellong
weiterführend erzählt
Der ist gut!
Helmut Schellong
2017-02-04 12:39:24 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
weiterführend erzählt
Der ist gut!
Das ist immer so, wenn man nicht alles haarklein definiert.

Mit 'weiterführend' meine ich, daß ich die Informationen

http://exploration.esa.int/science-e-media/img/78/ExoMars2016_DescentInfographic_20160223.jpg

für meine Erklärungen hinzugezogen hatte.
Das sind alles offizielle Fakten.

Im Übrigen habe ich recherchiert und insgesamt etwa
15 Dokumente gesichtet.

Abschrift der Grafik:
---------------------
1 Eintritt in die Atmosphäre : 0 s | 121 km | 21000 km/h
2 Hitzeschild-Nutzung : 72 s | 45 km | 19000 km/h
3 Fallschirm-Auslösung : 201 s | 11 km | 1700 km/h
4 Hitzeschild-Abstoßung, Radar EIN : 241 s | 7 km | 320 km/h
5 Abstoßung Rückenschale+Fallschirm: 322 s | 1,2 km | 240 km/h
6 Bremsdüsen-Zündung : 323 s | 1,1 km | 250 km/h
7 Bremsdüsen AUS : 352 s | 2 m | 4 km/h
8 Aufsetzen : 353 s | 0 m | 10 km/h
9 Nach der Landung :353+n s | <=0 m | 0 km/h
---------------------
So war das geplant.
In der Realität nahm Descent jedoch einen anderen Verlauf.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-05 08:54:02 UTC
Permalink
Raw Message
Post by Helmut Schellong
Im Übrigen habe ich recherchiert und insgesamt etwa
15 Dokumente gesichtet.
Sicher interessant, aber 15 ist immer noch Einige, und ich glaube,
dass "veröffentlicht" und "offiziell" zwei Paar Schuhe sind.
Post by Helmut Schellong
So war das geplant.
Diese als Fakt formulierte Behauptung eben ist ein voreiliger
Schluss, von dem nur ein Prophet wissen kann, ob er eine
Tatsache beschreibt.
Helmut Schellong
2017-02-06 13:19:36 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
So war das geplant.
Diese als Fakt formulierte Behauptung eben ist ein voreiliger
Schluss, von dem nur ein Prophet wissen kann, ob er eine
Tatsache beschreibt.
Es handelt sich weder um Prophetie (Religion) noch um Prognose,
Hellsehen oder Wahrsagung, sondern ganz einfach um Physik.

Wenn ich sage, daß eine Masse auf der Erde durch die
Fallbeschleunigung fallen wird, wenn ich sie zu einem beliebigen
Zeitpunkt in der Zukunft loslasse, dann ist das keine Prophetie,
sondern einfache Physik, die im gesamten Universum gilt.

Die oben angesprochene Planung der ESA, dargestellt durch eine
von der ESA angefertigte jpg-Grafik, gründet sich auf Physik.
Eine Physik, die seit nnn Jahren unverändert bekannt ist.

Man kennt im voraus alle Verhaltensweisen eines Objektes, weil
*alle* relevanten physikalischen Parameter bekannt sind, ohne daß
es sich dabei um Prophetie handelt.
Es handelt sich um exakte Vorausberechnungen, so, wie wenn ich sage,
daß ein weggeworfener dichter Gegenstand den Verlauf einer
Wurfparabel nehmen wird.

Wenn ich zur Planung der ESA sage: "So war das geplant.", so ist das
von vornherein ein Fakt, und nicht als Fakt (hin)formuliert.
Ich berichte also von einem Fakt.
Ein 'Schluß' ist in diesem Fall gar nicht möglich.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-06 14:30:42 UTC
Permalink
Raw Message
Wenn ich sage, ... die im gesamten Universum gilt.
Naja, beinahe. Ich war noch nicht in 'nem schwarzen Loch,
aber da soll einiges für das Universum relevante abgehen,
das für Apfel und Erde die Gesetze der klassischen Physik
alt aussehen lässt. Überhaupt Gravitation...
Aber nehmen wir mal an, die ESA weiß, wie ein Apfel auf
den Mars fällt, besser als wir alle zusammen.
Die oben angesprochene Planung der ESA, dargestellt durch eine
von der ESA angefertigte jpg-Grafik, gründet sich auf Physik.
Der nächste Satellit wird dann bestimmt besser vollständig nach
einer jpg-Grafik gebaut.
Man kennt im voraus alle Verhaltensweisen eines Objektes, weil
wenn
*alle* relevanten physikalischen Parameter bekannt sind,
Gut, dass du "relevant" erwähnst. "Alle" und "vorläufig"
schließen einander erst mal aus, auch das "einige", das du bis
hierher mehrfach verwendet hast, steht sich mit "alle"
nicht gut. "Weil *alle*... bekannt sind" unterstellt jetzt die
Behauptung in einem verallgemeinerten Zusammenhang, wodurch
sie im besonderen Zusammenhang dennoch die Behauptung bleibt,
die sie ist.
Es handelt sich um exakte Vorausberechnungen,
Es handelt sich um die arithmetische Ausführung des logischen
Schlusses also.
Wenn ich zur Planung der ESA sage: "So war das geplant.", so ist das
von vornherein ein Fakt,
Warum? Du charakterisierst ein Bild als Planung der ESA,
auf dem alle relevanten Parameter zu sehen sein sollen.
Das kann man mit Humor nehmen, der Vorläufigkeit und dem
Presserahmen zum Trotz.

Behauptung: A
Physik: A -> B
Deswegen: B

Aber A steht noch in Frage, ganz offiziell.
Ob "A -> B" als erschöpfend angeführt werden darf, auch.

Auch steht in Frage, ob dein A nicht doch ein a ist,
an dem zum A noch Einiges fehlt. Letztere könnte deine
"weiter erzählte Vorausberechnung", wenn ich so sagen darf,
als voreilig darstellen.
Ein 'Schluß' ist in diesem Fall gar nicht möglich.
Dann hättest du deine Ableitungen ja gar nicht präsentieren
müssen.
Helmut Schellong
2017-02-06 17:10:49 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Die oben angesprochene Planung der ESA, dargestellt durch eine
von der ESA angefertigte jpg-Grafik, gründet sich auf Physik.
Der nächste Satellit wird dann bestimmt besser vollständig nach
einer jpg-Grafik gebaut.
Nein, ganz gewiß nicht. Es ist praktisch gar nicht möglich, einen
Satelliten nach einer jpg-Grafik zu bauen.

Das Datei-Format muß übrigens kein jpg-Format sein.
Ich schrieb 'jpg' nur, weil die von mir gepostete ESA-Grafik
tatsächlich eine jpg-Grafik ist.
Post by G.B.
Post by Helmut Schellong
Man kennt im voraus alle Verhaltensweisen eines Objektes, weil
wenn
Post by Helmut Schellong
*alle* relevanten physikalischen Parameter bekannt sind,
'wenn' oder 'weil' sind hier beide korrekt.
Geschrieben werden kann 'weil', weil in diesem Fall tatsächlich
alle relevanten Parameter bekannt sind und bekannt waren.
Post by G.B.
Gut, dass du "relevant" erwähnst. "Alle" und "vorläufig"
schließen einander erst mal aus, auch das "einige", das du bis
hierher mehrfach verwendet hast, steht sich mit "alle"
nicht gut. "Weil *alle*... bekannt sind" unterstellt jetzt die
Behauptung in einem verallgemeinerten Zusammenhang, wodurch
sie im besonderen Zusammenhang dennoch die Behauptung bleibt,
die sie ist.
Du betreibst Wortspiele in der deutschen Sprache
und verfälschst die Semantiken beliebig, um Behauptungen
aufstellen zu können.
Ich habe hier nichts, aber auch gar nichts behauptet.
Im gesamten Thread habe ich keine Behauptungen zum Thema
aufgestellt.
Post by G.B.
Post by Helmut Schellong
Es handelt sich um exakte Vorausberechnungen,
Es handelt sich um die arithmetische Ausführung des logischen
Schlusses also.
Ich habe keine Schlüsse gezogen.
Es handelt sich um Vorausberechnungen wie sie z.B. jeder
Entwicklungsingenieur vornimmt.
Post by G.B.
Post by Helmut Schellong
Wenn ich zur Planung der ESA sage: "So war das geplant.", so ist das
von vornherein ein Fakt,
Warum? Du charakterisierst ein Bild als Planung der ESA,
Nein, ich zeige ein Bild der ESA, welches die Planung
der ESA darstellt.

http://exploration.esa.int/mars/57464-exomars-2016-schiaparelli-descent-sequence/

Das Bild stammt vom 24.Feb.2016, also von vor dem Flug zum Mars.
Folglich handelt es sich um eine offizielle Planung der ESA:
"ExoMars 2016 Schiaparelli descent sequence"
Post by G.B.
auf dem alle relevanten Parameter zu sehen sein sollen.
Nein, das sagte ich nicht.
Ich sagte, daß der ESA alle relevanten Parameter bekannt seien.
Relevante Parameter sind alle bekannten Parameter des Mars.
Mindestens einen Auszug davon kann man in Wikipedia nachlesen:
https://de.wikipedia.org/wiki/Mars_%28Planet%29

Weitere Parameter sind die Daten der Module des Schiaparelli.
Beispielsweise der Strömungswiderstand des Fallschirms
und die Schubkraft der Bremstriebwerke.
Post by G.B.
Das kann man mit Humor nehmen, der Vorläufigkeit und dem
Da ist nichts Vorläufiges enthalten.
Post by G.B.
Presserahmen zum Trotz.
Da gibt es auch keinen Presserahmen.
Post by G.B.
Behauptung: A
Physik: A -> B
Deswegen: B
Aber A steht noch in Frage, ganz offiziell.
Ob "A -> B" als erschöpfend angeführt werden darf, auch.
Auch steht in Frage, ob dein A nicht doch ein a ist,
an dem zum A noch Einiges fehlt. Letztere könnte deine
"weiter erzählte Vorausberechnung", wenn ich so sagen darf,
als voreilig darstellen.
Ich habe gar nichts vorausberechnet.
Post by G.B.
Post by Helmut Schellong
Ein 'Schluß' ist in diesem Fall gar nicht möglich.
Dann hättest du deine Ableitungen ja gar nicht präsentieren
müssen.
Ich habe keine Ableitungen getroffen, sondern nur Fakten
berichtet und eigene zusätzliche Darstellungen auf Basis
der ESA-Darstellungen angefertigt.
Zum Beispiel die aus der ESA-Grafik gewonnene Tabelle.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-07 08:05:56 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by G.B.
Gut, dass du "relevant" erwähnst. "Alle" und "vorläufig"
schließen einander erst mal aus, auch das "einige", das du bis
hierher mehrfach verwendet hast, steht sich mit "alle"
nicht gut. "Weil *alle*... bekannt sind" unterstellt jetzt die
Behauptung in einem verallgemeinerten Zusammenhang, wodurch
sie im besonderen Zusammenhang dennoch die Behauptung bleibt,
die sie ist.
Du betreibst Wortspiele in der deutschen Sprache
und verfälschst die Semantiken beliebig, um Behauptungen
aufstellen zu können.
Ich habe hier nichts, aber auch gar nichts behauptet.
Und auch keine Schlussfolgerungen? So wie in

"Wenn die ... schätzt, ...
kann nicht deswegen ...,
da ... hätte .. sein müssen."

So ein Satz schießt mit Signalworten für Schlussfolgerungen
und Behauptungen nur so um sich, ist grammatisch auch von
der entsprechenden Form.

Auf der USENET-Bühne die Bezüge und Relativierungen hinterher
dran stricken, das sind der Umgebung angemessene Versäumnisse,
klärt aber dennoch nicht abschließend, was die Untersuchung
erbringen soll. Vorausberechnet auch nicht, was gewesen ist,
wenn du diese Formulierung vorzögest, sondern spekuliert
einfach, mit dem was da ist. Das ist anregend, sollte aber
nicht für ein Urteil (sprachliche Form!) genutzt werden, in
welchem "ungerechtfertigt ... verwürfelt" angeführt wird.

Sich hinter einer lokal stimmigen Teilrechnung verschanzen
und dann denen Rechtfertigung abzusprechen, die keine Outsider
sind, das ist nicht überzeugend.
Post by Helmut Schellong
Ich habe keine Schlüsse gezogen.
Es handelt sich um Vorausberechnungen wie sie z.B. jeder
Entwicklungsingenieur vornimmt.
Korrekte Rechnungen folgen der selben Form wie logische Schlüsse,
auch wenn sie nicht danach aussehen.
Ähnlich verhält es sich mit der Euklidischen Geometrie,
die du für deine weitererzählende Verrechnung brauchst.
Post by Helmut Schellong
Das Bild stammt vom 24.Feb.2016, also von vor dem Flug zum Mars.
"also", "Folglich"...

Es gab wohl eine Planung der ESA, und da ist ein veröffentlichtes
Bild, das was illustriert, das mit dem Plan in Zusammenhang
gebracht werden kann.
Post by Helmut Schellong
Ich habe keine Ableitungen getroffen, sondern nur Fakten
berichtet und eigene zusätzliche Darstellungen auf Basis
der ESA-Darstellungen angefertigt.
Zum Beispiel die aus der ESA-Grafik gewonnene Tabelle.
"Eigene zusätzliche Darstellungen ... angefertigt".
Dazu gehört eine "Darstellung", in der Worte wie "deswegen",
"da" u.a.m. vorkommen, und die in "ungerechtfertigt" gipfelt.

Die angeführten Daten bleiben vorläufig, du bleibst Outsider,
und die Rechnung ist ebenso vorläufig wie die Datenlage.
Von dieser Vorläufigkeit und von außen auf das zu kommen,
was da innen abschließen hätte anders sein müssen, ist urteilende
Spekulation.

Vorläufigkeit, Unvollständigkeit -> Spekulation

Man kann diese spekulativen Redeweisen auch als solche kennzeichnen.
Helmut Schellong
2017-02-07 11:38:52 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Ich habe hier nichts, aber auch gar nichts behauptet.
Und auch keine Schlussfolgerungen? So wie in
"Wenn die ... schätzt, ...
kann nicht deswegen ...,
da ... hätte .. sein müssen."
So ein Satz schießt mit Signalworten für Schlussfolgerungen
und Behauptungen nur so um sich, ist grammatisch auch von
der entsprechenden Form.
Leser meiner Postings müssen im Thread alle meine Postings
und auch den Links folgen und die jeweiligen Inhalte lesen.
Erst dann wird sichtbar, daß ich eben keine Behauptungen
aufstellte, sondern daß die ESA Fakten mitteilte, die ich
dann mit anderen Worten und in Verschmelzung weitergab.

Die mir angedichteten Schlußfolgerungen hatte die ESA bereits
selbst gezogen, in der Gesamtheit ihrer Informationen.
Ich hätte auch ohne das Wort 'folglich' formulieren können.

Beispiel:
Die ESA schrieb, daß das Navigationssystem eine negative Höhe
aufgrund einer fehlerhaften Information schätzte.
Deswegen wurde der Fallschirm zu früh abgeworfen.
Die ESA schrieb, daß dabei die Höhe 3,7 km betrug.

Es ist nicht meine Schlußfolgerung, wenn ich nun sage, daß die
korrekte Höhenangabe von 3,7 km, gemessen vom Doppler-Radar,
ignoriert wurde, denn die ESA hatte das bereits selbst gesagt,
nur nicht unter Verwendung des Wortes 'ignoriert'.

Zwei verschiedene Höhen zur gleichen Zeit kann kein Objekt
haben, im Universum, wenn die Höhe jeweils am selben Punkt
des Objektes abgenommen wird.
Eine der beiden Höhen muß also falsch sein.
Das war jetzt eine Schlußfolgerung.
Aber keine, die (als eigenmächtig) kritisiert werden kann.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-07 12:51:06 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by G.B.
Post by Helmut Schellong
Ich habe hier nichts, aber auch gar nichts behauptet.
Und auch keine Schlussfolgerungen? So wie in
"Wenn die ... schätzt, ...
kann nicht deswegen ...,
da ... hätte .. sein müssen."
So ein Satz schießt mit Signalworten für Schlussfolgerungen
und Behauptungen nur so um sich, ist grammatisch auch von
der entsprechenden Form.
Leser meiner Postings müssen im Thread alle meine Postings
und auch den Links folgen und die jeweiligen Inhalte lesen.
Erst dann wird sichtbar, daß ich eben keine Behauptungen
aufstellte, sondern daß die ESA Fakten mitteilte, die ich
dann mit anderen Worten und in Verschmelzung weitergab.
Eine klassische Figur, die aus einem tiefen rhetorischen Loch
hallt. Eine Behauptung bleibt eine Behauptung und setzt sich
um so mehr dem Verdacht rhetorischen Geschnörkels aus, wenn sie
durch Fingerzeigen auf "Zusammenhänge" von dieser sichtbaren
Tatsache abzulenken versucht.

Das oben angeführte Zitat zeugt in ganzer Länge und in
dem vor Dir erbetenen Kontext vom Gegenteil.
Post by Helmut Schellong
Die mir angedichteten Schlußfolgerungen hatte die ESA bereits
selbst gezogen, in der Gesamtheit ihrer Informationen.
Da hätte, wenn die Gesamtheit (Allquantor eingebaut)
und der Schluss doch da sind, ein link gereicht. Im thread
schien dieses Gesamt mit etwas "ergänzt" werden zu müssen,
mit Wenn-Dann-Sätzen und mit "ungerechtfertig", wo die
Untersuchung noch aussteht.
Post by Helmut Schellong
Zwei verschiedene Höhen zur gleichen Zeit kann kein Objekt
haben, im Universum, wenn die Höhe jeweils am selben Punkt
des Objektes abgenommen wird.
Eine der beiden Höhen muß also falsch sein.
Das war jetzt eine Schlußfolgerung.
Aber keine, die (als eigenmächtig) kritisiert werden kann.
Genau um solch eine Schlussfolgerung geht es.
Mal aus eingeschränkten, mal als Gesamtheit qualifizierten
Voraussetzungen, bei beliebiger Hinzunahme passend Widerspruch
erzeugender Voraussetzung in geeigneter Menge: betrachten wir
mal zwei, nicht drei, nicht null Orte, und in der Senkrechten,
da entsteht wohlfeil ein Schluss und der bekommt ein Urteil
drangehängt. Ob er stimmt oder allein stehen kann oder nicht,
wird sich weisen. Deshalb wäre das alles als interessante,
deutende Vermutung besser formuliert und würde nicht so gut
taugen, einem Sündenbock hellseherisch formulierte Vorwürfe
zu machen.
Helmut Schellong
2017-02-07 14:43:17 UTC
Permalink
Raw Message
Post by G.B.
Das oben angeführte Zitat zeugt in ganzer Länge und in
dem vor Dir erbetenen Kontext vom Gegenteil.
Post by Helmut Schellong
Die mir angedichteten Schlußfolgerungen hatte die ESA bereits
selbst gezogen, in der Gesamtheit ihrer Informationen.
Da hätte, wenn die Gesamtheit (Allquantor eingebaut)
und der Schluss doch da sind, ein link gereicht.
Der Sinn von Postings ist es auch, den Lesern zu ersparen, z.B.
die Recherche von etwa 15 Dokumenten selbst durchführen zu
müssen, sondern nebst Links als Service auch zusammenzufassen.
Ein Link hätte nicht gereicht; ich habe 4-5 Links gepostet.
Post by G.B.
Im thread schien dieses Gesamt mit etwas "ergänzt" werden zu müssen,
mit Wenn-Dann-Sätzen und mit "ungerechtfertig", wo die
Untersuchung noch aussteht.
Daß das Auslösen des Fallschirms ungerechtfertigt war, hat ebenfalls
die ESA als Fakt mitgeteilt, nur eben nicht unter Verwendung
des Wortes 'ungerechtfertigt'.
Post by G.B.
Post by Helmut Schellong
Zwei verschiedene Höhen zur gleichen Zeit kann kein Objekt
haben, im Universum, wenn die Höhe jeweils am selben Punkt
[...]
Post by G.B.
Genau um solch eine Schlussfolgerung geht es.
[...]
Post by G.B.
wird sich weisen. Deshalb wäre das alles als interessante,
deutende Vermutung besser formuliert und würde nicht so gut
taugen, einem Sündenbock hellseherisch formulierte Vorwürfe
zu machen.
Ich habe in dieser Sache bisher der ESA nichts vorgeworfen, sondern
nur Vorwürfe erzählt, die die ESA sich selbst gemacht hat.

Vorwürfe an die Adresse der ESA haben bisher nur Medien erhoben,
und in zurückhaltender Weise Harald Lesch, soweit ich
Vorwürfe hierzu kenne.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-02-07 18:38:52 UTC
Permalink
Raw Message
Post by Helmut Schellong
Leser meiner Postings müssen im Thread alle meine Postings
und auch den Links folgen und die jeweiligen Inhalte lesen.
Das ist ein starkes Argument dafür, deine Postings nicht zu lesen :-)
Helmut Schellong
2017-02-08 13:47:42 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Leser meiner Postings müssen im Thread alle meine Postings
und auch den Links folgen und die jeweiligen Inhalte lesen.
Das ist ein starkes Argument dafür, deine Postings nicht zu lesen :-)
Aber die Leute sind doch sehr neugierig:

Gestern im heise-Forum gelesen:
==========================================================================
Im Statement der ESA (Siehe [1]) heißt es:

As Schiaparelli descended under its parachute, its radar Doppler
altimeter functioned correctly and the measurements were included in the
guidance, navigation and control system. However, saturation – maximum
measurement – of the Inertial Measurement Unit (IMU) had occurred shortly
after the parachute deployment. The IMU measures the rotation rates of the
vehicle. Its output was generally as predicted except for this event, which
persisted for about one second – longer than would be expected.

Im diesem Absatz des Statements erfährt man von der Existenz eines
(wohlgemerkt) funktionierenden Messgeräts, daß dort als "radar Doppler
altimeter" (Infos zur Technik siehe [2]) bezeichnet wird. Es wird nicht mal
angedeutet, daß auch dieses Messgerät im fraglichen Zeitraum falsche Daten
geliefert haben könnte. was den Schluß zuläßt, daß von dessen
Funktionsfähigkeit und Korrektheit der gelieferten Daten zu jedem Zeitpunkt
des rasanten Abstiegs ausgegangen werden kann. Allein diese Daten hätten dem
"guidance, navigation and control system" (im Weiteren von mir als "GNCS"
bezeichnet) verraten können, daß der Abstieg keineswegs bereits beendet war.

Dummerweise hat nun das "GNCS" die (fehlerhaften) Daten des "IMU", die nach
dessen Fehlfunktion empfangen wurden, über die Daten des "radar Doppler
altimeter" gestellt. Weiterhin hätte das "GNCS" doch bloß, während des
fraglichen Zeitraums von lediglich einer Sekunde, die bis dahin gesammelten
(korrekten) Daten extrapolieren müssen (was es vermutlich auch getan hat —
oder etwa nicht?) um zweifelsfrei feststellen zu können, das die Daten der
"IMU" nicht korrekt sein können. Es hätte genügt, die Daten der "IMU" auf den
extrapolierten Wert quasi "umzubiegen", um eine mögliche Kollision zu
verhindern. Schließlich hat die "IMU" lediglich Rotationsdaten des
Landemoduls geliefert, nur eben nicht fehlerfrei (siehe Zitat ganz oben, die
letzten beiden Sätze).
Jedes moderne Smartphone verfügt über Gravitationsfeld-Sensoren — das
ESA-Landemodul etwa nicht? Dessen Daten hätten doch genutzt werden können, um
die Rotationsdaten der "IMU" ergänzen und ggf. korrigieren zu können.

Im nächsten absatz wird dann zugegeben, daß die mutmaßlich weiterhin
korrekten Daten des "radar Doppler altimeter" vom "GNCS" komplett ignoriert
wurden:

When merged into the navigation system, the erroneous information
generated an estimated altitude that was negative – that is, below ground
level. This in turn successively triggered a premature release of the
parachute and the backshell, a brief firing of the braking thrusters and
finally activation of the on-ground systems as if Schiaparelli had already
landed. In reality, the vehicle was still at an altitude of around 3.7 km.

Weiter heißt es dann:

This behaviour has been clearly reproduced in computer simulations of
the control system’s response to the erroneous information.

Da drängen sich mir direkt zwei Fragen auf:
Ja zum Kuckuck, hat man das denn vorher nicht getestet? Warum haben das die
Verantwortlichen nicht simuliert, bevor die Mission gestartet wurde?

Tja, dumm gelaufen! Aber David Parker ("ESA’s Director of Human Spaceflight
and Robotic Exploration") verkündet dann ganz optimistisch:

But we will have learned much from Schiaparelli that will directly
contribute to the second ExoMars mission being developed with our
international partners for launch in 2020.

Aha! Offenbar wurde hier das Prinzip "trial and error" angewendet. Versuch
macht kluch!
Das war aber — mit Verlaub — ein ziemlich kostspieliger Versuch.
==========================================================================

Die Sichtweise/Analyse des Posters ist weitgehend identisch mit der meinen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-02-09 12:30:46 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Thomas Koenig
Post by Helmut Schellong
Leser meiner Postings müssen im Thread alle meine Postings
und auch den Links folgen und die jeweiligen Inhalte lesen.
Das ist ein starkes Argument dafür, deine Postings nicht zu lesen :-)
==========================================================================
[...]
Im nächsten absatz wird dann zugegeben, daß die mutmaßlich weiterhin
korrekten Daten des "radar Doppler altimeter" vom "GNCS" komplett ignoriert
[...]
Post by Helmut Schellong
==========================================================================
Die Sichtweise/Analyse des Posters ist weitgehend identisch mit der meinen.
Ich füge noch hinzu:
========================================================================
As Schiaparelli descended under its parachute, its
radar Doppler altimeter functioned correctly and the measurements
were included in the guidance, navigation and control system.
========================================================================
Der Text erklärt ausdrücklich, daß das Radar korrekt funktionierte,
während Schiaparelli unter seinem Fallschirm absank.
Die Funktion als 'mutmaßlich' hinzustellen ist offenbar gar nicht nötig.

Das Radar wurde bei etwa 7 km Höhe eingeschaltet, und bei 1,2 km
sollte die hintere Schale mit dem Fallschirm dran abgeworfen werden.
Dies geschah allerdings zu früh, bereits bei 3,7 km.
Diese 3,7 km Höhe wurde offenbar vom Radar gemessen - von was sonst?
...
Man erkennt, wie /grausam/ der Softwarefehler doch ist.
Dazu paßt der Ausspruch: "Ich könnt' mich bepissen!".

Die 3 Antennen des Radar-Systems:
Loading Image...
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-02-04 07:39:23 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Zu konstatieren das "weil der Computer der Ansicht war
Es wurde konstatiert, wie der Computer zu dieser Ansicht
gekommen sein müsse, und Helmut hat sich beim Konstatieren selbst
als "Outsider" bekannt. Mit "weil der Computer der Ansicht war",
wäre die Tatsache enthymematisch untergeschoben, die eben
erst ergründet werden soll...

Heraus windet sich ein logischer Schluss, für welchen einige
geeignete, als faktisch deklarierte Daten als Prämissen
zusammen getragen wurden... Beste politische Rede, wenn dann
"Fakten" behauptet werden, statt "Hypothesen" oder "Spekulationen"
angeboten, aus denen selbst zu schlussfolgern dem gesunden
Menschenverstand des Zuhörers gestattet bliebe.

Soweit ich blicke, kann man von Vollständigkeit oder Zutreffen
der Behauptungen über, auch von hinreichender Kenntnis (unter
Outsidern) des Aufbaus und der Arbeitsweise der Weltraum-Apparate
noch nicht ausgehen.
Rainer Weikusat
2017-02-05 20:39:10 UTC
Permalink
Raw Message
Post by G.B.
Post by Rainer Weikusat
Zu konstatieren das "weil der Computer der Ansicht war
| der Flugapperat befeaende sich mehrere Kilometer unter der
| Marsoberflaeche, loeste er den Abwurf des Fallschirms aus"

[eine im realen Universum unmoeglich Anfangssituation hat]
Post by G.B.
Es wurde konstatiert, wie der Computer zu dieser Ansicht
gekommen sein müsse, und Helmut hat sich beim Konstatieren selbst
als "Outsider" bekannt. Mit "weil der Computer der Ansicht war",
wäre die Tatsache enthymematisch untergeschoben, die eben
erst ergründet werden soll...
,----
| Als Konsequenz habe der Lander einen negativen Wert für die geschätzte
| Höhe ermittelt. Schiaparelli habe sich dann so verhalten, als sei er
| bereits gelandet, was angesichts einer tatsächlichen Höhe von 3,7
| Kilometern zum Absturz geführt habe.
|
| Schiaparelli habe also viel zu früh den Fallschirm und einen der
| Schutzschilde gelöst. Dieses fehlerhafte Verhalten sei im eigenen
| Simulator exakt so reproduziert worden, teilten die Ingenieure nun mit.
`----

https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html

Wenn man das mal als gegeben annimmt (und bessere Informationen hast Du
augenscheinlich keine) haette eine Sinnhaftigkeitspruefung der
ermittelten Hoehe dieses Problem verhindern koennen. Dh
unueberraschenderweise liegt hier in algorithmisches Defizit vor und
dadurch, den mangelhaften Algorithmus in anderen Sprache auszudruecken,
haette sich hier nichts geaendert.

Das 'Ariane 5'-Equivalent waere: Das Laufzeitsystem loeste nun eine
Exception aus, die die CPU anhielt, worauf das Landegeraet ebenfalls wie
ein Stein zu Boden fiel.
Peter J. Holzer
2017-02-05 21:22:14 UTC
Permalink
Raw Message
Post by Rainer Weikusat
,----
| Als Konsequenz habe der Lander einen negativen Wert für die geschätzte
| Höhe ermittelt. Schiaparelli habe sich dann so verhalten, als sei er
| bereits gelandet, was angesichts einer tatsächlichen Höhe von 3,7
| Kilometern zum Absturz geführt habe.
|
| Schiaparelli habe also viel zu früh den Fallschirm und einen der
| Schutzschilde gelöst. Dieses fehlerhafte Verhalten sei im eigenen
| Simulator exakt so reproduziert worden, teilten die Ingenieure nun mit.
`----
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
Wenn man das mal als gegeben annimmt (und bessere Informationen hast Du
augenscheinlich keine) haette eine Sinnhaftigkeitspruefung der
ermittelten Hoehe dieses Problem verhindern koennen. Dh
unueberraschenderweise liegt hier in algorithmisches Defizit vor und
dadurch, den mangelhaften Algorithmus in anderen Sprache auszudruecken,
haette sich hier nichts geaendert.
Das 'Ariane 5'-Equivalent waere: Das Laufzeitsystem loeste nun eine
Exception aus, die die CPU anhielt, worauf das Landegeraet ebenfalls wie
ein Stein zu Boden fiel.
1) Dinge, die an Fallschirmen hängen, fallen eher selten wie ein Stein
zu Boden (höchstens wie ein Stein an einem Fallschirm ;-))

2) Eine Exception hält nicht die CPU an. Sie überträgt den Kontrollfluss
an eine Fehlerbehandlungsroutine. Wenn gar nichts anderes geht, wird
der Prozess abgebrochen und neu gestartet.

Wenn eine Sonde in 3.7 km Höhe am Fallschirm baumelt, ist ein Neustart
eines fehlerhaften Prozesses oder sogar des ganzen Systems
wahrscheinlich überlebbar - ein versehentliches Abwerfen des Fallschirms
aber nicht. Eine Exception (egal, ob explizit programmiert oder durch
die Laufzeitumgebung ausgelöst) hätte also möglicherweise den Lander
retten können.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
G.B.
2017-02-06 08:39:18 UTC
Permalink
Raw Message
Post by Helmut Schellong
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
Wenn man das mal als gegeben annimmt (und bessere Informationen hast Du
augenscheinlich keine) haette
hätte
Post by Helmut Schellong
verhindern koennen.
hätte können. Und nochmal die Fahradkette.

Die "Sinnhaftigkeitsprüfung" und ist zwar ein großes Wort, das die
Arbeit der Leute aus der Ferne kommentiert, aber noch erwähnt
die obige Journalquelle ein "vorläufiges Endergebnis"
("very preliminary conclusion" im dort verlinkten Original).
Sowohl Überschriften wie ESA-Details bleiben im Bereich "einige",
woraus sich in bekannter Weise durch Weglassung des Quantors eine
Überschrift von journalistischer Bestimmtheit ableiten lässt.
Post by Helmut Schellong
Dh
Tut es das?
Post by Helmut Schellong
unueberraschenderweise liegt hier in algorithmisches Defizit vor
und dann werden in einige "Details" von Outsidern mit rhetorischer Verve
die endgültigen Schlussfolgerungen hinein interpretiert...

Wir wäre es mit der Betrachtung von Vermutung darüber, wann Flughöhen
fast immer geschätzt werden? Ich wüsste nicht, wie ein Barometer auf
dem Mars funktioniert, oder mit welchen Radarstationen auf dem
Mars ein Lander eine Höhenmessung abgleichen könnte. Hatte der einen
Laser vom Schreiner mit, der auf drei Kilometer und Marsoberfläche
zuverlässig misst, statt schätzt?
Oder: Was ist eine überlastete Berechnung (Heise)? Was ein überlasteter
Sensor genau (ebd.)?
Flughöhen sind vielleicht nicht wie C-Programme, deren Interpretation
bei einer vollständig bekannten Implementierung und funktionell
einwandfreier Hardware im Hinblick auf Variablenwerte ziemlich gut
möglich ist, wenn man hinreichend viel tracing mitlaufen hatte.

Vielleicht hätte der Trainer wirklich die 12 vom Platz nehmen
sollen. Aber da, als der Trainer das selber sagte, wurde überhört,
dass seine fußballfachlichen Überlegungen komplexer waren, als
der Fernsehzuschauer sich hätte träumen lassen (wollen). Vielleicht
auch nicht.
Rainer Weikusat
2017-02-06 15:50:20 UTC
Permalink
Raw Message
Post by Helmut Schellong
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
Wenn man das mal als gegeben annimmt (und bessere Informationen hast Du
augenscheinlich keine) haette
[...]

Diese 'Diskussion' unter konstanter Weglassung des
Diskussionsgegenstands ist mir zu unsinnig.
G.B.
2017-02-07 06:59:03 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Post by Helmut Schellong
https://www.heise.de/newsticker/meldung/Absturz-des-ExoMars-Landers-Schiaparelli-ESA-findet-Softwarefehler-3502663.html
Wenn man das mal als gegeben annimmt (und bessere Informationen hast Du
augenscheinlich keine) haette
[...]
Diese 'Diskussion' unter konstanter Weglassung des
Diskussionsgegenstands ist mir zu unsinnig.
Durch Weglassung konnte das Ganze ja erst seinen Anfang machen.
Rainer Weikusat
2017-02-02 21:03:42 UTC
Permalink
Raw Message
Helmut Schellong <***@schellong.biz> writes:

[...]
Post by Helmut Schellong
Die Information, daß eine negative Höhe geschätzt wurde, wegen
einer zuvor aufgetretenen Sättigung bei Rotationsdaten.
Die Information, daß wegen der Höhenschätzung der Zustand 9
angenommen wurde und deswegen der Fallschirm abgeworfen wurde.
Hierzu waere auch noch anzumerken, dass "eine negative Hoehe" jedenfalls
Quatsch ist (U-Boot-Steuersoftware wiederverwendet?): Hier hat bei einer
Berechnung ein Bereichsunterlauf stattgefunden, der deswegen nicht als
solcher erschien, weil der Hoehenwert vorzeichenbehaftet repraesentiert
wurde und jeder repraesntierbare Wert a priori als gueltig angenommen
wurde. Das haette vorzeichenlos sein sollen und der Unterlauf haette
als solcher erkannt werden muessen.
Helmut Schellong
2017-02-02 22:43:41 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Post by Helmut Schellong
Die Information, daß eine negative Höhe geschätzt wurde, wegen
einer zuvor aufgetretenen Sättigung bei Rotationsdaten.
Die Information, daß wegen der Höhenschätzung der Zustand 9
angenommen wurde und deswegen der Fallschirm abgeworfen wurde.
Hierzu waere auch noch anzumerken, dass "eine negative Hoehe" jedenfalls
Quatsch ist (U-Boot-Steuersoftware wiederverwendet?): Hier hat bei einer
Berechnung ein Bereichsunterlauf stattgefunden, der deswegen nicht als
solcher erschien, weil der Hoehenwert vorzeichenbehaftet repraesentiert
wurde und jeder repraesntierbare Wert a priori als gueltig angenommen
wurde. Das haette vorzeichenlos sein sollen und der Unterlauf haette
als solcher erkannt werden muessen.
Ja, außer einem Eintrag in den Log hätte da nichts passieren dürfen.
Es gab ja einen weiteren Vorgang, der überraschend 2 statt 1 Minute
dauerte.

Es zieht mir die Schuhe aus, daß da während des Landezustands 4
übergangslos und unplausibel, die Zustände 5,6,7,8 auslassend,
zum Zustand 9 gesprungen wurde und darin Aktionen des Zustands 5
'nachgeholt' wurden, jedoch nicht die von 6,7,8.
Das ist völlig /kaputt/ und verrückt.
Da kann man kreuz und quer prüfen - alles ist unplausibel.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-02-03 11:43:18 UTC
Permalink
Raw Message
On 02/02/2017 22:03, Rainer Weikusat wrote:
[...]
Post by Rainer Weikusat
wurde. Das haette vorzeichenlos sein sollen und der Unterlauf haette
als solcher erkannt werden muessen.
Allerdings: ich habe Meßwerte bisher pauschal signed definiert.
Z.B. typedef long MESW;

Was man wo mit/wegen negativen Werten macht, ist eine andere Frage.
Niemals würde ich überall den gesamten Wertebereich pauschal
als gültig ansehen.

Bei Extrapolation z.B. kann ein negativer Wert entstehen.
Der darf dann aber |x| nur gering sein.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-01-29 19:31:06 UTC
Permalink
Raw Message
Post by Helmut Schellong
Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
wenn notwendige Überlegungen beim Programmieren unterlassen
werden, und ähnliche Vorkommnisse.
Mit sicher(en) Sprachen kann man die Häufigkeit von Fehlern
reduzieren, wenn man sie richtig anwendet. Das kann von ~ 5 Fehler
pro 1000 LOC (typischer Wert für C) bis zu 0.05 Fehler pro 1000
LOC (stark formale Systeme) gehen. Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
Post by Helmut Schellong
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
So toll war das nicht. Jeder von zwei unabhängigen Fehlern hätte
fast die Mission gekostet:

http://www.doneyles.com/LM/Tales.html
Rainer Weikusat
2017-01-29 20:55:27 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
wenn notwendige Überlegungen beim Programmieren unterlassen
werden, und ähnliche Vorkommnisse.
Mit sicher(en) Sprachen kann man die Häufigkeit von Fehlern
reduzieren, wenn man sie richtig anwendet. Das kann von ~ 5 Fehler
pro 1000 LOC (typischer Wert für C) bis zu 0.05 Fehler pro 1000
LOC (stark formale Systeme) gehen.
Daraus, das eine Analyse irgendwelcher in C geschriebener Software einen
Durchschnitt von 5 Fehlern pro 1000 LOC ergab (was ich als technische
Bedeutung dieser Aussage annehme) folgt genau nichts ueber nicht
analysierte Software, die ebenfalls in C geschrieben wurde oder noch
geschrieben werden wird. Insbesondere deswegen nicht weil die Analyse
selber nicht nur nicht notwendigerweise korrekt ist sondern sogar
wahrscheinlich falsch: Haette jemand den Stein der Weisen fuer
identifizieren von Fehlern in Code gefunden wuerde sich eine solche
Analyse mangels Fehlern eruebrigen.
Hermann Riemann
2017-01-30 12:05:03 UTC
Permalink
Raw Message
Post by Thomas Koenig
Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
Doch. ungetestetes Beispiel:
int main(){return 0;}

Hermann
der vermutet, dass auch main(){} fehlerfei ist.
--
http://www.hermann-riemann.de
Stefan Reuther
2017-01-30 16:44:03 UTC
Permalink
Raw Message
Post by Hermann Riemann
Post by Thomas Koenig
Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
int main(){return 0;}
Das mag aus Sicht des C-Standards korrekt sein. Aus Sicht des Praktikers
sind davor schon ein paar hundert bis tausend Zeilen Assembler gelaufen,
die natürlich Fehler haben können.

Ich erinnere nur mal an das beliebte "runtime error 200" von der
Konkurrenz. Das war ein Fehler in deren Laufzeitbibliothek.


Stefan
Helmut Schellong
2017-01-30 18:25:19 UTC
Permalink
Raw Message
Post by Stefan Reuther
Post by Hermann Riemann
Post by Thomas Koenig
Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
int main(){return 0;}
Das mag aus Sicht des C-Standards korrekt sein. Aus Sicht des Praktikers
sind davor schon ein paar hundert bis tausend Zeilen Assembler gelaufen,
die natürlich Fehler haben können.
Es wurde nicht definiert, ob Quellcode oder übersetzter
Code gemeint war - wie praktisch.

Außerdem wurde nicht definiert, ob es sich um ein
Hosted Env oder Freestanding Env handelt.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Hermann Riemann
2017-01-31 05:51:39 UTC
Permalink
Raw Message
Post by Stefan Reuther
Post by Hermann Riemann
int main(){return 0;}
Das mag aus Sicht des C-Standards korrekt sein. Aus Sicht des Praktikers
sind davor schon ein paar hundert bis tausend Zeilen Assembler gelaufen,
die natürlich Fehler haben können.
Der compiler etc ist selber schon ein anders Programm.
Welches z.B. nicht mit dem hello world Programm umgehen konnte.

Das habe ich bei microsoft visual C erlebt ( Vermutlich Version 4)
Im flat mode übersetzt, und der Binder (linker) hat sich geweigert.

Danach habe ich windows nicht mehr zur Entwicklung eingesetzt
und bin nach Linux gewechselt,
einem System wo C und Betriebssystem zusammenpassten.

Hermann
der auch die Erfahrung gemacht hat dass man bei K&R C
beim hello world programm die #include Anweisung
weglassen kann.
Und es dann genauso abläuft, wenn das Laufzeitsystem mitspielt.
--
http://www.hermann-riemann.de
Peter J. Holzer
2017-01-31 07:03:22 UTC
Permalink
Raw Message
Post by Hermann Riemann
Hermann
der auch die Erfahrung gemacht hat dass man bei K&R C
beim hello world programm die #include Anweisung
weglassen kann.
Und es dann genauso abläuft, wenn das Laufzeitsystem mitspielt.
Das dürfte auch bei den meisten standardkonformen Compilern
funktionieren. Garantiert ist es nicht, weil »int printf(char *)«
und »int printf(const char *, ...)« unterschiedliche Aufrufkonventionen
haben könnten. Gcc warnt daher »incompatible implicit declaration of
built-in function ‘printf’«. Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2017-01-31 21:16:21 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?
Ich interessiere mich jedenfalls nicht dafür, diese Frage
beantworten zu können.
Was bringt es, einen entsprechenden Compiler zu kennen?
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-02-01 19:49:35 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?
Ich interessiere mich jedenfalls nicht dafür, diese Frage
beantworten zu können.
Was bringt es, einen entsprechenden Compiler zu kennen?
Falls du mal was auf einer entsprechenden Architektur programmieren
möchtest?

ARM-THUMB ist ein Beispiel (siehe anderer Post), NVPTX ein anderes.
Wenn du dich für beides nicht interessierst, dann brauchst du
das ja nicht verwenden.

Ach ja, und dann gibt es da noch die (von der C-Norm
vorgeschriebene) Typumwandlung von float nach double, wenn man
eine variadische Funktion hat. Deshalb heißt es ja auch %f bei
printf für float _und_ für double. Daher die nette Asymmetrie
zwischen printf und scanf mit %f und %lf...
Helmut Schellong
2017-02-01 21:15:46 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Helmut Schellong
Post by Peter J. Holzer
Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?
Ich interessiere mich jedenfalls nicht dafür, diese Frage
beantworten zu können.
Was bringt es, einen entsprechenden Compiler zu kennen?
Falls du mal was auf einer entsprechenden Architektur programmieren
möchtest?
ARM-THUMB ist ein Beispiel (siehe anderer Post), NVPTX ein anderes.
Wenn du dich für beides nicht interessierst, dann brauchst du
das ja nicht verwenden.
Ich würde stets einfach die vorgeschriebene Syntax verwenden.
Post by Thomas Koenig
Ach ja, und dann gibt es da noch die (von der C-Norm
vorgeschriebene) Typumwandlung von float nach double, wenn man
eine variadische Funktion hat. Deshalb heißt es ja auch %f bei
printf für float _und_ für double. Daher die nette Asymmetrie
zwischen printf und scanf mit %f und %lf...
Ich kenne das seit ... 30 Jahren?
Allerdings würde ich bei printf %lf verwenden, damit Symmetrie
gegeben ist.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Thomas Koenig
2017-02-01 19:38:53 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Das dürfte auch bei den meisten standardkonformen Compilern
funktionieren. Garantiert ist es nicht, weil »int printf(char *)«
und »int printf(const char *, ...)« unterschiedliche Aufrufkonventionen
haben könnten. Gcc warnt daher »incompatible implicit declaration of
built-in function ‘printf’«. Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?
Auf vernünftigen Plattformen gibt es eine ABI, in der das definiert ist.
Der Compiler implementiert dann einfach die ABI.

Und ja, da gibt es Unterschiede. Beispiel aus dem "ARM-THUMB
Procedure Call Standard". Wer da Floating-Point-Zahlen übergibt
und vergisst, die Funktion vorher als variadic zu deklarieren,
der hat einfach gelitten.

# 4.4.1 Variable number of parameters (variadic routines) The list of
# machine parameter values is converted to integer machine words as if
# by storing each value in turn into consecutive memory words. These
# integer parameter words are passed to a variadic routine as if by:
#
# o Loading the first 4 words into integer registers a1-a4 (lowest
# addressed into a1). If there are fewer than 4
# words, they are loaded into a1-a3, a1-a2, or a1 only.
#
# o Pushing remaining words onto the stack in reverse order (so the first
# remaining parameter word is at
# VAL(SP), the second at VAL(SP)+4, and so on).
#
# Note
# Consequently, a floating-point value can be passed in integer
# registers, or can be split between an
# integer register and memory.
#
# 4.4.2 Fixed number of parameters
#
# Machine-level parameter values are passed to a non-variadic routine
# as if:
#
# o The first N floating-point values are removed from the parameter
# list and assigned to floating-point argument registers of the
# appropriate precision. The number N and the details of the
# assignment depend on the selected floating-point architecture
# (see section 4.6, The FPA procedure call standard and 4.7,
# The VFP (scalar mode) procedure call standard).
#
# o The first 4 integer values are removed from the parameter list
# and assigned to integer registers a1-a4. Fewer than 4 integer
# parameter values there are assigned to a1-a3, a1-a2, or a1 only.
#
# o Remaining values are pushed onto the stack in reverse order.
#
# Note
#
# Consequently, a machine-level floating-point value is passed
# in a floating-point register or in memory, never in integer
# registers. (But, a source-level floating-point field does not
# always map to a machine- level floating-point value. Consider,
# for example, a floating-point field in an inhomogeneous structure.)
Peter J. Holzer
2017-02-03 17:28:17 UTC
Permalink
Raw Message
Post by Thomas Koenig
Post by Peter J. Holzer
Das dürfte auch bei den meisten standardkonformen Compilern
funktionieren. Garantiert ist es nicht, weil »int printf(char *)«
und »int printf(const char *, ...)« unterschiedliche Aufrufkonventionen
haben könnten. Gcc warnt daher »incompatible implicit declaration of
built-in function ‘printf’«. Aber in der Praxis wird das ABI für
Funktionen mit fixer und variabler Anzahl Parameter wohl zumindest für
die fixen Parameter gleich sein. Kennt wer einen Compiler, wo das nicht
der Fall ist?
Auf vernünftigen Plattformen gibt es eine ABI, in der das definiert ist.
Klar.
Post by Thomas Koenig
Der Compiler implementiert dann einfach die ABI.
Henne-Ei-Problem: Implementiert der Compiler das ABI oder dokumentiert
das ABI das Verhalten des (ersten) Compilers? Zumindest seit der
RISC-Welle in den 80er-Jahren gehe ich davon aus, dass das ABI einer
neuen Plattform nicht am Whiteboard entworfen wird, sondern das Ergebnis
eines Optimierungsprozesses ist - dafür braucht man aber lauffähigen
Code und dafür wieder einen Compiler. Und davor hat wohl sowieso jeder
Compilerschreiber gemacht, was ihm sinnvoll erschienen ist.
Post by Thomas Koenig
Und ja, da gibt es Unterschiede. Beispiel aus dem "ARM-THUMB
Procedure Call Standard". Wer da Floating-Point-Zahlen übergibt
und vergisst, die Funktion vorher als variadic zu deklarieren,
der hat einfach gelitten.
# 4.4.1 Variable number of parameters (variadic routines) The list of
# machine parameter values is converted to integer machine words as if
# by storing each value in turn into consecutive memory words. These
[...]
Post by Thomas Koenig
# 4.4.2 Fixed number of parameters
#
# Machine-level parameter values are passed to a non-variadic routine
#
# o The first N floating-point values are removed from the parameter
# list and assigned to floating-point argument registers of the
# appropriate precision. The number N and the details of the
[...]
Post by Thomas Koenig
# assignment depend on the selected floating-point architecture
# (see section 4.6, The FPA procedure call standard and 4.7,
# The VFP (scalar mode) procedure call standard).
Yup. Machen viele RISC-Architekturen so.

Allerdings geht aus dieser Beschreibung für mich nicht eindeutig hervor,
wie die fixen Parameter einer variadischen Funktion behandelt werden:
Wird bei einem Aufruf der Funktion »double f(double a, ...)« der erste
Parameter in einem FP-Register oder in einem Integer-Register übergeben?

Spannenderweise habe ich aber gerade ein noch viel besseres Beispiel
gefunden. x86_64 (auf Linux) übergibt bei variadischen Funktionen die
Anzahl der Parameter, die in FP-Registern übergeben wurden, in %eax.
Wenn der Compiler beim Aufruf nicht weiß, dass die Funktion variadisch
ist, steht in %eax ziemlich sicher Unsinn und die Funktion wird nicht
funktionieren.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Hermann Riemann
2017-02-03 13:34:48 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Hermann Riemann
der auch die Erfahrung gemacht hat dass man bei K&R C
beim hello world programm die #include Anweisung
weglassen kann.
Und es dann genauso abläuft, wenn das Laufzeitsystem mitspielt.
Das dürfte auch bei den meisten standardkonformen Compilern
funktionieren. Garantiert ist es nicht, weil »int printf(char *)«
und »int printf(const char *, ...)« unterschiedliche Aufrufkonventionen
haben könnten. Gcc warnt daher »incompatible implicit declaration of
built-in function ‘printf’«.
Das hängt von der Unterprogrammschnittstelle ab.
Das könnte ein Ende Markierung für Argumente sein.
( Dies war früher bei BS2000 so.)
Es könnte auch irgendwo Längenangaben stehen.

Hermann
der früher statt eine Argumentliste
einen pointer auf eine Struktur übergeben hat,
weil dies aufwärtskompatibel erweiterbar ist.
--
http://www.hermann-riemann.de
Thomas Koenig
2017-01-30 18:12:36 UTC
Permalink
Raw Message
Post by Hermann Riemann
Post by Thomas Koenig
Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
int main(){return 0;}
Beispiel, was fehlerhaft war: Das Äquivalent für MVS, IEFBR14.
Das hatte zwei Fehler, einmal wurde der return code nicht gesetzt,
das zweit mal wurde vergessen, das Programm reentrant zu setzen.
Ach ja, und dann fehlte noch der Programmname im Hexdump, aber
das war eine Ergänzung.

Mittlerweile glaubt man aber, dass dieses Programm keine Fehler
mehr hat :-)
Helmut Schellong
2017-01-30 12:49:14 UTC
Permalink
Raw Message
Post by Thomas Koenig
Sicher, dass kein Fehler im
Programm steckt, kann man nie sein.
Ich kann sicherstellen, daß zumindest Module in sich
100% korrekt sind.
Ich kann mir vorstellen, daß mit großer Disziplin und Konzentration
und mit Ausschöpfung einer optimalen Entwicklungszeit
eine vollkommen fehlerfreie Software möglich ist.
Zumindest, wenn nur ein Entwickler dran arbeitet.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Schellong
2017-05-27 19:10:03 UTC
Permalink
Raw Message
Post by Helmut Schellong
Es ist ja vor etwa 3 Monaten der Marslander Schiaparelli auf der
Mars-Oberfläche zerschellt.
Wegen Software-Fehler.
Der Fehler hat Ähnlichkeit mit dem Ariane5-Fehler.
Wieder so ein Algorithmus-Fehler mit einem Mangel
bei der Beachtung von Plausibilität.
Eine negative Höhe wurde festgestellt;
Harald Lesch erzählte (und wirkte dabei sauer), daß die
Einheiten [Feet] und [m] verwechselt wurden.
Für ihn ist der Fehler etwas zum Schämen.
Es stellt sich sich immer wieder heraus, daß sogenannte
Sichere Sprachen oder Sicherheitsmerkmale nichts nützen,
wenn notwendige Überlegungen beim Programmieren unterlassen
werden, und ähnliche Vorkommnisse.
"Der Betriebswirt ordnet an: jetzt ist der Lander fertig entwickelt."
Wie bei CSI aufgeschnappt: "Der Staatsanwalt sagt, wir sind jetzt fertig
mit unseren Tatort-Ermittlungen."
Waren die beim Apollo-Programm mit ~30 KB Code in Assembler besser?
Scheint mir fast so; vollkommen fehlerlos war das damals aber nicht.
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf

d) Eine unerwartete Drehung des Landers wurde notiert.
e) Fallschirm-Ausbringung wurde angestoßen.
f) Fallschirm-Entfaltung dauerte 1 s - okay.
o Das Fallschirm-Aufblasen generierte einige Oszillationen ~2,5 Hz.
o Nach etwa 0,2 s stellte die IMU eine Winkelabweichung fest, die
höher war als erwartet.
o Die IMU setzte ein Sättigungs-Flag.
o Während das Sättigungs-Flag gesetzt war, setzte die GNC-Software
einen dem Sättigungs-Schwellwert entsprechenden Winkelwert fest.
Die Festlegung dieser Konstante, während der Lander in Wirklichkeit
oszillierte, führte zu einem Fehler hinsichtlich dem von der GNC
geschätzten Winkelwert von etwa 165 Grad.
Dies würde beinahe einem Falschherum des Landers entsprechen!
o Nach Fallschirm-Aufblasen war die Oszillation des Landers
auf normale Werte gedämpft - fast verschwunden.
g) Der Front-Schild wurde wie geplant 40 s nach e) abgeworfen.
h) Das Radar (RDA) wurde eingeschaltet und meldete keinerlei Anomalien.
o Konsistenz-Checks der Messungen von IMU und RDA wurden vorgenommen:
o Wegen des fehlerhaften geschätzten Winkels durch die GNC-Software
veranschlagte die GNC die Messungen des Radars mit einem falschen
Winkel und einer negativen Höhe (cos(>90°)).
i) In Konsequenz schlug der Konsistenz-Check mehr als 5 s fehl.
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
o GNC-Mode war TERMINAL_DESCENT, wo die Höhe genau beobachtet wird,
um den Rücken-Schild und den Fallschirm passend abzuwerfen.
o Wegen der negativen Höhe (<+Schwellwert) veranlaßte die GNC dies.
j) Abwurf des Rückenschildes, und damit des Fallschirms.
k) Einschalten des Reaction-Control-System (RCS), in 3,7 km Höhe.
l) Abschalten des RCS nach 3 Sekunden --> Freier Fall.
o Das Kriterium für die Abschaltung basierte auf der Schätzung der
EDM-Energie (Höhe und Geschw.), die kleiner wurde als ein Schwellwert.
Weil die geschätzte Höhe negativ und sehr groß war, war die Energie
des negativen Potentials viel höher als die positive kinetische
Energie, und dieses Kriterium RCS-Off war sofort erfüllt.
m) Crash des Landers mit 150 m/s.
Die erwartete Landezeit lag 37 s später.

Wenn ein Fallschirm ausgestoßen wird, liegt zunächst ein im Detail
nicht vorhersagbares unsymmetrisches Verhalten vor.
Wenn der Schirm sich aufbauscht, gibt es einen gewaltigen Ruck, der
einen fallschirmspringenden Menschen mächtig zur Seite und nach oben
reißen kann.
Bei Körpern, die breiter als hoch sind (Schiaparelli), ist dieser Effekt
noch wesentlich heftiger, besonders, wenn der Zug nicht vollkommen
symmetrisch und zentral zum Schwerpunkt gerichtet ist, oder wenn die
Last eine ungleiche Gewichtsverteilung hat.
Diese Kenntnisse waren bei der ESA offenbar nicht vorhanden.

Ich würde einige Sekunden lang, nach dem Aufbauschen des Schirms, alle
relevanten Meßwerte zwar protokollieren, jedoch nicht für irgendwelche
Aktions-Entscheidungen verwenden - also pauschal ignorieren.
Nach ein paar Sekunden würde ich nochmals messen.
(Es gab 40 s Zeit!)
Ein Sättigungs-Flag würde ich je nach späteren Meßwerten wieder
zurücksetzen bzw. so frühzeitig erst gar nicht setzen.

Ich würde dem Radar Vorrang vor den cosinus-Berechnungen der GNC
geben - unbedingt!
Denn, das Radar braucht man unbedingt für die Landung; also würde
ich mich blind auf die Werte vom Radar verlassen, weil man ohne
funktionierendes Radar sowieso nicht landen kann - in keinem Fall!
Ohne die Berechnungen der GNC hier kann man hingegen sehr wohl landen.
Simple Logik.

Es wurden die fortlaufend korrekten Werte des Radars ignoriert
und errechneten, katastrophal falschen und unplausiblen Werten
der GNC Vorrang eingeräumt.
Das hatte eine negative Höhe zur Folge, weshalb wiederum
der Fallschirm abgeworfen wurde --> freier Fall!

Weil die korrekten Werte des Radars ignoriert wurden, wurden
auch noch die Triebwerke schnell wieder abgeschaltet
oder gar nicht erst eingeschaltet.
Zum Einschalten der Triebwerke (3,7 km) wurde das Radar jedoch
benutzt - oh Wunder, wie logisch!

Eine negative oder geringe Höhe vor Abwurf des Fallschirms
ist in jedem Falle unplausibel.
Ich würde dann nochmals Meßwerte ziehen (und verrechnen).

In dem Lander Schiaparelli steckt aus meiner Sicht ein ziemlich
großer Haufen Unlogik - nicht vernünftig-praktisch, sondern
theoretisch-dilettantisch bei der Software und beim Konzept.

Es wäre unter Umständen besser und sicherer, ohne Radar, einfach
nur nach Zeitdauern zu landen!
Man müßte dann eine längere Triebwerks-Zeit vorsehen, als Puffer.
Muß man eine IMU (Trägheitsnavigation) haben?
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Peter J. Holzer
2017-05-29 07:03:05 UTC
Permalink
Raw Message
Post by Helmut Schellong
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf
d) Eine unerwartete Drehung des Landers wurde notiert.
e) Fallschirm-Ausbringung wurde angestoßen.
f) Fallschirm-Entfaltung dauerte 1 s - okay.
o Das Fallschirm-Aufblasen generierte einige Oszillationen ~2,5 Hz.
o Nach etwa 0,2 s stellte die IMU eine Winkelabweichung fest, die
höher war als erwartet.
Nicht Winkelabweichung, sondern Winkelgeschwindigkeit.
Post by Helmut Schellong
o Die IMU setzte ein Sättigungs-Flag.
o Während das Sättigungs-Flag gesetzt war, setzte die GNC-Software
einen dem Sättigungs-Schwellwert entsprechenden Winkelwert fest.
Die Festlegung dieser Konstante, während der Lander in Wirklichkeit
oszillierte, führte zu einem Fehler hinsichtlich dem von der GNC
geschätzten Winkelwert von etwa 165 Grad.
Dies würde beinahe einem Falschherum des Landers entsprechen!
o Nach Fallschirm-Aufblasen war die Oszillation des Landers
auf normale Werte gedämpft - fast verschwunden.
g) Der Front-Schild wurde wie geplant 40 s nach e) abgeworfen.
h) Das Radar (RDA) wurde eingeschaltet und meldete keinerlei Anomalien.
o Wegen des fehlerhaften geschätzten Winkels durch die GNC-Software
veranschlagte die GNC die Messungen des Radars mit einem falschen
Winkel und einer negativen Höhe (cos(>90°)).
i) In Konsequenz schlug der Konsistenz-Check mehr als 5 s fehl.
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
Das halte ich für eine Fehlübersetzung. "forced into the loop" verstehe
ich so, dass die Messwerte des Radars trotz fehlgeschlagener
Konsistenzchecks verwendet wurden.
Post by Helmut Schellong
o GNC-Mode war TERMINAL_DESCENT, wo die Höhe genau beobachtet wird,
um den Rücken-Schild und den Fallschirm passend abzuwerfen.
o Wegen der negativen Höhe (<+Schwellwert) veranlaßte die GNC dies.
j) Abwurf des Rückenschildes, und damit des Fallschirms.
k) Einschalten des Reaction-Control-System (RCS), in 3,7 km Höhe.
l) Abschalten des RCS nach 3 Sekunden --> Freier Fall.
o Das Kriterium für die Abschaltung basierte auf der Schätzung der
EDM-Energie (Höhe und Geschw.), die kleiner wurde als ein Schwellwert.
Weil die geschätzte Höhe negativ und sehr groß war, war die Energie
des negativen Potentials viel höher als die positive kinetische
Energie, und dieses Kriterium RCS-Off war sofort erfüllt.
m) Crash des Landers mit 150 m/s.
Die erwartete Landezeit lag 37 s später.
Wenn ein Fallschirm ausgestoßen wird, liegt zunächst ein im Detail
nicht vorhersagbares unsymmetrisches Verhalten vor.
Wenn der Schirm sich aufbauscht, gibt es einen gewaltigen Ruck, der
einen fallschirmspringenden Menschen mächtig zur Seite und nach oben
reißen kann.
Bei Körpern, die breiter als hoch sind (Schiaparelli), ist dieser Effekt
noch wesentlich heftiger, besonders, wenn der Zug nicht vollkommen
symmetrisch und zentral zum Schwerpunkt gerichtet ist, oder wenn die
Last eine ungleiche Gewichtsverteilung hat.
Diese Kenntnisse waren bei der ESA offenbar nicht vorhanden.
Das ist so natürlich nicht richtig. Natürlich wussten die ESA-Ingenieure
(oder die des Auftragnehmers), dass es beim Öffnen eines Fallschirms bei
Überschallgeschwindigkeit "einen gewaltiger Ruck gibt". Die wissen das
sogar ziemlich sicher besser als ein Laie wie Du und ich. Es wurden ja
auch Simulationen durchgeführt. Diese Simulationen waren allerdings
unzureichend (was dabei alles nicht berücksichtigt wurde, kann man im
Bericht nachlesen), und die Schaukelbewegungen waren in der Praxis dann
deutlich heftiger - so heftig, dass das Inertialsystem seinen Messwerten
nicht mehr geglaubt hat.
Post by Helmut Schellong
Ich würde einige Sekunden lang, nach dem Aufbauschen des Schirms, alle
relevanten Meßwerte zwar protokollieren, jedoch nicht für irgendwelche
Aktions-Entscheidungen verwenden - also pauschal ignorieren.
Nach ein paar Sekunden würde ich nochmals messen.
(Es gab 40 s Zeit!)
Eine Entscheidung wurde in diesen 40 Sekunden ohnehin nicht getroffen.
Aber Du missverstehst offenbar, wie das Inertialsystem funktioniert. Das
liefert keine absolute Lage im Raum, sondern Informationen über
Drehbewegungen. Die absolute Lage ergibt sich durch fortlaufende
Integration der Drehbewegungen. Da hier ein Teil der Messwerte falsch
war, war das Integral auch falsch.
Post by Helmut Schellong
Ein Sättigungs-Flag würde ich je nach späteren Meßwerten wieder
zurücksetzen bzw. so frühzeitig erst gar nicht setzen.
Das Flag wurde ja zurückgesetzt, nachdem die Schaukelbewegungen wieder
im erwarteten Rahmen waren, aber da war der Schaden schon passiert.

Was hier nötig gewesen wäre, wäre wohl eine Neukalibrierung des
Inertialsystem gewesen. Oder alternativ (wenn das zu lange dauert oder
in dieser Situation nicht möglich ist) hätte man auf die unzuverlässigen
Werte des Inertialsystems verzichten und alternative Quellen für die
Lagebestimmung verwenden müssen.
Post by Helmut Schellong
Ich würde dem Radar Vorrang vor den cosinus-Berechnungen der GNC
geben - unbedingt!
Denn, das Radar braucht man unbedingt für die Landung; also würde
ich mich blind auf die Werte vom Radar verlassen, weil man ohne
funktionierendes Radar sowieso nicht landen kann - in keinem Fall!
Ohne die Berechnungen der GNC hier kann man hingegen sehr wohl landen.
Simple Logik.
Es wurden die fortlaufend korrekten Werte des Radars ignoriert
und errechneten, katastrophal falschen und unplausiblen Werten
der GNC Vorrang eingeräumt.
Falsch. Der GNC hat die Werte des Radars nicht ignoriert. Er hat aus den
(korrekten) Werten des Radars und den (falschen) Lagewerten einen
falschen Abstand zum Boden errechnet. Das wurde zwar bemerkt, aber weil
die Ingenieure zwar vorhergesehen hatten, dass das Radar falsche Werte
liefert, aber nicht, dass die Lage falsch sein könnte, gab es keine
sinnvolle mögliche Aktion - denn wie Du richtig schreibst, ohne Radar
ist keine Landung möglich.
Post by Helmut Schellong
Das hatte eine negative Höhe zur Folge, weshalb wiederum
der Fallschirm abgeworfen wurde --> freier Fall!
Weil die korrekten Werte des Radars ignoriert wurden, wurden
auch noch die Triebwerke schnell wieder abgeschaltet
oder gar nicht erst eingeschaltet.
Zum Einschalten der Triebwerke (3,7 km) wurde das Radar jedoch
benutzt - oh Wunder, wie logisch!
Einfache State-Machine.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2017-05-29 19:53:34 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Helmut Schellong
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf
[...]
Post by Peter J. Holzer
Das halte ich für eine Fehlübersetzung. "forced into the loop" verstehe
ich so, dass die Messwerte des Radars trotz fehlgeschlagener
Konsistenzchecks verwendet wurden.
Fehlübersetzung?
Ich schrieb nicht, daß die Meßwerte nicht verwendet wurden, sondern
hatte das 1:1 übersetzt:
--------------------------------------------------------------------
the RDA was forced anyway into the loop based on the logic that
landing was impossible without the RDA.
--------------------------------------------------------------------
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
--------------------------------------------------------------------

Ich war da aber etwas verunsichert, wegen zuvor:
"Once the RDA is on, RIL mode,"
Das Radar war also eh schon im Loop-Modus, und es wurde dann pauschal
forciert der Loop-Modus aktiviert.

[...]
Post by Peter J. Holzer
Post by Helmut Schellong
Wenn ein Fallschirm ausgestoßen wird, liegt zunächst ein im Detail
nicht vorhersagbares unsymmetrisches Verhalten vor.
Wenn der Schirm sich aufbauscht, gibt es einen gewaltigen Ruck, der
einen fallschirmspringenden Menschen mächtig zur Seite und nach oben
reißen kann.
Bei Körpern, die breiter als hoch sind (Schiaparelli), ist dieser Effekt
noch wesentlich heftiger, besonders, wenn der Zug nicht vollkommen
symmetrisch und zentral zum Schwerpunkt gerichtet ist, oder wenn die
Last eine ungleiche Gewichtsverteilung hat.
Diese Kenntnisse waren bei der ESA offenbar nicht vorhanden.
Das ist so natürlich nicht richtig. Natürlich wussten die ESA-Ingenieure
(oder die des Auftragnehmers), dass es beim Öffnen eines Fallschirms bei
Überschallgeschwindigkeit "einen gewaltiger Ruck gibt". Die wissen das
sogar ziemlich sicher besser als ein Laie wie Du und ich.
Ja, so habe auch ich das angenommen.
Jedoch wurde dieses Wissen nicht in der Software berücksichtigt,
so als ob dieses Wissen nicht vorhanden wäre.
Post by Peter J. Holzer
Es wurden ja
auch Simulationen durchgeführt. Diese Simulationen waren allerdings
unzureichend (was dabei alles nicht berücksichtigt wurde, kann man im
Bericht nachlesen), und die Schaukelbewegungen waren in der Praxis dann
deutlich heftiger - so heftig, dass das Inertialsystem seinen Messwerten
nicht mehr geglaubt hat.
Eben - das alles wirkt, als ob da einiges 'zu gut' gemacht wurde,
irgendwie überkandidelt, unrobust.
Post by Peter J. Holzer
Post by Helmut Schellong
Ich würde einige Sekunden lang, nach dem Aufbauschen des Schirms, alle
relevanten Meßwerte zwar protokollieren, jedoch nicht für irgendwelche
Aktions-Entscheidungen verwenden - also pauschal ignorieren.
Nach ein paar Sekunden würde ich nochmals messen.
(Es gab 40 s Zeit!)
Eine Entscheidung wurde in diesen 40 Sekunden ohnehin nicht getroffen.
Doch, es wurde das Flag gesetzt, nach dem sich dann alles richtete!
Das GNC hat deshalb den konstanten Sättigungs-Schwellwert als realen
Meßwert *ersatzweise angenommen* und alles hierauf basierende
40+15+5 s lang konserviert, bis einschließlich der Konsistenz-Tests
mit dem Radar!
Das GNC hat also die Situation 0,2 s nach dem Fallschirm-Aufbauschen
wertemäßig eingefroren und alles spätere Plausible ignoriert.

Das Radar hat während seiner Arbeit fortlaufend Höhenwerte von
einigen Kilometern geliefert, was die GNC ignorierte.
Die Oszillation betrug direkt nach dem Aufbauschen weniger als 3°.
Da wäre die Höhe vom Radar, ohne weitere Berechnung!, schon recht genau.
Post by Peter J. Holzer
Aber Du missverstehst offenbar, wie das Inertialsystem funktioniert. Das
liefert keine absolute Lage im Raum, sondern Informationen über
Drehbewegungen.
Das weiß ich - also kein Mißverstehen.
Welcher meiner Textabschnitte gibt denn dem Verdacht Nahrung, ich würde
annehmen, die Trägheitsnavigation würde die absolute Lage im Raum liefern?
Post by Peter J. Holzer
Die absolute Lage ergibt sich durch fortlaufende
Integration der Drehbewegungen. Da hier ein Teil der Messwerte falsch
war, war das Integral auch falsch.
Post by Helmut Schellong
Ein Sättigungs-Flag würde ich je nach späteren Meßwerten wieder
zurücksetzen bzw. so frühzeitig erst gar nicht setzen.
Das Flag wurde ja zurückgesetzt, nachdem die Schaukelbewegungen wieder
im erwarteten Rahmen waren, aber da war der Schaden schon passiert.
Der 'zukünftige Schaden' hier waren die von der GNC konservierten
falschen Werte.
Erst etwa 45+15+5 s später kamen die falschen Werte zu schädlicher
Anwendung, obwohl schon etwa 0,3 s später alles hier relevante
in bester Ordnung war.

Rücksetzen finde ich im Dokument nicht;
========================================================================
led to the Schiaparelli failure:
--------------------------------
o Insufficient conservative modelling of the parachute dynamics
which led to expect much lower dynamics than observed in flight;
o Inadequate persistence time of the IMU saturation flag
and inadequate handling of IMU saturation by the GNC;
o Insufficient approach to FDIR and design robustness;
o Mishap in management of subcontractors and acceptance of hardware,
(the persistence of IMU saturation time was not recorded
at acceptance and instead believed to be 15 ms).
......................................................................
root causes for the mishap:
---------------------------
o Insufficient uncertainty and configuration management in the
modelling of the parachute dynamics which led to expect much
lower dynamics than observed in flight;
o Inadequate persistence time of the IMU saturation flag and
inadequate handling of IMU saturation by the GNC;
o Insufficient approach to Failure Detection, Isolation and Recovery
and design robustness;
o Mishap in management of subcontractors and acceptance of hardware.
========================================================================
Post by Peter J. Holzer
Was hier nötig gewesen wäre, wäre wohl eine Neukalibrierung des
Inertialsystem gewesen. Oder alternativ (wenn das zu lange dauert oder
in dieser Situation nicht möglich ist) hätte man auf die unzuverlässigen
Werte des Inertialsystems verzichten und alternative Quellen für die
Lagebestimmung verwenden müssen.
Ja, ich schrieb ja, daß alle Werte während einiger Sekunden nach dem
Fallschirm-Aufbauschen bis auf den Log gänzlich unbenutzt sein
sollten.
Werteziehen 0,2 s nach dem Aufbauschen sollte es einfach nicht geben.
Alternative Quellen sind unnötig.
Man kann hier kurze Zeit auf Werte völlig verzichten.
Post by Peter J. Holzer
Post by Helmut Schellong
Ich würde dem Radar Vorrang vor den cosinus-Berechnungen der GNC
geben - unbedingt!
Denn, das Radar braucht man unbedingt für die Landung; also würde
ich mich blind auf die Werte vom Radar verlassen, weil man ohne
funktionierendes Radar sowieso nicht landen kann - in keinem Fall!
Ohne die Berechnungen der GNC hier kann man hingegen sehr wohl landen.
Simple Logik.
Es wurden die fortlaufend korrekten Werte des Radars ignoriert
und errechneten, katastrophal falschen und unplausiblen Werten
der GNC Vorrang eingeräumt.
Falsch. Der GNC hat die Werte des Radars nicht ignoriert. Er hat aus den
(korrekten) Werten des Radars und den (falschen) Lagewerten einen
falschen Abstand zum Boden errechnet.
Der GNC hat die Werte des Radars nicht bewertet, sondern blind verrechnet.
Das meine ich mit 'ignoriert'.
Wie so vieles in der Software leider nicht sophisticated ist.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
G.B.
2017-05-30 21:05:59 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Post by Helmut Schellong
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf
[...]
Post by Peter J. Holzer
Das halte ich für eine Fehlübersetzung. "forced into the loop" verstehe
ich so, dass die Messwerte des Radars trotz fehlgeschlagener
Konsistenzchecks verwendet wurden.
Fehlübersetzung?
Ich schrieb nicht, daß die Meßwerte nicht verwendet wurden, sondern
Das scheint mir der Fehler zu sein. Oder falls eine nur
eigenlogische Übersetzung, dann nicht zu diskutieren. Eine
1:1-Übersetzung (was immer das sein soll, eine Charakterisierung
wie "bedeutungserhaltend" wäre da anders)
ergibt oft nur etwas, das inhaltlich so nah an Übersetzung ist,
wie eine Translation.
Post by Helmut Schellong
--------------------------------------------------------------------
the RDA was forced anyway into the loop based on the logic that
landing was impossible without the RDA.
--------------------------------------------------------------------
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
--------------------------------------------------------------------
Sag doch mal, was du als "the loop" auffasst.



Vielleicht bezeichnet "loop" hier eine Auswahl aus den technischen, größeren
Komponenten des Systems und/oder deren co-operative Wirkweise; sie sind teilweise
auch benannt. Die Einladung zum Missverständnis ist u.a. dadurch angelegt,
dass "forced into" mit "versetzt in" übersetzt und damit die Objektbezüge
verschoben sind: Dreht sich das RDA in einer eigenen Schleife, oder wird
das RDA in eine "Schleife" aufgenommen?

Dein Ansatz einer Übersetzung bedient sich bei "the" des bewährten, dokumentierten
rhetorischen Mittels, ob gewollt oder versehentlich, the == eine zu setzen.
Diese Ersetzung des bestimmten durch einen unbestimmten Artikel kann
fachwissenschaftlich ein durchaus schwerwiegender logischer Fehler sein,
für andere Zwecke ist sie aber eine gute Grundlage: da wo es von Vorteil
ist, das Bestimmte ins Unbestimmte zu verwirren.

Versuchsweise könnte ich interpretieren, dass in der Formulierung "the loop"
etwas wie "its loop" inhaltlich impliziert wäre, weil die Schreiber solchermaßen
in der Denkwelt um die untersuchte Gerätschaft gefangen gewesen wären, dass
alltagssprachliche Ungenauigkeit in die Veröffentlichung aufgenommen und
entsprechenden Kontext für diese Deutung zu nennen versäumt worden wäre.
M.E. keine zulässige Annahme bei einer vermutlich mehrfach und
fachübergreifend gegengelesenen Veröffentlichung.
Helmut Schellong
2017-05-31 09:43:41 UTC
Permalink
Raw Message
Post by G.B.
Post by Helmut Schellong
Post by Peter J. Holzer
Post by Helmut Schellong
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf
[...]
Post by Peter J. Holzer
Das halte ich für eine Fehlübersetzung. "forced into the loop" verstehe
ich so, dass die Messwerte des Radars trotz fehlgeschlagener
Konsistenzchecks verwendet wurden.
Fehlübersetzung?
Ich schrieb nicht, daß die Meßwerte nicht verwendet wurden, sondern
Das scheint mir der Fehler zu sein. Oder falls eine nur
eigenlogische Übersetzung, dann nicht zu diskutieren. Eine
1:1-Übersetzung (was immer das sein soll, eine Charakterisierung
wie "bedeutungserhaltend" wäre da anders)
ergibt oft nur etwas, das inhaltlich so nah an Übersetzung ist,
wie eine Translation.
Post by Helmut Schellong
--------------------------------------------------------------------
the RDA was forced anyway into the loop based on the logic that
landing was impossible without the RDA.
--------------------------------------------------------------------
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
--------------------------------------------------------------------
Sag doch mal, was du als "the loop" auffasst.
Vielleicht bezeichnet "loop" hier eine Auswahl aus den technischen, größeren
Komponenten des Systems und/oder deren co-operative Wirkweise; sie sind
[...]
Texte aus dem Dokument:
"Once the RDA is on, RIL mode, ..."
RIL = Radar in the loop

Daraus schließe ich, daß RIL nur zum RDA gehört.
RIL bedeutet IMO, daß das Radar fortlaufend Höhen-Werte generiert,
zum Abholen durch andere Module.

Ich kenne Luftkühlung und forcierte Luftkühlung mit Ventilator.
Das Radar war bereits im RIL-Modus und wurde dann pauschal (anyway)
in den RIL-Modus gezwungen (forced).
Ohne diese Schaltung kann das Radar möglicherweise von selbst
den Loop beenden.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Peter J. Holzer
2017-06-05 17:51:17 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by G.B.
Post by Helmut Schellong
Post by Peter J. Holzer
Post by Helmut Schellong
18.05.2017 - Endauswertung und Fazit
------------------------------------
http://www.schellong.de/pdf/schiaparelli18052017.pdf
[...]
Post by Peter J. Holzer
Das halte ich für eine Fehlübersetzung. "forced into the loop" verstehe
ich so, dass die Messwerte des Radars trotz fehlgeschlagener
Konsistenzchecks verwendet wurden.
Fehlübersetzung?
Ich schrieb nicht, daß die Meßwerte nicht verwendet wurden, sondern
Das scheint mir der Fehler zu sein. Oder falls eine nur
eigenlogische Übersetzung, dann nicht zu diskutieren. Eine
1:1-Übersetzung (was immer das sein soll, eine Charakterisierung
wie "bedeutungserhaltend" wäre da anders)
ergibt oft nur etwas, das inhaltlich so nah an Übersetzung ist,
wie eine Translation.
Post by Helmut Schellong
--------------------------------------------------------------------
the RDA was forced anyway into the loop based on the logic that
landing was impossible without the RDA.
--------------------------------------------------------------------
Danach wurde das RDA forciert in eine Schleife versetzt, basierend
auf der Logik, daß das Landen ohne das RDA unmöglich ist.
--------------------------------------------------------------------
Sag doch mal, was du als "the loop" auffasst.
Vielleicht bezeichnet "loop" hier eine Auswahl aus den technischen, größeren
Komponenten des Systems und/oder deren co-operative Wirkweise; sie sind
[...]
"Once the RDA is on, RIL mode, ..."
RIL = Radar in the loop
Daraus schließe ich, daß RIL nur zum RDA gehört.
RIL bedeutet IMO, daß das Radar fortlaufend Höhen-Werte generiert,
zum Abholen durch andere Module.
Meiner Meinung nach nein: RIL bedeutet, dass die Werte des Radars für
die Höhenbestimmung verwendet werden. "The loop" ist hier offenbar der
Regelkreis, oder möglicherweise eine Anwendung der englischen
Redewendung "to be in the loop", was so viel wie "[in Entscheidungen]
eingebunden" bedeutet.

Das ist hier meines Erachtens ziemlich eindeutig: 15 Sekunden nach dem
Abwerfen des Hitzeschilds wurde das RDA eingeschaltet. Nach dem
Einschalten wurden "RIL mode, “consistency checks”" [das Komma hier ist
offensichtlich falsch - der Autor hat offenbar die Neigung an zufälligen
Stellen Kommas einzufügen, das ist mir andernorts auch mehrfach
aufgefallen] durchgeführt. Die haben ein negatives Ergebnis geliefert.
Natürlich möchte man inkonsistente Werte nicht verwenden, also wurden
sie (vorerst) nicht verwendet.

Nachdem sich 5 Sekunden an dieser bedauerlichen Situation nichts
geändert hat, wurde die Verwendung der Messwerte des Radars erzwungen.
[Ich spekuliere, dass das Radar kurz nach dem Einschalten ein paar
Sekunden braucht, um zuverlässige Werte zu liefern. Die Konsistenzchecks
sollten diese Phase überbrücken. Nach 5 Sekunden ist das Radar entweder
"da", oder man hat sowieso verloren.]

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2017-06-05 19:40:03 UTC
Permalink
Raw Message
[...]
Post by Peter J. Holzer
Post by Helmut Schellong
Post by G.B.
Sag doch mal, was du als "the loop" auffasst.
Vielleicht bezeichnet "loop" hier eine Auswahl aus den technischen, größeren
Komponenten des Systems und/oder deren co-operative Wirkweise; sie sind
[...]
"Once the RDA is on, RIL mode, ..."
RIL = Radar in the loop
Daraus schließe ich, daß RIL nur zum RDA gehört.
RIL bedeutet IMO, daß das Radar fortlaufend Höhen-Werte generiert,
zum Abholen durch andere Module.
Meiner Meinung nach nein: RIL bedeutet, dass die Werte des Radars für
die Höhenbestimmung verwendet werden. "The loop" ist hier offenbar der
Regelkreis, oder möglicherweise eine Anwendung der englischen
Redewendung "to be in the loop", was so viel wie "[in Entscheidungen]
eingebunden" bedeutet.
Auf Seite 2 steht "RIL Radar In the Loop", unter vielen anderen
Abkürzungen mit jeweiliger Erklärung.
Das ist dort die einzige Zeile mit "Loop".
RIL gibt es nur für RDA.
Es gibt z.B. nicht IIL für 'IMU in the loop', etc.
Post by Peter J. Holzer
Das ist hier meines Erachtens ziemlich eindeutig: 15 Sekunden nach dem
Abwerfen des Hitzeschilds wurde das RDA eingeschaltet. Nach dem
Einschalten wurden "RIL mode, “consistency checks”" [das Komma hier ist
offensichtlich falsch - der Autor hat offenbar die Neigung an zufälligen
Stellen Kommas einzufügen, das ist mir andernorts auch mehrfach
aufgefallen] durchgeführt.
============================================================================
Once the RDA is on, RIL mode, “consistency checks” between IMU and RDA
measurements are performed.
============================================================================
Du meinst also, das Komma nach 'mode' ist falsch.
Ich meine, folgender Text hat gleiche Bedeutung:
»Once the RDA is on (RIL mode), “consistency checks” between IMU and RDA«

[... ...]

Ich sehe in Übersetzungen eher das Gegenteil, nämlich daß das RDA
in den Loop eingebunden wurde, damit das RDA informiert blieb: Einschleifen
Das ist jedoch widersprüchlich/unplausibel.

Das Dokument ist in diesem Punkt schlicht unklar/widersprüchlich.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Loading...