Full life cycle management system and method

Abstract

The invention discloses a full-life-cycle management system and method, relates to the technical field of full-life-cycle management and digital research and development of products, and is used for solving the problems that tracing among requirements, design, bill of materials, process, change, production and quality is broken, version is out of control, and the change influence range is difficult to recheck. Obtaining and normalizing according to requirements, de-overlapping and merging, and establishing a review baseline and a requirement tracking matrix; design data is stored in a controlled manner, and file fingerprints and versions or states are used for circulation control, linkage of process routes and process files, simulation and manufacturability examination; in an engineering change stage, multi-record evidences are sliced and aligned according to timestamps, same-code ectopic structure path mapping is solidified, a quantization sequence is constructed, a double-boundary influence object list is output by a gating factor, and a propagation layer number is stabilized; a traceability chain is constructed in the production process, and quality closed-loop write-back and knowledge base retrieval enhancement are formed, so that traceable and recheckable closed-loop management is realized.

Description

Technical Field

[0001] This invention relates to the field of product lifecycle management and digital R&D technology, and more specifically, to a lifecycle management system and method. Background Technology

[0002] Under fragmented PLM, ALM, MES, or quality systems, existing R&D and manufacturing enterprises face common problems including: scattered and inconsistent records of demand sources, making it difficult to solidify demand baselines and track changes; while design data and drawings can be archived, they lack unified fingerprint verification and controlled state flow, leading to high risks of version cross-modification and different items with the same name; the reconstruction from E bill of materials to P or M bill of materials relies heavily on manual experience, and the lack of consistency constraints on structural differences and process binding easily results in the same material code being inconsistent in different bill of materials levels; during engineering changes, multiple responsible persons submitting candidate versions in parallel can cause rapid growth in version numbers, repeated fingerprint changes, and oscillating structural differences, potentially leading to reversals in simulation and review conclusions, resulting in frequent expansion or regression of the scope of impact, making it difficult to form a verifiable list of objects; although production and quality data are collected, their relationship with demand acceptance criteria and verification evidence is unstable, making it difficult to build closed-loop improvement and searchable knowledge accumulation.

[0003] To address the above problems, this invention proposes a solution. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a full lifecycle management system and method to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: In a preferred embodiment, it includes: Collect and store the requirement data into the database and structure it into requirement items. Generate requirement item numbers and form a requirement baseline version number and requirement traceability matrix. Split the work package according to the requirement item number. Generate design object identifiers, controllably import 3D models and 2D drawings into the warehouse, construct engineering bill of materials and reconstruct process bill of materials and manufacturing bill of materials; Generate an engineering change request number and write it into the version baseline record and lock record. Construct an evidence slice sequence and use an object mapping index to solidify the structural path identifier and the same code misaligned state. Calculate the quantization sequence and maintain the smooth value and inertia value to generate a state gating factor. Output the list of affected objects between the convergence boundary and the conservative boundary according to the state gating factor and write it into the boundary update record and the propagation layer number. The convergence boundary and the conservative boundary are both based on the material code as the object. The propagation layer number is used to characterize the layer extension level in the list of affected objects. Generate quality anomaly records and write the source carrier identifier; generate quality closed-loop improvement records and generate engineering change requests and write the engineering change request number; write back the requirements traceability matrix and write the knowledge entries.

[0006] In a preferred embodiment, demand data is collected and, upon entry into the database, the demand source identifier, source carrier identifier, collection timestamp, and collection responsible person identifier are bound and written to the demand data. Demand data lacking a demand source identifier or source carrier identifier is set as unacceptable for entry into the database, and a supplementary task is generated. The entered demand data is structured and converted into demand items, and a unique demand item number is generated for the entire lifecycle. At the same time, the demand item text, scope of application, priority, acceptance criteria, risk level, and demand source identifier are written, and the text, priority, and risk level are standardized.

[0007] In a preferred embodiment, feature vectors are generated based on the requirement item text and semantic similarity is calculated; a requirement baseline version number is generated for the approved requirement items and differences are recorded; a requirement tracking matrix is ​​constructed with the requirement item number as the row and design object identifier, verification object identifier and status identifier are written in it; the status is updated according to the verification evidence corresponding to the acceptance criteria; and the requirement items are split into work packages according to the baseline and the responsible persons, milestones and deliverable constraints are bound to them; when the baseline is updated, the tracking matrix and the work package binding relationship are updated in conjunction.

[0008] In a preferred embodiment, a design object identifier is generated or completed for each requirement item based on the requirement traceability matrix, and the timestamp and responsible person identifier are recorded. The 3D model and 2D drawings are written into the database in a controlled manner, with version number, status identifier and creation information written, and the file fingerprint value is calculated and associated with the design object identifier. An engineering bill of materials is constructed according to the assembly structure, and the association between material nodes and drawings or models and the consistency of version number are verified. When an anomaly occurs, an anomaly record and pending tasks are generated. When design data is modified and submitted, the file fingerprint value is compared to trigger the generation of a new version number and the version change information and status flow record are recorded. After the review is approved, it is updated to "approved". After the design object identifier has been approved, the engineering bill of materials is reconstructed into a process bill of materials and a manufacturing bill of materials with the material code remaining unchanged as a constraint. The process route identifier and manufacturing attribute fields are written. During the reconstruction, structural difference records are written, and the inclusion relationship of material code sets between the lists and the missing key fields are verified. Based on the manufacturing bill of materials, process routes and process documents are generated, and file fingerprint values ​​and version information are written. Then, a three-dimensional structured process is generated, and process simulation is performed to generate simulation problem records. Subsequently, manufacturability review rules are run to generate review problem records, and when the problem is closed, the relevant data objects are driven to generate new version numbers and change information is recorded.

[0009] In a preferred embodiment, after an engineering change request is generated and written with the engineering change request number, the source carrier identifier of the change reason, and the set of involved objects, a version baseline record and a lock record are written for the controlled objects, and parallel candidate version submissions are allowed during the lock period. For issues such as same code but different structure mapping, rapid version number growth accompanied by file fingerprint value rebound, structural difference addition, movement, deletion combination oscillation, simulation collision conclusion reversal, and asynchronous expansion and convergence of the impact range caused by the reopening of review issues after closure, the lock record, version baseline record, structural difference record, simulation issue record, and review issue record are aligned according to continuous timestamps to form an evidence slice sequence. The structural position of the same material code in the engineering bill of materials, process bill of materials, and manufacturing bill of materials is solidified with structural path identifiers and written into the object mapping index and marked as same code but different state. The candidate version is a controlled version with different version numbers submitted around the same design object identifier during the lock period.

[0010] In a preferred embodiment, for each timestamp evidence slice, a quantized sequence of lock persistence, file fingerprint value jump and file fingerprint value bounce, structural difference complexity and structural difference oscillation, simulation unclosed strength, review unclosed strength, conclusion flip density, same code misalignment offset, boundary drift and boundary back is calculated and smoothed and inertial values ​​are maintained. A state gating factor is calculated based on multi-factor recursive values ​​to determine whether the current trend is more inclined towards convergence or oscillation. Convergence boundary and conservative boundary are generated synchronously at the same timestamp. Candidate sets are screened by object-level evidence hit vector and multiplicative truncation score, combined with object thresholds adjusted with same code misalignment offset and boundary drift. The state gating factor then selects between the two candidate sets to output the current list of affected objects and writes it into the boundary update record and oscillation interval field. The path evidence field is used to record the structural path identifier corresponding to the same code misalignment state. Simultaneously, the parent-child relationship of the list and the three-dimensional assembly constraints are integrated to establish an adjacency set and calculate the propagation layer number by layer expansion. The same code but different depth difference and layer number transition trigger consistency constraints and recalculation and write them into the path evidence field. Thus, under the conditions of recording oscillation and structural reorganization, a playable list of affected objects and a verifiable hierarchical relationship are continuously output. The oscillation interval field is used to record the expansion and convergence alternation interval in the boundary update record.

