원격 배수지 수위·수압 데이터, HTTP API로 운영 시스템에 잇는 기준

데이터가 지나가는 길부터 그려요

원격 배수지의 수위와 수압을 운영 시스템에 연결할 때는 화면부터 만들기보다 데이터가 지나가는 길을 먼저 그리는 편이 좋아요. 환경부는 스마트 상수도 관리체계를 수량·수질·수압 상태를 실시간으로 살피고 관리하는 구조로 설명해요. 또 실시간 배수지 수위와 수압을 의사결정에 활용하는 국내 기술검증 자료도 공개돼 있어요.

현장에서는 수위센서와 압력센서의 값이 PLC 주소에 들어오고, 수집기가 이를 읽어 외부 시스템으로 보내요. 여기서 원본 측정 시각, PLC 수집 시각, HTTP 요청 시각과 수신 응답 시각을 하나로 합치지 않는 것이 중요해요. 네 시각을 분리하면 값이 늦게 측정된 것인지, 현장 수집이 멈춘 것인지, API 전달만 실패한 것인지 나눠 볼 수 있어요.

수집 상태와 전달 상태를 나눠요

예시로 D0100을 배수지 수위, D0102를 토출 수압이라고 가정해 볼게요. 주소와 배율은 제품 기본값이 아니라 설명을 위한 예시이므로 실제 PLC 주소 맵, 센서 단위와 데이터 타입을 반드시 대조해야 해요. 두 값이 같은 주기로 들어와도 마지막 정상 수신 시각이 다를 수 있으니 필드별 상태를 따로 남겨요.

운영 화면에는 현재값만 두지 말고 last_measured_at, last_collected_at, delivery_status를 나눠 표시해요. 수위 값은 최근인데 전달 상태가 오류라면 센서보다 HTTP API 경로를 먼저 볼 수 있어요. 반대로 API 응답은 정상이지만 원본 측정 시각이 오래됐다면 오래된 값을 반복 전송하고 있지 않은지 확인해야 해요. 이런 구분이 원격 모니터링의 출발점이에요.

목적지에 따라 전달 방식을 골라요

HTTP API는 상위 시스템이 요청 본문과 응답 코드의 계약을 명확히 관리할 때 잘 맞아요. MQTT는 여러 소비자가 이벤트를 구독해야 할 때, MySQL은 외부 스키마에 장기 이력을 적재해 쿼리로 비교할 때, Firebase는 웹·모바일 화면에 상태를 빠르게 동기화할 때 검토할 수 있어요. 어느 방식이 항상 우월한 것은 아니며, 재시도·중복 처리·권한과 보존 책임을 누가 맡는지에 따라 선택이 달라져요.

현장 연결 계층에서는 EASY-LINK가 Modbus TCP 등 공식 확인된 데이터를 읽고 HTTP API로 전달하는 산업용 IoT 게이트웨이 역할을 맡을 수 있어요. 주소 변환과 전달 한 경로만 필요하면 EASY-LINK 중심으로 시작할 수 있어요. 여러 배수지의 저장 이력, 전달 상태와 Dashboard 운영을 함께 관리해야 한다면 EASY LOGGER를 더해 책임을 나누는 편이 좋아요. 두 제품 모두 수도시설의 운전 기준이나 수질 적합성을 대신 결정하지는 않아요.

실제 EASY-LINK 원본 이미지이며, 현장 센서와 PLC 데이터를 외부 목적지로 연결하는 계층을 검토할 때 참고할 수 있어요.

EASY LOGGER HTTP API 예제

아래 WATER_PLC, RESERVOIR_A, D0100, D0102와 LOGGER_HOST는 모두 예시예요. callback endpoint는 Automatic Endpoint Preview에서 실제 POST 대상과 필드 구성을 확인한 뒤 현장 주소 맵과 수신 시스템 계약을 대조해요. 수위 필드 D0100과 수압 필드 D0102를 하나의 POST JSON으로 보낸다고 가정하면 다음처럼 구분할 수 있어요.

