CN112180891A - 一种ecu离线运行故障排查分析方法 - Google Patents

Abstract

本发明涉及一种ECU离线运行故障排查分析方法，吸收了离线调试中UDS和XCP各自的优点，将XCP通信协议作为UDS服务协议的一种，扩展UDS服务协议，利用集成XCP通信协议的UDS服务协议对ECU进行离线运行故障排查分析，使得ECU在应用过程中其内部的内核状态、外设状态、内存信号、故障信息、各种功能逻辑过程内存等等能够被访问和连续监测，从而能排查分析ECU运行过程中的故障。

Description

一种ECU离线运行故障排查分析方法

技术领域

本发明涉及汽车控制技术领域，具体涉及一种ECU离线运行故障排查分析方法。

背景技术

ECU是电控单元的缩写，目前整车上越来越多的ECU节点，在未来的电子电器架构中，以域为单位后，ECU节点会增加的更多。

在目前的ECU产品上，特别是新品上，由于需求、边界、条件等不定或者改变，很多ECU功能在开发初始或者应用之后，在某些工况下，其功能表现不够理想，甚至于可以定义为问题和故障。为了改善ECU的功能和性能，故障的排查、定位方法很重要。

关于ECU故障排查从过程看，可以分为开发环节和应用环节。在应用环节，一般使用UDS协议读取一些ECU内部诊断的故障结果信息或者基于XCP(Universal CalibrationProtocol，通用校准协议)的信号监测等。

UDS是广为主机厂定义和支持的，应用普遍，应用门槛相对XCP低，但是功能也有缺陷，UDS可以支持从ECU获取ECU内部诊断的DTC故障信息，也即，ECU内部定义和做了诊断的故障才能被获取，未定义和诊断的无法获取；相对的XCP非常方便监测ECU内部内存信息、运行状态、故障信息等，但是XCP依赖特定的接口定义，一般整车未留有支持接口。而实际整车ECU开发过程中，一般整车厂只预留了UDS的CAN通讯接口，定义了UDS诊断通讯的ID，并未定义支持基于XCP的接口，而且XCP的工具链和技术有一定门槛。

在实际开发一款汽车仪表控制器时，整车厂就只定义了UDS通讯接口和ID，并未支持其他任何接口，且汽车仪表控制器外壳包围实际无任何其他对外接口。但由于需求迭代和软件功能升级后某些功能细节表现错误，需要一种故障排查方法支持。

发明内容

本发明针对现有技术中存在的技术问题，提供一种ECU离线运行故障排查分析方法，吸收了离线调试中UDS和XCP各自的优点，使得ECU在应用过程中其内部的内核状态、外设状态、内存信号、故障信息、各种功能逻辑过程内存等等能够被访问和连续监测，从而能排查分析ECU运行过程中的故障。

本发明解决上述技术问题的技术方案如下：

一种ECU离线运行故障排查分析方法，包括将XCP通信协议作为UDS服务协议的一种，扩展UDS服务协议，利用集成XCP通信协议的UDS服务协议对ECU进行离线运行故障排查分析。

进一步的，所述的扩展UDS服务协议包括：选取服务ID为0x19的UDS服务，扩展0x19服务的子功能服务，根据XCP通信协议内容定义该子功能服务的服务数据流，并定义扩展的子功能服务ID为0xFF。

进一步的，所述的服务数据流包括请求数据和响应数据，其中所述请求数据为由故障检测设备向ECU发送的监测请求数据，所述响应数据为由ECU根据所述请求数据向所述故障检测设备反馈的ECU状态数据。

进一步的，所述请求数据包括有效数据长度字段、服务ID字段、子服务ID字段、地址字段、应答数据类型字段；所述响应数据包括有效长度字段、服务ID及应答类型字段、子服务ID字段、应答数据内容字段。

进一步的，所述应答数据类型字段用于标记被监测信号或者内存是uint8、uint16或者uint32类型；

若被监测信号或者内存是uint8类型，则应答数据类型字段的值为0x01，应答数据内容字段为1个字节长度的数据；

若被监测信号或者内存是uint16类型，则应答数据类型字段的值为0x02，应答数据内容字段为2个字节长度的数据；

若被监测信号或者内存是uint32类型，则应答数据类型字段的值为0x04，应答数据内容字段为4个字节长度的数据。

进一步的，该方法还包括：

