식품공장 세척수 온도, Mitsubishi MC와 MQTT로 기록하는 방법

세척수 온도는 한 번 확인하고 끝내는 숫자보다 공정 시점과 함께 다시 비교할 수 있는 기록으로 남길 때 활용도가 커져요. 세척 시작 전, 순환 중, 종료 후의 값을 같은 시간축에 놓으면 온도 변화와 통신 공백을 구분하기 쉬워져요. 오늘은 식품공장 세척수 탱크 한 곳의 온도센서 값을 Mitsubishi MC로 읽어 MQTT로 전달하는 구성을 살펴볼게요.

식품안전나라 안내는 온도와 시간을 함께 확인하고 기록하는 운영을 설명해요. 이 글은 특정 공정의 법적 기준이나 HACCP 인증·심사 결과를 대신하지 않아요. 적용 기준은 사업장 문서와 최신 공식 규정을 따로 확인하고, 여기서는 센서 값의 출처·시각·전달 상태를 남기는 흐름에 집중해요.

세척수 온도를 왜 기록할까요

먼저 wash_water_temperature, 단위, 센서 식별자, 측정 시각, 공정 단계, 수집 상태를 한 묶음으로 정해 보세요. 세척 전 준비, 세척 진행, 보충 또는 배출처럼 현장에서 쓰는 작업 식별자를 함께 저장하면 특정 시간대의 온도 변화를 다시 찾기 쉬워져요. 값이 달라졌을 때 센서 상태, 공정 변화, 주소 해석, 네트워크 지연을 순서대로 나눠 볼 수도 있어요.

실제 Mitsubishi MC 주소는 장치 매뉴얼과 현장 주소 맵을 기준으로 정해야 해요. 예시로 D0100을 쓰더라도 실제 주소를 의미하지 않으며, 데이터 타입과 배율·단위를 먼저 확인해야 해요. 현장 표시값, PLC 원시값, 변환한 온도, MQTT payload를 같은 시각에 적으면 최초 기준점이 생겨요.

온도 데이터를 모으는 이유는 숫자를 많이 쌓기 위해서가 아니에요. 세척 과정에서 언제 값이 변했는지, 마지막 정상 수신이 언제였는지, 기록할 수 없는 구간이 어디였는지를 구분해 다음 확인 순서를 정하는 데 있어요. 최근 식품 및 축산물 안전관리인증기준 개정 자료도 자동 기록관리 시스템과 현장평가의 적용 범위를 나누어 다루므로, 장비가 기록을 만든다는 사실과 현장 기준의 적용 판단을 구분해요.

온도 필드가 PLC 주소에서 MQTT 전달 경로로 이어지는 흐름을 추상화한 그림이에요.

주소와 기록 기준을 맞춰요

점검표에는 센서 모델, Mitsubishi MC 통신 조건, PLC 주소, 데이터 타입, 배율, 단위, 수집 주기, 마지막 정상 수신 시각을 적어 보세요. 통신 설정이 맞아도 주소 오프셋이나 바이트 순서가 다르면 값은 그럴듯하게 보일 수 있어요. 정상값 하나만 보지 말고 세척 전후 변화를 현장 표시와 함께 확인하는 편이 좋아요.

수집 주기는 온도 변화 속도와 담당자가 확인할 간격을 기준으로 정하면 돼요. 값이 정상 범위여도 마지막 수신 시각이 오래됐다면 센서가 정상이라고 단정하지 말고 PLC 응답과 네트워크 전달 상태를 따로 확인해요. 온도 기록은 품질 판단의 모든 조건을 대신하지 않으므로 작업 기준과 이상 시 조치 문서에 연결해 사용해요.

EASY-LINK와 EASY LOGGER를 구분해요

EASY-LINK는 현장 연결 계층의 게이트웨이예요. Mitsubishi MC에서 PLC 데이터를 수집하고 MQTT, HTTP API, MySQL, Firebase로 전달하는 데이터 수집·전달 역할을 맡아요. 온도센서 한 대와 주소 한 구간을 정해진 목적지로 보내는 구성은 EASY-LINK만으로 충분할 수 있지만, 센서 교정이나 공정 기준의 승인·법적 판단을 대신하지는 않아요.

