情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

IEEE1888 通信スタックの組込み向け軽量実装
落合 秀也1,a)

井上 博之2

寺西 裕一3

江崎 浩4

受付日 2012年11月5日, 採録日 2013年4月5日

概要：インターネット上のセンサデータ配送に HTTP/XML 通信が広く使われようとしているが，これはハードウェアやメモリ容量などに制限の多い組込みシステムにとって，挑戦的な課題となっている．我々
は，センサデータやアクチュエータ制御コマンドの交換に HTTP/XML を使用する IEEE1888 通信プロト
コルに着目し，この通信スタックの軽量実装手法を研究した．本研究で開発した IEEE1888 通信スタック
は，WRITE クライアント機能が 1,820 バイト，FETCH クライアント機能が 3,360 バイトの大きさを持ち，Java，.NET Framework，PHP5，Ruby などの SOAP ライブラリ上に実装された IEEE1888 通信ス
タックと相互に通信できることが確認されている．
キーワード：機械間通信，XML，IEEE1888

Lightweight IEEE1888 Protocol Stack for Embedded Systems
Hideya Ochiai1,a)Hiroyuki Inoue2

Yuuichi Teranishi3

Hiroshi Esaki4

Received: November 5, 2012, Accepted: April 5, 2013

Abstract: HTTP and XML are getting widely used for sensor data delivery over the Internet. This raises
a challenge to embedded systems for limitted memory resources and other hardware reasons. In this paper, we focus on IEEE1888 communication protocol that uses HTTP and XML for exchanging sensor data
and actuator-control signals, and show how we can implement it in a lightweight manner. The IEEE1888
communication stack that we have developed in this research has 1,820 bytes for WRITE-client functions
and 3,360 bytes for FETCH-client functions. It can communicate with IEEE1888 communication stacks
implemented on standard SOAP libraries including Java, .NET framework, PHP5, Ruby.
Keywords: Machine-to-Machine communication, XML, IEEE1888

1. はじめに（IoT）[4], [7], [20] や Machine-to-Machine（M2M）[15] と呼ばれる分野に成長し，広域監視制御のアプリケーション

2000 年代に入ってから，インターネット技術は，センサ（e.g.，施設管理 [26] やスマートグリッド [6]）のための基機器やアクチュエータ機器との通信媒体としても利用され盤技術となりつつある．一方で，Web 技術やデータベー

るようになってきた．この動きは，近年 Internet of Things

ス技術との親和性を高めるために [11]，インターネット側の通信に HTTP や XML のような高次な通信プロトコル

1

2

3

4
a)

東京大学/NICTThe University of Tokyo, Bunkyo, Tokyo 113–8656,
Japan/NICT, Koganei, Tokyo 184–0015, Japan
広島市立大学/NICT
Hiroshima
City
University,
Hiroshima
731–3194,
Japan/NICT, Koganei, Tokyo 184–0015, Japan
NICT/大阪大学
NICT, Koganei, Tokyo 184–0015, Japan/Osaka University,
Suita, Osaka 565–0871, Japan東京大学
The University of Tokyo, Bunkyo, Tokyo 113–8656, Japan
jo2lxq@hongo.wide.ad.jp

c 2013 Information Processing Society of Japanやデータフォーマットを用いる傾向にある [13], [16]．汎用の HTTP や XML 処理ライブラリは多くのフットプリン
ト（動作するのに必要なプログラムやデータがメモリ上に占めるバイト数）を要求するため，組込み機器によっては，実装上の制約となる場合もある．
本 研 究 で は ，HTTP/XML を 用 い る 通 信 方 式 と し てIEEE1888 [12], [17], [27] に着目し，この通信プロトコル
スタックを，8 ビットのワンチップマイクロプロセッサに実1849情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

装する技術を研究している．IEEE1888 は，インターネッ

3 章で IEEE1888 通信プロトコルのうち，本研究で関係すトを介した，センサからの値収集やアクチュエータ制御なる部分を述べる．4 章で本研究で行った軽量化の手法を整どを SOAP 通信 [18] で交換するプロトコルであり，デー

理し，5 章で，実装と評価結果を述べる．6 章で考察およタベースや Web などへの連携（i.e.，システム・インテグ

びまとめを行う．

レーション）をスムーズに行うことを可能にしている．一
般に，SOAP 通信を実現するには，Java の Axis2 ライブラ

2. 関連研究

リや，.NET Framework のような，フットプリントが，数施設管理やビルディング・オートメーション，あるいは百メガバイトを持つようなライブラリを利用する必要があ

ホーム・オートメーションのシステムや機器の設計・開発

る．しかし，実際には，IEEE1888 のように通信規格が定は，主に産業界で行われている．有名な通信方式としては，

まってしまえば，データ構造が定まるため，必ずしもそのLonworks [14]，BACnet [5]，ZigBee [22]，Z-wave [21] などような SOAP 通信ライブラリを使う必要はなく，もっと軽があり，組込み機器に実装されて，各所で使われている．

量な実装が可能である．我々は，この原理に基づいて組込

ただし，これらの通信方式では，ごく一部の例外を除き，

みコンピュータ向けに独自の IEEE1888 通信スタックを開

主にバイナリフォーマットのメッセージをやりとりする．

発することになった．

近年，インターネットを活用した遠隔の監視制御が一般

組込みコンピュータにも様々な種類があり，たとえば，的になり，インターネット側に計測データや設備ステータ

Linux 系のオペレーティングシステム（OS）を動かすことス情報を取り出し，インターネット側から制御コマンドが可能なもの（e.g.，ARM CPU が使われている）から，OSを発行するようなシステム形態が増えてきた．その際に，がほとんど存在していないようなもの（e.g.，ATmega328P

データベースや Web などと連携をすることになるため，そで動く Arduino [2] など）まで多様性に富んでいる．我々のエンジニアが扱いやすい，HTTP や XML による通信がの研究では，下記の理由で，後者のコンピュータ・プラッ

規格化されている．その 1 つとして，IEEE1888 [12], [17]トフォームをターゲットとし，その環境で動作可能な通信があり，また，oBIX [16]，BACnet Web Services [5] など

プロトコルの実装手法を研究することになった．

もある．

まず，後者のコンピュータ・プラットフォームは，ハー

小型のマイコンに TCP/IP 通信スタックを実装した例は，ドウェアが，部品点数で 50 点，ネットリスト*1 で 250 行，

