基于ReWorks与openEuler的全栈国产化无人智能控制系统架构实践

1. 项目概述为什么我们需要全栈国产化的无人智能控制系统最近几年我参与了不少工业自动化和边缘计算的项目一个越来越强烈的感受是在一些对自主可控、数据安全有极高要求的领域比如能源、交通、高端制造纯粹的“拿来主义”技术栈开始显得力不从心。客户不仅关心功能实现更关心底层技术是否自主可控、供应链是否安全、数据能否不出境。正是在这样的背景下我们团队启动了一个探索性项目基于ReWorks实时操作系统和openEuler开源操作系统构建一套全栈国产化的无人智能控制系统。这个项目的核心目标是验证在“硬件-操作系统-中间件-应用”全链条上采用国产或开源可控技术栈实现一个复杂异构计算场景的可行性。我们选择的场景是“无人智能控制”它本身就是一个典型的多层次、多任务、强实时与高算力并存的系统。上层需要跑复杂的AI视觉识别、路径规划算法通常基于Linux下层则需要毫秒甚至微秒级的实时控制来驱动电机、处理传感器信号依赖实时操作系统。传统的做法可能是“X86工控机Windows/Linux 实时扩展卡”或者“ARM SoC 定制Linux RT补丁”。而我们这次决心走一条不同的路。ReWorks和openEuler是这个架构的两大基石。ReWorks是一款国内自主研发的、符合POSIX标准的硬实时操作系统在航空航天、工业控制等领域有深厚的积累它的强项在于确定性的实时响应和极高的可靠性。openEuler则是华为开源、国内社区活跃的企业级Linux发行版它继承了开源生态的丰富性同时在安全性、长周期支持上做了大量增强非常适合作为AI算法和复杂业务逻辑的运行平台。将两者结合一个负责“控制”实时域一个负责“智能”非实时域就构成了我们所说的“异构架构”——不是指CPU指令集不同而是指操作系统内核的性质和任务分工不同。这套方案的价值远不止于技术上的“替换”。它意味着从底层芯片指令集、操作系统内核调度、到上层应用开发框架都可以在一种自主、透明、可审计的技术体系内完成。对于关乎国计民生的关键基础设施这种可控性带来的安全感是任何国外商业闭源系统无法给予的。接下来我将详细拆解我们是如何设计、实现并调优这套系统的希望能为有志于国产化技术落地的同行提供一份详实的参考。2. 架构设计与核心思路拆解2.1 异构架构的必然性实时与智能的分离无人智能控制系统听起来高大上拆开来看无非是两类任务的集合一类是“反应”一类是“思考”。“反应”类任务比如编码器反馈回来电机转过了0.1度必须在100微秒内计算出新的PWM占空比并输出激光雷达传来一个突发的障碍物点云必须在5毫秒内触发紧急制动信号。这类任务的特点是截止时间严格、延迟要求极高、执行周期稳定。错过截止时间轻则控制精度下降重则引发安全事故。这类任务必须由实时操作系统来保障。“思考”类任务比如融合摄像头和激光雷达数据运行深度学习模型识别行人、车辆根据识别结果和高精度地图规划出一条最优的全局路径将系统状态和日志上传到云端监控平台。这类任务的特点是计算密集、算法复杂、对吞吐量要求高、但允许一定的延迟和抖动。它们需要丰富的软件生态如Python, TensorFlow, ROS和强大的通用计算能力这正是通用操作系统如Linux所擅长的。试图让一个系统同时完美满足这两类需求是极其困难的。通用的Linux内核虽然通过PREEMPT_RT补丁可以提升实时性但其调度器、内存管理、驱动模型等并非为硬实时而生在最坏情况下的延迟依然难以满足微秒级要求。而专为实时设计的RTOS其软件生态又相对薄弱跑个OpenCV都费劲。因此异构架构成为了最优解。在我们的设计中实时域由ReWorks RTOS主导。它运行在独立的CPU核心上或者作为主核上优先级最高的任务。负责所有时间关键型任务电机伺服控制、传感器数据采集与滤波、安全联锁逻辑、通信总线如CAN, EtherCAT的协议栈处理。智能域由openEuler Linux主导。它运行在其他的CPU核心上。负责所有计算密集型和非实时任务AI模型推理、SLAM同步定位与地图构建、高级路径规划、人机交互界面、网络通信、数据存储。两个域之间需要通过高效的跨域通信机制进行数据交换和指令同步这是整个架构成败的关键之一。2.2 全栈国产化技术选型背后的逻辑确定了异构架构的方向后具体技术组件的选型就需要慎之又慎。全栈国产化不是口号每一层的选择都关乎最终的稳定性、性能和开发效率。硬件层我们选择了搭载飞腾或鲲鹏处理器的国产化工控模块。这些处理器基于ARM架构拥有完整的自主知识产权。选择它们不仅是从供应链安全考虑其内置的多核异构计算能力如大小核架构也非常契合我们的软件架构——可以将大核分配给openEuler小核或隔离出的核分配给ReWorks。操作系统层实时域ReWorks。选择它而非VxWorks或QNX等国外RTOS首要原因是自主可控。ReWorks提供了符合POSIX标准的API大大降低了开发者的学习门槛和代码移植成本。其次它在国内军工、轨交等领域有大量成功应用案例稳定性和可靠性经过严苛验证。其提供的实时性指标中断延迟、任务切换时间完全满足我们项目的需求。智能域openEuler。选择它而非CentOS或Ubuntu是因为openEuler是面向数字基础设施的开源系统在安全性集成多种安全模块、性能针对ARM架构有深度优化和长期支持有LTS版本上更有优势。其活跃的国内社区也意味着在遇到问题时能获得更及时的本土化支持。中间件与通信层这是粘合两个域的核心。我们评估了多种方案共享内存速度最快延迟最低适用于大数据量的周期性交换如摄像头帧数据。但需要自行处理同步和互斥复杂度高。RTPS这是DDS数据分发服务的实时传输协议非常适合复杂的分布式系统但协议栈较重。自定义IPC基于消息队列或信号量灵活但开发量大。 经过权衡我们采用了“共享内存RT-Pipe”的混合模式。ReWorks提供了RT-Pipe机制这是一种高效的、基于管道的跨域通信方式底层可能由共享内存实现但提供了更友好的API。我们将对实时性要求极高的控制指令如“急停”和状态反馈通过RT-Pipe传递将图像、点云等大数据块通过精心设计的共享内存区交换并在共享内存头中设置原子变量作为信号量。应用框架与算法层在openEuler侧我们自然融入了ROS 2生态。ROS 2的节点化思想与我们的异构架构不谋而合其底层通信DDS也可以配置为使用共享内存传输效率很高。AI算法部分我们使用MindSpore或PaddlePaddle国产AI框架在openEuler上均有良好的支持。在ReWorks侧应用主要是用C语言编写的实时控制循环遵循典型的“初始化-循环-清理”模式关键在于保证每个循环的执行时间确定。注意全栈国产化不是简单的“替换”而是“适配”和“优化”。例如ARM架构与X86架构在内存序、缓存一致性上存在差异在编写跨域共享内存通信代码时必须使用内存屏障指令来确保数据可见性的正确性这是从X86平台迁移过来时最容易忽略的坑。3. 开发环境搭建与核心组件部署3.1 双系统开发环境构建开发这样一套异构系统首先需要一个高效的开发环境。我们采用的是“宿主机-目标机”的交叉编译模式。宿主机环境我们选择在Ubuntu 20.04 LTS上搭建。需要在宿主机上安装ReWorks开发套件从厂商处获取SDK它通常包含针对特定硬件板的编译器可能是arm-none-eabi-gcc或厂商定制的工具链、调试器、烧写工具以及ReWorks内核与库文件的头文件及链接库。openEuler交叉编译工具链对于ARM64架构的openEuler我们可以使用aarch64-linux-gnu-gcc工具链。更推荐的做法是直接使用openEuler官方提供的Docker镜像或OSC构建工具可以确保编译环境与目标系统完全一致。# 示例拉取openEuler的Docker编译镜像 docker pull openeuler/openeuler:22.03-lts # 运行容器并挂载代码目录 docker run -it -v /your/code/path:/home/code openeuler/openeuler:22.03-lts /bin/bash集成开发环境虽然可以用VSCode插件但对于复杂的异构调试我们最终选择了Eclipse作为统一IDE。通过安装CDT插件、厂商提供的ReWorks插件以及远程系统探针插件可以在一个工程里管理两套代码并支持联调。目标机环境部署 这是关键步骤。我们的硬件板上有多个CPU核心需要将两个操作系统部署到不同的核心上或者以非对称多处理的方式运行。Bootloader配置使用U-Boot作为引导程序。我们需要修改U-Boot的启动脚本让其能够分别加载两个系统的内核镜像。一种常见的方法是U-Boot先加载一个轻量级Hypervisor或直接利用ARM的TrustZone技术进行隔离然后再分别启动两个内核。更实用的、我们采用的方法是主从核启动。主从核启动流程系统上电后所有CPU核心都从同一地址启动运行U-Boot。U-Boot中我们指定CPU 0作为主核负责加载并跳转到openEuler内核。openEuler内核启动时在其设备树中将CPU 1标记为“reserved”或通过cpu-release-addr机制告知ReWorks内核的入口地址。CPU 0启动openEuler的同时CPU 1在U-Boot的安排下跳转到ReWorks内核的入口地址开始执行ReWorks。两个内核独立初始化各自管理的硬件资源内存区间、外设并通过预先约定的内存区域通常是设备树中预留的进行通信初始化。设备树这是ARM Linux系统的硬件描述文件至关重要。我们需要在openEuler的设备树中明确划分出哪些内存区域归openEuler哪些归ReWorks。哪些外设如某个UART、某个GPIO控制器归openEuler哪些归ReWorks。对于需要共享的外设如用于跨域通信的邮箱硬件需要仔细设计驱动。声明共享内存区域的位置和大小。3.2 ReWorks实时域的关键配置与裁剪ReWorks通常以源码形式提供我们需要针对自己的硬件进行配置和编译。内核配置进入ReWorks源码目录执行类似make menuconfig的配置命令。重点配置项包括处理器类型与时钟选择正确的ARM核心型号配置主频。内存布局必须与openEuler设备树中预留的区域完全一致包括起始地址和大小。任务调度器选择优先级抢占式调度配置最大任务数、优先级数量。定时器与时钟源选择高精度硬件定时器配置系统心跳频率通常为1000Hz或更高。通信机制启用RT-Pipe、消息队列、信号量等组件。驱动仅添加本项目必需的硬件驱动如CAN、EtherCAT、PWM、ADC等无关驱动一律不选以最大化确定性。编写实时应用ReWorks应用通常是一个独立的C程序入口为main函数。核心是一个无限循环循环体内以固定的周期执行#include reworks.h int main() { // 1. 硬件初始化GPIO, PWM, ADC, 通信外设 hardware_init(); // 2. 创建RT-Pipe端点连接到openEuler域 rt_pipe_t *pipe rt_pipe_open(/dev/pipe/control, O_RDWR); // 3. 创建实时控制任务 rt_task_create(control_task, ctrl, 0, 200, T_JOINABLE); rt_task_start(control_task, control_loop, NULL); // 4. 主循环可能处理其他低优先级任务或看门狗 while (1) { rt_sleep(1000); // 休眠1秒 } return 0; } void control_loop(void *arg) { while (1) { rt_timer_start(); // 记录循环开始时间 // 读取传感器数据 read_sensors(); // 从RT-Pipe读取上层指令非阻塞 read_control_command(pipe); // 执行核心控制算法PID、状态机等 execute_control_law(); // 输出控制信号到执行器 drive_actuators(); // 通过RT-Pipe发送状态反馈 send_status_feedback(pipe); // 精确休眠保证固定周期如1ms rt_timer_delay_until(CYCLE_TIME_1MS); } }实操心得在control_loop中使用rt_timer_delay_until而不是简单的sleep是实现严格周期控制的关键。它能补偿循环体执行时间的波动确保任务绝对按固定周期执行避免累积误差。3.3 openEuler智能域的软件栈集成openEuler侧的环境更像一个标准的Linux服务器开发。系统安装与基础配置从官网下载openEuler LTS版本的ISO镜像安装到目标板的硬盘或eMMC上。安装时注意分区为ReWorks预留出内存空间。安装后首要任务是配置网络和SSH方便远程开发。# 配置防火墙开放SSH端口默认22 sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --reload # 或者如果使用iptables旧版 sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT sudo service iptables save安装核心软件包开发工具链gcc,g,cmake,git,vim等。ROS 2建议从源码编译安装ROS 2 Humble或Iron版本以获得对ARM架构的最佳兼容性。这是一个耗时但稳定的过程。AI框架通过pip或conda安装PaddlePaddle或MindSpore的ARM版本。通信中间件安装CycloneDDS或FastDDS这是ROS 2的默认通信层我们将其配置为使用共享内存传输。编写智能域应用我们使用ROS 2的节点来组织代码。一个典型的节点会订阅传感器话题数据可能来自共享内存接口发布控制指令话题。#!/usr/bin/env python3 import rclpy from rclpy.node import Node from sensor_msgs.msg import Image from custom_msgs.msg import ControlCommand class PlannerNode(Node): def __init__(self): super().__init__(planner_node) # 订阅来自“感知节点”的相机图像 self.subscription self.create_subscription( Image, camera/image, self.image_callback, 10) # 发布控制指令到“通信接口节点” self.publisher self.create_publisher( ControlCommand, control/command, 10) # 初始化共享内存接口用于与ReWorks域高速交换数据 self.shm_interface SharedMemoryInterface(/dev/shm/rt_data) def image_callback(self, msg): # 1. 图像预处理 cv_image self.bridge.imgmsg_to_cv2(msg) # 2. AI模型推理使用PaddlePaddle detections self.model.predict(cv_image) # 3. 路径规划 trajectory self.planner.plan(detections) # 4. 生成底层控制指令 cmd ControlCommand() cmd.speed trajectory.speed cmd.steering trajectory.curvature # 5. 发布指令 self.publisher.publish(cmd) # 6. 同时将关键数据写入共享内存供ReWorks实时读取 self.shm_interface.write_immediate_status(cmd) def main(argsNone): rclpy.init(argsargs) node PlannerNode() rclpy.spin(node) node.destroy_node() rclpy.shutdown()4. 跨域通信的实现与深度优化通信是异构架构的“任督二脉”实现不好整个系统就会“气血不畅”。4.1 RT-Pipe通信的实现细节RT-Pipe是ReWorks提供的高效IPC机制。在openEuler侧需要通过一个内核模块来创建与ReWorks对接的Pipe设备节点。ReWorks侧创建Pipe在ReWorks启动脚本或初始化代码中创建Pipe并命名。// ReWorks侧 #define PIPE_NAME /dev/pipe/control rt_pipe_t *pipe; pipe rt_pipe_create(PIPE_NAME, 1024); // 创建缓冲区为1KB的管道 if (pipe NULL) { rt_printf(Failed to create pipe!\n); return -1; }openEuler侧访问Pipe首先确保ReWorks内核配置导出了该Pipe。然后在openEuler的文件系统中会出现对应的设备节点如/dev/rpmsg0。我们可以像操作普通文件一样操作它但为了极致的性能通常编写一个专用的内核模块或使用ioctl进行优化。// openEuler用户态示例简化 int fd open(/dev/rpmsg0, O_RDWR); if (fd 0) { perror(open pipe failed); exit(1); } // 写入指令 ControlCommand cmd {.speed1.0, .steering0.05}; write(fd, cmd, sizeof(cmd)); // 读取状态 RobotStatus status; read(fd, status, sizeof(status)); close(fd);注意事项read和write是阻塞调用。在实时性要求高的场景ReWorks侧应使用非阻塞模式并配合select或poll来避免任务因等待IO而被挂起影响实时性。4.2 共享内存通信的同步与数据一致性共享内存速度最快但管理也最复杂。我们划分了一块物理上连续的内存区域两边分别映射到自己的地址空间。内存布局设计我们设计了一个结构体作为共享内存的数据区。typedef struct { volatile uint32_t head_index; // 生产者写入的索引 volatile uint32_t tail_index; // 消费者读取的索引 uint32_t data_size; // 每个数据块的大小 uint32_t buffer_count; // 环形缓冲区大小 char buffer[0]; // 柔性数组实际数据区 } SharedMemoryRingBuffer;这是一个典型的环形缓冲区用于传输图像帧等大数据。head_index和tail_index是临界资源它们的读写必须原子化。ARM架构下的内存屏障这是最大的坑。ARM是弱内存序模型编译器和处理器可能会对指令重排。假设openEuler侧写入了数据然后更新head_index。在ReWorks侧可能会先看到新的head_index但还没看到新写入的数据必须使用内存屏障。// openEuler侧生产者写入数据后 memcpy(shm-buffer[new_head], data, shm-data_size); // 确保数据完全写入后再更新索引 __sync_synchronize(); // GCC内置函数全内存屏障 shm-head_index new_head; // ReWorks侧消费者读取数据前 while (shm-head_index shm-tail_index) { /* 空转等待 */ } uint32_t idx_to_read shm-tail_index; // 先读取索引再使用屏障确保后续读取能拿到最新数据 __sync_synchronize(); memcpy(data, shm-buffer[idx_to_read], shm-data_size); // 数据读取完毕后再更新tail_index __sync_synchronize(); shm-tail_index next_tail;使用__sync_synchronize()或C11标准的atomic_thread_fence可以确保屏障前的内存操作对屏障后的操作可见。这是保证跨异构核心数据一致性的生命线。无锁环形缓冲区的实现技巧我们通过精心设计让生产者和消费者只修改各自的索引head或tail避免了同时修改同一变量从而实现了无锁。但前提是缓冲区大小必须是2的幂这样索引回绕可以通过位与操作高效完成new_index (old_index 1) (buffer_count - 1)。5. 系统联调、性能测试与问题排查实录当两个域的系统都就绪通信链路打通后就进入了最考验人的联调阶段。5.1 调试方法与工具链ReWorks域调试严重依赖JTAG/SWD仿真器和串口日志。通过JTAG可以单步调试、设置断点、查看内存和寄存器。我们将关键任务的执行时间戳、中断触发情况通过一个专用的调试串口打印出来用于分析实时性。openEuler域调试这就是标准的Linux调试。gdb,strace,perf是我们的主要工具。特别是perf可以分析系统性能瓶颈。跨域联合调试这是难点。我们采用的方法是逻辑分析仪和系统跟踪。在共享内存中预留一块区域作为“事件记录区”两边在关键操作如发送指令、收到反馈、进入临界区时都向该区域写入一个带时间戳的事件ID。然后通过一个上位机工具定期读取并可视化这个事件流就能清晰地看到两个域之间的协作时序是否正常。5.2 性能测试关键指标我们建立了以下测试用例和验收标准测试项测试方法预期指标实测结果说明ReWorks任务周期抖动使用高精度示波器测量任务循环中某个GPIO引脚翻转的间隔 ±10 µs±5 µs反映RTOS的确定性控制指令跨域延迟从openEuler发送指令到ReWorks执行并返回确认的时间戳差 200 µs平均150 µs最坏180 µs反映RT-Pipe通信效率图像数据吞吐量通过共享内存传输1080P YUV图像帧的速率 60 FPS75 FPS反映大数据通道带宽openEuler AI推理延迟从收到图像到输出识别结果的时间 50 ms平均35 ms反映智能域算法性能系统最长中断关闭时间在ReWorks中测量 20 µs15 µs影响实时性关键指标5.3 常见问题与排查技巧在实际调试中我们遇到了无数问题以下是几个最具代表性的问题一系统随机死锁尤其在长时间运行后。排查首先检查共享内存的环形缓冲区索引。发现当生产速度远大于消费速度时缓冲区很快被写满。我们的生产代码在缓冲区满时会忙等待而消费代码因为某个低优先级任务被阻塞导致双方都在等对方形成死锁。解决将缓冲区满时的策略从“忙等待”改为“丢弃最旧数据”或“流控通知生产者降速”。同时提高消费任务的优先级确保其能及时运行。问题二从openEuler发送的控制指令偶尔在ReWorks侧读取到错误数据。排查检查通信代码发现数据结构和内存对齐都没问题。最终通过逻辑分析仪抓取共享内存总线信号发现极少数情况下一次32位写入被拆成了两次16位写入。这指向了数据一致性问题。解决根本原因是缺少内存屏障。在写入数据和更新索引之间以及读取索引和读取数据之间都加入了__sync_synchronize()屏障指令。问题消失。问题三当openEuler侧CPU负载很高时ReWorks域的实时任务周期出现明显抖动。排查两个系统运行在不同的核心上理论上不应相互影响。使用性能分析工具发现当openEuler内存压力大时总线访问延迟会增加。而ReWorks访问的共享内存以及一些外设寄存器都需要通过系统总线。总线拥塞影响了ReWorks的访问速度。解决1.硬件隔离在芯片层面将ReWorks使用的内存控制器通道和openEuler的隔离开如果硬件支持。2.软件优化为ReWorks的关键内存访问路径启用CPU缓存并锁定缓存行减少总线访问频率。3.资源预留在BIOS/U-Boot层面为ReWorks预留专属的内存带宽。问题四ROS 2节点与ReWorks的时钟同步问题。描述路径规划节点基于openEuler的系统时钟生成未来轨迹但ReWorks的时钟可能有微小的偏移导致“现在”执行的轨迹其实是“过去”规划的。解决我们实现了一个简单的跨域时钟同步协议。在共享内存中开辟一个区域由ReWorks以其高精度时钟定期写入当前时间戳。openEuler侧以一个后台线程读取这个时间戳并计算与本地时钟的偏移量用于校正所有发给ReWorks的带时间戳的指令。6. 安全性与可靠性增强实践对于无人控制系统安全是生命线。在全栈国产化的背景下我们从多个层面进行了加固。系统隔离这是第一道防线。通过硬件虚拟化或AMP配置确保ReWorks和openEuler在内存空间、外设访问上严格隔离。一个域的崩溃或恶意行为不能直接影响另一个域。特别是实时域必须被保护起来。openEuler安全加固等保合规参照网络安全等级保护要求对openEuler进行配置。包括启用防火墙严格限制端口、强制使用强密码和密钥登录、关闭不必要的服务、配置审计日志、安装入侵检测工具如aide。内核安全模块启用SELinux或AppArmor为每个进程尤其是ROS节点配置最小权限策略。例如规划节点不需要访问摄像头原始设备文件。OTA升级安全为系统更新设计签名验证机制确保只有经过授权的固件包才能被刷入。ReWorks侧的安全考虑RTOS通常更注重功能安全。我们采取了内存保护单元为不同优先级的任务或模块配置MPU防止错误的内存访问导致系统级故障。看门狗设置多级看门狗。任务级看门狗监控关键控制循环系统级看门狗监控整个ReWorks内核。一旦超时立即触发安全状态如停车。控制算法容错在控制代码中对所有输入数据来自共享内存进行有效性检查范围、变化率对执行器输出进行饱和限制防止因通信错误导致执行器暴走。通信安全跨域通信虽然是内部通信但也需防范潜在风险。我们对关键控制指令如急停、模式切换增加了CRC校验甚至轻量级数字签名确保指令在传输过程中未被篡改。7. 项目总结与未来展望经过数个月的开发、调试和测试这套基于ReWorks和openEuler的无人智能控制系统原型终于稳定跑起来了。从技术验证的角度看我们成功证明了全栈国产化异构架构在复杂控制场景下的可行性。ReWorks提供了坚如磐石的实时性保障openEuler则承载了丰富的智能生态两者通过高效的跨域通信协同工作性能指标达到了设计预期。回顾整个过程最大的挑战并非来自某个单一技术而是来自于“整合”。将两套截然不同的系统、工具链、开发思维模式无缝整合需要开发者同时具备嵌入式实时系统和Linux应用开发的双重经验。其中对硬件底层的理解如缓存、内存序、总线仲裁和对系统级设计的把握如资源划分、通信协议设计、错误传播边界至关重要。踩过最深的坑几乎都与“想当然”有关。以为数据写进去对方就能立刻看到结果忽略了缓存一致性以为两个核各自独立就不会相互影响结果忽略了共享总线的竞争。这些教训让我们深刻认识到在异构系统中任何共享资源都是潜在的瓶颈和故障点必须用最严谨、最悲观的方式去设计和验证。对于想要尝试类似架构的团队我的建议是从小处着手逐步迭代。不要一开始就试图构建一个完整的无人系统。可以先实现一个最简单的“Linux发指令RTOS闪LED”的demo把通信链路调通。然后加入共享内存传输传感器数据再逐步引入AI算法和复杂控制逻辑。每一步都做好充分的测试和性能剖析。这套架构的未来扩展方向也很清晰。在硬件上可以探索集成更多国产化芯片如AI加速卡、功能安全MCU等。在软件上可以研究更先进的混合关键性系统调度理论或者将ROS 2的某些实时节点直接移植到ReWorks侧形成更灵活的“混合节点”部署。在生态上希望ReWorks和openEuler的社区能提供更多开箱即用的跨域通信示例和调试工具进一步降低开发门槛。全栈国产化之路道阻且长但行则将至。这次实践让我们看到通过扎实的工程能力和开放的合作生态我们完全有能力构建出安全、可靠、高性能的自主可控智能系统。这不仅仅是技术上的替代更是构建未来数字世界基础设施自主权的关键一步。