Product research and development intelligent auxiliary system and method based on historical prototype data and medium

Abstract

The invention relates to the field of product research and development management, and discloses a product research and development intelligent auxiliary system and method based on historical prototype data and a medium, and the system comprises a project collaborative management system, a project data center, a historical project database and an intelligent push module. Generating a structured research and development task chain bound with the demand point; realizing automatic transmission and version synchronization of cross-task data based on a standardized data template; after the project is settled, the research and development data are archived to a historical database according to predefined fields to form a searchable knowledge base; and the intelligent pushing module extracts new project demand features, matches similar prototypes from historical data and pushes the similar prototypes to a current task interface. According to the method, the problems of data dispersion, disordered format and low experience reuse efficiency in traditional research and development are solved, and full-process closed-loop management of demand-task-data-history reuse is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of product R & D management, and specifically to an intelligent auxiliary system, method and medium for product R & D based on historical prototype data. Background Art

[0002] With the expansion of the enterprise R & D scale and the intensification of market competition, the quantity and complexity of product R & D projects have increased significantly, and the amount of data generated during the R & D process has grown exponentially. Although enterprises have gradually established product R & D management systems and archived some key data, a large amount of R & D process data is still scattered in the local terminals of engineers, facing the risk of loss due to equipment failures, personnel changes or outdated formats. In addition, the reuse rate of existing archived data in new project R & D is low, and its potential value has not been fully explored, resulting in frequent problems such as repeated design and experience gaps.

[0003] Although the current Product Data Management (PDM) system can perform version control and baseline management on design drawings and documents, its functions focus on the static storage and approval process of design files, lacking the ability to dynamically track the entire R & D process. There are significant shortcomings especially in aspects such as cross-task data transfer, requirement-task association traceability, and intelligent reuse of historical data. For example, the PDM system cannot automatically generate a task chain based on requirement indicators, nor can it achieve automated synchronization and version compatibility verification of upstream and downstream data. At the same time, its retrieval and push functions for historical data rely on manual experience and it is difficult to achieve accurate recommendations through feature matching. These problems have led to bottlenecks in the enterprise's demand response speed, R & D resource utilization rate, and cross-departmental collaboration efficiency, and there is an urgent need for a systematic solution covering the entire life cycle of "requirement definition - task execution - data precipitation - intelligent reuse". Summary of the Invention

[0004] Aiming at the deficiencies of the prior art, the present invention provides an intelligent auxiliary system, method and medium for product R & D based on historical prototype data, which overcomes the defects of decentralized data management, low cross-task transfer efficiency, difficult reuse of historical data and lack of full-process closed-loop management in traditional R & D through standardized data templates, automated transfer mechanisms and intelligent matching and pushing.

[0005] To achieve the above objectives, the present invention is realized through the following technical solutions: An intelligent auxiliary system for product R & D based on historical prototype data, including: A project collaboration management system, used to define product R & D projects, decompose R & D tasks, associate business opportunity information in the marketing module, analyze the marketing plan requirement indicators corresponding to business opportunities, and generate R & D tasks and standardized data templates associated with the requirement indicators; The project data center receives the data generated by the R & D tasks, classifies and stores the data according to the standardized data template, and automatically transfers the upstream task output data to the downstream task input data based on the template matching rules; The historical project database receives the R & D data from the project data center after the project is completed and archives the data according to the predefined field structure; The intelligent push module matches the similar historical prototype data from the historical project database according to the requirement indicators entered for the new project, and pushes the matching results to the input / output data interface of the current R & D task.

[0006] Preferably, the project collaborative management system includes: The business opportunity management unit is used to bind the business opportunity information with the basic project information and generate project requirements; The requirement decomposition unit decomposes the requirement indicators in the marketing plan into executable product design requirement points and associates them with the R & D tasks.

[0007] Preferably, the requirement decomposition unit generates R & D tasks including input / output data templates by calling the predefined plan template, assigns the tasks to the responsible persons, and records the requirement tracking results at the same time.

[0008] Preferably, the project data center includes: The data template definition unit defines the standardized templates for the input / output data for each R & D task. The template fields include data type, version number, and source task; The data transfer unit matches the data with the same template from the output data of the upstream task according to the input template of the downstream task and automatically fills it into the downstream task input interface.

[0009] Preferably, when the data transfer unit detects the update of the upstream task data, it triggers the data version synchronization of the downstream task, updates the downstream input data and marks the change status, and pushes a reminder to the responsible person at the same time.

[0010] Preferably, the archiving process of the historical project database includes: The project completion verification unit verifies the project task completion rate, risk closure status, and data approval status; The data mapping unit maps the data in the project data center to the historical project database according to the predefined fields.

[0011] Preferably, the intelligent push module includes: The similarity calculation unit calculates the matching score between the new project requirement indicators and the historical project requirement indicators based on the cosine similarity algorithm; The push decision-making unit screens the Top-N historical projects according to the matching degree scores and pushes the associated prototype data to the current R & D task interface.

[0012] Preferably, the calculation formula of the matching degree score is: Among them, S A is the name similarity, S B is the specification similarity, S AB is the comprehensive similarity.

