원격지 저수조 수위·온도 데이터를 HTTP API로 상위 시스템까지 잇는 구성

원격지 설비는 담당자가 상주하지 않는 조건에서 운전됩니다. 값은 PLC 안에 남아 있는데 사무실의 MES나 CIM 화면까지 올라오지 못하는 일이 잦습니다. 막히는 자리는 대개 센서가 아니라 계층과 계층을 잇는 인터페이스입니다.

저수조에서 상위 시스템까지 이어지는 세 계층

이 글은 저수조와 가압 펌프실을 원격으로 맡고 있는 담당자를 대상으로 합니다. 수위센서와 온도센서 값을 Mitsubishi PLC에서 읽어 상위 시스템까지 올리는 경로를 실제 설정 항목 이름으로 정리합니다. 제품 구성은 홈에서, 지난 구성 사례는 블로그 목록에서 보실 수 있습니다.

계층은 셋으로 나눕니다. 값을 재는 현장 계층, 값을 옮기는 연결 계층, 값을 쌓고 보여 주는 운영 계층입니다. 경계를 먼저 그어 두면 장애가 났을 때 어느 구간을 열어 볼지가 분명해집니다.

현장 계층: 값을 재는 지점과 수집 주기

수위센서는 저수조 수위를, 온도센서는 펌프실과 배관 온도를 잽니다. 두 값은 Mitsubishi PLC의 데이터 레지스터에 들어갑니다. MAIN 설정에서 CONNECTION PROTOCOL을 MC Protocol 3E/4E로 고르고 IP ADDRESS, PORT, MC Frame, PLC Type을 채운 뒤 연결 테스트가 성공하면 PLC 저장을 누릅니다.

PLC NAME은 운영을 시작한 뒤에 바꾸기 어렵습니다. MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로가 모두 이 이름을 기준으로 만들어지기 때문입니다. 처음 등록할 때 REMOTE_TANK처럼 현장에서 통하는 이름으로 정합니다.

수집 조건에는 CONFIG NAME, PLC SELECT, TRIGGER TYPE, DATA TYPE, 시작 번지, 수집요청주기(ms), 디바이스 수를 넣고 설정 저장을 누릅니다. 저장 설정 목록의 STATUS가 RUNNING이면 정상이고, FAULT라면 접속 정보와 주소 범위를 다시 봅니다.

수위와 온도 값이 계층을 따라 올라가는 경로

연결 계층과 운영 계층의 역할 나누기

배선이 닿지 않는 지점은 EASY-LINK가 맡습니다. EASY-LINK는 떨어져 있는 지점의 값을 수집해 MQTT로 발행하는 연결 역할을 담당합니다. 반대편에서는 CONNECTION PROTOCOL을 EASY-LINK로 고른 설정이 그 토픽을 구독하고, 주소 대신 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES, TRIGGER, STALE AFTER (MS)를 입력합니다. 토픽 스캔을 누르면 실제로 들어오는 토픽과 키가 보입니다.

EASY LOGGER는 운영 계층을 맡습니다. 값을 MariaDB나 MySQL에 쌓고 같은 값을 외부로 내보내며, EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다. 브로커가 끊기면 그 설정만 SKIPPED로 표시되고 나머지 수집은 계속 돌아가므로, 어느 계층이 멈췄는지 화면에서 구분됩니다.

EASY LOGGER HTTP API 예제

상위 시스템이 값을 받아 가는 방식을 원한다면 API 설정으로 경로를 만듭니다. 전송은 POST로 하고 본문은 JSON입니다. 주소는 임의로 적지 말고, PLC NAME과 CONFIG NAME으로 조합된 값을 Endpoint Preview에서 확인해 그대로 씁니다. 쓰기 결과를 되돌려받을 callback endpoint는 write_callback_url에 넣습니다.

{
  "method": "POST",
  "endpoint": "/REMOTE_TANK/TANK_LEVEL/READ",
  "write_callback_url": "http://192.168.0.60:8080/mes/write-result",
  "payload": {
    "plc": "REMOTE_TANK",
    "config": "TANK_LEVEL",
    "values": {
      "D0100": 1842,
      "D0102": 236
    }
  }
}

설정을 저장하고 Enable을 켠 다음에는 API Payload Log에서 실제로 나간 본문과 응답을 확인합니다. 화면 아래 STATUS 표시등의 API 항목이 정상으로 바뀌는지, 대시보드의 값이 같은 시각으로 갱신되는지 함께 봅니다.

쓰기 경로를 함께 열 때 지키는 경계입니다.

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

전달 대상 비교: HTTP API·MQTT·MySQL·Firebase

이 구성의 주 전달 대상은 HTTP API입니다. 요청과 응답이 한 쌍으로 남아 상위 시스템이 수신 결과를 코드로 판정할 수 있고, 사내망 방화벽에서 허용 규칙을 만들기도 수월합니다. 연결이 끊긴 구간의 값은 상위 시스템이 다시 요청해 채워야 합니다.

MQTT는 값이 바뀔 때 밀어내는 방식이라 지연이 짧고 구독자를 늘리기 쉬운 반면 브로커를 따로 운영해야 합니다. MySQL은 이력 조회와 보고서 작성에 유리하지만 실시간성은 떨어집니다. Firebase는 외부 망에서 화면을 띄우기 편한 대신 폐쇄망 정책과 부딪히는 현장이 있습니다. 원격 모니터링 화면과 상위 연계를 함께 놓고 두 가지 이상을 조합하는 편이 현실적입니다.

요청 응답, 발행 구독, 이력 조회 경로를 나란히 둔 비교도

MES·CIM 상위 시스템과 잇는 데이터 연동 설계

MES나 CIM 같은 상위 시스템과의 데이터 연동은 세 가지 인터페이스로 정리하면 관리하기 쉽습니다. 실시간 상태는 MQTT, 조회와 명령 응답은 HTTP API, 이력 대사는 데이터베이스 인터페이스가 맡습니다. 세 경로 모두 PLC 연동 단계에서 정한 PLC NAME과 CONFIG NAME을 그대로 쓰므로 이름 규칙을 먼저 확정해야 합니다.

권한은 계정 등급으로 나눕니다. 현장 작업자에게는 monitor, 설비 담당자에게는 editor 또는 admin을 부여하고, 상위 시스템 연계용 계정은 필요한 범위만 갖도록 제한합니다.

한 대부터 단계적으로 범위를 넓히기

처음부터 모든 설비를 붙일 이유는 없습니다. 저수조 한 대와 펌프 한 대로 시작해 STATUS와 API Payload Log가 하루 이상 안정적으로 유지되는지 본 뒤 같은 방식으로 단계적으로 범위를 넓힙니다. 비슷한 흐름은 시험 리그 사이클을 HTTP API로 넘긴 구성에도 정리해 두었습니다.

원격지 설비는 통신 조건이 현장마다 다릅니다. 도면을 준비하기 전에 현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다.