RFrame Architecture Overview
An introduction to RFrame's capabilities and how they work together, for robot application developers, system integrators, and architects.
1. Platform positioning
RFrame aims to let users focus on application logic instead of repeatedly solving framework integration problems. Its architecture is based on a unified reflection model describing, discovering, and using functional component classes (Plugin), capabilities (Task), data channels (Channel), and their types and data (Dynamic Data). Applications can compose components, capabilities, connections, and data using this model.
RGL is intended to express types and orchestration, describing the types, capabilities, and composition relationships in an application; user logic is part of that orchestration. RFlow connects Task and Channel by organizing inputs, trigger conditions, capability execution, and output propagation. Both are internal RFrame capabilities connecting user programming expressions with runtime execution.
RFramePlugin provides extensions. The plugin layer handles ROS2 runtimes, type parsing, and related adapters; Zenoh integration remains internal to RFrame. Tools such as RobbyDataTools reuse framework and plugin capabilities for parsing, diagnosis, visualization, and data processing. Configuration-based assembly, lifecycle management, scheduling, and tracing provide runtime support.
This overview describes architectural intent. Full consistency across the four reflection categories, RGL type and orchestration expressions with embedded user logic, and direct RFlow orchestration of reflected capabilities remain ongoing design goals. This does not imply that every path is fully implemented.
2. Overall architecture
Figure 1 · Overall platform architecture
The architecture uses a fixed-layout layered block diagram. The center contains RGL type and orchestration expressions, RFlow data/execution coordination, the four reflection foundations, and runtime support. RFramePlugin extensions appear on the left; the RobbyDataTools diagnostic and visualization toolchain appears on the right; system infrastructure is at the bottom. Nesting and placement indicate ownership and supporting layers, not execution order. The Plugin mechanism spans the platform, while tools span development, operation, and validation. Subsequent relationship diagrams explain component collaboration and data flow.
RGL addresses type and orchestration expressions, RFlow addresses data/execution coordination, and the four reflection object categories provide a unified organizational basis. The diagram shows design responsibilities; it does not imply that all automatic compilation and assembly paths from RGL to the runtime are implemented.
3. How applications run together
Figure 2 · Collaboration between type orchestration, capabilities, and data channels
Figure 2 shows the intended collaboration. Dashed lines indicate the planned connection between type/orchestration expressions and runtime organization.
Unified reflection aims to let frameworks and tools answer what a component is, what it can do, how it connects, and what its data is, then use that information for discovery, parameter validation, configuration, and invocation. Plugin Capability queries are an optional capability interface. They are not equivalent to the complete reflection model and are not mandatory for every application component.
| Reflection object | Design responsibility |
|---|---|
| Plugin | Describes component classes, construction and configuration methods, and available capabilities; supports instance assembly and lifecycle management. |
| Task | Describes operations and their inputs, outputs, states, and feedback; supports capability discovery and invocation. Executors perform the actual execution. |
| Channel | Describes channel types, configuration, interaction patterns, and carried types; supports connection creation and binding. |
| Dynamic Data | Combines runtime type descriptions and data instances to support field access, data construction and conversion, and parameter/message passing. |
3.1. Express types and application orchestration
RGL is intended to express types and application orchestration in a unified way, describing components, capabilities, and connections while expressing or integrating user logic. Inputs, outputs, data dependencies, states, and trigger relationships should be explicit wherever possible, making programs easier to inspect, understand, and reproduce. Current parsing, structural modeling, and semantic checks provide a foundation for this direction.
Deterministic programming requires constraining conditions that affect results at the expression stage, rather than relying only on later message replay. RGL starts with type and orchestration expressions; RFlow connects Channel and Task data/execution relationships. Together they support this design.
3.2. Organize functions and operations
A robot application typically includes device integration, application processing, recording, and status monitoring. RFrame uses Plugin to organize related state, resources, and operations into components, with AppCore managing initialization, startup, and shutdown. Components can be added directly or loaded on demand from dynamic libraries.
Components expose operations through named Tasks, such as starting recording, querying process status, or configuring log rotation. A Task carries inputs, outputs, execution state, and feedback, and can refer back to its owning component to use its resources. The same functionality can therefore be invoked inside an application or exposed to external clients through a task gateway.
Components can also register communication implementations or declare queryable Capabilities, allowing applications to obtain optional runtimes, parsers, and other capabilities on demand. These mechanisms all support component assembly; application components do not all need to implement Capability.
3.3. Connect data and computation
Channel provides a unified communication interface, with underlying implementations such as shared memory, ROS 2, Zenoh, MQTT, and WebSocket. Type descriptions, serialization, and endpoint discovery support message interpretation, adaptation, and connection, keeping application processing separate from transport details.
Task also handles computation, callbacks, timers, and events. Executors, ordered processing, and cooperative chunking allocate resources and organize execution for different workloads. Low-level notifiers and event-wait mechanisms connect data readiness to processing; external runtimes' I/O drivers handle their corresponding waiting responsibilities.
RFlow connects Task and Channel: it binds channel data to processing inputs, determines when trigger conditions are met and which data an execution consumes, and propagates results to output channels. TaskManager/Executor hosts execution, while RFlow organizes its relationship with data. Current Proc, Port, and trigger mechanisms already connect Channels with task execution. Capability discovery and automatic binding directly through named Task reflection remain a separate integration goal.
3.4. Combine existing capabilities and application extensions
Dynamic Plugin loading and unified reflection support use without compile-time dependencies on specific implementations. Applications discover components and invoke Tasks through public interfaces and capability descriptions, then connect and pass data through Channel and Dynamic Data. They need not include implementation headers or link implementation libraries of specific plugins. Providers still build and deploy plugins, but consumers need not compile alongside each implementation.
Provided public interfaces, data contracts, and ABI remain compatible, capabilities can be delivered independently, loaded on demand, and composed through configuration, enabling plug-and-play at deployment time. Adding or replacing compatible capabilities reduces the need to rebuild, relink, and rerelease the main application. It also helps tailor products, reuse existing plugins, and isolate optional dependencies.
Here, “no compile-time dependency” refers to specific implementations, not the absence of framework interfaces or runtime dependencies. Runtime hot-plugging additionally requires in-flight Tasks to settle, callbacks and Channels to be unbound, and associated objects and resources to be released safely. Dynamic loading and reflection alone do not mean every plugin can be safely unloaded at runtime.
Platform components cover communication integration, task gateways, data parsing, runtime monitoring, and data processing. They use the same assembly mechanism as user application components and can be combined according to product requirements.
ROS 2 and WebSocket runtimes support external connections; HTTP/FTP provide transport; bridges and task gateways connect systems. Discovery and parsing components provide FastDDS discovery, ROS 2 type parsing, and JSON dynamic-data conversion. Recording, MP4 writing, compression, log rotation, and process monitoring support everyday operation and data management. RFramePlugin supplies these implementations; the same Plugin mechanism is available to components in other application repositories.
3.5. Observe execution and reproduce problems
The framework provides configuration/runtime descriptions, RTrace tracing, and RFlow execution records. Tools use them to display configuration and topology, observe communication paths, and analyze execution. RTrace focuses on context, duration, and errors; RFlow execution records associate a processing step with its input messages. They are distinct records. Visualization capabilities depend on the actual integration scope; the main diagram does not introduce a separate monitoring communication layer.
Figure 3 · Diagnosis, visualization, and replay loop
Solid lines represent data or information flow; dashed lines represent feedback from analysis into application improvements. Application data recording and RFlow execution records jointly support offline analysis.
RobbyDataTools turns Channel, discovery, and type capabilities into directly usable tools: inspect messages online, measure frequency, publish data, invoke services, and inspect shared memory and discovery state. Recorder/Player, MCAP, the cache SDK, and type-generation tools also support data collection, processing, and reinjection.
For applications using RFlow, execution metadata records how processing relates to input messages. Replaying application data together with these records restores processing according to the recorded input relationships, supporting fault diagnosis, algorithm regression, and scenario validation.
Deterministic replay relies on complete message and execution records. Reproduction also depends on consistent initial application state, clocks, randomness, and external dependencies. The platform provides mechanisms to restore input relationships and analyze execution; applications must establish their own reproduction and validation conditions.
4. Platform characteristics
| Characteristic | Application value |
|---|---|
| Unified reflection and capability composition | Plugin, Task, Channel, and Dynamic Data describe components, capabilities, connections, and data, providing a common basis for discovery, assembly, invocation, and tool interpretation. |
| No compile-time dependency on specific implementations | Dynamic loading and reflection decouple consumers from implementations. Compatible capabilities can be deployed and assembled on demand, reducing main-program rebuilds and full releases. |
| A shared component mechanism for common services and application extensions | Core services, existing plugins, and user components share lifecycle-based assembly, with direct integration and dynamic loading. |
| Communication abstraction with execution management | Applications use consistent data interfaces and organize work with executors, ordered processing, and event-driven mechanisms. |
| Coordination between expressions and execution | RGL expresses types and orchestration relationships; RFlow connects Channel and Task to organize data-triggered execution. |
| Tools across development, operation, and validation | A common data system supports type generation, online diagnosis, recording/replay, and execution analysis, shortening diagnosis and validation. |
5. Complete workflow and recommended practices
The recommended approach is to select capabilities through configuration, organize data and execution with RFlow, express types and application orchestration with RGL, and observe and validate through the toolchain. Providers deliver reusable plugins, developers compose application logic, and deployment engineers select product capabilities through configuration.
5.1. From capability assembly to application execution
Consider “device collection → data processing → result output, with optional recording”:
- Prepare capabilities and data contracts: Select Plugins for device access, processing, recording, and other functions. Deploy dynamic libraries and runtime dependencies, and confirm compatibility of input/output types, interfaces, and framework ABI. Providers implement missing capabilities as plugins.
- Assemble plugins through configuration: Use
plugin.config_pathin the main configuration to specify the loading catalog. Select plugin names, library paths, enabled states, and initialization policies, then configure devices, algorithm parameters, and Channels according to each plugin's public contract. On-demand entries can declare associated Capabilities. Installation, enabling, and actual loading are separate steps. - Organize application data flow with RFlow: For coordinated data flows, specify which processing inputs receive collected data, when multiple inputs meet trigger conditions, what each execution consumes, and how results are published. RFlow connects data and execution; plugin-loading configuration alone does not generate an application processing chain.
- Express types and orchestration with RGL: RGL is designed to describe types, capabilities, and orchestration relationships, bringing inputs, outputs, states, dependencies, and user logic into one model. Use currently supported expression and execution integration paths. Implement missing paths through existing APIs or user code; do not assume RGL can automatically compile and assemble arbitrary RFlows.
- Start the application and validate assembly: AppCore reads the catalog, loads enabled plugins, and initializes them according to policy. On-demand entries load when their Capability is queried. Plugins register Tasks, communication implementations, or queryable capabilities according to their implementation; the application runs configured or programmed logic. Verify capabilities and connections before application inputs and outputs.
- Observe, reproduce, and change compositions: Use RobbyDataTools to inspect messages and connections and collect data. For offline diagnosis, replay records and use retained RFlow execution metadata to restore input relationships. The same main program can switch from collection/processing to compositions including recording, monitoring, or gateways by changing deployed plugins, the loading catalog, and application configuration, then restarting.
Within the supported interfaces, data contracts, and configuration capabilities, selecting or replacing existing plugins does not require changing or rebuilding the main program. New application logic may still require programming. Configuration-based assembly and on-demand loading do not imply automatic hot replacement at runtime.
5.2. Recommended practice: adopt mechanisms as complexity grows
When existing plugins and configuration meet requirements, prefer configuration-based assembly. Simple operations can use Task and Channel directly without additional orchestration. Introduce RFlow when multiple input dependencies, coordinated triggers, or execution records are needed. Introduce RGL within its currently supported scope when a unified description of types, orchestration, and user logic is needed, retaining clear integration boundaries for user code.
Keeping reusable capabilities in Plugin, data/execution relationships in RFlow, and type/orchestration expressions in RGL is a recommended separation of responsibilities, not a requirement for every application to use every mechanism. The main program supplies stable startup and lifecycle entry points; loading catalogs, parameters, and application orchestration should express product differences where possible.
Manage plugin versions, loading catalogs, application configuration, and orchestration files as one delivery set to avoid mismatches. Establish a minimal input/output path before adding multi-input coordination, recording, and external integrations. For reproducible results, constrain initial state, clocks, randomness, and external dependencies as well as recording messages.
6. Conclusion
RFrame organizes capability assembly, application expression, and runtime validation in one architecture. Unified reflection describes components, capabilities, channels, and data. Plugin supports independent delivery and on-demand assembly. RFlow connects data and execution; RGL addresses type and orchestration expressions. RobbyDataTools helps users understand runtime state and validate results.
The platform is evolving toward easier composition, clearer application relationships, and more understandable and reproducible execution. Configuration selects capabilities, orchestration organizes behavior, and the runtime hosts execution. This reduces compile-time coupling to specific implementations while retaining the necessary room for user programming and extensions.