Intelligent evaluation system for product design based on big data

Abstract

The application discloses a product design intelligent evaluation system based on big data, and particularly relates to the technical field of product design evaluation, and the system comprises an anchor point account establishing module, a product evaluation module, a scheme rating module and a result output module; the anchor point account establishing module forms a design anchor point table according to a demand preliminary evaluation sheet and initial scheme information; the product evaluation module acquires a scheme change sheet and calls scheme verification data, and performs product undertaking verification; the scheme rating module combines the undertaking verification result and an auxiliary verification result to output a scheme evaluation state; and the result output module outputs product design intelligent evaluation results in a summarized manner. The application can continuously verify whether customer demand is undertaken by design parameters, versions, materials, processes, samples, costs and market feedback after scheme change, and can locate abnormalities to specific change fields, change components, anchoring relationships and data sources, thereby improving the traceability and review efficiency of evaluation results.

Description

Technical Field

[0001] This invention relates to the field of product design evaluation technology, and in particular to a product design intelligent evaluation system based on big data. Background Technology

[0002] The field of product design evaluation technology involves evaluation items in various stages of a product's lifecycle, from requirement identification, solution design, material selection, process matching, cost accounting, sample verification to market feedback collection. The evaluation criteria typically include customer requirements, design parameters, BOM data, drawing dimensional tolerances, material test records, process records, sample test results, after-sales feedback, and competitor parameters. Furthermore, the product design scheme is reviewed in accordance with the company's design specifications, industry standards, cost control tables, and quality inspection tables.

[0003] Traditional intelligent product design evaluation systems refer to computer application systems that use historical design documents, product BOMs, process routes, sample test reports, user evaluation texts, after-sales work orders, and competitor specification tables as data sources. Through methods such as field extraction, parameter comparison, threshold comparison, weight calculation, and result recording, they organize and evaluate product function configuration, structural dimensions, material usage, manufacturing processes, costs, test indicators, and market performance.

[0004] Existing product design evaluation systems primarily rely on extracting fields and comparing thresholds from historical forms, BOMs, test reports, after-sales work orders, and competitor specifications. They fail to continuously bind customer requirements to the fields, components, and version baselines in the initial solution. When the solution is revised, parameters are adjusted, materials are replaced, or processes are changed, it is difficult to determine whether the original customer requirements are still supported by the changed parameters, material testing, and process control. This can easily lead to the misuse of old fields, old versions, or old material test records, and the evaluation conclusions may not accurately pinpoint the mismatch in requirements. Summary of the Invention

[0005] The main objective of this invention is to provide a product design intelligent evaluation system based on big data, which can effectively solve the problems involved in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A product design intelligent evaluation system based on big data, the system comprising: The anchor point creation module obtains the initial requirement assessment form and initial plan information, extracts the anchoring benchmark group based on the initial plan information, reads the customer requirements in the initial requirement assessment form and matches them with the initial plan information to form the anchoring relationship, and associates the anchoring relationship with the anchoring benchmark group to form the design anchor point table. The product evaluation module obtains the scheme change order and matches it with the initial scheme information to obtain the scheme change information. It obtains the scheme verification data corresponding to the scheme change information from an external big data server through a preset interface. Based on the scheme change information, the scheme verification data, and the design anchor table, it performs product acceptance verification and summarizes the conclusions of the product acceptance verification into acceptance verification results. The scheme rating module calls the scheme verification data to perform scheme auxiliary verification to form auxiliary verification results, combines the acceptance verification results and auxiliary verification results to determine the status relationship, and outputs the scheme evaluation status. The results output module extracts the scheme change information and corresponding anchoring relationships involved in the state relationship determination and collects them into evaluation trigger information. The evaluation trigger information is combined with the scheme evaluation status, acceptance verification results and auxiliary verification results and output as the product design intelligent evaluation results.

[0007] Preferably, the initial requirement assessment form records customer requirements and their corresponding requirement judgment rules. The requirement judgment rules include requirement target values, constraint directions, and tolerance zones. The requirement target values ​​include one or more of the following: parameter target values, material performance target values, process control target values, sample verification target values, and cost target values. The initial scheme information includes design evaluation information and version information. The design evaluation information includes field names, field baseline values, field units, and field mapped components. The anchoring baseline group includes field names, field baseline values, and version information.

[0008] Preferably, the specific matching process of the anchoring relationship is as follows: read customer requirements and requirement judgment rules, obtain design evaluation information corresponding to customer requirements from initial solution information, and when at least one of the field names and field mapping components in the design evaluation information matches the customer requirements, the field unit is consistent with or convertible to the unit of the requirement target value, and the field benchmark value conforms to the requirement judgment rules, it is determined that the design evaluation information can be used as the judgment basis of the requirement judgment rules; when the design evaluation information can be used as the judgment basis, an anchoring relationship between customer requirements and corresponding design evaluation information is generated; otherwise, an unanchored prompt message is generated and the corresponding customer requirements are transferred to manual review. When manual review confirms that it can be anchored, the corresponding anchoring relationship is generated and associated with the anchoring benchmark group and written into the design anchor point table.

[0009] Preferably, the scheme change information includes the changed design parameters, changed fields, changed components, and version change information; the scheme verification data includes parameter verification data, material verification data, process verification data, sample verification data, current cost data, after-sales feedback data, and competitor comparison data, wherein the parameter verification data includes the field name and current value of the field corresponding to the anchoring relationship.

