基于架構的軟實時軟件的自適應框架的研究*

包曉安，張 娜，桂 寧，宋瑾鈺

（浙江理工大學信息學院 杭州310018）

1 引言

傳統實時系統，如過程控制系統，通常工作在封閉和高度可預知的環境。這些系統也只能提供預先定義的、固定不變的服務。只要滿足這些假設和條件，這種方法能夠高度保證硬實時需求得以滿足。然而，越來越多的系統被應用于動態的環境中，如在云計算系統中，服務器的配置不斷地發生改變。在這樣的動態環境中，傳統的基于瀑布模型的實時應用程序開發模式不能有效工作[1]。提供有效的實時軟件的重配置支持，提供整個系統的生命周期中系統配置演變支持，已經成為研究的熱點問題。

這種開放和不斷演變的執行環境需要新的辦法來建立和管理實時應用程序。但是，由于系統資源的缺乏，這些已安裝的應用程序通常在一定程度上是互相依存的，不同的應用程序會相互競爭CPU、內存、網絡或其他系統資源。這種依賴性可能會導致違背實時程序不能滿足亟需滿足的實時特性指標[2]。

傳統的基于實時操作系統和實時調度的解決方案無法應對這樣復雜的依賴性。系統作業調度器本身不可能理解這種高級別的應用程序的相互依賴性。在某種意義上，實時操作系統離應用程序級的問題太“遙遠”，因此無法正確決定自適應策略，如選擇哪些組件、預留哪些資源。對于云計算來說，這就意味著系統的調度程序無法很好地使用后臺的服務器資源。

由設計自適應實時系統的經驗可知，為了支持動態變化的實時應用程序，任何一個有效的解決方案應該有以下3個重要方面[3]。第一，跨應用程序的資源需求管理。第二，組件依賴的依賴必須顯式化，包括顯式功能的依賴和由于爭奪有限的可用資源而產生的隱含功能的依賴。第三，系統高層模型應該可以被用于驅動相應實時任務的較低級別的管理。

本文從不同的角度解決這些問題，引入一種基于結構的管理框架，即聲明實時組件的框架（DRCom框架），跨越安裝應用程序域。通過從它的元數據及其組件管理接口引出每個實時組件的不同屬性，可以為當前實時系統構建一個準確的總體結構模型。為了保證實時應用程序的某些性能，可根據不同的適應策略對該模型進行映射以調整低級實時任務的屬性和狀態。得益于面向服務的體系結構，該框架易于用其他依賴解析策略進行擴展，以處理不同的系統需求。本文定性和定量地證明了本體系結構的有效性，可以用于云計算的資源調度管理。

2 軟件架構

為了支持動態變化的實時應用程序，本文提出了一種基于架構的自適應軟件設計模式，即聲明實時組件框架（DRCom框架），用以生成自適應實時應用程序。

2.1 架構設計目標

為了在提供實時支持的同時，應對高度動態的運行環境，本文的軟件架構提供了3種功能支持，即實時組件動態支持、實時組件依賴性支持、可自定義的全局自適應支持，實現了將系統生命周期的所有請求當作一個整體進行控制管理，能快速得到當前系統配置，并能管理軟硬件各組件間兩種類型的依賴，即關于業務邏輯的功能性依賴和關于QoS需求的非功能性依賴。利用當前系統配置以及組件間的功能性和非功能性依賴的相關描述定義自定義的適應策略，并根據資源的動態可用性和自適應策略，采用不同的約束策略。

2.2 系統需求

本模型使用可擴展的元數據文件中聲明DRCom的各個實時屬性。由于不同的實時應用程序具有不同的特定的域和功能，不可能提出一個萬能的自適應邏輯，因此系統的體系結構必須適應不同的環境。

本框架的設計可以使用不同種類的描述語言和適應邏輯。用3個關鍵模塊，即描述模塊、推理模塊和動作模塊，滿足各種需求。描述模塊進行依賴關系和配置說明，推理模塊進行推理說明，動作模塊進行相應的動作描述。參考文獻[4]和現有的大多數研究，都是在運行時靜態地集成這3個模塊，與此相反，本框架通過運用面向服務的模型，將這3個模塊當作服務提供者來執行，各服務提供者通過服務接口松散耦合。這種設計使得未來復雜自適應模塊可以容易地融入本框架中。

