Control method, integrated control system and computer program product

Abstract

The application provides a control method, an integrated control system and a computer program product; the method is applied to the integrated control system, and the method comprises the following steps: a module loading subsystem acquires a list of modules to be loaded according to the configuration requirement of a current battery swap station; a functional module in the list is loaded and activated; a process configuration subsystem constructs a process configuration file of the current battery swap station on a visual interface according to the activated functional module; and a control node of the current battery swap station is executed in response to the process configuration file, and a standardized instruction of the control node is sent to a service abstraction subsystem; after receiving the standardized instruction, the service abstraction subsystem calls a protocol configuration file of the current battery swap station in a communication protocol subsystem; the standardized instruction is converted into a private protocol instruction based on the protocol configuration file, and the private protocol instruction is sent to the current battery swap station to control the current battery swap station to execute corresponding operations based on the private protocol instruction. The application can be flexibly adapted to various battery swap stations.

Description

Technical Field

[0001] This application relates to the field of battery swapping station technology, and in particular to a control method, an integrated control system, and a computer program product. Background Technology

[0002] With the continuous development of battery swapping stations, a single station may have anywhere from a few to dozens of different types of equipment, each with its own communication protocols, resulting in a massive development workload. System developers must write and solidify control logic and communication driver code separately for each specific type of equipment within the swapping station (such as specific models of charging piles, battery swapping robots, battery storage racks, and safety detectors). Because devices with the same functions may use different control systems in different swapping stations, the modules already developed for the control system cannot be reused, requiring repeated development, leading to wasted manpower and long project cycles. Summary of the Invention

[0003] This application provides a control method, an integrated control system, and a computer program product, which can not only flexibly adapt to different battery swapping stations, but also improve code reusability, eliminate the need for repeated development, reduce manpower waste, and increase project delivery speed.

[0004] In a first aspect, embodiments of this application provide a control method applied to an integrated control system. The integrated control system includes a module loading subsystem, a process configuration subsystem, a service abstraction subsystem, and a communication protocol subsystem. The control method includes: the module loading subsystem obtaining a list of modules to be loaded based on the current configuration requirements of the battery swapping station; loading and activating corresponding functional modules based on the list of modules to be loaded; the process configuration subsystem constructing a process configuration file corresponding to the current battery swapping station on a visual interface based on the activated functional modules; and in response to the process configuration file being executed to the control node of the current battery swapping station, sending a standardized instruction corresponding to the control node to the service abstraction subsystem through the process configuration subsystem; after receiving the standardized instruction, the service abstraction subsystem calling the protocol configuration file of the current battery swapping station in the communication protocol subsystem; converting the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station, and sending the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0005] Through the aforementioned technical means, the module loading subsystem in the integrated control system can load and activate functional modules corresponding to the list of modules to be loaded at the current battery swapping station. These activated functional modules match the current operation of the battery swapping station, enabling an integrated control system to flexibly derive customized versions adapted to different battery swapping stations. This not only improves the flexibility of the integrated control system but also eliminates the need for redevelopment of already developed functional modules, allowing for direct use and increasing the reusability (i.e., code reusability) of developed functional modules, reducing development costs, and accelerating project delivery. Furthermore, the process configuration subsystem in the integrated control system can construct the corresponding process configuration file for the current battery swapping station on a visual interface based on the activated functional modules. This de-fixes the business processes of the current battery swapping station, allowing them to be adjusted according to different needs / application scenarios, thus improving the convenience of updating the current battery swapping station's business processes. Additionally, the process configuration subsystem in the integrated control system can execute the current... After the control node of the previous battery swapping station is established, standardized instructions corresponding to the control node are sent to the service abstraction subsystem. This eliminates the need to consider the specific implementation of each functional module in the current battery swapping station, as well as the differences in suppliers and structures of these modules. The same control instruction can be adapted to functional modules from different manufacturers and models, improving the compatibility of the integrated control system. In addition, the service abstraction subsystem in the integrated control system only calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized instructions. Then, it converts the standardized instructions into the private protocol instructions of the current battery swapping station according to the protocol configuration file. This approach can decouple the upper-layer standardized control from the lower-layer private protocol. Without modifying the original equipment of the battery swapping station or the private protocol, it can achieve unified control and compatibility adaptation for battery swapping stations of different types and manufacturers. This further improves the versatility, scalability, and stability of the integrated control system, reduces the deployment and maintenance costs of the integrated control system, and facilitates large-scale promotion and application.

[0006] In some embodiments, the control method further includes: after obtaining the process configuration file corresponding to the current battery swapping station, the process configuration subsystem stores the process configuration file in a structured format into the process configuration database.

[0007] By using the aforementioned technical methods to store process configuration files in a process configuration database, data loss can be prevented. Furthermore, since the process configuration files are stored in a structured format, potentially disorganized configuration information can be standardized. This ensures a consistent format, clear hierarchy, and ease of understanding and modification by developers, resulting in strong maintainability.

[0008] In some embodiments, the control method further includes: when the integrated control system is running, the process configuration subsystem loads the process configuration file corresponding to the current battery swapping station from the process configuration database and executes the process configuration file.

[0009] By using the above technical means, the process configuration file is only called from the process configuration database when needed (such as when the integrated control system is running). This "store first, use later" approach can save system resources of the integrated control system compared to the "use directly" approach, making the integrated control system run more smoothly.

[0010] In some embodiments, the control method further includes: a module loading subsystem performing functional decomposition on the integrated control system to determine multiple candidate functional modules; wherein, the functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to standard plug-in interfaces.

[0011] Using the aforementioned technical means, the integrated control system can be functionally decomposed to obtain multiple candidate functional modules. On the one hand, these multiple candidate functional modules can cover the functional modules of different battery swapping stations, enabling the integrated control system to flexibly derive customized versions adapted to different battery swapping stations. Functional modules already developed in the battery swapping station do not need to be redeveloped and can be used directly, thus further improving the reusability (i.e., code reusability) of the developed functional modules, reducing development costs, and increasing project delivery speed. On the other hand, since the interfaces of the obtained candidate functional modules are standard plug-in interfaces, they can be developed in accordance with a unified plug-in interface specification, thus improving development speed and reducing manpower waste.

[0012] In some embodiments, the communication protocol subsystem includes a protocol configuration module, and the control method further includes: the protocol configuration module configures the protocol of each functional module in the current battery swapping station according to preset protocol rules, and determines the protocol configuration file of the current battery swapping station; wherein, the preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table and instruction-response mapping relationship.

[0013] Using the above-mentioned technical means, the communication protocol rules of each functional module in the current battery swapping station can be configured, so that different communication protocol rules follow the preset protocol rules. Since the communication protocol rules are changed by configuration rather than by hard-coding, the workload of developers can be reduced, thereby improving the development speed.

[0014] In some embodiments, the communication protocol subsystem includes a parsing engine module, and the control method further includes: when the parsing engine module receives device data sent by the current battery swapping station, it parses the device data based on the protocol configuration file to obtain parsed data, and encapsulates the parsed data based on a preset encapsulation format to generate a standardized data object, and sends the standardized data object to the service abstraction subsystem; the service abstraction subsystem updates the device data model corresponding to the current battery swapping station based on the standardized data object; the device data model is obtained by model mapping based on the functional modules in the current battery swapping station.

[0015] By using the above-mentioned technical means, the parsing speed can be improved by parsing the equipment data sent by the current battery swapping station according to the current battery swapping station's configuration file. In addition, by encapsulating the parsed data into standardized data objects, the differences in data format of the equipment data sent by the current battery swapping station can be masked, giving the integrated control system strong scalability, reusability and maintainability.

[0016] In some embodiments, the service abstraction subsystem includes an adaptation module and a service abstraction interface. The control method further includes: after receiving a standardized instruction, the adaptation module calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem; converts the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station; and the service abstraction interface sends the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0017] Through the above technical means, the adaptation module and the service abstraction interface work together to convert the standardized instructions issued by the process configuration subsystem into the private protocol instructions of the current battery swapping station. In addition, the service abstraction interface is a set of standard equipment service interfaces obtained by abstracting a standardized data model based on all possible types of functional modules in the current battery swapping station. Therefore, it can reduce the complexity of interface adaptation and development costs, and reduce the difficulty of joint debugging.

