Tooling real-time production planning and scheduling system based on internet of things two-dimensional code

Abstract

The application belongs to the technical field of production planning, resource scheduling and data processing, and particularly relates to a tooling real-time production planning and scheduling system based on an Internet of Things two-dimensional code. The system comprises an Internet of Things two-dimensional code event access module, an event chain construction module, a state digital shadow maintenance module, a plan constraint mapping module and a local plan correction module. Scanning code records formed by tooling in the links of taking, going online, sequence conversion, temporary storage, release or repair are converted into standardized two-dimensional code events, and two-dimensional code event chains are generated according to tooling identification, order identification, process nodes and event time stamps. Tooling state versions are generated according to the event chains, and the tooling state versions are mapped to order process networks, tooling occupation windows and front and rear process constraints. The system can reduce state lag caused by disconnection between scanning code events and plan constraints, and make production planning updated synchronously with the actual flow state of tooling.

Description

Technical Field

[0001] This invention belongs to the field of production planning, resource scheduling and data processing technology, and specifically relates to a real-time production planning and scheduling system for tooling based on Internet of Things QR codes. Background Technology

[0002] Tooling production planning and scheduling systems are typically used to record basic tooling files, tooling requisition status, process occupancy relationships, and production order scheduling information. Current solutions generally involve planning personnel entering orders, process routes, planned start times, planned end times, and tooling requirement lists into the system. Field personnel then manually register or scan QR codes at stages such as tooling requisition, deployment, transfer, temporary storage, release, and rework. QR codes in these systems are typically used to bind tooling numbers, specifications, processes, storage locations, and usage status. After a scanning terminal reads the QR code, it uploads the scanning time, operator, operation node, and tooling number to the backend database, which then updates the tooling ledger based on preset fields. This method can replace paper registration and reduce tooling identification errors; however, QR code data primarily serves as status query and recording evidence. Production planning in the system still largely relies on pre-set schedules, manual work reports, or timed synchronization results for adjustments, lacking a continuous data transmission relationship between scanning events and planning scheduling constraints.

[0003] In conventional production planning and scheduling, the system typically breaks down orders into multiple process nodes and establishes scheduling results based on process routes, delivery times, equipment capabilities, and available tooling quantities. For tooling resources, the system generally uses static availability status, inventory status, or manually confirmed status as scheduling inputs to determine whether a process node is ready to start. If tooling is assigned to a specific order process, the system records the occupied time window in the planning table and releases the tooling upon expected completion. Subsequent processes or other orders then use the tooling according to the plan. This approach relies on the synchronization and consistency between planned time and actual on-site status. However, tooling may be released early, delayed, temporarily stored, delayed for repair, or adjusted across processes during actual on-site circulation. If these changes are not promptly entered into the scheduling model, the tooling availability status in the planning table will lag behind the on-site status, and subsequent scheduling calculations will still use the distorted occupied window and process sequence relationships.

[0004] Existing systems also offer solutions for connecting IoT barcode scanning data with production planning systems. These typically involve triggering a status change message after scanning and writing the message to the tooling management database or production execution system database. The system can display the current location, status, and associated orders of the tooling on the interface, and can also notify planners that a tooling has been used or released. However, these solutions often employ an event-based update logic, lacking a chain-like verification mechanism based on tooling identifiers, order identifiers, process nodes, and event times, as well as a local constraint mapping mechanism oriented towards planning nodes. For situations such as duplicate scanning, scanning delays, time inversions, missing status loops, and cross-process jumps, the system often only retains the last arrival record or requires manual confirmation before correcting the status. Therefore, although QR code events enter the system, they are not transformed into verifiable, traceable, and directly constraining continuous state variables for planning adjustments.

[0005] Therefore, a real-time, continuous, and verifiable linkage is not established between QR code scanning events and production planning scheduling constraints. When the actual occupancy, transfer, release, or rework status of tooling changes, the system struggles to promptly confirm the reliable status version based on the scanning event chain, and it is difficult to map this status version to the order process network, tooling occupancy window, and preceding and following process constraints for local correction. The scheduling module continues to calculate based on lagging tooling availability information and the original planned occupancy window, which can easily lead to the duplicate allocation of the same tooling, mismatch between planned nodes and actual tooling release times, and the spread of local tooling status deviations to adjacent processes and shared tooling nodes, causing a continuous deviation between the production plan and the actual tooling flow status on-site. Summary of the Invention

[0006] The purpose of this invention is to provide a real-time production planning and scheduling system for tooling based on Internet of Things (IoT) QR codes, which can effectively solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A real-time production planning and scheduling system for tooling based on Internet of Things (IoT) QR codes includes an IoT QR code event access module, an event chain construction module, a status digital shadow maintenance module, a plan constraint mapping module, and a local plan correction module. The IoT QR code event access module receives the scanning records generated by the tooling during the requisition, online, sequence transfer, temporary storage, release or rework process and converts them into standardized QR code events. The event chain construction module generates a QR code event chain based on tooling identifier, order identifier, process node, and event timestamp. The status digital shadow maintenance module generates a tooling status version based on the QR code event chain; The planning constraint mapping module maps the tooling status version to the order process network, tooling occupancy window, and preceding and following process constraints. The local plan correction module generates correction results for plan nodes with constraint conflicts after mapping and adjacent shared tooling nodes.

