1 诊断服务设计概述

诊断被设计在开发、制造 及维修过程中用来实现特定的功能，如用于软件更新、售后检修、产线EOL等方面。当然，BootLoader及App的侧重点也会略有不同，BootLoader主要的功能为软件的更新，而App功能的目的则是侧重于具体功能模块的诊断、数据保护及IO输入输出等。

BootLoader及App的需要支持的基本服务
BootLoader常用服务：
1)、诊断会话控制服务(0x10): 实现在三种会话模式(默认会话、扩展会话及编程会话)下进行切换；
对于三种会话模式的功能及管里，请参考ISO14229-1
2)、诊断会话保持服务(0x3E): 当控制器切换到扩展会话后，当断开控制器会切换回默认会话，此服务目的就是让其保持在当前会话模式(如扩展会话的某些服务在默认会话下不支持，退回是自然退出)；
3)、控制器复位服务(0x11)： 通过诊断服务使ECU进行复位操作，服务之后会切换值默认会话；
4)、安全访问服务(0x27): 对其它服务或者功能进行保护，避免非法读取、非法改写及非法操作。与安全访问服务进行关联的诊断服务须通过安全访问服务后才能及进行相应的操作；
与Application的安全访问的Level不一样，相应子服务及算法区别
5)、数据读取服务(0x22): 在BootLoader中，数据读取服务主要读取如诊断数据版本、硬件版本等内容，还须读取当前诊断会话(在软件更新中极为重要)；
6)、数据改写服务(0x2E): 通过DID进行数据写入服务，主要写入一些常数等内容，如安全访问常数(OEM用于避免其他非法软件更新)、校验常数等内容；
7)、例程控制服务(0x31): 如字面意思，它由一些列定义好的软件操作，在BootLoader中主要用于数据的擦除、数据的写入及数据校验等；
8)、下载相关服务(0x34、0x36、0x37)： 此三服务对应下载过程——请求下载、数据传输、下载完成退出

Application常用服务：
1)、诊断会话控制服务(0x10): 实现在三种会话模式(默认会话、扩展会话及编程会话)下进行切换；
2)、诊断会话保持服务(0x3E): 当控制器切换到扩展会话后，当断开控制器会切换回默认会话，此服务目的就是让其保持在当前会话模式(如扩展会话的某些服务在默认会话下不支持，退回是自然退出)；
3)、控制器复位服务(0x11)： 通过诊断服务使ECU进行复位操作，服务之后会切换值默认会话；
4)、安全访问服务(0x27): 对其它服务或者功能进行保护，避免非法读取、非法改写及非法操作。与安全访问服务进行关联的诊断服务须通过安全访问服务后才能及进行相应的操作；
与BootLoader的安全访问的Level不一样，相应子服务及算法区别
5)、数据读取服务(0x22): 数据读取服务主要读取如诊断数据版本、硬件版本等内容，还须读取当前诊断会话(在软件更新中极为重要)，以及输出的状态、输入的状态及错误Log等内容；
6)、数据改写服务(0x2E): 写入参数可以选择永久写入及短时参数调整。短时调整如用于标定等可将参数写入RAM，永久写入可以写入EEPROM(断电重启仍保持数据有效性，可以用于功能的使能与禁止等)
7)、IO控制服务(0x2F): 直接控制IO口的输入输出，此功能必须经过安全访问；
8)、例程控制服务(0x31): 如字面意思，它由一些列定义好的软件操作，如检查编程条件、参数学习、位置擦除及EOL模式进入等(三种例程类型，详细见ISO14229-1)；
9)、按地址读取服务(0x23): 此服务读取地址中的数据，建议关联安全访问；
10)、通信控制服务(0x28): 通信控制服务主要用于禁止一些应用报文的发送与接收，用于软件的更新(更新过程中停止所有控制器的应用报文，使得控制器软件更新时总线负载降低)；
11)、DTC控制服务(0x85): 主要用于软件更新过程中，禁止DTC的设置，在禁用应用报文时会造成DTC误报(相关DTC如果存在定义的话)；
12)、诊断信息清除服务(0x14): 清除DTC相关信息，用于检修完成后清除DTC及EOL检测结束时，避免后续检修造成错误判断；
13)、诊断信息读取服务(0x19): 读取DTC相关信息服务包含较多服务(此处不详细介绍)，可以读取冻结帧等详细信息用于更好的故障判断；

2 诊断数据服务DID设计

