ORiNの構成要素

ORiNの構成要素

1. ORiN2の構成要素

ORiNは,ロボットを始めとする各種FA機器や,データベースなどさまざまなリソースの標準的なインターフェイスを提供するミドルウェアです.現在のORiN仕様はVer.2.0で,これを略して単に “ORiN2″と呼んでいます. ORiN Ver.1.0 と Ver.2.0の違いは〔表 1〕でまとめてあります.
〔図1〕にORiN2の構成を示します.この図に示すようにORiN2は,CAO/CRD/CAPという3つの基本技術から構成されています.CAOとは,クライアントアプリケーションおよびロボットコントローラ,PLCなどのFA機器に対して,共通のインターフェイスと機能を提供する「標準プログラムインターフェイス」です.CAPとは,インターネット上のFA機器にアクセスするための「インターネット対応通信プロトコル」です.CRDとは,FA機器が持つリソース情報を,メーカ非依存のフォーマットを表現するための「標準データスキーマ」です. 以降,この三つの技術を順に解説します.

〔図1〕ORiN2のモデル化と3つの技術

〔表 1〕ORiN1 と ORiN2の比較
ORiN 1 (2002 年リリース) ORiN 2 (2005 年リリース )
OS Windows Windows / Linux など (CORBA 仕様は OS 非依存 )
言語

アプリケーション部: Visual Basic, C++ など
エンジン,プロバイダ部: C++

アプリケーション部: Visual Basic, C++, VB.NET, C#, JAVA, VBScript エンジン,プロバイダ部: C++ ( CORBA 仕様は言語非依存.ただし,現実的にはバインドされている言語だけなので Visual Basic などは使えない.)
通信 DCOM / WEB サービス (RAP) DCOM / CORBA / WEB サービス (CAP) / HTTP(e-CAP) / UPnP
対象機器 比較的機能が高いコントローラ( PLC ,ロボコン,NC) 比較的機能が高いコントローラ( PLC ,ロボコン, NC )から単機能コントローラまで( DA/AD 変換ボード, DIO ボード)まで.
対象分野 FA FA/HA/ROBOT
デバイス
プロファイル
XML スキーマ(RRD) XML スキーマ(CRD), UPnP Device Description
フレーム
ワーク
抽象コントローラを定義し,アプリケーションはそのコントローラを操作する.プロバイダは抽象コントローラと実コントローラとの違いを埋める. 左に同じ
インターフェイス アプリケーション向けIFとデバイス向けIFを規定. 左に同じ
モジュール
開発支援
ORiN 1 SDK に,サンプル,ドキュメント,簡単なテストツールなどが入っている.「プロバイダウィザード」はプロバイダの C++ スケルトンプログラムを自動生成できる. ORiN 2 SDK に,サンプル,ドキュメント,統合テストツールなどが入っている.「プロバイダウィザード」はプロバイダの C++ スケルトンプログラムを自動生成できる.
コンフィギュ
レーション
サービス

RaoConfig によるセキュリティ設定など

CaoCofing によるセキュリティ設定や言語ロケール設定など.
CaoSQLConfig によるモジュール構成とソフトウェア配線,データ型変換など.

アプリケーション
開発支援
アプリケーション開発は,市販の開発環境 (Visual Studio , VS.NET , Eclipse) などが使える. 左に加え, ORiN2 SDK の CAO スクリプト言語エディタでも簡易プログラムが開発可能.

2. CAO

CAOとは,Controller Access Objectの略で,クライアントアプリケーション向けとFAデバイス(機器)向けの二つのインターフェイスを提供しています.これにより,デバイスメーカはクライアントアプリケーションに依存しないで,デバイスが持つ機能を公開することができます.また,アプリケーションベンダは,デバイスに依存しないで,クライアントアプリケーションを開発することができるようになります.

〔図2〕 CAOのアーキテクチャ

