實時軟體技術

實時軟體是必須滿足嚴格時間約束條件的軟體。比較而言,實時程式設計是目前套用軟體開發中技術最難、風險最大的程式設計領域,這是由它的套用對象和環境決定的。考查順序程式設計、多道程式設計和實時程式設計這三大程式設計領域的關係:多道程式中每一道程式是順序的,而實時軟體往往又是多道程式構成的,只是增加了實時性等特殊要求。因此,這三種軟體開發方法之間具有包含關係,即一個比一個難度大,所需技巧更多。

基本信息

實時軟體及其特性

順序程式設計,相對後兩種程式設計來說,其最主要的特性是程式的封閉性和可再現性。所謂封閉性是指程式一但開始運行,其結果不受外界因素的影響;可再現性是指該程式重複執行時,必獲得相同之結果。多道程式的引入,使程式喪失了封閉性和可再現性,從而引入進程(或稱任務)的概念。相對於順序程式,多道程式產生了並發特性和異步特性。並發性是指一個程式段的第一個操作是在另一個程式段最後一個操作完成之前開始的,則稱這些程式段是並發的。對進程而言,異步特性是指各進程按照各自獨立的、不可預知的速度向前推進;對事件而言,系指各事件發生的時間和順序是不可預知的。

在許多實際套用中,我們將實時系統設計成多任務並發系統,因而要用到多道程式並發設計技術。但應認識到,這樣做主要是為了更充分地利用計算機資源,而不是說實時系統就必須是多任務並發系統。從邏輯上講,實時是我們的目標,多道程式並發是技術或途徑。

正因為實時系統往往採用多道程式並發技術,所以它具有多道程式並發特性和異步特性。除此之外,實時軟體還具有如下特性:

1.實時性

實時性是指某個事件服務或某進程代碼在分配的回響時間內必須是可執行的。換言之,假定沒有其他進程競爭CPU,該進程必須能在規定的回響時間內執行完。

在實軟體中,“時標”是一個極其重要的概念。因為任何實時程式的工作,均是在“時標”控制下進行的一一無論周期性或隨機性工作,都離不開“時標”約束。這就意味著“逾時”一一即使程式正確地完成功能性操作,但執行時間已起出“時標”限定範圍,仍認為是軟體錯誤。

2.線上性

在實時系統中,計算機往往作為嵌入式系統,實時軟體是在環境事件的驅動下工作的。計算機的狀態和運行是整個系統的一部分,只要裝置的運行不停,則計算機是不能停的。這就是線上性要求。由於線上環境下系統事件發生的隨機性,系統工作狀態的不確定性,使實時軟體的測試工作變得非常困難。

3.高可靠性

高可靠性是實時軟體的重要指標。這不僅在於實時軟體常用作重要或有較大危險性的設備的控制,而且由於線上性要求,即使出問題也不允許暫停。

實軟體設計方法

1.任務劃分

實時系統的工作過程(或稱工作原理)就是實時數據採集一一實時處理一一實時輸出控制量以控制受控對象的過程。實時軟體結構設計的主要問題是把系統分解成若干並行任務的方法以及任務間通訊與同步的表達。在實時軟體中,任務劃分一般依據以下原則:

(1)受相同事件驅動的加工應劃分在同一個任務中。因為它們的激發條件一樣,可一次性統一調度。

(2)限定條件比較特殊(如回響時間要求短)的加工,應當相應地劃分為獨立任務,以便進行高度的調整來滿足這些特殊要求。

(3)信息交換頻繁的加工應劃分在同一任務中,可降低任務通訊帶來的開銷。

(4)同外部設備接口有關的加工應劃分在同一任務中。因為實時軟體往往要同特種外部設備打交道,將這些加工放在一起,可有利於對其它任務隱蔽這些設備的特性,方便其管理和編程。

在按以上原則進行任務劃分的基礎上,還可從各任務中提取出共同的功能,形成管程和公用子程式。管程主要是用來管理資源的。由管程統一管理資源,一是比較方便、安全,二是可隱蔽資源和外界關係的特性於管程內,三是方便任務間互斥與同步的管理。從各任務劃分中抽出公用子程式比較簡單,要注意的是應保證這些子程式的再入性,因為很可能有幾個任務同時調用某子程式。

2.任務通訊

在一個並發多任務系統中,各個任務是異步向前推進的,但出於資源共享或任務的協作關係,各並發任務間存在相互的制約關係,我們把這些制約關係稱為“任務通訊”。

