Instrument detection system and method

The automated testing method of the instrument testing system solves the problem of large errors in traditional manual testing, realizes efficient and accurate recording of test results and quality traceability, and improves testing efficiency and accuracy.

CN121209745BActive Publication Date: 2026-04-07GUANGZHOU CHUANG RUI AUTOMOBILE ELECTRIC APPLIANCE CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-12-01
Publication Date
2026-04-07

AI Technical Summary

Technical Problem

Traditional instrument testing methods rely on manual operation, which leads to large errors in the test results and makes it difficult to guarantee testing efficiency and accuracy.

Method used

The instrument-based testing system, consisting of a main system and several subsystems, achieves automated testing through a weakly correlated architecture. It integrates visual inspection, hardware control, and process management, provides templated configuration and online status synchronization, and supports cross-device compatibility and visual monitoring.

Benefits of technology

It improves testing efficiency and accuracy, reduces human error, ensures product quality stability and repeatability, and enables rapid and accurate traceability of quality issues and data recording.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121209745B_ABST
    Figure CN121209745B_ABST
Patent Text Reader

Abstract

The application provides an instrument detection system and method, and belongs to the technical field of instrument detection. The application comprises: a main system for calling a subsystem, controlling instrument detection; the main system comprises a main interface and a formula adding interface; the main interface is used for displaying instrument detection information and prompting equipment operation information; the main interface comprises a visual detection picture, a detection item list, a current detection item, an operation button, a detection result, a running log, a detection quantity statistics, a traceability barcode state, equipment state and equipment operation prompts; the formula adding interface is used for instrument detection of a detection formula customized by a user; the formula adding interface comprises a new product, a new configuration, a control mode, a mode selection, a calling template name, a detection result, an interval time, a cycle number and a single-step execution button; the subsystem is used for providing running data to the main system and receiving instructions; a weak association architecture is adopted between the main system and the subsystem. The application can improve detection efficiency and detection accuracy.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of instrument testing technology, and in particular to instrument testing systems and methods. Background Technology

[0002] In related technologies, end-of-line (EOL) testing is a crucial step in ensuring product quality during the production of precision instruments such as automotive and home appliance instruments. However, traditional testing involves operators manually operating equipment such as power supplies and signal generators according to a checklist, and visually observing the dashboard display (such as pointer position, screen characters, and indicator light colors) and manually recording the results. This method, however, has a large margin of error in its testing results.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose an instrument testing system and method that can improve testing efficiency and accuracy.

[0005] To achieve the above objectives, one aspect of this application provides an instrument testing system, which includes a main system and several subsystems;

[0006] The main system is used to call the subsystems and control instrument detection; the main system includes a main interface and a recipe addition interface.

[0007] The main interface is used to display instrument detection information and prompt equipment operation information; the main interface includes visual inspection screen, inspection item list, current inspection item, operation button, inspection results, operation log, inspection quantity statistics, traceability barcode status, equipment status and equipment operation prompts;

[0008] The formula addition interface is used to perform instrument testing on user-defined test formulas; the formula addition interface includes new product, new configuration, control method, mode selection, template name, test result, interval time, number of cycles, and single-step execution button;

[0009] The subsystem is used to provide operating data and receive instructions from the main system;

[0010] The main system and the subsystems adopt a weakly related architecture.

[0011] In some embodiments, the weakly associated architecture includes:

[0012] An interface standardization module is used to perform communication between the main system and the subsystem through a unified calling protocol;

[0013] The main system has a subsystem registration and discovery module, which is used to identify and call newly added and registered subsystems;

[0014] The main system performs process scheduling, permission management, and status feedback, while the subsystems perform business logic processing.

[0015] In some embodiments, the system further includes a process configuration visualization module and a process verification and fault tolerance module;

[0016] The process configuration visualization module is used for users to customize at least one of the following: the calling order of subsystems, the triggering conditions of subsystems, and the parameter rules passed to subsystems;

[0017] When the process verification and fault tolerance module detects an abnormality in a subsystem or hardware board, it performs operations to skip the abnormal steps or enable an alternative call path.

[0018] In some embodiments, the system employs a templated configuration mechanism, including:

[0019] The template supports a parameterized configuration module, which allows users to customize at least one parameter among detection accuracy, process steps, and data output format.

[0020] The template version management module is used to perform template modification, archiving, and rollback operations;

[0021] The combined invocation module is used to combine templates from multiple subsystems to form a composite detection scheme.

[0022] In some embodiments, the subsystem has templates for cross-device compatibility, adapting to different models or manufacturers of instrumentation equipment through parameter adjustments;

[0023] The main system and the subsystems adopt an online status synchronization mechanism to perform visual monitoring and feed back the operating status and detection data of the subsystems to the main system online.

[0024] The system executes processes such as batch import and export of templates, and copies and migrates detection schemes.

[0025] In some embodiments, the main system further includes a product production record interface, an equipment information interface, and a permission setting interface;

[0026] The product production record interface is used to record the testing time of the produced product, the corresponding barcode of the product, the test results and data content;

[0027] The device information interface is used to display the status of devices connected to the main system;

[0028] The permission settings interface is used to define user permissions.

[0029] In some embodiments, the category of subsystems includes an instrument vision inspection subsystem;

[0030] The instrument visual inspection subsystem is used to recognize patterns and characters on the instrument interface, detect dissimilar colors, judge light leakage on the side of the instrument, and cancel or enable it according to the task.

[0031] The instrument vision inspection subsystem includes a vision camera parameter setting interface, a vision inspection tool addition interface, a product vision inspection template interface, and a product vision template management list.

[0032] In some embodiments, the category of subsystems includes hardware configuration subsystems;

[0033] The hardware configuration subsystem is used to uniformly manage the testing hardware and provides a standardized control interface;

[0034] The hardware configuration subsystem includes a hardware communication configuration interface, a hardware function setting interface, and a hardware software permission interface.

[0035] In some embodiments, the category of subsystems includes an instrument communication protocol subsystem;

[0036] The instrument communication protocol subsystem is used to edit the protocols and messages for data communication with the instrument, and to set up and send messages according to the user-defined product protocol formula; the product protocol formula includes formula name, protocol content, version and remarks;

[0037] The instrument communication protocol subsystem includes a communication settings interface and a product protocol formula interface.

[0038] To achieve the above objectives, another aspect of this application provides an instrument testing method for use with the instrument testing system described above, the method comprising:

[0039] The test formula for the instrument under test is set through the main system;

[0040] The subsystem is invoked according to the detection formula to obtain the instrument detection results;

