Cloud resource evaluation method and device, equipment, storage medium and program product

Abstract

The invention discloses a cloud resource evaluation method and device, equipment, a storage medium and a program product, and relates to the technical field of cloud, the method comprises the following steps: evaluating data uploading tasks of a vehicle at different time periods to obtain preset evaluation parameters, and determining the number of connectable processes of a server according to the performance of the server under a given confidence coefficient; based on the confidence coefficient, determining a queue average length corresponding to the server connectable process number; and comparing the average queue length with the uploading time efficiency requirement, and determining a server resource result. According to the method and the device, the connectable process number of the server is determined by combining the confidence coefficient and the server performance according to the preset evaluation parameter, and then the corresponding queue average length is compared with the uploading time efficiency requirement, so that the required server resource result can be quickly determined. The situation of waste caused by too many resources or data loss caused by too few resources is avoided, so that the server resources can be reasonably configured, and the condition that the data of the vehicle can be transmitted back without causing resource waste is fully ensured.

Description

Technical Field

[0001] The present application relates to the field of cloud technology, and in particular to a cloud resource evaluation method, device, equipment, storage medium and program product. Background Art

[0002] In the intelligent driving industry, data collection has always been the most important part of optimizing algorithms. Currently, more and more data is collected, and some high-value data fragments are selected through certain trigger rules and uploaded to cloud servers through wireless networks. For example, the real-time feedback of high-value problem data during the testing phase, and the upload of shadow mode data of mass-produced vehicles to the cloud storage of original equipment manufacturers (OEMs). These data usually contain output results from sensors, chassis and algorithms, which can help engineers quickly troubleshoot problems and accumulate data to optimize algorithms.

[0003] Generally speaking, the data on the vehicle needs to be uploaded to the cloud in a timely manner, and the cloud also has corresponding server resources for receiving and processing. However, since the trigger is a relatively random event, if the server process resources are considered to be the same as the number of vehicles, it will cause a lot of resource waste; if the resources are too few, a large amount of data will be queued, and if the queue is too long, it will cause the data to be difficult to upload in time and lost. Therefore, in the face of the data backhaul of massive mass-produced vehicles, how to reasonably deal with the consumption of cloud computing resources for data transmission is an urgent problem to be solved. Summary of the invention

[0004] The main purpose of this application is to provide a cloud resource evaluation method, device, equipment, storage medium and program product, which aims to solve the technical problem of how to reasonably deal with the consumption of cloud computing resources for data transmission when facing the data feedback of massive mass-produced vehicles.

[0005] To achieve the above objectives, the present application proposes a cloud resource evaluation method, the method comprising:

[0006] Evaluate the data upload tasks of vehicles at different time periods to obtain preset evaluation parameters;

[0007] Under a given confidence level, determining the number of processes that can be connected to the server according to the preset evaluation parameters and server performance;

[0008] Based on the confidence level, determining an average queue length corresponding to the number of processes connectable to the server;

[0009] The average queue length is compared with the preset upload time requirement to determine the server resource result.

[0010] In one embodiment, the preset evaluation parameters include the number of vehicles that can upload, the average number of triggers, and the data upload duration. The step of evaluating the data upload tasks of the vehicles at different time periods to obtain the preset evaluation parameters includes:

[0011] Evaluate the data upload function of vehicles in the testing phase or mass production phase and determine the number of vehicles that can upload data;

[0012] Based on the triggering rules of the data upload function, statistics are collected on the upload requests triggered by the vehicle to determine the average number of triggering times of the vehicle;

[0013] The data upload duration of the vehicle is calculated based on the upload rate and data packet size of the wireless network of the vehicle.

[0014] In one embodiment, the step of counting the upload requests triggered by the vehicle based on the triggering rule of the data upload function to determine the average number of triggering times of the vehicle includes:

[0015] Based on a preset time period, the upload request triggered by the vehicle is monitored based on the triggering rule of the data upload function to obtain the number of triggers within the preset time period;

[0016] According to the triggering times, counting the total number of triggering times corresponding to each preset time period within a preset duration, the preset duration being greater than the preset time period;

[0017] Based on the preset time period and the preset duration, an average number of triggering times of the vehicle is determined.

[0018] In one embodiment, the step of determining the number of processes that can be connected to the server according to the preset evaluation parameters and server performance under a given confidence level includes:

[0019] Treating the current data receiving process as a queuing service system, wherein the queuing service system includes the transmission data uploaded by the vehicle;

[0020] Evaluate the transmission data according to the preset evaluation parameters and server performance to obtain the queue waiting probability of the queuing service system;

[0021] The queue waiting probability is converted according to a given confidence level to determine the number of server connectable processes corresponding to the confidence level.

[0022] In one embodiment, the step of comparing the average queue length with a preset upload time requirement to determine the server resource result includes:

[0023] Determine whether the average length of the queue meets the preset upload time requirement;

[0024] When the average length of the queue reaches the upload time requirement, it is determined that the current server resources are insufficient, and whether the insufficient amount of the current server resources reaches a preset value;

