熊葉青,張樹東,韋 冰
(首都師范大學 信息工程學院,北京100048)
航天活動中的測控任務等關鍵業務量的增長和對服務質量要求的提高,高可靠性、高可用性和易維護性日益成為航天測控系統的設計目標。而軟件可靠性已變得越來越重要,特別是對于安全關鍵和任務關鍵的系統尤其如此。航天器組件日趨復雜化,高可靠性和高自動化的真空熱試驗是保證航天器組件質量的重要環節之一。其測控平臺主要承擔著航天器真空熱試驗時的溫度測量、空間外熱流模擬、航天器溫度控制等關鍵任務。高可靠的測控平臺,是航天器在地面成功實現各類空間環境試驗不可或缺的,對掌握航天器的環境適應性,保證航天器質量,確保航天活動正確進行具有重要作用。從提高軟件的可靠性角度出發,針對測控平臺的實時性特點,本文提出了一種分布式四層架構模型,該模型遵循高內聚低耦合的原則,在測控系統中具有廣泛地適用性。
目前軟件可靠性技術主要可以劃分成三類:避錯技術,排錯技術和容錯技術[1]。通常軟件錯誤需要經歷軟件錯誤,軟件缺陷,軟件故障和軟件失效這一過程才能最終導致軟件功能的部分或全部失效[2]。因此,在軟件設計階段,我們應從軟件源頭入手,減少軟件錯誤的產生;同時,一旦錯誤產生,應該在演變過程中設置不同的屏障,防止錯誤的蔓延和擴展。
避錯技術是指采用正確的設計和質量控制方法盡量避免把故障引進系統以及盡量減少各模塊的失效率,它主要采用設計方法學來使得軟件盡可能的無錯。因此,避錯技術通常包括軟件說明書設計,軟件結構設計,模塊設計,健壯性設計,編程風格等可靠性設計。
(1)軟件結構設計。軟件結構設計分為系統結構設計和程序結構設計。前者是把大而復雜的軟件系統分解成子系統,主要有分層抽象法,模式驅動法,領域驅動法等;后者的任務側重于定義程序的全部模塊、模塊間的優先結構及模塊間的接口關系。
(2)模塊化設計。模塊化設計中,系統模塊化分解后,各個模塊之間的耦合度是影響模塊獨立性,即影響避錯設計的一個重要因素。在軟件開發過程中應該嚴格遵守高內聚、低耦合的軟件設計原則。文中利用模塊化設計方案對基于DSP的無人機導航系統軟件進行實現,提高了系統的實時性,可繼承性和維護性[3]。
(3)健壯性設計。健壯性設計主要是使系統能夠抵御各種外界干擾,防止錯誤輸入和錯誤操作等不確定性因素造成系統錯誤,如.net數據驗證技術、正則表達式等都能夠對非法輸入進行分類處理,阻止錯誤向系統內部轉移,起到屏蔽軟件錯誤的作用。
避錯技術是提高系統可靠性的第一道防線,在軟件錯誤演變過程中起著減少軟件錯誤的重要作用。文中提出了一種軟件故障診斷過程框架,將軟件故障檢測、故障定位、故障排除等活動集成在一起,把這種框架設計用于實際的軟件故障診斷,驗證了其有效性.避錯設計在系統軟件設計中合理運用對提高系統可靠性具有重要的應用[4]。
排錯技術的使用能夠大幅度地提高軟件的可靠性,但當軟件系統很復雜時,很難通過計算機語言用形式化的方法把它們合理地表達出來,因此需要采用查錯,糾錯等手段,排除系統錯誤。
(1)軟件測試技術:軟件測試的目的在于發現程序中的錯誤,盡可能提高代碼的正確性和健壯性。可靠性測試過程中搜集到的測試數據是評估軟件可靠性水平的重要依據。常用錯誤密度、出錯率和缺陷指數等指標來確定系統是否進行了足夠的測試。設測試時間周期T 內,第i次代碼測試發現的錯誤數為ni,則總錯誤數為NT=∑ini;錯誤密度 (nd)表示每千行源代碼 (kLOC)的錯誤率,則有nd=NT/kLOC;出錯率 (nr)表示每單位時間內的出錯數,則nr=NT/T,缺陷指數 (nq)表示錯誤的嚴重程度。測試過程中每次發現的錯誤,我們可以區分為嚴重錯誤、中等錯誤和輕度錯誤三類,并分別賦予不同的錯誤權重w1,w2,w3。設第i次測試的錯誤數ni中,發現的嚴重錯誤數是hi,中間錯誤數是mi,輕度錯誤數是li,則該次測試的缺陷指數定義為pi=(w1×hi+w2×mi+w3×li)/ni。若考慮軟件生命周期各個階段的權重,設第i次測試的階段權重為qi,則在測試時間周期T 內的缺陷指數是:Nq=∑i(qi×pi)/kLOC。
測試過程中對這些可靠性測試指標的確定,不僅有利于評估軟件可靠性水平,同時有利于建立軟件可靠性模型對軟件可靠性進行預測。
(2)軟件可靠性模型:通過軟件測試,我們可以獲得系統的錯誤數據、失效數據、缺陷數據等,結合這些數據,有助于軟件可靠性模型的建立。
軟件可靠性模型是軟件可靠性定量評估技術的核心,能夠幫助我們對軟件可靠性進行測試、評價、估測及驗證。Martin等提出了基于模型開發和自動化驗證的方法,該方法符合歐洲標準ECSS-E-ST-40C系列,適合航空航天領域中安全性至關重要的軟件開發和測試[5]。Long等利用軟件可靠性增長模型跟蹤和預測軟件可靠性增長用于提高軟件質量[6]。
(3)故障檢測技術:故障檢測是容錯的前提和基礎。我國針對某一號衛星的可靠性專門設計了智能故障診斷系統,該系統采用XML語言對任務失效準則進行描述,不僅能準確地判斷故障,同時能提供故障趨勢警告,幫助故障檢測人員實施正確的對策[7]。
航天系統依賴于硬件和軟件的組合,許多軟件測試方法專注于源代碼,卻忽略了由硬件故障或異常所引發的軟件錯誤。Wu J討論了一般性的 “硬件故障—軟件異?!到y故障”的流程,并闡述了有關軟硬件故障檢測的方法[8]。Yan Zhang等以DFT 理論為背景,對幾種硬件故障算法進行了仿真,分析、比較了它們在提高可靠性方面的優缺點[9]。
借助避錯、排錯技術不可能使系統完全不存在錯誤或缺陷,因此軟件容錯技術成為提高系統可靠性的關鍵所在。軟件容錯技術是指系統在發生錯誤的情況下,仍能不中斷系統正確、穩定地運行。其基本思想是冗余技術,即在一個部件上并聯相同的備份部件,當該部件發生故障時,備份部件取代故障部件。目前,主要的容錯技術有RAID 技術,全冗余雙機熱備技術,容災備份技術,集群技術等,此外還有一些在特定環境下使用的USP監控系統技術等。
(1)RAID 技術。RAID 是一個硬盤組,具有較高的存儲性能和數據備份功能。當數據發生損壞后,利用備份信息可以使損壞數據得以恢復,從而保障數據的安全性。
(2)全冗余雙機熱備技術。該方法利用心跳信息在主備服務器之間相互傳遞狀態信息的方法,實現備用服務器對主服務器的不斷監聽,同時通過同步數據備份技術實現主備服務器中數據的一致性。
(3)容災備份。容災備份是在本地和相隔較遠的異地,建立2套或多套功能相同的系統,互相之間通過健康狀態監視和功能切換,利用地理上的分散性來保證關鍵業務和數據對于災難性事件的抵御和恢復能力。
(4)集群。高可靠性集群,當集群中其計算機出現故障時,在故障機上運行的任務可以自動由其它運行正常的計算機接替,使整個集群的服務仍然可以正常運行。章宏燦等人利用基于Markov模型的集群RAID5構建可靠性存儲系統,提高了系統重構速率和可靠性[10]。
在航天、航空、軍事等領域的工業應用中,計算機群經常需要與各類設備進行通信,實現控制、測量、管理等功能。在通用的三層結構模型的基礎上,進一步融合設備層,將形成圖1所示的四層分布式系統結構模型。該模型由展現層、業務層、數據層、設備控制層構成。各層之內仍然保持高度內聚,層次之間則通過松耦合接口和密集消息交互。

