早在1999年就已經有了“物聯網”這個概念，但是直到十年之后的2009年，IBM提出“智慧地球”的概念，才推動很多國家把物聯網研究和發展提升到戰略層面。但是比較遺憾的是，直到現在的2015年，我國的物聯網的發展依然主要靠政府項目來拉動，所以現在的發展似乎前景越來越不明朗。

　　政府似乎意識到這是個問題，在一些互聯網公司的倡導和推動下，提出了“互聯網+”的概念。雖然“互聯網+”和“物聯網”都是以網為主，但是發展的側重有了本質區別?！盎ヂ摼W+”是以互聯網為主，外圍智能模塊和傳感器為輔，構建互聯生態。而“物聯網”卻是以互聯網為基礎，重點在傳感器數據采集，設備控制，遠程監控為主。

　　但是現在很多互聯網公司，做的是“互聯網+“的事，卻以”物聯網“的名義來宣傳。所以現在的人越來越搞不清”物聯網“的真實定位了。

　　我一直認為從技術角度來看，所謂“物聯網“就是傳統工控網的一個外延。傳統的工業現場，考慮到生產安全，都是內部網絡。另外實施和維護的代價相對較高。而在互聯網和移動互聯網越來越完善的今天，在各個領域都有了遠程測控的要求。比如目前比較典型的農業大棚監控、森林防火監控、魚塘監測和養殖管理等等。

　　“互聯網+”和“物聯網”由于發展的側重點不同，在做架構設計上肯定有所不同?！盎ヂ摼W+“的項目，其實更看重的是用戶數，通信數據流量，這是衡量一個”互聯網+“項目成功的標志，當然這是也是那些做云平臺為主的互聯網公司最看重的，用戶數和通信數據流量正是他們的利益點所在。

　　而以中小項目為主的“物聯網”項目，其實更看重的，一是系統穩定可靠，能保證系統長期穩定的運行，因為有些監控點往往部署在人跡罕至的地方，系統的可靠性成為關鍵。二就是系統便于開發和維護，因為基于不同行業，不同工藝需求的，很難開發出像民用領域的通用產品，需要根據現場實際調整相關的業務邏輯和監控畫面，所以是否易于開發很關鍵。當然維護更為重要，因為偏工業級的“物聯網”項目一般設計至少是三年或更長的生命周期，所以項目維護難以避免，甚至系統還會根據現場工藝的變更進行變化，易于維護是“物聯網“項目一個不可或缺的要素。

　　由以上的說明，我們可以很清晰地了解，從技術角度來講，做“互聯網+”和“物聯網”項目的架構設計是有很大的不同，本篇文章主要介紹工業級“物聯網”項目的架構設計及實施。

　　工業級物聯網的概念和特色

　　由于筆者曾經在傳統工控領域工作7年之久，所以理解“物聯網”更多是從工控的角度來考慮。所謂的工業級物聯網，不是工業領域的物聯網，而是具備工業領域的特色的物聯網項目，比如農、林、牧和漁業等領域的相關項目。和工業領域的項目不同，沒有那么龐大和要求嚴格，采集和監控的數據也相對較少，對設備、及實施和維護的成本比較敏感，并且一般要求遠程監控。但是相同的要求是，設備要穩定可靠，便于根據工藝要求調整控制策略，方便升級、擴展，易于維護。

　　傳統工控項目，一般相對龐大，環節多，開發和實施周期都比較久，當然項目的費用也是相對高昂的。往往一個實施工控項目的公司，一年能做十幾個這樣的項目就已經很繁忙了。而在物聯網時代，由于互聯網和移動互聯網基礎設施比較完善，云服務公司也是層出不窮，可以花最少的代價，相對快速的完成一些項目。

　　由于開發和實施的代價大大降低，所以可做的領域被大大拓寬了，形成了一個良性循環，做的越多，越可靠，也越便宜。越便宜，可做的項目也越來越多。

　　工業級物聯網項目架構設計思想

　　了解了工業級的物聯網項目的一些特色，所以架構設計方面就有了方向和思路。我們先從技術角度分析，當前一個典型的物聯網項目，從組成上來講，至少有三部分：一是設備端，二是云端（主要指公有云），三是監控端。

　　【設備端架構設計】

