블로그2026. 7. 29.

원격 수처리 수질 데이터, 대시보드에서 비교할 기준

원격 수처리 수질 데이터, 대시보드에서 비교할 기준

숫자보다 비교가 먼저예요

원격 수처리 시설의 pH 센서와 수질 계측값은 한 번 확인하는 숫자로 끝나지 않아요. 같은 지점의 값이 시간에 따라 어떻게 달라졌는지, 다른 지점과 차이가 있는지, 마지막 데이터가 언제 들어왔는지를 함께 봐야 운영자가 다음 점검 순서를 정할 수 있어요. 현장에 바로 갈 수 없는 원격지 설비라면 이 비교 기준이 더 중요해져요.

환경부의 수질자동측정망 공개 항목은 수온, pH, 전기전도도, 용존산소처럼 서로 의미가 다른 값을 지점별로 나누고, 실시간 현황과 기간별 일평균을 함께 제공해요. K-water 물정보 화면도 취수장·정수장·배수지를 구분해 항목을 보여주고, 실시간 자료가 검보정 전이라는 점을 따로 밝혀요. 현장 대시보드도 값만 크게 띄우기보다 어디서 언제 들어왔고 확인 전인지 검토된 값인지 구분해야 해요.

공공 화면의 기준값을 개별 시설에 그대로 복사하자는 뜻은 아니에요. 시설별 관리 기준과 센서 사양은 해당 운영 절차와 장비 문서로 정해야 해요. 여기서 가져올 수 있는 원칙은 지점, 측정 항목, 시간, 데이터 상태를 분리해 기록한다는 점이에요.

값 옆에 상태를 남겨요

대시보드에 올릴 데이터는 최소한 facilityId, pointId, metric, value, unit, measuredAt으로 나눠 두는 편이 좋아요. 여기에 PLC가 읽은 시각과 서버가 받은 시각, 통신 상태, 값의 유효 여부를 더하면 값이 변한 것과 데이터가 늦게 온 것을 구분할 수 있어요. 센서 교정 여부나 현장 검토 결과가 필요하다면 원시값을 덮어쓰지 말고 별도 상태로 남겨야 해요.

함께 남길 항목대시보드에서 답할 질문
시설·공정·측정 지점어느 위치의 값인가요?
항목·단위·배율같은 이름을 같은 의미로 읽고 있나요?
측정·수집·도착 시각실제 변화인가요, 전달 지연인가요?
유효·결측·점검 상태비교에 포함해도 되는 값인가요?
마지막 정상 수신 시각현장 방문 전에 통신 구간을 볼 필요가 있나요?

이 구조를 먼저 정하면 데이터 추세 분석도 단순한 선 그래프를 넘어서요. 같은 시간대의 지점별 차이, 운전 전후의 변화, 데이터가 비어 있는 구간을 따로 볼 수 있어요. 원격 모니터링 화면은 정상처럼 보이는 마지막 값과 지금도 들어오는 값을 반드시 구분해야 해요.

연결 계층을 나눠요

현장 수질 계측값이 LS PLC에 모여 있다면, 이제 수집과 전달 구간을 분리해 볼 수 있어요. EASY-LINK는 LS XGT 데이터를 읽어 Firebase, MQTT, HTTP API, MySQL 같은 목적지로 이어 주는 산업용 IoT 게이트웨이 역할을 맡아요. 센서의 정확도나 현장 관리 기준을 대신 정하지 않고, 확인된 PLC 값을 필요한 형식으로 연결하는 계층이에요.

수질 계측기와 LS PLC에서 운영 화면까지 이어지는 데이터 흐름

수질 계측값이 LS PLC와 연결 계층을 거쳐 저장·운영 화면으로 전달되는 구간을 나눈 모습이에요.

한 제어반의 몇 개 항목을 이미 운영 중인 Firebase로 보내는 목적이라면 EASY-LINK 중심으로 작게 시작할 수 있어요. 반대로 여러 시설의 수집 주기, 저장 이력과 전달 상태를 함께 관리하고 대시보드를 구성해야 한다면 EASY LOGGER를 운영 계층으로 검토할 수 있어요. EASY LOGGER는 통합 수집과 저장·전송 관리를 맡지만 센서 검교정이나 수질 적합 판정을 대신하지는 않아요.

