知能化の敷居を下げるDESTINY : スクリプトでの自律運用(<特集>宇宙に挑む人工知能技術)

(1)

1．は　じ　め　に

遠隔探査装置についての研究・実用は数多くの分野で実施されており，知能化が課題である対象にはローバー， UAV（無人飛行機），AUV（自律潜水艇），宇宙機などがあげられる．特に人のアクセスが本質的に困難であり，探査機との通信が必ずしも自由ではない宇宙や深海探査においては，人の代わりに作業と判断ができる知能化技術が期待されている．宇宙におけるこの分野の活動で最も先行しているのは米国である．ミッションそれ自体に AI 技術の検証が含まれているものは，古くは Deep Space 1（DS-1） [Muscettola 98]，Earth Observation 1（EO-1）[Chien 04]から今後の James Webb Space Telescope（JWST） [Balzano 06]まで複数存在している．2000 年当時の先端技術検証を目的とした DS-1 ミッションでは運用にいろいろと制約があるイオンエンジンの取扱いや宇宙機の状態監視に積極的に AI 技術を導入することを目的としていた．また EO-1 はノミナル運用期間が終了した段階で，搭載ソフトウェアを大きく改変し，搭載系での観測データ処理および運用計画の変更を自律的に行うことを試み，火山噴火や洪水の早期検知などの検証を行った．さらに JWST では，地上運用者が介在しない状態で，観測計画の部分的な自律変更を行ってむだ時間を削減させ，取得データ量を減らさない工夫がなされており，実用に供される予定のようである．宇宙機の知能化に対する上記のような試みは，宇宙開発における地上装置や通常の社会生活における情報処理分野への研究結果の応用例と比較して少ない．その大きな理由は，宇宙機では利用できる計算機のリソースが少ないことである．これは宇宙開発分野すべてにおいて共通に抱える本質的な問題である．宇宙では利用できるエネルギーが地上と比較して少なく，耐環境性能，特に耐放射線能力が強い部品が求められるので，地上で利用される計算機と比較して 10 年は遅れているものを利用せざるを得ない．知能化技術は本質的に情報処理技術なので，情報処理速度や利用可能メモリ容量が少なければ，最先端ばかりの研究成果ではなく，一昔前の結果すら応用されない．この状況は日本においても米国においても同じだが，日本においては特に宇宙機搭載機能の知能化については検討例が少ない．その理由は計算機リソースの問題以上にそのコストにある．宇宙機開発には数百億円という巨額費用が必要で，開発期間も数年から 10 年になってしまう．ゆえに開発できる宇宙機の数が少なく，だからこそ宇宙機に何よりも安全を確保しようとする姿勢が優先され，結果的に既存の技術で実現できるミッションを選択してきたことによる．つまり，高度な知能化がなければ実現できない宇宙機ミッションはそもそも考察されず，ゆえに搭載系の知能化についての需要がなかったのである． 2010年に地球に帰還した「はやぶさ」の後続機「はやぶさ 2」は現在開発中であり，今後はより高度な深宇宙探査機が計画されると予測される．また，深宇宙探査機でなくとも，JAXA の科学衛星は大型化しているので，ミッション運用は複雑化していく．そのため運用における人の判断を減らす工夫は地上にある情報処理装置と同様に搭載系でも必要となるのは確実である．そこで本稿では，現在宇宙科学研究所で検討されている深宇宙探査の工学技術実証ミッションである DES-TINY [Kawakatsu 12]を題材にとり，宇宙機の知能化の一つの道筋案について説明する．その中では，ある特定のアルゴリズムの提案や機能検証を行うのではなく，着眼点の次元を一つ上げ，自律化機能を提供するためのインフラ技術を提案し，それで知能化技術適用を促すことを考える．具体的には宇宙機に搭載計算機に「スクリプトエンジン」と呼ばれるプログラムの実行環境を実装

知能化の敷居を下げる DESTINY

─スクリプトでの自律運用─

Commanding Spacecraft by Script as Mission Operation Intelligence

─ The Onboard Autonomous Mission Managing Mechanism in

DESTINY Mission ─

福島　洋介

宇宙航空研究開発機構宇宙科学研究所

Yosuke Fukushima Institute of Space and Astronautical Science（JAXA）． [email protected]

Keywords:

spacecraft, deep space mission, onboard autonomy, script self-commanding. 「宇宙に挑む人工知能技術」

(2)

し，その上で動作するスクリプト（テキストで記述されたプログラム）に従って宇宙機のテレメトリを参照し，また宇宙機にコマンドを発行できるという仕組みを創出する．

2．DESTINY ミッションにおける自律運用

