Executable Digital Twin: 잴 수 없는 유리 용해로 안을 AI로 추정하는 Vivix 시범

센서를 둘 수 없는 설비 내부도, 물리 모델을 가볍게 줄여 데이터 옆에서 상시 돌리면 실시간으로 추정할 수 있습니다. Vivix는 이 방식으로 유리 용해로의 과열을 몇 시간 앞서 잡고 에너지를 3~5% 줄이는 것을 노립니다. 따라 하려면 먼저 센서 태그를 한 이름 체계로 묶고, 측정 가능한 지점에서 예측과 실측을 계속 맞춰 볼 장치를 갖춰야 합니다.

요약

브라질 판유리 제조사 Vivix는 건축·가구용 유리와 거울을 만듭니다. 생산의 중심은 float-glass(녹인 유리를 주석 위에 띄워 평평하게 만드는 공법) 용해로입니다. 로 안은 1,550~1,600°C라서 연소 가스, 녹은 유리, 내화물 벽을 직접 보기 어렵습니다. 2026년 10월 21일 Snowflake 블로그에 Vivix·Siemens·Snowflake·NVIDIA 담당자 네 명이 함께 쓴 글은 이 용해로의 executable digital twin(xDT, 실행형 디지털 트윈)을 만드는 과정을 소개합니다. Siemens Simcenter의 다중물리 모델을 reduced order model(ROM, 계산을 줄인 축소 모델)로 바꿔 가벼운 실행 파일로 만들고, 이를 Snowflake 안에 배포해 센서 데이터 바로 옆에서 돌립니다. 여기에 NVIDIA PhysicsNeMo로 만든 AI surrogate(대리 모델)를 더합니다.

무거운 시뮬레이션을 가벼운 실행 파일로 줄여, 데이터가 있는 곳에서 바로 돌립니다.

결과는 아직 전망입니다. Vivix는 시범을 근거로 용해로 에너지 사용 3~5% 절감, 로 수명 1년 연장, 데이터 수집·분석 주기 80% 단축을 기대합니다. 프로젝트는 진행 중이고, 이 수치는 참여 벤더들이 함께 쓴 글에 나온 기대치입니다. 효과가 나는 이유는 세 가지입니다. 바깥의 측정값으로 안쪽 상태를 상시 추정하는 virtual sensor(가상 센서)가 생기고, 내화물 과열을 몇 시간 앞서 알 수 있으며, 운전 조건을 실제 로가 아니라 트윈에서 먼저 시험할 수 있습니다. 아래에서는 이 구조를 다섯 개념으로 풀고, 우리 공장의 고온·연속 공정에 옮길 때 필요한 기술·현업 디테일을 덧붙였습니다.

시범 결과에서 나온 기대치입니다(벤더 공동 발표). 운영 실측치가 아닙니다.

핵심 메커니즘

Executable Digital Twin: 물리 모델을 어디서나 돌릴 수 있게 묶은 실행 파일

무엇인가. Siemens는 xDT를 실시간으로 돌 수 있는 설비 거동 모델로 설명합니다. 혼자 실행되고 실시간 IoT 데이터에 연결되도록 포장한 것입니다. 어떻게 작동하나. 고충실도 물리 모델은 한 번 풀 때 시간이 오래 걸립니다. Simcenter Reduced Order Modeling은 이를 머신러닝·선형대수·통계 기법으로 줄여, 메모리를 적게 쓰고 실시간으로 도는 ROM을 만듭니다. ROM과 풀이기(solver)를 한 패키지로 묶으면 엣지 장비나 클라우드 어디서든 실행됩니다. 수명주기는 Simcenter Executable Digital Twin Manager가 관리합니다. 언제 쓰나. 같은 설비에 같은 질문을 자주, 빨리 던져야 할 때 씁니다. 설계 단계에서 한 번 깊이 따져 볼 문제라면 원래 시뮬레이션이 낫습니다. 원문의 예. Vivix는 이 실행 파일을 Snowflake 안에 바로 배포했습니다. 시뮬레이션 환경에 계속 붙어 있지 않아도 됩니다.

