李芍， 馮亮， 張領(lǐng)輝， 李耀偉

(中國北方車輛研究所, 北京 100072)

0 引言

近年來，軟件重構(gòu)技術(shù)、系統(tǒng)故障管理在航空電子系統(tǒng)領(lǐng)域中得到了廣泛的關(guān)注和實際應(yīng)用。王震等[1]描述了航空電子系統(tǒng)中的軟件重構(gòu)流程，并通過一種上下級周期詢問- 應(yīng)答的方式實現(xiàn)了軟件的故障上報；石海洋等[2]對航空電子系統(tǒng)中的系統(tǒng)重構(gòu)方案給出了綜述；劉意等[3]和郭秋麗等[4]則分別針對襟翼控制計算機(jī)中的余度控制和某特定機(jī)載嵌入式系統(tǒng)平臺的動態(tài)重配置管理軟件的服務(wù)端和客戶端進(jìn)行了設(shè)計；黃英蘭等[5]對航空電子系統(tǒng)中的故障管理架構(gòu)進(jìn)行了說明；Han等[6]也在理論上使用Petri網(wǎng)的建模方式研究了綜合模塊化航空電子系統(tǒng)(IMA)中的故障狀態(tài)遷移；在車輛任務(wù)領(lǐng)域，文獻(xiàn)[7]給出了一種多車協(xié)同之間的軟件重構(gòu)方法，處理了多車協(xié)同的故障冗余重構(gòu)問題。軟件重構(gòu)技術(shù)和系統(tǒng)故障管理已實質(zhì)上成為了IMA中的重要組成部分。

在目前的車輛電子系統(tǒng)中，也借鑒IMA的設(shè)計思路，形成了綜合模塊化車輛電子系統(tǒng)(IMV)或分布式綜合模塊化車輛電子系統(tǒng)(DIMV)[8]。在IMA和IMV中，基本的處理單元是綜合核心處理機(jī)(ICP)內(nèi)的處理模塊。從硬件模塊的角度看，IMV核心系統(tǒng)包括一組預(yù)定義的標(biāo)準(zhǔn)化模塊。一種IMV的示意如圖1所示，圖中的核心處理系統(tǒng)包含2個ICP，實際系統(tǒng)中的核心處理機(jī)數(shù)量、處理模塊數(shù)量和類型可以按需配置。

現(xiàn)階段車輛核心處理系統(tǒng)包括的模塊種類有：

圖1 IMV核心處理系統(tǒng)Fig.1 IMV core processing system

1)信息處理模塊，集成了通用處理器和實時操作系統(tǒng)。有些還可集成顯卡，用于驅(qū)動乘載員的顯示界面；

2)信號處理模塊，集成了數(shù)字信號處理器(DSP)和現(xiàn)場可編程門陣列(FPGA)；

3)圖像處理模塊，集成了DSP和FPGA；

4)系統(tǒng)管理模塊，集成通用處理器、實時操作系統(tǒng)和大容量存儲介質(zhì)；

5)電源模塊。

相比于IMA，IMV的主要區(qū)別在于：

1)IMV的計算資源主要用于車輛的任務(wù)系統(tǒng)，包括態(tài)勢、任務(wù)決策、打擊、防護(hù)、效能評估，以及車際的任務(wù)規(guī)劃、任務(wù)流程、任務(wù)評估等，主要使用信息處理模塊；IMA的大部分計算資源則用于本機(jī)雷達(dá)、射頻、光電、導(dǎo)航等信號的處理；

2)IMV承載了車內(nèi)3～6個乘載員的獨立顯示和控制功能，每個乘載員標(biāo)配不少于1個1080p分辨率的交互式顯示屏和多個操控設(shè)備，在人機(jī)交互系統(tǒng)的顯示與控制上相比IMA更為復(fù)雜；

3)IMV的安全性設(shè)計等級較IMA低，現(xiàn)有的IMV并未采用IMA的雙余度、三余度設(shè)計；

4)盡管IMV和IMA都采用了高速統(tǒng)一網(wǎng)絡(luò)互連，但是IMV的交換網(wǎng)絡(luò)承載了多路高清原始視頻的傳輸，這些視頻的帶寬大，對抖動和延時的敏感度高；

5)IMV的散熱環(huán)境更為嚴(yán)苛，IMA多采用風(fēng)冷和液冷循環(huán)的散熱方式，但I(xiàn)MV易受沙塵、鹽霧、振動沖擊等影響，僅能使用導(dǎo)冷的方式，這一特點限制了IMV的規(guī)模，以及其處理平臺的功耗和性能。

此外，IMV中的系統(tǒng)管理模塊可視為存儲空間較大的、執(zhí)行系統(tǒng)管理相關(guān)功能的特殊信息處理模塊，這與IMA中的大容量存儲模塊有本質(zhì)區(qū)別。

本文的研究目的在于，借鑒IMA軟件重構(gòu)的已有研究基礎(chǔ)，針對IMV提出一種分層級的軟件重構(gòu)方法及實現(xiàn)方式，同時創(chuàng)新地改變IMA中使用的詢問- 應(yīng)答監(jiān)控機(jī)制，以大幅減少數(shù)據(jù)通信負(fù)荷，降低對任務(wù)數(shù)據(jù)、視頻數(shù)據(jù)傳輸質(zhì)量的影響。

