Batched data collaborative integration system for aerospace products

Abstract

The application discloses a batch data collaborative integration system for an aviation product, which acquires source instances and target instances with the same main code, constructs a state source evidence package containing replacement approval, allowed batches, allowed assembly positions, preceding processes and supplementary inspection conditions based on the source instances, and constructs an instance context signature containing actual batches, assembly positions, completed processes and inspection conclusions based on the target instances; consistency checking is performed to determine whether the target instance meets the replacement state effective prerequisite, and when the prerequisite is met, a state inheritance authorization record is generated and the replacement state is written back, and when the prerequisite is not met, a blocking reference record is generated and the writing back is prohibited; when the context of the target instance changes, the checking is triggered again and the blocking is converted to authorization. The system can control the state propagation boundary in the batch data collaborative process of the aviation product and reduce the risk of misinheritance of the replacement state.

Description

Technical Field

[0001] This application relates to the field of aviation product data processing technology, and in particular to a batch data collaborative integration system for aviation products. Background Technology

[0002] In the research, development, manufacturing, assembly, and quality control of aerospace products, it is usually necessary to coordinate the management of design data, process data, assembly data, and quality data. For the same master-coded component, different batches, assembly locations, process completion statuses, and inspection conclusions may result in different instance states.

[0003] For example, a component with the same master code can be used as a substitute part when it is in a certain batch and assembly position and meets the requirements of additional processes and supplementary inspections; however, it is not allowed to use the substitute part status when it is in another batch, another assembly position, or when the requirements of additional processes and supplementary inspections are not met. Similarly, the status of rework parts, restricted release status, etc., usually also have corresponding grounds for establishment and applicable boundaries.

[0004] In existing batch data collaborative processing, similar objects are often merged and written back using master codes, version information, or instance identifiers. When alternative, rework, or restricted release states on a source instance need to be propagated to other instances, if the state writing is performed solely based on master code consistency or instance affiliation, states that are only valid for specific batches, locations, processes, and inspection conditions may be incorrectly propagated to target instances that do not share the same validity prerequisites.

[0005] This could lead to incorrect inheritance of replacement status, incorrect propagation of rework status, or incorrect release of restricted release status, thereby affecting subsequent assembly release, process execution, quality traceability, and batch variation maintenance.

[0006] Therefore, how to construct a system for batch data collaboration scenarios of aviation products, control the state propagation boundary between different instances of the same master coded component, and prevent the state on the source instance from being erroneously propagated to the target instance that does not meet the effective premise during batch write-back has become a technical problem that needs to be solved in this field. Summary of the Invention

[0007] This application provides a batch data collaboration and integration system for aviation products to solve the problem that during the batch data collaboration process of aviation products, the alternative state of the same master coded component is easily propagated to instances that do not have the same effective premise, resulting in the incorrect inheritance of the alternative state.

[0008] To achieve the above objectives, this application adopts the following technical solution.

[0009] In a first aspect, this application provides a batch data collaborative integration system for aviation products, comprising: The module includes: instance acquisition module, state source evidence package construction module, instance context signature construction module, consistency verification module, state inheritance authorization module, and blocking reference record module. The instance acquisition module is used to acquire source instances with the same master code and at least one target instance, wherein the source instance is a component instance with a replacement state; The state source evidence package construction module is used to construct a state source evidence package based on the source instance; the instance context signature construction module is used to construct an instance context signature based on the target instance; The consistency verification module is used to verify the consistency between the state source evidence package and the instance context signature to determine whether the target instance meets the prerequisite for the alternative state to take effect. The state inheritance authorization module is used to generate a state inheritance authorization record corresponding to the target instance when the target instance meets the effective prerequisite, and write the alternative state back to the target instance; The blocking reference record module is used to generate a blocking reference record between the source instance and the target instance when the target instance does not meet the effective prerequisite, and to prevent the alternative state from being written back to the target instance.

[0010] In the aforementioned system, instead of treating the alternative state as a static label that can propagate directly along the main coding chain, the state source evidence package construction module constructs a state source evidence package around the source instance, and the instance context signature construction module constructs an instance context signature around the target instance. Then, the consistency verification module performs a consistency check on both before the alternative state is written back. The state inheritance authorization module only performs state inheritance authorization and alternative state write-back if the target instance meets the validity prerequisites. If the target instance does not meet the validity prerequisites, the blocking reference record module generates a blocking reference record and blocks the propagation of the alternative state. This design transforms the alternative state from a static state label into a conditional state with a basis for validity and applicable boundaries, thereby controlling the propagation boundaries of the alternative state during batch write-back and reducing the risk of erroneous inheritance of the alternative state.

