Data persistent storage method, device and storage medium for vehicle-mounted system

Abstract

The present application provides a data persistence storage method, device and storage medium for an in-vehicle system. The method includes: writing vehicle configuration information in the form of key-value pairs into a persistent storage area; determining a target storage area based on the received key-value pair information; writing or updating vehicle configuration information in the target storage area, and storing the vehicle configuration information in a preset format, wherein data in different partitions are isolated and managed according to the identity or authority of the caller; when reading the vehicle configuration information, using the upper-layer application to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines the corresponding storage area based on the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area. The present application can ensure data consistency, simplify data management, and can efficiently integrate solutions under different system environments.

Description

Technical Field

[0001] The present application relates to the field of new energy vehicle technology, and in particular to a method, device, and storage medium for persistent data storage in an on-board system. Background Art

[0002] With the widespread adoption of intelligent and networked in-vehicle systems, vehicles are integrating complex applications such as infotainment, navigation, and driver assistance systems. These systems need to process and store large amounts of vehicle configuration information and operational data. To ensure continuous and efficient system operation, in-vehicle systems are increasingly demanding persistent data storage.

[0003] Traditional in-vehicle data storage solutions have several shortcomings, especially when it comes to addressing the complex demands of today's in-vehicle systems. These shortcomings include:

[0004] During vehicle operation, unexpected events such as power outages or system crashes can interrupt data writing, leading to data inconsistency. Existing in-vehicle systems typically lack built-in persistent storage support, forcing manufacturers to develop customized persistent storage capabilities, increasing development complexity and costs.

[0005] In-vehicle systems typically need to process massive amounts of data, including vehicle configuration, user preferences, and driving information. Traditional storage solutions often struggle to efficiently manage and quickly access large amounts of data, leading to system performance bottlenecks.

[0006] Some in-vehicle systems rely on third-party storage solutions, which are often expensive, complex to integrate, and costly to maintain. This dependency not only complicates system development but also makes subsequent system upgrades and maintenance difficult. Summary of the Invention

[0007] In view of this, the embodiments of the present application provide a data persistent storage method, device and storage medium for an in-vehicle system to solve the problems of poor data consistency, difficult data management, and complex system integration and maintenance in the prior art.

[0008] In a first aspect of an embodiment of the present application, a data persistence storage method for an in-vehicle system is provided, comprising: utilizing an upper-layer application in the in-vehicle system to call a persistence service interface, and writing vehicle configuration information in the form of key-value pairs into a persistent storage area, wherein the persistence service interface communicates with a persistence service module through an abstract interface definition language; utilizing the persistence service module to determine a target storage area based on the received key-value pair information, wherein the target storage area includes multiple partitions corresponding to storing vehicle configuration information of different levels; writing or updating the vehicle configuration information in the target storage area, and storing the vehicle configuration information in a preset format, wherein data in different partitions is isolated and managed according to the identity or authority of the caller; when reading the vehicle configuration information, utilizing the upper-layer application to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines the corresponding storage area based on the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area.

[0009] According to a second aspect of an embodiment of the present application, a data persistence storage device for an in-vehicle system is provided, comprising: a calling module configured to call a persistence service interface using an upper-layer application in the in-vehicle system, and write vehicle configuration information in the form of key-value pairs into a persistent storage area, wherein the persistence service interface communicates with the persistence service module through an abstract interface definition language; a determining module configured to use the persistence service module to determine a target storage area based on the received key-value pair information, wherein the target storage area includes multiple partitions corresponding to vehicle configuration information of different levels; a storage module configured to write or update vehicle configuration information in the target storage area, and store the vehicle configuration information in a preset format, wherein data in different partitions is isolated and managed according to the identity or authority of the caller; a reading module configured to send a read request to the persistence service module through the persistence service interface using an upper-layer application when reading the vehicle configuration information, so that the persistence service module determines the corresponding storage area based on the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area.

[0010] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0011] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above method are implemented.

[0012] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0013] By utilizing the upper-layer application in the vehicle system to call the persistence service interface, the vehicle configuration information is written into the persistent storage area in the form of key-value pairs, wherein the persistence service interface communicates with the persistence service module through an abstract interface definition language; utilizing the persistence service module, the target storage area is determined according to the received key-value pair information, wherein the target storage area includes multiple partitions corresponding to the vehicle configuration information of different levels; the vehicle configuration information is written or updated in the target storage area, and the vehicle configuration information is stored in a preset format, wherein the data of different partitions is isolated and managed according to the identity or authority of the caller; when reading the vehicle configuration information, the upper-layer application is utilized to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines the corresponding storage area according to the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area. This application can ensure data consistency, simplify data management, and can efficiently integrate solutions under different system environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0015] Figure 1 This is a schematic diagram of the framework of the persistent storage technology architecture of the hypervisor virtualized vehicle system provided in an embodiment of the present application;

[0016] Figure 2 This is a flow chart of a method for persistent data storage in an in-vehicle system provided by an embodiment of the present application;

[0017] Figure 3 This is a schematic diagram of a data partition design in a vehicle-mounted system provided in an embodiment of the present application;

[0018] Figure 4 This is a data read and write timing diagram on the Android side provided by an embodiment of the present application;

[0019] Figure 5 This is a PersService data read and write timing diagram provided by an embodiment of the present application;

[0020] Figure 6 Schematic diagram of the structure of a data persistent storage device for an in-vehicle system provided in an embodiment of the present application;

[0021] Figure 7 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0023] With the prevalence of intelligent and networked in-vehicle systems, vehicles are integrating a variety of complex systems and applications, such as infotainment, navigation, and driver assistance systems. These systems extensively use data to provide their functions, making persistent data storage a key requirement.

[0024] There are some traditional storage solutions in existing vehicle systems, but these solutions cannot fully meet the data persistence storage needs of increasingly complex vehicle systems. The existing vehicle system data persistence storage solutions have the following main problems:

[0025] 1. Data consistency issues: While driving, in-vehicle systems may experience interruptions due to unforeseen circumstances such as power outages and system crashes. Such unexpected interruptions can affect ongoing persistent storage operations, leading to inconsistencies in stored data. Existing in-vehicle systems often lack native persistent storage capabilities, forcing system vendors to develop and customize them to meet this requirement.

[0026] 2. Data management issues: In-vehicle systems need to process massive amounts of data, including navigation information, vehicle operating status, and user preferences. Traditional storage solutions may not be designed for these complex requirements, resulting in inefficient operations such as reading, writing, and deleting data when faced with massive amounts of data, making effective data management difficult.

[0027] 3. Integration and maintenance issues: While using third-party storage solutions can address some data storage needs, these solutions typically require payment and have a cumbersome integration process. Subsequent system maintenance is also complex, increasing system development and operation costs.

[0028] In view of the problems existing in the prior art, this application provides a data persistence storage solution for vehicle-mounted systems. This solution achieves effective data management, storage, and fast access through the collaborative work of different modules. In particular, it can meet the storage requirements of different data when processing vehicle configuration data.

