Data storage method, system, electronic device and vehicle

Abstract

The application provides a data storage method, system, electronic equipment and vehicle, relates to the technical field of vehicles, and is used for the comprehensive performance of data storage. The method comprises the following steps: in response to receiving a data write request, splitting to-be-stored data carried by the data write request into a plurality of storage data slices; for each storage data slice, determining additional information corresponding to each storage data slice; the additional information at least comprises at least one of the following: a write time of the storage data slice, a function call address of initiating the data write request, a write starting position of the storage data slice, and a write length of the storage data slice; combining each storage data slice and the additional information corresponding to each storage data slice to obtain a plurality of combined data slices; and writing the plurality of combined data slices into a storage unit of a domain controller.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, specifically to a data storage method, system, electronic device, and vehicle. Background Technology

[0002] With the rapid iteration of electronic technology, domain controllers are evolving towards higher functional complexity and continuously increasing system integration. Today's domain controllers not only need to integrate multiple core functional domains such as powertrain, chassis, cockpit, and autonomous driving, but also generally adopt a multi-core architecture to support the collaborative operation of many distributed applications.

[0003] Against this backdrop, most related technologies employ methods such as direct writing of the entire data or simple partitioned storage for data storage. However, these methods suffer from low data storage efficiency and poor data quality, which seriously affect the operational reliability of multi-core architectures of domain controllers. Summary of the Invention

[0004] This application provides a data storage method, system, electronic device, and vehicle to solve the problem of poor overall performance of data storage in the prior art.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0006] In a first aspect, a data storage method is provided, applied to a domain controller. The method includes: in response to receiving a data write request, splitting the data to be stored carried by the data write request into multiple storage data slices; for each storage data slice, determining additional information corresponding to each storage data slice; the additional information includes at least one of the following: the write time of the storage data slice, the function call address that initiated the data write request, the write start position of the storage data slice, and the write length of the storage data slice; combining each storage data slice and the additional information corresponding to each storage data slice to obtain multiple combined data slices; and writing the multiple combined data slices into the storage unit of the domain controller.

[0007] Based on the aforementioned technical means, this data storage method divides the data to be stored into multiple storage data slices and appends additional information such as write time, function call address, write start position, and length. During data verification, anomaly tracing, or fault diagnosis, this additional information allows for precise location of the data source and storage location, facilitating rapid anomaly detection. Furthermore, dividing the data to be stored into multiple combined data slices allows for independent processing of each slice during data storage. This not only improves the quality of data storage but also increases its efficiency, thereby comprehensively enhancing the reliability and efficiency of data storage, and ultimately improving the overall performance of data storage.

[0008] Furthermore, the data to be stored carried by the data write request is split into multiple storage data slices, including: determining a first preset length threshold based on the data write request frequency of the function type to which the data to be stored belongs; the first preset length threshold is negatively correlated with the data write request frequency; and splitting the data to be stored into multiple storage data slices when the length of the data to be stored is greater than the first preset length threshold.

[0009] Based on the above technical means, the size of the first preset length threshold is determined according to the data write request frequency. When the data write request frequency is relatively high (high-frequency data), a small threshold is used to force the data to be split into small slices, which can make the amount of data written in a single transaction smaller and the processing time shorter, thereby avoiding serial blocking caused by a single large slice occupying core resources, thus ensuring the lifespan of the storage unit.

[0010] Furthermore, the data to be stored is divided into multiple storage data slices, including: dividing the data to be stored according to a second preset length threshold to obtain multiple storage data slices; the second preset length threshold is equal to the first preset length threshold minus the preset length corresponding to the additional information.

[0011] Based on the above technical means, in the storage design of the domain controller, the preset length of the additional information is fixed. The size of the combined slice is precisely controlled by the second preset length threshold to ensure that the split data units can be processed efficiently without exceeding the preset storage performance boundary.

[0012] Furthermore, in response to receiving a data write request, the data to be stored carried by the data write request is split into multiple storage data slices, including: in response to receiving a data write request, determining whether there is data corresponding to the function type in the storage unit based on the function type to which the data to be stored carried by the data write request belongs; if there is no data corresponding to the function type in the storage unit, the data to be stored carried by the data write request is split into multiple storage data slices.

[0013] Based on the above technical means, by first determining whether the functional type data exists, and then performing standardized splitting on the new data, it can ensure that the data stored for the first time can be accurately and quickly stored in the storage unit of the domain controller, and avoid resource waste caused by duplicate storage.

[0014] Furthermore, the above method also includes: when data corresponding to a function type exists in the storage unit, determining the target combined data slice corresponding to the data to be stored from multiple combined data slices of data corresponding to the function type; determining the additional information corresponding to the data to be stored; and updating the target combined data slice based on the data to be stored and the additional information corresponding to the data to be stored.

[0015] Based on the above technical means, by accurately locating the target slice and performing local updates, the amount of stored data is reduced to the minimum while ensuring data consistency (only the single slice that has changed is updated, rather than the entire set of data), thereby improving the storage efficiency of the domain controller in data iteration scenarios.

[0016] Furthermore, writing multiple combined data slices into the storage unit of the domain controller includes: determining a target writing strategy for the multiple combined data slices based on the importance of the data to be stored and / or the data write request frequency of the functional module that generates the data to be stored; if the target writing strategy is a synchronous writing strategy, writing the multiple combined data slices into the storage unit in response to a data write request; or, if the target writing strategy is a timed writing strategy, writing all the combined data in memory within a preset time interval into the non-volatile memory of the domain controller at preset time intervals; the storage unit includes: memory and non-volatile memory; or, if the target writing strategy is a power-down writing strategy, temporarily storing the multiple combined data slices in memory, and writing the combined data into the non-volatile memory of the domain controller in response to receiving a power-down command.

[0017] Based on the above technical means, a differentiated writing strategy is dynamically matched according to the importance of data and the writing frequency. Important data that is written frequently is cached or optimized for batch writing, while low-importance data is delayed until power-off for centralized processing. This ensures that the data is recorded and also balances the number of erase and write cycles of the storage unit to extend its lifespan.

[0018] In a second aspect, a data storage system is provided, comprising: a first domain controller and a second domain controller; the first domain controller is configured to, in response to receiving a first data write request sent by a configuration module, store the data to be stored carried in the first data write request based on any optional data storage method in the first aspect; the first domain controller is further configured to send a second data write request to the second domain controller, the second data write request being used to request the second domain controller to store the data to be stored; the second domain controller is configured to, in response to receiving the second data write request, store the data to be stored carried in the second data write request based on any optional data storage method in the first aspect.

[0019] Based on the above technical means, after the first domain controller completes data storage, it actively initiates a synchronization request to the second domain controller. The dual domain controllers use a unified data storage method to perform storage, which can ensure that the data stored in the two domain controllers always remains completely consistent, realizes redundant backup of critical data, and avoids the risk of data loss caused by single controller failure.

[0020] Furthermore, the first domain controller is also configured to send a data retrieval request to the second domain controller to retrieve second stored data corresponding to the first stored data; the first stored data is the data already stored in the first domain controller, and the second stored data is the data already stored in the second domain controller; perform a consistency check on the first stored data and the second stored data to obtain a check result; if the check result indicates that the first stored data and the second stored data are inconsistent, send a second data write request to the second domain controller.

[0021] Based on the above technical means, by having the first domain controller actively initiate data comparison and update data when there is inconsistency, it is possible to detect inconsistencies in the stored data between the two domain controllers in real time (such as synchronization omissions or content deviations caused by storage anomalies). By resending write requests, the stored data of the two domain controllers can be synchronized, ensuring that the backup data of the second domain controller is always consistent with the baseline data of the first domain controller.

