Device control method, terminal device, and computer-readable storage medium

Abstract

The application is suitable for the technical field of control, and provides a device control method, a terminal device and a computer readable storage medium, comprising: acquiring a heterogeneous event data stream; wherein the heterogeneous event data stream comprises a plurality of control events with different structures, each control event corresponds to a device control task, and each control event carries an event type identifier; determining a verification template corresponding to each control event according to the event type identifier carried by each control event; performing integrity verification on each control event according to the verification template corresponding to each control event to obtain a first verification result corresponding to each control event; and generating a control instruction corresponding to each target event; wherein the target event is a control event whose first verification result indicates that the verification is passed. Through the above method, the reliability and operation and maintenance flexibility of a virtual power plant energy storage regulation system can be improved.

Description

Technical Field

[0001] This application belongs to the field of control technology, and in particular relates to a device control method, a terminal device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of virtual power plant technology, a large number of distributed energy storage devices, photovoltaics, and controllable loads are connected to the control system. The system needs to continuously receive various energy storage charging and discharging control, load regulation, and other equipment control tasks issued by external dispatch. The control events corresponding to different types of control tasks come from diverse sources and have different data structures, forming a massive heterogeneous event data stream. The system needs to conduct pre-verification of various control events to ensure the safe and orderly control of energy storage clusters and distributed resources.

[0003] Current virtual power plant energy storage control systems typically perform unified verification of various control events, which makes it difficult to adapt to diverse energy storage control services. This can easily lead to situations such as the misinterpretation of legitimate control commands and the issuance of incomplete or abnormal control commands to energy storage devices, causing control anomalies. Furthermore, when adding new energy storage devices or control services, the verification logic needs to be reconstructed, which is difficult to expand and makes it hard to support the business needs of large-scale and multi-type collaborative control of virtual power plant energy storage clusters. Summary of the Invention

[0004] This application provides a device control method, a terminal device, and a computer-readable storage medium, which can improve the reliability and operation and maintenance flexibility of a virtual power plant energy storage control system.

[0005] In a first aspect, embodiments of this application provide a device control method, including: Acquire heterogeneous event data streams; wherein, the heterogeneous event data streams include a variety of control events with different structures, each control event corresponds to a device control task, and each control event carries an event type identifier; The verification template corresponding to each control event is determined based on the event type identifier carried by each control event; Perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event; Generate control instructions corresponding to each target event; wherein, the target event is a control event whose first verification result indicates that the verification has passed; the control instructions corresponding to the target event are used to control the target device, and the target device is the device involved in the device control task corresponding to the target event.

[0006] In this embodiment, heterogeneous events with different structures can be dynamically matched with corresponding verification templates based on event type identifiers for verification. This overcomes the shortcomings of traditional solutions that uniformly verify heterogeneous events, leading to inaccurate verification and inability to adapt to multiple event types. It achieves standardized access and structured verification of various heterogeneous events, accurately identifies anomalies in each control event, effectively intercepts dirty data, ensures the stability and reliability of downstream event processing, and facilitates flexible expansion with new event types, improving the universality of heterogeneous event stream data governance and ease of operation and maintenance. Through this method, the reliability and operational flexibility of the virtual power plant energy storage control system can be improved.

[0007] In one possible implementation of the first aspect, determining the verification template corresponding to each control event based on the event type identifier carried by each control event includes: For each control event, the event type identifier carried by the control event is segmented into fields to obtain the identifier fields corresponding to each of the multiple event type levels; Based on the hierarchical order of the event type hierarchy, the identifier fields corresponding to each of the multiple event type hierarchies are identified sequentially to obtain the event type of the control event; The verification template corresponding to the control event is determined based on the event type of the control event.

[0008] In the above implementation, by segmenting the event type identifier carried by the control event into fields, the identifier fields corresponding to different event type levels are decomposed, and the fields are identified in hierarchical order to determine the event type. Then, the corresponding verification template is matched, which can realize the event category parsing from coarse to fine level, take into account the classification hierarchy logic, accurately distinguish similar events, and improve the accuracy and orderliness of event type identification.

[0009] In one possible implementation of the first aspect, generating the control instruction corresponding to each of the target events includes: The scheduling information carried by the target event is parsed; wherein, the scheduling information includes scheduling items corresponding to multiple execution stages generated according to the control task corresponding to the target event, and each scheduling item is used to describe the task that the target device needs to execute in one execution stage; For a scheduling item carrying a preset flag, the current operating status of the target device is obtained in the first stage; wherein, the first stage is the execution stage corresponding to the scheduling item carrying the preset flag. For scheduling items that do not carry a preset flag, control instructions for the target device are generated in the second stage based on the current operating condition of the target device; wherein, the second stage is the execution stage corresponding to the scheduling item that does not carry a preset flag; the time period corresponding to the first stage is before the time period corresponding to the second stage.

[0010] In the above implementation method, multiple scheduling items are carried by scheduling information, and flag bits are used to distinguish preparatory scheduling items. The preset time window corresponding to the preparatory action is set before the formal execution time period. This allows the equipment group's operating status to be obtained in advance and preparatory processing to be carried out. During the formal execution period, control commands are generated in combination with the real-time operating status of the equipment. This realizes the separation and arrangement of the preparatory process and the formal scheduling sequence, and allows for the early investigation and supplementation of equipment operating conditions, reducing the risk of failure and communication time during the formal execution phase. This ensures that each equipment group can execute segmented scheduling sub-tasks on time and stably, and improves the reliability of scheduling execution.

[0011] In one possible implementation of the first aspect, the generation of control commands for the target device based on the current operating condition of the target device in the second stage includes: Analyze the control parameters carried by the target event; The target operating condition of the target equipment is calculated based on the control parameters and the current operating condition of the target equipment. The control commands for the target device are generated based on the target operating conditions of the target device.

