Fog に基づく IoT アプリケーションのためのコンテキスト指向アーキテクチャの設計
M2015SE003 川畑 賢史
指導教員：野呂 昌滿

1

はじめに

近年，ICT の発展に伴い，組込み機器をネットワークに接続し，相互通信を行なう Internet of Things(以下，IoT)[3] が普及してきた．この組込みシステムは移動体として実現され，サービスを連携させることで機能を実現する．クラウド [7] 上のサービスと連携することによる実時間性能の低下の問題を解決するためにフォグ [2] が提案されている．様々なサービスと連携することでアプリケーションドメインは拡大し，高機能化してきている．複数の非機能特性を考慮しながら実行時に変化するサービスや移動体に応じた振舞いを実現するには動的再構成の方法を考えることが重要である．Truong らは，クラウド上
図 1 IoT の参照アーキテクチャのサービスに応じたフォグの構成を動的に変更するアーキテクチャ[4] を提案している．
1. Data Center, Cloud Layer
移動体，フォグ，クラウドは相互に影響を受けて再構データセンタが置かれ，このサーバ上にサービスを成されると我々は考える．この場合，Truong らの提案す配置する．
るアーキテクチャは移動体に関する視点が欠落している．
2. Core Network Layer
移動体にとって重視する非機能特性に応じてフォグの構IP ネットワークなど，複数のサブネットワーク間で成の変更が必要となる．実行時にアクセス可能なフォグデータを送信，交換する．
やクラウド上のサービスは変化するので，移動体は非機3. Multi Service Edge Layer
能特性を考慮しながら，状況に応じたサービスを１つ選組込みシステムやセンサなどをコアネットワークに択する必要がある．
アクセス可能とするために，この層に配置されるゲー本研究では，移動体として実現される組込みソフトウェ
トウェイによってコアネットワークとの橋渡しを行
アおよびフォグを動的に再構成するアーキテクチャを提なう．フォグはこの層に対応する．
案する．非機能要求を充足した IoT アプリケーションの開発支援を実現する．
4. Embedded Systems and Sensors Layer
移動体およびフォグの動的再構成に関する問題として組込みシステム，センサ，アクチュエータなどのデバアーキテクチャを設計する．動的再構成に関する要求をイスが存在する．これらは，一般にコアネットワー整理し，アーキテクチャの設計指針を定義する．移動体おクにアクセスする機能を持たない．
よびフォグをコンテキスト指向設計し，コンテキスト間の2.1.2 フォグ協調によってそれぞれの再構成を可能とする．Clements
フォグとはクラウドより，地理的に分散し，デバイス・らが定義するアーキテクチャスタイル [5] を参考にアーキテクチャを設計する．考察では，動的再構成に関する要 ユーザの近距離に配置することで，情報の提供にかかる求に対するアーキテクチャの妥当性と Truong らの提案 遅延を短くすることを目的としている．類似の概念としするアーキテクチャとの比較によるアーキテクチャの新 てエッジがある．クラウドに対して，IoT を制御する上での遅延などの問題を解決するためにクラウドを補完す規性および利点を確認する．
る概念である．フォグ/エッジはクラウドにとってかわる2 背景技術と関連研究ものではなく，フォグとクラウドを連携することで新たなサービスを提供することを目的としている．
2.1 背景技術

2.1.1

IoT

IoT とは，センサやアクチュエータ等の組込みデバイスをネットワークに接続し，相互通信を行なう仕組みや概念のことである．IoT を用いることで，必要な情報をリアルタイムで取得することが可能となる．ユビキタス計算やパーベイシブ計算と同じ概念である．IoT の参照
アーキテクチャ[2] は次の４層からなる (図 1)．

2.2
2.2.1

関連研究
移動体に関する研究

欧州電気通信標準化機構により，モバイルエッジコン
ピューティング (以下，MEC) の標準化が進められている [1]．[1] では，MEC の参照アーキテクチャとフレームワークが提案されている．図 2 は，MEC の参照アーキテ• コンテキスト間の協調によってそれぞれを再構成
構成要素間の関係の変化に動的に対応する動的な再構成を実現する要素を独立して定義し，非機能要求を考慮して様々な配置で実現可能とする．

3.2

提案するアーキテクチャの概略