1 ASAAC標(biāo)準(zhǔn)系統(tǒng)管理架構(gòu)

ASAAC標(biāo)準(zhǔn)[9-11]是聯(lián)合標(biāo)準(zhǔn)航空電子委員會定義并已驗證的一套開放式、綜合化、模塊化的先進(jìn)航空電子體系結(jié)構(gòu)標(biāo)準(zhǔn)。ASAAC標(biāo)準(zhǔn)包括系統(tǒng)架構(gòu)、硬件模塊、通用網(wǎng)絡(luò)、軟件結(jié)構(gòu)、機(jī)械結(jié)構(gòu)、故障管理和安全性等內(nèi)容。

ASAAC標(biāo)準(zhǔn)所定義的系統(tǒng)管理架構(gòu)分為3個層級，分別是飛機(jī)級(AC)、綜合區(qū)域級(IA)以及資源單元級(RE)。這3個層級的關(guān)系如圖2所示。

圖2 ASAAC標(biāo)準(zhǔn)所定義的系統(tǒng)管理架構(gòu)Fig.2 System management architecture defined by ASAAC standard

每個級別的系統(tǒng)管理實體都運行在所對應(yīng)的3層處理器中，這3層分別是硬件支持層、操作系統(tǒng)層和應(yīng)用層，如圖3所示。系統(tǒng)管理作為系統(tǒng)配置管理、健康監(jiān)控以及故障診斷等功能的載體，它的組成部分主要包括健康監(jiān)控(HM)、故障管理(FM)以及配置管理(CM)；應(yīng)用管理是應(yīng)用軟件或人員與系統(tǒng)管理交互的接口；藍(lán)圖是系統(tǒng)資源及調(diào)度描述、配置與重新配置、行為列表及狀態(tài)機(jī)的描述，是系統(tǒng)管理的策略輸入。

圖3 3層處理器軟件架構(gòu)Fig.3 Three-layer stack processor software architecture

HM、FM和CM 3個部件的功能分別是：

1)HM負(fù)責(zé)監(jiān)控其所在層級(AC、IA或RE)處理單元的運行狀態(tài)，它以主動或被動的方式接收來自應(yīng)用程序、操作系統(tǒng)、硬件、網(wǎng)絡(luò)或下級HM等的運行狀態(tài)，識別這些運行狀態(tài)是否為故障狀態(tài)，并報告給FM. 上下級HM之間通過心跳問詢以及應(yīng)答實現(xiàn)；

2)FM接收HM的故障報告，通過故障識別、隔離、運行自身或下級的自檢測試等一系列手段，努力將故障所帶來的危害降至最小。FM通過藍(lán)圖配置決定故障是在本地解決，或者報告給更高層的HM；

3)CM管理系統(tǒng)的配置，包括系統(tǒng)起動、配置與重配置以及系統(tǒng)關(guān)閉。在故障處理中，CM接收FM的故障處理結(jié)果，向故障所在的處理單元(本級或下級)發(fā)送重構(gòu)請求。

HM、FM、CM之間的信息流和接口如圖4所示。

圖4 故障管理信息流和接口Fig.4 Information flow and interface of fault management

由圖4可見，ASAAC標(biāo)準(zhǔn)中的系統(tǒng)管理是一套較為完備且復(fù)雜的系統(tǒng)。在地面裝備中，由于關(guān)乎成員安全的車輛控制、武器控制和防護(hù)控制在各自的實時子系統(tǒng)中，核心處理機(jī)的功能域主要是任務(wù)系統(tǒng)、管理系統(tǒng)和顯控系統(tǒng)，其實時性較低；其次，車輛核心處理機(jī)的故障模式大部分是由于沖擊、振動等因素導(dǎo)致的網(wǎng)絡(luò)通訊異常，目前尚無由于任務(wù)模式改變而重新配置系統(tǒng)的需求。因此，本文考慮地面裝備中的一種針對軟件重構(gòu)機(jī)制的實現(xiàn)方案，重點關(guān)注軟件自身的錯誤退出以及網(wǎng)絡(luò)通信異常的故障模式，并采用模塊間的異步通信以減少多模塊IMV中的通信負(fù)荷。

2 IMV管理架構(gòu)

IMV管理架構(gòu)如圖5所示，將ASAAC標(biāo)準(zhǔn)的3層管理架構(gòu)簡化為2層，分別是系統(tǒng)管理模塊和信息處理模塊，系統(tǒng)管理模塊和信息處理模塊的處理單元也運行了3層軟件架構(gòu)。在應(yīng)用層，系統(tǒng)管理模塊或信息處理模塊運行系統(tǒng)管理軟件。在本文中，默認(rèn)系統(tǒng)管理軟件運行于系統(tǒng)管理模塊中。在信息處理模塊運行模塊管理軟件。管理模塊是一組封裝了通信管理、操作系統(tǒng)進(jìn)程管理等接口的軟件中間件類庫和函數(shù)庫，系統(tǒng)管理的實體是系統(tǒng)管理軟件和模塊管理軟件。

圖5 IMV管理架構(gòu)Fig.5 IMV system management architecture

在此基礎(chǔ)上，將藍(lán)圖文件設(shè)計成一組多個模塊共享的配置文件，這些配置文件規(guī)范了模塊號、軟件號、軟件的部署、故障重構(gòu)序列等信息，這些信息在所有處理模塊上保持一致。

