文章

VRTE-DM的应用一（doip协议介绍）

发表于 更新于
作者 匆匆那年 17 分钟阅读

背景介绍

在汽车行业，随着车辆电子化、智能化程度的提高，汽车中电子控制单元（ECU）的数量已经从早期的几个增加到几十甚至上百个。这些 ECU 负责管理发动机、变速器、安全系统、娱乐系统等功能。为了确保车辆在整个生命周期内的性能稳定并快速诊断故障，Diagnostic Manager（诊断管理器）成为车辆电子架构中不可或缺的一部分。Diagnostic Manager 是基于国际诊断协议（如 UDS、OBD-II）的软件组件，用于集中管理和协调车辆的诊断功能。它通过标准化的通信接口与外部诊断工具交互，为车辆的生产、维护和软件更新提供支持。 故障记录是DM中比较常见的功能，比如汽车仪表盘亮起发动机故障灯，由于发动机故障灯对应的故障非常多，因此诊断工程师需要通过诊断仪读出对应的故障码及信息，以便快速定位问题，比如颗粒捕捉器堵塞（符合国六排放的汽车，会安装颗粒 捕捉器）；在OTA广泛应用前，汽车软件更新或修复需要通过诊断仪刷写去完成；其它比如获取车辆信息，标定等功能在DM中应用也非常广泛，就不一一例举了。 和CP一样，AP也定义并实现了DM软件。DM（Diagnostic Manager）通常分为两个子模块：DCM（Diagnostic Communication Manager）和 DEM（Diagnostic Event Manager）。DCM 是诊断管理器中负责与外部诊断工具或系统进行通信的模块。 它主要处理诊断协议的实现和请求的解析与响应。主要功能包括通信协议支持 （DoIP）、请求解析与响应、诊断会话管理。DEM 是诊断管理器中负责故障事件和诊断数据管理的模块，它是故障监控、记录和报告的核心。主要功能包括故障事件监 控、故障记录管理。这两个模块在汽车诊断功能中各司其职，共同构成完整的诊断管 理系统。

图1-1 显示了DM与其它模块交互关系：

image1

DM 与其它模块具体介绍模块如下：

交互模块含义
Diag App(asw)DM 作为proxy 方，通过ara::com（IPC SHM）将具体服务请 求发送至Diag App，Diag App 完成具体UDS 服务实现。
Per(bsw)DM 判定故障达到存储条件时，会调用Per提供的相关接口， 进行相关故障信息存出。
Crypto(bsw)DM 进行安全认证服务时，在获取根证书以及证书验证，会使 用到Crypto 相关信息安全api。
STMDM在收到EcuReset 服务请求时，会向STM发起请求，由STM 执行操作。
LogDM 使用Log接口打印相关日志（console、remote、file）
EMDM 的启动和停止被EM管理，需要向EM汇报进程状态

doip 协议介绍

DoIP（Diagnostic communication over Internet Protocol）是基于车载以太网的诊断，在OSI 七层模型中属于传输层，其传输的诊断数据也是基于UDS，即DoIP是在以太网网络上传输UDS诊断数据的传输协议。DoIP带宽高，适合传输大量数据的场景。 其中报文类型对应的处理流程以及时间参数是协议ISO13400中比较重点的内容。

doip 报文数据流

如下图 2-1所示，显示了在诊断工具和车辆的电子控制单元（ECU）之间基于 DoIP（Diagnostic over Internet Protocol）协议进行通信时的数据传输过程。

image2

诊断设备用户程序将请求的uds报文传输至诊断设备的DOIP层，DOIP层会将 uds 报文进行打包，封装doip header（具体格式参考图2-2 所示），进而传输至ECU 端。ECU 的DOIP 层接收到报文，会先进行doip header 处理，处理完成后将uds报文传输至ecu的uds处理程序。处理完成后数据流上述相反，再回复至诊断设备，从而完成一次完整交互。

image3

doip 时间参数

在 DoIP 协议中，时间参数的设置非常重要，因为它直接影响通信的稳定性和效率。下图2-3定义了doip时间参数。

image4

  1. A_DoIP_Ctrl 该参数值诊断设备发送完上一个UDP报文后的等待响应的最长等待时间，如果该UDP报文以广播形式发送给多个DoIP节点，那么这个时间指等待所有节点 响应的完成的时间。该时间参数只针对UDP报文。
  2. A_DoIP_Announce_Wait 这个时间参数应用场景有两个：
    1. DoIP节点在获取IP地址成功到发送第一个车辆声明报文的时间间隔
    2. DoIP节点在收到诊断设备发送的车辆信息请求报文后发送车辆信息响应报文的时间间隔。该参数是0-500ms的一个随机值，之所以设 置为随机值是为了避免所有DoIP节点同时发送车辆声明报文或车辆信息响应报文，造成网络堵塞。
  3. A_DoIP_Announce_Interval 该参数是指三条车辆声明报文之间的时间间隔，为500ms。
  4. A_DoIP_Announce_Num 这个参数不是时间参数，是指DoIP节点发送车辆声明报文的次数，标准定义 为3次。
  5. A_Vehicle_Discovery_Timer 该参数是指留给车上DoIP节点做GID同步的时间，诊断设备只有在收到的车辆信息响应报文或车辆声明报文中带有有效的 VIN/GID 且 VIN/GID sync. status 为 “incomplete(0x10)”时，才会启动该定时器，等待车上的DoIP 节点进行GID 同 步。该定时器超时时间为5s，超时后诊断设备可再次请求车辆信息。
  6. T_TCP_Initial_Inactivity 该参数指DoIP节点在建立TCP连接后等待路由激活报文的最长等待时间，超时时间为2s，如果2S后仍没有收到路由激活报文，DoIP节点将关闭TCP连接。
  7. T_TCP_General_Inactivity 该参数指DoIP节点在收到路由激活报文后，且没有进行TCP数据交互的情况 下，保持TCP连接的最长时间，超时时间为5min，超时后仍没有任何TCP数据 交互的话将关闭TCP连接。
  8. A_DoIP_Diagnostic_Message 该参数指DoIP节点在诊断报文接收完成后，到发送诊断ACK/NACK的时间间 隔，该参数有两层含义，对DoIP节点来说，它是对性能的要求，要求DoIP节点 要在50ms 内做出相应；对诊断设备来说，它是发送完诊断报文后的等待时间，超时时间为2s，超时后仍未收到诊断响应报文的话，应该重复发送该诊断报文。
  9. A_Processing_Time 有些UDS诊断请求是不需要诊断响应的（例如禁止肯定响应位为TRUE），诊断设备在发送完一个不需要响应的诊断报文后，应等待一段时间再发送下一个诊断请求，给ECU预留一段时间进行处理。A_Processing_Time 就是指这个间隔时 间。
  10. T_TCP_Alive_Check 该参数指DoIP节点在发送了一个诊断设备在线检查请求报文后等待响应的时间，超时时间为500ms，如果超时后未收到响应，则DoIP节点判断诊断设备已离线，关闭TCP连接。注意，当DoIP节点向TCP socket 发送请求失败时也应该启动该定时器，应为这意味着诊断设备通信失败，可能已经离线。

