Microgrid operating system, method, device, equipment, medium and program product

By adopting a layered and decoupled architecture consisting of a device abstraction layer, a core service layer, and an artificial intelligence core layer, the problems of device compatibility and scheduling delay in traditional microgrid systems are solved, enabling plug-and-play functionality for heterogeneous devices and efficient operation and maintenance of the system.

CN121663816APending Publication Date: 2026-03-13HAIER ENERGY TECHNOLOGY CO LTD
View PDF 8 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-02-06
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

The closed nature and customized development of traditional microgrid operating systems make system upgrades difficult, maintenance costs high, scheduling delays severe, and they are difficult to support plug-and-play functionality for heterogeneous devices from multiple vendors.

Method used

The device abstraction layer maps heterogeneous physical devices into standardized device data objects, the core service layer handles registration and publishing, the application runtime environment layer implements business logic isolation, and the artificial intelligence core layer generates microgrid scheduling instructions, forming a layered and decoupled architecture.

Benefits of technology

It enables plug-and-play functionality for heterogeneous devices, reduces maintenance costs, improves system availability, reduces scheduling latency, and enhances system integration efficiency and flexibility.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121663816A_ABST
    Figure CN121663816A_ABST
Patent Text Reader

Abstract

The invention provides a micro-grid operating system, method, device and equipment, a medium and a program product. The system comprises a device abstraction layer, a core service layer, an application operation environment layer, a business application layer and an artificial intelligence core layer. The device abstraction layer is used for accessing a plurality of heterogeneous physical devices and mapping device data of each heterogeneous physical device into a standardized device data object; the core service layer is used for registering each equipment data object to obtain an equipment directory; each equipment data object is published to the corresponding storage path; the application running environment layer is used for distributing an independent running environment for each business application in the business application layer; the business application layer is used for calling the core service layer to obtain a corresponding equipment data object; and each business application executes business logic according to the equipment data object in the independent operation environment. And the artificial intelligence core layer is used for generating a micro-grid dispatching instruction. The operation and maintenance cost is reduced, the system availability is improved, and the scheduling delay of the micro-grid is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of microgrid technology, and in particular to a microgrid operating system, method, apparatus, equipment, medium and program product. Background Technology

[0002] In typical microgrid scenarios such as industrial parks, commercial buildings, and residential communities, various energy devices, including photovoltaics, energy storage, charging piles, and controllable loads, need to be coordinated and operated through a unified control system. These scenarios place extremely high demands on the reliability, flexibility, and intelligence of microgrid systems. Microgrids need to support plug-and-play capabilities for heterogeneous devices from multiple vendors to avoid redundant development costs caused by protocol differences.

[0003] Currently, traditional microgrid operating systems mostly rely on monolithic energy management systems, whose closed and customized development models make system upgrades difficult. For example, when adding energy storage equipment to a facility, the entire energy management system code needs to be modified and the system shut down and restarted, resulting in high operation and maintenance costs and low system availability. Moreover, traditional microgrid operating systems require manual or semi-automatic methods to parse the system status when scheduling the microgrid, leading to delays in microgrid scheduling. Summary of the Invention

[0004] This application provides microgrid operating systems, methods, devices, equipment, media, and program products to reduce operation and maintenance costs, improve system availability, and reduce microgrid scheduling delays.

[0005] In a first aspect, embodiments of this application provide a microgrid operating system, comprising: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer; the device abstraction layer is used to access multiple heterogeneous physical devices and map the device data of each heterogeneous physical device to standardized device data objects; the core service layer is used to register each device data object to obtain a device catalog and publish each device data object to a corresponding storage path; wherein the device catalog allocates a storage path for each device data object; the application runtime environment layer is used to allocate an independent runtime environment for each business application in the business application layer; the business application layer is used to call the core service layer to obtain the storage path of the target heterogeneous physical device from the device catalog and obtain the corresponding device data object according to the storage path; each business application executes business logic according to the device data object in an independent runtime environment; the artificial intelligence core layer is used to generate microgrid scheduling instructions and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions.

[0006] In one possible implementation, the device abstraction layer includes multiple virtual device drivers; wherein each virtual device driver supports dynamic loading and hot-plugging; correspondingly, the device abstraction layer is used to access multiple heterogeneous physical devices and map the device data of each heterogeneous physical device to a standardized device data object, including: each virtual device driver accesses a heterogeneous physical device and maps the device data of each heterogeneous physical device to a standardized device data object conforming to a unified information model.

[0007] In one possible implementation, the core service layer includes a registration module and a unified data bus module; correspondingly, the core service layer is used to register each device data object to obtain a device directory; and publish each device data object to the corresponding storage path, including: a registration module, used to register each device data object to obtain a device directory; and publish each device data object to the unified data bus module; the unified data bus module is used to publish each device data object to the corresponding storage path.

[0008] In one possible implementation, the core service layer includes a data access service module; correspondingly, the business application layer is used to call the core service layer to obtain the storage path of the target heterogeneous physical device from the device directory and obtain the corresponding device data object according to the storage path, including: the business application layer is used to call the data access service module to obtain the storage path of the target heterogeneous physical device from the device directory and obtain the corresponding device data object according to the storage path.

[0009] In one possible implementation, the artificial intelligence core layer is used to generate microgrid dispatch instructions and send the microgrid dispatch instructions to corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid dispatch instructions. This includes: the artificial intelligence core layer generating a microgrid situation map; generating a microgrid dispatch decision based on the microgrid situation map; generating microgrid dispatch instructions based on the microgrid dispatch decision, and sending the microgrid dispatch instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid dispatch instructions.

