Method and device for dynamically generating upper computer interface of battery management system

Abstract

The embodiment of the invention provides a method and a device for dynamically generating an upper computer interface of a battery management system. The method for dynamically generating the upper computer interface of the battery management system comprises the following steps: acquiring parameter information of a plurality of battery parameters corresponding to a battery module in the battery management system; reading a configuration file generated by a user through user-defined configuration, analyzing the configuration file to obtain a template view corresponding to the parameter information, and obtaining a binding relationship between different battery parameters and different template controls; determining target template controls bound with the plurality of battery parameters according to the binding relationship, and combining the target template controls according to the template view to generate an initial upper computer interface; and based on the binding relationship, dynamically filling the target template control in the initial upper computer interface with the parameter information, and generating a target upper computer interface for visual display.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification relate to the technical field of computer technology, and particularly relate to a method for dynamically generating an upper computer interface of a battery management system. BACKGROUND

[0002] With the increasing demand for energy and the widespread use of renewable energy, energy storage systems play an increasingly important role in power systems. As a core component of energy storage systems, the battery management system (BMS) is responsible for monitoring, protecting, managing and optimizing the battery. However, existing energy storage BMS systems face many challenges.

[0003] Currently, due to different regional energy storage application scenarios, there are differences in the parameter requirements of the battery management system. In addition, there are many types of energy storage devices, which further lead to the variability of the parameters of the battery management system. In this case, the traditional design method of the upper computer interface cannot adapt to the frequent changes of the parameters of the battery management system. Usually, the upper computer interface needs to be customized and developed according to different battery management system parameters, which will result in a large number of developed upper computer versions and high maintenance costs. Therefore, an effective method is needed to solve this problem. SUMMARY

[0004] Therefore, the embodiments of the present specification provide a method for dynamically generating an upper computer interface of a battery management system. One or more embodiments of the present specification also relate to a device for dynamically generating an upper computer interface of a battery management system, a computing device, a computer-readable storage medium, and a computer program to solve the technical defects in the prior art.

[0005] According to a first aspect of the embodiments of the present specification, a method for dynamically generating an upper computer interface of a battery management system is provided, comprising: obtaining parameter information of a plurality of battery parameters corresponding to a battery module in the battery management system; reading a configuration file generated by a user through self-defined configuration and parsing the configuration file to obtain a template view corresponding to the parameter information and to obtain a binding relationship between different battery parameters and different template controls; determining target template controls respectively bound to the plurality of battery parameters according to the binding relationship, and combining the target template controls according to the template view to generate an initial upper computer interface; based on the binding relationship, dynamically filling the parameter information into the target template controls in the initial upper computer interface to generate a target upper computer interface for visual display.

[0006] Optionally, after obtaining the binding relationship between different battery parameters and different template controls, the method further comprises: According to the template view and based on the binding relationship, screen the interface template meeting the condition in the pre-constructed interface template library, and determine the interface template as the initial host computer interface.

[0007] Optionally, the configuration file further contains control attribute configuration. Correspondingly, the method further comprises: providing a parameter control binding interface, and receiving user operation through the parameter control binding interface to bind different battery parameters with different template controls; providing an attribute configuration interface of the template control, and receiving user operation through the attribute configuration interface to configure attribute parameters of each template control, wherein the attribute parameters include editing attributes and parsing attributes, and the editing attributes contain identifiers corresponding to read-only attributes.

[0008] Optionally, the method for dynamically generating the host computer interface of the battery management system further comprises: in response to a click operation of a user on target parameter information in the target host computer interface, determining an identifier corresponding to a read-only attribute associated with the target parameter information; in a case where it is determined according to the identifier that the target parameter information is in an editable state, dynamically loading an editing pop-up window corresponding to the target parameter information.

[0009] Optionally, the method for dynamically generating the host computer interface of the battery management system further comprises: in response to an update instruction of a remote client, sending a file download request to a server, wherein the file download request carries a version number identifier of the battery management system, and the file download request is used to request the server to determine a corresponding initial configuration file according to the version number identifier in the file download request; receiving the initial configuration file sent by the server.

[0010] Optionally, the method for dynamically generating the host computer interface of the battery management system further comprises: in response to an update instruction of a remote client, sending a file download request to a server, wherein the file download request carries a battery parameter identifier of a battery block in the battery management system, and the file download request is used to request the server to determine a corresponding initial configuration file and / or initial template control according to the battery parameter identifier in the file download request; receiving the initial configuration file and / or the initial template control sent by the server, and storing the initial template control to an interface template library.

[0011] According to a second aspect of the embodiments of the present specification, a battery management system host computer interface dynamic generation device is provided, comprising: An acquisition module configured to acquire parameter information of a plurality of battery parameters corresponding to a battery module in a battery management system; A reading module configured to read a configuration file generated by a user through self-defined configuration, and parse the configuration file to obtain a template view corresponding to the parameter information, and obtain a binding relationship between different battery parameters and different template controls; A first generation module configured to determine target template controls respectively bound to the plurality of battery parameters according to the binding relationship, and combine the target template controls according to the template view to generate an initial host computer interface; A second generation module configured to dynamically fill the parameter information into the target template controls in the initial host computer interface based on the binding relationship to generate a target host computer interface for visual display.

[0012] Optionally, the battery management system host computer interface dynamic generation device further comprises: A processing module configured to filter an interface template meeting the conditions in a pre-constructed interface template library according to the template view and based on the binding relationship, and determine the interface template as an initial host computer interface.

[0013] According to a third aspect of the embodiments of the present specification, a computing device is provided, comprising: A memory and a processor; The memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions to implement the steps of any one of the battery management system host computer interface dynamic generation methods.

[0014] According to a fourth aspect of the embodiments of the present specification, a computer readable storage medium is provided, which stores computer executable instructions, and the instructions are executed by a processor to implement the steps of any one of the battery management system host computer interface dynamic generation methods.

[0015] According to a fifth aspect of the embodiments of the present specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the battery management system host computer interface dynamic generation method.