[0022] Furthermore, the first and second stored data are vehicle configuration information, which defines the vehicle's control functions. Before sending the second data write request to the second domain controller, the first domain controller is also configured to determine the target data in the first stored data and the target vehicle control function corresponding to the target data. The target data is used to instruct the first domain controller to modify the data in response to the first data write request. Based on the target vehicle control function and the mapping relationship between vehicle functions and services, the target service identifier corresponding to the target vehicle control function is determined. One target service identifier corresponds to one vehicle control function. Based on the target data and the target service identifier, data to be stored is generated.

[0023] Based on the above technical means, after the first domain controller updates the first storage data stored locally, it can extract the difference data and generate synchronized content by associating service identifiers. This ensures that the data to be synchronized is the latest and accurate partial update (rather than the full data), thereby achieving accurate cross-domain data synchronization.

[0024] Furthermore, the second domain controller is configured to determine the target storage data slice corresponding to the data to be stored based on the target service identifier and the mapping relationship between the service identifier and the data location; and update the target storage data slice based on the data to be stored.

[0025] Based on the aforementioned technical means, the second domain controller can quickly locate the target slice and perform partial updates based on the service identifier, skipping the scanning and rewriting of the entire data, thereby completing data synchronization with minimal operations, significantly improving update efficiency and reducing the erase and write losses of storage units.

[0026] In a third aspect, an electronic device is provided, comprising: a processor and a memory configured to store processor-executable instructions; wherein the processor is configured to execute the instructions to implement any of the optional data storage methods described in the first aspect above.

[0027] Fourthly, a vehicle is provided, including the aforementioned electronic equipment and data storage system.

[0028] Fifthly, a computer-readable storage medium is provided, on which instructions are stored, such that when the instructions in the computer-readable storage medium are executed by a device, the device is able to perform any of the optional data storage methods described in the first aspect.

[0029] In a sixth aspect, a computer program product is provided, the computer program product including computer instructions that, when executed on a processor of a device, enable the device to perform any of the optional data storage methods described in the first aspect above.

[0030] The beneficial effects of this application are:

[0031] (1) This data storage method divides the data to be stored into multiple storage data slices and adds additional information such as write time, function call address, write start position and length. During data verification, anomaly tracing or fault diagnosis, the additional information can be used to accurately locate the data source and storage location, which facilitates rapid anomaly investigation. In addition, dividing the data to be stored into multiple combined data slices, during data storage, since the length of a single slice is small, each slice can be processed independently, which can not only improve the quality of data storage, but also improve the efficiency of data storage, thereby comprehensively improving the reliability and efficiency of data storage.

[0032] (2) Determine the size of the first preset length threshold according to the data write request frequency. When the data write request frequency is relatively high (high frequency data), use a small threshold to force split into small slices, which can make the amount of data written in a single instance smaller and the processing time shorter, thereby avoiding serial blocking caused by a single large slice occupying core resources, thus ensuring the lifespan of the storage unit.

[0033] (3) In the storage design of the domain controller, the preset length of the additional information is fixed. The size of the combined slice is precisely controlled by the second preset length threshold to ensure that the split data units can be processed efficiently without exceeding the preset storage performance boundary.

[0034] (4) By first determining whether the functional type data exists, and then performing standardized splitting on the new data, it can ensure that the data stored for the first time can be accurately and quickly stored in the storage unit of the domain controller, and avoid resource waste caused by duplicate storage.

[0035] (5) By accurately locating the target slice and performing local updates, the amount of stored data is reduced to the minimum while ensuring data consistency (only the single slice that has changed is updated, rather than the entire set of data), thus improving the storage efficiency of the domain controller in the data iteration scenario.

[0036] (6) Based on the importance of data and the frequency of writing, a differentiated writing strategy is dynamically matched. Important data that is written frequently is cached or optimized for batch writing. Low-importance data is delayed until power-off for centralized processing. This ensures that the data is recorded and balances the number of erase and write operations of the storage unit to extend its lifespan.

[0037] (7) After the first domain controller completes data storage, it actively initiates a synchronization request to the second domain controller. The dual domain controllers use a unified data storage method to perform storage, which can ensure that the data stored in the two domain controllers always remains completely consistent, realizes redundant backup of critical data, and avoids the risk of data loss caused by single controller failure.

[0038] (8) By actively initiating data comparison by the first domain controller and updating data when data is inconsistent, it is possible to detect inconsistencies in the stored data between the two domain controllers in real time (such as synchronization omissions or content deviations caused by storage anomalies), and synchronize the stored data of the two domain controllers by resending write requests, ensuring that the backup data of the second domain controller is always consistent with the baseline data of the first domain controller.

[0039] (9) After the first domain controller updates the first storage data in the local storage, it can generate synchronized content by extracting the difference data and associating the service identifier. This ensures that the data to be synchronized is the latest and accurate partial update (rather than the full data), thereby achieving the accuracy of cross-domain data synchronization.

[0040] (10) The second domain controller can quickly locate the target slice based on the service identifier and perform local updates, skipping the scanning and rewriting of the full data, thereby completing data synchronization with the fewest operations, significantly improving update efficiency and reducing the erase and write losses of storage units. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the structure of a data storage system proposed in this application;

[0042] Figure 2 This is a schematic diagram of the structure of a memory unit of a domain controller proposed in this application;

[0043] Figure 3 A flowchart (I) illustrating a data storage method proposed in this application;

[0044] Figure 4This is a schematic diagram of a combined data slice proposed in this application;

[0045] Figure 5 A flowchart (II) illustrating a data storage method proposed in this application;

[0046] Figure 6 A flowchart (III) illustrating a data storage method proposed in this application;

[0047] Figure 7 A flowchart (IV) illustrating a data storage method proposed in this application;

[0048] Figure 8 A flowchart (V) illustrating a data storage method proposed in this application;

[0049] Figure 9 This is a schematic diagram of the structure of a data storage device proposed in this application;

[0050] Figure 10 This is a schematic diagram of another data storage device proposed in this application;

[0051] Figure 11 This is a schematic diagram of the structure of an electronic device proposed in this application. Detailed Implementation

[0052] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0053] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0054] With the rapid iteration of electronic technology, domain controllers are evolving towards higher functional complexity and continuously increasing system integration. Today's domain controllers not only need to integrate multiple core functional domains such as powertrain, chassis, cockpit, and autonomous driving, but also generally adopt a multi-core architecture to support the collaborative operation of many distributed applications.

[0055] Against this backdrop, most related technologies employ methods such as direct writing of the entire data or simple partitioned storage for data storage. However, these methods suffer from low data storage efficiency and poor data quality, which seriously affect the operational reliability of multi-core architectures of domain controllers.

[0056] Based on this, this application proposes a data storage method, system, electronic device, and vehicle applied to a domain controller. The method includes: responding to a received data write request, splitting the data to be stored carried in the data write request into multiple storage data slices; for each storage data slice, determining additional information corresponding to each storage data slice; the additional information includes at least one of the following: the write time of the storage data slice, the function call address that initiated the data write request, the write start position of the storage data slice, and the write length of the storage data slice; combining each storage data slice and the additional information corresponding to each storage data slice to obtain multiple combined data slices; and writing the multiple combined data slices into the storage unit of the domain controller. This data storage method, by splitting the data to be stored into multiple storage data slices and attaching additional information such as write time, function call address, write start position, and length, can accurately locate the data source and storage location during data verification, anomaly tracing, or fault diagnosis, facilitating rapid anomaly troubleshooting. Furthermore, dividing the data to be stored into multiple combined data slices, during data storage, because the length of each slice is small, allows for independent processing of each slice, which not only improves the quality of data storage but also increases the efficiency of data storage, thereby comprehensively improving the reliability and efficiency of data storage.

