基于异步通信的综合模块化车辆电子系统软件重构

李芍， 冯亮， 张领辉， 李耀伟

(中国北方车辆研究所, 北京 100072)

0 引言

近年来，软件重构技术、系统故障管理在航空电子系统领域中得到了广泛的关注和实际应用。王震等[1]描述了航空电子系统中的软件重构流程，并通过一种上下级周期询问- 应答的方式实现了软件的故障上报；石海洋等[2]对航空电子系统中的系统重构方案给出了综述；刘意等[3]和郭秋丽等[4]则分别针对襟翼控制计算机中的余度控制和某特定机载嵌入式系统平台的动态重配置管理软件的服务端和客户端进行了设计；黄英兰等[5]对航空电子系统中的故障管理架构进行了说明；Han等[6]也在理论上使用Petri网的建模方式研究了综合模块化航空电子系统(IMA)中的故障状态迁移；在车辆任务领域，文献[7]给出了一种多车协同之间的软件重构方法，处理了多车协同的故障冗余重构问题。软件重构技术和系统故障管理已实质上成为了IMA中的重要组成部分。

在目前的车辆电子系统中，也借鉴IMA的设计思路，形成了综合模块化车辆电子系统(IMV)或分布式综合模块化车辆电子系统(DIMV)[8]。在IMA和IMV中，基本的处理单元是综合核心处理机(ICP)内的处理模块。从硬件模块的角度看，IMV核心系统包括一组预定义的标准化模块。一种IMV的示意如图1所示，图中的核心处理系统包含2个ICP，实际系统中的核心处理机数量、处理模块数量和类型可以按需配置。

现阶段车辆核心处理系统包括的模块种类有：

图1 IMV核心处理系统Fig.1 IMV core processing system

1)信息处理模块，集成了通用处理器和实时操作系统。有些还可集成显卡，用于驱动乘载员的显示界面；

2)信号处理模块，集成了数字信号处理器(DSP)和现场可编程门阵列(FPGA)；

3)图像处理模块，集成了DSP和FPGA；

4)系统管理模块，集成通用处理器、实时操作系统和大容量存储介质；

5)电源模块。

相比于IMA，IMV的主要区别在于：

1)IMV的计算资源主要用于车辆的任务系统，包括态势、任务决策、打击、防护、效能评估，以及车际的任务规划、任务流程、任务评估等，主要使用信息处理模块；IMA的大部分计算资源则用于本机雷达、射频、光电、导航等信号的处理；

2)IMV承载了车内3～6个乘载员的独立显示和控制功能，每个乘载员标配不少于1个1080p分辨率的交互式显示屏和多个操控设备，在人机交互系统的显示与控制上相比IMA更为复杂；

3)IMV的安全性设计等级较IMA低，现有的IMV并未采用IMA的双余度、三余度设计；

4)尽管IMV和IMA都采用了高速统一网络互连，但是IMV的交换网络承载了多路高清原始视频的传输，这些视频的带宽大，对抖动和延时的敏感度高；

5)IMV的散热环境更为严苛，IMA多采用风冷和液冷循环的散热方式，但IMV易受沙尘、盐雾、振动冲击等影响，仅能使用导冷的方式，这一特点限制了IMV的规模，以及其处理平台的功耗和性能。

此外，IMV中的系统管理模块可视为存储空间较大的、执行系统管理相关功能的特殊信息处理模块，这与IMA中的大容量存储模块有本质区别。

本文的研究目的在于，借鉴IMA软件重构的已有研究基础，针对IMV提出一种分层级的软件重构方法及实现方式，同时创新地改变IMA中使用的询问- 应答监控机制，以大幅减少数据通信负荷，降低对任务数据、视频数据传输质量的影响。

1 ASAAC标准系统管理架构

ASAAC标准[9-11]是联合标准航空电子委员会定义并已验证的一套开放式、综合化、模块化的先进航空电子体系结构标准。ASAAC标准包括系统架构、硬件模块、通用网络、软件结构、机械结构、故障管理和安全性等内容。