IoT アーキテクチャに基づき，移動体，フォグ，クラウドの 3 つを構成要素とした．図 3 は，本研究で提案するアーキテクチャの概略である．
移動体とフォグのコンテキストをベースコンテキストとし，ベースコンテキストを変更させる要因となるメタコンテキストを定義した．メタコンテキストを定義した
図 2 MEC の参照アーキテクチャ
ことにより，メタコンテキストに応じたベースコンテキストの変更が可能になる．メタコンテキストを持つ構成クチャである．MEC の参照アーキテクチャはシステムレ 要素として Coordinator を定義した．Coordinator を Fog
ベルとホストレベルの２つの層で表現される．このアー および移動体と独立して定義することにより，変更に対キテクチャに基づき実現することにより，モバイルエッ する柔軟性を確保する．以下に，各構成要素のコンテキスジホストの構成を動的に変更することが可能となり，実 トとその振舞いを記述する．移動体のコンテキストはア時間性能が向上する．
クセス可能なフォグの集合である．移動体は非機能特性を充足するために，アクセス可能な Fog の中から適切な2.2.2 自己適応システムに関する研究対象を選択する．フォグのコンテキストはアクセス可能環境の変化に応じて，ソフトウェアの構成や振る舞い なクラウド上のサービスの集合である．フォグは非機能を変更することができる自己適応システムの研究が行な 特性を充足するために，アクセス可能なサービスの中かわれている [6]．ここでは，動的再構成の実現方法として， ら適切な対象を選択する．メタコンテキストは移動体の動的織込みスタイルと C2 スタイルの２つのアーキテク 集合とクラウド上のサービスおよびフォグの集合である．
チャスタイルを提案している．織込みスタイルは，メタ 2.2.1 は MEC における要求を満たすために，MEC の構オブジェクトプロトコルを用いてコンポーネントの振舞 造を整理したものである．2.2.1 の MEC の参照アーキテいを動的に変更するスタイルである．C2 スタイルは，動 クチャと比較して，本研究ではコンテキスト間の協調に的コンポーネントの組み替え用アスペクト間記述である より，フォグだけでなく移動体の再構成も可能となる．
C2 コネクタを用いて，動的再構成を実現するスタイルである．
織込みスタイルによる再構成は，系統的な対処が可能となるが，仕組みが大掛かりになる．他方，C2 スタイルによる再構成は，仕組みは簡単であるが局所的な対処となってしまう．アプリケーションによってどちらのスタイルを適用するかを考えるべきであることを示唆している．

3アーキテクチャの設計

図 3 本研究で提案するアーキテクチャの概略
本研究では，移動体およびフォグの動的再構成に関する問題としてアーキテクチャを設計する．アーキテクチャ設計に向けて，動的再構成に関する要求を整理し，この要求 3.3 Module Viewに基づきアーキテクチャの設計指針を定義する．V&B で定
図 4 は本研究で提案するアーキテクチャを Module View
義されている Module View，Component and Connector に基づき記述したものである．アスペクト指向技術を導View，Allocation View の 3 つの標準的な視点からアー 入し，横断的関心事をアスペクトとして分離することでキテクチャを記述する．Module View を用いて静的観 関心事毎に独立してモジュールを定義した．アスペクト点から構造を整理する．Component and Connector(以 間記述 (IAD) は，アスペクトとアスペクトの合成関係を下，C&C) View を用いて動的観点から構造を整理する． 記述したものである．
Allocation View は物理的観点から構造を整理する．
Aspect Style を用いることにより，アスペクトを記述した．Oreizy ら [6] は，動的なコンポーネントの結合方法と3.1 要求とアーキテクチャ設計指針
して C2 スタイルと織込みスタイルを述べている．C2 ス
非機能要求として実時間性能および信頼性の向上を目 タイルおよび織込みスタイルは，非同期通信とコンポー指し，設計指針を定義する．定義した非機能要求に基づ ネントの変更に対する柔軟性を確保している．本研究でき設計指針は次のように定義した．
は，非同期通信と変更に対する柔軟性を確保するために• 移動体とフォグをコンテキスト指向設計
Configuration Concern と Communication Concern を横• Shared Data Style• SOA Style• Publish Subscribe Style