任務通訊有基於共享變數和基於訊息傳送二種方式。共享變數通訊又分為互斥與條件同步。互斥是指一個任務(進程)訪問某共享變數時,不允許其它任務訪問該共享變數。條件同步是指共享變數處於不適合某個特性操作的狀態時,任何需要作這種操作的任務都要延時,直到其它進程所執行的操作改變了該共享變數的狀態為止。基於訊息傳送的通訊方式較共享變數方式是高級的通訊方式,因為進程不讀寫共享變時,而是傳送與接收訊息。這種方式不僅能完成訊息的傳送,也能實現進程間的同步。這兩種方式的差別還在於:

訊息傳送方式是把不同時刻的數據排列在訊息隊伍中,共享變數方式則始終用當前時刻數據把上一時刻數據覆蓋掉,而不管舊數據是否被取用了。

確定任務間的通訊方式(也叫任務界面)是非常重要的。任務界面設計得好,通訊效率相應的就高,各任務間也能協調、有序地工作。任務界面的確定,也就是要準確有效地將以上幾種通訊方式用到各任務間通訊中去。

3.任務調度

在實時系統中,任務數一般都多於CPU數,所以調度亦成了滿足實時時間約束的一個關鍵問題。任務調度的核心問題就是採用什麼算法把處理機分配給各任務進程。實時系統中,為保證重要的或緊迫的任務及時執行,通常都採用最高優先數優先(High Priority First)調度算法。只要用戶將“重要或緊迫”的任務賦於高優先數,則可保證這些任務能優先得到調度執行。所以,採用這種算法首先應考慮的問題就是任務優先數的確定。確定優先數的辦法很多,但概括起來不外是基於靜態特性和基於動態特性兩種方法。靜態優先是在任務進程創建時確定的。一經確定則在整個進行運行期間不再改變。

還有就是調度方式問題。調度方式是一進程正在處理機上執行時,若有優先數更高的請求處理機服務時,如何分配處理機。調度方式分剝奪方式和非剝奪方式,剝奪方式系指一旦出現優先數更高的進程,便立即中斷正在執行的進程,而把處理機分配給高優先數進程;非剝奪方式是指即使出現優先更高的進程,仍保持原進程的運行,直到原進程執行完成或因某種原因阻塞時,才將處理機分配等待運行的優先數最高的是程。顯然,剝奪方式更靈活,它可使某些緊進程迅速得到回響。

在實時系統中,除非原進程耗時少,一般都採用剝奪調度方式。當然,這會帶來系統開銷的增長。

4.容錯處理

理論和實踐證明,儘管軟體在設計、編制和測試過程中可通過各種方法、手段排除軟體中的錯誤,但軟體投入運行後絕對沒有錯誤是不可能的。軟體件容錯技術則是力圖使設計和編制的軟體始終能正確執行,而不必擔心運行軟體中存在的,在設計、編制和測試中個別未被排除的故障。這對於具有線上性和高可靠性要求的實時系統來說,無疑具有極重要的意義。

(1)故障類型

軟體故障是軟體設計和編程中的缺陷在功能上的一種表現。研究軟體容錯首先應從分析故障類型,即從建立故障模型開始。從錯誤效果來看,我們可將軟體故障分三類:

①內部故障(或稱局部故障)

內部故障是指其影響局限於一進程內,且能被該進程處理的故障。

②外部故障

故障的影響雖局限於一進程內,但不能被該進程處理的故障。

③擴散性故障(全局性故障)

故障的影響不局限於一進程,且不能被一個進程處理的故障。

(2)容錯軟體方法

目前,對那些能建立確定軟體故障模型的故障,如除零錯,超出輸入輸出狀態定義域非法軟體操作等,可以從軟體故障檢出,損害評估,錯誤恢復,繼續軟體運行這四個方面採取措施實現軟體容錯;面以一些難於建立模型的軟體故障來說,就只有採取軟體冗餘來實現軟體容錯。下面簡單地對用得較多的幾種軟體設計方法加以討論。

①故障處理(器)軟體容錯法

此法實際是設計一種嵌入或線上實時自診斷和自處理程式。它們被分段嵌入到主體軟體中,從而能對主體軟體進行線上實時的故障處理。

對軟體故障檢出,原則上可利用軟體工程化中有關軟體驗證和測試中的任何方法。但由於其線上性和實時性的要求,應考慮那些有效而省時的方法。

在軟體故障損害評估方面,對單任務系統比較容易,而對多任務系統則比較困難。必須對任務間的通訊聯繫有充分的了解和嚴格的控制。

