Multi-system compatible control method and device and central control equipment

Abstract

The invention discloses a multi-system compatible control method and device and central control equipment, and relates to the field of computers. The method comprises: when a control instruction for an access device is received, obtaining communication feature data and a dynamic instruction mapping table of the access device, the dynamic instruction mapping table comprising a mapping relationship between a device type and a protocol format; inputting the communication feature data into a device type identification model to obtain a target device type corresponding to the access device, and determining a target protocol format corresponding to the target device type; converting the control instruction into a specific protocol instruction in a target protocol format, and generating a driving script corresponding to the target protocol format; and a specific protocol instruction is sent to the access equipment through the driving script, so that intelligent control on the access equipment is realized. After the new device is accessed, the system automatically identifies the protocol and loads the driver, the configuration time is greatly shortened, and the problems of protocol fragmentation and high manual configuration cost in multi-system compatibility are solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a multi-system compatible control method, apparatus, and central control device. Background Art

[0002] In the field of intelligent control, with the rapid development of Internet of Things technology, the types of devices and communication protocols that need to be integrated in scenarios such as conference rooms, smart buildings, and industrial production lines are becoming increasingly diverse, covering audio and video systems, environmental control systems, and security systems. However, the current intelligent control field still faces severe challenges in multi-system compatibility:

[0003] 1. Traditional central control equipment is limited by insufficient protocol compatibility (for example, it only supports a single brand's proprietary protocol). Cross-domain devices must rely on multi-protocol conversion gateways, resulting in a sharp increase in system complexity and costs. 2. Manual configuration is inefficient. New device access requires reverse parsing of instructions, and single device configuration takes up to 3-5 hours, seriously slowing project delivery. 3. System stability risk: When multiple protocols are controlled concurrently, command conflicts and resource preemption can easily cause abnormal device responses.

[0004] In summary, existing technologies are limited by three bottlenecks: protocol fragmentation, high configuration costs, and low control reliability. This results in inefficient cross-system device collaboration and makes it difficult to meet the demands of the "Internet of Everything" in intelligent scenarios. Therefore, an integrated and compatible control solution is urgently needed that can dynamically adapt to multiple protocols, intelligently optimize control logic, and autonomously recover from anomalies. Summary of the Invention

[0005] The purpose of this application is to solve at least one of the above technical deficiencies.

[0006] In one aspect, an embodiment of the present application provides a multi-system compatible control method, which includes:

[0007] Upon receiving a control instruction for an access device, obtaining communication characteristic data of the access device and a dynamic instruction mapping table, the dynamic instruction mapping table including a mapping relationship between a device type and a protocol format;

[0008] Input the communication feature data into the device type identification model to obtain the target device type corresponding to the access device, and determine the target protocol format corresponding to the target device type based on the mapping relationship between the device type and the protocol format;

[0009] Convert the control instructions into specific protocol instructions of the target protocol format and generate the driver script corresponding to the target protocol format;

[0010] Specific protocol instructions are sent to the access device through the driver script corresponding to the target protocol format to achieve intelligent control of the access device.

[0011] Optionally, the communication characteristic data includes the protocol handshake signal, the response time of the control instruction, the data packet length corresponding to the control instruction and the device identification of the access device. The device identification information includes at least one of the EDID data of the access device, the MAC address of the network device and the manufacturer's private identification code of the access device. The EDID data includes the manufacturer identification and resolution parameters.

[0012] Optionally, after sending a specific protocol instruction to the access device through a driver script corresponding to the target protocol format, the method further includes:

[0013] If no response signal corresponding to a specific protocol instruction is received, a multi-level exception control mechanism is triggered to achieve intelligent control of the access device.

[0014] Optionally, trigger the multi-level exception control mechanism in at least one of the following ways to implement intelligent control of access devices:

[0015] Convert specific protocol instructions into alternative instructions in the target protocol format and adjust the retry interval;

[0016] Determine an associated protocol format corresponding to the target protocol format, and convert the control instruction into a specific protocol instruction in the associated protocol format;

[0017] Trigger the backup control mode of the physical layer and generate an alarm log.

[0018] Optionally, the dynamic instruction mapping table is a JSON format data structure. Each unified control semantics is associated with multiple protocol instructions, and priority rules and retry strategies are defined. The dynamic instruction mapping table supports user-defined extensions and generates instruction mapping relationships by dragging and dropping protocol fields through a graphical interface.

[0019] Optionally, the retry interval of the retry policy is determined by the following formula:

[0020]

[0021] Where interval is the retry interval, base is the initial interval, historical success rate 1 is the success rate of the last 10 instructions of the current protocol, historical success rate is the benchmark success rate, α is the randomization coefficient, rand(0,1) is a uniform random number between 0 and 1, and attempt is the current number of retries.

[0022] On the other hand, an embodiment of the present application provides a multi-system compatible control device, the device comprising:

[0023] Feature collection module, used to obtain communication feature data and dynamic instruction mapping table of access devices in real time;

[0024] The edge computing unit is used to deploy a device type recognition model and identify the target device type corresponding to the access device;

[0025] The instruction mapping engine is used to determine the target protocol format corresponding to the target device type according to the dynamic instruction mapping table, and convert the control instruction into a specific protocol instruction in the target protocol format and send it to the access device;

[0026] The exception handling module is used to trigger the multi-level exception control mechanism and record fault information when no response signal corresponding to a specific protocol instruction is received.

[0027] Optionally, the edge computing unit is an embedded AI chip that supports model inference in the TensorFlow Lite framework.

[0028] In another aspect, an embodiment of the present application provides a central control device that performs a multi-system compatible control method, the central control device comprising a hardware layer, a protocol conversion layer, and a control layer;

[0029] The hardware layer includes plug-in interface boards and interface circuits. The protocol conversion layer includes a dynamic protocol library with built-in connectable device protocols and dynamic instruction mapping tables. The control layer includes a device type identification model, and automatically confirms the protocol type of the access device based on the type identification model, and dynamically loads the corresponding driver to realize the linkage of the access device.

[0030] Optionally, the plug-in interface board communicates with the main control unit through the backplane bus. The interface circuit has optocoupler isolation and magnetic isolation technology. The dynamic protocol library includes preset protocol modules and user-defined protocol modules, and supports the use of protocol reverse tools to capture device signals and generate driver scripts.

[0031] In another aspect, an embodiment of the present application provides an electronic device, including a processor and a memory:

[0032] The memory is configured to store machine-readable instructions, which, when executed by the processor, cause the processor to perform any one of the multi-system compatible control methods.

[0033] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0034] In an embodiment of the present application, when a control instruction for an access device is received, the corresponding target protocol format can be identified based on the device type identification model and the dynamic instruction mapping table, and then the control instruction is converted into a specific protocol instruction in the target protocol format, and a corresponding driver script is generated to send the specific protocol instruction to the access device to achieve intelligent control of the access device. In other words, through the logic of device identification plus data drive and instruction optimization in this application, the complex multi-protocol adaptation problem can be converted into a configurable data-driven model, thereby solving the core pain points of high device heterogeneity and difficult abnormal recovery in multi-protocol control, so that it can be flexibly integrated into any project plan without destroying the original system architecture, improving the overall intelligent experience, and forming a unique competitive advantage of "full-scene adaptation".

[0035] In an embodiment of the present application, when the access device receives a specific protocol instruction, it can trigger a multi-level exception control mechanism to achieve intelligent control of the access device. In this process, exception recovery can be expanded from a single protocol retry to multi-level collaboration across protocols and physical layers, thereby improving system robustness. Retry parameters can be dynamically calculated based on historical data to avoid the overfitting problem of fixed strategies. At the same time, exception handling and equipment health management are deeply integrated to achieve full-link automated maintenance from fault recovery, root cause analysis to preventive maintenance.

[0036] In this application, since the dynamic instruction mapping table uses the JSON format data structure, it supports dynamic expansion. New protocols only need to add entries without modifying the core code. The priority and retry parameters can be flexibly adjusted according to the device type. At the same time, multi-protocol instructions are executed in layers to avoid global loss of control caused by a single protocol failure.

