Skip to content
Librux Runtime Kernel for Robotics development
Librux Runtime Kernel for Robotics development

    Host, Control Backend, and Federation

    The semantic model of Librux is subsystem-to-subsystem interaction.

    Application code should primarily think in terms of.

    • which subsystem provides a capability
    • which subsystem consumes that capability
    • which semantic surface is being used, such as Event, Control, Procedure, or Operation

    That semantic model stays valid even when the deployment grows across multiple machines.

    Why This Architectural Layer Exists

    A practical robot system rarely remains one sealed software stack on one machine for long.

    Semantically, Librux wants the system to be understood as a set of cooperating subsystems.

    Architecturally, those subsystems need real execution environments.

    • component compute machines
    • gateway or field-interface machines
    • perception compute nodes
    • UI or supervisory nodes
    • diagnostics or integration nodes

    In other words, the semantic unit is the subsystem, but the deployment has to be organized around real machines and network boundaries.

    For that reason, a real robot system usually grows into a distributed system shape even if it starts from a smaller local deployment. Different hardware interfaces, compute requirements, isolation needs, and network boundaries push different subsystem roles toward different machines.

    This does not mean Librux requires every deployment to span multiple machines from day one. Single-machine composition is supported. But the architecture is designed around the fact that many practical robot systems eventually need multiple machines.

    Once Librux is deployed in that kind of environment, the system needs architectural boundaries for these concerns.

    • machine-local subsystem lifecycle
    • status aggregation
    • route metadata
    • remote visibility
    • cross-machine forwarding and relay policy

    That is why Librux introduces three architectural concepts.

    • a host as the deployment boundary
    • a control backend as the host-level control plane
    • federation as the cross-machine relation

    These concepts solve deployment and network structure efficiently without changing the semantic model that user code sees.

    Host

    A host is the machine that runs one deployment unit of the robot system.

    It is the place where Librux groups together.

    • one control backend instance
    • one or more local subsystems
    • managed subsystem packages and resource leases
    • local transport paths
    • optional host-level time-sync processes

    So while the semantic model is subsystem-oriented, the deployment boundary is host-oriented.

    Control Backend

    The control backend is the control plane for one host.

    It owns the following.

    • subsystem registration and status aggregation
    • managed package launch and host-local resource authority
    • host-level discovery and route metadata
    • remote visibility of local subsystem capability
    • cross-host forwarding and relay policy
    • browser-facing or API-facing status surfaces

    This is why a subsystem does not need to own remote machine topology directly in application code.

    Federation

    Federation is the relation between hosts.

    It does not mean that a subsystem itself stretches across hosts. It means the following.

    • one host exports the relevant visibility of its local subsystems
    • another host learns that visibility through its control backend
    • remote delivery and control are resolved through the host-level runtime path

    So the user-facing semantics are subsystem-to-subsystem, but the actual cross-host realization is host-to-host through control-managed federation.

    Federation security also belongs at this host-to-host boundary. Subsystems do not manage peer keys or encrypted sockets directly. When enabled, the control backend wraps federation frames with a lightweight secure transport layer before they leave the host runtime.

    Architectural View

    flowchart LR subgraph SYS["One Robot System"] subgraph FED["Federated Host Topology"] subgraph H1["Host A"] OA["Control Backend A"] SA1["Subsystem A1"] SA2["Subsystem A2"] SA3["Subsystem A3"] OA ---|"physical relation"| SA1 OA --- SA2 OA --- SA3 end subgraph H2["Host B"] OB["Control Backend B"] SB1["Subsystem B1"] SB2["Subsystem B2"] OB --- SB1 OB --- SB2 end subgraph H3["Host C"] OC["Control Backend C"] SC1["Subsystem C1"] SC2["Subsystem C2"] OC --- SC1 OC --- SC2 end OA === OB OA === OC OB === OC end SA1 -.- SB2 SA2 -. "semantic relation" .- SB1 SA2 -.- SC1 SA3 -.- SB2 SB1 -.- SC2 end

    In this architecture.

    • each host runs one control backend
    • each control backend manages multiple host-local subsystems
    • federation is shown as the host-topology layer, not as a named subsystem interface
    • the multi-host deployment is one robot system, not several unrelated systems
    • solid lines show physical host-local relation
    • thick lines show the federation relation between hosts
    • dotted lines show example semantic relations between subsystems

    This is the same robot-system idea shown in Subsystems, Roles, And Interfaces, now drawn with its deployment boundaries. Federation is not a named interface between control backends. It is the architectural relation that allows one robot system to span multiple hosts.

    Why This Separation Matters

    This split keeps two things true at once.

    • user code can stay focused on subsystem capability and semantic intent
    • the runtime can handle real multi-host deployment concerns at the host boundary

    That separation is one of the main reasons Librux can keep the same subsystem model across local and federated deployments.