某重卡诊断系统的开发和应用

俞 燚

某重卡诊断系统的开发和应用

俞 燚

（安徽江淮汽车集团股份有限公司，安徽 合肥 230601）

文章以某重型卡车的诊断系统开发为例，描述了整车诊断系统的开发流程、设计方案和测试验证等方面，为其他车型开发提供经验。

诊断；V型开发；诊断测试

CLC NO.: U462.1 Document Code: A Article ID: 1671-7988 (2017)16-22-03

前言

近年来，汽车行业的发展速度十分迅猛，车内电控单元系统数量不断提高，网络越来越复杂。复杂度的提高使得全面而有效的故障诊断变得比以往任何时候都更加重要。汽车的电子控制单元大约有30%～40%的内存被用于故障诊断，诊断服务也越来越丰富，各种服务子功能也越来越细化。诊断系统开发的合理性将越来越成为各大汽车厂商关注的重点。本文将以某重卡车型为例从开发流程、设计方案、测试验证等几个方面来浅析下诊断系统的开发和应用。

1 诊断开发流程

车辆的开发过程一般都遵守V型开发模式，诊断作为车辆开发的一个子系统，开发流程也同样符合V型开发模型。诊断开发贯穿于ECU开发的始终，包括前期的需求规范制定、ECU供应商诊断软件开发和后期测试验证。模型如下图所示：

图1

前期的需求分析主要工作是诊断功能的设计，诊断协议及服务的确定，包括总体的诊断功能需求描述，以及针对单个ECU的具体需求规范等。实现阶段主要是由ECU供应商开展ECU软件设计，实现需求规范中的所有诊断功能。后期测试验证包括ECU级单节点诊断测试以及系统级诊断功能验证。一般主机厂目前诊断开发和测试过程使用的工具链都是基于Vector公司的，主要工具为CANoe、CANdito和CANape，可以将诊断需求和诊断测试无缝连接。

2 诊断需求设计

2.1 需求分析

根据某重卡整车配置表，整车CAN网络节点包括车身控制器（BCM）、组合仪表（ICM）、防抱死制动系统（ABS）、发动机管理系统（EMS）、车门控制器（DCM）、缓速器（RCM）、车道偏离系统（LDW）、胎压监测系统（TMPS）和行车记录仪（TCO）等模块。其中ABS、EMS和RCM为成熟产品，其通信协议遵守SAE J1939标准，即整车通信速率为250Kbps，采用29位CAN标示符；诊断协议遵守J1939在线诊断。对于其他新开发的节点，我们要求全面实施UDSonCAN诊断（ISO14229），保证总线上的每个CAN节点，最终都能够实现独立通过诊断仪进行诊断和刷写，最大化地发挥出诊断对于整车开发的意义。

具体的诊断协议规划如下：

表1

2.2 诊断需求规范设计

诊断需求规范设计分为系统诊断需求制定和部件诊断需求制定两个阶段。在系统诊断需求制定阶段，需要制定平台诊断需求规范和bootloader需求规范。诊断需求规范中包括传输层约束，应用层约束，诊断服务约束，OEM标准化的诊断数据（故障码，数据标识符）等。Bootloader需求规范定义了下载流程，源文件需求，安全机制等内容。两份平台需求规范集中体现了整车厂对供应商对诊断开发的整体要求，有任何偏离项都需要与整车厂沟通确认。

表2

为提升整车的可维修性，发挥诊断服务的最大优势，在平台需求规范中对所有控制器提出基础诊断要求：必须具备故障诊断和在线刷写的功能。

部件级诊断需求规范是各部件根据自身功能需求，基于平台规范的细化。部件诊断规范需要制定诊断服务具体内容，包括故障诊断具体内容，数据流读写内容，输入输出控制定义，例程控制定义等，并结合自身的功能，基于整车EER架构功能定义规划诊断对象、策略、故障处理机制。

根据UDS规范中的服务，制定一款基于Excel的标准格式的诊断调查问卷。通过诊断调查问卷对零部件供应商进行调查，多轮沟通后，了解供应商的当前诊断实现状态、技术问题和项目信息，基于架构定义和产品的功能最终确定相应ECU部件的诊断需求规范。诊断调查问卷的模版如下：

表3

3 诊断测试验证

为了验证诊断开发的质量，满足车辆诊断需求，在ECU诊断开发完成后需要根据测试规范对诊断进行多轮测试。测试规范定义了每一测试项的测试步骤和通过条件等。测试内容包含诊断协议测试，bootloader测试和诊断功能测试。为了保证测试的全面性，每一类型测试都必须进行单部件，台架/实车测试，验证各条件下诊断满足要求。

3.1 诊断协议测试

诊断协议测试包括传输层测试，应用层测试和诊断服务测试。测试用例是基于部件诊断需求生成的。目前常用的测试软件为Vector公司的CANoeOption.Diva。之前基于Excel标准诊断调查问卷可通过Sure软件转化为ODX格式，通过diva可生成自动化测试用例，测试效率高，用例覆盖度广。测试报告的形式可以根据需求为XML，HTML和转换而成的Excel格式。

图2

3.2 Bootloader测试

Bootloader测试用例是基于平台的Bootloader需求规范，利用Vector工具链中的CANoe软件和CAPL语言开发的，可以实现全自动化的正向和逆向测试。测试内容包括bootloader流程测试，可靠性测试，安全性测试和完整性测试。测试完成后还能通过CANoe自动生成Excel版本的测试报告。

图3

3.3 诊断数据一致性测试

诊断数据一致性测试主要是为了验证ECU的诊断功能实现是否正确，内容包括部件诊断需求报告中的DTC一致性验证，数据流测试，输入输出控制测试，例程控制测试（除bootloader相关）。由于该测试项对硬件环境有要求，需要控制器接入开关负载等，所以该测试是基于台架或者实车来开展的。根据ECU的功能和诊断需求进行测试用例的分解，对每个输入输出量进行故障状态模拟，逐一手动测试验证。最后输出基于测试规范（excel版）手动创建的excel版报告。

图4

4 结束语

随着整车智能化的不断提升，商用车厂商对于诊断的覆盖率和有效性也将越来越关注。通过本文可以初步了解车型开发过程中诊断系统的开发流程，作为汽车诊断工程师开发参考。

[1] SO 14229-1∶Road vehicles - Unified diagnostic services (UDS) - Part 1∶Specification and requirements (2006).

[2] 刘丽丽.车辆通用故障诊断协议的研究与开发.

Development and application of diagnosis system on the heavy truck

Yu Yi
( Anhui Jianghuai Automobile group Co., Ltd, Anhui Hefei 230601 )

In the paper, a heavy truck is taken as an example to describe the development process, design scheme and test verification of the vehicle diagnosis system.

diagnosis; V type development; diagnosis test

U462.1

A

1671-7988 (2017)16-22-03

10.16638 /j.cnki.1671-7988.2017.16.009

俞燚，女，工程师，就职于安徽江淮汽车集团股份有限公司技术中心，从事电器设计工作，研究方向为车载网络技术。