[0037] In this application, dynamic base adjustment and randomization factors are introduced into the traditional method of determining the retry interval, which can avoid conflicts caused by simultaneous retry of multiple devices, reduce the probability of simultaneous retry of multiple devices, and shorten the backoff interval in scenarios with a higher success rate, thereby improving real-time performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0039] Figure 1 A flowchart of a multi-system compatible control method provided in an embodiment of the present application;

[0040] Figure 2A schematic diagram of the structure of a central control device provided in an embodiment of the present application;

[0041] Figure 3 A schematic diagram of a multi-system compatible control device provided in an embodiment of the present application;

[0042] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and are not to be construed as limiting the present invention.

[0044] It will be understood by those skilled in the art that, unless expressly stated otherwise, the singular forms "a", "an", "said" and "the" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. In addition, "connected" or "coupled" as used herein may include wireless connections or wireless couplings. The term "and / or" used herein includes all or any units and all combinations of one or more associated listed items.

[0045] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0046] In the field of intelligent control, with the rapid development of Internet of Things technology, the types of devices and communication protocols that need to be integrated in scenarios such as conference rooms, smart buildings, and industrial production lines are becoming increasingly diverse, covering audio and video systems (such as HDMI-CEC and Dante), environmental control systems (such as KNX and Modbus), and security systems (such as ONVIF and SIP). However, existing technologies still have significant shortcomings in multi-system compatible control:

[0047] 1. Insufficient protocol compatibility: Traditional central control equipment typically supports only a limited number of protocols (such as a single brand's proprietary protocol or a small number of common protocols), making it difficult to cover cross-domain devices. For example, if a smart conference room needs to simultaneously control a projector using the HDBaseT protocol, a sound system based on the Dante protocol, and lighting equipment using the KNX protocol, multiple protocol conversion gateways must be deployed, resulting in a surge in system complexity and costs.

[0048] 2. Inefficient manual configuration: When connecting a new device, integrators must manually analyze its communication protocol (e.g., reverse engineering infrared codes and writing serial port command scripts), taking up to 3-5 hours to configure a single device. For example, a new LED display screen uses a proprietary HDMI-CEC instruction set, requiring additional development resources to complete driver adaptation, significantly slowing project delivery. Alternatively, a fixed protocol library is used for device control, but this lacks dynamic expansion capabilities and cannot adapt to new devices without pre-configured protocols, forcing manual and repetitive development of underlying drivers.

[0049] 3. System stability risk: When multiple protocols are concurrently controlled, command conflicts and resource preemption can easily lead to abnormal device responses. For example, in a smart building scenario, bus contention between KNX lighting control and Modbus air conditioning commands can cause light flickering or temperature control failures. Fault tracing is also difficult, and system availability is less than 95%.

[0050] Based on this, the present application provides a multi-system compatible control method, device and equipment, aiming to solve the above technical problems of the prior art.

[0051] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0052] Specifically, such as Figure 1 As shown, the method may include:

[0053] Step S101: upon receiving a control instruction for an access device, obtaining communication characteristic data and a dynamic instruction mapping table of the access device, wherein the dynamic instruction mapping table includes a mapping relationship between a device type and a protocol format.

[0054] Alternatively, an access device may refer to a conference system (LED display, sound pickup, sound reinforcement, etc.) or an intelligent system (lighting, curtains, etc.) connected to the central control device. Accordingly, to intelligently control an access device based on the central control device, a control instruction for the access device can be triggered. The control instruction includes the access device identifier and a specific control method. For example, if the specific control method is to open the curtains, the identifier identifies the specific device.

[0055] Correspondingly, after receiving the control instruction, the communication characteristic data corresponding to the access device and the pre-configured dynamic instruction mapping table can be obtained according to the identifier included in the control instruction, which includes the mapping relationship between the device type and the protocol format, that is, the protocol format corresponding to each device type is marked.

[0056] In an optional embodiment of the present application, the communication characteristic data includes a protocol handshake signal, a response time of a control instruction, a data packet length corresponding to the control instruction, and a device identification of the access device; the device identification information includes at least one of the EDID data of the access device, the MAC address of the network device, and the manufacturer's private identification code of the access device; and the EDID data includes a manufacturer identification and resolution parameters.

