大家好，感觉好久没有和大家见面了，西门子PLC通信原理探秘系列告一段落了，收到了众多网友的好评，大家都对时间片和CCP通信的概念耳目一新，觉得有所收获，并希望我可以再接再厉给大家继续奉献精彩内容。在这里向大家表示感谢，感谢大家给予的正面评价和鼓励。可是技术的积累是需要时间的，我相信时间会给大家带来精彩！

在我33篇《西门子PLC通信原理探秘》的第一篇故事中，我曾说过，PROFINET是我在西门子技术支持的起点，最初我是从PROFINET开始，或者说我是做PROFINET的第一人。多年研究PROFINET，其实我有很多话想和大家聊聊，甚至曾经想出一本PN的书籍，把自己关于PN的奥秘一一呈现给大家。

PROFINET就像是我的亲密伙伴，因为在西门子，他的面市和我的入职几乎是同时开始的，我们是一起成长的。最初的PN产品，例如ET200S只有一个PN端口，只能支持RT，设备连接只能通过交换机。最初的我，是技术支持团队的一个新人，是网络通信的一个菜鸟，完全不懂通信理论。然而放在同事桌子上的PROFINET培训文档，吸引着我让我随手翻开，像是冥冥中注定，他和我注定在我的职业生涯中深深的纠缠在一起。我们也相互的成就着，通过我的努力，他给我们中国客户的生产带来了翻天覆地的变化，通过他的发展，也给我的职业生涯带来了深远的影响，那么他有什么奇妙之处呢？

首先，在技术上，PROFINET基于以太网，也就是由于以太网，使之能够具有快速的通信速度和灵活的拓扑结构，而PN就是以太网上的实时协议集合，就和TCP是以太网的协议一样，仅此而已。但是这对于企业生产就不同了，因为在PN之前，以太网是不能延伸到现场级的，而如今以太网一直延伸到现场的末端，带有PN接口的传感器和执行器比比皆是。以太网的安装确实给用户带来了诸多的便利，然而，由于用户大都想着就近连接交换机即可，这种可能导致混乱的连接拓扑，还有就是交换机产品的选择，错误的选择同样会给用户生产带来一些问题，这两个看似很小的问题，却可能会给企业生产带来毁灭性的伤害。

早年去一家钢厂，骨干网使用了冗余环网，正常生产了一段时间，却突然全网瘫痪，导致高炉停产，对于钢厂来说这是一个非常大的事故了。而现场的问题解决却是很简单，原因是冗余环网使用了西门子的SCALANCE X交换机，然而冗余管理器RM却使用了第三方的交换机，那我还说什么呢？前些天，去了另外一家钢管厂去做预维护，询问网络的拓扑连接是如何的，回答是不知，这是中国用户目前普遍存在的问题。通过PRONATA进行现场网络拓扑的扫描，竟然发现网络拓扑出现两个环网，而且是现场级的，也不知什么原因鬼使神差的让生产可以正常进行，我们知道环网会产生广播风暴，导致全网瘫痪。可是由于生产还在继续，我们无法确定真正的原因是什么，只能告诉用户这种环型链接风险极高，需要尽快整改。

其次，对于PROFINET RT通信，我想这是中国用户最常用的PN协议，因为配置简单，只要用过PROFIBUS DP就能做很快的转换。然而用户往往会有两个问题，一个是不清楚如何选择交换机，选择的依据是什么？另一个是不清楚分布式IO最多能串联多少个，级联深度的依据是什么？