[0057] The data storage method, system, electronic equipment, and vehicle of this application are described below with reference to the accompanying drawings.

[0058] like Figure 1 As shown, this application proposes a data storage system, including: a first domain controller 101 and a second domain controller 102.

[0059] The first domain controller 101 and the second domain controller 102 each include multiple cores (core 0-core 5), storage units, and SOA service interfaces.

[0060] In some embodiments, a domain controller integrates functions (such as powertrain, cockpit, and autonomous driving) that were originally distributed across multiple independent electronic control units into a single hardware platform. Through unified hardware resource allocation, software management, and data interaction, the complexity of the vehicle's electronic systems is reduced, and operational efficiency is improved. In intelligent driving vehicles, domain controllers can be functionally divided, such as a powertrain domain controller, or location-based, such as a front cabin domain controller. By uniformly analyzing multi-source sensor data (such as camera, radar, and millimeter-wave radar), coordinating cross-domain functional requirements, and securely storing and transmitting vehicle data, the vehicle can achieve precise adjustment of power output, personalized adaptation to cockpit scenarios, and decision-making and execution for autonomous driving.

[0061] In some embodiments, the core, serving as the computing brain of the domain controller, typically employs a multi-core heterogeneous processor. This multi-core heterogeneous processor can integrate units with different architectures, such as general-purpose computing cores, real-time control cores, and dedicated acceleration cores, enabling on-demand allocation of computing power. It can meet the response requirements of high real-time tasks, provide high-density computing power for complex data processing, and optimize energy efficiency through differentiated power consumption design, perfectly adapting to the heterogeneous needs of multiple tasks (such as real-time control, data parsing, and intelligent decision-making) in the domain controller.

[0062] Within this architecture, different cores can be assigned tasks as needed: for example, cores 0 and 1 are responsible for real-time control (such as power output adjustment), cores 2 and 3 are responsible for data processing (such as sensor data parsing), and cores 4 and 5 are responsible for communication and service management. The multi-core architecture supports the simultaneous operation of multiple applications, and through the isolation mechanism between cores, it ensures that critical functions (such as autonomous driving control) are not interfered with by non-critical functions (such as entertainment data processing).

[0063] For example, when the vehicle is driving in autonomous driving mode, cores 0-1 continuously and stably output power control commands to maintain a stable vehicle speed, cores 2-3 analyze road condition data from cameras and millimeter-wave radar and generate environmental perception results, and cores 4-5 realize communication between the intelligent driving domain and the cockpit domain through SOA service interfaces (such as synchronizing information about obstacles ahead to the instrument panel display).

[0064] In some embodiments, the storage unit is a database of the domain controller, used to store program code, runtime data, data to be interacted with, etc. Figure 2 As shown, the storage units of a domain controller can include: memory, non-volatile memory, storage management modules, and read / write interfaces. They typically include two types of storage: memory (such as RAM), used for temporary storage of frequently accessed data to improve read speed; and non-volatile memory (such as flash memory and hard disks), used for long-term storage of core programs, configuration parameters, historical data, etc.

[0065] As the complexity of domain controller functions skyrockets, a single core can no longer handle all tasks. A multi-core deployment is typically adopted, with cores 0-5 running different applications (such as real-time control, intelligent driving decision-making, cockpit interaction, and logging). All applications frequently need to read and write data to the storage unit. However, if multiple cores simultaneously read and write the same data block in the storage unit, it can lead to data contention, resulting in security risks such as data tampering and inconsistent read results, severely impacting the stability of the domain controller.

[0066] By configuring a storage management module and read / write interfaces, all cores communicate with the storage management module through a single read / write interface. The storage management module uniformly receives and schedules access requests from all cores. It first verifies the validity of the request and data access permissions, then determines whether there are multi-core concurrent access conflicts based on the data address. If a conflict exists, a CmpAndSwap atomic operation is immediately triggered, locking the target data block through an uninterrupted "compare-swap" process, ensuring that only one core can perform read / write operations at a time, thus avoiding data contention. If there is no conflict, the read / write interface is directly scheduled to complete the data transmission.

[0067] In some embodiments, the Service-Oriented Architecture (SOA) service interface is the communication interface of the domain controller. The SOA service interface can encapsulate the functions of the domain controller into standardized services (such as "power status query service" and "cabin ambient lighting control service"), and realize interaction with other domain controllers, the vehicle central computing platform or vehicle terminals through a unified communication protocol (such as SOME / IP, DDS).

[0068] For example, the first domain controller encapsulates a "Traffic Warning Service": the service name is "TrafficWarningService", the request parameters include "warning type (congestion / obstacle / speed limit)", "distance (meters)" and "priority (high / medium / low)", and the communication protocol adopts SOME / IP (vehicle SOA communication protocol).

[0069] The second domain controller encapsulates a "Multimedia Interaction Service": the service name is "MultimediaInteractionService", which supports receiving commands such as "text prompts", "voice broadcasts", and "icon displays", and the response parameter is "execution result (success / failure)".

[0070] After parsing the sensor data, the Neural Processing Unit (NPU) of the first domain controller identifies congestion ahead. The general computing core determines that a cockpit alert needs to be triggered and calls the request interface of the "Traffic Warning Service". In accordance with the SOA protocol, the first domain controller packages the request data into a standardized format (including service ID, method ID, parameters: warning type = congestion, distance = 500, priority = medium) and sends it to the cockpit domain controller via the vehicle Ethernet.

[0071] After receiving the request, the second domain controller parses the service ID and parameters, confirms that it is a call to the "Traffic Warning Service," and then triggers the "Multimedia Interaction Service." Based on the parameters, it executes the following actions: the instrument panel displays the text icon "Traffic congestion ahead 500 meters, slow down recommended," the vehicle's voice system provides a synchronized prompt, and the navigation route is adjusted (if navigation is enabled) to avoid congested areas.

[0072] In some embodiments, a first domain controller and a second domain controller are configured; the first domain controller is configured to, in response to receiving a first data write request sent by a configuration module, store the data to be stored carried in the first data write request based on the data storage method provided in the following embodiments; the first domain controller is further configured to send a second data write request to the second domain controller, the second data write request being used to request the second domain controller to store the data to be stored; the second domain controller is configured to, in response to receiving the second data write request, store the data to be stored carried in the second data write request based on the data storage method provided in the following embodiments.

[0073] It should be understood that the first domain controller is the data storage provider, and the second domain controller is the data backup provider. When the first domain controller receives the first data write request sent by the configuration module and writes the data to be stored, it means that the stored data of the first domain controller has changed. This requires data synchronization to avoid inconsistencies between the data of the two domain controllers, which could lead to data deviations during subsequent reading, retrieval, or fault recovery (such as backup data lagging behind the latest data and being unable to be accurately replaced).