[0057] Optionally, the communication characteristic data of each device may be acquired when the device is first connected and then stored in association with the device. The communication characteristic data may specifically include a handshake signal, a control command response time, a data packet length corresponding to the control command, and a device identifier of the connected device. The device identifier may be at least one of the EDID data of the connected device, the MAC address of the network device, and the manufacturer's private identification code of the connected device. The EDID data may specifically include a manufacturer identifier and resolution parameters.

[0058] Step S102: input the communication feature data into a device type identification model to obtain a target device type corresponding to the access device, and determine a target protocol format corresponding to the target device type based on a mapping relationship between the device type and the protocol format.

[0059] Optionally, after acquiring the communication characteristic data of the access device, the characteristic data can be input into a pre-trained device type recognition model. Accordingly, the device type recognition model can output the device type corresponding to the access device (i.e., the target device type), and then determine the protocol format corresponding to the target device type (i.e., the target protocol format) based on the mapping relationship between device types and protocol formats in the pre-acquired dynamic instruction mapping table.

[0060] The device type identification model can be a multimodal feature fusion network that processes protocol features, timing features, and device identification separately, achieving cross-modal information complementation through a feature fusion layer. Specifically, the device type identification model can include a protocol feature branch, a timing feature branch, a device identification branch, and a feature fusion and classification layer.

[0061] Among them, the input of the protocol feature branch (CNN+Transformer) is the protocol handshake signal (binary stream, such as Hex-encoded Modbus / TCP message). The included Embedding layer maps the byte value (0-255) to a 128-dimensional vector. The convolution kernel size of the 1D-CNN layer is 3, 5, and 7, which is used to capture local protocol syntax features. The output channel is 64. The multi-head attention layer captures the long-range dependency of the protocol and converts the data to 128. Finally, the global average pooling process is performed to obtain the protocol feature vector (128 dimensions).

[0062] The input of the temporal feature branch (LSTM) is the instruction response time series (such as the delay [ms] of the last 10 instructions). Specifically, the delay time is normalized to the range [0, 1]. The number of hidden units in the BiLSTM layer is 64, and then bidirectional features are output. The attention mechanism calculates the weight of each time step and performs weighted summation to obtain a temporal feature vector (64 dimensions).

[0063] The input of the device identification branch (Embedding+FC) is the device identification (manufacturer ID, MAC address and other categorical data). Specifically, the Embedding layer maps the discrete ID into a 32-dimensional vector, and obtains the device identification feature vector (64 dimensions) through the fully connected layer and the ReLU activation layer.

[0064] The feature fusion and classification layer concatenates the three feature vectors (i.e., device identification feature vector, timing feature vector, and protocol feature vector), and then obtains the final output result by fusing the fully connected layer and the classification output layer.

[0065] Among them, the corresponding training data volume when training the device type recognition model can be 10,000+ device samples (covering 200+ brands), and the classification accuracy and inference speed both meet the set requirements, such as the classification accuracy reaches 98.7% and the inference speed is <5ms.

[0066] Step S103: convert the control instruction into a specific protocol instruction in the target protocol format, and generate a driver script corresponding to the target protocol format.

[0067] Optionally, after obtaining the protocol format corresponding to the device type corresponding to the access device, the control instructions can be converted into specific protocol instructions of the target protocol format, that is, the unified control semantics (such as "adjust the light to 50% brightness") are converted into specific protocol instructions (Dimming 50% of KNX or Arc 128 of DALI), etc., and then a driver script corresponding to the target protocol format is generated.

[0068] Step S104: Send specific protocol instructions to the access device through a driver script corresponding to the target protocol format to achieve intelligent control of the access device.

[0069] Optionally, after generating a driver script corresponding to the target protocol format, specific protocol instructions can be sent to the access device based on the driver script, thereby realizing intelligent control of the access device.

[0070] In an optional embodiment of the present application, after sending a specific protocol instruction to the access device through a driver script corresponding to the target protocol format, the method further includes:

[0071] If no response signal corresponding to a specific protocol instruction is received, a multi-level exception control mechanism is triggered to achieve intelligent control of the access device.

[0072] Optionally, after a specific protocol instruction is sent to the access device, if the access device receives the specific protocol instruction, it will return a response signal corresponding to the specific protocol instruction. If no response signal is received at this time, it means that the current instruction transmission has failed. At this time, a multi-level exception control mechanism can be triggered to ensure that intelligent control of the access device can be achieved.

