目次


たった 7 つのステップでコグニティブ IoT アプリを構築する

Data Science Experience を利用して、高度な機械学習を適用して IoT センサーのデータ・ストリームを基にリアルタイムで異常を検出するコグニティブ IoT ソリューションに変身させる

Comments

コグニティブ IoT をコグニティブたるものにするものは何でしょうか?どうすればコグニティブ IoT を実現することができるのでしょうか?一部の人々にとって、コグニティブ IoT は人とモノとの間のやりとりをより人間らしくすることにつきます。例えばエレベーターの中で、ソーシャル・メディアがその人の心理学的プロファイルに基づいて最新のニュースを報じたり、その人がストレスを感じていることを認識してリラックスさせる音楽を流したりするなどといった人とモノとの間のやりとりです。

私自身は、コグニティブ IoT の舞台裏で何が行われているかのほうに興味があります。人間とコンピューターの相互作用 (HCI) は多くのコグニティブ IoT で鍵を握る部分になっていますが、HCI はすでに最先端のテクノロジーになりつつあるので、このチュートリアルでは HCI よりも舞台裏の仕組みに重点を置きます。コグニティブ IoT アプリの舞台裏で IBM Watson コグニティブ API (テキスト音声変換 (TTS)、音声テキスト変換 (STT)、機械翻訳、視覚認識など) が動作すれば、想像力以外に、高度な HCI の可能性を制限するものはなくなります。

コグニティブ IoT と人口知能 (AI) は高度な機械学習でしかありません。高度な機械学習には 2 つの原動力があります。

  • 必要な動作をデータから学習できるだけの力を備えたアルゴリズム (またはモデル)。
  • トレーニング対象の膨大な量のデータに対処するための無制限のデータ処理機能とストレージ。

コグニティブ IoT ソリューションでは、機械学習をエッジ・コンピューティング・アーキテクチャー内で行う必要があります。エッジ・コンピューティングとは基本的に、計算処理の舞台をクラウドやデータ・センターからセンサー近くの場所に移すことを意味します。つまり、センサーやアクターの近くにあるエッジ・ゲートウェイ上で計算を行います (あるいは、ゲートウェイとセンサーまたはアクターの間にあるマイクロコントローラー上で計算を行って、センサーやアクターとの距離をさらに縮める場合もあります)。エッジ・コンピューティング・アーキテクチャーを使用するのは、以下の 2 つの理由から、クラウド内での計算によってあらゆる決定を下すことはできないためです。

  • 待ち時間。クラウドとの間でデータを送受信するだけの余裕がない極めて重要な意思決定には、待ち時間が影響を及ぼします。例えば、インターネットに接続されたスマート・カーについて考えてください。スマート・カーの車内から自宅に時折 (つまり、数秒以内で) 電話できるのは便利ですが、前を走っている自動車が急ブレーキをかけたとしたら、スマート・カーが即時に反応しなければなりません。
  • 転送コスト。センサーが生成するデータ全体をクラウドに転送するには量が多すぎる場合、転送コストが極めて高くなる可能性があります。リンク速度のためにデータ全体をクラウドに転送するのは技術的に不可能であるか、単にコストが高すぎるか、またはその両方が当てはまることもあります。

コグニティブ IoT のアーキテクチャー

図 1 に示すアーキテクチャー図を見て恐れることはありません。この図は、コグニティブ IoT を実装するために必要なコンポーネントを大まかに示したものです。作成するソリューションでは、これらのコンポーネントのサブセットだけを使用する場合もあります。その場合、アーキテクチャーはこれよりも単純になります。嬉しいことに、サービスとしての IBM Cloud を利用するとしたら、これらすべてのコンポーネントがプリインストールされていて、しかもその運用管理をすべて任せることができます。さらに、これらのコンポーネントはオープン・スタンダードをベースにオープンソース・テクノロジー上で動作するため、ロックインが最小限に抑えられます。したがって、投資が保護されることにもなります。

図 1. コグニティブ IoT アプリケーションのアーキテクチャー図
コグニティブ IoT アプリケーションのアーキテクチャー図
コグニティブ IoT アプリケーションのアーキテクチャー図

すべての IoT ソリューションに共通して、その中核となるのはセンサーとアクターです。センサーを使用して環境を認知し、(認知した事実に基づいて) 意思決定を行い、アクターによって対処するという構図です。

