공장 설비 진동 데이터를 MQTT로 운영 판단에 연결하는 순서

먼저 진동 데이터가 필요한 이유부터 볼게요

공장 설비의 진동값은 숫자를 오래 모으는 것보다 점검 순서를 정하는 데 의미가 있어요. 같은 설비에서 평소와 다른 변화가 언제 시작됐는지, 부하나 생산 조건이 바뀐 뒤에도 변화가 이어지는지, 통신이 끊긴 뒤 어느 시점부터 다시 믿을 수 있는지를 함께 봐야 해요. 현재값 하나만 보면 순간적인 튐과 실제 추세를 구분하기 어렵고, 이력만 보면 지금 연결이 살아 있는지 놓칠 수 있어요.

그래서 첫 운영 질문은 ‘진동이 높으냐’가 아니라 ‘어느 설비의 어떤 필드가 변했고, 담당자가 다음에 무엇을 확인할 것인가’로 잡는 게 좋아요. 진동센서 표시값, PLC 원시값, 전송 payload의 측정 시각, 마지막 수신 시각을 같은 기준으로 남기면 센서·주소·전달 구간을 나눠 확인할 수 있어요. 처음부터 전체 라인을 묶기보다 한 대의 회전 설비와 한 측정 필드로 시작해 경계값과 재연결 뒤 첫 값을 비교하는 편이 운영 판단에 유리해요.

현장 필드와 PLC 주소를 먼저 맞춰요

예시로 MOTOR_LINE01의 BearingVibration 필드가 LS PLC의 D3200과 대응한다고 가정해요. 이 PLC명과 필드명, 주소는 설명을 위한 샘플이므로 실제 진동센서 사양, 데이터 타입, 단위, 배율과 현장 field address map을 대조해 확정해야 해요. D3200이 원시 정수인지 실수인지, 진동의 단위와 변환식이 무엇인지, 측정 시각과 수신 시각을 어느 필드로 기록할지도 주소 표에 함께 남겨요.

이 단계에서 LS PLC 데이터 수집과 공정 병목을 보는 글을 참고하면 주소와 운영 질문을 분리해 적는 데 도움이 돼요. 장치별 통신 항목과 설정 순서는 제품 매뉴얼 자료실에서 대조할 수 있어요.

EASY-LINK는 확인된 현장 PLC·센서 필드를 연결하고 MQTT로 목적지에 전달하는 연결 계층이에요. 한 대의 설비에서 한 필드를 읽어 MQTT로 보내는 범위라면 EASY-LINK만으로 충분할 수 있어요. EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 맡는 운영 계층이에요. 여러 설비의 이력과 담당자별 화면이 필요해지면 EASY LOGGER를 더하고, EASY-LINK의 현장 주소는 실제 주소 맵으로 따로 확인해요.

확인된 PLC와 센서 필드를 목적지로 전달하는 연결 계층이에요.

MQTT와 다른 전달 경로를 비교해요

MQTT는 진동 상태를 Topic으로 나눠 여러 화면이나 저장 소비자에 전달할 때 검토하기 좋아요. HTTP API는 외부 운영 서버가 정한 endpoint와 요청·응답 계약을 맞출 때 비교하고, MySQL은 외부 스키마와 테이블을 운영팀이 관리하며 기간별 이력을 조회할 때 살펴봐요. Firebase는 웹이나 모바일 화면에서 현재 상태를 빠르게 보여줄 때 검토할 수 있어요. 어떤 방식이든 deviceId, field, value, measuredAt, receivedAt의 의미를 먼저 고정해야 해요.

MQTT는 실시간 전달과 구독 구조가 장점이고, HTTP API는 요청 결과를 확인하기 쉬워요. MySQL은 외부 스키마의 조회·보관 정책이 분명할 때 적합하고, Firebase는 화면 갱신과 권한 범위를 별도로 설계해야 해요. MES나 CIM 같은 상위 시스템은 MQTT, HTTP API 또는 DB 인터페이스로 연계 범위를 협의해요. 이 글의 핵심은 PLC 연동과 센서 데이터 수집을 한 흐름으로 보고, MQTT 전달 뒤 데이터 연동과 원격 모니터링을 운영 기준으로 비교하는 데 있어요. 확인되지 않은 전용 커넥터를 전제로 하지 않고, 상위 화면에서도 같은 필드 의미와 시간 기준이 유지되는지 확인해요.

