實時操作系統(tǒng)μC/OS-II在井場RTU中的應用

文/王先鵬 王開明

（貴州航天凱山石油儀器有限公司 貴州省貴陽市 550009）

井場RTU 是油氣井生產(chǎn)物聯(lián)網(wǎng)系統(tǒng)的控制核心，對整個數(shù)據(jù)采集系統(tǒng)進行協(xié)調(diào)和管理，把各智能傳感器采集到的數(shù)據(jù)傳輸?shù)秸?、廠，并根據(jù)站、廠的要求對各個智能傳感器以無線通訊方式發(fā)送控制命令，從而實現(xiàn)抽油機井數(shù)據(jù)采集和控制管理功能。

井場RTU 以ATMEL 公司8 位AVR 單片機ATmega128L 為核心設計的嵌入式系統(tǒng)，移植有μC/OS-II 實時操作系統(tǒng)，預留有豐富的接口，可通過通信接口擴展連接其它測試設備，具備較強的可擴展性。

1 井場RTU硬件設計

在油氣井生產(chǎn)物聯(lián)網(wǎng)系統(tǒng)中，遵循一套井場RTU 管理一個叢式井場（長慶油田井場有抽油機井1 至10 幾口井數(shù)量不等）的設計原則：即每個井場安裝井場RTU 一套，單井各安裝示功圖傳感器、電機智能參數(shù)傳感器一套，還可以擴展注水閥組單元、溫度和壓力采集傳感器等。

井場RTU 與各類傳感器在系統(tǒng)設計上遵循“分散采集、集中控制”設計理念，示功圖傳感器、電機智能參數(shù)傳感器、無線壓力變送器和無線溫度變送器等智能數(shù)據(jù)采集監(jiān)控設備傳感節(jié)點為系統(tǒng)設計的“分散采集”部分，采集油水井各種物理參數(shù)；井場RTU為系統(tǒng)設計的“集中控制”部分，集中管理各種分散采集部分的傳感器節(jié)點。

井場RTU 以8 位AVR 單片機為核心設計的最小嵌入式系統(tǒng)，移植有μC/OS-II 實時操作系統(tǒng)，預留了豐富的接口，具備較強的可擴展性。

井場RTU 通過AD 轉(zhuǎn)換器完成模擬量的數(shù)據(jù)采集，通過IO 接口判斷開關量的輸入輸出。井場RTU 與各類傳感器之間通過無線通信模塊（或采集接口）實現(xiàn)點對點或一點對多點的無線方式通訊；與服務器通過RJ45 接口，實現(xiàn)數(shù)據(jù)的交互。在工作過程中，井場RTU 起到橋梁紐帶的作用，它實時將各類傳感器采集到的數(shù)據(jù)傳輸?shù)秸究豍C 機或服務器端；井場RTU 與各類傳感器通訊時，RTU 相當于RS485 總線的主站，各類傳感器是RS485 總線的從站，RTU 與各類傳感器之間采用主從通信方式，通訊協(xié)議采用Modbus RTU 傳輸協(xié)議。

在井場RTU 的嵌入式系統(tǒng)設計過程中硬件的驅(qū)動程序使井場RTU 的硬件的發(fā)揮了最優(yōu)的狀態(tài)，應用程序通過調(diào)用驅(qū)動程序完成與硬件相關的所有操作。驅(qū)動程序的編制與所使用的CPU 類型、外圍的硬件相關，在這里不是本論文討論的重點。

2 井場RTU的嵌入式軟件設計

2.1 實現(xiàn)功能

2.1.1 功圖測試

定時測試井場中每口油井的示功圖。定時向示功圖傳感器發(fā)送功圖測試命令，然后與功圖傳感器通信，獲取測試后的實測功圖數(shù)據(jù)保存于RTU 中，同時將測試結(jié)果發(fā)給服務器。

2.1.2 電參數(shù)測試

定時測試井場中每口油井的電機運行參數(shù)。定時向電機智能參數(shù)傳感器發(fā)送電參數(shù)測試命令，然后與電機智能參數(shù)傳感器通信，獲取測試后的實測電機運行參數(shù)數(shù)據(jù)保存于RTU 中，同時將測試結(jié)果發(fā)給服務器。

2.1.3 注水井數(shù)測試定時測試井場中注水井的注水壓力、流量、配注等參數(shù)，并將測試結(jié)果保存在RTU 中，并同時將結(jié)果上傳至服務器。

2.1.4 井場匯管壓力測試實時采集井場匯管壓力參數(shù)，并將測試結(jié)果保存在RTU 中，并同時將結(jié)果上傳至服務器。

2.1.5 實時命令功能實時接收上位機發(fā)來的采集、控制等命令，進行相應的參數(shù)測試及設備控制等功能。

