Building automation interface automatic data binding method and device

Abstract

The application relates to a building automatic control interface automatic data binding method and device, which comprises the following steps: obtaining device access information, wherein the device access information at least comprises a protocol component identifier; according to the protocol component identifier, a corresponding protocol component is matched from a protocol component library, the protocol component comprises parameter information of a corresponding device type and an interface binding mapping rule; wherein the interface binding mapping rule is shared by same-type devices corresponding to the same protocol component; according to the device access information and the parameter information, an instantiation parameter structure of a current device is generated; according to the interface binding mapping rule and the instantiation parameter structure, each parameter in the instantiation parameter structure is mapped to an interface element of a host computer interface to generate binding relationship configuration data. The application can reduce manual binding workload, improve development efficiency and realize permanent reuse after one-time binding.

Description

Technical Field

[0001] This invention relates to the field of building automation control technology, specifically to a method and device for automatic data binding of building automation interfaces. Background Technology

[0002] In the building intelligent control industry, when using host computer development software to create visual interfaces, it is necessary to bind the interface space with the specific equipment parameters of the connected electromechanical devices to achieve real-time correspondence between the interface display and the equipment status. These devices typically acquire data and issue control commands through PLCs (Programmable Logic Controllers). However, the current method of data binding between interface controls and PLC variables mainly relies on manual operation, which is labor-intensive, error-prone, and seriously affects development efficiency and system maintainability.