从ECU软件中确定需要监测的对象，确定其在软件中的信号名称定义；

在ECU软件对应的map文件中搜索该信号名称定义查询得到该定义在编译后对应的内存地址；

根据该信号名称定义的数据类型和查询得到的内存地址，确定XCP通信协议内容。

本发明的有益效果是：本发明兼具了UDS和XCP的优点，规避了UDS和XCP的不足，整车兼容性好，使用工具、技术门槛相对低，维护难度相对低，并且在集中了这么多有利因素的情况下，使用质量和效果非常好，可以监测ECU内部各种状态，通过连续监测可以进行ECU离线运行监测分析。在发生故障时，通过本发明很容易帮助排查、分析、定位故障点，从而帮助快速解决问题。从其他各方面节省了大量了人力、物力、工具、技术等成本。

附图说明

图1为本发明实施例提供的UDS服务中0x19子功能列表；

图2为本发明实施例提供的UDS服务中0x19的子功能0xFF的详细协议结构图；

图3为本发明实施例提供的XCP数据转换原理图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

一般故障排查分析的总体方法，开发阶段主要用在线调试的方法，运用调试器在软件运行中打断点监测内核、外设和内存等，优点是操作简单，成本低，缺点也很明显，只能应用于开发阶段，而且是断点调试监测，不能连续监测，无法监测ECU软件连续运行功能时序。应用阶段主要用离线调试方法，运用一些通讯手段监测ECU运行状态。目前主流的方式有UDS和XCP，这两种离线方式的优缺点也很清晰，基本是互补的：UDS是广为主机厂定义和支持的，应用普遍，应用门槛相对XCP低，但是功能也有缺陷，UDS可以支持从ECU获取ECU内部诊断的DTC故障信息，也即，ECU内部定义和做了诊断的故障才能被获取，未定义和诊断的无法获取；相对的XCP正好互补，优点是非常方便监测ECU内部内存信息、运行状态、故障信息等，但缺点也很明显，XCP依赖通讯接口，即便是XCP on CAN，一般整车网络上也基本未曾留有独立的CAN接口或者ID定义，并且XCP工具链的应用，成本和技术较高。

因此，在目前主流背景下，将UDS和XCP的优点汇总，缺点规避，即为一种最为直接有效的方案，即为本案核心要义。

本方案的核心组成为：使用UDS的通讯协议+XCP的数据转换方法。使用UDS的通讯协议是为了继承UDS的优点，整车接口支持的好，门槛相对不高；使用XCP数据转换方法是为了继承XCP的优点，方便内存监测、运行状态监测、故障信息监测。这两大功能的融合体就汇总了优点，规避了缺点。

如图1，为本方案选用的UDS服务。选用服务ID为0x19的UDS服务。0x19服务的子功能服务定义了0x00～0x13的服务，在此基础上新增一个与0x00～0x13子功能服务互不干涉的子功能服务，即0xFF服务。

如图2，为本方案选用的UDS的0x19服务中定义的0xFF子功能服务的详细协议。本协议详细描述了0x190xFF服务的数据流。Add1、Add2、Add3、Add4为一个uint32的地址拆分出来的4个byte。

举例说明：一个地址为0x20002318对应的Add1、Add2、Add3、Add4分别为0x20、0x00、0x23、0x18(这个顺序方便看数据，也可以反过来为0x18、0x23、0x00、0x20)。SigDlc表示被监测信号或者内存是uint8、uint16、uint32的类型，当监测uint8时，SigDlc为0x01，当监测uint16时，SigDlc为0x02，当监测uint32时，SigDlc为0x04。因此详细的数据流可以描述为：

0x07 0x19 0xFF Add1 Add2 Add3 Add4 0x01

0x03 0x19 0xFF Sig

其中Sig为对应的uint8数据；

0x07 0x19 0xFF Add1 Add2 Add3 Add4 0x02

0x04 0x19 0xFF SigB0 SigB1

其中SigB0和SigB1拼成uint16数据；

0x07 0x19 0xFF Add1 Add2 Add3 Add4 0x04

0x06 0x19 0xFF SigB0 SigB1 SigB2 SigB3

其中SigB0和SigB1和SigB2和SigB3拼成uint32数据。

uint16和uint32的数据拼接可以按照intel或者Motorola格式，都可以支持。

