Scheduling method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a scheduling method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring a priority score of each service in each equipment queue; the device queue refers to a queue for aggregating services of different types of identifiers of the same physical device; determining a matching relationship between each service and each equipment queue based on the priority score of each service in each equipment queue and the state of each equipment queue; determining a target polling weight of each device queue in the cross-device coordination queue based on a matching relationship between each service and each device queue; wherein the cross-device coordination queue refers to a queue for aggregating a plurality of physical devices; and based on the target polling weight of each device queue, determining the allocation duration of each device queue. By adopting the method, the resource information of each level in the global situation can be fused, and the accuracy of the scheduling scheme is improved while the cross-level of the scheduling scheme is realized.

Description

Technical Field

[0001] This application relates to the field of scheduling technology, and in particular to a scheduling method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] The power industry's business dispatch system is a core infrastructure supporting the stable operation of the smart grid. Its core task is to achieve efficient resource allocation and real-time response in complex and ever-changing business scenarios.

[0003] In the field of power dispatching, queue scheduling technology has evolved through three stages: The initial fixed priority stage: Hard-coded priority strategies were adopted, with service types strictly bound to queues (e.g., SCADA services were always mapped to high-priority queues). The threshold-triggered dynamic adjustment stage (2010-2018): Priority adjustment mechanisms based on traffic thresholds were introduced (e.g., temporarily increasing priority when queue depth exceeds limits). Representative technologies include Cisco's WRED (Weighted Random Early Detection) algorithm, but its adjustment granularity is coarse (only 3-4 priority levels) and it does not solve the cross-level coordination problem. The intelligent collaborative scheduling exploration stage: Attempts were made to combine SDN (Software Defined Networking) and machine learning technologies to achieve dynamic scheduling.

[0004] However, due to rigid rule design and fragmented decision-making mechanisms, the current scheduling system allows for independent scheduling of queues at different levels, making it impossible to achieve cross-level and cross-business resource collaboration in a dynamic and multi-dimensional environment, resulting in inaccurate scheduling schemes. Summary of the Invention

[0005] Therefore, it is necessary to provide a scheduling method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can achieve cross-level scheduling and improve the accuracy of scheduling schemes, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a scheduling method, the method comprising:

[0007] Obtain the priority score of each service in each device queue; the device queue refers to a queue that aggregates services with different types of identifiers on the same physical device;

[0008] Based on the priority score of each service in each device queue and the status of each device queue, the matching relationship between each service and each device queue is determined;

[0009] Based on the matching relationship between each of the services and each of the device queues, the target polling weight of each device queue in the cross-device coordination queue is determined; wherein, the cross-device coordination queue refers to a queue that aggregates multiple physical devices;

[0010] The allocation duration for each device queue is determined based on the target polling weight of each device queue.

[0011] In one embodiment, obtaining the priority score of each service in each device queue includes:

[0012] Obtain the target feature vector of each of the aforementioned services; each service carries a type identifier;

[0013] For the same type identifier, the target feature vectors are processed according to the fuzzy logic algorithm to obtain the target dynamic weights of each service in each flow queue; wherein, the flow queue refers to the queue that aggregates services with the same type identifier from the same physical device.

[0014] Based on the target dynamic weight of each service in each of the flow queues, the priority score of each service in each of the device queues is determined.

[0015] In one embodiment, the target feature vector includes latency sensitivity, data volume, and fault data; the step of processing each target feature vector according to a fuzzy logic algorithm for the same type identifier to obtain the target dynamic weight of each service in each flow queue includes:

[0016] The membership function is used to determine the level corresponding to the latency sensitivity, the level corresponding to the data volume, and the level corresponding to the fault data for each of the services.

[0017] For the same type identifier, the latency sensitivity level, data volume level, and fault level of each service are processed according to fuzzy rules to determine the initial dynamic weight of each service in each flow queue.

[0018] The initial dynamic weights are defuzzified to obtain the membership function distribution corresponding to the initial dynamic weights;

[0019] Based on the initial dynamic weights of each service and the corresponding membership function distribution, the target dynamic weights of each service in each flow queue are determined.

[0020] In one embodiment, determining the priority score of each service in each device queue based on the target dynamic weight of each service in each flow queue includes:

[0021] Obtain the actual capacity and reference capacity of each of the device queues;

[0022] Based on the target dynamic weight of each service, the actual capacity and reference capacity in each device queue, the priority score of each service in each device queue is determined.

[0023] In one embodiment, the state includes a target queue depth, a target time difference, and a resource utilization rate; wherein, the target queue depth represents the number of services waiting to be scheduled in the device queue; and the target time difference refers to the time difference between a service entering the device queue and the device queue starting processing.

[0024] The step of determining the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue includes:

[0025] When the resource utilization rate of a device queue exceeds a resource threshold, a virtual queue corresponding to the target device queue is created; wherein, the target device queue is the device queue whose resource utilization rate exceeds the resource threshold; the virtual queue occupies the resources of other physical devices besides the physical device where the target device queue is located.

[0026] Based on the priority scores of each service in each device queue and the virtual queue, the target queue depth, target time difference, and resource utilization of each device queue, and the target queue depth, target time difference, and resource utilization of the virtual queue, the distance between each service and each device queue and the virtual queue is determined; the priority score of the virtual queue is the same as the priority score of the target device queue.

[0027] Based on constraints and the distances between each service and each device queue and the virtual queue, the matching relationship between each service and each device queue and the virtual queue is determined; wherein, the constraints represent conditions that constrain at least one of the loads of the device queue and the virtual queue.

