기계 데이터가 Microsoft Fabric에 도달하는 과정 - OPC UA에서 실시간 분석까지

머신 알람, 센서 값, 생산 카운터, 고장 이벤트를 클라우드로 전송하는 일은 그 어느 때보다 쉬워졌습니다. OPC UA는 머신 신호를 노출하고, 엣지 계층이 이를 수집하며, MQTT는 이를 로컬에 분배할 수 있고, Microsoft Fabric은 결과로 생성된 스트림을 수집하고 분석할 수 있습니다. 어려운 부분은 데이터가 도착한 이후에 시작됩니다. 원시 텔레메트리를 실제 의사결정을 뒷받침할 만큼 충분한 생산 맥락으로 어떻게 바꿀 것인가 하는 문제입니다.

이번 에피소드는 하나의 머신 신호가 공장 현장에서 Microsoft 산업 데이터 스택을 거쳐 이동하는 과정을 따라갑니다. OPC UA에서 시작해 엣지와 MQTT를 거치고, 보안을 유지한 채 Azure와 Microsoft Fabric으로 넘어간 다음, Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, 유지보수 데이터, 생산 맥락이 어떻게 맞물리는지 살펴봅니다. 목표는 단순히 또 하나의 텔레메트리 파이프라인을 보여주는 것이 아닙니다. 머신 데이터가 생산, 유지보수, 품질, 계획에 유용해지기 전에 무엇이 일어나야 하는지를 설명하는 것입니다.

설비 정지에서 생산상의 결과까지
설비 정지는 컨트롤러 수준에서는 단순해 보입니다. 상태가 가동에서 고장으로 바뀌고, 고장 코드가 나타나며, 부품 카운터가 멈추고, 같은 시점 주변의 다른 값들도 변할 수 있습니다. 이런 정보는 유용하지만, 생산 부서는 보통 다른 질문을 합니다. 어떤 작업지시가 영향을 받는가, 남은 수량은 얼마인가, 다른 설비가 대신 맡을 수 있는가, 이 지연이 납기를 위협하는가?

설비는 자신의 상태를 이해하지만, 그 상태가 비즈니스에 어떤 결과를 가져오는지는 자동으로 알지 못합니다. MES는 공정과 작업지시를 알고 있을 수 있습니다. ERP는 납기일과 수요를 알 수 있습니다. 유지보수 부서는 설비 이력을 이해할 것입니다. 품질 부서는 산출물을 여전히 사용할 수 있는지 판단할 것입니다. 그래서 빠른 텔레메트리 파이프라인은 아키텍처의 출발점일 뿐입니다.

OPC UA — 신호가 데이터 경로에 진입하는 지점
OPC UA는 모든 클라우드 애플리케이션이 독점적인 컨트롤러 프로토콜을 이해하지 않아도 설비의 정보에 접근할 수 있도록 표준화된 산업용 인터페이스를 제공합니다. 서버는 변수, 설비 상태, 알람, 이벤트, 메서드, 타임스탬프, 품질 정보, 그리고 경우에 따라 구조화된 설비 모델을 노출할 수 있습니다.

이런 구조는 중요합니다. 유용한 산업 이벤트는 단순한 숫자 값 이상을 담아야 하기 때문입니다. 소스 타임스탬프, 서버 타임스탬프, 품질 상태, 단위, 소스 식별자, 원래의 OPC UA 노드 정보는 나중에 누군가 어떤 숫자의 출처를 묻거나 생산 계산이 이상해 보일 때 중요한 역할을 할 수 있습니다.

이 에피소드는 또한 태그 이름이 데이터 모델이 아니라는 점을 강조합니다. "temperature"나 "machine state"라는 필드는 여전히 설비, 엔지니어링 단위, 허용 범위, 상태 정의, 그리고 신호가 관측된 생산 상황과 같은 맥락이 필요합니다.

OT 경계를 통제된 상태로 유지하기
설비 연결이 생산 네트워크를 기업 또는 클라우드 환경의 확장으로 만들어서는 안 됩니다. 산업 네트워크에는 승인된 엣지 시스템이 설비와 통신할 수 있도록 하되, 기업 애플리케이션이 컨트롤러에 직접 접근하지 못하도록 하는 통제된 경계가 필요합니다. 일반적으로 세그먼테이션과 산업용 DMZ가 포함됩니다.

권장되는 패턴은 일반적으로 아웃바운드 지향입니다. 엣지 계층은 승인된 OPC UA 엔드포인트에 연결한 다음, 통제된 목적지, 포트, 프로토콜, 아이덴티티를 통해 선별된 정보를 클라우드 서비스로 보냅니다. 분석 플랫폼은 생산 시스템을 탐색하거나 수정할 수 있는 광범위한 권한을 상속하지 않고 데이터만 받아야 합니다.

인증서, 방화벽 규칙, 신뢰 관계, 만료 처리, 소유권 역시 일회성 구성 작업이 아니라 운영 프로세스로 다뤄야 합니다.

엣지는 데이터를 개선해야 하며, 비즈니스 의미를 만들어내서는 안 됩니다
엣지 계층은 머신 환경과 더 넓은 데이터 플랫폼 사이에 위치합니다. 첫 번째 책임은 연결이지만, 공장 밖으로 나가기 전에 정보를 필터링하고, 정규화하고, 버퍼링하고, 보강하고, 라우팅할 수도 있습니다.