[0008] Preferably, the event chain construction module configures an event index for each standardized QR code event, consisting of a tooling identifier, order identifier, process node, event type, event occurrence time, reporting time, and preceding status summary. A chained reference relationship is formed according to the event occurrence time and the preceding status summary. Under the same tooling identifier, a closed-loop rule is set for the status between requisition, online, transfer, temporary storage, release, and rework. Scanning records that lack a preceding status summary, have duplicate event indexes, or are inconsistent with the status closed-loop rule are marked as events to be corrected.

[0009] Preferably, the status digital shadow maintenance module establishes a status record table for each tooling identifier. The status record table includes the current process, occupied order, associated plan node, status version number, status lock flag, and recent trusted event index. Upon receiving the standardized QR code event, the standardized QR code event is compared with the most recent trusted event index, and the status version number is updated according to the matching relationship between the scanning link and the process route. Generate a set of candidate states for events that are time-inverted, jump across processes, or have missing state loops.

[0010] Preferably, the planning constraint mapping module establishes a planning node table, a tooling occupancy window table, a planning node current execution flag, and a process pre- and post-constraint table in the order process network, and writes the tooling status version into the corresponding planning node, occupancy window, and pre- and post-constraints respectively; The local plan correction module uses the changed tooling identifier as an index to extract a set of nodes that have the same tooling occupation relationship, adjacent process relationship, or shared tooling relationship with the plan node, and forms a plan segment to be corrected and an index of the original plan sequence within the set of nodes.

[0011] Preferably, the event chain construction module generates event consistency tags for the event to be corrected, and the event consistency tags include consistency in time sequence, consistency in process route, consistency in scanning steps, and consistency in status summary; When there are multiple events to be corrected under the same tooling identifier, event candidate branches are formed according to the event consistency label combination, and the event candidate branches are matched with the already formed QR code event chain in three categories: chain head, chain tail, and middle insertion. Event candidate branches that meet the state closure rule and do not disrupt the continuity of the previous state summary are retained.

[0012] Preferably, the status digital shadow maintenance module establishes a status transition table for the candidate status set. The status transition table includes the candidate current process, candidate occupied order, candidate planned node, candidate occupied start and end time, tooling status source category and corresponding event index. The state transition table is checked for consistency with the process route, planned node table and tooling occupancy window table. Candidate states are then filtered in the order of complete prerequisite relationships, non-overlapping occupancy windows and reachable process nodes. The filtered candidate states are then written into the state record table corresponding to the tooling identifier.

[0013] Preferably, the local plan correction module establishes a local constraint matrix for the plan segment to be corrected. The local constraint matrix includes the binding relationship between the plan node and the tooling occupancy window, the sequential relationship between adjacent processes, the mutual exclusion relationship between the same tooling in different plan nodes, and the minimum changeover interval relationship. In the local constraint matrix, conflicting edges caused by changes in the tooling state version are marked, and only for connected regions containing the conflicting edges, a planned node rearrangement sequence, the original planned version number, and the node source index are generated.

[0014] Preferably, the local plan correction module generates a candidate correction table based on the rearrangement sequence of the plan nodes. The candidate correction table includes the adjustment order of the plan nodes, the adjustment amount of the tooling window, the correction trigger event index, the constraint satisfaction flag of the preceding and following processes, and the shared tooling conflict flag. For multiple candidate correction tables, the target correction table is determined according to the following rules: the constraint satisfaction mark of both preceding and subsequent processes is satisfied, the shared tooling conflict mark is empty, and the total value of tooling occupation window adjustment is sorted first. The target correction table is then written into the production plan version record.

[0015] Preferably, the status digital shadow maintenance module establishes a bidirectional index between each event in the event candidate branch and its corresponding candidate status. The bidirectional index includes the event index, the candidate current process, the candidate occupied order, and the status version number. When the event candidate branch can form the same preceding state summary with the unique candidate state, the event candidate branch is connected to the QR code event chain; When the event candidate branch corresponds to multiple candidate states, cross-matching is performed according to the plan node table, tooling occupancy window table, and process pre- and post-process constraint table, and the candidate state with a unique matching result is retained.

[0016] Preferably, the local plan correction module establishes a correction anchor table when writing the production plan version record. The correction anchor table includes the location of the trigger QR code event chain, the version number before the change, the version number after the change, the target correction table identifier, and the set of affected plan nodes. When a subsequent standardized QR code event points to the set of affected planning nodes, the latest production plan version is read according to the correction anchor table, and candidate correction tables that are not referenced by subsequent events are marked as invalid records. For scan records that reappear at the same trigger QR code event chain location, no new target correction table will be generated.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By converting the barcode records generated during tooling requisition, deployment, transfer, temporary storage, release, or rework into standardized QR code events, and constructing a QR code event chain based on tooling identifier, order identifier, process node, and event timestamp, the system can organize discrete barcode records into a continuous event sequence with preceding and following state relationships. The status digital shadow maintenance module generates a tooling status version based on the QR code event chain, ensuring that the tooling's current process, occupying order, associated plan node, and status version number change synchronously with trusted events. The plan constraint mapping module then writes the tooling status version into the order process network, tooling occupancy window, and preceding and following process constraints. The local plan correction module only generates correction results for plan nodes with constraint conflicts and adjacent shared tooling nodes. Thus, QR code events no longer remain at the tooling identity registration level but become constraint inputs for production plan correction, forming a closed data relationship between plan nodes and the actual occupancy status of tooling, solving the problems of barcode data lagging behind the scheduling model and tooling status not being timely entered into plan constraints.