[0018] Secondly, embodiments of this application also provide an integrated control system, including a module loading subsystem, a process configuration subsystem, a service abstraction subsystem, and a communication protocol subsystem; wherein: the module loading subsystem is used to obtain a list of modules to be loaded according to the configuration requirements of the current battery swapping station; load and activate the corresponding functional modules based on the list of modules to be loaded; the process configuration subsystem is used to construct a process configuration file corresponding to the current battery swapping station on a visual interface based on the activated functional modules; and in response to the execution of the process configuration file to the control node of the current battery swapping station, send a standardized instruction corresponding to the control node to the service abstraction subsystem; the service abstraction subsystem is used to call the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized instruction; convert the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station, and send the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0019] Through the aforementioned technical means, the functional modules loaded and activated by the module loading subsystem in the integrated control system are loaded and activated based on the list of modules to be loaded at the current battery swapping station. Therefore, the activated functional modules perfectly match the current operation of the battery swapping station, enabling the integrated control system to flexibly derive customized versions adapted to different battery swapping stations. This not only improves the flexibility of the integrated control system but also eliminates the need for redevelopment of already developed functional modules, allowing for direct use and increasing the reusability (i.e., code reusability) of existing functional modules, reducing development costs, and accelerating project delivery. Furthermore, the process configuration subsystem in the integrated control system can construct the corresponding process configuration file for the current battery swapping station on a visual interface based on the activated functional modules. This de-fixes the business processes of the current battery swapping station, allowing them to be adjusted according to different needs / application scenarios, thus improving the convenience of updating the current battery swapping station's business processes. Additionally, the process configuration subsystem executes... Upon reaching the control node of the current battery swapping station, the system sends standardized commands corresponding to the control node to the service abstraction subsystem. This eliminates the need to consider the specific implementation of each functional module within the current battery swapping station, or the differences in suppliers and structures of these modules. The same control command can adapt to functional modules from different manufacturers and models, improving the compatibility of the integrated control system. Furthermore, the service abstraction subsystem only invokes the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized command. Then, it converts the standardized command into the current battery swapping station's proprietary protocol command based on the protocol configuration file. This approach decouples the upper-layer standardized control from the lower-layer proprietary protocol. Without modifying the original equipment of the battery swapping station or altering the proprietary protocol, it achieves unified control and compatibility adaptation for different types and manufacturers of battery swapping stations. This further improves the versatility, scalability, and stability of the integrated control system, reduces the deployment and maintenance costs of the integrated control system, and facilitates large-scale promotion and application.

[0020] In some embodiments, the process configuration subsystem is further configured to store the process configuration file in a structured format into the process configuration database after obtaining the process configuration file corresponding to the current battery swapping station.

[0021] Through the aforementioned technical means, the process configuration subsystem can store process configuration files in the process configuration database, preventing data loss. Furthermore, the process configuration files are stored in a structured format, thus unifying potentially disorganized configuration information. This standardized format and clear hierarchy facilitate understanding and modification by developers, resulting in strong maintainability.

[0022] In some embodiments, the process configuration subsystem is further configured to load the process configuration file corresponding to the current battery swapping station from the process configuration database and execute the process configuration file when the integrated control system is in operation.

[0023] Through the above technical means, the process configuration subsystem can also call the process configuration file from the process configuration database only when needed (such as when the integrated control system is running). This "store first, use later" approach can save system resources of the integrated control system compared to the "use directly" approach, making the integrated control system run more smoothly.

[0024] In some embodiments, the module loading subsystem is further configured to perform functional decomposition on the integrated control system and determine multiple candidate functional modules; wherein, the functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to standard plug-in interfaces.

[0025] Through the aforementioned technical means, the module loading subsystem can functionally decompose the integrated control system to obtain multiple candidate functional modules. On the one hand, these multiple candidate functional modules can cover the functional modules of different battery swapping stations, enabling the integrated control system to flexibly derive customized versions adapted to different battery swapping stations. Functional modules already developed in the battery swapping station do not need to be redeveloped and can be used directly, thus further improving the reusability (i.e., code reusability) of the developed functional modules, reducing development costs, and increasing project delivery speed. On the other hand, since the interfaces of the obtained candidate functional modules are standard plug-in interfaces, they can be developed in accordance with a unified plug-in interface specification, thus improving development speed and reducing manpower waste.

[0026] In some embodiments, the communication protocol subsystem includes a protocol configuration module, wherein: the protocol configuration module is used to configure the protocol of each functional module in the current battery swapping station according to preset protocol rules, and determine the protocol configuration file of the current battery swapping station; wherein the preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table and command-response mapping relationship.

[0027] Through the above technical means, the protocol configuration module in the communication protocol subsystem can configure the protocol rules of the communication protocols of various functional modules in the current battery swapping station, so that the different communication protocol rules follow the preset protocol rules. Since the protocol rules of the communication protocol are changed by configuration rather than by hard coding, the workload of developers can be reduced and the development speed can be improved.

[0028] In some embodiments, the communication protocol subsystem further includes a parsing engine module, wherein: the parsing engine module is used to parse the device data based on the protocol configuration file when receiving device data sent by the current swapping station, obtain parsed data, encapsulate the parsed data based on a preset encapsulation format, generate a standardized data object, and send the standardized data object to the service abstraction subsystem; the service abstraction subsystem is also used to update the device data model corresponding to the current swapping station based on the standardized data object; the device data model is obtained by model mapping based on the functional modules in the current swapping station.

[0029] Through the aforementioned technical means, the parsing engine module in the communication protocol subsystem can parse the device data sent by the current swapping station according to the current swapping station's configuration file, thereby improving the parsing speed. In addition, by encapsulating the parsed data into standardized data objects, the differences in data format of the device data sent by the current swapping station can be masked, giving the integrated control system strong scalability, reusability, and maintainability.

[0030] In some embodiments, the service abstraction subsystem includes a service abstraction interface and an adaptation module, wherein: the adaptation module is used to call the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving a standardized instruction; and to convert the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station; the service abstraction interface is used to send the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0031] Through the above technical means, the adaptation module and the service abstraction interface work together to convert the standardized instructions issued by the process configuration subsystem into the private protocol instructions of the current battery swapping station. In addition, the service abstraction interface is a set of standard equipment service interfaces obtained by abstracting a standardized data model based on all possible types of functional modules in the current battery swapping station. Therefore, it can reduce the complexity of interface adaptation and development costs, and reduce the difficulty of joint debugging.

[0032] Thirdly, embodiments of this application also provide a computer program product, which includes a computer program or instructions that, when executed by an integrated control system, implement the steps of the method as described in any of the first aspects.

[0033] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating a control method provided in an embodiment of this application. Figure 1 ; Figure 2 This is a flowchart illustrating a control method provided in an embodiment of this application. Figure 2 ; Figure 3 This is a schematic diagram of the structure of an integrated control system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a process configuration subsystem provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a module loading subsystem provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a communication protocol subsystem provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a service abstraction subsystem provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0037] In the following description, references to "some embodiments," "this embodiment," "this application embodiment," and examples, etc., describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0038] The descriptions such as "first," "second," and "third" appearing in the embodiments of this application do not have a specific meaning (such as no order, nor do they indicate a special limitation on the number of devices in the embodiments of this application), but are merely for the purpose of clearly describing the embodiments of this application and do not constitute any limitation on the embodiments of this application.

[0039] Before providing a more detailed description of the embodiments of this application, the nouns and terms that may be involved in the embodiments of this application will be explained. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0040] Currently, new energy batteries are being used more and more widely in daily life and industry. They are not only used in energy storage systems for hydropower, thermal power, wind power, and solar power plants, but also extensively in electric vehicles such as electric bicycles, electric motorcycles, and electric cars, as well as in aerospace and other fields. With the continuous expansion of the application areas of power batteries, the market demand is also constantly increasing.

[0041] In this embodiment, the battery can be a single battery cell or a battery pack composed of multiple battery cells. A single battery cell refers to a basic unit (or "cell") capable of converting chemical energy into electrical energy, and can be used to manufacture battery modules or battery packs to supply power to electrical devices. A single battery cell can be a rechargeable battery, which is a battery cell that can be recharged after discharge to reactivate its active materials and continue to be used. A single battery cell can be a lithium-ion battery, sodium-ion battery, sodium-lithium-ion battery, lithium metal battery, sodium metal battery, lithium-sulfur battery, magnesium-ion battery, nickel-metal hydride battery, nickel-cadmium battery, lead-acid battery, etc., and is not limited to any particular type.

[0042] In this embodiment, the battery may also be a single physical module comprising one or more battery cells to provide higher voltage and capacity. When there are multiple battery cells, they can be connected in series, parallel, or mixed via a busbar.

[0043] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies or terms of the embodiments of this application are described below. The following relevant technologies or terms are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0044] Related technical solutions typically employ a centralized station control system architecture based on hard coding. The core of this approach lies in the fact that system developers must individually write and solidify control logic and communication driver code for each specific device within the battery swapping station (such as specific models of charging piles, battery swapping robots, battery storage racks, safety detectors, etc.). This code is directly embedded in the main station control program. The device's data point addresses, communication message formats (such as Modbus Remote Terminal Unit (MODBUS RTU) / Modbus Transmission Control Protocol (MODBUS TCP), Controller Area Network (CAN) bus, proprietary TCP protocol, etc.), control command sequences, and status parsing rules are all predefined in the form of constants, fixed structures, or conditional statements.

[0045] When on-site business processes (such as battery replacement sequence and charging strategies) need to be adjusted, or when equipment models or suppliers change, developers must manually find, modify, recompile, test, and deploy the entire station control software. This approach essentially binds equipment differences and process logic deeply to the core control system, forming a highly customized but rigid monolithic software.

[0046] In other words, while control methods for battery swapping stations already exist, existing technical solutions still have some problems. For example, a single battery swapping station may have anywhere from a few to dozens of different types of equipment, each with its own communication protocols, resulting in a huge development workload. Equipment with the same function in different swapping stations may also use different control systems, causing the already developed modules of the station control system to be unusable, requiring repeated development, wasting manpower, and extending project cycles. Furthermore, because the equipment interfaces and data types of various devices within the same swapping station are not standardized, upper-level business logic (such as charging strategies and battery swapping scheduling) requires extensive adaptation and special processing for specific devices, increasing system complexity and maintenance costs.

