Vol. 0

情報処理学会論文誌

No. 0

1959

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構
落 合 秀 也†

江 崎

浩†

ネットワーク通信機能を持った汎用 I/O(GPIO) の応用で遠隔制御や遠隔モニタリングが可能になったが，制御においてベンダー固有の通信プロトコルを考慮する必要がある現状では，制御ソフト
ウェアの開発効率や再利用性を向上させることはできない．本研究は，制御ソフトウェア向けに高級言語で制御インタフェースを提供する一方，ネットワーク接続された組込み機器との固有の通信を翻訳スクリプトとして記述することで，制御ソフトウェアから隠蔽する翻訳機構を提案する．提案する翻訳機構は，(1) 制御ソフトウェアの開発を容易にし，(2) 制御ソフトウェアの再利用性を向上させる．
翻訳スクリプトを Web 等で公開させることで (3) 誰でも自由に組込み機器への制御インタフェースを公開できる．本研究では，翻訳機構のプロトタイプ実装を作成し，システム評価を行い，組込み機
器のソフトウェアには全く手を加えることなく，これらの性質を満足することを確かめた．

Networked GPIO Control by High-Level Languages and Protocol Translator
Hideya Ochiai† and Hiroshi Esaki†
Remote control and monitoring enabled by networked GPIO force system developers toaware unique protocols for the devices. This indicates low eﬃciency in development and low
reusablity of application software. We propose an translator that provides high-level language
interfaces for application and hides detailed communication protocols of devices. Our proposed translator enables (1) to ease programming, (2) to improve reusability of the software,and (3) anyone to publish the accessibility of their GPIO devices. We conﬁrmed our prototype
system satisﬁes these properties.

制御インタフェース (デバイスインタフェースと呼ぶ)

1. は じ め にとの結合関係を翻訳スクリプトに記述しておき，セン

近年の組込みコンピュータの小型化／高効率化によ

サやアクチュエータの制御実行時に，これらを動的にり，インターネットを介した汎用 I/O(GPIO) の遠隔結合させる翻訳機構を提案する．翻訳機構を，制御ア制御が可能になっている．独自の機器を GPIO に接

プリケーションの基本コンポーネントとして導入する

続し，遠隔地の環境情報観測や，アクチュエータ機器

ことにより，次の 3 つの効果がもたらされる．

制御を実現しているアプリケーションも見受けられ(1)

る7),15)．これらのアプリケーションでは，組込み機器

制御ソフトウェアの開発が容易になる
開発者は下位通信プロトコルを意識しなくて済

ベンダーごとに独自の TCP/IP 上の軽量通信プロトコ

むようになる．

ルを使っている場合も少なくない2),13),14) ．現在，制(2)

御ソフトウェア開発においては，対象とする組込み機

制御ソフトウェアの再利用性向上
特定の機器だけでなく他の機器にも同じ制御ソ器に応じて，様々な環境が要求される．高級言語 (e.g.,

フトウェアを使える．

Java, Perl, C#, XML) で制御ソフトウェアが記述さ(3)

スケーラブルなオープン性

れ，機器に依存しない動作環境を用意することができ翻訳スクリプトを Web 等で公開することで，誰れば，ソフトウェアの開発効率および再利用性を向上

でも自由にセンサやアクチュエータへのアクセさせることができると考えられる．

スを提供できる．

本研究は，高級言語制御インタフェース (単に，制御

これらの効果を組込み機器のソフトウェアを変更せず

インタフェースと呼ぶ) と組込み機器が提供する GPIOに提供可能である．
本研究が対象とする組込み機器 (別名，デバイスと呼ぶ) とは，遠隔地に設置され，デジタル I/O やアナロ

† 東京大学
The University of Tokyo

グ I/O を，インターネット越しに低速に (100ms 以上
1

情報処理学会論文誌

2の精度で) 読書きできるものである．低速なのは，ネッ
トワーク遅延による限界に由来する．GPIO に接続さ1959

6 章で考察する．
スクリプト言語を採用したため，処理能力の低下れる機器は，標本精度が数秒ほどでも十分なもの，例(e.g., 遅延の増加など) が懸念されるかもしれない．本

えば，温度センサや DIP スイッチ，電源の ON/OFF研究では，プロトタイプシステムを構築し，動作を確

コントローラ，キャラクタディスプレイ，照明の輝度

認すると共に，スクリプト言語方式が，この点におい制御装置などを想定する．これら遠隔 GPIO の先に接て，遠隔 GPIO のアプリケーションにとって実用的か続される機器をサーバと呼び，汎用コンピュータからどうかも検証する．

観測や制御等のためにリクエストを発行する制御ソフ

本論文の構成は以下の通りである．第 2 章で関連技

トウェアのことをクライアントと呼ぶことにする．本術を述べる．第 3 章で翻訳機構アーキテクチャを述べ，研究では，サーバへのインターネットからの到達性は

第 4 章で，プロトタイプ実装について言及する．第 5確保されているものとする．サーバの利用権限はすべ章で，プロトタイプシステムを使った評価実験を行い，てのクライアントに開かれているものとし，クライア

第 6 章で考察を述べ，第 7 章でまとめる．

ントのアクセスコントロールは将来的な課題である．
通信形態は，Remote Procedure Call(RPC) 型のみを考え，イベント通知型は本研究では扱わない．

2. 関 連 技 術
GSN1) は，Wrapper デザインを応用した仮想化に一般に，異なる表現で定義されたインタフェースをより，複数種類の無線センサネットワークのインタ

