Is TCP/IP real time?

M

Michael Griffin

In reply to Dick Caro: You have qualified your points a bit, but I think that it needs to be pointed out that "no time-critical I/O points and remote I/O is not being used for a safety application" covers most of the market.

I would also like to point out that almost all of the I/O available for the networks you mentioned ("Modbus/RTU, PROFIbus, Interbus, ASi, DeviceNet,
ControlNet, or EtherNet/IP") *CANNOT* be used for safety applications either.

There is more to a safety system than just determinism. There are safety versions of Profibus and ASI (and perhaps others as well), but the entire system from end to end (PLC program, PLC, network, and I/O) must all be made
with special safety versions, not the garden variety components.

As for a "need for the PLC to react in 'real-time'", most PLCs themselves are not "real-time". Furthermore, I think a more typical application for this type of I/O is with PC based automation, and very few PC applications require real-time either. When the I/O is used over a closed network, transmission delays will be negligable compared to the delays in the PLC/PC or in the I/O devices themselves.

While I agree with your points in principle, I think you have placed undue emphasis on certain marginal applications (networked safety and real-time) and not enough on normal machine control and monitoring.
 
D

Dave Zimbrich

You may be interested in looking at EtherCat I/O, which is a type of I/O soon available from Beckhoff. EtherCat uses standard 802.3 frames and can update 1000 digital points in 30 microseconds (0.03mS). See http://www.beckhoff.com and http://www.ethercat.org

Dave Zimbrich
Field Application Engineer
Beckhoff New Automation Technology
Plainfield, IL
 
Curt, when you already have an 8-headded monster as the international fieldbus standard what difference will it make to add one or two more? EtherCAT has been accepted by the IEC as a PAS (Publicly Available Specification) along with Modbus/TCP, EtherNet/IP, and Ethernet PowerLink as candidates to add to IEC 61158 fieldbus standard. This elevates EtherCAT to a draft international standard status. ControlNet was already one of the original 8 along with Profibus and both Foundation Fieldbus H1 (the original Fieldbus) and Foundation Fieldbus HSE.

I tend to agree with you that there are too many standards, but the IEC and the European Commission seem to like these "multistandards." The claim is that multistandards promote commerce between nations or "free trade." Somehow the needs of the end user are lost in this rush to standards.

Dick Caro
===========================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
http://www.spitzerandboyes.com/Seminar/semfbus.htm
===========================================
 
C

Curt Wuollet

Hi Dick,

Yeah, but that's the whole problem in a nutshell. It's all about commerce and trade and diametrically opposed to the needs of integrators and their customers. The only way it could be of benefit, is if everything supported all of those. That would be a nightmare but at least you could get brand a and brand b to recognize that they were incompatible. I don't recall how many heads the original Medusa had, but more must be better. Witness the other multiheaded beast, the suite of languages. Has anyone ever seen any interoperability in practice? Commercial zeal can derail even the best of intentions. And I'm willing to bet that there is some reason that publicly available spec is of no practical value to my business unless there's money in it for Beckhoff. And I'm a fan of some of Beckhoff's ideas.

Regards

cww
 
Curt, you are preaching to the converted. I totally agree with you. I tried my best to stem the tide of this kind of multistandard, but they are supported by all the suppliers as long as their customers allow them to. For example, when I came out against the 8-headded monster called IEC fieldbus (61158), I tried to get nations to vote against it. Japan, France, Italy, and Canada agreed with me, but I could not sway the US National Committee to vote against that standard - mostly because the suppliers controlled the voting process and they were tired of the battle. I could not even cast a vote on the US National Committee because it required that I pay dues of $200 per year that is nothing to a large corporation, but had to come out of my own pocket.

The end users and small system integrators are unheard in this battle unless you put pressure on the large system suppliers that you want them to support decisions at the international standards level that favor YOU. This has not
happened, so we continue to have TOO MANY STANDARDS - which means no "real standards" at all.

Dick Caro
===========================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
===========================================
 
G

Gustavo A. Valero P.

Hi,

Reading all answers, opinions and definitions given here, I'd rather clarify some terms/concepts before giving my opinion:

1) TCP/IP = a big family of protocols based on 4 layers: Application (FTP,SMTP,SNMP,HTTP and applications live here for example); Transport (UDP & TCP); Internet (IP, ICPM, ARP, RARP) and Network Access (here there are no protocols, it only works at hardware level to define the physical transmission of signals along the network)

2) TCP = a connection-based protocol which gives a reliable delivery service with error detection, correction and retransmission of data. It's used for Web for example when the packages travel several ways/routers, it is slower than connections based on UDP.

3) UDP = a no connection-based protocol, it means that it does not need to create a connection between the source host and the target host before sending data, therefore, Application layer must provide all error detection and correction.

The industrial protocols based on UDP and used by SCADAs app do not need a reliable delivery service with error detection due to this feature can be solved using polling actions constantly.

4) IP = a connectionless protocol, which means it doesn't wait for an answer/approval from the destination to send datagrams (Transport layer must do all the error checking and handshaking between hosts) making the Internet layers job simple. The main job is to carry out all routing by using IP Destination Address.

5) Network= A group of computers or devices that are connected together for the exchange of data/resources. A network always needs a method to transmit packets (Architecture) and sometimes the term architecture includes topology. Examples are Ethernet, FDDI, Token Ring, AppleTalk, etc.

Well, these are my opinions and answers:

a) Is TCP/IP fast?
R: As I indicated above, TCP/IP is a family of protocols and has nothing to do with the speed of the network!! If you have a fast network (1 Gbps or 10 Gbps Ethernet based on UTP Cat 5e/FDDI - full duplex) you will get a slot time very low (<5 ms) and you could have a SCADA very fast.

