Vehicle uplink data control method, program product, vehicle and vehicle-mounted communication module

Abstract

The invention provides a vehicle uplink data control method, a program product, a vehicle and a vehicle-mounted communication module, and relates to the technical field of communication. According to the method and the device, unified speed control on different file uploading requests of multiple processors can be realized by configuring the maximum sending window size. Particularly, the maximum sending window size of the process is reconfigured based on the uplink time delay of the file after the uplink file of the process is transmitted by utilizing the first-in first-out characteristic of the sending buffer area, so that the uploading speed of the process is matched with the current bandwidth, and the uplink bandwidth and the network time delay are balanced; not only is waste of the uplink bandwidth avoided, but also the problem of high delay caused by full load of the uplink bandwidth is effectively solved. Besides, in the process, the maximum sending window size is directly configured by the sending end, only the upper limit value is configured, the receiving window size requirement of the receiving party can be met, the receiving mode of the receiving end does not need to be changed, and good adaptability is achieved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a vehicle uplink data control method, a program product, a vehicle and a vehicle-mounted communication module. Background Art

[0002] Upload refers to the process of sending data from user devices (such as computers, mobile phones, etc.) to the Internet or other networks. Specifically, uplink is usually used for activities such as uploading files, sending emails, and making video calls.

[0003] In the actual data transmission process, when the uplink bandwidth is occupied by the file transfer task, the uplink messages such as communication establishment and data verification of other processes cannot be sent, which may cause the process to be unable to communicate when the downlink bandwidth is good. Especially with the development of intelligence, more and more log files need to be transmitted by various electronic devices. The unlimited transmission of log files may cause other functions of the electronic device to fail.

[0004] Therefore, how to perform uplink data transmission management is a technical problem that needs to be solved urgently by those skilled in the art. Summary of the invention

[0005] In view of this, an embodiment of the present application provides a vehicle uplink data control method, which can achieve uplink speed management by directly configuring the sending window size for each upload request.

[0006] In a first aspect, the present application provides a vehicle uplink data control method, which is applied to an on-board communication module of a vehicle, the on-board communication module is connected to multiple domain controllers of the vehicle and is used for external communication, and specifically includes: in response to the completion of sending the target uplink file in the sending buffer, determining the uplink delay of the target uplink file at the current moment. Based on the target uplink file, determining the target process corresponding to the target uplink file and the remaining uplink files of the target process from multiple domain controllers. Determining the maximum sending window size of the target process at the current moment based on the uplink delay. Cache the remaining uplink files in the sending buffer based on the maximum sending window size. Send each uplink file cached in the sending buffer.

[0007] In a second aspect, the present application provides a vehicle-mounted communication module, which is arranged in a vehicle, is communicatively connected to multiple domain controllers in the vehicle and communicates externally, and is used to execute the vehicle uplink data control method described in the first aspect for file upload requests in each domain controller.

[0008] In a third aspect, the present application provides a computer program product, including a computer program / instruction, which implements the vehicle uplink data control method described in the first aspect when the computer program / instruction processor is executed. Optionally, the computer program can be stored in a readable storage medium of a computer device or in the cloud; the processor of the computer device reads the computer program from the readable storage medium or the cloud.

[0009] In a fourth aspect, the present application provides a vehicle, comprising: a plurality of domain controllers and an on-board communication module connected to the plurality of domain controllers for communication, wherein the on-board communication module is used to execute the vehicle uplink data control method described in the first aspect for file upload requests in each domain controller.

[0010] The present application provides a vehicle uplink data control method, a program product, a vehicle and an on-board communication module, and relates to the field of communication technology. In the present application, unified speed control of different file upload requests of multiple processors can be achieved by configuring the maximum sending window size. In particular, the present application utilizes the first-in-first-out feature of the sending buffer, and reconfigures the maximum sending window size of the process based on the uplink delay of the file after the uplink file of the process is transmitted, so that the upload speed of the process matches the current bandwidth, thereby achieving a balance between the uplink bandwidth and the network delay, avoiding the waste of uplink bandwidth, and effectively solving the high delay problem caused by the full load of the uplink bandwidth. In addition, in the aforementioned process, the maximum sending window size is directly configured by the sending end, and only its upper limit is configured, which can be compatible with the receiving window size requirements of the receiving end, so that there is no need to change the receiving mode of the receiving end, and it has good adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 It is a data schematic diagram of the vehicle-side data uploading process provided by an exemplary embodiment of the present application.

[0013] Figure 2 It is an exemplary flow chart of a vehicle uplink data control method provided by an exemplary embodiment of the present application.

[0014] Figure 3 It is an exemplary flow chart of a method for determining a sending window size provided by an exemplary embodiment of the present application.

