Device Lifecycle¶
This page traces the complete journey of a device on the ToloMEO platform, from the first hardware definition through years of field operation to eventual retirement. Each stage links to the dedicated flow that covers it in detail.
Involves: All platform sections.
Defining the product¶
Before a single device is manufactured, the platform needs to know what it is. A part is created in PMS to represent the hardware variant, carrying the part number, PCB revision, BOM version, and a reference to the firmware model that will drive OTA delivery throughout its life. Customers are defined in the Admin module so that devices can be assigned to the organizations that will operate them.
This catalog work happens once per product line, not once per device. It is the foundation everything else builds on.
See: PMS Setup
Building the firmware¶
With the hardware defined, the production firmware is built from the meta-tolomeo Yocto layer. The production distribution ships with secure boot, a read-only root filesystem, kernel hardening, and audit tooling enabled by default. Cryptographic keys for FIT image signing and SWUpdate package signing are generated once and kept offline; from that point every production build is signed automatically.
The build produces the firmware image and, as a side effect, a CycloneDX SBOM and VEX file capturing every software component in the image. These artifacts travel with the firmware throughout its life.
See: BSP and Application Development, Hardening and Secure Boot
Manufacturing and provisioning¶
At the manufacturing line, two things happen to each physical device.
First, the firmware is flashed onto the hardware using uuu for the initial programming.
This establishes the software baseline the device will ship with.
Second, the device is provisioned: the serial number is registered in PMS and the IoT layer, generating a unique platform identity and a configuration file containing the credentials the on-device agent needs to authenticate on first boot. That configuration file is injected into the device storage as part of the same manufacturing step. Without it the device has no way to reach the platform.
Provisioning can be run individually or scripted across an entire production batch, making it suitable for both low-volume and high-volume manufacturing lines.
See: Device Provisioning
First boot and claiming¶
When the device powers on in the field for the first time, the on-device agent reads its configuration, authenticates with the platform using the init key, and completes registration. From that moment the device is live.
An operator then claims the device into Fleet Manager, giving it a human-readable name and making it visible in the operational fleet alongside its connectivity state, firmware version, and first telemetry readings. Bulk claiming handles entire batches in a single operation for larger deployments.
Tracking vulnerabilities¶
Once the firmware version is in the field, its SBOM is uploaded to the Cybersecurity module. The platform matches every component against CVE databases and surfaces findings by severity. Alarms are configured so that newly published CVEs matching any tracked component generate an immediate notification, without requiring anyone to manually recheck.
Triage is performed on the findings, suppressing false positives and recording the exploitability assessment for components that are not reachable in the specific build. When the analysis is complete, a security report is generated as a formal artifact that can be shared with customers or auditors.
See: SBOM Tracking
Operation¶
Day-to-day operation revolves around Fleet Manager: device connectivity, telemetry charts, system metrics, and the command control panel for sending instructions to individual devices. Significant real-world events - deliveries, returns, field interventions - are recorded against the device in PMS as public or internal events, building the audit trail that follows the device throughout its life.
If IoT and telemetry services have been developed using py-tolomeo, their data streams are visible alongside the built-in system metrics. Custom applications can also consume the same data and control surface through the ToloMEO REST API.
See: IoT and Telemetry, Third-Party Cloud Integration
Firmware updates¶
When a new firmware version is ready, it is registered against the model in PMS and activated. Devices in the fleet are notified and work through the OTA state machine: downloading the signed package, verifying its signature, writing it to the inactive partition, and rebooting into the new version. The entire process can be monitored per-device in Fleet Manager and automated end-to-end via the API.
After a successful rollout, the new build's SBOM is uploaded to Cybersecurity so vulnerability tracking continues without interruption at the new version.
See: OTA Release, SBOM Tracking
End of life¶
When a device is retired, a disposal event is recorded in PMS before any records are removed, preserving the audit trail. The device is then unprovisioned, permanently removing its platform identity. If that firmware version is no longer running on any remaining device in the fleet, its release is removed from the model in PMS and its tracked version is retired from Cybersecurity, keeping the platform free of records that no longer correspond to anything in the field.