Urban rail transit substation inspection robot collaborative operation method

Abstract

The application provides a kind of urban rail transit substation inspection robot collaborative operation method, it is related to data processing field.In the method, obtain equipment object set and generate equipment object identification, build assertion dictionary and set legal witness number and heterogeneous witness number, generate witness identification and assertion auction book, generate assertion work order identification through sealed bidding and priority decision, collect evidence fragments to form assertion record and write into assertion event chain, establish emergency bifurcation event chain and generate missing assertion ticket and lightweight witness assertion record when emergency triggers, perform mapping and restatistics after emergency ends, update stable area index and output resolvable health conclusion and controversial assertion identification, realize collaborative operation closed loop under emergency insertion condition.Implementation of the technical solution provided in the application facilitates maintaining the continuity and traceability of the device state expression while ensuring the timeliness of emergency response in scenarios where emergency tasks are frequently inserted.

Description

Technical Field

[0001] This application relates to the technical field of data processing, specifically to a collaborative operation and maintenance method for urban rail transit substation inspection robots. Background Technology

[0002] As urban rail transit substations gradually evolve towards unmanned and minimally staffed operation modes, inspection robots are widely used to replace manual labor in tasks such as equipment status data collection, anomaly identification, and remote operation support. Under normal operating conditions, inspection robots periodically observe equipment according to preset inspection cycles and fixed inspection paths, and construct time series models based on continuously collected data for trend analysis, status prediction, and periodic health index calculation, thereby supporting closed-loop operation and maintenance decisions. However, in actual operating environments, substations frequently experience emergencies such as abnormal switch status, protection alarms, load surges, or environmental safety alarms. Inspection robots need to respond to emergency tasks immediately and temporarily interrupt the current routine inspection process.

[0003] Under conditions of continuous emergency priority insertion, the original inspection cycle is frequently interrupted, and the observation data of some equipment objects exhibits time-fragmented characteristics, with continuous time series being broken into multiple discrete segments. Since trend analysis and periodic health index statistics typically rely on stable, equally spaced time series data, when gaps or overlaps appear in the observation data over time, traditional closed-loop systems often correct them through simple interpolation or supplementary sampling. However, such corrections cannot accurately reflect the evolution of equipment under actual operating conditions, easily leading to biased trend judgments or abnormal fluctuations in health indices. Furthermore, during emergency response, the path and dwell time of the inspection robot are constrained by safety domains and handling time limits, making it difficult to complete complete observations of all planned equipment objects. This extends the inspection cycle of some equipment objects or alters observation conditions, further exacerbating the discontinuity of the time series. Existing technologies mostly alleviate the conflict from the perspective of scheduling optimization or priority rearrangement, but fail to address the inherent contradiction between emergency priority and inspection continuity at the data structure and state representation level.

[0004] Therefore, in scenarios where emergency tasks are frequently interrupted, how to maintain the continuity and traceability of equipment status expression while ensuring the timeliness of emergency response has become an urgent technical problem to be solved in the collaborative operation and maintenance of urban rail transit substation inspection robots. Summary of the Invention

[0005] This application provides a collaborative operation and maintenance method for urban rail transit substation inspection robots, which facilitates timely emergency response while maintaining the continuity and traceability of equipment status expression in scenarios with frequent emergency tasks.

[0006] The first aspect of this application provides a collaborative operation and maintenance method for inspection robots in urban rail transit substations. The method includes: acquiring a set of equipment objects in the urban rail transit substation and generating an equipment object identifier for each equipment object in the set; constructing an assertion dictionary based on the equipment object identifiers and setting a statutory witness count and a heterogeneous witness count for each assertion to be verified in the assertion dictionary, while simultaneously generating a witness identifier for the inspection robot corresponding to the urban rail transit substation; generating an assertion auction book, simultaneously receiving sealed bids corresponding to the witness identifiers, and executing a transaction decision based on expiration risk, historical dispute level, and witness count gap to generate an assertion work order identifier; obtaining evidence fragments based on the witness identifiers corresponding to the assertion work order identifiers to generate assertion records, and simultaneously storing the assertion records... The system adds assertion event chains to the record and updates the stable zone index and generates disputed assertion identifiers based on the statutory witness count and the heterogeneous witness count. When an emergency event is triggered, an emergency fork identifier is generated, and an emergency fork event chain is created. Incomplete assertion work order identifiers are converted into missing assertion tickets and written back to the assertion auction book. At the same time, lightweight witness assertion records are generated and written to the emergency fork event chain. After the emergency event ends, the lightweight witness assertion records in the emergency fork event chain are mapped to the assertion event chain. After performing statutory witness count recount and heterogeneous witness count recount, the stable zone index is updated for assertion identifiers that meet preset conditions, and an adjudicable health conclusion is generated. At the same time, the missing assertion ticket and the disputed assertion identifier are output to achieve collaborative operation and maintenance of inspection robots under emergency priority insertion conditions.

[0007] A second aspect of this application provides a collaborative operation and maintenance device for inspection robots in urban rail transit substations. The device includes an acquisition module and a processing module. The acquisition module is used to acquire a set of equipment objects in the urban rail transit substation and generate an equipment object identifier for each equipment object in the set. The processing module is used to construct an assertion dictionary based on the equipment object identifiers and set a statutory witness count and a heterogeneous witness count for each assertion to be verified in the assertion dictionary, while generating a witness identifier for the inspection robot corresponding to the urban rail transit substation. The processing module is also used to generate an assertion auction book, receive sealed bids corresponding to the witness identifiers, and execute a transaction decision based on expiration risk, historical dispute level, and witness count gap to generate an assertion work order identifier. The processing module is also used to obtain evidence fragments based on the witness identifiers corresponding to the assertion work order identifiers, in order to... The processing module generates assertion records and appends them to the assertion event chain. It also updates the stable region index and generates disputed assertion identifiers based on the statistical witness count and the heterogeneous witness count. Furthermore, when an emergency event is triggered, it generates an emergency fork identifier and creates an emergency fork event chain. It converts incomplete assertion work order identifiers into missing assertion tickets and writes them back to the assertion auction book. Simultaneously, it generates lightweight witness assertion records and writes them to the emergency fork event chain. After the emergency event ends, the processing module maps the lightweight witness assertion records in the emergency fork event chain to the assertion event chain. After performing a recount of the statistical witness count and a recount of the heterogeneous witness count, it updates the stable region index for assertion identifiers that meet preset conditions and generates adjudicable health conclusions. It also outputs the missing assertion tickets and the disputed assertion identifiers to achieve collaborative operation and maintenance of the inspection robot under emergency priority insertion conditions.

[0008] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, and both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method described above.

[0009] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing instructions that, when executed, perform the method described above.

[0010] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By introducing device object identifiers and assertion dictionaries, the representation of device status is abstracted from the raw data layer to a verifiable assertion layer. This transforms the inspection process from simply relying on fixed-time interval sampling to accumulating evidence and converging consensus around the assertions to be verified, fundamentally mitigating the destructive impact of time fragmentation on trend judgment. By setting statutory witness counts and heterogeneous witness counts, device status must meet dual constraints of quantity and source structure before entering the stable zone index, thereby improving the robustness and resistance to false judgments of assertion conclusions. Even if some inspections are interrupted during emergency response, as long as the witness count statistics meet the conditions, the stable zone index can form an adjudicable health conclusion, avoiding distortion of the overall health index calculation due to a single interruption. By constructing an assertion auction book and a sealed-bid mechanism, the allocation of inspection resources is transformed from fixed-path scheduling to dynamic scheduling based on assertion gaps and the degree of dispute. Under the constraints of witness count gaps and historical dispute levels, priorities can be automatically reordered, creating a structured competitive relationship between emergency and routine tasks rather than a simple preemptive relationship, improving resource utilization efficiency.

[0011] By setting emergency fork identifiers and emergency fork event chains, lightweight witness assertion records generated during emergencies maintain an isomorphic structure with regular assertion records. After the emergency ends, they are incorporated into the assertion event chain for unified statistics through a mapping mechanism, preventing emergency data from being stored in isolation or simply discarded. This achieves controllable merging and traceable mapping of emergency and regular data, ensuring data integrity. By outputting missing assertion tickets and disputed assertion identifiers, the system can clearly distinguish between insufficient witnesses and conflicting conclusions, writing them back to the assertion auction book to form new scheduling criteria. This constructs a closed-loop structure from assertion issuance, evidence generation, stability zone determination to dispute resolution and gap filling, improving the executability and interpretability of collaborative operations and maintenance. Therefore, it facilitates maintaining the continuity and traceability of equipment status expression while ensuring timely emergency response in scenarios with frequent emergency task insertions. Attached Figure Description

