검사 데이터를 HTTP API와 MQTT로 운영에 잇는 설계 기준

먼저 결론부터 볼게요

검사 데이터 연계는 어떤 프로토콜이 더 좋은지보다, 현장 값이 어느 화면과 판단까지 도착해야 하는지를 먼저 정하는 일이에요. 검사 모니터에서 나온 결과와 설비 상태를 한데 묶으면 불량 원인, 재검 대상, 라인 정지 여부를 구분하기 어려워져요. 그래서 센서·PLC의 원시값, 전송 메시지, 저장 기록, 운영 화면을 각각 확인할 수 있게 설계하는 편이 좋아요.

첫 단계에서는 검사 모니터 한 대와 진동센서 한 채널만 정해요. PLC 주소 또는 센서 필드, 값의 단위, 측정 시각, 판정 코드를 함께 적고 정상·경계·통신 단절을 순서대로 확인해요. 이 기준점이 있어야 HTTP API 응답이 늦은 것인지, MQTT 메시지가 끊긴 것인지, DB 기록이 누락된 것인지 나눠 볼 수 있어요.

스마트팩토리의 운영자는 숫자 하나보다 다음 행동을 알고 싶어 해요. 검사 결과가 기준을 벗어나면 재검을 할지, 설비를 멈출지, 담당자에게 알릴지 결정해야 하죠. 데이터 연동의 목표를 이 운영 질문으로 좁히면 필요한 인터페이스와 화면도 자연스럽게 정리돼요.

데이터가 생기는 지점부터 맞춰요

검사 모니터의 판정값은 PLC 레지스터나 센서 필드와 연결돼요. 예를 들어 D0100은 검사 결과 코드, D0101은 측정값, D0102는 검사 시각의 예시 주소로 기록할 수 있어요. 다만 이 주소명과 배율은 실제 PLC·센서 필드 주소 맵과 대조한 예시로만 사용해야 해요. 주소가 맞아도 정수와 실수, 스케일, 바이트 순서가 다르면 같은 검사 결과가 서로 다른 값으로 보일 수 있어요.

여기서 EASY-LINK는 검사 모니터와 PLC의 신호를 수집해 정해진 전달 대상으로 보내고, 그 뒤 단계는 맡지 않아요. RS-485나 네트워크로 확인한 값을 MQTT, HTTP API, MySQL, Firebase 가운데 목적에 맞는 경로로 넘기는 연결 계층이에요. 작은 라인에서 연결과 전송만 필요하면 EASY-LINK만으로 충분한지 먼저 확인해요.

검사 모니터의 신호를 PLC 주소 맵과 대조한 뒤 전달 경로를 고르는 모습이에요.

여러 설비의 수집 주기, 저장 이력, 전달 상태, 통합 관리가 필요하면 EASY LOGGER를 함께 검토해요. EASY LOGGER는 데이터 로거로서 수집 주기와 저장 이력을 관리하고, 전달 상태와 대시보드에서 운영 흐름을 확인하는 계층이에요. EASY-LINK와 EASY LOGGER를 함께 쓸 때도 연결 역할과 운영 역할을 섞지 않는 것이 핵심이에요.

목적지별 선택 기준을 세워요

HTTP API는 검사 결과를 한 번의 요청과 응답으로 상위 시스템에 전달할 때 읽기 쉬워요. 응답 코드와 처리 시각을 기준으로 연계 성공을 확인하기 좋지만, 호출 재시도와 중복 요청 규칙을 함께 정해야 해요. MQTT는 이벤트를 여러 화면이나 서비스가 구독할 때 잘 맞아요. 대신 Topic, 권한, 재연결 상태와 payload 기록을 운영 항목으로 남겨야 해요.

MySQL은 외부 시스템의 검사 이력 스키마에 맞춰 기간 조회와 원인 비교를 할 때 유용해요. Firebase는 모바일이나 웹 화면에서 빠르게 상태를 보여줄 목적에 어울리지만, 저장 구조와 권한을 별도로 확인해야 해요. 어느 경로를 택해도 프로토콜 비교의 기준은 속도 하나가 아니라 재처리, 이력 조회, 권한 분리, 담당자의 확인 화면까지 포함해야 해요.

MES와 CIM은 전용 커넥터를 전제로 하지 않고 MQTT, HTTP API 또는 DB 인터페이스로만 연결 범위를 정의해요. 상위 시스템으로 보낼 필드와 현장에 남길 필드를 나누면 검사 결과가 중복 저장되는 문제도 줄어들어요. 외부 스키마의 테이블명과 컬럼명은 해당 시스템 문서에서 확인한 뒤 정해야 하며, EASY LOGGER 내부 스키마라고 단정하지 않아요.

운영 검증 순서를 작게 잡아요

처음부터 전 라인을 열지 말고 한 대, 한 공정의 검사 모니터만 연결해요. 수집 화면에서 원시값을 확인하고, 변환된 payload의 단위와 시각을 비교한 뒤, 목적지의 수신 기록과 대시보드 표시를 차례로 맞춰요. 오류가 생기면 배선·주소·변환·전송·화면을 한 단계씩 되짚을 수 있어야 해요.

수집 주기, 저장 이력, 전달 상태를 한 화면의 운영 기준으로 확인하는 모습이에요.

산업 데이터 보안도 운영 설계에 넣어요. 읽기 계정과 쓰기 계정을 나누고, 브로커·API·DB의 허용 범위를 필요한 대상에만 열어요. 통신 장애 점검을 위해 마지막 수신 시각과 재연결 시각을 남기고, 데이터베이스 설계에서는 검사 ID와 측정 시각을 중복 없이 묶어요. 설정 변경 전후의 값을 저장하면 추후 데이터 추세 분석에도 도움이 돼요.

연결 대상과 필요한 화면을 더 좁히고 싶다면 EASY LOGGER MQTT 설정 흐름에서 Topic Preview와 전달 상태를 이어서 살펴볼 수 있어요. 제품 역할과 통신 범위는 EASY-LINK 제품 안내에서 확인하고, 장비별 설정 항목은 매뉴얼 자료실에서 대조해 보세요.

EASY LOGGER MQTT 예제

아래 INSPECT_PLC, D0100_RESULT, D0101_VALUE는 예시 이름이에요. 검사 모니터의 판정 코드와 측정값이 PLC 주소 맵에 각각 대응한다고 가정한 것이므로, 실제 필드 주소와 수집 설정을 대조한 뒤 사용해요. 먼저 Automatic Topic Preview에서 READ Topic과 WRITE Topic을 확인하고, Runtime Status에서 연결 상태를 본 다음 Payload Log에서 마지막 payload를 확인해요.

READ TOPIC: INSPECT_PLC/D0100_RESULT/READ
WRITE TOPIC: INSPECT_PLC/D0100_RESULT/WRITE

READ payload의 values는 검사 모니터 필드와 PLC 주소 맵을 맞춘 예시예요. 값의 의미는 외부 검사 시스템의 필드 정의와 대조하고, WRITE payload는 테스트용 주소와 허용값을 별도로 확인해요.

{
  "plc_name": "INSPECT_PLC",
  "config_name": "D0100_RESULT",
  "data_type": "word",
  "values": {"D0100": 1}
}

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

이 흐름은 Automatic Topic Preview, Runtime Status, Payload Log를 연결해서 보는 예제예요. 현장 연결 가능 여부를 확인하거나 상담을 요청할 때는 검사 모니터 모델, PLC 주소 맵, 필요한 목적지와 확인 화면을 함께 준비하면 다음 범위를 정하기 쉬워요.