[0015] Figure 4It is an exemplary flow chart of an uplink file caching process provided by an exemplary embodiment of the present application.

[0016] Figure 5 It is an exemplary flow chart of a new file upload request caching process provided by an exemplary embodiment of the present application.

[0017] Figure 6 It is a system module diagram of a vehicle uplink data control system provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0019] Application Overview

[0020] In the prior art, file uplink tasks are generally performed by controlling the transmission speed to ensure redundancy of the uplink bandwidth. With the development of technology, multiple processors may be integrated into electronic devices. When multiple processors share the vehicle communication module, each process in the multiple processors may have uplink requirements. When limiting the speed, they need to be controlled one by one and cannot be uniformly allocated.

[0021] To further illustrate this situation, the present application provides a data schematic diagram of a multi-processor vehicle-side data upload process ( Figure 1 ).in, Figure 1 The vehicle is used as an example to illustrate the communication process of other multi-processor electronic devices. Figure 1 Similarly, adaptive adjustments can be made.

[0022] like Figure 1 As shown, in Figure 1 The process of data uploading is explained in a visual form. Figure 1 The vehicle shown may include multiple domain controllers and vehicle communication modules (represented by sending buffers and sending ports). In addition to the domain controllers, other sensors may also have uplink requirements. For example, Figure 1 The diagram may include an autonomous driving domain controller ACU, a body domain controller BGM, and a cockpit domain controller CDC. In addition, it may also include a traffic sensor TCAM that users use to collect road information.

[0023] It should be noted that not only the aforementioned domain controllers are provided in the vehicle, but the upload process is explained by taking the aforementioned four domain controllers that often have large-size uplink file requirements as an example.

[0024] The present application found that in the actual application of the above-mentioned vehicle, in addition to external network factors, the uplink bandwidth is blocked (also known as high occupancy) due to the large uplink demand, thus affecting other normal uplink demands. For example, the communication establishment message in TCP / IP (such as the synchronization message segment, the synchronization confirmation message segment and the confirmation message segment) may be blocked by the aforementioned uplink bandwidth and cannot be sent, so that the communication connection cannot be established.

[0025] like Figure 1 As shown in the figure, the autonomous driving domain controller, body domain controller, traffic sensor, and cockpit domain controller all have large uplink traffic requirements. Among them, the autonomous driving domain controller, body domain controller, traffic sensor, and cockpit domain controller themselves have log upload and service point upload requirements. In addition, the autonomous driving domain controller has transmission requirements such as intelligent driving data backhaul, intelligent driving car cloud link upload, and SLAM data cloud upload.

[0026] For example, in Figure 1 The data upload tasks of each controller can be seen as gray strip rectangles (such as log upload, service point upload, etc.). Among them, the execution process of each data upload task can be understood as the upward movement of the gray rectangle. That is, the transmission tasks represented by each gray rectangle can cache part of the data in the send buffer, thereby completing the upload through the send buffer and the send port. Specifically, the area where the gray matrix overlaps with the send buffer (marked with a rectangular dotted line) can represent the part of the corresponding file cached in the send buffer. The part above the block can be the part that has been sent, and the part below is the part that has not been sent.

[0027] For the cockpit domain controller, uplink messages that do not involve file transfer / have small data size can be directly transmitted via the sending port.

[0028] However, based on the aforementioned large-volume uplink demand, the entertainment software in the cockpit domain controller may not be able to establish a connection with the corresponding server due to the aforementioned large-volume uplink demand. That is, the cockpit domain controller cannot use online services. Especially when the downlink bandwidth is idle, this situation will seriously affect the user experience.

[0029] Specifically, the high-volume uplink demand can refer to the data transmission demand of the receiving party to determine the message segment when uploading data. The high-volume uplink demand is generally characterized by the transmission demand of a large file to be transmitted, so that in actual transmission, the file needs to be split into multiple messages and sent one by one. Therefore, the receiving party will feedback a confirmation message (usually an acknowledgment character (ACK)) when receiving the corresponding message, so as to send the next message.

[0030] To achieve the transmission of large files, a sending buffer can be configured in the vehicle communication module. The sending buffer is a memory area used by the vehicle communication module to store data to be sent, allowing the sender in the data upload process to send a certain amount of data before waiting for the reception confirmation.

[0031] In order to avoid bandwidth saturation of both parties due to continuous data upload, both parties usually agree on the window size. The sender is recorded as the send window size, and the receiver is recorded as the receive window size. The two are the same and are used to limit the number of messages that have been sent but have not received confirmation characters. That is, on the sender side, the uplink file can be cached in the send buffer with the size of the send window size, waiting for the confirmation character sent back by the receiver.

