Author | Gu Yang
Produced by | Automotive Electronics and Software
As the automotive industry enters a new era of intelligence and electrification, the core competitiveness of vehicles is undergoing fundamental changes, software is replacing mechanical components and becoming the “soul” of the vehicle. The Software-Defined Vehicle (SDV) has become a key force in reshaping the industry landscape. The core concept of SDV is to make software the main driving force behind vehicle functions, enabling dynamic definition and updates of vehicle functions, experiences, and performance through software, thus achieving continuous evolution throughout the vehicle’s lifecycle (pre- &post-sale).
It is well known that traditional vehicles are centered around mechanical and hardware components, with functions locked at the factory. Updating or enhancing vehicle performance often requires hardware replacement or a visit to the4S store for software flashing. However, SDV enables continuous evolution of vehicles throughout their lifecycle through centralized computing, modular software, cloud connectivity, and OTA updates. Vehicles are no longer static products but have become intelligent mobile platforms.
Example of Software-Defined Vehicle E/E Architecture
Software-Defined Vehicles have the following six key characteristics:
1. OTA Updates
Push system patches, feature upgrades, and interface optimizations via wireless connections to achieve remote maintenance and value-added services.
2. Centralized Computing Architecture
Integrate multiple ECUs into a central computing unit to enhance computing density and system real-time consistency, providing computational support for advanced functions such as autonomous driving.
3. Decoupling of Software and Hardware
Achieve generalization of hardware platforms and modularization of software functions, enhancing maintainability and flexibility, and supporting on-demand loading of functions.
4. Personalized User Experience
Provide customized cabin environments and driving suggestions through user identification, behavior learning, and cloud data analysis. Additionally, driver profiles can be stored in the cloud, allowing settings to be downloaded to any vehicle.
5. Advanced Connectivity Capabilities
Seamless integration of information flow inside and outside the vehicle, including V2X communication, 5G/6G networks, and remote vehicle control, providing a technical foundation for intelligent transportation and vehicle-road collaboration.
6. Autonomous Driving/ADAS Capabilities
Provide a unified platform and continuous evolution capability for autonomous driving systems, achieving deep integration of perception, decision-making, and control.
It is evident that software-defined vehicles have the following significant advantages:
-
Continuous Optimization: Vehicle functions can be continuously upgraded during use, providing value throughout the entire lifecycle upgrade.
-
Cost Reduction and Efficiency Improvement: Unified hardware platforms, enhance development and maintenance efficiency.
-
Accelerated Innovation: Modular software architecture supports agile development, accelerates iteration, and shortens the feature launch cycle.
-
Personalized Services: Users can choose functions and services on demand, enhancing their satisfaction and stickiness.
-
Improved Vehicle Safety: Rapid response to security vulnerabilities and compliance requirements, ensuring system and data security.
-
Expansion of Business Models: Introducing new profit channels such as subscriptions, feature unlocking, and software bundling.
-
Intelligent Operation and Maintenance:: Real-time diagnostics and predictive maintenance improve service efficiency and reduce operational costs and failure rates.
Thus, under the empowerment of SDV, automotive companies have begun to adopt the “Vehicle-as-a-Service” (VaaS) profit model. Vehicles are no longer one-time transactions but rather a platform that continuously provides services throughout their entire lifecycle. Let’s take a look at the business model of printers. When a printer is sold at an incredible price, even below its cost, the printer manufacturer relies entirely on the continuous sale of its ink or toner to offset the price difference and continuously generate profits. If we replicate this business model on SDV vehicles, we can view the vehicle as a printer, with the services and additional features provided as the printer’s ink.
Among the six advantages of software-defined vehicles, the vehicle’s E/E architecture plays a crucial role in achieving the first three, while the implementation of the latter four relies more on the acquisition and reuse of vehicle data.
This article will focus on exploring solutions that support the acquisition and reuse framework of vehicle data.
We have learned that data is the basis for continuously optimizing product experiences, is an asset supporting new business and service models, and is a tool for ensuring safety and compliance. The importance of vehicle data is undeniable, as the saying goes, “Data is king”.
However, vehicle data is not freely accessible. Typically, a pure electric vehicle’s power system software variables can reach up to2000 – 5000, limited by the vehicle’s hardware resources (memory, computing, bandwidth, etc.), only a small portion of this data is predefined at the factory and shared with the outside through communication interfaces (CAN, Ethernet, etc.), and the real-time nature of this data, i.e., its update/transmission frequency, is also limited by system resources. Achieving new functions, new services, and new predictive maintenance will generate demand for new data, while the predefined vehicle data obtained through communication interfaces may no longer meet the requirements. Our usual approach is to redefine the output vehicle data by updating and upgrading software (such as the power system software). However, frequent modifications, verification, release, and flashing (Homologation) undoubtedly increase the operational costs and safety risks of the vehicle.
To address this pain point, this article will introduce a new solution— the Connected Data Loop of Embedded System (CDL).
Data Loop Architecture of Software-Defined Vehicle Embedded Systems
As shown in the figure, CDL consists of two software units: Flexible Data Acquisition (FDA) and Shadow Mode in Sandbox (ShM). The two complement each other but can also exist independently, forming the architecture for vehicle-cloud data recycling (Framework).
Flexible Data Acquisition
Flexible Data Acquisition of Software-Defined Vehicles
As mentioned above, the typically predefined vehicle data is transmitted unidirectionally from the vehicle to the cloud, while FDA features bidirectional communication. This means that the backend (Cloud/Backend) can send data requests to the vehicle based on needs, and the vehicle can return the acquired data to the backend, thus meeting the needs of different functional services, which is the flexibility of data acquisition. Let’s explain its specific operation with an example. For instance, if the backend needs to obtain certain data from a vehicle’s power control domain to serve as input for its new service or diagnostic function, and this data is typically not available through the vehicle’s standard communication interface. With FDA, the backend can send its request in byte code that the vehicle controller can understand (Request), such as requesting to collect the instantaneous current of one phase of a three-phase motor at a certain frequency, and then, after performing simple mathematical calculations as required by the backend, return the acquired data to the backend. The data request is sent in the form of a campaign, transmitted from the backend to the vehicle’s central gateway via mobile network, and then the FDA Onboard Data Manager (ODM) forwards the request to the corresponding domain controller or a specific controller under the domain controller (Sub-Control Unit). Here, we can understand the transmission path of the instructions as similar to the arrangement of OTA flashing instructions. Next, the FDA agent on the controller begins the acquisition operation after translating the backend’s request, and then returns the data to the FDA ODM, which is then transmitted to the cloud via the central gateway through the mobile network. In this way, the backend can obtain the required data through FDA, forming a flexible data acquisition closed loop. When data acquisition is no longer necessary, the backend can issue a termination request, thus effectively releasing the corresponding system operation and computing resources.
In terms of data security, data acquisition will also be controlled by the security level of the data.
Shadow Mode in Sandbox
Shadow Mode in Software-Defined Vehicles
Shadow Mode was initially proposed by Tesla as a key testing and validation strategy in the development of autonomous driving systems. In simple terms, Tesla’s Shadow Mode allows the autonomous driving system to “quietly run” on the vehicle, but it does not control the vehicle; it only observes and makes predictions and decisions, which are then compared with the driver’s actual operations to evaluate the new system’s performance.
In the CDL system, the Shadow Mode (ShM) is also used to achieve similar functions, but it is not limited to autonomous driving. We can deploy any new functions that need testing and validation within the ShM sandbox, and also perform necessary preprocessing, filtering, or even compression of the data that FDA needs to upload. Compared to Digital Twin, the advantage of ShM lies in its ability to run relatively small functional models in real-time real-world scenarios without needing to replicate and simulate their operating environment 1:1 in the cloud, saving a lot of time and money. Moreover, the results and data validation tested through ShM are more direct and accurate. For the uploaded data, ShM can effectively capture time-sensitive and state-sensitive scenarios, filtering and processing the data to eliminate useless junk data and compress effective upload data, thus greatly reducing the pressure on data transmission bandwidth (mobile network) and operational costs.
The functions in the ShM sandbox run in the background and do not allow any impact or interference with the vehicle’s operation, so it must comply with the Freedom From Interference protocol. Specifically, ShM only possesses the lowest security level (QM), and neither data read/write nor runtime aspects can affect or interfere with the vehicle’s high-level safety functions.
Since we can deploy and update functions in the ShM sandbox through partial programming of the controller without changing the main software of the controller, it can also be applied throughout the vehicle’s lifecycle, just like FDA.
As shown in the figure above, the main software on the left side of the vehicle is locked and shielded, while ShM only has the authority to change the functions in the right-side sandbox.
Next, we will use two examples to better understand the functions and applications of CDL.
Example 1: Development of a Virtual Pressure Sensor:
Project Requirement:
Develop software (virtual pressure sensor) to replace the physical pressure sensor.
Simple Software Function Development Process:
The backend deploys the first version of the virtual pressure sensor software to the ShM sandbox via OTA, and FDA uploads the data obtained from the physical pressure sensor and the virtual pressure sensor in the vehicle to the backend. The backend analyzes and compares this data to further improve the virtual pressure sensor software, and the second version of the software is then deployed to the ShM sandbox. This cycle continues, and ultimately, we will obtain the most satisfactory version of the virtual pressure sensor software. The final version of the virtual pressure sensor software can then be integrated into the vehicle’s main software, while the physical pressure sensor is removed from the vehicle.
Example 2: Diagnosing Coil Winding Faults in Electric Motors:
Project Requirement:
Detect faults in the motor coils by deploying testing software.
Simple Software Function Development Process:
As a mass-produced vehicle, to reduce the data transmission load and costs, some important data can typically only be uploaded from the vehicle at a relatively slow frequency, which clearly cannot reflect time-critical operating conditions. Let’s assume that the data upload frequency to the backend is 10 milliseconds, while we need a sampling frequency of 100 microseconds to capture abnormal peaks in the motor coil current. We can deploy the corresponding detection software for the 100 microsecond process to the ShM sandbox via OTA, and then upload the relevant data and information obtained through FDA to the backend at a rate of 10 milliseconds for further diagnostic analysis.
Conclusion
In the era of “data is king” for software-defined vehicles, the data loop framework composed of FDA and ShM provides strong technical support for both new product development and aftermarket services.
/ END /