A method and system for real-time collaborative control of beverage equipment

Abstract

This invention proposes a real-time collaborative control method and system for beverage equipment. The method includes: acquiring the target beverage order and generating a collaborative event chain; collecting the current execution status, actual trigger time, weighing result, and equipment executable status of each action event to form a current order process status table; calculating key judgment values ​​based on the collaborative event chain and the current order process status table, and determining the set of affected events along the successor relationship; and issuing local collaborative control instructions based on the action events that have not yet been completed in the set of affected events. This invention more specifically addresses the problems of insufficient real-time collaboration, inaccurate key deviation positioning, and delayed compensation control in the prior art.

Description

Technical Field

[0001] This invention belongs to the field of beverage preparation equipment, and in particular relates to a real-time collaborative control method and system for beverage equipment. Background Technology

[0002] Existing beverage preparation equipment and its control systems are typically designed and controlled around a single device or a single process. For example, a coffee machine dispenses liquid according to preset extraction parameters, a fructose machine adds sugar according to a set time or output volume, an ice maker supplies ice, a robotic arm handles cup picking, moving, and positioning, and a weighing module, I / O control board, and related drive interfaces handle status acquisition and control execution functions, respectively. In some more mature systems, these devices can connect to a unified software platform via serial ports, network interfaces, or control boards, enabling functions such as recipe management, device management, queue ordering, status display, and fault indication. However, their underlying control methods mostly still break down a beverage into several coarse-grained preparation steps, then issue action commands to different devices in a preset order, with each device executing independently within its local scope. This approach can complete basic preparation tasks when the number of devices is small and the process is simple. However, in real-world scenarios, when multiple heterogeneous devices such as robotic arms, ice makers, coffee machines, fructose machines, and weighing modules participate in the same order simultaneously, and there are overlapping actions, waiting times, sequential switching, and result constraints, the shortcomings of existing technologies become apparent. First, existing systems are typically organized using coarse-grained steps such as "adding ice," "adding liquid," "adding sugar," and "transferring the cup." This makes it difficult to break down actions within the same step, such as starting, executing, stopping, and confirming, into sufficiently fine control levels. While multiple devices may interact, there's a lack of unified event-level timing representation, failing to accurately support real-time collaboration for the entire beverage preparation process. Second, existing systems often only focus on whether a single device is executing correctly, lacking a unified state representation mechanism for the entire beverage preparation process. It's difficult to handle the execution status, result status, and whether subsequent devices have the necessary conditions for execution within the same framework. Therefore, if delays, insufficient results, or sequential waiting conflicts occur, the system can usually only react passively at the local device level, unable to accurately determine which subsequent stage the deviation has propagated to. Furthermore, beverage making is characterized by short cycles, dense movements, and the difficulty in reversing some results once they are achieved. For example, insufficient syrup addition will directly affect subsequent weighing confirmation and compensation actions, and a delay in the robotic arm's arrival will affect the timing of the coffee machine's start-up. Small mismatches in preceding actions will quickly transmit to subsequent action waiting, result deviations, and abnormal overall cup rhythm. Existing technologies lack an engineering method that can both identify key deviations at the action event level and implement local corrections for subsequent incomplete actions.

[0003] It is evident that while the closest existing technology already possesses the capabilities of device access, recipe execution, and basic status acquisition, it still struggles to address issues such as coarse-grained actions, insufficient process status organization, difficulty in identifying deviation propagation, and lagging local control during the production of multiple beverage devices for the same order. Therefore, it is necessary to propose a real-time collaborative control scheme that better suits the beverage production scenario, enabling the system to establish a unified event organization structure, process status structure, and local control structure around the actual production process of a single beverage, thereby improving the stability and consistency of multi-device collaborative production. Summary of the Invention

[0004] The purpose of this invention is to propose a real-time collaborative control method and system for beverage equipment to solve the above-mentioned problems.

[0005] To achieve the above objectives, a real-time collaborative control method for beverage equipment is provided in a first aspect of the present invention, the method comprising the following steps: S1. Obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online device from the device management module, expand each recipe step of the recipe template into an action event for a specific device action, and establish a set of preceding events and an offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound device number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field; S2. During the execution of the collaborative event chain, the current execution status, actual trigger time, weighing result and equipment executable status of each action event are collected to calculate the normalized timing deviation and event status index, and to form the current order process status table. S3. Based on the collaborative event chain and the current order process status table, calculate the deviation intensity value of each action event, and combine the successor path length from the current event to the end of the order and the event status index to calculate the key judgment value. Action events with key judgment values ​​higher than the threshold are judged as key collaborative control deviation events, and the set of affected events is determined along the successor relationship. S4. Based on the action events that have not yet been completed in the set of affected events, backtrack to the most recent key collaborative control deviation event, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time for time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

[0006] Preferably, S1 further includes: After each recipe step of the recipe template is expanded into an action event for a specific device, the corresponding action event is immediately bound to the specific device, and the binding is based on the action matching relationship in the device capability table. When multiple similar devices exist, the system will read the current status of the devices and select the device that is in an executable state and has the lowest current order occupancy to complete the binding.

[0007] Preferably, the step of calculating the planned trigger time of the corresponding action event specifically includes: For each preceding event of the current action event, add the completion time of the current preceding event to the offset configuration from the preceding event to the current event to obtain the preceding event calculation result. Take the maximum value among all the preceding event calculation results as the planned trigger time of the current action event.

[0008] Preferably, the target value field is used to record the target result of the action event in the current order. Action events with feeding or weighing constraints are written to the target value in the recipe template, and action events without result constraints are written to 0. The collaborative event chain is stored using a combination of node tables and relationship tables. Each record in the node table corresponds to an action event. Each record in the relationship table corresponds to a prerequisite constraint, which includes at least the current event number, the prerequisite event number, and the offset configuration. The node table stores the action events sequentially.

