VDA 5050 and ISO 21423 both concern industrial mobile-robot interoperability, but they should not be treated as two finished documents with interchangeable fields. VDA 5050 publishes an implementable master-control interface; ISO 21423 defines broader communication and interoperability scope and is still in final publication processing.
As of July 29, 2026, ISO lists edition 1 at stage 60.00, International Standard under publication, following the July 21 close of final voting. That is more advanced than an FDIS ballot, but the final International Standard is not yet shown at stage 60.60. Procurement language should state this exact status.
Use this guide with the VDA 5050 version 3 guide and Open-RMF integration guide. Verify the current official pages again at contract or design freeze.
State the current publication status precisely
The official ISO 21423 page currently says Under publication and stage 60.00. Its lifecycle records final voting closure on July 21, 2026. Do not call it a published International Standard until ISO marks the publication stage complete.
The official VDA 5050 repository identifies version 3.0.0 as the latest published version on its main branch. Status can change, so include an as-of date, edition and source URL in requirements instead of writing latest without a frozen reference.
Understand the concrete VDA 5050 interface
VDA 5050 specifies communication between a central master control and mobile robots, with structured messages such as orders and states plus actions, factsheets and connection behavior. The exact fields, constraints and JSON schemas depend on the named protocol version.
The official VDA 5050 repository states that the published VDA PDF prevails over differences in GitHub markdown or schemas. Archive the valid PDF, schemas and implementation profile together so engineers and suppliers test the same edition.
| Dimension | VDA 5050 | ISO 21423 | Procurement implication |
|---|---|---|---|
| Current state | Version 3.0.0 published | Stage 60.00 under publication | Name status and date |
| Public detail | Messages and schemas available | Abstract and lifecycle public | Do not invent field mapping |
| Primary scope | Master control to mobile robots | Industrial AMR system communications | List system boundary |
| Conformance | Implementation tests required | Final edition package needed | Demand evidence |
| Safety | Not established by interface claim | Safety requirements excluded in abstract | Specify separately |
Read ISO 21423 as a system interoperability scope
ISO’s public abstract says the standard specifies communication protocols enabling interoperability among industrial AMR systems from different vendors. It covers AMRs, fleet manager equipment and other enterprise resources communicating with AMRs in an industrial environment.
The same abstract excludes safety-related requirements and mobile machines on public roads. Without the final purchased standard, do not claim its detailed messages, field semantics or exact equivalence to VDA 5050. Public scope is useful for architecture planning, not a substitute for normative text.
Do not infer one-to-one field mappings
Two documents can cover similar actors while defining different data models, timing, lifecycle, exceptions and conformance. A table that pairs every VDA message with a guessed ISO field creates false certainty. Build mappings only from the exact normative editions and an approved implementation profile.
Record unmapped, partially mapped and extension-dependent behavior. Preserve source field, destination field, units, allowed values, default handling and information loss. Test round trips where translation must be reversible.
Separate overlap from replacement
A future ISO edition may overlap VDA 5050’s communication boundary, but overlap does not prove immediate replacement. Installed systems, vendor support, conformance tooling and contractual obligations persist. Migration depends on implementable detail and verified product support.
Define a decision gate: final standard obtained, supplier implementation available, required functions mapped, multi-vendor tests passed and rollback proven. Until then, continue a controlled VDA interface rather than treating a standards milestone as an automatic production cutover.
| Vendor claim | Evidence to request | Acceptance test | Reject when |
|---|---|---|---|
| Supports VDA 5050 | Exact version and profile | Schema plus message traces | Version unspecified |
| ISO 21423 ready | Edition and implemented functions | Normative conformance package | Based only on roadmap |
| Interoperable | Tested vendor combinations | Normal and exception matrix | Single-vendor demo |
| Backward compatible | Negotiation and fallback | Mixed-version operation | Silent downgrade |
| Safety compliant | Separate safety basis | Risk-specific validation | Protocol claim used as proof |
Turn standard support into a versioned profile
Write the required order types, actions, state updates, maps, zones, load handling, battery, charging, errors, connection lifecycle and extensions. Name mandatory and optional behavior. Two vendors can both claim a standard while implementing different optional subsets.
Require schemas, sample payloads, broker or transport settings, update rates, timeouts and reason codes. Freeze the profile with acceptance tests. A marketing checkbox is not sufficient evidence for mission interoperability.
Keep safety outside the protocol comparison
The ISO public abstract explicitly excludes safety-related requirements, and VDA 5050 communication does not by itself establish protective performance. Keep functional safety, speed and separation, emergency stop, facility access and recovery procedures in their own verified requirements.
A master-control stop request can support operations, but its network path should not be presented as a safety function without an appropriate safety architecture and validation. Use the Physical AI safety-layer guide to preserve this boundary.
Write present and transition requirements separately
For a system being built now, specify the deployed VDA 5050 version and functions that suppliers must pass. Add a separate ISO 21423 transition clause with triggers, evidence, schedule and commercial responsibility. This prevents an unpublished or unsupported future interface from weakening current acceptance.
Define who funds adapters, firmware and retesting. State how long legacy operation remains supported. Include data retention so incident evidence is comparable before and after migration.
Design explicit version negotiation and failure
Mixed fleets need an explicit mechanism to identify supported versions and profiles. Unknown or incompatible versions should fail visibly before orders are accepted. Silent field dropping or best-effort interpretation creates dangerous partial operation.
Test downgrade, upgrade, rollback, broker restart and a participant joining with an unsupported schema. Keep dual support bounded; indefinite compatibility layers multiply test combinations and hide which interface actually controlled a robot.
Test exceptions more heavily than normal orders
Exercise duplicate and out-of-order messages, update loss, stale state, rejected actions, canceled orders, blocked nodes, low battery, connection loss and restart. Confirm idempotency and authority. A normal pickup-and-delivery demo proves little about interoperability under failure.
Build a vendor-pair matrix across robot and master-control implementations. Track exact software, protocol version, optional features and broker settings. One passing pair does not prove all combinations.
Use conformance evidence and operational pilots
Collect schema validation, protocol traces, automated test results, mapping records and supplier declarations. Then run a bounded pilot with real task, traffic and recovery conditions. Conformance to message format does not prove acceptable throughput or fault recovery.
Define rollback conditions and preserve original logs. Recheck after firmware, master-control or standard-profile changes.
Make the decision from a testable package
Approve interoperability from a package containing the exact editions, system boundary, functions, extensions, security settings, exceptions, vendor combinations and acceptance results. Revisit the package when ISO publication status or product support changes.
Use a concise decision checklist.
- Record the official status and as-of date.
- Name exact versions and implementation profiles.
- Do not invent normative field mappings.
- Test vendor combinations and exception sequences.
- Keep safety and migration requirements separate.
Frequently asked questions
Is ISO 21423 already a published International Standard?
As of July 29, 2026, ISO lists it at stage 60.00, under publication, not yet stage 60.60 published.
Will ISO 21423 immediately replace VDA 5050?
No automatic replacement follows from publication. Migration depends on normative detail, vendor support, mapping and verified transition tests.
Does VDA 5050 support guarantee plug-and-play fleets?
No. Exact version, optional functions, extensions, transport settings and exception behavior still require agreement and testing.
What should an RFP say about these standards?
Name exact current versions and functions, evidence, test matrix and a separate future ISO transition condition.
Does interoperability conformance prove safety compliance?
No. The ISO abstract excludes safety-related requirements, and communication conformance is not a safety validation.
Standards Status and Conformance Boundary
Standards status and product support change. Verify official sources and obtain the applicable normative documents before contracting or certifying an implementation.