在研发阶段，我们一般将ECU直连至刷写上位机进行软件更新，但在整车环境中，各ECU之间通过线束连接在一起，如果此时想对某个单独的样件进行软件更新，把零件拆下来再接到上位机上进行软件更新是不现实的。
作为测试工程师，除了保证ECU直连上位机的时候可以正常进行软件升级之外，也要保证在整车环境下可以对车辆软件进行更新。搭建一个系统级的台架测试环境，将车内的ECU节点按照整车网络拓扑连接好之后，模拟上位机对ECU进行刷写测试，可以验证在整车环境下，各ECU之间是否能配合完成车辆软件的更新。
在整车上实现软件升级一般有两种方式，最常见的是通过车辆的OBD接口，用诊断仪进行升级，还有一种是通过远程诊断（如TBOX）的方式来实现升级功能。下图描述了整车网络拓扑的简图。
上位机（诊断仪/TBOX）通过以太网TX/T1接口连接网关节点，将UDS诊断请求发送给网关，网关要实现诊断路由功能，解析DoIP报文中的TA（Target Logical Address），识别上位机是给哪个网段的哪个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->DoIP
当上位机刷写的ECU为车内DoIP节点时，网关根据诊断报文中的Target ECU Logical Address识别目标DoIP节点，并主动与ECU完成路由激活，之后转发上位机发送的以太网诊断请求给ECU，以及ECU回复的诊断响应给上位机，实现DoIP->DoIP的诊断路由。诊断请求报文格式转换示例如下。
上位机
上位机发送UDS诊断请求，网关在上位机和ECU之间实现诊断路由，从而实现上位机对ECU的诊断，上位机按照刷写流程一步一步的将刷写文件写入ECU中，实现ECU的软件更新。
实现系统级刷写测试需考虑系统供电、通讯控制、故障注入三个方面。
系统供电：需要选用可编程控制的电源，方便自动化调节系统的供电电压。
通讯控制：Tester需要模拟上位机实现跟网关的通信，同时也要监听网关和ECU之间的通信，这就要求测试使用的网络接口卡可以同时监听多个网段（Tester<-->网关，网关<-->车内ECU），当刷写流程出现问题时（如，上位机没有接收到诊断响应），可以通过不同网段的log分析是ECU没有回复诊断响应，还是网关没有正确转发ECU的诊断响应。采用TAP模式监听网关和车内以太网节点之间的以太网数据。
故障注入：测试过程中需要模拟网络通讯故障和ECU掉电故障，如CAN通讯断路，以太网P/N短路等。可以选用ETS6204模拟以太网通讯故障，ETS6210模拟CAN网络通讯故障，同时也都能实现对ECU的电源控制。
系统级刷写测试的执行一般是在完成单节点刷写测试和网关诊断路由测试之后，在此之前应已单独验证了ECU可以实现刷写功能，以及网关可以实现诊断路由功能。
单节点的刷写测试，侧重点在于验证刷写流程，以及刷写流程错误时ECU的响应。而系统级刷写测试，则着重关注测试环境变化对刷写的影响，如电压不稳定、以太网接线不稳定等，确保当一次刷写出现问题时不影响后续重新对其进行刷写。可设计的测试点参考如下。
软件实现
Tester可以使用CANoe或SolarTest软件实现自动化测试，如之前描述，在系统级刷写测试之前已经进行了单节点的刷写测试，那么系统级的刷写测试，就可以基于单节点的刷写测试脚本进行更新。
以上就是我们给大家分享的以太网系统级刷写测试的相关内容了，任何疑问或是自动化测试需求，都可以随时联系我们噢，感谢大家的阅读~