[0009] Preferably, in step S2, during the execution of the collaborative event chain, an event status table is established for the current order. Each record in the event status table corresponds to an action event in the event chain, and the record content includes the current execution status, the actual trigger time, the weighing result, and the equipment's executable status. The initialization of the event status table comes from the replication of the event chain node. The execution status is initially recorded as not started, and is set to empty at the actual trigger time. The weighing result is set to the most recent sampled value for feeding-related events and to zero value for non-weighing-related events. The executable status of the equipment is jointly determined by the basic status returned by the current equipment driver and the completion status of the preceding events.

[0010] Preferably, the steps for calculating the normalized time series deviation and the event state index are as follows: By combining the actual trigger time, the planned trigger time, and the average connection configuration or order-level basic scheduling interval of the corresponding action event, the dimensionless normalized timing deviation is calculated; wherein, the average connection configuration is the average value of the offset configuration of all preceding events of the current action event; The executable state of the device bound to the action event is combined with the preceding event of the corresponding action event, the normalized timing deviation, and the relative result deviation to calculate the event state index; wherein, the relative result deviation is calculated based on the absolute value of the relative deviation between the current result value and the target result value and the configured weight; the current result value comes from the real-time sampling of the weighing module and is written into the state table.

[0011] Preferably, the calculated key judgment value is generated based on the deviation intensity value, subsequent path length, maximum path length, and event state index, and is used to filter the set of affected events.

[0012] Preferably, the deviation intensity value is calculated and generated based on the normalized timing deviation, the relative result deviation term, the subsequent normalized base, and the set of direct successor events of the current action event, and is used to screen key collaborative control deviation events.

[0013] Preferably, the control strength is calculated based on multiplying the key judgment value by the corresponding first weight, the event state index, and the corresponding second weight; the control strength is used to determine the correction range of subsequent actions; The generation of compensation duration for result-driven action events specifically includes: The compensation duration is calculated by combining the control strength multiplier, the target result value of the source key event, the positive difference of the current result value, and the equivalent output rate of the device corresponding to the event to be adjusted.

[0014] A second aspect of the present invention provides a real-time collaborative control system for beverage equipment, the system comprising: The event chain generation module is used to obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online equipment from the equipment management module, expand each recipe step of the recipe template into an action event for a specific equipment action, and establish a set of preceding events and offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound equipment number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field; The status extraction module is used to collect the current execution status, actual trigger time, weighing result and equipment executable status of each action event during the execution of the collaborative event chain, so as to calculate the normalized timing deviation and event status index, and form the current order process status table. The deviation determination module is used to calculate the deviation intensity value of each action event based on the collaborative event chain and the current order process status table, and to calculate the key determination value by combining the successor path length from the current event to the end of the order and the event status index. Action events with key determination values ​​higher than the threshold are determined as key collaborative control deviation events, and the set of affected events is determined along the successor relationship. The local control module is used to backtrack to the most recent key collaborative control deviation event based on the incomplete action events in the affected event set, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time of time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

[0015] The beneficial technical effects of the present invention are at least as follows: This invention first combines recipe templates and equipment capabilities, expanding the single-cup beverage preparation process from coarse-grained steps into a collaborative event chain oriented towards specific equipment actions. This allows the actions of equipment such as robotic arms, ice makers, coffee machines, fructose machines, and weighing modules to be organized under unified pre- and post-constraints, waiting relationships, and result constraints. Then, it extracts the minimum necessary process states around this collaborative event chain, mapping the execution state of action events, current result values, and equipment executable states to an event-level structure. This enables the system to accurately represent the actual progress of the current order without introducing a large amount of irrelevant data. Furthermore, this invention does not simply interpret deviations as local anomalies of a single piece of equipment, but rather judges deviations within the context of the collaborative event chain. By combining event timing deviations, result deviations, and the degree to which subsequent actions are affected, it identifies the key collaborative control deviations that truly alter the subsequent production progress and clarifies their corresponding affected event ranges. Finally, for affected but not yet completed subsequent actions, this invention generates a real-time local collaborative control scheme for the current order, specifically correcting the trigger time, execution parameters, or compensation actions of subsequent actions, ensuring that pre-sequence deviations are promptly absorbed and repaired during the subsequent production process. Through the above design, the present invention upgrades the existing system from the execution mode of "driving equipment actions step by step" to the execution mode of "organizing the process according to events, judging deviations according to the process, and implementing local collaborative control according to subsequent actions". This enables multiple beverage equipment to maintain stable collaboration around the same order in production scenarios with short processes, strong coupling, and difficulty in backtracking. This more effectively solves the problems of insufficient real-time collaboration, inaccurate positioning of key deviations, and lagging compensation control in the background technology. Attached Figure Description

[0016] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0017] Figure 1 This is a flowchart of a real-time collaborative control method for beverage equipment according to the present invention. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] like Figure 1 As shown in the figure, an embodiment of the present invention provides a real-time collaborative control method for beverage equipment, the method comprising: S1. Obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online device from the device management module, expand each recipe step of the recipe template into an action event for a specific device action, and establish a set of preceding events and an offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound device number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field.