[0011] In one possible design, the status source evidence package includes at least one of the following: source instance identifier, alternative approval identifier, set of permitted assembly locations, permitted batch range or validity range, conditions for completion of preceding processes, and conditions for passing supplementary inspections.

[0012] Therefore, the alternative states on the source instance can be transformed from a single state label into a set of evidence with a basis for establishment and applicable boundaries, so that subsequent consistency verification has a clear input basis and avoids coarse-grained propagation of alternative states based solely on the master code or version information.

[0013] In one possible design, the instance context signature includes at least one of the following: target instance identifier, actual batch information, actual assembly location information, completed process path information, and inspection conclusion information.

[0014] This design allows for a unified expression of the batch, location, process, and inspection context of the target instance at the current business moment, thereby enabling a structured determination of whether the target instance possesses the conditions for alternative state inheritance.

[0015] In one possible design, the consistency verification module includes the following functions: Verify whether the actual batch information is consistent with the allowed batch range or validity range; verify whether the actual assembly location information is consistent with the allowed assembly location set; verify whether the completed process path information meets the conditions for completing the preceding process; verify whether the inspection conclusion information meets the conditions for passing the supplementary inspection.

[0016] This design allows for the refinement of the effective conditions into four categories of constraints: batch, location, process, and inspection. Consistency checks are then performed item by item according to these constraints, reducing misjudgments of alternative states during batch write-back.

[0017] In one possible design, when the at least one target instance includes multiple target instances, the state inheritance authorization module is specifically used to: determine a subset of target instances from the multiple target instances that satisfy the effective prerequisite; generate a state inheritance authorization record for each target instance in the subset of target instances; and write back the alternative state only to the target instance carrying the state inheritance authorization record.

[0018] With this design, in batch object scenarios, instead of writing the replacement state on the source instance to all objects with the same main code, a subset of target instances that meet the conditions for effectiveness is first selected, and then an authorization write-back is performed on the subset of target instances, thereby limiting the scope of state propagation to the set of instances that meet the conditions.

[0019] In one possible design, the state inheritance authorization record includes at least: source instance identifier; target instance identifier; satisfied validity prerequisites; and authorization validity time.

[0020] This design allows for the retention of clear authorization criteria and effective dates for executed state inheritance behaviors, facilitating subsequent verification of the legitimate propagation relationship between the source instance and the target instance.

[0021] In one possible design, the blocking reference record includes at least: a source instance identifier; a target instance identifier; and unmet activation prerequisites.

[0022] With this design, even if the target instance does not currently meet the prerequisites for the alternative state to take effect, the system will not directly discard the association between the source instance and the target instance. Instead, it will retain the restricted relationship and the reason for blocking by blocking the reference record, thereby providing a basis for subsequent re-verification.

[0023] In one possible design, the system further includes a re-inspection processing module, which is used to re-trigger the consistency verification module to perform consistency verification between the source instance and the target instance corresponding to the blocking reference record after the blocking reference record is generated, in response to changes in the actual batch information, actual assembly location information, completed process path information or inspection conclusion information of the target instance.

[0024] This design allows for the automatic restart of the alternative state propagation decision process after the target instance's business context changes, thereby avoiding the permanent blocking of subsequent legitimate propagation due to unmet prior conditions.

[0025] In one possible design, the state inheritance authorization module is further configured to, after a new consistency check, update the blocking reference record to a state inheritance authorization record if the target instance meets the effective prerequisite, and write the alternative state back to the target instance.

[0026] This design allows for the transition from a blocked state to an authorized state after subsequent conditions are met, thus enabling the write-back process of the alternative state to take into account both the initial blocking control and the subsequent dynamic release.

[0027] In one possible design, the system further includes a log and recording module, which is used to record information such as state source evidence package generation information, instance context signature generation information, consistency verification results, state inheritance authorization records, blocking reference records, and re-examination processing results.

[0028] This design allows for the auditing and backtracking of the control process for the propagation of alternative states, facilitating subsequent quality analysis and accountability.

[0029] In one possible design, the data corresponding to the source instance and the target instance are derived from at least two of the design data, process data, assembly data, and quality data, and the alternative state includes at least one of the alternative part state, rework part state, and restricted release state.

[0030] This design defines the typical data source range and applicable state range of this application, enabling it to adapt to the state propagation control requirements of aerospace products in collaborative scenarios of design, process, assembly, and quality.

