Intelligent factory data collaborative processing method based on industrial internet of things

Abstract

This invention discloses a data collaborative processing method for smart factories based on the Industrial Internet of Things (IIoT), specifically relating to the field of collaborative scheduling of production resources in IIoT and smart factories. The method includes acquiring task records and resource occupancy records for the same period on the production side, locating the first unexecuted action of an incomplete task, reading the planned start time and occupancy start and end times of the resource number to form a task table on the edge side; based on the task table, reading the first unexecuted action as the target action, tracing the occupied tasks to form a candidate group, canceling the subsequent resource occupancy of each candidate group task, deleting the current task if still blocked, and restoring the current task when the blockage is lifted, forming a verified conflict group after one round without deletion; identifying the verified conflict group on the production side based on the actual resource occupancy relationship, determining the rewrite group using an incremental implicit hit set algorithm, and having the cloud perform branch pricing rearrangement of the task execution paths within the group based on freezing resource occupancy outside the rewrite group.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IIoT) and smart factory production resource collaborative scheduling technology, and more specifically, to a smart factory data collaborative processing method based on IIoT. Background Technology

[0002] Existing smart factories mostly collect data such as equipment status, process progress, material location, tooling occupancy, and handling tasks through the Industrial Internet of Things (IIoT). The cloud-based scheduling platform then generates production plans based on order priority, process relationships, and resource utilization. When equipment delays, buffer congestion, or changes in the status of shared resources occur on-site, the task order and resource allocation are adjusted based on the data uploaded from the terminal. Taking a production scenario where multiple production lines share testing equipment, special tooling, automated guided vehicles, and entrances and exits of automated warehouses as an example, a certain process often needs to obtain the equipment, tooling, handling units, and buffer locations simultaneously before execution. Furthermore, completed clamping, transfer, warehousing, or equipment startup actions cannot be arbitrarily canceled due to changes in cloud scheduling, and other tasks that have already met the execution conditions should not be modified synchronously. In this situation, even if the schedule generated by the cloud based on the periodic data upload does not have direct overlap in time arrangement, it may still result in partial inability to execute due to the offset of the completion time of the on-site actions and the mutual constraints of multiple types of resources. Specifically, tasks may remain in the pending state for a long time, related resources may be shown as allocated but cannot be obtained at the same time, the end side may report blocking information multiple times and the cloud may repeatedly expand the adjustment scope and further change the order of tasks that could originally be executed normally. The reason for the above situation is that the existing uploaded content on the client side can usually only reflect the results of device busyness, task delay or resource consumption, and cannot further determine which tasks are causing the current action to fail to be executed, nor can it limit the scope of tasks that actually need to be adjusted in the cloud. The technical problem this application aims to solve is: how to identify and upload the minimum task combination that causes the next action to fail to be executed based on the actual resource relationship on the end side, so that the cloud only adjusts the tasks within the combination and keeps the resource allocation relationship outside the combination unchanged. Summary of the Invention

[0003] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a smart factory data collaborative processing method based on the Industrial Internet of Things. This method identifies and verifies conflict groups at the production end based on actual resource occupancy relationships, determines rewrite groups using an incremental implicit hit set algorithm, and then, based on freezing resource occupancy outside the rewrite groups, performs branch pricing rearrangement of task execution paths within the groups to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a smart factory data collaborative processing method based on the Industrial Internet of Things, comprising: S1. Obtain task records and resource usage records for the same period from the production side, locate the first unexecuted action of the unfinished task, read the planned start time and usage start and end time of the resource number, and form the task table on the end side. S2. Based on the task table on the end side, read the first resource-incomplete action as the target action, trace the occupied tasks to form a candidate group, cancel the subsequent resource occupation of the candidate group tasks one by one, delete the current task if it is still blocked, restore the current task when the block is lifted, and form a verified conflict group after one round without deletion. S3. The implicit hit set algorithm is executed on the end side. The task is grouped as a binary item and each designated conflict group is hit as a constraint. The branch is based on the task number and the non-hit branches are truncated. The complete branch with the highest number of rewrite slots is read as the rewrite group. After canceling the rewrite group resource occupation, the task table on the end side is checked. If blocked, it returns to S2. If not blocked, the rewrite group is output. S4. Upload the terminal task table containing the rewriting group and the approved conflict group through terminal-cloud collaboration. Execute the branch pricing algorithm in the cloud, freeze the resource occupation of tasks outside the rewriting group, write the subsequent path of the rewriting group task as a column, so that each task takes one column, the same resource time slot is reserved for one column, and one task of each approved conflict group avoids the original resource time slot. The column cost is the sum of the number of delayed beats and the number of rewriting time slots. Add columns according to the reduced cost. For fractional columns, form two branches according to the fixed and disabled resource time slots. Read the integer column group to form the cloud scheduling result. S5. After the cloud-edge collaboration, the cloud scheduling results are sent out. The production end rewrites the resource occupancy record and verifies the resource acquisition status of the first unexecuted action at the start of the plan. After the resource is acquired, it is written into the execution record and the action sequence is advanced. If it is blocked, it returns to S2.

[0005] In a preferred embodiment, S1 includes: S11. Collect task records by task number and sort them by action order. When multiple task records correspond to the same task number and action order, retain the last task record in ascending order of record beat number to form a task action chain. S12. Read the action completion time along the task action chain, determine the first action that has not been written with an action completion time as the first unexecuted action, and write the resource number and the plan start time corresponding to the first unexecuted action into the pending task line; The action completion timer refers to the timer number recorded by the unified scheduling clock when the production end confirms that the corresponding action has been completed and writes the completion status. A resource number is a unique identifier assigned to a production resource. The same resource number is used for the same production resource in both the task record and the resource usage record. The start of the scheduled auction refers to the auction number marked by the unified scheduling clock when the corresponding action begins to acquire and occupy resources according to the cloud scheduling results.

[0006] In a preferred embodiment, S1 further includes: S13. Collect resource occupancy records by resource number, extract all occupancy start and end times and sort them by time number, divide resource time periods by adjacent time numbers, and then write the occupancy tasks covering each resource time period into the corresponding resource time period to form a resource occupancy chain. The resource occupancy record refers to the record written by the production end for a single use of resources. It records the resource number, the task number of the occupancy task, the start time of occupancy, and the end time of occupancy, which are used to indicate the range of production resources occupied by the corresponding task. The start and end times of occupation include the start time of occupation and the end time of occupation. The start time of occupation is the first time when the task acquires the resource, and the end time of occupation is the first time after the resource is released from occupation. The two limit the resource occupation range of left-closed and right-open. When the resource has not been released, the end time of occupation is written into the release time determined by the current scheduling result, and is rewritten into the actual release time after the resource is released. A resource time period refers to the left-closed, right-open interval of the start and end slots under the same resource number, where the resource occupancy relationship remains unchanged within the same resource time period. An occupied task refers to a task whose resource occupation interval intersects with and covers the current resource time period. It is written to the resource time period with the corresponding task number. When multiple occupied tasks correspond to the same resource time period, they are written separately according to the task number to preserve resource conflict relationships. S14. Align the pending task row with the resource occupation chain according to the resource number, read the occupied tasks and occupation start and end times of the resource time period where the plan starts, and write them into the end-side task table according to the task number and action order.

