设备生命周期管理

设备生命周期管理（Device Lifecycle Management, DLM）是围绕一台物理设备从制造到退役的全过程管理方法，用统一身份、状态机、事件记录和策略规则维护设备在平台中的真实状态。

它的目标不是简单保存一张设备列表，而是让制造、销售、激活、运行、升级、售后和报废都围绕同一个设备事实流转。

核心问题

设备一旦离开产线，就会在多个系统里出现：制造系统知道批次和烧录结果，IoT 平台知道连接凭据，业务系统知道 owner，远控系统知道在线和告警，售后系统知道 RMA，OTA 系统知道版本和升级结果。

如果这些系统各自维护状态，就会出现典型问题：

• 设备已经换机，但旧设备仍然可以联网。
• 用户解绑了设备，但售后系统仍认为它属于原客户。
• OTA 失败后设备被标记为在线可升级，实际已经需要人工维修。
• 仓库收到返修机，但平台生命周期仍显示 active。
• 同一个 SN 和 Device ID 的映射关系在不同系统中不一致。

设备生命周期管理解决的是“这台设备现在到底处于什么状态，以及谁有权让它进入下一个状态”。

核心对象

对象	作用	工程关注点
physical device	真实硬件实体	整机、主板、模组和配件可能有不同序列号
SN 与 Device ID	连接实物身份和平台身份	SN 偏出厂追溯，Device ID 偏平台账号
owner / tenant	当前用户、组织或客户	绑定、转移、解绑和权限继承
lifecycle_state	生命周期主状态	manufactured、allocated、activated、frozen、under_repair、replaced、retired 等
binding_state	用户或组织绑定状态	unclaimed、claimed、transferred、revoked
runtime_state	运行状态	online、offline、degraded、blocked
firmware / artifact	软件和固件版本	与 OTA 准入、回滚和兼容性相关
entitlement	服务权益	保修、合同、召回、付费维修和地区策略
service case	售后或异常处置记录	RMA、维修、换机、召回和报废
audit event	状态变化证据	谁在什么时间基于什么原因改变了状态

核心机制

设备生命周期管理通常用事件驱动状态机实现。一个最小模型可以写成：

next_state = transition(current_state, event, guard)

• current_state 是设备当前生命周期状态，例如 activated 或 under_repair。
• event 是触发状态变化的事实，例如 device.activated、repair.authorization_issued、ota.failed。
• guard 是允许转移的前置条件，例如“申请人是当前 owner”“设备没有被召回锁定”“固件版本允许升级”。
• next_state 是满足规则后得到的新状态。

这里的 transition 不是任意赋值。它必须受状态机规则约束：例如 manufactured -> allocated -> activated 是常见路径，但 retired -> activated 通常不应直接发生；如果要重新启用退役设备，需要额外审批和检测事件。

一个简化状态链如下：

manufactured
  -> allocated
  -> activated
  -> active
  -> under_repair
  -> active | replaced | retired

对应流程可以拆成：

1. 制造建档：产线生成 SN、批次、硬件版本和烧录结果。
2. 平台注册：设备管理服务分配或绑定 Device ID、凭据和产品模型。
3. 销售 / 分配：设备归属到客户、渠道、区域或库存位置。
4. 激活 / 绑定：用户或组织完成持有证明，建立 owner 关系。
5. 运行监控：平台持续接收在线状态、告警、版本和健康状态。
6. 升级维护：通过 OTA、配置下发或现场维护改变设备软件状态。
7. 售后处置：故障、召回、换机或返修通过 RMA 等流程改变生命周期。
8. 退役闭环：设备被报废、回收、销毁或永久禁止接入。

工程上通常会把生命周期主状态、运行状态、绑定状态分开，而不是塞进一个大字段。例如：

{
  "device_id": "dev_8f31",
  "sn": "ACT-2026-00042",
  "lifecycle_state": "under_repair",
  "binding_state": "claimed",
  "runtime_state": "offline",
  "firmware_artifact": "robot-os-2026.05.1",
  "service_case_id": "RMA-20260528-0007"
}

这样设计的原因是：设备处于返修中并不自动说明 owner 关系不存在；设备离线也不等于退役；OTA 失败也不一定等于硬件损坏。不同状态维度分开，才能让运营、售后和自动化策略更精确。

工程用途

• 统一设备台账：把制造、销售、客户、版本、运行和售后状态放到同一事实模型下。
• 设备准入控制：决定设备是否允许联网、远控、证书续期、OTA 或使用高级功能。
• 售后闭环：返修、换机、退款和报废都能反向更新平台状态。
• 风险控制：识别串货、重复激活、异常换机、旧设备继续使用和批次缺陷。
• 运维分析：按型号、批次、地区、固件版本和生命周期状态统计故障率。

在 IoT 或机器人平台中，设备生命周期管理常和 OTA、证书、远程控制、用户绑定、库存和售后系统一起构成设备运营中枢。

边界与常见坑

• 设备生命周期管理不是 PLM：PLM 管产品设计和物料版本，设备生命周期管理管每一台已生产设备的运行和处置状态。
• 生命周期状态不是在线状态：offline 是运行观测结果，retired 是业务处置结果，二者不能互相替代。
• SN 和 Device ID 不要无条件合并：实物换主板、重置、重新注册、换机都会让身份映射变复杂。
• 状态变化必须事件化：直接改数据库字段而没有事件、操作者和原因，会让售后追溯和审计失效。
• 投影视图不能反向定义真值：远控、客服或仓库视图可以消费生命周期事实，但不应各自创造互相冲突的主状态。
• 退役要阻断能力：设备被 replaced 或 retired 后，证书、远控、OTA 和用户权益都需要同步收口。

相关术语

• RMA
• SN 与 Device ID
• IoT
• OTA