[0028] In one embodiment, determining the target polling weight of each device queue in the cross-device coordination queue based on the matching relationship between each service and each device queue includes:

[0029] Based on the matching relationship between each of the services and the device queues and the virtual queues, the load relationship between each of the device queues and the virtual queues is determined;

[0030] Calculate the initial polling weights of each device queue and the virtual queue in the cross-device coordination queue based on the load relationship;

[0031] The initial polling weights are normalized to obtain the target polling weights of each device queue and the virtual queue in the cross-device coordination queue.

[0032] In one embodiment, determining the load relationship between each of the device queues and the virtual queue based on the matching relationship between each of the services and the device queues and the virtual queues includes:

[0033] The load rate is obtained based on the matching relationship between each of the aforementioned services, each of the aforementioned device queues, and the aforementioned virtual queues;

[0034] Based on the aforementioned load rates, determine the average load rate;

[0035] Based on each load rate and the average load rate, the standard deviation of the load rate is obtained;

[0036] The load relationship between each device queue and the virtual queue is determined based on the respective load rates, the average load rate, and the standard deviation of the load rates.

[0037] Secondly, this application also provides a scheduling device, the device comprising:

[0038] The acquisition module is used to acquire the priority score of each service in each device queue; the device queue refers to the queue that aggregates services with different types of identifiers on the same physical device.

[0039] The matching relationship determination module is used to determine the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue;

[0040] The polling weight determination module is used to determine the target polling weight of each device queue in the cross-device coordination queue based on the matching relationship between each service and each device queue; wherein, the cross-device coordination queue refers to a queue that aggregates multiple physical devices;

[0041] The scheduling module is used to determine the allocation duration of each device queue based on the target polling weight of each device queue.

[0042] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0043] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0044] The aforementioned scheduling method, apparatus, computer equipment, computer-readable storage medium, and computer program product determine the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue. Secondly, based on the matching relationship between each service and each device queue, the target polling weight of each device queue in the cross-domain coordination queue is determined. Finally, based on the target polling weight of each device queue, the scheduling scheme, i.e., the allocation duration, for each device queue is determined. By acquiring information between services and queues at different levels (device queues, cross-device coordination queues), i.e., global resource information (service itself, device queues, cross-device coordination queues), the resource information at each level in the global context is integrated based on the global resource information, improving the accuracy of the scheduling scheme while achieving cross-level scheduling. This avoids problems such as high-priority services crowding out device queue resources, leading to unreasonable user scheduling, or cross-device coordination queue polling strategies failing to perceive device load differences, resulting in high scheduling latency during peak periods, which are caused by inaccurate scheduling schemes due to the lack of global resource information at each level. Attached Figure Description

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

[0046] Figure 1 This is a diagram illustrating the application environment of the scheduling method in one embodiment;

[0047] Figure 2 This is a flowchart illustrating the scheduling method in one embodiment;

[0048] Figure 3 This is a schematic diagram of the process for obtaining the priority score of each service in each device queue in one embodiment;

[0049] Figure 4 This is a flowchart illustrating the process of determining the target dynamic weight of each service in each flow queue in one embodiment;

[0050] Figure 5 This is a flowchart illustrating the process of determining the matching relationship between each service and each device queue in one embodiment;

[0051] Figure 6 This is a flowchart illustrating the process of determining the target polling weight of each device queue in the cross-device coordination queue in one embodiment.

[0052] Figure 7This is a flowchart illustrating the process of determining the load relationship between each device queue and the virtual queue in one embodiment;

[0053] Figure 8 This is a structural block diagram of the scheduling device in one embodiment;

[0054] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] The scheduling method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on the cloud or other network servers. Server 104 obtains the priority scores of each service in each device queue; a device queue refers to a queue that aggregates services with different types of identifiers from the same physical device; based on the priority scores of each service in each device queue and the status of each device queue, it determines the matching relationship between each service and each device queue; based on the matching relationship between each service and each device queue, it determines the target polling weight of each device queue in the cross-device coordination queue; where a cross-device coordination queue refers to a queue that aggregates multiple physical devices; based on the target polling weight of each device queue, it determines the allocation duration of each device queue. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Headset devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0057] In one exemplary embodiment, such as Figure 2 As shown, a scheduling method is provided, which is applied to Figure 1 Taking the server in the example, the explanation includes the following steps S202 to S208. Wherein:

[0058] Step S202: Obtain the priority score of each service in each device queue.

[0059] In this context, a device queue refers to a queue that aggregates services with different types of identifiers for the same physical device. For example, a queue aggregating all services with different types of identifiers for the same substation is used to coordinate the proportion of substation resources occupied by services with different types of identifiers. The priority score of each service in each device queue is determined based on the target dynamic weight of each service in each flow queue; where a flow queue refers to a queue that aggregates services with the same type of identifier for the same physical device.

[0060] Suppose there are three physical facilities, such as substations, in a certain area: substation A, substation B, and substation C. Substations A, B, and C form a cross-domain coordination queue. For example, each substation has three service categories: category J1, category J2, and category J3. Category J1, J2, and J3 in each substation form a device queue, and the three substations correspond to three device queues. Each category has three services. Taking category J1 as an example, there are services J11, J12, and J13, forming a flow queue; taking category J2 as an example, there are services J21, J22, and J23, forming another flow queue; and taking category J3 as an example, there are services J31, J32, and J33, forming yet another flow queue.