[0012] Figure 1 A flowchart illustrating a collaborative operation and maintenance method for urban rail transit substation inspection robots, provided in an embodiment of this application; Figure 2 A schematic diagram of a collaborative operation and maintenance device for urban rail transit substation inspection robots provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0013] Explanation of reference numerals in the attached figures: 21. Acquisition module; 22. Processing module; 31. Processor; 32. Communication bus; 33. User interface; 34. Network interface; 35. Memory. Detailed Implementation

[0014] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0015] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0016] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0017] To address the aforementioned technical problems, this application provides a collaborative operation and maintenance method for urban rail transit substation inspection robots, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a collaborative operation and maintenance method for an urban rail transit substation inspection robot, provided in an embodiment of this application. The method is applied to a server and includes steps S110 to S160, as follows:

[0018] S110. Obtain the set of equipment objects for the urban rail transit substation, and generate an equipment object identifier for each equipment object in the set.

[0019] Specifically, a server refers to a data processing and control computing node deployed in urban rail transit substations or higher-level operation and maintenance centers. It carries core logic such as constructing equipment object sets, maintaining assertion dictionaries, scheduling assertion auction books, storing assertion event chains, and managing emergency fork event chains. A server is not a single hardware component, but a logical system composed of computing units, storage units, network interface units, and scheduling and control units. It can be deployed as a physical server, a virtual machine instance, or a containerized service cluster. Essentially, it is a processing entity responsible for centralized data fusion, rule determination, and collaborative control. The server first connects to the station control layer monitoring system, asset management system, and drawing management system, pulling static asset data and dynamic operational data and performing unified encoding and merging. Static asset data describes the static attributes and spatial ownership of equipment, including at least a primary system diagram, bay layout diagram, cabinet list, equipment nameplate information, factory serial number, commissioning date, and maintenance / replacement records. Dynamic operational data describes the operational status and data observability of equipment, including at least telemetry, remote signaling, remote control, alarm records, and event sequence records. The equipment name field in static asset data describes the standardized name of the equipment and serves as a human-machine consistent retrieval entry point. The equipment installation location field describes the physical location of the equipment within the station and serves as the primary key for spatial deduplication. The interval field describes the interval maintenance boundary to which the equipment belongs and supports the subsequent definition of security domains and inspection operation scopes. The primary system topology field describes the connection relationship of the equipment in the primary system and supports subsequent topology consistency verification. The associative point table field describes the mapping relationship between the equipment and monitoring points and supports the subsequent projection of operational data onto equipment objects. Based on the above fields, the server aggregates devices with the same name, location, and topology from different system sources into a candidate set of equipment objects. Each candidate equipment object in the candidate set retains its source system tag and field confidence tag so that field conflicts can be adjudicated in the subsequent verification stage without directly overwriting the original information.

[0020] When performing deduplication and split correction on the candidate set of device objects to obtain the target set of device objects, the server considers the device installation location field and the primary system topology field as the main constraint for topology consistency verification. Topology consistency verification is used to determine whether multiple device object candidates point to the same physical device or the same maintenance object. Specifically, when the device installation location field is consistent and the primary system topology field maps to the same topology node or the same set of topology edges in the primary system graph, multiple device object candidates are merged into the same target device object. The target device object retains multi-source alias mapping relationships and multi-source point table mapping relationships to support subsequent backtracking. Split correction is used to handle situations where a device object candidate covers multiple physical components or multiple cabinet units. The server performs observable splitting of the device object candidate based on the interval field and the associative point table field, ensuring that each split target device object satisfies point table mapping closure and has a unique node affiliation in the primary system topology, thereby avoiding the subsequent incorrect assignment of the same telemetry or teleindication quantity to multiple device objects. In topology consistency verification, the primary system topology refers to the electrical connection relationship diagram between primary devices. Topology nodes are used to represent the endpoints or bus nodes of primary devices, and topology edges are used to represent electrical connections or interval connections. The point table refers to the list of monitoring system points and their correspondence with the device measurement points. Deduplication is used to eliminate duplicate entries of the same physical device in multiple systems and multiple tables. Split correction is used to split composite entries into the smallest objects that can be independently operated and observed, so that the target device object set becomes the unique object set for subsequent identification generation and evidence collection.

[0021] When generating a device object identifier for each device object in the target device object set, the server combines and encodes the site identifier, primary system topology path summary, interval identifier, device category identifier, and device serial number summary. The site identifier uniquely identifies a specific urban rail transit substation and prevents cross-site conflicts. The interval identifier solidifies the device object within the operation and maintenance boundary to support subsequent permission and security domain constraints. The device category identifier expresses the device type semantics to support assertion template matching and statistical classification. The device serial number summary maintains evolutionary traceability when device replacement occurs at the same topology location. The primary system topology path summary stably expresses the device object's position in the primary system topology and reduces conflicts caused by naming differences. The primary system topology path summary can be generated by deterministically summarizing the path node sequence from the interval entry node to the target device node in the primary system topology. For example, the summary value can be calculated by concatenating the path node sequence and the path edge sequence into a topology path string, with the expression:

[0022] in, Represents a summary of a system topology path; This represents a digest function, whose value is obtained by performing a fixed algorithm on the input string to output a fixed-length digest; This represents a normalization function used to normalize node identifiers, edge identifiers, separators, and direction markers in a topological path string according to uniform rules, in order to eliminate inconsistencies caused by case differences, redundant whitespace, and equivalent aliases; The topology path string is generated by concatenating the node identifier sequence and edge identifier sequence from the entry node of the corresponding interval to the target node of the device object in a fixed order in a primary system topology. During concatenation, the node order and edge direction are kept consistent to ensure that the same device object receives the same data from different acquisition sources. After generating the device object identifier, the server binds and stores the device object identifier with the target device object's device name field, device installation location field, interval field, primary system topology field, and associative point table field. The server also writes the device object identifier into the operation and maintenance master data for unified reference in subsequent assertion dictionary construction, assertion auction book publication, and assertion event chain appending processes. This ensures that the device object maintains consistency and traceability of object ownership even under emergency insertion and multi-robot collaboration conditions.

[0023] S120. Construct an assertion dictionary based on the device object identifier, and set a statutory witness number and a heterogeneous witness number for each assertion to be verified in the assertion dictionary. At the same time, generate a witness identifier for the inspection robot corresponding to the urban rail transit substation.

[0024] Specifically, when generating a set of assertions to be verified by reading the device category identifier and the primary system topology path summary based on the device object identifier and matching them with the assertion template set, the server first locates the entry corresponding to the device object identifier in the device object master data and reads the device category identifier and the primary system topology path summary. The device category identifier is used to limit the range of applicable assertion template types, and the primary system topology path summary is used to characterize the structural position of the device object in the primary system topology. The server pre-constructs a category adaptation vector and a topology position adaptation vector for each assertion template in the assertion template library. The category adaptation vector is used to describe the degree of matching between the assertion template and different device categories, and the topology position adaptation vector is used to describe the degree of matching between the assertion template and different topology path patterns. The matching scoring function can be expressed as:

[0025] in, This represents the overall matching score for a given assertion template. This is a weighting coefficient used to adjust the contribution ratio of different similarity items, and its value range is a non-negative real number; The device category identifier of a device object is represented by a vectorized representation. Represents the category adaptation vector of the assertion template; This represents the category similarity function, used to calculate the degree of matching between the device category and the template category, and its value ranges from 0 to 1; This represents a vectorized representation of a system topology path summary. Represents the topological position adaptation vector of the assertion template; This represents the topological similarity function, used to measure the degree of structural similarity between the location of a device in a primary system and the location of the template adaptation. Represents the historical fault feature vector of the equipment; This represents the adaptation vector of the assertion template for historical failure modes; This represents the historical pattern similarity function. The server selects those that satisfy... assertion template, in which A matching threshold is used to control the strictness of assertion template selection. The selected assertion template is instantiated to generate a set of assertions to be verified. Each assertion to be verified contains an assertion identifier, a set of assertion applicable operating condition labels, and a set of observation semantic slots, and establishes a one-to-one mapping relationship with the device object identifier.

[0026] When setting the statutory witness count based on the risk level and device criticality of the set of assertions to be verified, the server performs numerical modeling of the risk level and device criticality. Risk Level This is derived from a comprehensive assessment of the potential safety consequences and operational impacts of assertion failure, and the criticality of the equipment. It originates from the topological centrality and load coverage ratio of the equipment in the primary system power supply path. To enhance sensitivity and nonlinear expression, the statutory witness number is calculated using a nonlinear coupling function, the expression of which is:

[0027] in, Indicates the statutory number of witnesses; This represents the rounding function; Represents the fundamental witness number constant; This represents the coupling weight coefficient, used to control the impact of the risk level squared term, the criticality squared term, the cross term, and the logarithmic coupling term on the results; This represents the risk level numerical value, which is a non-negative real number and increases as the risk increases. This represents the criticality level of the equipment, and its value is a non-negative real number that increases as the criticality level increases. This represents the natural logarithm function, used to suppress excessively rapid growth in high-value ranges. The expression reflects the amplification effect of risk and criticality through squared and cross terms, and suppresses extreme value fluctuations through the logarithmic term, causing the statutory witness count to grow non-linearly with the systemic risk structure, thereby raising the witness threshold for high-risk assertions.

