DoIP----报文类型(二)

        我们上一篇文章提到,DoIP报头中有两字节的数据类型(Payload Type),代表DoIP报文类型,本文就来详细介绍一下每一种报文类型。

        标准中对报文类型的定义如下:

        数据类型分为三部分,标绿的是节点管理报文,标黄的是状态信息获取报文,标蓝的是诊断报文。

 

1. 节点管理报文


        节点管理报文的作用主要是获取DoIP节点的信息、建立连接、保持连接等。

① 0x0000:Generic DoIP header negative acknowledge


        当DoIP节点收到的DoIP报文的报头不符合规则时,返回该数据类型的报文。该报文的数据部分只包含1字节的否定响应码(Generic DoIP header NACK code),用来指示错误原因,定义如下:

        上表中,Required action表示DoIP节点在发送完该否定响应报文后应该采取的动作,是忽略该报文还是关闭套接字。

        该报文可使用上文所述的三种端口类型作为目的端口,具体使用哪种取决于DoIP请求使用的哪种端口。

② 0x0001:Vehicle identification request message


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

        该报文中只包含DoIP报头,没有数据。

        该报文的目的端口为UDP_DISCOVERY。

③ 0x0002:Vehicle identification request message with EID


        该类型报文的作用和上面的一样,只是在请求报文的数据中搭载了6字节EID,可请求指定EID的DoIP节点的其它车辆信息,用于被诊断节点的EID已知的情况。

        EID是DoIP节点的唯一识别标识符,一般会被设置为该节点的MAC地址。

        该报文的目的端口为UDP_DISCOVERY。

④ 0x0003:Vehicle identification request message with VIN


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

        该报文的目的端口为UDP_DISCOVERY。

⑤ 0x0004:Vehicle announcement/Vehicle identification response message


        从名称中可以看出,该类型的报文有两种用途,第一个用途是以上三种报文的响应报文(Vehicle identification response message),当诊断节点发送了以上三种车辆信息请求报文后,符合条件的DoIP节点将会返回该响应报文,报文数据部分的格式如下:

        报文数据共33字节,包含:

17字节的VIN
2字节逻辑地址,该逻辑地址用于诊断,后文详述
6字节EID
6字节GID:同一辆车上多个DoIP节点可以编为一组,用GID来标识这一组的DoIP节点。
1字节Further action required:该字节用来表示在数据传输过程中是否需要额外的操作,如是否启用安全机制,定义如下:

        1字节VIN/GID sync. status:该字节用来表示车内的DoIP节点是否已经完成了VIN或GID的同步(如何同步后文详述)。定义如下;

        作为车辆信息响应报文使用时,该报文的目的端口为UDP_TEST_EQUIPMENT_REQUEST。
        该报文的第二个用途是作为车辆声明报文(Vehicle announcement),标准规定,当一个DoIP节点成功获取到IP地址后,应在500ms内发送3条车辆声明报文,向网络中的所有DoIP节点广播自己的车辆信息,这时数据部分的定义和上面相同,发送时使用UDP,IP地址设置为255.255.255.255。实际应用过程中发送时间和发送报文数目可能会根据实际情况有所调整。

        作为车辆声明报文使用时,该报文的目的端口为UDP_DISCOVERY。

⑥ 0x0005:Routing activation request


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

        路由激活请求报文由外部诊断设备发送,目的端口为TCP_DATA,源端口可动态定义。报文的数据格式如下:

        数据共11字节,包含以下内容:

        源地址(SourceAddress):外部诊断设备的逻辑地址,与诊断通信中的逻辑地址相同。这个逻辑地址用于对某个特定的DoIP节点进行寻址,与UDSonCAN中的CAN ID是类似的概念,是在网络架构设计阶段就分配好的。标准中的范围划分如下图所示,其中红色框内的范围用于诊断设备的逻辑地址,0x0E00-0x0E7F用于OBD诊断,0x0E80-0x0EFF用于增强型诊断。蓝色框内的逻辑地址用于DoIP节点,与UDSonCAN类似,节点的逻辑地址有两个,一个是物理逻辑地址,在0x0001-0x0DFF或0x1000-0x7FFF范围内,另一个是功能寻址,是0xE000。

        激活类型(activation type):用于诊断设备通知被诊断DoIP节点进入哪种类型的诊断状态。定义如下:

         剩余字节为保留或自定义字段,一般没有作用。

⑦ 0x0006:Routing activation response

        DoIP节点收到诊断设备的路由激活请求报文后,建立TCP连接,并返回该路由激活响应报文,源端口为TCP_DATA,目的端口为诊断设备动态定义的端口。路由激活响应报文的数据格式如下:

        响应中的参数定义如下:

        诊断设备逻辑地址(Logical address of the external test equipment):就是路由激活请求报文中的诊断设备逻辑地址。
        DoIP节点逻辑地址(Logical address of the responding DoIP entity):也就是我们上文说的DoIP节点物理逻辑地址。
        路由激活响应码(Routing activation response code):1字节,用来表示TCP连接建立是否成功,以及不成功的原因。定义如下表所示,Required Action栏展示了DoIP节点在返回响应后应该采取的操作。

