A user-side customized acquisition strategy configuration method and system

Abstract

The application discloses a user-side customized collection strategy configuration method and system, relates to the technical field of power utilization information collection, and generates user demand parameters based on a structured demand template of a client; performs compliance auditing, collection terminal capability adaptability auditing and power grid load evaluation auditing through pre-verified user demand parameters; for the user demand parameters that pass the auditing, default collection strategy templates determined according to user types are used to generate temporary strategy parameters, a main station constructs temporary strategy objects according to the temporary strategy parameters, and a message is sent to a collection terminal through an application layer protocol to complete customized collection strategy configuration. According to the application, after a user submits a demand, a system can automatically extract core parameters into a subsequent processing flow without manual translation, three auditing processes are automatically completed, subjective bias and omission risks of manual auditing are eliminated, and a configuration cycle is greatly shortened from when a user submits a demand to when a terminal executes a temporary strategy.

Description

Technical Field

[0001] This invention relates to the technical field of electricity consumption information collection, and in particular to a user-side customized collection strategy configuration method and system. Background Technology

[0002] The electricity consumption information collection system is a core support for the intelligent management of the power system. Through the collaborative work of collection terminals and the master station system, it achieves full collection, real-time monitoring, and precise control of electricity consumption data from various types of electricity users (residential, industrial and commercial, photovoltaic, energy storage, etc.), providing data support for electricity billing, grid operation monitoring, and coordinated control of power generation, grid, load, and energy storage. The collection strategy, as the core configuration of the collection system, directly determines the frequency, scope, timeliness, and completeness of data collection, and is crucial to ensuring the stable operation and efficient service of the power system.

[0003] However, the existing unified fixed configuration technology of the master station adopts a "one-size-fits-all" approach, with the same policies for users of the same type, which cannot meet the temporary and personalized data needs of users. At the same time, whether the policy adjustment is compliant, whether the terminal supports it, and whether the power grid is overloaded all depend on manual judgment, lacking a systematic automatic review mechanism. Furthermore, the conversion from user needs to terminal executable policy parameters depends on manual completion, resulting in low configuration efficiency. Summary of the Invention

[0004] The purpose of this section is to outline some aspects of embodiments of the present invention and to briefly describe some preferred embodiments. Simplifications or omissions may be made in this section, as well as in the abstract and title of this application, to avoid obscuring the purpose of these documents; however, such simplifications or omissions should not be construed as limiting the scope of the invention.

[0005] To address the technical problems of lack of compliance review and low efficiency in existing technologies that rely on unified fixed configurations for the main station and manual configuration through manual applications, this invention provides a user-side customized data acquisition strategy configuration method and system. The invention provides the following technical solution: A user-side customized data acquisition strategy configuration method, used to configure temporary policy data objects for power data acquisition terminals, including the following steps: Users generate user requirement parameters based on the structured requirement template on the client side. The user requirement parameters include: target collection frequency, data item list, effective start time and effective duration parameters; the main station receives the user requirement message and performs pre-verification on the user requirement parameters. Compliance audits, data acquisition terminal capability compatibility audits, and power grid load assessment audits are performed using pre-verified user requirement parameters. The compliance review includes: frequency compliance, data item compliance, and time period compliance; the terminal capability adaptability review includes: the review fails when the target acquisition frequency exceeds the maximum supported frequency, the data item list does not belong to the supported data item list, or the estimated data volume calculated for the effective duration exceeds the storage capacity; the power grid load assessment includes: calculating the new load based on the user demand, and if the sum of the current load rate and the new load exceeds the safety threshold, the review fails. For the approved user requirements parameters, a default collection strategy template is determined based on the user type. Then, the system merges and generates temporary strategy parameters. The main station constructs a temporary strategy object based on the temporary strategy parameters and sends a message to the collection terminal through the application layer protocol to complete the customized collection strategy configuration.

[0006] As a preferred embodiment of the user-side customized acquisition strategy configuration method and system described in this invention, the message structure adopted by the application layer protocol includes: a message header field with a fixed identifier, a version number field for identifying the version information of the current protocol, a message type field for distinguishing operation types, a strategy number field for carrying the strategy data object, a strategy parameter field for carrying all information of the temporary strategy data object, and a checksum field for verifying whether data errors or loss have occurred during the transmission of the message when the acquisition terminal receives it.

[0007] As a preferred embodiment of the user-side customized data collection strategy configuration method and system described in this invention, the pre-verification verification rules include: The target acquisition frequency belongs to the preset discrete set {60, 300, 900, 1800, 3600}, in seconds, and is not lower than the default acquisition frequency for this user type; each item in the list of data items to be acquired by the user belongs to the preset data item dictionary; the effective duration of the policy is between 1 and 72 hours; the effective start time of the temporary policy must not be earlier than the current time and must not be later than the current time + 72 hours; if the pre-verification fails, the main station will immediately return an error code and a specific error description.

[0008] As a preferred embodiment of the user-side customized data collection strategy configuration method and system described in this invention, the design for calculating the new load based on the user requirements is as follows: ; in, To estimate the new load, The amount of data reported per instance corresponds to the user's needs. The target acquisition frequency; according to Calculation and evaluation ; If L evalIf L is less than the preset safety threshold, the review is approved; if L eval If the load exceeds the preset safety threshold, the main site calculates the recommended time period: shifting the demand period to the off-peak or low-peak period and pushing the load rate to the user along with the rejection notification.

[0009] As a preferred embodiment of the user-side customized data collection strategy configuration method and system described in this invention, the structured requirement template is a structured requirement data object, and the data structure of the structured requirement data object is defined as follows: The `user_id` field, a string, stores a unique user identifier; the `demand_type` field, an enumeration, identifies the demand type, with possible values ​​including frequency adjustment, adding data items, and time period customization; the `freq_target` field, an integer, specifies the target collection frequency, with values ​​in GB / T seconds; the `data_items` field, a string array, lists the data items the user needs to collect; the `time_start` field, a date and time, indicates the start time of the temporary policy; the `duration` field, an integer, represents the effective duration of the policy; the `push_format` field, an enumeration, specifies the push format of the collected data, with possible values ​​of Excel or JSON; the `push_addr` field, a string, specifies the target address for data push, which can be an email address, a Uniform Resource Locator (URL), or a cloud drive path; and the `attach_file` field, a binary field, is used to attach a requirement specification file. The default data collection strategy template is a structured data object containing the following fields: default frequency base_freq, default data item list base_items, default reporting period base_period, and default push format base_push_format.

