Autosar诊断-诊断模块设计

1、Autosar 诊断诊断模块设计诊断服务设计概述诊断被设计在开发、制造 及维修过程中用来实现特定的功能，如用于软件更新、售后检修、产线 EOL 等方面。当然， BootLoader及App 的侧重点也会略有不同， BootLoader主要的功能为软件的更新，而 App 功能的目则是侧重于具体功能模块的诊断、数据保护及IO 输入输出等。BootLoaderApp 的需要支持的基本服务BootLoader常用服务：、诊断会话控制服务 (0 x10):实现在三种会话模式 (默认会话、扩展会话编程会话)下进行切换；对于三种会话模式的功能及管里，请参考ISO14229-1、诊断会话保持服务 (0 x3E

2、):当控制器切换到扩展会话后，当断开控制器 会切换回默认会话，此服务目的就是让其保持在当前会话模式(如扩展会的某些服务在默认会话下不支持，退回是自然退出)；、控制器复位服务 (0 x11) ：通过诊断服务使 ECU 后会切换值默认会话；、安全访问服务 (0 x27):对其它服务或者功能进行保护，避免非法读取非法改写及非法操作。与安全访问服务进行关联的诊断服务须通过安全访 问服务后才能及进行相应的操作；与Application的安全访问的Level 不一样，相应子服务及算法区别、数据读取服务 (0 x22):在BootLoader中，数据读取服务主要读取如诊 断数据版本、硬件版本等内容，还须读取

3、当前诊断会话(在软件更新中极重要)；、数据改写服务 (0 x2E): DID 进行数据写入服务，主要写入一些常数等内容，如安全访问常数 (OEM 用于避免其他非法软件更新 )内容；(0 x31): 如字面意思，它由一些列定义好的软件操作，在BootLoader中主要用于数据的擦除、数据的写入及数据校验等；、下载相关服务 (0 x34 、0 x35 、0 x37) ：此三服务对应下载过程 下载、数据传输、下载完成退出Application 常用服务：、诊断会话控制服务 (0 x10): 实现在三种会话模式 ()下进行切换；、诊断会话保持服务 (0 x3E):当控制器切换到扩展会话后，当断开控制器

4、 会切换回默认会话，此服务目的就是让其保持在当前会话模式(如扩展会的某些服务在默认会话下不支持，退回是自然退出)；、控制器复位服务 (0 x11) ：通过诊断服务使 ECU 后会切换值默认会话；、安全访问服务 (0 x27):对其它服务或者功能进行保护，避免非法读取非法改写及非法操作。与安全访问服务进行关联的诊断服务须通过安全访 问服务后才能及进行相应的操作；与BootLoader的安全访问的Level 不一样，相应子服务及算法区别、数据读取服务 (0 x22):数据读取服务主要读取如诊断数据版本、硬件版 本等内容，还须读取当前诊断会话 (在软件更新中极为重要 )，以及输出的态、输入的状态及错

5、误 Log 等内容；、数据改写服务 (0 x2E):写入参数可以选择永久写入及短时参数调整。短 时调整如用于标定等可将参数写入 RAM，永久写入可以写入 EEPROM( 电重启仍保持数据有效性，可以用于功能的使能与禁止等)、IO (0 x2F): 直接控制 IO 访问；、例程控制服务 (0 x31): 如字面意思，它由一些列定义好的软件操作，如检查编程条件、参数学习、位置擦除及 EOL (ISO14229-1) ；、按地址读取服务 (0 x23):此服务读取地址中的数据，建议关联安全问；、通信控制服务 (0 x28):通信控制服务主要用于禁止一些应用报文的发送与接收，用于软件的更新 (更新过程

6、中停止所有控制器的应用报文，使控制器软件更新时总线负载降低 )；、DTC 控制服务(0 x85):主要用于软件更新过程中，禁止 DTC 的设置在禁用应用报文时会造成 DTC 误报(相关DTC 如果存在定义的话 )；、诊断信息清除服务 (0 x14):清除DTC 相关信息，用于检修完成后清除DTC EOL 检测结束时，避免后续检修造成错误判断；、诊断信息读取服务 (0 x19):读取DTC 相关信息服务包含较多服务 (此不详细介绍)，可以读取冻结帧等详细信息用于更好的故障判断；诊断数据服务 DID 设计DID 全称为 Data Identifier，即数据 ID，详细定义定义见 14229 规范

7、。简单来说，就是给一个编号赋予了特殊含义 (如0 x4328 代表电机状态)，然后服务通过操作这个编号来实现功能 (如读取状态、控制电机的动作等 )。对DID 的编号具体定义须遵循 ISO14229-1，规范中会存在为车辆制造商保留 的范围、特殊 DID 的具体定义。此处截取了部分表格，详细定义见规范文档。2.1 据服务(0 x22)通过数据读取服务，可以读取模拟输入和输出信号，数字输入和输出信 号，内部数据以及系统状态信息等，具体设计由OEM 设计或者认可基本格式 :Request: 22 + XXXX(DID)Positive Response: 62 + XXXX(DID) +响应参数N

