Data center-based automatic verification method and system for ship binding

Abstract

The application relates to the technical field of ship design, and discloses a ship binding piece automatic checking method and system based on a data center, wherein the method comprises the following steps: acquiring a current data snapshot and a historical data snapshot; performing field-by-field comparison based on the unique identification of the binding piece to generate a changed binding piece set; analyzing an influence range according to a checking rule type to generate an incremental checking object set; performing rule checking on the incremental checking object set and merging the checking result with a historical checking result; comparing the incremental checking result with the historical checking result to generate a checking change tracing record with a change traceability label.

Description

Technical Field

[0001] This invention relates to the field of ship design technology, and more specifically, to a data center-based automatic verification method and system for ship lashing components. Background Technology

[0002] In the ship design process, lashing devices are used to secure cargo on deck, and their design data needs to be verified by multiple rules to ensure safety. In the current process, the data center periodically retrieves lashing device design data in batches from the 3D design platform, converts the format, and stores it in the data center. The verification program then iterates through all valid rules for all lashing devices in the data center, verifies them one by one, and writes the complete verification results back to the data center for designers to query via a web interface.

[0003] However, in actual ship design iterations, designers only add, modify, or delete a small number of lashing components daily. The aforementioned full-scale verification method performs verification calculations for all lashing components and all rules each time, resulting in a large number of unchanged lashing components being repeatedly verified, consuming unnecessary computing resources and verification time. Furthermore, the verification results stored in the data center are completely overwritten each time. Designers cannot directly identify from the query interface which verification results were newly generated or changed due to the current design change. They need to manually compare the two sets of verification results to pinpoint the impact of the change, leading to a technical problem where the impact of changes is difficult to trace quickly. Summary of the Invention

[0004] This invention provides a data center-based automatic verification method and system for ship lashing components, solving the technical problems of low verification efficiency and difficulty in tracing changes in related technologies.

[0005] This invention discloses an automatic verification method for ship lashing components based on a data center, which includes acquiring lashing component design data from a 3D design platform and converting it into a general format data, generating a snapshot of the data extracted this time, and reading historical data snapshots from the data center at the same time; Using the unique identifier of the binding as the association key, perform a field-by-field comparison between the current data snapshot and the historical data snapshot to generate a set of changed bindings containing change type labels and a list of change fields; For each change record in the set of changed bindings, analyze its impact on the verification scope according to the verification rule type, and generate an incremental verification object set by merging and deduplicating the objects affected by each rule. Perform the verification calculation of the associated rules on the binding objects in the incremental verification object set, generate the incremental verification result, and merge it with the historical verification result to generate the latest verification result; The incremental verification results are compared with the historical verification results by the combination key of the binding component identifier and the rule number. After the status change record is attached with the change traceability tag, it is stored in the verification change traceability table.

[0006] Furthermore, the field-by-field comparison includes: marking records that exist only in the current data snapshot as new bundles; marking records that exist only in historical data snapshots as deleted bundles; marking records that exist in both snapshots but at least one attribute field value has changed as modified bundles; and summarizing the new bundles, deleted bundles, and modified bundles to generate the set of changed bundles.

[0007] Furthermore, the analysis of the impact of the verification rule type on the verification range includes: for the spacing range check rule, obtaining the deck number to which the changed lashing belongs, querying other lashings on the same deck whose distance from the center point of the changed lashing is less than the preset maximum spacing parameter from the data snapshot extracted this time, and adding the other lashings and the changed lashing itself to the set of objects affected by the spacing rule.

[0008] Furthermore, the centroid distance is calculated using Euclidean distance; when the change type of the binding is deletion, the neighborhood query of the spacing range check rule is also triggered, adding the bindings that were originally adjacent to the deleted binding to the set of objects affected by the spacing rule.

[0009] Furthermore, the step of querying other lashings on the same deck whose distance from the center of gravity of the changed lashing is less than the preset maximum spacing parameter includes: grouping the lashings in the current data snapshot by deck number, establishing a two-dimensional spatial index for the center of gravity coordinates of each group of lashings, performing a range query based on the two-dimensional spatial index, and obtaining lashings whose distance from the center of gravity of the changed lashing is less than the preset maximum spacing parameter.

[0010] Furthermore, the analysis of the impact of the verification rule type on the verification scope also includes: for type constraint rules, filtering bundles whose change type is addition or modification and whose change field list contains category fields, and adding them to the set of objects affected by the type constraint rule; for specification validity rules, filtering bundles whose change type is addition or modification and whose change field list contains specification fields, and adding them to the set of objects affected by the specification validity rule.

