はじめに
はじめまして,NTTコミュニケーションズの川戸と申します.
同社のIoTチームにて, Things Cloud という IoT プラットフォームを活用したソリューションアーキテクトに携わらせていただいております.
本記事は,NTTコミュニケーションズ Advent Calendar 2020の23日目の記事です.
いよいよクリスマスも目前ですね!このご時世で外出もままなりませんが,適度に楽しんでいきましょう.
さて,早速ですが本記事の概要をご説明します.
今回は,EnOcean Multisensor STM 550 というセンサデバイスを使用し,クラウドサービス上に設置先の様々な情報を表示する流れをまとめていきます.
センサから取得した情報のアップロード先は,弊社の Things Cloud を選択します.
今回使用するセンサ STM 550は,まだ Things Cloud への接続実績がありませんので,こちらの接続検証も兼ねて取り組んでみました.
これからIoTシステムを自分で構築してみたい,という方にとっても何かしらご参考になれば幸いです.
また,記事に不正確な点や事実誤認がありましたら,コメントにてご指摘ください.
EnOcean とは
ご存知の方も多いかとは思いますが,EnOcean(エンオーシャン)とは,EnOcean社が開発し,基本特許をもつエネルギーハーベスティング無線通信技術のことを指します.
EnOceanは,エネルギーハーベスティング技術により,無給電で動作するという大きな特徴があります.あまり高頻度な通信には向きませんが,一般的なIoTシステムのように定頻度で少量のデータ通信を主として行う場合,電池レス,配線レスのEnOceanセンサは非常に有効であると言えます.
大量のデバイスを扱うIoTシステムでは通常,電池交換などのメンテナンスが必要不可欠かつ面倒な部分となっており,この作業が必要なくなることはIoTシステムにとって大きなメリットであるため,EnOceanは今後ますます注目度が高まる技術であると考えられています.
EnOceanの技術仕様など,さらに詳しい情報については下記の記事をご覧いただくとより理解が深まります.
使用機器と構成
本記事で使用するデバイス等についてご説明します.
センサデバイス
データ収集用のセンサとしてEnOcean Multisensor STM 550を使用します.
以下の図からもわかる通り,かなりコンパクトな造りをしており,配線等は一切ありません.
このセンサ1つで
- 温度センサ
- 湿度センサ
- 照度センサ
- 3軸加速度センサ
- マグネットセンサ
の役割を果たすことができます.
どのセンサデータを送信するかは,設定から変更することが可能です.
今回はせっかくなので全てのデータを送信してみましょう.
因みにですが,このセンサはNFCリーダに対応しており,NFC対応のスマートフォンに専用のアプリをインストールすることで,スマホから簡単に設定を変更する事ができます.変更できる設定内容も,送信するデータ種別だけでなく,データの送信間隔や閾値など,柔軟性が高いものになっています.ご参考までに,専用アプリの動作画面を以下に載せておきます.
(App Storeにて"EnOcean Tool"でヒットします.iPhone8で問題なく動作することを確認)
IoTゲートウェイ
センサからのデータをクラウドへアップロードするには,ゲートウェイ(以下,GW)が必要となります.
EnOceanセンサを使用する場合,当然ですがGWもEnOceanに対応している必要があります.
今回は簡単のため,Raspberry Pi 4 に EnOcean対応通信モジュールを接続し,GWとして使用します.
クラウドサービス
センサだけではIoTシステムとして成立しません.センサデータを蓄積し,管理するプラットフォームが必要です.本記事では,Things Cloud 上にデータをアップロードし,リアルタイムにデータを観察してみましょう.
Things Cloud は,IoTシステムを構築・管理する上で必要となる様々な機能が全て標準搭載されているため,特別な知識が無くても非常に扱いやすいクラウドサービスであると言えるでしょう.実際の動作画面は以下の図の様になっています.センサデータの可視化UIもとても見やすいですね.
Things Cloud についての詳細は,NTTコミュニケーションズ公式サイトをご覧ください.
Node-RED
センサから受信したデータを解析してクラウドへの送信を実行するための,所謂 Agent Software の実装に使用します.このNode-REDを使用してAgent Softwareを実装し,Raspberry Pi 上で動作させます.以下の図の様に,コードブロック形式のプログラミングツールとなっており,今回の様なテスト開発にもうってつけです.
構成
以上の構成要素の関係を簡単にまとめると,以下の様になります.
センサとクラウドサービスとの接続
センサデータを可視化するには,いくつかの工程を踏む必要があり,
使用する機器等にもよりますが,基本的には以下の様な流れになっています.
以降,それぞれの工程について詳しく説明していきます.
- センサとGWのペアリング(EnOceanの場合はTeachi-in機能による事前登録)
- センサデータの解析
- 使用クラウドに応じたデータ整形処理
- クラウドへのデバイス登録
- データ可視化画面の構築
EnOceanはブロードキャストの通信ですので,センサとGWのペアリング機能はなく,GW側でセンサのIDと通信プロファイルの対応づけを行います.このセンサのIDと通信プロファイルの対応づけの作業を行うため,Teach-Inという仕組み用意されており,データの種別や取りうる値の範囲などのデータ定義をGWに登録できます.(しかし今回は理解を深めるため,Teach-Inを使用せずに実施しています.)
1. センサとGWのペアリング(センサの事前登録)
まずはセンサの仕様書を見てみます.
今回使用するSTM-550は,冒頭でも述べた通り設定によって送信するデータ種別をカスタマイズできます.そのため,設定によって通信プロファイルも異っていることがわかりました.今回はデフォルト設定ですが,扱えるデータ種の最も多いプロファイルを使用します.
仕様書で確認すると,プロファイル番号は「D2-14-41」となっていますね.
EnOceanでは送信される電文の中にプロファイル番号が含まれていないため,EnOceanを利用するアプリケーションは,各センサのIDとプロファイル番号の対応付けを独自に実装する必要があります.
今回は,Node-REDのプログラムから読み込み易いよう,JSON形式で Raspberry Pi 上に保存することで,プロファイル番号とセンサのシリアルIDとの対応づけをGW側で保持します.
{"sensors":[ {"Serial ID": "d21441"} ]}
2. センサデータの解析
EnOceanの通信プロトコル
さて,いきなり通信プロファイルの話が飛び出しましたが
その前に,EnOceanの通信プロトコルの基本的な部分から改めてご説明しておきます.
まず,EnOceanセンサから送信される電文は,大別すると次のような構成をしており,
登場するプロトコルは4つです.
プロトコル | 役割・概要 | 規格 |
---|---|---|
ESP3(EnOcean Serial Protocol 3) | データ長,パケット種別,チェックサムなど | EnOcean GmbH |
ERP2(EnOcean Radio Protocol 2) | 送信元ID,電文タイプなど | EnOcean GmbH |
EEP(EnOcean Equipment Profiles 2.6.X) | 各センサにおけるデータモデルの定義 (予め登録されているものを扱う) |
EnOcean Alliance |
GP(Generic Profiles 1.0) | 各センサにおけるデータモデルの定義 (センサのメーカが独自に定義) |
EnOcean Alliance |
各センサごとのデータモデル定義はEEPもしくはGPで行われており,これらのデータモデルをネットワーク経由でやりとりするためにERP2,ESP3でパケットがカプセル化されます.
先ほど登場したプロファイル番号とは,EEPにおけるデータフォーマットの識別番号のことでした.(EEPのプロファイルはEnOcean Allianceへの申請によって可能で,200以上ものデータフォーマットが登録されているとのこと)
ESPとERP
まずはESPとERPの内容を解析する機能を実装する必要があるのですが,
この部分はEnOceanの基本となる部分であり,どのメーカのEnOceanセンサでも共通です.
つまり,一度実装してしまえばずっと使いまわせる,という事になります.この辺りは標準化プロトコルの強みと言えますね.
ESP・ERPの説明から始めると,クリスマスが終わってしまいそうなので,本記事では割愛させていただきます.ご興味のある方は,下記の記事をご覧ください.
- IoTの台風の目!?EnOceanについて本気出して語ってみた
- Node-REDのserialノードを使ってEnOceanのスイッチデータを受信してみた
- Node-REDでのEnOceanのデータ読み取りをもう少し踏み込んだメモ
EEP
さて,大幅に端折ってしまいましたが,ここまでの内容を実施していただくと,受信したセンサデータから以下のような情報を取り出すことができるはずです.(Node-REDのデバッグウィンドウにて確認可能)
次に解析すべきは,上記payload
に含まれる9Byteからなるデータです.
ここで,もう一度STM-550の仕様書を確認しましょう.
先ほどのpayloadに含まれていた9Byteのデータの読み方が記述されています.
ここから読み取れる内容を図にまとめると,以下の様になりますね.
ここまで理解できれば,後はpayloadの中身を適切に処理するのみとなります.
具体的には,下記の様な処理をそれぞれのデータに対して行います.
// データの抽出&格納用に初期化
var data = msg.payload;
msg.data = {};
//温度(先頭10bit, -40°C ... 60°C)
var temp = data[0]<<2 | (data[1]&0xC0)>>6; //必要な部分を連結
temp = temp / 1023.0 * (60 - (-40)) - 40 //表現可能範囲に合わせる
msg.data.Temperature = temp;
湿度,照度,加速度,マグネットについても同様の処理を行うと,センサデータの解析は完了です.ここまで解析が進むと,いよいよ人間が読んでも理解できる情報が得られました.
詳しい動作確認は後に行いますが,感覚的には正しくデータが抽出できていると思われます.
3. 使用クラウドに応じたデータ整形処理
続いて,抽出したセンサデータをクラウドにアップロードする訳ですが,
その前にクラウド側が理解できる形にデータを整形する必要があります.
Things Cloud の場合,クラウドに送信するセンサデータはメジャーメントと呼ばれるフォーマットに従って整形されている必要があります.
メジャーメントへのデータ整形は,具体的に下記の様な処理で実現できます.
// フラグメント格納用オブジェクト
var fragments = {};
//温度
var c8y_TemperatureMeasurement = {};
var T = {};
T.value = msg.data.Temperature; //計測値
T.unit = "C"; //単位
c8y_TemperatureMeasurement.T = T;
fragments.c8y_TemperatureMeasurement = c8y_TemperatureMeasurement;
整形されたメジャーメントは,下記の様なJSON形式で保存されます.
{
"c8y_TemperatureMeasurement": {
"T": {"value": "---", "unit": "C" }
}
}
メジャーメント形式に整形すると,後はThings CloudのAPIを利用してデータをPOSTするだけですので,この部分も割愛していきます.
ここまで本記事でご説明した処理をNode-REDのフローで表現すると,次の様になります.
4. クラウドへのデバイス登録
ここからは,Things Cloud側から設定を行っていきます.
まずは,今回IoTゲートウェイとして使用する Raspberry Pi をデバイス一覧に登録します.
デバイス登録は,以下の図のように,デバイス管理
> デバイス
> 登録
から実施します.
登録が完了すると,デバイス一覧
画面にRaspberry Piが表示されます.
このように,デバイスの登録・管理が直感的かつ簡単に行えるのもThings Cloudのいいところだと思います.
5. データ可視化画面の構築
続いて,クラウドにアップされたデータの可視化画面を構築します.
冒頭で例をお見せしておりましたが,Things Cloudではコックピット
と呼ばれるアプリケーションから,デバイスごとまたはグループごとに可視化画面を自由にカスタマイズできます.
本記事の本題ではないので,ここはあまり拘らず,以下のようにウィジェットを配置してみました.これで,マルチセンサで取得した様々なデータが,リアルタイムにかつ一目で把握できるようになりました.
以上で,センサデータをクラウド上で可視化する作業は完了です.お疲れ様でした.
動作確認
最後に,センサ本体および今回実装したAgent Softwareが正しく動作しているか,実際にセンサへ刺激を加えながら確認していきます.
温度・湿度
まずは基本となる温度と湿度です.
私の部屋には温度計の類がないので正確な値を知ることはできませんが,実際こんなものでしょう.
照度
続いて,照度を見てみましょう.
めちゃめちゃ暗いですね.こちらも照度計などは置いていないので正解値は不明です.
心配なので,照度センサに直接ライトを当ててみました.
無事に明るさの変化に応答してくれていますね.
仕様書によると100000luxまで計測可能とのことでしたが,屋内ではそこまでの明るさは必要なさそうです.
加速度
次は加速度です.
EnOceanセンサはデータ送信間隔が長めなので,センサの動きをトラッキングするのではなく,センサの傾きを読みとることがメインの用途になると思われます.
動作確認として,以下のようにセンサ本体の置き方を変えながら,センサ値の変化を観察しました.図より,重力加速度(約1g)の加わり方が置き方に応じて正しく変化していることがわかります.こちらは間違いなく正しく動作しているといえそうです.
STM-550は,3軸の加速度センサ値以外に,
AccelerationStatus
というものもセンサデータの1部として送信しています.こちらは,センサが動いている時に1
を,センサが静止している時に0
を示します.
マグネットコンタクト
最後はマグネットセンサです.
マグネットセンサは,その名の通り磁石を近づけたり離したりすることで値が変化します.
こちらも問題なく動作していることが確認できました.
マグネットセンサは,磁石が近づいた時,離れた時,それぞれ即座にデータを送信します.
他のセンサも,センサ値に大きな変化が起こった場合,デフォルトのデータ送信頻度によらずデータの送信を行う仕様になっているようです.(加速度の場合は,AccelerationStatusが0→1の時に即座に送信.再び0に戻るまでは通常通りの頻度で送信)
考察
今回クラウドへ接続したSTM-550ですが,実際に使用する場合にどのような使用用途があるのか,少し考えてみました.
これまで述べてきたように,STM-550では5種類のデータを扱うことができます.それぞれのセンサで出来ることを考えると,下記のようなところかと思います.(もっとよく考えれば様々な使い方がありそうですが.)
センサ種 | 基本使用用途 | 応用 |
---|---|---|
温度センサ | ・室内状況の監視 | ・空調設備の自動制御システム ・食品衛生管理システム |
湿度センサ | ・室内状況の監視 | ・空調設備の自動制御システム |
照度センサ | ・室内状況の監視 | ・照明設備の自動制御システム |
加速度センサ | ・窓やケージなどの開閉検知 ・荷物などの転倒検知 ・稼働率監視 |
・窓などの閉め忘れ防止システム |
マグネット センサ |
・扉などの開閉検知 | ・空室 / 利用状況管理システム ・配達物などの開封検知システム※ |
上記全てのデータを組み合わせて有効活用することは難しそうですが,
「生き物などを飼育するケージの総合マネジメント」
などはいかがでしょうか.
生き物などを飼育するケージの総合マネジメント
動物園や水族館,趣味で生物の飼育を行っている人向けに,ケージの状態監視システムを構築できそうです.温湿度や照度を把握し,必要に応じて手動または自動で設備を調節できます.また,加速度センサやマグネットセンサを利用することで,扉や蓋の閉め忘れ時にアラームで知らせることもできますし,万が一生物が脱走した場合も逸早く気づくことができます.
似たようなサービスは既にありそうですが,STM-550の場合,これ1つで全て完結しますし,配線や電池交換が一切必要ないという点で差別化を図っていけるのではないでしょうか.
※先日のニュースにて,極低温で保存する必要のある新型コロナウィルス用ワクチンの運搬には,温度管理用のデバイスが箱に同封されているとの情報を耳にしました。STM-550では-20℃までしか計測できず互換性は全くありませんが,転倒検知や開封検知と組み合わせ,ワクチンのように重要な荷物の安全管理に有効活用できるかもしれません.
おまけ:作業中に困ったことのメモ
以下の図はSTM-550のVLD Telegramの内容を記したものですが,ここのデータパースで若干詰まる部分があったのでメモしておきます.
受信した9byteのデータを,上記の仕様書通りに素直に読み解くと,次のようになります.
ところが,この形式でデータ解析を行うと,加速度だけ狂っているように感じました.
具体的には,センサ本体を動かしていないにもかかわらず,加速度センサの値が一定に定まらない,重力加速度に対して検出される値が明らかにおかしい,などです.
また,Acceleration Status の値も動きにかかわらず1になったり0になったりしていました.
感覚的な部分も含みますが,加速度センサ以外のデータは正常に見えたため,加速度だけ何かがおかしいという予想のもと,試しに以下のようにデータ解析の順序を変更してみました.
その結果,これまで確認してきたような正常な値を読みとることができました.
色々試してみるもんですね.
おわりに
長らくお付き合いいただきありがとうございました.
また機会がありましたら何かしらまとめていきますので,今後もよろしくお願いいたします.