스마트 HACCP 압력 데이터, OPC UA와 Firebase 대시보드로 운영하는 기준

먼저 결론부터 볼게요

식품공장 모니터링에서 압력 값 하나가 화면에 보인다고 운영 기준이 끝나는 것은 아니에요. 현재값이 얼마인지, 언제 마지막으로 들어왔는지, Firebase로 전달된 상태가 어떤지, 지난 시간의 이력이 이어지는지를 함께 봐야 다음 점검을 정할 수 있어요. 식품의약품안전처는 스마트 HACCP을 IoT로 중요공정 모니터링 데이터를 자동 기록·관리하고 확인·평가하는 시스템으로 설명하고 있어요. 이 글은 그 정책이나 인증을 대신 판단하지 않고, 압력 신호를 수집·확인하는 데이터 흐름만 다뤄요.

처음부터 여러 공정과 모든 위젯을 만들기보다 냉각 설비의 대표 압력 신호 하나로 시작해 보세요. 센서와 PLC 또는 OPC UA 서버에서 같은 시각의 값이 읽히는지 확인하고, 수집 계층과 Firebase 전달 계층을 분리하면 값이 달라진 지점을 좁히기 쉬워요. 실제 주소, Node ID, 단위와 배율은 장비 매뉴얼과 현장 필드 주소 맵으로 대조해야 하며, 아래 이름과 값은 그 맵에 맞추기 위한 예시예요.

압력 신호를 먼저 이름과 시간으로 묶어요

예시 필드 이름을 cold_room_pressure로 정하고 압력센서의 단위, 데이터 타입, 배율, source timestamp를 함께 기록해요. PLC의 원시값과 표시값을 같은 시각에 남기면 OPC UA에서 읽은 값이 잘못된 주소인지, 변환 과정에서 배율이 달라졌는지 구분할 수 있어요. 마지막 수신 시각은 원본 측정 시각과 다른 값일 수 있으므로 둘을 하나로 덮지 않는 편이 좋아요.

이때 EASY-LINK와 EASY LOGGER의 역할도 나눠 보세요. 현장 장치와 PLC의 연결 변환만 필요하면 EASY-LINK 중심으로 검토할 수 있어요. 여러 신호의 수집 이력, 전달 상태와 대시보드 운영을 한곳에서 관리하려면 EASY LOGGER가 더 잘 맞아요. EASY-LINK가 현장 연결 계층에서 데이터 전달을 맡고 EASY LOGGER가 데이터 로거와 운영 계층을 맡는다는 식으로 책임을 나누면 제품을 무조건 함께 써야 한다는 판단을 피할 수 있어요. EASY-LINK는 현장 장치·PLC에서 값을 읽어 필요한 전달 경로로 넘기는 데 충분하고, 여러 신호의 이력·전달 상태·Dashboard 운영이 필요할 때 EASY LOGGER를 추가하는 경계예요.

센서와 PLC·OPC UA 값에서 시작해 수집, 이력, 외부 전달과 운영 화면으로 이어지는 데이터 흐름을 추상화한 그림이에요.

Firebase를 주 전달 대상으로 고를 때 비교할 점

이번 조합의 주 전달 대상은 Firebase예요. 모바일·웹 화면에서 여러 지점의 상태를 빠르게 동기화해야 할 때 검토하기 좋은 경로지만, 이 선택이 모든 현장에 맞는 것은 아니에요. MQTT는 지속적인 이벤트 전달과 구독 구조가 필요할 때 유리하고, HTTP API는 상위 시스템의 요청·응답 계약에 맞춰 보내야 할 때 적합해요. MySQL은 외부 스키마에 장기 이력을 적재하고 정해진 쿼리로 조회해야 할 때 검토할 수 있어요. 예를 들어 외부 스키마 cold_chain_ops.measurements의 pressure_value, measured_at, quality를 조회하는 방식처럼 수신 측 계약을 먼저 정해야 하며, 이를 EASY LOGGER 내부 스키마라고 단정하면 안 돼요.

Firebase를 선택하면 현재값과 전달 결과를 화면에서 빠르게 확인하는 장점이 있지만, 이력 보존 기간·중복 이벤트 처리·권한 모델은 수신 시스템 문서와 운영 기준으로 별도 정해야 해요. MQTT는 연결이 끊긴 구간의 재전송과 구독 권한을, HTTP API는 endpoint·응답 코드·재시도 기준을, 외부 MySQL은 테이블·인덱스·중복 키를 먼저 확인해요. 무엇을 고르든 수집 상태와 외부 전달 상태를 같은 표시로 합치지 않는 것이 핵심이에요.