Dunkels [9] や PICNIC [24] などがある．ただし，TCP/IP

ピン数が 300 点程度ぐらいで実現可能である．つまり，時の場合は XML 文書と異なり，通信メッセージはバイナリ間を費やすことなく，基板のパターン設計を行うことがで

フォーマット化されている．XML 文書を取り扱う場合にきる．CAD を使えば 1 日〜1 週間程度で基板の設計が完は，XML の要素名や，名前空間のプレフィックスなどを了し，さらに 1 週間あれば基板製造や部品実装まで行うこ

意識する必要がある．また，HTTP/XML による通信は，とができる．前者のコンピュータ・プラットフォームの場

Remote Procedure Call（RPC）が通信の基調となるケー

合は，部品点数，ネットリスト行数，ピン数が何倍もあり，スも多く，たとえばクライアント機能の実装に徹底する開発のハードルは急激に高くなる．

など，着眼点も異なってくる．なお，最近は組込み向けのまた，後者のコンピュータ・プラットフォームは，ハーTCP/IP ハードワイヤードチップ（e.g.，W5100 [19]）が登

ドウェア・アプリケーション機能（たとえば，温度計測，場したため，TCP/IP はソフトウェアで実装しなくてもよ

パルス検出，LED 表示版のダイナミック点灯表示，Pulse-

くなってきた（本研究で使用したハードウェアも W5100

Width-Modulation（PWM）制御など）を直接プログラミを利用している）が，XML を使うプロトコルに関しては，

ングすることができる．Linux 系の OS が動く組込みコン

いまだ組込み向けのチップは存在していないものと思わ

ピュータ（たとえば，Armadillo [3]）の場合には，必ずしれる．

も周辺 I/O が充実しているわけではないため，専用のアプ

XML を組込み機器で扱う際に，同等スキーマでバイナ

リケーション・ハードウェアを別途用意し，その間との通リ変換が可能な Eﬃcient XML Interchange（EXI）を使え

信をシリアルで行うなどする必要がある．

ばよいとする考え方や試みもある [7], [8]．特に，無線通信

本研究は，このような理由から，IEEE1888 通信スタッの場合には XML を EXI 化することで通信量を落とすこと

クを，OS がほとんど存在しないようなコンピュータ・プ

が可能である．また，バイナリ表現を使うことにより，プ

ラットフォームに載せることに意味があると判断し，そのログラムメモリ上の定型文が圧縮できるなどの可能性もあ

実装手法を研究したものである．
以下，本論文の構成を示す．2 章で関連研究を取り上げ，*1

る．ただし，EXI を使う場合にはネットワークの途中で，何らかの機器やソフトウェアが，EXI↔XML 変換を行う必要があり，ネットワークの構造に制限を与えるものになっネットリストとは回路網の接続関係をリストで表現したものである．小さいほど，回路構成が単純になりハードウェア開発に柔軟性が増す．

c 2013 Information Processing Society of Japanてしまう．また，EXI だけで完結するのであれば，本来のXML の利点であるたとえば可読性を失ってしまうことに1850情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

もなる．可読性は Web や DB などの開発に関するエンジ

チュエータをインターネット・オンライン化する役割

ニアリングコストを大きく下げることに貢献している．

を果たす．本研究では「本研究で対象とするプラット

IEEE1888 通信プロトコルスタックの軽量化に挑戦した

フォームの基板上には複数のセンサやアクチュエータ

活動としては，我々の知る限り，mbed や Android 上へのが載っているため，これ自身が，それらのセンサやア

実装 [1], [25] がある．しかし，これらの研究は，我々が開クチュエータへの GW である」と考える．

発した FIAPUploadAgent（4 章参照）がベースになってストレージ（Storage）：Storage は，GW によってオンラいる．IEEE1888 プロトコル教科書 [27] に掲載されている

イン化されたデータを長期間にわたって蓄積する．こFIAPUploadAgent や FIAPDownloadAgent は，本研究でれにより，GW にデータを蓄積できなくても，昨年や開発された実装と同一のものである．本教科書は，これら一昨年のデータ（たとえば，電力消費状況）を，後かライブラリの使い方を解説するチュートリアルとしての位ら参照可能になる．

置付けとなっているのに対し，本論文は，これらのライブ

アプリケーション（APP）：APP は，その応用方法によっ

ラリ本体の設計方法，軽量化の工夫内容，評価検証を論じて様々な役割および実装形態がある．Storage から読たものとなっている．

み出してきて，画面や帳票にデータを出力する APP
もあれば，読み出したデータを加工分析処理し，その3. IEEE1888 通信プロトコル

結果を Storage に書き戻すといった APP もある．

3.1 システム・アーキテクチャ

ここで，GW，Storage，APP は，総称して IEEE1888

図 1 に，IEEE1888 のシステム・アーキテクチャを示

コンポーネントと呼ばれ，それぞれ役割は違うものの，固す．このシステムは，ゲートウェイ（GW），ストレー

有の操作インタフェースを持つわけではない．つまり，ジ（Storage），アプリケーション（APP）と分類が可能な

APP-Storage 間の通信方式と，GW-Storage 間の通信方式「IEEE1888 コンポーネント」で構成されており，これらは，後述する WRITE/FETCH/TRAP のみで構成されるの間で IEEE1888 通信プロトコルでデータ交換が行われるようにしている．たとえば，APP が Storage から値をとっ（運用構成に応じて，相互に行われる場合もあれば，一方てくるときに FETCH 手順を使うが，GW が，Storage に方向の場合もある）．IEEE1888 は，後に述べる XML メッ

保存されたアクチュエータの制御信号をとってくるときにセージを，SOAP による Remote Procedure Call（RPC）

も FETCH 手順を使う．

の一連の流れとしてやりとりする通信方式をとっている．

GW，Storage，APP は便宜上の呼び名であり，インタ

SOAP はソフトウェア・オブジェクトを XML に展開し，フェースとしてはお互いに接続可能なように規定されていインターネットを介してやりとりするための通信規格である（実際に接続可能かどうかは，実装されている内容およる．IEEE1888 では，SOAP を採用することで，Web 関連

びそれに付随する機能に依存する）．結果として，GW に技術やデータベースなどの各種情報システムとのインテグ

対しても SOAP+XML を実装することが求められる（注：レーション性を高くしている．