[0018] 2. By combining event indexes, preceding state summaries, state closure rules, candidate state sets, local constraint matrices, and correction anchor point tables, the system can process duplicate scans, time inversions, cross-process jumps, and missing state closures in scan records. The event chain construction module marks abnormal scan records as events to be corrected and maintains the continuity of the event chain through event consistency tags and event candidate branches. The state digital shadow maintenance module performs consistency checks on candidate states with process routes, planned node tables, and tooling occupancy window tables to reduce the situation where erroneous events cover the current tooling state. The local plan correction module generates a planned node rearrangement sequence in connected regions with conflicting edges and records the state version before and after the change, the triggering event position, and the set of affected planned nodes through the target correction table and correction anchor point table. The above processing enables subsequent scan events to continue to be updated based on the latest production plan version, and repeatedly triggered scan records will not repeatedly generate new correction results. The scope of plan adjustment is limited to the set of nodes related to changes in tooling state. Attached Figure Description

[0019] Figure 1 This is a flowchart of the overall processing flow of the tooling real-time production planning and scheduling system based on IoT QR codes of the present invention; Figure 2 This is a flowchart illustrating the construction of the QR code event chain and the access to candidate branches of events to be corrected in this invention. Figure 3 This is a flowchart of the tooling status digital shadow maintenance and candidate status screening process of the present invention; Figure 4 This is a flowchart of the production plan partial correction and correction anchor point control of the present invention. Detailed Implementation

[0020] 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, not all, of the embodiments of the present invention. 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.

[0021] Please refer to Figure 1This embodiment provides a real-time production planning and scheduling system for tooling based on IoT QR codes, including an IoT QR code event access module, an event chain construction module, a status digital shadow maintenance module, a plan constraint mapping module, and a local plan correction module. The IoT QR code event access module receives scan records generated by tooling during requisition, online, transfer, temporary storage, release, or rework stages and converts them into standardized QR code events. The event chain construction module generates a QR code event chain according to tooling identifier, order identifier, process node, and event timestamp. The status digital shadow maintenance module generates a tooling status version based on the QR code event chain. The plan constraint mapping module maps the tooling status version to the order process network, tooling occupancy window, and preceding / following process constraints. The local plan correction module generates correction results for plan nodes with constraint conflicts after mapping and adjacent shared tooling nodes. In specific implementation, the IoT QR code event access module does not directly write the scan record into the tooling's current status field, but instead decomposes the scan record into an identity field, a business field, a time field, and a source field. The identity field includes at least the tooling identifier and the scanning terminal identifier, and the business field... The segment includes at least an order identifier, a process node, and a scanning step. The time field includes at least the event occurrence time and the reporting time. The source field is used to distinguish between real-time scanning, cached re-transmission, and background re-entry. After the decomposed fields are formatted, they form a standardized QR code event. The event chain construction module uses the tooling identifier as the main index and the order identifier and process node as auxiliary indexes. It arranges the standardized QR code events generated by the same tooling in different stages into a QR code event chain with a preceding reference relationship. The status digital shadow maintenance module only reads the QR code events that have passed the chain verification and synchronously writes the tooling's current process, occupying order, associated plan node, and status version number into the status record. The plan constraint mapping module embeds the status version number into the tooling occupancy window and preceding and following process constraints according to the binding relationship between the plan node and the tooling requirement in the order process network. The local plan correction module only extracts the plan nodes that have the same occupancy, adjacent process, or shared relationship with the changed tooling for recalculation to avoid irrelevant plan nodes being disturbed by scanning events. This embodiment makes the QR code event, tooling status version, and production plan constraints form a closed data chain, reducing the continuous deviation between the plan table and the on-site tooling flow status.

[0022] In the above implementation, the event chain credibility value is calculated for the j-th standardized QR code event, as shown in the following formula: ; in, This represents the confidence value of the j-th standardized QR code event relative to the current QR code event chain. This indicates that the time of the event is consistent with the temporal order of events before and after the QR code event chain. This indicates that the digest of the previous state is consistent with the digest index of the most recent trusted event. This indicates that the path between the process node and the process route is consistent. This indicates that the scanning process and the state loop rules have consistent values. , , and They represent , , and The corresponding weights are calculated to ensure consistency, and the sum of the four values ​​is 1. For example, if an online scanning event satisfies the time sequence, process route, and scanning step but lacks a preceding state summary, then... , and Take 1, If the value is 0, the online scanning event does not directly cover the current tooling status, but enters the candidate branch to wait for cross-verification with subsequent events; when all four values ​​of a release scanning event are 1, the release scanning event is connected to the QR code event chain and triggers the status version update. This embodiment provides a calculable chain-like determination basis for whether the scanning record enters the planned correction link.

