硬件板卡测试系统设计与实现

李倩，张立鹏，张奕男

在信号系统中,为了确保地铁或国铁现场中各系统的正常运行,首先要保证硬件板卡本身的功能正常,因此板卡生产厂商需对硬件板卡在出厂前进行充分的测试,以确保硬件的各个接口,如网口、串口、CAN口、定时器等能够满足设计及现场的需要［1］,减少出厂板卡的故障率,即在出厂前保证硬件板卡的功能可靠稳定。基于此,为了更加方便地对核心的硬件板卡进行大规模的测试,需要设计一套功能齐全、安全稳定、便捷简单的自动化硬件板卡测试系统,用于保障硬件板卡的生产质量［2-3］；同时对从板卡生产厂商采购的所有板卡进行抽样检查与验收。

1 测试系统设计

硬件板卡测试系统由硬件环境、上位机软件与下位机软件3部分组成。

1）硬件环境包括机柜、机笼、板卡、交换机、电源、工控机等,待测设备通常为机柜,可以同时测试1套或多套设备,1套设备可配插1块或多块板卡（取决于硬件机柜的结构）,这是硬件板卡测试系统的基础。以VLE（中心处理运算板）测试为例,其机笼槽道硬件配置见表1。机笼中设置A、B双系,每系中有VLE板卡、VPS（安全电源板）板卡及其他板卡。每系VLE板卡上有2个CPU,简称为上模块和下模块,各模块中分别设有4个串口、2个CAN口 和2个网 口,A、B系VLE板卡的各硬件接口通过配线通信。A系VLE上模块串口1～4与B系VLE上模块串口1～4配线连接；A、B系各个网口独立配线,连接至交换机；A系VLE上 模 块CAN1和CAN2与B系VLE上模块CAN1和CAN2配线连接,VLE下模块各接口配线方式相同。只有确保硬件中的板卡、配线等都连接正确,才能保证测试的准确性与可靠性。

表1 机笼槽道硬件配置

2）上位机软件基于Windows平台下的.NET,使用C#语言开发［4］,使用spring.net框架进行XML配置［5］,将测试软件安装到工控机上,通过交换机与通信板卡进行网络通信,将下位机发出的板卡各接口的测试信息快速采集后存储在本地［6］,并显示到界面上警示用户,最终确定各板卡是否通过测试。

3）下位机软件基于VxWorks操作系统,使用C语言开发［7］,编译的软件镜像（Image）通过网线直接烧录到通信板卡的Flash中（VLE的上、下2个模块分别与交换机连接）。下位机软件的主要功能是通过特定数据的发送与接收,对硬件板卡上的各个接口按照最高性能指标进行接口功能测试［8］,并将根据自定义通信协议组包生成的测试数据,通过网络发送给上位机软件进行处理。

2 软件架构

整体设计上,测试系统的软件架构分为表示层、业务层和数据访问层3层,如图1所示,目的是实现高内聚、低耦合,增强硬件板卡测试系统的可重用性与扩展性。

图1 测试系统软件架构

表示层:以Windows窗体的形式展现,在窗体中显示测试机笼的结构图,实时显示软件运行过程中各测试板卡的报警或故障信息。用户可通过表示层操控测试系统。

业务层:对数据相关业务的逻辑处理,业务层处理接收和发送的所有数据,根据通信协议进行组包和不同类型的消息分发与解析。

数据访问层:接收和发送基于网络通信的原始数据。

功能结构上,测试系统软件可分为网络通信模块、测试预设模块、命令发送模块、数据采集模块、数据解析模块、界面显示及警告模块和报告生成模块。各个功能模块之间需要有关联性和时序性,以正确地执行软件功能,满足软件功能需求。测试系统软件处理流程见图2。

图2 测试系统软件处理流程

2.1 网络通信模块

由于硬件板卡测试系统对时效性要求较高,为了提高信息传输的灵活性和时效性,选择UDP协议（User Datagram Protocol,用户数据报协议）进行网络通信［9］。

上位机软件与下位机软件之间的协议约定见图3。

图3 帧协议格式

帧头（0x5A）与帧尾（0xA5）是用于区分是否是本测试系统报文的固定字节,各占1个字节。

版本用于定义协议的版本号,当协议升级时,版本变更。

应用消息长度定义此字段（不包含）后面的所有报文的字节总数,考虑到每包消息的最长字节数,定义为2个字节。

周期号（CycleNo）用于区分下位机周期性发送报文的计数值,占4个字节。

类型（MsgType）用于区分不同类型的报文消息,占1个字节。

子类型用于区分同一类型不同分组的报文消息,占1个字节。

数据长度表示后面填充的应用数据所占的字节总数,占2个字节。

本系统中所有类型报文消息均小于1 000个字节,故未考虑分包与组包。

