Work-in-process change disposition method and apparatus based on a modular data architecture

Abstract

The application relates to an in-process change handling method and device based on a modular data architecture, comprising: obtaining a main line design configuration product structure according to preset basic rules; creating a corresponding change handling sheet for a specific flight change, and identifying a flight validity interval to which the change handling sheet is applicable; determining a design module associated with the change handling sheet of the specific flight change according to a preset flight validity interval calculation rule; identifying an in-process change required to be carried out on the design module by comparing the change handling sheet and the associated design module; and completing single-machine EBOM analysis according to a preset validity calculation rule.

Description

Technical Field

[0001] This application relates to the field of configuration management technology for (high-end complex) aircraft products, and more specifically, to a method and apparatus for handling changes to work-in-process based on a modular data architecture. Background Technology

[0002] For high-end, complex products, such as aircraft, the industry commonly employs modular design and implements validity management for these design modules. Change control for components traces back to changes in the design module itself. Specifically, this involves determining whether the change to a component affects all valid scopes related to the design module, thus classifying the change as a version change or a number change. This control method is suitable for managing fluctuating production lines.

[0003] However, in actual modification processes, there are frequent scenarios where passive changes are made to the handling of specific aircraft flights, making it difficult to strictly follow a fixed production rhythm to pulse through the optimized design configuration.

[0004] As shown in Figure 1, assuming the production line operates on a pulse of 50 frames, when a passive change occurs to a local part in a specific frame (e.g., frames 8-10 or 21-25) within the pulse frame interval, a new design module is generated for the merged change of that specific frame. This causes the pulse frame of the main configuration to be cut out in a disordered manner, which disturbs the established pulse production rhythm. Furthermore, there is a high degree of part reuse between the newly generated design module and the module before the change (statistically, the repetition rate is usually >95%), which in turn leads to a large amount of redundant part redesign work.

[0005] Therefore, the problem with this control method is that as the number of changes to a particular flight increases, the design modules are frequently changed, resulting in unclear evolution of the design configuration. At the same time, the large number of repetitive design of components and revisions of manufacturing process documents disrupt the pulse production rhythm.

[0006] Currently, mainstream manufacturers manage changes by building product structures, adopting modular divisions based on configuration items, and combining data validity expressions with change control methods to achieve technical status control for individual aircraft and modules. However, there are no complete and effective solutions to problems such as unclear configuration evolution and difficulties in implementing manufacturing process documents caused by frequent module number changes during specific aircraft changes in actual processes.

[0007] For example, patent application CN111191323A proposes a design change control method, which defines a change control mechanism for design modules and components. It solves the problem of unclear design module status caused by frequent engineering changes at the design end, but does not solve the problems of increased management costs caused by a large number of design module number changes in the process, or how to manage changes to specific aircraft.

[0008] The patent application with publication number CN117434893A proposes a data and process-driven physical technical status control system and method, which solves a series of management problems related to changes such as impact analysis, baseline changes, material changes, and product handling after design changes occur. However, it does not mention how to fundamentally reduce overall module changes caused by changes in specific flights.

[0009] Patent application CN115879605A proposes a method for calculating the transient production capacity of an aircraft final assembly system based on a pulsed production mode. This method can improve the production capacity of the aircraft final assembly line and is applicable to the actual aircraft production process. However, it still cannot reduce the probability of design changes at the design stage, nor does it address how to solve the problem of the pulsed production mode failing to execute due to changes in specific flight schedules.

[0010] Patent application CN118134405A proposes a change implementation process control method based on MBOM (Machine Learning Machine) driven technology. This method effectively addresses the impact of changes on work-in-process inventory and physical inventory on the production line, reducing the difficulty of implementing change process control on the production line. However, it does not address the impact of changes on in-service aircraft, nor does it offer solutions for issues such as change management and technical status confirmation when changes occur on specific aircraft flights.

[0011] Furthermore, the paper "Design and Application of Aircraft Multi-State Change Control Model" (authors: Li Qiang, Zhao Pan, Liu Yaxing, "Aeronautical Computing Technology", 2020) analyzes the similarities and differences between multi-state changes and single-state changes in engineering changes, and elaborates on the management and control process of multi-state changes in detail from aspects such as change impact analysis, change scenario planning, baseline maintenance, and change process control. It proposes an aircraft multi-state change control model, but it does not solve the problem of unclear design configuration evolution, nor does it mention a scheme for separating and controlling changes for specific flights from changes to the main line design.

