工作太忙，这篇文章断断续续花了2个月才写出来。

累。

所以看名字就知道我是怎么干的：这是SCANeR和Simulink联合仿真的一个例子。

所以你要想看懂这篇这篇文章，我是默认你会Matlab/simulink和SCANeR（ANSYS版本）这两个软件的。

另外，本案例也想借助AEB功能的实现来演示搭建一个模型在环（MIL）测试的开发流程。

先来看看目录：

1. NCAP-AEB场景

2. 实现方式及逻辑框架

3. SCANeR中设计一个AEB场景

4. Simulink中的模型搭建

5. 效果演示

6. 完善场景

7. 算法测试

1、AEB的法规场景案例

在NCAP中挑选一个车对人的AEB场景-CPFA。

标准描述："远端场景下，行人以6.5km/h 的速度以与车辆行驶方向垂直的方向移动。VUT 分别以20km/h，30km/h，40km/h，50km/h 和60km/h 的速度测试。碰撞位置在25%和50%处，对应下图中的M点和L点。

图片来源：CNCAP2021法规

为了方便场景模型搭建，我们再具体点描述一个场景：

行人横穿速度为6.5km/h，车辆速度为30km/h，碰撞点位置设计为50%。也即CPFA50。

法规里对场景结束条件的描述：

单次试验结束条件

以下条件之一发生时，试验结束：

a）VUT = 0km/h；

b）VUT 和PTA 之间发生接触；

c）PTA 离开VUT 行驶路径；

哦，看不懂上面这些专业术语的也建议去翻翻法规。

挑好了具体场景，我就准备拿这个场景来做测试了。

照例，先画好框架再往下干。

2、实现方式及逻辑框架

为了方便演示效果，我觉得可以设计两个模块，一个模块用来控制车辆的驾驶，模块名：【DRIVER30】；另一个模块用来实现AEB功能，模块名：【AEB_ACT】。

注：所谓模块，是SCANeR中的专业术语，你可以理解模块就是一段代码。

【DRIVER30】的主要作用是让车辆始终保持在30km/h的速度，直线行驶，原理是当车辆低于30km/h时，就加速，如果高于30km/h时，就制动。

【AEB_ACT】的主要作用是让车辆判断前方行人的距离，触发AEB功能，并制动。

假设这两个模块已经开发好了，怎么来证明我的算法生效了呢？

当打开【DRIVER30】，不打开【AEB_ACT】时，可以看到车辆撞到行人。

当打开【DRIVER30】，也打开【AEB_ACT】时，可以看到车辆撞到行人前刹车停止。

这样，AEB的效果就设计出来了。也能直观地理解到【AEB_ACT】就是给了车辆添加了一个AEB的功能。

同时需要注意的是，如果这两个模块都有控制车辆制动的行为，那肯定会打架的，所以两个模块只能有一个用来控制驾驶行为。

所以，作为解决方案，可以让【AEB_ACT】将制动信号发送到SCANeR的export channel里，【DRIVER30】在决定保持30km/这个速度前要先读入这个信号，根据这个信号判断是否继续保持30km/h的速度。

工作流逻辑如下图所示。

好，原理讲清楚了，就开始建模，实操。

3、SCANeR场景模型搭建

3.1、车辆行人的建模

按照CNCAP法规的要求，我们利用SCANeR来简单创建一条直路，道路上放置一辆主车，主车前方再放置一个目标行人。

然后是对车和人的行为控制。

主车的驾驶由SIMULINK来控制（驾驶模式：MODELHANDLER，Mix/ACQUISITION）。行人的动作由SCANeR自行控制，可以设置方向为横穿马路、速度为6.5km/h的固定方式。

两者的相对位置需要保证当主车以30km/h行进时，刚好50%重叠位撞到横穿的行人，这个要多尝试几下才能调试好位置。

在本场景案例中，我设置了一个Trigger，当车辆经过Trigger时，触发行人开始行走。

3.2、毫米波雷达的建模

车辆怎么知道前面有人呢？毫米波雷达可以做车辆的眼睛。

然后就是毫米波雷达的建模，相关参数简单设置如下：

外参：

内参（毫米波雷达由于探测行人性能较差所以默认情况下是不会选择探测行人的，这里一定要主动勾选上行人）：

3.3、VISUAL界面显示信息设置

为了让我在做仿真测试的时候能实时看到更多信息，我在VISUAL界面里设置了2个参数的显示。