圖1 四層架構模型
基于上述抽象的四層分布式系統模型,能夠根據不同的業務需求形成不同的分布式應用系統。航天器真空熱試驗平臺利用設備層對溫度的控制、測量、管理實現對航天器組件的熱流模擬等達到對航天器組件進行真空熱試驗的目的,它符合上述的四層分布式系統模型,是一個典型的基于四層模型的分布式應用實例。下面對其各層的詳細設計進行展開介紹。
設備控制層直接與設備進行通信,對設備進行控制和管理。借鑒文獻 [8]中對軟硬件實時監控的思想,補充以智能診斷的功能,在設備控制層設計了智能代理,實現對設備的智能診斷、自動檢測等功能。
智能代理主要由能夠完成實時對設備的各種狀態信息的采集、處理的監測程序和利用人工智能推理機制、領域專家知識、裝備管理信息等對故障能夠進行分析、比較、判斷、反饋的故障診斷程序組成。
監測程序通過命令、設備寄存器等方式完成對實時信號、狀態的采集、處理,監控人員也可在本地對設備進行監測和控制。監測程序采集的狀態信息會在數據庫中進行存儲,作為運行歷史數據為以后分析、設備維護、可靠性預測提供依據;同時根據代理配置,數個周期之內的狀態信息會在本地進行存儲,有助于故障診斷系統迅速從本地獲取數據進行分析、處理、診斷,從而減少系統的吞吐量,加快響應時間,提高系統的可靠性。
代理根據診斷結果生成指令對設備狀態進行調控,同時向客戶端反饋狀態信息及診斷結果,并將其存入數據庫中。若智能診斷系統無法對故障進行診斷,診斷系統會通過服務器向客戶端推送相關信息,在領域專家的參與下,獲得問題的解決方案對設備進行控制。
數據層用于存儲各類數據,其可靠性與系統的安全性、穩定性、持久性密切相關。測控平臺絕大部分功能在處理各類數據,尤其是試驗過程中產生的大量數據會存儲到數據庫中,供專家進行分析、評估、預測等,因此確保數據的完整性和可用性十分重要。
通常把集群分為高可用性集群、負載均衡集群和高性能集群[11]。常用的機器的穩定可用性可定義為A =MTTF/(MTTF +MTTR),其中MTTF 是機器的平均無故障時間,MTTR 是錯誤的平均修復時間。同樣地,軟件的可靠性也可以用錯誤出現和糾正的速率來表示。高可用集群的目的是減少服務中斷時間,故障轉移集群是其中一種。
當系統檢測到故障時自動進行故障轉移。即故障轉移集群會停止當前的活動節點,根據轉移策略,選擇新節點,啟動新的實例進程,對未完成的事務進行回滾。同時由于數據是存儲在共享的SAN 上,在故障轉移過程中并不需要數據復制,宕機時間也就只發生在故障轉移時的短暫瞬間,這樣就盡可能地提高了MTTF ,減小了MTTR ,從而使整個系統具有較高的可用性、可靠性。
文獻 [7]中采用數據庫集群的高可用設計實現衛星控制中心系統平臺,使系統的高可用度提高了1.5 倍。SQL Server解決高可用性問題的方案之一是故障轉移集群,故障轉移集群具有明顯的快速恢復,零數據丟失、自動故障轉移的特性,能有效解決測控平臺對實時采集、存儲數據的功能需求。
業務服務層是連接設備控制層、數據層和展現層的橋梁,系統業務的復雜性等將使服務器面臨服務超載、網絡擁塞、數據信息量過大的挑戰。提高單個服務器硬件的性能,并不能從根本上解決問題,因為單臺服務器的性能是有限的[12]。
負載均衡集群是把大量的同一類型的并發訪問,分擔到多臺節點設備上分別處理,提高系統的可靠性。為了應對日益復雜的各類航天空間環境試驗,最大程度地保持最優服務質量。服務端模塊采用負載均衡技術,其負載均衡體系結構如圖2所示。