[0031] Secondly, this application provides a management device, including a processor and a memory, wherein the memory stores program instructions, and the processor executes the program instructions to implement the functions of the various modules of the system as described in the first aspect and its various designs.

[0032] Thirdly, this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the functions of the modules of the system as described in the first aspect and its various designs.

[0033] The technical effects and advantages of the present invention for a batch data collaborative integration system for aviation products are as follows: This invention transforms the alternative states on the source instance into a state source evidence package containing alternative approval, applicable batch, assembly location, preceding process, and supplementary inspection conditions, and performs consistency verification in conjunction with the batch, location, process, and inspection context of the target instance. Instead of relying solely on the master code or instance identifier for batch write-back, this invention avoids the problem of incorrect inheritance of alternative states.

[0034] For target instances that meet the prerequisites for effectiveness, the system generates a state inheritance authorization record and performs state write-back; for target instances that do not meet the prerequisites for effectiveness, the system generates a blocking reference record and retains the reason for non-compliance, thereby making the state propagation process traceable and auditable.

[0035] Meanwhile, the present invention also re-triggers the verification after the target instance context changes through the re-verification processing module, which can realize the conversion from the blocking state to the authorized state when the subsequent conditions are completed, thereby taking into account the security, accuracy and dynamic adaptability of state propagation, and improving the quality control capability and data consistency in the process of batch data collaborative integration of aviation products. Attached Figure Description

[0036] Figure 1 This application provides an overall architecture diagram of a batch data collaborative integration system for aviation products.

[0037] Figure 2 A flowchart illustrating a method for batch data collaborative integration of aviation products, provided in this application embodiment.

[0038] Figure 3 This is a schematic diagram illustrating the composition of a state source evidence package provided in an embodiment of this application.

[0039] Figure 4 This is a schematic diagram illustrating the formation of an instance context signature, as provided in an embodiment of this application.

[0040] Figure 5 This is a logic diagram for verifying the consistency between a state source evidence package and an instance context signature, as provided in an embodiment of this application.

[0041] Figure 6 This is a schematic diagram illustrating batch target instance filtering and status write-back control provided in an embodiment of this application.

[0042] Figure 7 This is a state transition diagram for blocking, re-detection, and sublicense provided in an embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and beneficial effects of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to specific implementation methods. It should be understood that the following specific implementation methods are only used to explain this application and are not intended to limit the scope of protection of this application.

[0044] The system applicable to the embodiments of this application may include a management device, a design data source, a process data source, an assembly data source, and a quality data source. The management device can communicate with the design data source, process data source, assembly data source, and quality data source to acquire data related to source instances and target instances, and to perform propagation control of alternative states. The management device may be a server, a workstation, a centralized control platform, or a management platform composed of a server and terminal devices.

[0045] like Figure 1 As shown in the embodiments of this application, the batch data collaborative integration system for aviation products includes design data sources, process data sources, assembly data sources, quality data sources, and management equipment; the management equipment internally includes an instance acquisition module, a state source evidence package construction module, an instance context signature construction module, a consistency verification module, a state inheritance authorization module, a blocking reference record module, a re-inspection processing module, and a log and record module.

[0046] Specifically, the instance acquisition module provides source instance and target instance data to the state source evidence package construction module and the instance context signature construction module, respectively; The consistency verification module calls the state source evidence package output by the state source evidence package construction module and the instance context signature output by the instance context signature construction module to complete the validity prerequisite judgment; The state inheritance authorization module and the blocking reference record module execute different branch processing based on the consistency check results; After detecting a change in the target instance context, the re-inspection processing module re-invokes the state source evidence package construction module, the instance context signature construction module, and the consistency verification module to complete the re-inspection. The logging and recording module is used to record the running results of the above modules.

[0047] In this embodiment, the source instance can be a component instance that has been approved to be assigned a replacement state, and the target instance can be a component instance with the same main code as the source instance and whose inheritance of the replacement state is to be determined. The replacement state can be a replacement part state, a rework part state, or a restricted release state. As a higher-level concept, the replacement state is used to collectively refer to the instance states that need to be controlled and propagated according to the applicable boundaries.

[0048] The state source evidence package is used to characterize the basis and applicable boundaries of the alternative state on the source instance; the instance context signature is used to characterize the batch, location, process and inspection context of the target instance at the current business moment; the state inheritance authorization record is used to characterize that the target instance has been allowed to inherit the alternative state; the blocking reference record is used to characterize that the target instance does not currently meet the prerequisites for the alternative state to take effect, but still retains the restricted association relationship between the source instance and the target instance.

