Guardrail topological graph generation system based on guardrail connection identification

Abstract

The invention relates to the field of guardrail topology generation, and particularly discloses a guardrail topological graph generation system based on guardrail connection identification, which comprises the following steps: firstly, acquiring an original signal flow generated by connection or disconnection operation in real time through a sensor deployed at a guardrail connection port; the signals are then parsed into a structured event list. By analyzing the time sequence of the events, the active connection event of one guardrail is matched with the passive connection event of the other guardrail in an extremely short time window, so that the connection relationship between the guardrails is accurately identified. Once the connection relation is confirmed, nodes representing guardrails and edges representing connection are generated on the basis, and a logic topological graph is formed. And finally, performing visualization processing on the logic diagram to generate a visual layout form image. Therefore, the real-time and remote visual supervision of the guardrail topology is realized, and the construction management efficiency and the safety response speed are effectively improved.

Description

Technical Field

[0001] This application relates to the field of guardrail topology generation, and more specifically, to a guardrail topology graph generation system based on guardrail connection recognition. Background Technology

[0002] In modern construction management and public safety maintenance, prefabricated warning barriers, as a flexible modular structure, are widely used for temporary isolation and area demarcation. However, with increasingly complex application scenarios, how to efficiently and accurately grasp the real-time deployment status of the barriers has become a pressing technical challenge. Especially in large construction sites or emergency response areas, maintenance personnel urgently need a digital platform to remotely view the physical connection topology of the barriers in order to confirm their deployment form in real time, such as straight lines, branches, or closed structures. This lack of visualization capability not only seriously affects the efficiency of construction supervision but also delays the speed of safety response to accident areas. Therefore, building a system that can automatically identify the connection relationships of barriers and generate topology maps is crucial.

[0003] Currently, the management of guardrail connection status largely relies on traditional manual methods. Maintenance personnel register the connection sequence, direction, and overall topology of the guardrails through on-site inspections and manual recording. This method is not only inefficient but also highly susceptible to human error, leading to errors or omissions and making it difficult to trace and verify historical status. More importantly, during the dynamic process of frequent connection and disconnection of guardrail nodes, the connection direction changes frequently, and traditional manual recording methods are completely inadequate for real-time and accurate identification of such dynamic connection relationships. The lack of effective automated solutions in existing technologies is mainly due to the multiple technical challenges involved in signal acquisition of guardrail connection events, logical judgment of complex connection relationships, and dynamic generation of topology diagrams, resulting in an exceptionally complex construction of automated systems.

[0004] To overcome the above-mentioned shortcomings, a fence topology map generation scheme based on fence connection recognition is desired, which can realize real-time and accurate visualization of fence layout, and improve construction supervision efficiency and safety response capabilities. Summary of the Invention

[0005] To address the difficulties in dynamic connection identification and the complexity of topology graph generation in existing technologies, this application is proposed. According to this application, a fence topology graph generation system based on fence connection identification includes: The raw signal stream acquisition module is used to acquire the raw signal stream; The raw signal stream normalization module is used to normalize the raw signal stream to obtain an event list; The connection pair matching and recognition module is used to perform connection pair timing matching and recognition on the event list to obtain a connection pair list; The topology graph construction module is used to construct topology nodes and connecting edges based on the list of connection pairs and the list of all fence IDs to obtain a topology graph. The topology rendering module is used to visualize and render the topology graph to obtain the rendered topology graph image.

[0006] Compared with existing technologies, this application provides a fence topology map generation system based on fence connection identification, which transforms physical connection events into visualized digital graphics through time-series analysis. First, sensors deployed at the fence connection ports acquire the raw signal streams generated by connection or disconnection operations in real time. Then, these signals are parsed into a structured event list containing fence numbers, event ports, and precise timestamps. By analyzing the temporal sequence of events, an active connection event of one fence is matched with a passive connection event of another fence within a very short time window, thereby accurately identifying the connection relationships between fences. Once the connection relationship is confirmed, nodes representing fences and edges representing connections are generated, forming a logical topology map. Finally, the logical map is visualized to generate an intuitive layout image. This automated signal acquisition and time-series matching solves the problems of low efficiency and error-proneness of traditional manual recording, accurately captures dynamically changing connection states, and ultimately achieves real-time, remote, visualized monitoring of the fence topology, effectively improving construction management efficiency and safety response speed. Attached Figure Description

[0007] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0008] Figure 1 This is a block diagram of a fence topology graph generation system based on fence connection identification according to an embodiment of this application.

[0009] Figure 2 This is a schematic diagram of the data flow of a fence topology map generation system based on fence connection identification according to an embodiment of this application.

[0010] Figure 3 This is a schematic diagram of a guardrail number generation system based on guardrail connection identification according to an embodiment of this application.

[0011] Figure 4 This is a schematic diagram of the guardrail direction and nodes in the guardrail topology graph generation system based on guardrail connection identification according to the embodiments of this application.

[0012] Figure 5 This invention relates to a system for generating four basic scenarios of guardrail connections based on guardrail connection identification, according to embodiments of this application.

[0013] Figure 6 This invention relates to a guardrail status coding diagram generated from a guardrail topology diagram based on guardrail connection identification, according to an embodiment of this application.

[0014] Figure 7 This document describes the generation of six guardrails in a guardrail topology graph generation system based on guardrail connection identification, according to an embodiment of this application. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0017] In view of the aforementioned deficiencies in the prior art, this application is hereby filed. Figure 1 This is a block diagram of a fence topology graph generation system based on fence connection identification according to an embodiment of this application. Figure 2 This is a schematic diagram of the data flow in a fence topology generation system based on fence connection identification according to an embodiment of this application. Specifically, as shown... Figure 1 and Figure 2 As shown, the guardrail topology graph generation system 100 based on guardrail connection recognition according to an embodiment of this application includes: an original signal flow acquisition module 110, used to acquire an original signal flow; an original signal flow normalization module 120, used to normalize the original signal flow to obtain an event list; a connection pair matching and recognition module 130, used to perform connection pair timing matching and recognition on the event list to obtain a connection pair list; a topology graph construction module 140, used to construct topology nodes and connection edges based on the connection pair list and a list of all guardrail IDs to obtain a topology graph; and a topology graph rendering module 150, used to perform visualization rendering on the topology graph to obtain a rendered topology graph image.

