WPF 디지털 트윈 연재 04 - 전체 시스템 아키텍처

[4편] WPF 디지털 트윈 전체 시스템 아키텍처

3D Viewer를 넘어, 재사용 가능한 산업장비 플랫폼으로

디지털 트윈 프로젝트를 시작하면 가장 먼저 눈에 보이는 3D 화면부터 만들고 싶어집니다. CAD 모델을 불러오고, 축을 움직이고, 카메라를 회전시키면 빠르게 성과가 보이기 때문입니다. 그러나 산업장비용 디지털 트윈의 성패는 3D 표현이 아니라 소프트웨어 아키텍처에서 갈립니다.

PLC, Motion Controller, Robot, Camera, Sensor, Vision, Alarm, Recipe, Logging, Replay, AI까지 모두 하나의 프로그램 안에 직접 엮기 시작하면 초기에는 빨리 만들어져도 시간이 지날수록 유지보수와 확장이 어려워집니다. 따라서 처음부터 각 기능의 책임을 나누고, 모든 기능이 공통 Equipment Model을 기준으로 연결되도록 설계해야 합니다.

■ 1. 전체 아키텍처의 출발점: Control과 Visualization의 분리

실제 장비 제어와 WPF 화면은 분리되어야 합니다. Rendering이 느려지거나 UI Thread에 예외가 발생하더라도 Servo Control이나 Sequence에는 영향을 주지 않아야 합니다.

권장 흐름은 Physical Equipment → Communication → Equipment Model → Digital Twin Core → WPF Application입니다. Logging, Replay, AI는 Equipment Model과 Twin Core를 중심으로 독립적으로 연결합니다.

■ 2. Visual Studio Solution은 처음부터 모듈로 나눈다

하나의 WPF 프로젝트 안에 모든 기능을 넣기보다 Domain, Contracts, EquipmentModel, Communication, DeviceAdapters, TwinCore, Coordinate, ThreeD, Logging, Replay, Persistence, AI, WPF, Simulator, UnitTests 등으로 역할을 분리하는 것이 좋습니다.

처음에는 프로젝트 수가 많아 보여도 장비 종류가 늘고 기능이 확장되면 구조가 훨씬 안정적입니다.

■ 3. 시스템의 중심은 Equipment Model이다

Axis, Robot, Sensor, Cylinder, Camera, VisionResult, Alarm, MachineState를 공통 객체로 정의합니다. 예를 들어 Axis에는 Position, CommandPosition, Velocity, Torque, ServoOn, Home, Limit, Alarm, Timestamp가 포함될 수 있습니다.

이 공통 모델을 사용하면 3D 화면, Alarm, Trend, Logging, Replay, AI가 모두 같은 장비 상태를 바라보게 됩니다.

■ 4. Vendor SDK는 Adapter 뒤에 숨긴다

PLC나 Motion Controller 제조사가 바뀔 때 상위 소프트웨어 전체가 흔들리면 플랫폼이라고 할 수 없습니다. Mitsubishi, Panasonic, Beckhoff, Robot, Camera SDK 등 서로 다른 API는 Device Adapter를 통해 Standard Equipment Data로 변환해야 합니다.

Vendor Data → Adapter → Equipment Model 구조를 만들면 Hardware가 바뀌어도 Twin Core와 WPF UI는 그대로 유지할 수 있습니다.

■ 5. 좌표계와 Transform은 별도 모듈로 관리한다

산업장비에는 Machine, Stage, Robot, Camera, Work, Wafer, Tray 좌표계가 동시에 존재합니다. 좌표 변환을 여러 화면과 알고리즘에 흩어놓으면 Calibration과 유지보수가 어려워집니다.

따라서 Coordinate 모듈에서 Machine→Robot, Robot→Camera, Camera→Wafer, Stage→Machine 변환을 통합 관리하고, 향후 Hand-Eye Calibration과 Vision 보정값도 이 계층에 연결하는 것이 좋습니다.

■ 6. 3D Engine에는 ‘표현’만 맡긴다

3D Engine의 책임은 Model Loading, Scene Management, Camera Control, Object Selection, Transform Apply, Visibility, Material, Animation 정도로 제한합니다.

PLC 통신, Servo 제어, Recipe, Alarm 판단, Database 저장, AI 분석을 3D Engine 안에 넣으면 안 됩니다. 3D Engine은 Twin Core가 제공하는 상태를 화면에 그려주는 Renderer에 가까워야 합니다.

■ 7. Equipment Snapshot이 Replay의 기반이 된다

