空調發(fā)電車運行狀態(tài)記錄儀

趙志春,孫華勇,殷樹松

(1 北京交通大學 電氣工程學院,北京100044;2 濟南鐵路局 車輛處,山東濟南250001;3 濟南鐵路局 科學技術研究所,山東濟南250001)

空調發(fā)電車是空調列車的重要組成部分,其工作狀況直接影響到列車能否正常運行。實際工作中,對發(fā)電機組的運行狀況進行實時監(jiān)測記錄是保證機組正常運行的重要措施。技術人員通過運行數(shù)據(jù)了解機組全過程的運行狀況,有針對性對機組進行檢修維護,目前這項工作是依靠乘務員每小時查看一次顯示儀表并記錄數(shù)據(jù)來完成的。技術人員反映采用人工方式取得運行數(shù)據(jù)有很大的缺點,獲得的數(shù)據(jù)基本上無法作為判斷發(fā)電車運行狀況好壞的依據(jù),也無法為檢修提供有用的信息。經(jīng)分析造成這種狀況的原因主要有以下兩個:(1)記錄間隔時間過長,數(shù)據(jù)不連續(xù),無法獲知記錄間隔之間的運行狀況。(2)沒有客觀監(jiān)督措施,數(shù)據(jù)受人工的影響較大。人工疏忽及觀察角度的不同容易造成誤讀,不能保證數(shù)據(jù)的有效性和真實性。由于技術人無法獲得準確連續(xù)的運行數(shù)據(jù),致使不能及時發(fā)現(xiàn)機組運行中的異常,隨著異常運轉時間的延長使隱患擴展成了故障,造成嚴重后果。鑒于這種情況,我們認為有必要針對發(fā)電車的特點研制一套專用的運行數(shù)據(jù)記錄裝置,以便為技術人員提供全過程的運行數(shù)據(jù),及時發(fā)現(xiàn)運行隱患,預防發(fā)生故障。

針對現(xiàn)場的實際需求,我們研制了“空調發(fā)電車運行狀態(tài)記錄儀”。通過該記錄儀不但實現(xiàn)了對設備運行狀況的連續(xù)監(jiān)測記錄,而且客觀上也起到了對乘務員的監(jiān)督作用,有利于提高乘務員的操作水平。通過對運行數(shù)據(jù)進行觀察分析可以提前發(fā)現(xiàn)運行中的不穩(wěn)定因素和故障隱患,做到提前發(fā)現(xiàn)、提前預防,從而改變目前發(fā)電車檢修維護的被動局面,保障行車安全。

1 系統(tǒng)總體組成

系統(tǒng)總體組成如圖1所示。記錄儀車載部分包括記錄儀主機、數(shù)據(jù)采集子機及專用軟件,它負責實時檢測記錄3個發(fā)電機組的運行參數(shù),如每個機組的各相供電電壓、電流、頻率、功率以及柴油機的油溫、油壓、水溫等。本裝置利用CF卡作為數(shù)據(jù)存儲介質,可以把數(shù)據(jù)轉存到微機中供分析使用。地面分析系統(tǒng)可對記錄的數(shù)據(jù)進行處理,以圖表的形式向技術人員提供設備全過程的運行狀況。

圖1 運行狀況圖

2 硬件設計

2.1 車載部分硬件結構

硬件設計中遵循了COTS(Commercial Off-The-Shelf)思想,即設計中盡量選用成熟的、現(xiàn)有的模塊,不自行開發(fā)硬件,以降低成本,提高開發(fā)效率。車載部分的硬件結構如圖2所示。

該裝置采用了模塊化設計,以M2020-FNU20工控模塊為核心,通過RS485總線把各個采集模塊連接起來組成一個主從式監(jiān)測網(wǎng)絡。這種結構方式具有硬件結構簡單、擴展靈活的優(yōu)點,可以根據(jù)需要接入其他測控模塊,從而構成一個更復雜的綜合測控系統(tǒng)。

圖2 車載部分硬件結構圖

2.2 車載主機的設計

車載主機是記錄儀的核心,負責控制各部分協(xié)同工作,完成顯示驅動,人機交互,通信驅動,CF卡讀寫驅動以及數(shù)據(jù)存儲等任務。采用了以MiniARM工控模塊M2020-FNU20為核心進行記錄儀車載主機設計的方案。M2020-FNU20模塊的CPU采用了ARM芯片LPC2200,主頻可達75 MHz。模塊上的軟硬件資源非常豐富,集成了ARM 最小系統(tǒng)、以太網(wǎng)控制器、USB控制器、大容量電子盤以及實時時鐘,模塊的體積只有名片大小,可以方便的集成到系統(tǒng)中。設計中只根據(jù)需要設計了相應的接口電路,大大簡化了硬件設計工作,縮短了設計周期。