对于第一个问题，我给用户传达的信息就是只要是交换机都支持PROFINET，然而并不是所有的交换机都适用，这种前后矛盾的话，大家肯定会觉得疑惑不解。PROFINET使用百兆全双工的技术，那么交换机必然是唯一选择的连接部件，而我们在使用PN RT协议的时候，都知道RT通信的报文是带有优先级的，也就是含有优先级是6（最高为7）的VLAN标签（其ID=0），这个标签使之PN数据在网络链路传输时可以“横行霸道”，因为除了MRP冗余环网之外的网络链路上的数据没有优先级比它高的，其它数据难以望其项背，这样才能最大程度的保证它的实时性。那么如果你选择了例如SCALANCE X300/400系列的交换机用来连接IO设备，那么VLAN标签的优先级的意义就消失了，因为这些交换机默认支持VLAN，而这些交换机恰恰判定VLAN ID=0的数据没有优先级，也就是说此时的PN数据只能和普通数据一样，不再被优先转发，这意味就显而易见了。第二个问题，可能是困扰大家最多的问题，因为它影响现场到底如何安装布线。到底能级联多少？我的答案就是能带多少IO设备就能级联多少IO设备？然而我们需要考虑线型网络末端的IO设备的刷新时间的大小，这就需要一个公式了，也就是说一个IO报文从PLC侧发出，经过若干台交换机，这些交换机是支持C&T或是S&F，那么这个公式就是报文的传输时间，加上经过各个交换机的延迟时间，达到最终的设备。这个时间才是你参考的Update time的时间，如果不能满足你的实时性要求，那么这台设备需要在线型拓扑中靠近PLC，也就是你的IO控制器。

最后，我想谈的就是PROFINET网络如何诊断了，这个是用户经常忽略或者无法正视的问题，因为一旦谈到诊断，那么必然需要全面的IT知识，不像前面所描述的，仅是需要组态和计算，从基本的Ping指令到Wireshark的使用，这些都是必备的。但这些往往是用户缺乏的。具体诊断PN网络的方式有很多种，那是根据不同的故障现象采取不同的方法。这里和大家谈谈用户所面临的经常丢站的故障。

丢站的根本原因就是IO数据没有在看门狗时间内出现，也就是超时了，这时会报丢站，OB86被激活。那么什么原因会导致IO数据在看门狗时间内不能出现，主要是两种原因，第一种就是网络拥堵严重，数据不能在看门狗时间内到达IO设备，那么这种情况使用Ping指令就可以来判断网络链路的状态；第二种就是数据发生畸变，可能是由于干扰或者安装的线缆短路所致，也就是IO报文的CRC检验出现错误，这种情况可以通过Step7在线查看分布式IO的端口的Statistics或者登陆管理型交换机的网页查看丢站IO设备所对应的端口的Statistics，再或者对于S7-1500来说使用LPNDR功能块来读取对应IO设备的端口的Statistics，来查看是否存在CRC错误。如果存在CRC错误，那么导致的原因就是前面我说的两种原因，干扰或者短路造成的，那么就去查EMC和线缆的状况。当然，Wireshark工具是诊断PN网络的最最重要的工具，当你具备IT知识的时候，建议你使用Wireshark这个工具去检测和发现网络故障，因为它是终极利器。

关于PROFINET技术，其实它包罗万象，涉及各种IT知识，当你想理解它时，你就需要理解终端设备，例如：PLC和分布式IO，其实西门子PLC通信原理也是来源于我对PN的研究，然后理解TCP协议，路由协议等等，也就是这一根绿色的网线使我在技术上越走越远，越走越宽。这里我仅仅提到了PROFINET技术的冰山一角，深奥的理论主要集中在IRT上面，需要对其设备集成的交换机内部要有全面的理解，因为IRT需要对时，各个时间片段的计算是非常关键的，在这里我无法一一的给大家说明。而现在由我的同事，网络专家冯学卫先生正在网上论坛主持PROFINET通信探秘技术π的活动，他是一位非常优秀的工程师，对于IT和各种网络协议都非常的了解，我们经常在一起讨论关于网络，PN，通信的各种问题，对各种技术细节进行深入的剖析，例如Step7中IO RT的时间预留后台是如何计算的等等。大家如果想

在谈到PROFINET技术之前，我想和大家先说说Wireshark，因为只有通过Wireshark软件进行报文捕捉，才能更好的理解PROFINET的工作原理，后面的原理和技术的展示，大家才可能明白和理解。

Wireshark这个软件，相信很多工控人还是知道的，不过用过的人可能就相对少了，至于能够使用该软件去诊断和评估捕捉的报文质量可能又是少之又少。不过学习都有一个过程，在这里我强烈的建议大家只要你接触PROFINET，接触工业以太网，Wireshark是首选，最重要的诊断工具，没有之一。能够掌握PROFINET和工业以太网，Wireshark是关键！而这里我不和大家讲解如何使用Wireshark这个软件，因为网上相关的教程很多，大家有时间可以去看看。

