Definition
Device Lifecycle management covers the status of a device through all stages from production, activation, operation, maintenance to decommissioning. It supports custom State Machine, State Transition, Automation Policy, and integrates with Asset Management, ERP, Work Order.
Typical States and Transitions
Common states include: Inactive - the device is registered but has not connected for the first time; Online/Offline - operational; In Maintenance - within a maintenance window or work order handling; Decommissioned - the device is retired. The State Machine is used to define state transition rules, such as "Automatically mark as abnormal if offline for N days" or "Prevent OTA for decommissioned devices," enabling automated lifecycle management.
Integration with business systems
The device lifecycle is linked with the Asset Management asset ledger: purchasing and warehousing corresponds to Inactive, deployment and going online corresponds to Online, and scrapping corresponds to Decommissioned. It can interface with ERP to synchronize device master data, and with the Work Order system, automatically setting the device to In Maintenance when a maintenance work order is created and restoring it upon completion.
Automation Strategy
Supports rule-based lifecycle strategies: for example, automatically archiving devices long offline, batch updating statuses when migrating multiple devices, automatically marking devices as pending maintenance if OTA upgrade fails. Lifecycle events can trigger Webhooks, alerts, or downstream system synchronization to support operation decisions and compliance audits.
What a state transition allows and forbids
The device lifecycle means using a limited set of states to describe whether a terminal is registered, waiting to be installed, in service, in repair, or retired, and stating for each state which operations are allowed. In service may receive upgrades and remote control. In repair, ordinary control may be paused while diagnosis is kept. After retirement, the device should not receive upgrades, and it should not be issued a valid session. State is not another name for connection status. An offline device that is in service is still in service. A retired device that is online and can still connect means retirement was not applied to access control. Transitions have a direction. A device cannot go from retired straight back to in service without the checks that come with enabling it again.
A state machine is usable when the team has already agreed the entry and exit of each state, and when every action that changes a device’s fate checks the current state. If there is only a dropdown on the screen, and the upgrade job behind it does not check state, the lifecycle is only a label. An automatic transition must state its trigger and whether it can be undone. For example, a long time without activation may archive a device, but it must not dispose of the device without confirmation. Relative to device credentials, retirement must make the credentials invalid, and enabling again must reissue them or restore them explicitly. Changing a state field is not enough. Relative to OTA, the job checks state again before it runs. A device that was in service when the job was created and retired when it runs should be skipped, and the reason kept.
When credentials can still connect after retirement
A common mistake is to dispose of the device in the asset system while the device platform still shows in service, so upgrade jobs keep covering it. The reverse is marking retired on the platform without revoking credentials. The device connects again with a different card, and data keeps being written into a record that was supposed to be sealed. Another mistake is automatic retirement from days offline, which permanently removes a device stopped for the season. Recovery has no step to enable it again, so it can only be registered as a new device, and the history breaks. Forgetting to leave the repair state also keeps the device from receiving business control for a long time, while the site thinks communication is broken.
When state is changed concurrently, the later write covers the earlier one. If there is no record of who changed it, when, and from which state to which state, there is no way to explain why a device skipped repair. A bulk import that writes an empty state as in service by default puts devices still in the warehouse, and not yet installed, into the upgrade scope. State names may be customized by industry, but whether upgrade is allowed, whether connection is allowed, and whether it still counts as an in-service asset must be fixed in the definition. Changing only the display name, and not the allowed actions, makes the new name look as if the policy has already changed.
Forgetting to return a device from repair to in service
After a device enters repair, ordinary control may be paused. Diagnosis and necessary parameter reads should still be allowed. If nobody returns the state when repair ends, the device refuses business commands for a long time. The site only sees control failing and thinks it is a communication fault. If an automatic rule retires directly from days offline, a device stopped for the season is removed permanently. Recovery has no check for enabling it again, so it can only be registered as a new device, and the original history breaks there. The act of retirement must refuse new sessions and disable credentials at the same time. Changing only a display state lets the device report again on another link, while the record has already been sealed as disposed. New data is written into a record that should no longer be updated.
A bulk import most easily writes an empty state as in service by default, so devices in the warehouse that are not yet installed enter the upgrade scope. A state may be renamed in the language of an industry, but whether upgrade is allowed, whether connection is allowed, and whether it still counts as an in-service asset must stay in the definition. They cannot become vague together with the display name. Concurrent changes should leave which state it came from, which state it went to, and who or which rule triggered it. Without that trail, there is no way to explain why a device skipped repair and went straight to retired. A device that was in service when an upgrade job was created, and retired before the job runs, should be skipped and the reason recorded, rather than keeping the old judgment from when the job was created.