本项目为方案设计阶段，页面中的数字来自需求测算与架构推演，不是上线后的实际运行数据。 已交付项目会单独标注「已交付」。
这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
校方原有的 12 个子系统由不同厂商在不同年份建设，数据接口形式各异，有的只有数据库直连，有的连文档都没有。
招标技术参数必须写成可核验的形式，但又不能写成只有某一家能响应的私有指标，否则会被质疑排他。
平台要同时服务三类角色——校领导看汇总、后勤看设备、网络中心看告警，三套视角的数据粒度和刷新频率完全不同。
预算有限，需要说清楚哪些能力必须自研、哪些用开源二开、哪些直接采购现成产品。
问题不在技术，在需求描述不出来
校方很明确要建一个「校园物联网平台」，但问到具体要接哪些设备、采哪些数据、数据保留多久、谁能看什么，就说不清了。招标文件里如果只写「建设统一的物联网平台，实现设备统一接入管理」，投标方会给出十种完全不同的方案，评标时无法横向比较。
我们要解决的第一件事，是把模糊的建设意愿翻译成 157 条可以逐条打勾的技术参数。
从数据流反推架构，而不是从架构往下套
常见的错误是先画一张漂亮的分层图，再往格子里填东西。这次反过来：先确定数据从哪来、到哪去，再决定需要哪些组件。
- 1列出全部数据源：12 个子系统、约 40 类设备、每类设备的输出字段。
- 2确定采集方式：能走标准协议的走协议（Modbus、BACnet、SNMP、OPC UA），只能走数据库的做定时同步，完全封闭的走厂商提供的 SDK。
- 3定义数据模型：把 40 类设备归并成 9 个物模型，避免每接一类设备就新建一张表。
- 4规划数据生命周期：原始数据保留 30 天，分钟级聚合保留 1 年，小时级聚合长期保留。
- 5最后才画架构图，此时每一层放什么组件已经是推导结果，不是拍脑袋。
平台是可以换的，数据模型换了等于全部重做。先把 9 个物模型定下来，后面无论用开源平台二开还是采购商业产品，迁移成本都可控。
157 条参数怎么写才既能核验又不排他
IOC 格式（指标—算子—条件）的核心是把「要好用」变成「在什么条件下、达到什么指标、怎么测」。三条经验：
- 写能力不写品牌。不写「支持某厂商协议」，写「支持 Modbus RTU/TCP、BACnet/IP、SNMP v2c/v3、OPC UA 中至少三种」。
- 写可测的数字不写形容词。不写「高性能」，写「单节点支持不少于 5000 个设备连接，消息吞吐不低于 3000 条/秒」。
- 写验收方法。每条参数后面注明怎么验证——现场演示、提供测试报告、还是提供第三方检测证书。
| 参数类别 | 条数 | 示例 |
|---|---|---|
| 设备接入能力 | 38 | 协议种类、单节点连接数、断线重连时间 |
| 数据存储与查询 | 27 | 写入吞吐、查询响应、数据保留策略 |
| 平台功能 | 42 | 规则引擎、告警、OTA、权限模型 |
| 可视化与报表 | 24 | 组态能力、大屏刷新频率、报表导出格式 |
| 安全与运维 | 26 | 认证方式、审计日志、备份恢复 |
开源二开到底省不省钱：三套方案的成本测算
开源 IoT 平台看起来很香，但二次开发的隐性成本经常被低估。我们对三套主流方案做了拆解：
| 方案类型 | 首年成本构成 | 隐性成本 | 适用判断 |
|---|---|---|---|
| 开源平台二开 | 开发人力为主，无授权费 | 社区版功能裁剪、升级冲突、文档质量参差 | 有稳定技术团队、需求会持续变 |
| 商业平台采购 | 授权费 + 实施费 | 按设备数或节点数计费的扩容成本 | 需求相对标准、需要厂商兜底 |
| 自研核心 + 开源组件 | 人力最高 | 周期最长，但完全可控 | 有特殊数据模型、长期演进 |
开源平台的社区版和企业版功能差异，往往在你开发到一半时才发现——某个关键能力（比如多租户或规则引擎的某个节点）只有企业版才有。选型时必须在 PoC 阶段就把这些点验证掉。
方案产出
本项目处于方案设计阶段，交付物为可直接用于招标的技术文件与决策依据。
- 157 条 IOC 格式技术参数，每条含指标、条件与验收方法。
- 自下而上的四层数据流架构图，标注每层组件与数据流向。
- 12 个子系统的接入方式清单，标明协议、数据粒度、对接工作量。
- 演示评分标准，把主观印象分转成可打分的维度。
- 三套开源方案的二开成本测算与选型建议。
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。