这里我给大家讲解一下通过什么样的硬件与Wireshark匹配以获得你想要的结果。使用安装有Wireshark的PC，通过本身的网卡可以捕捉该PC与外部设备之间通信的所有交换的数据信息。但是不能捕捉设备之间的交换的数据报文，只能借助其它设备，有经验的工程师应该知道借助的设备就是交换机了。如下图展示。两台1500PLC进行通信，装有Wireshark的PC可以通过此交换机进行捕捉通信报文，此时交换机需要支持一个功能，那就是端口镜像功能，也就是说要选择管理型的交换机。例如，设置交换机Port 1为Monitored, 设置Port3为Monitor端口，那么流经端口1的数据就像照镜子一样出现在端口3，即端口3上出现和端口1上一样的数据，所以通过安装有Wireshark的PC就可以捕捉到两台1500PLC之间交换的数据，进一步可以诊断两台PLC之间通信的状态和故障。

我想这是大家经常使用的一种现场捕捉报文的方法。然而这种方式有一定的弊端，需要大家提前了解，这样才能更好的进行报文的分析。

1， 交换机会对错误的报文进行过滤，所以网络中出现的错误报文是不会被捕捉到的，这意味在这种条件下，你可能无法判断错误报文所带来的原因，例如EMC干扰。

2， 带宽的问题，图例中交换机的端口是百兆全双工，那么对于端口1和端口2的数据交互的带宽总量是200M（发送和接收的总和），因为端口1的数据全部被映像到端口3，而端口3的带宽最多是100M，这意味着当端口1 的网络负荷超过50M的时候，捕捉的报文就会失真。

3， 当捕捉PN IO RT的报文时，需要对PC侧网卡进行设置，因为默认的状态下网卡会对报文中的VLAN标签是去除的，只有对网卡进行正确设置才能看到报文中的VLAN标签。

4， 不能使用普通的交换机，例如SCALANCE X208进行捕捉PN IRT的报文，需要使用IRT的交换机，然而只能捕捉一侧的数据报文，要么是发送的，要么是接收的，不能同时接收到发送和接收的数据。

5， 端口镜像不能一定保证被捕捉数据顺序的准确性，因为照镜子的过程需要复原，这个过程交换机可能会对报文顺序的处理产生错误。例如下图是正确的TCP的3次握手的报文顺序。

而端口镜像的方式可能扑捉到错误的TCP3次握手的结果。例如下图中对比正确的上图中的[SYN]和[SYN，ACK]两个报文的顺序发生了变化。这一点需要你事先要理解协议的工作原理，而且发生这种情况要有个心里准备，知道这是什么原因造成的，而不是认为TCP连接发生错误！

那么说了这么多弊端，大家可能就会说这种方式我不能用了，或者这种方式没有什么用啊等等。这里我需要和大家澄清的是这种方式是目前性价比最佳的方式，没有之一。因为首先在你的网络中，管理型的交换机可能随处都有，需要设置端口镜像就能进行报文捕捉，即使没有，备用一台管理型交换机，需要监控哪一段网络，就放置到哪里，简单方便。其次，我所说的弊端都是有条件的，例如VLAN标签的去除，首先你要想我是否需要捕捉到VLAN标签，它对我的用处是什么，还有带宽问题，你确信你要监控的网段带宽会超过50M？我想99%的现场不会出现，更何况你也不会让它出现。所以去除这些在某些条件下的弊端，这是目前对于大家最好的报文捕捉方式！

当然，西门子也有其它方式解决上述出现的弊端。在这里给大家推荐一个西门子专业的捕捉报文的硬件和软件，它们就是硬件为BUS ANALYZER XM，软件为Bany Scope。硬件实际上就是一个TAP，软件用于网络数据分析，如果需要查看报文，仍然需要使用Wireshark工具。具体的连接方式，这里给大家看一个简单的网络拓扑的实例。

对于使用BUS ANALYZER XM模块时，需要在PC侧安装Bany Scope软件配合使用。因为硬件模块内部集成TAP，捕捉报文的结果即所见即所得，所以交换机捕捉报文时带来的上述缺点都不复存在了。

