前几天在一个碳素车间的智能天车无人化改造中遇到了如下问题：
网络通讯正常但是ET200M IM153-4 Profinet IO远程站无法实现和CPU315-2DP/PN的正常数据交换，IM153-4的BF指示灯一直红色闪烁。经过对Profinet数据包分析最终实现了CPU和IM153-4的无线数据通讯。
首先对本项目做个简单介绍，本项目旨在通过伟联科技大功率高速WiFi模块实现天车的自动行走，由于天车正常运行过程中需要往复行走，因此无法通过电缆实现地面状态和控制信号向车辆上CPU的信号传输，地面设置2个IM153-4 系列IO站，每个站对应一台天车；两台天车上分别安装一套CPU315-2PN/DP和一个IM153-4系列IO站，每台天车上设置一个WiFi的Client端，地面设置一个WiFi的AP端。详细网络图如下：
上图可以看到1号天车的CPU315带了两个IM153远程站，一个是网线连接，一个是无线连接。同时还有一些变频器。2号天车和1号天车同样的配置。控制中心部署一台工程师站，通过无线实现对车上PLC程序的上下载，同时WinCC监视两辆大车的行走轨迹和运行状态。地面控制中心和车辆高度差大约15米，我们在地面通过无线调试PLC省去了来回上下车辆的麻烦。
整个系统部署完成后我们发现地面可以正常对PLC程序进行上载，下载以及在线监视。Wincc也可以正常显示车辆上的设备运行状态，但是地面的编码器以及车辆位置信号无法获取到。
经过测试网络延时均小于1ms，而且丢包率很低， 整个无线网络Ping 30万数据包基本没有丢包，这是我们判断西门子S7协议是正常的，因为PLC上下载和Wincc数据正常，那么位置信号没有只有一个可能，地面的1号IO站和2号IO站数据没有回到CPU。
这时我们 首先想到在地面测抓包进行分析，通过WireShark抓取5分钟数据包，结果如下：
这是我们发现了一条 异常数据包，源地址为SIEMENS_8a:bd:e6,目的地址为PN-MC_00:00:00,协议为LLC； 我们知道目的MAC如果后三位为00，则改地址为组播地址。LLC不应该是802.2么？通过对比我们发现所有SIEMENS的设备发出的LLDP_MultiCast（01：80：C2：00：00：0e）数据均是Ethernet II帧（参考第44条报文），协议类型为ProfiNet；唯有这条变成了一条802.3的帧（第43条）
继续往下分析，我们可以判断数据包中的 PN-PTCP为IO Device发出的组播包 ，这时我们猜测这条LLC的数据包为主站CPU发出。 为了验证这个猜测，我们讲天车停靠在离AP比较近的位置，拉一根网线讲2号IO站连接到了2号天车的CPU柜内交换机。我们继续抓取数据包，结果如下：
对于一个搞工业通讯的人出现这个结果是非常兴奋的，首先 同样的源地址， 同样的目的地址，协议由LLC变为了PN-DCP ，也就是说正常的报文是一条由主控制器下发的PN-DCP组播数据，但是经过无线传输后变成了一条LLC数据。 本是一条Ethernet II的Profinet数据帧，结果经过无线通讯后被识别为了802.3数据帧。感兴趣的朋友可以自己查找802.3和Ethernet II数据帧的区别。
到这个节点我们把正常数据帧和异常数据帧进行对比
对比发现数据经过无线通讯后帧头插入了一个长度字节 Length：58
而0x8892就变成了802.2 LLC的DSAP和SSAP，FEFE变成了LLC的控制域。
正常数据包帧头为0x8892代表这条数据包是一个Profinet数据包，FEFE为ProfiNET RT的帧ID，FEFE代表这是一条DCP（Dynamic Configuration Protocol）数据包，紧跟着为ProfiNET组态中的站点名称和端口号。Port 5922这个对西门子熟悉的工程师一定不陌生，这个就是ProfiNET网络组态时的网络端口。
最初我们认为造成这种现象的原因应该是 802.1d的限制，802.1d规定网桥必须过滤如下MAC地址：
MAC address Protocol
01-80-C2-00-00-00 Spanning Tree (STP/RSPT/MSTP)
01-80-C2-00-00-01 Ethernet Flow Control (pause frames)
01-80-C2-00-00-02 Link Aggregation Control Protocol (LACP)
01-80-C2-00-00-03 802.1X Port-Based Network Access Control
01-80-C2-00-00-08 Provider Bridge protocols (STP)
01-80-C2-00-00-0D Provider Bridge protocols (MVRP)
01-80-C2-00-00-0E 802.1AB Link Layer Discovery Protocol (LLDP)
而WIFI桥接刚好符合802.1d网桥的规定，使用上述MAC地址的协议，都会被网桥过滤掉，而最后一个地址01-80-C2-00-00-0E这个刚好就是SIEMENS的LLDP-MultiCast，也就是PN-PTCP。但是在下面这张图中我们发现了SIEMENS_34:63:f5的这个地址，这个说明车上IO Device的数据通过无线正常发送到地面了。这也就说明了
LLDP数据包是可以通过无线网桥的。 第一种判读排除。
组播也能传送，LLDP数据也能经过无线传到地面，那还有什么原因会导致数据包发生变化呢？
根据以往经验，我们将故障原因定位在了 无线网桥对组播数据的处理上。 ProfiNET IO协议将所有的实时数据全部封装在了组播数据包内，因此我们将组播数据做了直通，启用IGMPv3后，重新将无线模块接回网络，所有IO数据通讯均都正常。
本案重点难点在于通过无线实现ProfiNET IO的无线网络数据传输，而且网络内是四个ProfiNET IO Devices和两个控制器实现数据交换，还有一点就是一个无线网络内运行着两个工业以太网协议，S7协议和ProfiNET协议。
最后也向大家证明了不是只有SIEMENS的无线网桥才可以进行ProfiNET RT协议的无线传输。
閱讀更多 川哥工控界自媒體 的文章
