Expressway electromechanical equipment operation and maintenance record tamper-proofing method based on block chain

Abstract

The invention relates to the technical field of block chains, in particular to an expressway electromechanical equipment operation and maintenance record tamper-proofing method based on a block chain, and provides the following scheme: shadow log bits are pre-generated for all equipment according to time granularity in a block main chain, and the commitment of the equipment is solidified; the actual operation and maintenance behavior of each responsibility subject generates an abstract through a corresponding operation and maintenance sub-chain and maps the abstract to a target shadow log bit in an activation recording mode; the device side operation state generates a state abstract according to a time window and is anchored to the main chain. And establishing an index relationship between the state abstract in the time window and the shadow log bit activation condition, performing negative space comparison on the state abstract and the shadow log bit activation condition through rules such as field mask, bit sequence comparison and coverage judgment, identifying the window of which the equipment state is changed but the corresponding log bit is not activated, forming a negative space abnormal record, and writing the negative space abnormal record into a main chain. Structured constraint and record integrity verification of multi-responsibility subject operation and maintenance behaviors are realized, and reliability and traceability of electromechanical equipment operation and maintenance records are improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based method for preventing tampering of maintenance records of highway electromechanical equipment. Background Technology

[0002] During long-term operation, highway electromechanical equipment requires inspection, maintenance, and troubleshooting by multiple stakeholders. Related maintenance records are typically stored through independent recording platforms or internal databases of each unit. In existing technologies, significant differences exist in the recording structure, recording methods, and time stamps among different stakeholders, making it difficult to establish a complete chain of records for the same equipment within the same time period, thus hindering subsequent traceability. Furthermore, existing maintenance records often focus primarily on outcome-based information, insufficiently expressing temporal relationships and behavioral continuity, making it difficult to verify the completeness of the records through objective data.

[0003] Furthermore, existing maintenance records largely rely on self-upload by the responsible parties, lacking structured methods to identify unrecorded behaviors. Once certain maintenance actions are not recorded, subsequent investigations and responsibility determination often fail to accurately pinpoint the missing areas. In cross-unit collaboration scenarios, the lack of an effective correspondence between equipment operating status and maintenance records makes it difficult for external reviewers to determine whether certain anomalies correspond to existing maintenance actions, compromising the reliability and consistency of records. As electromechanical systems expand in scale, the number of devices and the volume of operational data grow rapidly, making traditional manual comparison methods inefficient and limiting their effectiveness in handling large-scale, multi-party maintenance processes.

[0004] To address the above issues, this application proposes a blockchain-based method for preventing tampering of highway electromechanical equipment maintenance records. Summary of the Invention

[0005] The technical problem this application aims to solve is to address the shortcomings of existing technologies by providing a blockchain-based method for preventing tampering of maintenance records for highway electromechanical equipment. In the main blockchain, shadow log bits are pre-generated for each device at a time granularity and their commitments are solidified. The actual maintenance behavior of each responsible entity generates a summary through the corresponding maintenance sub-chain and maps it to the target shadow log bit using an activation record method. The device's operating status generates a status summary according to a time window and anchors it to the main chain. Within a preset period, an index relationship is established between the status summary within the time window and the activation status of the shadow log bits. Negative space comparison is performed between the two using rules such as field masking, bit order comparison, and coverage determination to identify windows where the device status has changed but the corresponding log bit has not been activated, forming negative space anomaly records and writing them to the main chain.

[0006] To achieve the above objectives, this application provides the following technical solution: A blockchain-based method for preventing tampering of highway electromechanical equipment maintenance records is applied to a maintenance record system with multiple responsible parties. The maintenance record system is configured with a main blockchain, which includes multiple maintenance sub-chains. Each responsible party corresponds one-to-one with a maintenance sub-chain. The method includes: Based on the equipment, responsible party, and time granularity, at least one shadow log bit is pre-generated for each equipment at each time granularity, and the shadow log bit and the commitment corresponding to the shadow log bit are written into the main blockchain. When an operational activity is detected, the operational record is written into the corresponding responsible entity's operational subchain, and operational summary data is generated. Determine the target shadow log bit corresponding to the operation and maintenance behavior, and modify the state of the target shadow log bit in the main blockchain; Within a preset time period, based on the shadow log bit status information in the main blockchain and the corresponding operating status data of the device, a negative space comparison is performed on each device in each time window. If a negative space situation exists, a negative space anomaly record is generated and written into the main blockchain.

[0007] The process of pre-generating at least one shadow log bit for each device at each time granularity includes: Each device's identifier, responsible entity identifier, and time granularity are combined and encoded, and a time window identifier corresponding to the time window is generated based on the combined encoding. At least one shadow log bit identifier is constructed based on the time window identifier, wherein the shadow log bit identifier includes a field for distinguishing the device, the responsible party, and the time window; Calculate a first hash value for each shadow log bit identifier, and construct commitment data based on the first hash value; The shadow log bit identifier and the corresponding commitment data are combined to form a shadow log bit commitment pair. The consensus node of the main blockchain packages the shadow log bit commitment pair and writes it into the block to generate an irreversible pre-commitment storage block. The shadow log bit is committed to not being modified, replaced, or deleted after being written to the main chain of blocks, and state updates are only allowed by adding an activation record corresponding to the shadow log bit.

[0008] Modifying the state of the target shadow log bit in the main blockchain includes: Calculate the second hash value based on the maintenance summary data; Construct an activation record that includes a shadow log bit identifier, an activation flag field, and a second hash value; The activation record is encapsulated using the transaction packaging logic of the main blockchain to obtain a transaction structure. The transaction packaging logic includes serializing the activation record, assigning a transaction identifier to the serialization result, writing a timestamp field into the transaction structure, performing signature processing on the transaction structure, and appending the signature information to the transaction signature field of the transaction structure. The transaction structure is broadcast to the consensus network of the main blockchain, and the consensus network determines whether to write the activation record into a new block based on a preset consensus algorithm. If not written to a new block, the activation record is appended in an overwriteable manner, ensuring a chained association with the previously written shadow log bit; If a new block is written, an offset address within the block is allocated for the activation record in the data area of ​​the new block, and the Merkle root hash containing the activation record is written in the block header; The activation flag field in the activation record is used to record the status change of the shadow log bit. The activation process of the shadow log bit allows multiple activation records to be associated with the same shadow log bit, so as to represent one or more maintenance actions performed by the responsible party within the same time window.

[0009] The collection of the equipment operating status data includes: The monitoring terminals deployed on the side of the electromechanical equipment of the highway periodically collect the operating parameters of the equipment, wherein the operating parameters include data from at least one internal sensor of the equipment; The operating parameters are divided into corresponding time windows according to the time granularity; Calculate the third hash value for the operating parameters within each time window to form a device status summary; The device status digest is written into the main blockchain, and the root hash of the device status chain is recorded through the main blockchain.