[0025] When the insufficient amount does not reach the preset value, increasing the server resources according to a preset ratio;

[0026] A server resource result is determined according to the server resource amount and the current server resource.

[0027] In one embodiment, after the step of determining whether the insufficient amount of the current server resources reaches a preset value, the method further includes:

[0028] When the insufficient number reaches the preset value, determining that the number of vehicles that can be uploaded, the average number of trigger times and / or the data upload duration have changed;

[0029] Returning to the step of evaluating the data uploading function of the vehicle in the testing phase or the mass production phase to determine the number of vehicles that can upload data;

[0030] Until the average queue length is less than the upload time requirement, and the current server resources corresponding to the length less than the upload time requirement are taken as the server resource results.

[0031] In addition, to achieve the above purpose, the present application also proposes a cloud resource evaluation device, the device comprising:

[0032] An evaluation parameter module is used to evaluate the data upload tasks of vehicles at different time periods and obtain preset evaluation parameters;

[0033] A process number module, used to determine the number of processes that can be connected to the server according to the preset evaluation parameters and server performance under a given confidence level;

[0034] A queue length module, used to determine the average queue length corresponding to the number of connectable processes of the server based on the confidence level;

[0035] The resource result module is used to compare the average length of the queue with the preset upload time requirement to determine the server resource result.

[0036] In addition, to achieve the above objectives, the present application also proposes a cloud resource evaluation device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the cloud resource evaluation method described above.

[0037] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the cloud resource evaluation method described above are implemented.

[0038] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the cloud resource evaluation method described above are implemented.

[0039] One or more technical solutions proposed in the present application have at least the following technical effects: The cloud resource evaluation method of the present application includes: evaluating the data upload tasks of the vehicle at different time periods to obtain preset evaluation parameters; under a given confidence level, determining the number of processes that can be connected to the server according to the preset evaluation parameters and server performance; based on the confidence level, determining the average length of the queue corresponding to the number of processes that can be connected to the server; comparing the average length of the queue with the preset upload time requirement to determine the server resource result.

[0040] Since this application first evaluates the preset evaluation parameters according to the data upload tasks of the vehicle at different time periods, then determines the number of processes that can be connected to the server in combination with the confidence and server performance, and finally compares the average queue length corresponding to the number of processes that can be connected to the server with the upload time requirement, the required server resource results are quickly determined. This avoids the situation where too many server resources cause waste or too few resources cause data loss, thereby fully ensuring that the vehicle data can be transmitted back without causing resource waste by reasonably configuring the server resource results. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0043] Figure 1 A flowchart of the first embodiment of the cloud resource evaluation method of the present application is provided;

[0044] Figure 2 A flowchart of the second embodiment of the cloud resource evaluation method of the present application is provided;

[0045] Figure 3The overall flow chart for resource evaluation provided in Example 2 of the present application;

[0046] Figure 4 This is a schematic diagram of the module structure of the cloud resource evaluation device according to an embodiment of the present application;

[0047] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the cloud resource evaluation method in the embodiment of the present application.

[0048] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0049] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0050] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0051] It should be noted that the execution subject of this embodiment can be a computing service device with parameter evaluation, process number estimation and resource result determination functions, such as a personal computer, a server, etc., or an electronic device capable of realizing the above functions, a cloud resource evaluation device (such as a cloud server) that executes the cloud resource evaluation method of this application, etc., and this embodiment does not limit this. The following takes the cloud server as an example to illustrate this embodiment and the following embodiments.

[0052] Based on this, the present application embodiment provides a cloud resource evaluation method, referring to Figure 1 , Figure 1 A flowchart of the first embodiment of the cloud resource evaluation method of the present application is provided.

[0053] In this embodiment, the cloud resource evaluation method includes steps S10 to S40:

[0054] Step S10: Evaluate the data uploading tasks of the vehicle at different time periods to obtain preset evaluation parameters.

[0055] It should be noted that different time periods may be different stages in which the vehicle collects data and uploads the data to the cloud server, such as the vehicle testing stage, the vehicle mass production stage, etc., and this embodiment does not limit this.

[0056] It is understandable that the data upload task can be a work task that transmits vehicle data (such as high-value data, vehicle status data, etc.) to a cloud server via a wireless network. These data can be uploaded to the cloud server for optimizing the vehicle.

[0057] Among them, the preset evaluation parameters can be the parameters used for cloud resource evaluation in this embodiment. Since the resources of the cloud server are related to time and data volume, the preset evaluation parameters may include the duration of data uploading to the cloud server, the frequency of data uploading to the cloud server, etc., and this embodiment does not limit this.

[0058] In this embodiment, the cloud server can evaluate the data collected by the vehicle according to the data upload task at different time periods through some prior information or observation results over a period of time, such as the main parameters related to data upload, such as time and data volume, to obtain preset evaluation parameters for subsequent server resource calculations.

