基于CAN總線和WiFi通信的爬架組監控系統設計

賀尊義，勞振煜，李 宏

(寧波大學 信息科學與工程學院，浙江 寧波 315211)

0 引言

爬架是建設部在建筑業重點推廣和應用的新技術[1]，是一種附著在建筑物結構上，依靠自身的提升設備來實現升降的懸空腳手架，特別適用于高層建筑施工。爬架組是由多個架體沿著建筑物圍成一圈形成的整體，它既可以整體升降也可以分片升降。由于爬架往往懸在高層建筑上，施工人員作業危險性非常大，為了保障施工安全必須對爬架組的安全狀況進行實時監控。目前國內對爬架的研究多數停留在結構和動力設備的改進上，如文獻[2]提出的集成式爬架，文獻[3]提出的液壓步進式爬架，對爬架控制安全方面的研究較少。近年來隨著對施工安全的不斷重視，開始有對爬架控制安全的研究，如文獻[4]提出的基于485總線的爬架控制系統，通過便攜式PC機和專用控制儀表來監控爬架，提高了爬架運行的安全性。但485總線構成的主從式結構系統，系統的實時性和可靠性并不理想，無法滿足實時監控爬架的需求。并且控制現場各設備間多采用有線連接，致使現場布線復雜，監控設備移動性差[5]，為爬架的可靠運行埋下了安全隱患。

針對上述問題，本文設計了一種基于CAN總線和WiFi通信的爬架組監控系統，能有效減少現場布線，增強監控設備的可移動性，滿足實時監控爬架安全的需求。該系統由分控器、協調器和上位機構成，通過CAN總線實現各分控器和協調器間的通信，通過WiFi模塊實現協調器和PC端上位機的無線通信。分控器主要起到數據采集的作用，采集爬架的重要參數信息并上傳給協調器。協調器主要起到數據中轉的作用，利用TCP/IP協議與上位機進行通信。用戶可以很方便地在PC端查看爬架組的所有參數信息，一旦發現報警可立即通過上位機操控爬架，及時排除險情。

1 系統總體結構

爬架組監控系統的總體結如圖1所示，自底向上可將其分為三層：數據采集層、數據中轉層和數據處理層。

圖1 爬架組監控系統總體結構

數據采集層是指分控器采集爬架的基本參數信息。分控器安置在爬架組的各個架體上，每個分控器都擁有重力傳感器、拉線傳感器和傾角傳感器分別采集所在架體的拉力、高度和傾角。分控器一面將傳感器信息和故障信息通過CAN總線上傳給協調器，另一面從協調器接收上位機下發的控制命令來控制執行機構。

數據中轉層主要由協調器和WiFi模塊組成。協調器接收到分控器上傳的數據后將其打包通過WiFi模塊發送給上位機，同時從WiFi模塊接收上位機下發的控制命令并通過CAN總線發送給各個分控器。

數據處理層是指PC端的上位機接收到數據后將其解析，并在上位機界面上顯示。上位機有狀態顯示、記錄查看、系統控制、參數控制等功能。用戶可以通過狀態顯示對爬架的安全狀況進行實時查看，也可以通過系統控制發送命令給分控器對其進行操控，如此便實現了對爬架組的實時監控。

2 系統硬件設計

2.1 數據采集層的硬件設計

數據采集層由25個分控器以及傳感器組成。分控器采用STM32F103為主控芯片，配合檢測電路、繼電器電路、CAN收發電路、LCD接口等外圍電路，其主要職責是采集所在架體的參數信息以及控制架體的升降。數據采集層采用CAN總線來構建各分控器間的通信網絡，理論上CAN總線可容納的終端節點的個數不受限制[6]，但本系統中僅連接25個分控器，可有效減輕總線上的負荷。傾角傳感器采用的是MPU6050，可測得架體在前后、左右兩個方向的傾斜角度。拉線傳感器采用的是MPS-L-MA電流型傳感器，其量程范圍為0～5 000 mm。重力傳感器采用電壓型稱重傳感器，其量程范圍為0～10 T。LCD用于顯示參數信息與故障信息，E2PROM用于存儲報警參數閾值，固態繼電器用于控制電機，分控器的硬件結構如圖2所示。