[0010] The negative spatial comparison of each device in each time window includes: Based on the set of shadow log bit identifiers, the set of shadow log bit activation states, and the set of device status summaries recorded in the main blockchain, a time window index table is constructed for each device. The time window index table is used to map the device status summary to the set of shadow log bits one by one within a preset time window. The device status summary is located according to the time window index table, and the internal fields of the device status summary are read. The internal fields include the operating parameter fields collected by the monitoring terminal and processed by hashing. At least one summary field for characterizing the internal status change of the device is extracted based on the preset field masking rules. Read the shadow log bit identifiers bound to the time window index table, construct a shadow log bit set, and according to each shadow log bit identifier in the shadow log bit set, retrieve the corresponding activation record in the main chain of the block, extract the activation flag field therein, and generate a shadow log bit activation status vector. The comparison operation is performed based on the summary field and the shadow log bit activation state vector, combined with a negative space judgment rule set that includes at least threshold judgment rules, bit order comparison rules and field coverage rules.

[0011] The comparison operation, which combines a negative space judgment rule set including at least threshold judgment rules, positional comparison rules, and field coverage rules, includes: The threshold determination rule is used to determine whether the summary field meets the preset change conditions within the current time window without accessing the original operating parameters. If it does not meet the conditions, an uncovered flag is written to the comparison result. The bit alignment rule is used to establish a one-to-one correspondence between the shadow log bit set and the summary field. If there is no one-to-one correspondence, an overwritten flag is written to the alignment result. The field overwrite rule is used to write an overwritten flag to the comparison result when all bits of the shadow log bit activation state vector are inactive. When the comparison operation outputs an uncovered flag in the time window, a negative space anomaly record is constructed. The negative space anomaly record includes at least a device identifier field, a time window identifier field, a shadow log bit identifier set field, a device status summary reference field, and an uncovered flag field.

[0012] The main blockchain adopts a consortium blockchain structure, with multiple operation and maintenance responsible entities, equipment manufacturers, and regulatory agencies participating as consensus nodes. The consensus algorithm of the main blockchain includes at least one of the Byzantine fault tolerance algorithm, the practical Byzantine fault tolerance algorithm, and the weighted voting consensus algorithm. The main blockchain provides a unified record index and timestamp source for each operating sub-chain.

[0013] The operation and maintenance summary data includes at least one structured field generated internally by the operation and maintenance sub-chain; The structured fields include at least one of the following: operation and maintenance event type, operation instruction code, device component code, operation and maintenance tool identifier, execution terminal identifier, operator identifier, and signature field; The second hash value is written into the activation record containing the target shadow log bit identifier, which is used to establish a many-to-one reference relationship between the operation and maintenance summary data and the same shadow log bit within the main chain of the block.

[0014] The time granularity of the time window is a configurable parameter, which can be adjusted according to equipment type, inspection frequency, and maintenance standards. Adjustments to the time window include increasing the number of time windows, shortening the length of the time window, and reassigning the numbering of the generated time windows. The adjusted time window configuration is updated on-chain via the main blockchain.

[0015] After the negative space anomaly record is written into the main blockchain, an anomaly index table is constructed based on the negative space anomaly record. The anomaly index table includes device identifier index, responsible entity index, time window index, and shadow log bit index fields. The anomaly index table is verified by the consensus network based on a preset consensus algorithm, and the verified anomaly index table is appended to the main blockchain.

[0016] Compared with the prior art, the beneficial effects of this application are: This application pre-generates shadow log bits in the main blockchain and solidifies them in the form of commitments, providing a verifiable record space for operational activities. The responsible party cannot alter the record structure through additions or deletions. Combined with on-chain anchoring of device-side state summaries, it can simultaneously obtain two-dimensional information—whether the device status has changed and whether the operational record exists—within a unified time window, thus enabling structured identification of missing records. Through a negative space comparison mechanism, it can directly locate time periods where the device status has changed but the corresponding slots have not been activated, improving the accuracy of missing record identification. Both activated records and state summaries are written to the blockchain using hashing, ensuring that operational activities and device status are immutable. Attached Figure Description

[0017] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 An exemplary application scenario diagram provided for an embodiment of this application; Figure 2 This is a flowchart illustrating a blockchain-based method for preventing tampering of highway electromechanical equipment maintenance records, as provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions in the embodiments of this application 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.

[0019] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] In a typical highway electromechanical system operation and maintenance scenario, electromechanical equipment is widely distributed, has multiple levels, and involves complex and overlapping responsibilities. The same road section often involves multiple parties, including the owner, the road company's operation and maintenance unit, the electromechanical system integrator, the equipment manufacturer, the supervisor, and the higher-level regulatory authorities.

[0021] Those skilled in the art will understand that in routine inspections, emergency repairs, remote parameter adjustments, and other operation and maintenance activities, all parties generally use a central database, operation and maintenance work order system, or their own log servers to record the operation process. Even though some projects have tried to introduce blockchain technology to record operation and maintenance on the chain, discrepancies between the records and the actual situation still frequently occur during actual accident reviews.

[0022] On the one hand, traditional operation and maintenance records mostly rely on post-event entry and centralized supplementary entry. When equipment is offline for a long time, the on-site environment is harsh, or the operation and maintenance pressure is high, the responsible party can selectively record, delay recording, or even not record certain operation and maintenance behaviors that are not conducive to their own assessment. On the other hand, existing blockchain-based solutions focus on the immutability of written records, but lack the ability to characterize records that should exist but have been deliberately omitted or never written. This makes it difficult to provide technical basis for determining which responsible party failed to perform its due operations or which responsible party may have concealed its operations, based on the ledger structure itself, when the device status has changed significantly at a certain time.

[0023] This problem is particularly prominent in highway electromechanical operation and maintenance systems involving multiple responsible parties: When any of the tunnel's ventilation, lighting, gantry toll collection, or monitoring systems malfunctions, and a subsequent traffic accident or major service quality incident occurs, the participating parties often provide logs or on-chain records from different sources as corroboration. Even if these records are immutable within their respective systems, the lack of unified constraints on the response space of maintenance responsibilities over the timeline allows each party to rewrite the chain of facts by underreporting, omitting, or not recording anything. Such tampering through omissions is virtually impossible to quantify and identify with current technology. Furthermore, due to the limited network connectivity and intermittent reporting of numerous electromechanical devices in the highway environment, relying solely on the central server's real-time timestamps is insufficient as a mutually agreed-upon time benchmark, making the construction of a joint maintenance timeline across entities and systems extremely difficult.

[0024] Building upon the aforementioned practices, the conceptual logic of this application is not to recreate a simple on-chain operation and maintenance system. Instead, it introduces a shadow log bit bound to a time window, device object, and responsible entity. This pre-determines on the chain whether the responsible entity has performed operation and maintenance activities within a specific time window as a set of potential operation and maintenance record slots. Leveraging the irreversible and unoverwriteable characteristics of blockchain, the pre-commitment of the shadow log bit, its subsequent activation, and the device state change summary are all anchored within a unified chain structure. In this architecture, each device, each responsible entity, and each time window corresponds to one or more activatable shadow log bits. Once the responsible entity completes the actual operation and maintenance within the corresponding time window, it must generate an operation and maintenance summary through the operation and maintenance sub-chain and bind the hash of this summary to the target shadow log bit on the main chain as an activation record. Conversely, if the device state has changed significantly within a time window, but the associated shadow log bit remains inactive, a negative space that can be recognized by the algorithm is naturally formed on the chain. This allows information that should have been recorded but was not to be derived from the ledger structure itself without relying on a single central referee.

