An engineering vehicle traceability and ownership authentication platform for cross-border trade

Abstract

The application discloses a kind of engineering vehicle provenance and ownership authentication platform for cross-border trade, including data access module, root identity anchoring module, component lineage module, provenance event module, right standardization module, ownership continuity verification module, cross-border authentication module and offline handover module, root identity anchoring module obtains engineering vehicle fixed identification data, identification area three-dimensional surface feature and vehicle controller challenge response data, generates whole vehicle root identity, component lineage module is associated to whole vehicle root identity as replaceable sub-identity with engine, power battery, working device and controller, offline handover module generates offline handover record using pre-locked right certificate, vehicle field identity response and handover random number in network limited environment, and state is merged after recovery connection, the application can maintain whole vehicle identity continuity in the case where engineering vehicle component is replaced, and improve the verifiability of cross-border ownership transfer record.

Description

Technical Field

[0001] This invention relates to the field of cross-border trade data processing and digital authentication technology for engineering vehicles, specifically to a platform for tracing and authenticating the ownership of engineering vehicles through the vehicle's root identity, component lineage, and continuous rights certificates. Background Technology

[0002] Construction vehicles typically include excavators, loaders, cranes, and other non-road mobile equipment used for construction operations. Construction vehicles are high-value and have a long service life. In cross-border trade, they may undergo multiple transfers, leasing, or parts replacement.

[0003] Compared to ordinary passenger vehicles, some engineering vehicles lack unified registration information across regions. Vehicle ownership may be proven through purchase contracts, payment vouchers, factory documents, or other business documents. The document names and field formats used in different countries and regions are not consistent, making it difficult for transferees in cross-border transactions to confirm the complete ownership status through a single data interface.

[0004] The engine, power battery, hydraulic components and working device of engineering vehicles may be replaced during long-term use. If the traceability platform directly binds the vehicle identity to the code of a replaceable part, a new vehicle identity may be generated incorrectly after the part is replaced. If only the vehicle number is retained, it is difficult to confirm the source and replacement process of the currently installed part.

[0005] Existing traceability systems typically assign QR codes, electronic tags, or blockchain identifiers to vehicles or components and write production and circulation information into a traceability database. This method can save submitted data, but it cannot prove that the vehicle on site is the one initially registered based solely on the data summary. When the vehicle nameplate is replaced or the chassis markings are reworked, a regular code query may still return the original vehicle record.

[0006] Existing ownership management methods typically store the current rights holder as a single field. Engineering vehicles may simultaneously have an actual possessor, an equipment user, and a guarantor. If the platform only covers the owner field, it is difficult to determine whether other valid rights restrict the transfer when ownership is transferred.

[0007] Cross-border handover points may be located in ports, storage yards, or construction areas, where network connections are unstable. If the handover process requires real-time access to the central platform, network interruptions will affect vehicle identity verification and handover record generation. Allowing both parties to generate records offline may result in the same ownership certificate being used repeatedly in different transactions.

[0008] Therefore, there is a need to provide a traceability and ownership authentication platform for engineering vehicles in cross-border trade, which can manage the identity of the whole vehicle and the identity of replaceable parts in a hierarchical manner, and ensure that each transfer of ownership can be linked to a unique and valid prior rights certificate, while meeting the requirements for on-site vehicle verification and handover record merging in network-limited environments. Summary of the Invention

[0009] The purpose of this invention is to provide a traceability and ownership authentication platform for engineering vehicles in cross-border trade, in order to solve the technical problems that vehicle codes are easily replaced, identity relationships are interrupted due to replaceable parts, the binding relationship between different rights is difficult to verify, and offline handover may result in duplicate transfers. To achieve the above objectives, this invention sets up a data access module for receiving engineering vehicle identity data, physical feature data, component data, business event data, and ownership certificate data.

[0010] The data access module can establish data interfaces with vehicle manufacturing enterprise systems, equipment trading systems, testing service systems, maintenance service systems, and cross-border logistics systems. Each data interface is configured with a data source identifier and interface identity certificate. For paper or electronic documents that cannot be directly obtained through the data interface, the data access module can receive document images, perform character recognition and field extraction on the document content, and save the original document summary.

