现在的系统已经变得相当复杂，以至于在很多情况下验证硬件、软件功能以及正确性的唯一方法是在循环（HITL,或者有时候也说成HIL）中使用硬件。那么HITL是什么？答案很简单：视情况而定。大部分讨论都把HITL描述为一个由软件驱动的系统，这个系统具有模拟和数字I/O口，跨越基本开关闭合包到RF，试图复制你的设计必须工作的系统。

有关HITL使用的最常见的例子是汽车，这很有意义，因为每个人都知道汽车是什么，了解其各个子系统的复杂性和多样性，并且对测试汽车电子产品的挑战性至少有个基本的认识。在一个常见的与汽车相关的HITL场景中，设计者必须评估引擎控制单元(ECU)的硬件和软件性能--这种情况似乎需要将其连接到一个真正的引擎上。

软件建模方法

但是将ECU和真正的引擎连接起来并不是必须的。通过使用HITL方法，ECU在评估中被连接到一个包含相关引擎连接器的电子机架上，所以这个引擎本身就可以由机架上的软件表示，也就是说这个软件模拟了一个真实的引擎，如图1所示。显然，在变化、测试场景、噪声、诱导传感器、接口、引擎的弯头结构以及故障等方面，使用HITL方法要比使用真正的引擎更简单。HITL也很适合测试电机的控制器以及任何与机械性能电子控制相关的东西。

图1：在经典的HITL设置中，通过利用真实的I/O口，使得待管理的系统被硬件和软件取代，这些I/O可以模拟和仿真实际的系统，比如一辆汽车(显示)、火箭、马达或其他复杂的产品。(来源:国家仪器)

但是，HITL的节奏并不是很快或者很容易。主要项目是开发电子机架和取代真正引擎的软件。通过方程和功能块，它必须能够如实地模拟真实引擎的性能以及细微差别，从基本功能开始，然后添加关键层，子层，以及子层的子层。实际上一个模型开发团队可能比产品开发团队更大。

还有一个测试问题:如何验证一个模型? 在实际引擎的HITL模型中，任何简化、忽略、错误假设等因素都意味着ECU的测试不会像使用真正的引擎时那样有效，当然，这只是一个简单的观点。(这里可以用一句著名的短语--“垃圾进来，垃圾出去”来类比我所表达的意思。) 然而，实际情况是，任何一个真正的引擎都不能代表所有的引擎，所以即使使用了真正的引擎，测试也只对特定的引擎类型有效。HITL的方法更好，因为它更容易修改以模拟不同的引擎。

比例模型方法

针对HITL还有另一种非常不同的方法，这种方法涉及到真正的硬件，而不仅仅是基于软件的表示。然而，这种方法使用的不是全尺寸硬件，而是一个缩小版，其较大的对象和系统也被更小的对象和系统所取代。经典的风洞模型是这种方法最著名的例子，但它也被用于诸如汽车以及他们的发动机等功能；Keysight技术的应用注释5991–2873EN是第二种方法的一个很好的例子。

这种方法的优点是，您不必创建一个真实详细的引擎或者飞机模型。但它也引发了一些难题: 如何缩小发动机、引擎或飞机的控制分析，以匹配物理小模型的特征? 毕竟,很多事情都是不同的：时间常数，热性能，动量，惯性，瞬态响应…(这是一个很长的列表) 这种方法增加的挑战是，有些因素是线性的，有些是指数级的，有些是不连续性的，而有些关系很复杂。

选择一个HITL的方法

哪个HITL的场景更有用？同样，这取决于特定应用，有效时间，成本以及对系统本身的理解程度。我所知道的，除了一些较为简单、定义良好并严格约束的系统外，借助于详细的、基于软件的模型，使用HITL来模拟实际系统似乎是首选的方法。

原因有很多：这种方法能够表示相似硬件不同变体的灵活性，例如引擎；结果的可信度更高；操作的成本更低和并且更方便(与使用真实的马达、汽车发动机、火箭以及电子设备相比较)；建立模拟故障场景的更简单;并且可以轻松地设置多个系统，这样就可以并行地进行测试，从而节省了时间，团队之间也可以相互学习。

不管你采用哪种方式，不仅仅是汽车和火箭设计需要HITL，与运动或者动力相关的设计都需要HITL。如果你正在测试一种光电、风能或电池控制器，使用HITL方法要比利用实际的太阳能电池板、风力涡轮机或电池堆更容易。更好的是，对于这种类型的产品，您可以从各种T&M系统供应商那里购买现成的、完全可编程的仿真器，例如Keysight技术，从而将一个大问题转化为一个小的问题(图2)。这就是产品开发工程师们喜欢听到的！

图2：标准的测试和评估产品适用于许多通用的应用程序，例如千瓦/水池 单元。它可以被用来测试可充电电池、超级电容器、电动发电机、双向dc/dc转换器、电池管理系统、再生制动系统和光伏阵列等系统。