[0029] Specifically, this application relates to storage technology for in-vehicle systems, and in particular, to a persistent storage technology solution for in-vehicle systems. The in-vehicle persistent storage technology solution provided in this application significantly improves the data reliability, performance, and management efficiency of in-vehicle systems through a multi-layered storage architecture, persistence mechanisms, data isolation strategies, and intelligent data management technologies. This solution has broad application prospects and provides an effective solution for the stability and reliability of in-vehicle systems.

[0030] The following is a summary of the core technical points involved in the persistent storage solution for vehicle systems provided by this application. The core technical content of the technical solution of this application includes the following aspects:

[0031] 1. The persistent storage subsystem is responsible for processing persistent data related to vehicle configuration and providing a unified access method for apps without requiring apps to be concerned with information such as the location and method of vehicle data storage.

[0032] 2. This component design mainly has a three-layer data structure, covering offline (factory) data, 4S store (dealer) configuration data and end-user (user) data. It provides read, write, restore, import and export functions for these data to meet the needs of vehicle configuration data operations in the in-vehicle infotainment system.

[0033] 3. For special fast-access data, we designed a Raw partition method, which can be supported by both Android and Hypervisor.

[0034] 4. All vehicle-related data items need to be defined in advance, and dynamic modification items are not provided. If you need to add or delete certain items, you need to upgrade the vehicle configuration.

[0035] 5. For data access by third-party apps, if there are items that are not in the original data, you need to apply for additional data before you can access it. If the data is not related to vehicle control and is only used by the app itself, it is recommended to use the Android native data storage solution.

[0036] Based on the above-mentioned persistent storage solution, the present application also provides a persistent storage technology architecture for a hypervisor virtualized vehicle system. The content of the persistent storage technology architecture for a hypervisor virtualized vehicle system provided by the present application is described below with reference to the accompanying drawings. Figure 1 This is a schematic diagram of the framework of the persistent storage technology architecture of the Hypervisor virtualized vehicle system provided in the embodiment of the present application. Figure 1 As shown, the persistent storage technology architecture of the hypervisor virtualized vehicle system of this application may include the following modules and module information:

[0037]

[0038] The basic working principle of the vehicle system persistent storage technology architecture of this application is: through the architectural design process, the upper-level application calls the put() interface of persistenceService to persistently store data in the persistent partition database, and when obtaining, it obtains the previously stored data by calling the get() interface of persistenceService.

[0039] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0040] Figure 2 FIG is a flow chart of a data persistence storage method for an in-vehicle system provided by an embodiment of the present application. Figure 2 As shown, the data persistent storage method for the vehicle system may specifically include:

[0041] S201, using an upper-layer application in the vehicle system to call a persistence service interface to write vehicle configuration information into a persistent storage area in the form of key-value pairs, wherein the persistence service interface communicates with the persistence service module through an abstract interface definition language;

[0042] S202, using the persistence service module to determine a target storage area based on the received key-value pair information, wherein the target storage area includes multiple partitions corresponding to different levels of vehicle configuration information;

[0043] S203, writing or updating the vehicle configuration information in the target storage area and storing the vehicle configuration information in a preset format, wherein data in different partitions are isolated and managed according to the identity or authority of the caller;

[0044] S204, when reading vehicle configuration information, use the upper-layer application to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines the corresponding storage area according to the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area.

[0045] In some embodiments, determining a target storage area based on received key-value pair information using a persistence service module includes:

[0046] Utilize the persistence service module to receive key-value pair information sent by the upper-layer application through the persistence service interface, wherein the key-value pair information includes key-value pair data of vehicle configuration information and the corresponding application identifier;

[0047] Use the persistence service module to parse key-value pairs to identify the target data category, data priority, and data scope;

[0048] Determine the target partition type based on the target data category, data priority, and data scope;

[0049] According to the target partition type, a corresponding target storage area is selected from multiple physical storage areas in the vehicle system, wherein the physical storage area includes an Android-side storage area and a virtualized system storage area.

[0050] Specifically, this application provides a persistent storage method for determining target storage areas in an in-vehicle system. Specifically, this method processes storage requests for vehicle configuration information through a persistent service module. Based on received key-value pairs, this method automatically identifies the data's category, priority, and scope, and accordingly determines the target partition and physical storage area where the data should be stored, enabling efficient data management and rapid access.

[0051] In this embodiment, an upper-layer application in the vehicle system (such as an infotainment system or a driver assistance system) sends a storage or read request to the persistence service module by calling the persistence service interface. The request includes key-value pairs of vehicle configuration information and the application identifier associated with the request.

[0052] For example, the upper-layer application may pass the following key-value pair: {key: UIMode, value: 1}, where "UIMode" indicates the display mode of the user interface and the value "1" indicates daytime mode. The application ID is used to identify which application the request comes from.

[0053] Furthermore, after receiving the key-value pair information, the persistence service module will first parse it and identify the following attributes of the data:

[0054] Target data category: For example, whether the data belongs to system configuration, user configuration, or third-party application data.

[0055] Data priority: Based on the requesting application ID or process ID, determine whether the data requires high-priority processing. For example, system configuration data is usually given a higher priority, while personalized data set by the user may have a lower priority.

[0056] Data scope: Determines whether the data is shared across multiple systems or is only used in a specific system environment. The scope can cover different partitions of the Android system and virtualized systems (such as QNX).

[0057] For example, when the persistence service module parses the key-value pair of "UIMode=1", it will determine that the data belongs to the user's interface settings, has a higher priority, and its scope of application is the infotainment module in the Android system and the virtualization system.

[0058] Furthermore, after parsing the data category, priority, and scope, the persistence service module will determine the target partition type based on this information. In practical applications, the following partition types may be included:

[0059] Factory configuration partition: used to store factory settings, suitable for data related to the core configuration of the vehicle.

[0060] Service provider configuration partition: used to store the configuration of the vehicle system made by the 4S store or service provider during the maintenance process.

[0061] User configuration partition: used to store user-defined settings, such as navigation preferences, audio settings, etc.

[0062] High-speed access partition: used to store critical data that requires fast access, such as vehicle status or important system parameters.

[0063] In this embodiment, the persistence service module determines that "UIMode=1" should be stored in the user configuration partition because the data belongs to the user's personalized settings and needs to be shared across Android and virtualization systems.

[0064] Furthermore, the persistence service module selects a suitable target storage area from multiple physical storage areas based on the determined partition type. The vehicle-mounted system usually includes multiple storage areas, for example, including the following storage areas:

[0065] Android storage area: used to store configuration information related to the Android system.

[0066] Virtualized system storage area: For example, the QNX system stores its related configuration and data.

[0067] In this embodiment, the vehicle configuration information of "UIMode=1" will be stored in the Android user configuration partition and synchronized to the virtualized system storage area to ensure that the data can be shared and used in multiple environments such as the infotainment system.

