MIL SIL PIL HIL RCP 一文通

先来一个V流程

 系统仿真作为一种分析和验证的技术手段，属于典型的基于模型的设计（Modelbase Design）范畴。系统仿真再进一步细分，又可划分为控制系统仿真和物理系统仿真。特别的针对控制系统应用MBD技术时又可能涉及到以下概念：

• RT：Real-Time（特指Hard Real-Time），实时（硬实时）

• Soft Real-Time，软实时

• MiL：Model-in-the-Loop，模型在环

• SiL：Software-in-the-Loop，软件在环

• RCP：RapidControl Prototyping (别称RP)，快速控制原型（别称快速原型）

• PiL：Processor-in-the-Loop，处理器在环

• HiL：Hardware-in-the-Loop，硬件在环

• piL：pilot-in-the-Loop，人在环（航空领域）

• DiL：Driver-in-the-Loop，人在环（车辆领域）

1       实时与非实时

有关“实时”的分类如下图所示：

                                                                  图2 “实时”分类

是否“实时”依赖于运行模型的操作系统和相应软件。“实时”一般指硬实时仿真，其一定是依赖于硬实时操作系统。硬实时操作系统是保证在一定时间限制内完成特定功能的操作系统，其调度一切可利用的资源完成实时任务，并控制所有实时任务协调一致的运行。常见的硬实时操作系统有VxWorks、uC/OS-II、QNX、RT-Linux等。与“硬实时”类似的运行情况是“软实时”，软实时运行在非实时操作系统上，例如大家熟知的Windows操作系统。为了在非实时操作系统上实现“实时”的效果，这必须通过具备特定功能的软件来保证，例如通过具备定步长求解算法的Simulink或SimulationX工具实现。“非实时”分类还包括比“实时”运行时间快的“超实时”仿真，和比“实时”运行时间慢的“欠实时”仿真。可通过下图进一步理解相关概念。

                                                                图3 “实时”相关概念

2       在环仿真

在环仿真包括模型在环、软件在环、处理器在环、硬件在环和人在环，一般统称为XiL（X-in-the-Loop）。XiL概念常指MBD技术在控制系统设计和验证的应用场景中来说的，所以系统仿真中的物理系统仿真模型通常被称为被控对象模型，控制被控对象模型的控制算法或控制策略模型（通常指最终控制器产品的应用层功能模型）就是控制系统模型。控制系统模型和被控对象模型共同组成了基于模型仿真验证的核心模型。

2.1      模型在环

控制系统分为开环控制和闭环控制。模型在环也因此区分为开环控制和闭环控制。如下图所示：

                                                                        图4 开环控制

                                                                      图5 开环控制示例

                                                                        图6 闭环控制

                                                                        图7 闭环控制示例

开环控制相对于闭环控制简单。开环控制是被控对象模型数据无需反馈回控制模型的一种控制方式。闭环控制是被控对象模型有数据反馈回控制模型作为输入的一种控制方法。一般应用MBD技术进行复杂系统设计时，控制系统以闭环系统居多。应当指出的是，无论是开环控制还是闭环控制，最关键的核心模型都由控制模型和被控对象模型两部分组成，且模型在环是运行在非实时操作系统（例如Windows10）上的一种仿真技术手段。

模型在环是非实时的，为了不同的应用需求，可能要求软实时运行或超实时运行。往往超实时运行是最难的，因为应用者希望模型即准又快，但精度与速度是一对矛盾量，较高精度的模型会带来较大的计算量，在计算机资源和求解算法约束下会导致计算速度慢，进而导致仿真应用的等待时间长。有读者可能会问为啥没谈欠实时应用场景呢？这是因为没人愿意浪费时间，都希望通过提高工作效率来提高生产力。但是也无需担心，面对复杂大系统仿真时，几乎碰到的都是欠实时仿真，届时就会想破脑袋提高仿真速度。满足超实时仿真的模型运行可以人为拖慢仿真进度来实现软实时或欠实时，但是欠实时提高速度将是一件困难的事情，依赖于模型实时化技术，例如降阶模型方法、白盒模型变黑盒模型的等效替代方法等，无论那种方法都严重依赖于您的仿真经验积累。

模型在环在设计阶段的早期就可使用，尤其是硬件环境还不具备的情况下是唯一可用的设计手段。控制算法设计过程中设计需求和实现方案都可能在不断变更和调整中，模型在环可以快速的调整校准控制参数、验证控制算法。即使在设计的后期阶段，面对实物试验台不便于试验或试验造价高昂的工况，也可使用模型在环方法提前进行虚拟试验探索和工况设计，为实物试验提供指导依据。同时，经过标定和实时化处理的模型也可作为HiL（稍后介绍）中的实时模型，参与故障注入模式的测试和验证等应用。