Firebase 화면은 이렇게 구성해요

Firebase를 주 전달 대상으로 고르면 기존 웹·모바일 화면과 데이터를 연결하기 편한 구성이 될 수 있어요. 다만 현재값 한 칸만 갱신하면 과거 변화와 누락 구간을 비교하기 어려워요. 시설과 지점별 현재 상태, 시간순 이력, 마지막 수신 시각을 분리하고 보존 기간과 읽기·쓰기 권한을 먼저 정해야 해요.

목적지가 다르면 전달 방식도 달라져요. 여러 소비자가 같은 데이터를 받아야 하면 MQTT가 자연스럽고, 정해진 업무 시스템과 요청·응답 결과를 확인하려면 HTTP API를 비교할 수 있어요. 장기 조회와 표 형태 집계가 중심이면 MySQL 같은 DB가 편할 수 있어요. 한 방식이 언제나 우월한 게 아니라 수신자, 재시도, 중복 처리와 조회 목적이 선택 기준이에요.

대시보드 첫 화면에는 모든 센서를 한꺼번에 넣기보다 세 가지 질문만 남겨 보세요. 지금 들어오는가, 최근 추세가 평소와 다른가, 어떤 지점을 먼저 확인할 것인가예요. 세부 화면에서 원시값과 단위, 수신 시각, 결측 구간을 확인하도록 나누면 화면은 단순해지고 판단 근거는 더 선명해져요.

상위 시스템과 제어를 구분해요

수질 데이터가 MES·CIM 같은 상위 시스템에도 필요하다면 MQTT, HTTP API 또는 DB 인터페이스로 조회 범위를 먼저 연결해요. 검증된 인터페이스 범위에서 시설 ID와 항목 이름, 시간대, 결측 표현, 중복 키를 송신·수신 담당자가 합의해야 해요. 대시보드의 표시 권한과 설정 변경 권한도 나누는 편이 좋아요.

한 지점에서 시작해 저장·대시보드·상위 시스템으로 넓히는 단계

한 제어반의 데이터 검증부터 저장 이력과 상위 시스템 인터페이스까지 범위를 단계적으로 넓히는 모습이에요.

수집 화면이 현장 제어 권한을 자동으로 가져서는 안 돼요. 펌프나 밸브의 운전과 인터락은 승인된 PLC 로직과 현장 안전 절차에 남겨 두고, 데이터 연동은 먼저 읽기와 운영 판단 범위로 시작하는 편이 안전해요. 외부 쓰기가 꼭 필요하다면 최소 권한, 명령 기록, 인터락과 수동 복귀 절차를 별도 검토해야 해요.

한 지점부터 확인해요

처음에는 제어반 한 대와 수질 항목 두세 개만 고르세요. 현장 표시값과 LS PLC 값, 전송된 Firebase 값이 같은 시각에 같은 단위로 보이는지 확인해요. 통신을 잠시 끊었을 때 결측이 어떻게 남는지, 복구 뒤 중복 데이터가 생기는지, 마지막 수신 시각이 제대로 바뀌는지도 함께 기록해요.

그다음 다른 지점을 더하고 EASY LOGGER의 저장 이력·전달 상태 관리와 대시보드가 필요한 범위를 정하면 돼요. 원격 시설의 펌프 운영 흐름은 원격 배수장 데이터 운영 글에서 다른 관점으로 볼 수 있고, 더 많은 수집 주제는 기술 블로그에서 비교할 수 있어요.

현재 사용 중인 계측기, LS PLC 주소, 수집할 항목과 단위, 보낼 Firebase 구조를 정리했다면 HT Automation 홈페이지에서 현장 연결 가능 여부를 부담 없이 확인해 보세요. EASY-LINK만으로 충분한지, 여러 지점의 이력과 전달 상태를 위해 EASY LOGGER까지 필요한지 연결 구간부터 나눠 볼 수 있어요.

목록으로 돌아가기