IoTの約束を実現する技術

20年以上前、インターネットが一般で利用できるようになったとき、あらゆる種類の新たなビジネスや働き方が可能となりました。 このことにより、実店舗を構える「ブリックアンドモルタル」のビジネス形態をそのまま継続していくことは難しくなりました。 モノのインターネット（IoT）は、形ある資産をオンラインでつなぐことによってこの動きをさらに進めることになります。 こうした動きは、素材としての「ブリックアンドモルタル」、すなわち店舗そのものにも影響を及ぼすことがあります。というのも、店舗には店舗の状態を監視するためのセンサが組み込まれているからです。

IoTは、物理的な世界に広まった計算知能を使うことにより、従来のビジネスモデルをもう一度見直す機会を与えてくれます。 企業は、消費者が本当に必要なものは何か、そしてそれをサポートするために何ができるのかを問うことができます。 こうした変化は、航空機向けジェットエンジンにおいてすでに見られます。 主要なサプライヤは、IoTモデルをいち早く導入しました。サプライヤは、通信ネットワークを単に製品のサポートに用いるだけでなく、航空会社の製品購買にも活用しています。

このモデルは、航空運送の収益を高める上で最も重要な部分に焦点を当てることで、航空会社とジェットエンジンメーカのインセンティブを調整します。つまり、航空機が地上で休止する時間を減らし、航路の数を最大化します。 エンジンのセンサはリアルタイムで更新され、航空機が地上の空港ゲートにあるときに取得されたより詳細な状態データと組み合わされます。 そこで得られた情報はエンジンメーカにエンジン最新状態を可視的に提供し、メーカは飛行計画から最も合理的なタイミングでエンジンを取り外してメンテナンスを行うようスケジュールを立てることができるようになります。

ジェットエンジンのビジネスモデル自体は、航空機が可能な限り飛行できるよう、エンジンメーカにインセンティブを与えるように設計されています。そして航空会社は、エンジンを購入するというよりも実質的に航空機を飛行させ続ける能力をリースしているといえます。 センサと世界的規模の通信網は、エンジンメーカにビジネスモデルを実現できる能力を与えています。

同じ原則は、他の多くの市場にも拡げられます。 たとえば、自動車メーカは伝統的な製品ベンダから、信頼できる輸送手段の提供者に変わることができます。 自動車バリューチェーンの他のサプライヤも役目を果たせます。 メーカはタイヤを運転者に不定期的に販売する代わりに、センサの活用により強化したリースモデルを採用できます。すでにタイヤにセンサを取り付けているメーカもあります。

図1：NXP SemiconductorのFXTH87ファミリ、タイヤ空気圧監視センサを使用したシステムの応用例（出典：NXP）。

タイヤ空気圧監視システムを運転データと共にIoTに紐付けることにより、クラウド内のアプリケーションは、サービスステーションに停止して空気を入れ、運転データが高い使用度を示している場合にはトレッドの深さやタイヤの状態を確認するよう、最適な時間や場所を運転者に通知できます。 運転者は年ごとの保守を待たずに、摩耗がタイヤ交換の必要が生じる段階に近づくと、都合の良いときにタイヤ交換ができる場所に行けるのです。 このアプローチは消費者に大きな価値をもたらすとともに、タイヤメーカーも収益の流れをより確実に予測できるようになります。

保険分野では、より劇的な変化が起こるかもしれません。 保険業者は、単に保険統計的な情報を用いてリスクを推定し方針を定めるのではなく、リスクと全体のコストを削減するためにより積極的な役割を果たし、保険業者と消費者の双方により大きな価値をもたらすことができます。 例えば、住宅保険における最大のコストの1つは、配管の破裂で建物が浸水した後に清掃を行い、物品を交換することにあります。 配管の破裂に対応する時間が長いほど、コストは高くなります。 そのため、建物が無人である場合、高い清掃費用がかかる結果を招く場合があります。

家庭のセンサが、水浸しを起こす兆しを検知すれば、自動制御された弁が元栓で水を遮断することにより、損害の可能性を大幅に減らせます。 センサは他のさまざまな問題も検出できるので、保険会社は、費用がかかる前に問題に対処できるサービスを提供できます。 こうすることにより、保険会社の役割は保証の提供に変わります。