[0010] Preferably, the product acceptance verification includes parameter anchoring verification and version retention verification. The parameter anchoring verification reads the current value of the field from the parameter verification data based on the field name in the anchoring relationship, and calls the requirement judgment rule and the corresponding parameter target value to determine the parameter achievement status. The version retention verification compares the version change information in the anchoring benchmark group and the solution change information, and determines the field retention status based on the field name in the parameter verification data. It then combines the requirement judgment rule to determine the version retention verification result, which includes version consistency, anchor retention, or anchor failure.

[0011] Preferably, the product acceptance verification also includes material acceptance verification. The material acceptance verification calls the material data and performance test records in the material verification data, obtains the material performance target value associated with the anchoring relationship based on the changed components in the scheme change information, determines the component performance requirements based on the material performance target value, judges the correspondence between the material data and the performance test records and the achievement of the component performance requirements, and forms the material acceptance status of acceptance achieved, insufficient acceptance or broken acceptance chain.

[0012] Preferably, the product acceptance verification also includes process support verification. The process support verification calls the process execution data range in the process verification data, determines whether the process execution data range corresponds to the field name in the anchoring relationship, and determines whether the process execution data range meets the requirement judgment rule of the corresponding process control target value, and outputs the process support status.

[0013] Preferably, when the process execution data interval does not correspond to the field name in the anchoring relationship, the process support status is insufficient inspection coverage; when the process execution data interval corresponds to the field name in the anchoring relationship but does not meet the requirement judgment rule for the corresponding process control target value, the process support status is insufficient process boundary; when the process execution data interval corresponds to the field name in the anchoring relationship and meets the requirement judgment rule for the corresponding process control target value, the process support status is achieved; the acceptance verification results include parameter achievement status, version maintenance verification results, material acceptance status, and process support status.

[0014] Preferably, the auxiliary verification of the solution includes: verifying whether the sample verification data achieves the sample verification target value based on the demand determination rule, and outputting the sample verification result of achievement or non-achievement; reading the current cost data and substituting it into the demand determination rule to determine whether the cost target value is achieved, and outputting the cost verification result of cost compliance or cost exceeding the limit; outputting the after-sales reason pointing status of hit or miss based on the pointing relationship between after-sales feedback data and solution change information; comparing and analyzing the solution change information with competitor comparison data, and outputting the competitor comparison status of parameter competitive disadvantage, material competitive disadvantage, or no competitive disadvantage; the sample verification result, cost verification result, after-sales reason pointing status, and competitor comparison status are summarized to form the auxiliary verification result.

[0015] Preferably, the state relationship determination is as follows: when the parameter achievement state is not achieved or the version maintenance verification result is anchor failure, output parameter correction state; when the material acceptance state is insufficient acceptance or acceptance chain break, output material correction state; when the process support state is insufficient inspection coverage or insufficient process boundary, output process correction state; when the sample verification result is not achieved, output sample verification correction state; when the cost verification result is cost exceeding limit, output cost review state; when the after-sales reason pointing state is hit, or the competitor comparison state is parameter competitive disadvantage or material competitive disadvantage, output market adaptation correction state; when none of the above conditions are met, output design evaluation passed state; when the same scheme change information simultaneously meets multiple state relationship determination conditions, output the scheme evaluation state in the first position according to the preset determination order, and the remaining triggered scheme evaluation states are used as associated scheme evaluation states.

[0016] Compared with the prior art, the present invention has the following beneficial effects: This invention pre-anchors customer requirements to fields, components, and version baselines in the initial solution, and synchronously verifies parameter achievement, version maintenance, material performance, process boundaries, sample testing, cost, and market feedback around the same anchoring relationship after solution changes. Therefore, the system can not only determine whether a changed solution is approved, but also pinpoint anomalies to specific changed fields, components, version change information, and data sources, distinguishing between simple version changes, parameter failures, material supply chain disruptions, and insufficient process support. This reduces manual table-by-table tracing and misuse of old test records, improving the executability of review conclusions and the efficiency of verification. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the overall system flow of the present invention. Figure 2 This is a flowchart of the anchor point account creation module of the present invention; Figure 3 The flowchart illustrates the auxiliary verification and status relationship determination process for the present invention. Detailed Implementation

[0018] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0019] See Figure 1 This invention discloses a product design intelligent evaluation system based on big data, the system comprising: The anchor point creation module obtains the initial requirement assessment form and initial plan information, extracts the anchoring benchmark group based on the initial plan information, reads the customer requirements in the initial requirement assessment form and matches them with the initial plan information to form the anchoring relationship, and associates the anchoring relationship with the anchoring benchmark group to form the design anchor point table. The product evaluation module obtains the solution change order and matches it with the initial solution information to obtain the solution change information. It retrieves the solution verification data corresponding to the solution change information from the external big data server through a preset interface. Based on the solution change information, solution verification data and design anchor table, it performs product acceptance verification and summarizes the conclusions of the product acceptance verification into acceptance verification results. The scheme rating module calls the scheme verification data to perform auxiliary verification of the scheme and generate auxiliary verification results. It combines the acceptance verification results and auxiliary verification results to determine the status relationship and outputs the scheme evaluation status. The results output module extracts the scheme change information and corresponding anchoring relationships involved in the state relationship determination and collects them into evaluation trigger information. The evaluation trigger information is combined with the scheme evaluation status, acceptance verification results and auxiliary verification results and output as the product design intelligent evaluation results.

