方便、舒適、高效、安全，以及環(huán)保節(jié)能等作為人們對自身生活和工作場所的基本要求由來已久。自上世紀90年代以來，隨著數(shù)字通信技術和信息技術的飛速發(fā)展，基于網(wǎng)絡的智能化建筑和住宅是該領域的一個主要發(fā)展方向。
    現(xiàn)介紹其中一種利用ARM技術、嵌入式實時內(nèi)核和TCP協(xié)議設計的現(xiàn)場數(shù)據(jù)采集器。

1 現(xiàn)場數(shù)據(jù)采集器的基本功能
    “一線通”系統(tǒng)的基本架構如圖1所示，3臺管理計算機互為冗余。

    系統(tǒng)是面向設備管理的，基本功能可歸結為三點，即“監(jiān)”、“控’’和“報警”?！氨O(jiān)”是指管理機查詢設備的狀態(tài)；
控，是管理者通過監(jiān)控界面操縱現(xiàn)場設備；“報警”是當設備運行狀態(tài)超越報警限時，及時向管理機報告。管理機監(jiān)控界面采用組態(tài)王6.5通用組態(tài)軟件進行設計。
    “一線通”系統(tǒng)將監(jiān)測與報警合并。在現(xiàn)場，設備的DEC控制器和智能儀表通過485總線連接到數(shù)據(jù)采集器，在整理設備狀態(tài)數(shù)據(jù)的基礎上，根據(jù)狀態(tài)的變化，由采集器向管理機發(fā)送設備最新變化狀態(tài)。徹底避免了無謂的查詢，減輕了網(wǎng)絡的通信負荷。這就是數(shù)據(jù)采集器的由來。

    現(xiàn)場數(shù)據(jù)采集器的基本功能要求分為兩個方面。首先，要定期采集各DDC控制器(以下稱子站)和智能儀表中的狀態(tài)數(shù)據(jù)，并將狀態(tài)變化信息發(fā)送到管理機。其次，也要傳遞管理機對設備的控制命令。

2 現(xiàn)場數(shù)據(jù)采集器的設計實現(xiàn)
    設計采用了EasyARM2200開發(fā)板，CPU是Philips公司的32位嵌入式處理器LPC2210(ARM7TDMI-S核)。開發(fā)板基本結構如圖2所示[1]。CPU采用11.059 2 MHz晶振，通過片內(nèi)鎖相環(huán)和外設分頻器，分別獲得44 MHz系統(tǒng)時鐘和11 MHz外設時鐘頻率。串行通信波特率為19 200 bps。
    采集器用C語言編制實現(xiàn)。設計大致分四步進行。

(1) 協(xié)議設計
    在“一線通”系統(tǒng)中，設備以采集器號、子站號和設備號惟一確定。管理機用采集器號區(qū)別局域網(wǎng)上的采集器。采集器用子站號標識總線上的DDC控制器。同一子站下可能有不止一個設備，相互以設備號區(qū)分。
    所有的狀態(tài)和控制數(shù)據(jù)都以設備為單位進行組織。通過工程項目的配置文件，系統(tǒng)中確定的設備與具體設備類型聯(lián)系起來。采集器中設備狀態(tài)數(shù)據(jù)塊格式定義為

   

    設備狀態(tài)數(shù)據(jù)和控制數(shù)據(jù)格式由設備類型數(shù)據(jù)協(xié)議規(guī)定。
    采集器與子站的串行通信數(shù)據(jù)幀基本格式為

STX

協(xié)議數(shù)據(jù)

ETX

校驗和

    所有協(xié)議數(shù)據(jù)傳輸字節(jié)加ETX生成校驗和。由16個ASCII字符O～9、A～B作為傳輸字節(jié)對協(xié)議數(shù)據(jù)和校驗和進行編碼，傳輸字節(jié)的最高位用作奇偶校驗位。
    通信采用主從方式，由采集器向子站寫控制數(shù)據(jù)。寫命令幀協(xié)議數(shù)據(jù)為