[0047] Based on this, the embodiments of this application provide the following control methods, integrated control systems, and computer program products, which can at least reduce development workload and improve project delivery speed.

[0048] This application provides a control method for an integrated control system. The method includes: a module loading subsystem obtaining a list of modules to be loaded based on the current configuration requirements of the battery swapping station; loading and activating corresponding functional modules based on the list of modules to be loaded; a process configuration subsystem constructing a process configuration file corresponding to the current battery swapping station on a visual interface based on the activated functional modules; and sending standardized instructions corresponding to the control node to the current battery swapping station in response to the execution of the process configuration file to the control node of the current battery swapping station; after receiving the standardized instructions, the service abstraction subsystem calling the protocol configuration file of the current battery swapping station in the communication protocol subsystem; converting the standardized instructions based on the protocol configuration file to obtain the private protocol instructions of the current battery swapping station, and sending the private protocol instructions to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instructions.

[0049] In this way, the module loading subsystem loads and activates the functional modules corresponding to the list of modules to be loaded for the current battery swapping station. These activated functional modules perfectly match the current operation of the battery swapping station, enabling an integrated control system to flexibly derive customized versions adapted to different battery swapping stations. This not only improves the flexibility of the integrated control system but also eliminates the need for redevelopment of already developed functional modules, allowing for direct use, improving code reusability, reducing development costs, and accelerating project delivery. Furthermore, the process configuration subsystem constructs the corresponding process configuration file for the current battery swapping station in a visual interface based on the activated functional modules. This de-fixes the business processes of the current battery swapping station, allowing them to be adjusted according to different needs / application scenarios, thus improving the convenience of updating the current battery swapping station's business processes. Finally, after executing the control node of the current battery swapping station, the process configuration subsystem sends a control request to the service abstraction subsystem. The standardized instructions corresponding to the control nodes do not need to consider the specific implementation of each functional module in the current battery swapping station, nor the differences in the suppliers and structures of the functional modules. The same control instruction can be adapted to functional modules from different manufacturers and models, improving the compatibility of the integrated control system. In addition, after receiving the standardized instructions, the service abstraction subsystem of the integrated control system calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem, and then converts the standardized instructions into the private protocol instructions of the current battery swapping station according to the protocol configuration file. This scheme can decouple the upper-level standardized control from the lower-level private protocol, and achieve unified control and compatibility adaptation for different types and manufacturers of battery swapping stations without modifying the original equipment of the battery swapping station or modifying the private protocol. This further improves the versatility, scalability and stability of the integrated control system, reduces the deployment and maintenance costs of the integrated control system, and facilitates large-scale promotion and application.

[0050] The control method and integrated control system provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0051] In one optional embodiment of this application, a control method is provided, applied to an integrated control system. The integrated control system includes: a module loading subsystem, a process configuration subsystem, a service abstraction subsystem, and a communication protocol subsystem. The control method provided in this embodiment is as follows: Figure 1 As shown, the control method includes the following steps: S101. The module loading subsystem obtains a list of modules to be loaded based on the current configuration requirements of the battery swapping station; and loads and activates the corresponding functional modules based on the list of modules to be loaded.

[0052] It is understandable that current battery swapping stations can have other functions besides battery swapping, such as charging, energy storage, and detection. In other words, current battery swapping stations can have one or more of these functions.

[0053] For example, the configuration requirements of a current battery swapping station may include the hardware configuration and service requirements of the current battery swapping station.

[0054] The hardware configuration of the current battery swapping station refers to the various functional modules within the current battery swapping station. These functional modules can also be referred to as the physical equipment within the current battery swapping station, such as charging equipment, battery swapping equipment, energy storage equipment, and testing equipment. This application does not impose any specific limitations on this.

[0055] The list of modules to be loaded lists the functional modules that need to be loaded and activated. The module loading subsystem can load and activate the functional modules listed in the list of modules to be loaded.

[0056] The module loading subsystem obtains a list of modules to be loaded based on the current configuration requirements of the battery swapping station. In other words, the module loading subsystem loads virtual functional modules that match the functional modules and business requirements within the current battery swapping station into the integrated control system. For example, if the current battery swapping station is a base station that only provides battery swapping services, the list of modules to be loaded includes functional modules related to battery swapping; if the current battery swapping station is a large integrated energy station, the list of modules to be loaded can include all functional modules related to charging, battery swapping, energy storage, and detection.

[0057] In some embodiments, the list of modules to be loaded can list not only the functional modules that need to be loaded and activated, but also the initialization parameters of these functional modules. The module loading subsystem may include a core container that can dynamically load, instantiate and register the corresponding functional modules based on this list.

[0058] For example, the core container may be the Open Service Gateway Initiative (OSGi) framework or a custom lightweight plugin manager, etc., and this application does not make any special limitations on it.

[0059] Understandably, only activated and loaded modules will be able to present the corresponding functional interface and services at runtime. This design allows a unified integrated control system to flexibly generate customized versions for different scenarios, greatly improving code reusability and project delivery speed.

[0060] S102. The process configuration subsystem constructs the process configuration file corresponding to the current battery swapping station in the visual interface according to the activated functional modules; and in response to the execution of the process configuration file to the control node of the current battery swapping station, it sends the standardized instructions corresponding to the control node to the service abstraction subsystem through the process configuration subsystem.

[0061] The process configuration subsystem can provide a visual interface, where users can customize a process configuration file corresponding to the current battery swapping station based on the activated functional modules. Alternatively, the process configuration subsystem can build the process configuration file corresponding to the current battery swapping station itself based on the activated functional modules in the visual interface. This application does not impose any particular limitations on this.

[0062] Understandably, a process configuration file contains multiple control nodes, each corresponding to an action that the physical equipment in the current battery swapping station needs to perform. For example, users or the process configuration subsystem can build, edit, and debug the current battery swapping station's business process by dragging and dropping predefined, standardized control nodes.

[0063] For example, the control node may include vehicle location, battery unlocking, initiating charging, and sending detection reports, etc.

[0064] It should be noted that each control node encapsulates atomic-level business operations or pen-related operation instructions.

[0065] Understandably, a process configuration file includes a complete process, such as a standard battery swapping process, a fast charging process, and a battery depth testing process, etc.

[0066] In some embodiments, the process configuration subsystem can directly execute the process configuration file after obtaining it.

[0067] In other embodiments, after obtaining the process configuration file, the process configuration subsystem can first store the process configuration file in a structured format in the process configuration database, and then, while the integrated control system is running, load and execute the process configuration file corresponding to the current battery swapping station from the process configuration database.

[0068] It is understood that a structured format is a structured data format. For example, a structured data format can be JavaScript Object Notation (JSON), Extensible Markup Language (XML), a specific process description language, etc. This application does not make any special limitations on this.

[0069] It's important to note that when retrieving and executing the process configuration file from the process configuration database, this can be done by a separate Process Engine module, also known as the Process Execution Engine module. The Process Execution Engine module parses the process definition and instantiates, schedules, and executes each control node sequentially. Upon reaching the control node of the current battery swapping station, it sends the corresponding standardized instructions to the service abstraction subsystem. This eliminates the need to concern oneself with the specific implementation of the physical equipment within the current battery swapping station. Consequently, the same integrated control system can adapt to the business needs of various station types, from passenger car battery swapping stations and commercial vehicle battery swapping stations to integrated "swapping, storage, and inspection" stations, simply by loading different process configuration files.

[0070] Understandably, in this embodiment, storing the process configuration file in the process configuration database can prevent loss. Furthermore, the process configuration file is stored in a structured format, thus unifying potentially disorganized configuration information. This results in a consistent format, clear hierarchy, and ease of understanding and modification by developers, leading to strong maintainability.

[0071] It is understandable that in this embodiment, the process configuration file is called from the process configuration database only when needed (such as when the integrated control system is running). This "store first, use later" approach can save system resources of the integrated control system compared to the "use directly" approach, making the integrated control system run more smoothly.

[0072] S103. After receiving the standardized instruction, the service abstraction subsystem calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem; based on the protocol configuration file, it converts the standardized instruction to obtain the private protocol instruction of the current battery swapping station, and sends the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0073] In some embodiments, the communication protocol subsystem may include a protocol configuration module, which can configure the protocol of each functional module in the current battery swapping station according to preset protocol rules and determine the protocol configuration file of the current battery swapping station.

[0074] The preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table, and command-response mapping relationship.

[0075] In some embodiments, the protocol configuration module can automatically configure the communication protocol rules of each functional module in the current battery swapping station according to preset protocol rules; in other embodiments, the protocol configuration module can allow users (e.g., developers or integration engineers) to configure the communication protocol rules of each functional module in the current battery swapping station. It should be noted that whether the protocol configuration module performs protocol configuration or the user uses the protocol configuration module to perform protocol configuration, it is only a description and does not require coding, thus reducing the development workload for developers.

[0076] When a new communication protocol emerges, the protocol configuration module can also be used to configure the new communication protocol.

[0077] It should be noted that the emergence of a new communication protocol may be caused by the appearance of a new physical device in the current battery swapping station, i.e., the communication protocol of the new device; or it may be caused by the appearance of a new battery swapping station, etc. This application does not make any special limitation on this. The following will take the emergence of a new communication protocol caused by the appearance of a new physical device in the current battery swapping station as an example for illustrative explanation.