8、egative Response: 7F+ XXXX(DID) + NRC(否定响应码）ECU软硬件信息软件版本信息、硬件版本信息、生产日期、诊断版本信息、标定参数版本信息等内容。此处可通过 DID 读取相关信息，用于 ECU EOL (过产线注入的方式写入特定地址 )、OEM 的总装产线对于控制器的软件及硬件版本信息验证等。采集数据输入：、开关输入信号 : 模拟开关的状态信息、数字开关状态信息， (处理后的信息，不推荐使用 AD 返回值，换算对于售后并不方便 )、输入电流电压信息 : 传感器采集信息 (位置传感器、温度传感器等 )，流采集值，电压采集值等 (推荐使用处理后的信息，不推荐使用A

9、D 返回值，换算对于售后并不方便 )功能输出状态 :、电机输出状态 : 电机输出的方向，至于输出的电压信息 (定)、灯负载输出状态 : 灯负载的输出状态 (可以为功能状态 ON/OFF 针对存在调光要求负载 )ECU 节点请求信息ECU 可能存在一些私有节点 (主要指 LIN 节点，只与一个 ECU )， 因此对于它的输出状态及请求状态均通过信号形式传输。为了确定该节点的输出信息，需要将该节点的请求信息通过DID 直观反映，以便检修。: 如开关的背光、状态指示灯等的输出状态、输入的请求信息：开关的请求信息等log 信息车窗丢位置原因、车窗防夹事件、车窗的学习状态等ECU车速，时间，供电电压等等

10、(0 x2E)数据写入服务可以将数据写入 RAM 、EEPROM 、FLASH 达到临时或者永久改写。基本格式 :Request: 2E + XXXX(DID) +写入参数Positive Response: 6E + XXXX(DID) +响应参数Negative Response: 7F+ XXXX(DID) + NRC(否定响应码功能的使能变量推荐将功能的使能或禁用变量存储在EEPROM 中(并且关联安全访问 )，样可以通过 0 x2E 服务进行功能的调整。、用于功能的使能及调整，永久禁用或使能功能(如一键升窗)；、参数的永久调整，永久改变某功能的配置 (如转向灯的闪烁次数 )；参数的临

11、时修改改写软件某些临时变量的改写，如标定的参数(初始化从 FLASH 拷贝值RAM) RAM 中的值。1) 、临时改变参数的值，可用于标定某些参数将软件等信息写入 FLASH用于改写一些常数， OEM 露。如安全访问虽然存在算法，但转换算法供应商也知道，如果设置一组 常数进行转换，这组常数改变，那么安全访问将对供应上不再透明。同理 下载的加密算法都一样。、用于软件更新过程中的改写，只有在软件更新时才会存在DRIVER ；、用于算法一些常数改写，将整车控制器的加密信息对外保密(供应商)；(0 x2F)IO 控制服务强制在扩展会话下进行，并且推荐关联安全访问，避免非法使用；在退出扩展会话时需要退出

12、 IO 控制服务，避免造成正常功能异常。IO 控制服务包括四个子服务，常用的两个子服务为：0 x03( 短期调整)0 x00( 返回控制权)基本格式 :Request: 2F + XXXX(DID) +子服务(03/00) +控制参数Positive Response: 6F + XXXX(DID) +子服务(03/00) +当前控制状态Negative Response: 7F+ XXXX(DID) + NRC()(HSD) 控制高边输出可以通过调整占空比直接控制负载的输出，存在两种控制方式：、直接使用百分比 ()进行输出；、两个状态来进行控制输出，输出值由软件内部给定；桥驱电机输出控制桥驱

13、多用于电机输出控制，对于电机输出堵转须小心处理，可以通过控制正反传进行输出。最重要的是避免持续输出造成电机损坏，采用两种实现方式：、标定堵转阈值，通过电流回采确定堵转，堵转后停止输出；、给出运行时间限制，超时停止输出；负载位置控制某些输出存在位置反馈 ()，定义运动至指定位置的 DID 控制：、直接给定位置，电机运动速度由软件内部给定；、给定输出的占空比以及运动的目标位置；“需要判断参数范围，配置工具不能配置两个参数的范围”诊断例程设计 (0 x31)客户机使用例程服务执行定义的步骤序列并获得任何相关结果。此服务具有很大的灵活性，但典型的用法可能包括以下功能：擦除内存、重置或学习自适应数据、运

14、行自检、覆盖正常的服务器控制策略以及控制服务器值随时间变化，包括预定义的序列（例如，关闭敞篷车顶）。例程控制存在三个子服务：开始例程 (0 x01) (0 x2) 果(0 x03)例程控制可分为三种类型：短例程、长例程、持续例程短例程：可只支持 * (0 x01)* 子服务，直接返回例程结果长例程：需支持开始例程 (0 x01) (0 x2) 、* (0 x03)* 三个子服务，可定义例程时间并在定时结束时自动结束，例程运行中可以通过结束例程 (0 x02) (0 x03) 子服务请求例程状态及结果持续型例程：需支持开始例程 (0 x01) (0 x2) 、* 请求例程结果(0 x03)* 三

15、个子服务，例程运行须通过结束例程 (0 x02) 程运行，例程运行中可以通过请求例程结果 (0 x03) 子服务请求例程状态及结果前编程条件检查在进行更新软件之前需要检查车辆的运行状态，如车速、车辆使用模式等信息，检查结果通过例程返回。此例程可以设置为短例程类型，该例程只需要支持0 x01 子服务即可，历结果通过响应结果进行返回。EOL 产线ECU 控制器的生产产线上需要除了必要的校验生产信息之外，还需要对ECU 控制器的内部电路进行检测，保证控制器的正常电路功能。产品的 EOL 检测为了简化实现逻辑可以复用产品的IO 控制进行，DTC 以将某些 DTC 设置进行禁用以避免在此模式下不必要DT

16、C 设置干扰此过程。免的可通过定义 EOL 模式来进行区分，以达到最大的功能检测。EOL模式定义EOL 模式设定是为了区分正常产品模式，在产品模式下无法覆盖所有的产品配置，定义 EOL 模式为了避免此类情况 (EOL 模式下可以直接 控制)。除此之外，内部电路的一些上拉源的控制在产品模式下不应该在产 品模式下支持此类功能，通过 EOL 模式来规避此类问题。例程定义：例程类型：推荐使用持续型例程类型，此例程需要手动开始与结束例程 例程检验：开始例程时需要进行数据校验，避免OEM 误触发此类模推荐将此类型的模式标志存储 EEPROM ，退出 EOL 模式下时进行擦除 (于休眠唤醒检测时使用 )快速

17、休眠EOL 还需要进行休眠电流的检测、唤醒电流检测等内容。对于正常休眠流程，耗时过长、检测项太多不利于产线使用。例程定义：例程类型：推荐使用短例程类型，此例程只需开始例程子服务(0 x01)例程检验：开始例程时需要进行数据校验，避免OEM 误触发此类模式EEPROM( )此例程用于重置 EEPROM 数据，同时可用于产品软件 (OEM )EEPROM 中数值重置为默认值例程定义：例程类型：推荐使用长例程类型，此例程手动开始例程子服务(0 x01) 、请求例程结果(0 x03)OEMEOL 产线对于 OEM 要首先下发产品的配置信息，后续步骤均需要通过产品的配置信息完成检 测或者学习。(EOL)

18、该例程主要用于负载的电路连接检测，当检测出电路错误时需要记DTC 者通过 DID 进行反馈，OEM 的产线通过此类信息对相应的负载安装信息进行重新检测以避免产品出现电路质量问题。例程定义：例程类型：推荐使用长例程类型，此例程手动开始例程子服务(0 x01) 、请求例程结果(0 x03)请求例程状态，当例程状态为完成后，再次检测自建的结果学习自适应数据该例程用于产线的数据自动学习，由软件内部定义好学习序列，在满足学习的条件时，运行例程进行数据学习。例程定义：例程类型：推荐使用长例程类型，此例程手动开始例程子服务(0 x01) 、请求例程结果(0 x03)可以将学习结果定义在请求例程结果子服务 (

19、0 x03) 中，在请求例程达到例程完成后，校验例程学习的结果立即保存状态数据该例程用于数据的立刻存储，避免由于操作失误直接断电等异常情况造成学习数据丢失，因此对于产线使用此例程可避免此类情况。例程定义：例程类型：推荐使用长例程类型，此例程手动开始例程子服务(0 x01) 、请求例程结果(0 x03)可以将学习结果定义在请求例程结果子服务 (0 x03) 中，在请求例程达到例程完成后，校验例程执行的结果诊断故障码 DTC 设计DTC 设计能够为售后节省大量的时间。电路故障常见的电路故障如开路、断电源、短地等，高边输出：高边输出检测断电源与开路在输出时不能区分，因此可以使用短地、短电源或开路两种故障类型。对于需要检测出短电源的负载，可以设计在无输出时对高边进行电压回采，并定义短电源故障桥驱输出：对于桥驱输出，低边短电源与高边短地都造成过流(在短电时，总会存在一个边回过流），建议设计两种类型：过流、开路逻辑或信号错误故障预期信号与实际信号的不一致，举一个简单例子：锁命令输出了但无法测到锁的状态反馈信号，进行了两次Retry 均无法达到预期状态。此类错误详细设计可以与 OEM 进行协商或者根据标准进行设置。通信故障通信故障包括电路的错误及通信错误，CAN CAN 的物理电路错误、 CAN (Bus