顶棚控制模块自动测试

　　图1 测试项目涉及的三个方面

　　为了给特定的受测系统确定理想的测试方法，在本案例中，RCM的测试要求必须包括各个方面。下面重点讨论设备方面的要求：测试系统。

　　测试系统要求

　　为了提供其功能特性，RCM必须产生并处理众多不同的信号。同样，RCM测试系统还需做出执行反应。数据通讯一般包括标准与非标准信号。标准信号的种类包括数字信号（如按钮）、各种频率的PWM信号（如调光、电机控制）和各种模拟信号（从LED到联锁电机）。另外，非标准信号，如与外部传感器的专用通信协议，也需考虑在内。

　　有些功能（如防撞预警）需要ECU评估被控执行机构（如电机）和传感器（电流、位置传感器）的相互作用。这些相互作用必须在测试系统上进行模拟。因此，对测试系统需要相应设计和充分配置。

　　通过CAN和LIN接口，RCM与车辆的其他部件进行通讯。在装有有源传感器的情况下，ECU可用作网关。例如，通过CAN接口将雨水传感器数据从接入的LIN接口传送到所连接的其他ECU上。这些接口的执行，需要多重网络的特定测试：验证通信参数（身份、循环时间等）和类似于网络管理的交叉功能。对于需要多个ECU来共同完成的一些功能（如雨水袭来时的天窗关闭），这种测试显得尤为重要。这些功能不仅需要对单个ECU进行测试，并且需要对所有相关的ECU进行综合测试。

　　尽管RCM的测试与许多其他车载ECU的测试相类似，RCM的测试系统还必须满足某些另外的特定要求。各种功能的组合、多种变量（在本案例中，单个模块线路中需要5个变量）、功能参数和软件发布（为20种软件发布运行HiL综合测试是很常见的）要求进行大量的测试。本案例中，仅综合测试就需要540种测试脚本，一个完整的测试需要进行75h（纯测试时间）。

　　因此， RCM测试是一个复杂而耗时的工作，不是靠手工测试能够完成的，也不是开发过程中的一项附属工作。要取得成功，关键在于需要全面的测试和开发流程，同时利用所有的自动测试技术。

　　测试设备设计

　　有效的测试取决于详尽的计划和健全的规范。测试设备的设计取决于所定义的测试案例，包括其他因素。在RCM案例中，防撞预警功能的测试强化了对测试系统设计的特定要求。当然，最终设计不仅取决于技术，而且还取决于项目成本和期限等因素。

　　测试自动化有多种不同技术。下面按增加的成本和复杂性进行介绍，它们是：

　　1. 自动测试台架

　　自动测试台架通常利用已有的硬件资源。在本案例中，可以是天窗，并包含有电机和ECU。由一个自动化元件提供简便操作和对特定变量（电流、电压和CAN信号）的监测。

　　2. 开环测试台架

　　开环测试台架不采用实际硬件，而是利用定制设计的电路来模拟零部件。信号激励和测量完全由自动化元件来控制。这意味着对当前任何系统的任何反馈不能进行模拟。

　　3. 硬件在环系统

　　硬件在环（HiL）系统利用整合的实时模型，能模拟ECU的整个环境。

　　在实践中，所述系统之间的区分并不清晰。可以发现，在这些技术的描述中都有“硬件在环”。

　　RCM特性：防撞预警功能

　　防撞预警功能通过监测汽车天窗关闭时的电机转速得以实现，而监测又是通过1～2个霍耳传感器实现的。作为一项附加安全特性，电机使用的电力受到监测，并同时评估，因为电力与所产生的扭矩成正比。具有鲁棒性的碰撞识别会受到很多种外部干扰的影响，比如在最终关闭阶段，天窗被推入一个橡胶密封件中，所测扭矩和转数的级数和实际发生碰撞时的情景非常相像，通常仅在知道了天窗位置时方可区别开来（见图2）。

　　图2 顶棚控制模块的自动测试用硬件在环设置

　　外部干扰，如雨、雪或者灰尘，也可对天窗摩擦和克服这种摩擦需要的力产生强烈的影响。这还可干扰测得的扭矩和转数，从而进一步影响对碰撞的精确识别。为了对RCM进行有意义的测试，测试系统需要对这些力进行建模。公差范围和需测试的外部干扰使天窗的物理硬件不再适用。这不但需要制作仿真模型，而且还要为对问题的动态和相互依赖特性进行实时的仿真。因此，硬件在环是此案例中优先采用的技术。

　　方法

