CN115987963A

CN115987963A - Vehicle data uploading method, wireless networking controller and system

Info

Publication number: CN115987963A
Application number: CN202211472917.2A
Authority: CN
Inventors: 张培强; 见永刚; 邓冕
Original assignee: Beijing Jingwei Hirain Tech Co Ltd
Current assignee: Beijing Jingwei Hirain Tech Co Ltd
Priority date: 2022-11-17
Filing date: 2022-11-17
Publication date: 2023-04-18

Abstract

The invention provides a vehicle data uploading method, a wireless networking controller and a system. And setting NFS service in the Tbox as a Client mode, and setting the NFS service in each ECU as a Server mode so as to share local data to the Tbox. The Tbox receives a data uploading instruction sent by the data platform, analyzes the data uploading instruction to obtain data characteristics, determines a target ECU corresponding to the data characteristics, mounts the target ECU to obtain target data corresponding to the data characteristics, and uploads the target data to the FTP server. In the invention, the Tbox mounts the ECU to acquire the target data from the ECU and uploads the target data to the FTP server, so that only the network security of the Tbox in the vehicle is required to be ensured when the system is used, and each ECU is not required to be modified, thereby reducing the development difficulty and the workload and having higher security.

Description

Vehicle data uploading method, wireless networking controller and system

Technical Field

The invention relates to the technical field of data transmission, in particular to a vehicle data uploading method, a wireless networking controller and a system.

Background

When the driving track and the driving state of the vehicle are abnormal, developers can hardly locate the cause of the fault only by the fault phenomenon of the vehicle. The analysis of the cause of the fault is required to be performed according to the relevant ECU (Electronic Control Unit) and the relevant sensor data.

The existing data uploading is performed in a mode that each ECU is communicated with a server, so that each ECU is required to have a network access function. The ECU has a networking function and brings hidden dangers of network safety, and the network safety needs to be additionally considered, so that the development difficulty and the workload are increased.

Disclosure of Invention

In order to solve the problems of potential networking safety hazards, development difficulty increase, workload increase and the like in the prior art, the invention provides a vehicle data uploading method, a wireless networking controller and a system, and the vehicle data uploading method, the wireless networking controller and the system have the characteristics of higher safety, development difficulty reduction, workload reduction and the like.

According to a vehicle data uploading method provided by the specific embodiment of the invention, the method is applied to a wireless networking controller (Tbox) in a vehicle, each Electronic Control Unit (ECU) on the vehicle is used for acquiring original data and storing local data of a sensor carried by the ECU, and storing a system running log, a Network File System (NFS) service is built in the Tbox and is set to be a Client mode, so that the Tbox obtains access authority of local data of each ECU, an NFS service is built in each ECU and is set to be a Server mode, so that the local data are shared by the Tbox, and the Tbox and the ECUs are connected through a vehicle-mounted Ethernet, so that communication between the Client end and the Server end of the NFS service is realized;

the vehicle data uploading method comprises the following steps:

receiving a data uploading instruction sent by a data platform, wherein the communication between the data platform and the Tbox is realized based on a Message Queue Telemetry Transmission (MQTT) protocol, and the communication between the data platform and the Tbox is realized by building an MQTTBrker service on the data platform end;

analyzing the data uploading instruction to obtain data characteristics, and determining a target ECU corresponding to the data characteristics, wherein the data characteristics comprise at least one of an equipment identifier and a to-be-acquired data identifier, the equipment identifier comprises an ECU identifier and/or a sensor identifier, and the to-be-acquired data identifier comprises a time slice or a target file name;

and mounting the target ECU to acquire target data corresponding to the data characteristics, and uploading the target data to a File Transfer Protocol (FTP) server.

Optionally, the analyzing the data uploading instruction to obtain the data characteristics includes:

under the condition that the data uploading instruction comprises an equipment identifier and a time slice, acquiring the equipment identifier and the time slice from the data uploading instruction, wherein the equipment identifier comprises an ECU identifier and/or a sensor identifier, and the time slice is a time period determined by a starting time and an ending time;

under the condition that the data uploading instruction comprises an equipment identifier and a target file name, acquiring the equipment identifier and the target file name from the data uploading instruction, wherein the target file name is selected from a file name list;

and under the condition that the data uploading instruction only comprises the equipment identification, acquiring the equipment identification from the data uploading instruction.