刚开始接触PROFINET的时候，还不知道从哪里入手，东瞧瞧，西看看，最终觉得还是从协议入手，可是那个时候的我也是刚刚入职不久，说实话，协议是什么不是很懂。胶片和手册中都提到PROFINET协议和TCP协议可以并存，里面也提到和TCP协议做对比，还提到建立通信连接是通过UDP协议的，而PN IO RT通信是不需要TCP和UDP协议的，当时看到这样的话，也是一头雾水，到底PN和TCP/UDP协议到底有什么关联呢？两者到底是怎样工作在PN通信中的？带着这样的疑问，我想刚刚使用VB通过Socket来编写TCP协议与TDC通信，还是先了解一下TCP/IP协议吧，毕竟我还是觉得自己更加的熟悉，（就自以为是了，哈哈！），然而却陷入了TCP/IP的陷阱，这是一个比PN难百倍的协议。经历在技术支持工作超过15年，我也不敢说我精通TCP/IP协议，我只能说略懂，嗯，对，略懂而已！

手册和胶片中常常说TCP的协议特点，如下：

遵循RFC793，是开放式协议

可靠的，面向连接的，字节流的点对点通讯协议

IP即网际协议，负责将消息从一个主机传送到另一个主机。在传送的过程中可能被分割成一个个的小包

在接收端收到后再根据顺序号将其正确地还原，保证了数据包在传送中准确无误

数据包正确的到达后，发送方得到这些分段的一个应答

错误，重复以及丢失会重新发送数据

通过“滑动窗口”进行流量控制

通过端口号可实现多路复用

下面我就通过对TCP/IP略懂的知识，给大家介绍一下，TCP/IP协议是怎样的一种协议。

作为开放式协议，显而易见，你也可以用，我也可以用，无论是西门子还是第三方设备，只要支持TCP/IP都遵循RFC793，即都可以相互通信。对比S7协议，这是西门子自己独有的协议，只有西门子自己支持自己产品间的通信，所以不是开放式的协议。

面向连接，指的是TCP/IP通信是要先建立连接的，然后才能数据交换，建立连接的方式就是我们常常听到的所谓的三次握手。字节流的通信，大家会觉得这三个字很简单，首先，其它协议交换的数据信息都可以以字节为单位，那么关键在于“流”这个字眼。看到这个字，大家的脑海里闪现的肯定是液体，或者首先想到的是水，那么TCP/IP似水一样的流动，向接收端发送字节流，既然像水，接收端就像一个容器，接收这些水，那么你会区别这里面的水，哪些是先倒入的，哪些是后倒入的？显而易见，你无法区分，所以才会有你在TCP/IP通信的时候，处理可变数据长度时的尴尬。

对于IP协议，这个TCP协议为啥还要关联IP协议，总是凑成TCP/IP协议呢？这个IP协议的作用是大的很呢，可以说法力无边！这要从ISO/OSI参考模型的第三层说起，第三层IP的主要作用有两点，第一点是选路，也就是我们常说的路由，帮助IP数据从一个网段路由到另一个网段，这时IP地址就有用了。第二点就是分片，作为工控工程师，我们在做以太网通信时，应该知道以太网帧数据的长度是46-1500Bytes，这是由以太网的物理特性决定的，通常1500Bytes被称为数据链路层的最大传输单元，即MTU。IP的数据报文从理论上最大可以传输64KB数据，但是在以太网上的传输数据长度却不能，所以IP数据报大于1500B时，即大于MTU，发送方的IP报文即会被分解成若干片，这样每一片都小于或等于MTU的大小。而接收方则对这些报文的分片进行重组。然而，由于可能网络中各种状况的出现，例如其中一片丢失，整个IP报就不能完成重组，整个IP报就会丢弃，所以IP报是不可靠的传输协议。

