A method, device, apparatus and storage medium for planning a scheduled index migration

Abstract

The application relates to the technical field of intelligent manufacturing, and discloses a plan scheduling index migration method, device, equipment and storage medium. The method comprises the following steps: monitoring a candidate task set state change event; collecting migration context information in response to the event; identifying an event type and determining an index migration strategy; performing migration update on a task logic index and / or a reference position based on the context and the strategy, maintaining the consistency of task identification, the logic index and the reference position before and after the event; and outputting the updated logic index mapping and reference position information. Through the closed-loop process of event monitoring, context collection, strategy matching and migration update, the unified maintenance of the logic index and the reference association in the dynamic evolution process of the candidate task list is realized, the consistency is ensured, the explainable priority and consistent index semantics are provided for downstream modules, the downstream incremental determination error caused by index misplacement or reference disconnection is effectively avoided, and the accuracy and stability of the scheduling system are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent manufacturing technology, specifically to a method, apparatus, device, and storage medium for index migration of planning and scheduling. Background Technology

[0002] In Advanced Planning and Scheduling (APS) systems, candidate task sequences are typically stored in linear lists, with logical indexes identifying their positions in the queue. These lists are also associated with a policy baseline task and its baseline value to support subsequent incremental decisions. Existing task list maintenance techniques primarily focus on changes in the physical storage structure—that is, directly modifying the underlying data when tasks are removed, their order is adjusted, or the baseline object is switched—while often neglecting the synchronous update of logical mapping relationships.

[0003] However, existing technologies lack systematic index migration rules and baseline association maintenance mechanisms when handling dynamic list evolution. Specifically, this manifests in several ways: the auxiliary indexes are not updated synchronously after list compression, leading to inconsistencies between the logical index and the physical order; during partial or full reordering, task identifiers are prone to misalignment with the actual list order; and when the baseline task changes or its location shifts, the positioning information on the strategy side fails to keep pace with the actual elements.

[0004] The inconsistency between the aforementioned index semantics and physical state can lead to subsequent scheduling modules obtaining incorrect priority information during incremental determination, resulting in technical problems such as "ghost offsets" or "baseline misalignment." This amplifies the risk of propagating computational errors and affects the accuracy and stability of the entire production planning system. Therefore, ensuring that the candidate list maintains interpretable priority and consistent index semantics during dynamic evolution processes such as compression, rearrangement, and baseline switching has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0005] In related technologies, task list maintenance techniques only focus on changes in physical storage structure and lack systematic index migration rules and baseline association maintenance mechanisms, resulting in inconsistencies between logical indexes and physical states in the candidate list during dynamic evolution.

[0006] In a first aspect, embodiments of this application provide a method for migrating an index for planning and scheduling, the index migration method comprising: Monitor events that change the status of the candidate task set. The types of change events include: compression events that change the physical location of candidate tasks, rearrangement events that change the order of candidate tasks, and baseline switching events that change the baseline status. In response to the detection of a current state change event, migration context information is collected. The migration context information includes at least the candidate task list status before the event occurred, the mapping relationship between task identifiers and logical indexes, and the baseline task information. Identify the event type of the current state change event, and determine the corresponding index migration strategy based on the event type; Based on migration context information and index migration strategy, migration updates are performed on the logical index and / or baseline location of tasks in the candidate task set to maintain the consistency of task identifier, logical index and baseline location before and after the event. Output the updated logical index mapping and baseline positioning information.

[0007] In conjunction with the first aspect, in one implementation, performing migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on migration context information and index migration strategies includes: If the current event type is a compressed event, remove the dequeued tasks from the candidate task set and perform a translation update on the task logic index of the remaining candidate tasks.

[0008] In conjunction with the first aspect, in one implementation, performing migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on migration context information and index migration strategies includes: If the current event type is a rearrangement event, then determine the range of rearranged tasks affected by the rearrangement event in the candidate task set; Get the ranking information of tasks within the rearranged task range after reordering, and update the logical index of each task based on the starting position of the rearranged task range and the ranking information of the tasks.

