A cloud edge collaboration-based production scheduling intelligent management and control system

Abstract

The application relates to the technical field of cloud-edge collaboration, in particular to a production scheduling intelligent management and control system based on cloud-edge collaboration, which comprises a task characteristic aggregation module, which extracts a task type code based on an input task request, queries a task type and calculation amount mapping table in a pre-stored knowledge base, matches the task type and extracts a calculation amount parameter. In the application, the task data packet size, the real-time requirement threshold and the bandwidth benchmark value are linked to calculate the transmission time consumption parameter by dynamically matching the task type and the pre-stored calculation amount mapping relationship, the quantitative mapping of task demand and resource supply is realized, and the parameter deviation caused by traditional artificial experience estimation is eliminated. The CPU occupancy rate value of the edge node process queue is collected in real time, the multi-dimensional node state vector is generated by combining the cloud virtual machine instance quantity and the memory residual quantity data, the limitation of traditional single resource index monitoring is broken through, and the time and space fine granularity of load evaluation is improved.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge collaboration technology, and in particular to a production scheduling intelligent management and control system based on cloud-edge collaboration. Background Technology

[0002] The intelligent production scheduling and control system is a decision optimization platform deployed in a cloud-edge collaborative environment. It is used for dynamic orchestration and fault-tolerant control of production resources (equipment, materials, and manpower) across the entire manufacturing chain. By integrating a global optimization model in the cloud with real-time operating data from the edge, the system achieves closed-loop management of order scheduling, equipment load balancing, fault pre-diagnosis, and energy consumption optimization.

[0003] Current technologies rely on centralized decision-making and lack integration of real-time edge data, resulting in lags in order scheduling and equipment load balancing, making it difficult to handle sudden production tasks or equipment failures. Resource scheduling uses static empirical thresholds as the basis for judgment, without establishing a dynamic correlation mechanism for parameters such as task type, computational load, and transmission time. This easily leads to contradictory phenomena such as resource overload or idleness coexisting, for example, high-priority tasks being delayed due to incorrect bandwidth estimation. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud-edge collaborative intelligent production scheduling and control system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a cloud-edge collaborative intelligent production scheduling and management system includes:

[0006] The task feature aggregation module extracts the task type code based on the input task request, queries the task type and computational quantity mapping table in the pre-stored knowledge base, matches the task type and extracts the computational quantity parameters, generates computational quantity mapping parameters, calculates the transmission time parameters based on the computational quantity mapping parameters, and generates a structured task description.

[0007] The node status retrieval module, based on the task type encoding in the structured task description, collects the CPU utilization value in the current edge node process queue, generates edge load parameters, sends a resource status query request to the cloud, receives the number of available virtual machine instances and the amount of memory remaining returned by the cloud, and generates a node status vector.

[0008] The utility decision index module calculates the local time consumption estimate based on the edge load parameters and cloud memory remaining data in the node state vector, and calculates the cloud time consumption estimate by adding the transmission time parameters in the structured task description based on the computation amount parameters and the number of virtual machine instances, and generates utility index parameters.

[0009] The contingency plan storage module retrieves the associated entries of time consumption threshold and task type in the pre-stored contingency plan library based on the local time consumption estimate and cloud time consumption estimate in the utility index parameters, extracts the set of contingency plan numbers that meet the threshold range, and generates a set of candidate contingency plans.

[0010] Preferably, the steps for obtaining the computational quantity mapping parameters are as follows:

[0011] Based on the input task request, the task type encoding string carried in the task request header field is parsed, and the 3rd to 6th characters in the string are extracted as the core identifier. The task type and computation amount mapping table in the pre-stored knowledge base is traversed, and the core identifier is compared with the complete match of the task type encoding in the mapping table to obtain the locked task type entry.

[0012] Based on the locked task type entries, the upper and lower limit values ​​of the "basic computational quantity numerical range" field defined in the mapping table are extracted to obtain the computational quantity mapping parameters.

[0013] Preferably, the step of obtaining the structured task description is as follows:

[0014] Based on the computational volume mapping parameters, extract the number of bytes in the task data packet size, the real-time requirement threshold, the real-time CPU utilization of edge nodes, and the remaining available memory in the cloud to obtain a set of quadruples parameters;

[0015] Based on the aforementioned quadruple parameter set, the transmission time parameter is calculated;

[0016] The transmission time parameter is combined with the task type encoding and computational quantity mapping parameter to generate a structured task description by field name.

[0017] Preferably, the step of obtaining the edge load parameters is as follows:

[0018] Based on the task type encoding in the structured task description, the process identifier prefix appended at the end is parsed, the edge node operating system interface is called, the fields of all processes in the process queue are traversed, and process instances containing the process identifier prefix are filtered to obtain a set of filtered process instances.

[0019] Based on the selected set of process instances, the CPU utilization of each instance is counted, the average CPU utilization is calculated, and if the average value exceeds a predefined threshold, the process queue overload flag is triggered, and a process queue load summary is generated.

[0020] Based on the process queue load summary, the average CPU utilization is multiplied by the number of processes. If the overload flag is true, a predefined penalty coefficient is added to generate edge load parameters.

[0021] Preferably, the steps for obtaining the node state vector are as follows:

[0022] Based on the task type code in the structured task description, a resource status query request message is constructed. The current timestamp and the hash value of the task type code are added to the message as an authentication token. A query request with a timestamp is sent to the cloud resource management interface to generate a resource query request object.

[0023] Based on the resource query request object, receive the response message returned by the cloud, parse the "number of available virtual machine instances" and "remaining memory" fields in the response data, verify whether the difference between the timestamp in the response message and the local request object is less than the preset timeout threshold, and generate a resource status response dataset.

[0024] Based on the resource status response dataset, if the timestamp validity flag is true, the number of available virtual machine instances and the remaining memory are concatenated into an array in order to generate a node status vector.

[0025] Preferably, the step of obtaining the local time consumption estimate is as follows:

[0026] Obtain the computational complexity parameters and CPU utilization rate from the structured task description;

[0027] Calculate the estimated local latency based on load intensity, computational parameters, and CPU utilization.