[0011] The root identity anchoring module first acquires the fixed identification data of the engineering vehicle. The fixed identification data may include the chassis identification code, manufacturing serial number, or equipment code fixed on the main load-bearing structure. After character cleaning, encoding rule verification, and manufacturing entity mapping, the fixed identification data forms a standardized fixed identification. The platform also acquires the physical feature data of the identification area through image acquisition equipment. The image acquisition equipment can be a binocular camera, a structured light acquisition device, or a mobile terminal with depth measurement function. The physical feature data of the identification area not only includes the identification character content, but also the character stamping depth, character edge contour, substrate surface texture, and the positional relationship of the identification area relative to the chassis structure. The physical feature extraction unit extracts the three-dimensional contour feature vector, local texture feature vector, and structural position feature vector from the physical feature data of the identification area, and combines them into physical fingerprint features.

[0012] The vehicle controller identity data can be provided by the main controller of the engineering vehicle or an independent security authentication unit. The platform sends random challenge data to the vehicle controller. The vehicle controller uses the internally stored device key to sign the random challenge data and the controller status digest, and returns the challenge response data to the platform. The root identity anchoring module uses the pre-registered controller public key to verify the challenge response data. After successful verification, it proves that the field device can use the device key corresponding to the initially registered controller. The root identity anchoring module establishes the whole vehicle root identity record based on the standardized fixed identifier, physical fingerprint feature and controller public key digest. The whole vehicle root identity record can include root identity identifier, fixed identifier digest, initial physical fingerprint feature, controller public key digest, initial registration time and root identity trust value.

[0013] The root identity trust value is calculated based on the consistency of the fixed identifier, the similarity of the physical fingerprint, and the challenge response verification results. When all three verification channels pass, the root identity trust value is in the first trust interval. When one of the verification channels cannot be used for a reasonable reason, but the other verification channels pass, the root identity trust value is in the second trust interval and a supplementary verification is triggered. Using multiple verification channels can reduce the misidentification caused by determining the identity of engineering vehicles based solely on the nameplate text or QR code.

[0014] During long-term use, engineering vehicles may experience corrosion and wear in the identification area. The platform cannot deny the original vehicle root identity simply because of minor changes in the physical fingerprint. Therefore, the root identity anchoring module saves multiple historical physical fingerprint features of the identification area and forms a physical fingerprint time sequence according to the collection time. When the similarity between the on-site physical fingerprint and the initial physical fingerprint decreases, the platform compares the change direction and change rate between adjacent historical physical fingerprints. If the physical fingerprint change conforms to the continuous wear model and the fixed identification content and controller challenge response pass the verification, the original vehicle root identity is maintained, and the on-site physical fingerprint is saved as a new feature version. If the physical fingerprint shows discontinuous changes, or the depth contour of the character area is significantly reconstructed, the platform generates a vehicle identity anomaly event.

[0015] The component hierarchy module manages replaceable components in engineering vehicles. Replaceable components can include engines, power batteries, hydraulic pumps, main controllers, cabs, or working devices. Each replaceable component has a component sub-identity, generated based on component code, component type, manufacturing information, and component physical characteristics. The component hierarchy module establishes a current component set and a historical component set under the vehicle root identity. The component sub-identity currently installed on the engineering vehicle is in the current subordinate state. After a component is removed, its component sub-identity is transferred to the historical subordinate state, and the removal time, removal reason, and removal subject are recorded. When a new component is installed, the platform establishes a component installation event, which includes the new component sub-identity, the replaced component sub-identity, installation time, installation subject, and installation certificate summary. After a valid component replacement event is connected, changes to components will not cause changes to the vehicle root identity. When the platform queries the vehicle traceability information, it can simultaneously return the current component hierarchy and the historical component hierarchy.

[0016] For main controller replacement, the platform requires the original controller or authorized maintenance entity to sign the controller replacement event. The new controller's public key is added to the vehicle's root identity record through the replacement event. If a valid controller replacement event is missing, or if the on-site controller's public key is inconsistent with the platform record, the platform generates a controller identity anomaly event.

[0017] The traceability event module converts data generated during vehicle production, initial delivery, inspection, repair, parts replacement, transportation, and cross-border handover into traceability event objects. Each traceability event object includes event type, event subject, event time, event location, scope of associated assets, data summary, and summary of preceding events. Traceability event objects can be saved by appending. New events do not overwrite the original events but are connected to the previous valid event through the summary of preceding events. The platform thus forms a traceability event graph centered on the root identity of the whole vehicle, with the sub-identities of parts connected to the corresponding part events as child nodes.