[0013] The present invention also provides an intelligent auxiliary method for product R & D based on historical prototype data, including the following steps: Define the R & D project and associate business opportunity information, analyze the demand indicators of the marketing plan, and generate R & D tasks and standardized data templates associated with the demand points; Based on the standardized data template, automatically transfer the output data of the upstream task to the input interface of the downstream task; After the project is completed, file the R & D data into the historical project database according to the predefined field structure; According to the demand indicators of the new project, match similar prototype data from the historical project database and push it to the current task interface.

[0014] The present invention also provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the method as described above is implemented.

[0015] The present invention also provides a storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method as described above is implemented.

[0016] The present invention provides an intelligent auxiliary system, method and medium for product R & D based on historical prototype data. It has the following Beneficial effects: 1. By predefined input / output data templates and mandatory verification rules, the present invention ensures the format unity and content compatibility of cross-task data, avoids format errors or data loss caused by manual intervention, and improves the cooperation efficiency between upstream and downstream tasks.

[0017] 2. From business opportunity demand analysis, task decomposition, data transfer to historical archiving and intelligent push, the present invention forms an end-to-end closed-loop management link, solves the problems of disconnection between demand and tasks and isolation of historical data in traditional R & D, and ensures the traceability of the whole process of data flow.

[0018] 3. Based on the characteristic matching and similarity ranking of demand indicators, the present invention accurately pushes the associated historical prototype data to the current task interface, reduces the workload of repeated design, and shortens the product R & D cycle.

[0019] 4. The present invention dynamically associates requirement indicators with R & D tasks through a requirement tracking matrix. When requirements change, the system automatically analyzes the impact scope and prompts the adjustment of associated tasks, reducing the risk of rework.

[0020] 5. The historical project database of the present invention archives data according to standardized fields. Combining index optimization and permission control, it forms a retrievable and reusable enterprise knowledge asset library, enhancing the reuse of team experience and the cross - departmental collaboration ability. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic diagram of the system architecture of the present invention; Figure 2 It is a schematic diagram of the association relationship between projects and business opportunity data of the present invention; Figure 3 It is a schematic diagram of the functional logic of the association relationship of task data of the present invention; Figure 4 It is a schematic diagram of the push logic of historical project materials of the present invention; Figure 5 It is a schematic diagram of the method flow of the present invention; Figure 6 It is a schematic diagram of the structure of a computer device of the present invention.

[0022] Among them, 40, computer device; 41, processor; 42, memory; 43, storage medium. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0024] Please refer to the attached Figure 1 - attached Figure 4 , the present invention provides an intelligent auxiliary system for product R & D based on historical prototype data, which realizes the full - process automatic collection, transmission and intelligent reuse of R & D data by constructing a closed - loop data management link.

[0025] This system includes the following core modules: A project collaboration management system, which is responsible for project definition, task decomposition and requirement management; A project data center, which realizes the automatic transmission and storage of data between tasks; A historical project database, which completes the standardized archiving of project - closing data; The intelligent push module matches and pushes historical prototype data based on a similarity algorithm.

[0026] Each module is connected in series through a data interface and logical rules to form a closed-loop link of "project definition → data flow → historical archiving → intelligent push".

[0027] The following is a detailed description of each module in the system of the present invention, comprehensively elaborating on the specific implementation principles, technical details, and processes of each module.

[0028] In this embodiment, the project collaborative management system realizes the technical functions of business opportunity information binding, requirement decomposition, and task management through predefined database table structures.

[0029] Business Opportunity Table (Business_Opportunity) Used to store the basic business opportunity information transmitted by the marketing module. The key fields include: Busi_ID: Uniquely identifies the business opportunity number and is used to associate with the R & D project (Pro_ID); Busi_name: The name of the business opportunity, describing the business scenario of the business opportunity; Busi_type: Business opportunity classification (such as new product development, customized improvement); Customer_name: The name of the customer, identifying the source of the requirement; Busi_author: The person in charge of the business opportunity, associated with the responsible department (Busi_Department) in the organizational structure.

[0030] The Business Opportunity Table is associated with the Project Information Table (Project_Info) through the Pro_Busi_ID field to ensure that the business opportunity context is automatically inherited when the project is created.

[0031] Project Information Table (Project_Info) Used to define the basic attributes of the R & D project. The key fields include: Pro_ID: Uniquely identifies the project number; Pro_Num: The name of the project, logically corresponding to the business opportunity name (Busi_name); Pro_mana: The project manager ID, associated with the task assignment and approval process; Pro_Plan: The project plan, storing the called plan template (such as the mechanical design template ID); Pro_cost: The project budget, used for cost control and resource allocation.

[0032] The project information form is associated with the Requirement_Decompose table through the Pro_Req_ID field to form a complete link of "business opportunity → project → requirement".

[0033] Requirement_Decompose table Used to record the process of requirement index decomposition and the task association relationship. The key fields include: Req_ID: Uniquely identifies the requirement number; Req_name: Requirement name (such as "lightweight design"); Req_type: Requirement classification (such as performance requirement, cost requirement); Req_data: Requirement detailed information, storing structured parameters (such as "weight ≤ 2kg"); Req_path: Requirement point path, recording the requirement decomposition level (such as "Req1.1.2"); Req_status: Requirement status (such as not started, in progress, closed); Req_resList: Requirement tracking result, storing the associated task ID (Task_ID) and the output data index.

