Production scheduling intelligent management and control system based on cloud edge collaboration

Abstract

The invention 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, and the system comprises a task feature aggregation module which is used for extracting a task type code based on an input task request, querying a task type and calculation amount mapping table in a pre-stored knowledge base, matching the task type and extracting a calculation amount parameter. According to the method, the mapping relation between the task type and the pre-stored calculation amount is dynamically matched, the task data packet size, the real-time requirement threshold value and the bandwidth reference value are linked to calculate the transmission time consumption parameter, quantitative mapping of task requirements and resource supply is achieved, and 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, and the multi-dimensional node state vector is generated in combination with the number of cloud virtual machine instances and memory surplus data, so that the limitation of traditional single resource index monitoring is broken through, and the space-time fine granularity of load evaluation is improved.

Description

Technical Field

[0001] The present 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 Art

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

[0003] Existing technologies rely on centralized decision-making and lack the integration of real-time edge-side operating data. This leads to lags in order scheduling and equipment load balancing, making it difficult to cope with sudden production tasks or equipment failures. The resource scheduling process relies on static empirical thresholds and lacks a dynamic correlation mechanism for parameters such as task type, computational effort, and transmission time. This can easily lead to conflicting resource allocation scenarios, such as overloaded and idle resources. For example, high-priority tasks may be delayed due to bandwidth misestimation. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to solve the shortcomings of the existing technology and propose a production scheduling intelligent management and control system based on cloud-edge collaboration.

[0005] To achieve the above objectives, the present invention adopts the following technical solutions: A production scheduling intelligent management and control system based on cloud-edge collaboration includes:

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

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

[0008] A utility decision index module calculates a local time estimate based on the edge load parameter in the node state vector and the remaining cloud memory data, calculates a cloud time estimate based on the computational load parameter and the number of virtual machine instances, and superimposes the transmission time parameter in the structured task description to generate a utility index parameter.

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

[0010] Preferably, the steps for obtaining the calculation amount mapping parameters are:

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

[0012] Based on the locked task type entry, the upper and lower limit values ​​of the "basic calculation amount value range" field defined in the mapping table are extracted to obtain the calculation amount mapping parameters.

[0013] Preferably, the steps of obtaining the structured task description are:

[0014] Based on the computational workload mapping parameters, the number of bytes of the task data packet size, the real-time requirement threshold, the real-time CPU occupancy rate of the edge node, and the remaining amount of available cloud memory are extracted to obtain a four-tuple parameter set;

[0015] Calculating a transmission time parameter based on the four-tuple parameter set;

[0016] The transmission time consumption parameter is combined with the task type code and the calculation amount mapping parameter to generate a structured task description according to the field name.

[0017] Preferably, the step of obtaining the edge load parameter is:

[0018] Based on the task type code 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 the process instances containing the process identifier prefix are filtered to obtain a filtered process instance set;

[0019] According to the filtered set of process instances, the CPU usage of each instance is counted, and the average value of the CPU usage is calculated. If the average value exceeds a predefined threshold, a 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 occupancy is multiplied by the number of processes. If the overload flag is true, a predefined penalty coefficient is additionally added to generate an edge load parameter.

[0021] Preferably, the step of obtaining the node state vector is:

[0022] Based on the task type code in the structured task description, a resource status query request message is constructed, a hash value of the current timestamp and the task type code is added to the message as an authentication token, and 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 a response message returned by the cloud, parse the "number of available virtual machine instances" field and the "remaining memory" field in the response data, verify whether the difference between the timestamp in the response message and the local request object is less than a preset timeout threshold, and generate a resource status response data set;

[0024] According to the resource status response data set, if the timestamp validity flag is true, the number of available virtual machine instances and the remaining memory are sequentially concatenated into an array to generate a node status vector.

[0025] Preferably, the steps for obtaining the local time estimation are:

[0026] Obtaining the computational load parameters and CPU occupancy rate in the structured task description;

[0027] Calculate the local time estimate based on load intensity, computing parameters, and CPU usage.

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

[0029] Based on the computational load parameter and the transmission time consumption parameter in the structured task description, the number of available virtual machine instances in the node state vector is extracted to generate a parameter triplet;

[0030] Calculate the estimated cloud time based on the parameter triples;

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

[0032] Preferably, the steps of obtaining the candidate plan set are:

[0033] Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameter, 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 a SHA-256 hash operation to generate a 128-bit feature vector as a query index key for the pre-stored plan library;

