物联网项目立项前，硬件侧一般需要提供哪些资料？

正式立项前，硬件侧至少要提供可运行样机、带版本号的通信协议、字段与指令字典、联网/配网与身份方案、故障码、断网和 OTA 设计、目标环境与数量，以及能持续联调的固件负责人。只有产品介绍或口头协议时，软件方只能做预研，不能给出可靠工期和固定总价。

资料清单的目标不是写更多文档，而是让软件团队能重现一台设备从出厂、激活、运行、故障、升级到退役的完整生命周期。我们会在签约前把缺失资料标成假设与风险，并说明由谁在何时补齐；不能一边默认资料齐全报价，一边在开发中把协议变化都算需求变更。

在拆分设备、连接与软件平台职责时，还可以对照 如果硬件供应商不止一家、协议也不统一，这类项目还能做好吗？ 和 你们能做软硬件结合的物联网应用定制开发吗？；这些内容补充了需要放在同一项决策中考虑的上下文。

三道门分别需要哪些证据

决策门	硬件侧最低资料	软件侧能形成的结论	资料不足时的处理
是否值得做 POC	产品用途、型号、连接方式、初版协议、一台样机、技术联系人	判断能否连接、读取和执行一个安全命令	只做调研，不承诺正式架构
是否可正式报价	冻结协议、字段/指令/错误码、身份与配网、数量频率、网络环境、OTA、样机批次	拆接入、平台、应用、测试与运维工作量	报区间并列风险准备金或暂缓
是否可试产	多台不同批次样机、生产烧录、证书注入、日志、固件发布与回滚、验收治具	验证激活、长稳、批量升级和支持流程	不进入批量部署
是否可规模上线	认证与合规资料、供应链与版本策略、容量计划、漏洞响应、停产/退役安排	确认运营、安全、成本和生命周期	限制规模，先补治理能力

样机数量没有通用的“至少 2—3 台”。POC 一台可验证链路，稳定性和批次差异则需要更多真实生产样机，数量由失效模式、硬件批次和统计目标决定。样机应标明硬件版本、固件版本、序列号、SIM/证书和已知问题，禁止多人无记录刷写后继续对比。

协议文档必须能让第三方复现

协议需写明传输层与端点、认证、编码、字节序、校验、分包、主题或路径、心跳、重连和超时。每个字段说明名称、类型、单位、缩放、范围、枚举、缺失与异常值、采集和上报周期、时间来源；每条命令说明前置状态、参数范围、幂等 ID、确认/最终回执、超时、重试和失败安全状态。附正常及异常报文、抓包或模拟器，比只给 JSON 示例更可靠。

采用 MQTT 时可对照 OASIS MQTT 5.0确认 QoS、会话、遗嘱、消息过期与原因码，但私有主题和业务幂等仍由双方定义。协议文件必须有版本、发布日期、兼容范围和变更记录；改变单位、枚举或命令行为属于破坏性变更，不能静默覆盖。

安全、升级和退役资料不能最后补

硬件要说明唯一身份如何生成和注入，是否存在共用密码，密钥能否轮换撤销，调试口如何控制，固件是否签名、防回滚和失败恢复，日志如何导出，设备转让或报废如何清除数据。NIST IR 8259 Rev.1 的制造商基础安全活动强调 IoT 产品从上市前到上市后的安全与支持，说明硬件交付不应止于“能联网”。

目标运行环境也要量化：室内外、温湿度、电源、振动、防护、网络运营商、信号、带宽、时延和断网时长。若有边缘网关，提供型号、系统、端口、协议、资源、远程维护和补丁方式。涉及传感精度或控制安全，还需校准、认证、危险分析和现场联锁资料，软件团队不能自行推断。

资料最终要变成可执行验收包

我们会把硬件资料纳入版本库或双方可访问的文档空间，生成设备能力矩阵、字段/命令契约测试、模拟器、联调问题单和冻结基线。首次 POC 覆盖激活、上报、断网补传、重复乱序、时间漂移、无效值、命令超时、重启和凭据撤销；每次固件升级自动回归核心契约。

滚水科技的BMS 案例可说明品牌涉及设备平台方向，但不能证明客户硬件资料可以省略。最直接的启动方式是：硬件方交一台标注版本的样机、协议和固件联系人，双方在正式报价前跑通一个最小闭环；跑不通就先解决硬件或协议问题。