[0034] The Requirement_Decompose table records the requirement change history through Req_Ctime (requirement creation time) and Req_Etime (requirement modification time), and drives the task scheduling order through the Req_level (requirement priority) field.

[0035] Task_Assignment table Used to manage the R & D task execution process. The key fields include: Task_ID: Uniquely identifies the task number; Input_Template: Input data template, defining the data format (such as STEP file), version number and source task; Output_Template: Output data template, defining the deliverable specification and the downstream task association rule; Req_path: Associated requirement point path, supporting two-way traceability between requirements and tasks.

[0036] The data association relationship is as follows: The business opportunity is bound to the project: A foreign key association is established through Busi_ID (business opportunity table) and Pro_Busi_ID (project table) to ensure that the project inherits the business opportunity requirement context.

[0037] Project and Requirement Decomposition: Establish a one-to-many association through Pro_Req_ID (Project Table) and Req_ID (Requirement Table) to support the decomposition of multi-level requirements for a single project.

[0038] Requirement and Task Mapping: Establish an index association through Req_resList (Requirement Table) and Task_ID (Task Table) to achieve dynamic statistics of requirement coverage.

[0039] Through the above database table structure design, this embodiment solves problems such as business opportunity information silos and difficult requirement traceability in traditional R & D management. The logical associations between fields (such as Pro_Busi_ID, Req_resList) provide a structured data basis for the system to realize automated task generation, data transfer, and status tracking.

[0040] For the project collaborative management system: In this embodiment, the project collaborative management system is used to realize the full-process definition and task decomposition of product R & D projects. By deeply integrating with the business opportunity information of the marketing module, it transforms market requirements into executable R & D tasks and provides structured input for subsequent data transfer and intelligent push.

[0041] In this embodiment, the project collaborative management system docks with the enterprise marketing module through the business opportunity management unit to obtain business opportunity information (such as Busi_ID, Busi_name, Customer_name, etc.).

[0042] Specifically, when a user creates a new R & D project in the system, it is necessary to associate the business opportunity number (Busi_ID) registered in the marketing module. The system automatically parses the marketing plan document corresponding to the business opportunity and extracts the defined requirement indicators (Req_data), including customer technical requirements, market positioning parameters, performance targets, etc.

[0043] Preferably, the business opportunity information table (Business_Opportunity) records the business opportunity type (Busi_type) and the responsible department (Busi_Department) for matching the department to which the responsible person belongs during subsequent task assignment.

[0044] Preferably, the requirement indicators are converted into structured data through predefined semantic parsing rules. For example, the text description "The product weight needs to be less than 2 kg" is parsed into a field combination {Req_name: "Lightweight design", Req_data: "Weight ≤ 2 kg"} and bound to the project basic information (Pro_ID, Pro_Num) and stored in the project requirement table (Project_Req).

[0045] Further, the Project_Req is associated with the Pro_cost field in the project requirements form, which is used for cost constraint verification during the task decomposition phase.

[0046] In this embodiment, the requirement decomposition unit decomposes the high-level requirement indicators in the marketing plan into executable product design requirement points (Req_path) and generates corresponding R & D tasks.

[0047] Specifically, the system calls different decomposition strategies according to the requirement type (Req_type). For example, for performance requirements (such as "impact resistance level ≥ 5 levels"), they are decomposed into subtasks such as material selection, structural simulation, and prototype testing; for cost requirements (such as "BOM cost ≤ 500 yuan"), they are decomposed into subtasks such as supplier price comparison and alternative solution design.

[0048] Preferably, the system dynamically adjusts the task scheduling order according to the requirement priority (Req_level), and the tasks associated with high-priority requirements (Req_level = 1) are automatically assigned to the front of the queue.

[0049] Preferably, a predefined requirement-task mapping rule library is referenced during the decomposition process to ensure that the logical association between requirement indicators and R & D tasks is traceable. Each requirement point (Req_path) records its source requirement (Req_ID), responsible person (Req_author), and tracking status (Req_status) to form a requirement tracking matrix (Req_resList).

[0050] Further, the requirement creation time (Req_Ctime) and modification time (Req_Etime) are recorded during the requirement decomposition process for tracing the requirement change history.

[0051] In this embodiment, the system automatically generates an R & D task chain including input / output data templates (Input_Template, Output_Template) by calling a predefined plan template (Pro_Plan).

[0052] Specifically, when the user completes the requirement decomposition, the system selects a matching plan template according to the project type (such as mechanical design, electronic development). The template pre-sets the task order, deliverable format, and upstream and downstream data dependencies. For example, in the mechanical design template, the output template (Output_Template) of the "3D modeling" task will specify the file format (such as STEP format), version number (Data_Version), and reference standard (such as GB / T 1182).

[0053] Preferably, the data template enforces unified data definition through field combination. The input template (Input_Template) includes fields such as data source task (Data_Source) and data type (Data_type); the output template (Output_Template) extends fields such as target task (Target_Task) and version change record (Version_Log). This design ensures strict compatibility of format and content during data transfer between tasks.

[0054] Furthermore, the dependency relationship between tasks is defined in the project plan template (Pro_Plan). For example, the "structural simulation" task can only be started after the data output by the "3D modeling" task passes the verification.