[0018] In a specific embodiment of this application, the basic unit of the system, the warning guardrail, is first defined, which is the physical basis for subsequent signal acquisition, recognition, and topology generation. Figure 3 This is a schematic diagram of a guardrail number generation system based on guardrail connection identification according to an embodiment of this application. Figure 4 This document provides a schematic diagram of the guardrail orientation and nodes in a guardrail topology graph generation system based on guardrail connection identification, according to embodiments of this application. Figure 3 and Figure 4 As shown, each guardrail unit is assigned a unique identifier, namely the guardrail number, such as T0001 to T9999, for unique identification and tracking by the system. Each guardrail also has four connection ports, defined as nodes A, B, C, and D. To effectively identify the connection action and direction, the functions and hardware configurations of these ports are clearly distinguished: port A is defined as the fixed "active end," its physical action being "pulled open," representing the initiation of a connection action (direction of force). It can be equipped with a detection device capable of detecting pulling out or extending actions, such as a mechanical switch or a pull rope sensor. Ports B, C, and D are the "passive ends," used to receive connections from other guardrail terminals A (direction of force). Each port has an embedded Hall sensor used to determine the connection status by detecting the proximity of an external magnetic connector. When terminal A of one guardrail physically connects to terminal B, C, or D of another guardrail, the corresponding sensor is triggered and generates the original electrical signal, which constitutes the data source of the entire system.

[0019] Based on the above definition, the connection between guardrails can be summarized into four basic cases. Figure 5 To generate four basic scenarios of guardrail connections in the system based on guardrail connection identification according to embodiments of this application. For example... Figure 5 As shown, regardless of whether the connection is horizontal, reverse horizontal, vertical, or reverse vertical, each action of a node connecting to other nodes or being connected generates an event with a precise timestamp. This event is then processed by the system described in this application to ultimately generate a guardrail status code that reflects the state after the connection. For example, in the example of a horizontal connection, the active end A of guardrail T0001 is pulled out at a specific timestamp and completes the connection with the passive end C of guardrail T0002 at a later timestamp. This series of events is ultimately resolved so that the status code of T0001 is updated to 0000, and the status code of T0002 is updated to 1010.

[0020] Specifically, the raw signal stream acquisition module 110 is used to acquire raw signal streams. It is understood that in complex construction sites or emergency response areas, the deployment status of guardrails is dynamic and constantly changing, and traditional manual recording methods cannot capture every connection or disassembly operation in real time and accurately. To achieve automated and digital topology management, the primary task is to transform these instantaneous connection behaviors occurring in the physical world into digital information that can be analyzed and processed by computers. The signals generated by these physical behaviors themselves are unprocessed, in their most raw data form. Therefore, acquiring raw signal streams is the first choice to establish the data foundation for the entire identification and generation process. By capturing the most direct signal responses generated at the moment of physical interaction at the guardrail connection ports, a real, continuous, and unprocessed input source is provided for subsequent event normalization, connection matching, and topology construction.

[0021] In one exemplary embodiment, the raw signal stream acquisition module 110 is specifically configured as follows: To acquire the raw signal stream, each guardrail unit first needs to be configured with hardware. The raw signal stream is a set of unprocessed continuous signal data generated by the sensing hardware installed on each guardrail unit. Specifically, each guardrail unit is assigned a unique guardrail number, such as T0001, T0002, etc. Simultaneously, each guardrail defines four connection ports, namely A, B, C, and D. Port A is designated as a fixed active end, internally equipped with a detection device capable of detecting pull-out or extension actions, such as a mechanical switch or a pull-cord sensor. Ports B, C, and D are passive connection ends, each embedded with a Hall sensor to detect the proximity of an external magnetic connector, thereby determining the connection status.

[0022] The acquisition of the raw signal stream is performed by the raw signal stream acquisition module 110. This module continuously monitors and receives signals from all sensors on all guardrail units in the field via a wireless or wired communication network. When the connection status of a guardrail changes, the corresponding sensor is immediately triggered and generates an electrical signal. For example, when a construction worker pulls out the A port connector of guardrail T0001 to prepare for connection, its internal pull-out detection device is triggered, generating a signal representing the active end being pulled out. This signal is instantly captured by the guardrail's built-in microcontroller and encapsulated into a raw data packet of a predetermined format. This data packet has a compact structure and contains key physical information. Specifically, it has a guardrail identification field and an event field. The guardrail identification field is used to uniquely identify the guardrail unit from which the signal originates, and its value is a binary number. For example, the hardware identifier of guardrail T0001 is set to 0x0001. The event field is used to carry the encoded information of the triggered port. The guardrail's built-in microcontroller follows a set of preset encoding rules to convert the physical port event into a specific four-bit binary code. The rule defines the event code as follows: Port A triggers an event with 0b1000, Port B with 0b0100, Port C with 0b0010, and Port D with 0b0001. Therefore, when Port A of T0001 is pulled out, the value of the identification field in the generated raw data packet is 0x0001, and the value of the event field is 0b1000. This complete data packet is sent out through the communication unit built into the fence. The raw signal stream acquisition module 110 receives this signal and records it as a data point in the data stream.