在IMV部署時，可以事先在每個信息處理模塊中部署系統(tǒng)中所有的軟件和藍(lán)圖配置文件，以便在發(fā)生故障重構(gòu)時，不必臨時加載軟件的可執(zhí)行文件，可以加快系統(tǒng)重構(gòu)的速度。

2.1 系統(tǒng)模塊藍(lán)圖配置

系統(tǒng)模塊配置文件可定義系統(tǒng)中包含哪些模塊，以及這些模塊號、名稱、版本日期等。以下給出了一個系統(tǒng)模塊配置文件的簡化方案：

〈?xml version = "1.0" encoding = "utf-8" ?〉

〈system_modules〉

〈module name = "InfoProc"〉

〈id〉2〈/id〉

〈/ module 〉

〈 module name = "InfoProc"〉

〈id〉3〈/id〉

〈/ module 〉

〈 module name = "SysManage"〉

〈id〉1〈/id〉

〈/ module 〉

〈/system_modules〉.

在該配置文件中，定義了2個信息處理模塊，1個系統(tǒng)管理模塊，其中“InfoProc”代表信息處理模塊，“SysManage”代表系統(tǒng)管理模塊，信息處理模塊號為2和3，系統(tǒng)管理模塊號為1. 在該系統(tǒng)配置中，同類別處理模塊的設(shè)備名稱相同，這是因為相同類別的模塊在功能、性能和接口上對外并無區(qū)分的必要，僅需通過設(shè)備號在特定的IMV中進(jìn)行唯一的標(biāo)識，該設(shè)備號數(shù)值的確定可以由物理地址、網(wǎng)絡(luò)地址、軟件分配，或交換式任務(wù)網(wǎng)絡(luò)系統(tǒng)中的端口號進(jìn)行對應(yīng)。圖6給出了一個按端口號進(jìn)行設(shè)備號區(qū)分的系統(tǒng)示例。

圖6 車載交換網(wǎng)絡(luò)系統(tǒng)構(gòu)成Fig.6 Composition of vehicle switching network system

由于交換網(wǎng)絡(luò)一般含有交換機(jī)或路由器，當(dāng)設(shè)備接入交換機(jī)時，交換機(jī)或路由器給設(shè)備分配的網(wǎng)絡(luò)地址可以與接入的端口號一一對應(yīng)，當(dāng)模塊的應(yīng)用軟件正常運行后，可以讀取自身的網(wǎng)絡(luò)地址確定接入的端口號，借助這一特點，可以將設(shè)備號直接定義為交換機(jī)端口號(若系統(tǒng)中存在多個交換機(jī)，則可以使用特定的地址分配順序或交換機(jī)設(shè)備號和端口號的組合方式進(jìn)行標(biāo)識)。需要注意的是，該方法的前提是必須嚴(yán)格規(guī)劃每類模塊的端口范圍，例如1端口固定給系統(tǒng)管理模塊使用，2～6端口固定給信息處理模塊使用等，該方法允許任一信息處理模塊在2～6之間的端口進(jìn)行互換，但不允許信息處理模塊接入其他端口。

為了得到更大的通用性，例如允許信息處理模塊接入任意一個交換端口，則需要犧牲其他方面的性能，例如：一種方式是在每個信息處理模塊的內(nèi)部固定一個模塊號，但是這種方法可能會導(dǎo)致安裝過程中弄混而裝入同樣模塊號的模塊；另一種方法是采用更為靈活的模塊號分配策略，例如上電后所有的信息處理模塊向系統(tǒng)管理上報自身的模塊類別，隨后由系統(tǒng)管理動態(tài)地分配各模塊的系統(tǒng)唯一模塊號，但是該方法在系統(tǒng)管理功能失效、通信故障的時候可能會導(dǎo)致失效，復(fù)雜度較高而可靠性較低。

2.2 軟件藍(lán)圖配置

軟件藍(lán)圖配置的作用是定義每個處理模塊在默認(rèn)條件下運行的軟件集合，以及這些軟件在故障后的重構(gòu)處理方式，本文將軟件重構(gòu)的處理方式簡化為重新起動，使用如下簡化的軟件藍(lán)圖配置文件：

〈?xml version = "1.0" encoding = "utf-8" ?〉

〈system_softwares〉

〈software name = "Comp1"〉

〈module〉

〈default〉2〈/default〉

〈reconfig〉3/4/5〈/ reconfig〉

〈/module〉

〈/software〉

〈software name = "Comp2"〉

〈 module 〉

〈default〉3〈/default〉

〈reconfig〉5/4〈/reconfig〉

〈/module〉

〈/software〉

〈/system_softwares〉.

在該配置文件中共定義了2個軟件，其中software name 代表軟件名稱字符串，module標(biāo)簽定義了該軟件運行的模塊標(biāo)識信息，其中default的值表示默認(rèn)條件下(例如上電后)該軟件運行的模塊號，reconfig的值表示該軟件發(fā)生故障后的遷移重構(gòu)的模塊號序列，以“/”符號分隔?？梢妌ame為Comp1的軟件初始運行在模塊號為2的模塊中，若發(fā)生故障后則遷移到模塊3，遷移后若再次故障則遷移到模塊4，再到模塊5，以此類推。在該文件中，隱式的表達(dá)了應(yīng)用軟件號的概念，即第1個軟件(Comp1)的軟件號為1，第2個軟件(Comp2)的軟件號為2，軟件號可以配合軟件的名稱使用。