接続する方法としてよく知られたものに Adapter デフェースを抽象化している．Janus4) は，Agent が，

ザインパターン (別名 Wrapper)5)の応用がある．イ

無線センサネットワークごとに通信に必要な Adapter

ンターフェース間のメソッド名の対応付けや，データを管理しており，クライアントが指定した通信相手へ表現の変換に良く使われるデザインである．制御インの Adapter を動的に選択する．これらの研究においタフェースの定義が決まれば，制御インタフェースとては，Adapter ライブラリの管理運用方法について深デバイスインタフェースとを繋ぐ Adapter を実装すく考察されていないようである．我々の提案システムればよい．Adapter により，デバイスインタフェース

は，誰でも自由にライブラリを翻訳スクリプトの形では隠蔽され，制御ソフトウェアは，制御インタフェー

公開可能にし，分散的に動作するように構築されていスを使ったプログラムとして記述される．

る点でこれらの方式と比べ優れている．

本研究は，Adapter をスクリプト言語で記述してお高級言語インタフェースをアプリケーションに提き，クライアントの通信対象とするサーバに応じて，供し，遠隔サービスとの通信における，下位通信プ

適切なスクリプトを選択後，クライアントコンピューロトコルを隠蔽する技術としては，Interface Deﬁ-

タ上で実行することで，制御インタフェースとデバイ

nition Language(IDL) 関連の技術 (e.g., Microsoft-

スインタフェースの間を動的に接続する手法を提案すIDL6) , WSDL3) ) がある．定義された IDL から，RPCる．このスクリプトのことを翻訳スクリプトと呼び，のサーバスタブやクライアントスタブを自動的に作成

インタプリタを翻訳プロセッサと呼ぶ．各クライアン

することで，下位通信の詳細を隠蔽する．同一の IDL

トは，ローカル環境にライブラリ等の方法で，翻訳プをグローバルに共有すれば，ソフトウェアの再利用性

ロセッサを用意し，サーバへのリクエスト発行時に，対を向上させることもできる．本研究で提案する翻訳ス

応する翻訳スクリプトを実行させることで，Adapter

クリプトも，下位通信プロトコルを隠蔽する点は IDL

機能を再現する．

と同じである．IDL は，通常，対等な言語レベルのサーバと通信を行うためには，そのサーバに対応すソフトウェア間通信を実現することが目的であるのにる翻訳スクリプトを取得することができればよい．し対し，翻訳スクリプトは，異なる表現レベルの通信をたがって，例えば Web を介して翻訳スクリプトの提Adapter により結合させることを目的としている．

供と取得を行うことにすれば，サーバの公開に分散性とオープン性を与えることができる．

温度センサなどの機器を操作するための API を，機器の運用者がサービスとして提供し，クライアントが本研究は，すでに翻訳スクリプトが Web 等で提供

これを使って，間接的に操作する方式も考えられる．

されている状況を想定し，翻訳機構のシステムが制御

しかしこの手法は，サービスの信頼・安定性，可用性，

ソフトウェア (クライアント) の開発効率を向上させ，

スループット等についての検討課題を生み出す．本提そこに再利用性を持たせられることに主眼を置く．翻案システムでは，クライアントとデバイスは IP 到達

訳スクリプトを作成する実際的な方法については，第性があれば通信可能で，中間的なサービスの性質を気Vol. 0No. 0

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構