[0061] Optionally, the server obtains the priority score of each service in each device queue, as shown in Table 1. The priority score is denoted as mij, and the value range of the priority score is (0-1). Here, i represents the index of the device queue, and j represents the index of the service. The matrix shown in Table 1 is updated every 200ms, using a sliding window smoothing process. The sliding window refers to using the results of the most recent N matrix updates; the smoothing method is to take a weighted average of the data within the window, with preset weight coefficients, where the weight coefficients are smaller for more recent matrix updates.

[0062] Table 1. Priority Scoring of Each Service in the Equipment Queues of Each Substation

[0063]

[0064] Step S204: Based on the priority score of each service in each device queue and the status of each device queue, determine the matching relationship between each service and each device queue.

[0065] Optionally, the server retrieves the initial state of each device queue and normalizes it to obtain the state of each device queue. The server then uses a modified Hungarian method to perform matching calculations based on the priority score of each service in each device queue and the state of each device queue, obtaining the distance between each service and each device queue, denoted as cij, as shown in Table 2, where i represents the index of the device queue and j represents the index of the service. Based on the distance cij between each service and each device queue, the matching relationship between each service and each device queue is determined.

[0066] Furthermore, for each service, obtain the maximum value of the distance between the service and each device queue; for example, the maximum value in c11c21c31, the maximum value in c12c32c32, and so on. Mark the position of each maximum value as 1 and the other positions as 0. 1 indicates that the service is occupied by a device queue, and 0 indicates that the service is not occupied by a device queue, which is the final matching relationship between each service and each device queue.

[0067] Table 2 Distances between each service and each device queue

[0068]

[0069] Step S206: Based on the matching relationship between each service and each device queue, determine the target polling weight of each device queue in the cross-device coordination queue.

[0070] Among them, cross-device coordination queues refer to queues that aggregate multiple physical devices.

[0071] Optionally, the server determines the load data of each device queue based on the matching relationship between each service and each device queue, and determines the target round-robin weight of each device queue in the cross-device coordination queue based on the load data of each device queue, denoted as W. i norm The load data includes load rate, average load rate, and load rate standard deviation.

[0072] Traditional methods, based on simple polling or static weighting resource allocation strategies, cannot effectively address the spatiotemporal imbalances in power operations. For example, when a sudden grid failure occurs in a region, fault handling services are forced to queue due to full equipment queues, while adjacent idle equipment queues remain unused. The target polling weights obtained through the aforementioned methods are not simply set but determined in real-time based on resource information at each level of queues, thus ensuring the accuracy of the scheduling scheme.

[0073] Step S208: Determine the allocation duration for each device queue based on the target polling weight of each device queue.

[0074] Optionally, the server uses an improved weighted round-robin (IWRR) algorithm to assign weighted buckets to each device queue, with a bucket size of W. i norm ×100; where W i norm This refers to the target polling weight. Each poll selects queues based on their bucket counts, sorted from largest to smallest. A time slice is allocated to each device queue within a given period. Within the time slice, services are processed according to the queue's internal priority, such as stream queues, device queues, and cross-device coordination queues. The time slice duration is proportional to the target polling weight of the device queue, ensuring that higher-weight queues receive more resources. Bucket counts are reset after all device queue bucket values ​​are reduced to zero. At the end of each period, the time slice is reset, the weights are dynamically updated, and the bucket counts are reset.

[0075] Furthermore, within a certain scheduling period, such as 100ms, the server obtains the target polling weight of device queue A in the cross-device coordination queue. Target polling weight of device queue B in the cross-device coordination queue Target polling weight of device queue C in the cross-device coordination queue Within a 100ms scheduling cycle, the scheduling sequence is as follows: 70ms for equipment queue A, 20ms for equipment queue B, and 10ms for equipment queue C. Executing this scheduling sequence can improve the rationality of scheduling and make full use of power resources at each level.

[0076] The aforementioned scheduling method acquires information between the service and queues at different levels (device queues, cross-device coordination queues), i.e., global resource information (the service itself, device queues, and cross-device coordination queues). Based on this global resource information, it integrates resource information from all levels, improving the accuracy of the scheduling scheme while enabling cross-level scheduling. This avoids problems such as high-priority services crowding out device queue resources, leading to unreasonable user scheduling, or cross-device coordination queue polling strategies failing to perceive device load differences, resulting in high scheduling latency during peak periods—all issues caused by the lack of accurate scheduling schemes due to missing global resource information at all levels.

[0077] In one exemplary embodiment, such as Figure 3 As shown, the priority score of each service in each device queue is obtained, including steps S302 to S306. Wherein:

[0078] Step S302: Obtain the target feature vector of each service; the service carries a type identifier.

[0079] Optionally, the server obtains the type identifier of each service. Simultaneously, it obtains the initial feature vector for each service, which includes latency sensitivity w1, initial data volume w2, and fault data w3.

[0080] Regarding the initial latency sensitivity w1, the server uses a fixed mapping table to obtain the initial latency sensitivity corresponding to the service type (e.g., for protection and control services, w1 = 0.9 by default), where w1 ∈ [0, 1]. Specifically, the fixed mapping table can be obtained according to power industry standards. For example, in the service categories defined in IEC 61850-7-2, when the service category is Service Class 2 and the service type is protection tripping or emergency control command, the latency requirement is extremely high (usually <10ms), and real-time performance and reliability must be ensured. Failures may lead to equipment damage or safety accidents. When the service category is Service Class 0 and the service type is configuration file transmission or historical data query, the corresponding latency is not sensitive (hundreds of milliseconds to seconds of delay are acceptable), does not directly affect the real-time operation of the power grid, and non-real-time transmission is allowed.

