汽车诊断技术概述

汽车诊断技术是用于检测和解决汽车故障的技术。

诊断常采用问答模式，它通过与汽车的电子控制单元（ECU）进行简单的问答交互来检测故障。在这种模式下，诊断设备向汽车发送一个特定的问答报文，请求ECU提供相关的诊断信息。然后，ECU根据请求返回相应的报文，其中包含了故障代码、传感器数据等信息。诊断设备根据接收到的报文解析并分析故障信息，从而确定故障原因和解决方案。

问答报文是在汽车诊断过程中用来交换信息的特定格式的数据。它通常包含了以下几个部分：

1. 报文ID（Command ID）：用于标识该报文的类型和目的。
2. 报文长度（Message Length）：指示报文的长度，以确保正确接收和解析。
3. 数据字段（Data Field）：包含了特定的诊断信息，如故障代码、传感器数据等。
4. 校验和（Checksum）：用于验证报文的完整性和准确性。

报文的含义根据其报文ID的不同而有所不同。例如，诊断设备可以发送一个报文请求故障码信息，而ECU则会返回一个包含故障码的报文。诊断设备可以根据这些故障码来确定故障的具体原因，并采取相应的修复措施。

诊断术语

1. 客户端：在汽车诊断中，客户端是指连接到汽车电子控制单元（ECU）的诊断设备，通常是一个便携式或台式诊断仪。客户端用于与ECU进行通信，发送诊断指令并接收返回的数据。

2. 服务端：服务端是指安装在汽车上的电子控制单元（ECU），它控制着汽车的各个系统和子系统，例如发动机控制模块、制动控制模块等。服务端负责接收来自客户端的诊断指令，并根据指令执行相应的操作，同时将结果返回给客户端。

3. 远程客户端：远程客户端是指可以通过互联网或其他远程连接方式与汽车ECU进行通信的诊断设备。远程客户端可以通过远程访问汽车的诊断系统，进行远程监控、编程、诊断等操作，无需直接接触汽车。

4. 服务器：在远程诊断中，服务器是指承载远程客户端和汽车ECU之间通信的中间设备。服务器充当数据传输和转发的角色，接收远程客户端发送的指令，将其转发给汽车ECU，并将返回的数据传递给远程客户端。

5. 肯定响应：在汽车诊断中，肯定响应是指当汽车ECU成功接收到客户端发送的诊断指令并完成相应操作后，向客户端返回的确认信息。肯定响应通常包含执行结果、状态信息等。

6. 否定响应：否定响应是指当汽车ECU无法执行客户端发送的诊断指令时，向客户端返回的错误信息。否定响应可以包含错误代码、错误描述等，用于告知客户端指令执行失败的原因。

OBD诊断

OBD（On-board Diagnostics）是指车辆上的自动诊断系统，可以帮助检测和解决汽车故障。OBD诊断是通过与车辆的电子控制单元（ECU）进行通信，读取和解码车辆的故障码，从而确定车辆存在的问题。

OBD诊断系统通常包括两个部分：OBD扫描工具和OBD接口。OBD扫描工具是一种便携式设备，可以与车辆的诊断接口连接，并通过与ECU通信来读取和解码故障码。OBD接口是一个标准的16针插座，通常位于车辆驾驶室的仪表盘下方。通过将OBD扫描工具插入OBD接口，用户可以轻松地进行诊断。

OBD诊断可以帮助车主或技师快速定位车辆存在的问题，节省了查找故障的时间和精力。OBD系统可以检测和诊断多种汽车系统，包括发动机、变速器、刹车系统、空调系统等。它可以读取和显示故障码，提供故障码的含义以及建议的修复方法。

除了故障码，OBD诊断还可以提供其他有用的信息，如传感器数据、实时性能数据、燃油经济性等。这些信息可以帮助车主监测车辆的状况，并及时采取必要的维修措施，以防止潜在的故障。

