A data processing method, electronic device and vehicle

Abstract

The application provides a data processing method, an electronic device and a vehicle, and relates to the technical field of processing. The data processing method is applied to an electronic device comprising a master chip, at least one module chip and a nonvolatile memory; a first process runs on the module chip; a second process and a database engine run on the master chip; and the nonvolatile memory is electrically connected with the master chip. In a data storage process, the first process on the module chip initiates a storage request to the second process on the master chip, the second process calls the database engine to write data into the nonvolatile memory electrically connected with the master chip, and the persistent storage of the data of the module chip is realized. The application reuses the storage resources of the master chip, reduces the hardware cost and system complexity, and uses the characteristics of the database engine to guarantee the consistency and safety of the data, and solves the pain points of waste of storage resources and insufficient data reliability in the prior art.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, electronic device, and vehicle. Background Technology

[0002] With the rapid development of intelligent cockpit systems, in-vehicle integrated units that integrate multiple functional modules with cockpit domain controllers are gradually becoming the mainstream solution in the field of intelligent cockpits.

[0003] In current all-in-one solutions, the main control chip is responsible for core computing and control in the cockpit domain, while the module chips are responsible for dedicated functions such as communication and positioning. During operation, the module chips generate critical data such as logs, configuration parameters, and event records. This data needs to be persistently stored so that it can be recovered after system power failure or used for fault analysis.

[0004] Therefore, how to achieve low-cost, high-reliability persistent storage of data generated by module chips has become one of the urgent technical problems to be solved in the field of in-vehicle integrated machines. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a data processing method that enables low-cost, high-reliability persistent storage of data generated by module chips.

[0006] The embodiments of this application disclose the following technical solutions: This application provides a data processing method applied to an electronic device, the electronic device including a main control chip, at least one module chip, and a non-volatile memory; a first process runs on the module chip; a second process and a database engine run on the main control chip; the non-volatile memory is electrically connected to the main control chip; the method includes: The first process initiates a storage request to the second process; the storage request carries the first data. After receiving the storage request, the second process calls the database engine to write the first data into the non-volatile memory and sends the write result corresponding to the storage request to the first process.

[0007] In one optional implementation, the data interaction between the main control chip and the module chip includes: software layer interaction based on Socket communication, and hardware layer interaction based on serial bus or shared memory.

[0008] In one alternative implementation, the database engine is an SQLite database engine; the module chip includes a T-BOX module chip.

[0009] In one optional implementation, the electronic device includes multiple module chips; the second process allocates an independent service thread to each of the first processes; the database engine supports multi-threaded access control and transaction isolation mechanisms; the method further includes: Multiple first processes initiate multiple storage requests to the second process; After receiving multiple storage requests, the second process uses multiple service threads, which correspond one-to-one with the multiple first processes, to control the multiple service threads to independently and concurrently call the database engine, so as to write the first data in each storage request into the non-volatile memory.

[0010] In one optional implementation, the data transmitted between the main control chip and the module chip is stored in the non-volatile memory.

[0011] In one alternative implementation, a first operating system runs on the module chip, and a second operating system runs on the main control chip.

[0012] In one alternative implementation, it also includes: The first process initiates a query request to the second process; the query request is used to query second data. After receiving the query request, the second process calls the database engine to query the second data from the non-volatile memory and sends the query result corresponding to the query request to the first process.

[0013] In one alternative implementation, it also includes: The first process initiates a deletion request to the second process; the deletion request is used to delete third data. After receiving the deletion request, the second process calls the database engine to delete the third data from the non-volatile memory and sends the deletion result corresponding to the deletion request to the first process.

[0014] A second aspect of this application provides an electronic device, the electronic device comprising a main control chip, at least one module chip, and a non-volatile memory; a first process runs on the module chip; a second process and a database engine run on the main control chip; and the non-volatile memory is electrically connected to the main control chip. The first process is configured to send a storage request to the second process; receive a write result returned by the second process corresponding to the storage request; the storage request carries first data; The second process is used to listen for and receive the storage request; call the database engine to write the first data into the non-volatile memory; and return the write result to the first process.

