JPY | USD

M2M/IoT機能に対するアプリケーション層プロトコルの選択肢

著者 ジョディ・ムエラナー

Digi-Keyの北米担当編集者 の提供

モノのインターネット(IoT)やインダストリ4.0の機能が採用されるのに伴い、産業用プロトコルによる機器の接続が増えています。さらに、今日のマシンツーマシン(M2M)通信では、これらのプロトコルが急速に標準となってきています。複雑なのは、複数の標準が運用されているため、IoTプロトコルが同一のアプリケーション層プロトコルを記述していないことです。つまり、初期のIoT実装では複数の標準的なインターネットプロトコルを使用していましたが、現在ではIoT専用のプロトコルも登場しています。

通信構造をモデル化し、特定のアプリケーションに適したプロトコルを特定することは、困難な場合があります。この記事では、設計者が統合に最適なプロトコルをより簡単に選択できるように、様々なプロトコルの機能と、それらのプロトコルで利用可能なオプションについて概説します。

産業用オートメーションにおけるIIoT機能の画像図1:産業用オートメーションにおけるIIoT機能では、ネットワークに産業用プロトコルを採用して接続するデバイスの使用が増えている。このようなネットワークの抽象化層を使用するに当たっては、下位層の機能を知っている必要はない。このため、マシン間ネットワークの最上位層(アプリケーション層)を重視する設計が多く行われている(画像提供:Getty Images)。

産業用ネットワークのアプリケーション層プロトコルの定義

デジタルM2M/IoTシステムの通信プロトコルの構造は、概念的に抽象化層に分かれており、一般的なモデルでは3~5層や7層となっています。これらの概念的なフレームワークは、すべての層が基本的に、所定のデバイス層やソフトウェア層の詳細な動作を、それらの層が通信している他のデバイスやアルゴリズムから「隠す」ことを前提としています。それは、層は担当するデータ交換に必要なだけの情報のみを含むものとして定義されているためです。

階層型システムアーキテクチャとクラウド/フォグコンピューティングを比較した画像(クリックで拡大)図2:従来のシステムアーキテクチャは階層型であるが、クラウド/フォグコンピューティングによってコンポーネント機能の境界線が曖昧になってきている。そのため、新しいネットワークプロトコルモデルの使用が求められている(画像提供:motioncontroltips.com)。

使用するどのモデルにおいても、ネットワーク上で相互に通信する機器間の最上位抽象化層として、アプリケーション層を設定します。アプリケーション層は、約30年前に国際標準化機構(ISO)によって開放型システム間相互接続(OSI)モデルの中で、ネットワーク通信用に初めて定義された概念の1つです。この古典的な7層モデルは、現在のプロトコルの一部を記述するにはやや複雑すぎますが、システム内のデータフローを完全に理解するのには役立ちます。

プロトコルの物理層では、生データ(デジタルビット)を電気信号、無線信号、光信号として伝送することができます。この層では、データを伝送する物理的要素のピンレイアウト、電圧レベル、データレート、ラインインピーダンスを規定します。Ethernetは代表的な物理層プロトコルです。その詳細については、Digi-Keyの記事「EtherNet/IP vs. PROFINET」をお読みください。

データリンク層は、ネットワークノードを接続することで、デバイスが接続の確立と物理層でのエラー修正を行えるようにします。IEEE 802規格では、データリンク層は、機器を接続するための媒体アクセス制御(MAC)層と、次に使用する層(ネットワーク層)の識別とエラーチェックや同期を行うための論理リンク制御(LLC)層に分かれています。データリンク層の機能については、Digi-Keyの記事「Implementing Industrial Ethernet with 32-bit MCU」をご覧ください。一方、ネットワーク層では、データパケットをネットワークアドレスに転送することができます。インターネットプロトコルが伝送制御プロトコル/インターネットプロトコル(TCP/IP)モデル(本記事の次のセクションで説明)である場合は、データリンク層とネットワーク層の間にインターネット層が存在します。実際には、通常、インターネット層はネットワーク層の一部であると考えられています。

