在周末的上午，坐在五道口Starbucks咖啡廳里，慢慢啜著稍帶苦澀的冰美式，嚼著偶爾從吸管里吸上來的焦糖粒，目光停留在玻璃窗外來回穿梭的車輛上，心緒散漫…很久沒有這么悠閑和放松了。記得***次喝星巴克的美式(Americano)咖啡，貌似是2004年，在中東的巴林做項目，跟客戶交流的時候。當時也是周末，交流地點就定在一個星巴克咖啡廳里。有兩個客戶，名字都很阿拉伯化，一個叫做Ahmad(貌似翻譯為艾哈邁德)，另外一個叫做Mohamod(莫哈默德)，分別是巴林電信的CTO和副總裁。當時交流的內容，是如何把客戶基于電路交換的電話網(PSTN)，演進為基于IP承載的NGN。十年過去了，現在貌似還是做著同樣性質的工作，不過內容變了，是如何把客戶的IP網絡，演進為SDN。

 [[148553]]

本文的主題仍然是物聯網操作系統，上面的內容純粹是作為引子，與本文后面的內容沒有任何邏輯關系。如果非要找出一點聯系的話，那么只能是哲學層面的聯系了，那就是任何事情都在變化和演進，永不休止。物聯網領域也是這樣，雖然至今未成氣候，但是其架構演進的速度，或者說“折騰”的速度，一點也不比電信網絡慢。最初的時候，物聯網被定義為三層架構，即所謂的傳感層，網絡層，后臺支撐層。很多公司或組織，按照這種結構推出了產品，比如愛立信，推出了基于其核心網平臺的EDCP(貌似是愛立信設備連接平臺)，***制放大網絡層的功能要求，因為這是其客戶-電信運營商關注的領域。很多電信運營商，也被設備商忽悠，投資建設了遵循這三層架構的物聯網平臺，結果虧得一沓糊涂。后來，物聯網公司，比如BAT等，發現物聯網是一個潛在的市場空間，于是切入進來，按照互聯網思維來做物聯網，于是物聯網又被這些互聯網巨頭定義為兩層，即終端層和平臺層。其中終端設備直接與平臺層鏈接，弱化了原來架構中的“網絡層”。在這種結構下，互聯網公司提供平臺服務，這樣就面臨一個問題，如何讓海量的，種類各不相同的終端，接入到互聯網公司的平臺呢?在沒有標準可以遵循的情況下，只有兩條途徑，一條是把平臺做得足夠大足夠好，形成事實標準，形成壟斷效應。但是物聯網行業是發展初期，很難形成這樣一家獨大的平臺，于是就只能采取第二個途徑-結盟，說白了就是平臺廠商和終端廠商聯合起來，定義一個私有的標準，然后自己玩。最普遍的表現，就是互聯網公司與家電廠商結盟，比如小米和格力，海爾與阿里，等等。結盟模式是最不利于行業發展的，尤其是在行業發展的初期。結盟的結果，是形成了一個個小的，封閉的領域，因為聯盟之間的標準不同，相互之間不能交互，其結果可想而知。

在電信行業混了這么多年，深知這個行業的諸多弊端會嚴重阻礙物聯網的發展，因此我個人更傾向于互聯網公司來做物聯網。但互聯網公司采用結盟的方式，卻是非常不合適的。為了克服結盟的弊端，必須在終端和平臺之間，插入一個”中間層“，把這種強耦合關系打破。這個中間層，就是物聯網操作系統。

物聯網操作系統的概念，是與電信行業的幾個同仁交流后提出的，起初的目的，并不是解決互聯網與終端廠商結盟的問題，而是站在運營商的角度上，試圖解決運營商網絡在物聯網領域面臨的挑戰。一個典型的場景，就是智能抄表解決方案中可能導致的無線網絡信令風暴。考慮一個安裝了百萬電表級別的城市，所有電表通過運營商的無線網絡連接到抄表平臺。在月底的時候，同時上報抄表數據，這時候大量電表同時產生的無線信令，會把運營商網絡搞垮。于是希望在終端層面，嵌入運營商提供的操作系統，操作系統中內嵌定制化的網絡訪問規則，把并發的大批量的網絡訪問，變成平緩的分散訪問。