[0025] It should be noted that the shadow log bit and negative space comparison mechanism proposed in this application does not depend on the organizational structure of a specific operating entity, nor is it limited to a specific model of toll controller, information board controller or video surveillance front-end equipment. Instead, it is aimed at a general scenario with multi-entity collaborative operation and maintenance responsibility division, distributed deployment along highways, quantifiable collection of equipment status and structured summaries of operation and maintenance behavior in sub-chains.

[0026] In some specific implementations, the main blockchain can be operated by multiple entities as consortium blockchain nodes. Each responsible entity maintains an operation and maintenance sub-chain coupled with its own business system. Through cross-chain mapping, the operation and maintenance summary hash in the sub-chain is associated with the shadow log bit identifier on the main chain. At the same time, status acquisition terminals are deployed on the device side or monitoring center side to summarize the device's operating status at a fixed time granularity and upload it to the chain, so that the device status change trajectory and the response slot of the operation and maintenance responsibility can be compared and traced in the time dimension.

[0027] The core concept of this application stems from the long-standing dilemma in the field that only what has been written can be proven, but not what has not been written. By explicitly modeling the record space that should exist on the chain and constructing a computable negative space in conjunction with device status summaries, this allows those skilled in the art to intuitively observe the absence of maintenance behavior and possible record concealment within a unified ledger structure when facing compliance reviews of high-risk electromechanical systems with multiple responsible parties. This provides a basic framework for the specific data structure design, block organization method, and comparison algorithm described in subsequent embodiments.

[0028] refer to Figure 1 , Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0029] In a typical highway electromechanical system operation and maintenance architecture, various electromechanical equipment are usually managed by different responsible entities according to contract boundaries. The equipment is numerous and widely distributed. While the operation and maintenance activities of each entity are independent, they must also be coordinated over time. This makes the simultaneous presentation of operation and maintenance activities of multiple entities on the same timeline a fundamental requirement. To adapt to this characteristic, the implementation method in this application does not directly aggregate all operation and maintenance information into a single ledger, but instead constructs a system such as... Figure 1 The diagram shows a multi-level chain structure formed by the block main chain and multiple operation and maintenance sub-chains.

[0030] like Figure 1 As shown, the main blockchain serves as the time-series anchoring layer for the entire system, corresponding to the daily operational activities of different entities. Each entity maintains an operational sub-chain that matches its permission domain, for example... Figure 1 The three sub-chains shown are maintenance sub-chains 1, 2, and 3. Each sub-chain is independently controlled by a corresponding responsible entity and is used to record structured maintenance records such as inspections, maintenance, adjustments, and handling on the equipment under that entity's jurisdiction. Different responsible entities are responsible for different types of equipment, such as... Figure 1 The illustrated devices one through five present the logical correspondence between the responsible parties and the devices, specifically including responsible party one, responsible party two, and responsible party three.

[0031] Understandable, Figure 1The architecture shown is a simplified illustration for the purpose of understanding the logical relationship of the solution in this application. In actual implementation, the number of responsible entities, sub-chain levels, device types and quantities can be flexibly expanded according to the project deployment.

[0032] Next, with reference to the accompanying drawings, the blockchain-based method for preventing tampering of highway electromechanical equipment maintenance records provided in this application will be further described. Figure 2 The method shown is applied to an operation and maintenance record system with multiple responsible parties. The operation and maintenance record system is configured with a main blockchain, which includes multiple operation and maintenance sub-chains. Each responsible party corresponds to one of the operation and maintenance sub-chains. The main blockchain adopts a consortium blockchain structure, with multiple operation and maintenance responsible parties, equipment manufacturers, and regulatory agencies participating as consensus nodes. The consensus algorithm of the main blockchain includes at least one of the Byzantine fault tolerance algorithm, the practical Byzantine fault tolerance algorithm, and the weighted voting consensus algorithm. The main blockchain provides a unified record index and timestamp source for each operating sub-chain.

[0033] The method includes: S1: Based on the device, responsible party and time granularity, pre-generate at least one shadow log bit for each device at each time granularity, and write the shadow log bit and the commitment corresponding to the shadow log bit into the main chain of the block; In this embodiment, the generation of shadow log bits is based on a combination encoding of three types of information: device identifier, responsible entity identifier, and preset time granularity. After obtaining a unique time window identifier, at least one shadow log bit identifier is constructed for each time window, and corresponding commitment data is formed based on hash calculation. The shadow log bit identifier and the commitment are jointly written into the main blockchain, so that each device has a structured, non-deletable preset record slot in each responsibility window.

[0034] S2: When an operation and maintenance activity is detected, the operation and maintenance record is written as the operation and maintenance sub-chain of the corresponding responsible entity, and operation and maintenance summary data is generated; In this embodiment, maintenance activities are generated by the responsible entity using a field terminal or maintenance platform. The generated maintenance records are first written to the maintenance sub-chain corresponding to the responsible entity. Before writing, the maintenance summary generation module set in this embodiment constructs a structured summary based on fields such as operation instruction type, tool used, component code, execution terminal information, and operator signature, and obtains the summary identifier through a hash algorithm.

[0035] It is important to note that the field content of the maintenance record is not limited to a specific format, as long as it includes key fields that logically demonstrate the identifiable nature of the maintenance activity. For example, remote reset of wind turbine drives, camera angle readjustment, and gantry equipment software version updates can all have necessary fields extracted to calculate the summary based on actual needs. In this embodiment, the structured summary stores the complete fields within the sub-chain, and its summary hash serves as a reference identifier for subsequent record activation, avoiding the exposure of too much business information on the main chain.

[0036] S3: Determine the target shadow log bit corresponding to the operation and maintenance behavior, and modify the status of the target shadow log bit in the main blockchain; In this embodiment, for each maintenance record written to the maintenance subchain, the corresponding time window can be located using the device identifier and the action time, thereby determining the target shadow log bit. Once determined, the target shadow log bit's state is updated in the main blockchain by constructing an activation record. It should be noted that the state update does not mean overwriting the original commitment; rather, it uses a new on-chain record appending method to change the target shadow log bit from inactive to active. The activation record contains the shadow log bit identifier, activation flag, and maintenance digest hash, and is written to the main blockchain after being signed and timestamped.

[0037] Furthermore, activation records can establish a many-to-one relationship with the same shadow log bit, thereby allowing multiple operational actions to occur within a single time window. For example, after extreme weather causes a large number of devices to issue alarms simultaneously, the responsible party may perform multiple diagnostic and restart operations on the same device within the same time window. This embodiment does not impose an upper limit constraint on the data structure.