• 主车当前速度

• 碰撞距离：Distance to Collision

其中，主车当前速度直接可以用MICE脚本里的【getspeed】函数获得。【DistanceToCollision】可以在【AEB_ACT】的Simulink里将该值输出给SCANeR的ExportChannel，再由MICE脚本读取这个通道的值并显示出来。

这个时候，这个模型应该可以跑起来了，简单来看下效果。

注：

1、由于还没有启用SIMULINK模型，所以先不要管【Distance to Collision】这个值的正确与否；

2、如果这个时候你尝试将主车改为TRAFFIC模式/不识别行人/且保持常速30km/h，你应该可以看到车辆刚好撞到行人；

SCANeR中的模型搭好了，再来搭建Simulink里的模型。

4、Simulink模型搭建

4.1、【AEB_ACT】模型搭建

这个模型的主要作用是根据传感器探测到的前方行人的碰撞距离等信息，计算出需要刹车的力值，碰撞距离和力值会被输出到SCANeR的Export Channel中。

该模型整体框架如下所示：

测试下这个模型的运行效果，看下是否会有数据输出给SCANeR的Export Channel里。

如此，【AEB_ACT】这个模块的使命完成了。我们将该模型编译为exe文件（这就是我们后续要加到SCANeR里的模块【AEB_ACT】）。并将该exe文件保存到vs2019下。

E:\AVSimulation\SCANeRstudio_2021\APIs\bin\x64\vs2019

4.2、【DRIVER30】模型搭建

这个模块的主要作用是保持车辆始终维持30km/h的速度直线前行，并且在要碰到行人时紧急制动。该模块的模型框架如下所示：

这个时候，简单测试下这个模型，将之启动后，SCANeR中的场景运行起来，应该可以看到主车会逐渐加速到30km/h，然后始终维持在这个速度左右波动。

哦，开心。

不要开心得太早，如上的功能只能实现车辆始终保持在30km/h的速度下行驶。我们还需要根据【AEB_ACT】输出给SCANeR的ExportChannel里的值来判断是否触发AEB功能而紧急制动，为此，简单地对上述模型进行改造。

最终，我们将该模型编译为exe文件（这就是我们后续要加到SCANeR里的模块【DRIVER30】）。并将该exe文件保存到vs2019下。

E:\AVSimulation\SCANeRstudio_2021\APIs\bin\x64\vs2019

5、效果演示

我们将SIMULINK的两个编译后的模块添加进SCANeR。如下所示：

添加【DRIVER30】模块。

添加【AEB_ACT】模块。

这两个特殊模块添加成功后，首先仅启动【DRIVER30】模块，运行场景。可以看到车辆正好撞到行人。车辆没有减速行为。如下图所示。

在此基础上再启动【AEB_ACT】模块，运行场景。可以看到车辆在撞到行人前减速停下来。如下所示。

如此证明，我们简单地利用【AEB_ACT】模块给车辆添加了AEB功能。

正常来讲，当算法开发出来后，后面会将程序烧到控制器里，再进行SIL测试，然后是HIL测试，然后是VIL测试，走完整个V字形的测试流程才能打完收功的。

本文只专注于MIL测试这一环节，就不深究其它了。

6、完善场景

MIL到这里就完了嘛？No！

一个完善的场景必然包含结束条件。

我们按照NCAP中的结束条件，给SCANeR场景添加几个结束条件，当条件触发时，可以自动结束当前运行的场景。

MICE脚本如下所示：

场景结束条件1：车辆没有撞到行人，错过行人，驾驶到前方，遇到Trigger，结束仿真；

场景结束条件2：车辆地速度减速到0km/h；

场景结束条件3：车辆与行人发生碰撞；

设置好结束条件后，有一个非常大的好处就是，可以脱离SCANeR软件的操作界面，开始“快乐地”在Simulink界面看数据，测试AEB算法了。（直指本质，仿真的目的就是为了测试并完善算法。）

7、算法测试

7.1、搭建测试环境

先来搭建一个好用一点的测试环境，我们希望测试过程在Simulink里操作就可以了，不再希望打开SCANeR点来点去，软件之间切换来切换去，太麻烦了。所以我们需要首先在Simulink里设置好SCANeR场景的运行方法和Simulink的结束方法。SCANeR场景运行的结束方法在上一节已经定义在了SCANeR的MICE脚本中。Simulink的仿真的结束可以直接定主在simulink模型里，如下所示（当检测到SCANeR场景运行结束，也停止Simulink仿真）。