[0015] A third aspect of this application provides a vehicle that includes the electronic equipment described in the second aspect.

[0016] Compared with the prior art, this application has the following beneficial effects: The data processing method provided in this application is applied to an electronic device, which includes a main control chip, at least one module chip, and a non-volatile memory. A first process runs on the module chip; a second process and a database engine run on the main control chip; and the non-volatile memory is electrically connected to the main control chip. During data storage, the first process on the module chip initiates a storage request to the second process on the main control chip. The second process then calls the database engine to write the data to the non-volatile memory electrically connected to the main control chip, thereby achieving persistent and centralized storage of module chip data on the main control chip side. This application reduces hardware costs and system complexity by reusing the storage resources of the main control chip; and it utilizes the characteristics of the database engine to ensure data consistency and security, solving the pain points of wasted storage resources and insufficient data reliability. Therefore, the data processing scheme of this application can perform low-cost, high-reliability persistent storage of data generated by the module chip. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 2 A flowchart illustrating a data storage method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of another electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating information interaction between a main control chip and a module chip, provided as an embodiment of this application. Detailed Implementation

[0019] As mentioned earlier, the key data generated by the module chip during operation, such as logs, configuration parameters, and event records, need to be persistently stored to meet the requirements of power failure recovery and fault analysis.

[0020] Related technologies typically achieve this functionality by using external independent storage devices. External independent storage devices refer to configuring a dedicated physical storage chip, such as eMMC or NAND Flash, outside the module chip to store data. However, this approach has significant drawbacks: First, it introduces additional material costs and PCB layout area, hindering the miniaturization and integration of automotive terminals; second, the data storage requirements of module chips are usually small, while the standard capacity of independent storage is often far greater than actual needs, leading to severe storage resource redundancy; third, the discreteness of data physical distribution increases the complexity of system data management, making it difficult to implement global data backup and security strategies; finally, if the external storage device of the module chip uses consumer-grade, low-specification NAND Flash, it often suffers from insufficient read / write endurance and a lack of effective power-loss protection mechanisms, increasing the risk of data loss.

[0021] Therefore, how to achieve low-cost, high-reliability persistent storage of data generated by module chips has become one of the urgent technical problems to be solved in the field of in-vehicle integrated machines.

[0022] Based on this, this application provides a data processing method applied to an electronic device including a main control chip, at least one module chip, and non-volatile memory. The module chip runs a first process; the main control chip runs a second process and a database engine; and the non-volatile memory is electrically connected to the main control chip. In use, the first process on the module chip initiates a storage request to the second process on the main control chip, which then calls the database engine to write data to the non-volatile memory electrically connected to the main control chip, thereby achieving persistent storage of the module chip data.

[0023] This solution eliminates the need for independent configuration of storage devices and peripheral circuits for each module chip, effectively reducing hardware costs and PCB footprint. By relying on the database engine on the main control chip side for unified data management, and leveraging the inherent transaction mechanism and crash recovery capabilities of the database engine, the consistency and reliability of data storage are significantly improved. Furthermore, by reusing the high-performance storage resources of the main control chip, idle storage capacity is avoided, achieving intensive utilization of storage resources. Therefore, the data processing solution of this application can provide low-cost, high-reliability persistent storage for data generated by the module chips.

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0025] The data processing method in this application is implemented based on the main control chip, module chip, and non-volatile memory in an electronic device. To facilitate understanding of the data processing method in this application, the structure of the electronic device will be described first.

[0026] Figure 1 This is a schematic diagram of an electronic device provided as an embodiment of this application. (In conjunction with...) Figure 1 The electronic device 100 described in this application includes: at least one module chip 101, a main control chip 102, and a non-volatile memory 103. A first process runs on the module chip 101; a second process and a database engine run on the main control chip 102; the non-volatile memory 103 is electrically connected to the main control chip 102 and is uniformly managed and accessed by the main control chip 102.