[0011] In a preferred embodiment, quality anomaly records are generated and source carrier identifiers are written for quality anomalies in the production and quality stages. The process, equipment tooling, and material batch corresponding to the anomaly are located by linking the product identifier to the traceability record. Then, a quality closed-loop improvement record is generated. When it is necessary to revise the 3D model, 2D drawings, or various bills of materials and process data objects, an engineering change request number is generated and the relevant objects are included in the controlled change. At the same time, a verification object identifier and its evidence carrier source carrier identifier are generated and written back to the verification object identifier field of the requirement tracking matrix to drive the status update corresponding to the acceptance criteria. The engineering change request number and the quality anomaly record number are written into the source carrier identifier set of the knowledge entry.

[0012] In a preferred embodiment, it includes: a demand management module, a design control module, a change impact analysis module, a traceability closed-loop module, and signal connections between the modules; The requirements governance module is used to collect and store requirements data, structure them into requirements items, generate requirements item numbers, form requirements baseline version numbers and requirements traceability matrices, and split work packages according to requirements item numbers. The controlled design module is used to generate design object identifiers, controllably store 3D models and 2D drawings, construct engineering bill of materials and reconstruct process bill of materials and manufacturing bill of materials; The change impact analysis module is used to generate engineering change request numbers and write them into the version baseline record and lock record, construct evidence slice sequences and use object mapping index to solidify structural path identifiers and same code misaligned states, calculate quantification sequence and maintain smooth value and inertia value to generate state gating factor, output the list of affected objects between the convergence boundary and the conservative boundary according to the state gating factor and write it into the boundary update record and propagation layer number. The convergence boundary and the conservative boundary are both based on material code as objects, and the propagation layer number is used to characterize the layer extension level in the list of affected objects. The traceability closed-loop module is used to generate quality anomaly records and write the source carrier identifier, generate quality closed-loop improvement records and generate engineering change requests and write the engineering change request number, and write back the requirement tracking matrix and write the knowledge entries.

[0013] The technical effects and advantages of the whole life cycle management system and method of the present invention are as follows: This invention improves the quality of requirement input through source binding, field standardization, and semantic deduplication, and solidifies design and verification evidence into a verifiable link using baseline versions and requirement tracking matrices. It uses SHA-256 file fingerprints to overlay version or state transitions, achieving anti-tampering and auditability of models, drawings, or process documents. The reconstruction from E-bill of materials to P-bill of materials and then to M-bill of materials, combined with set inclusion constraints and consistency checks, reduces the risk of structural mismatch caused by different code positions. In change impact analysis, it introduces evidence slice sequences, quantitative indicator smoothing, or inertia and gating dual-boundary output, ensuring that the boundary remains stable, replayable, and verifiable even under oscillating conditions. Production traceability and quality closed-loop write-back directly link anomaly handling with requirement acceptance, and condenses this into vectorized knowledge entries, improving reuse and retrieval efficiency, and overall reducing the probability of rework and missed changes. Attached Figure Description

[0014] Figure 1 This is a sequence diagram of a full lifecycle management system and method according to the present invention.

[0015] Figure 2 This is a schematic diagram of a full lifecycle management system and method module of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example This invention discloses a full lifecycle management method, such as... Figure 1 As shown, it includes: Step 1: Requirements gathering, requirement item standardization, and requirement traceability matrix construction; First, the requirement data collection and source binding are executed. For requirement inputs in R&D activities, requirement data is collected according to preset requirement source types. These requirement source types include at least market research records, customer requirement inputs, after-sales service feedback, quality anomaly records, and legal or compliance clauses. For each piece of collected requirement data, before writing it into the requirement set, a requirement source identifier, a source carrier identifier, a collection timestamp, and a collection responsible person identifier are simultaneously written, and these four identifiers are bound to the requirement data. If any requirement data is missing a requirement source identifier or a source carrier identifier, the requirement data is set to an un-included state and a supplementary task is generated. Only after the supplementation is completed is it allowed to enter the requirement set.

[0018] After the requirement data is imported into the database, a structured transformation of the requirement items is performed. Each requirement data item in the requirement set is structured to generate a set of requirement items. Each requirement item consistently includes a requirement item number, requirement item text, applicable product or model range, priority, acceptance criteria, risk level, and requirement source identifier, maintaining consistent field naming. The requirement item number is generated according to the company's unified coding rules and remains unique throughout its entire lifecycle. The acceptance criteria are written as verifiable statements and stored in conjunction with the requirement item number. For example, when the requirement item text is "shell drop resistance," the acceptance criteria could be, for instance, that the shell shows no cracks and functions normally after a drop test under predetermined test conditions, and this is saved along with the corresponding requirement item number.

[0019] After the requirement item set is generated, requirement item normalization is performed. Requirement item normalization includes text normalization and field normalization: text normalization performs synonym unification, terminology standardization, and format standardization on the requirement item text; field normalization maps priority and risk level to a preset enumeration value set and writes the mapping results back to the corresponding requirement item fields to form a normalized requirement item set.

[0020] After completing the requirement item normalization, perform requirement item deduplication and merging. Generate a feature vector for each requirement item text, and record the feature vector generation method used as a vector generation method identifier; Among them, the feature vector refers to the numerical vector in the vector space that maps the requirement text; the vector generation method identifier is used to identify the feature vector generation method used; the vector 2 norm is represented by the symbol ‖‖, which is used to perform length normalization related calculations on the feature vector.

[0021] Then, semantic similarity is calculated for any two requirements using the cosine similarity formula. First, the original cosine similarity value cos(i,j) is calculated, expressed as: cos(i,j)=(Vi⋅Vj) / (‖Vi‖·‖Vj‖); Where Vi is the feature vector of the i-th requirement text, and Vj is the feature vector of the j-th requirement text; ⋅ is the vector dot product; ‖Vi‖ and ‖Vj‖ are the vector L2 norms; cos(i,j) takes values ​​in the range [-1,1].

[0022] To maintain the semantic similarity value range of [0,1] and facilitate its binding and storage with the deduplication threshold parameter, the semantic similarity sim(i,j) is defined as a linear mapping result to cos(i,j), and the mapping expression is: sim(i,j)=(1+cos(i,j)) / 2; Therefore, the value range of sim(i,j) is [0,1]. The enterprise's preset deduplication threshold parameter is bound and stored with this deduplication batch. For example, the deduplication threshold parameter can be set to 0.85. When sim(i,j)≥0.85, a merging action is triggered. During the merging action, the demand source identifiers of the merged demand items are combined and their union is retained, and a demand item merging record is generated. The demand item merging record includes at least the set of demand item numbers to be merged, the merged demand item number, the trigger similarity value, the deduplication threshold parameter, the vector generation method identifier, the merging executor identifier, and the merging timestamp. The merged demand items are then written back to the demand item set.

[0023] After deduplication and merging of requirements, a requirements review is performed, generating a requirements baseline version number. When initiating a review, a review batch identifier is generated, and the requirement item number, acceptance criteria, risk level, and requirement source identifier are used as review inputs. Review conclusions generated during the review process are bound to and stored one by one with the requirement item number, and the reviewer's identifier and review timestamp are recorded. The set of requirements that pass the review is solidified, and a requirements baseline version number is generated. This baseline version number also records the set of requirement item numbers it contains, the generation timestamp, and the identifier of the person responsible for its generation. If new requirements or requirements are added or changed, a new requirements baseline version number is generated, and a difference record is created. This difference record at least includes the set of newly added or changed requirement item numbers and the changes in their requirement source identifiers.

[0024] After the requirement baseline version number is generated, a requirement traceability matrix is ​​constructed and consistency checks are performed. A requirement traceability matrix object is created with the requirement item number as the row index, and three columns are fixed: design object identifier, verification object identifier, and status identifier. The set of requirement item numbers under the requirement baseline version number is written into the row set of the requirement traceability matrix, and the status identifier of the corresponding row is initialized to unclosed.

[0025] After the build is completed, a consistency check is performed: for each requirement item number, check whether its design object identifier and verification object identifier are empty. If they are empty, maintain the status identifier as unclosed and generate a pending task. When both the design object identifier and verification object identifier have been written and the evidence corresponding to the verification object identifier meets the acceptance criteria, update the status identifier to closed and record the status change timestamp and the identifier of the person responsible for the change.

