FIT2016( 第 15 回情報科学技術フォーラム ) C-035 ユーザ ドリブン アーキテクチャ デバイス (UdAD) の検討 Consideration on User-driven Architecture for Devices (UdAD) 大橋正 Tadashi Ohashi 1.

Transcription

1 C-035 ユーザ ドリブン アーキテクチャ デバイス (UdAD) の検討 Consideration on User-driven Architecture for Devices (UdAD) 大橋正 Tadashi Ohashi 1. まえがき 今日の電子機器 ( デバイス ) は仕様が最大機能 ( オーバ スペック ) になっており, ユーザが時として不要な機能又は操作の場合にも, 購入したデバイスに合わす, デバイス オリエンテッド システムに陥りやすい. この結果, 使用しない機能に伴う操作性の複雑さ, 回路や部品のために消費電力の浪費や販売価格の高騰化の一理を招く傾向にあると考える. 本来であれば最大機能をデバイスが持ち合わせていたとしても, ユーザが必要な時に必要な機能に限定するユーザ ドリブン デバイスはユーザが欲する機能を満たし, 且つエネルギーの保全及び自然エネルギーの持続可能なIoTシステムを実現する上で重要である. 以上の問題を解決するアーキテクチャを具備したユーザ駆動システム ( 仮称 : User Driven Architecture for Devices: UdAD ユーダッド ) を提唱する [1] [2]. 上記問題の解決策として, ユーザの欲する機能を実現する部品情報及びオブジェクトをクラウドから LOD (Linked Open Data) [3] により集め, クラウド上でシステム ゼネレーションを行う為に所与のデバイスのシステム構成をクラウドで収集し, 所与のデバイスのハードウェア動作条件を満足するコンパティビィティを論理推論又は機械学習により満足させるハードウェア (H) 及びソフトウェア (S) 構成情報を形成し, デバイスのシステム機能強化やシステム機能弱化をデバイスへ自動的に反映ならしめる手段を講ずる. この手段は強化操作 (Strong Operation) または弱化操作 (Weak Operation) のアーキテクチャを形成するものであり, デバイス側にはシステム構成の柔軟性に富む FPGA(Field Programmable Gate Allay) [4] を実装し, プロダクツの実行形式オブジェクトをクラウドからダウンロード可能なIoTへのユーザ ドリブン システム方式 (UdAD) の研究を報告する. 2. 現状の課題とその解決 今日に出現してきたスマートデバイスは ICT の中枢を担っており今までの利用環境が固定から携帯へと変遷してきた. これに伴い運用形態が利用場所に制約されることなく, ユーザの利き腕となり, ユーザの思いを実現するユーザドリブンのデバイスとしての地位を確立してきた. 特にオープンソースの OS の出現はこの確立を築き上げる一因ともなった. 一方ユーザ ドリブン システムはサステナビリテを実現するシステムともいえる. ここでサステナブルシステムに論点を向ける. 今日では自然エネルギーの保全を意図したシステム設計, 即ちデバイスの電源の省電力化が中心となっているが, その本質を堅持しながらサステ アイリクト (ilict) ナビリテは広範にわたる. 更に加えてデバイスの品質維持, セキュリティの維持, 更にはユーザが購入デバイスを長期にわたって使用したいという意欲を醸し出し, デバイスを新規に買い変えることなく維持して使っていこうという視点もサステナビリテと考える. 2.1 現状の課題現状の課題のメインテーマはサステナビリテの達成がユーザドリブンの在り方に繋がると考える. 所与の購入デバイスのハードウェア及びソフトウェアの機能の版数を上位に挙げることが機能強化即ち Strong Operation とし, 下位に下げることを機能弱化即ち Weak Operation として捉える. 以上の機能を具備したデバイス ドリブンのサステナビリテ設計を阻害する課題を下記に列挙する. (1) ハードウェア製品及びソフトウェア製品の設計 製造 検査の多様化. (2) ハードウェア及びソフトウェア設計の上述した広範囲な意味を包含したサステナビリテの視点に立った設計思想の欠如. 2.2 課題解決デバイスに実装されるハードウェア プロダクト及びソフトウェアプロダクトを上記 2.1 の各項目に合わせて課題解決のシナリオを以下に記述する. (1) 設計 製造 検査の多様化. デバイスの設計 製造等のプロセスが国内外の多種多様な個人若しくはメーカ等により行われており, すでに一箇所で行うことはできない. 従いソースコード又はオブジェクトをクラウドでビックデータとして維持管理させる. 各々の構成要素は RDF(Resource Description Framework) [5] 又は OWL(Ontology Web Language) [6] でハードウェア部品及びソフトウェア部品の構成メタ情報 (CMD: Compositional Meta Data) として表現し, 構成メタ情報にプロダクトの機能版数ソース及びオブジェクトの格納場所及び動作条件を具備させる. 更にデバイスの構成要素は上記の構成メタ情報の塊を構成群データ (CGD :Compositional Group Data) とする. (2) サステナビリテの設計思想の導入 Strong 及び Weak 操作の導入することで問題解決を図 る. 双方の機能はハードウェア動作の確証, 論理的推論又は機械学習によりコンパティビリティ検証を行い動作の保証を確立する. 3. 提唱するアーキテクチャ以下に提唱するアーキテクチャの処理概要をクラウド ( ウェブ ) 側とデバイス側に大別して述べる. 図 1 のシステム全体構成図に於いて,UdAD/Cn システム ( ユーザ ドリブン システムのクラウド側システムとして定義 ) はデバイスの開発元若しくは販売元が管理者となり多種多様のデバイスのハードウェア及びソフトウェア 313