[0016] The embodiment of the present specification can obtain parameter information of a plurality of battery parameters corresponding to a battery module in a battery management system; read a configuration file generated by a user through self-defined configuration and analyze the configuration file to obtain a template view corresponding to the parameter information and obtain a binding relationship between different battery parameters and different template controls; determine target template controls respectively bound to the plurality of battery parameters according to the binding relationship, and combine the target template controls according to the template view to generate an initial host computer interface; and based on the binding relationship, dynamically fill the parameter information into the target template controls in the initial host computer interface to generate a target host computer interface for visual display. In this way, the battery parameters and the information interface can be dynamically constructed, so as to realize dynamic generation, efficient maintenance and real-time response of the host computer interface, and the host computer interface can be automatically adjusted according to the change of the battery parameters, without frequent version update and customized development, thereby improving the overall performance and user experience of the battery management system. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 is a flowchart of a host computer interface dynamic generation method of a battery management system provided by an embodiment of the present specification; Figure 2 is a flowchart of an interface updating process provided by an embodiment of the present specification; Figure 3 is a flowchart of another interface updating process provided by an embodiment of the present specification; Figure 4 is a structural schematic diagram of a host computer interface dynamic generation device of a battery management system provided by an embodiment of the present specification; Figure 5 is a structural block diagram of a computing device provided by an embodiment of the present specification. DETAILED DESCRIPTION

[0018] In the following description, many specific details are set forth in order to provide a thorough understanding of the present specification. However, the present specification can be practiced in many different ways beyond the specific embodiments described herein, and it is understood that persons having ordinary skill in the art can make similar modifications without departing from the spirit of the present specification, so the present specification is not limited to the specific implementations disclosed below.

[0019] The terminology used in this description of one or more embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of one or more embodiments of the description. As used in this description of one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0020] It will be understood that, although the terms first, second, etc. can be used herein to describe various information, these

[0021] In current energy storage systems, the parameters and information of the battery management system (BMS) are variable, which requires frequent version release of the host computer and is costly. In addition, different sites are concerned about different information, and the requirements for the host computer interface are also different, which leads to the fact that one host computer cannot meet the requirements of multiple projects. Therefore, the following main problems exist in the prior art: 1. Existing host computer interface is difficult to adapt to parameter variability: In existing BMS, due to different regional energy storage application scenarios and different types of energy storage equipment, the parameters of BMS have high variability. Traditional host computer interface design is usually developed based on fixed parameters, which is difficult to adapt to such variability. When the BMS parameters change, the interface often needs to be redeveloped or modified, which not only consumes time and effort, but also easily introduces new errors.

[0022] 2. Numerous versions of host computer are difficult to maintain: Due to the variability of BMS parameters, traditional host computer interface needs to be customized and developed for different application scenarios and equipment types, resulting in a large number of versions of host computer. In this case, maintenance work becomes extremely complex, and each update or repair needs to be operated for multiple versions, increasing the maintenance cost and error risk of the system.

[0023] 3. Lack of flexibility and real-time performance: The existing host computer interface is usually fixed after development and cannot dynamically adjust the interface layout and data display according to the real-time running state of the BMS system. This lack of flexibility limits the real-time monitoring and rapid response capability of the operating personnel to the system state, especially in the face of sudden failures or abnormal situations, it is difficult to obtain key information in a timely manner.

[0024] 4. Poor user experience: Traditional host computer interface design often lacks user customization functions, and cannot meet the operation habits and personalized needs of different users. In addition, problems such as interface update not in time and data display not intuitive also seriously affect the user's operation experience and reduce the work efficiency.

[0025] 5. Difficulty in remote maintenance and upgrade: In the existing system, the update and maintenance of the host computer interface usually need to be operated on site, and cannot realize remote automatic management. This not only increases the maintenance cost, but also may cause the system update not in time, affecting the stability and reliability of the system.

[0026] The embodiment of the present specification proposes a battery management system host computer interface dynamic generation method based on WPF (Windows Presentation Foundation), aiming to realize flexible generation and efficient maintenance of the host computer interface through dynamic parameter analysis, interface template library, dynamic generation algorithm and user-defined functions.

[0027] In the present specification, a battery management system host computer interface dynamic generation method is provided, and the present specification also relates to a battery management system host computer interface dynamic generation device, a computing device, a computer readable storage medium, and a computer program, which are described in detail one by one in the following embodiments.

[0028] Figure 1 A flow chart of a battery management system host computer interface dynamic generation method according to an embodiment of the present specification is shown, which specifically includes the following steps.

[0029] Step 102: Obtain parameter information of a plurality of battery parameters corresponding to a battery module in the battery management system.

[0030] Specifically, the plurality of battery parameters corresponding to the battery module include but are not limited to battery voltage, current, temperature, state of charge SOC, state of health SOH, etc., and support multiple data formats (such as uint, ulong, etc.). The parameter information contains the parameter value of the battery parameter.

[0031] The embodiment of the present specification can design a dynamic parameter analysis unit for real-time reading of parameter information of each battery module in the battery management system. In addition, the unit can realize the binding and dynamic update of the parameters by defining a dependency property (DependencyProperty), such as UIParaProperty.

[0032] Step 104: reading a configuration file generated by the user through self-defined configuration, and parsing the configuration file to obtain a template view corresponding to the parameter information and to obtain a binding relationship between different battery parameters and different template controls.

[0033] Specifically, the template control is used for display in the host computer interface and can be used to realize display and editing of the parameter information.

[0034] In actual application, the user can perform self-defined configuration on input mode, display position, display mode, whether can be edited and / or editing mode of each parameter information, and generate a corresponding configuration file.

[0035] In addition, since different template controls are needed to display different parameter information in the host computer interface, the embodiment of the present specification can also pre-construct a set of interface template library, which contains a plurality of preset interface layouts and template controls, such as data table, chart, editing pop-up window, etc. These template controls support dynamic binding data and can be self-defined according to user demand. For different template controls, ParaType_E enumeration can be used to distinguish different types of parameter input interfaces, such as charge and discharge self-check pop-up box, sampling line sequence pop-up box, etc.

[0036] The user can configure the relationship between the template controls in the interface template library and the parameter information to determine which template control is needed to display which parameter information, that is, to self-define the binding relationship between the template controls and the parameter information, which is also stored in the configuration file.

