Vehicle-mounted data collection and uploading method, system, electronic device and storage medium

Abstract

The application relates to the field of data processing, and provides a vehicle-mounted data collection and uploading method and system, an electronic device and a storage medium. The method is applied to a first tracking application, the first tracking application is encapsulated with a data receiving class, a data processing class, a data management class and a data uploading class; the first tracking application is portably installed in a first virtual machine, and the first virtual machine is deployed in a first operating system; the method comprises the following steps: calling the data receiving class, acquiring vehicle-mounted data collected by a second tracking application through a first data transmission channel, and writing the vehicle-mounted data into a buffer data queue; calling the data processing class and the data management class, reading the vehicle-mounted data from the buffer data queue and processing the vehicle-mounted data to obtain a to-be-transmitted file; and calling the data uploading class, uploading the to-be-transmitted file to a data demand end through a data uploading channel. The application has high data utilization, good real-time performance of data collection and uploading, can improve system performance, and supports user-initiated customized modification of an architecture process based on business requirements.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method, system, electronic device and storage medium for collecting and uploading vehicle-mounted data. Background Art

[0002] With the continuous development of information and intelligent technologies, the functions of vehicle-mounted systems are becoming more and more abundant and complex, and the amount of vehicle-mounted data related to vehicle-mounted systems is also increasing sharply, which brings more challenges in vehicle-mounted data collection and uploading.

[0003] For example, automakers and service providers typically use a third-party data collection and upload system architecture to collect and upload in-vehicle data. This third-party architecture is typically closed-source, preventing automakers and service providers from accessing the code details of the architecture and processes, making it impossible for them to proactively customize them to suit their specific business needs. If automakers and service providers need to modify the architecture and processes, they must first communicate their business requirements to the third party. The third party then translates these requirements into functional implementations and modifies the architecture and processes accordingly. This process often requires multiple rounds of communication and confirmation between both parties, which is time-consuming, labor-intensive, and costly, and often produces unsatisfactory results. Furthermore, the data collection and upload processes in traditional data collection and upload system architectures lack logical connectivity, resulting in low data utilization, poor real-time performance, and poor system performance.

[0004] Therefore, the existing vehicle-mounted data collection and uploading methods need to be further improved. Summary of the Invention

[0005] In view of this, embodiments of the present application provide a method, system, electronic device, and storage medium for collecting and uploading in-vehicle data to solve at least one problem existing in existing methods for collecting and uploading in-vehicle data.

[0006] In a first aspect of an embodiment of the present application, a method for collecting and uploading vehicle data is provided, which is applied to a first tracking application, wherein the first tracking application encapsulates a data receiving class, a data processing class, a data management class, and a data uploading class; the first tracking application can be portable and installed in a first virtual machine, and the first virtual machine is deployed in a first operating system;

[0007] The method includes:

[0008] Establishing a first data transmission channel between the data receiving class and a second tracking application; wherein the second tracking application encapsulates a tracking management class and a tracking service class; the second tracking application can be portable and installed in a second virtual machine, and the second virtual machine is deployed in a second operating system;

[0009] Calling the data receiving class to obtain the vehicle data collected by the second tracking application through the first data transmission channel, and writing the vehicle data into the buffer data queue;

[0010] Call the data processing class and data management class to read the vehicle data from the buffered data queue and process it to obtain the file to be transmitted;

[0011] Establish a data upload channel between the data upload class and the data demand side;

[0012] If it is determined that the network status of the data upload channel is normal, the data upload class is called to upload the file to be transferred to the data demand end through the data upload channel.

[0013] A second aspect of the embodiments of the present application provides a vehicle-mounted data collection and uploading system, comprising:

[0014] a first virtual machine, the first virtual machine being deployed in a first operating system; the first virtual machine being portable and having a first tracking application installed thereon, the first tracking application encapsulating a data receiving class, a data processing class, a data management class, and a data uploading class;

[0015] a second virtual machine, the second virtual machine being deployed in a second operating system; the second virtual machine being portable and having a second tracking application installed thereon, the second tracking application encapsulating a tracking management class and a tracking service class;

[0016] The first tracking application is configured to:

[0017] establishing a first data transmission channel between the data receiving class and the second tracking application;

[0018] Calling the data receiving class to obtain the vehicle data collected by the second tracking application through the first data transmission channel, and writing the vehicle data into the buffer data queue;

[0019] Call the data processing class and data management class to read the vehicle data from the buffered data queue and process it to obtain the file to be transmitted;

[0020] Establish a data upload channel between the data upload class and the data demand side;

[0021] If it is determined that the network status of the data upload channel is normal, the data upload class is called to upload the file to be transferred to the data demand end through the data upload channel.

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

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

[0024] Compared with the prior art, the embodiments of the present application have at least the following beneficial effects: First, by adopting the independently developed data collection and upload architecture, automobile manufacturers and service providers can actively customize the architecture process according to their actual business needs, eliminating the need for multiple communications and confirmations with third parties to modify the architecture process, saving time, effort, low cost, and good results. Second, a production-consumer model is adopted to collect and upload vehicle data. Specifically, the vehicle data collected by the second tracking application is obtained by the data receiving class and written into the buffer data queue. The data processing class and the data management class then read the vehicle data from the buffer data queue and process it to obtain the file to be transmitted. Finally, when the network status of the data upload channel is normal, the data upload class uploads the file to be transmitted to the data demand end. This not only improves data utilization, but also ensures that the continuity and logical correlation of the entire data collection and upload process are strong, which can improve the real-time performance of data collection and upload, and is conducive to improving the system performance of the data collection and upload architecture. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0026] Figure 1 This is a schematic diagram of a data collection and upload architecture according to an embodiment of the present application;