錯誤恢復是指恢復到故障前的正常狀態。可用硬體(如便箋或暫存器組)存儲上一時刻現場,以此幫助系統實現高速恢復;對周期性實時系統,可用存儲一些標準操作常數來恢復;對周期性實時系統,可用存儲一些標準操作常數來恢復現場;對外界輸入數據可用估值法恢復,或者重讀輸入數據來恢復;對輸出控制信號,由於有些執行過程是不逆的,因而錯誤處理軟體應在這些信號的內部校驗和測試通過後送出。

②恢復模組容錯法

此由故障處理方法發展而成。恢復厝塊對主體程式的中間結果進行能否接收的校驗。如不合格,就給出替代程式,直到通過接收校驗。如所有替代程式用完而仍不能通過校驗時,只有對系統進行降級處理。

③N版程式容錯法

對那些難於實現故障檢出的軟體故障,一般採用N版程式容錯法,此容錯法是對同一需求由N(≥2)個小組獨立地設計N個功能等價的程式。這N個程式能在N模時間冗餘度的系統中並行運行。並在這N個程式中適當區段設立某些交叉檢驗點,皆在此點進行比較(或稱表決),取大多數能接受的表決結果作為處理結果。

5.過載防護

在進行實時系統設計時,應賦予系統足夠的的處理能力,使之能及時處理系統中的所有任務。儘管如此,由於實時系統中事件發生的隨機性,或者說是異步性,它們很可能都集中在某短時間內發生,即出現峰值負載的情況使系統應接不暇,超過其處理能力,從而,帶來所謂的過載(Overload)問題。因此,實時系統必須具備某種防護機構,以保證即使任務過載,系統仍能順利運行下去,也就是說使系統具有一定的自適應能力。

當過載防護機構發現系統出現瞬時峰值負載時,可通過緩衝區予以平滑。即將計算任務存儲於緩衝區中,並按一定的策略排成一個或若干個等待佇列,等候處理。若系統中地過載等待時間很長,就必須採取相應的措施,當然,實時系統中不可能取其它系統中的停止任務插入的辦法,因為這樣很可能拒絕了一些重要的任務,從而給系統帶來嚴重的後果。通常,實時系統中採用的辦法是拋棄一些不重要的任務或降低某些不重要的周期性任務的頻率。

實時軟體測試

實時軟體的測試是比較困難的,它除了完成程式功能的常規測試外,還必須線上地測試系統實時關係。因為即使是系統的每個模組是正確的,也不能保證其總的系統效應是正確的,也不能保證其總的系統效應是正確的。所以,要很好地完成實時軟體的測試工作,一般應做如下工作:

1.模組功能測試

首先,在非並發環境,用軟體測試的白盒法、黑盒法獨立地對各個模組進行測試,考查能否達到規定的功能。如數據處理是否準確,精度是否達到標準,是否滿足實時性要求(在規定時間內完成處理)。

2.實時關係測試

這完全是實時軟體所特有的問題,實時軟體的並發性使其在運行過程中的情況變得十分複雜,難以預知。實時關係測試主要包括任務調度關係測試和任務通訊的測試。任務調度關係測試主要測試多任務並發情況下,各任務是否按規定策略實現有序調度;任務通訊的測試則測試任務間同步、互斥關係以及訊息傳送是否正常,各任務是否能協調地向前推進。

3.構造實時軟體測試工具

鑒於實時軟體必須線上地進行實時關係測試,這是非常困難的事情,未調好的軟體又不能拿到真的實時系統中去運行,所以,必須依靠一定的輔助工具一一藉助於實際系統的仿真模擬系統。用於系統測試的仿真系統不僅具有模擬系統。用於系統測試的仿真系統不僅應具有模設定真實環境的功能,還應具有某些監測功能。環境的模擬設定,使實時軟體各進程運行到一定格局,而監測功能可顯示出相應時候的狀態並跟蹤一些關鍵變數(控制量)的變化情況。系統仿真測試系統在實時軟體開始設計時同步籌劃,齊頭並進。可以說,沒有這些仿真測試系統的支持,大型實時軟體的測試工作是難以完成的。

4.強度測試

強度測試也是實時軟體所特有的要求。在實時控制系統中,計算機的負荷是隨環境和操作變化的。實時軟體的質量保證規範中一般要求軟體必須在指定的強度條件下通過測試,即在一定超強度負荷的情況下仍能正常運行。測試的辦法就是用模擬仿真系統人為地造成極限時空,如同時讓多個部件提出數據處理的要求,並同時在多處設定故障和報警等。

結束語

隨著人類對自動控制系統的廣泛開發,實時軟體的需求越來越大。作為套用軟體來說,它是涉及問題較多、技術較難的一個分支。其工程化問題急待解決,其軟體開發方法、開發環境、開發工具等還有待於進一步研究和提高。

相關詞條

相關搜尋

熱門詞條

聯絡我們