xDT는 축소 모델과 풀이기를 한 묶음으로 만들어 어디서든 실행하게 한 것입니다.

Virtual Sensor: 잴 수 없는 곳의 값을 바깥 측정값으로 추정

무엇인가. 물리 센서를 둘 수 없는 위치의 값을 계산으로 만들어 내는 센서입니다. 어떻게 작동하나. 입력은 열전대처럼 잴 수 있는 지점의 실시간 값입니다. 트윈은 이를 물리 법칙과 학습한 관계에 넣어 로 안쪽의 체적 열 분포, 가스 속도장, 내화물 벽을 지나는 열유속을 거의 실시간으로 다시 그립니다. 언제 쓰나. 고온·고압·회전체처럼 센서가 견디지 못하거나 설치할 수 없을 때 씁니다. 잴 수 있는 값이라면 센서를 다는 편이 단순합니다. 작은 예시(가상). 시멘트 킬른 운영팀이 킬른 외벽 온도 20곳만으로 내부 코팅 두께를 추정하는 경우가 같은 구조입니다.

1,550~1,600°C 안쪽처럼 센서를 둘 수 없는 곳의 값을 바깥 측정값으로 추정합니다.

Unified Namespace: IT·OT 데이터를 한 이름 체계로 모으기

무엇인가. unified namespace(UNS)는 공장의 모든 데이터를 한 계층형 이름 체계로 모은 저장 구조입니다. 어떻게 작동하나. Vivix는 생산·품질 같은 IT 데이터와 센서 값 같은 OT(운영 기술) 데이터를 Snowflake의 UNS로 모았습니다. 엔지니어링과 운영 팀은 거버넌스가 걸린 한 화면에서 관측값과 트윈 예측값을 나란히 봅니다. 언제 쓰나. 트윈이 쓸 입력과 트윈이 낸 출력을 같은 이름으로 묶어야 할 때 필요합니다. 이름이 시스템마다 다르면 예측을 실측과 맞춰 볼 수 없습니다. 원문은 UNS의 세부 소스나 스키마는 밝히지 않았습니다.

관측값과 예측값을 같은 이름 체계 안에서 나란히 봅니다.

Physics AI Surrogate: 물리 인과를 배운 빠른 대리 모델

무엇인가. PhysicsNeMo는 NVIDIA의 오픈소스(Apache 2.0) PyTorch 프레임워크입니다. 물리와 시뮬레이션 결과, 관측 데이터를 함께 써서 빠른 대리 모델을 학습시킵니다. 어떻게 작동하나. 고충실도 시뮬레이션을 여러 조건에서 돌려 결과를 쌓고, 신경망이 입력 조건과 결과 사이의 관계를 배웁니다. PINN(물리 방정식을 손실에 넣는 신경망), neural operator, graph neural network 같은 구조를 고를 수 있습니다. 학습이 끝나면 같은 질문에 시뮬레이션보다 훨씬 빨리 답합니다. 원문의 예. Vivix 팀은 유리 용해와 내화물 벽의 conjugate heat transfer(고체·유체 사이 열전달을 함께 푸는 계산)를 PhysicsNeMo로 학습시켰고, 결과는 NVIDIA Omniverse 라이브러리로 함께 검토합니다.

surrogate는 시뮬레이션 결과를 배워 같은 질문에 훨씬 빨리 답합니다.

What-if 멀티에이전트 인터페이스: 운전원이 트윈에 말로 묻기