[0055] In this embodiment, the system assigns the generated R & D tasks to the designated responsible person (Pro_mana) and monitors the task execution status in real time.

[0056] Specifically, after the task is assigned, the responsible person can view the data format required by the input template, associated requirement points (Req_path), and the completion status of the pre-task in the task interface. When the upstream task data is updated, the system automatically triggers the version synchronization of the input data of the downstream task according to the target task (Target_Task) field in the template and marks the change prompt in the interface (such as "the data has been updated to V2.0").

[0057] Preferably, the process data generated during the task execution (such as design sketches and simulation intermediate results) will be temporarily stored in the project data center according to the template rules and bound to the task ID (Task_ID). After the task is completed, the responsible person needs to submit the final output data, and the system automatically verifies its compliance with the output template, such as checking the integrity of required fields and the compliance of file formats.

[0058] Furthermore, when the verification fails, the system generates an error code (such as E1001: missing required field) and associates it with the specific template field to guide the responsible person to correct the data.

[0059] In this embodiment, the system realizes the two-way traceability between requirement indicators and R & D tasks through the requirement traceability matrix (Req_resList).

[0060] Specifically, each requirement point (Req_path) can be associated with multiple R & D tasks. Conversely, the output data of each task will be linked back to the corresponding requirement indicators. For example, the requirement indicator "waterproof level IP68" may be associated with tasks such as "sealing structure design" and "environmental test verification", and the output data of these tasks (such as the sealing ring selection report and test passing certificate) will be used as evidence for the achievement of this requirement.

[0061] Preferably, the system provides a visual dashboard to display the requirement coverage rate (Req_Coverage) and the task completion progress (Task_completion). When the requirement status changes (such as new customer metrics), the system automatically analyzes the impact scope and prompts the associated tasks and data templates that need to be adjusted.

[0062] Furthermore, the requirement coverage rate (Req_Coverage) is calculated by statistically analyzing the proportion of the number of Req_path of the associated tasks to the total number of requirements, and is dynamically displayed in the form of a progress bar on the dashboard.

[0063] In this embodiment, the structured task chain and the standardized data template generated by the project collaboration management system lay the foundation for downstream data transfer and intelligent push.

[0064] Specifically, the predefined rules for the input / output templates between tasks enable the project data center to automatically pull data based on template matching; while the structured storage of requirement metrics (such as performance parameters in Req_data) provides comparable feature vectors for the similarity calculation of the intelligent push module.

[0065] Preferably, when the project enters the closing stage, the system packages and transfers the requirement tracking results (Req_resList) and task deliverables to the historical project database to ensure the integrity and retrievability of the archived data.

[0066] Furthermore, at the time of project closure, the system verifies the task completion rate (Task_completion = 100%) and the risk closure status (Risk_status = Resolved), and maps the project data to the historical database according to predefined fields (Hist_Req_ID, Hist_Spec).

[0067] For the project data center: In this embodiment, the project data center is used to achieve the structured storage, versioned transfer, and automated synchronization of R & D task data. By defining standardized data templates and template matching rules, it ensures the compatibility and consistency of cross-task data, providing a standardized data source for subsequent historical data archiving and intelligent push.

[0068] In this embodiment, the project data center creates standardized templates (Input_Template, Output_Template) for the input / output data of each R & D task through the data template definition unit, specifying the data format, source, and version rules.

[0069] Specifically, when a R & D task is issued from the project collaboration management system, the system calls a predefined template library according to the task type (such as design, simulation, testing) to generate a data template bound to the task. For example, in the input template of a simulation task, the data source (Data_Source = upstream task ID), data type (Data_type = simulation parameter file), and version number (Data_Version = V1.0) are defined, and reference standards (such as ISO 10303) are associated and referenced.

[0070] Preferably, the template fields constrain the data format through mandatory verification rules. For example, in the output template (Output_Template), it is required that data of the "test report" type must include fields such as the test case number (TestCase_ID) and pass rate (Pass_Rate), otherwise the system refuses to accept data submission.

[0071] In this embodiment, the data transfer unit realizes the automatic transfer of upstream and downstream task data based on template matching rules.

[0072] Specifically, when a downstream task is started, the system retrieves matching items from the output data pool of the upstream task according to the Data_type and Data_Source fields defined in its input template (Input_Template). For example, if the downstream task input template requires a "3D model file (STEP format)", the system automatically pulls the latest version of the model file output by the upstream task (Data_Version = latest value).

[0073] Preferably, version consistency verification is performed during the data transfer process. If the upstream data version is updated (such as from V1.0 to V2.0), the system automatically updates the version number of the downstream task input data, marks the change status (Req_status = Updated), and simultaneously pushes a notification to the person in charge of the downstream task.

[0074] In this embodiment, the data transfer unit supports the coexistence of multiple versions of data and conflict detection.

[0075] Specifically, when there are multiple versions of the same data template (such as design drawing V1.0 and V2.0), the system displays the version history in the task interface and allows the person in charge to select to roll back to a specified version. If there is a conflict in the versions of the same data template between the upstream and downstream tasks (such as the upstream has been upgraded to V3.0 and the downstream still depends on V2.0), the system generates a conflict report (Conflict_Report) to prompt the person in charge to coordinate the version dependency relationship.