[0012] The paper "Research on Single-Flight, Modular Technical Status Management for the Entire Lifecycle of Aircraft Development" (authors: Zhao Zuojia and An Xiaoqiang, *Aircraft Design*, 2023) proposes a modular approach based on configuration items, combined with data validity expression and change control methods. This approach enables single-flight, modular technical status management, allowing for the real-time and accurate acquisition and management of the entire aircraft's Bill of Materials (BOM) data. However, it does not address the increased management costs and unclear configuration status caused by frequent changes in validity, such as frequent number changes and flight switching. Furthermore, it lacks concise and clear control methods for changes to specific flights.

[0013] In summary, existing technologies struggle to achieve an effective balance between the orderly evolution of the main configuration throughout its entire lifecycle and the rapid handling of work-in-process for specific flights. Therefore, there is an urgent need to develop a new method or device capable of decoupling and managing main design changes from changes made to specific flights, thereby improving the efficiency of engineering change management while ensuring the integrity, clarity, and traceability of the configuration status.

[0014] Based on the above background and problems, there is a need to develop a new solution that can effectively separate and manage changes to specific flights and changes to the main line design, on the basis of a modular data architecture. This would ensure that the main line design configuration can evolve in an orderly manner according to the pulsed production line, while also enabling rapid identification and timely information transmission of work-in-process changes for specific flights. Summary of the Invention

[0015] This application achieves a balance between "stability" and "flexibility" in the development of large and complex products through methodological innovation. It not only effectively solves the management dilemma of existing technologies, but also provides a brand-new practical path for the digital and refined configuration management of high-end equipment manufacturing industry.

[0016] According to a first aspect of this application, a method for handling changes to work-in-progress based on a modular data architecture is provided, comprising: Obtain the main design configuration product structure according to the preset basic rules; Create a corresponding change order for a specific flight change and identify the flight validity range to which the change order applies; The design module associated with the change order for the specific flight change is determined according to the preset flight validity interval calculation rules; By comparing the change order with the associated design module, the work-in-process changes required on the identified design module are identified; and The single-machine EBOM is parsed according to the preset validity calculation rules.

[0017] According to a second aspect of this application, a work-in-process change handling apparatus based on a modular data architecture is provided, comprising: The main line design configuration product structure acquisition module is configured to acquire the main line design configuration product structure according to preset basic rules. The specific flight change creation module is configured to create a change order for a specific flight change and to identify the flight validity range to which the change order applies. The design benchmark association module is configured to determine the association between the change handling order and the specific change of the flight according to the preset flight validity interval calculation rules; The work-in-process change planning module is configured to identify the work-in-process changes required in the identified design modules by comparing the change action order with the associated design modules; and The standalone EBOM parsing module is configured to perform standalone EBOM calculation and parsing according to preset EBOM calculation rules.

[0018] This overview is provided to introduce, in a simplified form, some of the concepts further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0019] To describe how the above and other advantages and features of this application are obtained, a more specific description of the application briefly described above will be presented with reference to specific embodiments of the application shown in the accompanying drawings. It will be understood that these drawings depict only typical embodiments of the application and are therefore not intended to limit its scope. The application will be described and explained using the drawings and with the aid of additional features and details, in which: Figure 1 An example (50 copies) of a traditional data architecture with modular design in the prior art is shown.

[0020] Figure 2 An example modular data architecture of “mainline configuration (design module) + specific flight change (change action order)” according to one embodiment of this application is illustrated.

[0021] Figure 3 A schematic flowchart of a work-in-process change handling method based on a modular data architecture according to an embodiment of this application is shown.

[0022] Figure 4 An example of a mainline design configuration product structure according to an embodiment of this application is shown.

[0023] Figure 5This paper illustrates an example modular data architecture designed according to an embodiment of the present application, which is in the form of "mainline configuration including design modules + specific flight changes including change disposal orders (single change disposal orders)" and its stand-alone EBOM parsing diagram.

