OPC UA PubSubコネクタ

概要

OPC UA PubSubコネクタは、OPC UA PubSub仕様（Part 14）で定義されたパブリッシュ/サブスクライブパターンを実装します。2つのトランスポートマッピングのいずれかを使用して、OPC UAプロデューサーとコンシューマー間の高スループットで疎結合な通信を可能にします：

• MQTT - ブローカーベースのファンアウト用のMQTT/UDP経由のJSONエンコードメッセージ
• UADP - 低レイテンシLAN配信用のUDPマルチキャスト経由のバイナリUADP（UAデータグラムプロトコル）

コネクタタイプ:

• OpcuaPubSubReader - 受信PubSubメッセージをリッスンし、Meddleペイロードとして発行
• OpcuaPubSubWriter - MeddleペイロードをPubSubメッセージとしてパブリッシュ

機能

• ✅ 2つのトランスポート：MQTT（JSON）とUADP（バイナリマルチキャスト）
• ✅ JSONおよびUADPワイヤフォーマットの両方の自動デコード
• ✅ インターフェイス選択を伴うUDPマルチキャストグループ管理
• ✅ オプションのパブリッシャーIDおよびデータセット名フィルタリング
• ✅ 疎結合のプロデューサー/コンシューマー（ポイントツーポイントセッション不要）
• ✅ 高頻度のテレメトリ配信のために構築

基本設定

OPC UA PubSub Reader

UADP（マルチキャスト）

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Publisher_1",
    "dataSetName": "TankFarmDataSet"
  }
}

MQTT（UDP経由のJSON）

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "0.0.0.0:1883",
    "topic": "factory/line1",
    "publisherId": "Publisher_1",
    "dataSetName": "LineOneMetrics"
  }
}

OPC UA PubSub Writer

UADP（マルチキャスト）

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Publisher_1",
    "dataSetName": "TankFarmDataSet"
  }
}

MQTT（UDP経由のJSON）

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "192.168.1.20:1883",
    "topic": "factory/line1",
    "publisherId": "Publisher_1",
    "dataSetName": "LineOneMetrics"
  }
}

設定パラメータ

Transport

PubSubメッセージに使用されるワイヤトランスポート。以下のいずれかである必要があります：

• mqtt - UDP経由のJSONメッセージ（本番ではブローカーブリッジ）
• uadp - UDPマルチキャスト経由のバイナリUADPフレーム

{
  "transport": "uadp"
}

Broker URL（MQTTトランスポート）

transport: mqttの場合に必須。Meddleがバインドする（リーダー）または送信先（ライター）のアドレス。

{
  "brokerUrl": "192.168.1.20:1883"
}

形式: host:port。

注意:

• リーダーはこのアドレスでUDPリスナーをバインドします
• ライターの場合、これはPubSubメッセージの送信先アドレスです

Topic（MQTTトランスポート）

オプションの論理トピック識別子。データセットフィルタリングと一緒に含まれる情報メタデータです。

{
  "topic": "factory/line1"
}

Multicast Address（UADPトランスポート）

transport: uadpの場合に必須。IPv4マルチキャストグループとオプションのインターフェイス。

{
  "multicastAddr": "opc.udp://224.0.5.1:4840/eth0"
}

形式: opc.udp://<host>:<port>/<interface>。

• host:port - マルチキャストグループとポート（OPC UA PubSubのデフォルトでは典型的に224.0.5.1:4840）
• interface - 必須のネットワークインターフェイス名（eth0、en0、lo0）

インターフェイスが必須な理由? UDPマルチキャスト参加はインターフェイススコープです。指定されたインターフェイスがないと、OSはマルチキャストグループを確実にバインドできません。特にmacOS（lo0）と複数のNICを持つクラウドVMで顕著です。

プレーンなhost:port（スキームなし）も下位互換性のために受け入れられますが、インターフェイス選択を強く推奨します。

Publisher ID

PubSubメッセージのソースを識別します。

{
  "publisherId": "Publisher_1"
}

注意:

• ライターでは必須（パブリッシュされる各メッセージにタグ付けされます）
• リーダーではオプション（設定されている場合、このパブリッシャーからのメッセージのみが保持されます。空の場合、すべてのパブリッシャーが受け入れられます）

DataSet Name

パブリッシャー内の論理データセットを識別します。

{
  "dataSetName": "TankFarmDataSet"
}

注意:

• リーダーとライターの両方でオプション
• リーダーでは、設定されている場合フィルタとして機能

ワイヤ形式

JSON（MQTTトランスポート）

MQTTトランスポートは標準的なJSONエンベロープでメッセージを発行します：

{
  "PublisherId": "Publisher_1",
  "Messages": [
    {
      "DataSetName": "TankFarmDataSet",
      "Payload": {
        "tank_1_level": 78.4,
        "tank_2_level": 62.1,
        "pump_running": true
      }
    }
  ]
}

UADP（UADPトランスポート）

UADPトランスポートはOPC UA Part 14フレーミングに従ったバイナリフレームを発行します。リーダーはUADPとJSONコンテンツを自動検出し、両方をデコードします。デコードされた各UADPデータセットは、1つのMeddleペイロードを発行します。

データフロー

リーダー

マルチキャスト / UDP → OpcuaPubSubReader →（JSONまたはUADPデコード） → Meddleペイロード

単一のネットワークメッセージ内の複数のデータセットは、複数のMeddleペイロード（データセットごとに1つ）を生成します。

ライター

Meddleペイロード → OpcuaPubSubWriter →（JSONエンベロープエンコード） → UDP送信 → サブスクライバー

ライターは両方のトランスポートで常にJSONを発行します。各Write呼び出しは正確に1つのネットワークメッセージを生成します。

