Data persistence storage method and device for vehicle-mounted system and storage medium

Abstract

The invention provides a data persistence storage method and device for a vehicle-mounted system and a storage medium. The method comprises the steps that vehicle configuration information is written into a persistent storage area in a key value pair mode; determining a target storage area according to the received key value pair information; vehicle configuration information is written or updated in the target storage area, the vehicle configuration information is stored in a preset format, and data of different partitions are isolated and managed according to identities or permissions of callers; when the vehicle configuration information is read, a reading request is sent to the persistent service module through the persistent service interface by utilizing the upper-layer application, so that the persistent service module determines a corresponding storage area according to the key value pair information in the reading request, and the corresponding vehicle configuration information is acquired from the storage area. According to the invention, the data consistency can be ensured, the data management is simplified, and the scheme can be efficiently integrated in different system environments.

Description

Technical Field

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

[0002] With the widespread application of intelligent and networked vehicle systems, vehicles are integrated with complex applications such as infotainment systems, navigation systems, and driver assistance systems. These systems need to process and store a large amount of vehicle configuration information and operating data. In order to ensure the continuous and efficient operation of the system, the vehicle system has an increasing demand for persistent data storage.

[0003] Traditional in-vehicle data storage solutions have many shortcomings, especially when dealing with the current complex in-vehicle system requirements. Specifically, they have the following shortcomings:

[0004] During vehicle operation, unexpected situations such as power outages or system crashes may cause data writing to be interrupted, leading to data inconsistency. Existing vehicle systems usually do not have built-in persistent storage support, and vehicle system manufacturers need to develop customized persistent storage functions on their own, which increases development difficulty and cost.

[0005] In-vehicle systems usually need to process a large amount of data, including vehicle configuration, user preferences, driving information, etc. Traditional storage solutions often have difficulty in efficiently managing and quickly accessing large amounts of data, leading to system performance bottlenecks.

[0006] Some in-vehicle systems rely on third-party storage solutions, which are usually expensive, complex to integrate, and expensive to maintain. This dependency not only increases the complexity of 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 persistence storage method, device and storage medium for a vehicle-mounted 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 a vehicle-mounted system is provided, comprising: using an upper-layer application in the vehicle-mounted 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; using the persistence service module, determining a target storage area based on the received key-value pair information, wherein the target storage area includes a plurality of 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 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.

