我們日常生活中的創新讓我們認識到了技術的能力。對于我們這些在建筑環境中工作的人來說，帶來了許多關于建筑能力的假設。當我們開車去上班的時候，我們的車會為我們剎車以避免碰撞，也會根據每個駕駛員的喜好自動調節空調，下雨的時候會自動打開大燈。

于是，我們開始設想，建筑物如何實現這種智能來抑制碳排放，改善用戶體驗，降低運營效率和成本。但是建筑是非常復雜的，甚至比現代交通工具復雜得多。每一個都有數千個設備以及設備上的數千個數據點所有這些都具有自己的技術、供應商、樓宇管理系統協議和網絡。

智能建筑行業的大多數專家都認為，為了讓建筑達到我們在其他行業看到的智能水平，一個獨立的數據層(IDL)簡化了建筑技術的復雜性是至關重要的。他們也明白，要實現這一點，對于行業來說，有一個組織建筑數據的標準化方法是很重要的，這意味著建筑數據模型。

雖然“為什么”已經很清楚，但“如何”往往不太清楚。通往模型良好的建筑的道路往往不太順利。以下是為更順暢的數據建模之旅鋪平道路的 5 個技巧：

挑戰一：如何獲得統一的數據建模和一致性？

建筑環境的復雜性帶來了建筑環境中標記和數據建模的大量不一致。這些不一致使數據建模者難以跨設備、建筑物甚至投資組合選擇和實施一致且統一的數據模型。例如，如果有人要求你對點“AHU1DATSP”進行建模，你會怎么做？你會給它貼上“ahu”、“discharge”、“setpoint”、“temp”的標簽嗎？或者可能是“供應”、“空氣”、“溫度”、“設定點”？

解決方案：

標記和數據建模中的這種不一致是我們的Ontology Alignment Project (OAP)背后的動機。除了將多個本體集中在一個范圍下之外，OAP 還為標記點和設備提供了規范性指導。數據建模者可以從預定義的點名稱列表中選擇，而不是猜測一組好的標簽可能是什么。因此，可以通過應用 OAP 的點定義來標記名為“AHU1DATSP”的點：“排放空氣溫度設定點”，它定義了正確的標簽集：“空氣”、“排放”、“有效”、“點”、“sp” ，`溫度`。

挑戰二：如何進行數據建模？

建筑環境的復雜性——數據點、設備、建筑物、空間、關系——導致了大量的數據。由于要建模的數據如此之多，數據建模人員和開發人員可能很難知道如何以及從哪里開始。這可能會導致智能建筑解決方案的開發和實施出現重大瓶頸，或者會增加環境的復雜性。

解決方案

例如 Buildings IOT開發了工具和流程來輕松載入建筑物數據，并允許建筑集成商和數據建模人員快速有效地繪制建筑物地圖。此外，OAP 數據標準是完全開放、可訪問和可查詢的，其他人可以通過 GraphQL API 來利用和構建自己的工具。

挑戰 3：數據建模是一個重復且耗時的過程。

簡化構建環境的復雜性通常意味著重復標記大量實體。對于數據建模人員和開發人員來說，跨建筑和投資組合標準化建筑環境數據是一個耗時的過程。即使對于有經驗的數據建模人員，將“AHU1DATSP”標記為“排氣溫度設定點”也變得很麻煩。

解決方案

利用機器學習和人工智能來自動識別點并根據點或實體名稱和歷史數據應用數據模型。這節省了大量時間，使我們能夠更快、更準確地應用數據模型。

挑戰 4：我需要多少數據建模？

數據建模人員和開發人員普遍關心他們正在獲得滿足其需求的正確數據。更糟糕的是，如果沒有為建筑物的數字化設定目標，幾乎不可能知道需要對哪些數據進行建模。因此，很容易被數據建模沖昏頭腦，并構建一個過于詳細或過于復雜的模型。

解決方案：

解決這個問題首先要為建筑數字化轉型建立一個具體且可衡量的目標。問問自己，用例是什么，你想解決什么問題？使用這些問題的答案來指導數據建模以限制范圍并僅根據需要進行建模。例如，你會做分析嗎？故障檢測？能源洞察力？圖形？入住體驗？這些數據將如何使用，我是否滿足了這種需求？考慮到這些問題，更容易縮小需要建模的所需信息。

挑戰5：我做對了嗎？

一旦完成了一個數據模型，就很容易洗手走人，但重要的是要驗證已經創建了一個完整且準確的模型，它將處理所需的用例。

解決方案

驗證工具是確保建筑物完全建模且沒有錯誤的關鍵。例如，如果空氣處理器有一個熱水閥控制點，它的加熱過程是否定義為使用加熱熱水？它與為它服務的設備是否有熱水關系？

建立和檢查關系是模型創建的最后一個重要步驟。在建筑物物聯網，驗證工具建立在內部專業知識和OAP建模標準的基礎上。