工业物联网平台需求清单

很多工业物联网项目不是卡在开发阶段，问题往往更早。立项时只列了一个“做平台”的方向，真到实施才发现设备协议不统一、现场网络条件没摸清、报警流程没人拍板、验收口径也没定下来。前面省掉的确认，后面都会在联调和上线时补回来。

所以需求清单不能只写页面和功能名称。项目要落地，至少得先把设备怎么接、数据往哪走、谁来处理异常、哪些角色要用、首期准备交付到什么深度写清楚。若项目还在比选方案，可以先对照 工业物联网平台开发服务、海外冷链设备管理平台案例 和 常见问题 里的边界说明，判断当前需求是否已经够到可启动状态。

立项前先把边界写实

第一步是确认设备侧现状。设备是 PLC、网关、传感器、工控机，还是混合接入；协议走 Modbus、MQTT、HTTP 还是厂家私有协议；数据采样频率、上报方式、离线补传和远程控制权限是否已经明确。这些内容不落纸，平台需求就很容易停在空泛层面，后面每一轮讨论都得重来。

第二步是确认业务边界。平台给生产负责人、运维人员、经销商还是管理层使用，不同角色关注的内容完全不同。有人要看实时状态，有人只关心告警闭环，有人需要报表和权限审计。首期若把监控大屏、设备台账、告警联动、工单流转、能耗分析、移动端配套一起打包，范围很快就会失控。

建议把下面这些内容先整理成一页基础清单，再进入排期和报价阶段。

• 设备类型、数量、接入协议和现场网络条件
• 采集字段、控制指令、报警阈值和历史数据保留要求
• 角色划分、权限层级和通知方式
• 首期必须上线的页面、报表和接口范围
• 是否涉及私有化部署、第三方系统对接和多工厂扩展

平台需求里最常漏掉的几项

很多团队会把设备接入写进去，却漏掉数据治理。工业现场的数据并不总是干净稳定，同一个点位可能出现空值、延迟、重复上报或单位不一致。平台如果没有明确的字段口径、异常处理规则和历史归档策略，后续看板、报表和告警都会被拖慢。

第二类常漏项是运维链路。谁负责处理设备离线，多久触发通知，通知走短信、企微还是站内消息，处理后是否需要留痕，升级和回滚怎么做，这些都是上线后天天会遇到的事。需求文档里不写，项目验收时几乎一定会补。

还有一类问题出在协同接口。工业物联网平台通常不会单独存在，常见情况还包括 ERP、MES、售后系统、BI 报表或客户自有后台。对接方式、字段映射、同步频率和失败重试口径，最好在需求阶段就写明。若只是先做平台主体，也可以同步参考 IoT 定制开发服务 的交付范围，提前判断哪些接口该放进首期，哪些适合后置。

把这些项补齐后，需求清单通常至少应覆盖以下模块。

• 设备接入与在线状态
• 实时监控、历史趋势和数据导出
• 告警规则、通知方式和处理闭环
• 组织架构、账号权限和操作日志
• 第三方系统接口、部署环境和验收标准

清单里常被漏掉的三项

需求清单里有三项常被漏掉。一是设备在线状态的判断依据，灯具控制器项目上线后就遇到过“显示在线、实际已断开”。二是历史数据的去重和保留周期，设备上报频繁时数据量涨得很快。三是数据库变更的管理方式，测试和生产环境的结构对不上会带来很多麻烦。参考灯具与种植环境控制器平台案例。

用五层结构核对需求

工业物联网平台功能地图：设备接入、数据处理、业务功能、权限与组织、运维与交付

需求清单最常见的问题是「只写页面」：设备列表、监控大屏、告警列表……而接入、数据处理和运维几乎是空白。按上图五层逐项核对，能把大部分遗漏在立项阶段找出来。

每一层要写清楚的内容

设备接入

• 设备类型和数量、各自的通讯方式（4G、以太网、RS-485 经网关）和协议；
• 每类设备的上报频率、单条数据大小、是否有事件上报；
• 设备认证方式、是否需要远程配置和 OTA；
• 网络中断时设备或网关是否缓存、恢复后如何补传。

数据处理

• 点表：字段、单位、换算规则、有效范围；
• 数据质量规则：超出范围、长时间不变、跳变如何处理；
• 存储：原始数据和聚合数据各保留多久；
• 统计口径：日切点、时区、累计值清零如何处理。

业务功能

• 告警规则：条件、持续时间、级别、通知对象、恢复条件、重复抑制；
• 远程控制：哪些参数可写、谁能写、回执超时怎么处理；
• 报表：哪些报表、谁看、导出格式。

权限与组织

• 组织层级（集团、工厂、产线 / 客户、经销商）和数据可见范围；
• 角色权限，尤其是远程控制和参数修改；
• 操作审计要求。

运维与交付

• 部署方式（公有云 / 私有化）、环境数量（测试、生产）；
• 备份、监控、升级方式；
• 验收标准和验收数据。

把需求从「写虚」改成「写实」

需求清单里最容易写虚的地方

一个可验收的告警需求示例：

- name: 冷库温度过高
  device_type: cold-room-controller
  condition: room_temp > setpoint + 5   # 相对设定值
  duration: 10m                          # 持续 10 分钟才触发，过滤开门等短时波动
  level: major
  notify: [device_owner, project_engineer]
  channels: [app_push, email]
  recover: room_temp <= setpoint + 2 持续 5m
  suppress: 同一设备同一规则 30 分钟内只通知一次

写到这个程度，开发、测试和客户对「告警」的理解就是一致的。

我们项目里补上的需求

除了前面提到的三项，项目里还常补上这些：避雷器监测平台的「规则复算 dry-run」（调阈值前先看历史数据会命中多少）、雷冲计数「只增不减」并保留计数审计；冷链平台的「稀疏上报合并规则」；BMS 平台的「设备归属流转记录」。这些都是在需求阶段写清楚比上线后补便宜得多的点。

上线前再看一遍验收口径

需求清单写到最后，最值得再核一遍的是验收边界。页面做完不等于平台可以交付，设备在线率怎么算、报警误报怎么判、历史数据是否完整、角色权限是否符合现场流程、弱网或断网场景怎么处理，这些都要变成能核对的条目。验收条件越具体，项目推进越稳。

首期版本也不必什么都装进去。工业平台更适合先把核心链路跑通，先保证设备接得上、数据看得懂、异常有人接、权限不混乱，再决定二期是否补报表中心、能耗分析、预测维护和更复杂的跨系统联动。这样做，预算和时间都更容易控住。

若企业正在梳理工业物联网平台开发范围，可以先把现有设备清单、协议资料、目标角色和上线计划整理出来，再通过 联系我们 发一版项目背景。把这份需求清单和 工业物联网平台开发服务、海外冷链设备管理平台案例 放在一起看，讨论会更快落到能执行的范围上。

常见问题

工业物联网平台需求文档应该包含哪些部分？

至少包含设备接入、数据处理、业务功能、权限与组织、运维与交付五部分，每一项写到可以验收的程度，例如具体的采集频率、告警条件和数据保留时间。

告警需求怎么写才算清楚？

写明触发条件、持续时间、级别、通知对象和渠道、恢复条件和重复抑制规则，最好给出一两个具体例子。

性能需求怎么写？

写接入设备数、每秒消息数、数据保留时间和常用查询的时间范围，例如「查询单台设备 30 天曲线」，而不是写「系统要稳定、要快」。

需求还不完整能先启动吗？

可以先启动设备接入和数据链路部分，同时补齐业务需求；但点表、组织层级和告警规则越晚确定，返工风险越大。