[0027] Figure 2 This is a flow chart of a method for collecting and uploading vehicle data provided by an embodiment of the present application;

[0028] Figure 3 This is a schematic diagram of a data production and consumption model provided in an embodiment of the present application;

[0029] Figure 4 This is a schematic diagram of a vehicle data collection and upload logic implementation process provided by an embodiment of the present application;

[0030] Figure 5 This is a timing diagram of a vehicle-mounted data collection and upload process provided by an embodiment of the present application;

[0031] Figure 6 This is a structural diagram of a vehicle-mounted data collection and uploading system provided in an embodiment of the present application;

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

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

[0034] A method and device for collecting and uploading vehicle-mounted data according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 1 This is a schematic diagram of a data collection and upload architecture according to an embodiment of the present application. Figure 1 The data collection and upload architecture includes a first operating system 101, a second operating system 102, and a data demand end 103. Among them, the first operating system 101 can be an Android operating system. The second operating system 102 can be a QNX (Quick Unix) operating system. The QNX operating system can be applied to the vehicle-mounted system of a vehicle (such as a new energy vehicle, etc.). The vehicle-mounted system includes but is not limited to an in-vehicle entertainment information system, an in-vehicle communication system, an intelligent driving assistance system, an in-vehicle diagnostic system, and an in-vehicle network system. The data demand end 103 can be a TSP (Telematics Service Provider), which can be called an automobile remote service provider or a background data service provider.

[0036] In some implementations, a first virtual machine corresponding to the first operating system 101 and a second virtual machine corresponding to the second operating system 102 may be obtained through virtualization using a hardware hypervisor.