那这时大家会有疑问了，不是说TCP/IP是可靠的传输协议吗？这到底是怎么回事儿？那需要我们说说TCP到底是怎么工作的，TCP采用了尽量分片的方法，避免IP在MTU分片所造成的不可靠的数据传输，这样也就避免了IP分片所造成数传时的数据丢失，增加重传数据包的机率。前面提到TCP通信需要建立通信连接， 3次握手，在握手的时候，双方就协商了MSS的大小，即Maximum Segment Size，也就是双方确定TCP最大分节长度。这个值用来告诉对方，能够发送TCP分节的大小。而这个值是取其链路层MTU大小减去TCP头部大小和IP头部大小，即MSS=MTU-TCP头部大小-IP头部大小。这样对于以太网的MSS的最大长度为=1460Bytes。这样TCP的数据每次发送都不会超过1460B，到了数据链路层不会超过MTU的大小，那么IP报自然不会进行分片传输，这样就减少了TCP/IP重传的机率。TCP可靠的数据传输，除了MSS的协商机制，那么还有一个重要的特性就是序列号确认机制，这两个特性基本上可以保证数据的可靠传输。在TCP分节报文中，包含顺序号和应答号的字段，数据重传和数据应答机制的基本前提就是对每个传输字节进行编号，即顺序号Sequence Number。顺序号表示发送方已发送字节流的计数，接收方在成功接收到一个有效数据包后，发送一个确认应答数据包给发送方，应答数据包中包含的应答号Ack Number即指已接收的数据长度+1，或者说已接收到的数据中的最后一个字节的序列号+1，表示已期望接收的下一个字节的序列号。这个机制可以解决诸如数据在传输过程中破坏的问题，处理接收重复数据的问题，数据丢失的问题，以及处理接收端数据乱序的问题等等来保证可靠的数据传输。

对于“滑动窗口”，这也是TCP/IP通信的一个特点，在TCP通要建立通信连接， 3次握手的时候，不仅仅双方协商了MSS的大小，也协商了Window Size的大小。接收端的容器，水总会有注满的时候，所以通过不断向发送端告知容器还有多少的剩余，也就是自己窗口的大小，通知发送端，根据我的接收能力，你还能发送多少数据给我，这就是流量的控制。这个流量控制对于TCP/IP通信的通信速度影响很大，如果你需要你的TCP/IP通信快速，那你就需要保证你的接收侧的滑动窗口始终有富余，唯一的办法就是接收一定要比发送快！

对于端口号的多路复用，这里给大家举一个例子，1500PLC是集成Web Server的，你可以通过一台PC1的浏览器浏览这个网页服务，默认的端口是80。当然你也可以同时使用另外一台PC2浏览这个网页服务，默认端口仍然是80。这个端口就是在被复用。

当然除此之外，还有许多定时器用于TCP/IP可靠的数据传输，例如Keepalive等等，这里就不一一赘述了。然而当看了五花八门的各种概念和协议机制，给了我乱花渐欲迷人眼的感觉，对于理解PN似乎没有什么帮助啊，但是最起码我知道了协议这个概念和工作机制。那么PN也可以套用这些理念的，至少可以做个对比。

TCP的一些同胞兄弟，例如UDP，ISO on TCP，以及S7协议，这些协议我觉的也有必要提一提，在我们正式进入PN的世界的时候，我们先做个铺垫吧。毕竟我们不能厚此薄彼，哈。只有这样，大家再看Profinet的时候，我觉得大家会对一些概念不再陌生，大家会更容易理解为什么Profinet是这样的。希望大家那个时候会说：“啊！原来如此！”。

首先从ISO/OSI参考模型来说，TCP/IP，ISO on TCP以及UDP协议都位于参考模型的第4层，即传输层，而S7协议基于ISO on TCP位于第7层，即应用层。层级越往上的协议，通常协议的安全性和可靠性就越完善，这是由各个ISO/OSI的各个层次定义的，当然层次越多，通信的速度也会相应的变慢，因为数据从上之下，或者从下至上打包和解包是需要时间的。顺便说一句就是这个ISO/OSI参考模型不仅仅是针对的以太网的通信，是关于所有协议的，例如PROFIBUS-DP，它是基于RS485的，DP协议也有ISO/OSI参考模型的概念，而DP协议位于第7层。

