
プロトコルの違う機器をまとめて接続し、上位システムには一つの窓口だけを見せます。
OPC UA、Modbus、BACnet/IP、MQTT のデバイスを1つのポイントモデルに集約し、統一 MQTT インターフェースで読み取り・制御。
機器はすでに稼働していて、データが複数のプロトコルの背後に散らばっている現場。

オフィスビルの空調機械室、商業施設の受変電室。空調機と電力量計の点を一本のデータにまとめます。

学校や病院の古いファンコイル系統。既設のコントローラーを残してセンサーを追加し、一つの表で読みます。

PLC と計器のメーカーが異なる工場。プロトコルの差はゲートウェイで吸収し、上位は一つの点リストだけを見ます。
適さない条件:Sparkplug B を必須とするシステム、認証された安全制御が必要な用途。Modbus RTU の本番書き込みは、現場での結合試験が終わるまで無効にしておきます。
現場にある既設のコントローラーと計器をゲートウェイホスト(reComputer R1000 / R1100 シリーズ、または reTerminal DM)に接続し、既存の上位システムから読み取ります。

3 つの要素があります。すでに設置されているフィールドデバイス、ポイントレジストリと双方向の通信を保持する 1 台のホスト、そして結果を受け取る側です。ホストはただの Docker ワークロードなので、コントローラネットワーク上の既存 Linux マシンも、専用に購入したゲートウェイと同じように使えます。ノースバウンド送信を有効にしない限り、現場からは何も出ていきません。
プラント側は何も置き換えません。変わるのはプロトコルの違いをどこで吸収するかだけです。
| フィールド側 | 接続方法 | 必要なもの |
|---|---|---|
| OPC UA コントローラ | ホストから到達可能な OPC UA エンドポイント | エンドポイントアドレスと認証情報 |
| Modbus デバイス | ローカルネットワーク上の Modbus TCP、または USB-RS-485 アダプタ経由の Modbus RTU | ユニット ID、レジスタマップ、バイト順とワード順 |
| BACnet/IP 設備 | 選択したネットワークインターフェースから到達可能な BACnet サブネット | ブロードキャストがそのインターフェースに届くこと。BBMD の境界と MS-TP は対象外 |
| MQTT ソース | 既存のブローカー | トピックとポイントの明示的な対応付け |
ディスカバリーは候補を提示するだけです。 管理対象ポイントになる前にユーザーが 1 件ずつ確認し、ディスカバリーが拾えなかった分は手動登録でカバーします。Modbus RTU にはシリアルデバイス向けのデプロイプロファイルが必要で、アダプタとコントローラが HIL 検証に合格するまで本番書き込みはオフのままです。
1 台のボードにポイントレジストリ、プロトコルアダプタ、内蔵 MQTT ブローカー、ノースバウンドパブリッシャー、Web コンソールがすべて収まります。x86-64 でも arm64 でも、Docker が動くホストであれば構いません。
| 要件 | |
|---|---|
| ランタイム | Docker Engine 20.10 以上 |
| ディスク | 空き 4GB 以上 |
| ポート | 8280(コンソール)と 1883(内蔵ブローカー)が空いていること。埋まっている場合はデプロイ前に別のホストポートを選ぶ |
| ネットワーク | 各プロトコルネットワークから到達可能なこと。リモートの Linux ターゲットはホストネットワーキングを使い、BACnet/IP のディスカバリーが物理サブネットに届くようにする |
| シリアル | Modbus RTU にはシリアルデバイス向けプロファイルが必要 |
| レジストリ上限 | 2,000 ポイント、うち書き込み可能は 50 まで —— コードで強制 |
同じサービスを動かせるリファレンスホストは 3 種類:reComputer R1000 Series(RS-485、Ethernet)、reComputer R1100 Series(RS-232、DI/DO、ギガビット Ethernet、CAN を追加)、reTerminal DM Series(デバイス上での設定用に 10.1 インチのタッチディスプレイを追加)。
ローカルシステムは内蔵 MQTT ブローカーを購読し、オペレーターはブラウザでコンソールを開きます。どちらもデータハブホスト上で完結し、インターネットは不要です。外部やクラウドのブローカーへのノースバウンド送信はオプトインで、ディスクにバッファリングするため、ブローカー障害時もサンプルはキューイングされ失われません。プレーンな MQTT はテレメトリ専用です。リモートコマンドを許可する前に TLS と認可された制御用 ID を有効にしてください。データインターフェースは下記の「何が得られるか」をご覧ください。
装置を立ち上げたあと、現場エンジニアがブラウザーのコンソールで機器を接続し、ポイントを監視し、書き込みごとの実行結果を確認します。
本デザインの能力の境界です。現場実測ではありません。
パッケージのホスト(reComputer R1000 / R1100 Series、reTerminal DM)上での全経路の実測はまだ行っていないため、ここに数値は掲載しません。開発機上でプロトコルシミュレータに対して測定した更新周期と障害後の追い込み結果はエンジニアリング Wiki にあります。
ポイント数 2,000(うち書き込み可能 50)の上限はコード上で強制される設計値であり、機器の限界ではありません。現場の規模は、選定したホスト上での自社の負荷試験から見積もってください。また、アダプタとコントローラが試運転を通るまで、Modbus RTU の本番書き込みは無効のままにしてください。
インターフェースは 3 つで、いずれもデータハブのホスト上にあります。どれを開放するかが、データが現場外に出るかどうかを決めます。
| ポート / エンドポイント | 内容 | インターネット |
|---|---|---|
HTTP 8280 / | ブラウザコンソール —— データソース管理、ポイントテーブル、コマンド受領票、プラグイン管理 | 不要 |
MQTT 1883 missionpack/v1/{gateway}/points/{point_id} | 内蔵ブローカーからのバージョン付きポイントテレメトリ。同じ契約上に presence、command、receipt のトピックも提供 | 不要 |
MQTT 8883 missionpack/v1/{gateway}/telemetry | ノースバウンドのバッチテレメトリ(QoS 1)。データソースごとのヘルス、遺言メッセージによる状態、ハートビートを含み、各サンプルにソースリビジョンとポイントリビジョンが付きます | ブローカーが現場外にある場合は必要 |
各サンプルには 2 つのリビジョン番号が付くため、受信側は値の変化と設定の変更を区別できます。ストアアンドフォワードはディスク上で動作し、導入ガイドに記載のイメージタグが必要です。契約はネイティブの MissionPack v1 であり、Sparkplug B ではありません。
再利用できる単位は「産業用ゲートウェイ」ではなく、「プロトコルアダプタ → 確認済みのポイントレジストリ → バージョン付きの単一 MQTT 契約 → コマンド受領票」というチェーンです。特定のプロトコルに紐づくのは最初の区間だけで、レジストリ以降は新しいプロトコルを追加してもそのまま使えます。
| レイヤー | 移植時に必要な作業 |
|---|---|
| ポイントレジストリ、リビジョン、品質モデル、2,000 / 50 の上限 | そのまま再利用 |
| 探索が候補を出し、利用者が確認するワークフロー | そのまま再利用(新しいアダプタが候補を供給) |
| 内蔵ブローカー、MissionPack v1 のトピック契約、presence と受領票 | そのまま再利用 |
| ノースバウンド配信とディスク上のストアアンドフォワード | そのまま再利用 |
| ブラウザコンソール、データソースとポイントの管理 | そのまま再利用 |
| プロトコルアダプタ本体(トランスポート、アドレッシング、データ型) | プロトコルごとに新規作成 |
| そのプロトコルの書き込み仕様(優先度、解放、読み戻し) | プロトコルごとに定義 |
形の似たデータソースは同じ範囲に入ります:ネットワークやシリアル経由でアドレス指定可能な値を公開し、一定周期でポーリングでき、品質を判断できるだけの情報を返すもの。
現場の状況をお聞かせください。ハードウェアはこちらで選び、その後データ接続と手順に進みます。
システムはどこから操作しますか?ここで決まるのはホストに画面が必要かどうかであり、接続できる対象ではありません。
| 構成 | 役割 | 機材 | 数量 |
|---|---|---|---|
| マルチプロトコルデータハブ | Data Hub Host | reComputer R1000 シリーズ / reComputer R1100 シリーズ / reTerminal DM シリーズ(いずれか) | 1 |
パッケージは 1 つです。ハードウェアの検討事項は、コントローラネットワークに置くホストの選定だけで、それ以外は試運転時に決めます。
| パッケージ | データハブのホスト | 導入するもの | 初日の制御 |
|---|---|---|---|
| マルチプロトコル・データハブ | reComputer R1000 Series、reComputer R1100 Series、reTerminal DM Series —— またはコントローラネットワーク上の任意の x86-64 / arm64 Docker ホスト | プロトコルアダプタ、2,000 ポイントのレジストリ、ポート 1883 の内蔵 MQTT ブローカー、ノースバウンド配信、ポート 8280 のブラウザコンソール、任意の予測プラグイン | 読み取りは可、書き込みは慎重に —— まずポイントごとに権限とデータ品質を確認し、ハードウェア・イン・ザ・ループの検証が済むまで Modbus RTU の本番書き込みは無効のままにします |
パッケージ内でエッジ機器は任意です。ローカルの Docker ターゲットは作業中のマシンにそのまま導入でき、SSH 経由のリモートターゲットは、コントローラネットワークに作業端末から到達できない場合に使います。Docker Desktop のブリッジ経由のローカルターゲットでは、BACnet のアドレスを手動で指定する必要がある場合があります。BACnet/IP のブロードキャスト探索がそのブリッジを確実には越えられないためです。
難易度は 中級、コンソールが起動するまでの目安は 15 分 です。最初のコントローラを組み込む工程 —— 探索、候補の確認、品質の検証、そして書き込み権限の付与 —— はこれより長くかかり、そのデプロイが信頼できるかどうかを決めます。
OPC UA、Modbus TCP と RTU、BACnet/IP、およびデータソースとしての MQTT に対応しています。BACnet の COV サブスクリプション、BBMD/外部デバイス登録、MS-TP は未実装です。Modbus RTU にはシリアルデバイスのデプロイ設定が必要です。
ありません。独自の MissionPack v1 契約を使用しており、Sparkplug のホストアプリケーション側で変換層が必要です。各サンプルにはデータソースのバージョン番号とポイントのバージョン番号が付き、コンシューマはこれにより「値が変わった」のか「設定が変わった」のかを区別できます。
北向き(ノースバウンド)送信はディスクにキャッシュされ、再接続後に再送されます。読み取り値は破棄されずキューに積まれます。上位システムで再送分をすべて受け取りたい場合は、永続化 Broker を使用し、永続サブスクリプションセッションを有効にしてください。この経路にはデプロイガイドに記載されているイメージタグが必要です。
レジストリの上限は 2,000 ポイントで、そのうち書き込み可能なものは 50 ポイントに、コードによって強制されています。これは設計上の上限であり、実測されたデバイス上限ではありません。現場規模に応じた機種選定の前に、選定したホストで自ら負荷試験を行ってください。
必須ではありません。コントローラと同じネットワークセグメント上に既にある Linux マシンもサポート対象です。リファレンスホスト間の違いはオンボードインターフェースにあり、R1000 シリーズは RS-485 とイーサネット、R1100 シリーズはさらに RS-232、DI/DO、CAN を備え、reTerminal DM はさらにタッチスクリーンを備えます。
読み書きの両方に対応しています。書き込みはまず権限とデータ品質のチェックを通過し、有効値、デバイスからの読み戻し、コマンドの応答によって追跡できます。リモート制御には TLS の有効化と制御用アイデンティティの設定が必須です。Modbus RTU の本番書き込み制御は、実機での結合テストが終わるまでは無効のままにしてください。
大半はネットワークインターフェースの問題です。BACnet/IP のディスカバリはブロードキャストに基づくため、ホストは BACnet のネットワークセグメント上にあるインターフェースを 1 枚持っている必要があります。Docker Desktop のローカルブリッジ配置ではこの種のブロードキャストが転送されないことがあります。その場合は BACnet アドレスを手動で入力してください。