[0018] The rights standardization module receives ownership certificate data from various sources, including transaction contracts, purchase certificates, lease documents, guarantee documents, judicial restriction information, and regulatory control records. The module extracts the rights holder, obligor, rights type, asset scope, validity period, applicable region, and transfer conditions through field mapping templates. For documents using different languages ​​or rights names, the rights type mapping unit converts the rights descriptions in the documents into standard rights types within the platform. Standard rights types can include ownership, possession, use, income rights, security rights, and regulatory control rights. Standard rights certificates do not represent the platform replacing authorized institutions in legal confirmation of rights; rather, they represent a calculable rights status formed by the platform based on received and verified ownership certificate data. Each standard rights certificate includes a rights certificate identifier, vehicle root identity, rights holder, rights type, asset scope, validity period, applicable region, transfer conditions, certificate status version, and a summary of preceding rights certificates. The asset scope can be the entire vehicle or a specific component. For cases where a working device is leased separately, the asset scope of the use right certificate can only point to the corresponding working device.

[0019] The ownership continuity verification module sets up a rights constraint matrix, which records whether different types of rights can coexist and whether a certain right restricts the transfer of another right. For example, a right of use certificate can coexist with an ownership certificate, but its validity period may restrict the immediate delivery of the vehicle. A valid security certificate can put the transfer of ownership into a conditional state. The ownership transfer request must include at least the transferor, the transferee, the vehicle's root identity, the type of right to be transferred, the scope of the assets to be transferred, and the transfer time. The ownership continuity verification module queries the currently valid standard rights certificates based on the vehicle's root identity and determines the preceding rights certificates that can support this transfer. The platform first verifies whether the transferor is the right holder recorded in the preceding rights certificate or whether it has a valid transfer authorization issued by the right holder. Then, it uses the rights constraint matrix to detect whether there are any rights certificates among the currently valid rights that restrict this transfer.

[0020] After successful verification, the platform sets the prior rights certificate to a locked state and generates a rights transfer reservation record. The rights transfer reservation record includes a summary of the prior rights certificate, the certificate status version, the transfer request identifier, a unique transfer random number, and the lock validity period. During the lock validity period, other rights transfer requests cannot lock the same certificate status version of the prior rights certificate again. After completing the delivery condition verification, the platform sets the prior rights certificate to a consumed state and generates a new rights certificate pointing to the transferee. The new rights certificate saves the summary of the prior rights certificate, enabling the platform to verify the source of rights step by step along the summary of the prior rights certificate. This rights certificate processing method requires that each ownership transfer consumes a unique and valid prior rights status, thereby detecting situations where the same vehicle rights are used repeatedly in multiple unrelated transactions. For transactions that only transfer the right of use without transferring ownership, the platform does not consume the ownership certificate, but generates a right of use certificate with an independent validity period based on the ownership certificate and authorization documents. After the validity period of the right of use expires, the platform sets the right of use certificate to a terminated state, while the ownership certificate remains valid.

[0021] The cross-border authentication module generates cross-border ownership authentication certificates based on the authentication field requirements of the target region. The platform configures right type mapping rules and authentication field templates for different target regions. The right type mapping rules convert the platform's standard right types into right descriptions that the target region can recognize. Cross-border ownership authentication certificates can include a whole vehicle root identity summary, a current component lineage summary, a current ownership certificate summary, a valid restriction right summary, and a key traceability event summary. To avoid disclosing all transaction data to different authentication data recipients, the cross-border authentication module calculates leaf node summaries for each authentication data item and constructs a Merkle tree using these leaf node summaries. The platform then uses these leaf node summaries to generate authentication certificates based on the authentication data. The recipient selects the authentication fields to be disclosed based on their verification permissions, and the platform returns the corresponding fields, associated verification paths, and Merkel root digests. The recipient can use the associated verification paths to verify that the disclosed fields belong to the same cross-border ownership authentication certificate. However, the platform cannot directly obtain the specific content of other undisclosed fields through this verification path. For recipients who only need to verify the vehicle's origin and the current rights holder, the platform may not disclose historical transaction amounts and other business information. Cross-border authentication certificates also include the generation time, validity period, target area identifier, and platform signature. After the validity period expires, the recipient needs to re-request the authentication certificate to obtain the current rights status.

