More Related Content More from harmonylab (20) 2. 背景
組み込みシステムの多様化
単体としての組み込みデバイス 携帯電話，オーディオプレイヤー
ネットワーク構造の一部を担う組み込みデバイス 自動車，ＦＡ
傾向
“部品”としての組み込みデバイス Device As A Service(DAAS)
被管理 センサ
組み込み デバイス アクチュエータ
ネットワークに接続された組み込みデバイスを
デバイス
別のプロセッシングユニットから使用する考え方
プロセッシングユニット
センサ アクチュエータ 利点
・ロードバランス，ロバスト
・デバイス利用の多様化
ネットワーク
プロセッシング
課題
ユニット
・構成変更に伴う管理
・デバイスの操作方法統一
分散ネットワーク型での例
3. Autonomic Computing Architecture
分散ネットワークシステムの自己管理を目指す
アーキテクチャ Analyze Planning
-MAPEループによって構成される知識ベース
の管理システム
knowledge
-Knowledge内の動作policyの変更による
Monitor policy Execution
動作変更の柔軟性
エンタプライズ系のシステムを対象 MAPEループ
先行研究
組み込みデバイスのためのオートノミック・コンピューティング・アーキテクチャ
[IBM,秋山一人,2007]
-Javaや非リポジトリベースのアーキテクチャの提案と，複合機によるプロトタイプの実装
-更にエンタプライズ系のシステムのAMとの連携が可能なことを示した．
（情報の保持方式と通信の仕様について）
ACアーキテクチャの柔軟性を，組み込みデバイスで扱うためには，
組み込みデバイス固有の仕様差を吸収するアーキテクチャの拡張が望まれる．
4. 目的
分散ネットワーク型組み込みシステムでの自己管理機能の実現
1.プロセッシングユニットの取り外し ２．ネットワークインタフェースの切り替え
①監視によって通信の不通を認識 ①インタフェース変更の認識
②情報の共有と分析によって取り外しと認識 ②情報の共有
③被管理デバイスの操作継承 ③代替通信手段の確立
③操作継承
①認識
①認識 P P
P P ③通信確立
②共有 ネットワーク
①認識
①認識 ②共有
P P ③通信確立
5. 目的
分散ネットワーク型組み込みシステムでの自己管理機能の実現
デバイス操作 AC Architecture
方法の仕様差 の枠組みで対応
1.プロセッシングユニットの取り外し ２．ネットワークインタフェースの切り替え
①監視によって通信の不通を認識 ①インタフェース変更の認識
②情報の共有と分析によって取り外しと認識 ②情報の共有
③被管理デバイスの操作継承 ③代替通信手段の確立
③操作継承
①認識
インターフェース
①認識 P P 間の差異
P P ③通信確立
②共有 ネットワーク
①認識
①認識 ②共有
P P ③通信確立
6. デバイスの仕様差を吸収する技術
secure SQL parser
被管理デバイス#1 被管理デバイス#2 デバイスのアクセス方式の多様性を
吸収することを目的としたミドルウェア
[TripodWorks社]
DLL #1 DLL #2
③内部変数の変更に応じた操作
SQLクエリによってデバイスの操作
SQLparserメインプログラム 柔軟なデバイス操作を可能に
②内部変数の変更
インタフェース DLLファイルにデバイスの操作記述
ソケット通信 Select
Update 操作可能なデバイスの
descript 拡張を容易にできる．
SQL parser
SQLクエリ
7. 通信インタフェースのプロトコル差
を吸収するアーキテクチャ
Dispatcher
Dispatcher
通信インタフェースへの通信要求
Application/ を中継する
MAPE knowledge 振り分け
Knowledgeの変更で動的に
利用インタフェースを切り替えられる
通信依頼 受信 インタフェース
イベント を判断
通信依頼
通信 通信
デーモン#2 デーモン#2
8. アーキテクチャの提案
アーキテクチャの全体像
MAPEループによる デバイス操作の
操作の自律化 プロセッシングユニット 差異を吸収
Application DLL
#1
secure Device
A P SQL #2
#1
parser #3
M knowledge E Device
#2
Dispatcher Device
#3
Daemon#1 Daemon#2
Interface#1 Interface#2 インタフェース間の
差異を吸収
他プロセッシングユニット
実環境で利用する際に環境からの影響や，複数の協調を実現した場合の
振る舞いは予測が困難であるため，検証が必要であるといえる．
10. プロトタイピング全体図
プロトタイピングの構成と機材についての説明
プロセッシング
ユニット
P P
T提案 Ethernet connection ネット ネットワーク
アーキテクチャ ワーク P 被管理デバイス
TriBOARD
TriBOARD（マイコン）
ネット
―Arm9(400MHz)
ワーク
―Memory 128Mbyte
Bluetooth connection ―外付けbluetoothドングル(planex)
一定距離を保ち NXT ―Ethernetポート
ライントレース
MindStrom NXT
―前方の距離を測ることができる
（超音波センサーを使用）
―地面の色の判別ができる
（光センサーを使用）
―BluetoothによるTriBOARDとの
通信が可能
11. プロトタイピング全体図
プロトタイピングの構成と機材についての説明
プロセッシング
ユニット
・他のTriBOARDからの疎通監視 P P
T提案 ・取得した情報（疎通，距離）をTriBOARDへ送信
ネット ネットワーク
Ethernet connection
・管理するNXTの出力量制御を行う
アーキテクチャ ワーク P 被管理デバイス
TriBOARD
TriBOARD（マイコン）
・前方との測距情報を取得 ―Arm9(400MHz)
・管理するTriBOARDに送る
―Memory 128Mbyte
Bluetooth connection
・出力量の制御はTriBOARDが行う
―外付けbluetoothドングル(planex)
一定距離を保ち NXT
―Ethernetポート
ライントレース
MindStrom NXT
―前方の距離を測ることができる
（超音波センサーを使用）
―地面の色の判別ができる
（光センサーを使用）
―BluetoothによるTriBOARDとの
通信が可能
12. プロトタイピング全体図
プロトタイピングの構成と機材についての説明
プロセッシング
ユニット
・他のTriBOARDからの疎通監視 P P
T提案 ・取得した情報（疎通，距離）をTriBOARDへ送信
ネット ネットワーク
Ethernet connection
・管理するNXTの出力量制御を行う
アーキテクチャ ワーク P 被管理デバイス
TriBOARD
TriBOARD（マイコン）
・前方との測距情報を取得 ―Arm9(400MHz)
―Memory 128Mbyte
・管理するTriBOARDに送る
Bluetooth connection
―外付けbluetoothドングル(planex)
・出力量の制御はTriBOARDが行う
NXT
―Ethernetポート
操作の継承
MindStrom NXT
―前方の距離を測ることができる
（超音波センサーを使用）
―地面の色の判別ができる
（光センサーを使用）
―BluetoothによるTriBOARDとの
通信が可能
13. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
secure SQL parserを用いた操作
１．MindStormNXT制御量の送信
２．計測距離の取得
３．MindStormとのBluetoothコネクション接続・切断
制御量の設定
update NXT_Config#1 set
ア Value=‘40’
プ デバイス操作
where Name=‘Output’
リ Bluetoothパケット
ケ 計測距離取得 ID Name Value
ー select Value from
シ 0 Output 30
NXT_Config#1
ョ 1 Dist 70
ン Where Name = ‘Dist’;
・
MAPE
2 Status STOP
Bluetoothコネクション
update NXT_Config#1 set ↑secure SQL parser
MindStorm
Value=‘START’ データテーブル
NXT
where Name=‘Status’;
14. プロトタイプシステム実装
MindStormNXTの状態監視機能
Monitoring
Ａ．ＮＸＴの監視
別プロセス
Ｂ．通信の監視
Ａ．MindStorm NXTの監視機能
１．secureSQLparserを経由して距離の取得
Sミリ秒間隔で，問い合わせSQLクエリstrを送信
２．取得した距離情報を距離キューへプッシュ
３．他TriBOARDへの距離情報送信と受け取り
関連するknowledge
情報 値
距離問い合わせ間隔s[ms] 500
問い合わせクエリstr select Value from NXT_Config where Name = “Dist”；
距離キュー j j={0..2} 0~255
15. プロトタイプシステム実装
MAPEループ内のネットワーク監視機能
Monitoring
Ａ．ＮＸＴの監視
別プロセス
Ｂ．通信の監視
Ｂ．通信の監視機能
１．通信疎通確認のための通知
nミリ秒間隔でハートビット(HB)データ送信
２．他TriBOARDとの通信疎通の判定 関連knowledge
過去m秒以内に通信が無い 情報 値
No
TriBOARDが存在するか？ TriBOARDのID：i {0,1,2}
Yes 不通のTriBOARDに対
HB送信間隔n[ms] 1000
応したシンプトン値を
キューにプッシュ 不通閾値m[ms] 3000
３．他TriBOARDとのシンプトン共有 TriBOARD# jへ不通シンプトン j
―発生したシンプトンは全TriBOARDに送信 シンプトンキューj {0,1,2}
―TriBOARD#Jからシンプトンを受けた
シンプトンキューjにプッシュ シンプトンは自身が発行したものと
共有したものを利用できる
16. プロトタイプシステム実装
symptonと状態から変更要求の導出
基本動作
Monitoringが発行，共有したシンプトン TriBOARD#0の
シンプトン0 シンプトン#1 シンプトン#2 持つシンプトン
1 2 TriBOARD#1,2の
0 0 持つシンプトン
（通信の不通による非対称性がある）
アナライズポリシ１ 0が不通
“現在のネットワーク状態“を出力 関連するknowledge
NXT管理情報 情報 値
TriBOARD ID : i
アナライズポリシ１ （デシジョンテーブル）
アナライズポリシ２
変更要求としてa｛a∈N｝を出力 アナライズポリシ２ （デシジョンテーブル）
a アクションの要求意味
NXT管理情報j {0,1,2}
0 NXTの操作放棄 {j=0,1,2}
1 NXT#0の操作継承
2 NXT#1の操作継承
3 NXT#2の操作継承
17. プロトタイプシステム実装
基本的な動作管理を行うMAPEループ
Planing:アクションから処理コードへの写像
Execution:処理コード
Planningの動作
入力
入力 出力 出力
0 0
変更要求a 1 1,2,1,1,5
処理コードID列
2 1,3,1,1,5
3 1,4,1,1,5
Executionは
Executionの動作コード 処理コードID列の
処理コードID 割り当てコード 処理を順に実行
0 NXT操作放棄 関連knowledge
1 １秒待機 情報 値
2 NXT#0とBluetoothでSPP接続開始 プランポリシ （デシジョンテーブル）
3 NXT#1とBluetoothでSPP接続開始
4 NXT#2とBluetoothでSPP接続開始 実行順序やタイミングの管理も
5 継承したNXT監視の開始 可能にできる
18. 実験
プロセッシングユニットが外れるユースケースでの有効性検証
プロセッシングユニットが外れるユースケースについて
提案アーキテクチャの実環境での有効性を検証したい
③操作継承
TriBOARDを任意の順で２台Ethernetから切り離して， ①認識
NXTの操作を継承できるか検証する ②共有 P P
―ネットワークから切り離し時に操作の継承が正常に行われるか ネットワーク
①認識
―平常時の情報の共有は正常に行えているか P
ＮＸＴ＃１が取得する距離情報の監視ログを見ることで継承ができたか検証する
19. 情報共有と操作継承
NXT#1の管理者情報 NXT#1の操作放棄
TriBOARD#1
NXT#1の継承完了
1 (TriBOARD#0)
NXT#2の操作放棄
(TriBOARD#2)
NXT#2の管理者情報
NXT#2の継承完了
2 (TriBOARD#0)
82 101 156 167
NXT#1について距離データ
時系列（1=500ms）
20. 情報共有と操作継承
NXT#1の管理者情報 NXT#1の操作放棄
TriBOARD#1
NXT#1の継承完了
1 (TriBOARD#0)
NXT#2の操作放棄
(TriBOARD#2)
NXT#2の管理者情報
NXT#2の継承完了
2 (TriBOARD#0)
82 101 156 167
NXT#1について距離データ NXT#1の継承後も
NXT#1の管理は
正常に行えた
時系列（1=500ms）
21. まとめ
• 構成が動的に変わるネットワーク型組み込みシステムの
課題として，動的な構成変更に伴う管理を位置づけた
• 課題へのアプローチとしてACのMAPEループ機能を参考にした．
• 組み込みデバイス操作の仕様差，通信インタフェースの差異
を吸収する解の一つとしてsecure SQL parserとDispatcherを組
み合わせて自己管理アーキテクチャを提案した
• プロトタイピングによって通信の障害が発生する
実環境でも提案アーキテクチャによる操作の継承が可能なこ
とを確認した．
25. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
NXTに含ませた意図的な仕様差
出力30%の出力値指定のパケット
20 0 30 0 0 … 0 NXT#0
20 0 0 30 0 … 0 NXT#1
20 0 0 0 30 … 0 NXT#2
ID Name Value NXTの出力量の変更クエリ
0 Output 30 update NXT_Config#1 set
1 Dist 255 Value=‘40’
2 Status STOP
↑作成したsecureSQLparserのデータテーブル
(NXT_Config#1 ~NXT_Config#2)
26. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
NXTに含ませた意図的な仕様差
出力30%の出力値指定のパケット
20 0 30 0 0 … 0 NXT#0
20 0 0 30 0 … 0 NXT#1
20 0 0 0 30 … 0 NXT#2
ID Name Value NXTの出力量の変更クエリ
0 Output 40 update NXT_Config#1 set
1 Dist 255 Value=‘40’;
2 Status STOP
NXT_Config#1.so
↑作成したsecureSQLparserのデータテーブル
(NXT_Config#1 ~NXT_Config#2) パケット送信
20 0 0 40 0 … 0
27. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
NXTに含ませた意図的な仕様差
距離データ要求パケット
20 0 255 0 0 … 0 NXT#0
20 0 0 255 0 … 0 NXT#1
20 0 0 0 255 … 0 NXT#2
ID Name Value NXTの距離データの要求
0 Output 30 select Value from NXT_Config#1
1 Dist 255 where Name = ‘Dist’;
2 Status STOP
↑作成したsecureSQLparserのデータテーブル
(NXT_Config#1 ~NXT_Config#2)
28. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
NXTに含ませた意図的な仕様差
距離データ要求パケット
20 0 255 0 0 … 0 NXT#0
20 0 0 255 0 … 0 NXT#1
20 0 0 0 255 … 0 NXT#2
ID Name Value NXTの距離データの要求
0 Output 30 select Value from NXT_Config#1
1 Dist 255 where Name = ‘Dist’;
2 Status STOP
NXT_Config#1.so
↑作成したsecureSQLparserのデータテーブル
(NXT_Config#1 ~NXT_Config#2)
パケット送信
20 0 0 255 0 … 0
29. プロトタイプシステム実装
デバイス間の仕様差を吸収するミドルウェアの実装
NXTに含ませた意図的な仕様差
距離データ要求パケット
20 0 255 0 0 … 0 NXT#0
20 0 0 255 0 … 0 NXT#1
20 0 0 0 255 … 0 NXT#2
ID Name Value NXTの距離データの要求
0 Output 30 select Value from NXT_Config#1
1 Dist 70 70 where Name = ‘Dist’;
2 Status STOP
NXT_Config#1.so
↑作成したsecureSQLparserのデータテーブル
(NXT_Config#1 ~NXT_Config#2)
距離データ受信
20 0 0 70 0 … 0
