A battery management system human-computer interaction method and system based on an embedded Web architecture

Abstract

This invention discloses a human-computer interaction method and system for a battery management system based on an embedded web architecture. The method includes: deploying a lightweight Nginx server in the embedded system of the BMS battery management system; responding to user input of the BMS device IP and a user request, the Nginx web service determines the type of the user request; if the user request is a static resource request, the Nginx web service processes the user request; if the user request is an HTTP request starting with "API", the user request is forwarded to the HTTP service; the HTTP service performs routing based on a preset routing table and calls the target module in the hardware driver layer to execute the user request. This method facilitates deployment, eliminating the need for users to install or update dedicated software, and significantly reducing deployment and training costs.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction technology, and in particular to a human-computer interaction method and system for a battery management system based on an embedded Web architecture. Background Technology

[0002] Currently, traditional Battery Management Systems (BMS) typically use local desktop applications as the host computer software. These applications establish direct communication connections with the BMS devices to monitor battery data, configure parameters, diagnose faults, and upgrade software. While this approach was widely used in early BMS systems, its inherent limitations have become increasingly apparent as system scale expands, devices become more widely distributed, and users demand greater ease of operation and real-time performance. These limitations are mainly manifested in the following aspects: Firstly, deployment is complex and updates are cumbersome: traditional solutions require the development and maintenance of separate host computer software versions for different BMS versions. Even if only a few parameters are adjusted or functions are optimized, it is necessary to recompile, release, and guide users to manually install and update, resulting in high development and testing costs and low efficiency in system iteration and responding to user needs.

[0003] Secondly, maintenance costs are high and management is difficult: software upgrades rely on users actively downloading and installing update packages, lacking a centralized version management and automatic distribution mechanism. In large-scale deployment scenarios, version fragmentation is severe, making it difficult for the operations and maintenance team to uniformly monitor software status, implement batch upgrades, or promptly fix security vulnerabilities, resulting in poor overall system maintainability.

[0004] Thirdly, there is a lack of cross-platform and multi-terminal support: traditional desktop applications are usually designed for specific platforms and are difficult to seamlessly adapt to different operating systems and hardware environments. Especially with the increasing popularity of mobile office and on-site maintenance, users expect to access the BMS anytime via mobile devices such as mobile phones and tablets, but traditional solutions often fail to provide good cross-platform compatibility and responsive interactive experience.

[0005] Fourthly, the interactive interface is rigid and poorly adaptable: traditional host computer interfaces mostly adopt fixed layouts and control designs, making it difficult to adapt to display devices with different resolutions (such as large-screen monitoring, portable terminals, etc.), and also unable to flexibly support new interaction methods such as touch and gestures. This limits the optimization of user experience and the improvement of operational efficiency, especially in environments with multiple scenarios and multiple roles working together.

[0006] Fifthly, software and hardware version coordination is difficult, and consistency in operation and maintenance is hard to guarantee: Since the host computer software and the BMS embedded system are usually developed and released independently by different teams, their version iteration rhythms and feature updates are often out of sync. In actual use, users may experience functional abnormalities, communication failures, or even system failures due to version incompatibility, which brings significant difficulties and additional costs to on-site debugging, troubleshooting, and system operation and maintenance.

[0007] Therefore, developing a lightweight, cross-platform, easy-to-deploy and maintain BMS human-machine interaction system that can achieve collaborative management of front-end and back-end versions has become an urgent need to improve the intelligent operation and maintenance level and user experience of energy storage systems. Summary of the Invention

[0008] The purpose of this invention is to provide a human-computer interaction method and system for a battery management system based on an embedded web architecture, which can solve at least one of the above-mentioned problems in the prior art.

[0009] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a human-computer interaction method for a battery management system based on an embedded web architecture, wherein the method includes: A lightweight Nginx server is deployed in the embedded system of the BMS battery management system. The Nginx server includes an Nginx web service and an HTTP service, and the HTTP service is embedded in the main program of the BMS embedded system. In response to the BMS device IP and user request input by the user, the Nginx Web service determines the type of the user request; If the user request is a static resource request, the Nginx Web service processes the user request; If the user request is an HTTP request starting with "API", the user request will be forwarded to the HTTP service. The HTTP service forwards the request based on a preset routing table and calls the target module in the hardware driver layer to execute the user request.