　　設備端主要負責數據采集，工藝邏輯執行及控制。

　　無論底層的設備數量有多少，通信協議有多復雜，考慮到項目安全等等因素，往往和云端通信，匯集在一個設備上，這樣的設備的角色往往是物聯網網關，除了專門負責和云端進行通信外，有時候也會對原始數據進行一定的處理，執行一些業務邏輯相關的代碼。 和云端通信有很多協議可選，常見的有基于HTTP協議的Get或Put方法，從服務器獲取一些設置及狀態，及向服務器推送采集到的數據。但是對數據量相對比較大，實時性要求高的，往往是直接的Socket TCP/UDP通信，這樣傳輸的代價相對較低，但是對編程設計方面要求比較高。

　　由以上分析，從功能層面上分，設備端架構一般可分三層，一是數據采集&控制輸出層；二是工藝流程執行層；三是數據上傳&命令接收通信層。

　　【云端架構設計】

　　云端一般包含三部分：Web前臺+ Web后臺+中間件；

　　作為工業級的物聯網項目，Web前臺一般會顯示這幾部分內容，一是工藝畫面，和現場實際的設備和工藝流程一一對應，畫面可以實時反映工業現場運行的情況。二是各種數據報表、曲線數據的保存、查詢和打印等。三是運行日志，保存各種運行情況，以備查詢。四是顯示系統診斷信息，便于系統出現問題的時候，及時判斷問題所在。

　　Web后臺相對復雜一些，一般完成三部分內容的工作，如果是設備端基于HTTP協議通信，往往需要處理Get和Put請求。由于前臺有實時畫面，所以Web后臺有時候也需要向前臺界面傳輸實時數據，目前有些實時數據是通過Web Socket協議進行傳輸，也可以由專門的程序來處理。還有一部分功能比較重要，就是要建立設備數據和各種報表，曲線，日志的對應關系，以便于適用盡可能多的現場。

　　在工業級物聯網項目中，一般中間件必不可少，其主要功能就是負責和現場設備進行通信，獲取數據或發送相關控制指令。此外還有一個比較重要的功能，由于中間件程序一般是作為系統的一個服務程序或普通應用程序，生命周期較長，可以長時間連續運行，可以處理一些相對復雜的業務邏輯、數據換算及數據轉儲。

　　【監控端架構設計】

　　監控端一般包含PC、手機或平板監控。

　　對一般項目而言，也許通過Web前臺就可以掌控一切了，但是在移動互聯網的時代，如果對應的手機或平板上沒有對應的APP，那這個項目就感覺有了一個很大的缺憾。有了手機或平板APP，就可以身在任何地方，都可以相對方便的監控現場。

　　從功能上劃分，架構可以相對簡單的分為兩層，一就是UI界面顯示及操作層，二就是數據通信層，實現和服務器信息交互。

　　【小結】

　　如果拋開其他一切因素，僅從技術角度來講，實現以上三個大環節的功能，用什么系統平臺，任何開發語言都可以完成其預定的功能。但是所謂的架構設計，不僅僅從功能角度來設計整個的系統平臺，更多還要考慮其可靠性，擴展性，維護性等幾個方面。

　　作為工業級的物聯網項目，大都是面向工、農、牧、漁等具體行業，每種行業雖然從技術角度而言有很多類似的部分，但是從工藝流程角度又有很大的區別，所以針對具體的項目，進行代碼調整及相關功能的擴展及二次開發必不可少。但是面向一線的工程師往往技術水平及能力相對比較低，能否快速編寫出可靠、健壯的代碼顯的非常重要，畢竟每個項目現場實施時間是有限的，但是同時項目要求也是比較高的。

　　另外一個物聯網項目，包含了嵌入式設備的開發、Web前后臺的開發、服務程序開發還有手機和平板程序開發，每一項從技術平臺上來說各種各樣，比如嵌入式設備，有微軟體系的Windows CE/XPE/.NET Micro Framework,有linux體系的嵌入式linux/uclinux等等，還有uCOSII/FreeRTOS/mbed OS等等實時嵌入式操作系統，其開發工具，系統架構各不相同，各有特色。手機和平板目前至少也有三種開發類型，一種是iOS開發，一種是安卓開發和windows 10 UWP通用程序開發等等。另外Web開發就更多了，這里就不一一舉例了。

