기술
문서와 3D 파일을 단순히 검색하는 것이 아니라, 실제 엔지니어링 객체의 식별자, 관계, 공간 맥락과 근거를 연결해 AI가 프로젝트를 이해하고 분석할 수 있게 합니다.
Pain Point — 공정 데이터는 SmartPlant P&ID Database나 엔지니어링 리스트에 있지만, AI가 원본만으로 동일한 객체 식별자와 관계를 읽지는 못합니다.
SmartPlant P&ID Database와 Process/Equipment/Line/Valve/Instrument/Drawing List를 입력으로 받아, DEXPI 2.0 스펙에 맞춰 객체 유형, 속성, 식별자와 관계를 정규화한 뒤 Process Rich Tag Graph를 생성합니다. P&ID가 없는 경우에도 리스트 기반 약식 Graph를 만들 수 있지만, 연결 구조와 문맥의 풍부함은 원본 P&ID 경로보다 제한적입니다.
이 객체는 무엇이며 무엇과 연결되어 있는가?
Pain Point — 문서·도면의 태그가 하나의 3D 객체로 깔끔하게 대응되지 않는 경우가 많습니다.
Tag Resolver는 엔지니어링 태그를 식별자, 명명 규칙, 계층구조, 모델 컨텍스트로 실제 3D 대상에 연결합니다. 문서·도면 태그만으로는 대응이 불명확한 경우에도 후보와 신뢰도를 남기고, 모호하면 사람이 최종 매핑을 확인할 수 있도록 근거와 후보 집합을 함께 제공합니다. 목표는 추측이 아니라 추적 가능한 객체 식별이며, 설계 검토의 첫 출발점이 됩니다.
이 태그가 가리키는 실제 3D 대상은 무엇인가?
Pain Point — 3D 모델에는 형상이 있지만, AI가 쓸 객체 식별자·계층구조·관계와 공간 컨텍스트는 별도로 구조화되어야 합니다.
Spatial Graph는 Smart3D의 객체, 계층구조, 위치, 관계와 메타데이터를 기반으로 구성합니다. 필요에 따라 AVEVA RVM/ATT 또는 Navisworks의 객체 속성과 계층 정보에서도 공간 컨텍스트를 구성할 수 있습니다. 풍부함은 동일하지 않습니다 — Smart3D가 가장 풍부하고, AVEVA RVM/ATT는 대안 엔지니어링 모델 경로이며, Navisworks 속성/계층은 약식·폴백입니다.
이 객체는 어디에 있고 주변과 어떤 관계를 갖는가?
Pain Point — 근접 검색만으로는 엔지니어가 지금 검토해야 할 주변 범위를 정할 수 없습니다.
Spatial Resolver는 엔지니어링 의도와 문서 요구를 Spatial Graph와 qualified spatial rule로 해석해, 설계 검토에 필요한 주변 공간과 관계를 선택합니다. 근접 거리만으로 범위를 정하지 않으며, 최근접 이웃 검색이나 scene-graph 순회가 아니라 검토에 실제로 필요한 이웃을 찾는 것이 목적입니다. 규칙의 출처와 적용 이유도 함께 설명할 수 있어야 합니다.
지금 어떤 공간과 관계를 검토해야 하는가?
Pain Point — 검토 판단이 남아도, 나중에 추적할 수 있는 엔지니어링 근거 패키지가 없는 경우가 많습니다.
Evidence Snapshot은 객체, 리비전, Viewpoint, 관련 요구사항·문서 조항, 공간 규칙·컨텍스트와 검토 근거를 함께 담는 결과 패키지입니다. 화면 캡처가 아니라 사람과 AI가 같은 근거로 판단을 추적할 수 있도록, 검토 시점의 컨텍스트를 휴대 가능한 형태로 남기는 것이 목적입니다. 승인 대체나 최종 처분이 아니라 근거를 남기는 일입니다.
무엇을 보고 왜 그렇게 판단했는가?
파일 검색 → 객체 식별 → 관계 이해 → 공간 이해 → 분석 → 설계 검토 지원 → 근거 제시
