從端到雲——工業物聯網項目全棧快速開發實踐

從去年伊始，國內外一些大公司都先后推出了面向物聯網領域的平台產品，如微軟 Azure 平台的 IoT Hub、阿里雲平台的物聯網開發套件、百度雲平台的物接入 IoT Hub、物解析 IoT Parser 和物管理 IoT Device 等等，但上述公司的產品從平台特色和技術角度來看，相對比較適合一些企業級項目開發及智能硬件的雲連接、雲存儲的使用，其實並不太適合一些對控制實時性較高、接入點多、業務邏輯相對復雜的工業領域。

工業自動化領域相對比較封閉，發展也比較慢，多年來涉及到通信相關的，大部分還是采用現場工業總線等技術來實現。筆者曾發過一篇《淺談工業級物聯網項目架構設計及實施》，里面除了介紹了工業物聯網的概念和特色外，還介紹了物聯網通用中間件平台的架構設計。時至今日，隨着國內外大公司的介入，物聯網越來越熱。下面筆者將結合工控領域的特色及當前物聯網領域的一些新技術新趨勢，分享工業物聯網和民用物聯網的特色及異同，並從自身實際應用開發的角度，解讀從端到雲，工業物聯網項目的全棧快速開發之路。

一、前言

1.1 民用物聯網 VS 工業物聯網

最近誕生的共享單車，短短一年多的時間就遍布國內一二線城市，迅速成為一個現象級應用，可以說是民用物聯網領域最大的應用。小米的智能家居套件，以低廉的價格，相對實用的功能，也贏得了不少智能家居愛好者的追捧，也是比較典型的民用物聯網應用。 
工業物聯網對大部分人來說，相對陌生，往往是面向行業的應用，比如我們當前所做的養殖物聯網監控，污水處理物聯網監控和垃圾處理物聯網監控。

那民用物聯網和工業物聯網的區別是什么呢？

從技術角度來說，民用物聯網和工業物聯網並沒有本質的區別，都是有雲、有端、都具備傳感器數據采集、設備控制及通信傳輸等功能。只是工業物聯網脫胎於工控自動化網絡，后者對可靠性和實時性有較高的要求，有各種工業級別的現場總線，如 Profibus，Modbus RTU/TCP，CANopen 等等，后續又在民用以太網的基礎上，推出了工業以太網。那時候還沒有雲的概念，考慮到安全，網絡都是私有的，很少和因特網進行互聯。從某種意義上來說，沒有雲技術的高速發展，就不會有現在的民用物聯網上各種現象級應用。當然工業物聯網也得益於雲技術的成熟，才能使高門檻的工業自動化技術得到了一定程度上的普及，否則也很難有今天所謂的工業物聯網。不過民用物聯網和工業物聯網區別還是有的，下面將一一簡要介紹。

• 首先是數量的區別，民用物聯網往往面臨的是百萬、千萬級別的用戶群。工業物聯網從量上來說，要比這個規模小得多。
• 其次是功能上的區別，民用物聯網功能往往比較單一，易用，免維護。工業物聯網功能就相對復雜的多，往往對應一個行業內的一系列具體的功能，
• 然后就是價格上的區別，民用領域的用戶對價格相對敏感，所以民用領域的物聯網產品往往價格比較低廉。工業物聯網領域的產品由於面向行業，面向具體的應用，量少，所以單價相對較貴。
• 最后就是品質上的區別了，最簡單的工業和民用的區別，就是設計產品的時候，器件選型民用產品往往選擇民用級別的，工業級產品往往選擇工業級的。除了價格上工業級的芯片比較貴外，應用環境的溫度范圍比民用領域也要寬廣，可以在相對苛刻的條件下也能可靠地工作。

1.2 工業物聯網全棧開發

全棧開發的概念來源於 Web 開發領域，指同時具備前端和后台開發的能力。引申到工業物聯網領域，全棧開發意味着要懂硬件開發，要懂各種傳感器、雲開發、Web 開發技術、手機 APP 開發、各種通信技術和數據存取，大數據時代還要求懂數據挖掘和分析。