[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 use an upper-layer application in the in-vehicle system to call a persistence service interface, and write vehicle configuration information in the form of a key-value pair 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 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 the 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 use an 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.

[0010] According to a third aspect of an embodiment of the present application, an electronic device is provided, including 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 an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and 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 using 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; using 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 are isolated and managed according to the identity or authority of the caller; when reading the vehicle configuration information, the upper-layer application is used 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 paying any creative work.

[0015] Figure 1 It 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;

[0016] Figure 2 It is a flowchart of a data persistence storage method for an in-vehicle system provided in an embodiment of the present application;

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

[0018] Figure 4 This is a data reading and writing timing diagram on the Android side provided in an embodiment of the present application;

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

[0020] Figure 6 It is a structural diagram 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 schematic diagram of the structure 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, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also 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 prevent unnecessary details from obstructing the description of the present application.

[0023] With the popularization of intelligent and networked vehicle systems, various complex systems and applications are integrated into vehicles, such as infotainment systems, navigation systems, driver assistance systems, etc. These systems use data extensively to provide functions, so persistent storage of data has become a key requirement.

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

[0025] 1. Data consistency issues: During vehicle driving, the vehicle system may be interrupted due to unforeseen circumstances such as power outages and system crashes. Such unexpected interruptions will affect ongoing persistent storage operations and cause inconsistency in stored data. Existing vehicle systems often do not have native persistent storage functions, and system manufacturers need to develop and customize them themselves to meet this demand.

[0026] 2. Data management issues: The vehicle system needs to process a large amount of data, including navigation information, vehicle operating status, user preference settings, etc. Traditional storage solutions may not be designed for these complex requirements, resulting in inefficient data reading, writing, and deleting operations when the system faces massive amounts of data, making it difficult to effectively manage data.

[0027] 3. Integration and maintenance issues: Although using third-party storage solutions can solve some data storage needs to a certain extent, these solutions usually require payment and the integration process is cumbersome. Subsequent system maintenance is also relatively complicated, increasing the cost of system development and operation.

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

[0029] Specifically, the present application relates to storage technology in vehicle-mounted systems, and in particular, to a persistent storage technology solution for vehicle-mounted systems. The vehicle-mounted system persistent storage technology solution provided by the present application significantly improves the data reliability, performance, and management efficiency of the vehicle-mounted system through a multi-level storage architecture, persistence mechanism, data isolation strategy, and intelligent data management technology. The solution has broad application prospects and provides an effective solution for the stability and reliability of vehicle-mounted systems.

[0030] The following is a summary of the core technical points involved in the persistent storage solution for the vehicle system 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 the need for APPs to care about information such as the location and method of vehicle data storage.

[0032] 2. This set of components is designed with three layers of data structure, covering the offline (factory) data, 4S shop (dealer) configuration data and end-user (user) data. It provides reading, writing, recovery, importing and exporting functions for these data to meet the needs of vehicle configuration data operation in the in-vehicle infotainment system.

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

[0034] 4. All vehicle-related data items need to be defined in advance, and no dynamic modification items are 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 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 Android's native data storage solution.

[0036] Based on the above-mentioned persistent storage solution, the present application also provides a persistent storage technology architecture of a hypervisor virtualized vehicle system. The content of the persistent storage technology architecture of a hypervisor virtualized vehicle system provided by the present application is described below in conjunction with the accompanying drawings. Figure 1 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 the present 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 architecture 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 the present application are described in detail below with reference to the accompanying drawings and specific embodiments.

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

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

[0042] S202, using 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 corresponding to the vehicle configuration information of different levels for storing;

[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, using a persistence service module, determining a target storage area according to received key-value pair information includes:

[0046] Using the persistence service module to receive the key-value pair information sent by the upper-layer 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;

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

[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 a plurality of physical storage areas in the vehicle-mounted system, wherein the physical storage area includes an Android-side storage area and a virtualized system storage area.

[0050] Specifically, the present application provides a persistent storage method for determining a target storage area in a vehicle system, which specifically processes a storage request for vehicle configuration information through a persistent service module. The method can automatically identify the category, priority, and scope of data based on the received key-value pair information, and accordingly determine the target partition and physical storage area where the data should be stored, so as to achieve efficient management and fast access to data.

[0051] In this embodiment, the upper layer application in the vehicle system (such as the infotainment system or the driver assistance system) sends a storage or read request to the persistence service module by calling the persistence service interface. The request includes the key-value pair data of the vehicle configuration information and the application identifier related to 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 the 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 is system configuration, user configuration, or third-party application data.

[0055] Data priority: Based on the application ID or process ID of the request, determine whether the data needs to be processed with high priority. For example, system configuration data usually has a higher priority, while personalized data set by the user may have a lower priority.

[0056] Data scope: Determine whether the data is shared between multiple systems or is only used in a specific system environment. The scope can involve 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 action 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 needs to be accessed quickly, 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 according to 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 user configuration partition of the Android end 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 the data writing process, the persistence service module will write the key-value pair data into the determined target storage area according to the predetermined format. During the reading operation, the persistence service module retrieves the data from the corresponding physical storage area by the key name in the key-value pair and returns the data to the upper-layer application that requested it.

[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 correctly restored.

[0070] Furthermore, for configuration data shared in multiple system environments, the persistence service module will ensure that the data in the Android system and the virtualized system are consistent through a data sharing mechanism. When a user changes a configuration item, the data will be automatically synchronized to other systems to ensure that the vehicle configuration in all systems remains consistent.

[0071] Through the method of the above-mentioned 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] Using the persistence service module to search the preset permission list according to the caller's application identifier, determine the caller's access rights, and determine whether the caller has the permission to access or operate the key-value pair information;

[0074] The target partition type is determined according to 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, which specifically describes how to parse key-value pair information through a persistence service module and determine the storage area of ​​the target data in combination with the caller's permissions. This method effectively ensures the isolated storage of different types of vehicle configuration data, ensuring the security of the system and the consistency of the data.

[0076] First, the upper-layer application in the vehicle system (such as navigation and infotainment systems) sends a storage request for key-value pair information 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 which application the request comes from, 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 category: 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 are generally given a lower priority, while data related to the core configuration of the system is given 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 for a preset permission list in the system according to 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 access or operation rights to the key-value pair information. The specific operations include:

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

[0086] Determine legitimacy: If the key-value pair information is in the caller's list of accessible data items, the caller is considered 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 the 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 Schematic diagram of data partition design in the vehicle-mounted system provided by the embodiment of the present application. Figure 3 As shown, the data partition and data partition description provided in the embodiment of the present application include the following contents:

[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 the user preference settings and has a lower priority, which only affects the personalized usage experience.

[0096] Furthermore, according to 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 end 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 the 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 strategies of different partitions;

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

[0105] Specifically, the embodiment of the present application also introduces how to use the persistence service module to write and read data after selecting the corresponding target storage area from the vehicle system according to the target partition type. This method ensures the correct storage and retrieval of vehicle configuration information, supports data synchronization or update, and improves the persistent storage capacity and data management efficiency of the vehicle system.

[0106] First, the persistence service module determines the target partition type (such as factory configuration partition, service provider configuration partition, or user configuration partition) based on the parsed key-value pair information. Then, the persistence service module selects a suitable 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, it 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 formats the key-value pairs according to the category, data priority and scope of the vehicle configuration information to ensure that 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 format.

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

[0114] The persistence service module writes the formatted key-value pair 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 between multiple systems (such as the Android system and the QNX virtualization system). To ensure data consistency between systems, the persistence service module will perform data synchronization or update according to the storage strategy of the specific partition after completing the write operation.

[0117] For example, the 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 the configuration when the user uses 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 be read is navigationMode, the persistence service module will first locate the user configuration partition on the Android side or other partitions that store the information.

[0123] 2) Get configuration information:

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

[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 make corresponding adjustments 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 for subsequent troubleshooting and system maintenance.

[0129] 5) Data security and integrity

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

[0131] Through the above method of this embodiment, the persistence service module provided by this embodiment realizes efficient storage and reading of vehicle configuration information through the above steps. This method not only supports cross-system data synchronization and update, but also can manage data securely according to different partition 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 the data in the high-speed access partition between the Android system and the virtualization system.

[0136] Specifically, a method for storing and sharing fast access data in an in-vehicle system is introduced, especially for vehicle configuration information that needs to be accessed frequently or in real time, high-speed access partitions are used for efficient storage, and data synchronization and two-way transmission between different systems are achieved through a cross-system data sharing plug-in. This embodiment describes in detail the specific steps of classifying, storing and sharing fast access data across systems.

[0137] In the vehicle system, some vehicle configuration information needs to be accessed frequently or in real time in specific scenarios. In order to improve the system response speed, the persistence service module classifies the received vehicle configuration information and identifies which data needs to be processed quickly.

[0138] The persistence service module divides vehicle configuration information into regular data and fast access data based on the application scenario and access frequency of the data. For example, the real-time status information of the vehicle (such as vehicle speed, engine status) and certain user interaction information (such as air conditioning adjustment, audio volume) may be classified as fast access data because these data 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] Furthermore, after identifying fast-access data, the persistence service module stores this data in independent high-speed access partitions. High-speed access partitions are designed for high-frequency access data, with lower read and write latency and higher performance, ensuring the fastest processing speed when the system needs real-time response.

[0141] The persistence service module writes fast access data directly to the high-speed access partition according to the data priority and classification results. The physical storage location of the partition can be located in the high-speed storage device of the vehicle system to optimize the data reading and writing speed.

[0142] For example, the engine status information of a vehicle (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. Two-way transmission and synchronization between different systems.

[0144] The data sharing plug-in establishes a communication channel between the Android system and the virtualization system (such as QNX), allowing the two operating systems to simultaneously access and modify data in the high-speed access partition. The plug-in is responsible for managing the data transmission and synchronization process between different systems, ensuring that each system can obtain the latest fast-access data in real time.

[0145] When an application in the Android system modifies the 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 the navigation application in the Android system modifies the real-time location data of the vehicle, 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 two-way data transfer between different systems, which means that changes made by any system to the data in the high-speed access partition can be obtained and updated by the other system in a timely manner.

[0148] When one system modifies the quick access data, the data sharing plug-in will synchronize the data changes to the other system through the 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, in order to ensure the integrity of the fast access data during the transmission and synchronization process, the data sharing plug-in is also equipped with the necessary verification mechanism to ensure that the data will not be lost or damaged during the cross-system transmission process. In addition, the plug-in can also protect the security of the data through encryption to prevent unauthorized systems or applications from accessing sensitive data in the high-speed access partition.

[0151] Through the method of the present embodiment described above, the vehicle system can effectively identify and process vehicle configuration information that needs to be accessed frequently or in real time, and use high-speed access partitions to achieve efficient data storage. At the same time, through cross-system data sharing plug-ins, data synchronization and two-way transmission between different systems are guaranteed. This method not only improves the response speed of the system, but also ensures the consistency and security of the data.

[0152] In some embodiments, data in the high-speed access partition is bidirectionally transferred and synchronized between the Android system and the virtualization system, including:

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

[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 implementing bidirectional transmission and synchronization of data in a high-speed access partition between an Android system and a virtualization system (such as a QNX system) through a persistent service module. The focus of this embodiment is how to achieve efficient acquisition and consistency maintenance of fast access data in a multi-operating system environment.

[0156] In the in-vehicle system, some key vehicle configuration information needs to be transmitted and synchronized bidirectionally between the Android system and the virtualization system, especially the data in the high-speed access partition, such as the real-time status of the vehicle, user interaction information, etc. These data usually need to be shared and maintained consistent in multiple operating system environments.

[0157] In order to realize such data sharing, this embodiment utilizes a persistent 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, an infotainment system in the Android system may request to obtain the current speed of the vehicle, and a driver assistance module in the virtualized system may request to obtain the engine status.

[0160] Furthermore, the persistence service module determines which system the request comes from through the data sharing plug-in and decides how to handle the request. The plug-in is responsible for establishing a communication bridge between the Android system and the virtualization system to ensure 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 according to the type of request. 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 obtains 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 the 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 virtualization system.

[0163] Furthermore, when the 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 real-time location data of the vehicle, 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 the updated data to another system. For example, when an application in the Android system updates the vehicle location, the data sharing plug-in will immediately synchronize the data to the virtualization system, ensuring that the QNX system can obtain the latest location information in real time.

[0168] 3) Two-way transmission mechanism:

[0169] In 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 some application scenarios, such as the vehicle air conditioning system settings, applications in the Android system may frequently read and update these configuration information. In order to keep these settings consistent in the virtualized system, the persistence service module will synchronize the updates in the Android system to the virtualized system through the data sharing plug-in, so that the QNX system can respond to user operations in real time.

[0173] Assuming that 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 method of this embodiment, this embodiment provides a method for realizing 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, and after the data is updated, it can be synchronized to another system in real time, ensuring data consistency and 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, continue to allow 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 implementing access control of vehicle configuration information by an application based on a persistent service module. By combining the application package name and process name, permissions are checked for different applications and system services to ensure data isolation and prevent unauthorized data access. This embodiment describes in detail how to perform permission verification and data access management through a persistent 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. The key value list contains the key names of the vehicle configuration information that the application is authorized to access.

[0182] Furthermore, after receiving the request, the persistence service module extracts the application package name contained in the request. For example, the package name of the infotainment system application may be com.car.entertainment. The persistence service module queries the permission configuration table through the package name to obtain the key value list that the application is allowed to access.

[0183] Furthermore, the key value list includes vehicle configuration information that the application is allowed to operate. For example, the infotainment system may be authorized to access vehicle setting items 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 list of accessible key values ​​of the application. For example, if the caller requests to operate the audioVolume key, the persistence service module will check whether the key name is in the permission list of the infotainment system.

[0187] 2) Reject unauthorized requests:

[0188] If the key name passed by the caller is not within its permission range, the persistence service module will reject the data access request and throw an exception to prevent unauthorized operations. For example, if the infotainment system attempts to access engineStatus (sensitive data related to driving), the persistence service module will reject 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 accessible key list, the persistence service module will allow continued 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 is allowed.

[0191] Furthermore, for system-level service requests, the permission verification method is slightly different. System services distinguish permissions by process name, and different processes have different permission ranges. The persistence service module searches for the corresponding permission configuration based on the requested process name to determine whether the system service has the permission to operate the 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 the request for system services to ensure that the system process can only access data within its scope of authority. For example, the driving control module can access engineStatus, but cannot access user personalized 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] The caller who has passed the permission check can initiate a data read and write request to the persistent storage layer. The persistent service module passes data from the application layer to the persistent storage layer through the abstract interface of the vehicle system, or obtains data from the storage layer and returns it to the caller. For example, if the volume setting of the infotainment system is modified, the persistent service module writes the modification to the storage layer and updates the vehicle's audio configuration.

[0197] The following uses Android 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 is a data reading and writing timing diagram on the Android side provided in an embodiment of the present application, Figure 5 This is a PersService data read and write timing diagram provided by the embodiment of the present application. Figures 4 to 5 As shown, the data read and write operations provided in the embodiment of the present application may include the following contents:

[0198] In this embodiment, the specific implementation process of data reading and writing based on the Android side and the persistent service (PersService) data reading and writing is described in detail. Figure 4 and Figure 5 , the following will describe in detail how to complete the data read and write operations in the vehicle system. This embodiment describes a series of steps such as data initiation request 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 The application initiates a 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 returns the default value.

[0203] 1.2 Persistence Service module 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 by the package name of the application. First, PersistenceService calls the PersGetAuthority(AppName) method to check whether the calling application has the permission to access the key value. The persistence service module verifies 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 passed, 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), the getPluginAvailableKeyList interface is used to communicate with the QNX plug-in to read the vehicle configuration information in the virtualization system.