[0028] Preferably, the steps for obtaining the utility index parameter are as follows:

[0029] Based on the computational complexity and transmission time parameters in the structured task description, the number of available virtual machine instances is extracted from the node state vector to generate parameter triples.

[0030] Based on the parameter triplet, calculate the cloud time estimation;

[0031] The cloud-based time consumption estimate and the local time consumption estimate are combined to generate a utility index parameter.

[0032] Preferably, the step of obtaining the candidate plan set is as follows:

[0033] Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameters, compare the local time consumption estimate and the cloud time consumption estimate, select the shorter time consumption estimate as the benchmark time consumption reference value, parse the version number and subclass identifier of the task type code in the structured task description, perform SHA-256 hash operation on the benchmark time consumption reference value and the task type code, generate a 128-bit feature vector, and use it as the query index key of the pre-stored plan library;

[0034] Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored contingency plan library is called. With the baseline time reference value as the center value, all related entries are retrieved within a ±15% fluctuation range. Entries with complete matching task type codes and contingency plan status marked as "available" are filtered out. The search results are sorted in descending order by contingency plan heat value, where contingency plan heat value = number of calls in the last 7 days × priority coefficient, to generate a preliminary matching contingency plan set.

[0035] Based on the preliminary matching plan set, the metadata description field of each plan is extracted. If the predicted start-up time of a plan is less than 1.2 times the baseline time reference value, it is retained as a valid candidate plan. The numbers of all valid plans are merged and deduplicated to generate a candidate plan set.

[0036] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0037] This invention dynamically matches the mapping relationship between task type and pre-stored computational load, linking task data packet size, real-time requirement threshold, and bandwidth benchmark value to calculate transmission time parameters. This achieves a quantitative mapping between task demand and resource supply, eliminating parameter bias caused by traditional manual estimation. Real-time collection of CPU utilization values ​​from edge node process queues, combined with cloud virtual machine instance count and remaining memory data, generates multi-dimensional node state vectors, overcoming the limitations of traditional single resource indicator monitoring and improving the spatiotemporal granularity of load assessment. Based on edge load parameters, computational load parameters, and CPU utilization, a dual assessment mechanism for local and cloud computational time is constructed. Through dynamic adaptation of transmission time aggregation and virtual machine instance count, a utility index parameter is formed, enhancing the real-time performance and environmental adaptability of task distribution decisions. Combining time threshold range matching and heat value sorting from the pre-stored contingency plan library, a candidate contingency plan set is generated, achieving deep coupling between the contingency plan selection process and real-time operating status, shortening the decision-making response cycle in abnormal scenarios. Attached Figure Description

[0038] Figure 1 This is a system flowchart of the present invention;

[0039] Figure 2 This is a flowchart of the steps for obtaining the computational quantity mapping parameters in this invention;

[0040] Figure 3 This is a flowchart of the steps for obtaining the structured task description in this invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0042] Please see Figure 1 This invention provides a technical solution: a cloud-edge collaborative intelligent production scheduling and management system comprising:

[0043] The task feature aggregation module extracts the task type code based on the input task request, queries the task type and computation amount mapping table in the pre-stored knowledge base, matches the task type and extracts the computation amount parameters, generates computation amount mapping parameters, calculates the transmission time parameters based on the computation amount mapping parameters, and generates a structured task description.

[0044] The node status retrieval module, based on the task type encoding in the structured task description, collects the CPU utilization value in the current edge node process queue, generates edge load parameters, sends a resource status query request to the cloud, receives the number of available virtual machine instances and the amount of memory remaining returned by the cloud, and generates a node status vector.

[0045] The utility decision index module calculates the local time consumption estimate based on the edge load parameters in the node state vector and the remaining cloud memory data. It also calculates the cloud time consumption estimate by overlaying the transmission time parameters in the structured task description with the computation quantity parameters and the number of virtual machine instances, and generates utility index parameters.

[0046] The contingency plan storage module retrieves the associated entries of time consumption threshold and task type in the pre-stored contingency plan library based on the local time consumption estimate and cloud time consumption estimate in the utility index parameters, extracts the set of contingency plan numbers that meet the threshold range, and generates a set of candidate contingency plans.

[0047] Please see Figure 2 The steps for obtaining the computational quantity mapping parameters are as follows:

[0048] Based on the input task request, the task type encoding string carried in the task request header field is parsed, and the 3rd to 6th characters in the string are extracted as the core identifier. The task type and computation amount mapping table in the pre-stored knowledge base is traversed, and the core identifier is compared with the complete match of the task type encoding in the mapping table to obtain the locked task type entry.

[0049] Based on the locked task type entries, extract the upper and lower limit values ​​of the "basic computational quantity numerical range" field defined in the mapping table to obtain the computational quantity mapping parameters.

[0050] Specifically, based on the input task request, the system first performs a parsing operation, specifically reading the header of the request message. This header encapsulates multiple metadata items according to a predetermined protocol format. The system locates the field named "TaskTypeCode" and extracts its string value. In this embodiment, a specific task request header may contain the field "TaskTypeCode: VTAN01OBJREC001". The system extracts the complete encoded string "VTAN01OBJREC001". Next, the system performs a truncation operation on this string, extracting the 3rd to 6th characters as the core identifier according to the rules. For the example string "VTAN01OBJREC001", the truncation operation will yield "AN01", which is the core type identifier of the task. Subsequently, the system accesses a pre-built and stored knowledge base, which maintains a "task type and computational load mapping table". This table establishes the association between task types and their required computational resource quantification indicators, and its structure is as follows:

[0051] Table 1. Example of Task Type and Computational Load Mapping

[0052]

[0053] As shown in Table 1, this table lists the codes, core identifiers, descriptions, and corresponding basic computational ranges for different task types. The system performs an exact match between the previously extracted core identifier "AN01" and each record in the "Core Identifier" column of the table. When a record in the table has a "Core Identifier" field value that is exactly the same as "AN01", that record is identified as a "locked task type record". In this example, the system will lock the first record (task type code VTAN01OBJREC). After locking the record, the system extracts data from that record. The specific value of the "Basic Computation Range" field is retrieved, that is, the values ​​of the "Basic Computation Lower Limit (Gops)" and "Basic Computation Upper Limit (Gops)" columns are searched and read. For the locked "AN01" entry, the extracted lower limit value is 1.5 Gops and the upper limit value is 3.0 Gops. The combination of these two values ​​(in this embodiment, forming an array containing two elements or an object with two attributes, such as [1.5, 3.0] or {min: 1.5, max: 3.0}) constitutes the computation mapping parameters required for this task request.