[0059] In a feasible implementation manner, the preset evaluation parameters include the number of vehicles that can upload data, the average number of triggering times, and the data upload duration. Step S10 of this embodiment may include the steps of: evaluating the data upload function of vehicles in the testing phase or the mass production phase to determine the number of vehicles that can upload data; based on the triggering rules of the data upload function, counting the upload requests triggered by the vehicle to determine the average number of triggering times of the vehicle; and calculating the data upload duration of the vehicle based on the upload rate and data packet size of the wireless network of the vehicle.

[0060] It should be noted that the testing phase can be a link before the vehicle is officially put into mass production and sales. At this stage, the vehicle's various performance, safety, reliability, etc. will be fully tested and verified. The mass production phase can refer to the stage where large-scale production of vehicles begins after testing and improvement. At this stage, vehicles are mass-produced according to established process flows and standards to meet market demand.

[0061] It should be understood that the data upload function can be the ability of the vehicle to transmit various data generated during its operation, such as driving speed, mileage, engine status, fault information, in-vehicle environment data, etc., to a specific server or data platform in real time or regularly through network communication technology (such as mobile network, Bluetooth, etc.). Vehicles in the testing stage or mass production stage all have this data upload function.

[0062] At the same time, the number of vehicles that can upload data can be the number of vehicles that can use the data upload function, which is recorded in consideration of the possibility of vehicle failure and the possibility that the vehicle's data upload function is damaged due to the failure.

[0063] For example, in order to facilitate understanding of the determination process of the number of vehicles that can be uploaded, this embodiment uses a specific formula calculation to illustrate it. The number of vehicles that can be uploaded m can be determined according to different data upload tasks, and is usually estimated in two ways, as follows:

[0064] During the vehicle testing phase: Generally speaking, the test vehicle is a vehicle invested in R&D. Basically, all vehicles have the upload function, so the number of vehicles that can be uploaded is:

[0065] m = Nσ;

[0066] Among them, N is the total number of vehicles in the test phase, σ is the vehicle failure probability, and m is the number of vehicles that can be uploaded.

[0067] In the mass production stage of vehicles: In this stage, the data is transmitted back to the shadow mode data of mass production vehicles. Generally speaking, the number of vehicles m that can be uploaded is:

[0068] m = Nσζ;

[0069] Among them, N is the total number of vehicles in the mass production stage, ζ is the proportion of mass production vehicles with the data upload function turned on, σ is the probability of vehicle failure, and m is the number of vehicles that can upload data.

[0070] Through the above test method, the number of vehicles that can be uploaded can be estimated m. For the test task, if there are new vehicles put into use, m needs to be updated; for the mass production stage, it can be updated at a certain frequency, usually in months, which is not limited in this embodiment.

[0071] In a feasible implementation manner, for the process of determining the average number of triggering times, the step of counting the upload requests triggered by the vehicle based on the triggering rules of the data upload function described in this embodiment to determine the average number of triggering times of the vehicle includes: monitoring the upload requests triggered by the vehicle based on the triggering rules of the data upload function in units of preset time periods to obtain the number of triggering times within the preset time period; based on the number of triggering times, counting the total number of triggering times corresponding to each preset time period within a preset duration, wherein the preset duration is greater than the preset time period; and determining the average number of triggering times of the vehicle based on the preset time period and the preset duration.

[0072] It should be noted that the trigger rule may be a set condition for the data upload function of the vehicle to determine under what circumstances the vehicle starts to upload data, such as a timing trigger, an event trigger, etc., which is not limited in this embodiment.

[0073] When the vehicle follows the triggering rules and starts uploading data, an upload request can be generated and sent to the cloud server.

[0074] It is understandable that the preset period can be the time frequency of monitoring the upload request, and the trigger count is the number of times the upload request triggers the cloud server within the preset period; for example, monitoring once every hour, monitoring once every two hours, etc., and this embodiment does not limit this. The preset duration is the duration set for data statistics of the preset period, and the total number of triggers is the total number of times the upload request triggers the cloud server within the preset duration; for example, statistics are counted once a day, once every two days, etc., and this embodiment does not limit this.

[0075] The total number of triggers obtained through the monitoring of the above preset time period can be averaged according to the number of triggers in the preset time period to obtain the average number of triggers.

[0076] Exemplarily, in order to facilitate understanding of the determination process of the average number of triggers, this embodiment uses a specific formula calculation to illustrate it. Because certain trigger rules are usually set on the vehicle during the test phase or the mass production phase, when the vehicle triggers these conditions, the recorded data is used for uploading, so the upload itself is a random event. Generally speaking, the number of triggers within a certain period of time satisfies the Poisson distribution, but due to different periods of the day, there will be obvious differences in vehicle operation. For example, there will be more triggers during peak hours in the morning and evening, and fewer at night. In this case, the parameter can be taken as an hour. After a certain period of observation, the total number of triggers of m vehicles per hour within 24 hours of the day is counted and then averaged, that is:

[0077]

[0078] Where T is each hour segment, X(T) is the number of triggers within the hour, and the average here can be obtained to get the average number of times in each hour segment (i.e., the average number of triggers λ).