2.2      软件在环

软件在环是针对MiL阶段的控制模型编译生成的C代码/DLL文件进行的测试。MiL与SiL的区别只在于控制算法存在的形式，前者是“模型”，后者是将“模型”编译成了“代码”。

                                                                        图8 软件在环

SiL的主要目的是在非实时的Windows操作系统环境下比较基于“控制模型”编译获取的“控制代码”与原“控制模型”的一致性，测试编译过程中可能引入的Bug，例如基于Simulink工具提供的Coder和调试测试功能模块将控制模型编译成S-Function代码模型进而开展对比测试。所以，SiL仿真是否有必要组成“闭环系统”，即控制代码与被控对象模型耦合仿真，需要根据具体应用情况来定：（1）对于控制与被控对象反馈数据耦合不紧密的则无需“闭环系统”；（2）反之，SiL只需要复用MiL的被控对象模型即可。SiL是一种等效性测试，可复用MiL阶段的控制模型测试用例，即在同一环境下，给控制模型和控制代码同样的输入，比较MiL的测试输出与SiL的测试输出结果的偏差是否在可接受的范围之内。如果偏差超出设定范围，则需要查找出现此问题的原因，进而排除潜在的Bug。

SiL还可以集成非通过模型编译生成的代码，例如通过手写实现的功能代码或经过确认的其他代码，进而开展覆盖率测试。这时的测试用例以量取胜，尽量覆盖所有路径分支。如此之多的测试用例仅仅通过复用MiL阶段的测试用例还不够，市面上提供了自动测试用例生成的工具来辅助完成此工作，当然用户也可以通过简便易学的脚本语言，例如Python，编写测试用例自动生成和测试的脚本软件。

SiL将模型编译成了代码形式，计算机直接运行代码模型要快于运行纯模型的仿真，因为中间少去了较为耗时的模型编译过程。正因此，SiL代码形式的模型应用带来了额外的好处，当面对模型和计算量很大导致仿真速度下降的应用场景时可以通过SiL方式来提高仿真速度。

2.3      快速控制原型

在控制器开发的初期阶段，需要快速地建立控制模型，并期望在实际的控制器硬件上运行调试控制代码。但受实际研制进度的影响，控制算法或控制策略很可能早于实际的控制器硬件而开发出来，这时在最终控制器硬件产品需要而不得的情况下，替代方式就是选用“通用”的快速控制原型硬件来辅助完成控制代码与硬件耦合的测试。例如dSPACE公司提供的MicroAutoBox II 产品，可用于多种快速控制原型开发应用，可应用于动力传动系统、车身控制、高级驾驶辅助系统、x-by-wire 应用以及航空航天应用等。（这里不是打广告，只因是比较知名的厂商产品，但欢迎金主来Modelica公众号投放广告($ _ $)）控制器快速原型也可以选用上一个版本的产品硬件充当，无论选择通用的还是上一个版本，其根本目的是作为控制器最终产品研制过程中的过渡手段，帮助控制器产品定型提供可靠的代码测试和辅助硬件设计。RCP涉及硬件，其应用一定是实时仿真。

                                                               图9 快速控制原型 

快速控制原型（Rapid Control Prototype，简称RCP）。实时硬件运行Simulink控制算法（模拟控制器），控制真实被控对象（如开关、电磁阀、电机、发动机等），快速验证该Simulink算法。此时实时硬件可以看作是原型的控制器，通过这种方式我们快速地得到了一个原型控制器，对原型的控制算法进行测试，故称之为快速控制原型。此时，被控对象是真的，控制器是假的（所谓控制器是假的，并不是说控制器是虚拟的，而是控制器不是客户的最终控制器）。

为什么要做快速控制原型

当用户开发出了相关的控制算法后，他可能已经通过电脑仿真的方式对算法进行了初步的测试（此测试中，控制算法是Simulink模型，被控对象也是Simulink模型，仿真测试纯粹在电脑中运行）。在这个初步的仿真测试之后，用户希望进一步验证该算法，此时一个比较合理的方式是让该控制算法去控制真实的被控对象，在更加真实的环境中对算法加以测试。

