Bài viết tiếp nối chuỗi nội dung về Urban Digital Twin, mở rộng từ mô hình đô thị và lớp dữ liệu không gian sang bài toán quản lý một tài sản hạ tầng trong suốt vòng đời vận hành.

Từ mô hình không gian đến tài sản có vòng đời

Ở các bài trước về Mô hình đô thị 3D và Digital Twin, chúng ta đã đi qua một nguyên tắc nền tảng: mô hình 3D chỉ là một lớp trong hệ thống biểu diễn thế giới thực. Nó cho biết đối tượng nằm ở đâu, có hình dạng ra sao và quan hệ không gian với các đối tượng xung quanh như thế nào. Tuy nhiên, khi đối tượng cần quản lý là một cây cầu, tuyến đường, đường sắt, nhà máy hoặc mạng lưới hạ tầng, câu hỏi quan trọng hơn sẽ xuất hiện: tài sản đó đang ở trạng thái nào, dữ liệu nào chứng minh trạng thái ấy, ai chịu trách nhiệm xử lý và kết quả xử lý được cập nhật trở lại hệ thống ra sao?

Đây là điểm Infrastructure Digital Twin bắt đầu trở thành một bài toán về information architecture, thay vì chỉ là bài toán dựng hình. Theo ISO/IEC 30173:2023, Digital Twin cần được nhìn cùng với bối cảnh hệ thống, vòng đời, góc nhìn chức năng và các bên liên quan. Còn ISO/IEC 30188:2026 cung cấp một reference architecture để mô tả các nền tảng của một Digital Twin system thông qua nhiều architecture view. Các tài liệu này không quy định một sản phẩm duy nhất, nhưng cho thấy một Digital Twin cần được xem như một hệ thống kết nối biểu diễn số, dữ liệu và hoạt động của thực thể mà nó đại diện.

Từ góc nhìn đó, luận điểm trung tâm của bài viết là: Infrastructure Digital Twin được hình thành bởi khả năng liên kết một tài sản thật với định danh, dữ liệu kỹ thuật, trạng thái theo thời gian và quy trình vòng đời; độ chi tiết của mô hình 3D chỉ là một thành phần trong liên kết ấy.

Khi hình học cần được đặt vào ngữ cảnh vận hành

Một mô hình cầu có thể cho biết vị trí, hình dạng nhịp cầu và các cấu kiện chính. Những thông tin đó có giá trị cho việc quan sát, đo đạc không gian hoặc làm nền cho mô phỏng. Thế nhưng, người quản lý tài sản thường cần thêm những câu trả lời khác: lần kiểm tra gần nhất diễn ra khi nào, cấu kiện nào được kiểm tra, ảnh hiện trường gắn với vị trí nào, phát hiện đã được xử lý chưa và lịch sử sửa chữa của tài sản ra sao.

Hình 1. Mô hình 3D mô tả tài sản trong không gian; dữ liệu vận hành bổ sung trạng thái, bằng chứng và lịch sử xử lý. Sơ đồ do MH&T thiết kế.

Vì vậy, việc đưa một mô hình hạ tầng lên nền tảng 3D chưa tự động tạo ra một Infrastructure Digital Twin. Giá trị vận hành chỉ xuất hiện khi hệ thống có thể nối geometry với đúng asset, nối asset với dữ liệu mới theo thời gian, đồng thời nối các kết quả phân tích với một quy trình xử lý cụ thể. Khi thiếu những mối nối ấy, mô hình chủ yếu dừng ở vai trò hiển thị và khó trở thành một hồ sơ sống của tài sản.

Điểm này cũng giúp phân biệt Digital Twin với một kho dữ liệu được tập hợp cơ học. Một hệ thống có thể chứa mô hình, ảnh, cảm biến và tài liệu, nhưng nếu các đối tượng không có định danh thống nhất, dữ liệu không có timestamp hoặc không biết bản ghi nào thuộc phiên bản nào của tài sản, việc tích hợp mới chỉ dừng ở mức “đặt dữ liệu cạnh nhau”. Infrastructure Digital Twin đòi hỏi mức liên kết có thể truy vấn, kiểm tra và phục vụ một hành động vận hành.

