定义
Device Lifecycle（设备生命周期）管理设备从生产、激活、运行、维护到报废各阶段状态。支持自定义 State Machine（状态机）、State Transition（状态流转）、Automation Policy（自动化策略），与 Asset Management、ERP、Work Order 集成。
典型状态与流转
常见状态包括：Inactive（未激活）—设备已注册但未首次连接；Online/Offline（在线/离线）—运行中；In Maintenance（维护中）—处于维护窗口或工单处置；Decommissioned（已报废）—设备退役。通过 State Machine 定义状态流转规则，如「离线超过 N 天自动标记为异常」「报废设备禁止 OTA」等，实现生命周期自动化管理。
与业务系统集成
设备生命周期与 Asset Management 资产台账关联，采购入库对应 Inactive，部署上线对应 Online，报废对应 Decommissioned。可对接 ERP 同步设备主数据，对接 Work Order 工单系统，在维护工单创建时自动将设备置为 In Maintenance，完成后恢复。
自动化策略
支持基于规则的生命周期策略：如设备长时间离线自动归档、批量设备迁移时批量更新状态、OTA 升级失败设备自动标记待维护。生命周期事件可触发 Webhook、告警或下游系统同步，支撑运维决策与合规审计。
状态流转允许做什么、禁止做什么
设备生命周期的技术含义，是用一组有限状态描述这台终端处在登记、待装、在运、维修还是退役，并且每个状态明确允许哪些操作。在运可以接收升级和远程控制，维修中可以暂停普通控制、保留诊断，退役后不应再接收升级，也不应再颁发有效会话。状态不是连接状态的别名：离线的在运设备仍然在运，在线的退役设备如果还能连上，说明退役没有落实到接入控制。流转要有方向，例如不能从退役直接回到在运而不经过重新启用的检查。
使用状态机的条件，是团队已经同意每个状态的入口和出口，并且会改变设备命运的动作都会查询当前状态。只有界面上的一个下拉框、后面的升级任务不检查状态，生命周期就只是标签。自动流转必须写清触发和是否可撤销，例如长时间未激活可以归档，但不能未经确认就报废。与设备凭证的关系是：退役要让凭证失效，重新启用要重新签发或明确恢复，不能只改一个状态字段。与空中升级的关系是：任务在执行前再次核对状态，创建任务时在运、执行时已退役的设备应被跳过并留下原因。
退役之后凭证仍能连上
常见错误是在资产系统里做了报废，设备平台的状态仍是在运，升级任务继续覆盖这台设备。反过来，平台点了退役，凭证没有吊销，设备换一张卡又能连上，数据继续写入已经封存的档案。另一种是用离线天数自动退役，把季节性停用的设备永久退出，恢复时没有重新启用步骤，只能当新设备登记，历史因此断开。维修状态忘记退回，也会让设备长期收不到业务控制，现场却以为通信坏了。
并发改状态时，后写覆盖先写，若不记录谁在何时从哪个状态改到哪个状态，就无法解释一台设备为什么跳过了维修。批量导入若把空状态写成默认在运，仓库里的未安装设备会进入升级范围。状态名字可以按行业定制，但“能否升级、能否连接、是否还计为在运资产”这几项语义必须在定义里写死。只改显示名称、不改允许的动作，新名称会让人误以为策略已经变了。
维修状态忘记退回在运
设备进入维修之后，普通控制可以暂停，诊断和必要的参数读取仍应允许。维修结束却没有人把状态退回，设备会长期拒绝业务指令，现场只看到控制失败，以为是通信故障。自动规则若用离线天数直接退役，季节性停用的设备会被永久移出，恢复时没有重新启用的检查，只能当成新设备登记，原有履历就此断开。退役的动作必须同时拒绝新会话并停用凭证。只改一个显示状态，设备换一条链路又能上报，档案却已经按报废封存，新数据会写进不该再更新的记录。
批量导入最容易把空着的状态写成默认在运，仓库中的未安装设备因此进入升级范围。状态可以从行业用语上改名，但能否升级、能否连接、是否仍算在运资产，这几项必须留在定义里，不能随显示名称一起含糊过去。并发修改时要留下从哪个状态到哪个状态、由谁或哪条规则触发。没有这段轨迹，就无法解释设备为什么跳过了维修直接到了退役。创建升级任务时在运、执行前已退役的，应跳过并记录原因，而不是沿用任务创建时的旧判断。