[0010] Optionally, the steps of deploying a lightweight Nginx server in the embedded system of the BMS battery management system include: Install the Nginx Web service in the BMS embedded system environment using a package management tool, and configure it to start automatically on boot. Start the Nginx web service and verify its running status; Configure the reverse proxy function of the Nginx web service to forward HTTP requests starting with "API" to the locally running BMS backend HTTP service.

[0011] Optionally, the HTTP service performs routing forwarding based on a preset routing table, and the step of calling the target module in the hardware driver layer to execute the user request includes: When an HTTP request is received, the HTTP service allocates a session structure for the HTTP request, wherein the session structure is used to store the context data of the HTTP request; If the HTTP request contains uploaded data, the HTTP service receives the uploaded data and stores the received data in the buffer until the HTTP request containing the uploaded data has been uploaded. The HTTP service calls a unified API dispatch function, which calls the corresponding business processing function based on the HTTP request content and the preset routing table. The HTTP request is executed by calling the target module in the hardware driver layer through the business processing function. The HTTP service receives the response data returned by the business processing function, encapsulates the response data into an HTTP response, sets the header fields in a preset format, and then returns it to the client.

[0012] Optionally, the steps of the HTTP service calling a unified API dispatch function and invoking the corresponding business processing function based on the HTTP request content and a preset routing table include: The HTTP service calls a unified API dispatch function, which searches for the corresponding business processing function in a preset routing table based on the interface name specified in the URL corresponding to the HTTP request; wherein, the preset routing table includes: the correspondence between interface and business processing function pointers; If a matching business processing function pointer is found, the business processing function pointed to by the matching business processing function pointer is called; If no matching business processing function is found, an error message is returned, indicating that the corresponding interface does not exist.

[0013] Optionally, the step of the Nginx Web service determining the type of the user request in response to the user-inputted BMS device IP and user request includes: The system receives access requests from clients, determines the corresponding CSS style rules for each client, and displays the browser interface according to the CSS style rules. Different CSS style rules are predefined for different types of client devices and different screen sizes of the same type. The system login page is displayed in response to the BMS device IP entered by the user in the browser interface; After completing system login, receive access requests entered by the user through the client; The Nginx web service determines the type of the user request.

[0014] Optionally, the method further includes: Different CSS style rules are set for different types of client devices, and for the same type of client device with different screen sizes; the client devices are divided into different types based on their screen size. Adaptive layout of the display interface for different types of client devices; Configure adaptive settings for different interface components, including: data icons, buttons, and interactive elements.

[0015] Optionally, the client types include: small-screen devices, medium-screen devices, and large-screen devices; the steps for adaptive layout of the display interface for different types of client devices include: On small-screen devices, the interface adopts a single-column layout, the navigation menu is collapsed, and the table data is switched to a card-style display; On mid-screen devices, the interface adopts a dual-column grid layout to increase the density of information display; On large-screen devices, the interface uses an N-column grid layout, where N ≥ 3.

[0016] Optionally, the method further includes: After logging into the system, the system receives control operations from the user in the web interface, including parameter modification, BMS firmware upgrade, file upload, and file download. In response to the control operation, the system responds and automatically executes the control operation.

[0017] Optionally, the method further includes: The system monitors whether the current web interface matches the BMS firmware version; If they do not match, a boot upgrade prompt message will be output; Receive BMS firmware upgrade packages uploaded by users through the web interface, and verify the version compatibility of the BMS firmware upgrade packages; If the verification passes, the BMS firmware version and Web interface components are updated synchronously to ensure version compatibility.

[0018] This invention also provides a battery management system human-computer interaction system based on an embedded web architecture. The system includes a battery management system (BMS), and a lightweight Nginx server is deployed within the embedded BMS. The Nginx server includes an Nginx web service and an HTTP service, with the HTTP service embedded in the main program of the embedded BMS. The battery management system human-computer interaction system based on the embedded web architecture is used to execute any of the aforementioned battery management system human-computer interaction methods based on the embedded web architecture.