2 構成情報 (CMD,CGD) をメーカ側が RDF/OWL 変換サイト等を利用して準備を行う. 更に各メーカとは別に登録された構成情報をスマッシュさせたりする管理者を置く. クラウドにはビッグデータ (Big Data) として以上の H/S 構成情報とオブジェクトデータがクラウド空間に格納されている. UdAD/Cn にはこのハードウェア及びソフトウェア部品を自エンドポイント サーバのみならず他のエンドポイント サーバを検索するために SPARQL(SPARQL Protocol and RDF Query Language) [7] [8] 検索エンジンが具備されており必要に応じて LOD API(Application Program Interface) を介して実行される. 図 1 システム全体構成図 一方所与のデバイス購入者がユーザとなり, ユーザの欲望, 若しくは利便性あるいは省電力化等の為にユーザが醸し出すサステナビリテを満たすユーザ ドリブンなシステムの強化 (Strong) 操作若しくは弱化 (Weak) 操作指示をデバイスからクラウドに発する. 3.1 クラウド側のアーキテクチャ図 1 のシステム構成図で示された個々のエンドポイント サーバ UdAD/Cn は以下の図 2 で拡大表示する. RDF/OWL ストアは多種多様のメーカ又は個人の設計者が管理するハードウェア及びソフトウェアプロダクトに関する構成メタ情報 CMD とその集合である構成群 CGD で構築される. 複数の UdAD/Cn 間で階層構造を形成し所与のハードウェア又はソフトウェアのプロダクトの各メーカによる開発関係を示している. 以下の図 2 に於いてはクラウド上にメーカ A,B,C 社の各々の設計者が所与のハードウェア部品又はソフトウェア部品がクラウド上で構成されていることを例示している. 各部品は 6 つの構成メタデータ CMD で一つの構成群データ CGD を構成している. 図 3 UdAD/Cn アーキテクチャ 更に加えてオブジェクトデータもメーカ及び個人の設計者が構築して当該データストアーに登録される. これとは別に所与のデバイスの構成情報は UdAD/Dm( ユーザ ドリブン システムのデバイス側システムとして定義 ) 構成データベースに格納され再構成後に必要なオブジェクトデータの格納場所が紐付されて再構成データベースに格納される. その再構成を行うエンジンが CMD/CGD 再構築エンジンである. 再構築の確証は同条件ハードウェア確証エンジンと論理推論エンジンと機械学習で行われる. (1) クラウド ( ウェブ ) 側 :UdAD/Cn (UdAD on Cloud) 1 ユーザの要望する構成情報の生成を行い, 現状のデバイスのハードウェア (H) 及びソフトウェア (S) の構成情報 ( メタ情報 ) を RDF または OWL で表現する. 2 各々の要素間を LOD(Linked Open Data) で結合させる. 当該 LOD はクラウド上でビッグデータとして集合させられる. 図 2 各メーカによるプロダクト開発関連図 例えばハードウェアの任意の部品に着目すると,FPGA の上位階層はプリント板であり下位構成であれば FPGA に実装されるゲート情報である. 次に図 3 において 図 4 プロダクト構成例 上記図 4 では所与のデバイス Dm のハードウェア及びソフトウェアの構成例を示している. 左側のツリーはハードウェア構成群データであり右側にはソフトウェア構成 314

