Central kitchen distribution scheduling system based on edge data transmission

Abstract

The present application relates to the technical field of edge data transmission, in particular to a central kitchen distribution scheduling system based on edge data transmission. The system comprises an event processing node, a dependency coding node, an edge transmission control node and a central consistency processing node; the event processing node parses the changes of order batches, meal serving batches, loading units, distribution tasks and line states into atomized scheduling events, the dependency coding node writes pre-event identifiers, influence range identifiers and state version identifiers, the edge transmission control node organizes differential data and supplementary transmission data sending according to the influence range and distribution time limit, and the central consistency processing node performs causal verification and generates missing dependency confirmation information. The system can maintain the continuity of the distribution scheduling state chain under the conditions of message disordering, local packet loss and cache retransmission, and reduce the occupation of the edge data transmission channel by irrelevant retransmission.

Description

Technical Field

[0001] This invention relates to the field of edge data transmission technology, specifically to a central kitchen delivery scheduling system based on edge data transmission. Background Technology

[0002] Central kitchen delivery scheduling systems typically process data around order aggregation, batch meal preparation, loading confirmation, delivery task allocation, and route status updates. Existing solutions often employ a centralized scheduling architecture, where each edge node uploads order batch status, meal preparation completion status, loading status, delivery task status, and route status to the central scheduling terminal according to a fixed period or event-triggered method. Upon receiving the data, the central scheduling terminal writes it to the scheduling status database based on the data arrival time or status version number, and then generates delivery tasks, adjusts routes, or updates batch merging relationships based on the current status. Communication in such solutions typically uses ordinary message queues, interface polling, or full status synchronization. The transport layer primarily focuses on whether data packets are delivered, whether messages are duplicated, and whether fields are complete, while the scheduling layer updates and calculates status only after receiving the data. Because the communication process is separated from the scheduling status evolution process, edge data transmission is usually treated as a general data handling process. Data packets only contain business fields and basic time information, lacking transmission control information that can express the dependencies between order batches, meal preparation batches, loading units, delivery tasks, and route status.

[0003] In similar existing technologies, to reduce the amount of data transmission between the central dispatcher and the edge nodes, the system employs differential upload or incremental synchronization. Edge nodes record field changes since the last upload, encapsulating the changed fields, current version number, and update time into incremental data and sending it to the central dispatcher. Upon receiving the incremental data, the central dispatcher overwrites the changed fields into existing status records and uses the version number to determine if there is a duplicate update or a write-back of an old version. This approach reduces the transmission of duplicate fields, but differential data is typically generated in units of table fields or status fields. The differential boundaries are determined by the data storage structure, not by the dependencies between delivery scheduling states. When order batch changes cause meal batch reorganization, or loading status changes cause delivery task adjustments, a single field change can affect multiple scheduling states. Ordinary differential uploads only record the field's before and after values, making it difficult to express the causal relationship between the field change and subsequent batches, tasks, and routes. The central dispatcher still needs to rely on arrival order and local status to infer the complete scheduling chain.

[0004] To improve data arrival reliability, existing communication schemes also incorporate mechanisms such as message acknowledgment, retransmission upon failure, buffer retransmission, and sequence numbering. Edge nodes wait for acknowledgment from the central dispatcher after sending data. If no acknowledgment is received within a specified time, the corresponding data is retransmitted. In the event of a network interruption, edge nodes temporarily store unsent data and retransmit it centrally after network recovery. The central dispatcher uses message number, status version, or timestamp for deduplication and sorting. While these mechanisms can handle some packet loss, duplicate transmissions, and network interruptions, their judgment is primarily based on communication layer sequence or data generation time, failing to identify whether a particular data point depends on a preceding state in terms of scheduling semantics. If subsequent line adjustment data arrives before the preceding loading acknowledgment data, or if a batch of reassembled data is missing while subsequent vehicle task data has arrived, the central dispatcher may only receive the newer data based on the version number, without being able to determine the integrity of the scheduling chain. Ordinary retransmission mechanisms may also retransmit entire buffered data segments, causing low-impact states to repeatedly enter the transmission queue.

[0005] The main technical problem with existing central kitchen delivery scheduling systems lies in the lack of identification and maintenance of causal dependencies in delivery scheduling states by the edge data transmission mechanism. This makes it difficult for the central dispatcher to promptly determine whether received data has a complete preceding state in scenarios involving network jitter, message out-of-order delivery, partial packet loss, or buffer retransmission. The root cause of this problem is that the transport layer only uses data packet arrival, version number, or timestamp as processing criteria, while there is a continuous state chain between order batches, meal preparation batches, loading units, delivery tasks, and route status during the delivery scheduling process. When an preceding event is missing, although subsequent differential data can be received normally at the communication layer, it may not be able to support correct scheduling state updates. When the central end detects inconsistencies in states, ordinary retransmission mechanisms are unable to locate missing dependencies and can only expand the retransmission scope or wait for full synchronization. Therefore, the edge data transmission process cannot directly guarantee the continuity and consistency of the scheduling state chain. Summary of the Invention

[0006] The purpose of this invention is to provide a central kitchen delivery scheduling system based on edge data transmission, which can solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The central kitchen delivery scheduling system based on edge data transmission includes an event processing node deployed at the edge of the delivery scheduling, a dependency coding node communicating with the event processing node, an edge transmission control node communicating with the dependency coding node, and a central consistency processing node communicating with the edge transmission control node. The event processing node parses changes in order batches, meal preparation batches, loading units, delivery tasks, and route status into atomic scheduling events; The dependent coding node writes a preceding event identifier, an impact scope identifier, and a status version identifier for the atomic scheduling event; The edge transmission control node organizes the transmission order of differential data and supplementary data according to the scope of event impact and delivery time limit; The central consistency processing node performs causal verification on the received data based on the preceding event identifier and the state version identifier, and generates missing dependency confirmation information.

[0008] Preferably, the event processing node establishes a delivery scheduling state diagram, and writes the order batch, meal preparation batch, loading unit, delivery task and route status into the state node with version field respectively, and forms directed dependency edges according to the constraints between batch generation, meal preparation completion, loading confirmation, task allocation and route adjustment. When any state node changes, the event processing node retrieves the affected state nodes starting from the changed state node and encapsulates the retrieval results into an atomic set of scheduling events within the same scheduling event chain.

[0009] Preferably, the dependent coding node generates a chain of event identifiers for the atomic scheduling event set, and the chain of event identifiers includes a current event identifier, a previous event identifier, a status version identifier, an impact scope identifier, and a scheduling time limit identifier; For multiple atomic scheduling events from the same scheduling event chain, the dependency encoding node determines the encoding order according to the directed dependency edge in the state diagram, writes multiple subsequent events corresponding to the same preceding state into the branch dependency field, and writes the cross-batch or cross-line impact into the impact range field.