　　所以如果在整體架構設計中，每種部分都選用不同的技術路線，那么每一種技術路線，意味著都要有一個團隊去開發，并且開發完畢后，還需要上下進行溝通，以便于把整個項目有機地聯系在一起。

　　開發完畢后，更多的還有維護工作，不僅是開發團隊的維護，更為重要的是現場維護，除了問題，如何及時定位，及時解決。針對如上問題，加上多年的現場實施和維護經驗，所以我更看重統一化和組態化的架構設計，下面我就講講我們是如何構建物聯網項目的。

　　物聯網通用中間件平臺架構設計

　　由于是一個物聯網通用中間件開發平臺，所以著眼點并不是一兩個非常有行業特點的項目平臺，而是面向不同行業，不同具體應用的二次開發平臺，更多考慮跨行業應用的技術通用部分及同一個運行時平臺支持多個項目點的功能。

　　下面我們就設備端、云端中間件及物聯網通用平臺分別進行介紹。

　　【物聯網嵌入式數據組態YFIOs架構設計】

　　在工控領域，組態軟件司空見慣。為什么很多工業項目采用組態軟件，原因主要有兩點，一是模塊化搭積木式的設計，技術門檻低，實施速度快，非常適合工控技術人員使用；二是可靠性非常高，由于模塊之間耦合性低，重用度高，并且每個模塊往往在不同項目現場，實際都得到過運行考驗，所以穩定性自不待言。

　　YFIOs的設計思想就來源于標準的組態軟件，但是又具備了一些物聯網時代的功能特色。

　　YFIOs包含三大部分：驅動層、策略層和核心層。

　　底部驅動層支持大部分物理通信接口，主要功能就是和傳感器（或智能模塊）通信，獲取相關的傳感器數據及發送控制執行指令。

　　上部策略層除了加載執行一些系統策略（如系統通信策略）外，還可以加載用戶策略，這樣可以基于現場工藝流程，立即就可以進行相關的工藝控制操作，不用送到服務端，等服務端遠程發出控制指令。

　　中間核心層是最關鍵的，除了啟動驅動和策略引擎外，還創建了兩個內存數據庫。一個是IODB，主要存放點數據（如溫度、濕度數據），另外一個是IOBC，主要存放塊數據（如攝像頭圖片）。策略程序和驅動程序，完全解耦合，通過IODB和IOBC進行數據交互。

　　和傳統組態軟件（特指數據組態部分）相比，YFIOs有如下特色：

　　基于.NET系統進行驅動和策略開發，由于系統自帶垃圾回收機制，不用擔心在編寫驅動和策略過程中，因內存溢出等原因導致系統當機。

　　傳統的組態軟件一般對外不提供驅動開發SDK，即使有，大都也采用C++進行開發，對開發者要求比較高。YFIOs和傳統組態軟件不同，驅動可以采用C#和VB.NET進行開發。且驅動有多種運行模式，不僅系統可以調用，用戶策略也可以調用。還可以綁定策略事件，通過觸發的方式去執行指定的策略。

　　YFIOs的驅動可以動態替換，如果配置了相關的連接變量，只要驅動變量接口兼容就可以替換，這大大降低了系統運行后的維護成本，外圍的硬件設備可以根據需要進行替換。

　　YFIOs系統支持遠程升級和遠程調試。支持三個層面升級，YFIOs運行時升級、YFIOs驅動和策略升級和YFIOs配置升級。

　　針對設備端，我們也設計了基于物聯網畫面的組態軟件YFHMI，由于這部分其實和傳統的畫面組態區別不是很大，所以這里限于篇幅，不再介紹了。

　　【物聯網云端中間件YFCloud架構設計】

　　云端YFCloud中間件平臺，可以說是完全脫胎于嵌入式YFIOs，從圖2的架構圖上就可以明顯看出，可以這樣說，YFIOs是一個“單機版”的數據組態平臺，而YFCloud是一個“網絡版”數據組態平臺。

　　YFCloud和YFIOs都可以運行策略程序和創建IODB內存數據庫，不同的是YFCloud去掉了IODC內存數據庫，并且驅動層簡化為一種，就是TCP/IP通信接口,每一個遠程設備，服務器都會分配一個Socket連接，登錄成功后，才能正常通信。如果設備30秒上傳數據無變化，則發送心跳信號，否則60秒無數據收到，服務器會主動關閉連接。