[0010] In one possible implementation, the AI ​​core layer includes a multimodal perception and fusion module, an inference and decision-making module, and an instruction execution module. Accordingly, the AI ​​core layer is used to generate a microgrid situation map; generate microgrid scheduling decisions based on the microgrid situation map; generate microgrid scheduling instructions based on the microgrid scheduling decisions, and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions. This includes: the multimodal perception and fusion module, used to call the core service layer to obtain data objects from each device; receive external multi-source data sent by the data terminal; and generate a microgrid situation map based on the data objects from each device and the external multi-source data; wherein, external multi-source data refers to external data related to microgrid operation; the inference and decision-making module, used to generate microgrid scheduling decisions based on the microgrid situation map; and the instruction execution module, used to generate microgrid scheduling instructions based on the microgrid scheduling decisions and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions.

[0011] In one possible implementation, the reasoning and decision-making module is further configured to parse the natural language instructions input by the operator and decompose the natural language instructions into an executable task chain; the instruction execution module is further configured to generate microgrid scheduling instructions based on the executable task chain.

[0012] In one possible implementation, the instruction execution module is further configured to encapsulate microgrid dispatch instructions and save the encapsulated microgrid dispatch instructions to the instruction encapsulation library.

[0013] In one possible implementation, the instruction execution module is also used to construct a microgrid digital twin model; based on the microgrid digital twin model, to deduce the deduction effect of the microgrid dispatch instructions; if the deduction effect matches the preset deduction effect, then the microgrid dispatch instructions are determined to be valid.

[0014] Secondly, embodiments of this application provide a microgrid operation method applied to a microgrid operating system. The microgrid operating system includes: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The method includes: accessing multiple heterogeneous physical devices through the device abstraction layer and mapping the device data of each heterogeneous physical device to standardized device data objects; registering each device data object through the core service layer to obtain a device directory; and publishing each device data object to a corresponding storage path; wherein the device directory allocates a storage path for each device data object; allocating an independent runtime environment for each business application in the business application layer through the application runtime environment layer; calling the core service layer through the business application layer to obtain the storage path of the target heterogeneous physical device from the device directory and obtain the corresponding device data object according to the storage path; each business application executing business logic according to the device data object in its independent runtime environment; and generating microgrid scheduling instructions through the artificial intelligence core layer and sending the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions.

[0015] Thirdly, embodiments of this application provide a microgrid operation device applied to a microgrid operating system. The microgrid operating system includes: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The device includes: an access module, used to access multiple heterogeneous physical devices through the device abstraction layer and map the device data of each heterogeneous physical device to standardized device data objects; a publishing module, used to register each device data object through the core service layer to obtain a device directory and publish each device data object to a corresponding storage path; wherein the device directory allocates a storage path for each device data object; an allocation module, used to allocate an independent runtime environment for each business application in the business application layer through the application runtime environment layer; an execution module, used to call the core service layer through the business application layer to obtain the storage path of the target heterogeneous physical device from the device directory and obtain the corresponding device data object according to the storage path; each business application executes business logic according to the device data object in the independent runtime environment; and a generation module, used to generate microgrid scheduling instructions through the artificial intelligence core layer and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions.

[0016] Fourthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0017] The memory stores instructions that the computer executes;

[0018] The processor executes computer execution instructions stored in memory, causing the processor to perform the second aspect and / or various possible implementations of the second aspect as described above.

[0019] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the second aspect and / or various possible implementations of the second aspect.

[0020] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the second aspect and / or various possible implementations of the second aspect as described above.

[0021] The microgrid operating system, method, apparatus, device, medium, and program products provided in this application embodiment include a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The device abstraction layer connects multiple heterogeneous physical devices and maps the device data of each heterogeneous physical device to standardized device data objects. This transforms hardware heterogeneity into unified device data objects, eliminates hardware heterogeneity, enables plug-and-play devices, and ensures that new devices can be connected without system downtime. This design reduces the complexity of integrating heterogeneous physical devices from code development to parameter configuration, significantly improving system integration efficiency. The core service layer registers each device data object to obtain a device directory and publishes each device data object to its corresponding storage path, decoupling data producers and consumers. This allows the system to connect new physical devices or deploy new business applications without system downtime. The application runtime environment layer allocates independent runtime environments to each business application in the business application layer, ensuring the isolation of business logic. A single business application failure will not affect the core functions of the system. The business application layer calls the core service layer to obtain the storage path of the target heterogeneous physical device from the device catalog, and then retrieves the corresponding device data object based on the storage path. Each business application executes its business logic based on the device data object in an independent operating environment. The artificial intelligence core layer generates microgrid scheduling instructions and sends them to the corresponding heterogeneous physical devices to enable them to execute the instructions. By decoupling the microgrid operating system into a layered structure—device abstraction layer, core service layer, application runtime environment layer, business application layer, and artificial intelligence core layer—the shortcomings of existing technologies in terms of device compatibility and system scalability are resolved. When new energy storage devices are added to the park, it is not necessary to completely modify the energy management system code or shut down and restart, reducing maintenance costs and improving system availability. Moreover, the artificial intelligence core layer can automatically generate microgrid scheduling instructions without manually or semi-automatically parsing the system status and sending the instructions to the corresponding heterogeneous physical devices, thereby reducing microgrid scheduling latency. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 A schematic diagram of the microgrid operating system provided in the embodiments of this application. Figure 1 ;

[0024] Figure 2 A schematic diagram of the microgrid operating system provided in the embodiments of this application. Figure 2 ;

[0025] Figure 3 A flowchart illustrating the microgrid operation method provided in this application embodiment;

[0026] Figure 4 This is a schematic diagram of the microgrid operating device provided in the embodiments of this application;