[0054] Please see Figure 3 The steps for obtaining a structured task description are as follows:

[0055] Based on the computational load mapping parameters, extract the number of bytes in the task data packet size, the real-time requirement threshold, the real-time CPU utilization of edge nodes, and the remaining available memory in the cloud to obtain a set of four-tuple parameters;

[0056] Based on the quadruple parameter set, the transmission time parameter is calculated using the following formula:

[0057]

[0058] Where Q is the number of bytes in the task data packet, D is the real-time requirement threshold, E is the CPU utilization rate of the edge node, C is the preset bandwidth baseline value, M is the remaining amount of available memory in the cloud, G is the system's predefined memory baseline constant, and T is the transmission time parameter.

[0059] Combine the transmission time parameter with the task type encoding and computation amount mapping parameters to generate a structured task description by field name.

[0060] Specifically, based on the computational complexity mapping parameters obtained in the previous step, in this embodiment, it is a numerical range.

[0061] [1.5, 3.0] Gops, the system further performs information extraction operations, which requires obtaining a set of specific parameters from the more detailed data payload of the task request or the associated metadata. This set of parameters constitutes a quadruple, specifically including: the number of bytes Q of the task data packet size, which is obtained by reading the length attribute of the request payload in this embodiment, and is 1,048,576 bytes (i.e., 1MB) in this embodiment; the real-time requirement threshold D, which is mapped from the priority or quality of service (QoS) field of the task request in this embodiment, and requires a processing latency of no more than 50 milliseconds in this embodiment; and the real-time CPU of the edge node. CPU utilization rate E is obtained by querying the operating system monitoring interface of the edge node currently executing the decision logic in this embodiment. In this embodiment, the current CPU utilization rate is 65%. The remaining available memory M in the cloud is obtained by calling the cloud platform resource management API in this embodiment. In this embodiment, the current remaining available memory of the target cluster or node in the cloud is 2048GB. The system integrates these four values ​​(1048576, 50, 65, 2048) to form a quadruple parameter set. Next, based on this quadruple parameter set and two preset system constants, the transmission time parameter T is calculated. The calculation needs to be based on the following formula:

[0062]

[0063] Before performing the calculation, it is necessary to determine the preset constants in the formula: the preset bandwidth reference value C and the system predefined memory reference constant G. The setting of C should refer to the network conditions of the system deployment environment. In this embodiment, if the system is deployed in a typical 5G edge network environment, C can be set to 100Mbps (i.e., 100,000,000bps). However, to simplify the calculation, the unit of C in this embodiment corresponds to the unit of Q (bytes), and the magnitude needs to be adjusted, or it can be understood as an abstract reference value related to the transmission rate, which here is related to Q (bytes) and D (...). In conjunction with milliseconds, C is set as an empirical adjustment value, 500,000 in this embodiment (this value needs to be determined based on the actual network model and unit uniformity; this is only an example). G is set with reference to the typical memory configuration of a single computing node in the system or the memory granularity managed by the entire cluster; in this embodiment, G is set to 128GB. Now, the obtained parameter values ​​and the set constant values ​​are substituted into the formula for calculation: Q = 1048576, D = 50, E = 65, C = 500,000, M = 2048, G = 128. The calculation process is as follows:

[0064] First, calculate the radical part of the denominator of the first term:

[0065] Then calculate the denominator of the first term:

[0066] Next, calculate the logarithmic part of the numerator of the first term:

[0067] Calculate the numerator of the first term:

[0068] Calculate the value of the first term:

[0069] Then calculate the denominator of the second term: D+1 = 50 + 1 = 51.

[0070] Calculate the integer part of the numerator of the second term:

[0071] Calculate the absolute value of the numerator in the second term:

[0072] Calculate the value of the second term:

[0073] Finally, T is calculated as: T≈1.47235+19580.0=19581.47235. The calculated transmission time parameter T is 19581.47 milliseconds. The system then combines this calculated transmission time parameter T=19581.47 with the task type code parsed from the task request (“VTAN01OBJREC001” in this embodiment) and the computational load mapping parameter obtained in the first step ([1.5, 3.0] Gops in this embodiment). A structured data object is generated according to predefined field names (such as TaskCode, ComputationParams, TransmissionTimeEstimate). In this embodiment, a JSON object is: {"TaskCode": "VTAN01OBJREC001",}

[0074] The object "ComputationParams": [1.5, 3.0], "TransmissionTimeEstimate": 19581.47} is the structured task description.

[0075] Detailed explanation of formula T:

[0076] formula Used to estimate the time or cost associated with task transmission.

[0077] Parameter description:

[0078] Q: Task data packet size in bytes, indicating the size of the task input data.

[0079] D: Real-time requirement threshold (milliseconds). The smaller the value, the higher the real-time requirement.

[0080] E: Real-time CPU utilization (percentage) of edge nodes, indicating the busy level of edge nodes.

[0081] C: Preset bandwidth baseline value, representing a benchmark reference for network transmission capacity.

[0082] M: Remaining available memory in the cloud (GB), reflecting the availability of cloud resources.

[0083] G: System-defined memory baseline constant (GB) used to normalize the impact of cloud memory.

[0084] ln: Natural logarithm function.

[0085] Square root operation.

[0086] |·|: Absolute value operation.

[0087] The function to round down.

[0088] T: The calculated transmission time parameter.

[0089] Operational logic:

[0090] The formula consists of two main parts added together.

[0091] Part One Attempting to simulate key transmission times or costs:

[0092] molecular The data volume Q is the base, multiplied by an adjustment factor. This factor increases with the product of real-time requirement D and edge node load E, but its growth rate decreases through the natural logarithm ln. This means that when D·E is high, its effect on increasing transmission time decreases marginally. This may simulate the nonlinear impact of network congestion or processing bottlenecks on the transmission of high-requirement, high-load tasks.