[0032] In actual applications, considering that the data receiver is generally a server with more data receiving tasks, in order to reasonably allocate the downlink bandwidth, the aforementioned sending window size is often configured by the receiving end, that is, the receiving end can synchronize its receiving window size to the sending end so that the receiving window size is consistent with the sending window size. Therefore, in conventional single-threaded file uplink, serious uplink bandwidth congestion generally does not occur.

[0033] However, in the vehicle, there are a lot of files that need to be uploaded. As mentioned above, without considering the uplink demand of entertainment applications in the cockpit domain controller, the number of uplink tasks with large data volumes for other domain controllers and vehicle communication modules is 11, which will normally occupy about 7MB / s of uplink bandwidth and cannot be controlled by the receiving window of the receiving end.

[0034] In view of this situation, there are mainly two technical directions in the relevant technology:

[0035] First, directly limit the uplink speed of each process. It is difficult to synchronize the uplink speeds of each processor. Individually limiting the speed of each process will waste uplink bandwidth, and in scenarios with low uplink bandwidth, even if the speed is limited to a very low level, it will still cause high latency problems.

[0036] Second, identify the usage scenarios and upload data only in specific scenarios. For example, in some existing technical solutions, high-traffic uplink business applications can only run when the new energy vehicle charging gun is plugged in, which avoids interference with entertainment applications to the greatest extent. However, the immediacy of data for high-traffic uplink business applications (such as smart driving data) cannot be guaranteed.

[0037] The present applicant has found that the above technical solutions are unable to solve the technical problem. In view of this scenario, the present applicant creatively configures the sending window size actively at the sending end, and limits the uplink transmission speed of the corresponding process by directly configuring the maximum sending window size of the process at the on-board communication module.

[0038] Specifically, the present application can achieve unified speed control of different file upload requests of multiple processors by configuring the maximum sending window size. In particular, the present application utilizes the first-in-first-out feature of the sending buffer, and reconfigures the maximum sending window size of the process based on the uplink delay of the file after the uplink file of the process is transmitted, so that the upload speed of the process matches the current bandwidth, thereby achieving a balance between the uplink bandwidth and the network delay, which not only avoids the waste of uplink bandwidth, but also effectively solves the high delay problem caused by the full load of the uplink bandwidth. In addition, in the aforementioned process, the maximum sending window size is directly configured by the sending end, and only its upper limit is configured, which can be compatible with the receiving window size requirements of the receiving end, so there is no need to change the receiving method of the receiving end, and it has good adaptability.

[0039] To further illustrate the vehicle uplink data control method provided by the present application, the following will refer to the attached Figure 2 to Figure 5 Various non-limiting embodiments of the present application will now be described in detail.

[0040] Exemplary vehicle uplink data control method:

[0041] Figure 2 is an exemplary flow chart of a vehicle uplink data control method provided by an exemplary embodiment of the present application. Figure 2 The process P200 shown can be executed by the vehicle communication module.

[0042] like Figure 2 As shown, P200 may include the following steps:

[0043] S210: In response to the target uplink file in the sending buffer being sent completely, determine the uplink delay of the target uplink file at the current moment.

[0044] S220. Determine, based on the target upstream file, from multiple domain controllers, a target process corresponding to the target upstream file and remaining upstream files of the target process.

[0045] S230. Determine the maximum sending window size of the target process at the current moment based on the uplink delay.

[0046] S240: Cache the remaining uplink files in the sending buffer based on the maximum sending window size.

[0047] S250: Send each uplink file cached in the sending buffer.

[0048] Considering that the sending buffer is configured as a first-in-first-out storage area, in order to maintain the sending window size of each process in the sending buffer, the uplink file of the process can be loaded into the sending buffer after the uplink file of the process is transmitted.

[0049] Thus, in the aforementioned S210, the target uplink file may refer to the uplink file that has completed uploading at the current moment. In other words, the aforementioned P200 may be executed in response to the completion of file uploading of each process, thereby adjusting the maximum sending window size of the corresponding process before storing a new uplink file in the sending buffer.

[0050] In some embodiments, the target uplink file can be selected based on the confirmation character (ACK) of the uplink message by the vehicle communication module. Specifically, in response to receiving the uplink file confirmation character, the target uplink file corresponding to the uplink file confirmation character can be determined. Among them, the uplink file confirmation character fed back by the receiving end often carries a message identifier, so that the corresponding message is determined based on the message identifier.

[0051] In addition, considering the data transmission property of the sending buffer, after the aforementioned receiving confirmation character, the target uplink file can be moved out of the sending buffer.

[0052] Uplink latency can refer to the time required for data to be uploaded. In practical applications, uplink latency is generally configured as round-trip time (RTT), which reflects the time required for data to be transmitted from one end of the network to the other. When calculating, round-trip time RTT = sending delay + propagation delay + queuing delay + processing delay.

