BIMBOX | 當你說BIM全生命周期的時候，有沒有看見那些大坑？

你好，這里是BIMBOX。

我們之前花了四期的篇幅，給你講解了BIM的編碼是什么，在第四期的最后我們也留了一個尾巴，再給你談談國內的建筑信息編碼。

之所以間隔了這么久，是因為我們越是了解就越是發(fā)現(xiàn)，國內的編碼體系很雜、很亂，而且和它相關的，還有設計、施工、運維等業(yè)務中存在的問題，有「全生命周期管理」這個理念的大坑，甚至很多環(huán)節(jié)BIM推進不下去的癥結也藏在這個深不見底的黑洞里。

因為我們在討論「全生命周期」這樣的大事時，很少會鉆到一個編碼的小細節(jié)里去，但正是這些細節(jié)里的小螞蟻，一點一點啃出了這條路上的一個個坑。

所以今天我們雖然是繼續(xù)聊BIM編碼，但真正的話題是它背后一系列問題，這些問題導致了各路專家理念的沖突、導致了理論研究和一線操作的割裂。

咱們先簡單回顧一下，之前我們四期關于編碼的內容都談了些什么。

到此，咱們算是趕上了進度，前幾期文章的鏈接放到最后，如果你感興趣可以去看看。

看完了這些知識，你會不會有種感覺：好像除了滿足一下好奇心，這些東西知道了也沒什么用呀。

你這么想就對了，大多數(shù)設計師和工程師，確實是不需要編碼知識的，正如我們每天都用鍵盤打字，卻根本不需要知道漢字背后的UTF-8和GB編碼規(guī)則一樣。這些編碼已經由你使用的軟件編寫好，你在前端使用功能時，對編碼應該是無感的。

不過，這里用文字編碼來打比方，有個很大的問題。文字的編碼歷史中，先后出現(xiàn)了ASCII、GB、Unicode、UTF等等不同的編碼，人們都是選擇「當前最好的編碼」，而不是等一個完美的編碼。

時至今日，我們能使用各種文本軟件而不需要操心編碼的問題，正是因為文字編碼的迭代已經基本完成，全球大一統(tǒng)都沒啥問題了。而我們的建筑編碼，還遠遠沒達到這一步，我們還是活在編碼不斷更替、不斷競爭的時代里，我們所使用的軟件自帶的功能，也還遠遠沒達到業(yè)務的要求。

所以在有些情況下，人們還是要求助于編碼，有時候是自己編，有時候是抄現(xiàn)成的。

咱們先舉幾個例子，來看看他們?yōu)槭裁匆镁幋a，再回來看一個大問題：不同的人說建筑系信息編碼，有時候根本不是一個意思。

之前我們的一位朋友@段晨光，談到他在參與法蘭克福一個大型項目時的案例。其中一項很重要的工作，就是把機電專業(yè)在墻和樓板上預留的洞口在建筑模型上表達出來，這樣建筑師才能出正式的施工圖。

這里的難點在于，機電工程師用的軟件是 Tricad，而建筑師用的 Revit。這些洞口還不是一次性挪過去就行，每一層建筑都需要前后開幾次會才能把洞口位置確定下來。整個項目下來，洞口轉移的過程需要重復將近1000次。

為了增加這項重復勞動的效率，甲方就組織第三方公司開發(fā)了專門的插件，它能把機電工程師提交的 Tricad 洞口數(shù)據批量轉化成 Revit 族，這些族還必須帶著自己的空間坐標信息，才能在導入 Revit 的時候，自動放到該呆的地方去。

這樣的批量導入工作還不夠，因為機電工程師設計過程中可能會犯錯，每次開完會，一部分洞口的位置也需要重新調整，如果每次導入都需要一個一個洞口檢查位置，那工作量還是太大了。

所以這個插件還開發(fā)了一個功能，就是利用一串編碼來跟蹤每一個洞口。它在 Tricad 里編號為3519621，到了 Revit 里也必須編號為 3519621，每一次移動了這個洞口的位置，它的編號還必須保持不變。

