A low-latency streaming data transmission scheduling method and system for industrial simulation

Abstract

The application discloses a low-latency streaming media data transmission scheduling method and system for industrial simulation, and particularly relates to the technical field of industrial simulation data transmission, and is used for solving the problem that in the industrial simulation data transmission, the related state cannot be submitted on time due to the fact that the state dependence is not satisfied in time, and further affecting the transmission of the subsequent irrelevant state. By forming an independent state unit and an incremental state unit according to a simulation step and establishing a dependence account book, a submission support boundary is formed in combination with a receiving end submission version, a reserved state and a slot remaining time, and then unreachable cuts, invalid domains, recovery closures and recovery boundaries are determined, and transmission unit sending qualification is controlled, so that the state affected by the dependence exception is limited in the invalid domain, and the state satisfying the condition outside the invalid domain is continuously sent, thereby reducing the influence of the local dependence failure on the transmission of the subsequent irrelevant state.

Description

Technical Field

[0001] This invention relates to the field of industrial simulation data transmission technology, specifically to a low-latency streaming media data transmission scheduling method and system for industrial simulation. Background Technology

[0002] Industrial simulation systems require the transmission of status data for multiple simulated objects between the sending and receiving ends during virtual debugging, remote simulation, or equipment status linkage, following a continuous simulation step. To reduce the amount of data transmitted in continuous state updates, existing systems typically employ a combination of complete and incremental state updates. Complete object states are transmitted only at certain times, while fields showing changes relative to previous states are transmitted at other times. The state update order is maintained using timestamps, sequence numbers, or object identifiers. Upon receiving the corresponding state, the receiving end restores the object state and updates the current simulation state according to a predetermined sequence. In the event of short-term network jitter, congestion, or delayed data arrival, state continuity is typically maintained through buffering, retransmission, delayed submission, or retransmission of a more complete state.

[0003] However, in industrial simulation scenarios where multiple object states have dependencies on previous or cross-object states, the degree of dependence of different state data on previous states varies. When a preceding state fails to arrive or complete its update at the receiving end within the corresponding time limit due to network transmission delays, subsequent incremental states that have already arrived, even if the data itself is complete, may not be directly usable due to the lack of the preceding state required for recovery. Existing methods of retransmission and recovery based on sending order, buffering order, or uniform timeout conditions often fail to further distinguish between subsequent states actually affected by the missing state and other states without corresponding dependencies. This can easily cause states that could still be transmitted or updated to wait, or trigger a large-scale retransmission of states.

[0004] Furthermore, when network-available transmission time is limited, the transmission time required for different combinations of recovery data varies. If transmission continues only according to the original queue order, the current state update time may expire before the required recovery data is fully transmitted. Conversely, directly expanding the retransmission range would further consume transmission resources for subsequent state data. Therefore, it is necessary to address how to limit the actual range of affected states during continuous transmission of industrial simulation states, and how to maintain a reasonable connection between the recovery of relevant states and other transmittable states within a limited transmission period, when some dependent states cannot be met in a timely manner. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a low-latency streaming media data transmission scheduling method and system for industrial simulation, thereby solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a low-latency streaming media data transmission scheduling method for industrial simulation, comprising: S1. According to the simulation steps, the state is formed into independent state units and incremental state units, and written to the object, version, predecessor dependency, cross-object dependency, and commit slot to establish a dependency ledger. S2. Determine the submission support boundaries based on the version submitted by the receiving end, the retention status, and the remaining time of the slot; S3. Track unmet dependencies outside the submission support boundary, calculate the duration based on the amount of dependency data, queue occupancy, and link rate; when the remaining time of the slot is exceeded, determine the unreachable segment and form a failure domain along the subsequent dependencies; S4. Starting from the simulation step after the unreachable cut, take candidate boundaries in sequence and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is longer than the duration of the independent state unit, replace the segment with the independent state unit to form a recovery closure. Take the first candidate boundary whose duration does not exceed the remaining time of the slot as the recovery boundary. S5. Freeze the unrecovered transmission units within the failure domain and write the recovery closure into the recovery queue; after inserting a transmission unit outside the failure domain, the transmission unit obtains the qualification to send when the recovery closure occupies no more than the remaining time of the recovery boundary slot. S6. The receiving end verifies and restores the integrity of the closure, accepts the dependencies, commits, and returns the record; the sending end updates the commit support boundary and releases subsequent transmission units based on the closure commit version.

[0007] Furthermore, S1 includes: The prerequisite dependencies of the independent state unit are empty; The incremental state unit's preceding dependency is taken from the state unit in the same object whose simulation step identifier is smaller than the current simulation step, is closest to the current simulation step, and has been completed. If there are multiple revision versions of the simulation step, the state unit version with the largest revision number is taken. The state unit version is determined by the simulation task identifier, simulation step identifier, object identifier, and revision number. Existing dependencies will not change due to subsequent revisions. Cross-object dependencies are determined by the state representation relationship in the locking model configuration, and circular references are checked level by level before writing.

[0008] Furthermore, S2 includes: The receiving end submits a version associated with the state unit version used by each simulation object; The reserved state is a state unit version where the receiver can read the complete object state; The submission support boundary includes the set of supported state unit versions, the remaining time record of the submission slot, and the correspondence between independent state unit replacements; If the preceding dependency version is the version of the end state unit of the original incremental dependency segment in the corresponding relationship and is not in the set of supported state unit versions, and the corresponding independent state unit version is in the set, then the preceding dependency is considered to have been committed and supported by the boundary.

[0009] Furthermore, S3 includes: The same transmission record layer caliber is used depending on the amount of data, queue usage, and link speed. The link rate is the ratio of the number of valid bytes initially acknowledged by the receiver within the rate acknowledgment interval to the interval duration, and the duration occupied is the ratio of the sum of dependent data and queue occupancy to the link rate. State units whose duration exceeds the remaining time of the slot are considered out-of-limit state units. The first submission slot containing an out-of-limit state unit is obtained in ascending order of submission slots. All out-of-limit state unit versions within it constitute an unreachable point, which forms a failure domain along subsequent dependencies.

[0010] Furthermore, S4 includes: Candidate boundaries are obtained incrementally according to the simulation steps after the unreachable cut, and missing dependencies are filled in backwards along the preceding dependencies and cross-object dependencies; An incremental dependency segment is the longest continuous sequence of state units for the same object that is connected along the preceding dependency, consists entirely of incremental state units, and has not reached the state position that has been submitted and supported. Candidate independent state units are formed from the solidified complete object state of the same object and the same simulation step as the end state unit of the segment.

[0011] Furthermore, the duration of the incremental dependency segment is determined by the ratio of the number of unacknowledged bytes of the actual deletable state unit after the segment is deleted to the link rate. The duration of an independent state unit is determined by the ratio of the amount of new bytes to be transmitted generated by candidate independent state units and cross-object dependencies to the same link rate. Replacement is performed when the duration of the incremental dependency segment exceeds the duration of the independent state unit. After all incremental dependency segments are judged, a recovery closure is formed. The candidate boundary whose first recovery closure occupies a duration that does not exceed the remaining time of the slot is taken as the recovery boundary.

[0012] Furthermore, S5 includes: The frozen transmission unit retains the status unit version, submitted slot, remaining bytes for which a complete transmission arrival confirmation has not yet been obtained from the receiving side, and the original queuing record, and cancels its eligibility to be directly selected from the normal transmission queue; The recovery queue is arranged according to the dependency relationship of the recovery closure, and multiple arrangeable transmission units are selected in the order of submission slot, object identifier and status unit version. Failed external transmission units are inserted sequentially. After insertion, the transmission qualification is obtained when the recovery closure occupancy time does not exceed the remaining time of the recovery boundary slot at the qualification determination time.

[0013] Furthermore, S6 includes: The receiving end verifies the integrity of the recovery closure based on the state unit version set and the length of the complete record, and verifies the dependency inheritance according to the recovery queue order. When the pending state of the objects involved in the recovery closure is fully formed and the task time is earlier than the deadline of the recovery boundary commit slot, a unified switch is made to form the closure commit version, and the independent state unit is locked to replace the corresponding relationship. The sending end updates the commit support boundary based on the returned record, and only releases the commit slots that are later than the recovery boundary commit slots and all rely on the frozen transmission units that have been taken over by the commit support boundary.

[0014] On the other hand, the present invention provides a low-latency streaming media data transmission scheduling system for industrial simulation, comprising: The dependency ledger creation module is used to form independent state units and incremental state units according to the simulation steps, write them to objects, versions, predecessor dependencies, cross-object dependencies, and commit slots, and create a dependency ledger. The submission support boundary determination module is used to determine the submission support boundary based on the submission version, retention status, and remaining slot time from the receiving end. The failure domain determination module is used to track unmet dependencies outside the submission support boundary. It calculates the duration of occupancy based on the amount of dependency data, queue occupancy, and link rate. When the occupancy time exceeds the remaining time of the slot, it determines the unreachable point and forms a failure domain along the subsequent dependencies. The recovery boundary determination module is used to sequentially obtain candidate boundaries from the simulation steps after the unreachable cut and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is greater than the duration of the independent state unit, the incremental dependency segment is replaced with the independent state unit to form a recovery closure. The candidate boundary whose duration of the first recovery closure does not exceed the remaining time of the slot is determined as the recovery boundary. The transmission qualification scheduling module is used to freeze the unrecovered transmission units within the failure domain, write the recovery closure into the recovery queue, and enable the transmission unit outside the failure domain to obtain transmission qualification when the recovery closure occupancy time after inserting the transmission unit outside the failure domain does not exceed the remaining time of the recovery boundary slot. The commit write-back module is used by the receiving end to verify and restore the integrity of the closure and the acceptance of dependencies, commit and return the record, and the sending end to update the commit support boundary and release subsequent transmission units based on the closure commit version.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By forming independent state units and incremental state units according to the simulation steps, and writing the object, state unit version, prior dependency, cross-object dependency, and commit slot into the dependency ledger, and then combining the actual commit version, retention state, and remaining slot time of the receiver to form a commit support boundary, based on the transmission occupancy of unmet dependencies, unreachable cut-off points and failure domains are determined, and further recovery closures, recovery boundaries, and corresponding transmission qualifications are formed. This ensures that state transmission, dependency judgment, recovery organization, and receiver commit are continuously connected according to the actual dependency relationship and commit time limit. Thus, when some state dependencies cannot be met in time, the affected states are restricted to the corresponding failure domains, and states outside the failure domain that still have the conditions for transmission can continue to participate in transmission, reducing the impact of a single dependency anomaly on the subsequent unrelated state transmission process.