[0010] Preferably, the edge transmission control node establishes an event sending queue based on the scheduling time limit identifier, the impact range identifier, the edge buffer queue, and the communication link return information; When the atomic scheduling event causes a delivery batch reorganization, vehicle task reassignment, or change in the route candidate set, the edge transmission control node writes differential data containing the complete preceding event identifier into the priority transmission segment. When the atomic scheduling event corresponds only to local state supplementation, the edge transmission control node merges multiple differential data within the same state version interval and writes them into the normal transmission segment.

[0011] Preferably, the event processing node sets a status baseline record and a change segment record for the delivery scheduling status diagram. The status baseline record stores the status version that was most recently confirmed by the center, and the change segment record stores the status node changes after the status baseline record. When generating the atomic scheduling event set, the event processing node excludes fields that are consistent with the state baseline record, retains fields that generate the addition, disconnection or redirection of the directed dependency edge, and writes the version increment relationship of the corresponding state node for each change fragment.

[0012] Preferably, the dependency encoding node calculates the minimum dependency closure of the atomic scheduling event set based on the directed dependency edge, writes the event identifier that has a direct preceding constraint with the current event into the main preceding field, writes the event identifier that is only indirectly constrained by intermediate events into the closure summary field, and retains the state version range of the corresponding intermediate events in the closure summary field. When multiple subsequent events share the same preceding event, the dependency encoding node generates a common dependency index for the shared preceding event and records the correspondence between the common dependency index and the branch event identifier in the branch dependency field.

[0013] Preferably, the edge transmission control node divides the event sending queue into a reliable pre-processing segment, a differential priority segment, and a merged digest segment; The reliable front-end segment stores front-end events that have not yet been confirmed by the central consistency processing node; the differential priority segment stores events whose impact range identifiers include batch reorganization, task reassignment, or changes in the route candidate set; and the merge summary segment stores local state events within the same state version range. Before sending any of the differential priority segment events, the edge transmission control node first checks whether a corresponding pre-event exists in the reliable pre-segment.

[0014] Preferably, the edge transmission control node sets a send cursor and an acknowledgment cursor for the reliable front-end segment. The send cursor points to the latest event that has been sent but has not yet received the missing dependency acknowledgment information, and the acknowledgment cursor points to the latest event that has passed the causality check by the central consistency processing node. When the confirmation cursor lags behind the sending cursor and there are subsequent events in the differential priority segment, the edge transmission control node only extracts the necessary context of the link between the two cursors and the subsequent events for retransmission, and retains the original sending order identifier and status version identifier in the retransmission link.

[0015] Preferably, after receiving the differential data containing the closure summary field, the central consistency processing node restores the corresponding set of preceding events according to the public dependency index, arranges the restoration results according to the encoding order of the chained event identifiers, and compares the restoration results with the locally stored state version identifiers. When the indirect constraint event pointed to by the closure summary field does not form a continuous path in the local state graph, the central consistency processing node generates missing dependency confirmation information carrying a common dependency index, a missing start event identifier, and a missing end event identifier.

[0016] Preferably, the central consistency processing node establishes a chain segment to be repaired based on the missing start event identifier and the missing end event identifier, and before the chain segment to be repaired is completed, writes the subsequent differential data with the same influence range identifier as the chain segment to be repaired into the temporary storage area, and writes the differential data of nodes with no shared state with the chain segment to be repaired into the scheduling state database. After receiving the missing dependency confirmation information, the edge transmission control node selects the corresponding chain segment and the status version identifier of the corresponding chain segment from the sent event cache for targeted retransmission.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Edge data transmission no longer processes data solely based on field changes or message arrival order. Instead, it parses changes in order batches, meal preparation batches, loading units, delivery tasks, and route status into atomic scheduling events, and writes a preceding event identifier, an impact scope identifier, and a status version identifier into each atomic scheduling event. The central consistency processing node can perform causal verification on received data based on the preceding event identifier and status version identifier, generating missing dependency confirmation information when the preceding event is missing, the version is discontinuous, or the state chain is not closed. The edge transmission control node then selects the corresponding chain segment and status version identifier from the sent event cache for targeted retransmission, rather than repeatedly sending the complete status or the entire cached data. This processing method creates a closed loop between communication layer data arrival verification and scheduling state chain maintenance. The central scheduling end can restore a continuous scheduling event chain under differential transmission conditions, reducing state overwrite errors caused by message out-of-order delivery, partial packet loss, or cache retransmission. This enables the edge data transmission process to support consistent updates of the central kitchen's delivery scheduling status.

[0018] 2. By employing a delivery scheduling state graph, minimum dependency closure, common dependency index, segmented event sending queue, and a mechanism for temporarily storing repaired chain segments, the scheduling event chain is organized with finer granularity. Event processing nodes write changes in state nodes, additions, disconnections, or redirections of dependency edges into the change fragment record, ensuring that uploaded data retains content directly related to the evolution of the scheduling state. Dependency encoding nodes write direct prerequisite constraints into the main prerequisite field and indirect constraints into the closure summary field, reducing redundant expressions of shared prerequisite events through the common dependency index. Edge transmission control nodes divide the event sending queue into reliable prerequisite segments, differential priority segments, and merged summary segments, verifying corresponding prerequisite events before sending subsequent critical differential events. The central consistency processing node temporarily stores data within the affected area of ​​missing chain segments and continues to write data without shared state nodes into the scheduling state database, ensuring that local chain segment repair does not block other scheduling state updates. This approach reduces the impact of irrelevant data on the retransmission process, enabling targeted repair of critical dependency chain segments. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the overall processing flow of a central kitchen delivery scheduling system based on edge data transmission. Figure 2 A flowchart for constructing the delivery scheduling state diagram and generating atomic scheduling event sets; Figure 3 Flowchart for chained dependency encoding and segmented event sending queue generation; Figure 4 This is a flowchart for missing dependency confirmation, targeted retransmission, and central temporary storage repair. Detailed Implementation