ASAAC标准所定义的系统管理架构分为3个层级，分别是飞机级(AC)、综合区域级(IA)以及资源单元级(RE)。这3个层级的关系如图2所示。

图2 ASAAC标准所定义的系统管理架构Fig.2 System management architecture defined by ASAAC standard

每个级别的系统管理实体都运行在所对应的3层处理器中，这3层分别是硬件支持层、操作系统层和应用层，如图3所示。系统管理作为系统配置管理、健康监控以及故障诊断等功能的载体，它的组成部分主要包括健康监控(HM)、故障管理(FM)以及配置管理(CM)；应用管理是应用软件或人员与系统管理交互的接口；蓝图是系统资源及调度描述、配置与重新配置、行为列表及状态机的描述，是系统管理的策略输入。

图3 3层处理器软件架构Fig.3 Three-layer stack processor software architecture

HM、FM和CM 3个部件的功能分别是：

1)HM负责监控其所在层级(AC、IA或RE)处理单元的运行状态，它以主动或被动的方式接收来自应用程序、操作系统、硬件、网络或下级HM等的运行状态，识别这些运行状态是否为故障状态，并报告给FM. 上下级HM之间通过心跳问询以及应答实现；

2)FM接收HM的故障报告，通过故障识别、隔离、运行自身或下级的自检测试等一系列手段，努力将故障所带来的危害降至最小。FM通过蓝图配置决定故障是在本地解决，或者报告给更高层的HM；

3)CM管理系统的配置，包括系统起动、配置与重配置以及系统关闭。在故障处理中，CM接收FM的故障处理结果，向故障所在的处理单元(本级或下级)发送重构请求。

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

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

由图4可见，ASAAC标准中的系统管理是一套较为完备且复杂的系统。在地面装备中，由于关乎成员安全的车辆控制、武器控制和防护控制在各自的实时子系统中，核心处理机的功能域主要是任务系统、管理系统和显控系统，其实时性较低；其次，车辆核心处理机的故障模式大部分是由于冲击、振动等因素导致的网络通讯异常，目前尚无由于任务模式改变而重新配置系统的需求。因此，本文考虑地面装备中的一种针对软件重构机制的实现方案，重点关注软件自身的错误退出以及网络通信异常的故障模式，并采用模块间的异步通信以减少多模块IMV中的通信负荷。

2 IMV管理架构

IMV管理架构如图5所示，将ASAAC标准的3层管理架构简化为2层，分别是系统管理模块和信息处理模块，系统管理模块和信息处理模块的处理单元也运行了3层软件架构。在应用层，系统管理模块或信息处理模块运行系统管理软件。在本文中，默认系统管理软件运行于系统管理模块中。在信息处理模块运行模块管理软件。管理模块是一组封装了通信管理、操作系统进程管理等接口的软件中间件类库和函数库，系统管理的实体是系统管理软件和模块管理软件。

图5 IMV管理架构Fig.5 IMV system management architecture

在此基础上，将蓝图文件设计成一组多个模块共享的配置文件，这些配置文件规范了模块号、软件号、软件的部署、故障重构序列等信息，这些信息在所有处理模块上保持一致。

在IMV部署时，可以事先在每个信息处理模块中部署系统中所有的软件和蓝图配置文件，以便在发生故障重构时，不必临时加载软件的可执行文件，可以加快系统重构的速度。

2.1 系统模块蓝图配置

系统模块配置文件可定义系统中包含哪些模块，以及这些模块号、名称、版本日期等。以下给出了一个系统模块配置文件的简化方案：

〈?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个系统管理模块，其中“InfoProc”代表信息处理模块，“SysManage”代表系统管理模块，信息处理模块号为2和3，系统管理模块号为1. 在该系统配置中，同类别处理模块的设备名称相同，这是因为相同类别的模块在功能、性能和接口上对外并无区分的必要，仅需通过设备号在特定的IMV中进行唯一的标识，该设备号数值的确定可以由物理地址、网络地址、软件分配，或交换式任务网络系统中的端口号进行对应。图6给出了一个按端口号进行设备号区分的系统示例。