[0007] In a preferred embodiment, S2 includes: S21. Read the task table on the end side according to the start time of the scheduled photo, task number and action order. Record the first unexecuted action that falls within any required resource occupation range when the start time of the scheduled photo is scheduled as the target action, and write the corresponding occupation task into the candidate group. The resource occupancy range refers to the range of left-closed and right-open auction numbers formed by the start auction and the end auction in the same resource occupancy record. Within this range, the corresponding resource is used by the occupancy task. The start auction is included in this range, but the end auction is not. S22. Taking the occupied tasks in the candidate group as the object, read the first unexecuted action of the occupied task and the corresponding required resources. Continue to write the occupied tasks that are scheduled to start bidding in the corresponding resource occupation range but have not yet been written into the candidate group into the candidate group. Repeat the process until no more tasks are added to the candidate group, forming a blocking relationship table.

[0008] In a preferred embodiment, S2 further includes: S23. Copy the resource occupancy record corresponding to the candidate group, read the current task by task number and cancel the resource occupancy of the current task from the first unexecuted action, then replay the resource acquisition and release process of the remaining tasks according to the start and end of the occupancy, read the occupancy status of each resource required when the target action reaches the start of the plan, and form the cancellation result of the current task. S24. If the cancellation result indicates that the target action still has resources occupied, delete the current task from the candidate group and retain the resource occupation record after cancellation. If the cancellation result indicates that the target action has obtained all the required resources, restore the current task and the corresponding resource occupation record. If there are still tasks to be deleted after completing one round of reading, re-execute S23. If no tasks are deleted after one round of reading, record the candidate group as the approved conflict group.

[0009] In a preferred embodiment, S3 includes: S31. Based on the task table on the end side, count the number of time slots occupied by each task since the first unexecuted action, set the status of the task written into the rewrite group as a binary item, and form a hit relationship table according to the relationship between the task and the approved conflict group. The time slot number refers to the total number of resource slots occupied by a task since the first unexecuted action. When counting, each resource occupation record is split into resource slots according to the resource number and the slot number. When the same task occupies different resources in the same slot, they are counted separately. When the same resource slot is written repeatedly, it is counted only once. S32. The edge executes the incremental implicit hit set algorithm, with each designated conflict group containing one entry task as a constraint, and the total number of time slots occupied by the entry tasks as the scheduling cost. Linear relaxation is performed on the binary terms and the branch boundary is read. The first fractional binary term is read according to the task number to establish the entry branch and the non-entry branch. Branches that cannot hit the designated conflict group or whose branch boundary is not lower than the scheduling cost of the existing integer branch are deleted. The first integer branch is read in ascending order of scheduling cost to form a candidate rewrite group. The process of executing the incremental implicit hit set algorithm is as follows: establish a binary entry item for task grouping and a hit limit for the verified conflict group based on the hit relationship table, solve the candidate rewrite group corresponding to the current hit relationship table; then cancel the resource occupation of the candidate rewrite group and replay the task table on the end side. When a blocked action occurs after replay, a new verified conflict group is generated. The new verified conflict group is added to the hit relationship table, and the existing branches that do not hit the new verified conflict group are deleted and the solution continues until no blocked action occurs during resource replay and no branch can be read to form a candidate rewrite group with lower scheduling cost. Incoming tasks refer to tasks in the current branch whose binary items have a value of one and whose resource usage is included in the rewriting scope; The process of performing linear relaxation on binary terms and reading branch boundaries is as follows: change the values ​​of unfixed binary terms in the current branch from zero or one to values ​​between zero and one, retain the constraint that each approved conflict group must contain at least one inbound task, and use the sum of the values ​​of each binary term multiplied by the corresponding time slot number as the solution objective; after completing the linear solution, use the obtained objective value as the current branch boundary value, and delete the current branch when there is no feasible solution to the linear problem; Branch scheduling cost refers to the sum of the number of time slots corresponding to all grouped tasks in an integer branch, which is used to represent the number of resource slots that need to be canceled and reconfigured when rewriting the production resource allocation according to the integer branch.

[0010] In a preferred embodiment, S3 further includes: S33. Copy the task table on the end side and cancel the resource occupation corresponding to the candidate rewrite group. Start the shooting and action sequence replay of the resource acquisition and release process of the remaining tasks according to the plan. When an obstructed action occurs, trace the occupied task along the obstructed resource, delete the traced task item by item and repeat the replay. Keep the task whose obstructed action is lifted after deletion to form a newly added approved conflict group. S34. Write the newly added designated conflict group into the hit relationship table, retain the existing branches that still hit the newly added designated conflict group and return to S32, until no blocked action occurs during resource replay and the branch boundary value of all unread branches is not lower than the scheduling cost of the candidate rewrite group, and output the candidate rewrite group as the rewrite group.

[0011] In a preferred embodiment, S4 includes: S41. Upload the task table of the end side containing the rewriting group and the approved conflict group to the cloud through end-cloud collaboration, freeze the resource occupation of tasks outside the rewriting group, and establish an action time slot diagram with the first unexecuted action of the task in the rewriting group, the order of subsequent actions, the resource number and the start and end time of occupation. Connect the nodes in the adjacent actions where the end time of the previous action is not later than the start time of the next action and the resource number satisfies the task record to form an execution path domain. S42. Read an execution path for each task from the execution path domain along the action sequence and write it as the initial path column. With the constraints of selecting one path column for each task, reserving one task for the same resource time slot, and ensuring that at least one task in each approved conflict group avoids the original resource time slot, add the number of time slots that the path completion time slot increases relative to the planned completion time slot to the number of time slots that deviate from the original resource time slot to form the column cost. Perform linear relaxation on the initial path column and output the task constraint value, resource time slot constraint value, and conflict group constraint value. The resource time slot refers to a unit occupied interval jointly identified by the resource number and the auction number. The starting point is the current auction number, and the ending point is the auction number after the current auction number. When the start and end auctions of the execution path occupying the resource cover the unit occupied interval, the occupied value of the corresponding path in the resource time slot is recorded as one; otherwise, it is recorded as zero.

[0012] In a preferred embodiment, S4 further includes: S43. Write the task constraint value to the corresponding task starting point, write the resource slot constraint value to the node occupying the corresponding resource slot, and write the conflict group constraint value to the node that avoids the original resource slot. Accumulate the node cost along the action sequence and retain the predecessor in ascending order of node cost. Backtrack to find the execution path that is not written to the current path column and has a negative reduced cost, add it to the current path column and return to S42, until no execution path with a negative reduced cost is generated for any task. The reduction cost refers to the column cost of the execution path minus the sum of the products of the corresponding coefficients and limit values ​​of the execution path in the task constraints, resource slot constraints, and conflict group constraints; a negative reduction cost indicates that adding the execution path to the current path column can reduce the linear relaxation target value. The process of recursively accumulating node costs is as follows: write the negative value of the corresponding task limit as the task starting cost, read each node in the action sequence, calculate the number of delayed beats and the number of beats deviating from the original resource time slot for the current node relative to the predecessor node, and then subtract the resource time slot limit value corresponding to the current node occupying the resource time slot and the conflict group limit value corresponding to the current node avoiding the original resource time slot. Add the obtained node increment to the cumulative cost of the predecessor node; when there are multiple predecessors for the same node, retain the predecessor with the highest cumulative cost value until the task endpoint is reached. The cumulative cost at the task endpoint is used as the reduced cost of the corresponding execution path. S44. When the linear relaxation result contains fractional column values, read the first fractional occupation item by task number, action order, resource number and start time. Create branch nodes with fixed corresponding occupation items and disabled corresponding occupation items respectively. Delete path columns that do not conform to the branch rules in each branch node and return to S42. Stop solving for branch nodes whose branch boundary value is not lower than the total cost of the existing integer column group until all branch nodes are processed. Then read the first integer column group in ascending order of total cost to form the cloud scheduling result.

