簡介：多年SOA規劃建設，私有云PaaS平臺架構設計經驗，長期從事一線專案實踐

今天整理下我最近2到3年對物聯網雲平臺，智慧家庭和物聯網開放生態體系建設方面的文章。實際上我們看到從傳統的軟體雲平臺到物聯網雲平臺構建，整體思路雖然一致，但是仍然存在較大的差異，特別是在軟硬體環境的整合上面。

對於物聯網雲平臺可以先參考下機智雲或氦氪科技兩家的IOT雲服務平臺的一下參考介紹。

傳統硬體升級為智慧硬體，會在已有的近端控制，已有的感測器資訊採集能力上增加遠端控制和資訊採集能力。常見的在傳統硬體上增加wifi模組，4G或GPRS，Zigbee等遠端控制能力晶片。同時增加對裝置的遠端控制APP應用。

一個裝置的智慧化升級並不一定就需要閘道器，而對於一個涉及到多個智慧硬體組成的完整解決方案（例如智慧安防）則一定會涉及到服務閘道器這個硬體裝置。這個閘道器不僅僅是很好解決了安全隔離的問題，同時更加重要的是實現了多硬體Drvier層API能力的聚合，只有在聚合後才能夠更好的實現多個智慧裝置之間的聯動和協同，轉發和路由等能力。

在整個IOT大生態環境下，單個智慧硬體本身能發揮的價值會越來越小，而更加重要的是硬體和硬體之間的連結，通過這種連結後衍生了各種基於業務和需求場景的增值類物聯網應用。

一個最簡單的智慧硬體，需要有APP應用，公有云端Server和服務提供，升級了智慧硬體晶片的硬體這三個部分的內容。

把這個思考清楚後就可以看到一個物聯網的PaaS平臺應該是：

硬體+軟體能力聚合的一個平臺

簡單的說就是在將一個傳統硬體升級為一個智慧硬體的過程中，平臺層提供了更多的硬體+軟體層面的服務能力幫助你快速的完成一個硬體的升級改造。

從硬體層面：

提供本地化的開發環境，開發包等，協助你完成Driver驅動和驅動能力的暴露。即首先你在接入一個硬體的時候，首先你要註冊一個硬體裝置ID，同時再將這硬體的Drvier層能力註冊和釋出出來。

從軟體層面：

我們需要開發一個控制類APP或應用類的APP，那麼平臺需要提供一些開發框架和環境，開發工具包，同時更加重要的是提供平臺層共性和標準技術能力，這個技術能力包括了安全，資料庫和快取服務，訊息，儲存，CT能力呼叫等。提供這些技術服務能力的目的很簡單，讓我們能夠更加快速的開發和構建自己的APP應用。技術服務+Driver層暴露的API服務，兩者結合起來才能構建一個完整應用。

一個好的物聯網PaaS平臺一定是包括了開發平臺和執行平臺兩方面能力提供，首先是提供開發環境，框架和工具，協助快速開發和本地化調測，其次是提供執行平臺能夠將開發完成服務或應用進行託管和部署。同時在整個過程中我們需要提供DevOps的完整一體化從開發態到執行態（本身又包括了測試環境和生產環境）的遷移能力。再進一步，我們還可以提供運維階段的運維監控，資料統計和分析介面和能力。

傳統的軟體PaaS平臺強調的是APPID，而物聯網PaaS平臺關注的是裝置ID，而APP本身歸屬到裝置上。傳統的軟體PaaS平臺不會太關注服務的單獨註冊和釋出，服務的管理，而物聯網PaaS平臺則必須包括服務API的全生命週期管理能力。服務API是銜接硬體Driver和智慧應用APP間的重要橋樑。即物聯網PaaS平臺必須包括了類似OpenAPI平臺，雲服務匯流排或微服務閘道器等的相關能力並進行了整合。

對於物聯網雲平臺暫時沒有找到一個權威標準的定義，但是可以將其簡單理解為實現物聯網應用從傳統的客戶端轉移到雲端統一整合和管理的平臺。物聯網雲平臺和傳統的軟體雲平臺一個最大的區別就是物聯網應用不是單純的軟體，而是軟體+硬體裝置的結合，正是由於該原因，雲平臺必須提供裝置層的接入和資源管控能力。

物聯網軟體平臺最關鍵的功能：裝置管理、整合、安全性、資料收集協議、分析型別以及支援視覺化，有個網站對主流的物聯網雲平臺做個一個對比可以參考上圖。

可以看到，其中整合方式以Http Rest介面服務為主流，同時對於裝置資訊採集和訊息處理以MQTT為主流。當前對於阿里雲，百度，中國移動，包括類似京東，樂視，還有機智雲等都推出由自己的物聯網雲平臺。

