Lyft recently published how it built the Glow emblem, its latest Internet of Things (IoT) device. The Glow is currently being actively launched in the US and is already available in over 30,000 active devices. Its architecture overcomes many challenges of previous iterations, including a unified IoT middleware framework, robust provisioning and authentication mechanisms, and advanced device control.
The Glow device (source)
Previously, Lyft engineers developed IoT devices with bespoke solutions that were difficult to scale or adapt to different use cases. These included the Amp, bikes, scooters, and autonomous research vehicles. By identifying standard features for these devices, Lyft’s engineering teams worked together to create a middleware layer that could serve multiple device types.
Commercial cloud platforms offer ready-to-use IoT frameworks that can greatly simplify the development process. These frameworks, such as Azure IoT or AWS IoT, provide ready-made mechanisms for deploying and managing IoT devices based on abstractions for request-response, command, and data stream communication patterns. However, Lyft’s article does not mention the use of such a commercial platform.
To improve security, Lyft assigns unique serial numbers to Glow devices 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 done through the Lyft app using 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 using a Glow device obtained from someone else or from somewhere other than Lyft, helping to keep riders safe.
End-to-end device control flow (source)
The Glow device pairs with the rider’s mobile device via Bluetooth Low Energy (BLE) and the Lyft driver app serves as a communications gateway, ensuring seamless data transfer between the device and the backend.
The backend service monitors event triggers, such as when a driver approaches a rider’s pickup location, and gives the device the appropriate instructions in real time by sending a command to the app, which forwards it to the device.
The commands can range from simple instructions, such as adjusting the brightness, which the app passes directly to the devices, to complex tasks, such as uploading new animation files to the device, which require the app to perform preprocessing to execute successfully.
To upload new animation files to the device, the mobile app must download the file from the Internet, split it into small parts, and then transfer it to the device.
Lyft engineers handle state management through a “device shadow” service that maintains a real-time mirror image of each device’s state (this is often referred to as a “device twin” or “digital twin”). This service ensures that the device’s current state matches the desired state defined by the backend, facilitating remote management and updates.
Azure IoT device twins (source)
The device status includes important information such as firmware versions, stored files and operating configurations, which the device regularly synchronizes with the backend.
Firmware updates are managed through an over-the-air (OTA) manager service that orchestrates the update process while protecting against potential problems such as power outages or broken updates. These safeguards include backing up old firmware to external storage before an upgrade, rolling back in case of failures, and mounting an immutable recovery firmware image on each device.
