关于区域控制器底层测试的介绍

01.

硬件测试

1.1 硬件模块化测试

硬件模块化测试一般包含以下三个部分

1）硬件模块通道级测试（HW Bring-up测试）：一般是在硬件第一次生产出来，主要做各硬件模块的通道级测试，譬如，MCU/SoC的最小系统运行是否正常；CAN/以太网通讯的基本功能是否正常；数字开关输入/模拟信号输入是否正常；负载驱动输出是否正常；Camera数据流输入/Display显示功能是否正常等等。

2）硬件模块信号级测试（设计验证）：在各硬件模块满足通道测试的前提下，利用示波器等测试工具，对硬件模块内部的关键信号进行测量，以确认驱动信号是否有振铃产生；SoC电源的上下电时序是否满足需求；Clock时钟波形是否满足spec需求等等。

3）硬件高速信号测试：在智驾域控制器中，部分告诉信号的测试已无法通过示波器的测量波形来评价信号质量的优劣，必须通过相应的一致性（Compliance Test）或者眼图来评价告诉信号质量，例如以太网一致性测试（包括PMA测试，IOP测试），GMSL的一致性测试，LPDDR4/5的眼图测试等等。

1.2 DV/PV测试

在上汽内部，主要参照上汽的SMTC38000001和SMTC38000006，制定产品的DV/PV测试计划，并在OEM认可的的第三方实验室进行相应的DV/PV测试。

根据实际项目的不同DV/PV测试会有不同的Leg图，以上图为列，分6个Leg测试，第一步是环境电气，机械试验，第二步是EMC测试，第三步是寿命测试，第四步是电性能测试，第五步是环境测试，第六个是参考样件，根据不同的项目留不同的good sample。

02.

软件接口测试

2.1 测试方案

创时主要提供的一个基于SOA架构的软件，在上层应用上会提供大量的软件接口。在测试过程中，大量的软件接口就成为测试的一个难点，也是一个重点，如何保证测试的完整性和可靠性，目前采用的方案如下：

第一步：输入

System model（系统模型）：通过客户提供的系统模型（.arxml）知道整个系统在不同的host之间有多少上层RTE接口的Provider和Consumer

Communication description（通讯矩阵描述）：包括比较传统的.dbc， 以太网、SOMEIP、CANFD用.arxml作为通讯矩阵的输入：

Source code：通过Davinci自动生成

第二步：执行

将这些输入全部导入到MotionWise Creator中并执行

第三步：输出

在第三步中会生成一些.c跟.h的文件，这些test code主要用于把这些测试代码集成到上层RTE接口，另外它会生成一些CANOE的.can文件CAPL文件跟xml文件，这样测试的上位机和待测软件的测试代码就已经生成好了。

2.2 测试workflow

接口测试的主要分为两个部分，第一个是输入中模型输入，模型输入主要包含上层SWC之间的通信接口，第二个是通讯矩阵的描述，通讯矩阵描述包含外围的CAN总线跟以太网信号传输到样件中，因此相应会做一个RTE READ测试。

以系统模型输入为例，比如两个SWC之间的测试验证。假设在客户端的两个SWC之间，通过模型识别到左侧的test SWC作为一个provider，右侧的SWC作为consumer，上一步已经生成了一些.C文件跟一些CAPL的或者是.can的一些测试脚本，那么当集成完整个测试链路之后，首先，外部会有Test PC， Test PC现在主要是基于CANoe的以太网的一个UDP的报文进行控制，Test PC会发一些UDP报文，然后通过ETH Stack发送给待测host，待测host通过IP地址跟UDP的port口直接将这条控制报文发送给上层待测的SWC， SWC通过报文内容的PayLoad，会知道现在是想要测试的哪一个接口、想用的测试方法是最大还是最小还是一个典型值，然后待测SWC会将这个数据通过RTE write的方式写入这个接口。写入完成之后，待测SWC会把写入成功的返回值又通过以太网的报文发送，那么我们知道我们其实成功触发的这条测试案例，下一步右侧待测的SWC，会通过主播报文，把它所收到的值通过UDP的主播报文发送到以太网上面，然后通过一个反序列化的操作，去解析是否它跟这个测试触发想要设置的命令跟拿到的命令对比，如果是一致的，那就认为这条测试案例，这个接口在provider端跟consumer端都是测试通过的。

