제조 설비 주기 데이터를 MQTT로 운영에 연결하는 기준과 확인 순서

먼저 결론부터 볼게요

제조 설비의 주기 데이터는 많이 모으는 것보다 어떤 운영 질문에 답하는지 먼저 정하는 게 중요해요. 생산 사이클이 예상보다 길어진 순간을 찾으려면 현재값만으로는 부족하고, 측정 시각과 설비 상태, 마지막 수신 시각을 함께 봐야 해요. 그래야 공정 변화와 통신 공백을 구분할 수 있어요.

처음에는 한 설비의 한 필드로 시작해요. 현장 표시값, PLC 원시 주소, 변환된 값, MQTT payload를 같은 시각에 기록하고, 값이 달라지는 지점을 찾아요. 수집 주기는 공정 변화보다 충분히 짧게 정하되, 담당자가 확인할 수 있는 이력과 보존 기간도 함께 적어야 해요.

주기 데이터가 필요한 이유는 설비를 감시하기 위해서만은 아니에요. 사이클이 길어진 구간을 생산 기록과 대조하고, 재연결 뒤 첫 값이 정상인지 확인하며, 다음 점검 대상을 좁히는 운영 근거가 되기 때문이에요. 이 글에서는 특정 설비의 성능을 단정하지 않고, 주소와 전달 계약을 맞추는 방법을 살펴볼게요.

필드 주소와 운영 질문을 맞춰요

주소 맵에는 설비 ID, 필드명, PLC 주소, 데이터 타입, 단위, 배율, 측정 시각, 품질 상태를 함께 적어요. 예를 들어 LINE01의 CycleTime이 PLC D120에 대응한다고 가정할 수 있어요. 이 이름과 주소는 설명을 위한 샘플이므로 실제 PLC 설정과 현장 field address map을 대조해 확정해야 해요. 정수인지 실수인지, 밀리초인지 초인지도 같은 표에서 확인해요.

운영 질문은 필드에 붙여서 정해요. 현재 사이클 시간이 기준 안에 있는지 보려면 현재값과 측정 시각이 필요하고, 직전 생산과 비교하려면 설비 ID와 작업 구간이 필요해요. 마지막 수신 시각이 멈췄다면 값이 정상 범위여도 통신 공백일 수 있으니 품질 상태와 전달 상태를 따로 남겨요.

EASY-LINK는 Mitsubishi PLC의 신호를 수집해 정해진 전달 대상으로 보내고, 그 뒤 단계는 맡지 않아요. 한 설비에서 PLC 필드와 MQTT 값이 맞는지 확인하고 정해진 목적지로 보내는 연결 역할이 필요할 때 충분한 출발점이 될 수 있어요.

현장 필드와 PLC 값이 MQTT·HTTP API·MySQL·Firebase로 나뉘어 전달되는 흐름을 보여줘요.

EASY LOGGER는 수집 주기와 저장 이력, 전달 상태, 대시보드 운영을 맡는 데이터 로거이자 운영 계층으로 구분해요. 여러 설비의 사이클 이력을 비교하거나 누락 시각과 전달 오류를 화면에서 추적해야 할 때 도움이 돼요. EASY-LINK만으로 저장 이력과 대시보드 운영까지 한다고 넓혀 말하지 않고, EASY LOGGER가 실제 주소를 임의로 확정한다고도 보지 않아요.

전달 방식을 비교해요

MQTT는 여러 소비자가 같은 변화 스트림을 구독할 때 검토하기 좋아요. HTTP API는 정해진 endpoint와 요청·응답 계약이 중요하고, MySQL은 운영팀이 관리하는 외부 스키마에서 기간별 기록을 조회할 때 비교해요. Firebase는 웹이나 모바일 화면에 현재 상태를 동기화할 때 살펴볼 수 있어요. 이 프로토콜 비교는 어느 방식이 항상 우수한지보다 소비자, 보존 책임, 권한 범위를 기준으로 해야 해요.

MES·CIM 같은 상위 시스템은 MQTT·HTTP API·DB 인터페이스로 확인된 연계 범위에서 설명해요. 외부 시스템이 받을 Topic, endpoint, 테이블 또는 데이터 계약을 먼저 정하고, 계약이 바뀌면 주소 맵과 운영 문서를 함께 갱신해요.

