A primary-secondary fusion ring box edge computing data interaction method and system

Abstract

This invention relates to the field of power edge communication and data interaction technology, and discloses a method and system for edge computing data interaction in a primary and secondary fusion ring network box, comprising: Step 1, collecting and encapsulating primary and secondary communication data, generating fusion objects and unique identifiers; Step 2, establishing binding relationships, determining integrity, scope, and interactive objects; Step 3, generating topology addresses and determining the target node set; Step 4, constructing self-describing interaction messages, generating differential text and structure check codes; Step 5, generating submission sequence numbers, performing version arbitration and release sorting, forming an edge sending queue; Step 6, sending messages and verifying them, updating the local object mirror table and local submission records; Step 7, determining the object convergence result based on the confirmation result, refreshing the sending-side object mirror or retaining pending records. This invention realizes the object-oriented organization, targeted interaction, version arbitration, and convergence confirmation of objectified data on the edge side of a primary and secondary fusion ring network box.

Description

Technical Field

[0001] This invention belongs to the field of power edge communication and data interaction technology, specifically relating to a primary and secondary integrated ring network box edge computing data interaction method and system. Background Technology

[0002] As distribution automation equipment becomes more integrated and miniaturized, integrated primary and secondary ring main units, in addition to undertaking tasks such as switch status acquisition, protection control, and operation monitoring, also need to exchange and transmit various types of data at the edge. In practical applications, primary-side status data, secondary-side status data, and communication configuration data are often generated separately by different units, with inconsistent data formats, update rhythms, and interaction ranges. This can easily lead to unclear object correspondences, unclear node reception ranges, and duplicate message transmissions. Current practices often organize data according to fixed point tables or fixed message types. Once the status changes, the entire packet often needs to be retransmitted, resulting in significant data redundancy. At the same time, different nodes use different methods to identify the same object, which can easily lead to version conflicts, duplicate submissions, and synchronization inconsistencies. Especially when there are hierarchical interactions between intra-station nodes, edge nodes, and upper-level nodes, the lack of a unified data organization, addressing, and acknowledgment mechanism makes it difficult to maintain continuous data interaction. Summary of the Invention

[0003] This invention provides a method and system for edge computing data interaction in a primary and secondary fusion ring network box, solving the technical problems in the background art.

[0004] This invention provides a method for data interaction in edge computing of primary and secondary fusion ring network boxes, comprising the following steps:

[0005] Step 1: Obtain the primary side status data, secondary side status data, and communication side configuration data corresponding to the primary and secondary fusion ring network box; merge and encapsulate the primary side status data, secondary side status data, and communication side configuration data to generate an edge computing fusion object; and generate a unique identifier for the fusion object.

[0006] Step 2: Establish binding relationships for edge computing fusion objects, determine object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects;

[0007] Step 3: Generate the topology address of the interactive object based on the unique identifier of the fusion object, the scope type, and the local topology description information, and determine the target node set based on the topology address and the node subscription relationship;

[0008] Step 4: Construct a self-describing interaction message for the interactive object, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate the differential text and structure check code.

[0009] Step 5: Generate a commit sequence number for the self-describing interaction message, and perform version arbitration and release sorting to form an edge sending queue;

[0010] Step 6: Send the self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local commit record when the verification passes.

[0011] Step 7: Determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, refresh the object image on the sending side; when the object convergence result indicates that convergence has not been completed, retain the pending record corresponding to the unconfirmed node.

[0012] This invention also provides a primary and secondary fusion ring network box edge computing data interaction system, comprising:

[0013] The object generation module is used to obtain the primary side status data, secondary side status data and communication side configuration data corresponding to the primary and secondary fusion ring network box, merge and encapsulate the primary side status data, secondary side status data and communication side configuration data, generate edge computing fusion objects, and generate a unique identifier for the fusion objects.

[0014] The object determination module is used to establish binding relationships for edge computing fusion objects, determine the object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects.

[0015] The address generation module is used to generate the topology address of interactive objects based on the unique identifier of the fusion object, the scope type, and the local topology description information, and to determine the target node set based on the topology address and the node subscription relationship.

[0016] The message construction module is used to construct a self-describing interactive message for interactive objects, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate differential text and structure check code.

[0017] The queue generation module is used to generate commit sequence numbers for self-describing interaction messages, and to perform version arbitration and release sorting to form an edge sending queue;

[0018] The message interaction module is used to send self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local submission record when the verification passes.

[0019] The convergence processing module is used to determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, the object image on the sending side is refreshed; when the object convergence result indicates that convergence has not been completed, the pending record corresponding to the unconfirmed node is retained.

[0020] The beneficial effects of this invention are as follows: This invention unifies primary-side state data, secondary-side state data, and communication-side configuration data into an edge computing fusion object, and establishes a continuous interaction link around the fusion object's unique identifier, topology address, self-describing interaction message, submission sequence number, and confirmation result. This reduces redundant data transmission caused by traditional whole-packet sending and ensures that the same object maintains a unified identification basis across different nodes. Furthermore, through differential text generation, version arbitration, target node-directed sending, and convergence determination processing, the edge-side data interaction process is made smoother, avoiding problems such as chaotic object mapping, duplicate submissions, and inconsistent node states, thereby improving the standardization, continuity, and inter-node collaboration of data interaction in the primary and secondary fusion ring network box scenario. Attached Figure Description

[0021] Figure 1 This is a flowchart of a primary and secondary fusion ring network box edge computing data interaction method according to the present invention. Detailed Implementation

[0022] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0023] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0024] like Figure 1 As shown, a method for data interaction in edge computing of a primary and secondary integrated ring network box includes the following steps:

[0025] Step 1: Obtain the primary side status data, secondary side status data, and communication side configuration data corresponding to the primary and secondary fusion ring network box; merge and encapsulate the primary side status data, secondary side status data, and communication side configuration data to generate an edge computing fusion object; and generate a unique identifier for the fusion object.

[0026] Step 2: Establish binding relationships for edge computing fusion objects, determine object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects;

