[BlogPost] WPF 디지털 트윈 연재 17 ## Alarm·이상상태 감지와 Predictive Maintenance 구조

[BlogPost] WPF 디지털 트윈 연재 17

Alarm·이상상태 감지와 Predictive Maintenance 구조

부제: 고장이 난 뒤 Alarm을 보는 장비에서, 고장이 나기 전에 변화를 읽는 장비로

1. Alarm의 목적은 ‘고장을 알려주는 것’에서 끝나지 않는다

산업장비에서 Alarm은 오랫동안 “이미 문제가 발생한 뒤 작업자에게 알려주는 기능”으로 사용되어 왔습니다. Servo Alarm, Vacuum Timeout, Cylinder Sensor Error, Vision NG, Communication Error와 같이 문제가 발생하면 Alarm Code를 발생시키고 설비를 정지하는 방식입니다.

그러나 디지털 트윈을 도입하면 Alarm의 의미를 한 단계 확장할 수 있습니다. 장비가 정상적으로 동작하던 시점의 데이터를 기준선(Baseline)으로 축적한 뒤, 현재의 동작이 그 기준에서 얼마나 달라지고 있는지를 지속적으로 비교할 수 있기 때문입니다.

예를 들어 실린더가 정상 시 220 ms 안에 전진 완료되던 장비가 어느 순간부터 250 ms, 280 ms, 320 ms로 느려진다면 아직 Timeout Alarm은 발생하지 않았더라도 이미 마찰 증가, 공압 저하, Solenoid Valve 열화, 센서 위치 변화 등의 가능성을 의심할 수 있습니다.

즉 디지털 트윈에서 Alarm은 단순한 결과가 아니라 정상 → 변화 → 이상징후 → 경고 → 고장으로 이어지는 시간축의 한 지점으로 보아야 합니다.

2. Predictive Maintenance의 핵심은 ‘고장을 맞히는 AI’가 아니다

예지보전이라고 하면 흔히 딥러닝이나 복잡한 AI 모델을 먼저 떠올리지만, 실제 장비에서는 AI보다 앞서 해야 할 일이 있습니다. 바로 정상상태의 기준선을 정의하고, 변화량을 안정적으로 측정하며, 원인을 추적할 수 있는 데이터 구조를 만드는 것입니다.

초기 단계에서는 Moving Average, Standard Deviation, Rate of Change, EWMA, 단순 Threshold, Z-Score와 같은 통계적 방법만으로도 상당한 이상징후를 잡을 수 있습니다. 데이터를 충분히 축적한 뒤에는 Isolation Forest, One-Class SVM, Autoencoder, 시계열 예측모델, 다변량 이상감지 등으로 발전시키는 것이 안전합니다.

따라서 개발 순서는 “AI를 먼저 만든다”가 아니라 Logging → Baseline → Trend → Rule-based Detection → Validation → AI가 되어야 합니다.

3. 어떤 데이터를 이상감지 대상으로 삼아야 하는가

반도체 및 자동화 장비에서는 다음과 같은 신호가 예지보전에 특히 유용합니다.

① Motion: Command Position, Actual Position, Position Error, Velocity, Acceleration, Motor Torque, Current, Servo On/Off, Following Error, Settling Time.

② Cylinder: Command ON 시각, Sensor ON 시각, Extend/Return Response Time, Timeout 횟수, 반복주기별 편차.

③ Vacuum: Valve ON 이후 목표 압력 도달시간, 유지압력, 누설에 따른 Pressure Recovery, Vacuum Release Time.

④ Vision: Alignment Score, Edge Contrast, Focus Metric, Defect Score, NG Rate, 위치 보정량, 조명 출력 변화.

⑤ Machine: Cycle Time, Step별 소요시간, Retry Count, Alarm 발생빈도, Recipe별 처리시간, Idle/Run 비율.

중요한 것은 값을 한 번 보는 것이 아니라 같은 공정·같은 Recipe·같은 장비조건에서 반복값이 어떻게 변해왔는가를 보는 것입니다.

4. Baseline을 정의해야 ‘이상’이라는 말이 의미를 가진다

이상감지 시스템에서 가장 중요한 질문은 “무엇이 정상인가?”입니다. 단순히 사양서의 상한·하한만으로는 부족합니다. 장비별 편차, Recipe별 차이, 제품 종류, 온도, 생산속도에 따라 정상범위가 달라질 수 있기 때문입니다.

따라서 Baseline에는 최소한 Equipment ID, Recipe ID, Product Type, Operating Mode, Calibration Version, Software Version을 함께 저장하는 것이 좋습니다. 동일 장비라도 Calibration 이후에는 이전 Baseline과 분리해서 관리할 필요가 있습니다.

