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

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

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

1、前言

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

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

那民用物聯網和工業物聯網的區別是什麼呢?web

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

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

1.2 工業物聯網全棧開發

全棧開發的概念來源於 Web 開發領域,指同時具有前端和後臺開發的能力。引伸到工業物聯網領域,全棧開發意味着要懂硬件開發,要懂各類傳感器、雲開發、Web 開發技術、手機 APP 開發、各類通訊技術和數據存取,大數據時代還要求懂數據挖掘和分析。編程

這對全棧工程師來講,要求就很是高了。考慮到實際,從技術路線來看,全棧開發仍是分派系的,如「Java 派」,各類層面的開發都是以 Java 類的開發技術爲主。如「.NET 派」,各類層面的開發都是用.NET 技術進行開發。因爲歷史緣由,我從 2001 年開始進入工控開發,工控軟件類開發大都以微軟技術爲主,因此全棧開發主要採用了.NET 技術。瀏覽器

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

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

咱們所作的工業物聯網的端設備就是供其餘工業物聯網集成商進行二次開發的。固然咱們也會基於咱們的軟硬件產品進行工業物聯網項目的集成開發。服務器

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

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 個接口函數便可:OnLoadOnRunOnUnload

 

 
圖 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); }
  • 1
  • 2
  • 3
  • 4
  • 5

以上代碼的意思是,從 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、雲端通訊協議

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 雙鏈路自動切換通訊模式。本篇文章中所介紹的雲端通訊就是基於該協議來實現的。

4、雲服務 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 策略管理

 

5、雲畫面 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 導入

 

咱們構建的組態畫面比較簡單,兩個指示燈分別對應智能終端的 I一、I2,一個切換開關對應 Q2,四個文本框分別對應 T一、T二、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、應用案例

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

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

 

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

 

 

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

 

 

 
圖 21 硬件控制櫃

 

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

6.2 遠程垃圾處理系統

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

 

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

 

6.3 物聯網養殖監控系統

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

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

 

  圖 23 養殖監控-實時數據
相關文章
相關標籤/搜索