车载分布式ATS动态可配置实现策略研究

申 飞,崔建峰,刘慧丰,冯 亮,李 杰,尤文斌

(1.中北大学 电气与控制工程学院，太原 030051；2.北京特种车辆试验场，北京 100072；3.中国北方车辆研究所，北京 100072)

为准确分析车辆设备的健康状况，需对车辆设备开展全面性的设备综合测试。传统的车辆测试方案采用“分立式”的测试方案，即针对每个具体的被测对象开发专项ATS，以实现车辆在运行过程中不同部位运行工况的反映——比如采用网络化耐高温温度场测试系统实现对动力舱温度分布状态的实时获取[1]；采用应变应力微型在线监测遥测装置实现对车辆关键构件的载荷测试[2-3]；采用分布式加速度传感装置实现对车辆悬架系统振动工况的实时监测[4]等。上述“分立式”方案的主要问题在于：专项ATS功能设计单一，可扩展性差，从而导致车辆ATS开发成本高、系统优化难度大[5]。解决此问题的一个有效途径是采用分布式设计架构[6]。分布式架构采用开放式的通讯网络结构以实现系统的可扩展，通过测试资源的集成与共用以降低系统开发成本。但现有分布式ATS存在以下问题：分布式ATS软件以静态化的方式配置主控单元与各个节点之间的关系。当分布式ATS的测试节点发生变更时，要求重调主控单元程序代码当中的配置参数，从而导致系统配置效率的大幅下降[7]。

为解决分布式系统对节点单元变化的适应能力问题，文献[8]采用软插件技术帮助实现异构数控系统通信协议的动态转换。结合军用车辆底盘系统的测试需求，本文提出一种车载分布式ATS的动态可配置实现策略。该策略以开放式的硬件通讯平台设计为基础，通过对测试资源建模以及在底层配置协议下对数据接收存储映射的动态重建，最终实现分布式ATS的动态可适配。相比于传统分布式ATS静态化的配置思想，本设计将系统配置作为系统动态业务的一部分，业务中由于配置参数动态可变，从而实现系统结构形态在一定范围内柔性可调。

1 设计思想概述

本文提出的车载分布式ATS动态可配置实现策略，基于测试系统“生产者-消费者”的开发模式，在保持实现测试功能所必须的基本环节与业务形态不变的前提下，充分考虑测试前端可变对系统造成的影响，对其进行动态适配性设计。

设计当中，适配目标为在统一电气接口与通讯协议约束设计下的测试前端。整个适配过程在系统上位机与分布式测试管理器的统一协调工作下完成：首先，系统上位机收集并整合当前所有处于连接状态的测试前端的属性信息，建立测试资源模型；其次，系统上位机调用模型数据访问业务对测试资源模型进行访问，根据访问结果分析当前测试任务对底层数据缓冲区的配置需求，生成底层配置协议；最后，分布式测试管理器则根据系统上位机下发的配置协议控制调整缓冲结构，重建其与数据源之间的映射关系，最终实现对测试前端变化的自适应。设计用例简图如图1。

图1 设计用例简图

2 分布式ATS动态可重构设计

2.1 通讯平台设计

为实现硬件通讯平台的动态可重构，本文基于开放式现场总线技术，通过车载CAN通信局域网和分布式测试管理器构建分布式ATS的硬件通讯平台，其系统组成结构框图如图2。

图2 硬件通讯平台结构框图

CAN协议规范定义了OSI开放式互联模型中的物理层、数据链路层以及应用层，使得在保证系统开放可扩展的基础之上简化其组成，提高开发与运行效率。网络总线物理层采用双绞线作为通讯介质，信号以差分电压的形式进行传输[9]。所有测试前端设备与分布式测试管理器通过内部CAN总线彼此互联，构成分布式测试局域网。

分布式测试局域网在一主多从的模式下进行工作，分布式测试管理器作为通讯主节点向局域网内的测试前端设备(从节点)发送广播信息或一对一定向指令，测试前端设备依据指令内容执行对应的操作——包括系统初始化、配置参数修改、运行数据采集、采集数据上传、工作状态上传以及错误信息报告等。

分布式测试管理器由主控模块、通讯模块、存储模块以及外围电路构成。主控模块采用飞思卡尔MC9S12XEP100作为主控芯片，该芯片内置MSCAN通讯模块，可实现CAN2.0A与CAN2.0B两种CAN协议，在进行实际开发时，只需设计外围电路与CAN驱动器即可[10]。系统设计将测试数据以文件的形式保存于FLASH芯片当中，为防止数据掉电丢失，设计在FLASH数据写入之前先将缓冲数据、文件属性信息以及FLASH当前的写入状态信息保存于铁电存储器FRAM当中，从而使得系统能够在重新上电之后快速恢复工作状态。