특정 시점의 MachineState, AxisStates, RobotStates, SensorStates, VisionStates, ActiveAlarms를 하나의 EquipmentSnapshot으로 저장하면 과거 상태를 그대로 복원할 수 있습니다.

Alarm 발생 10초 전으로 이동해 당시 Robot 위치와 Sensor 상태를 동일한 시간축에서 재현할 수 있다면 장애 분석은 텍스트 로그 중심에서 ‘상황 재현 중심’으로 바뀝니다.

■ 8. Logging은 Event와 Time-Series로 구분한다

Alarm, Recipe 변경, Lot Start/End, Vision NG, Operator Action은 Event Log로 저장하고 Position, Velocity, Torque, Temperature, Pressure, Cycle Time은 Sampling 기반 Time-Series로 저장하는 것이 좋습니다.

모든 데이터를 같은 빈도로 저장하면 용량만 커지고 분석 효율은 떨어질 수 있습니다. 데이터 성격에 맞는 저장 전략이 필요합니다.

■ 9. Live·Replay·Simulator는 같은 UI를 사용한다

실장비가 연결되면 Live Provider, 과거 데이터를 재생할 때는 Replay Provider, 장비 제작 전에는 Simulator가 동일한 Equipment Model에 데이터를 공급하도록 설계합니다.

이 구조를 사용하면 기계 조립 전에도 WPF UI, Sequence Visualization, Alarm, Trend를 먼저 검증할 수 있어 전체 개발 Lead Time을 줄일 수 있습니다.

■ 10. AI는 Core가 아니라 선택 가능한 상위 모듈이어야 한다

AI Module은 Equipment Model과 Historical Data를 입력으로 받아 Cycle Time 이상 감지, Servo Torque 이상, Sensor 응답 지연, 교체 시점 예측, Alarm 원인 후보 추천 등을 수행할 수 있습니다.

그러나 AI가 없어도 Digital Twin은 정상 동작해야 합니다. 그래야 AI 기술이 바뀌더라도 장비 플랫폼 자체는 안정적으로 유지됩니다.

■ 11. 품질평가와 수정·보완 기간을 아키텍처 단계부터 포함한다

평가 항목은 Position 동기화, Network Latency, Frame Rate, CPU/GPU 사용률, Memory Leak, 통신 단절 복구, CAD Loading Time, Logging 누락률, Replay 재현 정확도, Alarm Timestamp 일치 등을 포함해야 합니다.

일정은 설계 → 구현 → 자체검증 → 품질평가 → 수정·보완 → 재평가 → Release로 잡고, 품질평가 이후 수정 기간을 별도로 확보하는 것이 좋습니다.

■ 12. 장비별 프로그램이 아니라 ‘플랫폼’을 만든다

처음에는 WTR이나 특정 Stage 한 대를 대상으로 시작하더라도 MachineDefinition, 3D Model, Device Adapter만 교체하면 Aligner, Load Port, EFEM, Tray Handler, Wafer Sorter, Inspection Stage로 확장할 수 있는 구조가 좋습니다.

장기적으로는 이 플랫폼이 고객에게 제공되는 원격진단, 장애 Replay, 예지보전 서비스로 발전할 수 있습니다. 즉, 기술을 내부 개발비로 소비하는 것이 아니라 서비스 매출과 차기 장비 수주로 연결하는 선순환 구조를 만들 수 있습니다.

■ 4편 핵심 정리

좋은 WPF 디지털 트윈은 3D 화면에서 시작하지 않습니다.

Domain → Equipment Model → Communication → Twin Core → Logging/Replay → WPF UI → AI라는 계층을 먼저 만들고, 각 계층의 책임과 Interface를 고정해야 합니다.

특히 Equipment Model을 중심에 두면 실제 장비, Simulator, Replay, AI가 동일한 데이터를 공유할 수 있어 장비가 달라져도 재사용 가능한 플랫폼으로 발전할 수 있습니다.

다음 편 예고
5편에서는 기계설계팀으로부터 STEP, 원본 Assembly, Simplified Model, Axis, Stroke, Home, Pivot, 좌표계 정보를 어떤 규격으로 받아야 하는지 실무 체크리스트와 함께 정리합니다.

태그
#DigitalTwin #WPF #CSharp #SoftwareArchitecture #MVVM #EquipmentModel #DigitalTwinCore #PLC #MotionControl #Logging #Replay #Simulator #EventBus #MachineVision #PredictiveMaintenance #PhysicalAI #반도체장비 #산업자동화 #스마트팩토리 #RND