[0209] 1.5 Return results:

[0210] When 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, when the key value requested to be read is audioVolume, the system returns the current volume setting information to the application.

[0211] 2.PersService data read and write operations

[0212] Figure 5 The data reading and writing 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 persistence service module (PersistenceService) calls PersService to perform data reading operations. PersService obtains a persistence service client (PersClient) instance through the internal getClient(AppName) method, which is responsible for processing the application's data reading operations.

[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. PersManager traverses all PersProviders to find 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 check 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 PersistenceService. After successfully obtaining the vehicle configuration information, the persistence service module passes the data to PersistenceService through PersClient. At this time, the persistence service module returns the retrieved data value to the upper-level 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] The upper-layer application initiates a request through the persistence service module, and the system determines whether to allow data access based on permission verification. The persistence service module calls PersService to obtain the corresponding vehicle configuration information and supports obtaining data from the Android system or virtualization system. Through the management of the data provider, effective isolation and reading of data are achieved to ensure data security and consistency.

[0222] Through the operation of the above-mentioned embodiments, the vehicle system can efficiently and safely manage and access various types of vehicle configuration information, and ensure 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 implements inter-process communication between different applications and system services through AIDL (Android Interface Definition Language). After passing the permission check, 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 accessing data from other services will throw an exception. For example, the infotainment system cannot operate the data of the driving control module, and vice versa. The persistence service module strictly implements data isolation to ensure data security between different applications and services.

