I have a question concerning FF HSE and its relation to the H1 protocol: is it right that FF when using HSE does use the stock 802.3 MAC, that is, CSMA/CD without any traffic control, et cetera?

In particular, is it right that FF does *not* use any special media access protocol as it does with H1 (read: CD compel data, and token passing using PT/RT)? In consequence, FDA has no provisions to provide any realtime properties, right?

Is there any (planned) activity in this direction to connect H1 segments over HSE with realtime properties?

 

1. FF HSE does use the stock 802.3 MAC.

2. The MAC for FF H1 can be different, as that uses a non-802 network, i.e., one twisted pair. Remember, H1 was designed to work over the same twisted pair that carried the older 4-20mA signal.

3. AFAIK, FF doesn't have any plans to create a "version" of 802 that doesn't use the 802.3 MAC. One of the design constraints for HSE was to be able to use commodity Ethernet-100 components for cost sensitivity. Making a MAC change could introduce incompatibilities which would GREATLY drive up costs, you would need custom silicon.

4. Most people put limits around the non-determinism of 802.3 by employing star architectures with Ethernet switches (not hubs). The throughput is not an issue here, just the non-determinism, i.e., variance in latencies. This can be readily overcome per above. I remember Allen-Bradley peformed very detailed testing into this and concluded, based on actual data from a large number of installations, that the supposed problems by using 802.3 have an extremely low probability of occurrence in industrial applications like FF HSE.

5. If you just need that guaranteed deterministic response, then FF HSE is not for you. Sorry, but the FF couldn't insist upon a non-commodity implementation without being ignored by the end-user community. People were getting fed up with being forced to pay $1000 for a network connection, when their office computer could connect for $25.

 

Harald,

Foundation Fieldbus HSE uses exactly the same Application Layer as H1 and has all of the H1 capabilities. It just does it differently because it uses UDP protocol over the IP network that is on top of an IEEE 802.3 Ethernet stack. In most cases, you will install Ethernet as a 10/100BaseT network using Category 5e or 6 UTP cable and an industrial grade Ethernet switch set up to operate in full duplex mode. Each HSE segment uses unmodified CSMA protocol, but because there is only one station (Linking Device or CPU)
per segment, there are no collisions to detect. Since the network operates in full duplex mode, there can never be a statistical setback because a station is receiving at the same time it needs to send. In short, the entire HSE network is deterministic and operates in real-time.

Further, even though HSE operates on UDP/IP over Ethernet, the synchronization (what you called traffic control) is exactly like H1 using Publish/Subscribe protocol under control of a Link Active Scheduler. It just uses UDP frames instead of H1 frames. Since HSE is so fast, any UDP inefficiency doesn't matter.

If anyone attempts to link devices on different H1 segments through HSE, they will be synchronized as though they were on the same H1 segment. It's what HSE was designed to do, and it's how HSE is tested.

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] <mailto:[email protected]>
Web: http://www.CMC.us
===========================================

 

Thank you for the detailed answers.

I'm not from the hard realtime camp so I don't have any problems with the Foundation's stance on this. I just asked because there is currently much noise from PNO with their isochronous realtime activity and I was not sure whether I missed some similiar activities from FF.

As a final note: it could have been that FF could have used their H1 MAC for HSE also...

 

Richard,

thank you very much for your information. Since it is partly on the opposite a previous poster mentioned I have to ask a few things in order to make sure I don't misunderstand your answer.

> Since the network operates in full duplex mode, there can never be a statistical setback because a station is receiving at the same time it needs to send. In short, the entire HSE network is deterministic and operates in real-time. <

Well, I beg to slightly differ here: surely the MAC of an 802.3 100BASE-TX is "deterministic" in full-duplex mode. However, as I don't know the firmware built into switches and their manufacturers usually don't give any information on timings, I'm rather cautios as to call this "deterministic". Especially I don't regard a network as being deterministic, when other IP traffic (for instance, from TCP up/downloads, et cetera) can cause large jitters in the flow of realtime traffic -- and all this depending on how a particular switch's firmware looks like.

But then, for process automation, this usually just is good enough.

> Further, even though HSE operates on UDP/IP over Ethernet, the synchronization (what you called traffic control) is exactly like H1 using Publish/Subscribe protocol under control of a Link Active Scheduler. It just uses UDP frames instead of H1 frames. Since HSE is so fast, any UDP inefficiency doesn't matter. <