[0049] The following describes the batch data collaborative integration system for aviation products provided in this application embodiment, in conjunction with the system operation process. For example... Figure 2 As shown, the operation process of the system may include steps S101 to S105. It should be understood that the steps are only used to illustrate the working process between the various modules of the system and do not constitute an additional limitation on the scope of system protection.

[0050] S101, the instance acquisition module acquires a source instance and at least one target instance with the same main code. The source instance is a component instance with a substitute state, and the target instance is a component instance for which a substitute state propagation judgment is to be performed.

[0051] In some implementations, the instance acquisition module can read the master code, instance identifier, batch identifier, assembly location identifier, process execution record, and inspection record from design data, process data, assembly data, and quality data to determine the source instance and target instance. When different identifiers exist for the same instance in multiple data sources, the instance acquisition module can determine a unified instance identifier according to a preset alignment rule. The alignment rule could be, for example: preferentially using the unique instance identifier recorded in the quality data; if no unique instance identifier exists in the quality data, using the installation instance identifier from the assembly data; if no installation instance identifier exists in the assembly data either, then using a combination of the master code, batch identifier, and assembly location identifier as the unified instance identifier.

[0052] In some implementations, having the same master code means that the source instance and the target instance correspond to the same component master code, but the source instance and the target instance may differ in batch, assembly position, process completion status, and inspection conclusion.

[0053] When acquiring target instances, the instance acquisition module can acquire multiple target instances with the same main code as the source instance at once to support unified judgment in batch scenarios.

[0054] S102, the state source evidence package construction module constructs a state source evidence package based on the source instance. The state source evidence package is used to characterize the basis for the establishment of alternative states on the source instance and the boundaries by which the alternative states are allowed to propagate.

[0055] In some implementations, such as Figure 3 As shown, the status source evidence package includes at least a source instance identifier, a substitute approval identifier, a set of permitted assembly locations, a permitted batch range or validity range, prerequisite process completion conditions, and supplementary inspection pass conditions. Specifically, the source instance identifier uniquely identifies a source instance with a substitute status; the substitute approval identifier indicates that the source instance has received substitute approval, rework approval, or restricted release approval; the set of permitted assembly locations indicates the permitted assembly locations for the substitute status; the permitted batch range or validity range indicates the permitted batch interval, batch set, or effective validity interval for the substitute status; the prerequisite process completion conditions indicate the processes that the target instance must complete before inheriting the substitute status; and the supplementary inspection pass conditions indicate the inspection pass requirements that the target instance must meet before inheriting the substitute status.

[0056] The validity range can be composed of the start and end time of the status taking effect, the set of batches to which the status applies, or the interval between batches to which the status applies. When the validity range is represented by a time range, the consistency verification module reads the time of the business occurrence corresponding to the target instance and determines whether it is within the time range. When the validity range is represented by a set of batches or a interval between batches, the consistency verification module reads the actual batch information of the target instance and determines whether it falls into the set of batches or the interval between batches.

[0057] In some implementations, the state source evidence package construction module can extract the aforementioned evidence content from different data sources according to data item categories. For example: Source instance identifier and allowed batch range or source instance identifier and validity range can be extracted from design data or master data; Alternative approval identifiers can be extracted from quality data; The set of assembly locations can be extracted from the assembly data; The conditions for completing the preceding process can be extracted from the process data; Supplementary inspection pass criteria can be extracted from the quality data.

[0058] When the same piece of evidence exists in multiple data sources, the state source evidence package construction module can select the final value according to a preset confidence order; the confidence order can be, for example, quality data higher than assembly data, assembly data higher than process data, and process data higher than design data.

[0059] In some implementations, the allowed batch range or validity range can be represented by an enumerated list or by an interval from the start batch to the end batch. For example, the allowed batch range can be represented as batch A1 to batch A3, or it can be represented as batch A1, batch A2, and batch A5.

[0060] The set of allowed assembly locations can be represented by an assembly location code set, such as P03, P04, and P07.

[0061] The conditions for completing the preceding process can be represented by a set of process codes, such as G12 and G18.

[0062] Supplementary inspection pass conditions can be represented by a set of inspection item codes plus inspection result requirements. For example, the result of inspection J05 is pass, or both J05 and J09 are pass.