[0093] denominator The base bandwidth C is the core, multiplied by an adjustment factor. The more MB of cloud memory there is relative to the baseline GB, the better. The larger the value, the larger the denominator, resulting in a decrease in the first part of the calculated T. This may reflect the improved task reception and initial processing capabilities due to the abundance of cloud resources, thereby indirectly reducing the perceived "transmission time." (Square root) This means that the benefits of increasing memory M are also diminishing.

[0094] Part Two It is a penalty or adjustment item:

[0095] molecular Calculate the absolute difference between the task data volume Q and one-tenth (rounded) of the bandwidth baseline C. This represents the degree of mismatch between the data volume and a certain threshold of network capacity; the larger the difference, the higher the penalty.

[0096] Denominator D+1: The higher the real-time requirement D (the larger the value, the lower the requirement), the larger the denominator, and the smaller the penalty for this term. Conversely, the higher the real-time requirement (the smaller D), the larger the penalty. Adding 1 is to avoid the denominator being zero when D=0.

[0097] Overall logic: This formula comprehensively considers data size, real-time requirements, edge load, network bandwidth baseline, and cloud resource availability. It uses nonlinear functions (ln, sqrt) and absolute differences to simulate the impact of various factors on the generalized "transmission time", which includes penalties for resource shortages, high requirements, or data volume mismatch.

[0098] The advantage of the formula is that by comprehensively considering the characteristics of the task itself (Q, D), the state of the edge node (E), the network conditions (C), and the state of cloud resources (M, G), and introducing nonlinear relationships (logarithm, square root) and penalty terms, it can more accurately simulate the equivalent time cost or delay of task transmission to the cloud in complex environments, rather than just a simple Q / C, providing a more accurate basis for subsequent decisions (in this embodiment, determining whether the task is processed locally or offloaded to the cloud).

[0099] The calculation result of the transmission time parameter T, which is 19581.47 milliseconds in this embodiment, is not directly compared with a fixed threshold for decision-making. Instead, it serves as a quantitative indicator that will be used in subsequent steps (such as local time estimation, cloud time estimation, and utility index calculation). It reflects a time cost measure for transmitting task data to the cloud while considering the influence of relevant environmental factors. The higher this value, the greater the cost of the transmission stage, which may affect the final unloading decision.

[0100] The steps to obtain edge load parameters are as follows:

[0101] Based on the task type encoding in the structured task description, the process identifier prefix appended at the end is parsed, the edge node operating system interface is called, the fields of all processes in the process queue are traversed, and process instances containing the process identifier prefix are filtered to obtain the filtered set of process instances.

[0102] Based on the selected set of process instances, the CPU utilization of each instance is counted, the average CPU utilization is calculated, and if the average value exceeds a predefined threshold, the process queue overload flag is triggered and a process queue load summary is generated.

[0103] Based on the process queue load summary, the average CPU utilization is multiplied by the number of processes. If the overload flag is true, a predefined penalty coefficient is added to generate edge load parameters.