[0009] In conjunction with the first aspect, in one implementation, the step of obtaining the ranking information of tasks within the rearranged task interval after reordering and updating the logical index of each task based on the starting position of the rearranged task interval and the ranking information of the tasks further includes: If the reordering event is a full reordering, then set the starting position of the reordering task interval to the starting position and update the logical index for all candidate tasks.

[0010] In conjunction with the first aspect, in one implementation, performing migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on migration context information and index migration strategies includes: If the current event type is a baseline switching event, then the corresponding baseline task is searched in the updated candidate task set based on the baseline task information and task identifier. If the baseline task exists in the candidate task set but its location changes, then update the baseline positioning information to point to the current location of the baseline task; If the baseline task does not exist in the candidate task set, the baseline reselection process is triggered, and the baseline task identifier, baseline value, and baseline positioning information are redefined.

[0011] In conjunction with the first aspect, in one implementation, before outputting the updated logical index mapping and reference positioning information, the method further includes: Verify whether the logical traversal order is consistent with the sorting and writing order; If the verification results are inconsistent, an audit alert will be output, and a rollback or rebuild process will be triggered.

[0012] In conjunction with the first aspect, in one implementation, the output of the updated logical index mapping and reference positioning information includes: The updated index results are visualized and then transmitted to downstream modules.

[0013] Secondly, embodiments of this application provide a scheduling index migration apparatus, the index migration apparatus comprising: The event listening module is used to monitor events that change the state of the candidate task set; The context acquisition module is used to acquire migration context information in response to the detection of a current state change event; The strategy determination module is used to identify the event type of the current state change event and determine the corresponding index migration strategy based on the event type. The migration execution module is used to perform migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on migration context information and index migration strategies. The view output module is used to output the updated logical index mapping and baseline positioning information.

[0014] Thirdly, embodiments of this application provide an index migration device, which includes a processor, a memory, and an index migration program stored in the memory and executable by the processor, wherein when the index migration program is executed by the processor, it implements the steps of the index migration method as described in any one of the above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing an index migration program, wherein when the index migration program is executed by a processor, it implements the steps of the index migration method as described in any of the preceding claims.

[0016] The beneficial effects of the technical solutions provided in this application include: This application establishes a closed-loop process of event monitoring, context collection, strategy matching, and migration updates, which enables unified maintenance of the logical index and benchmark association during the dynamic evolution of the candidate task list. This ensures the consistency of task identifiers, logical indexes, and benchmark positioning before and after events, thereby providing downstream modules with an interpretable priority order and consistent index semantics. It effectively avoids downstream incremental judgment errors caused by index misalignment or benchmark disconnection, and improves the accuracy and stability of the scheduling system. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating an embodiment of the index migration method of this application; Figure 2 This is a schematic diagram of the hardware structure of the index migration device involved in the embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] In related technologies, task list maintenance techniques only focus on changes in physical storage structure and lack systematic index migration rules and baseline association maintenance mechanisms, resulting in inconsistencies between logical indexes and physical states in the candidate list during dynamic evolution.

[0020] In a first aspect, embodiments of this application provide a method for migrating indexes for planned scheduling.