2.2 测试资源建模

对测试节点信息模型化、结构化的管理方式为系统实现测试资源动态可适配提供了软件层面的可能。设计通过数据字典组织测试节点的属性信息，并建立测试资源模型，建模原理示意图如图3。

图3 测试资源模型示意图

模型当中以测试节点Nodei(1≤i≤n)作为系统测试资源的组织单位：

SysResource={Node1,Node2,…,Noden}

(1)

对于包含其中的每个测试节点，可将其属性通过式(2)进行描述：

Node=(NodeID,FramBytesLenth,TestBusiness)

(2)

其中:NodeID为通讯标识符；FramBytesLenth为该节点所上传的数据帧字节长度；TestBusiness为该测试节点所具有的测试业务。在此以信道代表测试节点上单个信号采集端口的业务实现，每个节点所包含的测试业务可描述为

TestBusiness={Ch1,Ch2,…,Chn}

(3)

模型当中对信道的描述形式为

Channel=(ChID,SigType,CaliModel,ValRange,

ByteLenth,Precision)

(4)

其中:ChID为该信道的标识符；SigType为端口信号类型；CaliModel为该信道测试所得数据的标定方式，在系统上位机当中对应于不同的数据标定业务与相关参数，以实现测试数据的处理与解析适配；ValRange表示该信道的值域范围；ByteLenth为该信道的数据字节长度；Precision代表测试精度。

最终形成的测试资源数据字典通过基于可扩展标记语言的XML文件实现[11]，并由.NET框架下的System.Xml命名空间提供访问支持。

2.3 存储映射的重建

对于分布式测试管理器而言，系统测试节点改变对系统存储配置的影响主要在于原有通讯节点与存储地址之间的映射关系被打破。传统的分布式ATS软件一般采用静态数组实现测试数据的缓冲，数据源与缓冲区之间的映射关系往往是固定不变的，而此种静态配置方式下的映射关系一旦被打破，只能通过线下重写程序代码进行修复。因此，

本设计当中对系统进行动态适配的主要工作将集中于重建通讯节点与数据缓冲区地址之间的映射。

系统上位机根据测试资源模型提供的有效信息长度描述生成底层配置协议，配置协议格式如表1所示。协议当中的测试节点表示CAN测试局域网当中具备测试数据上传业务、并通过CAN通讯ID进行标识的通讯对象；每个测试节点下所包含的配置描述信息包括该节点的通讯ID、该节点所上传的有效信息长度、信道数量以及信道的字长。

表1 通讯协议配置信息

在指定控制命令下，分布式测试管理器通过串口接收系统上位机下发的底层配置协议，接收成功后，分布式测试管理器通过重置缓冲区容量、重建缓冲区地址与通讯节点之间的映射两个步骤实现配置重置。

分布式测试管理器首先读取配置协议中的有效数据总长，然后通过malloc动态内存分配函数在存储堆区(Heap)中开辟相应字节大小的缓存空间，并将其用于数据接收，从而实现数据接收对于数据容量变动的适配。其后，分布式测试管理器读取配置协议中的通讯节点信息，据此建立动态链表以映射动态缓冲区当中的各个节点数据存放的首地址。配置协议与链表节点之间的关系示意图如图4。

图4 配置协议与链表节点关系示意图

链表节点Node(k)通过数据结构COM_NODE实现，其内容按如下方式定义：

typedef struct

{

byte *dataAddr;

unsigned short nodeID;

unsigned short dataLenth;

unsigned short chelCount;

unsigned short chelLenth;

struct COM_NODE *next;

}COM_NODE

其中，*next代表下一个链表节点Node(k+1)的存放地址；nodeID为该链表节点所对应通讯节点的ID标识符；dataLenth为对应通讯节点上传数据帧当中有效数据的总长；chelCount为上传数据帧当中所包含的信道数量；chelLenth为信道的字节长度。基于设计当中所采用的CAN通讯协议，其数据帧最大有效数据长度为8 Byte，设计将信道长度统一定义为2 Byte，则每个通讯节点上传的数据帧当中最多包含4条有效信道。动态缓冲区当中，由通讯节点上传所得的测试数据按链表节点的先后顺序连续分布，如图5所示。

图5 存储缓冲区结构