[0012] In the above implementation method, the control parameters carried by the target event are parsed and the target operating condition of the controlled equipment is calculated in combination with the real-time current operating condition of the controlled equipment. Based on the target operating condition, the equipment control command is generated. This realizes the linkage verification and calculation between the parameters of the upper-level control event and the actual operating state of the equipment, avoids issuing unreasonable commands out of the real-time operating condition of the equipment, can dynamically adjust the control target according to the current state of the equipment, improves the rationality and security of the control command, and ensures the stable and reliable execution of the equipment control task.

[0013] In one possible implementation of the first aspect, the control parameters carried by the target event include total power; The step of calculating the target operating condition of the target equipment based on the control parameters and the current operating condition of the target equipment includes: Based on the total power and the current operating condition of each target device, calculate the total available energy and the available energy of each target device. The total power is allocated based on the available energy and the available energy of each target device to obtain the target power for each target device; The target operating conditions of each target device are calculated based on the target power and current operating conditions of each target device.

[0014] In the above implementation method, dynamic power allocation is achieved based on the available energy of the equipment, and energy storage resources are used in a balanced manner under the premise of meeting the scheduling target, taking into account both system scheduling needs and power supply margin, thereby improving the operational safety of the energy storage system and the rationality of power utilization.

[0015] In one possible implementation of the first aspect, acquiring the heterogeneous event data stream includes: Receive multiple control requests issued by the scheduling platform; wherein each control request corresponds to a device control task; Perform a security verification on each of the control requests to obtain a second verification result for each of the control requests; Each target request is standardized and encapsulated to obtain the control event corresponding to each target request; wherein, the target request is the control request that passes the verification as indicated by the second verification result; Add each of the aforementioned control events to the message queue; The heterogeneous event data stream is retrieved from the message queue on demand.

[0016] In the above implementation, multiple device control requests issued by the scheduling platform are received first, and compliant requests are pre-screened through security verification. This can intercept illegal control requests in advance and reduce the overhead of handling invalid tasks. Standardized encapsulation shields the format differences of external requests, which helps improve system compatibility. In addition, relying on message queues to realize asynchronous on-demand data consumption, this synchronous reception and asynchronous processing method can improve the processing efficiency of system task scheduling.

[0017] In one possible implementation of the first aspect, after generating the control command corresponding to each target event, the method further includes: The control command is sent to the target device; After detecting the response information sent by the target device, the real-time operating parameters of the target device are obtained; The effectiveness of the target device in executing the control commands is verified based on the real-time operating parameters of the target device.

[0018] In the above implementation method, a closed-loop feedback verification mechanism is constructed after the instruction is issued. It does not rely solely on the instantaneous response of the equipment, but verifies the execution effect of the instruction in combination with the actual operating status; thereby improving the reliability of system control execution, fault detection capability and operational safety.

[0019] In one possible implementation of the first aspect, issuing the control command to the target device includes: If the target device corresponds to multiple control commands, then control commands are issued to the target device according to the priority of the control commands.

[0020] The above implementation introduces a hierarchical priority strategy and a command conflict arbitration mechanism to prevent multiple scheduling commands from acting on the same device simultaneously and causing operational disorder; thus ensuring the stable operation of energy storage equipment and the orderly execution of scheduling instructions.

[0021] Secondly, embodiments of this application provide a device control apparatus, including: An acquisition unit is used to acquire heterogeneous event data streams; wherein, the heterogeneous event data streams include a variety of control events with different structures, each control event corresponds to a device control task, and each control event carries an event type identifier; The determining unit is used to determine the verification template corresponding to each control event based on the event type identifier carried by each control event; The verification unit is used to perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event. A generation unit is used to generate control instructions corresponding to each target event; wherein, the target event is a control event that has passed the first verification result; the control instructions corresponding to the target event are used to control the target device, and the target device is the device involved in the device control task corresponding to the target event.

[0022] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the device control method as described in any one of the first aspects above.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device control method as described in any one of the first aspects above.

[0024] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the device control method described in any one of the first aspects.

[0025] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the architecture of the virtual power plant system provided in the embodiments of this application; Figure 2 This is a schematic flowchart of the device control method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the device control process provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a device control apparatus provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0028] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0029] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0030] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0032] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0033] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0034] With the rapid development of virtual power plant technology, a large number of distributed energy storage devices, photovoltaics, and controllable loads are connected to the control system. The system needs to continuously receive various energy storage charging and discharging control, load regulation, and other equipment control tasks issued by external dispatch. The control events corresponding to different types of control tasks come from diverse sources and have different data structures, forming a massive heterogeneous event data stream. The system needs to conduct pre-verification of various control events to ensure the safe and orderly control of energy storage clusters and distributed resources.

[0035] Current virtual power plant energy storage control systems typically perform unified verification of various control events, which makes it difficult to adapt to diverse energy storage control services. This can easily lead to situations such as the misinterpretation of legitimate control commands and the issuance of incomplete or abnormal control commands to energy storage devices, causing control anomalies. Furthermore, when adding new energy storage devices or control services, the verification logic needs to be reconstructed, which is difficult to expand and makes it hard to support the business needs of large-scale and multi-type collaborative control of virtual power plant energy storage clusters.

[0036] Based on this, this application provides a device control method. In this embodiment, heterogeneous events with different structures can be dynamically matched with corresponding verification templates based on event type identifiers for verification. This overcomes the shortcomings of traditional solutions that uniformly verify heterogeneous events, leading to inaccurate verification and inability to adapt to multiple event types. It achieves standardized access and structured verification of various heterogeneous events, accurately identifies abnormal situations in each control event, effectively intercepts dirty data, ensures the stability and reliability of downstream event processing flows, and facilitates flexible expansion with new event types, improving the universality of heterogeneous event stream data governance and ease of operation and maintenance. Through this method, the reliability and operational flexibility of the virtual power plant energy storage control system can be improved.