[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the index migration method of this application. Figure 1 As shown, the index migration methods include: Step S1: Monitor the status change events of the candidate task set.

[0022] Specifically, the change event types include: compression events that change the physical location of candidate tasks, rearrangement events that change the order of candidate tasks, and baseline switching events that change the baseline state.

[0023] Understandingly, compression events include those where subsequent tasks need to move forward to fill the gap after the task at the head of the queue is executed or canceled, resulting in a change in physical storage location. Reordering events include re-ordering some or all tasks in the queue based on task priority, urgency, or a new scheduling policy. Baseline switching events include changes in the position of the baseline task required by the policy dimension, or the failure of the original baseline task requiring a new one. These events can be captured in real time using event listening mechanisms (such as the observer pattern, message bus, or callback functions). Explicit event sources help avoid situations where "tables are quietly modified without triggering migrations," ensuring that all state changes are managed.

[0024] Step S2: In response to the detection of a current state change event, collect migration context information.

[0025] Specifically, the migration context information includes at least the status of the candidate task list before the event occurred, the mapping relationship between task identifiers and logical indices, and the baseline task information; among which, the status of the candidate task list includes the physical length of the list, the effective data range, etc. The mapping relationship between task identifiers and logical indices includes the logical position of each task before the event occurred.

[0026] Optionally, for compressed events that use logical offsets, the migration context information also includes the logical offset.

[0027] It is worth noting that the purpose of collecting contextual information is to provide a "previous state" reference for subsequent migration updates, ensuring that migration calculations are based on accurate historical data and avoiding data races caused by concurrent modifications.

[0028] In some specific implementations, the context information for a compression event includes: the logical offset before compression, the candidate list before compression, the valid task range before compression, the task identifiers still retained in the candidate set, and the mapping from the task to the logical index before compression.

[0029] In some specific implementations, the context information for a reordering event includes: reordering type (including partial reordering, suffix reordering, and full reordering), reordering interval, the task list in the interval before reordering, the task list in the interval after reordering, the sorting basis or sorting result number, and the set of tasks affected by the reordering.

[0030] In some specific implementations, the context information for a benchmark switching event includes: the current policy dimension, the original benchmark task identifier, the original benchmark value, the original benchmark task's position in the candidate task set, whether the benchmark task is still in the candidate list, and the new benchmark task identifier (if a reselection is triggered). Understandably, migration context information is used to record "what the state was before the migration and what the state should be after the migration".

[0031] Step S3: Identify the event type of the current state change event, and determine the corresponding index migration strategy based on the event type.

[0032] Understandably, the captured events need to be categorized and identified. Different event types correspond to different data change characteristics, thus requiring different migration strategies. This event type-based strategy distribution mechanism can then address index maintenance issues in different scenarios in a targeted manner, avoiding performance waste or logical omissions caused by using a single strategy.

[0033] Step S4: Based on the migration context information and index migration strategy, perform migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set to maintain the consistency of task identifiers, logical indexes, and baseline locations before and after the event.

[0034] Understandably, this step utilizes the collected migration context information to execute the corresponding index migration strategy and update the task metadata. The goal of the update is to maintain the consistency of the task identifier, logical index, and baseline location before and after the event.

[0035] Furthermore, step S4 includes the following cases: Case 1: The current event type is a compression event: Remove the dequeued tasks from the candidate task set and perform a translation update on the task logic index of the remaining candidate tasks.

[0036] Understandably, the relative order of tasks remains unchanged; only the invalid prefixes are removed, and all valid tasks are shifted forward as a whole. For compression events, a specific method is used: removing dequeued tasks and shifting the logical indexes of the remaining tasks. This ensures that the compressed logical indexes remain continuous and consistent with the physical order, eliminating index offset errors caused by prefix removal. Simultaneously, while ensuring index correctness, it avoids full table reconstruction, improving processing efficiency and access performance in compression scenarios.

[0037] Further, in an optional implementation, when performing a compressed event using a logical offset, the logical offset before the event and the effective task range are read; the logical offset of the candidate task list is set to 0; for each task still remaining in the candidate task list, the logical index after the event is calculated based on its logical index before the event and the logical offset; and the mapping relationship between the task identifier and the logical index is updated.

[0038] Scenario 2: The current event type is a rearrangement event.

[0039] Understandably, when the relative order of tasks changes, simple addition, subtraction, or shifting is not feasible; the tasks must be rewritten according to the new ranking. Specifically, this includes: Step A: Determine the range of rearranged tasks affected by the rearrangement event in the candidate task set.

[0040] Specifically, the interval [l, r) of rearranged tasks affected by the rearrangement event is determined in the candidate task set, where l is the starting position of the interval and r is the ending position of the interval. The indexes of tasks within this interval are reconstructed, while the indexes of tasks outside the interval remain unchanged.

[0041] Step B: Obtain the ranking information of tasks within the rearranged task interval after reordering, and update the logical index of each task based on the starting position of the rearranged task interval and the ranking information of the tasks.

[0042] Understandably, suffix reordering means that the prefix task remains unchanged, and only the second half starting from a certain position is reordered.

[0043] Furthermore, if the rearrangement event is a full rearrangement, the starting position l of the rearrangement task interval is set to the starting position "0", and the logical index is updated for all candidate tasks.

[0044] It's worth noting that a full reordering refers to re-sorting the entire candidate task list, requiring all tasks still in the candidate set to have their indices rewritten. By setting the interval start point to zero and updating all tasks during a full reordering, the integrity of the index semantics after the global list order changes is ensured, preventing global index errors due to partial update omissions, and enhancing the method's robustness and logical rigor when facing drastic changes to the entire list.

[0045] Optionally, if prefix merging is performed after the suffix task sorting, the final ordered interval after merging is used as the affected interval to rebuild the index uniformly.

[0046] Scenario 3: The current event type is a baseline switching event.

[0047] Specifically, the corresponding baseline task is searched in the updated candidate task set based on the baseline task information and task identifier. Case A: The baseline task is still in the list, but its position has changed: If the baseline task exists in the candidate task set but its position has changed, then update the baseline positioning information to point to the current position of the baseline task.

[0048] Case B: The original baseline task has left the candidate set: If the baseline task does not exist in the candidate task list, the baseline reselection process is triggered, and the baseline task identifier, baseline value and baseline positioning information are redefined.

[0049] Step S5: Output the updated logical index mapping and baseline positioning information.

[0050] In some specific implementations, step S5 includes: Step S5a: Verify whether the logical traversal order is consistent with the sorting and writing order.

[0051] Optionally, the updated list can be traversed to check whether the logical indices of adjacent tasks satisfy a monotonically increasing relationship, or to check whether the logical indexes correspond to physical storage slots.

[0052] Furthermore, if the verification results are inconsistent, it indicates that data corruption or logical errors have occurred during the migration process, and an audit alert is output, the error context is recorded, and a rollback or reconstruction of the entire index table is triggered.

[0053] Understandably, this step adds a security gate at the end of the migration chain, preventing index errors from propagating to downstream modules. Through runtime self-healing or auditing, it prevents index errors from contaminating subsequent incremental modules, significantly improving system stability and maintainability.

[0054] Step S5b: After visualizing the updated index results, transmit them to the downstream module.

[0055] Specifically, the updated index results are encapsulated into a specific data view object. This view object exposes only the read-only interface required by downstream modules, hiding the internal implementation details. The processed view is then transmitted to downstream modules (such as the incremental decision-making module and the admission sorting module).

[0056] It's worth noting that the visual processing provides a unified, true-source snapshot for downstream modules, preventing them from guessing the index or calculating based on old indexes. This decouples the index maintenance module from the downstream consumption module, ensuring that downstream modules operate based on the correct, latest state.

[0057] Secondly, embodiments of this application also provide a planned index migration device, the index migration device comprising: an event listening module, a context acquisition module, a strategy determination module, a migration execution module, and a view output module; wherein, The system comprises the following modules: an event monitoring module for monitoring state change events in the candidate task set; a context acquisition module for acquiring migration context information in response to a detected state change event; a strategy determination module for identifying the event type of the current state change event and determining the corresponding index migration strategy based on the event type; a migration execution module for performing migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on the migration context information and the index migration strategy; and a view output module for outputting the updated logical index mapping and baseline location information.

[0058] The functions of each module in the above-mentioned index migration device correspond to the steps in the above-mentioned index migration method embodiment, and their functions and implementation processes will not be described in detail here.

[0059] Thirdly, embodiments of this application provide an index migration device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0060] Reference Figure 2 , Figure 2 This is a schematic diagram of the hardware structure of the index migration device involved in the embodiments of this application. In the embodiments of this application, the index migration device may include a processor, a memory, a communication interface, and a communication bus.

