這半月進京被央企客戶趕考兩次，對於如何做好智慧型樓宇的產品，豐富解決方案打法又有所體會。產品來自客戶和專案需求，脫離了專案空談產品，就如同緣木求魚，白用功；而專案一樣離不了產品，解決方案的好壞，能否打動客戶，還在於做好標準產品的輸出和定製化的方案調整。乙個好的解決方案架構師如果不深入理解產品，就無法說服自己為何選擇這套方案，更無法讓客戶相信你推薦的方案。而且優秀的解決方案架構師還會帶著客戶的問題反哺產品，引導產品團隊的產品迭代方向，推動產品能更好地滿足市場的需要。
作為智慧型樓宇平台的產品設計師和解決方案架構師，我們重拾話題，繼續聊聊樓宇智慧型化。往前看，十年前市場上並沒有樓宇智慧型化平台這個說法，我們常聽到的是霍尼韋爾的bps、webs、ccs系統，江森的metasys、jem系統，這就涉及到乙個平台化 和 標準系統的區別。
雲計算技術 為何落到商業服務模式上有iaas/paas/saas三大類平台，因為這對應著硬體、作業系統、應用軟體三個層面的平台化程序。
儲存、cpu資源、網路頻寬 等硬體能力的彈性按需分配，帶來了iaas平台的大發展
軟體應用研發的作業系統、部署環境、開發工具等基礎設施平台化，衍生出paas平台。開發者只需要關注自己的業務邏輯，不需要關注底層，為生成、測試和部署軟體應用程式提供乙個環境，類似應用開發的middleware中介軟體
軟體開箱即用的需求則激發了saas平台的發展
那對於做智慧型建築的從業者來說，一樣迴避不了這三類問題。
硬體（邊緣）作為iaas基礎設施，是否可以做到按需調配
業務中樞是走平台化的方式還是整合系統的方式
應用軟體 在設計時如何平衡標準化和定製訴求
關鍵字：平台、系統、ibms、運營中心、ibos
感謝霍尼、tridium、utrc一起共事的同事和我一起無聊地討論這些話題，給我提供素材:)
首先我們了解下何為平台。
「平台」泛指要開展某項工作所依據的基礎條件。平台本身不做事，只是為其他做事的人或裝置或系統提供乙個環境或土壤。
平台也可以理解為一系列共性能力的集合。比如物聯網平台提供了裝置接入、裝置管理等基礎能力，大資料平台提供了資料管理、資料分析、視覺化呈現等通用服務。
前面所述的平台 並不直接解決具體的專業問題，但客戶更感冒的往往是「開包即用」軟體系統，比如企業資源管理的erp系統、營銷的crm系統、生產管理的mes系統，這些專業類的系統就是為了專門為做一件事或一類事而開發的一套系統，都帶有一定的業務目的性。
使用者不會為平台買單，只會為具體的業務系統或應用買單。所以從軟體公司來說，什麼時候需要平台？這其中的道理其實非常簡單——平台是可以復用的，而業務系統由於考慮了各條業務線的關聯性，反而不夠靈活，相對較僵化，復用性差。
當乙個行業業務需求還有很大的未知空間時，平台化會有優勢，而當乙個行業需求已經很固定，比如物業fm運維管理、辦公oa系統，這時再要做平台化 重新基於平台重塑業務應用系統，其實就是一件很值得推敲的事兒。不是不能做，而是現有的行業巨頭會評估是否值得推倒重來，當然有時候，外部壓力也會倒逼這些壟斷巨頭加快做出戰略調整。比如霍尼韋爾 在hbs樓宇板塊有ebi、webs、bps、ccs等多套系統軟體產品，涵蓋了bms、ibms、運營中心等多個客戶需求，本來穩賺不賠，不過在最近幾年網際網路公司數位化的強勢侵入下，也開始重視平台產品的建設，開始著力打造自己的forge雲平台。撇開網際網路巨頭為了推平台而不停地推數位化解決方案的動機，我個人覺得隨著c端、b端產品的壁壘逐步打破，未來的樓宇應用會越來越往個性化、定製化發展，所以有乙個平台級的支援底座還是很有必要。
不過對於這個平台來說，是做類似微軟azure iot、阿里雲iot這樣的通用物聯網平台，還是帶有業務賦能功能的系統平台。我覺得還是值得好好設計一番的。
現在很多在做數位化轉型的網際網路企業將iot物聯網平台當成自己的殺手鐗**，對外宣傳自己提供了怎樣怎樣的數位化能力，材料看起來也很不錯，不過這其實還是難以推敲的。裝置接入、連線管理雖然很重要，但我們已經不再是5-10年前剛做物聯網市場的時候，這些就如同00年的windows作業系統，10年的ios，已成為乙個大家都很認可、相對成熟的基礎產品，比拼的無非是差異競爭力。如果無法提供更顛覆性的改變，比如ios至於塞班，我們就需要在專業深度上下功夫。這就是我所說的智慧型建築需要平台，但更需要有專業know-how能力的平台。
從這個角度來說，我們如果將智慧型樓宇這個活兒按「端-邊-雲-應用」的四層架構來設計，雲上提供的其實是兩層平台，一層是iot通用平台，再其上則是賦能業務系統的領域平台。
通過通用和領域兩層平台，業務方不再需要自己去維護底層物聯基礎設施，也不需要過多的去關心業務引擎等相關的一些問題，業務方只需要專注於業務即可，這顯然能夠降低業務方的成本。
現在的智慧型樓宇和十年前的建築智慧型化，區別並不在於應用場景的多樣性，豐富的移動端玩法，兩者的最大差別還是管理思維的變遷。就像15年之後自從阿里提出「中臺」的概念，很多企業也一窩蜂的言必稱建設中臺，紛紛上馬各種資料中臺、技術中臺……，可效果如何，好像並不咋樣。不是中臺不好，而是用錯了地方。中臺其實是一種組織方式、思維方式、創新方式的變革，而不僅僅是乙個技術手段。當前的智慧型樓宇、智慧型園區也是一樣的道理，並不是新瓶裝舊酒，而更多代表的是一種運營模式、管理方式的創新。
傳統的本地ibms是什麼？這是一種對子系統/裝置的整合樓宇管理系統。其立意在「管」，為了管理的方便，所以就近提供了這樣一套集中式的中控入口，以管理可靠、方便為要旨。不過這樣一套整合管理系統是否適用現在這樣乙個需求多樣、訊息萬變的數字時代，還是需要去面對市場考驗。就拿我當前面臨的央企大樓智慧型專案來說，我們需要分三階段來立項，分步驟、分應用給客戶來做智慧型化設計。那ibms這種面向固定使用者群，注重流程和整體性考慮的系統軟體設計方式就顯得繁冗而不靈活。因為我需要更多考慮構件的重用性 和彼此間的低耦合。另外數位化時代，強調邊雲協同，synergy不是一句空話，雲和邊如何協調一致，離不了樓宇大腦這樣的作業系統調配。
作業系統，從狹義上來看，是管理和控制計算機硬體與軟體資源的計算機系統軟體。對樓宇來說，樓宇作業系統 就是對端裝置、邊裝置/系統的資源進行控制管理的一套系統平台。這套系統既可以安裝在近場的邊緣伺服器，也可以部署在彈性更大的雲端。通過雲-邊垂直聯動，邊-邊水平聯動，如臂使指，靈活地實現樓宇大腦中樞預期的效果。樓宇作業系統的價值在於能夠把乙個領域的能量（比如oa）傳遞到另外乙個領域（比如it），這裡面涉及到業務、管理的知識，不僅僅是技術能力復用那麼簡單。
作為連線底層物理硬體的關鍵中樞，作業系統減少人工資源分配的工作強度，降低使用者對於計算的操作干預程度。一樣的道理，樓宇作業系統，需要給上層的應用提供更多的開發便利，同時遮蔽現場裝置硬體的操作、管理、調配的難度，這也是當前ibms為何會跟不上的乙個因素。我們需要的是乙個足夠標準化、介於裝置與使用者之間溝通、完成諸多基礎管理能力的乙個作業系統，而不是乙個更側重專案制、定製化的整合管理系統。
tob業務和toc完全不一樣，家用智慧型家居對可用性，掉線率容忍性都很高，君不見google的nest，蘋果的smart home，經常可以看到各種安全新聞見諸報端。但企業端的客戶產品erp、sap則無法接受這種情況，對於智慧型樓宇尤其智慧型園區這塊，雖然我在「智慧型建築的幾個常見誤區」一文戲說過，屬於ton(『ni
結合最近熱炒的社群**，智慧型樓宇、智慧型產業無疑屬於投入多，但收效慢的行業，這不符合一些投資資本追逐的目標，所以願意在這塊好好經營的人也不多。劣幣驅逐良幣，優秀的高校人才往往被熱錢推動去一窩蜂忙著搞直播、**等短期逐利專案。圍繞流量跑，趨之若鶩，不過冷靜下來想想，這塊對社會和產品公升級的好處會有多少，資本逐利，風險大、周期長的晶元、硬體投入無人問津，反倒一杯奶茶、奈雪、喜茶等排隊上市，結合最近****對各大網際網路巨頭狂炒**事件的冷處理，可以看出真該好好學習霍尼韋爾、江森、西門子這些企業是如何在ddc控制器、plc可程式設計器件上大力投入的。想起三星當年從低端食品企業，勒緊腰幾十年帶搞晶元，才有了今天電子帝國的地位，牢牢把控上游話語權。
智慧型產業的未來還離不開一代人甚至更多人的努力，洗去鉛華,方顯真諦。共勉。
IOT智慧型建築實踐系列 一
iot智慧型建築需要將大樓 園區等建築內的裝置智慧型化 數位化 直白講就是將建築內的各種真實裝置 第三方系統連線的裝置整合起來，實現對裝置的控制 裝置資料的採集 最後將採集到的資料實現資料分析 大屏展示等上層業務。我們將業務架構分成三個層，從下到上分別為 對接層 業務層 iot平台層 每層實現各自不...
河姆渡智慧型建築專家支招 如何「機智」的解決機房工程
大家都知道，弱電機房工程建設的要求越來www.cppcns.com越高了，有些新人可能對這方面不是很了解，今天，河小妹來跟大家分享一下關於機房工程的一些乾貨，大家一起交流學習 以下，請看 機房裝修地面 牆面 吊頂 每個環節都有要求 具體如下 供配電系統機房供電採用 電壓 頻率 和三相五線制配線方式 ...
基於CAN匯流排智慧型建築監控系統的通訊協議設計
現代智慧型建築監控系統廣泛採用了現場匯流排技術。現場匯流排的種類目前有40多種，但適合智慧型建築且在我國推廣的主要有兩種 can control area network 匯流排和lonworks匯流排。can匯流排技術以其可靠性高，結構簡單，傳輸距離長和成本低而具有巨大的應用潛力。控制區域網can...