[0074] As one possible implementation, the configuration module (such as the vehicle's central configuration unit) generates a first data write request, which carries the data to be stored (such as updated autonomous driving calibration parameters) and sends it to the first domain controller (such as the intelligent driving domain controller). After receiving the request, the first domain controller stores the data to be stored in its own storage unit according to the data storage method described below (slicing → generating additional information → combining slices → matching write strategy), thus completing local storage.

[0075] Cross-domain backup request: After the first domain controller completes local storage, it generates a second data write request (the request carries the same data to be stored) and sends it to the second domain controller (such as the vehicle domain controller or a dedicated backup domain controller).

[0076] Backup storage: After receiving the second data write request, the second domain controller also uses the same data storage method to store the data to be stored in its own storage unit, thus completing the cross-domain backup.

[0077] Therefore, by having the first domain controller proactively initiate a synchronization request to the second domain controller after completing data storage, and by having both domain controllers use a unified data storage method to perform storage, it can be ensured that the data stored in the two domain controllers always remains completely consistent, achieving redundant backup of critical data and avoiding the risk of data loss due to single controller failure.

[0078] In some embodiments, the first domain controller is further configured to send a data acquisition request to the second domain controller to acquire second stored data corresponding to the first stored data; the first stored data is stored data in the first domain controller, and the second stored data is stored data in the second domain controller; to perform a consistency check on the first stored data and the second stored data to obtain a check result; and to send a second data write request to the second domain controller if the check result indicates that the first stored data and the second stored data are inconsistent.

[0079] It is understandable that during the actual data storage process, the data between the first domain controller and the second domain controller may become out of sync due to reasons such as the loss of the second data write request sent by the first domain controller (e.g., communication link interruption), slice corruption during the storage process of the second domain controller, or cross-domain synchronization delay.

[0080] As one possible implementation, the first domain controller sends a data acquisition request to the second domain controller at a preset period (e.g., 1 minute) or a preset trigger condition (e.g., after the first stored data is updated). The data acquisition request carries a target data identifier that needs to be verified (e.g., calibration data related to autonomous driving functions). After receiving the data acquisition request, the second domain controller determines the second stored data corresponding to the target data identifier based on the target data identifier. By comparing all data, it is determined whether the content and format of the first and second stored data are the same. If they are different, the first domain controller generates a second data write request (carrying complete consistent data or only carrying a difference slice) based on its local first stored data and sends it to the second domain controller. After receiving it, the second domain controller overwrites the corresponding second stored data according to the storage method provided in the following embodiment, thereby achieving data synchronization.

[0081] For example, the first domain controller (Intelligent Driving Domain) locally stores the V3 version Intelligent Driving calibration parameters and has already sent a synchronization request to the second domain controller (Vehicle Domain). A preset period has elapsed (e.g., 1 minute), and the first domain controller sends a request to the second domain controller to retrieve the Intelligent Driving calibration parameters. The second domain controller returns the stored parameters. The first domain controller calculates the hash values ​​of both and finds that the hash values ​​of the parameters in the second domain controller do not match (the second domain controller stores the V2 version Intelligent Driving calibration parameters). The first domain controller then resends a second data write request carrying the V3 version parameters. The second domain controller overwrites the stored V3 version parameters, and the data between the two domain controllers is restored to consistency.

[0082] Therefore, by having the first domain controller proactively initiate data comparisons and update data when inconsistencies arise, inconsistencies in the stored data between the two domain controllers can be detected in real time (such as synchronization omissions or content deviations caused by storage anomalies). By resending write requests, the stored data of the two domain controllers can be synchronized, ensuring that the backup data of the second domain controller is always consistent with the baseline data of the first domain controller.

[0083] In other embodiments, the vehicle's intelligent control module can simultaneously acquire first stored data from the first domain controller and second stored data from the second domain controller. Before calculating the control algorithm based on the first and second stored data, the intelligent control module compares the first and second stored data. If they match, the algorithm is calculated directly using either the first or second stored data. If they do not match, the write times in the additional information of the first and second stored data are compared, and the algorithm is calculated based on the data with the later write time, and data synchronization is performed. For example, if the write time of the second stored data is later than that of the first stored data, the control algorithm is calculated based on the second stored data, and the second domain controller sends an input write request to the first domain controller to update the first stored data with the second stored data.

[0084] For example, the vehicle intelligent control module (such as the autonomous driving central decision-making module) needs to perform acceleration strategy algorithm calculation based on the torque limit parameters of the power system: the intelligent control module simultaneously obtains the first stored data (torque limit value 150 Nm, write time 10:05:03) from the first domain controller (power domain controller) and the second stored data (torque limit value 180 Nm, write time 10:05:08) from the second domain controller (body domain controller).

[0085] Before the algorithm calculation, the intelligent control module compared the two sets of data and found that the values ​​were inconsistent. It then extracted the write time from the additional information of both sets. Because the write time of the second stored data (10:05:08) was later than that of the first stored data (10:05:03), the second stored data was determined to be the newer version. The acceleration strategy algorithm was then executed based on 180 Newton-meters as the baseline. Simultaneously, data synchronization was triggered: the second domain controller sent a data write request to the first domain controller, carrying the 180 Newton-meter torque limit parameter and corresponding additional information. Upon receiving the request, the first domain controller updated its local stored data, ultimately restoring consistency between the two domains.

[0086] In some embodiments, the first stored data and the second stored data are vehicle configuration information, which is used to define the vehicle's control functions. Before sending the second data write request to the second domain controller, the first domain controller is further configured to: determine target data in the first stored data and the target vehicle control function corresponding to the target data; wherein the target data is used to instruct the first domain controller to modify the data in response to the first data write request; determine the target service identifier corresponding to the target vehicle control function based on the target vehicle control function and the mapping relationship between vehicle functions and services; wherein one target service identifier corresponds to one vehicle control function; and generate data to be stored based on the target data and the target service identifier.

[0087] The second domain controller is configured to determine the target storage data slice corresponding to the data to be stored based on the target service identifier and the mapping relationship between the service identifier and the data location; and to update the target storage data slice based on the data to be stored.

[0088] As one possible implementation, after receiving the update request from the configuration module, the first domain controller first updates the first stored data locally. Then, it locates the updated target data from the updated first stored data and identifies the target vehicle control function corresponding to that value. It queries a preset mapping table of vehicle functions and services to obtain the corresponding target service identifier. The target data and the target service identifier are combined to form the data to be stored, which serves as the core content of the second data write request.

[0089] After receiving the second data write request, the second domain controller queries the preset mapping table between service identifiers and data locations, locates the target storage data slice that needs to be updated, writes the target data from the data to be stored into the located target storage data slice (overwriting the original value), and updates the additional information of the slice at the same time.

[0090] For example, the torque limit value changes from the original threshold of 150 Nm to a new threshold of 180 Nm. The first domain controller (such as the powertrain domain controller) first determines the target data as 180 Nm from the first stored data in its local storage, and the target vehicle control function corresponding to this value is vehicle acceleration / deceleration control (this function constrains the motor output through the torque limit value, directly affecting the vehicle's acceleration capability). Next, based on the preset mapping relationship between vehicle functions and services, it queries the target service identifier Service_Powertrain_AccDec_003 corresponding to the vehicle acceleration / deceleration control function. The first domain controller combines the target data 180 Nm with the target service identifier Service_Powertrain_AccDec_003 to generate data to be stored (formatted as Service_Powertrain_AccDec_003:180 Nm), and sends a second data write request to the second domain controller (such as the chassis domain controller).

[0091] After receiving the request, the second domain controller queries the mapping table between service identifiers and data locations based on the target service identifier Service_Powertrain_AccDec_003, locating the target storage data slice corresponding to this identifier as power parameter slice 5 (storage address 0x000C5000). Finally, it updates the original 150 Nm in power parameter slice 5 with 180 Nm from the data to be stored, and synchronously updates the write time and other information in the slice's additional information, completing the dual-domain data synchronization.

[0092] The following example, using the lighting function configuration word 0XFFFF (assuming this configuration word contains multiple sub-functions: byte 0 controls the number of one-key turn signals, byte 1 controls the daytime running light switch, byte 2 controls the charging and discharging lighting effects, etc.), illustrates the difference between SOA and existing technologies:

[0093] In related technologies, various functions are not service-oriented. Modifying configuration information is typically achieved through Unified Diagnostic Services (UDS). The UDS protocol relies on Data Identifiers (DIDs) to modify configuration information. If a configuration is not defined as a DID (e.g., a temporarily added sub-function), it cannot be modified through UDS. Furthermore, when modifying a DID, UDS can only rewrite all bytes of the entire configuration word at once (for example, to modify the daytime running light switch in byte 1, the entire 0xFFFF must be read first, byte 1 modified, and then all bytes written back). This operation is not only cumbersome but also prone to accidental modification of other bytes (such as byte 0 and byte 2).

[0094] This application abstracts each sub-configuration into an independent service through service-oriented architecture. The daytime running light function switch (byte1) is abstracted into a separate service (e.g., service ID Light_DaytimeSwitch), and other sub-functions (such as byte0 and byte2) also correspond to a service. Each service is deployed independently in a domain controller, focusing on managing its corresponding sub-configuration.

[0095] Any other controller (such as the body domain controller or cockpit domain controller) that needs to modify the daytime running light switch does not need to concern itself with the structure of the underlying configuration word 0xFFFF. It only needs to deploy the calling interface of the Light_DaytimeSwitch service and directly send a modification request (e.g., to turn on the daytime running lights). Upon receiving the request, the service's server (the domain controller responsible for storing the configuration) identifies the daytime running light switch via the service ID, directly locates byte 1 of the configuration word 0xFFFF, modifies only the value of that byte (e.g., from 0 to 1), and then writes it to non-volatile memory. The entire process does not require reading other bytes and does not affect the original configuration of bytes 0 and byte 2.

[0096] It should be understood that by using the service-oriented design of SOA, the scalability limitations of UDS are solved (no need to predefine DID, support for temporary addition of functions), the tediousness and risk of misoperation of full rewriting are avoided, and the configuration and interaction of cross-domain controllers are made simpler (the caller does not need to know the underlying data structure).

[0097] Therefore, after the first domain controller updates the first storage data locally, it can extract the difference data and generate synchronized content by associating service identifiers. This ensures that the data to be synchronized is the latest and accurate partial update (rather than the full data), thus achieving precise cross-domain data synchronization.

[0098] The second domain controller can quickly locate the target slice and perform partial updates based on the service identifier, skipping the full data scan and rewrite, thus completing data synchronization with minimal operations, significantly improving update efficiency and reducing the erase and write wear of storage units.

[0099] In some embodiments, such as Figure 3 As shown, this application provides a data storage method that can be applied to any domain controller in the aforementioned data storage system, comprising the following steps:

[0100] S301. In response to receiving a data write request, the data to be stored carried in the data write request is split into multiple storage data slices.

[0101] The data to be stored can include core vehicle operating data, environmental perception data, user interaction data, fault diagnosis data, and configuration parameter data. For example, core operating data includes real-time control data such as powertrain output torque, remaining battery charge (State of Charge, SOC), vehicle speed, engine speed, and braking pressure; environmental perception data includes road images captured by cameras, obstacle point cloud data from LiDAR / millimeter-wave radar, high-precision map positioning information, and traffic light status data; user interaction data includes cabin air conditioning temperature settings, seat adjustment parameters, navigation destination information, multimedia playback records, and voice command logs; fault diagnosis data includes sensor anomaly alarm information, electronic component fault codes, data transmission error records, and core operating overload logs; and configuration parameter data includes autonomous driving function calibration thresholds, power mode parameters (economy / sport mode settings), safety protection strategy parameters, and SOA service interface configuration information.

[0102] As one possible implementation, a data write request can be initiated by any core of the domain controller (such as core 0-core 5) or the application running on it. The request carries key information such as the type identifier, priority level, and storage period of the data to be stored.

[0103] As another possible implementation, splitting refers to breaking down the original data to be stored into multiple independent, parallel-processable data units according to preset rules. There are various splitting methods. For example, the data to be stored can be split into a preset fixed number of bytes (such as 256KB or 1MB), with the last slice retained to its actual length if it is smaller than the fixed size. Splitting can also be based on field boundaries or data types in the data to be stored. For example, vehicle configuration parameters (power parameters, cabin parameters) can be split into power parameter slices and cabin parameter slices. Splitting can also be based on data real-time and security requirements. For example, the data to be stored can be split into slices with high and low real-time requirements, or into slices requiring encryption and those not requiring encryption. These are just a few examples.

[0104] It should be understood that by splitting the data to be stored into multiple slices, the storage pressure can be distributed, avoiding storage blockage or excessive write / erase of storage units caused by writing a single large data block.

[0105] S302. For each storage data slice, determine the additional information corresponding to each storage data slice.

[0106] The additional information includes at least one of the following: the write time of the storage data slice, the function call address that initiated the data write request, the start position of the write of the storage data slice, and the write length of the storage data slice.

[0107] In some embodiments, the write time is used to trace the data generation order (e.g., in intelligent driving scenarios, timestamps can be used to match the temporal relationship of data from different sensors). The function call address represents the memory address of the application function that initiated the write request, used to locate the data source (e.g., when investigating abnormal data, the address can be used to trace back to the specific application or core where the abnormality occurred). The write start position represents the target address of the stored data slice in the storage unit (e.g., the physical sector location of non-volatile memory (NVM)). The write length represents the number of bytes of the stored data slice, used to verify data integrity (preventing truncation or tampering during storage).

[0108] It should be understood that by assigning identity and attributes to each stored data slice through additional information, the location, source, and status of data storage can be quickly located by filtering the additional information when data anomalies occur. In addition to processing information such as write time mentioned above, additional information may also include data verification codes, etc., which will not be listed here.

[0109] As one possible implementation, the generation context information (such as write time and function call address) and storage configuration information (such as write start position and length) of the storage data slice are obtained. The obtained multi-dimensional information is then combined according to a preset format to obtain the additional information corresponding to the storage data slice. For example, the preset format is "write time (4 bytes) + function call address (4 bytes) + start position (1 byte) + length (1 byte)".

[0110] For example, a 256KB storage data slice has 10 bytes of additional information, including: (write time 4 bytes + call address 4 bytes + start position 1 byte + length 1 byte).

[0111] S303. Combine each storage data slice and the additional information corresponding to each storage data slice to obtain multiple combined data slices.

[0112] One possible implementation is to package each stored data slice and its corresponding supplementary information according to a preset format to form a combined data slice. The preset format can be a structure that adds a tail of supplementary information to the data slice body (the supplementary information is directly appended to the data slice as a fixed-length tail), or it can be a separate structure with an independent storage area added to the index table, with the supplementary information centrally stored in the index table. It should be noted that there are other preset formats as well, which will not be elaborated upon here.

[0113] For example, such as Figure 4As shown, a combined data slice includes: a storage data slice and additional information, with the additional information at the end of the data. A 256KB storage data slice has the following combined slice: 10 bytes of additional information (4 bytes for write time + 4 bytes for call address + 1 byte for start position + 1 byte for length) + 256KB of storage data slice.

[0114] It should be understood that by generating combined data slices, the storage of data slices is ensured to be bound to additional information, avoiding separation during storage or transmission (for example, when reading, additional information can be directly parsed from the combined slice without additional querying), thus improving the convenience of data management.

[0115] S304. Write multiple combined data slices into the storage unit of the domain controller.

[0116] As one possible implementation, a target write strategy for multiple combined data slices is determined based on the importance of the data to be stored and / or the data write request frequency of the functional module that generates the data to be stored. If the target write strategy is a synchronous write strategy, the multiple combined data slices are written to the storage unit in response to a data write request. Alternatively, if the target write strategy is a timed write strategy, all combined data in memory within a preset time interval is written to the non-volatile memory of the domain controller at preset time intervals. The storage unit includes: memory and non-volatile memory. Alternatively, if the target write strategy is a power-down write strategy, the multiple combined data slices are temporarily stored in memory, and the combined data is written to the non-volatile memory of the domain controller in response to a power-down command.

[0117] It's understandable that non-volatile memory has a limited erase / write lifespan. Therefore, the frequency of data writes needs to be controlled. For important data with low write frequency, we use an immediate write approach. This means that when an application calls the write interface of the storage module, the data is immediately written to the Data Flash (DFLASH), ensuring no data loss even when power is off (synchronous write strategy). Because the write frequency is low, the impact on the DFLASH lifespan is minimal. For important data with frequent writes, an internal timed update can be set. When the timer expires, any changes to the data are immediately written to the DFLASH. When an application calls the write interface of the storage module, the data is temporarily stored in Random Access Memory (RAM) (timed write strategy), thus reducing the number of DFLASH writes. For data of low importance, a power-off storage approach is used. During power-on operation, write calls to the write interface are initially stored in RAM. When the domain controller powers down and prepares for hibernation, the data is written to the DFLASH in batches (power-off write strategy), further reducing the number of DFLASH writes.

[0118] It should be understood that by dynamically matching differentiated writing strategies based on data importance and writing frequency, important data that is written frequently is cached or optimized for batch writing, while low-importance data is delayed until power-off for centralized processing. This ensures that data is recorded and also balances the number of DFLASH erase / write cycles to extend its lifespan.

[0119] Therefore, this data storage method, by dividing the data to be stored into multiple storage data slices and attaching additional information such as write time, function call address, write start position, and length, can accurately locate the data source and storage location during data verification, anomaly tracing, or fault diagnosis, facilitating rapid anomaly detection. Furthermore, dividing the data to be stored into multiple combined data slices allows for independent processing of each slice during data storage, improving both the quality and efficiency of data storage, thus comprehensively enhancing the reliability and efficiency of data storage.

[0120] In some embodiments, when the length of the data to be stored is relatively large, writing it directly as a single large block of data will lead to low storage efficiency (long write time per operation) and high bandwidth consumption (affecting the writing of other data), especially when this type of data is written frequently, it will also exacerbate the wear and tear on storage units. Therefore, when the length of the data to be stored is large, it can be divided into multiple slices according to rules to achieve parallel processing and resource balancing. For example... Figure 5 As shown, the above method splits the data to be stored into multiple storage data slices, including:

[0121] S501. Determine a first preset length threshold based on the data write request frequency of the function type to which the data to be stored belongs.

[0122] Among them, the first preset length threshold is negatively correlated with the data write request frequency.

[0123] It should be understood that the data write frequencies for different functional types of vehicles vary greatly: For high-frequency data writes (such as real-time sensor data multiple times per second), excessively large slices will increase the time required for a single write, slowing down multi-core parallel efficiency, and frequent writes of large slices will exacerbate DFLASH erase / write wear; for low-frequency data writes (such as user configuration updates several times a day), excessively small slices will generate a large amount of fragmentation, increasing storage management complexity. Therefore, a criterion for determining whether to split data (a first preset length threshold) needs to be dynamically set based on the write frequency. By setting a first preset length threshold, efficiency issues caused by excessively large slices for high-frequency data can be avoided, while simultaneously preventing additional burden on the domain controller caused by excessive splitting of low-frequency data.

[0124] As one possible implementation, the average write frequency of different functional data types is statistically analyzed by the historical operation records of the domain controller. Then, a mapping table between the data write request frequency and the first preset length threshold is set in combination with the storage unit performance (such as the maximum single write efficiency of DFLASH). When a data write request is received, the above mapping table is queried to obtain the first preset length threshold.

[0125] S502. If the length of the data to be stored is greater than the first preset length threshold, the data to be stored is split into multiple storage data slices.

[0126] It should be understood that when the data length is relatively large, if it is not split, the data can only be written serially, which results in a slow data writing speed. If the large data writing process is interrupted, the entire data may be corrupted and cannot be recovered, which seriously affects the efficiency and quality of data storage.

[0127] As one possible implementation, the data to be stored is divided according to a second preset length threshold to obtain multiple storage data slices; the second preset length threshold is equal to the first preset length threshold minus the preset length corresponding to the additional information.

[0128] For example, the method for splitting the data to be stored can be as shown in Table 1.

[0129] Table 1

[0130]

[0131] For a piece of data that requires 4476 bytes of storage space, the first preset length threshold is 1034, the preset length is 10, and the second preset length threshold is 1024. The data to be stored is split into 5 storage data slices, block1-block5, with each data block being 1024 bytes.

[0132] Understandably, in the storage design of a domain controller, the preset length of the additional information is fixed. The size of the combined slice is precisely controlled by the second threshold to ensure that the split data units can be processed efficiently without exceeding the preset storage performance boundaries.

[0133] Therefore, the size of the first preset length threshold is determined according to the data write request frequency. When the data write request frequency is relatively high (high-frequency data), a small threshold is used to force the data to be split into small slices, which can make the amount of data written in a single transaction smaller and the processing time shorter. This avoids serial blocking caused by a single large slice occupying core resources, thereby ensuring the lifespan of DFLASH.

[0134] In some embodiments, to avoid duplicate storage of new data or a chaotic storage structure, it is necessary to first determine whether the storage unit already contains data of the corresponding functional type before deciding whether to execute the splitting process. Therefore, as Figure 6 As shown, the above S301 includes:

[0135] S601. In response to receiving a data write request, determine whether there is data corresponding to the function type in the storage unit based on the function type of the data to be stored carried in the data write request.

[0136] As one possible implementation, the data write request carries a function type identifier (such as motor data, vehicle light data, etc.). After receiving the data write request, the function type index table in the storage unit is queried according to the function type to which the data belongs. By determining whether the function type index table already contains historical data of that type, it is determined whether the data corresponding to the function type exists in the storage unit.

[0137] For example, when the vehicle is started for the first time, the initial calibration parameters (function type: intelligent driving calibration) generated by the autonomous driving domain controller have no historical records in the storage unit and are therefore determined to be non-existent.

[0138] S602. If there is no data corresponding to the function type in the storage unit, split the data to be stored carried in the data write request into multiple storage data slices.

[0139] It should be noted that the process of splitting the data to be stored carried in the data write request into multiple storage data slices can be referred to the description in the above embodiments, and will not be repeated here.

[0140] Therefore, by first determining whether the functional type data exists and then performing standardized splitting on the new data, we can ensure that the data stored for the first time can be accurately and quickly stored in the storage unit of the domain controller, while avoiding resource waste caused by duplicate storage.

[0141] In some embodiments, when data of the corresponding functional type already exists in the storage unit, data modification requests can be handled through partial updates rather than full rewrites to optimize storage efficiency. Therefore, as Figure 7 As shown, the above method also includes:

[0142] S701. If data corresponding to a function type exists in the storage unit, determine the target combined data slice corresponding to the data to be stored from among multiple combined data slices of data corresponding to the function type.

[0143] The target combined data slice represents the slice of stored data that needs to be updated.

[0144] It should be understood that when data corresponding to a specific function type exists within a storage unit, a data write request actually requests an update (partial modification) of existing data. A full split and rewrite would waste the domain controller's computing power and storage bandwidth, and exacerbate DFLASH write / erase losses. Therefore, by identifying the target combined data slice corresponding to the data to be stored, the slice requiring updating can be precisely located, avoiding invalid processing of irrelevant data and improving update efficiency.

[0145] As one possible implementation, the content of the data to be stored (such as the modified torque threshold) is parsed, its logical position in the original functional type data is matched, and the corresponding target combined data slice (such as the slice storing the torque threshold in the power parameters) is located by using the logical position information of the combined data slice corresponding to the original functional type data.

[0146] For example, there are 5 combined data slices corresponding to the original functional type data. The logical position information of the first combined data slice is 127-1023, and the logical position of the data to be stored is 512. Its logical position falls within the range of the first combined data slice. Therefore, the target combined data slice is the first combined data slice.

[0147] S702. Determine the additional information corresponding to the data to be stored.

[0148] The additional information corresponding to the data to be stored includes: the write time of the data to be stored into the target combined data slice, the function call address that initiated the data write request, the starting position of the data to be stored in the target combined data slice, and the write length of the data to be stored.

[0149] For example, if the total length of the target combined data slice is 256 bytes (address range 0x00-0xFF), and the data to be stored needs to be written starting from the 16th byte (0x10) of this slice, then the write start position is 0x10. If the total length of the data to be stored is 4 bytes, then the write length of the data to be stored is 4 bytes.

[0150] It should be noted that the implementation process of S702 can refer to the description of how to determine the additional information of the stored data slice in S302 of the above embodiment, and will not be repeated here.

[0151] S703. Update the target combined data slice based on the data to be stored and the additional information corresponding to the data to be stored.

[0152] As one possible implementation, the original data of the target combined data slice is replaced with new data to be stored (such as modified parameter values); and the original additional information is replaced with newly generated additional information, while keeping the slice storage address unchanged.

[0153] For example, the value of the torque threshold slice in the original data is changed from 150 Nm to 200 Nm in the new data to be stored, while other power parameters in the original data remain unchanged, and the newly generated additional information, such as the write time in the new data to be stored, replaces the write time in the original additional information.

[0154] Therefore, by accurately locating the target slice and performing local updates, the amount of stored data is minimized while ensuring data consistency (only the single slice that has changed is updated, rather than the entire set of data), thus improving the storage efficiency of the domain controller in data iteration scenarios.

[0155] In some embodiments, such as Figure 8 As shown, this application provides another data storage method that can be applied to the first domain controller and the second domain controller in the above-mentioned data storage system, including the following steps:

[0156] S801, the first domain controller, in response to receiving the first data write request sent by the configuration module, stores the data to be stored carried in the first data write request based on the data storage method in the above embodiment.

[0157] S802, the first domain controller sends a second data write request to the second domain controller.

[0158] The second data write request is used to request the second domain controller to store the data to be stored.

[0159] S803. Upon receiving the second data write request, the second domain controller stores the data to be stored carried in the second data write request based on the data storage method in the above embodiments.

[0160] In some embodiments, sending a second data write request to a second domain controller includes: sending a data acquisition request to the second domain controller to acquire second stored data corresponding to the first stored data; the first stored data is stored data in the first domain controller, and the second stored data is stored data in the second domain controller; performing a consistency check on the first stored data and the second stored data to obtain a check result; and sending a second data write request to the second domain controller if the check result indicates that the first stored data and the second stored data are inconsistent.

[0161] In some embodiments, the first stored data and the second stored data are vehicle configuration information, which is used to define the vehicle's control functions. Before the first domain controller sends a second data write request to the second domain controller, the method further includes: determining target data in the first stored data and a target vehicle control function corresponding to the target data; wherein the target data is used to instruct the first domain controller to modify the data in response to the first data write request; determining a target service identifier corresponding to the target vehicle control function based on the target vehicle control function and the mapping relationship between vehicle functions and services; wherein one target service identifier corresponds to one vehicle control function; and generating data to be stored based on the target data and the target service identifier.

[0162] In some embodiments, the second domain controller determines the target storage data slice corresponding to the data to be stored based on the target service identifier and the mapping relationship between the service identifier and the data location; and updates the target storage data slice based on the data to be stored.

[0163] The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the aforementioned functions, the data storage device or electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0164] This application embodiment can, according to the above method, exemplarily divide a data storage device or electronic device into functional modules. For example, the data storage device or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0165] Reference Figure 9 The data storage device 900 provided in this application embodiment is applied to a domain controller and includes: a slicing unit 901, a determination unit 902, and a combination unit 903.

