Service Discovery

The Service Registry is a centralized or distributed database that maintains a real-time directory of all active agents (services) in the fleet. Each agent registers its endpoint (e.g., IP address, port), capabilities, and current status upon startup and sends periodic heartbeats to indicate liveness. The registry is the single source of truth for the orchestrator, enabling it to query for agents matching specific task requirements. In distributed systems, this is often implemented as a key-value store like etcd, Consul, or Apache ZooKeeper.

This component ensures the registry's data remains accurate by detecting agent failures. A Health Check is a probe (e.g., an HTTP endpoint, TCP ping) that the registry or a sidecar process executes to verify an agent's operational state. A Heartbeat is a regular, proactive signal sent by the agent to the registry to confirm it is alive. If heartbeats cease or a health check fails, the agent is marked as unhealthy or deregistered, preventing the scheduler from assigning tasks to a non-responsive resource. This is critical for maintaining system fault tolerance.

The Discovery Client is the software library integrated into each agent that handles interactions with the service registry. Its responsibilities include:

• Registration: Automatically registering the agent upon startup with its metadata.
• Deregistration: Gracefully removing the agent's entry during shutdown.
• Service Lookup: Querying the registry to discover other agents the client may need to communicate with directly in peer-to-peer architectures. This decouples the agent's logic from the underlying discovery infrastructure, simplifying development. Libraries like Netflix Eureka Client or HashiCorp Consul client are common examples.

Often integrated with or sitting in front of the discovery system, the Load Balancer distributes incoming task requests or traffic across healthy instances of a service. It queries the service registry to obtain the current list of available agents. An API Gateway acts as a single entry point for all client requests, routing them to the appropriate backend service discovered via the registry. This pattern, central to microservices, is equally vital in robotics fleets where a central orchestrator dispatches tasks to the most suitable, available robot. Tools like NGINX, HAProxy, or Kubernetes Service objects fulfill this role.

Beyond a simple address, effective discovery relies on rich metadata attached to each service entry. This structured data describes the agent's capabilities (e.g., can_lift: "heavy_payload", has_gripper: true), physical attributes (e.g., max_speed: 2.0), current load, and location zone. The scheduler uses this metadata for capability-based assignment. A well-defined schema is essential for precise queries, such as "find all agents with a vacuum attachment that are currently in Zone A and have battery > 40%."

In advanced architectures, service discovery is integrated with the Domain Name System (DNS). When an agent or orchestrator looks up a service name (e.g., picker-robot.service.warehouse), a DNS query is resolved to the current IP addresses of healthy instances, provided by the service registry. This is a core feature of service meshes like Istio or Linkerd, which use a sidecar proxy (e.g., Envoy) to handle discovery and traffic routing transparently. For robotic fleets, this abstracts network location, allowing agents to communicate via stable names rather than volatile IP addresses.

When a new autonomous mobile robot (AMR) or a manual forklift with a telematics unit joins the network, it automatically advertises its capabilities and current state to the orchestration platform. This includes:

• Capability Vector: Payload capacity, attachment types (fork, clamp, conveyor), and special skills (e.g., pallet stacking).
• Dynamic State: Current battery level, location, and operational status (idle, charging, in-error).
• Network Endpoint: The IP address and port where the agent's control API can be reached for task assignment. This automated registration eliminates manual configuration, allowing the fleet to scale and adapt instantly.

The centralized scheduler uses the service registry to match incoming tasks with qualified agents in real-time. For a task like "Retrieve a 500kg pallet from Zone A," the discovery system filters the fleet to identify agents that satisfy the hard constraints:

• Load Capacity: Agents rated for ≥500kg.
• Attachment Type: Agents equipped with forks.
• Location Proximity: Agents currently in or near Zone A.
• Availability: Agents with status 'idle' and sufficient battery for the operation. This precise matching is the core of dynamic task allocation, ensuring tasks are only assigned to capable agents.

Service discovery provides continuous health checks (heartbeats) to monitor agent liveness. If an agent fails to respond—due to a mechanical fault, network dropout, or battery exhaustion—it is immediately marked as unavailable in the registry. The scheduler then:

• Reassigns In-Progress Tasks: Tasks assigned to the failed agent are put back into the queue for rediscovery and assignment to a healthy agent.
• Adjusts Load Balancing: The overall workload is redistributed among the remaining healthy agents.
• Triggers Alerts: Notifies maintenance systems of the agent failure. This creates a self-healing fleet that maintains operational continuity despite individual agent failures.