2･1　宇宙機を知能化することで運用の自律化を目指す宇宙機を知能化・自律化させる研究の動機は次の 2 点である．すなわち，宇宙機の高機能化（成果取得）という工学的な動機，そして宇宙機運用の効率化（コスト削減）という経済的な動機である．まずは高機能化の側面での利用について．現在実利用されている AI 技術の多くは「情報抽出」に関することである．例えば観測装置から取得したデータの中に「価値のある情報」を探す画像処理，売れ筋商品の把握などのマーケティング解析，あるいはクレジットカードの不正使用発見などがある．これらは一般生活を支える機能である．これを宇宙機の問題に読み換えると，観測データからの特徴抽出処理，システムのハウスキーピングデータ（HK データ）の状態監視 [矢入 11]，あるいは姿勢制御機器の故障検知に対応する．つまり，宇宙機においても有効であり，実際そのような利用が試みられている．次に効率化の側面での利用について．地上で実施される宇宙機の設計解析や取得データの情報解析など宇宙以外の分野と同様に各種の知能化技術は検討されてきた．搭載機器において故障発生時の冗長系自動切換え（FDIR）[小島 04]，宇宙機の異常発生後の IF-THEN による制御モードの状態遷移管理などは宇宙機の基本機能として一般的に利用されている．しかし，深宇宙探査ではこれだけでは不十分であり，地上から人の指示なしでミッションを遂行できる判断力や計画変更能力をもった自律化が求められている．なぜなら深宇宙探査では通信速度が毎秒数ビットということもあるくらい制約が大きく，また距離によっては往復数十分という通信時間遅れが存在しているので，地上からの直接操作は事実上不可能となるためである．耐放射線性が高く処理速度が向上した CPU やメモリは登場してくるだろうが，宇宙機を知能化をさせ自律化を向上させる技術には，上記の高機能化と効率化を同時に併せもち，かつ，深宇宙探査機の多くで利用できるインフラ技術の追求も必要である． 2・2　深宇宙探査の運用を汎用的に支援する技術とは DESTINYはそのミッション定義上，特定の科学・工学ミッションを実施することに最適化された宇宙機ではない [川勝 13]．深宇宙探査機の打上げには必ずしも適さないイプシロンロケットを使い，JAXA の小型科学衛星バスという地球周回衛星向きの衛星バスをベースとした，低コストで深宇宙探査機を実現させる一つのプロトタイプの提案である．そのため，特定のミッションに最適化した宇宙機の知能化機能の実証を行うのではなく，今後の深宇宙探査機で広く利用できるインフラ技術を試すことになる．知能化された深宇宙探査で必要となる共通機能を表 1 に示す．動的計画変更以外は現在でも限定的ではあるが実現されている．しかし，それらは緊急時に宇宙機をセーフモードに遷移させるような安全確保の仕組みとして実装されており，深宇宙において自律的な運用を実現することまでは想定されていない．動的計画変更については，従来の JAXA 衛星にはない考え方による運用方法であり，また複雑なミッション運用を自律的に遂行するためのキー技術であると著者は考えている．従来の宇宙機では，ミッション運用は発行時刻タグが付けられたコマンドシーケンスを宇宙機に登録しておき，時刻によって順次コマンドが発行されるタイムライン方式を基本的にとっている [山田 08]．したがって，運用内容について搭載系で変更することは難しく，パラメータを変更するか，スキップするか，あるいは中断して別のシーケンスを実装させることしかできない．つまり，宇宙機が自律的に運用内容を大きく変更することは異常・故障検知搭載機器の出力データを常時監視し，機器の異常兆候の発見や不具合箇所の同定を行う．（例：故障した機器について地上運用者に対応を促すテレメトリを送信する）イベント駆動宇宙機内部で発生するデータの集合によって「イベント」を定義し，運用中常時内部データを監視する．探査機の状態が特定のイベントにマッチしたらそのイベントに割り当てられている一連のアクションのためのコマンドを自動発行する．（例：姿勢制御用ホイールのアンロードを実施する）搭載データ解析宇宙機のデータレコーダに蓄積されているデータに対して，各種演算を適用して搭載系で「データ解析」を実施する．この解析では通信容量の制約から「地上にはダウンリンクされないデータ」も対象となるので，地上では不可能な解析が実施できる．（例：ある搭載機器の使用電力について統計値を計算して，トレンドを確認する）動的計画変更従来の宇宙機で利用されていたストアドコマンド方式によるコマンド発行管理を行わず，プログラム中にコマンドシーケンスを埋め込むことでコマンド発行条件や変更方法をロジックとして表現し，宇宙機の置かれた状況に合わせた自律的なコマンドシーケンスの変更を可能にする．（例：データレコーダの残量を鑑み，観測計画の順番を入れ替えて途中にダウンリンクを挟むことでトータルの観測時間を減少させないよう運用計画を宇宙機が自律的に変更する）表 1　DESTINY で検証する知能化による自律運用の機能

(3)

