思想と現実の狭間：有人宇宙飛行に見る安全とは ― 2020年09月21日 19:23
思想と現実の狭間：有人宇宙飛行に見る安全とは
先だって見たエウロパ（映画）の中にも、そういえばそんな台詞があった気がする。
困難な任務だからこそ、有人で実施するんだって。
スターライナーがＯＦＴ－１でコケタ時、ジムブライデンスタインは、直後には有人だったらうまくいったかもしれないとコメントした。
テクニカルダイビングの世界では、２つ目のトラブルは想定されていない。
バックアップの器材は有限だし、同時に致命的なトラブルが重なる確率は低い。
一つ目のトラブルは、バックアップに切り替えて凌ぐことができる場合もあるが、同時に起こった２つ目、３つ目のトラブルは対処できない。
宇宙では、バックアップがない場合の方が多いだろうな。
それでも、そこに人間を送り、機械と一緒に仕事をさせて成果を上げようという話は多い。
そもそも、人間が行くことが目的化しているしな。
アルテミス計画なんて、今更月面に人間が行って何が出来るわけじゃないけど、とにかく行くんだと。
そういう話になっちまっている。
この間のクルードラゴンのデモ－２でもそうだったが、今時の宇宙船は、人間がいなくても飛ぶ。
つーか、人間を荷物として積んでいくだけで、もう大変な仕掛けを用意しなければならない。
呼吸させなきゃならんし、温度管理もシビアだし、加速度は塩梅しないと潰れちゃうし、挙句の果てには打ち上げ時に乗り心地が悪いとか言い出すしな。
人間が乗っていない方がスムーズに行くことが多いのではないか。
まあ、それだと話が終わってしまうから、あくまでも人間を乗せていくことにする。
それで、何かいいことがあるんだろうか？。
ＯＦＴ－１の時は、アトラスＶロケットとスターライナー宇宙船との時計がずれていて、ミッションを継続することができなくなった。
その間違ったランタイムにいるはずの場所に辿り着こうとして、スターライナー側の燃料をしこたま使っちまったからな。
地上から止めようとしても、通信不良で直ぐには止まらなかったらしい（未確認）。
宇宙飛行士が乗っていれば、スイッチをポンと押して（具体な方法は未確認）、簡単に誤った噴射を止められたというのがストーリーとして語られた。
いいだろう。
有人の方が、アホなプログラムを馬鹿正直に実行しようとする機械より頭がいいからな。
先日、スペースシャトルの緊急打ち切りを調べていて、似たような話を見つけた。
（STS-51-F）
https://en.wikipedia.org/wiki/STS-51-F
「打ち上げ中にチャレンジャーは、RS-25エンジンで複数のセンサー障害を経験し、「Abort to Orbit」（ATO）緊急手順を実行する必要がありました。打ち上げ後に打ち切りを行ったのは唯一のシャトルミッション。ATOの結果、ミッションは少し低い軌道高度で実行されました。」
「上昇の3分31秒後、中央エンジンの2つの高圧燃料ターボポンプタービン吐出温度センサーの1つが故障しました。2分12秒後、2番目のセンサーが故障し、センターエンジンがシャットダウンしました。これは、スペースシャトルプログラムの飛行中のメインエンジンの唯一の障害でした。」
「フライトの約8分後、右側のエンジンの同じ温度センサーの1つが故障し、残りの右側のエンジンの温度センサーは、エンジンのシャットダウンのレッドラインの近くに測定値を表示しました。」
テクニカルダイビングで言えば、２つ目のトラブルが発生したようなもんだな。
テクニカルダイビングのミッションは、一つ目のトラブル発生で中止だが、ＳＴＳ－５１Ｆでは、そうならなかった。
「ブースターシステムエンジニアジェニーM.ハワードは、残りのセンサーの読み取り値に基づいて、RS-25の自動シャットダウンを禁止するように乗務員に指示し、2台目のエンジンの潜在的なシャットダウンと、車両の損失につながる可能性のある中止モードを防止するように迅速に行動しました。」
その判断をしたのは地上エンジニアだったから、有人システムでなくてもミッションは継続できたと言えば言えなくもない。
ちょっと分かり辛いんだが、ＡＴＯというのはミッションの中止じゃなくて、予定軌道より低い軌道に入ってミッションを可能な限り継続するという選択肢だ。
（軌道に乗って中止）
https://en.wikipedia.org/wiki/Space_Shuttle_abort_modes#Abort_to_orbit
「軌道への打ち切り（ATO）は、目的の軌道に到達できなかったときに利用できましたが、より低い安定した軌道（つまり、地表から120マイル以上）が可能でした」
「通信が失われた場合、宇宙船の司令官は打ち切りの決定を行い、独立して行動を起こした可能性があります。」
まあ、そういうことにしておこうか。
スターライナーの場合も、スペースシャトルの場合も、機械側の不具合によるミッションの完全な中止を、人間が介入することによって阻止し、しかるべく回復させて継続するという麗しい状況なわけだ。
その判断は、機械が限られたセンサーの値を読むだけというショボイ性能しか持っていなくて、様々なデータを総合して判断し、最善の結論を導くことができる人間がいるからこそ正しいと言える。
サルな人間ではダメで、訓練された優秀な奴じゃないとな。
デモ２が有人で行われたのは、まだ、クルードラゴンの機械としての信頼性に疑問があるからだ。
デモ１で戻ってきた機体が、アボートテストでスーパードラコを吹かした後で、配管内で酸化剤リークを起こし、チタンバルブと反応して木っ端みじんに吹っ飛んだ話以外にも、隠れた瑕疵が表出する可能性があったからな。
人間が乗っていれば、そのチョンボをカバーすることができる可能性がある。
しかし、生命維持装置とかにチョンボがあれば、乗っている人間の方が逝っちまう可能性もあるわけで、難しい判断になるわけだ。
機械だけなら、成功したのに・・・。
有人飛行が目的の場合、これじゃあ成功とは言えないしな。
スターライナーの再突入の際に、噴射タイミングが間違っていて、あわや分離したクルーモジュールにサービスモジュールが追突しかねなかったチョンボについては、人間が乗っていようが乗っていまいが、致命的な失敗に繋がった可能性がある。
地上スタッフが気付いて、緊急にデータを差し替えたから良かったようなものの、さもなければ目も当てられない被害をもたらしたに違いない。
この件は、既に記事にしたところだが、アポロ１１号の時にも似たような話があったという。
（50年前の今日地球帰還、アポロ11号の知られざる危機が今になって明らかに）
https://www.newsweekjapan.jp/stories/world/2019/07/5011.php
「再突入時にバラバラになったサービスモジュールの一部でもコマンドモジュールの軌道と交錯し、接触するようなことがあれば、時速4万キロメートルでの衝突となる。大事故は避けられず、3人の宇宙飛行士の帰還は危うい。」
今回、決して繰り返してはいけない話が繰り返されかけたわけで、技術の経時的な分断の恐ろしさ、人間の愚かさを感じざるを得ない。
もう一つ考えなければならないのは、有人で行うことと無人で行うことには基本的な差はないということだ。
有人で行うための技術的困難さをクリアして、ミッション成功に得られるメリットがどれほどあるかは知らない。
サルなシステムでは、困難を解決してくれる有難い存在には違いないだろうが、現代の賢いシステムで、人間がその場で介入しなければ実行できない話はないのではないか。
もちろん、火星の穴掘りに苦労しているインサイトの代わりに、土方のおっちゃんを送り込めれば、深さ５ｍの穴なんて簡単に掘れるという話はある（そういう比較かあ？）。
ミッションの性質に依るだろうし、何度も書いているように、人間を送り込むこと自体が目的のミッションでは選択肢はない。
システムの機能部品として人間を捉えるのか、お客様として捉えるのかという２者選択ではなく、宇宙「開発」では、その中間ということになるんだろう。
宇宙「旅行」ではお客様だがな。
やっかいだが、金を払ってくれる有難い荷物だ。
まあいい。
浮沈子は、有人宇宙開発に懐疑的だ。
過酷過ぎる環境に、人間は適応できない。
宇宙空間に軌道速度で飛び出すことさえ、容認できないリスクがある。
それでも、人間が機械と手を携えて飛びたいというなら、せめて機械の側では可能な限り安全を追求すべきだ。
それが、有人宇宙飛行の基本思想でなくてどーする？。
機械のミスを、人間がカバーしてミッションを成功させるなどという考えが、未だに残っているのが不思議だ。
冒頭紹介したエウロパという映画は、最後まで生き残っていたクルー（つまり、それ以外の全員は既に死んでる）が、エウロパの海に沈みゆく宇宙船のハッチを開いて、怪物を船内のカメラに捉えさせるという壮絶なシーンで終わる（おっと、ネタバレ！）。
映像データは地球に送信され、ミッションは成功！。
全滅したクルーは、英雄として称えられることになるんだろうが、なんか違うような気がする。
人間の職人技に頼る話は、飛行機関係でも存在する。
（18か月の調査後、DeFazio議長とLarsen議長、ボーイング737 MAXに関する最終委員会報告書を発表）
https://transportation.house.gov/news/press-releases/after-18-month-investigation-chairs-defazio-and-larsen-release-final-committee-report-on-boeing-737-max
「・隠蔽の文化：
ボーイングは、FAA、その顧客、737 MAXパイロットからの重要な情報を差し控えました。これには、ボーイングのテストパイロットがフライトシミュレーターでのコマンドなしのMCASのアクティブ化を診断して応答するのに10秒以上かかったことがパイロットの説明した状態を示す内部テストデータが含まれています「壊滅的」として。連邦政府のガイドラインは、パイロットが4秒以内にこの状態に応答することを前提としています。」
１０秒だから遅いとか、４秒以内ならいいとか、そういう話じゃないような気がするんだがな。
まあ、どうでもいいんですが。
ロケットの場合、人間が介入して飛ばせる範囲は極めて狭いだろう（未確認：旧ソ連時代は、手動操縦の離れ業でドッキングしてたらしい）。
巡航状態の微調整や航法については、さまざまな手動バックアップの手法があるようだが、打ち上げや再突入、ランデブー、ドッキングは機械の方が正確で確実に違いない（失敗するとヤバいしな）。
また、そうでなければ乗員の安全を確保することはできない。
そうでなかったために、何人もの犠牲者を出しているしな。
マンマシンシステムといえば聞こえはいいが、未成熟の技術を人間がカバーする話に過ぎない。
車の運転、飛行機の操縦、宇宙船の操縦。
電動アシスト自転車もそうかもしれない。
漕がないと進まないし、ハンドルから手を離せば倒れてしまう（手放し運転は止めましょう！）。
道を間違えれば遠回りになるしな（健康のために歩けばあ？）。
何でも自動でできるのがいいが、現実はそう上手くは出来ていない。
全自動と徒歩との間で人間は生きている。
それが、避けがたい現実である以上、最適解を求め続ける作業は続く。
絶対の安全を求めるなら、何処へも行かず、家で引き籠っているのが一番だ。
そうでないなら、正しい器材を正しく使い、トレーニングを欠かさず、マンマシンシステムを使いこなすしかない。
浮沈子は、スターライナーについては、ある疑問を持っている。
通信は別として、少なくとも２つのプログラムミスがあったソフトウェアを、ぶつ切り状態ではなく統合テストして、果たしてミスを発見できたのかどうかということだ。
修復しないで、当初のまま統合テストして、仮に何らかの偶然で条件がクリアされ、ミスを発見できないまま進行するようなことがあれば、統合テストそのものの信頼性を疑わなければならくなるからな。
特に、再突入時の噴射のタイミングデータの誤りについてはその疑問が消えない（タイマーの齟齬は、まあ見つかるかもな）。
ぶつ切りにしてテストしたことだけではなく、根本的に違う手法を採らなければ解決できないのではないか。
それはいつどのように行われ、どういう結果になっているのか。
１２月に飛ぶ話は出て来るけど、Ｂ社の企業秘密にかかわる話は出てこないからな。
何が秘密なのかも分からない（それが秘密だからな）。
それは、たまたまうまくいった（かも知れない）クルードラゴンも同じだ。
デモ２のレビューが終わっているのか、評価結果がどうだったのかも分からないままだ。
こっちは、１０月２３日（現地時間）だけが示されている。
最大の安全を追求しつつ、受け入れなければならない危険を伴う宇宙飛行。
客を乗せて、ＩＳＳに連れて行く前にすべきことは多いような気がするがな・・・。
＜以下追加＞－－－－－－－－－－
（ボーイングとNASAがスターライナーミッションで複数の異常を認める）
https://www.nasaspaceflight.com/2020/02/boeing-nasa-admit-multiple-anomalies-starliner-mission/
７か月以上前の記事だが、問題検証の段階でさえ、事を荒立てたくない、穏便に済ませたい、できれば無人飛行しないで有人飛行に繋げたいという下心があることが分かるな。
浮沈子が気になったのは、以下のところだ・・・。
「ミッション経過タイマーの最初の問題を取り巻く状況は文書化されていますが、木曜日の午後にASAPから判明したのは、2番目の主要なソフトウェアコーディングエラーでした。」
「サンチェス氏はミッション経過タイマーの異常以外の異常が発生したかどうか尋ねられました。彼の答えは、先のとがった決定的な「いいえ」でした。」
「発見して修正したので異常ではなかった」
「2番目の問題をメディアや米国の納税者に開示する必要はなかった」
「起こらなかった何かについて私たちが話したいと思わないでしょう。」
起こらなかったことは話さなくてもいいけど、コーディングミスを隠蔽することは正当化されるのかあ？。
「ボーイングのJim Chiltonが、Mission Elapsed Timerの最初の問題が発生していなければ2番目のソフトウェアの問題を発見できなかったことを認めた」
浮沈子は、点火のタイミングの誤りを発見したプロセスを知りたかったんだが、急遽、点検したに違いない。
「2つ目のソフトウェアの問題は、Starlinerが大気圏に再突入しようとしたときに破壊される数時間前に発見されました。」
やれやれ・・・。
見つかって良かったな。
いや、良かったのかどうか。
無事に着陸させてしまったことにより、内部改革が中途半端になり、問題の深い根が断たれることなく、ほとぼりが冷めれば元の木阿弥・・・。
タイマーエラーさまさまというところか。
もしも、タイマーが正常で、ドッキングにも成功し、万々歳で帰還する際に第２のエラーで破壊されたら目も当てられないからな。
宇宙船を曲がりなりにも着陸させ、徹底的に調べることができたわけで、改善のための豊富な材料を手に出来たことになる。
回収に失敗したら、隠れた瑕疵を抱えたまま、次の飛行に臨まなければならないところだったわけだ。
ソフトウェアエラーは、地上で保管されていたコードを洗えば発見され、改修は可能だろうが、再突入時にバラバラになっちまった宇宙船を調べることはできないからな。
不幸中の幸いで、スターライナーは地上に戻れた。
ＯＦＴ－１は、失敗が約束されていたフライトだったわけだ。
失敗するか、大失敗するか（そんなあ！）。
確認しておこう。
この宇宙機は、有人宇宙船として作られた。
要素技術は優れており、それぞれのシチュエーションで繰り返しテストされた（そうではなかったという話は、以下の＜さらに追加＞で）。
統合テストは省略されたかもしれないが、確認を怠ったわけではない。
考えてみれば、ＯＦＴ－１は統合テストの一環だ。
起こりうるトラブルは、そこで起こった。
それだけの話かもしれない。
そして、もう一度、統合テストが行われる。
年内か、来年かは知らない。
一度で済むかどうかは分からない。
浮沈子は、１度で沢山だと思っている。
２度目はいらない。
次に決定的なチョンボをしでかすようなら、お引き取り頂くのがいい。
この会社には、有人宇宙船を作る能力がないということだ。
間違っても、人間を乗せて機械のエラーをカバーしようなどとは考えないことだな・・・。
＜さらに追加＞－－－－－－－－－－
過去記事を漁って気になる記事を２つ見つけた。
（ボーイングクルーカプセル、ケープカナベラルからの打ち上げ後に沈静化）
https://spaceflightnow.com/2019/12/20/boeing-crew-capsule-falters-after-launch-from-cape-canaveral/
昨年１２月の打ち上げ直後の記事で、まだ２つ目のエラー（再突入時の噴射タイミングの問題）は見つかっていない時のものだ。
「「この非常に重要な挿入操作でこのタイミングに問題があったことを理解しています」とStich氏は語った。「私たちは、隠された問題がそこにないことを確認するためだけに、デオービットの書き込みとエントリを楽しみにして見なければなりません。それで、ソフトウェアを見て、シミュレータでいくつかの実行を行います…それがすべて安全であることを確認します。」」
その結果がどうだったかが、３月の記事に出ている。
（ボーイングは徹底的なテストがStarlinerソフトウェアの問題を捕らえたであろうと言います）
https://spaceflightnow.com/2020/02/28/boeing-says-thorough-testing-would-have-caught-starliner-software-problems/
「ミッションタイマーの問題が発生した後、ボーイングのエンジニアは、スターライナーのソフトウェアコードの他のセグメントを確認して、他の問題領域を探しました。彼らは、飛行前のテストで見逃された別のソフトウェアエラーを発見しました。これにより、Starlinerのサービスモジュールが、大気圏に再突入する直前に船の2つの要素が分離した後に、クラフトの乗員モジュールに激突しました。」
ミッションタイマーのエラーがなければ、再突入のシミュレーションは行われなかった。
そして、分離したクルーモジュールにサービスモジュールが激突して大破する可能性を発見したのだ。
なぜ、そんな基本的な過ちを犯し、事前にそれを発見できなかったかについても示唆している。
「マルホランド氏によると、より徹底的なテストによって、再突入前にスターライナーのサービスモジュールを安全に投棄するために必要な、誤って設定されたソフトウェアが明らかになった可能性もあるという。」
マルホランドさんはそう思っているかもしれないが、浮沈子は単なる幸運だけだと思うがな。
「マルホランド氏によると、Starlinerサービスモジュールの推進コントローラーは、別のプログラムで使用されている設計に基づいており、そのソフトウェアは、乗務員モジュールから分離した後のサービスモジュールの処分用に不適切に構成されていた。推進コントローラーの誤った「ジェットマップ」には、サービスモジュールのスラスタとバルブに関する情報が含まれていました。」
別のプログラムって何よ？。
「スターライナーは2つの異なるジェットマップを使用します。1つは宇宙船全体が接続されているとき、つまり搭乗員モジュールコンピューターがスラスタの発射を命令するときと、もう1つはサービスモジュールが投棄された後の処分火傷のためです。」
「収集された唯一のことは、統合された宇宙船のための1つのジェットマップであり、分離後のサービスに必要なジェットマップを逃した」
つまり、クルーモジュールとサービスモジュールがくっ付いている時の１つだけがコーディングしてあっただけで、分離後のもう１つの方を書き忘れちゃったってことかあ？。
「推進コントローラーのソフトウェアテストでは、Starliner宇宙船で飛行するための実際のコントローラーではなく、エミュレーターまたはシミュレートされたコンポーネントを使用したと彼は語った。ボーイングがソフトウェアシミュレーションを実行したとき、実際の推進コントローラーは、ニューメキシコのサービスモジュールスラスタのテスト噴射に使用されていました。」
「「その推進コントローラーは他のテストをサポートする外部にありましたが、ソフトウェアのそのセクションの認定テストを実行したときであり、不正なエミュレーターがあったため（そして）正しいジェットマッピングがなかったため、その問題は明らかになりませんでした。資格試験中」とマルホランド氏は語った。「ハードウェアがラボに返却されたため、ミッション中にシーケンスを再実行し、ジェットマッピングの問題を特定し、ソフトウェアの修正をアップロードしてから、再書き込みを行うことができました。」」
要するに、正しい要素試験が行われずに、本番に突入したということになる。
チャンクに分けた（ぶつ切りにした）個々のテストも、いい加減だったということになる。
本番のミッション中に、急遽行われたそのテストの評価が十分だったかどうかも分からない。
そんなコードを、本番中にアップリンクして（しかも、通信状態に問題を抱えている中）、無事に地上におろせたのは奇跡だ。
もし、推進コントローラーとやらがラボに戻っていなくて、不正なエミュレーターのままで再突入シーケンスを再実行していたら、この問題は発見できなかったじゃないの。
ははは・・・。
浮沈子は、ＯＦＴ－２が失敗する方に１票だな（１００票でもいい）。
「宇宙船が宇宙ステーションにドッキングしなかったため、チームはスターライナーのランデブーセンサーとナビゲーションセンサーのパフォーマンスを完全に確認できませんでした。」
ＩＳＳのドッキングアダプターは、２個ともボーイングが作った（Ｎｏ．１と、Ｎｏ．３。Ｎｏ．２は、スペースＸ社が、打ち上げ失敗で大西洋に叩き落しちゃったからな）。
宇宙船との間のデータのやり取りや、ハードウェアの設計製造については、世界のだれよりも詳しいはずだ。
ここでのチョンボは許されないだろう。
しかし、わからんぞお。
再び「不正なエミュレーター」が登場し、チョンボなソフトウェアや、有り得ないハードウェアの欠陥が露呈するかもしれない（大きさ違ってて、ハマんなかったりしたら目も当てられないな・・・）
まあ、クルードラゴンは、２回とも成功しているからな。
出来ませんでしたとは、舌噛んでも言えまい。
年内見送りで、来年になるだろうが、お手並み拝見というところだ。
先だって見たエウロパ（映画）の中にも、そういえばそんな台詞があった気がする。
困難な任務だからこそ、有人で実施するんだって。
スターライナーがＯＦＴ－１でコケタ時、ジムブライデンスタインは、直後には有人だったらうまくいったかもしれないとコメントした。
テクニカルダイビングの世界では、２つ目のトラブルは想定されていない。
バックアップの器材は有限だし、同時に致命的なトラブルが重なる確率は低い。
一つ目のトラブルは、バックアップに切り替えて凌ぐことができる場合もあるが、同時に起こった２つ目、３つ目のトラブルは対処できない。
宇宙では、バックアップがない場合の方が多いだろうな。
それでも、そこに人間を送り、機械と一緒に仕事をさせて成果を上げようという話は多い。
そもそも、人間が行くことが目的化しているしな。
アルテミス計画なんて、今更月面に人間が行って何が出来るわけじゃないけど、とにかく行くんだと。
そういう話になっちまっている。
この間のクルードラゴンのデモ－２でもそうだったが、今時の宇宙船は、人間がいなくても飛ぶ。
つーか、人間を荷物として積んでいくだけで、もう大変な仕掛けを用意しなければならない。
呼吸させなきゃならんし、温度管理もシビアだし、加速度は塩梅しないと潰れちゃうし、挙句の果てには打ち上げ時に乗り心地が悪いとか言い出すしな。
人間が乗っていない方がスムーズに行くことが多いのではないか。
まあ、それだと話が終わってしまうから、あくまでも人間を乗せていくことにする。
それで、何かいいことがあるんだろうか？。
ＯＦＴ－１の時は、アトラスＶロケットとスターライナー宇宙船との時計がずれていて、ミッションを継続することができなくなった。
その間違ったランタイムにいるはずの場所に辿り着こうとして、スターライナー側の燃料をしこたま使っちまったからな。
地上から止めようとしても、通信不良で直ぐには止まらなかったらしい（未確認）。
宇宙飛行士が乗っていれば、スイッチをポンと押して（具体な方法は未確認）、簡単に誤った噴射を止められたというのがストーリーとして語られた。
いいだろう。
有人の方が、アホなプログラムを馬鹿正直に実行しようとする機械より頭がいいからな。
先日、スペースシャトルの緊急打ち切りを調べていて、似たような話を見つけた。
（STS-51-F）
https://en.wikipedia.org/wiki/STS-51-F
「打ち上げ中にチャレンジャーは、RS-25エンジンで複数のセンサー障害を経験し、「Abort to Orbit」（ATO）緊急手順を実行する必要がありました。打ち上げ後に打ち切りを行ったのは唯一のシャトルミッション。ATOの結果、ミッションは少し低い軌道高度で実行されました。」
「上昇の3分31秒後、中央エンジンの2つの高圧燃料ターボポンプタービン吐出温度センサーの1つが故障しました。2分12秒後、2番目のセンサーが故障し、センターエンジンがシャットダウンしました。これは、スペースシャトルプログラムの飛行中のメインエンジンの唯一の障害でした。」
「フライトの約8分後、右側のエンジンの同じ温度センサーの1つが故障し、残りの右側のエンジンの温度センサーは、エンジンのシャットダウンのレッドラインの近くに測定値を表示しました。」
テクニカルダイビングで言えば、２つ目のトラブルが発生したようなもんだな。
テクニカルダイビングのミッションは、一つ目のトラブル発生で中止だが、ＳＴＳ－５１Ｆでは、そうならなかった。
「ブースターシステムエンジニアジェニーM.ハワードは、残りのセンサーの読み取り値に基づいて、RS-25の自動シャットダウンを禁止するように乗務員に指示し、2台目のエンジンの潜在的なシャットダウンと、車両の損失につながる可能性のある中止モードを防止するように迅速に行動しました。」
その判断をしたのは地上エンジニアだったから、有人システムでなくてもミッションは継続できたと言えば言えなくもない。
ちょっと分かり辛いんだが、ＡＴＯというのはミッションの中止じゃなくて、予定軌道より低い軌道に入ってミッションを可能な限り継続するという選択肢だ。
（軌道に乗って中止）
https://en.wikipedia.org/wiki/Space_Shuttle_abort_modes#Abort_to_orbit
「軌道への打ち切り（ATO）は、目的の軌道に到達できなかったときに利用できましたが、より低い安定した軌道（つまり、地表から120マイル以上）が可能でした」
「通信が失われた場合、宇宙船の司令官は打ち切りの決定を行い、独立して行動を起こした可能性があります。」
まあ、そういうことにしておこうか。
スターライナーの場合も、スペースシャトルの場合も、機械側の不具合によるミッションの完全な中止を、人間が介入することによって阻止し、しかるべく回復させて継続するという麗しい状況なわけだ。
その判断は、機械が限られたセンサーの値を読むだけというショボイ性能しか持っていなくて、様々なデータを総合して判断し、最善の結論を導くことができる人間がいるからこそ正しいと言える。
サルな人間ではダメで、訓練された優秀な奴じゃないとな。
デモ２が有人で行われたのは、まだ、クルードラゴンの機械としての信頼性に疑問があるからだ。
デモ１で戻ってきた機体が、アボートテストでスーパードラコを吹かした後で、配管内で酸化剤リークを起こし、チタンバルブと反応して木っ端みじんに吹っ飛んだ話以外にも、隠れた瑕疵が表出する可能性があったからな。
人間が乗っていれば、そのチョンボをカバーすることができる可能性がある。
しかし、生命維持装置とかにチョンボがあれば、乗っている人間の方が逝っちまう可能性もあるわけで、難しい判断になるわけだ。
機械だけなら、成功したのに・・・。
有人飛行が目的の場合、これじゃあ成功とは言えないしな。
スターライナーの再突入の際に、噴射タイミングが間違っていて、あわや分離したクルーモジュールにサービスモジュールが追突しかねなかったチョンボについては、人間が乗っていようが乗っていまいが、致命的な失敗に繋がった可能性がある。
地上スタッフが気付いて、緊急にデータを差し替えたから良かったようなものの、さもなければ目も当てられない被害をもたらしたに違いない。
この件は、既に記事にしたところだが、アポロ１１号の時にも似たような話があったという。
（50年前の今日地球帰還、アポロ11号の知られざる危機が今になって明らかに）
https://www.newsweekjapan.jp/stories/world/2019/07/5011.php
「再突入時にバラバラになったサービスモジュールの一部でもコマンドモジュールの軌道と交錯し、接触するようなことがあれば、時速4万キロメートルでの衝突となる。大事故は避けられず、3人の宇宙飛行士の帰還は危うい。」
今回、決して繰り返してはいけない話が繰り返されかけたわけで、技術の経時的な分断の恐ろしさ、人間の愚かさを感じざるを得ない。
もう一つ考えなければならないのは、有人で行うことと無人で行うことには基本的な差はないということだ。
有人で行うための技術的困難さをクリアして、ミッション成功に得られるメリットがどれほどあるかは知らない。
サルなシステムでは、困難を解決してくれる有難い存在には違いないだろうが、現代の賢いシステムで、人間がその場で介入しなければ実行できない話はないのではないか。
もちろん、火星の穴掘りに苦労しているインサイトの代わりに、土方のおっちゃんを送り込めれば、深さ５ｍの穴なんて簡単に掘れるという話はある（そういう比較かあ？）。
ミッションの性質に依るだろうし、何度も書いているように、人間を送り込むこと自体が目的のミッションでは選択肢はない。
システムの機能部品として人間を捉えるのか、お客様として捉えるのかという２者選択ではなく、宇宙「開発」では、その中間ということになるんだろう。
宇宙「旅行」ではお客様だがな。
やっかいだが、金を払ってくれる有難い荷物だ。
まあいい。
浮沈子は、有人宇宙開発に懐疑的だ。
過酷過ぎる環境に、人間は適応できない。
宇宙空間に軌道速度で飛び出すことさえ、容認できないリスクがある。
それでも、人間が機械と手を携えて飛びたいというなら、せめて機械の側では可能な限り安全を追求すべきだ。
それが、有人宇宙飛行の基本思想でなくてどーする？。
機械のミスを、人間がカバーしてミッションを成功させるなどという考えが、未だに残っているのが不思議だ。
冒頭紹介したエウロパという映画は、最後まで生き残っていたクルー（つまり、それ以外の全員は既に死んでる）が、エウロパの海に沈みゆく宇宙船のハッチを開いて、怪物を船内のカメラに捉えさせるという壮絶なシーンで終わる（おっと、ネタバレ！）。
映像データは地球に送信され、ミッションは成功！。
全滅したクルーは、英雄として称えられることになるんだろうが、なんか違うような気がする。
人間の職人技に頼る話は、飛行機関係でも存在する。
（18か月の調査後、DeFazio議長とLarsen議長、ボーイング737 MAXに関する最終委員会報告書を発表）
https://transportation.house.gov/news/press-releases/after-18-month-investigation-chairs-defazio-and-larsen-release-final-committee-report-on-boeing-737-max
「・隠蔽の文化：
ボーイングは、FAA、その顧客、737 MAXパイロットからの重要な情報を差し控えました。これには、ボーイングのテストパイロットがフライトシミュレーターでのコマンドなしのMCASのアクティブ化を診断して応答するのに10秒以上かかったことがパイロットの説明した状態を示す内部テストデータが含まれています「壊滅的」として。連邦政府のガイドラインは、パイロットが4秒以内にこの状態に応答することを前提としています。」
１０秒だから遅いとか、４秒以内ならいいとか、そういう話じゃないような気がするんだがな。
まあ、どうでもいいんですが。
ロケットの場合、人間が介入して飛ばせる範囲は極めて狭いだろう（未確認：旧ソ連時代は、手動操縦の離れ業でドッキングしてたらしい）。
巡航状態の微調整や航法については、さまざまな手動バックアップの手法があるようだが、打ち上げや再突入、ランデブー、ドッキングは機械の方が正確で確実に違いない（失敗するとヤバいしな）。
また、そうでなければ乗員の安全を確保することはできない。
そうでなかったために、何人もの犠牲者を出しているしな。
マンマシンシステムといえば聞こえはいいが、未成熟の技術を人間がカバーする話に過ぎない。
車の運転、飛行機の操縦、宇宙船の操縦。
電動アシスト自転車もそうかもしれない。
漕がないと進まないし、ハンドルから手を離せば倒れてしまう（手放し運転は止めましょう！）。
道を間違えれば遠回りになるしな（健康のために歩けばあ？）。
何でも自動でできるのがいいが、現実はそう上手くは出来ていない。
全自動と徒歩との間で人間は生きている。
それが、避けがたい現実である以上、最適解を求め続ける作業は続く。
絶対の安全を求めるなら、何処へも行かず、家で引き籠っているのが一番だ。
そうでないなら、正しい器材を正しく使い、トレーニングを欠かさず、マンマシンシステムを使いこなすしかない。
浮沈子は、スターライナーについては、ある疑問を持っている。
通信は別として、少なくとも２つのプログラムミスがあったソフトウェアを、ぶつ切り状態ではなく統合テストして、果たしてミスを発見できたのかどうかということだ。
修復しないで、当初のまま統合テストして、仮に何らかの偶然で条件がクリアされ、ミスを発見できないまま進行するようなことがあれば、統合テストそのものの信頼性を疑わなければならくなるからな。
特に、再突入時の噴射のタイミングデータの誤りについてはその疑問が消えない（タイマーの齟齬は、まあ見つかるかもな）。
ぶつ切りにしてテストしたことだけではなく、根本的に違う手法を採らなければ解決できないのではないか。
それはいつどのように行われ、どういう結果になっているのか。
１２月に飛ぶ話は出て来るけど、Ｂ社の企業秘密にかかわる話は出てこないからな。
何が秘密なのかも分からない（それが秘密だからな）。
それは、たまたまうまくいった（かも知れない）クルードラゴンも同じだ。
デモ２のレビューが終わっているのか、評価結果がどうだったのかも分からないままだ。
こっちは、１０月２３日（現地時間）だけが示されている。
最大の安全を追求しつつ、受け入れなければならない危険を伴う宇宙飛行。
客を乗せて、ＩＳＳに連れて行く前にすべきことは多いような気がするがな・・・。
＜以下追加＞－－－－－－－－－－
（ボーイングとNASAがスターライナーミッションで複数の異常を認める）
https://www.nasaspaceflight.com/2020/02/boeing-nasa-admit-multiple-anomalies-starliner-mission/
７か月以上前の記事だが、問題検証の段階でさえ、事を荒立てたくない、穏便に済ませたい、できれば無人飛行しないで有人飛行に繋げたいという下心があることが分かるな。
浮沈子が気になったのは、以下のところだ・・・。
「ミッション経過タイマーの最初の問題を取り巻く状況は文書化されていますが、木曜日の午後にASAPから判明したのは、2番目の主要なソフトウェアコーディングエラーでした。」
「サンチェス氏はミッション経過タイマーの異常以外の異常が発生したかどうか尋ねられました。彼の答えは、先のとがった決定的な「いいえ」でした。」
「発見して修正したので異常ではなかった」
「2番目の問題をメディアや米国の納税者に開示する必要はなかった」
「起こらなかった何かについて私たちが話したいと思わないでしょう。」
起こらなかったことは話さなくてもいいけど、コーディングミスを隠蔽することは正当化されるのかあ？。
「ボーイングのJim Chiltonが、Mission Elapsed Timerの最初の問題が発生していなければ2番目のソフトウェアの問題を発見できなかったことを認めた」
浮沈子は、点火のタイミングの誤りを発見したプロセスを知りたかったんだが、急遽、点検したに違いない。
「2つ目のソフトウェアの問題は、Starlinerが大気圏に再突入しようとしたときに破壊される数時間前に発見されました。」
やれやれ・・・。
見つかって良かったな。
いや、良かったのかどうか。
無事に着陸させてしまったことにより、内部改革が中途半端になり、問題の深い根が断たれることなく、ほとぼりが冷めれば元の木阿弥・・・。
タイマーエラーさまさまというところか。
もしも、タイマーが正常で、ドッキングにも成功し、万々歳で帰還する際に第２のエラーで破壊されたら目も当てられないからな。
宇宙船を曲がりなりにも着陸させ、徹底的に調べることができたわけで、改善のための豊富な材料を手に出来たことになる。
回収に失敗したら、隠れた瑕疵を抱えたまま、次の飛行に臨まなければならないところだったわけだ。
ソフトウェアエラーは、地上で保管されていたコードを洗えば発見され、改修は可能だろうが、再突入時にバラバラになっちまった宇宙船を調べることはできないからな。
不幸中の幸いで、スターライナーは地上に戻れた。
ＯＦＴ－１は、失敗が約束されていたフライトだったわけだ。
失敗するか、大失敗するか（そんなあ！）。
確認しておこう。
この宇宙機は、有人宇宙船として作られた。
要素技術は優れており、それぞれのシチュエーションで繰り返しテストされた（そうではなかったという話は、以下の＜さらに追加＞で）。
統合テストは省略されたかもしれないが、確認を怠ったわけではない。
考えてみれば、ＯＦＴ－１は統合テストの一環だ。
起こりうるトラブルは、そこで起こった。
それだけの話かもしれない。
そして、もう一度、統合テストが行われる。
年内か、来年かは知らない。
一度で済むかどうかは分からない。
浮沈子は、１度で沢山だと思っている。
２度目はいらない。
次に決定的なチョンボをしでかすようなら、お引き取り頂くのがいい。
この会社には、有人宇宙船を作る能力がないということだ。
間違っても、人間を乗せて機械のエラーをカバーしようなどとは考えないことだな・・・。
＜さらに追加＞－－－－－－－－－－
過去記事を漁って気になる記事を２つ見つけた。
（ボーイングクルーカプセル、ケープカナベラルからの打ち上げ後に沈静化）
https://spaceflightnow.com/2019/12/20/boeing-crew-capsule-falters-after-launch-from-cape-canaveral/
昨年１２月の打ち上げ直後の記事で、まだ２つ目のエラー（再突入時の噴射タイミングの問題）は見つかっていない時のものだ。
「「この非常に重要な挿入操作でこのタイミングに問題があったことを理解しています」とStich氏は語った。「私たちは、隠された問題がそこにないことを確認するためだけに、デオービットの書き込みとエントリを楽しみにして見なければなりません。それで、ソフトウェアを見て、シミュレータでいくつかの実行を行います…それがすべて安全であることを確認します。」」
その結果がどうだったかが、３月の記事に出ている。
（ボーイングは徹底的なテストがStarlinerソフトウェアの問題を捕らえたであろうと言います）
https://spaceflightnow.com/2020/02/28/boeing-says-thorough-testing-would-have-caught-starliner-software-problems/
「ミッションタイマーの問題が発生した後、ボーイングのエンジニアは、スターライナーのソフトウェアコードの他のセグメントを確認して、他の問題領域を探しました。彼らは、飛行前のテストで見逃された別のソフトウェアエラーを発見しました。これにより、Starlinerのサービスモジュールが、大気圏に再突入する直前に船の2つの要素が分離した後に、クラフトの乗員モジュールに激突しました。」
ミッションタイマーのエラーがなければ、再突入のシミュレーションは行われなかった。
そして、分離したクルーモジュールにサービスモジュールが激突して大破する可能性を発見したのだ。
なぜ、そんな基本的な過ちを犯し、事前にそれを発見できなかったかについても示唆している。
「マルホランド氏によると、より徹底的なテストによって、再突入前にスターライナーのサービスモジュールを安全に投棄するために必要な、誤って設定されたソフトウェアが明らかになった可能性もあるという。」
マルホランドさんはそう思っているかもしれないが、浮沈子は単なる幸運だけだと思うがな。
「マルホランド氏によると、Starlinerサービスモジュールの推進コントローラーは、別のプログラムで使用されている設計に基づいており、そのソフトウェアは、乗務員モジュールから分離した後のサービスモジュールの処分用に不適切に構成されていた。推進コントローラーの誤った「ジェットマップ」には、サービスモジュールのスラスタとバルブに関する情報が含まれていました。」
別のプログラムって何よ？。
「スターライナーは2つの異なるジェットマップを使用します。1つは宇宙船全体が接続されているとき、つまり搭乗員モジュールコンピューターがスラスタの発射を命令するときと、もう1つはサービスモジュールが投棄された後の処分火傷のためです。」
「収集された唯一のことは、統合された宇宙船のための1つのジェットマップであり、分離後のサービスに必要なジェットマップを逃した」
つまり、クルーモジュールとサービスモジュールがくっ付いている時の１つだけがコーディングしてあっただけで、分離後のもう１つの方を書き忘れちゃったってことかあ？。
「推進コントローラーのソフトウェアテストでは、Starliner宇宙船で飛行するための実際のコントローラーではなく、エミュレーターまたはシミュレートされたコンポーネントを使用したと彼は語った。ボーイングがソフトウェアシミュレーションを実行したとき、実際の推進コントローラーは、ニューメキシコのサービスモジュールスラスタのテスト噴射に使用されていました。」
「「その推進コントローラーは他のテストをサポートする外部にありましたが、ソフトウェアのそのセクションの認定テストを実行したときであり、不正なエミュレーターがあったため（そして）正しいジェットマッピングがなかったため、その問題は明らかになりませんでした。資格試験中」とマルホランド氏は語った。「ハードウェアがラボに返却されたため、ミッション中にシーケンスを再実行し、ジェットマッピングの問題を特定し、ソフトウェアの修正をアップロードしてから、再書き込みを行うことができました。」」
要するに、正しい要素試験が行われずに、本番に突入したということになる。
チャンクに分けた（ぶつ切りにした）個々のテストも、いい加減だったということになる。
本番のミッション中に、急遽行われたそのテストの評価が十分だったかどうかも分からない。
そんなコードを、本番中にアップリンクして（しかも、通信状態に問題を抱えている中）、無事に地上におろせたのは奇跡だ。
もし、推進コントローラーとやらがラボに戻っていなくて、不正なエミュレーターのままで再突入シーケンスを再実行していたら、この問題は発見できなかったじゃないの。
ははは・・・。
浮沈子は、ＯＦＴ－２が失敗する方に１票だな（１００票でもいい）。
「宇宙船が宇宙ステーションにドッキングしなかったため、チームはスターライナーのランデブーセンサーとナビゲーションセンサーのパフォーマンスを完全に確認できませんでした。」
ＩＳＳのドッキングアダプターは、２個ともボーイングが作った（Ｎｏ．１と、Ｎｏ．３。Ｎｏ．２は、スペースＸ社が、打ち上げ失敗で大西洋に叩き落しちゃったからな）。
宇宙船との間のデータのやり取りや、ハードウェアの設計製造については、世界のだれよりも詳しいはずだ。
ここでのチョンボは許されないだろう。
しかし、わからんぞお。
再び「不正なエミュレーター」が登場し、チョンボなソフトウェアや、有り得ないハードウェアの欠陥が露呈するかもしれない（大きさ違ってて、ハマんなかったりしたら目も当てられないな・・・）
まあ、クルードラゴンは、２回とも成功しているからな。
出来ませんでしたとは、舌噛んでも言えまい。
年内見送りで、来年になるだろうが、お手並み拝見というところだ。
最近のコメント