Profinet周期帧实例解析.doc

精品文档PROFINET 过程数据报结构下图展示了一个 PROFINET 周期性过程数据报的一般结构：此结构基于使用 VLAN 标签的第二层以太网帧。当每个 PROFINET IO 设备和 PROFINET IO 控制器发送 VLAN 域的时候，有可能被中间的网络交换机移除掉。分析报文的时候这个需要考虑到。C_SDU 域包含需要传输的数据。带 VLAN 的以太网帧的最小长度是 64 字节，如果 C_SDU 域 的长度小于 40 字节会自动填补。APDU 状态域 包含周期计数和额外的状态字节。C_SDU 由两种类型的数据组成：IO 数据对象IOCS 对象每个数据项与一个特定的子模块相连。IO 数据对象包括过程数据和子模块的相关 IOPS。IOCS 对象仅仅包含子模块的 IOCS。一个 C_SDU 常常包含多个对象。在 C_SDU 中的过程数据的实际位置已经在连接开始的时候的 RPC Connect Service 中被参数化。在两个相邻的项目中可能被插入额外的填充值。数据项的结构由下图展示。通常 IOPS 和 IOCS 的长度为一字节。解析示例下面通过一个例子描述整个过程数据报的解析过程。解析的帧是一个输入 IOCR。提取结构信息第一步要从 RPC Connect Service 中分析出需要的结构信息。通过 WireShark 很简单就能完成。下图展示了 RPC Connect Request 和需要被用来解析一个 Input IOCR 报文的部分。红色框住的是 Input IOCR 的描述，包含了帧 ID 和在 C_SDU 里面的数据项的偏移值。相关的过程数据能从黄色框中的 Submodule Requests 提取。开始解析需要创建一个包含所有数据项偏移值的列表。这些信息从 IOCR Block Request 中提取。在本例中我们主要关注 Input IOCR。帧中帧 ID 是 0x8000。 Output IOCR 帧 ID 必须从 RPC Connect Response 帧中提取出来，Output IOCR 帧 ID 由设备分配。下图展示了期望的 Input IOCR 的 IOCR Block Request。根据上面的信息，我们创建了下表。C SDU OffsetKindApiSlotSubslotLength of DataLength of Item0IO Data00x00010x000117IO Data00x00000x000118IO Data00x00000x800019IO Data00x00000x800120IO Data00x00000x800221IOCS00x00020x0001-现在所有的偏移值都知道了。下一步就是提取各项的大小。这些长度能从 Expected Submodule Blocks 描述的子模块中提取出来。第一个 Expected Submodule Blocks 由下图展示：从这些信息中我们能得到 API 0 和 Slot 0 数据项的长度。这边导入指针是为了检查正确的数据描述元素。每个子模块都能分配一个输入数据描述 Input-Data Description 和一个输出数据描述 Output-Data Description。对于 Input IOCR 来说 Input Data Description 和 IO Data 有关， Output Data Description 和 IOCS 项 有关。Output IOCR 反之亦然。在示例中所有的第一个 Expected Submodule Block 的子模块有 0 个输入数据，1 字节 IOPS 和 1 字节 IOCS。（IOPS/IOCS 长度通常为 1 字节。）C SDU OffsetKindApiSlotSubslotLength of DataLength of Item0IO Data00x00010x000117IO Data00x00000x000100 + 118IO Data00x00000x800000 + 119IO Data00x00000x800100 + 120IO Data00x00000x800200 + 121IOCS00x00020x0001-我们用剩下的 Expected Submodule Blocks 信息完善表格：完成的表格:C SDU OffsetKindApiSlotSubslotLength of DataLength of Item0IO Data00x00010x00011616 + 117IO Data00x00000x000100 + 118IO Data00x00000x800000 + 119IO Data00x00000x800100 + 120IO Data00x00000x800200 + 121IOCS00x00020x0001-1这表格包含了一些零数据长度的 IO Data。这些 IO Data 对象表明了在 PROFINET 中，一个没有任何过程数据的子模块都被认为是一个有 0 字节长度过程数据的输入子模块 Input Submodule。解析过程数据报最后一步是用上文创建的表格解析过程数据报。下图展示了一个 Input IOCR 的特定数据报。为了正确的选择解析不仅 Frame ID 需要加入计算，而且数据报的 Mac 地址 也要加入计算，因为在 RT Mode 下同样的 Frame ID 可能被不同的设备用到。下图中，帧 106 被选择用来分析。蓝色标记的部分是包含实际过程数据的 C_SDU部分（包括填充）。基于我们的表格可以提取到如下数据：C SDU OffsetKindApiSlotSubslotLength of DataLength of ItemDataStatus(IOPS/IOCS)0IO Data00x00010x00011616 + 10x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x01 0x00 0x00 0x00 0x00 0x8f 0xff0x8017IO Data00x00000x000100 + 1-0x8018IO Data00x00000x800000 + 1-0x8019IO Data00x00000x800100 + 1-0x8020IO Data00x00000x800200 + 1-0x8021IOCS00x00020x0001-1-0x80状态值 0x80 表示相关的过程数据对于 IO Data 对象是有效的。对于 IOCS 对象，它表明相关过程数据的 “消费者” 在使用这个数据。（这个相关的过程数据发送方向相反，因此不是 IOCR 的一部分。换句话说，这个例子中 Slot 0x1 Subslot 0x1 是一个输入子模块 Input Submodule， Slot 0x2 Subslot 0x1 是一个输出子模块 Output Submodule。）备注PROFINET 过程数据交换包括了一些额外的限制，设备必须遵守这些限制来确保适当的数据交换：一些现有的 IO 控制器（例如 S7-300，S7-400）从 RPC Application Ready Request 之后不识别 IOPS 从 “BAD” 到 “GOOD” 的变化。如果遇到这种情况， IO 设备必须返回一个子模块报警 Submodule Alarm 给控制器。期望的 IO 设备应该延后 RPC Application Ready Request 直到设备提供的 IOPS 和 IOCS 设置为 GOOD。然后再下发 RPC Application Ready Request。如果 IO 设备因为特殊的原因（比如 IO 设备传输了不合法的参数）没法设置特定子模块的 IOPS 为 GOOD，设备应该设置子模块状态到 application ready pending，为子模块增加诊断然后下发 RPC Application Ready Request。RPC Application Ready Request 会包含一个 Module Diff Block 指示该子模块的问题。一些时候它可能然后又可以设置子模块的 IOPS 为 GOOD，这个时候应用应该复位子模块状态，移除诊断再返回一个子模块报警。PROFINET 过程数据模型PROFINET 定义了一个生产者消费者模型。过程数据由生产者产生由消费者接收。此外一个生产者状态和消费者状态被交换。观察角度不同 IO 控制器或者 IO 设备既可以是生产者也可以是消费者。下表试图更详细的解释这种关系。通常，过程数据从 IO