More cameras, more connections, more testing

7 min read

With the rapid development and roll-out of high speed in-vehicle display and sensor connections so more testing will be required, as Carrie Browen and Kevin Kershner explain.

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.

Today, 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 but 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.

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 Colour Depth
  • Bit Rate = Frame Size x Frame rate

So, for an ADAS camera capturing a 1080p image, with a colour 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

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; future-proof technology and improved data security.

We have already established the need for high bandwidth technologies and keeping weight down to maximise 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.

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

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 to 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 (serialiser/deserialiser) 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 standardised 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.

Some of the features of next-gen SerDes support the Service Oriented Architecture of the future with protocol tunnelling 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.

The ultimate goal 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 organisations 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’.

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 over a frequency range, because PCB traces can behave as antennas at high speeds, and linearity tests 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 analyser (VNA) can characterise 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 characterisation 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 minimised.

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 characterise 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 and 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.

Author details: Carrie Browen is autonomous vehicle business line product manager for Keysight Technologies and Kevin Kershner is responsible for defining the requirements for Keysight’s future IVN solutions.