Optionally, mounting the target ECU to obtain target data corresponding to the data feature includes:

mounting the target ECU to acquire the data access authority of the target ECU;

under the condition that the data characteristics comprise equipment identification and data identification to be obtained, traversing data of equipment corresponding to the equipment identification from the target ECU, and screening target data corresponding to the data identification to be obtained from the data obtained by traversing;

and under the condition that the data features only comprise equipment identification, if the equipment identification is sensor identification, using original data which are stored by the target ECU and are acquired by a sensor corresponding to the sensor identification as target data, and if the equipment identification is ECU identification, using a system operation log stored by the target ECU as the target data.

Optionally, if the mounting of the target ECU fails, the method further includes:

replying a negative acknowledgement to the data platform;

if the target data corresponding to the data characteristics cannot be acquired, the method further comprises the following steps:

and replying a positive response to the data platform, and uploading the uploaded file list with empty content to the FTP server.

Optionally, the method further comprises:

based on NFS service, periodically mounting sharing partitions shared by the ECUs into the Tbox, and scanning existing files on each sharing partition;

sending the newly added file name to the data platform through an MQTT protocol in an incremental detection mode so that the data platform stores file list information in a database form;

and after the newly added file name is sent to the data platform, the Tbox releases the mounting of the Tbox on each ECU until the next mounting period comes and then the Tbox is mounted again.

Optionally, in the process of periodically mounting the shared partition shared by the ECUs to the Tbox, the method further includes:

and if the mounting is failed, forbidding the mounting operation, recording the reason of the mounting failure in a Tbox running log, and after the next mounting period comes, re-mounting, wherein the reason of the mounting failure at least comprises NFS service running abnormity or connection abnormity caused by poor contact of a vehicle-mounted Ethernet cable harness.

Optionally, the method further comprises:

when detecting that an abnormal information file exists in each ECU, the Tbox uploads the abnormal information file to an FTP server;

and uploading a system running log file closest to the time to the FTP server by taking the time stamp of the abnormal time as a reference, and sending a specific notification message to the data platform after the uploading is finished.

A wireless networking controller is used for executing the vehicle data uploading method.

A vehicle data uploading system comprises the wireless networking controller.

Optionally, the system further comprises a data platform and an FTP server;

the data platform is used for sending a data uploading instruction to the Tbox;

the FTP server is used for receiving the target data sent by the Tbox.

The invention provides a vehicle data uploading method, a wireless networking controller and a system. Each ECU on the vehicle is used for collecting and locally storing original data of a sensor carried by the ECU, and storing system running logs, NFS service is built in the Tbox and is set to be in a Client mode, so that the Tbox can obtain access rights to the local data of each ECU, NFS service is built in each ECU and is in a Server mode, so that the Tbox can share the local data, the Tbox is connected with each ECU through a vehicle-mounted Ethernet, and communication between a Client end and a Server end of the NFS service is achieved. The method comprises the steps that a Tbox receives a data uploading instruction sent by a data platform, data characteristics are obtained through analysis in the data uploading instruction, a target ECU corresponding to the data characteristics is determined, the target ECU is mounted to obtain target data corresponding to the data characteristics, and the target data are uploaded to an FTP server. In the invention, the Tbox mounts the ECU to acquire the target data from the ECU and uploads the target data to the FTP server, so that only the network security of the Tbox in the vehicle is required to be ensured when the system is used, and each ECU is not required to be modified, thereby effectively reducing the development difficulty and the workload, and having higher security.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

FIG. 1 is a method flow diagram of a vehicle data upload method provided in accordance with an exemplary embodiment;

FIG. 2 is a schematic diagram of a data upload flow provided in accordance with an exemplary embodiment;

fig. 3 is a schematic diagram of actively uploading a data file in an abnormal state according to an exemplary embodiment.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

When the vehicle is in an intelligent driving state, if the driving track and the driving state of the vehicle are abnormal, a developer is difficult to locate the cause of the fault only by the fault phenomenon of the vehicle. The failure cause analysis needs to be performed according to the data of relevant intelligent domain ECU (Electronic Control Unit) and relevant sensors (laser radar, millimeter wave radar, camera, etc.) before and after the abnormal time.