[0027] At the communication layer, the main control chip 102 and the module chip 101 exchange data via Socket communication. Specifically: the first process acts as a Socket client, actively initiating a Socket connection request to the second process when data processing is required; the second process acts as a Socket server, creating a Socket listening port during the initialization phase and continuously listening for connection requests from the first process on the module chip 101. Once the connection is established, the first process can send storage requests to the second process through this Socket connection. After completing the corresponding database operations, the second process returns the operation results to the first process through the same Socket connection, thus achieving reliable bidirectional communication between the two.

[0028] Understandably, because the Socket communication interface is highly standardized, it can be decoupled from the underlying physical link, so that the communication interface between the first process and the second process remains consistent, which facilitates the maintenance and upgrading of electronic devices.

[0029] At the physical level, the main control chip 102 and the module chip 101 exchange data via a serial bus or shared memory. Serial buses include, but are not limited to, SPI (Serial Peripheral Interface), UART (Universal Asynchronous Receiver / Transmitter), USB (Universal Serial Bus), and high-speed serial switch buses. Different types of serial buses have their own advantages and disadvantages in terms of transmission rate, communication distance, and hardware complexity; this application does not limit the type of serial bus.

[0030] In one alternative implementation, the database engine running on the main control chip 102 can be a MySQL database engine, a PostgreSQL database engine, or an SQLite database engine. Different database engines have different characteristics in terms of performance, resource consumption, and deployment complexity. Considering the resource constraints of the vehicle-mounted embedded system, SQLite, due to its lightweight nature, lack of a separate service process, and support for complete SQL syntax and transaction operations, is particularly suitable for the application scenario described in this application.

[0031] In one optional implementation, module chip 101 includes multiple module chips such as a communication module chip, a positioning module chip, or a T-BOX module chip. The communication module chip typically handles cellular network (e.g., 4G / 5G) communication, generating data such as network connection logs and signal status records during operation. The positioning module chip handles global navigation satellite system positioning, generating data such as location trajectory and positioning accuracy. The T-BOX module chip is a core module in intelligent connected vehicles that integrates communication and positioning functions, generating various types of data such as communication logs, location records, status events, and remote control command records. All of the above-mentioned module chips require persistent data storage and can be used as the applicable objects for the solution in this application.

[0032] This application does not limit the specific model of the main control chip 102. The main control chip 102 can be a cockpit domain controller chip, such as the Qualcomm Snapdragon 8155, 8295, etc., which are automotive-grade SoC chips with powerful computing power and complete storage interfaces. It can also be other SoC chips with certain computing power and storage interfaces.

[0033] This application does not limit the specific type of non-volatile memory 103. It can be general-purpose flash memory (UFS), embedded multimedia card (eMMC), or other types of non-volatile storage media such as NOR Flash and NAND Flash, as long as it can be electrically connected to the main control chip 102 and support persistent read and write operations. In actual in-vehicle integrated products, main control chips such as Qualcomm 8155 are usually equipped with large-capacity UFS or eMMC as main memory, with ample storage space, which can fully meet the persistent data storage needs of multiple module chips.

[0034] In this application, a first operating system runs on the module chip 101, and a second operating system runs on the main control chip 102. The first operating system can be a lightweight Linux system, which has low resource consumption and good real-time performance, making it suitable for running on module chips with limited computing and storage resources. The second operating system can be an Android system, which has a rich ecosystem and is easy to develop, making it suitable for complex cockpit-domain application scenarios running on the main control chip. Of course, the same type of operating system can also run on the module chip 101 and the main control chip 102, such as both running Linux systems; this application does not limit this.

[0035] In one alternative implementation, at least one module chip in the electronic device 100 may include multiple modules. For example, it may simultaneously include a communication module chip, a positioning module chip, and a T-BOX module chip. Each module chip runs a corresponding first process, and each first process can initiate a storage request to a second process on the main control chip 102 via Socket communication. After receiving storage requests from different module chips, the second process sequentially or concurrently calls the database engine to write the corresponding first data into the non-volatile memory 103, and returns the write result corresponding to its storage request to each first process.