[0037] In addition, since the user can perform self-defined configuration on the display position of each parameter information, after the display position of each parameter information is configured, the display positions of the plurality of parameter information are combined to obtain a corresponding template view.

[0038] Therefore, after obtaining the parameter information of the plurality of battery parameters, the template view corresponding to the parameter information can be parsed from the configuration file generated by the user self-defined, and the binding relationship between different battery parameters and different template controls can be obtained.

[0039] The embodiment of the present specification provides user self-defined function, allowing the user to set interface layout, data display mode, alarm threshold, etc. according to his own operation habit and focus, thereby being beneficial to enhancing the flexibility of the interface.

[0040] In an optional implementation, the configuration file further contains control attribute configuration. Correspondingly, the method further comprises: A parameter control binding interface is provided, and a user operation is received through the parameter control binding interface to bind different battery parameters to different template controls. A property configuration interface of the template controls is provided, and a user operation is received through the property configuration interface to configure property parameters of each template control, wherein the property parameters include editing properties and parsing properties, and the editing properties include identifiers corresponding to read-only properties.

[0041] Specifically, as described above, the user can customize the binding relationship between the template controls and the parameter information, and the embodiments of the present specification provide a parameter control binding interface for the user, so that the user can perform relevant operations through the interface to bind different battery parameters to different template controls.

[0042] In addition, as described above, the user can customize the input method, display position, display method, whether it can be edited and / or editing method of each parameter information, therefore, the embodiments of the present specification can also provide a property configuration interface of the template controls for the user, so that the user can perform relevant operations through the interface to configure property parameters of each template control.

[0043] Since different parameter information and different template controls are bound, configuring the property parameters of the template controls is actually equivalent to configuring the parameter information bound to the template controls.

[0044] In practical applications, the property parameters include editing properties and parsing properties, and the editing properties include identifiers corresponding to read-only properties (ReadOnly properties). In the case that the identifier is "true" in the editing properties of any template control, it means that the template control is not editable, i.e., the parameter information bound to the template control is not editable. In the case that the identifier is "false" in the editing properties of any template control, it means that the template control is editable, i.e., the parameter information bound to the template control is editable. The parsing properties are used to indicate the parsing method of the template control, i.e., the parsing method of the parameter information bound to the template control.

[0045] In addition, the input method of the parameter information can be direct input or selection input, and the selection input is to select the content of one of the multiple options as input. The display method of the parameter information can be text display, table display or graphic display.

[0046] In the embodiments of the present specification, the dynamic parameter parsing unit realizes the binding of the parameters by defining a dependency property (DependencyProperty), such as UIParaProperty, and the binding is realized through the following steps: Step one: load the configuration file.

[0047] Specifically, the configuration file can be a JSON file.

[0048] Step two: parse the configuration file.

[0049] Step three: build a parameter data model according to the parsing result.

[0050] Specifically, the parameter data model is implemented by calling the corresponding code in the template library. When building, the program will use the corresponding code from the existing template library, and the final interface is generated by these codes.

[0051] Step four: parameter attribute extraction.

[0052] Specifically, the extraction of parameter attributes is a supplement to the template library, including the upper and lower limits of the agreed parameter settings, the displayed units, and the accuracy and offset to be used in subsequent parsing.

[0053] The extracted parameter attributes specifically include: ParaName: parameter name; ParaType: parameter type; ParaValue: parameter value; ParaUnit: unit; Precision: precision; Offset: offset; ReadOnly: read-only flag; ItemsName: drop-down list items.

[0054] Step five: classify and set different types of parameters through routing.

[0055] Specifically, for integer parameter processing, the specific configuration is as follows: Data format: integer; Precision: no decimal; Unit: set as needed; Display mode: integer text box; Editing mode: integer editing; Input limit: set upper and lower limits.

[0056] For floating-point parameter processing, the specific configuration is as follows: Data format: floating-point number; Precision: set as needed; Unit: set as needed; Display mode: decimal text box; Editing mode: decimal editing; Input limit: set upper and lower limits.

[0057] For the pull-down parameter processing, the specific configuration is as follows: Data format: integer; Precision: no decimal; Unit: set as; Display mode: pull-down box; Editing mode: pull-down box selection; Mapping relationship: integer -> pull-down text.

[0058] For special parameter processing, the specific configuration is as follows: Mapping relationship: value -> special display; Editing mode: corresponding special pop-up box.

[0059] Step six: data binding configuration.

[0060] Specifically, the binding configuration is as follows: Binding target: UIParaProperty; binding mode: TwoWay; data converter and verification rule.

[0061] Among them, since the original data of each parameter information is a string of bytes, the data converter needs to be converted to generate a parameter meaning that the user can recognize.

[0062] The verification rule corresponds to the input rule of different parameters, for example, if a certain battery parameter is a digital type, then when the parameter input is performed for this battery parameter, a string cannot be input, and when the input is performed for the IP address, the input content must comply with the IP rule.

[0063] Step seven: output parameter set.

[0064] Step 106: determining the target template control respectively bound with the plurality of battery parameters according to the binding relationship, and combining the target template control according to the template view to generate an initial host computer interface.

[0065] Specifically, after determining the target template control respectively bound with each battery parameter, the target template control is combined, that is, the target template control is arranged or placed according to the display position of the parameter information in the template view, to generate an initial host computer interface.

[0066] In an optional implementation, after obtaining the binding relationship between different battery parameters and different template controls, it further includes: According to the template view and based on the binding relationship, filtering the interface template meeting the condition in the pre-constructed interface template library, and determining the interface template as the initial host computer interface.

[0067] Specifically, as described above, the embodiment of the present specification provides an interface template library, which contains not only various template controls, but also a plurality of preset interface layouts, i.e., interface templates, each of which is generated by combining different template controls. Therefore, after obtaining the binding relationship between different battery parameters and different template controls, the binding relationship can be used to screen the interface template that meets the condition in the pre-constructed interface template library in combination with the template view, and the interface template is determined as the initial host computer interface.