[0023] In a preferred embodiment, reference Figure 2The event chain construction module configures an event index for each standardized QR code event, consisting of a tooling identifier, order identifier, process node, event type, event occurrence time, reporting time, and preceding status summary. A chained reference relationship is formed between the event occurrence time and the preceding status summary. Under the same tooling identifier, closed-loop rules are set for the states of requisition, online, transfer, temporary storage, release, and rework. Scan records lacking preceding status summaries, having duplicate event indexes, or being inconsistent with the closed-loop rules are marked as events requiring correction. In specific implementation, the event index can be formed by concatenating the tooling identifier, order identifier, process node, and event occurrence time, and then writing the preceding status summary. The preceding status summary is obtained by performing a consistency digest operation on the core fields of the most recent trusted event. Each event in the QR code event chain stores the preceding event's... The abstract citation enables subsequent events to determine whether to inherit the existing state. The state closed-loop rules are based on the tooling flow semantics for allowing online access after requisition, allowing transposition or temporary storage after online access, allowing online access or release after temporary storage, allowing online access or release after transposition, allowing requisition after release, and allowing temporary storage or release after repair. If there is no online or temporary storage state before the release event, if the process node pointed to by the transposition event does not belong to the current order process route, or if the same event index appears repeatedly on the same chain, the event chain construction module will not write it to the latest trusted chain tail, but will put it into the event to be corrected area. The event to be corrected area records the original scan field, conflict type, and associated chain segment position. This embodiment organizes discrete scan records into a traceable event sequence through event indexes and state closed-loop rules to prevent old events or abnormal events from directly changing the tooling state version.

[0024] Table 1 is a table showing the correspondence between the QR code event chain construction and the state closed-loop rules. Table 1 shows the prerequisite states, verification fields, and processing results that need to be met when different scanning links enter the QR code event chain. In specific implementation, Table 1 can be stored as a rule table in the production plan database. After receiving the standardized QR code event, the event chain construction module reads the rule table and generates the corresponding verification tag. In this embodiment, the event access rules exist in the form of configurable data, which makes it easy to maintain the same set of chain verification logic under different process routes.

[0025] Table 1. Correspondence between QR code event chain construction and state loop closure rules ; Furthermore, the event chain construction module generates event consistency tags for the events to be corrected. These tags include consistency in time sequence, process route, scanning step, and state summary. When multiple events to be corrected exist under the same tooling identifier, event candidate branches are formed according to the event consistency tags. These candidate branches are then matched with the existing QR code event chain using three types of matching: chain head, chain tail, and middle insertion. Event candidate branches that satisfy the state closure rule and do not disrupt the continuity of the preceding state summary are retained. Specifically, consistency in time sequence indicates that the occurrence time of the event to be corrected can be inserted between adjacent reliable events; consistency in process route indicates that the process node of the event to be corrected is located on the reachable path of the order process network; and consistency in scanning step indicates that the event type is consistent with the allowed... There is a closed relationship between the preceding states. The consistency of the state digest is used to indicate that the preceding state digest can point to a certain trusted event or candidate event. The event chain construction module combines the events to be corrected with the same tooling identifier and adjacent time ranges into candidate branches, and attempts to access the head, tail and middle positions of the QR code event chain respectively. The head matching is used to handle historical supplementary events, the tail matching is used to handle delayed reporting events, and the middle insertion matching is used to handle cached supplementary events. If the preceding state digest of any adjacent event on the chain is destroyed after insertion, the candidate branch will not enter the trusted chain. If multiple candidate branches meet the closed-loop rule, the subsequent state digital shadow maintenance module will perform a second screening according to the plan constraints. This embodiment ensures that the events to be corrected still retain a verifiable path before confirmation, avoiding the state chain breakage caused by simply discarding abnormal scanning records.

[0026] During the above candidate branch processing, the event candidate branch access value is calculated according to the following formula: ; in, This represents the access value of the candidate branch for the r-th event. This represents the normalized value of the number of consecutive events in the preceding state summary of the QR code event chain after a candidate branch is connected. This indicates that the event process node within the candidate branch conforms to the normalized value of the process route. This represents the normalized value indicating the temporal compatibility between the candidate branch and the existing chain segment. This indicates that after a candidate branch is connected, the normalized value of the existing state version needs to be rolled back. , , and They represent , , and The corresponding weights are all non-negative. For example, when a candidate branch of a cache retransmission event makes the digest continuity, process reachability, and time compatibility all reach 1 and no rollback is required. If the value is 0, the candidate branch is considered an accessible branch; if another candidate branch is time-compatible but requires a rollback to the current state version, As the value increases, the candidate branch is only retained as a historical supplementary record. This embodiment enables the matching of the first, last, and middle insertions of the chain to be evaluated uniformly, reducing the reverse disturbance of the event to be corrected to the current plan version.