図 1 翻訳機構アーキテクチャ
Fig. 1 Translator architectureにしなくてよい．例えば，ポーリング型のアプリケー

図 2 デバイス (PICNIC) からの温度取得操作
Fig. 2 Temperature acquisition from a device (PICNIC)

invoke(s, m, p)

ションにおいてはすべてのリクエスト／レスポンスが

s: サーバ名IP レベルのルーティングで配送処理される．したがっm: 制御インタフェースのメソッド名て，中間サービスを導入する方式に比べて，スループッ

p: パラメータ値

トが問題になるケースは稀である．このように本提案

戻り値: 応答メッセージシステムを用いると，中間サービスに関する様々な検討課題から解放される利点がある．

3

この命令は，サーバ s に対してメソッド呼出し m(p)を発行することを意味する．デバイスインタフェース

ソフトウェアを，動的に他のコンピュータに転送し，の詳細は隠蔽され，クライアントは，常にこの命令にその場で実行させる技術は，Code Migration や Mo-

よって提供される制御インタフェースを利用する．s,bile Agent として知られている12) ．本研究は，プロm, p のスキーマは，グローバル権威により管理され，トコル翻訳に必要なコードをスクリプト言語として記実際のアプリケーション開発は，それに従う．IETF10)

述し，クライアントコンピュータ上で呼び出せるようや IEEE9) などの標準化団体，もしくは IANA8) などにした点で，これらの技術の応用と位置づけられる．

の名前運用権威団体によって，コマンド名やパラメー

3. 翻訳機構アーキテクチャ
図 1 に，本研究で提案する翻訳機構アーキテクチャを示す．デバイスは，RPC 型でサービスを提供してタセットを管理しておき，翻訳スクリプトの作成，および，クライアント開発が，これに従うことで，制御インタフェースに互換性を持たせ，ソフトウェア再利用性が達成されるようになる．

おり，クライアント側のコンピュータには，(1) 制御

s の例としては，DNS の FQDN や URL が考えら

ソフトウェアのインスタンスであるクライアント・ア

れる．m(p) は，具体的には，n を表示することを，プリケーション及び (2) 翻訳プロセッサが搭載されてdisplay(n); のように定義できるし，XML での命令表

いる．多数のユーザが参照するレポジトリがあり，こ記<display number=”n” />のように定義することもこで翻訳スクリプトが管理／提供されている．

できる．

このアーキテクチャ上での基本的な動作は次のよう

3.2 デ バ イ スになる．クライアントがサーバを指定し，翻訳プロ

デバイスは，TCP/IP での軽量な通信は可能だが，セッサに RPC 要求を発行すると，翻訳プロセッサは

Web サービスほどの高級な通信機能は備えていない．

レポジトリからそのサーバに対応するスクリプトを読サーバとの通信は，UDP や TCP 上の簡素なプロト込み，要求を翻訳後，デバイスに要求を発行する．デコルで提供されている．図 2 に，具体例として，PIC-

バイスからの応答は再び翻訳され，クライアントに返NIC14) から，温度を取得する場合を示す．PICNIC

される．

では UDP 上のプロトコルにより，温度センサから値

3.1 アプリケーションを読み出すためのデバイスインタフェースが提供されサーバ・アプリケーションは，デバイスが提供するている．図のようなリクエストを発行することで得ら

GPIO に接続された機器である．具体的には，温湿度れる応答結果の中から，特定のオクテット列を取り出

センサ，DIP スイッチ，電磁リレー，照明などが GPIO

し，計算式 X × 128 + Y /2 を適用することで，温度に接続されるサーバ・アプリケーションである．

(℃) として取り出すことができる．

クライアント・アプリケーションは，翻訳プロセッ

サーバ・アプリケーション開発は，複数の組織により

サから提供されている下記の invoke 命令を通じて，独立に行われる状況が一般的である．同じような機能

RPC 要求を発行する．

を持つサーバであっても，GPIO への実装方法 (e.g.,

情報処理学会論文誌

4

1959

図 3 典型的なメソッド (m) の実装形態
Fig. 3 A typical implementation for method(m)図 4 翻訳プロセッサ周辺の一連の動作
Fig. 4 Behavior of the translation processor

配線方法) や，使用している素子によって，デバイス
インタフェースは異なってきてしまう．本研究ではこのような状況を考え，デバイス側のソフトウェアには手を加えずとも，スクリプトを記述することで制御インタフェースに適合できるアーキテクチャとしている．

