モノのインターネットのプロトコル

現在、インターネットをIoTに適合させることは、多くの国際標準化団体にとって主要な優先事項の1つです。 

システムがTCPの機能を必要とせず、より制限されたUDP機能で機能できる場合は、TCPモジュールを完全に削除すると、製品の合計コード フットプリントのサイズを大幅に削減できます。これが、6LoWPAN (WSN用) とCoAP (軽量インターネット プロトコル) がIoTの世界にもたらすものです。

コーポレート

WebインフラストラクチャはIoTデバイスで利用可能で使用可能ですが、大部分のIoTアプリケーションには重すぎます。2013年7月、IETFは、低電力および損失の多い (制約のある) ノードおよびネットワーク (LLN) で使用するための制約付きアプリケーション プロトコル (CoAP) をリリースしました。CoAPは、HTTPと同様に、RESTfulプロトコルです。

CoAPは意味的にHTTPと一致しており、HTTPとの間で1対1のマッピングも備えています。ネットワーク デバイスは、フラッシュ メモリとRAMの容量が少ない小型マイクロコントローラによって制約を受けますが、6LoWPANなどのローカル ネットワークの制約は、パケット エラー率が高く、スループットが低い (1秒あたり数十キロビット) ことが原因です。CoAPは、バッテリーまたはエネルギーハーベスティングで動作するデバイスに適したプロトコルです。

CoAPの特徴: CoAPはUDPを使用する

 CoAPはUDPを使用するため、TCP機能の一部はCoAPに直接複製されます。たとえば、CoAPは確認可能なメッセージ (確認応答が必要) と確認不可能なメッセージを区別します。

•  リクエストとレスポンスは、CoAPメッセージを介して非同期的に交換されます (既存のTCP接続が使用されるHTTPとは異なります)。

•  すべてのヘッダー、メソッド、ステータス コードはバイナリでエンコードされるため、プロトコルのオーバーヘッドが削減されます。ただし、ネットワークの問題をトラブルシューティングするには、プロトコル アナライザーを使用する必要があります。

•  HTTPとは異なり、CoAP応答をキャッシュする機能は、要求方法ではなく応答コードに依存します。

  CoAPは、非常に軽量なプロトコルと永続的な接続の性質に対するニーズに完全に対応します。HTTPと意味的によく似ており、RESTful (リソース、リソース識別子、および統一されたアプリケーション プログラミング インターフェイス (API) を介してそれらのリソースを操作する) です。Webの経験があれば、CoAPの使用は比較的簡単です。

  翻訳

  MQ Telemetry Transport (MQTT) は、制約のあるデバイスや、低帯域幅、高レイテンシ、または信頼性の低いネットワーク向けに開発および最適化されたオープン ソース プロトコルです。これは、非常に軽量で、最小限の帯域幅で小型デバイスをネットワークに接続するのに最適な、パブリッシュ/サブスクライブ メッセージング トランスポートです。MQTTは帯域幅効率が高く、データに依存せず、TCPを使用するため継続的なセッション認識を備えています。これは、デバイスのリソース要件を最小限に抑えると同時に、信頼性を確保し、サービスのグレードに応じてある程度の配信保証を実現することを目的としています。

  MQTTは、インターネット上のバックエンド サーバーから監視または制御する必要がある小型デバイスの大規模ネットワークを対象としています。デバイス間の転送用に設計されていません。また、多数の受信者にデータを「マルチキャスト」するようには設計されていません。MQTTはシンプルで、制御オプションはほとんどありません。この場合の「リアルタイム」の定義が通常秒単位で測定されるため、MQTTを使用するアプリケーションは一般に低速です。

  潜在的なIoTプロトコルの比較

  Ciscoはインターネットの中心であり、同社のIP機器はあらゆるところに存在しています。Ciscoは現在、IoTの進化に積極的に取り組んでいます。物理的なオブジェクトを接続して環境からデータを取得し、そのデータを処理して生活水準を向上させる可能性を見出しています。

• これらのインターネット固有のIoTプロトコルは、メモリ容量の少ないデバイスや、帯域幅が狭くレイテンシが高いネットワークの要件を満たすように開発されました。