[0020] This technical solution is primarily applied to intelligent evaluation scenarios in manufacturing enterprises following product design changes. It is particularly suitable for product review processes that require simultaneous verification of customer requirements, design parameter attainment, version consistency, material performance support, process control, sample validation, cost constraints, and regional market feedback. The system can access design, BOM, process, testing, cost, after-sales, and competitor data, mapping design changes to design anchor points and outputting traceable evaluation results, providing a basis for design review and solution adjustment.

[0021] Based on the above application scenarios, the following describes the specific implementation process of this technical solution in conjunction with the data flow relationships between the various functional modules of the system. It should be noted that the following implementation process is described using the evaluation after a change in the product design scheme as an example. Its purpose is to illustrate the establishment of design anchor points, the retrieval of scheme verification data, the execution of acceptance verification and auxiliary verification, and the output method of evaluation results, and is not intended to limit the scope of protection of this technical solution.

[0022] Example 1, see Figure 2In the operation of this embodiment, the system first reads the initial requirement evaluation form and initial scheme information. The initial requirement evaluation form is used to record the customer requirements and requirement judgment rules formed in the initial review stage of the product to be evaluated. The customer requirements can come from existing business documents such as customer requirement forms, project establishment review forms, product definition documents, regional requirement feedback forms, or sales requirement summary forms. Its function is to provide the requirement-side basis for the subsequent verification of design parameters, material properties, process control, sample verification, and cost status. The requirement judgment rules include requirement target values, constraint directions, and tolerance zones. Requirement target values ​​include one or more of the following: parameter target values, material performance target values, process control target values, sample verification target values, and cost target values. The constraint direction is used to indicate the judgment method of the corresponding requirement target value, and the tolerance zone is used to indicate the allowable range of values ​​deviating from the requirement target value.

[0023] Among them, the parameter target value is used to characterize the structural dimensions, functional configuration, assembly clearance, or other quantifiable design parameters corresponding to customer requirements; the material performance target value is used to characterize the evaluation requirements of the field-mapped component in terms of strength, durability, or other material properties; the process control target value is used to characterize the control boundaries that need to be met during processing or assembly; the sample verification target value is used to characterize the verification requirements that the sample measured data needs to meet; and the cost target value is used to characterize the cost control requirements of the corresponding product, component, or solution. The constraint direction can be used to distinguish judgment methods such as not less than the target value, not greater than the target value, or within the tolerance zone, so that the system can judge the field benchmark value or the field current value according to a unified rule during subsequent verification.

[0024] Initial scheme information is used to record the scheme-side data corresponding to customer requirements in the initial design scheme. Initial scheme information includes design evaluation information and version information. Design evaluation information includes field name, field baseline value, field unit, and field mapping component. Field name is used to identify the parameter field participating in the evaluation in the design scheme. Field baseline value is used to indicate the value of the field in the initial scheme. Field unit is used to limit the dimension of the field baseline value. Field mapping component is used to indicate the product component or structural location corresponding to the field. Version information is used to identify the drawing version, BOM version, or process card version of the initial scheme, so that when the scheme is changed, the version can be verified based on the initial scheme.

[0025] The system extracts anchoring benchmark groups based on the initial solution information. The anchoring benchmark groups include field names, field benchmark values, and version information. The anchoring benchmark groups are used to save the initial verification benchmarks corresponding to the completion of customer requirements anchoring. In the subsequent solution change process, the system can use the anchoring benchmark groups to determine whether the fields corresponding to the original customer requirements are still retained, whether the current values ​​of the fields can still be judged according to the requirements judgment rules, and whether the version change affects the continuity of the corresponding anchoring relationship.

[0026] When performing anchoring relationship matching, the system reads customer requirements and their corresponding requirement judgment rules, and obtains design evaluation information corresponding to customer requirements from the initial solution information. When at least one of the field names and field mapping components in the design evaluation information matches the customer requirements, the field unit is consistent with or convertible to the unit of the requirement target value, and the field reference value can be determined to conform to the requirement judgment rules according to the requirement target value, constraint direction, and tolerance zone, the system determines that the design evaluation information can be used as the basis for judgment of the corresponding requirement judgment rules. For example, the field name can reflect the parameter category pointed to by the customer requirements, the field unit can support the same dimension comparison between the field reference value and the requirement target value, and the field mapping component can indicate that the field belongs to the product component or structural location involved in the customer requirements.

[0027] When design evaluation information can be used as a basis for judgment, the system generates an anchoring relationship between customer requirements and corresponding design evaluation information, and writes this anchoring relationship into the design anchor table after associating it with the anchoring benchmark group. The design anchor table is used to store the correspondence between customer requirements, requirement judgment rules, design evaluation information and anchoring benchmark group, so that subsequent product acceptance verification can call field names, field benchmark values, version information and corresponding requirement judgment rules according to the same anchoring relationship, thereby avoiding the need to re-establish the correspondence between requirements and design fields after the solution changes.