3.4 翻訳プロセッサの動作
図 4 に，翻訳プロセッサの一連動作を示す．

(1)

プロセッサは，invoke(s, m, p) を受けると3.3 翻訳スクリプト(2)

サーバ名 s でレポジトリに問い合わせ

翻訳スクリプトは，サーバごとに定義され，サー(3)

翻訳スクリプトを読み込む

バ識別子に対応づけるものとする．クライアントが，

ただし，ローカルキャッシュに有効なスクリプ

invoke(s, m, p) を実行すると，サーバ識別子 (s) を検トがあれば，これを利用する．

索キーに翻訳スクリプトレポジトリから読み出される．

(4)

本研究では，翻訳スクリプトをメソッド集合として定義する．すなわちサーバ s の翻訳スクリプト Ts は，

イム環境に展開する(5)

Ts = {ms1 , . . . , msn }と記述できる．クライアントから発行された m(p)

読み込んだ翻訳スクリプトをパースし，ランタ
アプリケーションから要求のあったメソッドを判別し，呼び出す(6)に対応するメソッド m が，翻訳プロセッサにより実行

実行は，翻訳スクリプトに記述された定義に従って行われ，このときにデバイスとの通信を含むされる．例えば，display(4) の場合，msi = ”display”(7)

メソッド実行の結果がである msi が 4 をパラメータとして呼び出される．

(8)

invoke メソッドの戻り値として，アプリケー

ここで，典型的な m の実装は，図 3 のようになってションに返される

おり，(1) リクエストデータ変換，(2) 通信，(3) レスポ

3.5 翻訳スクリプトレポジトリ

ンスデータ逆変換，を通して，デバイスインタフェー

本研究では，Adapter をスクリプトとして表現する

スを制御インタフェースへ適合させている．

ため，実行されるまでは通常のファイルと同じ方法でスクリプト言語のデザイン次第で，記述可能な扱うことができる．そのため，普段はレポジトリに保Adapter の範囲が決まってくる．言語が UDP ソケッ

管しておき，必要時に，ダウンロードして実行するこ

トしかサポートしていなければ，TCP 通信を利用するとが可能である．実際に利用するレポジトリの名前体

デバイス向けの翻訳スクリプト (Adapter) を作成する

系，管理方法，検索性能が，本提案システムの運用形ことはできない．同じことはデータ加工のための各種態を決定する．URL で翻訳スクリプトを指定できるよ

演算機能にも言える．記述力および利用可能なリソー

うにすれば，サーバ名は URL で識別され，スクリプ

ス数が多いほど，翻訳スクリプトの作成可能な範囲は

トの配置も Web サーバの場合とほぼ同じ運用方式で広くなる．一方，言語の記述力，利用可能なリソース行われる．検索は多くの場合，数秒以内に達成される．

を強化すると，実行先コンピュータのセキュリティ確保の問題もでてくる．これは Mobile Agent に共通す4. プロトタイプ実装

る課題12) であり，本研究の対象外である．本研究で本研究では，提案システムのプロトタイプ実装を作

は，アーキテクチャとしての提案を行うことに焦点を成し，その動作を検証した．動作検証およびアーキテ

おき，スクリプト言語のデザインについては，将来的クチャの評価は次章で行い，本章では，どのように検な研究課題としている．

証システムを実装したかを述べる．本研究では，プロ
トタイプ翻訳プロセッサを，Java v.1.4.2 で実装した．

Vol. 0No. 0

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構

5

図 5 翻訳スクリプトの構造
Fig. 5 Structure of a translation script

Java クラス数は 97 である．以下，翻訳スクリプト言語，翻訳レポジトリ，制御インタフェースの規定，実験環境について述べる．

4.1 翻訳スクリプト言語の規定
本研究では，翻訳スクリプト言語を，XML 上の言語として規定した．理由は，アーキテクチャの検証としては十分な性能を保ちつつ，翻訳プロセッサを短期間で実装することが可能なためなどによる．
図 5 が示すように，XML の上位階層で，command
列 (i.e., メソッド集合) を宣言するよう定義した．それぞれの command の実装部をスタブコードと呼び，この場所に，規定された言語で，翻訳プロセッサの動作を記述する．図 6 の例でその動作を解説する．
図 6 は，図 2 のデバイス (PICNIC) へ UDP 要求を

図 6 メソッド実装の例 (スタブコードの一部)
Fig. 6 An example of method implementation (in thestub code)