[0027] Step 3: Generate the topology address of the interactive object based on the unique identifier of the fusion object, the scope type, and the local topology description information, and determine the target node set based on the topology address and the node subscription relationship;

[0028] Step 4: Construct a self-describing interaction message for the interactive object, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate the differential text and structure check code.

[0029] Step 5: Generate a commit sequence number for the self-describing interaction message, and perform version arbitration and release sorting to form an edge sending queue;

[0030] Step 6: Send the self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local commit record when the verification passes.

[0031] Step 7: Determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, refresh the object image on the sending side; when the object convergence result indicates that convergence has not been completed, retain the pending record corresponding to the unconfirmed node.

[0032] In one embodiment of the present invention, the system first obtains the primary-side status data, secondary-side status data, and communication-side configuration data corresponding to the primary and secondary fusion ring network boxes. Then, according to the correspondence of the same ring network box, the same interval, and the same functional affiliation, the system organizes, merges, and encapsulates the above data to generate an edge computing fusion object, and further generates a unique identifier for the fusion object. Here, instead of storing the three types of data separately and then temporarily splicing them together later, a unified object is formed before the data enters the interaction link, and then a unique index is established for this object.

[0033] In step 11, the system acquires the primary-side status data, secondary-side status data, and communication-side configuration data corresponding to the integrated primary and secondary ring network box. The primary-side status data includes bay affiliation status, switch position status, energy storage status, interlocking status, and occupancy status; the secondary-side status data includes protection action status, measurement and control enable status, alarm status, remote / local status, and execution result status; and the communication-side configuration data includes published topic identifier, subscribed topic identifier, source port identifier, target domain identifier, and model version number.

[0034] The published topic identifier refers to the topic identifier corresponding to when the data object sends out interactive information; the subscribed topic identifier refers to the topic identifier corresponding to when the data object receives external interactive information; the target domain identifier refers to the network range identifier that the data object is subsequently allowed to reach. In other words, this step not only obtains the device's operating status but also simultaneously acquires the configuration foundation upon which subsequent data organization and inter-node interaction depend. If a certain interval corresponds to a switch unit, then the switch position status, protection action status, and published topic identifier related to that switch unit should be obtained together and used as the original input for the same processing object.

[0035] In step 12, the system associates, organizes, merges, and encapsulates primary-side status data, secondary-side status data, and communication-side configuration data according to the correspondence of the same ring network box, the same interval, and the same functional affiliation, generating an edge computing fusion object. The edge computing fusion object refers to a data object formed by writing primary-side status data, secondary-side status data, and communication-side configuration data into the same object record, using the same interval object as a unified index.

[0036] It should be noted that "same function attribution" here refers to the fact that the three types of data all correspond to the same business processing unit or the same bay unit within the ring network enclosure, rather than being grouped into the same object simply because they are located in the same device. Specifically, during encapsulation, the system first verifies the consistency of the three types of data in terms of ring network enclosure identification, bay attribution, and function attribution, and then performs merging and writing. This ensures that the source of fields within the object is consistent and avoids data from different bays and different processing units being mistakenly encapsulated into the same object. If a bay is in a remote control state, the remote-local state, execution result state, and target domain identifier corresponding to that bay should be written into the same edge computing fusion object, and subsequent steps can directly call this object.

[0037] In step 13, the system extracts the ring network box identifier, interval identifier, source class identifier, and data item identifier corresponding to the edge computing fusion object, concatenates them according to a preset field length order to generate a unique identifier for the fusion object, and establishes a one-to-one correspondence between the unique identifier of the fusion object and the corresponding edge computing fusion object. The source class identifier is an identifier that distinguishes the source category of the edge computing fusion object; the data item identifier is an identifier that distinguishes the internal data organization category of the edge computing fusion object. The preset field length order means that each identifier field uses a fixed length and a fixed arrangement order when generating the unique identifier of the fusion object, and remains unchanged during system operation.

[0038] Through the above processing, each edge computing fusion object has a unique reference entry. Even if different edge computing fusion objects have the same state value, as long as their interval identifier or data item identifier is different, the generated fusion object unique identifier will also be different, which facilitates subsequent organization of interactive data at the object granularity, execution of address mapping, and completion of inter-node transmission control.

[0039] In summary, this section first completes the unified collection of primary-side status data, secondary-side status data, and communication-side configuration data; then it completes the object-oriented organization of edge computing fusion objects; and finally, it establishes a unique identifier for the fusion objects. Through the above processing, the system simultaneously fixes the object content and object identity at the starting point of data interaction, which not only enables subsequent steps to be processed continuously around the same index, but also ensures that data encapsulation, object addressing, and message organization remain seamless.

[0040] In one embodiment of the present invention, after generating an edge computing fusion object and establishing a unique identifier for the fusion object, the system continues to establish a binding relationship for the edge computing fusion object, determine the object integrity and scope type, and identify the edge computing fusion object that meets the object integrity condition as an interactive object.

[0041] In step 21, the system extracts primary-side status data, secondary-side status data, and communication-side configuration data from the edge computing fusion object, and marks each field in the edge computing fusion object as a primary-side field, secondary-side field, or communication-side field, establishing a binding relationship. This binding relationship refers to a fixed correspondence between each field within the edge computing fusion object and its corresponding data category, rather than simply listing the fields. Through this marking, the system can clearly determine whether a field represents a device's operating status, control status, or interactive configuration status. Subsequent calculations of object completeness or determination of scope type are based on this field category marking.

[0042] For example, the switch position status is marked as a primary side field, the remote-to-local status is marked as a secondary side field, and the target domain identifier is marked as a communication side field. Although the three belong to the same edge computing fusion object, the judgment criteria in subsequent processing are not the same.