其中Write為寫命令字節(jié)。設備控制數(shù)據(jù)塊可任意組合到寫命令幀中。
    讀設備數(shù)據(jù)時，采集器先發(fā)讀子站命令，并等待應答。相應子站在收到讀命令后，還以應答幀。讀命令幀協(xié)議數(shù)據(jù)為

其中Read為讀命令字節(jié)。子站應答幀協(xié)議數(shù)據(jù)為

    采集器與管理機的通信應用層用戶數(shù)據(jù)報基本格式為
設備狀態(tài)數(shù)據(jù)塊或控制數(shù)據(jù)塊可任意組合到用戶數(shù)據(jù)域中。標志字符指明用戶數(shù)據(jù)的類型。例如，是采集器向管理機發(fā)送的設備狀態(tài)數(shù)據(jù)塊組合，還是管理機向采集器發(fā)送的設備控制數(shù)據(jù)塊組合。
(2)數(shù)據(jù)結構
    采集器中，為設備控制數(shù)據(jù)塊設置從網(wǎng)口到串口的隊列。設備狀態(tài)數(shù)據(jù)塊須定期地從各子站中讀取并刷新存儲，變化的狀態(tài)須向管理機發(fā)送。為此，設置子站項和設備記錄塊兩種基本結構，構成三種鏈表，如圖3所示。

    子站項的基本域是子站號。各子站項通過指針NextDDC相互連接，構成一個循環(huán)鏈表，管理對子站的采集過程。指針CurrDDC指向當前正被訪問的子站項。采集器根據(jù)CurrDDC沿循環(huán)鏈表的依次移動，確定下一個訪問的子站站號。
    在子站項數(shù)據(jù)域中設置了一個故障計數(shù)器。當某子站對采集器讀命令連續(xù)多次無正常應答時，采集器判定其故障，將暫停對其讀取，并啟動計數(shù)器。計時結束后再嘗試重新訪問該子站。如果成功，便恢復正常；否則，停止讀取而重新計時。這樣將大大減少對故障子站的超時等待時間，實現(xiàn)了故障屏蔽和自動恢復的連接重試功能。
    設備記錄塊的基本域是設備號。在其記錄數(shù)據(jù)域中存放著一個完整的最新設備狀態(tài)數(shù)據(jù)塊，由記錄長度域指明長度。
    每個子站下連接著數(shù)目不等的若干個設備，每個設備對應一個設備記錄塊。同一子站下的設備記錄塊通過指針域RBPtr連成一個單鏈表。采集器能根據(jù)子站下設備的增加自動添加設備記錄塊。
    狀態(tài)發(fā)生變化的設備記錄塊由指針域RBInList連接成發(fā)送鏈表。以太網(wǎng)發(fā)送程序將給設備狀態(tài)數(shù)據(jù)塊加上采集器號，組合到用戶數(shù)據(jù)報中。這樣的方式能保證發(fā)送設備最新的狀態(tài)數(shù)據(jù)。
(3)任務設計
    μC/OS-II(v2.52)被移植到LPC2210上，是獨立于采集器程序外的一段代碼。作為可剝奪型內(nèi)核，它能保證實時性的需要，使時間要求苛刻的事件得到快捷的處理[1]。
    采集器程序由一組任務構成，如表1所列。

    Task_UartProcess()是采集器的核心任務。它依次循環(huán)地完成：
    ◆發(fā)送寫命令幀(如果有控制數(shù)據(jù)塊)。從設備控制數(shù)據(jù)塊隊列中取出新的控制數(shù)據(jù)塊，組合到寫命令幀中。利用串行發(fā)送中斷服務發(fā)送寫命令幀。
    ◆發(fā)送讀命令幀。從子站項循環(huán)鏈表中獲得訪問子站號，生成讀命令幀。同樣，利用串行發(fā)送中斷服務發(fā)送讀命令幀。
    ◆等待子站應答幀。當收到UartRcvMbox中消息或超時退出時，進入應答幀數(shù)據(jù)處理程序。數(shù)據(jù)處理程序完成對設備狀態(tài)數(shù)據(jù)塊的刷新存儲和變化處理。
    ◆發(fā)采集信號量通知發(fā)送服務器和發(fā)送客戶端。