[0016] 2. By sequentially forming candidate boundaries from the simulation steps after the unreachable cut, missing dependencies that have not yet been accepted by the submitted support boundary are filled in backwards. The occupancy time of continuous incremental dependency segments is compared with that of independent state units that can restore the same object state. When the replacement condition is met, the corresponding incremental dependency segment is replaced by an independent state unit. Then, the dependency closure check is performed on the formed recovery closure, and the first candidate boundary whose occupancy time does not exceed the remaining time of the slot is selected as the recovery boundary. This allows the state required for recovery to be organized according to the actual dependency relationship and the current available transmission time, reducing the occupation of the recovery period by incremental dependency content that no longer needs to be transmitted, and avoiding the existence of dependency states that cannot be accepted after the recovery closure is formed.

[0017] 3. By using read-only or incremental records for state unit versions, dependency ledgers, commit support boundaries, recovery boundaries, and closure commit versions respectively, and by performing integrity checks, dependency acceptance, and overall state switching on the recovery closure at the receiving end to form the closure commit version, the independent state unit replacement correspondence is then preserved along with the new commit support boundary. This ensures that completed state commits, historical versions, and replacement acceptance relationships are not overwritten in situ during subsequent recovery processes. Based on this, the sending end only unfreezes the subsequent transmission units that have obtained acceptance from the new commit support boundary, thereby maintaining the continuity of state versions and dependency acceptance relationships before and after recovery, and providing traceable version and dependency basis for subsequent state transmission judgments. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the overall process for scheduling low-latency streaming media data transmission for industrial simulation. Figure 2 This is a schematic diagram of the functional structure of a low-latency streaming media data transmission scheduling system; Figure 3 This is a schematic diagram illustrating the formation of state units and their dependencies on ledger records. Figure 4To provide a schematic diagram of the formation of support boundaries and the determination of dependencies; Figure 5 This diagram illustrates the determination of unreachable cuts and the expansion of the failure domain. Figure 6 A schematic diagram illustrating the determination of candidate boundaries, incremental dependency segment replacement, and recovery boundaries; Figure 7 This diagram illustrates the process of freezing and restoring the queue in the failed domain and determining the eligibility to send data. Figure 8 A diagram illustrating the restoration of closure integrity, dependency acceptance, and unified commit. 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] Example 1: Combined with Appendix Figures 1-8 This embodiment provides a low-latency streaming media data transmission scheduling method for industrial simulation, including: S1. According to the simulation steps, the state is formed into independent state units and incremental state units, and written to the object, version, predecessor dependency, cross-object dependency, and commit slot to establish a dependency ledger. The specific implementation is as follows: After the industrial simulation server completes the state calculation for the current simulation step and sets the state of this step to a completed state that cannot be modified further, it collects the states of each simulation object according to the simulation step and forms independent state units and incremental state units respectively.

[0021] A simulation step is a state update interval that is continuously advanced according to a predetermined step sequence for the same industrial simulation task. Each simulation step has a unique simulation step identifier within the task. This step reads the object state that has been fixed at the end position of the simulation step, and does not read the temporary state that can still change during the calculation of the current simulation step.

[0022] The state source is the state record of the object in this step saved by the industrial simulation server; in the implementation of the simulation driven by the state of the field equipment, only the state record of the equipment that has been included in the current simulation step before entering this step is read, and the state value is not re-interpolated, filtered or changed in this step.

[0023] Each simulation object has a unique object identifier within the current simulation task. The names, engineering units, storage precision, and fixed order of the fields to be transmitted are determined according to the list of state fields corresponding to the identifier in the current model configuration. Continuous numerical fields maintain the engineering units and storage precision specified for that field, while discrete fields are recorded according to the fixed enumeration values ​​in the model configuration. When discussing the fixed order of object identifiers later, the order of the object list locked before the industrial simulation task starts will be uniformly adopted. When comparing the state unit versions of the same object, the order will be determined by incrementing the simulation step identifier and then the revision number. Submission slots will be determined according to the slot advancement order in the locking timing configuration, and subsequent steps will not change this order.

[0024] The model configuration identifier only indicates the source of field configuration used when forming state units, and is not considered as the state unit version in this application.

[0025] If the field name, engineering unit, storage precision, or sorting order is missing, it can be filled in from the currently locked model configuration. The actual state value must not be filled in based on the previous simulation step, the next simulation step, or the state of other objects. If the actual state value is missing, exceeds the field value range allowed by the current model configuration, or cannot be determined to belong to an object, the formation of the state unit of that object in the current simulation step will be stopped and a record to be verified will be formed.

[0026] For the current object, its state unit type is determined according to the independent state formation interval predetermined in this simulation task. The first transferable simulation step after the task starts, the simulation step that reaches the boundary of the independent state formation interval, and the simulation step that does not have a referenceable preceding state unit form independent state units. The remaining simulation steps that have referenceable preceding state units form incremental state units. The referenceable preceding state unit is always the state unit in the same object whose simulation step identifier is less than the current simulation step and is closest to the current simulation step, and whose dependency ledger has been completed. When there are multiple revision versions of the closest simulation step, the state unit version with the largest revision number is always used as the preceding recovery benchmark for the newly formed state unit. The old state unit version that has been locked and referenced by the existing state unit will not be written back and changed due to subsequent revisions.

[0027] An independent state unit contains all the current state field values ​​specified in the current object's state field list. It can restore the state of the object in the current simulation step without referencing the previous state of the same object. Here, "independent" only means that it has no prior dependencies. When its state representation uses the state of other objects as the recovery benchmark, it can still have cross-object dependencies.

[0028] The incremental state unit uses the preceding state unit of the same object obtained by the aforementioned unique rule as the preceding recovery benchmark. After normalizing the current state field according to a fixed storage precision, it compares the current state field with the corresponding field recovered from the preceding state field. If the values ​​of continuous numerical fields are different after being represented with the same storage precision, the current field value is recorded. If the enumerated values ​​of discrete fields are different, the current enumerated value is recorded. The same field is not recorded repeatedly. When all fields are the same, a corresponding incremental state unit is still formed. Its state change content is empty, and its preceding dependency still points to the preceding state unit to maintain the correspondence of continuous simulation steps.

[0029] After a state unit is formed, it is first written to an object. The object uses a unique object identifier in the current simulation task, and the display name is not used as the sole basis. If the object identifier is missing or the same identifier corresponds to multiple objects, the object is not automatically selected, and the current record is transferred to pending verification.

[0030] Subsequently, a state unit version is written. A state unit version specifically refers to the identity of a state unit formed by an object in a simulation step, determined by the simulation task identifier, simulation step identifier, object identifier, and revision number in a fixed order. When the same simulation task, simulation step, and object first form a state unit, the revision number starts from 0. Thereafter, when a new valid state unit record needs to be formed based on the already fixed source state, the revision number is incremented by 1 based on the maximum revision number already present for that object in that simulation step, generating a new state unit version. State unit content already written to the dependency ledger cannot be modified in situ; old state unit versions are retained and not overwritten. When selecting a preceding recovery benchmark for subsequently formed state units, the version with the largest revision number in the most recent simulation step is selected according to the aforementioned rules. Existing dependencies retain their original locked state unit versions.

[0031] Once the state unit version is determined, it is written to the preceding dependency. The preceding dependency specifically refers to a preceding state unit version of the same object that must be obtained first when restoring the current incremental state unit. The preceding dependency directly records the preceding state unit version obtained according to the aforementioned unique selection rule. The preceding dependency of an independent state unit is always empty. If there is no preceding state unit version that meets the aforementioned rule and can be uniquely determined, the incremental state unit cannot be changed to other historical states, and the current state unit is transferred to pending verification.

[0032] After completing the writing of preceding dependencies, write cross-object dependencies. Cross-object dependencies specifically refer to other object state unit versions that must be obtained simultaneously when restoring the current state unit according to the current state representation. This does not include objects that only have physical association, spatial proximity, control association, or participate in server internal simulation calculations but whose state values ​​are not the conditions for restoring the current state.

[0033] Cross-object dependencies are obtained item by item based on the fixed state representation relationships in the current model configuration; for example, when the end effector attitude is represented by a relative attitude relative to the robot arm mounting base, the end effector state unit records the version of the base state unit that actually serves as the reference for restoring the relative attitude. However, when the end effector has already recorded the absolute attitude value completely, the base state unit is no longer recorded as a cross-object dependency due to the mechanical structure connection relationship.

[0034] When there are multiple cross-object dependencies, they are arranged in a fixed order of object identifier and state unit version and duplicate references are deleted. Before writing a new cross-object dependency, the referenced state unit continues to check its recorded predecessor dependencies and cross-object dependencies level by level. If the current state unit is referenced again before reaching a state unit where there is no longer a reference, it is considered to form a circular reference. The dependency relationship is not written and the current state unit is transferred to pending verification, thereby ensuring that the state recovery relationship in the dependency ledger can obtain a definite termination state along the dependency direction.

[0035] After cross-object dependency is completed, it is written to the commit slot. The commit slot specifically refers to the time position when the current state unit should enter the corresponding simulation state on the receiving end according to the timing of this industrial simulation task. It is defined by the slot identifier and the slot end time. Before the industrial simulation task starts, a unique commit slot is determined for each simulation step in the locking timing configuration. Each object state unit in the same simulation step uses the same commit slot corresponding to that simulation step. The slot identifier is obtained according to the simulation step advancement order, and the slot end time is read from the locking timing configuration.

[0036] This step only writes the commit slot to the status unit and does not change the slot deadline based on the transmission rate, sending queue, or network status; if the commit slot cannot be uniquely obtained from the locking timing configuration, the current status unit will not be entered into the dependency ledger.

[0037] Once the object, state unit version, preceding dependencies, cross-object dependencies, and commit slots are all confirmed, the state unit is written to the dependency ledger.

[0038] The dependency ledger defines a state unit record by using the simulation task identifier, simulation step identifier, object identifier, and state unit version. The record content includes the state unit type, state field content, prior dependencies, cross-object dependencies, and submission slot. It also retains the source state record identifier, model configuration identifier, and formation time as a traceability record of the formation process of this step.

[0039] If the same unique record is submitted again and all the above contents are consistent, it is considered as the same accounting entry and no new record is added; if the unique records are the same but any status field, prior dependency, cross-object dependency or submission slot is different, the existing record will not be overwritten and will be transferred to pending verification.

[0040] The dependency ledger is saved in ascending order of simulation step identifiers, and within the same simulation step, it is saved in a fixed order of object identifiers. Status units that have been written into the ledger remain read-only.