[0036] In the scenario of concurrent access of multiple module chips, the second process on the main control chip 102 side can maintain an independent service thread for each module chip's corresponding first process. Each service thread concurrently processes storage requests from different first processes, ensuring that the data storage of multiple module chips does not interfere with each other, and preventing the storage request of one module chip from blocking the normal storage process of other module chips. The database engine (such as SQLite) itself supports multi-threaded access control and transaction isolation mechanisms, ensuring data consistency during concurrent writes and preventing data races and write conflicts.

[0037] In other words, when an electronic device includes multiple module chips, the second process allocates an independent service thread to each of the first processes; the database engine supports multi-threaded access control and transaction isolation mechanisms. When multiple first processes initiate multiple storage requests to the second process, and the second process receives multiple storage requests, this application uses multiple service threads, each corresponding to one of the multiple first processes, to control the multiple service threads to independently and concurrently call the database engine using multi-threaded access control and transaction isolation mechanisms, so as to write the first data in each storage request into non-volatile memory.

[0038] When a new module chip needs to be added, the main control chip 102 only needs to add the corresponding data table in the database engine and create a corresponding service thread for the newly added first process. There is no need to change the underlying storage architecture of the non-volatile memory 103, nor to modify the storage logic of the existing module chip. The first process of the newly added module chip establishes a connection with the second process according to the unified Socket communication interface specification, thus reusing the entire data storage mechanism (and the data query and data deletion mechanisms in subsequent embodiments of this application can also be reused). The entire access process has extremely low invasiveness to the existing system and possesses good horizontal scalability and engineering adaptability.

[0039] It should be noted that the data transmitted between the main control chip 102 and the module chip 101 in this application is referred to as cross-domain data; all cross-domain data is stored in non-volatile memory 103, which facilitates centralized encryption, backup, log auditing and remote management of the data.

[0040] Figure 2 This is a flowchart illustrating a data storage method provided in an embodiment of this application. The following is an example... Figure 1 Taking the electronic device 100 shown as an example, combined with Figure 2 The process of the data storage method provided in this application will be described in detail.

[0041] See Figure 2 The data storage method provided in this application includes: S201, the first process initiates a storage request to the second process.

[0042] Specifically, the first data refers to data generated by the module chip during operation that needs to be persistently stored, including but not limited to log information, configuration parameters, and status event records. The first process sends a storage request carrying the first data to the second process on the main control chip through an established Socket connection.

[0043] S202, after receiving the storage request, the second process calls the database engine to write the first data into the non-volatile memory and sends the write result corresponding to the storage request to the first process.

[0044] After receiving the storage request, the second process parses the request and extracts the first data and related metadata information (such as data type identifier, source module identifier, timestamp, etc.).

[0045] Subsequently, the second process calls a database engine (such as SQLite) to perform a data write operation, persistently storing the first data in a non-volatile memory 103 electrically connected to the main control chip 102.

[0046] When performing write operations, the database engine performs transaction management on the write process to ensure the atomicity of data writing. That is, a write operation either succeeds completely or is completely rolled back, and there will be no abnormal situation where part of the data is written, thereby ensuring the reliability and consistency of data storage.

[0047] After the write operation is complete, the second process returns the write result corresponding to this storage request to the first process. The write result indicates whether the storage operation was successful, and typically includes an operation status code (success / failure) and necessary error information (such as insufficient storage space, incorrect data format, etc.). After receiving the write result, the first process can perform subsequent processing based on the result status: if the write is successful, it continues the normal business process; if the write fails, it can retry or report the error according to a preset strategy, further ensuring the reliability of data storage.

[0048] In one alternative implementation, Figure 2 The methods also include query operations, including: The first process initiates a query request to the second process, which retrieves second data. Upon receiving the query request, the second process invokes the database engine to retrieve the second data from non-volatile memory and sends the query result corresponding to the query request back to the first process. Through this operation, the module chip can read historical stored data from the main control chip as needed for state recovery or data verification.