〔図2に示すように,PC上のORiN2プログラムは,三つの階層に分けられます.
一つ目は,クライアントアプリケーション部で,CAOエンジンから提供されるインターフェイスに準じてアプリケーションを作成することで,各デバイスの違いを意識することなく(※1),アプリケーションを構築することができます.また,このクライアントアプリケーションは,同時に複数動作させることが可能です.
二つ目は,CAOエンジン部で,標準のプログラムインターフェイスと共通の機能を提供します.クライアントアプリケーションに対しては,標準のプログラムインターフェイスを提供することで,メーカに依存せずに作成が可能になります.さらに,プロバイダの管理機能や非同期処理などを共通の機能としてエンジンが提供しているため,容易にクライアントアプリケーションやロボットコントローラを開発することができます.
三つ目が,CAOプロバイダ部で,ロボットコントローラ向けインターフェイスを持ち,メーカごとの違いを吸収するモジュールです.プロバイダは,単純にロボットコントローラ向けのインターフェイスを実装しただけのものではなく,CAOに新しい機能をアドイン的に追加するという柔軟な拡張性を提供します.後述するCRDやCAPなどは,それぞれプロバイダを利用することで,その機能を実現しています.
通常CAOはクライアントアプリケーション部を除いたCAOエンジン(CAO.exe)とCAOプロバイダ(dll群)を指します.
※1)通信デバイスやプロトコル〔アルゴリズム〕でのアクセスは意識不要の意味,デバイスの情報は意識する必要はあります

■CAOエンジン

CAOエンジンはORiNの中核となるEXEタイプのCOMコンポーネントです.CAOエンジンはORiNクライアントアプリケーションとCAOプロバイダとの間に存在し,両者間のデータあるいはコマンドの仲介を担います.クライアントアプリケーションは常にCAOエンジンとリンクを行い,クライアントの要求に応じてエンジンが必要なCAOプロバイダとリンクを行います.クライアントアプリケーション⇔CAOエンジン⇔CAOプロバイダ間のリンクは分散オブジェクト技術であるDCOMまたはCORBAの仕様で行われます.このため,これらのリンクはプロセスを越えて,あるいはPCマシン,インターネットをも越えて行うことが出来ます.この機能によってクライアントアプリケーションは実に簡単にリモートアクセスや負荷分散を行うことが出来るようになります.
CAOエンジンの機能は以下のものがあります.

  • CAOプロバイダの管理
  • オブジェクトコレクションの管理
  • メッセージプールによる非同期処理(イベント処理)
  • メッセージのオブジェクト化によるコンテキスト管理
  • オブジェクトの事前登録(CAOモデル)
  • ダイナミックバインディングによるAPIの動的変更
  • CRDファイルによる静的情報マージ処理
  • リモートエンジンの接続

ORiN2 SDK に含まれるCAOエンジンおよびCAOプロバイダの“実装”はDCOMで行われていますが,ORiN2での仕様上,CORBAであってもかまいません.SDKにはこのためにCORBA版のIDLファイルが含まれています.

■CAOプロバイダ

CAOプロバイダは,クライアントアプリケーションの要求に応じてCAOエンジンから動的に呼ばれます.言わば,CAOエンジンのアドインとして動作する仕組みになっていますが単純なDLLというわけではありません.CAOプロバイダもまたエンジン同様COMコンポーネントです.但し,CAOプロバイダはDLLタイプのCOMコンポーネントとして実装されています.

CAOプロバイダはクライアントアプリケーションから直接アクセスされることはありません.プロバイダはエンジンから,あるいは他のプロバイダからしか呼ばれないため,通常ユーザがプロバイダの持つインターフェイス仕様を意識する必要はありません.
CAOプロバイダはORiN2 SDKに含まれるプロバイダ作成ウィザードによって作成されますので,CAOエンジンに対して常に同じインターフェイスIDを持ちます.(もちろん,クラスIDは個々のプロバイダでユニークです.)そのため,CAOエンジンにとってリンクするプロバイダが異なっても全く同じ呼び出しが出来ます.この仕組みによってプロバイダはエンジンに対してアドインとして機能できるのです.

CAOプロバイダには多くのタイプが存在します.デバイス型,データ共有型,ユーティリティ型,ゲートウェイ型などがあります.
デバイス型は実際の機器と接続して,CAOエンジンに対して機器の通信仕様の差異を吸収するように実装されています.標準的なCAOプロバイダの多くはこのタイプに該当します.