[0038] S4: Within a preset time period, based on the shadow log bit status information in the main blockchain and the corresponding operating status data of the device, perform negative space comparison for each device in each time window. If a negative space situation exists, generate a negative space anomaly record and write the negative space anomaly record into the main blockchain. In this embodiment, negative spatial alignment uses two types of on-chain data within the same time window as input: a device status summary and the activation status of shadow log bits. The device status summary is calculated by the device or monitoring center based on collected operating parameters. These operating parameters can be determined according to the actual deployment; this embodiment does not impose restrictions on their source, as long as they can identify whether the device status has changed significantly within the time window. The activation status of shadow log bits is obtained by traversing all activation records of shadow log bits within the target time window.

[0039] Furthermore, this embodiment employs a negative space determination rule set to perform comparison operations, including threshold determination, bit order comparison, and coverage determination. For example, if the device status summary exhibits defined change characteristics within a certain time window, such as fan current fluctuations, sudden changes in camera viewpoints, or toll terminal resets, then it is determined that a status change exists within that time window; if simultaneously all shadow log bits of the corresponding responsible entity are not activated, then a negative space is formed in the chain structure. After identifying the negative space, this embodiment constructs a negative space anomaly record and writes it into the main blockchain. The anomaly record includes the device identifier, time window identifier, shadow log bit set, and status summary reference, among other things.

[0040] Furthermore, negative space records are written into the main chain as independent data units, serving as directly referenced data structures in subsequent equipment liability determination, accident tracing, or quality inspection. Their generation process does not rely on any central scheduling entity but is entirely derived from existing on-chain data, thus ensuring that the negative space phenomenon exists as an objective on-chain relationship and is not obscured by unilateral record omissions or delays.

[0041] Before delving into the specific technical details of the steps, the embodiments of this application need to be emphasized again.

[0042] In actual engineering deployments, electromechanical equipment along the route is mostly distributed and managed separately by different responsible parties according to contracts or operational boundaries. The operational status of this equipment and human intervention activities are typically generated on a minute or second-by-second basis, and the chain of events identified by each responsible party is inconsistent. Due to this inherent condition, regardless of the storage architecture used, a structural discrepancy inevitably arises between the continuous changes in equipment status and the discrete distribution of responsible behavior records. In traditional operational record-keeping methods, this discrepancy often manifests as the inability to establish a strict temporal mapping between the status trajectories within the same time period and the behavioral records of each party. Once it is necessary to trace external events or equipment anomalies, problems such as broken chains or missing context easily arise.

[0043] Furthermore, from the perspective of record-keeping organizations, there is no inherently unified timeline constraint among different responsible parties. Any party can adjust the position of their actions by delaying entry or selectively recording, making subsequent audits unable to rely solely on already written content to determine actions that should have occurred but did not. In fact, this structural blind spot caused by omissions is difficult to verify in a centralized database, and even more difficult to eliminate through manual comparison in a multi-party architecture. Long-term practice shows that although each party can guarantee that its own records are unalterable, it cannot guarantee that the recorded records represent a complete set of actions. This is precisely the area most prone to dispute in collaborative accountability.

[0044] Based on the aforementioned engineering characteristics, this embodiment does not focus on how to constrain the way each subject fills in records when designing the overall logic. Instead, it adopts a method that is closer to the structural characteristics of the event to model the record space itself.

[0045] In this embodiment, potential record slots are first pre-constructed in the main blockchain, corresponding one-to-one with devices, responsible entities, and time windows. This allows the theoretically existing record space at each point in time to be solidified as an on-chain entity. Unlike directly recording behavior, the core purpose of this structure is to make the occurrence of behavior a computable on-chain feature without relying on any additional censorship logic. These potential slots remain static until activated by actual operational behavior. Once a real on-site operation occurs, its structured summary is mapped to the corresponding slot in an activated manner, thereby constructing on-chain evidence of the behavior's existence.

[0046] Meanwhile, this embodiment also fixes the device's operating status in summary form on the same timeline, making the device's operating status and the corresponding slot's activation status within a certain time window two comparable dimensions. Since the device status originates from an independent data acquisition path, its temporal distribution does not depend on any responsible party, thus serving as an important reference point for determining whether responsible actions are lacking. By simultaneously maintaining device status trajectories and potential behavior slot activation status on the main blockchain, this embodiment establishes a self-consistent data relationship: If the device status undergoes a identifiable change within a certain time window, but the corresponding potential recording slot remains unactivated, then that window naturally manifests as a structured void, which can be identified and recorded as an anomaly in the chain structure.

[0047] It is important to emphasize that this embodiment does not limit the structure to a fixed data format, nor does it require all entities to generate operation and maintenance logs in a uniform manner. As long as each entity can generate a basic structured summary in its own operation and maintenance sub-chain, and the device side can report status information within a certain time resolution range, the structure of this embodiment can be adapted. This approach ensures that what is presented on the chain is not the behavioral perspective of a single entity, but a logical structure naturally formed based on the correspondence between device status and potential slots. This allows the existence or non-existence of behavior within each time window to have a way of expression in the chain structure that is independent of the entity's intention, facilitating the subsequent processing of negative space identification and abnormal record generation in this embodiment.

[0048] Next, the technical details of the shadow log bit in this application will be further introduced.

[0049] In one example, the step of pre-generating at least one shadow log bit for each device at each time granularity includes: S1.1: Combine and encode the identifier, responsible entity identifier, and time granularity of each device, and generate a time window identifier for the corresponding time window based on the combined code; Specifically, for highway electromechanical equipment that needs to be included in the operation and maintenance records, each piece of equipment is pre-assigned a unique equipment identifier, and a mapping relationship between the equipment and the responsible entity is formed on the operation and maintenance management side. The time granularity is determined as a fixed discrete unit based on the operation and maintenance management specifications, the equipment importance level, and the frequency of status changes. In order to establish a reversible correspondence between the subsequent shadow log bits and the time axis, this embodiment combines and encodes the equipment identifier, the responsible entity identifier, and the time slice sequence number under the time granularity to generate a structured time window identifier, so that each time window has a unique and resolvable number in the entire architecture.

[0050] In this embodiment, the combined encoding is organized using a combination of field concatenation and fixed-length encoding: For example, the equipment identifier uses a fixed-length alphanumeric code, the responsible entity identifier uses a numerical number, and the time window sequence number is obtained by accumulating backward from the starting base time. The three are concatenated in a preset order, and separators are inserted between the fields or fixed-length padding is used to avoid ambiguity.

[0051] Furthermore, to reduce the impact of time asynchrony on encoding, this embodiment can select a unified time source, such as the coordinated time synchronized by a time synchronization server. The original time is first converted into the offset from the reference time, and then an integer division operation is performed according to the time granularity to obtain the time window index. In this way, even if the device's local clock has an offset, it can still be merged into the same window as long as it is within a certain threshold range.

[0052] S1.2: Construct at least one shadow log bit identifier based on the time window identifier, wherein the shadow log bit identifier includes a field for distinguishing the device, the responsible party, and the time window; Specifically, once the time window identifier is determined, it cannot directly reflect the number of potential maintenance behaviors within that window. Therefore, this embodiment introduces the concept of a shadow log bit within each time window to abstract the number of available maintenance behaviors into one or more slots.

