天赐好车的博客

本专栏通过建立标准和平台的思路去解决车载网络诊断这项测试内容。

UDS 0x29 Authentication 认证服务详解

AI+ECU测试，AI+ECU测试工具，AI+ECU测试自动化

【并行刷写与队列刷写】汽车 ECU 软件刷写中的两种效率提升方案

SOVD 并不是新的诊断报文协议，而是一种面向服务、面向云、面向未来的软件定义汽车诊断访问标准。

根据 ISO 14229-1:2013 Table 5（“Response may be suppressed” 标记的行），可抑制的 NRC 只有以下五类

车载网络诊断测试设备与台架1.测试设备2.测试台架3.测试板卡方案设计

这篇介绍测试软件的方案，按照`平台化，模块化，标准化`的思路去设计。对于车载网络诊断的测试，同一项测试内容可以放在单控制器，系统环境，整车环境去测试，我们的脚本也需要能够分别在不同环境通过配置去执行。能够一个工具搞定的就不要用两个工具。能够在一个环境搞定的也不要放在两个环境。上篇我们介绍的硬件平台是可以经过配置在单件，系统，整车环境都可以布置测试的，配套的测试软件平台也需要按照这个思路去设计开发。这里主要分为以下几块：测试环境和设备控制，测试配置，解析工具，测试内容几块去介绍。

车载网络诊断测试用例标准与示例（车载网络诊断测试平台）

车载网络诊断CANoe测试平台工程建立1.概述2.车载网络诊断CANoe测试平台工程3.总结

本篇为工作中的一些思考，想到什么更新什么，等觉得成系统了再梳理。1.测试流程2.影响测试的因素3.管理4.持续更新

测试能力建设并非一蹴而就，也不一定需要一次性投入高昂成本。在项目节奏不断加快的现实条件下，围绕准确性、覆盖性和可复用性，逐步构建适合自身团队的测试能力，往往比追求“最强工具”更具实际价值。测得准，不误测；测得全，不漏测。始终是测试工作的核心目标。

目前车上主流的网络有CAN、LIN、ETH(以太网)。按照测试环境可以划分为单件测试，系统测试，整车测试。我们来看下CAN和以太网的分层图:CAN的分层图：以太网的分层图：最好的就是按照这个分层来开发对应的工程。在开发具体工程及具体用例的时候同样需要考虑是否可以在单件，系统，整车都可以复用，比如测试报文周期等用例。在开发工程的时候要按照平台化，标准化，模块化的原则去开发，能复用的功能就不要开发两次。当然这个需要经验去把握，需要你足够了解。

【测试用例设计方法论】如何构建“可定位、可维护、不漏测”的用例体系

CAN/CANFD通信E2E发送(ECU发送)自动化测试

测试台架如何选择线束?

CANoe新建XML自动化Test Modules。

这篇博客是对之前写的专栏从零开始搭建一个UDS诊断自动化测试CANoe工程和专栏车载网络诊断测试攻略内容的补充。之前也在文章里提到过一个log记录模块，这篇博客就是介绍log记录模块，主要实现保存每个用例的log.每次执行按照时间保存报告和log.每个用例的log按照用例名字和时间保存。大家可以按照此方式按照自己的需求修改。

CarConfig介绍carconfig测试都测试什么？测试carconfig需要实现什么？自动化测试实现思路

如果TCP链接的建立不是由Tester主动发起，而是由控制器主动发起的话，控制器作为client，是不符合协议规定的方向的，这时候就不能直接使用DoIP相关函数了，只能通过TCP socket的方式去建立连接。在我们使用TCP去建立连接的时候，ECU内部如果有两个不同的IP都需要建立TCP连接，CANoe是没办法在一个网络上实现的。那我们也需要可以控制去与哪个IP建立连接，我们现在说的情况都是ECU主动建立TCP连接的情况，不是CANoe去主动建立连接。

基本传输定时参数N_As、N_Ar、N_Bs、N_Br、N_Cs、N_Cr

SOME/IP-SD 是基于 UDP 多播的服务发现与订阅协议，作为 SOME/IP 的子协议存在于 AUTOSAR 通信栈中。它通过 Entry + Option 的 TLV 风格结构编码服务公告（OfferService）、服务发现（FindService）以及事件组订阅（SubscribeEventgroup）。SD 报文承载在固定 Service ID/Method ID 的 SOME/IP 消息中，典型部署使用统一的多播 IP 和 UDP 端口。服务可用性通过 TTL 管理，结合 Initial

调用osek_tp.dll实现诊断基本通信，可发送UDS诊断的报文，实现多帧传输等。本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。

