One mission, many machines: the autonomy ecosystem after the single-robot era.

Two systems can exchange JSON and still disagree about the task. One may interpret a waypoint as the centre of the robot; another as the payload edge. One may report complete when it reaches a position; another when an attached workcell acknowledges the handoff. A timestamp without clock quality can make stale data look current. A common status word can hide different failure and recovery semantics.

Operational interoperability therefore needs at least four alignments: message shape, semantic meaning, spatial and temporal reference, and authority. The adapter must state what the source system means, what was lost in translation, and which actions remain unsupported. Silent approximation is more dangerous than an explicit capability gap.

VDA 5050 Version 3.0.0 is a current, important interface for communication between central master control and mobile robots in intralogistics. It creates a valuable common boundary for orders and status. It does not make an AMR, aerial drone, industrial arm, inspection sensor, and autonomous road vehicle interchangeable, nor does it define the enterprise approval or evidence workflow around them.

Open-RMF provides a broader coordination pattern for heterogeneous fleets and infrastructure. Its public demonstrations cover task dispatch, traffic conflict handling, lifts, doors, campus routes, workcells, and fleets with limited pause/resume APIs. The architectural lesson is federation through adapters: independent systems expose the control and state needed for shared scheduling while retaining their vendor-specific internals.

OPC UA for Robotics 1.02 adds an industrial information-model perspective. It covers motion-device systems, robot and controller identity, operating modes, component structure, asset configuration, and runtime or condition data. Those records can help a mission layer decide whether a device is eligible, healthy, configured correctly, or due for intervention—without pretending OPC UA is the mission planner.

A static registry says a robot has a gripper. A useful capability passport says which end effector is currently installed, the supported payload envelope, the available sensing modes, the operating-zone restrictions, the software and configuration identity, battery or energy state, communication modes, maintenance state, and which evidence the platform can return for task completion.

The passport should also expose uncertainty and temporary degradation. A robot may remain eligible for transport but lose precise placement because a camera is unavailable. A drone may retain visual inspection but lose an accurate global position. A manipulator may be healthy while the receiving fixture is not. Capability is a time-varying claim that needs provenance, not a permanent checkbox.

Robots compete for narrow corridors, doors, lifts, chargers, loading docks, workcell windows, tools, and human attention. A local planner can produce a collision-free route for one platform and still create a system-level deadlock. A drone and a mobile robot may not collide physically yet can invalidate each other's sensing or operating zone. A workcell can be ready mechanically while its upstream quality release is still pending.

The ecosystem needs explicit reservations, dependencies, leases, and release evidence for these resources. Open-RMF demonstrates the importance of traffic and infrastructure negotiation for mobile fleets. NodeRiQ's wider research question is how the same resource record can inform unlike platforms and how uncertainty or priority changes should trigger replanning without erasing human intent.

ROS 2 Kilted made rmw_zenoh a Tier 1 middleware implementation and documents security support, reflecting continued work on flexible distributed communications. Technology choice alone, however, does not define degraded operation. The programme must decide which task states are safe to continue locally, which evidence is stored, how identities and clocks are maintained, and what happens when two disconnected participants make incompatible progress.

NodeRiQ's classical-first position is that local safety and platform control remain available without cloud or quantum access. A device can continue a pre-authorized bounded action, pause at a safe point, or return according to its local policy. When the link returns, the mission layer should reconcile event histories rather than overwrite one participant with the latest snapshot. Conflicts remain visible until a rule or accountable person resolves them.

A cross-device mission plane can become a powerful path for lateral movement if identity, authorization, software provenance, and least privilege are weak. A camera should not gain motion authority because it shares a message bus. A fleet adapter should not be allowed to close a work order it cannot verify. A model-generated plan should not gain direct access to an unrestricted device API.

Current 2026 robotics safety work is explicitly layered. NVIDIA's Halos for Robotics announcement spans compute, sensing, system software, safety applications, inspection, and preparation for third-party certification. ISO 10218 separates the industrial robot from the integrated application, while ISO 3691-4 treats the operating zone as material to driverless industrial-truck safety. The lesson for NodeRiQ is that ecosystem assurance cannot be delegated to one model, protocol, or robot vendor.

The proposed NodeRiQ Mixed-Fleet Coordination PoC should remain deliberately small: one simulated or non-production mission thread, two or three heterogeneous device or fleet interfaces, one shared resource such as a door, charger, corridor, or workcell, and one degraded-link or stale-sensor event. The PoC does not need to replace existing fleet managers. It needs to prove that mission meaning, authority, evidence, and recovery survive the adapters between them.

A credible acceptance packet includes the original work order; every capability claim used for assignment; adapter version and known gaps; map and time transformations; resource reservation; device acknowledgements; evidence supporting each state transition; the injected failure; human decision; recovery; and the final reconciliation. The system should also demonstrate a safe refusal when a required capability or translation cannot be established.

This ecosystem model is a public architecture and engagement direction for the NodeRiQ applied programme. It draws on current standards and public robotics platforms to define where a shared mission and evidence layer may add value. It does not claim released adapters, compatibility with every vendor, control of certified systems, production deployment, or performance at fleet scale.

The commercial conversation should therefore begin with the customer's existing devices and constraints. Which fleet managers must remain? Which standards are already supported? Which shared resource causes the most operational friction? Which handoff lacks evidence? Which failure is expensive or unsafe to diagnose? A high-quality PoC answers one of those questions with a reviewable record before the ecosystem expands.