これは SOAP+XML 通信機能を有することを意味し，必ず

ここで，この IEEE1888 システムにおける GW，Storage，

しも SOAP サーバにならなければいけないというわけでは

APP の役割はそれぞれ次のとおりである．

ない）．逆にいえば，GW が SOAP+XML を実装すること

ゲートウェイ（GW）：GW は，センサやアクチュエータ

ができれば，これらの IEEE1888 コンポーネント（Storageのような入出力インタフェースを IEEE1888 で扱えるや APP など）に自由に接続できるようになるため，情報ようにする．統一的な通信プロトコルでセンサやアクシステムとのインテグレーション性が高まるというわけで

図 1 IEEE1888 のシステム・アーキテクチャ

Fig. 1 IEEE1888 system architecture.

c 2013 Information Processing Society of Japan


1851

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

図 2 IEEE1888 通信スタックの構造．(a) IEEE1888 は SOAP 上の通信スタックとして実装される．(b) IEEE1888 は Remote Procedure Call により TCP/IP ネットワークの向こう側にあるサーバの query または data メソッドを呼び出すことで通信を行う

Fig. 2 IEEE1888 protocol stack. (a) IEEE1888 is implemented on SOAP communication stack. (b) IEEE1888 calls query or data methods at server side over
TCP/IP network.

ある．

3.3 実装内容と相互接続に対する考え方

本研究では，GW 実装として，IEEE1888 通信のクライIEEE1888 の GW，Storage，APP は，実際の機器やソアント機能だけがあれば十分な運用場面を想定し，クライ

フトウェアを開発する段階で，WRITE，FETCH，TRAP

アント機能にフォーカスを絞ることによって，軽量なプのうち，必要な機能だけを実装すればよいことになっていロトコルスタック実装を開発するという工夫を行う（4 章る．つまり，画面や帳票に出力するだけの APP であれば，参照）．

FETCH クライアント機能だけを実装し，Storage から読
み出してくることができればよい．また，計測機能しか保3.2 通信スタックの構造有しない機器（GW）で，それが NAT 配下での利用を想定

図 2 (a) に IEEE1888 通信スタック周辺のプロトコル

したものであれば，WRITE クライアント機能だけを実装

アーキテクチャ構造を示す．IEEE1888 通信スタックは，し，Storage に対して定期的に計測データを送信することがHTTP の SOAP 上に実装され，大きく分類して，WRITE，

できればよい．一般に，IEEE1888 においては，各機器やFETCH，TRAP 通信手順が規定されている．IEEE1888

ソフトウェアには，実装機能仕様書（この機器は FETCH

通信は，図 2 (b) に示すように，RPC がベースとなっておクライアント機能を持つとか，WRITE クライアント機能

り，クライアントがサーバに実装された query メソッドやを持つなどを定義した文書）が付随し，相互接続は，同手

data メソッドを呼ぶことにより，ネットワークを越えた通順でのクライアント・サーバ間での接続性を検証すること

信（i.e.，WRITE，FETCH，TRAP の実行）が行われる．

によって行う．つまり，WRITE クライアント機能を持つ

IEEE1888 通信手順のうち，本研究で関連するのは，

GW と，WRITE サーバ機能を持つ Storage との間でデー

WRITE と FETCH である．WRITE は，ある IEEE1888

タがやりとりされれば，WRITE に関して相互接続性検証

コンポーネントが別の IEEE1888 コンポーネントにデータに成功したということができる．

を送り付ける手順（e.g.，GW がセンサデータを Storage に対して送り付ける手順）であり，サーバ側の data メソッ

3.4 通信メッセージのデータ構造

ドをクライアントが呼び出すことで実行される．FETCHIEEE1888 コンポーネント間では，SOAP+XML で要求

は，ある IEEE1888 コンポーネントが別の IEEE1888 コン

メッセージと応答メッセージがやりとりされる．SOAP 通

ポーネントからデータを読み出してくる手順（e.g.，APP

信の基礎部分を除くと，IEEE1888 のメッセージは表 1 にが Storage や GW からデータを抜き出してくる，あるいは示す 10 種類の XML 要素で構成される．これらを組み合

GW が Storage などから最新の制御コマンドを能動的に取わせて IEEE1888 メッセージは作られる．

り出してくるときに使う手順）であり，サーバ側の query

以下，本研究に関連する部分の，メッセージの内容を解説

メソッドをクライアントが複数回呼び出すことで実行されする．WRITE の要求・応答メッセージ，および FETCH のる．詳細は文献 [12], [17] を参照のこと．

要求・応答メッセージをそれぞれ図 3 と図 4 に示す．まず，全体のメッセージは，transport で始まり，その transport
は，header と body を持てるようになっている．

c 2013 Information Processing Society of Japan


1852

情報処理学会論文誌

表 1Vol.54 No.7 1849–1860 (July 2013)

IEEE1888 で定義された 10 種類の XML 要素

Table 1 IEEE1888 XML definition (10 XML elements).
XML 要素意味transport

メッセージ全体を表す

header

メッセージのヘッダ部分を定義する

OK処理に成功したことを示す

error

処理に失敗したことを示す

query

読出し処理を対象にすることを示す

key

読出し対象（範囲）を指定する

body

メッセージの内容を定義する

pointSet

ポイントセット（複数のポイントを集約する）

point

ポイントを表現する

value

値（タイムスタンプ情報を含む）

図 4 IEEE1888 の (a) FETCH 要求メッセージ，(b) FETCH 応
答メッセージの例

Fig. 4 Examples of (a) FETCH request message and (b)FETCH response message of IEEE1888.

こともある．一方，body 部には，指定したデータが格納さ
図 3

IEEE1888 の (a) WRITE 要求メッセージ，(b) WRITE 応
答メッセージの例

Fig. 3 Examples of (a) WRITE request message and (b)WRITE response message of IEEE1888.

れてくる．図 4 (b) がその例である．なお，サーバ側でリクエストの処理中にエラー（たとえば，指定したポイント

ID が存在しない）が発生した場合には，<OK/>の代わりに，<error type="POINT_NOT_FOUND">...</error>が入る．

WRITE 要求メッセージは，図 3 (a) のような構造を持ち，body 部に，複数の point を並べ，それぞれに value を付与したメッセージである．point の id により，どのセンサのデータであるかを特定することができる．

