賀尊義,勞振煜,李 宏
(寧波大學 信息科學與工程學院,浙江 寧波 315211)
爬架是建設部在建筑業(yè)重點推廣和應用的新技術[1],是一種附著在建筑物結構上,依靠自身的提升設備來實現(xiàn)升降的懸空腳手架,特別適用于高層建筑施工。爬架組是由多個架體沿著建筑物圍成一圈形成的整體,它既可以整體升降也可以分片升降。由于爬架往往懸在高層建筑上,施工人員作業(yè)危險性非常大,為了保障施工安全必須對爬架組的安全狀況進行實時監(jiān)控。目前國內對爬架的研究多數(shù)停留在結構和動力設備的改進上,如文獻[2]提出的集成式爬架,文獻[3]提出的液壓步進式爬架,對爬架控制安全方面的研究較少。近年來隨著對施工安全的不斷重視,開始有對爬架控制安全的研究,如文獻[4]提出的基于485總線的爬架控制系統(tǒng),通過便攜式PC機和專用控制儀表來監(jiān)控爬架,提高了爬架運行的安全性。但485總線構成的主從式結構系統(tǒng),系統(tǒng)的實時性和可靠性并不理想,無法滿足實時監(jiān)控爬架的需求。并且控制現(xiàn)場各設備間多采用有線連接,致使現(xiàn)場布線復雜,監(jiān)控設備移動性差[5],為爬架的可靠運行埋下了安全隱患。
針對上述問題,本文設計了一種基于CAN總線和WiFi通信的爬架組監(jiān)控系統(tǒng),能有效減少現(xiàn)場布線,增強監(jiān)控設備的可移動性,滿足實時監(jiān)控爬架安全的需求。該系統(tǒng)由分控器、協(xié)調器和上位機構成,通過CAN總線實現(xiàn)各分控器和協(xié)調器間的通信,通過WiFi模塊實現(xiàn)協(xié)調器和PC端上位機的無線通信。分控器主要起到數(shù)據(jù)采集的作用,采集爬架的重要參數(shù)信息并上傳給協(xié)調器。協(xié)調器主要起到數(shù)據(jù)中轉的作用,利用TCP/IP協(xié)議與上位機進行通信。用戶可以很方便地在PC端查看爬架組的所有參數(shù)信息,一旦發(fā)現(xiàn)報警可立即通過上位機操控爬架,及時排除險情。
爬架組監(jiān)控系統(tǒng)的總體結如圖1所示,自底向上可將其分為三層:數(shù)據(jù)采集層、數(shù)據(jù)中轉層和數(shù)據(jù)處理層。
圖1 爬架組監(jiān)控系統(tǒng)總體結構
數(shù)據(jù)采集層是指分控器采集爬架的基本參數(shù)信息。分控器安置在爬架組的各個架體上,每個分控器都擁有重力傳感器、拉線傳感器和傾角傳感器分別采集所在架體的拉力、高度和傾角。分控器一面將傳感器信息和故障信息通過CAN總線上傳給協(xié)調器,另一面從協(xié)調器接收上位機下發(fā)的控制命令來控制執(zhí)行機構。
數(shù)據(jù)中轉層主要由協(xié)調器和WiFi模塊組成。協(xié)調器接收到分控器上傳的數(shù)據(jù)后將其打包通過WiFi模塊發(fā)送給上位機,同時從WiFi模塊接收上位機下發(fā)的控制命令并通過CAN總線發(fā)送給各個分控器。
數(shù)據(jù)處理層是指PC端的上位機接收到數(shù)據(jù)后將其解析,并在上位機界面上顯示。上位機有狀態(tài)顯示、記錄查看、系統(tǒng)控制、參數(shù)控制等功能。用戶可以通過狀態(tài)顯示對爬架的安全狀況進行實時查看,也可以通過系統(tǒng)控制發(fā)送命令給分控器對其進行操控,如此便實現(xiàn)了對爬架組的實時監(jiān)控。
2.1 數(shù)據(jù)采集層的硬件設計
數(shù)據(jù)采集層由25個分控器以及傳感器組成。分控器采用STM32F103為主控芯片,配合檢測電路、繼電器電路、CAN收發(fā)電路、LCD接口等外圍電路,其主要職責是采集所在架體的參數(shù)信息以及控制架體的升降。數(shù)據(jù)采集層采用CAN總線來構建各分控器間的通信網(wǎng)絡,理論上CAN總線可容納的終端節(jié)點的個數(shù)不受限制[6],但本系統(tǒng)中僅連接25個分控器,可有效減輕總線上的負荷。傾角傳感器采用的是MPU6050,可測得架體在前后、左右兩個方向的傾斜角度。拉線傳感器采用的是MPS-L-MA電流型傳感器,其量程范圍為0~5 000 mm。重力傳感器采用電壓型稱重傳感器,其量程范圍為0~10 T。LCD用于顯示參數(shù)信息與故障信息,E2PROM用于存儲報警參數(shù)閾值,固態(tài)繼電器用于控制電機,分控器的硬件結構如圖2所示。
圖2 分控器硬件結構
2.2 數(shù)據(jù)中轉層的硬件設計
數(shù)據(jù)中轉層的核心部件是協(xié)調器和WiFi模塊,在系統(tǒng)中主要起到數(shù)據(jù)中轉的作用。協(xié)調器的主控芯片采用的是ST公司的STM32F107,內置CAN控制器,可提供兩路CAN接口,具有功耗低、成本低、性能高的特點,能滿足數(shù)據(jù)中轉的要求。板上外擴了一個SRAM存儲器,因為涉及到通信編程對內存需求較大,協(xié)調器的硬件結構如圖3所示。
圖3 協(xié)調器硬件結構
WiFi模塊采用的是ESP8266,它內置了TCP/IP協(xié)議棧,完全支持IEEE 802.11b/g標準,支持UART/GPIO數(shù)據(jù)通信接口,能很方便地通過串口與微控制器連接[7]。該模塊可分別在STA/AP/STA+AP三種模式下工作,在本系統(tǒng)中將其配置為AP模式,PC機作為一個station接入ESP8266與其構成無線局域網(wǎng)絡,從而實現(xiàn)數(shù)據(jù)的互訪。WiFi模塊硬件電路如圖4所示。
圖4 WiFi模塊硬件電路
系統(tǒng)軟件設計包括CAN通信設計、分控器軟件設計、協(xié)調器軟件設計、WiFi通信設計和上位機軟件設計。
3.1 CAN通信設計
3.1.1 CAN應用層協(xié)議設計
協(xié)調器與各分控器間的數(shù)據(jù)傳輸是通過CAN總線來實現(xiàn)的。從OSI網(wǎng)絡模型來看,CAN總線僅僅定義了物理層和數(shù)據(jù)鏈路層,并未對其他層做出規(guī)定,因此用戶可根據(jù)實際需求定義應用層協(xié)議[8]。在本系統(tǒng)中主要用到了CAN總線的數(shù)據(jù)幀,其結構如圖5所示。
圖5 CAN數(shù)據(jù)幀結構
根據(jù)系統(tǒng)功能特點將CAN數(shù)據(jù)幀的11位標識符劃分為3個區(qū)域:2位用來標志優(yōu)先級,3位用來標志幀類型,6位用來標志節(jié)點編號。在設計中共定義了8種幀類型,其中急停幀用來廣播停止命令;報警幀用來發(fā)送故障信息給協(xié)調器;測試幀用來測試分控節(jié)點是否連接上;點對點通信幀用來設置單個分控的節(jié)點編號;傳感器信息幀用來傳輸傳感器信息;受控設置幀用來發(fā)送信息給被控制的分控節(jié)點;控制命令幀用來發(fā)送控制命令給各分控節(jié)點;閾值設置幀用來發(fā)送報警閾值給分控節(jié)點。具體的定義如表1所示。
表1 報文幀類型表
優(yōu)先級標志(2位)幀類型標志(3位)節(jié)點編號標志(6位)幀類型000000-111111急停幀010010-111111報警幀100100-111111測試幀100110-111111點對點通信幀111000-111111傳感器信息幀011010-111111受控設置幀011100-111111控制命令幀011110-111111閾值設置幀
3.1.2 在線檢測機制
協(xié)調器向分控器請求數(shù)據(jù)前先要確認其是否在線。協(xié)調器每隔500 ms對CAN網(wǎng)絡內的分控器發(fā)起一次輪詢檢測,采用“三次握手”方式確認分控器是否在線。若在輪詢檢測中向某分控器發(fā)送測試幀,連續(xù)三次均未收到回復,則認為該分控器已掉線,向接下去的分控器發(fā)起測試。在線檢測通信過程如圖6所示。
圖6 在線檢測通信過程
3.2 分控器軟件設計
分控器的職責是采集爬架組的基本信息并對電機進行控制,其軟件設計可分為主程序和中斷服務程序兩部分。在主程序中,分控器先進行硬件資源初始化和開機自檢。接著判斷自己是否接入CAN通信網(wǎng)絡,若成功接入就采集爬架的基本參數(shù)信息,包括拉力、高度、傾角,然后把這些數(shù)據(jù)通過傳感器信息幀發(fā)給協(xié)調器,此外還要響應控制指令對電機進行控制。主程序的工作流程如圖7所示。中斷服務程序主要包括:通信狀態(tài)的檢測、按鍵信號的掃描、CAN通信處理和故障信息處理。其中CAN通信處理是指分控器接收到協(xié)調器下發(fā)的各種CAN數(shù)據(jù)幀后并進行相應的處理。故障信息處理是指分控器集中處理檢測到的故障信息并通過報警幀發(fā)給協(xié)調器。
圖7 分控器主程序流程
3.3 協(xié)調器軟件設計
為了提高系統(tǒng)的實時性,協(xié)調器在μC/OS-II操作系統(tǒng)的基礎上進行軟件設計[9],其軟件結構可分為3層:驅動層、操作系統(tǒng)層和應用層。應用層包括3個任務,分別為WiFi通信任務和CAN通信任務、LCD顯示任務。在WiFi通信任務里,協(xié)調器一面接收上位機下發(fā)的命令,另一面將數(shù)據(jù)打包發(fā)送給上位機;在CAN通信任務里,協(xié)調器主要負責在CAN通信網(wǎng)絡里與各個分控器進行數(shù)據(jù)交互;LCD顯示任務中主要是顯示協(xié)調器與各個分控器以及上位機的通信狀況。協(xié)調器的軟件結構如圖8所示。
圖8 協(xié)調器軟件結構
3.4 WiFi通信設計
協(xié)調器與上位機之間的無線通信采用TCP/IP協(xié)議。TCP協(xié)議提供了無差錯的數(shù)據(jù)傳輸,保證了數(shù)據(jù)通信的可靠性,并且同時提供了流量控制和擁塞控制[10-11],所以在對數(shù)據(jù)包進行解析時,大大降低了PC端上位機軟件的處理壓力。為了適應協(xié)調器與上位機之間的數(shù)據(jù)傳輸特點,在TCP/IP協(xié)議以上制定了滿足系統(tǒng)功能需要的數(shù)據(jù)包格式。起始符和結束符各占兩個字節(jié),規(guī)定了數(shù)據(jù)包的開始和結束。包類型規(guī)定了數(shù)據(jù)包的類型是狀態(tài)數(shù)據(jù)包還是命令數(shù)據(jù)包,狀態(tài)數(shù)據(jù)包是協(xié)調器向上發(fā)送的爬架參數(shù)信息,命令數(shù)據(jù)包是上位機向下發(fā)送的控制命令。包長度規(guī)定了數(shù)據(jù)包中數(shù)據(jù)的長度。數(shù)據(jù)包的具體定義如圖9所示。
起始符(2byte)包類型(1byte)包長度(1byte)數(shù)據(jù)1(1byte)…數(shù)據(jù)n(1byte)結束符(2byte)
圖9數(shù)據(jù)包格式
WiFi模塊的配置以及通信功能的實現(xiàn)是通過向其發(fā)送AT指令來完成的。在協(xié)調器中通過MCU用串口向模塊發(fā)AT指令的方式將ESP8266配置為AP模式,在這個模式下WiFi模塊是無線網(wǎng)絡接入點(相當于路由器),而PC機則是個無線終端。為了方便應用層的調用,在驅動層中編寫WiFi收發(fā)函數(shù):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通信任務中協(xié)調器與上位機的通信流程如圖10所示。
圖10 WiFi通信流程
3.5 上位機軟件設計
上位機軟件是整個監(jiān)控系統(tǒng)的核心,其職責是實時監(jiān)控爬架組的參數(shù)信息,幫助用戶及時發(fā)現(xiàn)故障、處理報警,保證爬架穩(wěn)定安全地運行。上位機軟件是采用圖形化編程語言LabVIEW編寫的。LabVIEW集成了大量有關數(shù)據(jù)的采集、分析、顯示和存儲的工具和函數(shù),在測量、監(jiān)控等領域具有明顯的優(yōu)勢[12]。
上位機的軟件設計包括三大部分:WiFi通信、數(shù)據(jù)處理和系統(tǒng)控制。首先是WiFi通信,當上位機檢測到WiFi開啟后,打開TCP連接函數(shù)并輸入相應的IP地址和端口號[13],然后調用TCP read讀取TCP數(shù)據(jù)將其放在接收緩存區(qū)。接著是數(shù)據(jù)處理,對接收緩存區(qū)中的數(shù)據(jù)進行解析,然后按照不同的需求對其進行處理分別是數(shù)據(jù)顯示、數(shù)據(jù)存儲和數(shù)據(jù)查詢。系統(tǒng)控制是相對獨立的一部分,包括參數(shù)設置、激活組設置和動作控制,每部分的操作指令都會轉換成命令數(shù)據(jù)包的形式,通過調用TCP write下發(fā)給協(xié)調器。上位機的軟件結構如圖11所示,上位機的程序流程如圖12所示。
圖11 上位機軟件結構
圖12 上位機程序流程
首先上位機對用到的資源進行初始化,包括顯示控件恢復到默認的狀態(tài),系統(tǒng)參數(shù)從配置文件中加載出來,參數(shù)閾值從本地磁盤的文件中讀出來等。接著打開WiFi與協(xié)調器進行通信,上位機通過協(xié)調器來接收在線分控器采集的爬架基本參數(shù)信息并顯示,根據(jù)用戶的操作決定是否將數(shù)據(jù)保存或是否查詢數(shù)據(jù)庫。然后根據(jù)閾值參數(shù)判斷爬架參數(shù)是否正常,若異常進行報警指示。最后用戶選定激活組并對組內的爬架進行控制,通過TCP write將指令下發(fā)給協(xié)調器。
對系統(tǒng)的功能與性能進行測試,用CAN總線連接分控器和協(xié)調器,當系統(tǒng)上電后打開PC端的上位機軟件,系統(tǒng)運行時的上位機軟件圖形界面如圖13所示。
按照功能可以將上位機界面分為參數(shù)設置、記錄查看、系統(tǒng)控制、狀態(tài)顯示這4個區(qū)域。參數(shù)設置是用戶可以根據(jù)實際需求設定傳感器的報警閾值,并將其下發(fā)給各個分控器。記錄查看是幫助用戶可查看所有爬架組的傳感器信息和故障信息,并且上位機會定時將這些信息存儲到數(shù)據(jù)庫文件里供用戶查看歷史記錄。在系統(tǒng)控制中用戶通過點擊圖形按鈕直接操控爬架的升降。狀態(tài)顯示是上位機會將爬架組的所有信息(包括拉力、高度、傾角、故障信息)通過圖形化的方式在左側面板上顯示出來,用戶可以很直觀地觀察到爬架的安全狀況。
圖13 上位機軟件圖形界面
本文設計了一種基于CAN總線和WiFi通信的爬架組監(jiān)控系統(tǒng)。該系統(tǒng)主要由分控器、協(xié)調器和PC端上位機構成,采用可靠性更高的CAN總線構建協(xié)調器與各分控器間通信網(wǎng)絡,使得網(wǎng)絡內各站點間能自由通信,大大提高了系統(tǒng)的可靠性和實時性。采用WiFi模塊實現(xiàn)協(xié)調器和PC端上位機的無線通信,PC機可在任何接收到無線的地方對爬架進行監(jiān)控,克服了現(xiàn)有監(jiān)控系統(tǒng)受有線連接限制的弊端,提高了系統(tǒng)的靈活性和便捷性。實際測試表明該系統(tǒng)運行安全可靠,能有效提高爬架運行的安全性,保障施工人員的人身安全,在建筑施工領域有良好的應用前景。
[1] 李會良.爬架在高層建筑施工中的應用研究[D].西安:長安大學,2010.
[2] 葛川玲,劉坤,孔祥玉.集成式爬架在住宅樓施工中的應用[J].建筑施工,2015,37(9):1094-1096.
[3] 祝永成,焦紅衛(wèi).液壓步進式爬架提升技術研究[J].國外建材科技,2006(5):47-50.
[4] 羅少軒,喬愛民,王艷春,等.一種新型附著式升降腳手架控制系統(tǒng)設計[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的無線測控系統(tǒng)設計與實現(xiàn)[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協(xié)議的電工電子網(wǎng)絡實驗室[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在數(shù)據(jù)采集系統(tǒng)中的應用研究[J].國外電子測量技術,2014,33(6):103-106.
[13] 方立軍,陳衛(wèi)松,章良玉,等.基于STM32的以太網(wǎng)網(wǎng)絡視頻監(jiān)控系統(tǒng)[J].無線電通信技術,2017,43(5):91-94.