[0028] The heterogeneous witness number is determined based on the differences in motion morphology involved in the observed semantic slot set. The server first performs motion morphology requirement parsing on the observed semantic slot set and constructs a motion morphology requirement vector. Furthermore, a motion morphology capability vector is constructed based on the witness identifiers generated by the inspection robot. The expression for calculating heterogeneous demand intensity is:

[0029] in, Indicates the intensity of differences in motion patterns; Indicates the first Weighting coefficients for motion-like patterns; Represents the set of observed semantic slots for the first... The degree of demand for similar movement forms; This indicates that witnesses have been covered in the current number of events. Average coverage of similar motion patterns; This represents the total number of motion pattern categories. According to... The size of the heterogeneous witness number is set, and its calculation formula is:

[0030] in, Indicates the number of heterogeneous witnesses; This represents the difference amplification factor, used to adjust the impact of heterogeneous demand on the number of witnesses; This represents the floor function. This approach dynamically raises the heterogeneous witness threshold by measuring the difference between observation needs and existing capabilities, thereby avoiding systematic bias caused by repeated acquisition of single motion patterns.

[0031] When generating witness identifiers for inspection robots, the server encodes the robot type identifier, motion pattern identifier, sensor capability set summary, and security domain level identifier into a unified structure, and generates the witness identifier through a combination function. The combination expression can be represented as:

[0032] in, Indicates the identity of the witness; Represents a summary function; Indicates the robot type identification code; Indicates the motion pattern identification code; Represents a summary encoding of the sensor capability set; Indicates the security domain level identifier code; This indicates a field concatenation operation. The server also establishes a feasibility mapping matrix between witness identifiers and device object identifiers, used for subsequent assertion auction book scheduling and assertion record statistics.

[0033] Finally, the server writes the set of assertions to be verified, the number of quorum witnesses, the number of heterogeneous witnesses, and the witness identifiers into the assertion dictionary structure. The assertion dictionary uses the assertion identifier as the primary key and includes the device object identifier, the set of applicable assertion condition tags, the set of observation semantic slots, the number of quorum witnesses, and the number of heterogeneous witnesses. It also stores the overlay mapping relationship between the witness identifiers and the set of observation semantic slots. The assertion dictionary permanently assigns a version number and an effective time marker, ensuring that assertion rules and witness thresholds remain traceable and consistent throughout version evolution. This provides a unified structural foundation for subsequent assertion auction book publication, assertion record generation, and stable zone index statistics.

[0034] S130. Generate an assertion auction book, receive sealed bids corresponding to witness identifiers, and execute transaction decisions based on expiration risk, historical dispute level, and witness count gap to generate assertion work order identifiers.

[0035] Specifically, when constructing the assertion auction book under the constraints of the assertion dictionary and device object identifier, the server first reads the device object identifier, the set of applicable assertion condition tags, the set of observation semantic slots, the number of quorum witnesses, and the number of heterogeneous witnesses from the assertion dictionary using the assertion identifier as the primary key. It then simultaneously reads the aggregated statistical results of the assertion event chain, the stable region index, and the dispute queue to generate the assertion status, the statistical results of the number of quorum witnesses, the statistical results of the number of heterogeneous witnesses, and the coverage status of the observation semantic slots. The assertion auction book is a structured release table for rolling window publication. The rolling window is jointly defined by the time window boundary and the condition window boundary. The time window boundary is used to limit the effective refresh cycle of this bidding and dispatching, while the condition window boundary is used to limit whether the set of applicable assertion condition tags is encountered within the current window. Expiration risk is used to characterize the urgency of an assertion completing the accumulation of valid witnesses within the current rolling window. Historical controversy is used to characterize the intensity and frequency of conflicting conclusions in historical statistics. Witness gap is used to characterize the remaining difference between the statutory witness count and the heterogeneous witness count relative to the current aggregated statistical result. The server writes the above dynamic fields and the fixed fields of the assertion dictionary into the assertion auction book entries, so that subsequent sealed bid verification and transaction decisions can simultaneously constrain semantic consistency, object consistency and convergence target consistency on the same assertion identifier dimension.

[0036] When receiving a sealed bid submitted by a witness identifier and performing security domain feasibility and operational condition matching checks, the server accesses the sealed bid using the witness identifier as an index and first performs field completeness and field consistency checks. Field completeness checks ensure that the sealed bid includes the assertion identifier, device object identifier, target observation semantic slot identifier, reachable security domain set matching result, expected arrival window, expected evidence quality level, and heterogeneous witness type marker. Field consistency checks ensure that the assertion identifier and device object identifier exist in the assertion dictionary and that the target observation semantic slot identifier belongs to the observation semantic slot set corresponding to that assertion identifier. Security domain feasibility checks are based on the reachability mapping relationship of the device object identifier. This reachability mapping relationship is fixed by the spatial map anchor point set, corridor anchor points, and safety distance boundary anchor points. The check objective is to determine whether, under the constraints of the security domain level identifier, there exists a path from the current location anchor point to the target observation semantic slot identifier, and that this path does not cross the prohibited safety distance boundary anchor points. The working condition matching verification is used to determine whether there is a foreseeable intersection between the expected arrival window and the set of working condition labels applicable to the assertion. The server generates a set of foreseeable working condition intervals from the station control layer operation data and the working condition prediction model, and calculates the degree of overlap with the set of working condition labels applicable to the assertion within the expected arrival window. Whether the degree of overlap reaches a preset threshold is used as the matching condition, thereby avoiding the passive widening of the assertion record confidence boundary due to dispatching work under unverifiable working conditions.

[0037] When generating priority keys based on maturity risk, historical controversy, and witness count gap, the server constructs a multi-factor convergence driving function for each assertion identifier within the current scrolling window. This ensures that the priority key not only reflects urgency and controversy but also the structural uncertainty of the witness gap and the predictability of the working conditions, forming a sortable target metric under the feasibility constraints of the candidate closed-end bid set. The priority key can employ a nonlinear expression with risk-sensitive terms, gap coupling terms, and time-window survival terms.

[0038] in, This represents the priority key, with a value ranging from 0 to 1, and a larger value indicates a higher priority. This represents a compression function used to map real numbers within parentheses to 0 to 1 while maintaining sorting resolution in the high-value range. The value can be obtained using a monotonically increasing sigmoid function. to This represents the weighting coefficient, which takes the value of a non-negative real number and is determined by the operation and maintenance strategy configuration or offline parameter tuning. It represents the risk of expiration, and its value is a urgency index obtained by comprehensively considering the remaining time of the effective assertion window, the criticality of the equipment, and the predictability of the operating conditions. The larger the value, the more urgent the situation. This represents the urgency amplification function, used to amplify the convexity of the high urgency interval to avoid assertions nearing expiration being crowded out by low-controversy assertions for a long time. The value can be obtained by using a piecewise convex function. The historical degree of controversy is represented by a value obtained by combining the frequency of occurrence in the controversy queue, the proportion of conflicting conclusions and the number of times counter-evidence is involved. The larger the value, the more likely it is to cause conflict. This represents a dispute-sensitive function, used to impose higher priority on medium- to high-controversy assertions in order to accelerate dispute resolution. The value can be a log-weighted convex function. This represents the shortfall in the statutory witness count, and its value is calculated by subtracting the statutory witness count from the statutory witness count and truncating it to a non-negative value. This represents the heterogeneous witness count gap, and its value is obtained by subtracting the heterogeneous witness count from the heterogeneous witness count and truncating it to be non-negative. This represents the gap coupling function, used to simultaneously penalize both quantitative and structural gaps, reflecting the higher risk of structural gaps. Its value can be determined by combining cross-terms and saturation terms, for example, for... To prioritize filling heterogeneous sources; This represents the coverage of the observation semantic slots, and its value is the proportion of target observation semantic slots in the observation semantic slot set that have not yet been covered by valid assertion records. This indicates that the slot does not cover the amplification function, which is used to avoid the assertion conclusion from biasing the observation geometry due to repeated verification in only a few slots. The value can be a power function or an exponential function. This represents the survival probability of the time window. The value is determined by the combination of the foreseeable range of working conditions within the current scrolling window and the set of available witness identifiers. The larger the value, the more likely it is to be completed within the window. This represents the survival gain function, which is used to prioritize assertions with higher completion probabilities to improve overall convergence throughput. The value can be determined using logarithmic gain to suppress extreme values. It represents the scarcity of security domains. The value is the reciprocal of the proportion of witness identifiers that can enter the target security domain within the current window or its monotonic transformation. The larger the value, the scarcer the security domain. This represents the scarcity penalty function, used to avoid over-dispatch causing congestion and failure retries when resources are extremely scarce. The value can be a linear or convex penalty function.