图6 车载交换网络系统构成Fig.6 Composition of vehicle switching network system

由于交换网络一般含有交换机或路由器，当设备接入交换机时，交换机或路由器给设备分配的网络地址可以与接入的端口号一一对应，当模块的应用软件正常运行后，可以读取自身的网络地址确定接入的端口号，借助这一特点，可以将设备号直接定义为交换机端口号(若系统中存在多个交换机，则可以使用特定的地址分配顺序或交换机设备号和端口号的组合方式进行标识)。需要注意的是，该方法的前提是必须严格规划每类模块的端口范围，例如1端口固定给系统管理模块使用，2～6端口固定给信息处理模块使用等，该方法允许任一信息处理模块在2～6之间的端口进行互换，但不允许信息处理模块接入其他端口。

为了得到更大的通用性，例如允许信息处理模块接入任意一个交换端口，则需要牺牲其他方面的性能，例如：一种方式是在每个信息处理模块的内部固定一个模块号，但是这种方法可能会导致安装过程中弄混而装入同样模块号的模块；另一种方法是采用更为灵活的模块号分配策略，例如上电后所有的信息处理模块向系统管理上报自身的模块类别，随后由系统管理动态地分配各模块的系统唯一模块号，但是该方法在系统管理功能失效、通信故障的时候可能会导致失效，复杂度较高而可靠性较低。

2.2 软件蓝图配置

软件蓝图配置的作用是定义每个处理模块在默认条件下运行的软件集合，以及这些软件在故障后的重构处理方式，本文将软件重构的处理方式简化为重新起动，使用如下简化的软件蓝图配置文件：

〈?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标签定义了该软件运行的模块标识信息，其中default的值表示默认条件下(例如上电后)该软件运行的模块号，reconfig的值表示该软件发生故障后的迁移重构的模块号序列，以“/”符号分隔。可见name为Comp1的软件初始运行在模块号为2的模块中，若发生故障后则迁移到模块3，迁移后若再次故障则迁移到模块4，再到模块5，以此类推。在该文件中，隐式的表达了应用软件号的概念，即第1个软件(Comp1)的软件号为1，第2个软件(Comp2)的软件号为2，软件号可以配合软件的名称使用。

2.3 管理模块

从应用的角度看，管理模块定义了一组应用程序接口，其主要包括HM、FM和CM 3类：

1)HM包括获取模块的运行状态，包括软件运行状态、网络状态两类。其中软件运行状态包括模块当前运行的软件列表等，网络状态包括获取当前模块是否在线，以及获取网络中所有信息处理模块、系统管理模块是否在线等。系统管理模块的HM还需要负责异步地获取信息处理模块HM上报的软件运行信息，在ASAAC系统中，该信息是同步获取的；

2)FM用于识别当前模块软件运行的故障，其判断输入包括软件是否重复运行，软件运行状态是否发生改变，以及系统中的所有信息处理模块、系统管理模块是否在线等；

3)CM包括软件配置和网络配置，软件的配置包括软件起动和退出，网络配置包括初始化、销毁网络设备、接入网络、退出网络等。系统管理模块的CM还需要负责向信息处理模块的CM发送软件起动、退出命令。

3 系统管理软件设计

系统管理软件需要输入的信息有：

1)系统网络状态，包括所有(信息)处理模块以及自身的网络连接状态，这部分信息由系统管理模块的HM提供；

2)各个信息模块的运行软件信息，即在信息处理模块上运行的应用软件号集合，该信息由各个模块管理软件输入。