如图2-4 所示，将时间参数放到通讯流程中，可以更方便的理解其作用。

image5

doip 报文类型

在 DoIP（Diagnostics over Internet Protocol）协议中，报文类型是用于标识数据传输的上下文和类型的关键字段。DoIP 数据类型通常出现在消息的报文头部，用于区分不同的消息内容，确保通信双方能够正确处理和解析数据。

image6

节点管理报文

  1. 0x0000：Generic DoIP header negative acknowledge

    当DoIP 节点收到的DoIP报文的报头不符合规则时，返回该数据类型的报文。该报文的数据部分只包含1字节的否定响应码（Generic DoIP header NACK code），用来指示错误原因，定义如下图2-6所示：

    image7

    其中Required action 为 DoIP 节点在发送完否定响应报文后采取的动作，上图2-6 包括关闭套接字和忽视报文。

  2. 0x0001：Vehicle identification request message

该类型报文可以用来请求网络中DoIP节点的车辆信息，诊断设备用UDP报文向网络中发该报文，来获取被诊断节点的VIN、GID、EID、逻辑地址等信息。

  1. 0x0002：Vehicle identification request message with EID

    该类型报文的作用和上面的一样，只是在请求报文的数据中搭载了6个字节 的EID，可请求指定EID的DoIP节点的其它车辆信息，用于被诊断节点的EID已知的情况。（EID是DoIP 节点的唯一识别标识符，一般会被设置为该节点的MAC 地址）

  2. 0x0003：Vehicle identification request message with VIN

    该类型报文原理同上，只是在报文数据中搭载的不是EID，而是17个字节的 VIN，用于DoIP 节点的VIN 已知的情况下，请求指定VIN的DoIP节点的其它信息。

  3. 0x0004：Vehicle announcement/Vehicle identification response message

    该报文主要在两种场景下会使用到。第一种为0x0001、0x0002以及0x0003 的回复报文，第二种为车辆声明报文。

  4. 0x0005: Routing activation request

    在车辆发现阶段结束后，外部诊断设备已确定对哪个DoIP节点进行诊断，也获取了必要的信息，这时就需要发送路由激活请求报文，在诊断设备和被诊断的 DoIP 节点间建立起TCP连接，以便于发送诊断数据（诊断报文都是用TCP来发送的）。

  5. 0x0006: Routing activation response

    DoIP 节点收到诊断设备的路由激活请求报文后，建立TCP连接，并返回该路由激活响应报文。

  6. 0x0007: Alive check request

    在车辆发现阶段结束后，外部诊断设备已确定对哪个DoIP节点进行诊断，也 获取了必要的信息，这时就需要发送路由激活请求报文，在诊断设备和被诊断的DoIP 节点间建立起TCP连接，以便于发送诊断数据（诊断报文都是用TCP来发送的）。

  7. 0x0008: Routing activation response

    DoIP 节点收到诊断设备的路由激活请求报文后，建立TCP连接，并返回该路由激活响应报文。路由激活响应码如下图2-7所示：

    image8

状态信息获取报文

  1. 0x4001：DoIP entity status request

    该报文可以被诊断设备用来请求DoIP节点的状态。

  2. 0x4002：DoIP entity status response

    该报文是上一个报文的响应报文，DoIP节点用该响应报文来向诊断设备发送状态信息。报文的数据段定义如下：

    image9

  3. 0x4003：Diagnostic power mode information request

    该报文可以被诊断设备用来请求DoIP节点的电源模式信息

  4. 0x4004：Diagnostic power mode information response

    该报文是上一个报文的响应报文，DoIP节点用该响应报文来向诊断设备发送 电源模式信息，来告知诊断设备当前节点是否允许进行诊断。报文的数据段定义 如下：

    image10

诊断报文

  1. 0x8001：Diagnostic Message

    该类型报文可以用来请求UDS诊断请求数据

  2. 0x8002：Diagnostic Message positive acknowledgment

    该类型报文是ECU 在收到诊断工具发送的诊断请求后，经过处理并确认请求成功执行时返回的响应。

  3. 0x8003：Diagnostic Message negative acknowledgment

    该类型报文是ECU 用于表示请求失败的报文类型。

    image11

etas, dm
etas vrte dm
本文由作者按照 CC BY 4.0 进行授权