[0104] Specifically, based on the structured task description generated in the previous step, the system extracts the task type code, which in this embodiment is "VTAN01OBJREC001". Next, the system parses this encoded string, checking if it has a "process identifier prefix" appended to the end to identify a specific type of process. In this embodiment, according to preset rules, for task types starting with "VTAN", the associated edge computing process name prefix is ​​"EdgeAnalyticsProc_". The system then calls the interface provided by the operating system of the edge node. In this embodiment, the `ps` command under Linux combined with `grep`, or through system library functions of programming languages ​​(such as Python's `psutil` library), queries a list of all processes running on the current node. The system iterates through each process entry in this list, checking the name or command-line field of each process, and filtering out process instances whose names begin with "EdgeAnalyticsProc_". In this embodiment, there are three such processes running on the current node, namely "EdgeAnalyticsProc_Instance1".

[0105] The three process instances, "EdgeAnalyticsProc_Instance2", "EdgeAnalyticsProc_Instance3", and "EdgeAnalyticsProc_Instance3", constitute the set of process instances to be filtered. Then, for each process instance in this set, the system calls the operating system interface again (or uses library functions such as...).

[0106] The system uses `psutil.Process(pid).cpu_percent()` to obtain the current CPU utilization. In this example, the utilization rates obtained are: Instance 1 15%, Instance 2 25%, and Instance 3 20%. The system then calculates the average of these CPU utilization rates: (15+25+20) / 3 = 60 / 3 = 20%, meaning the average CPU utilization rate is 20%. The system needs to compare this average with a predefined CPU utilization rate threshold. This threshold should be set based on the processing capacity of the edge nodes and the expected response performance. In this example, based on historical load data analysis, a node is considered close to overload when the average CPU utilization rate exceeds 75%. We set this predefined threshold to 75%. In this example, the calculated average CPU utilization rate of 20% does not exceed 75%. Therefore, the system determines that the process queue is not overloaded and does not trigger the "process queue overload flag," i.e., the flag is false. The system generates a process queue load summary, which at least includes the calculated average CPU utilization rate (20%). The system calculates the edge load parameters based on the selected number of processes (3) and the overload flag (False). The calculation method involves multiplying the average CPU utilization (20%) by the number of processes (3), resulting in 20*3=60. Simultaneously, the overload flag is checked. Since the overload flag is false, no additional predefined penalty coefficient is needed. If the overload flag is true, a penalty coefficient needs to be multiplied. This penalty coefficient should reflect the severity of the overload state's impact on system performance. In this embodiment, it can be... The value is set to 1.5. The rationale for this setting could be that when the system is overloaded, the marginal cost of task processing increases significantly. Setting it to 1.5 indicates that the load parameter is numerically amplified by 50% to reflect this deterioration. In this embodiment, the average CPU utilization rate was 80% (exceeding the 75% threshold) in a certain calculation, and the number of processes was 5. Therefore, the overload flag is true, and the calculated edge load parameter is 80 * 5 * 1.5 = 600. However, in our current example, the overload flag is false, so the final edge load parameter is 60. This value of 60 is the edge load parameter L generated in this step. ′ It quantifies the overall load of processes currently associated with this task type on the edge node.

[0107] The steps to obtain the node state vector are as follows:

[0108] Based on the task type code in the structured task description, a resource status query request message is constructed. The current timestamp and the hash value of the task type code are added to the message as an authentication token. A query request with a timestamp is sent to the cloud resource management interface to generate a resource query request object.

[0109] Based on the resource query request object, receive the response message returned by the cloud, parse the "number of available virtual machine instances" and "remaining memory" fields in the response data, verify whether the difference between the timestamp in the response message and the local request object is less than the preset timeout threshold, and generate a resource status response dataset.

[0110] Based on the resource status response dataset, if the timestamp validity flag is true, the number of available virtual machine instances and the remaining memory are concatenated into an array in order to generate a node status vector.

[0111] Specifically, based on the task type code in the structured task description, in this embodiment "VTAN01OBJREC001", the system first constructs a request message for querying the status of cloud resources. This is typically an HTTP request conforming to a specific API specification (such as RESTful API). The target of the request is the address of the cloud resource management service interface, and the request content must specify the type of resource to be queried (such as virtual machine instances and memory). To ensure the legality and timeliness of the request, the system adds authentication information to the message. Specifically, it obtains the current precise timestamp, which in this embodiment is the Unix timestamp 1678886400000 (milliseconds). This timestamp is concatenated or combined with the task type code "VTAN01OBJREC001", and then its hash value is calculated. In this embodiment, the SHA-256 algorithm is used to obtain a hash string HASH_RES. ULT, this hash string, is added as a one-time authentication token to a specific field in the request message (such as the AuthorizationHeader or request body parameters). Simultaneously, the original timestamp 1678886400000 is also included in the message; in this embodiment, it's placed in a field named "Timestamp". After constructing the message, the system sends this query request with the timestamp and authentication token to the pre-configured cloud resource management interface URL, forming a resource query request object (this object may contain request details and sending status on the client side). Subsequently, the system listens for and receives the response message from the cloud resource management interface. This response message is typically in JSON or XML format and contains the queried resource status data. The system parses this response message and extracts the values ​​of two key fields: "Number of available virtual machine instances".

[0112] The response message contains "AvailableVMInstances" and "Remaining Memory" (MemoryAvailable GB). In this embodiment, these two fields are 8 and 2048 (GB) respectively. The response message also includes a timestamp field generated by the cloud service to verify the freshness of the response. The system extracts this response timestamp, which in this embodiment is 1678886400500, and compares it with the timestamp 1678886400000 recorded in the local request object when the previous request was sent. The time difference between the two is calculated as: 1678886400500 - 1678886400000 = 500 milliseconds. The system compares this difference with a preset timeout threshold. This timeout threshold should take into account network latency and processing time to ensure that the obtained status information is sufficiently real-time. In this embodiment, the timeout threshold can be set to 1000 milliseconds. This threshold is based on an assessment of normal network RTT (Round-Trip Time) and cloud interface response time. Setting it to 1000ms ensures relatively fresh information while allowing for some network fluctuations. In this example, the difference of 500 milliseconds is less than the preset 1000 millisecond threshold, so the system determines that the timestamp is valid and generates a resource status response dataset containing the query results (8 available virtual machines, 2048GB of remaining memory) and a timestamp validity flag (True). Finally, based on this dataset, the system checks the timestamp validity flag. Since the flag is True, the system concatenates the obtained "number of available virtual machine instances" value of 8 and "remaining memory" value of 2048 into an array [8, 2048] in a predefined order (in this embodiment, the number of virtual machines first, then the amount of memory). This array [8, 2048] is the generated node state vector V. state .

[0113] The steps to obtain the local time consumption estimate are as follows:

[0114] Obtain the computational parameters and CPU utilization from the structured task description;

[0115] Based on load intensity, computational parameters, and CPU utilization, the estimated local latency is calculated using the following formula:

[0116]

[0117] Where V is the number of available virtual machine instances in the node state vector, M is the remaining available memory in the cloud, H is the computational load parameter, L′ is the load intensity, P is the CPU utilization value, and T local Estimated local time consumption.

[0118] Specifically, the system first needs to obtain two key parameters: one is the computational load parameter H from the structured task description generated in the second step. Here, the average value or a specific value of the computational load mapping parameter range is used. In this embodiment, it is based on [1.5, 3.0] Gops, and a representative value is selected, such as the average value H = (1.5 + 3.0) / 2 = 2.25 Gops (i.e., 2.25 * 10^9 operations). The other is the CPU utilization P obtained from the task request or real-time monitoring of the edge node. This P refers to the percentage of CPU expected to be used to execute the task, or the part of the current node's total CPU utilization related to this type of task. The execution of this task is expected to consume 30% of the CPU. The system also needs to obtain the edge load parameter L calculated in the third step. ′ Its value is 60, and the node state vector V obtained in the fourth step. state = [8, 2048], from which the number of available virtual machine instances in the cloud, V = 8, and the remaining available memory in the cloud, M = 2048GB, are extracted. Next, based on these parameters, the system calculates the estimated local time consumption, T. local The calculations should be based on the following formula:

[0119]

[0120] Where P is the expected local CPU utilization for task execution, V and M are the cloud resource status (number of available VMs and memory), and L... ′ H represents the edge load parameter, H represents the computational cost, and K is a memory-dependent scaling factor.

[0121] Substitute the obtained and calculated parameter values ​​into the formula: H = 2.25 × 10 9 L ′ =60, P=30, V=8, M=2048.

[0122] The calculation process is as follows:

[0123] Calculate the logarithmic part of the numerator: ln(1+L) ′ )=ln(1+60)=ln(61)≈4.1109,

[0124] Calculate the molecule: H·ln(1+L) ′ )=(2.25×10 9 )·4.1109≈9.2495×10 9 ,

[0125] Calculate the CPU-usable portion in the denominator: 100 - P = 100 - 30 = 70.

[0126] Calculate the radical part in the denominator:

[0127] Calculate the memory impact portion in the denominator:

[0128] Calculate the part in parentheses in the denominator:

[0129] Calculate the denominator:

[0130] Finally, calculate T. local :

[0131] The calculation result T local It is approximately equal to 5,627,586, and the local execution is expected to take about 5,628 seconds.

[0132] Regarding formula T local Detailed explanation:

[0133] formula Used to estimate the time required for a task to be executed locally on an edge node.

[0134] Parameter description:

[0135] H: The computational workload of the task, representing the total computational work required to complete the task.

[0136] L ′ Edge load parameter, which reflects the overall load of related processes on the current edge node. The larger the value, the higher the load.

[0137] P: Expected local CPU utilization (percentage) for executing this task, representing the proportion of CPU resources consumed by the task itself.

[0138] V: The number of available virtual machine instances in the cloud (from the node state vector), a measure of cloud computing resources.

[0139] M: Remaining available memory in the cloud (GB) (from the node state vector), a measure of cloud memory resources.

[0140] ln: Natural logarithm function.

[0141] Square root operation.

[0142] T local : The calculated local execution time estimate (the unit depends on the unit settings of H and the denominator).

[0143] Operational logic:

[0144] The formula structure is: Total computational cost / (Available computational resources * Resource adjustment factor).

[0145] Molecular H·ln(1+L) ′ The basic computational load H is reduced by the current edge load L. ′ Modulation. ln(1+L) ′ With load L ′ The load increases, but the rate of increase decreases, indicating that the higher the load, the longer the effective time required to complete the same amount of computation (considering contention and scheduling overhead).

[0146] denominator This represents effective local computing power or resources.

[0147] (100-P): Represents the percentage of CPU processing power remaining on the node after executing this task. The lower the remaining power, the smaller the denominator, and the longer the processing time.

[0148] This section introduces cloud resource status (V and M) to adjust local execution time estimation. The richer the cloud resources (larger V and M), the more likely some global scheduling or resource optimization will benefit the local execution environment (in this embodiment, it can acquire dependency libraries and update models faster), thereby reducing local execution time. (Square root) The linear term M / 100 represents the contribution of the number of cloud VMs and memory to this potential "benefit," with the contribution of the number of VMs decreasing marginally. A larger denominator indicates stronger effective computing power, and a longer time consumption T... local The shorter.

[0149] The advantage of this formula lies in its ability to predict local execution time by combining the computational load of the task itself, the real-time load of edge nodes, the task's resource consumption on local resources, and (potentially indirectly related) global resource conditions. This is achieved through ln and... By incorporating nonlinear functions, the model attempts to more realistically reflect the impact of load and resource changes on execution time, rather than simply presenting a linear relationship.

[0150] The calculated local time estimate T local ≈5,627,586 is a predicted value that will be used to compare with the estimated execution time in the cloud, and is one of the key inputs for subsequent decisions (choosing between on-premises or cloud execution). It represents the estimated time required to process the task on an edge node in this embodiment of the model.

[0151] The steps to obtain the utility index parameter are as follows:

[0152] Based on the computational complexity and transmission time parameters in the structured task description, the number of available virtual machine instances is extracted from the node state vector to generate parameter triples.

[0153] Based on the parameter triplet, the estimated cloud latency is calculated using the following formula:

[0154]

[0155] Where H is the computational cost parameter, T is the transmission time parameter, V is the number of available virtual machine instances, and T cloud Estimating the time spent in the cloud;

[0156] The cloud-based time-consuming estimate is combined with the local time-consuming estimate to generate a utility index parameter.