[0053] The shadow log bit identifier inherits all the information from the time window identifier and adds a slot number field or category field to it, so that multiple shadow log bits within the same time window can be distinguished one by one. For example, the first potential behavior in the same window can be assigned slot number 00, the second can be assigned 01, and so on.

[0054] In this embodiment, the shadow log bit identifier field structure typically includes a project or road segment identifier field, an equipment identifier field, a responsible entity field, a time window field, and a slot number field. These fields are organized using a fixed-length layout or a TLV layout to ensure both easy compression and parsing during on-chain storage. The specific value of the slot number can be estimated based on experience, estimating the maximum number of maintenance operations a certain type of equipment might experience within a time window, and reserving a corresponding number of slots. For example, for equipment with frequent alarms but few operations, 2-4 shadow log bits can be preset for each window, while for toll control equipment with high event density, more slots can be preset. If the actual number of maintenance operations exceeds the preset number of slots, this embodiment can trigger expansion logic to add a new set of expanded slots for the window and generate a new shadow log bit identifier. Simultaneously, the expansion information is associated with the original time window through on-chain marking.

[0055] S1.3: Calculate the first hash value for each shadow log bit identifier, and construct commitment data based on the first hash value; Specifically, as a structured identifier, the shadow log bit identifier, if directly and publicly displayed in plaintext on the blockchain for an extended period, could easily expose sensitive information such as device distribution and responsibility allocation in multi-entity collaborative scenarios. Furthermore, it would hinder adjustments to the field structure during subsequent version upgrades. Therefore, this embodiment introduces hash operations to compress and de-identify the shadow log bit identifier. Specifically, a first hash value is calculated for each shadow log bit identifier, serving as a mathematical commitment to its existence. The first hash value is designed to be collision-resistant and irreversible, preventing external observers from deducing the plaintext identifier from the hash value. However, when verifying the existence of a shadow log bit on the blockchain, it is only necessary to recalculate the hash of the identifier and compare it with the on-chain record. The commitment data is built upon this foundation, including not only the first hash value but also metadata such as the hash algorithm version and random salt identifier, ensuring compatibility with historical records during future algorithm iterations.

[0056] In this embodiment, the commitment data is typically encapsulated as a fixed-length structure, with its core field being the first hash value, supplemented by a small number of metadata fields, such as a time window statistics identifier, a slot count counter, or an extended flag. The commitment data does not record any information about the operation and maintenance behavior itself, but merely represents that there is a pre-allocated potential record slot within a certain device, a certain responsible entity, and a certain time window.

[0057] It's easy to understand that even before the shadow log bit is activated, the chain already has a complete grasp of the set of all potential record spaces without revealing any behavioral details. When subsequent operational actions occur and activate records are generated, simply including the plaintext of the shadow log bit identifier or its hash in the activation record is sufficient to complete the association and verification with existing committed data. This embodiment provides a verifiable record space benchmark for subsequent negative space identification through the form of committed data.

[0058] S1.4: The shadow log bit identifier and the corresponding commitment data are combined to form a shadow log bit commitment pair. The consensus node of the main chain of the block packages the shadow log bit commitment pair and writes it into the block to generate an irreversible pre-commitment storage block. The shadow log bit is committed to not being modified, replaced or deleted after being written to the main chain of the block, and only the addition of an activation record corresponding to the shadow log bit is allowed to represent the state update. Specifically, after constructing the shadow log bit identifier and commitment data, this embodiment assembles them into a shadow log bit commitment pair, where one end is a resolvable identifier field and the other end is the corresponding commitment data. The shadow log bit commitment pair is submitted to the main blockchain in the form of a transaction or record unit, and is received and verified by the consensus nodes participating in maintaining the main blockchain. Verification typically includes checking the validity of the field format, whether the time window is within the allowed range, and whether there are conflicts in the combined encoding. Once a batch of shadow log bit commitment pairs passes verification, the consensus node responsible for block production packages them into the data area of ​​the new block, forming a set of pre-commitment storage records. Because the main blockchain adopts a chain structure and records the hash value of the previous block in the block header, once a block is referenced by multiple subsequent blocks, all shadow log bit commitment pairs contained in that block acquire the properties of being irreversible and immutable.

[0059] In this embodiment, pre-committed storage blocks can be generated in batches based on time or by responsible party. For example, at midnight each day, a set of shadow log bit commitment pairs for a future period can be generated all at once based on the previous day's equipment list, responsibility allocation, and time granularity, and submitted to the main chain for packaging, thereby pre-solidifying all potential record space for the subsequent time period on the chain. Alternatively, a rolling approach can be used, dynamically generating and writing the corresponding shadow log bit commitment pairs within several time units before the start of each time window. Regardless of the strategy used, this embodiment ensures that the relevant shadow log bits have already appeared in the main chain in the form of commitments before the operation and maintenance behavior occurs. Through such pre-committed blocks, once a certain time window is entered, any record of operation and maintenance behavior can only be activated on these existing shadow log bits, and it is impossible to add new slots afterwards to cover up the missing records.

[0060] In another example, modifying the state of the target shadow log bit in the main blockchain includes: S1.5: Calculate the second hash value based on the maintenance summary data; Specifically, after the shadow log bits have been committed to the main blockchain, a stable method is needed to establish a one-to-one correspondence between each actual maintenance action and its corresponding shadow log bit. Considering that maintenance records typically contain multiple fields such as operation instructions, parameters, and equipment component information, directly writing the complete record to the main blockchain would not only consume on-chain storage space but also easily expose the business details of each responsible party. Therefore, it is necessary to compress the maintenance records into a fixed-length, irreversible digest representation. To this end, this step selects the maintenance digest data as input and calculates a second hash value using a hash algorithm. This ensures that only this digest needs to be stored on the blockchain subsequently, without exposing the original maintenance content, while allowing for integrity verification by recalculating the hash value when needed.

[0061] In this embodiment, the operation and maintenance summary data undergoes field normalization before hash calculation to ensure consistent results across different nodes or implementation versions. Specifically, this includes: arranging the structured fields within the operation and maintenance summary according to a predefined field order; standardizing numerical fields to the same precision and unit; encoding string fields using a unified character set; and filling missing fields with placeholders. After normalization, the entire operation and maintenance summary data is used as hash input, and a collision-resistant hash algorithm is used to calculate the second hash value. This second hash value serves as the unique fingerprint of the operation and maintenance record on the blockchain. If any field is subsequently altered, the recalculated hash value will differ from the initially stored result, allowing this embodiment to identify any modifications.

[0062] The operation and maintenance summary data includes at least one structured field generated internally by the operation and maintenance sub-chain; The structured fields include at least one of the following: operation and maintenance event type, operation instruction code, device component code, operation and maintenance tool identifier, execution terminal identifier, operator identifier, and signature field; The second hash value is written into the activation record containing the target shadow log bit identifier, which is used to establish a many-to-one reference relationship between the operation and maintenance summary data and the same shadow log bit within the main chain of the block.