[0063] In some implementations, if a source instance lacks an alternative approval identifier, or lacks any of the necessary items among the allowed batch range or validity range, allowed assembly location set, prerequisite completion conditions, and supplementary inspection pass conditions, the state source evidence package construction module will not treat that source instance as a propagable source instance. In this embodiment, the alternative approval identifier, allowed batch range or validity range, allowed assembly location set, prerequisite completion conditions, and supplementary inspection pass conditions are all considered necessary evidence items. This design avoids directly performing propagation judgments on alternative states when source evidence is incomplete.

[0064] In some implementations, after completing the construction of the state source evidence package, the state source evidence package construction module can store the state source evidence package in the evidence cache area or the evidence database, and record the evidence package generation time and evidence item source in the log and recording module, so as to facilitate subsequent auditing and re-examination.

[0065] S103, the instance context signature construction module constructs an instance context signature based on the target instance. The instance context signature is used to characterize the instance identity and current context state of the target instance at the current business moment.

[0066] In some implementations, such as Figure 4 As shown, the instance context signature includes at least the target instance identifier, actual batch information, actual assembly location information, completed process path information, and inspection conclusion information.

[0067] Among them, the target instance identifier is used to uniquely identify the target instance; the actual batch information is used to indicate the current batch to which the target instance belongs; the actual assembly location information is used to indicate the current assembly or planned assembly location of the target instance; the completed process path information is used to indicate the set of processes or process sequence that the target instance has completed; and the inspection conclusion information is used to indicate the inspection results related to the current replacement state of the target instance.

[0068] In some implementations, the instance context signature building module can construct the instance context signature in the following manner: Extract the actual assembly location information of the target instance from the assembly data; Extract the actual batch information of the target instance from batch management data or manufacturing execution data; Extract the completed process path information of the target instance from the process execution record; Extract inspection conclusion information of target instances from quality data; The target instance identifier, actual batch information, actual assembly location information, completed process path information, and inspection conclusion information are combined to form an instance context signature.

[0069] In some implementations, the completed process path information can be represented by a process sequence ordered by completion time, or by a set of process codes. When the process completion order affects the validity prerequisite judgment, the instance context signature construction module uses a process sequence to represent the completed process path information. When the process completion order does not affect the validity prerequisite judgment, the instance context signature construction module uses a set of process codes to represent the completed process path information.

[0070] In some implementations, the inspection conclusion information may include statuses such as not inspected, under inspection, passed, failed, or released with concession.

[0071] In this embodiment, when the supplementary inspection pass condition requires a certain inspection item to pass, the inspection condition is considered to be met only if the inspection conclusion corresponding to the inspection item is passed; that is, if the inspection conclusion is not inspected, in progress, not passed, or missing, the inspection condition is considered not met.

[0072] In some implementations, if the target instance lacks any of the necessary items such as actual batch information, actual assembly location information, completed process path information, or inspection conclusion information, the instance context signature construction module can still generate an instance context signature, but the missing item will be marked as to be supplemented, and the missing item will be judged as not satisfying in the subsequent consistency check; thus, through this design, the propagation of the alternative state due to data missing can be avoided without losing the target instance.

[0073] S104, the consistency verification module performs consistency verification on the state source evidence package and the instance context signature to determine whether the target instance meets the prerequisites for the effectiveness of the alternative state.

[0074] In this embodiment, the prerequisites for the effectiveness of the alternative state include batch prerequisites, location prerequisites, process prerequisites, and inspection prerequisites. Specifically, the batch prerequisite determines whether the target instance is within the allowed batch range or validity range; the location prerequisite determines whether the target instance is located within the allowed assembly location set; the process prerequisite determines whether the target instance has completed the process required by the preceding process completion conditions; and the inspection prerequisite determines whether the target instance meets the supplementary inspection pass conditions. In this embodiment, the batch prerequisite, location prerequisite, process prerequisite, and inspection prerequisite are all necessary prerequisites. If any necessary prerequisite is not met, the target instance does not meet the prerequisites for the effectiveness of the alternative state.

[0075] In some implementations, the consistency verification module performs consistency verification in the following order: first, batch consistency verification; second, location consistency verification; third, process satisfaction verification; and finally, inspection satisfaction verification. The consistency verification module can also perform the above four types of verification in parallel, but when generating the verification results, the results of each of the four types of verification still need to be provided separately.

[0076] In some implementations, the batch consistency verification rules can be: When the actual batch information of the target instance falls within the allowed batch range or validity range of the state source evidence package, the batch prerequisite is determined to be met. When the actual batch information of the target instance does not fall within the allowed batch range or validity range, the batch prerequisite is determined to be unmet.

