什么是汽车的诊断通讯？它和普通模式下的通讯区别在哪里？

临床医师

CAN/LIN等等都算是汽车ECU之间的通讯协议，到底什么才这些ECU的诊断通讯呢？例如，假如在LIn通讯中，BCM作为主节点，天窗控制ECU是从节点，两者之间就能实现通讯，那么这两者之间能实现诊断通讯吗？ 还是说，诊断通讯一定需要诊断设备作为主节点呢？ 诊断通讯的具体协议和普通通讯之间的区别到底在哪里？谢谢
原文地址：https://www.zhihu.com/question/30368583

检验医师

没有这么分的吧？没有诊断模式和普通模式一说。还是说问的是售后维修模式？
诊断是电控功能之一。有一些诊断功能依赖于通讯来实现，比如要从总线上读取一些信息，判断故障情况；通讯情况也是诊断检查的一部分，要检查通讯是否正常。
诊断 汽车电控功能开发进阶

[6 诊断]
同系列文章点击如下链接：
[概述] 汽车系统安全 功能安全 与网络安全
[诊断] 开发者视角的汽车电控功能功能安全和诊断设计
[诊断] 诊断 汽车电控功能开发进阶
[网络安全] 汽车网络安全初识
[5 安全 功能安全] 26262规范解读笔记 11-Part 2 Concept phase
[5 安全 功能安全] 26262规范解读笔记 11-Part 3 Concept phase
[5 安全 功能安全] 26262规范解读笔记 11-Part 4 Product development at the system level
[5 安全 功能安全] 26262规范解读笔记 11-Part 5 Product development at the hardware level
[5 安全 功能安全] 26262规范解读笔记 11-Part 6 Product development at the software level
[5 安全 功能安全] 26262规范解读笔记 18-Part 9 Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses
[5 安全 功能安全] 26262规范解读笔记 18-Part 11 Guidelines on application of ISO 26262 to semiconductors

1 诊断有什么用

本质上来说，诊断是为了搭建一个客户（设计，测试，生产，售后，终端用户）和汽车的一个沟通渠道，让黑盒子的某些功能在某些必要的时候变成白盒、灰盒。
传统的汽车诊断被称为diagnostic，而当前一些先进的OEM已经进化为采用prognostics – predictive diagnostics，即预测型诊断。
如今诊断的方式已经不再限于通过诊断仪的本地诊断，也可以借助网联技术的云端在线诊断，或是基于大数据与故障预测模型进行预测型诊断。

虽然大部分车辆的自动驾驶系统都已经按照功能安全的标准来进行了设计和开发，但要注意，功能安全是保证“人”的安全，而不关注保证车辆功能的可用性与可靠性。也就是说，可能某个系统在单点失效后不对人身产生重大的伤害，但是车辆的某项功能却无法使用了。
一个robust的ECU设计，应该是具备完善的自我诊断策略的，越来越多的主机厂在以hardware review或者是software joint review的形式，要求供应从源头做到这一点。
1.1 OBD on board diagnostic

说到诊断，不知道大家先想到的是什么，可能先想到的两个东西是OBD和DTC，那就从OBD开始说。
诊断，说明有故障，那我们怎么知道故障是什么呢。
就要从OBD口读。
这个OBD口是个什么东西呢？OBD我们都知道是on board diagnostic。
它最开始的时候是监控可能导致排放问题的一些故障
后来电控功能越来越多，就增加了很多其他监控。
OBD系统
OBD系统的监控对象是传感器、执行器以及电子控制器本身，通过实时监测与排放相关的部件的工作信号，来判断汽车尾气排放是否超标。
如果某些信号发生异常变化而出现排放超标的现象，系统会判断这一信号相关的部件或电路出现故障，点亮故障指示灯（MIL）并将对应故障码存入内部数据。故障信息可以通过诊断仪来读取。
作用
排放控制- 开发 OBD 的最大原因之一是帮助减少车辆排放。OBD系统通过监控主要发动机部件的性能，来帮助解决可能导致排放增加的任何系统故障。OBD系统会监控主要引擎部件的性能，检测是否出现了能导致排放增加的系统错误，并协助控制排放。OBD在这一领域非常有用，以至于它被纳入EPA 关于实施清洁空气法案的文献中。
电子组件：随着电子燃油喷射的普及，越来越多的电子设备在汽车中变得司空见惯，从而增加了对更复杂的监控系统的需求，以帮助更准确地识别问题。
使用
可用专用的诊断工具读取汽车存在的故障码，故障发生时间、里程、故障发生次数等重要参数，方便快速了解问题
1.2 DLC diagnostic link connector

