ASCM:基于SOA的嵌入式安全關鍵中間件

摘 要:由于嵌入式安全關鍵系統自身的特點和應用環境的特殊性，導致了設計分布式嵌入式安全關鍵應用比一般的嵌入式實時應用要困難得多。提出了一種新的基于SOA構架的自適應安全關鍵中間件，極大地簡化了嵌入式安全關鍵系統應用的開發，并對相應的體系結構和關鍵技術進行了討論。另外，針對嵌入式安全關鍵系統運行環境的特殊性，重點討論了SOA構架中基于動態配置服務的端到端的自適應QoS管理機制和實時容錯機制的設計和實現。

關鍵詞:安全關鍵中間件; 面向服務構架; 自適應; 端到端; 服務質量; 容錯

中圖分類號:TP311文獻標志碼:A

文章編號:1001-3695(2010)03-0966-04

doi:10.3969/j.issn.10013695.2010.03.043

ASCM:SOAbased embedded adaptive safety critical middleware

ZHANG Yi， CAI Wan-dong

(School of Computer Science Engineering， Northwestern Polytechnical University， Xi’an 710072， China)

Abstract:Embedded safetycritical systems (ESCS) are those systems whose failure could result in loss of life， significant property damage， or damage to the environment. Because of the nature of ESCS， designing the applications for ESCS in distributed environment is harder than those for distributed realtime embedded systems. This paper described a SOA based safetycritical middleware calledadaptive safetycritical middleware (ASCM).ASCM provided related services for ease the development of embedded safetycritical applications. Also presented the technologies of endtoend adaptive QoS management and fault tolerance to satisfy the dynamic and unpredictable mission requirements of ESCS.

Key words:safetycritical middleware; SOA(serviceoriented architecture); adaptive; endtoend; QoS; fault tolerance

0 引言

嵌入式安全關鍵系統(ESCS)是指其系統功能一旦失效將引起嚴重的后果，包括生命或財產的重大損失、環境的破壞、信息的丟失或泄露等應用于安全關鍵領域中的嵌入式系統。

嵌入式安全關鍵系統廣泛應用于航空、航天、國防等重要領域。隨著ES應用的日益廣泛和微處理器技術的不斷革新，其變得日趨復雜。新一代ESCS具有以下特征:功能越來越多，且功能的實現更加依賴于軟件;連網能力成為ESCS的必備功能;在高度自動化、網絡化的情況下，安全性、可靠性問題更加突出。

軟件功能的日趨復雜和應用環境的不可確定性，是目前造成ESCS開發復雜性和高成本的重要因素。設計一種能屏蔽底層運行環境，自適應外界環境變化的應用于安全關鍵領域的中間件，是解決上述問題的有效手段[1]，也是嵌入式安全關鍵領域研究的一個熱點。目前，學術界研究的熱點是嵌入式實時中間件，但將當前的嵌入式實時中間件直接應用于ESCS還存在不能靈活應用、不能保證關鍵任務的QoS等諸多不足。因此，需要一種專門針對ESCS應用的中間件，通過其提供的服務和功能，來保證嵌入式安全關鍵系統的以下關鍵屬性:

a)實時性，保證滿足安全關鍵應用任務的嚴格時限要求。

b)分布性，管理分布式數據的一致性，使得ESCS的內部子系統及它們之間的交互得到實時的監控。

c)可用性，當出現故障時，通過容錯軟件保證安全關鍵應用的高可用性，并保證安全關鍵應用執行的正確性。

d)自適應性，由于典型的嵌入式安全關鍵系統運行在動態、不可預測的環境下，通過自適應屬性可以幫助嵌入式安全關鍵系統解決可靠性和自適應之間的沖突。

針對上述問題，本文提出了一種新的基于SOA構架的專門針對ESCS應用的嵌入式自適應安全關鍵中間件(ASCM)。

1 相關工作

盡管國內外已經針對嵌入式實時中間件進行了多年的研究，同時也取得了多項研究成果，但目前這些嵌入式實時中間件技術直接應用到嵌入式安全關鍵系統的效果都不是十分理想。