[0023] Next, when the construction worker inserts the A port connector of guardrail T0001 into the C port of guardrail T0002, the magnetic component on the T0001 connector triggers the Hall sensor on the C port of T0002. This Hall sensor changes its output level upon detecting a change in magnetic field strength, generating a signal representing a passive connection. This signal is also encapsulated into a raw data packet of the same format by the microcontroller of guardrail T0002. In this data packet, the guardrail identification field contains a unique hardware identifier for guardrail T0002, such as 0x0002, while the event field, according to the aforementioned preset encoding rules, is set to 0b0010 to uniquely represent the instantaneous event of the C port being connected. This data packet is then sent to the raw signal stream acquisition module 110. Upon receiving this signal, the module also adds it as a new data point to the data stream.

[0024] Ultimately, the output of the raw signal stream acquisition module 110 is a continuous raw signal stream arranged in chronological order. Taking the aforementioned operation as an example, the raw signal stream output by this module will sequentially contain two raw data packets: the data content of the first data packet is the guardrail identification identifier 0x0001 and the event field 0b1000; the data content of the second data packet that follows is the guardrail identification identifier 0x0002 and the event field 0b0010.

[0025] Specifically, the raw signal stream normalization module 120 is used to normalize the raw signal stream to obtain an event list. Correspondingly, the raw signal stream acquired from the sensor hardware is essentially an unprocessed, physical-level data set, which may exist in the form of binary code streams, level changes, or low-level data packets. Although these raw signals accurately reflect the physical state changes of the guardrail ports, they lack direct business logic meaning and are diverse in format and fragmented in information, making them unsuitable for direct understanding and use by the upper-layer topology construction logic. Furthermore, the data formats and encoding methods generated by different sensors may differ; without unified processing, subsequent analysis will become extremely complex and unreliable. Therefore, before performing connection matching, these raw signal streams need to be normalized to transform the heterogeneous, disordered, and low-semantic raw signals into unified, structured high-level event objects containing clear business identifiers and precise timing information.

[0026] In one exemplary embodiment, the original signal stream normalization module 120 includes: an original signal stream parsing unit 121, used to perform data parsing and semantic mapping on the original signal stream to obtain parsed data tuples, the parsed data tuples including guardrail numbers and event ports; and an event object encapsulation and calibration unit 122, used to encapsulate event objects and calibrate timestamps on the parsed data tuples to obtain the event list.

[0027] In the above implementation, the raw signal stream normalization module 120 is specifically described as follows: The raw signal stream parsing unit 121 first processes the input raw signal stream. The input raw signal stream is a sequence containing multiple raw data packets, each representing a sensor trigger. Taking the example of the A port connector of guardrail T0001 being pulled out and connected to the C port of guardrail T0002, this unit will receive two raw data packets in succession. The first data packet comes from guardrail T0001, and the second comes from guardrail T0002. The processing of this unit follows a set of predefined communication protocols and data structures. First, it parses the first data packet. According to the preset data structure, the unit locates the field in the data packet that represents the guardrail identification. This field is a binary value, such as 0x0001. In order to convert this hardware-level identifier into a guardrail number with business significance, the unit queries a preset guardrail registry. This registry is set up during the guardrail deployment phase, and it maintains the mapping relationship between all guardrail hardware identifiers and their business logic numbers, such as 'T0001'. By looking up the table, the unit successfully decodes the binary value 0x0001 into the fence number 'T0001'. Next, the raw signal stream parsing unit 121 continues to parse the field representing the event type in the data packet. To decode this binary event field, encoded by the fence hardware, such as 0b1000, into a logical port identifier that the upper-layer application can understand, the unit utilizes a preset port mapping rule table. This rule table defines the correspondence between binary event encodings and logical port characters ('A', 'B', 'C', 'D'), corresponding to the encoding rules described in module 110. According to this rule, the unit successfully decodes and maps the received binary value 0b1000 into the event port 'A'. After completing the parsing and mapping of the fence number and the event port, the unit combines these two pieces of information into a parsed data tuple, namely ('T0001', 'A'). This tuple is an intermediate data structure that has undergone preliminary parsing and semanticization, clearly indicating which fence and which port experienced the event. After processing the first data packet, the raw signal stream parsing unit 121 processes the following second data packet in the exact same way. This data packet has a guardrail identification field of 0x0002 and an event field of 0b0010. By querying the guardrail registry, 0x0002 is decoded into the guardrail number 'T0002'. Similarly, by querying the port mapping rule table, the unit decodes the binary value of the event field 0b0010 into the event port 'C'. Thus, the second parsed data tuple ('T0002', 'C') is generated. This unit then passes these two parsed data tuples sequentially to the event object encapsulation and labeling unit 122 for final processing, according to their order of appearance in the raw signal stream.

[0028] The event object encapsulation and calibration unit 122 receives the parsed data tuple sequence from the parsing unit. Its core task is to accurately calibrate the timestamp for each tuple and encapsulate it into a standardized event object. When the first tuple ('T0001', 'A') arrives, the unit immediately invokes a high-precision time service to obtain the current precise time. The timestamp of the active end A, such as '2025 / 06 / 27 14:28:00', is used as the occurrence time of the event. Subsequently, the unit creates an event object. In one exemplary embodiment, each event object in the event list includes a fence number, an event port, and an event timestamp. It assigns 'T0001' from the tuple to the fence number attribute, 'A' to the event port attribute, and the newly obtained timestamp '2025 / 06 / 27 14:28:00' to the event timestamp attribute. In this way, a complete and structured event object is created. Next, when the second tuple ('T0002', 'C') arrives, the event object encapsulation and calibration unit 122 repeats the same operation. It queries the high-precision time service again to obtain a new timestamp, slightly later than the previous one. The time when the passive connection end C was connected is defined as ct, so the obtained timestamp, for example, '2025 / 06 / 27 14:28:03', is recorded precisely. This tiny time difference accurately reflects the timing relationship between the two physical operations. Then, the unit uses the tuple ('T0002', 'C') and the new timestamp '2025 / 06 / 27 14:28:03' to create a second event object.