Những lớp dữ liệu cấu thành hệ thống

Không có một cấu trúc duy nhất phù hợp cho mọi loại hạ tầng. Tuy nhiên, khi phân tích một asset cụ thể, có thể bắt đầu bằng bốn lớp dữ liệu có quan hệ chặt chẽ với nhau. Sơ đồ dưới đây là cách MH&T tổng hợp để diễn giải kiến trúc thông tin; đây không phải một mô hình chuẩn bắt buộc.

Hình 2. Bốn lớp dữ liệu được quy tụ quanh cùng một Bridge Asset. Sơ đồ do MH&T tự thiết kế.

Định danh và ngữ cảnh không gian

Lớp đầu tiên trả lời câu hỏi tài sản là gì và đang ở đâu. Nó có thể bao gồm asset ID, vị trí, hệ tọa độ, khu vực quản lý, quan hệ với tuyến hoặc mạng lưới, cũng như cấu trúc phân cấp giữa tài sản tổng thể và các cấu kiện thành phần.

Đây là lớp thường bị đánh giá thấp vì không tạo ra hình ảnh trực quan. Tuy nhiên, nếu thiếu một định danh ổn định, hệ thống không có điểm neo để liên kết mô hình 3D với ảnh kiểm tra, cảm biến, hồ sơ sửa chữa hoặc work order. Nếu thiếu thông tin CRS và quy tắc định vị, dữ liệu có thể hiển thị đúng trong một phần mềm nhưng bị lệch khi kết hợp với bản đồ, point cloud hoặc hệ thống GIS khác.

Trong các hệ thống hạ tầng, “vị trí” vượt ra ngoài một cặp tọa độ. Một cấu kiện có thể cần được xác định theo tuyến, lý trình, nhịp cầu, cao độ, phía công trình hoặc quan hệ với một asset cha. Vì vậy, ngữ cảnh không gian cần được thiết kế theo cách mà nghiệp vụ kiểm tra và bảo trì thực sự sử dụng.

Dữ liệu kỹ thuật và hình học

Lớp thứ hai mô tả hình dạng và đặc tính kỹ thuật của tài sản. Nó có thể bao gồm geometry, cấu kiện, vật liệu, kích thước, thiết kế, as-built model, dữ liệu khảo sát hoặc các thuộc tính kỹ thuật được quản lý trong BIM và GIS.

Mô hình 3D ở lớp này không nên được hiểu như một bản sao tuyệt đối của tài sản. Mỗi representation được tạo ra cho một mục tiêu, một thời điểm và một mức độ chính xác nhất định. Mô hình phục vụ quan sát tổng thể có thể không đủ cho kiểm tra cấu kiện; ngược lại, dữ liệu quá chi tiết có thể làm tăng chi phí lưu trữ, trao đổi và xử lý mà không tạo thêm giá trị cho use case hiện tại.

Điều cần quản lý là quan hệ giữa geometry và đối tượng nghiệp vụ. Một mặt cầu, cột trụ hoặc đoạn lan can không phải một mesh đơn thuần; chúng cần được nhận diện như các phần của tài sản, có thể được truy vấn, kiểm tra và gắn với dữ liệu khác. Khi đó, hình học trở thành một cổng truy cập trực quan vào asset information thay vì tồn tại như một lớp hiển thị độc lập.

Trạng thái và dữ liệu theo thời gian

Lớp thứ ba mô tả tài sản đang thay đổi như thế nào. Dữ liệu có thể đến từ đợt kiểm tra định kỳ, cảm biến, ảnh drone, biên bản hiện trường, hệ thống cảnh báo hoặc kết quả phân tích.