[0003] Currently, typical solutions in the industry usually require the use of configuration software (such as Schneider Electric's Harmony software) for interface development and data binding, and the operation process is as follows: 1. Variable definition: In configuration software, you need to define the input / output (I / O) variables in the PLC (Programmable Logic Controller) and specify their data type, address and other information. This process requires manually configuring each variable one by one. When there are many devices and parameters, the workload of variable definition is extremely large.

[0004] 2. Drag and drop objects: In the design area of ​​the configuration software interface, drag and drop various interface components (such as buttons, indicator lights, text boxes, charts, etc.) onto the design canvas.

[0005] 3. Variable Binding: This involves binding the properties of UI components (such as button states, indicator light colors, and text box display values) to variables in the PLC. This is typically achieved through association or linking functions. For example, associating the "pressed" state of a button with a numeric input variable in the PLC. Each UI component and variable requires manual binding; batch or automatic binding is not possible.

[0006] However, the above typical solutions have the following shortcomings: (1) Each interface component needs to be manually defined and bound one by one. When there are many devices and parameters, the binding workload is extremely large and the efficiency is low.

[0007] (2) The variable definition and binding process lacks the abstraction and reuse mechanism of device type. Devices of the same type need to be bound repeatedly, and it is impossible to achieve one-time binding and multiple reuse.

[0008] (3) The mapping between the logical points and physical points on the controller side is realized by the point identification naming rules (e.g., "hardware interface-communication address-parameter name"). The matching of the naming rules requires traversal search, which is inefficient when the number of devices and the scale of parameters increase; and the naming rules cannot guarantee the uniqueness of the mapping relationship, and the parameters of different devices may cause mapping errors due to naming conflicts.

[0009] Therefore, there is a need to provide an improved method and system for automatic data binding of building automation interfaces. Summary of the Invention

[0010] To address the shortcomings of existing technologies, this invention provides an automatic data binding method and device for building automation interfaces, which can automatically bind electromechanical equipment parameters to interface elements, reduce manual binding workload, improve development efficiency, and achieve permanent reuse after a single binding.

[0011] The present invention adopts the following technical solution.

[0012] According to a first aspect of the present invention, an automatic data binding method for a building automation interface is provided. The method includes: Obtain the current device's access information, including protocol component identifier, device type identifier, and current device parameter values; Based on the protocol component identifier, a corresponding protocol component is matched from the protocol component library, and the protocol component contains a corresponding interface binding mapping rule; wherein, devices of the same type corresponding to the same protocol component share the interface binding mapping rule; Based on the device type identifier, a corresponding device template is matched from the device template library, and an instantiated parameter structure is generated using the device template and the current device parameters; The parameter identifiers of each parameter are extracted from the instantiated parameter structure. The corresponding interface element attributes of each parameter are matched according to the parameter identifiers. The configuration data of the binding relationship is generated according to the interface binding mapping rule, which is used to bind the current device parameter values ​​corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attributes.

[0013] Furthermore, the interface binding mapping rule includes at least one of the following or a combination thereof: Parameter-control type mapping is used to define the interface control type corresponding to each parameter; Parameter-control property mapping is used to define how each parameter value is mapped to a specific property of the UI control. Data conversion rules are used to define how parameter values ​​are converted into values ​​displayed on the interface. Control style configuration is used to define the display properties of UI controls; Interactive behavior mapping is used to define the parameter write-back rules when the interface sends control commands to the device.

[0014] Furthermore, the matching of the corresponding protocol component from the protocol component library is implemented based on protocol layer hash lookup; the matching of the corresponding device template from the device template library is implemented based on device layer hash lookup; the matching of the interface element attributes corresponding to each parameter based on the parameter identifier is implemented based on interface layer hash lookup; the protocol layer hash lookup, the device layer hash lookup, and the interface layer hash lookup all use the same lookup logic.

[0015] Furthermore, the search logic includes: Determine the hash table for the corresponding layer, wherein the hash table stores the mapping relationship between different identification information of the corresponding layer and the corresponding configuration data; Obtain and generate a hash key based on the identifier information to be matched in the corresponding layer; The hash key is hashed using the first hash function to obtain the main hash address; When the slot corresponding to the main hash address is not occupied, it is determined that the matching object does not exist, and an alarm message is output. When the slot corresponding to the main hash address is occupied and the key stored therein is different from the identifier information to be matched, the hash key is hashed using a second hash function independent of the first hash function to obtain an offset; subsequent slots are continuously probed along the offset until an unoccupied free slot or a matching slot with the same key as the identifier information to be matched is found; when a free slot is found, it is determined that the identifier information to be matched does not exist and an alarm message is returned; when a matching slot is found, the configuration data corresponding to the identifier information to be matched is obtained from the slot as the search result.

[0016] Furthermore, in the protocol layer hash lookup, the hash table corresponding to the protocol layer stores the mapping relationship between different protocol component identifiers and corresponding protocol component definition data; the identifier information to be matched in the protocol layer is the protocol component identifier.

[0017] Furthermore, in the device layer hash lookup, the hash table corresponding to the device layer stores the mapping relationship between different device type identifiers and corresponding device templates; the identifier information to be matched in the device layer is the device type identifier.

[0018] Furthermore, in the interface layer hash lookup, the hash table corresponding to the interface layer stores the mapping relationship between different parameter identifiers and corresponding interface element attributes; the identifier information to be matched in the interface layer is the parameter identifier of each parameter.

[0019] Furthermore, obtaining the current device's access information includes: obtaining the current device's access information through the Can4Net communication channel.

[0020] According to a second aspect of the present invention, an automatic data binding device for a building automation interface is provided, utilizing the method described in the first aspect of the present invention. The device includes: The acquisition module is used to acquire the access information of the current device, including the protocol component identifier, device type identifier, and current device parameter values; The protocol matching module is used to match the corresponding protocol component from the protocol component library according to the protocol component identifier. The protocol component contains the corresponding interface binding mapping rule. The interface binding mapping rule is shared by devices of the same type corresponding to the same protocol component. The device matching module is used to match the corresponding device template from the device template library according to the device type identifier, and generate an instantiated parameter structure using the device template and the current device parameters; The binding module is used to extract the parameter identifier of each parameter from the instantiated parameter structure, match the interface element attributes corresponding to each parameter according to the parameter identifier, and generate configuration data of binding relationship according to the interface binding mapping rule, which is used to bind the current device parameter value corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attribute.

[0021] According to a third aspect of the present invention, an electronic device is provided, comprising a processor and a storage medium: The storage medium stores computer instructions; When the processor executes the computer instructions, it implements the method as described in the first aspect of the present invention.

[0022] The beneficial effects of this invention are that, compared with the prior art, 1. Significantly reduces manual binding workload. In traditional solutions, each interface component requires manual definition of variables and binding one by one, which is extremely labor-intensive when there are many devices and parameters. This invention pre-places the interface binding mapping rules in the protocol component. After the device connects, the cross-layer hash binding engine automatically completes all binding work, eliminating the need for manual configuration and greatly improving interface development efficiency.

[0023] 2. Achieve one-time binding and reuse across all device types. In traditional solutions, devices of the same type need to undergo the same binding operation repeatedly, lacking a mechanism for abstracting and reusing device types. In this invention, all devices of the same type corresponding to the same protocol component share the same set of interface binding mapping rules. After configuration is completed once, subsequent connected devices of the same type automatically inherit the binding relationship, completely eliminating repetitive work.

[0024] 3. Ensuring the uniqueness and determinacy of mapping relationships. Traditional solutions implement point mapping through a naming convention of hardware interface-communication address-parameter name, requiring traversal searching. This is inefficient as the number of devices increases, and the naming convention cannot guarantee the uniqueness and determinacy of the mapping relationship, easily leading to mapping errors due to naming conflicts. This invention ensures the global uniqueness of hash keys through a composite key hash key generation method and guarantees the uniqueness and determinacy of hash mapping through a double hash collision resolution mechanism. This achieves a unique and conflict-free binding relationship between each parameter of each device and interface element.

[0025] 4. Automatic device binding upon connection. This invention utilizes the Can4Net communication active reporting mechanism. When a new device is connected, the controller automatically reports the device type identifier and protocol component identifier. Upon receiving this information, the host computer software automatically triggers a complete hash lookup and binding process, achieving the effect of automatic device binding upon connection.

[0026] 5. Improved binding efficiency for large-scale devices. This invention uses hash lookup instead of traditional traversal lookup, achieving constant-time complexity that is independent of the number of devices. Binding efficiency remains unaffected as the number of devices and parameter scale increase, making it particularly suitable for interface development scenarios in large-scale building automation systems.

[0027] 6. Lowering the technical barrier to UI development. Developers only need to configure the UI binding mapping rules once in the protocol component. The system will automatically complete the binding when subsequent devices are connected, without requiring in-depth programming and protocol configuration skills, thus reducing the technical barrier and workload of UI development.

[0028] 7. Unified hash lookup logic. The protocol layer, device layer, and interface layer all use the same hash lookup logic, including composite key generation, master hash operation, and double hash collision resolution, which reduces the implementation complexity of the system and improves code reusability and maintainability. Attached Figure Description

[0029] Figure 1 This is a system architecture diagram of the automatic data binding system for building automation interface provided in this embodiment of the invention; Figure 2 This is a schematic diagram illustrating the principle of cross-layer hash three-layer mapping provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the automatic data binding method for building automation interfaces provided in this embodiment of the invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this invention. The embodiments described in this application are merely some embodiments of this invention, and not all embodiments. Based on the spirit of this invention, other embodiments obtained by those skilled in the art without creative effort are all within the protection scope of this invention.

[0031] Example 1 This embodiment relates to an automatic data binding method for building automation interfaces. This method is applicable to building automation interface systems.

[0032] like Figures 1-2 As shown, the overall architecture of the building automation interface system is divided into five layers: device access layer, communication transmission layer, protocol component layer, binding processing layer, and interface display layer.

[0033] In the equipment access layer, electromechanical equipment connects to the controller via Can4Net communication. The controller is responsible for collecting and reporting equipment data. Electromechanical equipment includes various controlled objects in the building automation system, such as air conditioning units, fans, water pumps, lighting fixtures, temperature sensors, humidity sensors, and pressure sensors. Each device has one or more monitorable or controllable parameters, such as the current temperature value from the temperature sensor, the start / stop status of the fan, and the operating frequency of the water pump.

[0034] In the communication transmission layer, the Can4Net communication module is responsible for data communication between the controller and the host computer software. During the communication process, it reports the device type identifier, protocol component identifier and current device parameter values ​​to the host computer software to drive the automatic binding process.

[0035] In the protocol component layer, the protocol component library stores and manages protocol components for various devices. Each protocol component encapsulates information such as a parameter list, communication protocol definition, device type identifier, and interface binding mapping rules for the corresponding device type, serving as a standardized basic unit for device access and binding. The device template layer generates device templates based on the protocol components and defines binding mapping relationships.

[0036] In the binding processing layer, the cross-layer hash binding engine automatically binds the protocol layer, device layer, and interface layer one-to-one according to the information reported by Can4Net and the binding rules of protocol components through the cross-layer hash algorithm. It is the core binding processing module.

[0037] In the presentation layer, the rendering layer renders a visual interface based on the binding relationship configuration data, displaying real-time device parameter data. Users perform interface development and configuration operations through interactive terminals, which include, but are not limited to, computer web pages and client applications.

[0038] like Figure 1 As shown, the host computer runs on the computer equipment in the monitoring center, providing a visual interface development and runtime environment. When developing the interface through the host computer software, users can drag and drop interface components such as buttons, indicator lights, text boxes, and charts from the component library onto the design canvas to form the layout framework of the visual interface.

[0039] The controller connects to various electromechanical devices via fieldbus, and is responsible for collecting the operating parameters of the devices and executing control commands issued by the host computer. The controller and the host computer are connected via industrial Ethernet or a dedicated communication network, and use communication protocols such as Can4Net for data exchange.

[0040] Within the host computer, this invention constructs three logical processing layers: a protocol layer, a device layer, and a user interface layer. The protocol layer maintains a protocol component library to store standardized protocol components for various electromechanical devices; the device layer maintains a device template library to store device templates generated based on the protocol components; and the user interface layer is responsible for matching and binding user interface elements. Automatic mapping is achieved between the protocol layer, device layer, and user interface layer through a cross-layer hash binding engine. The three-layer hashing is executed serially, strictly following the order from the protocol layer to the device layer to the user interface layer. This is because the execution of each layer depends on the output of the previous layer; for example, the device layer hashing requires the binding mapping rules output by the protocol layer hashing, which cannot be performed in parallel.

[0041] The automatic data binding method for the building automation interface in this embodiment is executed in the host computer. For example... Figure 3 As shown, this method mainly includes four steps: obtaining device access information; matching protocol components from the protocol component library based on the protocol component identifier; matching device templates from the device template library based on the device type identifier to generate an instantiated parameter structure; and matching each parameter with interface elements according to the interface binding mapping rules to generate binding relationship configuration data. The following section, in conjunction with the appendix... Figure 3 Each step is explained in detail.

[0042] like Figure 3 The method in this embodiment includes the following steps: S1. Obtain the access information of the current device, including the protocol component identifier, device type identifier, and current device parameter values.

[0043] When a new electromechanical device is connected to the building automation system, the controller first establishes a physical layer communication connection with the device via the fieldbus to identify the device's basic information. Subsequently, the controller actively reports the device connection information to the host computer software via the Can4Net communication protocol.

[0044] The structure of a Can4Net communication data frame is as follows: Frame header + Device type identifier (DeviceTypeId) + Protocol component identifier (ComponentId) + Device parameter data (Payload) + Frame trailer checksum (CRC) Specific examples are as follows: 0xAA55 + "DEV-TempSnsr" + "PROTO-Temp-V2" + {"param.temperature.value":25.6, "param.humidity.value":55.2} + 0x0D0A The fields are described as follows: The frame header is a fixed identifier 0xAA55, occupying 2 bytes, used for frame synchronization; the device type identifier is an ASCII string, occupying 16 bytes, uniquely identifying the device type, such as DEV-TempSnsr; the protocol component identifier is an ASCII string, occupying 16 bytes, uniquely identifying the protocol component, such as PROTO-Temp-V2; the device parameter data is in JSON format, with variable length, containing key-value pairs of parameter identifiers and current values; the frame tail checksum is a CRC16 checksum, occupying 2 bytes.

[0045] After receiving a Can4Net data frame, the host computer software first parses the frame header to confirm the frame's validity, then extracts the device type identifier and protocol component identifier for cross-layer hash matching, and finally parses the device parameter data for interface updates. Therefore, the device access information obtained by the host computer includes at least the protocol component identifier, device type identifier, and current device parameter values.

[0046] Can4Net reporting employs a proactive reporting method, specifically including two triggering mechanisms. The first is device access-triggered reporting: when a new device connects to the controller, the controller immediately and proactively reports the device type identifier, protocol component identifier, and full device parameter information, triggering the automatic binding process. The second is parameter change-triggered reporting: during device operation, when device parameter values ​​change, the controller proactively reports the latest parameter values ​​based on the change event, for real-time interface updates. The reporting frequency depends on the frequency of device parameter changes and is determined by the device itself and the controller configuration; this invention does not limit the reporting frequency.

[0047] The fields are described as follows: The frame header is a fixed identifier 0xAA55, occupying 2 bytes, used for frame synchronization; the device type identifier is an ASCII string, occupying 16 bytes, uniquely identifying the device type, such as DEV-TempSnsr; the protocol component identifier is an ASCII string, occupying 16 bytes, uniquely identifying the protocol component, such as PROTO-Temp-V2; the device parameter data is in JSON format, with variable length, containing key-value pairs of parameter identifiers and current values; the frame tail checksum is a CRC16 checksum, occupying 2 bytes.

[0048] After receiving a Can4Net data frame, the host computer software first parses the frame header to confirm the frame's validity, then extracts the device type identifier and protocol component identifier for cross-layer hash matching, and finally parses the device parameter data for interface updates. Therefore, the device access information obtained by the host computer includes at least the protocol component identifier, device type identifier, and current device parameter values.

[0049] Can4Net reporting employs a proactive reporting method, specifically including two triggering mechanisms. The first is device access-triggered reporting: when a new device connects to the controller, the controller immediately and proactively reports the device type identifier, protocol component identifier, and full device parameter information, triggering the automatic binding process. The second is parameter change-triggered reporting: during device operation, when device parameter values ​​change, the controller proactively reports the latest parameter values ​​based on the change event, for real-time interface updates. The reporting frequency depends on the frequency of device parameter changes and is determined by the device itself and the controller configuration; this invention does not limit the reporting frequency.

[0050] S2. Based on the protocol component identifier, match the corresponding protocol component from the protocol component library. The protocol component contains the corresponding interface binding mapping rule. Among them, devices of the same type corresponding to the same protocol component share the interface binding mapping rule.

[0051] After obtaining the device access information, the host computer matches the corresponding protocol component from the protocol component library based on the protocol component identifier. This step is implemented through protocol layer hash lookup.

[0052] like Figure 2 As shown, the protocol layer hash lookup uses the protocol component identifier reported by Can4Net to quickly match the corresponding protocol component in the protocol component library using a hash algorithm, and obtains the parameter list and interface binding mapping rules of that protocol component. The hash key is the protocol component identifier, and the hash value is the complete definition data of the protocol component.

[0053] Protocol components are the core basic data units of this invention. Developers encapsulate equipment parameters (such as temperature values, switch states, operating modes, etc.), communication protocols (such as Modbus, BACnet, Can4Net, etc.), and equipment type identifiers into unified protocol components based on the communication protocols and parameter specifications of various electromechanical devices. Each protocol component corresponds to a specific device type and contains standardized information such as a complete parameter list, parameter data types, read / write attributes, and communication address rules for that type of device. Protocol components are stored in a protocol component library and can be selected and referenced during interface development.

[0054] The encapsulation structure of the protocol component includes the following elements: (a) Device type identifier: uniquely identifies the device type corresponding to this protocol component, used for type matching when the device is accessed.

[0055] (b) Parameter list: Defines the names, data types, read / write attributes, units, value ranges, communication addresses, and other information of all available parameters for this device type.

[0056] (c) Communication Protocol Definition: Defines the communication protocol and communication parameters used by this device type.

[0057] (d) Interface binding mapping rules: Define the default correspondence between each parameter in the parameter list and the interface element type. For example, the temperature parameter corresponds to the temperature display control by default, and the switch parameter corresponds to the switch button control by default.

[0058] The interface binding mapping rule is not just a mapping table, but contains complete binding configuration information in the following dimensions: Parameter-control type mapping defines which UI control type corresponds to each parameter in the protocol component. For example, temperature parameters correspond to a temperature display control (TextBox), switch parameters correspond to a switch button control (ToggleButton), and analog parameters correspond to a gauge control (Gauge). Parameter-control attribute mapping defines which specific attribute of the control the parameter value maps to. For example, temperature value parameters map to the display value attribute of a text box (displayValue), and switch status parameters map to the active status attribute of a button (isActive). Data conversion rules define the conversion method between parameter values ​​and UI display values, including range scaling, unit conversion, and enumerated value mapping (e.g., value 0 maps to text "off", value 1 maps to text "on"). Control style and layout configuration defines the default size, color scheme, position layout, and other display attributes of the control. Interaction behavior mapping defines the parameter write-back rules when the interface sends control commands to the device. For example, when a button is pressed, the corresponding switch parameter is written back.

[0059] In one specific embodiment of the present invention, the protocol component is defined using the following data structure: ProtocolComponent { componentId: String, / / Unique identifier for the protocol component deviceTypeId: String, / / Device type identifier deviceTypeName: String, / / Device type name communicationProtocol: { / / Communication protocol definition protocolType: String, / / Such as "Modbus", "BACnet", "Can4Net" baudRate: Integer, dataBits: Integer, stopBits: Integer, parity: String }, parameterList: [ / / Parameter list] { paramId: String, / / Unique identifier for the parameter paramName: String, / / Parameter name dataType: String, / / Such as "Float", "Boolean", "Enum" readWrite: String, / / "R" read-only / "W" write-only / "RW" read-write unit: String, / / Unit minValue: Number, / / Minimum value maxValue: Number, / / Maximum value address: String / / Communication address } ], bindingMappingRules: { / / Interface binding mapping rules defaultControlMapping: [ / / Parameter - Default mapping for control type] { paramId: String, controlType: String, / / Such as "TextBox", "ToggleButton", "Gauge" controlProperty: String, / / such as "displayValue", "isActive" transformRule: String, / / Data transformation rule styleConfig: { / / Style configuration defaultSize: {width, height}, colorScheme: String, layoutHint: String }, interactionBehavior: { / / Interaction behavior writeBackParamId: String, writeBackProperty: String } } ] } } Taking a temperature and humidity sensor as an example, its protocol components are defined as follows: componentId is PROTO-TempSensor-V2, and deviceTypeId is DEV-TempSensor. parameterList contains three parameters: paramId is the parameter for param.temperature.value, named "temperature value," with data type Float, unit ℃, and communication address 0x0001; paramId is the parameter for param.temperature.alarm, named "over-temperature alarm," with data type Boolean, and communication address 0x0002; and paramId is the parameter for param.humidity.value, named "humidity value," with data type Float, unit %RH, and communication address 0x0003.