[0020] In one embodiment, reference Figure 1A central kitchen delivery scheduling system based on edge data transmission includes an event processing node deployed at the edge of the delivery scheduling, a dependency encoding node communicating with the event processing node, an edge transmission control node communicating with the dependency encoding node, and a central consistency processing node communicating with the edge transmission control node. The event processing node parses changes in order batches, meal preparation batches, loading units, delivery tasks, and route status into atomic scheduling events. The dependency encoding node writes a preceding event identifier, an impact range identifier, and a status version identifier into each atomic scheduling event. The edge transmission control node organizes the transmission order of differential data and supplementary data according to the event impact range and delivery time limit. The central consistency processing node performs causal verification on the received data based on the preceding event identifier and the status version identifier, and generates missing dependency confirmation information. Specifically, the event processing node is set at the data aggregation edge of the central kitchen delivery scheduling system, receiving data streams from order processing, meal preparation confirmation, loading confirmation, delivery task maintenance, and route status maintenance. The event processing node does not directly treat the received data as a centrally covered state, but instead decomposes a single state change into a series of data streams. Atomic scheduling events, including object identifier, object type, change fields, version before change, version after change, and generation time, are generated. The dependency encoding node reads the atomic scheduling events output by the event processing node and retrieves the most recently confirmed event in the edge-side cache for the same order batch, loading unit, delivery task, or route status. This most recently confirmed event is written to the preceding event identifier. The set of order batches, delivery tasks, or route candidates affected by the event are written to the influence range identifier. The progressive version of the corresponding status node is written to the status version identifier. The edge transmission control node sorts the differential data, preceding data, and retransmitted data in the same queue according to the influence range identifier and delivery time limit. After receiving the data, the central consistency processing node first verifies whether the preceding event identifier exists in the central state database, and then verifies whether the status version identifier is continuous with the version already received by the central end. If any verification result does not meet the continuity condition, missing dependency confirmation information containing the missing preceding event, missing version interval, and influence range is generated. In this embodiment, a verifiable correspondence is formed between the communication data packet and the delivery scheduling status chain. The central end can process data according to causal relationships under conditions of out-of-order delivery, partial packet loss, or cache retransmission.

[0021] When organizing the transmission sequence, the edge transmission control node can use an event transmission priority calculation method, which allows the scope of impact, delivery time limit, and chain segment repair status to all participate in the generation of the transmission queue. The calculation formula is as follows: ; in, This represents the transmission priority of event e; a larger value indicates a higher position in the transmission queue. This indicates the level of event impact, with values ​​of 0, 1, 2, and 3. 0 indicates that it only affects a single status field, 1 indicates that it affects the same order batch, 2 indicates that it affects delivery tasks, and 3 indicates that it affects the route candidate set or batch reorganization. This indicates the urgency of delivery, with a value ranging from 0 to 1. The closer the value is to 1, the shorter the acceptable waiting time. This indicates the required number of chain segments to be repaired. 0 means no retransmission is needed, 1 means there are preceding events to be confirmed, and 2 means confirmation of missing dependencies has been received. This represents the merge tolerance; 0 indicates that merging with other events is not allowed, and 1 indicates that entering the merge summary section is allowed. a, b, c, and d are sorting coefficients fixed in the system configuration file. In one example, if event A's... , , , Event B , , , ,and , , , Then event A's If event A is greater than event B, the edge transmission control node will prioritize event A in the differential priority segment, so that events containing changes in the candidate set of lines and prerequisite dependencies are sent before mergeable local state events.

[0022] In this embodiment, reference Figure 2The event processing node establishes a delivery scheduling state graph, writing order batches, meal preparation batches, loading units, delivery tasks, and route status into state nodes with version fields, and forming directed dependency edges according to the constraints between batch generation, meal preparation completion, loading confirmation, task allocation, and route adjustment. When any state node changes, the event processing node retrieves the affected state nodes starting from the changed state node, encapsulating the retrieval results into an atomic set of scheduling events within the same scheduling event chain. Specifically, the delivery scheduling state graph uses a joint storage of a node table and a dependency edge table. The node table records the object identifier, object type, current version, nearest central confirmed version, and edge local change version of the state node. The dependency edge table records the preceding state node, the following state node, and the dependency type. The dependencies arise because when order batches are merged or split, the event processing node retrieves the meal preparation batch node, loading unit node, and delivery task node connected to the order batch. When the meal preparation completion status changes, the event processing node retrieves the loading unit node and waiting-to-depart task node associated with the same batch. When the route status is adjusted, the event processing node retrieves the delivery task nodes using the same route candidate set. The retrieved nodes are written into the same scheduling event chain according to the direction of the dependency edges. Each atomic scheduling event in the event chain retains its own state change content, and the event chain as a whole retains the transmission path from the previous state to the subsequent state. In this embodiment, the edge side has solidified the dependencies between delivery states into a transmittable data structure before data transmission, reducing the situation where the central end infers the state relationship based on the arrival order. The scheduling event chain field configuration is shown in Table 1 below.

[0023] Table 1. Scheduling Event Chain Field Configuration Table The fields in Table 1 are generated by the event processing node and the dependency encoding node within the same edge cache transaction. The current event identifier provides a unique reference basis for the event granularity. The preceding event identifier and the status version identifier together represent the continuity of the event chain. The scope of influence identifier provides a boundary for local temporary storage and targeted retransmission at the central end. The scheduling time limit identifier participates in the edge transmission ordering. The branch dependency field is used to avoid the repeated encoding of shared preceding events in multiple subsequent events. These fields are uniformly written into the differential data header before transmission and written into the consistency check cache after being received at the central end.

[0024] Preferred, Reference Figure 3The dependency encoding node generates a chain of event identifiers for the atomic scheduling event set. These chained event identifiers include a current event identifier, a preceding event identifier, a state version identifier, an impact scope identifier, and a scheduling time limit identifier. For multiple atomic scheduling events from the same scheduling event chain, the dependency encoding node determines the encoding order according to the directed dependency edges in the state graph. It writes multiple subsequent events corresponding to the same preceding state into the branch dependency field and writes cross-batch or cross-line impacts into the impact scope field. Specifically, after receiving the atomic scheduling event set output by the event processing node, the dependency encoding node reads the state node and dependency edge corresponding to each event in the set. If an event has a unique direct preceding event, then the direct preceding event is... The current event identifier of the preceding event is written into the preceding event identifier. If an event has multiple direct preceding events, they are written into the preceding event identifier array according to the generation time and state version of the dependency edge. If multiple subsequent events come from the same loading confirmation event or the same batch reorganization event, the dependency encoding node generates a common dependency index for the shared preceding event and records the correspondence between the common dependency index and the subsequent event identifier in the branch dependency field of each subsequent event. Cross-batch impact is written into the impact range field through the batch set boundary, and cross-line impact is written into the impact range field through the line candidate set version. In this embodiment, multiple subsequent state changes can share the same preceding reference, and the central end can determine whether the preceding state exists based on the same common dependency index set.