車載主機的人機界面采用了帶觸摸屏的串口液晶顯示終端,該液晶終端內部集成了電源、觸摸屏及液晶驅動電路。采用該液晶終端無需再設計外部驅動電路,只需編寫串口通信程序即可完成文字及圖形顯示、觸摸屏控制等功能,大大簡化了軟硬件設計,也便于以后的維護升級。

2.3 車載數(shù)據(jù)采集子機的設計

車載數(shù)據(jù)采集子機主要完成各機組運行參數(shù)的采集,并把數(shù)據(jù)發(fā)送給車載主機。采集子機需采集的參數(shù)都是模擬量,數(shù)量較多,如果采用傳統(tǒng)的采集方法需要安裝電壓、電流、功率、頻率、功率因數(shù)等一系列變送器以及設計相應的模數(shù)轉換電路,安裝布線和電路設計都比較復雜。為簡化設計我們采用了智能電量采集模塊9033E實現(xiàn)發(fā)電機電量參數(shù)的采集,采用了模擬量采集模塊9015A實現(xiàn)柴油機運行參數(shù)的采集。

9033E是一款智能電量采集模塊,模塊內部以32位ARM處理器為核心,采用16位A/D以4 kHz的頻率進行采樣,能夠綜合采集電壓、電流、功率、頻率等電參數(shù)。每臺機組設置了一個模塊完成本機組所有電參數(shù)的采集處理,各模塊通過RS485總線與CPU主控板連接,根據(jù)主控板發(fā)出的命令采集數(shù)據(jù)并把數(shù)據(jù)傳送給主控板。使用該模塊不但簡化了設計,降低了成本,同時也使得現(xiàn)場布線較為簡單。為了方便安裝定制了專用的開合式互感器,和普通的穿心式互感器相比,這種傳感器在安裝時不需要對線路進行改動,固定在銅排上即可。

在采集柴油機的運行數(shù)據(jù)時發(fā)現(xiàn)安裝新的水溫、油溫、油壓傳感器比較困難,為了獲取相關數(shù)據(jù),采用了直接采集相應儀表信號線數(shù)據(jù)的方法。傳感器的輸出信號直接和儀表的S端子連接,且均為直流電壓信號,因此采集儀表S端子的電壓,然后經(jīng)過一系列運算即可獲取相關的參數(shù)。經(jīng)試驗發(fā)現(xiàn)傳感器的輸出電壓不但和溫度及壓力值有關,而且和24 V供電電壓有關,因此計算時還需考慮電源的影響。經(jīng)多次試驗確定了電源電壓和傳感器輸出信號之間的關系。經(jīng)過測試,采集的溫度及壓力的精度達到了設計要求。對儀表S端子電壓、24 V及48 V電壓的采集是用9015A模擬量采集模塊實現(xiàn)的。該模塊廣泛應用于各種工業(yè)控制與測量系統(tǒng)中,它能測量12路直流0～60 V電壓信號。通訊接口為RS485,支持MODBUS-RTU、ASCII碼等多種通信協(xié)議,可以方便的和其他模塊組成RS485測控網(wǎng)絡。

3 車載主機軟件設計

3.1 軟件總體結構

設計中采用了ADS1.2作為開發(fā)工具設計車載主機軟件,使用ARM C語言編寫程序。M2020-FNU20工控模塊具有豐富軟件資源,內部以固件的方式固化了uC/OS-II實時多任務操作系統(tǒng)、文件管理系統(tǒng)、USB通信協(xié)議、MODBUS通信協(xié)議以及CAN通信協(xié)議等,用戶無需再編寫相應的底層驅動程序,只需調用相應的API函數(shù)即可完成U盤讀寫、串行通信、文件管理等一些復雜的功能,大大簡化了設計。由于優(yōu)先級0～15的任務被系統(tǒng)占用,在程序設計中使用的任務優(yōu)先級為16～20。系統(tǒng)初始化部分通過調用API函數(shù)加載U盤、串口及其他的驅動程序。各個任務建立后即在操作系統(tǒng)的調度下運行,各任務既相互獨立又互相配合共同完成系統(tǒng)功能,任務之間通過郵箱進行數(shù)據(jù)交換。車載主機軟件的總體結構如圖3所示。