[0157] Specifically, we first need to gather three key parameters to form a parameter triple: the first is the computational cost parameter H from the structured task description, which continues to use the value from the previous step, H = 2.25 × 10. 9 The first parameter is Gops, the second is the transmission time parameter T, which also comes from the structured task description and is calculated using the second step (T = 19581.47). The third parameter is the node state vector V obtained from the fourth step. state =8. The number of available virtual machine instances extracted from [8,2048] is V=8. This triple is (2.25×10 9 Based on this parameter triplet (19581.47, 8), the system then calculates the estimated time T for the task to be executed in the cloud. cloud The calculations should be based on the following formula:

[0158]

[0159] Substitute the obtained parameter values ​​into the formula: H = 2.25 × 10 9 T = 19581.47, V = 8.

[0160] The calculation process is as follows:

[0161] Calculate the denominator: V 2 +1 = 8 2 +1 = 64 + 1 = 65

[0162] Calculate the numerator: H·T=(2.25×10 9 )·19581.47≈4.40583×10 13 ,

[0163] Calculate T cloud :

[0164] The calculation result T cloud Approximately 6.7782 × 10 11 Convert to milliseconds to get T cloud = 6778 milliseconds.

[0165] Finally, the system uses this calculated cloud time estimate T cloud= 6778 milliseconds, compared to the estimated local latency T calculated in the previous step. local =5,627,586 milliseconds are merged to form a combination containing two values. In this embodiment, a tuple [T] local T cloud That is, [5627586, 6778], this combination is the generated utility index parameter.

[0166] Regarding formula T cloud Detailed explanation:

[0167] formula Used to estimate the total time required to offload a task to the cloud for execution (including transport and processing).

[0168] Parameter description:

[0169] H: The computational load of the task (Giga-operations in this embodiment).

[0170] T: Transmission time parameter (calculated by formula 2), representing a comprehensive measure of the time cost of data transmission to the cloud and possible queuing, scheduling, etc.

[0171] V: Number of available virtual machine instances in the cloud.

[0172] T cloud The calculated total execution time estimate in the cloud.

[0173] Operational logic:

[0174] The formula attempts to combine transmission costs and cloud computing time.

[0175] The numerator H·T is the product of the task computation H and the transmission time parameter T.

[0176] Denominator V 2 +1: The square of the number of available virtual machines V in the cloud plus 1. Using V 2 This indicates that cloud processing capacity grows non-linearly (quadraticly) with the number of available instances, reflecting the significant speedup effect of massively parallel processing. Adding 1 is to avoid the denominator being zero when V=0 and to ensure that even with only one VM, there is basic processing capacity. A larger denominator indicates stronger cloud processing capacity, and a larger total time T. cloud The shorter.

[0177] Overall logic: In this embodiment of the model, the total cloud computing time is proportional to (computational load * transmission factor) and the available cloud computing resources (in V). 2 (It reflects) an inverse relationship.

[0178] The advantage of this formula is that it combines the cost of data transmission (represented by T) and cloud computing power (represented by V).2 This reflects the total execution time in the cloud, and is assessed through V. 2 This item reflects the scale effect of cloud resources and, compared to simpler models (such as T+H / speed), better captures the advantages of parallel processing.

[0179] The calculated cloud time estimate T cloud =6778 milliseconds and local time estimation T local =

[0180] 5,627,586 milliseconds together constitute the utility index parameter. The core function of this parameter is to provide the basic criterion needed for decision-making: comparing these two values ​​can preliminarily determine whether it's faster to keep the task running locally or offload it to the cloud. In this example, T... cloud (Approximately 6.8 seconds) is much smaller than T. local (Approximately 5628 seconds) indicates that, from a purely time-consuming perspective, offloading this task to the cloud is a significantly better option.

[0181] The steps for obtaining the candidate plan set are as follows:

[0182] Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameters, the local time consumption estimate and the cloud time consumption estimate are compared, and the shorter time consumption is selected as the benchmark time consumption reference value. The version number and subclass identifier of the task type code in the structured task description are parsed, and the benchmark time consumption reference value and the task type code are subjected to SHA-256 hash operation to generate a 128-bit feature vector, which is used as the query index key of the pre-stored plan library.

[0183] Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored contingency plan library is called. With the baseline time reference value as the center value, all related entries are retrieved within a ±15% fluctuation range. Entries with complete matching task type codes and contingency plan status marked as "available" are filtered out. The search results are sorted in descending order by contingency plan heat value, where contingency plan heat value = number of calls in the last 7 days × priority coefficient, to generate a preliminary matching contingency plan set.

[0184] Based on the preliminary matching set of contingency plans, the metadata description field of each contingency plan is extracted. If the predicted start-up time of a contingency plan is less than 1.2 times the baseline time reference value, it is retained as a valid candidate contingency plan. The numbers of all valid contingency plans are merged and deduplicated to generate a set of candidate contingency plans.

[0185] Specifically, based on the utility index parameters obtained in the previous step, i.e., the local time consumption estimate T local =

[0186] 5,627,586 milliseconds and cloud latency estimate T cloud = 6778 milliseconds, the system first performs a comparison operation, setting T... localCompare with the value of T cloud and select the smaller value as the reference value of the benchmark time-consuming. In this example, 6778 <5627586>, so the reference value of the benchmark time-consuming is set to T base = 6778 milliseconds. Then, the system extracts the task type code "VTAN01OBJREC001" from the structured task description again and analyzes this code to obtain the version number and subclass identifier contained therein (in this embodiment, the coding rule allows these information to be analyzed. In this embodiment, "01" is the version number and "OBJREC" is the subclass identifier). Then, the system combines the reference value of the benchmark time-consuming T base = 6778 (it may need to be converted to the standard format or string first) with the complete task type code "VTAN01OBJREC001". In this embodiment, it is concatenated into a string "6778: VTAN01OBJREC001". Perform the SHA-256 hash operation on this combined result to generate a 256-bit hash digest. The system intercepts the first 128 bits of this hash digest to obtain a 128-bit feature vector. In this embodiment, "a3b1c8d..." (for illustration here), this 128-bit feature vector will be used as the query index key to search for similar or matching execution plans in the pre-stored plan library. Then, the system calls the query interface of the pre-stored plan library. This plan library is designed to support efficient retrieval. In this embodiment, a distributed inverted index structure is used. When querying, the system uses the reference value of the benchmark time-consuming T base = 6778 as the central query point and defines a floating range. In this embodiment, ±15%, and calculates the lower limit of the query range as 6778×(1 - 0.15) = 6778×0.85 = 5761.3 milliseconds, and the upper limit as 6778×(1 + 0.15) = 6778×1.15 = 7794.7 milliseconds. The system retrieves all associated plan entries in the plan library, and a certain performance index (such as the historical average time-consuming) of these entries falls within the range of [5761.3, 7794.7] milliseconds. At the same time, the retrieval also needs to meet two filtering conditions: one is that the task type code corresponding to the plan must exactly match the code "VTAN01OBJREC001" of the current task, and the other is that the status flag of the plan must be "available"

[0187] (Available) In this embodiment, five preliminary matching plans that meet the conditions were retrieved. The system then sorts these five plans in descending order according to their "plan heat value". The "plan heat value" is calculated as the total number of times the plan has been successfully invoked in the last 7 days multiplied by a preset priority coefficient. The priority coefficient can be set based on factors such as the plan's stability, resource consumption efficiency, or business importance. In this embodiment, the coefficient for high-stability plans is set to 1.2, for standard plans it is 1.0, and for experimental plans it is 0.8. In this embodiment, plan A has been invoked 100 times in the last 7 days, with a priority coefficient of 1.0 and a heat value of 100; plan B has been invoked 80 times, with a priority coefficient of 1.2 and a heat value of 96; and plan C has been invoked 120 times. Priority coefficient 0.8, heat value 96; Plan D called 50 times, priority coefficient 1.0, heat value 50; Plan E called 60 times, priority coefficient 1.0, heat value 60, then the sorting result is A(100), B(96), C(96), E(60), D(50) (the same heat value can be sorted according to other rules, such as the most recent call time). After sorting, a preliminary matching plan set {A, B, C, E, D} is obtained. The system further refines this preliminary set by extracting the metadata description field of each plan and looking for the "plan start-up time prediction value" recorded therein (this may be the plan's own attribute, or a value dynamically estimated based on the current system status). This prediction value is compared with the previously determined baseline time reference value T. base =6778 is compared, and the judgment condition is: whether the predicted time for the contingency plan to be activated is less than T. base The time taken to start the prediction of plan A is 1.2 times that of the previous plan, which is less than 6778 × 1.2 = 8133.6 milliseconds. In this embodiment, the prediction start time of plan A is 7000ms, plan B is 8000ms, plan C is 8500ms, plan E is 7500ms, and plan D is 6000ms. Therefore, the prediction times of plans A, B, E, and D are all less than 8133.6ms, while the 8500ms of plan C is greater than this threshold. Therefore, plans A, B, E, and D are retained as valid candidate plans, and plan C is eliminated. Finally, the system merges the unique identifiers of all valid candidate plans (plan numbers in this embodiment) and performs deduplication (although there are no duplicates in this example) to generate the final set of candidate plans. In this embodiment, the list containing plan numbers is: [PlanID_A, PlanID_B, PlanID_E, PlanID_D]. This set is the list of specific plans provided to the subsequent decision-making module for selection and execution.