2.3 結構框架

圖1所示為本文所述結構框架的示意。該框架由3個主要部分組成，分別對應于第2.2節所述的3個模塊，其他部分提供輔助性服務。

其中，資源依賴性表示機制（自定義語言解析服務，作為描述模塊）允許開發人員用自定義的語言描述組件依賴性；自定義約束解析服務（作為推理模塊）允許用戶或管理員指定特定域系統的自適應策略；描述性實時組件運行時執行環境DRCR（動作模塊）是本框架的核心，它管理DRCom實例并執行解析服務推理出的動作，負責監測由資源管理服務和OSGi系統發出的更改事件，并由DRCR維護的DRCom實例注冊表來保存已安裝的實時組件實例的信息。

本框架設計了一個完整的組件生命周期模型和一個相應的實時組件管理界面。根據自定義約束解析服務做出的決策，DRCR完全控制組件的生命周期。自適應過程由組件狀態更改和外部事件源的通知（如資源管理器或簡單的周期時間）觸發。

3 架構組件

實時組件說明在元數據文件中定義，該文件描述了特定實時組件的主要特性。此外，本文使用支持復雜描述語言的混合實時組件模型[5]。

在DRCom實現中，實時組件配置表示組件實例的功能需求和非功能需求。如上所述，框架應能夠支持不同的描述語言。但從實現的角度看，純粹分離的方法意味著事先不了解組件元數據格式，這將導致相當大的實現復雜性和不必要的性能開銷。與復雜的非功能需求相比，組件的功能需求部分有較好的結構和穩定性。為了在性能和復雜度之間達到一個平衡點，使用兩相模式描述和處理組件的功能性和非功能性依賴。其中，功能部分由XML（extensible markup language，可擴展標記語言）定義，由DRCR解析；非功能部分的組件資源的先決條件描述，由外部的自定義解析服務進行解析，并對已解析的數據進行處理，然后將結果發送到DRCR。

圖2所示為元數據文件的一個片段，其中包含了一個能夠根據需要返回用戶感興趣的區域（一幀圖像數據的子集）的智能相機組件的功能和非功能需求。

其中，name：被用作組件調用名，因此必須是全局唯一的；enabled：控制組件是否啟用，其默認值為真。組件的implementation元素定義組件實現類的名稱，DRCR通過引用此屬性創建組件實例，因此是組件必不可少的元素。組件的inport和outport元素定義通信方法，通過它們可進行組件間數據共享。組件可能有0個或多個輸入、輸出端口。outport指定實時組件所需輸出的內容，它包含一個用作通信調用的名稱屬性。而除了名稱屬性外，輸入端口還具有以下屬性。interface：通信接口，它可以是共享內存、實時FIFO導管或郵箱。type：傳輸的的數據類型，可以是整型或字節。size：數據類型的基數。與outport相比，inport有一個額外屬性，即optional屬性，該屬性顯示此端口依賴性是否是組件執行所必需的。此外，組件描述也可以有許多屬性，可以通過管理接口來利用這些屬性元素配置實時組件實例。

4 約束關系解析

本文實時組件框架的一個關鍵過程是約束關系解析，它負責識別實時組件之間以及資源之間的關系，并根據當前系統環境推斷出系統可能的反應。

當系統配置更改時，例如，有新的實時組件的出現或者資源管理服務組件提示有明顯的資源變化，DRCR將被激活。首先它將檢查已有的 DRCom約束和依賴；如果功能部分成功通過檢查并滿足要求，DRCR將判定是否能在不危害其他組件實時合同的有效性的條件下滿足組件的非功能需求，如果能夠滿足，這一新組件將被激活。

為了與兩相DRCom配置一致，運用兩相約束解析。一個是功能依賴解析相，用于在發生系統更改時檢查各個實時組件功能依賴；另一個是自定義約束關系解析相，由于本框架使用OSGi面向服務的模型，因此系統管理員可以通過注冊自定義的解析服務改變系統解析行為，以適應特定的系統配置。