[0078] It is understandable that the communication protocols of the various functional modules in the current battery swapping station may be different due to different suppliers. The protocol configuration module can configure the protocol rules of the communication protocols of the various functional modules in the current battery swapping station according to the preset protocol rules, and determine the protocol configuration file of the current battery swapping station.

[0079] The determined protocol configuration file of the current battery swapping station can be the protocol configuration file corresponding to each functional module (i.e., physical device) within the current battery swapping station, or it can be the protocol configuration file of the current battery swapping station itself. This application does not make any special restrictions on this.

[0080] For example, the physical link parameters of the communication may include, but are not limited to, serial port baud rate, Transmission Control Protocol (TCP) / Internet Protocol Address (IP) port, etc.; the message frame structure may include, but is not limited to, start character, length field, data field and checksum, etc.; the data point table may include, but is not limited to, the address, data type, scaling factor and unit of each monitoring point or control command, etc.

[0081] It is understood that in this embodiment, the protocol rules of the communication protocols of each functional module in the current battery swapping station can be configured so that the different communication protocol rules follow the preset protocol rules. Since the protocol rules of the communication protocol are changed by configuration rather than by hard coding, the workload of developers can be reduced and the development speed can be improved.

[0082] Understandably, in this embodiment, the module loading subsystem in the integrated control system loads and activates functional modules corresponding to the list of modules to be loaded at the current battery swapping station. These activated functional modules match the current operation of the battery swapping station, enabling an integrated control system to flexibly derive customized versions adapted to different battery swapping stations. This not only improves the flexibility of the integrated control system but also eliminates the need for redevelopment of already developed functional modules, allowing for direct use and increasing the reusability (i.e., code reusability) of developed functional modules, reducing development costs, and accelerating project delivery. Furthermore, the process configuration subsystem in the integrated control system constructs the corresponding process configuration file for the current battery swapping station on the visual interface based on the activated functional modules. This decouples the current battery swapping station's business processes from rigid ones, allowing adjustments to the business processes based on different needs / application scenarios, thus improving the convenience of updating the current battery swapping station's business processes. Additionally, the process configuration subsystem in the integrated control system can execute... After the control node of the current battery swapping station is reached, standardized instructions corresponding to the control node are sent to the service abstraction subsystem. This eliminates the need to consider the specific implementation of each functional module within the current battery swapping station, or the differences in suppliers and structures of these modules. The same control instruction can adapt to functional modules from different manufacturers and models, improving the compatibility of the integrated control system. Furthermore, the service abstraction subsystem in the integrated control system only calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized instructions. Then, based on the protocol configuration file, the standardized instructions are converted into the current battery swapping station's proprietary protocol instructions. This approach decouples the upper-layer standardized control from the lower-layer proprietary protocol. Without modifying the original equipment of the battery swapping station or altering the proprietary protocol, unified control and compatibility adaptation for different types and manufacturers of battery swapping stations are achieved. This further improves the versatility, scalability, and stability of the integrated control system, reduces deployment and maintenance costs, and facilitates large-scale application.

[0083] As another alternative embodiment, such as Figure 2 As shown in the embodiments of this application, the control method may further include the following steps: S100, the module loading subsystem, performs functional decomposition of the integrated control system and identifies multiple candidate functional modules.

[0084] Among them, the functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to the standard plug-in interface.

[0085] It is understandable that step S100 can be executed before step S101, and the module loading subsystem can decompose the complete function of the integrated control system into independent candidate functional modules with high cohesion and low coupling.

[0086] For example, multiple candidate functional modules may include a DC charging control module, a battery swapping robot scheduling module, a battery storage management module, an online detection and analysis module, and a vehicle to grid module, etc.

[0087] It should be noted that each candidate functional module is a virtual functional module, or it can be understood as a virtual device that corresponds one-to-one with each physical device in the current battery swapping station. Each candidate functional module is also a plug-in that enables the software function to be used "plug and play".

[0088] It should also be noted that each candidate functional module is an independent software package, including its own business logic, user interface components and internal data modules, and is developed in accordance with a unified plugin interface specification.

[0089] It should also be noted that the module loading subsystem can obtain a list of modules to be loaded based on the current configuration requirements of the battery swapping station, and then load and activate the corresponding functional modules based on this list. It is important to note that only the functional modules that are configured to be loaded and activated will display their functional interface and services at runtime. For example, a base station that only provides battery swapping services will only contain battery swapping-related modules in its list of modules to be loaded; while a large integrated energy station may include charging, battery swapping, energy storage, and detection modules in its list. This design allows a unified software platform to flexibly derive customized versions for different scenarios, greatly improving code reusability and project delivery speed.

[0090] Understandably, in this embodiment, the integrated control system can be functionally decomposed to obtain multiple candidate functional modules. On the one hand, multiple candidate functional modules can cover the functional modules of different battery swapping stations, enabling the integrated control system to flexibly derive customized versions adapted to different battery swapping stations. Functional modules already developed in the battery swapping station do not need to be redeveloped and can be used directly, which can further improve the reusability (i.e., code reusability) of the developed functional modules, reduce development costs, and increase project delivery speed. On the other hand, since the interfaces of the obtained candidate functional modules are standard plug-in interfaces, they can be developed in accordance with a unified plug-in interface specification, which can improve the development speed and reduce manpower waste.

[0091] As another optional embodiment, the communication protocol subsystem may further include a parsing engine module. In this case, the control method provided in this application embodiment may further include: when the parsing engine module receives device data sent by the current swapping station, it parses the device data based on the protocol configuration file of the current swapping station to obtain parsed data, and encapsulates the parsed data based on a preset encapsulation format to generate a standardized data object, and sends the standardized data object to the service abstraction subsystem; the service abstraction subsystem updates the device data model corresponding to the current swapping station based on the standardized data object.

[0092] In some embodiments, when receiving device data sent by the current battery swapping station, the device data can be parsed based on the protocol configuration file of the current battery swapping station; in other embodiments, when receiving device data sent by the current battery swapping station, the device data sent by the device through the current battery swapping station can be parsed based on the device's protocol configuration file. This application does not impose any particular limitation on this, and the following explanation will take the parsing of the device data sent by the device through the current battery swapping station based on the device's protocol configuration file as an example.

[0093] It should be noted that the parsing engine module can dynamically parse the raw byte stream of device data and automatically complete operations such as unpacking, verification, data point extraction, and type conversion.

[0094] The type conversion can be to convert a two-byte integer to a floating-point value, or it can be to convert a two-byte integer to a floating-point temperature value, etc. This application does not make any special limitation on this. The following example will be used to illustrate the type conversion of converting a two-byte integer to a floating-point temperature value.

[0095] For example, the structure of a standardized data object may include timestamps, device identifiers (IDs), and data point key-value pairs, etc.

[0096] It should be noted that the equipment data model of the current battery swapping station can include several models. Each equipment data model corresponds to a functional module within the current battery swapping station and is obtained by mapping the functional modules within the current battery swapping station. The "equipment data model" can also be called the "equipment shadow" data model. In other words, the service abstraction subsystem maintains an "equipment shadow" data model corresponding to the physical equipment within the current battery swapping station. When the service abstraction subsystem receives a standardized data object reported from a physical equipment within the current battery swapping station, which has been parsed by the communication protocol subsystem, it updates the standardized data object into the "equipment shadow" data model corresponding to that physical equipment for upper-layer business queries.

[0097] Understandably, this layer of abstraction completely separates the volatile and diverse equipment details from the stable and unified business logic, enabling parallel and decoupled business development and equipment integration work.

[0098] It is understandable that in this embodiment, parsing the device data sent by the current swapping station according to the current swapping station's configuration file can improve the parsing speed. In addition, encapsulating the parsed data into standardized data objects can shield the differences in data format of the device data sent by the current swapping station, making the integrated control system highly scalable, reusable, and maintainable.

[0099] As another optional embodiment, the service abstraction subsystem may include an adaptation module and a service abstraction interface. In this case, the control method provided in this application embodiment may further include: after receiving a standardized instruction, the adaptation module calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem; the standardized instruction is converted based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station; the service abstraction interface sends the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction.

[0100] In some embodiments, the service abstraction subsystem can abstract all possible types of physical devices within the current battery swapping station into a unified core data model (i.e., a standardized data model). The standardized data model defines the standard attributes of the physical devices (such as device ID, online status, operating mode, and alarm level, etc.). Then, based on the standardized data model, a set of standard device service interfaces are defined to obtain the service abstraction interface.

[0101] For example, the service abstraction interface can be IDeviceService.getRealTimeData(deviceId), IDeviceService.sendControlCommand(deviceId, command, value), etc.

[0102] The IDeviceService.getRealTimeData(deviceId) function is to obtain the real-time status / data of a specified device. It is the core interface for device data acquisition and is suitable for scenarios such as sensor data (e.g., temperature, humidity) and device operating status (e.g., power on / off, speed).

[0103] The IDeviceService.sendControlCommand(deviceId, command, value) function sends control commands to a specified device. It is the core interface for reverse device control and is suitable for scenarios such as switch control (e.g., turning lights on / off), parameter adjustment (e.g., adjusting air conditioner temperature), and device operation (e.g., starting / stopping a motor).

[0104] It is understood that in this embodiment, the adaptation module and the service abstraction interface work together to convert the standardized instructions issued by the process configuration subsystem into the private protocol instructions of the current battery swapping station. In addition, since the service abstraction interface is a set of standard device service interfaces, it can reduce the complexity of interface adaptation and development costs, and reduce the difficulty of joint debugging.

