MQTTは、発行者がメッセージを送り、購読者が関連トピックのメッセージを受け取るプロトコルです。産業用収集装置とアプリケーションをつなげますが、センサーの測定方法、値の単位、アラーム条件を決めるものではありません。それらはアプリケーションのデータ契約で定義します。
ブローカーとトピックの設計
ブローカーは発行されたメッセージを購読者へ転送します。発行者は全受信者を直接知る必要がなくなりますが、ブローカーのアクセス、容量、権限、接続状態は運用責務になります。すべての機器に全トピックへの発行を認めるのは適切な初期設定ではありません。
トピック名には分かりやすい設備階層を反映します。例はsite-a/line-2/machine-7/stateで、実在施設のアドレスではありません。表示名と安定した設備識別子を分け、改名で履歴が分断されないようにします。秘密情報や個人情報をトピック名に入れません。
ペイロードには値、単位、取得元時刻、品質、スキーマ版を含められます。サイズ制限と任意項目を文書化します。受信者ごとにレジスターの意味を推測せず、同じメッセージを同じように解釈できるようにします。
QoSが実際に保証する範囲
OASIS MQTT 5.0は三つのQoSを定義します。配送動作が対象とするのは、該当するプロトコル通信区間です。データベース書き込みや物理動作が一度だけになる保証ではありません。
| レベル | プロトコル上の配送動作 | アプリケーションの問い |
|---|---|---|
| QoS 0 | 最大1回 | この観測は失われてもよいか |
| QoS 1 | 少なくとも1回 | 重複をどう認識するか |
| QoS 2 | 対象通信区間で正確に1回 | 下流サービスではどうなるか |
購読側が処理後にデータベースの確認を失うと、再試行で処理を重ねることがあります。そのためMQTT設定に加え、安定したイベント識別子、一意制約、トランザクション境界が重要です。QoS 2は無制限の業務全体の「正確に1回」保証ではありません。
保持メッセージは現在値とは限らない
保持メッセージは新しい購読者に、そのトピックの最後の保存内容を渡せます。ただし古い値かもしれません。画面は取得元時刻と鮮度方針を確認します。接続直後の受信は、機器が現在正常である証拠ではありません。
遺言メッセージは接続喪失の合図になりますが、あらゆる現場故障を診断するわけではありません。収集装置は接続中でも一つのセンサーに届かない場合があります。機器可用性、収集装置の健全性、アプリ接続を区別します。
温度収集の説明用フロー
上流が使えない間、収集装置が時刻付き温度記録を蓄えるとします。復旧後、元のイベント識別子で送ります。アプリは重複を除き、遅着を履歴へ配置し、古い再送値で現在表示を上書きしません。
キューは有限です。対応可能な停止時間、保存警報、保存失敗時の動作を定めます。多数の機器が同時復帰する試験を行い、再送を制限して現在測定と現場ポーリングを維持します。上限を持つ待機の延長は、復旧中のネットワークをさらに悪化させないために役立ちます。
調査時の確認事項
- ブローカーはどこで動き、誰が運用するか。
- 機器識別子とトピック権限をどう管理するか。
- 有効なメッセージの必須項目は何か。
- 蓄積、再送、重複をどう試験するか。
- 認証情報や証明書の更新時にどうなるか。
MQTTは良いデータモデルや運用計画の代わりではありません。通常、切断、重複配送を小さな流れで検証してから機器を増やします。
アプリケーション側の重複例
収集装置がobservation-1042という温度観測を発行したとします。受信アプリは保存しましたが、処理確認が送信側へ届きません。再試行でも同じ識別子と元の時刻を使えば、受信側は既存記録を認識し、2件目を追加せずに済みます。再試行ごとに新しい識別子を付けると、同じ観測の二つの配送だという証拠を失います。
別の消費側がその記録からアラームを評価するなら、その処理状態も考慮します。測定の重複防止は通知の重複防止を自動的には実現しません。入力イベント、アラーム遷移、通知ジョブの関係を保存します。配送事業者がタイムアウトした場合は「何も送られていない」と断定せず、不確かな結果を保持します。これはアプリ設計例であり、MQTTの追加保証ではありません。
拒否メッセージの扱いも決めます。不明なスキーマ版、誤単位、存在しない設備識別子を診断可能にします。恒久的に不正なメッセージを無制限に繰り返しても資源を消費するだけです。範囲を定めた拒否処理と影響元の運用表示を用意し、デバッグのためだけに認証情報や無制限の本文をログへ含めません。
権限と復旧を検証する
機器識別子ごとに許可された発行・購読トピックを試し、範囲外へのアクセスが拒否されることも確認します。交換した認証情報と廃止機器は、普通の再接続と別に試します。接続成功だけでは、接続の権限境界は分かりません。
復旧演習では収集を続けたまま上流を切り、履歴と現在観測の両方を伴って戻します。元の時刻、識別子、画面の経過時間を確認します。保存上限に到達した動作も調べ、ブローカー復旧後にも満杯だった事実を見えるようにします。選択したMQTT版、セッション動作、アプリの確認規則を、実際のクライアントとブローカー設定とともに残します。統合レビューにはこの運用記録、サンプルペイロード、トピック階層を持ち寄ります。一つのQoS設定ですべて解決すると主張せず、信頼性の境界を評価できます。