1.7 设备从工厂到用户手中的完整旅程

返回第 1 章：IoT 世界地图

在前面的章节里，我们分别看了 IoT 产品由哪些角色共同提供、能够组织成什么形态，以及设备通过哪些网络和协议连接起来。现在把这些内容放回时间顺序：一台设备怎样从设计图上的产品，变成工厂里可以识别的实物，进入用户的家庭或现场，持续接受控制和维护，最后退出服务。

这条旅程不是设备单方面的移动。设备在工厂里需要身份，在网络中需要凭据，在平台里需要记录，在用户侧需要归属；每一次转交，都会改变“谁可以做什么”和“系统怎样判断它处于什么状态”。设备生命周期管理的核心，不是给设备排一串阶段名称，而是让每个阶段的进入条件、责任主体和退出方式都能够被确认。

1.7.1 先定义产品，再定义设备

一款智能灯在生产以前，已经有一套产品定义：支持哪些电源和灯珠，能够调节什么参数，使用 Wi-Fi、Thread 还是其他连接方式，哪些功能必须在本地运行，哪些功能依赖平台，允许哪些用户控制，以及将来怎样升级固件。

这些决定会同时影响硬件、固件、App 和平台。比如，产品如果承诺断网时仍然可以通过墙壁开关控制，就不能把所有控制逻辑都放在云端；如果产品承诺多年远程升级，就需要预留存储空间、升级分区、回滚机制和安全验证；如果产品允许更换家庭成员，就要把“设备属于谁”和“谁当前可以控制”分开建模。

产品定义还要说明设备与产品型号的关系。十万盏相同型号的灯，通常共享一个产品定义，但每一盏灯都有自己的序列号、密钥、生产批次和运行状态。产品定义回答“这类设备应该具备什么能力”，设备实例回答“这一台设备现在是谁、在哪里、处于什么状态”。

如果这两个层次从一开始就混在一起，后面会出现很多难以修补的问题：同一型号升级时无法区分版本，售后人员找不到具体设备，用户转让设备时误删整类产品，平台也无法判断一条数据究竟来自哪一台实物。

1.7.2 生产把设计变成带身份的实物

设备生产不是把电路板组装完成就结束了。对联网设备来说，工厂还要把软件、身份和初始配置写入实物，让平台将来能够确认“这是谁”。

一个典型的生产流程可能包括：

1. 安装元器件并完成电气、结构和功能测试；
2. 写入引导程序、固件和必要的默认配置；
3. 为设备生成或注入唯一标识、密钥、证书或安全芯片材料；
4. 记录序列号、产品型号、生产批次和测试结果；
5. 将能够用于首次接入的信息交给后续平台或供应链系统；
6. 完成包装、出货和库存状态变更。

这里有一个重要区别：设备身份不等于设备当前归属。 工厂可以证明某台设备是合法生产的，但它还不知道这台设备最终属于哪个家庭、房间或企业租户。生产身份通常要先进入“库存”或“待激活”状态，等设备被交付和配网以后，平台再建立它与用户或组织的关系。

身份材料的保护也不能被当作普通配置处理。如果每台设备使用同一个默认密码，设备一旦泄露，攻击面就会从一台扩大到整批产品；如果工厂日志中长期保留所有生产密钥，供应链环节也可能成为风险来源。生产环节需要记录足够的证据来追溯设备，又要限制能够读取和导出敏感材料的人员与系统。

生产测试同样应该留下可用的结果。测试通过只说明设备在某个时间点、某个工位和某组条件下符合要求，不等于它已经成功接入平台，更不等于用户现场一定能够使用。把“工厂测试通过”“已出货”“已激活”和“当前在线”写成同一个状态，后续排查会很困难。

1.7.3 出厂不等于已经上线

设备离开工厂以后，可能经过仓库、经销商、安装人员和用户多次转手。它可以已经完成生产，却还没有被任何网络发现；也可以已经被打开使用，却没有完成平台绑定。

因此，平台通常需要区分几个互不等价的事实：

• **已生产：**设备通过生产流程，拥有合法的产品身份；
• **已出货：**设备离开制造和库存环节，进入运输或销售流程；
• **已激活：**设备完成首次初始化，平台接受它作为一个可使用的实例；
• **已绑定：**设备与某个用户、家庭、空间或组织建立了归属关系；
• **曾在线：**设备过去至少成功连接过一次；
• **当前在线：**平台最近一次观察到设备仍然保持或恢复连接；
• **可用或可控：**设备在当前条件下能够完成某项业务操作。

这些状态之间没有简单的等号。一台设备可以已激活但暂时离线，可以在线但没有任何用户权限，也可以能够上报温度却无法执行开灯命令。“在线”描述的是连接观察，“可用”描述的是业务能力，二者不能互相替代。

