今天是2022年7月2日，天气晴朗，魔都难得的好天气。也正好出去玩耍了一圈，简略分享几张美照：
分享一句喜欢的话，避免自己成为高知识低文化的工科男：
“
逝去的从容逝去，重温的依然重温，在沧桑的枝叶间，折取一朵明媚，簪进岁月肌里，许它疼痛又甜蜜，许它流去又流回，改头换面千千万，我认取你一如初见
”
Return to today's topic！
最近在整理DoIP协议中关于DoIP generic header handler中NACK value相关内容，输出点文字作为总结。
DoIP协议是ISO 13400定义相关内容，在整个OSI七层模型中如下图所示：
DoIP协议位于三四层（传输层），其协议定义的目的是保证Tester基于车载以太网，将请求准确无误发送至想要发送的地方，相当于一个传输机制，这点可以类比与车身CAN总线的传输规则——CAN TP,详情可参看如下链接：
文章在公众号：《车载诊断技术》
DoIP定义了车载以太网通信规则，该规则既包括了单个ECU内在实现功能时所需要遵循的逻辑，也定义了整车电子电气架构中车载以太网需要遵循的内容。比如DoIP协议定义了只要边缘节点可与外界Tester通信，其他车内DoIP实体不具备通信条件，但是这样就会造成边缘节点“通信阻塞”，因此也就有了更新版的协议，通过边缘节点安全认证，边缘节点可以作为“路由器”，直接无脑转发DoIP帧内容。
DoIP诊断具体内容格式如下：
将传统以太网帧去掉帧头帧尾，是IP帧格式，再去掉帧头是TCP/UDP帧格式，在TCP/UDP Payload type中包含着DoIP帧，因此在日常进行DoIP测试时（使用CANoe），也可以不直接使用DoIP.dll库，直接用TCP/UDP帧，在其中按照DoIP帧格式添加所需要的内容，也可以直接测试。
在DoIP中不同的Payload type具有不同的功能，几种常用到的如下表格：
其中需要注意的一点，Payload type为0x0007-0008 Alive Check一般发送方是车内DoIP实体，用于检测当前Socket是否处于live使用状态。
关于其处理流程可以参看如下图：
处理的先后顺序表示着对应的处理优先级策略。基于上述途中处理策略，逐步分析下。
-> 首先进行公共头部校验：
1、检查Version字段是否合法？如果不合法，回复NACK 00,并关闭Socket，具体实例参看如下：
解析 0x02表示DoIP Version 2（ISO 13400-2:2012）
2、Payload Type是否支持，如果不支持回复NACK 01,并将该报文信息丢弃。在OEM定义企业级DoIP规范时，会明确定义支持的Payload Type，并不是协议中定义的所有Payload Type都需要支持（这点类同所有的协议，在定义企业级规范时，需要基于自身需求，定义即可），按需定义需求，Software具体实现。
3、如果有效负载长度超过了DoIP实体支持的最大DoIP消息大小，则每个DoIP实体应发送一个通用DoIP报头否定确认消息，NACK代码设置为02，而不考虑当前内存利用率。DoIP支持的最大长度是工程师在使用配置工具按照项目芯片性能和使用需求，配置特定的数据长度。
4、Payload Length是否小于等于当前可用的存储空间，如果小于接着走判断，如果大于，该报文丢弃，NACK代码设置为03。
5、Payload type是否在此Payload Type预期长度范围内，如果不在此定义范围内，NACK代码设置为04。
在其AUTOSAR配置BSW模块时，对于DoIP模块，关于Buffer长度是可以定义的，因此这里面的数据长度（存储空间）是可以直接对比。
以上是关于DoIP generic header handler内容定义分析。
|