车上有了OBD系统之后，我们就可以通过DLC端口去访问
这个端口一般在驾驶员侧仪表板下方。
通常诊断口有如下作用：功能监控，错误检测，记录，存储故障信息，读取数据。


1.3 DTC（diagnostic trouble code）

通过这个DLC端口可以读到什么东西呢？
通过设备可以读取DCT。
DCT是什么
DTC（Diagnostic Trouble Code 诊断故障代码）为不同故障所对应的“数字码”
为保障车辆行车安全，ECU会进行故障自检， 当产生故障后，会进行DTC置位。
利用诊断仪可以读取出DTC，从而可以判断具体的故障，帮助问题排查。
如果系统检测到了一个错误，它将存储为DTC。DTC可表现为：
一个显而易见的故障；
通讯信号的丢失(不会使故障灯亮起)；
排放相关的故障；
安全相关的错误等。
故障码包括四个大类，分别是PCBU，
P是powertrain动力系统，
C是Chassis底盘，
B是Body车身，
U是network通信系统。
一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码

DTC（Diagnostic Trouble Code 诊断故障代码）为不同故障所对应的“数字码”
如果系统检测到了一个错误，它将其存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。
故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。
DTC可以揭示错误的位置和错误类型。诊断故障代码附属信息包含诊断故障代码状态信息、快照信息和扩展数据。
所以说它是一个代码，有规定的格式，一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。



1.3.1 故障内码 2字节
故障内码：如P0101、C1234、B2236等等
DTC开头的字母表示被监测到的故障系统：
P为动力系统；B为车身系统；C为底盘系统；U为网络或数据通讯传输系统故障码。
1为燃油及空气计量系统；
2为燃油及空气计量系统（特指喷射系统回路功能不良）；
3为点火系统或缺缸监测系统；
4为辅助排放系统；
5为车速控制和怠速控制系统；
6为计算机输出线路系统；
7为变速箱。
1.3.2 状态掩码 1字节
要完全理解DTC状态掩码还需要先理解下面这些概念：
1) Test：在线诊断算法，该算法决定系统的故障状态。一个算法对应于一个唯一DTC，非连续性测试在一个监控周期内仅运行一次，连续测试在每次循环中进行调用，可以是毫秒级的；
2) Failure：系统不能满足功能，则为一个故障。
3) Monitor：可以是一个test也可由多个test组成，用于决定系统故障状态；
4) Monitoring cycle：由设备制造商定义，在这个周期下Test可以运行。当然制造商也可定义其它的周期，只要这个定义满足法规要求；
5) Complete：在当前监控周期内，test决定是否有故障存在的一种指示。(不仅指failed)
状态掩码各个位的含义如下，
bit 0 : testFailed
指示最近执行test的结果，test失败置1，但是它不一定被ECU存储到EEprom中，只有当bit2或bit3被置1时DTC才会被存储。test通过则置0，如果调用了14服务清除DTC的话，也需要重新置0。
bit1：testFailedThisMonitoringCycle
该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时，这个位需要置0，在调用了14服务后也需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。
bit2：pendingDTC
根据ISO 14229的定义，当一个test结束时，若某个DTC满足故障触发条件，则bit2置1。bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，称为待定DTC。因为DTC并不是一达到触发位就会被报出来的，而是故障出现一段时间后才会被确认，而中间的这个状态就用bit2位来表示，因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候，bit2被置1，若一段时间后故障条件不满足了，则bit2置0，若一段时间后故障仍然存在，那么bit3就要置1了。
bit3：confirmedDTC
当bit3置1时，说明故障已经发生了一段时间，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，所以可以理解为历史故障。在调用14服务清除DTC后需要置0。
bit4：testNotCompletedSinceLastClear
因为并不是所有的DTC测试都是从上电就开始的，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。调用完14服务后就是置0的。
bit5：testFailedSinceLastClear
该位表示在上次调用14服务清除后DTC后，若test DTC未进行测试或者测试了但结果是pass时置0，如果test运行完成并且返回结果为fails，那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。
bit6：testNotCompletedThisMonitoringCycle
该位表示在当前检测循环周期过程中DTC test是否完成，若完成了置0，未完成置1。在调用ClearDiagnosticDTC后需要置1。
bit7：warningIndicatorRequested
该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0。
1.4 MIL灯

