A warehouse resource scheduling optimization method and system based on big data analysis

Abstract

The application provides a warehouse resource scheduling optimization method and system based on big data analysis, relates to the technical field of warehouse resource scheduling optimization, and has the technical solution points that the platform receiving time and terminal recording time of an event record are acquired, and when the sequence of the two is inconsistent, whether it is caused by backhaul delay is judged in combination with the terminal type and backhaul behavior attribute, and if so, the state time sequence is reconstructed according to the terminal recording time, so that the time sequence dislocation caused by backhaul delay can be accurately identified, data out-of-order misjudgment as operation conflict is avoided, the accuracy of the location state information is improved, and the advantages of optimizing warehouse resource scheduling and improving resource utilization efficiency are achieved.

Description

Technical Field

[0001] This application relates to the field of warehouse resource scheduling optimization technology, and more specifically, to a warehouse resource scheduling optimization method and system based on big data analysis. Background Technology

[0002] In modern warehousing and logistics management, especially in scenarios with frequent concurrent operations such as replenishment, relocation, and new goods placement, big data analytics-based scheduling systems are widely used to dynamically generate storage location allocation strategies and continuously adjust storage location occupancy status and task priorities based on feedback from operation execution, thereby optimizing the scheduling of warehousing resources. In conventional processes, these systems collect and process storage location release event records corresponding to relocation operations and storage location occupancy event records corresponding to placement operations, updating the storage location availability model in real time to provide a data foundation for subsequent scheduling decisions.

[0003] In actual operations, storage space release and occupancy events are typically triggered and recorded by different types of work terminals within their respective business processes. For example... Figure 4 As shown, in the physical operation site recording terminal records, for storage location A, the forklift-mounted terminal automatically triggers upon completion of the storage transfer operation, generating a terminal record time T1, which is the actual release time; while the operator confirms the shelving operation via a handheld terminal, manually scanning the code and submitting, generating a terminal record time T2, which is the actual occupation time. At this point, T1 is less than T2, and the actual order is release first, then occupation. Due to differences in the communication network environment, data upload mechanism, and operator response habits used by different terminal devices, there may be varying degrees of inconsistent delays between the recording time of release and occupation events related to the same storage location on the terminal and the time the system platform receives the event. For example... Figure 4 As shown, the transmission delay of vehicle-mounted terminals via the communication network is relatively long, while that of handheld terminals is relatively short. Especially during peak operating periods, manual confirmation operations often experience delays in submission, and network congestion can also cause significant delays in uploading from some terminals.

[0004] Existing big data analytics-based warehouse scheduling systems typically handle these events by directly determining the order in which the platform receives the events, or simply relying on the timestamps recorded by the terminals. This lacks the ability to analyze and identify differences in the feedback behavior of different terminals. In the scheduling system platform and observation results, the platform's reception perspective shows that the platform's reception time t2' for the occupancy event is earlier than the platform's reception time t1' for the release event, meaning t2' is less than t1'. This results in the observation order being reversed, with occupancy preceding release. Due to the lack of an effective discrimination mechanism, the system cannot determine whether this inconsistency between the platform's reception order and the terminal's recording order is simply due to data misordering caused by terminal feedback delays, or due to actual operational conflicts. It cannot determine whether the misordering is caused by feedback delays.

[0005] This lack of discriminative ability makes the system highly susceptible to misclassifying timing misalignments caused by terminal feedback delays as issues such as warehouse location recommendation conflicts, operator violations, or untimely execution of warehouse transfer tasks. The system's incorrect conclusion of operational conflicts or violations results in erroneously lowering warehouse location scores, causing scheduling strategies to deviate from reality, and increasing costs. Based on such misjudgments, the scheduling system often incorrectly lowers the availability scores of relevant warehouse locations or areas during subsequent rescheduling evaluations and closed-loop iterations. This leads to subsequent warehouse location allocation strategies deliberately avoiding these actually available locations, instead allocating them to more distant or lower-priority locations, thereby increasing unnecessary cross-regional transport distances and operational costs. This not only reduces the actual utilization efficiency of warehousing resources but also causes warehouse location scheduling strategies to continuously deviate from the true physical state, even incorporating erroneous conclusions into historical analysis samples, further interfering with the optimization direction of the scheduling model and affecting the overall effectiveness of warehousing resource scheduling optimization.

[0006] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0007] The purpose of this application is to provide a method and system for optimizing warehouse resource scheduling based on big data analysis. This method and system can accurately identify the reversal of event sequence caused by terminal feedback delay, avoid misjudgment, improve the accuracy of warehouse location status determination, and optimize scheduling decisions.

[0008] This application provides a method for optimizing warehouse resource scheduling based on big data analysis, the technical solution of which is as follows: A warehouse resource scheduling optimization method based on big data analysis includes: Obtain the release event record and the occupation event record of the target storage location. The release event record and the occupation event record each contain their respective platform reception time and terminal recording time. When the platform receiving time of the release event record is later than the platform receiving time of the occupation event record, and the terminal recording time of the release event record is earlier than the terminal recording time of the occupation event record, obtain the terminal type and feedback behavior attributes associated with the release event record and the occupation event record respectively. Based on the terminal type and backhaul behavior attributes, determine whether the inconsistency between the platform's receiving time order and the terminal's recording time order is caused by terminal backhaul delay. If it is determined that the delay is caused by the terminal's backhaul, the status change sequence of the target storage location is reconstructed according to the order of the terminal's recorded times, and storage location status information is generated for scheduling decisions.

[0009] Furthermore, this application also proposes, after obtaining the release event record and the occupancy event record of the target storage location, and before the determination that the platform receiving time of the release event record is later than the platform receiving time of the occupancy event record and the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record, the following additional steps are included: Based on the connecting reference information used to characterize whether release event records and occupancy event records belong to the same storage location status change process, release event records and occupancy event records are divided into at least one event sub-chain, and one event sub-chain corresponds to one storage location status change process; Furthermore, the system determines whether the release event record and the occupancy event record satisfy the inconsistency condition between the platform's receiving time and the terminal's recording time only within the same event subchain. This technical solution further improves the accuracy of backhaul delay identification by limiting the scope of inconsistency judgment through event subchain division.

[0010] Furthermore, this application also proposes that the following reference information be included: The relationship between the previous defined state of the target storage location and the event type; The comparison results between the time intervals between event records and the duration threshold, which is determined based on the operational rhythm of the area where the target storage location is located; And the task identifier or operator continuity information in the event log; The division includes grouping event records into the same event subchain based on succession relationships, comparison results, and continuity information; Furthermore, the method also includes: Generate a confidence flag for each event subchain; the confidence flag represents the reliability of the partition. When determining inconsistency conditions, if the confidence flag of an event subchain is low confidence, the event records within that subchain will not be used for determining the inconsistency condition. This technical solution improves the reliability of determining the cause of the misordering by excluding low confidence judgments through confidence flags.

[0011] Furthermore, this application proposes steps for determining whether the discrepancy between the platform's received time sequence and the terminal's recorded time sequence is caused by a delay in terminal data transmission, including: Obtain the first difference, which is the time difference between the platform's receiving time and the terminal's recording time for the release event record; Obtain the second difference, which is the time difference between the platform receiving time and the terminal recording time that occupy the event record; Obtain the first delay statistical feature, which is used to characterize the backhaul delay statistical characteristics of the terminal that generated the release event record within a historical time period; Obtain the second delay statistical feature, which is used to characterize the backhaul delay statistical characteristics of the terminal that generated the occupancy event record within the historical time period; Based on the comparison results of the first difference and the first delay statistical feature, and the comparison results of the second difference and the second delay statistical feature, it is determined whether the inconsistency is caused by terminal backhaul delay. This technical solution utilizes time difference and delay statistical features for quantitative analysis, improving the accuracy of backhaul delay determination.