[0068] If the interface template library contains a target interface template, the template controls contained in the target interface template are consistent with the template controls bound to each battery parameter, and the arrangement mode of each template control contained in the target interface template is consistent with the arrangement mode of each parameter information in the template view, the target interface template is determined as the interface template that meets the condition.

[0069] Step 108: Based on the binding relationship, the parameter information is dynamically filled into the target template control in the initial host computer interface to generate a target host computer interface for visual display.

[0070] Specifically, after the initial host computer interface is generated by combining the target template control according to the template view, the parameter information can be dynamically filled into the corresponding target template control in the initial host computer interface based on the binding relationship between the parameter information and the target template control in the initial host computer interface, so as to generate a target host computer interface and perform visual display.

[0071] In an optional embodiment, the method for dynamically generating a host computer interface of a battery management system further includes: In response to a click operation of a user on target parameter information in the target host computer interface, an identifier corresponding to a read-only attribute associated with the target parameter information is determined. If it is determined according to the identifier that the target parameter information is in an editable state, an editing popup window corresponding to the target parameter information is dynamically loaded.

[0072] The embodiment of the present specification can utilize the event-driven mechanism of WPF to realize the interactive function of the interface. For example, the ParaTextBlock_MouseDown event is used to process the user click operation and dynamically display the editing popup window; the EditPopup_MouseWheel event is used to process the scrolling operation and prevent the popup window from following the scrolling.

[0073] Based on this, when the user's click operation on the target parameter information in the target host computer interface is detected, in response to the click operation, the identifier corresponding to the read-only attribute associated with the target parameter information is determined; if the identifier is "false", it is determined that the target parameter information is in an editable state, in which case the editing pop-up window corresponding to the target parameter information can be dynamically loaded and displayed.

[0074] In addition, a dynamic UI generation unit can also be designed in the embodiments of the present specification, which can automatically select appropriate template controls according to real-time parameter changes of the battery management system, and dynamically fill the changed data into the template controls to realize the display of the changed data through the interface. For example, when the user clicks on the parameter, the corresponding editing pop-up window is dynamically loaded according to the ParaType type, and the editing content of the user is received through the editing pop-up window, and then the received editing content is filled into the template control for information updating and display. The specific updating and display process is realized through the following steps: Step one: receive the user-defined configuration file generated by JSON configuration.

[0075] Step two: judge the read-only attribute of the battery parameter according to the information in the configuration file.

[0076] Step three: based on the read-only attribute judgment result, add the read-only style or editing style corresponding to the battery parameter to the parameter group.

[0077] Step four: parameter grouping processing, control layout processing, creating GroupBox, setting group title, and configuring application group style are performed through the UI generation engine.

[0078] GroupBox is a container control in WPF for grouping related UI elements, and its core function is to classify logically related controls (such as form fields and device parameter items) through visual boundaries (border + title), improving the readability and neatness of the interface.

[0079] Step five: receive user editing operation.

[0080] Step six: edit data verification.

[0081] Step seven: edit data formatting.

[0082] Step eight: data update trigger.

[0083] Alternatively, after step four is executed, if it is detected that the sampling data has changed, the data update process can also be triggered.

[0084] Step nine: dependency property change callback.

[0085] Step ten: display update.

[0086] In an alternative embodiment, the method for dynamically generating the host computer interface of the battery management system further comprises: in response to an update instruction from the remote client, sending a file download request to the server, the file download request carrying a version number identifier of the battery management system, the file download request being used to request the server to determine a corresponding initial configuration file according to the version number identifier in the file download request; receiving the initial configuration file sent by the server.

[0087] In an alternative embodiment, the method for dynamically generating the host computer interface of the battery management system further comprises: in response to an update instruction from the remote client, sending a file download request to the server, the file download request carrying a battery parameter identifier of a battery block in the battery management system, the file download request being used to request the server to determine a corresponding initial configuration file and / or initial template control according to the battery parameter identifier in the file download request; receiving the initial configuration file and / or the initial template control sent by the server, and storing the initial template control to an interface template library.

[0088] In the embodiments of the present specification, the host computer supports remote update function, and the host computer interface can automatically download the latest template control and configuration file (initial configuration file before user performs self-defined configuration) from the server according to the version upgrade or parameter change of the battery management system, without manual intervention. Meanwhile, the system also has remote maintenance function, and the technical personnel can perform fault diagnosis and optimization adjustment on the host computer interface through the network.

[0089] The embodiment of the present specification acquires parameter information of a plurality of battery parameters corresponding to a battery module in a battery management system; reads a configuration file generated by a user through self-defined configuration, and parses the configuration file to obtain a template view corresponding to the parameter information, and obtain a binding relationship between different battery parameters and different template controls; determine target template controls respectively bound to the plurality of battery parameters according to the binding relationship, and combine the target template controls according to the template view to generate an initial host computer interface; based on the binding relationship, the parameter information is dynamically filled into the target template control in the initial host computer interface to generate a target host computer interface for visual display. In this way, the battery parameters and the information interface can be dynamically constructed, so as to realize the dynamic generation, efficient maintenance and real-time response of the host computer interface, and the host computer interface can be automatically adjusted according to the change of the battery parameters, without frequent version update and customized development, thereby improving the overall performance and user experience of the battery management system.

[0090] In addition, the target control associated logical picture can also be recognized in response to the user's click operation on the target control in the interface, and the target template picture associated with the logical picture is determined; In the case that it is determined through detection that the target template picture has been loaded in the memory of the battery management system, the data point bound to the first template control in the target template picture and the first grouping mark are determined, and the second grouping mark bound to the second template control in the target template picture is determined; The first binding relationship between the first grouping mark stored in the logical picture and the energy storage device is acquired, and the second binding relationship between the second grouping mark stored in the logical picture and the text to be displayed is acquired; Based on the first binding relationship, the parameters of the first template control are replaced with the corresponding parameters of the energy storage device at the data point, and based on the second binding relationship, the parameters of the second template control are replaced with the text to be displayed; The picture instance after parameter replacement is rendered and displayed on the operation interface to complete the configuration picture configuration.

[0091] Among them, the actual picture refers to the configuration picture which exists independently and has complete configuration data. Such a picture does not depend on any template, and all its configuration information is stored in its independent configuration file.

