[论文阅读] AI +软件工程 | 从Simulink到ROS 2：一键生成并行代码，自动驾驶开发效率翻倍

从Simulink到ROS 2：一键生成并行代码，自动驾驶开发效率翻倍

论文信息

• 原标题：Model-based Development for Autonomous Driving Systems Considering Event-driven and Timer-driven Nodes
• 主要作者：Kenshin Obi、Ryo Yoshinaka、Hiroshi Fujimoto、Takuya Azumi
• 研究机构：埼玉大学理工学研究科（Saitama University Graduate School of Science and Engineering）、eSOL株式会社软件事业部（Software Division eSOL Co., Ltd）
• 引文格式（GB/T 7714）：Obi K, Yoshinaka R, Fujimoto H, et al. Model-based Development for Autonomous Driving Systems Considering Event-driven and Timer-driven Nodes[C]//2024 IEEE 50th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). IEEE, 2024: 1-8. DOI:10.1109/SEAA64295.2024.00017.
• 预印本链接：arXiv:2512.23605v1 [cs.SE]

1. 一段话总结

本文针对自动驾驶系统中嵌入式系统复杂度与规模增长带来的并行化挑战，提出了一种支持ROS 2的模型驱动开发（MBD）框架，该框架将兼容ROS 2的Simulink模型分为事件驱动型和定时器驱动型节点进行针对性并行化，通过MBP工具生成并行C代码并转换为ROS 2兼容的C++代码，适配多核/众核处理器（如Kalray MPPA3-80 Coolidge），在POSIX和eMCOS环境下的评估显示，所有模式的执行时间均缩短，且通过增加每个核心的线程数可进一步提升CPU利用率，解决了传统MBD与ROS 2集成困难、并发问题规避等痛点。

研究背景：自动驾驶系统的“并行化困境”

如今的自动驾驶汽车，就像一台“移动的超级计算机”——要处理摄像头、LiDAR、雷达等数十个传感器的实时数据，还要完成路径规划、障碍物识别、速度控制等复杂任务。这背后，是规模和复杂度呈指数级增长的嵌入式系统在支撑。

为了应对这种复杂性，行业里有两个“神器”被广泛使用：一是ROS 2（机器人操作系统第二代），它就像一个“通信枢纽”，让汽车各个功能模块（比如传感器、控制器）能高效交换数据；二是多核/众核处理器，就像工厂里的多条生产线，能同时处理多个任务，提升运算速度。

但问题也随之而来：要让这两个“神器”协同工作，需要对程序进行“并行化”（简单说就是把一个大任务拆成多个小任务，分配给不同核心同时做）。传统的并行化方法面临两大难题：

1. 手动并行化：全靠工程师写代码拆分任务，不仅耗时费力，还容易出现数据混乱、程序卡死（死锁）等问题，就像一群工人没协调好分工，要么重复干活，要么互相挡路；
2. 模型驱动开发（MBD）自动化并行化：这是更先进的方法，先通过Simulink等工具搭建数学模型，再自动生成并行代码，但它“不兼容”ROS 2——MBD原本是为单个孤立模块优化设计的，而ROS 2的核心是模块间的通信协作，尤其是多个传感器同时输入数据时，MBD根本不知道该怎么处理不同的触发时机（比如有的数据要实时响应，有的要定期处理）。

举个具体例子：自动驾驶中，LiDAR的点云数据需要每隔100毫秒处理一次（定期触发），而摄像头检测到障碍物时需要立即启动避障计算（事件触发）。传统MBD无法同时适配这两种触发逻辑，导致ROS 2和MBD很难“牵手成功”，并行化效果大打折扣。

创新点：三大核心突破，破解集成难题

这篇论文的厉害之处，在于精准击中了上述痛点，提出了一套“对症下药”的解决方案，核心创新点有三个：

1. 首次明确“双驱动”分类：将ROS 2兼容的Simulink模型分为事件驱动型（数据来了就立即处理，比如障碍物检测）和定时器驱动型（到点就处理，比如定期更新地图），针对性设计并行逻辑；
2. 自动化集成转换：无需手动修改代码，框架能自动把MBD工具（MBP）生成的并行C代码，转换成ROS 2能直接使用的C++代码，打通从模型到实际部署的“最后一公里”；
3. 多核/众核适配优化：支持单核心分配多个线程，解决了传统并行化中“核心等待通信时没事干”的问题，还专门设计了死锁规避脚本，适配众核处理器（如80核的Kalray MPPA3-80 Coolidge）。

2. 思维导图

3. 详细总结

