원격지 설비 유량·온도 값을 MQTT로 모아 한 화면에서 읽는 구성

사람이 없는 현장에서는 값이 늦게 도착합니다

취수장과 중계 펌프실, 폐수 처리동처럼 상주 인원이 없는 원격지 설비는 순회 점검 때 적어 온 숫자가 기록의 전부인 경우가 많습니다. 유량계 적산값과 배관 온도를 하루 한 번 수기로 옮기면, 값이 언제부터 어긋나기 시작했는지 되짚을 근거가 남지 않습니다. 결국 설비가 멈춘 뒤에야 원인을 찾게 되는 구조입니다.

기후에너지환경부가 공개한 스마트상수도 관리체계 자료는 수질·수량·수압 감시 장치를 관망에 설치해 실시간으로 현황을 감시하는 방향을 제시합니다. 한국환경공단이 운영하는 수질원격감시체계도 사업장에서 측정한 값을 관제센터로 전송해 24시간 원격으로 감시합니다. 공공 영역에서 이미 자리를 잡은 구성이므로, 민간 원격지 설비도 같은 순서를 따라가면 무리가 없습니다.

유량계와 온도센서 값을 어디까지 남길 것인가

원격 모니터링을 도입하는 이유는 화면을 하나 더 만들기 위해서가 아니라, 운영 판단에 쓸 숫자를 확보하기 위해서입니다. 순간 유량만 보면 지금 흐르는지 여부만 알 수 있지만, 같은 값을 10초 간격으로 계속 남기면 펌프 기동 뒤 유량이 정상 구간까지 오르는 데 걸리는 시간이 보입니다. 배관 온도센서 값을 함께 남기면 동절기 저온 구간과 유량 감소 구간이 겹치는지도 비교할 수 있습니다.

기록 간격이 일정해야 데이터 추세 분석이 성립합니다. 사람이 적는 점검일지는 간격이 들쭉날쭉해 어제와 오늘을 나란히 놓을 수 없습니다. 수집 주기를 고정해 두면 월 단위 사용량 곡선, 계통별 손실 구간, 이상 상태의 지속 시간이 모두 같은 기준으로 계산됩니다.

계측에서 저장까지 세 계층으로 나눕니다

현장 구성은 계측·연결·운영 세 계층으로 나눕니다. 배관에 붙은 유량계와 온도센서는 RS485 한 선에 물려 Modbus RTU로 값을 냅니다. EASY-LOGGER 계열 수집 장치가 이 지점에서 현장 값을 직접 읽어 오는 계측·수집 장치 역할을 맡습니다. MAIN 설정의 CONNECTION PROTOCOL에서 Modbus RTU를 고르고 COM 포트와 Baudrate, Unit ID(1~247)를 채운 뒤, 연결 테스트가 통과하면 PLC 저장을 누릅니다.

배관 계측기 값이 RS485와 무선 구간을 거쳐 한 화면으로 모이는 경로

EASY-LINK는 그 값을 상위로 옮기는 연결 역할을 맡는 게이트웨이입니다. 관리동과 처리동이 떨어져 있어 유선 포설이 어려운 구간에서 계측값을 MQTT 메시지로 발행합니다. 한 통신 포트에 여러 대를 물릴 때는 장비마다 따로 등록하고, 같은 COM 포트를 쓰더라도 프로토콜과 국번은 장비별로 각각 넣습니다.

EASY LOGGER는 그 메시지를 구독해 저장하고 화면으로 보여 주는 운영 계층입니다. 수집 조건에서는 시작 번지와 디바이스 수 대신 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES를 넣고 TRIGGER를 On message나 Timer 중에서 고릅니다. STALE AFTER (MS)를 넣어 두면 그 시간 동안 수신이 없을 때 값을 null로 저장하고 결함으로 표시하므로, 무선 구간이 끊긴 사실도 기록에 남습니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다.

EASY LOGGER MQTT 예제

