Modbus 실전 연동: 레지스터 맵부터 폴링 용량 산정까지

산업 현장과 IT 시스템을 잇는 필드버스 프로토콜 중 Modbus(모드버스)는 1979년 Modicon(현 Schneider Electric)이 제정한 이래 PLC, HMI, 계량기, 센서 등 OT 장비의 사실상 표준으로 자리잡았다. IIoT·SCADA·BMS/EMS 통합과 데이터 수집 파이프라인에 그대로 적용할 수 있다.

데이터 모델과 전송 방식

Modbus는 요청-응답 기반의 애플리케이션 계층 프로토콜로, 데이터 모델(코일/레지스터)과 함수 코드(Function Code)로 동작한다. 전송 계층으로는 시리얼(RTU/ASCII) 또는 TCP를 쓴다.

데이터 모델은 네 가지로 나뉜다. Coils(0xxxx)는 1비트 R/W 출력, Discrete Inputs(1xxxx)는 1비트 R 전용 입력, Input Registers(3xxxx)는 16비트 R 전용, Holding Registers(4xxxx)는 16비트 R/W다. 주소는 PDU 기준 0-기반이지만 전통적 문서 표기는 1-기반(예: 40001 ↔ PDU 주소 0)을 혼용한다.

전송 형식은 Modbus RTU/ASCII(Serial, RS-485/232 기반, 현장 배선 최적)와 Modbus TCP(이더넷/IP 기반, 포트 502, MBAP 헤더 포함)로 나뉜다.

주소 체계와 전송 방식 선택

기능별 주소 영역이 분리돼 있고 기능 코드로 접근을 제어한다. 다중 비트·레지스터 일괄 읽기/쓰기가 가능하지만 최대 전송량 제한이 있다 — Read Holding/Input Registers(0x03/0x04)는 최대 125 레지스터, Read Coils(0x01)는 최대 2000 비트가 권장 상한이다. 정수·실수(32/64비트) 표현 시에는 워드/바이트 오더 정의가 필요해 장치별 문서 확인이 필수다.

RTU는 이진 프레임+CRC로 대역 효율이 우수하지만 케이블·종단·접지 품질에 민감해 장거리·소규모 노드에 적합하다. ASCII는 텍스트 프레임+LRC로 가시성은 높으나 효율이 낮아 유지보수 특수 목적에나 쓴다. TCP는 이더넷·스위칭으로 확장이 쉽고 멀티 세션·다중 마스터가 가능하며 MBAP 헤더로 Unit ID를 쓴다.

프레임 구조와 통신 패턴

PDU는 Function Code + Data로 구성되며, RTU/ASCII는 CRC/LRC를 포함한 ADU, TCP는 MBAP(Header: Transaction ID, Unit ID 등) + PDU 형태를 취한다. 요청-응답 시퀀스가 기본이고, 예외 응답은 Function Code에 0x80을 OR 연산해 표시한다. 브로드캐스트(Unit ID=0, RTU/ASCII)는 쓰기 명령에 한해 허용되며 응답이 없어 신중하게 써야 한다.

전통적으로는 마스터/슬레이브, 현대 용어로는 클라이언트/서버 구조이며 단일 마스터 폴링 패턴이 일반적이다. TCP는 다중 클라이언트의 동시 접근이 가능하지만 장치 처리 큐에 제한이 있어 충돌 방지를 위한 폴링 간격·타임아웃 설계가 필요하다.

인증·암호화가 없고 재전송·순서 보장 외의 고급 신뢰성 기능도 제한적이다. 네트워크 분리, 방화벽 포트·기능 코드 화이트리스트, VPN/TLS 터널링, 게이트웨이 프록시, 읽기 전용 접근 우선이 보안 모범사례로 꼽힌다.

실무 적용: 데이터 수집부터 테스트까지

공정 데이터 수집(PLC/계량기)은 장치 리스트업 → 레지스터 맵 정규화 → 폴링 그룹(주소 연속성 기준) 설계 → 게이트웨이/드라이버 설정 → 타임아웃/리트라이 튜닝 순으로 진행한다. 산출물로는 태그 정의서, 주소·스케일·단위, 워드/바이트 오더, 품질 상태 코드 매핑이 나온다.

SCADA·IIoT 게이트웨이 설계에서는 Modbus Client → 수집 버퍼 → 변환(OPC UA/MQTT) → 백엔드(Time-series DB)의 메커니즘을 따른다. Nagle·크기 기반 패킷 결합, 백프레셔 제어, 장치 보호를 위한 최대 QPS 제한을 고려해야 한다.

BMS/EMS 통합에서는 전력·설비 계측기의 Holding/Input Register를 일괄 폴링하고 알람 코일 이벤트를 매핑한다. 펌웨어 버전별 레지스터 맵 차이를 관리하고 변경 이력을 버전드 스키마로 남겨야 한다.

테스트·시뮬레이션에는 modpoll/mbpoll, diagslave, pymodbus 같은 도구를 쓴다. 가짜 디바이스로 폴링 부하·타임아웃 시나리오를 검증하며 응답율, 평균·95퍼센타일 지연, 예외 코드 분포, 손실·CRC 오류 비율을 관찰 지표로 삼는다.

요청→처리→응답 절차

⤢✕

전송 방식 비교

