身近な例から学ぶ“サービス”：Robotics Studio活用術 はじめて作るサービス（2）（1/2 ページ）

身近な「例」を用いて、MSRSのサービスを構成する“コンポーネント”と“その働き”について詳しく解説します

[大川 善邦 工学博士 日本大学工学部非常勤講師／大阪大学名誉教授，＠IT MONOist]

　前回、Visual C# 2005 Express Edition SP1（以下、VC#）のテンプレートを使って、必要最小限のサービスを作り、ビルド＆実行しました。

　今回は、前回の内容を踏まえたうえで、“マイクロソフトのRobotics Studio（以下、MSRS）のサービスとは何か”について解説します。

モデルベース設計

　航空機や自動車の設計において、モデルベース設計（MBD：Model Based Design）を採用する企業が増えています（注）。

※注：

モデルベース設計の基礎については、拙著「MATLABによるリアルタイム制御入門―xPC Targetを使ったモデル・ベース開発」を参考にしてください。

　モデルベース設計では、はじめに対象となる機械の動特性を数式で記述し、この動特性を実現するシミュレータを作ります。そして、制御系のプログラムを書き、ビルドして、シミュレータを使って十分に動作検証を行います。その後、実機へダウンロードして、実機検証を行うという流れが基本となります。

　では、ロボットの分野ではどうでしょうか？

　そうです。本連載の主役「MSRS」こそが、“ロボット分野におけるモデルベース設計を実現するためのツール”といえるのです。

マニフェストとコンフィグレーション

　次に、MSRSで重要となるマニフェスト（manifest）とコンフィグレーション（configuration）について解説します。

　MSRSを使ってロボットを制御するプログラムを作り、ビルドしたとします。このプログラムを実行する際に、マニフェストというXMLファイルを添付します。マニフェストでシミュレータを指定すれば、プログラムはシミュレータと結合して動作し、実機のロボットを指名すれば、プログラムはロボット実機と結合して動作します。

　制御対象をシミュレータから実機へ切り替える際に、ビルドしたプログラムを書き換えたり、再ビルドしたりする必要はありません。プログラムに手を加えることなく、マニフェストで指定するだけで、シミュレータと実機を切り替えることができるのです（図1）。

図1　マニフェストファイル

　次に、コンフィグレーションについて説明します。

　サービスをデバッグする際、基本となるのがログの解析です。一般的に、最初の段階では多くのログを取りますが、デバッグが進むにつれて、不要なログは切り捨て、記録するログを絞り込んでいきます（注）。

※注：

ログの記録の際、ディスクへアクセスする必要があります。多くのログを取ると、プログラムの実行時間が増加します。

　MSRSでは、記録するログをコンフィグレーションファイルで指定します。サービス起動時に“どのログを取るのか”、これをコンフィグレーションファイルで指定します。これにより、サービスのプログラムを再ビルドすることなく、記録するログを変更できます。サービスをデバッグする際に利用するととても便利です。

　ちなみに、マニフェストとコンフィグレーションは、いずれもXMLによって記述します。

メッセージの配送

　前述しましたが、MSRSではプログラムの起動時にマニフェストによって、シミュレータと実機を使い分けることができます。プログラム自体を書き換える必要はありません。

　なぜ、SOAにおいて、このような使い分けが可能になるのでしょうか？ 以下の例で説明します。

　例えば、手紙をポストへ投函（とうかん）したとします。

　この手紙は、郵便局へ集められ、さらにその地域の中央郵便局に集められ、ソートされて、目的地の郵便局に送られ、あて先へ配達されます（図2）。

図2　手紙の経路

　ここで強調したいのは、投函（とうかん）した手紙が、“規定の経路をたどって、あて先に届く”ところです。郵便局が手紙の経路をコントロールしているので、図3のように、封筒のあて名を変えることで、あて先を変えることができます。つまり、手紙の中身まで変更する必要はないのです。

図3　マニフェストは手紙の封筒のようなもの

　SOAにおいて、メッセージの配送はシステムが一元管理するので、このような経路の切り替え（シミュレータからロボット実機など）が簡単に実現できます。

メッセージのオーバーヘッド

　ロボットの設計において、モデルベース設計が重要な手段となっていることは事実ですが、これに重点を置き過ぎると別の場所に不具合が生じる可能性があります。

　例えば、町内の回覧板が来たときに、これを隣の家へ届けるために、郵便小包にしてポストへ投函（とうかん）する人はまずいないと思います。図2に示したように、郵便は規定のルートを回って隣の家へ届くので、配達は早くても1、2日後になります。はっきりいって時間の無駄です。

　SOAにおける“メッセージ”は、サービスからシステムのキュー（待ち行列）へ投函（とうかん）され、そこから相手のキューへ配送され、そこから処理が始まります。時間に関するオーバーヘッドは大きくなります。

　では、ロボットが障害物にぶつかって、バンパーの信号がOFFからONに変わったとしたらどうでしょうか？ 普通であれば、ロボットをストップして、何らかの処置を取る必要があります。

　このような事態において、対応が遅れると、ロボットのバンパーに傷を付けたり、ぶつかった相手に障害を与えたり、いろいろな問題を引き起こす場合があります。また、組み込み分野では、通常、時間に関する制約が強いのでSOAのメッセージを使うことができなくて、プログラム間で直接データを授受する必要が出てくる可能性もあります。

　ここでいえることは、ロボットの制御を行う際に、「粒度の小さいサービスを多数作ることは、“望ましくない”」ということです。