[0068] Furthermore, during data writing, the persistence service module writes the key-value pair data to the specified target storage area according to a predetermined format. During read operations, the persistence service module retrieves the data from the corresponding physical storage area using the key name in the key-value pair and returns the data to the requesting upper-layer application.

[0069] For example, when the upper-layer application requests to read the "UIMode" key value, the persistence service module will search for the key value from the Android storage area or the virtualization system storage area, and return the stored "UIMode=1" to the application to ensure that the user's interface settings are restored correctly.

[0070] Furthermore, for configuration data shared across multiple system environments, the persistence service module ensures data consistency between the Android system and the virtualized system through a data sharing mechanism. When a user changes a configuration item, the data is automatically synchronized to the other systems, ensuring that the vehicle configuration remains consistent across all systems.

[0071] Through the method of the above embodiment, the technical solution of the present application effectively solves the storage and management problems of different vehicle configuration data in the vehicle-mounted system, ensuring the consistency, security, cross-system sharing and fast access of the data.

[0072] In some embodiments, after parsing the key-value pair information using the persistence service module to identify the category of the target data, the priority of the data, and the scope of the data, the method further includes:

[0073] The persistence service module searches the preset permission list based on the caller's application ID to determine the caller's access rights and whether the caller has the permission to access or operate the key-value pair information.

[0074] The target partition type is determined based on the parsed key-value pair information and the caller's access rights, wherein the partition types in the target storage area include factory-configured partitions, service provider-configured partitions, and user-configured partitions.

[0075] Specifically, this application provides a data persistence storage method for an in-vehicle system. It specifically describes how to parse key-value pairs through a persistence service module and, based on the caller's permissions, determine the storage area for the target data. This method effectively ensures the isolated storage of different types of vehicle configuration data, ensuring system security and data consistency.

[0076] First, the upper-layer application in the vehicle system (such as navigation and infotainment systems) sends a key-value pair storage request to the persistence service module by calling the persistence service interface. The request content includes:

[0077] Key-value pair information: such as {key: navigationMode, value: 2}, where "navigationMode" indicates the navigation mode and the value "2" represents a certain navigation setting;

[0078] Application ID: used to identify the application from which the request comes, such as the application ID of the infotainment system.

[0079] Furthermore, after receiving this request, the persistence service module first parses the key-value pair information and identifies the following important information:

[0080] Data categories: such as system data, user data, or third-party application data. Here, navigationMode may belong to the user data category because it involves the user's personalized navigation settings.

[0081] Data priority: Data priority may vary depending on the requesting application. User preferences generally have a lower priority, while data related to core system configuration has a higher priority.

[0082] Scope of data: Determine whether the data is used only in a single system environment (such as the Android system) or needs to be shared across systems (such as supporting both Android and QNX systems).

[0083] Furthermore, after the parsing is completed, the persistence service module further searches the system for a preset permission list based on the requested application ID or process ID. The permission list pre-configures the vehicle configuration information that each application can access or operate.

[0084] Furthermore, the persistence service module uses the list to determine whether the current caller has the permission to access or operate the key-value pair information. The specific operations include:

[0085] Permission matching: The persistence service module extracts accessible data items related to the application identity from the permission list and checks whether the incoming key-value pair information is within the caller's permission range.

[0086] Judgment of legitimacy: If the key-value pair information is in the caller's list of accessible data items, the caller is deemed to have the corresponding access rights and subsequent storage or reading operations are allowed; otherwise, the operation is rejected and an exception log is generated to prevent unauthorized access.

[0087] In this embodiment, assuming that the application identifier indicates that the request comes from the infotainment system and the system has access rights to the navigationMode key, the persistence service module allows the operation to continue.

[0088] Furthermore, after verifying the caller's access rights, the persistence service module further determines the target partition type where the data should be stored based on the parsed data category, data priority, and scope. In the vehicle system, the partition types generally include:

[0089] Factory configuration partition: used to store the vehicle's factory settings or system-level configuration data;

[0090] Service provider configuration partition: used to store configuration data generated by service providers (such as 4S stores) when maintaining vehicles;

[0091] User configuration partition: used to store user's personalized settings, such as navigation, audio, air conditioning and other preferences.

[0092] The following is a detailed introduction to the partition types and partition descriptions of the embodiments of the present application in conjunction with the accompanying drawings and specific examples. Figure 3 This is a schematic diagram of the data partition design in the vehicle-mounted system provided by the embodiment of the present application. Figure 3 As shown, the data partitions and data partition descriptions provided in the embodiment of the present application include the following:

[0093]

[0094]

[0095] For the navigationMode key-value pair in this embodiment, the persistence service module determines that it belongs to the user configuration partition because the data is related to user preference settings and has a low priority, only affecting the personalized usage experience.

[0096] Furthermore, based on the target partition type determined in the above steps, the persistence service module selects a corresponding storage area from multiple physical storage areas. Common physical storage areas include:

[0097] Android storage area: used to store vehicle configuration information related to the Android system;

[0098] Virtualization system storage area: For example, the QNX system is used to store vehicle configuration information related to the virtualization operating system.

[0099] In this embodiment, the configuration information of navigationMode will be stored in the user configuration partition of the Android side to ensure that the user's personalized settings can be persisted by the system and restored after the system is restarted or upgraded.

[0100] Furthermore, in some cases, if the configuration item needs to be shared between multiple systems (such as Android and QNX), the persistence service module will synchronize the data to the virtualized system storage area through a cross-system data synchronization mechanism to ensure data consistency and availability in different operating system environments.

[0101] Through the above-mentioned method of this embodiment, this embodiment can accurately determine the target partition type and storage area by parsing key-value pair information and combining the caller's permission verification and data category determination, thereby realizing effective management, storage and isolation of vehicle configuration information, and improving the security and data consistency of the vehicle system.

[0102] In some embodiments, after selecting a corresponding target storage area from a plurality of physical storage areas in the vehicle system according to the target partition type, the method further includes:

[0103] For write operations, the persistence service module is used to store the parsed key-value pair information in a preset format in the target storage area, and synchronize or update the data according to the storage strategy of different partitions;

[0104] For read operations, the persistence service module is used to retrieve the target storage area based on the data items in the parsed key-value pair information and return the corresponding vehicle configuration information.

[0105] Specifically, the present embodiment also describes how to use the persistence service module to write and read data after selecting the corresponding target storage area from the vehicle system based on the target partition type. This method ensures the correct storage and retrieval of vehicle configuration information and supports data synchronization or updates, thereby improving the vehicle system's persistent storage capabilities and data management efficiency.

[0106] First, the persistence service module determines the target partition type (e.g., factory-configured partition, provider-configured partition, or user-configured partition) based on the parsed key-value pair information. Next, the persistence service module selects an appropriate target storage area from multiple physical storage areas. Common storage areas include:

[0107] Android storage area: used to store vehicle configuration information related to the Android system;

[0108] Virtualization system storage area: For example, in the QNX system, this area is used to store configuration information related to the virtualization operating system.

