공장 압력 데이터를 MQTT로 운영에 연결하는 기준과 확인 순서

압력값을 모아야 하는 이유

공장 압력 데이터는 현재 숫자 하나보다 언제, 어느 설비에서, 어떤 단위로 들어왔는지까지 이어질 때 운영 판단에 도움이 돼요. 압축공기나 공정 라인의 압력이 기준에서 벗어나면 현장 표시값, PLC 원시값, 전달 시각을 함께 봐야 계측 변화와 통신 지연을 나눌 수 있어요. 그래서 먼저 한 대의 압력센서와 한 공정만 정하고, 정상값·경계값·재연결 뒤 값을 같은 기준으로 기록하는 편이 좋아요. 이 기준이 있으면 숫자가 들어왔는지만 보는 대신 설비 상태와 수집 경로를 함께 점검할 수 있어요. 운영자는 같은 필드의 단위, 시간대, 장비 식별자를 맞춘 뒤 전달 성공 여부와 이력 보존 여부를 순서대로 확인하면 돼요. 처음부터 모든 설비를 묶기보다 판단에 필요한 압력값의 범위와 확인 화면을 좁혀 두는 편이 변경 원인을 찾기 쉬워요.

압력 데이터는 설비가 정상으로 돌아가는지를 판단하는 기준이 됩니다. 값이 낮아지면 누설이나 배관 변화를 의심할 수 있고, 값이 높아지면 배출구의 막힘과 압축기 제어 상태를 함께 확인해야 해요. 특히 순간값만 보면 일시적인 파동과 지속적인 변화를 구분하기 어려워요. 정상범위와 경계값을 미리 정하고, 측정시각과 수신시각을 분리해 남기면 현장에서 원인을 추적하기 쉽습니다. 이런 기준은 유지보수 시점을 정하거나 공정을 작게 늘릴 때도 필요해요.

이번 글의 예시는 PRESSPLC01의 PRESSURE_PV 필드를 PLC D0120에 매핑하고 kPa 단위로 읽는 구성입니다. PRESSPLC01, PRESSURE_PV, D0120, float, kPa는 설명을 위한 샘플이며 실제 센서 사양, PLC 프로그램, 현장 field address map과 대조해 확정해야 해요. measured_at과 received_at을 분리하면 값이 변한 시각과 서버가 받은 시각을 비교하기 쉬워져요.

연결 계층과 운영 계층을 나눠요

EASY-LINK는 압력센서·PLC에서 확인된 필드를 목적지까지 연결하고 MQTT로 전달하는 현장 연결 계층으로 봐요. 한 설비의 현재 압력값을 MQTT로 보내고 연결 상태만 확인한다면 EASY-LINK만으로 시작할 수 있어요. 반면 여러 설정의 수집 이력, 전달 상태와 대시보드 운영까지 이어서 확인하려면 EASY LOGGER를 더하는 편이 좋아요. EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 맡고, PLC 제어 로직이나 인터록을 대신하는 제품으로 설명하지 않아요.

두 제품의 경계는 EASY 제품의 연결·운영 범위에서 비교하고, 주소와 설정 항목은 제품 매뉴얼 자료실에서 버전별로 대조하면 돼요. 기존 압력 데이터 글이 HTTP API와 외부 MySQL 스키마의 계약을 다뤘다면, 이번 글은 같은 pressure-operation measurementFamily를 MQTT 전달과 운영 가치 관점에서 다시 살펴봐요. 관련된 압력 데이터 인터페이스 설계 글과 비교하면 전달 방식에 따른 확인 지점을 나누기 좋아요.

EASY-LINK는 압력센서와 PLC 필드를 MQTT 목적지까지 연결하는 역할을 맡아요.

MQTT와 다른 전달 경로를 비교해요

MQTT는 READ Topic과 구독 권한을 정해 현재값과 상태를 여러 소비자에게 나누기 좋아요. HTTP API는 운영 서버가 정한 endpoint와 요청·응답 계약, 재시도와 중복 요청을 확인하는 데 맞아요. MySQL은 외부 스키마에 측정 시각과 압력값을 보존해 기간별 비교를 할 때 유용하고, Firebase는 여러 화면에서 현재 상태를 공유할 때 비교할 수 있어요. 즉 MQTT는 전달, HTTP API는 계약, MySQL은 외부 이력, Firebase는 화면 공유라는 책임을 나눠 보는 게 좋아요.

