一文聊聊域控制器的底层测试

一文聊聊域控制器的底层测试

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

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

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

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

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

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

　　接口测试的主要分为两个部分，第一个是输入中模型输入，模型输入主要包含上层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的做一个反序列化，然后把数据进行对比。

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

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

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

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

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

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

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

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

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

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

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

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

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

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