赵欣,西门子(中国)有限公司 工业客户服务部 客户服务中心 自动化系统技术高级专家
最近我和冯工去了一家生产企业,这家企业使用了很多国外进口的机器装置来生产汽车配件,随着机器设备的增多及数字化的管理手段的要求,企业数据就要和现场的设备进行交互,不过在进行IT和OT融合的时候,前期并没有进行很好的网络规划,而是直接从IT侧拉过一根网线和装置的现场网络相连,用户描述现场网络总会莫名其妙出现网络中断,那么今天我给大家讲清楚这背后的原因以及解决这个问题的方法。首先,我们在现场看到了现场PN设备和IT网线都连接至一个知名的第三方的交换机上,基本上采用星型的拓扑连接方式,那么我们首先要使用Bany来检测一下来自IT网线上的数据是否包含大量的广播数据或者高负荷的数据,然而可能是由于这根网线连接到IT侧的端口是千兆口,不能使用Bany的T1/T2口进行抓包,也就是基于这样的原因,我当时改Bany的T3/T4口代替T1/T2口和更换网线等方式进行测试,在更换连接方式过程中,发现每当插入IT网线到该交换机时就会出现生产装置急停,实际上就是PN IO通信中断。此时,我们已经看到了这个故障现象,也知道了其中的一点端倪。为了验证我们的想法,使用Bany捕捉当网线插入前后,PN网络中的IO控制器...
我们在现场发现了一个奇怪的故障信息。用户使用夹具,每个夹具都配备了 CPU1515F 作为智能设备,并且通过一些复杂的设置与 IO 控制器X2接口相连。然而,使用”ReconfigIOSystem”在使能设备加入的过程中,IO 控制器却报出了两个奇怪的错误:“Diagnostics available and is Being processed”和“Multi-interface mismatch-inconsistent parameterization for sending LLDP data”。为了揭开这个故障的神秘面纱,我们决定进行抓包分析。通过 Bany 捕捉使能智能设备加入前后的报文,希望能找到故障产生的根源。我们发现子槽号 0x8000 为接口模块上存在错误 1,Fault:Fault available,但详细原因却不得而知,只知道这与控制器诊断缓冲区中的提示“Diagnostics available and is Being processed”一致。但这些故障信息在西门子手册和网站中都无法找到,只能参考 PROFINET 相关的标准文件。深入研究这些标准文档,...
今天写这篇文章,目的有2个,一个是想描述现场的故障信息,并向大家讨教解决方案,二是总结一下OEM用户/甲方的网络设计的粗粗建议,同样也希望大家给我一些建议。前几天,我和另外一位西门子高级专家冯学卫一道去一家生产锂电池的高科技公司做了一次现场诊断,现场的设备提供来自一家国内知名的OEM厂商。我和大家描述一下现场的故障,MES位于IT中心,使用第三方的驱动和现场的装置S7-1200和S7-1500通过工厂IT网络的路由做数据采集。对于S7-1200,无论是集成的PN口还是CP卡都无法与MES做S7连接,而S7-1500可以使用CP卡和MES做S7连接(实际上现场也出现过其中一个1500CP卡不通的),集成的CPU的PN接口却无法与MES通信。而为了测试这个故障,用户在现场也放了一台MES,与PLC的CP卡处在同一网段,无论是CPU还是CP卡,S7通信完全没有问题。这证明第三方的驱动和西门子的PLC通信没有问题。看到这里,大家会觉得故障的原因应该在工厂网络的路由上。但是在IT中心Ping现场的PLC都是1ms,这说明链路是非常好的。在现场我们先查看PLC的连接资源和硬件组态,这些都没有问题。...
今天我们开始故事07,而上一个故事06,似乎是很遥远的事情,因为时间精力甚至内容都用于1847撰稿了,一直不知道如何继续这个系列话题,正好最近在测试PROFINET启动过程,因为有些概念与GSD文件关联,这才发现GSD文件的强大,所以从GSD概念作为出发点,给大家稍稍总结一下这些关联的知识点,希望大家从GSD的角度再从重新刷新对PROFINET的认识。PROFINET系统启动过程是基于UDP/IP进行交互的PNIO-CM协议,其中CM(Context-Management)表示上下关系管理,为系统启动的核心协议,且可以归纳到RT_Class_UDP实时等级,完整的过程为:Connect帧(57,133):建立一个AR和对应的CR。Write帧(120,183): 参数化所有组态的子模块。DControl帧(190,239):控制器参数化结束。CControl帧(248,255):IO设备的参数化结束。控制器或监视器使用“Connect帧”建立连接,并传输建立AR和必要的CR所需的所有数据。其中包含了参数化数据以及顺序、过程数据通信以及启动的监视时间以及循环的I/O数据的传输频率等等。在...
这次我们谈谈PN的报警,因为这部分内容正好是我近期整理的内容,所以整理完之后和大家分享一下,由于时间仓促,如果有理解错误或者概念不清晰,希望大家多多提建议,也希望和大家多多交流。关于报警概念,即损害自动化系统正确运行的事件必须作为报警发送给控制系统。报警来自与现场设备相连接的过程,称之为过程报警,例如温度超过上限;报警来自现场设备本身,称为诊断报警,例如插拔模块。发生过程报警时,设备仍然能正常工作。诊断报警标识为入向“Incoming”或者出向“Outgoing”来表示报警的到来和离开,而过程报警仅传递一个入向“Incoming”消息。PROFINET 可以基于槽/子槽组合以及相关通道的进行报警起源定位,以及通过接口模块中的报警-ASE(Alarm Service Entity:报警服务实体)发送实时非循环的高优先级(5,6)报警传输至高层控制器。PROFINET 只会对发出的诊断报警保存在模块的诊断缓存中,并在接口模块上存在该报警信息的映射。此时控制器或者监视器可以利用数据记录关系Record data-CR来读取缓存中的诊断信息。诊断报警作为消息保存在报警ASE中,直到它们被明确消...
今天我们开始故事6,继续故事5来讨论一下PROFINET中带宽。在故事5(我与PROFINET不得不说的事-05-带宽-技术论坛-工业支持中心-西门子中国 (siemens.com.cn))中,提到了带宽的两个单位,一个是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控制器在一个S...
[置顶] 重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话04-FCS错误的报文帧处理
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话01-楔子
SCALANCE X-200IRT手册中提到这样一段话,我先来翻译一下,若是以前对于概念的不理解,肯定翻译不正确,不过我是已经做了试验测试和验证的,应该可以翻译正确一些。我们来看一下:X200 IRT IE交换机工作在Cut-through模式。如果收到一个带有错误校验码的报文,正在转发的该报文会被提前终止,这样该帧因此会变短。CRC的错误计数会增加。如果这个帧是一个长度为64字节的帧,Undersize错误计数也会增加,因为该报文帧被缩短了。别小瞧这一段话,这里面的信息非常多,甚至颠覆了自己原有对交换机转发方式的理解。我们来看看第一个概念Cut through,本质上的理解该概念是就是当交换机只要读取到报文帧的目标MAC地址,根据地址表,然后立即转发该数据帧,这种方式的优势就是转发速度极快,缺点就是无法检测报文帧的错误。那问题就来了为什么我们的IRT交换机可以检测错误? 第二个疑问是正在转发的帧由于错误而被CUT了,翻译是这样的逻辑吧?什么?还可以“砍”报文。怎么还有这样的神操作?我最好奇的被砍的报文在网络中又是以什么形态存在? 第三个疑问是64个字节长度的帧,不仅仅会计数CRC...
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话06-关于PN IO的级联深度
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话05-失真报文帧的处理
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话04-FCS错误的报文帧处理
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话03-直通模式
重新认识PROFINET-04-剧场版-源于IRT交换机手册中的一段话02-存储和转发模式
重新认识PROFINET-04-交换机对于PROFINET是怎样的存在
距离上一次的故事4(我与PROFINET不得不说的事-04对比-技术论坛-工业支持中心-西门子中国 (siemens.com.cn))觉得已经有很久没有更新了,不是我不想去更新故事5,而是每次写到一半都在后来又删除了,所写的内容总是不满意,总是觉得不该先写这个或者那个部分,觉得这个部分太简单,或者觉得那个部分太难,犹犹豫豫间时间就这样流逝了。我想说:“我太难了!,哈哈!”。而这次我觉得和大家聊一聊带宽这个概念,从此入手,再拓展到PROFINET的报文,带宽预留本身上来,循序渐进,让大家逐渐理解这些我们常听见,或者看见,只是没有对这些概念的感性或者理性认识。 言归正传,手册上常说,PROFINET是开放的,标准的,实时的以太网标准,基于快速以太网。从概念的角度,对于10Mbits/S的以太网是标准的以太网,现在几乎看不见了。因为它被更快速的带宽100Mbits/S的以太网所取代,称为快速以太网。所以我们现在在谈自己的工业网络时,实际上都是基于快速以太网100Mbits/S,只是我们简单的称其为以太网。从技术术语或者专业概念的角度来说,我们要严格的区分使用的是以太网还是快速以太网。对于百...
和大家聊完了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...
(我与PROFINET不得不说的事-02抓包-技术论坛-工业支持中心-西门子中国 (siemens.com.cn))刚开始接触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,是开放式协议可靠的,面向连接的,字节流的点对点通讯协...
大家好,再次和大家见面,这次给大家奉献《我与PROFINET不得不说的事》系列的第二篇文章。其实在写完第一篇文章(我与PROFINET不得不说的事-01概览-技术论坛-工业支持中心-西门子中国 (siemens.com.cn))的时候,我还没有想好第二篇文章写什么,和大家谈论什么。不过我想不会像《PLC通信原理探秘》系列文章那样,描绘自己的心路历程,剥茧除丝,逐步揭露PLC的通信原理。因为PROFINET的学习,随着PN的诞生,我是循序渐进的学习的,那里没有像《PLC通信原理探秘》系列文章描绘的那样跌宕起伏,波澜壮阔,而是像春天的雨丝,润物细无声,如涓涓细流汇入我小时候庭院门前的水塘。所以我想把我所知道的PROFINET关键知识通过此系列文章呈现给大家。在谈到PROFINET技术之前,我想和大家先说说Wireshark,因为只有通过Wireshark软件进行报文捕捉,才能更好的理解PROFINET的工作原理,后面的原理和技术的展示,大家才可能明白和理解。Wireshark这个软件,相信很多工控人还是知道的,不过用过的人可能就相对少了,至于能够使用该软件去诊断和评估捕捉的报文质量可能又是...
重新认识PROFINET-03-PROFINET YYDS
https://www.ad.siemens.com.cn/club/bbs/PostStoryExpert.aspx?a_id=1739892b_id=155
重新认识PROFINET-01-注定不凡的PROFINET
分享