[0027] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0028] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] To address the aforementioned technical problems, this application proposes the following technical concept: Starting from the pain points of existing technologies, the inventors first propose a device abstraction layer to solve the compatibility problem of heterogeneous devices. Through virtual drivers, physical devices are mapped to standardized device data objects, achieving protocol-independent access capabilities. Subsequently, a core service layer is designed, introducing a registration module and a unified data bus module to register each device data object, obtaining a device catalog; and each device data object is published to its corresponding storage path, decoupling data producers and consumers. Further, an application runtime environment layer is introduced to achieve resource isolation and hot updates for business applications. Finally, the business application layer calls the core service layer to obtain the storage path of the target heterogeneous physical device from the device catalog, and retrieves the corresponding device data object based on the storage path; each business application executes its logic based on the device data object in an independent runtime environment. This evolution path systematically solves the shortcomings of existing technologies in terms of device compatibility and system scalability. When new energy storage devices are added to the park, it is not necessary to completely modify the energy management system code or shut down and restart, reducing operation and maintenance costs and improving system availability. Finally, to address the issue of microgrid scheduling delay, an artificial intelligence core layer is constructed, integrating multimodal perception, real-time reasoning, digital twin verification, and secure execution. This includes a multimodal perception and fusion module, a reasoning and decision-making module, and an instruction execution module, forming a closed loop of perception-decision-verification-execution. This automatically generates microgrid scheduling instructions, reducing microgrid scheduling delay.

[0031] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0032] Figure 1 A schematic diagram of the microgrid operating system provided in the embodiments of this application. Figure 1 ,like Figure 1 As shown, the microgrid operating system includes a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer.

[0033] The device abstraction layer is used to connect multiple heterogeneous physical devices and map the device data of each heterogeneous physical device into standardized device data objects.

[0034] In this embodiment, heterogeneous physical devices refer to various physical devices connected to the microgrid that come from different manufacturers, use different communication protocols, and have incompatible data formats. Their core characteristics are that their hardware models, communication methods, and data formats differ, but they all serve the operation of the microgrid.

[0035] For example, heterogeneous physical devices include photovoltaic inverters, energy storage converters, charging piles, electricity meters, and weather instruments.

[0036] In this embodiment, the device abstraction layer includes multiple virtual device drivers; each virtual device driver supports dynamic loading and hot-plugging.

[0037] Dynamic loading means that adding heterogeneous physical devices requires no system downtime and is immediately usable upon connection. Hot-swapping means that removing or replacing heterogeneous physical devices does not affect the system, ensuring uninterrupted maintenance. For example, when a heterogeneous physical device needs repair, replacement, or obsolescence, the corresponding virtual device driver can be directly uninstalled. The operation of virtual device drivers for other heterogeneous physical devices and the normal functionality of business applications remain unaffected, and the system continues to run stably. When the device is reconnected subsequently, simply reloading the driver restores its functionality.

[0038] In this embodiment, each virtual device driver connects to a heterogeneous physical device and maps the device data of each heterogeneous physical device to a standardized device data object that conforms to a unified information model.

[0039] In this embodiment, the device abstraction layer contains multiple virtual device drivers, each corresponding to a heterogeneous physical device. The core function of the virtual device driver is to translate the raw data of the physical device, such as messages from different protocols, into standardized device data objects that are uniformly recognized by the system. For example, regardless of the brand of the photovoltaic inverter, it is uniformly converted into a data format containing standard attributes such as active power and operating status.

[0040] In this embodiment, the virtual device driver supports dynamic loading and hot-plugging. That is, when a new physical device is added at runtime, only the corresponding virtual device driver needs to be loaded, without any downtime, and it is plug-and-play.

[0041] In this embodiment, the unified information model is a standardized data structure used to define the attributes and behaviors of physical devices, and is used to mask hardware differences.

[0042] For example, the unified information model is as follows:

[0043] ID: Device_PV_01

[0044] Attribute: Active power

[0045] Attribute: Running status

[0046] Method: setPower()

[0047] In this embodiment, the virtual device driver encapsulates the mapped standard attributes into a recognizable, standardized device data object. This device data object not only contains the device's real-time data but also integrates the device's basic information, such as device ID, type, and executable operations, making it a complete, structured abstract entity.

[0048] For example, the device data object is:

[0049] {

[0050] "Device ID": "Device_PV_01",

[0051] Equipment Type: Photovoltaic Inverter

[0052] "Attributes": {

[0053] Active power: 50kW

[0054] "Running Status": "Normal"

[0055] Daily power generation: 200 kWh

[0056] },

[0057] Supported operations: ["setPower()", "getStatus()"]

[0058] }

[0059] In this embodiment, the upper-layer core service layer and business application layer do not need to care about the device manufacturer, protocol, or original data format; they only need to call the standardized device data object. Even if the physical device brand is changed, as long as the driver can complete the standardized mapping, the upper-layer system does not need any modifications, thus solving the pain point of rewriting the parsing code when changing physical devices in traditional methods.

[0060] The core service layer is used to register data objects of each device to obtain a device directory; and to publish each data object of each device to the corresponding storage path; the storage path is allocated for each data object of each device in the device directory.

[0061] In this embodiment, the core responsibility of the core service layer is to uniformly manage all heterogeneous physical devices and their corresponding device data objects, providing upper-layer applications with channels for finding and retrieving data, and is the core of inter-layer collaboration.

[0062] In this embodiment, the core service layer includes a registration module and a unified data bus module. The registration module registers each device data object to obtain a device directory and publishes each device data object to the unified data bus module. The unified data bus module publishes each device data object to its corresponding storage path.

[0063] In this embodiment, the registration module receives the device data object uploaded by the device abstraction layer, and creates an identity profile for each physical device when the virtual device driver starts, forming a unified device directory;

