Hazardous waste operation execution engine rule visualized arrangement method based on internet of things

Abstract

The application discloses a hazardous waste operation execution engine rule visual arrangement method based on Internet of Things, and particularly relates to the technical field of hazardous waste Internet of Things control, which is used for solving the defect of time sequence out of step caused by multi-protocol concurrent issuing and linkage action; through abstract syntax tree analysis on visual rule trigger instructions, concurrent control nodes and sub-actions are extracted, network access addresses and bottom layer communication protocol types are positioned in combination with target device identification codes, and delay scheduling and protocol release are implemented based on existing message empty frame number of protocol stack, gateway mainboard heat dissipation loss period, protocol analysis performance degradation coefficient, dynamic analysis delay, global synchronization reference time and reverse compensation waiting time difference, time delay attribute tags are written into metadata packet headers, and cross-node task stripping decisions are executed when the protocol analysis performance degradation coefficient exceeds a safety fuse threshold, and the sub-actions are redirected to a standby gateway in the same network segment.

Description

Technical Field

[0001] This invention relates to the field of hazardous waste Internet of Things (IoT) control technology, and more specifically, to a method for visualizing and orchestrating rules for hazardous waste operation execution engines based on the Internet of Things. Background Technology

[0002] With the profound evolution of IoT technology, the hazardous waste disposal industry is undergoing a comprehensive transformation towards automation and intelligence. In the hazardous waste operation execution phase, to lower the operational threshold and improve the efficiency of business collaboration, the industry commonly uses visual orchestration engines to define and distribute control rules for each operation node. Because hazardous waste treatment sites require the large-scale deployment of heterogeneous sensing and control equipment to monitor and intervene in different physical states, the underlying communication network must be compatible with multiple different industrial protocol standards. For example, the patent material "An IoT Business Processing System Based on a Multi-Protocol Instant Messaging System" (application number: CN105763426A) discloses a business scheduling system that converts diverse terminal requests into messages of a unified format through an underlying protocol parsing module before handing them over to an upper-layer engine for processing. While this architecture achieves initial access to heterogeneous IoT devices and visualized coordination of business processes in the software interface, its core mechanism remains at the level of static instruction format translation and unidirectional data routing and distribution.

[0003] However, directly applying the aforementioned general multi-protocol adaptation architecture to the dynamic physical closed loop of hazardous waste operations exposes a serious physical time lag defect between the underlying protocol parsing and the upper-layer rule execution. Due to the inherent latency differences in message assembly complexity, parsing mechanisms, and network handshake verification among different communication protocols, when the visual orchestration engine synchronously issues high-risk collaborative operation instructions to multiple related execution units at the software level, the underlying multi-protocol adapter inevitably experiences asymmetrical network processing latency when translating and issuing these heterogeneous instructions. This pure software code perspective of instruction concurrency evolves into highly dangerous asynchronous actions in the real physical space. In the absence of underlying protocol latency awareness and physical time compensation alignment mechanisms at hazardous waste sites, microsecond-level instruction time differences can lead to misaligned and logically contradictory execution sequences of critical mechanical actions such as leak prevention and sealing, and emergency ventilation and explosion prevention. This can easily trigger irreversible secondary environmental disasters such as high-pressure spraying of toxic chemicals or spatial deflagration of volatile gases, completely failing to meet the stringent control requirements of hard real-time synchronization and absolute physical safety at hazardous waste disposal industrial sites.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a method for visualizing and orchestrating rules for hazardous waste operation execution engines based on the Internet of Things. This method involves parsing the visualized rule triggering instructions using an abstract syntax tree to extract concurrent control nodes and sub-actions. It combines the target device identifier to determine the network access address and underlying communication protocol type. Furthermore, it implements delay scheduling and protocol release based on factors such as the number of existing message clearing frames in the protocol stack, the gateway motherboard heat dissipation degradation cycle, the protocol parsing performance degradation coefficient, dynamic parsing latency, global synchronization reference time, and reverse compensation waiting time difference. Simultaneously, it writes the time delay attribute label into the metadata header and executes a cross-node task stripping decision when the protocol parsing performance degradation coefficient exceeds the safety circuit breaker threshold, redirecting the sub-action to a backup gateway in the same network segment. This addresses the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: Step S1: Receive the visual rule triggering instruction and deserialize it to build an abstract syntax tree, extract the sub-actions within the concurrent control node, and determine the network access address and underlying communication protocol type of the sub-action based on the target device identifier code; Step S2: Send a status telemetry probe for the sub-action. Based on the number of existing message clearing frames in the protocol stack and the heat dissipation loss cycle of the gateway motherboard, obtain the protocol parsing performance degradation coefficient, dynamic parsing latency and global synchronization reference time. Step S3: Write the global synchronization reference time into the compensation calculation register, generate the reverse compensation waiting time difference for the sub-action, and write it into the header of the corresponding sub-action's metadata as a time delay attribute label. Step S4: Based on the time delay attribute label, push the sub-action into the kernel-level high-precision delay scheduling queue, and decrement the time through the clock countdown interception module. When the time reaches zero, unblock the queue and allow it to pass to the underlying multi-protocol adaptation module.

[0007] Furthermore, in step S1, the execution engine performs field segmentation and deserialization on the visual rule triggering instructions to obtain an ordered sequence of semantic fragments, and constructs an abstract syntax tree based on the preset syntax generation rules. Then, it traverses the hierarchical nodes from the root node downwards and selects nodes with parallel execution identifiers and at least two executable branches as concurrency control nodes.

[0008] Furthermore, in step S1, the execution engine extracts leaf nodes around the concurrent control node to form sub-actions, and extracts action tokens, control object tokens, process constraint tokens, time tag tokens and device name tokens in sequence from each sub-action. Then, it calls the device alias normalization table to convert the device name tokens into target device identifiers, and determines the network access address and underlying communication protocol type through the IoT device registry center and physical device mapping matrix.

[0009] Furthermore, in step S2, the status telemetry probe includes at least the channel index query content, buffer pool read / write position query content, pending instruction entry query content, underlying network interface net capacity query content, and main control chip core temperature sensing element query content. The execution engine reads the set of pending instruction entries according to the multi-protocol adaptation channel index, and after accumulating the effective payload bytes of all pending instructions, it calculates the number of existing message clearing frames in the protocol stack based on the single frame net payload bytes.

[0010] Furthermore, in step S2, the execution engine compares the reading of the core temperature sensing element of the main control chip with the optimal ambient reference temperature to obtain the net heat convergence value, and inputs the net heat convergence value into the physical thermal impedance mapping matrix to obtain the heat dissipation loss period of the gateway motherboard. Then, the number of existing message clearing frames in the protocol stack and the heat dissipation loss period of the gateway motherboard are written into the real-time state feature vector in a fixed component order, and input into the support vector machine classification model to obtain the protocol parsing performance degradation coefficient.

[0011] Furthermore, in step S2, the execution engine multiplies the protocol parsing performance degradation coefficient with the static time base in the protocol conversion inherent time ledger to obtain the dynamic parsing latency of each sub-action. When the protocol parsing performance degradation coefficient is higher than the security circuit breaker threshold, the engine performs a cross-node task stripping decision based on the expected parsing latency of the backup gateway in the same network segment. In other cases, the engine performs bubble sort on the dynamic parsing latency and extracts the maximum value as the global synchronization reference time.

[0012] Furthermore, in step S3, the execution engine allocates an independent compensation calculation register for each concurrent control node, writes the global synchronization reference time into the compensation calculation register, and reads the dynamic parsing delay corresponding to each sub-action item by item in a single calculation cycle. The dynamic parsing delay is subtracted from the global synchronization reference time to obtain the reverse compensation waiting time difference corresponding to each sub-action.

