Equipment function adaptation method and system based on configuration data, equipment and medium

Abstract

The invention discloses an equipment function adaptation method and system based on configuration data, equipment and a medium, and relates to the technical field of equipment debugging and adaptation. Static and dynamic configuration data of newly-added equipment are constructed, and a configuration file is generated; importing the configuration file into a debugging system to establish association mapping; searching a new device through a bus or an MAC address protocol, and matching a configuration file based on a device identity identifier; analyzing the file to extract a static attribute and a dynamic instruction, and generating a function logic and a communication format which can be identified by a debugging system; the debugging system automatically adapts to data read-write and control functions and generates an interactive interface; according to the method, bottom layer codes do not need to be modified, the adaptation efficiency of newly-added equipment and the expansibility of a debugging system are improved, and the research and development cost and the operation complexity are reduced.

Description

Technical Field

[0001] This application relates to the field of equipment debugging and adaptation technology, and in particular to a method, system, device and medium for device function adaptation based on configuration data. Background Technology

[0002] In the research and development and debugging of intelligent control devices, such as intelligent relay modules and sensor modules, the adaptation efficiency of the debugging system to new devices directly affects the device's time-to-market and R&D costs. Currently, the industry generally adopts a one-device-one-development adaptation model, which means that for each new device or function launched, the R&D team needs to modify the underlying code of the debugging system specifically, including the new device identification logic, adapting data read and write instructions, and developing a dedicated debugging interface. This model has significant drawbacks. On the one hand, repetitive code development work consumes a lot of manpower and time, resulting in a long adaptation cycle for new devices, low R&D efficiency, and difficulty in meeting the market's rapid iteration needs. On the other hand, frequent code modifications can easily introduce logical vulnerabilities and compatibility issues, increase the difficulty of software testing and maintenance, and reduce the stability and reliability of the debugging process.

[0003] Meanwhile, the adaptation of traditional debugging systems and equipment relies on hard-coded associations, lacking unified configuration standards and data interaction specifications. The basic attributes of different equipment models, such as equipment type, number of loops, and parameter operation rules, such as read and write commands and data formats, cannot be standardized and recognized by the debugging system. This not only leads to poor scalability of the debugging system and difficulty in quickly adapting to multiple types and specifications of newly added equipment, but also increases the operational complexity for engineers, who need to learn differentiated debugging processes for different equipment. As the categories of intelligent control equipment become increasingly rich and their functions are constantly iterated, the efficiency bottleneck and cost pressure of the traditional adaptation mode become more and more prominent. There is an urgent need for a solution that can quickly adapt to new equipment without modifying the underlying code and through standardized configuration. Summary of the Invention

[0004] This application provides a device function adaptation method, system, device, and medium based on configuration data to simplify the adaptation process for new devices, improve R&D and debugging efficiency, enhance the scalability and compatibility of the debugging system, and is suitable for rapid adaptation of various intelligent control devices.

[0005] In a first aspect, embodiments of this application provide a device function adaptation method based on configuration data, comprising the following steps: Build configuration data for the newly added device, and generate a configuration file based on the configuration data; Import the configuration file into the debugging system and establish an association mapping between the configuration data and the debugging system; The newly added device is searched using a preset communication protocol to obtain its identity identifier, and the configuration file is matched based on the identity identifier. The configuration file matched by the identity identifier is parsed, and the static attribute information and dynamic operation instructions of the configuration data of the newly added device are extracted. Based on the static attribute information and the dynamic operation instructions, the functional logic and communication format recognized by the debugging system are generated. Based on the functional logic and the communication format, the configuration data reading, modification and control functions of the newly added device are adapted, and a debugging interactive interface is generated; In response to operations on the debugging interface, the system records the use of configuration data and exception information during the debugging process, and iteratively optimizes the data definition and instruction mapping relationship of the configuration file. Based on the optimized configuration file, the adaptation and debugging of the newly added device functions are completed.

[0006] Furthermore, the configuration data includes static configuration data and dynamic configuration data, wherein the static configuration data represents the static attribute information of the newly added device, and the dynamic configuration data represents the dynamic operation instructions of the newly added device; The static configuration data includes device type identifier, device model, product name, number of circuits, and inherent hardware parameters. The static configuration data is a read-only attribute used to define the basic functions and basic information of the newly added device. The dynamic configuration data includes data read / write identifiers, data types, function descriptions, read instruction configurations, write instruction configurations, and data constraint rules, which are used to define the read / write logic and communication interaction specifications of the newly added device data.

[0007] Furthermore, the read instruction configuration includes a read opcode, a data length to be sent, a data index, and a response opcode; The write instruction configuration includes the write opcode, the data length to be sent, the data index, additional fixed data, and the response opcode. The data constraint rules include the range of data values, data length limits, and dependencies between related data.

[0008] Further, the newly added device is searched using a preset communication protocol to obtain its identity identifier, and the configuration file is matched based on the identity identifier, including: Send search commands to the newly added device via bus protocol or MAC address search protocol; Receive the response data from the newly added device, and extract the device type identifier and device model of the newly added device as the device identity identifier; Based on the device identity identifier, a matching process is performed in the configuration file that has been imported into the debugging system to establish a communication link for the newly added device.

[0009] Further, the step of parsing the configuration file matched by the identity identifier, extracting the static attribute information and dynamic operation instructions of the configuration data of the newly added device, and generating the functional logic and communication format recognized by the debugging system based on the static attribute information and the dynamic operation instructions includes: Extract the basic device information from the static configuration data and use the basic device information as the display data source for the debugging interaction interface; Parse the dynamic operation instructions in the dynamic configuration data, and generate the data read / write execution logic and communication instruction format of the debugging system based on the dynamic operation instructions; The basic equipment information is associated with the dynamic operation instructions to form the functional logic that the debugging system directly executes.

[0010] Furthermore, the adaptation of the configuration data reading, modification, and control functions of the newly added device based on the functional logic and the communication format includes: According to the parsed read instruction configuration, a data read request is sent to the newly added device, and the response data of the newly added device is received and parsed. According to the parsed write instruction configuration, the modified data is encapsulated and sent to the newly added device, and the configuration result response from the newly added device is received, wherein the communication format is adapted to the communication protocol of the newly added device.

[0011] Furthermore, the process of recording the use of configuration data and exception information during debugging, and iteratively optimizing the data definition and instruction mapping relationship of the configuration file, includes: Statistical data include read / write frequency, command execution success rate, data parsing anomaly types, and communication timeouts. Based on the statistical data, optimize the data index definition, instruction mapping relationship, and data constraint rules in the configuration file; Verify the adaptation effect of the optimized configuration file to form a configuration iteration.

[0012] In a second aspect, embodiments of this application provide a device function adaptation system based on configuration data, including: A configuration building module is used to build configuration data for newly added devices and generate configuration files based on the configuration data; The configuration import module is used to import the configuration file into the debugging system and establish an association mapping between the configuration data and the debugging system. The device search module is used to search for the newly added device through a preset communication protocol, obtain the identity identifier of the newly added device, and match the configuration file based on the identity identifier; The configuration parsing module is used to parse the configuration file matched by the identity identifier, extract the static attribute information and dynamic operation instructions of the configuration data of the newly added device, and generate the functional logic and communication format recognized by the debugging system based on the static attribute information and the dynamic operation instructions. The function adaptation module is used to adapt the configuration data reading, modification and control functions of the newly added device based on the functional logic and the communication format, and generate a debugging interactive interface; The configuration optimization module is used to respond to operations on the debugging interface, record the configuration data usage and exception information during the debugging process, and iteratively optimize the data definition and instruction mapping relationship of the configuration file. The debugging and optimization module is used to adapt and debug the newly added device functions based on the optimized configuration file.

[0013] In a third aspect, embodiments of this application provide an electronic device, including: a memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the device function adaptation method based on configuration data as described in the first aspect.

[0014] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform the device function adaptation method based on configuration data as described in the first aspect.

[0015] This application's embodiments break down new device attributes and operation rules into static and dynamic configuration data, forming standardized configuration files. This allows for the establishment of associated mappings without modifying the underlying code of the debugging system, solving the inefficiency problem caused by the traditional "one device, one development" approach and shortening the adaptation cycle for new devices. By searching for new devices through bus protocols or MAC address protocols and accurately matching configuration files based on their identity, combined with a configuration parsing module to extract static attributes and dynamic instructions, the system generates functional logic and communication formats that the debugging system can directly execute. This enables the debugging system to automatically adapt to the data reading, writing, modification, and control functions of new devices, while automatically generating a debugging interface, reducing the operational complexity for engineers and improving debugging convenience. Furthermore, the design of a configuration optimization module records information such as data reading and writing frequency and instruction execution success rate during the debugging process, iteratively optimizing the data definition and instruction mapping relationship of the configuration file, continuously improving adaptation stability and reliability, enhancing the scalability and compatibility of the debugging system, and enabling it to flexibly adapt to multiple types and specifications of new devices, reducing R&D and maintenance costs, and meeting the needs of rapid market iteration. Attached Figure Description

