식품공장 세척수 온도 기록, MQTT와 MySQL을 운영 기준으로 나누는 방법

먼저 결론부터 볼게요

안녕하세요. 식품공장에서 세척수 온도를 기록할 때는 현재값을 빠르게 받는 경로와 나중에 다시 찾을 수 있는 이력 경로를 나눠 보는 게 좋아요. MQTT는 브로커를 통해 온도 변화를 실시간으로 전달하기 좋고, MySQL은 외부 시스템이 정한 스키마에 기록해 세척 시작 전·순환 중·종료 후를 비교하기 좋아요. 둘 중 하나만 고르는 문제라기보다 MQTT로 흐름을 확인하고 외부 MySQL에 보존하는 구성이 운영 판단에 맞는지 확인하는 문제예요.

이번 글에서는 세척수 탱크 한 곳의 온도센서 필드 하나에서 시작해요. 실제 PLC 주소와 데이터 타입은 현장 필드 주소 맵을 먼저 승인해야 하며, 아래의 WASH_TEMP_01, D0100, 설정명은 주소 맵과 대조하기 위한 예시예요. 센서 식별자, 측정 시각, 단위, 원시 주소를 한 묶음으로 기록하면 값이 변한 것과 메시지가 끊긴 것을 구분하기 쉬워요.

세척수 온도 기록에서 먼저 맞출 기준

세척수 온도는 값만 저장하면 공정 시점을 다시 읽기 어려워요. 세척 시작 전·순환 중·종료 후를 비교하려면 센서 식별자, 측정 시각, 단위, PLC 주소, 수집 설정명을 함께 남겨야 해요. WASH_TEMP_01을 PLC D0100에 매핑한다는 표현은 설명용 예시이며, 실제 주소와 스케일은 현장 필드 주소 맵과 대조해야 해요.

세척 전후의 판단 기준과 저장 위치를 먼저 정하면 제품 선택이 뒤섞이지 않아요. 현장 표시값과 원시값의 시각을 맞추고, 어떤 기록을 얼마나 보존할지도 함께 정해야 해요. 이 준비가 끝난 뒤 연결과 운영 역할을 나누면 검증 결과를 설명하기 쉬워져요.

이 단계에서는 허용 주소 범위와 저장 주기를 먼저 좁혀요. 값이 정상인지 확인할 때는 현장 화면, 수집 로그, 외부 기록을 같은 시간순으로 놓고 비교해요. 한 번에 여러 탱크를 연결하면 원인이 섞일 수 있으니 첫 검증의 범위를 작게 정하는 게 좋아요.

현장 담당자가 확인할 순서와 기록 양식도 이때 정해 두면 좋아요. 검증 날짜와 담당 화면도 함께 적어 두면 다음 단계의 비교가 빨라져요.

이 기준을 잡은 뒤 EASY-LINK는 센서나 PLC와 목적지 사이의 현장 연결·전달 계층에 잘 맞고, EASY LOGGER는 수집 이력·전달 상태·DB 조회·대시보드 운영을 함께 확인해야 할 때 도움이 돼요. 한 현장에서 MQTT와 외부 MySQL 한 경로만 우선 검증한다면 EASY-LINK만으로 충분할 수 있어요. 여러 설정의 상태와 이력을 계속 관리해야 한다면 EASY LOGGER를 함께 검토하는 편이 좋아요. 제품의 PLC·센서 연결과 전송 범위는 EASY 제품의 PLC·센서 연결과 전송 범위에서, 설정 항목은 DB 조회 및 보존 설정 매뉴얼에서 확인할 수 있어요. 전체 글 목록에서 MQTT·DB 운영 주제를 더 찾으려면 기술 블로그 글 목록을 참고해도 좋아요.

EASY-LINK는 현장 센서·PLC와 MQTT 및 외부 DB 전송 경계를 연결하는 공식 제품 이미지예요.

MQTT와 MySQL을 비교해 목적지를 정해요

MQTT는 발행·구독 구조라 외부 모니터링 클라이언트나 상위 시스템이 같은 온도 흐름을 받아야 할 때 유리해요. Automatic Topic Preview로 주소를 확인하고 Runtime Status에서 브로커 연결 상태를 살펴보면 전달 문제를 좁히기 쉬워요. 다만 MQTT 메시지만으로 장기간 이력을 검색하려면 별도의 저장 정책과 외부 스키마가 필요해요.

MySQL은 외부 시스템이 정한 테이블과 컬럼으로 보존하고 기간·주소·설정명으로 검색할 때 적합해요. MQTT가 현재 흐름과 전달 속도에 초점을 둔다면 MySQL은 기록의 검색성과 보존에 초점을 둬요. HTTP API는 외부 서버의 요청·응답 계약이 명확할 때, Firebase는 웹 대시보드에서 상태를 공유할 때 비교할 수 있어요. 즉 MQTT, HTTP API, MySQL, Firebase는 우열보다 확인할 운영 지점이 달라요. 세척 전후의 온도 이력을 다시 찾아야 한다면 MQTT와 MySQL을 함께 비교하고, 실시간 전달만 필요하면 MQTT 단독 범위를 먼저 확인해도 돼요. MQTT와 HTTP API 전달 방식을 비교한 운영 글에서도 목적지 선택 기준을 이어서 볼 수 있어요.

세척수 온도를 작은 범위에서 검증해요