對於這些物聯網雲平臺可以看到核心仍然是提供兩方面的能力：

裝置和Driver層API的快速接入，裝置效能資料採集和監控物聯網應用APP的設計，開發，測試，釋出，管理全部雲化能力

物聯網雲平臺本身不僅僅提供硬體資源池的Driver相關API的聚合能力，同時還提供對於應用層業務服務和內容服務的聚合能力，這也是和傳統雲平臺的一個區別。傳統的軟體雲平臺只涉及到軟體APP和雲平臺兩個部分的內容，而對於物聯網雲平臺則涉及到雲平臺，移動APP，物聯網裝置三者之間的協同和互動，這也是兩個雲平臺之間的一個差別。

對於一個真實的物聯網應用場景，對於在裝置端往往是一組裝置的管理而不是單個，同時在裝置端還需要具備離線和近場的管理能力。正是由於這個原因，往往在一個物聯網雲平臺的協同架構中，在裝置端還會增加一個物聯網的閘道器，做裝置資源類的API能力的聚合，近場的控制，簡單的控制組合等操作。

對於兩者的區別可以再看下百度IoT雲平臺的一個架構圖，如下：

在百度IoT框架中，IoT裝置啟動後要註冊到百度IoT雲。設備註冊成功後，雲端將裝置管理起來。在裝置活躍狀態下，雲端可以向裝置端下發監控命令，裝置端也可以主動向雲端上報資料。

從這個圖可以看到物聯網雲平臺在傳統IaaS和PaaS軟體服務的基礎上，增加了IoT的PaaS平臺服務能力，在百度整體架構圖裡面又將其分為兩個框，一個是和硬體裝置接入相關的PaaS層服務能力，一個是和移動APP軟體接入相關的PaaS層服務能力。

在這裡，對於裝置的註冊，接入，韌體Driver的下發和升級，裝置資訊採集，效能監控，裝置認證和安全等都是和物聯網場景應用相關的一些能力，這也是物聯網雲平臺和傳統雲平臺不同的一個地方。同時我們也看到一個物聯網雲平臺一定會提供對Open API介面的統一管理和監控能力，這本身就是一個輕量的服務匯流排，也是物聯網雲平臺必須要提供的內容。

以上內容都搞清楚後，我們基本就把物聯網雲平臺和傳統雲平臺的區別搞明白了。再簡單點來說就是物聯網雲平臺需要同時提供資源層（裝置接入）和應用服務層（APP+OpenAPI)全部雲端管控和治理能力。

物聯網閘道器

我經常會談到API閘道器，也曾經談過智慧家庭裡面的閘道器裝置，但是沒有專門談過物聯網閘道器，實際上對於智慧家庭閘道器本身也是屬於物聯網閘道器的範疇。對於物聯網閘道器，首先還是參考下百度百科給出的一個基礎定義，具體如下：

物聯網閘道器，作為一個新的名詞，在未來的物聯網時代將會扮演非常重要的角色，它將成為連線感知網路與傳統通訊網路的紐帶。作為閘道器裝置，物聯網閘道器可以實現感知網路與通訊網路，以及不同型別感知網路之間的協議轉換．既可以實現廣域互聯．也可以實現局域互聯。此外物聯網閘道器還需要具備裝置管理功能，運營商通過物聯網閘道器裝置可以管理底層的各感知節點，了解各節點的相關資訊，並實現遠端控制。圖l示意性地給出了以物聯網閘道器構建的物聯網典型拓撲。

在這裡面強調了一個關鍵重點，即物聯網閘道器來實現感知網路和通訊網路的互聯，但是感知網路存在多種不同的協議，比如Lonworks、ZigBee、 6LowPAN、RUBEE等，那麼要實現這種網際網路，閘道器就必須具備協議轉換能力。同時閘道器有兩個重點，就是既實現廣域互聯，同時在廣域網際網路不可用的時候，往往可以通過閘道器來實現區域網互聯，即近端的相互互動和協同。

對於物聯網閘道器的功能，主要包括：

1.廣泛的接入能力

目前用於近程通訊的技術標準很多，僅常見的WSNs技術就包括Lonworks、ZigBee、 6LowPAN、RUBEE等。各類技術主要針對某一應用展開，之間缺乏相容性和體系規劃。現在國內、外已經在展開針對物聯網閘道器進行標準化工作，如3GPP、感測器工作組，實現各種通訊技術標準的互聯互通。

2.可管理能力

強大的管理能力，對於任何大型網路都是必不可少的。首先要對閘道器進行管理，如註冊管理、許可權管理、狀態監管等。閘道器實現子網內的節點的管理，如獲取節點的標識、狀態、屬性、能量等，以及遠端實現喚醒、控制、診斷、升級和維護等。由於子網的技術標準不同，協議的複雜性不同，所以閘道器具有的管理效能力不同。提出基於模組化物聯網閘道器方式來管理不同的感知網路、不同的應用，保證能夠使用統一的管理介面技術對末梢網路節點進行統一管理。