[0016] Figure 1 This is a flowchart of a device function adaptation method based on configuration data provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the process of adding a new device search in a device function adaptation method based on configuration data, as provided in an embodiment of this application. Figure 3 This is a flowchart illustrating the configuration parsing process of a device function adaptation method based on configuration data, provided in an embodiment of this application. Figure 4 This is a flowchart illustrating the configuration optimization of a device function adaptation method based on configuration data, as provided in an embodiment of this application. Figure 5 This is a flowchart illustrating the bus protocol usage of a device function adaptation method based on configuration data, provided in an embodiment of this application. Figure 6 This is a structural diagram of a device function adaptation system based on configuration data provided in an embodiment of this application; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship. This embodiment takes the standardized configuration of a 16-channel 10A intelligent relay module (HDL-MR1610.433) as an example to demonstrate how the device functions can be supported through configuration. The following is a detailed explanation of the overall architecture, module details, and function mapping.

[0019] Figure 1 This is a flowchart illustrating a device function adaptation method based on configuration data provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The process of this application includes configuration building, configuration import, device search, configuration parsing, function adaptation, configuration optimization, and debugging completion, forming a closed loop of configuration, adaptation, and optimization, specifically including: Step 101: Construct configuration data for the newly added device and generate a configuration file based on the configuration data.

[0020] In one embodiment, configuration data for the newly added device is constructed, and a configuration file is generated based on the configuration data. The configuration data includes static configuration data and dynamic configuration data, which together define the basic information and interaction rules of the newly added device, ensuring that the debugging system can fully identify the device characteristics without the need to develop additional adaptation code.

