살균 공정의 온도와 유지 시간을 MySQL에 기록하는 구성

살균 기록이 남아야 판단이 가능합니다

식품공장의 살균 공정은 한계기준을 지켰는지가 그날 생산분의 출하 여부를 가릅니다. 온도가 몇 도까지 올라갔고 그 온도를 몇 분 유지했는지가 남아 있지 않으면 나중에 되짚을 근거가 사라집니다. 종이 기록지는 작업자가 정해진 시각에 값을 옮겨 적는 방식이라 그 사이 구간이 비어 있습니다.

식품의약품안전처 자료는 가열 조리 식품의 중심부를 74℃ 이상에서 1분 이상 가열하고, 식품용 온도계로 온도와 시간을 기록하도록 안내합니다. 판정 기준이 분 단위라면 기록 간격도 그보다 촘촘해야 합니다. 기준과 기록의 해상도가 어긋나면 경계 구간에서 판단이 흔들립니다.

자동 기록이 실제로 돕는 운영 판단

기록이 초 단위로 쌓이면 배치별 승온 곡선을 겹쳐 볼 수 있습니다. 같은 제품을 같은 설정으로 돌렸는데 승온에 걸리는 시간이 조금씩 길어진다면, 열교환기 세정이나 스팀 트랩 점검 시점을 앞당길 근거가 됩니다. 이런 판단은 하루 몇 번 적는 종이 기록지로는 나오기 어렵습니다.

한계기준을 벗어난 순간을 놓치지 않는 것도 중요합니다. 유지 구간 중간에 온도가 잠깐 떨어졌다면 자동 기록에는 그 골이 그대로 남지만, 정시 기록에서는 사라집니다. 개선 조치를 언제 취했는지도 같은 표에서 시각으로 확인됩니다.

제도 측면의 이유도 있습니다. 식품의약품안전처는 중요관리점 자동 기록관리 시스템 등록업소의 연장심사 가점 적용 범위를 냉장·냉동업 등으로 넓히는 개정을 고시했습니다. 현장 부담을 줄이면서 심사에서도 유리해지는 방향입니다.

살균기 제어반에서 무엇을 읽을지 정합니다

살균기 제어반은 Modbus TCP를 지원하는 경우가 많습니다. 챔버 온도, 유지 타이머, 스팀 밸브 상태, 배치 번호가 각각 레지스터로 열려 있으므로 판정에 필요한 주소만 골라 읽습니다. 챔버에 꽂힌 온도센서 값은 제어반이 이미 보정해 두었으므로 그 값을 그대로 받는 편이 안전합니다.

주소를 고를 때는 세 가지를 함께 봅니다. 판정에 쓰는 살균 온도, 유지 시간을 세는 타이머, 배치를 구분하는 번호입니다. 이 세 가지가 같은 시각에 한 줄로 남아야 몇 번 배치가 몇 분 유지됐는지를 말할 수 있습니다. 주기는 1초 이하로 잡되, 짧게 잡을수록 제어반과 네트워크 부하가 늘어난다는 점을 함께 봅니다.

수집 계층과 저장 계층을 나눠 구성합니다

EASY-LINK는 살균기 제어반과 상위 저장 계층 사이에서 연결 역할을 맡는 산업용 IoT 게이트웨이입니다. Modbus TCP로 제어반 레지스터에서 데이터를 수집해 정해진 토픽으로 올려 보냅니다. 제어반 사양이 바뀌어도 이 계층만 손보면 되므로 설비 데이터 수집 경로가 단순해집니다.

EASY LOGGER는 그 값을 받아 쌓고 내보내는 운영 계층입니다. MAIN 설정에서 PLC NAME과 CONFIG NAME을 등록하면 그 이름이 MQTT 토픽과 HTTP API 엔드포인트, OPC-UA 노드 경로에 그대로 들어가므로 처음부터 현장에서 통하는 이름으로 정합니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다.