[0053] The uplink delay of the message in the data buffer can be determined based on the message time and the receiving time of the message, that is, the uplink delay of the target uplink file at the current moment can be determined based on the receiving timestamp in the uplink file confirmation character.

[0054] In some embodiments, the sender puts the data packet into the send buffer and starts sending the data packet. At this time, the sender records the sending time. Then, after receiving the data packet, the receiver sends an ACK (acknowledgement) message to the sender, indicating that the data packet has been successfully received. Finally, after receiving the ACK, the sender calculates the round-trip delay (RTT) based on the sending time and the timestamp in the ACK.

[0055] Specifically, the round-trip time (RTT) is usually determined by the following formula:

[0056] RTT = current time - sending time. The sending time is the timestamp when the sender sends the data packet, and the current time is the timestamp when the sender receives the ACK.

[0057] In the aforementioned S220, the target process may refer to the process corresponding to the target uplink file, that is, the file upload request of the target process includes the target uplink file, and the remaining uplink files may refer to the portion of each uplink file in the file upload request of the target process that has not been cached in the sending buffer.

[0058] In some embodiments, S220 may be executed based on the process identifier in the target upstream file, that is, the corresponding target process may be determined based on the process identifier, thereby calling the remaining upstream files.

[0059] In the aforementioned S230, the maximum sending window size may refer to the maximum sending window size directly configured by the sending end for each uplink process. In the present application, the maximum sending window size may be related to the uplink time, so that when the uplink bandwidth is large, more uplink files are cached, and when the uplink bandwidth is small, fewer uplink files are cached.

[0060] In some embodiments, in order to reasonably configure the maximum sending window size, the uplink speed requirement at the current moment can be determined based on the network conditions and the task transmission requirements of the target process, and the window size can be determined based on the uplink speed requirement and the uplink delay. Generally, the window size = uplink speed requirement × uplink delay. That is, the general maximum window size can be configured as the product of the uplink speed requirement and the uplink delay. Among them, the uplink speed requirement at the current moment can be determined based on the existing bandwidth allocation method or speed limit method.

[0061] In some embodiments, considering the impact of uplink delay on the sending speed, when determining the uplink speed requirement, the ideal upload speed requirement of the process under the ideal delay (such as 50ms) can be determined first, and then corrected based on the uplink delay at the current moment, so as to determine the maximum sending window size. For more information on determining the maximum sending window size, please refer to Figure 3 and its related description.

[0062] In some embodiments, considering the correction of the receiving window size to the sending window size, when determining the maximum sending window size, the adjustment can be made based on the receiving window size. Exemplarily, in response to receiving the sent receiving window size information, the smaller value of the receiving window size information and the aforementioned maximum sending window size can be configured as the new maximum sending window size.

[0063] In the aforementioned S240, considering that the aforementioned P200 can be executed in response to the completion of at least one uplink file transmission of the target process in the sending buffer, an appropriate number of uplink messages can generally be added based on the uploaded uplink messages. In particular, considering that the uplink files of the same process are generally uploaded in sequence, each cache is generally executed in response to the completion of the transmission of an uplink file.

[0064] In some embodiments, considering that the target process often stores uplink files for which no confirmation characters have been received in the sending buffer, when determining the number of cached uplink files, the size of the cached files in the sending buffer of the target process can be determined first. Then, based on the cached file size and the maximum sending window size of the target process at the current moment, the remaining uplink files are cached in the sending buffer. The number of remaining cached uplink files generally matches the difference between the aforementioned maximum sending window size and the cached file size. For more information on determining the number of remaining cached uplink files, see Figure 4 and its related description.

[0065] Based on the above S210 to S240, the uplink files in the sending buffer can be updated and the size of the sending buffer can be adjusted, so that each uplink file cached in the sending buffer is sent based on S250.

[0066] As an exemplary description only, when sending each uplink file cached in the sending buffer, the following steps may be included:

[0067] First, the data is stored in the send buffer: When the application needs to send data, the data will first be copied to the send buffer of the TCP protocol. This buffer is the memory area used in the TCP protocol to store the data to be sent. The function of the send buffer is to temporarily store the data transmitted by the application to the TCP layer.

[0068] Secondly, data transmission: Once the data is stored in the sending buffer, the TCP protocol will decide when and how to send the data based on the network conditions and congestion control strategy. If the number of bytes to be sent is too long, it will be split into multiple TCP packets and sent out; if the number of bytes to be sent is too short, it will wait in the buffer until the buffer length is almost full, or when it is sent out at another appropriate time.

