物联网项目最容易出纠纷的环节不是开发，是验收。技术上做完了，验收标准谈不拢，尾款拖半年。
根本原因通常不在技术，在合同：验收标准写得太笼统，双方理解不一致。这篇文章把最常见的 12 个问题列出来，每个都给出可操作的验收方法。
Q1：设备在线率怎么算？按什么口径？
这是最容易扯皮的一项。同一批设备，用不同口径算出来能差 10 个百分点。
必须先约定三件事：
- 统计周期：按天算还是按月算？按月平均还是按最差值？
- 在线定义：多久没上报算离线？5 分钟、30 分钟还是 2 小时？
- 分母范围：包含哪些设备？施工未完成的、客户自己拆掉的、断电的算不算？
推荐写法：「在线率 = 统计周期内每日在线设备数之和 ÷（设备总数 × 天数）。设备连续 30 分钟无数据上报判定为离线。因客户原因（断电、拆机、断网）导致的离线，经双方书面确认后从分母中剔除。」
Q2：并发怎么测？多少路算达标？
「支持 1000 路并发」这种表述没有意义，因为没定义「并发」是什么。
并发的三个层次：
| 层次 | 含义 | 测试方法 |
|---|---|---|
| 连接并发 | 同时保持连接的设备数 | 用压测工具模拟 N 个 MQTT 连接保持不断 |
| 消息并发 | 每秒处理的消息数（TPS） | 固定连接数，逐步提高上报频率，测吞吐上限 |
| 查询并发 | 同时进行的 API 请求数 | 用 JMeter 等工具压 API，看响应时间和错误率 |
推荐写法：「系统支持 10000 个设备长连接同时在线，单设备上报频率 1 次/分钟时，消息处理能力不低于 200 TPS，P99 处理延迟不超过 500ms。API 在 50 并发下，P95 响应时间不超过 800ms。」
关键是把数字拆开，每项都能测。
Q3：数据准确性怎么验证？
平台显示的温度是 23.5 度，怎么证明这个数字是对的？
三种验证方式：
- 端到端比对：在设备侧接一个标准表（比如标准电阻箱模拟 PT100），设定已知值，看平台显示是否一致
- 抽样人工核对：随机抽 10-20 个点位，现场用标准仪器读数，和平台对比
- 数据链路校验：抓包看设备上报的原始报文，和平台入库的值对比，确认中间没有转换错误
推荐写法：「随机抽取不少于 20 个测点，现场实测值与平台显示值的偏差不超过设备标称精度的 1.5 倍。」
Q4：响应延迟多少算合格？
「实时」这个词在合同里等于没写。
延迟分三段，每段都要单独约定：
- 采集延迟：从物理量变化到设备上报，取决于设备的采集周期
- 传输延迟：从设备发出到平台收到，取决于网络
- 呈现延迟：从平台收到到页面刷新，取决于推送机制
推荐写法：「设备采集周期 10 秒，端到端延迟（物理量变化到平台页面显示）不超过 15 秒，P95 不超过 20 秒。」
注意：如果你要求「秒级实时」，设备的采集周期、网络、平台推送三处都要配合，成本会明显上升。签合同前想清楚是不是真的需要。
Q5：告警准确率怎么算？误报率多少可接受？
告警是物联网项目最容易被投诉的功能。误报太多，用户会关掉通知；漏报，出了事故要担责。
三个指标：
- 准确率：真实发生的告警中被正确报出的比例（漏报率的反面）
- 误报率：报出的告警中，实际不成立的比例
- 响应时间：从告警条件成立到通知送达的时间
推荐写法：「在验收测试期内，按双方确认的告警规则触发 50 次真实告警，准确率不低于 95%，误报率不高于 5%，告警通知延迟不超过 30 秒。」
重要提示：告警规则本身要写进合同附件。规则不明确，准确率就没法算。
Q6：历史数据保留多久？
这一项直接影响存储成本，必须写清楚。
分层约定：
- 原始数据（秒级/分钟级）：保留 3-6 个月
- 聚合数据（小时级）：保留 2-3 年
- 日统计：长期保留
推荐写法：「原始采集数据保留 6 个月，1 小时聚合数据保留 3 年，日统计数据永久保留。超出保留期的数据自动归档或清理。」
如果不约定，客户默认「永久保留」，你的存储成本会失控。
Q7：验收测试期多长？期间出问题怎么算？
常见的坑：验收测试期设 7 天，结果第 6 天出了个 bug，客户要求重新计 7 天，无限循环。
推荐写法：「连续试运行 30 天，期间如出现影响系统正常使用的严重故障（定义为导致 30% 以上设备离线超过 2 小时，或核心功能不可用超过 1 小时），试运行期自故障修复之日起重新计算。一般缺陷不计入重置条件，乙方应在 5 个工作日内修复。」
关键是区分「严重故障」和「一般缺陷」，否则客户可以拿任何一个 bug 重置工期。
Q8：设备清单和实际到货不一致怎么办？
项目常见的现实：合同签的是 A 型号，实际供货因为停产换成了 B 型号，参数接近但不完全一样。
推荐做法：合同里写「或同等性能替代型号，经甲方书面确认后可替换」，并附上关键参数的允许偏差范围（比如精度 ±0.5% 可放宽到 ±1%）。
不要写「必须完全一致」，也不要写「乙方可自行替换」。两个极端都会出问题。
Q9：软件功能「符合需求文档」怎么判定？
这是最模糊的一条。需求文档写「支持数据可视化」，做出来的大屏客户说「不是我要的样子」。
推荐做法：需求文档必须配原型图或者界面截图。文字描述不算数，必须有视觉稿。
验收时逐条对照原型：功能在不在、交互是否一致、数据是否正确。样式细节（配色、字体）不纳入验收，避免无限修改。
Q10：第三方系统对接失败，责任怎么分？
物联网项目经常要对接客户已有的 ERP、OA、门禁、视频平台。对接不上时，双方互相推。
推荐写法：「乙方负责按甲方提供的接口文档完成对接开发。因第三方系统接口变更、文档错误、或第三方不配合导致的对接失败，不属于乙方责任，但乙方应提供必要的技术协助，协助工作量超出 5 人日的部分另行计费。」
同时要求甲方在项目启动时提供完整的接口文档和测试环境。没有这两样，对接工作无法评估工期。
Q11：验收不通过怎么办？
必须约定整改机制，否则会陷入「客户永远不满意」的循环。
推荐写法：「验收不通过时，乙方应在 15 个工作日内完成整改并提交复验。复验仍未通过的，双方应就具体不符合项进行书面确认，属于乙方责任范围内的继续整改，属于新增需求或标准变更的，另行协商工期和费用。」
核心是把「不符合项」书面化、逐条确认。口头说「不行」不算，必须列出哪一条不符合、依据是什么。
Q12：质保期从什么时候开始算？
常见争议：项目 3 月完工，客户拖到 9 月才验收，质保期从 3 月还是 9 月算？
推荐写法：「质保期自项目验收合格之日起计算，为期 12 个月。如因甲方原因导致验收延迟超过 60 天，质保期自系统实际投入使用之日起计算。」
这条能避免「系统用了半年才验收，质保期已经过了一半」的情况。
签合同前的检查清单
- 在线率的统计口径、统计周期、分母范围写清楚了吗？
- 并发拆成连接数、TPS、API 并发三项了吗？
- 数据准确性有抽样数量和偏差标准吗？
- 延迟拆成采集、传输、呈现三段了吗？
- 告警的准确率、误报率、响应时间都约定了吗？告警规则进附件了吗？
- 数据保留期分层约定了吗？
- 试运行期的重置条件写清楚了吗？「严重故障」定义了吗？
- 设备型号替换的机制有吗？
- 需求文档配原型图了吗？
- 第三方对接的责任边界划清了吗？
- 验收不通过的整改机制和复验流程有吗？
- 质保期的起算点和延迟验收的处理约定了吗？
这 12 条看着琐碎，但每一条都对应过真实的纠纷。合同阶段多花两个小时写清楚，能省掉后期两个月的扯皮。