[0027] In one embodiment, reference Figure 3 The status digital shadow maintenance module establishes a status record table for each tooling identifier. This table includes the current process, occupied order, associated plan node, status version number, status lock flag, and most recently trusted event index. Upon receiving the standardized QR code event, the module performs a preliminary relationship comparison between the standardized QR code event and the most recently trusted event index, and updates the status version number according to the matching relationship between the scanning step and the process route. Candidate status sets are generated for events with time inversion, cross-process jumps, or missing status loops. In specific implementation, the status record table uses the tooling identifier as the primary key, the status version number uses an incremental version sequence, the status lock flag indicates whether the current tooling already has an unclosed occupied window, and the most recently trusted event index points to the QR code event chain. When a new trusted event is received, the status digital shadow maintenance module reads the previous status summary of the trusted event and compares it with the corresponding summary of the most recent trusted event index. If the comparison is consistent and the scanning process and the current process status meet the closure rule, the current process, occupied order, associated plan node, and status version number are updated. If the comparison is inconsistent, the current status in the status record table is not overwritten. Instead, a candidate status set is generated based on adjacent events in the QR code event chain, the order process network, and the tooling occupancy window. Each candidate status in the candidate status set contains a candidate current process, a candidate occupied order, a candidate plan node, and a candidate occupancy time. This embodiment keeps the tooling status digital shadow versioned and traceable, avoiding the scanning arrival order directly determining the status result.

[0028] In a preferred embodiment, the state digital shadow maintenance module establishes a state transition table for the candidate state set. The state transition table includes candidate current process, candidate occupied order, candidate planned node, candidate occupation start and end time, tooling state source category, and corresponding event index. The state transition table is then checked for consistency with the process route, planned node table, and tooling occupation window table. Candidate states are filtered according to the order of complete prerequisite relationships, non-overlapping occupation windows, and reachable process nodes. The filtered candidate states are written into the state record table corresponding to the tooling identifier. Specifically, the tooling state source category can be distinguished into direct derivation from a trusted chain, candidate branch derivation, historical retransmission derivation, and conflict event derivation. The candidate occupation start and end time in the state transition table is determined by the candidate event. The time and the corresponding planned node's occupied window are jointly determined. If the current process of a candidate state cannot be reached from the previous process node in the order process network, the candidate state is removed from the state transition table. If the candidate's occupied time overlaps with the confirmed occupied window of the same tooling on another planned node, the candidate state is retained as a conflict candidate and is not written into the current state version. If the candidate state's preceding relationship is complete and the process node is reachable, the state number shadow maintenance module writes it into the state record table and generates a new state version number. At the same time, the candidate source event index is retained during writing, so that subsequent planned constraint mapping can track the state source. In this embodiment, the abnormal QR code event is transformed into a constrained and filtered candidate state through the state transition table, avoiding the expansion of a single scanning field error into a planned node error.

[0029] In the above state selection process, the candidate state selection value is calculated according to the following formula: ; in, This represents the selection value for the q-th candidate state. This indicates that the preceding relation has a complete set of values. This indicates that the tooling occupies a non-overlapping window for value retrieval. Indicates the reachable values ​​of process nodes. This represents the cost of reverting an existing state version after a candidate state is written. , , and They represent , , and The corresponding weights are all non-negative, for example, when a candidate state has complete preceding relationships, non-overlapping occupied windows, and reachable process nodes without causing backtracking. , , All are 1 and If the value is 0, the candidate state is preferentially written into the state record table; if another candidate state overlaps with the confirmed occupied window, then... If the value is set to 0, the candidate state is retained as a conflict candidate. This embodiment makes the candidate state screening have a verifiable source of constraints, avoiding updating the state version based solely on the event arrival time.

[0030] Furthermore, the status digital shadow maintenance module establishes a bidirectional index between each event in the event candidate branch and its corresponding candidate status. The bidirectional index includes the event index, the candidate current process, the candidate occupied order, and the status version number. When the event candidate branch can form the same preceding status summary with a unique candidate status, the event candidate branch is connected to the QR code event chain. When the event candidate branch corresponds to multiple candidate statuses, cross-matching is performed according to the planned node table, the tooling occupied window table, and the process preceding and following constraint table, and the candidate status with the unique matching result is retained. In specific implementation, the bidirectional index consists of an event-side index table and a status-side index table. The event-side index table stores the candidate status number pointed to by the event index, and the status-side index table stores the event index set pointed to in reverse by the candidate status number. When processing event candidate branches, the status digital shadow maintenance module first checks whether the candidate status is unique. If the previous status summary of the unique candidate status is consistent with the event summary at the head of the event candidate branch chain, the event candidate branch is connected to the trusted QR code event chain. If multiple candidate statuses can be derived from the same candidate branch, the current execution mark of the plan node in the plan node table, the confirmed occupancy time in the tooling occupancy window table, and the adjacent process relationship in the process pre- and post-process constraints table are read. Cross-matching is performed on each candidate status. Only when the matching result is unique is it written to the status record table. If the matching result is not unique, the candidate branch and candidate status are retained and wait for subsequent QR code events to supplement. This embodiment controls the access range of abnormal events through the bidirectional traceability relationship from event to status and from status to event, reducing the situation where candidate status is mistakenly written to the current tooling status.