[0013] Furthermore, in step S3, the execution engine converts the reverse compensation waiting time difference into the number of discrete schedulers based on the basic scheduling time slice, and writes the original reverse compensation waiting time difference and the number of discrete schedulers together into the time delay attribute label. Then, the time delay attribute label is written as the first field of the metadata header into the corresponding sub-action, thereby forming a sub-action unit to be scheduled that includes the network access address, the underlying communication protocol type, and the multi-protocol adaptation channel index.

[0014] Furthermore, in step S4, the execution engine reads the discrete scheduling count from the time delay attribute label, copies the discrete scheduling count to the initial remaining count, pushes the scheduled sub-action units into the kernel-level high-precision delay scheduling queue, and then the clock countdown interception module performs a polling of the remaining count for all blocked and valid scheduled sub-action units when each basic scheduling time slice arrives.

[0015] Furthermore, in step S4, the clock countdown interception module uses the zero-trigger threshold as the release boundary. When the remaining count reaches the zero-trigger threshold and the zero-trigger lock bit is in an untriggered state, it generates a hardware-level interrupt signal and sequentially releases the blocking state of the scheduled sub-action unit, clears the queue occupants, reads the network access address, underlying communication protocol type, and multi-protocol adaptation channel index in the header of the metadata packet, and allows the sub-action to be passed to the corresponding multi-protocol adaptation module.

[0016] The technical effects and advantages of the present invention's IoT-based hazardous waste handling execution engine rule visualization and orchestration method are as follows: The beneficial effect of this invention lies in the fact that the processing link does not stop at the format conversion and sequential forwarding of multi-protocol instructions, but rather decomposes the visual rule triggering instructions into concurrent control nodes and sub-actions, and then implements each sub-action into the network access address, underlying communication protocol type, and multi-protocol adaptation channel index, so that the semantics of the rule layer, the state of the protocol layer, and the physical execution link form a continuous correspondence. Based on this object chain, the execution engine further introduces the number of existing message clearing frames in the protocol stack and the heat dissipation loss cycle of the gateway motherboard to perform linkage judgment on the protocol parsing capability, thereby obtaining the dynamic parsing latency and the global synchronization reference time, and the processing basis is no longer limited to single message backlog information.

[0017] Furthermore, this invention does not employ a crude approach of uniformly delaying or immediately issuing commands. Instead, it generates reverse compensation waiting time differences for different sub-actions based on a global synchronization reference time, and writes these reverse compensation waiting time differences into the time delay attribute tag. Then, it uses a kernel-level high-precision delay scheduling queue, a clock countdown interception module, and hardware-level interrupt signals to complete the blocking and release of each action sequentially. As a result, the originally dispersed parsing starting points between multiple protocol channels are recalculated to a unified protocol parsing completion time. When a local gateway enters a dangerous state, it can also connect cross-node task stripping decisions, giving the coordinated actions such as ventilation, sealing, and spraying at hazardous waste sites a more rigorous timing constraint relationship. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the IoT-based hazardous waste handling execution engine rule visualization and orchestration method of the present invention. Figure 2 This invention describes the process of parsing the visual rule-triggered instructions into an abstract syntax tree and identifying concurrent control nodes. Figure 3 This invention defines the mapping relationship between sub-actions and target devices, access addresses, protocol types, and channel indexes. Figure 4 This invention relates to protocol status telemetry, protocol parsing performance degradation assessment, and cross-node task stripping processes. Figure 5 This describes the process of generating the reverse compensation waiting time difference, discrete scheduler quantity, and time delay attribute labels for the present invention. Figure 6 This invention describes the timing process for achieving multi-protocol synchronous release after the scheduled sub-action is released by the delayed scheduling queue. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please see Figures 1-6 This invention provides a method for visualizing and orchestrating rules for a hazardous waste handling execution engine based on the Internet of Things, including: Step S1: Receive the visual rule triggering instruction and deserialize it to build an abstract syntax tree, extract the sub-actions within the concurrent control node, and determine the network access address and underlying communication protocol type of the sub-action based on the target device identifier code; Step S2: Send a status telemetry probe for the sub-action. Based on the number of existing message clearing frames in the protocol stack and the heat dissipation loss cycle of the gateway motherboard, obtain the protocol parsing performance degradation coefficient, dynamic parsing latency and global synchronization reference time. Step S3: Write the global synchronization reference time into the compensation calculation register, generate the reverse compensation waiting time difference for the sub-action, and write it into the header of the corresponding sub-action's metadata as a time delay attribute label. Step S4: Based on the time delay attribute label, push the sub-action into the kernel-level high-precision delay scheduling queue, and decrement the time through the clock countdown interception module. When the time reaches zero, unblock the queue and allow it to pass to the underlying multi-protocol adaptation module.

[0021] This invention takes the concurrent linkage rules at hazardous waste sites as the starting point for processing. First, it parses the visual rule triggering instructions into concurrent control nodes and sub-actions, and completes the assignment of the network access address and underlying communication protocol type of the target physical actuator. Then, it extracts the protocol congestion status and gateway hot status around the multi-protocol adaptation module corresponding to the sub-action, generates dynamic parsing delay and global synchronization reference time, and writes the reverse compensation waiting time difference for each sub-action according to the global synchronization reference time. Finally, it enters the delay scheduling link through the time delay attribute tag, and completes the blocking release and release under a unified time base.

[0022] Step S1 corresponds to the initial processing stage from the expression of visual rules to the expression of executable objects. The linkage control at hazardous waste sites does not directly issue commands to a single device. Instead, the front-end business layer first generates visual rule trigger commands with parallel relationships, process constraints, and device names. When these trigger commands enter the execution engine, they are still in a state of mixed and overlapping interface semantics, control semantics, and device names. Without first separating the concurrent relationships, sub-action boundaries, and unique device placement points layer by layer, the execution engine cannot distinguish which actions within the same linkage rule belong to the same concurrent control node, nor can it stably map device names to actual physical actuators. Therefore, step S1 undertakes the basic processing tasks of rule semantic deconstruction, object boundary definition, and device placement formation.

[0023] Step S1 includes the following: S101: Normalization of rule-triggered messages and determination of their valid structure.

[0024] After receiving a rule trigger message, the execution engine first reads the number of fields, field order, byte length of each field, and position of the check field recorded in the rule trigger message header. It then divides the rule trigger message into three parts: header, payload, and check field. Next, it adds the header byte count, the total payload field byte count, and the check field byte count, comparing each sum with the total byte count of the rule trigger message. If the sum of the three parts is exactly equal to the total byte count of the rule trigger message, the rule trigger message is considered structurally complete, indicating that the message boundaries are intact, no fields are missing, and field lengths are not misaligned, and it proceeds to deserialization. If the sum of the three parts is not equal to the total byte count of the rule trigger message, the rule trigger message is considered structurally incomplete, and subsequent parsing is not performed.

[0025] Deserialization means restoring a continuous byte stream into an ordered sequence of semantic fragments that can be directly recognized by semantic analysis. This ordered sequence of semantic fragments must contain at least control keywords, action keywords, logical relation words, time stamps, equipment designations, and process constraint words, maintaining the same order as the original sequence in the rule trigger message. In practice, the execution engine determines the position of the first byte of the payload according to the field length table recorded in the message header. Then, starting from the first byte, it continuously segments the data according to the field length, extracting the field content item by item, and finally restoring the field content into an ordered sequence of semantic fragments.

[0026] For example, when a leak occurs at the hazardous waste unloading station, the rule trigger message issued by the front-end business terminal may contain linkage instructions such as closing the reflux valve, turning on the exhaust fan, and releasing the spray head. After processing by this sub-step, the drag-and-drop relationship and compressed byte stream on the interface are no longer mixed, but are transformed into a sequence of ordered semantic fragments with a clear order, laying the foundation for subsequent tree-shaped semantic expansion.