圖3 車載主機軟件的總體結構圖

3.2 任務的劃分

uC/OS-II是一個實時多任務操作系統(tǒng),可以同時運行多個任務。每個任務都是應用程序的一部分,完成特定的功能,獨立于其他任務運行,運行時該任務認為CPU完全屬于自己,可以使用或等待CPU、I/O設備及內存空間等系統(tǒng)資源。通過調用uC/OS-II提供的系統(tǒng)服務函數(shù)來建立、刪除、或者進行任務切換。

設計時首要的工作是合理劃分任務,在對一個具體應用進行任務劃分時存在以下的矛盾:如果劃分的任務過多會造成任務頻繁切換的開銷增加;相反,如果過少則會造成系統(tǒng)的并行度降低,使原本可以并行的操作只能按順序串行執(zhí)行,實時性就比較差。在劃分任務時遵循了以下原則:具有相同時間間隔的工作歸到一個任務中,盡量減少各個任務之間的通信量,不同的優(yōu)先級處理不同的任務。對實時性要求比較高的任務以高優(yōu)先級運行,以保證系統(tǒng)的實時性。根據(jù)以上原則,把采集任務設置為最高優(yōu)先級任務,鍵盤掃描及采集任務次之,把寫入任務設置為最低優(yōu)先級。經(jīng)過試驗驗證以上設置可以保證系統(tǒng)的實時性。

3.3 各任務流程

(1)RTC中斷服務程序

工控模塊的RTC實時時鐘設置為定時中斷的模式,中斷時系統(tǒng)調用本程序。在程序中調用OSSem-Post()函數(shù)向數(shù)據(jù)采集任務發(fā)信號,由于數(shù)據(jù)采集任務的優(yōu)先級最高,因此立即被激活進行一次數(shù)據(jù)采集。

(2)數(shù)據(jù)采集任務

負責和各模塊進行通信,完成數(shù)據(jù)采集任務。任務的優(yōu)先級設置為系統(tǒng)的最高優(yōu)先級16。該任務調用OSSemPend()函數(shù)等待RTC中斷服務程序的信號,沒有接收到信號時處于休眠狀態(tài),一旦接收到信號立即被激活進行數(shù)據(jù)采集。采集到的數(shù)據(jù)首先寫入緩沖區(qū)中,然后向寫入任務發(fā)信號,寫入任務收到信號后從緩沖區(qū)中取出數(shù)據(jù)寫入文件中。采集到的數(shù)據(jù)通過郵箱發(fā)送給顯示任務,顯示任務從郵箱中取出數(shù)據(jù)進行顯示處理。

(3)顯示及觸摸屏掃描任務

主要負責數(shù)據(jù)顯示和接受用戶的輸入信息并進行處理,任務的優(yōu)先級設為17。任務首先進行整個系統(tǒng)的初始化及其他任務的創(chuàng)建工作,然后進入任務循環(huán)。在任務循環(huán)中調用OSMboxPend()函數(shù)查詢郵箱,從郵箱中取出數(shù)據(jù)進行顯示。調用API函數(shù)查詢用戶是否點擊觸摸屏,根據(jù)用戶點擊的按鈕進行相應的處理。

(4)數(shù)據(jù)寫入任務

主要負責把采集到的數(shù)據(jù)寫入文件中,任務的優(yōu)先級設置為最低18。該任務收到數(shù)據(jù)采集任務發(fā)送的信號后,從緩沖區(qū)中取出數(shù)據(jù)寫入文件中。由于寫入占用的時間較長,設置成較低的優(yōu)先級可以保證采集任務及時運行,避免丟失數(shù)據(jù)。

4 結束語

以M2020-FNU20工控模塊為核心設計的空調發(fā)電車運行狀態(tài)記錄儀結構簡單、安裝方便、擴展靈活。設計中吸收了COTS的設計思想,充分利用了現(xiàn)有的模塊及組件,降低了開發(fā)成本,提高了開發(fā)效率。記錄儀經(jīng)實際裝車運行考驗,各項性能指標及可靠性、安全性達到了設計要求。

[1] M2020-FNU20_產品用戶手冊[Z].廣州致遠電子有限公司,2007.

[2] 邵貝貝 等譯.嵌入式實時操作系統(tǒng)uC/OS-II[M].北京:北京航空航天大學出版社,2003.