DID全称为Data Identifier，即数据ID，详细定义定义见14229规范。简单来说，就是给一个编号赋予了特殊含义(如0x4328代表电机状态)，然后服务通过操作这个编号来实现功能(如读取状态、控制电机的动作等)。对于DID的编号具体定义须遵循ISO14229-1，规范中会存在为车辆制造商保留的范围、特殊DID的具体定义。

此处截取了部分表格，详细定义见规范文档。

2.1 据服务(0x22)

通过数据读取服务，可以读取模拟输入和输出信号，数字输入和输出信号，内部数据以及系统状态信息等，具体设计由OEM设计或者认可。
基本格式:
Request: 22 + XXXX(DID)
Positive Response: 62 + XXXX(DID) + 响应参数
Negative Response: 7F+ XXXX(DID) + NRC(否定响应码）

2.1.1 ECU软硬件信息

软件版本信息、硬件版本信息、生产日期、诊断版本信息、标定参数版本信息等内容。
此处可通过DID读取相关信息，用于ECU产线EOL校验信息(这些信息通过产线注入的方式写入特定地址)、OEM的总装产线对于控制器的软件及硬件版本信息验证等。

2.1.2 输出及反馈状态

采集数据输入：
1)、开关输入信号: 模拟开关的状态信息、数字开关状态信息，(推荐使用处理后的信息，不推荐使用AD返回值，换算对于售后并不方便)
2)、输入电流电压信息: 传感器采集信息(位置传感器、温度传感器等)，电流采集值，电压采集值等(推荐使用处理后的信息，不推荐使用AD返回值，换算对于售后并不方便)
功能输出状态:
1)、电机输出状态: 电机输出的方向，至于输出的电压信息(有软件内部给定)
2)、灯负载输出状态: 灯负载的输出状态(可以为功能状态——ON/OFF，或者是输出占空比——针对存在调光要求负载)

2.1.3 私有ECU节点请求信息

ECU可能存在一些私有节点(主要指LIN节点，只与一个ECU存在通信)，因此对于它的输出状态及请求状态均通过信号形式传输。为了确定该节点的输出信息，需要将该节点的请求信息通过DID直观反映，以便检修。
1) 、输出状态信息: 如开关的背光、状态指示灯等的输出状态
2)、输入的请求信息： 开关的请求信息等

2.1.4 错误log信息

车窗丢位置原因、车窗防夹事件、车窗的学习状态等

2.1.5 ECU的运行基础信息

车速，时间，供电电压等等

2.2 写数据服务(0x2E)

数据写入服务可以将数据写入RAM、EEPROM、FLASH内存之中，可以达到临时或者永久改写。

基本格式:
Request: 2E + XXXX(DID) + 写入参数
Positive Response: 6E + XXXX(DID) + 响应参数
Negative Response: 7F+ XXXX(DID) + NRC(否定响应码

2.2.1 功能的使能变量

推荐将功能的使能或禁用变量存储在EEPROM中(并且关联安全访问)，这样可以通过0x2E服务进行功能的调整。
1)、用于功能的使能及调整，永久禁用或使能功能(如一键升窗)；
2)、参数的永久调整，永久改变某功能的配置(如转向灯的闪烁次数)；

2.2.2 参数的临时修改

改写软件某些临时变量的改写，如标定的参数(初始化从FLASH拷贝值RAM)，改写RAM中的值。
1)、临时改变参数的值，可用于标定某些参数

2.2.3 将软件等信息写入FLASH

用于改写一些常数，OEM需要通过自己产线将数据进行写入，避免信息泄露。如安全访问虽然存在算法，但转换算法供应商也知道，如果设置一组常数进行转换，这组常数改变，那么安全访问将对供应上不再透明。同理下载的加密算法都一样。

1)、用于软件更新过程中的改写，只有在软件更新时才会存在FLASH DRIVER；
2)、用于算法一些常数改写，将整车控制器的加密信息对外保密(供应商)；

2.3 输入输出控制(0x2F)

IO控制服务强制在扩展会话下进行，并且推荐关联安全访问，避免非法使用；
在退出扩展会话时需要退出IO控制服务，避免造成正常功能异常。
IO控制服务包括四个子服务，常用的两个子服务为：0x03(短期调整)、0x00(返回控制权)

基本格式:
Request: 2F + XXXX(DID) + 子服务(03/00) + 控制参数
Positive Response: 6F + XXXX(DID) + 子服务(03/00) + 当前控制状态
Negative Response: 7F+ XXXX(DID) + NRC(否定响应码)

2.3.1 高边输出(HSD)控制

高边输出可以通过调整占空比直接控制负载的输出，存在两种控制方式：
1)、直接使用百分比(换算成占空比)进行输出；
2)、两个状态来进行控制输出，输出值由软件内部给定；