[0020] Specifically, for the current beverage order, the system first reads the corresponding recipe template from the recipe management module and the capability description of the currently online device from the device management module. Then, it merges the two into a collaborative event chain that can directly drive hardware execution. The recipe template, configured by the front-end recipe editing interface, is stored in the back-end database, typically using structured records. Each record includes at least the ingredient type, target addition order, target addition amount, and recommended execution device type. The device capability description is established during the device access phase, derived from serial port handshake results, the device registry, or driver configuration files. It indicates the set of actions a device can perform; for example, a robotic arm corresponds to grasping, moving, and releasing; a coffee machine corresponds to extraction start and extraction end; a fructose machine corresponds to sugar dispensing start and sugar dispensing stop; an ice maker corresponds to ice dispensing start and ice dispensing stop; and a weighing module corresponds to weight reading. After obtaining these two types of information, the system does not directly use coarse-grained steps like "add sugar," "add ice," and "add coffee." Instead, it expands each recipe step into action events that can be directly executed by the device driver layer. For example, "add syrup" is expanded into "fructose machine starts dispensing sugar," "fructose machine stops dispensing sugar," and "weighing module reads current weight." "Add coffee liquid" is expanded into "coffee machine starts extraction" and "coffee machine ends extraction." "Take cup and move to dispensing position" is expanded into "robotic arm grabs cup," "robotic arm moves to target position," and "robotic arm releases cup." Each action event is immediately bound to a specific device after expansion. The binding is based on the action matching relationship in the device capability table. For example, the action type "sugar dispensing start" is bound to the fructose machine, the action type "weight read" is bound to the weighing module, and the action type "cup movement" is bound to the robotic arm. When multiple similar devices exist, the system reads the current status of the devices and selects the device that is in an executable state and has the lowest current order occupancy to complete the binding. After this processing, each action event has an event number, action type, device number, and execution constraints. Subsequent timing organization can then be carried out directly at the device action level, instead of remaining at the recipe semantic level.

[0021] Understandably, during the event organization phase, the system, following the basic principle of pre- and post-constraint scheduling, establishes a set of preceding events for each action event and calculates the planned trigger time based on preset offsets between events. This calculation method originates from the earliest start time calculation method in operations research. In this scenario, it incorporates offset configurations from preceding events to the current event to meet equipment switching and process waiting requirements, thereby obtaining the planned trigger time of the current action event. ; in, This indicates the planned trigger time for action event e, which is written into the event node by the system when generating the collaborative event chain; The set of preceding events for action event e is derived from the recipe logic and equipment action constraints. For example, the preceding event for weighing and reading is that the fructose machine stops dispensing sugar, and the preceding event for the coffee machine to start extraction is that the robotic arm moves the cup to the coffee position. This indicates the completion time of the preceding event i. In the initial generation stage, it is taken from the expected completion time or the debugging configuration value in the recipe template. In the subsequent execution stage, it is replaced by the value returned by the device execution status. This represents the offset configuration from the preceding event i to the action event e. This configuration comes from the process waiting configuration in the recipe template or from on-site debugging records. For example, after sugar dispensing stops, a short interval is delayed before weighing; after releasing the cup, a short interval is delayed before starting the coffee machine. During implementation, the system maintains a preceding event list for each action event, storing the preceding event number and its corresponding offset configuration. When generating the event chain, the program iterates through each action event, reads its preceding event list, calculates the sum of the completion time of each preceding event and its corresponding offset configuration, and then takes the maximum value and writes it as the planned trigger time for the current action event. Taking an iced Americano with sugar as an example, if the "weighing and reading" event is only conditional on the preceding event "fructose dispenser stops dispensing sugar," the estimated completion time of this preceding event in the template is recorded as 12.0, and the corresponding offset configuration is recorded as 0.4. Therefore, the planned trigger time of "weighing and reading" is calculated to be 12.4. If "coffee machine starts extraction" is simultaneously constrained by two conditions: "robotic arm releases cup" and "coffee machine enters executable state," the completion times of these two preceding events are 5.2 and 5.6, respectively, and the corresponding offset configurations are 0.3 and 0, respectively. Therefore, the planned trigger time of "coffee machine starts extraction" is the larger value between 5.5 and 5.6, i.e., 5.6. After this calculation, both single-preceding-event scenarios and multi-preceding-event scenarios can be uniformly represented. The sequential relationships, waiting relationships, and device connection relationships between events are also solidified into the collaborative event chain itself. Subsequent steps only need to read the nodes and relationships in the event chain to directly enter the current process state extraction and key deviation determination.

[0022] Furthermore, the generated collaborative event chain is stored using a combination of node tables and relation tables. Each record in the node table corresponds to an action event and includes at least the event number, action type, bound device number, planned trigger time, number of preceding events, and result target value field. The result target value field records the target result of the action event in the current order. Action events with feeding or weighing constraints have their target value written in the recipe template, while action events without result constraints have 0 written. Each record in the relation table corresponds to a preceding constraint and includes at least the current event number, the preceding event number, and the offset configuration. Taking the same iced Americano with sugar order as an example, the node table can sequentially store action events such as "robotic arm grabs the cup," "robotic arm moves to the ice-making position," "ice maker starts dispensing ice," "ice maker stops dispensing ice," "robotic arm moves to the coffee position," "coffee machine starts extraction," "coffee machine finishes extraction," "fructose maker starts dispensing sugar," "fructose maker stops dispensing sugar," and "weighing and reading." Among these, action events like "fructose maker stops dispensing sugar" and "weighing and reading," which carry result constraints, have the target value corresponding to the current stage written in the result target value field, and are considered result-driven action events. Action events like "robotic arm moves to the coffee position" and "robotic arm grabs the cup," which do not carry result constraints, have 0 written in the result target value field, and are considered time-driven action events. The relationship table explicitly records that "robotic arm moves to the ice-making position" is conditional on the preceding event "robotic arm grabs the cup," "coffee machine starts extraction" is conditional on the preceding event "robotic arm moves to the coffee position," and "weighing and reading" is conditional on the preceding event "fructose maker stops dispensing sugar." Through this organizational method, the current beverage order is expressed within the system as a collaborative event chain that includes action events, device binding relationships, priority and waiting constraints, and result target values.

[0023] S2. During the execution of the collaborative event chain, the current execution status, actual trigger time, weighing result and equipment executable status of each action event are collected to calculate the normalized timing deviation and event status index, and to form the current order process status table.