[0069] Next, data confirmation: In the TCP protocol, after receiving a TCP datagram, the other end must ACK (confirm) its sequence number. Only after receiving an ACK for a TCP datagram can the TCP datagram be cleared from the socket's send buffer queue.

[0070] Finally, the data is moved out of the send buffer: When the peer confirms the received data, the sender removes the confirmed data from the send buffer. This process is based on all the rules of TCP data transmission to ensure reliable data transmission.

[0071] The aforementioned vehicle uplink data control method P200 can achieve unified speed control of different file upload requests of multiple processors by configuring the maximum sending window size. In particular, the present application utilizes the first-in-first-out feature of the sending buffer, and reconfigures the maximum sending window size of the process based on the uplink delay of the file after the uplink file of the process is transmitted, so that the upload speed of the process matches the current bandwidth, thereby achieving a balance between the uplink bandwidth and the network delay, which not only avoids the waste of uplink bandwidth, but also effectively solves the high delay problem caused by the full load of the uplink bandwidth. In addition, in the aforementioned process, the maximum sending window size is directly configured by the sending end, and only its upper limit is configured, which can be compatible with the receiving window size requirements of the receiving end, so there is no need to change the receiving method of the receiving end, and it has good adaptability.

[0072] Exemplary send window size determination method:

[0073] To further illustrate the process of determining the maximum sending window size, the present application also provides an exemplary flow chart of a method for determining a sending window size ( Figure 3 ).

[0074] like Figure 3 As shown, process P300 may include the following steps:

[0075] S310: Determine the ideal upload speed requirement of the target process.

[0076] S320: Correct the ideal upload speed requirement based on the uplink delay at the current moment, and determine the current uplink speed requirement of the target process.

[0077] S330: Determine the maximum sending window size of the target process at the current moment based on the current uplink speed requirement and the uplink delay.

[0078] In the aforementioned S310, the ideal upload speed requirement can be determined based on the uplink data requirement of the target process under an ideal delay (such as an uplink delay representing the average level of vehicle-to-cloud communication in a real vehicle, such as 50ms).

[0079] In some embodiments, the ideal upload speed requirement of each process may be calibrated in advance, so that the corresponding ideal upload speed requirement is called based on the name of the process in executing the aforementioned S310.

[0080] In some embodiments, the ideal uplink speed requirement can be calibrated based on the actual requirements of the process. That is, the uplink speed of each process to meet the needs of the corresponding process can be tested under the ideal delay, and it can be configured as the ideal uplink speed requirement. For example, the maximum uplink speed that the server can receive can be determined based on the receiving capacity of the corresponding server as its ideal uplink speed requirement. Therefore, the corresponding call can be made when executing the aforementioned S310.

[0081] In some embodiments, considering the different urgency of file uplink requirements of different domain controllers, the ideal uplink requirements can be adjusted based on the actual needs of the process when configuring. For example, in a vehicle, the Fuel smart driving data backhaul, smart driving car cloud link upload, and SLAM data cloud upload in the smart driving domain controller are all important processes, and their uplink speeds are related to the operating status of the vehicle itself. A larger ideal upload speed requirement can be configured for it. Exemplarily, the ideal uplink speed requirements for Fuel smart driving data backhaul, smart driving car cloud link upload, and SLAM data cloud upload can all be 1.25MB / s.

[0082] In some embodiments, considering that many vehicle data uplink processes (such as log file uploads of various domain controllers) are not urgent and can be uploaded at any time, in order to avoid the impact of such processes on important processes (such as the aforementioned Fuel smart driving data backhaul, smart driving car cloud link upload, and SLAM data cloud upload), when determining the ideal uplink speed requirements, the ideal upload speed requirements for each scenario can be configured based on the combination of different types of processes in each scenario. Correspondingly, when executing the aforementioned S310, the various processes being executed at the current moment can be matched with a plurality of preset scenarios to determine the ideal uplink speed requirements for the process in the corresponding scenario. Among them, in the case of sufficient bandwidth, the ideal uplink speed requirements of 80KB / s to 640KB / s for log upload and service point upload are generally based on the corresponding domain controller.

[0083] As an example scenario only, the ideal uplink speed requirements for each domain controller can be as follows:

[0084] Serial number Domain controller Process Name Expected upload speed requirements 1 ACU Fuel Intelligent Driving Data Feedback 1.25MB / s 2 ACU Smart Driving Cloud Link Upload 1.25MB / s 3 ACU SLAM data on the cloud 1.25MB / s 4 ACU Log upload 640KB / s 5 ACU Service point upload 320KB / s 6 CDC Log upload 160KB / s 7 CDC Service point upload 160KB / s 8 BGM Log upload 320KB / s 9 BGM Service / signal point upload 1.25MB / s 10 TCAM Log upload 160KB / s 11 TCAM Service point upload 80KB / s