The existing data uploading is performed in a mode that each ECU is communicated with a server, so that each ECU is required to have a network access function. The ECU has a networking function and brings hidden danger of network safety, and from the development point of view, a functional design scheme is redundant, and the network safety needs to be additionally considered, so that the development difficulty and workload are increased.

In addition, the networking function of each ECU is realized, and the safety of the whole vehicle network is reduced. Meanwhile, each ECU uploads data to the same FTP (File transfer protocol) server, which may cause a problem of network congestion.

Therefore, the invention provides a vehicle data uploading method, a wireless networking controller and a system. Each ECU on the vehicle is used for collecting and locally storing original data of a sensor carried by the ECU, and storing system running logs, NFS service is built in the Tbox and is set to be in a Client mode, so that the Tbox can obtain access rights to the local data of each ECU, NFS service is built in each ECU and is in a Server mode, so that the Tbox can share the local data, the Tbox is connected with each ECU through a vehicle-mounted Ethernet, and communication between a Client end and a Server end of the NFS service is achieved. The method comprises the steps that a Tbox receives a data uploading instruction sent by a data platform, data characteristics are obtained through analysis in the data uploading instruction, a target ECU corresponding to the data characteristics is determined, the target ECU is mounted, target data corresponding to the data characteristics are obtained, and the target data are uploaded to an FTP server. In the invention, the Tbox mounts the ECU to acquire the target data from the ECU and uploads the target data to the FTP server, so that only the network security of the Tbox in a vehicle is required to be ensured during use, each ECU does not need to be modified, the development difficulty and workload are effectively reduced, and the safety is higher.

In addition, the network connection function of the Tbox is adopted, and the network connection function does not need to be additionally configured for each ECU, so that the network safety of the whole vehicle is improved. Meanwhile, the Tbox transmits data to the FTP server, and network congestion cannot be caused.

On the basis of the above, an embodiment of the present invention provides a vehicle data uploading method, which is applied to a wireless networking controller Tbox in a vehicle.

In this embodiment, each ECU on the vehicle is used for collecting and locally storing original data of a sensor (such as a laser radar, a millimeter wave radar, a camera, and the like) mounted on the vehicle, and storing a system operation log, for example, the data may be stored in an EMMC (Embedded Multi Media Card) or an extended SD Card (Secure Digital Memory Card).

The Tbox is used as a network transceiving node, the ECU system running log and the original data of all the sensors collected by the ECU system running log are stored locally and shared to the Tbox, and the data is uploaded and uploaded in a mode which can be realized by a mode of issuing an instruction by a data platform; when the ECU runs abnormally, the Tbox can also initiate data uploading operation actively.

And setting a network file system NFS service in the Tbox and setting the NFS service as a Client mode so that the Tbox obtains access authority to local data of each ECU.

Specifically, the Tbox dials to get on the internet based on the 4G module. The system is used as the only networking equipment and is mainly responsible for finishing the functions of identity authentication, connection maintenance, instruction receiving, data uploading and the like between the system and a data platform. In addition, the NFS service needs to be built in the Tbox and set as a Client mode to obtain the access right of the Tbox to the local data of each ECU.

And setting up NFS service in each ECU and serving as a Server mode so as to share local data with the Tbox.

Specifically, the ECU is mainly responsible for raw data acquisition and local storage of the sensors mounted on the ECU, and storage of the system operation logs of the ECU. Meanwhile, an NFS service needs to be built in the ECU, set to a Server mode, and share local data to the outside, such as Tbox.

The Tbox is connected with each ECU through a vehicle-mounted Ethernet, and communication between a Client end and a Server end of NFS service is achieved. In detail, the Tbox and each ECU are connected to the same gateway, so that the Tbox and all ECUs are in the same lan and can access each other. During the operation of each ECU, each ECU shares the path of the original data file of each saved system operation log file and sensor to the local area network by running the server process of NFS service. Meanwhile, a client process of the NFS service is also run on the Tbox, and a mount instruction is adopted to try to mount a path shared by the ECUs. If the mounting is successful, the original data files of the sensors on the ECUs and the system operation log files can be checked in the Tbox.

Referring to fig. 1, a vehicle data uploading method may include:

and S11, receiving a data uploading instruction sent by the data platform.

The communication between the data platform and the Tbox is realized based on a message queue telemetry transmission MQTT protocol, and the communication between the data platform and the Tbox is realized by building an MQTTBrker service on the data platform end.