[0010] As a preferred embodiment of the user-side customized data collection strategy configuration method and system described in this invention, the user requirement parameters are used to determine a default data collection strategy template based on the user type, and then a temporary strategy parameter is generated through fusion. Determine whether the user has submitted the freq_target field: if submitted, use the freq_target field as the sampling frequency of the temporary policy; if not submitted, read the base_freq from the default sampling policy template corresponding to the user type as the sampling frequency. Take the union of base_items in the default collection strategy template and data_items submitted by the user, and perform deduplication to obtain the data item list for the temporary strategy; Determine whether the user has submitted the time_start and duration fields: if submitted, set the reporting period to start from the time_start and last for the duration of the duration field; if not submitted, take the base_period in the default collection strategy template as the reporting period. Determine whether the user has submitted the push_format field: if submitted, use the push_format as the push format; if not submitted, use the base_push_format in the default collection strategy template as the push format. The push address is directly taken from the push_addr submitted by the user.

[0011] As a preferred embodiment of the user-side customized acquisition strategy configuration method and system described in this invention, the internal maintenance strategy storage area of ​​the acquisition terminal is divided into three areas: a default strategy area, which stores the default acquisition strategy issued by the factory or the main station and is read-only; a temporary strategy area, which is a read-write storage area used to store temporary strategies that have been received but have not yet taken effect or are taking effect; and a strategy status register, which stores the current strategy status, including three states: default strategy in effect, temporary strategy pending effect, and temporary strategy in effect. After receiving the message, the acquisition terminal performs the following processing steps: Calculate the CRC16 checksum for the received message and compare it with the checksum field carried in the message; if they do not match, discard the message and return a checksum failure response to the master station. After successful verification, the JSON string is read from the policy parameter field of the message, deserialized, and the complete temporary policy data object is restored. Extract policy parameters from the temporary policy data object; Copy the currently stored default acquisition policy from the default policy area of ​​the acquisition terminal to the temporary backup area; Write the parsed policy parameters into the temporary policy area of ​​the acquisition terminal; Marking the policy status register as a temporary policy pending activation indicates that the temporary policy is ready and waiting to be activated before switching to execution. A successful delivery confirmation message is sent back to the main station, including the policy number and the current status of the data acquisition terminal; When the temporary policy reaches its specified effective time, the internal timer of the acquisition terminal triggers a policy switching interrupt and performs the following operations based on the current situation: Stop the currently executing data acquisition task; The acquisition task is reinitialized based on the policy parameters stored in the temporary policy area, including setting the acquisition frequency timer to the value of the current temporary policy acquisition frequency, configuring the data item channel selection to all data items contained in the items field, and configuring the reporting period filter to the time window limited by the period field. Start a new data collection task; update the policy status register to a temporary policy pending effect. Report the successful policy switch status to the main station, including the policy number and the switch timestamp.

[0012] As a preferred embodiment of the user-side customized data collection strategy configuration method and system described in this invention, an exception handling mechanism and a timer-based automatic strategy recovery mechanism are designed. The exception handling mechanism continuously monitors the following abnormal situations during the execution of the temporary strategy at the data collection terminal: if three consecutive data collections are not completed within the expected time, it is determined to be a data collection abnormality; storage overflow: if the storage area utilization rate exceeds 90%, it is determined to be a storage abnormality; communication interruption: if communication with the main station is interrupted for more than 5 minutes, it is determined to be a communication abnormality. If any of the above anomalies occur, the data acquisition terminal shall perform the following operations: Immediately stop the current temporary strategy's data collection task execution; Read the default policy parameters from the temporary backup area; reinitialize the data collection task to the default configuration; Update the policy status register to the default policy and make it effective; encapsulate the exception information into an alarm message and report it to the main station. The exception information includes the exception type, the timestamp of occurrence, and the policy number of the current temporary policy. After receiving the alarm, the main site pushes an anomaly notification to the user through the APP; The timer-based automatic policy recovery mechanism registers a scheduled task in the expiration monitoring queue for each issued temporary policy at the main station. The core parameter of the scheduled task is expire_time = start_time + duration. When the time expires, the scheduled task is triggered, and the main station performs the following operations: Retrieve complete information about the temporary policy from the database; construct a policy recovery message containing the policy number and recovery command; send it to the corresponding acquisition terminal via the communication link; update the status field of the policy in the database to indicate that it has expired; When the acquisition terminal receives a temporary policy, in addition to writing the policy parameters, it also registers an expiration timer task in the local timer module, with the trigger time also being expire_time. The acquisition terminal will trigger policy recovery in the following two situations: upon receiving a recovery command from the master station, it executes recovery immediately after parsing the command; the local timer expires: if no recovery command is received from the master station by the expiration time, recovery is automatically triggered. The recovery operation process is as follows: stop the current temporary policy acquisition task; read the default policy parameters from the backup area; reinitialize the acquisition task to the default configuration; update the policy status register to show that the default policy is in effect; report the recovery success status to the master station. The exception handling mechanism and the timer-based automatic recovery mechanism operate independently of each other; when the exception recovery condition and the expiration recovery condition are met at the same time, the exception recovery is executed first to ensure terminal security.

[0013] This invention also discloses a user-side customized data collection strategy configuration system, which is applied to the above-mentioned user-side customized data collection strategy configuration method. The system includes the following modules: The user requirement acquisition module generates user requirement parameters based on the client's structured requirement template. These parameters include: target acquisition frequency, data item list, effective start time, and effective duration. The main station receives user requirement messages and pre-verifies the user requirement parameters. The main station intelligent review module performs compliance review, acquisition terminal capability compatibility review, and power grid load assessment review on the pre-verified user requirement parameters. The temporary policy generation module determines the default acquisition policy template based on the user type for the approved user requirement parameters and generates temporary policy parameters. The main station constructs a temporary policy object based on the temporary policy parameters. The policy distribution module distributes messages to the acquisition terminals via application layer protocols.

[0014] As a preferred embodiment of the user-side customized collection strategy configuration system of the present invention, the system comprises: a terminal execution module for executing the strategy after the collection terminal receives a message; an automatic recovery module for executing a timer-based automatic policy recovery mechanism; and a data push module for pushing temporary policies in Excel and JSON output formats.