データ共有型はアプリケーション間でデータを共有するためのプロバイダです.共有メモリプロバイダ,XMLにアクセスするためのCRDプロバイダがこれに該当します.
ゲートウェイ型はORiNのインターフェイス仕様とは異なる他の規格との接続を行い,データやコマンドの橋渡しをするタイプです.ORiN2 SDKに含まれるものとしてはOPC Foundationが策定したアプリケーション間通信インターフェイスの統一規格であるOPCと接続するためのOPCプロバイダやORiN Ver.1.0の仕様であるRAOと接続するためのRAOゲートウェイプロバイダがこれに該当します.

上記以外にも実装次第であらゆるタイプのプロバイダが作成可能です.例えば,仮想機器型プロバイダ.これは実際の機器とは接続せずに,ソフトウェアのみで対象とする機器の動作をエミュレートします.ロボットコントローラをこのタイプに対応させた場合,クライアントアプリケーションは実際のロボットコントローラがなくても,仮想的にロボットを動作させたり,モニタしたりとシステム導入前の事前検証が可能になります.また,ORiNクライアントアプリケーションから見た場合,実機か,仮想機かの区別をしなくても済むため,アプリケーション開発が非常に楽になるといった利点も生まれます.

その他の標準CAOプロバイダに関してはORiN2 SDKの各プロバイダの仕様書を参照してください.

■CAOオブジェクトモデル

〔図3はCAOのオブジェクトモデルを示しています.

〔図3〕 CAOオブジェクトモデル

CAOオブジェクトモデルはもともとORiN2が対象としているFA,HA,ロボットの機器が持っている揮発性リソースと不揮発性リソースの二種類を抽象化したものです.揮発性リソースはメッセージやコマンドを指し,CaoMessageオブジェクト,CaoCommandオブジェクトがこれらに対応します.不揮発性リソースにはコントローラ,変数,ファイル,タスク,ロボット,拡張カードを指し,CaoController,CaoVariable,CaoFile,CaoTask,CaoRobot,CaoExtentionオブジェクトがそれぞれ対応します. CaoEngineオブジェクトはCAOエンジンそのものに対応し,CaoEngineStatusオブジェクトはCAOエンジンの状態に関する情報を提供します.CaoWorkspaceオブジェクトはコントローラを配置するための作業空間に対応します.
その他のオブジェクトとして複数の同種CAOオブジェクトをまとめて管理するためのコレクションオブジェクトが存在します.

〔図4〕 ORiN2の対象リソース

ORiN2が対象としている機器デバイスは,プル型とプッシュ型のデバイスです.
プル型(ストア型)デバイスは,値を格納する領域を機器の中に持っており,外部からの要求に応じる形で値を返します.これに対して,プッシュ型(イベント型)デバイスというのは,任意のタイミングで機器内部から外部に値を送り出すタイプのデバイスを指します.
ORiN2では,プッシュ型デバイスの対応をCaoControllerオブジェクトのOnMessageイベントにCaoMessageオブジェクトを渡して,機器から送り出された情報をクライアントプログラムで取得できるようにしています.あるいは,動作モード指定により,一旦,CAOエンジンが機器から送り出された情報をCaoMessageオブジェクトに格納して,そのオブジェクトをキューに貯め,任意のタイミングでクライアントプログラムからの要求に応じる形で情報を渡すようにしています.

 

3. CRD

CRD(Controller Resource Definition)はFAデバイスが持つ各種静的リソースをXMLで記述するための規格です.そのデータスキーマをCRDスキーマと呼び,このCRDスキーマに従い記述されているXMLファイルをCRDファイルと呼びます.CRDスキーマの詳細に関してはORiN2 SDKのCRDSchema.xsd ファイルを参照してください.
CRDはFAデバイスの情報をファイルとして管理するためにあります.

〔図5〕 CRDファイルへのアクセス