[0085] In the aforementioned S320, considering that the delay at the aforementioned moment is generally different from the ideal delay, the ideal upload speed requirement can be corrected based on the current delay, so that the current uplink speed requirement reflects the uplink speed requirement of the target process at the current moment.

[0086] In some embodiments, the difference between the ideal delay corresponding to the ideal upload speed requirement and the uplink delay at the current moment can generally be used for correction. For example, a machine learning model can be used to determine the delay difference under different bandwidths, and then the correction value of the bandwidth can be determined based on the delay. For another example, calibration can also be performed based on common scenarios to determine the correction coefficient under different differences.

[0087] In some embodiments, considering that the present application involves uplink management of vehicle data, the priority can be configured in advance in the uplink process of the actual vehicle, so as to give priority to reserving bandwidth for important processes. Therefore, the aforementioned S320 can also include the following steps:

[0088] S321. Determine the priority correction parameters of the target process.

[0089] S322: Determine a delay correction parameter based on the difference between an ideal delay corresponding to the ideal upload speed requirement and the uplink delay at the current moment.

[0090] S323: Adjust the ideal upload speed requirement based on the priority correction parameter and the delay correction parameter to determine the current uplink speed requirement.

[0091] In some embodiments, the priority correction parameter may refer to a correction to the current speed requirement of the process based on the requirements in the process, which can generally be characterized as a correction ratio and / or a minimum speed limit. In general, the correction ratios of various processes of the same priority are the same to ensure fair competition for bandwidth within the same level. Exemplarily, the correction coefficient of an important process may be 2, that of a generally important process may be 1, and that of an unimportant process may be 0.2.

[0092] In some embodiments, the priority correction parameters of the target process are generally related to the importance of the process. When executing the aforementioned S321, the process priority (quantitative representation of importance) of the target process can be determined first, and then the priority correction parameters configured for different process priorities can be determined.

[0093] In some embodiments, considering that unimportant processes such as log uploads occupy bandwidth, which may affect the upload of important processes when the bandwidth is small, the correction coefficient may also be related to the actual bandwidth, so that when the bandwidth is small, a priority correction parameter of 0 is configured for unimportant processes to directly suspend the corresponding file upload to ensure the upload stability of important processes. Therefore, when executing the aforementioned S321, the priority correction parameter of the process can be determined based on the identification information of the process and the uplink delay at the current moment.

[0094] The minimum speed limit is generally related to the uplink speed requirement of the actual task. For example, during the process of vehicle autonomous driving / assisted driving, in order to ensure the smooth progress of intelligent driving, the related upload process must at least maintain the minimum speed limit.

[0095] The delay correction parameter in the aforementioned S322 can refer to the aforementioned description. The general delay correction parameter can also be configured as a correction ratio of the ideal upload speed requirement.

[0096] That is, in the aforementioned S323, the two correction ratios may be multiplied in sequence with the ideal upload speed requirement to determine the current uplink speed requirement at the current moment.

[0097] In the aforementioned S330, after determining the relevant parameters, the maximum sending window size can be directly calculated. The maximum sending window size is the product of the current uplink speed requirement and the uplink delay.

[0098] As mentioned above, in an uplink delay environment of 50ms, the uplink speed requirements for the Fuel intelligent driving data backhaul in the intelligent driving domain controller, the intelligent driving car cloud link upload, and the SLAM data cloud upload can all be 1.25MB / s. In the sending buffer, the maximum sending window size allocated to the corresponding process can be 1.25MB / s*50ms=64KB.

[0099] In this way, the maximum sending window size of each process can be configured and updated in real time based on the uplink delay during the uplink process.

[0100] Example Uplink File Cache Process:

[0101] To further illustrate the process of caching the remaining uplink messages in the sending buffer, the present application also provides an exemplary flow chart of the uplink file caching process ( Figure 4 ).

[0102] like Figure 4 As shown, process P400 may include the following steps:

[0103] S410: Determine the size of the cached file in the send buffer of the target process.

[0104] S420: Determine whether the maximum sending window size is greater than the cached file size.

[0105] S430: If not, then do not cache the remaining uplink files at the current moment.

[0106] S440: If yes, determine the number of newly added caches based on the size difference between the maximum sending window size and the size of the cached files.

[0107] S450: Cache the remaining uplink files in the sending buffer based on the newly added cache quantity.