[0019] The human-machine interaction solution for a battery management system based on an embedded web architecture provided in this invention offers several advantages. First, it simplifies deployment, eliminating the need for users to install or update dedicated software, significantly reducing deployment and training costs. Second, it supports various operating systems and terminal devices, making it particularly suitable for mobile inspections and remote collaboration scenarios, achieving full cross-platform coverage. Third, it provides a customizable web interface, supporting real-time data visualization and operational feedback, enhancing the user experience. Fourth, it features a unified management entry point and real-time communication mechanism, supporting remote diagnostics, batch configuration, log tracing, and other functions, making operation and maintenance more intelligent and improving system maintainability. Fifth, it enables integrated version management, specifically through the association and collaborative updates of the front-end interface and BMS firmware versions, ensuring system functional integrity and operational stability. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the steps of a human-computer interaction method for a battery management system based on an embedded web architecture, according to an embodiment of this application. Figure 2 This is a schematic diagram of access and interaction in a BMS system based on an embedded web architecture; Figure 3 This is a schematic diagram of the collaborative upgrade process between the Web front-end and the BMS firmware. Detailed Implementation

[0021] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0022] This application addresses at least one of the following problems existing in the interaction layer of the Battery Management System (BMS) in current energy storage systems, and proposes a human-computer interaction system and method for a Battery Management System (BMS) based on an embedded Web architecture. The problems of the existing technology are as follows: Deployment and update efficiency is low: Traditional host computers rely on local installation, different operating systems need to be developed independently, and version updates require manual intervention from users, which cannot achieve rapid iteration and unified distribution.

[0023] Weak cross-platform and multi-terminal support: It is difficult to adapt to various terminals such as Windows, Linux, Mac and mobile devices, which limits the flexibility of on-site operation and maintenance and remote monitoring.

[0024] Fixed human-computer interaction experience: The interface layout is fixed and cannot adapt to different screen sizes and interaction methods, resulting in poor user experience consistency.

[0025] Disconnect between hardware and software version management: The host computer and BMS firmware versions evolve independently, which can easily lead to communication abnormalities, functional failures or system instability caused by version mismatch.

[0026] Low efficiency in operation and maintenance collaboration and diagnosis: There is a lack of a unified entry point and real-time interaction mechanism. Operations such as fault diagnosis, parameter adjustment, and log acquisition rely on on-site personnel or special tools, resulting in high response latency.

[0027] To address the aforementioned issues, this invention proposes an embedded web-based BMS human-computer interaction system, aiming to achieve a novel interaction mode of "one-time development, multi-terminal adaptation, real-time management, and version collaboration." This solution constructs the BMS device as an intelligent terminal with web service capabilities, enabling a lightweight human-computer interaction solution that requires no dedicated client installation, is cross-platform, and can be accessed in real time, thereby significantly improving the accessibility, maintainability, and user experience of the BMS system.

[0028] The following description, in conjunction with the accompanying drawings, details the human-computer interaction scheme for a battery management system based on an embedded Web architecture provided in this application, through specific embodiments and application scenarios.

[0029] As attached Figure 1 As shown in the figure, the human-computer interaction method for a battery management system based on an embedded web architecture according to an embodiment of this application includes the following steps: Step 101: Deploy a lightweight Nginx server in the embedded system of the BMS battery management system.

[0030] A lightweight Nginx server is a typical web server, but in practice, it's not limited to just lightweight Nginx; it can also be any other suitable server. The lightweight Nginx server acts as a bridge for communication between the front-end and back-end. The web server uses a reverse proxy mechanism to route and forward front-end page requests to back-end business interfaces such as status queries, control commands, and file transfers.

[0031] The Nginx server includes the Nginx Web service and the HTTP service, with the HTTP service embedded in the main program of the BMS embedded system.

[0032] In one optional embodiment, deploying a lightweight Nginx server in the embedded system of the BMS battery management system may include the following sub-steps: S1: Install the Nginx Web service in the BMS embedded system environment using a package management tool and configure it to start automatically on boot. S2: Start the Nginx web service and verify its running status; S3: Configure the reverse proxy function of Nginx Web service to forward HTTP requests starting with "API" to the locally running BMS backend HTTP service.

[0033] In this system architecture, the backend provides APIs to interface with core BMS functional modules such as data acquisition, battery protection, and communication protocol stacks, enabling the encapsulation of business logic and data interaction. Furthermore, this embodiment also includes a responsive web frontend interface implemented using HTML5, CSS3, and JavaScript technologies, supporting functions such as data visualization, parameter configuration, program upgrades, log downloads, and real-time alarms.