[0028] When design evaluation information cannot be used as a basis for judgment, the system generates an unanchored prompt and transfers the corresponding customer requirement to manual review. The unanchored prompt indicates that no design evaluation information supporting the requirement judgment rules has been found in the current initial solution information. Manual review can confirm whether the customer requirement can establish an anchoring relationship with other design evaluation information based on design documents, product definition documents, or supplementary design specifications. When manual review confirms that it can be anchored, the system generates the corresponding anchoring relationship and associates it with the anchoring benchmark group, writing it into the design anchor point table. When manual review does not confirm that it can be anchored, the corresponding customer requirement can be retained as information to be reviewed to avoid it directly participating in subsequent product acceptance verification without a basis for judgment.

[0029] Example 2: Based on the design anchor point table already formed in Example 1, this example further obtains a scheme change order from the product evaluation module and matches the scheme change order with the initial scheme information to obtain scheme change information. The scheme change information includes the changed design parameters, changed fields, changed components, and version change information. The changed design parameters are used to indicate the parameter values ​​participating in the evaluation after this scheme adjustment. The changed fields are used to identify the field names that have been adjusted relative to the initial scheme. The changed components are used to determine the product component or structural location to which the changed field belongs. The version change information is used to identify the drawing version, BOM version, or process card version corresponding to the changed scheme, so that the system can compare the continuity status between the initial scheme and the changed scheme under the same anchoring relationship.

[0030] When matching the scheme change order with the initial scheme information, the system can perform the matching according to at least one of the following: product model, design scheme number, field name, field mapping component, and version information, in order to determine the design parameters, changed fields, changed components, and version change information that have changed relative to the initial scheme in the scheme change order; when the matching result can point to the anchoring relationship in the design anchor table, the system will use the matching result as the input basis for subsequent product acceptance verification.

[0031] The product evaluation module retrieves solution verification data corresponding to the solution change information from an external big data server through a preset interface. The solution verification data includes parameter verification data, material verification data, process verification data, sample verification data, current cost data, after-sales feedback data, and competitor comparison data. Among them, parameter verification data includes the field names and current values ​​corresponding to the anchoring relationship, used to determine whether the changed design parameters still meet customer requirements. Material verification data is used to determine whether the changed materials support the material performance target values ​​of the field-mapped components. Process verification data is used to determine whether the changed process control range can support the corresponding fields. Sample verification data, current cost data, after-sales feedback data, and competitor comparison data can serve as the data basis for subsequent solution auxiliary verification, so that product acceptance verification and subsequent auxiliary verification can be carried out based on the same solution change information.

[0032] In one optional implementation, the external big data server can be an existing enterprise data storage platform for design data, material data, process data, test data, cost data, after-sales data, or competitor data. The preset interface can connect to a product lifecycle management system, BOM management system, process management system, quality testing system, cost accounting system, after-sales management system, or competitor database. The preset interface can call the corresponding scheme verification data according to product model, design scheme number, change field, change component, version change information, or sales area information. The specific communication method, database type, and data storage method can be implemented using existing data processing technologies.

[0033] During product acceptance verification, the product evaluation module first performs parameter anchoring verification and version maintenance verification. The parameter anchoring verification reads the current value of the corresponding field from the parameter verification data based on the field names recorded in the anchoring relationship in the design anchor table, and calls the requirement judgment rule and the corresponding parameter target value to determine the parameter achievement status. When the constraint direction in the requirement judgment rule is "not less than the target value", the system judges whether the current value of the field has reached the parameter target value. When the constraint direction is "not greater than the target value", the system judges whether the current value of the field has exceeded the parameter target value. When the constraint direction is "within the tolerance zone", the system judges whether the current value of the field is within the corresponding tolerance zone. This forms the parameter achievement status corresponding to the anchoring relationship.

[0034] Version retention verification is used to determine whether customer requirements are still supported by the original anchoring relationship after a solution version change. The system compares the version information in the anchoring benchmark group with the version change information in the solution change information, and determines the field retention status based on the field names in the parameter verification data. Combined with the requirement judgment rules, the version retention verification result is determined. When the version information in the anchoring benchmark group is consistent with the version change information in the solution change information, the version retention verification result can be determined as version consistency. When the version change information changes relative to the version information but the field names corresponding to the anchoring relationship are still retained in the parameter verification data, and the current field values ​​still meet the requirement judgment rules, the version retention verification result can be determined as anchor retention. When the field name is missing, or the current field value does not meet the requirement judgment rules, the version retention verification result can be determined as anchor failure.

[0035] Product acceptance verification also includes material acceptance verification. Material acceptance verification calls upon material data and performance test records from the material verification data. Material data can come from revised BOM data, material management data, or material review records. It can include data characterizing the material state, such as material grade, material specifications, material thickness, supply batch, heat treatment status, or surface treatment status. Performance test records can come from quality testing systems, sample test reports, or material testing records. These records can include sample components, sample materials, test items, test conditions, test dates, test equipment numbers, and test conclusions. Based on the changed components in the scheme change information, the system obtains the material performance target values ​​associated with the anchoring relationship and determines the component performance requirements of the component mapped to that field based on the material performance target values.