MIL：MIL灯，malfunction indication lamp，当ECU收集到DTC代码时，它会向车辆仪表板发送信号以打开相应的指示灯，进行车辆故障初步预警。


2 什么是UDS

UDS，unified diagnostic services。汽车行业诊断通信的需求规范，规定诊断相关的服务要求，不涉及通信机制。
电子系统故障的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议。
常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有就是ISO 14229（UDS协议）。
ISO-14229是一个用于汽车行业诊断通信的需求规范，它只规定了域诊断相关的服务要求，没有涉及到通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（ISO-15765），数据链路层（ISO-11898）还有底层硬件实现方式（CAN控制器）。ISO 15765 协议是一种CAN总线上的诊断数据传输协议，主要是基于CAN总线数据的拆箱和装箱。

由于不涉及网络通信机制，因此ISO-14229也称为UDS（Unified Diagnostic Services），在UDS协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。




UDS诊断协议是ISO15765 和ISO14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层。
可在不同的汽车总线（例如CAN, LIN, Flexray, Internet 和K-line）上实现。
UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。
UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据。
OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。
2.1 OSI七层模型

在2013年释放的UDS协议中，除了对通用诊断服务的定义以外，还增加了关于UDS在各个总线中应用的定义。
下图描述了UDS在OSI七层模型中的应用，
比如说我们熟悉CAN总线，物理层和数据链路层遵循的是ISO 11898，而它的传输层遵循的是ISO 15765-2，在ISO 14229-3中定义了UDS基于CAN总线的应用；
而现在比较火的以太网，它的物理层和数据链路层遵循的是ISO 13400-3，它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5；


OSI（Open System Interconnect），即开放式系统互联，一般叫OSI参考模型，是ISO（国际标准化组织）组织在1985年研究的网络互连模型。
OSI模型把网络通信的工作分为7层。
1至4层被认为是低层，这些层与数据移动密切相关。
5至7层是高层，包含应用程序级的数据。每一层负责一项具体的工作，然后把数据传送到下一层。
由低到高具体分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。


2.2 诊断服务

所有的UDS服务都有相同的请求与响应格式。
诊断是通过诊断仪和 ECU 之间的请求和响应完成的，诊断的请求通常是从诊断仪到 ECU，响应则从ECU到诊断仪。
CAN是一种广播式的通信方式，即一条CAN报文发送出去后，在同一条CAN网络中的所有节点都能够收到该条CAN报文。
诊断仪在发出诊断请求报文后，具体是想诊断哪个节点，有两种寻址方式，一个叫物理寻址，另一个为功能寻址。ECU收到诊断请求后，则通过消息的ID区分是物理寻址还是功能寻址，一般功能寻址的信号ID为0x7DF，物理寻址的消息ID为客户自定义，每个ECU都不一样。
物理寻址
诊断仪与单个ECU之间的诊断，即诊断仪通过物理寻址方式发送请求报文时，只有指向的ECU可以回复响应报文；
功能寻址
诊断仪与多个ECU之间的诊断，诊断仪通过功能寻址方式发送请求报文时，同一网络中支持功能寻址的所有ECU都需要回复响应报文。
2.3 $19服务