[0092] The template picture refers to a pre-defined configuration picture prototype. In this picture, all data-bound controls need to be grouped and labeled according to the preset rules. The template picture has an independent configuration file, which serves as the basis for generating other pictures.

[0093] A logical screen refers to a virtual screen generated based on a template screen and through a device replacement mechanism. Unlike the two aforementioned screens, a logical screen has no independent configuration file in a storage path, and its essence is to store a mapping relationship between a "template screen" and a "target device" and a parameter replacement rule.

[0094] A screen tree is used to describe a logical model of a navigation relationship between screens in a configuration interface. It is constructed in a manner that, starting from a main interface (root node) as a trunk, a series of branch screens (child nodes) are derived through jump logic configured on a control. All these screens, including the actual screen as the trunk and the logical screen or the actual screen as the branch, jointly form a complete screen tree. In addition, the screen tree supports a nested sub-tree structure, and each branch can exist as an independent screen tree, forming a hierarchical navigation network.

[0095] In an optional implementation, in a case where it is determined that the target template screen is not loaded in the system memory, the target template screen and the binding content of the target template screen are read according to a specified path; The binding content is parsed to obtain a data point and a first grouping tag bound to a first template control in the target template screen, and a second grouping tag bound to a second template control in the target template screen is parsed; The target template screen and the parsing result are loaded into the system memory.

[0096] Specifically, the operation interface includes a plurality of controls, and the control clicked by the user is the target control; the first grouping tag can be a data grouping tag, and the second grouping tag can be a constant grouping tag.

[0097] The aforementioned process of visual data loading and rendering of the configuration screen is mainly for a logical screen, and specifically includes the following contents: (1) On-demand loading and instantiation of a logical screen, when the operation interface needs to jump to a logical screen, the following sub-steps are performed: 1) Identify the target template screen associated with the logical screen, wherein the target template screen is one of a plurality of pre-generated template screens; 2) Check whether the target template screen has been loaded in the memory; 3) If not, read the configuration file of the target template screen from a specified path, and load the control information, data binding content and grouping tag structure therein into the memory; 4) If it has been loaded, directly read the data points and / or grouping tags bound to each template control in the target template from the memory; 5) According to the binding relationship between the pre-stored group mark of the logical picture and the energy storage device or the to-be-displayed text, the parameter binding of each template control in the target template picture is replaced by the corresponding parameter of the energy storage device or the corresponding to-be-displayed text; 6) The target template picture after the parameter replacement is instantiated, and is rendered and displayed on the operation interface, so as to complete the configuration picture configuration.

[0098] (2) Memory residence and reuse mechanism of the template picture: 1) Once the template picture is loaded into the memory, it is continuously resident in the entire running cycle of the operation interface; 2) When other logical pictures of the same template need to be generated subsequently, the system directly reuses the template picture information in the resident memory, and only performs the parameter replacement operation, so as to avoid repeated analysis overhead.

[0099] (3) Single loading principle of picture resources: all picture resources with independent configuration files, including actual pictures and template pictures, follow the single loading principle during the operation interface running period; subsequent picture switching only involves changing the display state, and does not need to reload the picture resources.

[0100] (4) Dynamic subscription and queue management of data points: 1) During the operation interface running, only the data points required by the current active picture are subscribed and processed; 2) The data points associated with the inactive picture are temporarily removed from the real-time data processing queue; 3) This dynamic management mechanism ensures that system resources are concentrated on current display requirements, avoiding performance bottlenecks caused by invalid data processing.

[0101] The above processing manner of the embodiments of the present specification can realize stable memory occupation, the same template picture is loaded only once in the running cycle, and the instantiation process of the subsequent logical picture is only parameter replacement, which effectively controls the memory growth of the operation interface, and improves the system stability. In addition, based on the instantiated template picture in the memory, repeated file analysis overhead is avoided, so that the picture switching and loading speed is improved by orders of magnitude, that is, the picture response speed is improved. In addition, the operation interface adopts a dynamic subscription mechanism, only processes the data points required by the current active picture, avoids communication congestion and processing delay caused by massive irrelevant data refreshing, ensures the refreshing efficiency and real-time performance of the core data, so that the data flow can be more efficient and accurate.

[0102] In an optional implementation, at least two template controls can also be added in the initial template picture according to the visualization requirement. binding data points, display parameters and control parameters to the template control of the target type, wherein the template control of the target type is used for dynamically displaying data, and the display parameters and the control parameters can be associated with the same data point or different data points; binding group labels to the at least two template controls; After the binding is completed, the initial template picture and the binding content are stored according to a specified path.

[0103] Further, the group labels include data group labels and constant group labels. Correspondingly, the binding of the group labels to the at least two template controls includes: binding data group labels to the template control of the target type and binding constant group labels to other types of template controls, wherein the other types of template controls are template controls other than the template control of the target type in the at least two template controls, and the other types of template controls are not used for dynamically displaying data.

[0104] Specifically, before visual data loading and rendering of the configuration picture are performed, template picture generation needs to be performed first, and a specific template picture generation process is as follows: (1) Picture configuration: according to the visual demand, various types of controls (such as data text boxes, state indicator lights, trend curves, etc.) are configured on the initial template picture, so as to present data in a diversified and intuitive form.

[0105] (2) Parameter binding: data points are bound to the controls (i.e. the template control of the target type) in the picture that need to dynamically display data. Each control can be bound to display parameters (used for state monitoring) and control parameters (used for instruction issuing) respectively; the two can be associated with the same data point, or can be respectively directed to different data points.

[0106] (3) Group label: data group labels are set for the controls that have bound data points, and the labels will be used as the logical basis for subsequent device parameter replacement. In addition, for the controls (such as static text labels) that do not need to bind data points, constant group labels can be set to realize batch replacement of fixed display content. In the template picture, the system automatically divides the controls with the same labels into the same group according to the group labels set by the controls.

[0107] (4) After the binding is completed, the initial template picture and the binding content are stored according to a specified path.

[0108] It should be noted that, according to the visualization requirement, at least two template controls are added in the initial template picture in the embodiments of the present specification, but in actual application, the number of template controls added in the initial template picture can be one, or no template control can be added in part of the initial template picture. The number of template controls added can be determined according to actual requirements, and no limitation is made herein.

