Software-Defined Networking for the Software-Defined Vehicle

The software-defined vehicle (SDV) is one of the newest and most interesting megatrends in the automotive industry. As we discussed in a previous blog, the reason that this new architectural—and business—model will be successful is the advantages it offers to all stakeholders:

• The OEMs (car manufacturers) will gain new revenue streams from aftermarket services and new applications;
• The car owners will easily upgrade their vehicle features and functions; and
• The mobile operators will profit from increased vehicle data consumption driven by new applications.

What is a software-defined vehicle? While there is no official definition, the term reflects the change in the way software is being used in vehicle design to enable flexibility and extensibility. To better understand the software-defined vehicle, it helps to first examine the current approach.

Today’s embedded control units (ECUs) that manage car functions do include software, however, the software in each ECU is often incompatible with and isolated from other modules. When updates are required, the vehicle owner must visit the dealer service center, which inconveniences the owner and is costly for the manufacturer.

The software-defined vehicle changes the status quo in several ways:

• Software-defined vehicles will be able to dynamically reconfigure and programmatically control ECU software so it can be updated more easily and frequently; 
• The ECUs that previously managed individual functions can be consolidated to manage multiple tasks, which simplifies the vehicle. 

Previously, we discussed the benefits of an Ethernet-based network in the vehicle that allows it to be reprogrammed and to easily adapt to new applications. This is what a software defined network (SDN) is all about.

What is a Software-Defined Network?

An SDN decouples the network control plane from the data or forwarding plane, physically moving it away from on-premises networking equipment—in-vehicle networking equipment in this case—to the cloud. This physical separation enables the establishment of a centralized control function that, in the vehicle case, allows the OEM to manage, via 5G cellular, all its customers’ in-vehicle networks, with no need to visit the service center. The OEMs can further incorporate user-defined applications and traffic-forwarding policies that, thanks to SDN, can be programmed as needed to be aware of these applications and their associated bandwidth and security needs.

Practical implementations of the in-vehicle SDN

Let’s discuss two new potential applications, and analyze how the SDN can support these applications:

Application 1: “Catch the Car Scratcher.” How many times have we heard of, or even been in, this situation? Someone accidentally scratches your car in the parking lot or maliciously scratches your car with a key. What if the car were able to capture the face of the person or license plate number of the car that caused the damage? Wouldn’t that be a cool feature an OEM could provide to the car owner on demand? If priced right, it could become a popular application. The application would use the accelerometers, and potentially a microphone, to detect the noise caused by scratching, bumping or hitting the car. Once the car identifies the scratching or bumping, it would activate all the cameras around the car. The car would then record the video streams into central storage. This video could later be used by the owner as necessary to recover repair costs through insurance or the courts.

Application 2: “Break-in Attempt Recording.” In this next application, when the system detects a break-in attempt, all internal and external cameras record the video into central storage and immediately upload it to the cloud. This is done in case the car thief tries to tamper with the storage later. In parallel, the user gets a warning signal or alert by phone so they can watch the video streams or even connect to the sound system in the car and scare the thief with their own voice.

To explain how in-vehicle SDN can support these proposed applications, let’s consider a high-level zonal architecture that includes central compute, storage and 5G modem (also called Telematics Control Unit or TCU), as shown in Figure 1.

Figure 1 – Zonal architecture with central compute, storage and 5G modem

During regular operation of a car with such an architecture, video streams from selected cameras are routed to central compute where vision analytics are performed using machine learning (ML); and data from other sensors, such as radar and lidar, is fused with the video. The central compute then calculates the path of the car based on collision-free spaces, lane boundaries and other obstacles in which the vehicle is expected to maneuver. These spaces, also called corridors, are calculated using the Simultaneous Location and Mapping (SLAM) algorithm. The SLAM algorithm uses high-definition maps that are continuously updated from the cloud and stored in the SSD.

For these specific tasks, the in-vehicle network is configured to:

• Stream video from cameras and sensors to the central compute;
• Route downloaded HD maps from the TCU to the SSD storage (in bursts);
• Route HD map data from the SSD to the central compute;
• Route commands to the steering, acceleration and braking systems in the car, over the network; and
• Support quality-of-service (QoS) that will enable the smooth operation of the vehicle using network switches and gateways that provide highest priority for steering, acceleration, and braking commands.