[0027] S102: Abstract syntax tree construction and concurrent control node identification.

[0028] After an ordered sequence of semantic fragments is formed, the execution engine calls the pre-defined syntax generation rules to perform semantic merging and build an abstract syntax tree. The abstract syntax tree is a hierarchical semantic structure with the entire rule as the root node, the control relationship as the intermediate node, and the final executable action as the leaf node. With the help of this hierarchical structure, the sequence, branching, and parallel relationships in the front-end orchestration can be fixed.

[0029] When building the abstract syntax tree, the execution engine reads the content item by item in the original order of the ordered semantic fragment sequence. When it encounters a control keyword, it generates a control node; when it encounters an action keyword, it generates an execution node; when it encounters a logical relation word, it determines the node connection direction; when it encounters a time tag word, equipment name word, or process constraint word, it fills the attribute area of ​​the corresponding execution node until the entire rule is loaded into the abstract syntax tree.

[0030] In this embodiment, the preset syntax generation rules include at least the following rules: rule root node generation rules, condition node generation rules, sequence control node generation rules, concurrency control node generation rules, and execution node generation rules. The rule root node carries the entire visual rule, the condition node carries the triggering condition, the sequence control node connects subsequent execution nodes according to the order of the original semantic fragments, the concurrency control node carries two or more parallel execution branches, and the execution node carries action terms, control object terms, process constraint terms, time tag terms, and equipment name terms. The execution engine scans from left to right according to the ordered semantic fragment sequence. When it encounters a logical relation word indicating "simultaneously," "parallel," or "concurrent," it generates a concurrency control node. When it encounters a logical relation word indicating "then," "following," or "after completion," it generates a sequence control node. When it encounters an action keyword, it attaches an execution node under the current control node and writes the control object term, process constraint term, time tag term, and equipment name term adjacent to the action keyword into the attribute area of ​​that execution node.

[0031] For example, when the rule statement issued by the front-end business terminal is "When a leak alarm is triggered, simultaneously close the reflux valve, turn on the exhaust fan, and release the sprinkler heads," the execution engine first parses "when a leak alarm is triggered" into a condition node and "simultaneously" into a concurrent control node. Then, under the concurrent control node, it sequentially generates three execution nodes: "close the reflux valve," "turn on the exhaust fan," and "release the sprinkler heads." Each execution node contains corresponding action tokens, control object tokens, time tag tokens, and device name tokens. After the abstract syntax tree is built, the root node is first connected to the condition node, then to the concurrent control node, and the concurrent control node continues to connect to three execution leaf nodes. This uniquely determines the triggering condition, concurrency relationship, and action boundary of the rule.

[0032] After the abstract syntax tree is built, the execution engine traverses layer by layer from the root node. At each level node, it first checks whether the level node has a parallel execution flag, then checks whether the control category of the level node belongs to concurrent control, and finally checks whether the level node leads down to at least two branches that can fall into the executable leaf nodes. Only when the parallel execution flag is set, the control category belongs to concurrent control, and the number of executable branches is not less than two, is the level node recognized as a concurrent control node.

[0033] The threshold for the number of concurrent branches is fixed at two here. The logic for obtaining this threshold comes from the basic definition of concurrency. This is because there is no meaning to concurrent scheduling when there are fewer than two branches. Only when there are two or more executable branches at the same time is it necessary to continue to calculate the protocol parsing difference and the reverse compensation waiting time difference in subsequent steps.

[0034] For example, when a hazardous waste temporary storage area needs to simultaneously lower the sealing gate, turn on the exhaust fan, and close the conveying valve, the hierarchical node in the abstract syntax tree that contains these three action branches will be identified as a concurrent control node, while the hierarchical node that only derives a single action branch will not enter the scope of the concurrent control node.

[0035] S103: Sub-action extraction, atomic operation semantic expansion and target device identifier generation.

[0036] Once the concurrent control nodes are determined, the execution engine continues to expand downwards around each concurrent control node, extracting all executable actions that eventually stop at the leaf node positions to form a set of sub-actions. A sub-action is the smallest execution unit that can drive a target physical executor to complete a single control behavior with a single independent issuance, and no longer includes lower-level splitting space.

[0037] For each sub-action, the execution engine extracts five fixed semantic contents in a uniform order. These five fixed semantic contents are, in order: action terminology, control object terminology, process constraint terminology, time tag terminology, and equipment name terminology. Action terminology indicates control methods such as opening, closing, locking, and releasing; control object terminology indicates controlled objects such as fans, valves, gates, and sprinkler heads; process constraint terminology indicates process boundaries such as opening limits, interlocking limits, and preconditions; time tag terminology indicates the time attribute of immediate execution or execution after conditions are met; and equipment name terminology retains the field equipment names written by the front-end business logic.

[0038] After all five fixed semantic contents are extracted, the execution engine checks whether all semantic slots of each sub-action are complete. The complete threshold for semantic slots is fixed at all slots. The acquisition logic comes from the minimum completeness condition of the execution action. If any one of the following is missing: action method, control object, process constraint, time attribute, or equipment name, a unique mapping cannot be formed and the network positioning cannot continue.

[0039] When the semantic slots are complete, the execution engine calls the device alias unification table to uniformly convert device name terms into target device identifiers. The meaning of the device alias unification table is to map multiple names on site to a corresponding table of unique device codes. For example, if the North Exhaust Fan, Transfer Exhaust Fan, and Exhaust Fan No. 2 all point to the same physical actuator, after processing by the device alias unification table, they will all converge to the same target device identifier.

[0040] For example, if the linkage rule for the hazardous waste transfer station is to activate the north exhaust fan, the execution engine will not retain the field name "north exhaust fan" in this sub-step. Instead, it will check this name against the equipment alias unification table and output a unique target equipment identifier code. From this point on, subsequent steps will only revolve around the target equipment identifier code and will no longer backtrack to use the equipment name term.

[0041] S104: IoT device registry center query and physical device mapping matrix output.

[0042] After the target device identifier is generated, the execution engine calls the IoT device registry center for registration and querying. The IoT device registry center is a registration entity organized according to the unique device code, which stores at least the unique device code, device alias, installation region, network access address, underlying communication protocol type, and multi-protocol adaptation channel index. The execution engine uses the target device identifier as the search key to compare each line in the IoT device registry center, counting the number of registration lines that completely match the target device identifier.

[0043] The unique threshold for device mapping is fixed at one here. The acquisition logic comes from the field device registration rules. Because a physical actuator can only correspond to one unique device code, and a unique device code can only occupy one valid registration in the registry. If the number of hits is not one, it means that there is a duplicate or missing registration, and there is no subsequent placement condition. When the number of hits is exactly one, the execution engine determines the registration line number and reads the physical device mapping matrix based on this registration line number.

[0044] The physical device mapping matrix is ​​a two-dimensional mapping structure with the registration row number as the row index and the communication landing point parameters as the column content. The network access address identifies the access location of the target physical actuator in the communication network, the underlying communication protocol type indicates the type of communication protocol the target physical actuator adheres to, and the multi-protocol adaptation channel index indicates which multi-protocol adaptation processing link should be entered subsequently. Based on the registration row number, the execution engine sequentially retrieves the network access address, underlying communication protocol type, and multi-protocol adaptation channel index from the physical device mapping matrix and binds them one by one with the corresponding sub-actions.