図 4 Module View に基づき記述したアーキテクチャ
断的関心事として特定する．我々は横断的関心事として次の 4 つの関心事を特定し，それぞれアスペクトとして分離した．表 1 は，横断的関心事とアスペクトの関係を表で
表 1 横断的関心事とアスペクトの関係
横断的関心事アスペクト
Configuration Concern
Configuration Aspect
SOA Concern
SOA Aspect
Context Concern
Context Aspect
Communication Concern Asynchronous Aspect

移動体，Fog，Cloud Service は Coordinator に対して稼働状態や位置情報を送信する．Coordinator の持つメタコ
ンテキストは移動体，Fog，Cloud Service の共有データと定義できるので，Coordinator と移動体，Fog，Cloud
Service に Shared Data Style を適用する．Fog およびCloud の Service は実行環境が異なる場合でも相互作用を可能とすることを目的としている．Fog および Cloud のService，Registry，Service Bus は SOA Style を適用す
る．Coordinator から移動体および Fog にコンテキスト変更のメッセージを非同期に送る．Coordinator と移動体，Fog，Cloud Service に Publsih-Subscribe Style を適用す
る．移動体は Service Bus を介して Service を利用するか，Coordinator に位置情報を送信する．Fog は Service Bus
を介して Service を利用するか，Coordinator に稼働状態を送信する，Coordinator は Service Bus を介して移動体と Service Bus を再構成させる．

3.5

Allocation View

Service の配置および Coordinator の配置にはいくつかのパターンが存在し，それぞれのパターンについて説明する．
表したものである．Configuration Concern を Configura図 6 は本研究で提案するアーキテクチャを Allocation
tion Aspect として抽出．SOA Concern を SOA Aspect
View に基づき記述したものである．Service は，アプリとして抽出．Context Concern を Context Aspect としてケーションによってはクラウドとフォグに配置されるこ抽出．Communication Concern を Asynchronous Aspectとが考えられる．クラウド上の Service は Data Center 層として抽出．図 4 の黄線のモジュールは Configuration Asに，フォグおよび隣接するフォグ上のサービスは Multipect，青線のモジュールは SOA Aspect，赤線のモジュー
Service Edge 層に記述した．Coordinator は，アプリケー
ルは Context Aspect，緑線のモジュールは Asynchronous
ションによってはクラウド，フォグ，移動体に配置し，分Aspect を表す．
散・連携することが考えられる．Coordinator の配置は７3.4 C&C View
通り存在する．図 6 では，Data Center 層，Multi Service
Edge層，Embedded Systems and Sensors 層それぞれに
C&C View には，Module View で記述したアスペクトを織り込んだ実行時のコンポーネントの関係を記述する． 記述した．
図 5 は本研究で提案するアーキテクチャを C&C View に基づき記述したものである．

図 6 Allocation View に基づき記述したアーキテクチャ
図 5 C&C View に基づき記述したアーキテクチャ

C&C View に定義されている次の 3 つのスタイルを適用して記述し，実行時のコンポーネントの振舞いに対する役割について説明する．

4

考察

本章では，提案したアーキテクチャの有用性と，関連研究と比較し本研究で提案するアーキテクチャの新規性および利点を考察する．

