A cross-protocol configuration method, apparatus, device and medium

Abstract

This application discloses a cross-protocol configuration method, apparatus, device, and medium, relating to the field of communication protocol configuration technology. It receives configuration file registration information reported by the underlying protocol driver, parses it to generate a mapping relationship with the configuration file name as the key; receives a configuration request sent by debugging software, parses it to obtain the target configuration file name and configuration data, and queries the mapping relationship; if a match is found and the configuration status is marked as valid, the configuration data is saved to the corresponding file storage path, and a configuration loading notification is sent to the underlying protocol driver with the corresponding driver identifier; if a mismatch is found, a pass-through command sent by the debugging software via a pass-through protocol is received, the target driver identifier is parsed, and the pass-through command is forwarded to the corresponding underlying protocol driver, which converts it to its own protocol format and then sends it to the corresponding bus. This solution can uniformly adapt to multiple types of heterogeneous protocol drivers without requiring separate development of configuration interfaces for each protocol.

Description

Technical Field

[0001] This application relates to the field of communication protocol configuration technology, and in particular to a cross-protocol configuration method, apparatus, device and medium. Background Technology

[0002] With the rapid development of IoT and smart building automation technologies, modern engineering projects are increasingly inclined to integrate hardware devices from multiple manufacturers and of various types to build comprehensive management and control systems with rich functionality. Due to historical reasons and technological barriers, devices from different manufacturers often use heterogeneous communication protocols (such as the coexistence of industry standard protocols and proprietary custom protocols). This forces the upper-level management system to deal with the complex underlying hardware environment, making cross-protocol data interoperability and device configuration a key aspect of system integration.

[0003] However, existing technologies typically employ a tightly coupled point-to-point development model, meaning that the host computer debugging software needs to develop independent communication interfaces, data parsing logic, and configuration interfaces for each type of access hardware protocol. Because different protocols have incompatible data formats, storage paths, and configuration interfaces, the host computer software architecture becomes congested, resulting in extremely low code reusability. Whenever a new or replaced hardware device is added, the host computer must be customized and recompiled, leading to high development and maintenance costs and a high risk of configuration failures due to protocol differences, thus failing to achieve true unified management. Summary of the Invention

[0004] This application provides a cross-protocol configuration method, apparatus, device, and medium. It establishes a mapping relationship by receiving configuration file registration information reported by the underlying protocol driver. It adopts a combination of standard protocol configuration and transparent protocol configuration to uniformly manage the configuration and forward instructions of heterogeneous protocol drivers. It eliminates the need to develop separate adaptation interfaces for each protocol, simplifies the configuration process, and improves the compatibility and configuration efficiency of multi-protocol device access.

[0005] In a first aspect, embodiments of this application provide a cross-protocol configuration method applied to a gateway device, the configuration method comprising: The system receives configuration file registration information reported by the underlying protocol driver, parses and processes the configuration file registration information, and generates a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path. The system receives a configuration request sent by the debugging software, parses the configuration request to obtain the target configuration file name and configuration data, and queries the mapping relationship based on the target configuration file name. If the target configuration file name matches the registered configuration file name, the corresponding file storage path and driver identifier are obtained according to the mapping relationship, the configuration data is saved to the file storage path, and a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier after successful saving. If the target configuration file name does not match the registered configuration file name, the debugging software receives a pass-through command sent through the pass-through protocol, parses the pass-through command to obtain the target driver identifier, and forwards the pass-through command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver converts the pass-through command into its own protocol format and sends it to the corresponding bus.

[0006] Further, the step of parsing the registration information of the configuration file and generating a mapping relationship includes: The configuration file registration information is parsed to generate the mapping relationship with the configuration file name as the key. The mapping value of the mapping relationship includes the file storage path, the driver identifier, and the configuration status flag. If the configuration request sent by the debugging software is received, the mapping relationship is queried according to the target configuration file name to obtain the corresponding file storage path, driver identifier and configuration status flag; When the configuration status is marked as valid, the configuration data is saved to the file storage path, and after successful saving, a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier. If the configuration status is marked as invalid, return an error response indicating that the driver is offline to the debugging software.

[0007] Furthermore, the step of sending a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving includes: The corresponding driver identifier is obtained from the mapping relationship based on the target configuration file name; A configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier. After receiving the configuration loading notification, the underlying protocol driver loads the target configuration file from the file storage path and returns the loading result. Update the configuration status flag corresponding to the target configuration file name in the mapping relationship based on the loading result.

[0008] Further, forwarding the transparent command to the corresponding underlying protocol driver based on the target driver identifier includes: Parse the protocol header of the transparent transmission command to extract the target driver identifier and the payload length check value. The integrity of the pass-through command is verified based on the load length verification value, and load data is extracted from the pass-through command that has passed the verification. Traverse the set of driver identifiers of registered underlying protocol drivers and match the target driver identifier; If a match is successful, the payload data is encapsulated into an inter-driver communication message via the inter-driver message bus and sent to the transparent receiving interface of the underlying protocol driver corresponding to the target driver identifier. If the matching fails, return an error response indicating that the driver is not registered to the debugging software.

[0009] Furthermore, the step of enabling the underlying protocol driver to convert the transparent command into its own protocol format and then send it to the corresponding bus includes: The underlying protocol driver obtains the payload data of the transparent command from the transparent receive interface; Based on the protocol type corresponding to the underlying protocol driver, a preset protocol conversion rule library is invoked to convert the payload data into a native command frame that conforms to the protocol type; The native command frame is written into the transmit buffer of the corresponding bus and sent to the target device mounted on the bus through the bus controller.

[0010] Furthermore, after generating the mapping relationship, the process also includes: Periodically send heartbeat detection requests to the registered underlying protocol driver; If no heartbeat response is received from the underlying protocol driver within a preset time, the configuration status in all mapping relationships corresponding to the underlying protocol driver will be marked as invalid. When the underlying protocol driver re-reports the configuration file registration information, the corresponding mapping relationship is updated according to the reported configuration file registration information, and the configuration status corresponding to the mapping relationship is marked as valid.

[0011] Furthermore, the cross-protocol configuration method supports bidirectional transparent transmission of configuration data, specifically including: When the pass-through command is a pass-through query request, the pass-through query request is routed to the corresponding underlying protocol driver according to the target driver identifier; The underlying protocol driver converts the transparent query request into the underlying protocol format and sends it to the corresponding bus, and receives the status report fed back by the target device mounted on the bus; The underlying protocol driver restores the status report to the standard protocol format and transmits it back to the debugging software through the transparent transmission channel of the standard protocol driver.