[0076] Preferably, the version change record (Version_Log) stores the version number, modification time, modifier, and change summary, supporting version traceability and auditing.

[0077] In this embodiment, the intermediate data generated during the task execution (such as design sketches, intermediate simulation results) are temporarily stored in the project data center according to the template rules and are bound to the task ID (Task_ID) and the version number (Data_Version).

[0078] Specifically, the responsible person can submit multiple intermediate version data in the task interface, and the system automatically generates a version sequence according to the timestamp (such as Draft_V1, Draft_V2). When the task is completed, the responsible person needs to submit the final output data, and the system performs the following validations: Integrity validation: Check whether the required fields (such as Data_Source, Data_Version) are complete; Format compliance validation: Verify whether the file format (such as STEP, PDF) conforms to the template definition; Dependency validation: Confirm whether the input template of the downstream task has synchronized the latest version data.

[0079] Preferably, when the validation fails, the system generates an error code (such as E2001: Data_Source field missing) and a correction guide to assist the responsible person in quickly locating the problem.

[0080] In this embodiment, after the project is completed, the project data center transfers the R & D data to the historical project database according to the predefined field mapping rules.

[0081] Specifically, the system converts the project data center fields (such as Req_data, Output_Template) into the standardized fields of the historical database (such as Hist_Spec, Hist_Data) through the data mapping unit, and associates the dependencies of the original task chain (such as the upstream task ID, version sequence). For example, the output data (Output_Template) of the simulation task will be mapped to the historical prototype data (Hist_Data), and the associated requirement indicators will be recorded (Hist_Spec = Req_data).

[0082] Preferably, before data archiving, it is necessary to verify the task completion rate (Task_completion = 100%) and the risk closure status (Risk_status = Resolved) through the project completion verification unit to ensure the integrity and reusability of the archived data.

[0083] In this embodiment, the operation of the project data center depends on the predefined database table structure and interface protocol.

[0084] Specifically, the data template definition information is stored in the Data_Template table, and the key fields include Template_ID (template ID), Task_Type (task type), Data_Format (data format), Mandatory_Fields (list of mandatory fields), etc.

[0085] Preferably, the data transfer log is recorded in the Data_Flow_Log table, and the fields include Source_Task (source task ID), Target_Task (target task ID), Data_Version (version number), Transfer_Time (transfer time), which are used to trace the data flow path.

[0086] In this embodiment, the project data center receives a structured task chain from the project collaborative management system and provides feature vectors (such as requirement indicators, version numbers) to the intelligent push module through a standardized data interface.

[0087] Specifically, when the intelligent push module initiates a historical data matching request, the project data center extracts the parametric features of the current task (such as weight, size, performance level) according to the requirement indicators (Req_data) and encapsulates them in a vector format for the similarity calculation unit to call.

[0088] This embodiment solves the problems of chaotic data formats, version conflicts, and difficult traceability in traditional R & D through a standardized data template, an automated transfer rule, and a version control mechanism.

[0089] For the historical project database: In this embodiment, the historical project database is used to achieve the standardized archiving, structured storage, and efficient retrieval of the completed R & D data. Through predefined field mapping rules and data verification mechanisms, it ensures the integrity and reusability of the historical prototype data and provides a standardized data source for the similarity matching of the intelligent push module.

[0090] In this embodiment, the historical project database performs admission verification on the project to be archived through the completion verification unit to ensure that the data quality meets the archiving standards.

[0091] Specifically, when the project collaborative management system triggers the completion process, the system automatically verifies the following conditions: Task completion rate (Task_completion): The status of all R & D tasks is marked as "completed" (Status = Closed), and the task chain is not interrupted; Risk closure status (Risk_status): All items in the project risk list are marked as "resolved" (Risk_status = Resolved); Data Approval Status (Data_Approval): The final output data passes the quality review (Approval_Result = Passed), and the signatures of the responsible persons are complete.

[0092] Preferably, when the verification fails, the system generates an exception report (Exception_Report), lists the non-compliant items and the associated task IDs, and blocks the data archiving process until the problem is fixed.

[0093] In this embodiment, the data mapping unit converts and stores the R & D data in the project data center into the historical project database according to the predefined field structure.

[0094] Specifically, the data mapping process includes the following steps: 1. Data extraction: Extract requirement indicators (Req_data), task output data (Output_Template), and associated metadata (such as task dependencies, version sequences) from the project data center; 2. Field conversion: Map the source fields to the target fields according to the preset rules. For example: Project requirement indicators (Req_data) → Historical requirement specifications (Hist_Spec); Task output data (Output_Template) → Historical prototype data (Hist_Data); Task ID (Task_ID) → Historical task index (Hist_Task_ID); 3. Relationship binding: Record the association relationship between Hist_Spec and Hist_Data, and retain the upstream and downstream dependency information of the original task chain.

[0095] Preferably, the mapping rules are stored in an independent configuration table (Mapping_Rules), which supports dynamically loading different mapping schemes according to the project type (such as mechanical, electronic).

[0096] In this embodiment, the historical project database adopts a hierarchical storage model, including a historical project table (History_Project) and a historical data table (History_Data).