第k个测试节点于动态缓冲上的映射关系通过对应链表节点Node(k)下的成员dataAddr进行描述，dataAddr的数值按式(5)进行计算：

(5)

式(5)中:buffStartAddr为动态缓冲区的首地址；dataLenthi为基于链表排序，第i个节点的有效数据长度。

3 测试数据的接收与保存

分布式测试管理器通过CAN中断接收由各个测试节点上传的测试结果。当系统从CAN通讯局域网接收数据包信息成功后，从链表头指针Com_Head开始逐个索引链表节点。若被索引链表节点的通讯标识符tempNode->nodeID与CAN报文标识符接收寄存器(CANxIDR0～CANxIDR3)当中的报文标识符信息相匹配，则根据该链表节点下的缓冲区地址映射tempNode->dataAddr进行寻址，存放接收所得的数据帧信息。数据接收流程框图如图6。

系统的采样周期由定时中断的定时时长决定，当定时器中断到达时，系统向缓冲区末端添加时间信道信息构成一个数据采样点，并将之经FRAM向Flash转存。

4 功能验证

为验证该策略的有效性，在实验室环境下搭建了如图7所示的试验验证平台。图中左侧为分布式测试管理器，其内部包含一块搭载高速FLASH存储芯片的存储板卡以收集数据，3块CAN通讯板卡用于模拟测试网络中的通讯节点，每块通讯板卡均以3 ms为周期向CAN通讯网络上传单个通讯地址下的信号采样结果，3块通讯板卡可上传具有60个不同通讯地址(0x01～0x3C)的报文信息。

图7 试验平台

为了对该策略下的配置功能进行充分验证，在验证过程中依据系统配置流程对系统测试资源(在配置功能中表现为测试设备)进行重新配置，并根据所得结果下发底层配置协议，通过查看串口上传的数据内容以判断底层配置功能是否正确执行。

系统于初始状态下共计包含48条测试信道，其中每4地址，所涉及的通讯地址范围为0x01～0x0C。现通过配置功能在原始状态的基础上另行增加新的测试设备，并向其中增加测试信道，配置界面如图8所示。

图8 系统配置界面

通过为新测试设备设定与已有设备相同的通讯协议编号属性以保证通讯协议版本一致。现新增共计48条测试信道，使系统信道总数达到98条。在保证对指定版本通讯协议中通讯地址引用完整性的原则下，为每4条新增信道指定相同的通讯地址，并按其在消息负载当中的先后顺序设置信道的字节号分别为0、2、4、6，以代表信道数据于消息负载字段当中的位置偏移。配置完毕后，系统可处理在0x01～0x18通讯地址范围下的测试数据。

将系统在原始状态下和配置后的状态下从串口所获取的测试结果进行对比，对比结果如图9所示。结果表明：经配置后的系统可成功接收并处理对应通讯节点上传所得的测试数据，即该策略具备工程上的可行性。

图9 配置前后的系统串口数据接收对比

为验证该策略下系统的配置效率，本文统计并对比基于传统的配置操作和基于动态配置策略的配置操作在配置同一测试项目时所消耗的平均时间长度。传统的配置操作过程普遍包含测试装置拆卸、调试装置连接、运行编程环境及编程工具、代码编写、功能的调试验证以及测试装置的重新安装部署等。相比之下，本文所提出的动态配置过程完全是在线进行的，故统计时仅考虑测试人员在熟悉配置操作流程的情况下，通过上位机平台当中配置界面进行实际配置操作所消耗的时间。

所选择的测试项目为底盘总成温度测试，该项目一般包含25～35条测试信道，在保持项目类型不变的前提下取常见值26、32和35对其进行配置测试。基于两种不同的配置操作，对每种常见值下的目标项目分别进行3次配置操作并统计其消耗的平均时间长度。统计结果表明：基于传统配置操作在配置上述数量信道的项目时所消耗的平均时间分别为8.3 h、8.5 h以及8.6 h，而基于动态配置操作所消耗的平均时间分别为1.9 h、2 h以及2.1 h。由此可得，本文所提出的动态配置策略可有效提高分布式ATS的配置效率。

5 结论

本文提出了一种车载分布式ATS系统动态可配置实现策略。该策略通过测试资源建模、配置协议实时下发以及存储映射的动态重建实现了车载分布式ATS的快速配置自适应，解决了传统车载分布式ATS测试任务切换难、功能扩展成本高、无法实现在线动态配置的缺陷。经多次测试结果表明：该策略具有可行性并能有效提升车载测试系统的灵活性与应变能力。