[0024] Figure 6 This paper illustrates an example modular data architecture designed according to an embodiment of the present application, which is in the form of "mainline configuration including design modules + specific flight changes including change disposal orders (two change disposal orders)" and its stand-alone EBOM parsing diagram.

[0025] Figure 7 A schematic structural diagram of a work-in-process change handling apparatus based on a modular data architecture according to an embodiment of this application is shown. Detailed Implementation

[0026] As a massive and complex system engineering project, aircraft require strict control over engineering changes occurring during research, development, production, and operation. Currently, the industry commonly employs a modular design change management approach. This method involves changing the version number of design modules and assigning different validity levels to different numbered or version design modules to differentiate their applicable aircraft sortie range. However, this traditional method reveals significant problems in practical applications, especially when dealing with frequent changes to work-in-progress for specific aircraft sorties. Specifically: (1) The evolution of the main configuration state is unclear and the management cost is high.

[0027] When changes only apply to specific aircraft that have been put into production or delivered, in order to implement these local changes, new design modules are created for the affected design modules to incorporate the changes. This results in a sharp increase in the number of design modules, making the evolution of the aircraft's main configuration confusing and greatly increasing the complexity and cost of configuration management.

[0028] (2) High design redundancy.

[0029] The newly generated design modules after the merging of work-in-process changes have a high degree of part reuse with the main configuration, which has led to a large amount of redundant component redesign work and manufacturing process document revision work, resulting in unnecessary waste of resources.

[0030] (3) It is not compatible with the pulsed production mode, which affects production efficiency.

[0031] This practice of "creating new modules for localized work-in-process changes" disrupts the original pulse-based availability of the main configuration, interfering with the established rhythmic production pace. A change designed for a specific flight of work-in-process can force the entire production line out of its stable pulse rhythm, severely impacting aircraft production and operational efficiency.

[0032] For relevant examples, please refer to the patent documents cited above.

[0033] To address these issues in the prior art, this application provides a method and apparatus for handling changes to work-in-process based on a modular data architecture. It innovatively introduces a dedicated "change handling form" as an independent carrier for recording and managing these changes. only For changes to work-in-process for specific flights, the aforementioned change order can be used to package incremental changes, the range of affected flights, and other information into a single management unit (i.e., a change order). A set of clear association rules can then be established to link the change order to the corresponding design module.

[0034] A "Change of Work Disposal Form" is a set of instructions describing a work-in-process disposal solution for a specific aircraft sortie. It includes a 3D model, a structured Bill of Materials (BOM), and descriptive instructions. The 3D model is used to coordinate digital prototypes for adding / removing components within the design environment; the structured BOM lists the materials that need to be added or removed during work-in-process disposal; and the descriptive instructions provide detailed change of work disposal instructions.

[0035] This unique design allows for a precise and complete architecture view of "main configuration + incremental changes" when querying the final configuration of any aircraft. This is achieved by simply finding the corresponding design module and overlaying all associated change orders applicable to that particular flight. This dual-track design of "design module + change order" decouples the main configuration from specific flight changes, effectively solving problems such as unclear main configuration evolution, high design redundancy, and incompatibility with pulsed production modes. Ultimately, it achieves the core objective of improving change control efficiency and ensuring a clear and complete configuration in complex product development.

[0036] Compared with existing technologies, this application has the following advantages: The control method and device designed in this application provide a parallel change mode for aircraft design modifications, which not only conforms to the concept of pulsed changes but also takes into account scenarios of passive change control under special circumstances. This application adds an incremental change carrier (change handling form) to express the change handling instructions that need to be carried out on the basis of the original work-in-progress for a specific flight, resulting in multiple beneficial effects: (1) It fundamentally solves the problem of chaotic configuration state caused by frequent number changes, and ensures the clarity and traceability of configuration evolution; (2) It avoids the problem of cutting pulse frames and interfering with the production rhythm due to local changes in work-in-process, and ensures the efficient operation of the pulsed production mode; (3) It greatly reduces unnecessary redesign of components and revision of process documents, and reduces the management cost and design redundancy of engineering changes; (4) It enables rapid response and precise control of changes to specific flights.

[0037] Therefore, this application achieves a balance between "stability" and "flexibility" in the development of large and complex products through methodological innovation. It not only effectively solves the management dilemma of existing technologies, but also provides a brand-new practical path for the digital and refined configuration management of high-end equipment manufacturing industry.