発行し，UDP 応答メッセージから，温度を取り出すプ
ロセスを表現している．IP アドレス 203.178.135.84

入力型と出力型に大別し，それぞれを read/write コ

宛に UDP10001 のデータグラムソケットを作成し，re-マンドで表現した．表 2 に示すように，コマンドのquest の配列を送信する．その後，受信したデータグラ

引数で，要求の詳細を識別できるようにした．このイ

ムを response 配列として保存する．response 配列のンタフェース規定は，実験の間，有効であり，クライ

4 番目, 5 番目のオクテットについて，response[4] ×

アントアプリケーションの発行するコマンドはこれに128 + response[5] × 0.5 を計算し，temperature の値

従う．

として格納する．

4.4 設 定 環 境

ここで示したスクリプト言語のコマンドは一部であ

実験では，数値入力，ビット出力，パターン出力をる．本研究のプロトタイプ実装で作成したスクリプト

行うサーバを設置した状況を想定した．同一観測項目

言語のコマンドセットを表 1 に示す．基本的な，四則を持つ二台の異なるサーバも設定した．

演算，ビット演算，論理演算などを定義した他，配列，

図 7 に実験環境を示す．ある部屋と，その屋外の環境

XML 処理を定義した．通信機能には，データグラム

を想定し，部屋には，(1) 温度センサ，(2)LED 表示器，ソケットを定義してある．これらのコマンドを組み合(3) コントロール SW，(4) 左右の照明，(5) 左右の照度

わせて翻訳処理を記述する．

センサが設置されている．(1,3,4,5) は PICNIC に接続

4.2 翻訳スクリプトレポジトリ

し，(2) は仮想デバイスとしてエミュレーションした．

翻訳スクリプトレポジトリは，インターネットに分

屋外に気象センサを設置した状況を設定し，Armadil-

散的に存在する Web サーバ群を利用する形態を取っloWS が，各種の気象項目を観測している．Armadil-

た．すなわち，アプリケーションサーバ識別子を URL

loWS は，Live E!プロジェクト11) で遠隔地の気象デーで表現し，指定された URL から翻訳スクリプトを読タを収集するために開発されたもので，ハードウェアはみ込むように作成した．

Armadillo-2102) である．それぞれのアプリケーション

4.3 制御インタフェースの規定

サーバ識別子は，図に示されている XML ファイルへのプロトタイプシステムでは，制御インタフェースをディレクトリパスであるが，この図では，プレフィッ

情報処理学会論文誌

6

1959

図 7 プロトタイプシステム設定環境
Fig. 7 Experimental organization of the prototype system

表 1 翻訳スクリプト・コマンドセット
Table 1 Translation script command set

Category
Data
Type
Operation
Bit Operation
Logical Operation
Test
Type Cast
BranchLoop
Procedure
Variable
XML DOM

Array
SocketCommandbyte int double text
null true false
plus minus multiply divide modbitand bitor bitxor
bitlshift bitrshift biturshift
and or not xor
eq neq lt gt lteq gteq
castbyte castint
castdouble casttext
if
while
progn
setq getq
domCreateElement
domSetAttribute
domSetTextContent
domGetAttribute
domGetTextContent
byteArray byteArrayAppend
byteArrayGet byteArrayLength
dgSocket dgSend dgRecv dgClose

表 2 プロトタイプシステムで規定した制御インタフェース
Table 2 API deﬁned in the prototype system
コマンド

<read
type=”param”/><writetype=”param0”
value=”param1” />パラメータの例
temperaturehumiditypressure
winddir
windspeed
rainfallilluminanceconﬁgparam0=display,param1=-9.9, —, 99.9
param0=switch
param1=on,oﬀ

述されており，Web サーバ (jo2lxq.hongo.wide.ad.jp)
から誰でも自由に読出し利用することが可能である．
図 7 では，制御クライアントは LAN 内に存在しているが，デバイス (i.e., PICNIC, Armadillo 等) には，
グローバル IP アドレスが与えられており，インター
ネット上から制御可能である．

PICNIC の通信プロトコルは14) を参照されたい．図クス (http://jo2lxq.hongo.wide.ad.jp/) が省略され7 での Virtual Device のプロトコルは，以下のようにている．これらのファイルには，そのアプリケーショなっている．コマンドは UDP 上のオクテット列 [X Y

ンサーバへアクセスするための手順がスクリプトで記

Z W] で構成されており，X=5A(16 進数) がディスプ

Vol. 0No. 0

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構

7