[0041] When the state unit forming end is separated from the dependency ledger storage location, the transmitted content shall at least include the simulation task identifier, simulation step identifier, object identifier, state unit version, state unit type, state field content, prior dependencies, cross-object dependencies, and commit slot. When resubmitting due to communication interruption, the original state unit version shall continue to be used, and the record identity shall not be regenerated. The number of retries allowed and the interval between adjacent retries shall be determined by the communication configuration locked before the industrial simulation task starts. If the record is not settled after reaching the number of retries, the record shall be kept in the write-in area and the current record shall not be considered settled.

[0042] This step only reads the status records generated by the proprietary industrial simulation system, the controlled test production line, or the authorized equipment, and does not send control commands to the actual industrial control equipment.

[0043] Preferably, in the virtual debugging mode of the robotic arm assembly line, the simulation step cycle is set to 20ms, each simulation step contains 12 transmission objects, and the interval for forming independent states is set to 25 simulation steps; the mechanical position is recorded with a storage accuracy of 0.01mm, the rotation position is recorded with a storage accuracy of 0.01°, the speed is recorded with a storage accuracy of 0.01mm / s, and the temperature is recorded with a storage accuracy of 0.1℃.

[0044] When a joint object changes only in its position and velocity fields after being represented by the above-mentioned storage precision in the 126th simulation step relative to its state in the 125th simulation step, the 126th simulation step forms an incremental state unit, writes the two current field values ​​into the state content, and writes the exact state unit version of the joint in the 125th simulation step as a preceding dependency; if the end effector attitude is represented by a relative attitude with respect to the mounting reference object to which the joint belongs, then the corresponding reference object state unit version is recorded as a cross-object dependency.

[0045] When extracting and verifying state units within a continuous 2000 simulation steps according to the fixed step spacing locked before the task starts, the source state record, locked model configuration, state unit version, dependency reference and submission slot are compared item by item. Records that are missing actual state values, cannot be uniquely determined by previous dependencies, form circular references across objects, or cannot be uniquely obtained by submission slots are kept pending verification and are not entered into the dependency ledger in an automatic value filling manner.

[0046] As an equivalent implementation, the independent state formation interval can be set to each simulation step, so that all simulation steps form independent state units; alternatively, an in-process persistent area and independent ledger storage nodes can be used to store the dependency ledger. As long as the object, state unit version, predecessor dependency, cross-object dependency and the formation criteria and reference relationship of the commit slot are consistent, subsequent steps will read the state unit records that have been completed in the dependency ledger.

[0047] S2. Determine the submission support boundaries based on the version submitted by the receiving end, the retention status, and the remaining time of the slot. The specific implementation is as follows: After the receiving end completes the status submission for the current submission slot, it retrieves the submitted version from the records of those already running in the current industrial simulation task. It then confirms the retention status and obtains the remaining time for each submission slot, which the sending end uses to form the submission support boundary. The sending end, as referred to below, is the side that reads the dependency ledger and maintains the state unit records to be sent. It can be located on the same computing device as the industrial simulation server or be handled by its associated sending process. The receiving end is the side that receives the state units and switches the restored object state to the state currently used by the remote industrial simulation task. Both the sending and receiving ends use the same model configuration identifier and submission slot timing configuration locked before task startup for the same industrial simulation task. If the model configuration identifier carried by the receiving end record cannot uniquely correspond to the current task, the status submission is not performed.

[0048] The receiving end submits a version only based on records where the receiving end has already completed the status submission. The arrival of network packets, writing to the receiving buffer, or completion of integrity checks are not considered as submission completion. When the state of the simulation object corresponding to this submission has been written to the current adopted state, the set of state unit versions associated with the current adopted state has been switched, and the corresponding submission slot has been written to the same submission record, the current status submission is considered complete.

[0049] The receiving end submission version is jointly defined by the simulation task identifier, the already submitted submission slot identifier, and the incrementing submission sequence number, and is associated with the actual state unit version used by all simulation objects at the moment of its formation. When a submission slot only updates some simulation objects, the updated objects record the state unit version used in this submission, while the unupdated objects retain the state unit version of the object in the previous receiving end submission version, so that each receiving end submission version can uniquely determine the source of the current state of all simulation objects at the moment of its formation.

[0050] After obtaining the version submitted by the receiving end, each state unit version is checked against the S1 dependency ledger. If the simulation task identifier, object identifier, and state unit version are consistent, it is confirmed. If there is no corresponding record in the dependency ledger, the object cannot be matched, or the current submission has not been completed, no new receiving end submission version record is formed.

[0051] Subsequently, the reserved status is confirmed. The reserved status is limited to the state unit version that the receiving end still saves after the version is formed and can directly read the complete object status. For records whose original transmission form is an incremental state unit, they are only allowed to be included in the reserved status if the receiving end has completed the object status recovery based on the incremental state unit and saved the complete object status corresponding to the state unit version. Records that only save the incremental field and cannot obtain the complete object status are not included in the reserved status.

[0052] The complete object status is confirmed item by item according to the status field list under the corresponding model configuration identifier in S1. The completeness is determined when the field name, engineering unit and field quantity are consistent and each actual status value can be read. If any required field is missing, it is directly excluded and not supplemented based on adjacent simulation steps or other object statuses.

[0053] The current state unit version used by the receiving end submission is included in the reserved state as long as its complete object state is still readable. The historical state unit version corresponding to the previous receiving end submission version can also be included as long as the complete object state is still saved. State unit versions that only exist in the receiving cache, have been overwritten, have been released, or whose complete object state cannot be read are not included.

[0054] Repeated versions of the same state unit are grouped into one item. If the saved content corresponding to the same state unit version is inconsistent, the version is excluded and recorded for verification.

[0055] To prevent state records from becoming invalid during transmission, the complete object state included in the retained state remains readable and unreleased within a pre-locked feedback validity period from the time the receiving end forms this state record. The feedback validity period is determined before the industrial simulation task starts and covers the time required for the receiving end to send a state record, the sending end to receive it, and the submission of support boundaries. When the sending end obtains the record, it checks the elapsed time from the record formation time to the current time according to the same task time. Records that have reached the feedback validity period do not form new submission support boundaries.

[0056] After confirming the retention status, obtain the remaining time for the slot. In this step, the task time is uniformly calculated as the continuously accumulated running time starting from the task start position locked in this industrial simulation task, and the natural clock time of the sending end and receiving end is not used as the basis for slot calculation.

[0057] The sending end obtains the slot expiration time slot by slot according to the commit slot sequence locked by S1, starting from the commit slot corresponding to the commit version of the receiving end, up to the last commit slot currently registered in the dependency ledger. Taking the current task time when the sending end forms the support boundary of this commit as the starting point, the remaining time before the corresponding slot expiration time is calculated as the slot remaining time. When the current task time has not yet reached the slot expiration time, the actual remaining time is recorded. When the slot expiration time has been reached or exceeded, it is fixed as 0. Negative values ​​are not generated, and the slot record that has expired is not deleted.

[0058] The receiving end status record also carries the task time when it was formed, and the sending end uses this to confirm the task progress to which the record belongs. If the simulation task identifier, model configuration identifier, submission slot or task time in the receiving end record cannot uniquely correspond to the current task and S1 lock configuration of the sending end, this record shall not form a new submission support boundary. The previous submission support boundary is only saved as a historical record and will not continue to replace the current record with the remaining time of the slots that have been consumed.

[0059] Once the receiving end confirms the submitted version, retention status, and remaining slot time, a submission support boundary is formed. The submission support boundary consists of a set of supported status unit versions, a record of remaining slot time, and the corresponding relationships for the replacement of independent status units that have been locked for the receiving end's submitted version. The set of supported status unit versions is a unique set of the currently used and fully readable status unit versions of the receiving end's submitted version, merged with the status unit versions in the retention status. The record of remaining slot time saves the remaining time of each slot according to the submission slot identifier. This part is empty when the receiving end's submitted version is not associated with an independent status unit replacement relationship. When determining whether a dependency has been accepted by the current commit's support boundary, first check if the version of the dependent state unit exists in the set of supporting state unit versions. For preceding dependencies, if the version is not in the set, but it belongs to the end state unit version of the original incremental dependency segment in the locked independent state unit replacement correspondence, and the corresponding independent state unit version exists in the set of supporting state unit versions, then the preceding dependency is still considered to have been accepted by the current commit's support boundary, and the original incremental state unit version itself is not added to the set of supporting state unit versions. When there is no such replacement for cross-object dependencies, acceptance is determined solely by whether the state unit version exists in the set of supporting state unit versions.

[0060] This step only determines whether the submission support boundary and dependencies have been accepted by that boundary. It does not track dependencies that have not yet been accepted by the submission support boundary.

[0061] Each submitted support boundary is assigned an incremental boundary number according to the order of its formation, and is associated with the simulation task identifier, the receiving end submission version, the set of supported state unit versions, the correspondence between independent state units, the remaining time of each submission slot, the boundary formation task time, and the incremental submission number of the receiving end submission version on which it is based. After formation, it remains read-only. If the receiving end status record corresponding to the same incremental submission number arrives repeatedly and the content is completely identical, no new boundary is added. If the incremental submission number is less than the currently used receiving end submission version, the boundary is not rolled back. If the content of the same incremental submission number is inconsistent, it is not used and is recorded for verification.

[0062] Preferably, in the virtual debugging mode of the robotic arm assembly line, the simulation step cycle is set to 20ms, the receiver status recording cycle is set to 10ms, and the feedback validity period is set to 30ms. After the receiver completes the 125th submission slot, it forms the receiver submission version. The robotic arm base object in the 125th slot that has not been updated continues to use the state unit version already used in the 124th slot. The updated joint objects record the new state unit version of the 125th slot. The receiver also saves the historical state unit versions of the 123rd to 125th slots that still have complete object states.

[0063] The sending end obtains the record 1ms after the record is formed. When the boundary of the 126th slot is formed, there are still 7ms left before the deadline. Therefore, the remaining time of the 126th slot is recorded as 7ms. The remaining time of the slot that has already been closed is recorded as 0. The 126th slot state unit that is still in the receive buffer and has not completed the state submission is not included in the supported state unit version set.

[0064] As an equivalent implementation, the receiving end's submitted version and retention status can be stored in the same persistent record area, or they can be stored in the current status record area and the historical status record area respectively, as long as the formation conditions of the receiving end's submitted version, the integrity conditions of the retention status, the unified task time base of the slot's remaining time, and the interface diameter of the submission support boundary to the support status unit version set and the locked replacement correspondence remain unchanged.