系统管理软件输出的信息有向模块管理软件输出的软件起动或退出控制信息，该信息包含软件号和信息处理模块的模块号。系统管理软件可以采用消息驱动的模式进行设计，其核心的逻辑包括初始化模块、退出模块、消息生成模块、运行信息处理模块、系统检测处理模块和信息发送模块部分，这些模块如图7所示。

图7 系统管理软件的模块划分Fig.7 Components of system management software

下面对这6个软件模块分别进行描述：

1)初始化模块。初始化模块完成蓝图配置文件的读取，交换网络的初始化和配置，模块运行软件信息表(见表1)及其他的内部数据结构初始化。系统管理软件可以运行在两种模式下：一种是强管理模式，即在初始化过程中将软件蓝图配置文件中的构件部署信息视为所有模块管理软件的首次上报信息；一种是弱管理模式，将模块运行软件信息表初始化为空。强管理模式适合于系统已经较为稳定且所有软件的运行可靠性较高的状态，此时系统软件重构的功能优先级很高。而弱管理模式则更适合于系统软件重构的功能作为辅助性系统功能，或系统的功能存在裁剪的系统(例如部分系统不工作)。

表1 模块运行软件信息表Tab.1 Module applications in running list

2)消息生成模块。消息生成模块的消息来源包括网络接收到的数据、内部定时器或其他外部事件产生的消息。

网络接收到的数据来源于模块管理软件，该数据包含模块号以及模块当前运行的所有软件号集合，为了节约消息空间同时使用固定的消息长度，可以将软件号映射为一个长数据的比特位序号，以特定序号为比特0表示不包含该软件号的软件，以比特1表示包含该软件号的软件，例如二进制数0000000001001000可代表该模块运行了软件号为3和6的软件。

定时器产生的系统检测消息用于系统管理软件的自身检测，检测的对象包括任务网络中是否有信息处理模块断网，以及待发送的软件重构命令队列、待确认的软件重构队列是否为空。

事件消息用于模块运行过程中的外部事件，例如自身断网产生的中断、其他软件发送的系统管理软件退出事件等。

消息生成模块将输入的信息进行格式化处理，输出运行软件信息、系统检测信息或退出信息。

3)运行信息处理模块。当收到消息生成模块发来的运行软件信息后，运行信息处理模块开始工作，它将运行软件信息更新并记录在本地的模块运行软件信息表(见表1)中。假定上一状态下模块号为2的信息处理模块运行的软件号为3、5、6，当前接收到模块号为2的信息处理模块发来的运行软件信息为01001000(即软件号为3、6)。

可见，相较于收到信息前一时刻的值，新接收到的运行软件信息不包括软件号为5的软件，此时认定软件号为5的软件需要进行迁移重构，运行信息处理模块将判断当前记录的所有模块运行软件信息表是否包含软件号为5的软件，若均不存在，则将软件号为5写入待发送的软件重构命令队列中；倘若发现同一个软件号的软件运行在多个模块中，则选择上一次上报已运行该软件号的信息处理模块，并向它发送软件退出命令。

4)系统检测处理模块。当收到消息生成模块发来的系统检测信息后，系统检测处理模块开始工作，首先确保自身模块对外的通信正常，随后逐一检测系统中所有的信息处理模块是否处于正常上网的状态，系统检测处理模块为每个信息处理模块设定一个不在网次数的阈值，若连续检测到同一个模块的不在网次数大于此阈值，则认为该模块整体失效；若认定该模块整体失效，则读取该模块的模块运行软件信息表(见表1)，将该模块运行的软件全部写入待发送的软件重构命令队列中。

5)信息发送模块。系统检测处理模块完成后，将待发送的软件重构命令队列及待确认的软件重构队列共享给信息发送模块，该模块首先会从待发送的软件重构命令队列中取出(指获得队列头的元素并将队列的头元素删去)一个软件号，若未检测到该软件的运行信息(查询所有模块运行软件信息表)，则通过蓝图配置查找该软件下一个可重构的信息处理模块的模块号(若找到，则隐含该模块网络在线)。若成功找到，则发送软件起动命令给该信息处理模块，并将该软件号及其对应的信息处理模块的模块号插入到待确认的软件重构队列中；否则将该软件号重新插入待发送的软件重构命令队列末尾。