[0025] When relying on the encoding node to determine the differential transmission content of the event set within the same scheduling event chain, it can be processed according to the formula for generating the differential set between the state baseline and the current state, as follows: ; in, This represents the set of difference fields corresponding to event chain k. This represents the i-th state field. Represents the status field The value in the current version on the edge side. Represents the status field The values ​​used in the recently finalized and centrally confirmed baseline version. This indicates the range of fields affecting event chain k. In a given value example, if the loading unit status field, delivery task status field, and route candidate set field belong to... If the current version of the loading unit status field differs from the baseline version, the current version of the delivery task status field differs from the baseline version, and the current version of the route candidate set field equals the baseline version, then... It only contains the loading unit status field and the delivery task status field. When the edge node sends data, it retains these two changed fields and their chained event identifiers, but does not send the unchanged route candidate set field.

[0026] In a preferred embodiment, the edge transmission control node establishes an event sending queue based on the scheduling time limit identifier, the impact range identifier, the edge buffer queue, and communication link return information. When the atomic scheduling event causes delivery batch reorganization, vehicle task reassignment, or a change in the route candidate set, the edge transmission control node writes differential data containing complete preceding event identifiers into the priority sending segment. When the atomic scheduling event only corresponds to local state supplementation, the edge transmission control node merges multiple differential data within the same state version interval into the normal sending segment. Specifically, the edge buffer queue establishes buffer partitions according to the event chain number, and the data within the same event chain is arranged in ascending order according to the state version identifier. Event chains are arranged according to transmission priority. The communication link return information includes the latest event identifier confirmed by the central end, missing dependency confirmation information, and the range of incomplete receiving chain segments. After reading the scheduling time limit identifier, the edge transmission control node increases the queue position of differential data with delivery time limits approaching. After reading the impact range identifier, it configures complete preceding event identifiers and necessary context for data containing batch reorganization, vehicle task reassignment, or changes in the route candidate set. Local state supplementary events enter the normal sending segment for merging when they are continuous in the version interval and have the same impact range. After merging, the initial state version and the termination state version are still retained. In this embodiment, critical events will not be blocked by a large number of local state supplementary events, and ordinary events will not occupy too many queue positions due to individual sending.

[0027] Furthermore, the event processing node sets a state baseline record and a change fragment record for the delivery scheduling state graph. The state baseline record stores the most recently confirmed state version, and the change fragment record stores changes to state nodes after the state baseline record. When generating an atomic scheduling event set, the event processing node excludes fields consistent with the state baseline record, retains fields that result in the addition, disconnection, or redirection of directed dependency edges, and writes an incrementing version relationship for the corresponding state node for each change fragment. Specifically, the state baseline record maintains a separate version according to the object identifier. The order batch status, meal preparation batch status, loading unit status, delivery task status, and route status all have the most recently confirmed version. The segment record is written in the order of local edge event generation, including the change field, the version before the change, the version after the change, the change type of dependent edge, and the scope of impact. Before generating the atomic scheduling event set, the event processing node reads the state baseline record. If a certain field is repeatedly reported but the current version is consistent with the version confirmed by the nearest center, it is not written to the differential field. If a certain field causes a dependent edge to be added, disconnected, or redirected, it is written to the change segment record even if the field value is short. Adding a dependent edge means that the new state node is constrained by the current event. Disconnecting a dependent edge means that the original pre-constraint is no longer applicable. Redirecting a dependent edge means that the pre-source of subsequent events has changed. In this embodiment, the differential transmission content is determined by the change of the scheduling state diagram, rather than just by the change of ordinary field values.

[0028] Dependency-encoded nodes can determine the scope of dependencies that the current event must carry through the minimum dependency closure, avoiding the lack of indirect preceding relationships during central-end verification. The calculation formula is as follows: ; in, Let represent the minimal dependency closure of event e, p represent the candidate preceding event, and m represent the intermediate event between the candidate preceding event and the current event. This indicates that there are direct directed dependency edges in the state graph. This represents a reachability relation formed by one or more directed dependency edges. This indicates that either the direct or indirect prerequisite condition is met. In one example, if the order batch generation event points to the meal preparation completion event, the meal preparation completion event points to the loading confirmation event, and the loading confirmation event points to the vehicle task reassignment event, then the minimum dependency closure of the vehicle task reassignment event includes the loading confirmation event, the meal preparation completion event, and the order batch generation event. The dependency coding node writes the loading confirmation event into the main prerequisite field and writes the version range of the meal preparation completion event and the order batch generation event into the closure summary field.

[0029] In this embodiment, the dependency encoding node calculates the minimum dependency closure of the atomic scheduling event set based on the directed dependency edges. Event identifiers with direct pre-constraints to the current event are written into the main pre-constraint field, and event identifiers with indirect constraints only via intermediate events are written into the closure summary field. The closure summary field also retains the state version range of the corresponding intermediate events. When multiple subsequent events share the same pre-constraint event, the dependency encoding node generates a common dependency index for the shared pre-constraint event and records the correspondence between the common dependency index and the branch event identifier in the branch dependency field. Specifically, the dependency encoding node traverses the directed dependency edges in reverse from the current event. When encountering a first-level preceding event, the main preceding field is written. As the process continues traversing upwards along the preceding events, the intermediate event version ranges are written into the closure summary field. If multiple vehicle task reassignment events are simultaneously generated from the same batch of reorganization events, the dependency encoding node generates only one common dependency index for the batch reorganization events and writes this common dependency index into the branch dependency field of each vehicle task reassignment event. The complete preceding chain of the batch reorganization events is not repeatedly written. After receiving the data, the central end can restore the shared preceding relationship through the common dependency index. In this embodiment, direct and indirect preceding constraints are expressed hierarchically, reducing chain data duplication and retaining the necessary dependency information required for causal verification at the central end. The event sending queue and chain segment repair configuration are shown in Table 2 below.

[0030] Table 2 Event Sending Queue and Link Segment Repair Configuration Table Table 2 describes the correspondence between the edge-side sending queue and the central-side chain segment repair status. The reliable pre-segment provides the pre-confirmation basis for the differential priority segment. The merged summary segment is used to carry low-association local states within the same state version range. The chain segment to be repaired is generated by the central end based on the missing dependency confirmation information. The temporary storage area only receives data that shares the influence range with the chain segment to be repaired. Data of non-shared state nodes does not enter the temporary storage area but continues to be processed according to the normal path.