這對全棧工程師來說，要求就非常高了。考慮到實際，從技術路線來看，全棧開發還是分派系的，如“Java 派”，各種層面的開發都是以 Java 類的開發技術為主。如“.NET 派”，各種層面的開發都是用.NET 技術進行開發。由於歷史原因，我從 2001 年開始進入工控開發，工控軟件類開發大都以微軟技術為主，所以全棧開發主要采用了.NET 技術。

二、工業物聯網設備端開發

民用物聯網端的開發和工業物聯網端的開發還是有很大區別的，民用物聯網端產品是廠家直接基於芯片進行產品開發。是典型的硬件開發了。而工業物聯網端的開發，往往是在第三方廠家的產品基礎上進行二次開發，也就是更多的是做集成類的開發工作。

我們所做的工業物聯網的端設備就是供其他工業物聯網集成商進行二次開發的。當然我們也會基於我們的軟硬件產品進行工業物聯網項目的集成開發。

這里着重介紹的就是在現有的工業物聯網產品基礎上進行的項目開發。

2.1 常見 IO 接口

目前工業領域常見的 IO 接口如下：

• RS485：兩線制，差分信號傳輸，半雙工通信，最大通信距離千米以上。
• RS232：三線制，全雙工通信，一般通信距離小於 10 米。 
  CAN：兩線制，多主通信，高性能，高可靠性，每次最多傳輸 8 個字節的數據。通信距離千米以上。
• 以太網：4 線或 8 線，多主通信，高性能。普通網線通信距離 100 米以內。
• Zigbee：基於 IEEE802.15.4 標准的低功耗無線通信協議，低功率一般傳輸距離 100 米以內，高功率的 1000 米左右。
• LoRa：基於擴頻技術的超遠距離無線傳輸方案。低功耗，多節點。
• GPRS：通用分組無線服務技術，廣域網通信。
• NB-IoT：IoT 領域一個新興的技術，支持低功耗設備在廣域網的蜂窩數據連接，亦稱低功耗廣域網(LPWA)。
• 模擬量輸入：0~20mA/0~5V/0~20V
• 開關量輸入：0~24V
• 繼電器輸出：0~220V/2A

2.2 常見通信協議

Modbus RTU: 施耐德公司制定的基於 RS485/RS232 的串行通信總線協議。 
Modbus TCP: 施耐德公司制定的基於以太網的通信總線協議。 
PPI：西門子公司專為 S7-200 系列 PLC 開發的通訊協議。 
Profibus：是一種國際化、開放式、不依賴於設備生產商的現場總線標准。 
CANopen：是一種架構在 CAN 上的高層通信協協議，包括通信子協議及設備子協議。

2.3 常見智能模塊

常見的智能模塊其實種類比較多的，比如智能電表，智能水表，各種 PLC 及其配套的擴展模塊等等。我們這里主要介紹的就是凌霄物聯網智能網關、智能終端、智能 IO 模塊和綜合采集模塊。

 

 
圖 1 物聯網智能網關 智能終端 綜合采集器

 

網關除具備網口、USB、SD 卡及擴展兩路智能模組（無線通信、RTC、存儲等板卡）外，還可以配置各種不同通信接口板（當然也可以直接對接智能終端或智能 IO 上的輸入輸出子板）。

• 綜合通信：1 路 RS485,2 路 RS232,1 路 CAN
• RS485-CAN：3 路 RS485,1 路 CAN
• RS485：4 路 RS485

智能終端和智能 IO 模塊的主要區別有，一是通信接口，智能終端有三種接口可選，以太網、RS485 和 CAN；而智能 IO 模塊僅具備 CAN 接口。二就是智能終端支持二次開發，能獨立運行，也可以作為智能網關的擴展模塊，而智能 IO 僅作為智能網關的擴展模塊存在。