[0041] Determine whether the instrument's test result is qualified. If it is not qualified, terminate the process. If it is qualified, generate a product identification mark.

[0042] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0043] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0044] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0045] The embodiments of this application include at least the following beneficial effects: This application provides an instrument testing method, system, electronic device, storage medium, and program product. The solution includes a main system and several subsystems. The main system is used to call the subsystems and control instrument testing. The main system includes a main interface and a recipe addition interface. The main interface is used to display instrument testing information and prompt equipment operation information. The main interface includes a visual inspection screen, a list of testing items, the current testing item, operation buttons, testing results, operation logs, testing quantity statistics, traceability barcode status, equipment status, and equipment operation prompts. The recipe addition interface is used to perform instrument testing on user-defined testing recipes. The recipe addition interface includes options for creating a new product, creating a new configuration, control method, mode selection, calling template name, testing results, interval time, number of loops, and a single-step execution button. The subsystems are used to provide operating data to the main system and receive instructions. This application can improve testing efficiency and accuracy. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the overall system configuration framework provided in the embodiments of this application;

[0047] Figure 2 This is a schematic diagram of the overall software architecture provided in the embodiments of this application;

[0048] Figure 3 This is a schematic diagram of the main interface provided in an embodiment of this application;

[0049] Figure 4 This is a schematic diagram of the recipe addition interface provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram illustrating the internal logic of the method of adding a formula provided in the embodiments of this application;

[0051] Figure 6 This is a schematic diagram of the production record interface provided in an embodiment of this application;

[0052] Figure 7 This is a schematic diagram of the device information interface provided in an embodiment of this application;

[0053] Figure 8This is a schematic diagram of the hardware configuration software architecture provided in the embodiments of this application;

[0054] Figure 9 This is a schematic diagram of the hardware communication configuration interface provided in an embodiment of this application;

[0055] Figure 10 This is a schematic diagram of the power control card interface provided in an embodiment of this application;

[0056] Figure 11 This is a schematic diagram of the PLC control interface provided in the embodiments of this application;

[0057] Figure 12 This is a schematic diagram of the communication settings interface provided in an embodiment of this application;

[0058] Figure 13 This is a schematic diagram of the serial communication interface provided in an embodiment of this application;

[0059] Figure 14 This is a schematic diagram of the CAN communication settings interface provided in an embodiment of this application;

[0060] Figure 15 This is a schematic diagram of the product protocol formulation interface provided in an embodiment of this application;

[0061] Figure 16 This is a schematic diagram of the settings of the CAN communication protocol provided in the embodiments of this application;

[0062] Figure 17 This is a schematic diagram of the form of the product protocol formulation provided in the embodiments of this application;

[0063] Figure 18 This is a schematic diagram of the product visual inspection template interface provided in the embodiments of this application;

[0064] Figure 19 This is a schematic diagram of the printing parameter setting interface provided in an embodiment of this application;

[0065] Figure 20 This is a schematic diagram of the product printing template creation interface provided in the embodiments of this application;

[0066] Figure 21 This is a simplified schematic diagram of the upload and email third-party system process provided in the embodiments of this application;

[0067] Figure 22 This is a detailed flowchart illustrating the upload and email third-party system process provided in this application embodiment;

[0068] Figure 23 This is a schematic diagram of the request parameters provided in an embodiment of this application;

[0069] Figure 24 This is a schematic diagram of the return parameters provided in the embodiments of this application;

[0070] Figure 25 This is a schematic diagram of the common request parameters provided in the embodiments of this application;

[0071] Figure 26 This is a schematic diagram of the common return parameters provided in the embodiments of this application. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0073] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0074] Before providing a detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application shall be explained first. The nouns and terms involved in the embodiments of this application shall be interpreted as follows: (1) EOL communication protocol, end-of-line communication protocol; (2) Modbus RTU protocol, a serial communication protocol; (3) DLL, dynamic link library; (4) PLC, programmable logic controller; (5) UART, universal asynchronous transceiver; (6) CAN, controller area network; (7) K-line, a diagnostic communication line; (8) Blob, blob analysis, a machine vision technology; (9) Data Matrix, a two-dimensional matrix code; (10) QR code, fast response matrix code; (11) UUID, universal unique identifier; (12) UDS, unified diagnostic service; (13) ECU, electronic control unit; (14) IOT, Internet of Things.

[0075] The relevant technologies require a software system that integrates visual inspection, hardware control, process management, and traceability control. This system will enable accurate multi-dimensional instrument inspection, standardized data recording, and efficient process collaboration, meeting the needs of production quality control and management.

[0076] In view of this, the present application provides an instrument testing system and method, which improves testing efficiency and accuracy.

[0077] The instrument detection system of this application embodiment includes a main system and several subsystems;

[0078] The main system is used to call subsystems and control instrument detection; the main system includes a main interface and a recipe addition interface;

[0079] The main interface is used to display instrument detection information and prompt equipment operation information; the main interface includes visual inspection screen, inspection item list, current inspection item, operation buttons, inspection results, operation log, inspection quantity statistics, traceability barcode status, equipment status, and equipment operation prompts;

[0080] The new formula interface is used to perform instrument testing on user-defined test formulas; the new formula interface includes options for creating a new product, creating a new configuration, control method, mode selection, calling template name, test results, interval time, number of cycles, and a single-step execution button;

[0081] The subsystem is used to provide operational data to the main system and receive instructions;

[0082] The main system and subsystems adopt a weakly related architecture.

[0083] This application embodiment, by executing a preset "test recipe," allows for customization of the testing process, standards, and operations for each instrument. This significantly reduces errors and variations caused by human factors, ensuring product quality stability and repeatability. The main interface integrates traceability barcode status and binds all test results and operation logs to the product barcode, forming a complete data chain. In the event of a quality problem, the complete production history of a single product can be quickly and accurately traced, including the test data, equipment status, and time points at each step, facilitating root cause analysis. The main interface centrally displays all key information (visual displays, project list, current step, results, logs, and status), allowing operators to clearly understand the testing status, quickly grasp the equipment's operating conditions, and intervene correctly based on equipment operation prompts, reducing operational difficulty and training costs.

[0084] In some embodiments, a weakly associated architecture includes:

[0085] The interface standardization module is used to perform communication between the main system and subsystems through a unified calling protocol;

[0086] The main system has a subsystem registration and discovery module, which is used to identify and call newly added and registered subsystems;

[0087] The main system handles process scheduling, access control, and status feedback, while the subsystems execute business logic processing.

