Software-Defined Networking (SDN), well known for years in the network architecture of data centers in the IT world, is now under serious consideration to be implemented into future vehicle e/e architectures to realize the next generation of mobility solutions economically.
SDN does not just sound very similar to SDV, which stands for Software-Defined Vehicle, it may also become a vital part of the technical solution for it. The software-defined vehicle is a term used to describe the gradual transition from hardware-driven development to software-defined development. New functions will be implemented primarily through software and can be made available to the vehicle through regular updates and throughout the whole life cycle of a car. As a result, a personalized user experience is being created for end customers that is always state of the art.
This blog will explain how SDN can help to create vehicles that are flexible in configuration in order to elevate the user experience to the next level.
So what exactly does SDN mean? SDN is a system design paradigm that separates the data plane from the control plane. The physical network elements can be dynamically reconfigured by the SDN controller that manages the network. Traditionally a network in a car is a designed network with a static routing matrix that is defined at the time when the car is built. SDN now allows for reconfiguring the network dynamically depending on the use case of the car or even to mitigate a failure condition. It also allows the creation of Virtual Local Area Networks (VLANs) on the fly, supporting each flavor of virtualization concepts. In other words, the physical network can be separated into logical networks with various functions.
Figure 1. Network configuration with SDN
Although the main communication infrastructure of the data plane is supposed to be Ethernet, it can consist of any type of network, including legacy protocols such as CAN, LIN, and FlexRay. The SDN model is separated into a management plane that hosts the applications and functions of a vehicle. Then, via the so-called northbound interface, it communicates with the control plane that has central control over the physical network. From there, it connects via the southbound interface to the data plane that keeps all of the physical network resources. That separation allows flexibility that is needed in case the operation and use case of the vehicle changes. Examples of this are an Over-the-Air update (OTA) that requires more network resources towards the target ECU that gets the update or the changeover from manual driving to semi-automatic or fully autonomous driving that focuses the network with priority on sensors and actuators. Also, cyber security is part of that system that may require changing network streams if a cyber attack is detected.
Figure 2. North- and southbound interface explanation in SDN (source: Bosch)
A central function of SDN is network reconfiguration which is dedicated to the control plane. The control plane has a global view of the abstracted network elements and its state, where state means the utilization of free and used resources. It is a logically centralized coordination of decentralized communication devices. The controller can calculate a global routing solution that is then translated into local configurations of the network devices, such as forwarding rules, tables, traffic shapers, and filters.
Although SDN does not require a specific physical network, it is assumed that automotive Ethernet will be used as the major medium. It can provide a quality of service (QoS) with the help of Time-Sensitive Networking (TSN) functions. Keeping the latency requirements of the system is a central condition for any network, and this specifically holds true for SDN. Therefore, the use of TSN-based Ethernet will be a central requirement. However, since TSN has many features, a profile needs to be defined that maps only some of the TSN features to the SDN requirements.
Use Cases
Let's imagine an ECU needs an update or a new feature, e.g., ADAS or infotainment has been purchased from the OEMs upgrade shop. Those features may require additional software to be installed, which is handled by an OTA update. The SDN can then set up a secure and performant path from the cloud down to the target ECU. Although there are studies that such an upgrade could be done while driving the example here shows the network configuration while the car is in the safe parking state. The SDN function focused on dynamic routing and on-demand bandwidth allocation for that use case.
Figure 3. OTA update while parking under SDN control (source: Jaspar)
The next example shows the network configuration when changing over from manual driving to automated driving. A lot of network resources are redirected to support camera and radar functions. The SDN focuses on dynamic routing and flexible redundancy.
Figure 4. Manual driving vs. automated driving with SDN (source: Jaspar)
Finally, an example of the network configuration when a security attack has been detected. SDN will focus on blocking and filtering messages to isolate the attacked unit and to operate the car with minimum resources and risk.
Figure 5. Network blocking during security attack (source: Jaspar)
Potential Issues and Hurdles
SDN offers huge flexibility and is intended to simplify the network setup and management for future generations of e/e architecture. However, as known from the IT world, it requires a lot of CPU resources and software that is standardized and can be reused across all OEM platforms. It also requires specific measures to prevent the SDN controller from becoming a single point of failure. Last but not least, the definition of a standard for SDN in automotive is important so that vendors can concentrate on unified hardware design reducing the overhead of unused features. So, same as with Ethernet in automotive, which was introduced first by BMW in 2008 to speed up the flash process in the service garage, it may take another 10 years until SDN fully moves into the automotive space.
Renesas Support for SDN
Renesas can already support PoCs and initial implementations of SDN with our R-Car S4 SoC that offers significant CPU resources combined with all automotive I/Fs such as CAN, LIN, FlexRay, PCIe, and automotive Ethernet. On the Ethernet side, it supports the TSN standard, which is one of the preconditions to provide the QoS required by SDN. The R-Car S4 even has an Ethernet switch integrated that allows hardware routing on Layer 2 (MAC address routing) and Layer 3 (IP address routing) and offers all of the flexibility that SDN needs in terms of network reconfiguration. For more details, please, refer to our "Communication Gateway/Car Server Chipset Solution with R-Car S4 and Tailored PMIC" blog or the R-Car S4 product information.
References:
[1] P802.1DG – TSN Profile for Automotive In-Vehicle Ethernet Communications | ieee802.org
[2] SDN in Automotive, Bosch IEEE Techday 2018 | ieee.org
[3] What is the conqueror in the SOA platform for the future in-vehicle networks?, Jaspar IEEE Techday 2021 | ieee.org
[4] Proposal of Dynamically Configurable In-Vehicle Network as an Enabler of Software Defined Vehicle?, Jaspar IEEE Techday 2022 | ieee.org
[5] Open technology platform for the software-defined vehicle | bosch-mobility-solutions.com
[6] Communication Gateway/Car Server Chipset Solution with R-Car S4 and Tailored PMIC
[7] Renesas Next Generation Automotive Vehicle Computer VC4 – A Winning Combo Solution with R-Car Ecosystem Partner Support
[8] The Art of Networking (Series 1): VC3, Evaluation System for New E/E architecture
[9] The Art of Networking (Series 7): TSN in a Virtualized Environment