Modbus란? Modbus RTU·ASCII·TCP 차이와 산업용 통신 원리

Modbus란? Modbus RTU·ASCII·TCP 차이와 산업용 통신 원리#

1장 1979년에 등장한 Modbus를 왜 지금도 사용할까#

공장, 빌딩, 물류 설비, 계측 시스템이나 각종 산업 장비를 다루다 보면 상당히 오래된 Protocol 하나를 계속 만나게 됩니다.

바로 Modbus입니다.

Modbus는 1979년 Modicon에서 산업용 장비 통신을 위해 도입한 Protocol입니다. 지금은 Modbus Organization을 중심으로 관련 사양이 공개되어 있으며 다양한 PLC, 계측기, Sensor, Controller, Gateway에서 지원합니다.

그렇다면 이런 의문이 생깁니다.

이렇게 오래된 Protocol을 왜 아직도 사용하는가?

이유는 의외로 단순합니다.

Modbus의 기본 구조가 비교적 단순하기 때문입니다.

어느 장비에

어떤 데이터를

읽을 것인가?

또는

어떤 값을 쓸 것인가?

이 질문을 Address와 Function Code, Data로 표현합니다.

복잡한 산업 시스템에서도 이 단순한 구조가 매우 유용합니다.

1.1 산업 현장에서는 최신 기술만 사용할 수 없다#

일반적인 Web Service라면 오래된 Protocol을 비교적 쉽게 교체할 수 있습니다.

산업 현장은 다릅니다.

한 번 설치된:

PLC

전력 계측기

온도 Controller

Sensor

Motor Controller

차단기 Controller

가 10년 이상 사용되기도 합니다.

전체 설비를 Protocol 하나 때문에 교체하기는 어렵습니다.

그래서 새 Server와 오래된 장비를 연결해야 하는 상황이 계속 생깁니다.

이런 환경에서 오래전부터 여러 제조사가 지원해온 Modbus는 여전히 실용적인 선택지가 됩니다.

2장 Modbus는 RS-485 자체가 아니다#

가장 먼저 구분해야 할 것이 있습니다.

Modbus
=
RS-485

는 아닙니다.

Modbus는 Application Layer의 Message Protocol이고 RS-485는 전기적인 Serial Interface입니다. 공식 Modbus Application Protocol 역시 Modbus가 TCP/IP와 비동기 Serial 전송 등 서로 다른 Network나 Bus 위에서 구현될 수 있다고 설명합니다.

관계를 단순화하면:

Modbus RTU
        ↓
RS-485 / RS-232 등

Modbus ASCII
        ↓
Serial 통신

Modbus TCP
        ↓
TCP/IP
        ↓
Ethernet 등을 사용하는 Network

처럼 볼 수 있습니다.

따라서:

RS-485를 사용한다.

는 것만으로 Modbus 장비라는 뜻은 아닙니다.

RS-485 위에서 제조사 자체 Binary Protocol을 사용할 수도 있습니다.

3장 Modbus의 기본 구조는 요청과 응답이다#

Modbus의 핵심 동작은 비교적 간단합니다.

Client가 요청합니다.

이 장비의 Register를 읽어줘.

Server가 응답합니다.

현재 값은 125입니다.

전체 흐름:

Modbus Client
      │
      │ Request
      ▼
Modbus Server
      │
      │ Response
      ▼
Modbus Client

공식 Modbus Application Protocol은 이를 Request/Reply Protocol로 정의하며, 수행할 작업은 Function Code로 지정합니다.

3.1 Master·Slave와 Client·Server#

오래된 현장 문서에서는 흔히:

Master
Slave

라는 용어를 볼 수 있습니다.

최근 Modbus 문서와 관련 도구에서는 주로:

Client
Server

를 사용합니다.

기본 개념은:

Client
→ Request를 시작

Server
→ Request를 처리하고 Response

입니다.

따라서 오래된 장비 Manual의 Slave Address와 최신 Software의 Server Address 또는 Device ID가 같은 종류의 개념을 가리키는 경우가 있습니다.

4장 Modbus RTU·ASCII·TCP는 무엇이 다른가#

Modbus를 처음 접하면 가장 먼저 세 가지 이름을 만나게 됩니다.