[0015] The beneficial effects of this invention are as follows: This invention, through the design of a user-side customized data acquisition strategy configuration method and system, can be deployed on existing power data acquisition terminals and master station servers. After applying this method and system, users submitting requirements no longer require manual translation; the system can automatically extract core parameters for subsequent processing. With this system, all three review processes are fully automated, eliminating the subjective bias and omission risks of manual review. From user submission of requirements to terminal execution of temporary strategies, the entire process requires no manual input of strategy parameters, significantly shortening the configuration cycle. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a schematic diagram of a user-side customized data collection strategy configuration method proposed in this invention; Figure 2 This is a schematic diagram of a user-side customized data acquisition strategy configuration system framework proposed in this invention; Figure 3 This is a flowchart illustrating a preferred embodiment of a user-side customized data collection strategy configuration method proposed in this invention. Detailed Implementation

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0018] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0019] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0020] Example 1 Reference Figure 1 As an embodiment of the present invention, a user-side customized data acquisition strategy configuration method is provided. This method is used to configure temporary strategy data objects of power acquisition terminals, and includes the following steps: S1: The user generates user requirement parameters based on the structured requirement template on the client. The user requirement parameters include: target collection frequency, data item list, effective start time and effective duration parameters; the main station receives the user requirement message and pre-verifies the user requirement parameters.

[0021] Specifically: A standardized requirement template is embedded in the system's interaction entry point (e.g., web interface, mobile app / mini-program). This template is essentially a structured requirement data object, and the data structure of the structured requirement data object is defined as follows: The user_id field, a string type, is used to store the user's unique identifier (electricity user number). The `demand_type` field, an enumeration type, identifies the demand type. Optional values ​​include frequency adjustment, adding new data items, and time period customization. The `freq_target` field, an integer type, specifies the target collection frequency. Its value is in GB seconds and must belong to the preset discrete value set {60, 300, 900, 1800, 3600}. The `data_items` field, a string array type, lists the data items the user needs to collect, and each item in this list must belong to the main site system's preset data item dictionary. The `time_start` field, a date and time type, indicates the start time of the temporary policy's effectiveness. The `duration` field, an integer type, represents the effective duration of the policy, ranging from 1 to 72 hours. The `push_format` field, an enumeration type, specifies the push format of the collected data, with options of Excel or JSON. The `push_addr` field, a string type, specifies the target address for data push, which can be an email address, a Uniform Resource Locator (URL), or a cloud drive path. Finally, the `attach_file` field, a binary type (optional), is used to attach a requirement specification file, whose file size cannot exceed 10 megabytes.

[0022] After the user fills in their requirements on the front-end interface, the front-end encapsulates the form data into a JSON-formatted requirement message according to the corresponding data structure mentioned above, and uploads it to the main site's requirement receiving interface via the HTTPS protocol.

[0023] After receiving the request message, the main station first performs a pre-validation of the parameters. The validation rules are as follows: (1) freq_target (target acquisition frequency) must belong to the preset discrete set {60, 300, 900, 1800, 3600} (unit: seconds) and not be lower than the default acquisition frequency of this user type (read from the user profile); (2) Each item in data_items (the list of data items to be collected by the user) must belong to the preset data item dictionary (this dictionary is pre-installed in the main station system and contains standardized data item codes such as positive active energy, reverse active energy, voltage, current, power factor, power generation, and load fluctuation value). (3) The duration value (the effective duration of the strategy) must be between 1 and 72 hours; (4) The time_start (the start time of the temporary policy) must not be earlier than the current time and must not be later than the current time + 72 hours.

[0024] If the pre-verification fails, the main station will immediately return an error code and a specific error description (such as "the collection frequency of 60 seconds is lower than the default minimum frequency of 300 seconds for this user type"), and the request process will terminate; if the pre-verification passes, the request message will enter the subsequent S2 review queue.

[0025] S2: Compliance review, data acquisition terminal capability compatibility review, and power grid load assessment review are performed based on pre-verified user requirement parameters. The compliance review includes frequency compliance, data item compliance, and time period compliance. The data acquisition terminal capability compatibility review includes failures if the target acquisition frequency exceeds the maximum supported frequency, the data item list does not belong to the supported data item list, or the estimated data volume calculated for the effective duration exceeds the storage capacity. The power grid load assessment includes calculating the new load based on user requirements; if the sum of the current load rate and the new load exceeds a safety threshold, the review fails. Specifically: I. Compliance Audit: Automated verification based on a rule engine; compliance audits are implemented using a rule engine. The main site has a pre-built compliance rule base, and each rule adopts a "condition-conclusion" format (e.g., IF freq_target<60 THEN reject("The collection frequency must not be less than 60 seconds")). The rule base contains the following three types of rules, each assigned a corresponding rule number: Rule No. 1, Frequency Compliance: Specifies the minimum sampling frequency allowed for various user types (e.g., residential users ≥ 900 seconds, industrial and commercial users ≥ 300 seconds, photovoltaic users ≥ 60 seconds). Number 2, Data Item Compliance Rules: This section specifies the prohibited data items to be collected (such as user identity information, geographical location, etc.), as well as the whitelist of data items that are allowed to be collected for each user type. Rule No. 3, Time Period Compliance: The reporting time period shall not exceed the data transmission window allowed by the power grid (e.g., 0:00-6:00 per day is the system maintenance window, during which new reporting tasks are prohibited).

[0026] The review engine matches and calculates the user's requirements parameters with the rule base. If all rules return "pass", the review will proceed to the next stage. If any rule triggers "rejection", the rejection rule number and the preset rejection reason template will be recorded, and a rejection notification will be generated and pushed to the user.

[0027] II. Verification of the compatibility of data acquisition terminals: based on parameter matching algorithms in the data acquisition terminal profiles; First, a maintenance database for data acquisition terminals is set up within the main site. Each data acquisition terminal file in the database contains the following fields: The `terminal_id` field, a string type, is used to uniquely identify the data acquisition terminal; the `terminal_model` field, a string type, is used to identify the model name of the data acquisition terminal (e.g., "2022 Concentrator" or "New Smart Integrated Data Acquisition Terminal for Distribution Areas"); the `max_freq` field, an integer type, is used to indicate the maximum acquisition frequency supported by the data acquisition terminal, in seconds; and the `storage_capacity` field, an integer type, is used to indicate the data storage capacity of the data acquisition terminal, in gigabytes (GB). The `supported_items` field, a string array, is used to enumerate the list of all data items supported by the acquisition terminal; and the `comm_bandwidth` field, an integer, represents the communication bandwidth of the acquisition terminal, in kilobits per second (kbps).

