“Software-defined vehicle (SWdV)” and the impacts on the onboard network

From domain architecture to zone architecture – the software-defined vehicle (SWdV) and requirements for data cables of the future

When reading trade articles from the automotive industry, two terms repeatedly pop up that you simply cannot avoid. On the one hand, we keep reading about “zone architecture”, and then, also in this context, there is a lot of talk about the “software-defined vehicle (SWdV)”.

So what are these terms all about and how are they impacting future vehicle generations? It’s precisely these questions that we want to answer in this blog post.

A glimpse into the past: complex wiring and considerable weight

What do the terms “zone architecture” and “software-defined vehicle” (SWdV) mean? How are they impacting future vehicle generations? To answer these questions, let’s take a brief trip back in time. The first type of onboard network topology was called “distributed architecture” or “modular architecture”. In this system, all sensors and actuators were connected individually and directly to one control unit. Each sensor or actuator possessed the necessary intelligence for its function, and only control signals and processed measurement signals were transferred via cables and bus systems (typically, Lin bus or Can bus systems) to the control units. Several hundred sensors and up to a hundred control units were installed in every vehicle. Individual cables measured up to 16.5 m in length and as a result, it was not uncommon for the total length of cables in the vehicle to exceed the kilometer mark! The consequences were: extremely complex wiring and seriously heavy wiring harnesses.

Modular architecture

Each control unit had to be exclusively programmed with specific software (firmware) for its own function. A firmware update could generally only be performed directly on the device by means of a special programming cable. This meant that a visit to the specialist car repair shop was necessary, and updates were only carried out in the rarest of cases.

Later enhancements of the vehicle’s functions with additional features proved to be very difficult – or even unfeasible. For each function, at least one additional cable had to be laid right across the vehicle and connected to a control unit. Often a firmware update would also need to be carried out on the control unit in order to support the new function. But the effort involved soon exceeded the intended benefit.

With an increasing number of vehicle functions, including in the area of safety and comfort, it didn’t take long before the limits of this type of wiring were reached.

And that was when “domain architecture” was born.

The current state of technology: domain architecture

Unlike “modular architecture”, domain architecture follows the approach whereby the sensors and actuators are arranged according to their functions and tasks (domains). Different functional domains such as drive, comfort or infotainment were defined, each of which is monitored and controlled by a higher-level control unit, the domain control unit (DCU). The connection to the sensor/actuator is made via a low-performance bus connection (e.g. Lin bus or Can bus). The DCUs themselves are connected to a high-performance and service-oriented network known as the gateway (e.g. Ethernet). Therefore, retrofitting an additional domain or a DCU with a new function such as an Advanced Driver Assist System (ADAS) can be carried out easily at any time.

Domain architecture

However, the disadvantage of this technology soon becomes apparent when functions that belong to one domain cannot be physically installed in the same position in the vehicle. Resulting once again in long cables to connect the DCU to the sensor or actuator. Take, for example, the indicator function: at least 6 indicator lights have to be wired in various corners of the vehicle, but all of them are controlled by one DCU. This type of vehicle topology is currently still state-of-the-art!

However, the automotive world is currently experiencing major changes.
In addition to replacing combustion engines with alternative drives, the “autonomous driving” megatrend is occupying the entire industry and demanding new concepts for tomorrow’s onboard network.

The onboard network of the future: zone architecture and the software-defined vehicle

Undoubtedly, domain architecture offers several advantages. However, in order to tackle the complexity of modern vehicles and address future requirements, a different approach is needed: that of zone architecture.

By taking a zone-based approach (zone architecture), unlike with a domain-oriented solution, the functions are arranged according to their position in the vehicle rather than according to their tasks.
In a basic car, there are maybe only four zones – one for each corner of the vehicle. All devices in one physical zone are controlled by one zonal control unit, or also by a zonal gateway or Electronic Control Unit (ECU). In turn, these zonal control units are connected to a central processor via a backbone link (high-speed data connection).

All tasks in one physical area, whose monitoring is performed by a zonal control unit, are assigned to this zone. So, for example, lighting, image sensors, indicators, brakes, steering, suspension, etc. can be combined into one common zone.

Zonal architecture

In addition to simplifying wiring in the vehicle, modularity and flexibility play a very important role in enabling the advantages of this solution to be fully exploited.

Here, modularity means that different tasks can be carried out with one and the same hardware (e.g. identical ECUs).

