스마트 HACCP 온도 기록, HTTP API와 MySQL로 빠짐없이 남기는 법

냉장고 온도가 화면에 잘 보이면 기록 관리도 끝난 걸까요? 실제로는 센서 값이 표시되는 것과 그 값이 빠짐없이 저장되는 것은 다른 문제예요. 네트워크가 잠깐 끊기거나 장치 시각이 달라지면 화면은 정상처럼 보여도 이력에는 빈 구간이나 중복 행이 생길 수 있어요.

식품의약품안전처의 스마트 HACCP 설명처럼 중요관리점 모니터링 데이터를 실시간으로 자동 기록·관리·확인·저장하려면, 숫자 하나보다 데이터가 생성되고 보관되는 전체 흐름을 봐야 해요. 센서 데이터 수집과 데이터 연동 시스템을 설치하는 것만으로 사업장의 인증 요건이 충족되는 것은 아니에요. 적용 기준과 기록 책임은 사업장 여건과 공식 절차에 맞춰 별도로 확인해야 해요.

먼저 ‘온도값 한 건’의 기준을 정해요

온도 기록에는 장치 ID, 설치 위치, 측정값, 단위, 현장 수집 시각, 서버 도착 시각과 상태를 함께 두는 편이 좋아요. ‘냉장실 3.2’만 남기면 어느 센서의 값인지, 언제 측정한 것인지 알기 어렵거든요. 센서를 교체하거나 위치를 옮겼다면 변경 시각과 작업자 확인 기록도 연결해 두세요.

수집 주기는 무조건 짧을수록 좋은 것이 아니에요. 센서 갱신 속도와 공정에서 확인할 변화, 저장 용량과 네트워크 상태를 함께 보고 정해야 해요. 경보 기준과 보관 기간은 해당 사업장의 HACCP 계획과 적용 기준을 따라야 하며, 통신 장비가 임의로 결정해 주는 값은 아니에요.

온도센서에서 제어반, 게이트웨이, 로거와 데이터베이스까지 각 구간의 상태를 따로 확인해요.

HTTP API는 재전송까지 생각해요

HTTP API는 정해진 서버에 데이터를 보내고 응답을 확인하기 쉬운 방식이에요. 다만 응답이 늦었다고 서버가 받지 못한 것은 아닐 수 있어요. 같은 온도 기록을 다시 전송해도 한 건으로 처리되도록 장치 ID, 측정 시각, 순번처럼 중복을 구분할 키를 수신 서버와 정해 두는 것이 좋아요.

응답 코드도 성공과 실패 두 종류로만 보지 마세요. 인증 오류, 입력 형식 오류, 일시적인 서버 장애를 구분해야 바로 수정할 요청과 나중에 다시 보낼 요청을 나눌 수 있어요. 전송에 실패한 자료를 어디에 얼마나 보관하고, 연결이 돌아온 뒤 어떤 순서로 보낼지도 운영 절차에 포함해요.

MySQL에는 원본과 운영 상태를 함께 저장해요

MySQL 테이블은 한 행이 어떤 측정 건인지 분명해야 해요. 장치 ID와 현장 수집 시각을 기본 축으로 두고, 위치, 값, 단위, 품질 상태, 서버 도착 시각과 원본 메시지 식별자를 함께 저장하면 결측과 중복을 확인하기 쉬워요. 장치 시각과 서버 시각을 둘 다 남기면 통신 지연과 실제 측정 시점을 구분하는 데 도움이 돼요.

화면용 보정값만 남기기보다 원본 값과 변환 규칙의 버전을 추적할 수 있게 준비해요. 센서를 교체하거나 배율을 바꿨을 때 과거 자료의 의미가 달라지는 일을 막을 수 있어요. 수정이 필요하다면 원본 행을 조용히 덮어쓰기보다 변경 이유와 시각이 남도록 운영하는 편이 기록을 설명하기 쉬워요.

정상·결측·중복을 서로 다른 상태로 표시하면 화면이 정상값을 보여도 기록 이상을 놓치지 않아요.

결측과 중복은 화면에서 바로 보여 주세요