[0060] All devices of the same type corresponding to the same protocol component share the same set of interface binding mapping rules. This is the key mechanism for achieving one-time binding and full-type reuse. That is, once a protocol component is bound to an interface element, all devices of the same type created by that protocol component automatically inherit the binding relationship without needing to be bound again.

[0061] S3. Based on the device type identifier, match the corresponding device template from the device template library, and generate an instantiated parameter structure using the device template and the current device parameters.

[0062] After the host computer obtains the protocol component through a protocol layer hash lookup, it further matches the corresponding device template from the device template library based on the device type identifier in the device access information, and uses this device template and the current device parameters to generate an instantiated parameter structure. This step is implemented through a device layer hash lookup.

[0063] like Figure 2As shown, the device-level hash lookup uses the reported device type identifier and device unique identifier to quickly match the corresponding device template in the device template library using a hash algorithm, generating the instantiation parameter structure of the device. The hash key is a combination of the device type identifier and the device unique identifier, and the hash value is the parameter structure data of the device instance.

[0064] Device templates are pre-generated based on protocol components during system initialization or project configuration. Based on these protocol components, the system automatically generates corresponding device templates. Each device template defines the general parameter structure and interface binding mapping for that device type. The device template includes protocol component identifiers, parameter lists, and correspondence rules between interface element types (e.g., temperature parameters correspond to temperature display controls, switch parameters correspond to switch button controls, etc.), serving as the template basis for subsequent batch creation of device instances and automatic binding. The device template is an instantiation template for the protocol components; when creating a specific device, the system automatically generates the complete parameter structure of that device instance based on the device template and protocol components.

