随着以太网技术在汽车领域的广泛应用，基于以太网（DoIP，Diagnostic Communication Over Internet Protocol）的车辆刷机已经不再是新鲜事。然而，当该技术投入开发时，总有许多细节值得我们考虑和注意。本文将谈谈基于以太网的软件刷机的 QA。
Q1：应用程序请求更新的TCP连接等待时间与普通冷启动的等待时间相同吗？
A1: 一般是不一样的。为了大家更容易理解这个问题，我们先对此进行扩展。芯片内含有用户的Bootloader程序和用户的Application程序。当Application需要更新时，Application可以先将一个标志（如：ProgSignature）写入一个共享内存区域（Shared Memory）。之后程序进入Bootloader，读取Bootloader中的标志，然后判断Application是否有更新请求，如下图所示：
如上图所示，当程序在Bootloader中，在进入Application之前，需要进行Application更新请求判断。如果有请求，程序就停留在Bootloader中，等待诊断指令更新Application。因为是基于DoIP刷机，所以建立TCP连接是前提（这里假设TCP连接时间为T_EstablishTCPConnection#1）；如果没有更新Application的请求，也必须建立TCP连接（这里假设TCP连接时间为T_EstablishTCPConnection#2），以便在诊断接收窗口期（Timeout_Prog，eg:5ms/20ms）内可以接收到诊断指令。这一步主要是为了防止控制器变砖。示意图如下：
那么，问题来了：T_EstablishTCPConnection#1和T_EstablishTCPConnection#2是同一个时间吗？如果Application不需要更新，即没有设置ProgSignature（No Set），应该尽快建立以太网通信连接（eg：T_EstablishTCPConnection#2 = 1s）。如果Application有更新请求，即设置了ProgSignature（Set），为了保证后续刷机，其以太网通信连接时间是可以容忍的（eg：T_EstablishTCPConnection#1=30s）。注意：上面的1s或者30s是指TCP建立连接的最大等待时间，对于实时性要求严格的MCU级芯片，实际的TCP连接时间不会这么长。
Q2：哪个节点首先发起 TCP 连接？
A2：要回答这个问题，首先我们要了解车辆的以太网网络拓扑结构。车辆的以太网拓扑结构如下图所示：
如上图所示，基于DoIP的诊断一般包含以下几个角色：外部测试设备、云端（Cloud Diagnostic Tester）、边缘节点（DoIP Edge Node）、以太网终端节点（DoIP node）。
由于每个人扮演的角色不同，功能上也会有一些差异，了解了基于DoIP的以太网拓扑结构之后，我们再回到问题：谁来主动发起TCP连接？
一般来说，DoIP 节点作为以太网的终端节点，会是 TCP 连接的客户端，也是 DoIP 的服务端。由于以太网的终端节点需要和边缘节点通信，或者让边缘节点转发以太网消息，所以边缘节点不仅会充当交换机的角色，还需要作为 TCP 的服务端。所以，问题有了答案：当 DoIP 节点和 DoIP Edge Node 进行 TCP 诊断通信时，DoIP 节点会主动发起 TCP 连接（特别是当 DoIPnode 进入编程会话时）。结合 Q1 中的 T_EstablishTCPConnection 时间，我们可以了解到，每次 DoIP 节点（TCP Client）复位或者冷启动时，都需要主动发送 TCP 请求。
在DoIP Node与DoIP Edge Node之间建立TCP连接时，需要注意以下几点：
Q3:S3Server何时启动/停止？
A3：首先明确一下S3Server的定义，S3Server时间是指服务器在收到诊断命令请求后刷ip软件，保持在非默认会话的时长（例如：5s）。S3Server启动/重置和会话的关系如下：
如果DoIP Node A初始化完成，DoIPNode B会先启动S3Server时间。如果DoIPNode B未初始化或者初始化时间太慢，DoIPNode A的S3Server时间会超时并退出非默认会话刷ip软件，影响后续诊断。因此，进入非默认会话后，S3Server启动时间需要等到客户端与服务端完成DoIP连接。
Q4:为什么需要在Bootloader中发送网络管理消息？
A4: 在一些OEM需求中，大家有没有注意到Bootloader开发者需要在Bootloader中周期性（例如：500ms±10%）发送网络管理消息（例如：0x53F）？这是为什么呢？我们知道在Bootloader中，一般是不需要网络管理的，网络管理一般都是在Application中使用。
例如支持以太网和CAN的ECU节点与子节点CAN ECU的诊断需要通过CAN消息交互，而CAN ECU的唤醒方式只能是被动接收CAN NM Msg。如果IP/CAN ECU在启动进入Bootloader后，不向CAN ECU发送CAN网管消息，那么就无法唤醒CAN ECU，无法与IP/CAN ECU建立通信。所以，这也是为什么需要在Bootloader中发送CAN NM Msg的原因。示意图如下：
同时考虑到CAN ECU可能支持PNC（Partial Network Cluster）网络管理，因此在发送CAN NM Msg时，可以设置所有的User Data，例如：0x3F 0x40 0xFF 0xFF0xFF0xFF0xFF0xFF。
过去的亮点
点击下方关注，一起聊聊Autosar/Embedded，有需要可以联系作者入群，给你更多专业解答。