智能終端和智能 IO 模塊，根據對外接口不同，主要有如下種類的模塊：

• 綜合輸入輸出模塊：2 路模擬量入，2 路開關量入，2 路繼電器輸出
• 綜合模擬量模塊：4 路模擬量輸入，2 路模擬量輸出
• 綜合開關量模塊：4 路開關量輸入，4 路開關量輸出
• 模擬量采集模塊：4 路模擬量輸入
• 開關量輸入模塊：8 路開關量輸入
• 繼電器輸出模塊：8 路開關量輸出
• 熱電偶采集模塊：4 路熱電偶采集

綜合采集器，是一個九合一的傳感器集成模塊，可以說是國內外集成度最高的一款產品。一次可以采集的傳感器數據有 3 路溫度，1 路濕度、1 路氧氣、1 路氨氣、1 路二氧化碳、1 路光照、1 路 PM2.5。該模塊可以通過 RS485 直接和網關相連，標准 Modbus RTU 通信協議。

2.4 YFIOs 數據組態開發

 

 
圖 2 YFIOs 系統架構

 

圖 2 是 YFIOs 數據組態系統的架構圖，其包含三部分：驅動層，核心層（驅動引擎及實時數據庫）和策略層。

所謂的二次開發大部分就是開發和具體業務聯系密切相關的策略程序，此外就是少部分的驅動程序開發（除了對接特殊設備，大部分情況下無需用戶開發驅動程序）。

下面我們用一個簡單示例來介紹一下 YFIOs 組態開發。

2.4.1 硬件准備及連接

我們需要准備如下設備：1 台物聯網智能網關，1 台物聯網智能終端（或智能 IO），1 台綜合采集器，1 條 USB 線及附屬電源及連接線等。設備及輔材准備好后，按如下方式進行接線：

 

 
圖 3 設備連接

 

2.4.2 創建用戶驅動

 

 
圖 4 新建 YFIOs 設備

 

如圖 4 所示，根據設備的類型，對應的網關接口，新建綜合采集器和輸入輸出智能終端對應的用戶設備。

設備創建后，對應的設備變量也會自動創建。

2.4.3 設備及變量監控

無需任何編程，只要把相關的驅動和配置信息部署到網關，就可以直接監控設備的通信狀態、IO 輸入狀態和連接的傳感器數據。如果有 IO 繼電器輸出，也可以在 IO 監控界面，直接修改對應的值以改變繼電器的開閉狀態。

 

 
圖 5 IO 數據監控

 

2.4.4 創建用戶策略

如果僅僅實現數據從端到雲的傳輸，那么無需寫用戶策略。當然對大部分的工業物聯網現場應用來說，還是需要一定的業務邏輯進行處理的。比如檢測到設備電機過熱，則要求網關立即停止電機運行或者對外發出報警信號。這里我們寫一個最簡單的用戶策略，就是當一路開關量輸入為高電平的時候，讓一路繼電器閉合，低電平的時候則繼電器釋放。

開發用戶策略，可以采用微軟 Visual Studio IDE 開發工具進行開發，我們也提供了對應的模板程序，可以直接填入必要的業務代碼即可。如圖 6 所示，標准的用戶策略其實只需要實現 3 個接口函數即可：OnLoad、OnRun和OnUnload。

 

 
圖 6 策略開發

 

OnLoad 在用戶策略開始加載的時候執行，只執行一次。OnRun 按設定的間隔，循環被 YFIOs 的驅動引擎調用。OnUnload 是策略被卸載前執行一次。

圖 6 中在 OnRun 添加的代碼如下：

if (op.IOReadInt("QI44:I1") != op.IOReadInt("QI44:Q1")) { op.Extern_IOWrite("QI44:Q1", op.IOReadInt("QI44:I1").ToString()); op.Print(MessageType.Debug, "I1=" + op.IOReadInt("QI44:I1").ToString(), Name); }

