MENU

Choosing the right transport method for automotive data

Choosing the right transport method for automotive data

Technology News |
By eeNews Europe



A car is made up of subsystems that may communicate with each other but have very different requirements for the data transports that they use. For example, a simple button to lower and raise a window has very low data communications requirements and is extremely cost sensitive. You won’t be running a full TCI/IP stack or even a CAN (Controller Area Network) controller to keep track of the window. Instead, many cars use an inexpensive serial bus called Local Interconnect Network (LIN). CAN also provides many useful functions in the vehicle and, though more complex than LIN, is easy to implement in a variety of automotive microcontrollers. Many diagnostics functions, body and engine control communications flow over CAN, which uses a message based protocol.

As the amount of data that needs to be transported increases, faster and more complex networks are needed. Those networks are the subject of this paper. These networks require significantly more processing power than the ones previously described and also use orders of magnitude more bandwidth due to the amount of data that needs to be moved from one place to another.

Over the last decade the automotive industry has gravitated towards MOST for its audio and video communications needs. The network was conceived from the beginning to stream data to various devices, with the primary intention of simplifying automotive entertainment systems. There are now over 115 car models with MOST networks in them, according to the MOST Cooperation, the association of car makers and their suppliers that is the caretaker of the standard. There are over 100 million devices that implement the technology, with some high end cars including up to 15 devices in one vehicle.

As the car becomes connected to the outside world, Internet Protocol (IP) communications have become more important. Most of the traffic in the IT world uses various protocols geared around IP packets and many applications rely on this standard to process the information that can be flowing in and out of the car to reach all the way around the world. 

Despite how the technologies are often portrayed as adversaries, where only one should prevail, both MOST and Ethernet have certain advantages and there is a lot of synergy between them.

The case for Ethernet: Packet transmission

Ethernet was developed in the 1970’s with the objective of connecting computing systems that could be widely separated and might not have reliable connections between them. It needed a simple physical layer to send packets of information over long distances and over a path that could change as the links between locations changed. Each packet had to be encapsulated with addressing and control information so that it could be rerouted at will, through computer systems that could join and leave the network at any time. This is akin to putting a letter in an envelope and sending it to a recipient in another country. The exact routing can change, but the important thing is that the information gets to the destination, even if you can’t predict the exact time it will get there and if that time varies from transmission to transmission. Any data exchanged with the outside of the vehicle, whether over a diagnostics interface or over a cellular modem, will likely be put in individual packets with a source and destination address along with other information designed to control how the data travels from point A to point B. This type of transmission is very useful for things such as e-mail, web browsing and moving data that is not time critical. In addition, the widespread use of Ethernet has resulted in a wide variety of applications that use Internet Protocol (IP) packets that are the mainstay of this type of communication, whether it be the IEEE802.3 wired physical layer or other mechanisms, such as wireless LAN or cellular communications. Having an Ethernet-based medium in the car makes it easy to use these applications with little change from their non-automotive instantiations.

The fundamental architecture of Ethernet is based on Carrier Sense Multiple Access with Collision Detect (CSMA/CD). This means that all participants sense whether the transmission medium is busy and try to transmit when it is not. If multiple transmitters start to transmit, a collision occurs and is detected. All transmitters then back off and try again after a random timeout.

The problem with this is that it is impossible to predict when there will be a collision and as more devices participate, the more time (and thus bandwidth) is wasted backing off and trying again. The system is non-deterministic and there can be wide variations in latency. In fact, some studies have shown that bandwidth utilization can be less than 50% in heavily loaded networks, with the rest of the time used to arbitrate and get control of the physical medium. The nodes that compete with each other are said to be in the same collision domain. This problem is not an issue for data without hard real time requirements. If some part of a web page is painted a few hundred milliseconds faster or slower than another part, the user won’t even notice. An e-mail can take a few seconds more to make its way around the world without any catastrophic effects. The simplicity and low cost of the overall world-wide system make it attractive. The problem manifests itself with audio and video and any other application where a continuously flowing stream of data can’t afford to be interrupted or a control message has to “absolutely, positively get there” within a predetermined timeframe, to quote an old TV commercial. Buffering can help, but it introduces delays which are unacceptable for applications like cameras or other driver-assist functions where latency is unacceptable.

Enter switches. Switches keep track of where the sources and destinations of various packets are located. They learn the network as traffic flows through it. The effect is that they separate collision domains and eliminate many of the bottlenecks that exist with the basic CSMA/CD technology of Ethernet. Traffic is only sent out to the port with the path to the destination and other devices never see it.

