센서 데이터가 Digital Twin에 연결되는 과정

센서 값을 Digital Twin 화면에 표시하는 일은 숫자를 네트워크로 보내는 것보다 복잡하다. 어느 장비에서 나온 값인지, 언제 측정했는지, 단위와 품질이 무엇인지가 보존되어야 현실 자산의 상태로 해석할 수 있다. 일반적인 흐름은 센서와 제어기, Edge Gateway, 수집 서비스, 정규화·검증, Twin 매핑, 이력·이벤트 처리, 애플리케이션 순으로 이어진다.

1. 측정과 장치 식별

센서는 온도, 진동, 전류, 위치와 같은 물리량을 측정하고 제어기나 장치 펌웨어가 이를 디지털 값으로 만든다. 이 단계에서 장치 일련번호만 보내기보다 논리적인 자산 ID, 채널, 측정 단위, 장치 측정 시각과 상태 코드를 함께 정의한다. 센서를 교체해도 자산의 이력이 이어져야 하므로 장치 ID와 설비 ID를 같은 것으로 간주하지 않는 편이 좋다.

2. Edge Gateway와 프로토콜 변환

현장에는 직렬 통신, 산업용 네트워크, 제조사 API 등 서로 다른 인터페이스가 섞여 있다. Gateway는 이를 MQTT, OPC UA 또는 HTTP처럼 상위 시스템이 처리할 수 있는 형태로 변환한다. 동시에 노이즈 필터, 단위 변환, 로컬 버퍼링과 연결 상태 감시를 수행할 수 있다. 네트워크 단절 중 데이터를 저장했다가 재전송한다면 원래 측정 시각을 유지해야 한다.

3. 메시지 수집과 전달

MQTT는 발행자와 구독자를 분리하는 경량 발행·구독 프로토콜이며 전달 품질 수준을 선택할 수 있다. 그러나 높은 QoS가 곧 데이터 정확성을 보장하는 것은 아니다. 재전송으로 중복이 생길 수 있으므로 메시지 ID, 장치 ID와 측정 시각을 기준으로 멱등 처리해야 한다. 명령과 텔레메트리는 권한과 Topic 구조도 분리한다.

4. 정규화와 데이터 품질 검사

수집 서비스는 제조사별 Payload를 공통 스키마로 변환한다. 단위, 허용 범위, 결측, 비정상 급변과 시간 역행을 검사하고 원본값과 가공값을 구분한다. 서버에 도착한 시각만 기록하면 버퍼에서 늦게 전달된 값을 최신값으로 오인할 수 있으므로 다음 시간 정보를 나누어 관리하는 것이 유용하다.

5. 자산과 Twin 속성에 매핑

검증된 메시지를 자산 레지스트리에서 찾고 대응하는 Twin 속성을 갱신한다. 예를 들어 site/A/ahu/07/supply_temp를 건물 A의 AHU-07 Twin에 있는 급기 온도 속성과 연결한다. 매핑 규칙은 코드에 흩어 놓기보다 버전 관리 가능한 설정이나 모델로 유지해야 장비 추가와 이름 변경에 대응할 수 있다.

Azure Digital Twins의 공식 구조에서는 IoT Hub 같은 상위 서비스가 텔레메트리를 전달하고 Azure Function이 이를 처리해 Twin을 갱신하는 패턴을 사용할 수 있다. 서비스 자체가 모든 장치 연결을 내장한다고 가정하지 않고 수집과 Twin 갱신의 책임을 분리하는 방식이다.

6. 현재 상태, 이력과 이벤트를 분리한다

Twin에는 운영자가 빠르게 확인할 현재 상태를 기록하고, 고빈도 원본은 시계열 저장소나 기존 Historian에 보존할 수 있다. 상태 변경 이벤트는 경보, 분석과 외부 워크플로로 전달한다. Azure Digital Twins의 외부 이벤트 전달은 최소 한 번 전달 방식이므로 소비자는 같은 이벤트를 다시 받아도 결과가 중복되지 않게 설계해야 한다. AWS IoT TwinMaker도 외부 시계열 저장소의 값을 데이터 커넥터로 조회하는 구조를 제공한다.

운영 체크리스트

• 장치 인증서와 키를 장비별로 관리하고 최소 권한을 적용한다.
• 센서 단위와 좌표계, 결측값 표현을 데이터 계약에 명시한다.
• 마지막 수신 시각과 품질 상태를 사용자 화면에 표시한다.
• 중복, 순서 역전, 연결 단절과 장치 재부팅을 시험한다.
• 명령 경로에는 승인, 허용 범위, 타임아웃과 감사 로그를 둔다.

FAQ