Looking Ahead: High-Speed In-Vehicle Display and Sensor Connections

Article By : Carrie Browen and Kevin Kershner, Keysight Technologies

If the last 20 years have been linear in the development of electrification, the last two to three years have been exponential.

This month’s In Focus looks at the latest developments, challenges, opportunities, and strategies in the electric vehicle (EV) space.

It is no secret the pace of innovation in the automotive industry is exploding. If the last 20 years have been linear in the development of electrification, the last two to three years have been exponential.

It used to be that a car was a means of getting from A to B. Now, we can safely say that is not true for the vehicles of today and certainly not for the new vehicles of tomorrow. Just about every new car on the market has a backup camera, park assist, and blind spot monitoring. Some offer a 360-degree view. Other features offer real-time traffic updates, cellular connection to potential hazards, other road users, vehicles, or pedestrians. There are features that can detect if a driver is distracted or tired. Meanwhile, the people in the car are often unaware of driving conditions, while they enjoy infotainment systems. These features are delivered through a mixture of sensors, cameras, and networks.

As demands go up, next-generation advanced driver-assistance systems (ADAS) require camera and radar systems with increasingly high resolution. That means more speed and bandwidth for networks, switches, and the connections that carry the data. Innovation in automotive technology has rapidly accelerated to accommodate advanced automotive technologies that run at greater than 1 Gbps date rates over existing cabling infrastructures. Higher bandwidth and lower latency networking will play a critical role in addressing time-sensitive and complex automotive technologies to come.

Many of these requirements can be met by automotive Ethernet with a bandwidth of up to 10 Gbps. When you consider the requirements for some of the cameras are up to 3,500 Mbps, we must also consider another technology to move that data around.

Bandwidth Requirements

To get a better understanding of the bandwidth requirements, remember that the approximate bit rate of a video stream can be calculated as:

Frame Size = Resolution x Color Depth
Bit Rate = Frame Size x Frame rate

So, for an ADAS camera capturing a 1080p image, with a color depth of 24-bits and transmitting at 30fps, the bit rate to be supported equals:

Frame Size = 1920 x 1080 x 24 = 49,766,400
Bit Rate = 49,766,400 x 30 = 1,493 Mbps

The table below shows typical volumes of data from the different sensors involved in autonomous driving:

Industry requirements

The automotive market is driven by many motivators. A few of the most influential motivators in the automotive market include:

Increasing demand for high bandwidth and lightweight materials
Rising demand for driver assistance systems
Rise in demand for luxury vehicles
Future-proof technology
Improved data security

We have already established the need for high bandwidth technologies and keeping weight down to maximize fuel (or battery) efficiency. All the sensors for backup views, parking, and lane-change assist, not to mention newer heads-up and co-driver displays, plus any additional infotainment systems, stems from the demand of ADAS and autonomous vehicle (AV) technologies.

In addition, network architects need to understand how the vehicle will be required to scale as the technology improves. Today, the expectation is that you will have a car for 10 to 15 years.  If cost-effective interconnect solutions can provide support for additional bandwidth, they may need to consider designing them today to allow for added ADAS/AV heavy features customers will want during the life of the vehicle. And of course, safety is another ultra-important area for vehicle design. As more AV and ADAS features take over functions from humans there is a very big focus on passenger safety.

Zonal architecture

Engineers are always trying to reduce complexity, and this is true with in-vehicle networking.

Figure 1 is an abstract version of a vehicle using may different data rates in the backplane. It is an oversimplification, but for the sake of this discussion, it helps us imagine how some of these technologies and standards work together.

Figure 1: A conceptual diagram of a zone-based in vehicle network architecture.

A zonal architecture will pull together multiple inputs and ultimately lower the complexity, cost, and weight of the wiring harness, transitioning from a “many to one” architecture to a daisy-chained, one-to-one architecture. This is an example of a zone-based architecture, while others are considering a domain-based architecture. Both will aggregate camera and sensor data, where Ethernet acts as an interconnect between each zone or domain. Because a central computing complex is linked to the sensors and devices through networked zonal gateways, a zonal approach can provide better scalability as well as improved reliability and functionality.

