I built a digital twin of my amateur-built airplane

기술 모임에서 동료가 나에게 제안했지만 나는 그 자리에서 그것을 무시했습니다. 디지털 트윈은 팀과 예산이 일치하는 자동차 공장이나 항공사가 하는 일과 비슷했습니다. 나는 여가 시간에 소형 고성능 실험용 비행기를 유지 관리하고 조종합니다. 그 아이디어는 내 격납고에 맞지 않는 것 같았습니다.

씨앗이 심어졌고, 머지않아 나는 그것에 대한 생각을 멈출 수가 없었습니다. 제가 묻고 싶은 질문을 나열하기 시작했습니다. 그 중 일부는 당황스러울 정도로 단순했습니다. 휠팬츠에 어떤 사이즈의 패스너가 들어가나요? 에일러론 힌지 볼트의 토크 값은 얼마입니까? 실제로 어떤 공기 필터 모델을 실행합니까? 매번 찾아보고 잊어버리고 다시 찾아보는 것들이죠. 그러자 질문은 더욱 복잡해졌습니다. 내 석유 소비 추세는 어떻습니까? 비행기를 소유한 지 몇 년이 지나면서 엔진 성능이 변합니까? 그리고 재미있는 것들. 2시간 미만의 비행 시간으로 내 로그북에 10개의 새로운 공항을 추가하는 경로를 계획할 수 있습니까?

얼마 지나지 않아 나는 디지털 트윈이 이 모든 질문에 답하고 추적하는 데 도움이 되도록 구축해야 한다고 확신했습니다. 제가 배운 것은 무엇이며, 무엇을 유지하든 여러분도 하나를 만들 수 있다고 생각하는 이유는 다음과 같습니다.

실제로 디지털 트윈이란 무엇입니까?

디지털 트윈은 물리적인 사물의 살아있는 모델로, 해당 사물에 대한 실제 데이터와 동기화됩니다. 3D 렌더링도 아니고 대시보드도 아니지만 둘 다 제공할 수는 있습니다. 귀하의 자산이 무엇인지, 무슨 일이 일어났는지, 현재 어떤 상태인지에 대한 기록으로, 질문하고 실제 답변을 얻을 수 있도록 구조화되어 있습니다.

전체 프로젝트를 클릭하게 만든 부분은 다음과 같습니다. 비행기는 이미 그래프입니다. 연결된 사물의 네트워크입니다. 기체에는 엔진이 있습니다. 엔진에는 4개의 실린더가 있습니다. 비행기는 100편의 항공편을 비행했으며 각 항공편은 한 공항에서 출발하여 다른 공항에 도착했습니다. 모든 오일 샘플은 원래 있던 엔진에 다시 연결됩니다. 모든 유지 관리 항목은 영향을 받은 부품과 연결되어 있습니다. 시간이 지남에 따라 다른 소유자가 항공기에 연결할 수 있습니다.

대부분의 가치는 개별 레코드가 아닌 해당 연결에 있습니다. 그래프 데이터베이스는 화이트보드에 그리는 것과 같은 방식으로 연결을 직접 저장합니다. 그래서 비행기를 그래프로 모델링하면 제가 묻고 싶은 질문이 데이터 위에 깔끔하게 매핑됩니다. 비행기를 스프레드시트 더미로 납작하게 만든 다음 매번 머리 속에서 다시 조립할 필요가 없습니다.

집에서 만든 비행기용 비행기를 만드는 이유

자체 항공기를 유지관리하고 있다면 데이터가 어디에 있는지 이미 알고 있을 것입니다. 그것은 어디에나 산다. 엔진 모니터는 CSV 파일을 내보냅니다. 오일 분석은 실험실에서 PDF로 반환됩니다. 조종사 운영 핸드북은 Word 문서입니다. 무게와 균형은 스프레드시트입니다. 기체와 엔진 일지는 수십 년 동안 손으로 쓴 종이로 작성되었습니다. 감항성 지침과 서비스 게시판은 분산된 디지털 더미이므로 내 비행기의 시스템, 부품 및 일련번호에 어떤 지침이 적용되는지 아는 것은 나에게 달려 있습니다.

1년에 한 번 상태 검사는 모든 것을 손으로 모으는 것을 의미합니다. 나는 FAA 및 공급업체 웹사이트에 걸쳐 감항성 지침 및 안전 게시판에 대해 설치된 일지와 부품 목록을 상호 참조합니다. 이는 실수할 수 있는 영역이 아니므로 정보를 수집하려면 철저하고 힘든 노력이 필요합니다.

나는 매번 그 그림을 처음부터 다시 조립하는 것을 멈추고 싶었습니다. 나는 하나의 질문을 하고 모든 데이터에서 동시에 하나의 답변을 얻고 싶었습니다.

쌍둥이에 들어가는 것