[0081] For an initial data volume w2, the server uses a traffic monitoring tool (such as sFlow) to count the number of bytes transmitted in the business flow in real time. The average number of bytes transmitted per second is calculated using a sliding window, updated every minute. The sliding window duration is one minute. The total number of bytes transmitted per second within the sliding window is counted, and then divided by 60 to obtain the average.

[0082] For fault data w3: The fault level is determined by parsing the alarm information from the SCADA system and classifying it according to the fault severity defined in the DL / T 860 standard (normalized from 0 to 1, with 1 representing the highest fault level). Not all services have fault data. In this solution, fault data only applies to fault handling services (such as relay protection actions, circuit breaker trip alarms, etc.). For non-fault services (such as meter reading, environmental monitoring, etc.), w3 is set to 0 by default. Specifically, service tags and fault data are obtained from the alarm information of the SCADA system, and then associated with the specific service flow. Fault data is included in the calculation when calculating the service characteristics of that service flow. A mapping relationship between fault data thresholds and normalized scores can be preset; for example, a voltage drop >10% is marked as a high level, with a normalized score of 0.7.

[0083] Each business process generates an initial feature vector, namely a triplet feature vector W = (w1, w2, w3), with a sampling frequency of 100ms / time. During each 100ms feature generation, w2 uses the latest minute-level average (e.g., the average generated at 10:00:00 is continuously used from 10:00:00 to 10:00:59).

[0084] Furthermore, the server normalizes the initial feature vector; in this scheme, only the data size w2 needs to be normalized. The resulting data size is: The target feature vector is obtained by taking the historical maximum traffic of the business.

[0085] Step S304: For the same type of identifier, process the feature vectors of each target according to the fuzzy logic algorithm to obtain the target dynamic weights of each service in each flow queue.

[0086] In this context, a flow queue refers to a queue that aggregates services with the same type of identifier from the same physical device. Each type of identifier corresponds to a flow queue.

[0087] Optionally, for type identifiers such as J1, the server processes each target feature vector using a fuzzy logic algorithm to obtain the target dynamic weights of each service corresponding to J1 located in the J1 flow queue; for type identifiers such as J2, it processes each target feature vector using a fuzzy logic algorithm to obtain the target dynamic weights of each service corresponding to J2 located in the J2 flow queue; and for type identifiers such as J3, it processes each target feature vector using a fuzzy logic algorithm to obtain the target dynamic weights of each service corresponding to J3 located in the J3 flow queue.

[0088] Step S306: Based on the target dynamic weight of each service in each flow queue, determine the priority score of each service in each device queue.

[0089] Optionally, the server obtains the capability matching coefficient of each device queue for each service. The capability matching coefficient is based on physical device registration information, such as a protocol support list, with a match value of 1 and a non-match value of 0. Based on the target dynamic weight of each service in each flow queue and the capability matching coefficient of each device queue for each service, the priority score of each service in each device queue is determined. The higher the priority score, the lighter the load on the device queue.

[0090] In this embodiment, the target dynamic weight of each service in each flow queue is determined by the target feature vector of each service. Then, based on the target dynamic weight of each service in each flow queue, the priority score of each service in each device queue is determined. This associates the resource information of the two-level queues, the flow queue and the device queue, and realizes a new integration of resources between the flow queue and the device queue.

[0091] In one exemplary embodiment, such as Figure 4 As shown, the target feature vector includes latency sensitivity, data volume, and fault data. For the same type of identifier, each target feature vector is processed according to a fuzzy logic algorithm to obtain the target dynamic weight of each service in each flow queue, including steps S402 to S408. Wherein:

[0092] Step S402: Determine the latency sensitivity level, data volume level, and fault data level for each service based on the membership function.

[0093] Optionally, the server uses the triangular membership function to select the target feature vectors of each service. The data is processed to obtain the latency sensitivity level, data volume level, and fault data level for each service. Each level has three categories: (low, medium, and high).

[0094] Furthermore, taking latency sensitivity w1 as an example, the server determines the center point of the corresponding region based on historical service latency distribution statistics, for example, 0.2, 0.5, 0.7. The server obtains the function width to control the range of the fuzzy transition zone. Based on the center point of the region, the function width, and the triangular membership function, the server determines the latency sensitivity level corresponding to each service.

[0095]

[0096] Similarly, data volume The classification levels are small / medium / large, with center points of 0.3, 0.6, and 0.9; the classification levels of fault level w3 are none / low / high, with center points of 0, 0.4, and 0.8.

[0097] Step S404: For the same type of identifier, process the latency sensitivity level, data volume level, and fault level of each service according to fuzzy rules to determine the initial dynamic weight of each service in each flow queue.

[0098] Optionally, the weighting coefficient for the latency sensitivity level is α, the weighting coefficient for the data volume level is β, and the weighting coefficient for the fault level is γ. The fuzzy rules are pre-defined, and there can be multiple fuzzy rules. Example fuzzy rule 1: IF High latency AND High fault rate THEN α = 0.6, β = 0.0, γ = 0.4; Example fuzzy rule 2: IF Large data volume AND Medium latency THEN α = 0.2, β = 0.5, γ = 0.3.

[0099] Furthermore, for the same type of identifier, the server selects any fuzzy rule as the target rule. Using formula (2), based on the target rule's activation level, the level corresponding to latency sensitivity, the weight coefficient α for the level corresponding to latency sensitivity in the target rule, the level corresponding to data volume, the weight coefficient β for the level corresponding to data volume, and the weight coefficient γ for the level corresponding to faults, the server determines the initial weight W of the service in the flow-to-flow pair corresponding to the same type of identifier. Similarly, the server calculates the initial dynamic weight of each service in its respective flow queue.