[0045] For example, in a hazardous waste emergency containment scenario, the containment gate driver may be connected to a serial communication network, the exhaust fan inverter may be connected to an industrial Ethernet communication network, and the sprinkler head driver may be connected to another type of fieldbus. After processing by this sub-step, each sub-action will correspond to a unique network access address, a unique underlying communication protocol type, and a unique multi-protocol adaptation channel index. Based on this, step S2 can directly collect operating parameters from the corresponding multi-protocol adaptation module.

[0046] After step S1 is completed, the visual rule triggering instructions have been restored to concurrent control nodes and sub-actions in the abstract syntax tree. The device name has been converted into the target device identifier code and further implemented as the network access address and underlying communication protocol type. The linkage rules that were originally at the interface layer have been organized into a chain of execution objects with single-value correspondences. At this point, the execution engine is no longer faced with a jumble of rule descriptions, but rather a set of sub-actions and device mapping results with clear boundaries, explicit directions, and the ability to be processed item by item.

[0047] Step S2 corresponds to the core processing step of determining the protocol parsing state from the execution object's location. In hazardous waste sites, although exhaust fans, sealing valve groups, and spray actuators can be triggered simultaneously at the rule layer, different underlying communication protocols exhibit inconsistent performance in terms of buffer backlog, message payload transmission, and gateway motherboard temperature rise. This difference does not remain at the software layer but directly affects the order in which physical actions arrive. The target device identifier and network access address alone cannot reveal whether the current protocol channel has entered a parsing degradation state. Therefore, step S2 needs to extract software and hardware operating parameters around the multi-protocol adaptation module corresponding to the sub-action, incorporating the protocol congestion state and the gateway thermal state into the same judgment chain.

[0048] Step S2 includes the following: S201: Status telemetry probe issuance and operational status sampling and collection.

[0049] After the hazardous waste unloading position enters the linkage sealing stage, the execution engine first sends status telemetry probes to the corresponding underlying network interfaces one by one according to the multi-protocol adaptation channel index output in step S1. The status telemetry probes are used to read the internal operating status of the channel. Their message content is fixed and includes channel index query content, buffer pool read / write position query content, pending instruction item query content, underlying network interface net capacity query content, main control chip core temperature sensing element query content, and sampling time stamp query content. After receiving the status telemetry probes, the multi-protocol adaptation module returns all pending instruction items that have not yet been parsed and sent in the current channel, the number of effective payload bytes occupied by each pending instruction, the number of net payload bytes that each physical frame of the current underlying network interface can carry, the real-time temperature reading of the main control chip core temperature sensing element, and the parsing queue occupancy status. The execution engine then binds the returned results to the corresponding sub-actions one by one, so that the exhaust fan sub-action, sealing valve sub-action, and spray driver sub-action fall into their respective multi-protocol adaptation module status sets, without object overlap.

[0050] S202: Calculation of the number of frames cleared from the existing message stack and determination of the heat dissipation and wear period of the gateway motherboard.

[0051] After the hazardous waste linkage rules enter the concurrent waiting area, the multi-protocol adaptation module typically experiences an initial backlog of pending instructions, followed by a rise in gateway motherboard temperature. Therefore, the execution engine first reads the payload bytes of each pending instruction item returned by the status telemetry probe, and continuously accumulates the payload bytes of all pending instructions within the same channel to obtain the total volume of backlogged data. Then, it reads the net payload bytes that each physical frame of the current underlying network interface can carry, divides the total volume of backlogged data by the net payload bytes per frame, and if there is a remainder after division, it rounds up to the nearest integer number of frames, thus obtaining the number of existing message clearing frames in the protocol stack. The number of existing message clearing frames in the protocol stack here represents the minimum number of physical frames required to completely empty all backlogged data in the current channel. The reason for rounding up is that even if the last frame is not full, it still occupies a complete physical frame time slot.

[0052] After completing the protocol congestion state measurement, the execution engine continues to read the real-time temperature readings of the core temperature sensing element of the main control chip and compares them item by item with the preset optimal ambient reference temperature. The optimal ambient reference temperature is subtracted from the real-time temperature reading to obtain the net heat convergence value. After the net heat convergence value is formed, the execution engine inputs the net heat convergence value into the physical thermal impedance mapping matrix. The physical thermal impedance mapping matrix here is a two-dimensional calibration structure established through hot box loading test, motherboard heat flux measurement, and steady-state temperature recovery calibration. The horizontal content is different temperature rise nodes, and the vertical content is the equivalent heat dissipation time at the corresponding temperature rise node. When the net heat convergence value falls exactly on a certain temperature rise node, the execution engine directly reads the corresponding equivalent heat dissipation time as the gateway motherboard heat dissipation loss period. When the net heat convergence value falls between two adjacent temperature rise nodes, the execution engine reads these two adjacent temperature rise nodes and their corresponding two sets of equivalent heat dissipation times, and then calculates the median equivalent heat dissipation time according to the proportion of the net heat convergence value between the two temperature rise nodes, which is used as the gateway motherboard heat dissipation loss period. The gateway motherboard heat dissipation loss period here refers to the extra time the gateway motherboard takes to release the same amount of heat as the baseline thermal state under the current thermal condition. Its physical meaning is the time loss caused by the slowdown of the heat dissipation path.

[0053] For example, when the gateway on the north side of the hazardous waste temporary storage facility continuously undertakes the protocol parsing tasks of exhaust fan commands and sealing valve commands, the number of command entries to be processed gradually increases, the number of existing message clearing frames in the protocol stack increases accordingly, and after the temperature of the main control chip continues to rise, the heat dissipation failure cycle of the gateway motherboard also extends. At this time, the software backlog and the hardware temperature rise have been quantified simultaneously.

[0054] S203: Real-time state feature vector construction, cascade collapse critical hyperplane ranging and protocol parsing performance degradation coefficient generation.

[0055] When a protocol channel at a hazardous waste site is simultaneously subjected to congestion and temperature rise, neither factor alone is sufficient to accurately determine whether the protocol parsing capability has entered the collapse initiation zone. Therefore, the execution engine first queries the protocol baseline clearing frame count and protocol baseline heat dissipation cycle in the protocol baseline ledger based on the underlying communication protocol type. Then, it compares the number of existing message clearing frames in the protocol stack obtained in step S2 with the protocol baseline clearing frame count, and compares the gateway motherboard heat dissipation loss cycle with the protocol baseline heat dissipation cycle. This transforms the two originally different operating parameters into two dimensionless state components. Subsequently, the execution engine writes the protocol congestion component into the first position and the heat dissipation component into the second position in a fixed order, forming a real-time state feature vector.

[0056] In this embodiment, the support vector machine classification model adopts the linear support vector machine (Linear SVM) classification model, and an independent model is established for each underlying communication protocol type. Before model training, the execution engine continuously collects stable operation samples, congestion warning samples, and crash initiation samples for the corresponding protocol type under no-load, rated power supply, and baseline ambient temperature conditions. Among them, stable operation samples are taken from the operation interval where parsing is successful continuously and the parsing queue is not stalled; crash initiation samples are taken from the operation interval where continuous parsing timeout, continuous retransmission increase, or parsing queue stall occurs for the first time; and congestion warning samples are taken from the transition operation interval between the stable operation interval and the crash initiation interval. For each sample, the number of existing message clearing frames in the protocol stack and the gateway motherboard heat dissipation loss period at the corresponding time are recorded, and normalized by the protocol channel baseline clearing frame number and protocol channel baseline heat dissipation period for that protocol type, respectively, to form a two-dimensional sample feature vector containing protocol congestion components and heat dissipation components.

