식품공장 보관 구역 습도를 한 대시보드에서 읽는 인터페이스 구성

보관 구역 습도 기록이 사람 손을 타는 이유

식품공장 보관·건조 구역의 습도는 제품 상태와 직결되지만, 기록은 여전히 순회 점검표에 남는 현장이 많습니다. 담당자가 하루 두세 번 값을 적는 방식으로는 그 사이 구간에 무슨 일이 있었는지 확인할 수 없습니다. 문제가 생긴 뒤 원인을 되짚으려 해도 참고할 자료가 사실상 남지 않습니다.

값을 자동으로 남기려면 구간을 셋으로 나누어야 합니다. 현장에서 값을 재는 계측 구간, 값을 서버까지 옮기는 연결 구간, 값을 쌓아 두고 보여 주는 운영 구간입니다. 이 글은 EASY LOGGER를 중심으로 세 구간의 인터페이스를 어떻게 정하는지 정리합니다. 제품 전반은 HT Automation 홈과 기술 블로그 목록에서 보실 수 있습니다.

계측 · 연결 · 저장으로 구간을 나눈 데이터 흐름

현장 계측 구간과 연결 구간 나누기

건조기와 공조 설비를 제어하는 Mitsubishi PLC가 이미 있다면 EASY LOGGER가 MC Protocol 3E/4E로 값을 직접 읽습니다. MAIN 설정의 CONNECTION PROTOCOL에서 프로토콜을 고른 뒤 IP ADDRESS, PORT, MC Frame, PLC Type을 넣고 연결 테스트를 거쳐 PLC 저장을 누릅니다. 이어서 수집 조건 설정에서 CONFIG NAME을 DRY_ROOM_RH처럼 정하고 TRIGGER TYPE은 Timer, DATA TYPE은 WORD로 고른 다음 시작 번지와 디바이스 수, 수집요청주기를 ms 단위로 입력합니다. PLC NAME과 CONFIG NAME은 이후 MQTT 토픽과 API 엔드포인트, OPC-UA 노드 경로의 기준이 되므로 처음에 현장에서 통하는 이름으로 정해 두십시오.

배선이 닿지 않는 창고 안쪽 습도센서는 EASY-LINK가 맡습니다. EASY-LINK는 센서 값을 읽어 MQTT로 보내고 EASY LOGGER가 그 토픽을 받는 게이트웨이 역할을 합니다. MAIN 설정에서 프로토콜을 EASY-LINK로 고르면 브로커 출처를 Self(관리자 MQTT 재사용)와 External(장치 브로커) 중에서 정하고, 수집 조건에는 SUBSCRIBE TOPIC, ROOT KEY, ADDRESSES, STALE AFTER (MS)를 넣습니다. STALE AFTER (MS)로 정한 시간 동안 수신이 없으면 값이 null로 저장되고 결함으로 표시되므로, 통신이 끊긴 구간과 값이 정상인 구간이 기록에서 구분됩니다.

EASY LOGGER는 이렇게 모인 값을 저장하고 내보내는 운영 계층입니다. 수집 주기마다 쌓인 값이 저장 이력으로 남고, 외부 시스템으로 나간 전달 상태까지 한 장비에서 통합 관리됩니다.

저장과 전달 인터페이스 고르기

이 구성에서 값이 가장 먼저 도착하는 주 전달 대상은 현장에 놓인 엣지 서버, 곧 EASY LOGGER 자체입니다. 저장과 표시를 현장에서 끝내는 엣지 컴퓨팅 구성이라 사무실 회선이 끊긴 동안에도 기록이 이어집니다. DB 설정 화면의 스위치를 ENABLE로 켜고 DB Name, Host Address, Port(MariaDB·MySQL 기본값 3306), User, Password를 입력한 뒤 연결 테스트를 거쳐 설정 저장을 누릅니다. 자체 저장이면 Host Address는 127.0.0.1입니다. DB 서버가 없는 현장은 로컬 CSV 저장으로 대신할 수 있으나, DB와 CSV는 동시에 켤 수 없습니다.

