스마트팜 관수 탱크 수위 값을 기록해 한 화면에서 읽는 대시보드 설계

관수 탱크가 비는 순간은 늘 뒤늦게 알려집니다

온실에서 관수 계통이 멈추는 원인은 펌프 고장보다 물이 모자란 상태에서 밸브가 열린 경우가 많습니다. 원수 탱크와 양액 탱크의 물 높이는 아직도 눈금자나 플로트 스위치로 보는 현장이 적지 않습니다. 사람이 들여다본 그 시각의 값 하나만 남으니, 언제부터 물이 줄기 시작했는지 되짚을 근거가 없습니다.

물 높이는 순간값보다 시간에 따른 변화가 더 많은 것을 알려 줍니다. 한 시간에 몇 센티미터가 줄었는지, 급액 시각과 감소 구간이 겹치는지, 보충 펌프가 돌고도 값이 오르지 않았는지가 그렇습니다. 이런 판단은 값을 일정한 간격으로 계속 남겨 두어야 가능합니다. 사람이 적는 점검일지로는 간격이 들쭉날쭉해 비교 자체가 성립하지 않습니다.

기록이 있어야 답할 수 있는 질문들

스마트팜을 두고 흔히 자동 제어부터 떠올리지만, 제어는 판단 뒤에 오는 단계입니다. 농림축산식품부의 지능형농장 지원 사업도 온·습도와 양액을 모니터링하는 센서와 복합환경관리시스템을 함께 묶는 방향으로 정리되어 있습니다. 급액 제어와 원수 확보는 한 계통이므로, 환경값만 남기고 물 높이를 빼 두면 원인 추적이 중간에서 끊깁니다.

수위센서 값을 일정 주기로 남겨 두면 세 가지 질문에 숫자로 답할 수 있습니다. 하루 실제 사용량이 계획 급액량과 얼마나 벌어졌는가, 보충 밸브가 열린 뒤 회복까지 몇 분이 걸리는가, 같은 작기 안에서 소비량 곡선이 어느 시점부터 달라졌는가입니다. 세 번째는 특히 작기 단위 데이터 추세 분석으로만 보입니다.

농촌진흥청 농업기술 데이터 플랫폼이 공개한 2023년 시설채소 농가 데이터도 환경·생육 항목을 작기 단위로 묶어 제공합니다. 현장에서 쌓는 값의 구조를 이렇게 맞춰 두면 나중에 외부 자료와 비교하기 쉬워집니다.

계측 장치에서 저장 계층까지

현장 구성은 세 계층으로 나눕니다. 물탱크의 수위센서 신호는 4-20mA로 제어반에 들어가고, LS PLC가 이 값을 워드 영역에 담습니다. EASY-LOGGER 계열 수집 장치는 이 지점에서 현장 값을 실제로 읽어 오는 계측·수집 장치 역할을 맡습니다. LS F-NET / XGT TCP를 고르고 IP ADDRESS, PORT, XGT 계열을 채운 뒤 연결 테스트가 통과하면 PLC 저장을 누릅니다.

EASY-LINK는 그 값을 상위로 옮기는 연결 역할을 맡는 게이트웨이입니다. 온실동과 기계실이 떨어져 있어 유선 포설이 어려운 구간에서 계측값을 MQTT 메시지로 발행합니다. 수집 조건에서는 주소를 계산하지 않고 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES를 그대로 씁니다. PRO 계열은 ROOT KEY가 RTU1 같은 채널 키이고, 토픽 스캔을 누르면 실제로 들어오는 토픽과 키를 불러와 입력란을 채워 줍니다. STALE AFTER (MS)를 넣어 두면 그 시간 동안 수신이 없을 때 값을 null로 저장하고 결함으로 표시하므로, 무선 구간이 끊긴 사실이 기록에 남습니다.

EASY LOGGER는 저장과 조회를 담당하는 운영 계층입니다. MAIN 설정에서 CONFIG NAME을 TANK_LEVEL처럼 정하고 PLC SELECT로 앞서 등록한 장비를 고른 뒤, TRIGGER TYPE을 Timer, DATA TYPE을 WORD로 두고 시작 번지와 디바이스 수, 수집요청주기를 ms 단위로 넣습니다. 저장 PLC 목록의 STATUS가 RUNNING이면 값이 실제로 들어오는 중입니다. 탱크 수위는 초 단위로 요동하는 값이 아니므로 수집 주기를 5초 안팎으로 두어도 급액 구간을 놓치지 않고, PLC와 네트워크 부하도 낮게 유지됩니다.

