摘要: 變制冷劑流量(VRV) 空調控制系統(tǒng)具有多傳感器、溫度數據具有時滯特性，維護程序代碼和功能調試非常困難，因而提出利用VRV 系統(tǒng)的通信網絡和單片機的Bootloader 特性,，開發(fā)基于CAN 總線的遠程下載功能。根據VRV 控制系統(tǒng)的應用需求,，制訂了通訊協議,，實現了包括單點、多點及廣播等多種遠程下載方式,，并具有軟件復位,、數據加解密、異常處理等新功能,。該技術已經應用于VRV 空調控制系統(tǒng)的開發(fā)調試,，應用效果良好,。
0 引 言
變制冷劑流量(Variable Refrigerant Volume, VRV)空調系統(tǒng)是一種網絡空調系統(tǒng),，由制冷劑管路網絡和通訊信息流網絡組成，并且一臺室外機通過配管和通訊總線連接多臺室內機,，由在監(jiān)控室的監(jiān)控PC 機,，監(jiān)控整個系統(tǒng)的運行狀態(tài)。系統(tǒng)結構簡圖如圖1 所示,。
VRV 空調系統(tǒng)結構簡圖
圖 1 VRV 空調系統(tǒng)結構簡圖
系統(tǒng)控制信息通過通信網絡傳輸,，實現對制冷劑管路網絡中制冷劑流量的精確調配，可使系統(tǒng)具有控溫舒適可靠,、節(jié)能環(huán)保,、節(jié)省建筑空間等優(yōu)勢，近十幾年得到迅猛的普及,。
通訊信息流網絡是VRV 系統(tǒng)的重要組成部分,。下文為敘述方便，將監(jiān)控PC 機稱為主機端、室外機和室內機統(tǒng)稱為目標端,。
由于每套系統(tǒng)都有多個參數需要傳感器實時檢測,，并且溫度數據本身具有很大的時滯性，因而維護程序代碼和功能調試非常困難,。本文提出一種利用VRV 的通信網絡和監(jiān)控PC機進行程序遠程下載的方法,。
另外，VRV 空調系統(tǒng)的通信信息流網絡目前還沒有統(tǒng)一的總線標準,，國際上各大廠家都是制定自己的總線標準,，兼容性不夠。我們在系統(tǒng)設計VRV 控制系統(tǒng)時,，經多方比較,，最后鑒于CAN 總線高安全性、故障自動退出等優(yōu)勢,，選擇CAN 總線作為系統(tǒng)的通訊總線,。
VRV 系統(tǒng)的室外機和室內機選一款支持CAN 模塊的Microchip公司的dsPIC33FJ 單片機作為主控制芯片。并且這款單片機本身支持Bootloader 功能,，這為開發(fā)遠程下載,，進而實現系統(tǒng)維護和程序更新提供了一種可能。
本文開發(fā)出一種基于 CAN 總線,，支持單點,、多點及廣播等多種方式的遠程下載的技術，并具有軟件復位,、異常處理,、數據加/解密等突出功能。這些功能極大方便了對VRV 空調控制系統(tǒng)的維護和應用,，也為初期進行空系統(tǒng)的設計,、開發(fā)、調試提供了一種極為便利的手段,。
1 總體設計方案
1.1 遠程下載原理
目標端復位后,，在一個指定的時間內，目標端都監(jiān)測與主機端相連的通訊總線是否有數據流活動,。如果有,，則跳轉到Bootloader 自舉程序，執(zhí)行Bootloader 自舉功能,，將接收的數據,，寫入目標端的用戶應用程序段，直到全部數據接收完成后,，再跳轉到用戶應用程序段,，執(zhí)行剛接收到的新代碼,，實現用戶應用程序的更新。如果超過時限,，都沒有監(jiān)測到該總線上有數據流活動,，則直接跳轉到用戶應用程序段，執(zhí)行原有的程序功能,。
在此一共有三段程序：
⑴目標端的自舉程序和用戶應用程序,。這兩個程序都是基于MAPLAB IDE 工具開發(fā)。
⑵主機端程序,。這個程序是用Visual Studio C++開發(fā),，只有主機端程序才能主動發(fā)起與目標端自舉程序間的通信。
整個通訊過程如圖2 所示,，其中：
(1)主機端程序讀取和解析MAPLAB IDE 編譯器生成的用戶應用程序,，并組織數據。
(2)通過CAN 總線將解析,、重組后的數據傳輸給目標端器件,。
(3)目標端自舉程序(Bootloader)，將收到的數據加載到目標端器件相應的FALSH 段上,。
通訊過程示意圖
圖 2 通訊過程示意圖
1.2 系統(tǒng)功能設計
在整個設計開發(fā)中,，關鍵之處是目標端 Bootloader 自舉程序的開發(fā)。結合到VRV 空調系統(tǒng)的實際應用,，整個系統(tǒng)應該至少具有以下功能：
(1)多種下載方式的提供,。VRV 空調系統(tǒng)運行當中，可能需要根據實際情況采用不同的方式來進行遠程下載,。因而需要實現對單點,、多點及廣播等通訊方式的支持。
(2)軟件復位功能,。即便是目標端設備已經具備利用Bootloader 自舉程序來實現遠程下載的能力,，但由于Bootloader 機制需要目標端先復位，才能重新再執(zhí)行Bootloader 自舉程序,。
然而現場環(huán)境往往不能實施掉電或其他硬件方式復位目標端設備,，這便需要有軟件實現復位的手段,。在此,，將軟件復位作為自定義的通訊協議中一個命令，由主機端發(fā)送給目標端,，目標端的用戶應用程序內接收到這一命令,，經過解析、確認后進行復位,。
(3)加/解密功能,。鑒于多聯機空調系統(tǒng)的商用價值,，Bootloader 程序應當具備加密的功能，保護知識產權,。這可以通過主機端和目標端之間采用一種密鑰或加,、解密算法，融合到通訊數據中實現,。
(4)異常處理功能,。在通訊過程中，很有可能出現如主機端出現故障,，造成當前的數據不能繼續(xù)成功發(fā)給目標端,。目標端運行自舉程序時，只有等到主機端數據全部通訊完畢,，才可以跳轉到用戶應用程序,，繼續(xù)執(zhí)行。此會造成目標端一直處于等待狀態(tài),，效率低下或者接收錯誤數據并執(zhí)行,，以致出現嚴重后果。在系統(tǒng)設計開發(fā)時需要預留一個能夠實現異常處理的命令以便主機端恢復后,，將這個命令下發(fā),，目標段根據這個命令，重新接收正確的數據,。
2 協議設計
要將系統(tǒng)的目標端和主機端之間,，設計成支持單點、多點以及廣播等多種遠程下載方式,，并且支持,、軟件復位和異常處理、加解密等功能,，可以充分利用 CAN 總線數據幀的29 位（遵循CAN2.0B 協議）標識符來實現,。定制的通訊協議中CAN 的幀格式如表1 所示，將CAN 的29 位標示符分為五段：優(yōu)先級,、控制域,、通訊方式、節(jié)點編號,、命令編號,。
表 1 數據幀29 位標識符分配表
數據幀29 位標識符分配表
優(yōu)先級：00->01->10->11 優(yōu)先級別依次降低，默認優(yōu)先級別為11,，故障報警優(yōu)先級最高為00,，數據傳輸優(yōu)先級為01，命令下傳優(yōu)先級為10,，應答返回優(yōu)先級為11,。
控制域：ID26/ID22,，用以表示當前的數據幀屬于哪一種類型：故障為00、數據為01,、命令10,、應答11。
通訊方式：ID24/ID15,，指定當前的數據幀是廣播傳輸或者單點傳輸,，全為0 是單點而全為1 是廣播。
節(jié)點編號：ID14/ID8,，共7 位,，足夠標識CAN 總線支持的多達112 個節(jié)點的最大負載。
命令編號：這里存放的是根據實際需要定制的一些命令,，如軟件復位命令,、異常處理命令。主機端將定制的命令編號下發(fā),，目標端接收到命令后,，解析后執(zhí)行相應動作。仿照上表,，配置各個目標端的接收過濾碼和接收屏蔽碼,，便可以實現單點、多點以及廣播通訊,。另外,，對于單點通訊方式下的遠程下載，為保證主機端和目標端的通訊數據的正確和可靠傳輸,，采用應答機制來實現,，并定制了一套圖3 所示的通訊鏈路機制。
主機端和目標端應答鏈路機制圖
圖 3 主機端和目標端應答鏈路機制圖
遠程下載的通訊只能由主機端開啟,。主機端先發(fā)送讀取器件型號命令,，讀取目標端器件芯片型號，目標端收到這個命令,，回復本身的型號數據作為一個應答,，主機端根據這個型號，再開辟動態(tài)內存和組織要下傳的數據,。主機端接著下發(fā)一個讀取器件PROM 命令,，以獲取目標端器件位于地址0x00 處的數據，將和從主機端讀取并解析,、組織后的HEX 文件一起下傳,。主機端收到這一步的應答后,，開始發(fā)送寫PROM 命令和PROM 數據,，目標端將接收到的數據寫入相應的地址段,，每完成一頁寫操作，返回一個應答,接著接收主機端下傳的下一頁數據,。PROM 寫數據發(fā)送完后,，主機端接著發(fā)送寫CM 數據命令和寫CM 數據，過程和寫PROM 是一樣的,。最后,，主機端下發(fā)一個跳轉命令，目標端收到這個命令后,，跳轉到程序存儲器的0x00 地址處,。然后，目標端根據地址0x00 處存放的數據,，跳轉到用戶應用程序,。
而對于多點或廣播，通常都是對數百甚至上千目標端進行下載,。如果目標端都應答,，會造成總線上數據的堵塞，浪費大量的總線時間,。所以采用非應答機制,，直接燒寫程序存儲器。
此時主機端數據的下傳,，采用定時器觸發(fā)方式,。每當定時時間到達時，觸發(fā)一次數據的發(fā)送,。
直至最后,，發(fā)送一個跳轉命令。如果目標端沒有執(zhí)行跳轉,，那么認為當前目標端沒能正確接收主機端發(fā)送的數據,，主機端重新對當前目標端進行一次單點方式下的遠程下載。
3 目標端設計方案
目標端Bootloader 自舉程序一般只是一個簡單的通訊程序,，負責接收和發(fā)送數據,，通常只需極少的存儲空間，可以位于單片機程序存儲器特定的Boot Segment 區(qū)域,。程序存儲器還有一段稱為General Segment 區(qū)域可用于存儲用戶應用程序,。單片機的程序存儲器大多都是FLASH 閃存，數據是以一個個數據頁的形式存儲,，必須先對當前存儲頁擦除,，然后才能寫入數據。自舉程序還需使用dsPIC33 單片機器件中斷向量表 (IVT) 中的復位向量實現程序的跳轉,、以及器件上的CAN 通信模塊,。單片機的程序存儲器的地址映射如下圖4 所示,。
dsPIC33F 程序存儲器地址映射圖
圖 4 dsPIC33F 程序存儲器地址映射圖
上圖給出了dsPIC33 單片機器件的程序存儲器的物理地址映射，由圖可知用戶應用代碼應放置在用戶應用程序地址段,，而Bootloader 代碼放在自舉程序地址段,。不論目標端自舉程序(Bootloader)需多少存儲空間，自舉程序(Bootloader)和用戶應用程序的存儲位置都必須嚴格遵守目標端存儲器構架,。在具體設計中,，須注意：
(1)慎用中斷：Bootloader 自舉程序不建議使用中斷方式。目標端器件在寫Flash 程序存儲器時,，有一個擦除程序存儲器的操作,，可能會擦除掉位于程序存儲器上的中斷向量表和備用中斷向量表地址處的值，造成系統(tǒng)的死機,。另外,，一個功能強大的程序，一般都是用中斷方式實現用戶應用程序以提高實時性,，這會生成一個中斷向量表,，存儲在目標端器件程指定中斷向量表和備用中斷向量表地址處。如果在 Bootloader 自舉程序也用中斷方式,，會使得一個目標端器件產生兩個不一樣的中斷向量表和備用中斷向量表區(qū),，造成系統(tǒng)的死機。
(2)存儲位置：Bootloader 程序和用戶應用程序不應處于同一頁,。自舉程序(Bootloader)要先執(zhí)行擦除程序存儲器,，才能將接收的新代碼存入其中。如果處于同一頁,，在遠程下載時,，很可能擦除Bootloader 程序本身。
(3)自舉延時：必須為目標端自舉程序的執(zhí)行指定一個延時值,，這個延時值作為檢測總線數據流活動的時限,。
(4)鏈接文件配置：單片機默認的自舉程序地址段是0X400 到0XC00。如果實際的自舉程序代碼量超過上述空間,，需要修改鏈接文件,，重新配置，以適合工程需要,。
4 主機端設計方案
主機端的設計主要包含主機端通訊程序的實現,，并為用戶提供一個管理遠程下載、軟件復位,、異常處理等功能的監(jiān)控界面,。主機端程序，采用了多線程的通信存儲技術，一共包含線程:主線程,、接收線程,、遠程下載線程，使得程序執(zhí)行效率較高,。
上位機軟件界面圖
圖5 上位機軟件界面圖
軟件界面如上圖 5 所示,，在這里實現的主要功能有：
(1)參數設置功能,，包括CAN 的連接,、斷開、復位,、啟動,、接收過濾碼和接收屏蔽碼等CAN 自身參數的設置。
(2)文件導入功能,，載入存儲在任意目錄下目標端用戶應用程序的HEX 文件,。
(3)遠程下載功能，這一功能由“更新按鈕”觸發(fā)產生,，啟動主機端程序和目標端的通信,，實現遠程下載。
(4)狀態(tài)顯示功能,，由兩個列表框,，用于顯示導入的HEX 文件的數據，和實時顯示當前的通訊狀態(tài),。
(5)軟件復位功能,，這一功能由“自舉復位”觸發(fā)產生，發(fā)送一個復位命令和異常處理命令,，目標端根據命令進行相應操作,。
5 結束語
本文結合VRV 空調控制系統(tǒng)開發(fā)的實際應用需求，以dsPIC33 單片機為硬件基礎,，開發(fā)了基于CAN 的遠程下載系統(tǒng),。系統(tǒng)同時支持單點、多點,、廣播等下載方式,，具有數據加密、軟件復位,、異常處理等以往所開發(fā)的遠程下載技術所不具備的功能,。
本文主機端程序的設計采用了多線程的通信存儲技術，保證了程序的高效性和擴展性,，并且可實時監(jiān)測系統(tǒng)的狀態(tài),，界面風格簡潔明了，符合工程人員操作習慣。目標端嚴格按照dsPIC33F 單片機的體系構架,，進行代碼開發(fā)和鏈接文件的修改及配置,，程序簡潔易讀、安全可靠,。本系統(tǒng)2009 年初進行實驗平臺的聯機調試,，性能良好。
本文作者創(chuàng)新點：結合VRV 空調控制系統(tǒng)具有多傳感器,、溫度數據具有時滯特性,，利用VRV 空調系統(tǒng)的通訊信息網絡，開發(fā)遠程下載技術,，節(jié)省成本提高效能,；實現了軟件復位和故障處理以及加解密等實際工況的需要，使得更為符合實際現場的需要,。