[0012] Furthermore, this application also proposes that, after determining whether the inconsistency between the platform's received time sequence and the terminal's recorded time sequence is caused by a terminal feedback delay, the following steps are also included: Based on the judgment results, the inconsistencies are classified as out-of-order due to terminal backhaul delay, actual operation conflict, or out-of-order pending confirmation. In response to inconsistencies being classified as misordering due to terminal backhaul delays, the steps are executed to reconstruct the state change sequence of the target storage location based on the order of the terminal recording times. In response to inconsistencies being classified as real job conflicts, a deviation alarm is generated to indicate scheduling execution conflicts; In response to inconsistencies being classified as out-of-order errors requiring confirmation, a confirmation flag is generated to indicate that the cause of the out-of-order error cannot be determined. This technical solution performs differentiated processing based on different types of inconsistencies, avoiding errors or missing information and improving system adaptability.

[0013] Furthermore, this application also proposes that, after classifying the inconsistency into out-of-order due to terminal backhaul delay, actual job conflict, or pending confirmation out-of-order based on the judgment result, and performing corresponding processing in response to the classification, it further includes: Get the status of the target storage location after classification and processing; Based on the classification results, the status credibility level of the target storage location is determined. When the classification result indicates that the out-of-order status is caused by terminal backhaul delay, the status credibility level is determined to be the first level. When the classification result is an unconfirmed misorder, the state credibility level is determined to be the second level, which represents a lower level of credibility than the first level. This method generates status information for target storage locations, carrying their status reliability levels, so that scheduling decisions can differentiate the use of target storage locations based on these reliability levels. This technical solution distinguishes storage location status by reliability levels, providing a more accurate reference for scheduling decisions.

[0014] Furthermore, this application also proposes that the scheduling decision includes: In response to a status trust level of Level 1, the target storage location will be used for storage location allocation; In response to a status trust level of Level 2, the target storage location is subject to restricted allocation, which includes at least one of the following: Lower the target storage location's ranking position in storage location matching; When a first-level allocable storage location exists, the target storage location is not selected for the current allocation. This technical solution allocates storage locations based on the status trust level, improving allocation efficiency and resource utilization.

[0015] Furthermore, this application proposes that, after classifying inconsistencies as out-of-order due to terminal return delays, actual job conflicts, or pending confirmation of out-of-order, it also includes: Event records classified as misordered due to terminal backhaul delays are excluded from the historical sample set used for scheduling error learning. This technical solution removes misordered events caused by backhaul delays from the learning samples, improving the accuracy of scheduling model training.

[0016] Furthermore, this application also proposes that, after generating the status information of the target storage location carrying the status confidence level, it also includes: Obtain the log of subsequent feedback events for the target storage location; Based on subsequent feedback event records, the reliability level of the target storage location is redefined so that it can be updated from level two to level one. This technical solution dynamically updates the reliability level through subsequent feedback, ensuring the timeliness and accuracy of the storage location status information.

[0017] In addition, this application also provides a warehouse resource scheduling optimization system based on big data analysis, the technical solution of which is as follows: A warehouse resource scheduling optimization system based on big data analytics includes: The event acquisition module is used to acquire the release event records and occupancy event records of the target storage location. The release event records and occupancy event records respectively contain the corresponding platform reception time and terminal recording time. The attribute acquisition module is used to acquire the terminal type and feedback behavior attributes associated with the release event record and the occupation event record respectively when the platform receiving time of the release event record is later than the platform receiving time of the occupation event record and the terminal recording time of the release event record is earlier than the terminal recording time of the occupation event record. The delay judgment module is used to determine whether the inconsistency between the platform's received time order and the terminal's recorded time order is caused by terminal back transmission delay, based on the terminal type and back transmission behavior attributes. The state reconstruction module, if determined to be caused by terminal feedback delay, reconstructs the state change sequence of the target storage location based on the chronological order of the terminal's recorded times, and generates storage location state information for scheduling decisions. This system implements the above method through a modular design, offering the same advantages.

[0018] As can be seen from the above, the warehouse resource scheduling optimization method and system based on big data analysis provided in this application obtains the platform receiving time and terminal recording time of the event record. When the order of the two is inconsistent, it combines the terminal type and backhaul behavior attributes to determine whether it is caused by backhaul delay. If so, it reconstructs the state time sequence according to the terminal recording time, thereby accurately identifying the time sequence misalignment caused by backhaul delay, avoiding misjudging data misorder as operation conflict, improving the accuracy of warehouse location status information, and having the advantages of optimizing warehouse resource scheduling and improving resource utilization efficiency. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the warehouse resource scheduling optimization method provided in an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the overall operation process of the warehouse resource scheduling optimization method based on big data analysis in this application embodiment.

[0021] Figure 3 This is a schematic diagram of the branch process for handling time inconsistency classification in this application embodiment.

[0022] Figure 4 This diagram illustrates the scheduling problem caused by disordered event recording timing in existing technologies. Detailed Implementation

[0023] The following description, in conjunction with the technical solution of this application, provides a clearer and more complete explanation of the relevant content. It should be noted that the embodiments described herein are only a part of the implementation methods of this application, and not all of them. Other implementation methods obtained by those skilled in the art based on the embodiments of this application without creative effort should also fall within the protection scope of this application. Furthermore, in the description of this application, the terms "first," "second," etc., are mainly for distinction and should not be construed as indicating relative importance.

[0024] Reference Figure 1 This application proposes: S1. Obtain the release event record and the occupation event record of the target storage location. The release event record and the occupation event record each contain the corresponding platform receiving time and terminal recording time.

[0025] S2. When the platform receiving time of the release event record is later than the platform receiving time of the occupation event record, and the terminal recording time of the release event record is earlier than the terminal recording time of the occupation event record, obtain the terminal type and return behavior attributes associated with the release event record and the occupation event record respectively.

[0026] S3. Based on the terminal type and backhaul behavior attributes, determine whether the inconsistency between the platform's receiving time order and the terminal's recording time order is caused by terminal backhaul delay.

[0027] S4. If it is determined that the delay is caused by the terminal's backhaul, the status change sequence of the target storage location is reconstructed according to the order of the terminal's recorded time, and storage location status information is generated for scheduling decisions.

[0028] In the daily operation of a warehouse, tasks such as transferring goods, placing new goods on shelves, and emergency replenishment often occur simultaneously. During a transfer, a forklift moves goods from storage location A to location B, freeing up storage location A. This release action is automatically detected by the onboard terminal of the forklift and generates a release event record. During shelf placement, workers place newly arrived goods into the newly vacated storage location and scan the location code with a barcode scanner to confirm occupancy. This occupancy action generates an occupancy event record. These two records are crucial for the subsequent big data analysis and scheduling system, as the system relies on them to determine which storage locations are empty and which are full, thus enabling it to allocate the next batch of goods accordingly.

[0029] However, there's a significant problem here. Forklift terminals are automatic sensors; almost immediately after an operation is completed, they send out the release record via the network—it's a real-time upload. The barcode scanners used by workers are more complex. Sometimes, to save time, workers scan the barcode and complete the task, but the scanner doesn't necessarily transmit the record immediately. This could be due to poor signal, the scanner being set to accumulate several records before sending them all at once, or the worker forgetting to confirm and submit, causing the record to remain in the scanner for a while before being transmitted to the platform. This results in a situation where, although the storage space is cleared before new goods are placed on-site, the big data analytics system might receive the occupancy event record first, followed by the release event record.

[0030] This reversal of reception time has a significant impact on the scheduling system. Conventional processing logic assumes that the first received record is the first event. If the system sees a storage location occupied before being released, it will assume there's a problem with that location. It might think a mistake was made during location recommendation, suggesting a used location as empty, or that a worker violated regulations by occupying a location they shouldn't. With this misjudgment, the scheduling system will deliberately avoid using that location when it should be, prioritizing locations in other areas. As a result, goods are moved further away, transport paths become longer, and overall operational efficiency decreases.

