“If all you have is a hammer, everything looks like a nail”
The saying, “If all you have is a hammer, everything looks like a nail,” also applies to the complexities of Linux device fleet management. Like many challenges, the architecture of any device or server consists of layers, typically starting with the operating system (OS), followed by various applications, and topped with device-specific customizations. This is simple to handle for small fleets, but difficult for millions of devices. In addition, you probably want the IoT devices’ individual settings connected to some of your backend, ERP or business systems. Let’s explore this further:
Consider an industrial device fleet tasked with collecting Modbus data. Each device’s architecture can be visualized as a pyramid, with the following layers from bottom to top:
- A consistent Linux OS across the fleet,
- A Modbus application common to 80% of the devices, with the remaining 20% utilizing a BACNET application,
- A general configuration for the Modbus application, such as a universal polling interval,
- A device-specific configuration, detailing the Modbus data to be sent to the cloud from a specific IP and requiring the reading of a particular Modbus coil.
Managing these layers presents a spectrum of options:
Full A/B OTA Image Update
Ideal for fleet-wide Linux updates or significant application changes, this method struggles with device individualization, especially when managing diverse applications like Modbus and BACNET across different fleet segments. This is the most commonly used OTA for millions of devices but lacking flexibility.
Package, Binary, or File Updates
Suited for application, script, or configuration updates, this method offers flexibility for fleet segments but falls short in achieving device-specific customization.
Key-Value Templating
This approach enhances individualization by:
- Allowing common configurations while enabling unique per device customizations through key-value pairs,
- Facilitating device or group-specific customizations via an ERP backend or database integration,
- Automatically rebuilding configuration files upon key-value changes or configuration updates, triggering application or script restarts for configuration reloading and operating with new parameters.
This methodology enables nuanced control, from fleet-wide changes down to individual device adjustments. With our Modbus example, this translates to:
- Device-specific Modbus IP and coil settings,
- Group or fleet-wide configurations, such as polling rates,
- Application updates for devices interfacing with Modbus, excluding those for BACNET,
- Linux OS updates for security and stability.
qbee.io has efficient tools to operate on all these levels on millions of IoT devices. Applying this approach to the described problem on different layers yields the following setup:
- Deploying new Linux versions via A/B OTA updates,
- Updating the Modbus forwarder application across relevant devices,
- Adjusting polling rates for device groups through new configuration distributions,
- Modifying individual device settings through key-value pair updates.
This can be easily visualized as a pyramid with 4 layers from bottom to apex. Furthermore, the overall over-the-air update risk is reduced as changes only apply to the minimum amount of devices that need to be impacted. This improves system robustness and stability a lot.
1. Base Layer: A/B OTA Updates for the Linux OS
At the pyramid’s base, we have the A/B Over-The-Air (OTA) updates, used for rolling out new versions of the Linux operating system across the entire fleet. This foundational layer affects every device, ensuring a secure and up-to-date operating environment. These updates are less frequent due to their broad impact and the necessity for thorough testing. These also have the highest operational risk and often high bandwidth demands.
2. Second Layer: Modbus Forwarder Version Updates
Moving up, the next layer consists of updates to the Modbus forwarder version, applied through package installations across all devices requiring this specific software. This layer offers a bit more specificity compared to the base, targeting only devices that use the Modbus forwarder. Such updates can occur more frequently than full OS updates, addressing improvements or patches specific to the Modbus application. Again, the risk is isolated to devices that really are in scope and here only a single application or script is updated reducing overall risk.
3. Third Layer: Group-Specific Polling Rate Adjustments
The third tier introduces the ability to adjust polling rates for groups of devices. This layer caters to the operational nuances of different device clusters within the fleet, distributing new configurations with updated polling rates. Individual device configurations, including IP and coil values, are templated, allowing each device within the group to generate a customized configuration file based on key-value pairs. This level of the pyramid affects smaller segments of the fleet, enabling tailored performance adjustments without impacting the entire network.
4. Apex: Individual Device Configuration Updates
At the pyramid’s apex, the most granular level of updates occurs. Here, individual device configurations can be adjusted, such as changing the IP address or modifying which Modbus coil is read. These updates are made through specific key-value pair adjustments, accessible via a user interface (UI) or a REST-API, affecting only a single device at a time. This top layer represents the pinnacle of customization and flexibility, allowing for precise, risk-minimized updates that enhance uptime and stability for specific devices without broader fleet implications. So if one device needs to be changed it is an operation that only impacts one device. This is the lowest risk you can achieve.
Conclusion: Individualize Millions of IoT Devices directly from your ERP System
This pyramid structure illustrates the layered approach to device management, where the breadth of impact decreases as you ascend, thereby reducing risk and increasing the ease of managing updates and configurations. By leveraging qbee’s key-value templating and REST-API integration, standard packages like the Modbus Forwarder can be easily managed and individualized, embodying qbee’s unique value proposition. This method, honed through extensive IoT experience and discussions with operation managers, addresses the dual challenges of keeping large fleets updated while ensuring device individualization, marking an industry-leading approach.
