ADAS and autonomous vehicles need new datacom architectures and new attitudes.
The state of California requires autonomous vehicle manufacturers to annually document and report every manual intervention by test drivers, including the cause and the vehicle’s mileage. In less than five years, these reports have demonstrated significant improvements in miles per intervention for virtually every car company. Despite these improvements, multiple high-profile car companies have either abandoned/suspended operations or had permits suspended following accidents. This demonstrates there are still significant challenges to developing autonomous vehicles, and by extension, Level 3 “conditional hands off” systems. Thus, vehicle OEMs still face numerous challenges as they shift from Level-2 advanced driver-assistance systems (ADAS) capabilities to Level-3 and Level-4 autonomous systems that enable drivers to take their eyes and mind off the road. Five of those challenges revolve around technical and societal issues.
A needed revision in computing architectures
Regardless of vehicle type, moving to higher levels of autonomy requires an ever-increasing number and variety of sensors. For example, the Waymo Generation-5 robotaxi combines 29 vision cameras, six radars, and five LiDAR sensors. The 4K 30 fps cameras generate image data at 6 Gb/sec, meaning that the cameras send 20 GB/sec of data to the vehicle’s network alone. Even with the reduced cost in the upcoming Generation-6 robotaxis (with 13 cameras), this is still nearly 10 GB/sec.
Vehicles have a growing number of ECUs in addition to cameras. Automotive compute architectures have, however, traditionally consolidated processing for each specific function within a single compute element, which integrates data from dedicated sensors or inputs. Even in lower-level ADAS systems, this is difficult. In a higher-level autonomous system, the cost, data rates, and power dissipation of the required processing make single processing elements impractical.
Managing the massive increase in data requires a revision in computing architectures that distribute workloads across several cores in one or more processors. This architecture becomes a central compute cluster, effectively creating a data center on wheels. In this data-center approach, specialized processing elements perform image analysis on camera data streams. Separate processing cores or CPUs may marry camera data with radar or lidar, using the “fusion” of data from different types of sensors to better understand the environment around the vehicle. Other cores can then focus on “policy,” or the determination of action required based on the output of the sensor analysis.
Waymo uses the multi-processor, data-center approach to manage the 39 major sensors in and moving its Level-4 robotaxis. Similarly, major OEMs are implementing this architecture to enable their Level 2+ ADAS systems, which often incorporate infotainment and cabin management functions within the central compute cluster. To optimize development time and minimize costs while supporting a range of capabilities, vehicles require a reusable, scalable, and high-performance compute architecture such as that shown in Figure 1.
Learning from decades of data center development, the basic elements of a scalable high-performance computing (HPC) architecture include:
- HPC SoCs with specialized image processing (inference and acceleration) engines.
- High bandwidth, low latency PCIe interconnect to enable movement of data between SoCs.
- In-vehicle Ethernet network connectivity into the HPC cluster, carrying sensor dataflows and control signals to other major vehicle systems.
- A safety processing element manages HPC system operations.
Optimized hybrid networking architectures
In vehicles, any latency or delays in data transmission can be fatal. The fast and efficient transmission of data from sensors to edge processors and then to or between central compute elements necessitates that the vehicle’s data network is its most critical system.
Autonomous vehicles, especially Level-2 and Level-3 passenger cars, must balance size, weight, performance, and cost. As mentioned, the cameras alone onboard the Waymo Generation-6 robotaxis send 9.75 GB/sec of data to the network. Especially when combined with the need for low latency, Ethernet simply lacks the performance to cope with this level of data reliably. This means a hybrid network approach is being deployed, utilizing the best features of each technology.
Ethernet has already become the dominant technology in the majority of global OEM in-vehicle network backbones (Figure 2). As the global data center standard, Ethernet offers a large supplier base, cost-effective, scalable bandwidth options, and attractive adaptations to automotive customers. The Single-Pair Ethernet standards at 100 Mb/sec and 1 Gb/sec speeds meet most network needs and are widely deployed globally for mainstream network requirements. Single-Pair Ethernet, also known as BASE-T1, brings a reduced wire count to automotive that offers weight savings and the potential for reduced cost in the Ethernet physical layer. Table 1 compares three flavors of Ethernet with the CAN bus.
| Feature | CAN FD | 100BASE-T1 | 1000BASE-T1 | 10GBASE-T1 |
| Bandwidth | 5 Mb/sec | 100 Mb/sec | 1 Gb/sec | 10 Gb/sec |
| Cost | Low | Low | Low | Moderate |
| Transmission distance | 40 m | 15 m | 15 m * | 15 m |
Table 1. A comparison of ‘legacy’ automotive CAN transmission standards to Single Pair Ethernet — a 40m “long reach” version of the standard is available.
Table 2 compares Ethernet to PCI Express.
| Feature | 10GBASE-T1 | SerDes | PCIe 4.0 (16 lanes) | PCIe 5.0 (16 lanes) | PCIe 6.0 (16 lanes) |
| Bandwidth | 10 Gb/Sec | Up to 28 Gb/sec per lane | 32 Gb/sec | 64 Gb/sec | 128 Gb/sec |
| Cost | Moderate | Moderate to high | Moderate to high | High | Very high |
| Transmission distance | 15 m | 1 m | 0.5 m | 0.5 m | 0.5 m |
Table 2. A comparison of high-speed interconnect options: 10G Ethernet, SerDes, and PCIe’s latest generations. Note the switch from gigabits per second for Ethernet / SerDes to gigabytes for PCIe (1 byte = 8 bits).
The emergence of 10BASE-T1S technology offers a lower bandwidth, cost-attractive alternative to CAN networking. The standards shown in Figure 3 include multi-drop functionality, which simplifies wiring to sensors across the various vehicle zones. 10BASE-T1S also offers the potential to remove ECUs that previously processed and routed CAN messages, simplifying the design of zonal network controller nodes. These nodes act as highway entrances by aggregating dataflows onto the backbone at points within the vehicle.
Despite the increasing number and bandwidth requirements of sensors, Ethernet can continue to dominate sensor and backbone infrastructure when augmented by other, optimized networking technologies.
Serializer-deserializer (SerDes) technology provides a high-bandwidth, cost-effective answer to the need for continuous, predominantly unidirectional data transmission. Cameras with a raw data interface use SerDes to provide real-time data delivery needed for high-performance image recognition. Using a SerDes interface reduces camera costs by eliminating pre-processing and sending raw data to an ADAS SoC, where optimized video engines can process the pixel-complete data more efficiently. Because virtually all SoC processors targeting ADAS include multiple camera interfaces and image-processing engines, data pre-processing on the camera is a duplication that adds cost. Ethernet-based cameras can be cost-effective in systems with only Ethernet connectivity or in cases where pixel-complete data isn’t required, such as a backup camera. Previously, SerDes implementations have been proprietary, locking OEM designs into a specific vendor, with the associated software and hardware restrictions. With the Motion Link standard from the Automotive Serdes Alliance (ASA-ML), scalable and interoperable products are emerging, offering OEMs a superior long-term ecosystem for managing camera data.
For high bandwidth inter-CPU communication, PCIe is the data center standard. PCIe offers extremely low latency, which is key for processing safety-critical data. The PCIe approach to scalable bandwidth, achieved by simply adding to the number of lanes (an Rx/Tx pair) in any given “port”, means connections are easily optimized around the expected bandwidth requirement. The protocol also has the significant benefit of being available on virtually every high-performance processor, a significant advantage when SoCs from different companies are chosen for different tasks. While there isn’t a specific automotive PCIe standard, the vastly superior latency and low processing overhead of PCIe have led to its adoption, and automotive-qualified chips are already available.
One challenge facing OEMs with respect to PCIe technology is the choice of PCIe Generation. Datacenters, whose revenue potential is proportional to bandwidth, are driven by the needs of AI processing. They are pursuing the leading edge of PCIe technology, Gen6, followed by Gen7. For embedded compute designs, SoCs and networking choices determine feature capability and total system cost. Bandwidth requirements for current data flows position PCIe Gen4 as the optimal price-performance technology (Figure 4). Reference Table 2, a Gen4 connection with four lanes, common on current ADAS SoCs, offers a bandwidth of 64 GT/sec (roughly analogous to 64 Gb/sec) and is a highly capable interface for sharing image data. Gen5 offers double the bandwidth, but at a price point 1.5x – 2x that of the Gen4 device, Gen5 is not expected to reach mainstream in OEM central compute designs until after 2030.
Finally, despite its lower bandwidth, CAN remains a proven and trusted standard within the automotive industry and will not be excluded from future networks. CAN offers a broadly supported ecosystem of reliable products and known suppliers to OEMs. It remains an ideal technology, for example, for sending actuator commands, including those for braking and steering. When interfaced through an MCU with Ethernet connectivity, it will continue to support many switching, actuation, and simple sensing applications.
Software at the heart, beyond AI algorithms
Beyond the development of AI systems to interpret the world around the vehicle and its responses to emergency situations, software development has taken center stage over virtually all vehicle functions.
In early vehicle platforms, software was used primarily to implement unique, advanced functions, such as ABS systems. Infotainment and the human interface have brought into the vehicle application software running on applications processors, similar to those found in smart phones. Vehicle chassis, powertrain, and safety features, along with infotainment, are increasingly delivered through software. This has given rise to the term Software-Defined Vehicle (SDV), where such a vehicle can be upgraded throughout its lifetime, enhancing existing functions and adding new ones.
Software upgrades for legacy, function-specific systems such as engine management were typically performed during a service visit, with the transfer taking place via a data cable. Delivering over-the-air (OTA) updates is an alternative that is beginning to see use by an increasing number of manufacturers. OTA updates from these OEMs include bug fixes, feature additions, or performance enhancements such as high-altitude driving or off-road handling.
When considered from a software perspective, an SDV can now be thought of as a mobile data center. New functions can be added years after the vehicle leaves the production line, reducing depreciation rates. Enhanced maintenance features could be sold as a package to enable the wear and tear of parts to be monitored in real time, with maintenance scheduled on actual usage rather than just miles driven.
However, automotive companies with limited experience implementing basic data center technologies will need to invest in new skills. Network management has become a functional skill area not previously required for stand-alone systems. Unique to automotive, functional safety processes, such as ISO-26262, married with data center hardware and software, affect electronic and software system development and implementation.
Potential trust barrier preventing adoption – cybersecurity is critical
The cybersecurity of autonomous vehicles is a key concern for consumers, with fears ranging from “virtual” hijacking to personal data being exploited. Surveys undertaken in Australia, the UK, and the USA have shown that over two-thirds of respondents express moderate to high concerns about the vehicle’s overall security, with a similar percentage expressing fear about data privacy. Compounding the concern, entertainment companies stoke fears about the security of connected vehicles for ratings, showing vehicle operation being hacked from afar, an act not possible in the great majority of today’s vehicles.
Valid examples of spoofing (tricking the systems into misreading signs) and hacking have, however, been reported in the media. For example, in 2020, researchers at McAfee tricked a driverless car into thinking the speed limit was 85 mph by altering a 35 mph sign with black electrical tape (an act that could work on a human driver, depending on several factors). In 2015, Wired magazine reported an experiment by ethical hackers to take over a connected vehicle (non-autonomous), disengaging both peripheral systems (air-con) as well as critical functions such as the accelerator. Though ten years of additional development have occurred, valid concerns persist in the minds of consumers.
Identifying the vulnerabilities is vital in preventing such attacks. In a 2020 literature review, the University of Texas, San Antonio, identified 21 points of vulnerability across four major classes of technological attack: positioning technologies, vision technologies, sensing technologies, and vehicle networks (V2V, V2X, and wired in-vehicle networks).
As a result, most OEMs now have dedicated personnel in security roles such as security architecture and threat vector analysis. Chip manufacturers have also responded, applying technologies such as MACsec to next-generation OEM Ethernet networks. In central compute clusters, technologies such as authentication and attestation ratified by the PCI-SIG support PCIe networks’ ability to ensure no unauthorized software is loaded and no unauthorized connections are made to the system. Security is another facet of data center learning that can and is applied to automotive systems.
As vehicle OEMs migrate towards the SDV, especially with OTA, they can provide regular software security updates and increase consumer protection without physically accessing the vehicle.
Cultural differences and issues of liability
The increase in driving assistance and automation may reduce the chance of a collision. Still, it also means OEMs are no longer simply selling the car to a driver and handing over responsibility for its use. Traditionally, OEMs were only liable in the event of a known fault, such as a weak steering column or a brake issue that wasn’t recalled. This is no longer the case, and laws are already being implemented to include manufacturers in the parties’ responsibility for some vehicle actions.
Waymo data suggests its cars are “three-and-a-half times more likely” to avoid collisions than a human driver. But what happens when the software makes a mistake? As Reuters put it last year: “Driverless car problems are outpacing liability laws.” Clearly, regional and national laws need to be defined to assign liability, but existing laws are not universally consistent. The situation gets even more complicated when we look internationally.
One of the most cited studies addressing this is a 2018 paper published in Nature that showed significant regional biases. Using an online series of image-based choices, researchers from MIT generated 40-million decisions from people in 233 countries, asking how individuals would prioritize numerous either-or situations: action over inaction, elderly versus adults, adults versus children, rich or poor, male or female, animals versus people, and even going so far as asking in one question cats versus dogs.
Autonomous vehicles need to consider countless outcomes when developing crash avoidance systems. Scenarios such as, is it right to change path to save two people when doing so would injure another person? Manufacturers may therefore need to determine in which countries they will market their vehicles and which level of driver assistance the vehicles will support based on regional laws.
Further, manufacturers may need to decide whether to create one set of policy algorithms for all or regional or country differences. Alternately, legislators may decide to take this option from manufacturers and force specific policy actions on a country-by-country basis.
Summary
On average, 40,000 people lose their lives each year on US roads. ADAS and autonomous vehicle technologies have the potential to reduce the number of fatalities. Research from the US drivers’ organization AAA suggests that adopting just six ADAS systems could reduce fatalities by 29%. Full autonomy could take this further.
The path ahead is not simple, and as we’ve seen, OEMs need to address several major challenges to address not only technological changes but also regional considerations.
Related EE World articles
Test 5G automotive designs for cybersecurity
10Base-T1S/L connects sensors in cars and buildings
What is the automotive SENT protocol?
Leave a Reply