[0043] In step 22, the system counts the number of fields with established binding relationships in the edge computing fusion object, counts the total number of fields in the edge computing fusion object, and then divides the number of fields with established binding relationships by the total number of fields to determine the object completeness. The object completeness can be expressed as: ,in, Indicates the first The object completeness of each edge computing fusion object; Indicates the first In the edge computing fusion object, the first The binding status of the first field, when the first field... When a binding relationship has been established between the fields The value is 1, when the first When no binding relationship has been established between the fields The value is 0; Indicates the first The total number of fields in an edge computing fusion object; Indicates the first The number of fields with established binding relationships in an edge computing fusion object.

[0044] The object completeness refers to the degree to which the fields within the edge computing fusion object have completed their attribution confirmation. When the object completeness is equal to 1, it means that all fields in the edge computing fusion object have established binding relationships; when the object completeness is less than 1, it means that there are still fields in the edge computing fusion object that have not established binding relationships. If all fields of an object have completed category labeling, the object completeness is in a complete state; if there are still fields that have not been labeled, the object completeness is less than a complete state. This is not simply a matter of quantity statistics, but rather a way to establish a unified basis for judging the completeness of the object as a whole based on the field-level attribution confirmation results.

[0045] In step 23, the system extracts the target domain identifier, publish topic identifier, subscribe topic identifier, and source port identifier from the communication-side configuration data, and determines the scope type accordingly. The scope type indicates the range of data interactions that the edge computing fusion object is allowed to participate in subsequently. Specifically, when the target domain identifier is limited to the current edge node, and both the publish topic identifier and the subscribe topic identifier correspond to the internal interaction range of the current edge node, the system determines the scope type as a local processing domain; when the target domain identifier is limited to a set of nodes within the site, and the publish topic identifier and the subscribe topic identifier correspond to the shared range within the site, the system determines the scope type as an intra-site shared domain; when the target domain identifier points to an inter-site node or an upstream gateway, and the publish topic identifier and the subscribe topic identifier correspond to the inter-site forwarding range, the system determines the scope type as an inter-site forwarding domain. The scope type here is not an isolated label, but rather a summary of the interaction range constraints in the communication-side configuration data. For example, if the same edge computing fusion object is only allowed to participate in state synchronization within the local machine, it should be classified as a local processing domain; if it needs to be sent to other nodes within the site, it should be classified as an intra-site shared domain.

[0046] In step 24, when the object integrity indicates that all fields in the edge computing fusion object have established binding relationships, the system determines the edge computing fusion object as an interactive object and writes the scope type into the interactive object record. The interactive object record refers to an object record that has completed field attribution confirmation, integrity determination, and scope type writing, and can be directly invoked by subsequent steps.

[0047] It should be noted that if the object's completeness does not meet the above conditions, the edge computing fusion object will not be included in the interactive object record, nor will it participate in topology address generation and target node determination. This ensures that the internal fields of objects entering the interaction link are clearly defined, and that each object has a clear interaction boundary before entering subsequent processing.

[0048] Through the above processing, after the edge computing fusion object is generated, the system further completes the fixation of field ownership, confirmation of object integrity, and determination of interaction range. This not only clarifies the internal structure of the object but also pre-limits the range that the object can subsequently reach. As a result, subsequent topology address generation, node subscription matching, and message organization can all revolve stably around the same object record, which better meets the requirements of object-oriented data interaction, directional transmission between nodes, and boundary-controlled processing in the primary and secondary fusion ring network box scenario.

[0049] In one embodiment of the present invention, after obtaining the interactive object, the system continues to generate the topology address of the interactive object based on the unique identifier of the fused object, the scope type, and the local topology description information, and further determines the target node set by combining the node subscription relationship. The previous stage has clarified the object identity and interaction boundaries, and this stage further clarifies what address the object should be organized by and which nodes should receive it, so that the subsequent generation and targeted transmission of self-describing interaction messages can continue to unfold along the same object link.

[0050] In step 31, the system extracts the unique identifier of the fusion object, the scope type, and the publication topic identifier from the communication-side configuration data corresponding to the interactive object. It also extracts the hierarchical identifier from the local topology description information. The hierarchical identifier, scope type, and unique identifier of the fusion object are combined according to a preset address field order to generate a topology address. The local topology description information refers to the local network organization information that the current ring network box edge node can perceive, including at least the hierarchical identifier, node subscription relationship, and node scope range. The hierarchical identifier indicates the hierarchical position of the object in the current network structure, and the topology address represents the address result that simultaneously contains object identity information and interaction boundary information. In other words, the topology address here is not a simple number in the general sense, but an addressing result that combines the object's hierarchical position, reachable range, and unique identifier. For example, the topology addresses generated by the same unique identifier of the fusion object under the local processing domain and the intra-site shared domain will be different, and the subsequent matched node ranges will also be different.

[0051] In step 32, the system reads the node subscription relationships from the local topology description information based on the published topic identifier, and determines the nodes that subscribe to the topic corresponding to the published topic identifier as the candidate node set. The node subscription relationship refers to the subscription records of each node for different topics; the candidate node set refers to the set of nodes that have met the receiving conditions at the topic level. Here, filtering is first performed based on the published topic identifier, rather than directly matching by topology address, because the topic relationship indicates the scope of a node's interest in the data content. Only nodes that have entered the acceptable range at the topic level need to undergo subsequent address matching. Through this process, the system first excludes nodes unrelated to the current object's content, and then continues boundary matching for the remaining nodes, making the processing chain clearer.

[0052] In step 33, the system reads the scope of each node in the candidate node set from the local topology description information, matches the scope of each node with the topology address, and determines the matching nodes as the target node set. A correspondence is then established between the interactive object, the topology address, and the target node set. The scope refers to the boundary description of objects a node is allowed to receive; the target node set refers to the set of nodes that simultaneously satisfy the topic subscription condition and the address boundary condition. This matching is not a simple comparison of whether fields are the same, but rather a determination of whether the scope of the candidate node covers the interaction boundary represented by the current topology address. If a candidate node has subscribed to the corresponding topic, but its scope is limited to the local processing domain, while the current topology address represents the inter-station forwarding domain, then the node cannot enter the target node set. After this processing, a stable correspondence is formed between the interactive object, the topology address, and the target node set. Subsequently, the sending side no longer re-selects nodes but directly uses this correspondence result to organize packet delivery.