[0073] In an optional embodiment of the present application, a multi-level exception control mechanism is triggered by at least one of the following methods to achieve intelligent control of access devices:

[0074] Convert specific protocol instructions into alternative instructions in the target protocol format and adjust the retry interval;

[0075] Determine an associated protocol format corresponding to the target protocol format, and convert the control instruction into a specific protocol instruction in the associated protocol format;

[0076] Trigger the backup control mode of the physical layer and generate an alarm log.

[0077] Optionally, different control methods may be included when triggering the multi-level exception control mechanism. Applicable methods are described in detail below.

[0078] 1. The specific protocol instructions can be converted into backup instructions in the target protocol format and the retry interval can be adjusted. Adjusting the retry interval refers to dynamically adjusting the retry interval. The rules for dynamically adjusting the retry interval can include calculating the exponential backoff time based on the historical success rate. The initial retry interval of the device is 200ms, and the maximum number of retries is 3. At this time, if there are continuous failures, the retry interval is increased according to the formula interval = base × 2^(attempt-1), where base = 200ms and attempt is the current number of retries.

[0079] 2. You can also determine the associated protocol format corresponding to the target protocol format, and then convert the control instructions into specific protocol instructions in the associated protocol format. The rules for determining the associated protocol format are determined based on priority. In this case, it is necessary to predefine a protocol priority list based on device type (such as KNX>DALI>Infrared), then evaluate the protocol communication quality (such as packet loss rate and latency) in real time, and dynamically select the optimal protocol as the associated protocol format based on the protocol communication quality. Finally, the control instructions are converted into specific protocol instructions that determine the optimal protocol format.

[0080] 3. It can also trigger backup control modes at the physical layer and generate an alarm log. These backup control modes can include sending pre-recorded infrared remote control codes, directly powering the device on and off via relays, enabling GPIO pins to output pulse signals, and driving the device. The generated alarm log can include the abnormal device identification, protocol type, failed instruction content, records of each level of abnormality handling, final recovery status, and recommended maintenance suggestions (e.g., "KNX bus voltage abnormality, recommended line inspection").

[0081] Among them, in order to better ensure real-time control of access devices, the device health score can be updated according to the exception processing results. When the score is lower than the threshold, a predictive maintenance work order is automatically triggered, thereby ensuring that maintenance can be carried out according to the predictive maintenance work order when an exception occurs.

[0082] In an embodiment of the present application, when the access device receives a specific protocol instruction, it can trigger a multi-level exception control mechanism to achieve intelligent control of the access device. In this process, exception recovery can be expanded from a single protocol retry to multi-level collaboration across protocols and physical layers, thereby improving system robustness. Retry parameters can be dynamically calculated based on historical data to avoid the overfitting problem of fixed strategies. At the same time, exception handling and equipment health management are deeply integrated to achieve full-link automated maintenance from fault recovery, root cause analysis to preventive maintenance.

[0083] In an optional embodiment of the present application, the dynamic instruction mapping table is a JSON format data structure, each unified control semantics is associated with multiple protocol instructions, and defines priority rules and retry strategies.

[0084] Optionally, the dynamic instruction mapping table adopts the JSON format data structure, and each unified control semantics is associated with multiple protocol instructions. Multiple protocol instructions can define priority rules and retry strategies. In other words, the dynamic instruction mapping table can transform complex multi-protocol adaptation problems into a configurable data-driven model through structured protocol description and strategic control logic, thereby realizing real-time control of access devices.

[0085] In this application, since the dynamic instruction mapping table uses the JSON format data structure, it supports dynamic expansion. New protocols only need to add entries without modifying the core code. The priority and retry parameters can be flexibly adjusted according to the device type. At the same time, multi-protocol instructions are executed in layers to avoid global loss of control caused by a single protocol failure.