4.1 功能依賴解析

功能依賴解析主要包括以下的兩個步驟。

（1）循環檢測

應用程序中由實時組件構成，通常可以建模為一個組件聯通圖，該圖通常是有向無環圖。在任務路徑上，組件上的任務具有一組輸出，這組輸出是該路徑上下一組件上的任務的一組輸入。一組組件描述可創建一個循環依賴，此時至少有一個組件的配置不能得到滿足，當DRCR試圖滿足組件配置時，它將檢測循環引用。這時，DRCR運行時將記錄一條錯誤消息，且不激活任何可能創建循環依賴的組件配置。

（2）端口兼容性檢測

為了滿足功能性依賴，所有已啟用和激活的組件輸入端口應有相應的輸出端口。這意味著它們的端口名稱、接口類型、數據類型和數據大小應完全匹配。圖2中的智能相機端口需要一個“windowsposition”輸入端口。為了滿足端口的兼容性檢查，名稱為“ua.pats.trajectory.windows”的已激活的組件實例和按如下定義的輸出端口必須已經在注冊表中部署和啟用。

4.2 自定義解析過程

在實際環境中，根據資源的動態可用性和系統特定需求，需要不同的資源描述方法。因此將自定義解析服務設計為面向服務的模型，以提供可自定義的支持。

通過使用不同的自定義解析服務提供者，系統行為可以在不更改應用程序主要功能邏輯的情況下輕易地改變，這緩解了重新編譯和加載整個應用程序的需要。一個基本的解析策略是，必須在激活組件配置之前滿足所有基本的資源需求。不管怎樣，運用特定的上下文或依賴性知識，可以進行更加靈活、復雜的解析，例如，通過停止低優先級任務或具有可選端口需求的任務，給高優先級實時組件釋放更多資源。此外，某些規則引擎，如Jess[6]，也可以集成到解析服務中。

多個自定義解析服務提供商可以共存于本系統中，DRCR會選擇一個與當前系統環境相匹配的候選服務提供者。在當前實現中，系統上下文是一個由管理員管理的全局屬性，下面筆者利用上下文推理策略，獲取更準確、靈活的上下文信息，以便使用更適當的自定義解析服務。

4.3 自適應配置時序圖

圖3所示為自適應軟件框架的動態調整時序。本方案中，組件B需要用組件A的輸出滿足其功能約束。由于組件A配置已經存在實例（ComAInstance），因此DRCR將成功解析B的功能約束。然后訪問內部解析服務和外部自定義服務，如果兩個服務均返回積極結果，DRCR將根據組件B的配置創建并激活它的實例 （ComBInstance）。如果ComAInstance被停止，DRCR將得到通知，并再次請求其內部和外部自定義服務以檢測新的滿足或不滿足條件的組件實例，當DRCR發現ComBInstance目前尚未滿足，那么ComBInstance將被禁用。

5 系統仿真

本文使用基于場景的仿真，測試基于框架的自適應軟件的動態調整模式，并定性和定量地驗證所提的框架的特性。

5.1 系統實現

系統使用OSGi[7]框架作為實現平臺。OSGi技術一個是通用中間件平臺，其開放標準簡化了新功能和服務的引入。筆者的基本開發平臺是Equinox，它是Eclipse組織開發的免費開放源OSGi平臺。組件實現中，使用DRCom模型，該模型最初是為動態可配置的反射實時系統的建模而設計的，它有一個基本的管理界面，能夠統一管理組件的生命周期和屬性，每個組件都與一個記錄其抽象概念（如通信接口、屬性以及引用約束）的元數據文件相關聯。這種方法提供了一種元數據級的反射和自檢，每個組件都標記了任務相關的配置和驗證信息。

5.2 模擬配置

