>>641]

1行目，ある意味正しい．
よもやあんなポカをやるとは，事前に誰も予想してなかったので（事故直後の専門家の論評含め)，
センサー対策もできなかっただろう．
2度目以降は対策立てたらなんとかなるかも．
だけど，あれは納入業者のミスというより，SpaceX のポカ(検査が甘い，文書化がいい加減)ではあるんだろう．

この他，紹介されたソースにはテレメトリーの転送の仕方で，非決定論的なネットワークパケットで
事故直前のデータが失われて解析が面倒になったことへの批判と改善要求があるね．

General Finding: SpaceX’s new implementation (forFalcon 9 “Full Thrust” flights)
of non-deterministic network packets in their flight telemetry increases
latency, directly resulting in substantial portions of the anomaly data
being lost due to network buffering in the Stage 2 flight computer.


上段のトラブルは，アボートシステムに頼るより，
信頼性を徹底するよう設計段階から考慮すべきだな．

上段のトラブルといえば，2015年のソユーズ＋プログレス宇宙船(M-27-M)の分離失敗もあった．
あの時はプログレス宇宙船(が不規則な回転状態になっていたので，有人だったら大変だった．
タイミング的にはアボートタワーを切り離したかなり後の段階なので，
宇宙船側の推進装置で対処するしかない．
あれは予定高度より 30-40 km 高かったそうなので，分離失敗と言うより爆発か，
宇宙船側の推進装置でアボート対策できるかどうか怪しい．


全液体ロケットでも，事故が起きる時には起きるし，これらの事例ではアボートがうまくいくかどうか怪しい．