当软件遇上硬件
内容提要
大型零售物联网改造中，约80万电池传感器部署于3000家门店。团队发现软件工程原则仍适用，但默认实践需调整：建立物理实验室与虚拟设备模拟器，将硬件纳入开发环境；为设备内置诊断与远程接口；针对间歇连接和能耗设计；固件升级兼顾恢复与分批发布；建设车队级监控。核心是快速反馈、自动化等原则不变，但需通过实验探索更合理的默认做法。
延伸解读
硬件开发环境：从软件工具到物理实验室
文章指出，传统软件开发环境由软件工具构成，但物联网项目需要物理设备。团队建立了包含真实传感器、线束和学习套件的物联网实验室，以及连接新网络的传感器农场。这些设施让工程师能观察设备通信、休眠、唤醒和断连行为，将物理行为纳入开发和测试。这改变了开发流程，使TDD、自动化等实践需结合硬件在环，快速反馈原则不变，但实现方式需调整。
设备自诊断与远程接口：可观测性的延伸
对于无法物理接触的设备，传统日志和追踪不适用。团队在固件中内置诊断功能，如固件版本、健康状态、最后通信时间、网络状态和升级状态，并提供本地NFC/BLE和远程API接口。这使工程师能远程检查配置、获取诊断信息。文章强调，对于数十万设备，这种设计从有用变为必需，可观测性不再只是应用日志，而是设备自我解释的能力。
间歇连接与能耗：重新定义设计约束
电池供电设备与网络的关系不同于企业应用。设备可能休眠、暂时失去连接或反复重连，连接尝试是最耗能操作。团队将间歇连接视为常态而非异常，影响固件、网关通信和命令设计。同时，能耗成为软件关注点，通过功耗测量和 profiling，理解每个设计决策的物理后果。甚至采用24小时重启等简化内存管理策略，这在服务器上不常见，但在设备上更合理。
固件部署与车队监控：安全发布与规模运维
固件部署无法快速回滚，且下载安装消耗电池。团队设计OTA更新时融入恢复机制，如安全下载、验证、分区交换，支持断点续传和分批发布。部署问题从“如何部署”变为“如何安全部署及出错怎么办”。随着设备规模扩大，监控从单设备转向车队级，通过仪表盘和分析识别通信失败、异常行为和固件分布，使运维团队能判断问题范围。
Q&A
在大型零售物联网改造中，团队部署了多少个电池传感器？覆盖多少家门店？
团队部署了约80万个电池供电的传感器，覆盖3000家门店。
为什么团队要建立物理实验室和虚拟设备模拟器？
因为需要理解已运行多年的物联网系统，但文档不足且部分行为无法复现，必须通过实际设备实验来学习；同时为了在规模上测试网络限制和大量设备行为，需要虚拟模拟器来模拟数百个设备。
针对电池供电设备的间歇连接和能耗问题，团队采取了哪些设计措施？
团队将间歇连接视为常态而非异常，设计固件、网关通信、命令和遥测以适应设备可能休眠、断连或重复连接的情况；同时引入功耗测量与分析，评估每次操作对电池寿命的影响，并简化内存管理（如定期重启）。
固件升级如何兼顾恢复与分批发布？
团队实现了OTA固件更新，包含安全下载、验证和分区交换；设备存储升级状态以便中断后恢复；支持按设备、分组或门店分批发布，并采用分阶段推出，确保更新安全可控。
为什么设备需要内置诊断和远程接口？
因为设备可能位于无法物理接触的位置，工程师需要远程了解设备状态、故障原因和网络情况。内置诊断提供健康检查、日志和API，远程接口（如NFC、BLE、网关）允许检查配置、获取诊断并执行操作。
车队级监控和仪表板解决了什么问题？
随着设备数量达到数十万，无法逐一检查，车队级监控通过仪表板和分析识别通信故障、异常行为、停机、固件分布等模式，帮助运营团队判断问题是孤立的还是影响整个车队。
AI在项目中起到了什么作用？
AI（LLM）用于探索不熟悉领域、原型解决方案、加速实验，以及辅助开发仪表板、迁移跟踪器等工具，主要降低了尝试新事物的成本，而非单纯生成代码。