상위 MES나 CIM과 붙일 때도 구조는 같습니다. MQTT나 HTTP API 인터페이스로 값을 넘기거나, 데이터베이스를 직접 조회하는 방식 중 현장 정책에 맞는 쪽을 고르는 데이터 연동 형태입니다.

제어반의 온도와 유지 시간이 한 경로로 모여 기록으로 남습니다

EASY LOGGER MySQL 예제

DB 설정 화면에서 저장 위치를 잡습니다. Host Address에 DB 서버 주소, Port에 MariaDB와 MySQL 기본값인 3306, DB Name과 User, Password를 채우고 연결 테스트로 접속을 확인한 뒤 설정 저장을 누릅니다. 테이블은 수집 설정 이름으로 만들어지고 Timestamp, Config, Address, Value 컬럼이 들어갑니다. 저장된 값은 외부 DB에 그대로 남아 품질 담당자가 기간별로 조회합니다. 품질 보고서 도구는 외부 쿼리로 배치 구간을 가져갑니다. 감사 자료를 만드는 담당자도 외부 테이블을 그대로 참조합니다.

DB Name       : HTA_STERILIZE
Host Address  : 192.168.0.30
Port          : 3306
User          : hta_reader
PLC NAME      : STERILIZER_A
CONFIG NAME   : STERILIZER_A_TEMP

SELECT Timestamp, Config, Address, Value
  FROM STERILIZER_A_TEMP
 WHERE Timestamp BETWEEN '2026-09-01 09:00:00' AND '2026-09-01 10:00:00'
   AND Address = 'D4000'
 ORDER BY Timestamp;

조회가 끝나면 화면 아래 STATUS 표시등의 DB가 정상인지 보고, DB 이력 로그(DB History)에서 전체 처리 건수와 성공률, 마지막 오류 시각을 확인합니다. 보존 기간(retention)은 DB 조회 화면의 DB TABLE DELETE에 지정하며, 매일 00:00에 기간이 지난 수집 데이터만 지웁니다. 필요한 구간은 조회 뒤 CSV 출력으로 뽑아 검색과 제출 자료로 씁니다.

MySQL과 MQTT, HTTP API를 나눠 쓰는 기준

이 구성의 주 전달 대상은 MySQL입니다. 기간 조회와 집계가 필요한 살균 기록에는 데이터베이스 설계가 분명한 MySQL이나 MariaDB가 맞습니다. 컬럼과 인덱스를 정해 두면 배치별 조회가 빨라지고 보존 정책도 한 곳에서 관리합니다. 다만 DB 서버와 계정 관리가 따로 필요합니다.

MQTT는 값이 바뀌는 즉시 여러 구독자에게 뿌리는 데 강합니다. 살균 시작과 종료 알림처럼 즉시성이 중요한 신호에 맞지만, 브로커는 장기 보관을 목적으로 하는 장치가 아닙니다. HTTP API는 상위 시스템이 필요한 시점에 끌어가는 방식이라 방화벽 정책이 단순하지만, 초 단위 연속 기록을 모두 받기에는 호출 수가 부담입니다. 실제 현장에서는 MySQL로 기록을 남기고 MQTT로 알림만 함께 내보내는 조합을 많이 씁니다.

배치별 승온 곡선과 저장 상태를 한 화면에서 확인합니다

한 대로 시작해 단계적으로 넓힙니다

식품공장 모니터링을 처음 붙이는 현장이라면 살균기 한 대로 시작합니다. 그 한 공정에서 온도와 유지 시간, 배치 번호가 정확히 남는지 2주 정도 확인하고 종이 기록지와 값을 맞춰 봅니다. 주소와 주기, 테이블 구조가 굳어지면 같은 설정을 복사해 단계적으로 라인 전체로 범위를 넓힙니다.

배치 기록을 다른 경로로 잇는 사례는 스마트 HACCP CCP 배치 기록 연동 글에 정리해 두었고, 제품 구성과 다른 현장 사례는 홈과 블로그 목록에서 확인하실 수 있습니다.

제어반 모델과 통신 포트, 읽을 주소 목록만 알려 주시면 현장 연결 가능 여부를 먼저 확인해 드립니다.