Digital Twins of Buildings
建築物的數位孿生
數位孿生醫院建築：透過持續生命週期整合，進行的案例性案例研究
本篇摘要
醫院建築通常包含複雜的設施系統，和特殊的醫療設備、嚴格的安全要求和業務系統。BIM 等傳統方法，對建築狀態和大數據量的即時更新能力越來越弱。
本文透過提出技術和管理上的創新 —— 一種基於數位孿生（DT）概念，和總承包商「早期運動」概念的「生命週期持續整合」方法，報導了中國一家大型醫院的成功項目案例。
該案例實現了從設計、施工、前期運維到維運階段，20 多個管理系統的靜態數據和動態數據的持續、有計劃的整合。隨後，開發了具有即時可視化管理和人工智慧診斷模組的 DT 軟體系統，並佈署在新建的 DT 控制中心。
管理者可以透過可視化管理，掌握整個醫院的詳細狀況，即時接收從數位化大樓，自動傳回現實的設施診斷，和操作建議。該案例在醫院穩定運行了一年多，透過降低能耗、避免設施故障、減少維修次數、提高日常維護工作質量，達到了預期的效果。
1. 簡介
隨著新建建築項目的數量，或複雜性不斷增加，日常管理效率和營運安全問題，變得比以往任何時候都更加重要。困難來自靜態和動態因素：大型公共建築中，通常有數百個房間，每個房間都有不同的使用要求。
如何以精確的方式進行管理，是一個具有挑戰性的難題。此外，還嵌入了冷/熱源、給排水、變配電、照明、弱電、通風/空調、電梯系統等眾多機電系統。即使對於專業工人來說，維護和修理這些系統也是很乏味的。
另一個挑戰是管理房屋內的人員 —— 這是最不可預測的因素，例如訪客行為，或不同任務的員工協作。
醫院建築不僅具有公共建築的共性難點，而且具有醫療行業獨有的特點。醫院內設有醫用氣體系統、氣動物流系統、醫用污水系統等特殊系統，按照他們的國家標準，醫院空間嚴格劃分為公共、醫學、臨床、外科等特殊技術領域。
這些領域對維運品質，都有著高標準的要求 —— 溫度、濕度、污水、排氣、換氣。在日常活動中，所有患者、家屬、醫生、行政人員，都可能造成密集複雜的交叉路口。因此，安全要求似乎比普通建築物更為重要。
另一個特點是，中國醫院的很多營運任務都委託給了外包團隊，這帶來了額外的品質不確定性，和管理問題。
在大型醫院建築管理問題的所有解決方案中，BIM（建築資訊模式）是最有前途，和最成熟的理論之一。BIM 提供了一個帶有 3D 建築實體的圖形平台，供設施管理人員在統一的軟體介面中，檢索、分析和處理各種數據 。一些成功案例，報導了基於 BIM 的設施管理、能源管理和安全管理 。BIM 平台還與電腦維護管理系統 (CMMS) 很好地協調，後者解決了日常維護的基本活動記錄。
儘管 BIM 取得了成就，但建築營運管理中，三個主要的問題仍未解決，尤其是大型醫院建築：
(1) 現有的軟體平台缺乏對現實世界建築的不斷更新的顯示 。例如，醫院門口突然人流很危險，應立即報告。現有平台上的大多數建築數據，都是預先導入的，然後保持不變。管理人員無法按照自己的意願，檢查真正的最新狀態。
(2)從各種來源收集數位數據，仍然存在困難。在醫院中，大約有 20 個系統是潛在的動態數據源。每個系統都有獨特的硬體設備、接口和數據格式。此外，感測器數據的累積速度非常快。這種大數據量的數據轉換，其策略和儲存工作也需要改。
(3) 典型的在用管理軟體，如 BIM 平台，主要以 3D 模式瀏覽，或檢查業務數據為主，而不是海量分析。如果使用單獨的離線數據庫分析，來填補這個空白，那麼即時回饋機制就會很差。因此，需要以即時的決策，建議的形式進行高級數據分析工作。
為瞭解決這些問題，製造業借鑒了一個相對較新的概念 —— 數位孿生（DT）。儘管製造 DT 已經發展了大約十年，但它在建築行業中遠沒有那麼受歡迎，只有少數案例與 AEC 和 O&M 階段相關 。
建立 DT 時，目的在描述虛擬模式和真實產品之間，即時的資訊映射。下面以某醫院大樓為例。數位孿生的現實世界，部分是指每天都包含所有醫生、患者、藥劑師和醫療設備的可觸控建構塊。該醫院建築的「數位影子」是數位孿生的虛擬部分，自動接收來自真實醫院的數據流。
借助與數位陰影相關聯的可視化管理功能和診斷算法，醫院管理人員能夠監控當前的營運狀態，並將優化決策，回饋給現實世界的醫院。透過提供從虛擬模式，到真實建築實體的鏈接方法，DT 的上述特徵，自然地解決了第一個問題。
一項調查顯示，超過一半已申報的，關於製造的 DT 研究論文，僅達到了整合的數位陰影水準，建築行業的情況更加慘淡。很明顯，類似的研究，通常利用相同的捷徑，將 BIM 系統的現有功能模組，直接升級為數位孿生系統。雖然這條捷徑為建築行業快速接受數位孿生概念，帶來了極大的便利，但 BIM 似乎更接近於單一的數位影子，因此只能部分實現數位孿生。
事實上，DT 可以更強大，實現整個生命週期的鏡像，透過基於當前狀態的鏡像，即時提出優化建議，來支持決策。DT 改進了建築物生命週期，服務過程中的常用功能，如即時監控、能耗預測、故障預測、操作指導等。在本文中，DT 的現實世界部分，比現有的 BIM 系統更受重視。
在建立 DT 時，智慧設備整合始終是關鍵，但困難的一步。現代智慧感測器，將透過生成極其龐大的數據，來產生有價值的見解。本文的主要貢獻之一，是設備數據在整個生命週期中，持續的整合和操作方法，它解決了第二個問題。
此外，為了分析這些數據，並將有用資訊反饋回現實，診斷功能應緊密整合到 DT 管理系統中。 DT 的框架中，自然引入了人工智慧（AI），在數據整合後進行進一步分析，包括事件辨識、故障診斷和自動化決策。
分析通常涉及，強大的機器學習模式或深度神經網路。例如，一些論文報導了大型建築中，用於行動/疏散路徑管理的空間模式，和引導系統。自然語言處理（NLP）和聚類算法，被用來從日常維修中發現故障模式。
基於收集到的最新資訊流，由於有保證的同步，分析結果將非常有用。在本文中，智慧診斷引擎，嵌入到 DT 軟體系統的核心中，成功解決了第 4 節中的第三個問題。
針對本文中的典型案例，提出了以「生命週期連續整合」概念，建構的 DT 醫院大樓。在第 2 節中，介紹了持續生命週期整合方法。在第 3 節中，開發了一個具體的 DT 管理系統。第 4 節介紹了 DT 醫院大樓的詳細現場應用，最後給出討論和結論。
2. 案例背景和方法論
2.1.引入 DT 之前的案例背景
同濟大學附屬上海東方醫院（簡稱東方醫院），是位於華東上海陸家嘴商業區的甲級綜合醫院。這個案例是集醫療、教學、科研、急救、預防、保健為一體的新型臨床中心大樓。
與舊的臨床大樓相比，這座新大樓主要集中於重大公共醫療保障，和高水準醫療服務。大樓地上 24 層，地下 2 層，床位 500張，總建築面積約 83000 平方米。
在新建臨床大樓之前，東院的機電設備，涉及單獨工作的複雜系統，包括燃氣系統、污水處理系統和醫療設備系統等，專業醫療系統。目前使用的 BA、維護、空間管理系統，是相互獨立的，自然不能根據醫療服務需求，整合一個統一的系統。
東院中高層管理人員，不便於即時決策，維運效率低下。另外，醫院大樓需要每天 24 小時不間斷運行；因此，維運管理部將承受巨大的壓力。傳統的手動簿記管理策略，已經過時且不直接，因為幾乎不可能監控和分析，來自眾多來源的大型數據集。
2.2. 創新
本案例研究中，採用的主要技術創新稱為「連續生命週期整合方法」，它是指在整個生命週期中，逐步、準時地引導適當內容，整合的詳細時間表。建築項目的時間表通常涉及 AEC（建築、工程和施工）和 O&M（營運和維護）活動。
因此，整個生命週期可以分為幾個階段，通常是設計階段、施工階段、維運階段等。其中，維運階段尤為重要，因為它佔據了建築物的大部分生命週期，和預算成本。但是，維運不能脫離AEC。主要的靜態資訊，如幾何形狀、設施附屬資訊、空間劃分、電氣系統邏輯等，在設計階段確定。用於收集動態運行數據的智慧硬體設備，在施工階段配備或保存。
總包「早動」，是管理實踐的又一創新，保證了 DT 數據的一致性。數位模式與現實世界，隨時保持一致，這就是「孿生」一詞的確切含義，是本案採用的 DT 的一個微妙特徵。
一致性在建築物的整個生命週期中都很重要，尤其是在 O&M 階段。例如，設施管理中的一致性，指的是靜態資訊和動態狀態。如果數位模式，未能根據施工變化進行更新，工人將無法找到報警的空調機組。
如果監控信號與實際情況不符，工人可能會誤操作用電設備，造成意想不到的後果。傳統上，總承包商只能控制施工階段。
在本文中，總承包商的 DT 顧問團隊，參與了早期的規劃和設計階段，直接向業主和設計師，提交了有關數據介面的請求。他們還收集了重要的設計元數據，例如設施和感測器位置的序列代碼。然後在施工中，總包商帶頭協調各系統供應商的合同，建構智慧設備網路，跟蹤點資訊變化等。透過項目整合交付（提前行動），總包商保證所有的DT信息在整個建築生命週期中，保持一致，不限於施工階段。
2.3. 持續生命週期整合的步驟
圖 1 顯示了為醫院建築建立 DT 的主要步驟，從現實世界的醫院開始，以完整的 DT 結束。
第一步是透過幾何建模，將醫院數位化。幾何建模主要是從設計階段，開始使用 CAD 圖紙進行，而透過雷射掃描，或攝影測量的 3D 點雲方法，在複雜的機械室中進行了測試。之後，BIM的建模過程，是主要的整合步驟之一。通常，拆分靜態本體數據，和動態生成的資訊，對於確保系統固有數據安全性，並適應適當的儲存策略是必要的。
因此，首先構建了一個基本的 BIM，整合了靜態模型和本體資訊。透過業務系統和感測器設備監控流程，動態 BIM 或數位影子出現了。應在監控數據到來後，立即添加具有預定義知識，和 AI 模式的分析引擎。
最後，現場調查的對象映射過程，對於鏈接到現實世界的醫院很重要。所有功能模組和診斷建議，都應根據正確的對象映射發送回現實世界的醫院大樓。
2.4. 整合詳細內容
在正確的時間做正確的事情，是規劃 DT 模式時的核心思想。從設計階段開始，在生命週期的不同階段，所有內容（指靜態數據、動態資訊和相應負責人，可能的診斷模式）都應按計劃進行整合。 表 1 給出了一些整合內容的例子。從一致的觀點來看，一個階段的關鍵資訊，必須是從前幾個階段接收到的，而不是任意回憶和覆蓋的（一些例子在表 1 中標記為三角形）。 這將確保任何時候，只有一份基本數據，同時節省大量不必要的建模成本。
3. DT 系統開發
基於持續整合方法，開發了一個跨桌面客戶端、智慧手機應用 app，和平板電腦應用 app 的統一 DT 系統。圖2 展示了以可視化管理為中心，系統主要的組件及其運行邏輯。
首先，處理來自真實醫院和數位陰影的原始數據，其中一些透過 Apache Kafka 引擎，作為高密度流數據（步驟 1 和 2）進行處理。然後，Apache Flink 引擎和定時提取 - 轉換 - 加載 (ETL) 兩種大數據方法，都將建築狀態的分析數據，不斷轉換成預定義的數據倉庫 —— 一種適合 AI 訓練的整潔格式（步驟 3）。
數據倉庫首先為 AI 模式，提供適當的訓練數據。經過適當的訓練，這些 AI 模式形成了一個診斷引擎，並經常從數據倉庫中，接收診斷數據（步驟4）。一旦引擎檢測到問題，應立即提示回到可視化管理介面（步驟 5）。
最後，針對數位孿生醫院建設，給出了一些有針對性的命令或建議（步驟6）。如果任何診斷建議被確認為不正確，則將其作為負面訓練集發送回引擎。人工智慧算法應該做相應的調整（步驟 7）。以下部分介紹了系統開發的關鍵方面。
3.1.設計和施工整合過程中的數據處理
DT 的數據整合持續了大約三年。雖然大部分動態數據，是在維運階段收集的，但設計和施工階段花費的時間最多。為了確保設計和施工數據多年來保持一致，並仍然適合 DT 平台的介面，顧問組出版了一本相當厚的室內數據標準手冊。
項目部的工作人員，可以以標準格式收集各種數據，建模工作人員可以以統一的方式，製作易於整合的數位模式。
在靜態建模期間，幾何數據隨著不斷整合的模式文件，而變得越來越大，尤其是 HVAC 元素。在建構階段結束時，主要幾何數據達到 15 GB，這對於 GPU 來說顯然太重了。執行了一系列提出的原始輕量級算法，包括合併鏈接管段、消除次要細節，和網格簡化。他們將文件大小、三角形面數和元素數減少到 20% 以下（如圖 3 所示）。
3.2. 動態操作系統整合
在 DT 平台中，整合了動態系統的六個方面作為數據源。表 2 列出了連接和數據處理框架時，使用的相應協議。由於預算限制，大數據服務由免費的開源引擎提供支持。Kafka 和 Flink 等大數據框架，能夠轉換從眾多感測器連續發送的快速而密集的流數據。這兩種框架已被產品行業廣泛採用多年，並且被認為足夠穩定。至於維修業務系統，或軍備系統，發送的記錄要少得多。因此，一些帶有 Pandas 的 Python ETL 腳本，由調度調度程序 APScheduler 管理，會更簡潔地完成工作。
在東院，BA 的硬體網路，包括電梯系統等 13 個子系統的 1900 多個智慧感測器，兩個能源監控系統（供電和供水）的約 230 個數位儀表，以及三個醫用氣體系統的 100 個感測器。
由於總承包商提前介入，已經保證了所有感測器的位置，和序列號一致，動態數據可以自動整合到正確對應的 DT 中。這些設備每天生成大約 200 萬條記錄，總共生成超過 10 TB 的記錄數據。儘管數量龐大，但數據格式相對簡單。在穩定網路的幫助下，持續整合工作順利。唯一的問題，是每三個月備份一次數據庫。相比之下，從維修系統、醫療系統或門診資訊系統中，提取的記錄包含相當複雜的屬性，因此開發靈活的 ETL 腳本要困難得多。
還考慮了安全監控影像，和患者就診記錄等機密數據的安全問題。根據軟體開發合同，DT 系統只能訪問醫院防火牆內的私有雲 HTTP API。這在開發階段引起了巨大的困惑。
因此，安全監控系統和門診資訊，或多或少是最後整合的數據。最後，在 DT 控制中心，和東方醫院資訊部佈署了私有雲，用於儲存機密業務數據。
3.3. 混合現實 (MR) 輔助對象映射：從數位陰影到 DT
在系統開發的數據階段，從真實醫院，到數位陰影的正確對象映射非常重要。如果數位部分中建築元素的位置、大小、屬性或關係，與現實世界的部分不一致，工作人員會感到困惑，基於錯誤數據的相應診斷，將被認為是無用的。現場調查在整個生命週期中進行，但在運維前階段進行的頻率更高。
為了幫助檢查對象映射，在 iPad 平板電腦上，開發了一個 MR 應用 app。MR 技術可以將虛擬場景，無縫疊加在真實的實體上，並在專用光學設備中顯示。如圖4 所示，透過精確的位置匹配，關鍵房間的數位模式形狀，與頭盔眼鏡內的真實場景一起顯示。
從 MR 的角度來看，任何位置差異都非常明顯，也支持即時測量。可以透過應用 app 調用輸入的屬性數據，例如材料、類型或工廠資訊，然後與機器標籤進行比較。那些必要的幾何和屬性數據，是從數位陰影部分自動提取的。 MR 應用程序有助於正確建模 DT。
3.4. 診斷引擎和大數據後端
診斷的核心算法，是透過 Python 語言開發的。AI 模式是由流行的框架實現的，例如 Keras 的 TensorFlow wrapping 和 Pytorch 深度學習。第 4 節介紹了診斷引擎的詳細應用。
大數據服務，在來自感測器設備的流數據上表現良好。 具體來說，首先，一個 Java 守護進程在後台工作，為 Kafka 生產者「主題」收集不同的數據源。然後 Kafka 管理和發送，原始數據作為流。另一方面，Flink 不斷消耗每個流，根據數據倉庫轉換為標準格式。DT 系統中的大數據服務設法隱藏了低級操作，例如保持一致性、避免重複計算、數據保存和備份。 這簡化了系統開發 API。
4. 現場使用
DT 醫院建築管理平台，在施工交付前成功開發。然後它被佈署在東醫院內。醫院手術部進行了人員重組，安排了約 10 名成員，從傳統崗位轉為 DT 管理崗位。此外，DT 產品團隊的顧問組，負責培訓現場工人和軟體使用者。到目前為止，所有 DT 應用已經穩定運行了大約 15 個月。
4.1. DT 螢幕及控制中心
在設計階段，東方醫院的執行管理者，就預見到在新的臨床大樓中預留 200 平方米的區域，以供更高級的 BA 使用。然後，在B1層核心區域，緊鄰暖通空調和電機機房的區域，建立了 DT 控制中心，如圖5 所示。控制中心配備了完善的工作條件，以確保穩健運行，包括伺服器機房、內網、 UPS（不間斷電源）、獨立辦公區、臉部辨識接入、通信線路和環境控制。
DT控制中心擁有更高的權限，和完整的數據訪問權限，不僅是建築管理辦公室的一個分支，而且已經成為能夠協調整個醫院日常活動的中心大腦。
DT 系統的主要顯示設備，是位於指揮台前的大型整合螢幕（高度和寬度）。對於員工使用，3個圖文站支持 DT 軟體平台，1 個 BA 監控螢幕，2 台伺服器終端電腦，以及多台普通辦公電腦。
4.2. 醫院可視化管理
4.2.1.醫院概覽螢幕
每天步入控制中心時，默認螢幕會顯示醫院概覽的大首頁。左邊部分是一個完整的學科 3D 模式，支持視覺轉換、自由漫遊、元素選擇和設施系統之間的切換。右側列出了現場管理人員應檢查的最關鍵資訊，如感測器報警、機器故障風險預測、未處理的維修請求、客流趨勢、臨床區域監控影像等。
4.2.2. 空間管理
根據醫院的要求，建立了房間和大廳的空間資訊，支持 3D 視圖和列表視圖中的房間分配、統計分析等功能。所有空間資訊都保留在此處（圖 6），作為下一節能量診斷的背景知識。每個空間的二維碼或藍牙信標，生成為室內定位標籤，支持維修人員自動定位。還給出了一些空間使用的統計分析。
計算了各醫療科室的空間佔用和利用率，並結合醫院的營運情況，分析了空間利用效率。這有助於房間的規劃和空間的優化。
4.2.3. 能源管理
該功能持續監控醫院建築的能源消耗，包括水和電的消耗。用水量分為廚房用水、衛生間用水、醫療用水。用電量分為照明和開關、電力系統、空調和特殊用電量等標準類別。能源消耗的絕對量，以折線圖顯示，而關聯的相對比率則以類別列出。在 DT 的圖形平台中，偏紅的顏色強調了相對密集的能源使用（圖 7）。
4.2.4. 設施管理
顯示了每個系統的主要設施資訊、邏輯結構和實體結構。透過與 BA 的無縫對接，在 3D 模式視圖中，顯示每台設備的運行狀態和報警狀態。根據第 2 節的整合內容，動態設施數據流涵蓋暖通空調、給排水、配電等系統。
系統以列表和趨勢圖的形式，展示各監控點的歷史監控數據，方便後台管理人員直，接掌握所有關鍵機器的運行情況，並對其性能進行評估。以空調系統為例。已經建立了空調機組的高層次詳細監測模式（圖8）。詳細模式顯示過濾器狀態、送風溫濕度、CO2/CO 濃度等 12 個監測點。設置進風溫濕度閾值、CO2、CO濃度監測值後，如果檢測到即時數據超過閾值，則以不同顏色提示警告或報警（圖左部分） 8)。
當工人需要瞭解，上游或下游設備的影響時，相應的維修工人將在他們的智慧手機上收到工作分配（在設施系統中，上游/下游設備意味著空氣或水，流入/流出當前設備的位置。例如，如果水流經 A ⟶ B ⟶ C，我們說 A 是 B 的上游設備，C 是 B 的下游設備），它們從 DT 控制中心獲取連接資訊。有關管道流邏輯和控制區域的資訊，已經整合到預運維階段。這些額外的知識，極大地幫助了對設施故障，做出合理和即時的反應。
例如，一個警報空氣處理裝置 (AHU) 的影響區域，用行動箭頭顯示，並發送到現場維修團隊（圖 8 的右側部分）。一些工人負責發現，沿空氣管道的潛在異常行為。其他工人去打開受影響房間的窗戶，以便在 AHU 維修期間，進行更好的空氣交換。
另一個亮點，是電梯系統監控。所有 18 部電梯的位置信號，每 5 秒發送一次。這樣，圖形系統為管理者展示了即時動畫。當觀察到一部繁忙的電梯時，DT 控制中心，會連接到附近的揚聲器，並引導等待的乘客，到另一部可用的電梯。
4.2.5. 維修保養子系統
該子系統是 DT 系統的服務窗口，方便各級使用者方便地發起和處理，維修請求或維護計劃。其中包括緊急維修啟動、接收、任務分配、工單生成、維護處理和維護日曆。維修方案支持，根據不同臨床科室或不同機械要求定制不同的應急維修、日常維修、按需維修流程，支持根據實際情況調整任務流程。
大樓內的普通使用者，可以透過行動應用 app，發起維修請求，提交問題的多媒體描述和簡訊。應用 app 支持文本、照片、錄音和影像。系統還收集，來自自動故障診斷模組的請求。手動和自動生成的任務，都分配給了醫院大樓中最近的工作人員。
採用 DT 模式輔助定位斷層空間位置，分析判斷斷層影響範圍或關鍵點。這提高了設備維護和應急維修的效率。
4.2.6. 安全子系統
該平台透過與醫院的影像監控平台對接，整合了所有的安控攝影機。如圖9 所示，系統包括即時監控、軌跡監控、重點區域監控。透過點擊 3D 建築模式上的攝影機圖標，直接調用即時影像，實現 360 度無縫目標追蹤。重要客人和危險人物的高級追蹤功能也在運行。
「醫療糾紛奸商」問題，嚴重威脅醫療秩序。在安全子系統的幫助下，一旦醫療糾紛人員侵入任何安控攝影機的範圍，就會根據他們的照片檔案，立即觸發臉部辨識警告。DT 控制中心會直接通知相應樓層的保全。
4.2.7. 客流管理
透過每層所有入口處的人臉辨識攝影機，實現了即時的客流管理。 ETL 每五分鐘計算一次流量總和。一旦平均流量強度（定義為流入/流出流量，佔當前入口最大容積的百分比）超過閾值 0.25，就會向控制中心發送警告。保全經理也會在行動應用 app 上收到提示。車牌辨識被嵌入到主入口攝影機中。記錄每輛車的車號、進入時間、離開時間和停車車道。管理人員可以查看照片和累計車流量。
4.3.醫院優化智慧診斷
4.3.1.異常用電檢測
醫院裡的各種電路顯示出不同的使用規律。例如，門診候診區的照明白天用電少，晚上用電多，晚上幾乎為零，而電力系統的用電在早上較高，之後保持較低。 230 個智慧電錶的監測數據，透過 k-means 聚類算法自動分類。這種方法是無監督和全自動的，因此非常適合尋找未知模式。得到 7 種正常用電行為，及對應的電錶組別。
DT 系統持續監控用電量，並辨識任何超出或低於，相應正常行為 20% 閾值的異常電錶。大螢幕顯示異常電路，透過手機 APP 提示檢查任務（圖10左）。對於經確認的異常高耗時間，工人必須找到相關設施，並停止不必要的能源消耗。對於確認的異常低耗，應檢查是否有任何機器停止工作。
4.3.2. 空氣處理機組故障預測
原始數據來自 BA 監測數據和維修記錄的結合。具體來說，在AHU 確認真正的故障報警後，取出最近 24 小時的監測數據，取出具體故障類型作為一對訓練集。為了從此類時間序列數據中學習預測規則，我們使用了長期和短期記憶 (LSTM) 網。這種網路具有靈活的記憶能力，隨時間的變化，可以追蹤異常數據。
LSTM 預測模式，總共涵蓋了過熱和過冷、低氣流、過濾器堵塞等 10 種故障。另一方面，數據倉庫不斷輸入，所有 AHU 的最新 24 小時監控數據。如果預測的故障概率大於 0.6，系統和移動應用 app，將發出預警（圖 10 的右側部分）。隨著實際失敗次數的增加，預測模式不斷接收新的訓練數據，從而提高其準確性。
4.3.3. 頻繁維修模式辨識
維修服務系統的維護請求，以中文自然語言記錄。每個月大約有 400 條記錄，往往用一兩句話，來描述維修地點和原因，因此無法直接分析這些句子背後的隱藏規律。與英語不同，分詞是中文語言分析中，非常重要的預處理。因此，採用了一種開源的中文 NLP 算法。提取了維修樓層、部門、房間和損壞類型等資訊。系統會自動將類似的維修，作為維修模式放在同一組中。
這些模式附在月報告中。當管理者發現有趣的模式時，他們會做出一些優化決策。例如，12月份重症監護病房（ICU）的兩個房間的洗臉盆水龍頭，已經損壞了4次（詳細列於表3）。經過檢查，發現都是同一個品牌，所以都換了。儘管增加了成本，但它確保了正常的醫療活動，並節省了數十小時的維護時間。
4.3.4. 低品質維護檢查
一些外包公司，承包了醫院一些主要設施單位的維修工作。過去，只有簡單的定性評價方法，來判斷這些外包公司的業務品質。使用 DT 系統管理維修工作後，可以自動分析每台設備的維修記錄，及其故障維修記錄。
採用假設檢驗法的 t 檢驗，如果維修後維修量序列的均值，大於維修前且有統計學意義，則認為品質低。表 4 列出了兩種維修的故障編號。在三週的範圍內執行了 t 檢驗。 AHU 維修團隊被認為是低品質的，因為假設檢驗的值小於 0.1，表明即使在維修後，發生的故障也明顯更多。雖然電梯的維修工作被認為是正常的。
5. 討論與結論
東院示範性 DT 項目，已運行一年多，並考慮達到預期性能：
(1) 一項調查顯示，與舊臨床大樓相比，管理滿意度提高了 10%。
(2) 綜合能耗預計每年可節約1%左右。
(3) DT診斷避免了 10% 以上的設施故障和請求維修。雖然示範案例是在中國上海進行的，但「持續生命週期整合」的概念，並不限於國家或地區。由於共同的管理要求和相似的電力系統，本案例將為世界其他現代醫院提供一些解決問題的參考。
綜上所述，根據總承包商提出的持續生命週期整合和早期行動的概念，成功建立了一個全功能的DT。該案例主要體現在
（1）全生命週期海量數據的持續整合。從設計、施工、預維運階段，一直到維運階段，TB 級的靜態信息和動態數據被管理集成為一個統一的 DT 系統，包括建築幾何模式、附屬屬性資訊、常用 BA 系統、維修和維護系統、安全管理系統，和醫院的特殊業務系統。
整個生命週期的持續整合過程，和總承包商的早期行動，都在本文中被證明是有效的。這種方法可以直接用於類似醫院項目，也可以被其他復雜的公共建築部分模仿。
(2) 即時可視化管理 —— 管理者可以透過可視化管理，掌握整個醫院的詳細狀態，遠比人工工作效率高。大數據服務被開發為後端，以一致地顯示高密度數據流。現在，醫院大樓的即時狀態，顯示在現代化的控制中心，作為指導日常管理活動的操作大腦。憑藉這種實時機制，DT 比傳統 BIM 技術顯示出更大的潛力，這將有助於專業人士從 BIM 升級到 DT。
(3)智慧 DT 診斷功能 —— 專業 AI 模式組裝為診斷引擎，與可視化管理功能無縫對接。海量動態綜合數據，支持即時的設施診斷和運行建議，自動回傳現實。這個示例性案例展示了人工智慧和現代數據分析技能，在 DT 應用中的潛在優勢。事實證明，智慧診斷模組最有價值，因此應謹慎開發。
在示範案例的實施過程中，顧問組發現，DT 仍然不能完全適應建築項目的需要。至少，短缺或困惑的三個方面需要進一步研究：
(1) BA 系統或醫療系統過於專業，DT 平台無法直接控制。因此，現有的 DT 並沒有實現故障設備的自動控制。現在只將即時警報發回控制中心，管理人員將任務分配給維修工人，人工解決設備故障。
例如，本案沒有嘗試鏈接自動化節能機制。所有異常行為，均由現場工作人員直接處理。如果實現控制功能，則需要額外的系統調試，這將導致無法承受的費用。但是，如果 DT 能夠真正實現，關鍵機器的可靠自動調整，自主消除故障狀態，比如降低能耗，將大大提升 DT 的實用價值。
(2)在建築項目中廣泛使用 DT 時，財務風險仍然相當大。建立 DT 涉及智慧感測器、攝影機、無線通信器等網路的大規模建設，如果在設計初期沒有精心規劃，將這些硬體設備添加到已建成的項目中，將非常困難甚至不可能建設項目，管理系統的控制中心也很昂貴。
因此，業主必須有強烈的動機和明確的遠見。如果證明在經濟上有利，一個項目應該毫不猶豫地採用 DT 技術。
（3）雖然前期總承包商的行動，在數據處理上被證明是有效的，但後來的系統開發，仍然涉及與建築物業主的繁瑣討價還價，總是有敏感數據整合。如果用於臉部辨識的患者個人數據等機密數據，向開發人員開放，那麼安全責任的邊界，就不會如此清晰。如果不開啟，DT 系統的可視化管理功能將不完整。所有者應在系統功能和資訊安全之間，找到平衡點。需要技術創新和管理創新。
在未來的研究中，這些難題有望透過更高級的 DT 應用案例來解決。在 DT 領域，這種做法被認為比純理論更有說服力，因為主要障礙，經常出現在管理和預算問題上，而不是技術問題上。隨著案例的累積，開發人員甚至可以將他們成功的軟體組件，發佈為流行的「微服務」模組，可以單獨分發和下載。
建築行業協會，也應制訂診斷模式的數據標準。根據這些公共標準，其他 DT 開發人員只需將來自 DT 的動態數據處理，成標準化輸入，然後選擇合適的竣工診斷模式。
高級 AI 編碼人員可以像開源社區一樣，貢獻模式儲存庫，而非專業人士則無需額外努力開發現有功能。理想情況下，DT 應用生態系統將逐漸出現，並使建築行業的使用者和軟體開發人員受益。
沒有留言:
張貼留言