The trade-off is that you need additional hardware and buffering and determinism is only a statistic, rather than a hard real-time feature. Switches are added to the basic network interfaces located in each device that uses the network. These switches can be centralized or a three port switch is added to each device so they can all be daisy chained. However, all network interfaces need to connect to a switch if they are to avoid colliding with other devices. If devices share the physical medium without a network, they go back to the CSMA/CD mechanisms. Switches used in the automobile also need to be more specialized than the typical switch in an office because they need to include hardware features for bridging audio and video. Ethernet AVB includes extra hardware to distribute clocks, provide timestamps for each packet that is transmitted, and provides mechanisms for bandwidth reservation and packet prioritization.

The bottom line, though, is that Ethernet is widely used and just about all data entering and leaving a vehicle is likely to ultimately make its way to an Ethernet network of some kind.

The case for MOST: Stream transmission

While the addressing information used in IP packets is needed when packets are going over long distances and over uncertain and varying paths, it results in significant amounts of overhead when the main purpose is to get large amounts of data between a well determined source and a well determined sink that are in relatively close proximity, and in a relatively fixed configuration, such as within the vehicle. 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 will flow from a well-defined source to one or more well-defined renderers. Adding addressing information and breaking up the data into packets that then 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. For such transmissions, the streaming and isochronous channels of MOST 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.

Below is the structure of a typical Ethernet frame:

Figure 1: Ethernet Frame defined by IEEE802.3. For higher resolution click here.

 

There are a total of 210 bits of miscellaneous information (preamble, start-of-frame delimiter, destination and source addresses, etc.) needed for every single frame of information. This doesn’t include any bits needed by protocols such as Audio/Video Bridging (AVB). When you consider that a CD quality audio sample is only 32 bits, this is a huge amount of overhead. It is true that 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 driver assistance applications. Using the smallest payload in Ethernet (46 bytes or 368 bits), the 210 bits of administrative information represent over 36% of the number of 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 46 bytes, 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 whole MOST network is synchronous, with all participants deriving their clock from a single timing master. This eliminates the need for buffering, and simplifies even isochronous transmissions, where the data clock is different than 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 time for data to traverse it that is on the order of microseconds. Applications can know exactly how long it will take for data to move from one place to the other without the need for time-stamping and processing of each packet to know where it came from and where it is going. Applications know exactly how fast data will be consumed and can place it or take it off the network “just-in-time”.

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 nodes. The Ethernet phy itself may be inexpensive, but you need a capable processor to implement the required software stack. MOST, in contrast, allows for remote control of INICs, so that for simple applications (e.g. an active speaker that just has an INIC and a Digital to Analog Converter with an amplifier), no additional processing power is required at the remote node.

On the other hand, as more and more data is by default already packetized and flowing between consumer applications that use the IP communications, sending such data over synchronous or isochronous MOST channels requires additional processing to put the data into different formats. Some of this processing could be wasteful when the applications already expect to process information in its native format. If you have a PC browsing the web over an LTE connection, it would be simplest if the data reached the PC in its native format.

The bottom line for MOST is that it is very efficient for transporting the streaming data that is usually required by infotainment and driver assistance systems.

Putting it all together

MOST150, the latest generation of MOST, puts this whole debate to rest. There is no need to force all data into a particular format to fit a single transmission protocol. MOST150 has a dedicated Ethernet channel within its frame. This channel can take a standard Ethernet packet without any special processing by the higher levels of the Ethernet network management stacks, and send it over the MOST network. MOST150 Intelligent Network Interface Controllers (INIC) even have Ethernet-style MAC addresses so the Ethernet packets can be extracted at the right location and passed on to other standard Ethernet devices. You eliminate the need for central switch hubs and additional hardware in the system. Streaming data, such as audio and video programs, can then be sent in parallel, using MOST mechanisms, to attain better efficiency in the use the available bandwidth.

In fact, even if an application called for just IP-based transmission, a MOST150 network could allocate 100% of its bandwidth just to the Ethernet channel. Thus, a proven automotive physical layer is already available for Ethernet transmissions in the car.

With MOST150, you have a single physical layer that supports the advantages that each technology brings to the vehicle.

The International Standard Organization (ISO) has developed an Open Systems Interconnect (OSI) reference model for network communications. In the case of Ethernet, the model looks like this:

 Figure 2: ISO Open Systems Interconnect Reference Model for Ethernet

To use the same model over MOST150, you simply change the lower two layers and replace them with MOST. You can then run additional MOST layers in parallel, so the new model looks like Figure 3:

Figure 3 Modified OSI Reference Model that includes MOST and Ethernet

All higher layers remain unchanged. Only the data link and physical layers need to change for Ethernet communications, without needing any changes to the actual consumer-facing applications. The MOST packet channels have their own network stack that can run in parallel and independently from the Ethernet stacks.