如图3，为简化的XCP数据转换原理。XCP原生的数据转换做法是将需要监测和标定的数据预先做成A2L文件格式的数据库。由于XCP方式工具、软件、技术有一定门槛，本方案化繁为简，跳出A2L数据文件的制作、解析等，直接使用核心原理从ECU软件对应的map文件进行数据转换，具体过程为：首先，从ECU软件中确定需要监测的信号、内存等对象，确定其在软件中的信号名称定义；然后在ECU软件对应的map文件中搜索该信号名称定义查询得到该定义在编译后对应的内存地址；最后根据该信号名称定义的数据类型(uint8、uint16、uint32)和查询得到的地址，可以确认如图2中的详细数据通讯协议数据流程。

为了更详细的阐述本发明方案，以下将以一个实施例(包含并不限于本实施例)详细过程展开进行描述。本实施例以一款汽车仪表ECU软件中的ECU工作模式进行阐述。

假设，ECU软件中工作模式确定信号定义为Ecu_m_st_Mode，数据类型为uint8，将Ecu_m_st_Mode代入ECU软件对应的map文件中查询其编译后的内存地址，查询为0x20002bff。

根据图1的数据协议发起UDS服务(本方案服务根据实际需要选择是否需要安全访问)。由上述步骤获知：Ecu_m_st_Mode为uint8数据类型，内存地址为0x20002bff。因此上位机工具发起核心服务：

0x07 0x19 0xFF 0x20 0x00 0x2b 0xFF 0x01

ECU实际应答数据为：

0x03 0x59 0xFF 0x02

其中0x59表示解析为正应答，Ecu_m_st_Mode信号使用本发明方案监测值为0x02。

如果需要连续监测多个信号，需要上位机工具做个请求队列即可。

综上，本发明方案实现了一种ECU离线运行故障排查分析方法。本发明兼具UDS和XCP的优点，规避了UDS和XCP的不足，整车兼容性好，使用工具、技术门槛相对低，维护难度相对低，并且在集中了这么多有利因素的情况下，使用质量和效果非常好，可以监测ECU内部各种状态，通过连续监测可以进行ECU离线运行监测分析。在发生故障时，通过本发明很容易帮助排查、分析、定位故障点，从而帮助快速解决问题。从其他各方面节省了大量了人力、物力、工具、技术等成本。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种ECU离线运行故障排查分析方法，其特征在于，包括将XCP通信协议作为UDS服务协议的一种，扩展UDS服务协议，利用集成XCP通信协议的UDS服务协议对ECU进行离线运行故障排查分析。

2.根据权利要求1所述的方法，其特征在于，所述的扩展UDS服务协议包括：选取服务ID为0x19的UDS服务，扩展0x19服务的子功能服务，根据XCP通信协议内容定义该子功能服务的服务数据流，并定义扩展的子功能服务ID为0xFF。

3.根据权利要求2所述的方法，其特征在于，所述的服务数据流包括请求数据和响应数据，其中所述请求数据为由故障检测设备向ECU发送的监测请求数据，所述响应数据为由ECU根据所述请求数据向所述故障检测设备反馈的ECU状态数据。

4.根据权利要求3所述的方法，其特征在于，所述请求数据包括有效数据长度字段、服务ID字段、子服务ID字段、地址字段、应答数据类型字段；所述响应数据包括有效长度字段、服务ID及应答类型字段、子服务ID字段、应答数据内容字段。

5.根据权利要求4所述的方法，其特征在于，所述应答数据类型字段用于标记被监测信号或者内存是uint8、uint16或者uint32类型；

若被监测信号或者内存是uint8类型，则应答数据类型字段的值为0x01，应答数据内容字段为1个字节长度的数据；

若被监测信号或者内存是uint16类型，则应答数据类型字段的值为0x02，应答数据内容字段为2个字节长度的数据；

若被监测信号或者内存是uint32类型，则应答数据类型字段的值为0x04，应答数据内容字段为4个字节长度的数据。

6.根据权利要求1所述的方法，其特征在于，该方法还包括：

从ECU软件中确定需要监测的对象，确定其在软件中的信号名称定义；

在ECU软件对应的map文件中搜索该信号名称定义查询得到该定义在编译后对应的内存地址；

根据该信号名称定义的数据类型和查询得到的内存地址，确定XCP通信协议内容。

Images