[0088] Optionally, the technologies for implementing a weakly correlated architecture in this application embodiment are as follows: (1) Clearly define the standardized interface design between the main software (main system) and the sub-software (subsystem), and achieve decoupling through a unified calling protocol. When sub-software is added, removed, or modified, there is no need to adjust the core logic of the main software. (2) Establish a sub-software registration and discovery mechanism. After a new sub-software completes registration, it can be recognized and called by the main software without reconstructing the entire system, thus improving expansion efficiency. (3) The main software only retains calling permissions and status feedback functions, while the sub-software independently undertakes business logic processing, achieving complete isolation of functional modules and reducing system maintenance costs.

[0089] In some embodiments, the system further includes a process configuration visualization module and a process verification and fault tolerance module;

[0090] The process configuration visualization module allows users to customize at least one of the following: the calling order of subsystems, the triggering conditions of subsystems, and the rules for passing parameters to subsystems;

[0091] When a subsystem or hardware board is detected to be abnormal, the process verification and fault tolerance module will either skip the abnormal steps or enable an alternative call path.

[0092] Optionally, the embodiments of this application achieve precise matching of process calls: (1) Design a process configuration visualization module to support user-defined sub-software call order, trigger conditions and parameter passing rules to adapt to different detection scenario requirements. (2) The name mapping between the board and the control method adopts a unique identifier binding mechanism to avoid name conflicts and ensure accurate response of the main software call instructions. (3) Add process verification and fault tolerance logic. When a sub-software or board is abnormal, the system automatically skips or enables the backup call path to ensure the continuity of the detection process.

[0093] In some embodiments, the system employs a templated configuration mechanism, including:

[0094] The template supports a parameterized configuration module, which allows users to customize at least one parameter among detection accuracy, process steps, and data output format.

[0095] The template version management module is used to perform template modification, archiving, and rollback operations;

[0096] The combined call module is used to combine templates from multiple subsystems to form a composite detection scheme.

[0097] Optionally, the embodiments of this application implement flexible expansion of template configuration: (1) Templates support parameterized configuration. In addition to product name identification, core parameters such as detection accuracy, process steps, and data output format can be customized to improve reusability. (2) A template version management mechanism is established to support the modification, archiving, and rollback of templates, meeting the needs of changes in detection standards at different times. (3) Templates support combined calls. According to the needs of complex detection tasks, templates of multiple sub-softwares can be spliced ​​together to form a composite detection scheme, enhancing the scene adaptability.

[0098] In some embodiments, the subsystem has templates for cross-device compatibility, adapting to different models or manufacturers of instrumentation equipment through parameter adjustments;

[0099] The main system and subsystems adopt an online status synchronization mechanism to perform visual monitoring and feed back the operating status and detection data of the subsystems to the main system online.

[0100] The system executes processes and templates for batch import and export, and performs copying and migration of detection schemes.

[0101] Optionally, the embodiments of this application achieve cross-scenario adaptation and interaction optimization: (1) Sub-software templates support cross-device compatibility. The same template can be adapted to instruments and equipment of different models and manufacturers, reducing the software adaptation cost of multi-device testing. (2) The interaction between the main software and sub-software adopts a real-time status synchronization mechanism. The running status and testing data of the sub-software are fed back to the main software in real time, realizing visual monitoring. (3) Supports batch import and export of processes and templates, which facilitates the copying and migration of testing schemes and improves the deployment efficiency of multi-workstations and multi-laboratories.

[0102] In some embodiments, the main system further includes a product production record interface, an equipment information interface, and a permission setting interface;

[0103] The product production record interface is used to record the testing time of the manufactured product, the corresponding barcode of the product, the test results and data content;

[0104] The device information interface is used to display the status of devices connected to the main system;

[0105] The permission settings interface is used to define user permissions.

[0106] Optionally, embodiments of this application construct a data traceability chain through a product production record interface, an equipment information interface, and a permission setting interface, which can greatly shorten the root cause analysis time for quality problems. When the testing process is interrupted due to hardware problems, engineers can quickly locate the source of the fault through the anomaly records in the interface. The log will clearly record which device, when, and what error was reported. Any modification to critical operations (such as formula changes or password resets) can be traced back to the specific person responsible.

[0107] In some embodiments, the category of subsystems includes an instrument vision inspection subsystem;

[0108] The instrument vision inspection subsystem is used to recognize patterns and characters on the instrument interface, detect dissimilar colors, judge light leakage on the side of the instrument, and cancel or enable it according to the task.

[0109] The instrument vision inspection subsystem includes a vision camera parameter setting interface, a vision inspection tool addition interface, a product vision inspection template interface, and a product vision template management list.

[0110] Optionally, by integrating various specialized tools (character recognition, graphic matching, Blob, brightness, RGB color, size measurement), the instrument inspection system can meet the visual requirements of instrument inspection, ranging from functionality (whether the numbers are correct) to appearance (whether there are defects, whether the colors are correct).

[0111] In some embodiments, the category of subsystems includes a hardware configuration subsystem;

[0112] The hardware configuration subsystem is used for unified management of testing hardware and provides a standardized control interface;

[0113] The hardware configuration subsystem includes a hardware communication configuration interface, a hardware function setting interface, and a hardware software permission interface.

[0114] Optionally, in this embodiment of the application, through a hardware communication configuration interface, the system centralizes the drivers (DLLs) and connection parameters (IP, serial port) of hardware (such as power supplies, I / O cards, and multimeters) from different brands and with different protocols on a single platform for management. When adding or replacing hardware, there is no need to modify the main software code; simply install the corresponding DLL and configure the connection on this interface. This subsystem establishes a standardized interface layer between the hardware and the upper-layer application. When a piece of hardware malfunctions and needs to be replaced, even if the brand and model are different, only the driver and parameters need to be changed in the hardware configuration subsystem; the main software and other parts do not require any modifications. The hardware software permission interface extends permission management to the hardware layer. Different levels of users can be configured to modify hardware parameters, add or delete hardware instructions, etc. For example, hardware engineers can focus on optimizing drivers and instructions in the hardware configuration subsystem, while process engineers can focus on using these encapsulated instructions to orchestrate testing processes in the main system.

[0115] In some embodiments, the subsystem category includes the instrument communication protocol subsystem;

[0116] The instrument communication protocol subsystem is used to edit the protocols and messages for data communication with the instrument, and to set up and send messages according to the user-defined product protocol recipes; the product protocol recipes include recipe name, protocol content, version and remarks;