[0031] In response, the proposed solution is to proactively detect discrepancies between the receiving time and the actual on-site time, identify the causes of these discrepancies, and then update the storage location status information according to the actual time sequence, ensuring that subsequent scheduling decisions are based on the correct information.

[0032] Specifically, each event record obtained in step S1, besides the readily apparent location number, task number, and event type (release or occupation), also includes several key time and source information. The terminal-recorded time is the actual moment the event occurred at the work site; for a release event, it's the instant the forklift senses it, and for an occupation event, it's the instant the worker scans the code. This time is automatically entered by the terminal. The platform's received time is the timestamp added by the backend server when the record is transmitted over the network to the big data analysis system's backend. These two timestamps together provide the most direct evidence for later determining whether the order has been disrupted by network transmission.

[0033] Next, in step S2, when the system processes a pair of release and occupancy events for the same storage location, it considers the time sequence of two dimensions. One dimension is the platform receiving time; if the occupancy record arrives at the platform before the release record, it appears to be occupancy followed by release. The other dimension is the terminal recording time; if the release record actually occurs earlier than the occupancy record, the actual situation should be release followed by occupancy. When the ordering results of these two dimensions are exactly opposite, it means that the data has been distorted at some point. This pair of events is marked as candidates for further analysis, and deeper information is extracted, namely, the terminal type and feedback behavior attributes. The terminal type indicates whether the record came from the forklift's onboard terminal or from a worker's handheld barcode scanner. The feedback behavior attributes describe some characteristics of this data upload, such as whether it was sent as a single record in real time or packaged with other records for batch sending, and whether there was a significant pause between scanning and final submission.

[0034] With this information, we proceed to step S3, which involves a judgment process. The core idea of ​​this judgment is to compare the transmission time of each of the two events from their formation at the scene to their reception by the platform, and to combine the terminal type, transmission behavior attributes, and the historical delay statistics of the corresponding terminal to determine whether there is an abnormal transmission delay that could cause the platform to receive the order in reverse.

[0035] For example, for a release event, the platform's receiving time can be subtracted from the terminal's recording time to obtain the transmission time for this release event; for an occupation event, the same method can be used to calculate the transmission time for this occupation event. However, a single time difference cannot directly explain the problem, because different terminal types, different network environments, and different upload methods have different normal transmission time ranges.

[0036] Therefore, it is also necessary to query the historical transmission delay statistics of the terminals that generated the release event records and the occupancy event records, such as average upload time, latency fluctuation range, maximum latency duration, and frequency of batch uploads. In the time inconsistency scenario defined in this implementation, if the transmission time of the release event significantly exceeds the historical normal latency range of its corresponding terminal, while the transmission time of the occupancy event is within the normal range of its corresponding terminal, or if the release event has a significantly larger abnormal transmission delay than the occupancy event, and the transmission behavior attributes of the release event show characteristics such as batch upload, offline caching, and centralized retransmission after network interruption, then it can be determined that the inconsistency between the platform's receiving time order and the terminal's recorded time order is mainly caused by the terminal transmission delay of the release event records.

[0037] If the return time of two events is within their respective historical normal range, or if the delay statistics and return behavior attributes do not both point to an abnormal return delay of a certain event record, then it is not appropriate to directly conclude that the inconsistency is caused by terminal return delay. Instead, it should proceed to the subsequent judgment of actual operation conflict or pending confirmation of misorder.

[0038] If, after the above judgment, it is confirmed that the reversal of the platform's receiving time is caused by the delay in the terminal's return of the event record, rather than an abnormal operation of occupying and then releasing actually occurring on-site, then proceed to step S4. In this step, the state change sequence of the target storage location is reconstructed according to the order of the terminal's recorded times.

[0039] Specifically, if the terminal recording time of the release event is earlier than the terminal recording time of the occupancy event, the actual state change process of the target storage location will be reconstructed as first changing from an occupied state to an available state, and then from an available state back to an occupied state. When generating new storage location status information based on this state change sequence, the start and end times corresponding to each state, the current state, and the misorder correction mark can be recorded in the storage location status information.

[0040] Therefore, scheduling decisions can determine whether a target storage location is available at a specific scheduling moment based on the timeline of the reconstructed state changes: during the period between the release event and the occupancy event, the target storage location can participate in scheduling as an available storage location; after the occupancy event, the target storage location should be identified as occupied and no longer considered a currently allocable storage location. This process avoids erroneous changes to storage location status judgments due to simple data backhaul delays, allowing storage location scheduling strategies to more accurately align with the actual operational situation of the warehouse.

[0041] After obtaining the release event records and occupancy event records of the target storage location, and before determining whether the platform receiving time of the release event record is later than the platform receiving time of the occupancy event record and whether the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record, the splitting of event subchains can be introduced. In actual warehousing scenarios with high-frequency warehouse transfers and concurrent put-aways, the same target storage location often undergoes multiple independent state changes within a very short time window. For example, it may complete a warehouse transfer release, be immediately occupied by a new task, and then be released again.

[0042] If events are retrieved solely based on storage location identifiers and fixed time windows, the resulting sets of release and occupancy event records are highly susceptible to mixing multiple change records belonging to different work chains. If these mixed records are then arbitrarily paired and time inconsistency checks are performed, it's easy to incorrectly associate a release event from a previous work chain with an occupancy event from a subsequent work chain, creating a false positive in the data representation. This observational illusion caused by cross-work chain mixing severely interferes with the accurate identification of the source of delays.

[0043] In response, this application proposes to divide release event records and occupancy event records into at least one event sub-chain based on the connecting reference information used to characterize whether release event records and occupancy event records belong to the same storage location status change process, with one event sub-chain corresponding to one storage location status change process; and to determine whether release event records and occupancy event records meet the condition of inconsistency between platform receiving time and terminal recording time only within the same event sub-chain.

[0044] Specifically, the succession reference information reflects whether there is a genuine sequential relationship between release event records and occupancy event records at the physical operation level. In practical applications, this type of reference information can cover multiple dimensions of data, such as the degree of fit between the previous defined state of the target storage location before the event occurred and the current event type, the reasonableness of the interval between the local recording times of adjacent events, the continuity of task identifiers, and the coherence of operators or operating equipment in the work chain. By integrating data from these dimensions, the event set that was originally stacked flatly by storage location can be reorganized into event sub-chains arranged according to the operation succession relationship. Each event sub-chain physically corresponds to only one local state change process of the target storage location, such as from occupied to available, or from available to occupied.

[0045] It's worth noting that the core purpose of dividing event records into event subchains is to define a more precise scope for subsequent time inconsistency judgments. After the subchains are split, the actions to determine the discrepancy between the platform's received time and the terminal's recorded time will be strictly limited to release event records and occupy event records within the same event subchain. In other words, records belonging to different event subchains will not be forcibly paired for timestamp comparison. This shift in processing significantly narrows the candidate objects for subsequent out-of-order judgments from arbitrary pairings of all events in the same database location to specific pairings within the same subchain.

[0046] This mechanism of first breaking down the chain and then pairing it effectively eliminates the root cause of mispairing across work chains. When a discrepancy is subsequently detected between the platform's received time and the terminal's recorded time, this discrepancy is more likely to reflect a real delay in terminal feedback from the same storage location change process, avoiding the illusion caused by the incorrect piecing together of events from different change processes. This not only helps improve the accuracy of out-of-order identification and delay source location, preventing normal multi-round continuous operations from being misjudged as scheduling conflicts, but also prevents the storage location status timeline from being incorrectly repaired, thereby ensuring the reliability of subsequent scheduling and allocation strategies and the purity of the historical analysis sample database.