[0024] Specifically, obtain the collaborative event chain output in step one. Each action event in the collaborative event chain already contains an event number, a bound device number, and a planned trigger time. Pre-event set And the offset configuration in the preceding relationships. During the execution phase, the system establishes an event status table for the order. Each record in the table corresponds to an action event in the event chain. The record content includes the current execution status, the actual trigger time, the weighing result, and the equipment executable status. The status table is initialized by copying from the event chain nodes. The execution status is initially recorded as not started, the actual trigger time is set to empty, the weighing result is set to the most recent sampled value for feeding-related events, and to zero for non-weighing-related events, and the equipment executable status is determined by the basic status returned by the current device driver and the completion status of the preceding events. During specific data acquisition, the system calls the corresponding driver according to the bound device number in the event chain: the fructose machine and coffee machine return the current running status word through serial port polling, the robotic arm returns the action completion flag through the control board, and the weighing module periodically returns the current weight reading through the serial port or the acquisition board. After parsing the original return frame, the driver layer writes the device status word, the action completion bit, and the weight reading into the status table record corresponding to the current action event.

[0025] For example, when the event chain reaches the "fructose dispenser starts dispensing sugar" event, the system reads the fructose dispenser status register in each polling cycle. If the status word indicates the sugar valve is open, the system records the event execution status as started and the first time this status is detected as the actual trigger time. When the status word indicates the valve is closed, the corresponding "fructose dispenser stops dispensing sugar" event is recorded as completed. For the "weighing read" event, the system writes the value received from the weighing module into the corresponding event's weighing result field each time. When the feeding action ends, the system retains the last stable sampled value of that stage as the weighing result for that event. In this way, the event status table always maintains a homogeneous relationship with the collaborative event chain, allowing subsequent judgments of any deviations to be directly traced back to the specific action event, rather than returning to coarse-grained formulation steps.

[0026] Furthermore, regarding the update of the state table, the system calculates the timing deviation at the event granularity. The original idea used here comes from the tracking error definition in control theory, namely "actual arrival amount minus target arrival amount." In this scenario, "actual arrival amount" and "target arrival amount" are specified as the actual trigger time of the action event and the planned trigger time already generated in step one, respectively. Considering the different number of preceding relationships between the first event and general events, the system first converts the number of preceding events into a unified normalized base, and then combines this with the order-level basic scheduling interval to obtain the normalized timing deviation of the action event: ; ; ; in, Indicates the pre-normalized cardinality of action event e; This represents the set of events preceding action event e; This indicates the average connection configuration of action event e; This represents the offset configuration from the preceding event i to the current event e, derived from the recipe template and action constraint configuration read during the generation of the event chain in step one. This represents the basic scheduling interval at the order level. This value comes from the scheduler configuration table and is used in scenarios where the first event or the preceding offset configuration is too small. This indicates the actual trigger time of action event e. This value is written to the status table when the system detects that the event status has first switched from never started to started. This indicates the planned trigger time written in the collaborative event chain in step one; This represents the normalized timing deviation of action event e. The derivation logic of this formula is to first use... The system obtains the raw timing error of the action event and then scales the error using the typical connection interval of the current event. When the current event has no preceding event, the system uses the order-level basic scheduling interval. As a normalization benchmark, the first event can also obtain a stable and comparable deviation value. Taking the "fructose dispenser stops discharging sugar" event as an example, if the planned trigger time generated in step one... The value is 12.0, but the event was actually detected and triggered on 12.6. The only preceding event, "Fructose dispenser starts dispensing sugar," has an offset configuration of 0.5. , After substituting, we get If "robotic arm grasps cup" is the first event without any preceding events, and the scheduler's configured basic scheduling interval... If the planned trigger time is 2.0 and the actual trigger time is 2.1, then... , ,get .

[0027] Furthermore, after the normalized timing deviation calculation is completed, the system continues to incorporate the weighing result and the equipment's executable state into the minimum necessary process state of the current order. The original idea used here comes from the readiness determination and quality deviation characterization in discrete event systems: whether an event can enter the executable state depends on whether its preceding events are completed and whether the bound equipment is in an executable state; whether an action event carrying a result constraint exhibits obvious abnormalities can be characterized by the relative deviation between the current result and the target result. Based on this idea, the system combines the preceding relationships of the event chain in step one, the currently updated execution state in step two, the current result, and the equipment's executable state into an event state index: ; ; in, The event state index represents the progress of action event e, used to comprehensively characterize the progress of the event in the current order; This indicates the executable state of the device to which the action event e is bound. It is set to 1 when the device driver returns to an idle or startable state, and to 0 when the device is in an occupied or abnormal state. This indicates the completion flag for the preceding event i. It is set to 1 when the corresponding record in the event status table is completed, and 0 otherwise. This represents the aforementioned pre-normalized cardinality; This represents the normalized timing bias calculated using the above formula; Indicates the relative deviation of the current action event from the outcome; This indicates the currently recorded result value of action event e, which comes from real-time sampling by the weighing module and is written to the status table; This indicates the target result value written in the target value field of the event node in step one. Action events that carry result constraints are written with the target value of the corresponding stage, and action events that do not carry result constraints are written with 0. This represents the preset stable value; and This represents the configuration weights for timing deviations and result deviations. These two parameters are written into the configuration table based on actual manufacturing experience during equipment commissioning. The derivation order of this formula is to first use... This indicates whether the event currently meets the conditions for proceeding. When an action event has no preceding events, this item automatically takes the value 1. Subtracting the timing deviation and result deviation items ensures the event status index simultaneously reflects "whether execution can continue" and "whether the current execution quality deviates from the target." Continuing with the "iced Americano with sugar" example, if the only preceding event for the "weighing and reading" event is "the fructose machine stops dispensing sugar," then the preceding event has already been completed. The prerequisite condition is 1; the weighing module returns the current result. The target result value in the node ,but If the weighing module of the bound device is currently executable, then If the event has already been calculated previously... And take the configuration weight , ,but If the current action event does not carry a result constraint, then the corresponding step in step one... Write it as 0, in the state table of step two. Keep it at 0, at this time The event state index is only affected by timing deviations and propagation conditions.

