The WIA-ROB-011 Cleaning Robot Standard sets out a common framework for interoperability so that a cleaning robot from any manufacturer can be integrated with smart homes, buildings and enterprise management systems without friction. Its mission, lowering the barriers to cleaning automation and accelerating innovation through open collaboration, follows directly from WIA's founding philosophy of 弘益人間, "benefit all humanity".
The standard envisions a world in which cleaning robots behave as interoperable, dependable infrastructure, much as Wi-Fi does, regardless of manufacturer, deployment size or environmental complexity. Customers choose robots on performance and features rather than on ecosystem lock-in. Developers build a value-added service once and deploy it to every compatible device. Building managers coordinate a mixed fleet of robots from different vendors through a single interface.
Universal interoperability: a robot that conforms to WIA-ROB-011 works with every conforming control system, whoever made it.
Data portability: robot state, maps, cleaning history and sensor data move between systems through standardized formats.
API consistency: developers learn one API to control every conforming robot, removing the burden of a separate integration per manufacturer.
Security by design: authentication, encryption in transit and encryption at rest are required at the specification level to protect users and facilities.
Future-ready architecture: extension fields and versioning rules let new technology be absorbed without breaking compatibility.
WIA-ROB-011 defines standard interfaces for autonomous and semi-autonomous cleaning devices. It deliberately does not prescribe mechanical designs or navigation algorithms; it concentrates on data exchange, control interfaces, communication protocols and integration with external systems.
The specification's data model (occupancy-grid maps, floor surface types, suction control and so on) is written around floor-cleaning robots. Other kinds of cleaning robot reuse the common layers unchanged, namely robot identity, state, events, commands, the API and the communication protocols, and express type-specific information through extension fields prefixed with x_.
| Robot category | Sub-types | How the standard applies |
|---|---|---|
| Floor cleaning | Vacuum, mopping, combined vacuum-and-mop, floor scrubber | Specification data model applies directly |
| Window cleaning | Residential windows, high-rise façades, skylights | Common layers + extension fields |
| Sanitization and disinfection | UV-C disinfection, chemical fogging, steam cleaning | Common layers + extension fields |
| Pool maintenance | Pool vacuum, scrubber and skimmer robots | Common layers + extension fields |
| Specialized systems | Escalator cleaning, solar-panel cleaning, duct cleaning | Common layers + extension fields |
The standard does not cover manual cleaning equipment (even when it is electronic), fixed cleaning infrastructure such as car-wash systems, or non-autonomous cleaning devices that require continuous human operation. Those systems fall under other standards or existing industry specifications.
WIA-ROB-011 follows the four-phase structure shared by WIA standards. Each phase is defined in its own specification document (PHASE-1 to PHASE-4, all at v1.0.0), and each phase builds on the one before it, so the standard can be adopted incrementally. Chapters 4 to 7 cover the phases in turn.
Prerequisites: none
Complexity: low
Value: data portability, vendor independence
Phase 1 sets the rules for representing cleaning-robot data in JSON-LD. It covers robot identity (CleaningRobot), robot state (RobotState), maps (OccupancyGrid), cleaning session logs (CleaningSession), LiDAR and camera sensor data, events and commands. Every timestamp must use ISO 8601 with a time zone, and every measurement must use SI units. Because any system can export and import this format, it enables:
Prerequisites: Phase 1
Complexity: medium
Value: programmatic control, integration flexibility
Phase 2 defines a RESTful HTTP API (base path /api/v1) and a WebSocket interface for controlling and monitoring robots. Every endpoint must implement authentication and rate limiting. Standardized endpoints, request and response formats and error handling make the following possible:
Prerequisites: Phase 2
Complexity: high
Value: secure communication, automatic discovery, safe firmware management
Phase 3 defines network protocols, security requirements, device discovery and the firmware update mechanism. Its main elements are:
wia/rob/{robot_id}/..., with QoS 0, 1 or 2 depending on the message type)_wia-rob._tcpPrerequisites: Phase 3
Complexity: very high
Value: ecosystem interoperability, fleet operations
Phase 4 connects cleaning robots to the wider ecosystem. The integration targets named in the specification are smart home platforms (Amazon Alexa, Google Assistant, Apple HomeKit, Samsung SmartThings), fleet management (multi-robot coordination, zone assignment, load balancing), cloud IoT services (AWS IoT Core, Azure IoT Hub and others) and third-party automation tools (IFTTT, Zapier, Home Assistant). This enables scenarios such as:
┌──────────────────────────────────────────────────────────┐ │ WIA-ROB-011 Architecture │ ├──────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Smart Home │ │ Building │ │ Enterprise │ │ │ │ Platform │ │ Management │ │ Systems │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ └─────────────────┼─────────────────┘ │ │ │ │ │ ┌────────────────────────┴───────────────────────────┐ │ │ │ WIA-ROB-011 API Layer │ │ │ │ (RESTful HTTP, WebSocket, MQTT) │ │ │ └────────────────────────┬───────────────────────────┘ │ │ │ │ │ ┌────────────────────────┴───────────────────────────┐ │ │ │ Standardized Data Formats (JSON-LD) │ │ │ │ State | Maps | Session Logs | Sensors | Events │ │ │ └────────────────────────┬───────────────────────────┘ │ │ │ │ │ ┌────────────────────────┴───────────────────────────┐ │ │ │ Robot Abstraction Layer │ │ │ │ (Manufacturer-Specific Translation) │ │ │ └────────────────────────┬───────────────────────────┘ │ │ │ │ │ ┌───────┬───────┬────────┴┬─────────┬───────┬───────┐ │ │ │Vacuum │ Mop │ Floor │ Window │ UV │ Pool │ │ │ │Robot │ Robot │Scrubber │ Cleaner │ Robot │Cleaner│ │ │ └───────┴───────┴─────────┴─────────┴───────┴───────┘ │ │ │ └──────────────────────────────────────────────────────────┘
Reading the diagram from top to bottom: smart home platforms, building management systems and enterprise systems all reach the robot through the WIA-ROB-011 API layer (RESTful HTTP, WebSocket, MQTT). Beneath it sit the standardized data formats (JSON-LD: state, maps, cleaning session logs, sensors, events), and a robot abstraction layer (manufacturer-specific translation) maps them onto each device. At the bottom are the physical devices: vacuum robots, mopping robots, floor scrubbers, window cleaners, UV robots, pool cleaners and so on.
The standard puts ease of implementation ahead of covering every edge case. A practical solution that is widely adopted creates more value than a perfect one that is rarely adopted. Foundational parts such as the Phase 1 data format are designed so that they can be applied to existing products with comparatively little effort.
All data carries version information such as @version and schemaVersion. Backward compatibility must be maintained across minor versions; a major version change requires migration tools and documentation of breaking changes. A breaking change to a normative clause of the specification requires a major version bump, and WIA-published reference implementations must support the previous major version in parallel for at least 90 days.
Implementations may add custom fields prefixed with x_ (for example x_customField). The prefix rule keeps manufacturer-specific information from colliding with fields that future versions of the standard may add. Third-party tools ignore extension fields they do not understand, while a manufacturer's own tools can use them to offer advanced features.
Every API endpoint must implement authentication, and network communication requires TLS 1.3 or later with certificate validation. Stored data is also subject to encryption. Privacy-sensitive data such as maps and camera images needs access control; the security details are covered in Chapters 6 and 8.
WIA publishes reference implementations under the WIA-Official GitHub organization: a TypeScript SDK skeleton, a POSIX shell client that demonstrates the request/response contract, and a browser-based simulator. The specification documents are published under the MIT License, and no particular library is mandated.
WIA-ROB-011 reuses or normatively references published international standards. The standards listed in the specification's Annex B are shown below. The cross-walk is informative; where it conflicts with a WIA requirement, the more specific WIA requirement governs unless a binding national regulation says otherwise.
| Referenced standard | Subject | Role in WIA-ROB-011 |
|---|---|---|
| ISO/IEC 17065:2012 | Requirements for bodies certifying products, processes and services | Conformity assessment for the highest conformance tier (Tier 3) |
| ISO/IEC 27001:2022 | Information security management systems | Baseline for security management |
| IETF RFC 9457 | Problem Details for HTTP APIs | API error responses |
| IETF RFC 7519 | JSON Web Token (JWT) | Recommended authentication token |
| IETF RFC 6749 | The OAuth 2.0 Authorization Framework | Authorizing third-party access |
| W3C PROV-DM | Provenance data model | Recording where data came from |
On the ecosystem side, the Phase 3 and Phase 4 specifications describe how to connect to major smart home platforms such as Matter/Thread, Apple HomeKit, Amazon Alexa and Google Home, and to cloud IoT services such as AWS IoT Core and Azure IoT Hub. Chapter 7 covers the concrete integration methods.
This book distinguishes three compliance levels (Basic, Standard, Advanced) according to how many phases a manufacturer has implemented (see Chapter 1). Separately, the specification defines three conformance tiers according to who verified conformance and how. The two axes are independent: an Advanced-level implementation can, for example, remain at self-declaration (Tier 1).
Requirements:
Target: entry-level products, gradual support in existing products
Benefits: data portability, backup and restore, analytics integration
Requirements:
Target: mid-range products, smart home integration
Benefits: control from third-party apps, smart home compatibility
Requirements:
Target: premium and commercial products, fleet operators
Benefits: ecosystem integration, multi-robot operation, enterprise management
| Tier | Scope | Mandatory artifacts | Audit cadence |
|---|---|---|---|
| Tier 1 — Self-declared | Internal use, pilot deployments | OpenAPI 3.0 contract, JSON Schema validation report, security threat model | Annual self-review |
| Tier 2 — Third-party assessed | External partners, B2B integrations | Tier 1 artifacts + signed third-party assessor report | Every 24 months |
| Tier 3 — Accredited | Public-facing or regulated deployments | Tier 2 artifacts + WIA accreditation, ISO/IEC 17065:2012 conformity assessment, evidence retained for at least 7 years | Every 12 months |
Implementations must disclose their conformance tier in the OpenAPI info.x-wia-tier extension and on any public certification page, and must report a tier downgrade to the WIA registry within 30 days. An implementation claiming Tier 2 or higher must pass every published test vector in both directions: request serialization and response deserialization.
The Phase 4 specification defines certification as the five steps below. Chapter 8 covers practical preparation and checklists.
The manufacturer applies for certification, identifying the product and the scope of implementation.
Automated tests verify API endpoint compliance, data format validity, performance benchmarks and similar items.
Items that automated tests cannot easily confirm, including the security audit, are reviewed by hand.
Interoperability with other systems is tested.
A product that passes every step is certified. Certified products must continue to undergo an annual security audit.
The WIA-ROB-011 specification documents, reference implementations and simulator are available from the public repository of the WIA-Official GitHub organization. The Phase 4 specification names TypeScript, Python, Java, C#, Go and Rust as the target languages for official SDKs and gives the package name wia-rob-011. At the time of writing, however, no package under that name has been published to public registries such as npm or PyPI. What is available today is the TypeScript SDK skeleton in the cleaning-robot/api/typescript directory of the public repository (module name wia-rob-011, main class WiaCleaningRobot). It is reference material intended as a starting point, not a production-grade implementation.
# Get the reference SDK skeleton from the public repository git clone https://github.com/WIA-Official/wia-standards-public.git cd wia-standards-public/cleaning-robot/api/typescript # Package names given in the specification (PHASE-4 §7.2); # not yet published at the time of writing # npm install wia-rob-011 # pip install wia-rob-011
Comments and proposals on the specification are accepted through the GitHub issues tracker of the WIA-Official organization. Each part of the specification is managed in one of three stability classes. Normative clauses marked MUST/MUST NOT are Stable and follow semantic versioning; the open questions in the annexes are Provisional and may be promoted to normative status after open discussion; test vectors, the simulator and the reference SDK are Reference material, versioned independently of the specification documents.
The WIA-ROB-011 specification is published under the MIT License, so any manufacturer can read and implement it without licence fees or royalties. Implementing the specification and obtaining official certification are separate matters: certification requires going through the process in Section 3.8. This openness lowers the barrier to adoption and helps many manufacturers and developers compete and collaborate on the same foundation.
x_ extension fieldsx_ extension fields balance standardization against manufacturer innovation?