后來隨著與更多的業內人士交流和碰撞，對物聯網操作系統的概念做了進一步的思考之后，重新定位為解決上面描述的結盟問題。在2014年的一篇文章中，對如何解決結盟問題，以及物聯網操作系統的整體框架，做了詳細描述。這個定位和框架，引起很多業內人士的共鳴，大部分持認同態度。

具體來說，在缺乏標準的情況下，要打破結盟的有效措施，就是軟硬件分離。終端廠商只聚焦終端功能的開發，這是他們的強項。把終端功能通過操作系統API的形式暴露出來，提供給軟件APP調用。比如一個智能開關，只要通過API，提供開關打開，關閉，調節電量，網絡連接等功能。具體什么時候打開，與其它家電設施如何聯動，如何形成有價值的智慧家庭解決方案，則是智能家電平臺廠商要做的工作。平臺廠商開發運行在智能開關上的應用程序(APP)，調用智能開關提供的API，實現智慧家庭功能。由于具體的通信協議和業務邏輯，是由平臺廠商自己實現的，因此就不存在強綁定的問題。智能開關的用戶，可以通過更換APP的形式，來更換智慧家庭服務提供商。這種模式與智能手機是一致的，可以通過安裝或卸載APP，來靈活選擇電子商務提供商。但是物聯網終端與PC不同，不像PC這么標準，有固定的架構和指令系統，物聯網終端的架構多種多樣，CPU更是千變萬化。為了確保同一款APP能夠應用在多種多樣的硬件上，必須采用硬件無關語言來編寫APP。比如Java，比如Python。當前HelloX操作系統采用的是Java語言。

物聯網的另外一個特征-碎片化，也是物聯網操作系統必須要解決的。所謂碎片化，是指物聯網終端的硬件配置各種各樣，比如內存配置，從只有十幾K甚至幾K內存，到數十M或數百M。再比如外圍設備，有的僅僅具備簡單的傳感和網絡功能，而復雜一點的終端，則具備完善的Ethernet或LTE連接支持。碎片化會導致企業開發成本的劇增，因為你必須為一些終端選擇低端的操作系統，為另外一些終端選擇相對高端的操作系統。這些操作系統提供的工作機制和API都是不同的，這樣就會導致企業無法共享開發和維護經驗，無法共享代碼和人力。物聯網操作系統必須要解決這個問題。目前來說，可能的解決方案，就是可裁剪性。同一個操作系統，通過裁剪或動態配置，既能夠適應低端的需求，又能夠滿足高端復雜的需求，而共享相同的工作機制和API，以及開發工具。

在滿足上述兩個條件的前提下，物聯網操作系統還必須能夠支撐物聯網的另外一個重要特征-本地協同。舉例來說，智能開關應該可以與智能電視協同，在智能電視被關閉后，應該能夠通知智能開關，以切斷電源，節約電量。這包含了本地設備發現，能力交互，工作協同等幾個相互關聯的要素。很多協議或標準可以支撐這種操作，比如AllSeen聯盟搞的AllJoyn標準等。物聯網操作系統可以自己定義相關交互規則，也可以直接集成AllJoyn等。總之相對上述兩個特征，支撐本地協同要簡單得多。

說了這么多，就是試圖對物聯網操作系統做一個定義。并不是所有的操作系統都是物聯網操作系統，只有滿足上述三個特點，即能夠支持軟硬件分離，支持碎片化特征，支持本地協同的操作系統，才算是物聯網操作系統。這只是個人的理解，不同意見的朋友，可以探討交流。只有本著開放合作的態度，找到***公約數，然后逐步擴大這個***公約數，才能慢慢的把一個行業做好。需要注意的是，這里強調的是“開放合作“，而不一定非要”合作共贏“。經濟學中有一個著名的概念，叫做”帕累托改進“，是指在參與經濟活動中的多個player之間，任何一個player經濟利益的擴大，只要不會導致其它player的利益降低，都叫做帕累托改進。因為這種改進，會導致整體經濟效益的改進。在物聯網領域的合作，我們也建議遵循帕累托改進的原則。另外一個觀點就是，物聯網操作系統必須是中立的，即不傾向于支持任何廠商的終端，也不傾向于支持任何廠商的物聯網后臺系統。同時，物聯網操作系統必須要開源，以展示開放和中立。

