Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Networks

Automotive communication backbone: MOST vs Ethernet

Posted: 15 Oct 2014 ?? ?Print Version ?Bookmark and Share

Keywords:Automotive? electronic systems? Advanced Driver Assistance System? ADAS? Media Oriented Systems Transport?

Sending an A/V stream between its source and its renderer means that a significant amount of data will be flowing for a prolonged period of time. The data flows from a fixed source to one or more fixed renderers. Adding addressing information and breaking up the data into packets that need to be examined every time they go through a device along the route results in a lot of wasted bandwidth. In addition, it complicates the processing of information, as packets may not always move through the system with exact latency and determinism.

Packets also need to be unpacked, and the data joined into a continuous stream, for the various audio and video decoders to process it.

This can cause high processing overhead at the microcontrollers that receive and reassemble the media streams before playback. This is typically done in software, on a host processor, since the network interfaces typically can only process standard Ethernet packets, without regard for the data contained in them.

An Ethernet channel is a pipe for Ethernet packets, and it is unaware of anything other than the priority of the packet, the source, and the destination. Higher-level software protocols, which use processing power, have to be implemented to ensure transmissions are properly acknowledged, and to decode what the data received means and what to do with it.

For continuously flowing audio and video transmissions, the streaming and isochronous MOST network channels have a distinct advantage. A control channel is used to set up where the data is going to be placed within a frame, and where a renderer can pick up the data it needs. Once this setup is completed, only actual audio or video data is transmitted, without any overhead for addressing or timing information.

Figure 1: Ethernet Frame, as defined by IEEE 802.3.

Figure 1 illustrates the structure of a typical Ethernet frame. It contains a total of 210 bits of miscellaneous information (preamble, start-of-frame delimiter, destination and source addresses, etc.), which is required for every single packet of information.

This doesn't include any bits needed by protocols such as audio/video dridging (AVB) and TCP/IP, which add their own data to the header of each Ethernet packet.

When you consider that a CD-quality stereo audio sample is only 32 bits, this is a huge amount of overhead. You could combine several audio samples into a larger data payload, but the larger you make this packet, the worse the audio drops are if a packet is lost, and the larger the buffers need to be to allow for software-based error detection, correction, and retransmission.

Latency becomes an issue when you have to buffer information. This is critical for ADAS applications.

Using the smallest payload in Ethernet (46B or 368 bits), the 210 bits of administrative information represent more than 36% of the bits transmitted in each frame. That doesn't even include the time needed for arbitration of the channel. If you don't have enough data to fill 46B, the overhead is even worse. A single audio sample is only about 5% of the bits transmitted in a minimal-payload Ethernet frame. Almost 95% of the bits are overhead.

The other issue that arises if you combine samples into big packets is that small but time-critical control information has to wait on those packets, should a large packet arrive slightly earlier than the important control information. This makes real-time control over Ethernet difficult.

The whole MOST network is synchronous, with all participants deriving their clocks from a single timing master. This eliminates the need for buffering, and it simplifies even isochronous transmissions, where the data clock is different from the network clock. Streaming channels are set up once, and then only actual data is transmitted, without additional overhead.

In a MOST network, each network interface has a deterministic duration for data to traverse it that is on the order of microseconds. Applications know exactly how long it will take for data to move from one place to the other, without the need to timestamp and process each packet to know where it came from and where it is going. Applications know exactly how fast data will be consumed, and they can place it or take it off the network "just in time."

Dedicated control channel
MOST technology also has a dedicated control channel, so time-critical control messages are not affected by other traffic on the network.

The Ethernet network uses "best effort" delivery. It does not guarantee delivery and instead requires higher-layer protocols, such as TCP/IP, to establish and maintain reliable data connections.

This means that there is a significant software overhead, with the attendant processing power, needed at each node that connects to the network. Even within a car, where the likelihood of packet loss is low, you still need all the processing power to implement standard Ethernet protocols.

?First Page?Previous Page 1???2???3???4???5?Next Page?Last Page

Article Comments - Automotive communication backbone: M...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top