4. 远程诊断通信协议解析

在 Omron Sysmac 平台上做远程诊断，本质上不是“连上 PLC 看变量”这么简单，而是要在四条不同的通信路径上分别取到诊断数据：EtherNet/IP 上的 CIP 消息、EtherCAT 主站内部的诊断对象、面向旧系统的 FINS 通信，以及面向上层信息系统的 OPC UA。它们各自解决不同层面的问题，理解它们的定位差异，才能在现场判断“该走哪条路、能拿到什么、拿不到时卡在哪里”。

一、EtherNet/IP CIP 消息：设备级诊断的主通道

CIP（Common Industrial Protocol）是 EtherNet/IP 的应用层协议，它把通信对象抽象为“类（Class）—实例（Instance）—属性（Attribute）”三级寻址模型。远程诊断时最常用的是显式消息（Explicit Messaging），通过未连接或已连接消息向目标设备发送服务请求，读取身份对象、TCP/IP 对象、Ethernet Link 对象以及厂商自定义诊断对象。

以读取设备身份为例，Identity Object 的类代码为 0x01，实例 1，属性 1 为厂商 ID、属性 7 为产品名称。一条典型的 CIP 显式请求在报文层面包含服务码、请求路径长度、路径段（类/实例/属性）和数据。用类 0x01、实例 0x01、属性 0x07 读取产品名称，返回的是短字符串，可用来确认远端站点的实际型号，避免“以为连的是 NX102，实际是 NX1P2”这类误判。

服务码: 0x0E (Get_Attribute_Single)
路径:  20 01 24 01 30 07
       └ Class 0x01 └ Instance 0x01 └ Attr 0x07
返回:  产品名称字符串 + 状态码 0x00(成功)

诊断价值更高的还有 Ethernet Link Object（类 0xF6），其属性可读出链路状态、协商速率、双工模式、收发字节数、CRC 错误与丢包计数。当现场出现“偶发掉站”时，先读这些计数器，比反复重启有效得多：如果 CRC 错误持续增长，问题多半在物理层（线缆、屏蔽、接地、连接器）；如果链路状态频繁翻转而错误计数不涨，则更可能是对端设备或交换机端口问题。需要注意，CIP 显式消息是请求—应答式，诊断工具应设置合理超时（例如 1000 ms）与重试次数，避免因单次超时误判为设备离线。

二、EtherCAT 诊断对象：从站健康状态的直接窗口

EtherCAT 的诊断信息不在应用层报文里，而在从站控制器的寄存器与状态机中。每个从站都有 AL Status（应用层状态）与 AL Status Code，正常运行时为 0x0008（OP），一旦进入 0x0011（SAFE-OP）或 0x0014（INIT）并伴随非零状态码，就说明该从站或其后链路出了问题。常见状态码如 0x001B（同步管理器看门狗超时）、0x0024（无有效过程数据）、0x0030（无效 DC 配置），这些码直接指向配置或同步问题。

此外，从站端口错误计数器（Port 0/1/2/3 的 CRC 错误、帧丢失）是定位拓扑断点的关键。EtherCAT 是逻辑环网，主站可以逐站读取每个从站的端口计数：若某从站的下行端口错误计数持续增加，而其后所有从站都异常，则断点就在该从站与其下游之间。诊断顺序建议是：先看主站是否处于 OP、再看各从站 AL Status、最后看端口错误计数分布，这样能快速把“整网异常”收敛到“某一段链路异常”。

三、FINS 通信：跨网络访问与旧系统兼容

FINS（Factory Interface Network Service）是 Omron 传统的命令—响应协议，命令帧由 ICF、RSV、GCT、DNA、DA1、DA2、SNA、SA1、SA2、SID 十个字节的头部加命令码和数据组成。它的优势在于地址结构清晰：DNA（目标网络号）、DA1（目标节点号）、DA2（目标单元号）可以指定跨网段的目标，配合 SNA/SA1/SA2 描述源地址，因此适合在 CS/CJ 系列与 Sysmac 混用的现场做远程访问。

常用诊断命令包括 0x0501（读控制器状态）、0x0601（读循环时间）、0x0620（读错误日志）。例如读取错误日志时，返回数据中包含错误代码、错误详情和发生时间，可用来还原“什么时候、哪个单元、报了什么错”。FINS 通常通过 UDP 9600 或 TCP 9600 端口承载，远程诊断时若走路由器，必须确认端口映射与网络号配置一致，否则会出现“能 ping 通但 FINS 无响应”的情况——这往往不是设备故障，而是路由表或单元号设置问题。

四、OPC UA 在 Sysmac 中的角色：面向信息层的统一出口

OPC UA 在 Sysmac 中不是用来替代 CIP 或 FINS 的实时控制通道，而是把 PLC 变量、结构体、诊断信息以标准化、带类型、可订阅的方式暴露给 SCADA、MES 或远程运维平台。NX102、NJ 系列等控制器内置 OPC UA 服务器，可在 Sysmac Studio 中把全局变量发布为 OPC UA 节点，客户端通过 Endpoint（如 opc.tcp://192.168.1.10:4840）连接，用 Browse 浏览地址空间、用 Subscription 订阅变化。

它的诊断价值在于“聚合”：把各站点的关键状态变量、报警字、通信质量指标统一映射为节点，上层平台无需理解 CIP 或 FINS 细节即可采集。但要注意，OPC UA 的采样周期通常为几十到几百毫秒，不适合替代 EtherCAT 的微秒级同步诊断；它更适合趋势观察、报警汇总和跨系统数据整合。安全方面应启用签名与加密策略，避免诊断通道本身成为暴露面。

五、四条路径如何配合使用

把四条路径放在一起看，它们的分工是清晰的。EtherNet/IP CIP 负责“设备级、按对象读取”的诊断，适合查身份、查链路质量、查厂商自定义状态；EtherCAT 诊断对象负责“从站级、按寄存器读取”的健康判断，适合定位拓扑断点与同步问题；FINS 负责“跨网络、面向旧系统”的命令访问，适合读取控制器状态与错误日志；OPC UA 负责“信息层、标准化发布”，适合把诊断数据聚合给上层平台。

实际排障时，一个可复用的判断顺序是：先用 CIP 或 EtherCAT 确认物理链路与从站状态是否正常，排除线缆、端口、同步配置问题；再用 FINS 读取控制器错误日志，还原故障发生的时间线；最后通过 OPC UA 把关键状态变量订阅到运维平台，形成持续观察。这样既不会在物理层问题上浪费时间翻日志，也不会因为只看应用层报警而漏掉链路劣化这类早期征兆。