总的来说，OBD诊断是一种方便快捷的汽车故障诊断方法，可以帮助车主或技师快速准确地定位车辆故障，并提供有用的修复建议，从而提高汽车维修的效率和准确性。

CAN诊断协议

CAN（Controller Area Network）诊断协议是一种在汽车领域广泛使用的网络协议，用于汽车电子控制单元（ECU）之间的通信。它是一种串行通信协议，能够实现高速、可靠的数据传输。

CAN诊断协议基于OSI（Open Systems Interconnection）参考模型中的物理层和数据链路层。它定义了数据传输的帧格式、错误检测和纠正机制，以及节点之间的通信规则。CAN诊断协议采用了分布式的网络结构，每个ECU都具有一个唯一的标识符，用于识别和区分不同的节点。

在CAN诊断协议中，数据传输以帧的形式进行。每个帧包括一个标识符、数据和一些控制信息。发送方将数据封装在帧中，并通过CAN总线发送给接收方。接收方根据标识符判断帧的优先级，并进行相应的处理。

在汽车中，OSI分层是一种将汽车系统划分为不同层级的架构。它涵盖了从硬件到软件的所有层级，以实现分层的协作和交互。常见的OSI分层如下：

1. 物理层：负责传输数据的物理媒介和数据编码。例如，CAN总线用于在ECU之间传输数据。

2. 数据链路层：负责将物理层传输的数据划分为逻辑帧，并进行错误检测和纠正。CAN诊断协议中的帧格式和错误检测机制就是在数据链路层实现的。

3. 网络层：负责数据包的路由和转发。在汽车中，网络层通常由ECU之间的通信协议实现。例如，CAN诊断协议就是在网络层定义的。

4. 传输层：负责数据传输的可靠性和流量控制。在汽车中，传输层通常由更高层的协议来实现，例如TCP（Transmission Control Protocol）。

5. 会话层、表示层和应用层：负责完成特定的功能和任务。在汽车诊断中，会话层通常由诊断工具和车辆之间的通信协议实现，表示层和应用层则负责解析和处理收到的数据。

通过OSI分层，不同的汽车系统可以独立开发和维护，提高了整个系统的可靠性和灵活性。同时，它也为汽车诊断提供了统一的架构和标准。

诊断周期

汽车诊断技术在汽车开发、制造、售后周期中具有广泛的应用。下面是对其在各个阶段的使用进行的简要介绍：

1. 汽车开发阶段：在汽车开发过程中，诊断技术被广泛应用于车辆原型的调试和验证，以确保车辆系统的正常运行和性能。它可以帮助工程师识别和排除系统故障，优化系统参数，提高车辆的安全性、可靠性和性能。

2. 汽车制造阶段：在汽车制造过程中，诊断技术用于测试和检查车辆组装、安装和连接过程中的潜在问题，确保汽车在生产线上的质量和可靠性。它可以帮助检测和纠正装配过程中的错误和故障，并提高生产效率和质量控制水平。

3. 汽车售后阶段：在汽车售后服务中，诊断技术是维修和维护车辆的重要工具。它可以通过连接车辆的电子控制单元（ECU）和传感器，读取和分析车辆的故障码和传感器数据，以确定车辆的故障原因，并提供相应的维修方案。此外，诊断技术还可以进行远程诊断，通过互联网与车辆和维修技师进行远程通信和故障诊断，减少维修时间和成本。
   

UDS诊断服务

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议，在ISO 14229中规定。它是从ISO 14230-3（KWP2000）和ISO 15765-3协议衍生出来的。“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止，这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能，包括电控燃油喷射系统（EFI），发动机控制系统，变速箱，防抱死制动系统(ABS)，门锁，制动器等。

诊断工具与车内的所有控制单元均有连接，且这些控制单元均启用了UDS服务。不同于仅使用OSI模型第一层、第二层的CAN协议，UDS服务使用OSI模型的第五层和第七层（会话层和应用层）。服务ID（SID）和与服务相关的参数包含在CAN数据帧的8个数据字节中，这些数据帧是从诊断工具发出的。