[0047] Furthermore, in some preferred embodiments, the reference information includes: the connection relationship between the previous defined state of the target storage location and the event type; the comparison result of the time interval between event records and the duration threshold, the duration threshold being determined according to the operational rhythm of the area where the target storage location is located; and the task identifier or operator continuity information of the event records; the division includes grouping event records into the same event sub-chain based on the connection relationship, comparison result, and continuity information; and the method further includes: generating a confidence marker for each event sub-chain, the confidence marker representing the reliability of the division; when determining inconsistency conditions, if the confidence marker of an event sub-chain is low confidence, then the event records in that event sub-chain are not used for determining inconsistency conditions.

[0048] In high-frequency warehousing operations, the same storage location may undergo multiple release and occupancy transitions within a very short period. For example, a forklift might release a storage location after completing a move, only for another batch of goods to be placed on the shelf and occupy that location, followed by another release and occupancy. If all events within a fixed time window are grouped into a single candidate event group, multiple independent operation chains will be mixed within that window. In this case, directly extracting and pairing events can easily lead to the forced combination of a release event from the first operation chain with an occupancy event from the second, creating a false temporal misalignment on the timeline. This incorrect pairing across chains can directly mislead the identification of subsequent delay sources, causing what should be normal continuous operations to be misjudged as backhaul delays or genuine conflicts.

[0049] To address this, this application proposes a multi-dimensional reference information approach to decompose mixed events within a window into sub-chains. Specifically, the reference information includes constraints in three dimensions. The first dimension is the relationship between the previous defined state of the target storage location and the event type. During the judgment, the final physical state of the storage location before entering the current time window is obtained. If the previous defined state was occupied, then the first event accepted in the current window should be a release event; if the previous defined state was available, then the first event accepted should be an occupied event. Through this logical verification of state transitions, a reasonable starting point can be determined for the event sub-chain, avoiding the forced grouping of events with conflicting types into the same chain.

[0050] The second dimension is the comparison between the time interval between event records and the duration threshold. This duration threshold is dynamically determined based on the actual operational rhythm of the target storage location's region. In practice, data on the time intervals from release to re-occupancy of similar storage locations in the region during recent historical cycles can be obtained from a regional statistical database. The median of these data is calculated as a benchmark, and a preset fluctuation range is overlaid to obtain the current duration threshold. During the splitting process, the time interval between adjacent events is calculated. Only when this interval falls within the allowable range of the duration threshold are the two events considered to have a temporal contiguous connection. This dynamic threshold based on the actual operational rhythm of the region effectively prevents two independent tasks with a long time gap from being mistakenly included in the current sub-chain.

[0051] The third dimension is the task identifier or operator continuity information recorded in the event log. During the splitting process, the task number, batch source number, and operator or equipment identifier carried by the event are extracted. If two events have the same task identifier, or if the upstream and downstream records of the operator and equipment can form a continuous work trajectory, they are preferentially grouped into the same event sub-chain. This verification based on business logic and personnel and equipment continuity further consolidates the true correlation between events within the sub-chain.

[0052] After grouping event records into the same event subchain by comprehensively considering the above-mentioned succession relationships, comparison results, and continuity information, a confidence marker is generated for each event subchain to characterize the reliability of this partitioning. The generation of confidence markers depends on the satisfaction of the above three-dimensional constraints. When the state succession is seamless, the time interval is reasonable, and the continuity of tasks or personnel / equipment is clear, the subchain can be marked as high confidence; when the state succession is reasonable but the time interval slightly exceeds the threshold, or there is partial missing task continuity information, it can be marked as medium confidence; and when there is a significant conflict between the event type and the previous state, key time fields are missing, or there are multiple competing succession candidates, it is marked as low confidence.

[0053] In one specific implementation, if the target storage location's previous state is "occupied," and the current event subchain consists of one release record and one occupancy record, with a 30-second time interval between the two records (consistent with the normal operational rhythm of the area), and the task source numbers associated with the two records are identical, then the subchain is marked as high confidence. If the time interval between these two records reaches 5 minutes, slightly exceeding the area's usual 2-minute duration threshold, but the state transition is still reasonable, then the subchain is marked as medium confidence. If the target storage location's previous state is "available," but the first record in the current event subchain is a release record, indicating a clear conflict between the event type and the previous state, then the subchain is marked as low confidence.

[0054] It is worth noting that when determining inconsistency conditions, if the confidence marker of a certain event subchain is identified as low confidence, the event records within that subchain will not be used to determine the inconsistency condition. This exclusion mechanism is implemented because the event succession relationships within low-confidence subchains are highly uncertain. Forcibly including them in out-of-order analysis could easily lead to false positives, thereby contaminating subsequent delay source localization and the historical sample database.

[0055] By actively isolating low-confidence subchains, it can be ensured that subsequent out-of-order identification focuses on genuine and reliable single state change processes. Excluded low-confidence subchains can be temporarily stored in a suspended event set with an observation period. If subsequent supplementary events are received within the observation period, clarifying the relationship, the confidence level can be reassessed and the analysis process resumed. If closure fails after the timeout, a low-confidence state indicating an unclosed local change chain is output, thus reliably handling boundary anomalies without constructing false conflicts.

[0056] Furthermore, in some preferred methods, the step of determining whether the inconsistency between the platform's receiving time sequence and the terminal's recording time sequence is caused by terminal backhaul delay includes: obtaining a first difference, which is the time difference between the platform's receiving time and the terminal's recording time for the release event record; obtaining a second difference, which is the time difference between the platform's receiving time and the terminal's recording time for the occupancy event record; obtaining a first delay statistical feature, which characterizes the backhaul delay statistical characteristics of the terminal that generated the release event record within a historical time period; obtaining a second delay statistical feature, which characterizes the backhaul delay statistical characteristics of the terminal that generated the occupancy event record within a historical time period; and determining whether the inconsistency is caused by terminal backhaul delay based on the comparison results of the first difference and the first delay statistical feature, and the comparison results of the second difference and the second delay statistical feature.

[0057] After confirming a discrepancy between the platform's received time and the terminal's recorded time, further processing can be performed to determine whether the discrepancy is indeed caused by the terminal's backhaul delay. When a discrepancy is found between the platform's received time and the terminal's recorded time for release and occupancy events, it is necessary to determine whether the discrepancy is caused by the terminal's backhaul delay or by actual operational conflicts. Since it is difficult to reliably distinguish based solely on terminal type, a location method based on time difference and historical delay statistical characteristics is introduced.

[0058] Specifically, obtaining the first and second differences involves calculating the actual transmission time from the occurrence of each event at the terminal to its reception by the platform. The first difference reflects the actual transmission delay of the release event, and the second difference reflects the actual transmission delay of the occupancy event.

[0059] When obtaining the first and second latency statistical characteristics, the historical transmission latency data of the terminal that generated the corresponding event can be queried from the terminal behavior statistics database. Historical transmission latency statistical characteristics can be represented as the average, median, maximum latency duration, standard deviation, or latency fluctuation range of the difference between the platform reception time and the terminal recording time for all event records of the terminal within a recent period. These statistical characteristics constitute the baseline of the corresponding terminal's transmission behavior under normal operation. During operation, the terminal's local recording time and platform reception time for each received event record can be continuously recorded, and historical latency statistical characteristics can be periodically calculated and updated at the terminal level for real-time judgment and querying.

[0060] When making judgments based on comparison results, the first difference can be compared with the first delay statistical feature, and the second difference can be compared with the second delay statistical feature. For example, when the first difference exceeds the normal delay range characterized by the first delay statistical feature, while the second difference falls within the normal fluctuation range of the second delay statistical feature, it can be determined that the inconsistency is mainly caused by the return delay of the terminal that generated the release event record. Conversely, if the second difference deviates from the normal range while the first difference is normal, it can be determined that it is caused by the terminal that generated the occupancy event record. In addition to difference comparison, the upload method identifier of the event can also be obtained. When it is determined that the difference of the event is abnormal and the upload method is batch upload, the confidence of the delay source judgment can be further strengthened.