무엇인가. Snowflake의 AI 멀티에이전트 인터페이스로 운전원이 트윈에 자연어로 질문하는 창구입니다. 어떻게 작동하나. 엔지니어가 최적 공기 속도를 묻거나, 운전 조건을 바꾸는 what-if 시나리오를 돌리거나, 이상의 근본 원인 진단을 요청합니다. 시나리오는 실제 로가 아니라 트윈 안에서 시험됩니다. 언제 쓰나. 실제 설비에서 낯설거나 위험한 조건을 시도할 수 없을 때 가장 쓸모가 큽니다. 원문은 에이전트가 쓰는 도구나 ROM을 부르는 방식은 밝히지 않았습니다.

실제 로를 낯선 조건에 두지 않고, 트윈 안에서 먼저 시험합니다.

통념과 다른 주장

흔히 이렇게 봅니다설비 예측에서는 느리지만 정확한 물리 시뮬레이션과, 빠르지만 물리 근거가 약한 데이터 기반 AI 가운데 하나를 고른다고 봅니다.

저자는 이렇게 봅니다둘을 맞바꿀 필요가 없습니다. 물리 모델을 줄이고 AI 대리 모델을 더하면 물리 근거를 지키면서 실시간으로 돌릴 수 있습니다.

근거Vivix의 가상 센서는 ROM과 PhysicsNeMo 대리 모델을 섞어, 무거운 시뮬레이션 환경 없이 로 내부 상태를 거의 실시간으로 추정합니다.

속도와 물리 근거를 맞바꾸지 않는다는 것이 이 글의 출발점입니다.

흔히 이렇게 봅니다운전 설정값은 현장에서 조금씩 바꿔 보고 결과를 보며 맞춰 갑니다.

저자는 이렇게 봅니다시나리오 시험의 장소를 트윈으로 옮겨야 합니다. 실제 설비를 낯설거나 위험한 조건에 두지 않아도 됩니다.

근거Vivix의 엔지니어는 공기 속도 같은 운전 조건을 바꾸는 what-if를 트윈에서 먼저 돌립니다. 저자들은 이것을 실제 설비를 알 수 없거나 안전하지 않은 조건에 두지 않는 방법으로 설명합니다.

운전 조건 탐색의 장소를 실제 설비에서 트윈으로 옮깁니다.

저자가 든 사례

Vivix 용해로 시범: 세 영역을 한 트윈으로

구분	내용
상황	1,550~1,600°C 용해로 내부(연소 가스·녹은 유리·내화물 벽)를 직접 보기 어려움. 원문은 용해로를 “one of the most critical assets”라고 부름
한 일	Siemens ROM 실행 파일을 Snowflake에 배포, IT·OT 데이터를 UNS로 통합, PhysicsNeMo 대리 모델 추가, 자연어 what-if 인터페이스 제공. 클라우드는 AWS
결과	시범 기준 전망: 에너지 3~5% 절감, 로 수명 1년 연장, 분석 주기 80% 단축. 시범 기간·기준선·범위는 원문에서 밝히지 않음
연결	xDT, 가상 센서, UNS, surrogate, what-if 인터페이스가 모두 쓰인 사례

세 영역은 같은 기반 위에서 돌아갑니다. 내화물 쪽은 실시간 열전대 값과 내화물 열 프로파일을 합쳐 국부 마모율을 계산하고, 생기기 시작한 핫스폿을 몇 시간 앞서 잡습니다. 목표는 cold repair(로를 식혀서 하는 대수리) 전까지의 campaign(로를 한 번 가동해 끌 때까지의 기간)을 늘리는 것입니다. 연소 쪽은 공기 흐름·열 모델로 버너 출력과 열 분포를 평가해 설정값을 고르고, 천연가스와 배출을 줄입니다. 용해 쪽은 녹은 유리의 열 구배와 유동을 모델링해 체류 시간 분포와 용해 완료도를 추정하고, 균질도를 높이고 결함을 줄입니다.

세 영역 모두 같은 트윈과 같은 데이터 기반 위에서 돌아갑니다.

결과는 시범 기반 전망이며 프로젝트는 진행 중입니다.

기술 디테일: 우리 설비에 이 구조를 옮기려면