[0026] After the requirements traceability matrix is ​​created and validated, a project plan is generated, and the work breakdown structure (WBS) and work packages are implemented. When generating the project plan, requirements under the baseline version number are grouped by applicable product or model range and priority to form a WBS and break it down into work packages. Each work package is assigned a responsible person identifier, milestone timestamp, and deliverable constraints. The work package identifier is then bound to the set of requirements item numbers it covers and stored. Simultaneously, the deliverable constraints generated by the work package are bound to the rows in the requirements traceability matrix for write-back updates when deliverables are generated. During project execution, when the baseline version number is updated, the affected set of requirements item numbers is located based on the difference record. The corresponding row in the requirements traceability matrix and the associated work package bindings are updated accordingly, and the executor identifier and execution timestamp of the update action are recorded.

[0027] Step Two: Controlled management of design data and linkage with bill of materials reconstruction or process planning; First, the design object identifier generation and controlled data entry of design data are performed. For each row corresponding to a requirement item number in the requirement traceability matrix, the design object identifier field of that row is read. When the design object identifier field is empty, a design object identifier is generated and written to the design object identifier field of that row, while simultaneously recording the writing timestamp and the responsible person identifier. The design object identifier is an identifier used to uniquely identify the design data set. The design data set includes at least a 3D model, 2D drawings, and a bill of materials, where: the 3D model refers to a 3D digital model used to express the geometric shape and assembly relationship of product components; the 2D drawings refer to engineering drawings containing dimension annotations and technical requirements; and the bill of materials refers to list data expressing the hierarchical and quantitative relationships of product components according to the engineering design structure. For each 3D model and 2D drawing, a controlled data entry operation is performed: version number, status identifier, creator identifier, and creation timestamp are written, and a file fingerprint value is calculated and written; the file fingerprint value is a hash digest calculated from the file content byte stream. The file fingerprint value is calculated using a hash algorithm, denoted as: File fingerprint value = ; in, This indicates that the input data is hashed using the SHA-256 algorithm; the file content byte stream represents the byte sequence obtained by reading the 3D model file or 2D drawing file according to a predetermined encoding. After writing the file fingerprint value, the 3D model, 2D drawing, and design object identifier are associated, and the association timestamp is recorded.

[0028] After the 3D model and 2D drawings are stored in a controlled manner, the engineering bill of materials (BOM) is constructed and its consistency is verified. During the construction of the BOM, a material hierarchy tree is formed layer by layer based on the product assembly structure. For each material node, a material code, material name, quantity, unit of measurement, material properties, version number, and status identifier are written. The material code is generated according to the company's unified coding rules and remains unique throughout its entire lifecycle. After the BOM is constructed, a consistency verification is performed: each material node in the BOM is checked to ensure it is associated with at least one 2D drawing or at least one 3D model, and the version number of the material node is checked to ensure it matches the version numbers of its associated 2D drawing and 3D model. When a missing association or inconsistent version number is found, an anomaly record is generated and a pending task is created. The anomaly record includes at least the material code, anomaly type, discovery timestamp, and the identifier of the person responsible for the discovery.

[0029] After the consistency verification of the engineering bill of materials is completed, design data version control and status transition control are executed. For 3D models and 2D drawings in a controlled state, when content is modified and submitted, the modified file content byte stream is reread and the file fingerprint value is recalculated; the file fingerprint value before modification is compared with the file fingerprint value after modification, and if they are not equal, a new version number is generated, and the version number before change, the version number after change, the identifier of the person responsible for the change, and the change timestamp are recorded, while the status identifier is updated to "Under Change". When the review is completed and approved, the status identifier is updated to "Approved", and the reviewer identifier and review timestamp are recorded. For each status transition, a status transition record is generated, which includes at least the trigger event type, the original status identifier, the new status identifier, the reviewer identifier, and the review timestamp.

[0030] After design data version control is completed, design review records are written and design object identifier status is updated. For each design object identifier, a design review action is initiated for the corresponding 3D model, 2D drawings, and bill of materials, and a review record identifier is generated. After review by the reviewers, review comments are generated and stored in conjunction with the review record identifier, along with the reviewer's identifier and review timestamp. If the review comments require modification, the status of the design object identifier is set to "Under Change," and the review comments are written to the design change description field. If the review is approved, the status of the design object identifier is set to "Approved," and the status update timestamp and responsible person's identifier are recorded.

[0031] After the design object identification reaches the approved state, the bill of materials (BOM) is restructured to generate the process BOM and the manufacturing BOM. The process BOM refers to the product decomposition structure and process attribute set expressed in terms of process; the manufacturing BOM refers to the final product structure and manufacturing attribute set expressed in terms of manufacturing assembly. The BOM restructuring includes the reconstruction from the engineering BOM to the process BOM, and the reconstruction from the process BOM to the manufacturing BOM; both reconstructions maintain the material codes unchanged, and adjust and supplement the structural hierarchy, attribute fields, and process binding relationships.

[0032] The reconstruction from the engineering bill of materials (BOM) to the process bill of materials (BOM) is performed as follows: The material hierarchy tree of the engineering BOM is read, the process structure tree of the process BOM is established, and the material nodes are reorganized according to the enterprise's process division rules to form assembly units and processing units. For each process structure tree node, the contracting unit attribute, component type attribute, and process route identifier are written. The contracting unit attribute records the organization undertaking the corresponding process task; the component type attribute distinguishes between parts, components, and assemblies; the process route identifier points to the corresponding process route data object. During the reconstruction process, structural difference records are generated: the material hierarchy tree of the engineering BOM is compared with the process structure tree of the process BOM, recording newly added nodes, deleted nodes, moved nodes, and their reasons, and the structural difference records are bound and stored with the corresponding design object identifiers. After the process BOM is generated, a process BOM consistency check is performed, and the material code set of the engineering BOM is defined as follows: Define the material code set for the process bill of materials as follows: Then the set constraint for consistency verification is: ; in, Indicates a set containment relationship; This is the set of all material codes in the project's bill of materials; This is the set of all material codes in the process bill of materials. (When exists) and At that time, an exception record is generated and a pending task is generated, wherein the exception record contains at least the missing material code. Discovery timestamp and identification of the person responsible for the discovery.

[0033] The reconstruction from the process bill of materials (BOM) to the manufacturing bill of materials (BOM) is performed as follows: The process structure tree of the process BOM is read, and a manufacturing structure tree of the manufacturing BOM is established. Within the manufacturing structure tree, the assembly levels are expanded according to the assembly process sequence, and a set of manufacturing attributes is added to each node. The set of manufacturing attributes includes at least the following: processing technology content, material quota information, time quota information, quality requirement information, equipment resource identifiers, tooling resource identifiers, and tooling and gauge resource identifiers. Specifically, the processing technology content describes the processing or assembly operation; the material quota information records the material grade, usage, and cutting parameters; the time quota information records the standard working hours and timing method; the quality requirement information records the inspection items and judgment criteria; and the equipment resource identifiers, tooling resource identifiers, and tooling and gauge resource identifiers point to the corresponding resource objects in the enterprise resource library. After the manufacturing BOM is generated, a consistency check is performed, and the material code set of the process BOM is defined as follows: Define the set of material codes for the bill of materials as follows: Then the set constraint for consistency verification is: ; And for each material node in the manufacturing bill of materials, check whether it has been written with at least one processing procedure and at least one quality requirement; when there are and If a material node lacks processing technology information or quality requirement information, an exception record is generated and a pending task is created.