[0038] exist Figure 2 The example shown is in relation to Figure 1 In the same scenario, an example modular data architecture is designed based on the form of "mainline design configuration including design modules + specific flight changes including change disposal orders" in this application.

[0039] As shown in Figure 2, the design module expresses the main design configuration for proactive modification and optimization based on pulse flight counts. Building upon this, an innovative change order is designed to express the work-in-process handling content for specific flight changes. Simultaneously, the relationship and constraints between the design module and the change order are clearly defined, ultimately decoupling the main design configuration from the passive modification process for specific flights. This scheme reduces redundant design of reusable components and design module number changes, maintains a clear evolution of the main design configuration, and eliminates the need to segment flight validity (also referred to as "validity" or "validity interval") with work-in-process changes, thus ensuring stable production cycle time.

[0040] In order to achieve, for example Figure 2 The novel modular data architecture shown in this application provides a method for handling in-process changes based on the modular data architecture, such as... Figure 3 As shown.

[0041] As shown in the figure, firstly, in step 302, the main design configuration product structure is obtained according to preset basic rules. This product structure primarily expresses the evolution of pulse flight design configurations at the design module level. The product structure includes multi-level nodes formed by configuration items (CI), design modules, and components. Flight validity should be indicated on each level of node, and the flight validity of components should be consistent with the flight validity of design modules. Lower-level nodes of design modules include, but are not limited to, self-made component nodes, finished part nodes, or standard part nodes.

[0042] As an example, in Figure 4 The example illustrates a specific instance of such a mainline design configuration product structure. In this example, each pulse interval consists of 5 aircraft. Design module 1 includes part 1 and part 2, with an aircraft validity of 6-10. Subsequently, modifications and optimizations were made to design module 1, changing part 1 to part 3. Since part number changes need to be traced back to the module level, and aircraft 6-10 already have work-in-process inventory, a new design module 2 containing part 1 and part 3 was created. The changes are implemented according to the next pulse point, i.e., an aircraft validity of 11-∞. This process is repeated to construct more design modules.

[0043] Subsequently, in step 304, a corresponding change order is created for the specific flight change, and the validity period of the flight to which the change order applies is identified.

[0044] In the above example, after implementing step 302, due to the need for passive modification, aircraft 8-10 need to be modified to reflect the configuration state of design module 2. In this scenario, the modification pertains to a specific flight; therefore, in step 304, a corresponding change order 1 is created, and the validity range for the flight is identified as 8-10. Figure 5 As shown.

[0045] In step 306, the design module associated with the change order for a specific flight change is determined according to the preset flight validity interval calculation rules.

[0046] In the example, based on the flight validity interval, the flight validity interval 8-10 of the change order 1 belongs to the flight validity interval (6-10) of the design module 1. Therefore, the design module associated with the change order 1 can be identified as design module 1.

[0047] Next, in step 308, by comparing the change order with the associated design module, the work-in-process changes that need to be carried out on the determined design module are identified, including: planning the incremental change content relative to the design module baseline under the change order, and determining the change method of the lower-level components of the design module as adding components and / or deleting components and / or changing component numbers.

[0048] As mentioned earlier, the change order contains a structured Bill of Materials (BOM). By linking the change order with the parts in the design module, the BOM can be automatically calculated. That is, if the change method in the change order is "addition," the BOM is calculated by summation; if the change method is "deletion," the BOM is calculated by subtraction. Finally, the single-aircraft BOM list is obtained by parsing the flight validity.

[0049] Specifically, among them: 1) If the modification method of the lower-level component of the design module is to add a new component, then further determine whether the component number object has been generated: If so, a new EBOM line for the component version object will be generated directly under the change handling form. The change method in the EBOM line will be displayed as "added", and the quantity information of the component will be edited on the EBOM line. If not, first plan the new number and version object of the component, then generate a new EBOM line for the component version object under the change handling form. The change method in the EBOM line is "add". Edit the quantity information of the component on the EBOM line. 2) If the modification method of the lower-level component of the design module is to delete the component, a new EBOM line of the component version object is generated on the change processing form. The modification method in the EBOM line is deletion. The quantity information of the component is edited on the EBOM line and consumed on the EBOM line of the component under the original design module to ensure that the number of deletions does not exceed the number of components under the original design module. 3) If the modification method of the lower-level components of the design module is component number change, then a new component number and version object are generated according to the preset component number change rules, and two EBOM lines are generated on the change processing form at the same time: One EBOM row is generated for the old part number of the component, and the change method is deletion; the other EBOM row is generated for the new part number of the component, and the change method is addition.