Modbus RTU

Modbus ASCII

Modbus TCP

기본적인 Application 의미는 비슷하지만 Message를 전달하는 방식이 다릅니다.

4.1 Modbus RTU#

RTU는 Binary 형태의 Serial Frame을 사용합니다.

개념적으로:

[Address]
[Function]
[Data]
[CRC]

형태입니다.

Binary 방식이기 때문에 같은 데이터를 ASCII 문자로 표현하는 것보다 비교적 작은 Frame을 만들 수 있습니다.

RS-485 기반 산업 장비에서 흔히 볼 수 있습니다.

4.2 Modbus ASCII#

Modbus ASCII에서는 Data를 ASCII 문자로 표현합니다.

예를 들어 Binary Byte:

01 03

을 문자 형태로 표현하면:

0103

처럼 전송될 수 있습니다.

Frame은 :로 시작하고 CR/LF로 끝나는 구조를 사용하며 오류 검출에는 LRC를 사용합니다.

사람이 Terminal에서 확인하기 상대적으로 편하지만 같은 정보를 표현할 때 RTU보다 많은 Byte가 필요합니다.

현대 현장에서는 RTU보다 접할 기회가 적은 편입니다.

4.3 Modbus TCP#

Modbus TCP는 Modbus Message를 TCP/IP Network에서 전달합니다.

일반적으로:

Modbus Client
↓
TCP
↓
IP
↓
Ethernet Network
↓
Modbus Server

구조로 사용합니다.

표준적으로 TCP Port 502를 사용합니다.

5장 RTU Frame을 보면 Modbus가 이해되기 시작한다#

Modbus RTU의 기본적인 구조를 단순화하면 다음과 같습니다.

[Device Address]
[Function Code]
[Data]
[CRC]

예를 들어:

01 03 00 00 00 02 C4 0B

이라는 Frame을 생각해봅시다.

구조적으로 보면:

01
→ Device Address

03
→ Function Code

00 00
→ 시작 Address

00 02
→ 읽을 Register 수

C4 0B
→ CRC

처럼 해석할 수 있습니다.

HEX 한 줄도 Field를 분리하면 의미 있는 명령이 됩니다.

5.1 Device Address#

Serial Modbus에서는 대상 장비를 식별할 Address가 필요합니다.

예:

Device 1
Address = 1

Device 2
Address = 2

Device 3
Address = 3

Client가:

01 ...

을 보내면 Address 1인 Device가 처리합니다.

6장 Function Code가 Modbus의 핵심이다#

Modbus에서는 Function Code가 어떤 작업을 할지 결정합니다.

공식 Modbus Application Protocol에는 대표적으로 다음 Function이 정의되어 있습니다.

Function Code 기능
0x01 Read Coils
0x02 Read Discrete Inputs
0x03 Read Holding Registers
0x04 Read Input Registers
0x05 Write Single Coil
0x06 Write Single Register
0x0F Write Multiple Coils
0x10 Write Multiple Registers

예를 들어:

03

은 Holding Register를 읽는 Function입니다.

그래서:

01 03 ...

을 보면:

Device 1에게
Holding Register를 읽어달라는 요청

이라고 해석하기 시작할 수 있습니다.

7장 Coil과 Register가 무엇인가#

Modbus를 이해하려면 네 가지 Data Model을 알아야 합니다.

공식 Modbus Data Model 역시 Coil, Discrete Input, Input Register, Holding Register의 네 영역을 정의합니다.

7.1 Coil#

1 Bit 단위의 Read/Write Data입니다.

개념적으로:

0
→ OFF

1
→ ON

입니다.

예를 들어 장비 제조사가 다음처럼 Mapping할 수 있습니다.

Coil 0
→ Gate Open Command

Coil 1
→ Light ON/OFF

단 실제 의미는 제조사 Register Map에서 확인해야 합니다.

7.2 Discrete Input#

1 Bit 상태값이며 일반적으로 읽기 용도로 사용합니다.

예:

Vehicle Sensor

Door Sensor

Alarm Contact

등을 Mapping할 수 있습니다.

7.3 Input Register#

16 Bit 단위의 읽기용 Data 영역입니다.

예:

온도

전압

전류

Sensor 측정값