[0109] For example, when the storage involves vehicle user personalized settings (such as navigation, audio, etc.), the persistence service module will select the Android user configuration partition as the target storage area.

[0110] Furthermore, when performing a write operation, the persistence service module stores the parsed key-value pair information in a preset format in the target storage area. The specific operation steps are as follows:

[0111] 1) Preset formatting:

[0112] The persistence service module pre-formats the key-value pairs based on the vehicle configuration information's category, data priority, and scope to ensure the data structure can be correctly identified and stored in the target storage area. For example, the formatted data may be stored in binary, JSON, or XML formats.

[0113] 2) Write to the target storage area:

[0114] The persistence service module writes the formatted key-value data to the selected target storage area. For example, if the user's navigation mode configuration data is stored (such as {key: navigationMode, value: 2}), the data will be stored in the user configuration partition on the Android side in a formatted manner.

[0115] 3) Data synchronization or update:

[0116] In some cases, vehicle configuration information needs to be synchronized across multiple systems (such as Android and QNX virtualization systems). To ensure data consistency between systems, the persistence service module synchronizes or updates data based on the storage policy of the specific partition after completing the write operation.

[0117] For example, navigationMode data is not only stored on the Android side, but also synchronized to the corresponding storage partition of the QNX system through the data sharing mechanism to ensure the consistency of configuration when users use it between different systems.

[0118] 4) Update storage policy:

[0119] For existing vehicle configuration information, if the new key-value pair information conflicts with the existing data, the persistence service module will decide whether to overwrite the original data or perform an incremental update based on the new data according to the established update strategy.

[0120] Furthermore, for data reading operations, the persistence service module will retrieve the target storage area based on the data items in the parsed key-value pair information and return the corresponding vehicle configuration information. The specific operation steps are as follows:

[0121] 1) Retrieve the target storage area:

[0122] The persistence service module locates the specified target storage area based on the key name information in the key-value pair. For example, if the key requested to read is navigationMode, the persistence service module will first locate the user configuration partition on the Android side or other partitions storing this information.

[0123] 2) Get configuration information:

[0124] The persistence service module searches the target storage area and finds the configuration information that matches the key name. Assuming the requested key is navigationMode, the value of the data item returned after the search (such as 2) represents the current vehicle's navigation mode setting.

[0125] 3) Return result:

[0126] The persistence service module returns the retrieved vehicle configuration information to the requesting upper-layer application. For example, if the user's navigation system requests to read the navigation mode configuration, the system will return the currently stored navigationMode=2 value to the navigation application so that it can adjust accordingly based on the configuration.

[0127] 4) Error handling and default values

[0128] If the persistence service module fails to find the corresponding key-value information in the target storage area during data reading, the system will return the preset default value. At the same time, if a storage or reading exception occurs, the persistence service module will generate a corresponding exception log to facilitate subsequent troubleshooting and system maintenance.

[0129] 5) Data security and integrity

[0130] To ensure the security and integrity of data storage and transmission, the persistence service module can encrypt the stored data using an encryption algorithm. In addition, when synchronizing or updating data, the persistence service module can use a verification mechanism to ensure data consistency between different systems.

[0131] Through the above-described method of this embodiment, the persistence service module provided by this embodiment achieves efficient storage and access of vehicle configuration information through the above steps. This method not only supports cross-system data synchronization and updates, but also securely manages data based on different partitioning strategies, ensuring the stability and consistency of data storage in the vehicle system.

[0132] In some embodiments, the method further comprises:

[0133] Classify the received vehicle configuration information and identify data items that need to be accessed frequently or in real time in specific scenarios as fast access data;

[0134] Use independent high-speed access partitions to store fast-access data, and share the data stored in the high-speed access partitions to different system environments through cross-system data sharing plug-ins;

[0135] The data sharing plug-in is used to establish a communication channel between the Android system and the virtualization system so as to bidirectionally transfer and synchronize data in the high-speed access partition between the Android system and the virtualization system.

[0136] Specifically, this paper introduces a method for storing and sharing fast-access data in an in-vehicle system. Specifically, for vehicle configuration information that requires frequent or real-time access, this method utilizes high-speed access partitions for efficient storage. Furthermore, a cross-system data sharing plug-in enables data synchronization and bidirectional transfer between different systems. This embodiment details the specific steps for classifying, storing, and sharing fast-access data across systems.

[0137] In vehicle systems, certain vehicle configuration information requires frequent or real-time access in specific scenarios. To improve system responsiveness, the persistence service module categorizes the received vehicle configuration information and identifies which data requires rapid processing.

[0138] The persistence service module categorizes vehicle configuration information into regular data and fast-access data based on the data's application scenario and access frequency. For example, real-time vehicle status information (such as speed and engine status) and certain user interaction information (such as air conditioning settings and audio volume) may be classified as fast-access data because they need to be read or updated frequently.

[0139] Once a data item is identified as fast-access data, the persistence service module will tag it with a fast-access tag so that it can be specially handled in subsequent storage operations.

[0140] After identifying fast-access data, the persistence service module stores it in a separate high-speed access partition. Designed specifically for frequently accessed data, high-speed access partitions offer lower read and write latency and higher performance, ensuring the fastest possible processing when real-time responses are required.

[0141] The persistence service module writes fast-access data directly to a high-speed access partition based on data priority and classification results. The physical storage location of this partition can be located in the high-speed storage device of the vehicle system to optimize data read and write speed.

[0142] For example, the vehicle's engine status information (such as {key: engineStatus, value: running}) is classified as fast-access data, and the persistence service module stores the information in a high-speed access partition so that the system can quickly read or update the data.

[0143] Furthermore, in order to ensure the consistency of vehicle configuration information in different system environments, especially when the vehicle system runs multiple operating systems (such as Android and virtualization system QNX) at the same time, this embodiment uses a cross-system data sharing plug-in to achieve high-speed access to the data in the partition and two-way transmission and synchronization between different systems.

[0144] The Data Sharing plugin establishes a communication channel between the Android system and a virtualization system (such as QNX), allowing both operating systems to simultaneously access and modify data in the high-speed access partition. The plugin manages the data transfer and synchronization between the different systems, ensuring that each system has access to the latest high-speed access data in real time.

[0145] When an Android application modifies fast-access data in the high-speed access partition, the data sharing plug-in automatically synchronizes these updates to the virtualized system, and vice versa. Through this two-way synchronization mechanism, all operating environments of the vehicle system can maintain consistent vehicle configuration information.

[0146] For example, when a navigation application in the Android system modifies the vehicle's real-time location data, the updated data will be synchronized to the QNX virtualization system through the data sharing plug-in, so that other applications in the QNX system can also obtain the latest location information in real time.

[0147] Furthermore, the data sharing plug-in not only synchronizes data but also allows for bidirectional data transfer between different systems, meaning that changes made by any system to data in the high-speed access partition can be immediately retrieved and updated by the other system.