[0050] Specifically, in Figure 4 and 5 In the example shown, the planned incremental change content is used to describe how to change from design module 1 to design module 2, that is, to achieve the change from design module 1 to design module 2 by deleting part 2 and adding part 3.

[0051] Furthermore, when planning to delete part 2 in Change Order 1, part 2 needs to be dragged and dropped from Design Module 1. A BOM line for part 2 will be generated under Change Order 1. The change method on the BOM line is "delete," and the deletion quantity is edited to 3 to represent the complete consumption of the original quantity. At the same time, the deletion quantity is limited to not exceeding the original quantity. Figure 5 As shown.

[0052] Furthermore, when planning to add part 3 in Change Order 1, a BOM line for part 3 is generated under Change Order 1. The change method on the BOM line is "Add", and the quantity of the new addition is 3, as shown in Figure 5.

[0053] Finally, in step 310, the single-machine EBOM parsing is completed according to the preset validity calculation rules.

[0054] The validity calculation rule refers to calculating the combination of the design module and the change order for each flight according to the flight interval defined by the design module and the change order.

[0055] For example: the validity range of Design Module 1 is 006-010, and the validity range of Change Order 1 is 008-010. Therefore, within the validity range of 006-007, only Design Module 1 exists, so the individual EBOMs for these two aircraft are the set of components for Design Module 1. However, within the validity range of 008-010, both Design Module 1 and Change Order 1 exist, so the individual EBOMs for these three aircraft are the set of components for Design Module 1 plus Change Order 1. This process can be repeated to complete the analysis of the corresponding individual EBOMs for each aircraft, thus generating results like... Figure 5 The single-machine EBOM parsing configuration is shown.

[0056] It should be understood that there may be more than one change order; rather, multiple change orders may be generated based on the number of changes made for a specific flight.

[0057] For example, such as Figure 6 As shown, in addition to generating Change Order 1 as described above, if there are changes to a specific flight (e.g., flights 9-12), the above steps can be repeated to generate the corresponding Change Order 2.

[0058] Specifically, assuming another passive change occurs during sorties 9-12, reducing the quantity of part 1 by 1 and increasing the quantity of part 3 by 1, then: Following step 304, create Change Handling Order 2 and identify the validity range of the flights as 9-12.

[0059] Subsequently, following step 306, Change Order 2 is simultaneously associated with Change Baseline - Design Module 1 (flight validity range 6-10) and Design Module 2 (flight validity range 11-∞) for aircraft 9-12. This indicates that Change Order 2 is an incremental change based on Design Module 1 for aircraft 9-10, and an incremental change based on Design Module 2 for aircraft 11-12, and the incremental change content of the two must be the same.

[0060] Next, following step 308, by comparing the change action form 2 with design modules 1 and 2 respectively, the incremental changes to the work-in-process change plan that need to be carried out on the determined design modules are identified.

[0061] Furthermore, when planning to delete part 1 in Change Order 2, part 1 needs to be dragged and dropped from Design Module 1. A BOM line for part 1 will be generated under Change Order 2. The change method on the BOM line is "delete," and the deletion quantity is edited to 1 to represent a partial consumption of the original quantity. Figure 6 As shown.

[0062] Furthermore, when planning to add part 3 in Change Order 2, a BOM line for part 3 is generated under Change Order 2. The change method on the BOM line is "Add", and the quantity is edited to be 1, such as... Figure 6 As shown.

[0063] It should be understood that if there are more specific changes to a particular flight, the above process can be repeated to create the corresponding change order, which will not be elaborated here.

[0064] Once all the corresponding change orders for specific flight changes have been created, in step 310, the single-machine EBOM is parsed according to the preset validity calculation rules, such as... Figure 6 As shown.

[0065] The following is based on Figure 7 This further illustrates an example structure of a work-in-process change disposal apparatus based on a modular data architecture according to an embodiment of this application.

