对HIL台架系统的一点认识

2024-10-22

阅读数：

作者 | 谦益行

出品 | 汽车电子与软件

曾经从事软件开发工作时，经常会与HIL测试打交道，有使用过HIL台架进行软件开发的测试验证，也有过辅助测试同事来设计测试用例，以及验收HIL台架的仿真模型等内容。曾经从事ECU系统工作时，有幸深度参与过HIL台架的需求定义；曾经也从事功能开发工作时，也深度思考过如何利用HIL台架更好地进行功能的开发和验证。因此，本文打算就个人对HIL台架的认识和思考，稍作分享。

#01

为什么需要HIL台架系统

首先第一个问题，为什么需要HIL台架系统？这是因为从整车研发流程来看，不管是在整车的系统层级，或是ECU的系统层级，还是 ECU软件层级，这些层级都有大量的设计开发内容。开发需要测试验证这是毫无疑问的，关键点在于用什么样的环境或设备来进行测试验证。

这些测试验证工作不可能都使用整车来进行，因为：

一是需求的整车数量巨大，成本巨高，耗时巨长；

二是开发的不同步，不管是在哪个级别都无法完全协调一致。

因此，在这样的事实之下，各个层级都需要明确自己的测试需求，进而去构建各自的测试环境，也就是HIL台架系统。

Source： 电子控制单元（ECU）HIL测试 | HIL仿真

以ECU的系统层级为例，其主体是ECU，一方面需要验证ECU与外界的信息交互功能，另一方需要验证自身的产品功能和性能。

因此在这个层级进行ECU的系统测试，那么ECU应该具备下列的一些条件，在信号输入方面有：

供电方面 ，是指电源和接地GND，比如KL30，KL15和KL31；

感知方面 ，是指各种传感器信号，比如温度、压力和速度等，具体取决于ECU的用途；另外信号涵盖模拟信号形式，数字信号形式，频率信号形式以及协议形式等；

通讯方面 ，主要有CAN通讯、LIN通讯、以太网通讯和SPI通讯等。

在信号输出方面有：

通讯方面 ，通讯与输入的通讯方面一样；

执行方面 ，主要指功率器件类、电磁阀类和电机类的控制。

也就说要进行完整的ECU的系统测试，这些条件都应该具备。而对于单独的ECU而言，显然很多信号的输入和输出都需要去构建，因此HIL台架系统的需求就应运而生。

#02

如何定义HIL台架系统

我们需要HIL台架系统做什么，决定了我们如何去定义。不同层级对于HIL台架系统的需求可能有所差异，但是在HIL台架系统所具备的硬件配置是基本一致的。

2.1 硬件能力

首先是根据ECU的Pin脚定义情况，确定HIL台架的输入和输出能力，包括：

电源方面 ，HIL台架系统需要提供足够的电压或功率能力，电压范围多少，功率范围多少，载流能力多大。

输入方面 ，HIL台架系统需要提供足够的输入通道。比如模拟信号，数字信号和频率信号的输入通道数量分别是多少，电压范围是多少，频率范围是多少等；对于输出方面也类似。

通讯方面 ，HIL台架系统需要提供足够的通讯类型和通道，比如：

需要具备多少路CAN/CAN FD通道，多少路LIN通道，多少路以太网通道；

需要支持SENT协议，SPI协议或AK协议等。

然后是根据故障诊断需求，需要提供足够的故障注入的类型和通道，以支持诊断的需求。

最后可能还包括提供一些负载的模拟或者替代等。

2.2 软件能力

HIL台架系统的软件能力，主要包括两个方面，一个是HIL台架系统本身的软件能力，另一个是HIL台架系统所能提供的ECU软件仿真能力。

关于HIL台架系统本身的软件能力，借助dspace产品来进行说明，主要包括以下几个方面：

对上述所提供的硬件能力，需要有相应的 软件平台进行实时硬件的配置 ，像ConfigurationDesk能提供较好的图形化配置。

需要提供 测试用例的编写和测试自动化的软件 ，像AutomationDesk可以使用户能以图形格式创建和编辑测试程序，无需具备编程技能。

需要提供 丰富HIL测试状态和进度的可视化 ，像ControlDesk用于开发ECU的通用模块化实验和仪表软件，让测试人员更容易接收到测试的信息和状态。

需要 HIL测试的数据管理与协作软件 ，像SYNECT提供了从需求到测试结果的完全可追溯性，与ALM工具和过程集成，以弥补与实际测试执行之间的差距，这样便于软件测试的管理，也优化HIL利用率。

Source： 电子控制单元（ECU）HIL测试 | HIL仿真