$19拥有28个子服务(Sub-Function)。（见后图）
常用的子服务有：
0x01
reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC（Diagnostic Trouble Code）数量）
(读取符合掩码条件的DTC数量)(必须支持),后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。在肯定回复时，组合应该是59(19+40) - 01 (子功能) - 09 (本ECU所支持的掩码条件)-01 DTC的格式(ISO14229-1为01) - 00 01 (目前满足条件的DTC有一个)
0x02
reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC）
(读取符合掩码条件的DTC列表及其状态)(必须支持)，后面的参数是DTC状态掩码，解读同上。在肯定回复是，59 - 02(子功能)- 09(本ECU所支持的掩码条件) - XX XX XX ( DTC,车厂定义 ) - 01 (这个故障码怎么了，01表示当前故障)
报文格式及内容
发 送： 19 +02+DTCStatusMask（状态掩码） 正响应： 59+02+DTCStatusAvailabilityMask（ECU支持的状态掩码）+DTC-状态位
0x04
reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的记录数据(快照)如发生某一故障记录DTC时的车速，电源电压状态等）
(读取快照信息)，也叫冻结帧。
为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。

0x06
reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的环境数据，环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。）
0x0A
reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态）
(读取ECU支持的所有DTC列表及其状态)(必须支持)。这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。


















2.3 $14服务 清除DTC

客户端通过该诊断服务清除ECU中存储的诊断信息。
请求格式分为两个部分，
第一部分：请求SID：0x14，占用一个字节
第二部分：groupOfDTC，由厂家自定义，占用三个字节
groupOfDTC为3个FF代表清除所有DTC，$14+FF+FF+FF，标识清除所有DTC

3.2 CRC检错码的工作原理

一般情况，一个由二进制数位串组成的发送序列，可以用一个只含有0和1系数的多项表达式的系数
表示出来，例如：代码1001011对应的多项式为X6+X3+X+1，再如：代码为1010111，则对应的
多项式X6+X4+X2+X+1.
CRC检错码是采用多项式相除的运算方法实现的，如被处理报文的比特序列对应的多项式为P
(X)，收发双方约定的多项式为G(X),用P(X)除以G (X)后，求得余数多项式R(X)，并将多项式R(X)附
加到多项式P(X)的后边，生成M(X)，这样能保证M(X)除以G(X)的余数为0.此时，可以将M(X)作为
发送序列发给接收方.接收方用收到的报文N(X)去除同样的G(X)，如果余数等于0，则说明接收到的
序列与发送的序列一致，接收到的数据没有错误；否则，说明传输过程中出错，由发送端重发，重
新开始CRC校验，直到接收到的数据没有错误为止.

如CAN的CRC，
CRC
 用于进行CRC校验







3 诊断设计

功能开发中需要建立平台化的安全监控框架实现故障监测与故障处理的解耦，通过全面的安全分析识别安全监控所需提供的安全措施，实现以下内容：
故障码设计
异常检测对象管理
异常处理对象管理
异常监测
异常处理
异常发布
异常订阅
异常信息查询
系统资源监控
冗余-类锁步核-比较器
检查点服务
心跳服务
安全动态加载/运行/卸载
通过功能安全技术全面构建安全的环境模型服务，保障，
安全的接收环境数据并分类存储；
安全的数据抽象，确保上行和下行数据进行安全的抽象转换与收发；
安全的数据流，确保所承载节点及算法的启动、加载、部署、调度、编排、运行、退出的安全性。

ECU故障诊断系统

ECU故障诊断系统检测的故障主要有五种类型：
机械/系统故障，以变速箱控制器所涉及的故障为例，像挡位执行器坏了，离合器坏了等故障；
电子电器故障，比如电磁阀或传感器短路，电源电压不在工作范围等故障；
硬件故障，主要指PCB上的器件故障，比如处理器故障，外围芯片故障等；
软件故障，比如死循环， 除零，溢出等故障；
通讯故障， 比如CAN连不上，CAN报文丢失等故障。