[0037] The first virtual machine includes but is not limited to: a first tracking application (such as Figure 1 TrackerAPP on the Android side), the first tracking application (such as Figure 1 The first tracking application (Tracker APP) encapsulates a data receiving class (such as Figure 1 DataRevice on the Android side), data processing classes (such as Figure 1DataHandle on the Android side), data management class (also known as system file management class, such as Figure 1 FileManager on the Android side) and data upload class (such as Figure 1 The first tracking application (Other APP) includes but is not limited to: SystemUI (System UI), Map (Map), Radio (Radio), BTControl (BT Control), Media (Media), etc. The first tracking application (Other APP) integrates the SDKs (Software Development Kits) corresponding to SystemUI (System UI), Map (Map), Radio (Radio), BTControl (BT Control), and Media (Media).

[0038] The second virtual machine includes but is not limited to: a second tracking application (such as Figure 1 Tracker Service (.so) on the QNX side) and the second tracking application (such as Figure 1 The second tracking application (TrackerService (.so)) encapsulates the tracking management class (such as Figure 1 TrackerManager on the QNX side) and tracking service classes (such as Figure 1 TrackerService on the QNX side. Secondary tracking applications include but are not limited to: AVM (panoramic imaging), Cluster HMI (instrument HMI), APA (automatic parking), Safety UI (functional safety), Effect Plugin, etc.

[0039] Figure 2 This is a flow chart of a method for collecting and uploading vehicle data provided in an embodiment of the present application. Figure 2 The vehicle data collection and upload method shown can be Figure 1 The first tracing application in the first virtual machine corresponding to the first operating system 101 is executed.

[0040] The first tracking application (Tracker APP) provided in the embodiment of the present application can be installed in the first virtual machine of the first operating system 101, and has good portability. The first tracking application (Tracker APP) is compatible with C++ and Java, has strong versatility, and has no special external dependencies, requiring only storage for data and a network for uploading data.

[0041] The first tracking application (Tracker APP) encapsulates the data receiving class, data processing class, data management class, and data uploading class for collecting and uploading vehicle data. It can decouple the first tracking application from other applications in the first virtual machine, making it easier for users (such as automobile manufacturers and service providers) to actively customize the architectural process of the data collection and uploading system architecture to adapt to their actual business needs.

[0042] See also Figure 2 The vehicle-mounted data collection and uploading method provided in the embodiment of the present application includes the following steps:

[0043] Step S201: establishing a first data transmission channel between a data receiving class and a second tracking application; wherein the second tracking application encapsulates a tracking management class and a tracking service class; the second tracking application can be installed in a second virtual machine, and the second virtual machine is deployed in a second operating system.

[0044] The second tracking application (Tracker Service (.so)) encapsulates the tracking management class (TrackerManager) and tracking service class (TrackerService) for collecting and uploading vehicle data. This decouples the second tracking application from other applications in the second virtual machine, allowing users (such as automakers and service providers) to proactively customize the architectural process of the data collection and upload system architecture to suit their actual business needs.

[0045] The second tracking application (Tracker Service (.so)) can be installed in the second virtual machine of the second operating system 102, thus offering excellent portability. The second tracking application (Tracker Service (.so)) is compatible with C++ and Java, is highly versatile, and has no external dependencies, requiring only storage for data and a network for uploading data.

[0046] See also Figure 1 The data receiving class (DataRevice) of the embodiment of the present application includes a tracking point intelligent service class (TrakerAgent), an internal tracking point class (App Traker Service) and an external tracking point class (QNX TrakerService).

[0047] As an example, the first tracking application (Tracker APP) can communicate through the TCP / IP layer of the kernel of the first operating system 101 and the TCP / IP layer of the kernel of the second operating system 102 to establish a first data transmission channel between the external tracking class (QNXTraker Service) and the second tracking application (Tracker Service (.so)). The first data transmission channel can be a socket transmission channel that supports the TCP / IP protocol.

[0048] Step S202 : calling the data receiving class to obtain the vehicle-mounted data collected by the second tracking application through the first data transmission channel, and writing the vehicle-mounted data into the buffer data queue.

[0049] Among them, in-vehicle data includes but is not limited to: in-vehicle infotainment data, intelligent driving data (for example, data related to automatic parking, adaptive cruise control, lane keeping, collision warning, etc.), in-vehicle diagnostic data, in-vehicle network data, etc.

[0050] Step S203: calling the data processing class and the data management class, reading the vehicle data from the buffered data queue and processing it to obtain the file to be transmitted.

[0051] The buffered data queue is essentially a message forwarder, which can be a message queue (MessageQueue, abbreviated as "MQ").

[0052] Generally, storing data in a buffered data queue is called a "producer." Reading data from a buffered data queue is called a "consumer." Therefore, the data receiving class (DataRevice) in this embodiment of the application can be called a "producer," and the data processing class (DataHandle) and data management class (FileManager) can be called "consumers."

[0053] Step S204: establishing a data upload channel between the data upload class and the data demand end.

[0054] As an example, the first tracking application (Tracker APP) can establish a data upload channel between the data upload class (UploadTracker) and the data demand side (TSP) through the TCP / IP layer of the kernel of the first operating system 101. The data upload channel can be an HTTP (Hypertext Transfer Protocol) channel or an MQTT (Message Queuing Telemetry Transport) channel.

[0055] Step S205: call the data upload class to upload the file to be transferred to the data demand end through the data upload channel.

[0056] Figure 3 This is a schematic diagram of a data production and consumption model provided in an embodiment of the present application.

[0057] As an example, see Figure 1 and Figure 3 , the first tracking application (Tracker APP) calls the external tracking class (QNX Traker Service) in the data receiving class (DataRevice), so that the external tracking class (QNXTraker Service) obtains the vehicle data collected by the second tracking application (Tracker Service (.so)) through the first data transmission channel, wherein these vehicle data come from the second tracking application (Application). Then, the data receiving class (DataRevice) can store these vehicle data in the buffered data queue (message queue (Queue)). The first tracking application (Tracker APP) obtains the application data generated by each APP in the first tracking application (Other APP) through the second data transmission channel by calling the internal tracking class (App TrackerService) in the data receiving class (DataRevice). Then, the data receiving class (DataRevice) can store these application data in the buffered data queue (message queue (Queue)). Afterwards, the data processing class (DataHandle) and the data management class (FileManager) can read the vehicle data from the buffered data queue (message queue (Queue)) and process it (write it to file consumption) to obtain the file to be transmitted, and then the data upload class (UploadTracker) uploads the file to be transmitted to the data demand side (TSP).

[0058] The technical solutions provided by the embodiments of this application have at least the following technical effects:

[0059] First, by adopting a self-developed data collection and upload architecture, automakers and service providers can proactively customize the architecture and processes based on their actual business needs, eliminating the need for multiple communications and confirmations with third parties to modify the architecture and processes. This approach saves time, effort, and costs, while delivering excellent results. Second, a producer-consumer model is used to collect and upload vehicle data. Specifically, the data receiving class obtains the vehicle data collected by the second tracking application and writes it into a buffered data queue. The data processing and data management classes then read the vehicle data from the buffered data queue and process it to obtain the file to be transmitted. Finally, when the network status of the data upload channel is normal, the data upload class uploads the file to be transmitted to the data demand side. This not only improves data utilization, but also ensures a strong continuity and logical correlation throughout the data collection and upload process, improving the real-time nature of data collection and upload, while also enhancing the system performance of the data collection and upload architecture.

[0060] In some embodiments, calling a data processing class and a data management class to read and process vehicle data from a buffered data queue to obtain a file to be transmitted includes:

[0061] Calling the data processing class to read the vehicle data from the buffer data queue, converting the format of the vehicle data to obtain a first data file, and calling the data management class to store the first data file in the first file path;

[0062] Call the data management class to copy the first data file from the first file path to the second file path;

[0063] Calling the data processing class to compress the first data file to obtain a second data file, and calling the data management class to store the second data file in a third file path;

[0064] The data processing class is called to encrypt the second data file to obtain the file to be transmitted, and the data management class is called to move the file to be transmitted to a fourth file path; wherein the first file path, the second file path, the third file path and the fourth file path are different.

[0065] As an example, first, the first tracking application (Tracker APP) can call the data processing class (DataHandle) to read N vehicle data (N is an integer ≥1) from the buffer data queue according to the preset data reading rules (for example, reading in the order in which the data is written to the buffer data queue), and convert these N vehicle data into json format to obtain the first data file (txt file); then, call the data management class (FileManager) to store the first data file (txt file) under the first file path.

[0066] For example, the file path "basePath" can be described as storage / emulated / 0 / Android / data / com.ts.track / file. The first file path can be "bathPath / temp". This path description states: When there are 20 pieces of vehicle data, these 20 pieces of vehicle data are converted into a JSON-formatted string and written to a txt file to obtain a first data file (txt file), and the first data file is stored in the first file path. Typically, the first file path only stores one first data file (txt file).

[0067] In one example, the naming convention for the first data file (txt file) can be: "vin_timestamp_fileCount.txt", where "vin" represents the unique identification code of the vehicle; "timestamp" represents the creation timestamp of the first data file; and "fileCount.txt" represents the file name of the first data file. For example, LHIBF97HFAKH_16797364871_1.txt, where "vin" is "LHIBF97HFAKH", "timestamp" is "16797364871", and "fileCount.txt" is "1.txt".

[0068] Next, the first tracking application (Tracker APP) can call the data management class (FileManager) to copy the first data file (txt file) stored in the first file path to the second file path, and call the data processing class (DataHandle) to compress the first data file (txt file) to obtain the second data file (gz file). Then, the data management class (FileManager) is called to store the second data file (gz file) in the third file path.

[0069] By compressing the first data file, the data storage capacity can be increased, which is beneficial to improving data utilization.

[0070] In one example, the second file path can be "basePath / src", which is described as: when 20 files are uploaded or vehicle data are written to the first data file, the first data file (txt file) is moved from the temp path (ie, the first file path) to the src path (ie, the second file path).

[0071] Next, the first tracking application (Tracker APP) calls the data processing class (DataHandle) to encrypt the second data file (gz file) to obtain the file to be transferred (enc file), and calls the data management class (FileManager) to move the file to be transferred (enc file) to the fourth file path. The encryption method for encrypting the second data file can adopt a PKI (Public Key Infrastructure) encryption method. Specifically, the cryptoFiles method under PkiController can be used to encrypt the second data file. The specific encryption method and implementation can be improved based on the actual application program interface (API) used.

[0072] In one example, the third file path can be "basePath / gz", which describes the writing location of the second data file (gz file) when uploading the file, and compressing the first data file (txt file) from the src path (ie, the second file path) to the gz path (ie, the third file path).

[0073] In one example, the fourth file path can be "basePath / enc", which describes the following: when uploading a file, the writing location of the file to be transferred (enc file), encrypting the second data file (gz file) from the gz path (ie, the third file path) to the enc path (ie, the fourth file path).

[0074] In some embodiments, when uploading vehicle data in debug mode, the vehicle data may be moved from the first file path to a fifth file path for testing and viewing. The fifth file path may be "basePath / debug," which indicates that when uploading a file in debug mode, the vehicle data is moved from the temp path (i.e., the first file path) to the debug path (i.e., the fifth file path) for testing and viewing.

[0075] In some embodiments, when the number of files of the first data files (txt files) under the second file path reaches a preset file quantity threshold (which can be flexibly set according to actual conditions, for example, it can be set to 10, 20, etc.), a trigger is triggered to determine whether the total file quantity of the second data files (gz files) under the third file path exceeds a preset file quantity threshold (which can be flexibly set according to actual conditions, for example, it can be set to 10M, 20M, etc.). If the total file quantity of the second data files (gz files) under the third file path exceeds the preset file quantity threshold, the old second data files (gz files) under the third file path are deleted to maintain the total file quantity of the second data files (gz files) under the third file path not exceeding the preset file quantity threshold. In this way, the file quantity under the third file path can be prevented from continuing to increase.

[0076] In some implementations, after the file to be transmitted is successfully uploaded to the data demand end, the second data file (gz file) corresponding to the file to be transmitted will be deleted.

[0077] In some embodiments, after the first data file (txt file) under the second file path is compressed into the second data file (gz file) and successfully stored in the third file path, the first data file (txt file) under the second file path is deleted.

[0078] In some embodiments, calling a data processing class to read vehicle data from a buffered data queue, performing format conversion on the vehicle data to obtain a first data file, and calling a data management class to store the first data file in a first file path includes:

[0079] Determine whether the network communication status between the data upload class and the data demand end is normal, and whether there is currently any data upload task being executed;

[0080] If the network communication status between the data upload class and the data demand end is normal and there is no data upload task currently being executed, determine the first directory status of the first directory under the first file path, the second directory status of the second directory under the second file path, and the third directory status of the second directory under the third file path;

[0081] If at least one of the first directory state, the second directory state or the third directory state is a non-empty state, the data processing class is called to read the vehicle data from the buffer data queue, and the vehicle data is format converted to obtain the first data file, and the data management class is called to store the first data file in the first file path.

[0082] The first directory status is used to indicate whether the first directory under the first file path is empty or not. For example, if the first directory is empty, it means that the first file directory under the first file path has no content. If the first directory is not empty, it means that the first file directory under the first file path has content, such as files or subdirectories.

[0083] The second directory status is used to indicate whether the second directory under the second file path is empty or not.

[0084] The third directory status is used to indicate whether the third directory under the third file path is empty or not empty.

[0085] Data upload tasks refer to tasks that upload files to be transferred to the data demand side.

[0086] In some embodiments, if at least one of the first directory state, the second directory state, or the third directory state is not empty, the data processing class is called to read the vehicle data from the buffered data queue, and the vehicle data is format converted to obtain a first data file, and the data management class is called to store the first data file in the first file path, including:

[0087] If at least one of the first directory status, the second directory status, or the third directory status is non-empty, determining whether there is a first empty folder under the first directory;

[0088] If there is a first empty folder under the first directory, delete the first empty folder;

[0089] Determine whether there is a second empty folder in the second directory;

[0090] If there is a second empty folder in the second directory, delete the second empty folder;

[0091] Delete the third directory under the third file path and recreate a new third directory;

[0092] Delete the fourth directory under the fourth file path and create a new fourth directory.

[0093] Figure 4 This is a schematic diagram of the logic implementation process of vehicle-mounted data collection and upload provided by this application.

[0094] See also Figure 4 The vehicle data collection and upload logic implementation process provided in the embodiment of the present application includes the following steps:

[0095] Step S401: Determine whether the network communication status between the data uploader and the data demander is normal (ie, whether the network connection status is normal), and whether there is a data upload task currently being executed.

[0096] Step S402: If the network communication status between the data upload class and the data demand end is abnormal or there is a data upload task currently being executed, wait for the next upload.

[0097] Step S403: If the network communication status between the data upload class and the data demand end is normal and there is no upload task currently being executed, determine whether the first, second and third directories under the first, second and third file paths are all empty.

[0098] If the first, second and third directories under the first, second and third file paths are all empty directories, the process returns to step S402.

[0099] If at least one of the first, second and third directories under the first, second and third file paths is not empty, jump to step S404.

[0100] Step S404: Determine whether there is a first empty folder in the first directory.

[0101] Step S405: If a first empty folder exists in the first directory, delete the first empty folder in the first directory and jump to step S406.

[0102] Step S406: If there is no first empty folder in the first directory, determine whether there is a second empty folder in the second directory.

[0103] Step S407: If a second empty folder exists in the second directory, delete the second empty folder in the second directory and jump to step S408.

[0104] Step S408: If the second empty folder does not exist in the second directory, the third directory in the third file path is deleted, and a new third directory is created.

[0105] Step S409: Delete the fourth directory under the fourth file path and create a new fourth directory.

[0106] Step S410: compress the first data file (txt file) stored in the second directory to obtain a second data file (gz file), and store the second data file (gz file) in the third directory.

[0107] Step S411: Encrypt the second data file (gz file) in the third directory to obtain a file to be transmitted (enc file), and store the file to be transmitted (enc file) in the fourth directory.

[0108] Step S412: Call the data upload class to upload the file to be transmitted (enc file) stored in the fourth directory to the data demand end.

[0109] Step S413: Determine whether the file to be transferred is uploaded successfully.

[0110] If the file to be transferred fails to be uploaded, jump to step S414.

[0111] Step S414, determine whether the number of upload failures exceeds the preset number threshold, where the preset number threshold can be flexibly set according to actual conditions, for example, it can be set to 3 times, 4 times, 5 times, etc., and the embodiment of the present application does not impose specific restrictions on this.

[0112] If the number of upload failures exceeds the preset number threshold, the upload task is terminated. If the number of upload failures does not exceed the preset number threshold, the process returns to step S401.

[0113] If the file to be transferred is uploaded successfully, jump to step S415.

[0114] Step S415: Delete the files to be transferred in the fourth empty file directory.

[0115] Through the above implementation, when the network communication status between the data upload class and the data demand end is normal and there is no data upload task being executed, the data upload task is started, which can ensure the quality of data transmission. In addition, by first determining the directory status of the first directory under the first file path, the second directory under the second file path, and the third directory under the third file path, and then determining whether there are empty folders under the first directory and the second directory, it is possible to achieve double verification of whether there are non-empty directories and empty folders under the first, second, third and fourth file paths, and avoid transmitting empty folders to the data demand end as much as possible. This can improve the efficiency and quality of data upload.

[0116] In some embodiments, calling a data upload class to upload a file to be transferred to a data demander through a data upload channel includes:

[0117] Call the data upload class to read the file to be transferred under the fourth file path, and upload the file to be transferred to the data demand end through the data upload channel;

[0118] Get the feedback message returned by the data demand side;

[0119] If the upload of the file to be transferred fails based on the feedback message, the number of upload failures is recorded;

[0120] If the number of upload failures exceeds a preset threshold, the uploading of the file to be transferred is terminated, the file to be transferred is marked as a failed upload file, and the failed upload file is cached in a third file path.

[0121] As an example, the first tracking application (Tracker APP) calls the data upload class (UploadTracker) to read the file to be transferred (enc file) under the fourth file path and uploads it to the data demander via the HTTPS channel or / and the MQTT channel. After receiving the file to be transferred (enc file), the data demander returns a feedback message to the first tracking application (Tracker APP). This feedback message indicates whether the data demander successfully received the file to be transferred (enc file).

[0122] If the first tracking application (Tracker APP) confirms that the upload of the file to be transferred has failed based on the feedback message returned by the data demander, the number of upload failures will be recorded. If the number of upload failures exceeds a preset threshold (which can be flexibly set according to actual conditions, for example, 3, 4, or 5 times), the data upload task will be terminated, the file to be transferred will be marked as a failed upload file, and the failed upload file will be cached in the third file path.

[0123] In some embodiments, the above method may further include the following steps:

[0124] Call the data management class to count the total file cache of failed upload files in the third empty file directory according to the preset statistical period;

[0125] If the total file cache amount reaches the preset cache upper limit, the failed uploaded files under the third file path are cleared and a data clearing record is recorded. The data clearing record includes at least the marking information and data size of the cleared failed uploaded files.

[0126] The preset statistical period can be flexibly set according to actual conditions. For example, it can be set to 1 day, 2 days, etc. The embodiment of the present application does not impose any specific restrictions on this.

[0127] As an example, the first tracking application (Tracker APP) calls the data management class (FileManager) to count the total file cache of failed upload files under the third file path according to a preset statistical period. If the total file cache reaches a preset cache upper limit (which can be flexibly set according to actual conditions, for example, 10M, 20M, etc.), the failed upload files under the third file path are cleared and a data clearing record is recorded. The data clearing record includes at least the file tag information and file size of the cleared failed upload files.

[0128] The file tag information may be a file name used to distinguish and identify different failed uploaded files. The file name may be a string of numbers, letters, etc.

[0129] By using the above method, the total amount of file cache under the third file path can be prevented from continuously increasing. In some embodiments, the above method may further include the following steps:

[0130] Call the data management class to read data and clear records;

[0131] According to the data clearing record, it is confirmed that the vehicle data has not been uploaded;

[0132] The data receiving class is called to send a re-collection instruction to the second tracking application through the first data transmission channel, where the re-collection instruction includes the vehicle data that has not been uploaded.

[0133] The data upload summary record mainly records the SharePreferences data recorded in the SPUtil class, such as the total number of files to be uploaded on the same day, the total file size of the files to be uploaded, the number of vehicle data collected by the second tracking application on the same day, the time of the last creation of the first data file (txt file), and the like.

[0134] As an example, the information of the cleaned failed upload file (including the tag information and the data size of the failed upload file) can be determined by querying the data to clear the record, so that the un-uploaded vehicle data can be determined. Then, the first tracking application (Tracker APP) can call the data receiving class to send a resampling instruction to the second tracking application through the first data transmission channel, and the resampling instruction includes the un-uploaded vehicle data.

[0135] In this way, the missing collection and uploading of the vehicle data can be effectively prevented, so that the accuracy of the subsequent data analysis result can be ensured.

[0136] Figure 5 is a timing diagram of a vehicle data collection and uploading process provided by an embodiment of the present application.

[0137] As an example, please refer to Figure 5 The vehicle data collection and uploading process of the embodiment of the present application is as follows:

[0138] When the preset file uploading trigger condition (for example, the first opening of the data collection and uploading application or every 30 minutes or the number of first data files (txt files) under the second file path exceeds 10) is met, the file uploading operation will be triggered.

[0139] When a file upload operation is triggered, the TrackerAgent (tracking intelligent service class) in the data receiving class (DataRevice) initializes the upload method, initializes the cryptoOperate method of the PKiController (data control class) in the data processing class (DataHandle), and calls the ProcessFIlesCOntroller (file operation control class) and FilUtils (file system operation tool class) in the data processing class (DataHandle) to move the first data file (or called Temp file) stored in the first file path to the src path (i.e., the second file path), and calls the SpUtils (cache tool class) in the data processing class (DataHandle) to write all files (the first data file). Call FilUtils (file system operation tool class) to clear the enc directory (i.e., the fourth directory under the fourth file path) and the gz directory (i.e., the third directory under the third file path). Next, TrackerAgent (tracking intelligent service class) calls ProcessFIlesCOntroller (file operation control class) and ZlibUitl (compression tool class) to compress the first data file (txt file) stored in the src path (i.e., the second file path) into the second data file (gz file), and stores it in the gz path (i.e., the third file path). TrackerAgent (tracking intelligent service class) calls PKiController (data control class) and uses the cryptoFiles method under PKiController (data control class) to encrypt the second data file (gz file) to obtain the file to be transmitted (enc file), and stores the file to be transmitted (enc file) in the enc path (i.e., the fourth file path). TrackerAgent (tracking intelligent service class) calls NetController (network status processing class) in the data upload class (UploadTracker) to upload the files to be transmitted to the data demand end according to the list. TrackerAgent (tracking intelligent service class) manages the data upload results. After successful upload, it calls ProcessFIlesCOntroller (file operation control class) to delete the corresponding gz file in the gz path.

[0140] In some embodiments, when the compressed files (gz files) under the third directory (gz directory) reach a preset file size threshold (such as 10M), the old gz files under the third file path will be deleted until the gz files under the gz directory are less than 10M. At this time, the deleted file names and file sizes will be recorded and added to the df_array.json file.

[0141] When initializing TrackerAgent (a smart service class for tracking), the content in df_array.json is read and the upload_operate_record method is called to upload the deletion record.

[0142] When initializing TrackerAgent (a smart service class for tracking), the information in the SPUtil class is read and written into sum_array.json, and the upload_operate_record method is called to upload the information in the sum_array.json file. The SPUtil class mainly records SharePreferences data, such as the total number of files written, the total amount of files written on the same day, the number of vehicle data collected on the same day, the last time the first data file (txt file) was created, and other information.

[0143] In some embodiments, tracking can use HTTP and TSP communication and implement upload logic. If other methods are needed, external implementation is required. Currently, data is packaged, and two methods, Upload(buffer) and Upload(File[]), are reserved. Upload(File[]) can be used to upload files, and Upload(buffer) can be used to upload "summary and deletion" records.

[0144] All the above optional technical solutions can be combined in any way to form optional embodiments of the present application, which will not be repeated here.

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

[0146] Figure 6 is a structural schematic diagram of a vehicle data collection and upload system provided by an embodiment of the present application. As shown in Figure 6 The vehicle data collection and upload system includes:

[0147] A first virtual machine is deployed in a first operating system. The first virtual machine is portably installed with a first tracking application, and the first tracking application encapsulates a data receiving class, a data processing class, a data management class, and a data uploading class.

[0148] A second virtual machine is deployed in a second operating system. The second virtual machine is portably installed with a second tracking application, and the second tracking application encapsulates a tracking management class and a tracking service class.

[0149] The first tracking application is configured to:

[0150] establishing a first data transmission channel between the data receiving class and the second tracking application;

[0151] Calling the data receiving class to obtain the vehicle data collected by the second tracking application through the first data transmission channel, and writing the vehicle data into the buffer data queue;

[0152] Call the data processing class and data management class to read the vehicle data from the buffered data queue and process it to obtain the file to be transmitted;

[0153] Establish a data upload channel between the data upload class and the data demand side;

[0154] If it is determined that the network status of the data upload channel is normal, the data upload class is called to upload the file to be transferred to the data demand end through the data upload channel.

[0155] In some embodiments, calling a data processing class and a data management class to read and process vehicle data from a buffered data queue to obtain a file to be transmitted includes:

[0156] Calling the data processing class to read the vehicle data from the buffer data queue, converting the format of the vehicle data to obtain a first data file, and calling the data management class to store the first data file in the first file path;

[0157] Call the data management class to copy the first data file from the first file path to the second file path;

[0158] Calling the data processing class to compress the first data file to obtain a second data file, and calling the data management class to store the second data file in a third file path;

[0159] The data processing class is called to encrypt the second data file to obtain the file to be transmitted, and the data management class is called to move the file to be transmitted to a fourth file path; wherein the first file path, the second file path, the third file path and the fourth file path are different.

[0160] In some embodiments, calling a data processing class to read vehicle data from a buffered data queue, performing format conversion on the vehicle data to obtain a first data file, and calling a data management class to store the first data file in a first file path includes:

[0161] Determine whether the network communication status between the data upload class and the data demand end is normal, and whether there is currently any data upload task being executed;

[0162] If the network communication state between the data uploading class and the data demand end is normal, and there is no data uploading task being executed at present, the first directory state of the first directory under the first file path, the second directory state of the second directory under the second file path, and the third directory state of the second directory under the third file path are determined.

[0163] If at least one of the first directory state, the second directory state, or the third directory state is a non-empty state, the data processing class is called, the vehicle-mounted data is read from the buffer data queue, the vehicle-mounted data is format-converted to obtain a first data file, and the data management class is called to store the first data file under the first file path.

[0164] In some embodiments, if at least one of the first directory state, the second directory state, or the third directory state is a non-empty state, the data processing class is called, the vehicle-mounted data is read from the buffer data queue, the vehicle-mounted data is format-converted to obtain a first data file, and the data management class is called to store the first data file under the first file path, including:

[0165] If at least one of the first directory state, the second directory state, or the third directory state is a non-empty state, it is determined whether the first empty folder exists under the first directory.

[0166] If the first empty folder exists under the first directory, the first empty folder is deleted.

[0167] It is determined whether the second empty folder exists under the second directory.

[0168] If the second empty folder exists under the second directory, the second empty folder is deleted.

[0169] The third directory under the third file path is deleted, and a new third directory is created.

[0170] The fourth directory under the fourth file path is deleted, and a new fourth directory is created.

[0171] In some embodiments, the data uploading class is called to upload the to-be-transmitted file to the data demand end through the data uploading channel, including:

[0172] The data uploading class is called to read the to-be-transmitted file under the fourth file path, and the to-be-transmitted file is uploaded to the data demand end through the data uploading channel.

[0173] The feedback message returned by the data demand end is obtained.

[0174] If it is confirmed based on the feedback message that the to-be-transmitted file fails to be uploaded, the number of upload failures is recorded.

[0175] If the number of failed uploads exceeds the preset number threshold, the uploading of the to-be-transmitted file is ended, the to-be-transmitted file is marked as a failed upload file, and the failed upload file is cached in the third file path.

[0176] In some embodiments, the first tracking application described above can be further configured to:

[0177] invoke the data management class to count the total file cache amount of the failed upload files in the third file path according to a preset statistical period;

[0178] If the total file cache amount reaches a preset upper cache limit, the failed upload files in the third file path are emptied, and a data emptying record is recorded, the data emptying record at least including file marker information and file size of the failed upload files cleaned.

[0179] In some embodiments, the first tracking application described above can be further configured to:

[0180] invoke the data management class to read the data emptying record;

[0181] determine the un-uploaded vehicle data according to the data emptying record;

[0182] invoke the data receiving class to send a resampling instruction to the second tracking application through the first data transmission channel, the resampling instruction including the un-uploaded vehicle data.

[0183] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0184] Figure 7 is a schematic diagram of an electronic device 7 provided by the embodiments of the present application. As shown in Figure 7 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. The processor 701 implements the steps in each of the above method embodiments when executing the computer program 703. Alternatively, the processor 701 implements the functions of each module / unit in each of the above device embodiments when executing the computer program 703.

[0185] The electronic device 7 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The electronic device 7 can include but is not limited to the processor 701 and the memory 702. Those skilled in the art can understand, Figure 7 is merely an example of the electronic device 7 and does not constitute a limitation on the electronic device 7, which can include more or fewer components or different components than those shown.

[0186] 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.

[0187] The memory 702 can be an internal storage unit of the electronic device 7, such as a hard disk or memory of the electronic device 7. The memory 702 can also be an external storage device of the electronic device 7, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 7. The memory 702 can 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.

[0188] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0189] 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 readable storage medium (such as 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, etc. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

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

Claims

1. A method for collecting and uploading vehicle data, characterized in that: Applied to a first tracking application, the first tracking application encapsulates a data receiving class, a data processing class, a data management class, and a data uploading class; The first tracking application is portable and installable in a first virtual machine, and the first virtual machine is deployed in a first operating system; The method comprises: Establishing a first data transmission channel between the data receiving class and a second tracking application; wherein the second tracking application encapsulates a tracking management class and a tracking service class; the second tracking application is portable and installable in a second virtual machine, and the second virtual machine is deployed in a second operating system; Calling the data receiving class to obtain the vehicle data collected by the second tracking application through the first data transmission channel, and writing the vehicle data into a buffered data queue; Calling the data processing class and the data management class to read the vehicle data from the buffered data queue and process it to obtain a file to be transmitted; Establishing a data upload channel between the data upload class and the data demand end; If it is determined that the network status of the data upload channel is normal, the data upload class is called to upload the file to be transmitted to the data demand end through the data upload channel.

2. The method according to claim 1, characterized in that Calling the data processing class and the data management class, reading the vehicle data from the buffered data queue and processing it to obtain the file to be transmitted, including: Calling the data processing class to read the vehicle-borne data from the buffered data queue, performing format conversion on the vehicle-borne data to obtain a first data file, and calling the data management class to store the first data file in a first file path; Calling the data management class to copy the first data file from the first file path to the second file path; Calling the data processing class to compress the first data file to obtain a second data file, and calling the data management class to store the second data file in a third file path; Call the data processing class to encrypt the second data file to obtain the file to be transmitted, and call the data management class to move the file to be transmitted to a fourth file path; wherein the first file path, the second file path, the third file path and the fourth file path are different.

3. The method according to claim 2, characterized in that Calling the data processing class, reading the vehicle data from the buffered data queue, performing format conversion on the vehicle data to obtain a first data file, and calling the data management class to store the first data file in a first file path, including: Determine whether the network communication status between the data upload class and the data demand end is normal, and whether there is a data upload task currently being executed; If the network communication status between the data upload class and the data demand end is normal and there is no data upload task currently being executed, determine the first directory status of the first directory under the first file path, the second directory status of the second directory under the second file path, and the third directory status of the second directory under the third file path; If at least one of the first directory state, the second directory state or the third directory state is a non-empty state, the data processing class is called to read the vehicle data from the buffered data queue, and the format of the vehicle data is converted to obtain a first data file, and the data management class is called to store the first data file in the first file path.

4. The method according to claim 3, characterized in that If at least one of the first directory state, the second directory state, or the third directory state is not empty, calling the data processing class, reading the vehicle data from the buffered data queue, performing format conversion on the vehicle data to obtain a first data file, and calling the data management class to store the first data file in a first file path, including: If at least one of the first directory status, the second directory status, or the third directory status is non-empty, determining whether there is a first empty folder under the first directory; If a first empty folder exists in the first directory, deleting the first empty folder; Determine whether there is a second empty folder in the second directory; If a second empty folder exists in the second directory, deleting the second empty folder; Deleting the third directory under the third file path and recreating a new third directory; The fourth directory under the fourth file path is deleted, and a new fourth directory is created.

5. The method according to claim 3, characterized in that Calling the data upload class to upload the file to be transferred to the data demand end through the data upload channel includes: Calling the data upload class to read the file to be transmitted under the fourth file path, and uploading the file to be transmitted to the data demand end through the data upload channel; Obtaining feedback from the data requester. If it is confirmed based on the feedback message that the file to be transferred has failed to be uploaded, the number of upload failures is recorded; If the number of upload failures exceeds a preset number threshold, the uploading of the file to be transmitted is terminated, the file to be transmitted is marked as a failed upload file, and the failed upload file is cached in the third file path.

6. The method according to claim 5, characterized in that The method further comprises: Calling the data management class to count the total file cache amount of failed uploaded files under the third file path according to a preset statistical period; If the total file cache amount reaches the preset cache upper limit, the failed uploaded files under the third file path are cleared and a data clearing record is recorded. The data clearing record includes at least the file mark information and file size of the cleared failed uploaded files.

7. The method according to claim 6, characterized in that The method further comprises: Call the data management class to read the data clearing record; Clear the record based on the data to determine that no vehicle data has been uploaded; The data receiving class is called to send a re-collection instruction to the second tracking application through the first data transmission channel, where the re-collection instruction includes the unuploaded vehicle data.

8. A vehicle-mounted data collection and upload system, characterized in that: include: a first virtual machine, wherein the first virtual machine is deployed in a first operating system; The first virtual machine is portable and has a first tracking application installed therein, wherein the first tracking application encapsulates a data receiving class, a data processing class, a data management class, and a data uploading class; a second virtual machine, wherein the second virtual machine is deployed in a second operating system; The second virtual machine is portable and has a second tracking application installed therein, wherein the second tracking application encapsulates a tracking management class and a tracking service class; The first tracking application is configured to: establishing a first data transmission channel between the data receiving class and a second tracking application; Calling the data receiving class to obtain the vehicle data collected by the second tracking application through the first data transmission channel, and writing the vehicle data into a buffered data queue; Calling the data processing class and the data management class to read the vehicle data from the buffered data queue and process it to obtain a file to be transmitted; Establishing a data upload channel between the data upload class and the data demand end; If it is determined that the network status of the data upload channel is normal, the data upload class is called to upload the file to be transmitted to the data demand end through the data upload channel.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 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