Flexibility is the ability to carry out updates, bug fixes, configurations and even add-ons with no great effort for the driver. Thanks to the “over the air” function, it is possible to carry out these tasks with an internet connection, without having to visit a car repair shop. The vehicle looks to see whether any updates are available, and completely independently uploads or installs the software on its ECUs. Options and enhancements can be purchased and installed by the vehicle owner in the same way as when smartphone users visit app stores of well-known mobile phone operating system providers.

In order to also achieve this level of modularity and flexibility on a practical level, these functions need to be mapped in software instead of in hardware in the future.
Here too, the modern smartphone serves as a good example of the way in which apps offer users a wide variety of functions and applications. You can use your smartphone to make phone calls, take photos or help you find your way. If you want to, you can even use it for your banking transactions or to catch up on social media.

In the car, this approach is known as “software-defined vehicle”.
Virtually all functions in the vehicle are no longer implemented via hardware-based control units but rather by a program (app) which handles the tasks on a universal control processor (zone controller). The advantage is that many apps can be run at the same time (multi-tasking) and therefore all functions in one zone can be implemented on just one zone controller. Of course, this requires extremely high processing power as well as a large number of interfaces to the sensors/actuators that have to be built into the zone controller.

The task of these zone controllers is also to communicate with the central processing unit. For this purpose, data that is sent to these central systems is pre-filtered and prioritized beforehand by the zone controller. This dramatically reduces the complexity of the system, and the processing unit can focus on processing relevant data (e.g.: ADAS functions, evaluating image data, etc.).

Data connections between the zone controllers and the central processing units require fast and reliable communication.  Automotive Ethernet solutions (e.g. MultiGiG) are the means to an ends here.

This connection is known as the backbone.

Zonal Gateway communication – Central processor

The “software-defined vehicle” approach is inevitably leading to a major paradigm shift for OEMs. Until now, car manufacturers have always been experts in the technology (hardware) installed in the vehicle. However, functions as well as the creation of value are now shifting almost completely from hardware to software.

The focus is no longer on the vehicle itself, but much more on its function, and this is tailored to the customer’s requirements. However, software development has not really been a core competence of OEMs. And that’s why we can already see different trends appearing in this area. While some companies, often younger ones, are tending to move in the direction of software service providers or complete systems, e.g. Android from the house of Google, “more traditional” OEMs are endeavoring to keep the expertise in-house and investing in the development of their own software departments. It will be exciting to see which of these directions will prevail in the long run.

What is equally interesting is that completely new business models are emerging here.

The function itself is no longer tied to the vehicle. Used car dealers or even customers can retrofit new functions relatively easily and thus create added value for the vehicle. Therefore the value of the car is maintained over its life-cycle or could even be increased.

Use of functions with limited validity or a subscription solution can now also be offered.

A further advantage is that the vehicle can communicate with its environment. It can collect data during operation and store it in a Cloud. This exchange of data enables continuous improvement of functions and services that can then be upgraded again on-the-fly in the vehicle. Direct communication between several vehicles is also technically feasible. All these possibilities are another important milestone on the road to autonomous driving.

Outlook: huge demands on processing power and data cables

Of course, it’s going to take time before onboard network architecture switches to zone architecture. Challenges such as the necessary processing power and data cables for 25 Gbit/s or more still need to be addressed. However, according to estimates, it could happen by 2030. All over the world, technicians are already working intensively on solutions.

With its product range, MD ELEKTRONIK is an extremely strong and competent partner who is focusing on precisely these requirements. We offer the right solution for coaxial, UPT, STP and USB products as well as for optical data transmission. Thanks to our highly automated production strategy, our products also meet the highest quality requirements. 

Summary

The automotive world is currently undergoing extreme change. It’s not just the switch to electric driving that is posing great challenges for car manufacturers. They also need to come up with solutions for the idea of a “smartphone on four wheels”.

One key approach here is to increase the effectiveness of the onboard network by replacing the high number of individual “point-to-point” cables with a few high-performance network cables (such as MultiGiG Ethernet). On the one hand, the advantage here is that a considerable amount of weight can be reduced. However, at the same time, this is a huge challenge for ECU manufacturers, as many functions which were previously implemented in individual sensors or actuators, are now being integrated into the ECU as software solutions. These two approaches are described as “zone architecture” and “software-defined vehicle” (SWdV).

Conclusion

The requirements in terms of processing power and data transmission are extremely high and there is still much room for improvement. Data cables of the future must be designed for reliable transmission in the range of 25 Gbit/s or faster. In this respect, optical data cables are becoming an increasingly popular alternative to copper-based solutions.

(*)
UTP – Unshielded Twisted Pair
STP – Shielded Twisted Pair