[0100]

[0101] In the formula, μ represents the target feature vector; i() represents the activation degree of the target fuzzy rule, which is also the activation degree of the i-th fuzzy rule, where i is the index of the fuzzy rule, specifically the product of the membership degrees of each feature under the target fuzzy rule; α i β i and γ i These are the weight coefficients for the levels corresponding to latency sensitivity, data volume, and fault in fuzzy rule i, respectively.

[0102] For example, if the rule is IF high latency sensitivity AND high fault level THENα_i = 0.6, we can obtain that the membership degree of high latency sensitivity w1 is 0.8 and the membership degree of high fault level w3 is 0.9. Since the rule does not involve the amount of data, w2 is not included in the calculation. Therefore, the corresponding activation degree is 0.8 * 0.9 = 0.72.

[0103] Step S406: Defuzzify the initial dynamic weights to obtain the membership function distribution corresponding to the initial dynamic weights.

[0104] The membership function distribution includes high-priority membership functions, medium-priority membership functions, and low-priority membership functions.

[0105] Optionally, the server uses the centroid method to defuzzify the initial dynamic weights. The server predefines a triangular membership function, also called the output membership function. The vertices and ranges of the output membership function are determined based on power industry dispatch standards and historical data. High priority: vertex 0.8, range 0.6-1.0; medium priority: vertex 0.5, range 0.3-0.7; low priority: vertex 0.3, range 0.0-0.6. The following membership functions are obtained:

[0106] The high-priority membership function is shown in formula (3):

[0107]

[0108] The membership function with medium priority is shown in formula (4):

[0109]

[0110] The low-priority membership function is shown in formula (5):

[0111]

[0112] Optionally, the server will initialize the dynamic weights. Substituting into formulas (3) through (5) respectively, we get...

[0113] arrive Membership function distribution

[0114] Step S408: Based on the initial dynamic weights of each service and the corresponding membership function distribution, determine the target dynamic weights of each service in each flow queue.

[0115] Optionally, the server determines the target dynamic weight of each service in each flow queue based on the initial dynamic weight of each service and the corresponding membership function distribution using formula (6).

[0116]

[0117] In this embodiment, a fuzzy rule base specifically for power business is designed using fuzzy logic algorithms. Priority mapping is adjusted in real time using fuzzy logic to obtain the target dynamic weight of each business in each flow queue to adapt to sudden changes in power business.

[0118] In one exemplary embodiment, the priority score of each service in each device queue is determined based on the target dynamic weight of each service in each flow queue, including: obtaining the actual capacity and reference capacity in each device queue; and determining the priority score of each service in each device queue based on the target dynamic weight of each service, the actual capacity and reference capacity in each device queue.

[0119] The reference capacity is denoted as This is the maximum capacity of the device queue. The actual capacity is denoted as... It represents the actual capacity of the device queue at the current moment.

[0120] Optionally, the server uses the target dynamic weight of each service in each flow queue, the actual capacity and reference capacity in each device queue, and the capability matching coefficient of each device queue for each service, as defined in formula (7), denoted as η. ij The priority score mij for each service in each device queue is determined.

[0121]

[0122] In this embodiment, the priority score of each service in each device queue is determined by the target dynamic weight of each service in each device queue and the actual capacity and reference capacity in each device queue.

[0123] In one exemplary embodiment, such as Figure 5 As shown, the status includes target queue depth, target time difference, and resource utilization rate; where target queue depth represents the number of services waiting to be scheduled in the device queue; target time difference refers to the time difference between a service entering the device queue and the device queue starting processing; based on the priority score of each service in each device queue and the status of each device queue, the matching relationship between each service and each device queue is determined, including steps S502 to S506. Wherein:

[0124] Optionally, the server obtains the initial state of each device's queue, including the initial queue depth (Di), the initial time difference (Ti), and the resource utilization rate (Ri). The server continuously counts the number of services waiting to be scheduled in each device's queue to obtain the initial queue depth D. i The time difference (sliding window mean) between a server's computing task entering the device queue and the start of processing. i The initial time difference is obtained. The server calculates the resource utilization of the device queue based on the number of CPU cores allocated to the device queue, the total number of CPU cores, the used memory, and the total memory. The specific relationship is as follows:

[0125] The initial queue depth Di is normalized to obtain the target queue depth, including: obtaining the historical maximum depth. Based on the initial queue depth Di and the historical maximum depth Determine the target queue depth; specifically through... The target queue depth is calculated. The initial time difference is standardized to obtain the target time difference, including: obtaining the reference time. Based on the initial time difference T i and reference time Determine the target time difference. The reference time is the standard response time specified in the Service Level Agreement (SLA).

[0126] Step S502: When the resource occupancy rate of an existing device queue is greater than the resource threshold, create a virtual queue corresponding to the target device queue.

[0127] Among them, the target device queue is the device queue whose resource utilization rate is greater than the resource threshold; the virtual queue occupies the resources of other physical devices besides the physical device where the target device queue is located.

[0128] Optionally, when the resource utilization of a device queue exceeds a resource threshold, such as R... i If the value is greater than 0.8, create a virtual queue corresponding to the target device queue. If two R values ​​appear... i For target device queues with a value greater than 0.8, two virtual queues are created. The virtual queues inherit attributes from the target queue, such as target queue depth, target time difference, and priority score; however, their resource utilization is reset to 0. Some services are allocated to the virtual queues, but are actually distributed to other physical devices via a load balancer. This avoids scheduling failures due to single-device queue overload (traditional methods directly discard overloaded services), while this application executes overloaded services through other physical devices. When the R value of the target device queue is greater than 0.8, i The corresponding virtual queue is destroyed when the value is less than or equal to 0.6 and there are no pending transactions in the virtual queue.