[0029] Finally, all created event objects are added to an event list. This event list is the final output of the raw signal flow normalization module 120. In this example, the output event list will contain two ordered event objects: the first object is {fence number: 'T0001', event port: 'A', event timestamp: '2025 / 06 / 27 14:28:00'}, and the second object is {fence number: 'T0002', event port: 'C', event timestamp: '2025 / 06 / 27 14:28:03'}.

[0030] Specifically, the connection pair matching and identification module 130 is used to perform connection pair temporal matching and identification on the event list to obtain a connection pair list. It should be understood that although the event list obtained after normalization is structurally clear and information-complete, it is essentially still a collection of isolated and discrete action records. Each event object in the list can only indicate that a certain port of a guardrail underwent a state change at a certain moment, but cannot directly reveal the crucial connection relationships between guardrails. For example, a pull-out event of an active port and a connection event of a passive port, although close in time, have no direct correlation at the data level. In order to construct a topology map that reflects the actual physical layout, it is necessary to accurately infer the logical pairing relationships between these independent events. Therefore, connection pair temporal matching and identification can transform discrete event points into connection pairs with clear directions and connection relationships by analyzing their inherent logical and temporal correlations.

[0031] In one exemplary embodiment, the connection pair matching and identification module 130 includes: an event classification and partitioning unit 131, used to classify and partition the event list to obtain an active event list and a passive event list; a candidate matching list generation unit 132, used to perform iterative matching based on a time window on the active event list and the passive event list to obtain a candidate matching list; and a matching decision unit 133, used to make an optimal matching decision on the candidate matching list to obtain a connection pair list.

[0032] In the above implementation, the specific content of the connection matching and recognition module 130 is as follows: the first processing step is executed by the event classification partitioning unit 131. Taking the event list generated in the previous stage as an example, and adding a few more events to more comprehensively demonstrate the partitioning process, the input event list may contain the following objects: {Guardrail ID:'T0001', Event Port:'A', Event Timestamp:'2025 / 06 / 27 14:28:00'}, {Guardrail ID:'T0002', Event Port:'C', Event Timestamp:'2025 / 06 / 27 14:28:03'}, {Guardrail ID:'T0003', Event Port:'A', Event Timestamp:'2025 / 06 / 27 14:32:00'}, and {Guardrail ID:'T0004', Event Port:'B', Event Timestamp:'2025 / 06 / 27 14:32:05'}. First, initialize two empty list containers, named the active event list and the passive event list respectively. Then, the unit begins iterating through each event object in the input event list. For each object, the unit checks the value of its event port attribute. A pre-defined classification rule based on the physical design of the fence is applied: since port A is designed as the active end initiating the connection, any event with event port 'A' is defined as an active event; correspondingly, events triggered by ports B, C, and D, as the receiving ends of the connection, are defined as passive events. According to this rule, when the unit processes the first event object {fence number: 'T0001', event port: 'A',...}, it recognizes the event port as 'A' and therefore stores the complete event object in the active event list. Next, it processes the second object {fence number: 'T0002', event port: 'C',...}, which, because its event port is 'C', is classified as a passive event and added to the passive event list. The unit continues processing the third object {fence number: 'T0003', event port: 'A',...}, which is similarly recognized as an active event and added to the active event list. For the fourth object {fence number:'T0004', event port:'B',...}, its port is 'B', so it is placed in the passive event list. After traversing all the input event objects, two filled lists will be output. The active event list will contain: {fence number:'T0001', event port:'A', event timestamp:'2025 / 06 / 27 14:28:00'} and {fence number:'T0003', event port:'A', event timestamp:'2025 / 06 / 27 14:32:00'}.The passive event list includes: {fence number:'T0002', event port:'C', event timestamp:'2025 / 06 / 27 14:28:03'} and {fence number:'T0004', event port:'B', event timestamp:'2025 / 06 / 27 14:32:05'}.

[0033] The candidate matching list generation unit 132 is responsible for performing the key matching search process. In one exemplary embodiment, the candidate matching list generation unit 132 includes: a first active event extraction subunit 1321, used to extract a first active event from the active event list; a time search window determination subunit 1322, used to determine a time search window based on the timestamp of the first active event and a preset time threshold; and a time search subunit 1323, used to search the passive event list for all passive events falling within the time search window to obtain a first candidate matching list.

[0034] The process begins with the first active event extraction subunit 1321. This subunit iteratively extracts events from the input list of active events. In its first iteration, it extracts the first event object from the beginning of the list and defines it as the first active event. Taking the output of the previous stage as an example, in the first iteration, the extracted first active event is {fence number:'T0001', event port:'A', event timestamp:'2025 / 06 / 27 14:28:00'}. This extracted event object is then passed to the next subunit.

[0035] Next, the time search window determines that subunit 1322 has received the first active event object and calculates a reasonable time search window. This time threshold (TimeThreshold) is a key parameter, and its setting directly affects the matching accuracy. This value is determined based on empirical data from actual operational scenarios. For example, by analyzing a large number of video recordings of guardrail installation operations, the distribution of the time required from the active end pulling out to the passive end completing the connection is statistically analyzed; this time is within a few seconds. To ensure coverage of the vast majority of normal operations while excluding obviously irrelevant events, a preset time threshold, such as 5 seconds, can be set. In an exemplary implementation, the time search window is [EventTimestamp-TimeThreshold, EventTimestamp+TimeThreshold], where EventTimestamp is the timestamp of the first active event, and TimeThreshold is the preset time threshold. Taking the received first active event as an example, its timestamp EventTimestamp is '2025 / 06 / 27 14:28:00', and the preset time threshold TimeThreshold is 5 seconds. Based on this, the calculated start time of the time search window is '2025 / 06 / 27 14:27:55', and the end time is '2025 / 06 / 27 14:28:05'.

