最近幾年公司規劃了好幾個工業物聯網方面專案,由於前期團隊較小，資源有限比較少考慮技術復用和抽象的問題，後面隨著業務的不斷發展，團隊規模逐漸擴大，為了能夠更好的支撐後期業務的快速迭代和輸出，從整個研發體系出發不得不考技術沉澱，抽象復用的問題。
根據公司業務特性，抽象提取出針對於裝置連線、安全、資料分析和儲存等能力，形成公司技術沉澱和後期業務快速構建的基礎。提公升開發效率。
公司本身從事工業物聯網行業，所涉及的解決方案基本都會涉及到裝置的連線和監控，不同裝置具備不同的資料協議，在考慮對這塊能力進行抽象和提去的過程中，重點需要考慮裝置從連線到上傳，到雲端資料儲存和最終分析展現資料的整個環節。
針對具體使用場景分析如下:
場景一:
此處以企業**空調為例:作為物業的管理人員或是作為空調的運維人員，希望能隨時隨地檢視空調當前輸出溫度，本身執行溫度，連續執行時長，耗電等及時性的狀態。
場景二:
此處以城市智慧型照明為例:作為城市管理人員想要監控到當前各個街道的路燈是否正常執行，或是否在執行。當大霧或是夜幕能夠通過手工或是自動化的機制遠端開啟路燈
場景三:
此處再列舉乙個汽車例子:比如一輛小汽車，汽車使用者希望能時刻了解汽車的安全狀態，什麼時候該做保養，該加油，應該換剎車片，當前是否有行駛等。作為乙個汽車維修技師在為車輛做檢查時也需要能夠知道汽車的重要部件是否有更換，執行狀態，都希望能有一些資料以供維修參考。
以上的三個場景，理論上是絕大部分物聯網解決方案需要能夠支援，總結主要在於三方面:
1. 裝置實時狀態監控
2. 遠端裝置控制
3. 裝置資料分析
對於這部分能力的抽象主要從裝置的連線開始到最後裝置資料分析的整個鏈路做元件的抽象和提取，通過領域的邊界的確定從而劃分出對應的職責邊界。
在這裡通過前期的分析和多個專案業務共性的抽象,整體規劃如下圖所示:
前面主要描述了裝置端到雲端再到使用者端的整個過程，接下來根據目前的思路從裝置端抽象-雲端抽象-使用者端抽象進行分層介紹
接下來主要針對雲端處理做抽象的分析和介紹。
對於雲端的處理由圖可以看出來，主要分為5部分:iot hub、資料分析、裝置管理、規則引擎和安全；接下來將對這五部分做整體介紹和說明在每個物聯網企業中大家對於iot hub的理解可能存在不一樣的定義，在本設計中對於iot hub主要解決裝置連線的問題，因此也是成為了所有裝置連線的入口。
對於產品之間的對比如下
server
qos 0
qos 1
qos 2
auth
bridge
$sys
ssldynamic topics
cluster
websockets
plugin system
2lemetry✔✔
✔✔✔§
✔✔✔✔
✘jmqtt✔✔
✔✔✔§
§✔§✔
✔apache activemq✔✔
✔✔✘✘
✔✔✔✔
✔apache activemq artemis✔✔
✔✔✘✘
✔✔✔✔
✔bevywise iot platform✔✔
✔✔✔✔
✔✔✔✔
rm
emitter✔§
✘✔✘✘
✔✔✔✔
✘emqttd✔✔
✔✔✔✔
✔✔✔✔
✔flespi✔✔
✔✔✘✘
✔✔✔✔
✘gnatmq✔✔
✔✔✘✘
✘✔✘✘
✘hbmqtt✔✔
✔✔✘✔
✔✔✘✔
✔hivemq✔✔
✔✔✔✔
✔✔✔✔
✔ibm wiotp message gateway✔✔
✔✔✔✔
✔✔✔✔
✔jorammq✔✔
✔✔✔✔
✔✔✔✔
✔mongoose✔✔
????
????
?moquette✔✔
✔✔??
✔?rm✔
✘mosca✔✔
✘✔??
??✘✔
✘mosquitto✔✔
✔✔✔✔
✔✔§✔
✔mqtt.js✔✔
✔§✘✘
✔✔✘✔
✘mqttwk✔✔
✔✔✔?
✔✔✔✔
✘rabbitmq✔✔
✘✔✘✘
✔✔??
?rsmb✔✔
✔✔✔✔
✘✔✘✘
?software ag universal messaging✔✔
✔✔✘✘
✔✔✔rm
✘solace✔✔
✘✔§✔
✔✔✔✔
✘swiftmq✔✔
✔✔✔✘
✔✔✔✘
✔trafero tstack✔✔
✔✔✘✘
✔✔✘✘
✘vernemq✔✔
✔✔✔✔
✔✔✔✔
✔websphere mq✔✔
✔✔✔✔
✔✔??
?安全認證和許可權策略，更多的是整合在broker中,比如mqtt協議的伺服器，對於連線的認證，對於topic的發布和訂閱的許可權控制策略，包括黑白名單等均由此模組負責
資料分析模組主要負責裝置聯網後的所有資料的上傳，解析，儲存和分析。目前抽象出的幾個元件為訊息路由、協議解析、多級儲存、地圖定位；根據實際業務需要適當選擇搭配；
訊息路由：主要負責將接受到的訊息路由到對應的目標佇列或渠道，可以是乙個或多個，便於對資料的不同業務處理
協議解析: 主要負責解析從裝置端上傳過來的訊息，可能上傳過來的是二進位制、json、xml或自定義字串等，這裡主要是對訊息進行解析
多級儲存: 主要提供對於解析後的訊息做儲存功能，對於裝置的訊息可以支援多種儲存方式，比如mysql,mongodb,tsdb等，便於系統在整合時的適配
地圖定位: 主要負責解析或轉換裝置的地理位置，因為裝置很多時候不能定位或是gps不到導致定位資料缺失，此元件提供基於其他雲廠商地圖服務的基站定位，和位址編碼轉換功能，從而明確出裝置的具體經緯度和位址描述
裝置管理模組主要負責裝置註冊、數字孿生、裝置控制、ota公升級等,對裝置整體做管理和控制。
裝置註冊: 裝置註冊負責裝置連線前的新增註冊，同時提供對外介面便於業務系統根據實際進行裝置登記
數字孿生: 數字孿生是乙個抽象概念，意為在雲端構建乙個與實體一致的裝置模型，然後同步裝置狀態及動作，當需要操作裝置或是查詢裝置資訊時直接通過數字孿生裝置進行查詢或操作即可，形成與物理裝置一一對應
裝置控制: 裝置控制主要負責下發訊息給裝置，與裝置建立下達通道，確保通道暢通。同時記錄操作日誌，便於如其他模組整合
ota公升級：ota公升級引擎提供安全的ota公升級服務，基於補丁分發機制的雲端智慧型推送策略，解決ota公升級過程中可能出現的如資料篡改，韌體包偽造，鏈路劫持等安全風險。主要體現形態：自動公升級、手動公升級、強制公升級三種模式，單台公升級、批量公升級、全網公升級三種模式。技術上實現可通過連線通道，後端的定時任務和佇列進行組合實現。
規則引擎主要在於解析裝置協議，或是上傳裝置資料之後對於裝置資料終端狀態、時間進行過濾，提取出關鍵資訊然後通過對外介面(如廣播)進行公告。此處可通過整合第三方規則引擎再結合mq訊息佇列或是http外部呼叫方式擴散特徵資料。
使用者端抽象主要分為兩方面，一方面是對於蒐集到的裝置資料在使用者端的個性化呈現，另一方面是對於外部系統整合所能提供的開放介面，因此主要抽象出兩個元件，自定義報表和open-api
主要希望通過此元件能實現裝置的實時展示，或是對分析過的資料進行結果呈現；此處可選實現方案可繼承第三方的bi元件，或是開源的報表元件，如果前期對於資料暫時效果要求不高，推薦用grafana，這是乙個不錯的展示工具，支援多種資料來源，可以多維度呈現不同的業務或裝置資料。openapi模組更多的是為了對外暴露整個雲端能力介面，在open-api中需要能夠提供介面鑑權，限流，容錯，記錄等功能，
以上是近期對於物理網整體架構抽象的思考，或許還不完美，但是已經比最初不知道如何做好了很多，知識的積累在於不斷的學習、驗證、總結再學習、驗證、總結的無限迴圈。
物聯網平台
樂為物聯 可登陸使用，資料顯示分析 非開源 參考文件 樂聯網使用詳細手冊 樂聯網mqtt服務使用說明 yeelink 暫不可登陸 api list 開發者 api文件 移動onenet平台 開發文件 onenet定位為paas服務，即在物聯網應用和真實裝置之間搭建高效 穩定 安全的應用平台 面向裝置...
物聯網平台定位
物聯網平台定位為paas服務，即在物聯網應用和真實裝置之間搭建高效 穩定 安全的應用平台 面向裝置，適配多種網路環境和常見傳輸協議，提供各類硬體終端的快速接入方案和裝置管理服務 面向應用層，提供豐富的api和資料分發能力以滿足各類行業應用系統的開發需求，使物聯網企業可以更加專注於自身應用的開發，而不...
Ninja Blocks物聯網平台簡介
ninja blocks是乙個物聯網控制平台，其平台架構包括硬體層 處理器層 軟體層以及平台層，請看下圖 最底層是硬體層，包括感測器 sensors 和驅動器 actuators 例如溫度感測器 開關等，屬於這一層。處理器層是ninja block，ninja block是乙個物聯網裝置的閘道器，它...