원격 설비 진동 데이터를 HTTP API와 Firebase로 운영하는 기준

먼저 결론부터 볼게요

원격 설비의 진동 데이터는 숫자가 들어오는지만 확인하면 운영 판단이 끝나지 않아요. 진동값, 단위, 측정 시각, 설비 식별자와 마지막 수신 시각을 함께 남겨야 지금 값과 오래된 값, 측정 문제와 전달 문제를 나눠 볼 수 있어요. 특히 사람이 자주 가기 어려운 설비는 정상 범위보다 데이터가 언제 갱신됐는지를 먼저 확인하는 흐름이 필요해요.

이번 글은 진동센서 한 대와 원격 설비 한 곳에서 시작해요. 진동 필드가 예시 PLC 주소 D0100에 대응한다고 가정하지만, D0100, REMOTEVIB01, VIBRATIONRMS는 현장 필드 주소 맵과 대조할 예시 이름이에요. 실제 주소, 배율, 단위와 수집 주기는 센서·PLC 문서와 운영 기준으로 확정해야 해요.

현재값보다 먼저 맞출 기준

첫 기록에는 설비 ID, 센서 ID, 원시 PLC 주소, 변환된 진동값, 단위, 측정 시각, 수집 시각과 전달 상태를 함께 적어요. 예를 들어 RMS 값이 VIBRATIONRMS로 들어온다면 mm/s인지 g인지부터 확인하고, 값이 만들어진 시각과 서버가 받은 시각을 분리해요. 그래야 화면에 값이 보이지만 마지막 수신 시각이 오래된 상황을 별도로 분류할 수 있어요.

원격 설비는 네트워크 지연이나 전원 상태가 현장마다 달라요. 그래서 처음부터 여러 대를 묶기보다 한 설비의 정상값, 경계값, 연결 단절과 재연결을 순서대로 기록하는 편이 좋아요. 이 기록은 진동 이상을 진단하는 근거라기보다 데이터를 믿고 다음 판단으로 넘어갈 수 있는 운영 기준이에요.

연결과 운영 역할을 나눠요

이 단계에서 EASY-LINK는 센서·PLC와 전달 대상 사이의 현장 연결과 전달 역할을 맡는 산업용 IoT 게이트웨이예요. HTTP API, MQTT, MySQL, Firebase 가운데 현장 계약에 맞는 경로로 값을 넘기는 범위를 검토할 수 있어요. 한 설비의 값을 정해진 서버로 보내고 연결 상태만 확인한다면 EASY-LINK만으로 충분할 수 있어요. 이 흐름은 센서 데이터 수집과 설비 데이터 수집의 책임 구간을 나누는 기준이기도 해요.

여러 원격 설비의 수집 이력과 전달 상태를 계속 확인하고, 운영자가 현재값과 마지막 수신 시각을 한 화면에서 살펴봐야 한다면 EASY LOGGER를 함께 검토해요. EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 맡는 계층으로 구분하고, EASY-LINK의 현장 연결 역할과 섞지 않는 게 좋아요.

EASY-LINK가 원격 설비의 센서·PLC 값과 외부 전달 경로를 잇는 역할을 보여주는 공식 이미지예요.

HTTP API, MQTT, Firebase와 외부 이력을 비교해요

HTTP API는 운영 서버가 정한 endpoint와 요청·응답 계약을 맞출 때 적합해요. 확인된 읽기 형식인 POST /api/read/{PLCNAME}/{CONFIGNAME}을 기준으로 보더라도 실제 호스트, 인증 헤더와 응답 필드는 외부 서버 계약으로 확정해야 해요. API 응답에 진동값, 단위와 collectedat이 함께 보존되는지 확인하면 값의 의미가 중간에서 바뀌었는지 좁혀 볼 수 있어요.

MQTT는 같은 상태 메시지를 여러 구독자가 받아야 할 때 비교하기 좋아요. Topic, broker 권한, 중복 처리 기준과 마지막 수신 시각을 함께 정해야 해요. Firebase는 현재 상태를 웹 화면에서 공유하고 시간순 이력을 확인하려는 경우에 비교할 수 있어요. 다만 Firebase에 저장됐다는 사실만으로 현장 수집이 계속됐다고 판단하지 말고, 수집 시각과 전달 상태를 함께 확인해요.