[0117] The instrument communication protocol subsystem includes a communication settings interface and a product protocol recipe interface.

[0118] Optionally, the product protocol recipe function in this application embodiment encapsulates complex communication commands (messages) for different instruments into independent, nameable "recipes" (such as a recipe for reading pressure values ​​or a recipe for setting alarm thresholds). In the product protocol recipe, not only can what is sent be defined, but also how to parse the returned messages and extract meaningful physical values ​​(such as voltage, temperature, and status bits) from them.

[0119] In some embodiments, the category of subsystems includes a printing laser engraving subsystem;

[0120] The laser engraving subsystem is used to generate and mark product identification tags; product identification tags include barcodes or QR codes for data traceability.

[0121] The printing and laser engraving subsystem includes a printer settings interface and a laser engraving machine settings interface.

[0122] Optionally, the subsystem prints or laser-engraves a unique barcode / QR code on the qualified instrument, thus binding the previously intangible, digital inspection data (visual results, communication data, hardware measurements) to the tangible, physical product.

[0123] In some embodiments, the subsystem categories include upload and email third-party systems;

[0124] The upload and email third-party system is used to upload the information of the instrument product to the preset cloud platform, interact with the cloud server, and perform cloud activation.

[0125] Optionally, after passing inspection and labeling, the system uploads the product's unique identifier (such as UUID, serial number) and key information to a cloud platform (such as Alibaba Cloud IoT) to complete the formal registration and activation of the device. The system can be configured to automatically send email notifications to relevant personnel in the event of specific events (such as detection of seriously defective products, batch completion, or upload failure). This enables proactive management, allowing engineers and managers to be aware of production anomalies immediately and respond quickly, minimizing production losses.

[0126] This application also provides an instrument testing method, which is implemented using the instrument testing system described above. The method includes:

[0127] The test formula for the instrument under test is set through the main system;

[0128] The subsystem is invoked according to the detection formula to obtain the instrument detection results;

[0129] Determine whether the instrument's test result is qualified. If it is not qualified, terminate the process. If it is qualified, generate a product identification mark.

[0130] As an optional implementation, this application embodiment sets the test recipe of the instrument under test through the main system; the test recipe includes control method selection, mode selection, template name call and specified return results;

[0131] The instrument testing results are obtained by calling the subsystem based on the testing formula. The subsystems include the instrument visual inspection subsystem, hardware configuration subsystem, instrument communication protocol subsystem, printing and laser engraving subsystem, and third-party system for uploading and email.

[0132] Optionally, embodiments of this application can instantly change all behaviors of the same testing line by simply selecting or switching different testing recipes in the main system to adapt to the testing needs of different instrument models. Once the recipe is set, the testing process, steps, standards, and judgment logic of each instrument are consistent, eliminating human differences caused by operator skills or fatigue. The testing recipe itself is a digital process document containing testing logic, parameters, and standards. It can be saved, exported, imported, and version-managed. The recipe can be upgraded to continuously improve the testing process.

[0133] As an optional implementation, the instrument test result is determined to be qualified. If it is not qualified, the process is terminated. If it is qualified, the printing and laser engraving subsystem is called to generate a product identification mark.

[0134] Optionally, the embodiments of this application reduce the possibility of defective products being misjudged or missed and mixed with qualified products for shipment, thereby improving the quality reliability of the shipped products.

[0135] The solutions of this application embodiment will be described in detail and explained below with reference to specific application examples:

[0136] I. Overall Software Architecture:

[0137] 1.1 Purpose of Development: In industrial instrument testing scenarios, a software system integrating visual inspection, hardware control, process management, and traceability control is needed. This system aims to achieve multi-dimensional and accurate instrument testing, standardized data recording, and efficient process collaboration, meeting production quality control and management requirements and improving testing efficiency and accuracy.

[0138] 1.2 Objective: To develop comprehensive, stable, and reliable instrument testing software, covering visual inspection, hardware interaction, process control, and traceability management, providing standardized and intelligent solutions for instrument testing. This will help enterprises improve their testing quality and management level.

[0139] 1.3 Software System Architecture:

[0140] 1.3.1 The software required in this application includes one main software (main system) and five sub-software (subsystems); the main software is: Instrumentation Integrated Testing Software;

[0141] 1.3.2 The main software calls five sub-software programs through a defined pattern (inter-program fields) to achieve comprehensive control over instrument detection. The five sub-software programs are: ① Instrument visual inspection (sub-software); ② Hardware configuration (sub-software); ③ Instrument communication protocol (sub-software); ④ Printing and laser engraving system (sub-software); ⑤ Upload and email third-party system functions (sub-software).

[0142] 1.3.3 Sub-software can run independently when not called by the main software and can be configured separately.

[0143] 1.4. Overall system configuration framework as follows: Figure 1 .

[0144] 1.5. Overall software architecture as follows: Figure 2 .

[0145] 1.6 Overall Design Description of the Detection System:

[0146] 1.6.1 Modular Software and Hardware Design: Software interrelationships are weakened, with each component forming a separate functional module (sub-software). Sub-software components are independent of each other and are all run and called by the main software. Hardware components are independent of each other, supporting rapid replacement.

[0147] 1.6.2 Main Software: Control vision, hardware, communication, printing and laser engraving to realize the analog control of the instrument, visual detection of instrument feedback, and production of printed labels or laser engraved codes; installed on the industrial control computer;

[0148] 1.6.3 Hardware Configuration: Through an industrial control computer, a unified communication interface is used: LAN and 485 communication (Modbus RTU protocol) to realize software-driven control of the newly added detection hardware;

[0149] 1.6.4 Software Subsystems and Page Structure and Password Permissions: The main software and each sub-software (such as hardware configuration and vision software) have their own permission checking mechanisms. For example, a process engineer can edit a recipe in the main software, but when he tries to open the hardware configuration software to make modifications, the system will also check whether he has the corresponding permissions in that sub-software.

[0150] II. Instrument Comprehensive Testing Software:

[0151] 2.1. Instrument Integrated Testing Software Interface (hereinafter referred to as: Main Software): The main software consists of 5 parts: ① Main Interface, ② Formula Addition (Product Program, supports program export and import), ③ Product Production Record (supports data export and import), ④ Equipment Information (Abnormal Record), and ⑤ Permission Settings.

[0152] 2.2 Main Interface: (Refer to...) Figure 3 The main interface includes the following: left side: visual inspection screen, inspection item list, current inspection item (current inspection step, inspection standard); right side: operation buttons, inspection results, operation log, inspection quantity statistics, traceability barcode status (previous product printed barcode, current product printed barcode), equipment status; bottom: equipment operation prompts.