[0028] During the review process, the main site retrieves the user's bound terminal_id from the user profile based on the user_id, and then reads the hardware parameters of the acquisition terminal from the acquisition terminal database. Then, it performs the following matching calculation: 1. If freq_target > max_freq, then it is judged as failing (the acquisition terminal cannot support higher frequencies); 2. If any item in data_items does not belong to supported_items, the result will be deemed as failing (the data collection terminal does not support the collection of that data item). 3. If the estimated data volume (a function of freq_target, number of data_items, and duration) exceeds storage_capacity, it will be considered as failing.

[0029] If the compatibility fails, the system will recommend the optimal combination of parameters that can be supported based on the parameters of the data acquisition terminal (e.g., "The maximum data acquisition frequency supported by this data acquisition terminal is 300 seconds. It is recommended to adjust the data acquisition frequency to 300 seconds") and push it to the user along with the rejection notification.

[0030] III. Power Grid Load Assessment: Overload Risk Calculation Based on Regional Load Model; The core of power grid load assessment is to calculate the load increment of user demand on the regional data acquisition terminal cluster and determine whether it exceeds the safety threshold. The main station maintains the regional load model, dividing the data acquisition terminals into several regional clusters according to administrative divisions or transformer areas. Each regional cluster records the following dynamic data: the number of currently online data acquisition terminals N; the current reporting frequency f of each data acquisition terminal. i (seconds); Data volume d reported by each acquisition terminal in a single batch i (KB); Total bandwidth of regional communication network B total (kbps); Current regional load factor L curr(%).

[0031] When user demand enters the load assessment phase, the system calculates and estimates the additional load. : ; in, The amount of data reported per instance corresponding to user needs (determined by the number and type of data items). B is the target acquisition frequency. total The total bandwidth of the regional communication network is calculated by the system based on the sum of the communication bandwidth fields of all online terminals in the region, or it can be preset by the system administrator.

[0032] Then, based on the estimated additional load... Calculation and evaluation ; If L eval ≤ 30% (preset safety threshold), approval approved; if L eval If the load rate is >30%, the system will calculate the recommended time period (the load rate after shifting the demand period to the off-peak or low-peak period) and push it to the user along with the rejection notification; After all three levels of review are passed, the main site will encapsulate the review results (including all parameters that have been approved) into a review approval message and send it to the strategy generation module through the message queue. At the same time, it will notify the user via SMS / APP push. After receiving the review approval message, the strategy generation module will read the user type from the user profile based on the user_id and then load the corresponding default collection strategy template from the strategy library. S3: For approved user requirement parameters, a default collection strategy template is determined based on the user type, and a fusion process is executed to generate temporary strategy parameters. The main site then constructs a temporary strategy object based on these temporary strategy parameters. Specifically: The main site's policy library stores default data collection policy templates for each user type. Each template is a structured data object containing the following fields: base_freq (default frequency), base_items (default data item list), base_period (default reporting period), and base_push_format (default push format). After approval, these templates are merged with the default data collection policy templates determined based on the user type to generate temporary policy parameters. Collection Frequency: Determine if the user has submitted the `freq_target` field: If submitted, `freq_target` is used as the collection frequency for the temporary strategy; if not submitted, `base_freq` from the default collection strategy template corresponding to the user type is used as the collection frequency. Data Item List: Take the union of `base_items` from the default collection strategy template and the user-submitted `data_items`, and perform deduplication to obtain the data item list for the temporary strategy. Reporting Period: Determine if the user has submitted the `time_start` and `duration` fields: If submitted, the reporting period is set to the time interval starting from `time_start` and lasting for `duration`; if not submitted, `base_period` from the default collection strategy template is used as the reporting period. Push Format: Determine if the user has submitted the `push_format` field: If submitted, `push_format` is used as the push format; if not submitted, `base_push_format` from the default collection strategy template is used as the push format. Push Address: Directly use the user-submitted `push_addr` as the push address.

[0033] After the above fusion is completed, a complete temporary policy data object is generated. The temporary policy data object is the core data carrier of policy information in this invention. Its functions include: (1) serving as a structured record for persistent storage, used for subsequent status tracking, expiration monitoring and historical tracing; (2) serving as the data source for policy issuance. In the policy issuance process, the object will be serialized into a JSON string and filled into the "policy parameter" field of the custom application layer protocol, and transmitted to the target acquisition terminal via the communication link; (3) serving as the basis for parsing and restoring policy parameters on the acquisition terminal side. After receiving the message, the acquisition terminal deserializes the data object from the "policy parameter" field and configures the acquisition task accordingly.

[0034] Temporary policy data objects need to include the following: 1. Policy number, a string type, serving as a unique identifier for the policy, automatically generated in the format of "User Type-Requirement Type-Date-Serial Number" (e.g., PV-COLLECT-2024052001); 2. Associated user ID (identity), a string type, used to associate the user who initiated the requirement; 3. The associated user's corresponding data collection terminal ID, a string type, used to associate the target data collection terminal to which the policy was issued; 4. Merged policy parameters; 5. Status, an enumeration type representing the policy status, with possible values ​​including INIT (initialized), DEPLOYED (issued), ACTIVE (in execution), and EXPIRED (expired). Policy creation timestamp, policy effectiveness timestamp, and policy expiration timestamp.

[0035] S4: The main station uses a custom application layer protocol to send temporary policy objects to the collection terminals.

[0036] Specifically, the custom application layer protocol used between the master station and the data acquisition terminal adopts a message structure with a fixed header and a variable-length body, as follows: The message header field, 4 bytes long, is a fixed identifier 0x504F4C49 (i.e., the ASCII character "POLI"), used by the acquisition terminal to identify the message's start position and protocol type; the version number field, 2 bytes long, is used to identify the current protocol version information to ensure compatibility during subsequent protocol upgrades; the message type field, 1 byte long, is used to identify the message's operation type, where 0x01 indicates a policy issuance command, 0x02 indicates a policy recovery command, and 0x03 indicates a status query command; the policy number field, 32 bytes long, is a string type used to carry the policy_id field value from the temporary policy data object to identify the specific policy associated with the current message; the policy parameter field, variable length, contains the string generated after JSON serialization of the temporary policy data object, meaning the complete information of the entire data object is carried in this field; the checksum field, 2 bytes long, is a CRC16 checksum value used by the acquisition terminal to verify whether data errors or loss occurred during message transmission.