Introduction of SerDes

In today’s infotainment systems, it is common for in-vehicle cameras and displays to be connected to the image-processing electronic control unit (ECU) via a SerDes (serializer/deserializer) connection. Today, they are delivered by individual vendors using closed, proprietary standards.

Extending the reach of feature-rich SerDes links can require operating at lower Baud rates and higher order modulations (e.g. PAM-4). In addition, it will require higher bandwidth Ethernet links as primary interconnects between zones perhaps with 802.3ch supports up to 10 Gbps throughput.

Emerging SerDes standards like mobile industry processor interface (MIPI) A-PHY (MIPI A-PHY is a physical layer specification targeted for ADAS/ADS surround sensor applications and Infotainment display applications in automotive) and Automotive SerDes Alliance (ASA) will be implemented by multiple silicon vendors. This will create a competitive market that acts to drive down the cost while delivering application specific features. There is also a desire to have standardized test methods throughout the ecosystem that establish interoperability requirements. For implementers and test vendors, this would unify requirements for silicon, tier ones and original equipment manufacturers (OEM’s). Unified test requirements allow silicon vendors, tier ones, and OEM’s to accelerate their development cycle, lower costs, and improve interoperability with other commercial devices.

Figure 2 is an example of a use-case for automotive displays. This diagram is from the MIPI Alliance with the reference to the newly released A-PHY standard.

Some of the features of next-gen SerDes support the Service Oriented Architecture of the future with protocol tunneling and adaptation which will enable emerging SerDes standards to forward legacy automotive protocols along daisy-chained links to the appropriate ECU or bridge device. Stream duplication provides a means for safety-critical systems to duplicate themselves if the primary link fails. Daisy-chaining will allow multiple SerDes ports to be connected back-to-back, aggregating data on the link, before it arrives at the ECU. Finally, functional safety is being addressed by providing end-to-end protection mechanisms that comply with ISO 26262.

These features are welcome in the next generation of ADAS/AV developed cars, but there are also a few challenges to overcome, including different media dependent interface (MDI) cables and connectors, securing the network, interoperability with other vendors and technical concerns of Tx testing ensuring linearity and PSD of PAM-N networks. It will also be critical to validate the robustness of receivers against electromagnetic interference (EMI) to ensure operation in the harsh automotive environment. This is a complex measurement that involves injecting pre-defined, calibrated levels of noise at the RX pin of the SerDes while monitoring its ability to clock symbols within acceptable error limits.

Physical layer testing

Interoperability is a real concern. Transceivers are sensitive devices that must operate in the notoriously harsh automotive environment that includes heat, vibration, electro-static discharge (ESD), and EMI.

We break this into three different areas of testing: transmission – making sure that what is sent is what you expect. Receiver capability – how reliably can your device (gateway, module, switch, PHY) receive the correct signals. Finally, the performance of the passive interconnect between transceivers known as the link segment. Physical layer validation includes all three of these elements.

Ultimate goals for all this testing is interoperability between vendors of different devices. There could be over 100 different vendors that contribute to one car and there are standards organizations that create specifications. These applications are a way to evaluate against known standards to ensure the data integrity is maintained.

Transmit testing

In the case of the transmitter, we are looking to ensure that the signal characteristic is good. So, we use a tool that acts as a receiver – in this case an oscilloscope. The device under test (DUT) is put into a series of known states and the acting receiver makes sure the signal is ‘valid’.

Figure 3: View of vehicle backup camera demonstrating gaps in the transmission.

Figure 3 is an example of a backup camera view with lines in it. The lines equate to gaps in the transmission, dropped packets. One or two and we can still see the image, but we certainly don’t want it to blink black when there is a child behind you.

The camera is made by one vendor, the cable by another vendor, the switch that routes the signal, likewise the GPU or ECU that processes the data, and then the brakes that ultimately need to stop the car. These are made by different vendors and need to work together, thereby underlining the importance of interoperability.