時間性能の低下の要因となる．本研究で提案するアーキ
提案するアーキテクチャに基づかずに安直に実現した テクチャは，移動体とフォグの動的な再構成を実現する．
Coordinator により移動体とフォグのコンテキストを変場合，次の問題があると考えた．
化させ再構成を行なう．移動体の再構成が必要な場合に• コンテキストの協調に関する視点の欠落は，移動体はフォグを経由した再構成情報の取得を必要• 非機能要求を充足したアプリケーションの実現が困難 としないことから，FSDN VANET と比較して，実時間移動体に対して，実行時に変化するフォグおよびクラ 性能が良いと考えられる．
ウド上のサービスに応じた処理を定義しなければならな
実時間性能の向上が求められる場合，クラウド上に SDN
い．フォグに対して，クラウド上のサービスおよび移動 を配置することを前提としていることから，困難である．
体の状況を考慮した処理を定義しなければならない．コ 本研究で提案するアーキテクチャは，移動体とフォグのンテキストの協調に関する視点が欠落していることから， 再構成を実現する Coordinator を独立して定義している．
これを実現した場合，移動体とフォグに対して協調に関 前節で説明したとおり，非機能要求に応じて Coordinatorする記述が散在することとなる．の配置を柔軟に決定することが可能となっている．
移動体およびフォグについて，アクセス可能なサービスを定期的に検索する必要がある．この定期的な検索は 5 おわりにアプリケーションの実時間性能の低下の要因となる．定
本研究は，非機能要求を充足した IoT アプリケーショ期的な検索の間隔を長くした場合，タイミングによって ンの開発を目的とし，コンテキストに応じて Fog およびは移動体とフォグとクラウドの実行時の変化に対応でき 組込みソフトウェアを動的に再構成するアーキテクチャ
ず，非機能要求を充足した最適なアクセス対象の選択を を提案した．結果として，提案するアーキテクチャに基実現することが困難となる．
づいて実現することで，コンテキスト間の協調によって提案するアーキテクチャは，構成要素間の関係の変化 移動体と Fog を再構成することが可能となった．に動的に対応可能とし，それぞれの構成要素を独立して定義している．安直に実現した場合と比較して，提案す 参考文献るアーキテクチャに基づいて実現することにより，実時[1] European Telecommunications Standards Insti間性能および信頼性の向上すると考えた．
tute, “Mobile Edge Computing (MEC); Framework
提案するアーキテクチャは，メタコンテキストを持つ
and Reference Architecture,Technical Report,Coordinator によるベースコンテキストの協調を実現し2016.ている．コンテキストの協調により，動的な構成要素間[2] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli,の関係の変更を実現することで，非機能特性を考慮した“Fog Computing and Its Role in the Internet of
最適なアクセス対象の選択を可能としている．また，移Things Characterization of Fog Computing,” in the
動体とフォグはそれぞれ独立して定義され，協調に関す
first edition of the MCC workshop on Mobile cloud
る記述は Coordinator としてモジュール化している．
computing, pp. 13-15, 2012.
非機能特性を考慮して柔軟に Coordinator の配置を決定[3] K. Ashton, “That ’Internet of Things’ Thing,”
することが可能である．Coordinator の配置のパターンは，RFID Journal, 2009.
前章の図 6 に示した．例えば，実時間性能を重視する場合[4] N. B. Truong, G. M. Lee, Y. G. Doudane, “Softには，より移動体の近くに Coordinator を配置すること
ware Defined Networking-based Vehicular Adhocが考えられる．信頼性を重視する場合には，Coordinator
Network with Fog Computing,” Integrated Networkを分散配置することが考えられる．
Management, pp. 11-15, 2015.
4.2 車車間アドホックネットワークに関する研究との[5] P. Clements, F. Bachmann, L. Bass, D. Garkan,
比較
J. Ivers, R. Little, R. Nord, and J.Staﬀord, DocuTruong らによって提案されている FSDN VANET[4] とmenting Soft-ware Architectures Views and Beyond
本研究で提案したアーキテクチャの比較を行ない，本研
Second Edition, Addison Wesley, 2010.
究の新規性および利点を考察する．FSDN VANET は車[6] P. Oreizy, M. M. Gorlick, R. N. Taylor, D. Heim車間アドホックネットワークのための実時間性能とモビ
bigner, G. Johnson, N. Medvidovic, A. Quilici, D.
リティを考慮したアーキテクチャである．
S. Rosenblum, A. L. Wolf, “An Architecture-BasedFSDN VANET は，実行時に変化するクラウド上のサー
Approach to Self-Adaptive Software,” IEEE Intelビスに応じて，フォグの構成を動的に変更する．この構
ligent Systems, vol. 14, pp. 54-62, 1999.
成の変更は，クラウド上に配置された SDN Controller に[7] P. Mell, T. Grance, “The NIST definition of cloud
よって実現される．実行時に変化するフォグとクラウド
computing,” Technical Report, 2011
上のサービスに応じて移動体を再構成すべき場合がある．
この場合，FSDN VANET は移動体に関する視点が欠落している．移動体の再構成を実現するためには，移動体はフォグを経由して再構成情報を取得する必要があり，実4.1

提案したアーキテクチャの有用性の考察