接下来是默认启动模块的设置：在SCANeR中设置好默认该打开的模块（需要在Configuration中勾选上相关模块），其中：

DRIVER30，控制着主车的运动（加减速）；

TRAFFIC，控制着行人的运动；

MODELHANDLER，处理主车的驾驶数据；

VISUAL，显示渲染后的画面；

SCENARIO，运行脚本；

SENSORS，运行传感器；

CONTROLPAD，查看通道里的值（Sensor输出值和Simulink里输出的值）；

设置自动运行SCANeR场景

这个需要用到Laucher模块，在改模块中定义好要打开的配置，以及该配置下的场景文件名称。如下所示。

整体模型

改造完成的【AEB_ACT】的Simulink模型如下所示。

就这样，我们搭建好了一个测试环境，以后测试AEB算法，可以关闭掉SCANeR，在Simulink里点一下【run】就可以快乐地开始测试算法了。

再来测试一下，关闭SCANeR，回到Simulink界面，打开【AEB_ACT】模块的模型，点击运行，整个模型开始运行起来，虽然看不到SCANeR中的场景，但从VISUAL输出的图像及其上显示的数据来看，一切正常。然后，车辆碰到行人，场景自动结束，Simulink随之停止运行，如下所示。

7.2、算法测试

针对我们这个AEB的算法，由哪些参数可以测试及优化呢？

AEB这个算法的功能，我觉得最重要的就是输出刹车力值和TTC参数控制的刹车时刻。

在以上这个例子中，力值的计算，非常简单，给的是一个恒定的常值，刹车时刻也给的是常值，这些力值究竟合不合理根本没经过深思，所以，还是有很多东西可以去测试然后优化的。

1、刹车力值大小的测试；

2、刹车时刻的测试；

3、其他；

7.2.1、刹车时刻的测试

在上面的例子中，刹车时刻定为TTC=3s的时候，车真的停止后，其实距离行人还较远，我们可以试试将刹车时刻进行更改，来简单进行一个对比。

这里简单的从Simulink中输出了DistanceToCollision-Time曲线图，如下图所示。

当TTC=3s的时候，最终主车距离行人还有14.98m。

当TTC=2s的时候，最终主车距离行人还有6.95m。

当TTC=1s的时候，最终主车距离行人还有1.36m。

7.2.2、刹车力值的测试

刹车力的大小对最终车人间距也是有影响的。

在此前的模型中，默认触发AEB功能时，采用的制动力为100N，接下测试下制动力的大小对最终的车人间距的影响。

当制动力=100N的时候，最终主车距离行人还有14.98m。

当制动力=50N的时候，最终主车距离行人还有9.65m。

当制动力=10N的时候，最终主车距离行人还有1.46m。

我们可以发现，当我们设置的刹车时刻和刹车力不同时，会影响车辆的最终距离行人距离。所以，要找到一个最优值并不是一个简单的事，影响因素可能包括：

1、车辆当前车速

2、车辆和地面间的摩擦力

3、车辆的AEB功能是否会触发

4、车辆距离行人的距离，需要的减速度大小

5、制动舒适性

应该需要一个非常全面的考虑，来设计具体的制动力。

7.2.3、算法的优化

此处简单来优化一下刹车的力值。

从上述刹车力值的测试来看，需要根据当前的主车和行人的状态，来设计一个合理的力值，保证车辆在撞到行人前刚好停下来。

假设我们已经知道了车辆的刹车时刻为TTC=3s的时候，开始制动，要在车辆刚好撞到行人前停下来，肯定能根据当前的相对速度和距离，计算出来一个减速度值。

我们将这个减速度值作为输入，刹车力值作为输出，可以通过测试得到一个一维的曲线关系，如下所示。

如果将刹车时刻也考虑进来作为输入，那么会是一个二维的Map，如下图所示：

下图中Row考虑的是TTC刹车时刻，Column考虑的是减速度值，两者一起纳入考虑，最终决定一个需要的刹车力值。

（该表尚未标定，需要进行很多次测试，才能填出此表。）

最后，本案例仅用来演示简单功能的AEB实现，了解从算法设计到仿真测试的完整流程。关于更详细的算法设计，此处不再展开。

本文完。

原创申明：本文原文发在vx公众号【车路慢慢】，图片多来自软件截图，是自己学习过程中的一点学习笔记，若有侵权，请联系删除。