[0097] Historical project table (History_Project): Records project-level metadata. The key fields include Hist_Pro_ID (historical project ID), Hist_Pro_Name (project name), Hist_Spec (summary of requirement specifications), archive time (Archive_Time), and responsible person (Hist_Owner); History_Data Table: Stores prototype data at the task level. The key fields include Hist_Data_ID (Data ID), Hist_Task_ID (associated task ID), data version (Hist_Version), file format (Hist_Format), and storage path (Hist_Path).

[0098] Preferably, the History_Data Table is associated with the History_Project Table through a foreign key (Hist_Pro_ID), supporting aggregated retrieval by project dimension.

[0099] In this embodiment, the historical prototype data is stored according to a versioning strategy, supporting multi-version traceability and difference comparison.

[0100] Specifically, different versions of data output by the same task (such as design drawings V1.0 and V2.0) are stored independently in the History_Data Table, and the version sequence is marked by the version number (Hist_Version) and timestamp (Hist_Timestamp). Users can retrieve specific version data by submitting version range conditions (such as Hist_Version≥1.0).

[0101] Preferably, the system creates an index (Index_Hist_Spec) for frequently accessed data (such as general component designs) to accelerate data matching efficiency during similarity calculation.

[0102] In this embodiment, the historical project database provides feature data to the intelligent push module through a standardized interface.

[0103] Specifically, when new project requirement indicators (Req_data) are input, the system performs the following operations: Feature vector extraction: Parse parametric features (such as weight, dimensions, material type) from Hist_Spec and convert them into numerical vectors; Data encapsulation: Package the feature vector and associated Hist_Data into a structured data packet (Data_Package) for the similarity calculation unit to call; Result feedback: Receive the matching results (such as Top-5 similar project IDs) from the intelligent push module and return the corresponding Hist_Data to the task interface.

[0104] Preferably, the interface supports batch data pulling and incremental updates to ensure that the intelligent push module can obtain the latest historical data in real time.

[0105] In this embodiment, the archiving process and data table structure of the historical project database achieve a technical closed-loop through predefined configurations.

[0106] Data archiving trigger condition: After the project collaborative management system sends the project completion instruction, the historical project database automatically starts the data pulling and mapping process; Exception handling mechanism: If a field is missing during the data mapping process (such as Req_data is not defined), the system records an error log (Error_Code = E3001) and notifies the administrator to intervene; Data security policy: The archived data is hierarchically controlled according to access permissions. For example, only project team members can modify Hist_Spec, while Hist_Data is read-only open to external users.

[0107] In this embodiment, through project completion verification, field mapping rules, versioned storage and retrieval optimization, the problem of difficult reuse caused by scattered historical data and heterogeneous formats is solved.

[0108] For the intelligent push module: In this embodiment, the intelligent push module is used to realize intelligent matching and recommendation of new project requirement indicators based on historical prototype data. Through feature data extraction, similarity calculation and push decision rules, the associated historical prototype data is accurately pushed to the current R & D task interface to assist designers in quickly reusing historical experience.

[0109] In this embodiment, the intelligent push module converts the new project requirement indicators (A i , B i ) and historical project requirement indicators (a i , b i ) into comparable feature vectors.

[0110] Specifically, the preprocessing process includes the following steps: Textual indicator processing: Tokenize, filter stop words and extract stems for the requirement name (such as "lightweight design") to generate a bag-of-words model or TF-IDF vector; Numerical indicator processing: Normalize the specification parameters (such as weight, size) to eliminate the dimension difference and make them fall into the [0, 1] interval; Composite indicator processing: For a mixed indicator containing text and numerical values (such as "impact resistance level ≥ 5 levels"), split it into a text description ("impact resistance level") and a numerical threshold ("5 levels"), and perform vectorization and standardization respectively.

[0111] Preferably, the preprocessing rules are dynamically configured according to the requirement type (Req_type). For example, for structural requirements, size parameters are preferentially extracted, while for performance requirements, performance level descriptions are emphasized.

[0112] In this embodiment, the similarity calculation unit uses a multi-dimensional weighted algorithm to calculate the matching score S between the new project and the historical project. The specific formula is as follows: 1. Name similarity (S A ): Based on the vectorization results of the requirement names ( representing the new project name vector, representing the historical project name vector), calculate the sum of the cosine similarities: where n is the number of word segments of the requirement name, the numerator is the dot product of the vectors, and the denominator is the product of the vector magnitudes.

[0113] 2. Specification similarity (S B ): Based on the vectorization results of the specification parameters ( representing the new project specification vector, representing the historical project specification vector), calculate the sum of the cosine similarities: where the vector elements are normalized numerical parameters (such as weight, size).

[0114] 3. Comprehensive similarity (S AB ): Take the average value of the name similarity S A and the specification similarity S B : 4. Final matching score (S): Take the weighted average of S A , S B and S AB : Preferably, the weight coefficients can be dynamically adjusted according to the requirement type (Req_type).

[0115] In this embodiment, the push decision unit filters the optimal historical projects according to the matching score S and pushes the associated prototype data (Hist_Data) to the current task interface.

[0116] Specifically, the decision-making process includes: Threshold filtering: Eliminate historical projects with matching scores lower than the preset threshold to ensure the relevance of the push results; Top-N sorting: Sort the remaining projects in descending order of scores and select the top N items (such as Top-5) as the recommended results; Data Association: Associate the prototype data (such as design drawings, test reports) of the recommended historical projects with the current task input / output template, and embed it in the sidebar or pop-up prompt of the task interface.