[0031] Preferably, the edge transmission control node divides the event sending queue into a reliable pre-event segment, a differential priority segment, and a merge summary segment. The reliable pre-event segment stores pre-events that have not yet been confirmed by the central consistency processing node. The differential priority segment stores events whose impact range identifiers include batch reorganization, task reassignment, or changes in the route candidate set. The merge summary segment stores local state events within the same state version interval. Before sending any differential priority segment event, the edge transmission control node first checks whether a corresponding pre-event exists in the reliable pre-event segment. Specifically, the event sending queue is managed in a segment-ordered and inter-segment-adjustable manner. The reliable pre-event segment sends events in ascending order of state version identifiers, and the differential priority segment sends events according to event transmission priority. When sending differential priority segment events, the merged summary segments are merged according to the impact range identifier and version range. When the edge transmission control node is preparing to send differential priority segment events, it reads the main pre-event field and closure summary field in the differential data header, and queries whether there are any unconfirmed direct pre-events in the reliable pre-event segment. If there is a corresponding pre-event, it sends or retransmits the pre-event first. If the pre-event has been confirmed by the central end, it sends the differential priority segment event. If there is a local state event in the merged summary segment that shares a state node with the differential priority segment event, the shared local state event is promoted to a necessary context and sent with the differential priority segment event. In this embodiment, the pre-event check is completed before the high-impact differential event is sent, and the low-impact local events are merged without disrupting the chain continuity.

[0032] When sending pre-events, differential priority events, and merged digest events, the edge transmission control node can use a continuity gap calculation method to determine whether the central end is missing events within the closure digest. The calculation formula is as follows: ; in, This represents the dependency gap amount of event e at the central end. Let p represent the minimal dependency closure of event e, and let p represent any preceding event in the minimal dependency closure. This indicates the central terminal's confirmation status of the existence of the preceding event p. A value of 1 indicates that the central terminal has stored and passed the causality check, while a value of 0 indicates that the central terminal has not stored or has not passed the causality check. In one example, if the minimum dependency closure of the vehicle task reassignment event includes the order batch generation event, the meal preparation completion event, and the loading confirmation event, where the order batch generation event and the loading confirmation event have been confirmed by the central terminal, but the meal preparation completion event has not been confirmed, then... The central consistency processing node generates missing dependency confirmation information for the chain segment where the meal preparation completion event is located, without requiring the edge side to retransmit the entire event chain.

[0033] Furthermore, the edge transmission control node sets a send cursor and an acknowledgment cursor for the reliable front-end segment. The send cursor points to the latest event that has been sent but for which missing dependency acknowledgment information has not been obtained, and the acknowledgment cursor points to the latest event that has passed causality verification by the central consistency processing node. When the acknowledgment cursor lags behind the send cursor and there are subsequent events in the differential priority segment, the edge transmission control node only extracts the chain segment between the two cursors and the necessary context of the subsequent events for retransmission, and retains the original sending order identifier and status version identifier in the retransmission chain segment. Specifically, the send cursor moves to the position of the sent event after each reliable front-end segment event is sent to the central end, and the acknowledgment cursor moves to the position of the event that has passed causality verification by the central consistency processing node after receiving the acknowledgment result from the central end. If the highest consecutive version position of the verification result is determined, and the sending cursor has moved to version 8 but the confirmation cursor is still at version 5, and there are subsequent line adjustment events in the differential priority segment that depend on events between versions 6 and 8, then the edge transmission control node extracts the corresponding chain segments from the sent event cache from versions 6 to 8, and attaches the order batch identifier, loading unit identifier, and line candidate set version required by the subsequent line adjustment events as necessary context. The retransmitted data retains the original sending order identifier for the central end to restore the original sending sequence, and the retransmitted data retains the status version identifier for the central end to determine whether the chain segment is continuous with the local state library. In this embodiment, the retransmission range is determined by the cursor difference and the subsequent event dependency relationship to avoid coarse retransmission based on the cache range.

[0034] When determining the supplementary transmission link segment, the edge transmission control node can use a link segment truncation formula for limitation, as follows: ; in, This indicates the link segment to be supplemented, triggered by event e. This indicates the highest consecutive state version confirmed by the central endpoint. This indicates the highest status version that has been sent from the edge side but has not yet been confirmed by the center. The set of necessary context versions for event e. This represents the version range from the next confirmed version to the highest version already sent. In one example, if the central end confirms version 5, and the edge end has already sent version 9, then subsequent line adjustment events only depend on versions 6, 7, and 9. Versions 6 to 9, For versions 6, 7, and 9, For versions 6, 7, and 9, the edge transmission control node only transmits the events and their status version identifiers corresponding to these three versions.

[0035] In this embodiment, reference Figure 4After receiving differential data containing the closure summary field, the central consistency processing node restores the corresponding set of preceding events based on the common dependency index, arranges the restoration results according to the encoded order of the chained event identifiers, and compares the restoration results with the locally stored state version identifiers. When the indirect constraint event pointed to by the closure summary field does not form a continuous path in the local state graph, the central consistency processing node generates missing dependency confirmation information carrying the common dependency index, missing start event identifier, and missing end event identifier. Specifically, after receiving the differential data, the central consistency processing node reads the current event identifier, main preceding field, closure summary field, common dependency index, and branch dependency field. If a common dependency index exists in the branch dependency field, the local common dependency index table is queried and the shared predecessor event set is restored. Then, the predecessor event set is sorted according to the state version identifier. After sorting, it is checked whether adjacent versions are continuous. If the main predecessor event exists but the intermediate events in the closure summary field cannot form a continuous path in the local state graph, the path break position is used as the missing start event identifier, and the last event required to restore the continuous path is used as the missing end event identifier. The missing dependency confirmation information also carries the common dependency index, so that the edge side can locate the common gap of multiple branch events under the same shared predecessor event. In this embodiment, the central end can discover the hidden indirect dependency gap in the differential data of the newer surface version.

[0036] When the central consistency processing node performs continuous path verification on the closure digest field, it can use the path integrity determination formula, as follows: ; in, This represents the complete dependency path of event e. This represents the ordered precedence path reconstructed from the closure summary field, where q represents any adjacent connection in the ordered precedence path. This represents the local existence state of adjacent connections. A value of 1 indicates that the central local state graph has a corresponding directed dependency edge and the versions at both ends are continuous. A value of 0 indicates that the corresponding directed dependency edge does not exist or the versions at both ends are not continuous. This indicates a product of all adjacent connections in the ordered preceding path. In one example, if the connection between the order batch generation event and the meal preparation completion event exists and the versions are consecutive, the connection between the meal preparation completion event and the loading confirmation event is missing, and the connection between the loading confirmation event and the vehicle task reassignment event exists and the versions are consecutive, then the corresponding... The values ​​are 1, 0, and 1 respectively. The central consistency processing node then confirms that the closure digest path is incomplete and generates missing dependency confirmation information.