[0057] During model training, the execution engine marks stable running samples as stable-side samples, collapse initiation samples as dangerous-side samples, and uses congestion warning samples as boundary verification samples input into the training process to verify whether the boundary falls between the stable running interval and the collapse initiation interval. After the Linear SVM is trained, a linear discriminant hyperplane is obtained that separates stable-side samples from dangerous-side samples; this linear discriminant hyperplane is the cascade collapse critical hyperplane referred to in this specification. After the model parameters are fixed, the execution engine uniformly sets the normal direction of the hyperplane to point from the dangerous side to the stable side, so that after the current real-time state feature vector is input into the model, the signed normal distance from the current state point to the cascade collapse critical hyperplane can be directly output; when the signed normal distance is positive, it indicates that the state point is on the stable side; when the signed normal distance is zero, it indicates that the state point is on the critical boundary; when the signed normal distance is negative, it indicates that the state point has entered the dangerous side.

[0058] After the signed normal distance is generated, the execution engine does not directly use fuzzy empirical values. Instead, it calls a pre-calibrated distance-degradation coefficient mapping table to obtain the protocol parsing performance degradation coefficient. This mapping table is established separately for each type of underlying communication protocol. The input of the mapping table is the signed normal distance, and the output is the dimensionless degradation ratio. When establishing the mapping table, the execution engine divides the signed normal distance into stable intervals, critical transition intervals, and danger intervals according to the offline calibration results, and records the corresponding degradation ratio range in each interval. During runtime, the execution engine first determines the interval in which the current signed normal distance falls, and then reads the corresponding degradation ratio for that interval. If the current signed normal distance falls within an interval, it performs linear interpolation according to the degradation ratios corresponding to the upper and lower boundaries of that interval to obtain the current protocol parsing performance degradation coefficient. Therefore, the closer the state point is to the danger side, the larger the output protocol parsing performance degradation coefficient is; when the state point is at the critical boundary, the protocol parsing performance degradation coefficient takes the boundary value; after the state point enters the danger side, the protocol parsing performance degradation coefficient is higher than the boundary value.

[0059] The safety circuit breaker threshold is a dangerous initial boundary value that is separately calibrated and stored for each underlying communication protocol type. It is obtained as follows: Under the same underlying communication protocol type, while maintaining consistent power supply and environmental conditions, the message backlog is gradually increased in a stepped manner while simultaneously raising the motherboard temperature. The real-time state feature vector, signed normal distance, and protocol parsing performance degradation coefficient are continuously recorded for each test level. When a certain test level first experiences continuous parsing timeouts, increased retransmissions, or parsing queue stagnation, the protocol parsing performance degradation coefficient corresponding to that test level is recorded as the dangerous initial coefficient. This process is repeated for all dangerous initial samples of the same protocol type, and the smallest dangerous initial coefficient is taken as the safety circuit breaker threshold corresponding to that protocol type.

[0060] When the protocol parsing performance degradation coefficient corresponding to the current sub-action exceeds the security circuit breaker threshold, the execution engine suspends the current parsing queue and triggers a cross-node task stripping decision. The cross-node task stripping decision is handled as follows: first, backup gateways capable of handling the same underlying communication protocol type are selected from the backup gateway registration table in the same network segment; then, similar status telemetry probes are sent to these backup gateways to calculate their expected parsing time; finally, the backup gateway with the shortest expected parsing time is selected, and the current sub-action is migrated to the corresponding backup gateway parsing link; if the protocol parsing performance degradation coefficient corresponding to the current sub-action does not exceed the security circuit breaker threshold, the current multi-protocol adaptation module is retained to continue undertaking the parsing task.

[0061] For example, during a hazardous waste leak, a large number of pending instructions have accumulated in the channel corresponding to the exhaust fan, and the temperature of the gateway motherboard continues to rise. The state point given by the support vector machine classification model is approaching the danger side. If the protocol parsing performance degradation coefficient exceeds the safety circuit breaker threshold at this time, the execution engine will no longer allow this channel to continue to handle parsing, but will reassign the exhaust fan sub-action to the backup gateway in the same network segment. Therefore, the linkage link will not be interrupted in the local channel.

[0062] S204: Dynamically analyze latency generation and filter global synchronization reference time.

[0063] When the channel where the current sub-action is located has not triggered cross-node task stripping, or has already completed backup gateway redirection, the execution engine queries the corresponding static time base in the protocol conversion inherent time ledger based on the underlying communication protocol type that actually undertakes the parsing task. The protocol conversion inherent time ledger here is a baseline table established through offline calibration, used to record the baseline time consumed by various underlying communication protocols under no-load, rated power supply, and baseline ambient temperature conditions, from message format reassembly, protocol field verification to the instruction issuance preparation stage.

[0064] After the static latency base is read, the execution engine uses the protocol parsing performance degradation coefficient as the degradation rate and multiplies it with the static latency base to obtain the dynamic parsing latency.

[0065] Under the same concurrent control node, there are often multiple sub-actions. After the dynamic resolution delays for all sub-actions are generated, the execution engine writes these dynamic resolution delays into a sorted sequence and uses bubble sort to compare adjacent values ​​round by round, swapping positions from largest to smallest, until the first value of the sequence stabilizes at its maximum value. Then, the first value is extracted as the global synchronization base time. The global synchronization base time here represents the maximum dynamic resolution delay corresponding to all sub-actions under the same concurrent control node at the current moment.

[0066] For example, in the hazardous waste leakage linkage, the dynamic analysis delay of the exhaust fan sub-action is the longest, while the dynamic analysis delay of the sealing valve sub-action and the spray drive sub-action is relatively shorter. After the bubble sort is completed, the dynamic analysis delay corresponding to the exhaust fan sub-action will remain at the beginning of the sequence. Based on this, the execution engine determines this longest dynamic analysis delay as the global synchronization reference time. Step S3 then calculates the reverse compensation waiting time difference for other sub-actions around this global synchronization reference time.

[0067] After step S2 is completed, each sub-action obtains the number of existing message clearing frames in the protocol stack, the gateway motherboard heat dissipation loss period, the protocol parsing performance degradation coefficient, and the dynamic parsing latency. The same concurrent control node simultaneously obtains the global synchronization reference time. If a local channel has reached the safety circuit breaker boundary, the cross-node task stripping decision is also completed within this step. After this processing, the execution engine possesses a set of sub-actions with parsing load status and time difference quantification results, rather than simply a static device control object.

[0068] Step S3 corresponds to the conversion process from parsing time difference to assigning compensation time. The linkage rules at the hazardous waste site require multiple physical actuators to complete their actions within the same hazardous disposal window. However, the dynamic parsing delay obtained in step S2 reveals that different sub-actions take different amounts of time in the protocol parsing link. If these sub-actions are directly sent to the scheduling link, the protocol channel with faster parsing will arrive at the physical actuator first, while the protocol channel with slower parsing will arrive later. The timing consistency of the linkage actions still cannot be achieved. Therefore, step S3 needs to calculate the reverse compensation waiting time difference for each sub-action based on the global synchronization reference time.

[0069] Step S3 includes the following: S301: Compensation calculation register allocation and global synchronization reference time fixation.

[0070] When the hazardous waste unloading position enters the linkage sealing stage, the execution engine first allocates compensation calculation registers one by one according to the concurrent control nodes. Each compensation calculation register is used by only one concurrent control node and is not shared with other concurrent control nodes in the same single calculation cycle. It is only allowed to be released after all sub-actions in the current concurrent control node have completed the reverse compensation waiting time difference assignment. The purpose of the compensation calculation register is to save the global synchronization reference time that has been screened in step S2 to a single storage location, so that the subsequent loop traversal thread always calculates the difference around the same time reference in the entire compensation calculation process, and no longer repeatedly accesses the dynamic parsing delay sorting result area.