[0117] Preferably, when presenting the push result, mark the key matching basis (such as "name similarity 92%", "specification deviation ≤ 5%") to facilitate the responsible person to quickly understand the recommendation logic.

[0118] In this embodiment, the intelligent push module pulls the characterized data from the historical project database through a standardized interface.

[0119] Specifically, when the new project requirement indicators are passed in, the module sends a data request to the historical database, and the request parameters include the feature vector, requirement type, and weight configuration. The historical database returns a list of matching historical project IDs and the storage path (Hist_Path) of the associated prototype data.

[0120] Preferably, the interface supports incremental data pulling. For example, when new project data is added to the historical database, the intelligent push module automatically triggers a partial data update to ensure the real-time nature of the recommendation result.

[0121] This embodiment solves the problems of low retrieval efficiency and high reuse threshold of historical prototype data through characterized data processing, multi-dimensional similarity calculation, and dynamic push decision-making.

[0122] Generally speaking, the present invention realizes the standardization and intelligence of the entire R & D process by constructing a closed-loop data management link of the project collaborative management system, project data center, historical project database, and intelligent push module. The system generates a structured R & D task chain based on business opportunity information, and realizes the automatic transfer of cross-task data through a standardized data template; when the project is completed, the data is archived in the historical database according to predefined fields to form a reusable knowledge base; the intelligent push module matches the optimal prototype solution from historical data based on feature vector extraction and multi-dimensional similarity calculation and pushes it to the current task interface, forming a closed-loop management mechanism of "requirement definition → data flow → historical precipitation → intelligent reuse", and solving the problems of scattered data, chaotic format, and difficult experience reuse in traditional R & D.

[0123] Please refer to the appendix Figure 5 , the present invention also provides an intelligent auxiliary method for product R & D based on historical prototype data, which realizes the efficient reuse of R & D experience by constructing a closed-loop management mechanism of requirement decomposition, data flow, historical archiving, and intelligent push.

[0124] Step S1: Project Definition and Task Decomposition Step S11: The user enters the basic information of a new project through the project collaborative management system, including the project name (Pro_Num), project ID (Pro_ID), project type (such as mechanical design, electronic development), and budget (Pro_cost).

[0125] Step S12: The system associates with the business opportunity information in the marketing module, automatically extracts the business opportunity name (Busi_name), customer name (Customer_name), and responsible department (Busi_Department) according to the business opportunity ID (Busi_ID), and binds them to the project information (Pro_Busi_ID).

[0126] Step S13: The system analyzes the marketing plan document associated with the business opportunity, extracts the requirement indicators (Req_data), including performance parameters (such as "impact resistance level ≥ 5 levels"), cost targets (such as "BOM cost ≤ 500 yuan"), etc., generates a project requirement table (Project_Req), and records the requirement ID (Req_ID), requirement type (Req_type), and priority (Req_level).

[0127] Step S14: The user decomposes the requirement indicators, decomposes the high-level requirements into executable design requirement points (Req_path). For example, decomposes "lightweight design" into sub-requirements such as "material selection" and "structural topology optimization", and associates the responsible person (Req_author) and tracking status (Req_status).

[0128] Step S15: The system calls a predefined plan template (Pro_Plan) to automatically generate a R & D task chain. Each task is bound to input / output data templates (Input_Template, Output_Template). For example, the output template of the "3D modeling" task specifies the STEP format file, version number (Data_Version), and reference standard. After the task is assigned to the responsible person (Pro_mana), the system records the requirement tracking matrix (Req_resList).

[0129] Step S2: Task execution and data submission After receiving the task, the person in charge of the R & D task views the data format required by the input template (such as STEP file), associated requirement points (Req_path), and the status of the previous task in the task interface. After completing the task, submit the output data to the project collaborative management system. The system verifies the data integrity (such as required fields) and format compliance (such as file type), and temporarily stores the process data (such as design sketches) in the project data center.

[0130] Step S3: Data transfer and storage Step S31: After the upstream task leader submits the data, the system triggers the data approval process to verify whether the data complies with the output template rules.

[0131] Step S32: After approval, the data is classified and stored in the project data center according to the task ID (Task_ID), data type (Data_type), and version number (Data_Version), and the data source task (Data_Source) and template information are recorded.

[0132] Step S33: When the downstream task starts, the system automatically pulls the matching upstream output data from the project data center according to the field definitions of its input template (Input_Template) (such as Data_type = simulation parameters) and fills it into the downstream task input interface.

[0133] Step S34: If the upstream data version is updated, the system synchronously updates the downstream input data version, marks the change status (such as "to be updated"), and pushes a reminder to the downstream responsible person.

[0134] Step S4: Completion verification and historical archiving Step S41: When the project is completed, the system verifies the task completion rate (Task_completion = 100%), risk closure status (Risk_status = Resolved), and data approval status (Data_Approval = Passed).

[0135] Step S42: After passing the verification, the system extracts the requirement indicators (Req_data), task output data (Output_Template), and associated metadata (such as version sequence, task dependencies) from the project data center.