圖2 分控器硬件結構

2.2 數據中轉層的硬件設計

數據中轉層的核心部件是協調器和WiFi模塊，在系統中主要起到數據中轉的作用。協調器的主控芯片采用的是ST公司的STM32F107，內置CAN控制器，可提供兩路CAN接口，具有功耗低、成本低、性能高的特點，能滿足數據中轉的要求。板上外擴了一個SRAM存儲器，因為涉及到通信編程對內存需求較大，協調器的硬件結構如圖3所示。

圖3 協調器硬件結構

WiFi模塊采用的是ESP8266，它內置了TCP/IP協議棧，完全支持IEEE 802.11b/g標準，支持UART/GPIO數據通信接口，能很方便地通過串口與微控制器連接[7]。該模塊可分別在STA/AP/STA+AP三種模式下工作，在本系統中將其配置為AP模式，PC機作為一個station接入ESP8266與其構成無線局域網絡，從而實現數據的互訪。WiFi模塊硬件電路如圖4所示。

圖4 WiFi模塊硬件電路

3 系統軟件設計

系統軟件設計包括CAN通信設計、分控器軟件設計、協調器軟件設計、WiFi通信設計和上位機軟件設計。

3.1 CAN通信設計

3.1.1 CAN應用層協議設計

協調器與各分控器間的數據傳輸是通過CAN總線來實現的。從OSI網絡模型來看，CAN總線僅僅定義了物理層和數據鏈路層，并未對其他層做出規定，因此用戶可根據實際需求定義應用層協議[8]。在本系統中主要用到了CAN總線的數據幀，其結構如圖5所示。

圖5 CAN數據幀結構

根據系統功能特點將CAN數據幀的11位標識符劃分為3個區域：2位用來標志優先級，3位用來標志幀類型，6位用來標志節點編號。在設計中共定義了8種幀類型，其中急停幀用來廣播停止命令；報警幀用來發送故障信息給協調器；測試幀用來測試分控節點是否連接上；點對點通信幀用來設置單個分控的節點編號；傳感器信息幀用來傳輸傳感器信息；受控設置幀用來發送信息給被控制的分控節點；控制命令幀用來發送控制命令給各分控節點；閾值設置幀用來發送報警閾值給分控節點。具體的定義如表1所示。

表1 報文幀類型表

優先級標志(2位)幀類型標志(3位)節點編號標志(6位)幀類型000000-111111急停幀010010-111111報警幀100100-111111測試幀100110-111111點對點通信幀111000-111111傳感器信息幀011010-111111受控設置幀011100-111111控制命令幀011110-111111閾值設置幀

3.1.2 在線檢測機制

協調器向分控器請求數據前先要確認其是否在線。協調器每隔500 ms對CAN網絡內的分控器發起一次輪詢檢測，采用“三次握手”方式確認分控器是否在線。若在輪詢檢測中向某分控器發送測試幀，連續三次均未收到回復，則認為該分控器已掉線，向接下去的分控器發起測試。在線檢測通信過程如圖6所示。

圖6 在線檢測通信過程

3.2 分控器軟件設計

分控器的職責是采集爬架組的基本信息并對電機進行控制，其軟件設計可分為主程序和中斷服務程序兩部分。在主程序中，分控器先進行硬件資源初始化和開機自檢。接著判斷自己是否接入CAN通信網絡，若成功接入就采集爬架的基本參數信息，包括拉力、高度、傾角，然后把這些數據通過傳感器信息幀發給協調器，此外還要響應控制指令對電機進行控制。主程序的工作流程如圖7所示。中斷服務程序主要包括：通信狀態的檢測、按鍵信號的掃描、CAN通信處理和故障信息處理。其中CAN通信處理是指分控器接收到協調器下發的各種CAN數據幀后并進行相應的處理。故障信息處理是指分控器集中處理檢測到的故障信息并通過報警幀發給協調器。

