Relentless Innovation is Driving Software-Defined Vehicles into the Future
Learn how the OpenGMSL standard enables edge connectivity, linking sensors and displays to zonal compute nodes in a modern software-defined vehicle (SDV) architecture.
Since the late 1960s, when software was first used to regulate fuel injection in automobiles, the march toward integrating software into every aspect of a vehicle has been relentless.
From improving the driving experience to increasing safety for nearby pedestrians and vehicles, automobile manufacturers are teaming with partners to deliver vehicles that are continuously updated, easy to drive and maintain, and safer—and, more enjoyable than ever.
We have reached the end of the era when a new function was added to a vehicle by yet another electronic control unit, or ECU. Today, the focus is on reducing the number of ECUs— consolidating function-specific ECUs into a centralized computer, where they now exist virtually in the form of software. A few zonal controllers collect data from as many as 200 sensors around the vehicle and bring this data to the central computer—traversing as many as 70 percent fewer cables.
Since functions are defined in software operating on a few networked ECUs, they can be updated throughout the life of the vehicle and help deliver an always up-to-date user experience that helps to extend the life of the in-car hardware platform. Plus, enabling the in-car computer to access all sensor data now allows any function access to any physical sensor data, which enables smarter functions.
Here’s why that’s so important. With the increasingly capable edge computer in the vehicle, insights continuously derived from vehicle sensors can be exchanged with the cloud, which can offer even further insights. How? By combining data from a large fleet of vehicles on the road with data from other sources such as maps, weather, and real-time traffic data. This essentially creates “vehicle learning,” insights that vehicles share automatically, enabling each to learn and operate smartly and safely.
The Automobile as Server
The ideal hardware architecture for the software-defined vehicle maximizes the availability of data for every function. From a software point of view, this means that all data in a vehicle lives on the same in-vehicle network – and uses a single communication stack throughout the vehicle. This enables sensor data to be combined to improve functions in ways that were previously impossible.
Consider the “lowly” headlight. Once limited to low and high beams, modern headlights can use data from cameras and suspension to self-adjust the beam based on load distribution, road conditions, and approaching traffic without driver intervention. One can easily envision expanded capabilities in the not-too-distant future such as widening beams at intersections to increase visibility, or directing beams based on mapping data.
The same is true for windshield wipers, which have evolved from simple speed settings to rain-sensing with self-adjusting functionality. Together, these examples illustrate the trend: Vehicle features are no longer isolated but are interconnected through software. Any sensor can serve multiple functions, and any function can use data from multiple sensors, independent of the reason for incorporating the sensor in the first place.
The key to implementing a cost-effective SDV is networking, zonal aggregation, and the central compute unit—essentially a “server” within the vehicle that receives updates and has the intelligence to route each update to the appropriate component.
More Than an Engineering Goal
This is more than an engineering goal. These capabilities are being demanded by consumers. Drivers increasingly expect more immersive in-car experiences that require more sensors, higher- resolution displays, and rapid audio and video processing.
Automakers are turning to solutions such as Gigabit Multimedia Serial Link (GMSL) and E2B from Analog Devices (ADI) to create these experiences with a minimum of cables. That’s because they need standardized interfaces to achieve resilient supply chains and increase the availability of test solutions that can be used for the life of the vehicle.
In fact, we joined leading automotive original equipment manufacturers (OEMs), Tier 1 suppliers, semiconductor manufacturers, and ecosystem partners to form the OpenGMSL Association. All About Circuits covered this June 3, 2025 lauch with an exclusive interview. Its goal: To guide the development of an interoperable, open standard and promote global adoption. This will help shape the future of video and high-speed connectivity across automotive and adjacent industries. Its extensive support for both camera applications and more complex display applications makes it unique.

Overview of the OpenGSML effort and its background
‘Single-tool’ Solutions vs. Networking Efficiency
There are two classes of connectivity technologies – serial link and networking. In general terms, serial link technologies are less complex and, therefore, more cost effective.
Serial buses are “single-purpose tools” built for a specific application, like hammers or screwdrivers. They are built for specific functions and perform those functions well. But the number of product variants becomes untenable when there is a large diversity and ever-changing composition of data types and traffic patterns. This calls for more flexible solutions that can transport any kind of data (for example, multi-tools or “Swiss army” knives.)