EASY LOGGER에서 MQTT를 선택할 때는 Automatic Topic Preview에서 READ Topic과 WRITE Topic을 확인하고, Runtime Status에서 연결 상태와 마지막 수신 시각을 봐요. Payload Log에서는 PLC 원시 필드와 변환값, 측정 시각이 같은 메시지에 들어갔는지 확인해요. 이 흐름을 EASY LOGGER MQTT 설정 화면과 확인 항목에서 더 자세히 대조할 수 있어요.

EASY LOGGER MQTT 예제

아래의 MITSUBISHI_LINE01, CycleTime, D120은 설명을 위한 샘플이에요. CycleTime 필드가 PLC D120과 대응한다고 가정했으므로 실제 사용 전 Mitsubishi PLC 설정과 현장 field address map을 대조해야 해요. Automatic Topic Preview에서 READ Topic과 WRITE Topic을 확인하고 Runtime Status와 Payload Log에서 같은 필드의 전달 상태를 확인해요.

READ TOPIC: MITSUBISHI_LINE01/CycleTime/READ
WRITE TOPIC: MITSUBISHI_LINE01/CycleTime/WRITE

READ payload는 D120의 주기 값을 values에 담는 형식으로 예시를 들 수 있어요. WRITE payload도 PLC 이름과 설정 이름, 데이터 타입, 주소를 실제 주소 맵과 대조한 뒤 시험 범위에서 확인해요.

{
  "plc_name": "MITSUBISHI_LINE01",
  "config_name": "CycleTime",
  "data_type": "word",
  "values": {"D120": 1840}
}

Automatic Topic Preview에서 Topic의 PLC명·설정명·READ/WRITE 구분을 확인하고 Runtime Status에서 연결 상태를 봐요. Payload Log에서는 D120, 측정 시각, 값, 품질 상태를 대조해요. 대시보드 운영이 필요하면 저장 이력과 전달 상태를 함께 연결하고, 제품 설정 항목을 확인할 수 있는 매뉴얼 자료실에서 실제 설정명을 다시 맞춰요.

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

WRITE는 시험 주소와 승인된 절차 안에서만 검토하고 운영 제어로 확대할지는 별도 승인과 인터록 조건을 확인해 판단해요.

작게 시작해 운영 범위를 넓혀요

처음에는 한 대의 설비와 한 공정의 CycleTime 필드만 선택해요. 정상 구간, 경계 구간, 센서 또는 PLC 통신 단절, 재연결 뒤 첫 수신값을 차례로 기록하면 어느 구간을 먼저 점검할지 선명해져요. 이후 단계적으로 필드를 늘릴 때는 주소 맵 버전, MQTT Topic, 보존 기간을 함께 남겨요.

운영 화면에서 현재값과 전달 상태를 확인한 뒤 한 설비에서 여러 설비로 범위를 넓히는 순서예요.

데이터 추세 분석을 할 때는 주기 값만 그리지 말고 작업 구간, 품질 상태, 마지막 수신 시각을 함께 표시해요. 값이 갑자기 변한 것처럼 보여도 측정 시각이 밀렸거나 재연결 뒤 중복된 값일 수 있어요. 통신 장애 점검 항목에는 브로커 연결, 권한, Topic, 주소 맵, 수집 주기를 순서대로 적고 담당자별 확인 화면을 나눠요.

제품 외형과 역할도 구분해서 봐요. EASY-LINK는 현장 PLC 신호를 수집해 정해진 대상으로 보내는 연결 계층이고, EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 확인하는 운영 계층이에요. 한 설비의 전달만 필요하면 EASY-LINK 범위가 충분할 수 있고, 여러 설비의 이력 비교와 화면 운영까지 필요하면 EASY LOGGER를 더해 검토해요.

현장 연결 가능 여부를 확인하려면 설비 모델, Mitsubishi PLC 주소 맵, MQTT Topic, 수집 주기, 필요한 화면을 정리해 상담이나 문의로 이어가 보세요.

근거와 적용 경계

HT Automation 공식 제품 자료는 EASY-LINK가 Mitsubishi MC를 수집 프로토콜로 다루고 MQTT·HTTP API·MySQL·Firebase를 전송 대상으로 설명해요. EASY LOGGER 공식 MQTT 설정 자료는 Automatic Topic Preview, Runtime Status, Payload Log의 확인 흐름을 제시해요. 이 글의 샘플 PLC명·주소·값은 실제 현장 설정이 아니라 주소 맵과 대조하기 위한 예시예요.