[0037] In a preferred embodiment, the central consistency processing node establishes a repairable chain segment based on the missing start event identifier and the missing end event identifier. Before the repairable chain segment is completed, subsequent differential data with the same influence range identifier as the repairable chain segment are written to a temporary storage area, and differential data of nodes with no shared state with the repairable chain segment are written to a scheduling state database. After receiving the missing dependency confirmation information, the edge transmission control node selects the corresponding chain segment and its corresponding state version identifier from the sent event cache for targeted retransmission. Specifically, the central consistency processing node establishes a repairable chain segment record after the missing dependency confirmation information is generated. The repairable chain segment record includes a common dependency index, a missing start event identifier, a missing end event identifier, an influence range identifier, and the current repair status. Subsequent arriving differential data with the same influence range identifier or common state identifier are retransmitted. If a shared state node is found, the central consistency processing node writes it into the temporary storage area and retains the original receiving order and state version identifier for the temporary storage data. If the differential data that arrives later does not share the order batch, loading unit, delivery task, or route candidate set, the central consistency processing node writes it into the scheduling state database after passing the regular causality check. After receiving the missing dependency confirmation information, the edge transmission control node queries the sent event cache based on the missing start event identifier and missing end event identifier, extracts the corresponding event chain segment, state version identifier, original sending order identifier, and necessary context, and then sends it to the central end through the reliable front-end segment. After the central end completes the verification of the chain segment to be repaired, it rereads the subsequent differential data with the same impact range identifier in the temporary storage area for causality verification. In this embodiment, the local missing chain segment will not pollute the global scheduling state, nor will it cause the data of the non-shared state node to wait for the same repair process.

[0038] In this embodiment, the central consistency processing node can also set the reading order of the temporary storage area according to the influence range identifier. Specifically, the temporary storage data corresponding to the same order batch, the same loading unit, the same delivery task, or the same route candidate set are stored in different temporary storage buckets. The temporary storage buckets are arranged in ascending order according to the status version identifier. After the repair chain segment is completed, only the temporary storage bucket with the same influence range as the repair chain segment is released. When releasing, the preceding event identifier verification, status version identifier verification, and closure summary path verification are re-executed. If the temporary storage data passes the verification, it is written to the scheduling status database. If there is still a new missing path, a new chain segment to be repaired is established based on the new missing start event identifier and missing end event identifier. The edge transmission control node retains the chain segment index divided according to the event chain number in the sent event cache. The chain segment index records the current event identifier, preceding event identifier, status version identifier, influence range identifier, and original sending order identifier. After receiving feedback from the central end, the data to be retransmitted can be directly located from the chain segment index. In this embodiment, there is a consistent identifier system between the central end temporary storage, chain segment repair, and edge side targeted retransmission, so that out-of-order received data can be restricted to the corresponding influence range for processing.

[0039] Furthermore, the system can set event cache cleanup conditions on the edge side. The event cache cleanup conditions are not based on the completion of transmission alone, but on the confirmation results returned by the central consistency processing node, the release results of the common dependency index, and the completion results of the chain segment to be repaired. Specifically, the edge transmission control node deletes the complete data of the sent event from the sent event cache only when the state version identifier of a certain event has been confirmed by the central end, the common dependency index referencing the event is no longer referenced by the differential priority segment event, and there is no chain segment to be repaired with the event as a missing start event or missing end event. If the event has been confirmed by the central end but is still referenced by subsequent branch events as a shared predecessor event, the current event identifier, state version identifier, common dependency index, and closure summary field are retained, but the complete field values ​​are no longer retained. If the central end needs to restore the shared predecessor relationship in subsequent verification, the edge side can use the retained index data to rebuild the corresponding dependency chain. In this embodiment, the event cache can both support the targeted retransmission of missing chain segments and avoid the long-term retention of complete state fields unrelated to scheduling dependencies.

[0040] In one embodiment, the central consistency processing node can set up state database write transactions. The state database write transactions use event chains as transaction boundaries, rather than individual data packets. Specifically, before writing the current event, the central node first reads the current event identifier, the preceding event identifier, the state version identifier, the scope of influence identifier, and the closure summary field. If the current event is a single-chain event without branches, then the minimum write transaction is formed with the event and the event corresponding to the main preceding field. If the current event is a branch event under the common dependency index, then the write transaction is formed with the shared preceding event corresponding to the common dependency index, the branch event in the branch dependency field, and the intermediate version range in the closure summary field. During the transaction execution, the central node first writes or confirms the preceding events that meet the continuity condition, and then writes the current difference field. After writing, the directed dependency edges and state version identifiers in the state graph are updated. If any preceding event is missing or the version is not continuous, the transaction does not overwrite the existing state, but generates missing dependency confirmation information and writes the relevant subsequent difference data to the temporary storage area. In this embodiment, the central node will not directly overwrite the unrepaired preceding state due to the newer version data that arrives later.

[0041] In a preferred embodiment, a version receipt mapping table can be set between the edge-side event processing node and the central consistency processing node. The version receipt mapping table records the highest consecutive version, the temporarily stored version, the requested retransmission version, and the released common dependency index returned by the central end for each event chain number. After receiving the communication link return information from the central end, the edge transmission control node updates the version receipt mapping table and corrects the subsequent sending queue according to the mapping table. If the highest consecutive version of an event chain is lower than the sent version and there is a requested retransmission version, the reliable front-end segment will send the event corresponding to the requested retransmission version first. If the temporarily stored version of an event chain shares the influence range with the subsequent events in the differential priority segment, the edge transmission control node will attach the necessary context of the subsequent events with the retransmission event. If a common dependency index has been released, the subsequent events will no longer carry the complete closure summary of the common dependency index, but only carry the release flag and the current front-end event identifier. In this embodiment, the edge-side sending queue can converge according to the actual link reception status of the central end, reducing the repeated sending of confirmed dependency information.

[0042] In this embodiment, to adapt to scenarios where multiple edge nodes simultaneously send scheduling events to the central end, the central consistency processing node can establish a two-layer receiving buffer based on the edge node identifier and the scheduling event chain identifier. The edge node identifier is used to distinguish different edge sources, and the scheduling event chain identifier is used to distinguish event sequences of different order batches, loading units, delivery tasks, or route candidate sets within the same edge node. When events sent by different edge nodes have the same influence range identifier, the central consistency processing node does not directly overwrite the state according to the receiving time, but compares whether the state version identifier and the preceding event identifier point to the same central end state node. If the events of two edge nodes correspond to different subsequent route candidate sets of the same delivery task, the central end establishes a conflict temporary storage record and requests the closure digest of the shared preceding event from the relevant edge nodes respectively. After receiving the closure digest, the writeable events are determined according to the common dependency index and version continuity. Events whose continuity cannot be determined are kept temporarily. In this embodiment, data from multiple edge sources can still enter the central state graph according to the unified event chain rules, and the causal verification logic will not be disrupted due to differences in sources.