[0065] S3. Track unmet dependencies outside the submission support boundary, calculate the duration based on dependency data volume, queue occupancy, and link rate; if the remaining time of the slot is exceeded, determine the unreachable segment, and form a failure domain along subsequent dependencies. Specifically, the implementation is as follows: After obtaining the current commit support boundary, the sending end uses the time when the task is formed at the boundary of this commit support boundary as the starting time of this judgment. Simultaneously, it fixes the last commit slot already logged in the S1 dependency ledger and the current sending queue arrangement. The current sending queue specifically refers to the existing arrangement of state units to be sent that actually existed at the sending end at the start of S3. This step only reads and fixes this arrangement, without re-establishing the initial sending order. Before the unreachable segment and failure domain are formed, newly logged state units are reserved for the next judgment, without changing the current tracking range.

[0066] The sending end starts from the state unit in the current sending queue whose submission slot is later than the submission slot of the receiving end and whose state unit version does not belong to the set of supported state unit versions. It then tracks unmet dependencies outside the support boundary one by one in the order of the submission slots. Within the same submission slot, it tracks according to the object identifier order locked by S1.

[0067] For each current state unit, first read its preceding dependencies, then read its cross-object dependencies, and determine whether each dependency has been accepted by the current commit support boundary according to the unified S2 criteria. If it has been accepted, the dependency branch stops at the corresponding acceptance state. If it has not been accepted, the version of the referenced state unit is included in the unsatisfied dependency and the preceding dependencies and cross-object dependencies recorded in the dependency ledger for that state unit version are traced forward until the branch reaches the state that has been accepted by the current commit support boundary, or reaches an independent state unit where the preceding dependencies are empty and there are no cross-object dependencies to continue tracing.

[0068] If the same state unit version is found repeatedly through multiple paths, it will only be retained once; if a state unit version has obtained a complete transmission arrival confirmation from the receiving side but has not yet entered the set of supported state unit versions and has not obtained the preceding dependency based on the S2 replacement correspondence, it is still considered an unsatisfied dependency, but it will no longer generate bytes to be sent; if a state unit is only in the receiving buffer and has not yet obtained a complete transmission arrival confirmation, it will continue to be included in the current transmission burden according to its unconfirmed transmission content.

[0069] If the dependency ledger lacks a version of the referenced state unit, the referenced object cannot uniquely correspond to the version of the state unit, or a circular reference that S1 has specified must not exist occurs, the current round of S3 will stop judging and form a record to be verified, and the dependency will not be presumed based on adjacent simulation steps; if the above situation occurs before the first unreachable point is fully determined, the current round will not skip the state unit and select a later submission slot as the unreachable point, nor will a new failure domain be formed.

[0070] After unmet dependency tracking is completed, the dependency data volume is determined. The dependency data volume adopts the byte caliber of the current transmission record layer of the sender. The current state unit and all state units of the unmet dependencies that have not yet obtained the complete transmission arrival confirmation from the receiver are used as the measurement objects. When the state unit has not started transmission, its complete pending transmission record bytes are counted. When transmission has started, only the remaining bytes in the current transmission record of the sender that have not yet obtained the arrival confirmation from the receiver are counted. When the complete transmission arrival confirmation has been obtained, it is counted as 0B.

[0071] When the same byte is repeatedly associated due to prior dependencies or cross-object dependencies, it is only counted once. The current transmission record layer referred to in this article is the record byte layer formed when the state unit completes the fixed encapsulation at the sending end and enters the sending queue. The record to be sent contains the state content, the state unit version identifier, and the record header, length, and dependency identifier fields that are fixedly added to this layer. It does not contain the frame header, frame tail, or duplicate copies formed by repeated transmissions that are subsequently added by lower communication layers. The amount of dependent data, the amount of queue occupancy, and the link rate all adopt the same transmission record layer caliber.

[0072] If the state unit lacks a definite record length to be sent or the number of remaining unacknowledged bytes cannot be uniquely obtained, the historical average will not be used as a substitute. The current round of S3 will stop the judgment and the current state unit will be transferred to pending verification. If this situation occurs before the first unreachable segment is fully determined, no new unreachable segment or failure domain will be formed in this round.

[0073] Subsequently, based on the fixed sending queue arrangement at the beginning of this operation, the queue occupancy is obtained. Among the current state units and their unmet dependencies, the state units that already exist in the sending queue are identified, and the state unit with the latest queue position is taken as the statistical endpoint. Since the current state unit itself is fixed as the position to be checked in the sending queue, there is at least one statistical endpoint.

[0074] From the head of the queue to the statistical endpoint, the bytes that must be transmitted before the statistical endpoint according to the current queue arrangement and have not yet received confirmation of transmission arrival from the receiving side are counted. All bytes already included in the dependent data are deducted, and the remaining number of bytes is recorded as the queue occupancy. State units that have not yet entered the sending queue in the dependency are only counted in the dependent data according to their bytes to be sent, and are regarded as completing the dependency immediately after the above statistical endpoint. No additional non-dependent queue occupancy is added, thereby ensuring that the same bytes to be transmitted are not counted repeatedly in the dependent data and queue occupancy.

[0075] The link rate is obtained based on the same communication link carrying the current transmission queue. Before the industrial simulation task starts, the sending end locks the rate confirmation interval and the validity period of the link rate record. Within the most recent rate confirmation interval, the number of valid bytes received as the first confirmation of the received transmission is counted. When the same transmission content generates multiple confirmations due to repeated transmissions, only the number of valid bytes received as the first confirmation is counted, and the actual number of valid bytes confirmed per unit time is calculated based on the duration of the interval as the link rate. If the elapsed time from the end of the task in the rate confirmation interval to the current time of use is less than the validity period of the link rate record, the link rate record is valid; if the validity period is reached or exceeded, the record is considered invalid. Since only the first confirmation is counted as valid bytes, the link resource consumption caused by repeated transmissions is reflected as a decrease in the effective link rate, rather than increasing the link rate by repeatedly accumulating bytes.

[0076] If there are bytes to be sent within the rate confirmation interval but no valid byte confirmation is obtained, the current link rate is recorded as 0. At this time, if the sum of the dependent data volume and queue occupancy of the current state unit is greater than 0, it is determined that the occupancy time cannot be completed within the finite time and is processed as if the occupancy time exceeds the remaining time of the slot.

[0077] If there is no record to be sent within the rate confirmation interval, the transmission record required to form the link rate is missing, or the most recent link rate record has expired, it is determined that the link rate cannot be obtained. The rated rate of the equipment, historical peak, or expired historical records will not be used as substitutes, and the current round of S3 will stop further judgment. If this situation occurs before the first unreachable cut is fully determined, no new unreachable cut or failure domain will be formed in this round.

[0078] Once the dependent data volume, queue occupancy, and non-zero link rate are determined, the dependent data volume and queue occupancy are combined to obtain the total effective transmission bytes that the current state unit needs to complete under the frozen queue condition. Then, the time required to complete the total effective transmission bytes is obtained according to the link rate, which is used as the occupancy duration. The occupancy duration is uniformly adopted in the same time unit as the remaining time of slot S2.

[0079] Before comparison, based on the remaining time of the slot recorded in the S2 submission support boundary, the task time that has elapsed from the moment the boundary is formed to the start of the comparison of the current state unit is deducted, and the resulting non-negative time is used as the remaining time of the slot for this comparison; if the deduction result is less than 0, it is fixed as 0.

[0080] The current state unit's occupancy time is then compared with the remaining time of the slot corresponding to its own submitted slot. If the occupancy time is less than or equal to the remaining time of the slot, the state unit is not an unreachable point, and subsequent state units are checked. If the occupancy time is significantly greater than the remaining time of the slot, the state unit is recorded as an out-of-limit state unit.

[0081] After checking the first submission slot with an out-of-limit status unit in the ascending order of submission slots, the later submission slots are no longer checked. Only the same comparison of the remaining status units in the same submission slot is completed, and all out-of-limit status unit versions in the submission slot are jointly determined as the unreachable segment. Therefore, the unreachable segment corresponds to the earliest submission slot that cannot meet the transmission occupancy condition, and may contain one or more status unit versions.

[0082] If the occupancy time of all state units within the fixed tracking range does not exceed the remaining time of the corresponding slot, then no unreachable cut will be formed this time, the failure domain will be empty, and this step will end.

[0083] Once an unreachable point is formed, each state unit version within the unreachable point serves as the starting point for subsequent tracing, forming an invalidation domain along the subsequent dependencies in the dependency ledger. Subsequent dependencies are searched in reverse order of the S1 dependency relationship. Any state unit whose predecessor dependency or cross-object dependency directly references a state unit version in the unreachable point is considered a direct successor. The search continues to find subsequent state units whose predecessor dependency or cross-object dependency directly references a state unit version already included in the invalidation domain, until the last commit slot of the dependency ledger, which was fixed at the beginning of this operation, is reached.

[0084] When the same state unit is found repeatedly through multiple successor paths, it is only included once; when the preceding dependency of a subsequent independent state unit is empty and its cross-object dependency does not reference any version of the state unit in the unreachable point or the failure domain, the dependency propagation terminates at this branch, and the independent state unit and the subsequent states re-formed only by the independent state unit do not automatically enter the failure domain due to the original unreachable point.

[0085] The failure domain is composed of all state unit versions in the unreachable section and the state unit versions found directly or indirectly along the aforementioned subsequent dependencies. It is associated with the current submission support boundary sequence number, the submission slot corresponding to the unreachable section, the set of state unit versions of the unreachable section, the set of state unit versions of the failure domain, the termination slot of the current dependency ledger tracking, and the read-only record kept at the time of task formation. This step only determines the unreachable section and the failure domain, does not change the sending eligibility of the failure domain state unit, and does not determine the subsequent recovery boundary.

[0086] Preferably, in the virtual debugging mode of the robotic arm assembly line, the simulation step cycle is set to 20ms, the link rate confirmation interval is set to 100ms, and the link rate record validity period is set to 200ms. A joint state unit in a certain submission slot generates 18000B of dependent data after tracking. Before its dependency acceptance is completed, another 7000B of non-dependent bytes form queue occupancy in the frozen queue. The current link rate is 2500B / ms, corresponding to an occupancy time of 10ms. In S2, the original record for the remaining time in this slot is 9ms. From the submission support boundary... If 1ms has elapsed since the start of this comparison, then the remaining time for this slot is 8ms. Since the occupation time exceeds 8ms, this state unit is recorded as an over-limit state unit. If the occupation time of another end effector state unit in the same slot is 11ms, then the two state unit versions together constitute an unreachable access point for this slot. Subsequently, the subsequent joint states and end effector states that directly or indirectly reference the above state unit versions in the dependency ledger are included in the failure domain, while the temperature state, which is restarted by a subsequent independent state unit and no longer references the above states, remains outside the failure domain.

