Was geschah mit Flug MH370?

Wenn es solchen Luxus wie das MFD mal überhaupt noch gab.

behind_eyes schrieb:Aber das MFD zeigt nicht mehr "offline" an wenn der Logon erfolgt ist, oder?

Das ist die Frage die man eigentlich klären müsste. Erfolgt ein Logeintrag bei INMARSAT innerhalb von, sagen wir 10 Sekunden, nachdem SATCOM nicht mehr Offline ist, und somit die entsprechende Meldung auch vom MfD verschwunden ist ?

Ich könnte mich auch täuschen, aber genau aus diesem Grund könnte der Täter ja auch das 18:25 UTC-Ereignis genutzt haben um sich anzuschauen wie lange es dauert bis die SATCOM-Meldung vom MfD verschwindet um diese Erkenntnis dann später nutzen zu können wegen der 07:00:00 Stunden-Sache.

Zz-Jones schrieb:Wenn es solchen Luxus wie das MFD mal überhaupt noch gab.

Das Middle-Flight-Display ? Das gab es natürlich, oder wovon sprichst Du ?

DearMRHazzard schrieb:Das ist die Frage die man eigentlich klären müsste. Erfolgt ein Logeintrag bei INMARSAT innerhalb von, sagen wir 10 Sekunden, nachdem SATCOM nicht mehr Offline ist, und somit die entsprechende Meldung auch vom MfD verschwunden ist ?

Da ich mich ein wenig mit Logerstellung auskenne, ich denke man kann prinzipiell davon ausgehen das die timestamps in den Logs stimmen, das muss aber nicht bedeuten das die Einträge auch zeitnah geschrieben werden, der dann geschriebene timestamp wird aber der timestamp des ursprünglichen Ereignisses sein.

Natürlich kann der Code so geschrieben sein, daß ein Ereignis "Status A" geschrieben wird, obwohl "Status A" schon ne Weile vergangen ist, ganz einfach weil es noch eine zweite Bedingung gibt, sagen wir "Status B", diese Bedingung aber nicht im Namen des Ereignisses auftaucht im Log. Das wäre unscharf programmiert und ich denke das dies vor allem in der Luftfahrt wohl eher nicht der Fall ist.

behind_eyes schrieb:Da ich mich ein wenig mit Logerstellung auskenne, ich denke man kann prinzipiell davon ausgehen das die timestamps in den Logs stimmen, das muss aber nicht bedeuten das die Einträge auch zeitnah geschrieben werden, der dann geschriebene timestamp wird aber der timestamp des ursprünglichen Ereignisses sein.

Im DCL haben wir halt nur einen Zeitstempel pro Ereignis, also müssen wir damit auch arbeiten.

Mich hat damals auch interessiert ob es einen Unterschied gibt zwischen Verarbeitung und Ereignis, aber ich konnte nie etwas darüber finden.

Was wir in den Logs aber auch sehen können ist, dass es um 00:11 UTC einen unvollständigen Ping gab der um diese Uhrzeit eigentlich nicht hätte geschehen dürfen. Wenn alles so gelaufen wäre wie in all den Stunden zuvor auch, dann hätte der unvollständige Ping um 00:15 UTC auftreten müssen. Hier entschied sich aber die GES in Perth dafür den Ping innerhalb von +/-256 Sekunden zu senden aufgrund hohen Datenverkehrs, was auch sehr viel Sinn machte, denn in Australien erhöhte sich um 08:11 Uhr morgens natürlich der Flugverkehr erheblich.

Pings zu senden für lustlose SDU´s rutschte dadurch wohl auf der Prioritätenliste in den Bereich "Mach ich wenn es am besten passt, und nicht wann ich es machen soll", um es mal so zu formulieren. Dafür gibt es bestimmt auch einen Fachbergriff. Vielleicht kennst Du ihn ja ?

