Intelligent robot research and development test resource collaborative management system
Through the intelligent robot research and development test resource collaborative management system, the problems of resource waste and progress impact in multi-team collaboration have been solved, and efficient utilization of hardware resources and optimization of test progress have been achieved.
Patent Information
- Application Number
- CN202510831870.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-20
- Publication Date
- 2025-09-12
AI Technical Summary
In the R&D and testing of intelligent robots, when multiple teams collaborate and share hardware resources, there are problems of resource waste and impact on testing progress.
Provides a collaborative management system for intelligent robot R&D and testing resources, including a hardware visualization module, a team rating module, a test plan appointment sorting module, a hardware allocation module, and a test library module. It optimizes resource allocation and test plans through real-time updates of hardware information, team keyword matching, conflict detection, and similarity evaluation.
It achieves efficient utilization of hardware resources, avoids resource waste, ensures that high-value projects receive priority resources, and improves testing progress and overall R&D efficiency.
Smart Images

Figure CN120634479A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of robot research and development, and in particular to a collaborative management system for intelligent robot research and development and testing resources. Background Art
[0002] Robot testing is the process of testing the software and hardware systems of a robot. Its purpose is to detect and evaluate the robot's performance, reliability, stability, and safety characteristics under various circumstances. Robot testing can be effectively carried out through various testing methods and standards.
[0003] The robot testing phase includes: unit testing: independent testing of each unit in the robot system to verify its correctness; component testing: testing of components composed of multiple units to verify their functions and performance; system testing: testing the entire robot system to verify its system functions, performance and stability; integration testing: integration testing of the robot system with other systems to verify its overall performance and system compatibility; acceptance testing: the user confirms the test results to determine whether the robot meets user needs and design requirements.
[0004] The development and testing of intelligent robots involves multi-team collaboration and shared hardware resources. When formulating R&D and testing plans, due to a lack of communication between teams, overlapping R&D directions among multiple teams lead to a waste of R&D resources. At the same time, idle hardware resources also affect the testing progress. Summary of the Invention
[0005] (1) Purpose of the invention
[0006] In order to solve the technical problems existing in the background technology, the present invention proposes an intelligent robot R&D and testing resource collaborative management system, which has the characteristics of efficient utilization of resources in the R&D and testing process.
[0007] (2) Technical solution
[0008] To solve the above technical problems, the present invention provides an intelligent robot R&D and testing resource collaborative management system, comprising:
[0009] The hardware visualization module visualizes hardware resources, and the resource chart updates the basic information, location information, status information and maintenance information of all hardware in real time;
[0010] The team rating module extracts technical keywords based on the team's R&D direction and associates them with the technology database. It also performs semantic analysis and keyword overlap testing on R&D projects, and quantifies their priority ratings.
[0011] Test plan appointment and sorting module: each team develops a standardized test plan and reserves the required hardware. Conflicting requirements are sorted by appointment time and priority.
[0012] In the hardware allocation module, non-task hardware that exceeds the idle time threshold is marked on the resource chart. Non-task hardware is matched with R&D projects and special test plans are assigned;
[0013] The test library module aggregates test results into the test library and traverses the test library for similarity evaluation before implementing future test plans;
[0014] The similarity comparison module reminds you to reuse the test results when the similarity difference is ≤20%, otherwise the test plan will be implemented.
[0015] Preferably, the basic information of the hardware resource includes model, serial number, and storage time;
[0016] The location information is obtained by the GPS module installed in the hardware and is used to locate the current location of the hardware;
[0017] Status information includes in use, idle, faulty, calibrating, and status update time;
[0018] Maintenance information: time of the most recent failure, cause of the failure, maintenance results and person responsible for the maintenance.
[0019] Preferably, the processing of hardware resources also includes visual alarms for abnormal conditions. An alarm unit is set at each hardware location. When a device fails, such as when the temperature exceeds a threshold or the battery is low, an audible alarm is sounded through the speaker of the alarm unit.
[0020] Preferably, the process of extracting technical keywords and associating them with the technical database according to the team's R&D direction includes:
[0021] The team submitted a project plan and test requirements document for the corresponding R&D direction, and used NLP technologies such as BERT and CRF to automatically extract technical keywords from the project description;
[0022] The extracted keywords are combined with the robot database for semantic analysis and stored in the technical database after manual review.
[0023] Preferably, as an example of keyword overlap test: calculating the keyword overlap between the new item and the historical item;
[0024] Similarity formula:
[0025] Among them, A is the new project keyword set, and B is the historical project keyword set; J(A,B)∈[0,1], the larger the value, the higher the overlap, such as J=0.8 indicates high overlap.
[0026] Preferably, as a quantitative example of priority rating: the comprehensive priority is calculated by weighting:
[0027] , define the three-dimensional scoring standard with a full score of 5 points,
[0028] Among them, O is the purpose value, E is the urgency, and R is the resource requirement.
[0029] Preferably, conflict detection is performed when reserving hardware.
[0030] The conflict detection steps sorted by time are as follows: the same hardware is in the sequence of scheduled submission review times in each standardized test plan;
[0031] When the two scheduled times are the same, the priorities of the two plans are compared. After the priority score is higher, the task with higher priority will take up the hardware first, and the hardware call time of the task with lower priority will be postponed.
[0032] When there are at least two deferred tasks at the same time, the priorities of the deferred tasks are compared again, and the hardware call time is deferred again.
[0033] Preferably, the non-task hardware that exceeds the idle time threshold includes: no tasks for 48 consecutive hours from the end of the last task; not assigned to any R&D project, and not under calibration or maintenance;
[0034] The system automatically scans the hardware status, and eligible devices are marked as idle in the resource chart;
[0035] The steps for matching non-mission hardware with R&D projects and issuing special test plans include:
[0036] According to the hardware list of the test plan, select devices with exact matching models from the idle hardware. If there is no exact match, select compatible devices of the same series and mark the compatibility risks;
[0037] The system recommends several compatible devices of the same series. The project leader must confirm that they accept the compatibility risk after selecting them.
[0038] When distributing, the test project and hardware are bound and a usage deadline is set. Idle equipment must be put into use within 7 days after distribution. If it is not used after the deadline, it will be automatically released as a public resource.
[0039] Preferably, the test library is hierarchical using labels, and the labels correspond to the test templates of the standardized test plan, including test type labels, hardware model labels, project name labels, environmental parameter labels, and time labels;
[0040] The similarity evaluation of future test scenarios is based on a multi-dimensional weighted calculation formula: ;
[0041] Define the similarity S between the new test plan Tn and the historical test plan T;
[0042] E is the environmental similarity: based on the matching degree of environmental parameters such as temperature, humidity, and scene type, it is calculated using normalized Euclidean distance in the range [0, 1], where the closer to 1, the more similar;
[0043] H is the hardware similarity: based on the matching degree of hardware model and version, perfect match = 1, compatible with the same series = 0.8, incompatible = 0;
[0044] G is the target similarity: based on the test type and the matching degree of the verification target, the semantic overlap of the test cases is calculated using cosine similarity, ranging from [0, 1]. The closer to 1, the more similar.
[0045] is the weight, , adjusted according to business needs.
[0046] The above technical solution of the present invention has the following beneficial technical effects:
[0047] 1. By updating basic hardware information in real time, it solves the problems of traditional manual recording being prone to errors and information lag.
[0048] 2. Ensure that key projects with high strategic value, high urgency and high resource demand receive priority resources through priority sorting.
[0049] 3. Through conflict resolution strategies, hardware can be prevented from being occupied for a long time by a single task, and idle hardware can be automatically identified to improve the turnover rate of hardware resources.
[0050] 4. Structured storage of test results: By building a test library through label classification, test results can be searched and reused. Intelligent reuse of test results can improve overall R&D efficiency and quality. BRIEF DESCRIPTION OF THE DRAWINGS
[0051] Figure 1 Schematic diagram of the system of the present invention. DETAILED DESCRIPTION
[0052] To make the objectives, technical solutions, and advantages of the present invention more clearly understood, the present invention will be further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present invention.
[0053] like Figure 1 As shown, the intelligent robot R&D and testing resource collaborative management system proposed by the present invention includes:
[0054] The hardware visualization module visualizes hardware resources, and the resource chart updates the basic information, location information, status information and maintenance information of all hardware in real time;
[0055] It is understandable that the basic information includes model number, serial number, and storage time;
[0056] The location information is obtained by the GPS module installed in the hardware and is used to locate the current location of the hardware;
[0057] Status information includes in use, idle, faulty, calibrating, and status update time;
[0058] Maintenance information: time of the most recent failure, cause of the failure, maintenance results and person responsible for the maintenance.
[0059] Each piece of hardware is connected to the Internet of Things platform through hardware sensors and RFID tag modules. The hardware location information and real-time status are updated at a frequency of 5 seconds. The movement trajectory coordinates of each piece of hardware and the time curve chart of each piece of hardware operation status are recorded separately for historical record.
[0060] In one embodiment, an alarm unit is set up at each hardware location for visual alarm of abnormal status. When a device fails, such as when the temperature exceeds a threshold or the battery is low, an audible alarm is sounded through the speaker of the alarm unit, and the resource chart is highlighted and a pop-up window is displayed to assist the administrator in responding quickly.
[0061] The team rating module extracts technical keywords based on the team's R&D direction and associates them with the technology database. It also performs semantic analysis and keyword overlap testing on R&D projects, and quantifies their priority ratings.
[0062] The process of extracting technical keywords based on the team's R&D direction and linking them to the technology database includes the following: the team submits a project plan and test requirements document for the corresponding R&D direction, and then uses the NLP technology BERT and CRF to automatically extract technical keywords from the project description;
[0063] For example, the keywords for the SLAM algorithm in the research and development direction include laser point cloud registration, dynamic object culling, lidar, and high-computing-power GPU.
[0064] The extracted keywords are combined with the robot database for semantic analysis to accurately understand the technical fields of the R&D project, such as navigation, control, perception, and human-computer interaction, and stored in the technology database after manual review.
[0065] As an example of keyword overlap testing: calculate the keyword overlap between new items and historical items;
[0066] Similarity formula:
[0067] Among them, A is the new project keyword set, and B is the historical project keyword set; J(A,B)∈[0,1], the larger the value, the higher the overlap, such as J=0.8 indicates high overlap.
[0068] As a quantitative example of priority rating: Calculate the overall priority by weighting:
[0069] , define the three-dimensional scoring standard with a full score of 5 points,
[0070] O Purpose value: 5 points for core products, 3 points for pre-research projects, and 1 point for internal validation;
[0071] E urgency: 5 points for delivery nodes, 3 points for quarterly milestones, and 1 point for routine R&D;
[0072] R Resource Requirements: 5 points for scarce equipment, 1 point for general equipment;
[0073] For example, a core product R&D and testing project is at the delivery node and requires scarce equipment. Then O=5, E=5, R=5, and the calculated P=0.4×5+0.3×5+0.3×5=2+1.5+1.5=5 points, which is the highest priority.
[0074] Test plan appointment and sorting module: each team develops a standardized test plan and reserves the required hardware. Conflicting requirements are sorted by appointment time and priority.
[0075] It should be noted that developing a standardized test plan includes filling out a test template, which includes a test ID associated with a unique identifier, the project name associated with the R&D project, the test type involving function, performance, and reliability, the test environment associated with temperature, humidity, and scenario types, test cases with input data and expected outputs, a hardware list associated with models and quantities, and the time associated with the test;
[0076] Conflict detection is performed when reserving hardware. The conflict detection steps are sorted by time: the same hardware is in the sequence of the scheduled submission review time in each standardized test plan;
[0077] If a hardware has been reserved for 9:00-11:00, and a new reservation is requested for 11:00-13:00, a conflict will occur and the hardware will be assigned to the original request first.
[0078] When the two scheduled times are the same, the priorities of the two plans are compared. After the priority score is higher, the task with higher priority will take up the hardware first, and the hardware call time of the task with lower priority will be postponed.
[0079] When there are at least two deferred tasks at the same time, the priorities of the deferred tasks are compared again, and the hardware call time is further deferred;
[0080] It is understood that when any task is automatically extended, the original applicant will be notified and informed of the reason for the task extension.
[0081] In the hardware allocation module, non-task hardware that exceeds the idle time threshold is marked on the resource chart. Non-task hardware is matched with R&D projects and special test plans are assigned;
[0082] Non-task hardware exceeding the idle time limit includes: no mission for 48 consecutive hours from the end of the last mission; not assigned to any R&D project, and not under calibration or maintenance;
[0083] The system automatically scans the hardware status, and eligible devices are marked as idle in the resource graph.
[0084] The steps for matching non-mission hardware with R&D projects and issuing special test plans include:
[0085] According to the hardware list of the test plan, select devices with exact matching models from the idle hardware. If there is no exact match, select compatible devices of the same series and mark the compatibility risks;
[0086] The system recommends several compatible devices of the same series. The project leader must confirm that they accept the compatibility risk after selecting them.
[0087] When distributing, the test project and hardware are bound and a usage deadline is set. Idle equipment must be put into use within 7 days after distribution. If it is not used after the deadline, it will be automatically released as a public resource.
[0088] The test library module aggregates test results into the test library and traverses the test library for similarity evaluation before implementing future test plans;
[0089] The test library is hierarchical using labels. The labels correspond to the test templates of the standardized test plan, including test type labels, hardware model labels, project name labels, environmental parameter labels, and time labels.
[0090] The similarity evaluation of future test scenarios is based on a multi-dimensional weighted calculation formula: ;
[0091] Define the similarity S between the new test plan Tn and the historical test plan T;
[0092] E is the environmental similarity: based on the matching degree of environmental parameters such as temperature, humidity, and scene type, it is calculated using normalized Euclidean distance in the range [0, 1], where the closer to 1, the more similar;
[0093] H is the hardware similarity: based on the matching degree of hardware model and version, perfect match = 1, compatible with the same series = 0.8, incompatible = 0;
[0094] G is the target similarity: based on the test type and the matching degree of the verification target, the semantic overlap of the test cases is calculated using cosine similarity, ranging from [0, 1]. The closer to 1, the more similar.
[0095] For weights (such as , adjusted according to business needs.
[0096] The similarity comparison module reminds you to reuse the test results when the similarity difference is ≤20%, otherwise the test plan will be implemented.
[0097] The difference threshold is set. When the total similarity S≥0.8, the test result reuse reminder is triggered; otherwise, if S<0.8, the new test plan is directly implemented.
[0098] As a reuse test review mechanism: the system automatically sends a similarity report, including E, H, and G sub-scores, to the test leader;
[0099] The test leader needs to confirm whether the environment / hardware differences affect the validity of the results. For example, if the sensor has been calibrated and the software version has not been upgraded, the test results can be reused after passing.
[0100] If there are key differences, such as an increase in computing power due to a hardware version upgrade, the system's automatic marking results may become invalid and require retesting.
[0101] It is understandable that when new test results are stored, the technical database is updated simultaneously, such as adding that the failure rate of a certain sensor increases in rainy days.
[0102] It should be understood that the above-described specific embodiments of the present invention are merely illustrative or illustrative of the principles of the present invention and do not constitute limitations of the present invention. Therefore, any modifications, equivalent substitutions, improvements, etc. made without departing from the spirit and scope of the present invention should be included within the scope of protection of the present invention. In addition, the appended claims are intended to cover all variations and modifications that fall within the scope and metes and bounds of the appended claims, or equivalents thereof.
Claims
1. Intelligent robot R&D and testing resource collaborative management system, characterized by: include: The hardware visualization module visualizes hardware resources, and the resource chart updates the basic information, location information, status information and maintenance information of all hardware in real time; The team rating module extracts technical keywords based on the team's R&D direction and associates them with the technology database. It also performs semantic analysis and keyword overlap testing on R&D projects, and quantifies their priority ratings. Test plan appointment and sorting module: each team develops a standardized test plan and reserves the required hardware. Conflicting requirements are sorted by appointment time and priority. In the hardware allocation module, non-task hardware that exceeds the idle time threshold is marked on the resource chart. Non-task hardware is matched with R&D projects and special test plans are assigned; The test library module aggregates test results into the test library and traverses the test library for similarity evaluation before implementing future test plans; The similarity comparison module reminds you to reuse the test results when the similarity difference is ≤20%, otherwise the test plan will be implemented.
2. The intelligent robot R&D and testing resource collaborative management system according to claim 1 is characterized in that: Basic information of hardware resources includes model, serial number, and storage time; The location information is obtained by the GPS module installed in the hardware and is used to locate the current location of the hardware; Status information includes in use, idle, faulty, calibrating, and status update time; Maintenance information: time of the most recent failure, cause of the failure, maintenance results and person responsible for the maintenance.
3. The intelligent robot R&D and testing resource collaborative management system according to claim 1 is characterized in that: The processing of hardware resources also includes visual alarms for abnormal conditions. Alarm units are set up at each hardware location. When a device fails, such as when the temperature exceeds the threshold or the battery is low, an audible alarm is issued through the alarm unit's speaker.
4. The intelligent robot R&D and testing resource collaborative management system according to claim 1, characterized in that: The process of extracting technical keywords based on the team's R&D direction and associating them with the technology database includes: The team submitted a project plan and test requirements document for the corresponding R&D direction, and used NLP technologies such as BERT and CRF to automatically extract technical keywords from the project description; The extracted keywords are combined with the robot database for semantic analysis and stored in the technical database after manual review.
5. The intelligent robot R&D and testing resource collaborative management system according to claim 1 is characterized in that: As an example of keyword overlap testing: calculate the keyword overlap between new items and historical items; Similarity formula: Among them, A is the new project keyword set, and B is the historical project keyword set; J(A,B)∈[0,1], the larger the value, the higher the overlap, such as J=0.8 indicates high overlap.
6. The intelligent robot R&D and testing resource collaborative management system according to claim 1, characterized in that: As a quantitative example of priority rating: Calculate the overall priority by weighting: , define the three-dimensional scoring standard with a full score of 5 points, Among them, O is the purpose value, E is the urgency, and R is the resource requirement.
7. The intelligent robot R&D and testing resource collaborative management system according to claim 1, characterized in that: Conflict detection is performed when reserving hardware. The conflict detection steps sorted by time are as follows: the same hardware is in the sequence of scheduled submission review times in each standardized test plan; When the two scheduled times are the same, the priorities of the two plans are compared. After the priority score is higher, the task with higher priority will take up the hardware first, and the hardware call time of the task with lower priority will be postponed. When there are at least two deferred tasks at the same time, the priorities of the deferred tasks are compared again, and the hardware call time is deferred again.
8. The intelligent robot R&D and testing resource collaborative management system according to claim 1, characterized in that: Non-task hardware exceeding the idle time limit includes: no mission for 48 consecutive hours from the end of the last mission; not assigned to any R&D project, and not under calibration or maintenance; The system automatically scans the hardware status, and eligible devices are marked as idle in the resource chart; The steps for matching non-mission hardware with R&D projects and issuing special test plans include: According to the hardware list of the test plan, select devices with exact matching models from the idle hardware. If there is no exact match, select compatible devices of the same series and mark the compatibility risks; The system recommends several compatible devices of the same series. The project leader must confirm that they accept the compatibility risk after selecting them. When distributing, the test project and hardware are bound and a usage deadline is set. Idle equipment must be put into use within 7 days after distribution. If it is not used after the deadline, it will be automatically released as a public resource.
9. The intelligent robot R&D and testing resource collaborative management system according to claim 1, characterized in that: The test library is hierarchical and the labels correspond to the test templates of the standardized test plan, including test type labels, hardware model labels, project name labels, environmental parameter labels and time labels; The similarity evaluation of future test scenarios is based on a multi-dimensional weighted calculation formula: ; Define the similarity S between the new test plan Tn and the historical test plan T; E is the environmental similarity: based on the matching degree of environmental parameters such as temperature, humidity, and scene type, it is calculated using normalized Euclidean distance in the range [0, 1], where the closer to 1, the more similar; H is the hardware similarity: based on the matching degree of hardware model and version, perfect match = 1, compatible with the same series = 0.8, incompatible = 0; G is the target similarity: based on the test type and the matching degree of the verification target, the semantic overlap of the test cases is calculated using cosine similarity, ranging from [0, 1]. The closer to 1, the more similar. is the weight, , adjusted according to business needs.
Citation Information
Cited By
Fire-fighting reconnaissance robot system hardware reliability evaluation method
CN121682545A