[0061] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0062] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the index migration device, as well as interfaces used for interconnecting the index migration device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0063] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0064] The processor can be a general-purpose processor, which can call the index migration program stored in memory and execute the index migration method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the index migration program is called can be referred to in the various embodiments of the index migration method of this application, and will not be repeated here.

[0065] Those skilled in the art will understand that Figure 2 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0066] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0067] The present application has an index migration program stored on a computer-readable storage medium, wherein when the index migration program is executed by a processor, it implements the steps of the index migration method as described above.

[0068] The method implemented when the index migration procedure is executed can be referred to in various embodiments of the index migration method of this application, and will not be repeated here.

[0069] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0070] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0071] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0072] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0073] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0074] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0075] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for migrating indexes in a planning and scheduling process, characterized in that, The index migration method includes: Monitor events that change the status of the candidate task set. The types of change events include: compression events that change the physical location of candidate tasks, rearrangement events that change the order of candidate tasks, and baseline switching events that change the baseline status. In response to the detection of a current state change event, migration context information is collected. The migration context information includes at least the candidate task list status before the event occurred, the mapping relationship between task identifiers and logical indexes, and the baseline task information. Identify the event type of the current state change event, and determine the corresponding index migration strategy based on the event type; Based on migration context information and index migration strategy, migration updates are performed on the logical index and / or baseline location of tasks in the candidate task set to maintain the consistency of task identifier, logical index and baseline location before and after the event. Output the updated logical index mapping and baseline positioning information.