コンピューティング・アーキテクチャーにおける進化を考えてください。サイロに限定された考え方から、エッジという考え方、そしてクラウドという考え方へと進化し、さらにエッジとクラウドを組み合わせた考え方へと進化しています。機械学習を含むエッジ・アナリティクスは、クラウド上でのデータ・ロードを最小限にまで減らし、待ち時間とデータ転送コストを激減させます。その上、すべてのデータをクラウドに送信しなければならないわけではないこと、あるいはデータをマスクできることから、プライバシーがより強力に保護されることになります。

開発時ではなくデプロイ時に物理的な場所を決定できるようにするには、分析コンポーネントをエッジおよびクラウド全体にわたってシームレスに置き換え可能な形でデプロイすることが重要となります。プラットフォームの中には、実行時の分析コンポーネントの動的再配置をサポートしているものもあります。そのようなプラットフォームの 1 つとして、このチュートリアルでは Node-RED を使用します。

説明のための極めて単純なシナリオとして、湿度センサーを使用して植物に水をやるタイミングを決定するスマート・ガーデンを取り上げます。給水ホースのバルブを開け閉めするアクターとしては、ステッピング・モーターを使用することになります。

フェーズ 1 – サイロのみのコンピューティング

図 1 のアーキテクチャー図を見るとわかるように、このシナリオではセンサー、アクター、マイクロコントローラーが必要になります。Micro_Model を使用して水分レベルに設定したしきい値を読み取り、アクションを実行するタイミングを決定します (決定の揺らぎや過剰な給水を防ぐために、動的にトレーニングしたヒステリシスを使用することも考えられます)。

フェーズ 2 – エッジのみのコンピューティング

一方、スマート・ガーデン・システムが自動的に植物に水をやった直後に雨が降ってきたとしたらどうなるでしょうか?水を無駄にするだけではなく、植物が水分過剰の状態になってしまうかもしれません。天気予報も考慮に入れることはできないでしょうか?もちろんそうすることもできますが、それには気象サービスに対するクエリーが必要になってくることから、マイクロコントローラーだけでは目的を果たせません。エッジ・ゲートウェイ上で機械学習アルゴリズムを使用すれば、天気予報と水分センサーに基づいて給水を最適化した上で、マイクロコントローラー上のそのモデルを更新することができます (マイクロコントローラー、そしてエッジ・ゲートウェイ自体で、ヒステリシスを使用していることを思い出してください)。

フェーズ 3 – エッジおよびクラウドでのコンピューティング

ここで、アーキテクチャー図に示されている他のコンポーネントもいくつか導入しましょう。最初のステップは、エッジ・ゲートウェイをクラウドに接続することです。この接続で事実上の標準となっているのは、MQTT と MQTT メッセージ・ブローカーを使用することです。パブリッシュ/サブスクライブ・モデルでは、n 対 n の接続シナリオに容易に対応できます。ゲートウェイからキューにデータを送信するだけでは不十分なので、ETL (Extract, Transform, Load) コンポーネントも導入しなければなりません。ETL コンポーネントでメッセージ・バスからデータを取得して保管し、そのデータをリアルタイムで処理するコンポーネントに送信し、さらに MQTT メッセージ・ブローカーにもデータを送信します。最後に、このデータをバッチ・アナリティクス・エンジンで使用して、さらに洞察を引き出すという仕組みです。このアーキテクチャーは、コグニティブ API サービスをリアルタイムで、あるいはバッチ処理中に呼び出すことで完成します。

このシナリオでは、スマート・ガーデン・システムを e-メール・アカウントにリンクすることにします。Watson コグニティブ API を使用すれば、旅行計画やカレンダーをいつでも簡単に抽出できます。その情報をスマート・ガーデン・システムで使用すれば、家族が庭で夕食をとっている間、芝を水で濡らさないようにすることができます。また、芝の状態に応じて自動的に肥料や殺虫剤をオーダーすることもできます。芝の状態を検出するには、特殊な科学センサー、またはウェブ・カメラで撮った画像を使用することで対処できます。

システムを最適化するための次のステップは、多数の機械学習アルゴリズムを利用することです。コグニティブ IoT アプリに最も関連性の高い機械学習アリゴリズムのタイプとしては、予測 (時系列予測など)、異常検出、最適化があります。

コグニティブ IoT ソリューションを構築する 7 つの単純なステップ