2.3.2 桥驱电机输出控制

桥驱多用于电机输出控制，对于电机输出堵转须小心处理，可以通过控制正反传进行输出。最重要的是避免持续输出造成电机损坏，采用两种实现方式：
1)、标定堵转阈值，通过电流回采确定堵转，堵转后停止输出；
2)、给出运行时间限制，超时停止输出；

2.3.3 负载位置控制

某些输出存在位置反馈(如车窗输出)，定义运动至指定位置的DID控制：
1)、直接给定位置，电机运动速度由软件内部给定；
2)、给定输出的占空比以及运动的目标位置；
“需要判断参数范围，配置工具不能配置两个参数的范围”

3 诊断例程设计(0x31)

客户机使用例程服务执行定义的步骤序列并获得任何相关结果。此服务具有很大的灵活性，但典型的用法可能包括以下功能：擦除内存、重置或学习自适应数据、运行自检、覆盖正常的服务器控制策略以及控制服务器值随时间变化，包括预定义的序列（例如，关闭敞篷车顶）。

例程控制存在三个子服务：开始例程(0x01)、结束例程(0x2)、请求例程结果(0x03)

例程控制可分为三种类型：短例程、长例程、持续例程

短例程： 可只支持**开始例程(0x01)**子服务，直接返回例程结果

长例程： 需支持开始例程(0x01)、结束例程(0x2)、**请求例程结果(0x03)**三个子服务，可定义例程时间并在定时结束时自动结束，例程运行中可以通过结束例程(0x02)子服务打断例程运行，例程运行中可以通过请求例程结果(0x03)子服务请求例程状态及结果

持续型例程： 需支持开始例程(0x01)、结束例程(0x2)、**请求例程结果(0x03)**三个子服务，例程运行须通过结束例程(0x02)子服务打断并结束例程运行，例程运行中可以通过请求例程结果(0x03)子服务请求例程状态及结果

3.1 前编程条件检查

在进行更新软件之前需要检查车辆的运行状态，如车速、车辆使用模式等信息，检查结果通过例程返回。
此例程可以设置为短例程类型，该例程只需要支持0x01子服务即可，历程结果通过响应结果进行返回。

3.2 供应商EOL产线

在ECU控制器的生产产线上需要除了必要的校验生产信息之外，还需要对ECU控制器的内部电路进行检测，保证控制器的正常电路功能。

产品的EOL检测为了简化实现逻辑可以复用产品的IO控制进行，DTC可以将某些DTC设置进行禁用以避免在此模式下不必要DTC设置干扰此过程。

对于现在车企为节省成本而推出平台架构，因此对于控制器存在很多配置信息，产线的通用性需要最大的功能配置避免检测到所有的功能。无法避免的可通过定义EOL模式来进行区分，以达到最大的功能检测。

3.2.1 EOL模式定义

EOL模式设定是为了区分正常产品模式，在产品模式下无法覆盖所有的产品配置，定义EOL模式为了避免此类情况(即在EOL模式下可以直接IO控制)。除此之外，内部电路的一些上拉源的控制在产品模式下不应该在产品模式下支持此类功能，通过EOL模式来规避此类问题。

例程定义：
例程类型： 推荐使用持续型例程类型，此例程需要手动开始与结束例程
例程检验： 开始例程时需要进行数据校验，避免OEM误触发此类模式

推荐将此类型的模式标志存储EEPROM，退出EOL模式下时进行擦除(用于休眠唤醒检测时使用)

3.2.2 快速休眠

EOL还需要进行休眠电流的检测、唤醒电流检测等内容。对于正常休眠流程，耗时过长、检测项太多不利于产线使用。

例程定义：
例程类型： 推荐使用短例程类型，此例程只需开始例程子服务(0x01)
例程检验： 开始例程时需要进行数据校验，避免OEM误触发此类模式

3.2.3 重置EEPROM(保证初始状态)

此例程用于重置EEPROM数据，同时可用于产品软件(用于OEM的售后维修或者是产线)，将EEPROM中数值重置为默认值

例程定义：
例程类型： 推荐使用长例程类型，此例程手动开始例程子服务(0x01)、并请求例程结果(0x03)

3.3 OEM的EOL产线

对于OEM产线车型配置信息极为重要，在进行产线检测及产线的学习时需要首先下发产品的配置信息，后续步骤均需要通过产品的配置信息完成检测或者学习。

3.3.1 负载自检(EOL)