[0034] After the manufacturing bill of materials (BOM) is generated and verified, process routing and process document generation are performed. For each material node in the BOM, its process routing identifier is read and a process routing data object is generated. The process routing data object includes at least the operation number, operation name, operation sequence, set of input material codes for the operation, set of output material codes for the operation, equipment resource identifier for the operation, tooling resource identifier for the operation, time quota information for the operation, and quality requirement information for the operation. Subsequently, a set of process documents is generated based on the process routing data objects. The set of process documents includes at least process specification documents, work instruction documents, and inspection guidance documents. Process specification documents describe the process plan and key parameters, work instruction documents describe the operation steps and precautions for the operation, and inspection guidance documents describe the inspection methods and judgment criteria. When generating the set of process documents, a file fingerprint value, version number, status identifier, creator identifier, and creation timestamp are written to each process document, and an association is established with the corresponding process routing data object. At the same time, an association is established between the process document and the corresponding material node in the BOM. The file fingerprint value of the process document is also calculated and written in the following way: File fingerprint value = ; After the process route and process documents are generated, a 3D structured process generation and process simulation verification are performed. A 3D structured process refers to a data object formed by structurally annotating process information such as assembly sequence, assembly posture, tooling position, and key inspection points according to the process route based on a 3D model. When generating a 3D structured process, the manufacturing structure tree of the 3D model and the manufacturing bill of materials is read. A sequence of process views is established according to the process sequence of the process route data object, and corresponding equipment resource identifiers, tooling resource identifiers, and quality requirement information are bound to each process view to form a 3D structured process data object, and its version number and status identifier are recorded. Subsequently, process simulation verification is performed: the 3D structured process data object is loaded into the simulation environment, and the assembly and processing process of the process view sequence is simulated. Assembly interference, motion collisions, assembly accessibility, and tooling positioning rationality are detected. When interference or collision is detected, a simulation problem record is generated, and the simulation problem record is bound and stored with the corresponding process number, material code, and tooling resource identifier. Simultaneously, the corresponding process view is marked as abnormal. After the simulation problem record is processed and verification is closed, the status identifier of the 3D structured process data object is updated to approved.

[0035] After the 3D structured process reaches the approved state, the manufacturability review rules are executed and the review results are solidified. The manufacturability review rules are a pre-established set of rules; for each manufacturability review rule, the rule number, rule conditions, rule threshold, and scope of application are recorded. During rule execution, the set of 2D drawings, 3D models, manufacturing bill of materials, and process documents is read, and each rule is executed sequentially according to its number, outputting the review conclusion. For rules with threshold determinations, a threshold determination formula is used for judgment. For example, when the rule condition is that the line width is not less than the rule threshold, and the line width is defined as W, and the rule threshold as T, the determination expression is: WT≥0; Where W represents the line width value read from the 2D drawing or design parameters; T represents the rule threshold value corresponding to the rule number; when W−T<0, a review issue record is generated and a review failure conclusion is output. For each review failure conclusion, a review issue record is generated and bound with the rule number, material code, issue location identifier, and issue description, and a pending task is generated at the same time; after the review issue record is closed, the corresponding 2D drawing, 3D model, manufacturing bill of materials, or process document generates a new version number and records the change responsible person identifier and change timestamp, until the review is passed.

[0036] Step 3: Controlled Execution of Engineering Changes and Impact Analysis; First, the controlled execution process for engineering changes is triggered. An engineering change refers to the modification, structural adjustment, or attribute update of any controlled object within a controlled state, such as a 3D model, 2D drawings, engineering bill of materials, process bill of materials, manufacturing bill of materials, process route data objects, process document sets, or 3D structured process data objects. The controlled execution process for engineering changes begins with an engineering change request: when the requester identifies an object requiring change, an engineering change request is generated and a change request number is written. The request also includes the reason for the change, the scope of the change, the set of design object identifiers involved, the set of material codes involved, and the set of requirement item numbers associated with the change. The reason for the change must at least include the source type and the source carrier identifier. The source type must at least include customer requirement input, quality anomaly records, legal or compliance clauses, and internal review opinions. The source carrier identifier is a verifiable carrier number.

[0037] After an engineering change request is established, object locking and version baseline recording are performed. For each controlled object associated with the engineering change request, its current version number and file fingerprint value are read, and a version baseline record is generated. The version baseline record includes at least the object identifier, object type, current version number, file fingerprint value, status identifier, record timestamp, and record responsible person identifier. Subsequently, the object status identifier is set to "Under Change," and a locking record is generated. The locking record includes at least the object identifier, locking timestamp, and locking responsible person identifier. After completing the above actions, the engineering change request enters the change impact analysis phase.

[0038] The locking record is used to constrain the baseline version of the controlled object from being directly overwritten by uncontrolled methods during the locking period, but it does not exclude the submission of candidate versions in parallel around the same design object identifier under the controlled process; the candidate version participates in the generation and updating of the version baseline record, structural difference record, simulation problem record and review problem record as the change content to be reviewed during the locking period, until the engineering change review is approved and the target version number strategy is uniformly determined by the engineering change instruction and implemented.

[0039] It should be noted that after the controlled execution process of engineering changes has generated engineering change request numbers, version baseline records, and lock records, a certain engineering change request may simultaneously reference the source carrier identifier of regulations or compliance clauses and the source carrier identifier of quality anomaly records. Furthermore, the set of material codes involved in the engineering change request may exhibit a structural mapping phenomenon of identical codes in different positions in the engineering bill of materials, process bill of materials, and manufacturing bill of materials. That is, the same material code may correspond to different hierarchical positions, different assembly unit affiliations, and different process route identifiers in the three types of lists. During the lock period, multiple responsible persons may submit candidate versions in parallel within the controlled scope around the same design object identifier. This causes the same object to exhibit rapid growth in version numbers and changes in file fingerprint values ​​on adjacent timestamps, followed by recovery and further changes. At the same time, structural difference records may exhibit a combination of added nodes, moved nodes, and deleted nodes on adjacent timestamps. This results in the repeated reorganization of the structural hierarchy of the same material code, making it impossible to express with a one-time static list.

[0040] Meanwhile, the conclusions of the process simulation verification and manufacturability review rules do not converge monotonically for the candidate versions. Specifically, the collision conclusions of the same three-dimensional structured process data object for the same assembly are flipped under different process view sequences, and the review issue record corresponding to the same issue location identifier is closed and reopened in a loop after the two-dimensional drawing version number changes. During this loop, the set of design object identifiers and the set of material codes involved in the engineering change request continue to expand and converge between adjacent timestamps. However, the expansion and convergence are not synchronized between different record types. As a result, if only a single record type or only the scope of the first submission is used at any point in time, there will be situations where the object boundary repeatedly regresses, the conclusion cannot be verified, or key objects are missed. Therefore, in this embodiment, during the change impact analysis phase, the following steps are performed: evidence slice alignment, object mapping solidification, quantification sequence construction, dual-boundary update, and propagation layer number stabilization. Evidence slice alignment refers to aligning locked records, version baseline records, structural difference records, simulation issue records, and review issue records according to consecutive timestamps to obtain an evidence set at the same point in time. Object mapping solidification refers to solidifying the structural positions of the same material code in the engineering bill of materials, process bill of materials, and manufacturing bill of materials using structural path identifiers into a replayable mapping. Quantification sequence construction refers to extracting data from the evidence set of engineering change request numbers at consecutive timestamps, calculating, and forming a sequence. Dual-boundary update refers to simultaneously generating convergence boundaries and conservative boundaries at the same timestamp and outputting the current list of affected objects between them based on the evidence status. Propagation layer number stabilization refers to performing consistency constraints and recalculation on the propagation layer numbers while updating the boundaries, ensuring that a verifiable hierarchical relationship can still be formed even under conditions of identical codes being out of place and record oscillations.

[0041] First, an object mapping index is constructed and structural path identifiers are fixed. The engineering bill of materials (BOM), process bill of materials (BOM), and manufacturing bill of materials (BOM) are read. For each material code, its structural path identifier in each of the three lists is extracted. The structural path identifier is the hierarchical sequence identifier from the root node to the material node. The material code, the engineering BOM structural path identifier, the process BOM structural path identifier, and the manufacturing BOM structural path identifier are combined to form an object tuple, and the object tuple is written into the object mapping index. The object mapping index is also written with a generation timestamp and a generation responsible person identifier. For any material code, if there is an inconsistency in its three structural path identifiers, the material code is marked as having the same code but different positions as true, and the three structural path identifiers are retained as is as location evidence.