这时候就遇到了一个很明显的问题：用户开发的控制算法是一个Simulink模型，是虚拟的东西，没法直接去控制真实的被控对象。比如一个真实的电机，它可能是被PWM信号或者模拟信号控制的，而我们的电脑是没法发出这样的信号去控制电机的，需要专门的硬件去发出这样的电气信号。这时候，传统的方式中，用户会自己去开发一个硬件，并且撰写调用硬件资源的代码，然后把控制算法部署到硬件中。这种方式有几个缺点：

① 用户需要自己开发硬件和底层代码，费时费力

② 用户自己开发的硬件和底层代码，可能存在bug，后期使用的时候，一旦出了问题，调试又是费时费力

对于很多用户来说，他面临两种状况：

① 他专注的是应用层的控制算法，根本不关注底层和硬件，完全没有必要自己去开发硬件和底层。硬件和底层只是他用来测试应用层控制算法的辅助工具。

② 用户也要开发自己的硬件和底层。如果按照从传统瀑布式的开发方式，用户想测应用层算法，必须先得等自己的硬件和底层开发完毕，然后三者集成在一起进行测试，这种方式的开发和测试流程非常长，大大延长了产品的上市时间。用户很希望在硬件和底层没有ready之前，就能对应用层算法进行全面的测试，发现和消除大部分的bug。这样等到硬件和底层ready之后，整个测试工作就会轻松很多。

对于这些用户，他们有一个明显的需求，就是：有人能给他们提供一个成熟的、无bug的硬件，同时给他们提供这个硬件的底层（一般是Simulink驱动模块），让他们能够直接将应用层算法下载到这个硬件中，使得他们可以直接用这个硬件去控制被控对象，在实时的环境中验证应用层算法。So，快速控制原型应运而生！

RCP中的原型控制器，一般具有如下特点：

① CPU、内存等配置高，用户无需担心硬件资源够不够的问题，比如如下典型配置

② 易于将Simulink模型编译、下载到原型控制器中（一般通过网口下载）

③ IO及通讯接口灵活且丰富，能够满足不同应用的需求，不同应用的接口需求也是大不相同

④部分应用要求快速控制原型设备便携、抗震抗冲击，比如车载快速控制原型应用。

MATLAB/Simulink有多款代码生成工具，RCP和HIL用的都是MATLAB Coder和Simulink Coder，而生成产品级代码用的是Embeded Coder。遇到一个比较常见的问题是：RCP的时候，为什么不用Embeded Coder，而用MATLAB Coder和Simulink Coder？这是因为使用Embeded Coder的时候，用户需要做定标之类的大量工作以优化生成的代码，提高代码在硬件上的运行速度。在RCP阶段，用户主要关心他的Simulink模型的功能逻辑是否OK，而不是生成代码质量。借助于MATLAB Coder和Simulink Coder，用户无需关注定标、硬件资源等一系列事情，只需在Simulink中点击Build将应用层控制算法模型编译下载到快速控制原型设备中。

所以快速控制原型最大的意义在于，帮助用户快速地构建一个原型控制器，这个原型控制器可以跟真实被控对象相连，在实时环境下验证用户的应用层算法。

2.4      处理器在环

处理器在环是指利用目标控制器的编译器对控制模型生成的控制代码编译后下载到目标处理器上运行，根据控制算法与被控对象模型的耦合程度，可以选择是否需要闭环进行仿真测试。PiL和SiL验证思路非常相似，最大的不同之处就是控制器的代码运行环境不同，SiL是在PC机上运行控制代码，而PiL是在目标处理器上运行控制代码。此外，PiL和SiL应用过程中将控制模型编译成控制代码的编译工具也不同，前者是目标控制板处理器配套的编译器，后者是Windows下的编译器，例如Visual Studio C++。

                                                                        图10 处理器在环

虽然SiL阶段已经对控制代码与控制模型的一致性进行了初步测试，但控制代码是运行在Windows平台上的，从某种程度上说这还不充分，因为这不能保证控制代码下载到目标处理器上运行的结果也能够和控制模型保持一致。此外考虑到控制代码不是完全从模型生成的，可能会增加用户手写代码时，那么通过PiL的进一步测试更显得必要。另外，PiL可以确定产品控制代码在目标处理器上的运行周期以及内存的占用情况，这些测试数据在所有软件功能模块集成之前对软件CPU负载、软件可能跑飞的风险评估、最终控制器硬件组件的选型确认和设计确认具有非常大的帮助。