• HTTPはIoTデバイスにとって重いプロトコルになる可能性があります。メッセージは人間が読める形式で送信されるため、サイズが大きくなります。IoTデバイスの場合、ペイロード サイズが制約となることがよくあります。大規模なデバイス ファミリの場合、はるかに軽量なプロトコルを使用して、コマンドの報告と受け入れをより効率的に実行できます。これらの問題に対する解決策としてMQTTが提案されました。MQTTはIETF標準ではなく、IBMとEclipse財団によって推進されています。

  結論

  「モノのインターネット」という用語にはインターネットが含まれています。インターネット プロトコルを使用せずにIoTデバイスと呼ばれるデバイスを提供する企業もあります。これを予想すべきです。今日、IoTは非常に強力な用語 (誇大宣伝だと言う人もいる) であるため、すべてのメーカーがIoTに関する膨大なメディア報道を活用したいと考えています。

  インターネット プロトコル (IP) はキャリアであり、現在のWebと同様にIoT用のプロトコルをカプセル化できます。多くの業界の専門家がプロトコルの標準化を求めています。しかし、Webにこれほど多くのプロトコルがあるのなら、IoTにも同じように多くのプロトコルがあるのはなぜでしょうか?要件を満たすプロトコルを選択します。唯一の違いは、IoTプロトコルはまだかなり新しく、信頼性が実証されていないことです。インターネットが現実のものとなったとき、それを可能にしたのはIPバージョン4だったことを思い出してください。現在、IPバージョン6が大規模に導入されており、IoTは通信事業者が必要な投資を正当化するために待ち望んでいたキラー アプリケーションです。

  各IoTプロトコルの位置付けについても同様の質問が必要です。HTTPを除き、これらすべてのプロトコルは、数百万台のデバイスをサポートするリアルタイムのパブリッシュ/サブスクライブIoTプロトコルとして位置付けられています。「リアルタイム」（秒、ミリ秒、マイクロ秒）と「モノ」（WSNノード、マルチメディア デバイス、個人用ウェアラブル デバイス、医療用スキャナー、エンジン制御など）をどのように定義するかに応じて、製品のプロトコルの選択が重要になります。基本的に、これらのプロトコルはすべて非常に異なります。

  ただし、ハードウェアとソフトウェアの設計を超えて、IoTデータ システムの設計が重要になります。データとアプリケーションを分離して、これまで想像もできなかった新しいことを実現できるようにする必要があります。一般的な組み込みシステム開発者にとって、システムが生成するデータについて具体的に考えるには、新しい考え方が必要です。このデータには価値があります。組み込みシステムの設計では、モノ、ローカル ネットワーク、さらにはゲートウェイを設計する方法を非常によく理解しています。プロセッサ、センサー、ワイヤレス接続、ゲートウェイ、IPネットワーク、セキュリティはすべて、組み込み開発者によく知られている要素です。

  組み込みコミュニティにとっての新たな課題は、何らかのクラウド コンピューティングを活用して、データに内在する価値を最大限に活用することです。組み込みシステムのデータを収益化するには、プライベート、アウトソーシング、パブリックを問わず、何らかのタイプのクラウド コンピューティングが絶対に必要です。これは組み込みコミュニティにとって新しいパラダイムです。

  組み込みシステムのハードウェア テクノロジ、ソフトウェア テクノロジ、インフラストラクチャ、クラウド コンピューティングが積極的にテストおよび展開されており、新興のモノのインターネットが促進されています。本当に成功し、2020年までに導入される500億台のデバイスを実現するには、人々のインターネット (Webとも呼ばれる) の作成を支えたのと同じオープン スタンダード、開発、協力が必要です。IPSOアライアンスはIP標準を推進し、それを使用して製品開発者が求めているリファレンス アーキテクチャを構築しています。

  組み込みシステム向けIoTは新たな産業革命です。組み込み業界の成長の可能性は非常に大きいです。この可能性を実現するには、組み込み業界が新しいIoTパラダイムを採用する必要があります。何をする必要があるかが分かりました。将来のIoTシステムの各構造要素 (構成の容易さや安全なリモート ファームウェア アップグレードなど) については、まだ明確に定義され確立された標準がない可能性があります。しかし、これは顧客に価値を提供するシステムの構築を妨げるものではありません。