這樣，每次導入的時候，它們就只需要追蹤那些編號一致、空間坐標發(fā)生變化的洞口，也就是下面圖中紫色的部分，看看是工程師弄錯了，還是洞口的位置發(fā)生變化了。

下面是重點了：我們知道 Revit 每個構件都有一個獨立的 ID，那我們能不能用這個 ID 號作為洞口的編碼呢？畢竟，這樣用現(xiàn)成的話我們就不需要專門為它設計一個編碼了。

答案是：不行。

因為 Revit 和 Tricad 用的不是一套計算機編碼體系，它們之間的構件 ID 是不一樣的。所以一個洞口必須有一個軟件自帶編碼之外的、額外的參數(shù)，我們還要在插件上設計一個規(guī)則，讓這個參數(shù)能從 Tricad 里出去，再完好無損地進入到 Revit 里面去。

這就是我們第一個案例代表的一種情況：當我們在不同軟件里傳遞一個信息的時候，光靠軟件自帶的構件ID編碼是不夠的。我們必須在它們之間創(chuàng)造一把「鑰匙」。

我們的另一位朋友@金戈也談到了他在項目服務中使用編碼的原因。

他所在公司的服務對象是業(yè)主方，對方要的東西很明確，不是設計模型，也不是施工模型，而是竣工模型。

甲方要求，在竣工模型的構件里，要加入他們運維需要的屬性信息，這些屬性包括技術信息，比如長度、寬度、高度、風量、水量等；也包括非技術信息，比如設計人員、施工人員、維保人員、工藝工法、控制開關、聯(lián)系電話等，加起來要寫70多個參數(shù)。

這些參數(shù)如果要一個一個手動填寫到 Revit 模型構件里，那是要累出人命的。所以金戈的團隊選擇了數(shù)模分離的方法：在 Excel 里批量編輯這些參數(shù)，然后把它們批量導入到 Revit 里，附著到每個構件上。

要達到這個目的，在 Excel 和 Revit 之間，就必須有一把鑰匙，這和前面說到的 Tricad 和 Revit 之間互傳信息是一樣的，只不過這次要傳輸?shù)牟粌H是空間坐標信息，而是70多項參數(shù)。

那么，我們還是像上個案例那樣，給每個構件設計唯一的編號，讓它作為 Excel 和 Revit 之間的「鑰匙」呢？

答案是：不行。

因為上一個案例要處理的只有一種構件類別，也就是洞口，也就不需要分類了，只要每個構件的編碼不重復、可以被不同軟件識別就行。但在這個案例中，工程項目的交付文件里有成千上萬個不同種類的構件，如果每個構件都彼此獨立，那 Excel 表格可就要寫得無限長了。所以必須要分類。

你可能會說，要分類這很簡單呀， Revit 不是按照墻梁柱板水暖電給分好類了嗎？跟著分類走不就行了？

還是不行。

這里的關鍵在于，不同人關注的構件分類不一樣。

拿水泵這個構件來舉個例子。設計師在做設計的時候，會根據專業(yè)，把空調水泵、給排水水泵、暖通水泵給區(qū)分開，它們的分類是跟著專業(yè)走的；到了施工那里，算量要按照清單分類來分，工序則要按照分部分項來分；而最終到了業(yè)主那里，水泵就是一個資產，不管它在設計的時候屬于什么專業(yè)，也不管它安裝的時候在哪個工序。

同樣一個東西，在設計階段可能歸屬于某種分類，在施工和運維階段可能會歸屬于另外不同的分類。而 Revit 是為設計服務的軟件，如果你的成果服務于運維，它自帶的編碼系統(tǒng)就難以滿足需求，而要在這之外重新設計一套符合運維標準的編碼規(guī)則。

在金戈所在的項目里，最終交付的是業(yè)主要的竣工模型，而且參與項目的還不止他們一家，所有服務商最終交付的結果要匯總到業(yè)主這里，大家寫參數(shù)的辦法可以各顯神通，但最終那把「鑰匙」必須是統(tǒng)一的。

最終這個項目，甲方召集各方開會，金戈團隊牽頭，編一個大家都同意的編碼規(guī)則，各家再把這個規(guī)則里的編碼作為「鑰匙」，寫到交付的模型里去。