EASY LOGGER 대시보드 예제

필드 주소 맵에서 cold_room_pressure가 PLC의 예시 주소 D0100에 연결되고, OPC UA 서버가 이를 ns=2;s=EASY_LOGGER/Devices/FOODPLC/Tags/D0100 Node ID로 노출한다고 가정해 볼게요. 이 PLC명, 주소와 Node ID는 제품 기본값이 아니라 실제 필드 주소 맵과 대조하기 위한 예시예요. Dashboard에서 이 신호를 압력 위젯의 데이터 원천으로 연결하고, 위젯의 current value는 배율을 적용한 표시값, last receive time은 EASY LOGGER가 마지막으로 읽은 시각으로 구분해요.

{
  "field": "cold_room_pressure",
  "node_id": "ns=2;s=EASY_LOGGER/Devices/FOODPLC/Tags/D0100",
  "value": 0.42,
  "unit": "MPa",
  "source_timestamp": "2026-08-06T12:00:00Z",
  "quality": "good"
}

이 JSON은 실제 payload 계약을 대신하는 고정 형식이 아니라 필드와 Node ID의 대응을 설명하는 예시예요. Dashboard의 압력 카드에는 current value와 unit을 함께 보여 주고, 카드 아래에는 last receive time과 quality를 붙여 주세요. 별도 상태 영역에는 Firebase delivery state를 received, pending, error처럼 수신 측 계약에 맞춘 상태로 표시하고, 수집 성공과 전달 성공을 분리해 확인해야 해요. History 그래프에서는 같은 cold_room_pressure의 시간 범위를 선택해 값의 변화와 수신 공백을 함께 봐요.

현재값이 정상 범위처럼 보여도 last receive time이 오래됐다면 최신 측정으로 단정하면 안 돼요. delivery state가 오류라면 센서나 PLC보다 외부 전달 경로를 먼저 볼 수 있고, History에 공백이 있으면 수집 주기와 연결 상태를 다시 대조할 수 있어요. Dashboard 화면에서 현재값·마지막 수신 시각·전달 상태·이력이 한 흐름으로 이어져야 운영자가 어디를 확인할지 바로 정할 수 있어요. 이 화면은 식품 안전이나 HACCP 적합성을 보증하는 근거가 아니라, 현장 데이터 흐름을 점검하기 위한 운영 화면이에요.

대표 신호 하나에서 여러 지점과 상위 시스템으로 넓혀 가는 단계별 대시보드 운영 흐름이에요.

작은 범위에서 단계적으로 넓혀요

1단계에서는 압력센서 한 대의 필드 이름, PLC 주소, Node ID, 단위와 배율을 맞추고 Dashboard의 current value와 last receive time을 확인해요. 2단계에서는 여러 냉각 구역의 신호를 모으되 위젯 이름과 단위를 통일하고 Firebase delivery state를 수집 상태와 분리해요. 3단계에서는 외부 시스템과 이력을 연결하면서 수신 측 스키마, 중복 처리와 보존 기간을 정해요.

현장 적용 전에는 다섯 가지를 확인해 보세요. 필드 주소 맵과 Node ID가 일치하는지, source timestamp와 last receive time을 구분했는지, quality가 나쁜 값을 정상값으로 덮지 않았는지, Firebase 전달 상태를 별도 표시했는지, Dashboard History에서 공백과 급격한 변화를 조회할 수 있는지예요. 원격 제어나 쓰기가 필요한 범위는 이 글의 대상이 아니며, 별도 승인·인터록·수동 복구 절차로 분리해야 해요.

압력 신호 하나로 시작해 데이터가 어디서 읽히고 어디서 늦어지는지 확인하면 EASY-LINK만 필요한 구간과 EASY LOGGER까지 필요한 구간이 선명해져요. 다음 단계에서는 대표 신호의 필드 주소 맵과 수신 측 Firebase 계약을 먼저 맞춰 보세요. 구매를 서두르기보다 현장 연결 가능 여부를 먼저 확인해 보고, 주소 맵·Node ID·전달 계약이 맞는지부터 가볍게 점검해 보세요.