一般的なユースケース

1. 疎結合のプラントフロアテレメトリ配信

中央PLCがプロセス変数をUADPマルチキャストグループにパブリッシュし、複数のMeddleサブスクライバーが独立してそれらを消費します。

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "PLC_Master"
  }
}

2. MQTTブリッジIoTテレメトリ

OPC UA PubSubをJSONフレンドリーなMQTTトピックにブリッジしてクラウドプラットフォームに取り込み：

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "0.0.0.0:1883",
    "topic": "factory/sensors",
    "dataSetName": "EnergyMeters"
  }
}

3. 集約されたKPIをパブリッシュするエッジゲートウェイ

処理後、集約されたKPIを単一のPubSubメッセージとしてパブリッシュ：

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Edge_Gateway_1",
    "dataSetName": "PlantKPIs"
  }
}

トラブルシューティング

メッセージが受信されない（UADP）

問題: リーダーが静かに実行されているが、ペイロードを発行しない

解決策:

1. マルチキャストグループがパブリッシャーと正確に一致することを確認（224.0.5.1:4840）
2. multicastAddrでインターフェイスを指定（例：/eth0） — 自動検出は信頼できません
3. tcpdump -i eth0 host 224.0.5.1 and port 4840のようなネットワークスニファーを使用してパケットが到着していることを確認
4. パブリッシャーとサブスクライバー間のスイッチ/ルーターでマルチキャストルーティングが有効であることを確認

network interface is required

問題: UADP設定が起動時に拒否される

解決策:

1. インターフェイスを含めるようにmulticastAddrを更新：opc.udp://224.0.5.1:4840/eth0
2. macOSではループバックインターフェイスはlo0、Linuxではlo。ifconfigまたはip addrで確認

パブリッシャーがフィルタアウトされる

問題: リーダーがワイヤ上でメッセージを見るが、何も発行しない

解決策:

1. リーダーのpublisherIdフィルタを確認 — 設定されている場合、そのパブリッシャーからのメッセージのみがパススルーします。すべてを受け入れるためにクリアします
2. dataSetNameにも同じことが言えます — 設定されている場合、マッチするデータセットのみがパススルーします

UDPポートがすでに使用中

問題: bind: address already in use

解決策:

1. 同じホスト上の複数のリーダーは異なるポートを使用する必要があります
2. UADPマルチキャストの場合、同じホスト上の複数のプロセスはSO_REUSEPORTが尊重される場合のみ（Linux）同じグループに参加できます。macOSではプロセスごとに同じグループ+ポートにつき1つのバインディングのみが許可されます

デコードエラー

問題: すべてのメッセージでErrOpcuaPubSubDecodeが発生

解決策:

1. パブリッシャーがJSONまたはUADPを使用しているかを確認 — リーダーは自動検出しますが、不正なデータは両方のパスで失敗します
2. パブリッシャーのPubSub設定を検査：データセットコンテンツタイプはサポートされているスカラーまたは構造である必要があります
3. パブリッシャーとサブスクライバーがエンコーディングについて一致していることを確認（OPC UAサーバーのPubSub設定がこれを定義します）

ベストプラクティス

1. プラント内配信にはUADPを使用

UADPはJSON-over-MQTTよりも高速でオーバーヘッドが少ないです。ネットワークを制御できる場合は常にそれを使用してください。

2. クロスサイトブリッジにはMQTT-JSONを使用

JSONは可搬性があり、デバッグが容易です。メッセージが公開インターネットを横断する必要がある場合、または非OPC UAツールによって消費される場合は、MQTT-JSONがより実用的です。

3. UADPでは常にインターフェイスを設定

OSが正しいNICを「推測する」ことに決して頼らないでください。マルチホームホストとコンテナはそうしないと静かに失敗します。

4. サブスクライバーでフィルタリング

publisherIdとdataSetNameフィルタリングはサーバー側で安価で、ダウンストリーム処理負荷を劇的に削減します。

5. IPマルチキャストを慎重に計画

• OPC UA Foundationの予約範囲（224.0.5.0/24）を使用
• ネットワークチームと調整 — 制御されていないマルチキャストはLANをフラッディングする可能性があります
• 本番に移行する前にtcpdump/Wiresharkでテスト

ワークフロー例

プラント全体のテレメトリファンアウト

PLC（パブリッシャー） → UADPマルチキャスト 224.0.5.1:4840
                                     │
                            ┌────────┼────────┬──────────────┐
                            ↓        ↓        ↓              ↓
                     OpcuaPubSubReader   OpcuaPubSubReader   OpcuaPubSubReader
                      （ストレージ）      （ダッシュボード）    （アラート）
                            │                 │                  │
                            ↓                 ↓                  ↓
                    InfluxDb2Writer        Chart              Isa182 → Alert

エッジツークラウドブリッジ

ModbusReader → Reshape → OpcuaPubSubWriter（MQTT） → 外部ブローカー → クラウドサブスクライバー

レガシーModbusデバイスをモダンなOPC UA PubSubエコシステムにブリッジします。

関連コネクタ

• OPC UA - 従来のOPC UAクライアント/サーバープロトコル（ポイントツーポイント）
• MQTT v5 - 汎用MQTT（非OPC UA）PubSub
• Modbus - レガシーデバイスをPubSubファブリックにブリッジ
• Reshape - パブリッシュ前にフィールド名を正規化
• InfluxDB v2 - サブスクライブされたテレメトリを永続化

追加リソース

• OPC UA Part 14: PubSub - 公式仕様
• OPC Foundation
• UADPネットワークメッセージリファレンス
• IANAマルチキャストアドレス
• Wireshark OPC UA PubSubディセクタ