"着车辆中ECU复杂度的增加，诊断的测试范围以及完成诊断功能验证需要花费的时间和精力也在增加。幸运的是，应用诊断自动化测试工具完成验证工作所需要花费的时"
随着车辆中ECU复杂度的增加，诊断的测试范围以及完成诊断功能验证需要花费的时间和精力也在增加。幸运的是，应用诊断自动化测试工具完成验证工作所需要花费的时间和精力不再是线性增长。尽管诊断测试的范围不断扩大，但创建和执行测试用例的时间和人力投入相对稳定。UDS和诊断描述格式CDD/ODX标准的制定，为完成高覆盖度和高质量的自动化测试提供了可能性。此外，诊断应用和刷写测试也可以实现自动化。
2006年，UDS（ISO 14229）标准的发布，使得诊断自动化测试跨出了重要的一步：诊断服务的统一，为更深入地实现跨整车厂的诊断协议测试提供了可能性。与UDS协议对比，KWP2000协议在实现诊断功能过程中允许很大的自由度，需要整车厂基于自己的需求定制化实现其功能，这使得自动化测试的实现变得困难。UDS修订版于2013年发布，新版本UDS可以实现更高覆盖度的自动化协议测试。
除协议规范之外，诊断数据的描述是测试用例自动生成的另一个重要的先决条件。为了能够自动生成测试用例，必须“知道”ECU中定义的诊断服务。Vector提供的CANdelaStudio软件可以基于诊断需求规范定义诊断服务，并导出诊断数据库（CDD或ODX格式）。与此同时，Vector提供的CANoe.DiVa软件可以通过导入CDD或ODX文件，自动生成全面的测试用例。
这些测试用例覆盖了有效和无效的请求，而这些请求则将ECU中的正确处理和错误处理用于测试。CANoe可以加载测试用例并自动执行，生成的测试结果会在测试报告中详细记录（如图1）。对于功能复杂的ECU，自动生成的测试用例可能超过10,000个且无需冗余测试。
图 1：CANoe.DiVa测试流程示意图
如果每个ECU都有CDD或ODX格式的诊断数据库，那么从诊断需求规范到全面的自动化协议测试只需一小步，仅需很少的准备工作就可以检测到协议错误。
1、AUTOSAR提高诊断协议质量
当AUTOSAR软件模块用于诊断时，AUTOSAR基础软件可以处理诊断仪的一系列协议非法测试（例如格式不正确）。由于AUTOSAR基础软件通常使用诊断数据库（DEXT）作为诊断模块的需求输入，提高了诊断需求的一致性，因此ECU的诊断响应通常也会符合协议要求。在使用AUTOSAR模块时，简单的协议错误的比例明显下降。因此，用于测试评估和故障排除的时间和精力相应的也会减少。尽管如此，协议测试仍然很重要，原因如下：
在配置AUTOSAR模块、集成和应用开发期间可能会发生错误；
如果ECU内诊断功能的实现和诊断仪内诊断功能的实现不匹配，尽管是正确的诊断功能实现，但是仍然不能通过诊断仪中的诊断功能；
利用应用程序实现的疏漏而发起的恶意攻击。
在DoIP和OTA应用的某些情况下，不需要与诊断仪直接进行物理连接。对于整个车队中的车辆，协议错误可能会对某些服务产生负面影响。在最坏的情况下，协议错误可能允许对车辆进行安全攻击。基于诊断功能，客户体验的新用例将持续发展。这些新用例将导致更频繁和更广泛的使用诊断功能。由此可以预见，对诊断功能实现的质量要求将会继续提高。
2、软件更新验证
尽管ECU刷写采用了诊断标准化服务，但刷写的流程仍然是整车厂特殊定义的，诸如数据传输的加密机制（数据识别、Checksum、签名等），结果是每个整车厂都拥有独一无二的刷写流程，这意味着每个整车厂都有一个特定的软件更新序列。因此，对于不同的整车厂项目，供应商需要使用不同的刷写序列，还必须为每个整车厂开发和维护特定的测试环境。在生产和售后服务中，ECU软件刷写是不可或缺的。考虑到未来OTA需求，车辆中可靠的软件刷写功能比以往任何时候都更加重要，软件更新的频率会更加频繁，类似于我们已经熟悉的手机移动设备（例如修复安全漏洞）。在刷写过程中应该尽量避免对ECU刷写失败而导致ECU不能正常工作的情况。但即使是成熟的智能手机制造商，采取了复杂的保护措施，在对软件版本进行更新时也会不可避免的出现问题，从而对刷写测试提出了更高的要求。
Vector提供的vFlash软件可以应用于不同整车厂的软件刷写，目前为止已经为超过100个整车厂定制了刷写模板（基于刷写规范的刷写序列）。CANoe.DiVa通过调用vFlash刷写工程，自动生成刷写过程的测试用例。除了测试刷写过程中的时序、相关服务的格式等，还会测试刷写序列、刷写异常序列、欠压、中断等，实现对Bootloader稳健性的全面性测试。
除此之外，对刷写过程中相关数据（识别数据或者签名）的测试需要整车厂提供特定的详细信息。对于此类测试，Vector已经为众多整车厂提供了特定的测试扩展，即CANoe.DiVa Plugin。
3、诊断应用的验证
诊断应用功能验证是确保车辆诊断功能实现的唯一办法。诊断数据库（CDD或ODX）定义诊断需求，测试工具则从诊断数据库中提取与应用相关的信息用于测试用例的自动生成。例如，基于对指定数值范围的描述，自动生成验证传输值合理性的测试用例。为了实现诊断应用的自动化测试，需要搭建ECU的应用仿真。ECU的应用配置信息可以从如下渠道获取：
从arxml或dbc文件中获取总线通信相关信息，从而读取或发送总线报文
从a2l文件获取ECU内部变量的地址信息，通过XCP读取或修改相关参数
利用VT System搭建硬件在环系统（如图2所示）。VT System配置文件描述硬件在环信息，如电器信号的输入输出，从而被CANoe.DiVa测量和触发。
图 2：硬件在环测试示意图
CANoe.DiVa还支持通过Excel文件导入/导出诊断参数配置和DTC配置。
交互式的配置选项提高了诊断应用测试的半自动化程度，甚至部分诊断应用测试达到全自动化。但是必须承认的是，诊断应用测试的自动化程度距离诊断协议测试的自动化程度还有一段距离。
4、测试范围、测试评估和进一步处理
CANoe.DiVa实现的诊断协议验证的高度自动化保证了测试的高效性。同时，CANoe.DiVa支持用户测试需求扩展，以CANoe.DiVa Plugin的方式定制化满足客户的特殊需求，保证了测试的高覆盖度。越来越多的整车厂在系统安全导向的诊断应用场景下受益于 CANoe.DiVa 及CANoe.DiVa Plugin的自动化测试验证，供应商也从验证安全导向的诊断功能测试中受益匪浅。
当前，全球众多整车厂都采用CANoe.DiVa实现诊断测试，并在测试过程中节省了大量时间（如图3所示）。CANoe.DiVa的测试后处理能力包括：
分类、过滤测试报告，便于获取期望的测试结果。
链接失败的测试用例与测试数据流（Trace）。
为各个测试结果添加注释，便于对错误以及错误原因进行分类。记录纠正措施，控制故障排除。
将测试解决方案链接到现有测试数据管理系统或需求管理系统，方便集成到现有流程中。
图3：手动测试与自动测试的对比
结论/展望
ECU的诊断范围和诊断质量需求在持续增加。庆幸的是，基于CANoe.DiVa的诊断自动化测试方案显著减少了诊断验证所用的时间和人力投入，同时极大地增加了测试的广度和深度。
随着车联网应用的不断增加，车辆网络安全需求迅速增加，“安全性测试”已经成为焦点话题。OTA 扩展了访问车辆的途径，为车辆诊断开辟了新的应用领域，但同时也可能带来新的安全问题。基于CANoe.DiVa的有效测试可以帮助用户消除一些潜在的隐患。