OSIモデルにおけるこの次の3層のうち、最初の層はトランスポート層であり、この層はデータシーケンスの転送時に通信の信頼性とセキュリティを確保します。その下位のセッション層は、機器同士が接続するタイミングと、接続を一方向(シンプレックス)と双方向(デュプレックス)のいずれにするのかを制御します。最下位のプレゼンテーション層は、異なる構文を使用するデバイス同士が通信できるようにデータ変換を行います。

この記事で焦点を当てている「アプリケーション層」は、抽象度が最も高く、ユーザーとシステムソフトウェアが通信し合うのに使用するための層です。

最新のネットワークプロトコルで構成されるOSIネットワークモデルの画像図3:製造業(と商業)用ネットワークで構成される古典的なOSIモデルを用いて説明されることが多い現代のネットワークプロトコル(およびアプリケーション層)。これに対し、3層構造のIoTアーキテクチャモデルではアプリケーション層の下にネットワーク層と知覚層があり、4層構造のモデルではアプリケーション層の下にデータ処理層、ネットワーク層、センシング層がある形となる。5層構造のIoTプロトコルモデルは3層構造のモデルと似ているが、さらに処理層とエンタープライズ層が追加されている(画像提供:Design World)。

産業用オートメーションにおけるインターネットプロトコル

インターネットプロトコルとは、ネットワーク境界間(=インター)で通信を行うために、ネットワーク間でデータを(通常、相互に)リレーすることからそう呼ばれるようになったデータ通信システムのことです。その機能は通常、前述のTCP/IPの4層モデルで説明されます。ここで、物理ネットワーク層リンク層は、OSIモデルの物理層と同じです。一方、TCP/IPのインターネット層(OSIモデルのデータリンク層とネットワーク層の機能を統合したものとほぼ同じ)では、データパケットだけでなく接続も処理します。IPv6では、この層で128ビットのIPアドレスを使用してネットワーク上のホストを識別し、1038個を超える一意のホストを使用可能にします。

TCP/IPのトランスポート層は通常、伝送制御プロトコル(TCP)またはユーザーデータグラムプロトコル(UDP)で構成されています。TCPは一般的には、電子メールやウェブ閲覧など人的なインタラクションに使われ、論理的な接続、送信されたパケットの確認、失われたパケットの再送、フロー制御を行います。これに対し、UDPを使用しているのは、より低いオーバーヘッドと優れたリアルタイム性能を得ることを目的としている組み込みシステムです。UDPは、ドメインネームサーバ(DNS)や動的ホスト構成プロトコル(DHCP)のほか、新しいIoTアプリケーションにも対応しています。

アプリケーション層は、ネットワークのTCP/IPモデルにおいて最上位に位置します。OSIモデルのセッション層やプレゼンテーション層に対応する機能も含まれています。

一般的なTCP/IPアプリケーション層プロトコル

アプリケーション層プロトコルによっては、データ帯域幅、リアルタイム性、ハードウェア要件が異なります。これらの要素に加えて、工場やOEMチームがそのプロトコルに精通しているかどうかが通常、アプリケーション層プロトコルの重要な選択基準となります。ハイパーテキスト転送プロトコル(HTTP)や簡易メール転送プロトコル(SMTP)など初期に誕生したインターネットプロトコルは人間が開始して消費する通信に主に使用されていますが、IIoT用のTCP/IPプロトコルはマシンツーマシン(M2M)通信などの産業用通信に特化しています。