[0086] For example, for smart conference room lighting control, if you want to adjust the lights to 50% brightness, you need to be compatible with the three protocol formats of KNX, DALI and infrared. At this time, you can select the KNX instruction GroupWrite1 / 1 / 1 0x32 with priority 1 according to the dynamic instruction mapping table. If the KNX bus does not respond (timeout 200ms), it will trigger an exponential backoff retry (first 400ms). When three retries fail, it will automatically switch to the DALI instruction Arc 128 with priority 2 and retry the DALI instruction 5 times (linear interval 100ms→500ms). If it still fails, the infrared code 0xA1B2C3D4 will be finally enabled. When infrared control is successful, the system will log: "KNX / DALI protocol exception, recovered by infrared backup instruction."

[0087] In an optional embodiment of the present application, the retry interval of the retry strategy is determined by the following formula:

[0088]

[0089] Where interval is the retry interval, base is the initial interval, historical success rate 1 is the success rate of the last 10 instructions of the current protocol, historical success rate is the benchmark success rate, α is the randomization coefficient, rand(0,1) is a uniform random number between 0 and 1, and attempt is the current number of retries.

[0090] In this application, dynamic base adjustment and randomization factors are introduced into the traditional method of determining the retry interval, which can avoid conflicts caused by simultaneous retry of multiple devices, reduce the probability of simultaneous retry of multiple devices, and shorten the backoff interval in scenarios with a higher success rate, thereby improving real-time performance.

[0091] It is understandable that the central control device provided in the embodiment of the present application performs the multi-system compatible control method can be performed by the central control device, such as Figure 2 As shown, the central control device includes a hardware layer, a protocol conversion layer and a control layer;

[0092] The hardware layer includes plug-in interface boards and interface circuits. The protocol conversion layer includes a dynamic protocol library with built-in connectable device protocols and dynamic instruction mapping tables. The control layer includes a device type identification model, and automatically confirms the protocol type of the access device based on the type identification model, and dynamically loads the corresponding driver to realize the linkage of the access device.

[0093] In an optional embodiment of the present application, the plug-in interface board communicates with the main control unit through the backplane bus, the interface circuit has optocoupler isolation and magnetic isolation technology, the dynamic protocol library includes preset protocol modules and user-defined protocol modules, and supports the capture of device signals and generation of driver scripts through protocol reverse tools.

[0094] Optionally, the hardware layer of the central control device is used for physical modular interface design, including plug-in interface boards and interface circuits, integrating RS-485, KNX, TCP / IP, HDMI, IR, Zigbee and other interface modules, communicating with the main control unit through the backplane bus, supporting plug-and-play adaptation of different devices, and the interface circuit also has optocoupler isolation and magnetic isolation technology. It can be equipped with FPGA chips to process high-speed signal conversion (such as HDMI→SDVoE, analog audio→Dante), and prevent interference from strong and weak current systems through electrical isolation circuits (such as KNX strong current control and RS-485 weak current communication isolation). It also has edge computing capabilities, and is equipped with embedded AI chips of the same specifications (such as Huawei Ascend, NVIDIA Jetson), which locally handle protocol parsing and device status prediction. For example, equipment failures (such as air conditioning compressor abnormalities) can be predicted by analyzing current fluctuations.

[0095] The protocol layer is used for dynamic adaptation and intelligent mapping. It has a built-in dynamic protocol library covering 300+ mainstream device protocols (such as Crestron, KNX, ONVIF, Modbus). The dynamic protocol library captures device commands (such as infrared codes and serial port commands) through reverse engineering tools, automatically generates driver scripts, and supports Lua / Python scripts to customize niche protocols (such as industrial PLC control logic).

[0096] The control layer includes a device abstraction layer, which maps physical devices to virtual objects (e.g., "lighting group 1" = KNX address 1.1.1 + DALI address 002). It also features a logic engine that implements scene-based linkage rules (e.g., "conference mode" triggers dimming of lights, turning on the projector, and activating the microphone). It also provides standardized APIs, such as RESTful APIs or SDKs, for third-party systems to call (e.g., a smart building platform controls conference room equipment via APIs). It also offers multiple interaction methods, supporting touch screens, voice assistants (e.g., domestically developed semantic parsing), and mobile apps for unified operation.