[0028] Furthermore, through the two-layer calculations described above, the system stably organizes the process state of the current order into a state table corresponding one-to-one with the event chain, based on the collaborative event chain generated in step one. For each action event, it generates an execution status, actual trigger time, normalized timing deviation, weighing result, and equipment executable status. This state table can be further stored using a node table expansion method, that is, adding execution status, actual trigger time, weighing result, normalized timing deviation, and event status index fields after the event node fields in step one. After each polling, the driver layer writes the new sampled values ​​into these fields, and the scheduling layer refreshes the equipment executable status of each event accordingly. In this way, the collaborative event chain output in step one is transformed into a unified structure of "collaborative event chain + current order process state" in this step. Subsequent steps directly read this structure, allowing for simultaneous judgment of timing and weight deviations at the event granularity, thereby locating key collaborative control deviations and determining the local adjustment methods for subsequent actions.

[0029] S3. Based on the collaborative event chain and the current order process status table, calculate the deviation intensity value of each action event, and combine the successor path length from the current event to the end of the order and the event status index to calculate the key judgment value. Action events with key judgment values ​​higher than the threshold are judged as key collaborative control deviation events, and the set of affected events is determined along the successor relationship.

[0030] Specifically, after generating the collaborative event chain in step one and forming the current order process status table and the set of executable statuses for event devices in step two, the system enters the critical collaborative control deviation determination stage. The input used at this stage remains completely consistent with the first two steps: the collaborative event chain already contains the preceding relationships for each action event. Successor relationship Plan trigger time and target weighing value The process status table already contains the actual trigger time of each action event. Normalized time series bias Weighing results and event status index The event device executable state set provides the executable state of the device bound to each action event at the current moment. The system establishes a deviation judgment table corresponding one-to-one with each node in the collaborative event chain based on these three types of inputs. The table includes at least the event number, deviation intensity value, critical judgment value, and the affected subsequent range. This organization is because the collaborative control of beverage equipment is not about scoring a single device, but about determining whether a particular action event has become a major obstacle to the progress of subsequent actions in the current order. Therefore, the judgment object must remain at the granularity of "action events in the collaborative event chain." In implementation, the system traverses all action events with execution statuses of "in execution" or "completed" according to the topological order of the collaborative event chain, reading the data for each event sequentially. , , , and its subsequent set of events For events that directly affect the recipe result, such as "the fructose machine stops dispensing sugar," "weighing and reading," and "the coffee machine finishes extraction," the system uses both timing information and weighing information. For events that directly affect the starting conditions of subsequent equipment, such as "the robotic arm moves to the ice-making position" and "the robotic arm moves to the coffee-making position," the system focuses on using timing information and the executable status of subsequent events. After this processing, all action events are still judged within the same calculation framework, but each type of action event can reflect its actual role in the beverage making scenario.

[0031] Understandably, the calculation of the deviation intensity value originates from the linear combination concept in multi-index weighted evaluation, and the propagation judgment concept in discrete event systems that "preceding anomalies will be reflected through subsequent ready states." The linear combination concept provides the basis for merging multiple normalized deviation quantities into a single evaluation quantity; the propagation judgment concept is used to incorporate the impact of the current action event on the execution conditions of subsequent actions into the deviation expression. In this scenario, step two has already calculated the normalized timing deviation by using the difference between the planned trigger time and the actual trigger time. Furthermore, the relative result deviation is obtained by comparing the target value and the current result value. Therefore, we directly use both as the main components of the deviation, and add a subsequent blocking term so that the deviation of the current action event not only reflects "how much it has deviated itself", but also "how much it has blocked what follows". The specific calculation formula is as follows: ; ; in, Represents the normalized cardinality of the successor to action event e; This represents the set of direct successor events to action event e, which comes from the event chain table generated in step one; The deviation intensity value represents the action event e, which is the first quantization result obtained in the current step; This represents the normalized timing bias obtained in step two; This indicates the relative deviation of the results obtained in step two; The device executable state of the subsequent action event j is derived from the event device executable state set output in step two. The weighting coefficients between timing deviations and result deviations are written into the configuration table during the equipment commissioning phase based on process sensitivity. This represents the weighting coefficient of the subsequent hindrance term, used to indicate the degree of influence of the current event deviation on the execution conditions of subsequent actions. The derivation order of this formula is first from... The contribution of timing bias is obtained, and then by The contribution of the result bias is obtained, and finally added. This subsequent blocking term is used to explicitly express the situation where "the current action event has made subsequent actions impossible to execute"; when the current action event has no subsequent events, The subsequent hindrance term is naturally set to 0. Taking the "fructose dispenser stops dispensing sugar" event in the "iced Americano with sugar" order as an example, if step two has already obtained the event... , Its two direct successor events are "weighing and reading" and "stirring". The former is currently executable, while the latter is temporarily unexecutable due to waiting for weighing confirmation. Therefore, the average value of the subsequent blocking term is ;Pick , Then there is This value indicates that the deviation of the current action event has reached the level of "significant deviation and subsequent progress has been affected", so it is necessary to proceed to the next level of critical judgment.