3 群データを示している. 構成情報を Strong 操作若しくは Weak 操作は先ずハードウェア構成に変更があるかを判断し, 若し変更がある場合 FPGA のデータ代替で吸収できないかを判断する. 代替が不可能であった場合は Strong 操作若しくは Weak 操作は中断する. 3 Strong や Weak 動作の為の上位または下位機能の検索は下記図 5 で例示したように SPARQL を駆動して実施する. 図 5 SPARQL シンタックス例 上記の図 5 では機能版数の Strong を検索する場合の SPARQL シンタックスの一例を示している. 当該クゥエリでは udad の独自の Strong を定義したサーバを定義し, 所与のプロダクト productnv が対象ハードウェア部品若しくはハードウェア部品名 N と機能版数 V を設定している. 検索の結果は所与の部品の上位機能版数 produccgd の先頭場所を獲得することを示している.Weak 操作の場合も同様である. 4 構成情報にはハードウェア (H) 及びソフトウェア (S) の名称, 版数を具備し更には動作条件も包摂している. 5 動作条件には所与の H/S プロダクトが動作する H/S 環境条件を基にハードウェア確証エンジンが動作可能を保証している. 例えば動作するための OS の名称, 版数並びにはハードディスク等の空き容量などの構成情報を持つ. 図 6 Strong( 上位 ),Weak( 下位 ) 検索 6 ハードウェアに変更が生じた場合では,FPGA 上のソフトウェアで代替できるか否かを判断する. もし代替できない場合は希望とする Strong 若しくは Weak を実現不可なので実現不可メッセージを出して終了する. 7 動作条件は論理和, 積等の一般的な論理式で表現できる.Strong 操作や Weak 操作が動作できるか否かはこの論理式が真か偽かで推論できる. 8 論理的に動作条件が真か偽かを判定できない場合は機械学習によって動作可か否かを判定することができる. 9 所与の H/S プロダクトの Strong または Weak するための版数を芋ずる式に手繰り寄せ構成情報を再構築する機能を具備する. 10 再構築できた構成表により必要なオブジェクトの格納場所を SPARQL にて見つけだすことができる. 11 以上によりデバイスの格納するコンフィグレーションをデバイスのメモリ空間としてクラウド上に展開する. 12 このタオブジェクトを所与のデバイスの格納領域へそのままダウンロードする. 図 7 でハッチしたアプリケーションの例は後述で触れる Chrome [9] である. 以上の処理を図 6 の流れ図において例示する. 図 7 デバイス書込みデータ 3.2 デバイス側のアーキテクチャ図 8 で例示する様にデバイス側は大きく分けて以下の 2 分野でアーキテクチャを構成する [1] [2]. (1)sWAP (swap control engine) 常電のコントロール エンジンであり以下の eace のハードウェア若しくはソフトウェアプロダクトをスワップさせるコントロール エンジンである. (2)eACE ( embedded Architecture Control Engine) 実運用のコントロール エンジンである. 現状のハードウェア並びにソフトウェアの一部分または全部を上位機能に強化したり弱化させたりする. この入れ替え制御は eace の電源を落とした状態で上記の swap が行う.sWAP が行われた後は eace が復電をして通常運用に入る.eACE を構成する電子部品は汎用性を持たせるために FPGA [10] を用いる. 当該 FPGA ではソフトウェアにより従来のハードウェア部品を置きかることができる.CPU や ARM 更に記憶素子例えば DDRn [11] などが今後益々 FPGA 内のソフトウェアで実現できると期待されている. (3) sebridge( swap and eace ) ブリッジ swap が中心となり実運用コントロール エンジンの入れ替えを行うための swap と eace 間の橋渡しを行う機能を具備している. 315