为了避免信息发送过程中可能的失败，信息发送模块还将从待确认的软件重构队列中取出一个软件号和其对应的信息处理模块的模块号，若未检测到该软件的运行信息(查询所有模块运行软件信息表)，则需要再次发送软件起动命令给该信息处理模块，同时将软件号和其对应的信息处理模块的模块号重新插入待确认的软件重构命令队列末尾；若该信息处理模块不在线，则将该软件号重新插入待发送的软件重构命令队列中。

6)退出模块。退出模块将会释放系统管理软件的所有资源，并且关闭本机的对外通信网络，退出模块一般在系统关闭、网络多次失效的条件下才会被进入。

通过这一设计，系统管理软件的消息收发是异步的，首先它不需要模块管理软件的心跳信息上报，而是通过调用HM的网络状态获取监控各个模块的运行状态确定其是否存在故障；其次，系统管理软件每次发送软件的起动或退出命令后，不需要等待模块管理软件的成功与失败反馈，而是在下一次收到信息处理模块的软件状态上报后再更新其对应的运行软件信息表。

4 模块管理软件设计

模块管理软件需要输入的信息有：

1)系统网络状态，包括系统管理模块以及自身的网络连接状态，这部分信息由HM提供；

2)当前模块已运行的软件信息，该信息通过HM接口获知；

3)当前模块运行的应用软件心跳信息，该信息用于辅助判断应用软件的运行状态，但是需要应用软件支持(可选)。

模块管理软件输出的信息有向系统管理软件上报的运行软件信息。

模块管理软件可以采用消息驱动的模式进行设计，其核心的逻辑包括初始化模块、退出模块、消息生成模块、软件管理模块、模块软件检测和信息发送模块部分，这些模块间的接口如图8所示。

图8 模块管理软件的模块划分Fig.8 Components of module management software

下面对这6个软件模块分别进行描述：

1)初始化模块。初始化模块完成蓝图配置文件的读取，交换网络的初始化和配置，按照蓝图配置文件运行本机模块的应用构件，初始化内部数据结构等工作。

2)消息生成模块。该模块的消息来源包括网络接收到的软件管理信息、内部定时器或外部事件产生的消息。网络接收到的信息来源于系统管理软件，该信息包含模块号、软件号以及起动或退出命令；定时器产生的模块软件检测消息用于模块管理软件的自身检测，检测的对象包括网络中系统管理模块或自身是否断网，本机运行的软件状态等；事件消息用于模块运行过程中的外部事件，例如自身断网产生的事件等；消息生成模块将输入的信息进行格式化处理，输出软件管理信息、模块软件检测信息或退出信息。

3)软件管理模块。当收到消息生成模块发来的软件起动命令后，解析出软件号，软件管理模块将检测本地是否已运行该软件号的应用软件，若未运行，则起动该软件；当收到消息生成模块发来的软件退出命令后，解析出软件号，软件管理模块将检测本地是否已运行该软件号的应用软件，若已运行，则退出该软件。

4)系统检测处理模块。当收到消息生成模块发来的模块软件检测信息后，系统检测处理模块首先确保自身对外的通信正常，系统检测处理模块为自身设定一个不在网次数的阈值，若连续检测到自身的不在网次数大于此阈值，则认为自身模块失效，模块管理软件可重起或关闭本模块的电源；若自身模块未断网，则读取模块自身的应用软件列表，形成本次模块运行软件信息表(见表1)；若不允许软件的重复运行，还将需要对重复运行的软件进行清理；若检测到系统管理模块不在线，则不进入信息发送模块，模块管理软件比对本次模块运行软件信息表的内容和上一次检测模块得到的运行软件信息表的内容，若存在构件缺失，则在本地重起该应用并更新模块运行软件信息表。

