从 Simulink 到 ROS 2：基于模型驱动的自动驾驶并行代码生成框架

一、研究背景与问题

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 节点类型：

1. 所有输入话题都收到数据才触发；
2. 特定输入话题收到数据就触发；
3. 特定话题收到数据且时间戳接近才触发（时序同步） | 多传感器数据融合、障碍物检测触发避障、摄像头与 LiDAR 数据同步 |

第三步：性能优化——提升 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. 领域突破性贡献

开源资源

目前论文未提及开源代码或数据集。

总结

这篇论文针对自动驾驶嵌入式系统中