WPF 디지털 트윈 연재 16 ## 실시간 데이터 Logging과 Replay 시스템 설계

WPF 디지털 트윈 연재 16

실시간 데이터 Logging과 Replay 시스템 설계

핵심 메시지: 디지털 트윈의 로그는 단순히 데이터를 쌓는 기능이 아니라, 과거의 장비 상태를 다시 실행할 수 있게 만드는 기능이어야 합니다. 그래야 장애 원인분석, 고객 대응, 품질검증, 예지보전까지 하나의 기술자산으로 연결됩니다.

1. 왜 Logging과 Replay가 디지털 트윈의 핵심인가

산업장비의 장애는 대개 한 순간의 단일 원인으로 발생하지 않습니다. 축의 위치 편차, Vacuum 형성 지연, Sensor 응답 변화, Vision 결과 이상, Sequence 변화, Operator 조작 등이 시간적으로 연결되면서 문제가 만들어집니다. 따라서 Alarm 한 줄만 저장해서는 원인을 찾기 어렵습니다.

디지털 트윈의 Logging은 ‘무슨 값이었는가’를 기록하는 것을 넘어, 언제 어떤 상태가 어떤 순서로 변했는가를 보존해야 합니다. Replay는 그 기록을 이용해 장비의 과거 상태를 화면에서 다시 재현하는 기능입니다.

2. 무엇을 기록해야 하는가

권장 로그 대상은 다음과 같습니다.

① Motion: Command Position, Actual Position, Velocity, Acceleration, Torque, Servo State, Home/Limit

② Robot: Joint1~6, TCP Position/Orientation, Robot Mode, Alarm

③ Sensor/I/O: DI/DO, Cylinder Command/Feedback, Vacuum, Pressure, Flow, Temperature

④ Vision: Trigger, Frame ID, Image ID, OK/NG, Score, X/Y/Angle, Defect Code, Recipe

⑤ Machine State: Auto/Manual, Sequence Step, Recipe, Lot/Wafer/Tray ID, Interlock

⑥ Alarm/Event: Alarm Code, 발생시각, 복구시각, Ack, Operator Action

3. 모든 데이터의 기준은 Timestamp다

Replay 품질은 Timestamp 품질과 거의 같습니다. Motion은 10 ms 주기, PLC는 50 ms, Vision은 Trigger 기반, Robot은 Vendor SDK 주기처럼 서로 다른 주기로 들어옵니다. 따라서 각 데이터는 수집 시점의 고정밀 Timestamp를 반드시 가져야 합니다.

실무에서는 Timestamp뿐 아니라 Sequence Number, Source ID, Data Quality, Calibration Version도 함께 저장하면 좋습니다. 특히 Camera Calibration이나 Robot Tool Offset이 바뀌면 같은 좌표값의 의미가 달라질 수 있으므로 버전까지 남겨야 과거 상태를 정확히 재현할 수 있습니다.

4. EquipmentSnapshot 개념

로그를 값별로만 따로 저장하면 사건 전체를 이해하기 어렵습니다. 그래서 특정 시점의 핵심 장비 상태를 하나의 Snapshot으로 묶는 구조가 유용합니다.

EquipmentSnapshot에는 Timestamp, MachineState, AxisStates, RobotStates, SensorStates, VisionStates, ActiveAlarms, Recipe, Lot/Wafer/Tray ID 등을 포함할 수 있습니다.

Alarm 발생 전후로 Snapshot을 저장하면 ‘문제 발생 직전 10초 → Alarm 발생 → 복구 후 10초’를 하나의 사건으로 재생할 수 있습니다.

5. Event Marker를 반드시 남겨야 한다

연속 데이터만으로 Replay 화면을 만들면 사용자가 긴 Timeline을 일일이 탐색해야 합니다. 그래서 중요한 사건에는 Event Marker를 부여합니다.

예: Cycle Start, Wafer Pick, Wafer Place, Vision Trigger, Vision NG, Vacuum On, Vacuum Timeout, Servo Alarm, Door Open, Robot Error, Recipe Change, Operator Reset.

Timeline에 Marker를 표시하면 사용자는 장애 지점으로 즉시 이동할 수 있고, CS 담당자도 현장 로그를 빠르게 이해할 수 있습니다.

6. 저장소는 데이터 성격에 따라 나눈다

모든 데이터를 하나의 DB에 넣는 것은 비효율적일 수 있습니다. 구성정보와 Recipe는 JSON/DB, Event와 Alarm은 SQLite/SQL, 고주기 시계열 데이터는 Time-Series DB 또는 압축 Binary, Snapshot은 Serialized Data, 이미지는 파일 저장소 + DB Index 형태가 효율적입니다.

특히 Vision 이미지까지 DB Blob으로 무조건 넣기보다는, 이미지 파일은 별도 보관하고 DB에는 Image ID, 경로, Timestamp, Result, Recipe, Lot 정보를 Index로 저장하는 편이 관리와 백업에 유리합니다.