(4)程序設計
    LPC2210上電后需運行一段匯編代碼，完成中斷向量表的定義和重映射，外部存儲控制器的初始化，并分配系統(tǒng)堆?？臻g，然后進入main()函數(shù)[2，3]。

    在main()中：
    ◆調用()SInit()函數(shù)對內(nèi)核多任務調度所用系統(tǒng)變量和數(shù)據(jù)結構完成初始化，并建立空閑任務[1]。
    ◆調用()SStart()函數(shù)進入內(nèi)核[1]。
    內(nèi)核中集成了TCP/IP協(xié)議[4]棧，數(shù)據(jù)報交換通過連接來進行。主要Socket API[2]函數(shù)如表2所列。
    在ADS開發(fā)環(huán)境下，函數(shù)都是可重入的[3]。
    采集器發(fā)送客戶端或發(fā)送服務器均能獨立地完成對變化的設備狀態(tài)數(shù)據(jù)塊的發(fā)送，和對控制數(shù)據(jù)塊的接收。采集器發(fā)送客戶端程序狀態(tài)如圖4左端所示。調用connect()函數(shù)發(fā)起與管理機的連接。連接只需與三臺管理機之一建立即可。
    連接建立后，可用send()發(fā)送設備狀態(tài)數(shù)據(jù)塊組合幀。采集器在訪問每個子站后，都要檢查設備狀態(tài)變化情況，并及時向管理機匯報。
    當故障發(fā)生時，send()函數(shù)將不能成功返回。若干次發(fā)送失敗后，客戶端程序將調用close()斷開連接，然后重新發(fā)起建立連接。
    實際上，close()并不一定能正常斷開連接，這將影響連接的重新建立。故約定，當設備狀態(tài)無變化時，采集器也將間隔一定時間發(fā)送一個空數(shù)據(jù)報。進入故障處理后，管理機因收不到定期的空數(shù)據(jù)報，亦將關閉連接而重新偵聽。

    采集器發(fā)送服務器程序狀態(tài)如圖4右端所示。事先指定偵聽的連接數(shù)，通過accept()函數(shù)查看管理機與采集器的連接情況。
    當有管理機連接后，即可通過send()發(fā)送設備狀態(tài)數(shù)據(jù)塊幀，所有過程同客戶端中一樣。不同的只是，當進入故障處理后，將退回到accept()重新偵聽遠程連接。 
    采集器由5個源文件和6個頭文件組成，編譯后約8 KB代碼。包括啟動代碼、實時內(nèi)核和TCP/IP協(xié)議棧后，總共40 KB，并占用125 KB數(shù)據(jù)空間。
    管理計算機可對采集器的數(shù)據(jù)結構和工作方式等進行必要的配置。
    采集器正常工作時測得的串口通信時序示意圖如圖5所示。其中，讀命令幀歷時約3.8 ms，子站應答幀約13.2 ms.子站應答延遲取決于子站的處理時間。

    由圖5可見，子站的訪問時間約35 ms。期間除完成子站訪問外，還包括以太網(wǎng)發(fā)送等各項任務。如果要求總線訪問周期小于1 s，則可連接25個子站。

結 語
    本文介紹的現(xiàn)場數(shù)據(jù)采集器采用32位ARM處理器加實時內(nèi)核μC/OS-II的嵌入式實現(xiàn)方案。它將現(xiàn)場各類設備與管理計算機連接起來，使智能小區(qū)“一線通”監(jiān)控系統(tǒng)的結構和對網(wǎng)絡資源的利用更趨合理。
    通常，對電梯運行狀態(tài)的監(jiān)控實時性要求較高，延遲一般應小于O.5 s。其他諸如安防報警等，也應小于2 s。現(xiàn)場數(shù)據(jù)采集器能很好地滿足實時性要求。當十臺電梯均以4 m/s以上的高速模擬運行時，監(jiān)控界面上所有的參數(shù)都能及時得到反映，并幾乎感覺不到延遲。事實上，每個狀態(tài)的數(shù)據(jù)都能被傳遞達2次以上。
    現(xiàn)場數(shù)據(jù)采集器已被成功地使用于上海金色家園等多處智能化小區(qū)工程中。