3.協議轉換能力

從不同的感知網路到接入網路的協議轉換、將下層的標準格式的資料統一封裝、保證不同的感知網路的協議能夠變成統一的資料和信令；將上層下發的資料包解析成感知層協議可以識別的信令和控制指令。

這些基本的閘道器能力總結都沒有問題，但是對於物聯網閘道器，其中一個關鍵的核心就是閘道器本身是實現感知層和通訊層的唯一入口和出口渠道。外部只需要和閘道器打交道即可，而閘道器來排程和管控下面接入和註冊的各種型別的感知裝置。

因此閘道器有一個關鍵能力，類似API閘道器，即對於感知層各種感知裝置提供的不同型別的協議的接入和適配，同時在協議接入後能夠轉化為標準的介面協議和通訊層互動，對於實時的介面可以採用類似Http Rest介面，而對於訊息整合可以採用類似標準的MQTT訊息等。這也是我們原來談智慧家庭的時候經常會談到的物聯網閘道器更多的是硬體層的Drvier API的註冊和接入，包括後續的管理。

物聯網閘道器一般在架構和實現的過程中會提供一個硬體裝置來完成，這個裝置來實現協議轉換，路由，轉發，自動註冊管理，介面的北向和南向整合能力。這個閘道器一般是部署在區域網端的一個裝置，對於整體的雲架構來說，只需要這個閘道器裝置和雲端進行互動即可。

在前面我有文章談到過邊緣計算，可以看到對於邊緣計算的最終落地，完全可以在物聯網閘道器層來實現，即進一步提高物聯網閘道器的儲存和計算能力。一方面是實現自動採集資料在閘道器層本地採集後，經過二次加工再採集上傳到雲端，一方面是雲端的關鍵計算規則和邏輯下發到閘道器層，支援在閘道器層來實現本地化的計算。而這也將成為閘道器層能力的一個關鍵擴充套件。

物聯網裝置模型

物聯網系統的基礎架構模型，即雲+app+端整合架構。

雲平臺：部署在雲端的物聯網應用程式，除後臺管理外核心是實現資料資訊的採集和控制端：即我們常說的近端側物聯網裝置，包括物聯網裝置的近端組網和物聯網硬體閘道器應用APP：方便我們對物聯網智慧裝置進行管理的APP應用和服務平臺

而實際上整個模型裡面我們討論最多的就是近端的組網和聯動能力，近端的計算和儲存能力。因此會涉及到兩個關鍵，一個就是近端的硬體閘道器裝置，一個就是具備計算和儲存能力的邊緣計算裝置。相對而言，對於雲平臺和app應用來說並沒有太大的變化。

對於雲平臺端，一定會涉及到一個物聯網管理平臺，實現對使用者，裝置等基礎資料的管理，因此這篇文章來思考下一個後端的管理平臺應該如何抽象一個通用的模型。

對於一個物聯網運營平臺來說，最基本的該模型應該是一個支援多租戶架構的模型，每個租戶能夠完全實現應用許可權，資料方面的資源隔離能力。在這個明確後我們再來看模型的抽象，初步來看，我準備從位置模型，裝置模型，組織模型，許可權模型幾個方面來分開談。

位置和基礎設施模型

可以看到該模型是基於GIS地理資訊拓展的一個多層樹狀模型結構。從最頂端的行政區域模型，再到區域分類->基礎設施樓宇->分層分單元->具體的房間號->房內區域。這個層次模型應該要做到相當靈活的可配置能力，簡單來說我們推要給智慧校園專案和一個智慧公寓專案兩者之間應該是有差異的，但是核心的基於GIS地圖和位置資訊拓展本身是不變的。

即針對我們實際運營的專案，我們應該去構建這麼一個模型，究竟要建幾層你自己去定義，每層類別應該擴充套件哪些熟悉你也自己去定義。這樣才可能具備足夠的靈活和可配置能力。為何需要這個模型，因為最終的物聯網裝置我們需要知道究竟安裝和部署在哪裡的，即裝置最終需要和位置模型進行關聯，這樣裝置才具備了位置屬性。

組織人員模型

組織人員模型實際上和我們傳統業務系統中的模型相似，即這裡有兩個業務物件，一個是組織結構，一個是人員，人員最終是掛接在組織結構下面的。要分多租戶，那麼租戶就應該是組織結構樹的最頂層。組織結構樹本身也是樹狀結構模型，可以做到靈活的多層擴充套件，層次結構本身也沒有限制。