WRITE 応答メッセージは，header 部に，要求の成否

3.5 通信文のバリエーション
IEEE1888 は，HTTP と SOAP の通信ルールに従うため，TCP 上を流れるメッセージは，図 3 や図 4 とまったく同一になるとは限らない．たとえば，HTTP には，情報が格納されたメッセージである．header 部に，OK がTransfer-Encoding: chunked 方式で HTTP ボディ部を送入っていれば成功で，error が入っていれば失敗である．た信する方式がある．この場合には TCP 上のデータとし

とえば，図 3 (b) は，WRITE 要求が正しく処理されたこては，1 つの XML 文書は途中で分割された形で転送されとを意味する．

る．また，SOAP では，<point id="..." を送る場合に，

FETCH 要求メッセージは，header 部に query 内容を<ns:point id="..." のように XML 名前空間プレフィッ

記載したメッセージである．query 内容には，さらに key

クスを付与して送信される場合がある．いずれの方式もとして id が埋め込まれ，どのセンサのデータを読み出した

XML としては正しいのだが，TCP 上のデータとしては異いかを指定する．たとえば，図 4 (a) は，温度センサと電なる形のメッセージとなる．つまり，IEEE1888 の通信ス

力メータの最新値を取得するリクエストである．

タックとしては，このような違いにも対応できる必要があ

FETCH 応答メッセージは，header 部に要求の成否がる．これは概して通信相手の実装に依存してくるものであ記載され，body 部に結果が記載されたメッセージである．

り，他スタック実装との相互接続性を検証することで，こheader 部に query 部が含まれ，ここに cursor が追加される

ちら側の通信スタックをテストすることができる（5.3 節

c 2013 Information Processing Society of Japan


1853

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

参照）．

4. IEEE1888 通信スタックの軽量化
4.1 目標本研究でターゲットとするのは，AVR 社のマイクロプ

IEEE1888 通信スタックは，本来 SOAP 上に実装され，HTTP や SOAP の通信ライブラリは別途用意されるものであるが，本研究では，FIAPUploadAgent と FIAPDown-

loadAgent の中に，必要最小限の HTTP や SOAP に関する処理も一緒に実装することにする．

ロセッサ（ATmega328P）に WIZNet 社の TCP/IP コン

なお，FETCH では，指定した IEEE1888 ポイント 1 個

トローラ（W5100）を組み合わせて作られる程度の規模の最新データのみを取得するものとし，IEEE1888 で規定の通信装置（Arduino Ethernet として市場に出回っていされている cursor 機能の実装はしなくて済むようにする．

るものを想定）である．16 MHz の CPU クロックで動作

つまり，FETCH 手順は 3.2 節で複数回の query メソッド

し，プログラムメモリ領域が 32 kbyte，データメモリ領域

呼び出しであると述べたが，この条件下では 1 回の呼び出が 2 kbyte，不揮発性メモリ領域に 512 byte を利用するこしで完結する．また WRITE 手順も 1 回の呼び出しで済とができる．ここには，実際には，他のネットワーク処理

む．これにより，実装する処理量を減らすことができる．

（DHCP，DNS，NTP）に関するソフトウェア，設定用のコ
マンドラインインタフェース（CLI）に関するソフトウェ

4.3 ライブラリの API 設計

ア，不揮発性メモリ（EEPROM）の管理ソフトウェア，各

前節でフォーカスを絞った機能を実装するために必要十種 I/O 処理（アナログ計測，パルス検出，ダイナミック制

分なアプリケーション・プログラミング・インタフェース

御，PWM 制御）に関するソフトウェア，など様々なソフ（API）を次のように設計した．なお，ここで定義されてトウェアを実装しなければならない．つまり，IEEE1888

いる API は文献 [27] で紹介されているものと同一である．

通信スタックとして実装できる部分は，かなり限定されて本論文では，その API 設計について解説するとともに，エくる．

ラーの扱い方についての工夫を述べる．

そこで，本研究では，具体的には，上述のプラットフォー
ムを想定し，

4.3.1 FIAPUploadAgent
表 2 および表 3 に，FIAPUploadAgent が持つ API を( 1 ) 本研究で開発する IEEE1888 通信スタックのほかに示す（これは Arduino の環境を想定した表現方法である）．

も，実用面において，ほかに重要な機能が実装できる

IEEE1888 サーバの場所を指定して begin メソッドを呼びこと出した後，post メソッドで送りたいデータを送信する．

( 2 ) 本研究で開発する IEEE1888 通信スタックは，ほか

データは，ﬁap element 構造体の上で日時情報とともに定の IEEE1888 通信装置と問題なく相互接続通信できる

義される形式となっている．

こと

4.3.2 FIAPDownloadAgentを達成することを目標とする．

表 4 に ，FIAPDownloadAgent が 持 つ API を 示 す ．

IEEE1888 サーバの場所を指定して begin メソッドを呼4.2 実装機能の選択
本研究では，以下に述べる機能にフォーカスを絞って，び出した後，get メソッドで取得したいポイント ID と結果格納用のメモリ領域を指定する．IEEE1888 サーバに対し

IEEE1888 通信スタック軽量化の工夫を行った．

ては，指定されたポイント ID の最新データのみを返答す

要件 1：センサ計測データ（ボード上にある数個のセンサるようにリクエストを発行する．成功すると get メソッドのデータ）を，インターネット上の IEEE1888 サーバの戻り値が，FIAP DOWNLOAD OK となり，値とそのに送信可能であること

値の時刻情報を取得することができる．

要件 2：インターネット上の IEEE1888 サーバから，アクチュエータ制御に反映させるデータを取得可能である
こと

4.3.3 エラーの取扱い
FIAPUploadAgent や FIAPDownloadAgent では，TCP/
IP 通信レベルの失敗，HTTP（SOAP）通信レベルの失敗，

IEEE1888 規格の言葉でいえば，要件 1 は，WRITE ク

IEEE1888 通信レベルの失敗の違いを判断できればよいとライアント機能の実装であり，要件 2 は FETCH クライ

考え，CONNFAIL，HTTPERR，FIAPERR の 3 種類を規

アント機能の実装である．ここで，それぞれの機能は，定している．実際には，様々なエラーが考えられるが，細サーバへのデータのアップロード機能，サーバからのかいエラー内容が分かったところで，本研究でターゲット