虽然S7没有第5层（会话层）和第6层（表示层），但是完善的应用层协议使S7协议更加适用于各种SIMATIC场合，S7协议就是完美的选择。首先在通信的数据量上与TCP/IP持平，最高支持64K字节的数据传输；其次由于其应用层协议，故障报警响应及时，例如发生断线的情况下，两侧的通信即停止，产生报错信息。然而再好的事物也有弱点，首先，数据一致性的范围比较小，对比TCP，S7的数据一致性从240B（S7-300）到480B（S7-400）再到960B（S7-1500），范围较小（这里没有细节讨论，这些数据实际上是S7的PDU大小，并非真正数据一致性的大小），而TCP的数据一致性却高达8KB（这个可是纯数据的长度），其次，由于具有更高的ISO/OSI的层次，相对TCP协议来说，处理应用层的数据的时间相对较长，也就是说通信会慢些，然而这个时间对比会随着通信数据字节的长度而随之延长，可以肯定的是毫秒级的差别。总结来说，瑕不掩瑜，S7协议通信是一个非常优秀的协议，非常实用在SIMATIC产品之间通信。

对于TCP/IP来说，对比S7，有些相关的优点和缺点却调换了位置。先说优点，首先TCP/IP是面向连接的，开放的以太网协议，这个协议不仅是SIMATIC的产品在使用，而且第三方的产品也在大量的使用，所以对于与第三方设备通信，TCP/IP协议绝对是首选协议。然而缺点也是很明显，首先，对于数据一致性虽然长度比S7要长很多为8KB，但是S7的数据一致性的数据却可以在CPU的一个周期中传输多次，而TCP/IP的8K数据一致性数据只能在CPU的一个循环中进行传输，也就是说一个CPU循环周期只能最大传输一个TCP/IP的8KB一致性数据，这也意味着TCP/IP通信的时间取决于CPU的周期。第二个缺点就是断线报警的问题，许多用户使用时间节拍的方式来检测通信是否正常就是这个原因，因为TCP工作不会因为断线而停止，即使断线，Done信号仍然会产生，而且产生报警与Keepalive时钟密切相关。总结来说，除了最后一个缺点，TCP/IP仍然是值得大家选择的最通用的协议。

TCP协议来说，只是在第4层的TCP上加载了ISO协议，原本ISO也是第4层的协议，两者的结合实际上就是相互利用了两者的最大优势。对于ISO协议是没有第3层的IP协议的，所以不能路由，基于IP协议，便可以路由；对于TCP协议，本身是流式传输协议，在可变长度的数据传输时，数据对位会出现问题，这样ISO协议的加入就避免出现这样的问题，因为ISO作为最佳的可变长度的协议，在报文中具有数据长度信息，这是TCP所不具备的。虽然TCP/IP在数据通信的过程中可以使用AD_HOC方式，但是真实的可变长度却是1460B，当超过这个数据长度时，数据对位会非常棘手，此时建议大家选择ISO on TCP。至于其它特点两者皆相同。

对于UDP，它是一个优点和缺点都非常明显的协议。首先它是不安全的传输协议，这意味着数据在网络中的丢失或者出错是不能重传的，然而在某些的小型局域网内，是非常建议使用该协议的，因为网络不会出错，不会有大量数据包挤占带宽等，UDP是非常快速的，此时无需人为检查错误，只要保证网络纯净。然而理想情况下毕竟占少数，要想安全可靠的数据传输，需要人为通过程序来保证，也就是通过程序来实现TCP/IP协议的可靠传输。UDP通信的另外一个好处就是适用组播通信，即数据从一个设备发送到该组中的其它设备中。总结来说，对于工控网络环境，使用UDP协议需要慎重，需要具有良好的网络知识和编程能力，才能驾驭UDP协议通信。

谈了这么多，还是没有进入到正题，我也觉得很难，很难进入正题，总是想着如何给大家带来一个不一样的Profinet，让大家领略到Profinet的真谛。期望在下一个故事，希望！

言归正传，手册上常说，PROFINET是开放的，标准的，实时的以太网标准，基于快速以太网。从概念的角度，对于10Mbits/S的以太网是标准的以太网，现在几乎看不见了。因为它被更快速的带宽100Mbits/S的以太网所取代，称为快速以太网。所以我们现在在谈自己的工业网络时，实际上都是基于快速以太网100Mbits/S，只是我们简单的称其为以太网。从技术术语或者专业概念的角度来说，我们要严格的区分使用的是以太网还是快速以太网。