[0087] As an equivalent implementation, the link rate can be obtained from the transmission record of the sending end, or it can be given by the effective transmission rate under the same byte metering level by the communication link management node carrying the same transmission queue, as long as the rules of dependency tracking, remaining byte metering, queue occupation deduplication, slot remaining time update, taking the earliest over-limit submitted slot for unreachable points and subsequent dependency extension are consistent.

[0088] S4. Starting from the simulation step after the unreachable cutout, sequentially select candidate boundaries and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is longer than the duration of the independent state unit, replace the segment with the independent state unit to form a recovery closure. Take the first candidate boundary whose duration does not exceed the remaining time of the slot as the recovery boundary. The specific implementation is as follows: After the sending end forms an unreachable segment and failure domain in S3, it fixes the task time at the start of this S4, the link rate record used in S3, and the dependency ledger tracing termination slot that has been fixed in S3, and keeps the above judgment criteria unchanged until the candidate boundary search is completed; if the link rate used has exceeded the validity period specified in S3 at the start of S4, no recovery boundary will be formed this time.

[0089] The sending end removes duplicate object identifiers from the failure domain. Starting from the earliest simulation step where the submitted slot is strictly later than the submitted slot corresponding to the unreachable cutout, candidate boundaries are obtained in ascending order of simulation step identifiers. The correspondence between simulation steps and submitted slots uses a unique mapping already locked by S1. For each simulation step, the state unit version corresponding to each object in that simulation step is obtained from the dependency ledger. If no state unit version of any object has been completed in the ledger for that simulation step, no valid candidate boundary is formed for that simulation step, and the process continues to obtain the next simulation step.

[0090] The remaining time of the slot corresponding to the candidate boundary is obtained by subtracting the time that has elapsed from the time when the task is formed by submitting the supporting boundary to the time when the task starts in S4. If the subtraction result is less than or equal to 0, the simulation step will not enter the subsequent recovery closure comparison. The remaining time of the slot is calculated using the same time when the task starts in S4 for all candidate boundaries. The time reference will not be changed due to the order of actual inspection of each candidate boundary.

[0091] For the current valid candidate boundary, the state unit version corresponding to each of the aforementioned objects in this simulation step is used as the starting point for reverse tracing. The preceding dependencies and cross-object dependencies recorded in the S1 dependency ledger are traced forward step by step. The S2 unified criteria are used to determine whether each dependency has been accepted by the current commit support boundary. If it has been accepted, the branch terminates. If it has not been accepted, the referenced state unit version is added to the missing dependency and the tracing continues until all dependency branches have reached the state of being accepted by the current commit support boundary, or have reached an independent state unit where the preceding dependencies are empty and all cross-object dependencies have been supported.

[0092] When the same state unit version is repeatedly obtained by multiple objects or multiple dependency branches, it is only added once; when the reference record is missing, the object cannot be uniquely matched, or the reference exceeds the S3 fixed tracking termination slot, the current candidate boundary does not form a recovery closure.

[0093] After missing dependencies are filled in, incremental dependency segments are divided for the same object according to the preceding dependency relationship. The incremental dependency segment is limited to the longest continuous sequence of state units in the current candidate boundary back-tracking result, which is continuously connected along the preceding dependency of the same object, consists entirely of incremental state units, does not contain any independent state units, and has not reached the state position that has been accepted by the current submission support boundary. The same incremental state unit can only belong to 1 incremental dependency segment.

[0094] Multiple incremental dependency segments are arranged in ascending order of object identifiers. When there are multiple incremental dependency segments for the same object, they are arranged in ascending order of simulation step identifiers at the end of the segments, and replacement judgment is completed in this fixed order.

[0095] For the current incremental dependency segment, the incremental state unit corresponding to the latest simulation step of the segment is determined as the segment-end state unit. The complete state content, identical to the segment-end state unit, with the same object, simulation step, and state field values, is obtained from the solidified complete object state record of the simulation step saved at the sending end. Candidate independent state units are formed according to the field list and state representation relationship of the model configuration identifier corresponding to the object in S1. Their preceding dependencies are fixed as empty, and cross-object dependencies are determined item by item according to the other object state unit versions necessary to restore the complete state in the model configuration. When forming candidate independent state units, the dependency ledger is first checked to see if a record with the state type of independent state unit and completely identical state field content, model configuration identifier, and cross-object dependencies already exists for the same simulation task, simulation step, and object. If it exists, the state unit version is directly reused; if it does not exist, the candidate state unit version is formed by adding 1 to the maximum revision number of the simulation step for the object, according to the revision number rule in S1. If the corresponding complete object state record has been released, the fields cannot be completely obtained, or the cross-object dependencies cannot be uniquely determined, the incremental dependency segment does not perform independent state unit replacement.

[0096] Candidate independent state units are only used to determine whether to replace the state inheritance relationship of the same object undertaken by the current incremental dependency segment, without changing the original state unit record in the S1 dependency ledger. When the subsequent comparison result meets the independent state unit replacement condition, the candidate independent state unit that does not yet exist in the dependency ledger is written into the dependency ledger according to the S1 record and kept read-only. Then, its corresponding original segment end state unit version is recorded, so that the subsequent state units in the recovery closure that originally used the segment end state unit version as the preorder dependency can be provided with the same object and the same simulation step state inheritance by the independent state unit. When the comparison result does not meet the replacement condition, the candidate independent state unit that has not yet been recorded is not written into the dependency ledger.

[0097] In this step, the current recovery set is fixed as the set of state unit versions after the missing dependencies of the current candidate boundary have been filled in, but before all incremental dependency segment replacement judgments have been completed. For the current incremental dependency segment, first determine the state unit version that can be deleted synchronously after deleting the segment in the current recovery set. Apart from the segment itself, only state units that have been filled in because of the segment and are not referenced by other state units, other incremental dependency segments, or cross-object dependencies in the current candidate boundary are allowed to be deleted. After deletion, continue to check its dependency status until there are no state units that have lost all references due to this deletion. The number of bytes that have not yet been confirmed for transmission by these actually deletable state units forms the transmission burden corresponding to the incremental dependency segment, and the duration occupied by the incremental dependency segment is obtained using the fixed link rate of this step.

[0098] Then, candidate independent state units and their cross-object dependencies that have not yet been accepted by the current submission support boundary and do not yet exist in the current recovery set are added step by step to form the actual new transmission content that needs to be added after adopting independent state units. The duration of independent state units is obtained by using the same link rate with the actual number of bytes to be transmitted for these new contents. Thus, the state unit shared by multiple incremental dependency segments is only retained by the party that still needs the state unit, and is not repeatedly deleted or counted due to partial replacement.

[0099] When the duration of an incremental dependency segment is significantly longer than the duration of an independent state unit, the incremental dependency segment is replaced by an independent state unit. The necessary dependency ledger entries and corresponding relationship records are then completed according to the aforementioned rules. The independent state unit then takes over the state unit following the end of the segment. When the duration of an incremental dependency segment is less than or equal to the duration of an independent state unit, the original incremental dependency segment is maintained.

[0100] After each incremental dependency segment is evaluated, the next incremental dependency segment in a fixed order is evaluated using the updated current recovery set, thus obtaining a unique replacement result under the same dependency ledger conditions.

[0101] After all incremental dependency segments are judged, the corresponding state unit versions of each object in the candidate boundary, the missing dependencies that have not been replaced, the independent state units retained after replacement, and the cross-object dependencies that must be added are merged and deduplicated to form a recovery closure. For each state unit in the recovery closure, its preceding dependencies and cross-object dependencies are checked one by one. If the preceding dependency is empty, it is not required to add the preceding state. If the preceding dependency is not empty, its dependency state must have been accepted by the current submission support boundary, exist in the recovery closure, or be accepted by the corresponding relationship that has been replaced by the independent state unit that has been established this time. All cross-object dependencies must exist in the support state unit version set or the recovery closure. If any dependency does not meet the above conditions, the current candidate boundary does not form a valid recovery closure.

[0102] After a valid recovery closure is formed, its content to be transmitted is fixed according to the actual record to be transmitted. The remaining bytes occupied by the state units that have not yet obtained the complete transmission confirmation from the receiving side and the fixed record fields actually sent with the closure are counted. The duration of the recovery closure is obtained using the fixed link rate. When the link rate is 0 and there are bytes to be transmitted, the current candidate boundary does not meet the occupancy condition. When there are no bytes to be transmitted in the recovery closure, its occupancy duration is recorded as 0.

[0103] The recovery closure duration is compared with the remaining slot time obtained at the current unified task time for the candidate boundary. If the recovery closure duration is greater than the remaining slot time, the next candidate boundary is obtained. If the recovery closure duration is less than or equal to the remaining slot time, the search is stopped immediately. The first candidate boundary that meets the conditions obtained in the incremental order of simulation steps is determined as the recovery boundary, and its recovery closure is locked. If there is still no candidate boundary that meets the conditions when checking to the S3 fixed dependency ledger tracing termination slot, no recovery boundary is formed in this case.

[0104] The recovery boundary record should at least be associated with the current submission support boundary number, the submission slot corresponding to the unreachable cutout, the simulation step corresponding to the recovery boundary, the submission slot, the state unit version in the recovery closure, the correspondence of independent state unit replacements, and the time of task formation, and should be kept read-only.

[0105] Preferably, in the virtual debugging mode of the robotic arm assembly line, the unreachable cut is located at the 128th simulation step. At the start of S4, the remaining time for the 129th submission slot is 7ms, and the remaining time for the 130th submission slot is 8ms, with a fixed link rate of 2500B / ms. The 129th candidate boundary recovery closure contains 24000B of content to be transmitted, occupying a time of 9.6ms, which does not meet the remaining time requirement of the corresponding slot. In the 130th candidate boundary, the actual deletable transmission content of a certain joint incremental dependency segment is 15000B, occupying a time of 6ms. After forming a candidate independent state unit based on the complete state of the joint in the 130th simulation step, the actual transmission content containing its necessary new dependencies is 7500B, and the independent state unit duration is 3ms. Therefore, a replacement is performed, and its formal state unit version is formed according to the S1 revision sequence number rule. Finally, the content to be transmitted in the recovery closure is 17500B, occupying a time of 7ms, which does not exceed 8ms. Thus, the 130th candidate boundary is determined as the recovery boundary.

[0106] S5. Freeze the unrecovered transmission units within the failure domain and write the recovery closure into the recovery queue; after inserting a transmission unit outside the failure domain, the transmission unit obtains the qualification to send when the duration occupied by the recovery closure does not exceed the remaining time of the recovery boundary slot. The specific implementation is as follows: After the sending end obtains the recovery boundary and recovery closure that have been locked in S4, it checks the transmission units in the failure domain of S3 item by item and freezes the transmission units that have not been recovered. The transmission unit in this step corresponds to the record to be sent formed by the sending end of one state unit. Its identity adopts the corresponding state unit version. The independent state unit formed by replacing the incremental dependency segment in S4 also maintains a unique identity according to the state unit version of S1, and enters this step using the state unit version that has been locked in the recovery closure of S4.