UNS를 만들려면 태그 이름부터 정합니다(UNS 메커니즘). 가상 예시로 site/line/asset/zone/measure 형식을 쓰면 plant1/furnace1/crown/z03/temp_c처럼 됩니다. 트윈 출력도 같은 경로 아래 virtual/ 접두어를 붙여 저장합니다. 그래야 예측과 실측을 같은 키로 이을 수 있습니다. 열전대 값은 1~10초 간격으로 들어오므로, 트윈 입력용으로 1분 평균 테이블을 따로 둡니다.

가상 센서 출력은 구조화해서 남깁니다(가상 센서 메커니즘). 가상 예시 필드: asset_id, zone, ts, quantity(heat_flux 등), value, unit, model_id, model_version, input_window, ood_flag(학습 범위를 벗어난 입력인지). model_version이 없으면 경보가 났을 때 어느 모델이 낸 값인지 되짚을 수 없습니다.

ROM을 데이터 옆에서 돌리려면 실행 방식을 먼저 고릅니다(xDT 메커니즘). 원문은 Snowflake 안의 배포 방식을 밝히지 않았습니다. 실제로는 컨테이너 서비스나 Python 함수 같은 선택지를 놓고, 호출 주기(예: 1분), 1회 실행 시간, 동시 실행 수를 재 보고 정합니다. 1회 실행이 주기보다 길면 구역을 나눠 병렬로 돌립니다.

surrogate를 믿으려면 잔차를 감시합니다(surrogate 메커니즘). 측정 가능한 지점에서는 예측과 실측의 차이(잔차)를 매분 계산합니다. 가상 예시 기준: 1시간 평균 잔차가 학습 검증 오차의 2배를 넘으면 ood_flag를 켜고 재보정 대상으로 올립니다. 내화물 마모가 진행되면 로 상태 자체가 바뀌므로, 분기마다 최근 데이터로 다시 맞춥니다. 학습 전에 고충실도 시뮬레이션 결과의 20% 정도는 떼어 두고 검증에만 씁니다.

가상 예시: 측정 가능한 지점에서 계속 맞춰 보며 모델의 신뢰를 유지합니다.

핫스폿 경고는 단계로 나눕니다(내화물 사례). 가상 예시: 예측 벽 온도가 구역 기준선보다 15°C 넘게 높으면 ‘관찰’, 시간당 5°C 넘게 오르면 ‘주의’, 두 신호가 30분 넘게 함께 이어지면 ‘조치’로 올려 내화물 담당에게 알립니다. 경고마다 근거 구역, 입력 값, 모델 버전을 함께 붙입니다.

what-if 에이전트에는 도구를 좁게 줍니다(what-if 메커니즘). 가상 예시 도구: query_uns(path, window), run_twin(scenario), compare(baseline, scenario). 에이전트는 시나리오를 돌리고 비교표를 만들 뿐, 제어 시스템에 설정값을 쓰지 않습니다. 같은 질문을 3회 돌려 추천 설정값이 달라지면 답 대신 ‘불확실’을 돌려줍니다. 답변에는 쓴 데이터 구간과 모델 버전을 꼭 붙입니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	하는 일
공정 엔지니어(현업 리더)	우선 문제 하나 고르기, 판정 기준 승인
내화물·설비 담당	핫스폿 경고의 기준과 대응 절차 정의
운전원(교대조 대표)	what-if 질문 목록 작성, 경고 실사용 평가
시뮬레이션 엔지니어	ROM·surrogate 학습과 재보정
OT·데이터 엔지니어	태그 정리, UNS 구축, 잔차 대시보드

시작 전 준비물. 열전대·버너·유량 태그 목록과 위치도, 최근 1~2년 운전 기록, 과거 내화물 점검·수리 기록, 기존 설계용 시뮬레이션 모델이 있는지 여부, 에너지 사용량 월별 기준선입니다.

가상 예시: 데이터 기반부터 깔고, 경고와 질의를 차례로 올립니다.

