블로그›2026. 8. 16.

압력센서 데이터를 HTTP API와 MySQL로 잇는 인터페이스 설계 기준

먼저 결론부터 볼게요

압력센서 데이터를 상위 시스템에 보내는 일은 전송 방식보다 같은 값을 같은 의미로 유지하는 일이 먼저예요. 센서의 압력값이 PLC 주소를 거쳐 HTTP API나 MQTT로 전달될 때 필드명·단위·수집 시각·품질 상태를 함께 설계해야 API 성공과 저장값 불일치를 구간별로 찾을 수 있어요.

이번 글은 스마트팩토리에서 압력센서 한 대로 시작하는 인터페이스 설계예요. HTTP API를 기본 계약으로 두고 MQTT, MySQL, Firebase를 목적별로 비교한 뒤 주소와 payload를 맞추는 순서로 설명할게요.

센서와 PLC 필드를 먼저 고정해요

압력센서 필드 line_pressure가 예시 PLC 주소 맵의 D0100에 대응한다고 가정해요. 실제 설정이 아니라 현장 주소 맵과 대조할 예시예요. 데이터 타입은 float, 단위는 bar, 수집 시각은 collected_at, 품질 상태는 quality처럼 나눠요. 주소 오프셋과 배율은 실제 센서·PLC 문서로 확인해야 해요.

EASY-LINK는 산업용 IoT 게이트웨이로서 현장 연결과 전달 역할에 집중해요. 센서와 PLC 값을 MQTT·HTTP API·MySQL·Firebase로 넘기는 연결 계층이고, 여러 설정의 저장 이력·전달 상태·대시보드 운영은 EASY LOGGER가 맡는 범위로 나눠요. 한 라인의 값만 보내면 EASY-LINK만으로 충분할 수 있고, 여러 라인의 이력과 화면을 관리하면 EASY LOGGER를 더해요.

센서와 PLC의 압력 필드가 게이트웨이를 거쳐 MQTT·HTTP API·MySQL·Firebase로 나뉘는 흐름이에요.

HTTP API, MQTT, MySQL, Firebase를 비교해요

HTTP API는 운영 서버의 endpoint와 요청·응답 계약을 맞출 때 적합해요. POST /api/read/{PLC_NAME}/{CONFIG_NAME}은 공식 설정 자료의 형식이고, 실제 호스트·경로·인증 헤더는 외부 서버 계약으로 확정해요. 응답 코드와 함께 line_pressure, collected_at, quality 보존 여부를 확인해요.

MQTT는 여러 소비자가 같은 상태 메시지를 구독하기 좋아요. broker 인증, Topic, QoS, 중복 처리 기준은 별도로 정해요. MySQL은 외부 스키마의 압력 이력을 조회할 때 유용해요. 테이블과 컬럼은 EASY LOGGER 내부 스키마가 아니라 운영팀이 정하는 외부 스키마 예시예요. Firebase는 현재 상태와 시간순 이력 공유가 필요할 때 비교하되 보존·권한·외부 서비스 의존성을 함께 검토해요.

MES·CIM 연계는 MQTT·HTTP API·DB 인터페이스를 통해 검토해요. 적용 범위는 현장 계약에 정의된 인터페이스와 공식 자료로 확인해요. HTTP API는 업무 서버 계약, MQTT는 실시간 분배, MySQL은 외부 이력에 무게가 있어요. EASY LOGGER의 Runtime Status와 Payload Log를 보고 외부 DB의 DB History와 조회 결과를 대조해요.

한 장치의 계약을 먼저 검증해요

압력센서 한 대와 D0100 한 주소만 선택해 현장 표시값, PLC 원시값, bar 값, API payload의 수집 시각을 기록해요. 외부 스키마 중복을 줄이려면 line_id와 collected_at을 묶은 외부 키 기준을 운영팀과 정해요.

EASY LOGGER의 Runtime Status에서 수집·전달 상태를 보고 Payload Log에서 필드를 확인해요. MySQL은 DB History와 외부 스키마 pressure_history 예시 테이블의 같은 시각 값을 비교해요.

