Technology
MQTT
(MQTT)
MQTTとは、センサ、設備、IoTゲートウェイ、クラウドなどの間で、少量のデータを効率よく送受信するための通信プロトコルです。設備側がデータを送信し、必要なシステムがそのデータを受信するPublish／Subscribe方式を採用しています。
通信量を抑えやすく、回線が不安定な環境や多数端末の接続に適しているため、温度、重量、電力、設備状態、異常通知などのIoTデータ連携に利用されます。
ハカルプラスでは、送信データ、周期、通信回線、クラウド仕様を確認し、トピック設計、QoS、認証、通信断時の保存・再送を含むMQTT連携を検討します。
MQTTの主な用途
- 設備計測値のクラウド送信
- 異常・警報の即時通知
- 複数拠点の設備状態収集
- 電池駆動センサの少量データ通信
- IoTゲートウェイと上位システムの連携
- 設備設定・指令の配信
Publish／Subscribe方式
データを送信することをPublish、受信するために登録することをSubscribeと呼びます。
送信側は特定の受信先を直接指定せず、トピックへデータを送ります。受信側は必要なトピックを購読します。
ブローカー
送信されたデータを受け取り、購読者へ配信する中継サーバーをMQTTブローカーと呼びます。
設備やセンサはブローカーへ接続し、直接互いに通信しません。ブローカーが停止するとデータ配信へ影響するため、可用性と監視を検討します。
クライアント
MQTTブローカーへ接続する設備、ゲートウェイ、サーバー、アプリケーションをクライアントと呼びます。
一つのクライアントがPublishとSubscribeの両方を行うこともできます。
トピック
トピックは、送信データを分類するための名称です。階層をスラッシュで区切って表現します。
例えば、工場、ライン、設備、データ種別の順に階層化すると、必要な範囲だけを購読しやすくなります。
トピック設計
設備ごとに異なる命名をすると、上位システムの処理が複雑になります。
工場コード、設備番号、信号種別などの命名規則を統一します。後から設備を追加しても拡張しやすい構造とします。
ワイルドカード
複数のトピックをまとめて購読するため、ワイルドカードを使用できます。
同じライン内の全設備や、全拠点の異常トピックなどを一括購読できます。広すぎる指定は不要な通信量を増やすため注意します。
ペイロード
トピックへ送信する実際のデータをペイロードと呼びます。
JSON、文字列、バイナリなどを利用できます。日時、値、単位、品質、通し番号を含めると、受信側で扱いやすくなります。
JSON形式
JSONは項目名と値を組み合わせて表現でき、計測値、状態、時刻などを一つのデータへまとめやすい形式です。
人が内容を確認しやすい一方、バイナリ形式よりデータ量が増える傾向があります。通信量と可読性のバランスを取ります。
QoS 0
QoS 0は、メッセージを一度送信し、到達確認を行わない方式です。
通信負荷が小さく、最新値を頻繁に送る用途に適します。途中で失われても次回値で更新できる温度や状態監視などに利用されます。
QoS 1
QoS 1は、少なくとも一回は相手へ届くよう、受信確認が得られるまで再送する方式です。
同じメッセージが複数回届く可能性があります。実績や警報では、メッセージIDや通し番号で重複処理を防ぎます。
QoS 2
QoS 2は、メッセージが一回だけ処理されるように複数段階の確認を行う方式です。
信頼性は高まりますが、通信量と処理負荷が増えます。すべてのデータへ使用せず、用途に応じて選定します。
Retained Message
ブローカーがトピックの最新メッセージを保持し、新しく購読したクライアントへ直ちに配信する機能です。
設備の現在状態や設定値に有効ですが、古い値が最新として見える可能性があります。時刻と通信状態を合わせて確認します。
Last Will
クライアントが正常な切断処理を行わず通信を失った場合に、ブローカーが事前設定したメッセージを配信する機能です。
設備やゲートウェイの通信断通知に利用できます。ただし、回線断と機器故障を区別できない場合があります。
Keep Alive
一定時間データ送信がなくても接続が生きていることを確認するため、Keep Aliveを設定します。
時間が短すぎると通信量が増え、長すぎると通信断の検出が遅れます。回線品質と監視要件から設定します。
Persistent Session
クライアントの接続が一時的に切れても、購読情報や未配信メッセージを保持する構成があります。
移動通信や不安定な回線で有効ですが、長期間接続しない端末の情報がブローカーへ残り続けないよう管理します。
通信断時の一時保存
ブローカーへ接続できない場合は、IoTゲートウェイや設備側へ送信データを保存します。
復旧後に古い順から再送します。保存容量を超えた場合の動作、データ優先順位、欠測表示を決めます。
重複データの処理
QoS 1や再接続後の再送によって、同じデータが複数回届く場合があります。
設備ID、時刻、通し番号を組み合わせ、受信側で重複を判定します。生産数量や積算値を単純加算しないようにします。
送信周期
温度や電力量は数分ごと、モーター状態は数秒ごと、異常は発生時すぐなど、データごとに送信条件を分けます。
すべてのデータを短周期で送ると、通信量とクラウド保存量が増えます。変化時送信と定期送信を組み合わせます。
時刻情報
受信時刻だけでなく、設備がデータを取得した時刻をペイロードへ含めます。
通信断後にまとめて再送した場合でも、本来の発生時刻を判別できます。設備とゲートウェイの時計を同期します。
認証
ブローカーへの接続時に、ユーザー名・パスワード、証明書、トークンなどを使用します。
設備ごとに認証情報を分けると、特定機器だけを停止・更新できます。共通パスワードの広範囲利用は避けます。
TLS暗号化
インターネットや移動通信網を利用する場合は、TLSによって通信を暗号化します。
証明書の有効期限、時刻、暗号方式を確認します。証明書更新時に遠隔設備が接続できなくならない運用が必要です。
アクセス制御
クライアントごとに、Publish・Subscribeできるトピックを制限します。
計測装置が他設備の指令トピックへ書き込めないようにし、必要最小限の権限を設定します。
設備への指令配信
上位システムから設備へ、設定値や動作要求をMQTTで送ることもできます。
通信が届いただけで即時動作させず、設備側で権限、値範囲、運転状態、安全条件を確認します。指令受付と実行結果を別メッセージで返します。
ブローカーの冗長化
多数設備が一台のブローカーへ依存すると、故障時の影響が大きくなります。
クラスタ構成、待機系、クラウドサービスなどを利用し、必要な可用性を確保します。切替時の再接続と重複配信を確認します。
監視とログ
接続クライアント数、送受信件数、未配信数、認証失敗を監視します。
設備側では、最終送信時刻、未送信件数、再接続回数を表示・保存します。
異常時の確認
接続できない場合は、ブローカーアドレス、ポート、認証、証明書、時刻を確認します。
データが届かない場合は、トピック名、購読条件、QoS、アクセス権限を点検します。重複する場合は、通し番号と再送処理を確認します。
ハカルプラスの対応
ハカルプラスでは、設備データ、異常、計量実績などの送信項目と周期を整理し、MQTTのトピック構成を検討します。
IoTゲートウェイ、LTE・5G、TLS、証明書、一時保存、再送を組み合わせ、クラウドや監視サーバーへ安定してデータを送る構成に対応できる場合があります。
よくある質問
Q. MQTTは設備同士が直接通信する方式ですか？
A. 一般にはブローカーを介し、送信側と受信側がトピックを通じてデータを交換します。
Q. 通信が切れた場合にデータを再送できますか？
A. 設備側へ一時保存し、接続復旧後に時刻や通し番号を付けて再送できます。
Q. QoSは高いほどよいですか？
A. 信頼性は高まりますが通信負荷も増えるため、最新値、警報、実績など用途別に選定します。
Q. MQTTで設備へ運転指令を送れますか？
A. 送信できますが、設備側で権限、状態、安全条件を確認してから実行する必要があります。
Q. MQTT通信を暗号化できますか？
A. TLSと証明書を使用して暗号化・認証できます。
関連ワード
同じカテゴリの『ハカル技術辞典』を見る