[0107] For the current transmission unit within the failure domain, its preceding dependencies and cross-object dependencies are read, and each dependency is judged according to the unified S2 standard to determine whether it has been accepted by the current commit support boundary. If any dependency required to complete the current state acceptance has not been accepted by the commit support boundary, the dependency of the transmission unit is considered not to have been recovered. If the dependency state unit has been written into the recovery closure, entered the recovery queue, obtained the sending qualification, completed the sending, or arrived at the receiving side but has not yet formed a commit support boundary acceptance, it is not considered that the dependency has been recovered.

[0108] When freezing, the status unit version, submission slot, remaining bytes for which a complete transmission arrival confirmation has not yet been obtained from the receiving side, and the original queuing record of the transmission unit are retained. Only its eligibility to be directly selected from the normal transmission queue is cancelled. The record is not deleted, and the status unit version is not regenerated. When the same status unit version repeatedly enters the freeze judgment, the existing frozen state is maintained.

[0109] Although transmission units belonging to the S4 recovery closure within the failure domain remain frozen in the normal transmission sequence, they are allowed to be written into the recovery queue according to the recovery closure, and the recovery queue forms their transmission order during this recovery period.

[0110] After freezing is complete, each state unit in the recovery closure is mapped to a transmission unit and written to the recovery queue. Transmission units that have received confirmation of complete transmission arrival from the receiving side no longer retain bytes to be sent. When the same state unit version appears repeatedly through multiple dependencies, only one item is retained.

[0111] The recovery queue is arranged in a fixed order according to the dependency relationship of the recovery closure: each time, the previous dependencies and cross-object dependencies of the recovery closure within the unarranged recovery closure are searched for, and the corresponding dependencies have been arranged at the front or have been supported by the current commit boundary. These transmission units are taken as the current arrangable objects. When there are multiple current arrangable objects, one item is selected in sequence according to the commit slot locked by S1, object identifier and status unit version and written to the next queue position. The above process is repeated until all transmission units of the recovery closure are arranged.

[0112] In the S4 independent state unit replacement correspondence, the independent state unit must be placed before the subsequent state unit that depends on the replacement result. If the above arrangement cannot be formed when both S1 and S4 records are complete, the recovery queue will not be sent and will retain the record to be verified. The sender will not change the dependency relationship on its own.

[0113] If a recovery closure has been written to the recovery queue according to the same recovery boundary and the state unit version set and the remaining range to be sent are consistent, it will not be written again. Locked recovery closures may not have state units added or deleted in place in S5.

[0114] After the recovery queue is formed, from the transmission units outside the S3 failure domain that have not yet received confirmation of complete transmission arrival from the receiving side, the transmission units to be judged are obtained one by one in the order of the submission slot, object identifier and status unit version locked in S1.

[0115] For each transmission unit to be judged, the current task time when the qualification judgment begins is used as the qualification judgment time. The remaining time of the slot before the deadline of the recovery boundary submission slot is reread, the remaining bytes of each transmission unit in the recovery closure that have not yet obtained the complete transmission arrival confirmation from the receiving side, the remaining bytes of the failed out-of-domain transmission units that have already obtained the qualification to send and are still arranged before the completion position of the recovery closure, and the current effective link rate that can be obtained according to the same caliber as S3. When the slot deadline has reached or exceeded the current task time, the remaining time of the slot is recorded as 0. If the link rate cannot be obtained, no new transmission qualification is granted. Similarly, if the link rate is 0 and there are still bytes to be sent in the recovery closure, no new transmission qualification is granted.

[0116] Subsequently, the transmission unit to be judged is temporarily inserted into the existing transmission sequence according to the position corresponding to its own submitted slot and object identifier. The existing transmission sequence in this step specifically refers to the logical transmission order relationship formed by the recovery queue and the failed out-of-domain transmission units that have obtained transmission qualification. It is not required that the above records be physically stored in the same queue. Insertion only changes the transmission order of the transmission unit relative to the recovery closure, and does not change the dependency order that has been locked within the recovery closure. When the transmission unit to be judged should be arranged before the last byte to be sent in the recovery closure, the remaining bytes that have not yet obtained the reception side's transmission arrival confirmation will be included in the calculation of the current occupancy time. When it is arranged after the completion position of the recovery closure, it will not increase the occupancy time of the current recovery closure.

[0117] When determining the recovery boundary in S4, the duration of the recovery closure corresponds to the baseline duration under the condition of no inserted failed external transmission unit. In this step, under the same byte metering level and link rate caliber, all remaining bytes that must pass before the recovery closure is sent are counted starting from the current qualification determination time. This includes the remaining bytes of the recovery closure itself and the remaining bytes of failed external transmission units that are arranged before the completion position of the recovery closure and have already obtained the qualification to send or are undergoing this determination. The duration of the recovery closure after insertion is obtained again according to the current effective link rate. Any byte that has already obtained the confirmation of arrival of the transmission on the receiving side is not counted again.

[0118] If the duration of the recovery closure after insertion is less than or equal to the remaining time of the recovery boundary slot at the time of this qualification determination, the current transmission unit obtains the qualification to send, the temporary insertion position becomes a valid arrangement, and serves as the basis for the existing arrangement when determining the qualification of subsequent transmission units; if the duration of the recovery closure after insertion is strictly greater than the remaining time of the slot, the current transmission unit does not obtain the qualification to send, the temporary insertion is immediately cancelled, the arrangement state before the determination of the transmission unit is restored, and the subsequent failed out-of-domain transmission units are determined according to the established order. Therefore, if the previous larger transmission unit cannot obtain the qualification to send, it does not prevent the subsequent smaller transmission units from receiving the same determination.

[0119] Sending eligibility only indicates that the current transmission unit is allowed to be selected by the sender under the current queue state and current time conditions, and does not indicate that it has been sent, has arrived at the receiver, or has formed a version submitted by the receiver. Sending eligibility is associated with and stored in relation to the current recovery boundary, the remaining range of the recovery closure to be sent, the queue arrangement state, and the eligibility determination time. Before the transmission unit is actually selected for transmission, if the remaining time of the recovery boundary slot continues to decrease, the remaining bytes of the recovery closure change, the current effective link rate record is updated, or other transmission units before the recovery closure completion position change, the original sending eligibility will not be directly used, but will be reconfirmed according to the same insertion and occupancy duration comparison rules before the actual selection.

[0120] Transmission units that have already completed sending will no longer participate in subsequent qualification assessments. Transmission units that have partially completed sending will continue to participate in subsequent calculations only with the remaining bytes for which they have not yet received confirmation of arrival from the receiving side.

[0121] The sending end will associate and save the current recovery boundary, recovery closure, frozen transmission unit set, recovery queue arrangement, failure of out-of-domain transmission unit transmission qualification and the judgment time corresponding to each qualification. This step does not change the version submitted by the receiving end, nor does it remove the dependency on the frozen state of unrecovered transmission units.

[0122] Preferably, in the virtual debugging mode of the robotic arm assembly line, at a certain qualification determination, the remaining time for restoring the boundary slot is 8ms, the recovery closure still has 15000B unacknowledged bytes, the current effective link rate is 2500B / ms, and the recovery closure takes 6ms when no other transmission units are inserted; the first transmission unit outside the failure domain has 2000B remaining and needs to be arranged before the completion position of the recovery closure. After insertion, the time taken is 6.8ms, so it obtains the qualification to send; the second transmission unit has 4000B remaining, and according to the new qualification determination time, the remaining time for obtaining the slot is 7.8ms. After inserting it based on the arrangement of the first transmission unit, the recovery closure takes 8.4ms, so it does not obtain the qualification to send and the insertion is canceled; the third transmission unit has 1000B remaining, and after re-determination, the recovery closure takes no more than the remaining time of the slot at that time, so it obtains the qualification to send.

[0123] As an equivalent implementation, the recovery queue can be stored independently of the ordinary transmission queue, or it can form the same logical transmission order relationship within the same physical transmission queue through the records of frozen state, recovery closure affiliation and transmission qualification. As long as the frozen transmission unit cannot be directly selected through the ordinary position, the internal dependency order of the recovery closure remains unchanged, and each time the transmission unit outside the failure domain obtains the transmission qualification, the duration of the recovery closure after insertion does not exceed the remaining time of the recovery boundary slot at that time.

[0124] S6. The receiving end verifies and restores the integrity of the closure, accepts dependencies, commits, and returns a record; the sending end updates the commit support boundary and releases subsequent transmission units based on the closure commit version as a dependency. Specifically, this is implemented as follows: When the receiving end receives the transmission record corresponding to the recovery closure, it registers the arrival status of each recovery closure item according to the recovery closure locked in S4. The recovery closure is uniquely defined by the industrial simulation task identifier, the current submission support boundary sequence number, the submission slot corresponding to the recovery boundary, and the set of state unit versions contained in the recovery closure. The sending end can determine the above content, the length of the complete record corresponding to each state unit version, the S4 independent state unit replacement correspondence, and the S5 recovery queue arrangement order of the locked record with this recovery transmission, so that the receiving end can pre-determine the set of state units that should be received this time, and does not reverse the determination of the recovery closure based on the actual arrival content. When segmented transmission is used, each segment record carries the state unit version, the starting position of the segment in the complete transmission record, the effective length of the segment, and the length of the corresponding complete record of the state unit.

[0125] The arrival status of each member of the recovery closure is updated as soon as a complete transmission record is obtained. When all expected state units have formed complete transmission records, the recovery closure integrity check is started immediately. If there are still members that have not arrived completely by the deadline of the recovery boundary submission slot, the integrity of the recovery closure is not valid and the current submission version of the receiver remains unchanged.

[0126] When a state unit is transmitted in segments, the receiving end merges the arrived content according to the segment start position and effective length corresponding to the same state unit version. If the same position is repeatedly arrived and the content is the same, only one copy is retained. Only when the deduplicated effective content continuously covers the locked complete length from the record start position without any gaps is the state unit considered complete. In the implementation method of transmitting a complete record in one go, the consistency between the actual record boundary and the locked complete length is used as the equivalent complete condition.

[0127] If the state unit versions are the same but the actual state fields, dependency references, or the content of the same record location are inconsistent, the relevant records will not be used, and the recovery closure will not be committed in this operation.