[0053] Through the above processing, the system first generates the topology address at the object level, and then filters candidate nodes and determines the target node at the node level. The entire process unfolds sequentially along the link of interactive object, topology address, candidate node set, and target node set. The unique identifier and scope type of the fusion object obtained in the previous step continue to be directly called as the addressing basis in this stage; the topology address and target node set output in this stage will continue to serve as input for subsequent message generation and message sending. This ensures that the object identity, interaction scope, and receiving node range remain continuous and consistent, and that data delivery between nodes has clear object indexes and boundary constraints, which better meets the processing requirements of edge-side object addressing and directional interaction in the primary and secondary fusion ring network box scenario.

[0054] In one embodiment of the present invention, after generating the topology address of the interactive object and determining the target node set, the system continues to construct a self-describing interaction message for the interactive object, and compares the interactive object with the previous submission value in the edge-side object mirror table to generate differential text and structure checksum. Through the above processing, the current state, historical submission state, and message structure information of the interactive object are uniformly incorporated into the same processing link, eliminating the need to separately search for object content and historical records later.

[0055] In step 41, the system extracts the unique identifier of the fusion object, the topology address, and the model version number from the communication-side configuration data corresponding to the interactive object, and establishes a self-describing interactive message containing the unique identifier of the fusion object, the model version number, the topology address, the submission sequence number field, the message body field, and the structure checksum field. The self-describing interactive message refers to a message structure that simultaneously carries object identity information, version information, addressing information, content information, and verification information within the message. The submission sequence number field is reserved in this step and will be written with the specific submission sequence number later. The message body field is used to carry the subsequently generated differential text, and the structure checksum field is used to carry the subsequently calculated structure checksum. In other words, this step first fixes the message skeleton, so that subsequent field comparison results and verification results can be written into a unified message, rather than temporarily splicing different content later. If an interactive object already has a definite unique identifier and topology address, the basic field structure of the self-describing interactive message remains unchanged regardless of subsequent field changes.

[0056] In step 42, the system reads the previous submitted value from the edge-side object mirror table, which corresponds to the unique identifier of the fused object and is stored in the fixed field order of the interactive objects. Then, following the fixed field order of the interactive objects, it compares each field value of the interactive object with the previous submitted value field by field. Fields with inconsistent values ​​are identified as changed fields and encapsulated into differential text according to the fixed field order of the interactive objects, then written into the message body field. The edge-side object mirror table refers to the historical submission record table of objects stored on the sending side; the previous submitted value refers to the most recent submitted field value record corresponding to the unique identifier of the current fused object; the fixed field order refers to the field arrangement order determined when the interactive object is created, which remains consistent during the comparison and encapsulation phases. This does not involve rewriting all fields of the interactive object into the message body field; instead, it first identifies the changed fields and then writes them into the differential text in the predetermined order. This ensures a one-to-one correspondence between the message body content and the actual changes in the object, and also allows the receiving side to restore the object state according to the same field order. For example, if only the alarm status and target domain identifier change in the interactive object, then only the current field values ​​corresponding to these two fields are written into the differential message body, and other unchanged fields are not included in the message body fields.

[0057] In step 43, the system concatenates the unique identifier of the fused object, model version number, topology address, and message body field according to the field order of a self-describing interaction message. It then performs a cyclic redundancy check (CRC) calculation on the concatenated result to obtain a structure checksum, which is written into the structure checksum field. The structure checksum refers to the integrity verification result calculated based on the key fields in the message. The unique identifier of the fused object, model version number, topology address, and message body field are chosen as the calculation input because these parts correspond to object identity, object version, object addressing, and object change content, respectively, covering the core parts of the message structure. Through this processing, when the receiving side reads the message, it only needs to reorganize the input content according to the same field order and perform the same checksum calculation to determine whether the received message content is consistent with that generated by the sending side. If the message body field changes, the structure checksum will also change accordingly, thus reflecting whether the main content of the message has been modified.

[0058] Through the above steps, the system first fixes the field framework of the self-describing interaction message, then extracts the changed fields based on the previous commit value in the edge-side object mirror table, and finally incorporates the key fields into the structure verification calculation to complete the organization of the self-describing interaction message. This ensures that the message content always revolves around the unique identifier of the same fused object, allows the differences between the current state and the historical commit state of the object to be directly converted into a transmittable message body, and simultaneously establishes the basis for integrity verification during the message generation stage. Subsequent commit sequence number generation, version arbitration, and sending sorting can all be directly based on this self-describing interaction message, with consistent data entry points between steps, resulting in a smoother processing chain.

[0059] In one embodiment of the present invention, after the system completes the construction of the self-describing interaction message, the generation of the differential text, and the writing of the structure checksum, it continues to generate a submission sequence number for the self-describing interaction message and performs version arbitration and release sorting to form an edge sending queue. The focus here is not on readjusting the message content, but on further transforming the self-describing interaction message, which already possesses object identity, version information, addressing information, and differential text, into a sortable, arbitrable, and sendable message unit. Through this stage of processing, if multiple candidate messages exist for the same object within the same sending cycle, the system can first perform deduplication and selection, and then provide a unified sending order. Subsequent sending sides no longer face an unordered set of messages, but directly execute delivery according to the edge sending queue.

[0060] In step 51, the system reads the current edge node identifier, source class identifier, and local monotonically increasing count value maintained by the current edge node for the interactive object corresponding to the self-describing interaction message. These three are combined in a preset bit-width order to generate a submission sequence number, which is then written into the submission sequence number field. The current edge node identifier indicates the sending node source of the message, the source class identifier indicates the source category of the object to which the message belongs, and the local monotonically increasing count value indicates the continuously increasing count result maintained by the current edge node for the interactive object. Instead of simply writing a sequential number, the node source information, object source category, and local increasing order are all written into the submission sequence number. This distinguishes messages sent from different edge nodes, messages from different categories of objects under the same edge node, and the order in which the same object was generated locally. Through this processing, subsequent comparisons of message age no longer rely on temporary judgments but directly use the submission sequence number as the order basis.