[0036] During material acceptance verification, the system matches material data with performance test records to determine whether the performance test records meet the component performance requirements. When the material data and performance test records match, and the performance test records meet the component performance requirements determined by the material performance target value, the material acceptance status is output as "acceptance achieved." When the material data and performance test records do not match, or the performance test records do not meet the component performance requirements, the material acceptance status is output as "acceptance insufficient." When the scheme change information shows that the changed component has a material change, but no performance test record corresponding to the changed material has been obtained, the material acceptance status is output as "acceptance broken," thereby avoiding the direct use of the test conclusions of the materials or other components before the change as the supporting basis for the changed materials.

[0037] In the material acceptance verification, the correspondence between material data and performance test records can be determined based on at least one of the following: changed components, material grade, material specifications, material thickness, heat treatment state, surface treatment state, test items, or test conditions. When the changed components, material state, or test items corresponding to the performance test record cannot correspond to the changed material data, the system will not use the performance test record as the basis for supporting the performance of the changed material.

[0038] Product acceptance verification also includes process support verification. Process support verification calls upon the process execution data range in the process verification data. The process verification data can come from process card version tables, process management systems, inspection work instructions, or processing control records. The process execution data range can include processing location, process number, inspection parameter fields, upper limit of process control, lower limit of process control, assembly clearance control range, or other data that can represent the process control boundary. The system determines whether the process execution data range corresponds to the field name in the anchoring relationship, and whether the process execution data range meets the requirement judgment rules composed of the corresponding process control target value, constraint direction, and tolerance zone.

[0039] When the process execution data range does not correspond to a field name in the anchoring relationship, it indicates that the process verification data does not cover the design field anchored by the customer requirements, and the process support status is insufficient inspection coverage. When the process execution data range corresponds to a field name in the anchoring relationship, but the process execution data range does not meet the requirement judgment rules composed of the corresponding process control target value, constraint direction, and tolerance zone, it indicates that although the corresponding process record exists, its control boundary cannot support the process control range required by the customer requirements, and the process support status is insufficient process boundary. When the process execution data range corresponds to a field name in the anchoring relationship and meets the requirement judgment rules composed of the corresponding process control target value, constraint direction, and tolerance zone, it indicates that the process record can cover and support the corresponding anchoring relationship, and the process support status is process support achieved.

[0040] The product evaluation module aggregates parameter achievement status, version maintenance verification results, material acceptance status, and process support status into acceptance verification results.

[0041] Example 3, see Figure 3 In this embodiment, based on the product acceptance verification completed in embodiment two and the formation of parameter achievement status, version maintenance verification results, material acceptance status, and process support status, the solution rating module further calls the solution verification data to perform solution auxiliary verification. Solution auxiliary verification is used to supplement the judgment on sample verification, cost constraints, after-sales feedback, and competitor comparison status corresponding to the changed solution, in addition to product acceptance verification. Solution auxiliary verification includes sample verification verification, cost constraint verification, after-sales reason verification, and competitor comparison verification. The sample verification results, cost verification results, after-sales reason status, and competitor comparison status are summarized to form the auxiliary verification results.

[0042] In sample verification and validation, the solution rating module reads the sample verification data and verifies whether the sample verification data achieves the sample verification target value based on the requirement judgment rules, outputting the sample verification result as achieved or not achieved. The sample verification data can come from sample test reports, quality testing systems, trial production verification records, or laboratory testing records, and can include sample number, corresponding sample version, verification items, verification parameter fields, verification measured values, and verification conclusions. The system maps the verification parameter fields to the field names in the anchoring relationship and substitutes the verification measured values ​​into the requirement judgment rules to verify the sample verification target value, constraint direction, and tolerance zone. When the verification measured value meets the corresponding requirement judgment rule, the sample verification result is achieved; when the verification measured value does not meet the corresponding requirement judgment rule, the sample verification result is not achieved.

[0043] In cost constraint verification, the solution rating module reads the current cost data and substitutes it into the demand determination rules to determine whether the cost target value has been achieved, outputting the cost verification result of cost compliance or cost exceeding the limit. The current cost data can come from the cost accounting system, purchase price list, process cost list, manufacturing cost accounting table, or project cost control table, and can include changed parts, material unit price, processing hours, process costs, unit target cost, and unit accounting cost, etc. The system determines the cost verification object based on the changed parts in the solution change information, and compares the unit accounting cost or other current cost fields with the cost target value in the demand determination rules. When the current cost data meets the cost target value and its constraint direction, the cost verification result is cost compliance; when the current cost data does not meet the cost target value and its constraint direction, the cost verification result is cost exceeding the limit.

[0044] During after-sales reason verification, the solution rating module reads after-sales feedback data and outputs the hit or miss status of the after-sales reason based on the relationship between the after-sales feedback data and the solution change information. The after-sales feedback data can come from the after-sales management system, return and exchange registration form, repair work order, user feedback record, or regional quality feedback form. It can include sales area, return reason, repair reason, user feedback content, user concern item code, and changed component information. The system matches the return reason, repair reason, or changed component information in the after-sales feedback data with the change fields, changed components, and version change information in the solution change information. When the after-sales feedback data can point to the change fields or changed components involved in the current solution change, the after-sales reason pointing status is hit; when the after-sales feedback data cannot point to the change fields or changed components involved in the current solution change, the after-sales reason pointing status is miss.