2.2 設計思路

以往的程序編制方式是采用前后臺面向過程的編程方式，采用μC/OS-Ⅱ嵌入式實時操作系統(tǒng)后，編程方式變成了基于事件驅(qū)動的編程方式。怎樣將RTU 復雜的功能一一簡化成簡單的事件就是井場RTU 儀器軟件的設計思想。

何為事件驅(qū)動，顧名思義，當一個事件發(fā)生了，任務再作相應處理，處理結(jié)束后又開始等待下一個事件的發(fā)生。如此周而復始的任務處理模型就是“事件驅(qū)動的編程模型”。μC/OS-Ⅱ嵌入式應用程序是由任務組成的，任務都必須符合事件驅(qū)動的編程模型，即μC/OS-Ⅱ的應用程序都必須是“事件驅(qū)動的編程模型”。一個任務首先等待一個事件的發(fā)生，事件可以是系統(tǒng)中斷發(fā)出的，也可以是其它任務發(fā)出的，又可以是任務自身等待的時間片結(jié)束。事件驅(qū)動模型也涵蓋了中斷驅(qū)動模型，μC/OS-Ⅱ事件歸根結(jié)底來自三個方面：

（1）中斷服務函數(shù)發(fā)送的事件；

（2）系統(tǒng)延時時間到所引起的；

（3）其它任務發(fā)送的事件。

其中“中斷服務函數(shù)發(fā)送的事件”就是指每當有硬件中斷發(fā)生，那么中斷服務程序就會以事件的形式告訴任務，而等待該事件的最高優(yōu)先級任務就會馬上得以運行；“系統(tǒng)延時時間到所引起的”事件其實也是硬件中斷導致的，那就是系統(tǒng)定時器中斷。而“其它任務發(fā)送的事件”則是由任務代碼自身決定的，這是完全的“軟事件”。不管“軟事件”還是“硬事件”，引起μC/OS-Ⅱ任務切換的原因就是“事件”，所以編寫應用程序的時候一定要體現(xiàn)出“事件驅(qū)動的編程模型”。

2.3 任務概念

如果想了解多任務操作系統(tǒng)，首先必須了解任務概念。所謂任務，也稱作線程，是一個簡單的、無限循環(huán)的程序，該程序可以認為CPU 完全只屬該程序自己。實時應用程序的設計過程，也就是如何把問題分割成多個任務的過程，每個任務都是整個應用程序的某一部分，每個任務被賦予一定的優(yōu)先級，有它自己的一套CPU寄存器和自己的?？臻g。

2.4 任務劃分

任務劃分存在這樣一對矛盾：如果任務太多，必然增加系統(tǒng)任務切換的開銷；如果任務太少，系統(tǒng)的并行度就降低了，實時性就比較差。在任務劃分時要遵循H.Gomma 原則：

（1）I/O 原則：不同的外設任務不同。CPU 的操作快于I/O 操作，如果將I/O 操作歸為一個任務順序執(zhí)行則會很浪費時間。

（2）優(yōu)先級原則：對于突發(fā)事件的優(yōu)先級等價于事件的時間耗盡線，不同優(yōu)先級處理不同任務。

（3）大量運算：歸為一個任務。

（4）功能耦合：歸為一個任務，舉例：f(),g(f()),h(g(f()))。

（5）偶然耦合：歸為一個任務，舉例：f1()，f2()，f3()。即事件之間并沒有必然的先后順序，但由于習慣一直是按這個順序做的。

2.5 軟件結(jié)構(gòu)

井場RTU 在油氣井生產(chǎn)物聯(lián)網(wǎng)系統(tǒng)中所實現(xiàn)的功能，將井場RTU 儀器軟件劃分成7 個任務，分別詳述如下：

（1）命令解析任務（CMD_Explain_Task）：負責解析串口0 發(fā)送來的數(shù)據(jù)，將解析出的完整一幀命令放入命令緩沖隊列，并向命令執(zhí)行任務發(fā)送命令事件觸發(fā)信號量COMMAND_COM0_SEM，通知命令執(zhí)行任務有事件需要處理。

（2）命令執(zhí)行任務（CMD_Execute_Task）：上位機（服務器端軟件）通過RJ45 網(wǎng)絡接口，發(fā)送給RTU 的所有控制命令（手動功圖測試命令除外），都是通過此任務來完成的。此任務平時處于掛起態(tài)即等待命令事件觸發(fā)信號量COMMAND_COM0_SEM 事件發(fā)生，當?shù)玫矫钍录|發(fā)信號量時命令執(zhí)行任務處于就緒態(tài)準備開始執(zhí)行。