[0039] When selecting a bid combination that satisfies the statutory witness count and heterogeneous witness count requirements from validated sealed bids under the same assertion flag based on the priority key, the server first constructs a candidate set of validated sealed bids and groups the candidate set by heterogeneous witness type to ensure that the selected bid combination can cover the different categories required for the heterogeneous witness count gap. Simultaneously, the server scores the feasibility of the candidate set based on the overlap between the expected arrival window and the foreseeable working conditions to avoid selecting bids that cannot be implemented within the window. The bid combination selection can be expressed as a combinatorial optimization problem with hard constraints and soft objectives. The hard constraints are used to enforce the satisfaction of the statutory witness count and heterogeneous witness count, while the soft objective aims to maximize evidence quality and minimize time risk and resource conflicts while satisfying the hard constraints. The expression is:

[0040] in, This represents the set of candidate sealed bids that pass the validation under the same assertion identifier; Indicates from The selected bid combination; This represents the optimal bid combination; This indicates selecting the combination with the smallest target value from all feasible bid combinations; to This represents the target weight coefficient, and its value range is a non-negative real number. This represents the time risk factor, and its value is calculated based on the overlap strength between the expected arrival window and the foreseeable operating condition interval. The weaker the overlap, the higher the risk. This represents a security risk item, and its value is calculated based on the matching result of the reachable security domain set and the security domain level margin. The smaller the margin, the higher the risk. This represents the resource consumption cost item, and its value is calculated based on the expected dwell time, path length, or probability of conflict with other work orders. This represents the quality benefit item, and its value is derived from the benefit mapped from the expected quality level of the evidence. The higher the quality level, the greater the benefit. This represents the set of categories corresponding to the heterogeneous witness type marker of the bid; This represents the feasibility determination function. A value of 1 indicates that the bid passes the security domain feasibility check, the working condition matching check, and the slot coverage check simultaneously, while a value of 0 indicates that it is not feasible. Under the premise that hard constraints ensure the number of witnesses and the heterogeneous structure of witnesses are met, by minimizing the risks of time-based failures and security failures while considering resource consumption and maximizing evidence quality benefits, the final dispatch can both quickly promote the convergence of the stable region index and reduce the probability of mid-process failures caused by emergency insertions.

[0041] When a bid combination is solidified into an assertion work order identifier, the server splits the bid combination into a set of assertion work order identifiers based on the witness identifier. For each assertion work order identifier, the server solidifies the assertion identifier, device object identifier, target observation semantic slot identifier, target operating condition label, witness identifier, work order valid window, and work order priority key. Simultaneously, the expected evidence quality level, heterogeneous witness type marker, reachable security domain set matching result, and mapping benchmark version are written into the work order constraint summary. The solidification of assertion work order identifiers transforms the commitments made during the bidding phase into executable dispatch credentials. This ensures that subsequent witness identifiers have consistent target constraints, traceable decision-making basis, and verifiable constraint sources when performing evidence fragment collection and assertion record generation. Furthermore, it enables the re-counting of statutory witnesses and the re-counting of heterogeneous witnesses after the assertion event chain is appended to achieve idempotent convergence with reference to the mapping benchmark version, avoiding statistical distortion caused by duplicate dispatching or dispatch drift.

[0042] S140. Obtain evidence fragments based on the witness identifier corresponding to the assertion work order identifier to generate an assertion record. At the same time, append the assertion record to the assertion event chain, update the stable zone index based on the number of legal witnesses and the number of heterogeneous witnesses, and generate a disputed assertion identifier.

[0043] Specifically, when parsing and generating an executable constraint set and obtaining evidence fragments under the constraints of the assertion work order identifier, the inspection robot corresponding to the witness identifier first parses the executable constraint set from the assertion work order identifier issued by the server. The executable constraint set is used to transform the work assignment commitment into feasible on-site execution conditions, and at least includes the assertion identifier, device object identifier, target working condition label, target observation semantic slot identifier, work order effective window, and safety domain constraint summary. The device object identifier is used to locate the spatial map anchor point set in the robot's local device object cache. The spatial map anchor point set is a set of identifiable position constraints for the device object in the station space, and at least includes visual identifier anchor points, passageway anchor points, and safety distance boundary anchor points. Visual identifier anchor points are used for visual or geometric confirmation of the device object, passageway anchor points are used to limit the path skeleton that the robot can pass through, and safety distance boundary anchor points are used to limit the allowable access range of the electrified area. Near-field localization verification is used to reconfirm that the device object identifier has not been mismatched when approaching the target device object. In implementation, the identification results of the visual identifier anchor points are jointly judged with the geometric consistency verification results of the spatial map anchor point set, so that the robot completes the object attribution closure before entering the slot acquisition configuration. The target working condition label is a discretized description of the assertion applicable working condition. The working condition consistency gating is used to confirm that the current on-site operating state is consistent with the target working condition label. In implementation, the telemetry and teleindication quantities associated with the device object identifier are read from the station control layer operation data and combined with the robot's local environment observation to generate a working condition consistency score. When the working condition consistency score reaches the threshold and is still within the work order's valid window, the slot acquisition configuration is called according to the target observation semantic slot identifier to obtain evidence fragments. The slot acquisition configuration is a set of acquisition action constraints for the observation semantic slot, which includes at least the sensor operating point, field of view skeleton, dwell time, sampling frequency, and quality threshold, so that the evidence fragments meet the verifiability conditions at the acquisition side rather than relying on post-processing remedies.

[0044] When generating evidence fragment fingerprint summaries and assertion records based on evidence fragments, the inspection robot performs fingerprint summarization processing on the evidence fragments. The evidence fragment fingerprint summary is used to establish an unconfusable evidence citation key during aggregation and deduplication at the central side, and is also used to backtrack to the corresponding evidence fragment after the disputed assertion identifier is formed. The expression for the evidence fragment fingerprint summary is:

[0045] in, This represents a fingerprint summary of the evidence fragment; This represents a summary function used to generate a fixed-length summary from the concatenated and normalized content; This represents a normalization function used to eliminate encoding differences, timestamp format differences, and irrelevant metadata differences, while maintaining the consistency of the summary of the same evidence across different transmission links. This represents the set of evidence fragments, and its value is obtained by structurally encapsulating the valid data stream used for assertion determination in the evidence fragments. This represents a set of metadata for evidence fragments, with values ​​derived from assertion identifiers, device object identifiers, target operating condition labels, target observation semantic slot identifiers, witness identifiers, acquisition time boundaries, and sensor operating points. This represents the set of key fragment indices, which are selected by extracting key frame indices, key temperature zone indices, key spectral peak indices, or key state transition indices from the set of evidence fragment content. This represents a set of acquisition parameter summaries, which are obtained by encoding acquisition parameters such as exposure strategy, gain configuration, filter configuration, and sampling frequency configuration. This indicates a field concatenation operation, used to combine different sets into the same summary base string in a fixed order. The inspection robot generates assertion conclusions and confidence boundary descriptions based on the assertion judgment rules corresponding to the assertion identifiers in the assertion dictionary. The assertion conclusions characterize the satisfaction status of the assertion to be verified under the current evidence fragment conditions, while the confidence boundary descriptions characterize the constraint range of the target observation semantic slot coverage, the satisfaction of evidence quality thresholds, and the working condition consistency gating results, upon which the assertion conclusions depend. Subsequently, the assertion identifier, target working condition label, target observation semantic slot identifier, evidence fragment fingerprint summary, assertion conclusion, confidence boundary description, and witness identifier are encapsulated into assertion records and appended only to the assertion event chain. The assertion event chain is a set of assertion records appended only in chronological order, used to ensure that subsequent statistics and tracing do not rely on overwrite modifications.

[0046] When aggregating statistics and updating the stable zone index or generating disputed assertion identifiers in the assertion event chain, the server performs aggregation statistics on the assertion event chain. The aggregation statistics use the assertion identifier, condition label, and observation semantic slot identifier as the aggregation key. For assertion records under the same aggregation key, duplicate evidence fragment fingerprint summaries and witness identifiers are deduplicated, and the statutory witness count and heterogeneous witness count are calculated separately. The statutory witness count indicates the number of assertion records that meet the validity conditions under the same aggregation key. The heterogeneous witness count indicates the number of witness identifiers from different motion morphology identifiers or different heterogeneous witness type tags. The motion morphology identifier characterizes the motion platform category and reachability geometry differences of the witness identifier, and the heterogeneous witness type tag characterizes the category affiliation of the witness identifier in the heterogeneous statistics. The server reads the statutory witness count and heterogeneous witness count corresponding to the assertion identifier from the assertion dictionary and performs a satisfaction determination. When the statistical results of the statutory witness count and the statistical results of the heterogeneous witness count simultaneously reach the corresponding threshold and the assertion conclusion is consistent within the same aggregate key, the assertion identifier, along with the working condition label and the observation semantic slot identifier, is written into the stable region index. The stable region index is a set of indexes used to record the assertion identifiers that have reached the consensus convergence state and is used for the subsequent generation of adjudicable health conclusions. When the statistical results of the statutory witness count and the statistical results of the heterogeneous witness count reach the corresponding threshold but the assertion conclusions conflict, a disputed assertion identifier is generated and written into the dispute queue. The disputed assertion identifier is used to uniformly number the conflicting assertions and drive the subsequent rebuttal and re-witness scheduling, enabling the system to explicitly externalize the conflicts caused by emergency insertion and sampling fragmentation into schedulable objects rather than implicit pollution trend statistics.