Claims

1. A cloud-edge collaborative intelligent production scheduling and control system, characterized in that, The system includes: The task feature aggregation module extracts the task type code based on the input task request, queries the task type and computational quantity mapping table in the pre-stored knowledge base, matches the task type and extracts the computational quantity parameters, generates computational quantity mapping parameters, calculates the transmission time parameters based on the computational quantity mapping parameters, and generates a structured task description. The node status retrieval module, based on the task type encoding in the structured task description, collects the CPU utilization value in the current edge node process queue, generates edge load parameters, sends a resource status query request to the cloud, receives the number of available virtual machine instances and the amount of memory remaining returned by the cloud, and generates a node status vector. The utility decision index module calculates the local time consumption estimate based on the edge load parameters and cloud memory remaining data in the node state vector, and calculates the cloud time consumption estimate by adding the transmission time parameters in the structured task description based on the computation amount parameters and the number of virtual machine instances, and generates utility index parameters. The contingency plan storage module, based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameters, retrieves the associated entries of time consumption threshold and task type in the pre-stored contingency plan library, extracts the set of contingency plan numbers that meet the threshold range, and generates a set of candidate contingency plans. The steps for obtaining the computational quantity mapping parameters are as follows: Based on the input task request, the task type encoding string carried in the task request header field is parsed, and the 3rd to 6th characters in the string are extracted as the core identifier. The task type and computation amount mapping table in the pre-stored knowledge base is traversed, and the core identifier is compared with the complete match of the task type encoding in the mapping table to obtain the locked task type entry. Based on the locked task type entries, extract the upper and lower limit values ​​of the "basic computational quantity numerical range" field defined in the mapping table to obtain the computational quantity mapping parameters; The steps for obtaining the candidate plan set are as follows: Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameters, compare the local time consumption estimate and the cloud time consumption estimate, select the shorter time consumption estimate as the benchmark time consumption reference value, parse the version number and subclass identifier of the task type code in the structured task description, perform SHA-256 hash operation on the benchmark time consumption reference value and the task type code, generate a 128-bit feature vector, and use it as the query index key of the pre-stored plan library; Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored contingency plan library is called. With the baseline time reference value as the center value, all related entries are retrieved within a ±15% fluctuation range. Entries with complete matching task type codes and contingency plan status marked as "available" are filtered out. The search results are sorted in descending order by contingency plan heat value, where contingency plan heat value = number of calls in the last 7 days × priority coefficient, to generate a preliminary matching contingency plan set. Based on the preliminary matching plan set, the metadata description field of each plan is extracted. If the predicted start-up time of a plan is less than 1.2 times the baseline time reference value, it is retained as a valid candidate plan. The numbers of all valid plans are merged and deduplicated to generate a candidate plan set.

2. The intelligent production scheduling and control system based on cloud-edge collaboration according to claim 1, characterized in that, The steps for obtaining the structured task description are as follows: Based on the computational volume mapping parameters, extract the number of bytes in the task data packet size, the real-time requirement threshold, the real-time CPU utilization of edge nodes, and the remaining available memory in the cloud to obtain a set of quadruples parameters; Based on the aforementioned quadruple parameter set, the transmission time parameter is calculated; The transmission time parameter is combined with the task type encoding and computational quantity mapping parameter to generate a structured task description by field name.

3. The intelligent production scheduling and control system based on cloud-edge collaboration according to claim 1, characterized in that, The steps for obtaining the edge load parameters are as follows: Based on the task type encoding in the structured task description, the process identifier prefix appended at the end is parsed, the edge node operating system interface is called, the fields of all processes in the process queue are traversed, and process instances containing the process identifier prefix are filtered to obtain a set of filtered process instances. Based on the selected set of process instances, the CPU utilization of each instance is counted, the average CPU utilization is calculated, and if the average value exceeds a predefined threshold, the process queue overload flag is triggered, and a process queue load summary is generated. Based on the process queue load summary, the average CPU utilization is multiplied by the number of processes. If the overload flag is true, a predefined penalty coefficient is added to generate edge load parameters.

4. The intelligent production scheduling and control system based on cloud-edge collaboration according to claim 1, characterized in that, The steps for obtaining the node state vector are as follows: Based on the task type code in the structured task description, a resource status query request message is constructed. The current timestamp and the hash value of the task type code are added to the message as an authentication token. A query request with a timestamp is sent to the cloud resource management interface to generate a resource query request object. Based on the resource query request object, receive the response message returned by the cloud, parse the "number of available virtual machine instances" and "remaining memory" fields in the response data, verify whether the difference between the timestamp in the response message and the local request object is less than the preset timeout threshold, and generate a resource status response dataset. Based on the resource status response dataset, if the timestamp validity flag is true, the number of available virtual machine instances and the remaining memory are concatenated into an array in order to generate a node status vector.

5. The intelligent production scheduling and control system based on cloud-edge collaboration according to claim 1, characterized in that, The steps for obtaining the local time consumption estimate are as follows: Obtain the computational complexity parameters and CPU utilization rate from the structured task description; Calculate the estimated local latency based on load intensity, computational parameters, and CPU utilization.

6. The intelligent production scheduling and control system based on cloud-edge collaboration according to claim 1, characterized in that, The steps for obtaining the utility index parameter are as follows: Based on the computational complexity and transmission time parameters in the structured task description, the number of available virtual machine instances is extracted from the node state vector to generate parameter triples. Based on the parameter triplet, calculate the cloud time estimation; The cloud-based time consumption estimate and the local time consumption estimate are combined to generate a utility index parameter.

Images