[0013] In a preferred embodiment, S5 includes: S51. Receive the cloud scheduling result through end-to-end cloud collaboration, extract the resource number and start and end time of the first unexecuted action and subsequent actions according to the task number, write the corresponding resource occupation into the scheduling sub-table, and replay the resource acquisition and release process with the execution records already written by the production end. For scheduling sub-table records that overlap with the occupied interval of executed actions, extend them to the corresponding resource release time to form the pending execution occupation table. The production end refers to the edge processing node set up on the production site and connected to the manufacturing equipment, which is used to collect task execution status and resource occupancy status, receive cloud scheduling results and control the execution of corresponding tasks. Execution records refer to the task status records written by the production end when an action begins or ends. They include at least the task number, action sequence, resource number, actual start time, and actual completion time, and are used to reconstruct the actual acquisition and release process of resources. The action occupancy range refers to the range of left-closed and right-opening time slots formed from the time slot when the action actually acquires resources to the time slot when the action actually releases resources. Within this range, the corresponding resources are occupied by the action being executed. The scheduling sub-table record refers to the resource allocation record copied from the cloud scheduling result and not yet corrected based on the production execution record. It includes task number, action order, resource number, planned start time, and planned end time. S52. When the scheduled start time is reached, the production end reads the pending occupancy table record corresponding to the first unexecuted action in the order of resource number, writes the resources that are not occupied by other tasks in the current shot into the resource acquisition table, and stops reading when the occupied resource is read, thus forming the resource acquisition result. The pending occupancy table record refers to the resource allocation record formed after the scheduling sub-table record has been corrected for the occupancy range of executed actions. It includes the task number, action sequence, resource number, and the corrected start and end times of the occupancy for the unexecuted actions. It is used by the production end to verify the resource acquisition status at the start of the plan. S53. When the resource acquisition result covers all resource numbers corresponding to the first unexecuted action, write the resource acquisition table into the resource occupancy record and generate an execution record, then write the next action as the first unexecuted action; when the resource acquisition result does not cover all resource numbers, delete the record written into the resource acquisition table this time, write the blocking resource and its occupancy task into the end-side task table and return to S2.

[0014] The technical effects and advantages of this invention are as follows: 1. This solution traces the actual resource usage and verifies the conflict group on the edge, so that the cloud only rewrites the related tasks, thereby maintaining the stability of the established resource allocation relationship outside the group; 2. By assigning multiple identified conflict groups to the incremental implicit hit set for unified solution, the size of the rewrite group can be reduced, and the number of time slots involved in resource rearrangement can be reduced accordingly. 3. Freeze the resource usage of tasks outside the group that are being rewritten, and only reconstruct the execution path of tasks within the group, which can reduce repeated adjustments to the global schedule caused by local blockages; 4. Set resource capacity and conflict avoidance limits in the action time slot diagram to enable multiple resource acquisition relationships to participate in the same solution process, thereby alleviating the problem that the plan can be scheduled but is difficult to execute on site; 5. Correcting cloud scheduling results with actual execution records and performing synchronous verification and one-time submission on action resource groups can relatively improve the consistency between planned arrangements and on-site resource status. Attached Figure Description

[0015] Figure 1 This is a flowchart of the intelligent factory data collaborative processing of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Refer to the instruction manual appendix Figure 1 The present invention provides a smart factory data collaborative processing method based on the Industrial Internet of Things, comprising: S1. Obtain task records and resource usage records for the same period from the production side, locate the first unexecuted action of the unfinished task, read the planned start time and usage start and end time of the resource number, and form the task table on the end side. To standardize the recording of task status and resource occupancy status on the production side, the cloud issues a cycle number, cycle start time, cycle end time, unified start time, and single-cycle duration before the start of each scheduling cycle. The production side converts the record cycle number based on the difference between the collection time and the unified start time, and writes the production side number, cycle number, record cycle number, and writing order into the task record and resource occupancy record. Resource occupancy records where the start of the occupancy period is earlier than the start of the cycle and the end of the occupancy period is later than the start of the cycle are still included in the current scheduling cycle, thus preserving the resource occupancy relationship that continues across cycles; the specific processing is as follows; Task records from different production ends are first filtered by cycle number. Records with a record number no later than the end of the cycle are entered into the current processing scope. Each task record includes at least the task number, action sequence, record number, write sequence, action start time, action completion time, resource number, and plan start time. After completing the field validation, the task records are collected in S11 by task number, and then arranged in order by action sequence, record time number and write sequence. Duplicate records with identical fields are retained as one. When the fields corresponding to the same task number, action sequence, and record beat number are inconsistent, the record with the later writing sequence is retained. When the same task number and action sequence still correspond to multiple valid records, the record with the later record beat number is retained, thus forming a task action chain. Records with missing task numbers, action sequences, or record beat numbers are written to the exception record table and do not participate in the generation of task action chains. The action status is determined by the action start beat and the action completion beat: when the action completion beat has been written, it is recorded as a completed action; when the action start beat has been written and the action completion beat is empty, it is recorded as an action in progress; when both the action start beat and the action completion beat are empty and all preceding actions have been completed, it is recorded as the first unexecuted action. After completing the above judgment along the task action chain, S12 reads the resource number and the start date of the scheduled action corresponding to the first unexecuted action and writes it into the pending task line; When an action requires multiple resources, each resource number forms a row of tasks to be scheduled. Each row shares the task number, action priority, and scheduled start time, and is associated with the same action resource group through the task number and action priority. Resource usage for actions in progress remains frozen, and no pending task lines are generated; if a resource number is missing, the corresponding action is written to the exception log table. When the action is completed, the unified scheduling sequence number corresponding to the time when the production end receives the manufacturing equipment completion signal and writes the completion status is captured. When the cloud scheduling result is scheduled to be captured, the unified scheduling sequence number corresponding to the time when the action begins to acquire resources is captured. Data processing on the resource side is based on the resource number. Each resource occupancy record includes the resource number, occupancy task number, action sequence, occupancy start time, occupancy end time, record time number, and write sequence. After completing the deletion of duplicate records and the correction of conflicting fields, S13 extracts all valid start and end times under the same resource number, adds the periodic start and end times, removes duplicates and arranges them by time number, and then forms a resource time period with left-closed and right-open by adjacent time numbers. When the resource occupation interval covers the current resource time period, the corresponding occupied task is written to the current resource time period. When no task covers it, it is written to the idle state. When multiple tasks cover it at the same time, they are written separately according to the task number. When the end of the occupation period is later than the start of the occupation period, a valid resource occupation interval is formed. If the end of the occupation period is empty, the release period specified by the current scheduling result is written first. After receiving the actual release record, it is rewritten as the actual release period and the resource time period of the affected resource number is reconstructed. Records whose end of occupation period is not later than the start of occupation period are entered into the exception record table. Each resource time period consists of several resource time slots, which are identified by a resource number and a single time slot number. Production resources with multiple independent workstations, warehouses, or carriers are each assigned a resource number, so that a resource number corresponds to only one item within the same resource time slot. When a task is associated with a resource, the task row to be scheduled is first matched to the corresponding resource occupation chain according to the resource number, and then the resource time period where the plan starts bidding is read according to the left-closed and right-open rules; when the plan starts bidding equals the start of the resource time period, it is assigned to the current resource time period, and when it equals the end of the resource time period, it is assigned to the next resource time period; After matching is completed, S14 writes the task number, action order, resource number, planned start time, resource time period start and end time, resource status and occupied task number into the terminal task table. Multiple pending task rows corresponding to the same action continue to be associated according to the task number and action order, so that subsequent processing can uniformly verify the action resource group. When the planned auction starts outside the current cycle's auction number range, the pending task line is transferred to the cycle to which the planned auction starts; when the resource number is not registered in the resource occupancy chain, the corresponding pending task line is written to the exception record table. After the task table is generated on the client side, the period number, table version number and the cutoff record time are written at the same time. When a new valid task record or resource usage record is added, the table version number is incremented, and only the record corresponding to the affected task number or resource number is rebuilt. Therefore, the task table on the edge can simultaneously reflect the current action position of the task, the start time of the action plan, and the resource occupancy status at the corresponding time number. Taking the periodic time number range of 1200 to 1260 as an example, action 1 of task T17 has been written to action completion time 1208, action 2 has been written to action start time 1210 and action completion time is empty. Action 2 is thus recorded as an action in execution and maintains resource occupancy. Action 1 of task T18 has not yet been written to action start time, and all preceding actions have been completed. Action 1 is thus recorded as the first unexecuted action. Action 1 of task T18 requires resources R07 and R09. The planned start time is 1220. The resource occupancy chain shows that R07 is occupied by task T16 from 1215 to 1224, and R09 is idle during the resource period of 1220. Based on this, the task table on the end side writes the idle status of the occupying task T16 corresponding to R07 and the idle status of R09 respectively, so that subsequent processing can directly identify the blocking task and the idle resources.