[0032] Furthermore, based on the deviation intensity value, the system further determines "which deviation events belong to the key collaborative control deviations in the current order." The underlying idea here comes from the residual path priority and risk propagation concepts in scheduling theory: deviations of the same magnitude, if occurring near the beginning of the order and with a longer subsequent chain, usually have a greater impact on the entire beverage; simultaneously, the event state index obtained in step two... This already reflects the overall progression of the current action event, so it can be used as a suppression term to guide the decision-making process to focus on events with "strong deviation, long propagation, and significantly deteriorated progression." Based on this logic, the system calculates the deviation intensity value for each action event. Based on this, and considering the remaining successor length of the current action event in the collaborative event chain, the key decision value is calculated. : ; in, This represents the critical decision value for action event e, which is the final value used in the current step to filter out critical collaborative control deviation events. This indicates the deviation strength value already calculated by the previous formula; This represents the length of the successor path between action event e and the last action event of the current order. This length is obtained by reading the collaborative event chain relationship table in step one and traversing layer by layer from the current node along the successor nodes. This represents the maximum path length in the current order collaboration event chain. This value can be calculated by the scheduling layer and written into the order context after the event chain is generated in step one. This represents the event state index calculated in step two. The higher the value, the closer the current action event is to a normal progress state. Substituting this value into... This will decrease the criticality of events with good progress, while increasing the criticality of events with significantly deteriorated progress. The construction logic of this formula is to first use... Express the magnitude of the deviation of the current action event itself, and then use Amplify its propagation potential throughout the entire order event chain, and finally use The degree of deterioration should be taken into account in the assessment. Continuing with the example of the aforementioned "fructose machine stopping dispensing sugar," if the event has already been... There are 4 more action events following it, and the maximum path length of the current order coordination event chain is 10, so the length factor is... If step two yields the event state index... The key decision value is Consider another event near the end of an order: "robotic arm returns to standby position," assuming it also has a high local deviation strength value. However, its successor length is only 1, and the current propulsion state index is... The key decision value is These two results indicate that although the former only has a slightly longer successor length and a greater degree of state deterioration than the latter, its criticality in the entire collaborative event chain is significantly higher, making it more suitable as a priority target for subsequent local collaborative control.

[0033] In terms of implementation process, the system performs two-level calculations for each candidate action event in the collaborative event chain: First, based on the normalized timing deviation, weighing result, and equipment executable status output in step two, and combined with the target result value and subsequent relationships in step one, the deviation intensity value is calculated. Then read the length of the successor path of the current action event. and the event state index in step two Calculate the key decision value Both levels of results are written to the deviation judgment table. After completing the traversal, the system will process all... Action events exceeding a threshold are added to the critical collaborative control deviation event set. Starting from these events, the process is repeated layer by layer along the successor relationships of the collaborative event chain until a node is encountered whose state has stabilized and is no longer affected by previous deviations. The intermediate nodes are then recorded as the affected event set. For example, if "the fructose machine stops dispensing sugar" is judged as a critical deviation event, its subsequent events such as "weighing and reading," "stirring," and "the robotic arm moving to the next station" may all enter the affected event set. If subsequent iterations find that the state index of "the robotic arm moving to the next station" has returned to the normal range, the propagation boundary ends there. This results in two outputs: one is the critical collaborative control deviation event set, and the other is the corresponding affected event set.

[0034] S4. Based on the action events that have not yet been completed in the set of affected events, backtrack to the most recent key collaborative control deviation event, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time for time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

[0035] Specifically, after obtaining the set of key collaborative control deviation events and the set of affected events in step three, the system directly maps these two results back to the node positions in the collaborative event chain, and generates real-time local collaborative control schemes for subsequent action events accordingly. The main processing line here is very clear: first, the action events that are still in the "not started" or "waiting" stage are screened out from the set of affected events to form a sequence of events to be adjusted; then, for each event to be adjusted, the upstream event is traced back along the predecessor relationship of the collaborative event chain to find the upstream event that is closest to the event to be adjusted and has been identified as a key collaborative control deviation event in step three, and is recorded as the source key event of the current event to be adjusted.

[0036] Understandably, this backtracking relationship is established using the event chain table created in step one. The program implementation simply requires reading the predecessor node list from memory by event number and traversing upwards until an event in the key collaborative control deviation event set is hit. After completing the backtracking, the system reads the key decision value calculated in step three for the source key event. And read the event status index of the event to be adjusted that was recorded in step two. ,in 'e' represents the source critical event, and 'e' represents the event to be adjusted. The reason for reading both values ​​simultaneously is because the source critical event... The propagation strength of the bias has already been reflected, while the current event to be adjusted... This already reflects the stability of the event's progress in the current order; only by combining these two quantities can we unify "how severe the upstream deviation is" and "how much adjustment space there is for this subsequent action" into a single control quantity. Based on this, the system uses a weighted combination method to generate the control strength of the event to be adjusted. This combination method originates from the weighted residual synthesis concept in classical control, that is, combining two indicators that have been normalized to the same scale with fixed weights into a single adjustment quantity. In this scenario, "source critical deviation" and "current progress margin" are further put into the same expression, thus obtaining a control strength that can be directly used for equipment action adjustment: ; in, This indicates the control strength of event e to be adjusted, and is a core quantity used when generating local cooperative control instructions in the current step. Indicates key events from the source The key judgment value comes from the deviation judgment table in step three; This represents the event status index of event e to be adjusted, and the value comes from the current order process status table in step two. This represents the weighting coefficient, which is written into the configuration table based on equipment type and process sensitivity during the joint debugging phase. The derivation of this formula involves first taking the key judgment values ​​obtained in step three... As the upstream deviation propagation intensity, then the value obtained in step two is used as the basis for further analysis. As the current event adjustable space, the two are then linearly synthesized into control strength according to the idea of ​​weighted residual synthesis. Taking an "Iced Americano with Sugar" order as an example, if the "fructose dispenser stops dispensing sugar" event in step three is identified as a key source event, and its key judgment value... The current event status index of the event "compensation for sugar" that needs adjustment Configuration during the joint debugging phase Then there is The system then writes the control strength into the control level table, and the scheduler selects the corresponding discrete adjustment level, and uses the timing correction step size or result compensation coefficient corresponding to that level for subsequent control.

