식품공장 세척수 탱크 수위 기록을 MySQL 스키마로 설계하는 구성

세척수 탱크 수위를 숫자로 남겨야 하는 이유

식품공장 세척 공정은 정해진 양의 세척수를 정해진 시간 동안 흘려보내야 합니다. 탱크 수위가 기준보다 낮으면 세척 압력과 시간이 함께 흔들리고, 그 영향은 다음 생산 배치의 위생 판정으로 이어집니다. 수위가 낮았던 사실을 뒤늦게 확인할 방법이 순찰 기록지뿐이라면 원인 구간을 좁히기 어렵습니다.

수위 값을 초 단위로 남겨 두면 세척 시작 시각, 최저 수위, 회복까지 걸린 시간을 숫자로 설명할 수 있습니다. 이 글은 수위센서 신호를 Mitsubishi PLC에서 읽어 MySQL 테이블로 남기고, 그 기록을 상위 시스템이 가져가도록 스키마부터 정하는 순서를 다룹니다. 비슷한 기록 구성은 살균 공정 기록 구성 글에서도 이어서 보실 수 있습니다.

계측·연결·운영 계층으로 역할 나누기

EASY-LOGGER는 세척수 탱크에 설치한 수위센서 신호를 현장에서 직접 읽는 계측·수집 장치로 씁니다. 아날로그 입력 채널에 신호 규격(4-20mA)과 공학 MIN/MAX, 단위를 등록해 두면 원시 값이 아니라 현장에서 쓰는 수위 값으로 올라옵니다. 단선 검출은 4-20mA에서만 켤 수 있으므로 신호 규격을 먼저 확정합니다.

EASY-LINK는 그 값을 MQTT로 발행해 상위 장비에 붙이는 연결 역할을 맡습니다. 받는 쪽에서는 SUBSCRIBE TOPIC과 ROOT KEY, ADDRESSES를 지정해 필요한 주소키만 받고, 수신이 끊기면 STALE AFTER (MS)에 정한 시간이 지난 뒤 값을 null로 남깁니다.

EASY LOGGER는 저장과 화면을 담당하는 운영 계층입니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인할 수 있어, 값이 비어 있는 구간이 수집 문제인지 전달 문제인지 구분할 수 있습니다.

현장 계측에서 저장과 화면까지 한 줄로 이어지는 경로

MC Protocol로 수위 값을 읽는 수집 조건

MAIN 설정의 PLC 연결 설정에서 CONNECTION PROTOCOL을 MC Protocol 3E/4E로 고르고 IP ADDRESS, PORT, MC Frame, PLC Type을 채웁니다. PLC NAME은 MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로의 기준이 되므로 나중에 바꾸기 어렵습니다. CIP_LINE1처럼 현장에서 통하는 이름으로 정하고, 연결 테스트가 성공한 뒤에 PLC 저장을 누릅니다.

수집 조건 설정에서는 CONFIG NAME을 CIP_TANK_LEVEL로 두고 PLC SELECT에서 앞서 저장한 PLC를 고릅니다. TRIGGER TYPE은 Timer, DATA TYPE은 WORD, 시작 번지는 D2400, 수집요청주기는 1000ms로 넣습니다. WORD와 BIT는 한 설정에 최대 400개까지 읽으므로 설비 데이터 수집 범위는 실제로 필요한 주소만 잡는 편이 안정적입니다. 저장한 뒤 저장 설정 목록의 STATUS가 RUNNING으로 바뀌는지 확인합니다.

기록 테이블 스키마를 먼저 정하는 순서

데이터베이스 설계는 DB 설정 화면에서 시작합니다. DB Name과 Host Address, Port를 넣는데 자체 DB 저장이면 127.0.0.1이고 MariaDB와 MySQL의 기본 Port는 3306입니다. User와 Password를 넣고 연결 테스트로 접속을 확인한 뒤 설정 저장을 누릅니다. DB 저장과 로컬 CSV 저장은 동시에 켤 수 없으므로 현장에 DB 서버가 있는지부터 정리해야 합니다.

