オンラインジャーナル/メッセージ

先号　　　次号

「宇宙から地上へのメッセージ」
－安全性・信頼性は宇宙で始まり、地上で活用されるー

長谷川　義幸：9月号

第　6　回

今回は、ハザード防御のための設計として「非作要動求機能の設計」について説明します。
(2)非作動要求機能の設計
ロボットアームの関節モーターが意図しない動きをすると実験室に衝突し亀裂を起して船内の空気が漏洩するカタストロフィックハザードになる場合があります。非作動要求機能の設計は、このような意図しない機能の起動がハザードを発生させる場合に備えて抑制機能(インヒビット)を設定して防ぐ方法です。その制御方法は2つあります。

●1つ目の方法は、図1に示すようにハザードを抑止する複数のインヒビットを複数のコンピュータで制御する設計(故障伝播抑制設計)です。この方法の特徴は、「インヒビットの制御を別々なコンピュータが行うこと」、「インヒビットが独立して3つ存在すること」、「それぞれのインヒビットを解除するコマンドが独立していること」です。　この方法は、スペースシャトル搭載実験装置に要求されているものです。

●2つ目の方法は、図2に示すようにハザードを抑止するインヒビットの制御を1台のコンピュータで行う設計(制御経路分離設計)です。この方法はコンピュータ内でコマンドの制御パスが独立していることです。単一のコンピュータ故障がすべてのインヒビット制御を不可能にしますが、意図せぬ動作は防ぐことができるので、ハザードとはなりません。ハザード制御のためのインヒビット解除の時は、人間による誤操作を防ぐために2人の搭乗員の操作により行うことにしています。ロボットアームの意図しない動きへの対策は、モーター動作を抑制するために3つのインヒビットを電源とモーターとの間に挿入しています。もちろん電源以外でも、例えばステップモーターであれば動作クロック信号もインヒビットとして採用できます。

　この設計のキーポイントは、「ハザード発生への対策として複数のインヒビットを１台のコンピュータで制御する。」「各インヒビットを制御する経路を論理的に分けること。」です。　宇宙ステーション日本実験棟をはじめ、多くの実験棟のソフトウエア安全設計は、この方式を主に採用しています。

■ コンピュータ制御システム安全要求

コンピュータ制御ソフトウエアへの安全要求を以下にまとめます。

(1) 一般要求
・安全に起動・停止し既知の安全な状態になること。
・オーバーライドコマンドは、少なくとも2つの独立したアクションによること。
・決められた手順以外のコマンドを棄却するとともにコマンド実行前検査を実施すること。
・異常やメモリの不正変更を検知し、安全な状態となること。
・データの有効・無効のチェックを実施し無効の場合，安全化を行うこと。

(2) ハザード防止要求
・ハザードを引き起こす可能性のある機能は、作動要求機能と非作動要求機能に識別し、その、機能要求を設計に反映させること。

コンピュータハードウエアもソフトウエアの設計・製作も、人間がどこかで関与しています。　「どんな優秀な人間でも、必ず、どこかで過ちを犯している」　ことを前提にした防護手段を仕組みにとりいれる手法(What if の手法)がここにあります。　NASAは、ハザードを引き起こす可能性のあるソフトウエア機能を識別して、上記の安全要求が満足できるような設計をするように、国際宇宙ステーション安全技術要求(SSP50038)をまとめ、NASA関係部門と国際パートナーに課しています。　

　NASAの宇宙ステーションプログラムでは、システムの不必要な巨大化を抑制するため、ソフトウエアの設計と検証を十分行うことを条件に高機能コンピュータの使用を認めています。　異なるコンピュータで制御する代わりに、制御径路分離されたソフトウエアを使用するので、その検証と評価を厳しくチェックする必要がでてきました。そのために、開発とは独立した部門がソフトウエア独立検証及び有効性評価(IV&V：Independent Validation & Verification)を実施することを要求しています。

宇宙ステーション一口メモ： 1986年から始まった国際宇宙ステーション構想計画フェーズでの国際調整では、欧米の事前調整が行なわれ、公式の場でその結果を押し付けられることがよくあったそうです。NASAは、プロジェクトの目的である運用や利用の構想について想像力を働かせて、その時点で想定できる要求仕様を高く設定、その技術的な実現の可能性を評価し、スケジュールと費用をトレードオフして、仕様を満足できなければ要求仕様を下げて再設定します。　想定される不具合の対処を含めて技術部門の経験者を集めて注意深く検討、そこを開発の前提とします。　この検討や評価の会議では、NASAおよびコントラクターは自分の意見をどんどん発言し議論を重ねてゆきます。作業の方向を決めるとまず動きだします。
　　一方、日本のやり方は、実現可能な要求仕様を予め評価し、目標コストを定め、そのコストに入るように設定します。そして、開発の達成度を見ながら設計見直しを行い、仕様の引上げ、引下げを行います。さらに、日本人は発言に慎重ですから、　この欧米流の仕事の進め方に当初は慣れておらず、英語のハンディーもあり議論の中に入ってゆくのが難しい状態でした。　NASAは、仕様設定後も、運用要求が変更されると、すばやく設計の見直しを行い国際合意した事項であっても、実情にあわせて変更します。政治情勢やコストで要求仕様の実現性が無い場合には、国際合意の開発事項でも、開発途中で中止することもあります。現在は、日本も事前の根回しや議論の進め方が欧米流になってきています。