[0011] Furthermore, each binding object in the incremental verification object set retains a list of affected rule numbers associated with it; the verification calculation of the associated rules is as follows: traverse the list of affected rule numbers associated with the binding object to find the rules that match the applicable conditions of the binding object, and execute the corresponding verification calculation logic.

[0012] Furthermore, the merging with historical verification results includes: for the combination of binding components and rules involved in the incremental verification results, the incremental verification results overwrite the corresponding records in the historical verification results; for binding components in the set of changed binding components whose change type is deletion, their corresponding records in the historical verification results are marked as invalid.

[0013] Furthermore, the change tracing tag includes the identifier of the changed bundle that triggered the change in verification status, the change type, and the change field; when the verification status of the bundle object changes due to its own change, the change tracing tag points to the change record of the bundle itself; when the bundle object is included in the verification scope and its status changes due to changes of other bundles in the neighborhood, the change tracing tag points to the change record of the changed bundle that triggered the neighborhood query.

[0014] This invention discloses an automatic verification system for ship lashing components based on a data center, used to perform the above-mentioned method, including: a data extraction module, used to obtain lashing component design data from a 3D design platform and convert it into general format data, generate a snapshot of the extracted data and write it into the data center, and read historical data snapshots at the same time; The change identification module is used to compare the current data snapshot with the historical data snapshot field by field, using the unique identifier of the binding as the association key, and generate a set of changed bindings containing change type labels and a list of changed fields; The impact analysis module is used to analyze the scope of impact based on the set of changed binding components according to the type of verification rule, and to generate an incremental set of verification objects by merging and deduplicating the objects affected by each rule. The incremental verification module is used to perform verification calculations on the bundled objects in the incremental verification object set according to the associated rules, and then persistently store the incremental verification results after merging them with the historical verification results. The change traceability module is used to compare incremental verification results with historical verification results, extract status change records, attach change traceability tags, and store them in the verification change traceability table.

[0015] The beneficial effects of this invention are as follows: This invention accurately identifies the changed bundle set by performing a field-by-field comparison based on the unique identifier of the bundle between the current extracted data snapshot and historical data snapshots, thus narrowing the verification input scope from all bundles to change-related objects. Furthermore, it employs spatial neighborhood query and change field-level matching to filter and determine affected objects for different verification rule types, ensuring that verification calculations are performed only on bundles truly affected by the change. This solves the technical problem of unnecessary computational resources and verification time being consumed by repetitive full-scale verification, achieving the technical effect of reducing the scope of verification calculations. Simultaneously, by directly associating verification status change records with the bundle identifier, change type, and change field that triggered the change to form a change tracing tag and persistently storing it, it solves the technical problem that designers cannot directly locate the source of the change's impact from the query interface, achieving the technical effect of allowing designers to directly obtain the verification status changes and their sources caused by the current change through a web interface. Attached Figure Description

[0016] Figure 1 This is a flowchart of an automatic verification method for ship lashing components based on a data center, provided in an embodiment of the present invention. Detailed Implementation

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

[0018] At least one embodiment of the present invention discloses an automatic verification method for ship lashing components based on a data center, see [link to relevant documentation]. Figure 1 This includes the following steps: Step S1: Obtain the current data snapshot and historical data snapshot.

[0019] The data center's scheduled extraction task retrieves the original design data of the binding components at the current moment in batches from the database interface of the 3D design platform. Following field mapping rules, it transforms the original design data into a universally formatted data stored uniformly in the data center, generates a snapshot of the extracted data, and writes it to the data center. Simultaneously, it reads the historical data snapshot persistently stored from the data center for the previous extraction task.

[0020] It should be noted that the above field mapping rules are pre-configured lookup tables used to convert the data field names and formats specific to the 3D design platform into corresponding fields in the data center's general format. General format data must at least include the lashing component's unique identifier (ObjectID), its deck number, center of gravity coordinates, type field, and specification field.

[0021] Step S2: Based on the current data snapshot and the historical data snapshot, compare each field to generate a set of change bindings.

[0022] Using the unique identifier ObjectID of the binding component as the association key, perform a field-by-field comparison operation between the current data snapshot and historical data snapshots. Step S2 may specifically include: Step S201: Mark records that exist only in this data snapshot as new ties.