등을 표현하는 데 사용할 수 있습니다.

7.4 Holding Register#

16 Bit 단위 Register로 읽기와 쓰기에 널리 사용됩니다.

예:

설정값

Device 상태

Counter

Threshold

운전 Parameter

등을 저장하도록 제조사가 정의할 수 있습니다.

8장 가장 헷갈리는 것이 Register Address다#

Modbus 개발에서 초보자가 자주 만나는 문제가 있습니다.

문서에는:

40001

이라고 되어 있는데 Library에서는:

address=0

을 사용해야 하는 경우입니다.

일부 문서에서 사용하는 4xxxx 표기는 Holding Register 영역을 사람이 쉽게 구분하기 위한 Reference 방식이고 실제 Protocol Address는 0부터 시작할 수 있습니다.

예:

문서 표시
40001

Protocol Address
0
문서 표시
40100

Protocol Address
99

처럼 대응할 수 있습니다. 현재 PyModbus 문서도 이 차이를 명시하고 있습니다.

8.1 무조건 1을 빼면 된다는 뜻은 아니다#

여기서 더 중요한 것이 있습니다.

장비 제조사 Manual이:

40001

방식을 쓰는지:

0
1
2
3

같은 Raw Address 방식을 쓰는지 먼저 확인해야 합니다.

제조사마다 Register Map 표현 방식이 다를 수 있습니다.

따라서 다음을 확인합니다.

Register 번호인가?

Protocol Address인가?

0-based인가?

1-based인가?

Modbus에서 매우 흔한 장애 원인입니다.

9장 Modbus RTU와 ASCII는 오류 검출 방식도 다르다#

9.1 RTU는 CRC#

Modbus RTU Frame에는 CRC가 포함됩니다.

[Address]
[Function]
[Data]
[CRC]

수신 장비는 Frame을 이용해 CRC를 계산하고 전달된 CRC와 비교합니다.

다르면 Frame을 정상 요청으로 처리하지 않습니다.

9.2 ASCII는 LRC#

Modbus ASCII에서는 LRC를 사용합니다.

따라서:

Modbus RTU
→ CRC

Modbus ASCII
→ LRC

라고 기억하면 됩니다.

9.3 Modbus TCP에는 RTU의 CRC Field가 없다#

Modbus TCP에서는 RTU Frame을 단순히 TCP에 그대로 넣는 것이 아닙니다.

Modbus TCP는 MBAP Header를 사용합니다.

개념적으로:

[MBAP Header]
[Function Code]
[Data]

형태입니다.

Serial RTU의 CRC Field를 그대로 붙이지 않습니다.

10장 Modbus TCP의 MBAP Header는 무엇인가#

Modbus TCP를 분석하면 RTU에는 없던 Header가 나타납니다.

MBAP는 Modbus Application Protocol Header입니다.

주요 Field는:

Transaction Identifier

Protocol Identifier

Length

Unit Identifier

입니다.

구조를 단순화하면:

[Transaction ID]
[Protocol ID]
[Length]
[Unit ID]
[Function]
[Data]

입니다.

10.1 Transaction ID#

TCP에서는 여러 요청을 구분할 필요가 있습니다.

Transaction Identifier를 이용하면 Request와 Response를 연결할 수 있습니다.

Request

Transaction ID = 15
Function = 03

Response:

Transaction ID = 15
Function = 03

처럼 Matching할 수 있습니다.

10.2 Unit Identifier#

특히 Modbus TCP와 Serial Modbus 사이에 Gateway가 존재할 때 뒤쪽 Serial Device를 식별하는 용도로 활용될 수 있습니다.

예:

Modbus TCP Client
       │
       ▼
Gateway
       │
       ├─ RTU Device 1
       ├─ RTU Device 2
       └─ RTU Device 3

이런 구조에서 Unit Identifier의 의미가 중요해질 수 있습니다.

11장 주차관제 같은 산업 현장에서는 어떻게 사용할까#

예를 들어 다음 시스템을 생각해보겠습니다.

Central Server
      │
      │ TCP/IP
      ▼
Modbus Gateway
      │
      │ RS-485
      ├── Controller 1
      ├── Controller 2
      └── Controller 3

각 Controller에 다음 상태가 Mapping되어 있다고 가정합니다.

