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