世の中いろいろな「IoT」がありますが、突き詰めればデバイスから上がってくるデータを処理して何かを実現するのがIoTです。IoTにおけるデータ処理を考える上で、ネットワークプロトコルの設計指針を参考にするとうまく整理できます。
シンタックス、セマンティクス、そしてコンテキスト
ネットワークプロトコルを設計するときにはシンタックス（Syntax; 文法）とセマンティクス（Semantics; 意味）に分けて考えます。そしてネットワークプロトコルの外側にあるコンテキスト（Context; 文脈）に基づいて処理が行われます。
それぞれ掘り下げていきます。
シンタックス：どのようにデータをやりとりするか
どのようにデータを送り、受け取るかという「文法」を決めるのがシンタックスです。
たとえばHTTPであれば、HTTPクライアントがHTTPサーバにTCPで接続し、以下のフォーマットでリクエストを送り、
[HTTPメソッド](空白)[URI](空白)[プロトコルバージョン]
(いくつかのヘッダ)
(空行)
(もしあればメッセージ本体)
HTTPサーバから以下のようなレスポンスが返ってくる、というのがシンタックスに相当します。
[プロトコルバージョン](空白)[ステータスコード](空白)[テキスト]
[いくつかのヘッダ]
(空行)
(もしあればペイロード本体)
ステータスコードは3桁の整数であるまでは決めますが、どの数字がどんな意味を持つか、例えば404が「URIが存在しない」を表すなどはシンタックスでは決めません。
これをIoTの分野で考えてみます。
Case 1: MQTT
MQTTでセンサーのデータを集める場合を考えてみます。
性能やコストをそこまで詰める必要が無い場合、後々の拡張性などを考えてメッセージに直接値を埋め込むのでは無く、JSONなどの汎用フォーマットに入れて送ることが多いかと思います。また、デバイスのIDをトピック名に入れて識別できるようにします。
そうすると、このようなシンタックスが考えられます。
- トピック名は「sensors/{デバイスのID}」
- ペイロードはJSON形式で符号化
シンタックスの段階ではどのようなセンサーがありどんな値を含めるかなどは決めず、セマンティクスに任せます。
JSONオブジェクトに含まれるキーや値の型までをシンタックスとみなす場合もありますが、この記事ではもう少し緩いところまでをシンタックスとみなしています。あくまでシンタックスかセマンティクスかは分類方法でしかないので、視線の先をどこに置くかでその境目は変わってきます。
Case 2: LoRaWAN
LPWAで代表的なLoRaWANでは、一番小さな設定ではメッセージサイズが11バイトになります。11バイトに集めたいデータを全て詰め込む必要があるため、1ビットは血の一滴と無駄にすることができません。
たとえばGPSトラッカーからデータを集めたい時に、以下のようなシンタックスが考えられます（この例はソラコムさんの記事をもとにしました）。
- 先頭1バイトはヘッダ
- ヘッダの上位2bitはステータス（0～3）
- ヘッダの下位6bitはバッテリー（0～100を1bit右シフトして符号化）
- 次の4バイトは緯度
- 次の4バイトは経度
- 次の2バイトは高度
- 緯度経度海抜は浮動小数点数とし、ビッグエンディアンで符号化
MQTTの例と同様に、ステータスの意味はセマンティクスの範疇となります。
このように、データの形を決めるのがシンタックスです。たとえばSORACOM Beamやバイナリパーサーはシンタックスの変換と考えることができます。
セマンティクス：データをどのように扱うか
受け取れるデータの形を決めるのがシンタックスなら、受け取ったデータの意味を決めるのがセマンティクスです。
先ほどのHTTPならば、受け取った3桁の数値が「404」ならば指定したURIにデータが存在しない、「301」ならばレスポンスのヘッダ「Location」で示されたURIに移動してしまった、というようなことを決めます。また、どのようなリクエストメソッドがあるのかもセマンティクスに相当します。
先ほどのIoTの例でセマンティクスを考えてみます。
Case 1: MQTT
実際のセンサーデータはJSON形式で符号化することがシンタックスで決まっていますが、その中身はセマンティクスに委ねられました。
今回使うセンサーでは、温度と湿度が取得できるので、temperatureとhumidityのキーでそれぞれのセンサーで取得した値を入れる事にします。温度は摂氏、湿度は100分率で表現します。このように数字の意味を細かく決めていきます。
Case 2: LoRaWAN
ステータスは、以下のような値を出すこととします。
- 0: GPS位置情報の取得ができなかった
（後に続く緯度経度高度のデータは正しくない） - 1: GPS位置情報の取得に成功した
- 2: 未定義
- 3: 故障している
バッテリーはフル充電時の最大電圧と、停止直前の最小電圧の間を100分率で表します。
緯度経度高度は、GPSで使われるWGS 84測地系で表現された値を利用します。緯度経度はともかく、高度はWGS 84測地系では地球をきれいな楕円体とみなしたときの表面からの高さになるので、実際の標高である平均海水面との差を計算したりするなどは、データを受け取った側の責任になります。
このように決めていくことで、ようやくセンサーで集めた情報が、正確にその意味をくみ取って利用できるようになります。それぞれの「値」に対してそれをどのような意味を持っているのかを細かく決めていくのがセマンティクスの役割です。
コンテキスト：文脈の上でデータの価値を見いだす
ここまでで、IoTデバイスから上がってきたデータをしっかり解釈することができましたが、それを具体的に役に立つようにするにはもう一手間必要です。それがコンテキスト（文脈）による価値付けです。
コンテキストも、細かく分けると2種類があります。
データの履歴と状態遷移
例えば温度センサーで30度という値を受け取ったとします。温度に応じて冷房のon/offを制御したいとき、たとえば部屋の温度が29度から30度に上がったときには冷房の電源を入れ、27度まで下がったときに冷房を止めて欲しいわけです。また、センサーからの値には誤差が含まれるため、移動平均なども計算したいです。
これを実現するには最新の温度データだけがあっても駄目で、過去のデータや冷房の状態があったうえで新しいデータを使って判断する必要があります。
このようにデータの履歴や状態をつかった処理を行うため、データを収集した側で様々な道具を使う必要があります。たとえばAWS IoT Eventsなんかはそのためのエンジンですし、Azure FunctionsやAWS LambdaなどのFaaSを使って自分で実装することもできます。
外部のデータ
GPSで測位した位置情報が分かったとして、その座標を使って何かを行うためには、たとえば登校前後に親御さんにメールする「みまもりサービス」であれば自宅と学校の座標など、そもそも他のデータと組み合わせる必要があります。
先ほどの冷房on/offであれば、そのセンサーの所有者が設定した目標温度も必要になります。
いわゆるETLの範疇にもなりますが、リアルタイムデータを別のマスタデータとJOINするようなケースでは、Azure Stream AnalyticsやAmazon Kinesis Data AnalyticsなどでリファレンスデータとJOINしたりできます。
データ量によってはリアルタイムで処理することにこだわらず、RDBMS等に放り込んで閲覧時やバッチでJOINしても良いでしょう。
このように、IoTデバイスからのデータは、ただそこに存在するだけでは価値が発揮できず、過去のデータ・状態や外部のデータと紐付けることでようやく様々な役に立つことができます。逆に言えば、この領域で何をやるかこそが「IoTを活用する」ということそのものと言えます。
まとめ
IoTにおけるデータ処理は全体をふわっと見ると複雑ですが、データの表現方法を決めるシンタックス、その意味を細かく決めるセマンティクス、そこから価値を見いだすコンテキストに分けて整理すると分かりやすいです。