So you mean, that, for instance, when an operator station (or maybe an archive system) is connected to an H1 segment over HSE, it requires a LAS in the HSE segment? Someone (well, the LAS) has to make sure that the media access on the HSE happens in a coordinated way if you want to be realtime. Where can I get information about this? From the documentation I got from the FF website and, e.g. from Yokogawa, I only found information talking about HSE being non-realtime and not taking part in the token rotation. If HSE is realtime, how do I connect such realtime HSE segments to non-realtime Ethernet segments? An ordinary switch can't do the trick.

> If anyone attempts to link devices on different H1 segments through HSE, they will be synchronized as though they were on the same H1 segment. It's what HSE was designed to do, and it's how HSE is tested. <

In what manner do the H1 segments get synchronized? Do they share the *same cycle* and the *same token rotation*? In this case, one LAS on one H1 segment needs to become active, while the other LAS on the other H1 segment needs to become stand-by. And for the implications to the HSE segment: does it runs in realtime too, taking part in token rotation too? In that case, both H1 segments and the HSE segment would form a large, single segment from the token perspective, right?

Or is it the other way, and both segments operate unsynchronized with process data re-broadcast by the H1-HSE couplers?

Where can I find more detailed information about such issues? I looked around the FF website but it is thin on actual details.

With best regards,

Harald

 

Harald,

There are only two companies who implement Foundation Fieldbus HSE as part of their systems: ABB and SMAR. Yokogawa implements HSE only in non-real-time segments, as far as I know.

To find out how HSE really works, I guess you need to purchase the standards document from the Fieldbus Foundation. You seem to not understand how HSE works, judging by your own words. I have the advantage of being around when it was created and I know the chief architect.

The definition of Determinism is more simple than you imagine. Determinism requires that the maximum worst case delay in signal transmission be predictable. In collision-domain Ethernet, there is a statistical setback to resolve the collision. This means that you cannot predict the maximum possible worst case delay in a signal transmission. Full duplex switched Ethernet is not stochastic, meaning that there is no element of chance in delivering a data packet. Therefore, by definition, it is deterministic. Real-time is relative to the application. Switching delays in all known Ethernet switches are well within real-time requirements for process control and most material handling applications, but are not real-time enough for motion control needed for machining operations. Do NOT confuse real-time with determinism; they are different things.

The only way Foundation Fieldbus can achieve synchronization is through the use of Publish/Subscribe (P/S) protocol. There are NO TOKENS in Foundation Fieldbus protocols. P/S requires that all network stations operate on the same clock tick. Each LAS is responsible for propagating time to its own network segment. If there is an Ethernet switch in that segment, and there is an HSE
segment branched from that switch or an HSE Linking Device, the LAS for that segment receives the time synch command and after synching its own clock, resynchs its HSE segment. Eventually, the H1 segments are also synchronized. When an HMI subscribes to a data set from a field device, the field device will send it on the subscription schedule synchronized by that common time clock. The entire Foundation Fieldbus network H1 and HSE alike are synchronized. The only sources of delay (loss of real-time) are lack of network capacity, unlikely at 100 Mbps.

Some suppliers are not willing to support HSE as their control network since they can't predict how it will be used. For example, there is no way to prevent a user from uplinking the HSE network to a corporate network and allowing the operator to use a web browser or downloading software. Personally, I don't see how this can interfere with HSE and its UDP/IP traffic. HSE does not use TCP/IP for anything. UDP/IP frames still travel the network even during TCP/IP traffic that may come from web browsing.

I hope that this clears this up for you.

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] <mailto:[email protected]>
Web: http://www.CMC.us
Buy my books: Automation Network Selection
Wireless Networks for Industrial Automation
The Consumer's Guide to Fieldbus Network Equipment
for Process Control
http://www.isa.org/books
===========================================

 

> There are only two companies who implement Foundation Fieldbus HSE as part of their systems: ABB and SMAR. Yokogawa implements HSE only in non-real-time segments, as far as I know. <

Thank you for this information. And what is about Emerson?

> You seem to not understand how HSE works, judging by your own words. I have the advantage of being around when it was created and I know the chief architect. <

I'm deeply impressed.

> Some suppliers are not willing to support HSE as their control network since they can't predict how it will be used. For example, there is no way to prevent a user from uplinking the HSE network to a corporate network and allowing the operator to use a web browser or downloading software. Personally, I don't see how this can interfere with HSE and its UDP/IP traffic. HSE does not use TCP/IP for anything. UDP/IP frames still travel the network even during TCP/IP traffic that may come from web browsing. <