[0031] In one embodiment, reference Figure 4The planning constraint mapping module establishes a planning node table, a tooling occupancy window table, a planning node current execution flag, and a process pre- and post-constraint table in the order process network, and writes the tooling status version into the corresponding planning node, occupancy window, and pre- and post-constraint tables respectively. The local planning correction module uses the changed tooling identifier as an index to extract a set of nodes that have the same tooling occupancy relationship, adjacent process relationship, or shared tooling relationship with the planning node, and forms a planning segment to be corrected and an index of the original planning sequence within the node set. In specific implementation, the planning node table records the order identifier, process node, planning start time, planning end time, and required tooling identifier; the tooling occupancy window table records the tooling identifier, occupancy planning node, occupancy start time, occupancy end time, and status version number; and the planning node current execution flag is used to distinguish unopened... The plan nodes are categorized into start, execution, temporary, and completed. The process pre- and post-process constraint table is used to store the sequential relationship between adjacent processes within an order. When the tooling status version changes, the plan constraint mapping module locates the associated plan node pointed to by the status version and writes the new status version number into the corresponding plan node and the occupied window. The local plan correction module expands the node set outward from the changed tooling identifier as the entry point. The expansion scope includes other plan nodes corresponding to the same tooling identifier, the pre- and post-process nodes adjacent to the associated plan node in the same order, and nodes that share the same type of tooling or the same tooling occupied window. The extracted node set is saved as a plan fragment to be corrected according to the original plan order. In this embodiment, the status version change is restricted to the plan fragment related to tooling resources and process constraints, avoiding frequent changes in plan version caused by full plan reordering.

[0032] Furthermore, the local plan correction module establishes a local constraint matrix for the plan segment to be corrected. This local constraint matrix includes the binding relationship between plan nodes and tooling occupancy windows, the sequence relationship between adjacent processes, the mutual exclusion relationship between the same tooling in different plan nodes, and the minimum changeover interval relationship. Conflict edges caused by changes in the tooling state version are marked in the local constraint matrix, and only for connected regions containing the conflict edges, a plan node rearrangement sequence, the original plan version number, and the node source index are generated. Specifically, the local constraint matrix uses the plan nodes in the plan segment to be corrected as row and column indices. Matrix elements are used to indicate whether there are resource mutual exclusion, process sequence, window overlap, or changeover interval constraints between two plan nodes, and the binding relationship between the plan node and the tooling occupancy window. The relationships are used to determine whether a certain planning node must wait for the release of a specific tooling. The sequential relationship between adjacent processes is used to restrict the process order within the same order. The mutual exclusion relationship between the same tooling and different planning nodes is used to restrict that the same tooling can only correspond to one planning node within the same time window. The minimum changeover interval relationship is used to record the necessary interval between the release of tooling from one planning node and its use in the next planning node. When a change in the tooling status version causes the occupancy window of a certain planning node to move or the execution mark to change, the matrix elements in the local constraint matrix connected to the planning node are marked as conflict edges. The local planning correction module only reads the connected regions containing conflict edges to generate a planning node rearrangement sequence. This embodiment uses matrix-based constraint expression to clearly define the local correction boundary and reduce the situation where nodes unrelated to conflict are adjusted.

[0033] In the local constraint matrix, the set of affected nodes is determined according to the following formula: ; in, This indicates the set of affected nodes that need to undergo local plan correction. Let R represent the i-th planning node in the planning segment to be corrected, and let R represent the number of constraint edges in the local constraint matrix. This indicates whether the i-th planning node is connected to the r-th constraint edge. This indicates whether the r-th constraint edge is marked as a conflict edge due to a change in the tooling state version. For example, if a planning node is connected to both a mutually exclusive tooling edge and an adjacent process edge, and the mutually exclusive tooling edge is marked as conflicting while the adjacent process edge is not conflicting, the summation value is greater than 0, and the planning node enters the set of affected nodes. If a planning node is not connected to any conflicting edge, it does not enter the local planning correction. In this embodiment, the constraint edge connection relationship is used to determine the rearrangement range, so that the planning correction forms a verifiable local boundary around the tooling state change.

[0034] In a preferred embodiment, the local plan correction module generates a candidate correction table based on the plan node rearrangement sequence. The candidate correction table includes the plan node adjustment order, tooling occupancy window adjustment amount, correction trigger event index, preceding and following process constraint satisfaction flags, and shared tooling conflict flags. For multiple candidate correction tables, a target correction table is determined according to the following rules: all preceding and following process constraint satisfaction flags are satisfied, the shared tooling conflict flag is empty, and the total tooling occupancy window adjustment amount is prioritized. The target correction table is then written into the production plan version record. Specifically, the plan node rearrangement sequence is generated by the plan nodes within the affected node set according to their process sequence, tooling release status, and current execution flag. The plan node adjustment order in the candidate correction table records the new position of each plan node in the local segment, and the tooling occupancy window... The adjustment amount records the time offset between the original occupied window and the adjusted occupied window. The correction trigger event index is used to point to the position of the QR code event chain that triggered this correction. The preceding and following process constraint satisfaction flag is used to indicate whether the internal process sequence of each order is maintained after the adjustment. The shared tooling conflict flag is used to indicate whether the same tooling is still occupied by two planning nodes simultaneously after the adjustment. When multiple candidate correction tables all satisfy the process sequence, the local planning correction module excludes candidate correction tables whose shared tooling conflict flag is not empty, and then selects the candidate correction table with the smaller total value of the tooling occupied window adjustment amount as the target correction table. The production plan version record saves the target correction table, the original plan version number, the trigger event index, and the set of affected nodes. In this embodiment, a traceable plan correction version is formed in a local area, so that the tooling status change is transformed into clear planning node adjustment data.