[0065] Protocol components and device templates form a hierarchical relationship between the definition layer and the instantiation layer: Protocol components describe the complete specification of a device type, including parameter lists, communication protocols, device type identifiers, and interface binding mapping rules; they are static, reusable, and standardized definitions. Device templates are generated based on a specific protocol component, inheriting all the component's definitions and additionally containing the interface binding mapping relationship for that device type in a specific project. Device templates are pre-generated based on protocol components during system initialization or project configuration and stored in the device template library.

[0066] The hierarchical relationship can be represented as follows: Protocol component library: { Protocol Component A (Device Type Definition: Parameters + Protocol + Type Identifier + Interface Binding Mapping Rules) { Device Template A-1 (based on Protocol Component A, with additional project-level interface binding configuration) {Device instance A-1-001 (a specific device created based on device template A-1), Device instance A-1-002} }, {Device Template A-2 (Binding configuration of the same protocol component in different projects)} } The device template already exists in the device template library before the device is connected. The device layer hash lookup directly matches the existing device template, rather than creating it temporarily when the device is connected.

[0067] After a successful device-layer hash lookup matches the device template, an instantiated parameter structure is generated using the device template and the current device parameters. The device template contains all parameter information inherited from the protocol component, including parameter identifier, parameter name, data type, unit, and communication address. The host computer extracts the current device parameter value from the device parameter data portion of the Can4Net data frame. Using the parameter identifier as the matching basis, the current device parameter value is filled into the current value field of the corresponding parameter in the device template, forming a complete instantiated parameter structure. The parameter identifier in the instantiated parameter structure comes from the parameter information of the protocol component, and the current value in the instantiated parameter structure comes from the current device parameters in the device access information.