[0037] See Figure 1 This is a schematic diagram of the architecture of a virtual power plant system provided in an embodiment of this application. As an example and not a limitation, the architecture of the virtual power plant system includes a dispatching platform 11, a control system 12, and an energy storage system 13. The energy storage system 13 may include multiple energy storage devices.

[0038] The scheduling platform 11 is responsible for generating the scheduling plan for the energy storage system 13. For example, the scheduling platform 11 can be a virtual power plant (VPP) platform, which can generate scheduling plans (Events), decompose the scheduling plans into scheduling commands (Commands) for specific devices, and send them to the energy storage system 13 via Webhook event push.

[0039] In related technologies, the scheduling platform 11 typically interfaces directly with the energy storage system 13. In this approach, due to protocol differences between the scheduling platform 11 and the energy storage system 13, communication between them may be disrupted, often requiring adaptive adjustments to either the scheduling platform 11 or the energy storage system 13. This significantly increases the complexity of operation and maintenance, especially when scheduling platforms need to be deployed for multiple energy storage systems.

[0040] In this embodiment, a control system 12 is added between the dispatching platform 11 and the energy storage system 13. The control system 12 is used to execute the equipment control method described in the following embodiments, thereby realizing adaptive bridging between the dispatching platform 11 and the energy storage system 13, effectively improving the flexibility of the virtual power plant system and reducing the complexity of system operation and maintenance.

[0041] See Figure 2 This is a flowchart illustrating the device control method provided in an embodiment of this application. It is understood that... Figure 2 The device control method in the embodiment can be provided by Figure 1 The control system 12 shown is executed. As an example and not a limitation, the method may include the following steps: S201, Obtain heterogeneous event data stream.

[0042] The heterogeneous event data stream includes control events with different structures. Each control event corresponds to a device control task, and each control event carries an event type identifier.

[0043] For example, taking the VPP platform as an example, the VPP platform pushes Webhook events; correspondingly, the control system receives the Webhook events, and each Webhook event corresponds to a control event. The message body of the Webhook event can include an `event_type` field, which serves as the event type identifier.

[0044] In one embodiment, S201 includes: Receive multiple control requests issued by the scheduling platform; each control request corresponds to a device control task. Perform a security check on each control request to obtain a second check result for each control request; Each target request is standardized and encapsulated to obtain the control event corresponding to each target request; where the target request is the control request that passes the second verification result. Add each control event to the message queue; Retrieve heterogeneous event data streams from the message queue on demand.

[0045] Continuing the example above, the control system receives Webhook events pushed by the VPP platform, and each Webhook event is recorded as a control request. This embodiment introduces a message queue between the Webhook receiver and the command processing end, constructing a synchronous reception-asynchronous consumption bridge architecture. Specifically, it can include the following three stages: Phase 1, Synchronous Reception 1. Receive HTTPS POST requests (i.e., control requests) from the VPP platform.

[0046] 2. Extract three security fields from the HTTP Header (the message header for the control request): webhook-id (message identifier), webhook-timestamp (timestamp), and webhook-signature (signature value).

[0047] 3. Perform HMAC-SHA256 signature verification: The string to be signed is: {webhook-id}.{webhook-timestamp}.{request_body}; Key processing involves removing the whsec_ prefix from the shared key and then performing Base64 decoding to obtain the original key bytes. The signature is calculated using the HMAC-SHA256 algorithm, and then Base64 encoded and compared with the signature value in the message header.

[0048] 4. Execute timestamp anti-replay verification: |Server current time - message timestamp| ≤ 300 seconds.

[0049] 5. After successful verification, return a response message (such as HTTP 204 (No Content)) to the VPP platform to ensure that the VPP platform does not time out while waiting for a response.

[0050] Phase Two: Message Encapsulation and Queuing The validated Webhook message body is encapsulated into a standard message envelope and added to the message queue. For example: { "type": "FlipEvents", / / Message type identifier "inQueueTime": 1687350000, / / Enqueue timestamp "timezone": "America / Los_Angeles", / / Time zone information (adapts to multiple time zones in North America) "data": "{Original Webhook Body}" / / Pass-through of raw data } Phase 3, Asynchronous Batch Consumption Consumers (such as command processors) pull messages from the message queue in batch mode, obtaining a heterogeneous event data stream. The amount of data pulled can be configured according to requirements.

[0051] Optionally, an acknowledgment (ACK) mechanism can be used. The ACK mechanism includes automatic ACK and manual ACK. Automatic ACK means that when a message is successfully sent to the consumer, consumption is automatically marked as complete, and the message is deleted immediately. Manual ACK means that when a message is successfully sent to the consumer, it is retained and marked and deleted as needed. For example, manual ACK can be used to confirm the completion of all message processing. If an exception occurs during processing, the message will not be acknowledged, and RabbitMQ will automatically redeliver it to ensure that no instructions are lost.

[0052] In the above implementation, multiple device control requests issued by the scheduling platform are received first, and compliant requests are pre-screened through security verification. This can intercept illegal control requests in advance and reduce the overhead of handling invalid tasks. Standardized encapsulation shields the format differences of external requests, which helps improve system compatibility. In addition, relying on message queues to realize asynchronous on-demand data consumption, this synchronous reception and asynchronous processing method can improve the processing efficiency of system task scheduling.

[0053] S202, determine the verification template corresponding to each control event based on the event type identifier carried by each control event.

[0054] In one embodiment, S202 includes: For each control event, the event type identifier carried by the control event is segmented into fields to obtain the identifier fields corresponding to multiple event type levels; Based on the hierarchical order of event types, the corresponding identifier fields of multiple event type levels are identified sequentially to obtain the event type controlling the event; The corresponding validation template for the control event is determined based on the event type of the control event.