[0063] S1.6: Construct an activation record containing a shadow log bit identifier, an activation flag field, and a second hash value; Specifically, the second hash value alone is insufficient to indicate the location of the operational activity on the timeline and which shadow log bit it is associated with. Therefore, a structured unit that can simultaneously carry the information of what happened in which slot is being recorded. This step combines the identified target shadow log bit identifier with an activation flag field used to distinguish between inactive, activated, or reactivated states, and the aforementioned second hash value to form a complete activation record. Through this structural design, the shadow log bit identifier points to the time window and the responsible party, the activation flag field describes the state transition process, and the second hash value acts as a fingerprint of the operational content. Together, these three elements constitute a logical characterization of this operational activity on the blockchain.

[0064] In this embodiment, the activation record can be encapsulated using a fixed-length or variable-length structure plus a TLV subfield. The shadow log bit identifier field can directly reference the identifier generated in S1.2, and the activation flag field can use enumerated values ​​to represent different states, such as first activation / re-activation / revocation flags. The second hash value field is a fixed-length digest value. As needed, auxiliary fields related to the responsible entity's identity, such as the operating terminal identifier and role code, can be added to the activation record. However, these fields will not participate in the commitment hash calculation, thus balancing privacy protection and internal auditing requirements.

[0065] S1.7: The activation record is encapsulated using the transaction packaging logic of the main blockchain to obtain a transaction structure, wherein the transaction packaging logic includes serializing the activation record, assigning a transaction identifier to the serialization result, writing a timestamp field into the transaction structure, performing signature processing on the transaction structure, and appending the signature information to the transaction signature field of the transaction structure. Specifically, after the activation record is generated, it needs to be submitted to the main blockchain in a standardized transaction format to participate in the consensus and block production process. Since different nodes may have different operating environments, storage media, and programming languages, direct transmission in memory structure can easily lead to parsing ambiguity. Therefore, it is necessary to serialize the activation record using a unified packaging logic to generate a stable transaction structure. This step generates a byte sequence by encoding and arranging the fields of the activation record, and assigns a unique transaction identifier to this sequence; simultaneously, a timestamp field is written into the transaction structure to record the time information when the transaction was initiated or constructed, so that it can be sorted and conflict resolved on the chain.

[0066] In this embodiment, the serialization process can employ pre-agreed binary encoding rules, such as assigning fixed offsets and lengths to each field, or using a variable-length structure with type tags. The transaction identifier can be generated by combining a local counter with node identity information, or it can be calculated from the transaction content using a hash function. The timestamp field can originate from a trusted time service, or adopt a logical clock mechanism agreed upon by the main blockchain to reduce the impact of local clock deviations on the node. After serialization is complete, this embodiment uses the private key held by the responsible entity to sign the transaction structure, appending the signature result to the transaction signature field. This allows verification in the subsequent consensus phase that the activation record was indeed initiated by an authorized entity and has not been tampered with during transmission.

[0067] S1.8: Broadcast the transaction structure to the consensus network of the main blockchain, and determine whether to write the activation record into a new block based on a preset consensus algorithm through the consensus network; If not written to a new block, the activation record is appended in an overwriteable manner, ensuring a chained association with the previously written shadow log bit; If a new block is written, an offset address within the block is allocated for the activation record in the data area of ​​the new block, and the Merkle root hash containing the activation record is written in the block header; The activation flag field in the activation record is used to record the status change of the shadow log bit. The activation process of the shadow log bit allows multiple activation records to be associated with the same shadow log bit to represent one or more maintenance actions performed by the responsible party within the same time window. Specifically, after the transaction structure is constructed, it needs to be sent to the set of nodes maintaining the main blockchain, where each node jointly completes the verification and recording process. This step distributes the transaction structure to the currently online consensus nodes through the broadcast mechanism provided by the consensus network, allowing each node to perform legality checks on the transaction content locally, including signature verification, field format checks, and matching verification with existing shadow log bit commitments. If the transaction meets the preset conditions, it can enter the subsequent block-building candidate set and participate in the construction of a new block; if it is not included in a new block in a certain round of block production, it is retained in the candidate set or buffer queue, waiting for the next round of block production, while the transaction is recorded locally in an append-only manner to ensure that the transaction content is not overwritten or lost.

[0068] In this embodiment, the consensus network can employ a Byzantine fault-tolerant, practical Byzantine fault-tolerant, or weighted voting consensus algorithm. The ordering and selection strategies for transactions may differ under different algorithms, but all require that when a new block is generated, the block-producing node selects a certain number of transactions from the verified transaction set and packages them into the block's data area. When the transaction containing the activation record is selected to be written into the new block, a specific offset address is assigned to the activation record within the data area for easy subsequent querying and indexing. The Merkle root hash containing all transactions is updated in the block header, allowing any node to verify that the activation record indeed exists in the corresponding block through the Merkle path. Through this process, the activation record ultimately becomes part of the main block chain, forming a chained association with the previously written shadow log bit commitments.

[0069] Next, we will further elaborate on the technical content of the method of this application regarding equipment operating status data.

[0070] In one example, the collection of the device operating status data includes: The monitoring terminals deployed on the side of the electromechanical equipment of the highway periodically collect the operating parameters of the equipment, wherein the operating parameters include data from at least one internal sensor of the equipment; The operating parameters are divided into corresponding time windows according to the time granularity; Calculate the third hash value for the operating parameters within each time window to form a device status summary; The device status digest is written into the main blockchain, and the root hash of the device status chain is recorded through the main blockchain.

[0071] Understandably, in highway scenarios, equipment used for lighting, ventilation, monitoring, and gantry recognition is generally deployed in a decentralized manner, with different driving methods and operating modes. Therefore, the monitoring terminal does not directly record all sensor outputs as is during data acquisition. Instead, it pre-sets parameter sampling templates based on the equipment type. For example, lighting drivers collect current, voltage, and dimming duty cycle; fans collect three-phase current and speed encoder pulses; and cameras collect attitude angles, focal loop positions, and image processing unit loads. Before acquisition, the raw signals undergo basic processing, such as de-jittering current fluctuations, performing circumferential calculations on angle information, and merging fields with different structures, such as three-phase current and single-phase current, into a unified representation. This ensures that subsequent summary calculations maintain a consistent input structure across different equipment models.

[0072] In this embodiment, the operating parameters collected by the monitoring terminal are not written to the blockchain in real time. Instead, they are first windowed according to a preset time granularity, making each time window an independent data segment. When dividing the window, the monitoring terminal maintains a lightweight circular buffer locally to cache all sampling points within a time window and perform preliminary processing. For example, it uses sliding sampling to filter out instantaneous noise, and performs range clipping on continuous quantities such as current or angle. Then, the data within the time window is concatenated into a structured data unit according to the field order. When the window ends, the monitoring terminal generates a summary value of the structured unit, i.e., a third hash value, thereby forming a device status summary.

[0073] Furthermore, device status summaries are not directly scattered and written to the main chain, but are appended to independent status record chains or status sequence structures in chronological order. Their root hashes are periodically recorded on the main chain to ensure the overall verifiability of the status sequence. Specifically, a Merkle tree of status summaries can be constructed on the monitoring terminal or central node, using all summaries for a given period as leaf nodes. After constructing the root tree, the root hash is written to the main chain, allowing any summary to be verified for existence via the Merkle path.