根据不同测试需求，PiL运行的测试用例来源可以是MiL阶段的测试用例，也可以是SiL阶段的测试用例，可以是开环仿真也可以是闭环仿真。大多数情况选择SiL的测试用例并与SiL测试结果对比。PiL的测试数据最终会传输到Windows操作计算机上，通过与SiL或MiL的输出比较，如果两者之差在容许范围之内，则测试通过，否则需要查找原因并修复潜在Bug。

• 示例：应用Simulink开展PiL时，控制代码的运行载体有三种模式：

• 运行在目标处理器上，处理器与Simulink通过串口/CAN等实现物理数据通信；

• Simulink通过IDE链接处理器，Simulink与IDE之间通过PiL应用接口实现虚拟通信，IDE与处理器之间通过IDE Debuger实现物理数据通信；

• 不需要硬件，通过IDE的指令集模拟器模拟硬件，Simulink与IDE之间通过PiL应用接口实现虚拟通信。

2.5      硬件在环

硬件在环仿真，又称半物理、半实物仿真，是指将控制模型生成代码下载到目标硬件上运行，被控对象模型也生成代码下载到实时仿真机上运行，目标控制器硬件和实时仿真机之间进行通信，形成闭环实时仿真。这时的被测控制器产品已接近最终形态，包括了硬件、底层驱动软件和应用层软件。

图11 硬件在环

HiL是一个应用比较宽泛的技术，根据被控对象是否为实物，分为三种常见应用场景：

• 真实控制器+虚拟被控对象

被控对象模型为实时模型，运行在实时仿真机中，控制器与实时仿真机通过硬件IO通道进行数据通信。因为被控对象模型和IO通道信号是用户可控的，从而可实现对不同工况的模拟。此种解决方案特别适用于在控制器软硬件不成熟的条件下，运行出错可能会导致人身伤害或者重大财产损失的情况。在开发过程中，被控对象开发和实物生产往往滞后于控制器的开发，应用此方案可避免控制等被控的情况，及早的开展控制器的测试工作。另外，HiL测试通常比实物测试更节省成本，比如，做汽油机台架测试，需要消耗大量的汽油，而通过HiL测试汽油机控制器，就没有汽油消耗。

• 虚拟控制器+真实被控对象

此应用场景的目的是测试被控的物理对象实际产品，通过补全控制环节来满足物理实物对象的外围测试环境，进而更合理和全面的开展测试。此时的控制器并不是最终产品形态的控制器，可能是功能简化的、替代的RCP。

• 真实控制器+真实被控对象

这就是通常所说的物理实验台。针对控制器的HiL测试，并不是说做了“真实控制器+虚拟被控对象”测试场景就可以替代实物测试，HiL测试之后，通常会跟着做实物试验的测试进行产品的最终验证和确认。

可能会有读者有疑问，为什么不开展“虚拟控制器+虚拟被控对象”的HiL仿真测试，其实没必要，因为全虚拟的测试已经在MiL和SiL阶段进行过验证了。此时的全虚拟HiL（或者叫实时的MiL）意义不大，通常的考虑是尽早开展测试，绝不把MiL和SiL可以解决的问题遗留到HiL阶段解决。

2.6    人在环

人在环在不同的领域有不同的名称，例如汽车领域叫Driver-in-the-Loop，航空领域叫pilot-in-the-Loop（此处的缩写piL中p是小写，与处理器在环PiL区别）。

人在环是建立在HiL基础上的有人参与交互的实时仿真系统，目的是测试人的操作对被测系统的影响。以上阶段的测试用例对控制算法或控制器进行了较为充分的测试，但并不能反映人的影响因素，例如不同驾驶人员对驾驶汽车的油门和刹车的踩踏力度不一，此外人员可能引入误操作等。人在环解决了通过人的参与进一步测试控制器的可靠性和安全性。此外，经过标定的人在环系统也可用于人员训练使用，使驾驶人员提前熟悉所开发的设备系统。

                                                  图12 人在环

3    总结

本篇针对系统仿真技术范畴的控制系统测试和验证技术，详细介绍了实时与非实时概念，各种XiL（MiL、SiL、RCP、PiL、HiL、piL）的原理、技术特点、应用场景和用途。可见，先进的MBD技术将有利促进和提高产品设计效率和质量。本篇虽较为全面的介绍了各种XiL技术，但这并不是要求在实际的控制器产品设计研发中要将所有的XiL都开展实施。实际应用中要根据测试需求、所具备的技术储备、软硬件购置情况等合理的选择XiL技术手段为您所用。

以上内容参考来源如下

微信公众号modelica

及原文链接：https://blog.csdn.net/weixin_39874366/article/details/112326927