[0108] As shown in P400, considering the network fluctuation after the target uplink file is uploaded, the remaining files may not be cached or the number of cached files may be larger. Specifically, it can be achieved by judging the size relationship between the maximum sending window size and the cached file size based on the judgment step of S420. Among them, if the maximum sending window size is larger, it means that there is still space for uplink file cache. If the cached file size is larger, it means that the uplink speed is slow under the current network fluctuation, and the file data in the sending buffer should be reduced, so the file cache is not performed at this time.

[0109] That is, based on the aforementioned S420, it can be clearly seen that the present application can directly respond to network fluctuations and adjust the number of uplink files contained in the sending buffer queue accordingly. In the case of congestion, the number of uplink files contained in the sending buffer queue is reduced, and in the case of smooth network, the number of uplink files contained in the sending buffer queue is increased, so as to achieve a balance between uplink bandwidth and network delay, which not only avoids the waste of uplink bandwidth, but also effectively solves the high delay problem caused by full load of uplink bandwidth.

[0110] In some embodiments, considering that the aforementioned P200 and its related processes all involve control during the process transmission, in order to illustrate the initialization configuration of the process when uploading files, the present application also provides an exemplary flowchart of a newly added file upload request cache process ( Figure 5 ).

[0111] like Figure 5 As shown, process P500 may include the following steps:

[0112] S510: In response to a file upload request of any process in a plurality of domain controllers, determine a plurality of upstream files of the file upload request.

[0113] S520: Determine the uplink delay of the sending buffer at the current moment.

[0114] S530: Determine the maximum sending window size of the process at the current moment based on the uplink delay.

[0115] S540: Cache at least some of the upstream files of the process in a sending buffer based on the maximum sending window size of the process.

[0116] In the aforementioned S510, any process can be understood as the initialization step shown in P500, which can be applicable to the large file upload process of each domain controller. In the subsequent description of P500, the process is any process therein to reflect the initialization configuration of any file upload request.

[0117] During the initialization process of the file upload request, the vehicle communication module can directly receive multiple uplink files from the corresponding domain controller, or it can establish a communication connection based on multiple handshakes and then receive multiple uplink files that need to be uploaded. Among them, considering that high-traffic uplink services generally involve larger files, the overall file (i.e., the total uplink file) can be directly split when requesting transmission to determine the individual uplink files. That is, multiple uplink files are the result of splitting the total uplink file corresponding to the file upload request.

[0118] In the aforementioned S520, different from the aforementioned S210, considering that the process has no transmission history, the uplink delay can also be determined based on the overall situation of the sending buffer. For example, the uplink delay average of each uplink file within a period of time can be determined as the uplink delay at the current moment.

[0119] The above-mentioned S530 and S230 are not described in detail here. The above-mentioned S540 is different from the above-mentioned S240. When caching the uplink file of the new uplink request, the corresponding number of uplink messages can be directly cached continuously based on the maximum sending window size, that is, considering that there is no record of the process in the sending buffer, there is no need to consider the size of the cached file, and the cache can be directly performed.

[0120] Based on the data caching process of P500, when the new process completes data caching, its uplink files will be sent one by one by the sending buffer. Therefore, the process at this time can be understood as the target process involved in P200, so after the uplink file is sent, the process of P200 will continue to be executed until the data is sent.

[0121] Exemplary Systems and Electronic Devices:

[0122] Combination of the above Figures 1 to 5 , describes the method embodiment of the present application in detail, and the device embodiment of the present application is described in detail below. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the part not described in detail can refer to the previous method embodiment.

[0123] The present application also provides a vehicle uplink data control system, including a module for implementing the vehicle uplink data control method provided by the present application. Figure 6 As shown, Figure 6 It is a system module diagram of a vehicle uplink data control system provided by an exemplary embodiment of the present application. The vehicle uplink data control system 600 may include a delay determination module 610, a process determination module 620, a window determination module 630, a file cache module 640 and a file sending module 650.

[0124] The delay determination module 610 may be configured to determine the uplink delay of the target uplink file at the current moment in response to the target uplink file in the sending buffer being sent completely.

[0125] The process determination module 620 may be used to determine a target process corresponding to a target upstream file and remaining upstream files of the target process from multiple domain controllers based on the target upstream file.

[0126] The window determination module 630 may be used to determine the maximum sending window size of the target process at the current moment based on the uplink delay.

[0127] The file cache module 640 may be configured to cache remaining uplink files in a sending buffer based on a maximum sending window size.

[0128] The file sending module 650 can utilize and send each uplink file cached in the sending buffer.

[0129] The present application also provides a vehicle, which includes the vehicle uplink data control system provided by the present application, and can execute the vehicle uplink data control method provided by the present application. The vehicle provided by the present application can be a fully automatic driving vehicle or a semi-automatic driving vehicle. The specific model of the vehicle provided by the present application can be a car, a commercial vehicle, a truck, a bus, a tram, etc.