[0129] Step S504: Based on the priority scores of each service in each device queue and virtual queue, the target queue depth, target time difference, and resource utilization of each device queue, as well as the target queue depth, target time difference, and resource utilization of the virtual queue, determine the distance between each service and each device queue and virtual queue.

[0130] The priority score of the virtual queue is the same as that of the target device queue. The virtual queue acts as an emergency channel, and only one service is allowed to use it at a time.

[0131] Optionally, the server determines the distance between each service and each device queue by using the priority score of each service in each device queue and virtual queue, the target queue depth of each device queue, the target time difference, and the resource utilization rate. The server then determines the distance between each service and the virtual queue by substituting the priority score of each service in the virtual queue, the target queue depth of the virtual queue, the target time difference, and the resource utilization rate into formula (8). As shown in the rows of Table 3, device queue 1 is represented by i1, device queue 2 by i2, device queue 3 by i3, and virtual queue by i4. As shown in the columns of Table 3, each service is represented by i1 to i33. Each element in the table represents the distance between J11 to J33 and i1 to i4.

[0132]

[0133] Table 3. Distances between each service, each device queue, and the virtual queue.

[0134]

[0135] Step S506: Based on the constraints, the distance between each service and each device queue and the virtual queue, determine the matching relationship between each service and each device queue and the virtual queue.

[0136] The constraints represent conditions that constrain at least one of the loads of the device queue and the virtual queue. The constraints are shown in Equation (9). This ensures that scheduling decisions do not increase the load on the device queue. For example: device queue i has a capacity of 1000 services / second, and currently R... i If the percentage is greater than 70%, the maximum allowable allocation is 1000 × (1 - 0.7) = 300 services / second.

[0137]

[0138] Optionally, the server selects the largest 'c' value from each column based on the distance between each service and each device queue and virtual queue, marking it as 1, and other values ​​as 0. 1 indicates that the service is occupied by a device queue, and 0 indicates that the service is not occupied by a device queue. Furthermore, the services marked as 1 in each row cannot exceed the maximum allowed allocation for that row, thus obtaining the matching relationship between each service and each device queue and virtual queue, as shown in Table 4.

[0139] Table 4 shows the matching relationships between various services, device queues, and virtual queues.

[0140]

[0141] In this embodiment, by introducing virtual resource nodes and load constraints, the overload matching problem in power service scheduling is solved, achieving optimal resource matching and reducing conflicts.

[0142] In one exemplary embodiment, such as Figure 6 As shown, based on the matching relationship between each service and each device queue, the target polling weight of each device queue in the cross-device coordination queue is determined, including steps S602 to S606. Wherein:

[0143] Step S602: Based on the matching relationship between each service and device queue and virtual queue, determine the load relationship between each device queue and virtual queue.

[0144] Optionally, the server determines the load relationship between each service and the device queue and the virtual queue based on the matching relationship between each service and the device queue and the virtual queue, as shown in Table 4. i1 represents device queue 1, which is assigned services J11 and J21; i2 represents device queue 2, which is assigned services J13, J21 and J33; i3 represents device queue 3, which is assigned services J21, J31 and J33. Virtual queue i4 is assigned service J12. The server obtains the services assigned to each queue (including device queues and virtual queues) i, and obtains the load relationship between each device queue and the virtual queue, that is, the load relationship of these four i, denoted as B, as shown in formula (10).

[0145]

[0146] In the formula, B represents the load relationship; ε is a smoothing factor to avoid division by zero errors; L i Indicates the load rate of the device queue or virtual queue; This represents the average load rate across multiple queues (device queues and virtual queues); σ L This represents the standard deviation of the load rate.

[0147] Step S604: Calculate the initial polling weights of each device queue and virtual queue in the cross-device coordination queue based on the load relationship.

[0148] Optionally, the server is based on the load relationship B, the smoothing factor ε, and the load rate L of the device queue or virtual queue. i And the queue overload threshold, denoted as L max This indicates that new service allocation is prohibited if the value exceeds this threshold. A possible value is 0.9. Substituting this value into formula (11), the initial polling weights of each device queue and virtual queue in the cross-device coordination queue are calculated. i is the index of the device queue and the virtual queue.

[0149] The initial polling weight is inversely proportional to the load balance degree B. The more unbalanced the load, the greater the adjustment of the initial polling weight. Ensure that lightly loaded queues receive higher weights.

[0150]

[0151] In the formula, L max This indicates the queue overload threshold.

[0152] Step S606: Normalize each initial polling weight to obtain the target polling weight of each device queue and virtual queue in the cross-device coordination queue.

[0153] Optionally, the server assigns initial polling weights W using formula (12). i in After normalization, the target polling weight W of each device queue and virtual queue in the cross-device coordination queue is obtained. i norm .

[0154]

[0155] In this embodiment, the target polling weight is dynamically adjusted based on the balance function to reduce latency fluctuations.

[0156] In one exemplary embodiment, such as Figure 7 As shown, based on the matching relationship between each service and device queue and virtual queue, the load relationship of each device queue and virtual queue is determined, including steps S702 to S708. Wherein:

[0157] Step S702: Based on the matching relationship between each service and each device queue and virtual queue, the load rate is obtained.