故障诊断包括检测，确认和处理3个部分。
故障的确认是指上述检测到“故障”出现多少次或多长时间才算是真正的故障。因为有时可能只是某个信号极其偶尔波动一下，而这种波动对汽车没有影响，这时如果识别为故障，那么就过敏感了，反而会给驾驶员带来困扰。因此，为了规避这样的情况也被识别为故障，那么就提出了debouncing的概念，即通过一次次数或时间的累加，才能确认是否出现了真正的故障。
只有当“故障”出现次数或时间累加到一定的值，才确认故障。当前常用Debouncing算法有基于计数器和基于时间两类，如下所示：总的来说，Debouncing算法原理是：根据检测到“故障”状态（PREFAILED, FAILED, PREPASSED, PASSED）来增减计数器或定时器，只有次数或时间达到阈值，才能确认或消除故障。

如上图所示，当报告的状态是PREFAILED时，计数器或定时器就累加一次；当累加次数或时间到Failed的域值，那么“故障”就被确认。这里会涉及的一些参数需要定义清楚，因此为这些参数将会决定故障需要多长时间确认或恢复，像图中所示的步长和阈值等。比如对于某个故障的确认时间为200ms，计数器每5ms计数一次，假设设定阈值为40，报告状态切换时，计数器总是从0开始计数，那么这时针对故障确认的固定步长设置为1。
总之，不同Debouncing算法的细节处理会不同，可根据实际诊断需求选择适合的Debouncing算法。
当故障被确认，那么车内在线诊断系统一方面将故障码DTC及相关数据存入ECU内部的非易失存储器内；另一方面将对故障进行处理，主要包括点灯策略和故障处理策略。
其中，点灯策略是指根据故障的严重程度决定是否点亮故障指示灯以及点亮何种颜色，以此警示驾驶员故障的存在，而故障处理策略是指根据故障的严重程度决定做怎样的临时处理措施。
比如出现了变速箱高档位损坏故障，那么这时点黄灯，显示变速箱故障，同时限制汽车行驶速度，采用跛行回家模式；或者出现了车窗无法下降故障，那么这时不点灯，此时也不会对汽车行驶有任何限制。
4 相关法规

2018年，SAE发布了JA 6268，这是一个航空和汽车推荐实践（RP，Recommended Practice ），题为 "健康就绪组件的设计和运行时信息交流（“Design and Run-Time Information Exchange for Health-Ready Components.”）"。一个 "Health-Ready"的部件是指一个由供应商交付的部件或子系统，这个部件或子系统被加强了（也许有额外的传感器，可以报告其健康状况，和/或 提供集成信息），以便部件和/或整个车载系统都可以获得其状态信息。

在SAE’s Industry Technology Consortia (ITC) via JA 6268标准中，将汽车诊断分为0~5级的6个层级：

0：有限的车辆报警提示，维修服务是基于定期的维护保养，或当车辆的操作人员或维修工注意到车辆上的相应的故障指示灯或简单的提示设备；

1：使用诊断工具的增强型诊断，通过使用自动化的诊断仪来提取存储于车辆内部的操作参数和诊断码来获取车辆的内部信息，维修服务可以部分基于诊断结果来进行；

2：通过Telematics提供实时的数据，通过基于车辆的远程监测来实时的获取车辆数据，从而可以根据更加完整的问题信息来展开维修保养服务；

3：部件层级的主动提示，操作人员和服务技师能够在故障发生之前获得部件的健康状态（R/Y/G，红黄绿），实现有限的基于条件（Condition-Based）的维修保养；

4：IVHM，集成式车辆健康管理，操作人员和服务技师能够在故障发生之前获得系统或车辆层级的整体健康指示信息，并可以估计剩余的使用时间，实现基于条件的维修保养；

5：自适应的健康管理，通过获取潜在的或实际的故障信息来实现自适应的控制和优化，从而能够延长车辆的使用，并增强安全性。

感恩由您

当前车载以太网得到了大范围应用，但出于成本、可靠性等综合因素的考虑，CAN和LIN仍大范围应用于车载总线中，CAN和LIN之间的信息交互的需求仍然很大，承载着CAN-CAN，CAN-LIN之间信息路由的“网关”，可能不再是独立的物理实体（单独网关控制器），但对应逻辑实体依然发挥着十分重要的作用。
诊断路由的作用和路由方式的选择

