Real-time locating system standards describe particular interfaces and behaviors within a location system. To evaluate interoperability, identify the exact standard part and edition, the components that implement it, and the evidence that those components work together. A standards name on a brochure is the beginning of that inquiry.
This guide is for RTLS buyers and integrators connecting tags, receivers, location software and business applications. Begin with the required outcome: presence in an area, a named zone, coordinates or a recorded transition. Define acceptable freshness and the application that will consume the result.
Understand what the standard covers
In 2003, INCITS announced three RTLS standards: two radio interfaces and an application interface. That division is useful historical context for today's procurement questions. Radio compatibility and application integration require different evidence.
For current catalog examples, ISO/IEC 24730-1:2014 addresses an application programming interface, while ISO/IEC 24730-2:2012 concerns a DSSS 2.4 GHz air-interface system and associated parts. The ISO catalog lists Part 1 as confirmed in 2025 and Part 2 as confirmed in 2023. Check the catalog status when specifying an edition.
These examples establish document scope. A purchasing or conformance decision requires the applicable normative requirements and implementation evidence. Other RTLS technologies and interfaces may be relevant to your deployment; identify them explicitly instead of treating the 24730 family as a universal compatibility label.
Ask for evidence at each boundary
On a narrow screen, scroll the table sideways. Keyboard: focus the table and use the arrow keys.
| Boundary | Questions for the supplier | Evidence to request |
|---|---|---|
| Tag to receiver | Which protocol, version, operating mode and regional variant? | Exact tag/receiver compatibility list and applicable test report |
| Receiver to location engine | Which transport, message format and supported firmware? | Integration documentation and a working data sample |
| Location engine to application | Which API version, authentication and event semantics? | API contract, error behavior and supported client example |
| Coordinates and time | What origin, axes, units, floor and timestamp meaning? | Coordinate convention and timestamp definitions |
| Asset identity | How does a tag map to the business asset and its lifecycle? | Identifier mapping, reassignment and retirement procedure |
| Operations | How are stale data, outages and upgrades represented? | Monitoring, recovery and version-support policy |
Assign an owner to every interface. Ask whether compatibility is based on a shared specification, a tested product pair or a custom adapter. Retain the exact scope of any certification or test report, including hardware, firmware, optional features and conditions.
Test the data your application will use
Create a small acceptance dataset using authorized test tags and known locations. Verify identity, position or zone, timestamp, validity and expected update behavior. Move a tag through a planned path and compare the location system's output with what the business application actually records.
In a fictional integration, a location engine reports x = 12.5 in metres from a warehouse origin. An application expects centimetres but reads the unconverted number. Both sides exchange valid messages, yet the displayed position is wrong by a factor of one hundred. Include units and coordinate transformations in the test, not just successful message receipt.
Test an unknown tag, a reassigned tag, a stale observation, a missing update and a supported receiver restart. Establish whether the application preserves the observation time or silently replaces it with receipt time. A delayed old location should remain identifiable as old.
Use the RTLS interface evidence record to keep document editions, mappings and test outcomes together. For position accuracy and zone-detection pilot design, continue with Wi-Fi Asset Tags; interface agreement and location quality are complementary checks.
Make compatibility maintainable
Agree how updates are tested before rollout. An API change, tag replacement, new receiver firmware or revised coordinate map can affect only part of the system while leaving its other components apparently healthy.
Keep a reproducible sample of valid, invalid and delayed messages, with sensitive identifiers replaced appropriately. Require an accountable owner for adapters and an exit plan for exporting asset mappings and location history in a documented format.
Before acceptance, confirm the original reader outcome: the intended application can use the location result with the required meaning and freshness, and failures are visible to the right operator. A standards reference helps organize this evidence; the completed integration test demonstrates the specific system you are buying.