企業がIoTを最大限に活用できるようにする技術は数多く存在しています。 上記の例が示すように、センサと通信という2つの技術は決定的に重要です。 ただし、システム全体を成り立たせるためのインフラストラクチャを忘れてはなりません。

既存のほとんどのIoTに類するアプリケーションでは、通信インフラストラクチャの役割はイントラネットの役割に似ています。 センサはメーカによって配備され、ネットワークも同様にメーカによって管理されることがよくあります。ただし、メーカはセルラーなど既存の通信インフラストラクチャにある容量を借りることもあります。 IoTは、複数のプロバイダのデータとネットワークを利用して1つのアプリケーションを作成できるようにすることで、最大限の価値を提供できます。

例えば、水を検知するセンサを所有者が設置し、自動制御された弁を水道会社が設置するといった具合にです。 これらを調整するための鍵は、保険会社によって開発されたソフトウェアであり、さまざまな場所で実行できます。 センサが読み取る水の値が水浸しを示すかどうかを決定するコアアルゴリズムは、多くの場合、クラウド内のサーバで実行されます。 これらのサーバは、供給者が直接所有することも、Amazon Web ServicesやMicrosoftのAzureサービスなど、プロバイダからリースすることもできます。

リアルタイム応答を保証するために、センサおよびアクチュエータにより近いIoTゲートウェイで動作するアプリケーションもあります。 このゲートウェイは、コンピューティングアーキテクチャのうち、IoTから最大の価値を引き出すために最も大きく変更すべきものの1つです。

IoTゲートウェイは、家庭、オフィス、または産業用セル内のルータとある意味で同じ機能を実行します。 IoTゲートウェイは複数のセンサノードからデータを収集し、コマンドをアクチュエータにリレーし、クラウドに情報を送信します。 ゲートウェイとさまざまなIoTノードとの間の接続は、「フォグ」レイヤの一部を形成し、より広いインターネット上のクラウドへの接続と区別されます。

ゲートウェイ設計の方向性として可能性が高いものの1つは、ゲートウェイをIoTアプリケーションのホストにするというものです。 ハイパーバイザをベースとした仮想化アーキテクチャにより、さまざまなサービスプロバイダや装置ベンダによるダウンロード可能なアプリケーションから、コアルーティングとネットワーク管理機能を分離することが可能になります。 Prplグループはアーキテクチャを実証し、それをサポートできるハイパーバイザを開発して、オープンソースの形式で提供しています。 これにより、メーカはIoTゲートウェイのコア機能を容易に実装でき、またアプリケーション作成者はその上で動作するソフトウェアを容易に作成できるようになります。

フォグネットワークにおいて、インテグレータと開発者は、範囲、データレート、その他の機能が非常に異なる、多くの選択肢に直面しています。 IoTには非常に多くの側面があり、すべての場合に当てはめることができるソリューションなどありません。

発生期にあるスマート農業の分野においてさえ、その多様性を考慮する必要があります。 比較的狭い更地で行われるスマート農業では、作物は温室で栽培されます。 温室環境においては植物の灌漑は比較的容易に制御できますが、この形式の農業では、密閉された環境により病気が急速に広がる傾向があります。

伝統的な、土地をベースとする農業には、これとは別のさまざまな課題があります。 病気や害虫の蔓延も問題ですが、水を無駄にせず効率的に作物を成長させる鍵は、灌漑の影響を土壌面で監視することです。 土壌自体の水分レベルを監視することにより、センサはアプリケーションに情報を送信して、アプリケーションは灌漑の方向を高度に制御できます。 水分レベルが田畑の特定箇所で著しく低下した場合にのみ、灌漑を行うのです。 過剰な灌漑を防ぐため、田畑の他の箇所には水を供給しません。 このような技術は、近年干ばつに見舞われたカリフォルニアなどの乾燥した地域においてすでに採用されています。

温室環境では、土壌データも重要かもしれませんが、 水の保全はそれほど重要ではありません。というのも、水はリサイクルできるからです。 その代わり、水流の速度を監視して栄養分を効率的に分配し続けるために、異なる種類のセンサを用いて水耕栽培の手段を利用できます。 疾病を監視するために、無人航空機（UAV）を利用して農作物を検査し、緊急の治療や除去が必要なものを識別して、残りの作物への感染を防ぐことができます。