Now let’s see how the described functionality applies to our potential new applications. When the car is parked, and the “Catch the Car Scratcher” feature is activated, the in-vehicle network is then configured for data routing that’s different from that used in daily operation:

• Data from an accelerometer(s), as well as local microphones, are routed to the central compute (or a different low-power controller, if it exists in the car).
• When the central compute detects a vibration or a scratching sound, it turns on all the cameras. The network routes the video streams to SSD storage, while balancing the traffic in the network to prevent video-frame dropouts.
• In parallel, central compute sends a warning notification to the cloud (and car owner) through the TCU and can also upload images from the cameras.

For the “Break-in Attempt Recording” application, the in-vehicle network would be configured in a different fashion:

• Upon activation of this feature—when parking in a garage, for example—cameras at each corner of the car continuously send low-resolution video (to reduce power) to the central processor, to detect intruders. The car alarm system also sends notification messages to the central compute.
• If an intrusion is detected, the cameras are configured to send HD video streams to the central compute.
• The central compute compresses the video streams and writes them to the SSD storage.
• To avoid the risk of the SSD storage and the video evidence being stolen by the thief, the video streams from the SSD storage are simultaneously uploaded to the cloud via the TCU.
• The TCU also sends an alert to the vehicle owner since they may want to investigate the alarm immediately.

These applications are simplified examples that we use to describe how in-vehicle SDN can serve new and different applications. Actual configurations would be more complex and would need to support different Ethernet layers, quality-of-service, load balancing and overall network performance optimization. Additionally, the services themselves must be provisioned. These collective requirements are met in many cases by the Ethernet standard itself and, in other cases, by special-purpose software.

Sonatus software manages SDN capabilities

Sonatus’s vehicle infrastructure management software is such an example. The Sonatus Network Configuration Manager optimizes in-vehicle Ethernet network configuration and performance, and dynamically controls communication within, into, and out of the vehicle, which is necessary to dynamically provision the services described in these scenarios. Similarly, the Sonatus Service-Oriented Architecture (SOA) and Quality of Service (QoS) management software allow for dynamic service addition and configuration. They facilitate the connection of new traffic sources, such as cameras or microphones, to add capabilities like those described above and ensure mission-critical traffic is prioritized. These software components serve to ease application management and facilitate the quick and reliable deployment of new features.

Marvell switches and features that power the in-vehicle SDN

Automotive Ethernet is one of the key enablers of in-vehicle SDN; and an end-to-end Ethernet network is required to realize the scenarios above. The Marvell® Brightlane™ Automotive Ethernet portfolio supports the design and implementation of such end-to-end Ethernet networks using three product categories: switches, PHYs and bridges.

• The Brightlane switch family includes multiple port-count options and high security in the form of 802.1AE MACsec, Trusted Boot and deep packet inspection (DPI). The switches further support deterministic networking requirements with Time-Sensitive Networking (TSN) and 802.1BA Audio Video Bridging (AVB) standards.
• The Brightlane Ethernet PHY family supports the full range of Automotive Ethernet standards from 100BASE-T1 to 10GBASE-T1, including 802.3ch-compliant multi-gig PHYs. Brightlane PHYs further support 802.1AE MACsec and 802.1AS Precision Time Protocol (PTP). All Brightlane PHYs are AEC-Q100 Automotive Standard-compliant.
• Brightlane multi-gigabit Ethernet bridges directly connect to automotive-grade cameras, and other devices via the CSI-2 interface as defined by the MIPI Alliance. They implement the Ethernet physical layer portion of the 802.3ch 10/5/2.5GBASE-T1 standard.

This blog contains forward-looking statements within the meaning of the federal securities laws that involve risks and uncertainties. Forward-looking statements include, without limitation, any statement that may predict, forecast, indicate or imply future events or achievements. Actual events or results may differ materially from those contemplated in this blog. 前瞻性声明仅在发表当日有效。 Readers are cautioned not to put undue reliance on forward-looking statements, and no person assumes any obligation to update or revise any such forward-looking statements, whether as a result of new information, future events or otherwise.