I'm not going to judge you here by your own words as you liked to do with me, so just a short and polite note: the answer to the second part of the paragraph above can be easily learnt by reading the 802.3 specification as well as the RFCs for IP, UDP and TCP. This information is truly open and freely available (not only as in beer), no need to buy expensive books.

 

Dear Mr. Albrecht:

To your question: Emerson Process Management, maker of the DeltaV system, has a Fieldbus Foundation registered HSE Linking Device, but does not sell it, nor do they support the use of HSE in the structure of a DeltaV system. Their reasons are approximately what I have previously written, and you have repeated.

If you read my previous comments, you will learn how Foundation Fieldbus works without spending the US$45 to buy my book. HSE is both deterministic and real-time in the domain of process control. If you are interested in how Ethernet can be used in a deterministic and real-time network suitable for motion control, then read about PROFInet in its "hard real-time" version on the PROFIBUS website http://www.profibus.com. Although not yet commercial, the iDA network protocol also supports such hard real-time via Ethernet (http://www2.modbus-ida.org/idagroup/service/download/IDA-Spec-V11.pdf). A third successful commercial Ethernet-based protocol suitable for multiaxis motion control is being produced as JetWeb by Jetter, AG (http://www.jetter.de/3.0.html?&L=1). I mention these since they all require low jitter, precise real-time delivery via unmodified commercial off-the-shelf Ethernet
components.

I don't judge you. I only state the obvious - you don't understand.

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] <mailto:[email protected]>
Web: http://www.CMC.us
Buy my books: Automation Network Selection
Wireless Networks for Industrial Automation
The Consumer's Guide to Fieldbus Network
Equipment for Process Control
http://www.isa.org/books
===========================================

 

Just a comment on the iRT (PNO Isochronous Realtime).

I (for one) am eagerly awaiting iRT. *NOT* because I plan to use it, but because since MAP/TOP days (ie: 1980's) people have been whining "Oh, we need a scheduled Ethernet for real time". I am curious to see if the gain of a "new" Ethernet-that-isn't-Ethernet outweighs the pain. Are big players willing to NOT buy Cisco and other mainline Ethernet gear for infra-structure? Will other "true-Ethernet" alternatives leveraging IEEE1588 time-sync be able to deliver similar value for less money? ODVA CIP-Sync and several consortiums in Europe are betting they can.

So big money is being bet on both sides. "Smart-folks" on both sides are convinced they are correct. But I am not a user buying products, so can be somewhat a bystander watching the show.

iRT may either be:
1) a spetacular success and 5 years from we all use it
2) or become just a niche PNO/Siemens fieldbus (ie: a "ControlNet" for Siemens)

best regards
- LynnL, www.digi.com

 

PNO iRT is not available yet because it needs a special Ethernet chip being designed by Siemens. This is not "standard Ethernet" because of the additional clocking pulses generated by the chip. I am assured it works to at least a 10 microsecond synchronization. Personally, I liked the approach originally taken for iDA, now part of Modbus.org. This used Real-time publish/subscribe for motion control synchronization, similar to Foundation Fieldbus, just to a tighter time specification. I have seen motion control systems implemented with a precursor of iDA supplied by Jetter Automation. This worked extremely well, but I cannot tell their maximum number of independent axes of motion vs. the iRT specification. Two different approaches for solving the same problem.

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] <mailto:[email protected]>
Web: http://www.CMC.us
Buy my books: Automation Network Selection
Wireless Networks for Industrial Automation
The Consumer's Guide to Fieldbus Network
Equipment for Process Control
http://www.isa.org/books
===========================================

 

Yup, you bet. I never meant to imply iRT was "on the shelf", but likely PNO will object to saying it's not even available yet and only being designed by Siemens.

Simple IP multi-cast alone (meaning IDA publish-subscribe or ODVA Class 0/1) won't be enough to enable the low-jitter iRT, Jetter, and CIP-Sync are aiming for. "Accidently" queueing a 1500 byte IP packet at the wrong time for even a full-duplex 100Mhz channel blocks the RT packet too long by some applications' definition. But will enough applications really require sub-200 microsecond timing? ODVA has demo'd sub-200 microsecond timing with CIPSync, IEEE1588 and standard Ethernet.

best regards
- LynnL, www.digi.com