[0037] Furthermore, in obtaining the control intensity The system then generates specific control commands based on the device type of the action event. For time-driven action events such as robotic arm movement, coffee machine start-up and extraction, and weighing and reading, which are primarily driven by the trigger moment, the system reads the planned trigger moment already written in step one from the event chain nodes. Then, the system reads the average connection configuration value recorded in the preconditions of step one for this event, and performs discrete level correction in the scheduler according to the control level table. Specifically, this is achieved by directly rewriting the trigger timestamp of the event in the priority queue. For result-driven action events such as sugar dispensing from a fructose machine and ice dispensing from an ice maker, which are primarily driven by result compensation, the system further adjusts the control intensity. This is mapped to the compensation duration. The original relationship used here comes from the most basic relationship in process control: "output quantity equals output rate multiplied by duration." After transformation, it becomes "compensation duration equals the difference in the result to be compensated divided by the equivalent output rate of the equipment." In this scenario, this is further multiplied by the control strength. This allows the actual compensation amount to change synchronously with the upstream deviation propagation intensity and the adjustable space of the current event. The system pre-records the equivalent output rate of each type of equipment under the current formula conditions in the equipment configuration file. This rate comes from the calibration results obtained through multiple actual measurements during equipment commissioning. At the same time, the result target value field has been written into the event node in step one, and the current result value has been written into the status table in step two. Therefore, the program can directly obtain the result difference of the source key event in memory.

[0038] The most direct criterion for distinguishing between time-driven and result-driven action events is to check whether the "result target value" of the action event in the collaborative event chain node is 0. If it is 0, it is time-driven; otherwise, it is result-driven. This design allows subsequent deviation determination and control correction to adopt the most appropriate adjustment strategy (time adjustment vs. dose compensation) for different types of actions.

[0039] It is important to note that, based on this existing data, the system calculates the compensation duration for outcome-driven events requiring adjustment: ; in, This indicates the duration of compensation for the action event e to be adjusted; This indicates the control strength obtained from the previous formula; Indicates key events from the source The target result value recorded in the target value field of the collaborative event chain node result; Indicates key events from the source The current result value recorded in the process status table in step two; This represents the equivalent output rate of the equipment corresponding to the event e to be adjusted under the current formula conditions. This value comes from the calibration configuration table formed during the equipment commissioning phase. The derivation of this formula begins with... The difference between the effective results not yet achieved from the source critical event is obtained. Then, the basic duration required to complete the compensation is calculated using the relationship "duration = target compensation / output rate" in process control. Finally, this is multiplied by the control strength. This ensures that the compensation amount is consistent with the key deviation determination result in step three and the current state margin of the event to be adjusted; when the source key event does not carry result constraints, or the current result value is already not lower than the target result value, the compensation amount in step one is adjusted accordingly. With the status table in step two This will cause the effective result difference to be 0, and the corresponding compensation duration will naturally be 0. In this case, the system retains the time-driven local adjustment and does not generate a result compensation action. Continuing with the aforementioned "iced Americano with sugar" order, if the target result value of the source key event "fructose machine stops dispensing sugar" is... Current result value If the effective result difference is 2, then the effective result difference is 2; for the event to be adjusted, "compensation for sugar output", if the equipment configuration table records the equivalent output rate of the fructose maker under the current formula conditions... The control intensity has already been calculated. Then the compensation duration The system then writes the compensation duration into the fructose machine's instruction parameter area and sends a sequence of instructions via serial port: "Start compensation sugar dispensing—Continue for specified duration—Stop sugar dispensing." Simultaneously, for the "weighing and reading" action in the affected event set, the scheduler moves the trigger time of the reading action forward by one scheduling step based on the event's own control level, ensuring that a new result value can be collected immediately after the compensation action is completed. Through this set of localized coordinated control, the new result value returned by the weighing module will be closer to the target result value in the coordinated event chain node. The event status indices corresponding to subsequent actions such as "stirring" and "robotic arm moving to the next station" will also rise accordingly, and the entire coordinated event chain returns to a stable progress state.

[0040] Furthermore, during program implementation, the system simultaneously loads the set of key collaborative control deviation events and the set of affected events output in step three, along with the collaborative event chain relationship table from step one and the current order process status table from step two, into the control scheduling module. The control scheduling module first performs backtracking of the source key events, and then calculates the control strength of each event to be adjusted. Subsequently, time correction instructions or result compensation instructions are generated according to the action event type. Time correction instructions are implemented by rewriting the trigger timestamp in the scheduling queue, while result compensation instructions are implemented by sending them to the corresponding beverage device through the device driver interface. After execution, the updated trigger time and compensation parameters are written back to the execution context of the current order as the basis for subsequent polling and re-determination. The two direct output results formed in this way are the updated subsequent action execution plan and the corresponding device control instruction set: the former is reflected in the fact that the trigger time and execution parameters of the relevant nodes in the collaborative event chain have been rewritten in real time, and the latter is reflected in the fact that the specific device has received the local control instructions corresponding to the current order and the current deviation.

[0041] This invention also provides a real-time collaborative control system for beverage equipment, the system comprising: The event chain generation module is used to obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online equipment from the equipment management module, expand each recipe step of the recipe template into an action event for a specific equipment action, and establish a set of preceding events and offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound equipment number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field; The status extraction module is used to collect the current execution status, actual trigger time, weighing result and equipment executable status of each action event during the execution of the collaborative event chain, so as to calculate the normalized timing deviation and event status index, and form the current order process status table. The deviation determination module is used to calculate the deviation intensity value of each action event based on the collaborative event chain and the current order process status table, and to calculate the key determination value by combining the successor path length from the current event to the end of the order and the event status index. Action events with key determination values ​​higher than the threshold are determined as key collaborative control deviation events, and the set of affected events is determined along the successor relationship. The local control module is used to backtrack to the most recent key collaborative control deviation event based on the incomplete action events in the affected event set, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time of time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