4 4. 動作解説 今まではクラウド側を主体に論述したが, 以降はユーザ ドリブン システムという主題の元でデバイス側から論述を展開する. 図 8 デバイス ブロック ダイヤグラム (4) 組込み ICE(IN Circuit Emulator) 従来は外付けであった ICE は swap と eace の双方に実装されている. いずれもデバッグの際に威力を発揮する. (5) ストレージコンポーネント UdAD/Cn からダウンロードされたオブジェクトは udad/cn から毎回ダウンロードを不要とさせるために当該ストレージコンポーネントに保管しておく. 以下に図 9 のハードウェアに実装するソフトウェアプロダクトの概要図を上記の図 8 に対比して述べる.sWAP に実装されるサステナブ オペレーティングシステム sos を基として, 各種ライブラリー, アプリケーションフレームワーク, サステナブルアプリケーションが実装される. 図 9 デバイス ソフトウェア ダイヤグラム UdAD/Dm と UdAD/Cn は通常 swap API を介してデータの授受を行う. 所与のデバイス内のテーブルやデータ類及び現デバイスのソフトウェアプロダクトは sdbc API を介して授受される. 図 10 UdAD ユースケース図 以下に図 10 に示したユースケース図を基に動作のシナリオを述べる. 4.1 デバイス側の動作解説 (1) デバイス側のユーザは, サステナブルシステムの実現を目指して, 現デバイスはハードウェア及びソフトウェア構成情報を RDF 又は OWL を変換サイトで生成する. ユーザは当該デバイスの入手時点からシステムの変更をしていないのであれば Default として RDF/OWL を具備している. ( 2 ) swap はユーザからの対象となるプロダクトの Strong 操作若しくは Weak 操作の要望を上位系の UdAD/Cn へ要望する. (3) UdAD/Cn はこの要望を受理すると UdAD/Dm へ現状のデバイスの構成情報 (RDF/OWL) を要求し, この情報を獲得する. (4) UdAD/Cn は Strong 及び Weak の機能を実現できることを判断すると, その処理可能通知を UdAD/Dm へ伝達する. もし不可能であると判断すると, その不可能通知を UdAD/Dm へ発信して一連の処理を中断して終了する. (5) UdAD/Dm は処理可能通知を受理すると, 現状のデータ類及びテーブル類及び現在のデバイス内のすべてのソフトウェアプロダクトを UdAD/Cn へ格納する. (6) UdAD/Dm の swap は新規の構成情報とデバイスへ書き込むオブジェクト データを受理して esbridge を介して eace へ書き込む. (7) 上記 (5) で退避させた現状のデータ類及びテーブル類を swap が eace へ復元させる. (8) swap は電源を全て切断し, 電源投入後に再起動させる. 4.2 クラウド側の動作解説 (1)UdAD/Cn はデバイスからの Strong 操作又は Weak 操作要求を受け付けるとデバイスへ現状のハードウェア (H) 316