[0022] The offline handover module is used to handle weak network handover in ports, yards, or remote construction areas. Before the engineering vehicle enters the offline handover area, the transferor or transferee submits an offline handover application to the platform. After the platform completes the ownership continuity verification, it locks the prior rights certificate and generates a handover authentication package. The handover authentication package includes the whole vehicle root identity digest, the prior rights certificate digest, the certificate status version, the ownership transfer reserved record, the handover random number, the allowed offline time, and the handover participant identifier. After being signed by the platform, the handover authentication package is sent to the handover terminal. The handover terminal can be a mobile authentication device or a handheld terminal with a secure storage unit.

[0023] During on-site handover, the handover terminal collects the physical characteristics of the engineering vehicle's identification area and reads the fixed identification data. The handover terminal sends the handover random number from the handover authentication packet to the vehicle controller. The vehicle controller signs the handover random number and the current controller status summary, and returns the on-site challenge response data. The handover terminal determines whether the on-site vehicle corresponds to the whole vehicle root identity in the handover authentication packet based on the on-site physical fingerprint similarity, fixed identification consistency, and challenge response verification results. After identity verification is passed, the transferor terminal and the transferee terminal sign the handover time, handover location, vehicle on-site status summary, and handover random number, respectively. The offline handover module generates an offline handover record based on the signatures of both parties. The offline handover record is stored in the secure storage area of ​​the handover terminal before the network is restored.

[0024] After the network connection is restored, the handover terminal sends the offline handover record to the platform. The platform first verifies the signature of the handover authentication packet and the signatures of both parties. Then, the platform compares the credential status version in the offline handover record with the version of the prior rights credential currently in a locked state. When the two versions match, the handover time is within the allowed offline time, and the ownership transfer reservation record has not been revoked, the platform accepts the offline handover record. The platform sets the prior rights credential to a consumed state and generates a new rights credential pointing to the transferee. The offline handover record is also written into the traceability event graph. When the credential status versions are inconsistent, it indicates that the prior rights status may have changed during the offline period. The platform does not directly complete the ownership transfer but generates a handover conflict event. The offline handover uses a pre-locked prior rights credential, which can retain a unique transfer position during network interruption and reduce the possibility of the same valid credential being reused in multiple offline handover processes.

[0025] The present invention also provides a query verification interface. After the authentication data recipient inputs the cross-border ownership certification certificate identifier, the platform returns the certificate validity status, root identity verification status, and certificate generation time. For recipients with on-site vehicle verification authority, the platform can also generate one-time challenge data. The recipient obtains the challenge response data returned by the vehicle controller through the on-site handover terminal to confirm that the vehicle pointed to by the query certificate is consistent with the on-site vehicle.

[0026] This invention forms a hierarchical identity structure through the vehicle's root identity and component sub-identities. When the engine or working device is reasonably replaced, the platform updates the component genealogy without changing the vehicle's root identity. Physical fingerprints and controller challenge responses are used together to verify the vehicle on-site, reducing the risk of identity theft caused by relying solely on text encoding or electronic tags. Standard rights certificates convert ownership documents from different sources into calculable rights states. The ownership continuity verification module forms a continuous transfer relationship by locking and consuming preceding rights certificates and uses a rights constraint matrix to detect rights conflicts. Selective disclosure of proofs enables the authentication data recipient to verify the required ownership fields without obtaining complete transaction data. The offline handover module combines certificate pre-locking with on-site vehicle identity verification and merges handover records according to certificate status versions after network recovery, improving the continuity of ownership handover data in weak network environments. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the system structure of the engineering vehicle traceability and ownership authentication platform of the present invention.

[0029] Figure 2 This is a schematic diagram of the whole vehicle root identity generation process of the present invention.

[0030] Figure 3 This is a schematic diagram illustrating the hierarchical relationship between the root identity of the whole vehicle and the sub-identity of the components in this invention.

[0031] Figure 4 This is a schematic diagram of the structure of the event tracing diagram of the present invention.

[0032] Figure 5 This is a schematic diagram of the continuous transfer process of the standard rights certificate of this invention.

