RTLS Requirements Template: How to Write Specs Vendors Can Actually Deliver

A vendor-proof RTLS requirements template (industrial-ready)

RTLS projects go off-track when requirements are written as marketing adjectives:
“high accuracy,” “real-time,” “stable,” “low latency.”
Those words cannot be tested, so acceptance becomes an argument.

A production-grade RTLS specification should read like an engineering contract:
it defines what the system must output, where it must work, how fast it must respond,
and how the result will be verified.

1) Project scope and objectives

1.1 Scope statement (copy/paste)

• Site type: (factory / warehouse / tunnel / yard / mixed indoor–outdoor)
• Coverage boundary: list buildings/areas/floors; include excluded areas
• Primary objective: (safety / compliance / dispatch / productivity / audit)
• Go-live date and phases: pilot zone → expansion zones

1.2 Constraints

• Power constraints: PoE allowed? DC available? hazardous-area limitations?
• Network constraints: public internet allowed? only private network? gateway required?
• Installation windows: shutdown periods, access rules, height work permits

2) Define entities and identifiers (what you track)

1. People: roles (operator, contractor, visitor), PPE requirements, tag form factor rules
2. Vehicles: forklift, tugger, truck, crane, AGV; speed ranges and critical interaction zones
3. Assets: pallets, tools, high-value equipment; whether they need continuous tracking or zone presence

Contract requirement: Every entity must have a stable ID that remains consistent across time, zones, and (if applicable) indoor/outdoor transitions.

3) Define zones, routes, and events (what must be produced)

3.1 Zones and routes

• Zones: restricted areas, hazardous areas, loading bays, work cells, mustering points
• Routes: tunnel segments, aisles, corridors, vehicle lanes
• Portals: indoor–outdoor doors, checkpoints, tunnel mouths, yard gates

3.2 Event catalog (copy/paste)

• Enter/leave zone
• Dwell time (e.g., “> X seconds in forbidden zone”)
• Route deviation (for tunnels/aisles)
• Proximity risk (person–vehicle, vehicle–vehicle, asset–hazard)
• Attendance/mustering (who is in which zone at a time)

Contract requirement: Events must be logged with timestamps, entity IDs, zone IDs, and event outcomes (triggered/acknowledged/closed).

4) Specify output level per area (the main cost lever)

Do not specify one output level for the entire site.
Most industrial sites need mixed output levels:
presence for most areas, 1D for linear spaces, and 2D/3D only for critical interaction zones.

5) Performance budgets (write them so they are testable)

5.1 Accuracy requirements (recommended structure)

• Define test zones: list worst zones explicitly (corners, rack ends, portals)
• Use percentiles: specify P95 and P99 positional error per zone
• Define the scenario: walking path, vehicle path, traffic density, obstruction conditions

5.2 Latency requirements (non-negotiable for safety)

Latency must be end-to-end:
movement → position update → event detection → alarm output.

• Safety events: specify maximum latency under normal and peak load
• Non-safety events: can allow higher latency, but must be consistent

5.3 Update rate requirements (zone-specific)

• Specify update rate per entity type (people vs vehicles) and per zone (critical vs non-critical)
• Specify the allowed behavior when update rate drops (e.g., “mark as unknown” vs “hold last position”)

6) Infrastructure and architecture requirements

6.1 Power and installation

• Allowed anchor types (wired PoE / DC / wiring-free beacons) by area
• Mounting constraints (height range, permitted structures, environmental rating)
• Documentation requirements (mounting drawings, cable routes, labeling)

6.2 Networking and security

• Network mode: on-premise / private cloud / public cloud
• If public internet is restricted: gateway-based architecture and approved uplinks
• Role-based access, audit logs, and secure data transport requirements

7) Data, reporting, and retention (evidence trail)

• Real-time view: live positions and status
• Playback: track replay for investigation
• Retention: define minimum retention period (weeks/months) for tracks and events
• Exports: event logs and reports in a defined format for audit

8) Acceptance test plan (make it hard to “demo dodge”)

8.1 Required test artifacts

• Worst-zone map with marked test routes
• Test scripts (step-by-step actions)
• Raw logs and summary report (including failures)

8.2 Recommended acceptance tests

1. Baseline consistency test: repeat the same route twice; results should be consistent.
2. Worst-zone stress test: corners/portals/racks under real traffic conditions.
3. Latency test: measure end-to-end event trigger time under normal and peak load.
4. False alarm test: quantify false triggers at boundaries; require hysteresis behavior.
5. Outage behavior test: define what happens if an anchor, gateway, or network path fails.

9) Handover deliverables (what you must receive before final payment)

• As-built package: anchor/beacon/gateway layout, IDs, mounting heights, photos
• Configuration export: zones, rules, thresholds, schedules
• Maintenance SOP: battery plans, replacement schedule, spare parts list
• Re-validation procedure: what to re-test after site changes
• Training: operator training + admin training

10) Optional appendix: mapping requirements to hardware families

If your solution includes a mix of infrastructure types, define where each family is allowed:

• PoE anchors: permanent areas requiring stable timing and predictable uptime
• Wiring-free UWB beacons: retrofit or construction-restricted areas with battery maintenance programs
• Tunnel/linear base stations: long corridors or tunnels requiring controlled handovers
• Gateways: restricted networks or segmented field deployments
• Outdoor GPS RTK chain: yard/port/mining coverage with reference station and correction delivery