RFID and IoT Asset Tracking in Aviation Warehousing

Summary

We build RFID and IoT asset tracking applications for aviation warehousing, where rotables, consumables, tooling and life-limited parts must have provable location, condition and certification status at any moment. This kind of work covers the capture layer of readers, antennas and sensors, the middleware that turns raw tag reads into business events, standards-based identification, and integration with the logistics, ERP or MRO systems already in place. The application sits as a hub between the physical floor and those systems, so asset status is derived from what was actually observed.

The Challenge

Manual scanning and paper travellers leave a gap between the moment a part physically moves and the moment the inventory system learns about it. Closing that gap is harder than it looks, because most of the trouble is physical rather than logical. Metal airframe parts and liquids detune tags and absorb energy, so tag selection, mounting and orientation matter more than software. Adjacent dock doors cross-read each other and produce phantom arrivals. Handhelds drift offline in racking aisles, so events must be buffered locally, timestamped at the edge and ingested idempotently, since duplicates and out-of-order arrivals are normal rather than exceptional. Naive builds treat read rate as a constant, underestimate reader power tuning and commissioning, and scatter tag encoding logic across handlers where it cannot be tested.

The Solution

Edge and capture layer

Automatic Identification and Data Capture hardware is heterogeneous by nature: fixed portal readers at dock doors and checkpoints, handheld and cart-mounted mobile scanners, standalone antennas covering staging lanes, Bluetooth and Wi-Fi based locators for coarse zoning, and weight sensors that confirm a physical event rather than just a radio one. Each device speaks a different dialect, so the architecture puts a device abstraction in front of them instead of coupling directly to a vendor SDK.

RFID middleware

Middleware is the core of the system. It subscribes to raw tag reads, applies filtering and smoothing windows to collapse the repeated reads a single tag produces into one arrival or departure event, resolves tag identity to a business object, and decides which downstream system is notified. A Spring Boot service layer is a practical base, deployable on an intranet, extranet or public network, with a React front end served through a Node build pipeline for operator dashboards, exception queues and manual overrides.

Identification and data structures

Interoperability depends on encoding identity to a standard rather than inventing keys, so the business layer handles the full GS1 identifier set:

• Serialized Global Trade Item Number and GTIN with batch or lot
• Global Location Number, with or without extension
• Global Returnable Asset Identifier and Global Individual Asset Identifier
• Global Service Relation Number, recipient and provider variants
• Global Document Type Identifier and Component or Part Identifier
• Serialized Global Coupon Number and General Identifier
• Defence and aerospace identifiers, with ATA Spec 2000 encoding and decoding

Each identifier maps to a different EPC memory bank layout and partition scheme, so encoding and decoding belongs in one tested module.

Workflow and integration

A checkpoint flow starts when tagged assets enter receiving. A fixed reader detects the tag population and triggers a weight sensor that confirms the physical movement, the middleware promotes the reads to a checkpoint event, and the asset record advances state. Downstream integration is message-based to the ERP or warehouse system, with REST endpoints for query and correction, and an append-only event store so any status can be replayed and explained.

How we build it

We begin with a functional specification that fixes the checkpoint model, identifier scheme and event vocabulary before any hardware is ordered, then prove the RF environment with a site survey. Middleware is developed against recorded reader traces so behaviour is testable without the floor, and the operator interface is built last, once event semantics are stable.

What This Delivers

Warehouse teams get inventory that reflects physical reality instead of remembered data entry, with receiving, put-away, movement, staging and dispatch recorded as they happen. Exceptions surface as queues to work rather than discrepancies found at stock count. Because every status is reconstructable from the event history, certification and location claims can be defended during an audit.

Technologies and Tools

• Spring Boot service layer, React front end, Node build pipeline
• REST and message-based integration to ERP, WMS and MRO systems
• Fixed portal RFID readers, mobile and cart-mounted scanners, antennas, Bluetooth and Wi-Fi locators, weight sensors
• GS1 identifiers and EPC memory bank encoding, ATA Spec 2000