[0033] Figure 6 This is a schematic diagram illustrating the generation process of the cross-border ownership authentication certificate of the present invention.

[0034] Figure 7 This is a schematic diagram of the offline handover and authentication process of the present invention. Detailed Implementation

[0035] The present invention will be further described below with reference to specific embodiments. The described embodiments are used to explain the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. This embodiment takes a used hydraulic excavator that is intended to be sold from the domestic market to a target area overseas as the object of processing. The excavator has been used for a long time, the engine has been replaced, and it is currently parked in a vehicle yard waiting for export.

[0036] The seller first submits a vehicle registration application through the platform. The data access module receives the excavator's chassis identification code, manufacturing serial number, factory documents, and existing controller information. The staff uses a mobile terminal with depth acquisition capabilities to take multi-angle photos of the chassis identification area. The mobile terminal establishes three-dimensional surface data of the identification area based on multiple images. The root identity anchoring module extracts the character recess contour, character edge shape, and substrate texture around the character from the three-dimensional surface data. The platform compares the above features with the physical fingerprint features saved when the manufacturer first registers the vehicle. The comparison process can first use key points in the character area for position correction, and then calculate the similarity between local feature vectors.

[0037] The platform simultaneously sends random challenge data to the excavator's main controller. The main controller uses the device key in the secure storage area to generate challenge response data. The root identity anchoring module uses the registered public key to verify the challenge response data. After the fixed identifier is consistent, the physical fingerprint similarity reaches the threshold, and the challenge response verification is successful, the platform generates the vehicle's root identity. If the excavator is entering the platform for the first time, the platform can establish an initial vehicle root identity based on the data provided by the manufacturing entity and use the physical fingerprint collected this time as the initial physical fingerprint version.

[0038] The component genealogy module reads the engine code, hydraulic pump code, and working device code, and establishes a component sub-identity for the corresponding component. The platform discovers that the current engine code is different from the engine code in the factory record. The system queries the maintenance event data and obtains the engine replacement record submitted by the maintenance service provider. The engine replacement record includes the original engine sub-identity, the new engine sub-identity, the disassembly time, the installation time, and the maintenance service provider's signature. After verifying the engine replacement record, the component genealogy module sets the original engine sub-identity to a historical subordinate state and sets the new engine sub-identity to a current subordinate state. Since the frame fixing mark, the physical fingerprint of the mark area, and the controller identity can still correspond to the original vehicle root identity, the engine replacement will not cause the platform to regenerate the vehicle root identity. If the system does not obtain a valid engine replacement record, the platform can still maintain the vehicle root identity, but set the new engine sub-identity to a source pending verification state and generate a component genealogy abnormal event.

[0039] The traceability event module converts factory events, first sales events, historical repair events, and current inspection events into traceability event objects. The current inspection event includes engine operating data, hydraulic system inspection results, vehicle exterior images, and the inspection entity's signature. Each event object stores a summary of the preceding events, allowing the platform to trace back from the current inspection event to the engine replacement event and the factory event.

[0040] The seller submits the original purchase documents, payment vouchers, and existing ownership declarations to the platform. The rights standardization module extracts the rights holder and asset scope from the above documents. The platform also finds that the excavator has a previous lease record, the lease contract has expired, and the corresponding right-of-use certificate has been set to terminated. If there is a right-of-use certificate that is still valid, the ownership continuity verification module will determine whether it restricts the vehicle delivery time based on the rights constraint matrix. The platform generates an ownership certificate pointing to the seller based on the verified ownership certificate data. The asset scope of the ownership certificate is the root identity of the whole vehicle and the current component lineage.

[0041] After the buyer and seller sign a cross-border transaction contract, the seller submits a request for ownership transfer to the platform. The request includes the buyer's identity, the vehicle owner's identity, and the scope of rights to be transferred. The ownership continuity verification module queries the currently valid rights certificates to determine if the seller's ownership certificate can support the transfer. The system checks whether there are any unterminated security rights certificates or regulatory control certificates. If there are no restrictive rights, the platform locks the seller's ownership certificate. When locking, the platform records the current certificate status version and generates a unique transfer random number. The seller's ownership certificate enters the transfer reservation state. If another transaction request attempts to lock the same ownership certificate at this time, the platform detects that the same certificate status version already has a valid reservation record and refuses the second lock.