DearMRHazzard schrieb:Im DCL haben wir halt nur einen Zeitstempel pro Ereignis, also müssen wir damit auch arbeiten.

Mich hat damals auch interessiert ob es einen Unterschied gibt zwischen Verarbeitung und Ereignis, aber ich konnte nie etwas darüber finden.

Den Unterschied gibt es eigentlich immer und je nach Auslastung der Systeme mal mehr oder weniger stark ausgeprägt. Deswegen ist es Usus, daß das zu schreibende Ereignis sich mit seinem timestamp gemerkt wird - im Speicher gehalten wird - bis es geschrieben wird. Die Information, wann etwas tatsächlich geschrieben wurde als zusätzlichen timestamp mit reinzubekommen ist garnichtmal so einfach, weil das Ereignis "schreiben erfolgreich beendet" ja erst vorbei sein muss bis man diese Information wieder schreiben kann.

DearMRHazzard schrieb:Pings zu senden für lustlose SDU´s rutschte dadurch wohl auf der Prioritätenliste in den Bereich "Mach ich wenn es am besten passt, und nicht wann ich es machen soll", um es mal so zu formulieren. Dafür gibt es bestimmt auch einen Fachbergriff. Vielleicht kennst Du ihn ja ?

Dafür bin ich zuwenig Programmierer, aber ich weiß das Threads - das sind Teile von Programmen die parallel ausgeführt werden, Logging ist mindestens einer davon, einen Ping senden als Teil einer Routine ein anderer - Prioritäten haben die festgelegt werden. Threads können ausgebremst werden, andere haben immer Vorfahrt usw.
Zum Beispiel das Löschen alter Logdaten - auf Systemen mit begrenztem Speicher - erfolgt Idr nur dann wenn das System die bereitgestellten Ressourcen auch hat oder das Hauptprogramm gerade wenig zu tun hat. Das sind Threads die mit Absicht völlig niedrig priorisiert sind.

@behind_eyes

Ok, also wenn ich das jetzt alles richtig verstehe, dann sind die Timestamps im DCL auch die Timestamps an denen die Ereignisse tatsächlich stattgefunden haben. Auslastung hin-oder her.

Die Timestamps der unvollständigen Pings zeigen ja auch sehr klar, dass sehr pünktlich nach jeweils 60 Minuten ein Ping gesendet und beantwortet wurde von der SDU, und das in den Logs auch genau so eingetragen wurde um 19:41, 20:41, 21:41, 22:41 und 00:11 UTC. Ich denke, für unsere Zwecke spielt daher auch die Zeit, wie lange diese Ereignisse im Speicher gehalten worden sein könnten, ohnehin keine Rolle.

Was im übrigen auch nicht geklärt wurde durch die Ermittler ist folgendes Problem :

Was passiert eigentlich mit SATCOM wenn man den Left AC Bus nur für 1 Sekunde isoliert ? Reicht das schon aus um die SDU dadurch zu einem Neustart zu zwingen, oder gilt hier eine Art Fail-Safe ? In meinen Tests damals in FSX mit dem PMDG 777-Mod erschien SATCOM sofort als Offline als ich den Left AC Bus isolierte, aber ist das auch realistisch ? Keine Ahnung.

DearMRHazzard schrieb:Was passiert eigentlich mit SATCOM wenn man den Left AC Bus nur für 1 Sekunde isoliert ? Reicht das schon aus um die SDU dadurch zu einem Neustart zu zwingen, oder gilt hier eine Art Fail-Safe ?

Es gibt die Test Kategorie Power Input

Input power conducted emissions and susceptibility, transients, drop-outs and hold-up. The power input tests simulate conditions of aircraft power from before engine start to after landing including emergencies.

Quelle: Wikipedia: DO-160

Sucht man jetzt nach der tatsächlich erlaubten drop out Zeit, kommt man auf maximal wenige hundert Millisekunden bei vollen Drop Out (also 0 Volt).... Also 200ms Idr..... Keine Primärquelle...