[0061] In step 52, the system groups self-describing interaction messages with written submission sequence numbers according to the unique identifier of the fusion object. For self-describing interaction messages in the same group, it first compares the model version number, then the submission sequence number, and finally the structure checksum. One of these is retained as the currently valid message, and self-describing interaction messages with inconsistent structure checksums are discarded. The currently valid message refers to the only message retained after version arbitration within the unique identifier range of the same fusion object. This process does not directly send all messages into the sending stage, but first limits arbitration to the same object range. That is, messages with higher model version numbers are retained first; if the model version numbers are the same, the submission sequence number is compared; if the first two cannot distinguish, the structure checksum is checked. If the structure checksum is inconsistent, it indicates that the message structure content is abnormal, and the message will not enter the subsequent sorting process. After this processing, only one currently valid message is retained for the same object in the same round of sending, making the subsequent sorting basis more stable.

[0062] In step 53, the system reads the object category level from the interactive object record corresponding to the currently valid message, and compares the current field value of the status field in the differential text with the corresponding field value of the status field in the previous submission. If a state boundary crossing occurs, the object state inversion marker is determined as an inversion marker; otherwise, it is determined as an uninverted marker. The object category level refers to the level result pre-set by the system for different object categories; a state boundary crossing refers to a status field switching from one state interval to another, rather than just a minor numerical change. For example, if a status field changes from a normal state to an alarm state, or from an idle state to an occupied state, it can be considered a state boundary crossing. Through this processing, the system not only knows which object category the message belongs to, but also identifies whether the object has undergone a state transition worthy of priority transmission, thus providing a more interaction-compliant judgment basis for the next sorting step.

[0063] In step 54, the system first sorts the packets by object category level from highest to lowest, then by object state inversion markers (prioritizing those with inverted markers), then by the total number of changed fields from highest to lowest, and finally by submission sequence number from highest to lowest. The sorted current valid packets and their corresponding target node sets are then written into the edge sending queue. This sorting is not a single-dimensional sorting, but rather a layer-by-layer convergence according to a predetermined order, moving to the next layer only when the previous layer cannot distinguish between them. Object category level indicates the order of packets at the object level, object state inversion markers indicate the urgency of state changes, the total number of changed fields indicates the scale of message content changes, and the submission sequence number further indicates the generation order of packets at the same level. Through this processing, the system fixes the current valid packets and their corresponding target node sets into a unified sending order. Subsequent sending only requires processing them item by item according to the queue order, without the need for further arbitration or re-sorting.

[0064] Through the above steps, the system first generates the submission sequence number, then arbitrates messages for the same object, subsequently adds object category level and object state inversion markers, and finally forms an edge sending queue. This not only reduces the problem of multiple messages for the same object to a single message problem, but also pre-determines the sending priority, enabling subsequent interactions between nodes to unfold continuously around a single valid message, a single target node set, and a single sending order, resulting in a more stable connection between the preceding and following steps.

[0065] In one embodiment of the present invention, after forming an edge sending queue, the system continues to send the currently valid packets in the edge sending queue to the corresponding set of target nodes. The target nodes then perform verification on the currently valid packets, updating their local object mirror table and local commit records upon successful verification. This embodiment delivers the sorted currently valid packets to the receiving side according to a predetermined range of target nodes, and establishes a unified commit determination entry point on the receiving side. Through this stage of processing, the sending side obtains node-by-node confirmation results, while the receiving side completes object state updates or rejects the commit, thus providing a clear basis for subsequent convergence determination.

[0066] In step 61, the system sends the currently valid packets in the edge sending queue to the corresponding set of target nodes. Each target node reads its local subscription table, local version compatibility table, local object mirror table, and local commit record corresponding to the unique identifier of the fusion object. The local subscription table refers to the object reception range record stored internally by the target node; the local version compatibility table refers to the compatibility relationship record established by the target node for model version numbers; the local object mirror table refers to the record table storing the current valid state of objects by the target node; and the local commit record refers to the most recent commit sequence number record retained by the target node for packets received for the same unique identifier of the fusion object. This process does not end with simply sending the currently valid packets to the target nodes; rather, the target nodes synchronously prepare the local basis required for subsequent verification, ensuring that the reception processing always revolves around the same unique identifier of the fusion object.

[0067] In step 62, each target node sequentially performs subscription verification, version compatibility verification, structure verification, and commit sequence number verification on the currently valid message. If all four verifications pass, the reception pass determination value is determined as passed; if any verification fails, the reception pass determination value is determined as failed. Subscription verification checks whether the object corresponding to the currently valid message is within the allowed reception range of the local subscription table. Version compatibility verification checks whether the model version number in the currently valid message is consistent with the local version compatibility table. Structure verification involves the target node reorganizing the key fields according to the same field order as the sender, performing the same verification calculation, and then comparing it with the structure checksum carried in the message. Commit sequence number verification compares the commit sequence number of the currently valid message with the committed sequence numbers in the local commit record; subsequent commits are only allowed if the commit sequence number of the currently valid message is updated.

[0068] In other words, these four checks are not interchangeable, but rather sequentially valid. If any check is not met, the currently valid message cannot enter the local submission stage. For example, if the target node has already subscribed to the object and the model version number is compatible, but the structure check results are inconsistent, it should still be directly judged as failing.

[0069] In step 63, when the received pass judgment value indicates success, the system merges the differential text into the local object mirror table and writes the submission sequence number into the local submission record corresponding to the unique identifier of the fused object. This merging and writing does not completely overwrite the entire record in the local object mirror table; instead, it updates the corresponding fields in the local object mirror table item by item according to the changed fields contained in the differential text of the currently valid message, while the remaining unchanged fields retain their original content.

[0070] Subsequently, the submission sequence number of the currently valid message is written to the local submission record, ensuring that the internal object content status and object submission order status of the target node are kept synchronized. If the differential message body contains alarm status fields and target domain identifier fields, the corresponding fields in the local object mirror table will be updated, while fields such as switch position status that remain unchanged will remain unchanged.