[0068] Taking a temperature and humidity sensor as an example, the generated instantiated parameter structure is as follows: { "deviceId": "SN-20260101-0001", "deviceTypeId": "DEV-TempSensor", "parameters": [ { "paramId": "param.temperature.value", "paramName": "Temperature value", "dataType": "Float", "readWrite": "R", "unit": "℃", "minValue": -40, "maxValue": 150, "address": "0x0001", "currentValue": 25.6 }, { "paramId": "param.temperature.alarm", "paramName": "Over-temperature alarm", "dataType": "Boolean", "readWrite": "R", "unit": "", "minValue": 0, "maxValue": 1, "address": "0x0002", "currentValue": false }, { "paramId": "param.humidity.value", "paramName": "Humidity value", "dataType": "Float", "readWrite": "R", "unit": "%RH", "minValue": 0, "maxValue": 100, "address": "0x0003", "currentValue": 55.2 } ] } S4. Extract the parameter identifier of each parameter from the instantiated parameter structure, match the interface element attributes corresponding to each parameter according to the parameter identifier, and generate the configuration data of the binding relationship according to the interface binding mapping rule, which is used to bind the current device parameter value corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attribute.

[0069] After obtaining the instantiated parameter structure, the host computer matches each parameter in the instantiated parameter structure with the interface elements of the host computer interface according to the interface binding mapping rules in the protocol component, and generates binding relationship configuration data based on the matching results. This step is implemented through interface layer hash lookup.