Kopetz 等人[2]提出的滿足實時應用三個需求的Mars系統，可以支持容錯和分布式處理，但是這個系統基于靜態和周期調度的模式，并依賴專用硬件來解決容錯和時鐘同步問題，導致了這個系統不能靈活應用于安全關鍵系統。Kieckhafer等人[3]提出的MAFT體系結構可以容忍拜占庭錯誤，來提供可靠的分布式計算而不用犧牲性能。然而與Mars系統一樣，MAFT體系結構也不能靈活地應用于安全關鍵系統。Spring[4]，MarutiⅡ[5]，Basement[6]提出的機制用于管理分布式和實時約束，但是這些機制均不支持安全關鍵應用，如故障檢測、復制等。

CORBA是用于分布式對象計算的標準中間件體系結構，簡化了分布式服務的開發。TAO是CORBA可預測的實現，并提供機制滿足實時需求。但是ASCM目標不同于TAO，TAO的重點在于異種軟件之間的互連，而ASCM重點是使ESCS:更容易重新配置，并能自適應動態改變的網絡和計算環境;端到端資源管理得更為精確;在出錯時及時容錯，保證系統的高可用性。

同時，面向嵌入式系統的QoS的研究工作也開展了多年，但是這些QoS研究大多數集中于軟實時和多媒體方面的應用[7~10]，而ESCS對QoS的要求相對于這些應用更加嚴格。為了滿足這些嚴格的QoS需求，需要構建一個統一的框架，在這個框架下不同的實際應用能夠統一開發。同時，ESCS的關鍵任務在執行時有一些性能指標是必須要滿足的，但服務又是動態的，如何解決這個矛盾，是本文提出的自適應安全關鍵中間件ASCM的一個研究重點。

2 ASCM關鍵技術設計分析

要同時滿足嵌入式安全關鍵系統的實時性、分布性、可用性、自適應性是非常困難的，導致了當前的面向ESCS應用的解決方法只能滿足一些特定應用領域的需求。同時，安全性、可靠性和實時性有時又是互相矛盾的。因此，傳統的用于實現、分配、調度和管理分布式實時系統資源的相對靜態的開發和分析技術，并不能很好地應用到ESCS中去。ASCM必須尋求新的支持動態資源分配能力的架構體系來滿足安全關鍵系統前述的四個關鍵屬性。

在設計ASCM體系結構時，本文的重點是:a)使嵌入式安全關鍵系統更容易重新配置，并能自適應動態改變的網絡和計算環境;b)使嵌入式安全關鍵系統的端到端動態資源管理得更為精確;c) 使嵌入式安全關鍵系統在出錯時能及時容錯，保證系統的高可用性。

2.1 基于SOA的構架模型

作為解決軟件系統構件化過程中長期存在的復雜度和相關度問題的最新方法，SOA借助了開放的社會系統中較為成熟的基于服務的松耦合運營模式的理念，將應用程序的不同功能單元封裝為服務。服務之間通過良好的接口和契約聯系[11]。

如圖1所示，在SOA架構中，服務提供者發布服務至服務注冊中心，服務注冊中心負責管理和維護服務;服務消費者向服務注冊中心發送服務查詢請求，服務注冊中心將請求描述并與服務描述進行匹配，返回合適的服務。通過服務注冊中心，SOA將服務實現與客戶如何使用服務方面隔離開來，有效地降低了兩者之間的耦合性。

ASCM采用SOA構架來解決傳統ESCS系統中的應用和資源調配之間靜態耦合的問題。各種資源分配策略被封裝為服務并發布在ASCM上，安全關鍵服務或上層的安全關鍵應用程序等服務消費者通過ASCM查找，調用服務。由于服務的使用者使用的是服務接口，在運行時，根據實際的參數由ASCM動態地提供各種具體的服務實現。當外界運行環境發生變化時，服務的具體實例可以進行透明替換，從而保證ESCS運行結果的可靠性和實時性。

2.2 端到端的自適應QoS

傳統的嵌入式實時應用QoS管理和應用邏輯是相互耦合的，并依賴靜態的體系結構來提供實時保證，如循環執行。但當需求改變時，特別是當需求改變發生在系統運行時，這種傳統的解決方案就變得非常脆弱。這是由于QoS管理和應用邏輯的相互耦合，使得應用開發人員需要直接面對一些難以預料的突發復雜情況，這樣就大大增加了整個安全關鍵系統故障發生的風險[12]。

滿足分布式實時嵌入式任務關鍵系統的QoS要求是困難的[13]，它需要系統的QoS管理滿足:自適應改變環境條件; 實時地執行自適應; 集成的規范的QoS管理功能;多級端到端QoS管理體系結構。因此，面向ESCS的ASCM的QoS管理必須具有以下的特征:

a)端到端整條路徑上所有重要的資源進行協同和動態的管理。

b)根據端到端路徑上各子系統的任務需求，在多個服務間協同分配資源。

c)在資源分配和任務需求的基礎上，自適應調整應用任務行為和資源使用。

2.3 系統的容錯處理

ESCS對系統的可用性要求十分嚴格，這類系統一旦失效，將帶來災難性的后果。在系統的運行過程中，容錯處理是最重要的可用性保障手段。

在基于 SOA 來構建ASCM時，對于關鍵性的服務需要充分考慮其可用性需求，可以由兩個層次的技術實現來支持:第一層，利用不同服務的具體內部實現所基于的框架容錯或冗余機制，來實現對服務可用性的支持;第二層，通過動態查找匹配方式來支持系統整體的高可用性。

SOA提供了服務需求者與服務提供者之間的解耦，ASCM在服務失效時，確定能夠滿足流程需求的替代服務，并通過重新配置系統來使用這些服務，從而完成系統故障的恢復。ESCS的實時性要求ASCM的故障恢復必須在SLA(service level agreement)規定的時間范圍內完成。

3 ASCM中間件的系統結構

ASCM作為ESCS中間件為軟件應用層提供嵌入式安全關鍵應用所需的服務，并采用自上而下的方法來構建嵌入式安全關鍵應用，如圖2所示。

ASCM自底向上分為OSGi框架、服務擴展層、通用和專用服務層三個部分:

a)OSGi框架作為ASCM的SOA構架的實現平臺，提供了一個適合于在嵌入式設備中進行服務開發、部署和管理的共有模塊框架。這個框架可以管理和動態加載模塊，模塊之間通過服務接口進行協作[14]。

b)服務擴展層擴展了OSGi的服務發現，注冊和綁定機制，并加入了QoS和容錯相關的處理。

c)通用和專用服務層包含了實時關鍵領域所用到的各種服務的實現。

下面分別從OSGi服務的擴展、QoS管理、容錯機制、專用和通用服務四方面詳細介紹ASCM的體系結構。

3.1 OSGi服務的擴展

OSGi的bundle實質上就是能夠對外提供服務的構件，可以由多個服務類組成，是OSGi加載、啟動的基本單元。如圖3所示，bundle被平臺激活后可以注冊和使用服務，所有bundle之間的交互通過服務完成。

OSGi提供了完整的服務注冊、查找、綁定和監聽的定義，但缺乏對安全關鍵應用需求(如QoS保證、容錯處理)的支持。ASCM的服務擴展框架對OSGi框架中的服務注冊、發現和綁定機制進行了如下擴展:

a)在服務的描述中增加了對QoS的描述信息。服務發現時，除了關注服務的接口和靜態屬性信息外，通過QoS 限制對所找到的服務提供者進行過濾，從而得到滿足基本QoS 需求的服務提供者。

b)在服務綁定之前，在滿足接口的可用服務提供者之間展開QoS 協商，從中選擇一個或多個服務提供者。在后續的服務綁定和調用中，服務提供者和服務請求者遵從并履行QoS的約定。在約定的QoS 無法達到時，通過重協商或自適應機制調整服務組合。

c)在服務綁定時，通過動態代理機制為OSGi的服務生成動態代理。當服務訪問時通過代理對服務和資源進行動態監測，自適應地調整服務，保證流程的正確運行。

3.2 服務的QoS管理

要在SOA的體系結構中提供QoS保證，重點是將服務行為模型與QoS模型進行統一描述并封裝在服務構建模型中。在對服務發現和調用的控制過程中，通過QoS約定、監控以及資源分配，在服務提供者與服務請求者之間建立明確的服務綁定協定，并在基于協定的方式下進行服務的綁定[15]。

在OSGi中，所有的bundle通過bundleContext注冊和查找服務。如圖4所示，ASCM通過在bundleContext的繼承類extendedBundleContext中重新實現服務注冊和查找功能方法，以支持基于QoS的服務注冊和發現。ExtendedBundleContext將服務請求者的QoS 需求映射為一組服務發現的約束條件，并基于它們進行服務發現。在獲得可用服務列表后，QoSManager依據一定的匹配策略選取QoS級別，由QoSNegotiation通過兩階段服務預約協議建立QoS預約。