上記2つの農業形態において、通信に求められる要件は、かなり異なっているかもしれません。 高帯域通信は、温室環境においてより重要となります。クラウドまたはゲートウェイベースのアプリケーションを使えば、疾病の兆しをより認識できるようなります。 ただし、特定の場所に集中する環境では、BluetoothやWi-Fiなどの短距離、高帯域幅のプロトコルを利用できるのですが、 伝統的な農業における野外環境においては、範囲の限定されるフォグネットワークはあまり適していません。しかしLoRaWanやセルラーなどを配置するといった選択肢があります。

Bluetoothは主に携帯電話と通信するデバイスのためのパーソナルエリアネットワークとして開発されましたが、Bluetoothのアプリケーション空間は一連のプロトコル拡張により劇的に拡大してきており、その傾向は続いています。 Bluetooth Special Interest Group（SIG）によって開発されている変更の1つは、100メートルという通常の送信範囲を4倍にまで拡大することです。 範囲の拡大によりビットレートは低下しますが、プロトコルは適応性があり、ノードが近いほどより高い送信速度が利用できます。 この変更の結果、密接に配置したデバイスでは、データレートが2Mビット/秒に増加する予定です。

もう1つの変化は、メッシュネットワークがサポートされるということで、これによりBluetoothは6LowPANやZigbeeなどの他のIoT指向のネットワークとこの点において肩を並べることになります。 6LowPANとZigbeeがベースとする無線通信用のIEEE 802.15.4仕様は、メッシュネットワークをサポートするように設計されています。メッシュネットワークは、こうしたフォグネットワークプロトコルの有効範囲と弾力性を拡張するために利用できます。

メッシュネットワークにおいては、短距離通信を用いてパケットの長距離を移動が可能になります。 パケットの長距離移動は、パケットが送信元と宛先との間にあるノード間で短いホップを利用できるようにすることによって達成できます。 メッシュ技術は弾力性を向上させます。なぜなら、1つのノードに障害が発生した場合でも、たいてい別のノードがデータ中継に使用できるからです。 メッシュ技術により、アクセスが困難な場所（温室の屋根など）に、IoTゲートウェイノードの直接的な範囲外にある場合でもセンサを配置できるようになります。

Bluetoothの改訂は、IoTの多様性も考慮に入れています。プロトコルをサポートするセンサノードは、6LowPANデバイスと相互に通信可能です。 6LowPANが導入されたのは、Zigbeeよりも最近の話ですが、Threadプロトコルグループがこれを採用したことにより、6LowPANはIoT設備においてより普及が進むでしょう。 Threadは、6LowPANに認証や暗号化などの機能を追加して、全体的なセキュリティを向上させます。

6LowPANなどのプロトコルは、BluetoothとWi-Fiが採用する2.4GHz帯だけでなく、免許不要な868MHzなどのサブギガヘルツ帯でも動作します。 この低い周波数範囲においては、狭帯域送信が用いられるため、サポートするビットレートは比較的低くなります。 ただし、送信範囲の増大は、電力消費にそれほど影響を与えない傾向があります。 結果として、サブギガヘルツでの動作は、メッシュネットワークにはあまり適していないものの、長距離伝送が必要な場合において、ワイヤレスセンサノードを配置する場合に適しています。 こうした例の1つとしては、道路に沿ってセンサが配置され、さらにクラウドとメッセージをやりとりするために一定間隔でゲートウェイが配置されるといったものがあります。

LoRaWanやSIGFOXのようなプロトコルに移行すると、1つのゲートウェイが郊外に散在する1キロメートル以上の範囲の多数のセンサと連絡を取り合うことができます。

図2：Semtech SX1272/73 - 860MHz～1020MHzの低電力長距離トランシーバ - ブロック図

LoRaWanプロトコルはSemtechによって開発されました、SemtechはMicrotech TechnologyやSTMicroelectronicsと共に、互換性のあるトランシーバを供給しています。 シリコンの入手のしやすさにより、IoTアプリケーション開発者やインテグレータは、適切なフォグネットワークの性質を選択できます。 開発者やインテグレータは、独自のゲートウェイハードウェアを配備するか、パブリックネットワークを利用することができます。つまりパブリックとプライベートの両方を選択できます。 商用のLoRaWanネットワークも現在配備中ですが、ボランティアも無料サービスを展開しています。 1つの例は、オランダのアムステルダムです。The Things Network組織のメンバーが配備したわずか11のゲートウェイによって、アムステルダムのほぼ全体がカバーされています。