[0166] The slicing unit 901 is used to split the data to be stored carried by the data write request into multiple storage data slices in response to receiving a data write request.

[0167] The determining unit 902 is used to determine additional information corresponding to each storage data slice for each storage data slice; the additional information includes at least one of the following: the write time of the storage data slice, the function call address that initiates the data write request, the write start position of the storage data slice, and the write length of the storage data slice;

[0168] Combination unit 903 is used to combine each storage data slice and the additional information corresponding to each storage data slice to obtain multiple combined data slices; and write the multiple combined data slices into the storage unit of the domain controller.

[0169] Furthermore, the aforementioned slicing unit 901 is specifically used to determine a first preset length threshold based on the data write request frequency of the functional type to which the data to be stored belongs; the first preset length threshold is negatively correlated with the data write request frequency; when the length of the data to be stored is greater than the first preset length threshold, the data to be stored is split into multiple storage data slices.

[0170] Furthermore, the aforementioned slicing unit 901 is specifically used to divide the data to be stored according to a second preset length threshold to obtain multiple storage data slices; the second preset length threshold is equal to the first preset length threshold minus the preset length corresponding to the additional information.

[0171] Furthermore, the aforementioned slicing unit 901 is specifically used to respond to a received data write request, determine whether there is data corresponding to the function type in the storage unit based on the function type of the data to be stored carried in the data write request; if there is no data corresponding to the function type in the storage unit, split the data to be stored carried in the data write request into multiple storage data slices.