In a mixed fleet, service discovery acts as the universal translator. It enables a unified orchestration layer to communicate with diverse hardware and software platforms:

• Legacy Systems: Manual vehicles report status via IoT gateways that register as a service.
• Multiple AMR Brands: Different manufacturers' robots (e.g., from MiR, OTTO, Fetch) each expose a standardized API endpoint discovered by the platform.
• Warehouse Management System (WMS): The WMS itself can be discovered as a service, providing task streams and inventory data. This abstraction is critical for orchestration middleware, allowing a single scheduler to command a heterogeneous fleet.

Service discovery is not a one-time lookup; it's a continuous stream of state updates. This real-time data feed powers spatial-temporal scheduling and real-time replanning engines. Key propagated states include:

• Location Updates: From lidar, UWB, or visual odometry, enabling collision avoidance.
• Battery Depletion Rates: Informing battery-aware scheduling to preemptively route agents to charging stations.
• Task Progress: Percentage completion, allowing for predictive scheduling of subsequent tasks. By consuming this live state, the orchestrator can dynamically adjust plans in response to congestion, delays, or new high-priority tasks.

Service discovery integrates with zone management protocols to enforce safety and efficiency rules. Agents advertise their current zone, and the discovery system checks this against access control lists. This enables:

• Speed Limit Zones: Identifying agents entering a 'slow zone' near human workers and commanding reduced speed.
• Exclusive Access Zones: Preventing multiple agents from discovering and attempting to enter a narrow aisle simultaneously.
• Dynamic Geofencing: Temporarily marking areas as 'discovered' for maintenance and removing all agents from the service pool for that zone. This contextual awareness prevents deadlocks and ensures safe cohabitation with human workers.

The real-time, automated process of assigning work items from a shared pool to a heterogeneous set of agents. It relies on service discovery to match tasks with agents based on:

• Current capability and status
• Agent availability and location
• Overall system objectives like throughput or cost minimization For example, in a warehouse, a mixed fleet of autonomous mobile robots (AMRs) and manual forklifts receives picking orders dynamically based on their proximity, battery level, and payload capacity.

The technique of maintaining a unified, real-time view of all agents' operational status. This is the data backbone for service discovery, aggregating:

• Agent pose (position and orientation) via SLAM or GPS
• Operational vitals like battery charge and diagnostic codes
• Current task load and estimated completion time Systems like ROS 2 use a distributed data space (DDS) to propagate this state, allowing the orchestrator to know which agents are idle, busy, or faulted at any moment.

A core allocation strategy that matches tasks to agents based on a formal specification of required skills or attributes. Service discovery provides the capability registry that makes this possible. Key elements include:

• Skill Ontologies: Structured vocabularies defining actions like lift, transport, or scan.
• Attribute Matching: Ensuring an agent has the correct payload interface, lift height, or sensor suite.
• Dynamic Updates: Capabilities can change, e.g., a robot attaching a new tool or a forklift being flagged for maintenance.

The core software platform that abstracts agent heterogeneity and provides unified control APIs. It consumes service discovery data to function. Essential components include:

• Unified Agent Model: A common interface for robots from different manufacturers (e.g., using VDA 5050 standard).
• Discovery Layer: A module that ingests heartbeat and status messages to maintain the agent registry.
• Scheduler API: Exposes endpoints for requesting agents with specific capabilities. Platforms like InOrbit, Formant, or Open-RMF provide this middleware layer.

The messaging standards and data formats that enable coordination and state propagation within a fleet. These protocols are the transport mechanism for service discovery messages. Common implementations include:

• Publish-Subscribe (Pub/Sub): Used by ROS 2 and DDS for broadcasting agent status topics.
• Request-Reply: For direct capability queries between a scheduler and an agent.
• Standardized Payloads: Formats like JSON or Protocol Buffers to encode capability advertisements, containing fields for agent_id, capabilities[], battery_level, and location.

A decentralized task allocation model where idle agents actively request or 'pull' the next task. This model inverts the discovery query: instead of a scheduler searching for agents, agents announce their availability. The process involves:

1. An idle agent broadcasts a bid or availability message.
2. A dispatcher or task queue matches the agent to a suitable pending task.
3. The task is assigned directly to the requesting agent. This reduces central scheduler load and can improve scalability in large, dynamic fleets.