問題をやや複雑にしているのは、TCP/IPでウェブベースでの人間の情報操作に使われている、確立されたアプリケーション層プロトコルの多くが、消費者用/産業用のIoTにも使われていることです。そのようなプロトコルとしては、HTTPやSMTPだけでなく、セキュアシェル(SSH)やファイル転送プロトコル(FTP)があります。拡張マークアップ言語(XML)やJavaScript Object Notation(JSON)も使用すれば、IoTの機能をウェブ技術で実現することは通常可能です。注意点としては、HTTPの使用にセキュリティ上の問題があるということです。そのため、このようなシステムに含めるIoTデバイスはサーバではなく1台のクライアントのみで構成することを通常お勧めします。これにより、外部からネットワークへの不正アクセスを許す可能性のある接続要求をデバイスが受信するのを防ぎます。ここで、WebSocketプロトコルが、HTTPを介して全二重通信を確立することができます。HTTPを使用しない場合、セキュリティを確保した上でリアルタイムにデータ通信を行う多数の機器に対応する必要があるケースでは、eXtensible Messaging and Presence Protocol(XMPP)をお勧めします。

IoTプロジェクトがITの知識を持つスタッフによって主導されている場合には、このような(人間が読めるウェブ上の)馴染みのある規格の使用をお勧めします。しかし、M2Mなどの産業用通信には、新しいIIoTプロトコルの方が適している場合もあります。

垂直接続トランスポート機能にはMQTTを使用

IIoTで最も急速に採用されているのは、MQTT(Message Queuing Telemetry Transport)プロトコルです。これは、メモリが限られたIoTデバイス向けに使用されることを当初の目的にしていた軽量プロトコルです。MQTTは、IBMが石油パイプラインにセンサを取り付けるために開発したもので、最小限の帯域幅しか使用せず、コンパクトなプロセスフットプリントで動作します。制約付きアプリケーションプロトコル(CoAP)とは異なり、ISO/IEC 20922としてすでに規格となっています。より多くのリソースを必要とするTCPトランスポート層を使用するため、より多くの電力を消費します。しかし、MQTTのメッセージはCoAPのメッセージよりもはるかに小さい2バイトです。

MQTTは、そのオープン性から、特に簡単に実装することができます。Amazon Web ServicesのAWS IoTがメッセージトランスポートにMQTTを採用し、MQTTをv3.1.1の仕様に基づいてサポートしている(注意点はありますが)のも不思議ではありません。

MQTTにいくつかある制限は、MQTTが当初テレメトリプロトコルとして設計されたことに起因しています。このように制限があるのは、まもなくカバーされるIoT専用の軽量マシンツーマシン(LwM2M)プロトコルとは大いに異なる点です。オブジェクト、コネクティビティ監視、リモートデバイスアクションなどの機能はMQTT規格に含まれていないため、これらが含まれるかどうかは通常、ベンダーに依存しています。含めた場合は、標準化されているMQTTプロトコルの価値が多少減じることになります。また、MQTTにはエラー処理機能がありません。最後に、MQTTは完全なTLSプロトコルを使用して安全にすることもできますが、そうするとオーバーヘッドが大きくなります。

AMQP:主に企業レベルで使用

Advanced Message Queuing Protocol(AMQP)は、MQTTと類似した点をいくつかの持つもう1つのオープンスタンダードです。メッセージキューなどの高度な機能を備えています。しかし、AMQPのオーバーヘッドはMQTTに比べて高く、非常に制約の多いデバイスの接続には適していません。産業用IoTアプリケーションでの使用が、企業向けの高速メッセージングでの使用に比べてあまり一般的ではないのも不思議ではありません。

CoAP:シンプルな機器同士の接続に最適

インターネットエンジニアリングタスクフォース(IETF)で作成された制約付きアプリケーションプロトコル(CoAP)は、低消費電力ネットワーク上で、最小限のメモリと処理能力を持つ機器間の通信を可能にします。CoAPは非常に低いオーバーヘッドで動作できます。リクエストとレスポンスはわずか4バイトほどの小ささになります。CoAPは、複雑なトランスポートスタックを使用せず、代わりにUDPを使用します。UDPの詳細については、リンクを記載した前述のDigi-Keyの記事「EtherNet/IP versus PROFINET」をご覧ください。CoAPもHTTPと同様にRESTモデルを採用しているため、サーバはURLを使用してリソースを公開し、クライアントはPOST、GET、DELETE、PUTの各メソッドでそれらのリソースにアクセスします。さらに、CoAPは、XMLやJSONなど他のウェブ機能との統合のために、簡単にHTTPに変換することができます。設計者は、CoAPによるIoTデバイスの接続は、ウェブAPIによるデバイスの接続と非常によく似ていることに気づくはずです。

