“설비 상태를 사무실 PC에서도 보고 싶습니다.” 현장 설비를 웹으로 올리는 일은 대부분 이 한 문장으로 시작합니다. 함께 받는 자료는 설비 사진 몇 장과 모델명 목록이 전부인 경우가 많습니다. 담당자는 화면에 어떤 그래프를 넣을지부터 이야기하고 싶어 합니다.
그런데 화면은 이 프로젝트에서 가장 나중에 정해도 되는 부분입니다. 값이 어디서 어떤 형태로 나오는지가 비어 있으면 견적의 절반은 추측이 됩니다. 견적서를 쓰기 전에 설비 업체에 먼저 물어야 할 항목이 있습니다.
첫 질문은 Modbus RTU인지 TCP인지입니다
같은 Modbus라도 RTU와 TCP는 전혀 다른 공사입니다. RTU는 RS-485 시리얼 선으로 통신하고, TCP는 이더넷 케이블과 502번 포트를 씁니다. Modbus 조직이 배포하는 규격 문서도 응용 프로토콜, 시리얼 회선용, TCP/IP용으로 나뉘어 있습니다.
RTU라는 답을 받으면 시리얼 신호를 이더넷으로 바꿔 줄 게이트웨이가 한 대 더 필요합니다. 배선 경로와 통신 속도까지 같이 물어야 합니다. TCP라면 설비에 IP 주소가 이미 부여됐는지, 사무실 망과 연결이 되는지를 확인하세요.
이 한 줄이 정해지지 않으면 하드웨어 비용과 현장 작업 일정이 통째로 미정입니다.
레지스터 맵 문서를 주는지 반드시 확인하세요
레지스터 맵은 몇 번 주소에 어떤 값이 들어 있는지를 적어 둔 표입니다. 이 문서가 없으면 개발이 아니라 해독 작업이 됩니다. 값이 245로 읽혔을 때 24.5도인지 245도인지 판단할 근거가 없기 때문입니다.
문서를 준다고 할 때도 세 가지를 같이 물어보세요. 값의 데이터 타입, 소수점 배율, 두 칸으로 나뉜 값의 순서입니다. 이 셋 중 하나만 빠져도 현장에서 값을 대조하는 일정이 한 번 더 생깁니다.
레지스터 맵 문서 한 장의 유무가 개발 기간을 며칠 단위로 바꿉니다.
폴링 주기는 초 단위 숫자로 받아 적으세요
“실시간으로 보고 싶다”는 요구는 견적에 쓸 수 없습니다. 1초인지 5초인지 1분인지를 숫자로 받아야 합니다. 이 숫자가 통신 속도, 설비 대수와 곧바로 충돌하기 때문입니다.
계산해 보면 이유가 분명해집니다. 9600bps에서 1바이트를 보내는 데 약 1ms가 걸립니다. 레지스터 20개를 읽으면 요청 8바이트와 응답 45바이트에 프레임 사이 유휴 시간까지 한 번에 60ms 안팎이 듭니다. 설비 20대를 차례로 돌면 1.2초가 넘습니다.
같은 요청을 115200bps로 하면 한 대당 5ms 수준이라 20대를 0.1초대에 돌 수 있습니다. 그래서 지금 통신 속도가 얼마인지, 올릴 수 있는지까지 물어야 합니다.
동시 접속 제한은 사양서에 숫자로 적혀 있습니다
설비와 게이트웨이는 동시에 붙을 수 있는 상대의 수가 정해져 있습니다. Moxa MGate MB3180은 동시 16개의 Modbus TCP 마스터와 마스터당 32개 요청을 지원합니다. 다만 IP나 TCP 포트로 시리얼 포트를 나누는 설정에서는 4개로 줄어듭니다.
Advantech EKI-1221은 시리얼 포트당 클라이언트 모드에서 16개 연결, 서버 모드에서 32개 세션을 허용합니다. 숫자만 보면 넉넉하지만, 이미 HMI와 상위 시스템이 그 자리를 쓰고 있는 현장이 많습니다.
그래서 제한이 몇 개인지와 지금 몇 개가 쓰이고 있는지를 함께 물어야 합니다. 남은 자리가 없으면 게이트웨이를 한 대 더 사는 비용이 견적에 들어갑니다.
통신 포트가 비어 있는지 물어야 합니다
PLC의 시리얼 포트는 이미 HMI가 쓰고 있는 경우가 흔합니다. 이때 선택지는 기존 RS-485 라인에 함께 물리거나, 통신 모듈을 증설하는 것입니다. 두 방법은 비용과 위험이 다릅니다.
같은 라인에 물리면 하드웨어 비용은 들지 않지만 폴링이 서로 밀립니다. 모듈을 증설하면 PLC를 세워야 하므로 라인 정지 일정을 잡아야 합니다. 이 일정 협의가 개발 기간보다 오래 걸리는 현장도 있습니다.
Modbus 시리얼 회선의 슬레이브 주소는 1번부터 247번까지입니다. 다만 게이트웨이가 실제로 감당하는 대수는 그보다 적어서, MB3180은 시리얼 포트당 31대입니다.
답이 없으면 규격 파악 단계에서부터 비용이 붙습니다
앞의 네 가지가 비어 있으면 견적을 낼 수 없어 조사부터 유상 작업이 됩니다. 현장에 나가 통신선을 확인하고, 실제로 값을 한 번 읽어 보는 일입니다. 왕복 이동과 라인 정지 대기까지 더하면 하루가 그냥 지나갑니다.
조사 없이 견적을 내면 개발사는 최악의 경우를 가정합니다. RTU일 수 있으니 게이트웨이 비용을 넣고, 문서가 없을 수 있으니 해독 공수를 얹습니다. 고객 입장에서는 이유를 알 수 없이 비싼 견적서를 받게 됩니다.
견적을 흔드는 것은 화면 개수가 아니라 통신 규격의 공백입니다.
질문지는 한 장으로 만들어 보내세요
설비 업체는 대개 이 질문에 답할 수 있습니다. 문제는 무엇을 물어야 하는지 모른 채 “데이터를 뽑을 수 있나요”라고만 묻는 데 있습니다. 아래 항목을 그대로 옮겨 메일로 보내면 보통 며칠 안에 회신이 옵니다.
- Modbus RTU입니까, Modbus TCP입니까 (RTU면 통신 속도와 패리티 설정)
- 레지스터 맵 문서를 제공해 주실 수 있습니까
- 데이터 타입과 배율, 값의 순서가 그 문서에 적혀 있습니까
- 권장 폴링 주기와 최소 주기는 몇 초입니까
- 동시에 접속할 수 있는 마스터는 몇 개입니까
- 그중 몇 개를 지금 HMI나 다른 시스템이 쓰고 있습니까
- 추가로 연결할 통신 포트가 남아 있습니까
- 연결 작업 때 설비를 세워야 합니까
회신 내용이 그대로 견적의 근거가 됩니다. 답이 오지 않은 항목은 위험 요소로 따로 적어 두세요.
이 질문지가 맞지 않는 설비도 있습니다
모든 설비가 Modbus를 쓰지는 않습니다. OPC UA나 EtherNet/IP를 쓰는 설비도 있고, 제조사 전용 프로토콜만 여는 설비도 있습니다. 접점과 아날로그 출력만 나오는 오래된 설비 역시 현장에 많습니다.
이때는 질문 항목이 통째로 달라집니다. 신호를 디지털로 바꿀 변환기부터 정해야 하고 비용 구조도 다릅니다. 첫 질문을 프로토콜 확인부터 시작해야 하는 이유가 여기에 있습니다.
레지스터 맵을 외부에 공개하는지는 제조사 정책과 계약 조건에 달려 있어 일반화할 수 없습니다. 유지보수 계약이 있는 곳에만 준다는 답을 받기도 합니다.
문서를 받아도 값 하나는 직접 읽어 봐야 합니다
문서와 실제 장비가 어긋나는 일은 드물지 않습니다. 펌웨어 버전이 다르거나, 주소를 1부터 세는 문서와 0부터 세는 장비가 섞이기 때문입니다. 값 한 점만 읽어 봐도 이 차이는 바로 드러납니다.
그래서 본 개발에 들어가기 전에 반나절짜리 연결 시험을 따로 잡는 편이 낫습니다. 여기서 규격이 확정되면 나머지 일정은 흔들리지 않습니다.
비슷한 판단 기준은 실무 가이드와 개발 노트에 정리해 두었습니다. 규격 문서는 Modbus 공식 규격 페이지에서 받을 수 있고, 구축 문의는 Codeforest로 주시면 됩니다.
결론: 화면보다 통신 규격을 먼저 확정하세요
설비 데이터를 웹으로 올리는 일의 난이도는 대시보드가 아니라 통신 구간에서 결정됩니다. RTU인지 TCP인지, 레지스터 맵 문서가 있는지, 폴링 주기와 동시 접속 여유가 얼마인지가 견적의 뼈대입니다. 이 네 가지 답을 들고 오면 개발사는 하루 안에 숫자를 낼 수 있습니다.
답이 없는 자리는 조사 비용과 예비비로 채워집니다. 설비 업체에 메일 한 통 보내는 일이 견적의 폭을 크게 줄입니다. 화면 이야기는 그 다음에 해도 늦지 않습니다.