図 8 翻訳機構を使用する場合の記述例
Fig. 8 Source code description with translator

レイへの書き込みコマンドを意味し，Y, Z, W は，3桁の LED ディスプレイの上位桁，中位桁，下位桁にそれぞれ対応している．各桁表示内容は 8 ビットで指定でき，各セグメント (a, ..., g, d.p.) を bit0, ..., bit7に接続した．[5A 5B 86 7F] であれば，21.8 と表示される．

ArmadilloWS は，UDP 上の 1 オクテット命令を発行することで，対応する気象観測項目を文字列で応答する．具体的には，温度 (10)，湿度 (11)，風向(12)，風速 (13)，雨量 (14)，気圧 (16) となっている．
すなわち，湿度の場合，[11] を発行すると，[37 38 2E

34](=78.4) などと応答を返す．

5. システム評価

図9

翻訳機構を使用しない場合の記述例 (PICNIC プロトコルを直接記述した場合)
Fig. 9 Source code description without translator(Description of PICNIC protocol)

5.1 制御ソフトウェアの開発効率
図 8 と図 9 に，PICNIC の温度素子からデータを取得するための，クライアントの記述例 (Java の場合)を示す．図 8 が翻訳機構を使用した場合で，図 9 が，

PICNIC プロトコルを直接記述した場合である．翻訳機構を導入することで，記述量が約 30 行から 6 行に削減できている．ソースコード中で利用されている型(クラス) の数も，11 個から 5 個に削減された．
上記の記述量の比較を，各サーバ・アプリケーショ
ンごとに行ったものを図 10 に示す．翻訳機構を使用した場合とプロトコルを直接記述した場合の Java での記述量 (行数) である．すべてのケースにおいて，記

図 11 要求変換の様子
Fig. 11 Translation behavior of request messages

述量を 20%以下に削減できている．これは，クライア
ント側で行われる制御ソフトウェアの開発効率を向上

ムの送信の様子である．指定されたサーバ識別子に対させることを示唆する．

応するスクリプトを動的に読込み，データグラムを正5.2 動 作 検 証

しく生成して，PICNIC および Virtual Device に発

表 2 で規定した XML 制御インタフェースを用い行されたことが確かめられた．

て命令を発行すると，それが正しく翻訳されて，サー

図 12 は，PICNIC および ArmadilloWS の温度サー

バと通信を行うことができることを確認した．以下，

バへ取得要求を発行した後の，これらのサーバからの値設定と，値取得の場合において，その検証結果を述UDP データグラム応答およびその変換の様子である．

べる．

この例では，温度変化に追従できていることを示すた

図 11 は，部屋の左ライトを ON/OFF する場合 (上め，それぞれのサーバへの温度取得要求を，10 分の段) と数値を表示する場合 (下段) について，発行した間隔をおき，2 度発行している．こうして，翻訳プロ

コマンドと，変換により生成された UDP データグラ

セッサが応答データグラムからデータを抽出し，高級情報処理学会論文誌

8

1959

図 10 クライアント側の記述量 (行数) の比較
Fig. 10 A comparison of source code size

図 12 応答変換の様子
Fig. 12 Translation behavior of response messages

言語表現を生成できることを確認した．
図 13 温度表示制御ソフトウェア (updateTD)
Fig. 13 Temperature monitor control software

本動作検証では，クライアントを外部ネットワークに接続した場合での動作も確認した．この実験により，翻訳スクリプトを公開すれば，誰でも自由にアプ
リケーションサーバを，クライアントに提供可能なことが示された．

している．
以下，実際に，src に下記の引数を指定して実験を

5.3 制御ソフトウェアの再利用性行い，この制御ソフトウェアが，デバイスに依存せず，

図 13 に，制御ソフトウェア updateTD を示す．up-

再利用可能であることを確認した．

dateTD は，サーバ src から温度データを取得し，サー(1)

バ dst のディスプレイに値を出力する制御ソフトウェ
アである．
図 13 のソースコードは実際に通信を行うデバイス

src に”/room/temperature.xml”を指定(PICNIC 温度素子)(2)

src に”/out/weather.xml”を指定(ArmadilloWS の気象センサ)の通信プロトコルを意識せずに記述することができて両ケースにおいて，dst には”/room/display.xml”

いる．これは，異なるデバイスを対象にしていてもこを指定した (各サーバ識別子のプレフィックスは省略)．

の制御ソフトウェア自体は再利用可能であることを示

図 14 に，プログラムの実行の様子を示す．プログ