[0035] In the process of determining the target correction table mentioned above, the evaluation value of the candidate correction table is calculated according to the following formula: ; in, This represents the evaluation value of the l-th candidate correction table. This indicates that the constraints of the preceding and following processes satisfy the normalized value of the marker. This indicates a normalized value where the shared tooling conflict flag is empty. This represents the normalized value of the total adjustment amount of the tooling window. This represents the normalized offset value of the planned node relative to the original planned sequence. , , and They represent , , and The corresponding weights are all non-negative. For example, when a candidate correction table satisfies all preceding and following process constraints and there are no shared tooling conflicts. and If the candidate correction table adjusts only one planning node connected to the conflicting edge and the window offset is small, then... and If the value is low, the candidate correction table is written to the production plan version record; if another candidate correction table eliminates shared tooling conflicts but changes the order of multiple conflict-free plan nodes, then... As the value increases, the candidate correction table is no longer used as the target correction table. In this embodiment, the selection of the target correction table is jointly limited by process constraints, shared tooling constraints, and local stability constraints.

[0036] Furthermore, the local plan correction module establishes a correction anchor table when writing the production plan version record. This table includes the trigger QR code event chain position, the pre-change state version number, the post-change state version number, the target correction table identifier, and the set of affected plan nodes. When a subsequent standardized QR code event points to the set of affected plan nodes, the latest production plan version is read based on the correction anchor table, and candidate correction tables not referenced by subsequent events are marked as invalid records. For scan records that reappear at the same trigger QR code event chain position, no new target correction table is generated. In specific implementation, the correction anchor table uses a combination of the trigger QR code event chain position and the state version number as the search key. The trigger QR code event chain position is used to locate the credible event or candidate branch access position that caused the plan correction, and the pre-change state version number is used to record the pre-correction state number. The shadow version, the changed status version number is used to record the status version written into the plan constraints after correction, the target correction table identifier is used to point to the target correction table that has been written into the production plan version record, and the affected plan node set is used to limit the range of subsequent scanning events reading the latest plan version. When the tooling identifier, order identifier or plan node of a subsequent scanning event falls into the affected plan node set, the local plan correction module no longer starts calculating from the original plan version, but reads the latest production plan version corresponding to the correction anchor table. If the subsequent event does not reference a candidate correction table and a new target correction table has been generated, the candidate correction table is marked as an invalid record. Scanning records that reappear at the same triggering QR code event chain position only update the audit record. This embodiment maintains the consistency of the plan correction version through the correction anchor table to avoid repeated generation of plan correction results by duplicate scanning records.

[0037] In the calibration anchor point table, the repeated trigger determination is calculated according to the following formula: ; in, This indicates that the judgment value is triggered repeatedly. This indicates that the value is 1 if the condition is true and 0 if the condition is false. This indicates the position in the QR code event chain that the current scan record points to. This indicates the version number of the current record before the change. This indicates the version number of the changed status corresponding to the current record. , and These represent the existing trigger QR code event chain position, the pre-change state version number, and the post-change state version number in the correction anchor point table, respectively. For example, if a release scan record is re-reported due to network retransmission, the corresponding release scan record... , and When consistent with existing records in the calibration anchor point table, If the value is 1, the local planning correction module reads the existing target correction table and does not generate a new target correction table; if a certain transcoding scan record points to the same tooling but its status version number changes, If the value is 0, the local plan correction module enters a new correction judgment process. In this embodiment, the duplicate scanning identification is bound to the production plan version record to avoid repeated disturbance of the plan correction result at the same event chain position.

[0038] In this embodiment, the above modules can be deployed as data processing programs corresponding to the event table, status table, constraint table, and version table in the same production planning database, or they can be deployed as business services that call each other. The IoT QR code event access module is responsible for converting on-site scanning records into standardized QR code events. The event chain construction module is responsible for organizing standardized QR code events into QR code event chains and identifying events to be corrected. The status digital shadow maintenance module is responsible for converting trusted chain events and candidate branches into status versions. The plan constraint mapping module is responsible for synchronizing status versions to the order process network, tooling occupancy window, and preceding and following process constraints. The local plan correction module is responsible for generating a target correction table around conflict edges and maintaining a correction anchor table. Throughout the entire process, after the scanning record enters the system, it must be... The process involves four data processing steps: event chain verification, status version update, plan constraint mapping, and local correction judgment. Intermediate data generated in any step is stored with a corresponding source index, allowing the plan adjustment result to be traced back to the specific QR code event chain position. If situations occur on-site such as not going online after being issued, delayed release after going online, re-transmission of release event cache, or cross-process jump of sequence event, the system will process the data through the event area to be corrected, candidate status set, local constraint matrix, and correction anchor point table. The system will not directly overwrite the plan status with the last arriving scan record. This embodiment provides a complete implementation path from IoT QR code scan record to production plan scheduling correction, and discloses the specific data processing methods for event chain generation, status version maintenance, plan constraint mapping, local plan correction, and repeated trigger control.

Claims

