下載app免費領取會員
我們之前花了四期的篇幅，給你講解了BIM的編碼是什么，在第四期的最后我們也留了一個尾巴，再給你談談國內的建筑信息編碼。
之所以間隔了這么久，是因為我們越是了解就越是發現，國內的編碼體系很雜、很亂，而且和它相關的，還有設計、施工、運維等業務中存在的問題，有「全生命周期管理」這個理念的大坑，甚至很多環節BIM推進不下去的癥結也藏在這個深不見底的黑洞里。
因為我們在討論「全生命周期」這樣的大事時，很少會鉆到一個編碼的小細節里去，但正是這些細節里的小螞蟻，一點一點啃出了這條路上的一個個坑。
所以今天我們雖然是繼續聊BIM編碼，但真正的話題是它背后一系列問題，這些問題導致了各路專家理念的沖突、導致了理論研究和一線操作的割裂。
1
咱們先簡單回顧一下，之前我們四期關于編碼的內容都談了些什么。
編碼的存在意義，是人類進入計算機時代，信息在不同語種、不同行業、不同軟件之間傳遞，需要一套統一的二進制規則。
建筑信息編碼的重點不在于代碼本身，而在于分類，因為不同角色對建筑元素的分類方法是不一樣的。投資人和設計師關注建筑的成品物理組件，而施工單位更關注工序的分解、是實現這個物理組件的方法。
美國的Masterformat和Uniformat都是樹狀分類法，前者是乙方思維，后者是甲方思維。
簡單的樹狀分層分類會帶來很多的問題，隨著特征的增加，編碼數量會急劇增加，并且哪個特點該排在更高的層級也更難界定。
后來出現的面分類法在一定程度解決了這兩個問題，它是把互相平行的「特征面」單獨分組編碼，互不干涉。需要的時候，在對應的特點組里挑出特定的編碼，組合到一起就行了。Revit軟件里集成的Omniclass就是面分類法。
到此，咱們算是趕上了進度，前幾期文章的鏈接放到最后，如果你感興趣可以去看看。
看完了這些知識，你會不會有種感覺：好像除了滿足一下好奇心，這些東西知道了也沒什么用呀。
你這么想就對了，大多數設計師和工程師，確實是不需要編碼知識的，正如我們每天都用鍵盤打字，卻根本不需要知道漢字背后的UTF-8和GB編碼規則一樣。這些編碼已經由你使用的軟件編寫好，你在前端使用功能時，對編碼應該是無感的。
不過，這里用文字編碼來打比方，有個很大的問題。文字的編碼歷史中，先后出現了ASCII、GB、Unicode、UTF等等不同的編碼，人們都是選擇「當前最好的編碼」，而不是等一個完美的編碼。
時至今日，我們能使用各種文本軟件而不需要操心編碼的問題，正是因為文字編碼的迭代已經基本完成，全球大一統都沒啥問題了。而我們的建筑編碼，還遠遠沒達到這一步，我們還是活在編碼不斷更替、不斷競爭的時代里，我們所使用的軟件自帶的功能，也還遠遠沒達到業務的要求。
所以在有些情況下，人們還是要求助于編碼，有時候是自己編，有時候是抄現成的。
2
咱們先舉幾個例子，來看看他們為什么要用編碼，再回來看一個大問題：不同的人說建筑系信息編碼，有時候根本不是一個意思。
案例一
之前我們的一位朋友@段晨光，談到他在參與法蘭克福一個大型項目時的案例。其中一項很重要的工作，就是把機電專業在墻和樓板上預留的洞口在建筑模型上表達出來，這樣建筑師才能出正式的施工圖。
這里的難點在于，機電工程師用的軟件是Tricad，而建筑師用的Revit。這些洞口還不是一次性挪過去就行，每一層建筑都需要前后開幾次會才能把洞口位置確定下來。整個項目下來，洞口轉移的過程需要重復將近1000次。
為了增加這項重復勞動的效率，甲方就組織第三方公司開發了專門的插件，它能把機電工程師提交的 Tricad 洞口數據批量轉化成 Revit 族，這些族還必須帶著自己的空間坐標信息，才能在導入 Revit 的時候，自動放到該呆的地方去。
這樣的批量導入工作還不夠，因為機電工程師設計過程中可能會犯錯，每次開完會，一部分洞口的位置也需要重新調整，如果每次導入都需要一個一個洞口檢查位置，那工作量還是太大了。
所以這個插件還開發了一個功能，就是利用一串編碼來跟蹤每一個洞口。它在 Tricad 里編號為3519621，到了 Revit 里也必須編號為 3519621，每一次移動了這個洞口的位置，它的編號還必須保持不變。
這樣，每次導入的時候，它們就只需要追蹤那些編號一致、空間坐標發生變化的洞口，也就是下面圖中紫色的部分，看看是工程師弄錯了，還是洞口的位置發生變化了。
下面是重點了：我們知道 Revit 每個構件都有一個獨立的 ID，那我們能不能用這個 ID 號作為洞口的編碼呢？畢竟，這樣用現成的話我們就不需要專門為它設計一個編碼了。
答案是：不行。
因為 Revit 和 Tricad 用的不是一套計算機編碼體系，它們之間的構件 ID 是不一樣的。所以一個洞口必須有一個軟件自帶編碼之外的、額外的參數，我們還要在插件上設計一個規則，讓這個參數能從 Tricad 里出去，再完好無損地進入到 Revit 里面去。
這就是我們第一個案例代表的一種情況：當我們在不同軟件里傳遞一個信息的時候，光靠軟件自帶的構件ID編碼是不夠的。我們必須在它們之間創造一把「鑰匙」。
案例二
我們的另一位朋友@金戈也談到了他在項目服務中使用編碼的原因。
他所在公司的服務對象是業主方，對方要的東西很明確，不是設計模型，也不是施工模型，而是竣工模型。
甲方要求，在竣工模型的構件里，要加入他們運維需要的屬性信息，這些屬性包括技術信息，比如長度、寬度、高度、風量、水量等；也包括非技術信息，比如設計人員、施工人員、維保人員、工藝工法、控制開關、聯系電話等，加起來要寫70多個參數。
這些參數如果要一個一個手動填寫到 Revit 模型構件里，那是要累出人命的。所以金戈的團隊選擇了數模分離的方法：在 Excel 里批量編輯這些參數，然后把它們批量導入到 Revit 里，附著到每個構件上。
要達到這個目的，在 Excel 和 Revit 之間，就必須有一把鑰匙，這和前面說到的 Tricad 和 Revit 之間互傳信息是一樣的，只不過這次要傳輸的不僅是空間坐標信息，而是70多項參數。
那么，我們還是像上個案例那樣，給每個構件設計唯一的編號，讓它作為 Excel 和 Revit 之間的「鑰匙」呢？
答案是：不行。
因為上一個案例要處理的只有一種構件類別，也就是洞口，也就不需要分類了，只要每個構件的編碼不重復、可以被不同軟件識別就行。但在這個案例中，工程項目的交付文件里有成千上萬個不同種類的構件，如果每個構件都彼此獨立，那 Excel 表格可就要寫得無限長了。所以必須要分類。
你可能會說，要分類這很簡單呀， Revit 不是按照墻梁柱板水暖電給分好類了嗎？跟著分類走不就行了？
還是不行。
這里的關鍵在于，不同人關注的構件分類不一樣。
拿水泵這個構件來舉個例子。設計師在做設計的時候，會根據專業，把空調水泵、給排水水泵、暖通水泵給區分開，它們的分類是跟著專業走的；到了施工那里，算量要按照清單分類來分，工序則要按照分部分項來分；而最終到了業主那里，水泵就是一個資產，不管它在設計的時候屬于什么專業，也不管它安裝的時候在哪個工序。
同樣一個東西，在設計階段可能歸屬于某種分類，在施工和運維階段可能會歸屬于另外不同的分類。而 Revit 是為設計服務的軟件，如果你的成果服務于運維，它自帶的編碼系統就難以滿足需求，而要在這之外重新設計一套符合運維標準的編碼規則。
在金戈所在的項目里，最終交付的是業主要的竣工模型，而且參與項目的還不止他們一家，所有服務商最終交付的結果要匯總到業主這里，大家寫參數的辦法可以各顯神通，但最終那把「鑰匙」必須是統一的。
最終這個項目，甲方召集各方開會，金戈團隊牽頭，編一個大家都同意的編碼規則，各家再把這個規則里的編碼作為「鑰匙」，寫到交付的模型里去。
下面這串代碼，就是站在甲方的視角來看待一個離心風機的結果，顯然，通過分類、規格、位置和序列號能定義一個構件的唯一性，剩下的就是往里挪參數了。
聊到這兒，咱們稍微總結一下，大多數時候，我們建一個模型交出去，或者出幾張圖、算算量，是完全不需要考慮編碼這件事的，軟件本身已經幫你編過碼了。但在以下幾種情況下，我們就需要自己定義編碼了：
需要軟件自帶功能無法實現的自動批量操作
需要在多個軟件之間傳遞數據
需要在多種數據類型之間傳遞數據
3
咱們說完了大家為什么要用編碼，接下來再說說：當人們爭論編碼的時候，很可能說的不是一件事。
你看，在第一個案例里，我們要實現的是讓每個洞口都能被 Revit 識別并且記住，那就需要給它們設置不同的代碼。給每個洞口設置唯一的代碼這個行為，有人把它稱為「編碼」，而也有一些人認為這不應該叫編碼，而應該只叫「編號」，因為它只要有唯一性就可以，而不需要遵循某個特定的規則。
在第二個案例里，我們不僅要讓每個構件唯一，還需要把它們進一步分類，有的人就說，有分類規則的編碼，才叫編碼。
還沒完，第二個案例中的編碼規則是有明確邊界的，只能給業主服務，甚至只能給一家業主服務，到了其他人那，這套編碼規則就得換。所以又有人說，這種編碼不能用于從設計到運維的各個環節，不能叫編碼。我們要做一套可以囊括所有信息、用于全生命周期管理的建筑信息編碼。
你看，「編碼」就是這么兩個字，每個人說出來的時候想的東西很可能不一樣，咱們可以非官方地把這三種編碼分別叫做「構件編號」、「分類編碼」和「全過程信息編碼」。
在這三種討論里，前兩種情況咱們說過了，接下來說說第三種情況：我們能不能編一個終極編碼規則，讓所有項目、所有人都適用呢？如果能，實現的難點在哪里呢？
很多人談到編碼的時候，喜歡用身份證舉例，那咱們就用身份證來說明這個問題。
每個人的身份證號都是不一樣的，它實現了每個人身份的唯一性，這一層不用多解釋了。
再進一層，身份證號碼除了唯一性，還是可以攜帶一些信息的。
比如目前用得最多的18位身份證號碼，你可以通過前六位數字定位一個人的籍貫所在地，從第7位開始可以知道一個人的出生年月日，進而可以計算出年齡；倒數第二位則可以看出性別來。
如果現在需要設計一個程序，對大量人員進行統計、管控，只需要把他們的身份證號輸入進去，再設置一定的過濾條件就行了，比如統計河南省有多少大于40歲的男性。
上面說的是事實，下面為了說明問題，我們做一些假設。
假設疫情過后，國家有關部門想給每個人加上一個「有沒有被傳染過」的信息，1代表傳染過，0代表沒被傳染過。那能不能往身份證號后面加一位數字呢？當然，理論上是可以的。
這樣每個人的身份證號就變成了19位。我們能用身份證號信息做的事就多了一個維度，可以統計每個省市不同年齡、不同性別的傳染分布了，很方便對不對？
可是沒過幾天，教育部的人又說，那不如把學歷也編個號，寫到身份證號里去吧。于是身份證號又變成了20位。
接下來的事你想想也知道了，很快，找來的部門越來越多，身份證號越來越長，沒過幾年，每個人的身份證號都變成2000位的了，出門像帶個扁擔一樣，這就不合適了吧？
還有另外一個問題，就是有些東西是隨時間不斷變化的，比如你想把一個人的職業、收入、胖瘦這些東西也讓計算機讀取，可它們今年和去年的數值是不一樣的，總不能每隔幾個月就換一個身份證號吧？
所以你看，雖然在理論上我們能把一切信息編碼，但在真實的世界里，要把所有信息全都儲存在一個「大一統」的編碼框架里，也許并不是一個好主意。
真實世界里的一個身份證號，能起到的作用主要還是唯一性，具體要查看一個人的職業、健康、社保、學歷等信息，是以這串唯一的編號作為「鑰匙」，進入到其他表格里才能查到。
我們給建筑構件編碼，也必須是這樣：先通過某種比較粗略的分類方法給構件分類，賦予一串唯一不重復的編碼，然后把每個階段需要的數據單獨存放到族信息、數據庫或者表格里。
到了這一步，爭議還沒有結束。
4
目前的現實情況是，不同構件在設計階段按專業分類、施工階段按流水分類、運維階段按資產分類，每一撥人關注的信息要分別裝到不同的籃子里。
甚至對于同一個構件的同一個屬性，大家的需求都不一樣。比如同樣是「材質」這個參數，做裝修的人可能關注它的紋理圖案，做綠色建筑分析的人可能關注它的保溫性能，施工方可能關注它的工藝流程，甲方可能關注它的價格成本。
原本，大家用各自的軟件，帶著各自的編碼，邊界清晰， 沒出現什么問題。
可一旦說到「建筑全生命周期管理」這樣的詞，問題就來了：大家各自使用的模型、數據庫、Excel，計算機程序是不能隨意互相訪問的。
比如某一家企業，把一根柱子編號為A-01，它的屬性信息單獨存放在一張資產運維表，表格被命名為CE01。只要到這張表格的第4列就能查到它的材質信息。
這家企業制定這樣的規則，可沒和全行業的人打招呼，另一家企業用其他軟件打開這個文件，A-01是啥不知道，CE01是哪張表也不知道，這就沒法查了。
在一次線下交流會上，一位BIMer向廣聯達的一位技術人員提問：為什么用圖形算量服務在施工階段總是很別扭？對方回答：因為圖形算量軟件是給招投標用的，本來就不是面向施工來設計的。而招標算量和施工算量的業務有很多不同。
算量依據不一樣，招投標階段是國家和地方的清單計價量，施工階段是實物量；
構件分類不一樣，招投標階段構造柱不用細分，施工階段還要按部位和流水段細分；
顆粒度不一樣，招投標階段只考慮主要工序，施工階段所有輔助作業也要分解出來；
業務關系不一樣，招投標階段各個工序之間基本沒有關系，施工階段則要嚴格考慮相互關系，等等。
其實類似這樣的問題很多，而我們真正應該深究的，不是去問為什么用于招投標的模型不能用于施工算量，而是要反過來問：我們為什么需要招投標模型能用于施工算量？
因為我們每天都聽到全生命周期管理，聽到信息的上下游傳遞，聽到一模多用，我們誤把愿景當成了現實。
而現實世界是這樣的：編碼是給軟件用的，每個軟件一定有自己的編碼體系。但軟件開發出來是要有人買單的，軟件開發的所有目標，就是滿足買單者的業務要求。
軟件的服務邊界處可能會有一點點模糊的外擴，比如支持一些中間格式的導入導出，但一定不能無限外擴，否則無限窮舉的研發成本會把一個軟件商拖垮。
那有沒有可能有行業里的其他參與方來做這件事呢？答案是有。
5
咱們拿大家都熟悉的三國來打個比方，簡單說說三方在做的事：
魏國
名正言順占天時
這一方最有代表性的就是中國建筑標準設計院。
標準院很早就拿到了尚方寶劍，組織行業專家出一本適用于整個行業的建筑信息編碼標準。工作起步時國內沒什么可以參考，主要就是參考了美國的 Omniclass來做本地化。可是這工作做了四年多，卻一直壓著沒有發，因為一直不知道這本標準發出去給誰貫宣交底，誰來用呢？直到2017年馬上要到五年期限，這才硬著頭皮把這本《建筑工程設計信息模型分類和編碼標準》發出來。
這一方目前的局勢是：Omniclass 在國外沒有解決的問題，它也尚未解決，而 Omniclass 有 Revit原生加持，好歹落了戶，可國內這本標準很少有人直接使用，GB/T的身份也沒能「挾天子以令諸侯」。
蜀國
將士效忠占人和
這一方的代表就是黃強先生帶領的中國BIM發展聯盟。
從P-BIM到CDM，黃強想做的事情是獨立于任何軟件之外的一套標準，一個編碼對應一張表，數據必須能讓現場一線人員編輯。之所以這么做，還是因為一線工程師的很多業務需求找不到現成好用的軟件來解決，軟件之間的數據打通也一直是猴年馬月的事，數字工程師的探索不能等，那就招呼工程師們自己搞數據標準。
這一方目前的局勢是：不管外界有怎樣的評價，確實有一群工程師在這套方法中看到希望，甘愿奉獻出時間來寫這套標準。不過也存在著標準寫出來之后，有多少軟件商愿意使用的問題。
吳國
財大氣粗占地利
這一方面最有代表性的就是萬達和華東院這樣的超大規模企業。它們有自己一套詳細的編碼標準，這套體系已經打破了設計、施工和運維之間的壁壘。
萬達要求凡是來提供服務的，必須用萬達的平臺，用萬達寫好編碼屬性的族庫，遵循萬達的標準來交付；華東院則是基于 Bentley 系列軟件無縫交換數據的特點，投入重金開發了自己的一套軟件和平臺體系，把所有數據壁壘都在內部消化掉。據說這兩家企業在信息化方面的投入都已經過億。
這一方目前的局勢是：打破了軟件和業務之間的邊界，但同時建立了自身服務的邊界，萬達的系統做不了碧桂園的項目，華東院的在雄安交付結果也用不到湖南。
在這里需要加粗強調：上面三國的比喻只是為了幫你理解三個不同的探索方向，國內探索的「諸侯」也不止這三方。BIMBOX沒有資格、也無意對任何一方的付出提出批評或質疑。
未來還很長，人們努力到最后其實不僅僅是技術問題，也有話語權的問題。一個全行業普適的標準，肯定不是在某個早晨突然讓所有人達成共識，而是通過某一個方向日以繼夜地持續探索，一個項目一個項目、一個軟件一個軟件、一撥人一撥人地爭取過來。
我們所在的世界不是一個純技術的世界，這個世界之所以是今天的樣子，還有很多商業的、資本的、甚至政治、人文的原因。
6
在和我們的朋友@林臻哲聊到編碼問題的時候，他說：
“現階段務實的企業不應該盲目追求編碼，而應該明晰自己業務對象的邊界。給誰提供服務，就按需交付。
尤其是對于現階段BIM在設計和施工的發展情況來說，首先要解決的根本不是編碼的問題，而是標簽的規范問題。
所謂標簽，你可以理解為 Revit 里任何參數的命名。我們要給一堵墻編碼，如果在內部光是「現澆」、「澆筑」、「混凝土澆筑」這些屬性標簽都無法統一，那任何編碼都是沒意義的。
這讓我想起在做《中國BIM草根報告》調研時候發生的一件糗事：我們寫了一道問題，讓大家回答自己常用的BIM軟件，給的是簡答題，拿到問卷我們就傻了，光是Navisworks一個軟件愣是有20多種寫法，這咋統計呀？
我們還處在一個莽荒的時代，未來的建筑信息編碼無論怎么發展，一定是被軟件集成在后端，使用的人對代碼應該是無感的。
這就像早些年大家寄東西，都要自己寫郵編，方便郵局的機器識別代碼、實現自動分揀。后來人們發快遞不需要查郵編了，用下拉菜單選擇就更不容易出錯。再到今天，連下拉菜單都不需要，你只要復制粘貼一下，軟件就會自動幫你把地址、人名和電話分類填好。
人本就應該處理自然語言，編碼本就應該屬于計算機。只不過我們這個行業和那個「去郵編」的美好世界之間，還隔著很多大坑。
但我們相信，看到坑的愁眉苦臉，總好過假裝沒有坑的歌舞升平。
在和@小耳朵貓醬一起探討這一期內容時，我開玩笑道：這個系列寫了好幾萬字，感覺繞了一個大圈，告訴大家這有一個坑。她這樣和我說：
它不是一個坑，它只是還沒填平的路。
這一期咱們就聊到這兒，有態度，有深度，BIMBOX，咱們下次見！
特別答謝在這段時間幫助我們提供案例和思路的：商麗梅、呂振、段晨光、金戈、戴路、王初翀（小耳朵貓醬）、林臻哲。
本文版權歸腿腿教學網及原創作者所有，未經授權，謝絕轉載。
上一篇：Revit如何對參數值進行舍入
推薦專題
- 人工智能浪潮席卷工業領域，當AI算法深度賦能機電一體化設計時，將會碰撞出怎樣的創新火花？
- 各地BIM審查政策陸續推出，如何提高BIM審查效率，解決報建交付難題？
- 城市生命線｜地下管網數字化建模
- Revit技巧 | Revit粘貼功能無法與當前所選標高對齊
- Revit技巧 | Revit項目中導入樣板文件的方法
- Revit技巧 | revit風管繪制教程：關于在Revit中如何設置標準的矩形風管邊長規格
- Revit技巧 | Revit操作技巧：如何將項目導出成方便查看的網頁模式
- Revit技巧 | 與Revit相關的標高灰色
- Revit技巧 | Revit如何刪除鏈接的CAD文件？
- Revit技巧 | 如何解決Revit結構框架搭接的問題？