[0070] like Figure 2 As shown, the interface layer hash lookup automatically maps device instance parameters to relevant attributes of interface elements based on the interface binding mapping rules of the protocol components using a hash algorithm. The hash key is a combination of the parameter name and the interface element identifier, and the hash value is the bound interface element attribute configuration data.

[0071] The identifier information to be matched in the interface layer hash lookup is the parameter identifier of each parameter. The parameter identifier of each parameter is extracted from the instantiated parameter structure, and a hash key is generated using a composite key hash key generation method. Then, the lookup is performed in the interface layer hash table according to the hash lookup logic to match the interface element attributes corresponding to each parameter.

[0072] The interface layer hash table stores the mapping relationship between different parameter identifiers and corresponding interface element attributes. This hash table is pre-built during system initialization according to the interface binding mapping rules in the protocol component library, using the parameter identifier as the key and the corresponding interface element attribute information as the value.

[0073] After a successful hash lookup match at the interface layer, the corresponding UI element attribute information for each parameter is retrieved from the interface layer hash table, including control type, control attributes, data conversion rules, style configuration, and interactive behavior. Based on the interface binding mapping rules and the matching results, binding relationship configuration data is generated to bind the current device parameter values ​​corresponding to each parameter in the instantiated parameter structure to the corresponding UI element attributes.

[0074] The binding relationship configuration data records the complete binding relationship between each parameter and the corresponding UI element attribute, including the correspondence between parameter identifiers and UI elements, the mapping of parameter values ​​to control attributes, data conversion rules, style configuration, interactive behavior, and other information.

[0075] Preferably, the hash lookup (protocol layer hash lookup, device layer hash lookup, and interface layer hash lookup) in steps S2, S3, and S4 above uses the same hash lookup logic. The unified implementation of this hash lookup is described in detail below.

[0076] 1. Method for generating composite key hash keys The method for generating a composite key hash key involves concatenating multiple identifier fields in an ordered manner according to a predefined structured delimiter to generate a globally unique composite string key, and then performing a hash operation on the composite string key to obtain the hash address.

[0077] The specific implementation is as follows: Protocol layer hash key generation: Hash key = Hash(componentId), where componentId is a unique identifier of the protocol component (such as PROTO-TempSensor-V2), which is directly used as the input hash key.

[0078] Device-level hash key generation: Hash key = Hash(deviceTypeId + "::" + deviceUniqueId), where deviceTypeId is the device type identifier (e.g., DEV-TempSensor), "::" is the structure delimiter, and deviceUniqueId is the unique identifier of the device (e.g., the serial number SN-20260101-0001 assigned by the controller). An example combination result is DEV-TempSensor::SN-20260101-0001. The hash key is obtained by hashing this string.

[0079] Interface layer hash key generation: Hash key = Hash(paramId + "::" + elementId), where paramId is a unique identifier for the parameter (e.g., param.temperature.value), and elementId is a unique identifier for the interface element (e.g., elem.textbox.room1_temp). The example combination is param.temperature.value::elem.textbox.room1_temp, where the hash key is obtained by performing a hash operation on this string.

[0080] The hash function uses the SHA-256 algorithm to operate on the composite string key, taking the first N bits as the hash table index address. A double colon is used as the delimiter, chosen because it does not appear in normal identifier naming, thus ensuring that different field combinations do not produce the same composite key and avoiding collisions such as the result of a combination of AB and CD being the same as the result of a combination of A and BCD.

[0081] 2. Storage structure of hash tables at each level Each layer of hash tables stores the mapping relationship between different identifiers of the corresponding layer and the corresponding configuration data: The protocol layer hash table stores the mapping relationship between different protocol component identifiers and the corresponding protocol component definition data.

[0082] The device layer hash table stores the mapping relationship between different device type identifiers and corresponding device templates.

[0083] The interface layer hash table stores the mapping relationship between different parameter identifiers and corresponding interface element attributes.

[0084] 3. The specific execution process of hash lookup The first step is to obtain and generate a hash key based on the identifier information to be matched in the corresponding layer, according to the composite key hash key generation method.

[0085] The second step involves performing a hash operation on the hash key using the first hash function to obtain the main hash address. The main hash function uses the SHA-256 algorithm. After performing the SHA-256 operation on the composite key string, the first N bits of the result (N is determined by the hash table size; for example, if the table size is 1024, the first 10 bits are taken) are converted into an integer and used as the main hash address. h1(key) = SHA256(key) mod TABLE_SIZE The third step is to check the slot status corresponding to the main hash address. If the slot corresponding to the main hash address is not occupied, it is determined that the matching object does not exist, and an alarm message is output. If the slot corresponding to the main hash address is occupied and the key stored therein is the same as the identifier information to be matched, the configuration data corresponding to the identifier information to be matched is retrieved from that slot as the search result.

[0086] The fourth step is to handle hash collisions. A hash collision occurs when the slot corresponding to the main hash address is already occupied and the key stored therein is different from the identifier information to be matched. The collision detection logic is as follows: if hash_table[h1(key)].occupied == True AND hash_table[h1(key)].stored_key != key: → A conflict occurs, triggering double hash probing. Specifically, if the slot is empty, the insertion is performed directly without conflict; if the slot is occupied, but the stored key is exactly the same as the current key, it means that it is a duplicate insertion of the same key, and the value can be updated without conflict; if the slot is occupied and the stored key is different from the current key, it is confirmed as a conflict.