7. WPF Replay UI의 핵심 기능

최소 기능은 Play / Pause / Stop / Seek / Speed Control / Timeline / Event Marker / Snapshot Restore입니다.

Replay 모드에서는 실제 통신 대신 LogDataProvider가 Equipment Data Model에 값을 공급하도록 설계하면 좋습니다. 이렇게 하면 Live, Replay, Simulator가 동일한 WPF UI를 사용할 수 있습니다.

예를 들어 LiveDataProvider, ReplayDataProvider, SimulatorDataProvider가 동일한 인터페이스를 구현하면, 화면 코드는 데이터의 출처를 몰라도 됩니다.

8. 장애 분석은 Before / Event / After 구조로 본다

실제 장애 분석 시에는 ‘Alarm이 난 순간’만 보면 부족합니다. 권장 방식은 Before 5~30초 → Event → After 5~30초를 함께 재생하는 것입니다.

예를 들어 Vacuum Timeout이 발생했다면 Vacuum Command 시점, Sensor 변화, Cylinder 위치, Robot Pick Position, Wafer Presence Sensor, Cycle Time을 동시에 확인합니다. 이런 접근은 단순 Alarm 분석보다 훨씬 빠르게 Root Cause를 찾게 해 줍니다.

9. 연구소 조직별 역할

기구: Axis/Pivot/기구 이벤트 기준 정의

전장: Sensor, I/O, Cylinder, Vacuum 신호 정의

제어: Sequence Step, Motion State, Machine State, 통신 Timestamp

광학·알고리즘: Image ID, Vision Result, Calibration Version, 검사 Parameter

품질: 데이터 누락, Timestamp 정합, Replay 재현성, 장시간 Logging 평가

CS: 실제 장애 시나리오와 필요한 전후 데이터 Window 정의

10. 품질평가에서 반드시 확인할 항목

① 데이터 누락률 ② Timestamp 정합성 ③ 장비 상태와 Replay 상태의 일치도 ④ 24~72시간 장시간 기록 안정성 ⑤ 저장장치 용량 증가율 ⑥ CPU/Memory 부하 ⑦ 통신단절 시 로그 복구 ⑧ 이미지-검사결과 연결 정확성 ⑨ Alarm Marker 정확성 ⑩ Seek 이후 상태 복원 정확성을 확인해야 합니다.

개발 일정에는 반드시 구현 → 자체검증 → 품질평가 → 수정·보완 → 재평가 → Release의 시간을 별도로 반영해야 합니다.

11. Logging이 예지보전으로 발전하는 과정

충분한 이력이 축적되면 단순 장애 재현을 넘어 추세분석이 가능합니다. Cylinder 응답시간 증가, Vacuum 형성시간 증가, Motor Torque 변화, Vision Score Drift, Cycle Time 증가 같은 작은 변화가 고장 전조가 됩니다.

처음부터 AI로 시작하기보다, 정확한 Logging → Replay → Trend → Rule-based 이상감지 → Machine Learning 순으로 발전시키는 것이 안정적입니다.

12. 기술을 매출로 연결하는 방법

Logging/Replay는 내부 개발도구에 머물 필요가 없습니다. 고객에게는 ‘장애가 났을 때 원인을 빨리 찾는 기능’ 자체가 큰 가치입니다. 이를 장비 옵션 또는 서비스 상품으로 만들 수 있습니다.

예를 들어 Basic은 Alarm/Event Log, Standard는 Replay와 Trend, Advanced는 Remote Diagnosis와 Predictive Maintenance로 구성할 수 있습니다. 장비 판매 이후에도 분석 소프트웨어, 유지보수 계약, 원격진단 서비스로 반복 매출을 만들 수 있습니다.

즉, 디지털 트윈은 기술개발비를 소모하는 프로젝트가 아니라 장비 → 데이터 → 진단 → 서비스 → 재투자의 선순환을 만드는 기술자본이 될 수 있습니다.

13. 마무리

Logging이 ‘기록’이라면 Replay는 ‘과거 장비의 재구성’입니다. 이 기능이 갖춰지면 개발자는 장애를 추측하지 않고 데이터로 분석하고, 품질팀은 동일 조건을 재검증하며, CS는 고객 현장의 문제를 본사에서 재현할 수 있습니다.

그리고 그 축적된 이력은 향후 AI 진단과 Physical AI의 학습 데이터가 됩니다. 따라서 Logging과 Replay는 디지털 트윈 프로젝트의 부가기능이 아니라, 지능화로 가는 핵심 기반입니다.

Tags

#DigitalTwin #WPF #Logging #Replay #EquipmentSnapshot #Timeline #RootCauseAnalysis #PredictiveMaintenance #MachineVision #MotionControl #Robot #PLC #스마트팩토리 #반도체장비 #산업자동화 #예지보전 #RND