[0036] Finally, the time search subunit 1323 receives this calculated time search window and simultaneously accesses the complete passive event list. To make the example more illustrative, the passive event list is expanded here as: [{fence number:'T0002', event port:'C', event timestamp:'2025 / 06 / 27 14:28:03'},{fence number:'T0005', event port:'D', event timestamp:'2025 / 06 / 27 14:28:04'},{fence number:'T0004', event port:'B', event timestamp:'2025 / 06 / 27 14:32:05'}]. The task of this sub-unit is to filter out all events in the passive event list whose timestamps fall within the interval ['2025 / 06 / 27 14:27:55', '2025 / 06 / 27 14:28:05']. It iterates through each event object in the passive event list: the timestamp of the first event {...'T0002', 'C', '14:28:03'} falls within the window and is therefore considered a candidate match; the timestamp of the second event {...'T0005', 'D', '14:28:04'} also falls within the window and is similarly considered a candidate match; the timestamp of the third event {...'T0004', 'B', '14:32:05'} is outside the window and is therefore ignored. All the filtered passive events are then paired with the currently processed first active event to form a first candidate match list. In this example, the list will contain two candidate pairs: ({active event:'T0001-A'}, {passive event:'T0002-C'}) and ({active event:'T0001-A'}, {passive event:'T0005-D'}). After the first iteration, the process returns to the first active event extraction subunit 1321, extracts the next unprocessed event from the active event list, namely {fence number:'T0003', event port:'A', event timestamp:'2025 / 06 / 27 14:32:00'}, and repeats all the above steps. The new time search window calculated for it will be ['2025 / 06 / 27 14:31:55', '2025 / 06 / 27 14:32:05']. When searching the same passive event list using this new window, only the timestamp of the event {...'T0004','B','14:32:05'} will fall into it, thus generating a second candidate matching list containing only one candidate pair: ({active event:'T0003-A'},{passive event:'T0004-B'}). After all events in the active event list have been processed, the candidate matching list generation unit 132 will merge all the candidate matching lists generated during the iteration process to form a total candidate matching list.This master list is the final output of this unit, containing all active events and all their potential passive match objects. In this example, the final output candidate match list is: [({Active Event:'T0001-A', timestamp:'14:28:00'},{Passive Event:'T0002-C', timestamp:'14:28:03'}),({Active Event:'T0001-A', timestamp:'14:28:00'},{Passive Event:'T0005-D', timestamp:'14:28:04'}),({Active Event:'T0003-A', timestamp:'14:32:00'},{Passive Event:'T0004-B', timestamp:'14:32:05'})].

[0037] The matching decision unit 133 is responsible for executing the final decision-making process. The input to this unit is the total candidate matching list output by the candidate matching list generation unit 132. Simultaneously, this unit initializes an empty list of connection pairs to store the final determined connection results. First, it processes the candidate pairs related to the active event 'T0001-A'. It finds two candidate matches for this active event: 'T0002-C' and 'T0005-D'. To select the best match, this unit applies a preset decision rule: selecting the passive event with the smallest absolute difference in timestamps with the active event as the unique best match. This rule is based on a physical assumption that the initiation and completion of the connection action are closest in time. The unit then calculates: for candidate 'T0002-C', the absolute value of the timestamp difference is |'14:28:03' - '14:28:00'| = 3 seconds. For candidate 'T0005-D', the absolute value of the timestamp difference is |'14:28:04' - '14:28:00'| = 4 seconds. By comparison, 3 seconds is less than 4 seconds; therefore, the unit determines that the passive event 'T0002-C' is the unique best match for the active event 'T0001-A'. Once the best match is determined, the unit immediately generates a connection pair object. This object is a structured data entity containing complete connection information. In one exemplary implementation, each connection pair in the connection pair list includes a source fence number, a source port, a target fence number, a target port, and a connection timestamp. Based on the current best match result, the unit assigns values: the source fence number is set to 'T0001', and the source port is set to 'A' (both from the active event); the target fence number is set to 'T0002', and the target port is set to 'C' (both from the selected best-matching passive event). For the connection timestamp, to ensure the consistency of the timing, the timestamp of the active event can be used as a representative; therefore, the connection timestamp is set to '2025 / 06 / 27 14:28:00'. This generated complete connection pair object is then added to the initially empty connection pair list. After generating the connection pair, the unit performs a crucial consumption operation to ensure that each event is matched only once, avoiding data reuse that could lead to topology errors. It immediately removes the successfully matched passive events {fence number: 'T0002', event port: 'C',...} from the original, complete passive event list. Simultaneously, since the active event 'T0001-A' has also been successfully matched, other related candidate pairs, i.e., the pairing with 'T0005-D', will no longer be considered, and the active event itself will be marked as processed or removed from the pending list. This consumption mechanism ensures the uniqueness of the match and the accuracy of the final topology. Next, the matching decision unit 133 continues to process the next pair in the candidate matching list. It processes candidate pairings associated with the active event 'T0003-A'.In this example, the active event has only one candidate match, 'T0004-B'. In this case, since there are no other competitors, the unit directly determines 'T0004-B' as the best match. Subsequently, it generates a second connection pair object in the exact same way: {Source Fence ID: 'T0003', Source Port: 'A', Target Fence ID: 'T0004', Target Port: 'B', Connection Timestamp: '2025 / 06 / 27 14:32:00'}. This new connection pair object is also added to the connection pair list. Similarly, the unit performs a consumption operation, removing the 'T0004-B' event from the corresponding passive event list and marking 'T0003-A' as processed.

[0038] After traversing and processing all entries in the candidate matching list, the matching decision unit 133 completes its work. Its final output is a list of connection pairs with determined content. In this complete example, the output list of connection pairs will contain two objects: {Source fence number:'T0001', Source port:'A', Target fence number:'T0002', Target port:'C', Connection timestamp:'2025 / 06 / 27 14:28:00'} and {Source fence number:'T0003', Source port:'A', Target fence number:'T0004', Target port:'B', Connection timestamp:'2025 / 06 / 27 14:32:00'}.