5)信息发送模块。若自身模块未断网且系统管理模块未断网时，信息发送模块发送两类信息；一类是事件信息，信息发送模块将比对当前模块运行软件信息表和上一次检测模块得到的运行软件信息表，若二者不同，则将运行软件信息发送给系统管理软件；另一类是长周期信息(周期可设置为5s或以上，与通信故障的偶发程度相关)，将运行软件信息表通过任务网络发送给系统管理软件，该消息是为了应对偶发的通信故障，保证第一类消息即使发送失败，系统管理模块也可以在一定时间内收到上报的运行软件信息。

6)退出模块。退出模块将会释放模块管理软件的所有资源，并且关闭本机的对外通信网络，退出模块一般在系统关闭、网络多次故障的条件下才会被进入。

可见，通过这一设计，模块管理软件的消息收发也是异步的，它不需要及时向系统管理软件反馈软件起动或退出的结果信息。

5 方案分析与试验验证

5.1 管理模块风险与对策分析

本文提出的软件重构方案中，面临的风险主要包括：

1)运行过程中的网络失效。信息处理模块或系统管理模块可能在运行过程中无法持续接入交换网络，或由于网络错误、丢包等因素导致偶发性的通信失效。

2)模块运行过程中失效。信息处理模块或系统管理模块自身的供电、硬件、操作系统或应用软件出现异常而导致了模块重起、或模块关闭。

为了解决这些问题，本文提出的系统管理方案所依赖的前提条件包括：

1)软件配置文件和系统配置文件正确。如果配置文件错误，则可能出现多个模块同时运行相同应用软件的故障情形，该条件可以通过配置文件的程序自动化检查和出入库审查等外部手段解决。

2)系统中所有软件的运行具备完备性。由于系统管理软件可运行在强管理或弱管理模式下，在弱管理模式下，系统管理软件不保证初始状态下已运行软件的数量和软件号能完全覆盖配置文件中的软件，系统管理软件的软件状态输入完全依赖于各个信息处理模块的运行软件信息，系统软件的完备性检测由各模块负责；在强管理模式下，系统管理软件将会尽可能保证蓝图中所有软件的运行。

3)上电起动后的有限时间内系统可正常运行。在弱管理模式下，需要保证系统管理软件、各应用软件及各模块管理软件以及任务网络在上电起动后的一段时间内运行正常(例如：1 min以内)，在此期间可以确保模块管理软件至少向系统管理软件上报一次运行的软件信息。

有了这3个前提，本文提出的迁移重构方案总能在一定程度上解决运行过程中的网络失效或模块运行过程中失效的问题。由于系统管理软件总能接收到各个模块初始发送的正常运行软件信息(由前提条件3保证)，因此可以建立起完备的运行软件信息列表，若后续出现网络运行异常，假定某个信息处理模块上报的运行软件信息丢失多次，但只要有一次能够正确地接收，系统管理软件就能够捕捉到需要重构的软件号；即使系统管理模块发送的软件起动命令多次未能正确接收，但只要未被系统管理软件的系统检测处理模块确认，该软件号的起动命令将会被重复发送，直至重构目标信息处理模块上报的运行软件信息中包含了该软件号。

此外，若某一个信息处理模块在运行过程中失效，由于系统管理软件的系统检测处理模块存在连续不在线次数的阈值检测策略，会将该处理模块中的所有应用软件迁移到其他处理模块中，若该模块在失效后热重起成功，系统管理软件仍能够正确识别它，并且能将其纳入整个系统的应用软件管理中。

若系统管理模块失效，信息处理模块中的模块管理软件将自动采用应用软件失效后原地重起的策略，系统进入降级模式。

5.2 与IMA的询问/应答机制对比分析

假定IMA/IMV各具有N个信息处理模块和1个系统管理模块，取软件重构过程从软件故障退出到软件重新起动的时间不大于1 s的指标，其中IMA采用周期问询/应答的方式，设每个信息处理模块的上报周期设置为500 ms(为信息双向传输、系统管理模块决策以及软件重新加载预留500 ms)；IMV采用本文所述的软件重构方法，模块管理软件将以500 ms时间周期检测自身的软件运行情况。