[0077] For example, if the allowed batch range is batch A1 to batch A3, and the target instance's current batch is A2, then the batch prerequisite is met; if the target instance's current batch is A4, then the batch prerequisite is not met.

[0078] In some implementations, the location consistency verification rule can be: The location prerequisite is satisfied when the actual assembly location information of the target instance belongs to the set of allowed assembly locations in the state source evidence package. When the actual assembly location information of the target instance does not belong to the set of allowed assembly locations, the location prerequisite is not met.

[0079] For example, if the set of allowed assembly positions is P03 and P04, then the position prerequisite is satisfied if the current assembly position of the target instance is P03; otherwise, the position prerequisite is not satisfied.

[0080] In some implementations, the process fulfillment verification rule can be as follows: When the prerequisite process completion conditions in the state source evidence package are represented by a set of process codes, if all process codes in the prerequisite process completion conditions are included in the completed process path information of the target instance, then the process prerequisite is determined to be satisfied; otherwise, the process prerequisite is determined to be unsatisfactory. When the prerequisite process completion conditions in the state source evidence package are represented by a process sequence, if the completed process path information of the target instance contains a completion order consistent with the process sequence, then the process prerequisite is determined to be satisfied; otherwise, the process prerequisite is determined to be unsatisfactory. For example, if the prerequisite process completion conditions are G12 and G18, and the target instance has completed processes including G12, G16, and G18, then the process prerequisite is satisfied; if the target instance has only completed G12, then the process prerequisite is unsatisfactory.

[0081] In some implementations, the verification satisfaction check rule can be: when the supplementary verification pass condition in the state source evidence package requires one or more specified verification items to pass, the verification premise is deemed satisfied only if the verification conclusion of each specified verification item corresponding to the target instance is passed; otherwise, the verification premise is deemed not satisfied. For example, if the supplementary verification pass condition is that both J05 and J09 pass, then the verification premise is satisfied if both J05 and J09 of the target instance pass; if J05 passes but J09 is not detected, then the verification premise is not satisfied.

[0082] In some implementations, such as Figure 5 As shown, the consistency verification module generates a verification result object after completing four types of prerequisite verifications. The verification result object includes at least the target instance identifier, batch verification result, location verification result, process verification result, inspection verification result, and comprehensive judgment result. When the batch verification result, location verification result, process verification result, and inspection verification result are all satisfied, the comprehensive judgment result is satisfied. If any one of them is not satisfied, the comprehensive judgment result is not satisfied.

[0083] S105, Branch processing based on consistency verification results; that is, when the target instance meets the prerequisites for the alternative state to take effect, the state inheritance authorization module generates a state inheritance authorization record and writes the alternative state back to the target instance; when the target instance does not meet the prerequisites for the alternative state to take effect, the blocking reference record module generates a blocking reference record and prohibits the writing of the alternative state back to the target instance.

[0084] In some implementations, if at least one target instance includes multiple target instances, the consistency verification module performs consistency verification on each of the multiple target instances and determines a subset of target instances whose comprehensive judgment result is satisfied. The state inheritance authorization module performs state inheritance authorization and alternative state write-back only for the target instances in the subset of target instances. Figure 6 As shown, in a batch target instance scenario, target instances that meet the conditions enter the authorization write-back branch, while target instances that do not meet the conditions enter the blocking branch.

[0085] In some implementations, the state inheritance authorization record includes at least the source instance identifier, the target instance identifier, the satisfied prerequisites for effectiveness, and the authorization effectiveness time. After generating the state inheritance authorization record, the state inheritance authorization module writes the alternative state on the source instance to the target instance, and submits the alternative state write-back time, write-back object, and corresponding authorization record identifier to the log and recording module for storage.

[0086] In some implementations, the blocking reference record includes at least the source instance identifier, the target instance identifier, the unmet prerequisites for effectiveness, the blocking generation time, and the current context summary of the target instance; the blocking reference record does not trigger alternative state writing, but is only used to retain the restricted association between the source instance and the target instance and the current blocking reason.

[0087] The logging and recording module records the generation results of the blocking reference record.

[0088] In some implementations, the same source instance can correspond to multiple blocking reference records, and the same target instance can also correspond to multiple blocking reference records; the blocking reference record module can use the source instance identifier, the target instance identifier, and the blocking generation time as the unique identifier of the blocking reference record.

[0089] When a block occurs again between the same source instance and the same target instance at a later time, the blocking reference record module can generate a new version of the blocking reference record and retain the historical version as a history record, instead of directly overwriting the original blocking reference record.