b) Must I use/change my Modbus TCP/IP protocol (for example) in order to improve the SCADA throughput?
R: No! change the type/architecture or increase the speed of your network!

c) "Are all errors detected by TCP/IP corrected by retransmission"?
R: Not always! If the application/program uses UDP instead TCP, there is no retransmission.

d) Is TCP/IP deterministic?
R: The word "deterministic" is oriented to Networks/topology and not protocols. A network is deterministic when it is based on a "token" to manage data traffic such as Token Ring and FDDI (Ethernet is not a deterministic network). Therefore, TCP/IP will be "deterministic" if it is working on a topology that supports it.

e) Is TCP/IP real time?
R: Yes!! Although the "real time" term should be associated to use/task that it will carry out and not associated to its design.

Best regards.

Gustavo A. Valero P.
BIConsulting C.A.
Valencia - Venezuela
[email protected]
 
M

Michael Griffin

Re: Curt Wuollet's comments on Beckhoff's EtherCat - As far as I can tell, it's just another proprietary protocol for another closed club. On their web site, technical details on how it works are strictly "members only". Obtaining a "number" from a standards organisation is in itself fairly meaningless as far as being "open" is concerned. Most of these standards organisations are simply meeting forums and filing systems for the various
proprietary clubs. They have nothing to do with making information genuinely "open" and available.

The Profibus organisation has four patents on Profinet. I have been told that there is nothing particularly innovative or profound in them, but presumeably they are enough to prevent anyone who is not a club member from implementing Profinet. I don't know what the Ethercat club intends to use to keep people away from the Ethercat protocol, but it would seem likely that they have similar measures in place to keep their protocol from coming into widespread general use in industry.
 
F

Fabio Mielli - Schneider Electric Brazil

Today Modbus TCP/IP are working also over UDP stack, so, under real time capabilities. Including global data and synchronization functions.
 
C

Curt Wuollet

Hi Dick

Yes, I remember your righteous disgust with the process
and your voice of reason amidst the madness. But, what
we get from this farce of standardization is actually much
worse than a lack of standards, which might result in a
logical migration towards the best. Instead, allowing this
antistandard standardization divides the user base into
splintered groups by whatever their vendor sees fit to
support and actually dissipates and prevents any
movement towards a true standard. And what's worse
is that this is intentional and a great disservice to the
automation industry as a whole. At a time when
advancement and prosperity would be best served by
emulating the experience of networking all the worlds
computer users together, automation users only become
more fractionalized, isolated and exploited.

Regards

cww
 
V

Vladimir E. Zyubin

Good example of mis-standardisation is the IEC 61131-3.
The real goal of the activity is protection of the marketing outlets. The guys are well known - have a look at the SC65B/WG7/TF3 member companies: Allen-Bradley, Schneider Automation, Siemens, Philips IAS, Yamatake-Honeywell... ;-)

--
Best regards.
= Vladimir E. Zyubin
= Wednesday, August 03, 2005, 11:44:27 AM =
 
M

Michael Griffin

Siemens even managed to produce two different "IEC 61131-3" implementations which are mutually incompatable.

I'm not sure that having a written "standard" is really going to solve anything by itself. No matter how thick the standards document, there will always be grey areas and room for interpretation. I think what is needed is a reference software implementation that everything needs to conform to (or siimply just use). The "standard" should then just be an explanation of this actual working system. There is a lot less room for "twisting" the standards this way. The questions become technical ones of whether or not something actually works with the reference, rather than ones about defending market share.

This isn't going to work though if any one party (or close club) "owns" the reference software. No one else is going to trust them that much to allow any one group to control access to the reference. It would have to be done in a way that treats everyone large or small the same, and which protects all of them equally.
 
V

Vladimir E. Zyubin

>Siemens even managed to produce two different "IEC 61131-3" implementations
>which are mutually incompatable. <

... and I bet both implementations are in full compliance with the IEC 61131-3
standard.

>I'm not sure that having a written "standard" is really going to solve
>anything by itself. No matter how thick the standards document, there will
>always be grey areas and room for interpretation. I think what is needed is a
>reference software implementation that everything needs to conform to (or
>siimply just use). The "standard" should then just be an explanation of this
>actual working system. There is a lot less room for "twisting" the standards
>this way. The questions become technical ones of whether or not something
>actually works with the reference, rather than ones about defending market
>share. <

I am sorry, but the standard does not bother about
cross-brand/cross-platform compatibility at all. (Though the way you suggest will work).
 
J

Jonas Berge - H

Dear Griffin and Zyubin,
IEC 61131-3 is just the programming language for building the control strategy (the element such as contacts and switches in ladder) it does not
say how the program downloads into a controller. That is why you can't make one PLC talk to another or use any third-party tool configure any PLC. All that is standardized is the meaning of "normally open" etc.

I guess what you are looking for is a solution encompassing both programming language for building the control strategy and the communication. This way several devices can participate in the same control strategy, part of the whole task executing in the same controller, regardless of brand. And the strategy can be build in a third party tool. To my knowledge there is only one solution for this available in the market: FOUNDATION Fieldbus. It includes a function block language based on IEC 61804 and it includes one protocol option based on UDP/IP over Ethernet media and another protocol a scheduled token over manchaster bus powered media.

To understand the design and application of two different media refer to chapter 3 of the book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or download immediately
in softcopy) and for the programming language see chapter 4:
http://www.isa.org/fieldbuses

Jonas
 
Top