|
在分析實時數據監測模塊實時性需求的基礎上，提出一個通用實時數據監測模塊系統結構，并闡述該模塊的軟件實現。該系統采用MODBUS_RTU通信協議,采集各個監測模塊的實時數據,并在LCD上以圖形方式顯示系統運行的情況。 實時數據監測是保證大中型旋轉機械安全運行的重要手段。隨著工業自動化程度的日益提高，對旋轉機械的實時數據監測的實時性、可靠性也提出了更高的要求。 筆者在S3C44B0上基于μC/OS-II進行通用實時數據監測模塊的設計，并將其應用在旋轉機械監視保護系統中，實現了很好的實時性。該監測模塊具有對32個模擬量測點進行采集、顯示、通信與管理的功能。 1 系統實時性需求 該實時數據監測模塊是基于μC/OS-II進行設計的，而保證系統實時性的重要策略是系統的中斷處理機制。下面首先對系統設計的中斷處理機制進行分析。 1.1 中斷處理機制分析 實時系統最根本的特點是實時性,而中斷處理程序是實時系統的重要組成部分,是RTOS實時性的重要體現。系統通過中斷機制了解外部世界,并對外部事件立刻作出響應。實時系統的反應速度取決于系統對于中斷的響應速度和中斷處理程序的處理速度。為了獲取對外部事件的最短反應時間,μC/OS-II系統中斷響應過程如圖1所示。 圖1 系統中斷處理機制分析 第①階段是中斷延遲時間,從出現中斷請求到當前任務開中斷這一過程。實時系統在進入臨界區代碼段之前都要關中斷,執行完臨界代碼之后再開中斷。關中斷的時間越長,中斷延遲就越長。 第②階段是內核保存當前任務的狀態,將CPU寄存器壓棧,以便為中斷服務。 第③階段調用OSIntEnter()函數或把中斷嵌套層數計數器直接加1,用OSIntExit()函數,將中斷嵌套層數計數器減1,當嵌套計數器減到零時,μC/OS-II要判定有沒有優先級較高的任務被中斷服務子程序喚醒。如果有優先級高的任務進入了就緒態,μC/OS-II就返回到那個優先級高的任務B。如果中斷嵌套層數計數器大于0,μC/OS-II將被返回到被中斷了的任務A。OSIntExit()函數的作用是進行中斷級的任務調度。 第④階段恢復已壓棧的寄存器值;最后執行中斷返回指令,結束中斷。 根據上述中斷處理機制，中斷響應時間是影響中斷實時性的最重要指標，而中斷延遲是其主要因素，延遲時間主要由系統時鐘和關中斷的時間決定。由于系統存在對任務和多中斷的調度，所以中斷延遲是個變量，一般為4～28個處理器周期。 1.2 實時數據監測模塊實時性需求分析 該實時數據監測模塊最多同時對32個測點的數據進行實時監測。下面就以32個測點數目對該系統的實時性進行分析，并從系統測量時間、功能要求兩個方面說明系統保證實時性的時間條件。 1.2.1 功能要求 ① 32同步采樣，即系統能夠進行多通道采樣，并且系統的A/D轉換芯片對采樣信號可以進行高速動態采集波形的要求，通道采集頻率高達240 Hz。 ② A/D轉換位數，不小于16位。 ③ 要求系統必須與計算機接口進行通信，并且接口具有足夠的傳輸速率來滿足系統的實時性要求。 ④ 要求該系統具有即插即用功能，在即插即用的同時，系統能夠實時更新測點的數據以及狀態參數。 ⑤ 該系統必須具有報警延時和報警保持功能。各個通道的報警延時用戶可以根據自己的需要設定，并且報警狀態可以被保持。 1.2.2 測量時間 因為每個測點就是需要采集的一個數據源，因此系統需要同時對32個數據源的數據進行采集。每個測點可以分為多個通道（假設都為2個通道），系統需要同時采集的數據有64個。這樣可以計算出系統測量周期t為： t=64×系統對每個通道數據源的測量時間 每個通道的測量時間包括通信時間和A/D采集時間、顯示時間。 (1) 通信時間 系統通信采用工業控制和分布式系統協議MODBUS_RTU通信協議。通信協議采用十六進制的形式，所有寄存器采用的都是16位寄存器。寄存器中數據的排列采用大端格式。MODBUS_RTU基本幀格式如表1所列。 表1 MODBUS_RTU基本幀格式 該系統按照上述MODBUS_RTU的基本幀格式發送命令。發送命令基本流程如下：上位機按照表1敘述的MODBUS_RTU基本幀格式向下位機發送，下位機接收到上位機發送過來的命令后，執行相應的操作，然后將返回上位機應答信號。這一過程成為一個通信過程。該系統的一個通道的通信時間為10 ms。 (2) A/D采集時間 系統A/D采集轉換需要采用高速動態的波形采集方式，每秒最高可采50 000個數據，那么采集一個數據源的時間為 2 μs。完成對32個測點64個數據源的采集時間僅為2 μs×64=128 μs。 采集數據的頻率最低可以為每秒鐘采集2500個數據，那么采集一個數據的時間最大值為0.5 ms。 (3) 顯示時間 嵌入式觸摸屏裝置是一種人機交互設備,將觸摸屏安裝在LCD液晶屏上,配以相應的控制電路對觸摸屏和LCD進行控制。用戶通過觸摸操作,就可以對相應的設備進行交互。觸摸屏由觸摸檢測部件和觸摸屏控制器組成。 采集到的數據送回到觸摸屏控制器的X與Y值僅是對當前觸摸點的電壓值的A/D轉換值,它不具有實用價值。這個值的大小不但與觸摸屏的分辨率有關,也與觸摸屏與LCD的貼合情況有關。因此,要想得到比較精確的體現LCD坐標的觸摸屏位置,還需要在程序中進行轉換。假設LCD的分辨率是320×240,坐標原點在左上角;觸摸屏分辨率是900×900,坐標原點在左上角,則轉換公式如下: 式中：X、Y是對當前觸摸點電壓值的A/D轉換值;X1、X2、Y1、Y2分別是觸摸屏坐標的最大值和最小值。 LCD顯示時將采集到的坐標經過具體的轉換程序進行轉換。轉換需要有一定的時間，所以LCD的顯示時間t包括取得當前觸摸點的電壓值的時間以及由程序轉換得到當前A/D轉換值的時間。觸摸屏采用中斷方式對數據進行采樣，可以利用定時器對觸摸屏的采樣基準時間進行設定，一般設定觸摸屏的采樣基準時間為10 ms。觸摸屏每隔10 ms對數據進行一次采樣，即每隔10 ms對每個通道的數據進行一次采樣，并將其顯示在LCD上。 根據以上所述，系統對每個通道數據源的測量時間tchannel =通信時間tc +采集時間ts+顯示時間tl=10 ms + 0.5 ms +10 ms = 20.5 ms。此時系統中最多64個通道，那么系統完成64個通道的測量周期為T=64×tchannel=64×20.5 s≈1 s,實時數據監測模塊的設計必須滿足上述要求才能很好地滿足系統的實時性。 2 系統設計 根據上述對實時數據監測模塊實時性的需求分析，將整個系統的體系結構分為3個模塊： 第1個模塊是LCD顯示模塊，第2個模塊是采集和通信模塊，第3個模塊是監測點模塊。如圖2所示，LCD顯示模塊用于顯示采集數據和以按鍵方式發送命令。通信模塊中LCD通過按鍵操作的方式通過MODBUS_RTU通信協議與各個監測點之間的通信連接，通信采用RS232/RS485無源轉接器連接。該實時數據監測模塊通過RS232/RS485對各個監測點的數據進行采集，并將采集到的數據送入各個監測點的數據緩沖區（數據緩沖區包括保持寄存器、控制寄存器和狀態寄存器）。系統的數據鏈路層采用MODBUS_RTU通信協議。 圖2 模塊結構 3 軟件設計 通過對各嵌入式操作系統的特點、性能進行可行性分析及比較，本模塊采用了μC/OS-II作為該模塊需要移植的操作系統。 3.1 任務劃分 μC/OS-II是一種占先式多任務內核，其實現的任務調度是基于優先級的,即優先級最高的任務一旦準備就緒,就取得CPU的所有權開始投入運行。目前,μC/OS-II管理多達64個任務,其中8個保留給系統,應用程序最多有56個任務,能滿足一般嵌入式系統的需要。在μC/OS-II中,每個任務的優先級要求不一樣且是唯一的,所以任務調度工作非常簡單,即查找準備就緒的最高優先級任務,然后進行上下文切換。μC/OS-II下每個任務有休眠、就緒、運行和中斷等狀態。 分析μC/OS-II的源碼會發現,它把任務的優先級作為任務的標識符來使用。只有進入就緒態的最高優先級的任務才能得到CPU的使用權。任務劃分是開發實時系統軟件的重要一步。要基于簡化任務間的通信這一目的進行任務劃分,使各任務程序實現的功能模塊化。在此模塊中,將處理采集和通信任務都設置了較高的任務優先級，通信任務為Task40_ComputerCom，采集任務劃分為TMapStaticData和TMapDynamicData。為使系統能夠及時更新管理模塊中的靜態數據,將對功能模塊靜態數據進行更新的任務的優先級設置成兩者中的最高。在模塊中的其他任務可根據具體情況進行設置。表2詳述此模塊中創建的各任務的任務說明及優先級劃分。 3.2 任務調度策略 TMapDynamicData任務輪詢所有在線測點的實時數據；同時,該實時數據監測模塊在RAM中為每個功能模塊建立一個數據映射區,并在映射區中保存各功能模塊的表號、變量參數、報警狀態、工作狀態等實時信息。在映射區中的數據可分為動態數據和靜態數據。動態數據是各個功能模塊的實時測點參數和狀態數據。當用戶使用觸摸屏按鍵方式完成對某一測點的動態數據映射區進行操作時,應用系統將立即喚醒任務TMapDynamicData,來更新在映射區中對應于此測點的動態數據，并且在觸摸屏上會顯示出各個測點的動態數據信息。靜態數據是反映各個測點相關的配置信息,不會時刻變化，但卻反映了測點的數據參數的特性。一旦測點的這些數據信息被修改了,映射區中對應數據就必須更新。為了降低整個系統的通信開銷,在實際應用中,沒有頻繁地更新映射區中的靜態數據。當用戶觸摸屏按鍵方式完成對某一測點的靜態數據進行操作后,應用系統立即喚醒任務TMapStaticData,來更新在映射區中對應于此測點靜態數據。 此實時數據監測模塊任務調度策略實現了多個不同優先級的任務與TMapDynamicData任務間的通信。比如，LCD的主界面顯示任務Tmain_Board,詳細顯示界面任務Tcheck_Board以及巡檢界面任務Tcheck_system都與TMapDynamicData進行任務間的通信。模塊必須優先處理LCD通過TComputerCom任務修改某一測點的靜態數據,同步更新各個監測點的靜態數據的情況。此任務通信過程不僅包含觸發事件的通知,還要考慮任務間相應數據的傳遞。因此必須通過消息郵箱、消息隊列或者事件標志組方式來實現此數據傳遞的情況。經進一步分析得出,由于負責映射靜態數據的TMapStaticData任務優先級高,模塊設計中采用了消息郵箱方式來處理其他任務與此任務間的通信過程。模塊設計任務邏輯關系如圖3所示。 表2 部分任務劃分與優先級分配 圖3 模塊設計任務邏輯關系 筆者認為，在開發基于多任務的嵌入式項目時，為使整個模塊的設計具有結構化、模塊化、標準化的特點，也便于將來模塊實現的維護與升級，應該盡量簡化各個任務間的邏輯關系，體現各個任務功能的獨立性和完整性。每個任務實現一個或若干個功能，但必須成為一個單獨的模塊。任務間的調度策略主要通過延時以及信號量、消息郵箱、消息隊列來完成。 3.3 程序實現 基于μC/OS-II嵌入式實時操作系統處理并發任務，該實時數據監測模塊軟件設計部分偽代碼如下： void Tstart(void * pdata) { while(1) { 創建TMapStaticData 通信任務； 創建TMapDynamicData 通信任務； 創建LCD的TMain_Board主界面顯示任務； 創建LCD的Tcheck_Board測點數據詳細顯示界面任務； 創建LCD的Tcheck_system測點數據顯示巡檢任務； }； } 結語 基于μC/OS-II的旋轉機械監視實時數據監測模塊利用了μC/OS-II能夠穩定、安全處理并發多任務這一特點,并按所述調度策略協調多任務運行,提高了模塊程序的運行效率。該模塊一直穩定運行,體現出較高的實時性和可靠性,取得了較好的實際效果。 |
