|
森基金報告書 ホームネットワークにおけるユビキタスサービス連携定義言語の 多様性を考慮するサービス連携システムの研究 政策・メディア研究科 高橋 元 １．研究概要 近年，ホームネットワークでは，情報家電等様々なアクチュエータがネットワーク接続され，また，実世界の情報を取得するセンサノードも高度な計算能力及びネットワーク接続能力を持つようなった．これらアクチュエータ及びセンサをサービスと呼ぶ．これにより，センサから取得した情報を元に，アクチュエータを連動させ動作するアプリケーションが実現される．単一のホームネットワークを見た場合，今後これらアクチュエータやセンサの数，種類はさらに増大することが予測される．また，動的なサービス連携定義が可能な分散オブジェクトシステム上にアプリケーションを構築することで，サービス連携定義者もアプリケーション開発者のみならず，利用者，サービスエンジニア，ソフトウェアなど多様となる．これら各定義者の記述能力も多様であるため，多様な連携定義言語が存在する． このようなホームネットワークでは，利用者は，１）適切な抽象度でサービス連携を定義できることが望まれる．これにより，ソフトウェア開発者のみならず，利用者の要求に即応してサービス連携の再定義が可能となる（End User Programmability）．また，利用者は，２）他の連携定義者により定義される連携定義を適切な抽象度で統一的に確認できることが望まれる(Conjunction Accountability)．これにより，他のソフトウェアコンポーネントが自律的に連携を再定義した場合も，利用者は，ホームネットワークでどのようなサービス連携が現在行われ，それが要求に合致しているか，確認できる．しかし，他の定義者により定義された連携を統一的に利用者が「確認」することは，各言語の連携定義モデルが異なるため困難である．連携定義言語開発者にとっては言語ごとに利用者向けのビューワを用意しなければならない．また，利用者にとっては，各言語に付属するビューワが統一的なモデルにより連携を表現しないため，各ビューワごとに連携定義モデルの再学習が必要となる．これを本研究では，ホームネットワークにおける連携定義言語のテロジニティー問題と呼ぶ．我々は，１）利用者自身が自然言語でサービス連携を定義し，また，２）利用者が他の連携定義言語による連携定義を自然言語で統一的に確認できるホームネットワークにおけるユビキタスサービス連携定義言語のヘテロジニティーを考慮するサービス連携システムPod-Morphの研究・開発を行った． ２．Smart Living Room 情報家電やセンサーネットワークが配備され，ホームオートメーションの実証実験空間の構築を行った．次のデバイスが配備され，ネットワーク接続され，遠隔から制御及び情報の取得ができる． １．TV (ア) IRDAにより制御 ２．DVD (ア) IRDAにより制御 ３．位相制御可能スピーカ (ア) IPネットワークにより制御 ４．床したに配備されたRFID (ア) RS232Cにより制御 ５．超音波によるものの位置情報 (ア) RS232Cにより制御 ６．電灯 (ア) MIDIにより制御
７．RFIDによる入退室管理 RFIDにより入退室管理を行うことにより，利用者の在室を検知する．
RFIDがつけられた入退室端末 ３．U-Middleware 情報家電やセンサーネットワークを統合的に相互接続する基盤技術u-middlewareの設計・実装を行った．U-middlewareは，情報家電やセンサーネットワークを統合的に接続し，協調動作アプリケーションをメッセージの送受信により実現するメッセージ指向ミドルウェアである．OSI７層モデルにおけるセッション層にメッセージ指向ミドルウェア層を設けることで，協調動作アプリケーションを実現する． これにより，第２節で述べた機器の多様な制御プロトコルを隠蔽する． ３．１u-middleware アーキテクチャ ３．１．１u-component 指向アプリケーションフレームワーク u-middlewareにおけるアプリケーションは，複数のノード上で動くコンポーネント(u-component)の集合である．ノードとは，ネットワークアドレスを持ち，u-middlewareにおける単体の機器を表現する．u-componentとは，u-middlewareからスレッド割り当てられたアクティブオブジェクトでありノード上で活動する．図１に示すようにノード間にまたがるチャンネルを介して通信を行うことで他のノードで活動するu-componentと協調動作を実現する．
図１ コンポーネント指向アプリケーションフレームワーク ３．１．２ u-middlewareモジュールフレームワーク u-textureは，RFIDタグの検知，近接u-textureの検知，u-texture単体の姿勢検知，接続されたu-textureの構造認識を行う．このため，u-textureは，RFIDリーダなどのセンサデバイスを持つ．これらデバイスはモジュール化されたソフトウェアコンポーネント，system-componentオブジェクトとして表現され，u-componentや他のsystem-componentから利用される． また，system-componentは，u-middlewareが配備されるホストごとに追加及び削除できる．これにより，情報家電や他のSmart Furniture用に構成されるモジュール群からなるu-middlewareが配備された他のホスト上のu-componentと第１節第２項で示したアプリケーションフレームワークを用いて，u-texture上のu-component間の協調を実現できる． さらに，u-componentとsystem-component間の通信は，以下の２種類がある． l チャネル経由アクセス チャネルを介してsystem-componentにアクセスすることで，u-componentは，接続されたu-texture上のすべてのsystem-componentに対して透過的にアクセスできる． l ダイレクトアクセス u-middlewareにより管理されるsystem-componentをu-middlewareから取得し，system-componentに定義されるメソッドを呼び出すことで，u-componentは，同一ホスト上のsystem-componentに対して高速にアクセスできる． ３．２．非同期メッセージング u-component及びsystem-componentは，異なるノード上の各コンポーネントとチャネルを介してメッセージを非同期に送受信する．本節では，チャネルに送受信されるメッセージの定義方法について述べる． ２．１メッセージ チャンネルに送信されるメッセージは，本オブジェクトは，jp.ac.keio.sfc.ht.utexture.event.Eventを継承するJavaのオブジェクトとして定義され，メッセージオブジェクトのインスタンスフィールドに宣言されるオブジェクトの型は，以下の制約を持つ． l 上記オブジェクトのフィールドは，以下の４項目に限る Ø void 型以外のPrimitive type Ø void 型以外のPrimitive typeの配列 Ø java.lang.String Ø java.lang.Stringの配列 primitive typeを以下に示す
l 各フィールドは，必ずpublic アクセス修飾子によるgetter/setterを付与する． ３．３送受信されるイベントの外部化の形式 チャンネルを介して送受信されるメッセージはプログラムにおいて，オブジェクトとして表現され，送受信時にXMLに変換/復元される．OSI７層モデルにおけるプレゼンテーション層をJava言語などのプログラミング言語を利用することで，プログラマの負担を軽減し，かつ，u-middlewareのプログラム言語非依存性実現する．次に，メッセージオブジェクトMyTagの定義とそのXML表現の例及びXMLタグの意味を示す． Package jp.ac.keio.sfc.ht.gengen; Public class MyTag extends jp.ac.keio.sfc.ht.utexture.event.Event{ Private int sdf = 11; Private int[] sd = {1,2}; Private String[] sdff = {“hosdf1”,” hosdf1”}; Public void setSdf(int a){ This.sdf = a; } Public int getSdf(){ Return sdf; } Public void setSd(int[] a){ This.sd = a; } Public int[] getSd(){ Return sd; } Public void setSdff(String[] a){ This.sdff = a; } Public String[] getSdff(){ Return this.adff; } } Event型を継承したMyTagオブジェクトは，次に示すXMLに変換され，送受信される． <umiddleware> <externalization class="jp.ac.keio.sfc.ht.gengen.MyTag" time="送信時間" nodeid="送信元ノードID"> <member name="sdf" type="int" value="11"/> <member name="sd" type="int[]" value="01h02h"/> <member name="sdff" type="string[]"> <element>hosdf1</element> <element> hosdf1</element> </member> </externalization> </ umiddleware
> ４．ISPL Smart Living Roomに配備されるセンサや情報家電の状態を取得し，協調動作をXMLにより定義する言語ISPL及びその処理系の設計・実装を行った．ISPLは，状態の因果関係をもとにした記述モデルを採用することで，End User Programabily及びConjunction Accountabilitを実現する．ISPLに基づいた各種フロントエンドを用いることで，利用者自身による連携定義を実現する．また，統一的なモデルを表現するISPLに基づいて定義された連携は，多様なフロントエンド上から部分的に変更・確認可能である．本節では，ISPLの意味及び構文について述べる． ホームネットワークの利用者自身が連携を記述する場合，記述者に状態変数や代数方程式などの数学的知識や分散オブジェクトシステムに関する知識を求めることは困難である．しかし，利用者から見たもの及びその状態の認知，また，実際に起こる事象の因果関係の把握を期待することは現実的である．このような把握は，利用者が日常生活において出来事を自然言語による方法に近いからである．従って，利用者が記述する振る舞いの記述は，自然言語に近い利用者が実際に見て取れる分散オブジェクトの状態の因果関係をもとにした記述モデルが適切と言える．言語が対応する記述モデルから離散時間的記述モデルを排除することで，記述の単純性を実現する．ISPLは，サービスの状態の因果関係を下に定義する．因果関係定義のために，サービスの状態定義を及び，定義された状態を原因とした場合の，結果の定義を遷移規則定義として，サービス連携の定義を行う． ４．１ISPLの意味 ４．１．１状態定義 状態の定義は，まずサービスの集合として定義される．サービスとは，分散オブジェクトのソフトウェア的な状態でかつ排他的関係にある状態の集合からなる．従って，サービスを構成する状態は，時刻t において同時に成立しない．状態とは，分散オブジェクトが不変条件を保つ間の状況を表す．ISPL では，情報家電等をエンティティと呼び，このような状態をエンティティの状態と呼ぶ．一方，空間的状態の定義に関して，エンティティは，実世界上の位置関係を表す空間的状態の集合として定義される．空間的な状態とは，実世界における物理的な位置関係であり，例えば，部屋の中にあるとか，2 つのエンティティが互いに3m 以内に近接している状態である． ４．１．２遷移規則定義 遷移規則とは，情報家電等の状態間の遷移を決定する．遷移規則は，トリガ，遷移先及びガードにより構成される．トリガとは，状態を遷移させる条件を指定する．条件は，エンティティの状態及び状態遷移系列である．また，状態の遷移系列をトリガに指定する場合，遷移系列評価の有効時間を指定する．遷移先とは，トリガで指定した条件が満たされた場合に遷移するエンティティの状態である． さらに，ガードに指定した状態が真であれば，トリガとして指定した条件が満たされた場合の遷移を抑制することができる．エンティティの状態s が真であるとは，エンティティにおいて現在の状態がs であることを指す． ４．２ ISPLのシンタクス ４．２．１状態定義 エンティティ，サービス及び状態は，それぞれ<ENTITY>タグ，<SERVICE>タグ及び<STATE>タグにより定義される．さらに，ISPL における状態遷移と分散オブジェ クトシステムにおいて呼び出される遠隔メソッドとの対応を<entrance_action>タグにより定義する．<entrance_action>タグでは，状態遷移時に呼び出される遠隔メソッド名が定義される．また，分散オブジェクトのクラスの型は<class>タグを 用いる．以下にDTD による構文を示す． <!DOCTYPE ispl[ <!ELEMENT entity (service+ class)> <!ATTLIST entity name CDATA #REQUIRED> <!ELEMENT service (state+)> <!ATTLIST service name CDATA #REQUIRED> <!ELEMENT class #PCDATA> <!ELEMENT state (entrance_action*)> <!ATTLIST state name CDATA #REQUIRED> <!ELEMENT entrance_action (#PCDATA)> ]> また，ISPL では，利用者が情報家電等の低レベルな状態の集合をより高度に抽象化し，新たな状態を定義できる．状態の抽象化の構文をDTD により示す．状態の集合として，時刻 t における状態の集合を指定する場合と，時刻t ¡ m から時刻t において状態の変遷をしていする場合がある．それぞれ，<user_defined_state> タグのtype 属性に，in_a_breath もしくは，in_a_sequential_order を指定する．また，期間m をpriod 属性で指定する． ４．２．２遷移規則定義 ISPL において，遷移規則定義を行うことがすなわち振る舞いを定義することである．遷移規則定義は，トリガ，遷移先及びガードにより構成される．<trigger>タグで，遷移条件を指定する．遷移条件は，状態の集合として，時刻t における状態の集合を指定する場合と，時刻t ¡m から時刻t において状態の変遷をしていする場合がある．それぞれ，<trigger> タグの属性type に，in_a_breath もしくは，in_a_sequential_orderを指定する．また，期間m をperiod 属性で指定する．ガードは，<guard>タグを用い，遷移を抑制する条件として，排他的状態の定義を行う．状態遷移以下にDTD による遷移規則定義 について示す． <!DOCTYPE ispl (behavior)[ <!ELEMENT behavior (transition_rule+)> <!ATTLIST behavior name CDATA #REQUIRED> <!ELEMENT transition_rule (trigger,transition_state,guard)> <!ELEMENT trigger (state+,spatial_state?)> <!ATTLIST trigger type (in_a_breath|in_a_sequential_order) "at_a_breath" period CDATA)> <!ELEMENT transition_state (state+)> <!ELEMENT gard (state+) <!ELEMENT state (entity,service?,name)> <!ELEMENT entity #PCDATA> <!ELEMENT service #PCDATA> <!ELEMENT name #PCDATA> <!ELEMENT spatial_state (entity,name,comparison?,viewer?)> <!ELEMENT comparison #PCDATA> <!ELEMENT viewer #PCDATA> ]> ５．ISPLの処理系 ISPLの処理系は，u-Middleware上で稼動するセンサや情報家電からの情報を収集し，遷移規則を評価する処理系である．さらに，本処理系は，u-Middlewareのu-Componentとして設計・実装されている． ６．フロントエンド フロントエンド ISPLを生成する日本語による連携定義フロントエンドの設計・実装を行った．GUIの画面を次に示す．
７．まとめ 本研究では，ホームネットワークにおいて，利用者自身がサービスの連携を実現するシステムを開発した．本システムでは，状態の因果関係による連携定義モデルを提案した．これにより，他の離散時間モデルのように代数方程式などを定義することなく，自然言語で事象を表現するように，利用者はサービスの連携を定義できる．さらに，ISPLを表現するXML言語を設計実装した．また，日本語によるISPLフロントエンドを作成した．このフロントエンドからXMLによるISPLを生成する．様々な利用者向けのフロントエンドがISPLを生成することで，他の利用者が定義した連携を利用者に適したフロントエンドを利用して連携の定義・確認できる． |
||||||||||||||||||||||||||||||||||||||||