该例程主要用于负载的电路连接检测，当检测出电路错误时需要记DTC或者通过DID进行反馈，OEM的产线通过此类信息对相应的负载安装信息进行重新检测以避免产品出现电路质量问题。

例程定义：
例程类型： 推荐使用长例程类型，此例程手动开始例程子服务(0x01)、并请求例程结果(0x03)

请求例程状态，当例程状态为完成后，再次检测自建的结果

3.3.2 学习自适应数据

该例程用于产线的数据自动学习，由软件内部定义好学习序列，在满足学习的条件时，运行例程进行数据学习。

例程定义：
例程类型： 推荐使用长例程类型，此例程手动开始例程子服务(0x01)、并请求例程结果(0x03)

可以将学习结果定义在请求例程结果子服务(0x03)中，在请求例程达到例程完成后，校验例程学习的结果

3.3.3 立即保存状态数据

该例程用于数据的立刻存储，避免由于操作失误直接断电等异常情况造成学习数据丢失，因此对于产线使用此例程可避免此类情况。

例程定义：
例程类型： 推荐使用长例程类型，此例程手动开始例程子服务(0x01)、并请求例程结果(0x03)

可以将学习结果定义在请求例程结果子服务(0x03)中，在请求例程达到例程完成后，校验例程执行的结果

4 诊断故障码DTC设计

诊断故障码涉及车辆的错误状态记录，是售后车辆进行检修的重要部分，好的DTC设计能够为售后节省大量的时间。

4.1 电路故障

常见的电路故障如开路、断电源、短地等，

高边输出： 高边输出检测断电源与开路在输出时不能区分，因此可以使用短地、短电源或开路两种故障类型。对于需要检测出短电源的负载，可以设计在无输出时对高边进行电压回采，并定义短电源故障

桥驱输出： 对于桥驱输出，低边短电源与高边短地都造成过流(在短电源时，总会存在一个边回过流），建议设计两种类型：过流、开路

4.2 逻辑或信号错误故障

预期信号与实际信号的不一致，举一个简单例子：锁命令输出了但无法检测到锁的状态反馈信号，进行了两次Retry均无法达到预期状态。

此类错误详细设计可以与OEM进行协商或者根据标准进行设置。

4.3 通信故障

通信故障包括电路的错误及通信错误，

CAN通信： CAN的物理电路错误、CAN节点离线(Bus Off)
LIN通信： LIN电路错误(短电源、短地)、发送错误、接收错误、报文丢失等

4.4 配置参数错误

OEM趋势时多个车型及硬件都是用一版软件，配置信息对于车辆的正常运行极为重要(配置参数可以通过写死在ECU或者由某个节点下发(OEM产线下发))

没有配置错误： 从接收过配置文件，在接收到配置文件后立即清除DTC(Age)
配置错误/无效： 接收到的配置信息超出范围或者为无效值，在接收到配置文件后立即清除DTC(Age)
配置与硬件不匹配： 配置信息与硬件的版本/变种不匹配，在接收到配置文件后立即清除DTC(Age)

4.5 内存参数错误

写内存校验错误、读内存校验错误等

4.6 开关粘滞错误

对于触发式的开关，常开或者常闭开关，长时间处于错误状态需要设计粘滞故障。

5 快照DID

这类信息，会在DTC设置过程中一同存储在EEPROM(冻结帧)，此类信息可用于故障原因的分析(设计的主要目的)。

5.1 ECU供电电压

在电压过高或过低，会造成DTC的误报等。

5.2 ECU运行时间

记录DTC产生的时间节点等

5.3 与DTC功能相关的信息

这部分内容需要仔细设计，考虑所有可能导致错误的原因

6 组合DID

通过单DID可以读出所需要信息(预先设计)，

6.1 产品信息

产品硬件版本号、软件版本号等内容DID组合成组合DID，通过此组合DID可以读出所需信息

6.2 任意组合

任意想一起读出来的信息，具体依据产品及个人设计

7 安全访问服务

安全访问过程如下图，算法设计应该由OEM提供，对于安全访问应设计常数方便OEM进行修改，避免产品安全对于供应商透明。

最后

以上就是强健御姐为你收集整理的Autosar诊断——诊断模块基础设计1 诊断服务设计概述2 诊断数据服务DID设计3 诊断例程设计(0x31)4 诊断故障码DTC设计5 快照DID6 组合DID7 安全访问服务的全部内容，希望文章能够帮你解决Autosar诊断——诊断模块基础设计1 诊断服务设计概述2 诊断数据服务DID设计3 诊断例程设计(0x31)4 诊断故障码DTC设计5 快照DID6 组合DID7 安全访问服务所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。