[0158] Optionally, the server uses the matching relationship between each service and each device queue and virtual queue as shown in Table 4. i1 represents device queue 1, which is assigned services J11 and J21; i2 represents device queue 2, which is assigned services J13, J21, and J33; i3 represents device queue 3, which is assigned services J21, J31, and J33. Virtual queue i4 is assigned service J12. The load rate L of each device queue or virtual queue is calculated using formula (13). i

[0159]

[0160] In the formula, queue can be i, which can refer to either a virtual queue or a device queue; allocated capacity refers to the services allocated in the queue. This is a reference capacity for the device queue or virtual queue.

[0161] Step S704: Determine the average load rate based on each load rate.

[0162] Optionally, the server is based on each load rate L i The average load factor is calculated using formula (14).

[0163]

[0164] In the formula, n represents the number of device queues and the number of virtual queues.

[0165] Step S706: Based on each load rate and the average load rate, obtain the standard deviation of the load rate.

[0166] Optionally, the server uses formula (15) based on each load rate L i and average load rate Calculate the standard deviation of the load rate σ L .

[0167]

[0168] Step S708: Determine the load relationship between each device queue and the virtual queue based on each load rate, average load rate, and load rate standard deviation.

[0169] Optionally, the server is based on each load rate L i Average load rate and load factor standard deviation σ L The load relationship B between each device queue and the virtual queue is determined as shown in formula (10).

[0170]

[0171] In the formula, B represents the load relationship; ε is a smoothing factor to avoid division by zero errors; L i Indicates the load rate of the device queue or virtual queue; This represents the average load rate across multiple queues (device queues and virtual queues); σ L This represents the standard deviation of the load rate.

[0172] In this embodiment, the load relationship B is obtained based on the matching relationship between each service, each device queue, and the virtual queue. The larger the value of B, the higher the load of the corresponding device queue. The initial polling weight is inversely proportional to the load relationship B, and thus smaller. The polling weight of a high-load device queue will be lower, and the polling weight of a high-load device queue will be higher, in order to achieve load balancing and reduce latency fluctuations.

[0173] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0174] Based on the same inventive concept, this application also provides a scheduling apparatus for implementing the scheduling method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more scheduling apparatus embodiments provided below can be found in the limitations of the scheduling method described above, and will not be repeated here.

[0175] In one exemplary embodiment, such as Figure 8 As shown, a scheduling device is provided, including: an acquisition module 801, a matching relationship determination module 802, a polling weight determination module 803, and a scheduling module 804, wherein:

[0176] The acquisition module 801 is used to acquire the priority score of each service in each device queue; the device queue refers to the queue that aggregates services with different types of identifiers on the same physical device.

[0177] The matching relationship determination module 802 is used to determine the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue.

[0178] The polling weight determination module 803 is used to determine the target polling weight of each device queue in the cross-device coordination queue based on the matching relationship between each service and each device queue; where the cross-device coordination queue refers to a queue that aggregates multiple physical devices.

[0179] The scheduling module 804 is used to determine the allocation duration of each device queue based on the target polling weight of each device queue.

[0180] In an exemplary embodiment, the acquisition module 801 is further configured to acquire the target feature vector of each service; the service carries a type identifier; for the same type identifier, each target feature vector is processed according to a fuzzy logic algorithm to obtain the target dynamic weight of each service in each flow queue; wherein, the flow queue refers to the queue of services with the same type identifier that aggregate the same physical device; based on the target dynamic weight of each service in each flow queue, the priority score of each service in each device queue is determined.

[0181] In an exemplary embodiment, the target feature vector includes latency sensitivity, data volume, and fault data; the acquisition module 801 is further configured to determine the latency sensitivity level, data volume level, and fault data level of each service based on the membership function; for the same type of identifier, the latency sensitivity level, data volume level, and fault level of each service are processed according to fuzzy rules to determine the initial dynamic weight of each service in each flow queue; the initial dynamic weight is defuzzified to obtain the membership function distribution corresponding to the initial dynamic weight; based on the initial dynamic weight and the corresponding membership function distribution of each service, the target dynamic weight of each service in each flow queue is determined.

[0182] In an exemplary embodiment, the acquisition module 801 is further configured to acquire the actual capacity and reference capacity in each device queue; and determine the priority score of each service in each device queue based on the target dynamic weight of each service and the actual capacity and reference capacity in each device queue.

[0183] In an exemplary embodiment, the state includes target queue depth, target time difference, and resource utilization rate; wherein, the target queue depth represents the number of services waiting to be scheduled in the device queue; the target time difference refers to the time difference between a service entering the device queue and the device queue starting processing; the matching relationship determination module 802 is further configured to create a virtual queue corresponding to the target device queue when the resource utilization rate of a device queue is greater than a resource threshold; wherein, the target device queue is a device queue whose resource utilization rate is greater than the resource threshold; the virtual queue occupies the resources of other physical devices besides the physical device where the target device queue is located; the distance between each service and each device queue and the virtual queue is determined based on the priority score of each service in each device queue and the virtual queue, the target queue depth, target time difference, and resource utilization rate of each device queue, and the target queue depth, target time difference, and resource utilization rate of the virtual queue; the priority score of the virtual queue is the same as the priority score of the target device queue; the matching relationship between each service and each device queue and the virtual queue is determined based on the constraints and the distance between each service and each device queue and the virtual queue; wherein, the constraints represent conditions that constrain at least one of the loads of the device queue and the virtual queue.

[0184] In an exemplary embodiment, the polling weight determination module 803 is further configured to determine the load relationship of each device queue and virtual queue based on the matching relationship between each service and device queue and the virtual queue; calculate the initial polling weight of each device queue and virtual queue in the cross-device coordination queue based on the load relationship; and normalize each initial polling weight to obtain the target polling weight of each device queue and virtual queue in the cross-device coordination queue.