データのダウンロード機能と考えることができることかとするコンピュータ環境では，そのエラー情報を活用する

ら，これらのソフトウェアを FIAPUploadAgent およびすべは持たないことも多いためである．このようにエラー

FIAPDownloadAgent と呼ぶことにする．なお，FIAP

粒度を粗く設定することで，TCP/IP 通信の成否，HTTP（Facility Information Access Protocol）は，IEEE1888 の通信の成否（SOAP Fault は HTTP エラー 500 として扱わ

別名で，ここではコードネームとして使用している．

れる），IEEE1888 通信の成否だけを確認すればよくなる．

c 2013 Information Processing Society of Japan


1854

Vol.54 No.7 1849–1860 (July 2013)

情報処理学会論文誌

表 2

FIAPUploadAgent（IEEE1888 WRITE クライアント機能）の API

Table 2 API for FIAPUploadAgent (IEEE1888 WRITE client stack).
メソッド

begin

引数

型

意味

server ip4

const uint8 t*

サーバの IPv4 アドレスを指定

server hostconst char*

サーバのホスト名を指定（HTTP ヘッダのserver path

const char*

Host パラメータに利用される）
IEEE1888 サービスを提供している
HTTP サーバのパス

post

server port

uint16 t

サーバの TCP ポート番号

fiap id prefix

const char*

ポイント ID の共通部分をプレフィックスとして指定

戻り値

void

N/A

v

struct fiap element*

サーバに送信するセンサデータ fiap element 構造体の配列へのポインタ

esize

uint8 tfiap element 構造体の配列の個数

戻り値

int

サーバとの通信状態を応答
成功：FIAP UPLOAD OK

TCP 接続失敗：FIAP UPLOAD CONNFAIL
HTTP エラー：FIAP UPLOAD HTTPERR
IEEE1888 エラー：FIAP UPLOAD FIAPERR
表 3 fiap element 構造体

Table 3 fiap element struct data type.
変数

型

意味

cid

const char*

ポイント ID のポストフィックス（センサごとに個別に指定される）

value

char*

このポイントに結び付けられて送信される値（文字列）へのポインタ

year

uint16 t

送信する値の時刻（年の部分）

month

uint8 t

送信する値の時刻（月の部分）1-12

day

uint8 t

送信する値の時刻（日の部分）1-31

hour

uint8 t

送信する値の時刻（時の部分）0-23

minuteuint8 t

送信する値の時刻（分の部分）0-59

seconduint8 t

送信する値の時刻（秒の部分）0-59

timezonechar*

送信する値の時刻（タイムゾーン表記）

4.4 要求メッセージ送信処理の軽量化

メッセージサイズ（Content-Length）は事前に推定する：

XML の処理において，送信操作は比較的単純で，XML

HTTP のボディ部（Content）の長さ（Content-Lengthのテンプレートを用意しておき，そこに変数となる値を埋プロパティ）を計算するときに，メッセージ全部を作め込みながら送信すればよい．ただし，送り出すメッセー

成してから計算するのではなく，送り出されるデータジ量を事前に計算して，その大きさ（バイト数）の情報を量（ﬁap element の内容）から推定するようにする．

先に送信する必要がある．以下が実装方法の原則である．

あるいは HTTP の Transfer-Encoding: chunked の方

この方法を使うと，メモリ消費量を小さく抑えることがで

式を使う．

きる．

定型文はプログラム領域から必要な分だけを SRAM 上

作業領域は小さく確保：たとえば，アプリケーション・メッ

に読み出して使う：通常の方法でプログラム内に書き込

セージを 1 度に確保するために char buf[2048]; のよまれた定型文は，起動時に SRAM 領域にコピーさうな宣言をしてはいけない（これでは 2 kbyte のメモ

れ，それらが利用される．そのため SRAM 領域を消

リ領域を消費してしまう）．確保する作業領域は char

費してしまう．これを防ぐには，定型文をプログラム

buf[50]; 程度に抑える．

領域にのみ配置しておき，必要になったときにのみ，細切れに作業する：た と え ば ，<transport xmlns=

SRAM 領域に一時的に展開させる．

"http://gutp.jp/fiap/2009/11/">を い う 1 文 を送り出すときには，まず，<transport xmlns=を送り 出 す ．そ し て ，次 に ，つ づ く メ ッ セ ー ジ と し て

4.5 応答メッセージ受信処理の軽量化
3.4 節で述べたように，応答の通信文は，通信相手となっ"http://gutp.jp/fiap/2009/11/">を送り出す．こている HTTP や SOAP スタックによって，バリエーショのように細切れに作業する．

ンがある．そこで，これらに対応する必要がある．本研究c 2013 Information Processing Society of Japan


1855

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

表 4 FIAPDownloadAgent（IEEE1888 FETCH クライアント機能）の API

Table 4 API for FIAPDownloadAgent (IEEE1888 FETCH client stack).
メソッド

begin

引数

型

意味

server ip4

const uint8 t*

サーバの IPv4 アドレスを指定

server hostconst char*

サーバのホスト名を指定（HTTP ヘッダのserver path

const char*

Host パラメータに利用される）
IEEE1888 サービスを提供している
HTTP サーバのパス

getserver port

uint16 t

戻り値

void

サーバの TCP ポート番号

N/A

pid

const uint8 t*

取得したい IEEE1888 のポイント ID

value

uint8 t*

取得した結果（文字列値）の格納場所

nint

文字列（value）の大きさ

year

int*

取得した結果の時刻（年の部分）

month

uint8 t*

取得した結果の時刻（月の部分）

day

uint8 t*

取得した結果の時刻（日の部分）

hour

uint8 t*

取得した結果の時刻（時の部分）

minuteuint8 t*

取得した結果の時刻（分の部分）

seconduint8 t*

取得した結果の時刻（秒の部分）

timezone

uint8 t*

取得した結果の時刻（タイムゾーンの部分）

n tz

int

文字列（timezone）の大きさ

戻り値

int

サーバとの通信状態を応答
成功：FIAP DOWNLOAD OK

TCP 接続失敗：FIAP DOWNLOAD CONNFAIL
HTTP エラー：FIAP DOWNLOAD HTTPERR
IEEE1888 エラー：FIAP DOWNLOAD FIAPERR

では，まず，HTTP の Transfer-Encoding: chunk 方式に関5.1 フットプリント絶対量