[0097] Optionally, central control equipment can utilize bypass access technology during system integration, bridging legacy systems via an external gateway (e.g., a KNX to TCP / IP gateway to integrate legacy building equipment), eliminating the need for wiring modifications. For example, this allows legacy analog cameras to be connected to an IP surveillance system via an A / D converter. The system also features hot-swappable and auto-discovery capabilities, discovering new devices through IP scanning and signal sniffing (e.g., Bluetooth broadcasts). Upon insertion, the system automatically loads drivers and completes configuration (based on actual data) within 30 minutes, achieving plug-and-play operation.

[0098] The embodiment of the present application provides a multi-system compatible control device, such as Figure 3 As shown, the control device 30 may include: a feature acquisition module 301, an edge computing unit 302, an edge computing unit 303 and an exception handling module 304, wherein:

[0099] Feature collection module, used to obtain communication feature data and dynamic instruction mapping table of access devices in real time;

[0100] An edge computing unit, configured to deploy a device type identification model and identify a target device type corresponding to the access device;

[0101] An instruction mapping engine, configured to determine a target protocol format corresponding to the target device type according to the dynamic instruction mapping table, and convert the control instruction into a specific protocol instruction in the target protocol format and send the result to the access device;

[0102] The exception handling module is used to trigger a multi-level exception control mechanism and record fault information when a response signal corresponding to the specific protocol instruction is not received.

[0103] Optionally, the edge computing unit is an embedded AI chip that supports model reasoning of the TensorFlow Lite framework.

[0104] Optionally, the communication characteristic data includes a protocol handshake signal, the response time of the control instruction, the data packet length corresponding to the control instruction, and the device identification of the access device; the device identification information includes at least one of the EDID data of the access device, the MAC address of the network device, and the manufacturer's private identification code of the access device; and the EDID data includes the manufacturer identification and resolution parameters.

[0105] Optionally, the exception handling module is specifically configured to:

[0106] After the specific protocol instruction is sent to the access device through the driver script corresponding to the target protocol format, if no response signal corresponding to the specific protocol instruction is received, a multi-level exception control mechanism is triggered to achieve intelligent control of the access device.

[0107] Optionally, the exception handling module triggers a multi-level exception control mechanism in at least one of the following ways to implement intelligent control of the access device:

[0108] Converting the specific protocol instruction into a backup instruction in the target protocol format and adjusting a retry interval;

[0109] Determining an associated protocol format corresponding to the target protocol format, and converting the control instruction into a specific protocol instruction of the associated protocol format;

[0110] Trigger the backup control mode of the physical layer and generate an alarm log.

[0111] Optionally, the dynamic instruction mapping table is a JSON format data structure, each unified control semantics is associated with multiple protocol instructions, and priority rules and retry strategies are defined; the dynamic instruction mapping table supports user-defined extensions, and generates instruction mapping relationships by dragging and dropping protocol fields through a graphical interface.

[0112] Optionally, the retry interval of the retry policy is determined by the following formula:

[0113]

[0114] Where interval is the retry interval, base is the initial interval, historical success rate 1 is the success rate of the last 10 instructions of the current protocol, historical success rate is the benchmark success rate, α is the randomization coefficient, rand(0,1) is a uniform random number between 0 and 1, and attempt is the current number of retries.

[0115] A multi-system compatible control device of this embodiment can execute a multi-system compatible control method shown in the embodiment of this application. The implementation principle is similar and will not be repeated here.

[0116] An embodiment of the present application provides an electronic device, which includes: a processor; and a memory, wherein the memory is configured to store machine-readable instructions, which, when executed by the processor, enable the processor to execute a multi-system compatible control method.

[0117] The present application embodiment provides an electronic device, such as Figure 4 As shown, Figure 4 The electronic device shown includes a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, for example, via a bus 2002. Optionally, the electronic device 2000 may further include a transceiver 2004. It should be noted that in practical applications, the number of transceivers 2004 is not limited to one, and the structure of the electronic device 2000 does not constitute a limitation on the embodiments of the present application.

[0118] Processor 2001 may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0119] The bus 2002 may include a path for transmitting information between the above components. The bus 2002 may be a PCI bus or an EISA bus, etc. The bus 2002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0120] The memory 2003 may be a ROM or other type of static storage device that can store static information and instructions, a RAM or other type of dynamic storage device that can store information and instructions, or an EEPROM, a CD-ROM or other optical disk storage, an optical disc storage (including a compact disc, a laser disc, an optical disc, a digital versatile disc, a Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0121] The memory 2003 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 2001. The processor 2001 is used to execute the application code stored in the memory 2003 to implement Figure 3 The illustrated embodiment provides an operation of a multi-system compatible control device.