CRDの機能を実装したプロバイダがCRDプロバイダ(CaoProvCRD.dll)です. CRDスキーマで定義された書式に従って書かれたXMLファイルにアクセスするためのプロバイダです.〔図5にCRDプロバイダがCRDファイルにアクセスする構造を示します.CRDファイルはCRDプロバイダ経由でアクセスする方法ともう一つ,ネイティブアプリケーションでXMLパーザを組み込み,直接アクセスする方法の二通りがあります.

〔図6〕 エンジンの静的情報マージ機能

CAOエンジンには,CAOプロバイダの静的情報を補完するために必要な情報をCRDファイルから取得してクライアントアプリケーションに返す機能があります.CAOプロバイダは情報取得の要求に対してE_CRDIMPLの値を返せば,エンジンが自動的にCRDプロバイダ経由でリンクされているCRDから対応する情報を取得して返しますという仕組みになっています.

■CRDの要素とCAOのインターフェイス

CRDスキーマでは,CAOインターフェイスとCRDの各要素とが密接に関連するように設計されています.

〔表 3〕 CRDの要素とCAOインターフェイスとの関連
CRD 要素名 CAO インターフェイス
Controller CaoController
Command CaoCommand
Extension CaoExtension
File CaoFile
Robot CaoRobot
Task CaoTask
Variable CaoVariable

〔表 3から分かるように,CRDの要素とCAOインターフェイス(内のプロパティ)はほぼ一対一で対応しており,直感的に理解しやすいデータ構造になっています.

また,VariableのValue要素,CommandのParameters要素及び各オブジェクトのID要素はVARIANT型を表現するための構造を持ちます.

VARIANT型の要素は保持するデータ型を指定するために,属性値として“Type”を持っています.CRDでは,このType属性値とそれに対応するデータ型の要素を与えることでVARIANT型を表現しています.型タイプを表すType属性値の値はあらかじめ取り決めています.Type属性値とVARIANTのデータ型の対応を〔表 4に示します.

〔表 4〕 バリアント型の型タイプ属性値とデータ型
型タイプ属性表記 データ型の名称
タグ表記 XML Schema 内の型
VT_I2 iVal Short
VT_I4 lVal Int
VT_R4 fltVal Float
VT_R8 dblVal Double
VT_DATE dateVal dateTime
VT_BSTR bstrVal String
VT_BOOL boolVal Boolean
VT_UI1 bVal unsignedByte
VT_VARIANT varVal Variant
VT_ARRAY array array

VARIANT型の要素を使って配列を表現する場合は,array要素をその子要素として追加し,さらにその子要素として次元数をあらわすdimension,各次元の要素数をあらわすarrayBound,配列の個々のデータをあらわすarrayDataを持ちます.arrayBoundは要素としてその次元に対するインデックスの起点を表すlBoundと要素数をあらわすelementsを持っています.arrayDataは子要素として各型の要素を持つことにより,任意の型のデータを取ることができます.

4. CAP

CAPとは,Controller Access Protocolの略で,インターネット経由でCAOプロバイダにアクセスするための「インターネット向け通信プロトコル」です.CAOエンジンを利用して,リモートのCAOプロバイダにアクセスするためにはDCOMを利用していますが,DCOMはセキュリティ上の制約から,インターネットを介したアクセスは実質上不可能です.また,企業などで存在するファイアウォールを越えてリモートアクセスすることは通常できません.そこで,この問題を解決するためにORiN2ではCAPが開発されました.
CAPは,SOAP(Simple Object Access Protocol)を使用して,インターネット経由でオブジェクト間のリモートアクセスを実現するためのプロトコルです.ORiN2 SDKでは,CAPプロバイダを提供することにより,CAPの仕様に従ったメッセージを作成,送信することができます.これにより,HTTPで接続可能な環境であれば,容易にインターネットを介してリモートのプロバイダに接続することが可能となります.
〔図7の[3]に示すように,CAPプロバイダはリモートのCAOプロバイダに接続するためのCAPメッセージ(SOAPパケット)をWebサーバへと送信します.Webサーバにより呼び出されたCAPリスナはメッセージを解析し,目的のCAOプロバイダを呼び出して必要な情報の受け渡しを仲介します.これにより,クライアントアプリケーション側では,ローカルに存在するロボットコントローラと同様に,インターネット経由でロボットコントローラにアクセスすることができます.
このCAPの機能を実装したプロバイダがCAPプロバイダ(CaoProvCAP.dll)です.
CAPでのSOAPパケットに関する厳密な仕様は,ORiN2 SDKのCAPプロバイダのCapListener.WSDL ファイルに定義されていますので詳細に関してはそちらを参照して下さい.

