RFrame 架构概览
面向机器人应用开发者、系统集成方与架构设计人员，介绍 RFrame 的整体能力与协同方式。
1. 平台定位
RFrame 的目标是让用户围绕业务编程，而不是反复处理框架集成。其架构设计以统一反射模型为基础：对功能组件类 Plugin、功能能力 Task、数据通道 Channel 和承载类型及数据 Dynamic Data 进行描述、发现与使用，使应用能够围绕组件、能力、连接和数据完成组合。
RGL 的设计定位是类型表达与编排表达，描述应用中的类型、能力及其组合关系；用户逻辑是编排表达的一部分。RFlow 是打通 Task 与 Channel 的关键，组织数据输入、触发条件、能力执行与输出传播。二者都是 RFrame 的内部能力，共同连接用户编程表达与实际运行。
RFramePlugin 提供能力扩展，ROS2 runtime、类型解析及相关适配由插件层承接；Zenoh 接入保留在 RFrame 内部。RobbyDataTools 等工具复用框架和插件能力，提供解析、诊断、可视化及数据处理。配置装配、生命周期、调度与追踪共同构成运行支撑。
本文以架构设计意图组织概览。四类反射的完整一致性、RGL 类型与编排表达及用户逻辑嵌入、RFlow 对反射能力的直接编排，属于需要持续落实的设计目标，不表示所有路径均已完整实现。
2. 总体架构
图 1 · 平台总体架构
总体架构采用固定布局的分层框图：中央依次是 RGL 类型与编排表达、RFlow 数据与执行协同、四类反射基础及运行支撑，左侧是 RFramePlugin 能力扩展，右侧是 RobbyDataTools 诊断与可视化工具链，底部是系统基础设施。框的嵌套与位置表达能力归属和支撑层次，不表示执行顺序。Plugin 机制贯穿平台，工具链贯穿开发、运行与验证；后文关系图补充说明组件协作和数据流。
RGL 面向类型与编排表达，RFlow 面向数据与执行协同，四类反射对象提供统一的组织基础。框图表达设计职责，不表示 RGL 到运行时的自动编译与装配路径已经全部实现。
3. 应用如何协同运行
图 2 · 类型编排、功能能力与数据通道协作
图 2 表达设计中的协作关系；虚线标注类型与编排表达与运行组织之间的设计衔接。
统一反射的目标是让框架和工具能够回答“组件是什么、能做什么、如何连接、数据是什么”，并据此完成发现、参数检查、配置和调用。Plugin 的 Capability 查询是可选能力接口，不等同于完整反射模型，也不是所有业务组件的强制要求。
| 反射对象 | 设计职责 |
|---|---|
| Plugin | 描述功能组件类、构造及配置方式、可提供的能力，支撑实例装配与生命周期管理。 |
| Task | 描述功能操作及其输入、输出、状态和反馈，支撑能力发现与调用；执行器承载具体执行。 |
| Channel | 描述数据通道类型、配置、交互方式和承载类型，支撑连接创建与绑定。 |
| Dynamic Data | 结合运行时类型描述和数据实例，支撑字段访问、数据构造、转换、参数与消息传递。 |
3.1. 表达类型与业务编排
RGL 的预期是统一表达类型与业务编排，描述组件、能力和连接关系，并在编排中表达或接入用户逻辑。输入输出、数据依赖、状态与触发关系应尽可能显式，使程序更便于检查、理解和复现。当前的解析、结构建模与语义检查为这一方向提供基础。
确定性编程需要从表达阶段约束影响结果的条件，而不仅依赖事后的消息回放。RGL 从类型与编排表达出发，RFlow 串联 Channel 与 Task 的数据和执行关系，共同支撑这一设计。
3.2. 组织功能与操作
一个机器人应用通常包含设备接入、业务处理、数据录制、状态监测等功能。RFrame 通过 Plugin 将相关状态、资源和操作组织为组件，交由 AppCore 管理初始化、启动及退出阶段。组件可以直接加入应用，也可以通过动态库按需装载。
组件通过命名 Task 提供操作，例如启动录制、查询进程状态或配置日志轮转。Task 携带输入、输出、执行状态和反馈，并可关联回所属组件使用其资源。因此，同一套功能既能由应用内部调用，也能经任务网关向外部客户端开放。
组件还可以注册通信实现，或声明可供查询的 Capability，让应用按需取得运行时、解析器等可选能力。不同提供方式共同服务于组件装配，业务组件无需一律实现 Capability。
3.3. 连接数据与计算
Channel 为应用提供统一通信接口，底层可选择共享内存、ROS 2、Zenoh、MQTT、WebSocket 等实现。类型描述、序列化和端点发现支撑消息理解、适配与连接，使业务处理与具体传输方式保持分离。
Task 同时承担计算、回调、定时和事件处理等执行工作。执行器、有序处理与协作式分片机制，为不同工作提供资源分配和执行秩序。底层通知器与事件等待机制将数据就绪接入处理链路；外部运行时的 I/O 驱动承担相应的等待职责。
RFlow 是 Task 与 Channel 之间的关键连接：将通道数据绑定到处理输入，判断何时满足触发条件，确定一次执行消费哪些数据，并组织结果向输出通道传播。TaskManager/Executor 承载执行，RFlow 组织执行与数据的关系。当前 Proc、Port 与触发机制已连接 Channel 和任务执行；直接基于命名 Task 反射进行能力发现与自动绑定，应作为设计衔接能力单独落实。
3.4. 组合已有能力与业务扩展
Plugin 动态装载与统一反射共同支撑“对具体功能实现零编译依赖”的使用方式：应用通过公共接口与功能描述发现组件、调用 Task，并通过 Channel 与 Dynamic Data 连接和传递数据，无需直接包含具体插件的实现头文件或链接其实现库。功能提供方仍需构建并部署插件，但功能使用方不必随每项实现一起编译。
在公共接口、数据契约与 ABI 兼容的前提下，功能可以独立交付、按需加载与配置组合，支持部署层面的即插即用。新增或替换符合既定契约的能力，可以减少主程序重新编译、链接及整体发布的需求，也便于按产品裁剪能力、复用存量插件和隔离可选依赖。
这里的“零编译依赖”针对具体功能实现，不代表没有框架接口或运行时依赖。运行中热插拔还要求在途 Task 收敛、回调与 Channel 解绑，以及相关对象和资源安全释放；动态装载与反射本身不等同于任意插件均可安全热卸载。
平台提供的组件覆盖通信接入、任务网关、数据解析、运行监测和数据处理。它们与用户业务组件使用共同的装配方式，可根据产品需要选择组合。
ROS 2 与 WebSocket 运行时支撑外部连接，HTTP/FTP 提供传输能力，桥接与任务网关连接不同系统；发现与解析组件提供 FastDDS 发现、ROS 2 类型解析和 JSON 动态数据转换；录制、MP4 写入、压缩、日志轮转和进程监测支撑日常运行与数据管理。这些存量能力由 RFramePlugin 提供相应实现，Plugin 机制同样可用于其他业务仓库中的组件。
3.5. 观察运行并复现问题
框架侧提供配置与运行描述、RTrace 追踪以及 RFlow 执行记录；工具侧使用这些信息进行配置与拓扑展示、链路观测和执行分析。RTrace 关注上下文、耗时与错误，RFlow 执行记录关注一次处理与输入消息的关联，二者不应混为一套记录。具体可视化能力按实际接入范围提供，主图不另设专用监控通信层。
图 3 · 诊断、可视化与回放闭环
图中实线表示数据或信息流，虚线表示分析结果对应用改进的反馈。业务数据录制与 RFlow 执行记录共同支撑离线分析。
RobbyDataTools 将 Channel、发现和类型能力转化为直接可用的工具：在线查看消息、统计频率、发布数据、调用服务、检查共享内存和发现状态；同时提供 Recorder/Player、MCAP、缓存 SDK 与类型生成工具，支持数据采集、处理和回灌。
对于采用 RFlow 的应用，执行元数据进一步记录处理过程与输入消息的关联。回放时结合业务数据和这些记录，可以按记录的输入关系恢复处理，为故障定位、算法回归和场景验证提供依据。
这种确定性回放能力以完整的消息及执行记录为基础；复现结果还取决于业务初始状态、时钟、随机性和外部依赖是否一致。平台提供恢复输入关系和分析执行过程的机制，应用据此建立自己的复现与验证条件。
4. 平台特色
| 特色 | 对应用的价值 |
|---|---|
| 统一反射与能力组合 | 以 Plugin、Task、Channel、Dynamic Data 描述组件、能力、连接与数据，为发现、装配、调用和工具理解提供共同基础。 |
| 对具体功能实现零编译依赖 | 动态装载与反射将功能使用方和实现方解耦；在契约兼容时按需部署与装配能力，减少主程序重新编译和整体发布。 |
| 公共服务与业务扩展共用组件机制 | 核心服务、存量插件和用户组件围绕共同生命周期进行装配，支持直接集成与动态加载。 |
| 通信抽象与执行治理配合 | 应用使用一致的数据接口，并利用执行器、有序处理和事件驱动机制组织工作。 |
| 表达与执行协同 | RGL 表达类型与编排关系；RFlow 串联 Channel 与 Task，组织数据触发与执行。 |
| 工具贯穿开发、运行与验证 | 同一数据体系支撑类型生成、在线诊断、录制回放和执行分析，缩短问题定位与验证路径。 |
5. 完整使用过程与推荐实践
RFrame 推荐的使用方式是：用配置选择能力，用 RFlow 组织数据与执行，用 RGL 表达类型与业务编排，再通过工具链观察和验证应用。功能提供方交付可复用插件，应用开发者围绕业务完成组合，部署人员通过配置选择产品所需的能力。
5.1. 从能力装配到业务运行
以“设备采集 → 数据处理 → 结果输出，并按需录制”为例：
- 准备能力与数据契约：选择设备接入、处理、录制等 Plugin，部署动态库及运行依赖，确认输入输出类型、功能接口与框架 ABI 兼容。缺少的能力由功能提供方实现并构建为插件。
- 通过配置装配插件：在总控配置中用
plugin.config_path指定加载清单，选择插件名称、动态库路径、启用状态和初始化策略，再按插件公开的配置契约设置设备、算法参数及 Channel。支持按需加载的条目可登记对应 Capability。安装、启用和实际加载是不同环节。 - 用 RFlow 组织业务数据流：对于需要数据流协同的应用，明确采集结果送往哪些处理输入、多路数据何时满足触发条件、一次执行消费哪些数据，以及结果如何发布。RFlow 负责连接数据与执行；插件加载配置本身不负责生成业务处理链。
- 用 RGL 表达类型与业务编排：在设计定位上，RGL 描述类型、功能能力及其编排关系，让输入输出、状态、依赖和业务逻辑在共同模型中表达。具体应用应采用当前已支持的表达与执行接入方式；尚未打通的路径通过现有 API 或用户代码实现，不假定 RGL 已能自动编译并装配任意 RFlow。
- 启动应用并验证装配：AppCore 读取插件清单，加载已启用插件并按策略初始化；按需条目在对应 Capability 被查询时加载。插件按自身实现注册 Task、通信实现或可查询能力，应用运行已配置或编写的业务逻辑。先确认能力与连接可用，再检查业务输入输出。
- 观察、复现与切换组合：用 RobbyDataTools 查看消息、连接状态并采集数据；需要离线定位时回灌记录，结合保留的 RFlow 执行元数据恢复输入关系。同一个主程序可通过调整插件部署、加载清单和业务配置，从“采集＋处理”切换到带录制、监测或网关的组合，重新启动后生效。
在既定接口、数据契约及配置能力覆盖范围内，选择或替换已有插件无需修改、重新编译主程序。新增业务逻辑仍可能需要编程；配置装配与按需加载也不等同于运行中的自动热替换。
5.2. 推荐实践：按业务复杂度逐步采用
已有插件和配置足以覆盖需求时，优先通过配置完成装配；简单操作可以直接使用 Task 与 Channel，不必为了形式完整引入额外编排。出现多输入依赖、触发协调或执行记录需求时，再用 RFlow 显式组织业务流。需要统一描述类型、编排和用户逻辑时，按当前支持范围引入 RGL，保留清晰的用户代码接入边界。
把可复用能力留在 Plugin，把数据与执行关系交给 RFlow，把类型与编排表达交给 RGL，是推荐的职责划分，而不是要求每个应用必须使用全部机制。主程序负责稳定的启动与生命周期入口，产品差异尽量由加载清单、参数和业务编排表达。
交付时，将插件版本、加载清单、业务配置及编排文件作为同一套应用材料管理，避免实现与配置不匹配。先打通最小输入输出链路，再增加多路协同、录制和外部接入；需要复现结果时，同时约束初始状态、时钟、随机性和外部依赖，而不只保存消息。
6. 结论
RFrame 将能力装配、业务表达与运行验证组织在同一套架构中：统一反射描述组件、能力、通道与数据；Plugin 支撑功能独立交付和按需装配；RFlow 连接数据与执行，RGL 面向类型与编排表达；RobbyDataTools 帮助用户理解运行状态并验证结果。
平台的演进方向，是让已有能力更容易组合、业务关系更明确、运行过程更容易理解与复现。配置负责选择能力，业务编排负责组织行为，运行时负责承载执行；这既减少应用对具体实现的编译期耦合，也为用户保留必要的编程与扩展空间。