EASY LOGGER는 데이터 로거이자 운영 계층이에요. 여러 장치의 수집 주기, 저장 이력, 전달 상태, 대시보드를 함께 관리해야 할 때 활용 범위를 넓힐 수 있어요. 대시보드는 EASY-LINK 단독 내장 기능으로 설명하지 않고 EASY LOGGER의 통합 관리 범위로 구분해요. 여러 탱크의 이력과 마지막 전달 상태를 함께 확인해야 한다면 EASY LOGGER를 더하는 구성이 자연스러워요.

주 전달 대상은 MQTT로 두고 목적지 요구에 따라 비교해 보세요. MQTT는 발행·구독으로 여러 소비자에게 전달하기 좋고, HTTP API는 요청·응답과 오류 코드를 확인하는 상위 애플리케이션에 맞아요. MySQL은 장기 이력과 조건 검색에 유리하며, Firebase는 모바일·웹의 현재 상태 공유를 검토할 때 후보가 돼요. 이 프로토콜 비교는 우열이 아니라 수신 방식과 보존 요구를 맞추는 과정이에요. MES·CIM은 MQTT, HTTP API 또는 DB 인터페이스를 통한 연계 범위로만 설명해요.

EASY LOGGER MQTT 예제

아래는 형식을 확인하기 위한 예시예요. wash_water_temperature가 Mitsubishi MC의 D0100 주소와 대응한다고 가정했지만 실제 PLC 주소 맵과 데이터 타입을 대조해야 해요. 코드 블록 앞에서 필드와 주소의 관계를 확인하고 Automatic Topic Preview에서 READ Topic과 WRITE Topic을 살펴본 뒤 Runtime Status에서 수집·전달 상태를, Payload Log에서 온도값과 시각을 확인해요.

{
  "READ Topic":"factory/wash-tank-01/temperature/READ",
  "WRITE Topic":"factory/wash-tank-01/temperature/WRITE",
  "device_id":"TEMP-01",
  "values":{"D0100":68},
  "unit":"celsius",
  "measured_at":"2026-08-12T09:00:00+09:00"
}

Subscribe to the WRITE Topic.

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

D0100과 wash_water_temperature 매핑은 실제 주소표와 대조한 뒤 사용해요. READ Topic은 수집 경로를, WRITE Topic은 제어가 필요한 경우의 경계를 보여주는 예시예요. Automatic Topic Preview, Runtime Status, Payload Log의 시각이 맞는지 확인하면 값과 전달 상태를 섞지 않고 판단할 수 있어요.

한 탱크에서 이력을 넓혀요

첫 단계에서는 세척수 탱크 한 곳의 온도센서와 Mitsubishi MC 주소 하나만 연결해 현장 표시값과 MQTT payload를 비교해 보세요. 다음에는 세척 시작·종료 식별자와 마지막 정상 수신 시각을 저장하고, 통신 단절·재연결 때 누락 구간을 표시해요. 다른 탱크를 추가할 때는 토픽 이름과 단위를 그대로 복사하지 말고 탱크별 센서 맵을 다시 확인해야 해요.

세척 공정 기록 시점은 식품공장 세척수 유량 이력 기준에서, 상위 기록과 MQTT·DB 경계는 CCP 기록과 MySQL 이력 설계에서 참고할 수 있어요. 제품 설정은 제품 자료실의 매뉴얼에서 현재 버전과 대조해 주세요.

한 장치의 현재값과 저장 이력을 확인한 뒤 여러 지점으로 넓히는 운영 흐름이에요.

구매를 서두르기보다 센서 모델, Mitsubishi MC 주소와 데이터 타입, MQTT 목적지, 필요한 보존 이력, 담당자가 볼 화면을 적어 보세요. 이 정보로 현장 연결 가능 여부를 확인하면 EASY-LINK만 필요한지 EASY LOGGER까지 필요한지 부담 없이 좁혀 볼 수 있어요. 식품 관련 기준은 식품 및 축산물 안전관리인증기준 개정 자료, 온도·시간 기록은 식품안전나라 자료에서 최신 적용 범위를 확인해 주세요.