Coil 0
→ Gate Open Command

Discrete Input 0
→ Vehicle Detected

Discrete Input 1
→ Gate Fully Open

Holding Register 0
→ Device Status

Holding Register 1
→ Error Code

Server는 주기적으로 상태를 읽을 수 있습니다.

Read Discrete Inputs

또 필요한 경우 설정값을 읽거나 쓸 수 있습니다.

중요한 점은 Modbus가 Gate나 차량이라는 의미를 정의하는 것은 아니라는 것입니다.

11.1 Register의 업무 의미는 제조사가 정의한다#

Modbus는:

Holding Register를 읽어라.

라는 방법을 정의합니다.

하지만:

Register 100
=
Gate 상태

라고 정해주는 것은 아닙니다.

그 의미는 장비 제조사가 Register Map에서 정의합니다.

그래서 Modbus 장비를 연동할 때 Protocol Specification 못지않게 중요한 문서가:

제조사 Register Map입니다.

12장 RS-485 Modbus RTU 현장에서 무엇을 확인해야 할까#

Modbus RTU가 동작하지 않는다면 Protocol만 봐서는 안 됩니다.

먼저 Serial 설정을 확인합니다.

Baud Rate

Data Bits

Parity

Stop Bits

예:

9600-8-E-1

장비 양쪽 설정이 동일해야 합니다.

12.1 RS-485 배선도 확인한다#

확인 항목:

A / B 또는 D+ / D-

배선 극성

종단저항

Bias

Topology

공통 기준 전위

Shield / Ground

입니다.

특히 A/B 명칭은 제조사마다 표기가 다르게 사용되는 경우가 있으므로 이름만 믿기보다 Manual의 D+, D-, Non-inverting, Inverting 정의까지 확인하는 편이 안전합니다.

12.2 종단저항은 모든 장비에 다는 것이 아니다#

RS-485 Bus에서는 일반적으로 Cable의 특성 임피던스에 맞는 Termination을 전기적 양 끝에 배치하는 방식을 사용합니다.

흔히 약 120Ω이 사용되지만:

모든 Device에 120Ω

을 연결하는 것은 올바른 일반 원칙이 아닙니다.

Cable, Topology, Transceiver와 제조사 권장사항을 확인해야 합니다.

13장 Modbus TCP 장애는 다른 순서로 본다#

Modbus TCP에서는 먼저 Network 계층부터 확인합니다.

IP Address

Subnet Mask

Gateway

VLAN

Routing

TCP Port

Firewall

그리고:

TCP 502 연결 가능

여부를 확인합니다.

그다음 Modbus Application Layer를 확인합니다.

Transaction ID

Unit ID

Function Code

Register Address

Quantity

Exception Response

즉:

Ping 성공

만으로 Modbus가 정상이라고 판단해서는 안 됩니다.

13.1 Port 502가 열려 있어도 Modbus 요청은 실패할 수 있다#

TCP Connection:

CONNECTED

상태더라도:

잘못된 Function Code

잘못된 Register Address

지원하지 않는 Quantity

잘못된 Unit ID

때문에 Modbus 요청은 실패할 수 있습니다.

Network 연결 성공과 Application 요청 성공을 분리해서 판단해야 합니다.

14장 Modbus Exception Response를 읽을 줄 알아야 한다#

Modbus Server가 요청을 정상적으로 수행하지 못하면 Exception Response를 반환할 수 있습니다.

대표적으로:

Illegal Function

Illegal Data Address

Illegal Data Value

Server Device Failure

같은 유형이 있습니다. 공식 Application Protocol은 Function Code별 동작과 함께 Exception Response 체계를 정의합니다.

예를 들어:

FC 03
Read Holding Registers

를 보냈는데 대상 Register가 존재하지 않는다면 Illegal Data Address 계열의 응답을 받을 수 있습니다.

이 경우 계속 Retry한다고 문제가 해결되지는 않습니다.

Register Map을 다시 확인해야 합니다.

15장 Modbus TCP를 Python으로 읽어보자#

현재 PyModbus 문서 기준으로 TCP Client는 다음과 같이 가져올 수 있습니다.

from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient(
    host="192.168.0.100",
    port=502
)