{
  "plc_name": "WATER_PLC",
  "config_name": "RESERVOIR_A",
  "data_type": "word",
  "values": {
    "D0100": 684,
    "D0102": 315
  }
}

예시 원시값은 실제 수위·수압이 아니에요. 현장 주소 맵에서 배율과 단위를 적용한 뒤 Runtime Status에서 마지막 수집 상태를 보고, API Payload Log에서 전송한 본문과 응답 결과를 확인해요. 수신 시스템은 같은 측정 시각과 장치 키가 다시 왔을 때 중복 저장할지 갱신할지 계약을 정해야 해요.

원격 쓰기 기능을 검토한다면 읽기 흐름과 분리해요. HTTP API의 WRITE CALLBACK 예시는 다음처럼 콜백 주소를 포함할 수 있지만, LOGGER_HOST, PLC명, 설정명과 주소는 실제 Automatic Endpoint Preview 및 현장 주소 맵으로 확인해야 해요.

{
  "D0100": 1,
  "D0102": 23.77,
  "write_callback_url": "http://LOGGER_HOST:8000/api/write/WATER_PLC/RESERVOIR_A"
}

• WRITE CALLBACK을 사용해 테스트 주소에만 전달해요.
• 테스트 주소만 사용합니다.
• 최소 권한만 부여합니다.
• 허용 주소 범위를 제한합니다.
• PLC 인터록을 확인합니다.
• 수동 복구 절차를 준비합니다.

쓰기 요청이 필요하지 않다면 콜백과 쓰기 권한을 열지 않는 편이 안전해요. EASY LOGGER의 Runtime Status와 Payload Log는 수집·전달 결과를 확인하는 운영 자료이며, 실제 펌프 운전 승인과 비상 절차를 대신하지 않아요.

수위·수압 센서와 PLC에서 시작한 데이터가 연결 계층을 지나 운영 화면과 상위 시스템으로 전달되는 추상 흐름이에요.

상위 시스템에는 확인 가능한 계약만 연결해요

운영 시스템이나 MES·CIM과 연계할 때는 HTTP API 인터페이스의 필드명, 단위, 시간대, 인증 방식, 응답 코드와 재시도 기준을 문서로 맞춰요. 데이터 연동의 성공을 HTTP 200 하나로만 판단하지 말고, 수신 측이 장치 키와 측정 시각을 정상 처리했는지도 확인해요. 수집 성공과 전달 성공을 분리하면 PLC 연동 구간과 상위 시스템 구간의 책임도 선명해져요.

화면에는 배수지별 현재 수위·수압, 마지막 측정 시각, 마지막 전달 시각과 연속 실패 횟수를 나란히 두는 편이 좋아요. 값이 범위 안에 있더라도 마지막 측정이 오래됐다면 정상 운영으로 단정하지 않아요. 수신 측 점검 시간에는 전송을 계속 재시도할지, 로컬 이력을 보관한 뒤 다시 보낼지 운영 기준을 먼저 정해요.

한 배수지에서 단계적으로 넓혀요

1단계에서는 배수지 한 곳의 읽기 주소 두 개만 연결하고 Runtime Status와 Payload Log를 비교해요. 2단계에서는 API 응답과 중복 처리 기준을 확인하고, 3단계에서 다른 배수지와 운영 화면으로 범위를 넓혀요. 원격 쓰기는 읽기 흐름이 안정된 뒤 별도 권한·인터록·수동 복구 시험을 통과한 범위에서만 검토해요.

현장 연결만 필요하면 EASY-LINK가 맡을 범위를 먼저 확인하고, 여러 지점의 이력과 전달 상태까지 함께 운영해야 하면 EASY LOGGER의 역할을 더해 보세요. 구매를 서두르기보다 현재 센서 형식, PLC 주소, API 수신 계약을 정리한 다음 현장 연결 가능 여부를 확인하는 것이 먼저예요. 비슷한 원격 설비 운영 화면은 원격 설비 데이터 대시보드 가이드와 함께 비교할 수 있어요.