Communication and bandwidth requirements increase as more and more complex applications appear in the car, for example for enhanced safety and entertainment solutions. End users expect the same level of entertainment functions in the car as known from their home environment. Furthermore, existing vehicle control networks such as the LIN, CAN and FlexRay standards are not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS). Future networking technology should re-use as much as possible from consumer and other non-automotive domains, while taking into account the automotive-specific requirements. This includes hardware components as well as software stacks. Communication solutions for higher bandwidth, such as MOST, are available but expensive for a broader usage in automotive networking systems. Today, in-vehicle networking architecture appears as a heterogeneous system as a result of its historically grown nature (see the left schematic in Figure 1).
Figure 1: Domain architecture, today and in the future Click on image to enlarge
A new in-vehicle networking system built from scratch and without legacy would most likely have the architecture as shown in the right schematic of Figure 1. Here, ECUs are structured in a hierarchical architecture where application domains are connected through a data highway. Ethernet provides all the prerequisites for such a holistic approach. It could be used as a backbone bus to connect the various application domains as well as for sub-networks that just require higher bandwidth. Today, switched Ethernet networks rely on a point-to-point communication where the available bandwidth is more efficiently used compared to broadcast systems like CAN or FlexRay. The switching concept can be advantageously applied to bridge the domain boundaries without time-consuming packing and re-sorting of the transmitted messages or packages as needed in a complex gateway.
The usage of Ethernet in the car means a paradigm shift in the design of next-generation in-vehicle networking systems: connecting different domain networks, transporting different kinds of data (control data, streaming, etc.) and fulfilling the stringent robustness demands in terms of extended temperature range and EMC performance.
It was bound to happen. I've been involved in digital control system networks for the vast majority of my career. And I've seen any number of special purpose schemes giving way to IP/Ethernet, as Ethernet speeds have increased.
You can even see this in the commercial sector. For example, way back in the 1980s and early 1990s, starting with the telcos of Scandinavian countries, interest was mounting in migrating digital telephony from the strict circuit-oriented architectures, such as those in ISDN, the old DSn standards, SONET, and ATM, to packet-switched IP over Ethernet.
The automotive CAN bus is probably following this same trend.
Original objections are always about "predictability." However what invariably happens is, if the network speed is much higher than that of these criticial signals, then predicability can statistically be "guaranteed" anyway. And by the way, math works. The idea has merit.
While ethernet will support all of the functions that CAN, LIN and Flexray currently perform, I would dare say the costs at this stage would be prohibative for most major OEMs.
The old adage of "if it aint broke dont fix it" fits quite well, CAN and LIN a suitable for for their respective functions in an automotive application (such as door locking, window control etc), especially vs cost per unit, so why change .
Where ethernet will thrive is in the ADAS, infotainment and active safety, where the cost will be outweighed by the bandwidth and speed that ether can deliver. not to mention utilising POE (power over ethernet) to streamline harnessing to support small current devices such as cameras.