[0071] In step 64, when the acceptance judgment value indicates failure, the system rejects the submission and generates a failure reason identifier; then, based on the acceptance judgment value, the unique identifier of the fusion object, and the submission sequence number, a confirmation result is generated, and if a failure reason identifier exists, it is written and sent back. The failure reason identifier refers to an identifier result used to indicate the direct reason for this submission rejection, and it can at least distinguish between subscription verification failure, version compatibility verification failure, structure verification failure, and submission sequence number verification failure.

[0072] The confirmation result here not only indicates whether it passed or failed, but also includes object identity information and submission order information. Therefore, after receiving the confirmation result, the sending side can accurately pinpoint which object, which submission, and at what node passed or failed. Through this processing, the receiving side will not update its local object mirror table due to erroneous messages that do not meet the conditions, and can also clearly report the source of the failure to the sending side.

[0073] Through the above steps, the system first delivers currently valid messages according to the edge sending queue, and then the target node performs verification and submission processing item by item based on the local subscription table, local version compatibility table, local object mirror table, and local commit records. This ensures that the object update on the receiving side is based on unified judgment conditions, and also ensures that the subsequent convergence analysis on the sending side is based on the confirmation results of each node, each object, and each commit sequence number, maintaining the continuity of the processing link before and after.

[0074] In one embodiment of the present invention, after the target node completes the reception determination of the currently valid message and returns an acknowledgment result, the system continues to determine the object convergence result based on the acknowledgment result returned by the target node. When the object convergence result indicates that convergence is complete, the sending-side object image is refreshed; when the object convergence result indicates that convergence is not complete, the pending record corresponding to the unacknowledged node is retained. This embodiment re-aggregates the acknowledgment results scattered across various target nodes to the sending side, determining whether the same currently valid message has completed a closed loop within the target node set. In other words, this step addresses the question of when the sending side should advance the object version and when to retain subsequent processing entry points.

[0075] In step 71, the system merges the acknowledgment results returned by the target nodes according to the unique identifier and submission sequence number of the fusion object. Acknowledgment results with a pass / fail judgment value in the target node set are identified as valid acknowledgment results, and duplicate valid acknowledgment results from the same target node are retained only once. This merging is not simply putting the acknowledgment results together; rather, it first limits them to a group of acknowledgment results corresponding to the same unique identifier and submission sequence number of the fusion object, and then filters out the portion that truly indicates successful reception from this group. Retaining duplicate valid acknowledgment results only once is to avoid amplifying subsequent statistics due to repeated transmissions from the same target node. After this process, each currently valid message corresponds to a set of clearly defined valid acknowledgment results, preventing object mixing or duplicate node counting issues when calculating object convergence later.

[0076] In step 72, the system counts the number of target nodes corresponding to valid confirmation results to obtain the number of valid confirmations; then it counts the total number of target nodes corresponding to the target node set; finally, it divides the number of valid confirmations by the total number of target nodes to determine the object convergence. The object convergence represents the completion ratio of the current valid messages in the target node set. Here, it does not simply look at whether any node returns a pass result, but compares the number of target nodes that have completed confirmation with the total number of target nodes that should have completed confirmation on the same scale.

[0077] If a currently valid message corresponds to four target nodes, and three of them return valid acknowledgments, the convergence of the object is three-quarters; if all four nodes return valid acknowledgments, the convergence of the object is one. In this way, objects with different target node sizes can be judged for loop closure using the same method, and subsequent processing on the sending side is more likely to maintain consistency.

[0078] In step 73, when the object convergence degree equals one, the system determines the object convergence result as complete convergence and writes the differential text, commit number, and object version information corresponding to the current valid message into the sending-side object mirror. The sending-side object mirror refers to the record stored on the sending side showing the latest completed loop closure state of the object. This writing action is not performed immediately after the message is sent, but only after all target nodes in the target node set have completed valid acknowledgments. This ensures that the sending-side object mirror is consistent with the actual completed state on the receiving side and prevents an object from prematurely advancing its version before completing loop closure. In other words, the sending-side object mirror truly represents the finalized object state in this round of interaction at this stage.

[0079] In step 74, when the object convergence is less than one, the system determines the object convergence result as incomplete, identifies the target nodes in the target node set that have not generated valid acknowledgments as unacknowledged nodes, and writes the current valid message, the unique identifier of the fused object, the submission sequence number, and the unacknowledged node into the pending processing record. Here, "not generating a valid acknowledgment result" includes both target nodes that did not return acknowledgments and those that returned acknowledgments but did not form a valid acknowledgment. The pending processing record refers to the record entry reserved by the sending side for subsequent processing of the object. After this processing, the sending side does not need to reprocess the entire target node set; it only needs to continue subsequent actions around the unacknowledged nodes, resulting in a more focused scope and a clearer processing chain.

[0080] After this stage, the system first consolidates the scattered confirmation results under the same unique identifier and submission sequence number of the same fusion object, then obtains the number of valid confirmations and the object convergence degree, and then processes them separately according to whether convergence is complete or not. This ensures that the refresh of the sending side object image is based on a complete closed loop, and also leaves clear pending records for objects that have not completed the closed loop. At this point, the entire object interaction process forms a relatively complete closing link.

[0081] This invention also provides a primary and secondary fusion ring network box edge computing data interaction system, comprising:

[0082] The object generation module is used to obtain the primary side status data, secondary side status data and communication side configuration data corresponding to the primary and secondary fusion ring network box, merge and encapsulate the primary side status data, secondary side status data and communication side configuration data, generate edge computing fusion objects, and generate a unique identifier for the fusion objects.

[0083] The object determination module is used to establish binding relationships for edge computing fusion objects, determine the object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects.

[0084] The address generation module is used to generate the topology address of interactive objects based on the unique identifier of the fusion object, the scope type, and the local topology description information, and to determine the target node set based on the topology address and the node subscription relationship.