[0037] In the above protocol, the policy parameter field carries all the information of the temporary policy data object and is the payload of the protocol; the other fields are protocol control information to help the acquisition terminal correctly receive, identify and verify the payload.

[0038] Furthermore, in this invention, the internal maintenance policy storage area of ​​the acquisition terminal is divided into three areas: a default policy area, which stores the default acquisition policy issued by the factory or the main station and is read-only; a temporary policy area, which is a read-write storage area used to store temporary policies that have been received but have not yet taken effect or are taking effect; and a policy status register, which stores the current policy status, including three states: DEFAULT (default policy is in effect), TEMP_PENDING (temporary policy is pending effect), and TEMP_ACTIVE (temporary policy is in effect).

[0039] After receiving the transmitted message, the acquisition terminal performs the following processing steps: Step 1, Verification: Calculate the CRC16 checksum of the received message and compare it with the checksum field carried in the message; if they do not match, discard the message and return a verification failure response to the main station; Step 2, Parsing: After successful verification, read the JSON string from the policy parameter field of the message, perform deserialization, and restore the complete temporary policy data object; Step 3, Parameter Extraction: Extract policy parameters such as freq, items, period, push_format, and push_addr from the restored data object. The steps are as follows: 4. Backup the default policy: Copy the currently stored default acquisition policy (including default frequency, default data item list, etc.) from the default policy area of ​​the acquisition terminal to the temporary backup area to ensure lossless write-back during recovery; 5. Write the temporary policy: Write the parsed policy parameters to the temporary policy area of ​​the acquisition terminal; 6. Status marking: Mark the policy status register as TEMP_PENDING (pending effect), indicating that the temporary policy is ready and waiting to be switched to execution after the effective time; 7. Feedback confirmation: Return a successful delivery confirmation message to the master station, including the policy number and the current status of the acquisition terminal.

[0040] When the temporary policy reaches the start_time specified by the policy, the internal timer of the acquisition terminal triggers a policy switching interrupt and performs the following operations: First, stop the currently executing data acquisition task; second, reinitialize the acquisition task according to the policy parameters stored in the temporary policy area, including setting the acquisition frequency timer to the value of the freq field, configuring the data item channel selection to all data items contained in the items field, and configuring the reporting period filter to the time window limited by the period field; third, start a new acquisition task; fourth, update the policy status register to TEMP_ACTIVE; fifth, report the policy switching success status to the master station, including the policy number and the switching timestamp.

[0041] Furthermore, the method of this invention also includes: an anomaly handling mechanism: during the execution of the temporary policy, the acquisition terminal continuously monitors the following anomalies: acquisition timeout: if three consecutive acquisitions fail to complete within the expected time, it is determined to be an acquisition anomaly; storage overflow: if the storage area utilization rate exceeds 90%, an early warning is triggered; communication interruption: if communication with the main station is interrupted for more than 5 minutes, offline processing is triggered. When any of the above anomalies occurs, the acquisition terminal performs the following operations: first, immediately stop the execution of the acquisition task of the current temporary policy; second, read the default policy parameters from the temporary backup area; third, reinitialize the acquisition task to the default configuration; fourth, update the policy status register to DEFAULT; fifth, encapsulate the anomaly information into an alarm message and report it to the main station, the anomaly information including the anomaly type, the occurrence timestamp, and the policy number of the current temporary policy; sixth, after receiving the alarm, the main station pushes an anomaly notification to the user through the APP.

[0042] And a timer-based automatic policy recovery mechanism: (1) Expiration monitoring on the main station side; the main station registers a timed task in the expiration monitoring queue for each issued temporary policy. The core parameter of the timed task is expire_time (i.e., start_time + duration). When the system time reaches expire_time, the timed task is triggered, and the main station performs the following operations: query the complete information of the temporary policy from the database; construct a policy recovery message (message type 0x02), which includes the policy number and recovery instruction; send it to the corresponding acquisition terminal through the communication link; update the status field of the policy in the database to EXPIRED. (2) Self-recovery guarantee on the acquisition terminal side; in order to prevent the main station recovery instruction from failing to reach the acquisition terminal due to communication interruption or other reasons, a local expiration timer is also set in the acquisition terminal. When the acquisition terminal receives a temporary policy, in addition to writing the policy parameters, it also registers an expiration timed task in the local timer module, and the trigger time is also expire_time. The acquisition terminal will trigger policy recovery in the following two situations: receiving the master station recovery instruction: immediately execute recovery after parsing the instruction; local timer expires: if no master station recovery instruction is received when the timer expires (or the received instruction fails to be verified), recovery will be automatically triggered. The recovery operation process is as follows: first step, stop the current temporary policy acquisition task; second step, read the default policy parameters from the backup area; third step, reinitialize the acquisition task to the default configuration; fourth step, update the policy status register to DEFAULT; fifth step, report the recovery success status to the master station (including recovery method: REMOTE or LOCAL). (3) Expiration reminder mechanism: 10 minutes before the expiration time, the master station will push an expiration reminder notification to the user via SMS / APP, informing the user that the temporary policy will be terminated and reminding the user that if there is a need for renewal, they can resubmit the application.

[0043] It should be noted that the exception handling mechanism and the timer-based automatic recovery mechanism operate independently of each other; when both the exception recovery condition and the expiration recovery condition are met, the exception recovery takes priority to ensure terminal security.

[0044] After the temporary policy expires and the data collection terminal reverts to the default policy, the main site's data push module starts. The core of this module is a format conversion engine, supporting both Excel and JSON output formats. 1. Excel Format Output: The engine reads the raw data collected during the temporary policy execution (stored in the temporary data partition), generates an .xlsx file according to an Excel template (preset headers and cell formats), and sends it to the user's specified email address via email service. 2. JSON Format Output: The engine encapsulates the raw data into a JSON array using the structure {"timestamp": "...", "values": {"item_code": value, ...}}, and pushes it to the user-specified API address or cloud drive via an HTTP POST request. After the push is complete, the main site records the push log (including push time, push address, number of data entries, and push status) and migrates the data from the temporary data partition to the historical data area (retained for 1 year).