[0066] As shown in the figure, the work-in-process alteration handling device mainly includes: The mainline design configuration product structure acquisition module 702 is configured to acquire the mainline design configuration product structure according to preset basic rules. The product structure mainly expresses the evolution of pulse flight design configuration with design modules as the granularity. The product structure includes multi-level nodes formed by configuration items (CI), design modules, and components. Flight validity should be marked on each level node, and the flight validity of components should be consistent with the flight validity of design modules.

[0067] The specific flight change creation module 704 is configured to create a change order for a specific flight change and to identify the flight validity range to which the change order applies.

[0068] The design benchmark association module 706 is configured to determine the association between the change handling order and the specific change order according to the preset flight validity interval calculation rules.

[0069] Work-in-process change planning module 708 is configured to identify work-in-process changes required in a determined design module by comparing a change action order with an associated design module, including: completing incremental change content planning under the change action order, and determining the change method of the lower-level components of the design module as adding components and / or deleting components and / or changing component numbers.

[0070] in: 1) If the modification method of the lower-level component of the design module is to add a new component, then further determine whether the component number object has been generated: If so, a new EBOM line for the component version object will be generated directly under the change handling form. The change method in the EBOM line will be displayed as "added". The quantity information of the component can be edited on the EBOM line. If not, first generate a new part number and version object for the component, then generate a new EBOM line for the component version object under the change handling form. The change method in the EBOM line is "add". Edit the quantity information of the component on the EBOM line. 2) If the modification method of the lower-level component of the design module is to delete the component, a new EBOM line of the component version object is generated on the change processing form. The modification method in the EBOM line is deletion. The quantity information of the component is edited on the EBOM line and consumed on the component EBOM line under the original design module to ensure that the number of deletions does not exceed the number of components under the original design module. 3) If the modification method of the lower-level component of the design module is component number change, then a new number and version object of the component are generated according to the preset component number change rules, and two EBOM lines are generated on the change processing form at the same time: one is the EBOM line generated by the old number of the component, and the modification method is deletion; the other is the EBOM line generated by the new number of the component, and the modification method is addition. The standalone EBOM parsing module 710 is configured with preset validity calculation rules to complete standalone EBOM calculation and parsing.

[0071] In summary, based on the above embodiments, this application has the following three characteristics: The first is to support passive change scenarios, through an incremental change handling carrier (change handling form), to express incremental changes on the basis of modularity, and to achieve separate control of specific flight changes and main configuration changes; Secondly, the change order can implement the same incremental changes across multiple design modules, making it flexible and reducing the frequency of changing design module numbers. Third, the change disposal order defines the validity and change method by planning the component BOM line, and carries out consumption-based management of the original quantity for deleted parts, providing a basis for realizing single-machine EBOM analysis under the coupling scenario of main line design configuration and specific flight change.

[0072] Although the techniques have been described using language specific to structural features and / or methodological actions, it should be understood that the appended claims are not necessarily limited to the described features or actions. Rather, these features and actions are described as exemplary forms of implementing these techniques.

[0073] The operations of the example processes are shown in separate boxes and are summarized with reference to these boxes. These processes are shown as a flow of logical boxes, each of which may represent one or more operations that can be implemented using hardware, software, or a combination thereof. In the context of software, these operations represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, cause one or more processors to perform a given operation. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, etc., that perform a particular function or implement a particular abstract data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the operations may be executed in any order, combined in any order, subdivided into multiple sub-operations, and / or executed in parallel to implement the described process. The described process may be executed by resources associated with one or more computing devices, such as one or more internal or external CPUs or GPUs, and / or one or more pieces of hardware logic, such as FPGAs, DSPs, or other types of accelerators.

[0074] All of the methods and processes described above can be embodied in software code modules executed by one or more general-purpose computers or processors, and can be fully automated via these software code modules. These code modules can be stored on any type of computer-executable storage medium or other computer storage device. This code can also be packaged into corresponding computer program products. Some or all of these methods can alternatively be embodied in dedicated computer hardware.

[0075] Any routine description, element, or box in the flowcharts described herein and / or in the accompanying drawings should be understood as potentially representing a module, segment, or portion of code comprising one or more executable instructions for implementing a specific logical function or element in that routine. Alternative implementations are included within the scope of the examples described herein, wherein elements or functions may be removed or performed inconsistently with the order shown or discussed, including substantially synchronous or reverse order execution, depending on the functionality involved, as will be understood by those skilled in the art.