对于百兆带宽，我简单的描述一下，就是每秒钟传输个位，这就是对于带宽的简单描述。或者我们可以变形这个带宽的单位为12.5MBytes/S，即每秒钟传输个字节。我们知道以太网中传输都是数据帧，数据帧的结构如下，那么用户数据从帧结构上看是46-1500Bytes字节长度，但真实的用户数据取决于使用什么样的通信协议，例如，TCP/IP协议通信，那么报文帧中的User Data部分包含IP报文头（20字节），TCP报文头（20字节），这样真正的用户数据最大为1460Bytes（）。所以报文除了协议数据单元PDU的报文头，以及除了帧部分的其它字段的字节，我们姑且认为快速以太网中的真实数据带宽约为10MBytes/S（也可考虑除去交互帧，例如：用于连接的帧所占的数据带宽）。利用这个数值有利于与用户交流时，大家谈的是同一个概念，因为我们在谈论的时候都是在说我有多少AI/AO数据或者你要传输给我多少字节的数据。

这些描述都是数字的概念，大家可能还是不能有感性的认知。可以给大家举一个PLC通信的例子，例如：OUC的TCP/IP通信。使用两台CPU1516-3PN/DP，都不采用最小的CPU循环周期选项，也就是程序有多快就运行多快。两个CPU之间使用TCON建立一个TCP的连接，发送方使用1个TSEND发送64Kbytes数据，这是TCP所能传输的最大字节数。自然，接收端使用1个TRECV来接收64Kbytes。对于发送端的REQ触发，采用最快的触发方式，例如使用M0.0的常闭触点输出至M0.0的线圈，即使用M0.0进行触发，这样REQ每隔一个CPU周期上升沿出现一次。这样实际上只是这样一个连接的投入，网络带宽就将近20Mbits/S。看下图！这样大家知道了原来这样的通信组态和编程会占用四分之一的百兆带宽！所以根据大家的网络拓扑情况，在组态和编程TCP/IP或者S7通信的时候，尤其是快速发送大量数据时需要注意带宽的问题。

这样在我们做PROFINET通信的时候，同样也要有这样的概念，设置的Update Time时间越短，IO设备的IO模板越多，占用的带宽就越大。但不会占用所有的百兆带宽，因为PROFINET规范中规定会预留50%的带宽用于非实时的数据，例如TCP/IP通信。所以我们在设置IO的Update Time的时候要根据实际情况来进行设置，如果需要IO的快速的响应，那么Update Time必然要符合工艺要求，理论上越快越好。如果读取现场的温度或者压力等模拟量的变量，那么可以适当的延长Update Time时间，这样可以减少对网络的带宽的占用。

我们再把目光投向PROFINET的报文帧的结构，除了加入4个字节的VLAN Tag，实际上和标准以太网报文之间毫无区别。大家都知道VLAN Tag的作用就是增加PROFINET实时通信的实时性能。

而这里还有一个12个字节的字段，就是最前面的MinNRTGap，它表示帧和帧之间传输的最小间隔时间。实际上任何的以太网通信中都会存在这个字段，只不过这个字段可能会>12Bytes长度。再回到前面的百兆带宽的单位100Mbits/S，通过换算可以知道以太网传输一个字节的时间为1000000us/12.5x.08us。那么对于一个PROFINET的最小帧的传输时间的计算如下，（12+7+1+6+6+4+2+2+40+2+1+1+4）x0.08us=88x0.08us=7.04us。而7.04us就是PROFINET网络中带宽的概念！那么为什么在PROFINET通信中要提到且使用这个MinNRTGap概念？还有为什么在PROFINET这里采用传输时间的概念来理解带宽，而为什么不采用前面提到的Mbits/S的概念呢？这些问题我会在下一个故事中逐步展开，而这里再引用一张来自TIA Portal中组态PROFINET通信时，大家常常看见，可能却没有注意，或者没有深思过的关于PROFINET带宽预留的组态计算的结果，看看大家想到了什么？想想0.704%是如何而来？

提到了带宽的两个单位，一个是Mbits/S，例如100MBits/S，就是我们常说的快速以太网的百兆带宽；另外一个是us，例如7.04us，就是最小PROFINET RT报文在快速以太网上的传输时间。而在Step7中显示0.704%，表示的是循环数据的计算带宽，即在1ms中PROFINET RT报文所传输的时间为0.00704ms，那么就占用了1ms的0.704%。