[0034] Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored plan library is called. With the benchmark time reference value as the central value, all related entries are retrieved within a floating range of ±15%. Entries with a complete match in the task type code and a plan status marked as "available" are selected. The search results are sorted in descending order by the plan's thermal value (plan thermal value = number of calls in the last 7 days × priority coefficient) to generate a preliminary set of matching plans.

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

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

[0037] In the present invention, by dynamically matching the mapping relationship between task types and pre-stored computing amounts, the task data packet size, real-time requirement threshold and bandwidth reference value are linked to calculate the transmission time parameters, thereby realizing the quantitative mapping of task demand and resource supply and eliminating the parameter deviation caused by traditional manual experience estimation. The CPU occupancy value of the edge node process queue is collected in real time, and the multi-dimensional node state vector is generated by combining the number of cloud virtual machine instances and memory remaining data, breaking through the limitations of traditional single resource indicator monitoring and improving the spatiotemporal granularity of load assessment. Based on edge load parameters, computing amount parameters and CPU occupancy, a dual evaluation mechanism of local computing time and cloud computing time is constructed. By superimposing the transmission time and dynamically adapting the number of virtual machine instances, a utility index parameter is formed to enhance the real-time and environmental adaptability of task distribution decisions. Combined with the time threshold interval matching and thermal value sorting of the pre-stored plan library, a set of candidate plans is generated to achieve deep coupling between the plan screening process and the real-time operating status, shortening the decision-making response cycle in abnormal scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 is a system flow chart of the present invention;

[0039] Figure 2 Flowchart of the steps for obtaining the calculation amount mapping parameters in the present invention;

[0040] Figure 3 Flowchart of the steps for obtaining the structured task description in the present invention. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present 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 only used to explain the present invention and are not intended to limit the present invention.

[0042] See also Figure 1 , the present invention provides a technical solution: a production scheduling intelligent management and control system based on cloud-edge collaboration includes:

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

[0044] The node status retrieval module, based on the task type code in the structured task description, collects the CPU usage 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 remaining memory data returned by the cloud, and generates a node status vector;

[0045] The utility decision index module calculates the local time estimate based on the edge load parameter in the node state vector and the remaining cloud memory data. It also calculates the cloud time estimate based on the computational load parameter and the number of virtual machine instances, and superimposes the transmission time parameter in the structured task description to generate the utility index parameter.

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

[0047] See also Figure 2 , the steps to obtain the calculation amount mapping parameters are:

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

[0049] Based on the locked task type entry, the upper and lower limit values ​​of the "basic calculation amount value range" field defined in the mapping table are extracted to obtain the calculation amount mapping parameters.

[0050] Specifically, based on the input task request, the system first performs a parsing operation, specifically reading the header part of the request message. This part encapsulates multiple metadata according to a predetermined protocol format. The system locates the field named "TaskTypeCode" and extracts the string value contained therein. In this embodiment, a specific task request header may contain the field "TaskTypeCode: VTAN01OBJREC001". The system extracts the complete encoded string "VTAN01OBJREC001". Then, the system performs a truncation operation on the string. According to the rules, the 3rd to 6th bits of the string are intercepted as the core identifier. For the example string "VTAN01OBJREC001", the truncation operation will obtain "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 computing amount mapping table". This table establishes an association between the task type and the quantitative indicators of the computing resources required. Its structure is as follows:

[0051] Table 1 Example of mapping between task type and computational load

[0052]

[0053] As shown in Table 1, the table lists the codes, core identifiers, descriptions, and corresponding basic computing ranges of different task types. The system will perform an exact match search with the core identifier "AN01" obtained earlier and each record in the "Core Identifier" column of the table. When the "Core Identifier" field value of an entry in the table is found to be exactly the same as "AN01", the entry is determined to be a "locked task type entry". In this example, the system will lock the first record (task type code VTAN01OBJREC). After locking the entry, the system will extract the task type from the entry. Take the specific value of the "Basic computing amount value range" field, that is, find and read the values ​​of the two columns "Basic computing amount lower limit (Gops)" and "Basic computing amount upper limit (Gops)". For the locked "AN01" entry, the extracted lower limit value is 1.5Gops and the upper limit value is 3.0Gops. The combination of these two values ​​(in this embodiment, forming an array containing two elements or an object with two properties, such as [1.5, 3.0] or {min: 1.5, max: 3.0}) constitutes the computing amount mapping parameters required for this task request.