[0064] In this embodiment, the device directory records where the data corresponding to which physical device is stored, i.e., the storage path.

[0065] In this embodiment, the device data objects synchronized by the registration module are stored according to the storage path allocated in the device directory. The microgrid operating system, through the registration module, has the ability to detect newly added physical devices and new business applications in real time.

[0066] In this embodiment, the unified data bus module adopts a publish / subscribe mechanism, which can decouple the data producer (device abstraction layer) and the consumer (business application layer). The physical device is only responsible for transmitting data to the unified data bus module, and the business application layer is only responsible for receiving data from the unified data bus module. The two parties do not need to directly interface.

[0067] In this embodiment, the core service layer includes a data access service module and a business application layer, which is used to call the data access service module to obtain the storage path of the target heterogeneous physical device from the device directory and obtain the corresponding device data object according to the storage path.

[0068] In this embodiment, the data access service module provides the upper-layer business application layer with a standardized access interface that shields the details of the underlying protocol, allowing business applications to make API calls through this interface to query the device directory, obtain the storage path, and read the corresponding data. All of these data are standardized data streams.

[0069] The application runtime environment layer is used to allocate independent runtime environments for each business application in the business application layer.

[0070] In this embodiment, the application runtime environment layer addresses the issue of interference between multiple applications. The application runtime environment layer employs containerization or microservice isolation technologies to allocate independent computing, memory, and network resources to each business application (such as equipment operation monitoring applications, energy management applications, and virtual power plant proxy interface applications). The crash or upgrade of one business application will not affect other business applications or the system core; this is crucial for fault isolation.

[0071] In this embodiment, the application runtime environment layer manages the lifecycle of business applications, supporting hot updates, independent scaling, or fault isolation without interfering with the system kernel. This enables business applications to be packaged once and run anywhere, as well as hot deployment and elastic scaling. Application upgrades and rollbacks can be performed independently, greatly improving the flexibility and reliability of system maintenance.

[0072] The business application layer is used to call the core service layer, obtain the storage path of the target heterogeneous physical device from the device directory, and obtain the corresponding device data object based on the storage path; each business application executes business logic based on the device data object in an independent running environment.

[0073] In this embodiment, the business application layer serves as the functional implementation carrier of the microgrid. Its core responsibility is to implement specific business logic based on device data objects. The business application layer consists of multiple independent business applications running within the application runtime environment layer. These applications obtain data and services by calling the data access service module provided by the core service layer, focusing on implementing business logic such as real-time monitoring, advanced energy management, power prediction, and virtual power plant agency. Applications can be independently developed by different vendors, forming an ecosystem.

[0074] For example, taking a campus microgrid that includes photovoltaics, energy storage, and adjustable loads as an example, the connection of heterogeneous physical devices is explained as follows:

[0075] Step 1: Deploy the core service layer of the microgrid operating system on the microgrid server or controller. At this stage, the microgrid operating system does not yet have any specific physical devices or business applications.

[0076] Step 2: Maintenance personnel connect a photovoltaic inverter of a certain brand to the microgrid network. In the management interface of the microgrid operating system, they select and load a virtual device driver matching the photovoltaic inverter model from the driver repository. If no ready-made driver is available in the repository, the driver development framework provided by the microgrid operating system can be used to quickly generate a driver based on the physical device protocol point table. The virtual device driver establishes a communication connection with the photovoltaic inverter. Subsequently, the virtual device driver sends a registration message to the registration module of the core service layer, reporting a logical device instance and describing the device data object. For example, it includes data attributes such as current active power, daily power generation, and operating status. The registration module enters this device data object into the directory. The virtual device driver begins to periodically collect data and publishes the device data object to the unified data bus module. For example, the storage path of the device data object is: / MicrogridA / PV / Inverter_01 / ActivePower.

[0077] Step 3: Application developers use the Software Development Kit (SDK) provided by the microgrid operating system to write a simple photovoltaic monitoring dashboard application. This application declares via the SDK that it needs to subscribe to data stored at the path ` / MicrogridA / PV / + / ActivePower`, where `+` is a wildcard matching all photovoltaic inverters. Optionally, the storage paths of all photovoltaic inverters can be obtained by querying the device directory. Developers package the application code into a Docker container image. Operations personnel upload this image and create a new application container instance through the microgrid operating system's management interface. The microgrid operating system automatically configures the network for this container, enabling it to access the data access service module of the core service layer. After the container starts, the photovoltaic monitoring dashboard application automatically connects to the unified data bus module via the SDK and begins receiving real-time power data from all registered photovoltaic inverters for visualization. The entire process requires no modification to the microgrid operating system's core code or other applications.

[0078] Optionally, if a new energy storage system needs to be added to the microgrid in the park, simply repeat step two to load the virtual device driver for the energy storage converter. The new energy storage data will automatically be imported into the unified data bus module. At this point, an already deployed "economic dispatch" application can immediately discover this new controllable resource by querying the registration module and begin optimizing its dispatch, without requiring any modification or redeployment of the "economic dispatch" application itself.

[0079] The core layer of artificial intelligence is used to generate microgrid dispatch instructions and send them to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid dispatch instructions.

[0080] In this embodiment, the core AI layer is the central intelligent unit that connects the device abstraction layer, core service layer, application runtime environment layer, and business application layer. Its responsibilities are: to generate a global situational awareness through comprehensive data perception; to generate scheduling decisions autonomously or interactively based on this situational awareness; and to issue precise microgrid scheduling commands after security verification. This eliminates the need for manual or semi-automatic system status analysis, ultimately achieving the upgrade of the microgrid from automation to autonomous intelligence, while ensuring the entire decision-making process is safe and controllable.

[0081] The core layer of artificial intelligence will be described in detail in subsequent embodiments.

