원격 배수장 수위·펌프 데이터를 MQTT로 잇는 운영 설계 기준

먼저 결론부터 볼게요

원격 배수장 데이터를 모을 때는 수위 현재값 하나보다 수위가 언제 바뀌었고, 어느 펌프가 실제로 운전했으며, 수문 상태가 무엇이었는지를 같은 시간축에 놓는 일이 먼저예요. 중앙 화면에 숫자가 보이는 것과 운영 판단에 쓸 수 있는 이력이 만들어진 것은 다르기 때문이에요.

행정안전부는 실제 배수펌프 가동 기록과 방류하천·유수지의 수위 차를 분석해 가동 기준을 조정·보완했다고 설명해요. 결국 원격 모니터링의 핵심은 한 번의 정상값이 아니라 수위, 운전, 정지, 통신 상태가 이어진 기록이에요. 이 기록이 있어야 현장 방문이 필요한 지점과 시간을 좁힐 수 있어요.

시간과 상태를 먼저 맞춰요

데이터 흐름은 수위센서와 펌프 제어반, PLC, 현장 연결 계층, 전송망, 중앙 운영 계층으로 나눠 보세요. Modbus TCP로 읽을 주소마다 설비 ID, 측정 항목, 원시값, 변환값, 단위, 현장 수집 시각, 서버 도착 시각, 품질 상태를 정하면 구간별 값을 비교하기 쉬워요.

펌프 운전 신호는 켜짐과 꺼짐만 저장하지 말고 상태가 바뀐 시각을 남겨야 해요. 수위도 현재값과 함께 마지막 정상 수신 시각을 봐야 실제 수위가 유지되는 상황과 통신이 멈춘 상황을 구분할 수 있어요. 수문 개도나 제어반 이상처럼 현장마다 주소 정의가 다른 값은 정확한 PLC 프로그램과 도면을 기준으로 확인해야 해요.

이 단계의 목표는 제어가 아니라 읽기 검증이에요. 현장 표시값, PLC 모니터 값, 수집된 값, 중앙 수신값을 같은 시각에 나란히 적으면 배율 문제와 네트워크 문제를 섞지 않을 수 있어요.

MQTT와 대안을 나눠 봐요

EASY-LINK는 Modbus RTU/TCP 장비와 PLC 데이터를 수집해 MQTT, HTTP API, MySQL, Firebase로 전달하는 산업용 IoT 게이트웨이예요. 배수장 한 곳의 수위센서와 제어반 데이터를 기존 중앙 서버로 잇는 데이터 연동이 목적이라면 EASY-LINK 중심으로 작은 범위를 먼저 구성할 수 있어요.

수위센서와 펌프 제어반에서 읽은 값이 현장 연결 계층을 거쳐 여러 전달 대상으로 나뉘는 흐름이에요.

주 전달 경로는 여러 배수장의 상태를 비동기로 모으기 쉬운 MQTT로 잡을 수 있어요. 다만 목적지 시스템의 수신 방식과 운영 책임에 따라 HTTP API나 MySQL이 더 단순할 수 있고, 웹·모바일 화면과 빠르게 연결해야 할 때는 Firebase를 검토할 수 있어요. 한 방식이 늘 우월한 것은 아니에요.

판단 질문	MQTT	HTTP API	MySQL	Firebase
여러 지점이 동시에 보내나요	발행자와 구독자를 나누기 좋아요	수신 주소와 응답 규칙이 필요해요	저장 스키마가 먼저예요	화면 연동 구조를 먼저 봐요
성공을 무엇으로 보나요	연결·발행·구독을 나눠요	응답과 업무 처리를 나눠요	쓰기와 조회를 나눠요	쓰기와 화면 반영을 나눠요
끊긴 뒤 무엇을 정하나요	재연결과 중복 기준이에요	재시도 키와 대기열 책임이에요	고유키와 재저장 기준이에요	연결 복구와 보관 정책이에요

MQTT를 쓴다면 토픽에 현장, 설비, 측정 항목을 구분하되 계정 정보는 넣지 마세요. 같은 기록이 다시 도착해도 중복되지 않도록 설비 ID, 측정 시각, 항목을 조합한 식별 기준도 정해 두는 편이 좋아요.