低消費電力のMCUであるNordic SiPの画像図4:LTE-M、ナローバンド(NB)IoTモデム、GPSを内蔵した低消費電力のMCUであるNordicのSiP。ソフトウェア開発キットではCoAPをセットアップ可能(画像提供:Nordic Semiconductor)。

LwM2M:電池駆動のデバイスを接続するのに使用

Open Mobile Allianceが提供するアプリケーション層プロトコルは、IoTアプリケーションに特化して構築されたLwM2Mプロトコルです。LwM2Mは、CoAPをベースにしているためその特性の多くを継承していて、スマートシティアプリケーション、出荷用コンテナ、貨物追跡、自動化されたオフハイウェイルーチン、電気・ガス・水道用計器の監視で使用されています。LwM2M規格では、明確に定義・更新される広範な標準オブジェクトや、コネクティビティの監視、リモートデバイスの動作などが規定されています。また、ファームウェアの自動アップグレードにより、LwM2Mで接続されたデバイスの管理が容易になります。JSONなどのモジュールを搭載すると、オーバーヘッドが大きくなりますが、開発者にとっては設計作業がしやすくなります。LwM2MはIoTアプリケーションに特化して設計されているため、オーバーヘッドを増やすことなく、強力なDTLSセキュリティプロトコルを実行することも可能です。

DDS:分散型リアルタイムアプリケーションに最適

Data Distribution Service(DDS)は少し変わっており、通常、アプリケーション層プロトコルではなくM2Mのミドルウェアに分類されます。自律走行車、発電機、航空管制システムなどで、安全で高性能な接続を実現します。このような環境において、DDSは、組み込みシステムの接続をサポートすることで、ゲートウェイに頼りすぎない分散制御を行えるようにします。また、DDSは、メッセージのルーティングと配信を、アプリケーションの介入なしに行います。さらに、DDSサービス品質パラメータが設定可能なので、システム制約内での作業に合わせてネットワークの運用を最適化することができます。

自律走行車向けソフトウェア「Connext Drive」の図図5:自律走行車用のConnext Driveソフトウェアは、AUTomotive Open System ARchitecture(AUTOSAR)AdaptiveとROS2ソフトウェアアーキテクチャの基盤の一部であるData Distribution Service(DDS)ミドルウェア上に構築されている。このソフトウェアは、DDSがIoTソフトウェアの統合をサポートしている例の1つである(画像提供:Real-Time Innovations)。

まとめ:IIoTアプリケーション層プロトコル

すべてのプロトコルには長所と短所がありますが、迅速な展開とセキュリティ(できれば小さなオーバーヘッド)を可能にするオープンソースのオプションが、IoTアプリケーションには最も適しています。組み込みシステムやシステムオンチップ(SoC)デバイスの演算能力はますます向上しているため、IIoTの実現に拍車をかけるとともに、各種プロトコルのアプリケーション層で実現できる機能がさらに増加しています。

免責条項:このウェブサイト上で、さまざまな著者および/またはフォーラム参加者によって表明された意見、信念や視点は、Digi-Key Electronicsの意見、信念および視点またはDigi-Key Electronicsの公式な方針を必ずしも反映するものではありません。

著者について

ジョディ・ムエラナー

ジョディ・ムエラナー博士は、製材所や医療機器の設計、航空宇宙製造システムの不確実性への対応、革新的なレーザー機器の開発などに携わってきたエンジニアです。同氏は、数多くの査読付き専門誌や政府の概要資料に寄稿しています...また、Rolls-Royce、SAE International、Airbusのための技術報告書も書いています。現在は、電動自転車を開発するプロジェクトを率いています。詳細はbetterbicycles.orgをご覧ください。また、同氏は脱炭素化技術に関する動向もカバーしています。

出版者について

Digi-Keyの北米担当編集者