[0090] In some implementations, after blocking the generation of reference records, the re-inspection processing module monitors whether at least one of the following changes: the actual batch information, the actual assembly position information, the completed process path information, and the inspection conclusion information of the target instance. For example, the re-inspection processing module can trigger a re-inspection event when the target instance completes a new process, the supplementary inspection changes from uninspected to passed, the target instance is transferred to an allowed batch, or the target instance is adjusted to an allowed assembly position.

[0091] In some implementations, after a re-inspection event, the re-inspection processing module re-requests the state source evidence package construction module to obtain the state source evidence package corresponding to the source instance, re-requests the instance context signature construction module to construct the instance context signature corresponding to the target instance, and then re-triggers the consistency verification module to execute the consistency verification described in step S104. In this embodiment, the re-verification re-verifies all batch prerequisites, location prerequisites, process prerequisites, and inspection prerequisites, rather than only verifying the previously unmet effective prerequisites. This approach avoids overlooking new conflict conditions due to only verifying partial prerequisites.

[0092] In some implementations, if the target instance meets the prerequisites for the alternative state after re-verification, the state inheritance authorization module updates the corresponding blocking reference record to a state inheritance authorization record and performs an alternative state write-back. During the update process, the blocking reference record module retains the historical version of the original blocking reference record, while the state inheritance authorization module adds a new state inheritance authorization record to characterize the change process of the target instance from a blocked state to an authorized state. If the target instance still does not meet the prerequisites for the alternative state after re-verification, the blocking reference record module retains the original blocking reference record or generates a new blocking reference record version, and submits the re-verification time and the prerequisites that are still not met to the log and recording module for storage.

[0093] In some implementations, such as Figure 7 As shown, the system achieves the state transition process of the three states of blocking, re-checking, and sub-authorization through the cooperation of the blocking reference record module, the re-checking processing module, the consistency verification module, and the state inheritance authorization module.

[0094] The logging and recording module records every blocking, re-inspection, and sub-authorization result to support subsequent auditing and backtracking.

[0095] The following example illustrates the operation of the system in this application. The main code of source instance R1 is C100. Source instance R1 has obtained the alternative approval identifier AP01. Its status source evidence package includes: allowed batch range of batches A1 to A2, allowed assembly location set of P03 and P04, prerequisite process completion conditions of G12 and G18, and supplementary inspection pass condition of J05. The instance acquisition module acquires three target instances T1, T2, and T3 with the same main code as source instance R1. Specifically, the actual batch of target instance T1 is A1, the actual assembly location is P03, completed processes include G12 and G18, and the J05 inspection result is passed; the actual batch of target instance T2 is A1, the actual assembly location is P05, completed processes include G12 and G18, and the J05 inspection result is passed; the actual batch of target instance T3 is A3, the actual assembly location is P03, completed processes include G12 and G18, and the J05 inspection result is not inspected.

[0096] The State Source Evidence Package Construction Module constructs a state source evidence package for source instance R1. The Instance Context Signature Construction Module constructs instance context signatures for target instances T1, T2, and T3 respectively. The Consistency Verification Module performs consistency verification on source instance R1 and target instances T1, T2, and T3 respectively. For target instance T1, the batch prerequisite, location prerequisite, process prerequisite, and inspection prerequisite are all satisfied. Therefore, the State Inheritance Authorization Module generates a state inheritance authorization record for target instance T1 and writes back the alternative state corresponding to source instance R1 to target instance T1. For target instance T2, the location prerequisite is not satisfied. Therefore, the Blocking Reference Record Module generates a blocking reference record for source instance R1 and target instance T2 and prohibits the writing back of the alternative state to target instance T2. For target instance T3, the batch prerequisite and inspection prerequisite are not satisfied. Therefore, the Blocking Reference Record Module generates a blocking reference record for source instance R1 and target instance T3 and prohibits the writing back of the alternative state to target instance T3.

[0097] In subsequent processing, if the actual batch of target instance T3 is adjusted to A2 and the J05 test result is updated to pass, the re-inspection processing module will trigger a re-inspection event in response to the context change of target instance T3, re-request the state source evidence package construction module to obtain the state source evidence package of source instance R1, re-request the instance context signature construction module to construct the instance context signature of target instance T3, and re-trigger the consistency verification module to perform consistency verification.