できない．そこで DESTINY では，ミッション運用を単純なコマンドシーケンスではなく，プログラムに内包させる方式を提案している [福島 11b]．どういう状況になったらコマンドが発行されるのか，論理的に記述するのである．プログラム内で参照できる情報は「異常・故障検知」，「イベント駆動」，「搭載データ解析」で参照できるデータとする．このデータには時刻も含まれるので，絶対時刻，相対時刻でコマンドを発行する従来型のコマンド発行管理をすべて引き継げる．また，プログラムであるので IF-THEN などのシーケンスの分岐制御やループ制御，さらに「イベント駆動」や「搭載データ解析」を活用でき，従来では不可能だったレベルの複雑なコマンドシーケンス管理が可能になる．これらを使えば，宇宙機の置かれた状況に合わせたミッション運用を自律的に動的に変更できる． 2･3　タイムライン方式からスクリプト方式へミッション運用の指令をタイムライン方式のコマンドシーケンスからプログラムに変更する．そのためには，そのプログラムがミッション運用ごとに変更できることが前提になる．しかし，通常の意味でのプログラムは頻繁に書き換えられない．書換え時にプログラムを実行している搭載計算機をいったん停止させる必要があるし，書換え後に不具合が発生すると最悪宇宙機を失う可能性があるからである．そこで DESTINY では，2･2 節で紹介したコマンドシーケンスを含むプログラムをスクリプトとする．スクリプトならばテキストで記述でき，そのスクリプトを解釈し実行するスクリプトエンジンを搭載計算機に準備すればよい．スクリプトは単なるテキストファイルなので通常のコマンドラインで伝送でき，それを書き換える行為はスクリプトエンジンのデータを変更することでしかない．搭載計算機の停止などは必要ない．だから従来コマンドと同程度の頻度で変更できる．いうならば，スクリプトは従来コマンドの拡張にあたる [Fukushima 11a]． DESTINYではスクリプトを深宇宙探査機のミッション運用の基本的な表記方法としたい．スクリプトによって計算機を制御する方式は，地上では PC においても一般的な方法である．それを宇宙機のミッション運用の制御に適用するだけである．また，宇宙機の状態監視や観測データ解析をスクリプトとして準備できれば，搭載計算機のソフトウェアとして最初から組み込まれている機能とは別に，スクリプトによってあとから機能追加が可能になる．さらに，スクリプトからスクリプトを実行することができるので，ミッション計画から別のミッション計画を制御することもできる．要するに，表 1 の機能はすべてスクリプトで実現できるのである．この考え方の適用先は深宇宙探査機に限定されない．地球周回の衛星に適用できるし，宇宙機ではない遠隔探査システム一般に対して適用できる． 2･4　ミッション運用をスクリプトで記述する方法地上運用者は，ミッション目的を実現させるべく宇宙機を遠隔操作する．その操作手順（内容）をミッション運用と呼ぶ．ミッション運用は，宇宙機において具体的な行動を引き起こすコマンドのシーケンスからなる．そして搭載計算機はシーケンスの各コマンドに対して付随している発行時刻あるいは発行条件を逐一チェックし，順次発行していく．ここでいうコマンドとは，観測装置のオンオフやデータの記録，あるいは宇宙機の姿勢を向けるといった具体的な行動の指示である．図 1 のような指示が電子化され，ビット列となる．そしてそのビット列は宇宙機に送信され，蓄積され，処理される．コマンドシーケンスは内容ごとにグループ化され，部品化され，「コマンド計画（PLN と表記する）」という単位で命名され，階層化されて整理される．そして，ミッション運用の場面ごとに運用意図に合うように一つながりのコマンドシーケンスに再構成され，宇宙機に送信される．ミッション運用中になんら問題がなければ一連にコマンド計画が順に実行されることで目的は達成される．しかし，何らかの問題が発生すると実行をいったん停止し，計画を変更する必要がある．コマンドに発行時刻が指示されたタイムライン型のミッション運用ではいったん停図 1 ミッション運用のためのコマンドシーケンスの一例（コマンドとその発行条件が記載されたものが並んでいる）図 2 あるコマンド計画が実行されたが途中で問題が生じ，別のコマンド計画が準備されて実行されたときの概念図（コマンド計画の実行をスクリプトが管理している場合は，問題発生後の新しいコマンド計画をスクリプトがアルゴリズムによって自律的に生成することが可能である）

(4)