人員最終是掛接在某個組織節點下面，形成人員和組織之間的關係。方便後續的業務功能和資料授權操作。同時也方便對平臺的人員和使用者進行分組管理。

在智慧家庭的應用裡面，我們看到還有一個常規的組織結構模型裡面沒有的概念，即家庭模型，首先你有一個家庭的概念，家庭裡面有多個人，實際上在家庭裡面的裝置是可以被家庭裡面的多個人共享和管控的。因此家庭聚合層實際上是在組織模型裡面必須具備的一個組織節點層。

裝置模型

裝置模型實際上是我們談到最重要的一個模型，因為各類裝置的引數屬性配置都不應用，但是針對所有裝置有有一些通有的基礎配置。因此裝置模型本身應該是一個基礎配置+擴充套件配置模式的，對於擴充套件配置可以做到靈活擴充套件，自定義屬性，按需配置。

其次裝置模型裡面還需要包括兩種關係模型

裝置和子裝置：類似父子結構，而且我們需要管理到子裝置，但是子裝置不能脫離父裝置裝置組合：一套組合的裝置，既可以獨立存在，也可以形成組合提供更強大的功能

這兩種裝置關係也需要在我們進行裝置模型建模的時候統一考慮。要意識到裝置模型本身不僅僅是簡單的裝置基礎元資料管理，更是要用於後續的裝置接入，註冊，裝置能力提供，資料採集，監控等一系列動作。

整體說明

裝置屬於某一個位置，同時人員本身屬於某一個組織，同時位置和組織本身之間也有關聯關係。人員操控裝置，人員和裝置之間本身又建立關聯和擁有關係。

前面談到，對於物聯網雲平臺可以看到核心仍然是提供兩方面的能力：

裝置和Driver層API的快速接入， 裝置效能資料採集和監控物聯網應用APP的設計， 開發， 測試， 釋出， 管理全部雲化能力

物聯網雲平臺本身不僅僅提供硬體資源池的Driver相關API的聚合能力， 同時還提供對於應用層業務服務和內容服務的聚合能力， 這也是和傳統雲平臺的一個區別。 傳統的軟體雲平臺只涉及到軟體APP和雲平臺兩個部分的內容， 而對於物聯網雲平臺則涉及到雲平臺， 移動APP， 物聯網裝置三者之間的協同和互動， 這也是兩個雲平臺之間的一個差別。

今天重點談下整個物聯網雲平臺架構中的服務能力聚合層，在一個完整的物聯網端到端應用裡面，可以看到能力聚合層起到關鍵的承上啟下的作用。即物聯網的能力聚合層核心作用就是將底層各種物聯網雲平臺或硬體Driver層，硬體閘道器層的能力聚合起來，然後統一開放給上層的業務應用使用。或者將將硬體層的能力通過適配和接入後，轉變為標準的軟體介面服務，並以能力開放，比如OpenAPI介面的方式暴露給上層。

而這種介面服務能力的開放本身又涉及到北向介面和南向介面兩個方面的內容：

1. 北向介面：採集硬體層的裝置狀態，熟悉，健康指標等資訊。2. 南向介面：對裝置的各種控制資訊，Driver更新等通過南向介面服務，寫入到裝置層。

那這個時候做上層業務系統就簡單了，不需要去關注複雜的硬體層介面，而只需要使用標準的軟體API介面服務即可。而這個時候的能力聚合和介面能力開放類似標準的OpenAPI平臺或微服務閘道器的能力。簡單來說就是這個服務聚合閘道器需要的關鍵能力就是：

服務的接入和註冊，服務代理和釋出，服務安全和訪問控制，服務執行監控，訊息管理(MQTT)，流量控制，其次包括了最基本的服務元資料。如果是一個可運營的服務能力開放平臺，那麼就還需要多租戶管理，服務訂購，產品和訂單管理，計費管理等方面的能力。即在能力服務本身標準化後，服務本身也就是產品，是可以釋出出去進行訂購供外部業務系統消費，並進行計費的。