바깥으로 내보내는 경로는 성격이 다릅니다. 사내 MySQL 서버는 기간별 조회와 이력 제출 자료 작성에 강하지만 값이 바뀌는 즉시 알려 주지는 못합니다. MQTT는 값이 갱신될 때마다 가볍게 전달되어 알림과 화면 갱신에 맞지만, 브로커가 끊기면 그 구간이 비어 버리므로 기록 원본으로 삼기에는 부족합니다. HTTP API는 상위 시스템이 필요할 때 끌어가는 방식이라 방화벽 정책을 세우기 쉬운 대신 호출 주기만큼 지연이 생깁니다. Firebase는 외부에서 화면을 열기 편하지만 사내망 밖으로 데이터가 나가므로 반출 승인이 먼저입니다. 기록 원본은 엣지 서버의 MySQL에 두고 MQTT를 알림 경로로 함께 쓰는 조합을 권장합니다.

기록 원본과 실시간 전달 경로를 분리한 인터페이스 구성

EASY LOGGER 대시보드 예제

대시보드(Dashboard) 메뉴는 MAIN 설정에 등록한 CONFIG NAME을 그대로 불러와 화면을 만듭니다. 여기서는 조회와 표시 전용으로만 구성하고, 현장 담당자 계정은 권한을 monitor로 내려 값만 보도록 합니다. 건조실과 보관 구역을 한 화면에 올려 두면 교대 인수인계 때 따로 자료를 만들지 않아도 됩니다.

위젯(widget) 배치는 이렇게 잡습니다. 왼쪽 위 게이지 위젯에는 DRY_ROOM_RH의 현재값(current value)을 %RH 단위로 놓고 바로 아래 텍스트 필드에 마지막 수신 시각(last reception time)을 붙입니다. 오른쪽에는 EASY-LINK로 받는 주소키를 필드로 올려 창고 안쪽 습도센서 값을 같은 화면에 둡니다. 아래쪽에는 추세 그래프 위젯을 넓게 배치해 최근 24시간 이력(history)을 보여 주고, 그 옆에 DB 저장과 외부 발행의 전달 상태(delivery state)를 나타내는 필드를 둡니다.

값이 제대로 올라오는지는 두 곳에서 봅니다. 저장 설정 목록의 STATUS가 RUNNING인지 보고, 화면 맨 아래 DB·PLC·API·MQTT·OPCUA 상태 표시등이 정상인지 확인합니다. 그다음 EASY LOGGER 대시보드에서 저장 이력과 전달 상태를 함께 확인합니다. 그래프는 평평한데 마지막 수신 시각만 갱신된다면 값이 고정된 것이고, 수신 시각이 멈춰 있다면 연결 구간부터 봐야 합니다. 이 한 화면이 데이터 추세 분석과 원격 모니터링을 같은 자리에서 처리하는 기준점이 됩니다.

MES·CIM 상위 시스템과 잇는 지점

상위 MES·CIM과의 연계는 세 가지 인터페이스로 정리하면 충분합니다. 첫째는 MQTT 발행입니다. PLC NAME과 CONFIG NAME으로 만들어지는 토픽을 상위 시스템이 받아 화면을 갱신합니다. 둘째는 HTTP API입니다. 상위 시스템이 정해진 주기로 최신값을 요청해 가져가는 방식이라 방화벽에서 열어 줄 구간이 분명합니다. 셋째는 데이터베이스 조회입니다. MES가 엣지 서버에 쌓인 MySQL 테이블을 읽어 배치별 집계를 만듭니다.

세 경로 모두 CONFIG NAME이 열쇠이므로, 상위 시스템과 붙이기 전에 이름 규칙을 문서로 정해 두어야 합니다. 운영을 시작한 뒤 이름을 바꾸면 토픽과 엔드포인트, 노드 경로가 한꺼번에 달라집니다. 인증 계정도 등급을 나누어 상위 시스템에는 조회 권한만 주는 편이 안전합니다.

한 대부터 붙여 보는 순서

식품공장 모니터링을 처음 도입한다면 공장 전체를 한 번에 묶을 이유가 없습니다. 건조기 한 대와 보관 구역 한 곳만 EASY LOGGER에 연결해 2주 정도 값을 쌓아 보고, 그래프가 실제 운전과 맞는지 확인한 다음 단계적으로 범위를 넓히면 됩니다. 이 순서로 진행하면 주소 오기입이나 데이터 타입 불일치를 초기에 잡을 수 있습니다.

이미 다른 공정에 계측기가 들어가 있다면 살균 공정 기록을 MySQL에 남기는 구성도 함께 보시기 바랍니다. 도입 여부를 정하기 전에 보유하신 PLC 기종과 센서 목록만 알려 주시면 현장 연결 가능 여부만 먼저 확인해 드립니다. 필요하시면 상담 과정에서 수집 주기와 저장 방식까지 함께 정리해 드립니다.