[0148] When one system modifies fast-access data, the data sharing plug-in synchronizes the changes to the other system via an internal communication channel. This mechanism ensures the timeliness and consistency of vehicle configuration information in an environment where multiple operating systems run in parallel.

[0149] For example, when the driving assistance system in the QNX system updates the vehicle speed information (such as {key: vehicleSpeed, value: 60}), the modified data will be synchronized to the Android system in real time through the data sharing plug-in to ensure that other related applications can obtain the latest speed information.

[0150] Furthermore, to ensure the integrity of high-speed access data during transmission and synchronization, the data sharing plug-in includes necessary verification mechanisms to ensure that data is not lost or corrupted during cross-system transmission. Furthermore, the plug-in can also protect data security through encryption, preventing unauthorized systems or applications from accessing sensitive data in the high-speed access zone.

[0151] Through the method described in this embodiment, the vehicle system can effectively identify and process vehicle configuration information that requires frequent or real-time access. High-speed access partitions are used to achieve efficient data storage. Furthermore, a cross-system data sharing plug-in ensures data synchronization and bidirectional transmission between different systems. This method not only improves system response speed but also ensures data consistency and security.

[0152] In some embodiments, bidirectionally transferring and synchronizing data in the high-speed access partition between the Android system and the virtualization system includes:

[0153] When an application in the Android system or virtualized system issues a request for fast access to data, the persistence service module uses the corresponding data sharing plug-in to direct the request to the high-speed access partition and obtain the data;

[0154] When the data in the high-speed access partition is updated in any system, the updated data is synchronized to the other system using the data sharing plug-in.

[0155] Specifically, this embodiment also introduces a method for bidirectionally transferring and synchronizing data in a high-speed access partition between an Android system and a virtualization system (such as a QNX system) through a persistence service module. This embodiment focuses on how to achieve efficient acquisition and consistency maintenance of fast-access data in a multi-operating system environment.

[0156] In the in-vehicle system, certain key vehicle configuration information needs to be bidirectionally transmitted and synchronized between the Android system and the virtualization system, especially data in high-speed access partitions, such as the vehicle's real-time status and user interaction information. This data usually needs to be shared and maintained consistent across multiple operating system environments.

[0157] To achieve this data sharing, this embodiment utilizes a persistence service module and a data sharing plug-in to ensure that requests and updates for high-speed access to data in the two systems can be effectively processed.

[0158] Furthermore, when an application in the Android system or virtualization system issues a request for fast access to data, the persistence service module is responsible for receiving the request and directing the request to the high-speed access partition through the data sharing plug-in. The specific steps are as follows:

[0159] Furthermore, an application in the Android system or the virtualized system may issue a request to read a certain fast-access data item. For example, the infotainment system in the Android system may request to obtain the current speed of the vehicle, and the driving assistance module in the virtualized system may request to obtain the engine status.

[0160] Furthermore, the persistence service module uses the data sharing plug-in to determine which system the request comes from and decide how to handle the request. This plug-in is responsible for establishing a communication bridge between the Android system and the virtualization system, ensuring that the request can access data across systems.

[0161] Furthermore, the persistence service module directs the request to the corresponding data item in the high-speed access partition based on the request type. For example, when the Android system requests to read the vehicle speed, the data sharing plug-in will direct the request to the high-speed access partition and retrieve the current speed data (such as {key: vehicleSpeed, value: 80}).

[0162] Furthermore, the data sharing plug-in retrieves the required fast-access data from the high-speed access partition and returns it to the requesting system. For example, if an application in the QNX system requests engine status, the persistence service module retrieves the engine status from the high-speed access partition through the data sharing plug-in and returns the data to the application in the virtualized system.

[0163] Furthermore, when data in the high-speed access partition is updated in any system, the persistence service module will synchronize the updated data to the other system through the data sharing plug-in to ensure data consistency. The specific steps are as follows:

[0164] 1) Data update trigger:

[0165] When an application in the Android system or virtualized system updates a data item in the high-speed access partition, the persistence service module detects the operation. For example, when a navigation application in the Android system modifies the vehicle's real-time location data, or when a driver assistance module in the virtualized system updates the throttle status.

[0166] 2) Synchronize to another system:

[0167] The data sharing plug-in is responsible for synchronizing updated data with the other system. For example, when an application in the Android system updates the vehicle's location, the data sharing plug-in will immediately synchronize this data with the virtualization system, ensuring that the QNX system can obtain the latest location information in real time.

[0168] 3) Two-way transmission mechanism:

[0169] During this process, the data sharing plug-in can not only transfer data from one system to another, but also realize bidirectional transfer as needed. This means that if the application in the QNX system modifies the data, the modification will also be synchronized back to the Android system through the data sharing plug-in.

[0170] 4) Data consistency maintenance:

[0171] To ensure the integrity of data transmission and synchronization between different systems, the data sharing plug-in can confirm the correctness of the data through a verification mechanism. At the same time, the persistence service module is responsible for coordinating the synchronization order between different systems to avoid data conflicts or overwriting errors.

[0172] For example, in certain scenarios, such as a vehicle's air conditioning system settings, Android applications may frequently read and update these configurations. To ensure consistency across the virtualized system, the persistence service module synchronizes updates from the Android system to the virtualized system through a data sharing plug-in, allowing the QNX system to respond to user operations in real time.

[0173] Suppose the temperature setting of the air conditioning system is updated, the data sharing plug-in synchronizes the setting to the virtualization system so that the driver assistance system can also obtain the data in real time.

[0174] Through the above-described method of this embodiment, this embodiment provides a method for bidirectional transmission and synchronization of fast-access data in high-speed access partitions between the Android system and the virtualization system. The persistence service module and the data sharing plug-in jointly ensure that data can flow efficiently between different systems. After the data is updated, it can be synchronized to the other system in real time, ensuring data consistency and the stability of system collaboration.

[0175] In some embodiments, the method further comprises:

[0176] Using the persistence service module to query the preset permission configuration table according to the caller's application package name, obtain the key value list accessible to the caller, wherein the key value list contains the key names of the vehicle configuration information data items that the application is allowed to access;

[0177] Verify the key-value information passed in by the caller to determine whether the key name in the key-value information is in the key-value list accessible to the caller. If the key name is not in the key-value list, reject the data access request and throw an exception. If the key name is in the key-value list, allow continued access.

[0178] For service requests at the system level, distinguish the access rights of different services based on the caller's process name and find the permission configuration of the corresponding process;

[0179] After the permission verification is passed, the caller is allowed to initiate data read and write operations, and use the abstract interface of the vehicle system to realize the interaction of data between the application layer and the persistent storage layer.

[0180] Specifically, this embodiment also introduces a method for controlling application access to vehicle configuration information based on a persistence service module. By combining the application package name and process name, permissions are verified for different applications and system services, ensuring data isolation and preventing unauthorized data access. This embodiment details how permission verification and data access management are performed using the persistence service module.