[0042] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0043] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or units may be electrical, mechanical, or other forms.

[0044] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0045] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for real-time collaborative control of beverage equipment, characterized in that, The method includes: S1. Obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online device from the device management module, expand each recipe step of the recipe template into an action event for a specific device action, and establish a set of preceding events and an offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound device number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field; S2. During the execution of the collaborative event chain, the current execution status, actual trigger time, weighing result and equipment executable status of each action event are collected to calculate the normalized timing deviation and event status index, and to form the current order process status table. S3. Based on the collaborative event chain and the current order process status table, calculate the deviation intensity value of each action event, and combine the successor path length from the current event to the end of the order and the event status index to calculate the key judgment value. Action events with key judgment values ​​higher than the threshold are judged as key collaborative control deviation events, and the set of affected events is determined along the successor relationship. S4. Based on the action events that have not yet been completed in the set of affected events, backtrack to the most recent key collaborative control deviation event, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time for time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

2. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, S1 further includes: After each recipe step of the recipe template is expanded into an action event for a specific device, the corresponding action event is immediately bound to the specific device, and the binding is based on the action matching relationship in the device capability table. When multiple similar devices exist, the system will read the current status of the devices and select the device that is in an executable state and has the lowest current order occupancy to complete the binding.

3. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, The specific steps for calculating the planned trigger time of the corresponding action event are as follows: For each preceding event of the current action event, add the completion time of the current preceding event to the offset configuration from the preceding event to the current event to obtain the preceding event calculation result. Take the maximum value among all the preceding event calculation results as the planned trigger time of the current action event.

4. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, The target value field is used to record the target result of the action event in the current order. Action events with feeding or weighing constraints are written to the target value in the recipe template, and action events without result constraints are written to 0. The collaborative event chain is stored using a combination of node tables and relationship tables. Each record in the node table corresponds to an action event. Each record in the relationship table corresponds to a prerequisite constraint, which includes at least the current event number, the prerequisite event number, and the offset configuration. The node table stores the action events sequentially.

5. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, In S2, during the execution of the collaborative event chain, an event status table is established for the current order. Each record in the event status table corresponds to an action event in the event chain, and the record content includes the current execution status, the actual trigger time, the weighing result, and the equipment's executable status. The initialization of the event status table comes from the replication of the event chain node. The execution status is initially recorded as not started, and is set to empty at the actual trigger time. The weighing result is set to the most recent sampled value for feeding-related events and to zero value for non-weighing-related events. The executable status of the equipment is jointly determined by the basic status returned by the current equipment driver and the completion status of the preceding events.

6. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, The specific steps for calculating the normalized time series deviation and the event state index are as follows: By combining the actual trigger time, the planned trigger time, and the average connection configuration or order-level basic scheduling interval of the corresponding action event, the dimensionless normalized timing deviation is calculated; wherein, the average connection configuration is the average value of the offset configuration of all preceding events of the current action event; The executable state of the device bound to the action event is combined with the preceding event of the corresponding action event, the normalized timing deviation, and the relative result deviation to calculate the event state index; wherein, the relative result deviation is calculated based on the absolute value of the relative deviation between the current result value and the target result value and the configured weight; the current result value comes from the real-time sampling of the weighing module and is written into the state table.

7. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, The calculated key judgment value is generated based on the deviation intensity value, subsequent path length, maximum path length, and event state index, and is used to filter the set of affected events.

8. The real-time collaborative control method for beverage equipment according to claim 7, characterized in that, The deviation intensity value is calculated based on the normalized timing deviation, the relative result deviation term, the subsequent normalized base, and the set of direct successor events of the current action event, and is used to screen key collaborative control deviation events.

9. The real-time collaborative control method for beverage equipment according to claim 1, characterized in that, The control strength is calculated based on multiplying the key judgment value by the corresponding first weight, the event state index, and the corresponding second weight; the control strength is used to determine the correction range of subsequent actions; The generation of compensation duration for result-driven action events specifically includes: The compensation duration is calculated by combining the control strength multiplier, the target result value of the source key event, the positive difference of the current result value, and the equivalent output rate of the device corresponding to the event to be adjusted.

10. A real-time collaborative control system for beverage equipment, characterized in that, The system includes: The event chain generation module is used to obtain the target beverage order, read the corresponding recipe template from the recipe management module and the capability description of the currently online equipment from the equipment management module, expand each recipe step of the recipe template into an action event for a specific equipment action, and establish a set of preceding events and offset configuration for each action event to calculate the planned trigger time of the corresponding action event and generate a collaborative event chain; wherein, each action event in the collaborative event chain includes an event number, a bound equipment number, a planned trigger time, a set of preceding events, an offset configuration in the preceding relationship, and a result target value field; The status extraction module is used to collect the current execution status, actual trigger time, weighing result and equipment executable status of each action event during the execution of the collaborative event chain, so as to calculate the normalized timing deviation and event status index, and form the current order process status table. The deviation determination module is used to calculate the deviation intensity value of each action event based on the collaborative event chain and the current order process status table, and to calculate the key determination value by combining the successor path length from the current event to the end of the order and the event status index. Action events with key determination values ​​higher than the threshold are determined as key collaborative control deviation events, and the set of affected events is determined along the successor relationship. The local control module is used to backtrack to the most recent key collaborative control deviation event based on the incomplete action events in the affected event set, generate the control intensity of the current action event to be adjusted according to the corresponding key judgment value and the current event state index; based on the control intensity, correct the trigger time of time-driven action events, generate compensation duration for result-driven action events, and issue local collaborative control instructions.

Images