[0047] S150. When an emergency event is triggered, an emergency fork identifier is generated and an emergency fork event chain is created. Incomplete assertion ticket identifiers are converted into missing assertion tickets and written back to the assertion auction book. At the same time, lightweight witness assertion records are generated and written to the emergency fork event chain.

[0048] Specifically, when generating an emergency fork identifier and creating an emergency fork event chain upon meeting the emergency trigger criteria, the server first continuously subscribes to the alarm records and event sequence records of the station control layer monitoring system. This, combined with environmental safety alarms transmitted from the inspection robot, forms the input for the emergency trigger criteria. The emergency trigger criteria are used to filter sudden events from general alarms into emergency events requiring priority dispatch. The emergency trigger criteria are constrained by the event credibility level, the event impact scope, and the event handling time limit. The event credibility level characterizes the degree of confidence that the event is a genuine anomaly; the event impact scope characterizes the set of affected device object identifiers and the set of affected security domains; and the event handling time limit characterizes the time boundary at which emergency handling must be completed. The server integrates these factors into an emergency trigger score and compares it with the trigger threshold. The expression for the emergency trigger score is:

[0049] in, This represents the emergency trigger score, ranging from 0 to 1, with a larger value indicating a closer proximity to an emergency. This represents a compression function used to compress the result of a linear combination to between 0 and 1 while maintaining monotonicity; , , , This represents the weighting coefficient, which takes the value of a non-negative real number and is configured by the operation and maintenance strategy. This represents a normalization function used to map quantities of different dimensions to 0 to 1 while maintaining monotonicity; It indicates the confidence level of the event, and the value is determined by the confidence index given by the consistency of multi-source alarms, alarm persistence and sensor self-test status; This indicates the scope and intensity of the event's impact, and its value is a weighted result based on the number of affected device object identifiers, the number of affected intervals, and the level of the affected security domain. Indicates the incident handling time limit, and its value is the maximum allowable response time read from alarm rules or emergency plans; It represents a very small positive number and is used to avoid the denominator being zero; This represents the propagation risk, and its value is derived from a comprehensive risk index based on the length of the fault propagation path, the coverage of critical nodes, and the magnitude of load fluctuations in a single system topology. It satisfies... When the threshold is not less than the trigger threshold, the server generates an emergency fork identifier and creates an emergency fork event chain under the operation and maintenance status ledger identifier. The emergency fork identifier is used to uniquely identify an emergency fork instance and serves as the primary key of the emergency fork event chain. The operation and maintenance status ledger identifier is used to represent the ledger namespace of this site in the global scope. The isomorphic structure of the emergency fork event chain and the assertion event chain means that both use assertion records as the smallest writing unit and have the same field structure. Only the emergency fork identifier is added to the emergency fork event chain as the ownership metadata, so as to ensure that no structural conversion is required during subsequent mapping and merging.

[0050] When freezing an assertion work order in an incomplete state and converting it into a missing assertion ticket, the server first searches the maintenance status ledger for all assertion work order identifiers that are not yet closed in the distribution process. It then determines whether freezing is necessary based on the work order's valid window, whether the security domain corresponding to the target observation semantic slot is occupied by an emergency, and the current occupancy status of the witness identifier. Work order freezing temporarily reclaims the execution right of regular work assignment from the witness identifier and fixes the execution progress at the time of freezing. After freezing, a freezing credential is generated and written to the maintenance status ledger. The freezing credential includes at least the assertion work order identifier, assertion identifier, device object identifier, target condition label, target observation semantic slot identifier, freezing time stamp, and incomplete reason stamp. The incomplete reason stamp distinguishes between conditions not met, security domain inaccessible, path unreachable, and emergency preemption. The frozen assertion work order identifiers are then converted into missing assertion tickets. Missing assertion tickets are used to represent incomplete assertion work order identifiers as reschedulable gap objects. Their fields include at least the assertion identifier, device object identifier, target condition label, target observation semantic slot identifier, statutory witness number gap, heterogeneous witness number gap, and missing valid window. Missing valid window is used to limit the gap to be filled within the time range that the set of assertion applicable condition labels can still be foreseen, so that missing assertion tickets become the direct input for the subsequent re-issuance of the assertion auction book instead of relying on manual re-creation of the order.

[0051] When writing back missing assertion notes to the assertion auction book and updating the witness count gap and maturity risk weight, the server merges the missing assertion notes into the assertion auction book entries according to the assertion identifier and performs gap recalculation. Gap recalculation is used to incorporate the existing statutory witness count statistics and heterogeneous witness count statistics in the assertion event chain into the missing assertion notes, ensuring that the witness count gap in the assertion auction book always reflects the current true gap rather than a snapshot at the freeze moment. The write-back means using the missing assertion notes as a source of dynamic fields for the assertion auction book, thereby triggering sealed bids and execution decisions in the subsequent rolling window. The maturity risk weight update is used to increase the scheduling priority of missing assertion notes after emergency insertion, avoiding long-term vacant gaps formed after multiple emergency preemptions during regular inspections. The maturity risk weight update can be achieved by applying time decay compensation and gap amplification compensation to the maturity risk in the assertion auction book, and its expression is:

[0052] in, This represents the updated maturity risk, with a value ranging from 0 to 1. This represents a truncation function used to restrict the result to the range of 0 to 1; This indicates the expiration risk before the update, and its value is calculated based on the urgency level obtained from the remaining length of the assertion window and the predictability of the operating conditions. This represents the shortfall in the statutory witness count, and its value is calculated by subtracting the statutory witness count from the statutory witness count and truncating it to a non-negative value. This represents the heterogeneous witness count gap, and its value is obtained by subtracting the heterogeneous witness count from the heterogeneous witness count and truncating it to be non-negative. This represents the time interval from the freeze time marker to the current starting point of the scrolling window, and its value is calculated from the time marker difference recorded in the operation and maintenance status ledger. , , , Represents the weighting coefficient and attenuation coefficient, with values ​​being non-negative real numbers. and Used to amplify the contribution of the gap to the sense of urgency. and This describes the magnitude and rate of increase in compensation over time. By converting quantity gaps, structural gaps, and freeze duration into urgency increments, it ensures that missing assertion tickets receive quantifiable priority during scheduling after the emergency ends, while preventing unlimited growth that could lead to uncontrolled ranking.

[0053] During emergency execution, when a lightweight witness assertion record is generated based on the emergency fork identifier and the target observation semantic slot identifier and written into the emergency fork event chain, the server distributes the path fragments and docking point sets of the emergency task to the inspection robot corresponding to the witness identifier. On the inspection robot side, a lightweight witness trigger condition is calculated for each docking point. The lightweight witness trigger condition ensures that minimal evidence is collected from the target observation semantic slot identifiers that can be covered along the route without changing the emergency response path. Lightweight witness means that the evidence fragment collection coverage is explicitly limited to the reachable range of the emergency path, and the collection duration and frequency adopt the minimum verifiable configuration of the slot collection configuration, thereby reducing the impact on the response time limit. After satisfying the security domain access conditions and operational condition consistency gating conditions of the target observation semantic slot identifier, the inspection robot generates evidence fragments and forms lightweight witness assertion records. The lightweight witness assertion record has the same field structure as the assertion record, including at least the assertion identifier, target operational condition label, target observation semantic slot identifier, evidence fragment fingerprint summary, assertion conclusion, confidence boundary description, and witness identifier. An emergency fork identifier is appended to the attribution metadata to indicate that the assertion record originates from the emergency fork event chain. Subsequently, the lightweight witness assertion record is appended only to the emergency fork event chain, and the missing status of missing assertion tickets is updated synchronously. The missing status is used to characterize whether the missing assertion ticket is incomplete, has obtained lightweight witness status, or has met the witness gap convergence condition at the current stage. Synchronous updates mean that the successful writing of lightweight witness assertion records is used as a trigger condition to reduce the witness count gap in the assertion auction book entries or update the observation semantic slot coverage status in real time. This enables subsequent transaction decisions to include lightweight witness assertion records in the preparation set of statutory witness count statistics and heterogeneous witness count statistics. In this way, the emergency process is transformed from a disturbance that disrupts the continuity of inspection into structured incremental evidence that can be absorbed by the ledger and subsequently re-statistically utilized.