[0153] 2.3 New Recipe Interface: See Reference Figure 4 The new recipe interface includes: Create Product + Configuration / Version. Under recipes named with Product + Configuration, you can run the process step by step. The process runs with program steps as nodes. Only after one step is completed will you proceed to the next step.

[0154] 2.3.1 Added right-click functionality to the recipe interface: ① The right-click function allows inserting new control steps between previous and subsequent steps; ② Allows performing single-step online execution operations.

[0155] 2.3.2 Interface Function Description:

[0156] ① While the main software is open, other sub-software can also be opened. However, if communication interference occurs, a warning box will pop up asking whether to disconnect the main program's connection once a sub-software is opened. If the communication control execution steps are edited and the operation is executed by right-clicking, and the vision interface needs to be opened simultaneously, then both the main software and the vision software can be opened at the same time. ② Single-step looping is allowed. Setting the number of loops to 0 means no loop is needed. If the number of loops is set to 2, the step will be executed twice, and the next step will only proceed after the judgment result is OK. ③ In the detection results, you can choose whether to store the detection results. When this is selected, the result of the step will be stored. ④ In all steps, but when no loop is needed, if an abnormality is detected, the process will jump directly to the end and will not be executed again.

[0157] 2.3.3 The internal logic of adding new formulas is as follows: Figure 5 ;

[0158] Product addition: The product name + product configuration / version is used as the whole card, and the product can be added step by step within the card; Step addition: Each step can be added an unlimited number of times; The steps include: control method selection (equivalent to selecting the sub-software to be called) - mode selection (equivalent to calling the corresponding program in the sub-software) - template name call (equivalent to the label element of the recipe in the sub-program) - detection results (the main software identifies the data returned after each step of the detection is completed, and collects and summarizes the data in the form of a table).

[0159] 2.4 Product Production Records: (Reference) Figure 6 The production record interface includes: the inspection time of the produced product, the corresponding barcode, and the inspection results that need to be stored step by step. The results are collected item by item according to their content, and the two results are separated by commas. All data is stored in a single cell "Inspection Result" in the form of a string.

[0160] Data query: Supports filtering by time period; supports filtering by product name; supports filtering by product name + configuration or version information; supports filtering by product printed barcode;

[0161] Product factory code: Recorded by calling the production data from the print template. Supported printing modes: 3 modes:

[0162] When the main software is in call mode: the template software generates the barcode and records it itself. After the main software completes the execution steps, it calls the printing or laser engraving software and records and saves the barcode information of the printing or laser engraving software.

[0163] In external trigger mode: the main software does not call barcode information recording, and the code is displayed as empty when searched by time;

[0164] In remote communication trigger mode: the product's factory barcode is only in the format of year, month, day (YYYYMMDD) + 6-digit serial number, which is recorded in its own main software and transmitted to the printing and laser engraving software. The printing and laser engraving software generates a corresponding factory barcode based on the serial number, and the serial number can be used to query the product.

[0165] 2.5 Equipment Information Reference Figure 7 .

[0166] 2.6 Permission Settings:

[0167] 2.6.1 The instrument integrated testing software has four levels of access control:

[0168] ① Regular Employee Permissions: Limited to basic viewing operations; Initial password: 8888 8888; ② Operator Permissions: Has permissions for exporting and querying production data, reprinting barcodes, etc.; can change the password of regular employees; Initial password: 8888 8888; ③ Process Engineer Permissions: Has all execution permissions of operators; can also change the password of operators. Can set permissions for adding recipes and setting print content; Initial password: 8888 8888; ④ Administrator Permissions: Has all software permissions. Initial password: ABC123.

[0169] III. Hardware Configuration and Software:

[0170] 3.1 Hardware Configuration Software Architecture: This software integrates the installed hardware drivers and calls the development interfaces provided by the hardware manufacturers to control the instruments. Therefore, the interfaces must be compatible. The hardware configuration software must be able to perform function calls, parameter passing, and data reading through the development interfaces provided by the hardware board manufacturers, ensuring compatibility with interfaces from different manufacturers and preventing error reports. Drivers are configured... Figure 8 Framework Structure. Functional Requirements: A unified hardware interface call layer allows all hardware devices of the same type to use the same software call interface; driver layer differences between different hardware manufacturers are addressed by writing different DLL dynamic link libraries for different hardware manufacturers to adapt to their implementations.

[0171] 3.2 Hardware Configuration Overview: The hardware configuration software currently uniformly controls hardware categories including hardware control type and communication control type. The hardware control type includes board types such as level signal boards (requirements include 24 channels of 0-5V high and low voltage screwdrivers; 10 or more channels of instruments exceeding 5V input), power supply cards (2 channels of product power supply), voltage detection (4 channels of voltage detection), current detection (4 channels of current detection), pulse signals (4 channels of pulses), electronic loads (24 channels of electronic loads), resistance signals (2 channels of resistance), resistance measurement (1 channel), Bluetooth detection (2 channels of Bluetooth detection), WIFI detection (1 channel of WIFI detection), audio output detection (2 channels of audio detection), USB voltage and data reception detection (2 channels of USB detection), and NFC antenna detection (1 channel). The communication control type includes board types such as CAN communication (2 channels of CANFD), serial communication (1 channel of URAT, 1 channel of RS485), one-line communication (1 channel of one-line communication), and standard K-Line communication (1 channel of standard K-line). Hardware can be added via newly added DLLs.

[0172] 3.3 Hardware Configuration Software Interface: The main interface includes the following interfaces: hardware communication configuration, hardware function settings, and permission settings (settings based on this software).

[0173] 3.3.1 The hardware communication configuration interface is as follows: (Reference) Figure 9 This software interface primarily functions as a tool for adding hardware. Hardware is added via DLLs, and its IP address or serial port is configured to establish a software-level connection. Enabling the hardware determines its future use. The hardware configuration interface is paginated based on the newly added hardware card, with each page containing corresponding hardware parameter settings. Newly added hardware includes: a programmable DC power supply (N39436-150-06), a high-speed digital I / O card (NXI-4101-32), a general-purpose relay card (NXI-4200-8), a multi-channel DC voltage measurement card (NXI-6700-4), a multi-channel DC current measurement card (NXI-6701-4), a programmable multi-channel high-voltage I / O card (NXI-4102-8 / 8), a multi-channel programmable DC electronic load (N6136-100-05), a high-density programmable resistor card (NXI-5100-1.11M / 8), and a 5.5-digit multimeter.