[0054] See also Figure 3 , the steps for obtaining structured task description are:

[0055] Based on the computational mapping parameters, the number of bytes of the task data packet size, the real-time requirement threshold, the real-time CPU usage of the edge node, and the remaining available cloud memory are extracted to obtain a four-tuple parameter set.

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

[0057]

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

[0059] Combine the transmission time parameter with the task type code and the computation amount mapping parameter to generate a structured task description based on the field name.

[0060] Specifically, based on the calculation amount mapping parameter obtained in the previous step, in this embodiment, the numerical range is

[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 (Payload) or associated metadata of the task request. This set of parameters constitutes a four-tuple, 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, which is 1048576 bytes (i.e., 1MB) in this embodiment; the real-time requirement threshold D, which is obtained from the priority or quality of service (QoS) field mapping of the task request in this embodiment, which requires the processing delay to be no more than 50 milliseconds in this embodiment; the edge node real-time CPU The occupancy 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 occupancy rate is 65%. The remaining available cloud memory M is obtained by calling the cloud platform resource management API in this embodiment. In this embodiment, the current remaining available cloud memory of the target cluster or node is 2048GB. The system integrates these four values ​​(1048576, 50, 65, 2048) to form a four-tuple parameter set. Next, based on this four-tuple parameter set and two preset system constants, the transmission time parameter T is calculated according to 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 byte of Q, and the magnitude needs to be adjusted, or it can be understood as an abstract reference value related to the transmission rate, which is the value corresponding to Q (byte) and D ( milliseconds), set C to an empirically adjusted value, 500,000 in this embodiment (this value needs to be determined based on the actual network model and unit consistency, and is only an example here). The setting of G refers 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, substitute the obtained parameter values ​​and the set constant values ​​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 square root 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] Compute the numerator of the first term:

[0068] Compute the value of the first term:

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

[0070] Compute the rounded portion of the numerator of the second term:

[0071] Compute the absolute value part of the numerator of the second term:

[0072] Calculate the value of the second term:

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

[0074] Detailed explanation of formula T:

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

[0076] Parameter Description:

[0077] Q: The number of bytes in the task data packet, indicating the size of the task input data.

[0078] D: Real-time requirement threshold (milliseconds). A smaller value indicates a higher real-time requirement.

[0079] E: Real-time CPU usage of edge nodes (percentage), indicating how busy the edge nodes are.

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

[0081] M: The remaining available cloud memory (GB), reflecting the availability of cloud resources.

[0082] G: System predefined memory baseline constant (GB), used to normalize the impact of cloud memory.

[0083] ln: natural logarithm function.

[0084] Square root operation.

[0085] |·|: Absolute value operation.

[0086] Floor function.

[0087] T: Calculated transmission time parameter.

[0088] Operation logic:

[0089] The formula is divided into two main parts that are added together.

[0090] Part 1 Trying to simulate prime transfer times or costs:

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

[0092] Denominator The base bandwidth C is the core, multiplied by an adjustment factor The more cloud memory M is relative to the benchmark G, The larger the value, the larger the denominator, resulting in a decrease in the first part of the calculated T, which may reflect the improvement of the cloud resource abundance in task reception and preliminary processing capabilities, thereby indirectly reducing the perceived "transmission time". Therefore, the benefits brought by the increase of memory M are also of diminishing marginal value.

[0093] Part 2 is a penalty or adjustment term:

[0094] molecular Calculate the absolute difference between the task data volume Q and one tenth (rounded) of the bandwidth benchmark C. This indicates the degree of mismatch between the data volume and a certain threshold of network capacity. The larger the difference, the higher the penalty.

[0095] Denominator D+1: The higher the real-time requirement D (a larger value means a lower requirement), the larger the denominator and the smaller the penalty. Conversely, the higher the real-time requirement (the smaller D), the larger the penalty. Adding 1 prevents the denominator from being zero when D = 0.

[0096] Overall Logic: This formula comprehensively considers data size, real-time requirements, edge load, network bandwidth benchmark, and cloud resource availability. It simulates the impact of various factors on the broad "transmission time" through nonlinear functions (ln, sqrt) and absolute difference, including penalties for resource constraints, high requirements, or data volume mismatch.