[0021] Static configuration data represents the static attribute information of newly added devices. It is a read-only attribute (R) used to define the basic functions and basic information of the newly added devices. Once determined, it cannot be modified. It includes device type identifier (product unique identifier, such as 451), device model (such as HDL-MR1610.433), product name (Chinese name such as 16-channel 10A intelligent relay module, English name such as 16CH 10A High Power Switch Actuator, number of circuits (such as 16 channels), and inherent hardware parameters (such as rated current 10A, communication baud rate 9600bps, operating voltage DC24V, communication protocol type Bus). These data are inherent attributes of the device and are used by the commissioning system to identify the device identity and basic capabilities to ensure that the device is accurately matched. Dynamic configuration data represents the dynamic operation instructions of newly added devices. It is used to define the read and write logic and communication interaction specifications of newly added device data, and supports the debugging system to configure parameters and read status of devices, including data read and write identifiers, such as RW for readable and writable and R for read-only; data types, such as String / Byte / Integer / Long / Float / Bit; function descriptions, such as device notes; loop parameter settings and switch status control; read instruction configuration; write instruction configuration; and data constraint rules, such as data value range, data length limit, and related data dependencies.

[0022] The static and dynamic configuration data mentioned above are organized into a configuration file in JSON format. The file name adopts the format of device type identifier-device model.json, such as 451-HDL-MR1610.433.json, which facilitates quick identification and matching by the debugging system. The configuration file must contain complete field definitions to ensure that there are no missing fields.

[0023] Step 102: Import the configuration file into the debugging system and establish an association mapping between the configuration data and the debugging system.

[0024] In one embodiment, the configuration file is imported into the debugging system, establishing a mapping between the configuration data and the debugging system. The debugging system provides a visual configuration import interface, supporting both single-file import and batch import modes to meet the needs of different adaptation scenarios. For single-file import, engineers select a local configuration file via the file selection button. The system automatically parses the JSON structure and verifies data integrity, such as checking the existence and format of required fields, and verifying that the command code is hexadecimal and the data length is a non-negative integer. If the verification is successful, the configuration file is stored in the system's specified directory, and the configuration index (hash table structure) is updated. If the verification fails, an error message window pops up, listing specific error items, such as a missing deviceModel field or an incorrect format of the cmd field (it should be a hexadecimal string), to facilitate engineer correction.

[0025] For batch import, engineers select a folder containing multiple configuration files. The system iterates through all .json files in the folder, parses and verifies them in batches, and generates an import report (including the number of successfully imported files, the names of failed files, and the reasons). Successfully imported configuration files are stored and the index is updated according to the same rules, while failed files do not affect the import of other files. The system associates static configuration data with the interface display module, and dynamic configuration data with the data read / write module and the communication module. The association relationship is stored in the configuration mapping table for other modules to call. The system provides configuration file management functionality, allowing users to view a list of imported configuration files (including device type identifier, device model, import time, and version number), and to delete, update (re-import and overwrite), and export configuration files for easy maintenance. Step 103: Search for the newly added device through a preset communication protocol, obtain the identity identifier of the newly added device, and match the configuration file based on the identity identifier.

[0026] In one embodiment, a new device is searched for using a preset communication protocol to obtain its identity identifier. A configuration file is then matched based on the identity identifier. The specific process is as follows: Figure 2 The following are included: In the device search interface of the debugging system, engineers can select the appropriate preset communication protocol—bus protocol or MAC address search protocol—through the drop-down menu. The system has built-in communication logic for both protocols, requiring no additional plugins. If the bus protocol is selected, a 0x000E search command is sent; if the MAC address search protocol is selected, a 0xF003 search command is sent. The search command includes the system identifier, such as DebugSystemV2.0, communication parameters (baud rate 9600bps, data bits 8 bits, stop bits 1 bit, parity none), and the search range, such as subnet number range 0-255 and device number range 0-255, ensuring that newly added devices can be accurately identified and responded to. After receiving the search command, the newly added device replies with data according to its own communication protocol specifications. The reply data is encapsulated in a fixed format and includes an operation code, such as 0x000F for bus protocol response and 0xF004 for MAC address protocol response, source device subnet number, device number, device type identifier, device model, device version, and additional data, such as device firmware version. The data is transmitted in hexadecimal encoding to ensure transmission stability.

[0027] The debugging system parses the response data and extracts the device type identifier and device model as device identification. For example, it parses deviceType=451 and deviceModel=HDL-MR1610.433 from the response data. These two fields are the basis for matching configuration files, ensuring that the corresponding configuration file can be accurately located and avoiding confusion. The system uses the extracted device identity identifier (451-HDL-MR1610.433) as a key to perform an exact match in the configuration index. If a corresponding record exists in the index, the system retrieves the configuration file path and loads the configuration file. If no matching record is found, the system displays a prompt window indicating that no configuration file corresponding to device type identifier 451-device model HDL-MR1610.433 was found. The system requests that the configuration file be imported and then retried, and provides an "Import Now" button to guide engineers in importing the appropriate configuration file.

[0028] After a successful match, the system reads communication parameters from the configuration file, such as baud rate 9600bps and protocol type Bus, and automatically establishes a stable communication link with the newly added device, completing the communication handshake (sending handshake command 0x0001, the device replies with 0x0002 to indicate a successful handshake); if the handshake fails, the system retryes 3 times. If it still fails, it will prompt that the communication link establishment has failed and ask you to check the device connection and communication parameters. Step 104: Parse the configuration file matched by the identity identifier, extract the static attribute information and dynamic operation instructions of the configuration data of the newly added device, and generate the functional logic and communication format recognized by the debugging system based on the static attribute information and the dynamic operation instructions. In one embodiment, the configuration file matched by the identity is parsed to extract the static attribute information and dynamic operation instructions of the newly added device. Based on these two, the functional logic and communication format for the debugging system are generated. The specific process is as follows: Figure 3 The following are included: The system parses the "base" field in the configuration file to extract basic device information, including device model, Chinese name, English name, number of loops, and hardware parameters (rated current, operating voltage, baud rate). This information is used as the data source for the debugging interface. The system automatically categorizes and organizes this information. For example, the device basic information section displays the device model, Chinese / English name, and hardware parameters; the loop information section displays the total number of loops, reserving 16 debugging entry points for each loop, eliminating the need for manual interface layout.

[0029] The `device` and `loops` fields in the configuration file are parsed to extract dynamic operation commands for each function. This generates the data read / write execution logic and communication command format for the debugging system. When parsing the read command, the `cmd` (read opcode), `len` (send data length), `ackCmd` (response opcode), and `ackData` (response data parsing rules) in the `read` field are extracted to generate the read execution logic for sending read commands, receiving response data, parsing data according to `ackData`, and converting it to a readable format. In terms of communication format, a standard communication frame format is generated based on the configured communication parameters (baud rate, data bits, etc.) and the command code format (hexadecimal).

[0030] During write command parsing, the `cmd` (write opcode), `len` (send data length), `data` (data encapsulation rules), `extra` (extra fixed data), and `ackCmd` (response opcode) of the `write` field are extracted to generate write execution logic that receives user input, validates according to constraint rules, encapsulates data (including extra fixed data), sends write commands, receives feedback results, and determines whether the write was successful. Regarding communication format, a communication frame containing extra fixed data is generated. During data constraint logic parsing, the data value range and data length limits of the `constraintRules` field are extracted to generate data validation logic, such as ensuring that string data length does not exceed 20 bytes and bit data values ​​are only 0 or 1, to ensure that user input data meets device requirements. The extracted basic equipment information is associated with the generated execution logic and communication format to form functional logic that the debugging system can directly execute. For example, the loop 1 remark reading function is associated with the loop 1 remark debugging entry in the loop information section. When this entry is clicked, the system automatically executes the logic of sending the F00E command, receiving the F00F response, parsing the 20 bytes of data starting from index 1, converting it into a string, and displaying it. The loop 1 switch control function is associated with the loop 1 switch status control button. When the open button is clicked, the system executes the logic of verifying the data (0-off, 1-on), encapsulating the data (loop number 1 + status 1), sending the F022 command, receiving the F023 response, and updating the switch status display. Step 105: Based on the functional logic and the communication format, adapt the configuration data reading, modification and control functions of the newly added device, and generate a debugging interactive interface.

[0031] In one embodiment, according to the parsed read instruction configuration, a data read request is sent to the newly added device. For example, when reading the device notes, the system generates a communication frame containing the 0x000E operation code according to the communication format and sends it to the device through the established communication link; the system receives the response data (containing the 0x000F operation code) from the device, parses the data according to the index (0) and length (20) defined by ackData, and converts the hexadecimal data into a string format, such as the living room lighting control host, which is displayed in the device notes input box of the debugging interface.

[0032] According to the parsed write command configuration, the modified data entered by the user is validated according to the data constraint rules. For example, if the user changes the device remark to "conference room relay control module", the system verifies the length (18 bytes ≤ 20 bytes, which meets the requirements). After the verification is successful, the data is encapsulated (starting from index 0, length 20 bytes, padding with 0x20 if insufficient), generating a communication frame containing the 0x192E operation code, and sending it to the newly added device. The system receives the configuration result response from the device (containing the 0x192F operation code), determines that the write is successful, and displays a success message on the interface. If other operation codes are returned or there is no response after timeout, the system displays a failure message and asks the user to retry.

[0033] For control commands of the device, such as relay switch control, the system implements command sending and status feedback according to the logic defined by the dynamically configured data. For example, when the switch of control loop 1 is turned on, the user clicks the turn button, the system verifies the data (status 1 meets the value range), encapsulates the data (additional fixed data loop number 1 + status 1), generates a communication frame containing the 0xF022 operation code, and sends it to the device; it receives the 0xF023 response code from the device, updates the switch status on the interface to turn on, and displays that the control is successful.

[0034] The system automatically generates a standardized debugging interface with a modular layout, comprising three sections: the basic equipment information section displays static information such as equipment model, Chinese name, English name, rated current, operating voltage, baud rate, and communication protocol type, which is not editable; the parameter configuration section displays a device remarks input box and read / save buttons based on the dynamic configuration of the device module; and the loop control section displays independent configuration areas for 16 loops based on the dynamic configuration of the loops module. Each area includes a loop remarks input box, a switch status control button (on / off), and buttons for reading and saving parameters. The interface layout is unified, and the operation logic is consistent, requiring no additional development.

[0035] Step 106: In response to the operation of the debugging interface, record the configuration data usage and exception information during the debugging process, and iteratively optimize the data definition and instruction mapping relationship of the configuration file.

[0036] In one embodiment, in response to operations on the debugging interface, configuration data usage and exception information during debugging are recorded, and the data definition and instruction mapping relationship of the configuration file are iteratively optimized. The specific process is as follows: Figure 4 The following are included: The system records key information during the debugging process in real time, forming a debugging log. Information includes the read / write frequency of each parameter, such as reading device notes 3 times, writing loop 1 notes 2 times, controlling loop 1 switch 5 times, operation time points, and operation duration (time from clicking the button to displaying the result). Abnormal information includes the number of command execution failures, such as failing to write to loop 2 notes once, data parsing anomaly types (data length mismatch 2 times, format error 1 time, value exceeding limit 3 times), communication timeouts (no response received after sending a read command 2 times), the operational scenario in which the anomaly occurred, such as data length mismatch when reading loop 3 notes, value exceeding limit when writing to loop 5 notes, and communication frame data at the time of the anomaly (for troubleshooting). The system performs statistical analysis on the collected information, generates statistical reports, calculates key indicators, and calculates the command execution success rate by function. For example, if all three attempts to read the device remarks are successful, the success rate is 100%; if only one of the two attempts to write the remarks to loop 2 is successful, the success rate is 50%. The system also calculates the percentage of each type of anomaly out of the total number of anomalies. For example, if there are two instances of data length mismatch, one instance of format error, and three instances of value exceeding limits, out of a total of six anomalies, the data length mismatch accounts for 33.3%. The communication timeout rate is calculated as the number of communication timeouts / total number of command transmissions × 100%. For example, if 20 commands are transmitted and two times out, the timeout rate is 10%. The system also tracks high-frequency anomalies, focusing on the functions with the most anomalies. Three functions, namely, loop 2 note writing exception once, loop 3 note reading exception once, and loop 5 switch control exception once, are all high-frequency abnormal functions. At the same time, the root causes of the abnormalities were initially located: data length mismatch, which is related to the len definition in ackData in the configuration file and the actual parsed data length; format error, which is related to whether the communication frame data conforms to the configured communication format; value exceeding the limit, which is related to the valueRange definition in constraintRules in the configuration file and the user input data; communication timeout, which is related to whether the communication parameters are consistent with the device and whether the device is online; and command response error, which is related to whether cmd and ackCmd in the configuration file are correct. Based on statistical reports and root cause analysis, engineers optimize configuration files. The optimization process supports both automatic and manual modes. In automatic optimization, the system automatically generates optimization suggestions and executes optimizations for anomalies with clear root causes. For example, if the actual parsed data length differs consistently from `ackData.len`, the system automatically corrects `ackData.len` to the actual length. In case of command response errors, if the system detects a device response code that is inconsistent with the configured `ackCmd` but the response code is fixed, it automatically corrects `ackCmd` to the actual response code. For values ​​exceeding limits, the system automatically adds interface prompt text to `constraintRules` and adds real-time prompts to the input boxes in the debugging interface. In manual optimization, engineer intervention is required. For example, if communication timeouts are caused by incorrect baud rate configuration, engineers modify `hardwareParams.baudRate` in the configuration file. If the success rate of writing remarks in loop 2 is low, engineers manually modify `write.cmd` after verifying the device manual. For constraint rule optimization, if users frequently input excessively long strings, engineers modify `constraintRules.lengthLimit` after assessing the device's actual support capabilities. The optimized configuration file automatically backs up the original file for easy rollback. The optimized configuration file was re-imported into the debugging system, and the new devices were functionally retested. The retesting process was the same as the initial debugging, focusing on verifying the optimized configuration items. For data length mismatch optimization, the data for this function was read multiple times to check whether it could be parsed accurately and whether there were any length mismatch anomalies. For command code error optimization, the command was executed multiple times to check whether the execution success rate had increased to over 99%. For constraint rule optimization, the original abnormal data, such as excessively long strings or out-of-limit status values, was input to check whether the system could accurately prompt or handle them normally. For communication parameter optimization, communication was conducted continuously for 30 minutes to check whether the communication timeout rate had dropped below 5%. If there were no anomalies in the retest, the optimization was considered effective. If anomalies still existed, the information was collected again and optimized again until the anomaly rate met the requirements (<1%). After the optimization effect is verified, the system archives and stores the optimized configuration file in the format of device type identifier-device model-optimization version number.json, such as "451-HDL-MR1610.433-V1.1.json", overwriting the original configuration file. The version number increments according to the number of optimizations, such as V1.0→V1.1→V1.2. At the same time, the configuration file path and core information in the configuration index library are updated to ensure that the optimized configuration file is loaded when matching devices in the future. The system records optimization logs, and the log content includes optimization time, optimization personnel, optimization type (automatic / manual), optimization fields, values ​​before optimization, values ​​after optimization, optimization reasons, and verification results. The optimization logs are stored in association with the configuration file for easy traceability and auditing. Step 107: Based on the optimized configuration file, complete the adaptation and debugging of the newly added device functions.

[0037] In one embodiment, engineers use an optimized debugging interface to fully verify the various functions of the newly added device. Optionally, the device basic information display verification check whether the interface correctly displays the device model, Chinese / English name, and hardware parameters, without any missing or incorrect information; parameter read / write verification checks whether the device notes and notes for each loop can be accurately obtained and displayed; modification of device notes and loop notes checks whether they can be successfully written and displayed synchronously, and whether data constraint rules are effective, such as prompting an over-limit error when a 30-byte string is entered; control function verification checks whether the switch status of each loop can be controlled accurately, whether the interface status is updated synchronously, and whether there is any delay or control failure; abnormal scenario testing simulates communication interruption and device restart after power failure, checking whether the system can re-establish the communication link and whether the data is retained normally; inputting invalid data, such as non-hexadecimal characters or values ​​exceeding the range, checks whether the system can accurately prompt errors, without crashing or freezing. After all functions pass verification and there are no abnormal alarms, it is determined that the new device function adaptation is complete, and the system generates an adaptation report, including device information, adaptation process (configuration building, import, search, optimization times), optimization records, retest results, etc. The adaptation report can be exported as a PDF for easy archiving and project acceptance.

[0038] Figure 1 The closed-loop process runs through the entire device adaptation cycle. The process logic is tight from configuration building to debugging completion, realizing the connection between configuration, adaptation and optimization. This process completely breaks away from the traditional one device, one development model. It replaces the modification of underlying code with standardized configuration files, shortens the adaptation cycle, and continuously improves the adaptation stability through configuration optimization, thereby improving the adaptation efficiency of new devices and reducing R&D and operation costs.

[0039] Figure 2 This is a flowchart illustrating the new device search process for a device function adaptation method based on configuration data, as provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 The process of searching for and matching new devices with their configuration files is a crucial step in ensuring effective communication between the system and the new devices. This process includes: Step 201: Send a search command to the newly added device via a bus protocol or MAC address search protocol.

[0040] In one embodiment, the engineer, in the device search interface of the debugging system, selects the appropriate preset communication protocol—bus protocol or MAC address search protocol—through a drop-down menu. The system has built-in communication logic for both protocols, requiring no additional plugins. If the bus protocol is selected, the system automatically generates a 0x000E search command frame with the format 0x00 0x0E 0x000x00 0x00 (frame header 0x00, opcode 0x0E, subnet number range 0x00-0xFF, device number range 0x00-0xFF, frame tail 0x00). If the MAC address search protocol is selected, a 0xF003 search command frame is generated with the format 0x00 0xF0 0x03 0x000x00 0x00 (Frame header 0x00, Manufacturer identifier 0xF0, Opcode 0x03, MAC address range 0x00-0xFF, Frame tail 0x00), the communication parameters of the search command (baud rate 9600bps, data bits 8 bits, stop bits 1 bit, parity none) are read from the general parameters in the configuration index library by default. Engineers can manually modify them according to the device manual. After modification, they are automatically saved as personalized configurations to adapt to the communication needs of special devices.

[0041] Step 202: Receive the response data from the newly added device, and extract the device type identifier and device model of the newly added device as the device identity identifier.

[0042] In one embodiment, after a new device powers on and connects to the communication bus, it enters a search-ready state. Upon receiving a search command, it responds according to its own communication protocol specifications. If it is a bus protocol device, the reply data frame format is 0x00 0x0F 0x01 0x02 0x45 0x31 0x48 0x44 0x4C 0x2D 0x4D 0x52 0x31 0x36 0x31 0x30 0x2E 0x34 0x33 0x33 0x00, which includes the operation code 0x0F (response code), subnet number 0x01, device number 0x02, device type identifier 0x45 0x31 (ASCII code 451), and device model 0x48 0x44 0x4C 0x2D 0x4D 0x52 0x31 0x36 0x31 0x30 0x2E 0x34 0x33 0x33 (ASCII code HDL-MR1610.433), frame end 0x00; if it is a MAC address protocol device, the reply data frame contains information such as MAC address, device type identifier, and device model. The format is similar to the bus protocol, only the opcode and manufacturer identifier are different. The transmission timeout for device reply data is set to 500ms. If the system does not receive a response within 500ms, it will automatically retry 3 times. If there is still no response, it will prompt that no device was found. Please check the device connection and power supply.

[0043] The debugging system parses the received response data, extracts key information according to the protocol format, and first verifies whether the frame header and frame trailer are valid, such as bus protocol frame header 0x00 and frame trailer 0x00. If they are invalid, the data is discarded and the system continues to wait for responses from other devices. If the data is valid, the device type identifier and device model are extracted from the specified fields. The process of extracting the device type identifier and device model can be as follows: In the bus protocol, the device type identifier is extracted from bytes 5-7, and the device model is extracted from bytes 8-21; in the MAC address protocol, the device type identifier and device model are extracted from the corresponding reserved fields; the extracted device type identifier and device model are converted into string format, such as byte 0x45 0x31 is converted to 451, and bytes 0x48 0x44 0x4C 0x2D 0x4D 0x52 0x31 0x36 0x31 0x30 0x2E 0x34 0x33 0x33 are converted to HDL-MR1610.433, forming the device identity identifier 451-HDL-MR1610.433. Step 203: Based on the device identity identifier, match it in the configuration file that has been imported into the debugging system to establish a communication link for the newly added device.

[0044] In one embodiment, the system uses the generated device identity as a key to perform an exact match in the configuration index. The configuration index is stored using a hash table. The system traverses the hash table to find the corresponding key. If a match is found, the system obtains the configuration file path, such as / config / devices / 451-HDL-MR1610.433.json, and loads the configuration file into memory. If no match is found, the system displays a prompt window indicating that no configuration file corresponding to device type identifier 451-device model HDL-MR1610.433 was found. The system requests that the configuration file be imported and the system try again. The window contains two buttons: "Import Now" and "Cancel". Clicking "Import Now" will directly open the file selection interface and import the adaptation configuration file. After the configuration file matches successfully, the system reads the communication parameters (baud rate, protocol type, data bits, stop bits, parity bits) from the configuration file, automatically establishes a communication link with the newly added device, and sends a handshake command (0x0001 for bus protocol, 0xF001 for MAC address protocol), waiting for the device to reply with a handshake response command (0x0002 for bus protocol, 0xF002 for MAC address protocol). If a handshake response command is received, the communication link is considered successfully established, the system prompts that the device connection is successful, debugging can begin, and it automatically jumps to the debugging interactive interface; if no handshake response command is received, the system retryes 3 times. If it still fails, it prompts that the communication link establishment failed, please check whether the device communication parameters are consistent with the configuration file, and provides a button to view communication parameters for engineers to verify and correct. Figure 2As a process for establishing device communication, the process involves protocol selection, data interaction, identity matching, and link establishment, enabling rapid identification and connection of new devices. This process standardizes communication interaction logic, ensuring accurate extraction of device identity, efficient configuration file matching, and stable communication link establishment, effectively solving the problems of poor compatibility and low connection success rate in traditional device search.

[0045] Figure 3 This is a flowchart illustrating the configuration parsing process of a device function adaptation method based on configuration data, as provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The process of parsing configuration files and generating functional logic is a crucial step in achieving automatic system adaptation, and specifically includes: Step 301: Extract the basic device information from the static configuration data and use the basic device information as the display data source for the debugging interaction interface.

[0046] In one embodiment, after the system loads the configuration file, it first parses the static configuration data of the base module, extracts and associates it with the debugging interface display module according to the field type, and extracts the basic identity information deviceType (451), deviceModel (HDL-MR1610.433), desc (16-channel 10A intelligent relay module), and descEn (16CH 10A HighPower Switch). The Actuator interface is associated with the device basic information section, which is displayed in the fields of device type identifier, device model, Chinese name and English name. The fields are read-only and cannot be edited. The hardware parameter information is extracted from hardwareParams, which contains ratedCurrent (10A), workingVoltage (DC24V), baudRate (9600), and protocolType (Bus). The hardware parameter sub-section of the associated interface is displayed in the format of parameter name-parameter value, such as rated current-10A, working voltage-DC24V, baud rate-9600bps, communication protocol-Bus. The loop information is extracted from loopCount (16), which is associated with the loop control section of the associated interface. 16 independent debugging entrances for loops are automatically generated. Each entrance is labeled as loop 1, loop 2, ..., loop 16. The display position of the remark input box and the switch control button is reserved. The interface layout adopts a responsive design to adapt to display devices with different resolutions. The device basic information and hardware parameters are laid out in two columns, and the loop control is laid out in 4 columns × 4 rows to ensure that the interface is clean and orderly and there is no information overlap. Step 302: Parse the dynamic operation instructions in the dynamic configuration data, and generate the data read / write execution logic and communication instruction format of the debugging system based on the dynamic operation instructions.

[0047] After static data parsing is completed, the system parses the dynamic configuration data of the device and loops modules, generates data read / write execution logic and communication instruction format, and processes them according to device-level functions and loop-level functions. Taking device remark as an example, when generating the read logic, cmd (000E), len (0), ackCmd (000F), and ackData (index=0, len=20) in device.remark.read are extracted to generate the execution logic. The execution logic process can be as follows: when the user clicks the "Read Remarks" button, the system generates a communication frame containing the 000E opcode according to the communication parameters, sends the communication frame, waits for the device response, and if a 000F response code is received, the response data is extracted according to index=0 and len=20, the hexadecimal data is converted into a string and displayed in the remarks input box, and if there is no response after timeout or other response codes are received, the reading failure is displayed; when the communication format is generated, the communication frame format is 0x00 0x0E 0x00 0x00 0x00, where 0x00 is the frame header, 0x0E is the opcode, the last two 0x00 are the subnet number and device number (default 0), and the last 0x00 is the frame tail; when the write logic is generated, cmd (192E), len (20), data (index=0, len=20), and ackCmd (192F) in device.remark.write are extracted to generate the execution logic. The execution logic process can be as follows: User inputs remarks → Clicks the "Save Remarks" button → System checks the length according to constraintRules (≤20 bytes) → Check passes → Encapsulates data (starting from index=0, 20 bytes long, padded with 0x20 if necessary) → Generates a communication frame containing the 192E opcode → Sends the communication frame → Waits for device response → If a 192F response code is received → Displays "Save Successful" → Updates the input box display → Check fails → Displays "Remarks length cannot exceed 20 bytes" → If no response is received within a timeout or another response code is received → Displays "Save Failed"; When generating the communication format, the communication frame format is 0x00 0x19 0x2E 0x00 0x00 (subnet number, device number) 0xXX... (20 bytes of remarks data) 0x00.

[0048] Taking the switch state of loop 1 as an example, when the logic is generated, the cmd (F020), len (1), data (index=0, len=1), ackCmd (F021), and ackData (index=2, len=1) in loops[0].switchStatus.read are extracted to generate the execution logic. The execution logic process can be as follows: the user clicks the loop 1 read status button → the system encapsulates data (index=0, len=1, data is loop number 1) → generates a communication frame containing the F020 operation code → sends the communication frame → waits for the device response → if the F021 response code is received → extracts the response data according to index=2, len=1 → if the data is 0, it displays closed, if it is 1, it displays open → timeout or response code error → displays read failure; when the communication format is generated, the communication frame format is 0x00 0xF0 0x20 0x00 0x00 0x01 (loop number) 0x00; when the write logic is generated, extract cmd (F022), len (2), data (index=1, len=1), extra (index=0, len=1, value=1), ackCmd (F023) from loops[0].switchStatus.write to generate the execution logic. The execution logic process can be as follows: the user clicks the "Open" button on loop 1 → the system verifies the data (1 is within the value range of 0 and 1) → encapsulates the data (extra field loop number 1 + data field status 1) → generates a communication frame containing the F022 operation code → sends the communication frame → waits for the device response → if the F023 response code is received → displays "Control successful" → updates the status to "Open" → clicking the "Close" button encapsulates the status to 0 → other logic is the same → data verification fails → displays an invalid status value → timeout or response code error → displays "Control failed"; when the communication format is generated, the communication frame format is 0x00 0xF0 0x22 0x00 0x00 0x01 (loop number) 0x01 (status) 0x00. Step 303: Associate the basic equipment information with the dynamic operation instructions to form the functional logic that the debugging system directly executes.

[0049] In one embodiment, the extracted basic device information is associated with the generated execution logic and communication format to form functional logic that the debugging system can directly execute. The association is stored through a configuration mapping table, which includes fields such as function name, interface element ID, static information association, execution logic ID, and communication format ID. For example, the device remark read function is associated with the interface element ID "btn_read_remark", the static information device model and Chinese name, the execution logic ID "logic_read_remark", and the communication format ID "format_read_remark". When the system is running, when the user clicks on an interface element, such as btn_read_remark, the corresponding execution logic and communication format can be quickly found through the configuration mapping table, and the corresponding operation can be executed without hard-coding the association, thus improving scalability.

[0050] Figure 3 Focusing on the configuration parsing stage, the configuration file is transformed into functional logic that can be directly executed by the debugging system through three steps: static information extraction, dynamic logic generation, and association mapping. This process achieves precise docking between configuration data and system functions, automatically generates standardized interface display rules and communication formats, eliminates the need for manual coding, improves system scalability, and ensures that the adaptation logic of different devices is uniform and standardized.

[0051] Figure 4 This is a configuration optimization flowchart of a device function adaptation method based on configuration data provided in an embodiment of this application. Please refer to [link / reference]. Figure 4 The configuration file iterative optimization process is a crucial step in continuously improving adaptation stability and reliability, and specifically includes: Step 601: Statistical data include read / write frequency, instruction execution success rate, data parsing exception types, and communication timeout status.

[0052] In one embodiment, when an engineer uses the debugging interface to operate a newly added device, the system background collects key information in real time at a frequency of once per operation. The collected content is stored in a debugging log database (SQLite). Basic operation information includes operation timestamp, operation type (read / write / control), function name (e.g., device note read, loop 1 switch open), and operation result (success / failure). Usage frequency data includes the number of operations for each function (e.g., device note read 3 times, loop 1 switch control 5 times), and operation interval (e.g., a 10-second interval between two loop controls). Command execution exception information includes the name of the failed function, failure time, failure reason (command response error, communication timeout, data parsing exception), corresponding command code (e.g., F010), and communication frame data (e.g., 0x00 0xF0 0x10 0x01 0xXX...). 0x00; Data parsing anomaly information includes anomaly type (data length mismatch, format error, value exceeding limit), and abnormal data, such as parsing 25 bytes of data but the configuration requires 20 bytes, receiving non-hexadecimal data, and a status value of 2; Communication anomaly information includes communication timeout count, timeout function name, timeout duration, and communication parameters at the time (baud rate, subnet number, device number). The log database is partitioned by day and retains 30 days of log data for easy traceability and analysis. Engineers can filter logs by time, function name, and anomaly type through the system log query function. The system periodically performs statistical analysis on the collected log data and generates configuration optimization analysis reports. It also supports engineers to manually trigger statistical analysis. Key statistical indicators include command execution success rate, percentage of exception types, communication timeout rate, and high-frequency exception functions. When initially locating the root cause of an exception, the system checks for data length mismatch (the len definition in the ackData configuration file matches the actual parsed data length), format errors (whether the communication frame data conforms to the configured communication format), value exceeding limits (the valueRange definition in the constraintRules configuration file matches the user input data), communication timeouts (whether the communication parameters are consistent with the device and whether the device is online), and command response errors (whether the cmd and ackCmd in the configuration file are correct). Step 602: Optimize the data index definition, instruction mapping relationship and data constraint rules in the configuration file based on the statistical data.

[0053] In one embodiment, engineers optimize the configuration file based on the configuration optimization analysis report and the root cause localization results. The optimization process supports both automatic and manual optimization modes. In automatic optimization, the system automatically generates optimization suggestions and executes optimizations for anomalies with clear root causes. For example, if the actual parsed data length is inconsistent with ackData.len, the system automatically corrects ackData.len to the actual length; if the system detects a command response error where the device's response code is inconsistent with the configured ackCmd but the response code is fixed, it automatically corrects ackCmd to the actual response code; if the value exceeds the limit, the system automatically adds interface prompt text to constraintRules and adds real-time prompts to the input box in the debugging interface. In manual optimization, engineer intervention is required. For example, if communication timeout is caused by an incorrect baud rate configuration, the engineer modifies hardwareParams.baudRate in the configuration file; if the success rate of writing loop 2 notes is low, the engineer manually modifies write.cmd after verifying the device manual; if users frequently input excessively long strings, the engineer modifies constraintRules.lengthLimit after assessing the actual support capability of the device. The optimized configuration file automatically backs up the original file for easy rollback.

[0054] Step 603: Verify the adaptation effect of the optimized configuration file and form a configuration iteration.

[0055] In one embodiment, the optimized configuration file is re-imported into the debugging system, and the newly added device undergoes functional retesting. The retesting process is consistent with the initial debugging, focusing on verifying the optimized configuration items. For data length mismatch optimization, the functional data is read multiple times to check whether it can be accurately parsed and whether there are any length mismatch anomalies. For instruction code error optimization, the instruction is executed multiple times to check whether the execution success rate has increased to over 99%. For constraint rule optimization, the original abnormal data, such as excessively long strings or out-of-limit status values, is input to check whether the system can accurately prompt or handle them normally. For communication parameter optimization, communication is conducted continuously for 30 minutes to check whether the communication timeout rate has dropped below 5%. If there are no anomalies in the retest, the optimization is considered effective. If anomalies still exist, the system returns to collect information again to analyze the reasons for the unresolved issues, such as device hardware failure or other errors in the configuration file. Optimization is repeated until the anomaly rate meets the requirement (<1%).

[0056] After the optimization effect is verified, the system archives and stores the optimized configuration file in the format of "Device Type Identifier-Device Model-Optimization Version Number.json", overwriting the original configuration file. The version number increments according to the number of optimizations, such as V1.0→V1.1→V1.2. At the same time, the configuration file path and core information in the configuration index library are updated to ensure that the optimized configuration file is loaded when matching devices in the future. The system records optimization logs, which include optimization time, optimization personnel, optimization type (automatic / manual), optimization fields, values ​​before optimization, values ​​after optimization, optimization reasons, and verification results. The optimization logs are stored in association with the configuration file for easy traceability and auditing in the future.

[0057] Figure 4 By combining anomaly information statistics, configuration optimization, and effect verification, a closed-loop configuration iteration is formed. This process accurately locates adaptation issues based on debug logs, optimizes configuration parameters in a targeted manner, and verifies the optimization effect through retesting. It can continuously reduce the anomaly rate, improve the command execution success rate and communication stability, and enable the adaptation solution to have complete capabilities, ensuring the reliability of long-term use.

[0058] Figure 5 This is a flowchart illustrating the bus protocol usage of a device function adaptation method based on configuration data, as provided in an embodiment of this application. Please refer to [link / reference]. Figure 5 The device search and basic information display process based on the Bus protocol is a specific application of the preset communication protocol, applicable to intelligent control devices that support the Bus protocol, specifically including: Step 701: Send Bus protocol search command to search for newly added devices.

[0059] In one embodiment, when an engineer selects the Bus protocol on the device search interface of the debugging system, the system generates a 0x000E search command frame. The frame format is 0x00 0x0E 0x00 0xFF 0x00 0xFF 0x00, where 0x00 is the frame header, 0x0E is the Bus protocol search opcode, 0x00-0xFF is the subnet number search range (0-255), 0x00-0xFF is the device number search range (0-255), and 0x00 is the frame tail. The engineer can modify the subnet number and device number search range according to the actual network topology, such as searching only subnet numbers 1-10 and device numbers 1-50 to narrow the search range and improve the search speed. After clicking the start search button, the system sends the search command according to the configured communication parameters (baud rate 9600bps, data bits 8 bits, stop bits 1 bit, parity none), with a sending interval of 100ms, and sends it three times consecutively to ensure that the device can receive it.

[0060] Step 702: Add device response data.

[0061] In one embodiment, after receiving the 0x000E search command, a newly added device supporting the Bus protocol replies with a response data frame according to the Bus protocol specification. The frame format is "0x00 0x0F 0x01 0x02 0x45 0x31 0x48 0x44 0x4C 0x2D 0x4D 0x52 0x31 0x36 0x31 0x30 0x2E 0x34 0x33 0x33 0x01 0x02 0x03 0x00", and the meanings of each field include: 0x00 is the frame header, 0x0F is the Bus protocol search response opcode, 0x01 is the source device subnet number, 0x02 is the source device number, 0x45 0x31 is the device type identifier (ASCII code 451), 0x48 0x44 0x4C 0x2D 0x4D 0x52 0x31 0x36 0x31 0x30 0x2E 0x34 0x33 0x33 is the device model (ASCII code HDL-MR1610.433), 0x01 0x02 0x03 is the device version number (V1.2.3), and 0x00 is the frame trailer. The transmission time of device reply data is ≤100ms to ensure fast response.

[0062] Step 703: Parse the response data and display the basic information of the newly added device.

[0063] In one embodiment, the debugging system parses the received Bus protocol response data frames. The parsing process includes: verifying whether the frame header and frame trailer are 0x00; if they do not match, the data is discarded; verifying whether the response opcode is 0x0F to confirm that it is a Bus protocol search response; extracting the subnet number (0x01) from the 3rd byte, the device number (0x02) from the 4th byte, the device type identifier (451) from the 5th to 7th bytes, the device model (HDL-MR1610.433) from the 8th to 21st bytes, and the device version number (V1.2.3) from the 22nd to 24th bytes; converting the hexadecimal device type identifier and device model into string format, and converting the version number according to the format "byte 1.byte 2.byte 3" (0x01 0x02 0x03 → V1.2.3). If data is missing or the format is incorrect during the parsing process, the system prompts that the device response data is abnormal and requests a re-search. The system displays the parsed basic device information in the debugging interface according to the preset layout. The display area is divided into the Bus protocol device information section, which includes the following fields: communication protocol (Bus), subnet number (1), device number (2), device type identifier (451), device model (HDL-MR1610.433), Chinese name (16-channel 10A intelligent relay module), English name (16CH10A High Power Switch Actuator), device version (V1.2.3), hardware parameters (rated current 10A, working voltage DC24V, baud rate 9600bps). All fields are read-only. Engineers can copy the basic device information by clicking the copy information button for easy document recording. Step 704: Configure the new device.

[0064] In one embodiment, after the engineer confirms that the equipment information is correct, they click the "Enter Debugging" button at the bottom of the interface. The system automatically loads the matching configuration file and generates a parameter configuration interface. The parameter configuration interface can be: device-level parameter configuration including a device remarks input box, and buttons for reading and saving remarks; loop-level parameter configuration including 16 loop remarks input boxes, switch status control buttons (on / off), and buttons for reading status and saving remarks; and an operation log display area that shows the operation process and results in real time, such as "2025-01-01 10:00:00 Successfully read device remarks (Conference room control module, 2025-01-01 10:01:00 Successfully opened control loop 1). After entering the debugging interface, the system maintains a Bus protocol communication link with the equipment, responding to the engineer's operation commands in real time without needing to re-establish a connection. Figure 5 By sending commands, responding to data, parsing and displaying data, and configuring parameters, end-to-end adaptation of Bus protocol devices is achieved. This process refines the communication and interaction details of the Bus protocol, ensuring accurate parsing of basic device information and convenient parameter configuration. It provides a standardized adaptation path for smart devices that support the Bus protocol, improving the adaptation efficiency and compatibility of devices with specific protocols.

[0065] Figure 6 This is a structural diagram of a device function adaptation system based on configuration data provided in an embodiment of this application. Please refer to [link / reference]. Figure 6 The functional modules of this application system include a configuration building module 501, a configuration import module 502, a device search module 503, a configuration parsing module 504, a function adaptation module 505, a configuration optimization module 506, and a debugging optimization module 507. These modules work together to achieve end-to-end device adaptation. Modules communicate via a data bus, and the data transmission format is standardized, specifically including: In one embodiment, the configuration building module 501 is used to build configuration data for newly added devices and generate configuration files based on the configuration data. The module provides a visual configuration editing interface, allowing engineers to fill in configuration data according to templates. The interface is divided into two tabs: static configuration and dynamic configuration. The operation logic is simple and requires no professional programming knowledge. The static configuration tab provides input boxes for device type identifier, device model, Chinese name, English name, number of loops, and hardware parameters (rated current, operating voltage, baud rate, protocol type). The input boxes have built-in validation rules, such as the device type identifier being a numeric string, the number of loops being a positive integer, and the baud rate being a common value (9600 / 4800 / 2400). Real-time prompts are given when input errors occur. The dynamic configuration tab supports adding device-level functions, such as device notes, and loop-level functions, such as loop notes and switch status. Each function can be configured with read / write identifiers, data types, and functions. The module includes a description, read instruction configuration (opcode, data length to send, response opcode, response data parsing rules), write instruction configuration (opcode, data length to send, data encapsulation rules, additional fixed data, response opcode), and data constraint rules (data length limit, value range). After engineers complete the form, they can click the "Generate Configuration File" button. The module automatically organizes the data in JSON format, generates the configuration file, and downloads it locally. The file name follows the format "device type identifier - device model.json" to ensure standardization. The module also includes configuration templates for common devices (smart relays, sensors, switches). Engineers can select a template, modify parameters, and quickly generate configuration files, improving efficiency. It also supports importing and editing configuration data. Engineers can import existing configuration files, modify fields on the visual interface, and regenerate the configuration file without manually editing the JSON code.

[0066] The configuration import module 502 is used to import configuration files into the debugging system, establishing a mapping between configuration data and the debugging system. The module supports single-file import and batch import, with a high degree of automation in the import process. For single-file import, engineers select a local configuration file via a file selection button. The module automatically parses the JSON structure, verifies data integrity (checking the existence of required fields) and format compliance (checking if the instruction code is hexadecimal and the data length is a non-negative integer). After successful verification, the configuration file is stored in the system's designated directory ( / config / devices / ) and the configuration index (hash table structure) is updated. If verification fails, an error message window pops up listing specific errors for engineers to correct. For batch import, engineers select... The module contains a folder with multiple configuration files. It iterates through all .json files in the folder, performs batch parsing and verification, and generates an import report (including the number of successfully imported files, the names of failed files, and the reasons). Successfully imported configuration files are stored and the index is updated according to the same rules. Failed files do not affect the import of other files. When the association mapping is established, the module associates static configuration data with the interface display module and dynamic configuration data with the data read / write module and the communication module. The association relationship is stored in the configuration mapping table for other modules to call. The module also provides configuration file management functions, supporting viewing the list of imported configuration files (including device type identifier, device model, import time, and version number), and supporting the deletion, updating (re-importing and overwriting), and export of configuration files for easy maintenance.

[0067] The device search module 503 is used to search for newly added devices through a preset communication protocol, obtain the identification of the newly added devices, and match the configuration file based on the identification. The module has built-in communication logic for the Bus protocol and MAC address search protocol, and supports automatic and manual search modes. In terms of communication protocol configuration, the module provides a communication parameter configuration interface, which supports configuring baud rate, data bits, stop bits, parity bits, subnet number range, and device number range. The configuration parameters can be saved as default configurations or personalized configurations (associated by device type identifier). When the search is executed, the engineer selects the communication protocol and clicks "Start Search". The module generates the corresponding search command frame and sends it to the bus through the system communication interface (RS485, Ethernet). The search process is displayed in real time. The system displays the search status ("Searching..." "1 device found..."). During device response processing, the module receives the data frames replied by the device, parses them according to the protocol format, and extracts the device identification (device type identifier - device model). If parsing fails, it displays "Unknown device found, unable to identify its identity." When matching configuration files, the module matches the extracted device identification in the configuration index library. If the match is successful, the corresponding configuration file is loaded; if the match fails, it prompts "No corresponding configuration file found, please import and provide an import entry." When establishing a communication link, after a successful match, the module establishes a communication link with the device according to the communication parameters in the configuration file, sends a handshake command and verifies the response. After the link is successfully established, it notifies the function adaptation module to enter the debugging state. The configuration parsing module 504 is used to parse the configuration file matched by the identity identifier, extract the static attribute information and dynamic operation instructions of the newly added device, and generate the functional logic and communication format for the debugging system based on the static attribute information and dynamic operation instructions. During static information parsing, the module parses the base field of the configuration file, extracts the basic information of the device (model, name, hardware parameters) and loop information, organizes it into a standardized data structure according to the requirements of the interface display module, and sends it to the interface display module. During dynamic instruction parsing, the module parses the device and loops fields, extracts the read instructions, write instructions, and data constraint rules of each function, and generates data read and write execution logic (including operation flow and condition judgment). Error handling and execution logic are implemented using a structured description language, such as JSON, to facilitate parsing and execution by the functional adaptation module. Simultaneously, a standardized communication frame format (including frame header, opcode, data, checksum, and frame trailer) is generated based on the communication parameters and command codes in the configuration file and associated with the execution logic to ensure that the execution logic can call the corresponding communication format. The module also generates a configuration mapping table to establish the association between interface elements, static information, execution logic, and communication formats, and sends it to the functional adaptation module for its use. Incremental parsing of the configuration file is also supported; when the configuration file is updated, only the modified fields are parsed and the corresponding execution logic and communication format are updated, without needing to re-parse the entire file, thus improving parsing efficiency. The functional adaptation module 505 is used to adapt the configuration data reading, modification, and control functions of newly added devices based on functional logic and communication format, and to generate a debugging interactive interface. When generating the interface, the module receives static information and a configuration mapping table sent by the configuration parsing module, and automatically generates a standardized debugging interactive interface. The interface adopts a modular layout, including a device basic information section, a parameter configuration section, a loop control section, and an operation log section. It supports responsive design and adapts to different display devices. During data read / write adaptation, the module receives operation commands from engineers, such as clicking to read notes, save notes, or open loop 1. It then looks up the corresponding execution logic and communication format through the configuration mapping table, executes the logic, generates a communication frame, and sends it through the communication module. The module receives response data from the device, parses and updates the interface display according to the execution logic, and records operation logs. During data verification and adaptation, the module performs real-time verification of the data input by the engineer according to the data constraint rules in the configuration file, such as length and value range. Only after the verification passes can subsequent operations be executed; if the verification fails, an error message is displayed. During control function adaptation, the module supports the adaptation of device control functions, such as switch control and mode switching. It sends control commands according to the execution logic, receives device status feedback, and updates the interface to ensure that the control functions are accurate and effective. The module also supports personalized interface configuration. Engineers can hide unnecessary sections and adjust the interface layout. Personalized configurations are automatically saved and loaded automatically the next time the debugging interface is accessed.

[0068] The configuration optimization module 506 responds to operations on the debugging interface, records configuration data usage and exception information during debugging, and iteratively optimizes the data definition and instruction mapping relationship of the configuration file. During information collection, the module collects operation and exception information in real time during the debugging process and stores it in the log database. The collected content includes operation type, function name, operation result, exception type, communication frame data, and timestamp. During statistical analysis, the module periodically performs statistical analysis on the log data and generates a configuration optimization analysis report, including instruction execution success rate, exception type ratio, high-frequency exception functions, and preliminary location of exception root causes. It supports manual triggering of analysis by engineers. When generating optimization suggestions, the module generates targeted configuration optimization suggestions based on the statistical analysis results, such as correcting instruction codes, adjusting data length, and supplementing constraint rule prompts. Engineers can view the suggestions and execute optimizations. When updating the configuration file, after the engineer confirms the optimization suggestions, the module automatically modifies the corresponding fields in the configuration file or provides a manual modification interface. After modification, the optimized configuration file is saved, the original file is backed up, and the configuration index library is updated. When verifying the optimization effect, the module supports quick import and retesting of the optimized configuration file, comparing key indicators (exception rate, execution success rate) before and after optimization to verify the optimization effect.

[0069] The debugging and optimization module 507 is used to adapt and debug the functions of newly added devices based on the optimized configuration file. During function retesting, the module provides a function retesting process, guiding engineers to fully verify the various functions of the newly added devices in a preset order (display of basic device information → parameter reading and writing → loop control → abnormal scenario testing), and records the retesting results in real time. When the adaptation report is generated, after the retesting is completed, the module generates a device adaptation report, which includes device information, adaptation process (configuration building, import, search, number of optimizations), optimization records, retesting results (testing status of various functions, anomaly rate, execution success rate), and adaptation conclusion (adaptation success / failure). The report can be exported to PDF format. When troubleshooting, if problems are found during the retesting process, the module provides troubleshooting tools, which support viewing operation logs, communication frame data, and anomaly types to help engineers locate the cause of the problem. When the adaptation is confirmed, if the retesting results meet the preset requirements (anomaly rate <1%, execution success rate ≥99%, all function tests passed), the module prompts that the device adaptation is complete, updates the adaptation status to complete, and stores the adaptation report and the optimized configuration file for later review and reuse.

[0070] Figure 6 The configuration building, importing, and searching processes are modularized, with clear responsibilities for each module and standardized data interaction. The configuration building module lowers the configuration threshold, the configuration optimization module ensures adaptation quality, and the debugging and optimization module completes the final verification, forming a well-defined and highly collaborative adaptation system. This improves system maintainability and scalability, and supports batch adaptation of multiple types of devices.

[0071] Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Please refer to it. Figure 7 The hardware structure of the electronic device of this application, which can integrate the device function adaptation system of this application and execute the device function adaptation method based on configuration data, specifically includes: In one embodiment, the electronic device includes a processor 401, a memory 402, an input device 403, an output device 404, a communication module, and a bus. The number of processors 401 can be one or more, and the figure shows one processor 401 as an example. The processor 401, memory 402, input device 403, output device 404, and communication module are connected by a bus. The bus adopts a CAN bus or a PCIe bus to ensure stable and efficient data transmission. The memory 402 serves as a computer-readable storage medium and can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules (configuration building module, configuration import module, device search module, etc.), configuration files, and log databases corresponding to the device function adaptation system in this embodiment of the application. The memory 402 may mainly include a program storage area and a data storage area.

[0072] The storage program area stores the operating system, such as Windows 10, Linux Ubuntu 20.04, program code for various functional modules of the device function adaptation system, communication protocol drivers (Bus protocol, MAC address protocol), interface generation tools (Qt, Electron), and database management system (SQLite). The storage data area stores imported configuration files (stored in a specified directory in the format of "device type identifier-device model.json"), configuration index (hash table data file), log database (SQLite database file, partitioned by day), interface personalization configuration files, and adaptation reports (PDF format). The storage 402 may include high-speed random access memory (DRAM, capacity ≥ 8GB) and may also include non-volatile memory (such as solid-state drive SSD, capacity ≥ 256GB) to ensure data storage security and read / write speed. In some instances, the storage 402 may further include storage remotely configured relative to the processor 401, such as a network storage server. These remote storage devices are connected to electronic devices via a network to support remote storage and retrieval of configuration files and log data.

[0073] The processor 401 executes various functional applications and data processing of electronic devices by running software programs, instructions, and modules stored in the memory 402, thereby realizing the device function adaptation method based on configuration data mentioned above. The processor 401 can be a multi-core CPU (such as Intel Core i7-12700H, AMD Ryzen 7 5800H), which has strong parallel computing and data processing capabilities, a main frequency of ≥2.7GHz, and a cache of ≥16MB, ensuring the efficient operation of processes such as configuration parsing, function adaptation, and statistical analysis. The entire adaptation process for a single device takes ≤5 minutes, meeting the needs of rapid adaptation. The processor 401 also supports virtualization technology, which can run adaptation tasks for multiple devices simultaneously, improving the efficiency of multi-device parallel adaptation.

[0074] Input device 403 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. For example, input device 403 can be a keyboard, mouse, touch screen, touchpad, knob, etc.; keyboard and mouse are used by engineers to input configuration data, click operation buttons, and select menu options; touch screen and touchpad support touch operation and are compatible with portable electronic devices, such as laptops, for easy on-site debugging; knob can be used to quickly adjust communication parameters, such as baud rate and select search range, to improve operational convenience. Input device 403 also supports external input devices, connecting external keyboards, mice, and touch screens via USB interface and Bluetooth to adapt to different debugging scenario requirements.

[0075] Output device 404 can be used to send or display key signal outputs related to user settings and function control of the device. For example, output device 404 can be a display screen, printer, indicator light, speaker, etc. The display screen is used to display the debugging interface, basic device information, operation log, configuration optimization analysis report, and adaptation report. The display screen can be a high-definition LCD or OLED screen with a resolution of ≥1920×1080 and support for multi-touch, which is convenient for engineers to operate. The printer is used to print adaptation reports and configuration file lists, which is convenient for paper archiving. The indicator light is used to indicate the device's operating status (green light is solid during normal operation, green light flashes during adaptation, and red light is solid during abnormality). The speaker is used to emit operation prompts, such as adaptation completion prompts and abnormal alarm sounds, to remind engineers to pay attention to critical status. The communication module is used for communication connections between electronic devices and external devices (new devices, network storage servers), supporting both wired and wireless communication. Optionally, wired communication is achieved through an RS485 interface and an Ethernet interface. The RS485 interface supports bus protocol communication with a transmission distance of ≤1200 meters, suitable for long-distance debugging in industrial environments. The Ethernet interface supports the TCP / IP protocol and is used to connect to a network storage server for remote uploading and downloading of configuration files and log data. Wireless communication is achieved through a Wi-Fi module and a Bluetooth module. The Wi-Fi module supports the 802.11a / b / g / n / ac protocol for wireless connection between the debugging system and new devices, suitable for wireless scenarios. The Bluetooth module supports the Bluetooth 5.0 protocol for short-range connection to external input / output devices (such as Bluetooth keyboards and Bluetooth headsets). The 405 communication module has a built-in communication protocol stack, supporting data packet encapsulation and parsing of Bus protocol and MAC address search protocol, ensuring the stability and reliability of communication with new devices. Figure 7 The hardware architecture provides support for the above methods and systems. The processor ensures the efficient operation of processes such as configuration parsing and function adaptation. The memory meets the storage requirements of a large number of configuration files and logs. The input / output devices improve the ease of operation. The communication module enables stable data transmission. This hardware configuration ensures that the entire adaptation process for a single device takes ≤5 minutes and supports parallel adaptation for multiple devices. It provides hardware support for the adaptation methods and systems, ensuring that the adaptation process is stable and efficient.

[0076] In one embodiment, the computer-readable storage medium of this embodiment adopts a solid-state drive (SSD, capacity ≥256GB) or a high-speed USB flash drive, supports USB 3.0 and above interfaces, ensures a data read / write speed ≥500MB / s, meets the requirements for rapid import and export of configuration files, and the storage medium pre-stores computer-readable instructions. The instructions are organized in a modular structure and include the execution code for the entire process of configuration building, importing, searching, parsing, adapting, optimizing and debugging. It also stores a common device configuration template library and a communication protocol driver package.

[0077] When the processor executes instructions, it first reads the configuration file parsing logic in the storage medium to quickly extract static and dynamic configuration data; it then uses a preset communication protocol driver to perform device search and identity matching, and generates executable instructions for the debugging system based on the functional logic generated in the storage medium; it calls the interface generation template in the storage medium to automatically create an interactive interface, while simultaneously recording debugging logs to a specified partition in the storage medium in real time; the log data is stored in categories by day, retaining 30 days of historical records, supporting anomaly tracing and configuration iteration optimization; the storage medium uses encrypted storage technology to ensure the security of configuration data and debugging logs, and is compatible with multiple operating systems such as Windows and Linux, and can be directly connected to various debugging terminals without additional driver installation, effectively supporting rapid adaptation of new devices and reducing cross-platform usage requirements.

[0078] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments provided herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A device function adaptation method based on configuration data, characterized in that, Includes the following steps: Build configuration data for the newly added device, and generate a configuration file based on the configuration data; Import the configuration file into the debugging system and establish an association mapping between the configuration data and the debugging system; The newly added device is searched using a preset communication protocol to obtain its identity identifier, and the configuration file is matched based on the identity identifier. The configuration file matched by the identity identifier is parsed, the static attribute information and dynamic operation instructions of the configuration data of the newly added device are extracted, and the functional logic and communication format recognized by the debugging system are generated based on the static attribute information and the dynamic operation instructions. Based on the functional logic and the communication format, the configuration data reading, modification and control functions of the newly added device are adapted, and a debugging interactive interface is generated; In response to operations on the debugging interface, the system records the use of configuration data and exception information during the debugging process, and iteratively optimizes the data definition and instruction mapping relationship of the configuration file. Based on the optimized configuration file, the adaptation and debugging of the newly added device functions are completed.

2. The device function adaptation method based on configuration data according to claim 1, characterized in that, The configuration data includes static configuration data and dynamic configuration data. The static configuration data represents the static attribute information of the newly added device, and the dynamic configuration data represents the dynamic operation instructions of the newly added device. The static configuration data includes device type identifier, device model, product name, number of circuits, and inherent hardware parameters. The static configuration data is a read-only attribute used to define the basic functions and basic information of the newly added device. The dynamic configuration data includes data read / write identifiers, data types, function descriptions, read instruction configurations, write instruction configurations, and data constraint rules, which are used to define the read / write logic and communication interaction specifications of the newly added device data.

3. The device function adaptation method based on configuration data according to claim 2, characterized in that, The read instruction configuration includes the read operation code, the data length to be sent, the data index, and the response operation code; The write instruction configuration includes the write opcode, the data length to be sent, the data index, additional fixed data, and the response opcode. The data constraint rules include the range of data values, data length limits, and dependencies between related data.

4. The device function adaptation method based on configuration data according to claim 2, characterized in that, The newly added device is searched using a preset communication protocol to obtain its identity identifier, and the configuration file is matched based on the identity identifier, including: Send search commands to the newly added device via bus protocol or MAC address search protocol; Receive the response data from the newly added device, and extract the device type identifier and device model of the newly added device as the device identity identifier; Based on the device identity identifier, a matching process is performed in the configuration file that has been imported into the debugging system to establish a communication link for the newly added device.

5. The device function adaptation method based on configuration data according to claim 2, characterized in that, The process of parsing the configuration file matched by the identity identifier, extracting static attribute information and dynamic operation instructions from the configuration data of the newly added device, and generating functional logic and communication format for the debugging system based on the static attribute information and the dynamic operation instructions includes: Extract the basic device information from the static configuration data and use the basic device information as the display data source for the debugging interaction interface; Parse the dynamic operation instructions in the dynamic configuration data, and generate the data read / write execution logic and communication instruction format of the debugging system based on the dynamic operation instructions; The basic equipment information is associated with the dynamic operation instructions to form the functional logic that the debugging system directly executes.

6. The device function adaptation method based on configuration data according to claim 1, characterized in that, The adaptation of the configuration data reading, modification, and control functions of the newly added device based on the functional logic and the communication format includes: According to the parsed read instruction configuration, a data read request is sent to the newly added device, and the response data of the newly added device is received and parsed. According to the parsed write instruction configuration, the modified data is encapsulated and sent to the newly added device, and the configuration result response from the newly added device is received, wherein the communication format is adapted to the communication protocol of the newly added device.

7. The device function adaptation method based on configuration data according to claim 1, characterized in that, The process of recording configuration data usage and exception information during debugging, and iteratively optimizing the data definition and instruction mapping relationship of the configuration file, includes: Statistical data include read / write frequency, command execution success rate, data parsing anomaly types, and communication timeouts. Based on the statistical data, optimize the data index definition, instruction mapping relationship, and data constraint rules in the configuration file; Verify the adaptation effect of the optimized configuration file to form a configuration iteration.

8. A device function adaptation system based on configuration data, characterized in that, include: A configuration building module is used to build configuration data for newly added devices and generate configuration files based on the configuration data; The configuration import module is used to import the configuration file into the debugging system and establish an association mapping between the configuration data and the debugging system. The device search module is used to search for the newly added device through a preset communication protocol, obtain the identity identifier of the newly added device, and match the configuration file based on the identity identifier; The configuration parsing module is used to parse the configuration file matched by the identity identifier, extract the static attribute information and dynamic operation instructions of the configuration data of the newly added device, and generate the functional logic and communication format recognized by the debugging system based on the static attribute information and the dynamic operation instructions. The function adaptation module is used to adapt the configuration data reading, modification and control functions of the newly added device based on the functional logic and the communication format, and generate a debugging interactive interface; The configuration optimization module is used to respond to operations on the debugging interface, record the configuration data usage and exception information during the debugging process, and iteratively optimize the data definition and instruction mapping relationship of the configuration file. The debugging and optimization module is used to adapt and debug the newly added device functions based on the optimized configuration file.

9. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the device function adaptation method based on configuration data as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the device function adaptation method based on configuration data as described in any one of claims 1-7.

Images