[0034] After deploying a lightweight Nginx server in the embedded system of the BMS battery management system, users can access or interact with the BMS system based on this deployment. A diagram illustrating access and interaction with the BMS system using an embedded web architecture is shown below. Figure 2 As shown, it has the following core functions: Unified access point: Users can access the system login page by entering the IP address or domain name of the BMS device in their browser, without the need to pre-install any client software.

[0035] Authentication and access control: Supports multi-level user authentication and operation permission control to ensure system access security.

[0036] Dynamic interaction and real-time updates: The front-end page communicates with the back-end via Fetch to enable real-time updates and push notifications of device status, battery data, and alarm information. Fetch is a native JavaScript API provided by modern browsers for handling HTTP requests.

[0037] Seamless operation: Users can complete operations such as parameter modification, firmware upgrade, file upload / download on the page, and the system automatically handles version verification, transmission retry, process prompts and result feedback.

[0038] The following section provides a detailed explanation of the human-computer interaction process for a battery management system based on an embedded web architecture.

[0039] Step 102: In response to the user's input of the BMS device IP and the user request, the Nginx web service determines the type of the user request.

[0040] In one optional embodiment, in response to the user-inputted BMS device IP and user request, the Nginx Web service may determine the type of user request by including the following sub-steps: Sub-step 1: Receive the client's access request, determine the corresponding CSS style rules for the client, and display the browser interface according to the CSS style rules.

[0041] Different CSS style rules are predefined for different types of client devices, and for the same type of device with different screen sizes.

[0042] Sub-step 2: In response to the BMS device IP entered by the user in the browser interface, display the system login page.

[0043] Users can access the system login page by entering the IP address or domain name of the BMS device in their browser.

[0044] Sub-step 3: After completing system login, receive the access request entered by the user through the client.

[0045] In one alternative embodiment, after logging into the system, the system can also receive control operations from the user in the web interface. In response to the control operations, the system responds and automatically executes the control operations.

[0046] The control operations include: parameter modification, BMS firmware upgrade, file upload, and file download.

[0047] This optional user control operation in the web interface can increase the user's freedom of interaction with the system, thereby improving the user experience.

[0048] Sub-step 4: The Nginx web service determines the type of user request.

[0049] User requests can be of various types, including but not limited to: static resource requests and HTTP requests starting with "API". The type of user request determines the service that will handle it.

[0050] Step 103: When the user request is a static resource request, the Nginx web service processes the user request.

[0051] Step 104: If the user request is an HTTP request starting with API, forward the user request to the HTTP service.

[0052] Step 105: The HTTP service forwards the request according to the preset routing table and calls the target module in the hardware driver layer to execute the user request.

[0053] In an optional embodiment, the HTTP service performs routing forwarding based on a preset routing table, and the method of invoking the target module in the hardware driver layer to execute the user request may include the following sub-steps: Sub-step 1: When an HTTP request is received, the HTTP service allocates a session structure for the HTTP request.

[0054] The session structure is used to store the context data of the HTTP request; Sub-step 2: If the HTTP request contains upload data, the HTTP service receives the upload data and stores the received data in the buffer until the HTTP request containing the upload data has been uploaded.

[0055] Sub-step 3: The HTTP service calls a unified API dispatch function, which calls the corresponding business processing function based on the HTTP request content and the preset routing table.

[0056] In actual implementation, when the HTTP service calls the unified API dispatch function and invokes the corresponding business processing function based on the HTTP request content and the preset routing table, the specific process can be executed as follows: The HTTP service calls a unified API dispatch function, which searches for the corresponding business processing function in a preset routing table based on the interface name specified in the URL corresponding to the HTTP request. The preset routing table includes the correspondence between interfaces and business processing function pointers. If a matching business processing function pointer is found, the business processing function indicated by the matching business processing function pointer is called; if no matching business processing function is found, an error message is returned, which indicates that the corresponding interface does not exist.

[0057] Sub-step 4: Execute an HTTP request by calling the target module in the hardware driver layer through the business processing function.

[0058] Sub-step 5: The HTTP service receives the response data returned by the business processing function, encapsulates the response data into an HTTP response, sets the header fields in the preset format, and then returns it to the client.