[0174] 3.3.2 Hardware Function Settings Interface: The hardware function settings interface contains each type of hardware added in the configuration interface, with each hardware having its own independent interface. Within each hardware's independent interface, you can view and configure the general control commands for that hardware, and set the data for the parameter section of those commands.

[0175] 3.3.2.1 Example 1: Power Control Card Interface:

[0176] like Figure 10 The power control card interface allows adding or deleting: ① Control command: Input: "Output setting instruction"; ② Send instruction content: Enter the corresponding instruction: "23 01 20 00881300 00" (this is an example; the actual instruction may vary depending on the specific communication control content); ③ Return instruction: Enter the corresponding instruction; ④ Enable / Disable: Select or cancel; ⑤ Setting content: For example, if the power supply sending instruction controls the power supply voltage setting, the corresponding voltage data in the instruction should be directly entered into this space. The program will automatically convert it to the number system of the instruction and automatically generate the corresponding instruction in "Send instruction content". ⑥ 3.3.2.2 Example 2: PLC control interface as follows Figure 11 .

[0177] 3.3.3 Hardware and software permission interface:

[0178] This is primarily used to set permissions for various interface operations within the software. Permissions are divided into management levels according to version 2.5.

[0179] IV. Communication Protocol Editing Software:

[0180] 4.1 Communication Protocol Editing Software Architecture: The communication protocol software interface includes: serial communication settings (including UART), one-line communication settings, CAN communication settings, K-line communication settings, TCP / IP communication, product protocol recipes, etc.

[0181] 4.2. Communication Protocol Editing Software Interface Structure:

[0182] 4.2.1. Illustrated explanation of each communication settings interface:

[0183] refer to Figure 12 The main function of each communication settings interface is to configure the relevant parameters for communication on each port, enabling the sending of messages using that port. Therefore, this interface needs to contain various communication information. For example, if serial port communication is added, information such as port number, communication rate, and whether flow control is enabled needs to be set. For instance, the serial port communication interface should include the following content: Figure 13 The CAN communication settings interface should include the following content: Figure 14 The above content are examples and need to be changed according to actual settings, including the configured content.

[0184] 4.3 The product protocol formulation interface is structured as follows: Figure 15 Product protocol recipes are recipes that primarily use fixed communication methods to implement multiple command sets and send complete version messages. Each newly created recipe can open a pop-up interface where the message name can be set (instructions with any message name under the recipe can be directly called in the main software), the message content can be sent, and the message content can be received. For example, the CAN communication protocol requires the following settings: Figure 16 Interface format as follows Figure 17 Protocol data can be imported and exported in Excel format (table format is fixed).

[0185] V. Visual Inspection Software:

[0186] 5.1 Visual Inspection Software Architecture:

[0187] The vision software features dual-camera setup and vision inspection control capabilities. Camera 1 primarily performs pattern and character recognition and detects out-of-color points on the instrument interface; Camera 2 primarily assesses light leakage on the sides of the instrument and can be enabled or disabled depending on the task. Camera 2's overall vision inspection function is relatively limited. The necessary inspection tools include: digit recognition tools, graphic symbol identification tools, blob recognition tools, brightness recognition tools, RGB color recognition tools, and size measurement tools.

[0188] 5.2 Visual software interface:

[0189] The vision software consists of four parts: ① vision camera parameter setting interface, ② adding vision inspection tools, ③ product vision inspection templates, and ④ product vision template management list.

[0190] 5.2.1 Visual Camera Parameter Setting Interface: Primarily used for setting camera recognition for Cameras 1 and 2, selecting camera models, establishing connections, setting exposure time, adjusting gain, and other parameter settings. ① The camera has an autofocus function: It has a visual correction function, which, by identifying the location of captured features, corrects the offset direction and angle of the subsequent detection template. This avoids interference during matching detection. The correction function must be used before the visual inspection single-step process is invoked. ② It has independent camera exposure and shutter response parameter settings; these settings may vary depending on the product.

[0191] 5.2.2 Visual Inspection Tool Interface: This interface is primarily used to add new visual tools to continuously improve the functionality of the visual inspection software and enhance its inspection capabilities. Based on existing products, the required functionalities are described in section 5.1. The functional descriptions of each tool are as follows:

[0192] 5.2.2.1 Numeric character recognition tool:

[0193] ① Normal digits: The detection area can be selected using visual software to directly identify the digits, which must be recordable. ② Normal characters: Primarily English letters; similar to digits, selecting the corresponding digit allows for character detection. ③ Mapped digits: The detection area is selected, and features are identified using a contour recognition tool. The corresponding Chinese / English letters or numbers can be set. When a digit matching the feature is detected, it is interpreted as the mapped Chinese / English letters or numbers and can be recorded.

[0194] 5.2.2.2 Graphic Symbol Recognition Tool: The tool should be easy to operate. It should only require shape matching and contour matching to identify whether the graphics within the selected area are consistent. It should also include a tool for extracting image edge contours.

[0195] 5.2.2.3 Blob tool: It can detect defective spots with a diameter of 0.2mm in a single color display.

[0196] 5.2.2.4 Brightness Recognition Tool: Based on image recognition, this tool determines color and brightness values, using upper and lower limits to check if the brightness falls within a specified range; values ​​within the range are considered acceptable. Specific brightness levels can be differentiated using the discrimination capability of the I parameter in the HIS (Hypermetry Information System).

[0197] 5.2.2.5 RGB color judgment tool: It can judge the color range of the product by judging the three primary colors and judge it by the upper and lower limit thresholds.

[0198] 5.2.2.6 Dimension measurement tools: It is recommended to use circular and straight line detection tools to measure the dimensions of the graphic.

[0199] 5.2.2.7 Tool Function Introduction: ① The above tools can be used in combination, but each tool can be used individually and output results separately. Within the main software, each tool can be called independently, and the decision to proceed to the next step is based solely on the acquired results. ② Flicker Detection (can be composed of an image recognition tool and a brightness recognition tool, existing as a single, fixed tool): It must be able to identify the difference between two consecutive colors within the same selected area. The time interval between two consecutive image captures must be <200 milliseconds, and the capture duration must not exceed 100 milliseconds. The number of consecutive captures can be set; any difference detected in the number of consecutive captures is considered a difference, and a signal is output.

[0200] 5.2.3 Product visual inspection template interface: Independent process steps need to be configured according to different products;

[0201] 5.2.3.1 In each product process, the correction function must be set before other functions are set;