운영 계층은 따로 봐요

현장 수가 늘면 값 자체보다 마지막 수집 시각, 저장 성공, 전달 대기, 재시도 결과를 함께 봐야 해요. EASY LOGGER는 여러 PLC와 EASY 장치의 통합 수집, 수집 주기, 저장 이력, 전달 상태 관리와 대시보드 구성을 맡는 운영 계층이에요. 현장 연결 장비 하나가 이 운영 범위까지 모두 맡는 구조로 보면 안 돼요.

연결 변환과 한 목적지 전송만 필요하면 EASY-LINK만으로 충분한지 먼저 볼 수 있어요. 여러 원격지 설비의 이력을 한 기준으로 저장하고 담당자가 전달 상태까지 확인해야 한다면 EASY LOGGER를 함께 검토하면 좋아요. 두 제품을 무조건 함께 써야 하는 것은 아니며, 현장 연결과 중앙 운영 중 어느 책임이 필요한지로 구분하면 돼요.

대시보드에는 큰 수위 숫자만 두기보다 마지막 수신 시각, 펌프별 운전 전환 시각, 연속 무수신, 수문 상태, 데이터 품질을 함께 배치해요. 화면은 원인을 자동으로 확정하는 도구가 아니라 현장 점검이 필요한 지점과 시간을 좁히는 도구로 보는 편이 안전해요.

상위 시스템은 경계를 정해요

MES·CIM이나 기관의 중앙 물관리 시스템과 연결할 때는 MQTT, HTTP API 또는 DB 인터페이스 중 실제로 제공되는 통신 경계를 먼저 확인해야 해요. 필드 이름, 단위, 타임스탬프 기준, 결측 표현, 중복 방지 키, 실패 응답, 재전송 책임을 양쪽이 같은 표로 확인하면 좋아요.

설비 데이터 수집 경로와 제어 경로도 분리해요. 처음에는 읽기 전용 계정과 필요한 네트워크 구간만 열고, 원격 쓰기는 별도 권한, 허용 주소, 현장 인터락, 수동 복귀 절차를 확인한 뒤 다뤄야 해요. 대시보드에서 상태가 보인다는 이유만으로 펌프나 수문 제어 권한까지 같은 계정에 주면 안 돼요.

한 지점의 읽기 검증부터 저장 이력, 다지점 운영, 제어 권한 분리까지 순서대로 넓히는 모습이에요.

한 지점에서 시작해요

첫 단계는 배수장 한 곳에서 수위 한 점과 펌프 운전 상태 한 점만 읽는 거예요. 정상 운전, 펌프 정지, PLC 재시작, 네트워크 단절, 중앙 시스템 점검을 차례로 만들고 각 구간의 시각과 상태를 기록해요. 복구 뒤 빠진 구간과 중복 기록이 어떻게 보이는지도 확인해야 해요.

두 번째 단계에서 펌프 수와 수문 상태를 늘리고, 세 번째 단계에서 EASY LOGGER의 저장 이력과 전달 상태 대시보드로 운영 기준을 맞춰요. 마지막에 상위 시스템 인터페이스로 범위를 넓히면 문제 구간을 작게 찾을 수 있어요.

비슷한 원격 수집의 끊김 기준은 원격 태양광 인버터 데이터 수집 글에서, MQTT 설정 항목은 EASY LOGGER MQTT 설정 방법에서 더 살펴볼 수 있어요. 다른 자료는 기술 블로그에 모아 두었어요.

현재 사용 중인 수위센서와 제어반의 Modbus TCP 주소, 중앙에서 받을 MQTT 또는 API 사양, 제어 권한 범위만 정리해도 필요한 구성을 좁힐 수 있어요. 구매를 서두르기보다 HT Automation 홈페이지에서 현장 연결 가능 여부를 먼저 확인해 보세요. EASY-LINK만으로 충분한지, EASY LOGGER까지 필요한지 데이터가 지나가는 구간부터 살펴볼 수 있어요.