[0045] In the competitive product comparison verification, the solution rating module compares and analyzes the changed fields and changed components in the solution change information with the competitive product comparison data, and outputs the competitive product comparison status of parameters, materials, or no competitive disadvantage. The competitive product comparison data can come from competitor specification tables, regional market research data, publicly available product parameter information, or enterprise competitor databases. It can include competitor model, competitor functional configuration parameters, competitor structural dimension parameters, competitor material identification, competitor thickness parameters, competitor durability level fields, and competitor warranty period fields, etc. The system determines the parameter category of the product to be compared based on the changed fields, determines the structure or material object of the product to be compared based on the changed components, and compares the current parameters and material acceptance status of the product with the corresponding parameters or material performance of the competitors.

[0046] When the current parameters of this product do not meet the demand determination rules, but the corresponding parameters in the competitor comparison data meet the same or corresponding demand determination rules, the competitor comparison status is parameter competitive disadvantage; when the current parameters of this product meet the demand determination rules, but the material acceptance status is insufficient acceptance or broken supply chain, and the corresponding material identification, thickness parameters, durability level fields or warranty period fields in the competitor comparison data form a relative advantage, the competitor comparison status is material competitive disadvantage; when the current parameters of this product, material acceptance status and corresponding competitor comparison data do not form the above disadvantage relationship, the competitor comparison status is no competitive disadvantage.

[0047] After the auxiliary verification results are generated, the solution rating module combines the acceptance verification results in Example 2 with the auxiliary verification results in this example to determine the status relationship. The status relationship determination is used to merge the parameter achievement status, version maintenance verification results, material acceptance status, process support status, sample verification results, cost verification results, after-sales reason pointing status and competitor comparison status into the solution evaluation status, so that the intelligent evaluation results of product design can not only reflect the individual verification results, but also indicate the direction of review or correction that the changed solution needs to enter.

[0048] The specific determination of the status relationship is as follows: When the parameter achievement status is not achieved or the version maintenance verification result is anchor failure, output parameter correction status; when the material acceptance status is insufficient acceptance or acceptance chain break, output material correction status; when the process support status is insufficient inspection coverage or insufficient process boundary, output process correction status; when the sample verification result is not achieved, output sample verification correction status; when the cost verification result is cost exceeding the limit, output cost review status; when the after-sales cause pointing status is hit, or the competitor comparison status is parameter competitive disadvantage or material competitive disadvantage, output market adaptation correction status; when none of the above conditions are met, output design evaluation passed status.

[0049] In one optional implementation, when the same scheme change information triggers multiple scheme evaluation states simultaneously, the scheme rating module can determine one state as the primary scheme evaluation state according to a preset judgment order, and the remaining triggered scheme evaluation states as related scheme evaluation states. The preset judgment order can be as follows: parameter correction state, material correction state, process correction state, sample verification correction state, cost review state, market adaptability correction state, and design evaluation passed state. The design evaluation passed state is determined only when none of the aforementioned correction and review states have been triggered. By setting the above preset judgment order, when multiple verification anomalies exist simultaneously, the evaluation states that have a greater impact on the basic compatibility of the design scheme can be output first, while other anomaly states are retained as part of the evaluation trigger information.

[0050] Through the above-mentioned state relationship determination, the solution rating module can convert the parameters, versions, materials, processes, samples, costs, after-sales and competitor-related verification results generated after the solution change into the corresponding solution evaluation status. The solution evaluation status can serve as the basis for the result output module to generate intelligent product design evaluation results, and can enable the subsequent output evaluation trigger information to be located to specific changed fields, changed components, corresponding anchoring relationships and corresponding verification conclusions.

[0051] After the scheme rating module outputs the scheme evaluation status, the result output module calls the scheme change information and corresponding anchoring relationship involved in the status relationship determination, and collects them into evaluation trigger information. The evaluation trigger information may include the change fields, changed components, version change information, corresponding anchoring relationship, corresponding verification conclusion and data source that trigger the corresponding scheme evaluation status. Among them, the change fields, changed components and version change information are obtained from the scheme change information, the corresponding anchoring relationship is obtained from the design anchor point table, the corresponding verification conclusion is obtained from the receiving verification result or auxiliary verification result, and the data source is obtained from the scheme verification data or the call record of the preset interface.

[0052] The results output module summarizes the evaluation trigger information, scheme evaluation status, acceptance verification results, and auxiliary verification results to generate intelligent product design evaluation results. The intelligent product design evaluation results are used to represent the evaluation conclusions of the modified scheme and the basis for their formation, enabling reviewers to locate specific changed fields, changed components, version change information, and anchoring relationships based on the output content, and to determine whether the scheme needs parameter correction, material correction, process correction, sample verification correction, cost review, market adaptation correction, or can pass the design evaluation.

[0053] Example 4 illustrates the processing procedure of the present invention in the context of a product design change scenario for a portable cleaning equipment housing bracket. In this scenario, the initial requirement assessment form records that the customer requirement is that the housing bracket should meet drop durability requirements, and the bracket wall thickness should not be less than 2.5mm, with a target cost per unit not exceeding 18 yuan. The design evaluation information recorded in the initial scheme information includes the bracket wall thickness field, the field baseline value of 2.8mm, the field unit of mm, the field mapped component as the housing bracket, and the version information including drawing version A1, BOM version B1, and process card version C1. After reading the above customer requirements and requirement judgment rules, the system establishes an anchoring relationship between the bracket wall thickness field and the customer requirements, and writes the field name, field baseline value, and version information as the anchoring baseline group into the design anchor point table.

