微波EDA网,见证研发工程师的成长!
首页 > 硬件设计 > 嵌入式设计 > 汽车电子诊断服务的自动验证

汽车电子诊断服务的自动验证

时间:12-12 来源:互联网 点击:
GME开发部在诊断验证过程中第一次引进了全自动的测试例程生成工具。该文档由GME与Vector共同完成,描述在新Opel Insignia的诊断实现过程中的自动测试。与在Opel Corsa进行手工验证相比,将Vector工具集成到现有的工具环境中,能够降低成本,节约时间,并改善流程。

1 概述

全球汽车市场竞争的日益激烈,导致了汽车电器网络越来越复杂,对开发周期的要求也越来越短。由于电器系统替代传统系统的核心目的是降低成本,提升系统的安全性与可靠性,同时方便管理。这里,暂不考虑这些好处,但是随着系统电器部件的增加,必然会导致与电器相关故障的增加。由于用户购买新车的重要评价指标是可靠性,因此有必要引进一种新的方法,能够适应这种复杂,快速的开发流程,并保证每一个已经装车的ECU正常运行。尤其是在ECU的诊断功能,必须保证诊断服务的正确性。其传输的信息能够帮助服务站的维修师快速准确的定位故障并修正这些故障。这些信息还要能够让维修师查出问题的根源,知道那些部件需要更换。如果这些内容不能保证的话,可能会导致不正确的更换一些正常工作的部件,这必将导致维护成本的增加以及客户满意度的降低。

Opel Insignia的电器系统结构包括几个CAN和LIN网络。所有的总线系统都通过中央诊断口(DLC)访问(图一)。通讯由GM协议定义,该诊断协议以KWP2000和CAN 2.0A为基础,包括所有访问ECU诊断系统的服务,用来获取诊断信息。这些诊断服务由诊断仪发出,建立诊断通讯。一旦请求被发出,被查询的ECU会根据情况发出肯定或否定响应。

·肯定响应包括诊断仪请求的所有诊断信息,如果诊断信息过长,响应包含多帧报文
·否定响应包括一个明确定义的否定


图一 Opel Insignia的电器结构与诊断通讯接口

根据这些响应,维修师能够判断导致问题的原因,并采取相应的措施予以解决。

因此,在服务站对于故障的正确维修得益于诊断系统大量准确的输出信息。在进行快速、专业的服务或维修来让客户满意的过程中,执行合适的诊断服务致关重要。诊断在下线测试的过程中也扮演重要的角色:其用来对ECU编程,保证产品的质量。这便是为什么要进行复杂的诊断验证的原因。

2 在GME的验证流程与工具环境

在Opel Insignia的开发过程中,GME引进了从Vector第一次“CANoe.DiVa”(诊断集成验证辅助)工具。“DiVa”自动生成诊断测试用例并执行诊断测试。图二显示了Opel Insignia和Opel Corsa的工具环境。在两个案子中,CANoe均为测试工具,但在Corsa开发过程中,大量测试均手动完成,而Insignia开发过程中,自动测试覆盖了绝大多数测试内容。


图二 Opel Insignia和Opel Corsa诊断验证工具环境对比

图三显示了GME测试工程师典型的诊断验证流程。ECU的软件开发被分为了几个阶段,在ECU开发的初期,重点在于实现ECU的功能而不是诊断服务,后者是在后续的软件版本中进行详述,开发的。就如图三所示,在阶段1软件版本(SWR1)中,仅实现了很少一部分的诊断服务,GME使用了诊断软件模块(CANdesc),使得在开发的初期就能够实现一部分的诊断内容,这样,就能够较早的集成到ECU中(见图三)。


图三 GME在ECU开发不同阶段诊断的实现情况

诊断功能测试的数量随着每一个开放循环不断增加,一旦所有的诊断服务被实现,就要进行回归测试(SWR7)。如果在此阶段没有缺陷报告,则表明该ECU的诊断功能已经成熟。

一般来讲,测试工程师会同时测试许多不同的ECU,如果没有合适工具的支持,测试工程师便不能很好的对每一个软件版本实现的诊断功能进行全面的测试。这样,只有新增的服务进行了详细测试,对于以前集成的服务仅根据自己的经验进行有代表性的回归测试。使用合适的自动工具,在提供效率的同时还能够进行更多的验证测试。

3 验证工具应具备的条件

一个自动诊断验证工具必须具备下述条件:

·与现有工具链无缝集成
·透明,可重复:测试工程师必须能够追踪测试并能够复现测试
·遵循GM的现有测试方法:该工具必须支持现有的测试方法;在诊断这一块,GM的诊断规范已经定义了ECU诊断服务的强制测试流程
·方便测试工程师扩展
·自动生成测试例程:为了实现该功能,规范必须能够机器可识别

4 从规范到测试执行,生成报告

如图二所示,“DiVa”建立了“CANdelaStudio”(诊断规范)与验证工具(“CANoe”)的联系。“DiVA”能够无缝集成到GME现有工具链中,根据“CANdela”的诊断规范(CDD文件),自动生成检验各诊断服务的测试例程。生成的代码是基于CANoe的编程语言“CAPL”的,所以能够在任何时候被执行。如果发现问题,测试工程师察看测试系列,找出错误所在(透明性)。另外,CANoe的纪录功能够在通信层记录诊断数据流。

使用“DiVa”,通过下述步骤来控制测试:

·选择ECU及其变量
·配置测试
·生成测试例程
·将测试模块添加到“CANoe”的测试环境中
·执行测试
·生成测试报告

用户可以在任何时候修改“DiVa”的测试约束,此外,范围参数用来配置测试内容,例如全范围测试,快速测试和正常例程测试。另外,在支持的服务中,用户可以从测试中去除部分服务,或者在数据对话窗口中修改服务的内容,如图四。

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top