NECが5億円支払いへ 観測衛星「ひとみ」失敗はプログラムミスだった
コメント
注目のコメント
事故原因は
http://www.jaxa.jp/press/2016/06/files/20160614_hitomi_01_j.pdf
比較的分かりやすく，興味深い内容．
慣性基準装置とスタートラッカをカルマンフィルタで融合して姿勢決定しているが，想定していなかった（？）モードの切り替えで，観測誤差が残った．オンボードの計算機は自分は回転運動していると勘違い．リアクションホイールで止めようとするが，観測誤差がゼロにならないので，リアクションホイールの能力限界まで回転．さらに回転を止めようとスラスタを噴射．ここでとどめの一撃．スラスタ制御パラメータに誤りがあった．これによって，より高速で回転し，遠心力で太陽電池パネルが引きちぎれて，終了．
バラバラになった衛星はデブリになったが，大きな物体は大気圏に再突入して燃え尽きた．この異常発生メカニズムは非常に興味深い。マネジメントレベルでいろいろと見直す点はあれど、事故の直接的な発端は土屋先生が示してくれているPDFのp.34のC.【想定漏れ事象】スタートラッカがすぐに捕捉モードに移り、IRU誤差推定値の更新が止まったこと。
この事象は、コンポーネントの故障を発端とする従来のハザード解析手法FTAでは想定しきれない。これは、ソフトウェア中心の複雑なシステムでは典型的な「プロセスモデルの不一致」。誰も故障していないのにコンポーネント間の誤ったインタラクションによって危険な状態が発生している。
正直言って、現代の複雑システムには、もはやFTAではカバーしきれない潜在的事故原因が多く内在しており、FTAという手法が限界を迎えている。手前味噌になるが、僕がMIT時代に開発に携わっていたSTPAというハザード解析手法なら、ひとみの事故原因は想定可能だった。
https://arc.aiaa.org/doi/abs/10.2514/1.A32449
STPAは、FTAで発見しうる全ての事故原因をカバーし、かつこの事例に見るようなシステム事故も洗い出すことが可能。ただし、ハザードがわかっても、それを緩和する設計を考えるのが次の難題。設計において、あるハザードをクリアしても、別のハザードが混入してくることはよくある。この手のプログラムは、あらゆるシチュエーションを想定して、相当なバリエーションのテストがなされていると思うわけですが、やはりそれでも抜け漏れはあり、さらに現実にそういう想定外のシチュエーションが起こってしまうんですね。