[0039] Specifically, the topology graph construction module 140 is used to construct topology nodes and connecting edges based on the connection pair list and the list of all fence IDs to obtain a topology graph. It is understood that the connection pair list clearly indicates which fences have one-to-one connections. However, this list is essentially a series of discrete relationship descriptions; while accurate, it does not form a unified data model that can completely depict the topology of the entire fence network. For example, it does not include information about units that exist independently and are not connected to any other fences. To ultimately generate a visual graph, the rendering engine needs standardized, structured graph data as input, not just scattered connection information. Therefore, before performing the final visualization rendering, to systematically convert this flattened list of connections into a structured graph data object containing complete node and edge information, providing a complete and rigorous data foundation for subsequent graphical rendering, further construction of the topology graph is necessary.

[0040] In one exemplary implementation, the topology graph construction module 140 is as follows: The construction process of this module begins with node initialization. It first needs to obtain a list of all fence IDs, which is determined during fence deployment and contains all fence units, whether connected or not. For example, if there are five fences in a scene, the list would be ['T0001', 'T0002', 'T0003', 'T0004', 'T0005']. The module iterates through each fence number in this ID list. For each number, such as 'T0001', it creates a corresponding node object and adds it to the node list of an initially empty topology graph. Each node object contains two core attributes: fence number and status code. According to preset rules, the status code of all nodes is set to the default value '1000' during initialization. This status code means that port A of the fence is available, i.e., A has not been pulled out (the first digit is '1'), while ports B, C, and D are not connected (the last three digits are '0'). After traversing the entire list of IDs, the node list of the topology graph is created, which contains five node objects, each with a status code of '1000'.

[0041] After all nodes are initialized, the module proceeds to the edge construction and node state update phase. The core input to this phase is the list of connection pairs generated by the previous module. Taking the output of the previous example as an example, the input list of connection pairs is: [{source fence number:'T0001', source port:'A', target fence number:'T0002', target port:'C',...},{source fence number:'T0003', source port:'A', target fence number:'T0004', target port:'B',...}]. The module iterates through each connection pair object in this list.

[0042] When processing the first connection pair {Source: 'T0001'-'A', Destination: 'T0002'-'C'}, the module performs three synchronization operations. First, it creates an edge object based on the source fence number 'T0001' and the destination fence number 'T0002'. This edge object contains the source node ID, the destination node ID, and a connection label. In this example, the generated edge object is {Source Node ID: 'T0001', Destination Node ID: 'T0002', Connection Label: 'A→C'}, and this label clearly indicates that the connection originates from port A of T0001 and connects to port C of T0002. This newly created edge object is added to the edge list of the topology graph. Second, the module looks up the node object with fence number 'T0001' in the node list and updates its status code from the initial '1000' to '0000' based on the connection fact (its port A has been used). Finally, it looks up the node object with fence number 'T0002'. Since the target port for the connection is 'C', the module updates the third bit representing port C in its status code, changing it from '0' to '1'. Therefore, the status code of node 'T0002' changes from '1000' to '1010'. This specific edge construction and node state update process is as follows: Figure 6 As shown. Figure 6 This invention relates to a fence status coding diagram in a fence topology graph generation system based on fence connection identification, according to an embodiment of this application. The diagram visually illustrates that after port A of fence T0001 is connected to port C of T0002, the status code of the source node T0001 is updated to '0000' because port A is occupied, while the status code of the target node T0002 is updated to '1010' because port C is connected. Next, the module processes the second object in the connection pair list {source: 'T0003'-'A', target: 'T0004'-'B'}, repeating the exact same logic. It creates a new edge object {source node ID: 'T0003', target node ID: 'T0004', connection label: 'A→B'} and adds it to the edge list. Then, it updates the status code of node 'T0003' from '1000' to '0000'. For the target node 'T0004', since the connection port is 'B', the second bit representing port B in its status code will change from '0' to '1', so the status code will be updated from '1000' to '1100'.

[0043] After traversing all entries in the connection pair list, the final output topology graph object is fully constructed. Its node list will contain five node objects with status codes as follows: 'T0001' is '0000', 'T0002' is '1010', 'T0003' is '0000', 'T0004' is '1100', while 'T0005', which is not involved in any connections, retains its initial status code '1000'. Its edge list will contain two edge objects: {Source:'T0001', Destination:'T0002', Label:'A→C'} and {Source:'T0003', Destination:'T0004', Label:'A→B'}. This structured topology graph object completely and accurately describes the current state and connections of the entire fence network.

[0044] Specifically, the topology rendering module 150 is used to perform visualization rendering of the topology map to obtain a rendered topology map image. That is, after the topology map is constructed, a structured graph data object has been completely established, accurately describing all fence nodes and their interconnections in a computer-readable format. However, this data object is essentially an abstract logical structure stored in memory, composed of a series of node and edge definitions. It lacks an intuitive spatial layout and visual form, and cannot be directly understood and used by on-site maintenance personnel. The ultimate goal is to provide managers with a graphical interface that allows them to clearly grasp the overall layout of the fence. Therefore, before finally presenting it to the user, there needs to be a process to transform this abstract data into a concrete image. To convert this abstract logical graph into a clearly discernible graphical image that conforms to human visual intuition, professional layout algorithms and graphics drawing techniques are used, thereby realizing the core value of this technical solution: visualization.

[0045] In one exemplary embodiment, the topology rendering module 150 includes: a layout unit 151, used to input node objects and edge objects in the topology graph into a layout algorithm engine to obtain a list of nodes with coordinates; a graphic element drawing unit 152, used to draw graphic elements on each node in the list of nodes with coordinates to obtain a set of drawn nodes and a set of drawn edges; and a node and edge merging unit 153, used to merge the set of drawn nodes and the set of drawn edges onto a canvas to obtain the rendered topology graph image.