예를 들어 Vacuum Build-up Time의 정상범위가 A Recipe에서는 180~230 ms, B Recipe에서는 250~320 ms라면 하나의 고정 Threshold로는 잘못된 Alarm이 많아집니다. 디지털 트윈은 이런 조건정보를 같이 보관할 수 있기 때문에 Context-aware Baseline을 만들 수 있습니다.

5. Alarm을 3단계로 나누면 현장 적용성이 높아진다

Level 1 – Alarm: 즉시 조치가 필요한 상태입니다. Safety Interlock, Servo Fault, Hard Limit, Vacuum Fail 등이 해당합니다.

Level 2 – Warning: 장비는 계속 운전할 수 있지만 성능 열화가 관찰되는 단계입니다. Cylinder Response Time 증가, Motor Torque 증가, Vision Score 저하, Cycle Time 증가 등이 이에 해당합니다.

Level 3 – Prediction: 현재 운전에는 문제가 없지만 추세상 일정 기간 내 고장 가능성이 높다고 판단하는 단계입니다. 이 단계에서는 유지보수 우선순위와 예상 교체시점을 제시하는 것이 좋습니다.

이 구조를 사용하면 모든 이상을 Alarm으로 띄워 작업자를 피로하게 만드는 문제를 줄일 수 있습니다.

6. 단일 Threshold보다 ‘변화율’이 더 중요할 때가 많다

고장은 절대값보다 변화속도에서 먼저 나타나는 경우가 많습니다. Motor Torque가 아직 허용범위 안에 있어도 최근 2주 동안 15%, 25%, 40% 증가했다면 주목할 가치가 있습니다.

따라서 다음 지표를 함께 관리하는 것이 좋습니다.

• Current Value
• Moving Average
• Standard Deviation
• Rate of Change
• Baseline 대비 편차(%)
• 최근 N Cycle의 최대·최소값
• 이상 지속시간(Duration)

이 값들을 WPF Trend Chart와 함께 표시하면 엔지니어가 “왜 Warning이 발생했는지”를 바로 이해할 수 있습니다.

7. Multi-signal Correlation이 고장 원인을 더 빨리 보여준다

실제 고장은 하나의 신호만 변하지 않는 경우가 많습니다. 예를 들어 Wafer Transfer Robot의 Pick 동작에서 Cycle Time이 증가하고, 동시에 Motor Torque가 올라가며, Vacuum Build-up Time도 길어진다면 단순 Motion 문제인지 Vacuum 문제인지 구분해야 합니다.

이때 여러 신호를 같은 Timeline에서 겹쳐 보면 원인 추적이 쉬워집니다. 디지털 트윈의 강점은 Motion, I/O, Vision, Sensor, Alarm을 서로 다른 프로그램 화면이 아니라 하나의 시간축으로 볼 수 있다는 점입니다.

향후 AI를 적용할 때도 단일 센서가 아니라 이러한 다변량 데이터를 학습시키면 훨씬 안정적인 이상감지가 가능합니다.

8. WPF에서는 Condition Monitoring을 별도 서비스로 분리한다

권장 구조는 다음과 같습니다.

Device Adapter → Equipment Data Model → Logging → Condition Monitoring Engine → Alarm/Warning Service → WPF Dashboard

Condition Monitoring Engine은 UI와 분리해야 합니다. WPF 화면이 느려지거나 종료되더라도 데이터 분석은 계속 수행되어야 하기 때문입니다.

또한 실장비 제어 Thread와 Predictive Maintenance 분석 Thread를 분리해야 합니다. 예지보전 계산이 실제 Motion 또는 Sequence 제어에 지연을 유발해서는 안 됩니다.

9. Replay와 결합해야 이상감지의 신뢰도가 높아진다

Warning이 발생했을 때 “현재 값이 이상하다”는 메시지만 있으면 현장 엔지니어는 다시 로그를 찾아야 합니다. 대신 Event Marker를 누르면 발생 30초 전부터 10초 후까지 장비를 Replay하도록 만들 수 있습니다.

예를 들어 Cylinder Response Warning이 발생했다면 Replay에서 Cylinder Command, Sensor Feedback, Vacuum Pressure, Robot Position, Machine State를 동시에 보여줄 수 있습니다.

이 기능은 CS 대응에서 매우 강력합니다. 현장에 엔지니어를 보내기 전에 데이터를 통해 원인을 상당 부분 좁힐 수 있기 때문입니다.

10. 품질평가에서 반드시 측정해야 할 지표

Predictive Maintenance 기능은 “그래프가 그럴듯하다”는 이유만으로 출시하면 안 됩니다. 품질평가 단계에서는 다음을 정량화해야 합니다.