[0055] Continuing with the example of pushing Webhook events on the VPP platform, the Webhook message body can include an `event_type` field, which serves as the event type identifier. For example, the `event_type` field can include `event.created`, `event.canceled`, `command.created`, `command.started`, `command.ended`, `command.canceled`, `command.updated`, and `enrollment.updated`. This field includes a separator "·". The part before the separator represents the event, and the part after the separator represents the specific action under that event. The event type identifier can be segmented based on this separator; for example, the part before the separator can be one identifier field (event), and the part after the separator can be another identifier field (action).

[0056] It's understandable that the event and action identifier fields belong to different event type levels, with the event type level above the action type level. The order of the event type levels can be top-down, such as event first, then action.

[0057] For example, see Table 1, which is a list of identification fields provided in the embodiments of this application.

[0058] Table 1

[0059] As shown in Table 1, for example, if a control event has the event type identifier "event.created", the segmented identifier fields include the event "event" and the action field "created". Following the hierarchical order of event types, the event type of this control event can be identified as VPP scheduling plan creation. Similarly, if a control event has the event type identifier "command.created", the segmented identifier fields include the event "command" and the action field "created". Following the hierarchical order of event types, the event type of this control event can be identified as scheduling command generated. Therefore, although the action fields of the two control events are the same (both are "created"), because their event fields are different, following the hierarchical order of event types allows us to identify that the two control events correspond to different event types.

[0060] Optionally, a set of required fields can be predefined for each event type, and this set of required fields serves as the validation template.

[0061] For example, you can predefine a set of required fields for each event type based on the event fields, such as: The required fields for the Command type are: {id, event_id, device_id, starts_at, ends_at, duration_s, is_preparatory_action, battery_commands, status, device_status, created_at, updated_at}.

[0062] The required fields for the Event type are: {id, program_id, site_id, starts_at, ends_at, duration_s, schedule, status, is_participating, created_at, updated_at}.

[0063] Enrollment type required field set: {id, device_ids, site_id, program_id,enroll_method, status, status_reason, enrolled_at, unenrolled_at, program_specific_attributes, has_agreed_to_terms_and_conditions, terms_and_conditions_version}.

[0064] Of course, you can also predefine a set of required fields for each event type, such as: The required fields for VPP scheduler creation (event.created) are: {id, event_id, device_id, starts_at, ends_at, duration_s, is_preparatory_action, battery_commands, status, device_status, created_at, updated_at}.

[0065] The required fields for VPP schedule cancellation (event.canceled) are: {id, event_id, device_id, status, device_status, canceled_at}.

[0066] In the above implementation, by segmenting the event type identifier carried by the control event into fields, the identifier fields corresponding to different event type levels are decomposed, and the fields are identified in hierarchical order to determine the event type. Then, the corresponding verification template is matched, which can realize the event category parsing from coarse to fine level, take into account the classification hierarchy logic, accurately distinguish similar events, and improve the accuracy and orderliness of event type identification.

[0067] S203, perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event.

[0068] As shown in example S202, integrity checks can be performed on control events using a set of required fields. Messages that fail the check are marked as malformed messages, logged, but not processed further to prevent malicious data injection.

[0069] S204 generates control instructions corresponding to each target event.

[0070] In this context, the target event is the control event whose first verification result indicates that the verification has passed. The control command corresponding to the target event is used to control the target device, which is the device involved in the device control task corresponding to the target event. It can be understood that different target events can correspond to different target devices. Each target event can correspond to one or more target devices.

[0071] In the embodiments described in S201-S204, heterogeneous events with different structures can be dynamically matched with corresponding verification templates based on event type identifiers for verification. This overcomes the shortcomings of traditional solutions that uniformly verify heterogeneous events, leading to inaccurate verification and inability to adapt to multiple event types. It achieves standardized access and structured verification of various heterogeneous events, accurately identifies abnormal situations in each control event, effectively intercepts dirty data, ensures the stability and reliability of downstream event processing flows, and facilitates flexible expansion with new event types, improving the universality of heterogeneous event stream data governance and ease of operation and maintenance. Through the above method, the reliability and operational flexibility of the virtual power plant energy storage control system can be improved.

[0072] In one embodiment, S204 includes: Parse the scheduling information carried by the target event; the scheduling information includes scheduling items corresponding to multiple execution stages generated according to the control task corresponding to the target event, and each scheduling item describes the task that the target device needs to execute in an execution stage; For scheduling items carrying preset flags, the current operating status of the target device is obtained in the first stage; wherein, the first stage is the execution stage corresponding to the scheduling item carrying the preset flags; For scheduling items that do not carry a preset flag, control commands for the target device are generated in the second stage based on the current operating condition of the target device; the second stage is the execution stage corresponding to the scheduling items that do not carry a preset flag. The time period corresponding to the first stage is before the time period corresponding to the second stage.

[0073] For example, the scheduling information includes a schedule array, where each schedule element (scheduling item) defines a task for a time period (execution phase), and each schedule element carries an is_preparatory_action flag. Here, is_preparatory_action=true (preset flag) indicates the preparatory phase, while is_preparatory_action=false or empty indicates the non-preparatory phase (no preset flag).

[0074] Optionally, for scheduling items carrying preset flags, the online status of the target device can be polled during the first stage; the current SOC of the target device can be read to verify whether it meets the minimum power requirements of the subsequent execution stage; if the SOC is insufficient, pre-charging can be started during the preparation stage; and a communication connection channel can be pre-established to reduce communication delays during the execution stage.

[0075] Optionally, different device groups can be specified for different execution phases, with each device group including at least one target device. In this way, at each execution phase, the device group corresponding to that execution phase is instructed to perform the task corresponding to that execution phase.