以上代碼的意思是，從 YFIOs 實時數據庫中讀取 QI44:I1 通道值，如果和繼電器的輸出狀態不同，則繼電器的狀態和輸入通道保持一致。

用戶策略編寫完畢后，則可以用 YFIOsManager 工具進行加載和調試了（如圖 7 和圖 8 所示）。

 

 
圖 7 新建策略

 

 

 
圖 8 策略調試

 

從圖 8 中我們可以看出，當 I1 輸入狀態被改變的時候，繼電器的輸出狀態也被改變了，調試窗口中也輸出了對應的調試信息。

2.4.5 添加 QCPB 雲端通信策略

如果不和雲端通信，也就不需要添加 QCPB 雲端通信策略了，但是如果沒有這部分也稱之不上為物聯網項目了，只是一個典型的小自動化項目而已。

和添加用戶策略一樣，我們添加上 QCPB 雲端通信策略，除了設置運行間隔外，我們還需要設定相關的參數，如圖 9 所示。

 

 
圖 9 添加雲端通信策略

 

IP 地址是指雲端服務器端地址，端口號默認為 12000，項目 ID 是指雲端創建對應項目時的 ID 號（這個后文會有介紹）。由於 QCPB 協議支持變化上傳數據，所以針對浮點數，需要設置數據變化的閾值。

“IO 配置”面板中有一個導出按鈕，可以單擊導出，保存后的 XML 文件在創建雲端項目及雲端組態畫面的時候會用到。

三、雲端通信協議

3.1 MQTT 通信協議

MQTT 是 Message Queuing Telemetry Transport 的縮寫，中文意思是消息隊列遙測傳輸，它是 IBM 開發的一個即時通訊協議，目前已經成為物聯網主流的通信協議，微軟雲、百度雲、阿里雲等都支持該通信協議。這意味着設備只要支持了該通信協議，就可以和當前主流的雲進行雲端通信。凌霄物聯網網關也支持該協議，在一個消防相關的項目中，就是通過該協議把采集到的數據上傳到的微軟 Azure IoT Hub 中。

3.2 WebSocket 通信協議

WebSocket 協議是 HTML5 標准里，基於 TCP 的一種新的網絡協議，2011 年被 IETF 定為標准 RFC 6455。它實現了瀏覽器與服務器全雙工(full-duplex)通信，服務器可隨時向客戶端發送信息，不僅通信數據量變小，同時也大大改善了網頁動畫的實時性能。我們的 YFHMI 組態動畫，就是基於 WebSocket 通信協議和服務器中間件 YFCloud 進行通信的。

3.3 QCPB 通信協議

這是我們自行開發的一個基於二進制格式的雲端通信協議，其優點是通信數據量小，支持數據變化上傳。除了支持數據通信外，還支持設備的遠程診斷、遠程參數下載和遠程升級等功能。支持 TCP/IP 以太網和 GPRS 雙鏈路自動切換通信模式。本篇文章中所介紹的雲端通信就是基於該協議來實現的。

四、雲服務 YFCloud 開發

雲端 YFCloud 有三部分組成：Web 后台、Web 前台和 YFIOs 雲端中間件。Web 后台和前台采用 ASP.NET 進行開發，YFIOs 雲端中間件也是采用.NET 技術進行開發，是一個標准的 Windows 服務程序。

4.1 雲端項目構建

首先登錄 YFCloud 物聯網中間件通用監控平台就可以開始創建雲端項目了。YFCloud 的構建思想是，先有項目模板，然后再基於項目模板創建應用。這樣的好處就是，基於一個項目模板可以創建若干應用。

4.1.1 創建項目模板

 

 
圖 10 創建項目模板

 

先添加一個項目模板，然后比較重要的一步就是導入【2.4.5】章節所導出的 IO 配置文件，從而構建雲端 IO 實時數據庫（如圖 11 所示）。

 

 
圖 11 雲端 IO 列表

 

4.1.2 創建項目應用