[0181] First, when an upper-layer application or system service issues a read or write request for vehicle configuration information, the persistence service module first queries the preset permission configuration table based on the caller's application package name to obtain a list of key values ​​that the application can access. This list contains the key names of the vehicle configuration information that the application is authorized to access.

[0182] After receiving the request, the persistence service module extracts the application package name contained in the request. For example, the package name of an infotainment system application may be com.car.entertainment. The persistence service module uses this package name to query the permission configuration table and obtain the list of key values ​​that the application is allowed to access.

[0183] Furthermore, the key-value list contains the vehicle configuration information that the application is allowed to operate. For example, the infotainment system may be authorized to access vehicle settings such as {key: audioVolume, key: screenBrightness}, but cannot access sensitive data related to driving control.

[0184] Furthermore, after obtaining the caller's key-value list, the persistence service module begins to verify the key-value information passed in by the caller. The specific implementation steps are as follows:

[0185] 1) Check the legitimacy of the key name:

[0186] The persistence service module checks whether the key name passed by the caller is in the application's list of accessible keys. For example, if the caller requests to operate the audioVolume key, the persistence service module will check whether the key name is in the infotainment system's permission list.

[0187] 2) Reject unauthorized requests:

[0188] If the caller passes in a key name that is not within its permission range, the persistence service module will deny the data access request and throw an exception to prevent unauthorized operations. For example, if the infotainment system attempts to access engineStatus (sensitive driving-related data), the persistence service module will deny the request and generate an exception log.

[0189] 3) Continue to authorize access:

[0190] If the key name passed in is in the caller's list of accessible keys, the persistence service module will allow further access. For example, if the infotainment system requests to modify the audioVolume, and the key name is in the permission list, the next data operation will be allowed.

[0191] Furthermore, for system-level service requests, permission verification is slightly different. System services distinguish permissions by process name, and different processes have different permission ranges. The persistence service module searches the corresponding permission configuration based on the requested process name to determine whether the system service has permission to operate vehicle configuration information.

[0192] For example, the driving control module in the QNX virtualization system may use com.car.qnx.control as the process name. The persistence service module queries the system permission configuration table based on the process name to determine whether the service can access certain vehicle configuration information.

[0193] Furthermore, the persistence service module verifies system service requests to ensure that system processes can only access data within their scope of authority. For example, the driving control module can access engineStatus but cannot access user-defined settings such as audioVolume.

[0194] Furthermore, after the permission verification is passed, the persistence service module allows the caller to initiate data read and write operations. The specific operation steps are as follows:

[0195] 1) Data read and write operations:

[0196] Permission-verified callers can initiate data read and write requests to the persistent storage layer. The persistence service module uses the vehicle system's abstract interface to transfer data from the application layer to the persistent storage layer, or retrieve data from the storage layer and return it to the caller. For example, if the infotainment system changes the volume setting, the persistence service module writes the change to the storage layer and updates the vehicle's audio configuration.

[0197] The following uses Android-side data reading and writing and PersService data reading and writing as examples to illustrate the implementation process of data reading and writing operations. Figure 4 This is a data read and write timing diagram on the Android side provided by the embodiment of the present application. Figure 5 This is a sequence diagram of the PersService data read and write provided by the embodiment of this application. Figures 4 and 5 As shown, the data read and write operations provided in the embodiment of the present application may include the following:

[0198] In this embodiment, the specific implementation process of data reading and writing based on Android side and persistent service (PersService) data reading and writing is introduced in detail. Figure 4 and Figure 5 The following describes in detail how to complete the data read and write operations in the vehicle system. This embodiment describes a series of steps, including data request initiation from the application layer, permission verification, data acquisition and return.

[0199] 1. Data read and write operations on the Android side

[0200] Figure 4 The data read and write timing on the Android side is shown. The specific process is as follows:

[0201] 1.1 Application initiates data request:

[0202] The application in the Android system issues a read request for a vehicle configuration information by calling the persistence service interface. The called interface can be getInt(KeyName,value), where KeyName is the key name of the data item to be read, such as audioVolume, and value is the default value. When the corresponding key is not found, the system will return the default value.

[0203] 1.2 Persistence Service module (PersistenceService) processes requests:

[0204] The persistence service module first receives the application's request and calls PersService for subsequent processing. During this process, PersistenceService interacts with PersService through the AIDL interface (Android Interface Definition Language) and passes the application's request to PersService.

[0205] 1.3 Permission verification:

[0206] The persistence service module verifies the legitimacy of the request using the application's package name. First, PersistenceService calls the PersGetAuthority(AppName) method to check whether the calling application has permission to access the key. The persistence service module performs this verification based on the caller's permission list (getAvailableKeyList(AppName)) and the plugin's permission list (getPluginAvailableKeyList(AppName)). If the permission check fails, the system throws an exception and rejects the request. If the permission is granted, the subsequent operation continues.

[0207] 1.4 Read data:

[0208] The persistence service module initiates a request to the underlying system through the getInt(KeyName,value) interface. If it is data in the Android system, the data stored in the Android system is directly read through the PersService module; if data needs to be obtained from a virtualization system (such as QNX), it communicates with the QNX plug-in through the getPluginAvailableKeyList interface to read the vehicle configuration information in the virtualization system.

[0209] 1.5 Return result:

[0210] After the data is read, the persistence service module returns the retrieved vehicle configuration information to the application, completing the data reading and writing process. For example, if the key value requested is audioVolume, the system will return the current volume setting information to the application.

[0211] 2.PersService data read and write operations

[0212] Figure 5 The data read and write timing of the persistence service module (PersService) is shown. The specific process is as follows:

[0213] 2.1 The persistence service module initiates a read request:

[0214] After receiving the application's request, the PersistenceService module calls the PersService to perform the data read operation. The PersService obtains a PersClient instance through the internal getClient(AppName) method, which is responsible for handling the application's data read operation.

[0215] 2.2 Get available data providers:

[0216] The persistence service module iterates all persistent data providers (PersProvider) through the PersManager module. These providers are responsible for managing different types of vehicle configuration information. The PersManager traverses all PersProviders and finds the appropriate provider that can handle the current key value.

[0217] 2.3 Verify key value and obtain data:

[0218] After finding the appropriate PersProvider, the persistence service module obtains the corresponding key-value pair data through the getKeyValue(KeyName) method. During the execution process, the system will verify whether the key value exists and determine whether to continue the data reading operation based on the legitimacy of the key value:

[0219] If the key value is found, the corresponding configuration information is returned. If the key value is not found, the default value is returned, further operations are terminated, and the data is returned to the PersistenceService. After successfully obtaining the vehicle configuration information, the persistence service module passes the data to the PersistenceService via the PersClient. At this point, the persistence service module returns the retrieved data value to the upper-layer application that initiated the request.

[0220] pass Figure 4 and Figure 5 The process shown, the read and write operations on the Android side and the persistence service module provided by this application can achieve the following functions:

[0221] Upper-level applications initiate requests through the persistence service module, and the system determines whether to grant data access based on permission checks. The persistence service module calls PersService to obtain the corresponding vehicle configuration information, supporting data acquisition from the Android system or virtualized systems. Through data provider management, effective data isolation and access are achieved, ensuring data security and consistency.

[0222] Through the operations of the above embodiments, the vehicle system can efficiently and securely manage and access various types of vehicle configuration information, ensuring the synchronization and consistency of data in the Android system and the virtualization system.

[0223] 2) AIDL and inter-process communication:

[0224] In the Android system, the persistence service module uses AIDL (Android Interface Definition Language) to implement inter-process communication between different applications and system services. After passing the permission verification, the caller continues to initiate AIDL calls to interact with the underlying persistent storage layer.

[0225] 3) Data isolation and permission control:

[0226] Each application can only access its authorized data, and any attempt to access data from other services will result in an exception. For example, the infotainment system cannot access data from the driver control module, and vice versa. The persistence service module strictly enforces data isolation, ensuring data security between different applications and services.

[0227] Furthermore, the persistence service module supports dynamic permission configuration. In certain circumstances, system administrators or vendors can dynamically adjust the access permissions of applications or system services by updating the permission configuration table. For example, after a system upgrade or security policy adjustment, it is possible to temporarily increase the access permissions of an application or restrict the access scope of certain services.

[0228] In one example, the AIDL interface in the above embodiment of the present application includes the following information:

[0229]

[0230]

[0231] It should be noted that the actual value returned by the getInt method in the above AIDL interface information is, for example, to store the current system mode as daytime. If UIMode = 1 is stored in the database, 1 is the actual value (UIMode - = 1 for daytime mode, UImode = 0 for nighttime mode). The purpose of the input parameter value returned on failure is to store the value required by the business scenario and ensure persistence. The stored value remains unchanged during upgrades and factory resets.

[0232] According to the method described above, this embodiment implements strict management of data access permissions for applications and system services through a persistence service module. By querying a preset permission configuration table and verifying key-value information, the persistence service module ensures that each caller can only access vehicle configuration information within their scope of authority, effectively preventing unauthorized access to data. It also enables data read and write operations through the AIDL interface. This method improves the data security and isolation of the vehicle system and ensures the collaborative operation of different applications and services.

[0233] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0234] Figure 6 Schematic diagram of the structure of the data persistent storage device for the vehicle system provided by the embodiment of the present application. Figure 6 As shown, the data persistent storage device for the vehicle system includes:

[0235] The calling module 601 is configured to use the upper-layer application in the vehicle system to call the persistence service interface and write the vehicle configuration information into the persistent storage area in the form of key-value pairs, wherein the persistence service interface communicates with the persistence service module through the abstract interface definition language;

[0236] The determination module 602 is configured to use the persistence service module to determine a target storage area according to the received key-value pair information, wherein the target storage area includes a plurality of partitions for storing vehicle configuration information of different levels;

[0237] The storage module 603 is configured to write or update the vehicle configuration information in the target storage area and store the vehicle configuration information in a preset format, wherein the data of different partitions are isolated and managed according to the identity or authority of the caller;

[0238] The reading module 604 is configured to use the upper-layer application to send a read request to the persistence service module through the persistence service interface when reading the vehicle configuration information, so that the persistence service module determines the corresponding storage area according to the key-value pair information in the read request and obtains the corresponding vehicle configuration information from the storage area.

[0239] In some embodiments, Figure 6 The determination module 602 uses the persistence service module to receive the key-value pair information sent by the upper-level application through the persistence service interface, wherein the key-value pair information includes the key-value pair data of the vehicle configuration information and the corresponding application identifier; uses the persistence service module to parse the key-value pair information to identify the category of the target data, the priority of the data and the scope of the data; determines the target partition type according to the category of the target data, the priority of the data and the scope of the data; selects the corresponding target storage area from multiple physical storage areas in the vehicle system according to the target partition type, wherein the physical storage area includes the Android-side storage area and the virtualization system storage area.

[0240] In some embodiments, Figure 6 The determination module 602 uses the persistence service module to parse the key-value pair information and identify the category of the target data, the priority of the data and the scope of the data. Then, the persistence service module uses the application identifier of the caller to search the preset permission list and determine the caller's access rights to determine whether the caller has the permission to access or operate the key-value pair information; based on the parsed key-value pair information and the caller's access rights, the target partition type is determined, where the partition types in the target storage area include factory configuration partitions, service provider configuration partitions and user configuration partitions.

[0241] In some embodiments, Figure 6After the synchronization module 605 selects the corresponding target storage area from multiple physical storage areas in the vehicle system according to the target partition type, for write operations, it uses the persistence service module to store the parsed key-value pair information in a preset format in the target storage area, and synchronizes or updates the data according to the storage strategies of different partitions; for read operations, it uses the persistence service module to retrieve the target storage area according to the data items in the parsed key-value pair information, and returns the corresponding vehicle configuration information.

[0242] In some embodiments, Figure 6 The sharing module 606 classifies the received vehicle configuration information and identifies data items that need to be accessed frequently or in real time in specific scenarios as fast access data; uses independent high-speed access partitions to store the fast access data, and uses a cross-system data sharing plug-in to share the data stored in the high-speed access partitions to different system environments; wherein, the data sharing plug-in is used to establish a communication channel between the Android system and the virtualization system so as to bidirectionally transfer and synchronize the data in the high-speed access partitions between the Android system and the virtualization system.

[0243] In some embodiments, Figure 6 When an application in the Android system or virtualization system issues a request for fast access to data, the sharing module 606 uses the persistence service module to direct the request to the high-speed access partition and obtain the data through the corresponding data sharing plug-in; when the data in the high-speed access partition is updated in any system, the data sharing plug-in is used to synchronize the updated data to the other system.

[0244] In some embodiments, Figure 6 The verification module 607 uses the persistence service module to query the preset permission configuration table according to the caller's application package name, and obtains the key value list accessible to the caller, wherein the key value list contains the key names of the vehicle configuration information data items that the application is allowed to access; the key value information passed in by the caller is verified to determine whether the key name in the key value information is in the key value list accessible to the caller. If the key name is not in the key value list, the data access request is rejected and an exception is thrown. If the key name is in the key value list, access is allowed to continue; for service requests at the system layer, the access rights of different services are distinguished according to the caller's process name, and the permission configuration of the corresponding process is found; after the permission verification is passed, the caller is allowed to initiate data read and write operations, and the abstract interface of the vehicle system is used to realize the interaction of data between the application layer and the persistent storage layer.

[0245] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0246] Figure 7 Schematic diagram of the structure of the electronic device 7 provided in the embodiment of the present application. Figure 7 As shown, the electronic device 7 of this embodiment includes: a processor 701, a memory 702, and a computer program 703 stored in the memory 702 and executable on the processor 701. When the processor 701 executes the computer program 703, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 701 executes the computer program 703, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0247] For example, the computer program 703 may be divided into one or more modules / units, which are stored in the memory 702 and executed by the processor 701 to implement the present application. The one or more modules / units may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program 703 in the electronic device 7.