[0079] In this embodiment, the average number of triggers λ related to the frequency of data upload can be estimated in this way. This parameter is usually related to the trigger rule. If the trigger rule is modified, it needs to be re-estimated. At the same time, through this trigger rule, it is also possible to not upload actual data, but only send an upload request to the cloud server to evaluate the average number of triggers.

[0080] It should be noted that the upload rate can be the speed at which the vehicle uploads data to the cloud server via the wireless network per unit time, which can be expressed as the amount of data transmitted per second (e.g., megabits per second), reflecting the speed at which data is uploaded from the vehicle to the cloud server. The data packet size can be the size of the data unit uploaded by the vehicle to the cloud server via the wireless network. The data upload duration can be the time required for the vehicle to complete the data transmission to the cloud server via the wireless network.

[0081] For example, to facilitate understanding of the determination process of data upload duration, this embodiment uses a specific formula calculation to illustrate it. The vehicle data can be transmitted back to the cloud server via a wireless network, but since the network speed is not stable (for example, 5G, 4G and other network signals), and the size of the data packet may change, the data upload duration obeys an exponential distribution with a parameter of μ, where μ needs to be observed for a certain period of time before calculation, and the calculation method is:

[0082]

[0083] Among them, Size is the data packet size, Rate is the upload rate; μ is the exponential distribution obeyed by the data upload duration, which is the reciprocal of the average data packet size / upload rate.

[0084] If the network operator is changed, or the packet size changes significantly (such as storing more data, changing the packet encapsulation method, etc.), μ needs to be re-estimated.

[0085] In this implementation, the server resources are evaluated using the above-calculated number of uploadable vehicles, average trigger times, and data upload duration, which can improve the accuracy of the evaluation.

[0086] Step S20: Under a given confidence level, the number of processes that can be connected to the server is determined according to the preset evaluation parameters and server performance.

[0087] Step S30: Based on the confidence level, determine the average queue length corresponding to the number of processes that can be connected to the server.

[0088] It should be noted that confidence can be a measure of the credibility or reliability of the results obtained when inferring or estimating the number of connectable processes. Server performance can be the ability to receive vehicle uploaded data, such as computing power, storage capacity, concurrent processing capacity, etc. Server performance can be determined by the number of CPU cores, the number of upload and reception service instances, etc., and this implementation does not impose any restrictions on this.

[0089] It is understandable that the number of processes that can be connected to the server may be the number of processes that the cloud server can simultaneously receive and process to connect to the vehicle.

[0090] In this embodiment, after determining the number of vehicles that can upload, the average number of triggers, and the data upload duration, the number of processes that can be connected to the cloud server is reasonably calculated while ensuring the probability that the data upload can be successfully received with a certain confidence level. When determining the number of processes that can be connected, the corresponding average queue length can also be inferred.

[0091] In a feasible implementation, step S20 of this embodiment may include the steps of: treating the current data receiving process as a queuing service system, the queuing service system including the transmission data uploaded by the vehicle; evaluating the transmission data according to the preset evaluation parameters and server performance to obtain the queue waiting probability of the queuing service system; converting the queue waiting probability according to a given confidence level to determine the number of server connectable processes corresponding to the confidence level.

[0092] It should be noted that the queuing service system is a system for managing the transmission data uploaded by vehicles waiting for service.

[0093] Assume that the cloud server has n process resources that can receive data (i.e., the number of processes that can be connected to the server), and the number of vehicles that can be uploaded for collection and uploading is m. Considering that the number of actual mass-produced vehicles is much larger than the server-related resources (i.e., m>>n). Whenever a vehicle collects a high-value scene (or triggers the vehicle shadow mode, etc.) and applies to upload a data packet, a process immediately receives the transmission data. However, when all n service processes are occupied, the car applying for information transmission will queue up for the upload time. This is a queuing service system with a finite source input stream (i.e., a random service system).

[0094] It can be understood that the queue waiting probability is the probability that when a vehicle uploads transmission data to the cloud server, it may need to enter the queue service system to wait.

[0095] For example, to facilitate understanding of the process of determining the number of processes that can be connected to the server, the embodiment uses a specific formula calculation to illustrate it, as follows:

[0096] 1. Usually within a certain period of time, the number of times a vehicle applies to upload satisfies the Poisson process. It is assumed that during the peak period, the interval between two uploads follows the exponential distribution of the above average number of triggers λ, which is the arrival rate of the Poisson flow in the service system. For different time periods, different λ values ​​are used to perform the following calculations to obtain the server resources required for different time periods.

[0097] Each vehicle is normal at time t, and the probability of triggering upload within (t, t+Δt) is:

[0098] P(x≤t)=1-e -λt ;

[0099] Among them, x represents the variable of the probability of triggering upload, t represents the normal time of the vehicle, λ is the average number of triggers, and Δt is the upload interval; P(x≤t) is the probability of each vehicle triggering upload. It can be seen that the upload interval of this probability obeys the exponential distribution with parameter λ.