[0076] In the above implementation method, multiple scheduling items are carried by scheduling information, and flag bits are used to distinguish preparatory scheduling items. The preset time window corresponding to the preparatory action is set before the formal execution time period. This allows the equipment group's operating status to be obtained in advance and preparatory processing to be carried out. During the formal execution period, control commands are generated in combination with the real-time operating status of the equipment. This realizes the separation and arrangement of the preparatory process and the formal scheduling sequence, and allows for the early investigation and supplementation of equipment operating conditions, reducing the risk of failure and communication time during the formal execution phase. This ensures that each equipment group can execute segmented scheduling sub-tasks on time and stably, and improves the reliability of scheduling execution.

[0077] In some implementations, the step of generating control commands for the target device in the second stage may include: Parse the control parameters carried by the target event; Calculate the target operating condition of the target equipment based on the control parameters and the current operating condition of the target equipment; Generate control commands for the target device based on the target device's target operating conditions.

[0078] Understandably, the purpose of the above steps is to translate the control requests from the dispatching platform into control commands that the energy storage system can recognize.

[0079] Optionally, a plurality of control modes can be divided according to the types of control parameters, and a translation template is set for each control mode; the corresponding translation template is determined according to the value of the control parameter carried by the target event to obtain a target template; the target working condition of the target device is calculated according to the target template, the value of the control parameter carried by the target event and the current working condition of the target device.

[0080] Taking the command.started event as an example, the control parameters carried by this event include working mode (charging or discharging), power mode (fixed-point power or load following), target power value, backup power percentage and whether power drawing from the power grid is allowed. According to these control parameters, three modes can be divided: Mode A is discharging-load following, Mode B is discharging-fixed-point power, and Mode C is charging-fixed-point power. The translation processes of the three modes are as follows.

[0081] Mode A: Discharging - Load Following Translation steps: 1. Read the current load power P_load of the target device; 2. Obtain the current state of charge SOC_current of the battery of the target device; 3. Calculate the schedulable power upper limit: P_max = (SOC_current - backup_reserve_percentage) × Battery_capacity / duration_s; 4. Calculate the actual discharge power: P_actual = min(P_load, P_max, setpoint_w); 5. If the ratio of P_actual to P_load is lower than the threshold (e.g., 80%), return a partial response to the VPP platform; 6. Encode P_actual into the discharge power register value of the target device to obtain the control instruction for the target device.

[0082] Mode B: Discharging - Fixed-point Power (DISCHARGE + SETPOINT) Translation steps: 1. Obtain the current state of charge SOC_current of the battery of the target device; 2. Calculate the sustainable discharge time of the target device: T_sustain = (SOC_current - backup_reserve_percentage) × Battery_capacity / setpoint_w; 3. If T_sustain<duration_s (command duration), derate the actual power: P_actual =(SOC_current - backup_reserve_percentage) × Battery_capacity / duration_s; 4. Set the target device to a constant power discharge mode, where the power setpoint = P_actual.

[0083] 5. If enable_grid_import = false, generate a prohibition command, which is used to prohibit the device from supplementing power from the power grid.

[0084] Wherein, the control instructions for the target device include the power setpoint and the prohibition command.

[0085] Mode C: Charging-Setpoint Power (CHARGE + SETPOINT) Translation steps: 1. Obtain the current state of charge SOC_current of the target battery; 2. Calculate the time required to charge to full capacity: T_charge = (100% - SOC_current) × Battery_capacity / setpoint_w; 3. Set the target device to a constant power charging mode, where the power setpoint = setpoint_w; 4. If enable_grid_import = true, generate an enable command, which is used to allow power drawing from the power grid for charging.

[0086] Wherein, the control instructions for the target device include the power setpoint and the enable command.

[0087] In the above implementation, by parsing the control parameters carried in the target event, and calculating the target working condition of the device in combination with the real-time current working condition of the controlled device, the device control instruction is generated based on the target working condition; linkage check and calculation between the parameters of the upper-layer control event and the actual operating state of the device are realized, unreasonable instructions issued without considering the real-time working condition of the device are avoided, the control target can be dynamically adjusted according to the current state of the device, the rationality and safety of the control instruction are improved, and the stable and reliable execution of the device control task is guaranteed.

[0088] Optionally, the control parameters carried in the target event include total power. In this case, power distribution is required among a plurality of energy storage devices in the energy storage system.

[0089] Correspondingly, the step of calculating the target working condition may include: Calculate the total available energy and the available energy of each target device based on the total power and the current operating condition of each target device. The total power is allocated based on the available energy and the available energy of each target device to obtain the target power for each target device; The target operating conditions for each target device are calculated based on its target power and current operating conditions.

[0090] For example, the power allocation steps include: 1. Iterate through all registered and online devices in the energy storage system, and for each device i, read: current SOC_i, battery capacity C_i, and maximum rated power P_rated_i; 2. Calculate the available energy for each device: E_avail_i = (SOC_i - backup_reserve_i) × C_i. If SOC_i ≤ backup_reserve_i, then the device will not participate in this scheduling. 3. Calculate the total available energy of the site: E_total = Σ(E_avail_i), i = 1..N; 4. Calculate the initial power allocation based on the percentage of available energy: P_alloc_i = min(P_site × E_avail_i / E_total, P_rated_i); where, E_avail_i = max(0, (SOC_i - backup_reserve_i) ×C_i); E_total = Σ E_avail_i (i = 1..N); 5. Limiting process: If P_alloc_i > P_rated_i, then the power of device i is limited to P_rated_i, and the remaining power ΔP = P_alloc_i - P_rated_i is redistributed to the remaining unlimited devices in the same proportion; The remaining power after limiting is redistributed according to the following formula: ΔP = Σ (P_alloc_i - P_rated_i) / / Remaining amount of all clipped devices; P_alloc_j += ΔP × E_avail_j / Σ E_avail_j / / j is the unlimited device; 6. Iterative convergence: Repeat step 5 until the power of all devices is within the limit or all devices are limited. Iterate a maximum of N times to ensure convergence.

