2017年10月17日

事例:天文衛星「ひとみ」の事故


初めての方はこちらを「はじめに

少し前に表題の件についてNECが五億円を支払うというニュースがありました。
NECがJAXAに衛星ひとみ破損で5億円支払い - 産経ニュース
この件に関して詳細な内容が書かれたサイトがあったので、今回はこれを事例にして今まで述べてきた内容を示してみたいと思います。なお目的は「ひとみ」の事故の真相を調べる事ではなく、具体的なものを通して今までの記事で述べてきた内容の理解を深める事です。

トラブルの始まり


記事は以下になります。
X線天文衛星「ひとみ」はなぜ失敗したか(1) 「要求以上の要望」の罠 | sorae : 宇宙(そら)へのポータルサイト
この記事によればトラブルの始まりは簡単に言えば以下の様なもののようです。
1.「衛星の姿勢を実測するスタートラッカ(STT)が不意にリセット」
2.対処が色々まずくて姿勢が大きくずれる

記事を読む限りだと1のエラーに対して2の色々なエラー処理があまりにも甘いように思えます。1の現象自体は珍しいものでは無い様で
STTのリセット自体は珍しいことではなく、「ひとみ」打ち上げ後1か月あまりの間に20回も起きている
と書かれています。

そんな頻繁に起きる現象の対処に、こんなに重大な問題が存在しているというのは正直言ってソフトウェアを開発する普通の感覚からすると設計の品質が低過ぎるように思えます。「低過ぎる」というのは衛星というのは非常に高品質な設計が求められるものだと思っていたので特にそう感じるのかもしれません。とにもかくにも自分自身はこの2のエラー処理の内容を知って非常に驚きました。

なので多分これは設計のミスという事ではなくて開発側(NEC)が言われた通りに作ってしまったという事なのではないかと思えます。言われた通りというのは「要件は誰が固めるべきなのか」に書いた意味合いで主体性を発揮しなかったという事です。冒頭のニュースの記事を読むとJAXAとNECで法廷で争っていたようなので、まさしく記事内で指摘した通りの展開になっています。もしその通りならばこの事故は同じく記事内で指摘している「責任を負わなくて良いという気楽さと引き換えに、関わる人すべてを不幸に陥れかねない」事態になってしまったという事なのかもしれません。

直接の原因


更に次の記事には実際に衛星が壊れてしまった直接の原因が書いてあります。
X線天文衛星「ひとみ」はなぜ失敗したか(2) 引き継ぎ不足が招いた運用ミス | sorae : 宇宙(そら)へのポータルサイト

これを読むと先程の2のエラー処理がまずくて姿勢がおかしいという状態を回復する手段は用意されていて、最終手段として手動で姿勢を戻す事になっていたようです。この辺の設計はさすがだと思います。別途記事を書く機会があると思いますが、ソフトウェアに限らない事ですが何が起きても最後の最後は人の手で対処できるようにする事は安全性を考える上で非常に基本的で重要な考え方だと思います。

さて、手動で操作をすればおかしな姿勢から回復できるはずでしたが、実はこの時の操作こそが衛星を破壊した直接の原因という事のようです。この時の流れはまず姿勢に関する情報をツールで算出して、その値を衛星への指令として手入力するという流れです。ここで衛星への指令は「絶対値」(座標?)を入力しなければならなかったものをツールで算出されたマイナスの値をそのまま入力して指令を送ってしまったという事のようです。その結果姿勢が回復するどころか逆に作用してしまい「ひとみ」は高速回転してしまい分解に至ったという事です。

この件について驚かされるのが以下の様な点です。
手動の手段がまるで開発者用の裏技の様なものだった事

「絶対値」などという誤り易いものに何のガードも掛けていなくプログラム的に全然配慮していないというのは製品レベルではなかなか考えにくい事です。SE用のツールのようなものだとしっくりきます。しかし手順書も公式なものは存在しないという事ですからSE用のツールにすら成り得ていなかったのでは無いかと疑いたくなります。

設定内容が正しいかテストをしていない事

我々ならば仮に正規の手順で作成したのではなくて急遽手作りしたようなものだとしてもそれを正規の製品に適用するならば必ずテストは行うのではないでしょうか。自分の場合ならばそれこそ前の「検証システムのすすめ」で書いたように「検証システム」を流します。例え送信する値が間違っていたとしても事前にテストが出来ていれば間違いに気が付いて正常な値を送信できたはずです。おそらくテストをする環境自体が無くテストのしようが無かったのではないでしょうか。少なくとも「検証システム」は無かったという事にはなります。

手動で命令を送信するのが20時間通信が途絶えるタイミングだった事

我々で言えばトラブル時にパッチを現場のSEに送信してそのまま帰ってしまう様なものです。パッチをあてた結果の確認をしないとしたら驚くべき事です。記事を読むとその気になれば日本以外の国経由で衛星の状態をトレース出来るようなのでそもそも「確認する意思」が無かったと思われます。こういう通信が途絶える状況は「いつかはやらなければならない事」とは書いてありますが、いきなりぶっつけ本番みたいなハードルの高い事をやる必然性は良く分かりません。

ここまで読んでくると個別の問題ではなくそもそもプロジェクト全体が品質に関して意識が低いように見えます。

組織的な視点


仮にプロジェクト全体の問題ならば背景として組織的な問題もあるのが普通だと思います。組織的な話についてはこちらの記事に更に詳しく書いてあります。
X線天文衛星「ひとみ」はなぜ失敗したか(3) ISASの独自性とOne JAXA | sorae : 宇宙(そら)へのポータルサイト

今回の「ひとみ」を推進したのはJAXA内の宇宙科学研究所(ISAS)という組織です。ISASの前身は東京大学宇宙航空研究所で、日本の宇宙開発の父と言われる糸川英夫さんが研究していたところです。JAXAはISASと宇宙開発事業団(NASDA)と航空宇宙技術研究所(NAL)の三組織が統合されて一本化されたものですが、実質的にはNASDAが母体となっているようです。名前等からも分かる様にNASDAは宇宙を開発して商売等をして行こうという組織なのに対しISASは研究が目的です。実際「ひとみ」もX線天文衛星です。

そして記事によるとISASはJAXA内でちょっとした独立した扱いに成っていてJAXA全体の標準が適用されていなかったようです。今回の対策として「これからは適用する」と書いてあります。なのでISASの研究者的なプロジェクト推進の感覚とNASDAの商業的なプロジェクト推進の感覚とは違っていたという事が推測されます。そう考えると「安全性に対する意識が低い」という印象に合点が行きます。ここまで見てくると結局この問題はJAXAによって組織の統合を図ったものの統合しきれていなかったというのが最も根本的な原因なのかもしれません。

ただ、これもまた別途記事で触れる事があると思いますが組織は遊びの余地を残しておかないと、安定はしますが飛躍しにくくなります。遊びというのは高い知能を持った動物しか行わない行動で、新しいものを生み出す源泉です。それと同時に失敗の源でもあります。なのでいかに失敗を織り込めるかという事は組織にとっては重要な事です。事実、人類初の偉業を成し遂げた「はやぶさ」を推進したのもISASなのです。

一覧


メニュー

関連


事例:ボーイング737MAXの墜落事故
検証システムのすすめ
要件は誰が固めるべきなのか
事例:ANAシステムトラブル


記事を広める



posted by 善 at 22:18 | Comment(0) | 事例 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。