〔図7〕 CAPの動作

CAPのクライアントとサーバの接続形態は〔図7で示す通り,四つあり,[3]に関しては先ほど説明した通りで,CAPの機能を持たないCAOプロバイダであってもCAOのリモートエンジンの機能とCAPプロバイダの仲介でインターネント,ファイアウォールを越えてアクセスする経路です.[1]と[2]はクライアントアプリケーションが自前でCAPの機能を実装した場合の経路を指します.また,[4]は逆にサーバ(機器)側が自前でXMLパーサ,SOAPを使用してCAPの機能を組み込んだ場合の経路を指します.[3],[4]の接続形態はCaoControllerオブジェクトを生成する際のAddControllerメソッドのオプション引数によって決まります.

〔表 5〕 CAPのAddControllerメソッドのオプション引数
オプション 意味
Provider[=< プロバイダ名 >] リモート起動するプロバイダ名.
Server[=<We bサーバ名 >] WEB サーバ名を指定します.
Machine[=< マシン名 >] WEB サーバと異なるマシンでリモートプロバイダを起動するときに指定します.
Option[=< オプション文字列 >] リモートプロバイダに必要なオプション文字列を指定します.
Message[=<True/False>] メッセージ取得の有無.

■e-CAP

CAPプロバイダはインターネット経由で情報をCAPリスナとやり取りする際にXML形式でSOAPパケットに情報を乗せて通信と行います.これは通常のDCOMの直結接続に比べて実に多くの処理を経て,余計なオーバヘッドが生じるため,用途によっては使用できない場合があります.また,組み込み機器等ではSOAPパケットに対応する処理,あるいは,XMLを解釈するためのXMLパーザの機能を実装することは容易なことではありません.そこで,ORiN2ではこれらの問題に対処するため,XMLを使用しないで,単純にHTTPのPOSTコマンドに必要な情報を格納して通信を行うバージョンのCAPが開発されました.これがe-CAPです.

■b-CAP

b-CAPは,CAPの概念を踏襲しつつ,通信速度の向上を狙ったプロトコルです.これにより,b-CAPはCAPファミリと同様な以下の特徴を持っています.

  • CAOプロバイダのオブジェクトモデルと同様なサービス構造
  • オブジェクトIDで対象オブジェクトを指定しての関数呼び出し
  • サーバからのイベントをポーリングで実現

b-CAPはTCPストリーム通信として実装されます.これはb-CAPのパケットにチェックコードが存在しないため,下位層のプロトコルでエラーフリーなプロトコルが必要なためです.

〔図8 〔図9 〔図10は同じ意味のメッセージをCAPとe-CAPとb-CAP,それぞれで処理した場合の動作を表しています.また,〔表6はDCOMでのアクセスを1とした場合のCAP,e-CAP,b-CAPとの時間によるパフォーマンス比較を表しています.御覧のようにe-CAPではCAPに比べてアクセスに掛かる時間が改善されていることがわかります.また、b-CAPではCAPに比べて4倍の速度を実現しています.

〔図8〕 CAPのメッセージ

〔図9〕 e-CAPのメッセージ

〔図10〕 b-CAPのメッセージ

〔表 6〕 e-CAP, b-CAPのパフォーマンス
CAO CAP e-CAP b-CAP
プロトコル DCOM HTTP+XML HTTP TCP
時間 (ms) 499.67 6453.33 5646.00 1578.33
比率 1 12.92 11.30 3.16

■ 測定条件: PC2 台 ( ペン 4 2.8GHz, WinXP SP2) を 100Base-HUB 経由のローカル接続,
  4 バイト整数値を 1000 回連続取得.

このページのトップへ