设备从库存进入用户现场时，平台还要处理重复激活、退货、换货和转售。一个用户扫描了包装上的二维码，不代表设备一定已经被他成功控制；一次配网失败后重新尝试，也不应该在平台里产生多个不可区分的设备实例。激活流程需要具备幂等性，并能够告诉用户当前失败发生在身份校验、网络连接、权限确认还是设备执行阶段。

1.7.4 配网让设备获得第一条可用连接

设备刚从工厂出来时，通常不知道用户家庭的 Wi-Fi 密码、现场网关地址或蜂窝连接参数。配网（commissioning 或 provisioning）就是把设备安全地带入它将要工作的网络和产品环境。

家庭智能灯的配网可能由手机通过 Bluetooth Low Energy 把 Wi-Fi 配置传给设备；Thread 设备可能需要加入局部网格并由边界路由器转发；蜂窝终端则可能通过物联网卡和运营商网络完成注册。配网方式不同，但都要回答类似的问题：

• 用户正在配置的是哪一台设备？
• 设备是否确实属于这个产品和这次交易？
• 配置信息怎样传给设备，传输过程中谁能看到？
• 设备能否验证自己加入的是正确网络？
• 配网失败后能否重试、回退或恢复出厂状态？

配网也不一定等于用户绑定。安装人员可以先把设备接入网络，再由住户稍后完成家庭绑定；在酒店项目中，设备可能先批量接入项目网络，最后由物业或运维组织分配到楼层和房间。把“网络归属”和“业务归属”分开，才能支持这些交付方式。

配网成功后，设备通常需要保存网络凭据、平台地址、证书或令牌。它们应该能够更新和撤销，否则更换路由器、供应商或平台时，设备只能被迫报废。设备端还要考虑断电、重复配网、网络切换和恢复出厂等情况，不能只为第一次成功路径设计。

1.7.5 平台接入与用户绑定是两次不同的确认

设备接入平台，首先证明的是“这台设备有资格和平台通信”。用户绑定则进一步证明“这个人或组织可以把它纳入自己的产品关系”。两者可能在同一个引导流程里完成，但语义不同。

平台接入通常涉及设备身份认证、产品型号校验、固件版本、协议能力和连接状态。平台需要知道设备是否属于允许接入的产品，是否使用了有效凭据，是否被标记为丢失、退役或已经转移。接入成功后，平台可以接收设备上报，也可以向它发送受授权的指令。

用户绑定涉及家庭、空间、组织、角色和权限。例如，家庭成员可以控制客厅的灯，维修人员可以查看设备诊断信息，但不能读取家庭的其他数据；酒店的工程账号可以管理整层设备，住客只能控制当前房间。绑定关系不是设备身份的一部分，而是业务系统对使用范围的记录。

设备转移时，这个区别尤为重要。二手设备可能仍然是同一个合法生产实例，但旧用户的控制权限应该被撤销，新用户需要重新完成绑定。若平台把用户绑定写死在设备身份里，转让、维修和批量部署都会变得困难；若完全不记录归属，又无法阻止旧用户继续控制设备。

因此，设备接入、用户绑定和权限授予应当留下不同的记录。它们可能先后发生，也可能由不同角色完成，但不能用一条“添加成功”日志替代全部证据。

1.7.6 日常运行是不断变化的状态流

设备进入家庭或现场后，生命周期并没有进入“完成”状态。它会持续产生状态、事件和数据，也会持续接收命令、配置和权限变化。

以智能灯为例，设备可能上报当前亮度、开关状态、固件版本、信号强度和故障码；平台可能向它发送开灯、调光、修改场景或更新配置的命令。用户看到的是一个按钮，系统实际需要处理的是命令是否被接受、是否送达、是否执行，以及设备执行后状态有没有回报。

传感器的上报也有自己的语义。一次温度读数可以是定时采样、阈值变化、设备重启后的当前快照，或者平台请求的即时读取。平台如果只把所有信息都保存成一串“最新值”，就会丢失数据产生的原因和时间关系；如果只保存原始事件，又可能无法快速回答用户当前看到的状态。

运行阶段还会出现离线、重复、乱序和局部成功：设备可能断网后补发数据，命令可能因超时被用户再次点击，网关可能重复转发消息，传感器和平台的时钟也可能不同。产品需要明确哪些数据允许覆盖，哪些事件必须保留，哪些命令可以重试，哪些动作必须返回确定结果。

这也是为什么设备生命周期不能只用“在线/离线”两个标签描述。平台至少需要区分连接观察、设备报告的状态、平台推断的可用性，以及最近一次控制操作的结果。它们都可能指向同一台设备，却来自不同证据。

