センサーデータの収集と可視化¶

まずはシンプルにセンサデバイスからセンサデータを集め、バックエンド上で集めたセンサデータを参照するところまでの設計について説明します。

Device Adapter によるセンサデータ収集¶

はじめに、Deviceからのセンサデータを収集する基本構造を決定します。

Deviceへの接続用ライブラリの選定
デバイスとの通信に必要なライブラリやドライバを選定します。
対象となるエッジGWのファームウェアやOSに含まれる標準的なドライバやAPIで実現できない場合は追加のライブラリやドライバのセットアップ方法を含め検討します。
Deviceへの接続
利用するライブラリやAPIの使用方法に従い、Deviceへの接続方法を決定します。
Deviceからのデータ取得
接続したDeviceからのデータ取得方法を決定します。
取得したデータの解析
対象のDeviceの仕様を確認し、 Deviceから取得した生データ(バイナリデータや文字列)を解析します。
送信データの作成、データフォーマットの設計
ICEでは内部データをKey-Valueの形式で扱います。
Deviceから取得したデータに含まれる値をどのようなキーに関連付けて送信するかを決定します。
ここで、Backend側の仕様(どのようなKey-Value仕様にするか)があらかじめ決まっている場合は、その仕様に合わせたキーを使う事になります。接続先のBackendが決まっていない場合など、合わせるべき仕様が無い場合はここでその仕様を決定する必要があります。 ICEを使えば、Backend側の仕様とここで決めたデータフォーマットの仕様が食い違う場合であってもトポロジ定義によってそのフォーマットの差異を吸収し、Device Adapterを修正することなくBackendにデータをつなぎこむことが出来ます。
データのサイズ
ICEによってやり取りする(ICE Core→バックエンド, バックエンド→ICE Coreの両方向で)送信データ本体が999.5KBを越えないよう注意してください。
データ送達保証(エッジ)
Device AdapterやEdge Applicationはエッジ - バックエンド間の通信路が遮断された状態(サーバ側処理できない状態も含む)にあっても、送信用のAPI(emit)を実行することが出来ます。送信データはICE Coreにバッファリングされ、通信路の復旧後に送信されます。ただし、通信ができない状態で送信データが溜まり続けることによってエッジ側のメモリが圧迫されることがあります。設定した最大値を超えたデータ送信要求は破棄されますが、破棄されたことはアプリケーションには通知されません。
データ送達保証(バックエンド)
バックエンド側の構成や運用によってはバックエンド側に到達したデータがロストする可能性があります。例えば下記いずれかのようなケースでエッジからの転送データが失われます。
- ICE Backend
  MongoDBの可用性を担保できない場合、MessageRouterからのMongoDB書き込み前にデータがロストします
- CAP
  RabbitMQの可用性を担保できない場合、Nebula API Gateway(AMQP)からRabbitMQへのデータ送信がエラーとなりデータがロストします(CAP)

プロファイル情報の決定¶

Device Adapter Profile
Device Adapter に対するメタデータ(VendorやVersionなど)の他にも、任意のKey-Valueを設定できます。このプロファイルに、Device Adapter動作用の設定を記載できるのでどのような設定項目を用意するかを決定します。
Device Profile
Device のメタデータ(VendorやModelNoなど)と、Deviceで発生するデータの種別を示すdata_typeを設定します。
Profileデータのサイズ
ICEでやり取りするデータと同様999.5KB以内に収まるよう注意して下さい。

Edge, Device Adapter, Deviceの識別¶

ICEでは下記の方法でシステム内のエッジ、Device AdapterやEdge Application、Deviceの識別が行えるようにしています。

edge_id
ICE Coreのcore_config.jsonに設定したedge_idの値です。
この値は、利用者によってシステムで一意な値を設定する必要があります。
尚、エッジGWエントリモデルにプリインストールされるICE CoreはエッジGW内臓のWebUIによるキッティングを実行したタイミングでエッジGWの型番+製造番号をedge_idに指定します。
Device Adapter のobject_id
Device Adapter初期化時に下記情報をキーにしてICE Coreがエッジに閉じた一意な識別子を払い出します。
- Device Adapter名(プログラムを配置するディレクトリ名)
- Device Adapter Profile名(Device Adapter Profileのファイル名)
Edge Application のobject_id
Edge Application 初期化時に下記情報をキーにしてICE Coreがエッジに閉じた一意な識別子を払い出します。
- Edge Application名(プログラムを配置するディレクトリ名)
- Edge Application Profile名(Edge Application Profileのファイル名)

Note

object_idが衝突する可能性があるため、本番適用前に評価環境で衝突の有無を確認してください。

Device毎のdevice_id
Deviceの登録関数呼び出し時に下記情報をキーにしてICE Coreがエッジに閉じた一意な識別子を払い出します。
- Device Adapter名(プログラムを配置するディレクトリ名)
- Device Profile名(Device Profileのファイル名)

複数の Device Adapter名、Edge Application名で名前が重複しないようにします。

この名前はディレクトリ名になるので、既存のモジュールを再利用する際に重複するようなことがあれば、配置先のディレクトリ名変更で対応します。そのため、Device AdapterやEdge Applicationを設計するに当たり配置先のディレクトリ名に依存するような実装・設計は避けてください。

Device Adapterのプログラム構造¶

Device Adapterは概ね下記処理を実装する事になります

プログラムのエントリポイント
ICE Coreとの接続, Device Adapterの初期化
デバイスとの接続確立
デバイスをICEに登録
デバイスからのデータ採取
データの解析, 送信データの作成
データの送信
5-7の繰り返し
プログラムの終了処理、シグナルのハンドリング

複数デバイスの接続¶

一つのDevice Adapterプロセスで複数のDeviceを扱うことが出来ます。その方法としては下記の２種類があります。

Device Profileをデバイス数分用意し、ddca_devadpt_register_device()で一つずつ登録＆ID払い出し Profile単位でdevice_idを一意に割り当てられますが、デバイス数分のファイルを用意する必要があります。
デバイス数が限られており、デバイス毎の設定があらかじめ定義できる場合に向いています。
Device Profileを一つ用意し、ddca_devadpt_register_multi_devices()でまとめて登録＆ID払い出しファイル１つで済みますが、実際のデバイスとdevice_idとの紐付をプログラム側で担保する必要があります。
デバイス数が多く、デバイスの個体識別が重要でないような場合に向いています。

バックエンドからのデータ参照¶

Device Profileで決定したdata_typeを指定して複数のエッジを横断したデータ取得が可能です。

ただし、エッジの数が増えてきた場合に一度に取得できるデータ量が増えてしまうため、下記観点での絞り込みを検討します。

edge_idを指定したfilter
センサデータに含まれるデータを条件に指定したfilter

バックエンドからのエンティティ参照とセンサデータとの紐付¶

ICE Coreの設定、Device Adapter Profile、Device Profile、Edge Application Profile を参照できます。

Device Adapterによって収集したデータには必ずdevice_idが付与されるため、そのデータがどのようなDevice ProfileのDeviceから発生したデータなのかを紐付けることが出来ます。