資源管理器(resourceManager)為QoS管理提供了系統資源的管理接口。它負責對系統的資源能力進行建模，對服務請求所需資源進行量化，并在服務運行時監視服務行為和QoS，動態自適應地調節資源的分配。如圖5所示，資源管理器采用了分層的資源管理結構。

各層的功能描述如下:a)系統資源管理器層，負責在各子系統、節點間分配資源并負責向下層局部資源管理器傳遞系統級、任務級的策略。這些策略包括資源的分配，相關的任務需求、參數等。

b)局部資源管理器層，接收來自上層系統資源管理器的相關策略。在局部信息的基礎上，滿足以策略形式傳遞過來的應用任務的需求和限制條件。同時，局部資源管理器在滿足這些限制條件的基礎上，提供比系統資源管理器更為細致和精確的控制行為，監視系統的資源分配，按照相應的次序和程度采用相應的自適應QoS行為。

c)自適應QoS機制層，由封裝好的自適應QoS行為組成，具體包括以下的內容:

(a)通過與資源相關的通用服務來監視和控制相關的資源，如內存、電源或CPU。

(b)專用自適應QoS機制并為資源的監視和控制提供接口。

(c)數據自適應控制，如改變的任務速率、算法或例程，或修改由應用程序組件使用的或產生的數據。

資源管理器的每一層都接收來自上層的策略和下層的狀態，通過使用這些狀態和策略形成相應的QoS決策。

3.3 服務的容錯機制

ASCM針對的執行環境是一個動態、不可預測的分布式環境，被調用的各服務都是具有不同特征的自治組件，其行為具有不可預測性。為了保證服務組合能按預約QoS正確執行，ASCM提供了容錯機制來監視和處理服務運行時的各種故障。

在沒有擴展的OSGi中，服務提供者需要在業務處理中檢測自身狀態。當不能提供服務時，通過unregister方法注銷服務，服務消費者會同時收到服務的注銷事件。因此，系統不能主動地去檢測系統的當前狀態，并根據服務狀態準確預測QoS變化，從而采取自適應機制調整服務組合，替換失效的服務。

由于OSGi沒有提供框架層面的容錯處理支持，ASCM為每個OSGi服務提供一個服務代理。當服務請求者綁定服務時，服務擴展框架不返回實際的服務提供者，而是動態地產生服務提供者的一個服務代理。服務代理和服務提供者的結構關系如圖6所示。

服務代理攔截所有發給服務的調用請求，并將請求轉發給容錯管理器。容錯管理器通過服務監視器追蹤服務的狀態:當服務正常時，將服務的調用轉發給被調用服務的提供者;當服務失效時，通過重定向服務調用完成服務的透明替換。ASCM容錯處理的時序如圖7所示。

ASCM提供了兩種替換失效服務的策略:動態投票和故障切換。在動態投票策略中，兩個服務提供者同時執行相同的服務，都產生一個臨時的結果，服務的使用者在這些結果中進行比較(投票)，選定最終結果。在故障切換策略中，提供同一服務的兩個提供者一個為主，一個為從。正常運行時，由主提供者提供服務，當主提供者失效時，從提供者取代主提供者繼續提供服務。

由于兩種替換失效服務的策略，在故障轉移時發生的時間是不同的，上層ESCS應用程序可以根據實際情況通過QoS協議進行容錯策略指定。

3.4 專用和通用服務

傳統嵌入式軟件的設計與部署方法只能一次性發揮作用，非常不利于后續的系統集成。每一種新設備的軟件開發幾乎都要從頭做起，以往的軟件開發成果很少有機會在新設備軟件中發揮作用。ASCM采用了基于SOA的構架，每一個服務都是一個獨立可復用的單元。通過對一些安全關鍵應用算法和調度策略的重用，ASCM大大降低了ESCS的開發成本并提高了其可靠性。ASCM提供的用于簡化和縮短ESCS應用開發的多種靈活服務分為以下兩種服務:

a)專用服務。是指與各種實時調度策略相關的服務機制。專用服務及其相關屬性的設計高度依賴于安全關鍵應用所固有的一些特征，如應用任務到達速率、任務優先級、搶占策略和資源訪問模式等。ASCM專用服務所提供的調度策略能夠支持大范圍的安全關鍵應用，并根據每個應用任務反應時間的不同，規定相應的關鍵度。最后調度策略根據專用服務所規定的應用任務的關鍵度，再進行相應的調度。