[0227] In addition, the persistence service module supports dynamic permission configuration. In certain cases, system administrators or manufacturers can dynamically adjust the access rights of applications or system services by updating the permission configuration table. For example, after a system upgrade or security policy adjustment, you can temporarily increase the access rights of an application or limit 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 successfully in getInt in the above AIDL interface information means, for example, storing the current system night and day mode as daytime. Assuming that UIMode=1 is stored in the database, 1 is the actual value (UIMode-=1 is daytime mode, UImode=0 is nighttime mode). The role of the input parameter value returned in failure is to store the value required by the business scenario and ensure persistence. The stored value remains unchanged in upgrades and factory resets.

[0232] According to the method of the present embodiment described above, the present embodiment implements strict management of data access rights for applications and system services through a persistent service module. By querying the preset permission configuration table and verifying the key value information, the persistent service module ensures that each caller can only operate the vehicle configuration information within its authority, effectively preventing unauthorized access to data, and implements 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 work between different applications and services.

[0233] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

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

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

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

[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, identifies the category of the target data, the priority of the data and the scope of the data, and then uses the persistence service module to search the preset permission list according to the application identifier of the caller to determine the caller's access rights to determine whether the caller has the authority to access or operate the key-value pair information; determines the target partition type based on the parsed key-value pair information and the caller's access rights, 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, the persistence service module is used to store the parsed key-value pair information in the target storage area in a preset format, and the data is synchronized or updated according to the storage strategies of different partitions; for read operations, the persistence service module is used to retrieve the target storage area according to the data items in the parsed key-value pair information, and return the corresponding vehicle configuration information.

[0242] In some embodiments, Figure 6 The sharing module 606 classifies the received vehicle configuration information, identifies data items that need to be accessed frequently or in real time in specific scenarios, and uses them 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 quick 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 persistent 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, continued access is allowed; 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 searched; 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 the present 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 in 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] Exemplarily, 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 complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which 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 appreciate 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 the processor may be any conventional processor, etc.