처음에는 탱크 한 곳과 온도센서 한 개만 선택해 현장 표시값, PLC 원시값, MQTT payload, 외부 DB 레코드를 같은 시각에 기록해요. 정상 범위는 임의로 정하지 말고 공정 문서와 센서 사양으로 승인해야 해요. 이처럼 한 장치·한 공정에서 시작하는 단계적 도입 방법을 적용하면 주소 오류, 단위 오류, 전달 지연을 한꺼번에 섞지 않고 확인할 수 있어요.

세척수 온도 필드 WASH_TEMP_01이 PLC D0100에 매핑된다는 설정은 예시이며 실제 적용 전 현장 필드 주소 맵과 대조해야 해요. XBMPLC, WASH_TEMP, D0100은 공식 Topic·payload 형식을 설명하기 위한 예시 이름이에요. Automatic Topic Preview에서 실제 설정의 READ Topic을 확인한 뒤 Runtime Status와 Payload Log에서 같은 시각의 수집 상태와 payload를 비교해요.

READ TOPIC: XBMPLC/WASH_TEMP/READ

위 Topic에서 D0100이 세척수 온도 필드로 읽히는지는 현장 주소 맵과 대조해야 해요. 아래 payload의 timestamp, values, 주소 키는 확인된 MQTT payload 형태를 따른 예시이며, 값의 단위와 실제 주소는 현장 설정을 기준으로 바꿔야 해요. MQTT 화면의 Automatic Topic Preview와 Runtime Status, Payload Log에서 Topic·수집 시각·값을 순서대로 확인하면 돼요.

{
  "plc_name": "XBMPLC",
  "config_name": "WASH_TEMP",
  "data_type": "float",
  "timestamp": "2026-08-14T09:00:00",
  "values": {"D0100": 23.7}
}

EASY LOGGER MySQL 예제

세척수 온도 필드 WASH_TEMP_01과 PLC D0100의 대응은 예시이며 실제 DB 컬럼·주소는 현장 필드 주소 맵과 외부 스키마 문서에 맞춰 대조해야 해요. 아래 SQL의 plant_quality 스키마와 temperature_history 테이블은 EASY LOGGER 내부 스키마가 아니라 외부 시스템이 관리하는 예시 스키마예요. DB Connection Configuration에서 승인된 외부 접속 정보를 사용하고, DB History Logs에서 저장 성공·오류와 Config·Address를 확인해요. 이 흐름은 외부 기록을 검색하는 데이터베이스 설계 기준으로 볼 수 있어요.

SELECT event_time, config_name, address, value
FROM plant_quality.temperature_history
WHERE address = 'D0100'
  AND event_time >= '2026-08-14 00:00:00'
ORDER BY event_time DESC
LIMIT 100;

이 조회는 외부 스키마의 기록을 기간과 주소로 검색하는 예시예요. D0100이 실제 세척수 온도 주소인지, value가 섭씨 단위인지, event_time이 수집 시각인지 외부 스키마와 주소 맵을 함께 대조해야 해요. DB History Logs에서는 저장 결과와 오류 이력을 먼저 보고, 외부 MySQL 조회 결과에서는 세척 전후의 기록이 실제로 검색되는지 확인해요. 보존 기간과 오래된 기록 정리 기준도 외부 DB 운영 정책으로 정하고 필요한 검색 기간을 먼저 합의해야 해요.

EASY LOGGER는 수집 이력, DB 저장 결과, 전달 상태와 운영 화면을 이어 보는 공식 제품 이미지예요.

운영 전에 확인할 경계

EASY-LINK만으로 충분한 경우는 한 현장의 센서·PLC 값을 MQTT나 MySQL로 전달하고 연결 상태만 확인하면 되는 경우예요. EASY LOGGER를 더하면 여러 수집 설정의 이력, 외부 DB 저장 결과, 마지막 수신 시각과 대시보드 운영을 한 흐름으로 확인하기 좋아요. 두 제품을 함께 사용하더라도 EASY-LINK가 EASY LOGGER의 대시보드 역할을 대신한다고 가정하지 않고, 현장 연결 계층과 데이터 운영 계층을 나눠 설계해야 해요.

상위 시스템과 연계할 때도 확인된 MQTT, HTTP API 또는 DB 인터페이스 범위 안에서 계약을 정해야 해요. 외부 스키마와 전송 권한, 보존 기간을 담당자와 먼저 맞추는 편이 안전해요. MQTT는 실시간 전달에, MySQL은 외부 이력 검색에, HTTP API는 요청·응답 계약에, Firebase는 웹 상태 공유에 각각 강점이 있으므로 목적에 맞춰 범위를 좁혀요.

마지막으로 현장 표시값과 D0100 원시값이 같은 시각에 맞는지, Automatic Topic Preview의 READ Topic이 실제 설정과 일치하는지, Runtime Status와 Payload Log에 수신 흔적이 있는지, DB History Logs와 외부 MySQL SELECT 결과가 연결되는지를 순서대로 확인해요. 이 네 가지가 맞으면 세척수 온도가 들어왔다는 사실과 나중에 운영 판단에 쓸 수 있는 기록이라는 사실을 분리해서 확인할 수 있어요.

현장 연결 가능 여부는 현재 센서 모델, PLC 주소 맵, MQTT 권한, 외부 MySQL 스키마와 보존 정책만 먼저 정리해도 부담 없이 좁혀볼 수 있어요.