[0018] S2. Based on the task table on the end side, read the first resource-incomplete action as the target action, trace the occupied tasks to form a candidate group, cancel the subsequent resource occupation of the candidate group tasks one by one, delete the current task if it is still blocked, restore the current task when the block is lifted, and form a verified conflict group after one round without deletion. After the task list is formed, the first actual blocked action needs to be identified from the tasks that have not yet been executed, and the tasks related to the blocked resources are gradually converged into a conflict range that can be used for subsequent rewriting calculations. During processing, the period number, table version number and end record of the task table on the terminal side are used uniformly. The resource occupation corresponding to the action in execution is kept frozen, and the cancellation verification is only performed on the planned resource occupation formed by the action that has not yet started. When the same action requires multiple resources, each resource is associated with the same task number and action priority to form an action resource group, and a one-time check and one-time acquisition method is adopted; the specific processing is as follows; The determination of the blocked entry point is based on whether the action resource group can acquire all resources at the start of the plan; the production end compares the start of the plan, the task number, and the action sequence in sequence, where the task number is encoded with a fixed length and compared in byte order, and reads the first unexecuted action that is ranked first. Then in S21, check whether the start of the plan falls within the left-closed and right-open resource occupancy range of each resource in the action resource group. When any resource is occupied by other tasks in this phase, record the current action as the target action and write the occupying task number, blocking resource number, blocking start and end phases and target action order into the candidate group. When the resources occupied by the previous action are allowed to be transferred to the target action according to the task record, the resources are considered to have been acquired; if the task record requires release before acquisition, failure to write a release record will still be recorded as blocking. If a resource occupancy record is missing a resource number, an occupancy task number, or an occupancy start / end timer, the current record will be entered into the abnormal record table and will not be included in the target action determination. The candidate group also needs to cover the resource dependencies behind the directly blocking task to avoid only retaining the surface-level occupancy relationship; for the tasks in the candidate group that have not yet been read, first locate the first unexecuted action and obtain the corresponding action resource group, and then check which resource occupancy intervals the planned start of the action falls into; Therefore, in S22, the occupied tasks that have not yet entered the candidate group are continued to be written, and the previous task number, the next task number, the blocking resource number and the blocking number range are recorded simultaneously to form a blocking relationship table. When each task is written to the candidate group, an accessed flag is set. When the same task reappears on a different resource, only the blocking relationship is added, and it is not written repeatedly. When tracing back to a visited task, the loop relationship is preserved and the expansion along that relationship is stopped until all tasks in the candidate group have been visited. The occupancy formed by the action during execution is marked as frozen occupancy in the blocking relationship table, and the original occupancy start and end times are maintained during subsequent replays; To determine whether candidate group members were indeed involved in the obstruction of the target action, resource replay needs to be performed without rewriting the production site records; The production side copies the relevant task records and resource usage records of the candidate group to form a working copy. The current task is read according to the task number. Then, in S23, only the resource usage of the current task that has not yet started since the first unexecuted action is cancelled. Completed actions, actions in execution, and actual usage that has not yet been released are retained. Remaining resource events are replayed in ascending order of their time slots. Within the same time slot, resource release is performed first, followed by resource acquisition according to the planned start time slot, task number, and action order. When an action corresponds to multiple resources, the time slot status of all resources in the action resource group is read first. Once all resources are idle, all resource occupancy is written at once. If any blocking resource exists, no resource occupancy is written. After replaying to the start of the target action plan, read the occupied tasks and start and end times of each resource in the action resource group, generate the cancellation result of the current task, and save it in the working copy; The elimination of candidate groups adopts a combination of item-by-item cancellation and full-round review to ensure that the final result remains undeleted based on the member inclusion relationship; If resources are still occupied by the target action after the current task is canceled, S24 removes the current task from the candidate group and retains the subsequent resource occupancy that has been canceled in the working copy; when the target action acquires all resources of the action resource group in the same beat, the current task and the corresponding resource occupancy record are restored. After completing a round of task reading, if a candidate group is deleted, a new working copy is created with the deleted candidate group and the reversal verification is performed again; if no task is deleted after a round of reading, the candidate group, target action, blocking resource number and the original blocking number range are written together as the approved conflict group. The verification conflict group satisfies the following conditions: when all members are retained, the target action is blocked; when any member's subsequent resource occupation is revoked, the target action is unblocked. The group code is formed in ascending order of task number; if the same group code already exists, it will not be written again. After completing the above processing, the endpoint can obtain the verified conflict group with the target action and the original blocking resource time slot from the actual resource relationship; taking the action two plan of task T18 to acquire R07 and R09 at the same time in time slot 1220 as an example, R07 is occupied by task T16 until time slot 1224, and R09 is occupied by task T21 until time slot 1222. After tracing, it is found that the first unexecuted action of task T16 is blocked by R03 occupied by task T12; the candidate group is written into T16, T21 and T12 accordingly; After virtual cancellation of T12, the target action is still blocked by R07 and R09, and T12 is removed from the candidate group; after cancellation of T16, R07 is released and the target action is still blocked by R09, and T16 is removed again; after re-executing the entire round of verification, cancellation of T21 can enable the target action to simultaneously acquire R07 and R09, so T21 is restored and forms a verified conflict group; the verified conflict group, together with the original blocking beat number range corresponding to R09, is used for subsequent implicit hit set calculation and reading.