　　YFCloud還集成了WebSocket服務器，Web動態網頁可以通過WebSocket協議和服務器進行通信。

　　YFCloud物聯網中間件平臺是以項目為最小單位來進行管理的，一個或多個項目對應一個項目模板，項目通過項目ID進行區分。由于是二次開發平臺，所以YFCloud提供了一個平臺級的開發接口，通過接口可以管理相關的項目模板和項目（如創建、編輯、刪除、啟動和停止等）。

　　【物聯網通用平臺架構設計】

　　YFIOs嵌入式數據組態運行在物聯網智能網關上，直接和YFCloud進行通信（云端中間件通過導入YFIOs的上傳IO表，就可以直接進行通信了）。

　　物聯網通用平臺的Web前臺，目前默認具備如下功能（每個項目模板可以根據需要，進行選擇所需要的功能，項目完全繼承了項目模板的選擇）工藝流程顯示、工藝報表（日報表，統計報表）、工藝曲線顯示、項目運行日志、工藝參數配置和攝像頭監控等等。

　　物聯網通用平臺的Web后臺，主要功能就是用戶管理、角色管理（和功能匹配的角色）、項目模板管理和項目管理。限于篇幅，就不詳細介紹了。

　　【小結】

　　該平臺的最大優勢就是，從軟到硬，全部采用了.NET平臺。所以不需要太多的技術人員，就可以從上到下進行項目開發。對客戶來說，由于涉及到的技術領域比較少，所以二次開發及后續平臺維護也比較容易。

　　物聯網項目案例簡介

　　【家庭遠程健康監控系統】

　　這是比較早的一個案例了。設備外接血糖儀、血壓計、攝像頭、溫濕度模塊，內部集成了RFID刷卡器及3G模塊。通過3G和遠程服務器進行通信，用戶或醫生通過網頁查看相關信息，其中醫生還可以遠程留言并發送到設備。采用組態式的架構最大的好處就是， 由于每個家庭已有的血糖儀或血壓計型號不同，設備可以根據對應的傳感器型號，選擇不同的驅動，可遠程部署驅動進行適配。

　　【農業大棚監控系統】

　　系統核心為物聯網智能網關，外部連接攝像頭、溫濕度傳感器，通過以太網、Wifi或3G路由器把相關數據推送到服務器。

　　客戶可以通過PC、平板或手機遠程監控蔬菜大棚中的作物生長情況。

　　【近海漁業監控系統】

　　通過水質傳感器，獲取當前水質情況（Modbus RTU通信）；通過攝像頭獲取當前圖片；通過GPS獲取當前經緯度；通過GPRS模塊把數據傳送到遠端服務器。

　　【村級污水處理監控系統】

　　物聯網智能網關通過RS485/CAN和智能終端連接在一起，智能終端采集各種數據，或控制相關設備運行。網關通過無線路由器或GPRS模塊向服務器發送數據，或者接收服務器的控制指令。

　　Web網頁可以查看現場工藝流程界面，工藝報表及設置工藝參數等等。

　　物聯網項目開發的未來發展方向

　　現在國內外互聯網企業巨頭，瞄準的物聯網領域，大都是民用領域，如智能家居、車聯網等等。這些領域的特點就是量大、并且相對統一，每個客戶不需要特別的定制（特別是硬件層面，區別不大，個性化最多在軟件層面）。

　　但是在非民用領域，即使類似的項目，往往因為最終客戶不同，工藝流程的差異，軟硬件也會有相對大的變動。另外和民用產品不同，一是應用環境相對惡劣，二是要求24*7連續運行，對穩定可靠性要求比較高，三是要便于擴展，便于維護。

　　所以這類物聯網項目，未來的發展方向，肯定是首先在可靠性上下工夫，滿足長期使用的需求后，就是盡可能提取共用部分，讓每個項目的修改量降到最低。

　　當然未來最有可能的發展方向就是，隨著現在分工越來越細，云計算發展的越來越成熟，物聯網協議標準的確立和客戶技術能力的提高，未來也許是在最終客戶的統一協調下，不同物聯網廠商各做一部分（或軟或硬），共同完成最終的項目。