[0054] During subsequent design changes, the company submitted a design change order to reduce costs, replacing the outer casing support material from raw material P1 to material P2 and adjusting the support wall thickness to 2.3mm. Simultaneously, drawing version A2, BOM version B2, and process card version C2 were generated. After obtaining the design change information, the product evaluation module retrieved parameter verification data, material verification data, process verification data, sample verification data, current cost data, after-sales feedback data, and competitor comparison data through a preset interface. The parameter verification data recorded the current value of the support wall thickness field as 2.3mm; the material verification data recorded the replaced material P2 and the retrieved candidate performance test records; the process verification data recorded the control range of the support molding process; and the current cost data recorded a unit cost of 16.8 yuan.

[0055] During product acceptance verification, the system reads the current value of the bracket wall thickness field in the anchoring relationship as 2.3mm, and judges it according to the parameter target value of not less than 2.5mm in the requirement judgment rule. Since the current value of the field does not reach the parameter target value, the parameter achievement status is judged as not achieved. At the same time, the system compares the drawing version A1, BOM version B1, and process card version C1 in the anchoring benchmark group with the drawing version A2, BOM version B2, and process card version C2 in the scheme change information, confirming that the version change information has changed relative to the version information, and further judges that the current value of the changed field does not meet the requirement judgment rule. Therefore, the version maintenance verification result is judged as anchoring failure.

[0056] In material acceptance verification, the system obtains the target material performance value associated with the anchoring relationship based on the shell support component in the scheme change information, and makes a corresponding judgment on the material data of material P2 with the performance test record; when the performance test record still points to raw material P1, or no drop durability performance test record corresponding to material P2 is obtained, the system outputs the material acceptance status as acceptance chain breakage; in process support verification, the system reads the process execution data range. If the process execution data range corresponds to the support wall thickness field, but its control range cannot meet the 2.5mm and corresponding tolerance zone requirements, the process support status is output as insufficient process boundary.

[0057] In the solution-assisted verification, the system reads the sample verification data and compares the sample drop verification results with the sample verification target value. If the sample test results do not meet the drop durability requirements, the sample verification result is "not met". The system reads the current cost data and compares it with the cost target value. Since the unit cost of 16.8 yuan does not exceed 18 yuan, the cost verification result is "cost compliant". The system further reads after-sales feedback data and competitor comparison data. If there is a return reason of cracked shell bracket in the after-sales feedback, and the corresponding bracket wall thickness or material durability performance of the competitor is better than this product, the after-sales reason pointing status is "hit", and the competitor comparison status is "parameter competitive disadvantage" or "material competitive disadvantage".

[0058] In the status relationship determination, the scheme rating module determines that the changed scheme does not meet the design evaluation pass conditions based on the parameter achievement status being "not achieved," the version maintenance verification result being "anchoring failure," the material acceptance status being "acceptance chain broken," the process support status being "insufficient process boundary," and the sample verification result being "not achieved." When multiple scheme evaluation statuses are triggered simultaneously, the scheme rating module outputs the parameter correction status as the main scheme evaluation status according to the preset judgment order, and uses the material correction status, process correction status, and sample verification correction status as the associated scheme evaluation status. The result output module collects the bracket wall thickness field, shell bracket component, drawing version A2, BOM version B2, corresponding anchoring relationship, parameter achievement status, version maintenance verification result, material acceptance status, and process support status into evaluation trigger information, and outputs the product design intelligent evaluation result to prompt the reviewers to review the bracket wall thickness, material replacement, and process control schemes.

[0059] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A product design intelligent evaluation system based on big data, characterized in that, The system includes: The anchor point creation module obtains the initial requirement assessment form and initial plan information, extracts the anchoring benchmark group based on the initial plan information, reads the customer requirements in the initial requirement assessment form and matches them with the initial plan information to form the anchoring relationship, and associates the anchoring relationship with the anchoring benchmark group to form the design anchor point table. The product evaluation module obtains the scheme change order and matches it with the initial scheme information to obtain the scheme change information. It obtains the scheme verification data corresponding to the scheme change information from an external big data server through a preset interface. Based on the scheme change information, the scheme verification data, and the design anchor table, it performs product acceptance verification and summarizes the conclusions of the product acceptance verification into acceptance verification results. The scheme rating module calls the scheme verification data to perform scheme auxiliary verification to form auxiliary verification results, combines the acceptance verification results and auxiliary verification results to determine the status relationship, and outputs the scheme evaluation status. The results output module extracts the scheme change information and corresponding anchoring relationships involved in the state relationship determination and collects them into evaluation trigger information. The evaluation trigger information is combined with the scheme evaluation status, acceptance verification results and auxiliary verification results and output as the product design intelligent evaluation results.

2. The intelligent evaluation system for product design based on big data according to claim 1, characterized in that, The initial requirement assessment form records customer requirements and their corresponding requirement judgment rules. The requirement judgment rules include requirement target values, constraint directions, and tolerance zones. The requirement target values ​​include one or more of the following: parameter target values, material performance target values, process control target values, sample verification target values, and cost target values. The initial scheme information includes design evaluation information and version information. The design evaluation information includes field name, field baseline value, field unit, and field mapping component. The anchoring baseline group includes field name, field baseline value, and version information.