目前市面上的新车都具有用于车外诊断的诊断接口，这使得我们可以用电脑或诊断工具（业内称为测试器Tester）连接到车辆的总线系统上。因此，UDS中定义的消息可以发送到支持UDS服务的控制器（业内称ECU）。这样我们就可以访问各个控制单元的故障存储器或用新的固件更新ECU的程序。除此之外，UDS还用于下线检测时把一些信息（如VIN码）写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。
为什么我们要设计UDS这样的诊断协议呢？在汽车诊断协议诞生之前，修车只能靠师傅的经验，因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后，一旦零部件出了问题或者出过问题，它们会把故障信息保存在内存里面，维修师傅就可以通过通信总线读取这些故障信息，比如一个ECU经历欠压故障之后，它会将欠压故障代表的DTC（诊断故障码）存储起来，可选择性保存的还有发生故障时的快照信息（比如此时的车速、读到的电压值等）。快照信息有助于测试工程师和售后技师查找发生故障的原因。

除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, Internet 和K-line）上实现。

如下图所示，ISO 14229也就是UDS协议仅对应用层、会话层做出了定义。这里有个疑问，UDS专指ISO 14229-1吗？这种说法是不对的，UDS包含了ISO 14229下属的7个子协议，其中ISO 14229-2还是会话层的，所以UDS仅包括应用层的说法也是错误的。

UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。

Diagnostic Request和Response

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。

请求的格式如下：

1. 有sub function的诊断请求 service ID+ sub-function+parameter
2. 无sub function的诊断请求 service ID+parameter
   SID(service id)诊断服务ID,表示诊断服务的功能，长度为1字节。sub-function子功能，表示诊断服务的具体操作，长度为1字节。parameter参数，表示诊断服务的执行条件
   响应的格式如下：
   Response SID +Sub-function+Parameter
   肯定响应：response SID是诊断请求的echo,值为SID+0x40
   否定响应：固定三个字节，分别是0X7F,请求SID,响应状态码
   

通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。

UDS的寻址模式分两种，一种是物理寻址（点对点、一对一），根据物理地址的不同进行访问，但只能访问单个ECU节点，Tester为SA源地址，ECU作为TA目标地址；对应的，另一种是功能寻址（广播、一对多），根据功能的不同进行访问，它能访问多个ECU节点，对于标准帧来说，通常是0x7DF。

每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息，0x709对应发给Tester的消息。

诊断服务介绍

1. Diagnostic session control (诊断会话控制)

• SID: 0x10
• 诊断服务名: DiagnosticSessionControl
• 服务service: 0x10
• Sub function:
  • 0x01：默认诊断会话
  • 0x02：编程会话
  • 0x03：扩展会话
  • 0x04：生产线模式
• 请求报文：0x10 0x02 (编程会话的请求报文)
• 响应报文：
  第一部分是0x50，是SID的响应echo；
  第二部分是进入的Session，作为Sub-function的响应echo;
  第三部分是4个字节，前两个字节代表P2Server_max,即ECU在应用层上对诊断命令的响应时间，后两个字节代表P2max，即ECU在暂时无法处理当前诊断命令，在应用层上对诊断命令响应的最长时间。

2. Tester Present (诊断工具存在性)

• SID: 0x3E
• 诊断服务名: TesterPresent
• 服务service: 0x3E
• Sub function: 无
• 请求报文：0x3E 0x00

TesterPresent用于告知ECU之前己经激活的诊断服务功能可以仍然保持激活状态。UDS中最简单的诊断服务，永远只有两个字节组成。

3. ECU Reset (ECU复位)

• SID: 0x11
• 诊断服务名: ECUReset
• 服务service: 0x11
• Sub function:
  • 0x00：硬件复位
  • 0x01：执行软件复位
  • 0x02：热复位