이번 deliveryTarget은 MQTT예요. MES·CIM 같은 상위 시스템은 확인된 MQTT, HTTP API 또는 DB 인터페이스 범위에서 필드 계약을 협의하고, 확인되지 않은 전용 커넥터를 전제로 하지 않아요. 어떤 경로를 선택해도 압력 단위, 측정 시각, 수신 시각, 장비 ID가 같은 의미인지 먼저 확인해야 해요.

EASY LOGGER MQTT 예제

PRESSURE_PV 필드가 예시 PLC 주소 D0120에 대응하고 PRESSPLC01 장치에서 kPa float로 읽힌다고 가정해요. 이 주소·필드·장치 이름은 현장 field address map과 PLC 설정에 대조해 확정할 예시예요. Automatic Topic Preview에서 READ Topic과 WRITE Topic을 확인하고 Runtime Status에서 연결·발행 상태를, Payload Log에서 D0120과 단위를 확인해요.

READ TOPIC: PRESSPLC01/AIR_PRESSURE/READ
WRITE TOPIC: PRESSPLC01/AIR_PRESSURE/WRITE

위 Topic의 values.D0120이 PRESSURE_PV와 같은 필드인지 주소 맵과 맞춘 뒤, Payload Log에서 측정 시각과 수신 시각을 함께 확인해요.

{
  "plc_name": "PRESSPLC01",
  "config_name": "AIR_PRESSURE",
  "data_type": "float",
  "unit": "kPa",
  "measured_at": "2026-08-19T09:00:00+09:00",
  "received_at": "2026-08-19T09:00:01+09:00",
  "values": {"D0120": 642.5}
}

이 JSON의 PRESSPLC01, AIR_PRESSURE, D0120과 필드 키는 예시이며 현장 field address map과 대조해 확정해요. Runtime Status에서 마지막 발행 시각을 보고 Payload Log에서 값·단위·시각을 비교하면 돼요.

Subscribe to the WRITE Topic.

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

WRITE payload의 대상 주소와 권한은 테스트 설정으로 검증하고 운영 제어와 분리해요. 운영 단계에서는 Subscribe to the WRITE Topic 을 확인해요.

이력과 화면에서 운영 가치를 확인해요

EASY LOGGER는 압력값의 수집 이력과 전달 상태를 운영 화면에서 확인하는 역할을 맡아요.

EASY LOGGER의 Runtime Status에서는 연결 여부와 마지막 전달 시각을 먼저 봐요. Payload Log에서는 PRESSURE_PV, D0120, kPa와 값이 맞는지 확인하고, DB History에서는 외부 운영 DB에 저장한 기록이 있다면 measured_at과 received_at을 비교해요. Dashboard에서는 현재 압력, 마지막 수신 시각, 전달 상태와 기간별 추세를 같은 장비 ID로 묶어 보면 돼요. 값은 최신인데 전달 시각이 오래됐다면 센서와 통신을 별도로 점검할 수 있어요.

EASY-LINK만으로 충분한 경우는 한 설비의 압력값을 정한 MQTT 목적지로 전달하고 연결 상태만 확인하는 경우예요. 여러 설비의 이력과 누락 구간, 전달 결과와 Dashboard를 함께 운영할 때는 EASY LOGGER가 더해져요. 두 제품을 함께 써도 EASY-LINK가 EASY LOGGER의 저장 이력이나 Dashboard 역할을 대신한다고 보지 않고, 현장 연결과 데이터 운영을 나눠 설계해요.

작게 시작해 범위를 넓혀요

처음에는 압력센서 한 대와 한 공정에서 정상값, 경계값, 통신 재연결을 확인해요. 다음으로 두 번째 설비를 추가하면서 device_id와 config_name이 섞이지 않는지 비교하고, MQTT와 HTTP API의 전달 시각을 나눠 기록해요. 외부 MySQL을 함께 쓴다면 DB History의 레코드와 Payload Log의 received_at이 같은 사건을 가리키는지 확인해요. 그 뒤 Dashboard에서 현재값과 추세를 확인하며 범위를 넓히면 주소 오류와 전달 지연을 따로 찾기 좋아요.

현장 연결 가능 여부가 궁금하다면 센서 모델, PLC field address map, MQTT Topic, 필요한 외부 DB 컬럼을 준비해 확인·상담·문의해 주세요.