一、研究背景与问题

1. 技术趋势：自动驾驶领域嵌入式系统的复杂度和规模显著增长，促使行业采用ROS 2（机器人操作系统第二代） 作为中间件，以及多核/众核处理器满足实时处理需求。
2. 核心挑战：
   • 传统手动程序并行化面临数据完整性维护、死锁等并发问题；
   • 模型驱动开发（MBD）虽能自动化并行化，但在ROS 2多输入场景下集成困难，因ROS 2侧重节点间通信协作，而传统MBD并行化聚焦孤立节点优化。

二、核心基础概念与工具

三、提出的MBD框架设计

1. 框架目标：自动将Simulink模型转换为ROS 2兼容的并行C++代码，支持事件驱动和定时器驱动节点，适配多核/众核处理器。
2. 输入与输出：
   • 输入：MBP生成的并行C代码、ROS 2节点信息（话题名、消息类型、回调函数名）；
   • 输出：事件驱动型或定时器驱动型的ROS 2并行C++代码。
3. 节点类型设计：
   • 定时器驱动型：按固定时间间隔触发处理（如LiDAR点云接收），通过定时器回调函数触发多线程处理，数据更新通过订阅回调写入中央数据区；
   • 事件驱动型（3种模式）：
     1. 所有输入话题接收数据后触发处理；
     2. 特定输入话题接收数据后触发处理；
     3. 特定输入话题接收且时间戳接近时触发处理（基于message_filters同步）。
4. 性能优化策略：
   • 单核心分配多线程：解决MBP默认1核1线程导致的通信等待空闲问题，提升CPU利用率；
   • 死锁规避：针对Kalray MPPA3-80 Coolidge设计转换脚本，避免线程占用核心导致的死锁。

四、评估环境与结果

1. 评估环境参数：
   | 环境 | 处理器 | 核心数 | 内存 | ROS 2版本 | 其他 |
   |------|--------|--------|------|-----------|------|
   | POSIX | Intel Core i5-12400F | 6物理核 | 32.0 GB | Humble Hawksbill | 线程调度策略SCHED_FIFO |
   | eMCOS | Kalray MPPA3-80 Coolidge | 80核（5个CC） | - | Humble Hawksbill | 单核心最大线程数32 |
2. 评估方法：使用随机Simulink模型（通过SLForge生成），重复测量1000次执行时间，取中位数80%的平均值作为结果。
3. 核心结果：
   • 基本并行化效果：两种环境下，核心数增加（1→2→4核）均导致执行时间缩短；POSIX环境中事件驱动与定时器驱动模式执行时间接近；
   • 多线程优化效果：
     • POSIX环境：2核下线程数从8增至64，执行时间显著缩短；
     • eMCOS环境：2核/4核下线程数从8增至32，执行时间总体缩短，但4核下线程数从8→16时因上下文切换成本增加，执行时间暂时上升；
   • 环境差异：相同核心/线程数下，POSIX环境（2.5GHz）执行时间短于eMCOS环境（1.0GHz），因处理器频率差异。

五、相关工作与结论

1. 相关工作对比：现有MBD并行化方案（如Scilab/Xcos、CoCoSim）未同时支持ROS 2集成与事件/定时器驱动节点，本文框架填补了这一空白（见表II）。
2. 研究贡献：
   • 实现Simulink模型的定时器驱动和事件驱动并行化；
   • 支持ROS 2多输入模型的自动并行化；
   • 适配多核/众核处理器，提升执行效率。
3. 未来方向：
   • 扩展至多模型互联的并行化优化；
   • 增加更多实用的节点模式，提升框架灵活性。

4. 关键问题

问题1：本文提出的MBD框架如何解决传统MBD与ROS 2集成的核心矛盾？

答案：核心矛盾在于传统MBD并行化聚焦孤立节点优化，而ROS 2侧重节点间通信协作，且多输入场景下处理时序复杂。框架通过两点解决：① 将ROS 2兼容的Simulink模型明确分为事件驱动型和定时器驱动型节点，针对性设计并行逻辑（如事件驱动的3种触发模式、定时器驱动的固定间隔触发）；② 自动整合MBP生成的并行C代码与ROS 2输入输出接口，补充话题名、消息类型等节点信息，无需手动修改代码即可实现ROS 2节点的并行化，避免了传统方案中ROS 2模块与MBD并行化的兼容性问题。

问题2：该框架在多核/众核处理器上的性能优化策略是什么？效果如何？