本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。通过osek_tp.dll实现诊断服务的接收和发送。物理寻址，功能寻址可以配置。实现27服务安全解锁的框架，具体算法需要根据不同厂商自己去实现。

通过Panel发送接收UDS诊断报文。本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。通过osek_tp.dll实现诊断服务的接收和发送。

在这个xml 测试节点加载我们需要使用的osek_tp.dll，并新建一个C本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。能寻址可以配置。实现27服务安全解锁的框架，具体算法需要根据不同厂商自己去实现。

前面几篇介绍了panel的上半部分，接下来介绍下半部分。诊断服务中有些服务我们是经常用到的，像会话切换，复位，解锁，读取清除DTC等。下面的面板优化的一部分，整体逻辑跟之前看到的是一样的，can canfd用了两个按钮设置，接收的数据增加了一个ascii码的显示，读取一些软件版本的时候能够转换。

UDS 27服务 安全解锁

本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。通过osek_tp.dll实现诊断服务的接收和发送。物理寻址，功能寻址可以配置。实现27服务安全解锁的框架，具体算法需要根据不同厂商自己去实现。

本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。通过osek_tp.dll实现诊断服务的接收和发送。物理寻址，功能寻址可以配置。实现27服务安全解锁的框架，具体算法需要根据不同厂商自己去实现。

10 03 50 0327 0567 05 xx xx xx xx27 06 yy yy yy yy //发送错误key7F 27 35//第一次解锁失败27 0567 05 xx xx xx xx27 06 yy yy yy yy //发送错误key7F 27 36//第二次解锁失败27 057F 27 37//第三次请求种子... ...//再次请求还是nrc37testswaitfortimeout（解锁失败后等待时间delay_TIME)27 05//再次请求seed

DTC这块测试对比其他测试项相对复杂，主要是解析数据和对比DTC这块。这两块解决了，然后就是如何制造故障，我们这里只介绍三种类型的故障：通信相关（节点丢失，信号错误等），制造这类故障主要是使用CANoeIL，通过代码来控制报文的发送行为，修改信号的数据等；高低压故障，如果有程控电源，就可以时间上比较精确的控制，如果没有，可以用testWaitForTesterConfirmation函数来进行等待手动操作完成。busoff故障，使用VH6501设备，也可进行程序控制。

三、如何使用CANoeIL制造故障（接上篇）四、通信相关DTC测试（报文丢失，信号错误）五、高低压DTC

本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。本工程主要实现功能如下：bootloader功能主要是36服务的实现，还不确定要不要实现及介绍。此工程拿来即可使用，除27服务算法那块需要自己去实现，诊断id，can/canfd都可配置。测试用例也可二次开发成自己需要的，底层函数均实现。要提升自动化程度，也可基

本专栏将从零开始搭建一个用于UDS诊断服务的CANoe测试工程，基于CAN/CANFD总线，可以手动测试，也可自动化测试，使用XML测试节点实现。目前使用cdd及diva可以快速生成uds诊断的测试用例及工程，任有部分用例无法涉及或配置比较复杂。CAN/CANFD可以配置选择。诊断ID可通过面板配置，工程运行过程也可以修改，cdd的诊断id是固定的。通过osek_tp.dll实现诊断服务的接收和发送。物理寻址，功能寻址可以配置。实现27服务安全解锁的框架，具体算法需要根据不同厂商自己去实现。

28服务是控制报文的发送与接收的，一般在刷写前会使用这个服务禁掉报文的发送。第一个字节：00 启用Rx和Tx01 启用Rx和禁用Tx02 禁用Rx和启用Tx03 禁用Rx和Tx第二个字节：01 APP报文02 NM报文03 APP+NM报文

36服务是实现boot刷写的重点，其他服务跟之前介绍的服务都有相似之处，不花大篇幅介绍。36服务发的数据格式为：36+counter+data，比如：第一轮：36 01 + data36 02 + data... ...36 FF + data第二轮：36 00 + data //从第二轮开始，counter是从 00 开始，直到传输完成36 01 + data36 02 + data... ...36 FF + data... ...... ...

本文在之前文章的基础上实现车载以太网DoIP诊断通信，通过调用DOIP.dll实现。除了发送接收报文部分，上层UDS诊断处理都是一样的，所以可以和CAN/CANFD的共用。最后在一个CANoe工程里实现了CAN/CANFD/ETH3种通信方式的UDS诊断。

上篇介绍了在test自动化模块里的DoIP通信，这篇介绍在节点里的DoIP通信，结合panel面板发送DoIP诊断报文。

通过一个excel来记录DTC的一些信息，我们定义填写标准，通过python对这个excel的数据进行提取，然后根据提取的信息生成一个config.cin文件。