Ah, Ethernet… our good, reliable, trusty friend from way back. So trusty, in fact, that our cars may soon be running a version of Ethernet for all of the electrification stuff. Leveraging something tried and true should certainly go without a hitch, right?
Well, certainly as compared to coming up with something entirely new, perhaps. But what’s this Ethernet going to do in our cars?
Well, for one, it will help with the infotainment stuff. Lots of data coming in through a wireless portal, to be beamed back to screens stared at raptly by restless children in an attempt to quell the hail of spitballs that otherwise might provide the divertimento during a long road trip. Important stuff, no doubt, but not mission-critical. After all, you didn’t see the Walton kids getting all butt-hurt when they couldn’t watch the depression-era version of Spongebob, so life is possible without a screen.
But then there’s the other part: beaming time-sensitive control messages around between the various functional parts of the car. Yeah, the Waltons survived just fine without those messages too, but this isn’t simply an ADD issue: it’s how cars are evolving. This isn’t your ancestors’ Buick. So, if that’s the case, that messaging has got to be right. Messages need to get to the intended target in time to be useful. “Turn left, we’re veering off a cliff to the right!!!” doesn’t help if it arrives at the steering assembly right about the time when the hood latch is greeting the rocks below.
And that gets to an issue with legacy Ethernet, love it though we do: it’s a “best-effort” kind of system. It can’t guarantee that your message will arrive when you need it to. Amazon Prime does you no good here, sorry.
So… how do we send messages with deadlines on a network that doesn’t know deadlines from deadheads? This has been an ongoing effort, creating what’s referred to as a time-sensitive network, or TSN. Not sure if this is a good name, since what you really have is a hybrid network with some time-sensitive messages (“Turn left!!!”) and with time-insensitive messages (“This is gonna be the BEST DAY EVER!”*).
So how do you blend those together? The approach taken is to reserve certain time slots for messages that absolutely, positively have to get there on time. Identification of those messages is by priority. So, during that time slot, messages of that priority will be sent. After the slot, other messages are sent according to their various priorities.
But the thing is, after those other messages start, then another time slot will approach. What if you start sending a low-priority packet in the unreserved time right before the designated slot, and it’s too long to finish sending by the time the priority slot arrives? It would be as if you reserved a time at the grocery-store checkout stand so that you could get in and get out quickly – except that the guy before you, who didn’t start during your time, ended up having 35 coupons, each of which needed to be verified and signed, and your time came and went with you standing there looking silly and knowing you’re going to be late back to work.
In order to avoid that, a guardband was added ahead of the reserved slot in order to block out some time where no new low-priority packet could be started. So you have a reserved slot, then open season for anything, then a time that might go empty, and then the next reserved slot.
If that guardband is long enough, you can pretty much guarantee that no packet that starts before the guardband will end after the guardband. That’s great – except for one thing: it’s a waste of bandwidth.
Now, for systems using a store-and-forward approach, where an entire message is received and stored before being sent on to the next destination, you can measure the length of the message to decide whether or not there’s time to send it before the critical time slot arrives. Got time to send 500 bits before the reserved slot? Then, if the stored message has less than 500 bits, go ahead and send it. If not, then wait. (Or find another message that does, but don’t take too long looking…) In this case, you no longer need the guardband, since you’re being deterministic about which packets will and won’t depart prior to the time slot.
But if your system is cut-through – that is to say, you receive a few bytes of a message and immediately start forwarding them on before you see the end of the packet – then you don’t know how long that packet is going to be. So you can’t tell whether or not to start sending it, and you no longer know whether or not it will encroach on the reserved slot. So you’ve still got a problem that might require a bandwidth-wasting guardband.
In order to address this, one final new critical feature has been added: the ability to interrupt a packet that’s in the middle of being sent in order to send some higher-priority packet at its duly appointed hour. The pre-empted packet continues being sent when the urgent stuff is complete. So now you can use the entire available bandwidth without having to throw some away “just in case.”
But some software has to perform this operation. It’s a matter of “shaping” the traffic as it’s being sent. Which is a product that Excelfore recently announced. It will be needed by sources of traffic as well as routers and switches to ensure that packets don’t bunch up at some bottleneck in the network.
Now… just because some company happens to be the first to send a press release about some new product doesn’t mean that they were the first to offer the product. So I asked Excelfore whether their traffic time-aware shaper (TAS) was new not only to them, but also to the industry.
According to Mark Singer, Director of Marketing at Excelfore, “Excelfore is aware that some TAS experiments have been shown, however we believe ours is the first commercially available.” So there you have it.
*For those of you without kids in a certain era, this is a Spongebob thing.