[0023] Step S202: Mark records that only exist in historical data snapshots as deleted bundles.

[0024] Step S203: Mark records that exist in both snapshots but at least one attribute field value has changed as modified binders.

[0025] Step S204: Summarize the newly added, deleted, and modified bundles to generate a set of changed bundles. Attach a change type label and a list of change fields to each change record and store the set of changed bundles in the data center change record table.

[0026] It should be noted that the above change type labels are enumeration values, and the value range includes three types: "Add", "Delete", and "Modify". The above change field list is a collection of attribute field names that record the specific numerical changes in the modified binding. For example, when the center of gravity coordinates and specification field of a binding change simultaneously, the change field list includes the center of gravity coordinate field name and the specification field name.

[0027] Step S3: Based on the analysis of the change in the set of binding components, determine the scope of influence of the verification rules and generate an incremental set of verification objects.

[0028] For each change record in the changed binding set, analyze its impact on the verification scope based on the verification rule type. Step S3 may specifically include: Step S301: For the spacing range check rules, obtain the deck number to which each changed lashing piece belongs, and query from the data snapshot extracted this time the distance between the center of gravity point of the changed lashing piece and the maximum spacing parameter on the same deck. Other binding elements are added to the set of objects affected by the spacing rules. The maximum spacing parameter preset in the spacing range check rules.

[0029] Furthermore, the aforementioned modified binding element itself is also added to the set of objects affected by the spacing rules to ensure that the spacing relationship between the modified binding element and its neighboring binding elements is re-verified.

[0030] Step S302: For type constraint rules, filter the binders whose change type is "add" or "modify" and whose change field list contains the category field, and add them to the set of objects affected by the type constraint rules.

[0031] Step S303: For specification validity rules, filter bundles whose change type is "addition" or "modification" and whose change field list contains specification fields, and add them to the set of objects affected by the specification validity rules.

[0032] Step S304: Merge the set of objects affected by the spacing rule, the set of objects affected by the type constraint rule, and the set of objects affected by the specification validity rule, perform deduplication according to ObjectID, and generate an incremental verification object set.

[0033] Furthermore, each bundle object in the incremental verification object set retains a list of the affected rule numbers associated with it, so that subsequent step S4 only performs rule verification on the bundle associated with it, rather than traversing all valid rules.

[0034] It should be noted that the calculation of the centroid distance in step S301 above uses Euclidean distance, taking the centroid coordinates of the changed lashing as the center, and calculating the distance between the centroid coordinates of other lashings on the same deck and this center. When a lashing is deleted, the spacing relationship between it and its adjacent lashings may change. Therefore, the deletion of a changed lashing also triggers a neighborhood query of the spacing rules.

[0035] In this embodiment of the application, to avoid traversing all lashings on the entire deck for neighborhood queries based on spacing rules, step S301 can also use a spatial index to accelerate the query. Specifically, after grouping the lashings in the current data snapshot by deck number, a two-dimensional spatial index is established for the centroid coordinates of each group of lashings. Based on the two-dimensional spatial index, a range query is performed to obtain the lashings whose centroid distance is less than [a certain value]. A collection of lashing components.

[0036] Step S4: Perform rule verification on the incremental verification object set and merge it with the historical verification results to generate the latest verification result.

[0037] Step S4 may specifically include: Step S401: For each binding object in the incremental verification object set, iterate through the list of affected rule numbers associated with that binding object to find rules that match the applicable conditions of that binding object, execute the corresponding verification calculation logic, and generate incremental verification results. Each incremental verification result includes the binding object ObjectID, rule number, and verification status.

[0038] Step S402: Read the stored historical verification results from the data center. For the combination of bindings and rules involved in the incremental verification results, overwrite the corresponding records in the historical verification results with the incremental verification results.

[0039] Step S403: For the bindings in the set of changed bindings whose change type is deletion, mark their corresponding records in the historical verification results as invalid.

[0040] Step S404: The updated verification result is used as the latest verification result and persistently stored in the data center.

[0041] Step S5: Compare the incremental verification results with the historical verification results to generate a verification change traceability record with a traceability tag.

[0042] Step S5 may specifically include: Step S501: Compare the incremental verification results with the historical verification results before merging using the combination key of the binding object ID and the rule number, and extract the records where the verification status has changed. Verification status changes include changing from pass to fail, changing from fail to pass, and adding a new fail item.