[0105] As another optional embodiment, the control method provided in this application embodiment may further include: when the process configuration file is changed, the module loading subsystem obtains a new list of modules to be loaded according to the changed process configuration file, and then loads and activates the corresponding functional modules based on the new list of modules to be loaded.

[0106] When the process documents are changed, the current battery swapping station's business processes can be updated and upgraded by modifying the process documents.

[0107] It is understood that in this embodiment, when updating and upgrading the current battery swapping station, it is only necessary to obtain a new process configuration file, obtain a new list of modules to be loaded based on the new process configuration file, and then load and activate the corresponding functional modules based on the new list of modules to be loaded. Functional modules that have already been developed in the integrated control system do not need to be redeveloped, which can reduce the development workload of developers and improve the project delivery speed.

[0108] In another optional embodiment of this application, an integrated control system is also provided, which is described below in conjunction with... Figures 3-7 The integrated control system provided in the embodiments of this application will be described in detail.

[0109] like Figure 3As shown, the integrated control system 300 includes a module loading subsystem 301, a process configuration subsystem 302, a service abstraction subsystem 303, and a communication protocol subsystem 304.

[0110] In this embodiment, the module loading subsystem 301 is used to obtain a list of modules to be loaded based on the current configuration requirements of the battery swapping station 400; and to load and activate the corresponding functional modules based on the list of modules to be loaded.

[0111] It is understandable that the current battery swapping station 400 can have other functions besides battery swapping, such as charging, energy storage and detection. In other words, the current battery swapping station 400 can have one or more of the following functions: battery swapping, charging, energy storage and detection.

[0112] For example, the configuration requirements of the current battery swapping station 400 may include the hardware configuration and service requirements of the current battery swapping station 400.

[0113] The hardware configuration of the current battery swapping station 400 refers to the various functional modules within the current battery swapping station 400. These functional modules can also be referred to as the physical equipment within the current battery swapping station 400, such as charging equipment, battery swapping equipment, energy storage equipment, and testing equipment. This application does not impose any specific limitations on this.

[0114] The list of modules to be loaded lists the functional modules that need to be loaded and activated. The module loading subsystem 301 can load and activate the functional modules listed in the list of modules to be loaded.

[0115] The module loading subsystem 301 obtains a list of modules to be loaded based on the current configuration requirements of the battery swapping station. In other words, the module loading subsystem 301 loads virtual functional modules that match the functional modules and business requirements within the current battery swapping station 400 into the integrated control system 300. For example, if the current battery swapping station 400 is a base station that only provides battery swapping services, the list of modules to be loaded includes functional modules related to battery swapping; if the current battery swapping station 400 is a large integrated energy station, the list of modules to be loaded can include all functional modules related to charging, battery swapping, energy storage, and detection.

[0116] In some embodiments, the list of modules to be loaded can list not only the functional modules that need to be loaded and activated, but also the initialization parameters of these functional modules. The module loading subsystem 301 may include a core container that can dynamically load, instantiate and register the corresponding functional modules according to this list.

[0117] For example, the core container may be the OSGi framework or a custom lightweight plugin manager, etc., and this application does not make any special limitation on it.

[0118] Understandably, only activated and loaded modules can present the corresponding functional interface and services at runtime. This design allows a unified integrated control system 300 to flexibly generate customized versions for different scenarios, greatly improving code reusability and project delivery speed.

[0119] In this embodiment, the process configuration subsystem 302 is used to construct the process configuration file corresponding to the current battery swapping station on the visual interface according to the activated functional modules; and in response to the process configuration file being executed to the control node of the current battery swapping station, to send the standardized instructions corresponding to the control node to the service abstraction subsystem 303.

[0120] As an optional implementation method, such as Figure 4 As shown, the process configuration subsystem 302 may include a visual interface 302-1. Users can customize a process configuration file corresponding to the current battery swapping station 400 in the visual interface 302-1 according to the activated functional modules. Alternatively, the process configuration subsystem 302 itself can build the process configuration file corresponding to the current battery swapping station in the visual interface according to the activated functional modules. This application does not make any special limitations on this.

[0121] Understandably, a process configuration file contains multiple control nodes, each corresponding to an action that the physical device in the current battery swapping station 400 needs to perform. For example, the user or the process configuration subsystem 302 can build, edit, and debug the current business process of the battery swapping station 400 by dragging and dropping predefined, standardized control nodes.

[0122] For example, the control node may include vehicle location, battery unlocking, initiating charging, and sending detection reports, etc.

[0123] It should be noted that each control node encapsulates atomic-level business operations or device operation instructions.

[0124] Understandably, a process configuration file includes a complete process, such as a standard battery swapping process, a fast charging process, and a battery depth testing process, etc.

[0125] In some embodiments, the process configuration subsystem 302 can directly execute the process configuration file after obtaining it.

[0126] In another alternative embodiment, continue as follows Figure 4As shown, the process configuration subsystem 302 may include a process configuration database 302-2 and a process execution engine module 302-3.

[0127] After obtaining the process configuration file, the process configuration subsystem 302 can first store the process configuration file in a structured format in the process configuration database 302-2. Then, when the integrated control system is running, it can load and execute the process configuration file corresponding to the current battery swapping station from the process configuration database 302-2.

[0128] It is understood that structured format is a structured data format. For example, a structured data format can be JSON, XML, or a specific process description language, etc. This application does not make any special limitation on this.

[0129] It should be noted that when the process configuration file is retrieved from the process configuration database and executed, it can be done by an independent process engine module, specifically process execution engine module 302-3. Process execution engine module 302-3 parses the process definition and instantiates, schedules, and executes each control node sequentially. Upon reaching the control node of the current battery swapping station, it sends the standardized instructions corresponding to the control node to the service abstraction subsystem 303. In this way, without needing to concern itself with the specific implementation of the physical equipment in the current battery swapping station 400, the same integrated control system 300 can adapt to the business needs of various station types, from passenger car battery swapping stations and commercial vehicle battery swapping stations to integrated "swapping, storage, and inspection" stations, simply by loading different process configuration files.

[0130] Understandably, in this embodiment, the process configuration subsystem can store the process configuration file in the process configuration database to prevent loss. Furthermore, the process configuration file is stored in a structured format, thus unifying potentially disorganized configuration information. This unified format and clear hierarchy facilitate understanding and modification by developers, resulting in strong maintainability.

[0131] It is understood that in this embodiment, the process configuration subsystem can also call the process configuration file from the process configuration database only when needed (such as when the integrated control system is running). This "store first, use later" approach can save system resources of the integrated control system compared to the "use directly" approach, making the integrated control system run more smoothly.

[0132] In this embodiment, the service abstraction subsystem 303 is used to call the protocol configuration file of the current battery swapping station in the communication protocol subsystem 304 after receiving the standardized instruction; convert the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station, and send the private protocol instruction to the current battery swapping station 400 to control the current battery swapping station 400 to perform corresponding operations based on the private protocol instruction.

[0133] It is understood that in this embodiment, the functional modules loaded and activated by the module loading subsystem in the integrated control system are loaded and activated according to the list of modules to be loaded at the current battery swapping station. Therefore, the activated functional modules match the current operation of the battery swapping station, enabling an integrated control system to flexibly derive customized versions adapted to different battery swapping stations. This not only improves the flexibility of the integrated control system but also eliminates the need for further development of already developed functional modules, allowing them to be used directly, thus increasing the reusability (i.e., code reusability) of developed functional modules, reducing development costs, and accelerating project delivery. Furthermore, the process configuration subsystem in the integrated control system can construct the corresponding process configuration file for the current battery swapping station on the visual interface based on the activated functional modules. This decouples the current battery swapping station's business processes from rigid ones, allowing adjustments to the business processes based on different needs / application scenarios, improving the convenience of updating the current battery swapping station's business processes. Moreover, the process configuration subsystem can... After executing the control node of the current battery swapping station, the standardized command corresponding to the control node is sent to the service abstraction subsystem. This eliminates the need to consider the specific implementation of each functional module within the current battery swapping station, nor the differences in suppliers and structures of these modules. The same control command can adapt to functional modules from different manufacturers and models, improving the compatibility of the integrated control system. Furthermore, the service abstraction subsystem only calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized command. Then, it converts the standardized command into the current battery swapping station's proprietary protocol command based on the protocol configuration file. This approach decouples the upper-layer standardized control from the lower-layer proprietary protocol, achieving unified control and compatibility for different types and manufacturers of battery swapping stations without modifying the original equipment or the proprietary protocol. This further improves the versatility, scalability, and stability of the integrated control system, reduces deployment and maintenance costs, and facilitates large-scale application.

[0134] As another alternative embodiment, such as Figure 5 As shown, the module loading subsystem 301 may include a modular design system 301-1.

[0135] In this embodiment, the modular design system 301-1 is used to perform functional decomposition on the integrated control system 300 and determine multiple candidate functional modules.

[0136] Among them, the functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to the standard plug-in interface.

[0137] Understandably, the modular design system 301-1 can break down the complete functionality of the integrated control system 300 into independent candidate functional modules with high cohesion and low coupling.

[0138] For example, multiple candidate functional modules may include a DC charging control module, a battery swapping robot scheduling module, a battery storage management module, an online detection and analysis module, and a vehicle to grid (V2G) module, etc.