[0042] The cross-border authentication module generates authentication data based on the authentication field templates of the target region. The authentication data includes the vehicle root identity summary, the seller's rights certificate summary, the engine replacement event summary, and the current inspection event summary. The platform calculates each authentication field as a leaf node summary and constructs a Merkle tree. The logistics service provider only needs to verify the vehicle identity and whether the seller has delivery authority. The platform provides the logistics service provider with the vehicle root identity field, delivery authority field, and corresponding verification path. The buyer needs to further verify the engine replacement record and the current inspection result. The platform adds corresponding disclosure fields within the buyer's authority, but does not disclose these fields to the logistics service provider.

[0043] Before the vehicle arrives at the port handover area, the platform generates a handover authentication package. The handover authentication package is bound to the locked seller's ownership certificate. The allowed offline time for the handover authentication package is set to a predetermined time range after the vehicle enters the port yard. If this time range is exceeded, the original handover authentication package becomes invalid. After the vehicle enters the yard, the on-site network is interrupted. The staff uses the handover terminal to read the handover authentication package and collect the on-site physical characteristics of the excavator frame marking area.

[0044] The handover terminal sends a handover random number to the excavator's main controller. The main controller returns challenge response data signed with the device key. The handover terminal completes fixed identifier verification, physical fingerprint similarity calculation, and challenge response verification to confirm the vehicle root identity in the handover authentication package corresponding to the excavator on site. The seller's handover personnel and logistics receiving personnel complete identity authentication on the handover terminal and sign the handover record. The handover terminal generates an offline handover record, which includes the vehicle's on-site identity verification result, handover time, handover location, vehicle status summary, and signatures of both parties.

[0045] After the network is restored, the handover terminal sends the offline handover record to the platform. The platform verifies that the handover authentication package is still valid and confirms that the certificate status version in the record is consistent with the locked seller ownership certificate version. The platform sets the seller ownership certificate to a consumed state, generates a new ownership certificate pointing to the buyer, and records the possession status corresponding to the logistics service provider as a traceability event. If the platform finds that the handover authentication package has expired, it does not directly generate a new ownership certificate, but requires both the buyer and seller to reconfirm the handover result. If the certificate status version changes, the platform generates a handover conflict event and sends the offline handover record to the manual review terminal.

[0046] After the vehicle arrives at the destination area, the buyer or the certification service provider can use the cross-border ownership certification certificate query platform to check the certificate status. On-site certification personnel can also request one-time challenge data and use the vehicle controller to complete the new challenge response verification, thereby confirming that the vehicle on-site in the destination area and the cross-border ownership certification certificate point to the same vehicle root identity.

[0047] The server, image acquisition equipment, mobile handover terminal, and communication equipment used in the platform can all be mature devices in the existing technology. Their function is to complete data acquisition, feature calculation, information storage, and handover communication. The innovation of this invention lies in the whole vehicle root identity verification method formed by the fixed identifier physical fingerprint and the controller challenge response, the hierarchical system of whole vehicle root identity and replaceable component sub-identity, the locking and consumable continuous transfer of standard rights certificates, and the offline handover authentication process involving pre-locked rights certificates.

[0048] The above description is only a preferred embodiment of the present invention. Any equivalent substitutions or changes that do not have substantial differences made based on the technical solution of the present invention should fall within the protection scope of the present invention.

Claims

1. A platform for tracing and authenticating the ownership of engineering vehicles for cross-border trade, characterized in that, The system includes a data access module, a root identity anchoring module, a component genealogy module, a traceability event module, a rights standardization module, a ownership continuity verification module, a cross-border authentication module, and an offline handover module. The data access module acquires fixed identifier data, identifier area physical feature data, vehicle controller identity data, component data, business event data, and ownership proof data. The root identity anchoring module standardizes fixed identifiers, extracts physical fingerprints from the identifier area's physical features, and performs vehicle controller challenge response verification to generate the vehicle's root identity. The component genealogy module establishes the hierarchical relationship between component sub-identities and the vehicle's root identity, and updates the component genealogy as components are replaced. The traceability event module... The module converts business events into traceable event objects associated with the root identity of the entire vehicle and containing summaries of preceding events; the rights standardization module converts ownership certificate data into standard rights certificates containing the rights holder, rights type, asset scope, validity period, and summaries of preceding certificates; the ownership continuity verification module locks preceding rights certificates during ownership transfer, verifies transfer permissions and rights constraints, consumes the certificate after successful verification, and generates a new rights certificate; the cross-border authentication module generates cross-border ownership authentication certificates according to the rules of the target region; the offline handover module generates offline handover records based on the locked preceding rights certificates, on-site identity verification results, and handover random numbers, and updates the status of rights certificates after network recovery.