[0054] S160. After the emergency event ends, the lightweight witness assertion record in the emergency fork event chain is mapped to the assertion event chain. After performing the statutory witness count recount and the heterogeneous witness count recount, the stable region index is updated for the assertion identifier that meets the preset conditions and an adjudicable health conclusion is generated. At the same time, missing assertion tickets and disputed assertion identifiers are output to realize the collaborative operation and maintenance of the inspection robot under the emergency priority insertion condition.

[0055] Specifically, after an emergency event ends, a fork closure action is performed based on the emergency fork identifier, and a fork closure credential is generated. Simultaneously, when performing mapping preparation verification on lightweight witness assertion records, the server first reads the emergency event end marker from the station control layer's operational data. Using the emergency fork identifier, it locates the emergency fork event chain under the operation and maintenance status ledger identifier. The fork closure action is then performed to solidify the end time marker and end position marker of the emergency fork event chain, ensuring that the set of lightweight witness assertion records before the end time marker enters a mappable state and preventing append writes after the end time marker. The fork closure credential is written to the operation and maintenance status ledger identifier and bound to the emergency fork identifier, end time marker, end position marker, assertion dictionary version evolution marker, and device object master data version evolution marker. The version evolution marker is used to lock the rule version and object version upon which the mapping interpretation is based. The mapping preparation verification sequentially performs field integrity verification, assertion dictionary validity verification, observation semantic slot attribution verification, attribution consistency verification, and duplication risk assessment for each lightweight witness assertion record. During the verification process, a mapping preparation score is calculated to support interpretable pass threshold determination. The expression for the mapping preparation score is:

[0056] in, This represents the mapping readiness score, with a value ranging from 0 to 1, and a larger value indicates a better fit for mapping. This represents a compression function used to map the result within the parentheses to 0 to 1 while maintaining a monotonically increasing order. to This represents the weighting coefficient, which takes the value of a non-negative real number and is configured by the operation and maintenance strategy. This indicates the field integrity indicator; 1 represents a complete field and 0 represents a missing field. This indicates the validity indicator of the assertion dictionary; it is 1 if the assertion flag exists and is in the effective window, otherwise it is 0. This indicates the observation semantic slot attribution indicator. The value is 1 if the observation semantic slot identifier belongs to the set of observation semantic slots corresponding to this assertion identifier, and 0 otherwise. This indicates the consistency indicator. The value is 1 if the emergency fork identifier attached to the lightweight witness assertion record matches the emergency fork identifier in the fork closure credential, and 0 otherwise. This represents the version deviation, and its value is the aggregated result of the difference between the version evolution marker carried by the lightweight witness assertion record and the version evolution marker carried by the fork closure credential in the assertion dictionary version and device object master data version dimensions. This represents the attenuation coefficient, which is a non-negative real number used to control the severity of the penalty imposed on the score by version deviation. The metadata interpretability score is calculated based on whether the confidence boundary description includes the coverage ratio of the operating condition consistency gating results, the collection configuration summary, the evidence quality level, and the security domain feasibility summary. This indicates a duplicate risk item, and its value is obtained by normalizing the frequency of repeated occurrences of the same assertion identifier, target condition label, observation semantic slot identifier, evidence fragment fingerprint digest, and witness identifier combination in the emergency fork event chain. This represents the delay amount, and its value is the interval between the light witness assertion record acquisition time marker and the fork closure time marker; This represents the delay reference threshold, with a value that is a non-negative real number, used to distinguish between acceptable and unacceptable delays. This represents a truncation function, which outputs the input value when the input is greater than 0, and outputs 0 when the input is not greater than 0. The score ensures structural validity through indices, strengthens version consistency and metadata interpretability through exponential and hyperbolic tangent terms, and suppresses statistical pollution caused by repeated mappings and long delays through logarithmic and squared penalty terms, thus ensuring that the data entering the mapping stage possesses structural isomorphism and interpretability.

[0057] When lightweight witness assertion records prepared for verification through mapping are appended to the assertion event chain and a mapping log is generated, the server allocates an append position for each lightweight witness assertion record in the assertion event chain and performs idempotent write control. Idempotent write control is jointly implemented through mapping fingerprints and mapping logs. The mapping log writes the operation and maintenance status ledger identifier and binds the source lightweight witness assertion record identifier, the target assertion event chain position, the mapping timestamp, the mapping result marker, and the mapping fingerprint, so that when mapping is repeatedly triggered, the mapping fingerprint can be used to determine whether the append has been successfully completed. The mapping fingerprint does not simply rely on field concatenation digests, but incorporates the evidence fragment fingerprint digest, assertion conclusion, confidence boundary description digest, version evolution marker, and emergency fork attribution, and recombines them through segmented digests to improve collision resistance and idempotent stability. The expression for the mapping fingerprint is:

[0058] in, Indicates a mapped fingerprint; This represents a digest function used to output a fixed-length digest and for idempotency deduplication. This represents a normalization function used to eliminate format differences, encoding differences, and redundant whitespace while ensuring that business-equivalent content achieves a consistent normalization result. Indicates assertion identifier; Indicates the target operating condition label; Indicates the semantic slot identifier for observation; This represents a fingerprint summary of the evidence fragment; Indicates the identity of the witness; Indicates an emergency fork indicator; This represents the assertion conclusion, and its value is obtained by encoding the enumerated value or structured result of the assertion conclusion; This represents a summary of the confidence boundary description. The value is obtained by normalizing the structured serialization of the coverage, working condition consistency gating result summary, quality threshold satisfaction summary and path constraint summary in the confidence boundary description. This represents the version evolution flag, and its value is a combination of the assertion dictionary version evolution flag and the device object master data version evolution flag. This indicates a field concatenation operation performed in a fixed order. This fingerprint reduces the impact of single-point field anomalies on idempotency deduplication through hierarchical combination of multiple digests, ensuring consistent mapping results for the same lightweight witness assertion record under retry and repeated triggering scenarios, and preventing duplicate counting of statutory witnesses and heterogeneous witnesses.

[0059] When performing a re-statistical analysis and satisfaction determination based on the assertion event chain according to the assertion identifier, target condition label, and observation semantic slot identifier, the server constructs an aggregation key using the assertion identifier, target condition label, and observation semantic slot identifier. It then performs deduplication and validity filtering on the set of assertion records under the same aggregation key in the assertion event chain. Deduplication includes at least mapping fingerprint deduplication, evidence fragment fingerprint digest deduplication, and witness identifier deduplication. Validity filtering includes at least confidence boundary description integrity filtering and condition consistency gating validity filtering. The re-statistical output includes legal witness count results and heterogeneous witness count results. The legal witness count results are used to count the number of witness identifiers for valid assertion records, while the heterogeneous witness count results are used to count the number of heterogeneous witness type tag categories covered by the aforementioned witness identifiers. To enable re-statistics to characterize the path constraints and evidence quality differences of lightweight witness assertion records while maintaining the interpretability of satisfaction determination, effective weights are calculated for each assertion record during implementation, and weighted statistical results are output simultaneously. Subsequently, satisfaction determination is performed using unweighted statistical results and assertion dictionary thresholds, and the weighted statistical results are used to generate a credibility stratification for adjudicable health conclusions. The expression for the effective weights is:

[0060] in, Indicates the first The effective weight of each assertion record, with a value ranging from 0 to 1; Represents the compression function; to This represents the weighting coefficient, which takes the value of a non-negative real number and is configured by the operation and maintenance strategy. This represents the evidence quality level mapping value, which is determined by mapping the evidence quality level to a continuous numerical value, with higher quality levels having larger numerical values. This indicates the strength of operating condition consistency, and its value is obtained by normalizing the operating condition consistency score output by the operating condition consistency gating. This indicates the adequacy of slot coverage, and its value is calculated based on the coverage range in the confidence boundary description and the coverage requirements of the target observation semantic slot identifier. The value represents the strength of the path constraint, which is obtained by parsing the degree of restriction of the emergency path constraint on the observation geometry and dwell time from the confidence boundary description and then normalizing it. This represents the delay penalty, and its value is obtained by normalizing the interval between the assertion record acquisition time marker and the re-statistic trigger time marker; This represents the penalty for duplication and similarity, and its value is determined by the aggregation of similarity between the assertion record and other assertion records under the same aggregation key in terms of proximity in evidence fragment fingerprint summary or proximity in collection parameter summary. This represents the validity indicator, with a value of 1 if the assertion record passes the field validity and confidence boundary description integrity checks, and 0 otherwise. The unweighted calculation of the statutory witness count and the heterogeneous witness count can be represented as the count of the set of deduplicated valid assertion records and the union count of the set of heterogeneous witness type tags, respectively. The weighted statistical result can be represented as the sum of the valid weights and the sum of the heterogeneous category weights, thus separating the threshold satisfaction determination from the credibility boundary characterization. During the satisfaction determination, the statutory witness count and the heterogeneous witness count corresponding to the assertion identifier are read from the assertion dictionary and compared with the statutory witness count and the heterogeneous witness count, respectively. If both reach the threshold, the assertion conclusion consistency determination is initiated; otherwise, insufficient witness processing is initiated and the missing assertion document is updated.