[0049] Specifically: When the first process needs to read historical data from the non-volatile memory 103, it sends a query request to the second process. The query request carries query conditions (such as data type, time range, data identifier, etc.) to query the second data. After receiving the query request, the second process parses the query conditions, calls the database engine to perform the corresponding query operation from the non-volatile memory 103, obtains the second data that meets the conditions, and sends the query result corresponding to the query request to the first process. The query result contains the queried second data or the error message of the query failure.

[0050] Through this operation, module chip 101 can read historical stored data from the main control chip 102 as needed for business scenarios such as status recovery, data verification, and breakpoint resume.

[0051] In one alternative implementation, Figure 2 The methods also include deletion operations, including: The first process sends a deletion request to the second process, which is used to delete the third data. After receiving the deletion request, the second process calls the database engine to delete the third data from the non-volatile memory and sends the deletion result corresponding to the deletion request back to the first process.

[0052] Specifically, when the first process needs to clear historical data in the non-volatile memory 103, it sends a deletion request to the second process. The deletion request carries deletion conditions (such as data identifier, time range, etc.) to delete the third data. After receiving the deletion request, the second process parses the deletion conditions, calls the database engine to perform the corresponding deletion operation from the non-volatile memory 103, and sends the deletion result corresponding to the deletion request to the first process. The deletion result is used to indicate whether the deletion operation was successful.

[0053] Through this operation, module chip 101 can clean up historical data that is no longer needed, avoid the invalid occupation of storage resources due to data accumulation, and effectively improve the utilization efficiency of storage space.

[0054] By organically combining the above-mentioned storage, query, and deletion operations, the data processing method provided in this application can meet the complete data persistence management requirements of the module chip 101 during actual operation, and construct a complete and unified cross-chip data management mechanism.

[0055] Since the T-BOX is a core functional module responsible for remote communication and positioning in intelligent connected vehicles, it continuously generates communication logs, location records, status events, and other data that require persistent storage during operation, making it one of the typical application scenarios for the solution in this application. Therefore, this application provides... Figure 3 The diagram shows the structure of another electronic device.

[0056] like Figure 3 As shown, in the electronic device 300, the module chip is a T-BOX module chip, and the main control chip is a Qualcomm 8155 chip (hereinafter referred to as 8155 chip). The two are integrated on the vehicle-mounted all-in-one hardware platform and interact with each other through Socket communication. The physical link is implemented using serial buses such as SPI, UART or USB.

[0057] The T-BOX module chip runs a lightweight Linux system, with the primary process being the Storage Client running on the Linux system. As a data storage agent on the T-BOX side, the Storage Client is responsible for collecting various types of data that need to be persistently stored during the operation of the T-BOX business process (APP, i.e., the T-BOX application), including communication status logs, remote control command execution records, and system status events. After collecting the above data, the Storage Client encapsulates it and sends it to the Storage Server on the 8155 main control chip side via a Socket connection in the form of a storage request.

[0058] The 8155 main control chip runs the Android system, and the second process is the StorageServer (storage service client) running on the Android system. As the data storage service on the 8155 side, the StorageServer initializes a Socket listening service after system startup, continuously listening for connection requests and data operation requests from the T-BOX's Storage Client. Upon receiving a storage request from the Storage Client, the StorageServer parses the request content, calls the SQLite database engine to perform data write operations, and persistently stores the data generated by the T-BOX in non-volatile memory electrically connected to the 8155 chip. This non-volatile memory is typically a high-capacity UFS (Universal Flash Memory) or eMMC (eMMC), and is the main memory of the 8155 chip, offering ample storage space and excellent read / write performance to meet the high-frequency data writing requirements of the T-BOX.

[0059] At the software architecture level, Storage Client and Storage Server communicate through a unified data operation interface protocol. This protocol defines the request and response formats for various operations such as storage requests, query requests, and deletion requests. This allows Storage Client to be free from concern itself with the underlying implementation details of the database and simply construct requests and parse responses according to the protocol format, thereby reducing the development complexity of the module chip-side software.