[0082] In summary, the microgrid operating system comprises a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The device abstraction layer connects to multiple heterogeneous physical devices and maps the device data of each heterogeneous device to standardized device data objects. This transforms hardware heterogeneity into unified device data objects, eliminating hardware heterogeneity and enabling plug-and-play functionality, ensuring that new devices can be connected without system downtime. This design reduces the complexity of integrating heterogeneous physical devices from code development to parameter configuration, significantly improving system integration efficiency. The core service layer registers each device data object, obtaining a device directory; and publishes each device data object to its corresponding storage path, decoupling data producers and consumers. This allows the system to connect new physical devices or deploy new business applications without downtime. The application runtime environment layer allocates independent runtime environments to each business application in the business application layer, ensuring the isolation of business logic. A failure of a single business application will not affect the core functions of the system. The business application layer calls the core service layer to obtain the storage path of the target heterogeneous physical device from the device catalog, and then retrieves the corresponding device data object based on the storage path. Each business application executes its business logic based on the device data object in an independent operating environment. The artificial intelligence core layer generates microgrid scheduling instructions and sends them to the corresponding heterogeneous physical devices to enable them to execute the instructions. By decoupling the microgrid operating system into a layered structure—device abstraction layer, core service layer, application runtime environment layer, business application layer, and artificial intelligence core layer—the shortcomings of existing technologies in terms of device compatibility and system scalability are resolved. When new energy storage devices are added to the park, it is not necessary to completely modify the energy management system code or shut down and restart, reducing maintenance costs and improving system availability. Moreover, the artificial intelligence core layer can automatically generate microgrid scheduling instructions without manually or semi-automatically parsing the system status and sending the instructions to the corresponding heterogeneous physical devices, thereby reducing microgrid scheduling latency.

[0083] refer to Figure 2 , Figure 2 A schematic diagram of the microgrid operating system provided in the embodiments of this application. Figure 2 In this embodiment, the core layer of artificial intelligence is described in detail.

[0084] In this embodiment, the core AI layer is the central intelligent unit that connects the device abstraction layer, core service layer, application runtime environment layer, and business application layer. Its responsibilities are: to generate a global situational awareness through comprehensive data perception; to generate scheduling decisions autonomously or interactively based on this situational awareness; and to issue precise instructions after security verification, ultimately achieving the upgrade of the microgrid from automation to autonomous intelligence, while ensuring the safety and controllability of decision-making throughout the entire process.

[0085] The core layer of artificial intelligence is used to generate microgrid status maps; based on the microgrid status maps, microgrid scheduling decisions are generated; based on the microgrid scheduling decisions, microgrid scheduling instructions are generated and sent to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

[0086] The core layer of artificial intelligence includes a multimodal perception and fusion module, a reasoning and decision-making module, and an instruction execution module.

[0087] The multimodal sensing and fusion module is used to call the core service layer to obtain data objects from various devices; receive external multi-source data sent by data terminals; and generate a microgrid status map based on the data objects from various devices and the external multi-source data. The external multi-source data refers to external data related to the operation of the microgrid.

[0088] In this embodiment, the registration module of the core service layer is invoked to obtain the storage path of each device data object, and then the data objects of each device under the storage path are obtained, such as photovoltaic active power, energy storage state of charge (SOC), and load power.

[0089] In this embodiment, the data received is external multi-source data sent by the data terminal, such as meteorological data, electricity market prices, video surveillance, and grid constraints.

[0090] In this embodiment, a lightweight fusion model is used to integrate and correlate data objects from various devices with external multi-source data to generate a unified microgrid status map. This is no longer an isolated numerical value, but a correlated scenario including device status, power balance, and external influencing factors, enabling a rapid understanding of the current operating status of the microgrid.

[0091] Among them, the lightweight fusion model is a lightweight data integration algorithm built into the multimodal sensing and fusion module of the microgrid operating system, optimized for real-time microgrid scenarios. It can efficiently process heterogeneous and scattered multi-source data, transforming the data into unified and interconnected information through low-computing-power logic.

[0092] The microgrid situation map is a visualized and interconnected scenario description generated by a lightweight fusion model, encompassing equipment status, power relationships, external influences, and potential risks. For example, it doesn't simply present a scenario with 200kW PV output, 60% SOC of energy storage, and 350kW load, but rather: 200kW PV output (decreased due to cloud cover) + 60% SOC of energy storage (available for discharge) + 350kW load (sudden increase of 150kW) + current peak electricity price period → system power deficit of 150kW, requiring dispatch to supplement it.

[0093] The reasoning and decision-making module is used to generate microgrid scheduling decisions based on the microgrid status map.

[0094] In this embodiment, the inference and decision-making module incorporates a lightweight domain-specific large model optimized for energy scenarios. Based on the microgrid situation map and preset high-level objectives (such as minimizing total operating cost), it generates or adjusts scheduling strategies in real time. These strategies include energy storage charging and discharging power regulation, adjustable load control, and grid-connected power optimization.

[0095] The instruction execution module is used to generate microgrid scheduling instructions based on microgrid scheduling decisions and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

[0096] In this embodiment, the microgrid scheduling decisions generated by the inference decision module are transformed into safe and compliant microgrid scheduling commands, such as discharging the energy storage converter at 300kW or reducing the central air conditioning power by 50kW. These commands are then sent to the corresponding heterogeneous physical devices, while ensuring the security and reusability of command execution.

[0097] In this embodiment, the microgrid dispatching instructions are compiled into control sequences that conform to the API standards of the data access service module in the core service layer, and then sent out through a secure channel.

[0098] In this embodiment, the reasoning and decision-making module is also used to parse the natural language instructions input by the operator and decompose the natural language instructions into an executable task chain; the instruction execution module is also used to generate microgrid scheduling instructions based on the executable task chain.

