As advanced driver assistance systems (ADAS) lead to autonomous driving, there’s an increasing need for multiple copies of aggregated video sensor data for machine vision, viewing, parallel processing and data logging.

The need for multiple copies is especially true for forward-looking machine vision cameras, but it will soon apply to additional cameras, radar and light detection and ranging (LIDAR) sensors in autonomous vehicles. A very common application for replication today is data logging (Figure 1). In machine-vision applications, it is common to record raw sensor data about certain driving events for future analysis. In such cases, it’s useful to have a second copy of the aggregated raw sensor data for data recording, while the other copy is used for machine-vision processing.

Replicating Aggregated Sensor Data

Data replication is possible in different places in the video path. It’s possible to connect each sensor via separate cables to both machine-vision and data-logging electronic control units (ECUs), but doing so doubles the number of required cables. Instead, it is often simpler to split the data after sensor data aggregation. For example, the DS90UB964-Q1 quad deserializer hub can aggregate raw data from up to four disparate sensors and create two copies of the combined data without external components such as splitters and bridge chips. Machine-vision algorithms (such as object recognition) can process one stream, while the other stream is recorded to memory for data logging (Figure 2). The connected sensors need not all be the same; combining multiple sensors of dissimilar type, resolution and speed can enable true sensor fusion systems. For example, you can merge data from a combination of cameras with different frame rates as well as separate radar sensors.

Figure 3 shows a four-camera system, with different data rates shown by the colored blocks. The aggregated data is presented at both the mobile industry processor interface (MIPI) camera serial interface (CSI)-2 ports 0 and 1. The CSI-2 bus is “bursty,” meaning that it operates at a fixed data rate, blasts data as available and reverts to a low-power (LP) state when idle. Thus, the sensor speed can vary without changing ECU processor timing. Even though the sensor links are running at independent frequencies, the deserializer hub presents data to the system-on-chip (SoC) processor on a single reference clock, simplifying system timing.

The DS90UB964-Q1 supports MIPI CSI-2 virtual channel ID remapping. Virtual channels separate sensor data in the aggregated stream so that the processor can easily determine which packet comes from which sensor instead of having to count bits in bit-stuffing approaches. The processor simply reads the virtual ID (VC-ID) field in the header to determine the virtual channel address. If the sensors already use identical VC-IDs, they can be remapped to unused VC-IDs to distinguish the incoming data. With up to 1.6Gbps/lane, a total of 6.4Gbps bandwidth per port is available to support four +1MP/60 fps, 2MP/30fps or satellite radar sensors – or a combination of different sensors.

Conclusion

Data logging will play an ever-more-important role in ADAS and especially autonomous driving applications. Replicating sensor data is often most efficient right after sensor data is already aggregated. New products integrate the replication function to eliminate external splitters and bring new architectural possibilities to future automotive ADAS applications. To learn more about ADAS camera and radar applications, log in to leave a comment or visit TI’s SerDes portfolio.

Additional Resources

• Check out the industry's first dual-port MIPI CSI-2 quad deserializer hub with replication mode.
• To get started quickly on your design, download the TI Designs “Automotive ADAS 4 Camera Hub Reference Design with Integrated ISP and DVP Outputs.”
• Pair our deserializer hub with the TDA3x SoC processor for ADAS.
• Learn more about TI’s ADAS solutions.