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:
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:
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:
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:
For the “Break-in Attempt Recording” application, the in-vehicle network would be configured in a different fashion:
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.
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. Forward-looking statements speak only as of the date they are made. 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.
Tags: Brightlane, Brightlane Ethernet PHY, Brightlane switch family, central compute, ECU, embedded control units, In-vehicle SDN, Mapping algorithm, multi-gigabit Ethernet bridges, SDN, SDV, SLAM algorithm, software defined network, software-defined vehicle, TCU, Telematics Control Unit