[0099] In this embodiment, the reasoning and decision-making module supports operators inputting natural language commands.

[0100] Specifically, operators input natural language commands through the microgrid operating system's interactive interface, without needing to adhere to a professional format. For example, a command could be: "Develop a minimum-cost dispatch plan to address the afternoon load peak from 2 PM to 4 PM." The reasoning and decision-making module parses the natural language commands, accurately understanding their core objectives, constraints, and timeframes. For instance, the parsing results for developing a minimum-cost dispatch plan to address the afternoon load peak from 2 PM show: the objective is the lowest electricity purchase cost, the scenario is the 2 PM to 4 PM load peak, and the core requirement is to fill the load gap.

[0101] In this embodiment, task chain decomposition is performed, breaking down abstract natural language instructions into standardized task chains that are executable by the system and arranged in a logical order. An example of the decomposed task chain result is shown below:

[0102] 1. Query load forecast data from 2 PM to 4 PM;

[0103] 2. Query current energy storage SOC and photovoltaic output forecast data;

[0104] 3. Calculate the power deficit during peak load periods;

[0105] 4. Generate a combined dispatch strategy of "energy storage discharge + adjustable load regulation";

[0106] 5. Define the control parameters for each physical device.

[0107] In this embodiment, the task chain is traversed, and each standardized task is converted into a corresponding microgrid scheduling command. For example, querying the current energy storage SOC is converted into a command to query the status of the energy storage converter, and discharging 300kW of energy storage is converted into a command to set the discharge power of the energy storage converter.

[0108] In this embodiment, the instruction execution module is also used to encapsulate the microgrid dispatch instructions and save the encapsulated microgrid dispatch instructions to the instruction encapsulation library.

[0109] In this embodiment, microgrid dispatch instructions are encapsulated into a unified format and saved to the instruction encapsulation library to form a reusable standard skill that can be directly called in subsequent similar scenarios without the need for repeated generation.

[0110] Optionally, the instruction encapsulation library includes control, query, and analysis instructions.

[0111] In this embodiment, the instruction execution module is also used to construct a microgrid digital twin model; based on the microgrid digital twin model, to deduce the deduction effect of the microgrid dispatch instruction; if the deduction effect matches the preset deduction effect, then the microgrid dispatch instruction is determined to be valid.

[0112] In this embodiment, the device data objects of all heterogeneous physical devices are obtained through the virtual device driver of the device abstraction layer to ensure that the device parameters in the microgrid digital twin model are consistent with the physical devices; the real-time network topology of the microgrid is obtained, including the device connection relationship of each heterogeneous physical device, system constraints such as grid connection protocol requirements, and external multi-source data to ensure that the microgrid digital twin model is synchronized with the operating scenario of the physical system, and is constructed using modeling tools.

[0113] In this embodiment, a microgrid digital twin model consistent with the physical microgrid is constructed. Microgrid dispatch commands are placed into the microgrid digital twin model for ultra-real-time simulation, such as simulating changes in system frequency, voltage, and equipment status over the next 5 minutes to verify the simulation effect. If the simulation result meets the preset simulation effect (such as system frequency stabilizing at a safe threshold, equipment operating without overload, and decision objectives being achieved), the command is deemed valid. If there are risks (such as frequency exceeding the standard or energy storage SOC being too low), the results are fed back to the inference and decision-making module for re-optimization.

[0114] For example, taking "responding to the combined event of a sudden drop in photovoltaic power and a sudden increase in load" as an example, we introduce the core layer of artificial intelligence:

[0115] The multimodal sensing and fusion module obtains information such as "photovoltaic output decreased by 200kW within 3 minutes" and "a large load suddenly started, increasing power by 150kW". It then integrates meteorological data to confirm cloud cover and queries market information to determine that it is currently in a peak electricity price period.

[0116] The reasoning and decision-making module analysis indicates a total power deficit of 350kW, and the grid is currently in a period of high electricity purchase prices. The decision objective is to minimize current electricity purchase costs and maintain stability. Microgrid dispatch instructions are generated: instructing the energy storage system to discharge at 300kW; adjusting the central air conditioning load to reduce it by 50kW; and maintaining the grid-connected power within ±10kW.

[0117] Based on real-time network topology and device status, a microgrid digital twin model is constructed, and the microgrid system status for the next 5 minutes is rapidly simulated within this model. The simulation results show that under this strategy, the system frequency and voltage are stable, and the energy storage SOC is within a safe range, thus the verification is successful. Commands are compiled and issued to the corresponding physical devices. Command 1 is sent to the energy storage PCS driver: setting the discharge power to 300kW; Command 2 is sent to the building management system driver: setting the air conditioning power to be reduced by 50kW; Command 3 is sent to the grid-connected controller driver: maintaining net power close to zero.

[0118] In this embodiment, the frequency curve and cost data after actual execution are fed back to the core layer of artificial intelligence. The reasoning and decision-making module compares the actual results with the results of the microgrid digital twin model, storing this data as experience data to optimize future decisions.

[0119] In summary, the core layer of artificial intelligence achieves a closed-loop process from comprehensive microgrid situational awareness and microgrid dispatch decision generation to the issuance and execution of microgrid dispatch commands. It automatically generates microgrid dispatch commands without requiring manual or semi-automatic system status analysis and sends these commands to corresponding heterogeneous physical devices. This enables these devices to execute the dispatch commands, driving the microgrid from passive automated operation to proactive, autonomous, and intelligent operation. This reduces dispatch latency and significantly lowers the cost of manual intervention and system operational risks, further reducing maintenance costs and improving system availability. Furthermore, before issuing dispatch commands, the process is simulated in a constructed microgrid digital twin model to prevent erroneous commands from damaging physical devices or causing system crashes, improving the accuracy of decision-making and execution. It eliminates the need for on-site testing on the physical system, reducing ineffective device actions and energy waste, and lowering trial-and-error costs and system losses.

