Recently, IoT technologies have been progressed, and many devices are connected to networks. Previously, IoT services were developed by vertical integration style. But now Open IoT concept has attracted attentions which achieves various IoT services by integrating horizontal separated devices and services. For Open IoT era, we have proposed the Tacit Computing technology to discover the devices with necessary data for users on demand and use them dynamically. Although Tacit Computing can discover and use the device based on the situation, a study of coordination logic description is insufficient when multiple devices are coordinated. In this paper, we study coordination logic description and execution to coordinate multiple devices dynamically. We compare methods with ideas to convert abstract description to specific interface access means at execution time, study merits and demerits and propose an appropriate method.
💡 Deep Analysis
📄 Full Content
動的なデバイス連携サービスの連携ロジック記述と実行の検討
A study of coordination logic description and execution for dynamic device coordination services
山登庸次1
Yoji Yamato
干川尚人1
Naoto Hoshikawa
野口博史1
Hirofumi Noguchi
出水達也1
Tatsuya Demizu
片岡操1
Misao Kataoka
日本電信電話株式会社 NTT ネットワークサービスシステム研究所1
NTT Network Service Systems Laboratories, NTT Corporation
1
はじめに
近年IoT 技術[1]-[11] やクラウド技術[12]-[33] が進展
し,数多くのデバイスがネットワークに接続され活用で
きるようになっている.多彩なIoT サービスをコスト低
く開発,運用するためには,デバイスとサービスを分離
し,水平分離的にデバイスとサービスを相互に利用可能
にすること(オープンIoT の考え)が必要となる.
私達は,オープンIoT に向けて,サービスからデバイス
を自由に利用するための仕組みとして,Tacit Computing
(TC)技術を提案している[34].Tacit Computing は,
ユーザが必要なデータを持つデバイスをオンデマンドに
発見し,利用する技術である.しかし,複数のデバイス
を動的に連携する際にその連携ロジックについては十分
検討されていない.そこで,本稿では,動的なデバイス
連携の連携ロジック記述と実行について提案する.
2
サービス例と課題
サービス例として,駅での外国人観光客グループへの
ナビを考える.連携するデバイスは,駅のカメラ,ディ
スプレイ,放送スピーカである.観光客が行先をスマホ
やタッチパネルで指定すると,駅のディスプレイに乗換
先が表示され,駅のスピーカーで案内が流れる.更に,
駅のカメラで観光客グループをモニタして,もし誤った
方向に向かった場合に,スピーカーでアラートをする.
ここで,各駅で設置されている,ディスプレイ,カメ
ラ,スピーカーは,機種や機器インタフェース(IF)が異
なるため,鉄道会社毎に連携するプログラムを書く必要
があるのが現状である.そのため,動的なデバイス連携
では,連携ロジックは,個々のデバイスに依存せず記述
できることが必要である.しかし,連携ロジックの記述
と実行について,デファクト標準な方法は無く,課題と
なっている.なお,デバイス側は,自身が持つ機能と位
置,アクセス手段等のメタデータを公開しているとする.
3
連携ロジック記述と実行の3 方式案
案1:標準インタフェースを使い連携ロジックを記述
UPnP デバイス等,デバイスが持つサービスのアクショ
ン(機能)が標準化されているデバイスがある.そのた
め,UPnP アクション等,標準IF を使って連携ロジック
を記述することで,実行時は連携ロジックをTC サーバ
等が解釈し,TC サーバより標準化された手法(SOAP
等)を用いて,デバイスを連携する.
メリット:標準IF を使うため具体的デバイスに依存
せず記述できる.デメリット:標準化されたデバイスし
か連携できない.
案2:連携ロジックは抽象的に記述し,実行時はTC
サーバより具体的IF で連携
デバイスは多種多様であり標準化されていない物も多
い.そこで,連携ロジックは,デバイスの具体的IF に依
存しない抽象的な指示として記述する.ユーザからリク
エストあった際に,TC サーバは,連携ロジックを取得
するとともに,デバイスのメタデータやその時点のデー
タを元に利用するデバイス群を選択する.選択したデバ
イス群を連携するサービス実行の際に,抽象的指示と,
デバイスメタデータの具体的IF 間のマッピングを取り,
TC サーバより具体的IF に基づいてデバイスを連携利用
する.メタデータ及び抽象的記述として,Semantic Web
Services 技術等が候補としてある.
メリット:具体的デバイスに依存しない抽象的記述で
連携ロジックを記述できる,TC サーバでサービス実行
が完結する.デメリット:メタデータや抽象的記述の標
準化や普及が必要(Semantic Web Services 等[35]-[72])
である,TC サーバでデバイスへの多彩なアクセス手段
を準備する必要がある.
案3:連携ロジックは抽象的に記述し,実行時はTC
サーバよりの抽象的指示をGW にて具体的IF に変換
案2 同様,連携ロジックは,デバイスの具体的IF に
依存しない抽象的な指示として記述.ユーザからリクエ
ストあった際に,TC サーバは,連携ロジックを取得す
るとともに,デバイスのメタデータやその時点のデータ
を元に利用するデバイス群を選択する.選択したデバイ
ス群を連携するサービス実行の際に,TC サーバは抽象
的指示をデバイスを収容するGW に標準的手段(REST
等)で送信し,GW で個々のデバイスに依存した具体的
IF に基づいてデバイスを利用する.
メリット:具体的デバイスに依存しない抽象的記述で
連携ロジックを記述できる,TC サーバはGW に抽象的
指示を標準的手段で送ればよい.デメリット:メタデー
タや抽象的記述の標準化や普及が必要である,GW 側で
抽象的指示からデバイスの具体的IF アクセスへの変換
手段を持つ必要がある.
4
提案
案1 は多様性がない.案2,3 は一長一短のため,折
衷案として,SOAP, REST 等のメジャーな手段で制御
できるデバイスは,案2 のTC サーバより直接連携し,
デバイスの制御がマイナーな手段や無線等の場合は,案
3 のTC サーバからはSOAP,REST 等で抽象的指示を
送り,GW で変換して連携する形を提案する.
参考文献
[1]
Y. Yamato, et al., ”Predictive Maintenance Platform with Sound
Stream
Analysis
in
Edges,”
Journal
of
Information
Processing,
Vol.25, pp.317-320, Apr. 2017.
[2]
Y. Yamato, ”Study of Vital Data Analysis Platform Using Wearable
Sensor,” IEICE Technical Report, SC2016-34, Mar. 2017.
[3]
Y. Yamato, et al., ”A Study of Optimizing Heterogeneous Resources
for Open IoT,” IEICE Technical Report, SC2017-26, Nov. 2017.
[4]
Y. Yamato, et al., ”Analyzing machine noise for real time mainte-
nance,” ICGIP 2016, Oct. 2016.
[5]
Y. Yamato, ”Proposal of Vital Data Analysis Platform using Wear-
able Sensor,” ICIAE2017, pp.138-143, Mar. 2017.
[6]
山登庸次,他,”エッジ画像分析及びERP を用いた万引防止サービスの検討,” 電子
情報通信学会技術報告, Vol.116, No.201, pp.19-22, Aug. 2016.
[7]
Y. Yamato, et al., ”Proposal of Lambda Architecture Adoption for
Real Time Predictive Maintenance,” IEEE CANDAR 2016, 2016.
[8]
Y. Yamato, ”Proposal of Real Time Predictive Maintenance Platform
with 3D Printer for Business Vehicles,” 5th International Conference
on Software and Information Engineering (ICSIE 2016), 2016
[9]
Y. Yamato, et al.,”Security Camera Movie and ERP Data Matching
System to Prevent Theft,” IEEE CCNC 2017, pp.1021-1022, 2017.
[10]
Y. Yamato, ”Experiments of posture estimation on vehicles using
wearable acceleration sensors,” IEEE BigDataSecurity 2017, 2017.
[11]
Y. Yamato, et al., ”Proposal of Shoplifting Prevention Service Using
Image Analysis and ERP Check,” IEEJ Transactions on Electrical
and Electronic Engineering, Vol.12, pp.141-145, June 2017.
[12]
Y. Yamato, et al., ”Fast and Reliable Restoration Method of Virtual
Resources on OpenStack,” IEEE Trans. Cloud Computing, 2015
[13]
Y. Yamato, ”Server Structure Proposal and Automatic Verification
Technology on IaaS Cloud of Plural Type Servers,” NETs2015, 2015.
[14]
Y. Yamato, ”Proposal of Optimum Application Deployment Technol-
ogy for Heterogeneous IaaS Cloud,” WCSE 2016, pp.34-37, 2016.
[15]
Y. Yamato, ”Use case study of HDD-SSD hybrid storage, distributed
storage and HDD storage on OpenStack,” IDEAS’15, 2015.
[16]
Y. Yamato, et al.,”Fast Restoration Method of Virtual Resources on
OpenStack,” IEEE CCNC 2015, pp.607-608, 2015.
[17]
Y. Yamato, et al., ”Survey of Public IaaS Cloud Computing API,”
IEEJ Transactions on Electronics, Information and Systems, Vol.132,
pp.173-180, 2012.
[18]
Y. Yamato, ”Implementation Evaluation of Amazon SQS Compati-
ble Functions,” IEEJ Transactions on Electronics, Information and
Systems, Vol.135, pp.561-562, 2015.
[