Ở đây, timestamp có vai trò đặc biệt quan trọng. Cùng một cấu kiện có thể xuất hiện trong nhiều bản ghi với các trạng thái khác nhau ở những thời điểm khác nhau. Vì thế, hệ thống cần phân biệt dữ liệu hiện tại, dữ liệu lịch sử và dữ liệu dự báo; đồng thời phải biết bản ghi nào là quan sát trực tiếp, bản ghi nào là kết quả suy luận hoặc kết quả do người dùng xác nhận.

Không phải mọi Infrastructure Digital Twin đều cần dữ liệu realtime. Một cây cầu có thể được cập nhật theo chu kỳ kiểm tra, trong khi một hệ thống điều phối giao thông hoặc cảnh báo an toàn có thể yêu cầu độ trễ thấp hơn. Yêu cầu đúng không phải là gắn nhãn “realtime” cho mọi hệ thống, mà là xác định rõ tần suất cập nhật, độ trễ chấp nhận được và ý nghĩa của trạng thái trong từng use case.

Dữ liệu vòng đời và quy trình

Lớp thứ tư đưa dữ liệu vào hoạt động quản lý. Nó bao gồm kế hoạch kiểm tra, yêu cầu sửa chữa, work order, hồ sơ nghiệm thu, phê duyệt, tài liệu kỹ thuật, trách nhiệm của các bên và lịch sử thay đổi.

Một cảnh báo chỉ thực sự hữu ích khi nó có thể dẫn tới một hành động được xác định: tạo yêu cầu kiểm tra, phân công người xử lý, đặt thời hạn, ghi nhận kết quả và cập nhật trạng thái. Nếu hệ thống chỉ hiển thị cảnh báo nhưng không lưu được quyết định và bằng chứng xử lý, nó vẫn chưa tạo thành một vòng đời thông tin hoàn chỉnh.

Cách tiếp cận này tương thích với tinh thần của ISO 19650-1, trong đó quản lý thông tin bao gồm trao đổi, ghi nhận, phiên bản hóa và tổ chức thông tin cho toàn bộ vòng đời của built asset. Khi đi sâu vào quá trình trao đổi, ISO 19650-4:2022 tập trung vào quy trình và tiêu chí giúp kiểm soát chất lượng của thông tin được trao đổi trong các giai đoạn bàn giao và vận hành.

Từ dữ liệu tĩnh đến mức độ đồng bộ

Một mô hình và một bộ hồ sơ chỉ trở thành nền tảng vận hành khi hệ thống xác định được dữ liệu nào được cập nhật, cập nhật bằng cách nào và trạng thái mới có tác động gì đến quy trình tiếp theo. Đây là lý do mức độ đồng bộ cần được thiết kế theo use case, thay vì mặc định rằng mọi Digital Twin đều phải có kết nối hai chiều và realtime.

Hình 3. Một cách phân loại tham khảo về mức độ kết nối giữa tài sản và biểu diễn số.

Sơ đồ trên được MH&T vẽ lại dựa trên cách phân loại được thảo luận trong OGC Discussion Paper về Urban Digital Twins. Cần nhấn mạnh rằng tài liệu này là Discussion Paper, không phải OGC Standard và không phải yêu cầu bắt buộc cho mọi dự án.

Ở trạng thái Digital Model, hệ thống có biểu diễn số của tài sản nhưng dữ liệu giữa thực thể thật và mô hình chưa được kết nối tự động. Digital Shadow mô tả trường hợp dữ liệu từ tài sản được đưa vào biểu diễn số, còn Autonomous Digital Twin diễn tả mức độ trao đổi hai chiều và khả năng tạo phản hồi trong hệ thống. Đây là một ngôn ngữ tham khảo để thảo luận về data flow và synchronization; nó không nên được dùng như một thang điểm duy nhất để đánh giá mọi nền tảng.

Trong thực tế, mức độ đồng bộ cần được trả lời bằng các câu hỏi cụ thể: dữ liệu nào là nguồn chính, sự kiện nào kích hoạt cập nhật, độ trễ bao nhiêu là phù hợp, ai có quyền xác nhận trạng thái, dữ liệu cũ được giữ lại như thế nào và hệ thống có được phép tự động tác động trở lại tài sản hay chỉ hỗ trợ con người ra quyết định.