if client.connect():
    result = client.read_coils(
        address=0,
        count=1,
        slave=1
    )

    if not result.isError():
        print(result.bits[0])

client.close()

이 코드는 읽기 예제입니다.

중요한 것은:

address=0

이 제조사 Manual에서 어떤 Coil을 의미하는지 확인하는 것입니다.

15.1 Holding Register 읽기#

예:

from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient("192.168.0.100", port=502)

if client.connect():
    result = client.read_holding_registers(
        address=0,
        count=2,
        slave=1
    )

    if not result.isError():
        print(result.registers)

client.close()

Function Code로 보면:

03
Read Holding Registers

에 해당합니다.

실제 현장에서는 Timeout과 예외 처리, Connection 복구 등을 함께 구현해야 합니다.

16장 Register 두 개를 읽었다고 바로 값이 되는 것은 아니다#

Modbus Register 하나는 기본적으로 16 Bit입니다.

32-bit Integer나 Float를 표현하려면 두 Register를 사용할 수 있습니다.

예:

Register 100
12 34

Register 101
56 78

그런데 문제는 순서입니다.

장비에 따라:

12 34 56 78

일 수도 있고:

56 78 12 34

일 수도 있습니다.

Byte Order뿐 아니라 Word Order까지 확인해야 할 수 있습니다.

16.1 Float 해석 오류가 자주 발생하는 이유#

예를 들어 장비에는:

25.5°C

가 저장되어 있는데 Application에서:

-0.00000001

같은 이상한 값이 나온다고 하겠습니다.

가능한 원인:

Register Address 오류

Data Type 오류

Byte Order 오류

Word Order 오류

Scale 적용 오류

입니다.

Modbus 자체가 이 두 Register는 IEEE 754 Float이다라고 자동으로 알려주는 것이 아닙니다.

제조사 Register Map을 확인해야 합니다.

17장 Serial-to-Ethernet Gateway에서는 더 조심해야 한다#

현장에서는 오래된 Modbus RTU 장비를 Network에 연결하기 위해 Gateway를 많이 사용합니다.

Server
  │
  │ Ethernet
  ▼
Serial-to-Ethernet Gateway
  │
  │ RS-485
  ▼
Modbus RTU Device

이때 장애 지점이 하나 더 늘어납니다.

Server

TCP Network

Gateway

Serial 설정

RS-485 Bus

Device

중 어느 곳에서든 문제가 생길 수 있습니다.

17.1 Gateway가 있다고 반드시 Modbus TCP는 아니다#

중요한 구분입니다.

어떤 Serial-to-Ethernet 장비는 단순히:

TCP Byte Stream
↔
Serial Byte Stream

을 변환하는 Transparent Mode로 동작합니다.

이 경우 TCP 안으로 Modbus RTU Frame이 그대로 전달될 수도 있습니다.

다른 Gateway는:

Modbus TCP
↔
Modbus RTU

를 실제로 변환합니다.

둘은 전혀 다른 구조이므로 Gateway Mode를 확인해야 합니다.

18장 Timeout과 Polling 주기를 잘못 잡으면 시스템이 느려진다#

Modbus는 상태를 주기적으로 읽는 Polling 방식으로 많이 사용됩니다.

예:

Device 1 조회
↓
Device 2 조회
↓
Device 3 조회
↓
Device 4 조회
↓
다시 Device 1

장비 하나가 응답하지 않으면 Timeout만큼 기다립니다.

예를 들어:

Timeout
2초

Offline Device
10대

라면 전체 Polling Cycle이 크게 느려질 수 있습니다.

18.1 Retry를 많게 하는 것이 항상 안정적인 것은 아니다#

예:

Timeout 2초
Retry 3회

라면 Offline Device 하나 때문에 상당한 시간이 소비될 수 있습니다.

특히 하나의 RS-485 Bus에 여러 장비가 연결되어 있다면 다른 장비 Polling까지 늦어집니다.

따라서:

Timeout

Retry

Polling Interval

Offline Device 처리

를 함께 설계해야 합니다.

19장 왜 현장에서는 결국 Modbus를 계속 사용하게 될까#

Modbus가 최신 Protocol보다 모든 면에서 뛰어나기 때문은 아닙니다.