[0120] The microgrid operating system described in this application enables a layered and decoupled architecture, successfully building an open ecosystem similar to a smartphone: the microgrid operating system is like iOS or Android, the virtual device driver is like the hardware driver, and the containerized applications are like various apps. Microgrid operators can manage the functions and capabilities of the microgrid flexibly and conveniently, just like managing a mobile app.

[0121] refer to Figure 3 , Figure 3 This is a flowchart illustrating the microgrid operation method provided in an embodiment of this application. The microgrid operation method is applied to a microgrid operating system, which includes: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer; such as... Figure 3 As shown, the method includes:

[0122] S301: Through the device abstraction layer, multiple heterogeneous physical devices are connected, and the device data of each heterogeneous physical device is mapped into standardized device data objects.

[0123] S302: Through the core service layer, register each device data object to obtain the device directory; and publish each device data object to the corresponding storage path; where the device directory allocates storage paths for each device data object.

[0124] S303: Through the application runtime environment layer, an independent runtime environment is allocated to each business application in the business application layer.

[0125] S304: Through the business application layer, the core service layer is called to obtain the storage path of the target heterogeneous physical device from the device directory, and the corresponding device data object is obtained according to the storage path; each business application executes business logic according to the device data object in an independent running environment.

[0126] S305: Through the core layer of artificial intelligence, microgrid dispatch instructions are generated and sent to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid dispatch instructions.

[0127] In summary, the microgrid operating system comprises a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The device abstraction layer connects to multiple heterogeneous physical devices and maps the device data of each heterogeneous device to standardized device data objects. This transforms hardware heterogeneity into unified device data objects, eliminating hardware heterogeneity and enabling plug-and-play functionality, ensuring that new devices can be connected without system downtime. This design reduces the complexity of integrating heterogeneous physical devices from code development to parameter configuration, significantly improving system integration efficiency. The core service layer registers each device data object, obtaining a device directory; and publishes each device data object to its corresponding storage path, decoupling data producers and consumers. This allows the system to connect new physical devices or deploy new business applications without downtime. The application runtime environment layer allocates independent runtime environments to each business application in the business application layer, ensuring the isolation of business logic. A failure of a single business application will not affect the core functions of the system. The business application layer calls the core service layer to obtain the storage path of the target heterogeneous physical device from the device catalog, and then retrieves the corresponding device data object based on the storage path. Each business application executes its business logic based on the device data object in an independent operating environment. The artificial intelligence core layer generates microgrid scheduling instructions and sends them to the corresponding heterogeneous physical devices to enable them to execute the instructions. By decoupling the microgrid operating system into a layered structure—device abstraction layer, core service layer, application runtime environment layer, business application layer, and artificial intelligence core layer—the shortcomings of existing technologies in terms of device compatibility and system scalability are resolved. When new energy storage devices are added to the park, it is not necessary to completely modify the energy management system code or shut down and restart, reducing maintenance costs and improving system availability. Moreover, the artificial intelligence core layer can automatically generate microgrid scheduling instructions without manually or semi-automatically parsing the system status and sending the instructions to the corresponding heterogeneous physical devices, thereby reducing microgrid scheduling latency.

[0128] Figure 4 This is a schematic diagram of the microgrid operating device provided in the embodiments of this application, as shown below. Figure 4 As shown, the microgrid operation device is applied to the microgrid operating system, which includes: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer. The microgrid operation device provided in this embodiment includes: an access module 401, a publishing module 402, an allocation module 403, an execution module 404, and a generation module 405.

[0129] The access module 401 is used to access multiple heterogeneous physical devices through the device abstraction layer and map the device data of each heterogeneous physical device into a standardized device data object.

[0130] The publishing module 402 is used to register each device data object through the core service layer to obtain the device directory; and to publish each device data object to the corresponding storage path; wherein the storage path is allocated for each device data object in the device directory.

[0131] The allocation module 403 is used to allocate an independent runtime environment to each business application in the business application layer through the application runtime environment layer.

[0132] Execution module 404 is used to call the core service layer through the business application layer to obtain the storage path of the target heterogeneous physical device from the device directory, and obtain the corresponding device data object according to the storage path; each business application executes business logic according to the device data object in an independent running environment.

[0133] The generation module 405 is used to generate microgrid scheduling instructions through the artificial intelligence core layer and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

[0134] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0135] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0136] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0137] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0138] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0139] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0140] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0141] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0142] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0143] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0144] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0147] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0148] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0149] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A microgrid operating system, characterized in that, include: Device abstraction layer, core service layer, application runtime environment layer, business application layer, and artificial intelligence core layer; The device abstraction layer is used to connect multiple heterogeneous physical devices and map the device data of each heterogeneous physical device into standardized device data objects. The core service layer is used to register each device data object to obtain a device directory; and to publish each device data object to its corresponding storage path. The device catalog assigns storage paths for each device data object; The application runtime environment layer is used to allocate an independent runtime environment for each business application in the business application layer. The business application layer is used to call the core service layer to obtain the storage path of the target heterogeneous physical device from the device directory, and obtain the corresponding device data object according to the storage path; each business application executes business logic according to the device data object in the independent running environment. The artificial intelligence core layer is used to generate microgrid scheduling instructions and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

2. The system according to claim 1, characterized in that, The device abstraction layer includes multiple virtual device drivers; each virtual device driver supports dynamic loading and hot-plugging. Accordingly, the device abstraction layer is used to access multiple heterogeneous physical devices and map the device data of each heterogeneous physical device into standardized device data objects, including: Each virtual device driver connects to a heterogeneous physical device and maps the device data of each heterogeneous physical device into standardized device data objects that conform to a unified information model.