止すると再起動は地上の運用者が再度指令する必要がある．また，計画を途中で変更する場合にも人が変更案を再送信し，再起動する必要がある．この作業を模式化すると図 2 のようになる．一度問題が発生すると自律的に計画を変更できないので人の介在が必要になる．このコマンド計画がスクリプトで表現されると問題発生後の状況が違ってくる．単なるコマンドシーケンスでしかなかったコマンド計画が図 3 のようなスクリプトで表現されることになる．スクリプトは別のスクリプトを入れ子構造のように包含できるので，人が介在して調整するしかなかった図 2 の順序修正をアルゴリズミックに解決することが原理的に可能となる．つまり，自律的にコマンド計画を変更できる可能性がある．コマンド計画の表現方法はプログラムであるがゆえに無限に存在してしまう．そこで，スクリプトの原型をテンプレートとして定義しておき，図 4 のように必須の処理ブロック（あるいは関数）を規格化することでスクリプトを標準化させる．標準化されているので図 2 のようなコマンド計画の実行，中断，実行順の変更などの調整を行う「上位の」スクリプトを準備することが容易になる．そしてこの上位スクリプトこそが表 1 の動的計画変更を実現する主体となる． 2･5　スクリプトに適した記述言語 2･4 節の図 3 に示した例では，スクリプト記述に JavaScriptを利用している．しかし，この選択は現時点での実現可能性を考慮した一つの提案であり，本稿で提案する内容に対しての「必須な選択」ではない．表 1 に示した機能を実現するためには別の言語を選択するほうが「自然ではないか」と考えることもできる．例えば，推論や述語論理を扱うならば LISP や Prolog という古くから人工知能研究のツールである言語を選択するほうが過去の資産を生かしやすいし，より簡潔的にソフトウェアを記述できるのではないか．そういう疑問の声が上がるだろうことは予想される．著者が JavaScript を選択した理由は，処理系の入手性である．本稿のアイディアを検証するために準備した何種類かの CPU 基板においては，JavaScript 処理系のソースコードを探しだすことができたし，コンパイル後のバイナリのサイズも動作速度も宇宙機のシステムへと転用する範囲に入っていると判断した．過去には JavaVMについて同様の確認を実施したことがある [福島 06]．特定の問題を簡潔的に解くためには，その問題にあった道具を使うほうが効率が高い．そう考えることには異論はない．しかし「その道具について，宇宙機で十分使えるものが準備できるのか？」という前提条件を考慮すると言語選択の幅は狭められてしまう．宇宙機において計算機のリソースは十分にない．地上での研究で使えるようなワークステーションがあるわけもなく，この問題のために計算機を専有できることもない．しかも Linux や Windows といった OS がそのまま動作するわけはないので，LISP や Prolog を使うための処理系の入手性は JavaScript と比較すれば低い．しかしこれら言語についても，宇宙機での適用可能性に変化があればそれらを評価して実装すればよい．本稿での議論は JavaScript に依存させているわけではない．スクリプトが扱える言語（インタプリタ機能，あるいはラムダ式が扱える言語）であれば，それらの言語に合わせて意味を翻訳すれば，多くの部分は適用可能である． 2･6　搭載スクリプトエンジンの実装一般的な宇宙機におけるコマンド・テレメトリ処理はデータハンドリングユニット（DHU）が行う．地上運用者は DHU 経由で姿勢・軌道制御システム（AOCS）や他の搭載機器を操作する．リアルタイムで通信できないときは，宇宙機のデータはいったんデータレコーダ（DR）に蓄積され，地上と通信できる時間にテレメトリとして地上へ送信される． 2･4 節で説明したスクリプトエンジンは，既存の DHUか，それ以外かに実装される．ただし現時点ではスクリプトによる運用は「実証すべき工学実験のテーマ」でしかない．またスクリプトエンジンの動作は軽くはない．DHU 上への実装は宇宙機システム全体へのインパクトが大きすぎる．そこで DESTINY では DHU とは別の搭載計算機を準備し，そこにスクリプトエンジンを実図 3 スクリプトによって記述されたコマンド計画（PLN）の一例（コマンド発行条件チェック方法とコマンド発行が JavaScriptによって記述されている）図 4 標準化されたコマンド計画のスクリプトの内部ブロック図（コマンド計画の内部構造をテンプレート化しておくことで，すべての計画スクリプトを上位のスクリプトがアルゴリズミックにハンドリングできる．図中には実行条件確認，初期化，内部モニタ処理，エラー処理，終了処理，およびマインループという一般的なブロック構造を示している）

(5)

装することを想定している．図 5 にスクリプトエンジンを実装するミッションデータプロセッサ（MDP）について，ソフトウェアとハードウェアの機能構成図を示す．運用者は MDP のスクリプトエンジンに向けてスクリプトを送信する一方，同時に従来どおりに DHU，AOCS，DR とテレメトリ・コマンドによってやり取りする．スクリプトエンジンは DHU 経由で従来型サブシステムとデータ交換する．したがってスクリプトエンジンからのコマンドは，サブシステムから見れば「地上運用者から送信されたもの」と同一の扱いになる．このデータ交換方法を採用することで，既存の宇宙機システムへのインパクトなしで 2･4 節を実現できる． DESTINYでは搭載ペイロードのデータを直接スクリプトで処理できるよう，MDP に直接ハードウェア機器を接続することもできるよう配慮されている．

3．運用スクリプトでの自律運用