2.3 管理模塊

從應(yīng)用的角度看，管理模塊定義了一組應(yīng)用程序接口，其主要包括HM、FM和CM 3類：

1)HM包括獲取模塊的運行狀態(tài)，包括軟件運行狀態(tài)、網(wǎng)絡(luò)狀態(tài)兩類。其中軟件運行狀態(tài)包括模塊當(dāng)前運行的軟件列表等，網(wǎng)絡(luò)狀態(tài)包括獲取當(dāng)前模塊是否在線，以及獲取網(wǎng)絡(luò)中所有信息處理模塊、系統(tǒng)管理模塊是否在線等。系統(tǒng)管理模塊的HM還需要負(fù)責(zé)異步地獲取信息處理模塊HM上報的軟件運行信息，在ASAAC系統(tǒng)中，該信息是同步獲取的；

2)FM用于識別當(dāng)前模塊軟件運行的故障，其判斷輸入包括軟件是否重復(fù)運行，軟件運行狀態(tài)是否發(fā)生改變，以及系統(tǒng)中的所有信息處理模塊、系統(tǒng)管理模塊是否在線等；

3)CM包括軟件配置和網(wǎng)絡(luò)配置，軟件的配置包括軟件起動和退出，網(wǎng)絡(luò)配置包括初始化、銷毀網(wǎng)絡(luò)設(shè)備、接入網(wǎng)絡(luò)、退出網(wǎng)絡(luò)等。系統(tǒng)管理模塊的CM還需要負(fù)責(zé)向信息處理模塊的CM發(fā)送軟件起動、退出命令。

3 系統(tǒng)管理軟件設(shè)計

系統(tǒng)管理軟件需要輸入的信息有：

1)系統(tǒng)網(wǎng)絡(luò)狀態(tài)，包括所有(信息)處理模塊以及自身的網(wǎng)絡(luò)連接狀態(tài)，這部分信息由系統(tǒng)管理模塊的HM提供；

2)各個信息模塊的運行軟件信息，即在信息處理模塊上運行的應(yīng)用軟件號集合，該信息由各個模塊管理軟件輸入。

系統(tǒng)管理軟件輸出的信息有向模塊管理軟件輸出的軟件起動或退出控制信息，該信息包含軟件號和信息處理模塊的模塊號。系統(tǒng)管理軟件可以采用消息驅(qū)動的模式進(jìn)行設(shè)計，其核心的邏輯包括初始化模塊、退出模塊、消息生成模塊、運行信息處理模塊、系統(tǒng)檢測處理模塊和信息發(fā)送模塊部分，這些模塊如圖7所示。

圖7 系統(tǒng)管理軟件的模塊劃分Fig.7 Components of system management software

下面對這6個軟件模塊分別進(jìn)行描述：

1)初始化模塊。初始化模塊完成藍(lán)圖配置文件的讀取，交換網(wǎng)絡(luò)的初始化和配置，模塊運行軟件信息表(見表1)及其他的內(nèi)部數(shù)據(jù)結(jié)構(gòu)初始化。系統(tǒng)管理軟件可以運行在兩種模式下：一種是強(qiáng)管理模式，即在初始化過程中將軟件藍(lán)圖配置文件中的構(gòu)件部署信息視為所有模塊管理軟件的首次上報信息；一種是弱管理模式，將模塊運行軟件信息表初始化為空。強(qiáng)管理模式適合于系統(tǒng)已經(jīng)較為穩(wěn)定且所有軟件的運行可靠性較高的狀態(tài)，此時系統(tǒng)軟件重構(gòu)的功能優(yōu)先級很高。而弱管理模式則更適合于系統(tǒng)軟件重構(gòu)的功能作為輔助性系統(tǒng)功能，或系統(tǒng)的功能存在裁剪的系統(tǒng)(例如部分系統(tǒng)不工作)。

表1 模塊運行軟件信息表Tab.1 Module applications in running list

2)消息生成模塊。消息生成模塊的消息來源包括網(wǎng)絡(luò)接收到的數(shù)據(jù)、內(nèi)部定時器或其他外部事件產(chǎn)生的消息。

網(wǎng)絡(luò)接收到的數(shù)據(jù)來源于模塊管理軟件，該數(shù)據(jù)包含模塊號以及模塊當(dāng)前運行的所有軟件號集合，為了節(jié)約消息空間同時使用固定的消息長度，可以將軟件號映射為一個長數(shù)據(jù)的比特位序號，以特定序號為比特0表示不包含該軟件號的軟件，以比特1表示包含該軟件號的軟件，例如二進(jìn)制數(shù)0000000001001000可代表該模塊運行了軟件號為3和6的軟件。

定時器產(chǎn)生的系統(tǒng)檢測消息用于系統(tǒng)管理軟件的自身檢測，檢測的對象包括任務(wù)網(wǎng)絡(luò)中是否有信息處理模塊斷網(wǎng)，以及待發(fā)送的軟件重構(gòu)命令隊列、待確認(rèn)的軟件重構(gòu)隊列是否為空。