[0248] The electronic device 7 may be a desktop computer, a notebook, a PDA, a cloud server or other electronic device. The electronic device 7 may include but is not limited to a processor 701 and a memory 702. Those skilled in the art will understand that Figure 7 It is only an example of the electronic device 7 and does not constitute a limitation of the electronic device 7. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0249] The processor 701 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0250] The memory 702 can be an internal storage unit of the electronic device 7, such as a hard disk or memory of the electronic device 7. The memory 702 can also be an external storage device of the electronic device 7, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the electronic device 7. Furthermore, the memory 702 can include both an internal storage unit of the electronic device 7 and an external storage device. The memory 702 is used to store computer programs and other programs and data required by the electronic device. The memory 702 can also be used to temporarily store data that has been output or is about to be output.

[0251] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0252] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0253] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel 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.

[0254] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

[0255] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0256] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0257] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0258] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A data persistent storage method for an in-vehicle system, characterized in that: include: Using an upper-layer application in the vehicle system to call a persistence service interface, the vehicle configuration information is written into a persistent storage area in the form of key-value pairs, wherein the persistence service interface communicates with the persistence service module via an abstract interface definition language; Determining a target storage area according to the received key-value pair information using the persistence service module, wherein the target storage area includes a plurality of partitions corresponding to vehicle configuration information of different levels; Writing or updating vehicle configuration information in the target storage area and storing the vehicle configuration information in a preset format, wherein data in different partitions are isolated and managed according to the identity or authority of the caller; When reading the vehicle configuration information, using the upper-layer application to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines the corresponding storage area according to the key-value pair information in the read request, and obtains the corresponding vehicle configuration information from the storage area; The step of using the persistence service module to determine the target storage area according to the received key-value pair information includes: Utilizing the persistence service module to receive key-value pair information sent by the upper layer application through the persistence service interface, wherein the key-value pair information includes key-value pair data of vehicle configuration information and a corresponding application identifier; Utilizing the persistence service module to parse the key-value pair information, identifying the category of target data, the priority of the data, and the scope of the data; Determine the target partition type according to the category of the target data, the priority of the data, and the scope of the data; Selecting a corresponding target storage area from a plurality of physical storage areas in the vehicle system according to the target partition type, wherein the physical storage area includes an Android-side storage area and a virtualized system storage area; Among them, the categories of the target data include system data, user data and third-party application data. The priority of the data is used to determine whether the data requires high-priority processing based on the requested application identifier or process identifier. The scope of the data is used to determine whether the data is used in a single system environment or shared across systems.

2. The method according to claim 1, characterized in that After parsing the key-value pair information using the persistence service module to identify the category of target data, the priority of the data, and the scope of the data, the method further includes: Using the persistence service module to search a preset permission list according to the caller's application identifier, determine the caller's access rights, and judge whether the caller has the permission to access or operate the key-value pair information; The target partition type is determined according to the parsed key-value pair information and the access rights of the caller, wherein the partition types in the target storage area include factory-configured partitions, service provider-configured partitions, and user-configured partitions.

3. The method according to claim 2, characterized in that After selecting a corresponding target storage area from a plurality of physical storage areas in the vehicle system according to the target partition type, the method further includes: For write operations, the persistence service module is used to store the parsed key-value pair information in a preset format in the target storage area, and synchronize or update the data according to the storage strategies of different partitions; For a read operation, the persistence service module is used to search the target storage area according to the data items in the parsed key-value pair information, and return the corresponding vehicle configuration information.

4. The method according to claim 1, wherein The method further comprises: Classify the received vehicle configuration information and identify data items that need to be accessed frequently or in real time in specific scenarios as fast access data; Using independent high-speed access partitions to store the fast-access data, and sharing the data stored in the high-speed access partitions to different system environments through a cross-system data sharing plug-in; The data sharing plug-in is used to establish a communication channel between the Android system and the virtualization system, so as to bidirectionally transfer and synchronize the data in the high-speed access partition between the Android system and the virtualization system.

5. The method according to claim 4, characterized in that The bidirectionally transmitting and synchronizing the data in the high-speed access partition between the Android system and the virtualization system includes: When an application in the Android system or the virtualization system issues a request for the fast access data, the persistence service module is used to direct the request to the high-speed access partition and obtain the data through the corresponding data sharing plug-in; When the data in the high-speed access partition is updated in any system, the updated data is synchronized to the other system using the data sharing plug-in.

6. The method according to claim 1, wherein The method further comprises: Utilizing the persistence service module to query a preset permission configuration table based on the caller's application package name to obtain a key value list accessible to the caller, wherein the key value list includes key names of vehicle configuration information data items that the application is allowed to access; Verify the key-value information passed in by the caller to determine whether the key name in the key-value information is in the key-value list accessible to the caller. If the key name is not in the key-value list, reject the data access request and throw an exception. If the key name is in the key-value list, allow continued access. For service requests at the system level, distinguish the access rights of different services based on the process name of the caller and find the permission configuration of the corresponding process; After the permission verification is passed, the caller is allowed to initiate data read and write operations, and the abstract interface of the vehicle system is used to realize the interaction of data between the application layer and the persistent storage layer.

7. A data persistent storage device for an in-vehicle system, characterized in that: include: a calling module configured to call a persistence service interface using an upper-layer application in the vehicle system to write the vehicle configuration information into a persistent storage area in the form of key-value pairs, wherein the persistence service interface communicates with the persistence service module via an abstract interface definition language; a determination module configured to determine, using the persistence service module, a target storage area according to the received key-value pair information, wherein the target storage area includes a plurality of partitions corresponding to vehicle configuration information of different levels; a storage module configured to write or update vehicle configuration information in the target storage area and store the vehicle configuration information in a preset format, wherein data in different partitions are isolated and managed according to the identity or authority of the caller; a reading module configured to, when reading the vehicle configuration information, use the upper-layer application to send a read request to the persistence service module through the persistence service interface, so that the persistence service module determines a corresponding storage area based on key-value pair information in the read request and obtains the corresponding vehicle configuration information from the storage area; Among them, the determination module is used to use the persistence service module to receive key-value pair information sent by the upper-level application through the persistence service interface, wherein the key-value pair information contains key-value pair data of vehicle configuration information and the corresponding application identifier; use the persistence service module to parse the key-value pair information to identify the category of target data, the priority of data and the scope of data; determine the target partition type according to the category of target data, the priority of data and the scope of data; according to the target partition type, select the corresponding target storage area from multiple physical storage areas in the vehicle system, wherein the physical storage area includes the Android-side storage area and the virtualized system storage area; wherein the category of the target data includes system data, user data and third-party application data, the priority of the data is used to determine whether the data needs high-priority processing based on the requested application identifier or process identifier, and the scope of the data is used to determine whether the data is used in a single system environment or shared across systems.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images