[0091] The implementation method for calculating the target operating condition of each target device based on the target power and current operating condition of each target device can be found in the translation process shown in the above embodiments. For example, the target power of the target device is the target power value in the control parameters carried by the target event.

[0092] In the above implementation method, dynamic power allocation is achieved based on the available energy of the equipment, and energy storage resources are used in a balanced manner under the premise of meeting the scheduling target, taking into account both system scheduling needs and power supply margin, thereby improving the operational safety of the energy storage system and the rationality of power utilization.

[0093] In some embodiments, after S204, the method further includes: Send control commands to the target device; After detecting the response information sent by the target device, the real-time operating parameters of the target device are obtained; Verify the target device's execution effect on control commands based on the target device's real-time operating parameters.

[0094] In one example, the verification process may include the following steps: Step 1: Issue control commands.

[0095] Step 2: Check the device's immediate response code (code == 0 indicates success).

[0096] Step 3: If the response is successful, start the verification timer (e.g., wait for T_verify = 2 seconds, device execution delay).

[0097] Step 4: Obtain the real-time operating parameters of the device and verify them.

[0098] For example, verification includes, but is not limited to: reading the current operating mode: verifying whether it is consistent with the issued mode; reading the current power setting value: verifying that |actual value - issued value| ≤ ε (tolerance, such as ±5%); reading the current SOC: verifying whether the trend of change is in line with expectations (the SOC should decrease during discharge).

[0099] Step 5: Verification result determination.

[0100] For example, if all operations pass, the instruction is marked as successfully executed and the execution log is recorded; if some operations fail, the retry process begins; if the device does not respond, the device is marked as offline and an alarm is triggered.

[0101] Optionally, the retry process may include: re-issuing the same command; waiting for T_verify and then verifying again; if it still fails after R_max retries, then record the exception log (device SN, command ID, reason for failure), report the device's abnormal status (device_status = "failed") to the VPP platform, mark the device as unavailable, and no longer allocate power to it in subsequent scheduling.

[0102] Optionally, the number of retries can be set, such as a maximum of 3 retries. If the retries still fail after reaching the maximum number, an exception log (device SN, command ID, reason for failure) is recorded, and the device's abnormal status (device_status = "failed") is reported to the VPP platform. The device is marked as unavailable, and no power will be allocated to it in subsequent scheduling.

[0103] In the above implementation method, a closed-loop feedback verification mechanism is constructed after the instruction is issued. It does not rely solely on the instantaneous response of the equipment, but verifies the execution effect of the instruction in combination with the actual operating status; thereby improving the reliability of system control execution, fault detection capability and operational safety.

[0104] In one implementation, the steps of issuing control commands to the target device include: if the target device corresponds to multiple control commands, then issuing control commands to the target device according to the priority of the control commands.

[0105] Optionally, arbitration strategies can be set based on priority.

[0106] For example, the arbitration strategy could be a preemption mechanism, specifically, when the priority of a new command is greater than the priority of the currently executing command: 1. First, send a "Stop current charging / discharging" command to the device; 2. After the equipment confirms it has stopped, issue the translated instruction for the new command; 3. Record the preemption log (preempted command ID, new command ID, timestamp); 4. Preempted commands are marked as "preempted".

[0107] For example, the arbitration strategy can be a queuing mechanism, specifically, when the priority of the new command is less than or equal to the priority of the current command: 1. Add the new command to the device's waiting queue; 2. After the current command ends (command.ended) or is preempted, the next command in the queue is executed in order of priority.

[0108] For example, when receiving a parameter update instruction, the arbitration strategy can be: 1. If the parameters are updated for the same command (same command ID), the control command will be regenerated based on the new parameters; 2. If the power setpoint changes beyond the threshold (e.g., change > 20%), a power ramp transition is adopted: the power change is gradually adjusted in M ​​steps (e.g., M = 5 steps, with an interval of 1 second between each step) to avoid the impact of sudden power changes on the power grid.

[0109] Optionally, a real-time status table can be maintained for each energy storage device in the energy storage system. This real-time status table can record at least one of the following: currently executing command ID, command priority, current device mode, power setting value, and execution start time.

[0110] In this way, all command operations (issuing, updating, canceling, preempting) must first update the status table before operating the device to ensure status consistency.

[0111] The above implementation introduces a hierarchical priority strategy and a command conflict arbitration mechanism to prevent multiple scheduling commands from acting on the same device simultaneously and causing operational disorder; thus ensuring the stable operation of energy storage equipment and the orderly execution of scheduling instructions.

[0112] One implementation method can employ a read-write separation communication approach. Specifically, the real-time operating status of the device is obtained through the read channel, while control commands are sent to the device through the write channel.

[0113] For example, a dual-channel gRPC architecture with read / write separation is designed as follows: Read Channel (RpcService): Used for real-time acquisition of device status parameters. service RpcService { rpc deviceOp (GrpcRequest) returns (GrpcReply) {} }message GrpcRequest { string sn = 1; / / Device serial number (routing identifier) string param = 2; / / Read parameter names (e.g., SOC, load power, online status) string val = 3; / / Parameter value (can be empty during read operations) } Write channel (RpcWriteService): Used to send device control commands. service RpcWriteService { rpc deviceOp (GrpcWriteRequest) returns (GrpcReply) {} }message GrpcWriteRequest { string sn = 1; / / Device serial number (routing identifier) string cid = 2; / / Control command ID (command tracing identifier) string key = 3; / / Control parameter key (e.g., "charge_mode", "power_setpoint") string val = 4; / / Control parameter value } Unified response format: message GrpcReply { int32 code = 1; / / Response code (0 = success, non-zero = error code) string msg = 2; / / Response message (human-readable description) string result = 3; / / Response data (JSON format, returned parameter value for read operation) } Through a read-write separation communication method, the two channels establish independent connections without blocking each other. In addition, the read channel is a stateless operation, which can poll and collect real-time data such as device SOC and load at high concurrency. The write channel is a stateful operation, which requires ensuring the orderliness and idempotency of instructions.