[0046] In the above implementation, the specific content of the topology rendering module 150 is as follows: The process begins with the layout unit 151. This unit receives a complete topology object as input. Taking the output of the previous stage as an example, the object contains a list of nodes [{fence number:'T0001', status code:'0000'},{fence number:'T0002', status code:'1010'},{fence number:'T0003', status code:'0000'},{fence number:'T0004', status code:'1100'},{fence number:'T0005', status code:'1000'}] and a list of edges [{source:'T0001', destination:'T0002', label:'A→C'},{source:'T0003', destination:'T0004', label:'A→B'}]. The core task of this unit is to calculate the optimal position coordinates of each node on the 2D canvas. To do this, it inputs the data of these nodes and edges into a pre-defined layout algorithm engine. One implementation is a force-guided layout algorithm. The algorithm begins with an initialization step, randomly distributing all node objects (five railings in this example) to their initial positions on the 2D canvas. The algorithm then enters an iterative calculation simulation loop. In each iteration, the algorithm calculates the resultant force acting on each node. This resultant force is composed of two types of forces: first, a repulsive force, where each node exerts a repulsive force on all other nodes. This force is inversely proportional to the square of the distance between nodes, similar to the Coulomb repulsion between charges, and its function is to prevent nodes from squeezing or overlapping in the layout; second, an attractive force, existing only between two nodes connected by an edge. This force acts like a spring, its magnitude proportional to the distance between the two nodes, and its function is to pull the connected nodes closer together to maintain the integrity of the topology. After calculating all repulsive and attractive forces acting on a node, these forces are combined into a single net force vector, which precisely indicates the direction and distance the node should move in this iteration. The algorithm performs this force calculation and position update for all nodes on the canvas. This iterative process is repeated, and a cooling mechanism is introduced: as the number of iterations increases, the step size of each node movement gradually decreases to prevent the layout from oscillating and failing to converge. Finally, after hundreds or thousands of iterations, the entire system reaches a stable state with minimum energy, where the net force on all nodes approaches zero, and the node positions no longer change significantly. This automatically unfolds the graph structure in an aesthetically pleasing and clear way, resulting in a uniform distribution of nodes and minimal edge intersections. When this iterative simulation process converges and ends, each node object is assigned a pair of (x, y) coordinates.The output of this unit is a list of nodes with coordinates, for example: [{fence number:'T0001',...,coordinates:(100,100)},{fence number:'T0002',...,coordinates:(200,100)},{fence number:'T0003',...,coordinates:(100,200)},{fence number:'T0004',...,coordinates:(200,200)},{fence number:'T0005',...,coordinates:(350,150)}].

[0047] Next, the graphics element drawing unit 152 receives the list of nodes with coordinates and the original edge list, and converts this abstract data with positional information into a set of concrete, renderable graphics elements. This unit first iterates through the list of nodes with coordinates. For the first node 'T0001' in the list, it reads its coordinates (100, 100) and calls the underlying graphics drawing interface to draw a preset graphic symbol, such as a rectangle, at the corresponding position on the canvas. To provide richer visual information, the border or fill color of the rectangle can be set according to the node's connection status (e.g., whether it is an unconnected or isolated node). The rectangle's interior uses a preset font and size, filled with the guardrail number 'T0001' and its final status code '0000' as a label. In the same way, this unit binds data attributes to visual attributes for all five nodes at their respective coordinate positions, drawing corresponding labeled rectangles. All these independently drawn node graphics objects together constitute a set of drawing nodes. Subsequently, the unit iterates through the edge list. For the first edge {Source:'T0001', Target:'T0002', Label:'A→C'}, it first finds the coordinates (100, 100) of the source node 'T0001' and the coordinates (200, 100) of the target node 'T0002' from the list of nodes with coordinates, using these as the starting and ending points for drawing. Then, it draws a connecting line between these two coordinate points. To clearly indicate the direction and relationship of the connection, this line is rendered as a straight line or a smooth curve with an arrow, and its color and thickness can be defined according to a preset style. Simultaneously, it labels the connection 'A→C' near the center point of this line to avoid visual confusion. The same operation is performed on the second edge {Source:'T0003', Target:'T0004',...}, drawing a labeled arrow between coordinates (100, 200) and (200, 200). All these connecting line graphics generated from the edge data together constitute a set of drawn edges.

[0048] Finally, the node edge merging unit 153 performs the final image compositing. It first calculates a bounding box that can fully accommodate the entire topology map based on the coordinate range of all drawn elements, and then creates a blank digital canvas with preset inner margins and background color. Then, following a clear rendering hierarchy, it accurately merges and renders all rectangles from the node set and all labeled arrows from the edge set onto the canvas according to their respective coordinates and geometric information. To ensure the integrity of the node graphics, all edges (connecting lines and arrows) are drawn on a lower layer first, followed by all nodes (rectangles and labels) on a higher layer, thus preventing connecting lines from crossing or obscuring node labels. To improve image readability, this unit can also add auxiliary information, such as a title centered at the top of the canvas, like "Real-time Fence Layout Topology Map," with a prominent font and size. Simultaneously, a legend is added in a corner of the canvas (e.g., the lower right corner) to clearly explain the meaning of different node colors (e.g., red for active end, green for passive end) or status code bits. After all graphic elements and auxiliary information are merged onto the canvas, the unit outputs the entire canvas content as a complete, visualized graphic image through the graphics rendering pipeline. This output can be a static image file, such as a PNG raster image for easy storage and transmission, or an SVG vector image that supports lossless scaling, or it can be a dynamically rendered graphic directly on a user interface. In dynamically rendered scenarios, the graphic can also support interactive operations; for example, users can zoom and pan with the mouse, or hover the cursor over a guardrail node to view more detailed real-time information, such as battery level or last connection time. The final presentation to maintenance personnel will be a clear and intuitive picture: two connected guardrail pairs are linked by arrows, while another independent guardrail is displayed in isolation to the side, making the identity and status of all guardrails immediately apparent.