Vol. 0No. 0

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構

9

図 15 Request/Response 処理時間
Fig. 15 Processing time for Request/Response

おいては，翻訳処理にかかる時間は，平均 2ms 以内
であった．

6. 考察と課題
翻訳機構アーキテクチャを用いることで，GPIO に接続されたサーバを高級言語インタフェースを使って制御でき，これがクライアント側ソフトウェアの開発
効率の向上につながることがわかった．updateTD の記述，および，異なる通信プロトコルを持つ PICNIC
図 14 再利用性の検証実験
Fig. 14 Software reusability testと ArmadilloWS からの温度取得実験により，下位通信プロトコルに依存しない形で制御ソフトウェアを作
成でき，これが実際に両デバイスに適用できることを

ラムは 2 度実行されており，前半が (1) のケース，後実証した．これは，本研究での提案システムが，制御半が (2) のケースである．前半の結果から読み取れる

ソフトウェアの再利用性を向上させたことを意味してことは，PICNIC プロトコルで温度取得後，ディスプいる．

レイに表示コマンドを発行したことである．後半の評価実験のシナリオにおいては，翻訳処理にかかる結果は，Armadillo プロトコルで温度取得後，ディス

時間は 2ms 以内であった．本研究では，ネットワーク

プレイに表示コマンドを発行したことを示す．この間

遅延を 100ms 程度と想定しており，2ms の処理時間はupdateTD には，変更を加えていない．こうして，こ

無視できる範囲だと考えている．実際には，最初の呼の制御ソフトウェアを再利用できることが確認できた．

び出しでは，スクリプトをレポジトリから読み込む時

5.4 翻訳スクリプト処理時間間として，数秒がかかると見込まれる．またキャッシュ

図 15 は，クライアントが，それぞれのサーバと通されるスクリプトの数によっても読み出し遅延が懸念信を行う際の，リクエスト変換，レスポンス変換にかされるかもしれない．前者の問題は，事前ダウンロード

かる平均的な処理時間を示している．処理時間の計測が可能であれば，積極的に先読みすることで吸収可能

にあたっては，Pentium 4, 1GByte メモリを搭載しだと考えられる．後者の懸念は，java.util.Hashtable

たコンピュータ (Linux 2.6.15) 上で，100 回の平均を実装を使えば，スクリプト数が 100 万件程度であれ取った．この図が示すように，評価実験のシナリオにば，低遅延で読み出せることが我々の行った簡単な実10

情報処理学会論文誌

1959

験で明らかになっている．もともと遅延が見込まれてに削減できた．(2) 異なる GPIO デバイスで実装されいる環境なため，本研究での実験シナリオの場合もそる機器にも，同一ソフトウェアが適用可能 (再利用可

うだが，数秒程度の遅延は，実際的な運用場面では耐能) であることが確かめられた．Web 等の分散的なレえられる場合も多い．

ポジトリ環境を利用することで，(3) スケール性の高い

本研究では，翻訳スクリプトが既に用意されている運用を実現できると考えられる．なお，翻訳処理にか状況を設定し，その上で，クライアント側の開発効率

かる時間は数 ms であり，ネットワーク遅延と比較しを考えた．実際に展開する場合には，翻訳スクリプト

無視できることがわかった．実際的な展開に向けては，をどのように用意するかが課題となるが，本研究の段翻訳スクリプトの開発支援技術，制御インタフェース

階では，次のような方法で翻訳スクリプトを用意するの標準化，アクセスコントロールの実現などの課題が方法を考えている．(1) 機器のベンダーがテンプレー

残っている．

トスクリプトを用意し，(2) 機器の設置者が GUI ツー
ルを使ってテンプレートに加工を施す．末端の開発者が，翻訳スクリプトをテキストエディタなどで直接記述する必要はなく，テンプレートおよび GUI ツール
を活用することで，これを比較的簡単に作成できると考えている．この際に，翻訳スクリプトを XML の上に表現することは，自動生成の観点から見て現実的なアプローチである．
今後，本提案システムを実際的な環境に適用していく上での課題としては，制御インタフェースの標準化やクライアントのアクセスコントロールに関するものなどが挙げられる．本研究では，プロトタイプシステ
ムとして制御インタフェースの規定を行い，実験の間，この規定を標準化されたものとして扱っていた．実際的な運用においては，なんらかの標準化団体によって，グローバルユニークに規定されることが必要となってくる．本研究では，アプリケーションサーバに対応するスクリプトを誰でも公開可能で，クライアントはス
クリプトを取得できれば制御可能な環境を想定していたが，実際的な環境においては，サーバに対するアクセス権限実現すべき場合がある．これらは実際に展開していく上での課題となると考えられる．