[0012] In a second aspect, embodiments of this application provide a cross-protocol configuration apparatus, including: The configuration registration module is configured to receive configuration file registration information reported by the underlying protocol driver, parse the configuration file registration information, and generate a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path. The request parsing module is configured to receive configuration requests sent by the debugging software, parse the configuration requests to obtain the target configuration file name and configuration data, and query the mapping relationship based on the target configuration file name; The standard forwarding module is configured to, when the target configuration file name matches the registered configuration file name, obtain the corresponding file storage path and driver identifier according to the mapping relationship, save the configuration data to the file storage path, and send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving; The pass-through forwarding module is configured to receive a pass-through command sent by the debugging software through the pass-through protocol when the target configuration file name does not match the registered configuration file name, parse the pass-through command to obtain the target driver identifier, and forward the pass-through command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver converts the pass-through command into its own protocol format and sends it to the corresponding bus.

[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 cross-protocol configuration method 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 cross-protocol configuration method as described in the first aspect.

[0015] This application's embodiments solve the problem of unified management of heterogeneous protocols by constructing a layered decoupled architecture of driver-initiated registration, mapping relationship routing, and transparent transmission channels. Specifically, the underlying protocol driver proactively reports registration information including driver identifier, configuration file name, and file storage path during the initialization phase, and generates mapping relationships in the standard protocol driver. This allows the host computer to accurately store and distribute configuration data based solely on a unified logical address without needing to be aware of underlying hardware differences. Simultaneously, through an intelligent switching mechanism between the transparent transmission protocol and the standard protocol, when the target configuration file name cannot match the mapping relationship, the original command is automatically tunneled to the underlying protocol driver for protocol conversion based on the target driver identifier. This ensures the standardization of standard configurations while maintaining the flexibility of proprietary protocols through the transparent transmission mechanism. Furthermore, combined with bidirectional transparent transmission query and heartbeat keep-alive mechanisms, real-time monitoring and dynamic management of non-standard protocol hardware status are achieved without changing the host computer interface specifications, reducing the complexity of system integration and maintenance costs. Attached Figure Description

[0016] Figure 1 This is a flowchart of a cross-protocol configuration method provided in an embodiment of this application; Figure 2 This is a flowchart of the mapping relationship generation and state management method provided in the embodiments of this application; Figure 3 This is a flowchart of the configuration loading notification and state synchronization method provided in the embodiments of this application; Figure 4 This is a flowchart of the transparent command forwarding method provided in the embodiments of this application; Figure 5 This is a flowchart of the transparent command protocol conversion and distribution method provided in the embodiments of this application; Figure 6 This is a flowchart of the driving heartbeat detection and state maintenance method provided in the embodiments of this application; Figure 7 This is a flowchart of the bidirectional transparent transmission method for configuration data provided in the embodiments of this application; Figure 8 This is a structural block diagram of a cross-protocol configuration device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure 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.

[0019] The technical solutions provided in this application are applied to gateway devices. A gateway device refers to a computing device deployed between upper-level computer debugging software and underlying field target devices, possessing multi-protocol adaptation, data routing, command forwarding, and file management capabilities. Gateway devices can be industrial control gateways, building automation controllers, IoT edge computing nodes, or embedded communication servers, etc. This application does not limit this; the gateway device runs a standard protocol driver and one or more underlying protocol drivers. A standard protocol driver is a software module running in the gateway device used for unified communication and interaction with the upper-level computer debugging software, providing standardized configuration and transparent transmission interfaces. An underlying protocol driver is a software module running in the gateway device used for protocol interaction with specific fieldbuses and mounted target devices, such as a DALI protocol driver, an RCU protocol driver, or other proprietary custom protocol drivers. Each underlying protocol driver can correspond to multiple specific protocol types and physical buses.

[0020] Figure 1 This is a flowchart of a cross-protocol configuration method provided in an embodiment of this application, such as... Figure 1As shown, this cross-protocol configuration method includes the following steps: Step 101: Receive the configuration file registration information reported by the underlying protocol driver, parse and process the configuration file registration information, and generate a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path.

[0021] The configuration file registration information refers to the metadata information that the underlying protocol driver actively reports to the standard protocol driver after initialization or startup, describing its configurable resources. The configuration file registration information includes at least the driver identifier, configuration file name, and file storage path. The driver identifier is a string or numeric code used to uniquely identify an underlying protocol driver within the gateway device, such as "dali_driver_01" or "rcu_driver_02". The configuration file name is the name of the configuration file that the underlying protocol driver expects to receive and load, such as "dali_lighting_config.json" or "rcu_hvac_params.xml". The file storage path is the absolute or relative path specified by the underlying protocol driver in the gateway device's local file system for storing the corresponding configuration file, such as " / config / dali / " or " / var / rcu / settings / ". The mapping relationship is a data structure used to establish the association between the configuration file name and the underlying protocol driver, so that the host computer only needs to provide the target configuration file name to locate the corresponding underlying protocol driver and its storage location.

[0022] In one embodiment, during the startup initialization process, the underlying protocol driver sends configuration file registration information to the standard protocol driver via the inter-driver message bus. The inter-driver message bus is a channel within the gateway device used for intra-process or inter-process communication between software modules; its implementation can be a shared memory queue, Unix domain socket, message middleware, or publish-subscribe bus. The configuration file registration information uses a preset message format. The message header includes an information type identifier, such as 0x01 indicating a registration request, and the message payload contains fields such as driver identifier, configuration file name, and file storage path. The standard protocol driver listens for configuration file registration information topics on the inter-driver message bus. Upon receiving the configuration file registration information reported by the underlying protocol driver, it parses and processes the information. This parsing process extracts the content of each field from the byte stream according to the preset message format specifications and performs validity checks, such as verifying whether the driver identifier is non-empty, whether the configuration file name conforms to file naming conventions, and whether the file storage path points to an existing directory. After successful verification, the standard protocol driver generates a mapping relationship in its own memory data structure or persistent database.

[0023] Step 102: Receive the configuration request sent by the debugging software, parse the configuration request to obtain the target configuration file name and configuration data, and query the mapping relationship based on the target configuration file name.

[0024] In one embodiment, the debugging software is an application running on a host computer or remote maintenance terminal, used for parameter configuration, status monitoring, debugging, and maintenance of the gateway device and its attached field target devices. The debugging software establishes a communication connection with the gateway device via a wired or wireless network, such as Ethernet, Wi-Fi, RS-485 to Ethernet, or a USB debugging channel. The configuration request is a request message sent by the debugging software to the standard protocol driver of the gateway device to distribute configuration data. The configuration request adopts a standard protocol format, such as encapsulation based on standard application layer protocols like JSON-RPC, HTTP REST, or MQTT. The standard protocol driver receives the configuration request through its own network listening interface and then parses and processes it. The parsing process includes two layers: protocol layer parsing and application layer parsing. Optionally, protocol layer parsing involves parsing the message header and payload data according to the selected standard communication protocol, such as HTTP or MQTT; application layer parsing extracts the target configuration file name and configuration data from the payload data. The target configuration file name is the name of the configuration file that the debugging software expects the configuration operation to target. It should be consistent with the configuration file name reported by the underlying protocol driver or have a preset mapping rule. The configuration data is the actual content to be written to the configuration file, which can be in the form of a JSON object, XML document, binary byte stream, or key-value pair sequence. After obtaining the target configuration file name, the standard protocol driver uses it as the query key to search the generated mapping relationship. The query is based on a key-value matching algorithm to search the mapping relationship data structure for a registered configuration file name that matches the target configuration file name.

[0025] Step 103: If the target configuration file name matches the registered configuration file name, obtain the corresponding file storage path and driver identifier according to the mapping relationship, save the configuration data to the file storage path, and send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving.

[0026] In this context, "matching" refers to the target configuration file name being completely identical to a registered configuration file name string in the mapping relationship, or being determined to be the same file after comparison using preset case-insensitive rules and alias rules.

[0027] In one embodiment, upon successful matching, the standard protocol driver reads the file storage path and driver identifier corresponding to the configuration file name from the mapping relationship. The standard protocol driver calls the file system interface to write the parsed configuration data into a file named after the target configuration file at the file storage path. The saving process includes creating or opening the target file, serializing the configuration data into a byte stream, writing the byte stream to a file buffer, calling a synchronous disk flush operation to ensure data persistence, and closing the file handle. After successful saving, the standard protocol driver sends a configuration loading notification to the underlying protocol driver corresponding to the driver identifier via the inter-driver message bus. The configuration loading notification is an asynchronous message informing the underlying protocol driver that its corresponding configuration file has been updated and needs to be reloaded. The configuration loading notification includes at least the target configuration file name and file storage path so that the underlying protocol driver can accurately locate the file to be loaded.

[0028] Step 104: If the target configuration file name does not match the registered configuration file name, receive the transparent transmission command sent by the debugging software through the transparent transmission protocol, parse the transparent transmission command to obtain the target driver identifier, and forward the transparent transmission command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver can convert the transparent transmission command into its own protocol format and send it to the corresponding physical bus.

[0029] In this context, a transparent transmission protocol refers to a tunnel communication protocol built on top of or independently of a standard protocol, used to carry protocol data. It does not parse the semantics of the payload data; it is only used for data routing and forwarding. A transparent transmission command refers to a data packet encapsulated using a transparent transmission protocol, containing a target driver identifier and payload data forwarded to the underlying protocol driver. The target driver identifier is the explicitly specified identifier in the transparent transmission command, indicating that the command should be processed by a specific underlying protocol driver.

[0030] In one embodiment, a mismatch occurs when no registered configuration file name corresponding to the target configuration file name is found in the mapping relationship. The data the debugging software expects to configure cannot be located to the specific underlying protocol driver through the standard configuration file routing mechanism, potentially involving non-standard or proprietary protocol instructions. In this case, the debugging software switches to pass-through mode and sends a pass-through command to the standard protocol driver via the pass-through protocol. Upon receiving the pass-through command, the standard protocol driver parses it, extracting the target driver identifier from the protocol header or payload prefix. Based on the target driver identifier, the standard protocol driver searches for the corresponding driver instance in the list of registered underlying protocol drivers and forwards the payload data of the pass-through command to the pass-through receiving interface of that underlying protocol driver via the inter-driver message bus. The pass-through receiving interface is a software interface in the underlying protocol driver specifically designed to receive pass-through data from the standard protocol driver, such as a callback function handle, message queue consumer, or event listener. After the underlying protocol driver obtains the payload data from the transparent receiving interface, it converts the payload data into its own protocol format that conforms to the protocol type according to its own protocol type, generates a native command frame, writes the native command frame into the transmit buffer of the corresponding physical bus, and finally sends it to the target device mounted on the physical bus through the bus controller.

[0031] As described above, receiving configuration file registration information reported by the underlying protocol driver and generating mapping relationships can establish an association index between configuration file names, driver identifiers, and file storage paths, providing a unified routing data foundation for configuration requests. Receiving configuration requests sent by debugging software and querying mapping relationships based on the target configuration file name enables standardized entry management and routing decisions for configuration requests. When a match is successful, the file storage path and driver identifier are obtained according to the mapping relationship, configuration data is saved, and a configuration loading notification is sent, enabling precise storage and loading triggering of configuration files through standard protocol paths. When a match fails, a pass-through command is received and forwarded to the corresponding underlying protocol driver, which can accommodate configuration distribution requirements of non-standard and proprietary protocols and achieve intelligent switching between standard and pass-through configurations.

[0032] Figure 2 This is a flowchart of the mapping relationship generation and state management method provided in the embodiments of this application, such as... Figure 2 As shown, this cross-protocol configuration method includes the following steps: Step 201: Parse the configuration file registration information to generate a mapping relationship with the configuration file name as the key. The mapping value of the mapping relationship includes the file storage path, driver identifier, and configuration status flag.

[0033] In this context, a key is an identifier used to uniquely index a record in a key-value pair data structure, such as a hash table, dictionary, or map. The mapped value is the data record associated with the key. Configuration status flags are markers used to indicate whether the current configuration file and its corresponding underlying protocol driver are in an available state. Their data type can be Boolean (e.g., true for valid, false for invalid); enumerated (e.g., ACTIVE for valid, INACTIVE for invalid); or integer (e.g., 0 for valid, 1 for invalid).

[0034] In one embodiment, the configuration file name string is used as the key, allowing debugging software to retrieve the corresponding configuration routing information simply by providing the target configuration file name when initiating a configuration request. In this embodiment, the mapping value is a composite data structure, containing at least three fields: file storage path, driver identifier, and configuration status flag. When generating the mapping relationship, the standard protocol driver creates a mapping table instance in memory, inserts the parsed configuration file name as the key into the mapping table, and associates the corresponding file storage path, driver identifier, and initial configuration status flag as mapping values ​​with the key.

[0035] Step 202: If a configuration request is received from the debugging software, the mapping relationship is queried according to the target configuration file name to obtain the corresponding file storage path, driver identifier and configuration status flag.

[0036] In one embodiment, after the debugging software initiates a configuration request, the standard protocol driver performs a parsing operation to obtain the target configuration file name. The standard protocol driver uses the target configuration file name as a query key to access the mapping relationship in the established mapping table. If the query matches, the standard protocol driver extracts the corresponding file storage path, driver identifier, and current configuration status flag from the mapping value.

[0037] Step 203: When the configuration status is marked as valid, save the configuration data to the file storage path, and send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving.

[0038] In one embodiment, when the configuration status is determined to be valid, the standard protocol driver writes the configuration data to the file storage path obtained from the mapping relationship. After the writing is completed, a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier through the inter-driver message bus, triggering the underlying protocol driver to reload the configuration file.

[0039] Step 204: If the configuration status is marked as invalid, return an error response indicating that the driver is offline to the debugging software.

[0040] In one embodiment, if the configuration status is determined to be in an invalid state, the standard protocol driver will no longer perform file saving and notification sending operations. Instead, it will directly return an error response to the debugging software, indicating that the underlying protocol driver cannot receive it normally. Upon receiving the error response, the debugging software will either display a message on the host computer interface indicating that the current target device is unreachable, or trigger a retry mechanism to wait for the underlying protocol driver to return to online status. The error response is a failure result message encapsulated in the same standard protocol format as the configuration request, which includes an error code and error description information.

[0041] The above-described process of parsing and processing the configuration file registration information and generating a mapping relationship with the configuration file name as the key establishes a structured association between the configuration file name, file storage path, driver identifier, and configuration status flag, providing routing information for configuration request queries. Querying the mapping relationship based on the target configuration file name to obtain the configuration status flag allows for predicting the driver's availability status before configuration distribution. Saving configuration data and sending a configuration loading notification when the configuration status flag is valid ensures the reliability of configuration data distribution to the online driver. Returning an error response indicating driver offline when the configuration status flag is invalid promptly blocks the distribution of invalid configurations, avoiding resource waste and operation timeouts.

[0042] Figure 3 This is a flowchart of the configuration loading notification and state synchronization method provided in the embodiments of this application, such as... Figure 3 As shown, this cross-protocol configuration method includes the following steps: Step 301: Obtain the corresponding driver identifier from the mapping relationship based on the target configuration file name.

[0043] In one embodiment, after the standard protocol driver completes the file saving operation of the configuration data, it needs to send a configuration loading notification to the corresponding underlying protocol driver. At this time, the standard protocol driver uses the name of the currently processed target configuration file as the query key to access the mapping relationship data structure in the mapping table again, and extracts the driver identifier field from the mapping value corresponding to the target configuration file name. The content of the driver identifier field is the unique identifier of the underlying protocol driver that should receive this configuration loading notification.

[0044] Step 302: Send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier. After receiving the configuration loading notification, the underlying protocol driver loads the target configuration file from the file storage path and returns the loading result.

[0045] In one embodiment, the standard protocol driver locates the corresponding underlying protocol driver handle or communication endpoint in the driver instance manager based on the acquired driver identifier. The standard protocol driver then constructs a configuration loading notification message. The message body of this configuration loading notification message includes at least the target configuration file name and file storage path; optionally, it may also include information such as the version number, timestamp, and checksum of the configuration data. The standard protocol driver sends the configuration loading notification message to the corresponding underlying protocol driver via the inter-driver message bus. The sending method can be a synchronous blocking call or an asynchronous non-blocking delivery, depending on the implementation mechanism of the inter-driver message bus. After receiving the configuration loading notification in the notification listening interface, the underlying protocol driver parses the notification message body and extracts the file storage path and target configuration file name. The underlying protocol driver calls the file system read interface to open the target configuration file from the file storage path and read the target configuration file content into a memory buffer. The underlying protocol driver parses the target configuration file content according to its own preset configuration parsing rules, such as JSON parsing, XML parsing, or binary structure parsing, and applies the parsed configuration data to its own runtime context, such as updating the device address table, adjusting the sampling threshold, or modifying the communication baud rate. During the loading and parsing process, the underlying protocol driver determines the loading result. Optionally, if the target configuration file is read successfully, parsing is error-free, and all configuration data is successfully applied, a loading success result is generated; if the file does not exist, reading fails, parsing errors occur, or some data is invalid, a loading failure result is generated, along with a failure reason code. The loading result is a data structure used to report the success or failure status of this configuration loading operation, typically including a result status code, error details, and a timestamp.

[0046] Step 303: Update the configuration status flag corresponding to the target configuration file name in the mapping relationship based on the loading result.

[0047] In one embodiment, the underlying protocol driver returns the loading result to the standard protocol driver via the inter-driver message bus. Upon receiving the loading result from the underlying protocol driver, the standard protocol driver parses the result status code. If the result status code indicates successful loading, the standard protocol driver updates the configuration status flag corresponding to the target configuration file name in the mapping relationship to a valid status, or keeps the valid status unchanged, and may optionally record the timestamp of the last successful loading. If the result status code indicates loading failure, the standard protocol driver may update the configuration status flag to an invalid status, or add a loading failure count field to the mapping value for subsequent fault diagnosis.

[0048] As described above, by retrieving the corresponding driver identifier from the mapping relationship based on the target configuration file name, the recipient of the configuration loading notification can be accurately located, avoiding mis-sending or missed notifications. Sending the configuration loading notification to the underlying protocol driver corresponding to the driver identifier can trigger the driver to actively reload the configuration file, realizing closed-loop control for configuration effectiveness. The underlying protocol driver loads the target configuration file from the file storage path and returns the loading result, which can synchronize the configuration data from persistent storage to the driver runtime context. Updating the configuration status flag in the mapping relationship based on the loading result can reflect the configuration synchronization status in real time, providing an accurate availability reference for configuration requests.

[0049] Figure 4 This is a flowchart of the transparent command forwarding method provided in the embodiments of this application, such as... Figure 4 As shown, this cross-protocol configuration method includes the following steps: Step 401: Parse the protocol header of the transparent transmission command and extract the target driver identifier and payload length check value.

[0050] The protocol header refers to a set of fixed-format fields located before the payload data in a transparent command message, used to describe the message's metadata. The protocol header conforms to the transparent communication specification between standard protocol drivers and debugging software.

[0051] In one embodiment, the protocol header includes the following fields, optionally: a start magic number field (2 bytes, used for frame synchronization), a protocol version field (1 byte), a command type field (1 byte, used to distinguish configuration distribution, query requests, etc.), a target driver identifier field (variable-length string, prefixed with a 1-byte length identifier), a payload length field (4 bytes, indicating the number of bytes of subsequent payload data), and a payload length checksum field (4 bytes, such as a CRC32 checksum or an Adler32 checksum). Upon receiving the pass-through command, the standard protocol driver reads and parses the protocol header from the byte stream according to the above field order and byte order, extracting the target driver identifier and the payload length checksum.

[0052] Step 402: Verify the integrity of the pass-through command based on the load length verification value, and extract the load data from the pass-through command that has passed the verification.

[0053] Integrity verification refers to verifying whether the received transparent transmission command message has undergone bit flipping, truncation, or tampering during transmission. Payload data refers to the actual business data carried in the transparent transmission command that needs to be forwarded to the underlying protocol driver. Its format is determined by the debugging software and the underlying protocol driver, and the standard protocol driver does not parse its semantics.

[0054] In one embodiment, after parsing the protocol header, the standard protocol driver obtains the actual byte length of the payload data indicated by the payload length field and calculates the actual checksum of the received payload data area, such as CRC32. The calculated actual checksum is compared with the payload length checksum extracted from the protocol header. If they match, the integrity check of the transparent command is deemed to have passed; if they do not match, the check is deemed to have failed, the standard protocol driver discards the transparent command, and returns a checksum error response to the debugging software. If the check passes, the standard protocol driver extracts the payload data from the transparent command message.

[0055] Step 403: Traverse the set of driver identifiers of the registered underlying protocol drivers and match the target driver identifier.

[0056] The driver identifier set refers to the list of driver identifiers of all currently registered and valid or invalid underlying protocol drivers collected and maintained by the standard protocol driver.

[0057] In one embodiment, the standard protocol driver performs a string comparison or numerical comparison between the extracted target driver identifier and each registered driver identifier in the driver identifier set. It then finds a driver identifier in the driver identifier set that completely matches the target driver identifier.

[0058] Step 404: If the match is successful, the payload data is encapsulated into an inter-driver communication message through the inter-driver message bus and sent to the transparent receiving interface of the underlying protocol driver corresponding to the target driver identifier.

[0059] Among them, the inter-driver communication message refers to the message format used to transmit data between various driver modules within the gateway device. It typically includes message type identifiers, such as transparent data type, standard protocol driver identifier, target driver identifier, and payload data field.

[0060] In one embodiment, upon successful matching, the standard protocol driver confirms that the underlying protocol driver corresponding to the target driver identifier exists in the current system. The standard protocol driver encapsulates the extracted payload data into an inter-driver communication message and sends the inter-driver communication message to the underlying protocol driver corresponding to the target driver identifier via the inter-driver message bus. The underlying protocol driver listens for and receives the inter-driver communication message on its transparent receiving interface, extracts the payload data from the message, and enters the protocol conversion and distribution process.

[0061] Step 405: If the matching fails, return an error response to the debugging software indicating that the driver is not registered.

[0062] In one embodiment, if a match fails—that is, if the target driver identifier does not appear in the set of registered driver identifiers—it indicates that the debugging software attempted to pass through commands to an unconnected, unstarted, or uninstalled underlying protocol driver. In this case, the standard protocol driver terminates the pass-through forwarding process and constructs an error response message indicating that the driver is not registered, returning it to the debugging software. The error response message includes an error code and error description, such as "DRIVER_NOT_REGISTERED, target driver identifier not registered," so that the debugging software can prompt the user to check the device connection status or driver configuration.

[0063] As described above, parsing the transparent command protocol header to extract the target driver identifier and payload length check value allows for rapid location of the command routing target and acquisition of integrity verification criteria. Verifying the integrity of the transparent command and extracting payload data based on the payload length check value ensures accurate forwarding of data. Traversing the set of registered driver identifiers to match the target driver identifier verifies the legality and reachability of the target driver. Upon successful matching, the payload data is forwarded to the transparent receiving interface via the inter-driver message bus, enabling tunneled transparent transmission of the original command. Upon failure to match, an error response indicating that the driver is not registered is returned, promptly informing the debugging software of the reason for the routing failure and facilitating troubleshooting.

[0064] Figure 5 This is a flowchart of the transparent command protocol conversion and distribution method provided in the embodiments of this application, such as... Figure 5 As shown, this cross-protocol configuration method includes the following steps: Step 501: The underlying protocol driver obtains the payload data of the transparent transmission command from the transparent transmission receiving interface.

[0065] In one embodiment, after receiving an inter-driver communication message forwarded by the standard protocol driver, the transparent receiving interface of the underlying protocol driver parses the message and extracts the payload data field. The payload data is the service data issued by the debugging software that needs to be further processed by the underlying protocol driver and sent to the physical bus. The underlying protocol driver temporarily stores the extracted payload data in an internal buffer, waiting for the protocol conversion stage.

[0066] Step 502: Based on the protocol type corresponding to the underlying protocol driver, call the preset protocol conversion rule library to convert the payload data into a native command frame that conforms to the protocol type.

[0067] The protocol type refers to the type identifier of the underlying physical bus or target device communication protocol adapted by the underlying protocol driver, such as DALI protocol type, RCU protocol type, Modbus protocol type, BACnet protocol type, or vendor-specific protocol type. The protocol conversion rule base refers to the set of rules stored in the internal or external configuration file of the underlying protocol driver, used to convert general payload data formats into native command frames of a specific protocol type. The rule base contains frame structure definitions, field encoding rules, address mapping tables, function code lookup tables, verification algorithms such as parity check, CRC8, and CRC16, and data field encapsulation rules for that protocol type. A native command frame refers to a bit sequence or byte array that conforms to the underlying physical bus communication protocol specification and can be directly sent by the bus controller.

[0068] In one embodiment, the underlying protocol driver loads the corresponding protocol conversion rule base module based on its own protocol type identifier. The underlying protocol driver then parses the semantics of the payload data, such as JSON-formatted key-value pairs or binary command codes, and converts the payload data into a native command frame conforming to the protocol type according to the rules defined in the rule base. For example, for the DALI protocol type, the native command frame can be a Manchester-encoded frame containing a 16-bit address field and an 8-bit command field; for the RCU protocol type, the native command frame can be a fixed-length or variable-length frame containing a frame header, device address, function code, data field, and CRC16 checksum field.

[0069] Step 503: Write the native command frame into the transmit buffer of the corresponding bus and send it to the target device mounted on the bus through the bus controller.

[0070] The transmit buffer refers to a queue or circular buffer located between the underlying protocol driver and the bus controller, used to temporarily store frame data to be transmitted. The bus controller refers to the hardware module or hardware abstraction layer driver in the gateway device that manages the physical bus interface, such as a CAN controller, DALI bus transceiver, or RS-485 transceiver. The target device refers to a field device with a unique device address that is located in the same physical bus topology as the underlying protocol driver, such as a DALI lighting fixture, RCU temperature controller, or sensor node.

[0071] In one embodiment, after completing the protocol conversion and obtaining the native command frame, the underlying protocol driver writes the native command frame into the transmit buffer in byte order. The write operation follows the first-in, first-out (FIFO) principle. If the buffer is full, the underlying protocol driver can choose to block and wait, discard old frames, or trigger a flow control mechanism. The underlying protocol driver reads the native command frame from the transmit buffer, calls the hardware transmit interface provided by the bus controller, such as write to the transmit register, DMA transfer initiation, or interrupt-triggered transmission, and outputs the bit stream of the native command frame to the physical bus cable. After the target device detects the native command frame matching its own address on the physical bus, it receives and parses the command frame and executes the corresponding configuration or control actions.

[0072] As described above, the underlying protocol driver obtains payload data from the transparent receive interface and can receive service data from the standard protocol driver; according to the protocol type, it calls the protocol conversion rule base to convert the payload data into native command frames, which can convert general data formats into bit sequences that conform to specific physical bus protocol specifications; the native command frames are written to the transmit buffer and sent to the target device through the bus controller, which can realize a complete protocol conversion link from software abstraction to physical signal output, ensuring that the transparent commands of the debugging software are ultimately accurately delivered to the field target device mounted on the bus.

[0073] Figure 6 This is a flowchart of the driving heartbeat detection and state maintenance method provided in the embodiments of this application, such as... Figure 6 As shown, this cross-protocol configuration method includes the following steps: Step 601: Periodically send heartbeat detection requests to the registered underlying protocol drivers.

[0074] In one embodiment, the standard protocol driver internally maintains a timer or scheduled task, for example, triggering a heartbeat detection process at fixed intervals. Upon each trigger, the standard protocol driver iterates through all currently registered underlying protocol driver identifiers and sends a heartbeat detection request to each underlying protocol driver. The heartbeat detection request is a lightweight probe message used to detect whether the underlying protocol driver is alive and whether the communication link is functioning correctly. The heartbeat detection request can be sent via the inter-driver message bus, and its message body includes a request sequence number and a timestamp for matching responses.

[0075] Step 602: If no heartbeat response is received from the underlying protocol driver within a preset time, mark the configuration status of all mapping relationships corresponding to the underlying protocol driver as invalid.

[0076] The preset time refers to the timeout period set for the heartbeat detection request, and the heartbeat response refers to the confirmation message of survival returned by the underlying protocol driver to the standard protocol driver after receiving the heartbeat detection request.

[0077] In one embodiment, the standard protocol driver starts a timeout timer for each heartbeat detection request. If a heartbeat response is received from the corresponding underlying protocol driver within a preset time, the driver is determined to be alive, and its configuration status in the mapping relationship is marked as valid. If no heartbeat response is received within the preset time, the standard protocol driver determines that the underlying protocol driver is offline or has failed. At this time, the standard protocol driver performs a batch update in the mapping relationship data structure. It searches for records in all mapping values ​​where the driver identifier field is equal to the offline driver identifier, and updates the configuration status of these records to invalid. This indicates that all configuration files managed by the underlying protocol driver are temporarily unconfigurable, preventing debugging software from repeatedly sending invalid configurations to the offline driver.

[0078] Step 603: If the underlying protocol driver re-reports the configuration file registration information, update the corresponding mapping relationship according to the reported configuration file registration information, and update the configuration status corresponding to the mapping relationship to a valid status.

[0079] In one embodiment, when the offline underlying protocol driver resumes operation, such as after a reboot or restoration of the communication link, it re-reports the configuration file registration information to the standard protocol driver. The re-reported configuration file registration information may contain the same configuration file name and file storage path as before, or it may have changed due to version updates or path adjustments. Upon receiving the re-reported configuration file registration information, the standard protocol driver searches for an existing record with the same configuration file name in the mapping relationship. If a match is found, the standard protocol driver updates the mapping value in that record. Specifically, it updates the file storage path to the latest reported path, maintains or updates the driver identifier, and changes the configuration status flag from invalid to valid. If no match is found, for example, if the driver has added a new configuration file, the standard protocol driver inserts a new key-value record into the mapping relationship and initializes the configuration status flag to valid. Thus, after completing re-registration, the underlying protocol driver's configuration service capabilities are restored, and the debugging software can continue to send configuration requests to the driver.

[0080] As described above, periodically sending heartbeat detection requests to registered underlying protocol drivers can proactively detect driver liveness and communication link quality; setting the configuration status to invalid when no heartbeat response is received within a preset time can promptly mark offline drivers and prevent invalid configurations from being repeatedly sent to unreachable drivers; updating the mapping relationship and restoring the configuration status to valid when the underlying protocol driver re-reports the configuration file registration information can achieve automatic reconnection and restoration of configuration service capabilities after driver failure recovery, ensuring the long-term stability of the system.

[0081] Figure 7 This is a flowchart of the bidirectional transparent transmission method for configuration data provided in the embodiments of this application, such as... Figure 7As shown, this cross-protocol configuration method includes the following steps: Step 701: When the pass-through command is a pass-through query request, route the pass-through query request to the corresponding underlying protocol driver based on the target driver identifier.

[0082] Among them, the transparent transmission query request refers to the transparent transmission command sent by the debugging software through the transparent transmission protocol to query the status or parameters of the underlying target device. The difference between it and the configuration request command lies in the command type identifier or the function code field in the load data.

[0083] In one embodiment, after receiving a pass-through command, the standard protocol driver parses the command type field in the protocol header or payload data prefix to determine whether the pass-through command is a pass-through query request. If it is a pass-through query request, the standard protocol driver extracts the target driver identifier from the pass-through command, traverses the set of registered driver identifiers, matches the target driver identifier, and if a match is successful, encapsulates the payload data of the pass-through query request into an inter-driver communication message through the inter-driver message bus and sends it to the pass-through receiving interface of the underlying protocol driver.

[0084] Step 702: The underlying protocol driver converts the transparent query request into the underlying protocol format and sends it to the corresponding bus, and receives the status report fed back by the target device mounted on the bus.

[0085] In one embodiment, after the underlying protocol driver obtains the payload data of the transparent query request from the transparent receive interface, it calls the protocol conversion rule base to convert the payload data into a native command frame conforming to its own protocol type, writes it to the transmit buffer, and sends it to the target device mounted on the physical bus through the bus controller. Upon receiving the query command, the target device performs the corresponding status acquisition or register read operation, encapsulates the acquired status data into a device response frame, and sends it back to the underlying protocol driver through the same physical bus. The underlying protocol driver reads the status report through the receive buffer of the bus controller. The status report is a data frame returned by the target device after responding to the query request, containing the device's current operating status, parameter values, or fault information.

[0086] Step 703: The underlying protocol driver restores the status report to the standard protocol format and sends it back to the debugging software through the transparent transmission channel of the standard protocol driver.

[0087] In one embodiment, upon receiving a status report, the underlying protocol driver invokes the reverse conversion rules in a pre-defined protocol conversion rule base to parse and reassemble the protocol fields in the status report into a standard protocol format. A standard protocol format refers to a common data format that the debugging software can recognize and parse, such as a JSON object or a standard XML structure. The underlying protocol driver encapsulates the restored standard protocol format data into an inter-driver communication message and sends it to the standard protocol driver via the inter-driver message bus. The standard protocol driver receives data through its transparent transmission channel. The transparent transmission channel is the uplink data path in the standard protocol driver used to process bidirectional transparent transmission data; it, together with the downlink transparent transmission forwarding path, constitutes a complete transparent transmission tunnel. The standard protocol driver further encapsulates the received standard protocol format data into an external communication protocol response message used by the debugging software and sends it back to the debugging software via the network interface. The debugging software parses the response message to obtain the real-time status information of the underlying target device and completes the bidirectional transparent transmission query.

[0088] As described above, when the transparent transmission command is a transparent transmission query request, it is routed to the corresponding underlying protocol driver based on the target driver identifier, which can accurately deliver the query command to the target driver; the underlying protocol driver converts the query request into the underlying protocol format and sends it out and receives the status report, which can complete the protocol conversion from general query to device status acquisition; the status report is restored to the standard protocol format and sent back to the debugging software through the transparent transmission channel, which can realize the standardized uplink feedback of device status data, complete the two-way transparent transmission closed loop, and enable the debugging software to obtain the real-time operating status of heterogeneous protocol devices under a unified interface.

[0089] Figure 8 This is a structural block diagram of a cross-protocol configuration device provided in an embodiment of this application. The cross-protocol configuration device is configured to execute the cross-protocol configuration method provided in the above embodiments, and has the corresponding functional modules and beneficial effects of executing the method, such as... Figure 8 As shown, the cross-protocol configuration device specifically includes: The configuration registration module 801 is configured to receive configuration file registration information reported by the underlying protocol driver, parse and process the configuration file registration information, and generate a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path. The request parsing module 802 is configured to receive configuration requests sent by the debugging software, parse the configuration requests to obtain the target configuration file name and configuration data, and query the mapping relationship based on the target configuration file name; The standard forwarding module 803 is configured to, when the target configuration file name matches the registered configuration file name, obtain the corresponding file storage path and driver identifier according to the mapping relationship, save the configuration data to the file storage path, and send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving. The transparent transmission forwarding module 804 is configured to receive a transparent transmission command sent by the debugging software through the transparent transmission protocol when the target configuration file name does not match the registered configuration file name, parse the transparent transmission command to obtain the target driver identifier, and forward the transparent transmission command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver can convert the transparent transmission command into its own protocol format and send it to the corresponding bus.

[0090] The above-described approach parses and processes the configuration file registration information reported by the underlying protocol driver, generating mapping relationships and establishing an association index between the configuration file name, file storage path, driver identifier, and configuration status flag, providing a unified routing data foundation for configuration requests. It also parses and processes configuration requests sent by the debugging software, querying the mapping relationship based on the target configuration file name. This enables standardized entry point management and routing decisions for configuration requests, eliminating the need for the host computer to perceive differences in the underlying protocols. Upon successful matching, the file storage path and driver identifier are obtained based on the mapping relationship, the configuration data is saved to the corresponding path, and a configuration loading notification is sent. Accurate storage and loading triggering of configuration files can be achieved through standard protocol paths. Upon failed matching, the target driver identifier in the pass-through command is parsed and forwarded to the corresponding underlying protocol driver, ensuring compatibility with configuration distribution requirements for non-standard and proprietary protocols. This solution, through a layered and decoupled architecture of driver-initiated registration, mapping relationship routing, and pass-through channels, can uniformly adapt to multiple types of heterogeneous protocol drivers without requiring separate configuration interfaces for each protocol. This ensures both the standardization of standard configurations and the flexibility of proprietary protocols, thereby reducing the complexity of system integration and maintenance costs.

[0091] In one possible embodiment, the registration module 801 is configured as follows: The configuration file registration information is parsed and processed to generate a mapping relationship with the configuration file name as the key. The mapping value of the mapping relationship includes the file storage path, driver identifier and configuration status flag. If a configuration request is received from the debugging software, the mapping relationship is queried based on the target configuration file name to obtain the corresponding file storage path, driver identifier, and configuration status flag; When the configuration status is marked as valid, the configuration data is saved to the file storage path, and a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier after successful saving. If the configuration status is marked as invalid, return an error response indicating that the driver is offline to the debugging software.

[0092] In one possible embodiment, the registration module 801 is further configured as follows: Periodically send heartbeat detection requests to the registered underlying protocol drivers; If no heartbeat response is received from the underlying protocol driver within a preset time, the configuration status in all mapping relationships corresponding to the underlying protocol driver will be marked as invalid. When the underlying protocol driver re-reports the configuration file registration information, the corresponding mapping relationship is updated according to the reported configuration file registration information, and the configuration status corresponding to the mapping relationship is marked as valid.

[0093] In one possible embodiment, the standard forwarding module 803 is specifically configured as follows: The corresponding driver identifier is obtained from the mapping relationship based on the target configuration file name; A configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier. After receiving the configuration loading notification, the underlying protocol driver loads the target configuration file from the file storage path and returns the loading result. Update the configuration status flag corresponding to the target configuration file name in the mapping relationship based on the loading results.

[0094] In one possible embodiment, the transparent forwarding module 804 is specifically configured as follows: Parse the protocol header of the pass-through command to extract the target driver identifier and payload length check value. The integrity of the pass-through command is verified based on the load length verification value, and the load data is extracted from the pass-through command that passes the verification. Iterate through the set of driver identifiers of the registered underlying protocol drivers and match the target driver identifier; If a match is successful, the payload data is encapsulated into an inter-driver communication message via the inter-driver message bus and sent to the transparent receiving interface of the underlying protocol driver corresponding to the target driver identifier. If the matching fails, return an error response to the debugging software indicating that the driver is not registered.

[0095] In one possible embodiment, the transparent forwarding module 804 is further configured as follows: The underlying protocol driver obtains the payload data of the transparent command from the transparent receive interface; Based on the underlying protocol driver's corresponding protocol type, a preset protocol conversion rule library is invoked to convert the payload data into a native command frame that conforms to the protocol type; The native command frame is written into the transmit buffer of the corresponding bus and then sent to the target device mounted on the bus through the bus controller.

[0096] In one possible embodiment, the transparent forwarding module 804 is further configured as follows: When the pass-through command is a pass-through query request, the pass-through query request is routed to the corresponding underlying protocol driver based on the target driver identifier. The underlying protocol driver converts the transparent query request into the underlying protocol format and sends it to the corresponding bus, and receives the status report from the target device mounted on the bus; The underlying protocol driver restores the status report to the standard protocol format and sends it back to the debugging software through the transparent transmission channel of the standard protocol driver.

[0097] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device includes a processor 901, a memory 902, an input device 903, and an output device 904.

[0098] The number of processors 901 can be one or more. Figure 9 Taking a processor 901 as an example; the processor 901, memory 902, input device 903, and output device 904 can be connected via a bus or other means. Figure 9 Taking a bus connection as an example, the memory 902, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the cross-protocol configuration method in this embodiment. The processor 901 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 902, thereby implementing the aforementioned cross-protocol configuration method. The input device 903 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 904 may include a display device such as a screen.

[0099] This application also provides a non-volatile storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform a cross-protocol configuration method described in the above embodiments. The method includes: receiving configuration file registration information reported by a lower-level protocol driver; parsing the configuration file registration information and generating a mapping relationship; the configuration file registration information includes a driver identifier, a configuration file name, and a file storage path; receiving a configuration request sent by debugging software; parsing the configuration request to obtain a target configuration file name and configuration data; querying the mapping relationship based on the target configuration file name; if the target configuration file name matches a registered configuration file name, obtaining the corresponding file storage path and driver identifier based on the mapping relationship; saving the configuration data to the file storage path; and sending a configuration loading notification to the lower-level protocol driver corresponding to the driver identifier after successful saving; if the target configuration file name does not match a registered configuration file name, receiving a pass-through command sent by the debugging software via a pass-through protocol; parsing the pass-through command to obtain a target driver identifier; and forwarding the pass-through command to the corresponding lower-level protocol driver based on the target driver identifier, so that the lower-level protocol driver converts the pass-through command into its own protocol format and sends it to the corresponding bus.

[0100] It is worth noting that in the above embodiments of the cross-protocol configuration device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of this application.

[0101] 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 cross-protocol configuration method, characterized in that, The configuration method, applied to gateway devices, includes: The system receives configuration file registration information reported by the underlying protocol driver, parses and processes the configuration file registration information, and generates a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path. The system receives a configuration request sent by the debugging software, parses the configuration request to obtain the target configuration file name and configuration data, and queries the mapping relationship based on the target configuration file name. If the target configuration file name matches the registered configuration file name, the corresponding file storage path and driver identifier are obtained according to the mapping relationship, the configuration data is saved to the file storage path, and a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier after successful saving. If the target configuration file name does not match the registered configuration file name, the debugging software receives a pass-through command sent through the pass-through protocol, parses the pass-through command to obtain the target driver identifier, and forwards the pass-through command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver converts the pass-through command into its own protocol format and sends it to the corresponding bus.

2. The cross-protocol configuration method according to claim 1, characterized in that, The step of parsing the registration information of the configuration file and generating a mapping relationship includes: The configuration file registration information is parsed to generate the mapping relationship with the configuration file name as the key. The mapping value of the mapping relationship includes the file storage path, the driver identifier, and the configuration status flag. If the configuration request sent by the debugging software is received, the mapping relationship is queried according to the target configuration file name to obtain the corresponding file storage path, driver identifier and configuration status flag; When the configuration status is marked as valid, the configuration data is saved to the file storage path, and after successful saving, a configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier. If the configuration status is marked as invalid, return an error response indicating that the driver is offline to the debugging software.

3. The cross-protocol configuration method according to claim 2, characterized in that, The step of sending a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving includes: The corresponding driver identifier is obtained from the mapping relationship based on the target configuration file name; A configuration loading notification is sent to the underlying protocol driver corresponding to the driver identifier. After receiving the configuration loading notification, the underlying protocol driver loads the target configuration file from the file storage path and returns the loading result. Update the configuration status flag corresponding to the target configuration file name in the mapping relationship based on the loading result.

4. The cross-protocol configuration method according to claim 1, characterized in that, The step of forwarding the transparent command to the corresponding underlying protocol driver based on the target driver identifier includes: Parse the protocol header of the transparent transmission command to extract the target driver identifier and the payload length check value. The integrity of the pass-through command is verified based on the load length verification value, and load data is extracted from the pass-through command that has passed the verification. Traverse the set of driver identifiers of registered underlying protocol drivers and match the target driver identifier; If a match is successful, the payload data is encapsulated into an inter-driver communication message via the inter-driver message bus and sent to the transparent receiving interface of the underlying protocol driver corresponding to the target driver identifier. If the matching fails, return an error response indicating that the driver is not registered to the debugging software.

5. The cross-protocol configuration method according to claim 1, characterized in that, The step of enabling the underlying protocol driver to convert the transparent command into its own protocol format and then send it to the corresponding bus includes: The underlying protocol driver obtains the payload data of the transparent command from the transparent receive interface; Based on the protocol type corresponding to the underlying protocol driver, a preset protocol conversion rule library is invoked to convert the payload data into a native command frame that conforms to the protocol type; The native command frame is written into the transmit buffer of the corresponding bus and sent to the target device mounted on the bus through the bus controller.

6. The cross-protocol configuration method according to claim 1, characterized in that, Following the generation of the mapping relationship, the following is also included: Periodically send heartbeat detection requests to the registered underlying protocol driver; If no heartbeat response is received from the underlying protocol driver within a preset time, the configuration status in all mapping relationships corresponding to the underlying protocol driver will be marked as invalid. When the underlying protocol driver re-reports the configuration file registration information, the corresponding mapping relationship is updated according to the reported configuration file registration information, and the configuration status corresponding to the mapping relationship is marked as valid.

7. The cross-protocol configuration method according to claim 1, characterized in that, The cross-protocol configuration method supports bidirectional transparent transmission of configuration data, specifically including: When the pass-through command is a pass-through query request, the pass-through query request is routed to the corresponding underlying protocol driver according to the target driver identifier; The underlying protocol driver converts the transparent query request into the underlying protocol format and sends it to the corresponding bus, and receives the status report fed back by the target device mounted on the bus; The underlying protocol driver restores the status report to the standard protocol format and transmits it back to the debugging software through the transparent transmission channel of the standard protocol driver.

8. A cross-protocol configuration device, characterized in that, include: The configuration registration module is configured to receive configuration file registration information reported by the underlying protocol driver, parse the configuration file registration information, and generate a mapping relationship. The configuration file registration information includes the driver identifier, configuration file name, and file storage path. The request parsing module is configured to receive configuration requests sent by the debugging software, parse the configuration requests to obtain the target configuration file name and configuration data, and query the mapping relationship based on the target configuration file name; The standard forwarding module is configured to, when the target configuration file name matches the registered configuration file name, obtain the corresponding file storage path and driver identifier according to the mapping relationship, save the configuration data to the file storage path, and send a configuration loading notification to the underlying protocol driver corresponding to the driver identifier after successful saving; The pass-through forwarding module is configured to receive a pass-through command sent by the debugging software through the pass-through protocol when the target configuration file name does not match the registered configuration file name, parse the pass-through command to obtain the target driver identifier, and forward the pass-through command to the corresponding underlying protocol driver according to the target driver identifier, so that the underlying protocol driver converts the pass-through command into its own protocol format and sends it to the corresponding bus.

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 cross-protocol configuration method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the cross-protocol configuration method as described in any one of claims 1-7.

Images