[0109] In an optional embodiment, each grouping mark defined in the initial template picture can also be traversed, and a configuration requirement is shown to the user based on each grouping mark, wherein the configuration requirement of the data grouping mark includes binding an energy storage device for each data grouping mark, and the configuration requirement of the constant grouping mark includes binding a to-be-displayed text for each constant grouping mark. Configuration information submitted by the user based on the configuration requirement is received, and a logical picture is generated based on the initial template picture and the configuration information, wherein the logical picture includes a first binding relationship between the data grouping mark and the energy storage device and a second binding relationship between the constant grouping mark and the to-be-displayed text.

[0110] Further, before the step of traversing each grouping mark defined in the initial template picture, the method further includes: determining a jump relationship between different controls in each picture related to the system and different pictures, and constructing a picture tree based on the jump relationship; detecting whether the picture type of the next jump target of any one control in the picture at the current level in the picture tree is a template picture; If yes, the step of traversing each grouping mark defined in the initial template picture is executed.

[0111] In addition, after the step of generating a logical picture based on the initial template picture and the configuration information, the method further includes: determining the next jump target of any one control as an intermediate template picture, and detecting whether the picture type of the next jump target of any one control in the intermediate template picture is a template picture; If yes, the step of traversing each grouping mark defined in the initial template picture is returned to be executed.

[0112] In addition, a constraint condition can also be set for the level to which the next jump target of each control in the template picture belongs, wherein the constraint condition includes that each control in the template picture is prohibited from jumping to a picture at a higher level in the picture tree.

[0113] Specifically, the pictures related to the system include actual pictures and template pictures; and the picture at the current level in the picture tree is an actual picture.

[0114] After the template screen is generated, the screen tree and logical screen can be constructed. The specific processing steps are as follows: (1) Jump screen binding In the configuration screen, controls in the actual screen and template screen can be configured to jump to the next level target screen. Therefore, a screen tree can be constructed by determining the jump relationships between different controls in each screen related to the system and different screens, and based on the jump relationships.

[0115] After the image tree is constructed, it is necessary to determine whether the root node, i.e., the first-level image, is an actual image. This is because different processing logic will be triggered depending on the type of the first-level image. 1) The first-level screen is a template screen: you only need to specify the target screen of the next level for the controls in this screen, and do not immediately generate a specific logic screen.

[0116] 2) The first-level screen is the actual screen: This indicates that the screen is already in the main hierarchy of the screen tree (first level). If the next-level jump target configured for any control in this type of screen is a template screen, the following logical screen generation process will be automatically triggered.

[0117] 3) Constraints: To avoid infinite loops, controls in a template screen are prohibited from jumping to higher-level screens (i.e., closer to the main branch) in the screen tree. For example, if a template screen is at the third level in the screen tree, then the controls in that template screen can only jump to the fourth level or other levels of the template screen or actual screen in the screen tree, but cannot jump to the second level or the first level of the template screen or actual screen.

[0118] (2) Logical screen generation process When the system transitions from the actual screen to the template screen (second layer), it initiates the logical screen generation process: 1) Parameter Configuration: The system will iterate through all group tags defined in the initial template screen and prompt the user for configuration: ① Data group tagging: Each data group tag needs to be bound to a specific energy storage device.

[0119] ② Constant grouping tags: For each constant grouping tag, a fixed display text (the text to be displayed) must be specified.

[0120] ③ Recursive generation: After completing the configuration of the current layer, if the controls in the template screen further jump to the next layer template screen (the third layer), the above configuration process needs to be repeated recursively based on the grouping mark of the third layer template.

[0121] 2) Process Termination: This recursive generation process continues until any termination condition is met: ① Reach the lowest-level template screen that no longer contains jump controls.

[0122] ②The next target is the actual screen (at this time, you will be directly redirected to the actual screen).

[0123] Once the logic screen is generated, the aforementioned process of loading and rendering visualization data for the configuration screen can be performed.

[0124] In practical applications, the configuration screen configuration of the embodiments in this specification is implemented in the following software environment: the system runs on the Linux operating system, uses C++ as the core development language, its configuration screen is built on the Qt framework, and the system configuration and mapping relationship data are stored in a MySQL database.

[0125] The following section will explain in detail the implementation steps of this solution, in conjunction with the system operation process.

[0126] 1. Creation and definition of template screens (1) The user opens the configuration tool and creates a new screen.

[0127] (2) Drag four text controls from the control library to the canvas and name them TextNode_0, TextNode_1, TextNode_2 and TextNode_3 respectively.

[0128] (3) Perform the following operations on the TextNode_0 control: 1) Right-click and select "Data Binding" to configure a data point for it. This data point can be the current state of the energy storage converter PCS.

[0129] 2) Right-click and select "Data Grouping Marker" to set a grouping mark for it. The mark name is equip1.

[0130] 3) Perform the following operations on the TextNode_1 control: Bind to another data point of the same device type as TextNode_0.

[0131] Set the same data grouping tag equip1 as TextNode_0.

[0132] 4) Perform the following operations on the TextNode_2 control: Bind other data points of the same device type as TextNode_0.

[0133] Set a new data grouping tag equip2.

[0134] 5) Perform the following operations on the TextNode_3 control: Right-click and select "Constant Grouping Marker", then set the marker name to const.

[0135] 6) After completing the configuration, the user specifies the screen type as "Template Screen" and names it "equip diagram" before saving. The system stores the configuration file for this template screen in the specified path.

[0136] 2. Screen Tree Construction and Logical Screen Generation (1) Place two text controls, TextNode_4 and TextNode_5, on the main screen of the system (actual screen).

[0137] (2) Configure jump logic for the TextNode_4 control: 1) Right-click and select "Screen Jump Settings". In the dialog box, select the template screen equipdiagram created in step 1. The system will then pop up the "Logical Screen Generation Dialog Box", which lists all the grouping tags of the template: data group equip1, equip2 and constant group const.

[0138] 2) Users should configure the following: ① Bind device a to equip1; ② Bind device b to equip2; ③ Specify the text "123" for const.