[0071] After the execution engine completes the allocation of the compensation calculation register, it immediately pushes the global synchronization reference time corresponding to the current concurrent control node into the compensation calculation register and keeps it locked. Thereafter, within a single calculation cycle of the current concurrent control node, the compensation calculation register always stores the same global synchronization reference time. For example, when the hazardous waste temporary storage facility simultaneously performs ventilation, sealing, and sprinkler linkage, if the dynamic resolution delay corresponding to the ventilation fan action is the longest, then the compensation calculation register stores this longest time. The subsequent actions of the sealing valve and the sprinkler drive will calculate their respective compensation waiting amounts around this time reference.

[0072] S302: Loop through the threads to calculate the reverse compensation waiting time difference item by item.

[0073] After the compensation calculation register completes the global synchronization reference time fixation, the execution engine starts a loop traversal thread to read the dynamically parsed delay item by item according to the existing storage order of the sub-actions inside the current concurrent control node, and completes the reverse compensation waiting time difference calculation for all sub-actions within the same single calculation cycle; a single calculation cycle here refers to the complete processing interval from the first sub-action in the current concurrent control node to the completion of the compensation time calculation for the last sub-action.

[0074] After reading the dynamic parsing delay of a certain sub-action, the execution engine calls the arithmetic logic unit to use the global synchronization reference time stored in the compensation calculation register as a unified time reference. Then, it subtracts the dynamic parsing delay of the current sub-action from this unified time reference to obtain the reverse compensation waiting time difference corresponding to the current sub-action. Since the global synchronization reference time comes from the maximum value of all dynamic parsing delays within the same concurrent control node, the dynamic parsing delay of any sub-action will not exceed the global synchronization reference time. Therefore, the obtained reverse compensation waiting time difference will only have two cases: one is that the current sub-action itself is the slowest parsing channel, and the corresponding reverse compensation waiting time difference is zero; the other is that the parsing speed of the current sub-action is faster than that of the slowest parsing channel, and the corresponding reverse compensation waiting time difference is positive.

[0075] The execution engine does not change the dynamic resolution latency of each sub-action itself. Instead, before entering the resolution process, it makes the sub-actions that resolve faster wait for an additional reverse compensation waiting time difference before entering their respective resolution links. This allows the faster and slower sub-actions to converge at the same time point at the protocol resolution completion point. For example, during the linkage sealing of the hazardous waste transfer station, the exhaust fan sub-action resolves the slowest, while the sealing valve sub-action and the spray actuator sub-action resolve faster. Therefore, the exhaust fan sub-action does not wait, while the sealing valve sub-action and the spray actuator sub-action wait for their respective reverse compensation waiting time differences before entering their respective protocol resolution links. All three will eventually align at the same protocol resolution completion point.

[0076] S303: Basic scheduling time slice selection, non-zero holding threshold setting and discrete scheduling count conversion.

[0077] The reverse compensation waiting time difference exists as a continuous time value in the arithmetic logic unit, while the high-precision delay scheduling queue in step S4 uses a discrete countdown polling method. Therefore, after obtaining the reverse compensation waiting time difference, the execution engine continues to select the basic scheduling time slice. The basic scheduling time slice is the smallest schedulable time unit used by all subsequent delay scheduling actions. It is obtained by comparing the output clock tick of the high-frequency clock oscillator with the minimum time slice of the operating environment, and selecting the one with the longer time span as the basic scheduling time slice. The reason for adopting this selection method is that if the time unit is smaller than the minimum time slice of the operating environment, it cannot be scheduled for execution; if the time unit is smaller than the output clock tick of the high-frequency clock oscillator, it cannot be stably counted. Therefore, the basic scheduling time slice must be subject to both of these constraints simultaneously.

[0078] After the basic scheduling time slice is determined, the execution engine continues to set the non-zero holding threshold. The non-zero holding threshold is fixed at one basic scheduling time slice. Its function is to stipulate that any reverse compensation waiting time difference greater than zero must occupy at least one discrete scheduling count after discretization, and cannot be erased to zero value during the counting conversion because the compensation time is too short.

[0079] Subsequently, the execution engine converts the reverse compensation waiting time difference of each sub-action into the number of discrete schedulers. The specific processing is divided into three cases: First, the reverse compensation waiting time difference is equal to zero, in which case the number of discrete schedulers is directly written as zero, indicating that the slowest parsing channel does not need to wait. Second, the reverse compensation waiting time difference is greater than zero but does not exceed the non-zero holding threshold, in which case the number of discrete schedulers is fixed at one, indicating that although the waiting time is less than a complete basic scheduling time slice, it still needs to occupy a minimum scheduling unit in step S4. Third, the reverse compensation waiting time difference exceeds the non-zero holding threshold, in which case the execution engine divides the reverse compensation waiting time difference by the basic scheduling time slice to obtain the corresponding number of time slices, and then rounds the result up to the nearest integer number of schedulers, serving as the direct basis for subsequent high-precision delay scheduling queue decrementing polling.

[0080] This conversion relationship is neither an empirical correction nor a fuzzy conversion, but rather a strict projection of continuous time values ​​onto a unified discrete time base, so that step S4 can be reduced piece by piece according to integer counts; for example, the action of the blocking valve only requires a very short waiting time, but after conversion it still occupies at least one discrete timer, while if the action of the spray drive requires a longer waiting time, it will be converted into multiple discrete timers.

[0081] S304: Generation of time delay attribute labels and writing of metadata headers.

[0082] Once the reverse compensation waiting time difference and the number of discrete schedulers have been generated, the execution engine begins to construct a time delay attribute label for the current sub-action. The time delay attribute label adopts a two-field structure, where the first field stores the original reverse compensation waiting time difference and the second field stores the number of discrete schedulers. The significance of this field layout is that, on the one hand, the original time value is preserved, which is convenient for subsequent readback, verification and log tracking, and on the other hand, the number of discrete schedulers is directly provided, which makes it convenient for step S4 to implement countdown polling without recalculation.

[0083] After the time delay attribute label is generated, the execution engine continues to construct the metadata header. The metadata header is written with content in a fixed field order: the first field contains the time delay attribute label, the second field inherits the network access address, the third field inherits the underlying communication protocol type, and the fourth field inherits the multi-protocol adaptation channel index. After writing, the sub-action and the metadata header together form a sub-action unit to be scheduled. The sub-action unit to be scheduled here represents the smallest scheduling object that already carries the time delay attribute label, network access address, underlying communication protocol type, and multi-protocol adaptation channel index, and can be directly received by the high-precision delay scheduling queue in step S4.

[0084] Before the end of the same single calculation cycle, the execution engine completes the above writing for all sub-actions in the current concurrent control node one by one, so that each sub-action has a unique reverse compensation waiting time difference and a unique discrete scheduling count; for example, in a hazardous waste leak site, the sealing valve sub-action will write a set of positive time delay attribute tags, the spray drive sub-action will write another set of positive time delay attribute tags, and the exhaust fan sub-action will write zero time delay attribute tags. Although the three can enter the high-precision delay scheduling queue at the same time, the time point of subsequent unblocking will be re-aligned due to the different time delay attribute tags.

[0085] After step S3 is completed, the global synchronization reference time has been written into the compensation calculation register. Each sub-action generates a corresponding reverse compensation waiting time difference, which is further converted into a time delay attribute label and written into the header of the metadata packet. At this point, the sub-action is no longer just a parsed object with dynamic resolution delay, but has been transformed into a scheduled sub-action unit carrying network access address, underlying communication protocol type, multi-protocol adaptation channel index, and time delay attribute label. The compensation information changes from calculation result to executable scheduling attribute.