物聯網操作系統的概念似乎得到了越來越多的認同。這幾天，華為在一個SDN大會上，發布了叫做LiteOS的物聯網操作系統，主要支持自有的芯片和物聯網終端，并內置私有的協議，與自產的物聯網網關進行配合。實際上，在2014年的行業分析師大會上，華為就公布了開發物聯網操作系統的想法。但是如果用我們上面定義的三個特征來匹配，就會發現華為發布的操作系統，不滿足上述全部特征。首先，從目前能夠拿到的信息來看，LiteOS并不能支持軟硬件分離，也不能保持中立性，因為其目的，還是希望對自有芯片進行更好的支持，同時與自產的物聯網網關進行配合，有很強的傾向性。雖然宣稱要開源，但是至今尚未看到其源代碼。實際上，我個人是很期望華為能夠發布一款真正的物聯網操作系統的。依托操作系統，建立一個完整的產業鏈，從而促進行業的發展。依華為的實力和品牌，完全可以做到這一點。但是對LiteOS的發布，卻有一些失望的情緒，首先其名字，就不太合適。物聯網操作系統可不能僅僅是Lite，而應該能大能小，小可以Lite，大則可能比通用操作系統還要復雜。但LiteOS未來的發展如何，目前下結論顯然太早，還需要長時間的觀望。個人仍然期望LiteOS能夠真正發展起來，改變筆者對Lite長期以來形成的貶義印象。

另據國外媒體報道，Google也將在近期的I/O大會上，發布一款物聯網操作系統Brillo。剛看到這則新聞，我心中的沖擊是很大的，顯然，Google認識到了Android不能適應物聯網的需求，終于另起爐灶了。但是看到報道中描述的細節，Brillo還是依托Android的內核開發，能夠適應32M到64M的內存要求，我個人又失望了。顯然，依托Android框架，采用Java語言實現軟硬件分離，完全滿足物聯網操作系統支持軟硬件分離的特征。但是卻不能支持碎片化特征，顯然32M以上的內存要求，就把絕大多數物聯網終端排除在外了。因此，個人不認為Brillo能夠像Android一樣，一統物聯網領域。但結果如何，還是需要實際表現來說明。

另外，騰訊也發布了用于物聯網領域的操作系統TOS，但是其內核，仍然是基于Android，還不如Brillo。還有一些其它的物聯網操作系統，就不一一評論了，朋友們可參照上面的討論，自行印證一下。

***，還是要說一下HelloX項目。顯然，HelloX操作系統是必然滿足上述討論的物聯網操作系統的特征的，因為我們就是按照上述特征，來開發HelloX的。對于軟硬件分離的支持，HelloX通過移植一個業界廣泛使用的嵌入式Java虛擬機JamVM，通過Java語言來實現。這種實現方式，與Android通過Java語言是實現APP與硬件的分離原理是一樣的，無需多說。對于支持碎片化特征，HelloX的伸縮性非常強。可以在編譯時，裁剪掉不需要的模塊，來匹配低端硬件的需求，當前可以裁剪到只需要十幾KRAM的級別。顯然，這時候是不能支撐Java虛擬機的，在這種低端硬件上，功能往往比較單一，也無需支持Java。對于高端硬件的支持上，HelloX目前可以支持服務器級的硬件，比如，HelloX曾經在Dell PowerEdge級的服務器上運行。另外，HelloX是完全中立的，沒有任何硬件的傾向性(也無法傾向，因為我們沒有硬件J)，更沒有任何平臺傾向性。實際上，對任何平臺的支持，在HelloX上都表現為一個特定的APP，可以動態安裝和卸載。另外，代碼完全開源，目前托管在github上(github.com/hellox-project/HelloX_OS)，任何人可以下載和修改。

我們的目標，是開發一個能夠支撐物聯網產業發展的基礎軟件平臺，來促進產業的發展，提升人們的生活質量。目前HelloX項目還在開發過程中，歡迎有興趣的同仁參與我們。

***再澄清一下，本文的內容和觀點，僅僅是一家之言，供業界同仁討論和碰撞。相信我們的目標是一致的，都是為了更好的促進行業的發展，在這個過程中實現自己應有的價值。另，如果希望轉載本文，請注明出處和作者，以及聯系方式，以供討論之用。