Bootloader开发：刷写时，被刷节点和非刷写节点行为有何不同？

开发Bootloader的朋友是否曾有这样的疑问：

1. 刷写Application程序的过程中，被刷写节点和非刷写节点，通信行为有何不同？

2. 一个节点为什么既要功能寻址，又要物理寻址？

3. ......

本文，带着这些疑问，展开聊聊。

提示：本文，以CAN总线为例，展开讨论。

1、报文类型及网络拓扑

（一）报文类型

在理解上述问题之前，我们需要先了解一下报文的类型，在整车的网络拓扑中，根据通信场景的不同，一般会将报文分为：应用报文、网络管理报文、标定报文、诊断报文、其他。报文类型及优先级，示意如下：

如上示意可以看出，一般，诊断报文的优先级最低，这也意味着：诊断报文在抢占总线使用权时，"很吃亏"，如果同一时刻，有其他类型的报文也要使用相同网段的CAN总线，诊断报文将会因抢不到总线使用权（优先级低），而被delay。关于CAN总线仲裁原理，可以参考前文CAN总线仲裁原理。所以，这也是UDS（Unified diagnosticservices）中，存在$28（Communication Control service）服务的意义。即：如果需要升级Application程序时，可以通过$28服务将网段内的非诊断报文禁用，只让诊断报文独占总线使用权，进而提高程序刷写效率。

（二）总线拓扑

一辆车的网络拓扑，会根据不同的使用场景，选用不同的总线。一个简易的整车网络拓扑示意如下所示：

如上图，当一个销售到终端用户的车辆需要更新Application时，比如：A节点。一般需要通过OBD（On Board Diagnostics）或者OTA（Over-the-Air）方式升级，不管使用何种方式，均需要诊断报文将信息送达需要升级的节点（eg：上图A节点）。如上可以看出，如果一条诊断指令要送达到A节点，同时，A节点将诊断响应给到上位机，需要经过中央网关（Central Gateway）和子网关（Auxiliary Gateway2）。既然，诊断报文需要经过这两个网关节点，就意味着，诊断报文需要在对应的网段参与竞争，获取总线使用权，之后才能到达目标节点。

2、刷写Application过程中，被刷写节点和非刷写节点的通信行为有何不同呢？

理解了整车网络拓扑和报文优先级，再来思考：“刷写Application过程中，被刷写节点和非刷写节点的通信行为有何不同”。对于上图中的被刷写节点A，如果想提高其刷写效率和稳定性，需要创造一个条件：尽可能地使诊断报文获取总线使用权。如何才能让诊断报文获取总线使用权呢？答：方式一：使用$28诊断服务，临时关闭非诊断报文的通信。

注意：一般$28服务，需要配合$85（Control DTC Setting service）一起使用，否则，节点间会因收不到对应的应用报文，而报节点丢失DTC。

但是，有些OEM，Application的刷写流程中，不用$28和$85服务。既然不用$28和$85服务，如何关闭节点间通信，给诊断报文让出总线使用权呢？答：方式二：使用功能寻址+$10 02/82（Diagnostic Session Control service）服务。

（一）一个节点，为什么既有功能寻址，又有物理寻址？

先理解一下功能寻址和物理寻址，如下：

• 功能寻址：一对多通信方式，即：上位机发送一帧诊断报文，所有节点均可以接收和处理；
• 物理寻址：一对一通信方式，即：上位机发送一帧诊断报文，只有指定的节点可以接收。

为了提高被刷写节点的刷写效率，需要将总线使用权让给诊断报文，这就意味着：上位机要告诉整车网络中的所有节点，有节点需要更新Application程序，大家静默一会（关闭各自的非诊断报文）。如何做到这一点呢？如果上位机一个一个节点的通知，显然不是最优方案。如果能让所有节点或者诊断报文经过的网段内所有节点同时静默，将大大地提高刷写效率。怎么做到呢？答：利用功能寻址的特点，一次告诉所有的目标节点，进入静默状态。如上的讨论中，静默的方式可以有两种：

• 功能寻址发送$85+$28服务；

• 功能寻址发送$10 02/82服务，让所有节点跳转，进入Bootloader程序（Bootloader程序中，一般不发送非诊断报文）。

功能寻址的诊断报文，所有节点均可以接收和处理，所以，所有节点均可进入静默模式。节点进入静默状态以后，诊断报文即可独占总线使用权，从而达到刷写目标节点的目的，但是，此时，不能再使用功能寻址发送诊断报文，因为要升级的节点是特定的，eg：上图中的节点A。如果只给目标节点升级，就需要使用唯一识别的ID进行升级，所以，这就是为什么每个节点还会有一个唯一识别的物理ID原因。使用物理寻址，升级完目标节点以后，再通过功能寻址，告诉其他静默节点，指定的节点升级完成，大家可以通信了，都“躁”起来吧。

提示：单件测试时，因为搭建的网络环境只有一个被测节点（DUT：Design Under Test）和仿真上位机，不像整车环境那样：存在大量节点。因此，有时单件测试表现良好，并不意味着整车测试也能表现良好。

思考：单件刷写测试中，CANoe等仿真设备启用self ack可以吗？答：可以。self ack启用等同于有节点接收到报文，整车刷写过程中，完成目标节点刷写，复位以后，各个节点恢复通信的时机存在一定差异，有的节点通信功能恢复的早，即：可早应答报文，有些节点通信恢复的时机稍晚，接收到的报文，可能已被其他早参与通信的节点ack，因此收到的报文，可能已被ack过。

文章转载自公众号：开心果 Need Car