跨HOST的测试也是用同样的方式。比如现在左侧test SWC是一个待测的话，它只是相当于把自己接收到的数据，通过RTE接口，再通过Switch发送到了右端另外一个host上一个待测的SWC，右侧SWC也是会通过UDP的主播报文，把它接收到的数据返回到总线然后回传给test PC，依然是利用一个反序列化的一个动作去解析到底设置的值跟得到的值是否是一致。

如果是对外总线的验证测试，整体的思路是一样的，只是走的链路可能不一样。在测CAN或者是测包括以太网的时候，主要会把外围的真实的CAN的环境接进去，上层待测SWC数据接收方式走真实CAN drv的方式往上层传输，传输到最上层接收端ApCom，然后ApCom会再把这些数据，根据模型把它RTE write到不同的待测SWC中，那么待测SWC也依然会往外发它所接收到值的组播报文，然后test PC通过这些定义好的组播报文的地址跟PayLoad的做一个反序列化，然后把数据进行对比。

03.

系统测试

3.1 CAN通讯测试

CAN通讯测试跟前面类似，根据客户的arxml输入，包括模型跟dbc的输入去识别到它到底有哪些接口，开发相应的CAPL测试脚本，来触发dot所需要接收到的值，发送它的最大最小，然后还会额外关心通讯的报文周期、DLC的长度、不同signal的PayLoad排布方式、mapping的方式。然后把它再整合到整个CANoe工程中，最后通过test module方式，将整个CAN总线的测试结果反馈出来。

有时候会通过串口或者劳特巴赫去检测CAN内部通信，比如说测试过程中对内有需求，如当DLC长度小于定义的时候，它不应该往上传输，这样就要配合劳特巴赫去ApCom，或者CAN Stack里面去看一下这一帧的数据，在这个故障注入的时候，到底有没有往RTE接口上去传。

3.2 FOTA测试

FOTA测试主要分为正向测试和故障注入测试：

正向测试：

1.制作更新包

2.用ICC simulator触发更新

3.用Tcpdump记录板子和外部的通信

4.在串口显示更新成功后，上载板子里的更新软件与所做的更新包进行对比

故障注入测试：

1.制作更新包

2.更改ICC Simulator代码进行故障注入

3.用TCPdump记录板子和外部的通信

4.分析板子是否报告需求描述的错误

3.3 诊断测试

测试方法

1.将用于模拟DID（Data ID），RID（Routine ID）的测试代码以及用来模拟DTC触发的错误注入代码插入到对应的SWC中。DSC作为其中的一个SWC通过RTE接口来收集其他SWC发送过来的诊断相关模拟信号

2.基于ISO-14229的基本诊断服务主要放置DCM（Diagnostic Communication Manager）和DEM（Diagnostic Event Manager）中。这块可以通过DiVa插件在CANoe中进行测试。

3.4 以太网通讯测试

在一些需求里面，有些报文是不走SOMIP服务，可能只是走单纯的UDP或者TCP的一个链路，那么在这个过程中，一样是通过客户的arxml的输入，通过脚本自动生成测试代码；然后使用脚本，注入通过XCP需要观测的一些变量，添加到A2L文件中；第三步通过CAPL触发Eth的package发送去板端，发送的过程中，数据从电脑或CANoe，通过Eth的Switch传送到上层的EthCom，然后再传递SWC接口，SWC接口所收到的数据可以通过XCP的方式观测到，然后在一个测试周期里面把所有的上层RTE接口跟发送UDP报文里面的这些关键的signal进行对比。

3.5 iECU3.1时间同步测试

时间同步主要分为两个域——AGT和EGT， EGT可以认为是板子内部Domain0的一个域， AGT是对外部有GrandMaster的一个域。

EGT域通过TCPdump的方式去抓取域内通讯的PTP报文，然后观察它：比如syn跟follow_up是否是正常成对出现，时间同步报文里面SequenceCounter或者ClockIdetify是否都是满足于预期; 其次会观察Pdelay request跟Response 和Response ACK是否能被正确的交互出来。