[0098] After re-verification, the batch prerequisites, location prerequisites, process prerequisites, and inspection prerequisites of the target instance T3 are all satisfied. Therefore, the state inheritance authorization module updates the blocking reference record between the source instance R1 and the target instance T3 to the state inheritance authorization record and writes the alternative state back to the target instance T3. In this way, the dynamic conversion of the alternative state from blocking control to authorization write-back is realized.

[0099] When the source instance and the target instance have the same primary code, the system does not directly propagate the alternative state as a whole according to the primary code. Instead, the state source evidence package construction module and the instance context signature construction module first generate the corresponding structured objects, and then the consistency verification module verifies the effective premise item by item. Only the state inheritance authorization module performs authorization write-back for target instances that meet the conditions, and the blocking reference record module generates blocking records for target instances that do not meet the conditions. This controls the propagation boundary of the alternative state and reduces the risk of incorrect inheritance of the alternative state.

[0100] Those skilled in the art will understand that the source instance, target instance, state source evidence package, instance context signature, state inheritance authorization record, blocking reference record, and the calling relationship, field settings, data source and processing order between modules in the above embodiments are only examples. As long as they do not deviate from the core idea of ​​this application, they can be adjusted according to the specific aviation product data collaboration scenario.

Claims

1. A batch data collaborative integration system for aviation products, characterized in that, include: An instance acquisition module is used to acquire source instances with the same master code and at least one target instance, wherein the source instance is a component instance with a replacement state; A state source evidence package construction module is used to construct a state source evidence package based on the source instance; An instance context signature building module is used to build an instance context signature based on the target instance. The consistency verification module is used to verify the consistency between the state source evidence package and the instance context signature to determine whether the target instance meets the prerequisite for the alternative state to take effect. The state inheritance authorization module is used to generate a state inheritance authorization record corresponding to the target instance when the target instance meets the effective prerequisite, and write the alternative state back to the target instance; The blocking reference record module is used to generate a blocking reference record between the source instance and the target instance when the target instance does not meet the effective prerequisite, and to prevent the alternative state from being written back to the target instance.

2. The batch data collaborative integration system for aviation products according to claim 1, characterized in that, The status source evidence package includes at least one of the following: source instance identifier; alternative approval identifier; permitted assembly location set; permitted batch range or validity range; conditions for completion of previous processes; and conditions for passing supplementary inspections.

3. The batch data collaborative integration system for aviation products according to claim 2, characterized in that, The instance context signature includes at least one of the following: target instance identifier; actual batch information; actual assembly location information; Completed process path information; inspection conclusion information.

4. The batch data collaborative integration system for aviation products according to claim 3, characterized in that, The consistency verification module specifically includes the following functions: Verify whether the actual batch information is consistent with the allowed batch range or validity range; verify whether the actual assembly location information is consistent with the allowed assembly location set; verify whether the completed process path information meets the conditions for completing the preceding process; verify whether the inspection conclusion information meets the conditions for passing the supplementary inspection.

5. The batch data collaborative integration system for aviation products according to claim 1, characterized in that, When the at least one target instance includes multiple target instances, the state inheritance authorization module is specifically used to: determine a subset of target instances that meet the effective prerequisite from the multiple target instances; generate a state inheritance authorization record for each target instance in the subset of target instances; and write back the alternative state only to the target instance carrying the state inheritance authorization record.

6. The batch data collaborative integration system for aviation products according to claim 5, characterized in that, The state inheritance authorization record includes at least: source instance identifier; target instance identifier; satisfied validity prerequisites; and authorization validity time.

7. The batch data collaborative integration system for aviation products according to claim 1, characterized in that, The blocking reference record includes at least: the source instance identifier; the target instance identifier; and unmet prerequisites for effectiveness.

8. The batch data collaborative integration system for aviation products according to claim 7, characterized in that, It also includes a re-inspection processing module, which is used to re-trigger the consistency verification module to perform consistency verification between the source instance and the target instance corresponding to the blocking reference record after the blocking reference record is generated, in response to changes in the actual batch information, actual assembly location information, completed process path information or inspection conclusion information of the target instance.

9. The batch data collaborative integration system for aviation products according to claim 8, characterized in that, The state inheritance authorization module is further configured to, after re-perform consistency verification, update the blocking reference record to the state inheritance authorization record if the target instance meets the effective prerequisite, and write the alternative state back to the target instance.

10. The batch data collaborative integration system for aviation products according to any one of claims 1-9, characterized in that, The data corresponding to the source instance and the target instance are derived from at least two of the design data, process data, assembly data and quality data, and the alternative status includes at least one of the alternative part status, rework part status and restricted release status.

Images