False Alarm Rate: 정상인데 Warning을 발생시킨 비율
Miss Rate: 실제 이상을 놓친 비율
Detection Lead Time: 실제 Alarm 이전 몇 분·몇 시간·몇 Cycle 전에 탐지했는지
Repeatability: 같은 조건에서 동일한 판단이 나오는지
Recipe Robustness: Recipe 변경 시 오탐이 증가하지 않는지
Long-term Drift: 24~72시간 이상 운전해도 Baseline이 비정상적으로 흔들리지 않는지

따라서 일정은 반드시 알고리즘 구현 → 내부 검증 → 품질평가 → Threshold/Baseline 수정 → 재평가 → Release로 잡아야 합니다. 품질평가에서 발견된 오탐을 수정할 시간을 별도로 확보해야 합니다.

11. 부서별 역할을 명확하게 나누면 개발 속도가 빨라진다

기구: 이상발생 가능 부품, 마찰·정렬·수명 요소 정의.
전장: Motor Current, Sensor, Pressure, Temperature 등 수집 가능한 신호 정의.
제어: Command/Feedback Timestamp, Sequence, Cycle Time, Retry 정보 제공.
광학: 조명 출력, Focus, 영상 Contrast 등 광학 열화 지표 정의.
알고리즘: Baseline, Trend, Anomaly Score, Correlation 분석.
품질: False Alarm, Miss Rate, Lead Time 및 장시간 평가.
CS: 실제 현장에서 반복 발생하는 Failure Mode 제공.

특히 CS의 현장 데이터는 예지보전 모델을 현실적으로 만드는 중요한 자산입니다.

12. AI 적용은 3단계로 발전시키는 것이 안전하다

1단계 – Rule-based: Threshold, Response Time, Moving Average, Rate of Change.

2단계 – Statistical Anomaly: Z-Score, EWMA, SPC, Multivariate Correlation.

3단계 – AI: Isolation Forest, Autoencoder, One-Class Classification, Time-series Forecasting, Remaining Useful Life 추정.

이렇게 단계적으로 올라가면 AI가 틀렸을 때도 원인을 설명할 수 있고, 고객사 품질팀을 설득하기도 쉽습니다.

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

Predictive Maintenance는 단순 연구개발 기능으로 끝낼 필요가 없습니다. 장비 옵션과 유지보수 서비스로 상품화할 수 있습니다.

예를 들어 기본 장비에는 Alarm/Trend만 제공하고, 상위 옵션에는 Advanced Monitoring, Replay, Health Score, Remote Diagnosis, Predictive Maintenance Report를 추가할 수 있습니다.

또한 월간·분기별 Equipment Health Report를 제공하면 단발성 장비 매출에서 유지보수·분석 서비스 매출로 확장할 수 있습니다. 이는 기술개발비가 다시 매출과 데이터로 회수되고, 그 데이터가 다시 알고리즘을 개선하는 선순환 구조가 됩니다.

장비 판매 → 운영 데이터 축적 → 이상감지 고도화 → 고객 다운타임 감소 → 차별화된 장비 판매 → 유지보수 서비스 매출

14. 결론 – 최고의 장비회사는 ‘고장이 적은 회사’를 넘어 ‘고장을 설명하고 예측하는 회사’가 된다

세계적인 장비회사가 되기 위해서는 기계 정밀도, 제어 성능, 광학 성능뿐 아니라 장비가 스스로 자신의 상태를 설명할 수 있어야 합니다.

디지털 트윈의 Alarm·Condition Monitoring·Predictive Maintenance는 단순한 부가 기능이 아니라 장비 기술을 데이터 자산으로 바꾸는 핵심 계층입니다.

처음부터 거대한 AI 시스템을 만들 필요는 없습니다. Cylinder Response Time, Vacuum Build-up Time, Motor Torque, Vision Score, Cycle Time처럼 현장에서 의미가 명확한 5~10개의 지표부터 시작해도 충분합니다.

중요한 것은 데이터를 계속 축적하고, 품질평가로 신뢰도를 검증하며, 고객 현장에서 얻은 Failure Mode를 다시 모델에 반영하는 것입니다. 이 과정이 반복되면 디지털 트윈은 단순 Viewer가 아니라 회사의 핵심 기술자산과 반복 매출 플랫폼으로 발전할 수 있습니다.

Tags

#DigitalTwin #WPF #PredictiveMaintenance #ConditionMonitoring #AnomalyDetection #AlarmManagement #EquipmentHealth #SmartFactory #IndustrialAI #MachineVision #MotionControl #PLC #반도체장비 #산업자동화 #예지보전 #이상감지 #설비진단 #RND