[0139] 3) Name the logical screen "logical 1" and confirm. The system stores the mapping relationship of this logical screen in the database instead of generating a separate file.

[0140] 4) Similarly, configure the TextNode_5 control to jump to the same template screen and generate another logical screen logical 2. The mapping relationship is as follows: ①equip1 binds to device c; ②equip2 binds to device d; ③ const specifies the text "456".

[0141] 3. Visual loading and dynamic rendering (1) The user starts the operation interface and enters the main interface.

[0142] (2) Clicking the TextNode_4 control triggers the following process: 1) The system identifies the target as logical screen 1 and obtains its associated template screen equipdiagram and its stored mapping relationship.

[0143] 2) The system checks whether the template screen has been loaded into memory. If it has not been loaded, the system reads the configuration file from the storage path and parses it into memory; if it has been loaded, it is reused directly.

[0144] 3) The system dynamically replaces parameters on the template image copy in memory based on the mapping relationship: ① The data points of the control (TextNode_0, TextNode_1) marked as equip1 are replaced with the corresponding parameters of device a.

[0145] ② The data points of the control marked as equip2 (TextNode_2) are replaced with the corresponding parameters of device b.

[0146] ③ The control marked as const (TextNode_3) has its displayed text replaced with "123".

[0147] ④ Render and display the replaced screen instance.

[0148] 4) When the user returns to the main interface and clicks the TextNode_5 control, the system will reuse the template screen equipment diagram that has been resident in memory, and quickly generate and display a new screen instance that binds device c, device d and text "456" according to the mapping relationship of logical 2.

[0149] It should be noted that the embodiments in this specification are only illustrative examples of the four controls TextNode_0, TextNode_1, TextNode_2 and TextNode_3, the three group tags equip1, equip2 and const, the device a, device b and the text "123", the device c, device d and the text "456". The specific number of controls, the number of group tags, and the bound devices and text can be determined according to actual needs and are not limited here.

[0150] This specification aims to address the repetitive configuration work in existing configuration methods for the same device type, as well as the problems of configuration redundancy, high resource consumption, and low maintenance efficiency caused by the increase in the number of devices. Its core lies in introducing a screen architecture that combines template screens, logical screens, and actual screens. By predefining template screens containing devices under certain device types, batch reuse of configuration screens is achieved. First, template screens with defined group tags are created. Then, when the user jumps from the actual screen to the template screen, a data flow for dynamically replacing parameters in the logical screen is triggered. The system dynamically binds corresponding parameters to the controls on the template screen according to the target device bound by the user to the group tag, forming a virtual logical screen. This screen only stores the mapping relationship and has no independent configuration file.

[0151] This specification's embodiments create template screens and configure a device for each group on the template screen based on the device type and template group of all bound data points on the template screen. This enables rapid generation and unified maintenance of configuration screens, thereby effectively reducing redundant configurations, lowering system load, and improving screen loading and switching efficiency.

[0152] Figure 2 A flowchart of an interface update process provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0153] Step 202: Load the interface template library.

[0154] Step 204: Read the parameter information of the battery management system.

[0155] Step 206: Parse the parameter type and parameter value.

[0156] Step 208: Match template controls based on parameter type.

[0157] Step 210: Check if the parameter structure is complete.

[0158] Specifically, if the result of step 210 is yes, then step 212 is executed; if the result of step 210 is no, then step 214 is executed.

[0159] Step 212: Dynamically generate and display the host computer interface.

[0160] Specifically, after step 212 is completed, proceed to step 216 or step 218.

[0161] Step 214: Error returned.

[0162] Step 216: Wait for user action.

[0163] Specifically, after step 216 is completed, continue with step 220.

[0164] Step 218: Read the latest parameter information.

[0165] Specifically, after step 218 is completed, continue with step 222.

[0166] Step 220: Parse whether the user input matches the parameter type.

[0167] Specifically, if the result of step 220 is yes, then step 222 is executed; if the result of step 220 is no, then step 224 is executed.

[0168] Step 222: Update interface information.

[0169] Step 224: Input error message.

[0170] Figure 3 A flowchart of another interface update process provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0171] Step 302: Check whether the host computer is bridged to the cloud server.

[0172] Specifically, if the result of step 302 is yes, then step 304 is executed; if the result of step 302 is no, then step 306 is executed.

[0173] Step 304: Check if the cloud server has updated configuration files.

[0174] Specifically, if the result of step 304 is yes, then step 310 is executed, and step 304 is repeated according to the inspection cycle.

[0175] Step 306: The interface displays "bridging failed".

[0176] Step 308: Attempt to reconnect.

[0177] Specifically, after step 308 is completed, the process returns to step 302.

[0178] Step 310: Download the latest configuration file and record the update flag.

[0179] Step 312: Restart the software to load the updated configuration file.

[0180] Step 314: Regenerate the interface.

[0181] Step 316: Dynamically generate and display the host computer interface.

[0182] Corresponding to the above method embodiments, this specification also provides an embodiment of a device for dynamically generating the host computer interface of a battery management system. Figure 4 This specification illustrates a schematic diagram of a device for dynamically generating a host computer interface for a battery management system, according to one embodiment of this specification. Figure 4 As shown, the device includes: The acquisition module 402 is configured to acquire parameter information of multiple battery parameters corresponding to the battery modules in the battery management system; The reading module 404 is configured to read the configuration file generated by the user through custom configuration, parse the configuration file, obtain the template view corresponding to the parameter information, and obtain the binding relationship between different battery parameters and different template controls; The first generation module 406 is configured to determine target template controls that are respectively bound to the plurality of battery parameters according to the binding relationship, and combine the target template controls according to the template view to generate an initial host computer interface; The second generation module 408 is configured to dynamically fill the parameter information into the target template control in the initial host computer interface based on the binding relationship, thereby generating a target host computer interface for visualization.

[0183] Optionally, the device for dynamically generating the host computer interface of the battery management system further includes: The processing module is configured to filter out interface templates that meet the conditions from a pre-built interface template library according to the template view and based on the binding relationship, and determine the interface template as the initial host computer interface.