2. The platform according to claim 1, characterized in that, The fixed identifier includes the chassis identification code and manufacturing serial number, while the physical fingerprint includes the three-dimensional outline of the identifier characters, the surface texture of the substrate, and the structural position of the identifier area. The root identity anchoring module generates a root identity credibility value based on the consistency of the fixed identifier, the similarity of the physical fingerprint, and the challenge response verification results.

3. The platform according to claim 2, characterized in that, The root identity anchoring module analyzes the temporal changes of historical physical fingerprints when the physical fingerprint similarity is below the first threshold but above the second threshold. If it conforms to the preset wear change model and the challenge response verification is passed, the root identity of the whole vehicle is maintained and the physical fingerprint version is updated; otherwise, an abnormal event of the whole vehicle identity is generated.

4. The platform according to claim 1, characterized in that, The component sub-identity configuration includes component type, identification, installation / removal time, source certificate, and installation entity signature; when a component is replaced, the original component sub-identity is converted to the historical subordinate status, the new component sub-identity is converted to the current subordinate status, and the vehicle root identity remains unchanged.

5. The platform according to claim 1, characterized in that, The ownership continuity verification module has a rights constraint matrix that records the coexistence relationship of rights types, transfer restrictions and priority order, and uses this matrix to detect conflicts between ownership transfer requests and non-terminated standard rights certificates.

6. The platform according to claim 1, characterized in that, The standard rights certificate also includes a certificate status version and a unique transfer random number; the ownership continuity verification module locks the previous rights certificate and generates a ownership transfer reservation record, prohibits the same certificate status version from being locked repeatedly, and the new rights certificate is associated with the summary of the previous certificate.

7. The platform according to claim 1, characterized in that, The cross-border authentication module converts the rights type according to the rules of the target region, constructs the authentication data into a Merkle tree, and generates a selective disclosure proof containing leaf nodes, verification paths, and root digests based on the recipient's permissions.

8. The platform according to claim 1, characterized in that, Before going offline, the offline handover module generates a handover authentication package containing the vehicle root identity digest, the previous credential digest, the credential status version, the ownership transfer reserved record, the handover random number, the allowed offline time, and the participant identifier. When offline, it generates an offline handover record based on the on-site physical fingerprint, the vehicle controller's challenge response to the handover random number, and the participant's signature. After the network is restored, when the credential status version is consistent and the handover time is within the allowed offline time, the previous rights credential is consumed and a new rights credential is generated.

9. A method for tracing and authenticating the ownership of engineering vehicles, characterized in that, The traceability and ownership authentication platform collects fixed identifiers, physical characteristics of the identifier area, and vehicle controller identity data. The fixed identifiers are standardized, and physical fingerprints are extracted from the physical characteristics. A challenge response verification is performed on the vehicle controller to generate the vehicle's root identity. A subordinate relationship is established between component sub-identities and the vehicle's root identity, and the current component hierarchy is updated as components are replaced. Vehicle business data is converted into traceability event objects associated with the vehicle's root identity. Ownership proof data is converted into standard rights certificates. Ownership transfer requests are received, prior rights certificates are locked, and transfer permissions and rights conflicts are verified. Upon successful transfer, the certificate is consumed, and a new rights certificate is generated. Cross-border ownership authentication certificates are generated according to the target area rules.

10. The method according to claim 9, characterized in that, When the platform cannot be connected at the handover location, the preceding rights certificate is locked and a handover authentication package is generated; the on-site vehicle identity is verified using the handover random number and an offline handover record is generated; after the connection is restored, the certificate status version, handover time, and participant signatures are verified. If the verification passes, the rights certificate status is updated; if the verification fails, the ownership transfer reservation record is revoked and a handover conflict event is generated.

Images