[0087] Fifth, when a hash collision occurs, the hash key is hashed using a second hash function independent of the first hash function to obtain the offset. The second hash function uses the MurmurHash3 algorithm, whose purpose is to calculate an offset associated with the key when a collision occurs in the primary hash address, rather than reprocessing the same hash value. h2(key) = MurmurHash3(key) mod (TABLE_SIZE - 1) + 1 Adding an operation here ensures that the offset is not 0, thus avoiding an infinite loop.

[0088] Step 6: Continuously probe subsequent slots along the offset. A double hash probing formula is used: probe(key, i) = (h1(key) + i × h2(key)) mod TABLE_SIZE Where i = 0, 1, 2, ... represents the number of probes. When i equals 0, the probe location is the main hash address; when i equals 1, the probe location is the main hash address plus an offset modulo the table size; when i equals 2, the probe location is the main hash address plus twice the offset modulo the table size; and so on.

[0089] Step 7: Perform corresponding operations based on the detection results. When an empty slot is found, it is determined that the identifier information to be matched does not exist, and an alarm message is returned. When a matching slot is found (the stored key is the same as the identifier information to be matched), the configuration data corresponding to the identifier information to be matched is retrieved from that slot as the search result.

[0090] Preferably, any abnormal situations that may occur during the above steps shall be handled in the following manner: If the protocol layer search fails in step S2 (the corresponding protocol component identifier does not exist in the protocol component library), the system records an error log, returns an alarm message that the protocol component was not found to the host computer software, terminates the current binding process, and waits for the developer to manually add the corresponding protocol component before re-triggering.

[0091] When the device layer lookup fails in step S3 (the corresponding device type identifier does not exist in the device template library), the system records an error log, returns an alarm message that the device template was not found, terminates the current binding process, and waits for the developer to generate the device template based on the corresponding protocol component before re-triggering the process.

[0092] If the interface layer matching fails in step S4 (a certain parameter does not find a corresponding interface element in the binding mapping rules), the binding of that parameter is skipped, the system records a warning log (non-fatal error), and the binding of the remaining parameters continues without affecting the normal binding of the already matched parameters.

[0093] Preferably, after generating the binding relationship configuration data, the host computer software's interface rendering engine renders and generates a visual interface based on this configuration data. For example... Figure 1 As shown, the interface rendering layer is located within the interface display layer. Based on automatically established binding relationships, the interface rendering layer performs real-time data binding between interface elements and corresponding device parameters to render the visual interface.

[0094] When device parameters change, the latest data is reported via Can4Net communication. Interface elements are automatically updated based on the binding relationships, enabling real-time visual monitoring of the device status. The entire data flow is as follows: device parameters change, Can4Net reports, cross-layer hash binding engine matches, interface element attributes are updated, and finally, the interface is rendered and refreshed.

[0095] Example 2 This embodiment provides an automatic data binding device for a building automation interface using the automatic data binding method of the present invention. The device includes: The acquisition module is used to acquire the access information of the current device, including the protocol component identifier, device type identifier, and current device parameter values; The protocol matching module is used to match the corresponding protocol component from the protocol component library according to the protocol component identifier. The protocol component contains the corresponding interface binding mapping rule. The interface binding mapping rule is shared by devices of the same type corresponding to the same protocol component. The device matching module is used to match the corresponding device template from the device template library according to the device type identifier, and generate an instantiated parameter structure using the device template and the current device parameters; The binding module is used to extract the parameter identifier of each parameter from the instantiated parameter structure, match the interface element attributes corresponding to each parameter according to the parameter identifier, and generate configuration data of binding relationship according to the interface binding mapping rule, which is used to bind the current device parameter value corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attribute.

[0096] Example 3 This embodiment provides an electronic device, including a processor and a storage medium: the storage medium stores computer instructions; when the processor executes the computer instructions, it implements the method described in this invention. Specific method implementation steps are not detailed here.

[0097] In summary, the present invention has the following advantages over the prior art: First, it significantly reduces the workload of manual binding. In traditional solutions, each interface component requires manually defining variables and binding them one by one, which is extremely labor-intensive when there are many devices and parameters. This invention pre-places the interface binding mapping rules in the protocol component. After the device connects, the cross-layer hash binding engine automatically completes all binding work, eliminating the need for manual configuration and greatly improving the efficiency of interface development.

[0098] Second, it achieves one-time binding and reuse across all device types. In traditional solutions, devices of the same type need to undergo the same binding operation repeatedly, lacking a mechanism for abstracting and reusing device types. In this invention, all devices of the same type corresponding to the same protocol component share the same set of interface binding mapping rules. After configuration is completed once, subsequent connected devices of the same type automatically inherit the binding relationship, completely eliminating repetitive work.

[0099] Third, it ensures the uniqueness and determinacy of the mapping relationship. Traditional solutions achieve point mapping through naming rules of hardware interfaces, communication addresses, and parameter names, requiring traversal searching. This is inefficient as the number of devices increases, and the naming rules cannot guarantee the uniqueness and determinacy of the mapping relationship, easily leading to mapping errors due to naming conflicts. This invention ensures the global uniqueness of hash keys through a composite key hash key generation method and ensures the uniqueness and determinacy of hash mapping through a double hash collision resolution mechanism, achieving a unique and conflict-free binding relationship between each parameter of each device and interface element.

[0100] Fourth, it enables automatic binding upon device access. This invention is based on the Can4Net communication proactive reporting mechanism. When a new device is accessed, the controller automatically reports the device type identifier and protocol component identifier. After receiving the report, the host computer software automatically triggers a complete hash lookup and binding process.