[0139] It should be noted that each candidate functional module is a virtual functional module, or it can be understood as a virtual device that corresponds one-to-one with each physical device in the current battery swapping station. Each candidate functional module is also a plug-in that enables the software function to be used "plug and play".

[0140] It should also be noted that each candidate functional module is an independent software package, including its own business logic, user interface components and internal data modules, and is developed in accordance with a unified plugin interface specification.

[0141] As another alternative embodiment, continue as follows Figure 5 As shown, the module loading subsystem 301 may also include a configuration loading system 301-2.

[0142] In this embodiment, a configuration loading system 301-2 is configured to obtain a list of modules to be loaded based on the current configuration requirements of the battery swapping station 400; and load and activate the corresponding functional modules based on the list of modules to be loaded.

[0143] It should also be noted that the module loading subsystem can obtain a list of modules to be loaded based on the current configuration requirements of the battery swapping station, and then load and activate the corresponding functional modules based on this list. It is important to note that only the functional modules that are configured to be loaded and activated will display their functional interface and services at runtime. For example, a base station that only provides battery swapping services will only contain battery swapping-related modules in its list of modules to be loaded; while a large integrated energy station may include charging, battery swapping, energy storage, and detection modules in its list. This design allows a unified software platform to flexibly derive customized versions for different scenarios, greatly improving code reusability and project delivery speed.

[0144] Understandably, in this embodiment, the module loading subsystem can functionally decompose the integrated control system to obtain multiple candidate functional modules. On the one hand, multiple candidate functional modules can cover the functional modules of different battery swapping stations, enabling the integrated control system to flexibly derive customized versions adapted to different battery swapping stations. Functional modules already developed in the battery swapping station do not need to be redeveloped and can be used directly, which can further improve the reusability (i.e., code reusability) of the developed functional modules, reduce development costs, and increase project delivery speed. On the other hand, since the interfaces of the obtained candidate functional modules are standard plug-in interfaces, they can be developed in accordance with a unified plug-in interface specification, which can improve the development speed and reduce manpower waste.

[0145] As another alternative embodiment, such as Figure 6 As shown, the communication protocol subsystem 304 includes a protocol configuration module 304-1.

[0146] In this embodiment, the protocol configuration module 304-1 can configure the protocol of each functional module in the current battery swapping station 400 according to the preset protocol rules, and determine the protocol configuration file of the current battery swapping station.

[0147] The preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table, and command-response mapping relationship.

[0148] In some embodiments, the protocol configuration module 304-1 can automatically configure the communication protocol rules of each functional module in the current battery swapping station 400 according to preset protocol rules; in other embodiments, the protocol configuration module 304-1 can allow users (e.g., developers or integration engineers) to configure the communication protocol rules of each functional module in the current battery swapping station 400. It should be noted that whether the protocol configuration module 304-1 performs protocol configuration or the user uses the protocol configuration module 304-1 to perform protocol configuration, it is only a description and does not require coding, thus reducing the development workload for developers.

[0149] When a new communication protocol emerges, the protocol configuration module 304-1 can also be used to configure the new communication protocol.

[0150] It should be noted that the emergence of a new communication protocol may be caused by the appearance of a new physical device within the current swapping station 400, i.e., the communication protocol of the new device; or it may be caused by the appearance of a new swapping station, etc. This application does not make any special limitation on this. The following will take the emergence of a new communication protocol caused by the appearance of a new physical device within the current swapping station 400 as an example for illustrative explanation.

[0151] It is understandable that the communication protocols of the various functional modules in the current battery swapping station 400 may be different due to different suppliers. The protocol configuration module 304-1 can configure the protocol rules of the communication protocols of the various functional modules in the current battery swapping station 400 according to the preset protocol rules, and determine the protocol configuration file of the current battery swapping station 400.

[0152] The determined protocol configuration file of the current swapping station 400 can be the protocol configuration file corresponding to each functional module (i.e., physical device) within the current swapping station 400, or it can be the protocol configuration file of the current swapping station 400 itself. This application does not make any special restrictions on this.

[0153] For example, the physical link parameters of the communication may include, but are not limited to, serial port baud rate, TCP / IP address and port, etc.; the message frame structure may include, but is not limited to, start character, length field, data field and checksum, etc.; the data point table may include, but is not limited to, the address, data type, scaling factor and unit of each monitoring point or control command, etc.

[0154] It is understood that, in this embodiment, the protocol configuration module in the communication protocol subsystem can configure the protocol rules of the communication protocols of each functional module in the current battery swapping station, so that the different communication protocol rules follow the preset protocol rules. Since the protocol rules of the communication protocol are changed by configuration rather than by hard coding, the workload of developers can be reduced and the development speed can be improved.

[0155] As another alternative embodiment, continue as follows Figure 6 As shown, the communication protocol subsystem 304 may also include a parsing engine module 304-2.

[0156] In this embodiment, the parsing engine module 304-2 is used to parse the device data based on the protocol configuration file when it receives the device data sent by the current swapping station 400, obtain parsed data, encapsulate the parsed data based on the preset encapsulation format, generate a standardized data object, and send the standardized data object to the service abstraction subsystem 303.

[0157] In this embodiment, the service abstraction subsystem 303 is also used to update the equipment data model corresponding to the current battery swapping station 400 based on standardized data objects.

[0158] In some embodiments, when the parsing engine module 304-2 receives device data sent by the current battery swapping station 400, it can parse the device data based on the protocol configuration file of the current battery swapping station 400. In other embodiments, when the parsing engine module 304-2 receives device data sent by the current battery swapping station 400, it can parse its own device data sent by the device through the current battery swapping station 400 based on the device's protocol configuration file. This application does not impose any particular limitation on this, and the following description will take the parsing of the device's own device data sent by the device through the current battery swapping station 400 based on the device's protocol configuration file as an example.

[0159] It should be noted that the parsing engine module 304-2 can dynamically parse the raw byte stream of device data and automatically complete operations such as unpacking, verification, data point extraction, and type conversion.

[0160] The type conversion can be to convert a two-byte integer to a floating-point value, or it can be to convert a two-byte integer to a floating-point temperature value, etc. This application does not make any special limitation on this. The following example will be used to illustrate the type conversion of a two-byte integer to a floating-point temperature value.

[0161] For example, the structure of a standardized data object may include timestamps, device IDs, and data point key-value pairs, etc.

[0162] It should be noted that the current device data model of the swapping station 400 can include several models. Each device data model corresponds to a functional module within the current swapping station and is obtained by mapping the functional modules within the current swapping station 400. The "device data model" can also be called the "device shadow" data model. That is to say, the service abstraction subsystem 303 maintains a "device shadow" data model corresponding to the physical device within the current swapping station 400. When the service abstraction subsystem 303 receives a standardized data object reported by a physical device in the current swapping station 400 and parsed by the communication protocol subsystem 304, it updates the standardized data object to the "device shadow" data model corresponding to that physical device for upper-layer business queries.

[0163] Understandably, this layer of abstraction completely separates the volatile and diverse equipment details from the stable and unified business logic, enabling parallel and decoupled business development and equipment integration work.

[0164] It is understood that, in this embodiment, the parsing engine module in the communication protocol subsystem can parse the device data sent by the current swapping station according to the configuration file of the current swapping station, thus improving the parsing speed. In addition, encapsulating the parsed data into standardized data objects can shield the differences in the data format of the device data sent by the current swapping station, making the integrated control system highly scalable, reusable and maintainable.

[0165] As another alternative embodiment, such as Figure 7 As shown, the service abstraction subsystem 303 includes an adaptation module 303-1 and a service abstraction interface 303-2.

[0166] In this embodiment, after receiving the standardized instruction, the adaptation module 303-1 calls the protocol configuration file of the current battery swapping station 400 in the communication protocol subsystem 304; based on the protocol configuration file, it converts the standardized instruction to obtain the private protocol instruction of the current battery swapping station 400, and sends the private protocol instruction to the service abstraction interface 303-2.

[0167] In this embodiment, after receiving the private protocol instruction, the service abstraction interface 303-2 sends the private protocol instruction to the current battery swapping station 400 to control the current battery swapping station 400 to perform corresponding operations based on the private protocol instruction.

[0168] In some embodiments, the service abstraction subsystem 303 can abstract all possible types of physical devices within the current battery swapping station 400 into a unified core data model (i.e., a standardized data model). The standardized data model defines the standard attributes of the physical devices (such as device ID, online status, operating mode, and alarm level, etc.). Then, based on the standardized data model, a set of standard device service interfaces are defined to obtain the service abstraction interface.

[0169] For example, the service abstraction interface 303-2 can be IDeviceService.getRealTimeData(deviceId), IDeviceService.sendControlCommand(deviceId, command, value), etc.

[0170] The IDeviceService.getRealTimeData(deviceId) function is to obtain the real-time status / data of a specified device. It is the core interface for device data acquisition and is suitable for scenarios such as sensor data (e.g., temperature, humidity) and device operating status (e.g., power on / off, speed).

[0171] The IDeviceService.sendControlCommand(deviceId, command, value) function sends control commands to a specified device. It is the core interface for reverse device control and is suitable for scenarios such as switch control (e.g., turning lights on / off), parameter adjustment (e.g., adjusting air conditioner temperature), and device operation (e.g., starting / stopping a motor).