在研发阶段的诊断测试过程中，我们一般将被测的诊断网段直连至诊断测试设备进行测试，但在成品汽车中，各电子部件之间通过线束直连在一起，而线束由胶皮或其他防护材料包裹，如果车辆已经生产完成或者已经售出，此时想对某个单独的样件进行诊断，我们拆下零件剪开线束再接到诊断仪上进行测试是不现实的。
而如果我们给每部分定义不同的诊断ID，从一条预留出的用于诊断网段发送诊断请求，通过诊断ID判断是对哪个样件进行诊断请求并将该诊断请求通过网关路由到相应的ECU上，之后，样件的诊断响应再通过网关路由回我们预留的诊断线路上。这样，我们只需要预留一条总线，就可以对全车支持诊断功能的ECU进行诊断。而不同的零件的诊断请求和诊断响应通过网关路由的行为称之为诊断路由，如下图。




图 1诊断路由示例

对于需要路由的信息，我们一般有以下几种方式对其路由：
1）直接报文路由
无论源网段的发送模式（事件、周期或者其他形式），网关在从源网段接收到报文后立即将报文路由到目标网段，如果没有收到源报文，则不需要路由。可以改变ID，但不可以改变报文中信号的值、Layout以及DLC，转发速率较快。
2）周期报文路由
在网关路由功能激活状态下，需要周期性的将报文从源网段发送到目标网段的模式称之为周期报文路由。可以改变ID，但不可以改变报文中信号的值、Layout以及DLC。
3）直接信号路由
在此模式下，可以更改报文中的 ID、DLC、信号的布局和长度。网关在从源网段接收到信号后立即路由到目标网段，如果没有收到源信号，则不需要向目标网段路由。
4）周期信号路由
如果需要路由的信号来自多个报文，则可以使用周期信号路由模式。网关将从多个源报文导出的信号重新组合成一个新的目标报文，并以周期方式发送。
对于诊断报文，我们对其进行路由时不需要修改其数据场，同时大部分情况下我们不需要诊断报文在目标网段进行周期性发送（为维持当前会话周期性发送3E 80等情况除外），与此同时，诊断报文对顺序，时效性和报文完整度也有一定要求。因此这种情况下我们对诊断报文采用直接报文的形式进行路由是较为合理的。
诊断路由常见的功能与测试

1）网关诊断网段测试
一般情况下网关最多只有两个网段支持诊断（其中一条用于远程诊断），即我们使用网关本身的诊断请求ID通过不同的网段向网关进行诊断请求，应该有且只有两条网段发送时，DUT才会给予响应，使用其他网段对网关进行诊断请求网关应该不予响应。
网关是路由该网关下支持诊断功能的样件，对于网关自身的请求ID和诊断ID，一般不参与路由且只有规定的至多两路总线可以支持与网关本身进行诊断通讯。
2）网关诊断路由的一致性测试
根据路由表仿真源网段报文，观察我们仿真的源网段的诊断报文是否按照路由表正确地路由（包括ID、DLC、数据场等）。
3）网络数据映射功能
当我们通过诊断将一网段的数据映射功能打开时，此网段的数据能够全部映射到诊断网段，无论它是否在路由表中；当数据映射功能关闭时，此网段的数据停止映射。开启此功能可以很方便的通过OBD功能来读取其他网段上的应用报文、网络管理报文、诊断报文，方便工程师和售后维修人员对总线进行设置和维修。
4) gatewaying-on-the-fly
在诊断消息需要多帧发送的时候，如果存在该功能，路由将在所有数据被接收前就开始转发（当达到指定阈值时），如果我们需要传输的数据量较大，使用该功能可以节省内存和时间。
CAN-LIN等带协议转换的路由

