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

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

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

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

　　挑戰(zhàn)一：如何獲得統(tǒng)一的數(shù)據(jù)建模和一致性?

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

　　解決方案：

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

　　挑戰(zhàn)二：如何進行數(shù)據(jù)建模?

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

　　解決方案

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

　　挑戰(zhàn) 3：數(shù)據(jù)建模是一個重復且耗時的過程。

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

　　解決方案

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

　　挑戰(zhàn) 4：我需要多少數(shù)據(jù)建模?

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

　　解決方案：

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

　　挑戰(zhàn)5：我做對了嗎?

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

　　解決方案

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

　　建立和檢查關系是模型創(chuàng)建的最后一個重要步驟。在建筑物物聯(lián)網(wǎng)，驗證工具建立在內部專業(yè)知識和OAP建模標準的基礎上。