系列文章目录
C++技能系列
Linux通信架构系列
C++高性能优化编程系列
深入理解软件架构设计系列
高级C++并发线程编程
设计模式系列
期待你的关注哦！！！
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
以太网诊断协议DoIP
诊断无论是从主机厂还是供应商，无论是从上层设计还是从顶层设计来说，诊断都是必不可少的，比如CAN诊断、LIN诊断、以太网诊断。
无论研发还是售前、售后都是需要诊断的，比如ECU的升级和刷写、4S店的升级刷新、OTA升级等。
1.1 诊断功能作用
（1）识别、检查、确认车辆状态
（2）提供车辆维护、维修、更新数据
1.2 车辆诊断方法
（1）本地诊断（比如4S店人员用OBD读取ECU信息，升级刷写）
（2）远程诊断（比如通过云端远程诊断）
（3）仪表显示（比如车辆仪表盘指示灯的显示胎压不足）
1.3 诊断功能发展历史
| 时间 | 协议 | 描述 |
|---|---|---|
| 1996 | ISO9141-2 | CARB Requirements for Interchange of Infomation |
| 1999 | ISO14230 | Keyword Protocol 2000 |
| 1999 | ISO/DIS15765 | Diagnostics on CAN - base on KWP2000 |
| 2001 | ISO15031 | Communication for emissions-related diagnostics |
| 2001 | ISO15765 | Diagnostics on CAN - base on UDS |
| 2006 | ISO14229 | Unified Diagnostics Services (UDS) |
| 2013 | ISO14229 | Unified Diagnostics Services (UDS) |
1.4 车辆诊断功能协议
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通讯协议。简单来说，可以理解为UDS诊断协议就是ISO 14229协议，在ISO 14229协议中定义了UDS服务用法、服务格式等信息。UDS诊断最主要目的是为了能够快速准确判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。
UDS-ISO：14229标准
| ISO14229 | Unified Diagnostics Services (UDS) |
|---|---|
| ISO14229_1 | Specification and requirements - 定义了诊断服务，只有应用层，不涉及网络及实现。 |
| ISO14229_2 | Session layer services |
| ISO14229_3 | Unified Diagnostics Services on Can implementation（UDSSonCAN）- 定义了UDS在CAN总线上的实现 |
| ISO14229_4 | Unified Diagnostics Services on FlexRay implementation（UDSSonFR） |
| ISO14229_5 | Unified Diagnostics Services on IP implementation（UDSonIP） |
| ISO14229_6 | UDS on K-Line implementation（UDSonk-Line） |
| ISO14229_7 | UDS on Local interconnect network（UDSonk-LIN） |
诊断协议是用于汽车行业诊断通信的需求规范，由ISO-14229系列标准定义。应用于OSI七层模型的应用层(第7层)，它只规定了与诊断相关的服务需求，并未涉及通信机制，所以，它可以在不同的汽车总线(例如CAN,LIN,FleXRAY,Ethernet和K-line)上实现。
在使用ISO-14229时，下面的通信机制可以改变，比如基于CAN，基于LAN，基于FlexRay等。诊断通信过程其实很简单，诊断仪发送诊断请求(request)，ECU给出诊断响应(response)，而UDS就是为不同诊断功能request和response定义统一的内容和格式。
1.5 诊断功能通信要素
-
服务 Service
UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）
-
会话Session
可以理解为某种诊断模式或权限，即在不同的模式下，对不同的诊断服务的使用做了限制。
| 功能码 | 说明 |
|---|---|
| 1 | Defaut Session |
| 2 | Pograming |
| 3 | Extended |
- 故障码DTC
1.6 诊断功能通信流程
其实诊断通信的机制很简单，事件驱动型，一问一答。
类比client-server通信方式，诊断仪即客户端，发送request，服务器即ECU，收到request之后进行处理，然后向诊断仪回复response。
-
需要确认的服务
-
不需要确认的服务
但是，诊断协议有自己的特色，它规定了request和response的格式，在收到request的时候要做格式检查。同时由于寻址方式的不同，有无sub-function的支持等，也会影响request和response的处理方式和结果。
1.7 DoIP协议
DoIP：Diagnositc communication over Internet Protocol
- 一种用于UDS功能的以太网通信协议
- ISO 13400
1.7.1 DoIP应用场景：
（1）本地一对一
（2）本地多对多
（3）远程一对多
（4）远程混合式
1.7.2 DoIP ISO:13400标准
标准：
ISO:13400_1：定义基本信息和用例
ISO:13400_2：网络层协议、传输层服务
ISO:13400_3：基于802.3，定义线序和接口
ISO:13400_4：定义诊断连接器
ISO:13400_5：一致性测试
1.7.3 DoIP消息格式：
DoIP报文由DoIP报头和Payload（有效载荷）组成，具体如下图所示。
- （1）DoIP报头包含：DoIP协议版本号，目前为0x02（DoIP 2012）。
- （2）协议版本号取反，目前为0xFD。注意：协议书上特别说明了Protocol version可以为0xFF，设这个值的作用是，当客户端和服务端的协议版本不匹配，可以设置此值绕过协议头版本不匹配而拒绝请求的case。
- （3）Payload类型，分为3大类：
①节点管理类，包含DoIP报头否定应答、车辆声明及标识、路由激活、在线检查；
②车辆信息类，包含DoIP实体状态、诊断电源模式信息；
③诊断数据类，包含诊断报文。
关于每个消息类型的含义如下表所示，具体含义参考标准即可。
1.7.4 DoIP通信流程
DoIP通信的4个阶段
（1）物理连接：Tester使用有线或无线的方式与车辆建立连接
物理连接线图：
（2）IP地址分配：静态或动态的分配IP地址，使Tester和车辆可以进行网络通信
- 静态分配：Tester与车辆连接前需配置完成（前期开发测试时可静态分配）
- 动态分配：DHCP协议动态分配IP地址（推荐：外部设备作为服务器，车辆作为客户端发起请DHCP求）
（3）车辆发现：Tester识别并确认被诊断车辆
- 查找识别车辆的过程
- 标识符：车辆VIN、EID、GID等信息
（4）诊断会话通信：Tester与车辆进行诊断功能通信 - 建立TCP连接
- 诊断功能通信
1.7.5 DoIP网关功能
DoIP网关通信流程