在传统网关的路由中经常涉及到不同传输协议间的路由，例如CAN FD-CAN，CAN-LIN等，我们以CAN-LIN的路由作为介绍。
由于CAN和LIN的传输协议不一致，网关在源网段以CAN的传输层协议接收数据后，在LIN的网段按照LIN传输层协议发送数据。CAN和LIN的报文虽然都是8字节，但由于传输层协议不同， CAN和LIN网段的每帧报文传输的数据内容都是不一致的。此外，由于CAN和LIN的传输速率不一样，CAN网段接收数据后存储在缓存中，在LIN网段按顺序发出。
因此，当我们在作为源网段的CAN上发送一条诊断请求消息时，CAN的诊断消息首先存储在网关的缓存中，等待LIN的调度表执行到0x3C的报文时再从缓存中发出到LIN总线上。
发送和接收过程如下图：



图 3 CAN-LIN诊断路由

其中，虚线箭头代表网关发出的LIN报文头。
小结
随着电子电器架构的升级换代，网关的“型态”和功能特性都呈现了新的变化。但如本文介绍的，其基础的、传统的功能特性会长时间地存在，对其验证测试是很重要的工作。

长长的路

什么是诊断服务？
在还没有诊断服务的时候，如果车辆故障，需要有经验的师傅长时间的摸排查找，费时费力。而车辆的ECU节点有了诊断模块后，就具有了诊断功能，这样车辆如果有了故障，就会自动生成故障代码储存在诊断模块中，然后利用诊断仪就可以读取故障代码，车辆哪个节点出现的哪个故障就一目了然




当然除了通过诊断服务读取故障代码外，还可以通过诊断服务做：




诊断服务车载网络分为四层，物理层、数据链路层、网络层和应用层，诊断服务位于应用层




UDS
Unified Diagnostic Services，统一诊断服务，ISO14229标准规范，是诊断服务的其中一种协议规范，是目前普遍使用的诊断协议

UDS基于CAN通讯诊断，也就是说它的网络层采用CAN网络协议


UDS服务结构为：服务标识符（Service ID） + 子功能（SubFunction）/数据位（DataIdentifier） + 数据(Data)

Service ID
表明了服务类型，由1字节无符号整数表示，从请求和响应的角度看，有三种类型的Service ID

• 请求服务标识符
  格式：x0xx xxxx
  

UDS请求服务标识符的bit6要为0，比如请求读取DTC故障信息的服务标识符是0x19，二进制是0001 1001，bit6就是0

• 肯定响应服务标识符
  

既然有请求，ECU肯定要有响应，而响应又有正负之分格式：x1xx xxxx肯定响应标识符是把请求服务标识符的bit6置为1，其他位不变，比如诊断仪向ECU发送请求读取DTC故障信息的服务0x19，ECU回复肯定响应，就需要把0x19的bit6设为1，就是0101 1001，也就是0x59，从中可以看出，bit6置为1对应成16进制就是加上0x40，所以肯定响应服务标识符就是把请求服务标识符加上0x40

• 否定响应服务标识符
  

当请求的服务ECU不支持，或者请求服务的参数不正确，或者。。。时，ECU需要回复否定响应告知格式：0111 1111可以看出，否定响应服务标识符是一个固定值，0x7F
SubFunction
如果UDS诊断服务支持子功能，子功能参数的第一个字节的bit7是禁止肯定响应指示位，bit7 = 1表示ECU禁止肯定响应，bit7 = 0表示ECU可以肯定响应，比如请求ECU reset服务11 02，02的bit7为0，表示ECU执行复位时回复肯定响应

同花顺

诊断通讯基于CAN一般指UDS通信，遵循UDS协议(ISO15765,ISO14229等)但是广义上也可以指诊断相关的通讯包括用于LIN的等等诊断通讯和一般通讯报文最大的区别是周期和立即帧的区别此外诊断帧在CAN里面的优先级较低
BCM作为主节点，天窗控制ECU是从节点，两者之间就能实现诊断通讯如果是为了满足某诊断功能是可以实现诊断通讯的各个OEM相关内容应该定义有所区别

同花顺

你说的CAN LIN都是指的物理层的通信机制，而诊断属于上层的概念，是一种基于各种物理层通信机制的应用。诊断通信是，外接的设备，也就是各种诊断仪，和ecu进行通信，在整车上的接口就是司机侧脚下位置的obd接口。