[0061] Through the above comparison, the processing status changed from "detected inconsistency in time sequence" to "determined that the inconsistency is caused by either the return delay of the releasing terminal or the return delay of the occupying terminal." This statistical difference analysis method allows the judgment to move beyond simple qualitative information and instead use quantifiable delay characteristics for source identification, helping to reduce the possibility of misjudging actual operational conflicts as return delays or vice versa. Therefore, subsequent scheduling decisions and model learning can be based on accurate determination of the cause of the misordering, enabling warehouse resource scheduling optimization to better reflect the actual physical inventory status. The judgment results can be used in subsequent steps to determine whether to correct the storage location status.

[0062] In actual warehousing operations, forklift drivers automatically trigger warehouse transfers via onboard terminals, while warehouse workers manually scan barcodes to confirm shelf occupancy via handheld terminals. After determining whether a time discrepancy is caused by a data transmission delay, relying solely on a binary yes / no result may present several risks. For example, if the discrepancy is not due to a delay but rather to warehouse workers scanning barcodes prematurely to secure a storage space, the actual operational conflict might be forcibly corrected, thus masking on-site scheduling irregularities. Furthermore, when there is uncertainty in delay assessment, blindly choosing a processing direction without a reasonable buffer mechanism can easily introduce incorrect storage space statuses. Therefore, this application proposes a further categorized processing mechanism.

[0063] Reference Figure 3After determining whether the inconsistency between the platform's received time sequence and the terminal's recorded time sequence is caused by terminal backhaul delay, the method further includes: classifying the inconsistency into misordering caused by terminal backhaul delay, actual job conflict, or unconfirmed misordering based on the determination result; in response to the inconsistency being classified as misordering caused by terminal backhaul delay, performing the step of reconstructing the state change sequence of the target storage location based on the order of the terminal's recorded time; in response to the inconsistency being classified as actual job conflict, generating a deviation alarm to indicate scheduling execution conflict; and in response to the inconsistency being classified as unconfirmed misordering, generating an unconfirmed flag to indicate that the cause of the misordering cannot be determined.

[0064] Specifically, the above classification process can categorize time discrepancies into three different types of situations based on the clarity and directionality of the judgment results. This classification is necessary because in real-world scenarios involving high-frequency data transfers and concurrent data uploads, the factors causing timestamp misalignments are often complex, and a single delay judgment cannot cover all on-site situations.

[0065] When the judgment result clearly points to a backhaul delay of a certain terminal, the inconsistency can be classified as misordering caused by terminal backhaul delay. In this case, the step of reconstructing the state change timeline of the target storage location based on the chronological order of the terminal's recorded times can be performed. Through this reconstruction, the storage location's state timeline can be corrected from an incorrect reception order to a correct state chain reflecting the physical order, so that subsequent scheduling is no longer misled by the backhaul order.

[0066] When the judgment result clearly indicates that the problem is not caused by a return delay, and the correspondence between the terminal's local recording time and the platform's receiving time, as well as the storage location status logic, can determine that there is an operation that violates the normal release and occupancy order, the inconsistency can be classified as a real operation conflict.

[0067] For example, if the latency difference is normal but there is a conflict in the storage location status logic, such as the previous status being occupied but an occupation event being received, and the terminal's local time being later than the release event, it can be determined as a real job conflict. In this case, instead of forcibly changing the storage location status sequence, a deviation alarm can be generated to indicate a scheduling execution conflict. This deviation alarm can include conflict event pair information, the storage locations involved, timestamp relationships, and operator or equipment numbers, making it easier for schedulers or subsequent verification processes to identify job-level violations or conflicts and avoid masking the real problem.

[0068] When inconsistencies arise in latency difference comparisons, upload method identifiers, or cross-validation of regional events, or when key information is missing, making reliable determination impossible, inconsistencies can be categorized as pending confirmation of out-of-order status. For example, this can be categorized when multiple pieces of evidence contradict each other or when the terminal's local time is severely lacking. In this case, a pending confirmation flag can be generated to indicate that the cause of the out-of-order status cannot be determined. This pending confirmation flag can be attached to the corresponding storage location status record, changing the storage location from a normal state to a suspended pending confirmation state, preventing it from being directly used as a reliable state for automatic allocation recommendations. It is worth noting that this pending confirmation flag is not a permanent state; it can be re-evaluated with the arrival of new events and can be cleared or upgraded to a clear classification in subsequent processes, thus preserving the possibility of clarification through subsequent feedback.

[0069] Through the above classification and processing, we can accurately respond to different types of out-of-order events, repair recoverable delayed out-of-order events, alert to real conflicts requiring attention, and isolate uncertain out-of-order events awaiting confirmation. This approach helps to reduce the interference of data out-of-order and unidentified conflicts in overall scheduling decisions, avoid erroneous handling of non-delayed situations, and thus improve the accuracy and robustness of warehouse location status information.

[0070] After classifying the inconsistent timestamps and reconstructing or marking the corresponding states, the states of different target storage locations differ in their degree of certainty. If these states with different degrees of certainty are passed directly to the subsequent scheduling process without distinction, the scheduling process may treat the uncertain states as reliable states and allocate them, thus leading to incorrect storage location allocation decisions.

[0071] Furthermore, in some preferred methods, after classifying the inconsistency into misordering caused by terminal backhaul delay, actual job conflict, or misordering pending confirmation based on the judgment result, and performing corresponding processing in response to the classification, the method further includes: obtaining the status of the target storage location after classification processing; determining the status credibility level of the target storage location based on the classification result, wherein when the classification result is misordering caused by terminal backhaul delay, the status credibility level is determined to be the first level; when the classification result is misordering pending confirmation, the status credibility level is determined to be the second level, the second level representing a lower level of credibility than the first level; generating status information of the target storage location carrying the status credibility level, so that the scheduling decision distinguishes the use of the target storage location based on the status credibility level.

[0072] When the classification result indicates that the misordering is caused by the terminal backhaul delay, it means that the source of the misordering has been identified and the state reconstruction has been completed according to the terminal recording time. At this time, the state of the target storage location can accurately reflect the real change sequence of the physical site. Therefore, its state credibility level is determined as the first level, which represents a high degree of credibility.

[0073] When the classification result is "Unconfirmed Out-of-Order," it indicates that the source of the delay is difficult to uniquely determine or that the evidence is contradictory, and the true physical state of the target storage location remains highly uncertain. Therefore, its status credibility level is determined to be Level 2, representing a lower level of credibility. For cases classified as genuine operational conflicts, since they reflect conflicts or violations at the operational execution level rather than data backordering that can be directly reconstructed and corrected through time sequence, the target storage location should not be output to the automatic scheduling process as a normally allocable storage location until the conflict is resolved or the status is clarified. Instead, the target storage location should be marked as conflict-locked and stored in association with deviation alarms. Once the physical state of the target storage location is clarified by manual review, subsequent feedback event records, or supplementary event chains, its status credibility level is determined to be either Level 1 or Level 2 based on the clarification results.

[0074] Through this process, the terminal feedback delay causes three types of processing results: out-of-order, unconfirmed out-of-order, and real job conflict, respectively, which are state reconstruction, restricted use, and conflict locking. This avoids mistaking real job conflicts as ordinary out-of-order events that can be directly corrected and entering the scheduling allocation.

[0075] It's important to note that situations categorized as genuine operational conflicts differ from those caused by terminal feedback delays or pending confirmation of out-of-order data. Terminal feedback delays result in an abnormal data feedback sequence, which can be reconstructed by recording the time on the terminal once the cause is identified. Pending confirmation of out-of-order data refers to data anomalies with unclear causes, which can be addressed by lowering the status trust level for restricted use. Genuine operational conflicts, however, reflect conflicts or violations at the on-site operational execution level, and are not simply out-of-order data feedback that can be corrected by adjusting the event time sequence.