[0019] S3. The implicit hit set algorithm is executed on the end side. The task is grouped as a binary item and each designated conflict group is hit as a constraint. The branch is based on the task number and the non-hit branches are truncated. The complete branch with the highest number of rewrite slots is read as the rewrite group. After canceling the rewrite group resource occupation, the task table on the end side is checked. If blocked, it returns to S2. If not blocked, the rewrite group is output. After the approved conflict groups are generated, the endpoint needs to determine the scope of resource occupation rewriting from the tasks involved in each approved conflict group, and uniformly measure the rewriting cost by the number of resource slots. During processing, only the union of all approved conflict group task numbers is used to create a binary item; tasks that have not entered the approved conflict group retain their original resource usage. Time slot statistics start from the planned start time of the first unexecuted action of the task and extend to the planned end time of the last action. Resource usage that spans the current scheduling cycle is still counted as the complete usage interval; the specific processing is as follows; Tasks entering the rewriting scope are first converted into a unified resource slot metering; the terminal reads all approved conflict groups from the terminal task table, deduplicates them by task number to form a set of candidate tasks, and then splits the resource occupation record of each task in the candidate task set from the first unexecuted action into resource slots identified by both resource number and single slot number. When the same task occupies different resources in the same time slot, they are counted separately. When the same resource slot appears multiple times due to repeated recording, only one item is retained. After the uniqueness of the position is completed, the number of time slots corresponding to each task is counted in S31, the task is written into the rewrite group with a state of zero or one binary value, and a hit relationship table is established based on whether the task number belongs to the designated conflict group. If the task number is duplicated within the designated conflict group, one entry is retained. Empty designated conflict groups are written to the exception record table and the current round of solving is stopped. When solving for the initial candidate rewrite group, the integer branch formed by all the candidate tasks is used as the initial upper bound, and the corresponding scheduling cost is the sum of the time slots of all candidate tasks. Then, S32 is executed, which restricts each approved conflict group to have at least one binary term, and uses the sum of the values ​​of each binary term multiplied by the corresponding time slot number as the solution objective. During the linear relaxation phase, the unfixed binary terms take values ​​between zero and one. After the solution is completed, the objective value is written as the current branch boundary value, and branches with no solution are directly deleted. When the linear result contains fractional binary terms, read the first fractional binary term according to the task number and create the grouping branch and the non-grouping branch respectively; delete the current branch when all tasks in a certain conflict group have been fixed to zero, and continue to retain it if there are tasks in the group that take one or there are still unfixed tasks. When the branch boundary is not lower than the current integer branch scheduling cost, the expansion stops and a new integer branch is obtained. The current upper bound is then updated with a lower scheduling cost. When the scheduling costs are the same, the number of tasks entering the group and the ascending sequence of task numbers are compared in turn, and the integer branch with the highest sorting value is read as the candidate rewrite group. After the candidate rewrite group is formed, it is necessary to verify whether it can lift all the blockages based on the actual resource relationship on the production side; the current version of the client-side task table and resource occupation record are copied on the client side, and only the planned resource occupation that has not yet started since the first unexecuted action of each task in the candidate rewrite group is cancelled, while the actions in execution and the actual occupation that has not yet been released remain frozen; Resource events are replayed in ascending order of their time slots. Within the same time slot, release events are processed first, followed by acquisition events processed according to the planned start time slot, task number, and action order. When an action corresponds to multiple resources, the status of all resources is read first, and then all resources are written to the action resource group once they are all idle. When a blocked action occurs during replay, S33 traces the tasks that are still occupied along the blocked resource, virtually deletes them one by one according to the task number and replays them. Tasks whose blocked actions are lifted after deletion are restored until a new approved conflict group is formed that is blocked when all members are retained and the block is lifted after deleting any member. The newly added approved conflict group only includes tasks that still exist in the current resource-occupying instance. If the same task appears in the candidate rewrite group, the current instance will be discarded and the resource replay will be re-executed. After a new approved conflict group is written, the original branch boundary value needs to be recalculated as the limit changes; when implementing S34, the task numbers in the new approved conflict group are first sorted in ascending order to form a group code, and the group code is not written repeatedly if it already exists. When a group code appears for the first time, it is added to the hit relationship table. Only existing branches in the group where all task binary items are fixed to zero are deleted. Branches in the group that already have a task to take one or still have unfixed tasks are retained. All branches are retained, linear relaxation is re-executed, and branch boundaries are updated. Then, return to S32 to continue solving. If no blocked action occurs during resource replay, and the updated boundaries of all unread branches are not lower than the scheduling cost of the candidate rewrite group, the candidate rewrite group is written as the rewrite group. The number of candidate tasks is limited. Each replay failure adds a new qualified conflict group that was not hit by the current candidate rewrite group. Therefore, the solution ends after a finite number of branch processing steps. After the above processing, the rewriting group simultaneously satisfies the hit limit of each designated conflict group, and uses the number of resource slots that need to be revoked and reconfigured as the uniform cost; taking designated conflict group G1 containing tasks T16 and T21, and designated conflict group G2 containing tasks T21 and T24 as an example, the number of time slots corresponding to tasks T16, T21 and T24 are six, four and five respectively. The linear solution first obtains the integer branch of task T21, with a scheduling cost of four. After canceling T21 on the end side and replaying it, it is still found that task T30 and task T24 jointly block another action. Therefore, a new conflict group G3 is added and the solution is re-solved. The updated hit relationship table requires that each integer branch hits G1, G2 and G3 simultaneously. The endpoint performs resource replay on the new candidate rewrite group. After no more blocked actions occur and the remaining branch thresholds are not lower than the current scheduling cost, the corresponding rewrite group is output for cloud branch pricing processing.