[0042] The structural path identifier is written in an ordered representation of a hierarchical sequence. The ordered representation includes at least one of the following two methods: one is a path string concatenated in hierarchical order; the other is a sequence of node identifiers arranged in hierarchical order. Regardless of the method used, the generation rules for the same structural path identifier are kept consistent in the engineering bill of materials, process bill of materials, and manufacturing bill of materials, and the identifier is bound to the object mapping index for replayable mapping.

[0043] Subsequently, a timestamp set is constructed based on the engineering change request number, forming an evidence slice sequence. The locking record is read to obtain the locking start timestamp, and a timestamp set is generated between the locking start timestamp and the current timestamp at a preset sampling interval. The sampling interval is set as an example, such as 5 minutes. For each timestamp in the timestamp set, the most recent version baseline record, structural difference record, simulation issue record, and review issue record prior to that timestamp are retrieved to form the evidence slice corresponding to that timestamp. If there are no searchable records of a certain record type before the timestamp, the record type is set to empty in the evidence slice and recorded as an empty marker to ensure that the evidence slice sequence can be generated continuously.

[0044] Each evidence slice should include at least the record number, status identifier, set of design object identifiers involved, set of material codes involved, set of problem location identifiers, and process view sequence identifier. The evidence slices are then arranged into an evidence slice sequence according to their timestamps, and the sequence generation timestamp and the identifier of the person responsible for generation are recorded.

[0045] After forming the evidence slice sequence, a quantization sequence is constructed, and the source record number is recorded for each quantization. For each timestamp of the evidence slice, the following quantizations are calculated and written: lock duration, file fingerprint jump variable, file fingerprint bounce, structural difference complexity measure, structural difference oscillation, simulation unclosed strength, review unclosed strength, conclusion flip density, same code misalignment offset, boundary drift, and boundary backoff. The lock duration is defined as the difference between the current timestamp and the lock start timestamp. The file fingerprint jump variable is defined as the count of whether the file fingerprint value of the same design object identifier changes between two adjacent version baseline records; the file fingerprint bounce is defined as the count of the bounce pattern of the same design object identifier reverting to the previous file fingerprint value after changes in three consecutive version baseline records, where the bounce pattern satisfies the file fingerprint value sequence. and As a condition for judgment, This represents the file fingerprint value of the T-th record. The structural difference complexity measure is defined as the numerical value obtained by mapping the number of newly added nodes, deleted nodes, and moved nodes in the structural difference record, denoted as: ; in, , , These represent the number of newly added nodes, deleted nodes, and moved nodes in the structural difference record corresponding to timestamp T, respectively. To map the coefficients and write them to the parameter record, the coefficient values ​​are set as examples; the structural difference oscillation is defined as the sum of the absolute values ​​of the changes in the structural difference complexity measure at adjacent time points, denoted as... The simulation unclosed intensity is defined as the number of simulation problem records in the evidence slice corresponding to the current timestamp that are not closed; the review unclosed intensity is defined as the number of review problem records in the evidence slice corresponding to the current timestamp that are not closed. The conclusion flip density is defined as the total number of times the closing status of simulation problem records and review problem records flips within a sliding time window of length L, divided by the length of the sliding time window, where the length L is given as an example. The boundary drift is defined as the number of elements in the symmetrical difference between the sets of material codes involved in two adjacent timestamps; the boundary rollback is defined as the number of elements that decrease in the set of material codes involved in the current timestamp relative to the previous timestamp. The same code misalignment offset is defined as the proportion of material codes in the object mapping index whose same code misalignment status is true in the current set of material codes involved.

[0046] Among them, the state flipping refers to the state change of the same simulation problem record or the same review problem record in the evidence slices of two adjacent timestamps, from not closed to closed or from closed to not closed; each such state change is counted as a flip, and the same record can be counted cumulatively within the sliding time window; the length L of the sliding time window is defined as the number of consecutive timestamps participating in the statistics, and the timestamp step size of the evidence slice sequence is used as the statistical step size.

[0047] After obtaining the quantized sequence, two types of recursive values ​​are maintained for each quantized quantity: a smoothed value and an inertial value, and a state gating factor under the timestamp is formed accordingly. The smoothed value is denoted as... The inertia value is denoted as The smoothing value uses a recursive expression: ; Where λ is a parameter in the interval [0,1] and is written into the parameter record, with values ​​set as examples. The inertia value is used to account for the hysteresis effect of bounces and flips, and is expressed using a recursive expression: ; Where μ is a parameter in the range [0,1] and is written into the parameter record, and its value is set in the form of an example; This indicates that inertia is accumulated only for upward changes. Inertia values ​​are maintained for the document fingerprint bounce, conclusion flip density, structural difference oscillation, and boundary drift, respectively, to preserve their impact even during short-term declines. The state gating factor is then calculated. The state gating factor is used to determine whether the current timestamp is closer to a convergent state or an oscillating state. The calculation expression is: ; in, S-shaped function ; The inertial value of the file fingerprint bounce. The conclusion is the inertial value of the flipped density. This represents the inertial value of the structural differential oscillation. This is a smoothed value for the boundary drift. Set the coefficients and write them to the parameter record. When A value close to 1 indicates a state more inclined towards oscillation; when... A value close to 0 indicates that the state is more inclined to convergence.

[0048] After obtaining the state gating factor, convergence and conservative boundaries are generated simultaneously, and a list of currently affected objects is output. Both convergence and conservative boundaries are based on material codes, forming candidate sets respectively. and For each material code, an object-level evidence hit vector is calculated. This vector contains at least five components: structural difference hit, simulation not closed hit, review not closed hit, document fingerprint jump hit, and same code misalignment hit. Each component takes a value of 0 or 1 and is determined by evidence slicing. Subsequently, two forms of object-level scoring are calculated: a convergence score is applied to the convergence boundary. Conservative scoring is applied to the conservative boundary. The convergence scoring employs enhanced terms for smoothing values ​​of structural difference complexity measures and document fingerprint jump variables, and applies a suppression term to the smoothing value of same-code misalignment offset. The conservative scoring employs enhanced terms for smoothing values ​​of simulation unclosed intensity and review unclosed intensity, and applies enhanced terms to the inertia values ​​of document fingerprint backslip and conclusion flip density. To avoid a single linear weighting, the scoring uses a multiplicative, truncated structure: for any material code, the multiplicative core term M is first calculated, and then mapped to a score according to the truncated threshold, denoted as: ; ; in, The set of components involved in the calculation; The value of the corresponding component or the intensity value obtained by mapping from the smooth value or the inertia value; Assign component coefficients and write them to the parameter record; To truncate the scale parameter and write it to the parameter record, the values ​​are set as examples. This structure allows the score to be non-linearly amplified when multiple pieces of evidence appear simultaneously, while a single piece of evidence is insufficient to quickly boost the score. Subsequently, object thresholds are set for convergent and conservative scores respectively. and The threshold is not set as a constant, but varies with the smoothing values ​​of the same code misalignment offset and boundary drift: when the same code misalignment offset or boundary drift increases, Upward adjustment Adjust downwards; reverse the adjustment when both decrease. The threshold adjustment magnitude is written to the threshold sequence record. This will satisfy... Add material code , will satisfy Add material code .

[0049] After obtaining the two candidate sets, output the list of affected objects at the current timestamp. The list of affected objects is selected by interpolation between two candidate sets using a state gating factor, defined as follows: ; in, This is the indicator function; γ is the gating threshold and is written to the parameter record, with values ​​set as examples. When When this happens, objects that are in the conservative candidate set but not in the convergent candidate set are merged into the conservatism candidate set. ;when At this time, only the set of objects whose intersection with the convergent candidate set is more consistent is retained to suppress repeated boundary rollbacks. This output rule and its parameters are stored in a bound manner with the engineering change request number to ensure verifiability.