[0202] 5.2.3.2. In each product process, you can set up as many sample testing processes as you like, without any correlation between them;

[0203] 5.2.3.3 The template process can be named and freely called. The detection result data of the process can be set, and a single detection result (OK or NG) can be given; the result data shall not exceed 4.

[0204] 5.2.3.4. All established processes based on product names are stored as files or folders. Copying the same software between different devices is supported. Simply copy and use. Interface example: Figure 18 .

[0205] 5.2.3.5 The process for establishing a product visual inspection template is as follows: ① Open the visual inspection tool and take a picture of a template. ② After the template is established, the first tool will always be the "Positioning Correction" tool to correct the features. If parameters such as "Offset Angle" and "X Offset Distance" are not set, there will be no correction. ③ After positioning correction, any tool can be selected. When each tool is activated, there will be a rectangular box with a "Detection Range" to constrain the detection range, i.e., the search and judgment will be performed within this range. ④ After the detection range is determined, all tools can use polygonal or rectangular boxes to select on the visual inspection image. Then, the relevant settings for the corresponding tools are made. For example, for number detection, the specific content of the number is identified. Except for number, color, and brightness detection, the result output is a numerical value, and other detections are OK / NG. ⑤ Except for the positioning template, which is a fixed first row required option, other templates can be selected arbitrarily and are not related to each other. After all the detections are set, a specific file is formed for the main file to call. The main file is called by the template name, and any template can be selected individually to obtain the results separately. In visual inspection software templates, the inspection results of each template do not determine whether the next template will be run.

[0206] VI. Printing and Laser Engraving Settings Software:

[0207] 6.1 Introduction to the Printing and Laser Engraving Settings Software: The printing and laser engraving settings software consists of two parts: printer label settings and control, and laser engraving settings and control. This software can operate in three control modes: ① Main software invocation for printing or laser engraving; ② As standalone software, controlled by external trigger signals for printing or laser engraving; ③ Remote invocation via Ethernet for printing or laser engraving.

[0208] 6.2 Printing Laser Engraving Settings Software Interface: The printing laser engraving software consists of two interfaces: printer settings interface and laser engraving machine settings interface; located at the top of the software; each interface has four sub-interfaces: parameter settings, product template creation, print template management, and print records.

[0209] 6.2.1 Printer Category Settings Interface:

[0210] 6.2.1.1 Printing Parameter Settings: Used for printer connection and related parameter settings to achieve stable control of label printing. Print page and working area are adjustable. Font is customizable. Print preview function is included. Label template printing paper length and width are adjustable.

[0211] 6.2.1.2 Creating Product Printing Templates: Different printing templates can be set independently for different products.

[0212] 6.2.1.3 Print Template Management List: All product templates can be managed uniformly, and can be exported and imported.

[0213] 6.2.1.4 Printing Records: All data related to printing can be recorded, and the records include the time and printing trigger type (manual trigger, automatic device trigger, reprint), forming a record.

[0214] 6.2.2 Laser Engraving Category Settings Interface:

[0215] 6.2.2.1 Laser engraving parameter settings: Used for connecting the laser engraving machine and setting related parameters.

[0216] 6.2.2.2 Creating a new product laser engraving template: Different laser engraving templates can be set independently according to different products.

[0217] 6.2.2.3 Laser Engraving Template Management List: All product templates can be managed uniformly, and import and export operations are possible.

[0218] 6.2.2.4 Laser Engraving Records: All data triggered by the software for laser engraving is recorded, including the time and the type of laser engraving trigger (manual trigger, automatic device trigger, re-engraving).

[0219] Example interface: Printing parameter settings interface as shown Figure 19 The product printing template creation interface is as follows: Figure 20 .

[0220] 6.3 Requirements for printing laser engraving templates:

[0221] 6.3.1 Coding rules: Item number + vehicle model + type + time (YYMMDD) + production batch number (0001).

[0222] ① The label template allows users to set characters, numbers, serial numbers, dates, insert graphics, and barcodes / QR codes to create templates. After creating a template, it can be printed according to its own rules, and the position can be freely set. ② Numbers have customizable mapping rules, such as converting 32-bit numbers to two numbers and letters, or using octal numbers. According to the mapping rules, the number can increment automatically based on changes in the serial number or time, or remain fixed. ③ The code system is selectable (QR codes can be DataMatrix or QR codes). ④ Implementable encoding rules include: product part number (changes according to product), product certification number (changes according to product), supplier code and qualification stamp (fixed numbers and text), and batch number (used for accurate traceability; production date and serial number are automatically updated; production line code needs to be set in advance).

[0223] 6.3.2 Coding Specifications:

[0224] ① Defective products are not allowed to be barcoded; products that pass all inspection processes and are deemed qualified must have barcodes printed. Production data is linked to the label serial number (the main software records this). ② Printed data has storage capabilities; if power is interrupted before printing, the current state is automatically saved. Once printed, regardless of whether the printer is feeding paper, labels with the same serial number will not be printed again. This ensures that printed labels are not duplicated. ③ Printing tests and parameter modifications require a password. ④ After the label editing software is set up, it can be triggered by the traceability software to print factory labels. The date and time in the barcode content changes with the system time, and the serial number automatically increments with each print, resetting to zero at midnight every day. ⑤ The software must ensure single-task capability. The traceability software can monitor the software's operation status. The software is not allowed to crash or freeze due to its own malfunctions. Defective printing software does not affect the normal operation of the traceability software. Printing software operation records are searchable.

[0225] VII. Third-party system software for uploading and email:

[0226] 7.1 Upload and Email Third-Party System Process: This sub-software is mainly used to upload the instrument product's ID number to Alibaba Cloud and activate it through a third-party website. The process is as follows: Figure 21 Detailed procedures are as follows: Figure 22 .

[0227] 7.2 Instructions for UUID and UDS read / write upload:

[0228] 7.2.1 Compatibility notes for UUID and UDS write and read operations:

[0229] 1) In 2022, the applicable products differ in three aspects: number of bytes, bytes, and data type;

[0230] The differences in the bytes are as follows: ① Part number, 12 bytes; ② Supplier, 10 bytes; ③ ECU name, 10 bytes; ④ Hardware version number, 8 bytes; ⑤ Software version number, 8 bytes.

[0231] ECU serial number: occupies 14 bytes; and the data type of each byte is HEX (Unsigned);

[0232] 2) Applicable products: FA80-12, EB80. The differences lie in the number of bytes, bytes, and data type.