由一個仿真的機頂盒系統進行模擬。該機頂盒系統運行2個應用軟件，一個是電視應用程序，一個是視頻文件轉換工具。各個軟件的核心模塊（解碼器和轉碼器）的執行組件都是以周期任務的形式執行。電視應用程序的解碼組件由一個周期為33.37 ms的實時任務實現，其優先級為2、執行時間約8 ms、截止時間為12 ms；轉碼器組件由一個周期為50 ms的實時任務實現，其優先級為1、執行時間約1 ms、截止時間為30 ms。其中，RTAI系統使用的計劃策略是FIFO。為了顯示這兩個組件之間的相互作用，其他組件只占用少量的CPU時間進行實現。此外，傳輸方法是異步的（共享內存），這樣就能夠重點研究兩個編碼模塊的性能。

由于視頻解碼執行時間會隨著視頻流內容的變化而改變，為了更加清晰地表明不同應用程序之間的相互影響，用一個在每輪計算中使用了同等恒定CPU時間的計算函數代替解碼函數。

5.3 仿真結果

對電視應用程序中解碼組件的執行時間進行5 000次觀測，表1顯示了有和沒有自適應框架支持時組件的執行時間。為了消除冷啟動和自適應過程帶來的影響，在系統啟動并能穩定執行后，才開始記錄測量數據。執行時間用微秒（μs）表示。

正常情況下，解碼器的執行時間大多為8 ms左右，有自定義解析服務（它會禁用轉碼模塊）時最大執行時間約8.13 ms；沒有自定義解析服務時，系統會同時運行這兩個應用程序，解碼器任務執行時間的抖動很大，其平均偏差是3 563.2 μs，遠遠大于有框架解析機制時的 5.23 μs，這最終可能導致視頻解碼任務的瞬態時間問題，包括幀缺失、數據溢出等。

表1 執行時間的比較

6 結論和進一步工作

本文描述了一種支持運行時自適應的軟件設計模式，以應對復雜的實時系統的動態演變和連續調度問題。其中，實時合同由組件元數據指定，組件實例由依賴解析服務和實時合同系統管理，DRCR服務對當前系統配置進行全局管理。這種系統能夠推理出系統配置更改的原因，能在遵守指定的實時組件實時合同的前提下執行某些操作，并使得各實時組件不必監視系統狀態，就能調用其他可用的動態實時組件。雖然本文所述框架是基于OSGi中間件的，但研究結果將會普遍運用于其他基于結構的管理系統。

雖然本文描述了一個為基于組件的應用程序提供實時屬性的完整方法，但仍有許多地方需要進一步研究。其中之一就是如何使用元數據來描述那些組件特有的自適應接口和功能，進而使系統具有更靈活、更強大的自適應能力。

1 Hassan Gomaa,Koji Hashimoto,Minseong Kim,et al.Software adaptation patterns for service-oriented architectures.Proceedings of ACM Symposium on Applied Computing (SAC),Sierre,Switzerland,2010:462～469

2 Gui Ning,Florio V D,Sun Hong,et al.A framework for adaptive real-time applications:the declarative real-time OSGi component model.Proceedings of the 7th Workshop on Adaptive and Reflective Middleware(ARM),Leuven,Belgium,2008:35～40

3 Gui Ning,Florio V D,Sun Hong,et al.A hybrid real-time component model for reconfigurable embedded systems.Proceedings of the 2008 ACM Symposium on Applied Computing,Fortaleza,Brazil,2008:1509～1596

4 Santambrogio M D,Rana V,Beretta I,et al.Operating system runtime managementofpartially dynamically reconfigurable embedded systems.Proceedings of the 8th IEEE Workshop on Embedded Systems for Real-Time Multimedia,Scottsdale,AZ,United states,2010:1～10

5 Colmenares J A,Kim K H,Zhang Z,et al.Real-time-component based software architecture for QoS-adaptive networked multimedia applications. Proceedings of the 13th IEEE International Symposium on Object,Component,and Service-Oriented Real-Time Distributed Computing (ISORC),Carmona,Seville,Spain,2010:133～142

6 Jess:the rule engine for the Java platform.http://www.jessrules.com/jess/index.shtml

7 OSGi service platform core specification.http://www.osgi.org,2011