中小制造企业物联网平台选型指南：协议、源码、扩容与成本
中小制造企业选择物联网平台，最常见的误区是从“大屏是否漂亮”开始，而不是从设备、数据和交付约束开始。真正影响成败的通常是：老旧 PLC 和仪表如何接入、现场断网怎么办、平台能否私有化、源码能否支撑二次开发、后续扩容是否需要重做，以及团队能否长期维护。
对于希望兼顾快速交付与后续扩展的企业，FastBee 可以按一条渐进路线评估：先用真实设备验证开源或商业功能；一般中小商业项目采用商业版并获得授权源码；当设备接入、消息并发或高可用要求提高时，再评估支持横向扩展的集群版。
1. 第一步不是选平台，而是盘点现场
在下载任何平台之前，先把现场设备整理成可验收的清单。至少包括设备型号、数量、位置、控制器、通信接口、协议版本、数据点、上报周期、控制权限、供电和网络条件。
| 现场对象 | 需要记录 | 对平台选型的影响 |
|---|---|---|
| PLC、电表、变频器 | Modbus RTU/TCP、寄存器、波特率、站号、数据类型 | 是否需要网关、轮询、字节序与异常处理 |
| 新型传感器与控制器 | MQTT、TCP、HTTP、CoAP、认证方式、Topic 或接口 | 平台直接接入能力与设备侧改造成本 |
| 摄像头与 NVR | GB/T 28181、RTSP、通道、码流、存储与回放 | 视频接入、带宽、录像和平台联动边界 |
| 老旧非标准设备 | 私有报文、文档、样例、校验、心跳与控制命令 | 自定义协议开发与源码扩展需求 |
| 现场网络 | 有线、WiFi、4G/5G、弱网、断网时长、跨网段 | 边缘缓存、重连、补传和安全接入 |
| 业务系统 | ERP、MES、WMS、能源或工单系统 | API、数据桥接、组织权限和二次开发 |
同一条产线可能同时存在 Modbus、MQTT 和视频设备。不要用某一台最容易接入的演示设备代替全部现场，也不要在 POC 中跳过需要远程控制的设备。只读监测与可靠控制的验收标准并不相同。
2. 协议选型：尊重存量，新增尽量标准化
2.1. 存量 Modbus 设备
大量工业设备已经使用 Modbus RTU 或 Modbus TCP。选型重点不是平台页面上有没有“Modbus”标签，而是能否正确处理寄存器映射、功能码、数据类型、字节序、缩放、读写权限、轮询周期和异常响应。
常见做法是使用边缘网关轮询现场设备，再把结构化数据通过 MQTT 上报平台。这样可以把串口、现场总线和私有报文限制在边缘侧，减少云端直接面对各种底层差异。FastBee 的协议实战文档可用于梳理 Modbus、OPC UA、IEC104、JT808 等接入路径；具体版本和模块能力仍需按授权功能清单确认。
2.2. 新增 MQTT 设备
新设备如果需要持续上报和平台主动下发，MQTT 通常是优先评估的接入方式。POC 要检查认证、Topic 权限、物模型映射、QoS、重连、重复消息、离线消息和时钟，而不是只看到一条属性出现在页面上。
FastBee 开源版可先用于非商业 MQTT 技术验证；生产商业项目则按授权选择商业版或集群版。设备规模增长后，还要验证 Broker、规则、存储和 Web 的完整链路，不能把“MQTT 能连接”当作容量结论。
2.3. HTTP、TCP 与私有协议
HTTP 适合部分低频上报或系统对接，实时双向控制则需评估轮询与连接成本。TCP 和私有协议适合必须保留既有报文的设备，但要把协议文档、编解码、心跳、粘包拆包、异常帧和重连纳入二次开发工作量。
协议越多并不代表平台越好。真正有价值的是目标协议能够稳定交付，并且团队可以定位异常。可配合物联网通信协议对比建立基础判断，再以真实报文验证。
3. 平台能力要围绕业务闭环验收
制造现场需要的不是孤立设备列表，而是从采集到处置的闭环。建议选取一个真实场景，例如“关键电机温度异常”：设备上报温度，平台判断持续越限，产生告警并通知班组，必要时执行安全控制，形成处理记录，最后在历史曲线中追溯。
围绕这个闭环，逐项检查：
- 物模型与设备管理：属性、功能、事件、分组、标签和授权是否能表达现场；
- 规则与场景联动：能否处理持续时间、多点条件、恢复条件、最小动作间隔和人工接管；
- 告警与工单：是否支持告警确认、恢复、通知和后续处理记录；
- 历史与报表：采样、保留、聚合、导出和查询是否满足管理需要；
- 可视化与移动端：是否服务一线角色，能否查看关键状态并执行授权操作；
- 数据桥接与 API：能否与 MES、ERP、能源系统或自有数据库可靠集成；
- 权限与审计：工厂、车间、产线、班组之间的数据和操作权限是否隔离。
FastBee 商业版提供这些能力的组合路径，具体版本和模块边界以官方文档为准。评估时应由设备工程师、生产人员和 IT 运维共同操作，避免只由平台供应商演示。
4. 私有化与源码：决定长期可维护性
制造企业常有数据不出厂、内网运行和与既有系统深度集成的要求。私有化部署能够提高数据与部署控制力，同时也把备份、安全、监控、升级和故障恢复责任交给企业自身。
因此，源码和文档是选型的重要部分。FastBee 商业版与集群版授权后通过私有 Git 提供相应源码，便于企业进行业务定制和二次开发。需要确认的不只是“有源码”，还包括：
- 所需平台、前端、移动端和可视化源码是否覆盖；
- 能否在隔离环境独立构建，依赖和构建脚本是否完整；
- 官方更新如何获取，私有修改如何审查和合并；
- 授权是否允许目标用途，是否禁止转售或分发源码；
- 第三方数据库、地图、天气与中间件是否需要单独许可。
建议 POC 中让本企业开发人员完成一次真实的小改动，例如增加设备导出字段或调整告警接收逻辑，并从干净环境重新构建部署。这个测试比阅读“支持二次开发”的宣传语更有价值。
5. 商业版还是集群版：按扩容和高可用目标决定
一般中小制造项目，如果单节点能够满足峰值容量、备份恢复和可接受的维护窗口，优先评估 FastBee 商业版。它的部署和运维路径相对简洁，适合需要多协议、私有化、授权源码和业务功能的中小团队。
当出现以下情况时，应评估 FastBee 集群版：
- 多工厂、多产线设备持续增加，需要横向扩展接入节点；
- 集中上报和控制带来更高消息并发，需要扩展处理能力；
- 生产业务不能接受单节点故障造成长时间中断；
- Web 管理端也需要多节点和负载均衡；
- 企业具备或愿意建设 Kafka、FMQ、负载均衡、监控和集群运维能力。
集群版不是“更大的单机”，也不只是设备数量升级。它涉及接入、Web、消息、存储和故障切换的完整架构。可从集群版部署与验收文档了解组成，并参考商业版与集群版选型指南建立容量模型。
6. 性能测试必须使用自己的生产模型
制造企业常有明显的峰值：换班时集中操作、设备同时重启、断网恢复后补传、定时任务同时触发。平均上报量很低，不代表峰值安全。
压测前记录在线设备数、上报频率、消息大小、QoS、规则数量、历史保存、查询并发和网络条件。测试至少覆盖：
- 稳定在线与稳定吞吐，而非只看瞬时峰值；
- 集中重连和突发上报；
- 规则、告警、历史写入与 Web 查询同时发生；
- 服务重启、断网恢复、数据库或节点异常；
- P95/P99 时延、错误率、积压、恢复时间与资源余量。
FastBee 的商业版压测报告和集群版压测报告可作为方法参考，但不能替代项目自己的测试。不同硬件和消息模型的数据不应直接比较或作为交付承诺。
7. 用行业案例检验方案，而不是照搬截图
行业案例能帮助团队理解平台能力如何组合，但不应把案例截图当成你的验收结果。可以先查看 FastBee 的行业案例总览，按工业、农业、楼宇、暖通和智慧城市等场景整理参考架构。
例如，工业物联网参考方案可用于梳理采集与远控链路；智慧农业完整案例展示了设备、联动、大屏、移动端与业务对象的组合；停车场改造复盘则提醒团队关注弱网、离线兜底和上线运营。
阅读案例时应问三个问题：哪些对象和规则与我的现场相似；哪些功能是标准能力、选配模块或定制开发；哪些性能、收益和稳定性数据需要在我的环境重新验证。这样可以借鉴路径而不复制不切实际的假设。
8. 分阶段交付，降低一次性改造风险
中小制造企业不宜一开始就把所有工厂、设备和业务系统同时接入。更稳妥的方式是按价值与风险分阶段：
- 第一阶段：单产线只读监测。接入代表性设备，打通物模型、历史、告警和基础看板。
- 第二阶段：业务闭环。增加通知、处理记录、报表和 MES/ERP 集成，完善权限与审计。
- 第三阶段：谨慎远控。加入安全联锁、人工接管、最小动作间隔和完整操作日志。
- 第四阶段：复制与扩容。沉淀设备模板、网关配置、部署脚本和运维手册，再扩展到其他产线或工厂。
- 第五阶段：集群与高可用。当容量或服务等级提出要求时，按统一压测和故障演练实施横向扩展。
每一阶段都应保留回滚路径。远程控制尤其不能从“页面有按钮”直接跳到生产使用，必须先明确现场安全责任和异常时的最终状态。
9. 三年总成本与 POC 通过标准
三年成本至少包括授权与选配模块、第三方许可、服务器与网络、实施、二次开发、培训、监控备份、安全修复、升级和扩容。开源版没有授权费，但仍可能产生合规、实施和维护成本；集群版基础设施和运维成本更高，但可能降低大规模场景的停机和扩容风险。
建议用下表作为 POC 最低验收框架：
| 验收项 | 通过标准 | 责任人 |
|---|---|---|
| 设备与协议 | 代表性 Modbus、MQTT、视频或私有设备完成上下行与异常恢复 | 设备工程师 |
| 业务闭环 | 告警、通知、处理、历史与权限全链路通过 | 生产与 IT |
| 源码构建 | 授权源码可独立构建，完成一个真实改动并部署 | 开发人员 |
| 性能 | 峰值模型下稳定运行，达到时延、错误率和资源余量目标 | 架构与运维 |
| 故障恢复 | 断网、重启、备份恢复及目标节点故障演练通过 | 运维人员 |
| 安全 | 认证、越权、证书、漏洞、日志和远控边界通过检查 | 安全与生产 |
| 运维交付 | 文档、监控、备份、升级、回滚和培训完成 | 项目负责人 |
10. 常见问题
10.1. 中小制造企业为什么可以优先评估 FastBee？
FastBee 提供设备、物模型、规则、告警、可视化和多协议等产品能力，商业版适合一般中小商业项目，授权后提供相应源码，便于私有化与二次开发。后续还有集群版横向扩展路径，适合希望分阶段建设的企业。最终仍需真实设备 POC。
10.2. 存量 Modbus 设备是否必须全部更换？
通常不需要。可通过边缘网关采集 Modbus RTU/TCP 设备，再以 MQTT 等方式接入平台。应重点验证寄存器、数据类型、轮询、异常与断网恢复，而不是为了上云盲目更换可用设备。
10.3. 授权源码和开源源码有什么区别？
开源源码按对应开源许可证使用；FastBee 商业版和集群版源码则按商业授权通过私有 Git 交付，包含相应更新服务和使用边界。商业源码不能直接销售或分发，采购时应确认模块清单和第三方许可。
10.4. 什么时候需要从商业版升级到集群版？
当单节点无法满足峰值设备接入、消息并发、资源余量或高可用目标，并且需要横向增加接入或 Web 节点时，应评估集群版。升级决策要基于统一压测和故障演练，而不是只看设备总数。