[0100] 2. The time length for each vehicle to transmit data follows an exponential distribution with the data upload duration of μ. Therefore, for a vehicle that is transmitting data at time t, the probability of completing the transmission of information within (t, t + Δt) is as follows:

[0101]

[0102] where t represents the normal time of the vehicle, x represents the variable of the triggering upload probability, Δt is the upload interval time; λ is the average number of triggers, o represents a higher-order infinitesimal, and P{t < x ≤ t + Δt|x > t} represents the probability of completing the transmission of information within (t, t + Δt).

[0103] Therefore, the probability of completing the transmission of information within (t, t + Δt) is: (1 - e -λΔt ) = λΔt + o(Δt) (Δt → 0).

[0104] 3. At this time, it can be assumed that the state of the system N(t) = j, which means that exactly j vehicles are transmitting information or waiting to transmit data at time t. Therefore, the state set of the system is:

[0105] {0, 1, 2, ……, m};

[0106] If the system is in state j at time t and transfers to j + 1 within (t, t + Δt) (0 ≤ j < M), it means that among the normal m - j vehicles, one triggers the shadow mode and applies for data transmission within (t, t + Δt), and none of the min(j, n) vehicles that are normally transmitting information have completed the transmission of information. Otherwise, more than two events will occur (each vehicle triggering and applying for upload counts as one event, or one transmission ends). Therefore, based on the above formula, its probability is:

[0107]

[0108] 4. If the system is in state j at time t and transfers to j - 1 within (t, t + Δt) (0 < j ≤ M), it means that within (t, t + Δt), one of the min(j, n) servers that are receiving information has completed the transmission, and none of the normal m - j vehicles have triggered the upload mechanism and there is no upload data. Otherwise, more than two events will occur. Therefore, its probability is:

[0109]

[0110] Then, when in state j at time t, the probability of transferring to i (|j - i| > 1) within (t, t + Δt) is o(Δt). Therefore, N(t) is a finite-source birth-death process, and from the birth-death process, it can be calculated that:

[0111]

[0112] Among them,

[0113]

[0114] The following results can be obtained:

[0115] 1. Probability that the system is busy:

[0116]

[0117] This is the probability that the vehicle end triggers an upload but needs to wait.

[0118] 2. The probability that the queue length of the waiting upload queue is P j (j ≥ n + 1, n + 2, ……, m), that is, the probability that the queue length is j - n. Its average queue length is (L):

[0119]

[0120] 3. According to the principle of first-come, first-served for upload services, the probability of the waiting time can be calculated:

[0121] Let P j (w > x) be the probability that when the vehicle triggers an upload and applies for transmission, under the condition that there are j vehicles uploading and queuing in the system, its waiting time w is greater than x (x ≥ 0), then:

[0122]

[0123] From the condition, P j {w > x} = 0 (j < n), so the above formula can be simplified to:

[0124]

[0125] Among them,

[0126]

[0127] From this, it can be obtained:

[0128]

[0129] This is the probability distribution of the waiting time w required for the vehicle to apply for data transmission, and the average waiting time is:

[0130]

[0131] 4. Assume that when the vehicle triggers and applies for uploading data, the probability that it cannot directly upload information due to being busy is less than α, where α is the confidence level, representing the significance level (for example, α = 0.01, α = 0.005, etc.), then:

[0132]

[0133] Based on the optimization idea, we can find the required number of server connectable processes n, which is the minimum number of connections.

[0134] In this implementation, through the above calculation, under a given confidence level, the actual number of connectable processes can be derived, that is, how many cloud processes are needed for resource scheduling. This is not a simple multiplication operation based on the number of vehicles sold and the amount of uploaded data, but fully considers the uploaded data as a random event, and provides a reasonable derivation process from the perspective of probability distribution.

[0135] Step S40: Compare the average queue length with the preset upload time requirement to determine the server resource result.

[0136] It should be noted that the upload time requirement can be the time limit specified for the vehicle to upload data to the cloud server. The server resource result is the resource result required by the cloud server determined by comparing the average queue length and the upload time requirement. If the average queue length cannot meet the upload time requirement, a new server resource requirement needs to be calculated. If the average queue length can meet the upload time requirement, it remains unchanged.

[0137] In this embodiment, based on the average queue length and the data upload time requirement, the cloud server can continuously estimate whether the current queue will cause a large data loss. Once the upload time requirement is not met, the above parameters can be re-estimated and new server resource requirements can be calculated as the server resource result.