2. The index migration method as described in claim 1, characterized in that, The migration update of the logical index and / or baseline location of tasks in the candidate task set based on migration context information and index migration strategy includes: If the current event type is a compressed event, remove the dequeued tasks from the candidate task set and perform a translation update on the task logic index of the remaining candidate tasks.

3. The index migration method as described in claim 2, characterized in that, The migration update of the logical index and / or baseline location of tasks in the candidate task set based on migration context information and index migration strategy includes: If the current event type is a rearrangement event, then determine the range of rearranged tasks affected by the rearrangement event in the candidate task set; Get the ranking information of tasks within the rearranged task range after reordering, and update the logical index of each task based on the starting position of the rearranged task range and the ranking information of the tasks.

4. The index migration method as described in claim 3, characterized in that, The step of obtaining the ranking information of tasks within the rearranged task interval after reordering, and updating the logical index of each task based on the starting position of the rearranged task interval and the ranking information of the tasks, further includes: If the reordering event is a full reordering, then set the starting position of the reordering task interval to the starting position and update the logical index for all candidate tasks.

5. The index migration method as described in claim 1, characterized in that, The migration update of the logical index and / or baseline location of tasks in the candidate task set based on migration context information and index migration strategy includes: If the current event type is a baseline switching event, then the corresponding baseline task is searched in the updated candidate task set based on the baseline task information and task identifier. If the baseline task exists in the candidate task set but its location changes, then update the baseline positioning information to point to the current location of the baseline task; If the baseline task does not exist in the candidate task set, the baseline reselection process is triggered, and the baseline task identifier, baseline value, and baseline positioning information are redefined.

6. The index migration method as described in claim 1, characterized in that, Before outputting the updated logical index mapping and baseline positioning information, the following is also included: Verify whether the logical traversal order is consistent with the sorting and writing order; If the verification results are inconsistent, an audit alert will be output, and a rollback or rebuild process will be triggered.

7. The index migration method as described in claim 1, characterized in that, The updated logical index mapping and baseline positioning information output includes: The updated index results are visualized and then transmitted to downstream modules.

8. A scheduling index migration device, characterized in that, The index migration device includes: The event listening module is used to monitor events that change the state of the candidate task set; The context acquisition module is used to acquire migration context information in response to the detection of a current state change event; The strategy determination module is used to identify the event type of the current state change event and determine the corresponding index migration strategy based on the event type. The migration execution module is used to perform migration updates on the logical indexes and / or baseline locations of tasks in the candidate task set based on migration context information and index migration strategies. The view output module is used to output the updated logical index mapping and baseline positioning information.

9. An index migration device, characterized in that, The index migration device includes a processor, a memory, and an index migration program stored in the memory and executable by the processor, wherein when the index migration program is executed by the processor, it implements the steps of the index migration method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an index migration program, wherein when the index migration program is executed by a processor, it implements the steps of the index migration method as described in any one of claims 1 to 7.

Images