标签: 闭环测试

上篇我们介绍了单元级软件的PiL测试（ PiL测试实战（上） 模型生成代码的单元级PiL测试-面包板社区 (eet-china.com) ） ，对于集成级的PiL测试，其流程和单元阶段基本一致。然而，对于一些带有反馈控制逻辑的集成测试（如电机控制器MCU），PiL阶段会将控制算法（Controller Model）刷入目标板，那如何带着位于PC端的Plant Model一起进行闭环测试呢？ 图1 PiL阶段的闭环测试流程 下面我会为以一个座舱温度控制（ClimateControl）软件为例，为大家展示基于TPT Fusion-Platform的PiL阶段闭环测试解决方案。 ClimateControl软件功能介绍 ClimateControl软件可以通过设定温度和当前座舱温度自动的控制汽车座舱的空调、暖风开启/关闭以及风机的转速，从而实现自动调节座舱温度的功能。其中Controller Model为主要控制逻辑的实现。 为了对Controller Model的功能在仿真条件下进行验证，我们搭建了模拟座舱环境的Plant Model，Plant Model通过一些预设条件以及Controller Model的控制来模拟座舱温度的变化。其中Plant Model输出的座舱温度信号会反馈到Controller Model实现反馈控制。 图2 ClimateControl控制逻辑示意图 在进行PiL测试时，我们会将Controller Model进行代码生成、编译并刷入目标板，而Plant Model依然在PC端运行。那么如何实现不同环境下的Controller Model和Plant Model之间的通讯呢？ TPT Fusion-Platform Fusion-Platform是TPT提供的控制软件的软件集成平台。它允许将多个软件模块（称为“节点”）相互连接，并将它们作为单个系统执行。Fusion节点一个接一个地处理，共享Fusion平台内存，进行数据交换。 这些节点可以支持dll、UDE、Trace32、XiL API、CAN等类型的平台，因此可以很方便的实现不同环境下的软件间的通讯。 图3 TPT Fusion-Platform 基于TPT Fusion-Platform的强大功能，我们可以很方便的实现ClimateControl软件的闭环测试，即：位于目标板的Controller Model（PLS UDE节点）+位于PC端的Plant Model（dll节点）。 测试环境配置 首先我们需要在TPT中新建一个Fusion-Platform。并对运行步长、最大运行时间进行简单的配置。 Custom Node dll节点配置 对于Plant Model，由于需要在PC端运行，我们可以将其转成dll的格式（TPT提供了把模型生成dll的tlc文件，并且可以在TPT端实现从模型到dll的一键生成）。在Fusion-Platform新建一个Custom Node dll节点，并加载dll文件，导入接口信号。 图4 Custom Node dll节点配置 图5 Plant Model的接口信息 PLS UDE节点配置 Controller Model我们需要将其进行代码生成、编译后刷入目标板。TPT可以通过UAD与目标板进行通讯，因此我们需要在Fusion-Platform中再新建一个PLS UDE节点。PLS UDE节点中的接口信号可以通过c文件导入，其他配置过程和我们上篇中的PLS UDE Platform的配置过程完全一致。 图6 PLS UDE节点配置 不同环境间的信号Mapping 在我们配置好Fusion-Platform的节点之后，便可以实现不同节点之间的信号交互。但是由于不同节点之间的信号接口数量、接口名称存在不一致的情况，因此我们需要做一些简单的信号Mapping工作： 仅在一个节点中存在的信号（例如发动机转速信号，仅存在于Plant Model）：需在另一个节点中对该信号进行Hidden； 两个节点中均存在但名称不同的信号（例如反馈信号，Controller Model中为“IntTemp_K”，Plant Model中为“IntTemp_K_”）：需要在“External_Name”中设置其外部名称进行Rename。 图7 信号Mapping 闭环测试的实现 做好这些配置工作之后，我们便可以在TPT中搭建测试用例，来进行闭环测试了。TPT会同时调起两个不同环境下的节点，实现PiL阶段的闭环测试。 这里我在TPT中搭建了一个简单的测试场景：外界温度-5摄氏度，座舱设定温度18摄氏度。我们可以运行测试用例在TPT中观测各信号的变化情况。 图8 “-5到18摄氏度”升温测试 图9 信号变化情况 通过信号窗口可以看出，当座舱温度低于设定温度时，Controller Model会控制暖风机使能信号使能，打开暖风机。与此同时，Plant Model会通过发动机转速、扭矩等信息计算出座舱温度变化并反馈至Controller Model，实现闭环反馈控制。 so...这个方案是不是很完美？感兴趣的小伙伴快来试一试吧。