[0128] After the integrity of the restored closure is established, the receiving end checks the dependency acceptance sequentially according to the order of the restored queue locked by S5. For each state unit, it reads its preceding dependencies and cross-object dependencies. If the preceding dependency is empty, the preceding state is not required. If the preceding dependency is not empty, the corresponding dependency must have been accepted by the current commit boundary, or belong to the same restored closure and have completed state restoration before the current state unit. Cross-object dependencies must exist in the set of supported state unit versions, or belong to the same restored closure and have completed state restoration before the current state unit.

[0129] When S4 replaces an incremental dependency segment with an independent state unit, according to the replacement correspondence locked by S4, the complete state of the same object and the same simulation step formed by the recovered independent state unit is taken as the inheriting state of the end state of the original incremental dependency segment. Subsequent references to the version of the end state unit of the original segment are inherited by the replacement correspondence, and it is not required to restore the replaced incremental dependency segment.

[0130] If any dependency cannot be uniquely accepted by replacing the corresponding relationship according to the current commit support boundary, the recovered state of the same recovery closure, or the independent state unit locked by S4, the current commit is stopped and the original receiving end commit version is maintained.

[0131] After all dependencies are successfully adopted, the receiving end first forms the complete pending state of the objects involved in the recovery closure at the temporary storage location without changing the current adopted state: independent state units directly form the complete state of the corresponding object according to the field list locked by S1; incremental state units first copy the previously adopted complete object state, and then overwrite each changed field recorded by the current incremental state unit, while unrecorded fields retain the previous state values; when state representation requires cross-object dependencies, the corresponding fields are restored using the already adopted cross-object complete state according to the same state representation relationship in the S1 locking model configuration. When all object states are successfully formed and the current task time is strictly earlier than the deadline of the recovery boundary commit slot, the current adopted state of these objects is switched uniformly under the same incremental commit sequence number; if any object has not yet been successfully formed, or if the current task time has reached or exceeded the deadline, this uniform switch is not performed, so there will be no state where only some objects of the recovery closure are effective.

[0132] After the unified switch is completed, a closure submission version is formed. The closure submission version belongs to the S2 receiver submission version and is uniquely identified by the industrial simulation task identifier, the recovery boundary submission slot, and the incremental submission sequence number. It is also associated with the current actual state unit version used by all simulation objects after the submission is completed. Objects that have not been changed in this recovery closure retain the state unit version currently used before the submission.

[0133] At the same time, the S4 independent state unit replacement correspondence is locked as the acceptance record of the closure submission version. This record only indicates that the end state of the original incremental dependency segment can be accepted by the actually submitted independent state unit, and does not write the original incremental state unit version that has not been actually submitted into the support state unit version set.

[0134] If the same record is received again after the same recovery closure has been successfully committed, the commit number will not be incremented again, but the original closure commit version will be returned.

[0135] When the receiving end generates a return record, it shall at least write the industrial simulation task identifier, the original submission support boundary sequence number, the recovery boundary submission slot, the closure submission version, the current state unit version of all objects after submission, the independent state unit replacement correspondence, the retained state that can still be fully read, and the submission completion time. The returned retained state shall remain readable in accordance with the S2 feedback validity period. Simple transmission arrival confirmation shall not replace this return record.

[0136] After receiving the return record, the sending end confirms that the industrial simulation task, the original submission support boundary, the recovery boundary, and the closure submission version all correspond to the current recovery record. It then rejects return records that are earlier than the currently adopted receiving end submission version according to the submission sequence number. After confirming the validity, the closure submission version is used as the new receiving end submission version. Based on the current state unit version, reserved state, and independent state unit replacement relationship associated with the closure submission version of all returned objects, a set of supporting state unit versions and corresponding acceptance records are formed according to the unified S2 standard. Then, based on the remaining time of the slots of subsequent submission slots obtained by the sending end at the current task time, a new submission support boundary is formed, and the original submission support boundary continues to be saved in read-only mode.

[0137] The independent state unit replacement correspondence is saved as the acceptance record of the new submission support boundary association, and is used by subsequent steps according to the submission support boundary acceptance interface standard already uniformly defined in S2; the original incremental dependency segment end state unit version itself is still not added to the support state unit version set. When S3, S4, and S5 judge the corresponding preceding dependencies, they will all take the acceptance result of the submission support boundary as the standard, and will no longer make the opposite judgment based solely on whether the original state unit version belongs to the support state unit version set.

[0138] After the submission support boundary update is completed, only subsequent transmission units whose submission slots are later than the recovery boundary submission slots and are still in the S5 frozen state are checked. When all their preceding dependencies and cross-object dependencies have been accepted by the updated submission support boundary, the subsequent transmission unit is determined to be based on the closure submission version and the S5 freeze is lifted, allowing it to re-enter the normal waiting range.

[0139] Old frozen transmission units whose slots are committed no later than the recovery boundary and which have not been actually committed by the recovery closure are not released by this closure commit version and still cannot re-enter the normal transmission sequence.

[0140] Release only means to unfreeze the corresponding invalidation domain, not to send immediately, nor to add the released but not yet committed state unit to the support state unit version set in advance.

[0141] Preferably, in the virtual debugging mode of the robotic arm assembly line, the recovery boundary is located at the 130th simulation step. The recovery closure contains 9 state unit versions, of which 1 independent state unit replaces the original incremental dependency segment. Before the deadline of the 130th submission slot, the receiving end confirms that all 9 state unit records are complete, and submits them in a unified manner after completing the dependency acceptance according to the recovery queue order to form a closure submission version. It returns the state unit version currently used by all 12 simulation objects and the corresponding replacement relationship. After the sending end forms a new submission support boundary, the dependencies in the 131st and subsequent submission slots have all been unfrozen by the transmission units accepted by the closure submission version, while the old frozen transmission units that have not entered the recovery closure at the 130th and earlier slots do not regain the qualification for normal transmission.

[0142] As an equivalent implementation, the receiving end can use the current state pointer and the pending state pointer in the same storage area to complete the unified switching, or it can use mutually isolated temporary storage areas and current state areas, as long as the integrity judgment, dependency acceptance, overall submission, closure submission version, return record, submission support boundary update and subsequent transmission unit release maintain the above unique rules.

[0143] In the operating scenario shown in this embodiment: the method is applied to the remote virtual debugging process of the robotic arm assembly line. The industrial simulation server is the computing side where the sending end is located, and the remote virtual debugging terminal is the receiving end. Before the industrial simulation task is started, both parties lock the same model configuration identifier and submission slot timing configuration. The simulation step cycle is set to 20ms. Each simulation step corresponds to 1 submission slot and contains 12 simulation objects. The simulation objects include the robotic arm base, multiple joints, end effector, and other objects involved in state linkage. The interval for forming independent states is set to 25 simulation steps.

[0144] During task execution, the industrial simulation server obtains the fixed object state after each simulation step calculation. For example, if a joint changes only in position and velocity in the 126th simulation step compared to the 125th simulation step, then an incremental state unit for the 126th simulation step is formed, and the most recently settled state unit version for that joint in the 125th simulation step is recorded as a preceding dependency. When the end effector adopts an attitude representation relative to the installed reference object, the corresponding reference object state unit version is written as a cross-object dependency. Each state unit, along with the object identifier, state unit version, and submission slot, is written to the dependency ledger.

[0145] After the receiving end successfully receives and submits the data to the 125th submission slot, it forms the corresponding receiving end submission version. Objects that are not updated in the 125th slot continue to use the state unit version that has been actually used before. The receiving end also retains the historical state that can still read the complete object state. After the sending end obtains this record, it forms the submission support boundary and determines whether the dependency of the subsequent state has been taken over by the current state of the receiving end.

[0146] Subsequently, a short-term transmission congestion occurred in the communication link, and a certain joint state unit and some subsequent states that depended on it failed to be transmitted in time according to the original transmission order. The sending end fixed the current transmission queue and the dependency ledger tracking range, and tracked the dependencies that had not yet been accepted by the submission support boundary level by level.

[0147] Taking one judgment as an example, a certain joint state unit needs to complete 18000B of dependent data. Before this state unit can complete the dependency takeover, there are still 7000B of non-dependent content to be transmitted in the sending queue. The nearest effective link rate is 2500B / ms, so the corresponding occupation time is 10ms. The original slot of this submission slot has a remaining time of 9ms. By the time of the actual comparison, 1ms has passed, and the actual remaining time is 8ms. 10ms exceeds 8ms, so this state unit is recorded as an over-limit state unit. When the occupation time of another end effector state unit in the same submission slot is 11ms, the two are jointly determined as the unreachable point of the earliest over-limit submission slot. The state units that directly or indirectly depend on the above state are included in the failure domain along the reverse reference relationship of the preceding dependency and cross-object dependency, while the state that is not related to the above dependency chain and restarts from the subsequent independent state remains outside the failure domain.

[0148] The unreachable section corresponds to the 128th simulation step. The sending end searches for candidate boundaries sequentially starting from the subsequent simulation steps. The 129th submitted slot has 7ms remaining at the unified task time of this search. The candidate recovery closure formed after backfilling the missing dependencies contains 24000B of content to be transmitted. At a link rate of 2500B / ms, it takes 9.6ms. Therefore, the 129th simulation step cannot be used as a recovery boundary.

[0149] Continuing to check the 130th simulation step, the remaining time for its submission slot is 8ms. Among them, the actual deletable content to be transmitted for a certain joint's continuous incremental dependency segment is 15000B, which takes 6ms. The sending end forms a candidate independent state unit from the complete object state of the joint that has been fixed in the 130th simulation step. This independent state unit and its necessary dependencies correspond to 7500B of content to be transmitted, which takes 3ms. Since 3ms is less than 6ms, the original incremental dependency segment is replaced with this independent state unit and the replacement correspondence is recorded. After merging other dependencies, a 17500B recovery closure is formed, which takes 7ms, not exceeding the 8ms remaining time for the 130th submission slot. Therefore, the 130th simulation step is determined as the boundary of this recovery and the corresponding recovery closure is locked.

[0150] The sender then freezes the ordinary transmission units within the failure domain whose dependencies have not yet been accepted by the current submission support boundary, and writes the recovery closure into the recovery queue according to the dependency acceptance order; for state units outside the failure domain that are still to be sent, the transmission is not stopped directly, but each item is checked to see if it can still guarantee that the recovery closure will be completed within the remaining time of the slot at the recovery boundary after insertion.

[0151] For example, during a certain judgment, the recovery closure still has 15000 bytes of unacknowledged content. The current link rate is 2500 bytes / ms, and its own occupancy time is 6ms, while the remaining time for the recovery boundary slot is 8ms. The first out-of-domain transmission unit with 2000 bytes remaining is positioned before the recovery closure completion position. After insertion, its occupancy time is 6.8ms, thus it is qualified to send. The second out-of-domain transmission unit with 4000 bytes remaining has its slot remaining time reduced to 7.8ms at the new judgment time. After insertion, its recovery closure occupancy time reaches 8.4ms, so the insertion is canceled and it is not qualified to send. Subsequently, another out-of-domain transmission unit with 1000 bytes remaining can still complete the recovery closure within the remaining slot time after re-judgment, so it is allowed to obtain the qualification to send. This ensures that the recovery data arrives on time while preventing the state units that can continue to transmit from the out-of-domain from stopping due to this dependency failure.