• 请求报文：0x11 0x01 (执行软件复位的请求报文)
• 响应报文：0x51 (执行软件复位的响应报文)

ECUReset用于ECU重启。Request固定为2个字节，第一个字节是SID，第二个字节的低7bit是Sub-function,用于表示ECU的重启模式。

4. Security access服务 (安全访问服务)

• SID: 0x27
• 诊断服务名: SecurityAccess
• 服务service: 0x27
• Sub function:
  • 0x01：Seed Request
  • 0x02：Key Send
  • 0x03：Seed & Key Request
  • 0x04：固定密钥
• 请求报文：0x27 0x01 (Seed Request的请求报文)
• 响应报文：0x67 XX XX … (Seed Request的响应报文，其中XX代表种子值)

SecurityAccess用于身份验证。身份验证的步骤是：

	1. 诊断仪向ECU请求"Seed"
	2. ECU向诊断仪发送“seed"
	3. 诊断仪向ECU发送“
	4. ECU判断诊断仪发来的“Key"是否有效

UDS诊断-0x27安全访问服务先执行2701请求加密种子，然后执行2702通过dll文件加密后，将加密信息发送到ECU进行对比，校验通过，解锁安全访问等级1。如果需要写入信息，继续执行2703，2704，解锁安全访问等级2用来写入操作。

5. Communication control服务 (通信控制服务)

• SID: 0x28
• 诊断服务名: CommunicationControl
• 服务service: 0x28
• Sub function:
  • 0x00：启用通信
  • 0x01：禁用通信
• 请求报文：
  第一部分SID,一个字节，值为0x28；
  第二部分Sub-function,一个字节，表明对ECU的通信的控制模式，
  第三部分CommunicationType,一个字节，表明对报文名的控制类型，第四部分可选项。
• 响应报文：0x68 (启用通信的响应报文)

6. Read Data by Identifier服务 (通过标识符读数据)

• SID: 0x22
• 诊断服务名: ReadDataByIdentifier
• 服务service: 0x22
• Sub function: 无
• 请求报文：0x22 XX XX … (读取标识符为XX XX …的数据的请求报文)
• 响应报文：0x62 XX XX … (读取标识符为XX XX …的数据的响应报文，其中XX代表数据值)

7. Write Data by Identifier服务 (通过标识符写数据)

• SID: 0x2E
• 诊断服务名: WriteDataByIdentifier
• 服务service: 0x2E
• Sub function: 无
• 请求报文：0x2E XX XX YY YY … (将数据值YY YY …写入标识符为XX XX …的数据的请求报文)
• 响应报文：0x6E (写入数据的响应报文)

8. Clear Diagnostic Information服务 (清除诊断信息)

• SID: 0x14
• 诊断服务名: Clear Diagnostic Information
• 服务service: 0x14
• Sub function: 无
• 请求报文：
  Clear Diagnostic Information删除存储ECU中的DTC。
  第一个部分，一个字节，是SID;
  第二个部分，三个字节，标识将要被删除的DTC种类。
  14 FF FF FF删除掉ECU中的所有DTC。
• 响应报文：0x54 (清除诊断信息的响应报文)

9. Read DTC服务 (读取故障码)

• SID: 0x19
• 诊断服务名: ReadDTCInformation
• 服务service: 0x19
• Sub function: 无
• 请求报文：
  Read DTC Information表示读取存储在ECU中的DTC。
  第一个部分，一个字节，是SID;
  第二个部分，一个字节，是子服务。
  常用子服务有：
  01 读取符合掩码条件的DTC数量，
  02 读取符合掩码条件的DTC列表及其状态。
  04 读取快照信息
  06 读取扩展信息
  第三个部分，四个字节，是DTC信息。
• 响应报文：0x59 XX YY ZZ … (读取当前故障码的响应报文，其中XX代表故障码个数，后续的YY ZZ …代表具体的故障码)

诊断文件CDD介绍