[0045] Reference Figure 2 This embodiment also discloses a user-side customized data acquisition strategy configuration system, which includes the following modules: a user requirement acquisition module, which generates user requirement parameters based on the client's structured requirement template. These user requirement parameters include: target acquisition frequency, data item list, effective start time, and effective duration parameters; a master station receiving user requirement messages and pre-verifying the user requirement parameters; a master station intelligent review module, which performs compliance review, acquisition terminal capability adaptability review, and power grid load assessment review on the pre-verified user requirement parameters; a temporary strategy generation module, which generates temporary strategy parameters based on the default acquisition strategy template determined by the user type for the approved user requirement parameters, and the master station constructs a temporary strategy object based on the temporary strategy parameters; a strategy distribution module, which distributes messages to the acquisition terminal via application layer protocols; a terminal execution module, which executes the strategy after receiving the message; an automatic recovery module, which executes a timer-based automatic strategy recovery mechanism; and a data push module, which pushes temporary strategies in Excel and JSON output formats.

[0046] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0047] The information interaction and execution process between the above modules are based on the same concept as the method embodiment of this application. It is a system corresponding to the above user-side customized collection strategy configuration method. All implementation methods in the above method embodiment are applicable to the system embodiment. For details on its specific functions and the resulting technical effects, please refer to the method embodiment section. It will not be repeated here.

[0048] To facilitate a further understanding of the technical solution of this invention, the method is described in full below through a preferred embodiment, with reference to... Figure 3 This embodiment takes the configuration of a data collection strategy for temporary monitoring of power generation fluctuations by photovoltaic users as an example, and includes the following steps: Step 1: User requirements submission and structured encapsulation; Photovoltaic users (low-voltage grid-connected three-phase photovoltaic users, account number: 1000001234) can log in to the power data acquisition service platform via mobile APP and, after completing identity authentication, enter the request submission interface. Users should select "Data Acquisition Frequency Adjustment + Add Data Item" as the request type in the templated form and fill in the following parameters: Target acquisition frequency: 60 seconds (1 minute); New data item: Power generation fluctuation value (data item code PV_FLUCT); Effective start time: 8:00 AM on the same day; Valid duration: 24 hours; Push format: Excel; Push notification address: xxx@company.com; The front-end encapsulates the above parameters into a JSON request message according to the structured requirement data object format, and uploads it to the main site's / api / demand / submit interface via HTTPS.

[0049] Step 2: Pre-validation of parameter validity; After receiving the message, the main station interface calls the pre-verification module to perform the following checks: freq_target=60 belongs to the preset set {60,300,900,1800,3600}, passing; the default collection frequency for this user type (PV user) is read from the user profile, which is 900 seconds, and 60<900, passing (frequency can be increased); data_items=[“PV_FLUCT”], where “PV_FLUCT” belongs to the preset data item dictionary, passing; duration=24 is between 1 and 72, passing; time_start is 8:00 AM on the current day, which is later than the current time but not more than 72 hours later, passing.

[0050] After the pre-validation is passed, the request message enters the review queue and is marked as PENDING.

[0051] Step 3: Compliance review; The rules engine loads the compliance rules library and matches each rule one by one: Frequency compliance rule: The minimum collection frequency for photovoltaic users is 60 seconds, freq_target=60≥60, passed; Data item compliance rule: "PV_FLUCT" is not in the blacklist of classified data items and belongs to the whitelist of data items that photovoltaic users are allowed to collect, passed; Time period compliance rule: The reporting time period of 8:00-8:00 the next day does not fall into the system maintenance window (0:00-6:00), passed.

[0052] All three rules were approved, and the device will proceed to the terminal capability compatibility review.

[0053] Step 4: Terminal capability compatibility verification; The main site queries the user profile based on user_id=1000001234 and retrieves the bound terminal_id=T98321. It then reads the terminal parameters from the terminal archive. Terminal Model: New Type of Smart Converged Terminal for Distribution Areas; max_freq=60 (Maximum support for 1 minute of data collection); supported_items contains "PV_FLUCT"; Matching calculation: freq_target=60≥max_freq=60, passed; "PV_FLUCT" in data_items belongs to supported_items, passed. Proceed to power grid load assessment.

[0054] Step 5: Power Grid Load Assessment; The system queries the load model data for the user's region (a specific distribution area): Current online terminal count N=156; Total bandwidth of the regional communication network B_total=10000 kbps; Current load rate L_curr=15%; Calculate the data size for a single report of "Power Generation Fluctuation Value" as d_new=2KB, f_new=60 seconds: ; ; The review has been approved. The main site will encapsulate the review result into a message and send it to the message queue of the policy generation module. At the same time, the app will push a notification to the user that "the review has been approved and the temporary policy will take effect at 8:00 today."

[0055] Step Six: Temporary strategies are automatically generated; The policy generation module consumes approved messages from the message queue and performs the following operations: reads the user profile as "PV user"; loads the default policy template for PV user from the policy library: base_freq=900, base_items=["forward active energy", "reverse active energy", "voltage", "current"], base_period="24 hours"; Execution parameter fusion: freq = 60 (user submission); items = [“Forward Active Energy”, “Reverse Active Energy”, “Voltage”, “Current”] ∪ [“PV_FLUCT”] = [“Forward Active Energy”, “Reverse Active Energy”, “Voltage”, “Current”, “PV_FLUCT”]; period = [8:00, 8:00 the next day]; push_format = "Excel"; push_addr = "xxx@company.com"; Generate policy ID: PV-COLLECT-2024052001; construct a complete temporary policy data object, status=INIT, and write it to the database.

[0056] Step 7: Policy distribution and terminal reception; The main station constructs a policy distribution message (type 0x01), serializes the policy data object into JSON, fills the message fields, calculates the CRC16 checksum, and distributes it to the terminal T98321 via the 4G communication link. Upon receiving the message, the terminal verifies the CRC16 checksum, which passes. Parse the policy parameters; copy the current default policy (900 seconds, four data items) to the temporary backup area; write the temporary policy (60 seconds, five data items) to the temporary policy area; mark the policy status register as TEMP_PENDING; return a confirmation of successful distribution to the master station.