[0172] Furthermore, the above-mentioned device also includes: an updating unit; the updating unit is configured to, when data corresponding to a function type exists in the storage unit, determine the target combined data slice corresponding to the data to be stored from multiple combined data slices of data corresponding to the function type; determine the additional information corresponding to the data to be stored; and update the target combined data slice based on the data to be stored and the additional information corresponding to the data to be stored.

[0173] Furthermore, the aforementioned combination unit 903 is specifically used to determine a target write strategy for multiple combined data slices based on the importance of the data to be stored and / or the data write request frequency of the functional module that generates the data to be stored; when the target write strategy is a synchronous write strategy, in response to a data write request, the multiple combined data slices are written to the storage unit; or, when the target write strategy is a timed write strategy, all the combined data in memory within a preset time interval are written to the non-volatile memory of the domain controller at preset time intervals; the storage unit includes: memory and non-volatile memory; or, when the target write strategy is a power-down write strategy, the multiple combined data slices are temporarily stored in memory, and in response to receiving a power-down command, the combined data is written to the non-volatile memory of the domain controller.

[0174] Reference Figure 10 The data storage device 1000 provided in this application embodiment is applied to a first domain controller and a second domain controller, and includes: a first storage unit 1001, a sending unit 1002, and a second storage unit 1003.