[0172] It is understood that in this embodiment, the adaptation module and the service abstraction interface work together to convert the standardized instructions issued by the process configuration subsystem into the private protocol instructions of the current battery swapping station. In addition, since the service abstraction interface is a set of standard device service interfaces, it can reduce the complexity of interface adaptation and development costs, and reduce the difficulty of joint debugging.

[0173] As another optional embodiment, the configuration loading system 301-2 in the module loading subsystem 301 provided in this application embodiment is also used to obtain a new list of modules to be loaded based on the changed process configuration file when the process configuration file is changed, and then load and activate the corresponding functional modules based on the new list of modules to be loaded.

[0174] When the process document changes, the current business process of the battery swapping station 400 can be updated and upgraded by changing the process document.

[0175] It is understood that in this embodiment, when updating and upgrading the current battery swapping station, it is only necessary to obtain a new process configuration file, obtain a new list of modules to be loaded based on the new process configuration file, and then load and activate the corresponding functional modules based on the new list of modules to be loaded. Functional modules that have already been developed in the integrated control system do not need to be redeveloped, which can reduce the development workload of developers and improve the project delivery speed.

[0176] The following examples illustrate possible implementation schemes of the integrated control system described in one or more of the above embodiments.

[0177] Related technical solutions typically employ a centralized station control system architecture based on hard coding. The core of this approach lies in the fact that system developers must individually write and solidify control logic and communication driver code for each specific device within the battery swapping station (such as specific models of charging piles, battery swapping robots, battery storage racks, safety detectors, etc.). This code is directly embedded in the main station control program. The device's data point addresses, communication message formats (such as Modbus Remote Terminal Unit (MODBUS RTU) / Modbus Transmission Control Protocol (MODBUS TCP), Controller Area Network (CAN) bus, proprietary TCP protocol, etc.), control command sequences, and status parsing rules are all predefined in the form of constants, fixed structures, or conditional statements.

[0178] When on-site business processes (such as battery replacement sequence and charging strategies) need to be adjusted, or when equipment models or suppliers change, developers must manually find, modify, recompile, test, and deploy the entire station control software. This approach essentially binds equipment differences and process logic deeply to the core control system, forming a highly customized but rigid monolithic software.

[0179] In other words, while control methods for battery swapping stations already exist, existing technical solutions still have some problems. For example, a single battery swapping station may have anywhere from a few to dozens of different types of equipment, each with its own communication protocols, resulting in a huge development workload. Equipment with the same function in different swapping stations may also use different control systems, causing the already developed modules of the station control system to be unusable, requiring repeated development, wasting manpower, and extending project cycles. Furthermore, because the equipment interfaces and data types of various devices within the same swapping station are not standardized, upper-level business logic (such as charging strategies and battery swapping scheduling) requires extensive adaptation and special processing for specific devices, increasing system complexity and maintenance costs.

[0180] The integrated station control software platform for charging, swapping, storage and inspection provided in this embodiment is used to realize the development of an integrated station control system for charging, swapping, storage and inspection. It enables different station control systems to load different modules through a plug-in configuration software architecture, and enables the integration of drivers for different devices through software and hardware pre-embedded technology.

[0181] The core of this embodiment lies in constructing a highly configurable, modular, and decoupled integrated station control software platform for charging, swapping, storage, and inspection, referred to as the station control system (i.e., integrated control system). This system addresses the problems of low development efficiency, poor reusability, and difficult maintenance associated with traditional hard-coding methods at the architectural level. For example... Figure 3As shown, the integrated charging, swapping, storage, and inspection station control software platform provided in this embodiment includes the following four mutually cooperating subsystems, which together achieve the goal of "software-defined swapping station".

[0182] Subsystem 1, Process Configuration System (i.e., Process Configuration Subsystem 302): The process configuration system is the business process hub of the station control system provided in this embodiment. Its core is a visual process orchestration engine and a set of process definition specifications stored in the database.

[0183] like Figure 4 As shown, the process configuration system includes a visual orchestration interface (i.e., visual interface 302-1), a process configuration database 302-2, and a process engine (i.e., process execution engine module 302-3).

[0184] The visual orchestration interface provides users (such as implementation engineers or senior maintenance personnel) with a graphical user interface. Users can build, edit, and debug the entire business process of the battery swapping station by dragging and dropping predefined standardized "activity nodes" (such as "vehicle location", "battery unlock", "start charging", "send test report", etc.).

[0185] The process configuration database 302-2 encapsulates atomic-level business operations or device control instructions behind each "activity node." Complete business process definition files (such as "standard battery swapping process," "fast charging process," and "battery deep detection process") orchestrated by the user are saved to the process configuration database in a structured data format (such as JSON, XML, or a specific process description language). This process definition file precisely describes the execution order between nodes, branch judgment conditions (such as battery health status judgment), loops, and exception handling logic.

[0186] The process engine, specifically the independent process engine, loads the definition of a specified process (i.e., the complete business process definition file used for orchestration) from the process configuration database during station control system (i.e., integrated control system 300) operation. The process engine parses the process definition and instantiates, schedules, and executes each activity node sequentially. When the process reaches a certain device control node (i.e., an activity node), the process engine issues standardized instructions through the "Unified Device Data Model and Service Abstraction System" (i.e., service abstraction subsystem 303), without needing to concern itself with the specific implementation of the underlying device.

[0187] Understandably, the process configuration system enables the same set of station control software (i.e., the integrated control system 300) to adapt to the business needs of various station types, such as passenger car battery swapping stations, commercial vehicle battery swapping stations, and integrated "swapping, storage, and inspection" stations, simply by loading different process configuration files.

[0188] Subsystem 2, Plug-in Module Loading System (i.e., Module Loading Subsystem 301): The plug-in module loading system is the functional combination framework of this embodiment, which realizes the "plug and play" of software functions.

[0189] like Figure 5 As shown, the plug-in module loading system includes a modular design system 301-1 and a configuration loading system (i.e., a configuration loading system).

[0190] The modular design system 301-1 involves first breaking down the complete functions of the station control system into highly cohesive and loosely coupled independent functional modules (plug-ins). Examples include "DC charging control module", "battery swapping robot scheduling module", "battery storage management module", "online detection and analysis module", and "V2G (vehicle-to-grid) module".

[0191] It should be noted that each module is an independent software package, including its own business logic, user interface components and internal data model, and is developed in accordance with a unified plugin interface specification.

[0192] The configuration-based loading system involves the following steps during the station control system initialization phase: The system reads a "module manifest configuration file" (i.e., a list of modules to be loaded) based on the current hardware configuration and business requirements of the battery swapping station. This file lists the modules that need to be activated and their initialization parameters. The configuration-based loading system may include a core container (such as the OSGi framework or a custom lightweight plugin manager) that dynamically loads, instantiates, and registers the corresponding modules according to the "module manifest configuration file."

[0193] In another example, the core container may be set in a pluggable module loading system instead of a configuration-based loading system, and this application does not impose any particular restrictions on this.

[0194] Understandably, during the operation of the station control system, the loaded modules are combined, and only the modules loaded by the configuration loading system will present their functional interface and services at runtime. For example, a base station that only provides battery swapping services will only contain battery swapping-related modules in its configuration list; while a large integrated energy station may include all modules such as charging, battery swapping, energy storage, and detection in its list.

[0195] Understandably, the plug-in module loading system enables a unified software platform (i.e., the station control system) to flexibly generate customized versions for different scenarios, greatly improving code reusability and project delivery speed.

[0196] Subsystem 3, Communication Protocol Custom Parsing System (i.e., Communication Protocol Subsystem 304): The custom communication protocol parsing system is the device access layer in this embodiment, responsible for shielding the communication heterogeneity of the underlying devices.

[0197] like Figure 6 As shown, the custom parsing system for communication protocols includes protocol modeling and configuration (i.e., protocol configuration module 304-1) and general engine parsing (i.e., parsing engine module 304-2).

[0198] Protocol modeling and configuration provides a protocol configuration tool that allows developers or integration engineers to "describe" rather than "code" new device communication protocols. Through this tool, developers or integration engineers can define: communication physical link parameters (such as serial port baud rate, TCP / IP address and port), message frame structure (such as start character, length field, data field, and checksum), data point table (address, data type, scaling factor, and unit for each monitoring point or control command), and command-response mapping relationships. These definitions are saved as a structured protocol configuration file.

[0199] The new equipment communication protocol can be the communication protocol of new equipment in the current battery swapping station, or a new communication protocol, or a new battery swapping station, etc. This application does not make any special restrictions on this.

[0200] The general parsing engine is located at the bottom layer of the custom parsing system for communication protocols. When device data arrives, the general parsing engine dynamically parses the raw byte stream according to the protocol configuration file bound to the device. The general parsing engine can automatically perform operations such as unpacking, verification, data point extraction, and type conversion (e.g., converting a two-byte integer to a floating-point temperature value), and finally encapsulates the parsed data into a standardized data object containing a timestamp, device ID, and data point key-value pairs.

[0201] The protocol configuration tool can be understood as "customizing rules", and the general parsing engine can be understood as "using rules".

[0202] It's important to note that, essentially, loading each protocol configuration file is equivalent to "generating" a software driver for that type of device. This eliminates the need for developers to write a single line of communication parsing code when integrating new devices. They can simply use configuration tools to complete protocol modeling and testing, reducing the workload of device integration from the "week / day" level to the "hour" level.

