汽车电子诊断服务的自动验证
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，如果没有合适工具的支持，测试工程师便不能很好的对每一个软件版本实现的诊断功能进行全面的测试。这样，只有新增的服务进行了详细测试，对于以前集成的服务仅根据自己的经验进行有代表性的回归测试。使用合适的自动工具，在提供效率的同时还能够进行更多的验证测试。
评论