AGT测试目前是通过CANoe或者树莓派模拟发送AGT的报文，AGT的报文通过串口或UDP报文把它的时间打印出来，然后将内部的AGT时间域通过串口的信息打印出来，或者通过其他的UDP报文也发送出来，这样可以通过UDP报文之间一个时间的对比的差值，来反映同步上的这个状态误差到底在多少。目前，AGT是可以做到在十毫秒左右，基本上都是可以满足客户的要求。

04.

压力与性能测试

大部分的feature在简单工况下面可以满足测试或者满足需求的，但是如果真的是在一个压力测试环境中，它或多或少会出现一些异常项。因此会做大量的压力跟性能测试快速的检测出软件里面的薄弱环节。

4.1 CAN通讯测试（丢帧）-台架测试方案

CAN 模拟输入：

通过CAPL 脚本模拟发送所有DUT接受报文

SWC：（ApCOM+MW）正常运行

在CANProxy FreeRunning SWC中增加测试代码，通过RTE接口读取所有PDU的EGT时间戳

测试数据将通过以下方式输出：

在线输出：UART接口，以太网接口

离线输出：通过SCP命令

测试结果

基于在线（或者离线所得到的测试数据）

利用自动化分析脚本，导入测试后的数据，得到所有PDU EGT时间戳的差值与数量，通过对应工时计算诸葛输出各个PDU在消费方CANProxy FreeRunning SWC的丢帧率

4.2 CAN通讯丢帧测试 - 测试代码自动生成器

1.识别所有待测接口

解析通讯模型输入文件 Host .arxml（SH or PH）

滤出消费方CANProxy FreeRunning SWC中所有携带EGT时间戳的接口

2.定义测试代码模板

通过手动方式，对某一PDU的EGT时间戳开发测试代码

集成并测试此PDU的丢帧率，验证测试结果是否有效

基于上述有效的测试方法，定义测试代码模板，以推广至所有待测PDU

3.自动生成测试代码

利用Python脚本，将前序识别到的待测PDU接口全部应用至已定义的测试代码模板中

自动生成代码xxx.c文件

4.编译&刷新

在PIE包中集成测试代码，通过Magpie单独编译FreeRunning SWC

将编译所得xxx.bin文件更新至待测样件中

上电后，通过QNX Shell界面观察代码运行情况，确保Xavior正常启动

4.3 CAN通讯丢帧测试 - 测试数据自动解析器

1.获取测试数据

CAN数据

xxx.blf（CANoe）

Etheret数据

xxx.pcap（Wireshark）

xxx.pcap（Tcpdump）

RTE_Read数据

xxx.text

2.自动分析

通过EGT时间戳，对其所有测试数据

使用Python脚本，分别计xxx.pcap and xxx.txt file的实际丢帧率

1.计算得到测试时间长度（End.Time – Start. Time）

2.计算得到该测试时长的理论有效EGT采样点个数

3.计算得到该测试时长的实际有效EGT采样点个数

4.将计算输出带入公式=（1-实际采样点个数/理论采样点个数）%，得到实际丢帧率

3.输出最终测试结果

以太网Tcpdump丢帧率

消费方CANProxy RTE_Read接口丢帧率

通过丢帧率数据，识别丢帧现象出现在链路

Aruix侧？

MW of Aruix侧？

MW of Xavior侧？

重复测10次，保证测试样本足够，统计后得到最终测试结果

4.4 性能测试

实际测试过程是在一个上层没有布真实客户算法的空RTE环境中，那么怎么保证在空的环境里面跟集成客户算法的环境里SOA的稳定性呢？这需要做一个性能测试，主要分为task跟core两个层面。

目前用到了一个内部叫做Perf的测试工具，它也是通过以太网的方式，支持python2或者3。敲一段命令之后，它可以触发到软件内部的Check point进行一个计算，最后计算的Summary以CSV格式保存下来。

最终perf会把这些数据全部汇总到Core上面，这样就可以看到在未集成算法的时候整个SOA它的负载率是多少。这个工具不仅可以用到未集成上层算法的环境中，如果客户集成了他自己的应用算法，他想看一下在集成应用算法的时候，到底自己的WCET负载率到底有没有超出预期，也是可以通过这个工具非常直观的看出，或者可以做一个标定的用途，来满足整体的系统设计需求。

审核编辑 ：李倩