事件消息用于模塊運行過程中的外部事件，例如自身斷網(wǎng)產(chǎn)生的中斷、其他軟件發(fā)送的系統(tǒng)管理軟件退出事件等。

消息生成模塊將輸入的信息進(jìn)行格式化處理，輸出運行軟件信息、系統(tǒng)檢測信息或退出信息。

3)運行信息處理模塊。當(dāng)收到消息生成模塊發(fā)來的運行軟件信息后，運行信息處理模塊開始工作，它將運行軟件信息更新并記錄在本地的模塊運行軟件信息表(見表1)中。假定上一狀態(tài)下模塊號為2的信息處理模塊運行的軟件號為3、5、6，當(dāng)前接收到模塊號為2的信息處理模塊發(fā)來的運行軟件信息為01001000(即軟件號為3、6)。

可見，相較于收到信息前一時刻的值，新接收到的運行軟件信息不包括軟件號為5的軟件，此時認(rèn)定軟件號為5的軟件需要進(jìn)行遷移重構(gòu)，運行信息處理模塊將判斷當(dāng)前記錄的所有模塊運行軟件信息表是否包含軟件號為5的軟件，若均不存在，則將軟件號為5寫入待發(fā)送的軟件重構(gòu)命令隊列中；倘若發(fā)現(xiàn)同一個軟件號的軟件運行在多個模塊中，則選擇上一次上報已運行該軟件號的信息處理模塊，并向它發(fā)送軟件退出命令。

4)系統(tǒng)檢測處理模塊。當(dāng)收到消息生成模塊發(fā)來的系統(tǒng)檢測信息后，系統(tǒng)檢測處理模塊開始工作，首先確保自身模塊對外的通信正常，隨后逐一檢測系統(tǒng)中所有的信息處理模塊是否處于正常上網(wǎng)的狀態(tài)，系統(tǒng)檢測處理模塊為每個信息處理模塊設(shè)定一個不在網(wǎng)次數(shù)的閾值，若連續(xù)檢測到同一個模塊的不在網(wǎng)次數(shù)大于此閾值，則認(rèn)為該模塊整體失效；若認(rèn)定該模塊整體失效，則讀取該模塊的模塊運行軟件信息表(見表1)，將該模塊運行的軟件全部寫入待發(fā)送的軟件重構(gòu)命令隊列中。

5)信息發(fā)送模塊。系統(tǒng)檢測處理模塊完成后，將待發(fā)送的軟件重構(gòu)命令隊列及待確認(rèn)的軟件重構(gòu)隊列共享給信息發(fā)送模塊，該模塊首先會從待發(fā)送的軟件重構(gòu)命令隊列中取出(指獲得隊列頭的元素并將隊列的頭元素刪去)一個軟件號，若未檢測到該軟件的運行信息(查詢所有模塊運行軟件信息表)，則通過藍(lán)圖配置查找該軟件下一個可重構(gòu)的信息處理模塊的模塊號(若找到，則隱含該模塊網(wǎng)絡(luò)在線)。若成功找到，則發(fā)送軟件起動命令給該信息處理模塊，并將該軟件號及其對應(yīng)的信息處理模塊的模塊號插入到待確認(rèn)的軟件重構(gòu)隊列中；否則將該軟件號重新插入待發(fā)送的軟件重構(gòu)命令隊列末尾。

為了避免信息發(fā)送過程中可能的失敗，信息發(fā)送模塊還將從待確認(rèn)的軟件重構(gòu)隊列中取出一個軟件號和其對應(yīng)的信息處理模塊的模塊號，若未檢測到該軟件的運行信息(查詢所有模塊運行軟件信息表)，則需要再次發(fā)送軟件起動命令給該信息處理模塊，同時將軟件號和其對應(yīng)的信息處理模塊的模塊號重新插入待確認(rèn)的軟件重構(gòu)命令隊列末尾；若該信息處理模塊不在線，則將該軟件號重新插入待發(fā)送的軟件重構(gòu)命令隊列中。

6)退出模塊。退出模塊將會釋放系統(tǒng)管理軟件的所有資源，并且關(guān)閉本機(jī)的對外通信網(wǎng)絡(luò)，退出模塊一般在系統(tǒng)關(guān)閉、網(wǎng)絡(luò)多次失效的條件下才會被進(jìn)入。

通過這一設(shè)計，系統(tǒng)管理軟件的消息收發(fā)是異步的，首先它不需要模塊管理軟件的心跳信息上報，而是通過調(diào)用HM的網(wǎng)絡(luò)狀態(tài)獲取監(jiān)控各個模塊的運行狀態(tài)確定其是否存在故障；其次，系統(tǒng)管理軟件每次發(fā)送軟件的起動或退出命令后，不需要等待模塊管理軟件的成功與失敗反饋，而是在下一次收到信息處理模塊的軟件狀態(tài)上報后再更新其對應(yīng)的運行軟件信息表。

4 模塊管理軟件設(shè)計

模塊管理軟件需要輸入的信息有：

1)系統(tǒng)網(wǎng)絡(luò)狀態(tài)，包括系統(tǒng)管理模塊以及自身的網(wǎng)絡(luò)連接狀態(tài)，這部分信息由HM提供；

2)當(dāng)前模塊已運行的軟件信息，該信息通過HM接口獲知；