[0060] At the data management level, the SQLite database engine provides structured management for various types of data generated by T-BOX, supporting multi-dimensional retrieval and querying based on data type, time range, event type, and other dimensions, facilitating subsequent data analysis, fault diagnosis, and remote operation and maintenance. Meanwhile, SQLite's transaction management mechanism ensures the atomicity and consistency of data writes. Even in the event of a system power outage, mechanisms such as write-ahead logs maximize the integrity of committed data, preventing data loss or corruption.

[0061] Compared to the traditional approach of configuring eMMC or NAND Flash memory devices separately for the T-BOX module chip, Figure 3 The solution shown reuses the existing large-capacity non-volatile memory resources of the 8155 chip, eliminating the need for independent memory devices and peripheral circuits on the T-BOX side. This reduces hardware material costs and PCB wiring complexity, which is conducive to the miniaturization and high-density integration of the vehicle-mounted integrated hardware platform.

[0062] Figure 4 This is a schematic diagram illustrating information interaction between a main control chip and a module chip, as provided in an embodiment of this application. To further understand the technical solutions in this application, in conjunction with... Figure 3 and Figure 4 The explanation focuses solely on the information exchange process between the main control chip and the module chip.

[0063] like Figure 4 As shown, the entire interaction process is divided into a connection establishment phase, a data storage phase, and an optional query / delete phase, as detailed below: During the connection establishment phase, the first process (Socket client) proactively initiates a connection request to the Socket port being listened to by the second process. Upon receiving the connection request, the second process establishes a Socket connection and returns a successful connection response to the first process, marking the formal establishment of the communication link. This connection establishment process is typically completed during system initialization or before the first data storage operation. Once established, the connection will be maintained continuously, eliminating the need to re-establish it before each operation, thus reducing communication latency and system overhead.

[0064] During the data storage phase, the first process sends a storage request carrying the first data to the second process via an established Socket connection. The storage request includes the first data to be persistently stored, along with necessary metadata information (such as data type identifier, source identifier, priority, etc.). Upon receiving the storage request, the second process parses and verifies it, then calls the database engine (such as SQLite) on the main control chip side to perform a data write operation, persistently writing the first data to non-volatile memory electrically connected to the main control chip. The database engine employs a transaction mechanism during the write process to ensure the atomicity and consistency of the write operation. After the write is complete, the second process sends the write result to the first process via the Socket connection. The write result indicates whether the storage operation was successful, and the first process uses this to confirm the execution status of the storage operation.

[0065] Beyond storage operations, the first process can also initiate query or delete requests to the second process via the same Socket connection, based on business needs. For query requests, the second process similarly invokes the database engine to perform data retrieval operations in non-volatile memory according to the query conditions carried in the query request. After retrieving historical data that meets the conditions, it returns the query results to the first process via the Socket connection. For delete requests, the second process invokes the database engine to perform data deletion operations according to the deletion conditions carried in the delete request, and returns the deletion results to the first process after the operation is completed.

[0066] Figure 4 The entire interaction process is based on the Socket communication mechanism, enabling reliable bidirectional transmission of storage, query, and deletion commands and their corresponding responses between the first and second processes. The Socket communication mechanism itself possesses data integrity protection capabilities, ensuring that every request and response message is transmitted completely and orderly to the other end, preventing data loss or out-of-order delivery, thus guaranteeing the integrity and traceability of data storage, query, and deletion operations.

[0067] It should be noted that, Figure 4 The example illustrates this by executing storage, query, and deletion operations sequentially. In practical applications, the first process can initiate storage, query, or deletion requests at any time according to business needs. These requests are independent of each other, and the second process can respond promptly and return the corresponding results, demonstrating high real-time performance and response efficiency.

[0068] In summary, the data processing method and system provided in this application have at least the following advantages compared to the prior art: First, it reduces hardware costs and system complexity. By reusing the existing non-volatile storage space of the main control chip (such as the Qualcomm 8155 chip), the need for each module chip to independently configure eMMC, NAND Flash and other memory devices and their peripheral circuits is eliminated, which effectively reduces the overall material cost and PCB layout complexity, and is conducive to the miniaturization and high-density integration of the vehicle-mounted integrated machine.