7. お わ り に
遠隔 GPIO を利用するセンサ／アクチュエータ機器を，高級言語インタフェースで統一的に制御できるよ
うにすることは，制御ソフトウェアの開発効率，再利用性の点で重要である．本研究で提案した翻訳機構アー
キテクチャは，翻訳スクリプトを翻訳プロセッサが動的に読込み実行させることで，このような環境を作り出している．提案アーキテクチャでは，翻訳スクリプ
トはセンサ／アクチュエータ機器と識別子で対応づけられ，レポジトリで管理される．翻訳機構により，制御ソフトウェア開発において，高級言語インタフェー
スで機器の操作を記述することが可能になった．これにより，(1) デバイスの操作に関する記述を 20%程度

参

考

文

献

1) Aberer, K., Hauswirth, M. and Salehi, A.: Infrastructure for data processing in large-scaleinterconnected sensor networks, IEEE MDM
2007 (2007).
2) Atmark Techno. http://www.atmark-techno.com/
3) Chinnici, R., Moreau, J.-J., Ryman, A. and
Weerawarana, S.: Web Services Description
Language (WSDL) 2.0, Working draft, World
Wide Web Consortium (2007).
4) Dunkels, A., Gold, R., Marti, S.A., Pears, A.
and Uddenfeldt, M.: Janus: An Architecture
for Flexible Access to Sensor Networks, ACM
DIN’05 (2005).
5) Gamma, E., Helm, R., Johnson, R. and Vlissides, J.: オブジェクト指向における再利用のためのデザインパターン，pp.149–161, ソフトバン
クパブリッシング (1999).
6) Grimes, R., Stockton, A., Reilly, G. and Templeman, J.: ATL COM プログラミング，chapter1, pp.16–18, Shoeisha, 1 edition (1999).
7) He, D., Bai, Y., Wang, Y. and Wu, H.: A Crop
Field Remote Monitoring System Based on
Web-server-embedded Technology and CDMA
Service, IEEE/IPSJ SAINT2007 (2007).
8) IANA. http://www.iana.org/
9) IEEE. http://www.ieee.org/
10) IETF. http://www.ietf.org/
11) Nakayama, M., Matsuura, S., Esaki, H. andSunahara, H.: Live E! Project: Sensing the
Earth, LNCS, Vol.4311, pp.61–74 (2006).
12) Tanenbaum, A. S. and Steen, M. V.: Distributed Systems, chapterCode Migration, pp.
103–112, Peason Education, Inc., second edition (2006).
13) 三岩幸夫：H8/3069F ネットワーク・マイコン・ボードの概要，トランジスタ技術，Vol.39, No.12,
pp.142–150 (2002).
14) 落合正弘：PICNIC の製作，トランジスタ技術，
Vol.38, No.1, pp.249–261 (2001).
15) 鷺山玲子，土屋 光：PICNIC を利用した He ガ

Vol. 0No. 0

高級言語によるネットワーク汎用 I/O 制御とプロトコル翻訳機構

スメータの遠隔自動計測 (2002).

(平成 ? 年 ? 月 ? 日受付)
(平成 ? 年 ? 月 ? 日採録)

江崎

11

浩

昭和 38 年生．昭和 62 年 九州大
学・工・電子 修士課程了．同年 (株) 東
芝 入社．平成 2 年 米国ニュージャー

落合 秀也（学生会員）

ジ州 ベルコア社．平成 6 年 コロン

昭和 58 年生．平成 18 年 東京大ビア大学・客員研究員．平成 10 年

学・工・電子情報工学科 卒．平成 20

東京大学 大型計算機センター・助教授．平成 13 年 同

年 東京大学大学院・情報理工学系研

大学大学院・情報理工学系研究科・助教授．平成 17 年

究科 修士課程了．同年 同大学大学

同大学大学院・同研究科・教授，現在に至る．工学博院・同研究科 博士後期課程，現在

士 (東京大学)．MPLS-JAPAN 代表，IPv6 普及・高に至る．ファシリティマネージメントシステム，広域度化推進協議会専務理事，WIDE プロジェクトボード

センサネットワーク，耐遅延ネットワークの研究に従メンバ，JPNIC 副理事長，ISOC 理事．

事．