关于HIL台架系统所能提供的ECU软件仿真能力，主要指ECU控制的Plant（物理）模型。对于Plant模型主要取决于ECU控制的是什么，MCU对应电机模型，动力总成域控制器对应整车的动力学模型。相对于供应商，OEM对于HIL测试系统的需求更多在于验证应用层软件的功能和性能，这样就需要依托强大的物理模型进行测试验证，即需要HIL测试系统提供强大的建模能力，比如针对动力总成系统的HIL台架测试系统，物理模型可能就包括发动机模型，变速箱模型和车辆动力学模型等。

source: Top Level of Vehicle Plant Model | Download Scientific Diagram

以上就是关于HIL台架系统的主要需求，目前国内HIL台架系统的主流解决方案来自几个平台：dSPACE平台， NI平台，Vector平台和Mathworks平台。总的来说，这些平台都具有各自的优势，有的成本低，有的易于维护，有的便于扩展。对于如何选择这些平台，最终还是看自己的需求。这些平台基本都能保证功能实现，主要看自己的会偏向于哪个特性。

#03

如何验收HIL台架系统

当定义好了HIL台架系统，接下来就是供应商去设计和制造，然后需求方再进行验收工作。

HIL台架系统的硬件能力，这些是供应商必须实现的，通常都没啥问题。

HIL台架系统的软件能力，这些需求通常不够清晰，边界不够精准，因此是验收重点。

曾经碰到过动力总成的Plant模型问题，虽然经历过多次的技术沟通，但最终给出还是相对折衷的交付物。其原因是软件或模型这块属于定制化需求， 我理解的并不一定是你所理解的 ，此时供应商的技术人员就特别重要，一方面是否对方是否真正理解了你的需求，另一方面是对方是否具备足够的能力去实现你的需求。

这里举一个例子，假设要求HIL的电机模型支持转速控制和转矩控制，如果只是简单这样一条需求， 那么实现方案是存在多种可能性，比如：

最简单的话，直接做转速和转矩层面的PI控制就行。

稍微复杂的话，采用电机控制算法来实现电机转速和转矩控制。

再复杂的话，建立电机控制及其本体模型，能反馈电机的电流电压等参数状态。

这样我们不难理解，随着需求的详细程度和复杂成不同，对HIL台架系统软件能力将会产生巨大的影响。因此，对于这块的需求最好事先调研清楚，十分清晰自己的需求。

#04

如何使用HIL台架系统

当HIL台架系统有了之后，那么接下来的关键点在于使用HIL台架系统的测试人员， 对于HIL测试人员有以下几个核心要点：

台架搭建 ，包括HIL硬件本体和外围相关硬件配置的使用和连接，以及HIL软件测试环境的构建和配置等。

HIL测试 ，包括信号的模拟和仿真，测试用例的编写、运行、评估和管理，测试问题的分析和解决，以及测试场景的构建操作等。

功能/软件开发 ，主要与功能相关的控制策略和物理模型开发。

对于以上这几点，前两点是HIL测试人员必须具备的技能，第三点会随HIL台架系统所使用的需求层级而变化，就下图所示的一个HIL测试工程师的招聘岗位职责：

该岗位要求对功能开发有所掌握，可以继续看下该岗位的人员要求，如下所示：

总的来说，对于在OEM的总成系统层级的HIL测试，通常会要求对功能开发有了解，同时最好还具备搭建Plant模型能力，这样还能更加高效地使用HIL台架系统进行功能的开发和验证工作。

而对于供应商的ECU系统层级，使用HIL台架系统主要进行两大方面的测试验证给工作，包括：

ECU与外界环境的信息交互验证，比如与其他ECU的通讯，传感器信号的采集和外部执行器的驱动等。

ECU自身产品功能和性能的验证，比如正常情况下，电机控制器的转速和转矩控制，整车控制器的上下电管理，扭矩控制等，或者非正常情况下，故障的诊断及处理等。

总之，ECU系统层级的HIL测试涵盖了ECU硬件和软件的设计验证，通常在汽车研发体系中还有ECU软件层级的HIL测试，相对于ECU系统层级是针对ECU系统需求的验证，ECU软件层级的HIL测试是验证ECU软件需求及详细设计。

如下示意一种BMS状态机，当对该状态进行HIL测试时，出现了某一步的状态异常跳转，虽然从控制整体状态上没啥影响，ECU系统层级的HIL测试可以不关注这个点，但是从ECU软件层级的HIL测试角度，这种情况则不能出现，因为不符合软件需求或软件的详细设计，因此需要对此问题分析和修复。

因此相对于ECU系统层级的HIL测试，ECU软件层级的HIL测试工程师需要对ECU的控制策略和逻辑有更深入的理解，这样才有助于去设计相应的测试用例。总的来说，在ECU软件层级的HIL测试，HIL测试人员最好能懂 软件代码或模型 ，从而才能更好地使用HIL台架系统进行软件功能或性能的测试验证。

#05