技术丨浅谈以太网系统级刷写测试

本文主要是介绍技术丨浅谈以太网系统级刷写测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在研发阶段，我们一般将ECU直连至刷写上位机进行软件更新，但在整车环境中，各ECU之间通过线束连接在一起，如果此时想对某个单独的样件进行软件更新，把零件拆下来再接到上位机上进行软件更新是不现实的。

作为测试工程师，除了保证ECU直连上位机的时候可以正常进行软件升级之外，也要保证在整车环境下可以对车辆软件进行更新。搭建一个系统级的台架测试环境，将车内的ECU节点按照整车网络拓扑连接好之后，模拟上位机对ECU进行刷写测试，可以验证在整车环境下，各ECU之间是否能配合完成车辆软件的更新。

01 系统级刷写实现方式

在整车上实现软件升级一般有两种方式，最常见的是通过车辆的OBD接口，用诊断仪进行升级，还有一种是通过远程诊断（如TBOX）的方式来实现升级功能。下图描述了整车网络拓扑的简图。

上位机（诊断仪/TBOX）通过以太网TX/T1接口连接网关节点，将UDS诊断请求发送给网关，网关要实现诊断路由功能，解析DoIP报文中的TA（Target Logical Address），识别上位机是给哪个网段的哪个ECU发送的诊断请求，并将该诊断请求路由到对应ECU所在的网段上。同理，网关将ECU回复的诊断响应路由给上位机，在执行了完整刷写流程的诊断交互之后即实现了对ECU的软件升级。

完成系统级刷写除了需要ECU本身实现刷写功能，还需要网关实现诊断路由功能，下面简要介绍各参与模块的工作原理。

ECU刷写

车载ECU的刷写流程主要包括3个阶段（预编程，编程，后编程），通过UDS协议来实现，下图是基于UDS刷写的流程示例。

网关诊断路由

DoIP->DoCAN

当上位机刷写的ECU为车内CAN节点时，网关根据诊断报文中的Target ECU Logical Address识别目标CAN节点，将上位机发送的以太网诊断请求转换为CAN诊断请求给ECU，之后将ECU回复的CAN诊断响应转换为以太网诊断响应给上位机，实现DoIP->DoCAN的路由。诊断请求报文格式转换示例如下。

DoIP路由DoCAN诊断请求格式示例

车内CAN节点诊断交互过程示例

DoIP->DoIP

当上位机刷写的ECU为车内DoIP节点时，网关根据诊断报文中的Target ECU Logical Address识别目标DoIP节点，并主动与ECU完成路由激活，之后转发上位机发送的以太网诊断请求给ECU，以及ECU回复的诊断响应给上位机，实现DoIP->DoIP的诊断路由。诊断请求报文格式转换示例如下。

DoIP路由DoIP诊断请求格式示例

车内DoIP节点诊断交互过程示例

上位机

上位机发送UDS诊断请求，网关在上位机和ECU之间实现诊断路由，从而实现上位机对ECU的诊断，上位机按照刷写流程一步一步的将刷写文件写入ECU中，实现ECU的软件更新。

02 系统级刷写测试

测试环境

实现系统级刷写测试需考虑系统供电、通讯控制、故障注入三个方面。

系统供电：需要选用可编程控制的电源，方便自动化调节系统的供电电压。

通讯控制：Tester需要模拟上位机实现跟网关的通信，同时也要监听网关和ECU之间的通信，这就要求测试使用的网络接口卡可以同时监听多个网段（Tester<-->网关，网关<-->车内ECU），当刷写流程出现问题时（如，上位机没有接收到诊断响应），可以通过不同网段的log分析是ECU没有回复诊断响应，还是网关没有正确转发ECU的诊断响应。采用TAP模式监听网关和车内以太网节点之间的以太网数据。