[0086] Step S4 corresponds to the final execution stage of physical release control, from assigning compensation attribute values. What truly needs to be controlled at the hazardous waste site is not the time difference at the field level, but rather when the scheduled sub-action unit is unblocked and enters the multi-protocol adaptation module. Although step S3 has written the reverse compensation waiting time difference into the time delay attribute tag, as long as these tags have not been placed into the countdown mechanism under the unified time base, the compensation amount remains at the recording level and has not yet been transformed into actual action constraints. Therefore, step S4 needs to load the scheduled sub-action unit into the kernel-level high-precision delay scheduling queue and complete the zeroing judgment and release trigger under the unified polling of the clock countdown interception module.

[0087] S401: Loading of scheduled sub-action units and initialization of kernel-level high-precision delayed scheduling queue.

[0088] After the hazardous waste unloading site linkage sealing enters the pre-instruction stage, the execution engine first reads the header of the metadata data packet of each scheduled sub-action unit, and extracts the time delay attribute label, network access address, underlying communication protocol type and multi-protocol adaptation channel index according to a fixed field order. The time delay attribute label continues to maintain a two-field structure. The first field stores the reverse compensation waiting time difference, and the second field stores the discrete scheduling count. The execution engine takes out the discrete scheduling count from the second field and directly copies this discrete scheduling count as the initial remaining count. Then, the sub-action, initial remaining count, network access address, underlying communication protocol type, multi-protocol adaptation channel index, blocking flag and zero-trigger lock bit are loaded together as queue elements and pushed into the kernel-level high-precision delay scheduling queue one by one.

[0089] The kernel-level high-precision delay scheduling queue is a delay storage container residing in kernel mode, storing only scheduled sub-action units whose compensation wait has not yet been exhausted. The initial remaining count is exactly the same as the discrete scheduling count, representing all waiting shares that have not been consumed when the scheduled sub-action unit is enqueued. The blocking flag is written as blocked valid at the moment of enqueuing, indicating that the scheduled sub-action unit can only stay in the kernel-level high-precision delay scheduling queue and cannot directly enter the multi-protocol adaptation module. The zero-triggered lock bit is written as untriggered at the moment of enqueuing, used to subsequently restrict the same scheduled sub-action unit to trigger a release action only once.

[0090] To maintain order among multiple scheduled sub-action units with varying waiting times within the same queue, the execution engine first establishes a primary sort based on the number of discrete schedulers, and then a secondary sort based on the order of entry. Thus, sub-action units with fewer discrete schedulers are placed earlier, while those with the same number of discrete schedulers are arranged according to their entry order. Taking a hazardous waste leak site as an example, the exhaust fan sub-action might carry zero discrete schedulers, while the sealing valve sub-action and the spray actuator sub-action each carry positive discrete schedulers. Although all three are initially blocked after entering the queue, a clear initial waiting pattern has already formed within the queue.

[0091] S402: The clock countdown interception module is bound to the remaining count and decreases synchronously.

[0092] After all scheduled sub-action units have entered the kernel-level high-precision delay scheduling queue, the execution engine starts the clock countdown interception module and establishes a one-to-one clock count binding relationship between the clock countdown interception module and the high-frequency clock oscillator. Here, the clock countdown interception module is an execution unit that uses the kernel clock interrupt as its trigger source and the decrementing and zeroing detection of the remaining count as its core tasks. Each time it receives a clock count output from the high-frequency clock oscillator, it performs a synchronous polling of all blocked and valid scheduled sub-action units in the kernel-level high-precision delay scheduling queue.

[0093] During each polling process, the clock countdown interception module reads the remaining count of the currently scheduled sub-action unit. If the remaining count is greater than zero, it subtracts one discrete count unit from the remaining count. If the remaining count is already equal to zero, it remains at zero and does not continue to deduct, thus ensuring that the remaining count remains at zero or in a positive range throughout the entire polling process, without becoming negative. The decrementing logic here is very clear: the execution engine does not directly deduct the original time difference for reverse compensation waiting, but rather consumes the remaining count piece by piece around the basic scheduling time slice, based on the discrete scheduling count calculated in step S3.

[0094] The discrete release waiting time is determined by the number of discrete schedulers and the basic scheduling time slice. Specifically, one discrete scheduler corresponds to one basic scheduling time slice, two discrete schedulers correspond to two basic scheduling time slices, and so on. Therefore, the actual waiting length of the scheduled sub-action unit in the queue is not an empirical estimate or a vague amplification, but rather obtained by multiplying the number of discrete schedulers by the basic scheduling time slice. Taking the hazardous waste transfer station's linked sealing as an example, if the sealing valve sub-action occupies two discrete schedulers and the spray actuator sub-action occupies three discrete schedulers, the clock countdown interception module deducts one value synchronously every time a basic scheduling time slice has elapsed. The sealing valve sub-action will reach the zero value boundary before the spray actuator sub-action.

[0095] S403: Zero-trigger threshold determination, zero-trigger locking, and hardware-level interrupt signal generation.

[0096] The key node in the delayed scheduling link for hazardous waste linkage actions is when the remaining count is considered to be completely exhausted. Therefore, after each polling, the clock countdown interception module continues to perform release judgments around the zero-trigger threshold. The zero-trigger threshold is fixed at zero in this step, and the acquisition logic is directly derived from the state boundary definition of the discrete countdown structure. Since the remaining count represents the unconsumed waiting share, as long as the remaining count is still greater than zero, it means that the compensation waiting has not been completed. Only when the remaining count is reduced to zero can it be said that the scheduled sub-action unit has met the release conditions.

[0097] After each poll, the execution engine first checks whether the remaining count has reached the zero-trigger threshold. If the remaining count is greater than the zero-trigger threshold, the release decision is to maintain the blocked state, and the waiting scheduling sub-action unit continues to stay in the kernel-level high-precision delay scheduling queue to participate in the next poll. If the remaining count is equal to the zero-trigger threshold, the release decision is changed to meet the release condition.

[0098] To prevent the same scheduled sub-action unit from triggering multiple interrupts consecutively during its zero-value dwell period, the execution engine continues to check the zero-trigger lock bit. The zero-trigger lock bit here is a single-value control bit that records whether the scheduled sub-action unit has completed its first zero-trigger. It is in an untriggered state when enqueued, and is immediately changed to a triggered state after the first zero-trigger and interrupt generation. The execution engine only generates a hardware-level interrupt signal when two conditions are met simultaneously: the first condition is that the remaining count has reached the zero-trigger threshold, and the second condition is that the zero-trigger lock bit is still in an untriggered state.

[0099] The hardware-level interrupt signal here is directly sent to the interrupt control link by the clock countdown interception module to initiate level-triggered events for blocking release and queue popping. Once the hardware-level interrupt signal is generated, the zero-triggered lock bit is synchronously rewritten to the triggered state, thereby shielding all possible repeated interrupts for the same scheduled sub-action unit. Taking a hazardous waste leak site as an example, if the exhaust fan sub-action has a zero discrete scheduling count at the moment of entry, the release condition can be met and a hardware-level interrupt signal will be triggered after the first poll; the sealing valve sub-action and the spray actuator sub-action will each trigger an interrupt at the polling node when their respective remaining counts are reduced to zero, and will not be released repeatedly.

[0100] S404: Blocking is released, queue popped, and multi-protocol adaptation module is allowed.

[0101] When a hardware-level interrupt signal is generated, the interrupt handling link immediately performs blocking release, queue popping, and forwarding on the corresponding scheduled sub-action unit. The execution order is fixed as follows: first, rewrite the blocking flag, then clear the queue placeholder, and finally read the network access address, underlying communication protocol type, and multi-protocol adaptation channel index in the fixed field order in the metadata header, and send the sub-action to the corresponding multi-protocol adaptation module.