3. The system according to claim 1, characterized in that, The core service layer includes a registration module and a unified data bus module; Accordingly, the core service layer is used to register each device data object to obtain a device catalog; And publish the data objects of each device to the corresponding storage path, including: The registration module is used to register each device data object to obtain a device directory; and to publish each device data object to the unified data bus module. The unified data bus module is used to publish the data objects of each device to the corresponding storage path.

4. The system according to claim 1, characterized in that, The core service layer includes a data access service module; Accordingly, the business application layer is used to call the core service layer to obtain the storage path of the target heterogeneous physical device from the device directory, and to obtain the corresponding device data object according to the storage path, including: The business application layer is used to call the data access service module to obtain the storage path of the target heterogeneous physical device from the device directory, and obtain the corresponding device data object according to the storage path.

5. The system according to claim 1, characterized in that, The core AI layer is used to generate microgrid scheduling instructions and send these instructions to corresponding heterogeneous physical devices, so that the heterogeneous physical devices execute the microgrid scheduling instructions, including: The core layer of artificial intelligence is used to generate a microgrid status map; generate a microgrid scheduling decision based on the microgrid status map; generate a microgrid scheduling instruction based on the microgrid scheduling decision; and send the microgrid scheduling instruction to the corresponding heterogeneous physical device so that the heterogeneous physical device executes the microgrid scheduling instruction.

6. The system according to claim 5, characterized in that, The core layer of artificial intelligence includes a multimodal perception and fusion module, a reasoning and decision-making module, and an instruction execution module; Accordingly, the core AI layer is used to generate a microgrid situation map; generate a microgrid scheduling decision based on the microgrid situation map; generate a microgrid scheduling instruction based on the microgrid scheduling decision, and send the microgrid scheduling instruction to the corresponding heterogeneous physical device so that the heterogeneous physical device executes the microgrid scheduling instruction, including: The multimodal sensing and fusion module is used to call the core service layer to obtain the data objects of each device; receive external multi-source data sent by the data terminal; and generate a microgrid status map based on the data objects of each device and the external multi-source data; wherein, the external multi-source data refers to external data related to the operation of the microgrid. The reasoning and decision-making module is used to generate microgrid scheduling decisions based on the microgrid situation map. The instruction execution module is used to generate microgrid scheduling instructions based on the microgrid scheduling decision, and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices execute the microgrid scheduling instructions.

7. The system according to claim 6, characterized in that, The reasoning and decision-making module is also used to parse the natural language instructions input by the operator and decompose the natural language instructions into an executable task chain; The instruction execution module is also used to generate microgrid scheduling instructions based on the executable task chain.

8. The system according to claim 6, characterized in that, The instruction execution module is also used to encapsulate the microgrid scheduling instructions and save the encapsulated microgrid scheduling instructions to the instruction encapsulation library.

9. The system according to claim 6, characterized in that, The instruction execution module is also used to construct a microgrid digital twin model; based on the microgrid digital twin model, to deduce the deduction effect of the microgrid dispatch instruction; if the deduction effect meets the preset deduction effect, then the microgrid dispatch instruction is determined to be valid.

10. A microgrid operation method, characterized in that, Applied to the microgrid operating system as described in claims 1-9, the microgrid operating system includes: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer; the method includes: Through the device abstraction layer, multiple heterogeneous physical devices are connected, and the device data of each heterogeneous physical device is mapped into a standardized device data object. The core service layer registers each device data object to obtain a device directory; and publishes each device data object to its corresponding storage path; wherein the device directory allocates a storage path for each device data object. The application runtime environment layer allocates an independent runtime environment to each business application in the business application layer. Through the business application layer, the core service layer is called to obtain the storage path of the target heterogeneous physical device from the device directory, and the corresponding device data object is obtained according to the storage path; each business application executes business logic according to the device data object in the independent running environment. The artificial intelligence core layer generates microgrid scheduling instructions and sends these instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

11. A microgrid operating device, characterized in that, The microgrid operating system described in claims 1-9 is applied, comprising: a device abstraction layer, a core service layer, an application runtime environment layer, a business application layer, and an artificial intelligence core layer; the device comprises: The access module is used to access multiple heterogeneous physical devices through the device abstraction layer and map the device data of each heterogeneous physical device into a standardized device data object; The publishing module is used to register each device data object through the core service layer to obtain a device directory; and to publish each device data object to the corresponding storage path; wherein the device directory allocates a storage path for each device data object; The allocation module is used to allocate an independent runtime environment to each business application in the business application layer through the application runtime environment layer; The execution module is used to call the core service layer through the business application layer, obtain the storage path of the target heterogeneous physical device from the device directory, and obtain the corresponding device data object according to the storage path; each business application executes business logic according to the device data object in the independent running environment. The generation module is used to generate microgrid scheduling instructions through the artificial intelligence core layer, and send the microgrid scheduling instructions to the corresponding heterogeneous physical devices so that the heterogeneous physical devices can execute the microgrid scheduling instructions.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the method of claim 10 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in claim 10.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method of claim 10.

Citation Information

Patent Citations

  • Cloud computing based micro power network power distribution method

    CN103426065A

  • Software architecture and hardware architecture for forming numerical control system

    CN113534744A

  • Island microgrid multi-mode switching strategy considering economic regulation based on double-Q learning

    CN114400704A

  • Situation knowledge graph construction method and system for power grid dispatching operation management

    CN115293507A

  • Low-code plug-and-play edge gateway configuration method, device, equipment and medium

    CN118524018A