[0250] The memory 702 may be an internal storage unit of the electronic device 7, for example, a hard disk or memory of the electronic device 7. The memory 702 may also be an external storage device of the electronic device 7, for example, 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. Further, the memory 702 may also 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 may also be used to temporarily store data that has been output or is to be output.

[0251] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be 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 in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in 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, which will not be repeated here.

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

[0253] Those of ordinary skill 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 to be beyond the scope of this application.

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

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

[0256] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of 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. Computer-readable media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, 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 embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A data persistent storage method for a vehicle-mounted system, characterized in that: include: Using an upper layer application in the vehicle system to call a persistent service interface, the vehicle configuration information is written into a persistent storage area in the form of a key-value pair, wherein the persistent service interface communicates with a persistent service module through an abstract interface definition language; Determine a target storage area according to the received key-value pair information by using the persistence service module, wherein the target storage area includes a plurality of partitions corresponding to the vehicle configuration information of different levels for storing; 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, the upper-layer application is used 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.

2. The method according to claim 1, characterized in that The 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; According to the target partition type, a corresponding target storage area is selected from a plurality of physical storage areas in the vehicle-mounted system, wherein the physical storage area includes an Android-side storage area and a virtualized system storage area.

3. The method according to claim 2, 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 application identifier of the caller, determine the access rights of the caller, 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.

4. 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-mounted 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 data is synchronized or updated according to the storage strategies of different partitions; For the 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.

5. The method according to claim 1, characterized in that 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.

6. The method according to claim 5, 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.

7. The method according to claim 1, characterized in that The method further comprises: Using the persistence service module to query a preset permission configuration table according to the application package name of the caller, and 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 according to 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.

8. A data persistent storage device for an in-vehicle system, characterized in that: include: A calling module is configured to use an upper layer application in the vehicle system to call a persistent service interface to write the vehicle configuration information into a persistent storage area in the form of a key-value pair, wherein the persistent service interface communicates with the persistent service module through an abstract interface definition language; A determination module is configured to determine 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 for storing; 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; The reading module 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.

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

10. 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 7 are implemented.

Images