3･1　運用スクリプト DESTINYミッションでは 2･2 節で説明したように，スクリプトを使ったミッション運用を計画している．以下では，この目的で 2･4 節で定義したスクリプトを「運用スクリプト」と呼ぶことにする．運用スクリプトは，従来タイムライン方式で発行時刻が指定されていたコマンドのリストあるいはシーケンスを，スクリプト言語によって記述される．図 4 で示したように，標準化されたブロック構造をもっており，スクリプトエンジン上で実行すれば特定の目的をもったプログラムの実行実体となる．つまり，運用スクリプト一つ一つは「タスク」のような意味合いをもつことになる．例えば，以下のような一まとまりのタスクが一つの運用スクリプトとして記述される．ミッション運用の実行は必要な運用スクリプトを順次実行することで実現できる．図 6 にイメージ図を示す．従来型のタイムラインコマンドでは図 5 の DHU へのコマンドが列挙されたものだが，この方法は MDP 上のスクリプトエンジンへの運用スクリプトが列挙されたものになる． 3･2　動的計画変更表 1 に示した DESTINY 運用で必要となる自律運用の機能項目は互いに独立ではない．搭載データ解析はどの機能でも必要になるからである．この中では動的計画変更が演算量が大きい．したがって，動的計画変更ができれば他の項目は実施できると考えてよい．ミッション運用は一連の運用スクリプトとして表現される．それぞれの運用スクリプトは「ミッションにおける実験提案者の意図」に沿って連結させる．ただし，それぞれの運用スクリプトにはそれぞれに「条件」や「制限」図 5 従来型宇宙機サブシステム，スクリプトエンジン動作用のミッションデータプロセッサ（MDP），地上運用者の従来コマンドおよびスクリプトの関係図（スクリプトは MDP 上で動作させ，従来型サブシステムとのデータのやり取りは DHU 経由で行うので，従来型には全くインパクトを与えない．スクリプトによる運用によるコマンド発行やデータ処理は，従来側から見れば地上運用者から直接コマンドと見分けがつかない．また MDP は直接実験装置を接続し，スクリプトにより詳細なデータ解析を高速で実施できるように配慮されている）図 6 運用スクリプトの実行イメージ（運用スクリプト p1, p2, p3 を順番に実行することでミッション運用での一連の作業が表現できる．各運用スクリプト p には特定の目的，実施条件がスクリプトで記述されている）図 7 運用スクリプトの集合からミッション運用として成立するものを生成する作業の概念図（ミッション運用に適した運用スクリプトを選択し，順番を付けて並べることで運用が計画できる） p1 観測装置の視野にある特定の星が入るように宇宙機の姿勢を変更する． p2 特定の観測装置を特定の観測モードに入れてデータを取得を行い，データレコーダに蓄積する． p3 特定の時刻がきたら，データレコーダ内のデータを順次テレメトリとして地上に送信する．

(6)

があり，どの運用スクリプト同士でも自由に繋げることはできない．図 7 はミッション運用を生成する様子を示している．運用スクリプトを部品と考え，その集合からピックアップして連結する．このとき，目的も制約も満足する「実行可能なミッション運用」は唯一とはならない．図 6 で示したような運用スクリプトのシーケンスについては，複数候補があり得るし，また一つも存在しないこともある．あるミッション運用のために必要な運用スクリプトを宇宙機に送信し，その開始条件成立後に運用が開始されたとする．図 2 のように途中で問題が発生したらとりあえずそのミッション運用は停止する．従来のタイムライン式のコマンドならば「安全な状態へ遷移」した後，地上からの指示を待つ．この場合，宇宙機の安全は確保されるが，次の地上からの指示までの時間，無為の時間を過ごすことになる．宇宙機の機能喪失につながる故障の疑いがある場合はそれでよい．しかしミッション運用条件が一時的に過渡的に逸脱しただけならば，ミッション運用は再開できるはずだが，時刻タグがついたコマンドの間に不整合が起きる可能性があるので，通常は何もできない．運用スクリプトならば，運用再開は自律的に実施できる．運用スクリプトの結合については図 7 で示すように搭載系でチェックし，検証を行うことができる．ミッション運用中に問題が発生したらいったん停止し，未実行の運用スクリプトを「組み換え」ることで「実施可能なシーケンス」を検索すればよい．一つ以上の解があれば，そのシーケンスを「変更後のミッション運用」としてミッション運用を再開すればよい．この中断・再構成・再開の一連のプロセスを地上運用者の介在なしに搭載系だけで処理できれば「自律的に」運用を再開したことになる．これをミッション運用の「動的計画変更」と呼び， DESTINYで検証する自律運用の中心的な機能となる． 3･3　自律運用の具体例従来のタイムライン方式の運用では不可能だが，運用スクリプトを使ったミッション運用ならば可能となる「動的計画変更」の具体的例を示す．DESTINY ミッションはまだ提案中の段階であるので，ミッション全体をシミュレーションする装置は準備できていない．本稿では簡略化された地球周回衛星のミッション運用を仮定し，それをモデルとして説明する．図 8 に複数の星を観測する周回衛星の概念図を示す．観測する星は 3 個で，宇宙機の姿勢を向け観測データを取得し，一連のミッション運用期間中に観測データを地上にダウンリンクする．姿勢制御用ホイールの蓄積角運動量のアンローディングは複数回行う．必要となる運用スクリプトの項目を図 8 の下部に示す．これらの運用スクリプトをシーケンスとして連結し，時刻や姿勢などの条件を追加してミッション運用全体を一連のシーケンスとして構成する．最初のシーケンスは地上運用者が「標準ミッション運用」として定義する．それを搭載スクリプトエンジンに送信し，実行を開始させる．数値シミュレーションでミッション運用を模擬した．全く問題が発生しなかった場合の予測を図 9 に示す．図中，すべての運用スクリプトを示す四角の記号には番号が振られている．すべての運用スクリプトが実施終了したとき，「ミッション運用は完了した」ことになる．このシミュレーションで使った環境計算モデルはシンプルであり，図 5 における H/W 部分をキネマティクス計算で代用している．搭載スクリプトエンジンの挙動解析では JavaScript エンジンを用いて予測した．そのため運用スクリプトの記述言語には JavaScript を用いた．図 3 はその実例の一部である．運用シミュレーションの実行結果を図 10 に示す．横図 8 3 個の星をターゲットとして観測を行う地球周回衛星の概念図と利用する運用スクリプトの項目（観測すればデータ蓄積量が増加し，衛星の姿勢制御のためのホイール蓄積角運動量は増加する．取得データのダウンリンクは地上の特定の場所で行う．これらの制約条件はすべて定量的な条件式で表現され，各運用スクリプト中にプログラムとして記載されている）図 9 標準シーケンス実施時の運用スクリプト推移図（左端でミッション運用が開始され，その時刻で実施された運用スクリプトを時間軸下に並べてある．観測運用，データダウンリンク運用，ホイールアンローディング運用のカテゴリーに属する運用スクリプトが順次実施される意図で計画された．衛星の姿勢は図中の矢印で表現されている．全運用スクリプトには 1 番から 14 番として命名されており，全部実行されればミッション運用は完了したことになる）