유용한 엣지의 책임은 다음과 같습니다:
• 정의된 사용 사례에 필요한 신호만 선택
• 불필요한 고빈도 데이터 필터링
• 합의된 단위 변환 적용
• 소스 타임스탬프와 품질 지표 보존
• 안정적인 사이트, 라인, 설비 식별자 추가
• 클라우드 중단 시 버퍼링
• 재시도 및 백프레셔 동작 처리
• 커넥터와 큐의 상태 노출
• 지연 시간이나 연결이 끊긴 상태에서의 운영이 필요한 경우 선택적인 로컬 계산 또는 AI 추론 수행

중요한 경계는 엣지가 확신할 수 있는 사실만 추가해야 한다는 점입니다. 오래된 정보를 근거로 현재 활성화된 생산 오더를 추측하거나, MES, ERP, 계획, 품질 시스템에 속한 비즈니스 맥락을 몰래 만들어서는 안 됩니다.

AZURE IOT EDGE 대 AZURE IOT OPERATIONS
이 에피소드는 산업용 엣지 워크로드를 실행하기 위한 두 가지 Microsoft 접근 방식을 비교합니다.
Azure IoT Edge는 요구 사항이 게이트웨이나 개별 디바이스 중심일 때 잘 맞습니다. 컨테이너화된 모듈이 데이터를 수집하고, 로컬 로직을 적용하며, 정보를 버퍼링한 다음 Azure IoT Hub를 통해 상위로 전송할 수 있습니다. 조직이 더 가벼운 운영 체계를 원하고 정의된 셀이나 소규모 워크로드를 다룬다면 실용적인 선택이 될 수 있습니다.

Azure IoT Operations는 사이트 수준의 산업 데이터 환경에 더 가깝게 위치합니다. Azure Arc가 활성화된 Kubernetes 환경에서 실행되며, OPC UA 연결, MQTT, 데이터 흐름, 자산 및 디바이스 관리와 관련된 기능을 포함합니다. 사이트에 여러 라인, 여러 설비 벤더, 로컬 소비자가 있고 여러 공장에 걸쳐 관리된 엣지 패턴을 반복 적용해야 할 때 더 적합할 수 있습니다.

결정은 어떤 플랫폼의 기능 목록이 가장 긴지가 아니라, 조직이 지원할 준비가 된 운영 모델을 기준으로 해야 합니다. Azure IoT Operations는 더 넓은 사이트 수준 기능을 제공하지만, Kubernetes, Arc, 클러스터 운영, 모니터링, 스토리지, 패치, 복구 책임도 함께 가져옵니다.

공장 이벤트 백본으로서의 MQTT
여러 소비자가 같은 설비 이벤트를 필요로 할 때 MQTT는 아키텍처를 극적으로 단순화할 수 있습니다. 머신 커넥터가 브로커에 한 번 발행하면, 유지보수 애플리케이션, 로컬 히스토리안, 클라우드 데이터 흐름, 기타 승인된 소비자가 각자 독립적으로 구독할 수 있습니다.

이렇게 하면 많은 점대점 의존성이 사라집니다. 새로운 애플리케이션은 PLC나 OPC UA 서버로 다시 직접 연결을 만들지 않고도 승인된 토픽을 구독할 수 있습니다.

그래도 토픽 설계는 중요합니다. 계층 구조로 사이트, 영역, 라인, 셀, 설비를 표현할 수는 있지만, 토픽이 데이터 모델 전체가 되어서는 안 됩니다. 이벤트 식별자, 소스 타임스탬프, 설비 ID, 품질, 계약 버전, 이벤트 유형과 같은 중요한 사실은 메시지 페이로드에 남아 있어야 이벤트가 저장, 재생, 다른 곳으로 라우팅되더라도 이해 가능한 상태를 유지할 수 있습니다.

Unified Namespace는 토픽 트리가 아니라 계약입니다
Unified Namespace 패턴은 산업 시스템 전반에 걸친 공유 운영 계약을 제공할 수 있습니다. 유용한 부분은 단지 하나의 거대한 MQTT 계층 구조를 갖는 것이 아닙니다. 가치는 설비가 어떻게 식별되는지, 이벤트가 어떤 형태를 갖는지, 누가 데이터를 소유하는지, 스키마가 어떻게 변경되는지, 어떤 시스템이 서로 다른 사실에 대해 권위를 갖는지에 대해 합의하는 데서 나옵니다.

좋은 Unified Namespace는 소스 시스템이 자신의 기록에 대한 소유권을 유지하도록 하면서, 설비를 안정적으로 식별하고 관리된 운영 이벤트를 발행하는 방법을 제공할 수 있습니다.

그 계약은 다음과 같은 사항을 정의해야 합니다:
• 설비 식별
• 이벤트 유형
• 메시지 형태
• 타임스탬프 규칙
• 품질 정보
• 소유권
• 보안
• 버전 관리
• 변경 관리

MQTT는 계약을 전달할 수 있지만, MQTT가 계약을 만들어내지는 않습니다.

OPC UA 알림에서 MQTT 이벤트로
OPC UA 알림을 MQTT 이벤트로 바꾸는 일은 단순한 프로토콜 변환 이상입니다. 커넥터는