[0136] Step S43: According to the predefined field mapping rules, the data is converted into the historical database structure. For example, Req_data is mapped to the historical requirement specification (Hist_Spec), Output_Template is mapped to the historical prototype data (Hist_Data), and the original task chain (Hist_Task_ID) is associated.

[0137] Step S44: The archived data is stored in the historical project database, and an index (such as according to the performance parameters in Hist_Spec) is established to support efficient retrieval.

[0138] Step S5: New project requirement matching Step S51: When a new project is created, the user enters the key requirement indicators (such as "waterproof level IP68"), and the system associates the business opportunity information (Busi_ID) in the marketing module and parses the requirements.

[0139] Step S52: The system extracts the requirement specifications (Hist_Spec) of similar projects from the historical project database and calculates the matching score between the new requirements and the historical requirements using the cosine similarity algorithm.

[0140] Step S53: Push similar historical projects sorted by matching degree (such as Top-5) and display the associated parameters (such as "sealing structure design drawing", "test report") of the historical prototype data (Hist_Data). After the user selects the association, the system establishes a reference relationship between the new task and the historical data.

[0141] Step S6: Intelligent push of historical data Step S61: During the task execution process, the system extracts the input / output data features (such as requirement type, specification parameters) of the current task and compares them with the Hist_Spec in the historical database in real time.

[0142] Step S62: When similar historical data is matched, the system pushes the associated prototype data (such as "sealing ring selection table", "environmental test plan") to the sidebar of the task interface and marks the matching basis (such as "requirement similarity 92%").

[0143] The person in charge can view the details of the historical data and choose to directly reference some content (such as bill of materials, test cases) into the output data of the current task.

[0144] This method solves the problems of scattered R & D data and difficult reuse of historical experience through standardized task decomposition, automated data transfer, structured historical archiving, and intelligent push decision-making.

[0145] Please refer to the appendix Figure 6 In addition, the present invention also provides a computer device 40, including: a processor 41 and a memory 42. The memory 42 stores a computer program executable by the processor. When the computer program is executed by the processor, the above method is executed.

[0146] The present invention also provides a storage medium 43. A computer program is stored on the storage medium 43. When the computer program is run by the processor 41, the above method is executed.

[0147] Among them, the storage medium 43 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disc.

[0148] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. An intelligent auxiliary system for product R & D based on historical prototype data, characterized in that, Including: A project collaborative management system, which is used to define product R & D projects, decompose R & D tasks, associate business opportunity information of the marketing module, analyze the marketing plan requirement indicators corresponding to business opportunities, and generate R & D tasks and standardized data templates associated with the requirement indicators. A project data center, which receives the data generated by the R & D tasks, classifies and stores the data according to the standardized data template, and automatically transfers the upstream task output data to the downstream task input data based on the template matching rule. A historical project database, which receives the R & D data from the project data center after the project is completed and archives the data according to the predefined field structure. An intelligent push module, which matches similar historical prototype data from the historical project database according to the requirement indicators entered for the new project and pushes the matching results to the input / output data interface of the current R & D task.

2. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 1, wherein The project collaborative management system includes: A business opportunity management unit, which is used to bind business opportunity information with project basic information and generate project requirements. A requirement decomposition unit, which decomposes the requirement indicators in the marketing plan into executable product design requirement points and associates them with the R & D tasks.

3. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 2, wherein, The requirement decomposition unit generates R & D tasks including input / output data templates by calling predefined plan templates, assigns the tasks to responsible persons, and records the requirement tracking results at the same time.

4. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 1, wherein The project data center includes: A data template definition unit, which defines standardized templates for input / output data for each R & D task. The template fields include data type, version number, and source task. A data transfer unit, which matches the data with the same template from the output data of the upstream task according to the input template of the downstream task and automatically fills it into the downstream task input interface.

5. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 4, characterized in that, When the data transfer unit detects an update of the upstream task data, it triggers the data version synchronization of the downstream task, updates the downstream input data and marks the change status, and pushes a reminder to the responsible person at the same time.

6. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 1, wherein The archiving process of the historical project database includes: A project completion verification unit, which verifies the project task completion rate, risk closure status, and data approval status. A data mapping unit, which maps the data in the project data center to the historical project database according to the predefined fields.

7. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 1, characterized in that, The intelligent push module includes: A similarity calculation unit, which calculates the matching score between the new project requirement indicators and the historical project requirement indicators based on the cosine similarity algorithm. A push decision unit, which screens the top-N historical projects according to the matching score and pushes the associated prototype data to the current R & D task interface.

8. The intelligent auxiliary system for product R & D based on historical prototype data according to claim 7, characterized in that, The calculation formula of the matching score is: Among them, S A is the name similarity, S B is the specification similarity, and S AB is the comprehensive similarity.

9. An intelligent auxiliary method for product R & D based on historical prototype data, according to the system described in any one of claims 1-8, characterized in that, Including the following steps: Define R & D projects and associate business opportunity information, analyze the marketing plan requirement indicators, and generate R & D tasks and standardized data templates associated with the requirement points. Based on the standardized data template, automatically transfer the upstream task output data to the downstream task input interface. After the project is completed, archive the R & D data to the historical project database according to the predefined field structure. According to the new project requirement indicators, match similar prototype data from the historical project database and push it to the current task interface.

10. A storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by a processor, it implements the method described in claim 9.

Images