しては，XML 要素名の途中で HTTP ボディ部が分割され

FIAPUploadAgent と FIAPDownloadAgent のフットプ

ることはないという想定で実装している．また，<の後，6リントを次のように検証した．まず，プログラム領域に文字目以内で:が出現したときには，その後を XML 要素名関しては，通信スタックのソースコードに対し，実装にとして採用するように，処理している（これにより，XML相当する部分をコメントアウトする場合と，コメントア

名前空間のプレフィックスがある場合とない場合とに耐えウトしない場合とで，ビルド後のプログラム量の大きさ

られる）．また，FIAPDownloadAgent の場合，リクエストの差分をとった．なお，この際，TCP 通信スタックに相時のクエリの内容から，value タグは 1 つだけしかないは当する部分は，その差分の中には入っていない（つまり，ずなので，出現した value タグがあれば，それが求める結TCP 通信を実装するプログラム領域は FIAPUploadAgent

果だと判断するようにしている．

や FIAPDownloadAgent のフットプリントに含まれないよ

構文解析においては，<で開始されたときに，その後ろがうに計算している）．次に，スタック領域，スタティック

value または error であるかを，まず判断する．それ以外の領域に関しては，通信スタックを実際に稼働させながら，

場合は読み飛ばす．error であれば，結果を FIAPERR とデータメモリ（SRAM: static random access memory）領して採用する．value であれば，value タグの内部を細かく域を適所でダンプすることで，分析評価した．その結果は構文解析する．このようにして受信処理の軽量化を行う．

次のとおりである．

5. 実装と評価
本研究で開発した IEEE1888 通信スタック軽量版（FI-• FIAPUploadAgent のフットプリントは，プログラム
領域が 1,820 バイト，スタティック領域が 35 バイト，
スタック領域が 109 バイトであった．

APUploadAgent および FIAPDownloadAgent）に対して，• FIAPDownloadAgent のフットプリントは，プログラ

フットプリントの絶対量，他機能とのフットプリントの比ム領域が 3,306 バイト，スタティック領域が 166 バイ

較，対向となる様々な通信スタックとの相互接続性を評価・

ト，スタック領域が 310 バイトであった．

検証した．なお，本研究では，フットプリントのことを，実際には，この通信スタック部分だけでは動作できない

プログラムメモリ領域やデータメモリ領域の占有量のこと

ため，TCP 通信スタックや Ethernet など（DHCP 機能やを指すものとする．

DNS 機能を含む）のスタックも併用することになる（次節c 2013 Information Processing Society of Japan


1856

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)参照）．

置の IP ネットワーク設定，通信先サーバの URL 設

参考までに，ARM9 CPU 向けの Linux で動く，IEEE1888

定，IEEE1888 ポイント ID 設定，データ取得頻度設の GW ソフトウェアおよび APP ソフトウェア（文献 [27]定，警報レベル設定，警報ガード時間設定ができる．

の参照コードとして提供されているサンプルを ARM9 向

実装しているソフトウェア機能は，Ethernet，DNS，

けにビルドしたもの）は，それぞれ，60,275 バイトおよび

FIAPDownloadAgent（IEEE1888 の FETCH クライ

59,268 バイトのプログラム領域を必要とする．

アント），CLI のコマンドライン処理，EEPROM 管理，I/O 処理機能などである．なお，ライブラリ群は，5.2 他機能のフットプリントとの比較

Arduino-0022 のものを用いている．

次に，FIAPUploadAgent と FIAPDownloadAgent を，

図 5 にそれぞれのソフトウェアが消費するプログラム領

それぞれ，IEEE1888 学習キットとピークカットヘルパー

域の大きさを図示する．この検証は，それぞれの機能を無（下記）に実装した．学習キットはセンサのみを搭載する

効にした場合に，その前後でプログラムメモリ消費量がど

機器（GW）なので FIAPUploadAgent（WRITE クライアの程度変動するかを調べることで行った．

ント機能）のみを実装し，ピークカットヘルパーはアク

FIAPUploadAgent および FIAPDownloadAgent のプロ

チュエータのみを搭載する機器（GW）なので FIAPDown-

グラムメモリ量が 5.1 節の結果と比べると多いように見え

loadAgent（FETCH クライアント機能）のみを実装する

るが，これは，5.1 節の結果では TCP 通信スタック量が含（これらのライブラリをセンサ計測やアクチュエータ制御

まれていなかったのに対し，ここでは TCP 通信スタックにどのように利用しているかは後述する）．この環境下で，部分を含んでいるためである．

それぞれの装置における通信スタックのフットプリント

この図から分かるように，FIAPUploadAgent や FIAP-（ここではプログラムメモリ領域に限定する）が，他のソ

DownloadAgent のフットプリントが，他のソフトウェアとフトウェア機能のフットプリントと比較して，どの程度相比較して突出して大きいわけではない．つまり，十分に軽対差があるかを調査した．これらの装置（下記）は，2012

量化されており，メモリ消費量に関して，他のソフトウェ

年 10 月現在，本研究で開発された FIAPUploadAgent とアライブラリと同等のメモリ消費感覚で利用可能なことを

FIAPDownloadAgent が実装され，製品として発売されて裏付けている．

いる [10]．

IEEE1888 学習キット：この装置は，アナログ入力の温5.3 相互接続性の評価

度・照度センサ，デジタル入力（スイッチ）の状態をイ

本研究で開発した通信スタックの機能をテストするた

ンターネット上にある IEEE1888 サーバに 1 分に 1 回

めに，各種 IEEE1888 通信スタック実装との相互接続性の頻度でタイムスタンプ情報とともに送信する．ユー

テストを実施した．この相互接続テストには，2012 年 3

ザは，パソコンを USB でシリアル接続すると，コマン

月および 10 月に東大グリーン ICT プロジェクト [23] がドライン方式（CLI: Command Line Interface）によ主催した IEEE1888 相互接続試験などを活用させていたり，インタラクティブに，この装置の IP ネットワーク

だいた．相互接続試験には，WRITE サーバに関しては，

設定，通信先サーバ（URL）設定，IEEE1888 ポイン