[0050] In obtaining Next, the propagation layer number is calculated and consistency constraints are applied to the propagation layer number. An adjacency set is constructed: the parent-child structural relationships of the engineering bill of materials, process bill of materials, and manufacturing bill of materials are read to establish structural adjacencies; the assembly constraint relationships of the 3D model are read to establish assembly adjacencies; the two types of adjacencies are merged to form an adjacency set. Each adjacency is then written with a relationship source identifier and an establishment timestamp. The set of objects from which engineering changes originate is determined. This is the set of objects directly modified in the engineering change request. A propagation layer set is generated by expanding layer by layer, and the calculation is as follows: ; The iteration stopping condition is If the set is empty or the maximum number of layers has been reached (the maximum number of layers is set as an example, e.g., 5), the layer number of each object is written into the propagation layer number. Then, a propagation layer number consistency constraint is executed: for material codes with the same code but different positions (true), if the difference in layer depth between the engineering bill of materials structure path identifier and the manufacturing bill of materials structure path identifier exceeds a preset depth threshold, its propagation layer number is appended to the path evidence field. The path evidence field contains the values ​​of the three types of structure path identifiers and the depth difference; the depth threshold is set as an example, e.g., 2. Furthermore, when the propagation layer number of this type of object jumps between two adjacent timestamps and exceeds a preset jump threshold, a recalculation of the propagation layer number is triggered: the object and its adjacent set are merged into the propagation layer number. The layer expansion calculation is then re-executed, with the transition threshold set as an example, such as a transition threshold of 2 layers. The recalculation process for the propagation layer number records the timestamp of the recalculation trigger, the material code of the triggering object, and the trigger reason field, and binds and stores them with the boundary update record.

[0051] Finally, perform boundary update and solidification, and write the replayable record. Set the current timestamp... Converging candidate set Conservative candidate set State gating factor Object threshold , The original values ​​and smoothed or inertial values ​​of each quantified quantity, along with the set of evidence slice record numbers involved in this calculation, are written into the boundary update record. The boundary update record must include at least the engineering change request number, timestamp, list of affected objects, propagation layer number, path evidence field, reference to gating-related parameter records, and set of evidence slice record numbers. For boundary update records with adjacent timestamps, the set difference of the list of affected objects is calculated and written into the difference field, along with the values ​​of boundary backoff and boundary drift. When the difference field shows alternating expansion and convergence within the sliding time window and the conclusion flip density is higher than the flip threshold, the time window is written into the oscillation interval field, and the values ​​within the window are recorded. The sequence and file fingerprint bounce inertia value sequence are used for playback. After the boundary update record is generated, the list of affected objects with the current timestamp is written to the list of affected objects of the engineering change request, and the propagation layer number and path evidence field are written to the corresponding fields. At the same time, the responsible person identifier and the writing timestamp are recorded.

[0052] After the scope of impact is identified, the engineering change review and engineering change instruction generation are performed. During the engineering change review, the engineering change request number, reason for change, scope of change, version baseline record, and overall impact score are retrieved. Information such as the scope of impact (U) and structural differences is used to form the review input, and a review timestamp is recorded. Upon successful review, an engineering change order is generated and an engineering change order number is written. The engineering change order must include at least: the set of object identifiers to be modified, the target version number strategy for each object, the set of material codes to be updated, the set of process route data objects to be updated, the set of process documents to be updated, and the set of verification and validation items to be re-executed. The engineering change order number is then bound to the engineering change request number. If the review fails, the rejection reason is written in the engineering change request, and the object lock record is either released or maintained until the engineering change request is closed.

[0053] After an engineering change order is generated, the engineering change is implemented, differences are fixed, and the review is closed. During implementation, modifications are made to each of the relevant 3D models, 2D drawings, engineering bill of materials (BOM), process bill of materials (BOM), manufacturing bill of materials (BOM), process route data objects, process document sets, and 3D structured process data objects according to the engineering change order. Each submission recalculates the file fingerprint value and generates a new version number, recording the change responsible person's identifier and change timestamp. For modifications involving changes to the BOM structure, a new structural difference record is generated and bound to the engineering change order number for storage. After implementation, a review is performed: consistency checks are re-executed on the engineering BOM, process BOM, and manufacturing BOM; manufacturability review rules are re-executed; and process simulation verification is re-executed. The review results are written to the review record; the review record includes at least the review item identifier, review conclusion, reviewer identifier, and review timestamp. After review approval, the status identifier of the locked object is updated to "approved," and an unlock record is generated; the unlock record includes at least the object identifier, unlock timestamp, and unlock responsible person identifier. Finally, update the status of the engineering change request to "closed" and record the closing timestamp and the identifier of the person responsible for closing.

[0054] Step 4: Production process traceability and quality closed-loop improvement, delivery archiving and knowledge base accumulation; First, production tasks are generated and production object identifiers are established. The manufacturing bill of materials and process route data objects are read, and a set of production tasks is generated according to the process sequence. For each production task, a production task number, process number, process name, process input material code set, process output material code set, process equipment resource identifier, process tooling resource identifier, process time quota information, and process quality requirement information are written, along with the issuance timestamp and the identifier of the person responsible for issuing the task. Next, a product identifier is established for each product or batch of products to be produced. A product identifier is an identifier used to uniquely identify an individual product or batch; product identifiers can be carried by barcodes, QR codes, or RFID tags. RFID tags are electronic tags that are read and written non-contactly using radio frequency signals, and their tag numbers serve as a form of product identifier. After the product identifier is established, it is bound to the corresponding production task number and material code set, and the binding timestamp and the identifier of the person responsible for binding are recorded.

[0055] After establishing the production object identifier, the production process data collection, writing, and traceability chain construction are executed. For each process in the production task set, production process data is collected and written into the production process record according to the process quality requirements and process parameter requirements. The production process data includes at least the process start timestamp, process end timestamp, operator identifier, equipment resource identifier, tooling resource identifier, key process parameter values, and process inspection results. The data source for key process parameter values ​​is one or more of the following: equipment-collected data, manually entered data, or inspection equipment output data. The data source identifier is recorded during writing; the data source identifier indicates which collection method and corresponding carrier number the parameter value comes from. For each production process record, the product identifier, production task number, process number, and record timestamp are written, thus forming a chain of association between product identifier, process number, parameter value, and inspection result.

[0056] Subsequently, a traceability chain is constructed: for the same product identifier, the production process records generated in each process are aggregated in sequence to form a product traceability record. The product traceability record includes at least the complete sequence of process numbers corresponding to the product identifier, the sequence of key process parameter values ​​for each process, the sequence of process inspection results for each process, and the set of material codes used and their corresponding batch identifiers. The batch identifier is a unique identifier for a material batch or incoming material batch. When writing the batch identifier, the supplier source carrier identifier is also written to ensure the material source is verifiable.

[0057] While production process records are continuously written, production scheduling optimization calculations are performed, and scheduling result records are generated. Production scheduling optimization refers to calculating the execution order and start time arrangement of production tasks on equipment resources under the constraints of production task set, equipment resource identifier set, tooling resource identifier set, and process time quota information, and outputting executable scheduling results. The objective function of scheduling optimization is to minimize the completion time, which is defined as the maximum value of the end timestamps of all production tasks, denoted as . The scheduling optimization uses genetic algorithms and particle swarm optimization algorithms as computational methods to generate candidate scheduling solutions and output scheduling result records.

[0058] When using a genetic algorithm to calculate the scheduling results, a scheduling candidate solution is encoded as a chromosome. The chromosome consists of a sequence of production task numbers and its corresponding equipment resource identifier sequence. Here, chromosome refers to the data encoding structure used to represent a candidate solution for scheduling; population refers to a set of multiple chromosomes; crossover refers to the operation of exchanging partial encoding segments between two chromosomes to generate a new chromosome; and mutation refers to the operation of randomly perturbing the local position of the chromosome encoding to generate a new chromosome.