EASY LOGGER를 쓰면 현장 연결 자체보다 운영 확인점에 집중할 수 있어요. 현재값은 값의 크기를, Runtime Status는 연결 상태와 마지막 수신 시각을, Payload Log는 실제 전달 형식을, DB History는 시간대별 변화를 보여주는 식으로 역할을 나눠요. 한 공정에서 기준이 맞으면 작게 범위를 넓히며 설비 ID와 주소가 섞이지 않는지 확인해요.

저장 이력과 전달 상태를 운영 화면에서 확인하는 계층이에요.

한 대에서 운영 확인 순서를 잡아요

먼저 진동센서 표시값과 D3200 원시값을 같은 시각에 적어요. 다음으로 변환된 단위값, MQTT payload의 measuredAt, 수신 화면의 receivedAt을 비교해요. 정상값만 보지 말고 경계값, 센서 단절, PLC 통신 단절, MQTT 재연결 뒤 첫 payload를 차례로 기록해야 해요. 값은 정상 범위인데 receivedAt이 오래됐다면 측정과 전달을 같은 문제로 판단하지 않도록 표시를 나눠요.

운영자는 Dashboard에서 현재값과 추세를 보고, Runtime Status에서 연결 상태를 확인한 뒤 Payload Log에서 필드와 시간을 대조해요. DB History에서는 같은 deviceId와 field가 시간 순서대로 쌓이는지 확인해요. 화면이 제어 명령을 대신한다고 해석하지 않고, 현장 점검과 승인 절차는 별도로 유지해요.

EASY LOGGER MQTT 예제

아래의 MOTOR_LINE01, BearingVibration, D3200은 예시 이름과 주소예요. 진동센서의 BearingVibration 필드가 LS PLC의 D3200 주소와 대응한다고 가정했으므로, 실제 설정에서는 field address map, PLC 데이터 타입, 단위를 대조해야 해요. Automatic Topic Preview에서 READ Topic과 WRITE Topic을 확인하고, Runtime Status에서 연결·수집 상태를 본 뒤 Payload Log에서 실제 수신 payload를 확인해요.

READ TOPIC: MOTOR_LINE01/BearingVibration/READ
WRITE TOPIC: MOTOR_LINE01/BearingVibration/WRITE

READ payload는 D3200의 변환된 진동값을 values에 담는 형식으로 설명한 예시예요. 아래 PLC명·설정명·데이터 타입과 주소는 현장 주소 맵과 대조한 뒤 사용해요.

{
  "plc_name": "MOTOR_LINE01",
  "config_name": "BearingVibration",
  "data_type": "float",
  "values": {"D3200": 2.4}
}

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

Automatic Topic Preview에서 Topic 이름을 먼저 확인하고, Runtime Status에서 마지막 수신 시각을 확인해요. Payload Log에서는 values.D3200이 주소 맵의 진동 필드와 맞는지 보고, DB History에서는 같은 deviceId의 변화가 이어지는지 확인해요. 이 순서를 거치면 값이 튄 원인을 센서, PLC 주소, MQTT 전달 중 어느 구간에서 먼저 좁힐지 정할 수 있어요.

운영 범위를 단계적으로 넓혀요

한 대에서 기준을 맞춘 뒤 한 공정으로 늘리고, 설비 ID와 주소 표가 유지될 때 범위를 넓혀요. MQTT는 상태 전달, HTTP API는 외부 요청 결과, MySQL은 외부 이력 조회, Firebase는 화면 표시라는 목적을 나눠 비교하면 선택 이유가 분명해져요. EASY-LINK만으로 연결·전달이 충분한지, EASY LOGGER의 저장 이력·전달 상태·대시보드가 필요한지는 담당자가 확인할 화면과 보관 책임으로 결정해요.

현장 연결 가능 여부를 확인하고 싶다면 진동센서 모델, LS PLC 주소 맵, 단위와 배율, MQTT 권한, 필요한 Dashboard 항목을 정리해 상담이나 문의로 확인해 보세요. 한 대에서 작게 검증한 뒤 현장 연결 가능 여부를 확인하고 단계적으로 범위를 넓히면 운영팀이 다음 점검 순서를 더 명확히 정할 수 있어요.