假设IMA/IMV中的第k个(k=1,2,…,N)信息处理模块运行的软件数量为sk，软件总数为S，每个软件500 ms内发生故障的概率为p：

1)IMA消息数量计算。在500 ms内，信息处理模块与系统管理模块在问询/应答中交互的消息数量为2N，在此期间平均发生pS个软件故障，在最坏情况下，系统管理模块还需要额外发送pS次软件重构消息(假设重构的目的地都不同)。因此，总共发送的消息数量在2N～2N+pS之间。

一般而言，车载加固计算机软硬件系统的平均失效间隔时间(MTBF)指标不小于104h数量级，IMV的总软件数量不超过103数量级，因此3pS的数值很小，可见，相对于IMA现有的询问/应答方式，本文提出的方案大幅减少了信息处理模块与系统管理模块间消息交互的数量。

5.3 试验结果

该方案在Windows 7 64位操作系统上进行了实现，采用1台计算机作为系统管理模块，2台计算机作为信息处理模块，模拟了2个信息处理模块(模块号为1、 2)，1个系统管理模块的IMV，共计4个软件，软件蓝图配置如下：

〈?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)一般条件下的软件重构测试(见图9)；

2)软件重构过程中出现偶发性断网故障(见图10)。

其他异常状况下的测试用例还包括：

1)多个信息处理模块重复运行同一个软件；

2)信息处理模块意外地运行了某一个未计划的软件；

3)信息处理模块的通信线缆断开；

4)信息处理模块的通信线缆断开，一段时间后再次插入；

5)系统管理模块的通信线缆断开；

6)系统管理模块的通信线缆断开，一段时间后再次插入；

7)交换网络断电，一段时间后再次上电。

一般条件下的软件重构测试时序图如图9所示，其表述的是信息处理模块1中的软件1发生重构的过程。在该流程中，系统管理软件采用弱管理模式，该流程第1部分是模块号为1及模块号为2的信息处理模块的模块管理软件向系统管理软件上报运行软件信息；当模块号为1的信息处理模块的软件1发生软件重构后，上报系统管理软件重构的软件信息，随后系统管理软件根据既定的蓝图在模块号为2的信息处理模块中起动该软件。

图9 软件1的重构时序图Fig.9 Sequence chart of software reconfiguration (ID=1)

图10 模块2偶发断网时软件1的重构时序图Fig.10 Sequence chart of software reconfiguraton (ID=1) with temporary network failure of Model 2

软件重构过程中出现偶发性断网故障的时序图如图10所示，在系统管理软件决策信息模块号为2的信息处理模块失效前，将会多次发送软件起动命令，直到模块号为2的信息处理模块上报的运行软件信息中包含该软件。

其余测试用例的时序图本文不再赘述，这些测试中的系统管理软件和模块管理软件可以正常应对，未出现软件运行丢失的状态，该方案已进一步在车辆电子系统嵌入式环境中进行测试。

6 结论

本文对ASAAC标准中的系统管理、故障处理机制进行了深入的研究，结合系统管理技术和车辆电子系统的特点，提出了一种基于异步通信的面向IMV应用软件的重构方案。得出以下主要结论：

1)相比于基于同步通信的IMA软件重构技术，采用异步通信的IMV软件重构方案大幅减少了管理所需的通信负荷。

2)IMV软件重构方案可以有效应对模块失效、任务网络失效、通信故障等问题，完成可靠的系统软件迁移重构。

本文工作为IMV的系统整体设计提供了一个可选的软件重构方案，受限于当前研究条件，该方案在桌面和实验室嵌入式条件下完成了测试，下一步的工作重点是将该方案在车辆IMV中进行集成，测试车辆应用软件在严苛环境中的重构能力。