圖7 分控器主程序流程

3.3 協調器軟件設計

為了提高系統的實時性，協調器在μC/OS-II操作系統的基礎上進行軟件設計[9]，其軟件結構可分為3層：驅動層、操作系統層和應用層。應用層包括3個任務，分別為WiFi通信任務和CAN通信任務、LCD顯示任務。在WiFi通信任務里，協調器一面接收上位機下發的命令，另一面將數據打包發送給上位機；在CAN通信任務里，協調器主要負責在CAN通信網絡里與各個分控器進行數據交互；LCD顯示任務中主要是顯示協調器與各個分控器以及上位機的通信狀況。協調器的軟件結構如圖8所示。

圖8 協調器軟件結構

3.4 WiFi通信設計

協調器與上位機之間的無線通信采用TCP/IP協議。TCP協議提供了無差錯的數據傳輸，保證了數據通信的可靠性，并且同時提供了流量控制和擁塞控制[10-11]，所以在對數據包進行解析時，大大降低了PC端上位機軟件的處理壓力。為了適應協調器與上位機之間的數據傳輸特點，在TCP/IP協議以上制定了滿足系統功能需要的數據包格式。起始符和結束符各占兩個字節，規定了數據包的開始和結束。包類型規定了數據包的類型是狀態數據包還是命令數據包，狀態數據包是協調器向上發送的爬架參數信息，命令數據包是上位機向下發送的控制命令。包長度規定了數據包中數據的長度。數據包的具體定義如圖9所示。

起始符(2byte)包類型(1byte)包長度(1byte)數據1(1byte)…數據n(1byte)結束符(2byte)

圖9數據包格式

WiFi模塊的配置以及通信功能的實現是通過向其發送AT指令來完成的。在協調器中通過MCU用串口向模塊發AT指令的方式將ESP8266配置為AP模式，在這個模式下WiFi模塊是無線網絡接入點(相當于路由器)，而PC機則是個無線終端。為了方便應用層的調用，在驅動層中編寫WiFi收發函數：ErrorStatus ESP8266_recv_message(char *msg,char *num,uint8_t *length)和ErrorStatus ESP8266_send_message(uint8_t *msg,uint8_t length,uint8_t num)。在WiFi通信任務中協調器與上位機的通信流程如圖10所示。

圖10 WiFi通信流程

3.5 上位機軟件設計

上位機軟件是整個監控系統的核心，其職責是實時監控爬架組的參數信息，幫助用戶及時發現故障、處理報警，保證爬架穩定安全地運行。上位機軟件是采用圖形化編程語言LabVIEW編寫的。LabVIEW集成了大量有關數據的采集、分析、顯示和存儲的工具和函數，在測量、監控等領域具有明顯的優勢[12]。

上位機的軟件設計包括三大部分：WiFi通信、數據處理和系統控制。首先是WiFi通信，當上位機檢測到WiFi開啟后，打開TCP連接函數并輸入相應的IP地址和端口號[13]，然后調用TCP read讀取TCP數據將其放在接收緩存區。接著是數據處理，對接收緩存區中的數據進行解析，然后按照不同的需求對其進行處理分別是數據顯示、數據存儲和數據查詢。系統控制是相對獨立的一部分，包括參數設置、激活組設置和動作控制，每部分的操作指令都會轉換成命令數據包的形式，通過調用TCP write下發給協調器。上位機的軟件結構如圖11所示,上位機的程序流程如圖12所示。

圖11 上位機軟件結構

圖12 上位機程序流程

首先上位機對用到的資源進行初始化，包括顯示控件恢復到默認的狀態，系統參數從配置文件中加載出來，參數閾值從本地磁盤的文件中讀出來等。接著打開WiFi與協調器進行通信，上位機通過協調器來接收在線分控器采集的爬架基本參數信息并顯示，根據用戶的操作決定是否將數據保存或是否查詢數據庫。然后根據閾值參數判斷爬架參數是否正常，若異常進行報警指示。最后用戶選定激活組并對組內的爬架進行控制，通過TCP write將指令下發給協調器。

