制御系ソフトウェアの部品化：OSEC API

これまでブラックボックスだったNC装置の内部の制御系ソフトウェアを整理・部品化することでアーキテクチャ化を行った。具体的には、国際ロボットFA技術センター(IROFA)のNCオープン化政策委員会ワーキンググループで報告された制御階層（図 3-1）を実装可能なレベルまでブレークダウンし、目的・処理内容・要求される実時間性などの点から機能毎に分類し、一つ一つの機能のまとまりを『機能ブロック』と呼ばれるソフトウェア部品として再構成した。制御系ソフトウェアが機能ブロック単位でプラグアンドプレイできることを目指している。またOSEC-Iの階層に対応するものとして、機能ブロックのうち同じレベルにあるものをまとめた『機能群』を規定した。

図 3-1 制御階層（IROFAの報告書より）

各機能群および機能ブロックのサービスの概略を表 3-1に示す。参考のため、各機能ブロックを再構成する上で想定した、要求される実時間性も併せて表す。応答のタイプを基準に、これら機能群のうちリソースマネージメントと動作生成はランダムイベント型、機械制御とデバイス制御は周期イベント型と区別することもできる。

各機能ブロックはオブジェクトの形でソフトウェア部品化され、これらオブジェクトに対するメッセージをインターフェイスプロトコル(OSEC API)として定義した（付録A参照）。各機能ブロックはオブジェクトとしてカプセル化されているので、機能ブロックがメッセージを受けて処理をどのように行うべきかはアーキテクチャとして規定されていない。つまり処理の実装に関しては機能ブロックの開発者に任されている。こうしたカプセル化により、企業や個人が個別に独自の付加価値を加えやすくなる。また処理方法を規定しないことは、各機能ブロック間の結合関係を規定しないことも意味する。OSECアーキテクチャではあくまで論理的な機能ブロックのサービスの内容とそれら機能ブロックに対する論理的なメッセージを定めているだけである。このためOSECアーキテクチャモデルとしては、各機能ブロックは図 3-1のような階層構造にはならず、各機能ブロックに対するメッセージ(OSEC API)を介して並列に接続される形となる（図 3-2）。

またモータ・I/Oといった制御コンポーネントハードウェアのプラグアンドプレイを可能にするため、各ハードウェアはデバイス制御機能群の中に隠蔽される。サーボ制御・PLC制御などの対応した機能ブロックへのメッセージがこうしたハードウェアへの唯一のインターフェイスとなっている。

図 3-2 OSECアーキテクチャモデル

論理的な機能ブロックから構成されるOSECアーキテクチャは一意に規定されるものである。しかしこれらの各機能ブロックを物理的に実装するときには、デバイスドライバ・プロセス・プロセス間通信といったシステムの機能、静的なライブラリ・DLLといった組込の手法、利用する制御カードなどのハードウェア要因、あるいは各種ソフトウェアの実行制御・監視用に追加されるソフトウェアモジュールなどの実装方式に依存したものとなる。そのためアーキテクチャを実装するための実装モデルとしては１つには限定されず、システムの規模や構成するハードウェアなど実装の形態あるいは使われ方に応じて複数存在することになる。図 3-3は特に各機能ブロック間の結合関係を明示的にした実装モデルである。

図 3-3 OSEC実装モデル

1. 機能ブロックの実装例

図 3-4は各機能ブロックを実装した一つの構成例である。また実証システムの各ステーションの説明でも、実装例が詳しく述べれれている。