[0076] Therefore, in one implementation, when an inconsistency is classified as a genuine operational conflict, a deviation alarm can be generated, and the target storage location can be marked as conflict-locked. Until the conflict is resolved, manual review is completed, or subsequent feedback event records clarify the physical status of the target storage location, that location will not be used as the current automatic allocation target. In this case, the genuine operational conflict branch may not be directly assigned a first or second level, but rather the conflict-locked status will be passed to the scheduling decision-making stage, causing the scheduling decision to exclude the target storage location or await review results. After the conflict is resolved or the status is clarified, the credibility level of the clarified storage location status will be determined as either first or second level.

[0077] After determining the trust level or conflict resolution status, this is written as an additional attribute into the status information of the target storage location. Specifically, in the data record containing the storage location identifier, current status, and status change time, an additional field is added to record the trust level or conflict resolution status. The value of this field can correspond to the first level, the second level, or the conflict lock status.

[0078] In this way, the status information of the target storage location changes from containing only internal processing results to structured information carrying external reliability or conflict markers. After this structured status information is transmitted to the scheduling process, the scheduling process can directly perceive the reliability of different storage location statuses and whether there are operational conflicts, and then adopt differentiated usage strategies.

[0079] For example, for first-tier target storage locations, they can be included in the available storage location allocation pool for matching calculations when their current status is available. For second-tier target storage locations, a penalty coefficient can be added to the matching calculation to lower their recommended priority, or they can be temporarily excluded from the current batch of allocations and added to the list awaiting review. For target storage locations marked as conflict-locked, they will not be used as current automatic allocation objects until the conflict is resolved or the status is clarified. This differentiated usage mechanism based on trust level and conflict status helps avoid blindly using unreliable or conflicting storage location statuses during scheduling, thereby reducing cross-regional handling and invalid storage transfers caused by data uncertainty or real operational conflicts, and improving the accuracy and robustness of warehouse resource scheduling in high-frequency concurrency scenarios.

[0080] Furthermore, in some priority modes, the scheduling decision includes: in response to a state confidence level of Level 1, using the target storage location for storage location allocation; in response to a state confidence level of Level 2, performing restricted allocation on the target storage location, the restricted allocation including at least one of the following: reducing the ranking position of the target storage location in storage location matching; and not selecting the target storage location as the current allocation target when there is an allocable storage location of Level 1.

[0081] In high-frequency concurrent warehouse operations, forklift drivers rely on onboard terminals to receive storage location allocation instructions and proceed to designated locations to perform shelving or relocation actions. If, after receiving storage location status information with a status reliability level, second-level storage locations with uncertain status are still treated the same as first-level storage locations with clear status and directly allocated, it can easily lead to forklifts arriving at the site to find that the storage location is actually occupied or its status is unclear, thus causing cross-area handling and disrupting the overall operational rhythm. To address this, by translating the status reliability level into specific allocation behavior constraints, the allocation result can be kept consistent with the actual physical status of the storage location.

[0082] Specifically, when the status credibility level is level one, it indicates that the status of the target storage location has been clearly repaired or the source is clear. At this time, the target storage location is directly included in the available storage location allocation pool, so that it can participate in the storage location matching calculation, and no restrictions are imposed on it during the allocation process.

[0083] When the status credibility level is level two, it indicates that there is an unconfirmed out-of-order event at the target storage location, and the true status is uncertain. In this case, restricted allocation is performed on the target storage location. Restricted allocation can be achieved by lowering the ranking position of the target storage location in storage location matching. When calculating the storage location matching score, a penalty factor less than 1 can be introduced, calculated according to the formula: Final Score = Original Matching Score * Penalty Factor, to obtain the adjusted final score.

[0084] By adjusting the score accordingly, the second-tier storage locations will be moved to the back of the generated candidate storage location ranking list, ensuring that the scheduling process prioritizes the higher-scoring first-tier storage locations under the same conditions. Furthermore, restricted allocation can also be achieved by not selecting the target storage location as the current allocation target when a first-tier allocable storage location exists. When generating the candidate storage location list for the current batch, all storage locations with a status confidence level of first-tier can be selected first.

[0085] If the number of first-level storage locations selected already meets the allocation requirements of the current batch of tasks, then second-level storage locations are directly removed from the candidate set and will not be considered for current allocation. Only when the number of first-level storage locations is insufficient to meet the allocation requirements will second-level storage locations be included in the candidate set, and the aforementioned demotion sorting logic will be applied.

[0086] For example, suppose the current batch of tasks requires the allocation of 5 target storage locations. The system initially filters out 8 first-level storage locations and 3 second-level storage locations. Since the 8 first-level storage locations already meet the allocation requirement of 5, the system directly removes these 3 second-level storage locations from the candidate set. If the current batch of tasks requires the allocation of 10 target storage locations, but there are only 8 first-level storage locations, which is insufficient to meet the requirement, the system will include these 3 second-level storage locations in the candidate set and multiply their original matching scores by a penalty factor of 0.8, so that they are ranked after the first-level storage locations in the final candidate storage location ranking list, thus participating in the allocation as a fallback option.

[0087] This tiered allocation strategy prioritizes the utilization of highly reliable storage locations, reducing subsequent relocation corrections caused by incorrectly occupied storage locations with uncertain status. Simultaneously, reserving second-tier storage locations as a backup option helps maintain task flow and prevent operational halts when first-tier storage locations are exhausted during peak periods.

[0088] In high-frequency warehouse operations involving both transfers and shelving, if only the out-of-order issues caused by data transmission delays are identified and corrected at the moment, without distinguishing historical learning samples, these event records identified as data transmission delays will still be entered into the historical sample database as apparent anomalies. During subsequent bias learning by the scheduling model, the model may mistakenly identify these apparent anomalies—where occupancy precedes release due to data transmission lag—as errors in the storage location allocation strategy itself. As the closed-loop iteration continues, the model will gradually learn data transmission delay features as scheduling error patterns, thereby incorrectly lowering the availability score of the relevant storage locations or areas. This distorted score can easily lead to subsequent allocations deliberately avoiding actually available areas, increasing unnecessary cross-area handling, causing the scheduling strategy to continuously deviate from the true physical state, and placing additional burdens on on-site operations.

[0089] Furthermore, in some preferred approaches, after classifying inconsistencies as misordering due to terminal backhaul delays, actual job conflicts, or pending misordering, the approach also includes: at least excluding event records classified as misordering due to terminal backhaul delays from the historical sample set used for scheduling error learning.

[0090] It is worth noting that the historical sample set used for scheduling error learning is specifically designed to provide training data for the scheduling model's bias learning and parameter updates, and differs from ordinary job event log storage. Ordinary job logs are mainly used for post-event review, while the composition of this historical sample set directly determines the direction of model parameter updates. Therefore, when writing event records and their processing conclusions back to the historical database, it is necessary to implement differentiated control over the classification results.

[0091] Specifically, during the write phase, event records classified as out-of-order due to terminal return delays can be marked with a delay pollution tag, or they can be directly isolated and written to the non-error sample partition. When the scheduling model prepares training data later, training data is extracted only from real job conflict samples based on the added delay pollution tag or storage partition. In this way, out-of-order samples caused by return delays can be effectively excluded from the training set.

[0092] Through the aforementioned differentiated sample control, the internal composition of the historical sample set used for scheduling error learning changes, and the training sample set no longer contains out-of-order samples caused by backhaul delays. This helps to learn biases based solely on real job conflicts during closed-loop iteration, avoiding contamination by backhaul anomalies in the data link. Therefore, even in long-term scenarios with asynchronous backhaul from multiple terminals, the storage location availability score remains accurate, and the storage location allocation strategy maintains a high degree of consistency with the actual physical state. This extends the effectiveness of a single misorder correction to the long-term learning loop, preventing the repeated accumulation of error feedback during model iteration.

