发那科+西门子机床联网，数据怎么统一？

车间里同时有发那科和西门子数控机床，很多企业第一反应是“把网线插上、找个软件读数据”。真正实施后才发现，A机床能看状态，B机床只能读报警；A用FOCAS，B用OPC UA；老机床连网口都没有。设备联网采集的核心不是接线，而是把多品牌、多代际的数控系统统一成一套可被MES系统消费的数据语言。

一、为什么“都插上网线”还是统一不了

发那科和西门子的差异集中在四个层面：协议不同、授权不同、数据语义不同、网络边界不同。发那科常用FOCAS或MTConnect，较新系统支持OPC UA，但FOCAS往往需要选项授权，并发连接数也有限；西门子840D sl、828D可通过OPC UA、S7协议或MTConnect采集，部分接口同样需要许可。若让MES直接高频轮询机床，容易出现连接数占满、数据丢包、机床通讯负荷上升等问题。

• 协议层：FOCAS、MTConnect、OPC UA、S7、Modbus并存。
• 授权层：部分端口和选项需要单独开通，实施前必须确认。
• 语义层：同样是“运行”，不同系统可能叫自动、加工、循环启动。
• 网络层：机床网段、办公网段、平台网段需要隔离和边界防护。

二、用边缘网关做“翻译层”

推荐采用“设备层—边缘层—平台层—应用层”的四层架构。设备层是CNC、PLC、电表和扫码枪；边缘层用工业网关做协议转换、边缘缓存、断点续传和死区过滤；平台层通过MQTT或OPC UA统一接入，写入时序数据库；应用层由MES系统做工单下发、报工回传、设备状态监控和OEE分析，工业互联网平台负责设备上云和多厂区看板。

采集频率不必一刀切：运行状态1—5秒一次，报警按事件触发，加工计数分钟级汇总，工艺参数按需采集。这样既能保证设备状态监控的实时性，又不会给老机床造成通讯压力。

三、统一数据模型，报表才能对得上

建议先定义设备台账和测点字典，统一设备ID、程序号、运行状态、主轴转速、进给倍率、报警码、加工计数、刀具号、节拍和合格数等字段，并明确单位、精度、上报频率和异常值处理规则。只有把“发那科的语言”和“西门子的语言”映射到同一套模型，MES里的OEE、停机分析和报工数据才有可比性。

四、实施路径：先试点，再推广

• 盘点每台机床的系统型号、软件版本、可用端口和授权情况。
• 选择3—5台代表性设备做试点，覆盖发那科、西门子和一台老设备。
• 验证数据完整率、时间同步、断网续传和报警准确性。
• 固化协议适配配置，再批量推广，避免每加一种机床就改代码。

某汽配厂有30台发那科、18台西门子设备，通过边缘网关统一语义后，设备数据完整率达到98%，OEE从手工报表的62%变为可分班次分析，停机响应时间从约40分钟降到8分钟。这个案例说明，统一采集的价值不在“多一个看板”，而在把停机、报工、OEE和工单进度连成闭环。

五、六个常见坑

• 让MES直接轮询机床，忽略FOCAS并发限制。
• 实施前没确认OPC UA或FOCAS授权，上线才发现端口不可用。
• 只采状态不统一语义，报表仍然靠人工二次整理。
• 忽略NTP时间同步，跨班次数据对不上。
• 边缘网关没有断网缓存，网络一抖就丢数。
• 协议适配写死在代码里，后续扩展成本高。

对于多品牌设备并存的企业，建议把协议适配层做成可配置组件，再由MES系统和工业互联网平台消费统一数据。若需要移动端查看设备状态，可结合小程序开发做轻量看板；有二次开发和系统集成需求时，选择熟悉车间现场与软件架构的团队，例如具备佛山顺德软件定制开发经验的服务商，更容易把设备联网、设备上云和智能制造目标落到可验收的交付物上。

总结一句话：发那科和西门子不需要被改造成同一种机床，只需要在边缘层被翻译成同一种数据模型。先解决授权和协议，再统一语义和频率，最后接进MES系统，设备联网采集才能从“能看”走向“能用”。