The data platform is mainly responsible for sending data uploading instructions and can appoint different conditions to upload data files.

Under the normal working state, each ECU can continuously record the original data of the sensor carried by the ECU and the system operation log. The data platform cannot know which stored data files exist currently, and the Tbox is used as a unified data uploading node, and needs to send current all file list information to the platform end, so that subsequent operation and maintenance personnel can designate files purposefully for uploading.

In practical application, during the operation of the Tbox, the Tbox can mount the shared partitions shared by the ECUs into the Tbox periodically based on the NFS service, scan files existing on each shared partition, and send newly added file names to the data platform through the MQTT protocol in an incremental detection manner, so that the data platform stores file list information in the form of a database. By the mode of periodic detection and active push, operation and maintenance personnel of the data platform can see the currently stored original data files and system operation log files in each ECU.

When the Tbox periodically scans each shared partition to update the file list, if the mount fails, the mount operation is prohibited, and the cause of the mount failure is recorded in the Tbox running log, and the mount is performed again after the next mount period comes, wherein the cause of the mount failure at least comprises abnormal operation of NFS service or abnormal connection caused by poor contact of vehicle-mounted ethernet cable harnesses.

Specifically, if the mount fails, the mount operation is abandoned, and mount and file screening are performed after the next mount cycle comes. When the mounting fails, the operation log of the Tbox can record the reason of the failure, if the repeated mounting fails all the time, the mounting operation can be abandoned all the time, the situation of the mounting failure all the time occurs, and only field support personnel can investigate the places where the problems possibly occur according to the Tbox log information. The reasons for mount failure include: the NFS service is abnormal in operation, connection is abnormal due to poor contact of vehicle-mounted Ethernet wire harnesses and the like.

The operation and maintenance personnel can specify the content in the data uploading instruction. Such as data upload instructions including device identification and time slices. The device identification comprises an ECU identification and/or a sensor identification, and the time segment is a time period determined by a starting time and an ending time.

Specifically, the data platform side may specify a centralized uploading scheme for data files that is filtered using timestamps. When the data file is screened by taking the timestamp as a condition, the data platform end needs to specify at least one sensor identifier (such as a sensor name) and/or an ECU identifier (such as an ECU name), and a time slice. And after the data uploading instruction is issued to the Tbox, the Tbox automatically mounts the corresponding target ECU shared partition, completely scans the partition and acquires a corresponding data file according to the time segment specified by the platform end. And then uploading the files meeting the conditions to an FTP server one by one, and finally sending topic of data uploading result response to the platform to inform the platform of task completion.

It should be noted that, when the sensor identifier is specified, the uploaded data is the raw sensor data; when the ECU identification is designated, the system operation log of the ECU is uploaded.

In addition, the data upload instruction may also include a device identification and a target file name. Wherein the target file name is selected from a list of file names.

Specifically, the present embodiment may adopt a data centralized uploading scheme based on a file list. The file list based data upload scheme flow is similar to the time based data upload flow.

When data screening is carried out under the condition of the file list, the MQTT instruction issued by the platform end is required to contain a specific sensor identifier and/or ECU identifier and a specific target file name, and the target file name is selected from the file name list. After the MQTT instruction is issued to the Tbox, the Tbox automatically mounts the corresponding ECU shared partition, then uploads the target file to the FTP server according to the specific file name list, and finally sends topic of data uploading result response to the platform to inform the platform of task completion.

In addition, the data upload instructions may also include only a device identification. That is, the present embodiment also supports a data set uploading scheme based on the ECU identifier or the sensor identifier. The data uploading scheme based on the ECU identification or the sensor identification is actually an extension of the uploading scheme based on the timestamp and the file list, and is used for acquiring all data files of the specified sensor and/or the ECU and meeting the requirement of uploading large batches of files. And after the data platform terminal issues the instruction, the Tbox uploads all the designated sensor original data and/or uploads all the designated system operation logs of the ECU.

As can be seen from the above, the data uploading instruction may configure different contents according to the actual scene application, so as to obtain the required data.

And S12, analyzing the data uploading instruction to obtain data characteristics, and determining a target ECU corresponding to the data characteristics.