Từ dữ liệu hiện trường đến hành động

Khi bốn lớp dữ liệu được liên kết, hệ thống có thể được nhìn như một operational thread. Dòng dữ liệu không kết thúc ở bước hiển thị hoặc phân tích; kết quả cần quay trở lại hồ sơ tài sản để tạo ngữ cảnh cho lần kiểm tra và quyết định tiếp theo.

Hình 4. Dòng dữ liệu từ hiện trường đến quyết định và trạng thái mới của tài sản. Sơ đồ do MH&T thiết kế.

Quy trình trong sơ đồ gồm sáu bước liên kết với nhau. Dữ liệu được thu nhận từ drone, sensor, ảnh hiện trường hoặc hồ sơ; sau đó được chuẩn hóa về format, CRS, timestamp và các quy tắc chất lượng cần thiết. Khi đã chuẩn hóa, dữ liệu được gắn với đúng asset ID, vị trí và cấu kiện. Từ đó, hệ thống mới có cơ sở để phân tích, phát hiện bất thường hoặc so sánh theo thời gian.

Phân tích chỉ tạo ra giá trị vận hành khi dẫn tới một quyết định có trách nhiệm: kiểm tra bổ sung, bảo trì, điều phối hoặc tiếp tục theo dõi. Kết quả của quyết định cần được cập nhật trở lại trạng thái tài sản cùng với phiên bản, thời điểm và lịch sử xử lý. Vòng phản hồi này giúp hệ thống lưu giữ context thay vì chỉ lưu một kết quả rời rạc.

Một ví dụ từ PLATEAU

Một minh họa cụ thể đến từ use case Hệ thống quản lý hạ tầng bằng drone trong chương trình PLATEAU của Bộ Đất đai, Hạ tầng, Giao thông và Du lịch Nhật Bản. Trang use case ghi nhận hệ thống được phát triển cho hoạt động bảo trì, kiểm tra cơ sở hạ tầng đường sắt; trong đó 3D City Model được dùng để xây dựng sổ quản lý tài sản, còn ảnh và video do drone thu thập được liên kết với các đối tượng cần kiểm tra. PLATEAU mô tả use case

Hình 5. Giao diện quản lý cho phép liên kết vị trí/đối tượng kiểm tra với ảnh hiện trường.
(Đây là bản chú thích tiếng Anh do MH&T biên tập lại từ ảnh gốc; tên địa danh trên bản đồ được giữ nguyên)

Ảnh gốc: PLATEAU – UC23-020 verification image.

Theo mô tả kỹ thuật của PLATEAU, hệ thống sử dụng các đối tượng thuộc mô hình giao thông đường sắt và mô hình thiết bị đô thị ở LOD3 làm đối tượng kiểm tra. Ảnh và video được quản lý cùng thông tin vị trí chụp, thời gian chụp và tên nhiệm vụ bay. Hệ thống còn có chức năng hiển thị vị trí chụp trên bản đồ, nhóm ảnh theo đối tượng hoặc vị trí, và liên kết dữ liệu media với các feature tương ứng.

Điểm đáng chú ý nằm ở cơ chế liên kết dữ liệu. CityGML parser được dùng để trích xuất các đối tượng đường sắt và đưa vào cơ sở dữ liệu. Các waypoint trên tuyến bay được gắn với đối tượng gần nhất; sau khi drone hoàn thành nhiệm vụ, metadata của ảnh được đối chiếu với thời gian và thứ tự waypoint để xác định ảnh thuộc về feature nào. Nhờ vậy, ảnh hiện trường vượt khỏi vai trò của một file độc lập và trở thành một phần của hồ sơ tài sản.