[0059] For each chromosome, its completion time is calculated based on the process time quota information and the available time of equipment resources. And define the fitness function as: ; Where F is the fitness value, This refers to the completion time corresponding to that chromosome; The smaller the value, the larger F becomes. The selection operation of the genetic algorithm uses a ratio based on fitness, and the selection probability of the i-th individual is defined as: ; in, Let be the probability that the i-th individual is selected. Let be the fitness value of the i-th individual, and N be the population size. After selection, crossover and mutation operations are performed on the selected individuals to generate a new generation of scheduling candidate solutions, and the process iterates until a preset generation number or fitness convergence condition is met. Each iteration records the generation number and the fitness value of the optimal individual. Match the corresponding production task number sequence and generate a scheduling result record; When using the particle swarm optimization algorithm to calculate the scheduling results, a candidate scheduling solution is represented as a particle position vector. This particle position vector represents the set of sorting key values ​​for the production task number sequence. The production task number sequence is obtained by sorting the sorting key values ​​in ascending order. For each particle, its velocity vector and position vector are updated as follows: ; ; in, Let T be the velocity vector of the Tth iteration. Let be the position vector in the Tth iteration. This represents the historical best position vector of the particle up to the Tth iteration. Let be the global optimal position vector of the group up to the T-th iteration; W is the inertia weight parameter; and For learning factor parameters; and The result is a random number within the interval [0,1]. After the position vector is updated, the sorting key values ​​are sorted to generate a production task number sequence, and then the completion time is calculated based on the process time quota information. And update accordingly. and Each iteration records the iteration number and the group optimal value. Match the corresponding sequence and generate a scheduling result record; After the scheduling result record is generated, production execution writing and exception event handling are performed. The scheduling result record is mapped to the planned start time stamp and planned end time stamp of each production task number and written to the production task set; during execution, when the actual start time stamp or actual end time stamp deviates from the planned time stamp by more than a preset threshold, a production exception record is generated and the exception type, deviation value, trigger time stamp and triggering responsible person identifier are written.

[0060] Based on production process records and anomaly handling, quality process control, quality anomaly record generation, and quality traceability are implemented. Quality process control employs statistical process control methods; statistical process control refers to the method of statistically calculating the fluctuations of key process parameter values ​​over time and comparing them with control limits to identify process anomalies. For each key process parameter value, a sample sequence is extracted from the production process records according to a preset window length, and the sample mean is calculated. Calculate the upper and lower limits of control based on the sample standard deviation s: ; ; in, s is the sample mean, and s is the sample standard deviation. When a critical process parameter value collected in a certain period is greater than the upper control limit or less than the lower control limit, a quality anomaly record is generated. The quality anomaly record must include at least the product identifier, process number, critical process parameter name, critical process parameter value, upper control limit, lower control limit, anomaly timestamp, and anomaly responsible person identifier, and must also include a quality anomaly record number. The critical process parameter name comes from the process quality requirement information, and the critical process parameter value comes from the production process record and retains the data source identifier.

[0061] After a quality anomaly record is generated, quality traceability and location are performed: using the product identifier in the quality anomaly record as an index, the corresponding product traceability record is read, the process number, equipment resource identifier, tooling resource identifier, and material batch identifier where the anomaly occurred are located, and the location results are written into the traceability and location field of the quality anomaly record.

[0062] After the quality anomaly record is generated and traced back, the generation of the quality closed-loop improvement record and the writing back of the requirement tracking matrix are executed. The quality closed-loop improvement record refers to the record of the handling process of the problem corresponding to the quality anomaly record, which includes at least the root cause analysis conclusion, corrective action content, preventive action content, the identifier of the person responsible for implementing the action, the action implementation timestamp, and the verification conclusion. The root cause analysis conclusion can be from review conclusions, inspection conclusions, or on-site analysis conclusions, and the source carrier identifier is written in. The corrective action content can include revision actions on 3D models, 2D drawings, engineering bill of materials, process bill of materials, manufacturing bill of materials, process route data objects, process document sets, and 3D structured process data objects. If a revision occurs, the controlled execution process of engineering change in step three is triggered and a corresponding engineering change request number is generated. After the corrective action is implemented, a verification object identifier is generated and the verification object identifier is bound and stored with the quality closed-loop improvement record; the evidence carrier of the verification object identifier includes at least one or more of the following: inspection report, test record, or simulation verification result, and the source carrier identifier and generation timestamp are written in the evidence carrier. Subsequently, according to the set of requirement item numbers associated with the quality anomaly record, the corresponding verification object identifier is written into the verification object identifier field of the requirement traceability matrix, and the status identifier is updated according to the acceptance criteria: when the evidence corresponding to the verification object identifier meets the acceptance criteria, the status identifier is updated to closed, and the status change timestamp and the identifier of the person responsible for the change are recorded; when it does not meet the criteria, it remains unclosed, and a pending task is generated.

[0063] After the quality closed-loop improvement record is formed and written back, delivery inspection, deliverable generation, and delivery archiving are performed. Delivery inspection refers to the final inspection of the finished product corresponding to the product identification according to acceptance criteria and quality requirements, and the formation of a delivery inspection record. The delivery inspection record must include at least the product identification, inspection items, inspection results, inspector identification, and inspection timestamp. Deliverables refer to a complete set of documents related to product delivery. Deliverables must include at least the final version of two-dimensional drawings, engineering bill of materials, manufacturing bill of materials, process document set, inspection report, and certificate of conformity. When generating deliverables, the current version number and document fingerprint value of the relevant controlled object are read and written into the deliverable list. The deliverable list must include at least the deliverable name, object identification, version number, document fingerprint value, generation timestamp, and generation responsible person identification. The deliverable list is archived. During archiving, the deliverable list is bound to the product identification for storage, and the archiving timestamp and archiving responsible person identification are recorded. For deliverables requiring paper output, the archiving and printing action is performed, and the printing batch identification, printing timestamp, and printing responsible person identification are recorded.

[0064] After delivery archiving is completed, the enterprise knowledge base is consolidated and enhanced with artificial intelligence retrieval. The enterprise knowledge base refers to a collection of controlled documents, records, and conclusions generated during R&D, process, production, quality, and delivery processes, stored according to a unified field system and searchable. The basic storage unit in the enterprise knowledge base is the knowledge entry. When generating knowledge entries, summary information is extracted from review records, structural difference records, simulation problem records, inspection problem records, quality anomaly records, quality closed-loop improvement records, delivery inspection records, and deliverable lists, and written into the knowledge entry number, knowledge entry title, knowledge entry content, set of associated object identifiers, set of associated material codes, set of associated requirement item numbers, set of source carrier identifiers, generation timestamp, and generation responsible person identifier. The source carrier identifier set must at least include the original record number, such as the quality anomaly record number or engineering change request number, to ensure the knowledge entry is traceable. After the knowledge entry is written, the knowledge entry index is constructed: feature vectors are generated for the knowledge entry content and written into the vector field; the feature vector generation method is recorded as the vector generation method identifier. During retrieval, the system receives the query text and generates a query feature vector. Cosine similarity is used to calculate the similarity between the query feature vector and the knowledge item feature vector. The top k knowledge items are selected as the retrieval result set based on similarity. k is a preset parameter, with values ​​recorded as examples. After obtaining the retrieval result set, AI-enhanced retrieval generation is performed: AI-enhanced retrieval generation uses the knowledge item content in the retrieval result set as input citation evidence, generates response text through an AI generation model, and includes the cited knowledge item number and source carrier identifier in the response text, thus forming a citation chain record of response text, knowledge item number, and source carrier identifier. The citation chain record includes at least the query text, the set of cited knowledge item numbers, a generation timestamp, and the identifier of the person responsible for generation. The generated response text is output as a knowledge service and stored in conjunction with the query record.

[0065] This invention also proposes a full lifecycle management system, such as... Figure 2 As shown, it includes: a demand management module, a design control module, a change impact analysis module, a traceability closed-loop module, and signal connections between the modules; The requirements governance module is used to collect and store requirements data, structure them into requirements items, generate requirements item numbers, form requirements baseline version numbers and requirements traceability matrices, and split work packages according to requirements item numbers. The controlled design module is used to generate design object identifiers, controllably store 3D models and 2D drawings, construct engineering bill of materials and reconstruct process bill of materials and manufacturing bill of materials; The change impact analysis module is used to generate engineering change request numbers and write them into the version baseline record and lock record, construct evidence slice sequences and use object mapping index to solidify structural path identifiers and same code misaligned states, calculate quantification sequence and maintain smooth value and inertia value to generate state gating factor, output the list of affected objects between the convergence boundary and the conservative boundary according to the state gating factor and write it into the boundary update record and propagation layer number. The convergence boundary and the conservative boundary are both based on material code as objects, and the propagation layer number is used to characterize the layer extension level in the list of affected objects. The traceability closed-loop module is used to generate quality anomaly records and write the source carrier identifier, generate quality closed-loop improvement records and generate engineering change requests and write the engineering change request number, and write back the requirement tracking matrix and write the knowledge entries.