오히려 기능적으로는 단순합니다.

그런데 산업 현장에서는 그 단순함이 장점이 됩니다.

Protocol 구조가 비교적 단순

많은 제조사가 지원

PLC·Sensor·Meter 등 장비가 풍부

Serial과 TCP 환경 모두 존재

Gateway 제품이 많음

Troubleshooting 자료가 풍부

그리고 가장 중요한 것은:

이미 설치된 수많은 장비가 Modbus를 사용하고 있다는 사실입니다.

그래서 새로운 시스템에서도 기존 설비와 연결하기 위해 Modbus 지원이 필요해집니다.

20장 Modbus가 모든 상황에 좋은 것은 아니다#

Modbus에는 한계도 있습니다.

기본적인 Modbus Protocol은:

사용자 인증

권한 관리

암호화

를 기본 기능으로 제공하도록 설계된 Protocol이 아닙니다.

따라서 일반 Modbus TCP를 신뢰할 수 없는 Network에 그대로 노출하는 것은 적절하지 않습니다.

20.1 Modbus Security도 존재한다#

현재 Modbus Organization은 기존 Modbus에 TLS를 결합한 Modbus Security Protocol도 제공합니다.

Modbus Security는 TLS를 통해 인증과 Message Integrity 보호를 제공하고 X.509v3 인증서를 이용한 Client·Server 인증을 정의하며 Port 802를 사용합니다.

하지만 실제 산업 현장에는 기존 Modbus TCP 장비도 매우 많습니다.

따라서 현실적인 보안에서는:

Network 분리

Firewall

VLAN

ACL

VPN

Gateway

접근 통제

같은 대책도 함께 사용합니다.

21장 Modbus 장애를 계층별로 나누면 빨리 찾을 수 있다#

Modbus RTU#

1. 전원
↓
2. RS-485 배선
↓
3. A/B 극성
↓
4. 종단·Bias
↓
5. Baud / Parity / Stop Bit
↓
6. Device Address
↓
7. Function Code
↓
8. Register Address
↓
9. CRC
↓
10. Application Data 해석

Modbus TCP#

1. Link
↓
2. IP
↓
3. VLAN / Routing
↓
4. TCP Port
↓
5. Connection
↓
6. Unit ID
↓
7. Function Code
↓
8. Register Address
↓
9. Exception Response
↓
10. Application Data 해석

Modbus가 안 된다라는 한 문장을 이렇게 분해하면 진단이 훨씬 쉬워집니다.

22장 현장에서 자주 하는 잘못된 판단#

Modbus는 RS-485 Protocol이다#

아닙니다.

Modbus는 Application Protocol이며 Serial과 TCP/IP 등 여러 방식으로 사용할 수 있습니다.

Modbus RTU는 무조건 RS-485다#

RS-485에서 매우 흔하지만 Modbus Serial 통신 자체를 RS-485 하나로만 제한해서 이해하면 안 됩니다.

Register 40001을 Library에 40001이라고 넣으면 된다#

Library가 Protocol Address를 요구한다면 0을 넣어야 할 수도 있습니다.

주소 표기 방식을 반드시 확인해야 합니다.

TCP 502가 열려 있으면 Modbus가 정상이다#

Network Connection과 Modbus 요청 성공은 다른 문제입니다.

Modbus TCP에는 RTU CRC가 그대로 붙는다#

일반적인 Modbus TCP ADU에서는 Serial RTU CRC를 사용하지 않습니다.

CRC Error면 CRC Algorithm이 잘못됐다#

Noise나 Serial 설정 문제로 Byte가 손상된 결과일 수도 있습니다.

Modbus TCP는 TCP니까 안전하다#

TCP는 암호화를 의미하지 않습니다.

Register 값은 Modbus가 의미까지 정의한다#

Modbus는 Data Model과 접근 방법을 정의하지만 실제 Register가 무엇을 의미하는지는 제조사 Device Map이 정의합니다.

23장 현장 점검 체크리스트#

□ Modbus RTU·ASCII·TCP 중 어떤 방식인가?

□ Serial인가 TCP/IP인가?

□ Device Address 또는 Unit ID는 무엇인가?

□ Baud Rate는 같은가?