[0138] In the technical solution provided in this embodiment, the cloud server can evaluate the data collected by the vehicle according to the data upload task at different time periods through some prior information or observation results over a period of time, such as the main parameters related to data upload, such as time and data volume, to obtain preset evaluation parameters for subsequent server resource calculation. After determining the number of vehicles that can be uploaded, the average number of triggers, and the length of data upload, the number of server-connectable processes of the cloud server can be reasonably calculated while ensuring the probability that the data upload can be successfully received with a certain confidence level, and the corresponding average queue length can also be inferred. Finally, based on the average queue length and the data upload timeliness requirements, the cloud server can continuously estimate whether the current queue will cause a large data loss. Once the upload timeliness requirements are not met, the above parameters can be re-estimated and the new server resource requirements can be calculated as the server resource results. This implementation evaluates the resources and queue length that the cloud server needs to schedule by combining the number of vehicles that can be uploaded, the average number of triggers, the length of data upload, the trigger rules, the size of the data packet, and other information, and quickly estimates and dynamically adjusts the server resources in combination with the upload timeliness requirements to fully ensure that the data can be returned without additional waste.

[0139] Based on the above first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above first embodiment can refer to the above introduction, and will not be repeated in the following. Figure 2 , Figure 2 A flowchart of the second embodiment of the cloud resource evaluation method of the present application is provided.

[0140] In this example, step S40 includes steps S41 to S44:

[0141] Step S41: Determine whether the average length of the queue reaches a preset upload time requirement.

[0142] Step S42: When the average length of the queue reaches the upload time requirement, it is determined that the current server resources are insufficient, and it is determined whether the insufficient amount of the current server resources reaches a preset value.

[0143] It should be noted that the preset value may be a specific value set to determine that the current server resources are insufficient and it is difficult to process the average queue length.

[0144] Step S43: When the insufficient quantity does not reach the preset value, increase the server resources according to a preset ratio.

[0145] Step S44: Determine the server resource result according to the server resource amount and the current server resources.

[0146] It should be noted that the preset ratio is a preset ratio for increasing the server resources.

[0147] For example, taking the used CPU computing power as an example, if the preset ratio is 20%, if the CPU computing power consumed by the current server is 5Gflops, then an additional 1Gflops is added according to this ratio, and it becomes 6Gflops.

[0148] In this embodiment, the server can first determine whether the average length of the queue meets the preset upload time requirement. If the upload time requirement is not met, it can be determined that the current server resources are insufficient. At this time, it can be determined whether the insufficient amount of the current server resources reaches a preset value. If the insufficient amount does not reach the preset value, the server resources can be increased according to a preset ratio to determine the final server resource result. In this way, server resources can be increased in a planned and proportional manner to better adapt to changes in vehicle data upload.

[0149] Furthermore, after step S43, this example also includes the following steps: when the insufficient number reaches the preset value, determining whether the number of vehicles that can be uploaded, the average number of triggers and / or the data upload duration have changed; returning to execute the step of evaluating the data upload function of vehicles in the testing phase or the mass production phase to determine the number of vehicles that can be uploaded; until the average length of the queue is less than the upload time requirement, and taking the current server resources corresponding to the less than the upload time requirement as the server resource result.

[0150] In the technical solution provided in this embodiment, after obtaining the average queue length L, the data upload timeliness requirement (which can be determined based on actual requirements) can be used. If L is less than the upload timeliness requirement, the current system can be maintained in normal operation; if L is greater than the upload timeliness requirement, it means that the current queue is too long and the server resources are insufficient to process the current upload data request in time, then it is necessary to consider: if the upload timeliness requirement is not met to a small extent, then the server resources are increased in a certain proportion, usually only a small increase in resources is required. If the upload timeliness requirement is not met to a large extent, usually this situation is caused by a large change in the number of vehicles, triggering rules, etc., so at this time, it is necessary to re-estimate the above-mentioned data such as the number of vehicles that can be uploaded, the average number of triggers, and the data upload duration parameters, and calculate the new server resource results based on these parameters. In this way, the use of resources can be controlled to the greatest extent, especially when resources are relatively tight and in the initial construction, or facing large-scale data upload for mass production, resources can be reasonably allocated to ensure that data is transmitted back as much as possible while reducing resource waste.

[0151] For example, in order to help understand the implementation process of the cloud resource evaluation method obtained by combining the above-mentioned embodiment 1 and embodiment 2, please refer to Figure 3 , Figure 3 The overall flow chart for resource evaluation provided in Example 2 of the present application; specifically:

[0152] 1. For the data collection of mass production shadow mode, the car manufacturer can obtain the vehicle sales situation and the vehicle upload function status, and the background can dynamically understand and estimate the number of vehicles that can be uploaded m.

[0153] 2. Based on observations over a certain period of time, it is not necessary to upload actual data, but it is necessary to send an upload request to the cloud to evaluate the number of uploads triggered per hour λ (i.e., the average number of triggers).

[0154] 3. Based on the wireless network rate as a priori and combined with the data packet size, the average data upload duration is actually measured, and tests are conducted at different locations to estimate the data upload duration μ.

[0155] 4. Based on the above formula, the actual number of server resources under a given confidence level is derived, that is, how many cloud processes are needed for resource scheduling. Combined with server performance (CPU core number, performance, number of upload and receive service instances, etc.), the actual server resource requirements (i.e., number of processes) are estimated.

