PMS Setup¶

This flow covers defining the hardware and customer catalog in the Product Management System before manufacturing begins. The catalog is the prerequisite for every subsequent manufacturing and provisioning operation: a device cannot be provisioned until its part and customer exist in the system.

Involves: PMS, Administration, ToloMEO CLI

Concepts¶

The PMS organizes manufacturing data around a small hierarchy of entities. Understanding how they relate makes it easier to model your own product line.

Parts represent a class of hardware: a specific board revision, BOM version, and configuration. A part is the template from which individual device instances are created. Parts can be grouped into part families for convenience when you produce multiple related hardware variants.

Models link a part to a firmware profile. Assigning a model to a part tells the platform which firmware release a device of that type should receive, enabling OTA targeting and version tracking. Models are managed in the cloud IoT layer and referenced from the PMS by ID.

Customers represent the organizations that will own and operate devices. Each customer maps to a platform tenant, which determines data isolation and access control. A device is always provisioned to a specific customer.

Step 1 - Create customers¶

Before any device can be provisioned it must be associated with a customer. Create a customer record for each organization you will be supplying devices to:

tlm-cli admin customers create

The command opens an interactive form. The customer code is the short identifier used in provisioning commands. The tenant_id is populated by the platform once the customer is created and is what links the customer record to the platform identity layer.

For the full reference on customer management see the tlm-cli documentation.

Step 2 - Define parts¶

A part captures the hardware identity of a device class. Define one part per distinct hardware configuration:

tlm-cli pms parts create

Key fields when defining a part:

Sub-parts can be declared on a part to model composite assemblies where a finished product consists of multiple distinct boards or modules, each with their own serial number and lifecycle.

Step 3 - Assign a model to the part¶

Once a firmware model exists in the platform, link it to the part so that devices of this type are automatically associated with the correct firmware profile:

tlm-cli pms parts set-model <part-number> --model <model-id>

This association drives OTA targeting: when a new firmware release is activated on a model, all provisioned devices whose part points to that model become eligible for the update. See the OTA Release flow for how firmware activation works.

Step 4 - Register devices¶

Individual device instances are added to the PMS at provisioning time, not as a separate catalog step. The PMS device record is created automatically when tlm-cli pms provisioning provision runs. See the Device Provisioning flow for the full process.

If you need to track devices in a batch before provisioning, devices can also be created directly:

tlm-cli pms devices create

This is useful for recording production data (MAC addresses, hardware UIDs, production dates) at manufacturing time, before the device goes through the provisioning step that ties it to the platform identity layer.

Tracking lifecycle events¶

The PMS maintains a permanent event log per device. Events are the audit trail of a device's physical lifecycle and can be attached at any point after the device record exists.

Public events are visible to the customer and cover external activities:

Internal events are operator-only and cover manufacturing activities such as production tests and manufacturing milestones.

# Create a public event for a device
tlm-cli pms events create public --serial <SN> --customer <code>

# Create an internal event
tlm-cli pms events create internal --serial <SN> --customer <code>

Events accumulate over the device's life and are accessible from the device detail view in the PMS and via the CLI. They are never deleted, giving a complete traceable history from manufacturing through field deployment and eventual decommission.