4 系統測試

對系統的功能與性能進行測試，用CAN總線連接分控器和協調器，當系統上電后打開PC端的上位機軟件，系統運行時的上位機軟件圖形界面如圖13所示。

按照功能可以將上位機界面分為參數設置、記錄查看、系統控制、狀態顯示這4個區域。參數設置是用戶可以根據實際需求設定傳感器的報警閾值，并將其下發給各個分控器。記錄查看是幫助用戶可查看所有爬架組的傳感器信息和故障信息，并且上位機會定時將這些信息存儲到數據庫文件里供用戶查看歷史記錄。在系統控制中用戶通過點擊圖形按鈕直接操控爬架的升降。狀態顯示是上位機會將爬架組的所有信息(包括拉力、高度、傾角、故障信息)通過圖形化的方式在左側面板上顯示出來，用戶可以很直觀地觀察到爬架的安全狀況。

圖13 上位機軟件圖形界面

5 結束語

本文設計了一種基于CAN總線和WiFi通信的爬架組監控系統。該系統主要由分控器、協調器和PC端上位機構成，采用可靠性更高的CAN總線構建協調器與各分控器間通信網絡，使得網絡內各站點間能自由通信，大大提高了系統的可靠性和實時性。采用WiFi模塊實現協調器和PC端上位機的無線通信，PC機可在任何接收到無線的地方對爬架進行監控，克服了現有監控系統受有線連接限制的弊端，提高了系統的靈活性和便捷性。實際測試表明該系統運行安全可靠，能有效提高爬架運行的安全性，保障施工人員的人身安全，在建筑施工領域有良好的應用前景。

[1] 李會良.爬架在高層建筑施工中的應用研究[D].西安：長安大學,2010.

[2] 葛川玲,劉坤,孔祥玉.集成式爬架在住宅樓施工中的應用[J].建筑施工,2015,37(9):1094-1096.

[3] 祝永成,焦紅衛.液壓步進式爬架提升技術研究[J].國外建材科技,2006(5):47-50.

[4] 羅少軒,喬愛民,王艷春,等.一種新型附著式升降腳手架控制系統設計[J].齊齊哈爾大學學報(自然科學版),2014,30(5):47-51，60.

[5] Liu L,Zeng Y,Li J.Research on the Track Dynamic Monitoring System to Assess the Safety of Train Operation [J].Procedia Engineering,2014,84:726-730.

[6] Ismail K,Muharam A,Pratama M.Design of CAN Bus for Research Applications Purpose Hybrid Electric Vehicle Using ARM Microcontroller [J].Energy Procedia,2015,68:288-296.

[7] 曾磊,張海峰,侯維巖.基于WiFi的無線測控系統設計與實現[J].電測與儀表,2011,48(7):81-83，96.

[8] Merugu R,Pai S.Microcontroller Based Temperature and Luminosity Control System Using CAN Bus[C]∥International Conference on Advances in Communication and Computing Technologies.IEEE,2015:1-5.

[9] Song X,Chen L.The Design and Realization of Vehicle Real-time Operating System Based on UC/OS-II[C]∥International Conference on Networked Computing.IEEE,2010:1-4.

[10] 陸晶晶,朱善安,葉旭東.基于TCP/IP協議的電工電子網絡實驗室[J].機電工程,2007,27(4):70-72.

[11] Han S,Kim H.On AUTOSAR TCP/IP Performance in In-Vehicle Network Environments[J].IEEE Communications Magazine,2016,54(12):168-173.

[12] 王樹東,何明.LabVIEW在數據采集系統中的應用研究[J].國外電子測量技術,2014,33(6):103-106.

[13] 方立軍,陳衛松,章良玉,等.基于STM32的以太網網絡視頻監控系統[J].無線電通信技術,2017,43(5):91-94.