1.7.7 维护升级与设备继续工作

联网设备售出以后，固件和配置仍然可能需要变化。安全漏洞需要修复，网络参数需要调整，设备能力需要增加，平台接口也可能随着产品演进而更新。

OTA（Over-the-Air）把软件更新送到现场设备，但“把文件下载下来”只是其中一小步。完整的升级过程还要处理：

• 设备是否确实属于这次升级的目标范围；
• 固件包是否来自可信来源，是否完整且未被篡改；
• 设备是否有足够电量、存储空间和网络条件；
• 升级中断后能否继续、回退或进入安全恢复模式；
• 新固件是否与硬件版本、产品能力和平台接口兼容；
• 升级后怎样确认设备重新上线并恢复关键功能。

批量升级还需要分批、暂停和回滚。先让少量设备接收新版本，可以观察失败率和异常；直接让所有设备同时更新，虽然节省调度时间，却可能把单个缺陷扩大成整批服务故障。升级策略还应考虑设备是否正在执行关键任务，电池是否即将耗尽，现场是否允许短暂中断。

维护不只包括 OTA。设备可能需要修改配置、更新证书、替换密钥、重新配网、诊断日志、远程重启或更换硬件。不同操作的风险不同，审批和权限也不应完全相同。能读取温度的客服账号，不一定有资格触发固件升级；能升级固件的工程账号，也不一定能查看用户的全部业务数据。

设备能够远程维护，前提是产品在设计阶段就保留了维护入口、身份验证和失败后的恢复路径。 设备售出后再临时补这些能力，往往需要现场回收或承担无法修复的风险。

1.7.8 转移、停用与淘汰也属于生命周期

设备并不总是由最初购买者一直使用。家庭成员可能变化，房屋可能转手，酒店房间可能改造，企业项目可能更换承包商，设备也可能因为故障或技术限制被替换。

转移需要同时处理几件事：撤销旧用户的权限，建立新用户或组织的关系，保留必要的维修和合规记录，清理不应继续保留的个人数据，并确认设备端不再接受旧凭据。只在 App 中删除一条设备记录，并不代表设备已经完成安全转移；旧账号、共享令牌、网关缓存和自动化规则都可能继续产生影响。

停用也有不同原因。设备可能暂时离线，等待维修；可能被标记为丢失，禁止重新接入；可能已经永久退役，平台不再接受它的业务消息；也可能只是从某个家庭移除，但仍准备进入另一个项目。平台应当区分这些状态，因为它们对应的恢复、审计和数据保留策略不同。

淘汰时还要处理设备和数据的两条路径。设备可能被回收、返修、转售或报废；历史数据可能需要继续保留一段时间，也可能应当按隐私和合同要求删除。产品如果没有规定清除凭据、撤销证书和处理本地数据的方法，设备离开现场以后仍然可能保留访问系统的能力。

长期运行的 IoT 产品还要面对供应商和平台变化。平台服务退役、证书体系调整、网络制式变化或关键部件停产，都可能迫使企业提前迁移或替换设备。生命周期设计的目标不是保证设备永远不变，而是让企业知道什么时候该升级、转移、替换或退出，以及每一步怎样留下可核查的结果。

1.7.9 用状态与证据描述完整旅程

把设备旅程压缩成一条线很方便，但工程系统更需要记录每次状态变化的依据。可以用下面的简化状态帮助建立共同语言：

已生产
  → 已出货
  → 待激活
  → 已接入
  → 已绑定
  → 运行中
  → 维护中 / 暂时离线
  → 已转移 / 已停用 / 已退役

这不是唯一的状态机，也不是每台设备都必须按同一顺序经过所有状态。设备可能在激活前退货，在绑定后转移，也可能从维护中恢复运行。重要的是，每次转换都要说明触发事件、执行者、时间、目标和结果。

例如，“已绑定”至少需要知道绑定了哪个家庭或组织、由谁完成、设备是否同时撤销了旧绑定；“升级成功”至少需要知道目标版本、升级批次、设备回报和验证时间；“已退役”则需要知道设备凭据是否撤销、平台是否拒绝后续消息、相关数据如何处理。

这些记录不只是为了发生故障后查日志，也会影响用户体验、售后流程、库存管理、计费、合规和安全。平台如果只保存当前状态，无法回答设备是怎样走到这里的；如果只保存流水而没有当前投影，又很难快速判断设备现在能不能被控制。

因此，设备生命周期需要同时维护两种视角：一是当前状态，方便系统和用户使用；二是状态变化的证据，方便追溯、诊断和承担责任。下一节将把这些对象和状态进一步整理成设备、产品、平台与生态之间的关系。