[0184] Optionally, the configuration file may also include control property configurations; Accordingly, the processing module is further configured as follows: A parameter control binding interface is provided, and user operations are received through the parameter control binding interface to bind different battery parameters with different template controls; A property configuration interface for template controls is provided, and user operations are received through the property configuration interface to configure the property parameters of each template control. The property parameters include: editable properties and parsed properties, and the editable properties contain the identifier corresponding to the read-only properties.

[0185] Optionally, the processing module is further configured to: In response to a user's click operation on target parameter information in the target host computer interface, determine the identifier corresponding to the read-only attribute associated with the target parameter information; If the target parameter information is determined to be editable based on the identifier, an editing pop-up window corresponding to the target parameter information is dynamically loaded.

[0186] Optionally, the processing module is further configured to: In response to an update command from a remote client, a file download request is sent to the server. The file download request carries a version number identifier of the battery management system. The file download request is used to request the server to determine the corresponding initial configuration file based on the version number identifier in the file download request. Receive the initial configuration file sent by the server.

[0187] Optionally, the processing module is further configured to: In response to an update command from a remote client, a file download request is sent to the server. The file download request carries the battery parameter identifier of the battery block in the battery management system. The file download request is used to request the server to determine the corresponding initial configuration file and / or initial template control based on the battery parameter identifier in the file download request. Receive the initial configuration file and / or the initial template control sent by the server, and store the initial template control in the interface template library.

[0188] The above is a schematic scheme of a host computer interface dynamic generation device for a battery management system according to this embodiment. It should be noted that the technical solution of this host computer interface dynamic generation device for a battery management system and the technical solution of the above-described host computer interface dynamic generation method for a battery management system belong to the same concept. For details not described in detail in the technical solution of the host computer interface dynamic generation device for a battery management system, please refer to the description of the technical solution of the above-described host computer interface dynamic generation method for a battery management system.

[0189] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0190] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0191] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0192] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 500 can also be a mobile or stationary server.

[0193] The processor 520 is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described method for dynamically generating the host computer interface of the battery management system.

[0194] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described method for dynamically generating the host computer interface of a battery management system belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described method for dynamically generating the host computer interface of a battery management system.

[0195] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described method for dynamically generating the host computer interface of the battery management system.

[0196] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described method for dynamically generating the host computer interface of the battery management system. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described method for dynamically generating the host computer interface of the battery management system.

[0197] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described method for dynamically generating the host computer interface of the battery management system.

[0198] The above is an illustrative scheme of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the above-described method for dynamically generating the host computer interface of the battery management system belong to the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-described method for dynamically generating the host computer interface of the battery management system.

[0199] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0200] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0201] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0202] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0203] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for dynamically generating a host computer interface for a battery management system, comprising: Obtain parameter information for multiple battery parameters corresponding to the battery module in the battery management system; Read the configuration file generated by the user through custom configuration, parse the configuration file to obtain the template view corresponding to the parameter information, and obtain the binding relationship between different battery parameters and different template controls; Based on the binding relationship, target template controls are determined to be bound to the multiple battery parameters respectively, and the target template controls are combined according to the template view to generate the initial host computer interface; Based on the binding relationship, the parameter information is dynamically filled into the target template control in the initial host computer interface to generate a target host computer interface for visualization.

2. The method for dynamically generating the host computer interface of the battery management system according to claim 1, after obtaining the binding relationship between different battery parameters and different template controls, further includes: According to the template view and based on the binding relationship, select the interface template that meets the conditions from the pre-built interface template library, and determine the interface template as the initial host computer interface.

3. The method for dynamically generating the host computer interface of the battery management system according to claim 1, wherein the configuration file further includes control attribute configuration; Accordingly, the method further includes: A parameter control binding interface is provided, and user operations are received through the parameter control binding interface to bind different battery parameters with different template controls; A property configuration interface for template controls is provided, and user operations are received through the property configuration interface to configure the property parameters of each template control. The property parameters include: editable properties and parsed properties, and the editable properties contain the identifier corresponding to the read-only properties.

4. The method for dynamically generating the host computer interface of the battery management system according to claim 1 or 3 further includes: In response to a user's click operation on target parameter information in the target host computer interface, determine the identifier corresponding to the read-only attribute associated with the target parameter information; If the target parameter information is determined to be editable based on the identifier, an editing pop-up window corresponding to the target parameter information is dynamically loaded.

5. The method for dynamically generating the host computer interface of the battery management system according to claim 1 further includes: In response to an update command from a remote client, a file download request is sent to the server. The file download request carries a version number identifier of the battery management system. The file download request is used to request the server to determine the corresponding initial configuration file based on the version number identifier in the file download request. Receive the initial configuration file sent by the server.

6. The method for dynamically generating the host computer interface of the battery management system according to claim 1 further includes: In response to an update command from a remote client, a file download request is sent to the server. The file download request carries the battery parameter identifier of the battery block in the battery management system. The file download request is used to request the server to determine the corresponding initial configuration file and / or initial template control based on the battery parameter identifier in the file download request. Receive the initial configuration file and / or the initial template control sent by the server, and store the initial template control in the interface template library.

7. A device for dynamically generating a host computer interface for a battery management system, comprising: The acquisition module is configured to acquire parameter information of multiple battery parameters corresponding to the battery modules in the battery management system; The reading module is configured to read the configuration file generated by the user through custom configuration, parse the configuration file to obtain the template view corresponding to the parameter information, and obtain the binding relationship between different battery parameters and different template controls; The first generation module is configured to determine target template controls that are respectively bound to the multiple battery parameters according to the binding relationship, and combine the target template controls according to the template view to generate an initial host computer interface; The second generation module is configured to dynamically fill the parameter information into the target template control in the initial host computer interface based on the binding relationship, thereby generating a target host computer interface for visualization.

8. The host computer interface dynamic generation device for the battery management system according to claim 7 further includes: The processing module is configured to filter out interface templates that meet the conditions from a pre-built interface template library according to the template view and based on the binding relationship, and determine the interface template as the initial host computer interface.

9. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the method for dynamically generating the host computer interface of the battery management system according to any one of claims 1 to 6.

10. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method for dynamically generating a host computer interface of the battery management system according to any one of claims 1 to 6.

Images