In addition, the data rate is going up >100X->1000X faster than CAN and growing a lot more complexity when there is a higher speed signal. The modulation type has become increasingly complex. Legacy standards like CAN use NRZ or PAM-2, as compared to PAM-3 or PAM-4 4 for Automotive Ethernet and automotive SerDes. So, these Tx tests also need to check data integrity which include:

Jitter tests as clock errors can cause transmitter jitter.
Power spectral density, which is a noise measurement (using a fast Fourier transform (FFT) or spectrum analyzer) over a frequency range, because PCB traces can behave as antennas at high speeds.
Linearity test to look for any distortion caused by reflections, which can in turn cause transmitter errors and bit errors.

Ultimately, we need to ensure that the data does not cause radiation emissions, reflections, or attenuations, and doesn’t interfere with other circuits. If it doesn’t pass one of these tests it will lead to symbol or packet errors that lead to dropped frames at the receiver, or lines in the display like we saw before.

Channel testing

The cable, connector, fixture, or harness connecting these devices together is the link or the channel.

A vector network analyzer (VNA) can characterize the impact the channel has on the signal, making sure signal integrity is maintained between the transmitter and receiver. Given the cable lengths used in the harsh automotive environment, it’s crucial to look at impedance versus frequency to predict how the channel will perform within the vehicle.

A link segment consists of cables plus inline connectors, along with mating connectors at either end. Ultimately the wire harness is responsible for moving control and payload data, as well as for providing DC power to remote sensors.

Channel characterization for SerDes link consists of both time domain and frequency domain analysis. This requires looking at the cabling system, the MDI, and the fixturing and test setup requirements.

The actual MDI connector is not standard, but there are some rigid specifications to help ensure that interactions between the MDI and cable are minimized. Figure 4 provides an example of an H-MTD connector that is being used for multi-gig automotive Ethernet and could also be used for emerging SerDes standards.

Figure 4: Example of MDI connector with H-MTD and SMA.

When we look at the channel tests, we are looking for errors such as:

Impedance mismatch
Signal distortions or defects
Cross talk between the cables

Receiver Testing

Receivers are responsible for making sense of the data sent over the link, then passing it along for further processing in an ECU or display device. Bit errors at the receiver result in lost or corrupted data coming from safety-critical sensors like camera, radar, and Lidar.

Proper receiver functionality becomes increasingly difficult for complex modulations like PAM-4, especially when sent over long channels exposed to many simultaneous sources of noise. To characterize the receiver’s capabilities, one must measure error levels in the presence of multiple noise sources, including:

Narrow band interference
Bulk current injection
Transients on-line
Alien cable bundle crosstalk

The measurement setup can include noise sources, amplifiers, and coupling circuitry that allow precise levels of noise to be injected onto an active SerDes link. The DUT’s signal quality registers are then queried to verify whether the receiver could interpret symbols correctly in the presence of noise. The emphasis in receiver testing is to stress the receiver to ensure it can still maintain BER rates.

Future Prediction

More cameras, more connections, and more sensors with greater accuracy, less weight, and increased safety. Undoubtedly, there will be a need for an in-vehicle network to seamlessly handle these challenges. Those in-vehicle networks will need to be tested, they will need to be interoperable, and they will need to be secure.

References

About the Authors

Carrie Browen is the autonomous vehicle business line product manager for Keysight Technologies. With over 20 years in the industry, she is responsible for translating and articulating Keysight solutions to convey the most important points to those that would find value in them. Carrie has a BS in electrical engineering, lives and enjoys the Colorado mountains, likes to garden, is horrible at hula hooping and can be convinced to try new things especially by her 3 teenage boys.

Kevin Kershner is responsible for defining the requirements for Keysight’s future IVN solutions. Kevin actively participates in MIPI A-PHY, ASA and VESA standards meetings. With 16 years in the industry, he is particularly good at understanding a technical issue from all angles and explaining it to others. Kevin has a BS in Electrical Engineering from UCLA, and currently lives near Chicago. Kevin’s passions outside of work include bicycling, general aviation, and traveling the world with his wife.