基於我們剛剛創建的“工業物聯網演示”模板創建一個項目應用。創建一個項目應用后，系統會自動生成一個項目 ID 號，把這個 ID 號填入【2.4.5】章節中所示的雲端通信策略中的 IO 配置面板中，填入后部署到物聯網智能網關即可。

4.2 YFIOs 雲端中間件

YFIOs 雲端中間件脫胎於嵌入式 YFIOs，從圖 12 的架構圖上就可以看出，嵌入式 YFIOs 是一個“單機版”的數據組態平台，而雲端中間件 YFIOs 是一個“網絡版”數據組態平台。

 

 
圖 12 YFIOs 中間件架構

 

YFIOs 雲端中間件集成了 WebSocket 服務器，Web 動態網頁可以通過 WebSocket 協議和服務器進行通信。

YFIOs 雲端中間件以項目為最小單位來進行管理的，一個或多個項目對應一個項目模板，實際應用通過項目 ID 進行區分。

4.2.1 遠程 IO 監控

 

 
圖 13 YFIOs 雲端中間件

 

在雲端服務器上打開 YFIOs 雲端中間件-客戶端程序，可以看到在“工業物聯網演示”項目模板下，我們看到“工業物聯網 Demo”應用的運行標志已經變為綠色，表示物聯網智能網關設備已經和雲端連接成功。右側的顯示面板上可以看到從物聯網智能網關上傳到雲端的各種 IO 數據。在該界面上，也可以對繼電器變量進行操作，寫入 0 或 1，可以看到物聯網智能終端上對應的繼電器閉合或開啟。

4.2.2 遠程參數&遠程升級

 

 
圖 14 遠程參數&遠程升級

 

針對一個具體的項目，遠程參數即可能雲端策略需要，也可能同時遠程設備上的策略需要，如果是這種情況，處理要復雜一些，相關參數需要保存到雲端服務器，並且參數一旦修改，需要同時通知雲端策略和遠程設備上的策略。如果僅遠程設備需要，那么簡單期間，可以直接通過 YFIOs 雲端中間件直接傳遞一個二進制參數文件即可。

遠程升級的實現要相對復雜，因為升級文件相對較大，並且傳輸通道有可能是 GPRS 窄帶傳輸，所以需要分段進行傳輸。要確保整個的升級文件，完整可靠的傳輸到遠程的物聯網智能網關上，並且重啟重連成功后，才算真正的升級完畢。

由於基於同一個項目模板下的多個相關應用的物聯網智能網關上的應用往往是一樣的，所以只要設定一個升級文件就可以升級整個項目模板下的所有的項目應用。但是這有一個前提，要升級的固件版本，要比設備上當前運行的版本高。

考慮到一些特殊情況的存在，YFIOs 雲端中間件也支持遠程強制升級，不管當前什么版本，不管以前運行的什么應用，都可以強制實現遠程升級的功能。

4.2.3 雲端策略開發

YFIOs 雲端中間件的策略和 YFIOs 嵌入式的策略開發基本相同，也含有 OnLoad、OnRun 和 OnUnload，差別就是雲端中間的策略能力更強，可以充分利用 Windows 平台本身的.NET Framework 能力。

有些業務邏輯即可以放在設備端的策略里，也可以放到雲端的策略里，比如一些當日量和累積量的處理和換算。有些最好放到設備端，比如某些指標超過閾值，需要立即關閉或開啟設備的。有些則放在雲端更合理，比如需要把數據進行永久存儲的。

雲端策略分三種類型：核心策略、公共策略和用戶策略。核心策略，YFIOs 雲端中間件每個項目都會執行，公共策略是多個項目可選擇性的執行，用戶策略則是用戶項目模板下的項目才會執行。其上三種策略從代碼結構上沒有什么區別，以所在的目錄決定其策略類型。

 

 
圖 15 策略管理

 

五、雲畫面 YFHMI 組態開發