The data characteristics comprise at least one of equipment identification and data identification to be acquired, the equipment identification comprises ECU identification and/or sensor identification, and the data identification to be acquired comprises a time slice or a target file name. Specific interpretation of the data characteristics can be found in reference to the corresponding description above.

And after the Tbox acquires the equipment identifier, determining the target ECU according to the equipment identifier. If the device identification comprises the ECU identification, the ECU corresponding to the ECU identification is the target ECU. And when the equipment identifier comprises a sensor identifier, the ECU carrying the sensor corresponding to the sensor identifier is the target ECU.

After the data uploading instruction is obtained, analyzing the data uploading instruction to obtain data characteristics, which may include:

and under the condition that the data uploading instruction comprises an equipment identifier and a time slice, acquiring the equipment identifier and the time slice from the data uploading instruction, wherein the equipment identifier comprises an ECU identifier and/or a sensor identifier, and the time slice is a time period determined by a starting time and an ending time.

And under the condition that the data uploading instruction comprises an equipment identifier and a target file name, acquiring the equipment identifier and the target file name from the data uploading instruction, wherein the target file name is selected from a file name list.

For a detailed explanation, reference is made to the corresponding explanations above.

And S13, mounting the target ECU to acquire target data corresponding to the data characteristics, and uploading the target data to a File Transfer Protocol (FTP) server.

Specifically, the target ECU is mounted to acquire the data access authority of the target ECU. And the Tbox replies a negative response to the data platform end if the target ECU is mounted in failure and the corresponding data cannot be acquired.

And then, traversing the data of the equipment corresponding to the equipment identifier from the target ECU under the condition that the data characteristics comprise the equipment identifier and the data identifier to be acquired, and screening out the target data corresponding to the data identifier to be acquired from the data obtained by traversal.

Specifically, under the condition that the data identifier to be acquired is a time segment, referring to fig. 2, the Tbox mounts the target ECU through a mount instruction, the data platform and the Tbox establish MQTT connection, and the Tbox sends the newly added file name to the data platform in a file list form through an MQTT protocol in an incremental detection manner, so that the data platform stores file list information in a database form to obtain a data list. In addition, the data platform can also issue an instruction of uploading a file list, so that the Tbox sends the newly added file name to the data platform through an MQTT protocol in an increment detection mode.

After receiving the data uploading instruction, if the data uploading instruction is pulled based on time segments, the operation and maintenance personnel select a sensor identifier and/or an ECU identifier, then screen data files (the files are named by a timestamp and a device identifier) related to the sensor and/or the ECU from the data platform, determine a starting time and an ending time from the data files, and send the instruction to the Tbox through the MQTT. After receiving the instruction, the Tbox firstly analyzes the instruction to obtain the device identifier and the time slice required to be pulled, and then mounts the ECU where the sensor is located to obtain the file access authority. And finally traversing the data files of the sensor in the mounting point, establishing FTP connection with an FTP server, and uploading the files meeting the time slice specified by the platform to the FTP server one by one through file uploading operation. And (4) uploading the system running logs corresponding to the ECU identification, and informing the platform of finishing the instruction processing after the transmission task is finished.

In the case where the data to be acquired is identified as the target file name, the pull based on the file list is similar to the above-described pull based on the time segment. Firstly, the operation and maintenance personnel select the sensor identification and/or the ECU identification, then view the data file related to the sensor identification and/or the ECU identification from the data platform, pick out the target file name from the file list, and finally send the sensor identification and/or the ECU identification and each target file name to the Tbox through MQTT. The Tbox receives and analyzes the instruction, acquires the sensor identification and/or the ECU identification and the target file name, then traverses the data file of the target ECU in mounting, finds the files matched with the target file name and uploads the files to the FTP server one by one, and after the transmission task is completed, the platform is informed that the instruction processing is completed.

And under the condition that the data features only comprise equipment identification, if the equipment identification is sensor identification, using the original data which is stored by the target ECU and is acquired by the sensor corresponding to the sensor identification as target data.

Specifically, based on the pulling of the sensor identifier, firstly, the operation and maintenance personnel select a target sensor, and the sensor identifier is sent to the Tbox through the MQTT. The Tbox receives the instruction and analyzes to obtain the target sensor field, and because only the sensor identification field exists in the instruction parameter, the Tbox uploads all data files related to the sensor stored by the target ECU to the FTP server, and does not pay attention to the time period or the file list.