b)通用服務。包括嵌入式安全關鍵應用能夠共享的健壯性屬性。具體的通用服務例子有應用任務的調度、錯誤發現、時間綁定的可靠多播和廣播、時鐘同步算法和監視服務。設計通用服務的目的是保證ESCS應用的可靠性、實時性和分布式數據的一致性。同時，通過通用服務使得應用開發人員無須再去考慮與底層相關的容錯處理、同步控制和監視管理。

4 結束語

嵌入式安全關鍵系統廣泛應用于航空、航天、國防等關鍵領域中。隨著軟件復雜度的提高，這類軟件的開發成本和時間急劇增加，常常達到人們難以接受的程度。為了應對這個挑戰，本文提出一個專門面向ESCS的自適應安全關鍵中間件ASCM。ASCM采用了SOA構架，在動態配置的服務基礎上實現了端對端自適應QoS管理和運行時容錯處理。通過對一些安全關鍵應用算法和調度策略的重用，ASCM大大降低了ESCS的開發成本并提高了ESCS的可靠性。

筆者今后的研究重點是進一步對ASCM的相關服務進行細化，并設計更多的相關服務和工具來簡化ESCS應用程序的開發。

參考文獻:

[1]

ISSARNY V， CAPORUSCIO M， GEORGANTAS N. A perspective on the future of middlewarebased software engineering[C]// Proc of International Conference on Software Engineering.Washington DC: IEEE Computer Society， 2007: 244-258.

[2]KOPETZ H， DAMM A， KOZA C， et al. Distributed faulttolerant realtime systems: the Mars approach [J]. IEEE Micro， 1989， 9(1):25-40.

[3]KIECKHAFER R， WALTER C， FINN A， et al. The MAFT architecture for distributed fault tolerance [J].IEEE Trans on Computers， 1988， 37(4):398-405.

[4]MOLESKY L D， RAMAMRITHAM K， SHEN C， et al. Implementing a predictable realtime multiprocessor kernel: the spring kernel[C]// Proc of the 7th IEEE Workshop on Realtime Operating Systems and Software. Washington DC: IEEE Computer Society， 1990: 20-26.

[5]SAKSENA M， Da SILVA J， AGRAWALA A. Design and implementation of MarutiⅡ， CSTR-2845[R]. [S.l.]: Prentice Hall， Inc， 1995: 73-102.

[6]HANSSON H， LAWSON H， STROMBERG M， et al. Basement: a distributed realtime architecture for vehicle applications [J]. RealTime Systems， 1996， 11(3):223-244.

[7]CAMPBELL A， AURRECOECHEA C， HAUW L. A review of QoS architectures[C]// Proc of IWQoS. 1996:138-151.

[8]WANG Zheng. Internet QoS: architecture and mechanisms for quality of service [M]. San Mateo: Morgan Kaufmann， 2001.

[9]SCHANTZ R， LOYALL J， RODRIGUES C， et al. Flexible and adaptive QoS control for distributed realtime and embedded middleware[C]// Proc of ACM/IFIP/USENIX International Middleware Conference. Berlin: Springer， 2003.

[10]SHANTZ R， LOYALL J， RODRIGUES C， et al. Controlling qualityofservice in distributed realtime and embedded systems via adaptive middleware [J]. Software: Practice and Experience， 2006， 36(11-12):1189-1208.

[11]The open service oriented architecture collaboration [EB/OL]. http://www.osoa.org/.

[12]GILL C D， LEVINE D L， SCHMIDT D C. Towards realtime adaptive QoS management in middleware for embedded computing systems[C]// Proc of the 4th Annual Workshop on High Performance Embedded Computing. Lexington: Massachusetts Institute of Technology， 2000.

[13]GILL C D， KUHNS F， LEVINE D L， et al. Applying adaptive realtime middleware to address grand challenges of COTSbased Missioncritical realtime systems[C]// Proc of the 1st IEEE International Workshop on Realtime MissionCritical Systems: Grand Challenge Problems. Axizona: IEEE Press， 1999.

[14]OSGi Alliance. OSGi service platform [EB/OL]. http://www.osgi.org.

[15]胡春明， 懷進鵬， 沃天宇，等.一種支持端到端QoS的服務網格體系結構[J]. 軟件學報，2006，17(6):1448-1458.