[0156] 5. Estimate the average queue length L under the confidence level, and compare it with the given data upload waiting time requirement (i.e., upload timeliness requirement) in the long term. If the timeliness requirement is not met, expand the server resources at a smaller ratio. If the ratio is greater than a certain value, re-estimate the above parameters and calculate the new server resource requirements.

[0157] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the cloud resource evaluation method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0158] This application also provides a cloud resource evaluation device, please refer to Figure 4 , Figure 4 This is a schematic diagram of the module structure of the cloud resource evaluation device according to an embodiment of the present application; the cloud resource evaluation device comprises:

[0159] An evaluation parameter module 401 is used to evaluate the data upload tasks of the vehicle at different time periods to obtain preset evaluation parameters;

[0160] The process number module 402 is used to determine the number of processes that can be connected to the server according to the preset evaluation parameters and server performance under a given confidence level;

[0161] A queue length module 403, used to determine the average queue length corresponding to the number of processes that can be connected to the server based on the confidence level;

[0162] The resource result module 404 is used to compare the average queue length with the preset upload time requirement to determine the server resource result.

[0163] As an implementation mode, the preset evaluation parameters include the number of vehicles that can upload data, the average number of triggers, and the data upload duration. The evaluation parameter module 401 is also used to evaluate the data upload function of the vehicle in the testing phase or the mass production phase to determine the number of vehicles that can upload data; based on the triggering rules of the data upload function, the upload requests triggered by the vehicle are counted to determine the average number of triggers of the vehicle; based on the upload rate of the wireless network of the vehicle and the data packet size, the data upload duration of the vehicle is calculated.

[0164] As an implementation mode, the evaluation parameter module 401 is also used to monitor the upload request triggered by the vehicle based on the trigger rules of the data upload function in units of preset time periods, and obtain the number of triggers within the preset time period; based on the number of triggers, count the total number of triggers corresponding to each preset time period within the preset duration, and the preset duration is greater than the preset time period; based on the preset time period and the preset duration, determine the average number of triggers of the vehicle.

[0165] As an implementation mode, the process number module 402 is also used to regard the current data receiving process as a queuing service system, wherein the queuing service system includes the transmission data uploaded by the vehicle; the transmission data is evaluated according to the preset evaluation parameters and the server performance to obtain the queue waiting probability of the queuing service system; the queue waiting probability is converted according to a given confidence level to determine the number of server connectable processes corresponding to the confidence level.

[0166] As an implementation mode, the resource result module 404 is also used to determine whether the average length of the queue meets the preset upload time requirement; when the average length of the queue reaches the upload time requirement, it is determined that the current server resources are insufficient, and whether the insufficient amount of the current server resources reaches a preset value; when the insufficient amount does not reach the preset value, the server resource amount is increased according to a preset ratio; based on the server resource amount and the current server resources, the server resource result is determined.

[0167] As an implementation mode, the resource result module 404 is also used to determine, when the insufficient number reaches the preset value, whether the number of vehicles that can be uploaded, the average number of triggers and / or the data upload duration have changed; return to execute the operation of evaluating the data upload function of vehicles in the testing phase or the mass production phase to determine the number of vehicles that can be uploaded; until the average length of the queue is less than the upload time requirement, and the current server resources corresponding to the length that is less than the upload time requirement are used as server resource results.

[0168] Other embodiments or specific implementations of the cloud resource evaluation device of the present application can refer to the above-mentioned method embodiments and will not be repeated here.

[0169] The cloud resource evaluation device provided by the present application adopts the cloud resource evaluation method in the above embodiment, which can solve the technical problem of how to reasonably deal with the consumption of cloud computing resources by data transmission in the face of massive data transmission of mass-produced vehicles. Compared with the prior art, the beneficial effects of the cloud resource evaluation device provided by the present application are the same as the beneficial effects of the cloud resource evaluation method provided by the above embodiment, and the other technical features in the cloud resource evaluation device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0170] The present application provides a cloud resource assessment device (e.g., a cloud server), which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the cloud resource assessment method in the above-mentioned embodiment 1.

[0171] Reference below Figure 5 , Figure 5 The schematic diagram of the device structure of the hardware operating environment involved in the cloud resource evaluation method in the embodiment of the present application shows a schematic diagram of the structure of the cloud resource evaluation device suitable for implementing the embodiment of the present application. The cloud resource evaluation device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The cloud resource evaluation device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0172] like Figure 5 As shown, the cloud resource evaluation device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the cloud resource evaluation device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the cloud resource evaluation device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a cloud resource evaluation device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0173] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0174] The cloud resource evaluation device provided by this application adopts the cloud resource evaluation method in the above embodiment, which can solve the technical problem of how to reasonably deal with the consumption of cloud computing resources by data transmission in the face of massive data transmission of mass-produced vehicles. Compared with the prior art, the beneficial effects of the cloud resource evaluation device provided by this application are the same as the beneficial effects of the cloud resource evaluation method provided by the above embodiment, and the other technical features in the cloud resource evaluation device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0175] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

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

[0177] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the cloud resource evaluation method in the above-mentioned embodiment.