And if the equipment identifier is an ECU identifier, taking a system operation log stored by the target ECU as target data. The specific implementation process is similar to the pulling based on the sensor identifier, please refer to the above corresponding description.

Through the modes, operation and maintenance personnel of the data platform can remotely pull the data file or the log file for problem analysis in the later period.

In another implementation manner of the present invention, if the target data corresponding to the data feature cannot be obtained, an acknowledgement is returned to the data platform, and the upload file list with empty content is uploaded to the FTP server.

Specifically, if there is no data satisfying the condition in the designated timestamp or there is no designated file to be uploaded, the Tbox replies an acknowledgement, but the uploaded file list is empty.

In addition, when detecting that an abnormal information file exists in each ECU, the Tbox can upload the abnormal information file to the FTP server, upload a system operation log file closest to the abnormal time to the FTP server by taking a time stamp of the abnormal time as a reference, and send a specific notification message to the data platform after the uploading is finished.

In detail, logic for throwing out the abnormality (such as fault, network break, shutdown and abnormal function) is added in the software design of each ECU of the intelligent driving domain of the whole vehicle, namely, the abnormal condition which possibly occurs is processed and thrown out in the development process. The throwing-out mode is as follows: and generating an abnormal information file in the self-sharing partition, describing the self-defined error reason in the software developer file, and naming the file by using the timestamp of the abnormal moment.

In the actual use process, the Tbox mounts each ECU shared partition periodically to obtain a new file name, and when an abnormal condition occurs in the operation process of each ECU, an abnormal information file is generated in real time to record problem description and problem generation time.

Referring to fig. 3, when the Tbox mounts and scans the shared paths of the ECUs, if such an abnormal information file is found, step Y is executed, the FTP connection is established with the FTP server at the first time, the abnormal information file is actively uploaded to the FTP server through a file uploading operation, and a system operation log file closest to the abnormal information file generation time is uploaded together with a timestamp of the abnormal time. After the uploading is finished, the platform end operation and maintenance personnel are notified through a specific topic, such as MQTT notification, and can see error description and system operation logs at corresponding moments in the first time, so that developers can analyze error reasons and repair the error reasons in time; if the problem analysis needs to be carried out by combining other data, the Tbox can be controlled to acquire a corresponding data file through the MQTT instruction, and the real-time monitoring and response to the abnormity are realized.

And if the abnormal information file is not found, normally executing the step N.

In fig. 2 and 3, the same operation is represented by the same action identifier, such as mount action identifier 1, FTP connection action identifier 5, and the action identifiers of the remaining operations refer to the details of fig. 2 and 3.

In this embodiment, the Tbox mounts the ECU to obtain the target data from the ECU and upload to the FTP server, and then only need guarantee the network security of the Tbox in the vehicle when in use can, no longer need reform transform every ECU, and then effectively reduce the development difficulty and the work load, the security is higher.

In addition, by the invention, all the data files which can be uploaded can complete data transmission with the server through a unified node (Tbox). Compared with the prior art, firstly, the design scheme of the whole architecture can be simplified, the requirement of the whole architecture networking does not need to be considered, and only the Tbox is ensured to have the networking function; secondly, as each ECU in the architecture does not have a network access function, the network security of the ECUs does not need to be considered, and the development work in the aspect of network information security is reduced to a great extent; finally, data uploading nodes in the whole framework are unified to the Tbox, so that operation and maintenance personnel can conveniently pull data files in a centralized mode without independently operating each ECU, and the problem of network congestion can be avoided. In addition, the scheme also supports active pushing of data in an abnormal operation state, so that developers can find problems at the first time and can quickly acquire all data before and after the abnormal time, and analysis of the problems is facilitated.

On the basis of the embodiment of the vehicle data uploading method, another embodiment of the invention provides a wireless networking controller for executing the vehicle data uploading method.

On the basis of the embodiment of the wireless networking controller, another embodiment of the invention provides a vehicle data uploading system, which comprises the wireless networking controller.

Further, the system also comprises a data platform and an FTP server;

the data platform is used for sending a data uploading instruction to the Tbox;

the FTP server is used for receiving the target data sent by the Tbox.

For the specific implementation process of the data platform and the FTP server in this embodiment, please refer to the corresponding description in the above embodiments, which is not described herein again.

