WIA-ROBOT-FLEET-001: Robot Fleet Management

Overview

The Robot Fleet Management standard (WIA-ROBOT-FLEET-001) documents the WIA Standards canonical envelope shape, API surface, protocol exchanges, and ecosystem integration for robot fleet management hosts that need to interoperate across jurisdictions, vendors, and operational contexts.

The standard composes with the wider WIA Standards family to inherit cross-standard composition, audit transport (W3C Trace Context plus OpenTelemetry semantic conventions), and federation handshakes (per WIA-INTENT) without per-standard re-implementation.

Phase organisation

• spec/PHASE-1.md — Phase 1 wire-format envelopes
• spec/PHASE-2.md — Phase 2 REST + JSON-RPC surface
• spec/PHASE-3.md — Phase 3 protocol exchanges and federation
• spec/PHASE-4.md — Phase 4 ecosystem composition and compliance

Normative references

• ISO 22166-1:2021 Modular service robots - General Requirements
• ROS 2 (Robot Operating System) Iron Irwini
• VDA 5050 v2.0 (AGV interface)
• OPC UA Companion Spec for Robotics
• ISO 8373:2021 (Robotics vocabulary)
• ISA-95 (Enterprise-Control System Integration)
• MQTT 5.0 per OASIS
• OpenRMF (Open Robotics Middleware Framework)
• ISO 18646 series (Robot performance)

Companion artefacts

• README.md — scope, normative references, governance
• cli/robot-fleet-management.sh — POSIX shell helper with sample envelope generators
• eBook EN — 8 chapters
• eBook KO — 8 chapters
• Reference simulator
• Press kit

Conformance

A standard is conformant when (1) every Phase 1 envelope it emits validates against the published JSON Schema for that envelope class, (2) every Phase 2 endpoint it exposes honours the documented status codes, content shapes, and error envelopes, (3) every Phase 3 protocol exchange it participates in honours the handshake order, signature requirements, and audit hook contract, and (4) Phase 4 ecosystem composition reaches the required cross-standard capabilities (audit transport, identity, federation) per the Phase 4 Sec 4 capability matrix.

Implementation timeline (typical)

A first implementation of the Robot Fleet Management standard typically follows: stand up the reference container at wia/robot-fleet-management-host:1.0.0; run the conformance suite end-to-end; replace mock backend with real backend; wire audit-log replication; onboard a single trusted peer for federation; expand to multiple peers; promote to production with the warning-envelope subscription enabled.

Cross-standard composition recap

The Robot Fleet Management standard composes with the wider WIA Standards family. Implementations reuse the cross-standard audit transport (W3C Trace Context plus OpenTelemetry semantic conventions per wia.standard.slug = robot-fleet-management), the cross-standard identity (WIA-OMNI-API), and the cross-standard runtime trust list (WIA-AIR-SHIELD).

Backwards-compatibility envelope

Within the 1.x line, every Phase 1 envelope shape, every Phase 2 endpoint, and every Phase 3 protocol exchange MUST remain reachable. Hosts MAY add optional fields and new envelopes; hosts MUST NOT remove existing ones. Breaking changes ride a major version bump with a 12-month deprecation window per IETF RFC 8594 and 9745.

Privacy and data-minimisation envelope

Hosts that process personal data through Robot Fleet Management envelopes MUST honour the operator's per-jurisdiction privacy law (EU GDPR, UK GDPR, California CPRA, Brazil LGPD, Canada PIPEDA, Korea PIPA, Japan APPI, Australia Privacy Act).

Disaster recovery and continuity envelope

Hosts publish a continuity-of-operations envelope per ISO 22301:2019 + ISO/IEC 27031 + NIST SP 800-34 Rev 1 covering: per-host RTO, per-host RPO, per-host backup envelope, per-host failover-rehearsal envelope, per-host vendor-exit envelope. Composes with WIA Secure Enclave for sealed-backup envelopes.

Audit transport hooks

Every Phase 1 envelope SHOULD emit a structured log line at the host's audit transport: timestamp per RFC 3339, host identifier, tenant identifier, envelope class, envelope identifier, operation outcome, and a W3C Trace Context traceparent propagated end-to-end. Phase 2 surfaces this trace identifier as the X-WIA-Trace-Id response header. Phase 3 protocol exchanges propagate the trace identifier inside the exchange envelope so federation crossings remain correlatable end-to-end.

Capabilities discovery and SemVer

Hosts SHOULD publish a capabilities document at /.well-known/wia-robot-fleet-management-capabilities enumerating per-endpoint optionality. Clients MUST treat unsupported capabilities as absent rather than as an error. Hosts moving from one minor version to the next MUST publish the change in release notes with the per-capability migration window per IETF RFC 8594 + RFC 9745.

Governance

Maintained under the WIA Standards public-benefit governance model. See https://wiastandards.com/governance/ for committee composition, voting rules, and the per-standard release calendar.