CANoe作为全球知名的总线仿真测试工具在汽车行业得到了广泛应用，与此同时，CANoe在ECU测试领域也不断扩展，基于VT的自动化测试方案在车身域的ECU领域也早已成为了主流。 借助于不同的软件接口和第三方标准接口协议 FMI （ Functional Mock-up Interface ， 功能模拟接口 ） ，CANoe得到更深入的应用，不仅能支持从MIL到SiL到HIL的不同测试阶段，同时也能支持各种常用的车辆动力学模型（如 TESIS公司的DYNA4、IPG公司的CarMaker、MSC公司的 Ada ms /Car ），进行ADAS等领域的ECU测试。 北汇信息作为 Vector 在中国的合作伙伴，将为客户提供全方位的支持和高效的测试解决方案。 CANoe与 Simulink 的接口 只需 将 CANoe提供的 “ CANoe MATLAB Integration Package ” 安装到所支持的 MATLAB 版本下， CANoe的应用层 （ CANoe IL ） 便可 借助Simulink中的CANoe blockset 直接访问模型中的信号 ， 此时Simulink模型 可 视为CANoe中的一个CAPL节点，可以通过编译生成支持CANoe的 动态链接库 DLL 实现在CANoe 中 仿真。 然后将DYNA4模型生成动态链接库DLL，只需通过一个简单的按钮就可实现无缝导入作为CANoe中的仿真节点。 而DYNA4的优势在于其基于Simulink的模型与模型参数化是独立的，可以从DYNA4框架 快速实现 针对不同车型，不同路况（测试用例）的模型 参数调整 。 其余 总线仿真可以通过CANoe实现 ，例如，通过启动面板上的指示灯开关。这样，带道路和交通情景的驾驶任务在DYNA4中完成了准备和管理，它将从测试管理工具开始，在ECU算法测试发生时作为场景。 下图 这个演示系统展示的是在一个HiL测试环境下的基于摄像头的LDW控制单元测试。 CANoe用于执行所有仿真，并且通过USB-CAN-Adapter作为所有硬件的接口；DYNA4用于生成在特定道路下行驶的车辆模型以及环境模型 ，所生成的道路及环境动画将在显示器中显示；LDW ECU（包括摄像头）作为硬件并且放在显示器前，这样它可以拍摄到显示器中的虚拟路况，LDW ECU处理这些图像信息，并在车辆偏离车道时通过CAN总线发出警告。 如果检测到意外的车道偏离，振动反馈将通过CAN总线从 CANoe 发送到方向盘，向司机发出警告。 CANoe支持FMI FMI是一个独立的工具，可用于不同厂商的工具之间交换仿真模型 （ Functional Mock-up Units – FMU ，功能模拟单元 ） ，实现CANoe和其它仿真工具（如 CarMaker ， Adams/Car 等）之间的协同仿真。 FMU是黑盒模型，有助于 保护 模型所有者的知识产权。 对于整车厂而言，可以在早期就对供应商提交的FMU方式的应用软件进行验证，也可以对于FMU进行标定。 对于CANoe的使用者来说，可以将开环测试扩展为闭环的功能测试，这时就需要复杂的驾驶环境的模拟。 对于CAE工程师而言，也需要在虚拟的仿真环境中，加载一个仿真的部分或者全部的车辆网络。 CANoe 作为FMU 导出 目的：提供一种工具耦合 可以在 选择 需要导出的 信号或系统变量； CANoe 和 配对的 工具都可激活和运行——通过以太网 实现数据交换 ； 支持 FMI 1.0 和 2.0 。 FMU导入CANoe（支持8.5 SP3及以上） 目的：用 CANoe 加载和执行不同来源的模型 输入、输出或参数映射到系统变量；支持针对联合仿真的 FMU s ，不支持针对模型交换的 FMUs ；使用XCP标定FMU；CANoe的仿真步骤支持离线模式；支持 FMI 1.0 和 2.0 。