Standardizing the communication to connect sensors and displays

There is a consensus in the automotive industry that a standard for the high-speed connection of cameras and displays will be needed in the future. However, the path to this is still open. It could look like this.

With the advances of driver assist functions towards autonomous driving, the number of cameras and sensors in cars is increasing. This changes the requirements for the communication technologies that connect those sensors. These changes, thereby, do not only affect technical aspects such as data rate, networking capabilities, and includability into a holistic security concept. One of the core concerns is that up until today, satellite cameras (and displays) are connected using non-interoperable, proprietary Automotive SerDes technologies. There seems consensus in the industry that a standardized technology is needed to connect cameras and displays in the future. However, for many, the exact when and how is not so clear, despite of and/or because of the options available for future implementations. This article reasons requirements and solutions to move the industry forward and explains why there is a chance for change now, provided swift and united actions.

It is risky to consider a standard “nice to have”

Today, cameras and displays are connected using proprietary SerDes technologies. The data rates supplied by these technologies match the resolutions of the typical video streams. Many of the respective products are well established and in series production. Furthermore, as there is more than one proprietary solution available, prices and capabilities are competitive. From this seemingly comfortable position, a standard can easily be perceived as an abstract concept that is “nice to have”, resulting in no immediate need for action.  
Such a stance is risky. To establish a standard needs a significant forerun, and not supporting its fast establishment today, limits being able to react to foreseeable market changes in the near future. Taking the example of cameras, obvious changes are:

1. The number of cameras in cars is increasing drastically (3-fold between 2020 and 2030, see Figure 1). This makes costs and single-source (supply) dependencies ever more critical.
2. In the past, cameras were bought in closed systems that included the link, so that the link technology was exchangeable with the system. Now, car manufacturers start buying camera modules from multiple Tier 1 suppliers who are additionally different from those Tier 1s who supply the Electronic Control Units (ECUs) that process the camera data. In this case, it is possible and desirable to renew individual cameras or processing ECUs at different points in time. However, the need for backwards compatibility locks the vendor in case of proprietary technologies. With every additional camera, the change-over to a different technology becomes more difficult and costly.  
3. More cameras and more connections between units of different suppliers make testability and interoperability ever more important.
4. Finally, EE-architectures are changing. This leads to new connectivity concepts for cameras in addition to the today typical Point-to-Point (P2P). Examples are aggregation, inclusion in zonal ECUs, or forwarding of video data (e.g., for redundancy reasons), and, of course, making use of Ethernet networking capabilities. This change might not be as immediate as points 1.-3., but it is the postulated direction of the industry.     

The basis to address all four points is a large eco-system for the used communication technology, whose establishment has to start now. With multiple proprietary solutions, a large eco-system for each is close to impossible to achieve. In contrast, for a successfully established standard, a large eco-system is the logic outcome. A large eco-system means:  

1. Multiple vendors have innovative and interoperable products. This does not only suggest competitive pricing (which exists also in case of multiple proprietary technologies). Next to better supply guarantees, and the possibility to avoid vendor lock-ins, multiple vendors have a better chance to offer an overall well-diversified product portfolio. This includes optimized products for all the new architectures – aggregation, zonalization, forwarding, …  – with the right set of internal and external interfaces. Furthermore, there will be integrated products. In these latter, the communication function is just one feature of a chip with more purposes, such as imaging, controlling displays, processing radar data, switching Ethernet, or general-purpose processing/System on Chips (SoCs). Integration makes the real difference, as it provides the basis for costs and (PCB) space savings not attainable otherwise.
2. A standard incentivizes a support industry to develop around it, with tools and test and the establishment of respective support organizations such as OPEN Alliance or the Automotive SerDes Alliance (ASA). To have such organizations, ensures non-discriminatory and transparent access to information plus a shared workload.   

As can be seen in Figure 1, the market size justifies a large eco-system. Just the market for camera, radar, and display ports is larger than (but in the same order of magnitude of) all ports for Automotive Ethernet or the complete Ethernet market outside of automotive! Communication standards provide essential infrastructure for innovative changes. With “nice to have” today, the options for high-speed communication maybe the limiting factor for innovations tomorrow.

In substitution scenarios half measures are not forgiven

For a new communication standard to succeed there needs to be the prospect of profit that serves the customers as well as the suppliers. Suppliers look for business opportunities. Customers look for new functionalities and/or cost downs. A standard is an essential means to achieve these in case of communication technologies, as discussed above. However, a standard provides the framework only. Especially in a fierce substitution scenario, it is important that a new solution provides all potential benefits from the start. What these are is discussed in some more detail in the following.
The base requirement for suppliers is access to the technical specification (and its necessary Intellectual Property, IP). For a standard, this is ensured by the organization the standard is published in. Especially when there is no early adopter bonus in a substitution scenario, it helps, if suppliers can play out their strengths in respect to the implementation. This includes a choice in process technologies, allowing implementation preferences (analog, digital, mixed signal), re-use of existing IP, and alike. It also helps if suppliers can address a large share of the market with few products (multi-speedgrade PHYs, serializer = deserializer, …).
The supplier side thereby requires a careful balance. Equal distribution of expertise and IP among vendors provides more incentive than a situation in which a single company has a significant head start, e.g., by having provided the technology. At the same time, not seeing enough competitive edge for the own development might also discourage suppliers from making the investment. It is thus understandable when suppliers fight for the best starting position in a standardization project. However, if this waters down the customer requirements (of a multi-vendor market or any of the requirements as listed below), this helps no one, except for the existing technologies the new solution aims to replace.  
The requirements from the customer perspective can be grouped into the following four categories:

1. Functional technology: Naturally, the technical solution needs to sustain in the challenging automotive environment. This includes the support of the right data rates (whether ~10 Gbps is sufficient is some matter of debate in the industry) and up to 15m link lengths (four inline connectors) for electromagnetic emissions and immunity. Furthermore, low power consumption is key (the imager sensor quality degrades with temperature) and in case of multiple coordinated sensors, especially radars, synch precision in the ns range is required. Mind though, meeting the technical targets is a necessary condition (but not necessarily sufficient) for the success of the technology. Overfulfilling the requirements typically only helps in corner cases, but regular customers would not want to pay for it. Of course, known deficiencies should be improved, but more promising for success is also meeting the requirements of bullet points 2-4.
2. Attractive costs: A successful standard is associated with attractive semiconductor costs, simply through competition and economies of scale. However, in this case it is worth looking at the cost for qualification and system costs additionally. The latter includes the cabling options (coaxial with power over is a must) and the external components as they might be needed (crystal, ESD protection, bias-T types for power over, power supplies, …). Integration scenarios as discussed above allow for further cost reductions by reducing the number of chips and PCB area. Costs resulting from architectural choices have impact, too. Qualification costs are typically lower in case of a standard because of better infrastructure and reuse.
3. Additional features: One of the most important new features for sensors is security, also because it is a legislative requirement for autonomous driving use cases (see also UNECE R155 and R156). In today’s camera implementations, the only option is to rely on the vendor specific security functions of the imagers, as the proprietary SerDes solutions do not yet offer sufficient link-based security. While imager security, and the security of the upcoming MIPI Camera Service Extension (CSE), allow to fulfil the legal requirements, they substantially burden the processor that processes the sensor data. Link-based security offered with the communication technology is the only sensible solution, especially if considering that the number of cameras is going to triple. Another important feature is to allow flexibility in the architecture. That implies efficient P2P, aggregation, zonal, forwarding, and other options. It also includes the possibility to connect sensors via “SerDes” or via “Ethernet” and to allow a smooth transition in between. Today’s camera communication technologies are optimized to transport camera video data and the processors have their processing chains optimized for the used camera video protocol, typically MIPI CSI-2. Without the right technology, switching to Ethernet means either using it as another SerDes with dedicated chips (and no reuse with standard Ethernet components) or changing the processing chain, i.e., changing not just the communication technology but also the processors (see Figure 2). If either requires too much effort, and the standard technology cannot compete in a P2P scenario, it is not going to happen. 
4. Timing: Finally, it is most important to consider, when a change and adoption of a standard solution can happen. Typically, eight to ten years are required between the initiation of a communication standard and its introduction in its first series production car (see Figure 3 for timing at BMW). Industry-wide rollout takes yet many additional years; in case of 100BASE-T1 Ethernet, e.g., eight. This long lead-time is required also, because car manufacturers can typically only introduce a new communication technology with a new Electrics and Electronics (EE) architecture (which additionally must offer the right window of opportunity forthe new technology). As these EE architectures are developed in distinct timeframes, typically every three to seven years, a manufacturer might have just missed the next opportunity. With the number of cameras (and radars and displays) on the rise, every year longer it takes for the industry to provide a standardized solution for replacing proprietary SerDes, the more cameras are connected using proprietary technologies, the more severe the vendor lock-in, the more difficult and costly (and unlikely) the change. It is thus important that the change over to a standard can start now. Considering a yet new development risks the complete enterprise of establishing a standard. Considering meeting only half the requirements also has a negative impact.

Unity is required

Up to here, this article discussed why a standard is needed for connecting cameras and displays (and radars that change to a satellite architecture) and what this standard must provide to be successful. This next part discusses the actual options.
Today’s (satellite) camera and display implementations use one of the proprietary Serdes technologies to connect the units. In subsequent efforts for a standard, first the MIPI Alliance ratified the MIPI A-PHY specification, then the Automotive SerDes Alliance (ASA) ratified the ASA-Motion Link (ASA-ML) and ASA-MLE (E for Ethernet) specifications. In July 2023, the IEEE 802.3 started a project for “Improved Support of Asymmetric Applications for MGbps Ethernet Cameras (ISAAC)”, which was numbered IEEE 802.3dm, when moving to Task Force (TF) in March 2024. Many in the industry look to this project to harmonize the industry in respect to the future camera (and other asymmetric communication) high-speed connectivity. The directions IEEE 802.3dm can take are the following:    

1. Add a coaxial channel to the existing IEEE 802.3ch and potentially improve Energy Efficient Ethernet (EEE).
2. Base the solution on ASA-ML(E).
3. Develop a new, likely Frequency Division Duplexing (FDD) solution.
4. Base the solution on one of the existing FDD technologies, which are dominated by one vendor (i.e., one of the proprietary solutions or MIPI A-PHY).

With the Option 4 not only requiring approval of the respective entity, but also giving a very (too?) large head start to the vendor dominating it, it seems an unlikely option. It is therefore not part of Table 1, which shows the results of a qualitative rating as seen by the author. As can be seen, in the authors opinion, adopting an ASA-ML(E)-based solution in the IEEE project is the most promising way forward, and most promising is what is needed to be successful in a substitution market situation. It is understood that consensus building, and technical proof is still necessary in the IEEE TF. However, Table 1 also emphasizes the importance to include also not-primarily technical items in the decision-making process. I invite everyone to join the process to move the industry forward. Unity is the way to reach the stars.