圖2 服務端模塊負載均衡體系結構
當服務器接收到外界的請求,負載均衡器會根據監控獲取集群里各后臺服務器的健康狀況和權重,將客戶端的請求根據加權最小連接度算法把請求發送給處理能力強,任務少的后臺服務器。設計的主、備負載均衡器,與集中式負載均衡相比,能解決其只能集中處理所有的負載服務,不能分發所有客戶請求這個系統瓶頸問題,有效防止產生單點故障,提高系統的可靠性。
設備控制層的智能代理和數據層的高可用數據庫都是部署在圖2中的真實服務器上,這些都要求系統具有較高的可用性。負載均衡體技術能夠實現當某臺服務器出現障礙時,負載均衡器可以立刻分配其它的應用服務器并由該應用服務器繼續提供服務,使得服務器集群具有一定的容錯性、可用性,能從錯誤中恢復過來。
展現層是人機交互的接口,它位于系統的最外層,主要接受用戶的請求,用數據、圖、表的形式向用戶返回,并為客戶端提供應用程序的訪問。
客戶端需要不斷接收服務端發送給客戶端以及用戶給服務端的重要數據。在實際應用中,由于系統的復雜性、人為的誤操作等均可導致客戶端關閉、停止工作。為了解決因客戶端程序關閉不能及時接收服務層數據,造成數據延時、丟失的不一致性問題,我們在展現層設計了基于操作系統服務的服務代理模塊。
該模塊的存在可以在客戶端崩潰后,繼續維持與服務的會話,接收服務端的重要數據,在一定程度上維持了數據的完整性。據統計,代理模塊能夠對實時系統的可靠性提高約10%。在服務代理中,對接收的數據進行本地化保存,因此加載數據無需通過網絡訪問遠程數據庫,極大提高了數據分析模塊在數據加載方面的速度。
服務代理的設計可以避免由于系統資源問題和低級操作錯誤帶來的風險,在一定程度上保障程序運行的可靠性,但也并非絕對安全。當計算機需要重啟時,服務代理必須重啟而仍可能會導致數據丟失。因此,在客戶端的下層額外設計了在服務重新聯機時的數據同步機制。
測控平臺系統在四層架構模型的基礎上,引入智能代理的診斷和檢測、數據庫容錯、服務器集群和基于操作系統服務的服務代理等軟件可靠性技術,使其在軟件錯誤演變過程中對錯誤進行規避、排除、糾正和容錯,加快了系統的響應時間,使系統具有伸縮性、可靠性。文獻 [13,14]中著重從測控平臺的功能需求對系統結構進行模塊化劃分,使計算節點之間具有較高程度的耦合,相鄰兩層之間在對外服務上具有依賴性。相比而言本文利用基于構件技術的可靠性設計方法,其結構是松散分布式的,具有部署靈活、通信方便、擴展性強等優點。該模型不僅適用于航天測控平臺系統,同時也適用于溫度、分布式等測控系統,適用性廣。
[1]JIN Ping,ZHANG Xiaochun.Airborne software reliability design based on DO-178B [J].Software,2012,33 (6):44-47(in Chinese).[金平,章曉春.基于DO-178B的機載軟件可靠性設計 [J].軟件,2012,33 (6):44-47.]
[2]CHEN Jianwei.Research of four-tier design method of software reliability [J].Industry and Mine Automation,2010,36(11):80-83 (in Chinese).[陳建偉.四級階梯式軟件可靠性設計方法研究 [J].工礦自動化,2010,36 (11):80-83.]
[3]SU Shaoliang,YAN Jianguo,LYongyin.A modularized software design for UAV navigation system based on DSP [J].Electronic Design Engineering,2013,21 (16):79-82 (in Chinese).[蘇少良,閆建國,呂永銀.某無人機導航控制系統模塊化設計 [J].電子設計工程,2013,21 (16):79-82.]
[4]SHAN Jinhui,XU Kejun,WANG Ji.A kind of software faults diagnosing framework [J].Chinese Journal of Computers,2011,34 (2):372-373 (in Chinese). [單錦輝,徐克俊,王戟.一種軟件故障診斷過程框架 [J].計算機學報,2011,34 (2):372-373.]
[5]Martin L,Schatalov M,Hagner M,et al.A methodology for model-based development and automated verification of software for aerospace systems [C]//Aerospace Conference.IEEE,2013:1-19.
[6]Long E A,Gullo L,Nikora A P.Applying software reliability growth models to DOD systems[C]//IEEE 23rd International Symposium on Software Reliability Engineering Workshops,2012:27-36.
[7]SHANG Huiping,JIA Ying,ZHENG Huiying.Design and implementation of high availability SCC system platform [J].Journal of Spacecraft TT&C Technology,2010,29 (1):17-21 (in Chinese).[尚慧萍,賈穎,鄭慧英.衛星控制中心系統平臺的高可用設計與實現[J].飛行器測控學報,2010,29 (1):17-21.]
[8]Wu J.Stress testing software to determine fault tolerance for hardware failure and anomalies [C]//IEEE Autotestcon,2012:294-298.
[9]Zhang Y,Guan Y,Wang G.Analysis and comparison of fault simulation [C]//International Symposium on Intelligent Ubiquitous Computing and Education.IEEE,2009:503-506.
[10]ZHANG Hongcan,XUE Wei.Reliability analysis of cluster RAID5storage system [J].Journal of Computer Research and Development,2010,47 (4):727-735 (in Chinese).[章宏燦,薛巍.集群RAID5存儲系統可靠性分析 [J].計算機研究與發展,2010,47 (4):727-735.]
[11]WU Dong,GAO Jiaqiong.The research and deployment failover clustering technology [J].Information & Communications,2013,27 (5):25-25 (in Chinese). [巫 冬,高加瓊.故障轉移群集技術研究與部署 [J].信息通信,2013,27 (5):25-25.]
[12]LIU Chang,WANG Yirong.The software architecture design of measurement and control system in vacuum thermal tests [J].Spacecraft Environment Engineering,2010,27 (3):324-327(in Chinese).[劉暢,王奕榮.真空熱試驗測控軟件系統架構設計[J].航天器環境工程,2010,27 (3):324-327.]
[13]XU Yingxue,CHEN Jinming,WANG Yirong.The software platform for analysis,test and evaluation of spacecraft vacuum thermal environment adaptability [J].Spacecraft Environment Engineering,2013,30 (4):370-374 (in Chinese).[徐英學,陳金明,王奕榮.航天器真空熱環境適應性試驗分析及評價軟件平臺 [J].航天器環境工程,2013,30 (4):370-374.]