[0057] Step 8: Execute the strategy switch; At 8:00 AM that day, the terminal's internal timer triggered a switching interrupt: the current 900-second cycle acquisition task was stopped; the acquisition task was reinitialized according to the temporary policy parameters: the acquisition cycle timer was set to 60 seconds, and the "PV_FLUCT" channel was added to the data item channel selection; a new acquisition task was started; the policy status register was updated to TEMP_ACTIVE; and "policy switching successful" was reported to the master station.

[0058] The terminal collects five data items every minute and uploads them to the main station in real time. The main station stores the data hourly. If one data item is missing during the period, the terminal is automatically triggered to re-collect the data. After successful re-collection, the data integrity rate reaches 100%.

[0059] Step Nine: Automatic Resumption Upon Expiration; At 7:50 AM the following day (10 minutes before expiration), the main station's expiration monitoring scheduled task is triggered, pushing an expiration reminder to the user's APP. At 8:00 AM the following day, the main station's scheduled task is triggered again, constructing a policy recovery message (type 0x02) and sending it to the terminal. Upon receiving the message: the terminal stops the temporary policy collection task; reads the default policy parameters from the backup area; reinitializes the collection task to a 900-second cycle and four data items; updates the policy status register to DEFAULT; and reports "Recovery successful (REMOTE)" to the main station.

[0060] Step 10: Data Push; At 8:30 the next day, the data push module was activated: it read 1,440 data records collected within 24 hours from the temporary data partition (60 seconds / time × 60 times / hour × 24 hours = 1,440 records); the format conversion engine generated .xlsx files according to the Excel template; it sent the files to xxx@company.com via email service; it recorded the push log and migrated the temporary data to the historical data area.

[0061] In summary, the advantages of using the method of this invention for customized data collection and configuration are as follows: It overcomes the bottleneck of existing technologies where "user requirements cannot be recognized by the system." After a user submits a requirement, no manual translation is needed; the system can automatically extract core parameters such as freq_target, data_items, and duration for subsequent processing. Requirement parsing and pre-verification are completed in milliseconds, significantly improving efficiency compared to the flow and entry of requirement documents in manual application (averaging several hours). All three review processes are fully automated, with a total review time of no more than one hour, and the review standards are uniform, eliminating the subjective bias and omission risks of manual review. The terminal file matching algorithm completely eliminates situations where strategy parameters exceed the terminal hardware capabilities. Through the regional load model, the risk of power grid overload is quantified into a calculable L_eval index, ensuring that any temporary strategy meets the safety constraint of L_eval ≤ 30%, guaranteeing the safe operation of the power grid. From user submission of requirements to terminal execution of temporary strategies, the entire process requires no manual entry of strategy parameters, shortening the configuration cycle from 2-3 working days in existing technologies to less than 1.5 hours, achieving a leap from "manual days" to "automated hours."

[0062] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for configuring a user-side customized data collection strategy, characterized in that, This method is used to configure temporary policy data objects for power acquisition terminals, and includes the following steps: Users generate user requirement parameters based on the structured requirement template on the client side. The user requirement parameters include: target collection frequency, data item list, effective start time and effective duration parameters; the main station receives the user requirement message and performs pre-verification on the user requirement parameters. Compliance audits, data acquisition terminal capability compatibility audits, and power grid load assessment audits are performed using pre-verified user requirement parameters. The compliance review includes: frequency compliance, data item compliance, and time period compliance; the terminal capability adaptability review includes: the review fails when the target acquisition frequency exceeds the maximum supported frequency, the data item list does not belong to the supported data item list, or the estimated data volume calculated for the effective duration exceeds the storage capacity; the power grid load assessment includes: calculating the new load based on the user demand, and if the sum of the current load rate and the new load exceeds the safety threshold, the review fails. For the approved user requirements parameters, a default collection strategy template is determined based on the user type. Then, the system merges and generates temporary strategy parameters. The main station constructs a temporary strategy object based on the temporary strategy parameters and sends a message to the collection terminal through the application layer protocol to complete the customized collection strategy configuration.

2. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The message structure adopted by the application layer protocol includes: a message header field with a fixed identifier, a version number field for identifying the version information of the current protocol, a message type field for distinguishing operation types, a policy number field for carrying the policy data object, a policy parameter field for carrying all information of the temporary policy data object, and a checksum field for verifying whether data errors or loss have occurred during the transmission of the message when the data acquisition terminal receives it.

3. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The pre-verification rules include: The target acquisition frequency belongs to the preset discrete set {60, 300, 900, 1800, 3600}, in seconds, and is not lower than the default acquisition frequency for this user type; each item in the list of data items to be acquired by the user belongs to the preset data item dictionary; the effective duration of the policy is between 1 and 72 hours; the effective start time of the temporary policy must not be earlier than the current time and must not be later than the current time + 72 hours; if the pre-verification fails, the main station will immediately return an error code and a specific error description.

4. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The design for calculating the additional load based on the user's needs is as follows: ； in, To estimate the new load, The amount of data reported per instance corresponds to the user's needs. B is the target acquisition frequency. total The total bandwidth of the regional communication network; according to Calculation and evaluation ; If L eval If L is less than the preset safety threshold, the review is approved; if L eval If the load exceeds the preset safety threshold, the main site calculates the recommended time period: shifting the demand period to the off-peak or low-peak period and pushing the load rate to the user along with the rejection notification.

5. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The structured requirement template is a structured requirement data object, and the data structure of the structured requirement data object is defined as follows: The `user_id` field, a string, stores a unique user identifier; the `demand_type` field, an enumeration, identifies the demand type, with possible values ​​including frequency adjustment, adding data items, and time period customization; the `freq_target` field, an integer, specifies the target collection frequency, with values ​​in GB / T seconds; the `data_items` field, a string array, lists the data items the user needs to collect; the `time_start` field, a date and time, indicates the start time of the temporary policy; the `duration` field, an integer, represents the effective duration of the policy; the `push_format` field, an enumeration, specifies the push format of the collected data, with possible values ​​of Excel or JSON; the `push_addr` field, a string, specifies the target address for data push, which can be an email address, a Uniform Resource Locator (URL), or a cloud drive path; and the `attach_file` field, a binary field, is used to attach a requirement specification file. The default data collection strategy template is a structured data object containing the following fields: default frequency base_freq, default data item list base_items, default reporting period base_period, and default push format base_push_format.

6. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The user requirement parameters are used to determine the default collection strategy template based on the user type, and then the fusion is performed to generate temporary strategy parameters: Determine whether the user has submitted the freq_target field: if submitted, use the freq_target field as the sampling frequency of the temporary policy; if not submitted, read the base_freq from the default sampling policy template corresponding to the user type as the sampling frequency. Take the union of base_items in the default collection strategy template and data_items submitted by the user, and perform deduplication to obtain the data item list for the temporary strategy; Determine whether the user has submitted the time_start and duration fields: if submitted, set the reporting period to start from the time_start and last for the duration of the duration field; If not submitted, the base_period in the default collection strategy template will be used as the reporting period; Determine whether the user has submitted the push_format field: if submitted, use the push_format as the push format; if not submitted, use the base_push_format in the default collection strategy template as the push format. The push address is directly taken from the push_addr submitted by the user.

7. The user-side customized data collection strategy configuration method according to claim 1, characterized in that: The internal maintenance strategy storage area of ​​the acquisition terminal is divided into three areas: the default strategy area, which stores the default acquisition strategy issued by the factory or the main station and is read-only; the temporary strategy area, which is a read-write storage area used to store the temporary strategies that have been received but have not yet taken effect or are in effect; and the strategy status register, which stores the current strategy status, including three states: default strategy in effect, temporary strategy pending, and temporary strategy in effect. After receiving the message, the acquisition terminal performs the following processing steps: Calculate the CRC16 checksum for the received message and compare it with the checksum field carried in the message; if they do not match, discard the message and return a checksum failure response to the master station. After successful verification, the JSON string is read from the policy parameter field of the message, deserialized, and the complete temporary policy data object is restored. Extract policy parameters from the temporary policy data object; Copy the currently stored default acquisition policy from the default policy area of ​​the acquisition terminal to the temporary backup area; Write the parsed policy parameters into the temporary policy area of ​​the acquisition terminal; Marking the policy status register as a temporary policy pending activation indicates that the temporary policy is ready and waiting to be activated before switching to execution. A successful delivery confirmation message is sent back to the main station, including the policy number and the current status of the data acquisition terminal; When the temporary policy reaches its specified effective time, the internal timer of the acquisition terminal triggers a policy switching interrupt and performs the following operations based on the current situation: Stop the currently executing data acquisition task; The acquisition task is reinitialized based on the policy parameters stored in the temporary policy area, including setting the acquisition frequency timer to the value of the current temporary policy acquisition frequency, configuring the data item channel selection to all data items contained in the items field, and configuring the reporting period filter to the time window limited by the period field. Start a new data collection task; update the policy status register to show that the temporary policy is in effect; Report the successful policy switch status to the main station, including the policy number and the switch timestamp.

8. The user-side customized data collection strategy configuration method according to claim 7, characterized in that: The method also includes: designing an exception handling mechanism and a timer-based automatic policy recovery mechanism. The exception handling mechanism continuously monitors the following abnormal situations during the execution of the temporary policy at the acquisition terminal: if three consecutive acquisitions are not completed within the expected time, it is determined to be an acquisition abnormality; storage overflow: if the storage area utilization rate exceeds 90%, it is determined to be a storage abnormality; communication interruption: if communication with the main station is interrupted for more than 5 minutes, it is determined to be a communication abnormality. If any of the above anomalies occur, the data acquisition terminal shall perform the following operations: Immediately stop the current temporary strategy's data collection task execution; Read the default policy parameters from the temporary backup area; reinitialize the data collection task to the default configuration; Update the policy status register to the default policy and make it effective; encapsulate the exception information into an alarm message and report it to the main station. The exception information includes the exception type, the timestamp of occurrence, and the policy number of the current temporary policy. After receiving the alarm, the main site pushes an anomaly notification to the user through the APP; The timer-based automatic policy recovery mechanism registers a scheduled task in the expiration monitoring queue for each issued temporary policy at the main station. The core parameter of the scheduled task is expire_time = start_time + duration. When the expire_time is reached, the scheduled task is triggered, and the main station performs the following operations: Retrieve complete information about the temporary policy from the database; construct a policy recovery message containing the policy number and recovery command; send it to the corresponding acquisition terminal via the communication link; update the status field of the policy in the database to indicate that it has expired; When the acquisition terminal receives a temporary policy, in addition to writing the policy parameters, it also registers an expiration timer task in the local timer module, with the trigger time also being expire_time. The acquisition terminal will trigger policy recovery in the following two situations: upon receiving a recovery command from the master station, it executes recovery immediately after parsing the command; the local timer expires: if no recovery command is received from the master station by the expiration time, recovery is automatically triggered. The recovery operation process is as follows: stop the current temporary policy acquisition task; read the default policy parameters from the backup area; reinitialize the acquisition task to the default configuration; update the policy status register to show that the default policy is in effect; report the recovery success status to the master station. The exception handling mechanism and the timer-based automatic recovery mechanism operate independently of each other; when the exception recovery condition and the expiration recovery condition are met at the same time, the exception recovery takes priority.

9. A user-side customized data acquisition strategy configuration system, wherein the system is applied to a user-side customized data acquisition strategy configuration method as described in any one of claims 1-8, characterized in that: The system includes the following modules: The user requirement acquisition module generates user requirement parameters based on the client's structured requirement template. The user requirement parameters include: target collection frequency, data item list, effective start time and effective duration parameters; the main station receives user requirement messages and pre-verifies the user requirement parameters. The main station's intelligent review module is used to perform compliance review, data acquisition terminal capability compatibility review, and power grid load assessment review on user requirement parameters that have passed pre-verification. The temporary strategy generation module is used to determine the default collection strategy template based on the user type for the approved user requirement parameters, and to perform fusion to generate temporary strategy parameters. The main site then constructs a temporary strategy object based on the temporary strategy parameters. The policy distribution module is used to distribute messages to the collection terminal via application layer protocols.

10. A user-side customized data acquisition strategy configuration system according to claim 9, characterized in that: The system also includes: a terminal execution module, used to execute a strategy after the acquisition terminal receives a message; The automatic recovery module upon expiration is used to execute the timer-based automatic policy recovery mechanism; and the data push module is used to push temporary policies in both Excel and JSON output formats.

Images