In addition, by the invention, all the data files capable of being uploaded can complete data transmission with the server through one unified node (Tbox). Compared with the prior art, firstly, the design scheme of the whole architecture can be simplified, the requirement of the whole architecture networking does not need to be considered, and only the Tbox is ensured to have the networking function; secondly, as each ECU in the architecture does not have a network access function, the network security of the ECUs does not need to be considered, and the development work in the aspect of network information security is reduced to a great extent; finally, data uploading nodes in the whole framework are unified to the Tbox, so that operation and maintenance personnel can conveniently pull data files in a centralized mode without independently operating each ECU, and the problem of network congestion can be avoided. In addition, the scheme also supports active pushing of data in an abnormal operation state, so that developers can find problems at the first time and can quickly acquire all data before and after the abnormal time, and analysis of the problems is facilitated.

While, for purposes of simplicity of explanation, the foregoing method embodiments have been described as a series of acts or combination of acts, it will be appreciated by those skilled in the art that the present invention is not limited by the illustrated ordering of acts, as some steps may occur in other orders or concurrently with other steps in accordance with the invention. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required by the invention.

It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. For the device-like embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The steps in the method of each embodiment of the present invention may be sequentially adjusted, combined, and deleted according to actual needs, and the technical features described in each embodiment may be replaced or combined.

The modules and sub-modules in the device and the terminal of the embodiments of the invention can be combined, divided and deleted according to actual needs.

In the embodiments provided in the present invention, it should be understood that the disclosed terminal, apparatus and method may be implemented in other ways. For example, the above-described terminal embodiments are merely illustrative, and for example, the division of a module or a sub-module is only one logical division, and there may be other divisions when the terminal is actually implemented, for example, a plurality of sub-modules or modules may be combined or integrated into another module, or some features may be omitted or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or modules, and may be in an electrical, mechanical or other form.

The modules or sub-modules described as separate parts may or may not be physically separate, and parts that are modules or sub-modules may or may not be physical modules or sub-modules, may be located in one place, or may be distributed over a plurality of network modules or sub-modules. Some or all of the modules or sub-modules can be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

In addition, each functional module or sub-module in each embodiment of the present invention may be integrated into one processing module, or each module or sub-module may exist alone physically, or two or more modules or sub-modules may be integrated into one module. The integrated modules or sub-modules may be implemented in the form of hardware, or may be implemented in the form of software functional modules or sub-modules.

Those of skill would further appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the components and steps of the various examples have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software unit executed by a processor, or in a combination of the two. The software cells may be located in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "...," or "comprising" does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle data uploading method is characterized in that the method is applied to a wireless internet controller (Tbox) in a vehicle, each Electronic Control Unit (ECU) on the vehicle is used for collecting original data and storing local data of a sensor carried by the ECU, and storing system running logs, a Network File System (NFS) service is built in the Tbox and is set to be a Client mode, so that the Tbox can obtain access right to the local data of each ECU, an NFS service is built in each ECU and is set to be a Server mode, so that the local data can be shared by the Tbox, the Tbox is connected with each ECU through a vehicle-mounted Ethernet, and communication between the Client terminal and the Server terminal of the NFS service is realized;

the vehicle data uploading method comprises the following steps:

2. The method of claim 1, wherein parsing the data upload instructions to obtain data characteristics comprises:

3. The method of claim 1, wherein mounting the target ECU to obtain target data corresponding to the data feature comprises:

mounting the target ECU to acquire the data access authority of the target ECU;

4. The method of claim 1, wherein if mounting the target ECU fails, further comprising:

replying a negative acknowledgement to the data platform;

5. The method of claim 1, further comprising:

based on NFS service, periodically mounting sharing partitions shared by all ECUs into the Tbox, and scanning existing files on each sharing partition;

6. The method according to claim 5, wherein in the periodically mounting the shared partition shared by the ECUs to the Tbox, further comprising:

7. The method of claim 1, further comprising:

8. A wireless networking controller for performing the vehicle data uploading method according to any one of claims 1 to 7.

9. A vehicle data upload system comprising the wireless networking controller of claim 8.

10. The system of claim 9, further comprising a data platform and an FTP server;

the data platform is used for sending a data uploading instruction to the Tbox;

the FTP server is used for receiving the target data sent by the Tbox.