[0130] Based on the same technical concept, the present application also provides a vehicle, including: multiple domain controllers and a vehicle communication module connected to the multiple domain controllers. The vehicle communication module is used to execute the vehicle air conditioning control method described in any of the above embodiments for the file upload request in each domain controller to control the vehicle air conditioning.

[0131] Based on the same technical concept, the present application also provides a computer program product, which includes a computer program / instruction, and when the computer program / instruction processor is executed, the vehicle uplink data control method as described in any of the above embodiments is implemented.

[0132] The computer program product may be implemented in hardware, software or a combination thereof. In one optional embodiment, the computer program product is embodied as a computer storage medium, and in another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK).

[0133] The method in the present application can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed on a computer, the process or function described in the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, a core network device, an OAM or other programmable device.

[0134] The computer program or instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0135] It should be understood that the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

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

[0137] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A vehicle uplink data control method, characterized in that: The method is applied to an on-board communication module of a vehicle, the on-board communication module is connected to a plurality of domain controllers of the vehicle and is used for external communication, and the method comprises: In response to completion of sending the target uplink file in the sending buffer, determining an uplink delay of the target uplink file at a current moment; Determining, from the multiple domain controllers, a target process corresponding to the target upstream file and remaining upstream files of the target process based on the target upstream file; Determine the maximum sending window size of the target process at the current moment based on the uplink delay; caching the remaining uplink files in the sending buffer based on the maximum sending window size; Each uplink file cached in the sending buffer is sent.

2. The method according to claim 1, characterized in that: The determining the maximum sending window size of the target process at the current moment based on the uplink delay includes: determining an ideal upload speed requirement for the target process; Correct the ideal upload speed requirement based on the uplink delay at the current moment, and determine the current uplink speed requirement of the target process; The maximum sending window size of the target process at the current moment is determined based on the current uplink speed requirement and the uplink delay, wherein the maximum sending window size is the product of the current uplink speed requirement and the uplink delay.

3. The method according to claim 2, characterized in that The correcting the ideal upload speed requirement based on the uplink delay at the current moment to determine the current uplink speed requirement of the target process includes: Determining a priority correction parameter of the target process; Determining a delay correction parameter based on a difference between an ideal delay corresponding to the ideal upload speed requirement and the uplink delay at the current moment; The ideal upload speed requirement is adjusted based on the priority correction parameter and the delay correction parameter to determine the current uplink speed requirement.

4. The method according to claim 1, characterized in that: In response to the target uplink file in the sending buffer being sent completely, determining the uplink delay of the target uplink file at the current moment includes: In response to receiving an uplink file confirmation character, determining a target uplink file corresponding to the uplink file confirmation character; Moving the target uplink file out of the sending buffer; The uplink delay of the target uplink file at the current moment is determined based on the receiving timestamp in the uplink file confirmation character.

5. The method according to claim 1, characterized in that The caching the remaining uplink files in the sending buffer based on the maximum sending window size includes: Determine the size of the cached file of the target process in the sending buffer; The remaining uplink files are cached in the sending buffer based on the cached file size and the maximum sending window size of the target process at the current moment.

6. The method according to claim 5, characterized in that The step of caching the remaining uplink files in the sending buffer based on the cached file size and the maximum sending window size of the target process at the current moment includes: Determining whether the maximum sending window size is greater than the cached file size; If yes, determining the number of newly added buffers based on the size difference between the maximum sending window size and the size of the buffered file, and buffering the remaining uplink files in the sending buffer based on the number of newly added buffers; If not, the remaining uplink files are not cached at the current moment.

7. The method according to claim 1, characterized in that The method further comprises: In response to a file upload request of any process in the multiple domain controllers, determine multiple upstream files of the file upload request, wherein the multiple upstream files are split results of the upstream total file corresponding to the file upload request; Determine the uplink delay of the sending buffer at the current moment; Determine the maximum sending window size of the process at the current moment based on the uplink delay; At least part of the multiple upstream files of the process are cached in the sending buffer based on the maximum sending window size of the process.

8. A vehicle-mounted communication module, characterized in that: The vehicle-mounted communication module is arranged in the vehicle, is communicatively connected with multiple domain controllers in the vehicle and communicates externally, and is used to execute the vehicle uplink data control method described in any one of claims 1-7 for file upload requests in each domain controller.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction processor is executed, the vehicle uplink data control method according to any one of claims 1 to 7 is implemented.

10. A vehicle, characterized in that: The vehicle comprises: Multiple domain controllers; and An on-board communication module communicatively connected to the plurality of domain controllers; Wherein, the on-board communication module is used to execute the vehicle uplink data control method described in any one of claims 1-7 for the file upload request in each domain controller.

Images