Use case này còn cho thấy Digital Twin của hạ tầng có thể mở rộng từ việc lưu trữ kết quả kiểm tra sang hỗ trợ an toàn vận hành. PLATEAU mô tả thêm một route management system sử dụng 3D City Model, thông tin chướng ngại vật và dữ liệu vị trí động của đoàn tàu để đánh giá rủi ro. Trong quá trình tạo tuyến bay, các khu vực có ground risk cao được xem xét; khi tàu tiếp cận, hệ thống có thể cập nhật vùng geofence động và hỗ trợ tạo tuyến tránh an toàn. Đây là ví dụ rõ về việc dữ liệu không gian, dữ liệu tài sản, dữ liệu thời gian và quy trình an toàn cùng tham gia vào một bài toán vận hành.

Những quyết định cần chốt trước khi triển khai

Trước khi lựa chọn nền tảng, định dạng trao đổi hoặc công cụ visualization, dự án cần chốt cách tài sản được nhận diện xuyên suốt hệ thống. Một asset ID chỉ có giá trị khi các hệ thống liên quan cùng hiểu nó, hoặc có một cơ chế mapping rõ ràng giữa các định danh khác nhau. Tiếp theo là chính sách cập nhật, cần xác định sự kiện nào tạo ra phiên bản mới, dữ liệu nào được coi là quan sát, dữ liệu nào là kết quả phân tích, ai xác nhận trạng thái và lịch sử cũ được truy xuất ra sao. Nếu không có chính sách này, hệ thống dễ rơi vào tình trạng dữ liệu mới ghi đè dữ liệu cũ mà không giữ được provenance.

Chất lượng trao đổi cũng cần được xem như một phần của kiến trúc: CRS, đơn vị đo, timestamp, schema, version, quyền truy cập và quy tắc kiểm tra cần được thống nhất trước khi dữ liệu đi vào pipeline. Việc một file có thể mở được trong phần mềm không đồng nghĩa với việc nó đã sẵn sàng để tích hợp vào hệ thống vận hành.

Cuối cùng, cần bắt đầu từ quyết định mà hệ thống phải hỗ trợ: (1) Nếu use case là quản lý ảnh kiểm tra, ưu tiên có thể nằm ở asset identity, vị trí chụp, timestamp và khả năng so sánh theo thời gian; (2) Nếu use case là giám sát an toàn bay, hệ thống cần bổ sung dữ liệu động, quy tắc rủi ro và cơ chế phản hồi phù hợp. Cùng một mô hình 3D có thể được tái sử dụng, nhưng data contract và workflow phía sau sẽ thay đổi theo mục tiêu.

Kết luận

Infrastructure Digital Twin không được xây dựng bằng cách đưa thật nhiều dữ liệu vào một mô hình 3D. Nó được hình thành khi các lớp dữ liệu khác nhau cùng quy tụ quanh một tài sản có định danh rõ ràng, có ngữ cảnh không gian, có trạng thái theo thời gian và có quy trình xử lý trong vòng đời.

Mô hình hình học giúp người dùng nhìn thấy tài sản. Dữ liệu kỹ thuật giúp hiểu cấu trúc. Dữ liệu trạng thái cho biết điều gì đang xảy ra. Còn dữ liệu vòng đời biến thông tin thành một chuỗi hành động có thể kiểm soát và truy nguyên.

Vì vậy, khi bắt đầu một dự án Infrastructure Digital Twin, câu hỏi hiệu quả hơn không phải là nên dựng mô hình chi tiết đến đâu trước tiên, mà là hệ thống cần hỗ trợ quyết định nào, dữ liệu nào chứng minh quyết định đó và trạng thái mới sẽ được cập nhật trở lại tài sản như thế nào. Khi các mối liên kết ấy được thiết kế rõ, mô hình 3D mới thực sự trở thành một thành phần có giá trị trong kiến trúc vận hành hạ tầng.

—

Nguồn tham khảo chính

• ISO/IEC 30173:2023 — Digital twin: Concepts and terminology
• ISO/IEC 30188:2026 — Digital twin: Reference architecture
• ISO 19650-1:2018 — Information management using BIM
• ISO 19650-4:2022 — Information exchange
• OGC Discussion Paper 24-025 — Urban Digital Twins
• PLATEAU — Hệ thống quản lý hạ tầng bằng drone