[0114] See Figure 3 This is a schematic diagram of the device control flow provided in an embodiment of this application. It is intended as an example and not a limitation. Figure 3 As shown, the equipment control process may include the following steps: S301 synchronously receives control requests from the scheduling platform and consumes them asynchronously.

[0115] The implementation method of step S301 can be found in the description of synchronous reception-asynchronous consumption in embodiment S201, and will not be repeated here.

[0116] S302, determine the verification template corresponding to each control event based on the event type identifier carried by each control event.

[0117] S303, perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event.

[0118] S304 generates control instructions corresponding to each target event.

[0119] S302-S304 are the same as S202-S204, and can be found in the description of the embodiments of S202-S204, which will not be repeated here.

[0120] Send control commands to the target devices in the energy storage system. Optionally, in the case of a read-write separated dual-channel communication method, control commands can be sent to the target devices in the energy storage system through the write channel.

[0121] Optionally, if the target device corresponds to multiple control commands, the control commands are sent to the target device according to the priority of the control commands.

[0122] S305: Obtain the real-time operating parameters of the target device in the energy storage system, and verify the execution effect of the target device on the control command based on the real-time operating parameters of the target device.

[0123] If the verification passes, the process ends. If the verification fails, the control command is reissued.

[0124] The implementation method for verifying the execution effect can be found in the description of the execution effect verification process in the above embodiments, and will not be repeated here.

[0125] Optionally, when using a read-write separation dual-channel communication method, the real-time operating parameters of the target device in the energy storage system can be obtained through the read channel.

[0126] The method in this application embodiment can dynamically match the corresponding verification template for heterogeneous events with different structures based on the event type identifier to carry out verification. This overcomes the shortcomings of traditional solutions that uniformly verify heterogeneous events, resulting in inaccurate verification and inability to adapt to multiple types of events. It enables standardized access and structured verification of various heterogeneous events, accurately identifies abnormal situations of each control event, effectively intercepts dirty data, ensures the stability and reliability of downstream event processing, and facilitates flexible expansion of new event types, thereby improving the universality of heterogeneous event stream data governance and the convenience of operation and maintenance.

[0127] In addition, by receiving multiple device control requests from the external scheduling platform in advance and performing security checks to screen out compliant requests, illegal control requests can be intercepted in advance, reducing the overhead of processing invalid tasks. Standardized encapsulation shields the differences in the format of external requests, which helps improve system compatibility. Furthermore, by relying on message queues to achieve asynchronous on-demand data consumption, this synchronous reception and asynchronous processing method can improve the processing efficiency of system task scheduling.

[0128] Furthermore, a closed-loop feedback verification mechanism is constructed after the command is issued, which does not rely solely on the instantaneous response of the equipment, but verifies the execution effect of the command in combination with the actual operating status; thereby improving the reliability of system control execution, fault detection capability and operational safety.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply the 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.

[0130] Corresponding to the device control method described in the above embodiments, Figure 4 This is a structural block diagram of the device control apparatus provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0131] Reference Figure 4 The device 4 includes: Acquisition unit 41 is used to acquire heterogeneous event data streams; wherein, the heterogeneous event data streams include a variety of control events with different structures, each control event corresponds to a device control task, and each control event carries an event type identifier.

[0132] The determining unit 42 is used to determine the verification template corresponding to each control event based on the event type identifier carried by each control event.

[0133] The verification unit 43 is used to perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event.

[0134] The generation unit 44 is used to generate control instructions corresponding to each target event; wherein, the target event is a control event in which the first verification result indicates that the verification has passed; the control instructions corresponding to the target event are used to control the target device, and the target device is the device involved in the device control task corresponding to the target event.

[0135] Optionally, the determining unit 42 is also used for: For each control event, the event type identifier carried by the control event is segmented into fields to obtain the identifier fields corresponding to each of the multiple event type levels; Based on the hierarchical order of the event type hierarchy, the identifier fields corresponding to each of the multiple event type hierarchies are identified sequentially to obtain the event type of the control event; The verification template corresponding to the control event is determined based on the event type of the control event.

[0136] Optionally, the generating unit 44 is also used for: The scheduling information carried by the target event is parsed; wherein, the scheduling information includes scheduling items corresponding to multiple execution stages generated according to the control task corresponding to the target event, and each scheduling item is used to describe the task that the target device needs to execute in one execution stage; For a scheduling item carrying a preset flag, the current operating status of the target device is obtained in the first stage; wherein, the first stage is the execution stage corresponding to the scheduling item carrying the preset flag. For scheduling items that do not carry a preset flag, control instructions for the target device are generated in the second stage based on the current operating condition of the target device; wherein, the second stage is the execution stage corresponding to the scheduling item that does not carry a preset flag; the time period corresponding to the first stage is before the time period corresponding to the second stage.

[0137] Optionally, the generating unit 44 is also used for: Analyze the control parameters carried by the target event; The target operating condition of the target equipment is calculated based on the control parameters and the current operating condition of the target equipment. The control commands for the target device are generated based on the target operating conditions of the target device.

[0138] Optionally, the generating unit 44 is also used for: Based on the total power and the current operating condition of each target device, calculate the total available energy and the available energy of each target device. The total power is allocated based on the available energy and the available energy of each target device to obtain the target power for each target device; The target operating conditions of each target device are calculated based on the target power and current operating conditions of each target device.