Twin은 하나의 비행기에 대한 네 가지 종류의 데이터를 통합합니다. 각 소스를 깨끗하고 일관된 모양으로 만드는 것이 작업의 대부분이었고 이 부분이 화려하지 않다는 점을 솔직하게 말씀드리고 싶습니다. 쌍둥이 중 섹시하지 않은 부분은 80%입니다.

항공기, 엔진, 프로펠러, 실린더, 항공 전자 공학, 개조 및 소유권 이력 등 기체의 정적 정체성이 먼저 나타났습니다. 여기에는 감항성 인증서 및 28가지 작동 제한 사항은 물론 내 항공기와 장비에 적용되는 감항성 지침 및 서비스 게시판을 포함한 감항성 데이터가 있는 곳이기도 합니다.

그다음에는 유지보수 내역이 나왔습니다. 이는 로그북 항목, 오일 분석 샘플 및 각 구성 요소의 실행 시간입니다. 일지에는 손으로 쓰거나 타이핑한 항목의 페이지가 포함되어 있으므로 각 페이지를 이미지로 렌더링하고 Claude에게 과거 AD에 대한 참조를 포함하여 구조화된 기록으로 읽어 달라고 했습니다.

비행 원격 측정은 대용량 소스입니다. 내 Garmin G3X Touch 기본 비행 디스플레이(PFD)는 매 비행마다 판독값을 기록합니다. 100번의 비행을 통해 약 178,000개의 개별 샘플이 수집됩니다.

참조 사양이 마무리되었습니다. 조종사 운영 핸드북은 V 속도, 중량 및 성능 데이터를 제공합니다. Lycoming 엔진 매뉴얼은 실린더 헤드 및 오일 온도와 같은 매개변수에 대한 권위 있는 작동 한계와 레드라인 수치를 제공합니다. 무게 및 균형 스프레드시트는 빈 무게와 무게 중심 포락선을 제공합니다.

PDF, Word 파일, 손으로 쓴 페이지 등 기계가 읽을 수 있는 형식이 없는 문서의 경우 Claude를 사용하여 정의된 스키마로 값을 추출한 다음 데이터베이스에 기록했습니다. 모든 추출 실행은 자체 비용과 오류를 기록했기 때문에 사후에 무슨 일이 일어났는지 감사할 수 있었습니다.

내가 만든 방법

그래프는 모든 것의 중추입니다. 관리형 클라우드 버전인 Neo4j AuraDB에서 실행되므로 데이터베이스 서버를 관리하지 않습니다. 모델은 화이트보드 스케치에서 기대할 수 있는 것입니다.Aircraft노드에 연결된 노드Engine, Propeller, Cylinder, 그리고AvionicsUnit노드,Flight에 연결된 노드Airport그들이 출발하고 도착한 노드,OilAnalysis샘플을 엔진에 다시 연결하고MaintenanceEntry노드는 접촉한 부분으로 라우팅됩니다. 현재로서는 대략 1,500개의 노드와 3,800개의 관계가 있습니다. 비행기 한 대의 경우 실제 질문에 답하기에 충분합니다.

그래프가 올바른 도구가 아닌 곳이 있는데, 바로 시계열 데이터입니다. 178,000개의 샘플인 초당 비행 원격 측정은 그래프에 적합하지 않습니다. 이는 밀도가 높고 반복적이며 시간 순서가 지정된 데이터이며, 이것이 바로 시계열 데이터베이스가 구축된 이유입니다. 따라서 원격 측정은 시계열 및 비행 경로 기하학을 처리하는 TimescaleDB 및 PostGIS 확장과 함께 PostgreSQL에 있습니다. 두 매장은 공통 항공편 식별자를 공유하므로 그래프의 항공편은 Postgres의 초 단위 데이터에 바로 연결됩니다. 소방호스의 구조와 의미, 시계열 데이터베이스에 대한 그래프입니다. 둘 다 클라우드 인스턴스에서 실행되므로 쌍둥이 전체가 어디에서나 접근할 수 있는 한 장소에 있습니다.

이 분할이 익숙하게 들리면 대규모 구현에서 사용하는 것과 동일한 모양입니다. Neo4j와 Databricks는 Databricks 레이크하우스에 함대 원격 측정을 배치하고 Neo4j 지식 그래프에 항공기 토폴로지를 배치하고 함께 결합하여 단일 엔터티로 쿼리하는 상업용 항공기 디지털 트윈을 설명합니다. 나는 여가 시간에 비행기 한 대를 타고 독립적으로 같은 건축물에 도착했습니다. 그게 요점입니다. 내 격납고 프로젝트와 함대 솔루션 사이의 격차는 대부분 개념이 아니라 규모입니다.

사용방법: 그냥 물어보세요