EASY LOGGER는 등록한 PLC 이름과 수집 설정 이름을 그대로 주소로 씁니다. 발행 토픽은 PLC이름/CONFIG이름/READ 형태이므로, PLC NAME을 RTU_FLOW로, CONFIG NAME을 FLOW_10S로 등록했다면 아래와 같은 READ Topic이 만들어집니다. MQTT 설정에서 MQTT Server와 Port를 채우고 Publish를 켠 뒤 오른쪽 위 Enable 스위치를 올리면 발행이 시작됩니다.

MQTT Server : 192.168.10.50
Port        : 1883
READ Topic  : RTU_FLOW/FLOW_10S/READ
Payload     :
{
  "values": {
    "D0100": 1274,
    "D0102": 318
  }
}

저장한 뒤에는 화면 세 곳을 봅니다. Topic Preview에서 의도한 주소가 그대로 만들어졌는지 확인하고, Runtime Status에서 브로커 접속이 살아 있는지 봅니다. Payload Log에는 실제로 나간 메시지가 남으므로 values 안의 주소키와 값이 현장 계측값과 맞는지 대조할 수 있습니다. 화면 맨 아래 상태 표시등의 MQTT 항목이 정상인지도 같이 확인합니다.

MQTT·HTTP API·MySQL 중 무엇으로 넘길 것인가

이 구성에서 주 전달 대상은 MQTT입니다. 브로커에 한 번 붙으면 여러 상위 시스템이 같은 토픽을 나눠 구독할 수 있고, 값이 갱신될 때마다 밀어 주므로 회선이 가는 원격지에서 재요청이 적습니다. 다만 브로커가 끊기면 그 설정만 SKIPPED로 바뀌므로 상태 감시가 함께 필요합니다.

HTTP API는 상위 시스템이 필요할 때 가져가는 방식이라 방화벽 정책이 까다로운 현장에서 다루기 쉽습니다. 대신 조회 간격보다 짧은 변화는 놓칩니다. MySQL은 값을 그대로 쌓아 두고 나중에 기간을 지정해 되짚을 때 유리하며, DB 설정에서 Host Address와 Port 3306, User, Password를 넣고 연결 테스트를 통과시키면 됩니다. 대신 DB 서버와 저장 공간을 계속 관리해야 합니다. 셋을 한 번에 고를 필요는 없고, 실시간 화면은 MQTT로, 이력 조회는 MySQL로 나누는 데이터 연동 구성이 무난합니다.

실시간 전달과 이력 조회를 나눠 상위 시스템에 연결한 인터페이스 구조

MES나 CIM 같은 상위 시스템과 붙일 때도 경계는 같습니다. 전용 커넥터를 전제로 하지 않고, MQTT 토픽과 HTTP API 엔드포인트, 데이터베이스 조회라는 세 인터페이스 가운데 상대 시스템이 이미 다루는 방식을 고르면 됩니다.

한 대에서 시작해 범위를 넓히는 순서

처음부터 전 계통을 묶을 필요는 없습니다. 유량계 한 대와 온도센서 한 대를 붙여 수집 주기와 저장 이력이 의도대로 쌓이는지 확인한 뒤, 같은 방식으로 계통을 단계적으로 늘립니다. 저장 설정 목록의 STATUS가 RUNNING으로 유지되는지, DB 이력 로그의 성공률과 마지막 오류 시각이 어떻게 움직이는지를 2주 정도 지켜보면 주기와 보존 기간을 정할 근거가 생깁니다.

현장마다 계측기와 회선 조건이 다르므로, 지금 쓰는 장비로 현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다. 제품 구성과 사양은 HT Automation 제품 소개에서 볼 수 있고, 다른 현장 구성 사례는 기술 블로그 목록에 정리해 두었습니다. 원격지 펌프장을 데이터베이스 중심으로 운영한 사례는 원격 펌프장 운영 기록 구성에서 이어 보시기 바랍니다.