Java+Axis2，.NET Framework(C#)，C 言語で組まれた機器

ト ID 設定，NTP タイムサーバ設定ができる．実装しやソフトと，FETCH サーバに関しては，Java+Axis2，.NETているソフトウェア機能は，Ethernet，DHCP，DNS，

Framework(C#)，PHP5，Ruby(+SOAP4R)，C 言語で組ま

NTP クライアント，FIAPUploadAgent（IEEE1888

れた機器やソフトが持ち込まれた．3.3 節の説明のとおり，の WRITE クライアント），CLI のコマンドライン処

FIAPUploadAgent（WRITE クライアント機能実装）は，

理，時刻管理，EEPROM 管理，I/O 処理機能などでWRITE サーバとの接続性を検証し，FIAPDownloadAgent

ある．なお，ライブラリ群は，Arduino-1.0 のものを

（FETCH クライアント機能実装）は，FETCH サーバとの用いている．

接続性を検証した．

ピークカットヘルパー：この装置は，4 桁の 7 セグメント• FIAPUploadAgent のテストは，上述の各 WRITE サー

LED（LED 表示板）と圧電ブザーを有し，ネットワー

バに対してセンサデータを送信することで行った．結クから IEEE1888 で取得してきた数値を，LED 表示

果としては，すべてのサーバとの接続テストに成功で板に表示するとともに，その値があらかじめ設定してあった．つまり，これらのサーバにデータを送信できおいた警報レベルを超えれば，その警報レベルに応ることを確認し，例外処理ケースでは，例外を検出でじた警報音を発生させる．ここで 7 セグメント LED

きることも確認した．

はタイマが発生させるイベントを使いダイナミック• FIAPDownloadAgent のテストは，上述の各 FETCH

点灯表示する．ユーザは，パソコンを USB でシリアサーバに対してセンサデータを送信することで行っ

ル接続することで，コマンドラインにより，この装た．結果としては，すべてのサーバとの接続テストに

c 2013 Information Processing Society of Japan


1857

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

図 5

IEEE1888 通信スタック（FIAPUploadAgent および FIAPDownloadAgent）が占めるプログラム領域の割合．他のソフトウェア機能と比較して突出して大きいことがない
ことが読み取れる．棒グラフ横の数値は各ソフトウェア機能のフットプリントの大きさ（バイト数）を表している

Fig. 5 Footprint of IEEE1888 communication stack (FIAPUploadAgent and FIAPDownloadAgent). Compared to other software functions, the stack is not remarkably large. The number along the graph shows the footprint (byte) of eachsoftware function.

成功であった．つまり，これらのサーバから値を取得的な方式や，UDP/IP 方式を用いることも 1 つの方向性とできることを確認し，例外処理ケースでは，例外を検しては考えられる．しかし，IEEE1888 がそのような方式

出できることも確認した．

を採用していない理由の 1 つとして，JSON では，相互接ここで，Java+Axis2 の実装は，応答時に，HTTP は

続性やマルチベンダ性の観点で扱いにくいというものがあTransfer Encoding: chunked モードで応答されていた．まる．簡易的な情報提供には優れた方式であるのだが，メッ

た，PHP5 サーバは，応答時に XML 名前空間を XML 要

セージにオブジェクトのスキーマ情報が載らず，名前空間

素にプレフィックスとして挿入した XML メッセージを返による各種管理もできないため，上記のような問題が発生答するが，そのような状況下でもこれを正しく読み飛ばしする．UDP の上にバイナリメッセージを載せる方式は，設て，狙いどおりに値をとれることを確認している．

計次第で，さらにコンパクトにできると思われるが，開発

6. 考察

効率の問題や，実展開されるネットワークでの問題（Webの一種として扱われないためファイヤウォールが通らない

今回の実験では，メモリ使用量の検証をメインに行い環境が多い）がある．そこで IEEE1888 では SOAP/XMLCPU 負荷の検証は行っていないが，それは次の理由によ方式を基調としており，これによって開発効率，展開効率，

る．XML 処理では，汎用の XML ライブラリなどを使う

相互接続性，マルチベンダ性を手に入れたというわけで場合には，CPU 負荷などを気にしなければならないケー

ある．SOAP/XML の場合，当然，軽量化に向かないのでスがあるが，本研究で実装した方式では，定型文をプログはないか，という意見も多いと思われるが，今回の研究に

ラムメモリ内に保存しておき，それを細切れにコピーしてよって，今回のプラットフォーム（32 kByte プログラムメ

送信するものであるため，汎用の XML ライブラリと比べ

モリ空間，2 kByte の SRAM 空間）で IEEE1888 機器の実て CPU 負荷に関して明らかに軽量である．また，構文解現が可能であることが実証されたわけである．これは，こ析においても，特定の文字列を意識して抽出する文字列処れまでの常識的感覚を見直すきっかけを与えてくれる，と理であるため，解析処理はほぼ O(m)（m は解析する XML

考える．

の文字列長）の計算量で達成できる．XML 文字列長はたかだか 1 kByte 程度であり，実際に動かした結果，無視できるほど短時間で処理できていたので，今回のようなケースでは問題にはならないと考えられる．
軽量化という観点では，メッセージ交換に REST/JSON

c 2013 Information Processing Society of Japan

7. まとめ
我々は，近年，インターネットを介したセンサデータ交換に使われつつある HTTP/XML ベースの通信として，

IEEE1888 を取り上げ，この通信プロトコルを，OS がほ

1858

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

とんど存在しないような組込みコンピュータ（具体的には，Arduino）に実装する手法を研究した．センサデー
タを送信するために IEEE1888 の WRITE クライアント

[16]
[17]

を，FIAPUploadAgent として実装し，アクチュエータ
制御信号を受信するために IEEE1888 の FETCH クライ
アントを FIAPDownloadAgent として実装した．HTTP
や SOAP に関する処理に対応させ，Java+Axis2，.NET

Framework(C#)，PHP5，Ruby(+SOAP4R)，C 言語で実装

[18]
[19]
[20]

された IEEE1888 サーバと，本研究で開発した IEEE1888
通信スタックが通信できることを確認した．本研究で開発した，FIAPUploadAgent は 1,820 バイトのプログラム領
域，35 バイトのスタティック領域，109 バイトのスタック
領域を消費し，FIAPDownloadAgent は，3,306 バイトのプログラム領域，166 バイトのスタティック領域，310 バ
イトのスタック領域を消費する．この大きさは，他の機能実装と比較して突出して大きいことはなく，十分に小型化されているといえる．
参考文献
[1]
[2]
[3]
[4]

[5]

[6]
[7]

[8]

[9]
[10]
[11]

[12]
[13]
[14]
[15]

IEEE1888(FIAP) を mbed で使う，入手先
http://mbed.org/users/yueee yt/notebook/ﬁap/.
Arduino, available from http://www.arduino.cc/.
Armadillo, available fromhttp://www.atmark-techno.com/.
Atzori, L., Iera, A. and Morabito, G.: The Internet ofThings: A survey, Computer Networks, Vol.54, No.15,
pp.2787–2805 (online) (2010), available fromhttp://linkinghub.elsevier.com/retrieve/pii/
S1389128610001568.
BACnet – A data communication protocol for building automation and control networks, available fromhttp://www.bacnet.org/.
Brown, R.: Impact of Smart Grid on distribution systemdesign, IEEE PES (2008).
Castellani, A., Bui, N., Casari, P., Rossi, M., Shelby, Z.
and Zorzi, M.: Architecture and protocols for the Internet of Things: A case study, IEEE PerCom (2010).
Doi, Y., Sato, Y., Ishiyama, M., Ohba, Y. and Teramoto,K.: XML-Less EXI with Code Generation for Integrationof Embedded Devices in Web Based Systems, 3rd International Workshop on the Internet of Things (2012).
Dunkels, A.: Full TCP/IP for 8-Bit Architectures, ACM
MobiSys, pp.85–98 (2003).
IEEE1888 学習キット，ピークカットヘルパー，入手先
http://www.futaba-kikaku.jp/.
Guinard, D., Trifa, V., Pham, T. and Liechti, O.: Towards physical mashups in the Web of Things, IEEE
INSS (2010).
IEEE1888-2011: Standard for Ubiquitous Green Community Control Network (2011).
i.Lon Smart Server, available fromhttp://www.echelon.co.jp/products/ilon/.
LonMark International, available fromhttp://www.lonmark.org/.
Niyato, D., Xiao, L. and Wang, P.: Machine-to-Machine
Communication for Home Energy Management System
in Smart Grid, IEEE Communication Magazine, Vol.49,
No.4, pp.53–59 (2011).

c 2013 Information Processing Society of Japan


[21]
[22]
[23]
[24]
[25]
[26]

[27]

Open Building Information Exchange, available fromhttp://www.obix.org/.
Ochiai, H., Ishiyama, M., Momose, T., Fujiwara,N., Ito, K., Inagaki, H., Nakagawa, A. and Esaki,
H.: FIAP: Facility Information Access Protocol for
Data-Centric Building Automation Systems, IEEE
INFOCOM M2MCN Workshop (2011).
SOAP version 1.2, W3C Recommendation 2007.
W5100 Datasheet, available fromhttp://www.wiznet.co.kr/.
Wilde, E.: Putting Things to REST, Technical Report
2007-015, UC Berkeley (2007).
Z-wave appliance, available fromhttp://www.z-wavealliance.org/.
ZigBee, available from http://www.zigbee.org/.
江崎 浩，落合秀也：東大グリーン ICT プロジェクト，電子情報通信学会論文誌，Vol.J94-B, pp.1225–1231 (2011).
落合正弘：PICNIC の製作，トランジスタ技術，Vol.38,
No.1, pp.249–261 (2001).
大川善邦：mbed+Android データ通信プログラミング，
工学社 (2012).
落合秀也，江崎 浩：グリーン・ビルディングと設備情報アクセスプロトコル：その設計と標準化，通信ソサイ
エティマガジン，Vol.18, pp.119–126 (2011).
落合秀也：スマートグリッド対応 IEEE1888 プロトコル
教科書，インプレスジャパン (2012).

落合 秀也 （正会員）
昭和 58 年生．平成 18 年東京大学工学部電子情報工学科卒業．平成 20 年同大学大学院情報理工学系研究科修士課
程修了．平成 23 年同大学院同研究科
博士課程修了．同年同大学大規模集積
システム設計教育研究センター助教，
現在に至る．博士（情報理工学）（平成 23 年 3 月，東京大学）．設備ネットワーク，広域センサネットワーク，遅延耐性ネットワーク研究のほか，IEEE1888 および ASHRAE
での設備ネットワーク標準化活動に従事．

井上 博之 （正会員）
昭和 62 年大阪大学工学部電子工学科卒業．平成 2 年同大学大学院修士課
程修了．同年住友電気工業株式会社入社．平成 12 年奈良先端科学技術大学
院大学博士後期課程修了．平成 12 年
株式会社インターネット総合研究所入社．平成 19 年広島市立大学大学院情報科学研究科講師，現在，同准教授．インターネットアーキテクチャ，コンテンツ配信に関する研究に従事．電子情報通信学会，IEEE 各
会員．

1859

情報処理学会論文誌

Vol.54 No.7 1849–1860 (July 2013)

寺西 裕一 （正会員）
平成 5 年大阪大学基礎工学部情報工学科卒業．平成 7 年同大学大学院基礎工学研究科博士前期課程修了．同年日
本電信電話株式会社入社．平成 17 年
大阪大学サイバーメディアセンター講師，平成 19 年同大学大学院情報科学研究科准教授，平成 20 年より情報通信研究機構専攻研究員，招へい専門員を兼任，平成 23 年より情報通信研究機構
研究マネージャおよび大阪大学サイバーメディアセンター
招へい准教授，現在に至る．博士（工学）（平成 16 年 3 月，大阪大学）
．マルチメディア情報システム，ユビキタスサー
ビス，センサーネットワーク，オーバレイネットワーク等の研究開発に従事．本会論文賞を受賞．IEEE 会員．

江崎 浩
昭和 38 年生．昭和 62 年九州大学大学
院工学系研究科電子工学専攻修士課程修了．同年（株）東芝入社．平成 2 年
米国ニュージャージ州ベルコア社．平成 6 年コロンビア大学客員研究員．平成 10 年東京大学大型計算機センター
助教授．平成 13 年同大学大学院情報理工学系研究科助教
授．平成 17 年同大学院同研究科教授，現在に至る．工学博士（東京大学）．MPLS-JAPAN 代表，IPv6 普及・高度化推進協議会専務理事，WIDE プロジェクト代表，JPNIC
副理事長，ISOC 理事．

c 2013 Information Processing Society of Japan

1860