[0085] The message construction module is used to construct a self-describing interactive message for interactive objects, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate differential text and structure check code.

[0086] The queue generation module is used to generate commit sequence numbers for self-describing interaction messages, and to perform version arbitration and release sorting to form an edge sending queue;

[0087] The message interaction module is used to send self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local submission record when the verification passes.

[0088] The convergence processing module is used to determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, the object image on the sending side is refreshed; when the object convergence result indicates that convergence has not been completed, the pending record corresponding to the unconfirmed node is retained.

[0089] It should be noted that the interval and threshold sizes are set for ease of comparison. The size of the threshold depends on the amount of sample data and the base number set by those skilled in the art for each set of sample data, as long as it does not affect the proportional relationship between the parameter and the quantized value. Furthermore, the above formulas are all dimensionless calculations, and the formulas are derived from software simulations using a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0090] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. A primary-secondary fusion ring box edge computing data interaction method, characterized in that, Includes the following steps: Step 1: Obtain the primary side status data, secondary side status data, and communication side configuration data corresponding to the primary and secondary fusion ring network box; merge and encapsulate the primary side status data, secondary side status data, and communication side configuration data to generate an edge computing fusion object; and generate a unique identifier for the fusion object. Step 2: Establish binding relationships for edge computing fusion objects, determine object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects; Step 3: Generate the topology address of the interactive object based on the unique identifier of the fusion object, the scope type, and the local topology description information, and determine the target node set based on the topology address and the node subscription relationship; Step 4: Construct a self-describing interaction message for the interactive object, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate the differential text and structure check code. Step 5: Generate a commit sequence number for the self-describing interaction message, and perform version arbitration and release sorting to form an edge sending queue; Step 6: Send the self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local commit record when the verification passes. Step 7: Determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence is complete, refresh the object image on the sending side. When the object convergence result representation has not yet converged, the pending record corresponding to the unconfirmed node is retained.

2. The primary-secondary fusion ring box edge computing data interaction method according to claim 1, characterized in that, Obtain the primary-side status data, secondary-side status data, and communication-side configuration data corresponding to the primary and secondary fusion ring network box. Merge and encapsulate the primary-side status data, secondary-side status data, and communication-side configuration data to generate an edge computing fusion object, and generate a unique identifier for the fusion object, including: Step 11: Obtain the primary side status data, secondary side status data, and communication side configuration data corresponding to the primary and secondary integrated ring network box. The primary side status data includes the bay ownership status, switch position status, energy storage status, interlocking status, and occupancy status. The secondary side status data includes the protection action status, measurement and control enable status, alarm status, remote and local status, and execution result status. The communication side configuration data includes the published topic identifier, subscribed topic identifier, source port identifier, target domain identifier, and model version number. Step 12: According to the correspondence of the same ring network box, the same interval, and the same function, the primary side status data, the secondary side status data, and the communication side configuration data are associated, organized, merged, and encapsulated to generate an edge computing fusion object; Step 13: Extract the ring network box identifier, interval identifier, source class identifier, and data item identifier corresponding to the edge computing fusion object, concatenate them in the order of preset field length to generate a unique identifier for the fusion object, and establish a one-to-one correspondence between the unique identifier of the fusion object and the corresponding edge computing fusion object.

3. The primary-secondary fusion ring box edge computing data interaction method according to claim 1, characterized in that, Establish binding relationships for edge computing fusion objects, determine object integrity and scope type, and identify edge computing fusion objects that meet the integrity requirements as interactive objects, including: Step 21: Extract primary-side status data, secondary-side status data, and communication-side configuration data from the edge computing fusion object, and mark each field in the edge computing fusion object as a primary-side field, secondary-side field, or communication-side field, and establish a binding relationship. Step 22: Count the number of fields with established binding relationships in the edge computing fusion object, count the total number of fields in the edge computing fusion object, divide the number of fields with established binding relationships by the total number of fields, and determine the object completeness. Step 23: Extract the target domain identifier, published topic identifier, subscribed topic identifier, and source port identifier from the communication side configuration data; when the target domain identifier is limited to the current edge node and the published topic identifier and subscribed topic identifier correspond to the internal interaction range of the current edge node, determine the scope type as local processing domain; when the target domain identifier is limited to the set of nodes within the site and the published topic identifier and subscribed topic identifier correspond to the shared range within the site, determine the scope type as shared domain within the site; when the target domain identifier points to an inter-site node or an upstream gateway and the published topic identifier and subscribed topic identifier correspond to the inter-site forwarding range, determine the scope type as inter-site forwarding domain. Step 24: When all fields in the edge computing fusion object representing object integrity have been bound together, the edge computing fusion object is identified as an interactive object, and the scope type is written into the interactive object record.

4. The primary-secondary fusion ring box edge computing data interaction method according to claim 1, characterized in that, Based on the unique identifier of the fusion object, its scope type, and local topology description information, the topology address of the interactive object is generated, and the target node set is determined based on the topology address and node subscription relationships, including: Step 31: Extract the unique identifier of the fusion object, the scope type, and the publication topic identifier from the communication side configuration data corresponding to the interactive object; extract the hierarchical identifier from the local topology description information; and combine the hierarchical identifier, scope type, and unique identifier of the fusion object according to the preset address field order to generate the topology address. Step 32: Read the node subscription relationship in the local topology description information according to the published topic identifier, and determine the nodes that subscribe to the topic corresponding to the published topic identifier in the node subscription relationship as the candidate node set; Step 33: Read the scope of each node in the candidate node set in the local topology description information, match the scope of each node with the topology address, determine the matching nodes as the target node set, and establish a correspondence between the interactive object, the topology address and the target node set.