□ Data Bit·Parity·Stop Bit는 같은가?

□ RS-485 A/B 배선은 제조사 정의와 일치하는가?

□ 종단과 Bias 구성이 적절한가?

□ Function Code는 무엇인가?

□ Coil·Register Address가 맞는가?

□ 주소가 0-based인지 1-based인지 확인했는가?

□ Data Type을 확인했는가?

□ Byte Order를 확인했는가?

□ Word Order를 확인했는가?

□ Scale 값을 확인했는가?

□ RTU라면 CRC가 정상인가?

□ TCP라면 Port와 Firewall을 확인했는가?

□ Exception Response를 확인했는가?

□ Gateway가 Transparent Mode인지 Protocol 변환 방식인지 확인했는가?

□ Timeout과 Retry가 적절한가?

□ Network 보안 대책이 적용되어 있는가?

24장 자기 점검#

Modbus RTU와 Modbus TCP의 가장 큰 차이는 무엇인가#

Modbus Application의 기본적인 Function과 Data Model은 공유하지만 전달 방식과 Frame 구조가 다릅니다. RTU는 Serial Line에서 Binary Frame과 CRC를 사용하고, Modbus TCP는 TCP/IP와 MBAP Header를 사용합니다.

Coil과 Holding Register의 차이는 무엇인가#

Coil은 1 Bit 단위의 Read/Write Data이고 Holding Register는 16 Bit 단위의 Read/Write Data 영역입니다.

Function Code 03은 무엇인가#

Holding Register를 읽는 Read Holding Registers입니다.

문서에 40001이라고 되어 있는데 왜 코드에서는 address=0을 사용할 수 있는가#

문서의 Register Reference 표기와 실제 Protocol Address가 서로 다를 수 있기 때문입니다. 제조사 Manual과 Library의 Address 방식을 모두 확인해야 합니다.

Modbus TCP가 연결되어 있으면 장비가 정상인가#

아닙니다. TCP Connection이 정상이어도 Unit ID, Function Code, Register Address 또는 장비 내부 상태 때문에 Modbus 요청이 실패할 수 있습니다.

25장 이 글을 마치며#

Modbus는 오래된 Protocol입니다.

하지만 단순히 오래됐다는 이유만으로 사라지지 않습니다.

산업 현장에서 중요한 것은:

가장 최신인가?

보다:

기존 장비와 연결할 수 있는가?

구조를 쉽게 이해할 수 있는가?

현장에서 진단할 수 있는가?

여러 제조사가 지원하는가?

인 경우가 많기 때문입니다.

Modbus의 전체 구조를 정리하면:

Client
↓
Request
↓
Device / Unit Address
↓
Function Code
↓
Coil / Register
↓
Server
↓
Response 또는 Exception

으로 이해할 수 있습니다.

그리고 전송 환경에 따라:

Modbus RTU
→ Serial + Binary Frame + CRC

Modbus ASCII
→ Serial + ASCII 표현 + LRC

Modbus TCP
→ TCP/IP + MBAP Header

로 구분할 수 있습니다.

특히 다음 다섯 가지를 기억하면 됩니다.

Modbus는 RS-485 자체가 아니라 장비가 데이터를 읽고 쓰기 위한 Application Protocol입니다.

Modbus RTU·ASCII·TCP는 같은 계열이지만 Frame 구성과 전달 방식이 다릅니다.

Modbus를 이해하려면 Function Code와 Coil·Discrete Input·Input Register·Holding Register의 관계를 알아야 합니다.

Register 주소 표기와 실제 Protocol Address가 다를 수 있으므로 0-based·1-based 문제를 반드시 확인해야 합니다.

Modbus 통신 장애는 Protocol만 볼 것이 아니라 RS-485 배선부터 TCP Network, Address, Function Code, Register Mapping까지 계층별로 추적해야 합니다.

결국 Modbus를 이해하는 핵심은 HEX 값을 암기하는 데 있지 않습니다.

어느 장비에 어떤 Function Code를 보내 어떤 Coil 또는 Register를 읽고 쓰는지를 이해하고, 그 요청과 응답이 Serial 또는 TCP 환경에서 어떻게 전달되는지를 추적할 수 있는 것이 핵심입니다.

이 페이지의 목차