为了防止消息丢包,保证消息接收的可靠性与完整性,上位机软件采用异步回调函数接收网络消息,下位机软件采用select模式非阻塞方式接收消息,为业务层处理数据提供基础和保障。

2.2 测试预设模块

本模块是开始正式测试前的预设配置,通过与用户交互方式实现。界面中设有测试人、测试时长、板卡序列号的编辑框,待有数据键入后,系统将测试人员姓名或工号、测试时长（精确到分）、待测板卡的序列号记录到内存中。在上述3个条件编辑框中内容均不为空的情况下,才会允许用户启动“开始测试”。

板卡序列号是待测板卡报告及测试记录的唯一标识,支持传统条形序列号及二维码2种格式,可以用扫描枪扫描或手动输入到指定的编辑框中,板卡序列号按照以下机制设计。

1）检测机制。如果检测到当前编码框中的序列号与其他重复或为空,系统弹出警示框。

2）动态创建。由于不同测试中板卡的个数是不同的,因此,本系统根据板卡复选框的点选情况,采用动态创建文本框和编辑框的模式,使测试系统功能更加灵活。

2.3 数据采集模块

监听线程接收到上位机软件发送的开始测试命令后,首先调用驱动函数对机笼中的槽位是否有板卡进行检测,并与上位机发送的板卡槽位检测（拔插）情况进行比对,如果比对不一致,将比对结果通过Send函数发送给上位机软件；如比对一致,下位机会启动采集任务,并对采集数据处理后发给上位机,数据采集流程见图4。

图4 数据采集流程

系统依次对待测板卡上的网口、CAN口、串口等接口进行数据采集与正确性判断。测试方案是A系VLE金板（良品,功能正常的板卡）与B系待测VLE板卡的各个对应接口进行通信。首先,金板调用驱动程序的接口函数发送一包固定长度的随机测试数据,待测板卡收到数据后,先对接收到的数据（不包含发送方计算的CRC校验码）计算CRC校验码,再与发送方计算的CRC校验码进行比对,如果一致,本轮采集是正确无误的,测试次数递增1,如果不一致,错误次数递增1；然后,待测板卡将一包固定长度的随机数据回发,金板收到数据后同样计算CRC并比对,如果一致,本轮采集是正确无误的,测试次数递增1,如果不一致,错误次数递增1。

下位机软件实时将各个待测接口测试的正确次

数与错误次数记录到数据结构中,并以一定的周期（500 ms）通过Send函数发送给上位机软件。

2.4 数据解析模块

本模块对接收到的数据进行处理。以上位机软件为例,如图5所示,监听线程收到报文后,首先会放到消息队列中,数据解析模块会对消息队列进行轮询,如果轮询到数据,便会一次性从消息队列中pop出全部数据。

图5 数据解析

上位机软件根据帧协议针对不同的消息类型（MsgType）进行消息分发,统一用*Response类来解析。不同类型的数据进入到相应的*Response类中进行报文解析,如ShakeRespose类用于解析握手回复消息,BoardStatusResponse类用于解析板卡故障消息,ComponentTestResponse类用于解析接口组件的常规消息等。每个*Response都继承了基类Response,基类中定义了板卡ID、接收时间Dtime、原始数据OriginalData和周期号CycleNo。每种解析都会返回字符串类型的返回值,并且根据解析结果将对应的待测板卡标志位更新为通过或失败。

该解析方法既降低了模块之间的耦合度,也可实现系统的扩展,如果新添加不同类型的网络消息解析,只需要在业务层复写对应类型的Response派生类。

2.5 界面显示及警告模块

本模块用于显示测试指令及必要的警告信息。界面中设置机笼中各板卡的相对槽道简易图,如无报错信息上报,则相应槽道背景色设置为绿色；当对应板卡有报错信息上报时,将相应槽道背景色设置为红色,同时在界面的文本框中显示出具体的故障信息,如故障板卡的名称、槽道号、首次出错时间、故障码等,并同步记录到本地csv格式日志中,方便用户查询。

2.6 报告生成模块

本模块以待测板卡的序列号作为唯一标识生成报告,并上传到服务器,作为待测板卡测试是否通过的重要证据。当系统运行达到预设的测试时间时,会生成报告；当系统的预设测试时间未到,而是用户手动强制停止测试时,不生成报告,本次测试无效,需要重新对本轮测试的所有板卡进行测试。

3 结束语

目前测试系统已应用于板卡生产厂商及公司质量部,通过对信号系统硬件板卡各项硬件接口进行测试,有效地避免了人为测试的繁琐或操作不当引起的测试失误,提高了板卡的测试效率,减少了验收的人力成本；同时该测试系统可对故障板卡进行故障定位,协助分析现场返回问题板卡的硬件故障［10］,从而保障了现场信号系统中各板卡硬件功能的正确性与完整性。