下面這串代碼，就是站在甲方的視角來看待一個離心風機的結果，顯然，通過分類、規(guī)格、位置和序列號能定義一個構件的唯一性，剩下的就是往里挪參數(shù)了。

聊到這兒，咱們稍微總結一下，大多數(shù)時候，我們建一個模型交出去，或者出幾張圖、算算量，是完全不需要考慮編碼這件事的，軟件本身已經幫你編過碼了。但在以下幾種情況下，我們就需要自己定義編碼了：

? 需要軟件自帶功能無法實現(xiàn)的自動批量操作

? 需要在多個軟件之間傳遞數(shù)據

? 需要在多種數(shù)據類型之間傳遞數(shù)據

咱們說完了大家為什么要用編碼，接下來再說說：當人們爭論編碼的時候，很可能說的不是一件事。

你看，在第一個案例里，我們要實現(xiàn)的是讓每個洞口都能被 Revit 識別并且記住，那就需要給它們設置不同的代碼。給每個洞口設置唯一的代碼這個行為，有人把它稱為「編碼」，而也有一些人認為這不應該叫編碼，而應該只叫「編號」，因為它只要有唯一性就可以，而不需要遵循某個特定的規(guī)則。

在第二個案例里，我們不僅要讓每個構件唯一，還需要把它們進一步分類，有的人就說，有分類規(guī)則的編碼，才叫編碼。

還沒完，第二個案例中的編碼規(guī)則是有明確邊界的，只能給業(yè)主服務，甚至只能給一家業(yè)主服務，到了其他人那，這套編碼規(guī)則就得換。所以又有人說，這種編碼不能用于從設計到運維的各個環(huán)節(jié)，不能叫編碼。我們要做一套可以囊括所有信息、用于全生命周期管理的建筑信息編碼。

你看，「編碼」就是這么兩個字，每個人說出來的時候想的東西很可能不一樣，咱們可以非官方地把這三種編碼分別叫做「構件編號」、「分類編碼」和「全過程信息編碼」。

在這三種討論里，前兩種情況咱們說過了，接下來說說第三種情況：我們能不能編一個終極編碼規(guī)則，讓所有項目、所有人都適用呢？如果能，實現(xiàn)的難點在哪里呢？

很多人談到編碼的時候，喜歡用身份證舉例，那咱們就用身份證來說明這個問題。

每個人的身份證號都是不一樣的，它實現(xiàn)了每個人身份的唯一性，這一層不用多解釋了。

再進一層，身份證號碼除了唯一性，還是可以攜帶一些信息的。

比如目前用得最多的18位身份證號碼，你可以通過前六位數(shù)字定位一個人的籍貫所在地，從第7位開始可以知道一個人的出生年月日，進而可以計算出年齡；倒數(shù)第二位則可以看出性別來。

如果現(xiàn)在需要設計一個程序，對大量人員進行統(tǒng)計、管控，只需要把他們的身份證號輸入進去，再設置一定的過濾條件就行了，比如統(tǒng)計河南省有多少大于40歲的男性。

上面說的是事實，下面為了說明問題，我們做一些假設。

假設疫情過后，國家有關部門想給每個人加上一個「有沒有被傳染過」的信息，1代表傳染過，0代表沒被傳染過。那能不能往身份證號后面加一位數(shù)字呢？當然，理論上是可以的。

這樣每個人的身份證號就變成了19位。我們能用身份證號信息做的事就多了一個維度，可以統(tǒng)計每個省市不同年齡、不同性別的傳染分布了，很方便對不對？

可是沒過幾天，教育部的人又說，那不如把學歷也編個號，寫到身份證號里去吧。于是身份證號又變成了20位。

接下來的事你想想也知道了，很快，找來的部門越來越多，身份證號越來越長，沒過幾年，每個人的身份證號都變成2000位的了，出門像帶個扁擔一樣，這就不合適了吧？

還有另外一個問題，就是有些東西是隨時間不斷變化的，比如你想把一個人的職業(yè)、收入、胖瘦這些東西也讓計算機讀取，可它們今年和去年的數(shù)值是不一樣的，總不能每隔幾個月就換一個身份證號吧？

