在斯堪尼亚开发先进的紧急制动系统

追尾是货运卡车和其他重型车辆最常见的事故类型。为了减少追尾事故的风险，2015年，欧盟要求所有新车必须安装先进的紧急制动系统(AEBS)。

与其他先进的驾驶辅助系统(ADAS)一样，AEBS使用来自传感器的输入来筛选环境。当碰撞即将发生时，系统会用声音警报向驾驶员发出警告。如果驾驶员没有反应，它就会发出警告刹车。如果驾驶员仍然没有反应，系统就会全力刹车以避免碰撞(图1)。AEBS还提供“制动辅助”:当驾驶员刹车，但力道不足以避免碰撞时，系统会计算并施加所需的额外制动力。

AEBS使用安装在车辆前部的雷达和摄像头传感器来扫描前方区域的物体。该系统利用每个传感器的特殊优势，以获得更精确的环境模型。雷达传感器擅长确定物体的距离、相对速度和固体度，但不太能确定物体的形状或横向位置。单独使用雷达的系统很难区分停在路边的汽车和驾驶车道上的汽车。另一方面，相机可以精确定位物体的大小和横向位置，但不能很好地探测距离，也无法评估密度(密集的云可能被认为是固体物体)。

我和同事们建立了一个传感器融合系统，将两个传感器的数据匹配并合并到一个物体中。该系统使用四种加权特性——纵向速度和位置、横向速度和位置——来计算两个传感器探测到同一物体的概率。一旦传感器融合系统在主车辆的路径上识别出一个物体，它就会将该物体的位置和车辆的投影路径传递给AEBS，由AEBS决定何时向驾驶员发出警报或制动。

我们的团队之前使用基于模型的设计开发了一种使用雷达技术的自适应巡航控制系统，但我们之前从未开发过传感器融合系统。因为这是一个新的设计，我们知道我们需要一个可读的、可理解的体系结构来可视化信号流。我们还预期有很多设计迭代，所以我们想要一种简单的方法来可视化结果和调试我们的设计。此外，我们希望通过生成代码来节省时间，但代码必须高效，因为当我们开始传感器融合项目时，电子控制单元(ECU)上的CPU负载已经约为60%。最后，我们需要彻底验证我们的设计——我们的计划是基于超过150万公里的传感器数据进行模拟。基于模型的设计满足了所有这些要求。

构建传感器融合系统

我们开始将系统设计划分为功能单元，如对象匹配和投影路径放置，并构建一个单独的Simulink^®为每个单元块。结果是一个清晰的软件架构和定义良好的接口(图2)。我们编写了MATLAB^®代码的轨迹关联，计算方差，计算加权概率，并执行其他任务，用脚本比用块更容易实现，并将此代码与MATLAB函数块合并到我们的Simulink模型。这些算法块使得团队成员可以很容易地合并他们的算法，并将它们与控制系统集成。

为了调试和完善我们的初始设计，我们使用记录的雷达传感器数据、相应的相机图像和其他车辆传感器数据进行了模拟。在调试过程中，我们发现将传感器数据与车辆前部的摄像头视图一起可视化是很有用的。我们在MATLAB中构建了一个可视化工具，它可以显示与周围交通的web摄像头视图同步的传感器融合数据(图3)。该工具利用MATLAB的面向对象编程功能，使用MATLAB类来表示任何传感器检测到的每个对象和传感器融合系统感知到的统一对象。这些MATLAB对象使我们能够在可视化数据时及时快速地向前和后退。

我们在道路测试中使用相同的工具来可视化来自车辆网络的实时数据(图4)。

系统实施和性能优化

为了将传感器融合系统部署到ECU，我们使用嵌入式Coder从Simulink模型中生成C代码^®．通过代码生成，我们能够快速实现，同时避免编码错误。ECU处理器的大部分资源分配给维护功能——监控仪表板警报、物理估计、数据网关、自适应巡航控制等等。因此，我们需要优化我们的初始设计，以提高其效率。

为了从生成的代码中获得最佳性能，我们与MathWorks试点团队合作，他们帮助我们优化从MATLAB Coder生成的代码。为了进一步减少处理负载，我们将模型划分为在交替循环中执行的独立部分。例如，我们不是在每个循环中运行静止和移动物体的计算，而是在交替循环中运行它们。我们意识到处理器被系统调用的三角函数卡住了。为了缓解这个问题，我们用C语言编写了三角逼近函数，并从MATLAB函数块中调用它们。这些修改不仅提高了传感器融合代码的效率，还使AEBS软件的反应速度更快，这在车辆以高速公路行驶、每一毫秒都很重要的情况下至关重要。

验证和改进设计

我们在一个封闭的赛道上测试了这个设计，但是我们需要知道系统在真实的驾驶场景中会如何反应，比如不同的天气条件、交通模式和司机行为。在这些条件下直接测试AEBS是不切实际的，也是不安全的。相反，我们使用了基于模拟的工作流。我们首先从一队卡车上收集数据。我们决定收集ecu上的所有可用数据，不仅仅是用于传感器融合的雷达和相机的数据，还有来自单独参考相机的图像。

利用这些车队测试数据，我们进行了模拟，以确定有趣的驾驶场景——AEBS干预警告司机或启动刹车的场景，以及系统可以干预但没有干预的场景——例如，当司机按下喇叭并同时刹车、转向或急刹车时。针对这些场景，我们分析了AEBS的性能，以确定可以改进设计的领域。

每次更新AEBS软件时，我们都需要重新模拟。然而，超过80tb的真实交通数据记录了超过150万公里的驾驶，运行一个模拟需要几天的时间。

为了加速模拟，我们使用从我们的Simulink模型生成的代码和Embedded Coder构建了一个模拟器。仿真器读取和写入与我们的Simulink模型相同的mat文件，但运行模拟的速度要快150倍。为了进一步加速模拟，我们编写了MATLAB脚本，在我们部门的多台计算机上运行模拟，以及在专用的多处理器服务器上，我们并行运行了多达300个模拟。有了这个设置，我们将模拟所有150万公里所需的时间缩短到12个小时。当我们在模拟器中发现一个新的有趣的场景时，我们在Simulink中重新运行模拟，以深入分析它。

在tb级数据中识别和分类潜在的有趣场景是一项繁琐而耗时的任务，因此我们开发了情境分类助手模块，这是一个基于MATLAB的工具，可以自动完成这部分过程(图5)。该工具从模拟中生成一系列事件，例如碰撞警告、警告刹车和系统启动的完全刹车，以及驾驶员启动的硬刹车和急转弯。然后，我们可以将这些列表与我们软件的任意两个版本进行比较。

进行大量模拟的能力增强了AEBS功能和ECU生产代码实现的鲁棒性和安全性。它还使我们能够更快地进行更改。我们对这些变化很有信心，因为我们在模拟中使用了所有可用的数据来测试数千种场景。

在生产ADAS中部署生成的代码

大多数斯堪尼亚卡车和公共汽车现在都配备了AEBS，运行由Simulink模型生成的生产代码，并通过广泛的模拟验证。我们在斯堪尼亚公司的自适应巡航控制系统中重用了我们的传感器融合系统设计，现在有超过10万辆在路上行驶。

文章刊载于MathWorks新闻与笔记