[0043] Furthermore, the event processing node can set event deduplication rules during the atomic scheduling event generation phase. The deduplication rules do not use the complete same field content as the only condition, but also compare the current event identifier, state version identifier, predecessor event identifier, and scope of influence identifier. If the field content of two events is the same but the state version identifier is different, the two events are retained and written into the same event chain. If the state version identifiers of two events are the same but the predecessor event identifiers are different, they are retained as conflict candidate events and handed over to the dependency encoding node to write the branch dependency field. If the current event identifier, state version identifier, predecessor event identifier, and scope of influence identifier of two events are all the same, the event that enters the edge cache first is retained and the duplicate source is recorded. After receiving the duplicate source record, the central end only updates the received statistics information and does not change the state diagram. In this embodiment, the three types of cases, duplicate reporting, different versions with the same value, and different predecessors with the same version, are processed separately to avoid the event chain being broken due to ordinary deduplication.

[0044] In one embodiment, the system can set a reconstructable payload format for differential data. The payload format includes a data header, a dependency header, a differential body, and a context body. The data header contains the current event identifier, event chain number, and edge node identifier. The dependency header contains the preceding event identifier, closure summary field, common dependency index, and branch dependency field. The differential body contains the change fields obtained by comparing the state baseline record with the current state. The context body contains auxiliary information required by the central end to complete causal verification but not directly overwriting the state database. The auxiliary information includes the original transmission order identifier, state version identifier, impact range identifier, and scheduling time limit identifier. When parsing the payload, the central end first parses the data header to determine the cache location, then parses the dependency header to establish the preceding path, then parses the differential body to confirm field changes, and then parses the context body to determine the temporary storage and retransmission boundaries. In this embodiment, the transmitted payload itself is self-descriptive, and the central end can recover the event chain structure without receiving the full state.

[0045] In a preferred embodiment, after the central consistency processing node completes the directed retransmission verification, it can return chain segment repair confirmation information to the edge transmission control node. The chain segment repair confirmation information includes the start event identifier of the repaired chain segment, the end event identifier of the repaired chain segment, the identifier of the released temporary storage bucket, the updated highest continuous state version, and the set of retained common dependency indexes. After receiving the chain segment repair confirmation information, the edge transmission control node removes the events that have been repaired in the reliable preceding segment from the range to be sent, recalculates the transmission priority of subsequent events in the differential priority segment that depend on the repaired chain segment, and splits or merges the summary data in the merged summary segment that shares the influence range with the released temporary storage bucket into new sending units. If the central end returns the set of retained common dependency indexes, the edge side continues to retain the corresponding preceding event index. If the central end does not return a certain common dependency index, the edge side marks the corresponding index as a cleanable state. In this embodiment, the state version advancement of the edge side and the central end can be kept consistent after the chain segment repair is completed.

[0046] In this embodiment, the system uses a temporary storage method rather than overwriting for data with abnormal arrival order. Specifically, when the central consistency processing node receives subsequent differential data, if the event corresponding to the main precondition field does not exist but the closure digest field can point to a known common dependency index, the subsequent differential data is written to the temporary storage bucket corresponding to the common dependency index. If neither the main precondition field nor the common dependency index can be found in the local state graph at the central end, the data is written to the unidentified cache corresponding to the source edge node, and the edge side is requested to resend the data header and dependency header. If the main precondition field exists but the state version identifier is not continuous, a repair chain segment is established and the writing of data with the same impact range identifier is frozen. The freezing is limited to data of shared order batches, loading units, delivery tasks, or route candidate sets. Other event chains can still be written to the scheduling state library after verification. In this embodiment, out-of-order data can be limited to its own dependency relationship for processing, and the central scheduling state library will not receive subsequent states that lack precondition proof.

[0047] Furthermore, the central consistency processing node can maintain two types of path markers in the local state graph: confirmed paths and paths to be repaired. Confirmed paths are formed by events that have passed causality verification and been written into the scheduling state database. Paths to be repaired are formed by missing start event identifiers and missing end event identifiers corresponding to missing dependency confirmation information. When a retransmission link arrives, the central end attempts to connect the retransmission link to the path to be repaired. If the start event of the retransmission link can be connected to the end of the confirmed path, and the end event of the retransmission link can be connected to the pre-field of subsequent events in the temporary storage area, then the path to be repaired is converted into a confirmed path, and subsequent events in the temporary storage area enter the re-verification process. If the retransmission link can only be connected to the end of the confirmed path but cannot be connected to subsequent events in the temporary storage area, then the central end continues to request intermediate links from the edge side between the end event of the retransmission link and the main pre-field of subsequent events. In this embodiment, link repair has explicit access conditions, avoiding the central end from prematurely releasing temporary data when the pre-link is still incomplete.

[0048] In one embodiment, the system can deploy the central kitchen delivery scheduling system based on edge data transmission as a software service that operates collaboratively on the edge and center sides. Event processing nodes, dependency coding nodes, and edge transmission control nodes interact with each other on the edge side through shared cache and message topics. The central consistency processing node interacts with each other on the center side through receive cache, state graph storage, and scheduling state library. The edge-side shared cache is partitioned according to the event chain number. The dependency coding node only reads events that the event processing node has completed version incrementing. The edge transmission control node only sends data that the dependency coding node has written with the current event identifier, the preceding event identifier, the state version identifier, and the scope of influence identifier. The central-side receive cache only submits data that has passed causality verification to the state graph storage. The state graph storage then submits overridable state fields to the scheduling state library. In this embodiment, the data handover between each node is based on the event chain identifier and the state version identifier as boundaries to avoid cross-layer state inconsistencies under the ordinary field synchronization method.