[0233] The differences in the bytes are as follows: ① Part number, 20 bytes; ② Supplier, 10 bytes; ③ ECU name, 6 bytes; ④ Hardware version number, 10 bytes; ⑤ Software version number, 10 bytes.

[0234] ECU serial number: occupies 14 bytes; and the data type of each byte is HEX (Unsigned);

[0235] 3) Applicable products: 6AQ1 / 6KMS / 6KW7 series. The differences lie in the number of bytes, bytes, and data type.

[0236] The differences in the bytes are as follows: ① Part number, 20 bytes; ② Supplier, 10 bytes; ③ ECU name, 6 bytes; ④ Hardware version number, 10 bytes; ⑤ Software version number, 10 bytes.

[0237] ECU serial number: occupies 10 bytes; and the data type of each byte is BCD.

[0238] 7.2.2 Interface Description for Registering Devices and Obtaining Device Information on the Alibaba Cloud IoT Platform:

[0239] Send an HTTPS / HTTP GET or POST request to the API's server address, and add the corresponding request parameters to the request according to the API interface documentation to call the API.

[0240] Return values ​​are uniformly in JSON format, and the data transmission encoding format used in the request and response process is UTF-8.

[0241] When calling an API, in addition to the API-specific request parameters, you also need to pass common request parameters: 1) Request parameter reference Figure 23 2) Return parameter reference Figure 24 3) Common API request parameters and common return parameters: 3.1) Reference for common request parameters Figure 25 3.2) Common Return Parameter Reference Figure 26 The API returns results in a unified format: a 2xx HTTP status code indicates a successful call; a 4xx or 5xx HTTP status code indicates a failed call. 4) Signature Mechanism: When signing, AccessKeyID and AccessKey Secret (provided offline by us) are required to generate a signature verification code (MAC). AccessKeyID identifies the visitor; AccessKey Secret is the key used to encrypt the signature string and for server-side verification of the signature string; this information is kept confidential.

[0242] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0243] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0244] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0245] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0246] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0247] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0248] The instrument testing methods, systems, electronic devices, storage media, and program products provided in this application provide a flexible process definition environment through recipe addition interfaces and modular subsystems.

[0249] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. An instrument testing system, characterized in that, The instrument testing system includes a main system and several subsystems; The main system is used to call the subsystems and control instrument detection; the main system includes a main interface and a recipe addition interface. The main interface is used to display instrument detection information and prompt equipment operation information; The main interface includes a visual inspection screen, a list of inspection items, the current inspection item, operation buttons, inspection results, operation logs, inspection quantity statistics, traceability barcode status, device status, and device operation prompts; The formula addition interface is used to perform instrument testing on user-defined test formulas; the formula addition interface includes new product, new configuration, control method, mode selection, template name, test result, interval time, number of cycles, and single-step execution button; The subsystem is used to provide operating data and receive instructions from the main system; The main system and the subsystems adopt a weakly correlated architecture; The weakly associated architecture includes: An interface standardization module is used to perform communication between the main system and the subsystem through a unified calling protocol; The main system has a subsystem registration and discovery module, which is used to identify and call newly added and registered subsystems; The main system performs process scheduling, access control, and status feedback, while the subsystems perform business logic processing. The system adopts a template-based configuration mechanism, including: The template supports a parameterized configuration module, which allows users to customize at least one parameter among detection accuracy, process steps, and data output format. The template version management module is used to perform template modification, archiving, and rollback operations; The combined invocation module is used to combine templates from multiple subsystems to form a composite detection scheme; The name mapping between the board and the control method adopts a unique identifier binding mechanism; The template version management module executes the testing standard change requirements at different times; The combined invocation module combines templates from multiple subsystems to form a composite detection scheme according to the requirements of the detection task. The subsystem has a template.

2. The instrument testing system according to claim 1, characterized in that, The system also includes a process configuration visualization module and a process verification and fault tolerance module; The process configuration visualization module is used for users to customize at least one of the following: the calling order of subsystems, the triggering conditions of subsystems, and the parameter rules passed to subsystems; When the process verification and fault tolerance module detects an abnormality in a subsystem or hardware board, it performs operations to skip the abnormal steps or enable an alternative call path.

3. The instrument testing system according to claim 1, characterized in that, The subsystem has templates for cross-device compatibility, allowing it to be adapted to different models or manufacturers of instruments and equipment through parameter adjustments; The main system and the subsystems adopt an online status synchronization mechanism to perform visual monitoring and feed back the operating status and detection data of the subsystems to the main system online. The subsystem performs batch import and export of templates and copies and migrates detection schemes.

4. The instrument testing system according to claim 1, characterized in that, The main system also includes a product production record interface, an equipment information interface, and a permission setting interface; The product production record interface is used to record the testing time of the produced product, the corresponding barcode of the product, the test results and data content; The device information interface is used to display the status of devices connected to the main system; The permission settings interface is used to define user permissions.

5. The instrument testing system according to claim 1, characterized in that, The category of the subsystems includes the instrument vision inspection subsystem; The instrument visual inspection subsystem is used to recognize patterns and characters on the instrument interface, detect dissimilar colors, judge light leakage on the side of the instrument, and cancel or enable it according to the task. The instrument vision inspection subsystem includes a vision camera parameter setting interface, a vision inspection tool addition interface, a product vision inspection template interface, and a product vision template management list.

6. The instrument testing system according to claim 1, characterized in that, The categories of the subsystems include hardware configuration subsystems; The hardware configuration subsystem is used to uniformly manage the testing hardware and provides a standardized control interface; The hardware configuration subsystem includes a hardware communication configuration interface, a hardware function setting interface, and a hardware software permission interface.

7. The instrument testing system according to claim 1, characterized in that, The subsystem category includes the instrument communication protocol subsystem; The instrument communication protocol subsystem is used to edit the protocol and messages for data communication with the instrument, and to set up and send messages according to the user-defined product protocol formula; The product protocol formula includes the formula name, protocol content, version, and remarks; The instrument communication protocol subsystem includes a communication settings interface and a product protocol formula interface.

8. An instrument testing method, implemented using the instrument testing system as described in any one of claims 1 to 7, characterized in that, The method includes: The test formula for the instrument under test is set through the main system; The subsystem is invoked according to the detection formula to obtain the instrument detection results; Determine whether the instrument's test result is qualified. If it is not qualified, terminate the process. If it is qualified, generate a product identification mark.

Citation Information

Patent Citations

  • Automobile instrument networked testing system and testing method thereof

    CN103017812A

  • Method and device for generating vehicle-mounted instrument function test case script

    CN119829455A