從物聯網大生態來說，那麼物聯網的服務能力聚合平臺一定不是簡單的接入和聚合硬體和閘道器Driver層的能力，更加重要的是聚合外圍周邊生態的軟體服務能力。而這些軟體服務能力本身包括了圍繞硬體層裝置的增值服務提供(安裝，維修），也包括了內容提供（音樂，視訊，食品配送）等。

從最簡單的服務能力聚合轉變到物聯網厚PaaS平臺能力提供

一個服務能力聚合平臺，發展演進到後面就會越做越厚，核心的原因還是我們前面經常談到的，你在實際應用場景實現過程中，會發現很多共性的內容，而這些共性內容按雲平臺的思路都應該是下沉的，即共效能力下沉然後以服務能力的方式向外暴露介面。而對這種共效能力本身又包括了技術共效能力和業務共效能力，業務共性和垂直行業類應用密切相關。

技術平臺：技術平臺解決技術共效能力，技術共性包括了典型的4A基礎能力，流程引擎，地圖，搜尋，訊息，快取，檔案等，這些能力和業務無關，可以在技術平臺統一規劃和提供。

業務平臺：類似於基於垂直行業業務中臺的概念，這類共效能力往往基於不同的垂直業務領域單獨規劃設計，將關鍵的業務場景和流程中的抽象業務模型提取出來，下沉到業務中臺資料模型中，形成共性化的業務介面服務能力後再向上層應用開放。

所有技術平臺和業務平臺中的各個元件完全可以按照微服務架構思想進行設計，每一個元件就是一個相對獨立，高度自治的微服務模組，可以進行獨立的設計，開發和部署運維。對於這種元件最終提供的介面服務能力也是接入和註冊到服務聚合平臺。也就是說對於技術+業務平臺，和服務聚合平臺之間本身也是一種鬆耦合的關係。

將物聯網能力聚合平臺按OpenAPI平臺的思路來做，這個OpenAPI平臺將成為整個物聯網生態裡面承上啟下的重要紐帶，同時開發相應的自服務門戶和流程，包括服務的自助接入和訂購，真正形成一個圍繞整個生態鏈上下游以聚合為核心的能力平臺。

物聯網雲平臺整體架構重新思考

近期會對物聯網雲平臺進行重新思考，首先還是要對整體架構做進一步的梳理。實際上在18年有不少的文章已經談到了物聯網雲平臺，包括和傳統的軟體雲平臺的差別等。

在重構物聯網雲平臺整體思路的時候，有些關鍵點簡要總結如下：

構建一個技術平臺容易，但是基於物聯網的業務和應用場景來構建一個運營服務平臺，或者說構建一個完整的生態則相對難，不僅僅需要技術能力，還需要對業務的深入理解能力，最外圍資源的整合能力。構建生態需要的更多的是開放心態，服務化驅動，系統思考。

物聯網雲平臺核心點還是在硬體Driver層的能力接入，即不僅僅是軟體能力，也包括了硬體能力接入，而硬體能力最終又轉變為軟體類的協議和介面，和軟體完成協同和控制。所以當我們將物聯網雲平臺的時候，一定是軟體+硬體融合的一個生態環境。

同時當我們將物聯網雲平臺提升到一個業務運營和服務平臺的時候，這個時候就不僅僅是技術平臺，更加重要的就是物聯網廠家下的硬體，軟體應用，內容服務等各種服務能力的介面抽象和服務能力聚合。即物聯網雲平臺不再單純是技術平臺，而是具備了強大的業務能力和內容服務提供能力的物聯網業務中臺。而作為這個業務中臺面向客戶和使用者的延伸，則可以是一個泛電商平臺。

泛電商平臺核心是電商平臺，但是將圍繞物聯網智慧硬體構建一個完整的電商生態，一個是前端的客戶關係管理和地推銷售，一個是後端的裝維和售後服務。電商本身提供產品和服務，而這個產品則是物聯網智慧硬體，物聯網應用軟體，而服務則是各種基於物聯網軟硬體的內容服務和增值服務能力。一切圍繞物聯網生態展開。這個生態將具備極強的外圍擴充套件能力。

常規的容器雲PaaS，技術中臺仍然是物聯網雲平臺的關鍵內容，這些內容支撐智慧硬體從接入到執行到後續運維監控的全生命週期流程。而裝置和軟體最終上線執行後，將轉變為電商平臺可以銷售的產品或服務。同時電商平臺完成產品銷售，本地化的安裝服務後，將形成真正線上執行的智慧產品。

手機APP端+智慧產品和閘道器+公有云服務中心三者本身又形成一個完整的閉環運作流程。而從公有云資料中心本身完成資料採集和處理後，為後續構建增值服務的大資料分析運營中心提供基礎。

物聯網開放平臺整體子系統劃分

物聯網發展的三個階段，即連線-感知-智慧， 第一階段是裝置接入，大量的內建了WiFi，ZigBee，藍芽，RFID等的智慧終端裝置被製造出來並連線入圍。第二階段是裝置狀態被感知，併產生海量資料，形成物聯網大資料，也是我們一直強調的資料形成積累是走向第三階段基礎；第三階段對產生的資料進行分析和機器學習，形成初始的人工智慧能力，實現使用者和商業價值。

物聯網應用領域相對廣泛，比如智慧城市和智慧家庭，車聯網，企業資產管理，工業網際網路，能源網際網路和泛在電力物聯網，智慧建築，智慧農業，智慧物流等。物聯網應用種類繁多，市場需求巨大。

平臺模式是企業主導的經營模式，而生態體系是建立在該模式基礎上的企業網路化協同整體圖景。Apple和Google的發展思路揭示了搭建開放平臺，在此基礎上建立生態體系，從而獲得巨大成功。

而實際上我們看到真正的重點在於首先平臺往往更多是技術層面的內容，而生態體系則涉及到諸多的外圍合作伙伴的參與和業務層面內容的提供。平臺更多提供的是資源和技術層面的能力，而生態提供的是業務，內容和服務能力。平臺提供商和生態提供商本身可以分離，各發揮優勢。比如我們可以基於阿里的物聯網雲平臺，構建上層的物聯網細分領域的生態體系等。

物聯網平臺型生態中的使用者型別包括平臺提供商，裝置供應商，應用提供商，內容和服務能力提供商，運營商，終端使用者等，相互之間形成一個完整的覆蓋物聯網硬體產品全生命週期的生態體系。特別要注意物聯網能力開放平臺包括了硬體裝置開發商和軟體應用開發商，硬體裝置開發商實現智慧裝置的開發和接入，軟體商實現應用，內容和服務的提供。兩者可以分離，也可以是同一個廠商。但是對於涉及到諸多物聯網裝置硬體大整合廠商，裝置組合聯動的，一般都為獨立的整合類開發商來完成。

物聯網開放平臺應用產品分類-應用類產品，裝置類產品，通道類產品，託管資源類產品，功能元件類產品，服務API類產品。

物聯網開放平臺總體架構

物聯網開放平臺主要是面向物聯網整個生態體系中的所有角色提供物聯網裝置和應用的快速開發，部署，能力開放，計費結算，服務運營能力的平臺。可以將物聯網開放平臺劃分為六大子平臺分別為裝置管理平臺(DMP)，連線管理平臺(CMP)，應用使能平臺(AEP)，資源管理平臺(RMP)，業務分析平臺(BAP)和應用中心平臺(ACP)。這個分發為作者的一個分發參考，非標準分法。

裝置管理平臺：對物聯網終端的遠端監控，設定調整，軟體升級，系統升級，故障排查，生命週期管理等，同時還可以實時提供閘道器和應用狀態監控告警反饋。而要做到這些，有兩個關鍵點，一個就是裝置模型的抽象，一個就是對裝置介面的抽象，這兩個是能夠實現對裝置全生命週期管理的基礎。

裝置接入過程，比如當前的智慧家庭裡面的各種智慧裝置，一般在家庭WiFi網路下可以實現裝置的自發現，在自發現裝置後再通過API介面實現在網際網路雲平臺的設備註冊和接入，設備註冊接入後設備管理平臺即可以通過相關的介面API對裝置進行各種管理。

裝置一般需要同時提供北向介面和南向介面，北向介面實現資料和狀態的採集，而南向介面實現雲端對裝置的狀態控制。注意在有物聯網閘道器的場景下，裝置一般會先註冊接入閘道器，而不是直接接入到雲端平臺，這個時候就需要建立裝置和閘道器之間的關係連線。同時雲端平臺也間接通過閘道器來實現對裝置的管理和控制。

連線管理平臺：一般應用於運營商網路上，實現對物聯網連線配置和故障管理，保證終端聯網通道穩定，網路資源用量管理，連線資費管理等。在這本書裡面講的連線管理平臺更多是和運營商相關的，而實際上即使無運營商介入也存在連線管理平臺。

應用使能平臺：提供應用開發和統一資料儲存兩大功能的PaaS平臺，架構在CMP平臺之上，這個和我們通常說的軟體PaaS平臺是一致的。一般的PaaS平臺能力服務層包括資料中心，應用開發測試執行環境，原子服務和能力中心，能力開放API，開發社群，以及安全管理和運營管理。

注意物聯網的應用使能平臺和傳統的PaaS平臺最大區別就是增加了和物聯網智慧裝置和終端的聯動，否則無法完成一個完整的開發測試工作，因此你首先要進行裝置的註冊和發現，裝置的接入，然後才可能讓你的裝置能夠和你的應用之間形成聯動並進行測試驗證。這是和傳統軟體PaaS平臺最大的區別，也因此裝置管理平臺實際上物聯網PaaS平臺不可分的一部分。

資源管理平臺：對應常說的軟體雲平臺裡面的IaaS資源池

應用中心平臺：該平臺為開發者，應用提供商，能力提供商，裝置廠商等提供功能元件，能力，應用服務，通道資源，託管資源，商品的釋出展示銷售，業務營銷，計費結算，客戶服務。可以理解為是一個產品最終入庫上架後的後生命週期管理平臺，類似一個物聯網電商平臺+運營平臺+售後服務平臺。

業務分析平臺：包含基礎大資料分析服務和機器學習兩大功能

和傳統的軟體能力開放平臺的區別，我們可以看到傳統軟體PaaS平臺一般為兩者聯動，即軟體使用者或APP和雲端SaaS應用的聯動，而在物聯網能力開放平臺下變成了三者聯動，即軟體使用者APP，雲SaaS應用，終端的智慧裝置三者之間的聯動。從子系統層面物聯網能力開放平臺在傳統的PaaS平臺基礎上增加了裝置管理平臺和連線平臺，其核心關鍵還是裝置管理平臺和傳統PaaS平臺間的整合和協同。

物聯網能力開放平臺和能力聚合，真正實現物聯網整體生態系統中的軟硬體一體化，資源內容服務一體化，物聯網裝置前後生命週期一體化，物聯網裝置和應用研發，運營和最終的運維管控的一體化。因此基於上面的各個子系統可以看到，裝置管理平臺和應用使能平臺實現軟硬體一體化，再加上應用中心平臺後實現研發運營交付一體化。這是相對不容易的事情。

物聯網開發生態和萬物互聯

在前面談物聯網雲平臺的整體框架的時候，實際上一直就在思考不僅僅是整體架構框架的重構，更加重要的是基於業務需求和業務場景對整體生態體系的重構。即通過物聯網雲平臺做為關鍵的技術能力支撐，泛電商平臺做為關鍵的業務和服務能力支撐來重構整個物聯網業務生態鏈。

這個生態鏈即需要實現從需求到最終產品交付使用的橫向流程貫通，同時又需要實現縱向的從硬體裝置層到雲平臺再到電商應用和APP終端的縱向打通。而所有的外圍生態都是圍繞橫向和縱向業務，資料和流程的全面貫通而展開。既實現了內部的完全整合，又通過服務聚合和能力開放來實現更大外圍生態。

前面一直在談萬物互聯。一方面是物物連線，一方面是物人連線，同時也包括傳統軟體應用中的人和人的連線。所有的連線都基於場景驅動，通過連線產生了直接的價值，同時通過連線形成大量的資料積累產生後續的大資料分析價值。

因此物聯網生態也可以講是一個連線生態，而這種連線除了我們常規談到的軟硬體技術，協議和應用外。更加重要的是人工智慧，即萬物互聯是第一，物化智慧是第二，沒有智慧的連線和應用無法靈活的匹配需求和場景，也無法帶來更大的增值服務價值。

基於以上關鍵思路，我們來看需要考慮的關鍵點如下：

構建面向外圍智慧裝置廠商的，覆蓋從裝置接入，執行，運營和運維管控的全生命週期支撐平臺。這個核心仍然是物聯網雲平臺，這個雲平臺本身也是物聯網雲能力開放平臺，更加體現了面向裝置廠商的自服務能力，裝置廠商基於平臺提供的標準規範，開發框架，基礎外掛，標準介面定義，接入流程，測試流程就能夠快速的完成自己裝置的改造和快速接入。

構建面向智慧平臺大B企業的端到端運營平臺，雲平臺完成最終的智慧裝置接入和上架，而運營平臺完成最終智慧裝置的推廣銷售，後續的裝維上線，上線的完整產品運營和管控。從大B企業到最終的C端客戶，從裝置訂購到最終的安裝上線，到後續的執行運維，實現完整的全生命週期管理流程。也實現整體運營平臺的端到端管理能力。

構建面向最終的C端客戶的從需求到交付的端到端支撐平臺，核心仍然是前面談到的泛電商平臺，提供智慧裝置，應用，內容，服務多方面的增值服務能力。覆蓋客戶從需求到消費使用的端到端流程，並形成完整閉環。

構建基於雲平臺+服務聚合開放+泛電商形成的外圍生態連線平臺，其中外圍生態包括了智慧裝置製造商，軟體應用開發商，內容提供商，第三方增長服務提供商，金融和支付，第三方物流等。該生態的整合一個關鍵就是服務聚合和能力開放，開放的能力又支撐外圍更多的合作伙伴接入。其次，就是我們看到這個生態裡面有三類產品，本身又是一個逐步演進和深入服務的關鍵。先是智慧裝置，其次是智慧應用，再次是基於智慧裝置和應用提供的各類內容服務和增值服務。

產品->應用->內容，從智慧硬體產品，再到最終的內容和增值服務，將智慧產品從最簡單的智慧控制功能轉化到內容服務提供，才是可持續發展的運營思路。

構建從建設過渡到運營後期的大資料分析增值服務能力平臺。平臺真正開始運營後，那麼一定能夠實際的採集到使用者使用智慧硬體產品的行為資料，消費習慣資料，而這些資料經過大資料採集，資料處理和分析後，形成上層的大資料分析平臺。通過大資料分析一方面是為第三方提供增值服務能力，一方面是通過大資料分析來改善我們前面的硬體接入上線，電商產品運營和針對性營銷的整個流程。使得整個平臺能夠保持持續優化和改進。

萬物互聯和資料賦能

對於萬物互聯，裡面重要的有三點：

連線-萬物互聯：物物連線，物人連線，硬體和軟體的連線，線上和線下的連線都可以納入智慧-資料驅動：連線後不是物本身智慧了，而是積累的資料通過分析後具備了智慧需求-場景驅動：做任何事情我們都需要有需求驅動，需求一定要依附於實際的使用者場景

在百度搜索，我們可以看下對萬物互聯的一個解釋

萬物互聯（IoE）定義為將人，流程，資料和事物結合一起使得網路連線變得更加相關，更有價值。萬物互聯將資訊轉化為行動，給企業，個人和國家創造新的功能，並帶來更加豐富的體驗和前所未有的經濟發展機遇。

在這個解釋裡面除了談到的人和物外，還增加了流程和資料，而流程可以理解為前面談到的關鍵業務需求和場景驅動，而資料則是真正的為人工智慧和分析決策服務。

萬物互聯僅僅是第一步，資料賦能才是真正的價值體現。

接著我們還是先談下萬物互聯裡面的一些核心

第一個要談的就是連線

這個連線大家很容易理解，首先要由物，然後還要由網路，最終就能夠形成連線。

這個物本身就包括了人，事物兩個方面。人和人，人和事物，事物和事物之間都可以產生連線。而事物本身又包括兩個方面，其一是移動事物，類似貨車，飛機，貼了條碼標籤的物品；一種就是靜態基礎設施事物，類似我們談到的家庭裝置，地下管線等。

而連線核心是網路，包括現在的5G網路和低功耗廣域網（LPWAN），能夠實現物聯網的部分應用需求。目前全球主流技術標準有兩個，一是華為主導的NB-IoT，另一個是國外廠商主導的LoRa。萬物互聯，就一定涉及到資料隨時隨地的採集和傳輸，而這就需要高效能高可靠的網路支撐，而這也是為何說5G技術的發展本身是對萬物互聯的一個巨大支撐。特別是對於實時的視訊影象採集和快速決策分析等。

在整個連線裡面還有一個關鍵物件，就是我們常說的物聯網採集裝置，感測裝置等。通過物聯網感測裝置讓物本身具備了可感知的人化能力。但是要注意我們的目標仍然是事物本身，而不是物聯網裝置，感測裝置僅僅是一個輔助我們萬物互聯實現的一個工具罷了。

第二談下流程和業務場景驅動

在原來我談SOA架構諮詢和介面服務識別的時候，經常會談到跨系統互動的端到端業務流程，其原因就是介面本身不是無緣無故就產生的，介面本身是為了滿足跨系統互動的業務流程服務的，是跨系統交付的業務流程產生了對介面的需求，產生了對業務系統連線的需求。

簡單的說就是，這種連線本身是有業務流程和需求場景支撐的。

在現在的萬物互聯定義裡面增加流程，是相當大的一個進步，即任何一個連線我們都要去思考為何需要存在，這個連線究竟是為哪個業務流程和需求場景服務。不要為了連線而連線，連線本身不是目的，而連線最終產生業務價值才是目的。

這也是我們在做物聯網應用和運營服務的時候必須要考慮的點，就是一定是業務和需求場景驅動，去考慮為了滿足業務流程和業務場景的需求，究竟需要形成哪些連線，採集哪些資料等。

最後談下資料賦能

對於物聯網和萬物互聯，連線本身不是目的，通過連線滿足業務需求，實現業務價值是目的。而這個業務價值的實現本身又包括兩個方面：

低層次價值：實時的滿足業務協同的需要，比如完成業務流轉，業務控制等流程。高層次價值：基於資料分析給出最佳輔助決策，或者能夠完全實現人工智慧自動化處理。

而我們這裡談的資料賦能更多的就是指讓資料發揮高層次價值，單個數據往往只能體現低層次價值，而大量資料的積累形成大資料後就能夠幫助我們進行人工智慧和輔助決策。因為只有足夠多的資料我們才能夠完全我們的機器學習和模型的訓練，使我們的決策模型具備更高的準確度。

大資料本身已經提出了很多年，但是人工智慧發展明顯延後，其原因主要還是體現在網路本身的發展上，資料採集和處理需要有強大的網路支撐，其次就是人工智慧本身就需要前期多年的資料積累參與訓練，這本身也有一個過程，而最近1到2年，我們也看到物聯網人工智慧發展的相當快速，因為所有的前提條件都已經具備。