Breaking News
Comments
Newest First | Oldest First | Threaded View
Bert22306
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
Bert22306   6/5/2013 8:07:15 PM
NO RATINGS
By the way, in case we lose perspective about what these tolerances actually mean, let's not forget that at the speed of light through wire or fiber, it takes an infinitely short timing pulse 5 nanoseconds to travel just 1 meter. So if you think you have timing tolerances that severe, you're not just going to be hardwiring, you're also going to be compensating for the length of wire.

Bert22306
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
Bert22306   6/5/2013 7:58:32 PM
NO RATINGS
Two points, assuming existing Ethernet tools available. One is that if you have a message with very tight latency constraints, you architect your network so it never has to go through a huge number of intervening switches. For instance, in a car situation, you'd never engineer the network to send time-sensitive messages through eight hops. Another point is that messages with tight timing constraints get to the head of the queue in any switch, by virtue of their high priority. Even if they get to the queue immediately after a full-length 1500-byte message, you're only talking 12 usec of latency. Or in a 10G Ethernet, 1.2 usec. Finally, if you do have incredibly tight tolerance requirements for a particular message, down in the nsec range, then I would argue that the actual cases of this are going to be few. So you hard-wire the timing pulse, in these few cases, between clock and destinations. And then you send whatever message contains the data separately, over the Ethernet network, to be synced up at the client system with that timing pulse. And you use whatever kalmann or other filtering to determine exactly where you are now.

db00
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
db00   6/5/2013 2:03:37 PM
NO RATINGS
Although ‘support pre-empting packets' may seem like a good idea, it will cost latency for many current network protocols. Many switches today support cut through operation, but when adding pre-emption cut through switches will need to operate in store and forward modes even for speed reduction cases. This is due to the fact that a large packet could be pre-empted near the end of its transmission due to a time sensitive flow. For example an eight hop 1G network 1518 byte packet cut through latency of 12.288uS goes to a store and forward latency of 101.248uS, nearly a 10x latency increase.

DrQuine
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
DrQuine   6/5/2013 12:10:14 AM
NO RATINGS
Real time control requires "speed" and "predictability". If responses are reliably received in a defined time frame, a process can be programmed accordingly. The unexpectedly early and especially the late responses are the ones that will create the challenges. If this effort is successful, perhaps the proliferation of microprocessors will evolve into a central processor with a number of peripheral sensors (and less complex programming).

Bert22306
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
Bert22306   6/4/2013 7:44:56 PM
NO RATINGS
That's also true, IMO. Especially if you have the really tight timing constraints only in short messages, which make up a small fraction of the totalnetwork load. VLANs with high priority should solve the problem. And it's up to the implementer to figure out how best to organize the different priority queues in the switches. Another point is that the Ethernet 1500-byte payload limit works in your favor as is, if you're concerned with wedging in high priority traffic among large messages at lower priority. Much like the small ATM cells did this, only now we're talking about way faster network speeds. It amounts to the same thing.

IanWalker
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
IanWalker   6/4/2013 4:54:00 PM
NO RATINGS
Vlans and QoS aware ethernet solve this... Ethernet will trump CAN...

mikejt
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
mikejt   6/3/2013 10:03:31 PM
NO RATINGS
Just going faster doesn't always work ... it certainly helps, but both the automotive and industrial networks are pushing data fast enough that over-provisioning is not enough. Over-provisioning *and* careful scheduling *and* engineering the network to avoid the interference caused by long packets can work (and is used today), but both the industrial and automotive industries are moving toward "converged" networks where such assumptions can no longer be made ... hence, the effort to standardize the methods for low-level QoS.

kjdsfkjdshfkdshfvc
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
kjdsfkjdshfkdshfvc   6/3/2013 8:06:27 PM
NO RATINGS
Ethernet in my car.... what? http://bit.ly/IC4m9t

Bert22306
User Rank
Author
re: Ethernet preps for real-time role in cars, factories
Bert22306   6/3/2013 7:47:02 PM
NO RATINGS
Déjà vu all over again. It must be decades ago now that I saw the first proposals for introducing synchronism into Ethernet. The historical trend has been, forget that, just throw more speed at the problem. If you want to add synchronism to 100M Ethernet, instead of struggling with that, just use 1G Ethernet. Automobile networks have been very low bitrate in the past. Going to Ethernet, as factories have been doing, provides the opportunity to increase speed by easily a couple of orders of magnitude, without having to invent anything new, and without incurring prohibitively high costs. That's usually enough extra speed that the latencies and jitter will become acceptable. (Yes, I will accept that under-hood temperatures in cars will require MIL-SPEC-like components.) Plus, the other aspect of this is, clever protocol and application design can also eliminate the perceived need for super tight timing tolerances in the network. For example, if your asynchronous network is way faster than it "needs" to be, for just carrying the data load, then you can implement some small amount of message buffering and still meet the tolerances of your control system. Those message buffers will reduce jitter to the point of being acceptable. And a very fast network can fill the buffers fast quickly to meet the latency requirements. Back in the days of ATM, it was fun to try to eek out QoS from relatively slow networks. But pragmatism, even back in the 1990s, won out. Cheap speed trumps super clever solutions. My bet is, the same will apply to automotive Ethernet.



Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Radio
NEXT UPCOMING BROADCAST

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.
Like Us on Facebook
Special Video Section
The quality and reliability of Mill-Max's two-piece ...
LED lighting is an important feature in today’s and future ...
05:27
The LT8602 has two high voltage buck regulators with an ...
05:18
The quality and reliability of Mill-Max's two-piece ...
01:34
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...
See the Virtex® UltraScale+™ FPGA with 32.75G backplane ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
10:35
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...