(7)

軸は時間とし，衛星の緯度と日照日陰の状態を参考情報として示してある．グラフを左側から確認する．図中に p1，p2，p3 といった添字がある四角形が書き込まれている．これは図 8 に示した運用スクリプトが四角形のある時間だけ実行されたことを示している．全部で 14 個の運用スクリプトからなるシーケンスで，その番号は連番となっている．ミッション運用を設計した運用者の想定どおりに（標準どおりに）運用スクリプトが実施されれば，時刻はともかく，図中の運用スクリプトの四角形は右上がりに連なるはずで，図 10 の結果を確認するとそうなっている． 3･4　自律運用のアルゴリズムの一例宇宙機の環境条件が変化すると，いくつかの運用スクリプトに付随する実施条件が成立しなくなり，図 6 のようには運用スクリプトが結合できなくなる．この問題がミッション運用中に発生したら，ミッション運用の実行をいったん停止し，残りの運用スクリプトの結合を変え，解が存在すればそれを使ってミッション運用を再開する（動的計画変更機能の発動）．変更方法については多くのアルゴリズムが適用できる [Zweben 94]．また，どのようなアルゴリズムであっても，それがスクリプトで記述できるものならば原理的には採用できる．とはいえ，それがどれだけ実現可能かは搭載計算機の処理能力しだいで決まる．図 5 でのタスク優先度から，運用スクリプトの動的計画変更処理は MDP上ではリアルタイム性は問われない．が，時間や使用メモリ量を無限に使えるわけではない．本稿では，運用スクリプトのシーケンス順変更検索アルゴリズムに「実験計画法」を適用した [福島 12]．この方法は最適解を探せるわけではないが，計算量は小さく，最大計算時間は決まっており，搭載系での探索アルゴリズムに要求される最低限の要求は満たしている．例として 7 個の運用要素から構成されるミッション運用を動的計画変更する手順を説明する．7 個ある運用スクリプトを単に順序変更する場合は，順列組合せで 5 040通りのシーケンス候補が生じる．これらの候補は制約条件を満たすわけではなく，どの候補が実行可能なのか（制約条件が満されるのか）確認の必要がある．しかし，搭載計算機で「リアルタイム」に確認するには，確認の演算内容に注意しなければならず，また実際のミッション運用では運用スクリプトは 7 個以上になると予想されるので，全シーケンスの確認は事実上困難である．そこで，シーケンス候補を実験計画法で大幅に絞り込んでしまう．以下で説明する方法では，候補となるシーケンスを 5 040 個から 7 個へと大幅に削減する．ここまで削減すると，ほとんどのシーケンス候補は破棄することになり，制約条件を満たす運用シーケンスの変更案が存在しない可能性もある．しかし，実験計画法での候補削減が全く機能しないこともない．また，絞られた候補は別の探索の初期値として使うこともできる．さらに，削減された候補数が固定なので確認のための演算量に上限が設定でき，搭載系リアルタイム計算への適用には都合が良い．図 11 に運用スクリプトの実行順番候補の生成例を示す．実験計画法で使用する直行表は 8 × 7 とする（図中左の行列）．この直交表の意味は，行を実験ケース，列を要素番号であり，その成分が 0 のものはそのまま， 1のものは「変更して実験せよ」という指示である．一方，図 11 の右の行列は実験計画法により生成された運用スクリプト実行シーケンス候補で，行が候補番号，列が実行順序である．一番上の行が基本となる実行順番であり，運用スクリプト番号は昇順に並んでいる．その下の 7 行はシーケンス変更候補（Seq1 から Seq7 と表記）である．対応する直交表の行を参照すると，成分が 1 の場所に該当する運用スクリプトについて，それらがローテーションされている．この直交法の解釈については著者の一案でしかなく，他の方法も考えられる．直交表のサイズは複数あり，直交表の生成アルゴリズムも存在する．また，ミッション運用全体に対して一つの直交表を適用する必要はなく，全体を複数のブロックに細分化し t〔s〕 図 10 標準シーケンス実施時の運用スクリプト時系列図（下図では横軸を時間，縦軸は実行中の運用スクリプト番号を示している．上図は横軸に時刻，縦軸に周回衛星の緯度，および日照日陰の状態を示した時系列図であり，周回上どの位置でどの作業をしたのかが確認できる）図 11 実験計画図（左が直交表，右はシーケンスの変更候補を示す）