理論はこれくらいにして、コグニティブ IoT ソリューションの作成に取り掛かりましょう。このソリューションを作成するために使用するのは、IBM Cloud、IBM Watson IoT Platform、そして IBM Data Science Experience です。

次に取り上げるシナリオまたは使用ケースは、家庭用電化製品としてのスマート洗濯機です。例えば、あるデバイス・メーカーが、電流が安定していないと特定のモデルに搭載されているモーターが破損することを発見したとします。世界のどこにいるとしても、安定した状態の電流を当然のものとして考えることはできません!

当初、このメーカーはクラウドからのデータを頼りに電流の異常を検出していました。その IoT ソリューションでは、電流が不安定であることを示すデータを受信すると、コマンドを洗濯機に送信してモーターを停止するという方法をとっていましたが、最終的にメーカーが認識することになったのは、この方法では待ち時間が長すぎること、そしてインターネット接続の安定性が低すぎることです。そのため、メーカーはエッジ・コンポーネント上で分析を行い、この特定のプロセスからクラウドを除外することにしました。

アプリケーションを作成するための前提条件

  • Bluemix アカウント
    (このリンク先のページで無料のトライアルを申請して、あとでフリーミアムに変換することができます)。
  • Data Science Experience アカウント。

    Data Science Experience アカウントを作成するには、以下の簡単な手順に従ってください。

    1. http://datascience.ibm.com/ を開いて、「Sign up (登録)」をクリックします。
    2. Sign in with your IBM ID (IBM ID でサインイン)」をクリックします。
    3. Sign up for DSX (DSX に登録)」をクリックします。
    4. 「Create Organization and Space (組織とスペースの作成)」ページで、「Continue (続行)」をクリックします。
    5. 環境が初期設定されて利用可能になったら、「Get Started (開始)」をクリックします。

この使用ケースの運用モデル

図 2 に示している使用ケースの運用モデルを見るとわかるように、このモデルは図 1 のアーキテクチャー図全体とは大きく異なります (そして遥かに単純になっています)。この運用モデルにはこの使用ケースに必須のコンポーネントだけが含まれており、コンポーネントの総称は IBM クラウド内で利用できる特定のコンポーネントで置き換えられています。

図 2. コグニティブ IoT アプリの運用モデル
アーキテクチャー図に基づく運用モデルを示す図
アーキテクチャー図に基づく運用モデルを示す図

表 1 に、各コンポーネントとこの使用ケースでのそれぞれの役割を記載します。UML ステレオタイプは、図 1 の汎用アーキテクチャー図に基づいています。

表 1. 運用モデルのコンポーネント
コンポーネント名コンポーネントのタイプUML ステレオタイプコンポーネントの説明
Node-RED EdgeNode-REDエッジ・ゲートウェイデータ・フロー・アプリケーションを作成するために使用します。

Node-RED は、JavaScript で作成された、Node.js 上で稼働するオープンソースのデータ・フロー・エディターです。当初 IBM が開発した Node-RED は、のちに JavaScript Foundation に寄贈されました。
Sensor_Actor_simulatorNode-RED ノードセンサーまたはアクター物理 IoT システムがない場合、センサーまたはアクターをシミュレーションするために使用します。
Data Science Experienceサービスとしての Apache Spark および Jupyter ノートブックバッチ機械学習IoT センサーの時系列ストリームに基づき、リアルタイムで異常を検出するために使用します。
IBM Watson IoT PlatformIBM Watson IoT PlatformMQTT メッセージ・ブローカーIoT 運用モデルに含まれるすべてのコンポーネントを非同期で結びつける役割を果たします。
Node-RED CloudNode-REDELT およびリアルタイムのストリーム処理IoT センサー・データをクラウド・ストレージにストリーム配信するために使用します。
Cloud_Storage_Cloudant_NoSQLCloudantクラウド・ストレージIoT センサー・データを保管するために使用します。
Cloudant はサービスとしての Apache CouchDB です。SQL データベースまたは OpenStack Swift オブジェクト・ストレージ (最もコスト効果の高い選択肢) を使用することもできます。
Edge_ModelNode-REDエッジ・モデルバッチ機械学習コンポーネントによって動的に取り込まれる単純なしきい値を保持します。
1

Bluemix 内で IoT アプリを作成する

