Device Provisioning¶
Provisioning is the manufacturing-time process that gives a physical device its platform identity and prepares it for field deployment. It has two sides: a server-side registration that creates the device record in the platform, and a device-side step that installs the software image and the configuration the on-board agent needs to connect.
Involves: PMS, Administration, Fleet Manager, ToloMEO CLI
Prerequisites¶
Before a device can be provisioned the following must exist in the platform:
- A customer record with a tenant ID (see PMS Setup)
- A part definition that matches the hardware being provisioned
- A model assigned to that part (for firmware targeting)
Step 1 - Generate the device credentials¶
The first step happens on the operator's workstation or build server, not on the device itself. Running the provisioning command against a serial number does two things simultaneously:
- Registers the device in PMS and the IoT layer, associating it with the customer tenant and creating its platform identity.
- Generates an
agent.envconfiguration file containing the credentials the on-device agent needs to authenticate with the platform on first boot.
The generated file is written locally to <serial-number>/agent.env. It contains a
one-time init key tied to that specific device's platform identity. Until this file is
placed on the device, the device has no way to connect to the platform.
If the file is lost after provisioning it can be reissued without re-provisioning:
For the full command reference and dry-run options see the tlm-cli documentation.
Step 2 - Flash software and inject configuration¶
With the credentials in hand, the device is ready to be programmed. This step puts two things onto the hardware:
- The firmware image: the production software built from meta-tolomeo following the BSP and Application Development and Hardening and Secure Boot flows, flashed using uuu (NXP Universal Update Utility) for initial programming.
- The agent configuration: the
agent.envfile generated in Step 1, placed in the location the on-device agent reads on boot.
The meta-tolomeo layer includes the tooling and image targets for the manufacturing flash procedure. Refer to the meta-tolomeo documentation for the specific uuu commands, image targets, and configuration file placement path.
On first boot the agent reads the configuration, uses the init key to authenticate with the platform, and completes device registration. From that point the device is live and visible in the platform.
Step 3 - Claim into Fleet Manager¶
A provisioned device is visible in PMS but not yet in the operational fleet. Claiming transfers it into Fleet Manager, where it becomes monitorable and manageable:
The device appears in Fleet Manager once it has booted and established connectivity. Its firmware version, connectivity state, and last-seen timestamp are then tracked automatically.
For large deployments, bulk claiming computes the difference between PMS and Fleet Manager and claims all provisioned but unclaimed devices in one operation:
Automating provisioning¶
The provisioning command is designed for scripted use. All commands support --dry-run
for validation and --yes to suppress interactive prompts, making them suitable for
integration into a manufacturing line script or CI/CD pipeline:
for sn in $(cat serials.txt); do
tlm-cli pms provisioning provision "$sn" --customer ACME --output-dir /opt/configs
done
The underlying provisioning API is a bulk endpoint and also accessible directly from the tlm-cli Python library for tighter integration with custom manufacturing tooling.
Unprovisioning¶
To permanently remove a device from the platform, follow the End-of-Life and Decommissioning flow. It covers recording the disposal event before unprovisioning and cleaning up associated firmware and CVE tracking records.
Warning
Unprovisioning is permanent. The device record and its platform identity are deleted and cannot be restored.