Web系エンジニアがSCADAに憧れてModbusを触り始めたら、
RTU / TCP / Slave(マスター / Unit ID) で初手から盛大に詰まり ました。

PLC実機は持っていないので、 PythonでPLCシミュレータを作りながら理解した内容を
未来の自分と、同じ沼にハマる人向けに整理します。

結論（まずこれだけ）

RTUのマスターは“役割”であって“機器の種類”ではない
- PLCにもなれる
- ゲートウェイにもなれる
- 産業用PCにもなれる
Modbus TCP の Unit ID（slave番号）は基本的にRTU互換の名残
- ただし TCP⇔RTU ゲートウェイ構成では実用上めちゃ重要

Modbus RTU とは？

特徴（RTU）

物理：RS-485 / RS-232
トポロジ：バス型（数珠つなぎ）
1マスター + 複数スレーブ
マスターだけが通信を開始
slave番号（Unit ID）が必須

[ マスター ] ---- RS-485 ---- [ スレーブ#1 ]
                             [ スレーブ#2 ]
                             [ スレーブ#3 ]

「誰に話しかけているか」を示すのが slave番号

スレーブって何者？

スレーブ =「要求が来たら答える側」
自分からは基本しゃべらない。聞かれたら返すだけの存在。

役割	従来の呼び方	いま風の言い方
司令塔	マスター	クライアント
返答役	スレーブ	サーバ / デバイス

Modbusでは今でも仕様書に Master / Slave 表記がありますが、
ドキュメントによっては Client / Server 表記も見かけるときがあります。

ざっくりイメージ

SCADA / 上位システム
「40513 読ませて」

PLC（スレーブ）
「はい、40513 = 1 です」

この 側がスレーブ。

自分からは送らない
読まれたら返す
書かれたら反映する
指定されたアドレス範囲しか知らない

RTUのマスターになれる“正体”は3パターン

① PLC がマスター


[ PLC (Master) ] ---- RS-485 ---- [ インバータ ]
[ 電力計 ]
[ I/O ]

条件

PLCが Modbus RTU マスター対応
または RS-485 通信ユニットを装着

Modbus TCP 非対応の機器を扱う場合、現場で一番多い構成な気がします。

② ゲートウェイがマスター（TCP⇔RTU変換）

[ SCADA ]
    |
Ethernet
    |
[ Gateway (RTU側 Master) ] ---- RS-485 ---- [ 旧機器 ]

方向	役割
TCP側	サーバ（スレーブ役）
RTU側	マスター

古いRTU機器をLANの世界に“翻訳”する橋渡し役

③ 産業用PC / 普通のPCがマスター

[ PC (Master) ] ---- USB-RS485 ---- [ センサー ]
                                    [ 電力計 ]

検証・試験・シミュレーションでよく使う構成
pymodbus / minimalmodbus などで実装

「スレーブの取り扱いが分からない」問題の正体

たぶんここが詰まったやつ

勘違いしないように

勘違い	実際
スレーブが勝手に通知してくる	❌ しない
スレーブ側から通信を開始できる	❌ できない
スレーブは状態を定期送信する	❌ 読まれたら返すだけ
スレーブは複雑なロジックを持てない	⭕ 持ってよい（通信は受動的）

つまり「RTUのマスターって誰？」

PLC？
ゲートウェイ？
Modbus対応PLC？

全部 YES（役割で決まる）

機器	マスターになれる？	条件
PLC		RTUマスター対応 or 通信ユニット
ゲートウェイ		TCP⇔RTU変換
PC		RS-485変換器 + ソフト
PLC（スレーブ専用）		マスター機能なし

Modbus TCP とは？

特徴（TCP）

物理：Ethernet（LAN）
IPアドレスで相手が一意
高速・構成がシンプル
slave番号（Unit ID）は基本不要

[ SCADA ] ---- TCP/IP ---- [ PLC ]

　IPアドレスで相手が決まるので「slave番号で誰に送るか」を決める必要がない。

それでも Unit ID が残っている理由

① RTU互換（歴史的経緯）

TCP化したが、フレーム構造を流用
Unit IDフィールドがそのまま残った

② TCP ⇔ RTU ゲートウェイ対応（ここが実務で重要）

[ SCADA ]
    |
(TCP)
    |
[ Gateway ] -- RS-485 --> [ Slave#1 ]
                          [ Slave#2 ]
                          [ Slave#3 ]

項目	意味
IP	ゲートウェイ
Unit ID	RTU側のスレーブ番号

TCP側の Unit ID = RTU側の宛先指定

扱い方

PLCへ直TCP接続

SCADA ---- TCP ---- PLC

Unit ID = 1 固定でOK（PLC仕様に従う）
複数PLCは IP で区別

TCP⇔RTUゲートウェイ経由

SCADA --TCP--> Gateway --RTU--> 複数機器

Unit ID = RTU側のスレーブ番号
設定ミスで 別機器が動く事故 が起きがち

よくあるハマりどころ

症状	原因
つながるが応答なし	Unit IDがPLC想定と違う
一部の機器だけ反応しない	Unit ID=0 を受け付けない機器がある
ゲートウェイ越しで誤動作	Unit ID 指定ミス

まとめ（これだけ覚えればOKかな！）

RTUのマスターは“役割”
TCPのUnit IDは“名残”
ゲートウェイ構成のときだけ本気で効いてくる

おまけ：設計チェックリスト

PLCはRTUマスター対応か？
Unit ID の扱いを構成図に明記しているか？
ゲートウェイ越しなら Unit ID と RTUアドレス対応表を作っているか？
検証環境と本番で Unit ID の扱いがズレていないか？