3. The intelligent evaluation system for product design based on big data according to claim 2, characterized in that, The specific matching process for the anchoring relationship is as follows: read customer requirements and requirement determination rules, obtain design evaluation information corresponding to customer requirements from initial solution information, and determine that the design evaluation information can be used as the basis for the requirement determination rules when at least one of the field names and field mapping components in the design evaluation information matches the customer requirements, the unit of the field is consistent with or convertible to the unit of the requirement target value, and the base value of the field conforms to the requirement determination rules; when the design evaluation information can be used as the basis for determination, generate the anchoring relationship between customer requirements and corresponding design evaluation information. Otherwise, an unanchored prompt message will be generated and the corresponding customer requirement will be transferred to manual review. When manual review confirms that anchoring is possible, the corresponding anchoring relationship will be generated and associated with the anchoring benchmark group and written into the design anchor point table.

4. The intelligent evaluation system for product design based on big data according to claim 2, characterized in that, The scheme change information includes the changed design parameters, changed fields, changed components, and version change information; The verification data for the scheme includes parameter verification data, material verification data, process verification data, sample verification data, current cost data, after-sales feedback data, and competitor comparison data. The parameter verification data includes the field name and current value of the field corresponding to the anchoring relationship.

5. The intelligent evaluation system for product design based on big data according to claim 4, characterized in that, The product acceptance verification includes parameter anchoring verification and version retention verification. The parameter anchoring verification reads the current value of the field from the parameter verification data based on the field name in the anchoring relationship, and calls the requirement judgment rules and the corresponding parameter target value to determine the parameter achievement status. The version retention verification compares the version change information in the anchoring benchmark group and the solution change information, and determines the field retention status based on the field name in the parameter verification data. Combined with the requirement judgment rules, the version retention verification result is determined. The version retention verification result includes version consistency, anchoring retention, or anchoring failure.

6. The intelligent evaluation system for product design based on big data according to claim 5, characterized in that, The product acceptance verification also includes material acceptance verification. The material acceptance verification calls up the material data and performance test records in the material verification data, obtains the material performance target value associated with the anchoring relationship based on the changed components in the scheme change information, determines the component performance requirements based on the material performance target value, judges the correspondence between the material data and the performance test records and the achievement of the component performance requirements, and forms the material acceptance status of acceptance achievement, insufficient acceptance or acceptance chain break.

7. The intelligent evaluation system for product design based on big data according to claim 6, characterized in that, The product acceptance verification also includes process support verification. The process support verification calls the process execution data range in the process verification data, determines whether the process execution data range corresponds to the field name in the anchoring relationship, and determines whether the process execution data range meets the requirement judgment rule of the corresponding process control target value, and outputs the process support status.

8. The intelligent evaluation system for product design based on big data according to claim 7, characterized in that, When the process execution data range does not correspond to the field name in the anchoring relationship, the process support status is insufficient inspection coverage; When the field name in the anchoring relationship corresponding to the process execution data range does not meet the requirement judgment rule of the corresponding process control target value, the process support status is insufficient process boundary; When the field name in the anchoring relationship corresponding to the process execution data range meets the requirement judgment rule of the corresponding process control target value, the process support status is that the process support has been achieved. The acceptance verification results include parameter achievement status, version maintenance verification results, material acceptance status, and process support status.

9. The intelligent evaluation system for product design based on big data according to claim 8, characterized in that, The solution auxiliary verification includes: verifying whether the sample verification data achieves the sample verification target value based on the demand determination rules, and outputting the sample verification result of achieving or not achieving the target value; reading the current cost data and substituting it into the demand determination rules to determine whether the cost target value is achieved, and outputting the cost verification result of cost compliance or cost exceeding the limit; outputting the after-sales reason pointing status of hit or miss based on the pointing relationship between after-sales feedback data and solution change information; comparing and analyzing the solution change information with competitor comparison data, and outputting the competitor comparison status of parameter competitive disadvantage, material competitive disadvantage, or no competitive disadvantage; the sample verification result, cost verification result, after-sales reason pointing status, and competitor comparison status are summarized to form the auxiliary verification result.

10. The intelligent evaluation system for product design based on big data according to claim 9, characterized in that, The state relationship determination is as follows: when the parameter achievement state is not achieved or the version maintenance verification result is anchor failure, the parameter correction state is output; when the material acceptance state is insufficient acceptance or acceptance chain break, the material correction state is output. When the process support status is insufficient inspection coverage or insufficient process boundary, output the process correction status. When the sample verification result is not met, the sample verification correction status will be output. When the cost verification result is that the cost exceeds the limit, output the cost review status; when the after-sales reason points to the hit status, or the competitor comparison status is parameter competitive disadvantage or material competitive disadvantage, output the market adaptation correction status; when none of the above conditions are met, output the design evaluation passed status; when the same scheme change information meets multiple status relationship judgment conditions at the same time, output the scheme evaluation status of the first position according to the preset judgment order, and the remaining triggered scheme evaluation statuses are used as related scheme evaluation statuses.

Images