확인 질문. 가장 비싼 비계획 정지는 무엇 때문이었나? 지금 로 안쪽을 어떤 간접 지표로 판단하나? 경고가 오면 누가 몇 분 안에 무엇을 하나? 설정값을 바꿀 권한은 누구에게 있나?

진행 판정(가상 예시). 8주차에 세 가지를 봅니다. 측정 지점 잔차가 합의한 허용 범위 안에 있는가, 과거 기록을 다시 돌렸을 때 실제 이상 징후를 경고가 미리 잡았는가, 운전원이 what-if 답을 근거와 함께 설명받았다고 평가하는가. 셋 중 둘 이상이면 다음 단계로 넘어갑니다.

AX 적용 제언. 이 구조가 가장 잘 맞는 곳은 유리·시멘트·철강·석유화학처럼 고온 연속 공정을 돌리고, 설비 하나가 멈추면 손실이 큰 기업입니다. 순서는 데이터 기반(UNS) → 가상 센서와 잔차 감시 → 경고 → what-if 질의가 무난합니다. 처음부터 에너지 최적화를 약속하기보다, 내화물 과열 경고처럼 성과를 바로 확인할 수 있는 문제 하나로 시작합니다. 스폰서는 공장장이 맡고, 설정값을 바꾸는 최종 결정은 끝까지 사람에게 남겨 둡니다.

원문 사례

항목	내용
저자	Aristóteles Terceiro Neto(Vivix), Leoluca Scurria(Siemens), Pugal Janakiraman(Snowflake), Zihan Wang(NVIDIA)
발표처·날짜	Snowflake 블로그, 2026.10.21
기업	Vivix, 브라질 판유리 제조사
대상 설비	float-glass 용해로, 1,550~1,600°C
구성	Siemens Simcenter ROM·xDT Manager, Snowflake UNS·Cortex AI·멀티에이전트 인터페이스, NVIDIA PhysicsNeMo·Omniverse, AWS
세 영역	내화물 건전성, 연소·에너지 효율, 용해·품질
기대 효과(시범 기준)	에너지 3~5% 절감, 로 수명 1년 연장, 수집·분석 주기 80% 단축
진행 상황	개발 중, 운영 확대 일정은 원문에서 밝히지 않음

핵심 개념

Reduced Order Model (ROM): 고충실도 물리 모델의 거동을 적은 계산으로 흉내 내도록 줄인 모델
Simcenter Executable Digital Twin Manager: xDT 실행 파일의 버전과 배포를 관리하는 Siemens 도구
Refractory: 로 벽을 이루는 내화물. 고열에 깎이며 수명이 로 가동 기간을 정함
Campaign · Cold repair: 로를 한 번 가동해 끌 때까지의 기간, 그리고 로를 식혀서 하는 대수리
Residence time distribution: 녹은 유리가 로 안에 머무는 시간의 분포. 용해 품질을 가늠하는 지표
NVIDIA Omniverse: 3D 시뮬레이션 결과를 여러 사람이 함께 보고 검토하는 플랫폼

내 메모

TODO: 내 생각 추가

원문: Aristóteles Terceiro Neto, Leoluca Scurria, Pugal Janakiraman, Zihan Wang, “Executable Digital Twin for Optimizing Manufacturing Operations of Float-Glass Production”(Snowflake 블로그, 2026.10.21). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 저자들이 언급한 내용을 AX Review가 다시 정리했습니다. 기대 효과 수치는 참여 벤더들이 함께 쓴 글에 실린 시범 기준 전망입니다. xDT와 ROM의 작동 방식은 Siemens Simcenter Executable Digital Twin 제품 페이지에서, PhysicsNeMo의 구조와 라이선스는 NVIDIA PhysicsNeMo 개발자 페이지에서 보강했습니다. 기술·현업 디테일, 필드명, 경고 단계, 일정·판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체는 Snowflake 블로그에서 볼 수 있습니다.