3)當(dāng)前模塊運行的應(yīng)用軟件心跳信息，該信息用于輔助判斷應(yīng)用軟件的運行狀態(tài)，但是需要應(yīng)用軟件支持(可選)。

模塊管理軟件輸出的信息有向系統(tǒng)管理軟件上報的運行軟件信息。

模塊管理軟件可以采用消息驅(qū)動的模式進(jìn)行設(shè)計，其核心的邏輯包括初始化模塊、退出模塊、消息生成模塊、軟件管理模塊、模塊軟件檢測和信息發(fā)送模塊部分，這些模塊間的接口如圖8所示。

圖8 模塊管理軟件的模塊劃分Fig.8 Components of module management software

下面對這6個軟件模塊分別進(jìn)行描述：

1)初始化模塊。初始化模塊完成藍(lán)圖配置文件的讀取，交換網(wǎng)絡(luò)的初始化和配置，按照藍(lán)圖配置文件運行本機(jī)模塊的應(yīng)用構(gòu)件，初始化內(nèi)部數(shù)據(jù)結(jié)構(gòu)等工作。

2)消息生成模塊。該模塊的消息來源包括網(wǎng)絡(luò)接收到的軟件管理信息、內(nèi)部定時器或外部事件產(chǎn)生的消息。網(wǎng)絡(luò)接收到的信息來源于系統(tǒng)管理軟件，該信息包含模塊號、軟件號以及起動或退出命令；定時器產(chǎn)生的模塊軟件檢測消息用于模塊管理軟件的自身檢測，檢測的對象包括網(wǎng)絡(luò)中系統(tǒng)管理模塊或自身是否斷網(wǎng)，本機(jī)運行的軟件狀態(tài)等；事件消息用于模塊運行過程中的外部事件，例如自身斷網(wǎng)產(chǎn)生的事件等；消息生成模塊將輸入的信息進(jìn)行格式化處理，輸出軟件管理信息、模塊軟件檢測信息或退出信息。

3)軟件管理模塊。當(dāng)收到消息生成模塊發(fā)來的軟件起動命令后，解析出軟件號，軟件管理模塊將檢測本地是否已運行該軟件號的應(yīng)用軟件，若未運行，則起動該軟件；當(dāng)收到消息生成模塊發(fā)來的軟件退出命令后，解析出軟件號，軟件管理模塊將檢測本地是否已運行該軟件號的應(yīng)用軟件，若已運行，則退出該軟件。

4)系統(tǒng)檢測處理模塊。當(dāng)收到消息生成模塊發(fā)來的模塊軟件檢測信息后，系統(tǒng)檢測處理模塊首先確保自身對外的通信正常，系統(tǒng)檢測處理模塊為自身設(shè)定一個不在網(wǎng)次數(shù)的閾值，若連續(xù)檢測到自身的不在網(wǎng)次數(shù)大于此閾值，則認(rèn)為自身模塊失效，模塊管理軟件可重起或關(guān)閉本模塊的電源；若自身模塊未斷網(wǎng)，則讀取模塊自身的應(yīng)用軟件列表，形成本次模塊運行軟件信息表(見表1)；若不允許軟件的重復(fù)運行，還將需要對重復(fù)運行的軟件進(jìn)行清理；若檢測到系統(tǒng)管理模塊不在線，則不進(jìn)入信息發(fā)送模塊，模塊管理軟件比對本次模塊運行軟件信息表的內(nèi)容和上一次檢測模塊得到的運行軟件信息表的內(nèi)容，若存在構(gòu)件缺失，則在本地重起該應(yīng)用并更新模塊運行軟件信息表。

5)信息發(fā)送模塊。若自身模塊未斷網(wǎng)且系統(tǒng)管理模塊未斷網(wǎng)時，信息發(fā)送模塊發(fā)送兩類信息；一類是事件信息，信息發(fā)送模塊將比對當(dāng)前模塊運行軟件信息表和上一次檢測模塊得到的運行軟件信息表，若二者不同，則將運行軟件信息發(fā)送給系統(tǒng)管理軟件；另一類是長周期信息(周期可設(shè)置為5s或以上，與通信故障的偶發(fā)程度相關(guān))，將運行軟件信息表通過任務(wù)網(wǎng)絡(luò)發(fā)送給系統(tǒng)管理軟件，該消息是為了應(yīng)對偶發(fā)的通信故障，保證第一類消息即使發(fā)送失敗，系統(tǒng)管理模塊也可以在一定時間內(nèi)收到上報的運行軟件信息。

6)退出模塊。退出模塊將會釋放模塊管理軟件的所有資源，并且關(guān)閉本機(jī)的對外通信網(wǎng)絡(luò)，退出模塊一般在系統(tǒng)關(guān)閉、網(wǎng)絡(luò)多次故障的條件下才會被進(jìn)入。

可見，通過這一設(shè)計，模塊管理軟件的消息收發(fā)也是異步的，它不需要及時向系統(tǒng)管理軟件反饋軟件起動或退出的結(jié)果信息。

5 方案分析與試驗驗證

5.1 管理模塊風(fēng)險與對策分析

本文提出的軟件重構(gòu)方案中，面臨的風(fēng)險主要包括：