5. The primary-secondary fusion ring box edge computing data interaction method according to claim 1, characterized in that, For interactive objects, a self-describing interaction message is constructed. The interactive object is compared with the previous submitted value in the edge-side object mirror table to generate a differential text and a structure checksum, including: Step 41: Extract the unique identifier of the fusion object, the topology address, and the model version number from the communication side configuration data corresponding to the interactive object, and establish a self-descriptive interactive message containing the unique identifier of the fusion object, the model version number, the topology address, the submission sequence number field, the message body field, and the structure check code field. Step 42: Read the previous submission value in the edge-side object mirror table that corresponds to the unique identifier of the fusion object and is stored in the fixed field order of the interactive object. Compare the field values ​​of each interactive object with the previous submission value field by field according to the fixed field order of the interactive object. Identify the fields with inconsistent field values ​​as changed fields, and encapsulate them into differential text according to the fixed field order of the interactive object and write them into the message body field. Step 43: Concatenate the unique identifier of the fusion object, the model version number, the topology address, and the message body field according to the field order of the self-describing interaction message. Perform cyclic redundancy check calculation on the concatenation result to obtain the structure check code, and write the structure check code into the structure check code field.

6. The method for edge computing data interaction of a primary and secondary fusion ring network box according to claim 1, characterized in that, For self-describing interaction messages, a commit sequence number is generated, and version arbitration and release sorting are performed to form an edge sending queue, including: Step 51: Read the current edge node identifier, source class identifier, and local monotonically increasing count value maintained by the current edge node for the interactive object corresponding to the self-description interaction message. Combine the three in the order of preset bit width to generate a submission sequence number and write it into the submission sequence number field. Step 52: Group the self-description interaction messages with written submission sequence numbers according to the unique identifier of the fusion object. For self-description interaction messages in the same group, first compare the model version number, then compare the submission sequence number, and finally compare the structure check code. Keep one of them as the current valid message and remove self-description interaction messages with inconsistent structure check codes. Step 53: Read the object category level in the interactive object record corresponding to the current valid message, compare the current field value of the status field in the differential text with the field value of the corresponding status field in the previous submission value, and determine the object state flip mark as a flip mark when there is a state boundary crossing, and determine the object state flip mark as a non-flip mark when there is no state boundary crossing. Step 54: First, sort the objects by category level from high to low, then sort by object status flipping markers (prioritizing non-flipped markers), then sort by the total number of changed fields from most to least, and finally sort by submission sequence number from largest to smallest. Write the sorted current valid messages and their corresponding target node sets into the edge sending queue.

7. The method for edge computing data interaction of a primary and secondary fusion ring network box according to claim 1, characterized in that, The self-describing interaction messages in the edge sending queue are sent to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update their local object mirror table and local commit records when the verification passes, including: Step 61: Send the currently valid packets in the edge sending queue to the corresponding set of target nodes. Each target node reads the local subscription table, the local version compatibility table, the local object mirror table, and the local commit record corresponding to the unique identifier of the fusion object. Step 62: Each target node performs subscription verification, version compatibility verification, structure verification and submission sequence number verification on the current valid message in sequence. If all four verifications pass, the receiving pass value is determined as passed. If any one of the verifications fails, the receiving pass value is determined as failed. Step 63: When the received pass judgment value indicates pass, merge the differential text into the local object mirror table and write the submission sequence number into the local submission record corresponding to the unique identifier of the fused object. Step 64: If the acceptance judgment value indicates failure, reject the submission and generate a failure reason identifier; generate a confirmation result based on the acceptance judgment value, the unique identifier of the fusion object and the submission sequence number, and write the failure reason identifier and send it back if it exists.

8. The method for edge computing data interaction of a primary and secondary fusion ring network box according to claim 1, characterized in that, The object convergence result is determined based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, the object image on the sending side is refreshed. When the object convergence result representation has not yet converged, the pending records corresponding to the unconfirmed nodes are retained, including: Step 71: Merge the confirmation results returned by the target node according to the unique identifier and submission sequence number of the fusion object. Determine the confirmation results in the target node set that have a pass judgment value as valid confirmation results, and retain one valid confirmation result for the same target node. Step 72: Count the number of target nodes corresponding to the valid confirmation results to obtain the number of valid confirmations; count the total number of target nodes corresponding to the target node set; divide the number of valid confirmations by the total number of target nodes to determine the convergence of the object. Step 73: When the object convergence is equal to one, the object convergence result is determined as complete convergence, and the differential text, submission sequence number and object version information corresponding to the current valid message are written to the sending side object image. Step 74: When the object convergence is less than one, the object convergence result is determined as incomplete convergence, the target nodes in the target node set that have not generated valid confirmation results are determined as unconfirmed nodes, and the current valid message, the unique identifier of the fused object, the submission sequence number and the unconfirmed node are written into the pending processing record.

9. A primary and secondary integrated ring network box edge computing data interaction system, characterized in that, The method for data interaction in edge computing of a primary and secondary fusion ring network box as described in any one of claims 1-8 includes: The object generation module is used to obtain the primary side status data, secondary side status data and communication side configuration data corresponding to the primary and secondary fusion ring network box, merge and encapsulate the primary side status data, secondary side status data and communication side configuration data, generate edge computing fusion objects, and generate a unique identifier for the fusion objects. The object determination module is used to establish binding relationships for edge computing fusion objects, determine the object integrity and scope type, and identify edge computing fusion objects that meet the object integrity conditions as interactive objects. The address generation module is used to generate the topology address of interactive objects based on the unique identifier of the fusion object, the scope type, and the local topology description information, and to determine the target node set based on the topology address and the node subscription relationship. The message construction module is used to construct a self-describing interactive message for interactive objects, compare the interactive object with the previous submitted value in the edge-side object mirror table, and generate differential text and structure check code. The queue generation module is used to generate commit sequence numbers for self-describing interaction messages, and to perform version arbitration and release sorting to form an edge sending queue; The message interaction module is used to send self-describing interaction messages in the edge sending queue to the corresponding set of target nodes. The target nodes perform verification on the self-describing interaction messages and update the local object mirror table and local submission record when the verification passes. The convergence processing module is used to determine the object convergence result based on the confirmation result returned by the target node. When the object convergence result indicates that convergence has been completed, the object image on the sending side is refreshed; when the object convergence result indicates that convergence has not been completed, the pending record corresponding to the unconfirmed node is retained.

Images