（3）手動功圖測試任務（Manual_GT_Test）：功圖測試所需要的時間較長而且與抽油機的運行快慢有關，沖次較快的抽油機井測試時間較短，沖次慢的所需時間較長。如果將此功能放入命令執(zhí)行任務中來完成，會因此功能長時間的占用CPU 的使用權而其它功能得不到實時的執(zhí)行而影響整個RTU 工作的實時性。將手動功圖測試功能獨立劃分成任務后賦予較低的優(yōu)先級，這樣優(yōu)先級較高的任務可以剝奪優(yōu)先級較低的任務對CPU 的使用權，可以立即執(zhí)行，因此不會由于功圖測試時間較長而影響整個系統(tǒng)的實時性。

（4）功圖巡檢任務（GT_Test_Task）：即定時測試功圖任務。井場RTU 的時鐘節(jié)拍中斷（OSTickISR）每10ms 產(chǎn)生一次，時鐘節(jié)拍是特定的周期性中斷。這個中斷是μC/OS-Ⅱ系統(tǒng)心臟的脈動。功圖巡檢任務利用時鐘節(jié)拍的10ms 時間基，根據(jù)EEPROM 定時測試時間常數(shù)，每隔一定時間產(chǎn)生一次功圖測試事件即功圖測試信號量（GTTEST_SEM）。功圖巡檢任務由于得到功圖測試事件（功圖測試信號量GTTEST_SEM）發(fā)生進入就緒態(tài)準備開始執(zhí)行。此任務不同于手動功圖測試任務中進行的功圖測試，它是針對一個井場所有抽油機井的功圖測試，而手動功圖測試任務是針對某一口抽油機井的。

（5）電參巡檢任務（DC_Test_Task）：和功圖巡檢任務一樣電參巡檢任務也是利用時鐘節(jié)拍中斷（OSTickISR）產(chǎn)生的10ms時間基，根據(jù)EEPROM 定時測試時間常數(shù)，每隔一定時間產(chǎn)生一次電參測試事件即電參測試信號量（DCTEST_SEM）來完成一次井場中所有的抽油機井的電參數(shù)測試。

圖1：井場RTU 儀器軟件的工作框圖

（6）數(shù)據(jù)發(fā)送任務（SendDataToPC_Task）：井場RTU 通過串口轉(zhuǎn)以太網(wǎng)向上位機發(fā)送數(shù)據(jù)，如果有任務需要向上位機發(fā)送數(shù)據(jù)，必須先向數(shù)據(jù)發(fā)送任務申請對串口0 的使用權。數(shù)據(jù)發(fā)送任務（SendDataToPC_Task）負責將系統(tǒng)中各任務打好的數(shù)據(jù)包發(fā)送給上位機。因串口0 為共享資源，且屬于外設，與CPU 的處理速度相比串口0 的通訊速度較慢。

（7）主從通訊服務任務（OSTaskModbusServe）：該任務負責處理主從通訊方面的主站與從站之間事務處理。主從通訊服務任務（OSTaskModbusServe）是RS485 通訊主站的核心組成部分，它負責Modbus RTU 協(xié)議中的ADU 報文幀的調(diào)度和Modbus 主從通訊方面的事務處理。該任務主要處理的事件：發(fā)送請求幀、等待應答幀、處理應答、處理差錯和等待轉(zhuǎn)換延時。該任務通過API 函數(shù)ModbusPoll 為μC/OS-Ⅱ系統(tǒng)中各任務的Modubs 請求提供服務。

井場RTU 儀器軟件中的7 個任務分別由7 種不同的事件驅(qū)動的，如圖1 所示。正是由于這些不同的事件組成了事件驅(qū)動模型的編程方式。此種編程方式結(jié)構(gòu)清晰、層次分明，非常適合復雜的嵌入式系統(tǒng)開發(fā)。

3 總結(jié)

8 位CPU 系統(tǒng)的井場RTU 引入了μC/OS-Ⅱ?qū)崟r嵌入式操作系統(tǒng)開發(fā)嵌入式軟件,并在任務劃分上采用了事件驅(qū)動的編程思想，它以多任務模塊化編程，設計出了滿足嵌入式實時操作系統(tǒng)性能要求的事件驅(qū)動機制。通過對這種機制的分析，讓我們可以更深入地理解實時操作系統(tǒng)設計的獨到之處。在油氣井生產(chǎn)物聯(lián)網(wǎng)系統(tǒng)中，井場RTU 引入了實時操作系統(tǒng)μC/OS-Ⅱ的設計理念使其嵌入式軟件可靠性、穩(wěn)定性和可擴展性得到了很大的提升，并且在長慶油田的數(shù)字化項目應用中得到了較好的驗證。