[0061] When the statistical results satisfy the requirements of the statutory witness count and the heterogeneous witness count, and the assertion conclusions are consistent, the stable region index is updated and an adjudicable health conclusion is generated. When assertion conclusions conflict, a disputed assertion identifier is generated. When witnesses are insufficient, missing assertion tickets are updated and written back to the assertion auction book. The server performs consistency determination on assertion conclusions under the same aggregation key. Consistency determination not only statistically analyzes the conclusion distribution but also incorporates the comparability of confidence boundary descriptions into the consistency constraints, enabling assertion conclusions generated by different witness identifiers under different acquisition windows to be compared under conditions of boundary consistency. The conclusion consistency score can be jointly generated based on the conclusion distribution entropy, the maximum proportion of conclusions, and boundary similarity, and its expression is:

[0062] in, The score represents the consistency of the conclusions, ranging from 0 to 1, with a larger value indicating greater consistency. Represents the compression function; to This represents the weighting coefficient, which takes the value of a non-negative real number and is configured by the operation and maintenance strategy. This represents the distribution vector of assertion conclusions, and its value is obtained by dividing the number of occurrences of each type of assertion conclusion under the same aggregation bond by the total number of occurrences. This represents the number of assertion conclusion categories, and its value is determined by the number of assertion conclusion categories allowed by the assertion dictionary for this assertion identifier. Represents the distribution entropy, and its value is determined by... The entropy function is used to measure the uncertainty of the distribution; the higher the entropy, the more dispersed the distribution. This represents the largest proportion in the distribution of assertion conclusions, with a value ranging from 0 to 1, and the larger the value, the more obvious the dominant conclusion. Represents boundary similarity, and its value is taken as a set of confidence boundary description summaries for each assertion record under the same aggregation key. Calculate pairwise similarity and aggregate the results; higher similarity indicates more consistent comparison conditions. This represents the effective weight variance, calculated by taking the variance of the set of effective weights for assertion records under the same aggregation key. A larger variance indicates greater differences in evidence contribution and a higher likelihood of false consistency. If the statistical results of the number of legal witnesses and the statistical results of the number of heterogeneous witnesses satisfy the assertion dictionary threshold and... If the consistency threshold is reached, the assertion identifier, target condition label, and observation semantic slot identifier are written into the stable region index, and a stable region version number is generated. The stable region version number is used to solidify the ledger point at which the assertion identifier enters a stable state and supports the traceability of adjudicable health conclusions. Adjudicable health conclusions aggregate stable region index entries using the device object identifier as the index, outputting the set of assertion identifiers entering the stable region, the covered set of target condition labels, the covered set of observation semantic slot identifiers, the stable region version number set, and a credibility hierarchy. The credibility hierarchy is generated jointly by the weighted statistical results and the conclusion consistency score, ensuring that the health conclusion is both adjudicable and interpretable. If the statutory witness count statistics and the heterogeneous witness count statistics meet the threshold but... If the consistency threshold is not met, a disputed assertion identifier is generated and written to the dispute queue. The disputed assertion identifier is simultaneously associated with the evidence fragment fingerprint summary set and the confidence boundary description summary set of the conflict assertion record set. This allows subsequent assertion auction books to increase the weight of historical disputes and strengthen the demand for heterogeneous witnesses to drive conflict resolution. If the statistical results of the statutory witness count or the statistical results of the heterogeneous witness count do not meet the threshold, the missing assertion ticket is updated and written back to the assertion auction book. The missing assertion ticket carries at least the statutory witness count gap, the heterogeneous witness count gap, the missing valid window, and the latest maturity risk weight. This allows subsequent rolling windows to continue to receive sealed bids around the real gap and generate assertion work order identifiers, thereby maintaining the collaborative operation and maintenance closed loop and the continuity of status expression of the inspection robot under the condition of emergency priority insertion.

[0063] This application also provides a collaborative operation and maintenance device for urban rail transit substation inspection robots, referring to... Figure 2 , Figure 2 This is a schematic diagram of a collaborative operation and maintenance device for an urban rail transit substation inspection robot, provided in an embodiment of this application. The device is a server, comprising an acquisition module 21 and a processing module 22. The acquisition module 21 acquires a set of equipment objects from the urban rail transit substation and generates an equipment object identifier for each equipment object in the set. The processing module 22 constructs an assertion dictionary based on the equipment object identifiers and sets a statutory witness count and a heterogeneous witness count for each assertion to be verified in the assertion dictionary. It also generates a witness identifier for the inspection robot corresponding to the urban rail transit substation. The processing module 22 further generates an assertion auction book, receives sealed bids corresponding to the witness identifiers, and executes a transaction decision based on expiration risk, historical dispute level, and witness count gap to generate an assertion work order identifier. The processing module 22 also determines the witness identifier based on the witness identifier. The witness identifier acquires evidence fragments to generate assertion records, and appends these assertion records to the assertion event chain. It also updates the stable zone index based on the statutory witness count and the heterogeneous witness count, and generates disputed assertion identifiers. The processing module 22 is further used to generate emergency fork identifiers and create an emergency fork event chain when an emergency event is triggered. It converts incomplete assertion work order identifiers into missing assertion tickets and writes them back to the assertion auction book, while simultaneously generating lightweight witness assertion records and writing them to the emergency fork event chain. After the emergency event ends, the processing module 22 also maps the lightweight witness assertion records in the emergency fork event chain to the assertion event chain. After performing a recount of the statutory witness count and a recount of the heterogeneous witness count, it updates the stable zone index for assertion identifiers that meet preset conditions and generates adjudicable health conclusions. It also outputs missing assertion tickets and disputed assertion identifiers to achieve collaborative operation and maintenance of the inspection robot under emergency priority insertion conditions.

[0064] This application also provides an electronic device, with reference to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: at least one processor 31, at least one network interface 34, a user interface 33, a memory 35, and at least one communication bus 32.

[0065] The communication bus 32 is used to enable communication between these components.

[0066] The user interface 33 may include a display screen and a camera. Optionally, the user interface 33 may also include a standard wired interface and a wireless interface.

[0067] The network interface 34 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0068] The processor 31 may include one or more processing cores. The processor 31 connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in the memory 35, and calling data stored in the memory 35 to perform various server functions and process data. Optionally, the processor 31 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 31 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 31 and may be implemented as a separate chip.

[0069] The memory 35 may include random access memory (RAM) or read-only memory. Optionally, the memory 35 may include a non-transitory computer-readable storage medium. The memory 35 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 35 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 35 may also be at least one storage device located remotely from the aforementioned processor 31. Figure 3 As shown, the memory 35, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a collaborative operation and maintenance method of an urban rail transit substation inspection robot.

[0070] exist Figure 3In the electronic device shown, the user interface 33 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 31 can be used to call the application stored in the memory 35 for a collaborative operation and maintenance method of an urban rail transit substation inspection robot. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0071] This application also provides a non-transitory computer-readable storage medium storing instructions. When executed by one or more processors, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

[0072] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A collaborative operation and maintenance method for urban rail transit substation inspection robots, characterized in that, The method includes: Obtain the set of equipment objects for urban rail transit substations, and generate an equipment object identifier for each equipment object in the set of equipment objects; An assertion dictionary is constructed based on the device object identifier, and a statutory witness number and a heterogeneous witness number are set for each assertion to be verified in the assertion dictionary. At the same time, a witness identifier is generated for the inspection robot corresponding to the urban rail transit substation. Generate an assertion auction book, receive sealed bids corresponding to the witness identifiers, and execute transaction decisions based on expiration risk, historical dispute level, and witness count gap to generate assertion work order identifiers; Evidence fragments are obtained based on the witness identifier corresponding to the assertion work order identifier to generate an assertion record. At the same time, the assertion record is appended to the assertion event chain, and the stable zone index is updated based on the statutory witness count and the heterogeneous witness count, and a dispute assertion identifier is generated. When an emergency event is triggered, an emergency fork identifier is generated and an emergency fork event chain is created. Incomplete assertion ticket identifiers are converted into missing assertion tickets and written back to the assertion auction book. At the same time, lightweight witness assertion records are generated and written to the emergency fork event chain. After the emergency event ends, the lightweight witness assertion records in the emergency fork event chain are mapped to the assertion event chain. After performing the statutory witness count recount and the heterogeneous witness count recount, the stable region index is updated for the assertion identifiers that meet the preset conditions and an adjudicable health conclusion is generated. At the same time, the missing assertion ticket and the disputed assertion identifier are output to realize the collaborative operation and maintenance of the inspection robot under the emergency priority insertion condition.

2. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 1, characterized in that, The step of obtaining the set of equipment objects for urban rail transit substations and generating an equipment object identifier for each equipment object in the set specifically includes: Read the static asset data and dynamic operation data of the urban rail transit substation, and generate a candidate set of equipment objects based on the static asset data and the dynamic operation data. Each candidate equipment object in the candidate set is bound to a field of equipment name, a field of equipment installation location, a field of belonging to the bay, a field of belonging to the primary system topology, and a field of associative point table. The candidate set of device objects is subjected to deduplication and split correction processing. Based on the device installation location field and the primary system topology field, a topology consistency check is performed to obtain the target device object set. For each device object in the target device object set, a device object identifier is generated. The device object identifier is formed by combining a site identifier, a primary system topology path summary, a segment identifier, a device category identifier, and a device serial number summary.

3. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 1, characterized in that, The process of constructing an assertion dictionary based on the device object identifier, setting a statutory witness count and a heterogeneous witness count for each assertion to be verified in the assertion dictionary, and generating a witness identifier for the inspection robot corresponding to the urban rail transit substation, specifically includes: Based on the device object identifier, read the device category identifier and the primary system topology path summary, and match the corresponding assertion template set to generate a set of assertions to be verified. Each assertion to be verified in the set of assertions to be verified contains an assertion identifier, a set of assertion applicable working condition labels and a set of observation semantic slots. Based on the risk level and equipment criticality of the set of assertions to be verified, a statutory witness number is set for each assertion to be verified, and a heterogeneous witness number is set for each assertion to be verified based on the differences in motion patterns involved in the set of observed semantic slots. A witness identifier is generated for the inspection robot. The witness identifier is formed by combining the robot type identifier, motion pattern identifier, sensor capability set summary, and security domain level identifier. Write the set of assertions to be verified, the number of legal witnesses, the number of heterogeneous witnesses, and the witness identifier into the assertion dictionary.

4. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 1, characterized in that, The process of generating the assertion auction book involves receiving sealed bids corresponding to the witness identifiers and making transaction decisions based on factors such as expiration risk, historical dispute level, and witness count gap, in order to generate an assertion work order identifier. Specifically, this includes: Under the constraints of the assertion dictionary and the device object identifier, the assertion auction book is constructed; The system receives a sealed bid submitted by the witness identifier. The sealed bid includes an assertion identifier, a device object identifier, a target observation semantic slot identifier, a reachable security domain set matching result, an expected arrival window, an expected evidence quality level, and a heterogeneous witness type marker. Based on the reachability mapping relationship of the device object identifier, the system performs security domain feasibility verification and operating condition matching verification on the sealed bid. A priority key is generated based on the expiration risk, the historical dispute level, and the witness count gap. Based on the priority key, a bid combination that meets the statutory witness count and the heterogeneous witness count requirements is selected from the verified sealed bids under the same assertion identifier. The bid combination is solidified into the assertion work order identifier.

5. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 4, characterized in that, The step of obtaining evidence fragments based on the witness identifier corresponding to the assertion work order identifier to generate an assertion record, appending the assertion record to the assertion event chain, updating the stable zone index based on the statutory witness count and the heterogeneous witness count, and generating a disputed assertion identifier specifically includes: Under the constraints of the assertion work order identifier, an executable constraint set is generated by parsing. Based on the device object identifier, the spatial map anchor point set is located and near-field positioning verification is performed. After the working condition consistency gating condition of the target working condition label is met, the slot acquisition configuration is called according to the target observation semantic slot identifier to obtain the evidence fragment. An evidence fragment fingerprint digest is generated based on the evidence fragment, and an assertion conclusion and confidence boundary description are generated based on the assertion dictionary. The assertion identifier, the target working condition label, the target observation semantic slot identifier, the evidence fragment fingerprint digest, the assertion conclusion, the confidence boundary description, and the witness identifier are encapsulated into an assertion record and appended to the assertion event chain. Aggregate statistics in the assertion event chain to obtain the number of legal witnesses and the number of heterogeneous witnesses. When the number of legal witnesses and the number of heterogeneous witnesses are satisfied and the assertion conclusions are consistent, update the stable region index. When there is a conflict in the assertion conclusions, generate the disputed assertion identifier.

6. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 4, characterized in that, The process of generating an emergency fork identifier and creating an emergency fork event chain upon triggering an emergency event, converting incomplete assertion ticket identifiers into missing assertion tickets and writing them back to the assertion auction book, and simultaneously generating lightweight witness assertion records and writing them to the emergency fork event chain, specifically includes: When the emergency trigger criterion is met, the emergency fork identifier is generated, and an emergency fork event chain with the same structure as the assertion event chain is created under the operation and maintenance status ledger identifier. For assertion work orders that are in an incomplete state, freeze the work order and convert it into a missing assertion ticket; The missing assertion notes are written back to the assertion auction book, and the witness count gap and maturity risk weight are updated to drive subsequent assertion scheduling. During emergency execution, the lightweight witness assertion record is generated based on the emergency fork identifier and the target observation semantic slot identifier, and the lightweight witness assertion record is appended to the emergency fork event chain, and the missing status of the missing assertion ticket is updated synchronously.

7. The collaborative operation and maintenance method for urban rail transit substation inspection robots according to claim 1, characterized in that, The process involves mapping lightweight witness assertion records from the emergency fork event chain to the assertion event chain after the emergency event ends. Following recounting of statutory and heterogeneous witness counts, the stable region index is updated for assertion identifiers meeting preset conditions, and a definable health conclusion is generated. Simultaneously, the missing assertion ticket and the disputed assertion identifier are output to achieve collaborative operation and maintenance of the inspection robot under emergency priority insertion conditions. Specifically, this includes: After the emergency event ends, a fork closure action is performed based on the emergency fork identifier, and a fork closure credential is generated. A mapping preparation verification is performed on the lightweight witness assertion record in the emergency fork event chain. The lightweight witness assertion records prepared for verification through mapping are appended to the assertion event chain and a mapping log is generated. Based on the assertion event chain, the assertion identifier, target condition label and observation semantic slot identifier are re-statistically analyzed to calculate the statistical results of the statutory witness count and the heterogeneous witness count, and the satisfaction determination is performed based on the statutory witness count and the heterogeneous witness count in the assertion dictionary. When the statistical results satisfy the requirement that the number of statutory witnesses is equal to the number of heterogeneous witnesses and the assertion conclusion is consistent, the stable zone index is updated and the adjudicable health conclusion is generated. When the assertion conclusions conflict, the disputed assertion identifier is generated. When there are insufficient witnesses, the missing assertion ticket is updated and written back to the assertion auction book.

8. A collaborative operation and maintenance device for urban rail transit substation inspection robots, characterized in that, The device is used to execute the collaborative operation and maintenance method of urban rail transit substation inspection robots as described in any one of claims 1 to 7, the device comprising an acquisition module and a processing module, wherein... The acquisition module is used to acquire a set of equipment objects of urban rail transit substations and generate an equipment object identifier for each equipment object in the set of equipment objects. The processing module is used to construct an assertion dictionary based on the device object identifier, and to set a statutory witness number and a heterogeneous witness number for each assertion to be verified in the assertion dictionary, while generating a witness identifier for the inspection robot corresponding to the urban rail transit substation. The processing module is also used to generate an assertion auction book, receive sealed bids corresponding to the witness identifiers, and make transaction decisions based on expiration risk, historical dispute level and witness count gap, so as to generate assertion work order identifiers. The processing module is also used to obtain evidence fragments based on the witness identifier corresponding to the assertion work order identifier to generate an assertion record, and simultaneously append the assertion record to the assertion event chain, and update the stable zone index and generate a dispute assertion identifier based on the statutory witness count and the heterogeneous witness count. The processing module is also used to generate an emergency fork identifier when an emergency event is triggered, and to create an emergency fork event chain. It converts incomplete assertion work order identifiers into missing assertion tickets and writes them back to the assertion auction book. At the same time, it generates lightweight witness assertion records and writes them into the emergency fork event chain. The processing module is also used to map the lightweight witness assertion records in the emergency fork event chain to the assertion event chain after the emergency event ends, and after performing the statutory witness count recount and heterogeneous witness count recount, update the stable region index for assertion identifiers that meet preset conditions and generate adjudicable health conclusions, and output the missing assertion ticket and the disputed assertion identifier, so as to realize the collaborative operation and maintenance of the inspection robot under the emergency priority insertion condition.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1 to 7.

Images