[0093] In warehousing operations involving high-frequency transfers and concurrent shelving, when a target storage location's reliability level is temporarily set to Level 2 (representing a lower reliability) due to unclear initial feedback or missing key events, the scheduling module typically restricts its use or lowers its allocation priority. However, as on-site operations continue, new operational feedback often emerges in the area where the location is located. If this new feedback clarifies previous timing discrepancies or fills in missing information, but the reliability level fails to dynamically improve, physically available storage locations become idle for extended periods. This increases unnecessary cross-regional transport burdens, leading to wasted warehousing resources and a rigid allocation strategy.

[0094] In response, this application proposes to obtain subsequent feedback event records for the target storage location after generating the status information of the target storage location carrying the status credibility level, and to redetermine the status credibility level of the target storage location based on the subsequent feedback event records, so that the status credibility level can be updated from the second level to the first level.

[0095] Specifically, when one or more new follow-up feedback event records for the target storage location are obtained, key fields such as the terminal local recording time, platform receiving time, event type, and upload method can be extracted from these records. For example, if the follow-up feedback event records show that the storage location has undergone a normal transfer and release, and the difference between its terminal recording time and platform receiving time is within the normal range of the terminal's history, and the timestamps of other related events in the same area can also confirm that the order of the storage location's status changes is reasonable, it can be determined that the timing conflict or ambiguity that previously led to a reduction in the trust level has been clarified.

[0096] Based on this, the reliability level of the target storage location can be updated from level two to level one, and the reliability flag in the storage location status record can be updated simultaneously, restoring the storage location to a highly reliable and available state for normal allocation. This dynamic correction mechanism helps avoid long-term resource idleness caused by incomplete data in a single instance, making the status based on scheduling decisions closer to the dynamic changes in the physical site.

[0097] In a further implementation, a fallback mechanism can be set up to handle extreme anomalies during the feedback correction process. For example, if the same storage location experiences multiple unconfirmed misorders within a short period that cannot be automatically clarified by subsequent feedback, an anomaly alarm can be triggered, prompting manual intervention to verify the clock and operation process of the storage location or the corresponding terminal. The manual confirmation result can be used as the basis for correction, and the status can be corrected in one go and recorded in the historical samples. In addition, if it is found that the local time of an event is severely missing or obviously incorrect, such as the recording time being much earlier than the creation time of all related tasks, this event can be marked as a timestamp anomaly event, directly entering the unconfirmed misorder branch and assigned extremely low confidence. Subsequently, when the storage location receives new valid feedback and the timestamp is normal, the above-mentioned feedback correction mechanism can also be used to reassess and restore its status confidence level.

[0098] Subsequent feedback event records include not only regular task completion feedback but also related event records that complete the event chain. For example, if a storage location was previously marked as a low-confidence sub-chain due to missing events or unclear relationships, resulting in a low-confidence state, the sub-chain's confidence can be recalculated if subsequent supplementary event records enable the sub-chain to satisfy state continuity constraints and temporal adjacency constraints. As the sub-chain's confidence increases, the storage location's confidence level determined based on that sub-chain can also be updated from level two to level one.

[0099] Similarly, this feedback correction mechanism also applies to scenarios where the state credibility level rises from a level representing medium credibility to level one. For example, a storage location marked as medium credibility and downgraded for allocation can have its credibility level reverted to the high-credibility level one if the feedback after job execution shows that the job was successfully completed without any new anomalies, thus eliminating the restrictive impact of downgraded allocation. Through the aforementioned multi-dimensional feedback correction and anomaly handling closed loop, the autonomous operation capability and robustness of warehouse scheduling under high-frequency concurrent operations can be significantly improved.

[0100] In some specific implementations, refer to Figure 2 The figure illustrates the overall operation process of the warehouse resource scheduling optimization method based on big data analysis.

[0101] First, the system obtains the warehouse event log, which contains release event records and occupation event records of the target storage location. Each record contains its corresponding platform reception time and terminal recording time.

[0102] During the event acquisition and preprocessing phase, the system divides release event records and occupancy event records into at least one event sub-chain based on the reference information used to characterize whether event records belong to the same storage location status change process. Each event sub-chain corresponds to one storage location status change process, and a confidence flag representing the reliability of the division is generated for each event sub-chain. In the subsequent determination of inconsistency conditions, if the confidence flag of an event sub-chain is low confidence, the event records within that event sub-chain will not be used for determining the inconsistency conditions.

[0103] Next, the system performs a time inconsistency determination. Specifically, this determination is made within the same event subchain that is not marked as low confidence, checking whether the platform receiving the released event record receives it later than the platform receiving the occupied event record, and whether the terminal recording time of the released event record is earlier than the terminal recording time of the occupied event record.

[0104] If the determination result is negative, it means that no out-of-order sequence has occurred. The system performs standard state processing and outputs the result directly to the scheduling decision.

[0105] If the determination result is yes, it indicates that a time inconsistency has occurred. The system will combine the terminal type and backhaul behavior attributes recorded in the terminal attribute database with data from the historical latency statistical feature library to perform latency analysis and classification. In the analysis, the system obtains the first difference between the platform receiving time and the terminal recording time of the release event record, and the second difference between the platform receiving time and the terminal recording time of the occupation event record. This difference is then combined with the first and second latency statistical features characterizing the backhaul latency of the terminal that generated the record within the historical time period. By comparing these features, the system determines whether the inconsistency is caused by terminal backhaul latency, and then classifies the inconsistency accordingly.

[0106] The classification results include three cases: The first scenario is that the out-of-order delivery is caused by terminal feedback delay. In this case, the time sequence of the target storage location's status changes is reconstructed based on the chronological order of the terminal's recorded times. The corresponding event records are then excluded from the historical sample set used for scheduling error learning, and the status reliability level of the target storage location is determined to be Level 1.

[0107] The second scenario is a real job conflict. In this case, a deviation alarm is generated to indicate a scheduling conflict, and the target storage location is marked as conflict locked. Until the conflict is resolved or the status is clarified, the target storage location will not be used as the current automatic allocation object.

[0108] The third scenario is an unconfirmed misordering. In this case, an unconfirmed flag is generated to indicate that the cause of the misordering cannot be determined, and the credibility level of the target storage location is determined to be Level 2, which represents a lower level of credibility than Level 1. Subsequently, if subsequent feedback event records for the target storage location are obtained, the delay analysis and classification judgment are retried according to the subsequent feedback event update mechanism, thereby updating the credibility level from Level 2 to Level 1.

[0109] Finally, for out-of-order and pending-confirmation out-of-order issues caused by terminal feedback delays, the system generates status information for the target storage location carrying its status reliability level; for actual job conflicts, the system generates status information for the target storage location carrying its conflict lock status. This status information is transmitted to the scheduling decision stage so that scheduling decisions can distinguish the use of target storage locations based on their status reliability level or conflict lock status.

[0110] exist Figure 2 In the illustrated process, when a real operational conflict branch enters the scheduling decision stage, it does not mean that the real operational conflict will be directly included in the regular allocation according to the first or second level of the storage location status. Instead, it means that the deviation alarm and the conflict lock status associated with the target storage location will be transmitted to the scheduling decision stage. Upon receiving the conflict lock status, the scheduling decision stage can either exclude the target storage location from the current automatic allocation process or transfer the target storage location to a manual review, on-site confirmation, or subsequent feedback waiting process.

[0111] thus, Figure 2 The three categories correspond to different scheduling methods: terminal feedback delay causing out-of-order status is reconstructed and assigned to the first level; unconfirmed out-of-order status is marked as unconfirmed and assigned to the second level; and real job conflict corresponds to deviation alarm and conflict lock status, and is not used as the current automatic allocation object.

[0112] In scheduling decisions: If the status trust level is Level 1, the target storage location will be used for normal storage location allocation.

[0113] If the status trust level is level 2, the target storage location will be subject to restricted allocation. Restricted allocation may include lowering the target storage location's ranking position in storage location matching, or not selecting the target storage location as the current allocation target when there is a level 1 available storage location.