[0059] The human-computer interaction method for a battery management system based on an embedded web architecture provided in this application also incorporates responsive and adaptive design, as detailed below: Automatic multi-device adaptation: The front-end uses CSS3 media queries and flexible layout technology to automatically identify the screen size, resolution, and operation method (touch / keyboard / mouse) of the accessing device, and dynamically adjust the interface layout, font size, and spacing of interactive elements. CSS3 is the third-generation standard version of Cascading Style Sheets (CSS) technology. Through a modular architecture, it adds features such as rounded corners, shadows, animations, and responsive layout, significantly enhancing the visual presentation and interactivity of web pages.

[0060] Intelligent switching of interaction modes: Optimize touch gestures such as swiping and long press for client devices, while retaining shortcut key support for client devices, providing an operating experience that conforms to device characteristics.

[0061] In an optional embodiment, the human-computer interaction method for a battery management system based on an embedded web architecture according to this application further includes: Different CSS style rules are set for different types of client devices, and for the same type of client device with different screen sizes; the display interface is adapted to different types of client devices; and different interface components are adapted to different interface components. The client devices are divided into different types based on their screen size. The interface components include: data icons, buttons, and interactive elements.

[0062] Client types include: small-screen devices, medium-screen devices, and large-screen devices. When adapting the display interface layout to different types of client devices, on small-screen devices, the interface can adopt a single-column layout, the navigation menu can be collapsed, and the table data can be switched to a card-style display. On medium-screen devices, the interface can adopt a double-column grid layout to improve the information display density. On large-screen devices, the interface can adopt an N-column grid layout, where N≥3.

[0063] In an optional embodiment, the human-computer interaction method for a battery management system based on an embedded web architecture according to this application further includes: The system monitors whether the current web interface and BMS firmware version match; if they do not match, it outputs a prompt message to guide the upgrade process; it receives the BMS firmware upgrade package uploaded by the user through the web interface and verifies the version compatibility of the BMS firmware upgrade package; if the verification passes, it synchronously updates the BMS firmware version and web interface components to ensure version compatibility. A schematic diagram of an example of a collaborative upgrade process between the web frontend and BMS firmware is shown below. Figure 3 As shown.

[0064] The version coordination mechanism provided in this optional embodiment automatically detects the version matching status of the current Web interface and BMS firmware when the system starts up. If a mismatch is found, the user is prompted in a prominent position on the interface and guided to upgrade. One-click collaborative update of BMS firmware and Web interface components can ensure the consistency of their functions.

[0065] The human-computer interaction method for a battery management system based on an embedded web architecture provided in this application has the following advantages: First, it facilitates deployment, eliminating the need for users to install or update dedicated software, significantly reducing deployment and training costs. Second, it supports various operating systems and terminal devices, making it particularly suitable for mobile inspection and remote collaboration scenarios, achieving full cross-platform coverage. Third, it provides a customizable web interface, supporting real-time data visualization and operation feedback, enhancing the user experience. Fourth, it features a unified management entry point and real-time communication mechanism, supporting functions such as remote diagnostics, batch configuration, and log tracing, making operation and maintenance more intelligent and improving system maintainability. Fifth, it enables integrated version management, specifically reflected in the version association and collaborative updates between the front-end interface and the BMS firmware, ensuring the integrity of system functions and operational stability.

[0066] The following example illustrates the human-computer interaction method for a battery management system based on an embedded web architecture provided in this application.

[0067] Part 1: Embedded Nginx Server Deployment and Reverse Proxy Configuration In a BMS embedded Linux system, a lightweight Nginx server is deployed to handle front-end page requests and forward them to back-end business modules. The specific implementation is as follows: First, install Nginx in the embedded Linux environment using a package management tool and configure it to start automatically on boot.

[0068] After installation, start the Nginx service and verify its running status.

[0069] Configure Nginx to reverse proxy, forwarding all HTTP requests starting with / api / to the locally running BMS backend service.

[0070] In the proxy configuration, retain the Host header, the client's real IP address, and the protocol type of the original request to ensure that the backend can correctly process the request source and protocol information.

[0071] This configuration implements a front-end and back-end separation communication architecture. The front-end page accesses the back-end API through Nginx, avoiding cross-domain issues and improving the system's security and scalability.