[0020] S4. Upload the terminal task table containing the rewriting group and the approved conflict group through terminal-cloud collaboration. Execute the branch pricing algorithm in the cloud, freeze the resource occupation of tasks outside the rewriting group, write the subsequent path of the rewriting group task as a column, so that each task takes one column, the same resource time slot is reserved for one column, and one task of each approved conflict group avoids the original resource time slot. The column cost is the sum of the number of delayed beats and the number of rewriting time slots. Add columns according to the reduced cost. For fractional columns, form two branches according to the fixed and disabled resource time slots. Read the integer column group to form the cloud scheduling result. Once the rewrite group is determined, the client only uploads task data related to this round of resource rearrangement. Based on this, the cloud generates the execution path of tasks within the rewrite group while keeping the resource usage outside the rewrite group unchanged. The uploaded content includes the client-side task table version number, the cut-off record, the rewrite group, the approved conflict group, and the original blocking resource time slot corresponding to the approved conflict group. The cloud first verifies the version number. When a new version has been created on the production side, the data from this round is returned to the client side for reorganization. When the versions are consistent, the process of path construction and column generation begins. The specific processing is as follows. The cloud first determines the range of time slot numbers for the action time slot diagram. The starting time slot for scheduling is the starting time slot of the current scheduling cycle. The ending time slot for scheduling is the time slot number obtained by adding the last time slot occupied by the frozen resources and the total number of time slots occupied by the remaining actions in the rewriting group. Candidate starting time slots are generated one by one within this range. Each node in the diagram represents the complete resource configuration of an action on a candidate start timer. The node contains the task number, action sequence, candidate start timer, candidate end timer, and all resource time slots occupied by the action resource group. When there is resource occupation during transportation, transformation, and inspection processes, the independent actions in the task record are used to participate in the diagram construction. After the node generation is completed, S41 connects the nodes whose previous action candidate ends no later than the next action candidate begins, and deletes the nodes and connections that overlap with frozen resource occupancy, whose resource numbers do not match the task record, or whose resource start times for the same action are inconsistent, forming an execution path domain from the task start point to the task end point. The initial path list must simultaneously meet the requirements of task integrity and resource slot capacity. When processing S42, the cloud reads and executes the tasks in the rewrite group sequentially according to the task number. The first task selects the path from the start of the scheduling, and the next task continues to select from the first slot after the relevant resources are released from the existing initial path, so that the initial path list does not repeatedly occupy the same resource slot. If the original blocking resource time slot corresponding to the approved conflict group is still occupied by all member paths, move the first member path to the subsequent feasible node in the order of task number until each approved conflict group has a member that avoids the original blocking resource time slot. The number of delayed beats for each path is the difference between the path completion beat and the planned completion beat. When the path completion beat is no later than the planned completion beat, it is recorded as zero. The number of beats deviating from the original resource time slot is the XOR number of the current path and the resource time slot set of the original scheduled path. The two are added together to form the column cost. This establishes a restricted master problem, which ensures that each task selects a path list, each resource time slot is occupied by only one path list, and each approved conflict group has at least one member path that avoids the corresponding original blocked resource time slot. After performing linear relaxation, read the dual values ​​corresponding to the task selection limit, resource slot capacity limit, and approved conflict group avoidance limit, and write them as task limit value, resource slot limit value, and conflict group limit value, respectively. The generation of the new path depends on the dual value to re-price the action slot graph; the task start cost is written as a negative value of the task limit value. When processing S43 along the action sequence, the intermediate node only accumulates the number of deviation resource slot beats added by the current action relative to the original scheduling path, and deducts the resource slot limit value corresponding to the resource slot occupied by the current node for the first time. The task endpoint writes the delay count for the entire path; the recursive state simultaneously saves the set of resource time slots that have been counted and the set of approved conflict group numbers that have been met for avoidance. The resource time slot limit value is deducted only once for the same resource time slot, and the conflict group limit value is deducted only once when the path avoids the original blocking resource time slot for the first time. When there are multiple predecessors for the same node, they are sorted in order by cumulative node cost, predecessor task number and predecessor candidate start beat, and the first predecessor is retained; after reaching the task end point, backtracking is used to form the path code. The path code is formed by connecting the candidate start beat, candidate end beat and resource number group of each action in the order of action. If the path encoding already exists, read the next sequential predecessor and backtrack again. After obtaining the execution path that is not written into the current path column and has a negative reduction cost, add it to the restricted master problem and solve it again until there are no new paths with negative reduction costs in each task of the rewritten group. When the linear relaxation result does not form an integer column group, the cloud calculates the score occupancy item from the path column; specifically, for occupancy items with the same task number, action order, resource number, and candidate start shot, the path column values ​​containing the occupancy item are accumulated, and when the accumulated value is between zero and one, it is recorded as a score occupancy item; When executing S44, the first item is read in order of task number, action sequence, resource number and candidate start beat, and fixed occupied branch and disabled occupied branch are established respectively. Fixed occupancy branches delete path columns that do not contain the corresponding occupancy item, and delete nodes and connections that cannot pass through the corresponding occupancy item in the action slot diagram; disabled occupancy branches delete path columns that contain the corresponding occupancy item, and delete the corresponding node from the action slot diagram. Path pricing is re-executed in each branch. If there is no path from the task start point to the task end point in a fixed branch, it is recorded as no solution. Branch nodes are read in ascending order of branch boundary value. If the branch boundary values ​​are the same, they are read in the generation order. After obtaining the integer column group, the total cost of the existing integer column group is updated. The solution is stopped when the branch boundary values ​​of all unprocessed branch nodes are not lower than the total cost of the existing integer column group. Then, the first integer column group is read in the order of total cost and path code to form the cloud scheduling result. The resulting cloud scheduling result only rewrites the task path required to hit the designated conflict group, while keeping the resource occupation outside the rewritten group unchanged. Taking the use of resource R09, which is jointly blocked by tasks T16 and T21 during the period from 1220 to 1222, as an example, the terminal uploads the designated conflict group number, member task number, and the original blocking resource time slot corresponding to R09. After the cloud generates candidate paths for the two tasks, the initial path list still makes the two tasks occupy the original blocking resource time slot. Based on this, the master problem generates a conflict group limit value. The pricing process reduces the cost of nodes that avoid the original blocking resource time slot of R09 and generates a new path. When linear relaxation occurs, if task T21 occupies the fractional item of R09 in shot 1220, the fixed branch retains the occupation, the disabled branch deletes the occupation and regenerates the path; after the disabled branch obtains the integer column group, task T21 is moved to the subsequent resource time slot, task T16 keeps the original path, and the resulting cloud scheduling result is sent to the production end for S5 to execute.