[0069] Second, it improves the efficiency of storage resource utilization. By making full use of the large-capacity, high-performance storage resources built into the main control chip, it avoids the resource idleness problem caused by configuring a large-capacity memory for a single module chip, and realizes the sharing and intensive utilization of storage resources.

[0070] Third, it enhances the uniformity and security of data management. Cross-domain data is centrally stored on the main control chip, which facilitates the unified implementation of data encryption, integrity verification, log auditing, and remote operation and maintenance policies, significantly improving the controllability and security protection capabilities of data management.

[0071] Fourth, ensuring data reliability and real-time performance. Reliable data transmission between the module chip and the main control chip is achieved based on the Socket communication mechanism. Combined with the transaction processing and crash recovery mechanisms of a database engine (such as SQLite), data integrity and consistency can be guaranteed to the greatest extent even in the event of abnormal power failure. Simultaneously, relying on high-speed inter-chip communication links, millisecond-level data storage can be achieved, meeting the real-time requirements of automotive scenarios.

[0072] Fifth, it has excellent scalability. It supports concurrent access of multiple module chips. The main control chip only needs to add data tables or service threads to support newly connected devices without changing the underlying storage architecture, thus possessing good horizontal scalability and engineering adaptability.

[0073] Based on the data processing method and electronic device provided in the foregoing embodiments, this application also provides a vehicle, including the electronic device provided in the foregoing embodiments.

[0074] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method, characterized in that, Applied to electronic devices, the electronic devices include a main control chip, at least one module chip, and non-volatile memory; The first process runs on the module chip; The main control chip runs a second process and a database engine; The non-volatile memory is electrically connected to the main control chip; the method includes: The first process initiates a storage request to the second process; the storage request carries the first data. After receiving the storage request, the second process calls the database engine to write the first data into the non-volatile memory and sends the write result corresponding to the storage request to the first process.

2. The method according to claim 1, characterized in that, The data interaction between the main control chip and the module chip includes: software layer interaction based on Socket communication, and hardware layer interaction based on serial bus or shared memory.

3. The method according to claim 1, characterized in that, The database engine is the SQLite database engine; the module chip includes the T-BOX module chip.

4. The method according to claim 1, characterized in that, The electronic device includes multiple module chips; the second process allocates an independent service thread to each of the first processes; the database engine supports multi-threaded access control and transaction isolation mechanisms; the method further includes: Multiple first processes initiate multiple storage requests to the second process; After receiving multiple storage requests, the second process uses multiple service threads, which correspond one-to-one with the multiple first processes, to control the multiple service threads to independently and concurrently call the database engine, so as to write the first data in each storage request into the non-volatile memory.

5. The method according to claim 4, characterized in that, The data transmitted between the main control chip and the module chip is stored in the non-volatile memory.

6. The method according to claim 1, characterized in that, The module chip runs a first operating system, and the main control chip runs a second operating system.

7. The method according to any one of claims 1-6, characterized in that, Also includes: The first process sends a query request to the second process; The query request is used to query the second data; After receiving the query request, the second process calls the database engine to query the second data from the non-volatile memory and sends the query result corresponding to the query request to the first process.

8. The method according to any one of claims 1-6, characterized in that, Also includes: The first process initiates a deletion request to the second process; the deletion request is used to delete third data. After receiving the deletion request, the second process calls the database engine to delete the third data from the non-volatile memory and sends the deletion result corresponding to the deletion request to the first process.

9. An electronic device, characterized in that, The electronic device includes a main control chip, at least one module chip, and a non-volatile memory; a first process runs on the module chip; a second process and a database engine run on the main control chip; and the non-volatile memory is electrically connected to the main control chip. The first process is used to send a storage request to the second process; Receive the write result returned by the second process corresponding to the storage request; The storage request carries the first data; The second process is used to listen for and receive the storage request; The database engine is invoked to write the first data into the non-volatile memory; The write result is returned to the first process.

10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 9.

Images