其余字段为预留或自定义字段,不常用。


⑧ 0x0007:Alive check request

        
        诊断仪在线检查报文,用于DoIP节点检查诊断设备是否还处于连接状态。该报文由DoIP节点在与诊断设备建立了TCP连接后用TCP_DATA端口发送,不携带DoIP数据,报文中只有DoIP报头。

⑨ 0x0008:Alive check response
        诊断设备在收到DoIP节点发送的诊断仪在线检查请求报文后,发送该响应报文,数据中携带两字节的诊断设备逻辑地址:

        此外,诊断设备也可以在没有收到请求报文的情况下向DoIP节点发送该响应报文,以通知DoIP节点诊断设备仍然在线。

2. 状态信息获取报文


① 0x4001:DoIP entity status request


        该报文可以被诊断设备用来请求DoIP节点的状态,报文数据段没有数据。

② 0x4002:DoIP entity status response


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

③ 0x4003:Diagnostic power mode information request


        该报文可以被诊断设备用来请求DoIP节点的电源模式信息,报文数据段没有数据。

④ 0x4004:Diagnostic power mode information response


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

3. 诊断报文


        诊断报文有三个: 0x8001-0x8003:Diagnostic Message and Positive/Negetive Acknowledgment,我们先把三个放在一起看。DoIP诊断通信流程和CAN不一样,CAN是一条诊断请求对应一条诊断响应,但DoIP遵循如下流程:

        诊断设备发送一条诊断请求(0x8001-Diagnostic Message),该请求中搭载了UDS诊断数据,DoIP节点收到后先对DoIP报头、诊断数据长度等做判断,先返回一个DoIP层的响应,如果各个条件都满足,则返回肯定响应(0x8002-Diagnostic message positive acknowledgment),否则返回否定响应(0x8003-Diagnostic message negative acknowledgment)。

        当DoIP节点返回肯定响应后,再将诊断请求报文中搭载的UDS诊断信息上报给UDS应用程序进行处理,处理完成后,不论是UDS肯定响应还是UDS否定响应,都用诊断报文(0x8001-Diagnostic Message)将UDS诊断响应数据发送给诊断设备。至此一次诊断数据交互才完成。

        流程示意图如下图所示:

        我们再分别来看一下三种诊断报文的数据段定义。

① 诊断报文(0x8001-Diagnostic Message)

        包含两字节诊断报文发送方源逻辑地址,和两字节接收方目的逻辑地址,以及UDS诊断数据。UDS诊断数据可以是UDS请求,也可以是UDS肯定响应和否定响应。

        以下是一条包含UDS诊断请求数据的DoIP诊断报文示例:

 

② 诊断肯定响应报文(0x8002-Diagnostic message positive acknowledgment)

        同样包含发送方和接收方的逻辑地址,还有一字节响应码,以及诊断请求报文中的诊断数据,以便于分析原因。响应码应置为0x00,具体定义如下:

③ 诊断否定响应报文(0x8003-Diagnostic message negative acknowledgment)

        与肯定响应报文的区别就是响应码变成了否定响应码,用来指示否定响应的原因,定义如下:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
DOIP(Diagnostics over Internet Protocol)是一种用于车辆诊断的通信协议,它使用以太网作为媒介,实现车载网络与诊断设备之间的数据通信。在车载以太网诊断中,边缘节点起到了路由数据的关键角色,因此对边缘节点的路由策略进行分析十分重要。 首先,边缘节点作为车载网络与诊断设备之间的桥梁,需要具备较强的路由功能,以确保数据能够快速准确地传输。因此,在设计边缘节点的路由策略时,需要考虑以下几个因素: 1. 网络拓扑:边缘节点需要了解整个车载网络的拓扑结构,包括各个节点之间的连接方式、节点的位置等信息。这样,边缘节点才能根据实际情况选择最优的数据传输路径。 2. 通信性能:边缘节点应该根据不同节点间的通信性能选择最佳的路由策略。如果有些节点之间的传输速度较快,可以直接通过较短的路径进行通信;而对于通信速度较慢的节点,可以选择通过其他节点进行中转,以提高整体的通信效率。 3. 可靠性:边缘节点的路由策略应考虑网络的可靠性,即当某个节点发生故障时,是否能够自动寻找备用路径。这样可以确保即使某个节点出现问题,车载网络的连通性也能够得到保障。 总之,车载以太网诊断中的边缘节点的路由策略分析需要综合考虑网络拓扑、通信性能和可靠性等因素。只有通过合理的路由策略,才能确保车载网络与诊断设备之间的稳定高效的数据传输。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

龍师兄

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值