[0072] Part Two: Implementation of the HTTP Service Module Embedded in the BMS Program In the BMS main program, an HTTP service module is embedded based on a lightweight HTTP server library (such as libmicrohttpd) to receive API requests forwarded by Nginx. Its workflow is as follows: When an HTTP request arrives, the system first allocates a session structure to store the context data of the current request.

[0073] If the request includes uploaded data (such as form submission or file upload), the system will receive the data step by step and store it in the buffer until all the data has been received.

[0074] After the data is received, the system calls a unified API dispatch function, which in turn calls the corresponding business processing function based on the request content.

[0075] The business processing function returns response data in JSON format. The HTTP service module encapsulates this data into an HTTP response, sets the correct Content-Type header, and then returns it to the client.

[0076] After the request is processed, session resources are released to ensure stable system memory operation.

[0077] This module supports multiple HTTP methods such as GET and POST, and can handle complex business scenarios including data query, parameter configuration, and file upload.

[0078] Part Three: API Interface Design and Router Implementation To achieve modular and scalable backend services, the system uses a routing table to manage all API interfaces. The specific implementation is as follows: Define a static routing table, where each entry contains an interface name such as get_single, set_range, login_verify, etc., and a pointer to the corresponding processing function.

[0079] When an API request arrives, the system looks up the corresponding processing function in the routing table based on the interface name specified in the URL.

[0080] If a match is found, the function is called to process the request; otherwise, an error message "interface does not exist" is returned.

[0081] Taking the "Read a single RTE data" interface as an example, its processing flow is as follows: Parse the required data ID from the request parameters.

[0082] Call the read function of the underlying BMS module to retrieve the corresponding data value based on the ID.

[0083] If the read operation is successful, the data will be encapsulated into a JSON array and returned; if it fails, the corresponding error code and message will be returned.

[0084] Other interfaces (such as writing data, login verification, firmware upgrade, configuration import / export, etc.) all adopt similar implementation methods to ensure a consistent interface style and clear logic.

[0085] Part Four: Multi-resolution Responsive Design To adapt to different client devices such as PCs, tablets, and mobile phones, the front-end interface adopts a responsive design, mainly implemented as follows: Breakpoint definition: Define different CSS style rules for different client device types, tablets (width ≥ 768px), desktops (width ≥ 1024px), and large screens (width ≥ 1440px).

[0086] Adaptive layout: On small-screen devices, the interface uses a single-column layout, the navigation menu collapses into a hamburger menu, and table data is displayed in a card format. On medium-screen devices, a two-column grid layout is used to increase information density. On large-screen devices, a three- or four-column grid layout is used to make full use of screen space to display more data.

[0087] Component adaptation: Data charts are drawn using Canvas and support automatic scaling based on container size. Button and interactive element sizes are adapted to touch operation, with a minimum touch area of ​​44×44 pixels. Font size, spacing, and margins all use relative units (such as rem and vw) to ensure good readability at different resolutions.

[0088] This design ensures that users can have a consistent and smooth interactive experience regardless of the device they use to access the BMS system.

[0089] This application also provides a human-computer interaction system for a battery management system based on an embedded web architecture. The human-computer interaction system for a battery management system based on an embedded web architecture provided in this application includes: The BMS battery management system includes a lightweight Nginx server deployed in its embedded system. The Nginx server includes an Nginx Web service and an HTTP service, with the HTTP service embedded in the main program of the BMS embedded system. The embedded Web-based battery management system human-computer interaction system is used to execute any one of the embedded Web-based battery management system human-computer interaction methods described in the foregoing method embodiments.

[0090] The battery management system human-computer interaction system based on an embedded web architecture provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0091] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0092] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A human-computer interaction method for a battery management system based on an embedded web architecture, characterized in that, The method includes: A lightweight Nginx server is deployed in the embedded system of the BMS battery management system. The Nginx server includes an Nginx web service and an HTTP service, and the HTTP service is embedded in the main program of the BMS embedded system. In response to the BMS device IP and user request input by the user, the Nginx Web service determines the type of the user request; If the user request is a static resource request, the Nginx Web service processes the user request; If the user request is an HTTP request starting with "API", the user request will be forwarded to the HTTP service. The HTTP service forwards the request based on a preset routing table and calls the target module in the hardware driver layer to execute the user request.

