Lyft recently published how it built the Glow emblem, its newest Internet-of-Things (IoT) device. The Glow is actively rolling out in markets across the US, with over 30,000 live devices. Its architecture addresses many challenges in previous iterations, including a unified IoT middleware framework, robust provisioning and authentication mechanisms and advanced device control.
The Glow Device (Source)
Previously, Lyft's engineers developed IoT devices with bespoke solutions that were difficult to scale or adapt across different use cases. These included the Amp, bikes, scooters, and autonomous research vehicles. By identifying standard functionalities across these devices, Lyft's engineering teams collaborated to build a middleware layer that could serve multiple device types.
Commercial cloud platforms offer off-the-shelf IoT frameworks that can significantly simplify the development process. These frameworks, such as Azure IoT or AWS IoT, offer pre-built mechanisms to provision and manage IoT devices based on abstractions for request-response, command and data stream communication patterns. However, Lyft's article doesn't mention using any such commercial platform.
To improve security, Lyft assigns Glow devices unique serial numbers during manufacturing. These serial numbers are stored on the device and in a central Device Registry, ensuring accurate tracking and management throughout the device's lifecycle. Authentication is handled through the Lyft app, leveraging a pre-shared key and the device's serial number.
This mechanism ensures that only authorized devices can connect to the Lyft backend and prevents unauthorized use by requiring successful authentication before the Glow can be activated. It prevents malicious parties from impersonating Lyft drivers with a Glow device obtained from someone or somewhere other than Lyft, contributing to riders' security.
End-to-end device control flow (Source)
The Glow device is paired with the driver's mobile device via Bluetooth Low Energy (BLE), and the Lyft driver app serves as the communication gateway, ensuring seamless data transmission between the device and the backend.
The backend service listens for event triggers, such as a driver approaching a rider's pickup location. It issues the appropriate instructions to the device in real-time by sending a command to the app, which forwards it to the device.
Commands can range from simple instructions, like adjusting brightness, which the app directly forwards to devices, to complex tasks, such as uploading new animation files to the device, that the app has to perform some pre-processing to execute successfully.
To upload new animation files to the device, the mobile app has to download the file from the Internet, divide it into small chunks, and then transmit it to the device.
Lyft engineers handle state management via a "Device Shadow" service that maintains a real-time mirror of each device's state (this is often called a "Device Twin" or a "Digital Twin"). This service ensures that the device's current state aligns with the desired state defined by the backend, facilitating remote management and updates.
Azure IoT Device Twins (Source)
The device's state includes critical information such as firmware versions, stored files, and operational configurations, which the device regularly synchronizes with the backend.
Firmware updates are managed through an Over-the-Air (OTA) Manager service, orchestrating the update process while safeguarding against potential issues such as power interruptions or faulty updates. These safeguards include backing up the old firmware to external storage before an upgrade, reverting on failure, and including an immutable recovery firmware image on each device.