The race to add more sophisticated and safety-critical electronics into cars is forcing carmakers to revisit the communications systems within increasingly electrified and connected vehicles.
Until very recently, communication between components within a vehicle was simplistic, and communication between vehicles was non-existent. All of that is changing quickly. Rapid and secure communication between more electronics within a car, between cars, and between cars and infrastructure are essential pieces of assisted and autonomous driving.
However, not all of the pieces are in place yet. And unless there are new solutions, automotive OEMs will have to compromise on some of the features that they would like to introduce, especially with respect to autonomous driving, said Micha Risling, senior vice president and head of Valens Automotive. “Because we are dealing here with a huge amount of data floating around the car, this topic should be addressed. We are talking about a revolution as opposed to an evolution with respect to connectivity. This same philosophy is applicable for all the different elements that are being used or are going to be used for autonomous vehicles. It’s really changing the way the car is being designed.”
A surge in the number of sensors is one of the drivers behind this need for improvements in communication. There currently are 16 or more different types of sensors: LiDAR, radar, accelerometers, gyrosocopes, pressure sensors, all of which somehow need to be connected to the ECUs in the vehicle today. And that number is going to grow significantly as more autonomous features are added into vehicles.
“The rising adoption of vehicle-to-vehicle and vehicle-to-infrastructure means a continued increase in the number of vehicular radar systems,” said Steven Liu, vice president of marketing at UMC, which manufactures sensors for the automotive sector. “Technologies needed for these systems include the car’s anti-collision radars and global positioning systems, as well as sensors that will be needed to interact with stoplights and vehicle dispatchers. These will work in conjunction with existing systems such as passenger comfort and infotainment control and engine monitoring subsystems that regulate temperature, tire pressure, and gas. Trucks for long distance transportation will require systems for load leveling, load shifting, curve and wind shear, all working together to ensure that cargo is not damaged during transport and that the truck container is stable throughout its journey. All of these 5G communication applications will be essential for the system’s ability to perform its respective operations.”
But given the technologies and the connectivity solutions that exist to date, cable clusters and the different harnesses are becoming one of the pain points. Another pain point is the amount of software code. As a point of reference, an autonomous vehicle will probably have approximately 100 times more lines of software code than an F-35 jet. The reason is that autonomous cars need to deal with many more operating scenarios than a jet.
“On automatic pilot when flying a jet, 99% of the time there is no one flying next to you,” said Valens’ Risling. “When you compare that to a car that needs to drive somewhere in Manhattan or Las Vegas, just taking into consideration the difference in potential scenarios that are needed to deal with per second, this is the major reason why you need special and sophisticated, advanced, complicated, heavy software to deal with that. This is true for ECUs, as well as connectivity in the sensing-especially when it comes to autonomous vehicles. When you’re dealing with safety, you need to have a lot of redundancy. Redundancy also complicates the architecture. You need more ECUs, which are more connectivity points, and for that you need advanced connectivity,” Risling explained.
Betting on Ethernet
For now, the automotive ecosystem is focusing on automotive Ethernet as the primary technology specification for in-vehicle communications. Ethernet has been in production for more than 40 years, and it has been well proven under a variety of environmental conditions.
“It was primarily used in infotainment and video and the like but it still brought Ethernet into the automotive industry John Swanson, Ethernet Product Line Manager at Synopsys IP. “We knew 10/100 wasn’t going to be fast enough even before it was done and it quickly moved to Gigabit Ethernet, which isn’t going to be fast enough either. When you look at an autonomous car, just take a very simple example of the cameras. You need high definition video because you need to do facial recognition and road sign recognition, so there is a lot of video coming in. That’s a ton of data, so 1 Gbps automotive Ethernet will be out before much longer and it will move quickly to 2.5 and 5 Gbps, and potentially even faster.”
This has prompted chipmakers such as Marvell to connect what used to be the separate domains of the car – infotainment, the advanced driver assistance system (ADAS), body electronics, and control – using Ethernet as a high bandwidth, standards-based data backbone for the vehicle. In the future, that information will be used to connect with the other sensors required for autonomous vehicles to enable connectivity not just inside but also outside the car.
“The Ethernet market historically has been split into two distinct segments,” said Venu Balasubramonian, marketing director for the Connectivity, Storage and Infrastructure business unit at Marvell. “On one side there is the 25/50/100/400 gigabit per second for data centers, which will drive bandwidth. That’s one piece of the market. The other piece is the enterprise served by copper, which is 10 Gbps. Another piece that’s emerging now is automotive Ethernet, because of all the electronics. Bandwidth there needs to be significant with all the data and the switching, and the Ethernet needs to be hardened.”
He noted that the automotive market ultimately could require 100 Gbps Ethernet for moving all of the data from image sensors. Moreover, by leveraging the low cost and high bandwidth of Ethernet, new applications will be able to be added to next generation automotive architectures, including features not even thought up yet.
Automotive OEMs have already begun to revisit their network design to add an Ethernet backbone and an Ethernet diagnostic over IP (DoIP) for diagnosing the vehicle, observed Sherif Ali, system architect at Mentor, a Siemens Business. “Given that in the future that most of the OEMs are trying to have over-the-air updates where they can update the software for the vehicle, this means that a huge amount of data will be downloaded into the ECUs to update the hundreds of ECUs in the vehicles. This also means that we need a way to be able to update the data using a huge amount of data during the updates, and Ethernet DoIP is actually providing this flexibility and this ability. We use Ethernet either as a backbone for the communication inside the ECU or as an interface between the ECU and the OEM or the service shop. Ethernet will play a great role, and the scale of using Ethernet is going to expand.”
Today there may be a couple of ECUs for interfacing with the vehicle. OEMs are working on backbone technology to connect a large number of ECUs, which essentially is an Ethernet bus. So two different standards—AUTOSAR and Open Alliance—are contributing to the standardization of the Ethernet usage and testing.
“AUTOSAR is providing a spec for implementing and also testing Ethernet,” Ali said. “AUTOSAR has something called acceptance test. This acceptance test is not only for Ethernet, but Ethernet was part of the specs that AUTOSAR uses to define how an AUTOSAR supplier can test their Ethernet basic software so they can guarantee that it confers with the Ethernet standard. The same thing happened with Open Alliance, which also provides an automotive Ethernet spec, and last year they released an automotive Ethernet ECU test specification. So this is from the testing and protocol specification point of view.”
Indeed, testing the automotive Ethernet is of the utmost importance given the magnitude of safety and reliability in future autonomous vehicles.
Today, there are three different categories for automotive Ethernet testing:
- Conformance test. This makes sure that each piece of software implementing the Ethernet protocol is compliant with the protocol itself. It’s usually a huge chunk of test cases that would be needed for this category.
- Integration test. This ensures the complete network and infrastructure is working as it is supposed to. In this case it is usually testing the robustness of the infrastructure using integration tests.
- Performance test. This category tests the performance on the throughput, the load on the software side, and network side. There are usually different categories where this will be seen, and most of this is done on the software side.
To be sure, delivering a signal from one automotive Ethernet controller to another is challenging because of the low-cost interconnect medium (twisted pair wire), long distance, and non-traditional multi-level signaling (PAM-3), said Brad Griffin, product management director for PCB, IC packaging and signal and power integrity at Cadence. “Integrating multiple modules requires going through a compliance test. Simulation tools provide virtual compliance tests to ensure that the standard is met before the module is designed, reducing the number of errors found during lab testing and helping to accelerate delivery of products to market.”
At the same time, designers need to know a few things to make their automotive Ethernet systems easier to test, noted Mentor’s Ali. “They need to know about the topology. What is the topology for using this Ethernet piece of code or software? If it is just a DoIP connection, the expected throughput or performance will be different if we’re talking about a backbone that is connecting a chunk of ECUs together. From a test and design perspective, this is very important. The design team also needs to understand the location of the ECU. Is it a gateway? Is it an edge node? This is another aspect that would affect the implementation of testing or test cases.”
Other challenges
From an IP standpoint, one of the big challenges in automotive Ethernet is the addition of the time-sensitive networking (TSN).
“When you say time-sensitive networking, people think it is a [single] specification, but it is a whole bunch of specifications that are effectively toolboxes,” said Synopsys’ Swanson. “Do you have different shaping algorithms? Do you have things like preemption? As as result, one of the challenges that people are having right now is how to use these features, because they are new. However, in the automotive industry people solve problems, and there are a lot of different approaches as people are learning right now. This translates to the challenge of determining which features to put on a chip. An endpoint is going to have different requirements then a switch. If it’s something that involves video it’s going to need more bandwidth than something that’s just doing pure control. So it is important to understand the market you’re going after to do a really optimized design for it.”
There is no shortage of research in this area. “Automotive Ethernet hit the ground running,” said Curtis Donahue, senior manager for Ethernet technologies at the InterOperability Laboratory (IOL) at the University of New Hampshire, which performs semiconductor testing of PHY conformance for BaseT Ethernet in automotive. “There were a lot of issues the OEMs wanted to resolve in many areas very quickly, and that’s why there is a lot happening at once. When it comes to autonomous driving, a lot of people think of the wireless vehicle communication – either vehicle-to-vehicle or vehicle-to-infrastructure – and that’s certainly a large part of the self driving ecosystem that’s starting to emerge. But even with the wireless technologies, the in-vehicle communications, such as being able to gather the information from all of the sensors, the cameras, all that’s being captured – all that bandwidth needs to have a very reliable in-vehicle communication network. That’s where the BASE-T1 technologies are stepping in and starting to replace the CANs and FlexRays of the world, and provide the higher bandwidth so that the self-driving future that we all know is coming can be realized.”
As far as how to make a design easier to test, Donahue said that based on the labs’ experience with the 100BASE-T1, which applies for future BASE-T1 technologies, the IEEE specification is not written in such a way that it’s very easy to understand how things can be tested. “They have statements that indicate what is a requirement, and what needs to be tested, but maybe not the how. There are a lot of areas that silicon vendors have noticed that the IEEE will say, ‘This is a requirement,’ but it might not necessarily be testable, for instance. There are many areas where there are internal signals, which a silicon vendor usually wouldn’t break out to a dedicated pin in order to be observed by test and measurement equipment. In those areas, it can be very difficult to determine what’s a ‘pass,’ what’s a ‘fail.’ Sometimes the silicon vendors get a little frustrated with that because the IEEE standard doesn’t directly say that it’s necessary, but to make it testable it does. So there are certainly considerations that need to be taken into account that aren’t obvious to get a full, 100% testable report.”
Conclusion
Automotive Ethernet seems to be the accepted method for vehicle connectivity. It is well understood, inexpensive and time-tested. Moreover, there is a roadmap for improving data transmission speeds that at this point are surpassed only by optical.
Nevertheless, much work remains to be done in terms of interoperability between solutions and in clarifying the Ethernet specification. And while Ethernet appears to be the winner, at least for in-vehicle communication, there are other options on the table and in development. As with all things in the rapidly evolving automotive market, anything can change.