While there are many IT related stacks for IP communications, the automotive industry has developed its own communication stacks that include many features specific to automotive applications, such as system management and control functions, and gateways to other aut0omotive networks, such as CAN. Such a stack is not geared to run over standard Ethernet, but is already available for MOST. Combining Ethernet and MOST on a single Data Link and Physical Layer speeds up the development effort required as it is no longer necessary to “reinvent the wheel” to manage automotive information and entertainment systems. The whole automotive network management infrastructure currently in place can be leveraged when adding Ethernet capabilities to the vehicle. Complete tool chains geared for automotive development and manufacturing systems already exist and would require little change to add Ethernet capabilities to the current set of MOST functions.

The MOST streaming channels do not require separate processing stacks. Data can just be pumped down into the network as shown in figure 4:

Figure 4 Streaming Channels do not require processing. Data can flow freely.

This results in very low latency transmissions that are well suited for driver assist functions. End-to-End delays, including compression and decompression are just a few milliseconds.

Finally, control information needs to be sent across the network with deterministic delays and low latency. This control information is also used to set up the streaming communications previously described. The MOST Intelligent Network Interface Controllers (INIC) provide for control channels that are used for that purpose. The function blocks for INIC and MOST NetBlock are built into the hardware so the network can come up as an independent entity, without having to wait for the individual devices to boot up and present the application functions blocks. Those can register themselves after each device finishes its startup procedure and tells the network what functions it provides. Figure 5 illustrates this concept.

Figure 5 Control Channel Reference Model

All the stacks presented in figures 2-4 can run together in the latest generation of MOST150 vehicles. From a technical perspective, there’s no need to argue what kind of infrastructure the vehicle needs. Both packet and stream transmissions can be accommodated and the designer can take advantage of the best solutions to his problems.

Automotive Quality

Beyond the technical details that bring different data transports together over a single physical connection, another very important issue for car makers is Automotive Quality. The Automotive Engineering Council published a quality specification, called AEC-Q100, that specifies a set of stress tests that need to be run to ensure some minimal level of reliability of automotive IC components. This is only a very small part of an overall automotive quality plan, though. The sample sizes specified by AEC-Q100 can only statistically guarantee just under 1,000 dpm defect rates. Most car makers want single digit DPS, almost 3 orders of magnitude less that AEC-Q100 can guarantee. It is not enough to run those tests and call a part “Automotive Grade”. Furthermore, these stress tests are a one-time event during the qualification of the part and do nothing to maintain quality throughout the products life and to monitor quality levels during on-going production.

Automotive environments are also very demanding in terms of electromagnetic emissions. Many car makers have tested standard Ethernet components and realized they cannot really take advantage of widely available products. There are some proprietary solutions on the market, but once you go down that route, the automotive industry is better off using a standard that they actually control, vs. being at the whim of the consumer electronics industry, that may or may not choose to take into account automotive requirements at any given time.

Ethernet, MOST or any other network must be adapted to the automotive world. Suppliers need to be deeply ingrained in the automotive quality mind-set in order to react as fast and as thoroughly as a car maker expects. A consumer electronics customer with ten times the automotive volume should not take precedence when a car maker’s line is down due to some unforeseen problem with a consumer part.

Standard Ethernet cabling is not well suited for an automotive wiring harness. Such a harness is the third heaviest component in a vehicle, and one of the most expensive ones. Typical CAT5 cabling, with 4 twisted pairs, is too thick. Using the existing optical fiber or electrical MOST infrastructure to also distribute Ethernet around the car is an easy way to take advantage of an automotive grade physical layer, whether the need is for MOST, Ethernet or a combination of the two.

Conclusion

The car makers that run the MOST Cooperation have taken a close look at the various networking technologies available today. They have found the advantages that various networks offer and have come up with a solution to take the best from each one. MOST can multiplex several different data transport mechanisms. The Ethernet channel of MOST150 was developed to be able to use IP communications within and outside the vehicle, while at the same time reaping the benefits of the efficient synchronous, streaming mechanisms of MOST that are already in place. It includes all the software layers needed for the car industry and does not require new automotive network management stacks. It can take advantage of over a decade of automotive networking experience by all the members of the MOST Cooperation and of hundreds of millions of nodes already on the road. The silicon and physical infrastructure required to implement these systems has been well proven in automotive applications, and the automotive specifications needed to implement automotive networking systems are all available today. The tools chain needed for every stage of the automotive production cycle, from design and development, through manufacturing and service in the field, are already in place.

About the author: Henry Muyshondt is Technical Liaison of the MOST Cooperation and Senior Director of Business Development at SMSC. He has been instrumental in introducing the MOST networking technology into the automotive industry. Henry has worked to bring together the automotive and CE industries and has led MOST Cooperation and CEA efforts to bridge the gap between these industries.

 

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s