技术论坛

 我与PROFINET不得不说的事-04对比

返回主题列表
作者 主题
赵欣
奇侠

经验值: 5576
发帖数: 387
精华帖: 52
楼主    2021-02-19 13:59:10
主题:我与PROFINET不得不说的事-04对比 精华帖 

和大家聊完了TCP/IP(我与PROFINET不得不说的事-03协议-技术论坛-工业支持中心-西门子中国 (siemens.com.cn)),我想可以聊聊PROFINET协议了,然而,突然又想到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仍然是值得大家选择的最通用的协议。

 

那么对于ISO on 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的真谛。期望在下一个故事,希望!

 

您是否还有疑问呢,请点击下面的留言区,我们可以相互交流。

读万卷书 行万里路
www123456
至圣

经验值: 12225
发帖数: 2431
精华帖: 86
1楼    2021-02-19 18:12:11
主题:【故事】回复:我与PROFINET不得不说的事-04对比
看来2个设备直接网线相连UDP通信,做好接头,速度是非常快的,因为省去了一些额外的传输开销 ,但可靠性与快速性之间就得自己平衡了,不会引起事故或影响安全的特殊场合是可以使用的。
yzm_cumt
至圣

经验值: 18166
发帖数: 2649
精华帖: 14
2楼    2021-02-24 09:53:25
主题:回复:我与PROFINET不得不说的事-04对比

有没有UDP应用的例子,能不能给介绍一个,看看具体的应用

sometimes you have to be your own hero!
yzm_cumt
至圣

经验值: 18166
发帖数: 2649
精华帖: 14
3楼    2021-02-25 09:15:41
主题:回复:我与PROFINET不得不说的事-04对比

在请问一下,这句话什么意思?“S7协议就是完美的选择。首先在通信的数据量上与TCP/IP持平,最高支持64K字节的数据传输;其次由于其应用层协议,故障报警响应及时,例如发生断线的情况下,两侧的通信即停止,产生报错信息。”为什么会这样呢?谢谢

sometimes you have to be your own hero!
每个眼神都只身荒野
侠圣

经验值: 2232
发帖数: 205
精华帖: 2
4楼    2021-02-25 21:54:29
主题:回复:我与PROFINET不得不说的事-04对比

感谢分享,获益了不少

赵欣
奇侠

经验值: 5576
发帖数: 387
精华帖: 52
6楼    2021-02-26 09:56:13
主题:回复:我与PROFINET不得不说的事-04对比

yzm_cumt:2楼2021-02-24 09:53:25

                   

有没有UDP应用的例子,能不能给介绍一个,看看具体的应用

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

回复有些晚,抱歉!

关于UDP的缺点我在文中已经提及,这里还需要强调的是作为长度1472个字节的UDP报文只有一个帧在网络上传输,那么如果网络环境良好,不会出现丢包的现象,但是也会有其它的风险,就是接收端的接收速度问题,如果接收的慢,数据可能被覆盖,这就是没有流量控制的原因。

如果超过1472个字节,就会分片,除了网络丢包造成UDP通信失败,同样后一个报文的超车,同样会导致UDP报文无法恢复原状,这也是没有排序的原因。

这些因素都是对比TCP的,如果想安全的通信,那么你就需要编程,在程序中完成这些工作,这样那我为什么不直接使用TCP呢。

既然UDP如此有缺陷,但是其优点又是极其明显的,速度快,节省带宽,视频会议,通信都是基于UDP的,还有支持组播,这是TCP无法支持的。这样的说法实际上暗含着应用场景的,但还是要显化一下,首先,UDP通信传输过程数据确实不太合适,除非你理解网络和UDP协议的工作,其次,UDP更多的用于传递消息和事件等应用,现在数字化也好,工业4.0也罢,数据的传输不仅仅局限在过程数据,消息和事件也越来越重要,相信在未来使用这样UDP的场合会越来越多!

读万卷书 行万里路
赵欣
奇侠

经验值: 5576
发帖数: 387
精华帖: 52
7楼    2021-02-26 10:02:29
主题:回复:我与PROFINET不得不说的事-04对比

yzm_cumt:3楼2021-02-25 09:15:41

                   

在请问一下,这句话什么意思?“S7协议就是完美的选择。首先在通信的数据量上与TCP/IP持平,最高支持64K字节的数据传输;其次由于其应用层协议,故障报警响应及时,例如发生断线的情况下,两侧的通信即停止,产生报错信息。”为什么会这样呢?谢谢

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

这是对比TCP协议的,对于数据量的传输,两者都支持64K,手册已经明确了,没有什么好说的。对比故障问题,我这里只需要说说TCP的报警,详细就可以理解。我想许多客户在使用TCP通信时,都是编写一些时间节拍的程序来判断TCP通信失败,那为什么不用功能块的引脚呢?因为这是通信协议或者说机制决定的,即使你断开网线,发送端仍然会发送数据到自己的缓冲区中,Done仍然会被置位,直至BUSY出现,那它也没有判断出与通信对方断开,因为它还没有等到看门狗时间的到来,在时间内,它会认为对方仍然存在,不认为对方丢失,所以这也是很多用户使用时间节拍来进行TCP诊断的原因。而S7却不是这样的,很好的避开这样的缺点。所以我说S7很完美.

读万卷书 行万里路
赵欣
奇侠

经验值: 5576
发帖数: 387
精华帖: 52
8楼    2021-02-26 10:11:41
主题:回复:我与PROFINET不得不说的事-04对比

这里给大家贴一张图来表达一下TCP和UDP的区别,大家如果感兴趣看看这里指的是什么?回答正确的,精华帖



读万卷书 行万里路
www123456
至圣

经验值: 12225
发帖数: 2431
精华帖: 86
11楼    2021-02-27 13:36:49
精华帖  主题:【故事】回复:我与PROFINET不得不说的事-04对比

左图人喝水,手拿着瓶子可以根据感知口腔大小调节瓶子角度(相当于流量),比如人口吞咽频率慢了,水快充满的时候,相当于告诉手臂应该调节流量了,当然这个过程要占用一些时间。对TCP类比一下,先拿着瓶子对准口腔(TCP建立连接),然后告诉发送方自己数据容量窗口的大小,根据我目前的储存能力(数据接收能力),发送方应该发送多少数据,这也是流量的控制。这个喝水过程的吞咽频率对水流流量影响很大,类比TCP/IP通信,也就是接收频率要比发送频率快,使接收端的滑动窗口始终有空闲,这样通信速度就快了。右图中没有喝水的流量调节,完全是流多少水,口腔尽量去喝的过程,当口腔吞咽频率不够的时候,口腔中水积累多了,没有变通机制,水流依然"一往无前",水很可能就会飞溅出来(丢失),对UDP来说就相当于丢包。

www123456
至圣

经验值: 12225
发帖数: 2431
精华帖: 86
12楼    2021-02-27 16:09:32
主题:回复:我与PROFINET不得不说的事-04对比

任何事物都具有两面性,虽然右图的水不用瓶口对准口腔(建立连接),水流控制一往无前显得有些"精简粗犷",但有时是需要这种喝法的,因为喝得"畅快"(省略占一定时间的交互调整思考过程,有更充足的时间去执行喝水动作),虽然可能丢掉几滴无关大局水滴,但这点相对于需要快速解渴要求就忽略不计了(有点不严谨);

UDP也不例外,没有了TCP的建立连接过程,滑动窗口控制机制,握手确认机制,序号控制,重传机制,校验机制等,所以如果接收端能力强(读取数据速度快),就可以"快速"传输数据,当然实时性增强了,这一点是TCP无法比拟的.

您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。