[0185] In an exemplary embodiment, the polling weight determination module 803 is further configured to obtain the load rate based on the matching relationship between each service and each device queue and virtual queue; determine the average load rate based on each load rate; obtain the load rate standard deviation based on each load rate and the average load rate; and determine the load relationship between each device queue and virtual queue based on each load rate, the average load rate and the load rate standard deviation.

[0186] Each module in the aforementioned scheduling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0187] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores scheduling-related data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a scheduling method.

[0188] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0189] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0190] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0191] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0192] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0193] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0194] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A scheduling method, characterized in that, The method includes: Obtain the priority score of each service in each device queue; the device queue refers to a queue that aggregates services with different types of identifiers on the same physical device; Based on the priority score of each service in each device queue and the status of each device queue, the matching relationship between each service and each device queue is determined; Based on the matching relationship between each of the services and each of the device queues, the target polling weight of each device queue in the cross-device coordination queue is determined; wherein, the cross-device coordination queue refers to a queue that aggregates multiple physical devices; The allocation duration for each device queue is determined based on the target polling weight of each device queue.

2. The method according to claim 1, characterized in that, The process of obtaining the priority score of each service in each device queue includes: Obtain the target feature vector of each of the aforementioned services; each service carries a type identifier; For the same type identifier, the target feature vectors are processed according to the fuzzy logic algorithm to obtain the target dynamic weights of each service in each flow queue; wherein, the flow queue refers to the queue that aggregates services with the same type identifier from the same physical device. Based on the target dynamic weight of each service in each of the flow queues, the priority score of each service in each of the device queues is determined.

3. The method according to claim 2, characterized in that, The target feature vector includes latency sensitivity, data volume, and fault data; for the same type identifier, processing each target feature vector according to a fuzzy logic algorithm to obtain the target dynamic weight of each service in each flow queue includes: The membership function is used to determine the level corresponding to the latency sensitivity, the level corresponding to the data volume, and the level corresponding to the fault data for each of the services. For the same type identifier, the latency sensitivity level, data volume level, and fault level of each service are processed according to fuzzy rules to determine the initial dynamic weight of each service in each flow queue. The initial dynamic weights are defuzzified to obtain the membership function distribution corresponding to the initial dynamic weights; Based on the initial dynamic weights of each service and the corresponding membership function distribution, the target dynamic weights of each service in each flow queue are determined.

4. The method according to claim 2, characterized in that, The step of determining the priority score of each service in each device queue based on the target dynamic weight of each service in each flow queue includes: Obtain the actual capacity and reference capacity of each of the device queues; Based on the target dynamic weight of each service, the actual capacity and reference capacity in each device queue, the priority score of each service in each device queue is determined.

5. The method according to claim 1, characterized in that, The status includes target queue depth, target time difference, and resource utilization rate; wherein, the target queue depth represents the number of services waiting to be scheduled in the device queue; the target time difference refers to the time difference between a service entering the device queue and the device queue starting processing; The step of determining the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue includes: When the resource utilization rate of a device queue exceeds a resource threshold, a virtual queue corresponding to the target device queue is created; wherein, the target device queue is the device queue whose resource utilization rate exceeds the resource threshold; the virtual queue occupies the resources of other physical devices besides the physical device where the target device queue is located. Based on the priority scores of each service in each device queue and the virtual queue, the target queue depth, target time difference, and resource utilization of each device queue, and the target queue depth, target time difference, and resource utilization of the virtual queue, the distance between each service and each device queue and the virtual queue is determined; the priority score of the virtual queue is the same as the priority score of the target device queue. Based on constraints and the distances between each service and each device queue and the virtual queue, the matching relationship between each service and each device queue and the virtual queue is determined; wherein, the constraints represent conditions that constrain at least one of the loads of the device queue and the virtual queue.

6. The method according to claim 5, characterized in that, The step of determining the target polling weight of each device queue in the cross-device coordination queue based on the matching relationship between each service and each device queue includes: Based on the matching relationship between each of the services and the device queues and the virtual queues, the load relationship between each of the device queues and the virtual queues is determined; Calculate the initial polling weights of each device queue and the virtual queue in the cross-device coordination queue based on the load relationship; The initial polling weights are normalized to obtain the target polling weights of each device queue and the virtual queue in the cross-device coordination queue.

7. The method according to claim 6, characterized in that, The step of determining the load relationship between each of the service queues and the virtual queues based on the matching relationship between each service and the device queue and the virtual queue includes: The load rate is obtained based on the matching relationship between each of the aforementioned services, each of the aforementioned device queues, and the aforementioned virtual queues; Based on the aforementioned load rates, determine the average load rate; Based on each load rate and the average load rate, the standard deviation of the load rate is obtained; The load relationship between each device queue and the virtual queue is determined based on the respective load rates, the average load rate, and the standard deviation of the load rates.

8. A scheduling device, characterized in that, The device includes: The acquisition module is used to acquire the priority score of each service in each device queue; the device queue refers to the queue that aggregates services with different types of identifiers on the same physical device. The matching relationship determination module is used to determine the matching relationship between each service and each device queue based on the priority score of each service in each device queue and the status of each device queue; The polling weight determination module is used to determine the target polling weight of each device queue in the cross-device coordination queue based on the matching relationship between each service and each device queue; wherein, the cross-device coordination queue refers to a queue that aggregates multiple physical devices; The scheduling module is used to determine the allocation duration of each device queue based on the target polling weight of each device queue.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images