[0097] The benefit of the formula lies in that by comprehensively considering the characteristics of the task itself (Q, D), the edge node status (E), the network conditions (C), and the cloud resource status (M, G), and introducing nonlinear relationships (logarithmic, 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 decision-making (in this embodiment, determining whether the task should be processed locally or offloaded to the cloud for processing).

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

[0099] The steps to obtain edge load parameters are:

[0100] Based on the task type code 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 the process instances containing the process identifier prefix are filtered to obtain a set of filtered process instances;

[0101] Based on the filtered set of process instances, the CPU usage of each instance is counted and the average CPU usage is calculated. If the average exceeds the predefined threshold, the process queue overload flag is triggered and a process queue load summary is generated.

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

[0103] Specifically, based on the structured task description generated in the previous link, the system extracts the task type code from it, which is "VTAN01OBJREC001" in this embodiment. Then, the system parses the encoded string to find out whether a "process identifier prefix" for identifying a specific type of process is appended to its tail. In this embodiment, according to the preset rules, for the task type starting with "VTAN", the prefix of its associated edge computing process name is "EdgeAnalyticsProc_". The system then calls the interface provided by the operating system of the edge node where it is located. In this embodiment, the ps command under the Linux system is combined with grep, or the system library function of the programming language (such as Python's psutil library) is used to query the list of all processes running on the current node. The system traverses each process entry in this list, checks the name or command line field of each process, and filters out those process instances whose names start with "EdgeAnalyticsProc_". In this embodiment, there are 3 such processes running on the current node, namely "EdgeAnalyticsProc_Instance1".

[0104] The three process instances "EdgeAnalyticsProc_Instance2" and "EdgeAnalyticsProc_Instance3" constitute the filtered process instance set. Then, the system calls the operating system interface again (or uses library functions such as

[0105] psutil.Process(pid).cpu_percent()) is used to obtain its current CPU usage. In this example, the usage obtained is: 15% for instance 1, 25% for instance 2, and 20% for instance 3. The system then calculates the average of these CPU usage, using the formula (15 + 25 + 20) / 3 = 60 / 3 = 20%, resulting in an average CPU usage of 20%. The system then compares this average with a predefined CPU usage threshold. This threshold should be set based on the edge node's processing capability and expected response performance. In this example, based on historical load data analysis, a node is considered close to overload when the average CPU usage exceeds 75%. This predefined threshold is set to 75%. In this example, the calculated average CPU usage 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 set to false. The system then generates a process queue load summary, which at least includes the calculated average CPU usage (20%). And the number of filtered processes (3), as well as the overload flag (False). Finally, based on this load summary, the system calculates the edge load parameter. The calculation method is to multiply the average CPU occupancy (20%) by the number of processes (3), that is, 20*3=60. At the same time, the overload flag is checked. Because the overload flag is false (False), there is no need to add an additional predefined penalty coefficient. If the overload flag is true, it needs to be multiplied by a penalty coefficient. The setting of the penalty coefficient should reflect the severity of the overload state on the system performance. In this embodiment, It is set to 1.5. The reason for setting it can be that when the system is overloaded, the marginal cost of task processing increases significantly. Setting it to 1.5 means that the load parameter is numerically amplified by 50% to reflect this deterioration. In this embodiment, the average CPU occupancy rate in a certain calculation is 80% (exceeding the 75% threshold) and the number of processes is 5. The overload flag is true, and the marginal load parameter is calculated as 80*5*1.5=600. However, in our current example, the overload flag is false, so the final marginal load parameter is 60. This value 60 is the marginal load parameter L generated in this step. ′ , which quantifies the overall load of processes related to this task type on the edge nodes.

[0106] The steps to obtain the node state vector are:

[0107] 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. The query request with the timestamp is sent to the cloud resource management interface to generate a resource query request object.

[0108] 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 data set;

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

[0110] Specifically, based on the task type code in the structured task description, "VTAN01OBJREC001" in this embodiment, the system first constructs a request message for querying the cloud resource status, which is usually an HTTP request that complies with a specific API specification (such as RESTfulAPI). The target of the request is the address of the cloud resource management service interface, and the request content must indicate the resource type to be queried (such as virtual machine instances and memory). To ensure the legitimacy and timeliness of the request, the system adds authentication information to the message. The specific method is: obtain the current precise timestamp, which is the Unix timestamp 1678886400000 (milliseconds) in this embodiment, and concatenate or combine this timestamp with the task type code "VTAN01OBJREC001", and then calculate its hash value. 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 of the request message (such as the AuthorizationHeader or request body parameter). At the same time, the original timestamp 1678886400000 is also included in the message. In this embodiment, it is placed in a field called "Timestamp". After completing the message construction, the system sends the query request with the timestamp and authentication token to the pre-configured cloud resource management interface URL to form a resource query request object (this object may contain request details and sending status on the client). Subsequently, the system listens for and receives the response message from the cloud resource management interface. The response message is usually in JSON or XML format and contains the queried resource status data. The system parses the response message and extracts the values ​​of two key fields: "Number of available virtual machine instances"

[0111] (AvailableVMInstances) and "memory remaining amount" (MemoryAvailableGB). In this embodiment, the values ​​of these two fields in the response message are 8 and 2048 (GB) respectively. At the same time, the response message should also include a timestamp field generated by the cloud service to verify the freshness of the response. The system extracts this response timestamp, which is 1678886400500 in this embodiment, and compares it with the timestamp 1678886400000 recorded in the local request object when the request was sent before, and calculates the time difference between the two: 1678886400500-1678886400000=500 milliseconds. The system compares this difference with a preset timeout threshold. The setting of the timeout threshold should take into account network delay and processing time to ensure that the acquired status information is sufficiently real-time. In this embodiment, the timeout threshold can be set to 1000 milliseconds This threshold is based on the evaluation of the normal network RTT (Round-Trip Time) and the cloud interface response time. Setting it to 1000ms can ensure that the information is relatively fresh while allowing certain network fluctuations. In this example, the difference of 500 milliseconds is less than the preset threshold of 1000 milliseconds, so the system determines that the timestamp is valid and generates a resource status response data set containing the query results (8 available virtual machines, 2048GB of remaining memory) and the timestamp validity flag (True). Finally, based on this data set, the system checks the timestamp validity flag. Because the flag is true (True), the system will obtain the "number of available virtual machine instances" value 8 and the "remaining memory" value 2048, and splice them into an array in a predefined order (in this embodiment, the number of virtual machines comes first and the memory amount comes last), that is, [8, 2048]. This array [8, 2048] is the generated node state vector V state .

[0112] The steps to obtain the local time estimate are:

[0113] Obtain the computational parameters and CPU usage in the structured task description;

[0114] Based on load intensity, computational parameters, and CPU usage, the local time estimation is calculated using the following formula:

[0115]

[0116] 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 computing capacity parameter, L′ is the load intensity, P is the CPU occupancy value, and T local Estimate the local time spent.

[0117] 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 specific value of the computational load mapping parameter range is used. In this embodiment, based on [1.5, 3.0] Gops, 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 occupancy rate 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 total CPU occupancy rate of the current node that is related to such tasks. The execution of this task is expected to occupy CPU = 30%. The system also needs to obtain the edge load parameter L calculated in the third step. ′ , whose 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 V = 8 and the remaining available cloud memory M = 2048GB are extracted. Next, based on these parameters, the system calculates the local time estimation T local , the calculation should be based on the following formula:

[0118]

[0119] Where P is the expected local CPU usage for executing the task, V and M are the cloud resource status (available VM number and memory), L ′ is the edge load parameter, H is the computational effort, and K is a memory-related scaling factor.

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

[0121] The calculation process is as follows:

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

[0123] Calculation numerator: H·ln(1+L ′ )=(2.25×10 9 )·4.1109≈9.2495×10 9 ,

[0124] Calculate the available CPU portion of the denominator: 100-P = 100-30 = 70,

[0125] Calculate the square root in the denominator:

[0126] Calculate the memory impact in the denominator:

[0127] Calculate the bracketed portion of the denominator:

[0128] Calculate the denominator:

[0129] Finally calculate T local :

[0130] This calculation result T local Approximately 5,627,586, and local execution is expected to take about 5,628 seconds.

[0131] For formula T local Detailed description:

[0132] formula Used to estimate the time required to execute a task locally on the edge node.

[0133] Parameter Description:

[0134] H: The computational effort of the task, which represents the total computational work that needs to be completed by the task.

[0135] L ′ : Edge load parameter, reflecting the overall load of related processes on the current edge node. A larger value indicates a higher load.

[0136] P: The expected local CPU usage (in percentage) for executing the task, indicating the proportion of CPU resources consumed by the task itself.

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

[0138] M: The remaining available cloud memory (GB) (from the node state vector), a measure of cloud memory resources.

[0139] ln: natural logarithm function.

[0140] Square root operation.

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

[0142] Operation logic:

[0143] The formula structure is: total computing amount / (available computing resources*resource adjustment factor).

[0144] Molecule H·ln(1+L ′ ):The basic computational load H is divided by the current edge load L ′ Modulation. ln(1+L ′ )With the load L ′ The higher the load, the longer the effective time required to complete the same amount of calculation (taking into account contention and scheduling overhead).

[0145] Denominator Represents effective local computing power or resources.

[0146] (100-P): Indicates the percentage of CPU processing capacity remaining on the node, excluding the task. The lower the remaining capacity, the smaller the denominator, and the longer the task takes.

[0147] This item introduces the cloud resource status (V and M) to adjust the local time estimation. The richer the cloud resources (the larger V and M), the better the local execution environment will benefit from some global scheduling or resource optimization (in this example, faster access to dependency libraries, model updates, etc.), thus reducing the local time. The linear term M / 100 represents the contribution of the number of cloud VMs and memory to this potential "benefit", and the contribution of the number of VMs is marginally decreasing. The larger the denominator, the stronger the effective computing power, and the time consumed is T local The shorter.

[0148] The usefulness of the formula is that it combines the computational load of the task itself, the real-time load of the edge node, the occupation of local resources by the task execution, and the (possibly indirectly related) global resource status to predict the local execution time. The model attempts to more realistically reflect the impact of load and resource changes on execution time rather than just a simple linear relationship.

[0149] The calculated local time estimate T local ≈5,627,586 is a predicted value that will be used for comparison with the estimated execution time in the cloud. This is a key input for subsequent decisions (whether to execute locally or in the cloud). It represents the estimated time required to process the task on an edge node under this model implementation.

[0150] The steps to obtain the utility index parameters are:

[0151] Based on the computational load parameters and transmission time parameters in the structured task description, the number of available virtual machine instances in the node state vector is extracted to generate a parameter triplet.

[0152] Based on the parameter triples, the estimated cloud time consumption is calculated using the following formula:

[0153]

[0154] Among them, H is the computational parameter, T is the transmission time parameter, V is the number of available virtual machine instances, and T cloud Estimate the time spent in the cloud;

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

[0156] Specifically, we first need to collect three key parameters to form a parameter triple: the first is the computational parameter H from the structured task description, and we continue to use the value H = 2.25 × 10 9 Gops, the second is the transmission time parameter T also from the structured task description, the value T = 19581.47 calculated using the second step, and the third is the node state vector V obtained from the fourth step state = [8,2048], the number of available virtual machine instances V = 8, this triple is (2.25×10 9 ,19581.47,8),Based on this parameter triple, the system then calculates the estimated time T of the task execution in the cloud cloud , the calculation should be based on the following formula:

[0157]

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

[0159] The calculation process is as follows:

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

[0161] Calculation numerator: H·T=(2.25×10 9 )·19581.47≈4.40583×10 13 ,

[0162] Calculate T cloud :

[0163] This calculation result T cloud Approximately equal to 6.7782×10 11 , converted to milliseconds to get T cloud =6778 milliseconds.

[0164] Finally, the system calculates the estimated cloud time consumption T cloud= 6778 milliseconds, which is equal to the local time estimate T calculated in the previous step. local = 5,627,586 milliseconds to form a combination of two values, a binary group [T local , T cloud ] That is, [5627586, 6778], this combination is the generated utility index parameter.

[0165] For formula T cloud Detailed description:

[0166] formula Used to estimate the total time required to offload tasks to the cloud for execution (including transmission and processing).

[0167] Parameter Description:

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

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

[0170] V: The number of virtual machine instances available in the cloud.

[0171] T cloud : The estimated total execution time on the cloud.

[0172] Operation logic:

[0173] The formula attempts to combine transmission costs and computing time in the cloud.

[0174] Numerator H·T: Multiply the task computational effort H by the transmission time parameter T.

[0175] Denominator V 2 +1: The square of the number of available virtual machines V in the cloud plus 1. Use V 2 The cloud processing capacity increases nonlinearly (quadratically) with the number of available instances, reflecting the significant acceleration effect brought by large-scale parallel processing. The addition of 1 is to avoid the denominator being zero when V=0 and to ensure that even with only one VM, there is still basic processing capacity. The larger the denominator, the stronger the cloud processing capacity. The total time taken is T cloud The shorter.

[0176] Overall logic: In this embodiment, the total cloud computing time is proportional to (computational amount * transmission factor) and the available cloud computing resources (in V 2 is inversely proportional to the

[0177] The usefulness of the formula is that it combines the cost of data transmission (represented by T) and the computing power of the cloud (represented by V)2 Reflection) are combined to evaluate the total execution time in the cloud, and V 2 This term reflects the scale effect of cloud resources and can better capture the advantages of parallel processing compared to simple models (such as T+H / speed).

[0178] The calculated cloud time estimate T cloud = 6778 milliseconds and the local time estimate T local =

[0179] 5,627,586 milliseconds together constitute the utility index parameter. The core role of this parameter is to provide the basic judgment basis required for decision-making: comparing these two values ​​can initially determine whether it is faster to keep the task locally or offload it to the cloud. In this example, T cloud (about 6.8 seconds) much shorter than T local (about 5628 seconds), indicating that from a purely time-consuming perspective, offloading this task to the cloud is a significantly better option.

[0180] The steps to obtain the candidate plan set are:

[0181] Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameter, 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 hashed with SHA-256 to generate a 128-bit feature vector, which is used as the query index key for the pre-stored plan library.

[0182] Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored plan library is called. With the benchmark time reference value as the central value, all related entries are retrieved within a floating range of ±15%. Entries with a complete match in the task type code and a plan status marked as "available" are selected. The search results are sorted in descending order by the plan's thermal value (plan thermal value = number of calls in the last 7 days × priority coefficient) to generate a preliminary set of matching plans.

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

[0184] Specifically, based on the utility index parameter obtained in the previous step, that is, the local time estimation T local =

[0185] 5,627,586 milliseconds and cloud time estimate T cloud = 6778 milliseconds, the system first performs a comparison operation and sets T localCompare with the value of T cloud and select the smaller value as the reference benchmark time-consuming value. In this example, 6778 <5627586>, so the reference benchmark time-consuming value 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 included 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 benchmark time-consuming value 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. During the query, the system uses the reference benchmark time-consuming value T base = 6778 as the central query point and defines a floating range. In this embodiment, ±15%. Calculate 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. Some performance indicators (such as historical average time-consuming) of these entries fall 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"

[0186] (Available), in this embodiment, 5 preliminary matching plans that meet the conditions are retrieved. The system then sorts these 5 plans in descending order according to the "plan thermal value". The calculation method of the "plan thermal value" is: the total number of times the plan has been successfully called in the past 7 days multiplied by a preset priority coefficient. The setting of the priority coefficient can be based on factors such as the stability of the plan, resource consumption efficiency, or business importance. In this embodiment, the high stability plan coefficient is set to 1.2, the standard plan is 1.0, and the experimental plan is 0.8. In this embodiment, a plan A has been called 100 times in the past 7 days, with a priority coefficient of 1.0 and a thermal value of 100; plan B has been called 80 times, with a priority coefficient of 1.2 and a thermal value of 96; plan C has been called 120 times, The priority coefficient is 0.8, and the thermal value is 96; Plan D is called 50 times, with a priority coefficient of 1.0 and a thermal value of 50; Plan E is called 60 times, with a priority coefficient of 1.0 and a thermal value of 60. The sorting results are A(100), B(96), C(96), E(60), and D(50) (the same thermal value can be sorted by other rules, such as the most recent call time). After sorting, the preliminary matching plan set {A, B, C, E, D} is obtained. The system further fine-screens this preliminary set, extracting the metadata description field of each plan and searching for the "plan startup 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 benchmark time reference value T base =6778 for comparison. The judgment condition is: whether the predicted time consumption of the plan start-up is less than T base 1.2 times, that is, less than 6778×1.2=8133.6 milliseconds. In this embodiment, the predicted startup time of Plan A is 7000ms, Plan B is 8000ms, Plan C is 8500ms, Plan E is 7500ms, and Plan D is 6000ms. The predicted startup time of Plans A, B, E, and D are all less than 8133.6ms, and the 8500ms of Plan C is greater than the threshold. Therefore, Plans A, B, E, and D are retained as valid candidate plans, and Plan C is screened out. Finally, the system merges the unique identifiers of all valid candidate plans (plan numbers in this embodiment) and performs deduplication processing (although there is no duplication in this example) to generate the final candidate plan set. In this embodiment, the list of plan numbers is: [PlanID_A, PlanID_B, PlanID_E, PlanID_D]. This set is the specific plan list provided to the subsequent decision module for selection and execution.

Claims

1. A production scheduling intelligent management and control system based on cloud-edge collaboration, characterized by: The system comprises: The task feature aggregation module extracts the task type code based on the input task request, queries the task type and computing amount mapping table in the pre-stored knowledge base, matches the task type and extracts the computing amount parameters, generates computing amount mapping parameters, calculates the transmission time parameters based on the computing amount mapping parameters, and generates a structured task description; A node status retrieval module collects the CPU occupancy value in the current edge node process queue based on the task type code in the structured task description, generates edge load parameters, sends a resource status query request to the cloud, receives the number of available virtual machine instances and remaining memory data returned by the cloud, and generates a node status vector; A utility decision index module calculates a local time estimate based on the edge load parameter in the node state vector and the remaining cloud memory data, calculates a cloud time estimate based on the computational load parameter and the number of virtual machine instances, and superimposes the transmission time parameter in the structured task description to generate a utility index parameter. The disposal plan storage module retrieves the associated entries of the time consumption threshold and the task type in the pre-stored plan library based on the local time consumption valuation and the cloud time consumption valuation in the utility index parameter, extracts the set of plan numbers that meet the threshold range, and generates a set of candidate plans.

2. The intelligent production scheduling management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the calculation amount 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, the 3rd to 6th characters in the string are intercepted as the core identifier, the task type and computing amount mapping table of the pre-stored knowledge base is traversed, and the core identifier is compared with the task type encoding in the mapping table one by one to obtain the locked task type entry; Based on the locked task type entry, the upper and lower limit values ​​of the "basic calculation amount value range" field defined in the mapping table are extracted to obtain the calculation amount mapping parameters.

3. The intelligent production scheduling management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the structured task description are: Based on the computational workload mapping parameters, the number of bytes of the task data packet size, the real-time requirement threshold, the real-time CPU occupancy rate of the edge node, and the remaining amount of available cloud memory are extracted to obtain a four-tuple parameter set; Calculating a transmission time parameter based on the four-tuple parameter set; The transmission time consumption parameter is combined with the task type code and the calculation amount mapping parameter to generate a structured task description according to the field name.

4. The intelligent production scheduling management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the edge load parameters are: Based on the task type code 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 the process instances containing the process identifier prefix are filtered to obtain a filtered process instance set; According to the filtered set of process instances, the CPU usage of each instance is counted, and the average value of the CPU usage is calculated. If the average value exceeds a predefined threshold, a process queue overload flag is triggered, and a process queue load summary is generated; Based on the process queue load summary, the average CPU occupancy is multiplied by the number of processes. If the overload flag is true, a predefined penalty coefficient is additionally added to generate an edge load parameter.

5. The production scheduling intelligent management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the node state vector are: Based on the task type code in the structured task description, a resource status query request message is constructed, a hash value of the current timestamp and the task type code is added to the message as an authentication token, and 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 a response message returned by the cloud, parse the "number of available virtual machine instances" field and the "remaining memory" field in the response data, verify whether the difference between the timestamp in the response message and the local request object is less than a preset timeout threshold, and generate a resource status response data set; According to the resource status response data set, if the timestamp validity flag is true, the number of available virtual machine instances and the remaining memory are sequentially concatenated into an array to generate a node status vector.

6. The intelligent production scheduling management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the local time estimation are as follows: Obtaining the computational load parameters and CPU occupancy rate in the structured task description; Calculate the local time estimate based on load intensity, computing parameters, and CPU usage.

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

8. The intelligent production scheduling management and control system based on cloud-edge collaboration according to claim 1 is characterized in that: The steps for obtaining the candidate plan set are: Based on the local time consumption estimate and the cloud time consumption estimate in the utility index parameter, 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 a SHA-256 hash operation to generate a 128-bit feature vector as a query index key for the pre-stored plan library; Based on the 128-bit feature vector, the distributed inverted index interface of the pre-stored emergency plan library is called. With the benchmark time reference value as the central value, all related entries are searched within a floating range of ±15%. Entries with a complete match in task type code and an emergency plan status marked as "available" are selected. The search results are sorted in descending order by the emergency plan heat value (the emergency plan heat value = the number of calls in the last 7 days × the priority coefficient). This generates a preliminary set of matching emergency plans. Based on the preliminary matching plan set, the metadata description field of each plan is extracted. If the predicted time consumption of the plan startup is less than 1.2 times the baseline time consumption reference value, it is retained as a valid candidate plan. The numbers of all valid plans are merged and duplicates are removed to generate a candidate plan set.

Images