toru-murasawaの日記

IoT,Startup,Technology etc

IoTプラットフォームの本質とは

前回、日記のつもりで書いた記事がバズってしまい困惑すると同時に嬉しかったりするのだがあくまで日記なので書きたい事を書いていきたい。

さて、「IoTプラットフォーム」であるが完全にバズワードというか大企業もベンチャーも同じ名前で出しているので一体、A社とB社のプラットフォームで何が違うのか?という企業関係者も多いのではないだろうか。

当社も「IoTメッセージブローカ」のPaaSサービスを運営する事業者として、「IoTプラットフォーム」の本質とは何かを考えてみた。

(ここでいう「IoTプラットフォーム」とはハードウェアエコシステムではなくクラウドプラットフォームを指す)

 

1.モノとのメッセージの交換

バイスクラウドを双方向通信させる仕組み一式の提供をする。メッセージとは温度データであったりモータの停止命令であったり様々だ。一般的にはMQTTというプロトコルが使われる事が多い。ここの出来が悪いとデバイスが増えてきた時に接続が切れたり、処理が間に合わないなど完全にIoTというよりは通信インフラの領域である。選定の際にはただ使えるのかだけでなく、安定性や性能的な要素も重要視すべき箇所である。

 

2.モノの認証

あちこちの現場に散在するデバイスに対して認証の仕組みが無いとセキュリティ的に問題である。そのためトークンと言われるユーザ名とパスワードを1つにまとめた認証文字や証明書をデバイスに埋め込んでクラウド接続の際に認証させる仕組みを提供する必要がある。

 

3.モノの管理

どこの現場のデバイスから何のデータが来たか識別するのにはデバイスの個体管理をする必要がある。名札に相当するのがデバイスIDであり、機器固有のMACアドレスだろうが東京工場1フロアAだろうが識別できれば何でも良い。

 

4.モノが生成するデータの蓄積

バイスにぶら下がるセンサなどの末端ノードの情報をクラウド内に貯める仕組みを提供する。センサによって、出力するデータ数とフォーマットが違うのでNoSQLと言われる闇鍋的なデータの突っ込み方が出来るデータベースが使われる事が多い。いちいち、センサの変更や追加で電文仕様を決めているほど現場は暇ではない。

 

5.外部との連携

ここでいう外部システムとは大抵、ユーザが利用するWebアプリの場合が多い。REST APIという標準的な仕組みを用いて、プラットフォームのデータを取り出し必要によって加工の上あとはユーザ要件によってグラフなりデジタル数値として表示する。

 

以上、5つの基本的な役割が「IoTプラットフォーム」の本質部分である。あとはデータに閾値をつけて通知する機能やウェジェットビルダーなるグラフや数値を見栄え良くピコピコさせる機能があるが、この辺りが差別化要素になる事が多い。

 

まとめ

IoT案件を担当する関係者の方は、上記ポイントさえ押さえておけばプラットフォームベンダの思惑と自社で実現したい事のフィット&ギャップが明確になるだろう。

上記に対する質問に答えられないベンダの場合は、プラットフォームを売り切りたいだけの可能性が高いのでポテンシャルを見極める意味でもユーザ自身がやりたい事を整理しておく事は大切である。