[0175] The first storage unit 1001 is used by the first domain controller to store the data to be stored carried in the first data write request in response to receiving a first data write request sent by the configuration module, based on any of the optional data storage methods in the first aspect.

[0176] The sending unit 1002 is used to send a second data write request from the first domain controller to the second domain controller. The second data write request is used to request the second domain controller to store the data to be stored.

[0177] The second storage unit 1003 is used by the second domain controller to store the data to be stored carried in the second data write request in response to receiving the second data write request, based on any of the optional data storage methods in the first aspect.

[0178] Furthermore, the sending unit 1002 is also used to send a data acquisition request from the first domain controller to the second domain controller to acquire second stored data corresponding to the first stored data; the first stored data is the data already stored in the first domain controller, and the second stored data is the data already stored in the second domain controller; to perform a consistency check on the first stored data and the second stored data to obtain a check result; and to send a second data write request to the second domain controller if the check result indicates that the first stored data and the second stored data are inconsistent.

[0179] Furthermore, the first stored data and the second stored data are vehicle configuration information, which is used to define the vehicle's control functions. The device further includes a processing unit. The processing unit is used for the first domain controller to determine the target data in the first stored data and the target vehicle control function corresponding to the target data. The target data is used to instruct the first domain controller to modify the data in response to the first data write request. Based on the target vehicle control function and the mapping relationship between vehicle functions and services, the processing unit determines the target service identifier corresponding to the target vehicle control function. One target service identifier corresponds to one vehicle control function. Based on the target data and the target service identifier, the processing unit generates data to be stored.