[0074] Next, we will further elaborate on the technical content of the negative space alignment method in this application.

[0075] In this embodiment, the core logic of negative space alignment can be understood as comparing two trajectories: One is the trajectory of the equipment status changes over time; The other is the activation trajectory of the shadow log position over time.

[0076] If a device status summary shows a change in operating mode within a certain time window—for example, current changing from no-load to load, fan speed changing from off to running, or camera pan / tilt angle changing abruptly—then a status change within that time window can be determined by comparing the summary values ​​of adjacent windows. Correspondingly, if all shadow log bits bound to the device and responsible entity remain inactive within the same time window, this is represented in the index table as a gap in the behavior record on the status change trajectory. In this embodiment, this gap is abstracted as a negative space, representing that within that time window, the device has reflected that its status has been interfered with or fluctuated, but no behavior from the operations and maintenance side has been projected onto the pre-allocated slots. Since the pre-allocation of shadow log bits is already fixed in the main blockchain and cannot be added or deleted afterwards, this negative space cannot be eliminated by unilaterally adding or deleting records by a single entity; rather, it is a natural result of the mismatch between two independent data paths.

[0077] In one example, the negative spatial comparison of each device in each time window includes: S4.1: Based on the set of shadow log bit identifiers, the set of shadow log bit activation states, and the set of device status summaries recorded in the main blockchain, a time window index table is constructed for each device, wherein the time window index table is used to correspond one-to-one between the device status summary and the set of shadow log bits within a preset time window range; Specifically, to avoid repeatedly retrieving device status summaries and shadow log bits from the main chain during negative space comparison, this step first logically constructs a time window index table for each device. This compresses various on-chain data related to the device within the same time window into a single index record that can be directly used for comparison. The time window index table can be built separately for each device. Each table uses the time window identifier as the row key, and each row simultaneously links to the device status summary reference, shadow log bit identifier set reference, and responsible entity identifier for that time window. This allows subsequent comparisons to obtain complete comparison input through a single index query, rather than performing a global scan on the main chain on a device-by-device basis. Since the time window identifier has already been associated with the device identifier, responsible entity identifier, and time granularity through combined encoding in the previous steps, each row of the index table uniquely corresponds to a set of shadow log bit commitments and a device status summary record on the main chain.

[0078] In this embodiment, the construction of the time window index table can be performed periodically by a node capable of reading the main chain of blocks: Nodes traverse block records related to a specific device within a preset time period, extracting the device status digest hash, shadow log bit commitment pairs, and reference information of active records belonging to the same time window, and categorizing them according to the time window identifier. During the categorization process, nodes can generate index entries for each time window, each entry including at least a status digest hash reference field, a shadow log bit identifier list field, and a responsible entity identifier field related to that window. The index table can be stored in off-chain data storage, and its integrity can be verified by calculating a digest or root hash of the entire table and then writing it to the main blockchain.

[0079] S4.2: Locate the device status summary according to the time window index table, read the internal fields of the device status summary, wherein the internal fields include the operating parameter fields collected by the monitoring terminal and processed by hashing, and extract at least one summary field for characterizing the changes in the internal status of the device based on the preset field masking rules. S4.3: Read the shadow log bit identifier bound to the time window index table, construct a shadow log bit set, and according to each shadow log bit identifier in the shadow log bit set, retrieve the corresponding activation record in the main chain of the block, extract the activation flag field therein, and generate a shadow log bit activation status vector. Specifically, the device status summary is not in the form of raw sensor data, but rather the result of organizing and hashing the operating parameters collected within a time window. Therefore, in the negative space comparison stage, it is necessary to reconstruct information on whether a status change has occurred from within the summary. This step locates the device status summary record of the target time window using the time window index table, and reads the structured fields within the summary, especially those fields that have been preprocessed, normalized, and marked as usable for status analysis by the monitoring terminal during the acquisition stage.

[0080] In this embodiment, field masking rules can be pre-configured according to the device type. For example, for tunnel ventilation fans, the amplitude range of three-phase current, changes in rotational speed encoding values, and start / stop flag fields can be used as core references for state changes, while instantaneous voltage fluctuations or ambient temperature fields can be marked as unnecessary fields. For cameras, fields such as pan / tilt angle, zoom motor position encoding, and frame drop rate can be the focus. Field masking rules can be defined in the form of Boolean masks, that is, each field within the summary is assigned a mark indicating whether it participates in the comparison or not. When reading the state summary during the comparison phase, the field set is filtered through the mask, and only the fields marked as participating in the comparison are retained as summary fields. This process ensures that state determination focuses on the parameters most sensitive to state changes, avoiding the influence of random fluctuations in irrelevant fields on the comparison results.

[0081] S4.4: Based on the summary field and the shadow log bit activation state vector, a comparison operation is performed using a negative space judgment rule set that includes at least threshold judgment rules, bit order comparison rules, and field coverage rules; Specifically, device status change information alone is insufficient for negative space judgment; a structured representation of whether all shadow log bits within the same time window are activated is also required. This step reads the set of shadow log bit identifiers bound to the target time window through a time window index table. For each shadow log bit identifier in the set, a search is performed on the main blockchain to determine if a corresponding activation record exists. During the search, the index relationship established by the shadow log bit identifiers in the main blockchain can be used to quickly locate the block or transaction entry containing the relevant activation record and extract the activation flag field. Subsequently, these activation flags are arranged in a preset order to form a shadow log bit activation status vector. This allows the activation status of each slot within the same time window to be intuitively represented by a vector structure, providing a suitable input format for subsequent rule comparison with the digest field.

[0082] In one example, the comparison operation, which combines a set of negative space rules including at least threshold determination rules, positional comparison rules, and field coverage rules, includes: The threshold determination rule is used to determine whether the summary field meets the preset change conditions within the current time window without accessing the original operating parameters. If it does not meet the conditions, an uncovered flag is written to the comparison result. The bit alignment rule is used to establish a one-to-one correspondence between the shadow log bit set and the summary field. If there is no one-to-one correspondence, an overwritten flag is written to the alignment result. The field overwrite rule is used to write an overwritten flag to the comparison result when all bits of the shadow log bit activation state vector are inactive. When the comparison operation outputs an uncovered flag in the time window, a negative space anomaly record is constructed. The negative space anomaly record includes at least a device identifier field, a time window identifier field, a shadow log bit identifier set field, a device status summary reference field, and an uncovered flag field.

[0083] In one example, the time granularity of the time window is a configurable parameter that can be adjusted based on device type, inspection frequency, and maintenance standards, wherein: Adjustments to the time window include increasing the number of time windows, shortening the length of the time window, and reassigning the numbering of the generated time windows. The adjusted time window configuration is updated on-chain via the main blockchain.

[0084] In another example, after the negative space anomaly record is written into the main blockchain, an anomaly index table is constructed based on the negative space anomaly record. The anomaly index table includes device identifier index, responsible entity index, time window index, and shadow log bit index fields. The anomaly index table is verified by the consensus network based on a preset consensus algorithm.