[0043] Step S502: Attach a change traceability label to each status change record. The change traceability label includes the change binding identifier that triggered the change in the verification status, the change type, and the change field.

[0044] Step S503: Persistently store the status change records with change source tags in the verification change traceability table in the data center. The web query interface reads the verification change traceability table data from the data center and displays the records whose status changed during this verification and their corresponding change sources to the designers in a highlighted manner.

[0045] It should be noted that the above-mentioned method of associating change tracing tags is obtained by tracing back the change records associated with each bundle object in the incremental verification object set. When a bundle object changes its verification status due to its own changes, the change tracing tag directly points to the change record of that bundle itself; when a bundle object is included in the spacing rule verification scope and its status changes due to changes of other bundles in its neighborhood, the change tracing tag points to the change record of the bundle that triggered the neighborhood query.

[0046] In this embodiment of the application, in order to enable designers to filter verification change information according to different dimensions, step S503 further includes: establishing a multi-dimensional index for the verification change traceability table by change type, by deck number, and by rule number, and providing corresponding filtering condition entry points on the WEB query interface, so that designers can quickly locate the verification status change records that need attention by deck or by rule type.

[0047] On the other hand, the present invention also proposes an automatic verification system for ship lashing components based on a data center, comprising: The data extraction module is used to obtain the original design data of the binding parts in batches from the database interface of the 3D design platform, convert it into general format data according to the field mapping rules, generate the data snapshot of this extraction and write it to the data center, and at the same time read the historical data snapshot.

[0048] The change identification module is used to compare the current data snapshot with historical data snapshots field by field, using the unique identifier of the binding as the association key, and generate a set of changed bindings containing change type labels and a list of changed fields.

[0049] The impact analysis module is used to analyze the scope of impact based on the changed binding set according to the verification rule type, and generate an incremental verification object set.

[0050] The incremental verification module is used to perform verification calculations based on matching rules on the binding objects in the incremental verification object set, and then persistently store the incremental verification results after merging them with the historical verification results.

[0051] The change traceability module is used to compare incremental verification results with historical verification results, extract status change records, attach change traceability tags, and store them in the verification change traceability table for the web query interface to read and display.

[0052] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0053] This invention, through step S2, performs a field-by-field comparison based on ObjectID between the current extracted data snapshot and historical data snapshots to accurately identify the set of added, modified, and deleted binding component changes, thus narrowing the input scope of subsequent verification from all binding components to change-related objects. Further, step S3 uses spatial neighborhood queries to determine affected objects based on spacing range checks, and uses change field-level matching to filter and determine affected objects based on type constraint rules and specification validity rules. This ensures that the verification calculation in step S4 is performed only on binding components truly affected by the changes, avoiding repeated verification of unchanged binding components, thereby reducing computational resource consumption and verification time. Simultaneously, step S5 creates a change traceability tag by directly associating the verification status change record with the specific binding component identifier, change type, and change field that triggered the change, and persistently stores this tag in the verification change traceability table. This allows designers to directly obtain the verification status changes and their sources caused by the current change through a web interface, eliminating the need for manual comparison of the two verification results.

[0054] The following application examples are proposed: A shipbuilding company is currently working on the overall layout of deck lashing components for a multipurpose cargo ship. The ship has three cargo decks and approximately 350 lashing components. One morning, designers made localized optimization adjustments to the C deck area, involving adding one lashing component, modifying the attribute parameters of two lashing components, and deleting one lashing component. The remaining lashing components remained unchanged. A scheduled data extraction task was triggered at 10:00 AM that day, retrieving the latest lashing component data from the 3D design platform.

[0055] The implementation process of step S1: The data center periodically extracts data from the 3D design platform's database interface, batch-retrieving the raw field data of all 350 lashing components at the current moment. Following pre-configured field mapping rules, the extraction task converts field names from the 3D design platform to the data center's common format, generating a snapshot of the extracted data. Simultaneously, it retrieves a historical data snapshot extracted and persistently stored at 10:00 AM the previous day from the data center. The following shows a comparison of the lashing components related to this change in Deck C between the two snapshots.