Internet of Things Platform Starter ボイラープレートには、Node-RED エンジンが含まれています。このエンジンは、あとで IoT メッセージを処理する際に使用します。

  1. Bluemix アカウントにログインします (またはフリートライアルにサインアップしてください)。
  2. 以下の URL を開き、Bluemix カタログ内の Internet of Things Platform Starter を表示します。
    https://console.ng.bluemix.net/catalog/starters/internet-of-things-platform-starter/?taxonomyNavigation=apps
  3. App name (アプリケーション名)」フィールドに、アプリの一意の名前を指定します (例: 1234yourName)。
    Bluemix カタログ内の IoT Platform Starter サービスを示す画面のスクリーン・キャプチャー
    Bluemix カタログ内の IoT Platform Starter サービスを示す画面のスクリーン・キャプチャー
  4. Create (作成)」をクリックします。
  5. 左側のメニューにある「Connections (接続)」をクリックします。Cloudant NoSQL DB Lite サービスのページで、「View credentials (資格情報を表示)」をクリックし、表示された資格情報に含まれるユーザー名、パスワード、ホストのプロパティーをメモします。
    Bluemix 内で Cloudant サービスのページに表示された「View credentials (資格情報を表示)」ボタンのスクリーン・キャプチャー
    Bluemix 内で Cloudant サービスのページに表示された「View credentials (資格情報を表示)」ボタンのスクリーン・キャプチャー
  6. 「Status (ステータス)」が「Running (実行中)」になるまで待ってから、「View app (アプリケーションを表示)」をクリックします。
    Watson IoT Platform Starter での起動ステータスを示す画面のスクリーン・キャプチャー
    Watson IoT Platform Starter での起動ステータスを示す画面のスクリーン・キャプチャー

    注: 要求したルートが見つからないことを意味する「404 Not Found: Requested route ('1234thisIsMyName.mybluemix.net) does not exist」というメッセージが表示されたとしても、ご心配なく。数分待ってから再試行してください。
2

デバイス・データをシミュレーションするデバイス・シミュレーターを作成する

  1. Go to your Node-RED flow editor (Node-RED フロー・エディターを表示)」をクリックします。
    Bluemix アプリ内で Node-RED フロー・エディターを開くためのボタンのスクリーン・キャプチャー
    Bluemix アプリ内で Node-RED フロー・エディターを開くためのボタンのスクリーン・キャプチャー
  2. デフォルト・フローに含まれる既存のノードをすべて削除するために、それらすべてのノードを選択してから Backspace キーまたは Delete キーを押します。(注: キーボード・ショートカットの CTRL-A は機能しません)。
    Node-RED エディター内のデフォルト・フローを示す画面のスクリーン・キャプチャー
    Node-RED エディター内のデフォルト・フローを示す画面のスクリーン・キャプチャー

    空白のキャンバスが表示されます。


    Node-RED エディター内の空のキャンバスを示す画面のスクリーン・キャプチャー
    Node-RED エディター内の空のキャンバスを示す画面のスクリーン・キャプチャー
  3. CognitiveIoT GitHub リポジトリーにアクセスして、flow1.json ファイルのコピーをダウンロードします。
  4. ダウンロードしたファイルをテキスト・エディターで開きます (注: ワード・プロセッサーを使用しないでください)。
  5. このファイルの内容全体をクリップボードにコピーします。
  6. クリップボードにコピーした内容を Node-RED フローにインポートするために、右上隅にあるメニューで「Import (インポート)」 > 「Clipboard (クリップボード)」の順にクリックします。
  7. Import nodes (ノードのインポート)」ダイアログ・ボックスで、コピーした内容をテキスト域に貼り付けてから「Import (インポート)」をクリックします。
    「Import nodes (ノードのインポート)」ダイアログ・ボックスのスクリーン・キャプチャー
    「Import nodes (ノードのインポート)」ダイアログ・ボックスのスクリーン・キャプチャー
  8. キャンバスをクリックしてフローをキャンバスに固定します。
    フローとしてインポートされたデバイス・シミュレーターを示す画面のスクリーン・キャプチャー
    フローとしてインポートされたデバイス・シミュレーターを示す画面のスクリーン・キャプチャー
  9. Deploy (デプロイ)」をクリックします。
3

デバイス・データをクラウド・ストレージ (NoSQL データベース) 内に保管する

  1. Node-RED エディター内で、新しいフローを作成します。それには、キャンバス領域の右上にあるプラス (+) 記号をクリックします。
    Node-RED エディターのキャンバス領域を示す画面のスクリーン・キャプチャー
    Node-RED エディターのキャンバス領域を示す画面のスクリーン・キャプチャー
  2. CognitiveIoT GitHub リポジトリーにアクセスして、flow2.json ファイルのコピーをダウンロードします。
  3. 前と同じようにファイルをテキスト・エディター内で開き、ファイルの内容全体をクリップボードにコピーします。
  4. クリップボードにコピーした内容を Node-RED フローにインポートするために、右上にあるメニューで「Import (インポート)」 > 「Clipboard (クリップボード)」の順にクリックします。
  5. 「limit to max 5000 entries (最大 500 エントリーに制限)」ノードを「washing (洗濯)」ノードに接続します。
    Node-RED エディターの「Flow 2 (フロー 2)」領域に表示されたノードを示す画面のスクリーン・キャプチャー
    Node-RED エディターの「Flow 2 (フロー 2)」領域に表示されたノードを示す画面のスクリーン・キャプチャー
  6. Deploy (デプロイ)」をクリックします。

おめでとうございます!IoT データが Cloudant Apache CouchDB NoSQL データベース内にストリーミング配信されるようになりました (注: あとで処理を高速にするためにデータのエントリー数を 5000 個に制限していますが、1 GB 相当のデータまで無料で保管できます)。

4

Data Science Experience を使用して IOT センサー・データ・ストリーム上で異常を検出する

最も単純な異常検出アルゴリズムの 1 つは、移動 z-score なので、このアルゴリズムを Apache Spark 上で SQL を使用して実装します。このアルゴリズムの仕組みを学ぶために、まず、平均値と標準偏差といった単純な測定から始めます。その後、移動量の平均値および標準偏差を計算させて時系列対応のアルゴリズムに変換し、最終的に移動 z-score に完成させます。

最初に必要な作業は、Python を使用して Apache Spark クラスターとやりとりする Python ノートブックを作成することです。Python の知識があまりないとしても心配しないでださい。Cloudant Apache CouchDB NoSQL 内に保管されているデータに対してクエリーを実行するには、Apache Spark SQL を使うので、主に使用するのは SQL です。

  1. datascience.ibm.com にログインします。
  2. ウィンドウの右上にあるプラス (+) 記号をクリックします。
    プラス記号が表示された Data Science Experience 内のメニューのスクリーン・キャプチャー
    プラス記号が表示された Data Science Experience 内のメニューのスクリーン・キャプチャー
  3. 表示されるメニューから、「Create notebook (ノートブックを作成」)」を選択します (注: 作成済みのデフォルト・プロジェクトが用意されています)。
  4. From URL (URL から)」タブをクリックします。
  5. Name (名前)」フィールドに Cognitive IoT と入力します。
  6. Notebook URL (ノートブックの URL)」フィールドに以下の URL を入力します。
    https://raw.githubusercontent.com/romeokienzler/developerWorks/master/CognitiveIoT/CognitiveIoT.ipynb
  7. 残りのデフォルト値はそのままにして、「Create Notebook (ノートブックを作成)」をクリックします。
    Data Science Experience 内の「Create Notebook (ノートブックの作成)」ページのスクリーン・キャプチャー
    Data Science Experience 内の「Create Notebook (ノートブックの作成)」ページのスクリーン・キャプチャー
  8. ノートブック内に、ステップ 1 でメモした Cloudant サービスの名前に関連付けられたホスト名、ユーザー、パスワードを指定します。
    Data Science Experience 内のノートブックのスクリーン・キャプチャー。ここに、データベース資格情報を入力します。
    Data Science Experience 内のノートブックのスクリーン・キャプチャー。ここに、データベース資格情報を入力します。
  9. 最初のテキスト域をクリックし、「Run (実行)」ボタン (音楽の再生ボタンのように見えるツールバー・ボタン) をクリックします。データ・セットに含まれる最初の 20 行が表示されるはずです。
    データ・セットに含まれる最初の 20 行が表示されたノートブックのスクリーン・キャプチャー
    データ・セットに含まれる最初の 20 行が表示されたノートブックのスクリーン・キャプチャー
  10. ノートブック内の手順に従って、このステップの残りの部分を完了します。
5

検出された異常をリアルタイム・データ処理コンポーネントに転送する

バッチ環境から取得したモデルをリアルタイム・データ処理コンポーネントに転送するには、いくつもの方法があります。そのうち最も簡単なのは HTTP 呼び出しを使用することなので、これから、この方法を実装します。エッジ上のモデルを更新するためには、クラウド内で稼働する RTL コンポーネントを使用します。Node-RED フロー内には HTTP エンドポイントを作成する必要があります。その上で、MQTT を使ってメッセージをエッジ・ゲートウェイに渡します。

  1. Bluemix 内で「View app (アプリケーションを表示)」をクリックします。
    Bluemix アプリと「View app (アプリケーションを表示)」ボタンのスクリーン・キャプチャー
    Bluemix アプリと「View app (アプリケーションを表示)」ボタンのスクリーン・キャプチャー
  2. Go to your Node-RED flow editor (Node-RED フロー・エディターを表示)」をクリックします。
  3. クラウド内で稼働する ETL コンポーネントを表す「Flow 2 (フロー 2)」をクリックします。
  4. 左側のパレットの「input (入力)」セクションから「http」を選択し、この入力ノードを「Flow 2 (フロー 2)」のキャンバスにドラッグします。
    「http」入力ノードが追加されたフローを示す画面のスクリーン・キャプチャー
    「http」入力ノードが追加されたフローを示す画面のスクリーン・キャプチャー
  5. すべてのリクエストにはレスポンスが必要なので、「http」入力ノードに「http」レスポンス・ノードを接続します。
    2 番目の「http」ノードが追加されたフローを示す画面のスクリーン・キャプチャー
    2 番目の「http」ノードが追加されたフローを示す画面のスクリーン・キャプチャー
  6. 「http」入力ノードをダブルクリックして、「URL」フィールドに /edgemodelupdate と入力してから「Done (完了)」をクリックします。
    「http」ノードの構成ダイアログのスクリーン・キャプチャー
    「http」ノードの構成ダイアログのスクリーン・キャプチャー
  7. パレットの「output (出力)」セクションで「IBM IoT」をクリックし、このノードをキャンバスにドラッグします。また、「http」ノードを「IBM IoT」ノードに接続します。
    「IBM IoT」ノードが追加されたフローを示す画面のスクリーン・キャプチャー
    「IBM IoT」ノードが追加されたフローを示す画面のスクリーン・キャプチャー
  8. IBM IoT」ノードをダブルクリックして、以下の手順に従います。
    1. Authentication (認証)」として「Bluemix Service (Bluemix サービス)」を選択します。この項目を選択すると、MQTT メッセージ・ブローカーの資格情報が IBM クラウド (Cloud Foundry サービス・ブローカー) から自動的に取り込まれるようになります。
    2. Output Type (出力タイプ)」として「Device Command (デバイス・コマンド)」を選択します。アプリケーションからデバイスまたはゲートウェイにメッセージを送信する場合は、デバイス・コマンドを出力タイプとして選択する必要があります。
    3. Device ID (デバイス ID)」には Washing01 と入力します。このシステムではパブリッシュ/サブスクライブ・メッセージ配信モデルを使用するので、MQTT から直接受信側デバイスをアドレス指定できます。
    4. Command Type (コマンド・タイプ)」には modelupdate と入力します。パブリッシュ/サブスクライブを使用することから、コマンド・タイプを定義して、デバイスが関連する特定のメッセージにサブスクライブできるようにします。
    5. Format (フォーマット)」には json と入力します。Node-RED におけるデータ配信の中心的手段は JSON をベースとしています。
    6. Data (データ)」プロパティーには payload と入力します。HTTP によってアップストリームから送られるメッセージのペイロードにアクセスするためです。
      「ibmiot」ノードの構成ダイアログを示すスクリーン・キャプチャー
      「ibmiot」ノードの構成ダイアログを示すスクリーン・キャプチャー
    7. Done (完了)」をクリックします。
  9. Deploy (デプロイ)」をクリックします。

これで、HTTP を使用してアナリティクス・ワークフローからメッセージを送信し、クラウド内の Node-RED を HTTP と MQTT の間のプロキシーとして使用して、エッジ・ゲートウェイでメッセージを受信できるようになりました。Watson IoT Platform を使用する利点として、エッジ・ゲートウェイに直接到達する方法を心配する必要はありません (多くの場合、エッジ・ゲートウェイに直接到達するのは不可能です)。それは、すべてのデバイスは MQTT メッセージ・ブローカーに接続され、それぞれのデバイスに関連するメッセージにゲートウェイがサブスクライブされるからです。このような構成であれば、必要なメッセージをメッセージ・バス経由でエッジ・ゲートウェイに確実に届けることができます。

6

エッジ・ゲートウェイ上でフローを実装する

エッジ・ゲートウェイ側にフローを実装するには、デバイスに必要なメッセージに対してエッジ・ゲートウェイをサブスクライブし、しきい値が更新されるとエッジ・ゲートウェイが反応するようにします。例えば、マシン上の電流が異常な場合、モーターを停止することでマシンを保護できます。これから、この動作を実装しましょう。

  1. エッジ・ゲートウェイを表すのは「Flow 1 (フロー 1)」なので、このフローをクリックします。
  2. パレットからキャンバスに「IBM IoT」入力ノードをドラッグします。
    キャンバス領域に追加された「IBM IoT」入力ノードを示す図
    キャンバス領域に追加された「IBM IoT」入力ノードを示す図
  3. 「IBM IoT」ノードをダブルクリックして、以下の詳細を入力します。
    1. Authentication (認証)」として「Bluemix Service (Bluemix サービス)」を選択します。
    2. Input Type (入力タイプ)」として「Device Command (デバイス・コマンド)」を選択します。これは、MQTT によってクラウドからエッジ・ゲートウェイにコマンドを送信するためです。
    3. Device Type (デバイス・タイプ)」、「Device ID (デバイス ID)」、「Command (コマンド)」、および「Format (フォーマット)」には、「All (すべて)」を選択します。
      単純にするために MQTT メッセージ・バス上のすべてのコマンドにサブスクライブしますが、実際のシナリオでは、関連性のあるコマンドだけにサブスクライブして反応することになるはずです。
      「ibmiot in」ノードの構成ダイアログのスクリーン・キャプチャー
      「ibmiot in」ノードの構成ダイアログのスクリーン・キャプチャー
    4. Done (完了)」をクリックします。
  4. パレットの「output (出力)」セクションにある「debug (デバッグ)」ノードをキャンバスにドラッグし、「IBM IoT」ノードに接続します。
    「IBM IoT」ノードに接続された「debug (デバッグ)」ノードを示す画面のスクリーン・キャプチャー
    「IBM IoT」ノードに接続された「debug (デバッグ)」ノードを示す画面のスクリーン・キャプチャー
  5. Deploy (デプロイ)」をクリックします。
7

HTTP エンドポイントをテストする

HTTP エンドポイントの作成が完了したので、このエンドポイントをテストする必要があります。

  1. Bluemix 内で、アプリケーションの URL をコピーして「red/#」の部分を「edgemodelupdate」で置き換えます。私の例では、HTTP エンドポイントの URL は次のようになります。
    https://1234thisismyname.mybluemix.net/edgemodelupdate
  2. 使用しているのは HTTP GET エンドポイントであるため、ブラウザーで (新しいタブを開いて) リクエストを送信するには、以下のように URL の末尾にパラメーターを追加できます。
    https://1234thisismyname.mybluemix.net/edgemodelupdate?command=emergencyshutdown
  3. Node-RED フロー・エディターのデバッグ・パネルに、以下のスクリーン・キャプチャーに示されているようなメッセージが表示されることを確認します。
    デバッグ・パネルが開いた状態のフローを示す画面のスクリーン・キャプチャー
    デバッグ・パネルが開いた状態のフローを示す画面のスクリーン・キャプチャー

ここではエッジ・ゲートウェイをシミュレーションしているので、実際のアクターは配備されていません。けれども実際のシナリオでは、エッジ・ゲートウェイがメッセージに反応して洗濯機のモーターが停止されることになります。

まとめ

このチュートリアルではコグニティブ IoT パイプラインの全体像として、分散型の検出から、中央での効果的な意思決定、さらにエッジ上で即時に反応する仕組みまでを説明しました。この全体像に欠けている要素はあと 2 つだけです。それは、コグニティブ API (TTS、STT、または資格認識) の適用と、エッジ上でのアナリティクスです。

詳細を学びたい場合は、私が作成した Coursera コース「A developer's guide to Exploring and Visualizing IoT Data」に参加してください。このコースで、Apache Spark を使用して IoT データ・アナリティクスを開始できるようお手伝いします。

また、私が取り組んでいる開発に関する最新情報を入手するには、私の YouTube チャネルにサブスクライブしてください。

締めくくりの演習

このチュートリアルの締めくくりとして、任意で取り組める演習を用意しました。この演習で、1 つの単純な Node-RED 関数を使用して z-score の計算をエッジで処理する方法を説明します。

z-score の計算はセンサーに可能な限り近い場所で行う必要があります。さらに、クラウドを介した完全なループを省略するために、エッジ・ゲートウェイ上の Node-RED インスタンスに直接実装する必要もあります。z-score の計算を Node-RED 内で JavaScript 関数を使用して行うには、以下のいずれかの方法を選択できます。

  • このセクションに記載するコードに従って、Node-RED フロー内にノードを実装します。
  • CognitiveIoT GitHub リポジトリー内にある edge_zscore.json ファイルから関数全体をクリップボードにコピーし、インポート機能を使って Node-RED フローのキャンバスに貼り付けます。

処理内容を理解するために、以下のソース・コードを見ていきましょう。

最初に、voltage パラメーターを使用して電流の最後の n 個の値を保管するリストを初期化します。ストリーム・コンピューティングでは、このリストは「固定長のスライディング・ウィンドウ (sliding window of fixed size)」と呼ばれています。

var aggwindow = context.get('aggwindow')||[];

初期化した後、このリストに値を追加します。具体的には、この関数ノードに到着したメッセージごとに 1 つの値を追加します。

aggwindow.push(msg.payload.d.voltage);

値が 30 個になるまで (基本的に、この条件がスライディング・ウィンドウのサイズを定義します)、リストに値を追加し続けます。

if (aggwindow.length> 30) {

z-score を計算するには、平均値と標準偏差が必要です。常に賢明な方法となるのは、集約の範囲とするウィンドウ内にあるすべての要素の合計を算出することです。

sum = aggwindow.reduce((a,b)=>a+b,0);

合計に加え、要素の数も必要なので、要素をカウントしましょう (注: 必ず 31 になるはずですが、わかってはいないですよね)。

n = aggwindow.length;

値の合計と要素の数がわかれば、平均値を計算するのは簡単です。

mean = sum/n;

平均値がわかれば、標準偏差を計算できます。

sd = Math.sqrt(aggwindow.map(x=>Math.pow(mean-x,2)).reduce((a,b)=>a+b,0));

続いて LIFO と同じように、リスト内の最も古い要素を削除する必要があります。

aggwindow.shift();

これで z-score の式に平均値と標準偏差の値を追加すれば、完了です (注: 標準偏差はゼロ (数学的には未定義) になる可能性があるため、標準偏差にごく小さい値を追加しています)。

msg.zscore = (mean-msg.payload.d.voltage)/(sd+0.0001)
}

最後に、このリストをグローバル・コンテキストに保管することで、個々のメッセージの有効期間全体にわたってリストを維持します。

context.set('aggwindow',aggwindow);

デバッグの目的で、実際の電流 (または電圧) と z-score を同時に追跡します (それでも、アラートを起動する必要がある場合は、msg.zscore で個々の z-score にアクセスできます)。

msg.payload=msg.payload.d.voltage+":"+msg.zscore;
return msg;

アラートを起動するようにして、この関数を完成させましょう。それには、最後の JavaScript 関数をフローに追加します。電流の値が非常に高くなったり低くなったりすると、モーターに損傷を与える可能性があるため、電流の変動が異常に大きい場合は、このアラートがトリガーされます。したがって、異常に高いスコアを認識するまではすべてのメッセージを無視し、異常に高いスコアを認識した場合にのみ、アラートを起動して反応します。

現時点で、Node-RED フローは以下の図に示すようなフローになっているはずです。

if (Math.abs(msg.zscore)>0.5) {
    msg.payload="ALERT ALERT ALERT!!!!!";
    return msg;
zscore 関数を追加した後の最終的な Node-RED フローを示す画面のスクリーン・キャプチャー
zscore 関数を追加した後の最終的な Node-RED フローを示す画面のスクリーン・キャプチャー

ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1048433
ArticleTitle=たった 7 つのステップでコグニティブ IoT アプリを構築する
publish-date=08102017