2. The method according to claim 1, characterized in that, The steps for deploying a lightweight Nginx server in an embedded system of a BMS battery management system include: Install the Nginx Web service in the BMS embedded system environment using a package management tool, and configure it to start automatically on boot. Start the Nginx web service and verify its running status; Configure the reverse proxy function of the Nginx web service to forward HTTP requests starting with "API" to the locally running BMS backend HTTP service.

3. The method according to claim 1, characterized in that, The HTTP service performs routing and forwarding based on a preset routing table, and calls the target module in the hardware driver layer to execute the user request, including the following steps: When an HTTP request is received, the HTTP service allocates a session structure for the HTTP request, wherein the session structure is used to store the context data of the HTTP request; If the HTTP request contains uploaded data, the HTTP service receives the uploaded data and stores the received data in the buffer until the HTTP request containing the uploaded data has been uploaded. The HTTP service calls a unified API dispatch function, which calls the corresponding business processing function based on the HTTP request content and the preset routing table. The HTTP request is executed by calling the target module in the hardware driver layer through the business processing function. The HTTP service receives the response data returned by the business processing function, encapsulates the response data into an HTTP response, sets the header fields in a preset format, and then returns it to the client.

4. The method according to claim 3, characterized in that, The steps of invoking a unified API dispatch function for HTTP service calls, and calling the corresponding business processing function based on the HTTP request content and a preset routing table, include: The HTTP service calls a unified API dispatch function, which searches for the corresponding business processing function in a preset routing table based on the interface name specified in the URL corresponding to the HTTP request; wherein, the preset routing table includes: the correspondence between interface and business processing function pointers; If a matching business processing function pointer is found, the business processing function pointed to by the matching business processing function pointer is called; If no matching business processing function is found, an error message is returned, indicating that the corresponding interface does not exist.

5. The method according to claim 1, characterized in that, The step of determining the type of the user request in response to the user-input BMS device IP and user request includes: The system receives access requests from clients, determines the corresponding CSS style rules for each client, and displays the browser interface according to the CSS style rules. Different CSS style rules are predefined for different types of client devices and different screen sizes of the same type. The system login page is displayed in response to the BMS device IP entered by the user in the browser interface; After completing system login, receive access requests entered by the user through the client; The Nginx web service determines the type of the user request.

6. The method according to claim 1, characterized in that, The method further includes: Different CSS style rules are set for different types of client devices, and for the same type of client device with different screen sizes; the client devices are divided into different types based on their screen size. Adaptive layout of the display interface for different types of client devices; Configure adaptive settings for different interface components, including: data icons, buttons, and interactive elements.

7. The method according to claim 6, characterized in that, Client types include: small-screen devices, medium-screen devices, and large-screen devices; the steps for adaptive layout of the display interface for different types of client devices include: On small-screen devices, the interface adopts a single-column layout, the navigation menu is collapsed, and the table data is switched to a card-style display; On mid-screen devices, the interface adopts a dual-column grid layout to increase the density of information display; On large-screen devices, the interface uses an N-column grid layout, where N ≥ 3.

8. The method according to claim 5, characterized in that, The method further includes: After logging into the system, the system receives control operations from the user in the web interface, including parameter modification, BMS firmware upgrade, file upload, and file download. In response to the control operation, the system responds and automatically executes the control operation.

9. The method according to claim 1, characterized in that, The method further includes: The system monitors whether the current web interface matches the BMS firmware version; If they do not match, a boot upgrade prompt message will be output; Receive BMS firmware upgrade packages uploaded by users through the web interface, and verify the version compatibility of the BMS firmware upgrade packages; If the verification passes, the BMS firmware version and Web interface components are updated synchronously to ensure version compatibility.

10. A human-computer interaction system for a battery management system based on an embedded web architecture, characterized in that, The system includes a battery management system (BMS), wherein a lightweight Nginx server is deployed in the embedded system of the BMS, and the Nginx server includes an Nginx web service and an HTTP service, wherein the HTTP service is embedded in the main program of the BMS embedded system; the battery management system human-computer interaction system based on embedded web architecture is used to execute the battery management system human-computer interaction method based on embedded web architecture according to any one of claims 1-9.

Images