테이블은 수집 설정 이름을 따라 만들어집니다. 그래서 CONFIG NAME을 정하는 순간 사실상 테이블 이름이 정해집니다. 조회 결과에 나오는 항목은 Timestamp, Config, Address, Value이므로 상위 시스템에 넘길 필드도 이 네 가지에 맞추면 변환 단계가 줄어듭니다. 보존 기간은 DB TABLE DELETE에 지정하며, 매일 00:00에 기간이 지난 수집 데이터만 지우고 테이블 구조는 그대로 둡니다.

수집 주소와 기록 항목을 같은 기준으로 맞춘 저장 구조

EASY LOGGER MySQL 예제

앞에서 만든 CIP_TANK_LEVEL 테이블을 그대로 읽어 봅니다. 저장된 값은 외부 데이터베이스에 그대로 남아 품질 담당자가 조회합니다. 스키마가 DB 조회 화면의 결과 항목과 같은 형태이므로, 기간과 주소를 조건으로 준 SELECT 쿼리 한 줄이면 세척 구간 검색이 끝납니다. 보존 기간(retention)을 90일로 잡았다면 그 범위 안에서 조회됩니다.

SELECT Timestamp, Config, Address, Value
FROM CIP_TANK_LEVEL
WHERE Address = 'D2400'
  AND Timestamp BETWEEN '2026-09-06 06:00:00' AND '2026-09-06 18:00:00'
ORDER BY Timestamp DESC;

같은 구간을 화면에서 보려면 DB 조회에서 테이블을 고르고 기간 설정의 24H를 누른 뒤 조회를 실행합니다. 결과에 Timestamp, Config, Address, Value가 나오고 화면 아래 STATUS 표시등의 DB가 정상이면 저장 경로가 살아 있는 상태입니다. 값이 빠진 구간이 보이면 DB 이력 로그(DB History)에서 전체 처리 건수와 성공률, 마지막 오류 시각을 확인합니다.

MQTT·HTTP API·Firebase와 비교한 MySQL 기록

이 구성의 주 전달 대상은 MySQL입니다. 기간 조건으로 지난 구간을 다시 뽑아야 하는 위생 기록에는 관계형 데이터베이스가 가장 단순하지만, 값을 실시간으로 흘려보내는 용도로는 무거운 편입니다.

MQTT는 값이 바뀔 때마다 가볍게 보낼 수 있고 여러 구독자가 같은 값을 나눠 보기 좋으나, 브로커가 끊긴 구간은 기록으로 남지 않습니다. HTTP API는 상위 시스템이 필요할 때 끌어가는 구조라 방화벽 정책을 정리하기 쉬운 반면 주기가 짧아지면 요청 수가 부담이 됩니다. Firebase는 외부 앱 화면을 빠르게 붙일 때 유리하지만 사내망 밖으로 데이터가 나가는 점을 먼저 검토해야 합니다.

MES나 CIM 같은 상위 시스템과는 이 가운데 필요한 인터페이스만 골라 연결합니다. 식품공장 모니터링 구성에서는 화면용 값은 MQTT 인터페이스로, 배치 단위 기록은 데이터베이스 조회로 나누는 방식이 무난합니다.

한 대부터 붙여 보는 순서

처음부터 모든 탱크를 연결할 이유는 없습니다. 세척수 탱크 한 대에 수집 조건 하나를 걸고 하루치 기록이 정상적으로 쌓이는지 본 다음, 같은 방식으로 단계적으로 대상을 늘리면 됩니다. 이때 볼 것은 STATUS가 RUNNING인지, DB 이력 로그의 성공률이 유지되는지 두 가지입니다.

현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다. 쓰고 계신 PLC 기종과 읽어야 할 주소, 저장 주기를 알려 주시면 구성 가능한 범위를 정리해 드립니다. 다른 사례는 블로그 목록에서, 제품 구성은 홈에서 보실 수 있습니다.