答案：优化策略主要是单核心分配多线程（突破MBP默认1核1线程的限制），通过在核心等待跨核通信时切换线程执行其他任务，提升CPU利用率。效果验证如下：① POSIX环境中，2核处理器线程数从8增至64时，执行时间显著缩短；② eMCOS环境中，2核/4核处理器线程数从8增至32时，执行时间总体下降（仅4核8→16线程时因上下文切换成本上升暂时变长）；③ 两种环境下，核心数从1增至4时，所有模式均实现执行时间缩短，验证了并行化的有效性。

问题3：本文提出的事件驱动型节点有哪几种模式？各自适用场景是什么？

答案：事件驱动型节点分为3种模式，适用场景不同：① 所有输入话题接收数据后触发：适用于需多源数据协同处理的场景（如多传感器数据融合）；② 特定输入话题接收数据后触发：适用于以某一核心数据为触发条件的场景（如仅当摄像头检测到障碍物时启动避障计算）；③ 特定输入话题接收且时间戳接近时触发：适用于对数据时序一致性要求高的场景（如自动驾驶中摄像头图像与LiDAR点云的时间同步处理），通过message_filters的ApproximateTime/ExactTime策略保证时序匹配。

研究方法：一步步看懂“并行化框架”的工作流程

这篇论文的研究思路非常清晰，就像搭积木一样，把复杂的方法论拆成了4个关键步骤：

第一步：打好基础——准备核心工具与数据

• 用Simulink搭建自动驾驶系统的模型（比如传感器数据处理、控制逻辑）；
• 通过MBP工具对模型进行自动化并行化：先生成模型的结构信息（BLXML文件）和单核心C代码，再根据处理器性能（通过SHIM工具获取）分配核心任务，最终生成并行C代码；
• 收集ROS 2节点信息：包括话题名（数据传输的“通道名”）、消息类型（数据格式）、回调函数名（数据处理的“触发器”）。

第二步：核心转换——适配“双驱动”节点

框架根据模型的触发逻辑，将并行C代码转换成两种ROS 2节点类型：

第三步：性能优化——提升CPU利用率

针对传统MBD“1核1线程”导致的资源浪费问题，框架采用“单核心多线程”策略：

• 比如一个核心原本只处理1个线程，等待跨核通信时就会闲置；现在分配多个线程，等待时可以切换到其他线程继续工作，就像一个工人在等待物料时，先去处理另一个订单，效率大幅提升；
• 针对众核处理器可能出现的死锁问题，设计转换脚本，避免线程长期占用核心。

第四步：实验验证——在两种环境下测试效果

为了证明框架的有效性，作者搭建了两种测试环境：

• 测试用例：通过SLForge工具生成随机Simulink模型（模拟自动驾驶多输入场景）；
• 测试方法：重复运行1000次，取中位数80%的平均执行时间作为结果，确保数据可靠性。

主要成果和贡献：实实在在的价值的是什么？

这篇论文的成果不是“纸上谈兵”，而是能直接落地的实用技术，核心价值有3点：

1. 执行效率显著提升

• POSIX环境：核心数从1增至4时，所有模式的执行时间均缩短；2核处理器下，线程数从8增至64，执行时间大幅下降；
• eMCOS环境：核心数从1增至4时，执行时间总体缩短（虽2核→4核时因通信开销略有波动，但并行化收益仍超过开销）；
• 两种驱动模式效果相当：事件驱动和定时器驱动的执行时间差异极小，说明框架能适配不同场景的需求。

2. 开发效率大幅提高

• 自动化程度高：从Simulink模型到ROS 2并行代码，全程无需手动修改，解决了传统MBD与ROS 2集成的“手动适配”痛点，缩短开发周期；
• 可靠性提升：框架自动处理数据完整性、死锁等并发问题，减少工程师的调试工作量，降低出错概率。

3. 领域突破性贡献

开源资源

目前论文未提及开源代码或数据集，后续可关注作者所属机构（埼玉大学、eSOL株式会社）的官方渠道获取更新。

总结

这篇论文针对自动驾驶嵌入式系统中“ROS 2与MBD集成难、并行化效率低”的核心痛点，提出了一套支持事件驱动和定时器驱动节点的MBD框架。它通过自动化代码转换、单核心多线程优化、众核处理器适配等创新设计，成功打通了从Simulink模型到ROS 2并行部署的全流程。实验证明，该框架能显著缩短执行时间，提升开发效率和系统可靠性，为自动驾驶等对实时性、复杂性要求极高的领域提供了实用的解决方案。未来，随着多模型并行化、更多节点模式的扩展，该框架的应用场景将更加广泛。