전송 방식	성능(지연/처리량)	확장성(노드/배선)	일관성(프레이밍)	안정성(오류 복원)	운영 편의
RTU	이진 프레임, 대역 효율 우수, 수 ms~수십 ms	RS-485 멀티드롭, 배선 제약	엄격한 타이밍·간격	CRC 검증, 전기적 노이즈 영향	장거리 저비용, 종단/접지 관리 필요
ASCII	텍스트 기반, 효율 낮음	제한적, 디버깅 용이	가독성 높음	LRC 검증, 지연 증가	트러블슈팅 용이, 권장도 낮음
TCP	LAN 성능, 병렬 연결 가능	스위칭/라우팅로 수천 노드	MBAP 헤더 일관성	TCP 재전송/흐름제어	배포/모니터링 용이, IT 통합 최적

예외 처리와 신뢰성 설계

예외 코드는 01 Illegal Function, 02 Illegal Data Address, 03 Illegal Data Value, 04 Slave Device Failure, 05 Acknowledge, 06 Slave Device Busy 등으로 정의돼 있다. 재시도 정책은 지수 백오프, 최대 재시도, 회로 차단기(연속 실패 시 쿨다운), 우회·격리를 조합한다. 폴링 설계는 연속 주소 그룹화(125 레지스터 단위), 읽기·쓰기 분리, 장치당 QPS 상한, 타임슬라이스 스케줄링을 기본으로 한다.

폴링 용량 산정 예시

Modbus TCP, 왕복 지연 5ms, 장치 10대, 장치당 1,000 Holding Registers 수집을 가정하면, 125 레지스터/요청 단위로 그룹화할 때 장치당 8회 요청이 필요해 전체 80회 요청/사이클이 된다. 이를 계산하면 80 × 5ms = 400ms에 처리 오버헤드(20~30%)를 더해 사이클당 약 0.5초가 된다. 병렬 세션 2개를 쓰면 사이클당 약 0.25초로 줄어드는데, 실제 값은 장치 처리 큐와 네트워크 품질에 의존한다.

보안·아키텍처 트레이드오프

네트워크 분리·세그멘테이션(OT VLAN, L3 방화벽, 502/TCP 최소 포트 허용)은 공격면을 줄이지만 운영 복잡성을 늘린다. 게이트웨이 프록시는 단일 수집 지점에서 캐싱·필터링과 Function Code 화이트리스트를 적용해 중앙 통제를 가능케 하지만, 장애 단일점(SPOF) 리스크가 있어 이중화가 필요하다. Modbus TCP 자체에는 암호화가 없어 IPsec·VPN·TLS 터널(stunnel)로 기밀성·무결성을 확보해야 하는데, 이는 레이턴시·운영 비용 증가로 이어진다. 권한·변경 통제는 쓰기 금지 또는 점진적 허용, 변경 로그·전자서명으로 안전성을 높이지만 반영 지연이라는 비용을 수반한다.

현장 적용 절차

요구 분석 단계에서 태그 목록, 수집 주기, SLA(지연·가용성)를 정의한다. 주소·데이터 정합 단계에서는 레지스터 맵을 정규화하고 스케일·엔디언·품질 코드를 문서화한다. 구현 단계에서는 드라이버·게이트웨이를 설정하고 병렬 세션 수, 타임아웃·재시도를 조정한다. 검증 단계에서는 시뮬레이터·샘플 장치로 포화·장애 시나리오를 테스트한다. 운영 단계에서는 응답율·지연·예외율을 모니터링하고 변경 관리·보안 점검을 주기화한다.

Python(pymodbus)로 Modbus TCP 읽기/쓰기

환경: Python 3.10+, pip install "pymodbus>=3.5", 네트워크 접근 가능, 장치 Unit ID 확인.

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusIOException

HOST, PORT, UNIT = "192.168.1.50", 502, 1

client = ModbusTcpClient(host=HOST, port=PORT, timeout=3.0)
if not client.connect():
    raise RuntimeError("Modbus TCP 연결 실패")

try:
    # Holding Registers 읽기: 주소 0부터 10개 (문서의 40001~40010에 해당)
    rr = client.read_holding_registers(address=0, count=10, unit=UNIT)
    if rr.isError():
        print(f"읽기 예외: {rr}")
    else:
        print(f"레지스터 값: {rr.registers}")

    # Coil 쓰기: 주소 5를 ON
    wr = client.write_coil(address=5, value=True, unit=UNIT)
    if wr.isError():
        print(f"쓰기 예외: {wr}")
finally:
    client.close()

32·64비트 값을 디코딩할 때는 BinaryPayloadDecoder로 엔디언·워드 순서를 지정해야 한다. 장치 문서의 워드 오더(예: AB CD 또는 BA DC)를 반드시 확인한다.

전송 방식과 폴링 전략을 표준화한 뒤 확장한다

Modbus는 단순한 데이터 모델과 광범위한 장치 호환성 덕에 OT·IT 통합의 기본 도구로 쓰인다. 성패는 전송 방식(RTU/TCP)과 폴링 전략, 예외 처리·보안 통제의 표준화에 달려 있다. 레지스터 맵 정규화, 그룹화 폴링, 네트워크 분리·프록시·터널링을 적용한 아키텍처를 권장하며, 파일럿 → 표준 템플릿 → 확장 순서로 도입하는 편이 리스크가 적다.