868MHz通信および類似の帯域用に開発されたほとんどのトランシーバは、SIGFOXプロトコルを使用できます。 このプロトコルは主に、プロトコルを開発した企業によってインストールされたゲートウェイノードへの単一方向、低データレート通信を目的としています。

長距離通信のもう1つの選択肢は、3Gおよび4Gセルラーの利用です。 3GPP標準化グループは、IoTアプリケーション用の4G LTEプロトコルのバージョンを既に開発済みで、現在は複雑さを少なくし、消費電力を下げるための別のプロジェクト、すなわちナローバンドIoTに取り組んでいます。

通信インフラストラクチャの発展の結果として、IoTデバイスは、フォグやクラウドに複数の方法で接続できるようになるでしょう。 重要となるのは、これらの異なるシステムを連携させることであり、これにはソフトウェアとデータの標準化が鍵となります。

Constrained Applications Protocol（CoAP）などのプロトコルは、HyperText Transfer Protocol（HTTP）などのインターネット標準の利点をフォグネットワークを通じてセンサノードにまで拡張できるようにするものです。 CoAPは、メモリと処理リソースに制約のあるマイクロコントローラに適した形式でHTTPへのアクセスを提供します。 CoAPは、Webベースのアプリケーション開発の標準となっているREpresentational State Transfer（REST）プログラミングモデルと同じものをサポートしています。 ただし、テキスト形式ではなく、従来のHTTPよりも小型となるバイナリ形式を採用しており、低データレート接続に適しています。

図3：MQTT QoS（Quality of Service）機能（出典：MQTT - モノのインターネットのための実用的なプロトコル：IBM MessageSight Solutions）

他のプロトコル、たとえばMQ Telemetry Transport（MQTT）などは、代替アプリケーションアーキテクチャをサポートしています。 MQTTは、CoAPのクライアント/サーバーアーキテクチャーとは対照的に、出版/購読型モデルをサポートしています。 出版/購読型アーキテクチャはIoTに適したアーキテクチャの1つです。なぜなら、ノードごとに直接アクセスを要求することなく、さまざまなアプリケーションの個々のセンサノードから送信されるデータを提供するからです。 これにより、フォグネットワークの需要が減少し、スケーラビリティが実現できます。 CoAPとMQTTは互いに排他的なものではありません。 ゲートウェイがCoAPを利用してデータを収集し、次にMQTTや他のプロトコルを利用して他のアプリケーションにアクセスするといったことも可能です。

重要なことは、既に導入されているアーキテクチャが相互運用性をサポートできることです。そしてこのおかげで、IoTがもたらす重要な約束の1つが実現します。つまり、革新的で収益性の高いアプリケーションを、インフラ投資を毎回することなく、素早く開発できるようになります。

例えば、作物を監視するためにUAVや他のセンサを配備した場合、農家は市場データや輸送状況に基づいて収穫に関する決定を調整できます。 特定の食品の需要を追跡するクラウドベースのアプリケーションは、農業システムが、需要増加に対応するため収穫を加速させるようにすることができるでしょう。 別のアプリケーションでは、ジャストインタイム収穫システムを操作して鮮度を最大限に保つことができるでしょう。 トラックが農場に到着できる範囲内にある場合にのみ、その日の収穫を始めます。UAVからのデータを使用して、どれほどの量の作物が収穫できるかを判断する予測ソフトウェアにより、トラックの到着時には作物の出荷準備が確実にできるのです。

トラックにセンサを追加して、位置や到着予定時刻を割り出す必要はありません。トラックはすでに到着しているのです。 唯一の要件は、データをアプリケーションで利用できるようにすることです。これはCoAPやMQTTなどのプロトコルを使用することにより実現できます。

IoTは、通信、センサ技術、クラウドベースの知見、オープンなソフトウェアプロトコルにまで及んでいます。 IoTは、これらの技術を組み合わせることなしには考えられないようなビジネスモデルによって、非常に多くの新機能を提供することを約束します。