所以你看，雖然在理論上我們能把一切信息編碼，但在真實的世界里，要把所有信息全都儲存在一個「大一統(tǒng)」的編碼框架里，也許并不是一個好主意。

真實世界里的一個身份證號，能起到的作用主要還是唯一性，具體要查看一個人的職業(yè)、健康、社保、學歷等信息，是以這串唯一的編號作為「鑰匙」，進入到其他表格里才能查到。

我們給建筑構件編碼，也必須是這樣：先通過某種比較粗略的分類方法給構件分類，賦予一串唯一不重復的編碼，然后把每個階段需要的數(shù)據單獨存放到族信息、數(shù)據庫或者表格里。

到了這一步，爭議還沒有結束。

目前的現(xiàn)實情況是，不同構件在設計階段按專業(yè)分類、施工階段按流水分類、運維階段按資產分類，每一撥人關注的信息要分別裝到不同的籃子里。

甚至對于同一個構件的同一個屬性，大家的需求都不一樣。比如同樣是「材質」這個參數(shù)，做裝修的人可能關注它的紋理圖案，做綠色建筑分析的人可能關注它的保溫性能，施工方可能關注它的工藝流程，甲方可能關注它的價格成本。

原本，大家用各自的軟件，帶著各自的編碼，邊界清晰， 沒出現(xiàn)什么問題。

可一旦說到「建筑全生命周期管理」這樣的詞，問題就來了：大家各自使用的模型、數(shù)據庫、Excel，計算機程序是不能隨意互相訪問的。

比如某一家企業(yè)，把一根柱子編號為A-01，它的屬性信息單獨存放在一張資產運維表，表格被命名為CE01。只要到這張表格的第4列就能查到它的材質信息。

這家企業(yè)制定這樣的規(guī)則，可沒和全行業(yè)的人打招呼，另一家企業(yè)用其他軟件打開這個文件，A-01是啥不知道，CE01是哪張表也不知道，這就沒法查了。

在一次線下交流會上，一位BIMer向廣聯(lián)達的一位技術人員提問：為什么用圖形算量服務在施工階段總是很別扭？對方回答：因為圖形算量軟件是給招投標用的，本來就不是面向施工來設計的。而招標算量和施工算量的業(yè)務有很多不同。

其實類似這樣的問題很多，而我們真正應該深究的，不是去問為什么用于招投標的模型不能用于施工算量，而是要反過來問：我們?yōu)槭裁葱枰型稑四Ｐ湍苡糜谑┕に懔浚?/span>

因為我們每天都聽到全生命周期管理，聽到信息的上下游傳遞，聽到一模多用，我們誤把愿景當成了現(xiàn)實。

而現(xiàn)實世界是這樣的：編碼是給軟件用的，每個軟件一定有自己的編碼體系。但軟件開發(fā)出來是要有人買單的，軟件開發(fā)的所有目標，就是滿足買單者的業(yè)務要求。

軟件的服務邊界處可能會有一點點模糊的外擴，比如支持一些中間格式的導入導出，但一定不能無限外擴，否則無限窮舉的研發(fā)成本會把一個軟件商拖垮。

那有沒有可能有行業(yè)里的其他參與方來做這件事呢？答案是有。

咱們拿大家都熟悉的三國來打個比方，簡單說說三方在做的事：

這一方最有代表性的就是中國建筑標準設計院。

標準院很早就拿到了尚方寶劍，組織行業(yè)專家出一本適用于整個行業(yè)的建筑信息編碼標準。工作起步時國內沒什么可以參考，主要就是參考了美國的 Omniclass來做本地化?？墒沁@工作做了四年多，卻一直壓著沒有發(fā)，因為一直不知道這本標準發(fā)出去給誰貫宣交底，誰來用呢？直到2017年馬上要到五年期限，這才硬著頭皮把這本《建筑工程設計信息模型分類和編碼標準》發(fā)出來。

這一方目前的局勢是：Omniclass 在國外沒有解決的問題，它也尚未解決，而 Omniclass 有 Revit原生加持，好歹落了戶，可國內這本標準很少有人直接使用，GB/T的身份也沒能「挾天子以令諸侯」。