CDD（CANdela Diagnostic Description）是一种描述汽车通信网络中诊断协议的文件格式。它指定了汽车的诊断要求和通信机制，以便汽车制造商、诊断工具供应商和诊断测试工程师可以进行正确的诊断和故障排除。

CDD文件中包含了诊断服务、诊断数据、统一诊断通道（UDS）以及其他相关参数的描述。它提供了用于交换诊断相关信息的格式约定，从而确保不同供应商的诊断工具和设备之间的兼容性和互操作性。

诊断安全访问服务(security Access)介绍

汽车诊断安全访问服务（Security Access）是一种保护汽车诊断系统的安全机制，它可以限制对一些关键操作的访问权限，确保只有授权的人员（例如经过授权的技术人员）才能执行特定的诊断任务。

通过使用Security Access，车主可以对诊断设备进行身份验证和授权，以获得访问受保护的功能和设置的权限。这可以防止未授权的人员对车辆进行非法访问和操作，保护车辆和车主的安全。

与Security Access密切相关的是security dll文件，它是一种动态链接库（DLL），用于提供和管理汽车诊断系统的安全访问功能。该文件包含一些加密算法和安全验证协议，可以对诊断设备和车辆之间的通信进行加密和身份验证。通过security dll文件，诊断设备可以发送安全令牌和验证信息给车辆，以获取访问受限功能的权限。

如何在Canoe UDS诊断实战

CANoe 开启诊断功能

以下项目是松勤培训中的案例，可供大家参考

1. 打开诊断功能
   
2. 添加CDD文件
   
3. 设置请求和报文的CAN ID
   

在Canoe诊断中，UDS（Unified Diagnostic Services）和CDD（Communication Data Description）是用于车辆通信的标准协议。设置请求和报文ID的目的如下：

1. 请求的目的：
   在UDS诊断中，请求是指发送给诊断目标（例如ECU或控制单元）的指令。设置请求ID的目的是明确诊断目标的地址或身份，确保请求被正确地发送到特定的目标单元。通过设置请求ID，系统可以识别出需要执行诊断命令的特定ECU或控制单元。
2. 报文ID的目的：
   在Canoe诊断中，报文ID用于区分不同的CAN（Controller Area Network）报文。CAN是一种常用于车辆通信的总线协议，可以传输车辆各种控制信息和诊断数据。每个CAN报文都有一个唯一的报文ID，用于标识此报文的内容和发送者。设置报文ID的目的是确保CAN总线上传输的数据能够被正确地接收和解析。
   总而言之，设置请求和报文ID的目的是确保在Canoe诊断中，请求和报文能够准确地发送到目标单元并被正确识别，从而实现有效的诊断和通信。

4. 添加DLL文件
   

在CANoe诊断中使用UDS CDD诊断时，添加Seed&Key动态链接库（DLL）文件的目的是为了提供支持诊断通信中Seed&Key机制。Seed&Key是一种用于访问和修改模块内部数据的保护机制，特别在安全相关的诊断操作中使用。
通过添加Seed&Key DLL文件，CANoe能够模拟Seed&Key挑战响应流程，以验证诊断通信的安全性。这包括生成Seed（种子）并向ECU发送Seed，然后ECU根据Seed计算出Key（密钥）并发送回CANoe，CANoe再验证并对密钥进行计算。

5. 打开IPC开启诊断
   

Canoe 诊断实战

1. 开始运行项目
   
2. 打开诊断的Trace便于诊断的调试
   
3. 点击IPC项目中的variant Coding Write，并运行
   
   如上图片中所示，报出 7F 2E 33的错误，其中7F是固定位，2E代表诊断服务SID,最后一位位错误码33，错误码列表所示，33表示不满足安全策略。
   
   此时发起解锁的服务，重新操作，此时返回的是positive response
   
   代表2E的请求成功，返回了6E 03 01(2E+40),表示对写入的日期进行了正响应。