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 の扱いがズレていないか？