데이터베이스의 트윈을 제가 매주 사용하는 것으로 바꾸는 부분은 다음과 같습니다. 나는 쿼리를 작성하지 않습니다. 나는 Neo4j의 공식 MCP(Model Context Protocol) 서버를 통해 Claude를 그래프에 연결하고 일반 영어로 질문합니다. MCP 서버는 Claude가 내 데이터베이스와 직접 통신할 수 있게 해줍니다. 내가 묻고, 그래프를 쿼리하고, 답을 얻습니다. 두 번째 MCP 서버는 Postgres의 원격 측정에 대해 동일한 작업을 수행하므로 구조와 비행 데이터에 대해 동일한 방식으로 질문할 수 있습니다.

나는 손에 렌치를 들고 비행기에 설 때마다 Cypher를 쓸 만큼의 인내심(또는 솔직히 능숙함)이 없습니다. 트윈이 구축되면 편집자가 직접 쿼리를 작성하는 것이 더 이상 의미가 없습니다. 나는 단지 묻는다. 솔직히 말해서 저는 타이핑하는 것이 꽤 지루하고 Wispr Flow를 사용하여 구두로 질문하는 경향이 있습니다.

작은 조회는 제가 가장 많이 사용하는 조회입니다. "주 랜딩 휠의 인플레이션 PSI는 얼마입니까?" "오일 교환 사이에 몇 쿼트의 오일을 추가했습니까?" "Garmin 내비게이션 데이터베이스는 언제 만료되나요?" 매뉴얼과 오래된 메모를 뒤지거나 격납고에 가서 살펴보게 만드는 질문들이었습니다.

추세 질문은 디지털 트윈이 유지되는 위치입니다. 시간이 지남에 따라 내 오일 소비 추세가 어떤지, 지난 1년 반 동안 분석에서 내 오일 샘플의 마모 금속이 어떤 역할을 했는지, 엔진 ​​성능이 표류하는지 물어볼 수 있습니다. 그 답은 많은 기록을 연결하는 데서 나오는데, 이것이 바로 그래프의 장점입니다.

상태 검사 연구는 훨씬 쉬워진 작업입니다. 내 항공기와 설치된 장비에 어떤 감항성 지침과 서비스 게시판이 적용되는지 물어보고 메모리와 종이 대신 데이터에서 체크리스트를 가져올 수 있습니다.

그리고 경로에 대한 질문이 있는데, 처음에 제가 건축을 시작하게 만든 재미있는 질문이었습니다. 나는 트윈에게 내가 이미 방문한 모든 공항을 알고 있기 때문에 최소 비행 거리에 대해 내 로그북에 가장 많은 새로운 공항을 추가하는 경로를 계획하도록 요청할 수 있습니다.

내가 얻는 것

가장 구체적인 이점은 시간입니다. 매뉴얼이나 종이 일지를 뒤지는 것을 의미하던 질문이 이제 몇 초 밖에 걸리지 않습니다. 하루의 대부분을 차지했던 상태 검사 연구가 더 짧아졌습니다. 쌍둥이가 저를 위해 그림을 조립해주기 때문입니다.

두 번째 이점은 가시성입니다. 개별 보고서 폴더가 아닌 추세로 마모 금속 및 오일 소비를 관찰한다는 것은 아직 작지만 느린 변화를 알아차린다는 것을 의미합니다. 이는 각 석유 보고서가 자체 PDF에 있을 때 놓치기 쉬운 종류입니다.

세 번째 이점은 측정하기 어렵지만 실제적입니다. 저는 이 비행기를 소유하고 조종하는 것을 더 즐깁니다. 패스너 크기부터 1년간의 성과 추세까지 무엇이든 물어볼 수 있게 되면서 일과의 관계가 바뀌었습니다.

이 중 어느 것도 항공에만 국한된 것이 아니며 항공기가 필요한 것도 아닙니다. 항공사는 수백 대의 항공기에서 이와 동일한 혜택을 얻습니다. 나는 취미 예산으로 한 사람이 만든 하나의 꼬리 번호로 구입합니다. 자신의 기계, 차량 또는 장비를 유지 관리하는 경우에도 동일한 접근 방식이 열려 있습니다.

다음엔 어디로 갈까

이것이 규모에 따라 어떻게 보이는지 확인하려면 Neo4j와 Databricks가 제가 착륙한 것과 동일한 그래프와 원격 측정 분할을 사용하고 전체 항공기를 위해 구축된 상용 항공기 디지털 트윈을 살펴보겠습니다. 예산과 이해관계가 커질 때 이 아이디어가 어디로 가는지 보여주는 좋은 지도입니다. 당신은 그것을 읽을 수 있습니다.

직접 구축하고 싶다면 다음에서 무료로 시작할 수 있습니다.Neo4j AuraDB. 유지 관리하는 항목을 선택하여 화이트보드에 그래프로 스케치하고 이미 이해하고 있는 연결부터 시작하세요. 그게 내가 한 전부야.

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지