[0114] This application also proposes a warehouse resource scheduling optimization system based on big data analysis, used to execute the method steps of any of the above, including: an event acquisition module, used to acquire release event records and occupancy event records of the target warehouse location, wherein the release event records and occupancy event records respectively contain their corresponding platform reception time and terminal recording time; an attribute acquisition module, used to acquire the terminal type and feedback behavior attributes associated with the release event records and occupancy event records respectively when the platform reception time of the release event record is later than the platform reception time of the occupancy event record and the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record; a delay judgment module, used to determine whether the inconsistency between the platform reception time order and the terminal recording time order is caused by terminal feedback delay based on the terminal type and feedback behavior attributes; and a state reconstruction module, used to reconstruct the state change sequence of the target warehouse location according to the order of terminal recording times if it is determined that it is caused by terminal feedback delay, and generate warehouse location state information for scheduling decisions.

[0115] The above scheme can identify and locate out-of-order feedback of storage location events from different terminals in high-frequency concurrent warehousing operations, distinguish between time sequence reversal caused by asynchronous backhaul and actual operation conflicts, thereby reconstructing a storage location change process that is closer to the actual physical order before scheduling decisions, reducing the error correction of subsequent storage location allocation and scheduling models, and improving the reliability of warehousing resource scheduling optimization.

[0116] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. All modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for optimizing warehouse resource scheduling based on big data analysis, characterized in that, include: Obtain the release event record and the occupation event record of the target storage location. The release event record and the occupation event record each contain their respective platform receiving time and terminal recording time. When the platform receiving time of the release event record is later than the platform receiving time of the occupancy event record, and the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record, the terminal type and feedback behavior attributes associated with the release event record and the occupancy event record are obtained respectively. Based on the terminal type and the backhaul behavior attributes, determine whether the inconsistency between the platform's receiving time order and the terminal's recording time order is caused by terminal backhaul delay. If it is determined that the delay is caused by the terminal's backhaul, the status change sequence of the target storage location is reconstructed according to the order of the time recorded by the terminal, and storage location status information is generated for scheduling decisions.

2. The warehouse resource scheduling optimization method based on big data analysis according to claim 1, characterized in that, After obtaining the release event record and occupancy event record of the target storage location, and before the determination that the platform reception time of the release event record is later than the platform reception time of the occupancy event record and the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record, the method further includes: Based on the connecting reference information used to characterize whether the release event record and the occupancy event record belong to the same storage location status change process, the release event record and the occupancy event record are divided into at least one event sub-chain, and one event sub-chain corresponds to one storage location status change process. Furthermore, it is determined only within the same event subchain whether the release event record and the occupation event record satisfy the condition of inconsistency between the platform receiving time and the terminal recording time.

3. The warehouse resource scheduling optimization method based on big data analysis according to claim 2, characterized in that, The reference information includes: The relationship between the previous defined state of the target storage location and the event type; The comparison result between the time interval between event records and the duration threshold, wherein the duration threshold is determined according to the operation rhythm of the area where the target storage location is located; And the task identifier or operator continuity information in the event log; The division includes grouping event records into the same event subchain based on the succession relationship, the comparison result, and the continuity information; Furthermore, the method also includes: Generate a confidence marker for each event subchain, the confidence marker representing the reliability of the partition; When determining the inconsistency condition, if the confidence flag of an event subchain is low confidence, then the event records in that event subchain will not be used for determining the inconsistency condition.

4. The warehouse resource scheduling optimization method based on big data analysis according to claim 1, characterized in that, The step of determining whether the inconsistency between the platform's received time order and the terminal's recorded time order is caused by a terminal feedback delay includes: Obtain a first difference, which is the time difference between the platform receiving time and the terminal recording time of the release event record; Obtain a second difference, which is the time difference between the platform receiving time and the terminal recording time of the occupied event record; Obtain a first delay statistical feature, which is used to characterize the backhaul delay statistical characteristics of the terminal that generated the release event record within a historical time period; Obtain a second delay statistical feature, which is used to characterize the backhaul delay statistical characteristics of the terminal that generated the occupancy event record within a historical time period; Based on the comparison results of the first difference and the first delay statistical feature, and the comparison results of the second difference and the second delay statistical feature, it is determined whether the inconsistency is caused by terminal backhaul delay.

5. The warehouse resource scheduling optimization method based on big data analysis according to claim 4, characterized in that, After the step of determining whether the inconsistency between the platform's received time order and the terminal's recorded time order is caused by a terminal feedback delay, the method further includes: Based on the judgment result, the inconsistency is classified as misordering caused by terminal backhaul delay, actual operation conflict, or misordering to be confirmed. In response to the inconsistency being classified as misordering due to terminal backhaul delay, the step of reconstructing the state change sequence of the target storage location based on the order of terminal recording times is executed. In response to the inconsistency being classified as a real job conflict, a deviation alarm is generated to indicate a scheduling execution conflict; In response to the inconsistency being classified as an unconfirmed misorder, an unconfirmed flag is generated to indicate that the cause of the misorder cannot be determined.

6. The warehouse resource scheduling optimization method based on big data analysis according to claim 5, characterized in that, After classifying the inconsistency into out-of-order due to terminal backhaul delay, actual job conflict, or unconfirmed out-of-order based on the judgment result, and performing corresponding processing in response to the classification, the method further includes: Obtain the status of the target storage location after classification processing; Based on the classification results, the status credibility level of the target storage location is determined. When the classification result indicates that the terminal backhaul delay causes out-of-order delivery, the status credibility level is determined to be the first level. When the classification result is the unconfirmed misorder, the state credibility level is determined to be the second level, and the credibility level represented by the second level is lower than that of the first level; Generate status information for the target storage location carrying the aforementioned status trust level, so that scheduling decisions can distinguish the use of the target storage location based on the status trust level.

7. The warehouse resource scheduling optimization method based on big data analysis according to claim 6, characterized in that, The scheduling decision includes: In response to the state confidence level being the first level, the target storage location is used for storage location allocation; In response to the state trust level being the second level, the target storage location is subject to restricted allocation, wherein the restricted allocation includes at least one of the following: Lower the ranking position of the target storage location in the storage location matching; If an allocable storage location of the first level exists, the target storage location is not selected as the current allocation target.

8. The warehouse resource scheduling optimization method based on big data analysis according to claim 5, characterized in that, After classifying the inconsistencies as misordering due to terminal backhaul delays, actual job conflicts, or pending misordering, the following are also included: Event records classified as being out of order due to terminal backhaul delays will be excluded from the historical sample set used for scheduling error learning.

9. The warehouse resource scheduling optimization method based on big data analysis according to claim 6, characterized in that, After generating the status information of the target storage location carrying the aforementioned status confidence level, the process further includes: Obtain subsequent feedback event records for the target storage location; Based on the subsequent feedback event records, the status credibility level of the target storage location is re-determined so that the status credibility level can be updated from the second level to the first level.

10. A warehouse resource scheduling optimization system based on big data analysis, used to execute the method according to any one of claims 1 to 9, characterized in that, include: The event acquisition module is used to acquire release event records and occupancy event records of the target storage location. The release event records and occupancy event records respectively include the corresponding platform receiving time and terminal recording time. The attribute acquisition module is used to acquire the terminal type and feedback behavior attributes associated with the release event record and the occupancy event record respectively when the platform receiving time of the release event record is later than the platform receiving time of the occupancy event record and the terminal recording time of the release event record is earlier than the terminal recording time of the occupancy event record. The delay judgment module is used to determine, based on the terminal type and the backhaul behavior attribute, whether the inconsistency between the platform's receiving time order and the terminal's recording time order is caused by the terminal's backhaul delay. The status reconstruction module is used to reconstruct the status change sequence of the target storage location according to the order of the time recorded by the terminal if it is determined that the delay is caused by the terminal's back transmission, and to generate storage location status information for scheduling decisions.

Images