[0056] Table 1. Records of lashing devices on deck C in historical data snapshots Table 2. Records of lashing devices on deck C in this data snapshot. The implementation process of step S2: The change identification module uses ObjectID as the association key to perform a field-by-field comparison between the current extracted data snapshot and historical data snapshots. LF-C-053 exists only in the current snapshot and is marked as added; LF-C-051 exists only in historical snapshots and is marked as deleted; LF-C-047 exists in both snapshots, but the centroid coordinates change from (12, 8) to (13, 8) and the specification changes from M36 to M42, so it is marked as modified; LF-C-052 exists in both snapshots, but the centroid coordinates change from (20, 10) to (20, 11), so it is marked as modified; LF-C-048 has no changes in any field values ​​and is not included in the change set. Finally, a change bundle set is generated and stored in the data center change record table.

[0057] Table 3 Changes to the Set of Binding Components The implementation process of step S3: The impact analysis module analyzes the affected scope for each change record in the set of changed bindings, according to the rule type.

[0058] For spacing range checking rules, the preset maximum spacing parameter is used. To determine the query radius, a neighborhood query is performed on each of the four change records. This is the maximum spacing threshold configured in the rule. Taking LF-C-047 as an example, its centroid coordinates (13, 8) are the query center. In this snapshot of deck C, the query will retrieve items whose Euclidean distance is less than [a certain value]. Other bindings, the query results include LF-C-048 and LF-C-053. Although LF-C-051 is a deletion type, LF-C-052 and LF-C-053 are both in the neighborhood of its original coordinates (18, 7). Within this range, objects affected by the spacing rule are also included in the set of objects affected. In the neighborhood of the centroid coordinates (20, 11) of LF-C-052, both LF-C-048 and LF-C-053 are within... Within the scope, both have been included through neighborhood queries of other change records.

[0059] For type constraint rules, select bundles whose change type is "new" or "modified" and whose change field list includes the "category" field. LF-C-047 and LF-C-052 do not include the "category" field in their change field lists, while LF-C-053, being a new type, is directly included.

[0060] For specification validity rules, select bundles whose change type is "modification" and whose change field list contains the specification field. LF-C-047's change field list contains the specification field, so it is included in the set of objects affected by the specification validity rule. LF-C-052's change field list does not contain the specification field, so it is not included in this rule.

[0061] After merging the sets of objects affected by each rule and deduplicating them by ObjectID, an incremental verification object set is generated.

[0062] Table 4 Incremental Validation Object Set The implementation process of step S4: The incremental verification module performs verification calculations only on each bundle object in the incremental verification object set, traversing only the rules in its associated list of affected rule numbers that match its applicable conditions. After verification, an incremental verification result is generated and merged with the historical verification results already stored in the data center, using the combination key of ObjectID and rule number. For the deleted bundle LF-C-051, its corresponding record in the historical verification results is marked as invalid. The latest merged verification result is persistently stored in the data center.

[0063] Table 5 Incremental Verification Results Table 6. Corresponding records in historical verification results (before merging) The implementation process of step S5: The change tracing module compares the incremental verification results with the historical verification results before merging, using the combination key of ObjectID and rule number. The specification validity rule verification status of LF-C-047 changed from passed to failed; the spacing rule verification status of LF-C-052 changed from passed to failed; and all rules in LF-C-053 are newly added records. A change tracing tag is attached to each status change record, indicating the change bundle identifier, change type, and changed fields that triggered the status change. Records with tracing tags are stored in the data center's verification change tracing table, and are highlighted in the web query interface.

[0064] Table 7 Verification Change Tracking Record Data flow summary Throughout the process, data acquired from the 3D design platform was mapped to form a snapshot of the extracted data. After comparing it field-by-field with historical data snapshots, it converged into four change records. These change records were then expanded into four incremental verification objects after rule impact analysis, with each object only associated with the rules it was affected by. The incremental verification module performed six rule verifications on the four objects, significantly narrowing the verification calculation scope compared to traversing all rules across all 350 binding components. Finally, the status comparison stage identified four status change records from the six incremental verification results. Each record, through a traceability tag, points to the specific binding component that triggered the change and its modified content. Designers can directly locate the verification failures caused by the LF-C-047 specification modification and the impact of the LF-C-051 deletion on the LF-C-052 spacing verification on the web interface, without the need for manual comparison of the before-and-after verification results.