현재값과 마지막 수신 시각, 전달 상태, 외부 이력을 함께 확인하는 운영 화면 개념도예요.

EASY LOGGER MQTT 예제

line_pressure가 예시 PLC 주소 맵의 D0100과 대응한다고 가정해요. XBMPLC와 PRESSURE_READ는 예시 PLC명·설정명이므로 실제 현장 주소 맵과 대조해요. READ·WRITE Topic은 Automatic Topic Preview에서, 상태는 Runtime Status와 Payload Log에서 확인해요.

READ TOPIC: XBMPLC/PRESSURE_READ/READ
WRITE TOPIC: XBMPLC/PRESSURE_READ/WRITE

READ payload의 D0100 값이 values에 들어오고 collected_at이 수집 시각이라고 가정해요. 실제 필드와 타입은 주소 맵 및 수집 설정과 대조한 뒤 Payload Log에서 확인해요.

{
  "plc_name": "XBMPLC",
  "config_name": "PRESSURE_READ",
  "data_type": "float",
  "values": {"D0100": 4.2},
  "collected_at": "2026-08-16T15:00:00+09:00",
  "quality": "good"
}

Subscribe to the WRITE Topic.

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

WRITE payload도 테스트 주소 맵과 대조해요. Automatic Topic Preview에서 Topic을, Runtime Status에서 연결 상태를, Payload Log에서 수신 필드를 확인해요.

외부 시스템과 운영 화면을 잇는 순서

HTTP API는 endpoint, 인증 방식, 응답 코드, 중복 처리 키를 문서화해요. MQTT와 HTTP API를 함께 쓰면 원시 압력값·단위·수집 시각을 같은 기준으로 유지해요. MySQL은 외부 스키마 pressure_history에 line_id, collected_at, pressure_bar, quality를 저장하는 예시로 검토하고, 실제 컬럼과 보존 기간은 DB 담당자가 정해요. Firebase는 실시간 공유와 이력 화면의 필요성을 확인해요.

대시보드에서는 현재 압력, 마지막 수신 시각, 전달 상태를 함께 봐요. MES·CIM은 MQTT 구독, HTTP API 요청, 외부 DB 조회 중 업무 기준을 정하고 line_id와 collected_at으로 기록을 대조해요. 자세한 API 화면은 EASY LOGGER의 API 연동 설정 안내에서, 설치·주소·메뉴는 제품 매뉴얼 자료실에서 확인해 보세요. 전체 글 목록은 HT Automation 블로그에서, 제품 역할은 HT Automation 제품 안내에서 비교할 수 있어요.

현장 적용 전 마지막 점검

압력센서 모델, PLC 주소 맵, 단위·배율, HTTP API endpoint, MQTT Topic, 외부 MySQL 스키마, Firebase 사용 여부를 인터페이스 표에 모아요. 한 장치의 READ 흐름을 확인한 뒤 EASY-LINK만으로 연결을 끝낼지, EASY LOGGER로 저장 이력·전달 상태·대시보드까지 관리할지 판단해요.

전송 방식은 운영 질문에 맞춰 선택해요. 여러 소비자가 즉시 받아야 하면 MQTT를, 업무 서버 계약이 중요하면 HTTP API를, 기간별 외부 이력이 중심이면 MySQL을 우선 검토하고 현재 상태 공유가 핵심이면 Firebase도 비교해요. 현장 연결 가능 여부를 확인하려면 센서 출력, PLC 주소 맵, HTTP API endpoint, MQTT Topic, 외부 MySQL 스키마와 운영 화면 담당자를 먼저 정리해 보세요. 이 확인 결과를 바탕으로 EASY-LINK만으로 충분한지 EASY LOGGER의 저장 이력·전달 상태·대시보드 운영까지 필요한지 판단할 수 있어요.

#EASY-LINK #EASY LOGGER #스마트팩토리 #압력센서 #HTTP API #MySQL #MQTT #데이터베이스 설계 #Firebase #산업용 IoT 게이트웨이