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

1 关于创时智驾

1.1 产品及服务

为客户提供平台和服务：

• 通过创时的系统平台解决方案，使客户能够进行快速地系统集成工作以及自由选择所需的上层应用程序。这意味着与所有更高层次的软件平台的最大兼容以及对面向服务平台的全面支持。
• 客户可以依靠创时强大的工程团队作为可靠集成伙伴，以实现项目所要求的速度，灵活性以及功能性。

鲁棒和安全的汽车解决方案

• 提供从基础软件到软件集成端到端的解决方案，从硬件设计到量产服务的灵活定制化服务。
• 整合最先进的安全模块，以补充软件定义汽车及生态系统赋能的功能趋势。

中国设计，服务全球

• 本土设计优势-充分了解中国市场需求和工程文化背景。
• 整合功能安全标准与网络安全技术，服务全球客户。

赋能OEM 与合作伙伴

• Fabless Tier- 客户可以跟工具自己的发展测略进行灵活选择
• 集成的开发环境，内置工具链和开发流程，使快速高效的开发和集成工作成为可能

最先进的技术和流程工艺

• 产品组合包含时下性能领先的NVIDIA Orin芯片
• 全球首个将Mobileye eyeQ4-HI, TDA4VM以及Orin-X芯片组合应用于ADAS L+项目中的服务商
• 中国首个获得ISO-26262 ASIL D 流程与硬件产品安全证书双认证企业
• 支持的技术：网络：带交换器配置的时间敏感型网络，带QoS的DDS，SOMEIP, 零贝进程间通信SOA: 信号转服务以及代码生成工具链，基于服务的应用开发APIs平台服务: GPS时间同步，平台健康监测，FOTA等开发服务：基于量产硬件数据搜集系统安全性：符合ISO 21413标准，支持国际加密，Safe Com/FOTA/Startup, IDPS集成

1.2 核心能力

复杂域控量产开发能力

• 复杂域控制器硬件的架构设计、器件选型、电路设计、实验验证等能力
• 多域集成高性能控制器硬件设计域实现、紧凑结构设计能力
• 高功能安全登记控制器硬件功能安全的设计域实现、分析与计算、登记提升整改的能力

软件系统集成能力

• 集成实时操作系统RTOS、QNX、安全Linux以及底层驱动软件开发能力
• 符合AUTOSAR架构规范的中间件软件集成、ECU软件木块、智驾框架软件开发与集成能力
• 支持视觉算法开发，AUTOSAR软件开发，数采、回放、可视化、以及HIL在内的ECU应用软件开发集成工具链的能力

2 硬件测试

2.1 硬件模块化测试

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

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

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

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

2.2 DV/PV测试

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

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

3 软件接口测试

3.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文件，这样测试的上位机和待测软件的测试代码就已经生成好了。

3.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的做一个反序列化，然后把数据进行对比。

4 系统测试

4.1 CAN通讯测试

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

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

4.2 FOTA测试

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

正向测试：

1.制作更新包

2.用ICC simulator触发更新

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

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

故障注入测试：

1.制作更新包

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

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

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

4.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中进行测试。

4.4 以太网通讯测试

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

4.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是可以做到在十毫秒左右，基本上都是可以满足客户的要求。

5 压力与性能测试

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

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

CAN 模拟输入：

• 通过CAPL 脚本模拟发送所有DUT接受报文
• SWC:(ApCOM+MW)正常运行
• 在CANProxy FreeRunning SWC中增加测试代码，通过RTE接口读取所有PDU的EGT时间戳
• 测试数据将通过以下方式输出：
  在线输出：UART接口，以太网接口
  离线输出：通过SCP命令

测试结果

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

5.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正常启动

5.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次，保证测试样本足够，统计后得到最终测试结果

5.4 性能测试

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

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

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

文章转载自公众号：智能汽车开发者平台