5 及びソフトウェア (S) の全ての構成情報を RDF や OWL 形式で要求する. (2) デバイスの H/S 構成情報を入手すると対象となるプロダクトに対する Strong 操作又は Weak 操作による要望の構成情報を再構築する. (3)SPARQL のシンタックスに対象となるプロダクトの上位または下位の機能を持ったプロダクトの構成情報のメタ情報を検索する. 図 6 参照. (4) 上位または下位のプロダクトを検索すると, プロダクトの動作条件のコンパティビリティを確認する. もし確認結果が真であれば Strong 又は Weak 操作を継続する. (5) もしコンパティビリティが偽であれば Strong 又は Weak 操作を中断する. (6) 動作条件のコンパティビリティはハードウェアの動作保証や論理的判断より優先して確証を得る. もし確証が得られない場合は機械学習により判別を行う. (7) 動作条件にはハードウェアの環境条件も入る. 例えばワークエリアが 5MB とするとこれが満足できるかを現在のハードウェア構成情報から確認しもし不足していれば FPGA のストレージ容量を拡大し, 併せてオブジェクトを展開する際のメモリーマップを変更する. 又新たなハードウェアの追加が余儀なくされた場合は FPGA のファームで代替させるように構成情報を変更し併せて FPGA の拡大ストレージを実現するソフトウェアをソフトウェア構成情報に追加する. (8) 機械学習による判別では所与のプロダクトの機能に対する Strong 機能及び Weak 機能の判断を図 11 の如く FFNN(Feed Forward Neural Network) [12] 等を用いて行えると考える. 図 11 機械学習の適用例 図 11 の機械学習適用例では構成メタデータ CMD 内の動作条件若しくはコメント欄を設けて動作条件をテキスト形式で記述させることで機械学習が可能であると考える. 機械学習の対象となる入力はプロダクトの動作条件であり RDF で記述されたコメント行に記載されたテキストデータが使用される. 将来的にはソースコードのテキスト文をそのまま解読して動作条件を生成することもできると考えている. (8)UdAD/Cn はハードウェアに於ける動作の確証や論理的コンパティビリティ若しくは機械学習でコンパティビリティを得ると新たに構築された構成情報により各々の メタ情報として示しているオブジェクトの保管場所からオブジェクトコードを LOD によりすべて収集する. (9) 収集されたオブシェクトはデバイスの格納空間に配列される. この配列はデバイスのストレージ格納空間情報としてデバイスへダウンロードされる. 以上の流れ図をシーケンス図として図 12 に示す. 図 12 UdAD/Dm-UdAD/Cn シーケンス図 上図の図 12 では左側がデバイス側の UdAD/Dm を示し, 右側はクラウド側の UdAD/Cn を示している. ユーザはユーザ インターフェースの LCD(Liquid Chrystal Display) を介して Strong 又は Weak を指示する. この要求は swap のコントロール エンジンに受け付けられる. その要求はクラウド側の UdAD/Cn へ通知される.UdAD/Cn のエンドポイント サーバはデバイスに対して現在のデバイスのハードウェア構成情報やソウトウェア構成表を要求する. この要求は swap のコントロール エンジンに受け付けとられ現デバイスの H/S 構成情報をエンドポイント サーバ UdAD/Cn に転送する.UdAD/Cn ではユーザの Strong 操作若しくは Weak 操作の要求に応じて図 5 に定義した SPARQL クエリーで Strong 検索又は Weak 検索を行う. その結果, 構成群データ CGD の先頭場所を獲得することができる. 現デバイスの構成情報 (CMD/CGD) を基底として上位及び下位プロダクトを得ることができる. 一通り新構成が得られた時点で, コンパティビリティによる確証結果から必要により, 既存 CGD を削除若しくは追加が行われ新構成のチューニングが繰り返し行われる. チューニングはハードウェアの動作確証, 論理的動作確証及び機械学習によるコンパティビリティのすべてが真で終われば, 所与のデバイスへ新構成情報を swap へダウンロードさせる. 次に全てのオブジェクトを CMD の格納場所により入手操作が実行される. デバイスに新オブジェクトをダウンロードするに先立って, 現デバイスの実行エンジンの eace にある現テーブル, データ類及びソフトウェアを swap が吸い上げ UdAD/Cn の退避用データベースへ格納させる. 以上の準備を終えると, 新構成情報や新オブジェクト, 退避していたテーブル及びデータ類を swap 経由で eace のストレージへ格納される. 以上のスワップが 317