CONNECTION PROTOCOL: LS F-NET / XGT TCP
PLC NAME: GH1_WATER
CONFIG NAME: TANK_LEVEL
TRIGGER TYPE: Timer
DATA TYPE: WORD
수집요청주기: 5000 ms

수위 신호가 제어반에서 저장 계층까지 이어지는 경로

전달 대상을 MySQL로 잡은 이유

이 구성의 주 전달 대상은 MySQL입니다. DB 설정 화면에서 DB Name, Host Address, Port, User, Password를 넣고 연결 테스트로 접속을 확인한 뒤 설정 저장을 누르면 됩니다. 자체 저장이면 Host Address는 127.0.0.1, Port는 3306입니다. 작기 단위로 몇 달치를 기간과 주소로 잘라 조회해야 하는 용도에는 이 방식이 가장 잘 맞고, DB TABLE DELETE에 보존 기간을 정해 두면 매일 00:00에 기간이 지난 수집 데이터만 정리됩니다.

MQTT는 값이 바뀌는 즉시 여러 구독자에게 뿌리는 데 강하지만 브로커는 이력을 책임지지 않습니다. 지난주 급액 구간을 다시 보려면 결국 별도의 데이터베이스가 필요합니다. HTTP API는 상위 시스템이 원하는 시점에 끌어가는 방식이라 방화벽 정책이 까다로운 망에서 다루기 쉬운 대신, 초 단위 갱신을 계속 받기에는 호출 부담이 큽니다. Firebase는 외부에서 화면만 빠르게 붙일 때 편하지만 재배 데이터가 사외로 나갑니다.

MES나 CIM 같은 상위 시스템과의 데이터 연동도 같은 기준으로 나눕니다. 실시간 상태 통지는 MQTT 인터페이스, 집계 조회는 HTTP API 인터페이스, 이력 재조회는 데이터베이스 직접 조회로 역할을 나눠 두면 한쪽이 멈춰도 나머지가 버팁니다.

EASY LOGGER 대시보드 예제

수집과 저장이 붙었으면 남는 일은 현장에서 읽을 화면을 만드는 것입니다. 대시보드는 값을 조회하고 표시하는 용도로만 쓰고, 밸브나 펌프 조작은 기존 제어반에 그대로 남겨 둡니다. 관리동에서 온실을 원격 모니터링하는 담당자가 보게 될 화면이므로 항목은 적을수록 좋습니다.

Dashboard 화면은 위젯 네 개로 충분합니다. 첫 번째 widget에는 TANK_LEVEL의 current value를 게이지로 두어 지금 물 높이를 보여 줍니다. 두 번째 위젯에는 last reception time 필드를 붙여 마지막으로 값이 들어온 시각을 표시합니다. 세 번째 위젯은 delivery state 필드로 저장 경로가 살아 있는지 표시하고, 네 번째 위젯에는 24시간 history 그래프를 배치해 급액 시각마다 계단처럼 떨어지는 구간을 그대로 보게 합니다.

화면을 만든 뒤에는 EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다. DB 이력 로그의 전체 처리 건수와 성공률, 마지막 오류 시각을 보고, DB 조회에서 Timestamp, Config, Address, Value가 의도한 주기로 쌓였는지 확인하면 됩니다. 화면 맨 아래 DB·PLC·MQTT 상태 표시등도 같이 봐 두면 어느 구간이 끊겼는지 바로 갈립니다.

현재값·수신 시각·전달 상태·이력을 한 화면에 배치한 구성

탱크 한 대부터 시작합니다

처음부터 온실 전체를 붙일 필요는 없습니다. 원수 탱크 한 대에 수위센서 한 점만 걸어 이틀치 값을 쌓아 보면 주기가 적당한지, 값의 진폭이 예상과 맞는지 바로 드러납니다. 여기서 확인된 CONFIG NAME 규칙과 저장 주기를 그대로 복사해 양액 탱크와 다른 동으로 단계적으로 넓히면 됩니다. 이름 규칙을 처음에 잘 정해 두는 편이 나중에 훨씬 편합니다. PLC NAME과 CONFIG NAME은 외부 연동 주소에 그대로 들어가므로, 운영을 시작한 뒤에 바꾸면 붙어 있던 조회 경로가 전부 달라집니다.

지금 쓰는 제어반과 PLC를 바꾸지 않고 붙일 수 있는지부터 궁금하시다면, 현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다. PLC 기종과 통신 포트, 읽을 주소 목록만 있으면 판단할 수 있습니다. 제품 구성은 HT Automation 홈에서, 다른 현장의 구성 사례는 기술 블로그 목록에서 볼 수 있습니다. 같은 LS PLC 값을 MySQL에 남긴 구성은 국책과제 시험 설비 소비전력 기록 사례에 정리해 두었습니다.