Building an Asset Tracking System That Turns Events Into Actions published: true tags: architecture, iot, backend, systemdesign

Asset tracking systems transform events into actionable insights. While the concept seems straightforward, adding more complexity such as additional devices and unreliable connectivity makes it challenging. GPS provides location data, RFID readers confirm tag presence, Bluetooth Low Energy (BLE) receivers detect proximity, and IoT sensors monitor temperature and vibration. These methods have different data formats, and the challenge lies in converting this information into useful actions.

A robust tracking system does more than just plot dots on a map. It maintains reliable records, operates efficiently with intermittent connectivity, identifies critical events, and assists decision-making. Here's a step-by-step approach to building such a system.

1. Organize the system into distinct layers:

Physical Assets | v GPS / RFID / BLE / IoT Devices | v Connectivity and Data Ingestion | v Validation and Normalization | v Event Processing and Business Rules | v Storage and Asset History | v APIs / Dashboards / Notifications | v Operational Action

Keeping these concerns separate allows flexibility to modify individual components without a complete system overhaul.

2. Avoid conflating every event with a geographical location. For instance, an RFID read doesn't represent a coordinate, and a temperature reading is distinct from a location. Define a common event envelope to accommodate various event types, including timestamps, source information, and metadata.

3. Standardize data while preserving its original meaning. For example, GPS reports a vehicle's position, an RFID reader identifies a tagged container, and a BLE receiver detects a tool nearby. While these events relate to assets, they represent different types of evidence. Maintain shared elements like asset IDs, timestamps, and source identifiers, but retain the original measurements and their contextual meaning.

4. Anticipate devices going offline. Trucks may enter areas with no signal, sensors might disconnect, or readers might accumulate data after an outage. Implement local buffering, retries with backoff, event IDs for deduplication, device and server timestamps, out-of-order handling, and device health monitoring. Establish policies for managing stale data.

5. Separate raw observations from business events. A raw observation reflects what a device reported, while a business event indicates the significance of that data for operational purposes. For instance, a GPS observation alone doesn't pose a problem, but raising an alert requires evaluating the asset's assigned site, schedule, operating hours, and authorized movements. This separation ensures processing remains independent of evolving business policies.

6. Design alerts to minimize disruption. Tracking systems generate numerous events, and excessive notifications can lead to desensitization. Create alerts only when necessary, such as when an asset leaves an authorized area without proper authorization or when a temperature exceeds a set threshold for a specific duration. Configure thresholds and durations based on asset or use case requirements.

Consider implementing duplicate notification prevention, flapping threshold management, escalation procedures, and recovery events.

7. Align storage with access patterns. Tracking systems often answer questions like where an asset was last seen, what occurred on a specific date, which assets entered a particular area, which devices stopped reporting, or which readings exceeded their thresholds. Implement a current-state view for quick lookups and a separate historical event store for reporting and investigation purposes. Choose the appropriate database based on event volume and query patterns.

By following these guidelines, you can build a robust asset tracking system that accurately converts events into meaningful actions, regardless of the complexity introduced by various devices, location factors, and connectivity challenges.