(8)

てからブロックごとに適用することもできる．以上の方法は完全ではないが，直交表の性質から広範囲に適用できると期待される．候補となるシーケンスが存在しない場合，運用スクリプトを削除また挿入した後にこの方法を反復適用するで，結果の改善が可能である． 3･5　自律運用のシミュレーション結果以下では，ミッション運用中に不具合を起こしてその応答を見るのではなく，運用スクリプトに課す制約条件を想定よりも厳しくし，それに応じて「自律的に」シーケンス順が変更されてミッション運用が実施される様子を確認する．表 2 に示す 4 個の制約条件を強める．それらは独立に有効無効を設定できるので，制約の種類としては全部で 16 ケースあり，それぞれの応答を確認していく．まず図 12 に，姿勢変更時の最大変化量を制限するケース（case1），運用スクリプト P9 を日照にするケース（case2），ホイールの蓄積角運動量を 1/4 に制限するケース（case3），データレコーダの記録上限を 1/10 に制限するケース（case4）の運用スクリプトのシーケンス変更結果を示す．これらの結果は図 10 と異なっているが，最後まで実行されているのでミッション運用としては完了している．各 case において，制約量（姿勢角，蓄積角運動量，蓄積データ量）の時系列グラフを同時に示されている．制約条件を満足しながらミッション運用が実施されたことが見て取れる．次に図 13 に，二つの制約条件が同時に有効化された場合の動的計画変更結果を示す．どのケースも結果的にすべての運用スクリプトを実施できている．case7 と case8は違う制約条件の組合せであるが，同じ順番変更となっている．これは実験計画法の同じテストケースを使って生成したシーケンスについて制約条件を確認したたところ満足していたので同じシーケンスで実施したことが理由である．最後に図 14 に，3 個，4 個の制約条件が同時に有効化された場合の動的計画変更結果を示す．3 制約条件以上を同時に満たすシーケンスの生成は，単純な順番の変更だけで解を見つけることができず，「実行しない（諦める）運用スクリプト」を選定し，その残りで順番変更を行う方式がとられている．特に case13 については，14 個中 7 個の運用スクリプトの実行を諦めた解を提示しているが，それでもミッション運用としては「中断」した場合よりも多くの観測データを取得していることに注意する．以上の具体例で着目するべき点は，従来であれば「運用停止」という事態となっていたものが，運用スクリプトのもつ性質を使って，停止せずに「変更することでミッション運用を継続した」という点である．DESTINY のように深宇宙探査ミッションでは，宇宙機の状態把握には時間がかかる．その運用制約下においては，搭載機が制約量表記制約内容説明記録データ量 ro/r- 制約時は通常の 1/4 蓄積角運動量 wo/w- 制限時は通常の 1/10 日照日陰観測 do/d- 運用（P9）を日照にするか否か姿勢角変化量 ao/a- 制約時は 40 deg 以下の変動のみ記号は，o：有効，-：無効を意味する表 2　運用スクリプトで設定した制約の種類 t〔s〕 図 12 運用スクリプトに制約をかけた場合の運用スクリプト時系列図（制約 1 個を有効化した場合の運用スクリプトのシーケンス．case4 では，順番変更だけでは解はなく，p3 をキャンセルして運用全体を中止する最悪の結果を回避している） t〔s〕 図 13 運用スクリプトに制約をかけた場合の運用スクリプト時系列図（制約 2 個を有効化した場合の運用スクリプトのシーケンス）

(9)

自律的に状況に合わせて振舞いを修正することは重要である．その場合は「最適」な選択でなくともよい．継続することで限られた時間的により多くの観測結果を取得できるからである．

4．ま　　と　　め

