投稿コーナー
先号　　次号

「きぼう」日本実験棟開発を振り返って (9)
―搭載コンピュータの安全制御―

宇宙航空研究開発機構客員／PMマイスター　長谷川　義幸　[プロフィール]　：8月号
　1995年、私が「きぼう」開発プロジェクトの電気通信ソフトウェアグループのマネジャーになった頃は、NASAが開発する統合システムソフトウェアと「きぼう」のソフトウェア間、「きぼう」内の各制御装置に搭載されるソフトウェア間のインタフェース仕様の調整や、ソフトウェアの開発手法の標準化、設計文書の整備と文書間のトレーサビリティの確保など、ソフトウェア要求や、開発管理要求をNASAと調整していた時でした。NASAは、これらの調整に加えて、衛星開発にはないコンピュータシステム(CBCS：Computer Based Control System)安全要求を参加国に提示してきました。

図 1．ハザード対処のイメージ 　きぼうの開発では、事故をもたらすハザード要因を解析し、システム設計の段階でなるべく除去し、除去が困難な場合には、危険度に応じて、リスクを最小化する設計や、故障許容(故障や誤操作の発生を想定した上でハザードを発生させない設計。想定する故障や誤操作の範囲(数)により大掛かりで複雑化する)を考慮した設計で対応していました。この設計に対し、ハザード制御にコンピュータが関わる場合には、さらにCBCS固有の安全要求を適用するというものでした。

　私が給湯室で自分のコップにお茶を注いでいる時に、NASAとの交渉担当だった若いエンジニアが、「交渉が難航していて、最悪、異なる複数のコンピュータを用意しなくてはいけなくなるかもしれません。」と暗い顔で報告に来たので、「なぜ衛星開発では当たり前の一種類のコンピュータの冗長構成ではだめなのか？　安全確保にもいろいろなやり方があるはずだ。」と返答しました。「きぼう」は、その当時地上でも急速に発達していたネットワークの考え方を持ち込み、メインのコンピュータが通信ネットワークを介して複数のコンピュータと情報をやり取りしながら「きぼう」の制御を行う構造を採用していました。これまでの衛星とはコンピュータの数も搭載されるソフトウェアの規模も異なり、それらをさらに全て冗長化する設計は、重量、コスト、スケジュールから見て不可能に近いものでした。私たちは、「きぼう」のコンピュータ開発で四苦八苦していた時でした。

　NASAは、異なる複数のコンピュータによる相互監視を行っていたスペースシャトルの安全思想に基づいた要求「ハザードに関わるコンピュータは同じハザードの他の制御(例：インヒビットの解除)をしてはならない」の適用を要請してきました。これが適用された場合、「きぼう」のほとんどの指令は「きぼう」のメインコンピュータ経由で行われており、基本的に宇宙飛行士か地上管制官が操作するため、「コマンド送信によるインヒビット制御」ができなくなるものでした。
　NASAと調整する中で、CBCS安全要求が登場した背景は、1960年代から1970年代のアポロ計画やスペースシャトル計画で生じたコンピュータの異常による事故の反映であることが分かってきました。コンピュータの異常により想定外のハザードが生じ、組み込んでおいた自動処置が実施されたことにより反って事態が悪化した経験から、コンピュータやソフトウェアの異常を想定し新たに検討された要求でした。開発担当のエンジニアは、安全信頼性グループとチームを組んで、何度もヒューストンにいき安全要求の思想を1つ1つ吟味して現実的な設計にすべく粘り強く調整を行いました。

図 2．「非動作要求機能」における制御経路分離設計の概念図 　光明が見えたのは、コンピュータ内での制御パスの独立性(図2)という概念が導入されてからでした。NASA側としても、巨大システムのISSのハザードを異なるソフトウェアを搭載した計算機で制御することは、システムが冗長になり過ぎ効率が悪いことから、シンプルかつコンパクトな計算機システム設計を実現させたいという思いがあったようです。

　調整を重ねた結果、インヒビット制御を構成する経路(実際にインヒビットを解除するコマンドを出すコンピュータを起点として、末端にてコマンドを解釈しインヒビットを解除する計算機やその先の電気回路までを一つの経路と定義)と、他のインヒビット制御の経路との独立性を示すことにより、「1つのコンピュータであっても複数のハザード制御を許容する」設計が可能となり、そのための要求が追加定義されることとなりました。

　開発中にNASAは新たな安全要求を出してくるので、現設計との対応を議論し、同時に、要求としての文言も何度も推敲を繰り返し誤解や新たな解釈が発生しない様に調整を行いました。
その後、この制御経路を分離することで安全要求を満たす考え方は、ISS全体に広がりほぼすべてのコンピュータの構成に影響を与え、コンピュータの内部状態だけではなく、物理的な信号系統を意識した系統制御によりハザードを防ぐなどの現実的な設計要求になっていきました。

　後日談ですが、NASAは声高に「ソフトウェア内部状態を用いたインヒビットをハザードコントロールのインヒビットとしてはならない」と主張していたのに、米国実験棟の設計レビューで、インヒビットとしてソフトウェア内部変数の値が記述されている事例が見つかり、日本のエンジニア同士顔を見合わせる場面もありました。日本人は真っ正直にルールをとらえてキチンと処理しますが、アメリカ人はルールを作る人とそれを実行する人は別なので、ルールは建て前と考え、現実の制約に合わせてフレキシブルに対応するようです。安全は、これをやれば絶対十分ということはなく、エンジニアリングジャッジに基づき妥協することが求められる分野ですが、要求の本質を解釈し、より安全な設計を目指すという事が非常に大事であり、日米双方でより高い安全性を求めて試行錯誤した日々でした。

参考文献
( 1 ) 酒井純一ほか、「国際宇宙ステーションにおけるソフトウエアの安全・開発保証管理」、
PMシンポジウム2007予稿集pp.315-332、2007年
( 2 ) 酒井純一ほか、「国際宇宙ステーション「きぼう」の技術解説、第18章フライトソフトウエア設計」、
日本航空宇宙学会誌、2003年1月

ページトップに戻る