定義──トピック・ペイロード・状態管理の3点を規定

Sparkplug Bは、Eclipse Foundationのもとで開発されている、MQTTの上にトピック名前空間・ペイロード形式・状態管理を定義する仕様です。素のMQTTは軽量なpublish/subscribe型メッセージングプロトコルであり、転送の仕組みは定めても「何を・どんな形式で・どんな名前のトピックに載せるか」は自由です。この自由さが相互運用の障害になるため、Sparkplugはトピック構造をspBv1.0/グループID/メッセージ種別/エッジノードID/[デバイスID]の形に固定し、ペイロードをProtocol Buffersベースのバイナリ形式で定義し、さらにBIRTH／DEATHメッセージによる接続状態の管理（発行元が生きているか、最後の値が有効かを購読側が判断できる仕組み）を規定します。現行版はバージョン3.0（2022年10月リリース）で、2023年11月にISO/IEC 20237として国際標準になりました。

誤解されやすい点──OPC UAの対抗馬ではない

「Sparkplug B対OPC UA」という対立構図で語られることがありますが、両者の守備範囲は異なります。OPC UAが機器の意味論まで含む豊かな情報モデルを提供するのに対し、Sparkplug Bのペイロードはメトリクス（名前・型・値・タイムスタンプ）の集合というシンプルな構造で、「軽く・疎結合に・大量配信する」ことに最適化されています。設備近くの精密なデータ取得はOPC UA、拠点全体への配信・集約はMQTT＋Sparkplugという組み合わせが実務では一般的です。もう一つの誤解は「Sparkplug対応と書いてあれば相互接続できる」というものです。v3.0で規範文が明確化され互換性テストが可能になったものの、メトリクスの命名や単位の扱いはユーザー側の設計に委ねられており、名前空間の設計規約を決めなければ相互運用は完成しません。また品質記録や電子署名のような規制対応の記録性は仕様の範囲外で、そこはMES側の責任です。

実務でこの用語が出てきたら確認すべきこと

  • バージョンと準拠範囲──提案製品が準拠するのはv3.0（ISO/IEC 20237）か、それ以前か。互換性テストの実施状況も確認します
  • メトリクス設計の規約──タグの命名、単位、エンジニアリング値への変換をどこで統一するか。仕様は形式を定めるだけで、意味の統一は自社の仕事です
  • ブローカーの可用性設計──UNS的な使い方をするとブローカーが単一障害点になります。冗長化と、断線時のストアアンドフォワードの扱いを確認します

深く知る

Sparkplug AやSparkplug Cはあるのですか？

Sparkplug Aは初期仕様で、現在使われているのは事実上Bのみです。仕様の系譜は1.0（2016年）から3.0（2022年）へと進み、名称としての「B」はペイロード定義の世代を指しています。

PLCが直接Sparkplug Bを話せない場合はどうしますか？

エッジゲートウェイやプロトコル変換ツールでOPC UA・各社PLCプロトコルからSparkplug Bへ変換するのが一般的です。変換層でタグの文脈づけ（設備・ライン・品目との紐づけ）まで行う設計が主流です。