這一方的代表就是黃強先生帶領的中國BIM發(fā)展聯(lián)盟。

從P-BIM到CDM，黃強想做的事情是獨立于任何軟件之外的一套標準，一個編碼對應一張表，數(shù)據必須能讓現(xiàn)場一線人員編輯。之所以這么做，還是因為一線工程師的很多業(yè)務需求找不到現(xiàn)成好用的軟件來解決，軟件之間的數(shù)據打通也一直是猴年馬月的事，數(shù)字工程師的探索不能等，那就招呼工程師們自己搞數(shù)據標準。

這一方目前的局勢是：不管外界有怎樣的評價，確實有一群工程師在這套方法中看到希望，甘愿奉獻出時間來寫這套標準。不過也存在著標準寫出來之后，有多少軟件商愿意使用的問題。

這一方面最有代表性的就是萬達和華東院這樣的超大規(guī)模企業(yè)。它們有自己一套詳細的編碼標準，這套體系已經打破了設計、施工和運維之間的壁壘。

萬達要求凡是來提供服務的，必須用萬達的平臺，用萬達寫好編碼屬性的族庫，遵循萬達的標準來交付；華東院則是基于 Bentley 系列軟件無縫交換數(shù)據的特點，投入重金開發(fā)了自己的一套軟件和平臺體系，把所有數(shù)據壁壘都在內部消化掉。據說這兩家企業(yè)在信息化方面的投入都已經過億。

這一方目前的局勢是：打破了軟件和業(yè)務之間的邊界，但同時建立了自身服務的邊界，萬達的系統(tǒng)做不了碧桂園的項目，華東院的在雄安交付結果也用不到湖南。

在這里需要加粗強調：上面三國的比喻只是為了幫你理解三個不同的探索方向，國內探索的「諸侯」也不止這三方。BIMBOX沒有資格、也無意對任何一方的付出提出批評或質疑。

未來還很長，人們努力到最后其實不僅僅是技術問題，也有話語權的問題。一個全行業(yè)普適的標準，肯定不是在某個早晨突然讓所有人達成共識，而是通過某一個方向日以繼夜地持續(xù)探索，一個項目一個項目、一個軟件一個軟件、一撥人一撥人地爭取過來。

我們所在的世界不是一個純技術的世界，這個世界之所以是今天的樣子，還有很多商業(yè)的、資本的、甚至政治、人文的原因。

在和我們的朋友@林臻哲聊到編碼問題的時候，他說：

這讓我想起在做《中國BIM草根報告》調研時候發(fā)生的一件糗事：我們寫了一道問題，讓大家回答自己常用的BIM軟件，給的是簡答題，拿到問卷我們就傻了，光是Navisworks一個軟件愣是有20多種寫法，這咋統(tǒng)計呀？

我們還處在一個莽荒的時代，未來的建筑信息編碼無論怎么發(fā)展，一定是被軟件集成在后端，使用的人對代碼應該是無感的。

這就像早些年大家寄東西，都要自己寫郵編，方便郵局的機器識別代碼、實現(xiàn)自動分揀。后來人們發(fā)快遞不需要查郵編了，用下拉菜單選擇就更不容易出錯。再到今天，連下拉菜單都不需要，你只要復制粘貼一下，軟件就會自動幫你把地址、人名和電話分類填好。

人本就應該處理自然語言，編碼本就應該屬于計算機。只不過我們這個行業(yè)和那個「去郵編」的美好世界之間，還隔著很多大坑。

但我們相信，看到坑的愁眉苦臉，總好過假裝沒有坑的歌舞升平。

在和@小耳朵貓醬一起探討這一期內容時，我開玩笑道：這個系列寫了好幾萬字，感覺繞了一個大圈，告訴大家這有一個坑。她這樣和我說：

它不是一個坑，它只是還沒填平的路。

這一期咱們就聊到這兒，有態(tài)度，有深度，BIMBOX，咱們下次見！

特別答謝在這段時間幫助我們提供案例和思路的：商麗梅、呂振、段晨光、金戈、戴路、王初翀（小耳朵貓醬）、林臻哲。