외부 MySQL은 운영팀이 정한 스키마와 테이블로 기간별 기록을 검색할 때 유용해요. MQTT가 실시간 분배, HTTP API가 업무 서버 계약, Firebase가 상태 공유에 초점을 둔다면 외부 MySQL은 보존과 검색에 무게가 있어요. MES·CIM과 연계할 때도 MQTT·HTTP API·DB 인터페이스 범위에서 목적과 책임 구간을 문서화해요. 확인되지 않은 전용 커넥터를 전제로 삼지 않아요.

EASY LOGGER MySQL 예제

아래 예시는 REMOTEVIB01의 진동 필드가 예시 PLC 주소 D0100에 대응한다고 가정한 외부 스키마 예제예요. ops_history 스키마와 vibration_history 테이블은 EASY LOGGER 내부 스키마가 아니라 운영팀이 관리하는 외부 스키마로 보고, 실제 필드·주소·컬럼은 현장 주소 맵과 외부 DB 문서에 대조해요. DB Connection Configuration에서 승인된 외부 접속 정보를 확인하고, DB History Logs에서 저장 성공·오류와 보존 상태를 먼저 살펴봐요.

SELECT asset_id, plc_address, vibration_rms, unit, measured_at, received_at
FROM ops_history.vibration_history
WHERE asset_id = 'REMOTEVIB01'
  AND plc_address = 'D0100'
ORDER BY measured_at DESC;

이 쿼리의 vibration_rms가 실제 진동 필드인지, measured_at과 received_at이 각각 측정 시각과 수신 시각인지 외부 스키마와 주소 맵으로 확인해요. DB History Logs의 저장 결과와 외부 조회 결과를 같은 시간대에 대조하면 저장 누락과 현장 측정 지연을 나눠 볼 수 있어요. 보존 기간과 오래된 기록 정리 기준도 외부 DB 운영 정책으로 정해요.

EASY LOGGER에서 수집 이력과 전달 상태, 운영 화면을 함께 확인하는 역할을 보여주는 공식 이미지예요.

작은 범위에서 운영을 시작해요

1단계에서는 한 설비의 한 진동 필드만 읽고 현장 표시값, PLC 원시값, HTTP API 응답, Firebase 기록과 외부 DB 레코드의 시각을 맞춰요. 2단계에서는 Runtime Status에서 연결 상태와 마지막 정상 수신 시각을 보고, Payload Log에서 필드와 단위를 확인해요. 3단계에서 설비를 늘리면서 Dashboard에서 현재 진동값과 마지막 수신 시각을 분리해 보여줘요.

진동값의 정상 범위는 임의로 정하지 말고 설비 담당자와 센서 문서로 승인해요. 수집이 끊겼을 때는 마지막 값만 정상처럼 보이지 않도록 상태 필드를 별도로 운영하고, 재연결 뒤 누락 구간과 중복 기록을 함께 확인해요. 운영 권한은 필요한 화면과 외부 저장 범위로 좁히고, 설비 제어와 연결된 변경은 별도 승인 절차로 다뤄요.

관련 제품 범위는 HT Automation 제품 안내에서 비교하고, 설치·주소·화면 설정은 제품 매뉴얼 자료실에서 버전과 함께 대조해 보세요. 다른 원격 설비 운영 관점은 HT Automation 블로그 글 목록과 원격지 시설물 상태 운영 글에서 함께 살펴볼 수 있어요. 원격 설비 진동 데이터 운영의 출발점은 제품을 먼저 늘리는 일이 아니라 현재 센서 모델, PLC 주소 맵, endpoint, Firebase 사용 목적, 외부 스키마와 담당 화면을 한 장에 맞추는 일이에요. 현장 연결 가능 여부를 가볍게 확인하려면 이 항목만 먼저 정리해 담당자와 범위를 맞춰 보세요.