1. A real-time production planning and scheduling system for tooling based on Internet of Things (IoT) QR codes, characterized in that, It includes an IoT QR code event access module, an event chain construction module, a status digital shadow maintenance module, a plan constraint mapping module, and a local plan correction module; The IoT QR code event access module receives the scanning records generated by the tooling during the requisition, online, sequence transfer, temporary storage, release or rework process and converts them into standardized QR code events. The event chain construction module generates a QR code event chain based on tooling identifier, order identifier, process node, and event timestamp. The status digital shadow maintenance module generates a tooling status version based on the QR code event chain; The planning constraint mapping module maps the tooling status version to the order process network, tooling occupancy window, and preceding and following process constraints. The local plan correction module generates correction results for plan nodes with constraint conflicts after mapping and adjacent shared tooling nodes.

2. The real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 1, characterized in that, The event chain construction module configures an event index for each standardized QR code event, consisting of tooling identifier, order identifier, process node, event type, event occurrence time, reporting time, and preceding status summary. A chain reference relationship is formed according to the event occurrence time and the preceding status summary. Under the same tooling identifier, a closed-loop rule is set for the status between requisition, online, transfer, temporary storage, release, and rework. Scanning records that lack a preceding status summary, have duplicate event indexes, or are inconsistent with the status closed-loop rule are marked as events to be corrected.

3. The real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 1, characterized in that, The status digital shadow maintenance module establishes a status record table for each tooling identifier. The status record table includes the current process, occupied order, associated plan node, status version number, status lock flag, and recent trusted event index. Upon receiving the standardized QR code event, the standardized QR code event is compared with the most recent trusted event index, and the status version number is updated according to the matching relationship between the scanning link and the process route. Generate a set of candidate states for events that are time-inverted, jump across processes, or have missing state loops.

4. The real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 1, characterized in that, The planning constraint mapping module establishes a planning node table, a tooling occupied window table, a planning node current execution flag, and a process pre- and post-constraint table in the order process network, and writes the tooling status version into the corresponding planning node, occupied window, and pre- and post-constraints respectively. The local plan correction module uses the changed tooling identifier as an index to extract a set of nodes that have the same tooling occupation relationship, adjacent process relationship, or shared tooling relationship with the plan node, and forms a plan segment to be corrected and an index of the original plan sequence within the set of nodes.

5. A real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 2, characterized in that, The event chain construction module generates event consistency tags for the events to be corrected. The event consistency tags include consistency in time sequence, consistency in process route, consistency in scanning steps, and consistency in status summary. When there are multiple events to be corrected under the same tooling identifier, event candidate branches are formed according to the event consistency label combination, and the event candidate branches are matched with the already formed QR code event chain in three categories: chain head, chain tail, and middle insertion. Event candidate branches that meet the state closure rule and do not disrupt the continuity of the previous state summary are retained.

6. The real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 3, characterized in that, The status digital shadow maintenance module establishes a status transition table for the candidate status set. The status transition table includes the candidate current process, candidate occupied order, candidate planned node, candidate occupied start and end time, tooling status source category and corresponding event index. The state transition table is checked for consistency with the process route, planned node table and tooling occupancy window table. Candidate states are then filtered in the order of complete prerequisite relationships, non-overlapping occupancy windows and reachable process nodes. The filtered candidate states are then written into the state record table corresponding to the tooling identifier.

7. A real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 4, characterized in that, The local plan correction module establishes a local constraint matrix for the plan segment to be corrected. The local constraint matrix includes the binding relationship between the plan node and the tooling window, the sequential relationship between adjacent processes, the mutual exclusion relationship of the same tooling between different plan nodes, and the minimum changeover interval relationship. In the local constraint matrix, conflicting edges caused by changes in the tooling state version are marked, and only for connected regions containing the conflicting edges, a planned node rearrangement sequence, the original planned version number, and the node source index are generated.

8. A real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 7, characterized in that, The local plan correction module generates a candidate correction table based on the rearrangement sequence of the plan nodes. The candidate correction table includes the plan node adjustment order, tooling window adjustment amount, correction trigger event index, constraint satisfaction flags of preceding and following processes, and shared tooling conflict flags. For multiple candidate correction tables, the target correction table is determined according to the following rules: the constraint satisfaction mark of both preceding and subsequent processes is satisfied, the shared tooling conflict mark is empty, and the total value of tooling occupation window adjustment is sorted first. The target correction table is then written into the production plan version record.

9. A real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 5, characterized in that, The status digital shadow maintenance module establishes a bidirectional index between each event in the event candidate branch and its corresponding candidate status. The bidirectional index includes the event index, the candidate current process, the candidate occupied order, and the status version number. When the event candidate branch can form the same preceding state summary with the unique candidate state, the event candidate branch is connected to the QR code event chain; When the event candidate branch corresponds to multiple candidate states, cross-matching is performed according to the plan node table, tooling occupancy window table, and process pre- and post-process constraint table, and the candidate state with a unique matching result is retained.

10. A real-time production planning and scheduling system for tooling based on IoT QR codes according to claim 8, characterized in that, The local plan correction module establishes a correction anchor table when writing the production plan version record. The correction anchor table includes the location of the trigger QR code event chain, the version number before the change, the version number after the change, the target correction table identifier, and the set of affected plan nodes. When a subsequent standardized QR code event points to the set of affected planning nodes, the latest production plan version is read according to the correction anchor table, and candidate correction tables that are not referenced by subsequent events are marked as invalid records. For scan records that reappear at the same trigger QR code event chain location, no new target correction table will be generated.

Images