　　要替代电机和顶棚机械部分，需要一个能覆盖以下两个方面的仿真模型：电机可由永励直流电机模型来进行模拟，所需的参数，即机器常量，可通过对实际电机进行测量来获取；机械系统通过一个简化模型进行模拟，该模型载加了参数化的位置电流和变量。在多种环境条件下，包括实验室和现场测试，对实际天窗以及天窗反应作大范围测量（见图3）。

　　图3 硬件在环设置示意图

　　在本RCM实例中，被测装置（DUT）通过一个输入/输出硬件和信号调节（包括负载和故障模拟）连接到环境模型上。环境模型（包括CAN和LIN总线仿真）以1ms的循环时间在实时硬件上计算出来。电气故障仿真能对各种故障状况进行测试，如与控制单元各界面引脚相连的电缆连接中断或者灰尘积累造成阻力。诊断界面将所有诊断功能集成到测试中。

　　MBtech集团提供的方法本着实现尽可能最大灵活度的硬件，使客户能采用多家供货商的标准元件。这样，可最大程度地满足客户的特定需要，从小型开环测试系统到高度复杂的集成测试系统。但关键是，各硬件平台是受经协调的平台独立的软件模块控制的。为此，MBtech集团开发出了一个独特的模块化的PROVEtech工具套件。它提供灵活的界面，可结合本例中必需的客户所规定的开发项目。PROVEtech：TA应用程序为开发和运行测试程序，收集和管理测试结果以及仿真控制提供了标准化的图形用户界面。

　　PROVEtech：TA由数个功能模块构成，控制台对模型仿真的所有信号状况进行再现和处理。控制单元的输入信号可直接定义，并通过一组用户友好的小窗口作反应监测，可采用诊断模块进行手工诊断工作，电气故障模拟也可通过集成前端来进行。

　　尽管如此，可靠且可重复的测试只能通过测试自动化来实现。测试管理器结合了所有需要的功能：包括用Basic语言（包括调试、句法检查、版本控制等），在一个完整的集成开发环境中开发测试脚本，以及单个与系统测试的执行。测试结果（包括自动产生的日志和所有测得的数据）都能追溯到，并同时存储在实际测试运行中。加上测试脚本和测试协议，所有的信息均存储在数据库中，以便于对测试运行和当前成熟水平作后续评估；另外，PROVEtech：TA还提供一个附加的命令库，用于极端实时要求的测试。它能使测试脚本直接在实时硬件上运行，作实际的定时分析，并作同步检查。

　　运行实施

　　开发高质量ECU来自于所有相关合作方的持续合作。顶棚控制模块经历了多个开发阶段，成熟性状态，因此感兴趣的各团队需作相互协调，甚至是跨越多家公司之间的协调。

　　贯穿整个测试过程及元件的成熟度来实现透明度，需要有高度纪律，以避免多余的测试和测试间隙。必须实施包括从模型产生到车辆集成的所有步骤的一致的测试管理。这有助于查找各测试策略，便于相关人员制定测试计划，加强测试过程中所有步骤的文件归档的一致性（见图4）。文件归档包括测试概况（即所谓的测试矩阵）、测试规范和最新的问题跟踪。MBtech集团为客户实施开发以外的测试流程提供支持。接口为初始的需求文档（规范）和最终检测到的异常清单。功能开发小组在集中精力于其核心职责时，还可把测试作为一项独特的服务进行提供。

　　图4 车辆集成之外的从建模阶段开始的一致测试管理

　　在对一个专用的测试系统进行测试编程前，必须与RCM功能开发人员一起对RCM测试用例进行协调并作评估。制定测试的过程使测试编程更加有效，也避免了因对测试规范及其相应的测试程序作修改而造成的不必要的重复劳动。

　　对适用于特定测试用例的测试设备的选用和配置应在基于测试策略的计划阶段完成（即“工具跟随过程”）。测试在自动测试系统上编程、实施和执行。在本案例中，摩擦力之类的外部影响可能具有强大干扰（如在碰撞检测结果中），系统的极限测试参数已证实为一个成功的测试策略。这是零部件HiL测试的主要工作。集成的HiL测试集中在验证网络特性上，如车门与车厢内部照明之间的通信，或者雨水传感器信号的线路。车辆测试集中在可由用户作实际“体验”的功能性上。

　　结论

　　质量与可靠性在汽车电子开发中极为重要，因为即使是小小的差错也会带来成本的指数级增长。这意味着，在整个开发的过程中，进行一致的测试是成功的先决条件。测试与开发之间有效而有序的沟通必须从开始时就得到保证，以便尽早地发现任何错误，并最大限度地降低或排除这些错误的成本。