1)運行過程中的網(wǎng)絡(luò)失效。信息處理模塊或系統(tǒng)管理模塊可能在運行過程中無法持續(xù)接入交換網(wǎng)絡(luò)，或由于網(wǎng)絡(luò)錯誤、丟包等因素導(dǎo)致偶發(fā)性的通信失效。

2)模塊運行過程中失效。信息處理模塊或系統(tǒng)管理模塊自身的供電、硬件、操作系統(tǒng)或應(yīng)用軟件出現(xiàn)異常而導(dǎo)致了模塊重起、或模塊關(guān)閉。

為了解決這些問題，本文提出的系統(tǒng)管理方案所依賴的前提條件包括：

1)軟件配置文件和系統(tǒng)配置文件正確。如果配置文件錯誤，則可能出現(xiàn)多個模塊同時運行相同應(yīng)用軟件的故障情形，該條件可以通過配置文件的程序自動化檢查和出入庫審查等外部手段解決。

2)系統(tǒng)中所有軟件的運行具備完備性。由于系統(tǒng)管理軟件可運行在強(qiáng)管理或弱管理模式下，在弱管理模式下，系統(tǒng)管理軟件不保證初始狀態(tài)下已運行軟件的數(shù)量和軟件號能完全覆蓋配置文件中的軟件，系統(tǒng)管理軟件的軟件狀態(tài)輸入完全依賴于各個信息處理模塊的運行軟件信息，系統(tǒng)軟件的完備性檢測由各模塊負(fù)責(zé)；在強(qiáng)管理模式下，系統(tǒng)管理軟件將會盡可能保證藍(lán)圖中所有軟件的運行。

3)上電起動后的有限時間內(nèi)系統(tǒng)可正常運行。在弱管理模式下，需要保證系統(tǒng)管理軟件、各應(yīng)用軟件及各模塊管理軟件以及任務(wù)網(wǎng)絡(luò)在上電起動后的一段時間內(nèi)運行正常(例如：1 min以內(nèi))，在此期間可以確保模塊管理軟件至少向系統(tǒng)管理軟件上報一次運行的軟件信息。

有了這3個前提，本文提出的遷移重構(gòu)方案總能在一定程度上解決運行過程中的網(wǎng)絡(luò)失效或模塊運行過程中失效的問題。由于系統(tǒng)管理軟件總能接收到各個模塊初始發(fā)送的正常運行軟件信息(由前提條件3保證)，因此可以建立起完備的運行軟件信息列表，若后續(xù)出現(xiàn)網(wǎng)絡(luò)運行異常，假定某個信息處理模塊上報的運行軟件信息丟失多次，但只要有一次能夠正確地接收，系統(tǒng)管理軟件就能夠捕捉到需要重構(gòu)的軟件號；即使系統(tǒng)管理模塊發(fā)送的軟件起動命令多次未能正確接收，但只要未被系統(tǒng)管理軟件的系統(tǒng)檢測處理模塊確認(rèn)，該軟件號的起動命令將會被重復(fù)發(fā)送，直至重構(gòu)目標(biāo)信息處理模塊上報的運行軟件信息中包含了該軟件號。

此外，若某一個信息處理模塊在運行過程中失效，由于系統(tǒng)管理軟件的系統(tǒng)檢測處理模塊存在連續(xù)不在線次數(shù)的閾值檢測策略，會將該處理模塊中的所有應(yīng)用軟件遷移到其他處理模塊中，若該模塊在失效后熱重起成功，系統(tǒng)管理軟件仍能夠正確識別它，并且能將其納入整個系統(tǒng)的應(yīng)用軟件管理中。

若系統(tǒng)管理模塊失效，信息處理模塊中的模塊管理軟件將自動采用應(yīng)用軟件失效后原地重起的策略，系統(tǒng)進(jìn)入降級模式。

5.2 與IMA的詢問/應(yīng)答機(jī)制對比分析

假定IMA/IMV各具有N個信息處理模塊和1個系統(tǒng)管理模塊，取軟件重構(gòu)過程從軟件故障退出到軟件重新起動的時間不大于1 s的指標(biāo)，其中IMA采用周期問詢/應(yīng)答的方式，設(shè)每個信息處理模塊的上報周期設(shè)置為500 ms(為信息雙向傳輸、系統(tǒng)管理模塊決策以及軟件重新加載預(yù)留500 ms)；IMV采用本文所述的軟件重構(gòu)方法，模塊管理軟件將以500 ms時間周期檢測自身的軟件運行情況。

假設(shè)IMA/IMV中的第k個(k=1,2,…,N)信息處理模塊運行的軟件數(shù)量為sk，軟件總數(shù)為S，每個軟件500 ms內(nèi)發(fā)生故障的概率為p：

1)IMA消息數(shù)量計算。在500 ms內(nèi)，信息處理模塊與系統(tǒng)管理模塊在問詢/應(yīng)答中交互的消息數(shù)量為2N，在此期間平均發(fā)生pS個軟件故障，在最壞情況下，系統(tǒng)管理模塊還需要額外發(fā)送pS次軟件重構(gòu)消息(假設(shè)重構(gòu)的目的地都不同)。因此，總共發(fā)送的消息數(shù)量在2N～2N+pS之間。