[0049] In this embodiment, the overall operation of the system is as follows: after receiving changes in the delivery scheduling status at the edge, atomic scheduling events are generated. The event processing node determines the affected status nodes based on the delivery scheduling status diagram and forms a scheduling event chain. The dependency encoding node writes chained event identifiers, minimum dependency closures, common dependency indexes, and branch dependency fields into the scheduling event chain. The edge transmission control node organizes the transmission order according to the reliable pre-segment, differential priority segment, and merged summary segment. The central consistency processing node performs causal verification based on the pre-segment event identifier, status version identifier, closure summary field, and common dependency index. When a missing chain segment is found, missing dependency confirmation information is generated and a chain segment to be repaired is established. The edge transmission control node selects the corresponding chain segment and necessary context from the sent event cache based on the missing dependency confirmation information for targeted retransmission. After the central end completes the repair, it releases the temporary data with the same impact range identifier and advances the scheduling status library version. In this embodiment, edge data transmission, event dependency encoding, central causal verification, and missing chain segment repair constitute a closed processing chain, enabling the central kitchen delivery scheduling system to maintain the continuous state relationship between order batches, meal batches, loading units, delivery tasks, and line status even under differential transmission conditions.

Claims

1. A central kitchen delivery scheduling system based on edge data transmission, characterized in that, It includes an event processing node deployed at the edge of the delivery scheduling, a dependency coding node that is communicatively connected to the event processing node, an edge transmission control node that is communicatively connected to the dependency coding node, and a central consistency processing node that is communicatively connected to the edge transmission control node. The event processing node parses changes in order batches, meal preparation batches, loading units, delivery tasks, and route status into atomic scheduling events; The dependent coding node writes a preceding event identifier, an impact scope identifier, and a status version identifier for the atomic scheduling event; The edge transmission control node organizes the transmission order of differential data and supplementary data according to the scope of event impact and delivery time limit; The central consistency processing node performs causal verification on the received data based on the preceding event identifier and the state version identifier, and generates missing dependency confirmation information.

2. The central kitchen delivery scheduling system based on edge data transmission according to claim 1, characterized in that, The event processing node establishes a delivery scheduling state diagram, and writes the order batch, meal preparation batch, loading unit, delivery task and route status into the state node with version field respectively, and forms directed dependency edges according to the constraints between batch generation, meal preparation completion, loading confirmation, task allocation and route adjustment. When any state node changes, the event processing node retrieves the affected state nodes starting from the changed state node and encapsulates the retrieval results into an atomic set of scheduling events within the same scheduling event chain.

3. The central kitchen delivery scheduling system based on edge data transmission according to claim 2, characterized in that, The dependent coding node generates a chain of event identifiers for the atomic scheduling event set. The chain of event identifiers includes a current event identifier, a preceding event identifier, a status version identifier, an impact scope identifier, and a scheduling time limit identifier. For multiple atomic scheduling events from the same scheduling event chain, the dependency encoding node determines the encoding order according to the directed dependency edge in the state diagram, writes multiple subsequent events corresponding to the same preceding state into the branch dependency field, and writes the cross-batch or cross-line impact into the impact range field.

4. The central kitchen delivery scheduling system based on edge data transmission according to claim 3, characterized in that, The edge transmission control node establishes an event sending queue based on the scheduling time limit identifier, the impact range identifier, the edge buffer queue, and the communication link return information; When the atomic scheduling event causes a delivery batch reorganization, vehicle task reassignment, or change in the route candidate set, the edge transmission control node writes differential data containing the complete preceding event identifier into the priority transmission segment. When the atomic scheduling event corresponds only to local state supplementation, the edge transmission control node merges multiple differential data within the same state version interval and writes them into the normal transmission segment.

5. The central kitchen delivery scheduling system based on edge data transmission according to claim 2, characterized in that, The event processing node sets a status baseline record and a change segment record for the delivery scheduling status diagram. The status baseline record saves the status version that was most recently confirmed by the center, and the change segment record saves the status node changes after the status baseline record. When generating the atomic scheduling event set, the event processing node excludes fields that are consistent with the state baseline record, retains fields that generate the addition, disconnection or redirection of the directed dependency edge, and writes the version increment relationship of the corresponding state node for each change fragment.

6. The central kitchen delivery scheduling system based on edge data transmission according to claim 3, characterized in that, The dependency encoding node calculates the minimum dependency closure of the atomic scheduling event set based on the directed dependency edge, writes the event identifier that has a direct preceding constraint with the current event into the main preceding field, writes the event identifier that is only indirectly constrained by intermediate events into the closure summary field, and retains the state version range of the corresponding intermediate event in the closure summary field. When multiple subsequent events share the same preceding event, the dependency encoding node generates a common dependency index for the shared preceding event and records the correspondence between the common dependency index and the branch event identifier in the branch dependency field.

7. The central kitchen delivery scheduling system based on edge data transmission according to claim 4, characterized in that, The edge transmission control node divides the event sending queue into a reliable pre-segment, a differential priority segment, and a merged digest segment; The reliable front-end segment stores front-end events that have not yet been confirmed by the central consistency processing node; the differential priority segment stores events whose impact range identifiers include batch reorganization, task reassignment, or changes in the route candidate set; and the merge summary segment stores local state events within the same state version range. Before sending any of the differential priority segment events, the edge transmission control node first checks whether a corresponding pre-event exists in the reliable pre-segment.

8. The central kitchen delivery scheduling system based on edge data transmission according to claim 7, characterized in that, The edge transmission control node sets a send cursor and an acknowledgment cursor for the reliable front-end. The send cursor points to the latest event that has been sent but has not yet received the missing dependency acknowledgment information. The acknowledgment cursor points to the latest event that has passed the causality check by the central consistency processing node. When the confirmation cursor lags behind the sending cursor and there are subsequent events in the differential priority segment, the edge transmission control node only extracts the necessary context of the link between the two cursors and the subsequent events for retransmission, and retains the original sending order identifier and status version identifier in the retransmission link.

9. The central kitchen delivery scheduling system based on edge data transmission according to claim 6, characterized in that, After receiving the differential data containing the closure summary field, the central consistency processing node restores the corresponding set of preceding events according to the public dependency index, arranges the restoration results according to the encoding order of the chained event identifiers, and compares the restoration results with the locally stored state version identifiers. When the indirect constraint event pointed to by the closure summary field does not form a continuous path in the local state graph, the central consistency processing node generates missing dependency confirmation information carrying a common dependency index, a missing start event identifier, and a missing end event identifier.

10. The central kitchen delivery scheduling system based on edge data transmission according to claim 9, characterized in that, The central consistency processing node establishes a chain segment to be repaired based on the missing start event identifier and the missing end event identifier. Before the chain segment to be repaired is completed, the subsequent differential data with the same influence range identifier as the chain segment to be repaired is written into the temporary storage area, and the differential data of nodes with no shared state with the chain segment to be repaired is written into the scheduling state database. After receiving the missing dependency confirmation information, the edge transmission control node selects the corresponding chain segment and the status version identifier of the corresponding chain segment from the sent event cache for targeted retransmission.

Images