这里有三个问题我们需要考虑清楚，第一个问题，1ms表示的什么？是否是用户定义的IO的刷新时间？第二个问题，PROFINET RT报文的传输时间计算为什么要考虑MinNRTGap；第三个问题PROFINET计算的带宽（Calculated bandwidth）为什么以时间为单位。

我们先看第二个问题，这个答案我简单的描述一下，与传统的TCP/IP，或者用户常常使用的S7通信不同，PROFINET的循环数据，例如RT数据，IO控制器在一个Send Clock中发送多个RT报文时，这些RT报文是肩并肩、连续发送出去的，那么大家可能会回想做TCP/IP通信，TCP的报文不也是连续的吗，但是这些报文不是肩并肩，也就是报文和报文之间的时间间隔时间都比较长，所以这个NRTGAP可以忽略不计，而PROFINET由于其实时性的要求，RT报文都是肩并肩排队发送出去的，这时RT报文之间的间隔就变为MinNRTGap，也就是12个字节，是报文之间最小的时间间隔。所以PROFINET循环数据的计算传输时间7.04us就需要考虑这12个字节。

然后再回答第一个问题，因为在问题2的解答中，我提到了Send Clock这个概念，而我们在Step7组态PN IO通信时，大家可能会经常看到，那么它和Update time之间的区别或者有什么关联呢？

先描述一下Send Clock，这个词中文翻译就是发送时钟，用来表示在一个发送时钟的时间间隔内提供RT/IRT数据的能力，或者说是发送RT/IRT数据的最小时间间隔，再者说是RT/IRT数据的出现本质上是在Send Clock时间内。说来说去，大家可能还是不理解，那么我们再结合Update （2ms=1msx2），2就是这个例子中的减速比。也许大家看过详细的PROFINET标准中关于这方面的计算，还有Sendclockfactor，Phase等其它概念，这些放在一起计算比较复杂且难以理解，这里我所描述的公式更便于大家理解。PROFINET的Send Clock就是发送RT数据的时间单位，为了优化带宽，RT数据会自动分布在多个Send

大家可能还是不能有感性的认知。结合上图给大家展示一个实验的结果，使用S7-1500作为IO控制器，（其它PLC也可以），使用两台ET200SP，在IO控制器侧设置Send Clock为1ms，IO设备侧设置的刷新时间为2ms，那么可见下图左侧的实时数据的带宽。如果在IO控制器侧设置Send Clock为2ms，IO设备侧的刷新时间仍为2ms，那么可见下图右侧的实时数据的带宽。由此一目了然！

我再具体解释一下，大家可以仔细观察Wireshark中的IO Graphs中的记录带宽结果，因为只有2个站，且数据较少，带宽不高，左侧图中带宽约为512bits/ms，右侧图中带宽是震荡的，最高为1025bits/ms，如果大家抓包请注意我图片中设置的单位和缩放后的刻度。右侧图中的带宽震荡的根本原因是2ms的Send Clock中发送2个IO RT的数据是肩并肩的出现的，如下图。

然后我们再谈论第三个问题，结合第二个问题的回答，PROFINET的带宽计算以时间为单位是由于在Step7中计算RT或者IRT数据占用的带宽的大小的基数是Send Clock，且Send Clock的单位是时间，所以计算的RT/IRT预留带宽的大小就以时间为单位。而这个预留带宽的计算是基于IO控制器的接口输出RT/IRT数据的带宽计算结果。还是以上述的例子，在Send Clock的时间为2ms，那么2个RT数据在一个Send Clock中的发送是肩并肩的，下图Wireshark中MAC地址:F1是IO控制器，:8A和:41分别是两台IO设备。根据记录时间，结果恰恰是7.04us，那么两个RT实时数据的带宽预留时间为7.04x2=14.08us。

以上就是我对这3个问题的解答，这里我想和大家讨论一下，根据故事中的知识，如果有4个IO设备，其中的1号设备的刷新时间是8ms，2号设备的刷新时间是4ms，3号设备的刷新时间是2ms，4号设备的刷新时间是1ms，而IO控制器中设置的Send Clock为1ms，那么大家是否可以做出RT数据的时钟分布图，大家可以尝试一下来理解Send Clock和Update Time之间的区别。