每一次集成都从协议审计开始。我们的工程师将每一台现场设备映射到其原生协议——Modbus RTU 与 TCP、OPC UA、MQTT、BACnet、LoRaWAN、ProfiNet（通过专用旁路实现只读）与 EtherNet/IP——并精确界定哪些寄存器、tag 或 topic 承载业务真正需要的变量。我们逐寄存器、逐 tag 地编制文档，而不仅是宣称"面板已接通"。这份目录将成为唯一可信数据源，被下游每一套系统——从 SCADA 到 AI 模型——在未来十年里持续引用。

边缘层是大多数项目成败的关键所在。我们以自研工业网关 SRT-MGATE-1210 作为默认平台——它专为印度尼西亚的气候、电压范围与蜂窝网络环境而设计与制造。当项目需要第三方认证硬件时，我们以同等的工程严谨度集成 Moxa、Advantech、Siemens IoT2050 或 Dell Edge 网关。每台网关都启用 store-and-forward 缓冲，让不稳定的 4G 链路永远不会丢失生产数据；并具备边缘分析能力，让低时延控制回路在本地执行，无需等待往返云端的延迟。

网络架构遵循 Purdue Reference Model 进行 OT/IT 分段。我们在 Level 2 与 Level 3 之间设置 DMZ，部署 Hirschmann、Moxa 或 Fortinet 的工业防火墙，并通过带双向认证的 TLS 1.3 隧道传输所有北向流量。对于既有改造（brownfield）场地，我们在 OT 侧加入深度包检测，在异常流量到达企业网络之前就将其捕获。安全不是附加项，而是在第一天就嵌入我们交付给客户的参考架构之中。

云端目的地按项目选择，而非按合作伙伴关系决定。新加坡与雅加达区域的 AWS IoT Core、东南亚区域的 Azure IoT Hub、Google Cloud IoT（在仍适用的场景下），以及本地部署的 InfluxDB 加 Grafana 栈，都是我们常规部署的选项。对于偏好 turn-key 平台的客户，我们的 SURGE SaaS 已经就绪，具备多租户隔离、KLHK SPARING 就绪的数据摄取以及白标仪表板。我们常规运行混合架构：敏感工艺数据保留在本地，非敏感聚合数据则流向云端仪表板供管理层查看。

参考模式在我们的项目组合中反复出现：针对高频振动数据的时间序列压缩、以减少蜂窝费用的 change-of-value 发布、为满足长期审计保留的冷热存储分层，以及为无法容忍网络往返的安全告警提供边缘推理。每一种模式都是为匹配工厂具体的失效模式而选定——而不是因为厂家手册推荐了它。