[0065] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. An automatic verification method for ship lashing components based on a data center, characterized in that, Includes the following steps: The design data of the binding components is obtained from the 3D design platform and converted into a common format data to generate a snapshot of the data extracted this time. At the same time, historical data snapshots are read from the data center. Using the unique identifier of the binding as the association key, perform a field-by-field comparison between the current data snapshot and the historical data snapshot to generate a set of changed bindings containing change type labels and a list of change fields; For each change record in the set of changed bindings, analyze its impact on the verification scope according to the verification rule type, and generate an incremental verification object set by merging and deduplicating the objects affected by each rule. Perform the associated rule verification calculation on the bundled objects in the incremental verification object set, generate the incremental verification result, and merge it with the historical verification result to generate the latest verification result; The incremental verification results are compared with the historical verification results by the combination key of the binding component identifier and the rule number. After the status change record is attached with the change traceability tag, it is stored in the verification change traceability table.

2. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, The field-by-field comparison includes: Records that exist only in the current data snapshot are marked as new bundles; records that exist only in historical data snapshots are marked as deleted bundles; records that exist in both snapshots but at least one attribute field value has changed are marked as modified bundles; the new bundles, deleted bundles and modified bundles are summarized to generate the change bundle set.

3. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, The analysis of the impact of the verification rule type on the verification range includes: For the spacing range check rule, obtain the deck number to which the changed lashing belongs, query other lashings on the same deck whose center of gravity is less than the preset maximum spacing parameter from the data snapshot extracted this time, and add the other lashings and the changed lashing itself to the set of objects affected by the spacing rule.

4. The automatic verification method for ship lashing components based on a data center according to claim 3, characterized in that, The centroid distance is calculated using Euclidean distance. When the change type of the binding is deletion, the neighborhood query of the spacing range check rule is also triggered, and the bindings that were originally adjacent to the deleted binding are added to the set of objects affected by the spacing rule.

5. The automatic verification method for ship lashing components based on a data center according to claim 3, characterized in that, The query includes other lashings on the same deck whose distance from the center of gravity of the changed lashing is less than the preset maximum spacing parameter, including: The lashing pieces in the data snapshot are grouped by deck number. A two-dimensional spatial index is established for the center of gravity coordinates of each group of lashing pieces. A range query is performed based on the two-dimensional spatial index to obtain lashing pieces whose distance from the center of gravity of the changed lashing piece is less than the preset maximum spacing parameter.

6. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, The analysis of the impact of the verification rule type on the verification range also includes: For type constraint rules, filter bundles whose change type is "add" or "modify" and whose change field list includes the category field, and add them to the set of objects affected by the type constraint rule; for specification validity rules, filter bundles whose change type is "add" or "modify" and whose change field list includes the specification field, and add them to the set of objects affected by the specification validity rule.

7. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, Each binding object in the incremental verification object set retains a list of affected rule numbers associated with it; the verification calculation of the associated rules is as follows: traverse the list of affected rule numbers associated with the binding object and find the rules that match the applicable conditions of the binding object, and execute the corresponding verification calculation logic.

8. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, The merging with historical verification results includes: For the combination of bindings and rules involved in the incremental verification results, the incremental verification results will overwrite the corresponding records in the historical verification results; for bindings in the set of changed bindings whose change type is deletion, their corresponding records in the historical verification results will be marked as invalid.

9. The automatic verification method for ship lashing components based on a data center according to claim 1, characterized in that, The change traceability label includes the change bundle identifier that triggered the change in verification status, the change type, and the change field; When the verification status of a rigging object changes due to its own modification, the change tracing tag points to the change record of the rigging itself; when a rigging object is included in the verification scope and its status changes due to changes of other rigging objects in the neighborhood, the change tracing tag points to the change record of the rigging object that triggered the neighborhood query.

10. A data center-based automatic verification system for ship lashing components, used to execute the data center-based automatic verification method for ship lashing components as described in any one of claims 1 to 9, characterized in that, include: The data extraction module is used to obtain the design data of the binding components from the 3D design platform and convert it into a common format data, generate a snapshot of the extracted data and write it to the data center, and read historical data snapshots at the same time. The change identification module is used to compare the current data snapshot with the historical data snapshot field by field, using the unique identifier of the binding as the association key, and generate a set of changed bindings containing change type labels and a list of changed fields; The impact analysis module is used to analyze the scope of impact based on the set of changed binding components according to the type of verification rule, and to generate an incremental set of verification objects by merging and deduplicating the objects affected by each rule. The incremental verification module is used to perform verification calculations on the bundled objects in the incremental verification object set according to the associated rules, and then persistently store the incremental verification results after merging them with the historical verification results. The change traceability module is used to compare incremental verification results with historical verification results, extract status change records, attach change traceability tags, and store them in the verification change traceability table.

Images