6 完了すると eace の再起動が行われて新システムが稼働する. 5. 適用事例 Android 用 Chrome を例に挙げて図 13 に適用事例として述べる. 最新機能版数は Chrome 42 である. この前機能版数は Chrome 41 であり更に遡ると Chrome 40 である. ここで現デバイスの実装は Chrome 41 とする. この上位系 Strong 操作は Chrome 42 下位系 Weak 操作は Chrome 40 となる. Chrome 42 の動作条件はホームページに以下の通り記述されている [13]. Android スマートフォンまたはタブレットの場合 Chrome for Android は Android 4.1 (Jelly Bean) 以上を搭載図 9 適用事例したスマートフォンやタブレットで使用できる.Android 4.0(Ice ここで現デバイスのソフトウェア Cream Sandwich) をご利用の場合 (OS) の版数は構成情報,Chrome バーによればジョン 42 Android5.0:LollyPOP 以下が動作するが, [10] 更新は行われないであったとするとユー. ザが 1. Play Chrome41 ストアでの Strong Chrome を希望したとすると for Android のページにアクセ Chrome42 の動作条件を満たすのでスする. UdAD(W) に於ける動作条件の論理的コンパティビリティが真となることが分かる. ハード 2. [ インストール ] をタップする. ウェアの動作条件では現在の Android5. 0 配下で Chrome41 3. [ 同意してダウンロードが動作しているハードウェア環境であればその ] をタップする. まま継続できるので論理的コンパティビリティが真とな 4. ブラウジングを始めるには ホームまたは [ すべてのアるプリ. 因みに ] ページに移動して Android5.0 のChrome UdAD(D) アイコンをタップのハードウェア動作 [12] 条件する. は図 7 図 13 アプリケーションの動作条件の一例 ここで現デバイスのソフトウェア (OS) の版数は構成情報によれば Android 5.0:LollyPOP [14] であるとしユーザが Chrome 41 の Strong を希望したとすると Chrome42 の動作条件を満たすので UdAD/Cn に於ける動作条件の論理的コンパティビリティが真となることが分かる. ハードウェアの動作条件では現在の Android 5.0 配下で Chrome41 が動作しているハードウェア環境であればそのまま継続できるので論理的コンパティビリティが真となる. 因みに Android 5.0 の UdAD/Dm のハードウェア動作条件 [15] は図 14 に一例として挙げられているが Chrome に関しての要件は無い. 最少メモリとストレージ Android テレビデバイス用として 5GB のアプリケーションプライベート容量が必要 図 14 Android 5.0 パーフォマンス コンデションの抜粋 6. まとめ (1) 本論文の提唱する UdAD アーキテクチャがハードウェアのソフトウェア代替やオペレーティング システム, ファームウェア, エミュレータ並びにアプリケーションの強化機能 (Strong) 若しくは弱化機能 (Weak) により, ユーザの利便性向上, 自然エネルギーの保全や持続可能なサステイナブルな社会システムとしての IoT の実現に有効であると考える. (2) クラウドでのコンパティビリティの処理にハードウェア動作確証, 動作条件論理推論と動作条件判定機械学習の適用が可能である. (3)seBridge がユーザ ドリブン アーキテクチャを基いとにしたデバイス内の eace と swap 間のデータ共有及びファームウェア等のソフトウェアの入替手段となる. (4)CMD や CGD は RDF 及び OWL で表現されるが SHIM [16] とのコンパティビリティの整合も必要であると考える. (5) 従来からの既存システムと当該提唱する UdAD システムをデバイス側とクラウド側の両面から総合的に考慮してシステム導入によるコスト パーフォマンスを俎上に載せて議論する余地がある. 参考文献 [1] 大橋正 :User-Driven Android Device(UdAD: ユーダッド ) の検討. ABC (Android Bazaar and Conference) 2016 Spring, Mar12, [2] Tadashi Ohashi Perspectives for Architecture of Sustainable Control Engine The 78 th National Convention of IPSJ. Mar [3]Tom Heath and Christian Bizer Linked Data- Evolving the Web into a Global Data Space Morgan & Claypool Publishers, [4]Editted by Peter Athanas, Dionisions Pnevmatikatos Embedded Systems Design with FPGAs Springer, 2012 [5]RDF [6]OWL [7]Bob DuCharme learning SPARQL 2 nd Edition published by O Reilly. [8]SPARQL Query Language for RDF [9]CHROME, com/chrome/answer/95346?hl=ja [10]Xilinx Inc. Virtex-5 FPGA User Guide, ides/ug190.pdf [11] DDR4 SDRAM [12]David E. Rumelhert Parallel et al. Distributed Processing: Vol.1 pp [13]What are the minimum hardware specifications for Android com/questions/34958/what-are-the-minimum-hardwarespecifications-for-android [14]Android 5.0: LollyPOP [15]Android 5.0 Compatibility Definition jp/?gfe_rd=cr&ei=emcdv9aaaex98wep4znocg&gws_rd=ssl# q=android5.0+compatibility+definition [16]SOFTWARE-HARDWARE INTERFACE FOR MULTI-MANY-CORE (SHIM) org/workgroup/shim.php 以上 318