설비 예지보전 모델에 최근 1분간 진동값을 넣었다고 생각해 봅시다. 화면에는 초록색 정상 신호가 계속 들어오고 모델도 “이상 없음”이라고 답합니다. 그런데 실제로는 게이트웨이와 서버 사이 통신이 끊겨 10분 전 값이 반복 표시되고 있었다면 어떨까요? 숫자 자체는 실제 측정값이지만, 지금 설비를 설명하지 않습니다.
제조 현장의 데이터 품질은 빈칸이나 이상치만의 문제가 아닙니다. 그 값이 언제 측정됐고, 그때 센서와 통신 상태가 어땠으며, 중간에 무엇이 누락됐는지를 함께 알아야 합니다. 실시간 대시보드, 이상 탐지, 에너지 최적화처럼 빠른 판단이 필요한 시스템일수록 이 차이가 큽니다.
이 글은 설비에서 AI까지 이어지는 데이터 길을 하나의 측정값을 따라가며 살펴봅니다. OPC UA의 DataValue, MQTT 기반 Sparkplug의 세션 상태, 그리고 저장·분석 단계의 운영 규칙을 연결해 설명하겠습니다.
숫자 하나가 실제로는 여러 질문에 답해야 한다
예를 들어 모터 온도 72.4°C라는 값이 있다고 해봅시다. 이 숫자만으로는 알람을 울릴지 판단하기 어렵습니다. 이 값이 2초 전에 측정됐는지, 20분 전에 측정됐는지에 따라 의미가 달라지기 때문입니다. 센서가 점검 중이었거나 통신 장애 직전의 마지막 정상값일 수도 있습니다. 여기서 72.4°C는 이해를 돕기 위한 가상의 예시입니다.
운영 데이터에는 적어도 설비·태그의 정체, 측정값과 단위, 원천 측정 시각, 수집 시각, 품질 상태가 함께 있어야 합니다. 필요에 따라 게이트웨이·장치 식별자, 수집 경로, 메시지 식별자나 순서 정보도 보존합니다. 그래야 대시보드가 최신값을 보여주고 있는지, AI가 학습할 수 있는 값인지, 사고 후 기록을 재구성할 수 있는지를 구분할 수 있습니다.
OPC UA 표준의 DataValue 정의는 이 문제를 잘 보여줍니다. 값과 함께 statusCode, sourceTimestamp, serverTimestamp를 다룹니다. 표준상 원천 시각은 데이터 소스가 값에 부여한 시각이며, 서버 시각은 서버가 값을 받거나 그 값이 유효함을 알게 된 시각입니다. 원천 시각은 UTC로 다루고, 값이 전달되더라도 임의로 바꾸지 않아야 합니다.
세 개의 시각을 분리하면 늦은 값을 알아볼 수 있다
실무에서는 시각을 세 군데에서 볼 수 있습니다. 원천 시각은 장치 또는 원천 시스템이 값에 붙인 시각입니다. 서버 시각은 OPC UA 서버가 그 값을 받거나 확인한 시각입니다. 도착 시각은 우리 수집 서비스가 메시지를 저장한 시각입니다. 앞의 둘은 OPC UA DataValue의 필드이고, 마지막은 수집 파이프라인이 별도로 기록하는 운영 필드입니다.
가령 원천 시각이 10:00:00, 서버 시각이 10:00:02, 저장 시각이 10:07:30이라면 설비 값이 늦게 들어왔음을 알 수 있습니다. 반대로 저장 시각만 남기면 10:07:30에 측정된 새 값으로 오인할 수 있습니다. 이벤트를 재생하거나 지연 데이터를 뒤늦게 적재하는 경우에는 이 차이가 모델 학습 데이터의 순서를 바꿉니다.
원천 장치가 시각을 제공하지 않는다면 없는 값을 지어내지 않는 편이 좋습니다. sourceTimestamp가 없다는 사실을 보존하고, 서버 시각과 도착 시각 중 어떤 것을 분석 기준으로 썼는지 명시합니다. 여러 장치의 시계가 어긋나 있다면 동일한 사건이 서로 다른 순서로 보일 수 있으므로, 시계 동기화와 시계 오차 감시도 데이터 파이프라인의 일부입니다.
Good, Uncertain, Bad를 한꺼번에 ‘숫자’로 바꾸지 않는다
OPC UA의 StatusCode는 그 값이 얼마나 사용할 만한지를 알려줍니다. 표준은 Good을 좋은 품질, Uncertain을 주의가 필요한 품질, Bad를 사용할 수 없는 품질로 설명하며, 클라이언트가 최소한 심각도는 확인하도록 요구합니다. 하위 코드에는 마지막으로 쓸 수 있었던 값, 장치 연결 문제, 센서 문제 같은 구체적인 사유가 담길 수 있습니다. 자세한 해석은 OPC UA 서비스 표준과 데이터 접근 상태 코드에서 확인할 수 있습니다.
그래서 수집 단계에서 Bad 값을 0으로 바꾸거나, Uncertain 값을 Good과 섞어 평균 내는 처리는 위험합니다. 0이라는 값이 실제 측정치인지 통신 실패의 대체값인지 나중에는 구별할 수 없기 때문입니다. 원본 값과 원본 상태 코드를 함께 보관하고, 화면 표시·알람·모델 학습마다 다른 사용 정책을 적용하는 편이 안전합니다.
- 실시간 제어·안전 알람: 품질이 나쁘거나 지나치게 오래된 값은 자동 판단에 쓰지 않고 현장 안전 로직으로 넘깁니다.
- 운영 대시보드: 마지막 값을 보여주더라도 “마지막 수신 시각”과 데이터 품질을 함께 표시합니다.
- 모델 학습: Bad 값은 기본적으로 제외하고, Uncertain 값은 사유별로 분리해 분석합니다. 제외 기록도 남깁니다.
- 사후 분석: 결측을 임의 보간했다면 원본과 보간본을 구분해 저장합니다.
OPC UA 구독의 ‘최신값’은 모든 변화를 뜻하지 않는다
서버가 값을 구독자에게 보낼 때는 샘플링 주기, 발행 주기, 필터, 큐 크기가 함께 작동합니다. 값이 빠르게 변해도 수집 쪽이 느리면 중간 변화가 사라질 수 있습니다. OPC UA MonitoredItem 규정에 따르면 큐가 꽉 차면 설정에 따라 오래된 알림 또는 마지막으로 쌓인 값을 버릴 수 있고, 큐 크기가 1이면 최신값만 유지합니다. 큐가 1보다 클 때 DataValue가 버려지면 상태 코드의 overflow 비트가 손실을 알릴 수 있습니다.
따라서 “1초마다 읽는다”는 설정만으로 1초 사이 모든 변화가 보장되지는 않습니다. 진동 파형처럼 빠른 신호와 설비 상태 변경 이벤트는 필요한 시간 해상도가 다릅니다. 수집 설계에서는 원천 갱신 주기, 서버 샘플링 주기, 발행 주기, 필터와 큐 설정을 목적별로 정해야 합니다. 장비가 낼 수 없는 속도를 수집기에 요청하는 것도 의미가 없습니다.
MQTT로 보낼 때는 값과 함께 장치의 생존 상태를 전한다
공장에는 서로 다른 설비와 프로토콜이 섞여 있습니다. 엣지 게이트웨이가 OPC UA에서 읽은 값을 여러 시스템으로 배포할 때 MQTT를 많이 검토하는 이유입니다. 다만 MQTT로 숫자를 발행하는 것만으로 구독자는 “설비가 현재 살아 있는지”와 “처음부터 모든 태그를 받았는지”를 알기 어렵습니다.
Eclipse Sparkplug 명세는 MQTT 기반 산업 데이터에 토픽 체계, 페이로드, 세션 상태 관리 규칙을 더합니다. 장치나 엣지 노드가 연결되며 상태를 알리고, 끊어졌을 때도 오프라인 상태를 전하는 방식입니다. 메시지 순서 번호는 누락 의심을 발견하는 단서가 됩니다. 순서 번호가 있다고 해서 사라진 원본 값이 자동 복원되는 것은 아닙니다. 누락을 발견한 뒤 어디에서 다시 읽을지, 얼마나 보관할지는 별도로 설계해야 합니다.
이 구분은 화면에서도 중요합니다. “마지막 값 72.4°C”만 보이면 운영자는 지금 센서가 72.4°C라고 받아들입니다. 같은 화면에 “게이트웨이 오프라인, 마지막 측정 10분 전”이 보이면 판단이 달라집니다. 상태 데이터는 부가 정보가 아니라 값의 의미를 결정하는 정보입니다.
저장소와 AI 앞에 품질 판단 지점을 둔다
한 번 수집된 값은 목적에 따라 서로 다른 길로 보낼 수 있습니다. 예를 들어 원천 시각이 유효하고 품질이 Good이며 허용 지연 안에 들어온 값은 실시간 모니터링과 추론에 사용합니다. 늦게 도착한 Good 값은 실시간 알람에는 쓰지 않더라도 시계열 기록에 원래 시각으로 보충할 수 있습니다. Bad 값은 원본을 남긴 채 자동 판단에서 제외하고, Uncertain 값은 사유를 검토합니다. 순서가 어긋나거나 연결이 끊긴 구간은 누락 조사 대상으로 표시합니다. 이 분기 기준은 설비 위험도와 업무 요구에 맞춰 정해야 하며, 아래 그림의 색은 고정된 표준 등급이 아닙니다.
이때 “신선함”의 기준은 태그마다 다릅니다. 온도가 천천히 변하는 장비와 밀리초 단위로 변하는 진동 신호에 같은 허용 지연을 적용하면 한쪽은 과도하게 버리고 다른 한쪽은 위험하게 받아들일 수 있습니다. 실시간 추론에는 최대 허용 나이, 학습 데이터에는 허용 품질 상태와 보간 규칙, 대시보드에는 마지막 측정 시각 표시 정책을 따로 둡니다.
현장에서 바로 시작할 수 있는 작은 검증
처음부터 공장 전체를 바꿀 필요는 없습니다. 영향이 큰 설비 한 대와 핵심 태그 몇 개를 골라 데이터의 여행 기록을 붙여보면 됩니다. 예를 들어 모터 온도, 전류, 운전 상태를 골랐다면 다음 순서로 점검합니다.
- 원천과 단위를 적는다. 각 태그의 센서, PLC, OPC UA 노드, 단위, 정상 갱신 주기를 한 줄로 정리합니다.
- 시각을 세 개 보존한다. 원천 시각, 서버 시각, 수집 시각을 분리해 저장하고, 누락된 시각은 누락 그대로 표시합니다.
- 상태 코드를 그대로 남긴다. Good·Uncertain·Bad와 가능한 하위 코드를 원본 기록에서 지우지 않습니다.
- 연결이 끊기는 시험을 한다. 게이트웨이 통신을 의도적으로 중단하고, 화면에 마지막 값이 어떻게 보이는지, 재연결 후 기록이 어떻게 들어오는지 확인합니다.
- 순서와 누락을 본다. 구독 큐의 overflow 징후, 브로커 메시지의 세션 변화, 재전송이나 재적재 결과를 함께 기록합니다.
- AI 입력 계약을 만든다. 모델이 사용할 수 있는 데이터 나이와 품질 상태를 정의하고, 기준을 벗어나면 추론 대신 보류·검토·안전 모드 중 무엇을 할지 정합니다.
시험 결과는 “데이터를 얼마나 많이 받았는가”만으로 평가하지 않는 편이 좋습니다. 전체 측정 중 원천 시각이 있는 비율, 지연 분포, Bad·Uncertain 비율, 연결 끊김의 탐지 시간, 늦은 데이터의 사후 보충 성공률 같은 지표가 실제 운영 품질을 더 잘 보여줍니다. 숫자 목표는 설비 특성과 작업 위험도를 확인한 뒤 정해야 합니다.
AI의 첫 입력값은 숫자와 그 숫자의 맥락이다
제조 AI에서는 모델을 교체하기 전에 데이터가 현장을 제대로 대표하는지 물어야 합니다. 같은 72.4°C도 지금의 정상값, 10분 전의 정상값, 연결이 끊기기 직전 값, 센서가 불확실하다고 표시한 값은 서로 다른 입력입니다. 숫자만 남기는 순간 이 차이는 지워집니다.
OPC UA의 시각·상태 코드를 보존하고, Sparkplug 같은 세션 상태 규칙을 활용하며, 저장과 추론 단계에서 사용 기준을 분리하면 현장 데이터는 훨씬 설명 가능해집니다. 설비 담당자에게는 무엇이 실제로 일어났는지, 개발자에게는 어느 단계에서 늦거나 빠졌는지, 모델 담당자에게는 어떤 데이터를 믿고 학습했는지 답할 수 있게 됩니다.
실무의 출발점은 간단합니다. 센서값 옆에 “언제, 어떤 상태로, 어떤 경로를 거쳐 왔는가”를 함께 저장하세요.
참고 자료
- OPC Foundation, OPC UA Part 4: DataValue
- OPC Foundation, OPC UA Part 4: MonitoredItem queue parameters
- OPC Foundation, OPC UA Part 8: Data Access status codes
- Eclipse Foundation, Sparkplug Specification
#산업AI #제조AI #스마트팩토리 #설비데이터 #센서데이터 #데이터품질 #OPCUA #Sparkplug #MQTT #엣지컴퓨팅 #예지보전 #시계열데이터