[0101] Fifth, it improves the binding efficiency of large-scale devices. This invention uses hash lookup instead of traditional traversal lookup, achieving a constant-time complexity that is independent of the number of devices. Binding efficiency remains unaffected as the number of devices and parameter scale increase, making it particularly suitable for interface development scenarios in large-scale building automation systems.

[0102] Sixth, it lowers the technical barrier to interface development. Developers only need to configure the interface binding mapping rules once in the protocol component, and the system will automatically complete the binding when subsequent devices are connected, without requiring extensive programming and protocol configuration skills.

[0103] Seventh, unified hash lookup logic. The protocol layer, device layer, and interface layer all use the same hash lookup logic, including composite key generation, master hash operation, and double hash collision resolution, which reduces the implementation complexity of the system and improves code reusability and maintainability.

[0104] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0105] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0106] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0107] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0108] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for automatic data binding of a building automation interface, characterized in that, include: Obtain the current device's access information, including protocol component identifier, device type identifier, and current device parameter values; Based on the protocol component identifier, a corresponding protocol component is matched from the protocol component library, and the protocol component contains a corresponding interface binding mapping rule; wherein, devices of the same type corresponding to the same protocol component share the interface binding mapping rule; Based on the device type identifier, a corresponding device template is matched from the device template library, and an instantiated parameter structure is generated using the device template and the current device parameters; The parameter identifiers of each parameter are extracted from the instantiated parameter structure. The corresponding interface element attributes of each parameter are matched according to the parameter identifiers. The configuration data of the binding relationship is generated according to the interface binding mapping rule, which is used to bind the current device parameter values ​​corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attributes.

2. The method according to claim 1, characterized in that, The interface binding mapping rules include at least one of the following or a combination thereof: Parameter-control type mapping is used to define the interface control type corresponding to each parameter; Parameter-control property mapping is used to define how each parameter value is mapped to a specific property of the UI control. Data conversion rules are used to define how parameter values ​​are converted into values ​​displayed on the interface. Control style configuration is used to define the display properties of UI controls; Interactive behavior mapping is used to define the parameter write-back rules when the interface sends control commands to the device.

3. The method according to claim 1, characterized in that, The matching of corresponding protocol components from the protocol component library is implemented based on protocol layer hash lookup; the matching of corresponding device templates from the device template library is implemented based on device layer hash lookup; the matching of interface element attributes corresponding to each parameter based on parameter identifier is implemented based on interface layer hash lookup. The protocol layer hash lookup, the device layer hash lookup, and the interface layer hash lookup all use the same lookup logic.

4. The method according to claim 3, characterized in that, The search logic includes: Determine the hash table for the corresponding layer, wherein the hash table stores the mapping relationship between different identification information of the corresponding layer and the corresponding configuration data; Obtain and generate a hash key based on the identifier information to be matched in the corresponding layer; The hash key is hashed using the first hash function to obtain the main hash address; When the slot corresponding to the main hash address is not occupied, it is determined that the matching object does not exist, and an alarm message is output. When the slot corresponding to the main hash address is occupied and the key stored therein is different from the identifier information to be matched, the hash key is hashed using a second hash function independent of the first hash function to obtain an offset; subsequent slots are continuously probed along the offset until an unoccupied free slot or a matching slot with the same key as the identifier information to be matched is found; when a free slot is found, it is determined that the identifier information to be matched does not exist and an alarm message is returned; when a matching slot is found, the configuration data corresponding to the identifier information to be matched is obtained from the slot as the search result.

5. The method according to claim 4, characterized in that, In the protocol layer hash lookup, the hash table corresponding to the protocol layer stores the mapping relationship between different protocol component identifiers and the corresponding protocol component definition data; the identifier information to be matched in the protocol layer is the protocol component identifier.

6. The method according to claim 4, characterized in that, In the device layer hash lookup, the hash table corresponding to the device layer stores the mapping relationship between different device type identifiers and corresponding device templates; the identifier information to be matched in the device layer is the device type identifier.

7. The method according to claim 4, characterized in that, In the interface layer hash lookup, the hash table corresponding to the interface layer stores the mapping relationship between different parameter identifiers and corresponding interface element attributes; the identifier information to be matched in the interface layer is the parameter identifier of each parameter.

8. The method according to claim 1, characterized in that, Obtaining the current device's access information includes: obtaining the current device's access information through the Can4Net communication channel.

9. An automatic data binding device for a building automation interface using the method described in any one of claims 1 to 8, characterized in that, include: The acquisition module is used to acquire the access information of the current device, including the protocol component identifier, device type identifier, and current device parameter values; The protocol matching module is used to match the corresponding protocol component from the protocol component library according to the protocol component identifier. The protocol component contains the corresponding interface binding mapping rule. The interface binding mapping rule is shared by devices of the same type corresponding to the same protocol component. The device matching module is used to match the corresponding device template from the device template library according to the device type identifier, and generate an instantiated parameter structure using the device template and the current device parameters; The binding module is used to extract the parameter identifier of each parameter from the instantiated parameter structure, match the interface element attributes corresponding to each parameter according to the parameter identifier, and generate configuration data of binding relationship according to the interface binding mapping rule, which is used to bind the current device parameter value corresponding to each parameter in the instantiated parameter structure to the corresponding interface element attribute.

10. An electronic device comprising a processor and a storage medium, characterized in that: The storage medium stores computer instructions; When the processor executes the computer instructions, it implements the method as described in any one of claims 1 to 8.

Images