[0203] Subsystem 4, Unified Device Data Model and Service Abstraction System (i.e., Service Abstraction Subsystem 303): The unified equipment data model and service abstraction system is the "adapter layer" and "translator" that connects the upper-layer business (such as processes and modules) with the lower-layer equipment drivers. It is the key to ensuring the configurability and scalability of the entire station control system.

[0204] like Figure 7 As shown, the unified device data model and service abstraction system may include service abstraction interface 303-2 and model mapping and adaptation (i.e., adaptation module 303-1).

[0205] The unified equipment data model and service abstraction system abstracts a unified core data model (i.e., a standardized data model) for all possible types of equipment within a battery swapping station. This model defines the standard attributes of the equipment (such as equipment ID, online status, operating mode, and alarm level).

[0206] Among them, the service abstraction interface: Based on this standardized data model, a set of standard device service interfaces are defined (e.g., IDeviceService.getRealTimeData(deviceId), IDeviceService.sendControlCommand(deviceId, command, value) etc.). All upper-layer business modules (such as process engine and monitoring interface) interact with the devices in the current battery swapping station through the service abstraction interface.

[0207] Among them, model mapping and adaptation: For each specific connected device instance, the unified device data model and service abstraction system maintains a "device shadow" and an "adapter". The adapter is responsible for two things: First, it translates standardized instructions (such as "set charging current to 100A") into specific byte instructions that conform to its private protocol by querying the device's configuration (i.e., protocol configuration file) in the "communication protocol custom parsing system" and then issues them; Second, it updates the standardized data objects reported by the device and parsed by the "communication protocol custom parsing system" into the device's "device shadow" data model for upper-layer business queries.

[0208] Understandably, by using a unified device data model and service abstraction system, the volatile and diverse device details are completely separated from the stable and unified business logic, thus achieving parallel and decoupled business development and device integration.

[0209] In this embodiment, on the one hand, the process configuration system not only enables the same station control software to adapt to different battery swapping station business processes, but also simplifies the difficulty and workload of driver development when adding new equipment to the station control management system, and enables customized development of different business processes within modules. On the other hand, by loading different modules through plug-ins, a single station control software can provide multiple combined functions such as charging, swapping, storage, and inspection. Furthermore, by using a unified equipment data model and service abstraction system, the heterogeneity of the underlying equipment (differences in protocols, instructions, and data formats) is decoupled from the upper-layer business logic (such as charging strategies and battery swapping scheduling). Upper-layer applications do not need to care about the implementation details of specific equipment; they only need to call standardized service interfaces and access data in a unified format. This greatly reduces the development complexity of business modules and the difficulty of joint debugging with equipment, and improves the reusability of business logic and the maintainability of the system.

[0210] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution.

[0211] It should be noted that the module division in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or have two or more units integrated into one unit. The integrated units can be implemented in hardware, as software functional units, or a combination of software and hardware.

[0212] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0213] Based on the same inventive concept as the foregoing embodiments, this application also provides a computer-readable storage medium for storing computer programs.

[0214] Optionally, the computer-readable storage medium can be used in an electronic device, and the computer program causes a processor or electronic device to perform the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0215] Based on the same inventive concept as the foregoing embodiments, this application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by an integrated control system, they implement the steps of the methods provided in the above embodiments.

[0216] Based on the same inventive concept as the foregoing embodiments, this application provides a computer program.

[0217] Optionally, the computer program can be applied to an electronic device. When the computer program runs on a processor or electronic device, it causes the processor or electronic device to execute the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0218] It should be noted that the descriptions of the storage media, computer program products, and computer program embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage media, computer program products, and computer program embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0219] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0220] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0221] 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.

[0222] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or modules can be electrical, mechanical, or other forms.

[0223] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0224] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0225] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions, and the program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments.

[0226] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0227] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0228] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0229] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0230] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A control method, characterized in that, The control method is applied to an integrated control system, which includes a module loading subsystem, a process configuration subsystem, a service abstraction subsystem, and a communication protocol subsystem. The control method includes: The module loading subsystem obtains a list of modules to be loaded based on the current configuration requirements of the battery swapping station; and loads and activates the corresponding functional modules based on the list of modules to be loaded. The process configuration subsystem constructs a process configuration file corresponding to the current battery swapping station in the visual interface based on the activated functional modules; and in response to the execution of the process configuration file to the control node of the current battery swapping station, it sends a standardized instruction corresponding to the control node to the service abstraction subsystem through the process configuration subsystem. Upon receiving the standardized instruction, the service abstraction subsystem calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem; it converts the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station, and sends the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction. The service abstraction subsystem includes an adaptation module and a service abstraction interface, and the control method further includes: After receiving the standardized instruction, the adaptation module calls the protocol configuration file of the current battery swapping station in the communication protocol subsystem; and converts the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station. The service abstraction interface sends the private protocol instructions to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instructions.

2. The control method according to claim 1, characterized in that, The control method further includes: After obtaining the process configuration file corresponding to the current battery swapping station, the process configuration subsystem stores the process configuration file in a structured format in the process configuration database.

3. The control method according to claim 2, characterized in that, The control method further includes: When the integrated control system is running, the process configuration subsystem loads the process configuration file corresponding to the current battery swapping station from the process configuration database and executes the process configuration file.

4. The control method according to claim 1, characterized in that, The control method further includes: The module loading subsystem performs functional decomposition on the integrated control system and determines multiple candidate functional modules; The functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to the standard plug-in interface.

5. The control method according to any one of claims 1 to 4, characterized in that, The communication protocol subsystem includes a protocol configuration module, and the control method further includes: The protocol configuration module configures the protocols of each functional module in the current battery swapping station according to preset protocol rules, and determines the protocol configuration file of the current battery swapping station. The preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table, and command-response mapping relationship.

6. The control method according to claim 5, characterized in that, The communication protocol subsystem includes a parsing engine module, and the control method further includes: When the parsing engine module receives the device data sent by the current battery swapping station, it parses the device data based on the protocol configuration file to obtain parsed data, and encapsulates the parsed data based on a preset encapsulation format to generate a standardized data object, and sends the standardized data object to the service abstraction subsystem. The service abstraction subsystem updates the equipment data model corresponding to the current battery swapping station based on the standardized data object; the equipment data model is obtained by model mapping based on the functional modules in the current battery swapping station.

7. An integrated control system, characterized in that, It includes a module loading subsystem, a process configuration subsystem, a service abstraction subsystem, and a communication protocol subsystem; among which: The module loading subsystem is used to obtain a list of modules to be loaded based on the current configuration requirements of the battery swapping station; and to load and activate the corresponding functional modules based on the list of modules to be loaded. The process configuration subsystem is used to construct a process configuration file corresponding to the current battery swapping station in the visual interface according to the activated functional modules; and in response to the process configuration file being executed to the control node of the current battery swapping station, to send a standardized instruction corresponding to the control node to the service abstraction subsystem. The service abstraction subsystem is used to, upon receiving the standardized instruction, call the protocol configuration file of the current battery swapping station in the communication protocol subsystem; convert the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station, and send the private protocol instruction to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instruction; The service abstraction subsystem includes a service abstraction interface and an adaptation module, wherein: The adaptation module is used to call the protocol configuration file of the current battery swapping station in the communication protocol subsystem after receiving the standardized instruction; and to convert the standardized instruction based on the protocol configuration file to obtain the private protocol instruction of the current battery swapping station. The service abstraction interface is used to send the private protocol instructions to the current battery swapping station to control the current battery swapping station to perform corresponding operations based on the private protocol instructions.

8. The integrated control system according to claim 7, characterized in that, The process configuration subsystem is also used to store the process configuration file in a structured format into the process configuration database after obtaining the process configuration file corresponding to the current battery swapping station.

9. The integrated control system according to claim 8, characterized in that, The process configuration subsystem is also used to load the process configuration file corresponding to the current battery swapping station from the process configuration database and execute the process configuration file when the integrated control system is running.

10. The integrated control system according to claim 7, characterized in that, The module loading subsystem is also used to perform functional decomposition of the integrated control system and determine multiple candidate functional modules; The functional modules in the list of modules to be loaded are some or all of the multiple candidate functional modules, and the interfaces of the multiple candidate functional modules conform to the standard plug-in interface.

11. The integrated control system according to any one of claims 7 to 10, characterized in that, The communication protocol subsystem includes a protocol configuration module, wherein: The protocol configuration module is used to configure the protocols of each functional module in the current battery swapping station according to preset protocol rules, and to determine the protocol configuration file of the current battery swapping station. The preset protocol rules include at least one of the following: communication physical link parameters, message frame structure, data point table, and command-response mapping relationship.

12. The integrated control system according to claim 11, characterized in that, The communication protocol subsystem also includes a parsing engine module, wherein: The parsing engine module is used to parse the device data based on the protocol configuration file when it receives device data sent by the current battery swapping station, obtain parsed data, encapsulate the parsed data based on a preset encapsulation format, generate a standardized data object, and send the standardized data object to the service abstraction subsystem. The service abstraction subsystem is also used to update the equipment data model corresponding to the current battery swapping station based on the standardized data object; the equipment data model is obtained by model mapping based on the functional modules in the current battery swapping station.

13. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by an integrated control system, implement the steps of the method as described in any one of claims 1 to 6.

Images