本稿では，DESTINY ミッションの宇宙機の知能化・自律化を目的とした工学実験について紹介した．宇宙機運用の知能化研究は古くからのテーマであるが，それらは個別の知能化アルゴリズムを扱ったものが多かった．したがって，ミッションや利用できる計算機が想定したものと大きく異なると実用にならなかった． DESTINYの知能化技術については，具体的な問題解決方法（アルゴリズムあるいはシステム）ではなく，宇宙機のインフラ技術としてスクリプトエンジンを扱う．スクリプト利用方法を表 1 のように分類し，そのなかでミッション運用の状況に合わせた「運用計画自律変更」の技術が包括的な知能化技術だと考えた．そこで「運用スクリプト」というミッション記述方法を提案し，運用スクリプトによって宇宙機が具体的に実施するミッション運用を記述し，搭載系が自律的に「状況に合わせて運用を変更できるのか」をシミュレーションを使って示した．搭載系でスクリプト実行という考え方は DESTINY 以前の JAXA 衛星にはなかった．宇宙機搭載スクリプトが実用化され，これまでの知能化研究の蓄積を広く短期間で宇宙機で利用できるようになることを期待している．

◇　参　考　文　献　◇

[Balzano 06] Balzano, V. and Isaacs, J. C.: Event-driven James Webb Space Telescope Operations, SpaceOps Conf. Proc., AIAA-2006-5747（2006）

[Chien 04] Chien, S., et al.: The EO-1 Autonomous Science Agent, Proc. 3rd Int. Joint Conf. on Autonomous Agents and

Multiagent Systems, pp. 420-427（2004）

[福島 06] 福島洋介，小林英司：宇宙機搭載ソフトウエアの動的変更方法についての一考察，第 50 回宇宙科学技術連合講演会， 2C04（2006）

[Fukushima 11a] Fukushima, Y. and Mita, M.: A new approach to autonomous on board mission replanning using orthogonal array design, Proc. 4th IEEE Int. Conf. on Space Mission

Challenges for Information Technology（SMC-IT 2011），Palo Alto, CA, USA, pp.43-50（2011）

[福島 11b] 福島洋介，山田隆行，川勝康弘：DESTINY 工学実験：運用および搭載機能の自律化・効率化，第 55 回宇宙科学技術連合講演会，3D08（2011） [福島 12] 福島洋介，三田信：自律遠隔システムにおける搭載ミッション管理機構での計画・スケジューリング機能実装について，計測自動制御学会論文集，Vol. 48, No. 7, pp.383-388（2012） [Kawakatsu 12] Kawakatsu, Y. and Iwata, T.: DESTINY mission

overview - A small satellite mission for deep space exploration technology demonstration -, 13th Int. Space Conf. of Pacific -

Basin Societies（2012）

[川勝 13] https://www.ep.isas.jaxa.jp/destiny/（2013） [小島 04] 小島寧，棚町健彦，狼嘉彰：環境観測技術衛星（ADEOS-Ⅱ）

搭載姿勢軌道制御系（AOCS）の耐故障設計，宇宙技術，Vol. 3, pp. 49-58 (2004)

[Muscettola 98] Muscettola, N., et al.: Remote Agent: To boldy go where no AI system has gone before, Artificial Intelligence, Vol. 103, pp.5-47（1998）

[Rabideau 99] Rabideau, G., Knight, R., Chien, S., Fukunaga, A. and Govindjee, A.: Iterative repair planning for spacecraft operations in the ASPEN system, Int. Symp. on Artificial

Intelligence Robotics and Automation in Space（ISAIRAS

1999），Noord-wijk, The Netherlands（1999）

[矢入 11] 矢入健久，乾稔，河原吉伸，高田昇：次元削減とクラスタリングによる宇宙機テレメトリ監視法，日本航空宇宙学会論文集，Vol. 59, No. 691, pp. 197-205（2011）

[山田 08] http://www.isas.ac.jp/docs/PLAINnews/172_ contents/172_1.html（2008）

[Zweben 94] Zweben, M., Daun, B., Davis, E. and Deale, M.: Scheduling and rescheduling with interactive repair,

Intelligent Scheduling, pp. 241-256, Morgan Kaufmann, San

Francisco（1994） 2014年 5 月 29 日受理 t〔s〕 図 14 運用スクリプトに制約をかけた場合の運用スクリプト時系列図（制約 3 個，4 個を有効化した場合の運用スクリプトのシーケンス．制約同時有効化では順番変更だけでは解はなく，多くのケースで運用スクリプトを一部キャンセルして運用全体を中止する最悪の結果を回避している）福島　洋介 1998年東京工業大学大学院理工学研究科機械物理工学専攻博士課程修了．2004 年（独）宇宙航空研究開発機構宇宙科学研究所助教，現在に至る．小型衛星の開発・運用，自律遠隔システムの研究に従事．博士（工学）．

知能化の敷居を下げるDESTINY : スクリプトでの自律運用(<特集>宇宙に挑む人工知能技術)

1．は じ め に