[0180] Furthermore, the processing unit is used by the second domain controller to determine the target storage data slice corresponding to the data to be stored based on the target service identifier and the mapping relationship between the service identifier and the data location; and to update the target storage data slice based on the data to be stored.

[0181] like Figure 11 As shown, the electronic device 1100 provided in this application embodiment includes, but is not limited to, a processor 1101 and a memory 1102.

[0182] The aforementioned memory 1102 is used to store the executable instructions of the processor 1101. It is understood that the processor 1101 is configured to execute instructions to implement the data storage method described in the above embodiments.

[0183] It should be noted that those skilled in the art will understand that Figure 11 The electronic device structure shown does not constitute a limitation on electronic device 1100; electronic devices may include, but are not limited to, other electronic devices. Figure 11 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0184] Processor 1101 is the control center of electronic device 1100. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 1102, and by calling data stored in memory 1102, it performs various functions and processes data of electronic device 1100, thereby providing overall monitoring of electronic device 1100. Processor 1101 may include one or more processing units. Optionally, processor 1101 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 1101.

[0185] The memory 1102 can be used to store software programs and various data. The memory 1102 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 1102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0186] In an exemplary embodiment, a vehicle is also provided, including the electronic equipment described above.

[0187] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1102 including instructions, which can be executed by a processor 1101 of an electronic device 1100 to implement the methods in the above embodiments.

[0188] In actual implementation, Figure 9 and Figure 10 The functions of each module can be provided by Figure 11 The processor 1101 calls the computer program stored in the memory 1102 to implement the process. The specific execution process can be found in the method section of the previous embodiment, and will not be repeated here.

[0189] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), a random access memory (RAM), a compact disc (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0190] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1101 of the electronic device 1100 to perform the methods described above.

[0191] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0192] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0193] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0194] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0195] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0196] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0197] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A data storage method, characterized by, The method applied to a domain controller comprises: In response to receiving a data write request, determining whether data corresponding to a function type exists in a storage unit based on the function type to which data carried by the data write request belongs; In the case where the data corresponding to the function type does not exist in the storage unit, splitting the data to be stored carried by the data write request into a plurality of storage data slices; For each storage data slice, determining additional information corresponding to the storage data slice; the additional information at least comprises at least one of the following: a write time of the storage data slice, a function call address of initiating the data write request, a write start position of the storage data slice, and a write length of the storage data slice; Combining each storage data slice and the additional information corresponding to each storage data slice to obtain a plurality of combined data slices; Writing the plurality of combined data slices into a storage unit of the domain controller; In the case where the data corresponding to the function type exists in the storage unit, determining a target combined data slice corresponding to the data to be stored among a plurality of combined data slices of the data corresponding to the function type; Determining additional information corresponding to the data to be stored; Updating the target combined data slice based on the data to be stored and the additional information corresponding to the data to be stored.

2. The method of claim 1, wherein, The splitting of the data to be stored carried by the data write request into a plurality of storage data slices comprises: Determining a first preset length threshold based on a data write request frequency of the function type to which the data to be stored belongs; the first preset length threshold is negatively correlated with the data write request frequency; In the case where the length of the data to be stored is greater than the first preset length threshold, splitting the data to be stored into a plurality of storage data slices.

3. The method of claim 2, wherein, The splitting of the data to be stored into a plurality of storage data slices comprises: Dividing the data to be stored according to a second preset length threshold to obtain the plurality of storage data slices; the second preset length threshold is equal to the first preset length threshold minus a preset length corresponding to the additional information.

4. The method of claim 1, wherein, The writing of the plurality of combined data slices into the storage unit of the domain controller comprises: Determining a target write strategy of the plurality of combined data slices according to an importance of the data to be stored and / or a data write request frequency of a function module generating the data to be stored; In the case where the target write strategy is a synchronous write strategy, writing the plurality of combined data slices into the storage unit in response to the data write request; or, In the case where the target write strategy is a timing write strategy, writing all combined data in the memory within a preset time interval into a non-volatile memory of the domain controller according to a preset time interval; the storage unit comprises the memory and the non-volatile memory; or, In a case where the target write strategy is a power-off write strategy, the multiple combined data slices are temporarily stored in the memory, and in a case where a power-off instruction is received, the combined data is written to the non-volatile memory of the domain controller.

5. A data storage system, characterized by Comprising: a first domain controller and a second domain controller; the first domain controller is configured to, in response to receiving a first data write request sent by a configuration module, store data to be stored carried in the first data write request based on the data storage method of any one of claims 1-4; the first domain controller is further configured to send a second data write request to the second domain controller, the second data write request being used to request the second domain controller to store the data to be stored; the second domain controller is configured to, in response to receiving the second data write request, store the data to be stored carried in the second data write request based on the data storage method of any one of claims 1-4.

6. The system of claim 5, wherein, the first domain controller is further configured to send a second data write request to the second domain controller, comprising: sending a data acquisition request to the second domain controller to acquire second stored data corresponding to first stored data; the first stored data is stored data in the first domain controller, and the second stored data is stored data in the second domain controller; performing consistency verification on the first stored data and the second stored data to obtain a verification result; in a case where the verification result indicates that the first stored data and the second stored data are inconsistent, sending a second data write request to the second domain controller.

7. The system of claim 6, wherein, the first stored data and the second stored data are configuration information of a vehicle, and the configuration information is used to define a control function of the vehicle; before sending the second data write request to the second domain controller, the first domain controller is further configured to: determine target data in the first stored data and a target vehicle control function corresponding to the target data; wherein the target data is used to indicate that the first domain controller changes data of a change part in response to the first data write request; based on the target vehicle control function and a mapping relationship between vehicle functions and services, determine a target service identifier corresponding to the target vehicle control function; wherein one target service identifier corresponds to one vehicle control function; based on the target data and the target service identifier, generate data to be stored.

8. The system of claim 7, wherein, the second domain controller is configured to: based on the target service identifier and a mapping relationship between service identifiers and data positions, determine target stored data slices corresponding to the data to be stored; update the target stored data slices based on the data to be stored.

9. An electronic device, comprising: Comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method of any one of claims 1-4.

10. A vehicle characterized by comprising: Comprising: the system of any one of claims 5-8, and / or the electronic device of claim 9.

Images