[0102] The read relationship here corresponds exactly to the write relationship in step S3. Step S3 writes the network access address, underlying communication protocol type, and multi-protocol adaptation channel index into the metadata header according to a fixed field order. Step S4 reads the data item by item according to the same field order, so there is no field drift or object mismatch. Once the scheduled sub-action unit is popped from the kernel-level high-precision delay scheduling queue, it will no longer participate in subsequent polling, and its blocked state will no longer be retained.

[0103] From a temporal perspective, the scheduled sub-action unit has already experienced a discrete release waiting time in the queue, determined by the number of discrete schedulers and the basic scheduling time slice. It will then experience the dynamic resolution delay generated in step S2. Therefore, the actual completion time of protocol resolution is formed by the continuous superposition of these two time periods. Furthermore, since step S3 uses an upward rounding method when converting the reverse compensation waiting time difference into the number of discrete schedulers, the discrete release waiting time will not be shorter than the reverse compensation waiting time difference. There may be a discrete compensation residual between them, not exceeding one basic scheduling time slice. This discrete compensation residual is the minimum remaining time difference naturally present in the discrete scheduling link, and its range is strictly limited to within one basic scheduling time slice. Therefore, it will not disrupt the synchronization target of the hazardous waste site linkage action.

[0104] After the scheduling sub-action unit completes its pop-up, the multi-protocol adaptation module performs message format reassembly and parsing based on the underlying communication protocol type, and then sends the control command to the target physical actuator based on the network access address. Taking hazardous waste leakage disposal as an example, the exhaust fan sub-action may be popped up first and enter the corresponding protocol parsing link, while the sealing valve sub-action and the spray actuator sub-action will enter the parsing link successively after their respective waiting times have expired. Although the polling times for unblocking the three are different, after the combined effect of discrete release waiting time and dynamic parsing delay, they will complete protocol parsing and reach the actual physical actuator within the same hazardous disposal window.

[0105] After step S4 is completed, the time delay attribute label has been confirmed as the actual queue blocking duration and release boundary. The sub-action unit to be scheduled decrements the remaining count in the kernel-level high-precision delay scheduling queue. When the zero-trigger threshold is met, the block is released by a hardware-level interrupt signal and the unit is popped from the queue. Subsequently, it enters the corresponding multi-protocol adaptation module based on the network access address, underlying communication protocol type, and multi-protocol adaptation channel index in the metadata header. At this point, the coordinated actions at the hazardous waste site, from rule arrangement, protocol identification, compensation assignment to physical release, form a complete closed loop.

[0106] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for visualizing and orchestrating rules for a hazardous waste handling execution engine based on the Internet of Things, characterized in that, Including the following steps: Step S1: Receive the visual rule triggering instruction and deserialize it to build an abstract syntax tree, extract the sub-actions within the concurrent control node, and determine the network access address and underlying communication protocol type of the sub-action based on the target device identifier code; Step S2: Send a status telemetry probe for the sub-action. Based on the number of existing message clearing frames in the protocol stack and the heat dissipation loss cycle of the gateway motherboard, obtain the protocol parsing performance degradation coefficient, dynamic parsing latency and global synchronization reference time. Step S3: Write the global synchronization reference time into the compensation calculation register, generate the reverse compensation waiting time difference for the sub-action, and write it into the header of the corresponding sub-action's metadata as a time delay attribute label. Step S4: Based on the time delay attribute label, push the sub-action into the kernel-level high-precision delay scheduling queue, and decrement the time through the clock countdown interception module. When the time reaches zero, unblock the queue and allow it to pass to the underlying multi-protocol adaptation module.

2. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 1, characterized in that, In step S1, the execution engine performs field segmentation and deserialization on the visual rule triggering command to obtain an ordered sequence of semantic fragments. It then constructs an abstract syntax tree based on the preset syntax generation rules, and traverses the hierarchical nodes from the root node downwards to select nodes with parallel execution identifiers and at least two executable branches as concurrency control nodes.

3. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 2, characterized in that, In step S1, the execution engine extracts leaf nodes around the concurrent control node to form sub-actions, and extracts action tokens, control object tokens, process constraint tokens, time tag tokens and device name tokens from each sub-action in sequence. Then, it calls the device alias normalization table to convert the device name tokens into target device identifiers, and determines the network access address and underlying communication protocol type through the IoT device registry center and physical device mapping matrix.

4. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 1, characterized in that, In step S2, the status telemetry probe includes at least the channel index query content, buffer pool read / write position query content, pending instruction entry query content, underlying network interface net capacity query content, and main control chip core temperature sensing element query content. The execution engine reads the set of pending instruction entries according to the multi-protocol adaptation channel index, and after accumulating the effective payload bytes of all pending instructions, it calculates the number of existing message clearing frames in the protocol stack based on the single frame net payload bytes.

5. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 4, characterized in that, In step S2, the execution engine compares the reading of the core temperature sensing element of the main control chip with the optimal ambient reference temperature to obtain the net heat convergence value, and inputs the net heat convergence value into the physical thermal impedance mapping matrix to obtain the heat dissipation loss period of the gateway motherboard. Then, the number of existing message clearing frames in the protocol stack and the heat dissipation loss period of the gateway motherboard are written into the real-time state feature vector in a fixed component order, and input into the support vector machine classification model to obtain the protocol parsing performance degradation coefficient.

6. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 5, characterized in that, In step S2, the execution engine multiplies the protocol parsing performance degradation coefficient with the static time base in the protocol conversion inherent time ledger to obtain the dynamic parsing latency of each sub-action. When the protocol parsing performance degradation coefficient is higher than the security circuit breaker threshold, the engine performs a cross-node task stripping decision based on the expected parsing latency of the backup gateway in the same network segment. In other cases, the engine performs bubble sort on the dynamic parsing latency and extracts the maximum value as the global synchronization reference time.

7. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 1, characterized in that, In step S3, the execution engine allocates an independent compensation calculation register for each concurrent control node, writes the global synchronization reference time into the compensation calculation register, and reads the dynamic parsing delay corresponding to each sub-action in a single calculation cycle. The dynamic parsing delay is subtracted from the global synchronization reference time to obtain the reverse compensation waiting time difference corresponding to each sub-action.

8. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 7, characterized in that, In step S3, the execution engine converts the reverse compensation waiting time difference into the number of discrete schedulers based on the basic scheduling time slice, and writes the original reverse compensation waiting time difference and the number of discrete schedulers into the time delay attribute label. Then, the time delay attribute label is written as the first field of the metadata header into the corresponding sub-action, thereby forming a sub-action unit to be scheduled that includes the network access address, the underlying communication protocol type, and the multi-protocol adaptation channel index.

9. The method for visualizing and orchestrating rules of an IoT-based hazardous waste handling execution engine according to claim 1, characterized in that, In step S4, the execution engine reads the discrete scheduling count from the time delay attribute label, copies the discrete scheduling count to the initial remaining count, pushes the scheduled sub-action units into the kernel-level high-precision delay scheduling queue, and then the clock countdown interception module performs a polling of the remaining count for all blocked and valid scheduled sub-action units when each basic scheduling time slice arrives.

10. The IoT-based hazardous waste operation execution engine rule visualization and orchestration method according to claim 9, characterized in that, In step S4, the clock countdown interception module uses the zero-trigger threshold as the release boundary. When the remaining count reaches the zero-trigger threshold and the zero-trigger lock bit is in an untriggered state, it generates a hardware-level interrupt signal and sequentially releases the blocking state of the scheduled sub-action unit, clears the queue occupants, reads the network access address, underlying communication protocol type, and multi-protocol adaptation channel index in the header of the metadata packet, and allows the sub-action to be passed to the corresponding multi-protocol adaptation module.

Images