[0066] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0067] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0068] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0069] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0070] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0071] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A full lifecycle management method, characterized in that, include: Collect and store the requirement data into the database and structure it into requirement items. Generate requirement item numbers and form a requirement baseline version number and requirement traceability matrix. Split the work package according to the requirement item number. Generate design object identifiers, controllably import 3D models and 2D drawings into the warehouse, construct engineering bill of materials and reconstruct process bill of materials and manufacturing bill of materials; Generate an engineering change request number and write it into the version baseline record and lock record. Construct an evidence slice sequence and use an object mapping index to solidify the structural path identifier and the same code misaligned state. Calculate the quantization sequence and maintain the smooth value and inertia value to generate a state gating factor. Output the list of affected objects between the convergence boundary and the conservative boundary according to the state gating factor and write it into the boundary update record and the propagation layer number. The convergence boundary and the conservative boundary are both based on the material code as the object. The propagation layer number is used to characterize the layer extension level in the list of affected objects. Generate quality anomaly records and write the source carrier identifier; generate quality closed-loop improvement records and generate engineering change requests and write the engineering change request number; write back the requirements traceability matrix and write the knowledge entries.

2. The full lifecycle management method according to claim 1, characterized in that: Collect demand data and bind the demand source identifier, source carrier identifier, collection timestamp, and collection responsible person identifier to the demand data when it is entered into the database. Demand data that is missing a demand source identifier or source carrier identifier is set to not be entered into the database and a supplementary task is generated. The entered demand data is structured and converted into demand items and a unique demand item number is generated for the entire life cycle. At the same time, the demand item text, scope of application, priority, acceptance criteria, risk level, and demand source identifier are written into it, and the text, priority, and risk level are standardized.

3. The full lifecycle management method according to claim 2, characterized in that: Feature vectors are generated based on the text of the requirement items, and semantic similarity is calculated; a requirement baseline version number is generated for the requirement items that have passed the review, and the differences are recorded; a requirement tracking matrix is ​​constructed with the requirement item number as the row and the design object identifier, verification object identifier, and status identifier are written in it; the status is updated according to the verification evidence corresponding to the acceptance criteria; and the requirement items are split into work packages according to the baseline and the responsible persons, milestones, and deliverable constraints are bound to them; when the baseline is updated, the tracking matrix and the work package binding relationship are updated in conjunction.

4. The full lifecycle management method according to claim 3, characterized in that: Based on the requirement traceability matrix, generate or complete the design object identifier for each requirement item and record the timestamp and the responsible person identifier. Write the version number, status identifier and creation information of the 3D model and 2D drawings into the controlled database and calculate the fingerprint value of the written file before establishing a relationship with the design object identifier. The bill of materials is constructed according to the assembly structure, and the material nodes are verified to be consistent with the drawings or models and the version numbers. When an anomaly occurs, an anomaly record and a pending task are generated. When design data is modified and submitted, a new version number is generated by comparing the file fingerprint value and the version change information and status flow record are recorded. After the review is approved, it is updated to "approved". After the design object identifier has been approved, the engineering bill of materials is reconstructed into a process bill of materials and a manufacturing bill of materials with the material code unchanged as a constraint. The process route identifier and manufacturing attribute fields are written. During the reconstruction, structural difference records are written and the inclusion relationship of material code sets between the lists and the missing key fields are verified. Based on the manufacturing bill of materials, process routes and process documents are generated and file fingerprint values ​​and version information are written. Then, a three-dimensional structured process is generated and process simulation is performed to generate simulation problem records. Subsequently, manufacturability review rules are run to generate review problem records. When the problem is closed, the relevant data objects are driven to generate new version numbers and record change information.

5. The full lifecycle management method according to claim 4, characterized in that: After generating and writing the engineering change request number, the source carrier identifier of the change reason, and the set of involved objects, the version baseline record and lock record are written to the controlled objects, and the candidate version submission is allowed in parallel during the lock period. For the same code but different structure mapping, rapid version number growth accompanied by file fingerprint value rebound, structural difference addition, movement and deletion combination oscillation, simulation collision conclusion reversal and the asynchronous convergence of the impact range caused by the reopening after the review issue is closed, the lock record, version baseline record, structural difference record, simulation issue record and review issue record are aligned according to continuous timestamps to form an evidence slice sequence. The structural position of the same material code in the engineering bill of materials, process bill of materials and manufacturing bill of materials is solidified with structural path identifier and written into the object mapping index and marked as same code but different state. The candidate version is the controlled version with different version number submitted around the same design object identifier during the lock period.

6. The full lifecycle management method according to claim 5, characterized in that: For each timestamp evidence slice, calculate the quantization sequence of lock persistence, file fingerprint value jump and file fingerprint value bounce, structural difference complexity and structural difference oscillation, simulation unclosed strength, review unclosed strength, conclusion flip density, same code misalignment offset, boundary drift and boundary back, and maintain smooth and inertial values. Calculate the state gating factor based on multi-factor recursive values ​​to determine whether the current trend is more towards convergence or oscillation. Simultaneously generate convergence and conservative boundaries at the same timestamp. Select candidate sets by object-level evidence hit vector and multiplicative truncation scoring, combined with object thresholds adjusted with same code misalignment offset and boundary drift dynamics. Then, the state gating factor selects between the two candidate sets to output the current list of affected objects and writes it into the boundary update record and oscillation interval field. The path evidence field is used to record the structural path identifier corresponding to the same code misalignment state. Simultaneously, the parent-child relationship of the list and the three-dimensional assembly constraints are integrated to establish an adjacency set and calculate the propagation layer number by layer expansion. The same code but different depth difference and layer number transition trigger consistency constraints and recalculation and write them into the path evidence field. Thus, under the conditions of recording oscillation and structural reorganization, a playable list of affected objects and a verifiable hierarchical relationship are continuously output. The oscillation interval field is used to record the expansion and convergence alternation interval in the boundary update record.

7. The full lifecycle management method according to claim 6, characterized in that: In the production and quality stages, quality anomalies are recorded and their source carrier identifiers are written. By linking the product identifiers to the traceability records, the corresponding processes, equipment tooling, and material batches are located. Then, a quality closed-loop improvement record is generated. When it is necessary to revise the 3D model, 2D drawings, or various bills of materials and process data objects, an engineering change request number is generated and the relevant objects are included in the controlled changes. At the same time, a verification object identifier and its evidence carrier source carrier identifier are generated and written back to the verification object identifier field of the requirement tracking matrix to drive the status update of the acceptance criteria. The engineering change request number and the quality anomaly record number are written into the source carrier identifier set of the knowledge entry.

8. A full lifecycle management system for implementing the full lifecycle management method according to any one of claims 1-7, characterized in that, include: The module includes a demand management module, a design control module, a change impact analysis module, a traceability closed-loop module, and signal connections between these modules. The requirements governance module is used to collect and store requirements data, structure them into requirements items, generate requirements item numbers, form requirements baseline version numbers and requirements traceability matrices, and split work packages according to requirements item numbers. The controlled design module is used to generate design object identifiers, controllably store 3D models and 2D drawings, construct engineering bill of materials and reconstruct process bill of materials and manufacturing bill of materials; The change impact analysis module is used to generate engineering change request numbers and write them into the version baseline record and lock record, construct evidence slice sequences and use object mapping index to solidify structural path identifiers and same code misaligned states, calculate quantification sequence and maintain smooth value and inertia value to generate state gating factor, output the list of affected objects between the convergence boundary and the conservative boundary according to the state gating factor and write it into the boundary update record and propagation layer number. The convergence boundary and the conservative boundary are both based on material code as objects, and the propagation layer number is used to characterize the layer extension level in the list of affected objects. The traceability closed-loop module is used to generate quality anomaly records and write the source carrier identifier, generate quality closed-loop improvement records and generate engineering change requests and write the engineering change request number, and write back the requirement tracking matrix and write the knowledge entries.

Images