YFHMI 畫面組態最早支持 WinCE 平台，后來在 WinCE 平台軟件的基礎上開發出了基於.NET Micro Framework 平台的版本。.NET Micro Framework 一般運行在相對資源較小的物聯網芯片（Cortex-M 系列）上，所以 YFHMI 在性能和體積上做了進一步的優化。考慮到 Html5+WebSocket 是未來 WEB 前端的主流，在 YFHMI 支持 Windows 版本后，又直接推出了 Html5 的組態版本。

5.1 Web 組態畫面構建

5.1.1 創建組態畫面

在創建基本組態畫面的同時，我們還是需要導入在【2.4.5】章節所導出的 IO 配置文件，以便於動畫綁定對應的 IO 變量（如圖 16 所示）。

 

 
圖 16 YFHMI 圖元創建 & IO 導入

 

我們構建的組態畫面比較簡單，兩個指示燈分別對應智能終端的 I1、I2，一個切換開關對應 Q2,四個文本框分別對應 T1、T2、T3 和 H。IO 變量導入后，相關的圖元分別綁定上對應的變量。 
5.1.2 導出 Html5 文件

 

 
圖 17 Html5 網頁導出

 

導出的 bg.png、Monitor.html、PublishIO.xml 和 YFWebSocket.js 四個文件需要上傳到雲端對應的項目模板目錄下。導出的 PublishIO.xml 文件需要導入雲端 IO 列表，以設定對應的發布 IO。

5.2 Web 畫面呈現及操控

 

 
圖 18 動畫監控

 

在 Web 網頁上我們打開動畫監控頁，可以看到這個內容是和我們在 YFHMI 中創建的組態畫面是一致的，並且其顯示的數據也和真實設備的值一樣（和 YFIOs 雲端中間件的 IO 實時數據保持一致）。這個時候如果我們用鼠標操作開關按鈕，可以看到物聯網智能終端的繼電器吸合或釋放。

六、應用案例

綜上，我們可以看出無需太多專業技能，無需太多時間，就可以從端到雲構建一套相對實用，且有一定復雜度的工業物聯網方案。下面我們將介紹的案例，就是我們這兩三年來在實際現場實施的項目，是真正得到實際運行考驗的項目。

6.1 遠程污水監測/監控系統

 

 
圖 19 恭城遠程污水監測界面

 

 

 
圖 20 龍灘遠程污水監控界面

 

 

 
圖 21 硬件控制櫃

 

廣西龍灘和恭城的污水監控和監測系統，分別在 2014 和 2015 年開始着手實施，最初龍灘項目沒有遠程監控畫面，僅包含現場自動化系統，在恭城遠程監控畫面實現后，才又增添了遠程監控功能。目前該項目已經在現場運行了兩年以上。

6.2 遠程垃圾處理系統

廣西龍灘垃圾處理系統在 2015 年開始研發實施，和污水監控系統不同的是，除了包含現場自動化控制、遠程雲端監控外，現場還有顯示器進行現場監控。所以 YFHMI 構建的組態，不僅支持 HTML 5 網頁組態畫面，還支持嵌入式組態畫面。

 

 
圖 22 龍灘遠程垃圾監控系統

 

6.3 物聯網養殖監控系統

物聯網養殖監控系統是我們在 2015 年底和新希望六合還有微軟共同合作研發的一套養殖監控系統。目前已經在山東濟南、濰坊、河南新鄉、武陟，河北香河等地進行了安裝實施。

本系統和上面介紹的污水處理和垃圾處理系統有些不同，上述兩個系統的架構，核心就是物聯網智能網關連接若干不同功能的智能終端和智能電表，通信也是僅采用 3G/4G 方式和遠程服務器進行通信。物聯網養殖系統除了包含上述的功能外，還專門為其研制了九合一的綜合采集器，此外還能連接智能電表、智能水表，環控器等等智能設備。為了保證通信的可靠性，還支持 GPRS/因特網雙網自動切換功能。在遠程監控端，除了具備網頁監控，微信監控外，還提供手機 APP 進行遠程操控。

 

 
圖 23 養殖監控-實時數據