一般而言，車載加固計算機(jī)軟硬件系統(tǒng)的平均失效間隔時間(MTBF)指標(biāo)不小于104h數(shù)量級，IMV的總軟件數(shù)量不超過103數(shù)量級，因此3pS的數(shù)值很小，可見，相對于IMA現(xiàn)有的詢問/應(yīng)答方式，本文提出的方案大幅減少了信息處理模塊與系統(tǒng)管理模塊間消息交互的數(shù)量。

5.3 試驗結(jié)果

該方案在Windows 7 64位操作系統(tǒng)上進(jìn)行了實現(xiàn)，采用1臺計算機(jī)作為系統(tǒng)管理模塊，2臺計算機(jī)作為信息處理模塊，模擬了2個信息處理模塊(模塊號為1、 2)，1個系統(tǒng)管理模塊的IMV，共計4個軟件，軟件藍(lán)圖配置如下：

〈?xml version = "1.0" encoding = "utf-8" ?〉

〈system_softwares〉

〈software name = "Comp1"〉

〈module〉

〈default〉1〈/default〉

〈reconfig〉2/1〈/reconfig〉

〈/module〉

〈/software〉

〈software name = "Comp2"〉

〈module〉

〈default〉1〈/default〉

〈reconfig〉1/2〈/ reconfig 〉

〈/module〉

〈/software〉

〈software name = "Comp3"〉

〈module〉

〈default〉2〈/default〉

〈reconfig〉1/2〈/ reconfig 〉

〈/module〉

〈/software〉

〈software name = "Comp4"〉

〈module〉

〈default〉2〈/default〉

〈reconfig〉2/1〈/ reconfig 〉

〈/module〉

〈/software〉

〈/system_softwares〉.

涵蓋的測試用例包括：

1)一般條件下的軟件重構(gòu)測試(見圖9)；

2)軟件重構(gòu)過程中出現(xiàn)偶發(fā)性斷網(wǎng)故障(見圖10)。

其他異常狀況下的測試用例還包括：

1)多個信息處理模塊重復(fù)運行同一個軟件；

2)信息處理模塊意外地運行了某一個未計劃的軟件；

3)信息處理模塊的通信線纜斷開；

4)信息處理模塊的通信線纜斷開，一段時間后再次插入；

5)系統(tǒng)管理模塊的通信線纜斷開；

6)系統(tǒng)管理模塊的通信線纜斷開，一段時間后再次插入；

7)交換網(wǎng)絡(luò)斷電，一段時間后再次上電。

一般條件下的軟件重構(gòu)測試時序圖如圖9所示，其表述的是信息處理模塊1中的軟件1發(fā)生重構(gòu)的過程。在該流程中，系統(tǒng)管理軟件采用弱管理模式，該流程第1部分是模塊號為1及模塊號為2的信息處理模塊的模塊管理軟件向系統(tǒng)管理軟件上報運行軟件信息；當(dāng)模塊號為1的信息處理模塊的軟件1發(fā)生軟件重構(gòu)后，上報系統(tǒng)管理軟件重構(gòu)的軟件信息，隨后系統(tǒng)管理軟件根據(jù)既定的藍(lán)圖在模塊號為2的信息處理模塊中起動該軟件。

圖9 軟件1的重構(gòu)時序圖Fig.9 Sequence chart of software reconfiguration (ID=1)

圖10 模塊2偶發(fā)斷網(wǎng)時軟件1的重構(gòu)時序圖Fig.10 Sequence chart of software reconfiguraton (ID=1) with temporary network failure of Model 2

軟件重構(gòu)過程中出現(xiàn)偶發(fā)性斷網(wǎng)故障的時序圖如圖10所示，在系統(tǒng)管理軟件決策信息模塊號為2的信息處理模塊失效前，將會多次發(fā)送軟件起動命令，直到模塊號為2的信息處理模塊上報的運行軟件信息中包含該軟件。

其余測試用例的時序圖本文不再贅述，這些測試中的系統(tǒng)管理軟件和模塊管理軟件可以正常應(yīng)對，未出現(xiàn)軟件運行丟失的狀態(tài)，該方案已進(jìn)一步在車輛電子系統(tǒng)嵌入式環(huán)境中進(jìn)行測試。

6 結(jié)論

本文對ASAAC標(biāo)準(zhǔn)中的系統(tǒng)管理、故障處理機(jī)制進(jìn)行了深入的研究，結(jié)合系統(tǒng)管理技術(shù)和車輛電子系統(tǒng)的特點，提出了一種基于異步通信的面向IMV應(yīng)用軟件的重構(gòu)方案。得出以下主要結(jié)論：

1)相比于基于同步通信的IMA軟件重構(gòu)技術(shù)，采用異步通信的IMV軟件重構(gòu)方案大幅減少了管理所需的通信負(fù)荷。

2)IMV軟件重構(gòu)方案可以有效應(yīng)對模塊失效、任務(wù)網(wǎng)絡(luò)失效、通信故障等問題，完成可靠的系統(tǒng)軟件遷移重構(gòu)。

本文工作為IMV的系統(tǒng)整體設(shè)計提供了一個可選的軟件重構(gòu)方案，受限于當(dāng)前研究條件，該方案在桌面和實驗室嵌入式條件下完成了測試，下一步的工作重點是將該方案在車輛IMV中進(jìn)行集成，測試車輛應(yīng)用軟件在嚴(yán)苛環(huán)境中的重構(gòu)能力。