オープンソースの画像生成AIをセットアップから使い方まで解説する『Stable Diffusion AI画像生成ガイドブック』(ソシム刊)発売中(→本のサポートページ

イプシロンロケット試験機 打上げ中止の原因究明状況記者説明会

開催日時/場所

  • 2013年8月30日(金)16時〜
  • JAXA内之浦宇宙空間観測所計器センター 記者会見室(主会場)
  • JAXA東京事務所 プレゼンテーションルーム(副会場)

f:id:Imamura:20130830194013j:plain

登壇者

f:id:Imamura:20130830160245j:plain

  • JAXA 宇宙輸送ミッション本部 イプシロンロケットプロジェクトチーム プロジェクトマネージャ 森田泰弘
  • JAXA 宇宙輸送ミッション本部 鹿児島宇宙センター射場技術開発室長(打上管制隊企画主任) 長田弘

中継録画

4分30秒くらいに始まります※冒頭大きな音が出ます。ご注意ください


Video streaming by Ustream

資料のPDFはこちらから

打上げ中止原因究明状況について


森田:宇宙ファンの皆さん、地元の皆さん、応援団の皆さん、JAXA放送で応援して下さった皆さん、報道の皆さん、ご迷惑をおかけして申し訳ありません。
M-Vが終わって7年間、いろいろあったが皆さんの応援が背中を押してくれてようやくここまで来られた。みなさんの声を乗せたイプシロンロケットを成功させるよう進めていきたい。勝利の瞬間をお届けするまで応援をよろしくお願いします。
資料の説明。
f:id:Imamura:20130830194014j:plain

なにが起きたかを復習

f:id:Imamura:20130830194015j:plain

  1. 70秒前に自動カウントダウンシーケンスを開始
  2. 打上げ20秒前に地上装置(LCS)からの信号でロケット搭載計算機(OBC)を起動。1秒後にOBCがロケットの姿勢計算を開始。LCSはイプシロンロケットを遠隔操作する設備で、宮原(みやばる)の管制センターにある
  3. LCSが打上げ19秒前に姿勢データの監視を開始。ロール姿勢異常を検出して停止

現時点で判明している原因

f:id:Imamura:20130830194016j:plain

  1. 地上装置の監視が搭載計算機の姿勢計算開始より約0.07秒早かったため、地上装置が姿勢異常と判定し自動停止した(正しいデータが来る前に判定を始めたため監視開始直後に自動停止)
  2. 絶対成功しなければならないと考え監視時間を短く設定していた。異常データが出たら即時に停止したいと考えたため。一方で0.07秒の時間差に十分な配慮ができていなかった。深く反省しているところ。
  3. 8月20日、21日にリハーサルを1回ずつ、合計2回行った。ほかの理由で18秒前までのシーケンスを確認。19秒前のできごとを検出できなかったのはなぜか
    • 8月20日のリハーサルではロケットを搭載した状態で初めてランチャを旋回し発射位置へ。機軸まわりの角度が変わっていき発射位置に来たときのロール角を取得。このとき初めて基準値を取得するためその値が正しいかどうかはわからない。監視の設定値、しきい値が適切ではなかったとこのときわかった。
    • 21日のリハーサルではしきい値を適正にした。天候不良でランチャ旋回を行わなかった。
  4. 単純な判定のためロール角と現在の姿勢からあとで解析できると考え監視設定値の妥当性を確認。このとき時刻ずれを考えるべきだったがそこに思い至らなかった。

対応状況

f:id:Imamura:20130830194017j:plain
地上装置の判定開始をちょっと遅らせるなどによって対応可能。ほかの監視項目でも同様の事象が起こり得ると考え、自動シーケンスを走らせ始めてからの監視項目でしきい値が正しいかを総点検したいと考えている。
すでに1回打ち上げを延期し今回で2回目。直接原因の対策だけでは済まないと考えている。JAXAの総力を挙げて徹底的に再点検、特別点検を行い安全かつ確実な打ち上げのために成功確率を上げるようチェック、100パーセントの実施を120パーセントに上げて行いたい。
点検の結果をふまえ対策し打ち上げ作業の開始としたい。
そのため次の打ち上げ時期は現時点では決められない。

質疑応答

KBS鹿児島テレビわかまつ:次回の打ち上げ時期について。ウィンドウが9月30日までと決まっているが9月のいつごろを考えているか

森田:難しい質問。すべて洗いざらい点検するためその方法、実施、結果の反映にどのくらい時間が必要か読めない状況。

わかまつ:下村文科相は9月の早い時期にと今日言っていたが

森田:早く打ちたいのはもちろんだが初号機は絶対に失敗できない。

読売新聞ながの:0.07秒のずれの原因について。タイマーの起動する時間が最初からずれていたのか、現時点でどう見ているか

森田:地上のコンピュータから起動命令を出す。搭載コンピュータに届くまでに時間がかかったと見ている。

ながの:今まで管制を近い距離からやっていた。離れたことが原因か

森田:それもあるかもしれないが演算の遅れもあるだろうし原因はひとつとは考えていない。

東京新聞ふかや:20日のリハーサルでは手動で点検したというがそのとき0.07秒の時間差が出ていたのか

森田:その通りだが我々が見落とした。リハーサル時点で出ていた。ずれがあることに思い至っていなかったため見落とした。
自動シーケンスが停止したあと解析で判明。27日の当日中、夜に判明。

ふかや:9月30日を過ぎることはあるか

森田:再点検のため不透明。われわれとしてはウィンドウ内で上げられるよう努力をしたい。

ふかや:それを過ぎるとどうなるか

森田:新たなウィンドウ設定を検討することになる。それがいつかは現時点では決まっていない。

産経新聞くさか:0.07秒のずれについて、どのくらいなら許されたのか

森田:今回は監視を厳しく設定して臨んでいた。監視を瞬時に発見することを重視。時間差がないような設定をしていた。

くさか:初号機だから厳しくというがロケットとしてはこのくらいというのはあるか

森田:厳しい自動判定が初めてなのでこれまでどうかということはない。

くさか:確認だが機体側のシステムは初物なのか

森田:搭載のコンピュータやジャイロはH-II用のものを使う。イプシロン用にマイナーチェンジ。モノとしては新しい。

くさか:リハーサルは再度行うのか

森田:それも含めて検討中。

南日本放送いわさき:20日の時点でずれが生じていたか

森田:その通り。必ず起こることが突き止められている。

いわさき:JAXAの総力を挙げて点検となると新チームを作るのか、既存のメンバーで行うのか

長田:打ち上げに関係していないJAXAの中のさまざまな部門から知識のある方を集め、違う視点から確認してもらうことを考えている。

いわさき:何人規模でいつから?

長田:有識者によるレビューをすでに始めている。チームリーダーがこれから指名されてその範囲の中で行う。

いわさき:JAXA外部の有識者

長田:現在は内部、本部のほかの部署で考えている。

いわさき:新しい不具合は出てきているか

森田:現時点では出てきていない。

■はっとり:0.07秒のずれについて。ロケット側の姿勢計算開始が遅かったということか

森田:その通り。地上の計算機が監視を始めたときには正しいデータが来ていなかった。

はっとり:計算値が届いていなかったのか

森田:その通り。

はっとり:監視値が適正でなかったとは監視がゆるかった?

森田:そうではなくて、発射位置まで行く角度の絶対値と搭載コンピュータが最初に何度と思っている初期値があり、それが2度ずれていた。飛行に問題はないがずれがあると監視設定値のしきい値を外れるため設定値を修正したというのが20日のリハーサル後行ったこと。

はっとり:監視時間を長くするのか

森田:ゆるめるということではなく監視自体は厳しいままだが監視のタイミング、姿勢データが来なければ監視しても意味がないため監視データが来てから監視を始めるようにする。

?:リハーサルが想定通り行われていたなら防げたのか

森田:悔いが残るが、21日に雨が降らずにランチャ旋回していたら検出できた

?:再々リハーサルの予定はなかったか

森田:それは打ち上げ日を遅らせることにつながる。単純な判定だったため人間があとで解析すればすむと考えた。

毎日新聞つしま:確認だが0.07秒のずれが生じた理由は

森田:主要なファクターは伝送経路にコンピュータがあり処理に時間がかかったということ。距離が増えたというよりさまざまなプロセッサの演算に時間がかかった。

つしま:地上に送られてくる間に演算をしたため…?

森田:資料2ページ目左下にLCSとOBCをつなぐラインがある。LCSからOBCへ起動信号を送る。これがLCSからOBCに届くのに70msかかったため0.07秒のずれにつながった。

鹿児島テレビ:LCSとOBCの通信に常に0.07秒のずれが起きるため対策を行うということか

森田:まったくその通り。

鹿児島テレビわかまつ:伝送時間を考慮せず同時に計算を始めてしまったということか

森田:限りなくそれに近い。地上のコンピュータで搭載のコンピュータのタイマを走らせる。その命令を受けてから搭載コンピュータは姿勢の演算を始め1秒後に伝送を開始する。それを地上コンピュータが監視する。
しかしそもそも地上のコンピュータから搭載コンピュータに命令を送ったとき時間差が生じたため搭載コンピュータが-19秒と考えたタイミングは地上のコンピュータが-19秒と考えるタイミングより70ms遅かった。

わかまつ:必ず0.07秒かかるものを検出できなかった?

森田:何回やっても同じ結果が出る。これを知るにはランチャーを旋回させなければならない。

わかまつ:原因の4、取得データの評価で監視設定値の妥当性…とあるが「0.07秒のずれに思い至らなかった」というのは

森田:気づける人がいれば気づいた。気づける人がいなかった。止まって初めて気がついた。

西日本のべ:21日は雨でランチャ旋回できず気づけなかったというが検査を除外していなければ気づいたのか

森田:その通り。20日は正しい設定値がまだなかったため監視から除外した。

?:伝送ロスなのか、演算処理の時間を考えていなかったのか

森田:物理的には両方ある。21日のリハーサル、本番前のテスト、ロケットの近くでのテストではそれぞれ違う。伝送ロスは0ではないが70ms、0.07秒というオーダーからするとごく小さい。主要な要因は伝送路内のコンピュータの演算遅れ。
それを本番までに確認できていれば止まらなかった。

(東京会場へ)

時事通信かんだ:0.07秒の遅れについて。コンピュータ的には長いと思うが「思いが至らなかった」とは

森田:こういうところにはこういう遅れがあると考えるべきだったが抜けていたというのが正直なところ。

かんだ:地上側とOBCの同期について、監視のタイミングがシビアでないから顕在化しないだけか

森田:実際には自動監視の部分以外では遅れがある仕様で設計している。設計には誤りはなく設計通り機能したが監視タイミングの設定のみ遅れがあることについて考えが抜けていた

かんだ:監視項目が本番と同じではなくもれがあったがそれをチェックするしくみはあったのか

森田:もれとは思っていない。監視の練習ができなかったのは確かだがOBCと地上のコンピュータのログを分析しリハーサルと同様の確認ができたと考えていた。確認自体が抜けていたのではなく確認の方法、確認の観点が不十分だった。

フリーランス大塚:0.07秒の遅れはLCSからOBCへの片道で0.07秒なのか往復か

森田:片道で0.07秒。OBCを起動するのに0.07秒。その時点で監視値にタイムスタンプがつくので戻り値に遅れは出ない。
タイマーが起動した瞬間に「この時刻のこのデータ」として送られてくるため片道の遅れだけが出てくる。

大塚:原因となる装置はどんなものがいくつなのか。伝送経路途中のエクステンダやリピータなどが原因か

森田:大きなファクターはLCSからM台地のOBCへ向かう線があるがロケットのROSE、データがROSEを通してOBCへ行くようになっている。ROSEの演算に多くの時間がかかった。エクステンダやリピータなどは無視できる。

大塚:リハーサルのとき適正値でないことに気づいたのはいつごろか。正しい設定値は。

森田:リハーサルの直前。正しい値は0±1度、正しい監視設定値は2度を中心として±1度(つまり1度〜3度)。
発射の瞬間に
正しいロール角、発射台の上に来たときの正しいロール角は2度。時間差があったため2度という数値が0.07秒遅れてきた。監視直後は演算がまだ始まっていなかったため0度という数値が帰ってきた。2度の±1度ということで1度〜3度におさまるかどうか監視していたところへ0度という数値が返ってきたため止まった。

大塚:ピッチとヨーはもともと0度が正しかったため返り値が0でも異常にならなかった?

森田:その通り。

日経BPとみおか:27日の会見で18秒前までしかリハーサルできない理由について使い捨ての熱電池に言及していたがそのコストは
今後リハーサルをするとき熱電池を起動するところまで行うのか

森田:コストはのちほど。リハーサルで熱電池の駆動を行わない最大の理由はコストではなく作業。熱電池は小さな火薬に火を付けてあたためて電力を発生する。使い捨て。取り替えるのに最低2日かかる。リハーサルで使うとそれだけで作業に2日かかるということでM-Vの時代から熱電池の起動はリハーサルでは実施せず工場での組み立て過程で試験している。
コストというより時間軸で考えている。

とみおか:2日間について。それで試験できるなら試験しては

森田:熱電池は使い捨てのため実物の試験にはならない。飛ばすものと違うもので試験しても意味がないと考えた。

とみおか:熱電池が変わってもその他のシステムが稼働するかどうかは熱電池の個体差に関係ないのでは

森田:ロール角の試験はランチャを旋回させなければならないため行う必要がある。熱電池は電気を流してどう発生するか試験する。これは整備塔の中や組み立て途中の工程でも可能。いつ試験しても同じという観点から早いうちに熱電池と監視装置を組み合わせた試験を組み立て工場で行っている。

NHKこぐれ:リハーサルについて。直前にトラブルがあったわけだがチェックするべきものを見落としたのか、トラブルがほかにあったため見落としたのか

森田:トラブルがあって見落としたのではなくそもそも考慮していなかったのが実態。あわてていてすっとばしたというものではない。

こぐれ:その値を見る人がいなかった?

森田:工場から始まって自動監視のシステムをちゃんと通るかどうかを点検してきた。ロール角度でいえば0度でかまわない値で試験してきたため0.07秒の遅れがあっても(返り値は0で同じため)検出できなかった。

こぐれ:通信時間がかかったということを想定していなかったのか、想像したより大きかったのか

森田:前者です。

東京新聞さかきばら:今回自動停止はROSEの演算時間を考慮していなかったのが主な原因か

森田:OBCの中にもプロセッサがありそこでの遅れもある。ROSEが入っていたから悪かったというわけではない。ROSEが入っていなくても70msよりは小さいが20〜30msという遅れが生じ打ち上げ停止に至っただろう。ROSEのせいで中止したわけではないということはくれぐれもお願いしたい。

さかきばら:M-Vまではどうしていたか

森田:自動監視していなかったため人が目視でテレメトリを見ていた。

さかきばら:(…)

森田:遅れをもって飛んでいったとしても飛行に影響はなかっただろう。

さかきばら:延期にともなってコストが上がる部分があれば

長田:一日あたりの正確な金額はわからないが、隊員によるトラブルシュートが必要。陸上、海上への監視なども必要。コストは増える。

読売新聞ちの:0.07秒の遅れを考慮して監視について、ソフトウェアで対応するのか

森田:監視設定のしきい値や監視のタイミングはもともとすべてソフトウェアで対応。ハードウェア的に特殊なことは行わない。

ちの:自動点検のトラブルは自慢の機能にトラブルということか

森田:人間がわからないことを監視するという意味ではきちんと機能した。
完全に自動で監視する打ち上げはイプシロンロケットの最大の開発要素。監視値が厳しかったため今回のようになったが新しいことの実現のために今後しっかり検証、対策を行っていきたい。

ちの:2号機以降に設計変更やコンピュータの取り替えなど大幅な手直しは必要になるか

森田:今回の事象に関しては搭載コンピュータ、地上のコンピュータについて設計の誤りはない。ハードウェア的にも機能が正しく発揮された。唯一監視システムのソフトウェア的な問題が出た。2号機についてハードウェア的な変更はない。

朝日新聞はたの:資料2ページの図に従うと起動信号がOBCに届くのに0.07秒かかったというがLCSに戻るときまた0.07秒遅れるということはないのか

森田:OBCのタイマがスタートするとタイマ時刻がデータにくっついてくるため帰りの遅れは加算されない。

はたの:打ち上げ中止の影響について、ロケットの部品の中で中止によって交換が必要なものはあるか

森田:現時点ではただちに交換が必要な部品はない。点検から時間がたつと再点検という項目はあり全体の洗い出しをしているところ。

はたの:SPRINT-Aについて。数時間空気にさらされているが影響はあるか

森田:発車直前まで空調で清浄度の高い空気を送っている。発車の瞬間には空調を止めるが今回は中止したため空調が止まることはなく衛星に影響はなかった。

共同通信すえ:確認。0.07秒についてはソフト的な問題ということで技術的には難しくないのか

森田:原因がこれだけと明らかになればソフトウェア的に軽微な修正ですむ。

すえ:その部分に限っていえば1日から数日でできるのか

森田:それだけなら1日2日ということになろうかと思う。しかし延期が2回目ということでほかになにかないかということで少しお時間をいただきたい。

すえ:再点検というと機体をばらしてということはあるか

森田:リハーサルでX-18秒まで確認できている。それをふまえて確認するため、リハーサルで抜けていた項目はないか、X-18秒以降で問題はないか確認するため機体をばらしたりはしない

NHKはるの:複数のコンピュータの演算処理で0.07秒というが具体的にはどれを指すのか

森田:主要なファクターはLCS、ROSE、OBC

はるの:先日の中止後の記者会見では計算機としてのROSEが原因ではないと考えていると言っていたが今までの説明だとROSEが原因と思えるが

森田:それは違う。ROSEに問題はない。演算処理の遅れを0にする装置は作れない。遅れを反映するしくみを作れなかったのが問題。

はるの:当然ある遅れを事前に盛り込めなかったのはどうしてか

森田:たいへん難しいが気づかなかったということ。

ニッポン放送はたなか:打ち上げ前のブリーフィングで自信のほどについて、自信の大きさに対して不安はごく小さいと言っていたがランチャ旋回ができなかったのが原因のひとつか

森田:ランチャ旋回がなくても人間が確認できると思っていたがそうではなかった。今回検出できなかった不具合がリハーサルを通した過程で唯一見落としていたこと。さらに広い視野で特別点検を行うことでイプシロンロケットへの自信はゆらがないと考えている。

はたなか:27日にすぐに対応できる見通しと言っていたが今は意外と、ということはあるか

森田:あのときは原因をすぐに特定できて改修できると考えてそう言った。ことここに至ると原因を取り除けばよいということではなく失敗できない初号機の打ち上げと考えると直接原因への対策ではなく同じような事象が隠れていないか、冷静に第三者の目を含めて特別に点検を行い100パーセントの自信を120パーセントにするべく少し時間をいただき確実な打ち上げにしたい

はたなか:見通しが甘かったという認識はあるか

森田:はやる気持ちをおさえきれなかったというのが正直なところ。見通しが甘い、厳しいということではなくいま一番重要なのは原因への対策を講じてすぐ上げるのではなく、あらゆるできることを行い打ち上げること。なので見通しが急に変わったということではなく今はこういう結論に至った。

フリーランス秋山:先ほどの話の中で今後の対策についてOBCに姿勢のデータが届いてから監視を始めると言ったか

森田:その通り。姿勢のデータが地上のコンピュータに届くタイミングで監視を始めるよう設定を変える。

秋山:その場合別の理由で姿勢データが届かないとまた問題で、ソフトウェア的に新しいことを盛り込むのか

森田:監視開始タイミングの話なので大変な改修ではない

ライター喜多:チームの皆さんはへこんでらっしゃいませんか。リーダーとしてモチベーションを維持するためになにをするのか

森田:打ち上げの27日に向けて緊張しながらやってきた。中止で一番つらかったのは打ち上げ管制隊のみんな。総点検で厳しいところに置かれているのは確か。しかし目標はイプシロンロケットの成功。そのために7年間かけてきた。ここにきての数日の苦労は7年間に対しては短い。決して下を向いたりしないよう鼓舞していきたい。

内之浦会場へ)

産経新聞くさか:慎重にことを運んで行いたいということだが少なくともこのくらい時間がかかるという見通しかヒントのようなものは
(今村註:これはつまり「私は内之浦からいったん撤収するのがいいんでしょうか」という質問でした)

森田:ですからそういうところをしっかり見きわめてお話しできればよいのだが特別点検はこれから始まるためちょっと難しい。冒頭往生際の悪いことを言っていたが時間を無制限にかけるわけではなく、自信を120パーセントに高め、ウィンドウ内におさまるよう打ち上げたい。
打ち上げ管制隊はチーム一丸となってがんばりたい。

共同通信ふかや:OBCは機体のどこにあるのか

森田:第3段計器部に載っている。ただし初号機はオプション形態のため第3段計器部は第4段にある。

ふかや:姿勢センサと同じ場所についている?

森田:その通り。

ふかや:検証チームは何人くらい

長田:わたしはチームリーダーではなくいま指名されているところ。チームリーダーが必要なメンバーを招集して規模が決まる。数人規模ではなく十数人規模ではないかと思う。

(以上)