[0178] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0179] The computer-readable storage medium may be included in the cloud resource evaluation device; or may exist independently without being assembled into the cloud resource evaluation device.

[0180] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the cloud resource evaluation device, the cloud resource evaluation device: evaluates the data upload tasks of the vehicle in different time periods to obtain preset evaluation parameters; determines the number of server connectable processes based on the preset evaluation parameters and server performance under a given confidence level; determines the average queue length corresponding to the number of server connectable processes based on the confidence level; compares the average queue length with the preset upload time requirement to determine the server resource result.

[0181] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0182] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0183] The modules involved in the embodiments described in the present application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0184] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned cloud resource evaluation method, and can solve the technical problem of how to reasonably deal with the consumption of cloud computing resources by data transmission in the face of massive data transmission of mass-produced vehicles. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the cloud resource evaluation method provided by the above-mentioned embodiment, and will not be elaborated here.

[0185] The present application also provides a computer program product, including a computer program, which implements the steps of the cloud resource evaluation method as described above when executed by a processor.

[0186] The computer program product provided by this application can solve the technical problem of how to reasonably deal with the consumption of cloud computing resources for data transmission in the face of massive data transmission of mass-produced vehicles. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the cloud resource evaluation method provided by the above embodiment, which will not be repeated here.

[0187] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A cloud resource evaluation method, characterized in that: The method comprises: Evaluate the data upload tasks of vehicles at different time periods to obtain preset evaluation parameters; Under a given confidence level, determining the number of processes that can be connected to the server according to the preset evaluation parameters and server performance; Based on the confidence level, determining an average queue length corresponding to the number of processes connectable to the server; The average queue length is compared with the preset upload time requirement to determine the server resource result.

2. The method according to claim 1, characterized in that The preset evaluation parameters include the number of vehicles that can upload, the average number of triggers, and the data upload duration. The step of evaluating the data upload tasks of the vehicles at different time periods to obtain the preset evaluation parameters includes: Evaluate the data upload function of vehicles in the testing phase or mass production phase and determine the number of vehicles that can upload data; Based on the triggering rules of the data upload function, statistics are collected on the upload requests triggered by the vehicle to determine the average number of triggering times of the vehicle; The data upload duration of the vehicle is calculated based on the upload rate and data packet size of the wireless network of the vehicle.

3. The method according to claim 2, characterized in that The step of counting the upload requests triggered by the vehicle based on the triggering rule of the data upload function to determine the average number of triggering times of the vehicle includes: Based on a preset time period, the upload request triggered by the vehicle is monitored based on the triggering rule of the data upload function to obtain the number of triggers within the preset time period; According to the triggering times, counting the total number of triggering times corresponding to each preset time period within a preset duration, the preset duration being greater than the preset time period; Based on the preset time period and the preset duration, an average number of triggering times of the vehicle is determined.

4. The method according to claim 1, characterized in that The step of determining the number of processes that can be connected to the server according to the preset evaluation parameters and the server performance under a given confidence level includes: Treating the current data receiving process as a queuing service system, wherein the queuing service system includes the transmission data uploaded by the vehicle; Evaluate the transmission data according to the preset evaluation parameters and server performance to obtain the queue waiting probability of the queuing service system; The queue waiting probability is converted according to a given confidence level to determine the number of server connectable processes corresponding to the confidence level.

5. The method according to any one of claims 2 to 4, characterized in that The step of comparing the average queue length with the preset upload time requirement to determine the server resource result includes: Determine whether the average length of the queue meets the preset upload time requirement; When the average length of the queue reaches the upload time requirement, it is determined that the current server resources are insufficient, and whether the insufficient amount of the current server resources reaches a preset value; When the insufficient amount does not reach the preset value, increasing the server resources according to a preset ratio; A server resource result is determined according to the server resource amount and the current server resource.

6. The method according to claim 5, characterized in that After the step of determining whether the insufficient amount of the current server resources reaches a preset value, the method further includes: When the insufficient number reaches the preset value, determining that the number of vehicles that can be uploaded, the average number of trigger times and / or the data upload duration have changed; Returning to the step of evaluating the data uploading function of the vehicle in the testing phase or the mass production phase to determine the number of vehicles that can upload data; Until the average queue length is less than the upload time requirement, and the current server resources corresponding to the length less than the upload time requirement are taken as the server resource results.

7. A cloud resource evaluation device, characterized in that: The device comprises: An evaluation parameter module is used to evaluate the data upload tasks of vehicles at different time periods and obtain preset evaluation parameters; A process number module, used to determine the number of processes that can be connected to the server according to the preset evaluation parameters and server performance under a given confidence level; A queue length module, used to determine the average queue length corresponding to the number of connectable processes of the server based on the confidence level; The resource result module is used to compare the average length of the queue with the preset upload time requirement to determine the server resource result.

8. A cloud resource evaluation device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the cloud resource assessment method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the cloud resource evaluation method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the cloud resource assessment method according to any one of claims 1 to 6 are implemented.

Images