디지털 트윈을 구축할 때 많은 팀이 가장 먼저 CAD 파일을 요청합니다. 하지만 실제 프로젝트를 진행해 보면 STEP 파일 하나만 받아서는 장비를 제대로 움직일 수 없습니다. 장비 형상이 있어도 어떤 부품이 어느 축에 속하는지, 회전축의 중심이 어디인지, 좌표계가 어떻게 연결되는지 모르면 가상 장비는 단순한 3D 모델에 머물게 됩니다.
따라서 기계설계팀으로부터 받아야 할 데이터는 단순한 ‘형상 파일’이 아니라 가상 장비가 실제 장비처럼 움직일 수 있도록 정의된 구조 데이터 패키지여야 합니다. 이번 편에서는 어떤 데이터를 어떤 형식으로 받아야 하는지, 그리고 어떻게 표준화해야 이후 장비에서도 재사용 가능한지를 정리합니다.
원본 CAD는 설계 변경 이력과 Assembly 관계를 확인하는 데 필요합니다. SolidWorks라면 SLDASM/SLDPRT, Inventor라면 IAM/IPT 같은 Native 파일이 해당합니다.
하지만 Digital Twin 소프트웨어에서 직접 Native CAD를 사용하는 것은 현실적으로 어렵습니다. 따라서 표준 교환 형식인 STEP(.stp/.step)을 함께 받아 두는 것이 좋습니다.
원본 CAD는 설계의 기준 데이터, STEP은 중립적인 전달 포맷이라고 생각하면 됩니다.
기계설계용 CAD에는 볼트, 너트, 와셔, 케이블 캐리어, 작은 브라켓, 내부 가공 형상, 미세 필렛, 반복 체결 부품 등 디지털 트윈 시각화에는 불필요한 형상이 매우 많습니다.
이 모델을 그대로 렌더링하면 Polygon 수가 과도하게 늘어나고 Loading Time, Memory, Frame Rate가 악화됩니다.
따라서 별도의 Digital Twin Simplified Model을 요청하는 것이 좋습니다. 고정부와 이동부의 형상은 유지하되, 시각화에 불필요한 세부 형상은 제거한 모델입니다.
디지털 트윈에서 가장 중요한 것은 어떤 부품이 어떤 축과 함께 움직이는지입니다. 예를 들어 X축 위에 Y축이 있고 Y축 위에 Z축과 Camera가 올라가 있다면 이 Parent-Child 관계가 그대로 유지되어야 합니다.
예를 들면 다음과 같은 구조가 적절합니다.
Machine → Gantry → XAxis → YAxis → ZAxis → Camera
Stage는 Machine 아래에서 독립적으로 움직이고, Robot은 Joint1→Joint2→Joint3 식의 계층 구조를 가져야 합니다.
이 구조가 없으면 X축을 움직였는데 Y축이나 Camera가 따라오지 않는 문제가 생길 수 있습니다.
각 운동축마다 최소한 다음 정보를 받아야 합니다.
- Axis ID / Axis Name
- Linear 또는 Rotary
- Positive Direction
- Stroke 또는 회전범위
- Home Position
- Mechanical Zero
- 단위(mm, deg)
- Gear Ratio
- Encoder Resolution
- Max Speed / Acceleration
이 정보는 3D Animation뿐 아니라 Simulator와 Replay에도 공통으로 사용됩니다.
Linear Axis는 방향과 이동거리만 맞으면 비교적 쉽게 구현할 수 있지만 Rotary Axis는 다릅니다. 회전 중심점(Pivot)이 틀리면 3D 모델이 실제 장비와 전혀 다른 궤적으로 움직입니다.
따라서 Theta Stage, Robot Joint, 회전 Chuck 등은 반드시 Pivot X/Y/Z와 회전축 방향, CW/CCW 기준을 기계설계팀에서 받아야 합니다.
가능하다면 도면상 기준점이나 Datum과 연결해 정의하는 것이 좋습니다.
산업장비에는 하나의 좌표계만 존재하지 않습니다. Machine, Stage, Robot, Camera, Work, Wafer, Tray 좌표계가 동시에 존재할 수 있습니다.
각 좌표계의 원점과 축 방향, 상호 Transformation을 문서화하지 않으면 Vision 좌표와 Motion 좌표를 연결할 때 문제가 발생합니다.
따라서 최소한 다음 변환을 명확히 관리하는 것이 좋습니다.
Robot→Machine, Camera→Machine, Stage→Machine, Work→Machine
향후 Hand-Eye Calibration, Pick & Place 보정, Vision 좌표 변환을 모두 이 구조 위에 올릴 수 있습니다.
장비가 늘어나면 파일명이 제각각인 것이 큰 문제가 됩니다. Base_final_v2.step, XAxis_new.step, X축최종.step 같은 파일은 시간이 지나면 누가 봐도 혼란스럽습니다.
따라서 Part ID, Axis ID, 파일명 규칙을 통일하는 것이 좋습니다.
예: MC01_BASE.step, MC01_XAXIS.glb, AX01_X, RB01_J1
이 Naming Rule은 CAD, 제어 Tag, Log, Replay, 3D Model까지 동일하게 사용하는 것이 이상적입니다.
기계설계팀에서 Digital Twin팀으로 전달할 때 다음과 같은 구조를 추천합니다.
01_CAD/ — Machine_Assy.step, Robot.step, Stage.step, Vision_Module.step
02_3D_Display/ — Base.glb, XAxis.glb, YAxis.glb, ZAxis.glb, Robot.glb
03_Drawing/ — Machine_Layout.pdf, Axis_Drawing.pdf, Assembly_Drawing.pdf
04_Data/ — Axis_List.xlsx, Coordinate_System.xlsx, Motor_List.xlsx, Sensor_List.xlsx
이 구조를 표준화하면 장비가 바뀌어도 같은 방식으로 데이터를 받아 자동 변환 파이프라인을 만들 수 있습니다.
궁극적으로는 기계설계 데이터가 들어오면 STEP을 경량화해 GLB로 변환하고, Axis와 Assembly 정보를 MachineDefinition.json 같은 설정 파일로 생성할 수 있어야 합니다.
그러면 WPF Digital Twin은 장비마다 코드를 새로 만들지 않고 Model과 Configuration만 바꿔 여러 장비를 로딩할 수 있습니다.
이 단계가 되면 WTR, Aligner, Load Port, Tray Handler, Stage 등 서로 다른 장비에 같은 Digital Twin Engine을 적용할 수 있습니다.
CAD 파일을 받았다고 바로 개발에 들어가기보다 데이터 품질을 먼저 확인해야 합니다.
- 이동부/고정부 분리가 제대로 되어 있는가
- Assembly Parent-Child 관계가 실제 장비와 일치하는가
- Pivot이 정확한가
- 좌표축 방향이 문서와 일치하는가
- Stroke와 실제 설계값이 같은가
- GLB 변환 후 형상 누락이 없는가
- 파일명과 ID가 표준화되어 있는가
이 검증이 끝난 뒤 3D 연결 작업에 들어가야 뒤늦은 재작업을 줄일 수 있습니다.
디지털 트윈을 위해 기계설계팀에서 받아야 할 것은 STEP 파일 하나가 아닙니다.
형상 데이터 + Assembly 관계 + Axis 정의 + Pivot + 좌표계 + Drawing + Naming Rule이 하나의 패키지로 전달되어야 합니다.
이 데이터 구조를 표준화하면 향후 새로운 장비가 개발될 때 CAD를 받아 자동으로 경량화하고, MachineDefinition을 생성해 동일한 WPF Digital Twin Engine에서 사용할 수 있습니다.
6편에서는 원본 CAD를 디지털 트윈용 3D 모델로 바꾸는 경량화 전략을 다룹니다. 어떤 형상을 제거해야 하고, STEP을 GLB/glTF로 변환할 때 무엇을 보존해야 하며, 성능과 정밀도의 균형을 어떻게 잡을지 구체적으로 살펴봅니다.
#DigitalTwin #디지털트윈 #WPF #CAD #STEP #GLB #glTF #MechanicalDesign #Assembly #Axis #Pivot #CoordinateSystem #MachineDefinition #반도체장비 #산업자동화 #3DVisualization #기계설계 #스마트팩토리 #RND
'경제' 카테고리의 다른 글
| WPF 디지털 트윈 연재 07 - STEP·STL·OBJ·glTF·GLB 파일 형식 비교와 선택 전략 (0) | 2026.10.13 |
|---|---|
| WPF 디지털 트윈 연재 06 - CAD 데이터와 디지털 트윈용 3D 모델 경량화 전략 (0) | 2026.10.13 |
| WPF 디지털 트윈 연재 04 - 전체 시스템 아키텍처 (0) | 2026.10.13 |
| WPF 디지털 트윈 연재 03 - 왜 WPF 기반 디지털 트윈인가 (0) | 2026.10.06 |
| WPF 디지털 트윈 연재 02 - Digital Model, Digital Shadow, Digital Twin의 차이 (0) | 2026.10.05 |
