센서에서 대시보드까지: Azure IoT Hub를 통한 MQTT 파이프라인

기계가 멈추면 계획 담당자에게는 대시보드의 빨간 선 하나보다 더 많은 정보가 필요합니다. 무엇이 멈췄는지, 왜 멈췄는지, 그 라인에 어떤 주문이 걸려 있는지, 그리고 생산 계획을 여전히 지킬 수 있는지를 알아야 합니다. 공장 현장의 원시 신호를 클라우드 분석으로 옮기려면 현장 센서, 산업용 게이트웨이, 메시지 브로커, 클라우드 수집 계층에 걸친 신뢰할 수 있는 아키텍처가 필요합니다.

엣지에서 신호 포착하기
센서 신호는 아직 제조 정보가 아닙니다. 컨베이어 모터의 온도가 정상 작동 한계를 넘어 올라가는 포장 라인을 떠올려 보십시오. 그 순간 프로그래머블 로직 컨트롤러(PLC)는 온도 측정값, 타임스탬프, 품질 상태와 같은 원시 태그 값을 보유하고 있습니다.

그러나 오래된 공장은 독점 프로토콜 또는 OPC UA를 사용하는 여러 세대의 장비를 함께 운영하는 경우가 많아, PLC가 클라우드 MQTT를 직접 사용하는 일은 드뭅니다. 운영기술(OT) 네트워크에 배치된 산업용 게이트웨이가 이 간극을 메우며 다음 역할을 수행합니다.

• 데이터 정규화: 서로 다른 형식, 척도, 엔지니어링 태그를 공통 메시지 형태로 변환합니다.
  
• 수집 주기 관리: 고빈도 스캔 데이터를 의미 있는 간격으로 집계하고, 상태 변화는 즉시 전달합니다.
  
• 로컬 버퍼링: 네트워크 장애 중에는 데이터를 안전하게 저장했다가 연결이 복구되면 안전하게 재전송합니다.
  

MQTT로 메시지 전달하기
게이트웨이가 메시지 형태를 갖추면, 제약이 있는 장치와 불안정한 링크에 적합한 경량 발행-구독 프로토콜인 MQTT(Message Queuing Telemetry Transport)를 사용해 메시지를 발행합니다.

• 발행-구독 디커플링: 발행자는 어떤 하위 시스템이나 애플리케이션이 메시지를 소비하는지 알 필요 없이 알려진 토픽으로 메시지를 보냅니다.
  
• 토픽 구조: 토픽은 메시지 범주를 위한 전송 주소 역할을 하지만, 전체 공장 자산 모델을 대신하도록 과도하게 사용해서는 안 됩니다.
  
• 페이로드 계약: 실제 메시지 본문에는 안정적인 원본 자산 식별자, 측정값, 단위, 타임스탬프, 품질 플래그가 명시적으로 포함되어야 합니다.
  

Azure IoT Hub의 역할
로컬 MQTT 브로커가 공장 내부 트래픽을 처리하는 동안, Azure IoT Hub는 기업 장치군을 위한 관리형 클라우드 연결 계층 역할을 합니다.

• 장치 ID 및 인증: 모든 게이트웨이는 Shared Access Signatures(SAS) 또는 X.509 인증서를 사용해 IoT Hub에 안전하게 등록된 장치 ID를 가져야 합니다.
  
• 전송 보안: 연결은 TLS(Transport Layer Security)에 의존하여 네트워크 경계와 방화벽을 넘는 전송 중 데이터를 보호합니다.
  
• 내장 엔드포인트: IoT Hub는 장치-클라우드 메시지를 수신하고, 신뢰할 수 있는 연결 메타데이터를 찍은 뒤, 다음 경로로 라우팅하기 전까지 일시적으로 보관합니다.
  

라우팅, 스트리밍, 장기 저장
수신된 텔레메트리는 조직 전반의 여러 소비자에게 사용되므로, 메시지 라우팅을 통해 트래픽을 서로 다른 경로로 나눌 필요가 있습니다.

1. 원시 이력 저장: Azure Blob 또는 Data Lake Storage로 메시지를 라우팅하면 엔지니어링 검토와 재처리를 위한 변경되지 않은 감사 추적이 보존됩니다.
   
2. 스트림 처리: Event Hubs와 같은 엔드포인트는 準실시간 스트리밍 소비자와 경보 규칙에 데이터를 공급하여 이상 상태를 유지보수팀에 알립니다.
   
3. 분석 모델: Microsoft Fabric과 같은 플랫폼에 데이터 스트림을 통합하면 텔레메트리를 기업의 계획 및 실행 맥락과 결합하는 데 도움이 됩니다.
   

이 팟캐스트의 후원자가 되어 주십시오: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.