3 軟件設計

　　系統軟件包括監測節點軟件和監測臺軟件兩部分。為了確保正常通信，采用問答方式，即控制臺依次與每個監測節點建立通信，收到節點發來的數據后，再收取下一個節點的溫度數據信息，這樣就避免了阻塞的情況，確保數據的可靠性［6］。

　　3.1 監測節點軟件

　　監測節點上電后，首先進行系統初始化，包括控制器各端口、寄存器和通信模塊nRF2401的配置等，之后進入接收控制臺指令狀態。當接收到指令時，立即讀取傳感器PT100的輸出值，經過查表處理得出當前軸溫信息，與節點ID打包正數據幀后發送到監測臺，并繼續進入到接收指令狀態。監測節點軟件流程如圖4所示。

　　3.2 數據格式

　　系統了制定了簡單的數據幀格式，如表1所示。

　　圖4 監測節點軟件流程

　　表1 監測節點數據幀結構

　　每個幀的幀頭都以‘start‘’開始，占用5個字節；然后是占用3個節點的ID，可以認為是節點在網絡中的地址；再接下來就是占用6個字節的溫度值。當監測臺發送指令時，每個監測節點都收到數據，但只有指令中ID與節點ID匹配時才會將該數據返回給監測臺，如果不匹配則不做任何處理。

　　3.3 監測臺指令幀結構

　　監測臺與各監測節點通信的時候主要是通過發送指令完成的，指令幀結構如表2所示。

　　表2 監測臺數據幀結構

　　每個指令幀也是以“start”開始，占用5個字節；然后是需要提供溫度數據的節點ID，占用3個字節；再接下來是指令的有無效，占用1個字節；最后是以“end”的幀尾結束符，占用3個字節。

　　3.4 數據發送和接收

　　發送數據。首先將nRF24L01配置為工作在PTX 模式，接著把地址TX_ADDR和數據TX_PLD按照時序由SPI口寫入nRF24L01緩存區，置CE為高電平并保持至少10μs，拉低CE后發射數據，并立即進入接收模式等待應答信號。如果收到應答，則認為此次通信成功，TX_DS置高，同時TX_PLD從發送堆棧中清除；若未收到應答，則自動重新發射該數據，若重發次數ARC_CNT達到上限，MAX_RT置高，TX_PLD 不會被清除；MAX_RT 或TX_DS置高時，使IRQ變低，通知處理器做相應處理。發射成功后，進入空閑模式。

　　接收數據。首先將nRF24L01配置為PRX接收模式，接著延遲130μs進入接收狀態等待數據的到來。當接收方檢測到有效的地址和CRC時，就將數據包存儲在接收堆棧中，同時中斷標志位RX_DR置高，IRQ變低，通知處理器讀取數據，接收完數據后進入發射狀態并回傳應答信號，接收成功，CE變低進入空閑模式［5］。

　　4 試驗結果與分析

　　試驗采用雙層集裝箱車，分別對空載和載重的兩種不同情況車廂進行了測試。空載車廂自重為25t，載重車廂重為78t.

　　兩種情況的測量結果如圖5所示。

　　圖5 測試結果

　　由于列車運行情況相對復雜，軸溫與速度、運行時間、制動、載重和環境溫度等情況都有密切關系。從對圖5的分析看，具體關系是：速度越快，軸溫越高；列車啟動階段，即0~30km之間，隨著運行時間的增加軸溫越高，當達到一定程度時，運行時間不再軸溫；在行駛到43~50km處，列車制動使車軸急劇升高，溫度達到71.45℃；在運行穩定狀態下，載重78t的車廂明顯比載重25t的車廂，溫度高6℃左右；另外，環境越高，軸溫越高。不難看出，載重越大，軸承運轉溫度越高，并且上升速度越快。

　　5 結論

　　針對目前列車軸溫探測存在的不足，借助于現代無線傳感器網絡技術，設計了系統簡潔、布局小巧、靈敏度高、收發信息能力快速的高速列車軸溫集中監測系統，擺脫了傳統有線的傳輸方式，可實時監測運行中的列車軸承情況，如超過軸溫監測預設定值，就發出報警信號，便于及時采取有效措施，有效地降低事故發生率，避免因事故而產生的巨大經濟損失。經過實驗得到兩種載重情況運行列車的軸溫數據，分析了提速列車的軸溫變化規律，給改進熱軸預報提供了數據基礎，對維護鐵路運輸的正常運行和高速鐵路的發展具有重要意義。