[0085] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A blockchain-based method for preventing tampering of highway electromechanical equipment operation and maintenance records, applied to an operation and maintenance record system with multiple responsible parties, characterized in that: The operation and maintenance record system is configured with a main blockchain, which includes multiple operation and maintenance sub-chains. Each responsible entity corresponds one-to-one with a specific operation and maintenance sub-chain. The method includes: Based on the equipment, responsible party, and time granularity, at least one shadow log bit is pre-generated for each equipment at each time granularity, and the shadow log bit and the commitment corresponding to the shadow log bit are written into the main blockchain. When an operational activity is detected, the operational record is written into the corresponding responsible entity's operational subchain, and operational summary data is generated. Determine the target shadow log bit corresponding to the operation and maintenance behavior, and modify the state of the target shadow log bit in the main blockchain; Within a preset time period, based on the shadow log bit status information in the main blockchain and the corresponding operating status data of the device, a negative space comparison is performed on each device in each time window. If a negative space situation exists, a negative space anomaly record is generated and written into the main blockchain.

2. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 1, characterized in that, The process of pre-generating at least one shadow log bit for each device at each time granularity includes: Each device's identifier, responsible entity identifier, and time granularity are combined and encoded, and a time window identifier corresponding to the time window is generated based on the combined encoding. At least one shadow log bit identifier is constructed based on the time window identifier, wherein the shadow log bit identifier includes a field for distinguishing the device, the responsible party, and the time window; Calculate a first hash value for each shadow log bit identifier, and construct commitment data based on the first hash value; The shadow log bit identifier and the corresponding commitment data are combined to form a shadow log bit commitment pair. The consensus node of the main blockchain packages the shadow log bit commitment pair and writes it into the block to generate an irreversible pre-commitment storage block. The shadow log bit is committed to not being modified, replaced, or deleted after being written to the main chain of blocks, and state updates are only allowed by adding an activation record corresponding to the shadow log bit.

3. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 2, characterized in that, Modifying the state of the target shadow log bit in the main blockchain includes: Calculate the second hash value based on the maintenance summary data; Construct an activation record that includes a shadow log bit identifier, an activation flag field, and a second hash value; The activation record is encapsulated using the transaction packaging logic of the main blockchain to obtain a transaction structure. The transaction packaging logic includes serializing the activation record, assigning a transaction identifier to the serialization result, writing a timestamp field into the transaction structure, performing signature processing on the transaction structure, and appending the signature information to the transaction signature field of the transaction structure. The transaction structure is broadcast to the consensus network of the main blockchain, and the consensus network determines whether to write the activation record into a new block based on a preset consensus algorithm. If not written to a new block, the activation record is appended in an overwriteable manner, ensuring a chained association with the previously written shadow log bit; If a new block is written, an offset address within the block is allocated for the activation record in the data area of ​​the new block, and the Merkle root hash containing the activation record is written in the block header; The activation flag field in the activation record is used to record the status change of the shadow log bit. The activation process of the shadow log bit allows multiple activation records to be associated with the same shadow log bit, so as to represent one or more maintenance actions performed by the responsible party within the same time window.

4. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 1, characterized in that, The collection of the equipment operating status data includes: The monitoring terminals deployed on the side of the electromechanical equipment of the highway periodically collect the operating parameters of the equipment, wherein the operating parameters include data from at least one internal sensor of the equipment; The operating parameters are divided into corresponding time windows according to the time granularity; Calculate the third hash value for the operating parameters within each time window to form a device status summary; The device status digest is written into the main blockchain, and the root hash of the device status chain is recorded through the main blockchain.

5. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 4, characterized in that, The negative spatial comparison of each device in each time window includes: Based on the set of shadow log bit identifiers, the set of shadow log bit activation states, and the set of device status summaries recorded in the main blockchain, a time window index table is constructed for each device. The time window index table is used to map the device status summary to the set of shadow log bits one by one within a preset time window. The device status summary is located according to the time window index table, and the internal fields of the device status summary are read. The internal fields include the operating parameter fields collected by the monitoring terminal and processed by hashing. At least one summary field for characterizing the internal status change of the device is extracted based on the preset field masking rules. Read the shadow log bit identifiers bound to the time window index table, construct a shadow log bit set, and according to each shadow log bit identifier in the shadow log bit set, retrieve the corresponding activation record in the main chain of the block, extract the activation flag field therein, and generate a shadow log bit activation status vector. The comparison operation is performed based on the summary field and the shadow log bit activation state vector, combined with a negative space judgment rule set that includes at least threshold judgment rules, bit order comparison rules and field coverage rules.

6. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 5, characterized in that, The comparison operation, which combines a negative space judgment rule set including at least threshold judgment rules, positional comparison rules, and field coverage rules, includes: The threshold determination rule is used to determine whether the summary field meets the preset change conditions within the current time window without accessing the original operating parameters. If it does not meet the conditions, an uncovered flag is written to the comparison result. The bit alignment rule is used to establish a one-to-one correspondence between the shadow log bit set and the summary field. If there is no one-to-one correspondence, an overwritten flag is written to the alignment result. The field overwrite rule is used to write an overwritten flag to the comparison result when all bits of the shadow log bit activation state vector are inactive. When the comparison operation outputs an uncovered flag in the time window, a negative space anomaly record is constructed. The negative space anomaly record includes at least a device identifier field, a time window identifier field, a shadow log bit identifier set field, a device status summary reference field, and an uncovered flag field.

7. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 1, characterized in that, The main blockchain adopts a consortium blockchain structure, with multiple operation and maintenance responsible entities, equipment manufacturers, and regulatory agencies participating as consensus nodes. The consensus algorithm of the main blockchain includes at least one of the Byzantine fault tolerance algorithm, the practical Byzantine fault tolerance algorithm, and the weighted voting consensus algorithm. The main blockchain provides a unified record index and timestamp source for each operating sub-chain.

8. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 3, characterized in that, The operation and maintenance summary data includes at least one structured field generated internally by the operation and maintenance sub-chain; The structured fields include at least one of the following: operation and maintenance event type, operation instruction code, device component code, operation and maintenance tool identifier, execution terminal identifier, operator identifier, and signature field; The second hash value is written into the activation record containing the target shadow log bit identifier, which is used to establish a many-to-one reference relationship between the operation and maintenance summary data and the same shadow log bit within the main chain of the block.

9. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 1, characterized in that, The time granularity of the time window is a configurable parameter, which can be adjusted according to equipment type, inspection frequency, and maintenance standards. Adjustments to the time window include increasing the number of time windows, shortening the length of the time window, and reassigning the numbering of the generated time windows. The adjusted time window configuration is updated on-chain via the main blockchain.

10. The method for preventing tampering of highway electromechanical equipment operation and maintenance records based on blockchain according to claim 1, characterized in that, After the negative space anomaly record is written into the main blockchain, an anomaly index table is constructed based on the negative space anomaly record. The anomaly index table includes device identifier index, responsible entity index, time window index, and shadow log bit index fields. The anomaly index table is verified by the consensus network based on a preset consensus algorithm, and the verified anomaly index table is appended to the main blockchain.

Images