[0122] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

Claims

1. A multi-system compatible control method, characterized in that: include: Upon receiving a control instruction for an access device, obtaining communication characteristic data and a dynamic instruction mapping table of the access device, the dynamic instruction mapping table including a mapping relationship between a device type and a protocol format; Inputting the communication characteristic data into a device type identification model to obtain a target device type corresponding to the access device, and determining a target protocol format corresponding to the target device type based on a mapping relationship between device type and protocol format; Convert the control instruction into a specific protocol instruction of the target protocol format, and generate a driver script corresponding to the target protocol format; The specific protocol instruction is sent to the access device through a driver script corresponding to the target protocol format to achieve intelligent control of the access device.

2. The method according to claim 1, characterized in that The communication characteristic data includes the protocol handshake signal, the response time of the control instruction, the data packet length corresponding to the control instruction and the device identification of the access device. The device identification information includes at least one of the EDID data of the access device, the MAC address of the network device and the manufacturer's private identification code of the access device. The EDID data includes the manufacturer identification and resolution parameters.

3. The method according to claim 2, characterized in that After sending the specific protocol instruction to the access device through the driver script corresponding to the target protocol format, the method further includes: If no response signal corresponding to the specific protocol instruction is received, a multi-level exception control mechanism is triggered to achieve intelligent control of the access device.

4. The method according to claim 3, characterized in that Triggering a multi-level exception control mechanism in at least one of the following ways to achieve intelligent control of the access device: Converting the specific protocol instruction into a backup instruction in the target protocol format and adjusting a retry interval; Determining an associated protocol format corresponding to the target protocol format, and converting the control instruction into a specific protocol instruction of the associated protocol format; Trigger the backup control mode of the physical layer and generate an alarm log.

5. The method according to claim 1, characterized in that The dynamic instruction mapping table is a JSON format data structure. Each unified control semantics is associated with multiple protocol instructions, and priority rules and retry strategies are defined. The dynamic instruction mapping table supports user-defined extensions and generates instruction mapping relationships by dragging and dropping protocol fields through a graphical interface.

6. The method according to claim 5, characterized in that The retry interval of the retry strategy is determined by the following formula: Where interval is the retry interval, base is the initial interval, historical success rate 1 is the success rate of the last 10 instructions of the current protocol, historical success rate is the benchmark success rate, α is the randomization coefficient, rand(0,1) is a uniform random number between 0 and 1, and attempt is the current number of retries.

7. A multi-system compatible control device, characterized in that: The device comprises: Feature collection module, used to obtain communication feature data and dynamic instruction mapping table of access devices in real time; An edge computing unit, configured to deploy a device type identification model and identify a target device type corresponding to the access device; An instruction mapping engine, configured to determine a target protocol format corresponding to the target device type according to the dynamic instruction mapping table, and convert the control instruction into a specific protocol instruction in the target protocol format and send the result to the access device; The exception handling module is used to trigger a multi-level exception control mechanism and record fault information when a response signal corresponding to the specific protocol instruction is not received.

8. The device according to claim 7, characterized in that The edge computing unit is an embedded AI chip that supports model reasoning of the TensorFlow Lite framework.

9. A central control device, characterized in that: The central control device executes a multi-system compatible control method, and the central control device includes a hardware layer, a protocol conversion layer and a control layer; The hardware layer includes a plug-in interface board and an interface circuit, the protocol conversion layer includes a dynamic protocol library, and the dynamic protocol library has a built-in connectable device protocol and a dynamic instruction mapping table. The control layer includes a device type identification model, and automatically confirms the protocol type of the access device according to the type identification model, and dynamically loads the corresponding driver to realize the linkage of the access device.

10. The central control device according to claim 9, characterized in that: The plug-in interface board communicates with the main control unit through the backplane bus. The interface circuit has optocoupler isolation and magnetic isolation technology. The dynamic protocol library includes preset protocol modules and user-defined protocol modules, and supports capturing device signals and generating driver scripts through protocol reverse tools.

Images