식품공장 CIP 세정액 pH 값을 MC Protocol로 읽어 대시보드에 남기는 구성
CIP 세정 공정에서 pH 값을 남겨야 하는 이유
식품공장 모니터링 현장에서 CIP(Clean-In-Place, 배관과 탱크를 분해하지 않고 세정하는 방식) 공정은 알칼리 세정, 중간 헹굼, 산 세정, 최종 헹굼이 정해진 순서로 이어집니다. 세정액의 pH가 설계 구간을 벗어나면 오염이 덜 씻기거나 세정제가 남을 수 있습니다. 그런데 이 값은 대개 PLC 안에서만 잠깐 존재하다가 배치가 끝나면 사라집니다.
값을 남겨 두면 운영 판단이 달라집니다. 어제 배치와 오늘 배치의 pH 추세를 나란히 비교할 수 있고, 헹굼 시간이 길어진 이유를 이력으로 되짚을 수 있습니다. 위생 점검 자료를 만들 때도 담당자의 기억이 아니라 기록으로 설명하게 됩니다.
식품의약품안전처는 「식품 및 축산물 안전관리인증기준」 일부개정고시(안) 행정예고에서 중요관리점 자동 기록관리시스템 등록업소의 연장심사 가점 대상 업종을 넓히는 내용을 다뤘습니다. 기록을 사람이 옮겨 적는 대신 장비가 남기는 방향으로 움직인다는 뜻입니다. 제품 구성은 HT Automation 제품 소개에서, 다른 현장 사례는 기술 블로그 글 목록에서 확인하실 수 있습니다.
pH 센서 값을 MC Protocol로 읽어 오는 구성
현장 pH 센서는 4-20mA 신호를 아날로그 입력으로 보내고, Mitsubishi PLC가 이를 공학값으로 바꿔 데이터 레지스터에 담습니다. 수집 장치는 이 레지스터를 주기적으로 읽기만 하면 됩니다. MAIN 설정 화면에서 CONNECTION PROTOCOL을 MC Protocol 3E로 고르면 입력란이 그 프로토콜에 맞게 바뀌고, PLC NAME, IP ADDRESS, PORT, MC Frame, PLC Type을 채운 뒤 연결 테스트를 거쳐 PLC 저장을 누릅니다.
PLC NAME과 CONFIG NAME은 뒤에서 만들 외부 연동 주소의 기준이 되므로 처음 등록할 때 현장에서 통하는 이름으로 정합니다. 실제 등록 값은 다음과 같은 형태입니다.
CONNECTION PROTOCOL: MC Protocol 3E
PLC NAME: CIP1_PH
CONFIG NAME: CIP_PH_MON
PLC SELECT: CIP1_PH
TRIGGER TYPE: Timer
DATA TYPE: FLOAT
시작 번지: ZR8000
수집요청주기: 1000 ms
디바이스 수: 4
FLOAT은 값 하나가 2 Word를 쓰므로 한 설정에서 최대 200개까지 읽습니다. 설정 저장을 누른 뒤 저장 설정 목록의 STATUS가 RUNNING으로 바뀌면 수집이 도는 상태이고, FAULT가 뜨면 접속 정보와 주소 범위부터 다시 확인합니다.
세정액 측정값이 현장 제어기에서 수집 계층으로 전달되는 경로
EASY-LINK와 EASY LOGGER의 역할 경계
EASY-LINK는 현장 신호와 상위 네트워크 사이에 놓이는 산업용 IoT 게이트웨이입니다. 세정 스키드처럼 PLC 랙에서 떨어진 위치의 값을 수집해 MQTT로 보내고, 상위 장비가 그 메시지를 구독해 받습니다. 수집 조건에는 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES, TRIGGER, STALE AFTER (MS)를 넣으며, STALE AFTER (MS) 동안 수신이 없으면 값이 null로 저장되고 결함으로 표시됩니다.
EASY LOGGER는 그 데이터를 다루는 운영 계층입니다. 수집 주기를 관리하고 MariaDB·MySQL 또는 내부 CSV로 값을 남기며, 같은 값을 MQTT, HTTP API, OPC-UA로 내보냅니다. EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인하면, 값이 안 보일 때 수집이 멈춘 것인지 전달만 끊긴 것인지 구분할 수 있습니다.
EASY LOGGER 대시보드 예제
세정 담당자에게 필요한 것은 조회 화면입니다. 대시보드 메뉴는 앞에서 등록한 CIP_PH_MON 설정의 값을 표시 전용으로 배치하는 화면이며, 이 예제에서는 조작 기능을 두지 않고 읽기만 하는 구성으로 만듭니다.
Dashboard 화면은 위젯 네 개로 구성합니다. 첫 번째 게이지 widget에는 ZR8000의 current value를 pH 단위로 표시하고, 두 번째 상태 위젯에는 마지막 수신 시각을 last reception time 필드로 둡니다. 세 번째 위젯에는 브로커로 값이 나가고 있는지를 delivery state 필드로 표시하고, 네 번째 그래프 위젯에는 최근 24시간 history를 추세선으로 배치합니다.
확인 순서는 단순합니다. 세정이 시작되면 current value가 알칼리 구간에서 산 구간으로 넘어가는지, last reception time이 수집요청주기에 맞춰 갱신되는지, delivery state가 유지되는지, history 그래프에 끊긴 구간이 없는지 차례로 봅니다. 값이 멈춰 있으면 화면 아래 상태 표시등에서 PLC와 MQTT 항목을 먼저 확인합니다.
MQTT·HTTP API·MySQL·Firebase 중 무엇으로 내보낼 것인가
이 구성의 주 전달 대상은 MQTT입니다. MQTT 설정 화면에서 MQTT Server, Port, User, Password, TLS, Publish, Retain을 지정하고 Enable을 켜면 수집값이 발행되며, 토픽은 PLC이름/CONFIG이름/READ 형태로 만들어집니다. 앞에서 정한 이름이 그대로 주소가 됩니다.
CIP1_PH/CIP_PH_MON/READ
MQTT는 값이 갱신되는 대로 여러 구독자에게 동시에 전달되어 표시 화면과 알람을 함께 붙이기 좋습니다. 다만 브로커가 끊기면 그 구간의 전달이 비고, 기간 조회는 브로커가 대신해 주지 않습니다. HTTP API는 요청과 응답이 하나씩 맞물려 방화벽 정책이 엄격한 망에서 승인받기 쉽지만, 주기가 짧아질수록 호출 수가 그대로 늘어납니다.
MySQL은 기간 조회와 이력 제출 자료를 만들 때 강합니다. DB 설정에서 DB Name, Host Address, Port, User, Password를 넣고 연결 테스트를 거치면 되지만, DB 서버 운영과 보존 기간 관리가 함께 따라옵니다. Firebase는 외부 망의 모바일 화면을 빨리 붙일 때 편한 대신 사내 데이터가 외부 클라우드로 나가므로 보안 검토가 먼저입니다. 실무에서는 실시간 전달을 MQTT에, 조회를 데이터베이스에 맡기는 조합이 무난합니다.
수집한 값이 조회 화면과 상위 시스템으로 나뉘어 전달되는 구조
MES·CIM 상위 시스템과 잇는 인터페이스 경계
상위 시스템 연계는 경계를 먼저 긋는 편이 안전합니다. MES나 CIM이 배치 단위 결과만 필요로 한다면 발행된 MQTT 메시지를 중계 서버가 받아 정리하는 방식이 단순하고, 상위 시스템이 조회 위주라면 MySQL 데이터베이스를 공용 접점으로 두고 기간 조회를 맡기는 편이 낫습니다. 어느 쪽이든 수집 계층은 값을 내보내는 인터페이스까지 책임지고, 판정 로직과 업무 화면은 상위 시스템의 몫으로 남깁니다.
MES·CIM에 전용 커넥터가 있다고 전제로 하지 않습니다. MQTT, HTTP API, 데이터베이스 세 가지 표준 인터페이스 가운데 하나로 맞춰 두면 상위 시스템이 바뀌어도 수집 쪽 설정은 그대로 쓸 수 있습니다.
한 공정에서 시작해 범위를 넓히는 순서
처음부터 라인 전체를 붙일 필요는 없습니다. CIP 스키드 한 공정에 pH 하나만 Timer 수집으로 등록하고, 대시보드 위젯 네 개와 MQTT 발행까지 2주 정도 돌려 보면 수집 주기, 저장량, 끊김 빈도가 실제 숫자로 나옵니다. 그다음 유량과 온도를 같은 방식으로 추가하고 라인 단위로 범위를 넓히면 됩니다.
한국식품안전관리인증원이 스마트HACCP 기술지원 업체 정보를 공공데이터포털에 공개하고 있는 것처럼, 기록의 디지털화는 이미 진행 중인 흐름입니다. 도입을 결정하기 전에 현장 연결 가능 여부만 먼저 확인해 보셔도 됩니다. 사용 중인 PLC 기종과 통신 포트, 읽어야 할 주소 목록만 정리되어 있으면 검토가 가능합니다. 같은 식품공장 사례로는 세척수 탱크 수위 기록을 MySQL 스키마로 설계한 구성을 함께 보시면 도움이 됩니다.