마지막 정상 온도만 계속 보여 주면 통신이 끊겨도 냉장실이 안정적인 것처럼 보일 수 있어요. 현재값 옆에 마지막 수신 시각, 연속 실패 횟수와 통신 상태를 표시해 주세요. 그래프에서도 빈 구간을 앞뒤 값으로 임의 연결하기보다 결측으로 구분해야 운영자가 실제 기록 상태를 알아볼 수 있어요.

중복 행은 합계나 평균을 왜곡할 수 있어요. 데이터베이스에서 고유 기준을 두고, 재전송된 기록은 별도 로그로 확인할 수 있게 해요. 정상 수집만 시험하지 말고 센서 분리, 네트워크 단절, 서버 중지와 복구를 작은 범위에서 순서대로 확인하면 예상하지 못한 기록 방식을 미리 발견할 수 있어요. 실제 식품 보관 조건을 바꾸는 시험은 피하고, 안전한 테스트 환경과 담당자 승인 아래 진행해야 해요.

EASY-LINK와 EASY-TEMP는 현장 연결을 간단하게 해요

기존 온도센서나 PLC가 Modbus RTU/TCP를 제공한다면 EASY-LINK는 그 값을 HTTP API나 MySQL로 전달하는 연결 계층으로 검토할 수 있어요. 장비마다 별도 프로그램을 만들지 않고 수집 주소와 전달 대상을 정리하는 데 도움이 돼요. 새 온·습도 채널이 필요하다면 EASY-TEMP의 PT100·DHT22 지원 범위와 현장 설치 조건을 함께 비교할 수 있어요.

EASY-LINK나 EASY-TEMP가 냉장·냉동 기준과 HACCP 관리 항목을 대신 정하는 것은 아니에요. 센서 정확도와 설치 위치, 보정 방법은 정확한 센서 사양과 사업장 기준을 확인해야 해요. 제품의 역할은 확인된 현장 값을 상위 시스템으로 일관되게 연결하는 데 있어요.

EASY LOGGER가 있으면 저장과 운영을 한곳에서 봐요

센서 한두 대를 정해진 서버로 보내는 정도라면 EASY-LINK 또는 EASY-TEMP부터 시작할 수 있어요. 반면 EASY LOGGER는 여러 냉장·냉동 구역과 PLC 데이터를 모아 DB 저장, 대시보드, MQTT·HTTP API 전달과 WireGuard VPN 원격 관리를 함께 맡는 상위 운영 계층으로 잘 맞아요.

EASY LOGGER를 두는 이유는 장비를 하나 더 추가하기 위해서가 아니라, 수집 상태와 저장 이력, 전달 로그를 같은 기준으로 확인하기 위해서예요. 어느 구역에서 언제 데이터가 멈췄는지 빨리 찾고, 복구 뒤 누락과 중복을 확인할 수 있어야 기록 자동화가 담당자의 일을 실제로 줄여 줘요.

도입 전에는 이 항목을 확인해 보세요

• 센서 ID, 위치, 측정·도착 시각과 상태가 함께 저장되나요?
• HTTP API 재전송 때 중복을 막을 기준이 있나요?
• 네트워크 단절 중 자료 보관과 복구 순서가 정해졌나요?
• MySQL에서 원본 값과 변환 규칙을 추적할 수 있나요?
• 화면에 마지막 수신 시각과 결측 구간이 분명히 보이나요?
• HACCP 관리 기준과 보관 기간을 공식 절차에 맞춰 확인했나요?
• 한 구역에서 단절·복구까지 검증한 뒤 확대하나요?

구체적인 저장 화면은 EASY LOGGER DB 설정 방법, 전송 흐름은 EASY LOGGER API 설정 방법에서 이어서 확인할 수 있어요. 다른 자료는 기술 블로그에서 살펴보세요. 현재 온도센서 모델과 구역 수, 필요한 보관 기간, 연동할 서버를 정리한 뒤 HT Automation 홈페이지에서 현장 연결 가능 여부를 편하게 문의해 주세요. 꼭 필요한 범위부터 함께 좁혀드릴게요.