[0139] Optionally, the acquisition unit 41 is also used for: Receive multiple control requests issued by the scheduling platform; wherein each control request corresponds to a device control task; Perform a security verification on each of the control requests to obtain a second verification result for each of the control requests; Each target request is standardized and encapsulated to obtain the control event corresponding to each target request; wherein, the target request is the control request that passes the verification as indicated by the second verification result; Add each of the aforementioned control events to the message queue; The heterogeneous event data stream is retrieved from the message queue on demand.

[0140] Optionally, device 4 also includes: The control unit 45 is used to send the control command to the target device; after monitoring the response information sent by the target device, it acquires the real-time operating parameters of the target device; and verifies the execution effect of the target device on the control command based on the real-time operating parameters of the target device.

[0141] Optionally, the control unit 45 is also used for: If the target device corresponds to multiple control commands, then control commands are issued to the target device according to the priority of the control commands.

[0142] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0143] in addition, Figure 4 The device control unit shown can be a software unit, hardware unit, or a combination of software and hardware built into an existing terminal device, or it can be integrated into the terminal device as an independent component, or it can exist as an independent terminal device.

[0144] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0145] Figure 5 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 5 As shown, the terminal device 5 in this embodiment includes: at least one processor 50 ( Figure 5 (Only one is shown in the diagram) a processor, a memory 51, and a computer program 52 stored in the memory 51 and executable on the at least one processor 50, wherein the processor 50 executes the computer program 52 to implement the steps in any of the above-described device control method embodiments.

[0146] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. This terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 5 This is merely an example of terminal device 5 and does not constitute a limitation on terminal device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0147] The processor 50 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0148] In some embodiments, the memory 51 may be an internal storage unit of the terminal device 5, such as a hard disk or memory of the terminal device 5. In other embodiments, the memory 51 may be an external storage device of the terminal device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal device 5. Furthermore, the memory 51 may include both internal and external storage units of the terminal device 5. The memory 51 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0149] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the above-described method embodiments.

[0150] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments.

[0151] If the integrated unit 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

[0153] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0154] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and 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 displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0156] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A device control method, characterized in that, include: Acquire heterogeneous event data streams; wherein, the heterogeneous event data streams include various control events with different structures, each control event corresponds to a device control task, and each control event carries an event type identifier; The verification template corresponding to each control event is determined based on the event type identifier carried by each control event; Perform integrity verification on each control event according to the verification template corresponding to each control event, and obtain the first verification result corresponding to each control event; Generate control instructions corresponding to each target event; wherein, the target event is a control event whose first verification result indicates that the verification has passed; the control instructions corresponding to the target event are used to control the target device, and the target device is the device involved in the device control task corresponding to the target event.

2. The equipment control method as described in claim 1, characterized in that, The step of determining the verification template corresponding to each control event based on the event type identifier carried by each control event includes: For each control event, the event type identifier carried by the control event is segmented into fields to obtain the identifier fields corresponding to each of the multiple event type levels; Based on the hierarchical order of the event type hierarchy, the identifier fields corresponding to each of the multiple event type hierarchies are identified sequentially to obtain the event type of the control event; The verification template corresponding to the control event is determined based on the event type of the control event.

3. The equipment control method as described in claim 1, characterized in that, The generation of control instructions corresponding to each target event includes: The scheduling information carried by the target event is parsed; wherein, the scheduling information includes scheduling items corresponding to multiple execution stages generated according to the control task corresponding to the target event, and each scheduling item is used to describe the task that the target device needs to execute in one execution stage; For a scheduling item carrying a preset flag, the current operating status of the target device is obtained in the first stage; wherein, the first stage is the execution stage corresponding to the scheduling item carrying the preset flag. For scheduling items that do not carry a preset flag, control instructions for the target device are generated in the second stage based on the current operating condition of the target device; wherein, the second stage is the execution stage corresponding to the scheduling item that does not carry a preset flag; the time period corresponding to the first stage is before the time period corresponding to the second stage.

4. The equipment control method as described in claim 3, characterized in that, The generation of control commands for the target device based on its current operating condition during the second stage includes: Analyze the control parameters carried by the target event; The target operating condition of the target equipment is calculated based on the control parameters and the current operating condition of the target equipment. The control commands for the target device are generated based on the target operating conditions of the target device.

5. The equipment control method as described in claim 4, characterized in that, The control parameters carried by the target event include total power; The step of calculating the target operating condition of the target equipment based on the control parameters and the current operating condition of the target equipment includes: Based on the total power and the current operating condition of each target device, calculate the total available energy and the available energy of each target device. The total power is allocated based on the available energy and the available energy of each target device to obtain the target power for each target device; The target operating conditions of each target device are calculated based on the target power and current operating conditions of each target device.

6. The equipment control method as described in claim 1, characterized in that, The acquisition of heterogeneous event data streams includes: Receive multiple control requests issued by the scheduling platform; wherein each control request corresponds to a device control task; Perform a security verification on each of the control requests to obtain a second verification result for each of the control requests; Each target request is standardized and encapsulated to obtain the control event corresponding to each target request; wherein, the target request is the control request that passes the verification as indicated by the second verification result; Add each of the aforementioned control events to the message queue; The heterogeneous event data stream is retrieved from the message queue on demand.

7. The equipment control method as described in claim 1, characterized in that, After generating the control command corresponding to each target event, the method further includes: The control command is sent to the target device; After detecting the response information sent by the target device, the real-time operating parameters of the target device are obtained; The effectiveness of the target device in executing the control commands is verified based on the real-time operating parameters of the target device.

8. The equipment control method as described in claim 7, characterized in that, Sending the control command to the target device includes: If the target device corresponds to multiple control commands, then control commands are issued to the target device according to the priority of the control commands.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images