[0021] S5. After the cloud-edge collaboration, the cloud scheduling result is sent out. The production end rewrites the resource occupancy record. At the start of the plan, the resource acquisition status of the first unexecuted action is verified. After the resource is acquired, it is written into the execution record and the action sequence is advanced. If it is blocked, it returns to S2. After the cloud scheduling results arrive at the production site, it is necessary to first eliminate the resource status deviation caused by the new execution records added during the scheduling calculation, and then complete the resource acquisition according to the actual occupancy status within the same time frame. The production end is implemented by edge processing nodes set up on-site and communicating with the manufacturing equipment. The cloud scheduling results carry the version number of the task table on the edge side and the deadline record. Subsequent correction, acquisition, execution and return are all based on this version. The specific processing is as follows. When the scheduling result enters the production end, it first compares the version number of the task table carried on the end with the currently received version. Duplicate results with the same version will not be written again, and results with a version earlier than the currently received version will be discarded. After the version passes the verification, the resource number of the first unexecuted action and subsequent actions, the start time of the plan, and the end time of the plan will be extracted according to the task number. On the production side, the extracted content is copied to the scheduling sub-table in S51, and the difference between the planned end time and the planned start time of each scheduling sub-table record is calculated as the number of time occupied by the action. Then, read the execution records that were added or rewritten after the deadline record, and replay the resource acquisition and release process according to the actual start record, task number and action order. Actions that have been written to the actual start record but are empty in the actual completion record will maintain resource occupation, and the currently registered occupation end record in the resource occupation record will be used as the release record. When the scheduling sub-table record overlaps with the interval occupied by the executed action, read the release time of all overlapping resources in the same action resource group, take the release time with the later value as the correction start time, then synchronize and extend all records in the action resource group, and recalculate the correction end time according to the number of action occupied time. The number of consecutive beats generated by the current action is added to the subsequent actions of the same task until all subsequent records no longer overlap with the intervals occupied by the already executed actions, forming a pending execution occupancy table; Once the scheduled start time for a new auction arrives, the production side first processes all resource release events that occur in the current auction, then latches the resource occupancy tasks and the start and end times of the occupancy, forming a snapshot of the resource status for the current auction. When executing S52 in order of resource number, read the action resource group corresponding to the first unexecuted action from the pending execution table, and check the resource status snapshot item by item; When a resource is idle, the resource number is written to a local temporary resource acquisition table. When a resource is occupied by the same task and the task record allows for sequential actions, the corresponding resource is directly included in the resource acquisition result. The start time of occupation is not written repeatedly. When a resource is occupied by another task, subsequent reading is stopped, and the blocking resource number, the occupying task number, and the end time of occupation are recorded. When multiple tasks apply for the same resource in the same auction, the edge resource registration node responsible for that resource applies according to the planned start auction, task number, and action order. Only the request from the task ranked first is accepted, and the remaining tasks form a resource acquisition result that does not cover all resource numbers. After the resource acquisition results are formed, S53 performs a unified submission based on the number of resource numbers in the action resource group; when the resource acquisition results cover all resource numbers, the production end writes the resource acquisition table into the resource occupancy record at once, and writes the action start record containing the task number, action sequence, resource number and the actual start time of the action. After the manufacturing equipment returns the action completion signal, the actual completed step and the first step after resource release are written, and then the action sequence is advanced and the next first unexecuted action is determined; When the resource acquisition results do not cover all resource numbers, the production end clears the resource acquisition table, does not rewrite any resource occupancy records, and writes the blocking resource number, blocking order number, and occupancy task number into the terminal task table. After incrementing the version number of the terminal task table, it returns to S2. The current cloud scheduling results continue to be retained in the scheduling sub-table until they are overwritten by subsequent versions. Through the above processing, the resource configuration provided by the cloud can be corrected according to the execution results that have occurred on the production site, and ensure that all resources required for the same action are submitted in the same batch. Taking task T18 as an example, which plans to acquire R07 and R09 simultaneously at time 1220, the cloud scheduling result is generated based on the cutoff record time 1218. The production end then receives the execution record of task T16 actually occupying R07 until time 1223. Therefore, the occupation record of R07 and R09 corresponding to task T18 is synchronously postponed to time 1223, and the subsequent actions of task T18 are increased by the same number of postponed times. Upon reaching frame 1223, the production end first processes the release of R07, then reads the current frame resource status snapshot. When both R07 and R09 pass verification, two resource occupancy items are written at once and an action start record is generated. The next action is only advanced after the manufacturing equipment completes the action writing for the frame. If R09 has been acquired by the task with the highest priority in the same frame, the resource acquisition table is cleared directly, the terminal task table is written with a new blocking relationship, and the conflict identification is re-entered.

[0022] exist Figure 1 It should be noted that: task records and resource occupancy records are sequentially processed by S1 to form the end-side task table, S2 identifies the target action and forms the verification conflict group, and S3 forms the rewrite group through implicit hit set solving. Subsequently, the end-cloud collaboratively uploads the rewrite group to the cloud, S4 executes branch pricing and generates scheduling results, and after the scheduling results are distributed, S5 corrects resource occupancy and verifies the resource acquisition status. Solid arrows indicate the normal execution order and data transmission direction between each processing stage, and diamond boxes indicate the judgment node for whether all resources have been acquired. If the judgment is yes, the execution record is written and the action sequence is advanced. If the judgment is no, the process returns to S2 along the dotted line, indicating that the verification conflict group is re-identified based on the new blocked resources and occupancy tasks.

[0023] Overall execution and implementation description: This solution first involves the production side organizing task records and resource usage records according to a unified scheduling schedule, determining the first unexecuted action for each task, and identifying the target action blocked due to unreleased resources; then, through item-by-item cancellation and resource replay, identifying the designated conflict groups that are causing the target action to be blocked and cannot be further deleted, and then using the incremental implicit hit set algorithm to select the task scope that needs to rewrite resource usage from multiple designated conflict groups; The endpoint uploads the rewrite group, the approved conflict group and related resource status to the cloud through endpoint-cloud collaboration. The cloud freezes tasks outside the rewrite group, uses the branch pricing algorithm to generate new execution paths for tasks within the rewrite group, and determines the cloud scheduling result based on resource slot occupancy, conflict avoidance and delay time. After the scheduling results are returned to the production end, the production end adjusts the planned time period based on the actual execution records that have occurred. At the beginning of the plan, the resources required for the unified verification action are collected. When the resources are complete, the action is started. If resources are still blocked, the conflict identification process is re-entered. For example, when multiple production lines share testing equipment and handling equipment, Task A plans to obtain the testing equipment at 120, but the testing equipment is still occupied by Task B, and the subsequent actions of Task B are blocked by the handling equipment used by Task C. The production side first identifies tasks B and C based on resource occupancy relationships, and then determines the default conflict group that is causing task A to be unable to execute by replaying resources. The incremental implicit hit set algorithm selects the tasks that need to be adjusted accordingly, and the cloud then reschedules the occupancy time of the detection and handling equipment for these tasks, while keeping the original plans of other tasks unchanged. After the adjustment results are issued, the production side will adjust subsequent actions in sync with the actual release of equipment on site. Once the testing and handling equipment have been released, all resources will be acquired at once and task A will be started, thereby avoiding repeated changes to the entire production plan caused by local resource conflicts.

[0024] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A smart factory data collaborative processing method based on the Industrial Internet of Things, characterized in that, include: S1. Obtain task records and resource usage records for the same period from the production side, locate the first unexecuted action of the unfinished task, read the planned start time and usage start and end time of the resource number, and form the task table on the end side. S2. Based on the task table on the end side, read the first resource-incomplete action as the target action, trace the occupied tasks to form a candidate group, cancel the subsequent resource occupation of the candidate group tasks one by one, delete the current task if it is still blocked, restore the current task when the block is lifted, and form a verified conflict group after one round without deletion. S3. The implicit hit set algorithm is executed on the end side. The task is grouped as a binary item and each designated conflict group is hit as a constraint. The branch is based on the task number and the non-hit branches are truncated. The complete branch with the highest number of rewrite slots is read as the rewrite group. After canceling the rewrite group resource occupation, the task table on the end side is checked. If blocked, it returns to S2. If not blocked, the rewrite group is output. S4. Upload the terminal task table containing the rewriting group and the approved conflict group through terminal-cloud collaboration. Execute the branch pricing algorithm in the cloud, freeze the resource occupation of tasks outside the rewriting group, write the subsequent path of the rewriting group task as a column, so that each task takes one column, the same resource time slot is reserved for one column, and one task of each approved conflict group avoids the original resource time slot. The column cost is the sum of the number of delayed beats and the number of rewriting time slots. Add columns according to the reduced cost. For fractional columns, form two branches according to the fixed and disabled resource time slots. Read the integer column group to form the cloud scheduling result. S5. After the cloud-edge collaboration, the cloud scheduling results are sent out. The production end rewrites the resource occupancy record and verifies the resource acquisition status of the first unexecuted action at the start of the plan. After the resource is acquired, it is written into the execution record and the action sequence is advanced. If it is blocked, it returns to S2.

2. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 1, characterized in that: S1 includes: S11. Collect task records by task number and sort them by action order. When multiple task records correspond to the same task number and action order, retain the last task record in ascending order of record beat number to form a task action chain. S12. Read the action completion timer along the task action chain, determine the first action that has not been written with an action completion timer as the first unexecuted action, and write the resource number and plan start timer corresponding to the first unexecuted action into the pending task line.

3. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 2, characterized in that: S1 also includes: S13. Collect resource occupancy records by resource number, extract all occupancy start and end times and sort them by time number, divide resource time periods by adjacent time numbers, and then write the occupancy tasks covering each resource time period into the corresponding resource time period to form a resource occupancy chain. S14. Align the pending task row with the resource occupation chain according to the resource number, read the occupied tasks and occupation start and end times of the resource time period where the plan starts, and write them into the end-side task table according to the task number and action order.

4. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 3, characterized in that: S2 includes: S21. Read the task table on the end side according to the start time of the scheduled photo, task number and action order. Record the first unexecuted action that falls within any required resource occupation range when the start time of the scheduled photo is scheduled as the target action, and write the corresponding occupation task into the candidate group. S22. Taking the occupied tasks in the candidate group as the object, read the first unexecuted action of the occupied task and the corresponding required resources. Continue to write the occupied tasks that are scheduled to start bidding in the corresponding resource occupation range but have not yet been written into the candidate group into the candidate group. Repeat the process until no more tasks are added to the candidate group, forming a blocking relationship table.

5. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 4, characterized in that: S2 also includes: S23. Copy the resource occupancy record corresponding to the candidate group, read the current task by task number and cancel the resource occupancy of the current task from the first unexecuted action, then replay the resource acquisition and release process of the remaining tasks according to the start and end of the occupancy, read the occupancy status of each resource required when the target action reaches the start of the plan, and form the cancellation result of the current task. S24. If the cancellation result indicates that the target action still has resources occupied, delete the current task from the candidate group and retain the resource occupation record after cancellation. If the cancellation result indicates that the target action has obtained all the required resources, restore the current task and the corresponding resource occupation record. If there are still tasks to be deleted after completing one round of reading, re-execute S23. If no tasks are deleted after one round of reading, record the candidate group as the approved conflict group.

6. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 5, characterized in that: S3 includes: S31. Based on the task table on the end side, count the number of time slots occupied by each task since the first unexecuted action, set the status of the task written into the rewrite group as a binary item, and form a hit relationship table according to the relationship between the task and the approved conflict group. S32. The edge executes the incremental implicit hit set algorithm, with each designated conflict group containing one entry task as a constraint, and the total number of time slots occupied by the entry tasks as the scheduling cost. Linear relaxation is performed on the binary terms and the branch boundary is read. The first fractional binary term is read according to the task number to establish the entry branch and the non-entry branch. Branches that cannot hit the designated conflict group or whose branch boundary is not lower than the scheduling cost of the existing integer branch are deleted. The first integer branch is read in ascending order of scheduling cost to form a candidate rewrite group.

7. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 6, characterized in that: S3 also includes: S33. Copy the task table on the end side and cancel the resource occupation corresponding to the candidate rewrite group. Start the shooting and action sequence replay of the resource acquisition and release process of the remaining tasks according to the plan. When an obstructed action occurs, trace the occupied task along the obstructed resource, delete the traced task item by item and repeat the replay. Keep the task whose obstructed action is lifted after deletion to form a newly added approved conflict group. S34. Write the newly added designated conflict group into the hit relationship table, retain the existing branches that still hit the newly added designated conflict group and return to S32, until no blocked action occurs during resource replay and the branch boundary value of all unread branches is not lower than the scheduling cost of the candidate rewrite group, and output the candidate rewrite group as the rewrite group.

8. The smart factory data collaborative processing method based on the Industrial Internet of Things according to claim 7, characterized in that: S4 includes: S41. Upload the task table of the end side containing the rewriting group and the approved conflict group to the cloud through end-cloud collaboration, freeze the resource occupation of tasks outside the rewriting group, and establish an action time slot diagram with the first unexecuted action of the task in the rewriting group, the order of subsequent actions, the resource number and the start and end time of occupation. Connect the nodes in the adjacent actions where the end time of the previous action is not later than the start time of the next action and the resource number satisfies the task record to form an execution path domain. S42. Read an execution path for each task from the execution path domain along the action sequence and write it as the initial path column. With the constraints of selecting one path column for each task, reserving one task for the same resource time slot, and ensuring that at least one task in each approved conflict group avoids the original resource time slot, add the number of time slots that the path completion time slot increases relative to the planned completion time slot to the number of time slots that deviate from the original resource time slot to form the column cost. Perform linear relaxation on the initial path column and output the task constraint value, resource time slot constraint value, and conflict group constraint value.

9. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 8, characterized in that: S4 also includes: S43. Write the task constraint value to the corresponding task starting point, write the resource slot constraint value to the node occupying the corresponding resource slot, and write the conflict group constraint value to the node that avoids the original resource slot. Accumulate the node cost along the action sequence and retain the predecessor in ascending order of node cost. Backtrack to find the execution path that is not written to the current path column and has a negative reduced cost, add it to the current path column and return to S42, until no execution path with a negative reduced cost is generated for any task. S44. When the linear relaxation result contains fractional column values, read the first fractional occupation item by task number, action order, resource number and start time. Create branch nodes with fixed corresponding occupation items and disabled corresponding occupation items respectively. Delete path columns that do not conform to the branch rules in each branch node and return to S42. Stop solving for branch nodes whose branch boundary value is not lower than the total cost of the existing integer column group until all branch nodes are processed. Then read the first integer column group in ascending order of total cost to form the cloud scheduling result.

10. The smart factory data collaborative processing method based on the Industrial Internet of Things as described in claim 9, characterized in that: S5 includes: S51. Receive the cloud scheduling result through end-to-end cloud collaboration, extract the resource number and start and end time of the first unexecuted action and subsequent actions according to the task number, write the corresponding resource occupation into the scheduling sub-table, and replay the resource acquisition and release process with the execution records already written by the production end. For the scheduling sub-table records that overlap with the occupied interval of the executed actions, extend them to the corresponding resource release time to form the pending execution occupation table. S52. When the scheduled start time is reached, the production end reads the pending occupancy table record corresponding to the first unexecuted action in the order of resource number, writes the resources that are not occupied by other tasks in the current shot into the resource acquisition table, and stops reading when the occupied resource is read, thus forming the resource acquisition result. S53. When the resource acquisition result covers all resource numbers corresponding to the first unexecuted action, write the resource acquisition table into the resource occupancy record and generate an execution record, then write the next action as the first unexecuted action; when the resource acquisition result does not cover all resource numbers, delete the record written into the resource acquisition table this time, write the blocking resource and its occupancy task into the end-side task table and return to S2.

Images