[0049] To further illustrate the collaborative workflow and final effect of the system described in this application when handling complex connection scenarios, the following will combine... Figure 7 A comprehensive embodiment involving six guardrail units is provided. Figure 7This document describes the generation of a topology map for six guardrails in a guardrail connection identification-based system according to an embodiment of this application. In this scenario, a series of connection actions occur at different times. The original signal flow acquisition module 110 and the original signal flow normalization module 120 first convert these actions into an ordered list containing multiple events. For example, this list might include events such as guardrail T0001's A end being pulled out at 14:28:00, guardrail T0002's D end being connected at 14:28:03, guardrail T0002's A end being pulled out at 14:30:00, and guardrail T0003's C end being connected at 14:30:04.

[0050] Subsequently, the connection matching and recognition module 130 processes this series of events and accurately identifies the connection relationships between the guardrails through time-series matching and decision-making. For example, T0001 is connected to T0002, T0002 is connected to T0003, T0006 is connected to T0005, and T0005 is connected to T0004.

[0051] Based on these defined connection pairs, the topology graph construction module 140 constructs a topology graph containing six nodes and five edges, and synchronously updates the status code of each fence node. After construction, the final status code of T0001 is 0000, T0002 is 0001, T0003 is 0010, T0004 is 1110, T0005 is 0010, and T0006 is 0000.

[0052] Finally, the topology rendering module 150 performs visualization rendering on this structured topology data, generating a result such as... Figure 7 The final topology diagram shown is clearly illustrated. It illustrates the chain and branching structure formed between the six guardrail units and includes key event timestamps and final status codes.

[0053] Therefore, by coordinating the processing of guardrail numbers (Txxxx), node event times, and node status codes, the solution of this application can accurately generate arbitrarily complex guardrail connection topology diagrams based on timing logic.

[0054] In summary, the fence topology graph generation system 100 based on fence connection identification, according to embodiments of this application, is explained. It transforms physical connection events into visualized digital graphics through time-series analysis. First, sensors deployed at the fence connection ports acquire the raw signal streams generated by connection or disconnection operations in real time. Then, these signals are parsed into a structured event list containing fence numbers, event ports, and precise timestamps. By analyzing the temporal sequence of events, an active connection event of one fence is matched with a passive connection event of another fence within a very short time window, thereby accurately identifying the connection relationships between fences. Once the connection relationship is confirmed, nodes representing fences and edges representing connections are generated based on this, forming a logical topology graph. Finally, the logical graph is visualized to generate an intuitive layout image. This automated signal acquisition and time-series matching solves the problems of low efficiency and error-proneness of traditional manual recording, accurately captures dynamically changing connection states, and ultimately achieves real-time, remote, visualized monitoring of the fence topology, effectively improving construction management efficiency and safety response speed.

[0055] Various implementations of this disclosure have been described above. The foregoing description is exemplary and not exhaustive. Furthermore, it is not limited to the disclosed implementations, and many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations.

Claims

1. A fence topology map generation system based on fence connection recognition, characterized in that, include: The raw signal stream acquisition module is used to acquire the raw signal stream; The raw signal stream normalization module is used to normalize the raw signal stream to obtain an event list; The connection pair matching and recognition module is used to perform connection pair timing matching and recognition on the event list to obtain a connection pair list; The topology graph construction module is used to construct topology nodes and connecting edges based on the list of connection pairs and the list of all fence IDs to obtain a topology graph. The topology rendering module is used to visualize and render the topology graph to obtain the rendered topology graph image.

2. The fence topology map generation system based on fence connection recognition according to claim 1, characterized in that, Each event object in the event list includes a guardrail number, an event port, and an event timestamp.

3. The fence topology map generation system based on fence connection recognition according to claim 1, characterized in that, Each connection pair in the connection pair list includes a source fence number, a source port, a target fence number, a target port, and a connection timestamp.

4. The fence topology map generation system based on fence connection recognition according to claim 2, characterized in that, The original signal stream normalization module includes: The original signal stream parsing unit is used to perform data parsing and semantic mapping on the original signal stream to obtain parsed data tuples, which include guardrail number and event port; The event object encapsulation and labeling unit is used to encapsulate the parsed data tuples into event objects and label them with timestamps to obtain the event list.

5. The fence topology map generation system based on fence connection identification according to claim 1, characterized in that, The connection pair matching and recognition module includes: The event classification and partitioning unit is used to classify and partition the event list to obtain an active event list and a passive event list; The candidate matching list generation unit is used to perform time-window-based iterative matching of the active event list and the passive event list to obtain the candidate matching list; The matching decision unit is used to make the best matching decision on the candidate matching list to obtain the list of connection pairs.

6. The fence topology map generation system based on fence connection identification according to claim 5, characterized in that, The candidate matching list generation unit includes: The first active event extraction subunit is used to extract a first active event from the active event list; The time search window determination subunit is used to determine the time search window based on the timestamp of the first active event and a preset time threshold; The time search subunit is used to search the passive event list for all passive events that fall within the time search window to obtain a first candidate matching list.

7. The fence topology map generation system based on fence connection recognition according to claim 6, characterized in that, The time search window is [EventTimestamp-TimeThreshold,EventTimestamp+TimeThreshold], where EventTimestamp is the timestamp of the first active event and TimeThreshold is a preset time threshold.

8. The fence topology map generation system based on fence connection identification according to claim 1, characterized in that, The topology rendering module includes: The layout unit is used to input node objects and edge objects in the topology graph into the layout algorithm engine to obtain a list of nodes with coordinates. The graphic element drawing unit is used to draw graphic elements for each coordinate node in the coordinate node list to obtain the drawing node set and the drawing edge set. The node-edge merging unit is used to merge the set of drawn nodes and the set of drawn edges onto the canvas to obtain the rendered topology image.

Images