Comparison of the two classes of connectivity technologies
This is where automotive Ethernet comes in—a single networking technology that has nearly unlimited flexibility in the data it can transport and, similarly, enables you to route that data anywhere. However, this flexibility comes at a cost. This high-diversity data is found in data flows between the in-vehicle ECUs. Data flows from peripherals to ECUs tend to be more well defined and one can live with less flexibility.
Given their general-purpose nature, Ethernet devices also are not as optimized for specific applications as more application-specific technologies, such as GMSL and A2B. Examples of such system-level capabilities include
- Real-time behavior: This includes low and deterministic latency, fast power-up, wake/sleep speed, synchronization, and resilience. For instance, low and deterministic latency is crucial in active noise cancellation; A2B can provide this low latency.
- Bandwidth: Video often requires more than 90% of the bandwidth in the car. When aggregating data from multiple cameras, the combined data bandwidth can exceed 50Gb/s. Video data for high-resolution displays also drives data bandwidth to multiple 10s of Gb/s, requiring application-specific video interfaces. Data for human vision can be compressed to good effect. Video link technologies, such as GMSL, support these interfaces and low-latency video compression.
- Safety and security: Different data in the car requires different levels of functional safety and security, and security has multiple aspects—including content protection, authentication, data integrity, and privacy. Different connectivity technologies support various safety aspects.
- Power and size: More data flows in the vehicle are asymmetric, meaning that a high data rate is needed in one direction while a much lower data rate is required in the opposite direction. Data in both directions flow on the same coaxial or single, twisted-pair cable. For instance, whereas a camera’s video data only flows in the forward direction, from the camera to the ECU, data flowing in the opposite direction carries much less bandwidth-intensive control data. Asymmetric implementations consume less power and silicon area than symmetric implementations, since they need a high-speed receiver at only one end of the link. Low power for “always-on” vehicle functions and remote wake-up also are areas where differences in technologies exist.
The situation with multiple connectivity technologies used in the vehicle is not unlike that found in the world of personal computers, where they may be networked with Ethernet while peripherals are often connected using more cost-effective technologies such as USB, DisplayPort interface, HDMI, or Bluetooth. Technologies to connect peripherals are very cost sensitive since there are so many. For the same reason, you want to minimize the cost of the peripherals in a car by controlling them from the host ECU. For this, you need cost-effective technologies that control and power each peripheral from the host.
Three different paradigms. (Click image to enlarge)
That being said, there are cases where both low-cost and networking aspects are desired. For instance, with camera connectivity, you want the component in the camera to have very low cost and power consumption. But you also want the flexibility to send the data to multiple ECUs, and maybe to mass storage and to diagnostics ports. For this reason, we envision a future of technology convergence.
Path to a Unified Network through Converging Technologies
So, we see a future where Ethernet and serial buses will become more similar in some critical respects. Serial buses, such as GMSL and A2B, are likely to absorb the advantages of Ethernet, while Ethernet is likely to absorb advantages of serial buses.

The path to a unified network means technology convergence.
Serial buses need standardization, plug-and-play functionality, bridging, some native networking aspects, and hardware abstraction. Ethernet, on the other hand, is absorbing advantages of serial buses, such as efficient and cost-effective physical layers, safety layers, determinism, faster startup, application-specific endpoints, and host control. Emerging standards like IEEE 802.3dm, E2B, and upcoming remote-control protocol from the Open Alliance will help maximize the potential of Ethernet-based networking.
Shown below is a before and after comparison of SDVs of the future.

BEFORE: the challenges of multiple in-vehicle technologies

AFTER: engineering a flexible, unified SDV network with centralized software
A Better Driver Experience
Successfully integrating these technologies will bring us closer to a unified architecture for the software-defined vehicle of the future and an improved user experience. For drivers, the result will be seamless, secure updates that are just as intuitive as updating a smartphone and all its applications. For car makers, it means platform variants and increased reuse going from one vehicle platform to the next
All images used courtesy of Analog Devices