[0152] After the receiving end obtains the recovery closure corresponding to the 130th recovery boundary, it checks the expected state unit version and the length of the complete record according to the locking record. If the recovery closure contains 9 state unit versions, it confirms that the valid content of each of the 9 state units has arrived completely, and checks the preceding dependencies and cross-object dependencies according to the order of the recovery queue. The original incremental dependency segment that was replaced by the independent state unit is no longer required to be restored. Instead, the independent state unit that has been arrived and restored is used as the basis for the complete state of the 130th simulation step of the same object.

[0153] Once all dependencies are established, the receiving end restores the complete pending state of each object in the temporary storage location, and switches to the current adopted state before the deadline of the 130th submission slot, forming the corresponding closure submission version. This closure submission version is associated with the actual adopted state unit version after the submission of the 12 simulation objects and the aforementioned independent state unit replacement correspondence, and is returned to the sending end.

[0154] After the sending end obtains the return record, it re-forms the commit support boundary based on the closure commit version. All frozen transmission units that depend on the 131st and subsequent commit slots are unfrozen and re-enter the normal waiting range, while the old frozen transmission units that did not enter the recovery closure or actually obtain the current commit support boundary remain frozen.

[0155] This completes a full cycle from normal state transmission, the inability of dependent states to arrive in a timely manner, the determination of the affected state range, the selection of recovery boundaries, the scheduling of transmission during recovery, to the receiving end's recovery submission and subsequent state re-acceptance.

[0156] Example 2: A low-latency streaming media data transmission scheduling system for industrial simulation, comprising: The dependency ledger creation module is used to form independent state units and incremental state units according to the simulation steps, write them to objects, versions, predecessor dependencies, cross-object dependencies, and commit slots, and create a dependency ledger. The submission support boundary determination module is used to determine the submission support boundary based on the submission version, retention status, and remaining slot time from the receiving end. The failure domain determination module is used to track unmet dependencies outside the submission support boundary. It calculates the duration of occupancy based on the amount of dependency data, queue occupancy, and link rate. When the occupancy time exceeds the remaining time of the slot, it determines the unreachable point and forms a failure domain along the subsequent dependencies. The recovery boundary determination module is used to sequentially obtain candidate boundaries from the simulation steps after the unreachable cut and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is greater than the duration of the independent state unit, the incremental dependency segment is replaced with the independent state unit to form a recovery closure. The candidate boundary whose duration of the first recovery closure does not exceed the remaining time of the slot is determined as the recovery boundary. The transmission qualification scheduling module is used to freeze the unrecovered transmission units within the failure domain, write the recovery closure into the recovery queue, and enable the transmission unit outside the failure domain to obtain transmission qualification when the recovery closure occupancy time after inserting the transmission unit outside the failure domain does not exceed the remaining time of the recovery boundary slot. The commit write-back module is used by the receiving end to verify and restore the integrity of the closure and the acceptance of dependencies, commit and return the record, and the sending end to update the commit support boundary and release subsequent transmission units based on the closure commit version.

[0157] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0158] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0159] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired means; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0160] 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 modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0161] In the several 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 modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 between apparatuses or modules may be electrical, mechanical, or other forms.

[0162] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0163] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0164] If the aforementioned functions are implemented as software functional modules 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.

[0165] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A low-latency streaming media data transmission scheduling method for industrial simulation, characterized in that, include: S1. According to the simulation steps, the state is formed into independent state units and incremental state units, and written to the object, version, predecessor dependency, cross-object dependency, and commit slot to establish a dependency ledger. S2. Determine the submission support boundaries based on the version submitted by the receiving end, the retention status, and the remaining time of the slot; S3. Track unmet dependencies outside the submission support boundary, calculate the duration based on the amount of dependency data, queue occupancy, and link rate; when the remaining time of the slot is exceeded, determine the unreachable segment and form a failure domain along the subsequent dependencies; S4. Starting from the simulation step after the unreachable cut, take candidate boundaries in sequence and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is longer than the duration of the independent state unit, replace the segment with the independent state unit to form a recovery closure. Take the first candidate boundary whose duration does not exceed the remaining time of the slot as the recovery boundary. S5. Freeze the unrecovered transmission units within the failure domain and write the recovery closure into the recovery queue; after inserting a transmission unit outside the failure domain, the transmission unit obtains the qualification to send when the recovery closure occupies no more than the remaining time of the recovery boundary slot. S6. The receiving end verifies and restores the integrity of the closure, accepts dependencies, commits, and returns a record; The sender updates the commit support boundary, releasing subsequent transport units that depend on the closure commit version.

2. The low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S1 includes: The prerequisite dependencies of the independent state unit are empty; The incremental state unit's preceding dependency is taken from the state unit in the same object whose simulation step identifier is smaller than the current simulation step, is closest to the current simulation step, and has been completed. If there are multiple revision versions of the simulation step, the state unit version with the largest revision number is taken. The state unit version is determined by the simulation task identifier, simulation step identifier, object identifier, and revision number. Existing dependencies will not change due to subsequent revisions. Cross-object dependencies are determined by the state representation relationship in the locking model configuration, and circular references are checked level by level before writing.

3. The low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S2 include: The receiving end submits a version associated with the state unit version used by each simulation object; The reserved state is a state unit version where the receiver can read the complete object state; The submission support boundary includes the set of supported state unit versions, the remaining time record of the submission slot, and the correspondence between independent state unit replacements; If the preceding dependency version is the version of the end state unit of the original incremental dependency segment in the corresponding relationship and is not in the set of supported state unit versions, and the corresponding independent state unit version is in the set, then the preceding dependency is considered to have been committed and supported by the boundary.

4. The low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S3 include: The same transmission record layer caliber is used depending on the amount of data, queue usage, and link speed. The link rate is the ratio of the number of valid bytes initially acknowledged by the receiver within the rate acknowledgment interval to the interval duration, and the duration occupied is the ratio of the sum of dependent data and queue occupancy to the link rate. State units whose duration exceeds the remaining time of the slot are considered out-of-limit state units. The first submission slot containing an out-of-limit state unit is obtained in ascending order of submission slots. All out-of-limit state unit versions within it constitute an unreachable point, which forms a failure domain along subsequent dependencies.

5. A low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S4 includes: Candidate boundaries are obtained incrementally according to the simulation steps after the unreachable cut, and missing dependencies are filled in backwards along the preceding dependencies and cross-object dependencies; An incremental dependency segment is the longest continuous sequence of state units for the same object that is connected along the preceding dependency, consists entirely of incremental state units, and has not reached the state position that has been submitted and supported. Candidate independent state units are formed from the solidified complete object state of the same object and the same simulation step as the end state unit of the segment.

6. A low-latency streaming media data transmission scheduling method for industrial simulation according to claim 5, characterized in that, The duration of the incremental dependency segment is determined by the ratio of the number of unacknowledged bytes of the actual deletable state unit after the segment is deleted to the link rate; The duration of an independent state unit is determined by the ratio of the amount of new bytes to be transmitted generated by candidate independent state units and cross-object dependencies to the same link rate. Replacement is performed when the duration of the incremental dependency segment exceeds the duration of the independent state unit. After all incremental dependency segments are judged, a recovery closure is formed. The candidate boundary whose first recovery closure occupies a duration that does not exceed the remaining time of the slot is taken as the recovery boundary.

7. A low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S5 include: The frozen transmission unit retains the status unit version, submitted slot, remaining bytes for which a complete transmission arrival confirmation has not yet been obtained from the receiving side, and the original queuing record, and cancels its eligibility to be directly selected from the normal transmission queue; The recovery queue is arranged according to the dependency relationship of the recovery closure, and multiple arrangeable transmission units are selected in the order of submission slot, object identifier and status unit version. Failed external transmission units are inserted sequentially. After insertion, the transmission qualification is obtained when the recovery closure occupancy time does not exceed the remaining time of the recovery boundary slot at the qualification determination time.

8. A low-latency streaming media data transmission scheduling method for industrial simulation according to claim 1, characterized in that, S6 include: The receiving end verifies the integrity of the recovery closure based on the state unit version set and the length of the complete record, and verifies the dependency inheritance according to the recovery queue order. When the pending state of the objects involved in the recovery closure is fully formed and the task time is earlier than the deadline of the recovery boundary commit slot, a unified switch is made to form the closure commit version, and the independent state unit is locked to replace the corresponding relationship. The sending end updates the commit support boundary based on the returned record, and only releases the commit slots that are later than the recovery boundary commit slots and all rely on the frozen transmission units that have been taken over by the commit support boundary.

9. A low-latency streaming media data transmission scheduling system for industrial simulation, used to implement the low-latency streaming media data transmission scheduling method for industrial simulation as described in any one of claims 1-8, characterized in that, include: The dependency ledger creation module is used to form independent state units and incremental state units according to the simulation steps, write them to objects, versions, predecessor dependencies, cross-object dependencies, and commit slots, and create a dependency ledger. The submission support boundary determination module is used to determine the submission support boundary based on the submission version, retention status, and remaining slot time from the receiving end. The failure domain determination module is used to track unmet dependencies outside the submission support boundary. It calculates the duration of occupancy based on the amount of dependency data, queue occupancy, and link rate. When the occupancy time exceeds the remaining time of the slot, it determines the unreachable point and forms a failure domain along the subsequent dependencies. The recovery boundary determination module is used to sequentially obtain candidate boundaries from the simulation steps after the unreachable cut and fill in the missing dependencies in reverse. When the duration of the incremental dependency segment is greater than the duration of the independent state unit, the incremental dependency segment is replaced with the independent state unit to form a recovery closure. The candidate boundary whose duration of the first recovery closure does not exceed the remaining time of the slot is determined as the recovery boundary. The transmission qualification scheduling module is used to freeze the unrecovered transmission units within the failure domain, write the recovery closure into the recovery queue, and enable the transmission unit outside the failure domain to obtain transmission qualification when the recovery closure occupancy time after inserting the transmission unit outside the failure domain does not exceed the remaining time of the recovery boundary slot. The commit write-back module is used by the receiving end to verify and restore the integrity of the closure and the acceptance of dependencies, commit and return the record, and the sending end to update the commit support boundary and release subsequent transmission units based on the closure commit version.

Images