[0076] While different embodiments have been described above, it should be understood that they are merely examples and not limitations. Those skilled in the art will appreciate that various modifications in form and detail may be made without departing from the spirit and scope of this application as defined in the appended claims. Therefore, the breadth and scope of this application disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A method for handling changes to work-in-progress based on a modular data architecture, comprising: Obtain the main design configuration product structure according to the preset basic rules; Create a corresponding change order for a specific flight change and identify the flight validity range to which the change order applies; The design module associated with the change order for the specific flight change is determined according to the preset flight validity interval calculation rules; By comparing the change order with the associated design module, the work-in-process changes required on the design module are identified; and stand-alone EBOM parsing is completed according to preset validity calculation rules.

2. The method for handling changes to work-in-process as described in claim 1, characterized in that, The main design configuration product structure includes a multi-level node consisting of configuration items, design modules, and components. The validity of each sortie is marked on each level node, wherein the validity of the sortie of the components is consistent with the validity of the sortie of the design modules.

3. The method for handling changes to work-in-process as described in claim 1, characterized in that, The Change of Process Order (COE) is a set of instructions that describes a work-in-process disposal solution for a specific aircraft. It includes a 3D model, a structured Bill of Materials (BOM), and descriptive instructions.

4. The method for handling changes to work-in-process as described in claim 1, characterized in that, The required changes to the work-in-process on the identification design module include: Under the change action form, plan the incremental changes relative to the design module baseline; determine the change method for the lower-level components of the design module as adding components and / or deleting components and / or changing component numbers.

5. The method for handling changes to work-in-process as described in claim 4, characterized in that, The method of determining the modification of the lower-level components of the design module includes adding components and / or deleting components and / or changing component numbers, including: 1) If the modification method of the lower-level component of the design module is to add a new component, then further determine whether the component number object has been generated: If so, a new EBOM line for the component version object will be generated directly under the change handling form, the change method in the EBOM line will be displayed as "added", and the quantity information of the component will be edited on the EBOM line; If not, first plan the new number and version object of the component, then generate a new EBOM line for the component version object under the change handling form. The change method in the EBOM line is "add". Edit the quantity information of the component on the EBOM line. 2) If the modification method of the lower-level component of the design module is to delete the component, a new EBOM line of the component version object is generated on the modification processing form. The modification method in the EBOM line is deletion. The quantity information of the component is edited on the EBOM line and consumed on the component EBOM line under the original design module to ensure that the number of deletions does not exceed the number of components under the original design module. 3) If the modification method of the lower-level component of the design module is component number change, then a new number and version object of the component are generated according to the preset component number change rules, and two EBOM lines are generated on the change processing form at the same time: one is the EBOM line generated by the old number of the component, and the modification method is deletion; the other is the EBOM line generated by the new number of the component, and the modification method is addition.

6. The method for handling changes to work-in-process as described in claim 1, characterized in that, The validity calculation rule is to calculate the combination of the design module and the change order for each flight according to the flight interval defined by the design module and the change order.

7. The method for handling changes to work-in-process as described in claim 1, characterized in that, Generate a corresponding number of change orders based on the number of changes made to a specific flight.

8. A work-in-process change handling device based on a modular data architecture, comprising: The main line design configuration product structure acquisition module is configured to acquire the main line design configuration product structure according to preset basic rules. The specific flight change creation module is configured to create a change order for a specific flight change and to identify the flight validity range to which the change order applies. The design benchmark association module is configured to determine the association between the change handling order and the specific change of the flight according to the preset flight validity interval calculation rules; The work-in-process change planning module is configured to identify the work-in-process changes required on the identified design modules by comparing the change action order with the associated design modules. as well as The standalone EBOM parsing module is configured to perform standalone EBOM calculation and parsing according to preset EBOM calculation rules.

9. The work-in-process alteration handling apparatus as described in claim 8, characterized in that, The identification of required in-process changes for the determined design module includes: Under the change action form, plan the incremental changes relative to the design module baseline; determine the change method for the lower-level components of the design module as adding components and / or deleting components and / or changing component numbers.

Images