A power terminal event-driven resource dynamic scheduling method and system

Abstract

The application discloses a power terminal event-driven resource dynamic scheduling method and system, the method comprising: obtaining terminal running state information; determining a target event state according to the terminal running state information; obtaining a preset association between event states and resource configurations, determining a target resource configuration according to the target event state and the association; generating a configuration switching transaction according to the target resource configuration to switch the current resource configuration into the target resource configuration to obtain a switched resource state; obtaining switching verification data, stably confirming the switched resource state according to the switching verification data, controlling terminal services according to the target resource configuration when the confirmation is passed, restoring the current resource configuration through the configuration switching transaction when the confirmation is not passed, and outputting a resource scheduling result. The application is conducive to reducing normal working condition resource occupation while guaranteeing the real-time performance, sampling continuity and data integrity of key services under abnormal working conditions.

Description

Technical Field

[0001] This application relates to the fields of power Internet of Things, embedded control of power terminals and edge resource scheduling technology, and in particular to a power terminal event-driven dynamic resource scheduling method and system. Background Technology

[0002] With the advancement of new power system construction, power terminals such as distribution line terminals and transformer area terminals are gradually evolving from data acquisition nodes into edge devices with capabilities including status awareness, fault diagnosis, protection and control, fault recording, and communication transmission. Different services have different requirements for real-time performance, storage capacity, and communication bandwidth.

[0003] Existing power terminals typically fix the sampling rate, buffer quota, task priority, and communication bandwidth during the initialization phase, or only switch the sampling rate when electrical quantities exceed limits. General-purpose real-time operating systems usually execute tasks according to static priorities, making it difficult to adapt to normal, early warning, and fault operating conditions simultaneously.

[0004] Therefore, how to coordinate the changes of various resources with the severity of power events under the condition of limited terminal resources, and avoid sampling interruptions, cached data disorder or delays in critical services caused by resource adjustments, has become a technical problem that needs to be solved. Summary of the Invention

[0005] This application proposes an event-driven dynamic resource scheduling method and system for power terminals, aiming to coordinate and adjust resources of multiple types of terminals when the operating conditions of power terminals change, and improve the continuity and consistency of the resource switching process.

[0006] In a first aspect, embodiments of this application provide an event-driven dynamic resource scheduling method for power terminals, applied to power terminals. The method includes: acquiring terminal operating status information, including electrical status, equipment status, communication status, and service load status; determining a target event status based on the terminal operating status information; acquiring a preset association between event status and resource configuration, and determining a target resource configuration based on the target event status and the association, the target resource configuration including at least two types of resource parameters among sampling resources, buffer resources, scheduling resources, and communication resources; generating a configuration switching transaction based on the target resource configuration, and switching the current resource configuration to the target resource configuration through the configuration switching transaction to obtain the switched resource status; acquiring switching verification data, performing stability confirmation on the switched resource status based on the switching verification data, controlling terminal services according to the target resource configuration when confirmation is successful, and restoring the current resource configuration through the configuration switching transaction when confirmation fails, and outputting resource scheduling results.

[0007] As can be seen, in this embodiment, the power terminal determines the resource configuration that is compatible with the current operating conditions based on the terminal's operating status, and completes the group switching of multiple types of resources and the confirmation after the switching through configuration switching transactions. This helps to balance the resource utilization rate under normal operating conditions with the real-time performance, sampling continuity and data integrity of key services under abnormal operating conditions.

[0008] In one possible example, the step of generating a configuration switching transaction based on the target resource configuration, and switching the current resource configuration to the target resource configuration through the configuration switching transaction to obtain the resource state after the switch, includes: performing resource pre-configuration based on the target resource configuration to obtain a configuration to be committed; recording the current resource configuration to obtain a rollback configuration; encapsulating the configuration to be committed and the rollback configuration into the configuration switching transaction; responding to the resource switching boundary, submitting the configuration to be committed to the corresponding hardware resources and system services through the configuration switching transaction, and retaining the rollback configuration to obtain the resource state after the switch; wherein, the resource switching boundary includes a sampling frame boundary or a data transport block boundary.

[0009] As can be seen, in this example, the resource preparation operation and the resource submission operation are separated, and the resource state before the switch is preserved, so that the resource switch can take effect at a defined boundary and provide a basis for recovery in case of submission anomalies or stability confirmation failures.

[0010] In one possible example, the step of pre-configuring resources according to the target resource configuration to obtain the configuration to be submitted includes: extracting a resource control parameter group from the target resource configuration; performing a validity check on the resource control parameter group according to the terminal hardware capabilities to obtain a valid parameter group; generating a target resource configuration item set based on the valid parameter group, the target resource configuration item set including at least two of the following: target cache space, target data transport descriptor, target scheduling parameter table, and target communication queue policy; and associating the configuration items in the target resource configuration item set to obtain the configuration to be submitted.

[0011] As can be seen in this example, the resource control parameters are verified by hardware capabilities before entering the switching process and are converted into configuration items that can be executed by the corresponding hardware resources or system services, which helps to reduce the possibility of invalid parameters entering the submission stage.

[0012] In one possible example, the step of associating configuration items in the target resource configuration item set to obtain the configuration to be committed includes: assigning a target configuration version identifier to the target resource configuration; writing the configuration items in the target resource configuration item set into configuration areas corresponding to the target configuration version identifiers to obtain a version resource configuration item set; determining resource dependencies based on the version resource configuration item set; generating an atomic commit sequence based on the resource dependencies; and associating the version resource configuration item set, the target configuration version identifier, and the atomic commit sequence to obtain the configuration to be committed.

[0013] As can be seen in this example, different resource configuration items form a complete configuration state through a unified version identifier and atomic commit sequence, enabling the switching process to distinguish between the current version, the version to be committed, and the rollback version, reducing the situation where new and old resource parameters take effect simultaneously.

[0014] In one possible example, determining resource dependencies based on the set of version resource configuration items includes: extracting sampling trigger configuration items, data transport configuration items, and caching configuration items from the set of version resource configuration items, and determining collection dependencies based on the corresponding data generation and writing order; extracting scheduling configuration items and communication configuration items from the set of version resource configuration items, and determining service dependencies based on the data processing and sending order of terminal services; and merging the collection dependencies and the service dependencies to obtain the resource dependencies.

[0015] As can be seen, in this example, the submission order of resource configuration items is constrained by both the sampling data path and the terminal service path, which can avoid the inconsistency problem of data transfer, task scheduling or communication queues using the new configuration before the data source has been switched.

[0016] In one possible example, generating an atomic commit sequence based on the resource dependencies includes: dividing the configuration items in the version resource configuration item set into at least two groups of collection commit group, scheduling commit group, and communication commit group according to the resource dependencies; setting the resource switching boundary as a commit trigger condition; arranging each commit group according to the resource dependencies to obtain a commit sequence to be confirmed; and setting the target configuration version identifier at the end of the commit sequence to be confirmed to obtain the atomic commit sequence.

[0017] As can be seen, in this example, the configuration items are grouped and arranged according to resource dependencies, and the target configuration version identifier is set only after a complete commit, which helps the terminal service to only identify the target resource configuration that is fully effective.

[0018] In one possible example, after determining the target event state, the method further includes: when the target event state satisfies the fault recording condition, determining the event time and the pre-fault recording window; determining the pre-fault data interval in the circular buffer based on the event time and the pre-fault recording window, setting the pre-fault data interval to read-only to obtain a frozen data segment, and updating the data transfer descriptor so that the write pointer avoids the pre-fault data interval and points to the double buffer; alternately writing the post-fault sampled data into the double buffer according to the target resource configuration, and writing the data in the double buffer into segments into non-volatile memory to obtain a post-fault data segment; combining the frozen data segment and the post-fault data segment in chronological order to output a fault recording file.

[0019] As can be seen in this example, the data before the fault is retained when the event occurs, and the data after the fault is continuously written to the non-volatile memory through a double buffer, thereby enabling the formation of a continuous fault record without requiring the on-chip cache to store all high-sampling-rate data for a long time.

[0020] In one possible example, upon successful confirmation, the method further includes: acquiring data to be transmitted; prioritizing the data to be transmitted according to the urgency of the business to obtain a hierarchical data queue; determining the channel allocation strategy and flow control strategy of the hierarchical data queue according to the communication resource parameters in the target resource configuration; extracting key data and complete waveform data from the hierarchical data queue according to the channel allocation strategy; transmitting the key data through a first communication channel and the complete waveform data through a second communication channel; and restricting or suspending the transmission of low-priority data according to the flow control strategy, and outputting the communication scheduling result; wherein the key data includes at least one of protection action information and fault summary, the transmission delay of the first communication channel is lower than that of the second communication channel, and the transmission bandwidth of the second communication channel is higher than that of the first communication channel.

[0021] As can be seen, in this example, critical data and large-capacity waveform data are matched with different communication channels, and low-priority data is deferred during high-level events, which helps to shorten the queuing time of critical data, while preserving the ability to send complete waveform data.

[0022] In one possible example, after outputting the resource scheduling result, the method further includes: obtaining the event resolution status and the critical data preservation status; when the event resolution status indicates that the target event has been resolved and the critical data preservation status indicates that the critical data has entered non-volatile memory or a reliable upload queue, starting a hold timer to obtain a hold result; when the hold result indicates that a preset hold duration has been reached, determining the backslip resource configuration corresponding to the adjacent lower-level event status according to the correlation; generating a backslip transaction according to the backslip resource configuration and switching it level by level to obtain a backslip scheduling result; when an event is detected to be more severe during the level-by-level switching, terminating the backslip transaction, re-determining the target event status and executing the corresponding configuration switching transaction, and updating the backslip scheduling result.

[0023] As can be seen in this example, the terminal releases resources step by step after the event is resolved, critical data is preserved and stabilized, and can resume the upgrade process if an anomaly occurs again during the rollback, which helps to suppress frequent switching near the event threshold.

[0024] Secondly, embodiments of this application provide a power terminal event-driven dynamic resource scheduling system, comprising: an operation status acquisition module for acquiring terminal operation status information, the terminal operation status information including electrical status, equipment status, communication status, and service load status; an event status determination module for determining a target event status based on the terminal operation status information; a resource configuration determination module for determining a target resource configuration based on the target event status and a preset correlation between the event status and resource configuration, the target resource configuration including at least two types of resource parameters among sampling resources, buffer resources, scheduling resources, and communication resources; a configuration switching module for generating a configuration switching transaction based on the target resource configuration, switching the current resource configuration to the target resource configuration through the configuration switching transaction, and obtaining the switched resource status; and a stability confirmation module for acquiring switching verification data, performing stability confirmation on the switched resource status based on the switching verification data, controlling terminal services according to the target resource configuration when confirmation is successful, restoring the current resource configuration through the configuration switching transaction when confirmation is unsuccessful, and outputting resource scheduling results.

[0025] As can be seen, in this embodiment, each functional module transmits the processing results in sequence according to the terminal running status information, the target event status, the target resource configuration, and the resource status after switching, thereby realizing the event-driven dynamic resource scheduling process corresponding to the aforementioned method.

[0026] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, a communication interface, and one or more programs, the one or more programs being stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps in the first aspect of embodiments of this application.

[0027] Fourthly, embodiments of this application provide a computer storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the first aspect of this embodiment.

[0028] As can be seen, in this embodiment, compared to existing power terminals that use fixed resource configurations or only adjust a single resource parameter, this application achieves dynamic association between power event states and multiple types of terminal resources. The power terminal in this application first obtains terminal operating status information; second, it determines the target event state based on the terminal operating status information; then, it obtains the association between the event state and resource configuration and determines the target resource configuration; third, it generates a configuration switching transaction based on the target resource configuration, and performs group switching of the current resource configuration through the configuration switching transaction; finally, it obtains switching verification data, confirms the stability of the resource state after switching, and controls terminal services or restores the current resource configuration according to the confirmation result. Because the configuration switching transaction organizes resource parameters at different levels into resource states that can be committed and restored as a whole, terminal resources can be consistently switched according to changes in event states, thereby reducing resource consumption under normal operating conditions while ensuring the real-time performance, sampling continuity, and data integrity of critical services under abnormal operating conditions. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the hardware architecture for power terminal event-driven dynamic resource scheduling provided in the embodiments of this application; Figure 2 This is a schematic diagram of the power terminal event-driven dynamic resource scheduling software architecture provided in the embodiments of this application; Figure 3 This is a schematic diagram of dynamic resource scheduling under a power distribution line fault scenario provided in an embodiment of this application; Figure 4 This is a schematic diagram of the power terminal event-driven dynamic resource scheduling method provided in the embodiments of this application; Figure 5 A schematic diagram illustrating the association between event status, resource configuration, and switch confirmation provided in an embodiment of this application; Figure 6 This is a schematic diagram of the configuration switching transaction execution process provided in an embodiment of this application; Figure 7 This is a schematic diagram of the resource pre-configuration process provided in an embodiment of this application; Figure 8 A flowchart illustrating the process of associating version resource configuration items as provided in this application embodiment; Figure 9 A flowchart illustrating the resource dependency determination process provided in this application embodiment; Figure 10 A flowchart illustrating the atomic submission sequence generation process provided in this application embodiment; Figure 11 A flowchart illustrating the process of freezing data before a fault and recording data after a fault, provided in an embodiment of this application; Figure 12 A flowchart illustrating the hierarchical data queue and dual communication channel scheduling process provided in the embodiments of this application; Figure 13 A flowchart illustrating the resource hierarchical switchback and subsequent upgrade state transition process provided in this application embodiment; Figure 14 A schematic diagram of the functional modules of the power terminal event-driven dynamic resource scheduling system provided in the embodiments of this application. Detailed Implementation

[0030] The power terminal in this application can be a distribution line terminal, a substation terminal, a transformer area intelligent terminal, a protection and control terminal, or other terminals with power status acquisition and edge processing capabilities. The power terminal can simultaneously perform multiple services including sampling, fault diagnosis, protection control, waveform recording, status diagnosis, communication transmission, and remote operation and maintenance.

[0031] Terminal operating status information is a collection of information that reflects the external operating conditions and internal resource load of a power terminal. Electrical status can include the status of voltage, current, frequency, harmonics, and zero-sequence components; equipment status can include temperature, power supply, reset, and watchdog status; communication status can include link connection, error count, packet loss, and latency status; and service load status can include task timeout, processing load, and buffer occupancy status.

[0032] The target event status is the basis for resource scheduling determined by the power terminal based on the current terminal operating status information. Target event status can include normal status, early warning status, severe abnormal status, and emergency protection status. The number of statuses can be adjusted according to the terminal type. When multiple events occur concurrently, the most severe valid event can be designated as the primary event, or the resource requirements of multiple events can be merged without reducing the resource requirements of any critical business operation.

[0033] The relationship between event states and resource configurations can be implemented using resource configuration templates, configuration rule sets, or candidate configuration indexes. Resource configurations describe the resource states adopted by a power terminal under a given operating condition. Target resource configurations must include at least two types of resource parameters: sampling, buffering, scheduling, and communication. Scheduling resources may further include task priority, interrupt priority, and execution quota; communication resources may further include queue priority, channel selection, transmission frequency, and flow limit parameters.

[0034] A configuration switchover transaction is a data structure that organizes the preparation content of the target resource configuration, the restoration content of the current resource configuration, and the configuration commit control information into a switchover unit. Grouped switchover does not require all registers to be written in the same clock cycle, but rather requires that terminal services cannot observe an intermediate state formed by a mixture of different configuration versions.

[0035] Switchover verification data is used to determine whether the resource status after the switchover can be stably used by the terminal service. It can include sampling sequence number, timestamp, buffer read / write position, configuration version, task running status, and communication queue status. Resource scheduling results can include switchover success result, rollback result, currently effective configuration version, reason for exception, and alarm status.

[0036] See Figure 1 The power terminal event-driven dynamic resource scheduling hardware system 100 includes a power terminal 110, an electrical parameter acquisition component 120, an equipment status acquisition component 130, a communication status monitoring component 140, an edge gateway 150, a distribution automation master station 160, an operation and maintenance management platform 170, and a communication network 180. The power terminal 110 may include a processor 111, a storage unit 112, a sampling and timing component 113, a data transfer component 114, a communication control component 115, a non-volatile memory component 116, and a watchdog component 117.

[0037] The electrical parameter acquisition component 120 provides voltage, current, frequency, and related electrical status to the power terminal 110. The equipment status acquisition component 130 provides temperature, power supply, and reset status. The communication status monitoring component 140 provides link connection, error count, packet loss, and latency status. The sampling and timing component 113 generates sampling data according to the current sampling resource parameters, and the data transfer component 114 writes the sampling data into the buffer area in the storage unit 112.

[0038] Processor 111 performs event status determination, resource configuration determination, configuration transaction control, and stability confirmation operations. Communication control component 115 manages different data queues according to communication resource parameters. Non-volatile memory component 116 is used to store resource configuration, waveform data, and switching records. Watchdog component 117 is used to monitor the operating status of power terminal 110 and can provide a basis for reset or alarm in case of abnormal resource switching.

[0039] The power terminal 110 interacts with the edge gateway 150, the distribution automation master station 160, and the operation and maintenance management platform 170 via the communication network 180. The edge gateway 150 can forward critical events and waveform recording data, and can also send verifiable configuration details to the power terminal 110. The above hardware configuration is only one implementation method, and the method described in this application is not limited to a specific processor, storage structure, or communication controller.

[0040] This hardware architecture enables sampling, caching, processing, storage, and communication resources to be uniformly scheduled by the power terminal 110, providing an execution basis for the preparation, submission, verification, and recovery of different resource configuration items.

[0041] See Figure 2 The resource dynamic scheduling software architecture 200 includes a hardware abstraction and driver layer 210, an event awareness and hierarchical layer 220, a resource configuration management layer 230, a transaction scheduling control layer 240, a buffer and waveform recording management layer 250, a task and interrupt control layer 260, a hierarchical communication management layer 270, a state machine and switchback layer 280, and a business application layer 290. The business application layer 290 may include a line status monitoring unit 291, a fault waveform recording unit 292, a protection control unit 293, an equipment diagnostic unit 294, and a remote operation and maintenance unit 295.

[0042] The hardware abstraction and driver layer 210 encapsulates the control interfaces for sampling, timing, data transfer, storage, and communication resources. The event awareness and hierarchy layer 220 aggregates electrical status, device status, communication status, and service load status, and determines the target event status. The resource configuration management layer 230 maintains the association between event status and resource configuration and provides the target resource configuration.

[0043] The transaction scheduling control layer 240 is used to generate transactions for configurations to be committed, configurations to be rolled back, and configuration switching, and to control configuration commits and stable confirmations. The caching and waveform recording management layer 250 is used to manage the circular cache, double buffers, frozen data segments, and waveform recording files. The task and interrupt control layer 260 is used to adjust task priorities, interrupt priorities, and the running frequency of non-critical tasks. The hierarchical communication management layer 270 is used to perform data hierarchies, channel allocation, and flow control. The state machine and rollback layer 280 is used to manage event escalation, timekeeping, tiered rollback, and re-escalation during rollback.

[0044] The business application layer 290 obtains resource guarantees through the aforementioned software layer. The protection control unit 293 retains basic execution conditions under any event state; the remote operation and maintenance unit 295, background logs, and non-critical diagnostic tasks can reduce their operating frequency or be suspended during high-level events. This software architecture can be deployed on an IoT operating system for power terminals, or on other embedded operating systems with event bus, task scheduling, and drive management capabilities.

[0045] This software architecture connects business events, resource configurations, and hardware execution actions in the same control link, eliminating the need for the application layer to modify sampling, caching, task, and communication parameters separately, thus reducing the possibility of inconsistent states caused by distributed configurations.

[0046] See Figure 3 In a power distribution line fault resource scheduling scenario, the state awareness component 320 obtains three-phase voltage and three-phase current from the power distribution line 310 and provides sampling signals to the power terminal 110. During normal operation, the power terminal 110 can maintain a ring buffer with a low sampling rate and send telemetry data via the second communication link 340 according to a regular cycle. When a fault event 350 manifests as a continuous current surge, protection input action, or a change in trip output, the power terminal 110 raises the target event status to a severe abnormal state or an emergency protection state, and increases the sampling intensity, expands the protection of critical business operations, freezes pre-fault data, and restricts non-critical tasks.

[0047] In this embodiment, the first communication link 330 can be a CAN-FD link with low transmission latency and high determinism, used to send protection action information and fault summaries in advance; the second communication link 340 can be an Ethernet link, used to send complete waveform data in segments to the edge gateway 150 or the distribution automation master station 160. The operation and maintenance management platform 170 can receive waveform files, switching records, and resource scheduling results after the event processing is completed.

[0048] As another business example, when power terminal 110 simultaneously experiences both increased equipment temperature and a rise in communication errors, even if the electrical quantities of distribution line 310 do not meet the fault criteria, power terminal 110 can still enter a severely abnormal state. This prioritizes equipment diagnostics and critical alarm transmission, while restricting batch logging and remote upgrade services. This scenario illustrates that the target event state can be triggered by different categories of operating states, rather than being limited to a single electrical quantity exceeding its limit.

[0049] See Figure 4 The power terminal event-driven dynamic resource scheduling method can be implemented through the following steps S101 to S105.

[0050] S101, Obtain terminal operating status information, which includes electrical status, equipment status, communication status, and service load status.

[0051] Electrical status can be formed by voltage amplitude, current amplitude, sudden changes in electrical quantities, frequency offset, harmonic status, and zero-sequence status. Equipment status can be formed by temperature, power supply, reset, and watchdog status. Communication status can be formed by link connection status, error count, packet loss status, and transmission delay. Service load status can be formed by task timeout count, processing load, and buffer occupancy status.

[0052] Status data from different sources can be written to the event cache according to their respective update cycles. For statuses with different update frequencies, the power terminal can save the most recent valid value, the acquisition time, and the validity period, and read statuses that are still within the validity period within a unified judgment period. The power terminal can also perform window filtering on continuous statuses and de-jitter counting on discrete alarms to reduce the impact of instantaneous noise on event judgment.

[0053] S102, determine the target event status based on the terminal operating status information.

[0054] The target event state is used to characterize the operating condition level that needs to be achieved in this resource scheduling. Power terminals can first normalize and classify different categories of states, and then set judgment weights for each category according to the terminal type. Line monitoring terminals can increase the judgment weight of electrical states, and equipment diagnostic terminals can increase the judgment weight of equipment states.

[0055] Power terminals can also be configured with mandatory state rules. When protection input actions, trip output changes, or other emergency control signals occur, an emergency protection state can be directly determined. When a sudden current change consistently meets set conditions, a state no lower than a severe abnormality can be determined. When multiple events occur concurrently, the most severe valid event can be selected as the primary event, preventing low-level events from lowering the resource levels required for critical operations.

[0056] S103, obtain the preset association between event state and resource configuration, and determine the target resource configuration based on the target event state and the association. The target resource configuration includes at least two types of resource parameters among sampling resources, cache resources, scheduling resources and communication resources.

[0057] The relationship can be represented as a mapping from state to resource configuration template, or as a mapping from state, event type, and terminal type to candidate configuration. Sampling resource parameters can include sampling rate, timed triggering method, and data transfer mode; caching resource parameters can include cache quota, pre-fault recording window, post-fault recording window, and data disk persistence method; scheduling resource parameters can include task priority, interrupt priority, and execution quota; communication resource parameters can include data queue level, channel selection, transmission frequency, and rate limiting method.

[0058] Target resource configuration is not an isolated modification of a single parameter, but rather a target operational state formed by at least two types of resources. For example, the target resource configuration corresponding to a severe abnormal state can simultaneously increase the sampling rate, enable double buffering, increase the priority of fault diagnosis tasks, and limit background log sending.

[0059] S104, Generate a configuration switching transaction based on the target resource configuration, and switch the current resource configuration to the target resource configuration through the configuration switching transaction to obtain the resource status after the switch.

[0060] A configuration switchover transaction can include configurations to be committed, configurations to be rolled back, target configuration versions, resource switchover boundaries, and commit control information. While normal business operations continue, the power terminal prepares the target cache, data transfer descriptors, and scheduling parameters, and commits the prepared configuration content when the resource switchover boundary is reached. The post-switchover resource status indicates the actual operating status of various resources after configuration commit, rather than simply indicating that the configuration command has been issued.

[0061] S105, obtain handover verification data, perform stability confirmation on the resource status after handover based on the handover verification data, control terminal services according to the target resource configuration when the confirmation is successful, restore the current resource configuration through the configuration handover transaction when the confirmation is unsuccessful, and output resource scheduling results.

[0062] The switchover verification data can include adjacent sampling sequence numbers before and after the switchover, adjacent sampling times, data transfer completion count, buffer read / write positions, current configuration version, critical task running status, and critical communication queue status. Stability can be confirmed as passed when sampling sequence numbers are consecutive, timestamps match the current sampling period, read / write positions do not illegally overlap, the target version is effective, and critical tasks have the necessary execution conditions.

[0063] When stability verification fails, the power terminal can stop continuing to provide the service output corresponding to the target configuration, invoke the rollback configuration in the configuration switching transaction to restore the state before the switch, and record the failure stage, abnormal resource items, and verification data. The resource scheduling results can be provided to the local alarm logic, edge gateway, or master station for subsequent handling and configuration adjustments.

[0064] As can be seen in this example, the target event state is first determined from the multi-source running state, then the target configuration of multiple types of resources is determined, and then the configuration switch is completed and the actual running state is verified in a transactional manner. This enables the event semantics to be transformed into executable and recoverable resource actions, which helps to maintain the continuity of critical business operations when terminal resources are limited.

[0065] See Figure 5 The event status, resource configuration, and handover confirmation association structure 500 includes terminal running status information 510, event status set 520, association relationship 530, target resource configuration 540, configuration handover transaction 550, post-handover resource status 560, handover verification data 570, resource scheduling result 580, and current resource configuration 590.

[0066] After the terminal operating status information 510 enters the event status set 520 for judgment, the power terminal determines the target event status from candidate statuses such as normal, warning, severe abnormality, and emergency protection. The association relationship 530 is used to locate the target resource configuration 540 from the target event status. The target resource configuration 540 and the current resource configuration 590 respectively provide the target content after the handover and the recovery content in case of handover failure.

[0067] Configuration switchover transaction 550 causes the target resource configuration 540 to enter the switched-off resource state 560 according to the resource dependency order. Switchover verification data 570 is used to verify whether the switched-off resource state 560 is consistent with the target resource configuration 540. If the verification passes, a resource scheduling result 580 indicating that the target configuration has taken effect is generated; if the verification fails, configuration switchover transaction 550 calls the recovery content corresponding to the current resource configuration 590 and generates a resource scheduling result 580 indicating that it has been rolled back or requires an alarm.

[0068] This association structure creates a closed loop for state determination, configuration selection, transaction switching, and result confirmation. Association 530 can be updated remotely, but the updated configuration is only allowed to enter the selectable state after passing version, capacity, and hardware capability verification, thereby preventing unverified configurations from directly participating in runtime switching.

[0069] See Figure 6 The configuration switching transaction execution process in step S104 can be implemented through the following steps S201 to S204. The configuration switching transaction execution structure includes target resource configuration 540, configuration to be committed, rollback configuration, resource switching boundary, configuration switching transaction 550, hardware resources, system services, and post-switching resource status 560.

[0070] S201, perform resource pre-configuration based on the target resource configuration to obtain the configuration to be submitted.

[0071] Resource pre-configuration refers to the pre-completion of memory allocation, descriptor construction, parameter writing, and service preparation required for the target resources while the current resource configuration remains effective for terminal services. Pending submission configuration refers to a configuration state where preparation is complete but the configuration is not yet open to terminal services. Resource pre-configuration does not directly change the current sampling path or the current task scheduling state.

[0072] For sampling resources, the power terminal can write target trigger parameters to the timer shadow area and establish a backup data transfer descriptor; for cache resources, it can allocate target caches and complete address boundary checks; for scheduling resources, it can write target task priorities and interrupt priorities to the backup priority table; for communication resources, it can pre-establish target queue weights and current limiting parameters.

[0073] S202, record the current resource configuration and obtain the rollback configuration.

[0074] The current resource configuration is the configuration state that actually took effect before the switch began. The rollback configuration can record the current sampling trigger parameters, current data transfer descriptor, current cache address, current priority table, current communication queue policy, and current configuration version. The rollback configuration can be either a complete copy of the aforementioned content or a version index that can relocate the currently active version.

[0075] S203, the configuration to be committed and the rollback configuration are encapsulated into the configuration switching transaction.

[0076] Configuration switch transactions can further carry transaction identifiers, target configuration versions, current configuration versions, resource switch boundaries, commit status, failed resource items, and recovery entry points. Transaction statuses can include preparing, pending commit, committing, pending confirmation, completed, and rolled back. A transaction is only allowed to enter the pending commit state when the configuration to be committed is complete and the rollback configuration is available.

[0077] S204, responding to the resource switching boundary, submitting the configuration to be submitted to the corresponding hardware resources and system services through the configuration switching transaction, and retaining the rollback configuration to obtain the resource status after the switch; wherein, the resource switching boundary includes the sampling frame boundary or the data transport block boundary.

[0078] Resource switching boundaries are the timing points at which a target configuration transitions from an invisible state to a state where it is effective for terminal services. A sampling frame boundary can be the position where the current sampling frame is completed and the next sampling frame has not yet been triggered; a data transport block boundary can be the position where a data transport block is completed and the next data transport block has not yet started. Choosing this type of boundary can prevent the simultaneous use of two configurations for the same sampling frame or the same data block.

[0079] Configuration submission can first switch the sampling trigger and data transfer path, then switch the scheduling parameters and communication queue. After submission, the target configuration version is set as the active version, and hardware resources and system services together form the post-switch resource state 560. Rollback configurations remain available until stability is confirmed.

[0080] In one possible implementation of this application, when the hardware resource has a shadow register, the target parameters can be pre-written, and the submission can be completed by updating the effective bits at the resource switching boundary; when the hardware resource does not have a shadow register, a spare descriptor, a spare parameter table, or an indirect index can be established, and the active pointer can be switched at the resource switching boundary. Thus, what is constrained by the boundary time limit is the active configuration switching operation, rather than the entire preparation process of pre-allocating cache, calculating parameters, and constructing descriptors.

[0081] As can be seen, in this example, separating resource preparation, current state saving, and boundary commit, and ensuring that rollback configuration is carried out throughout the stable confirmation phase, helps to reduce intermediate states during switching and improves the ability to recover from anomalies.

[0082] See Figure 7 The resource pre-configuration process in step S201 can be implemented through the following steps S301 to S304.

[0083] S301, Extract the resource control parameter group from the target resource configuration.

[0084] The resource control parameter group is a set of parameters extracted from the target resource configuration and organized according to the controlled resource category. Sampling parameters may include target sampling rate, trigger period, and data transfer mode; caching parameters may include cache quota, recording window, and storage method; scheduling parameters may include task priority, interrupt priority, and execution quota; and communication parameters may include queue level, channel selection, transmission period, and rate limiting level.

[0085] The resource control parameter group preserves the correlation between the parameters. For example, when the target sampling rate is increased, the associated cache write speed, data transport block size, and non-volatile memory write method need to be included in the subsequent verification, rather than simply judging whether the target sampling rate itself exceeds the hardware limit.

[0086] S302, the validity of the resource control parameter group is verified according to the terminal hardware capabilities to obtain a valid parameter group.

[0087] Terminal hardware capabilities can include maximum sampling capacity, available cache capacity, number of data transfer channels, continuous write capability of non-volatile memory, processing load margin, task priority range, and communication link capability. Validity checks can examine the range of parameter values ​​item by item, and can also check whether the resource requirements formed by the combination of multiple parameters can be executed by the terminal.

[0088] When the resource control parameter set does not meet the terminal hardware capabilities, the power terminal can choose the safe default configuration, or adjust the waveform recording window, buffer block size, downsampling storage method, or segmented disk method without lowering the minimum requirements for critical services. The adjusted parameter set needs to be re-verified, and a valid parameter set is formed after successful verification.

[0089] In one possible implementation of this application, pre-fault data and post-fault data can be stored using different paths. Pre-fault data is stored in a circular buffer at the normal sampling rate under normal conditions; after an event occurs, post-fault data, generated by increasing the sampling rate, only briefly resides in the double buffer and is continuously written to non-volatile memory. This approach allows the on-chip buffer to primarily handle the pre-fault window and data transfer buffering functions, without needing to accommodate all high-sampling-rate post-fault data, thus solving the subdivision problem of insufficient on-chip buffer capacity when the waveform recording window expands.

[0090] S303, Generate a target resource configuration item set based on the valid parameter set, wherein the target resource configuration item set includes at least two of the following: target cache space, target data transport descriptor, target scheduling parameter table, and target communication queue policy.

[0091] Target resource configuration items are configuration objects that can be directly executed by hardware resources or system services. Target cache space may include cache address, length, read-only range, and write boundary; target data transfer descriptor may include source address, target address, block length, round-robin mode, and completion notification mode; target scheduling parameter table may include target priorities corresponding to tasks and interrupts; target communication queue policy may include queue weight, channel selection, retry, and rate limiting parameters.

[0092] S304, associate the configuration items in the target resource configuration item set to obtain the configuration to be submitted.

[0093] Associated configuration items are used to set a common target configuration identity for different configuration items and to clarify the dependencies and commit conditions between them. The configuration to be committed contains the target resource configuration items that have already been allocated or generated, rather than just abstract parameters that are yet to be interpreted. Therefore, configuration switching transactions can directly invoke the configuration to be committed to execute subsequent commits.

[0094] As can be seen in this example, the target resource configuration is first converted into a resource control parameter group, and then the terminal hardware capability is verified and an executable configuration item is generated, so that the configuration entering the submission stage has a clear execution target and implementability.

[0095] See Figure 8 The configuration item association process in step S304 can be implemented through the following steps S401 to S405.

[0096] S401, Assign a target configuration version identifier to the target resource configuration.

[0097] The target configuration version identifier uniquely identifies the complete resource configuration to be submitted. This identifier can be a combination of the terminal identifier, configuration sequence number, and generation time, or it can use a locally monotonically increasing version sequence number. The lifecycle of a configuration version can include draft, validated, pending submission, active, rollback, and expired states.

[0098] The target configuration version identifier differs from the parameter number of a single resource item. Sampling, buffering, scheduling, and communication configuration items belonging to the same resource switch share the target configuration version identifier, enabling the terminal to determine whether different configuration items belong to the same target state.

[0099] S402, write the configuration items in the target resource configuration item set into the configuration area corresponding to the target configuration version identifier to obtain the version resource configuration item set.

[0100] The configuration area can be a transaction workspace in memory, a hardware shadow configuration area, a spare descriptor area, or a candidate parameter area for system services. Before a configuration to be committed is formed, the configuration area is isolated from the currently active configuration area, and the target configuration items written into it will not directly affect the current business.

[0101] The version resource configuration item collection stores the correspondence between the target configuration version identifier and each target resource configuration item. Each configuration item can carry the resource category, execution object, preparation status, commit status, and verification status to locate resource items that are not ready or have failed to commit.

[0102] S403, determine resource dependencies based on the set of version resource configuration items.

[0103] Resource dependencies are used to indicate the status of other configuration items that must be satisfied before a configuration item takes effect. For example, a data transfer descriptor points to a target cache space, so the target cache space needs to be allocated first; a communication queue processes fault summaries, so the corresponding communication queue only has complete business input after the fault summary task obtains the execution conditions.

[0104] S404, Generate an atomic commit sequence based on the resource dependency relationship.

[0105] An atomic commit sequence is a set of configuration commit actions arranged according to resource dependencies. An atomic commit sequence can include a commit group identifier, configuration items within the group, resource switching boundaries, inter-group order, completion flags, and failure handling entries. Atomicity here means that the target configuration is visible to end-user applications as a complete version, without requiring simultaneous physical writes to different hardware registers.

[0106] In one possible implementation of this application, the power terminal can generate a configuration summary for a set of version resource configuration items, and write the configuration summary, the current active version, and the target configuration version together into a transaction record. The configuration summary is verified before commit, the active version is verified after commit, and the current active version in the record is reactivated during rollback. This method can identify specific issues such as accidental overwriting of configuration areas, missing configuration items, or incorrect version references, and improves the verifiability of version recovery.

[0107] S405, associate the set of version resource configuration items, the target configuration version identifier, and the atomic commit sequence to obtain the configuration to be committed.

[0108] The configuration to be committed consists of the target resource content, version identity, and commit order. The configuration to be committed is set to a committable state only when all necessary configuration items in the version resource configuration item set are in a ready state and the atomic commit sequence covers the corresponding configuration items.

[0109] As can be seen, in this example, organizing scattered configuration items into a complete resource state by using the target configuration version identifier, and then determining the atomic commit sequence based on resource dependencies, helps prevent resource configuration items of different versions from taking effect simultaneously within the same business cycle.

[0110] See Figure 9 The resource dependency determination process in step S403 can be implemented through the following steps S501 to S503.

[0111] S501, extract the sampling trigger configuration item, data transfer configuration item and cache configuration item from the set of version resource configuration items, and determine the collection dependency relationship according to the corresponding data generation and writing order.

[0112] Among them, the sampling trigger configuration item determines the generation rhythm of sampling data, the data transport configuration item determines the target location and transport block boundary for writing sampling data, and the cache configuration item determines the writable area, frozen area, and read / write location. The power terminal determines the acquisition dependency relationship according to the actual data path between sampling trigger, data transport, and cache writing.

[0113] When both the target sampling rate and the target cache address change, the target cache can be made writable first, then the data migration configuration items can be prepared, and finally the sampling trigger configuration items and active data migration descriptors can be updated at the resource switching boundary. This sequence can prevent newly sampled data from being written to a cache area that has not yet been prepared.

[0114] S502, extract scheduling configuration items and communication configuration items from the set of version resource configuration items, and determine service dependencies based on the data processing and sending order of terminal services.

[0115] The scheduling configuration items determine the execution order of fault diagnosis, protection control, waveform recording and storage, and alarm coding tasks. The communication configuration items determine the transmission order of critical data, complete waveform recording data, and low-priority data. The power terminal determines service dependencies based on the processing chain of entering the fault diagnosis task with sampled data, entering the alarm coding task with the fault diagnosis results, and entering the communication queue with the alarm coding results.

[0116] S503, merge the acquisition dependency and the business dependency to obtain the resource dependency.

[0117] The merge operation can connect the data collection dependencies and business dependencies corresponding to the same configuration item and check for mutual waits. If a circular wait is detected, the relevant configuration items can be placed into the same commit group, or the order of configuration items that do not affect business semantics can be adjusted until an executable resource dependency relationship is formed.

[0118] In one possible implementation of this application, when multiple events occur concurrently, the primary event can be determined first based on its severity, and then the resource requirements proposed by other valid events can be written into candidate resource items. For the same resource item, parameters that do not degrade critical business assurance are used as the merging result; for different resource items, dependencies are re-established according to data paths and business paths. This approach can solve the problem that selecting only the highest event level may ignore the segmentation of resource requirements for other types of events, and maintains the verifiability of the execution order of the final configuration.

[0119] As can be seen, in this example, resource dependencies are determined from two directions: the sampling data path and the terminal service path, so that the atomic submission sequence can simultaneously meet the timing requirements of data generation, data writing, task processing, and data transmission.

[0120] See Figure 10 The atomic submission sequence generation process in step S404 can be implemented through the following steps S601 to S603.

[0121] S601, based on the resource dependency relationship, divide the configuration items in the version resource configuration item set into at least two groups: the collection submission group, the scheduling submission group, and the communication submission group.

[0122] The data collection submission group can include configuration items related to sampling triggering, data transfer, and cache address; the scheduling submission group can include configuration items for task priority, interrupt priority, and execution quota; and the communication submission group can include configuration items for queue level, channel selection, and flow control. Configuration items belonging to the same submission group must share common activation conditions or remain consistent at the business observable level.

[0123] The number of submission groups can be determined based on the resource categories included in the target resource configuration. When the target resource configuration only adjusts sampling and caching, a collection submission group and a scheduling submission group corresponding to the cache consumer can be formed; when the target resource configuration also adjusts communication resources, a communication submission group is added.

[0124] S602, set the resource switching boundary as the submission trigger condition, arrange each submission group according to the resource dependency relationship, and obtain the submission sequence to be confirmed.

[0125] Before the resource switching boundary is reached, all submission groups remain invisible or inactive. After the resource switching boundary is reached, the acquisition submission group can be activated first, followed by the scheduling submission group, and then the communication submission group. The specific order is determined by resource dependencies and is not limited to a fixed number of groups.

[0126] In one possible implementation of this application, a two-stage visibility control method can be adopted. The first stage writes the parameters of each submission group into the shadow region, alternate descriptor, or candidate parameter table, and sets the preparation completion status accordingly. The second stage switches the active version pointer at the resource switching boundary, making the completed submission groups visible sequentially according to the pending confirmation sequence. For hardware resources that cannot be written to at once, this method still prevents terminal services from reading configurations that are a mix of old and new versions, thereby solving the problem of fragmented writing across hardware resources that is difficult to physically synchronize.

[0127] S603, set the target configuration version identifier at the end of the commit sequence to be confirmed, and obtain the atomic commit sequence.

[0128] The target configuration version identifier is located at the end of the pending commit sequence, indicating that the preceding commit group has been completed. If any preceding commit group fails, the target configuration version identifier is not set, and the terminal service continues to identify the current active version or enters the rollback process. When all commit groups are completed, the target configuration version identifier is set, forming the completion status of the atomic commit sequence.

[0129] As can be seen, in this example, grouping configuration items according to resource dependencies and starting to commit at the resource switch boundary, and only opening the target configuration version after all necessary commit groups are completed, helps to maintain the consistency of resource state across layers.

[0130] See Figure 11 The fault recording process after determining the state of the target event can be implemented through the following steps S701 to S704.

[0131] S701, when the target event state meets the fault recording conditions, determine the event time and the recording window before the fault.

[0132] The fault recording conditions can include the establishment of a severe abnormal state, the establishment of an emergency protection state, protection input actions, or manual triggering of recording. The event time can be the first valid sampling time that triggers the fault recording condition, or the time when the highest priority criterion among multiple relevant criteria is met. The pre-fault recording window is used to limit the range of historical data that needs to be retained from before the event time.

[0133] The circular cache continuously writes sampled data during normal operation, overwriting earlier data in the order it is written. Each data block can carry the first sample number, last sample number, start time, end time, and configuration version, so that the data range before the failure can be located according to the time of the event after an event occurs.

[0134] S702, based on the event time and the pre-fault recording window, determine the pre-fault data interval in the circular buffer, set the pre-fault data interval to read-only, obtain the frozen data segment, and update the data transfer descriptor so that the write pointer avoids the pre-fault data interval and points to the double buffer.

[0135] The power terminal searches backwards from the event time to find the data block covering the waveform recording window before the fault, and sets the corresponding data block to an unwriteable state, thus forming a frozen data segment. The freezing operation can be implemented through read-only marking, reference counting, or a frozen interval table.

[0136] When updating the target data transfer descriptor, the target address of subsequent data can be switched from the circular cache to a double buffer, while retaining the sampling rate, configuration version, and timestamps corresponding to the frozen data segment. After the write pointer avoids the data range before the failure, subsequent high-sampling-rate data will not overwrite the pre-failure data that needs to be retained.

[0137] S703, according to the target resource configuration, the post-fault sampling data is alternately written to the dual buffer, and the data in the dual buffer is segmented and written to the non-volatile memory to obtain the post-fault data segment.

[0138] The dual buffer consists of a first buffer and a second buffer. When the data transport component writes to the first buffer, the processing task can read the already full second buffer; after the data transport component switches to the second buffer, the processing task reads the first buffer. The processing task writes data to the non-volatile storage component 116 in the order of data blocks and records the sampling sequence number range, time range, and write verification result of each data block.

[0139] As a concrete example, the power terminal can store the data for the three seconds prior to a fault across six channels at a sampling rate of 10 kHz per channel under normal conditions, with the original sampled data occupying approximately 360 kilobytes. After an event occurs, the sampling rate increases to 100 kHz per channel, and the data for the ten seconds following the fault is alternately written to the non-volatile memory component 116 through two 64 kilobyte buffers. Thus, the on-chip cache with a capacity of no less than 512 kilobytes can primarily store the pre-fault window and the double buffers, while the high-sampling-rate data after the fault is continuously carried by the non-volatile memory component 116.

[0140] If the continuous write capability of the non-volatile storage component 116 is insufficient, the target resource configuration can shorten the post-failure recording window, use downsampled replicas, or prioritize the retention of critical channels, while recording the adjusted recording parameters in the resource scheduling results. The adjustment operation should undergo legality verification during the resource pre-configuration phase.

[0141] S704, combine the frozen data segment and the post-fault data segment in chronological order, and output the fault waveform file.

[0142] The power terminal connects the frozen data segment with the post-fault data segment based on the sampling sequence number, timestamp, and event time, and records the sampling rate change and configuration version change at the connection point. The fault recording file may include a file header, channel description, event description, pre-fault data, post-fault data, data verification information, and resource switching records.

[0143] As can be seen in this example, a circular buffer is used to retain limited historical data during the normal phase, and the historical window is frozen and continuously written to disk through double buffering during the fault phase. This ensures that the data before and after the fault has traceable time and version information, which helps to improve the integrity of waveform recording and control on-chip cache usage.

[0144] See Figure 12 The communication scheduling process after the stability confirmation is passed can be implemented through the following steps S801 to S803.

[0145] S801, Obtain the data to be sent, and mark the data to be sent according to the urgency of the business to obtain a hierarchical data queue.

[0146] The data to be sent can be categorized according to the urgency of the business into protection action data, fault summary data, complete waveform data, routine telemetry data, and log maintenance data. Protection action data can have the highest priority, fault summary data can have the second highest priority, complete waveform data will receive bandwidth after critical data is sent, and routine telemetry and log maintenance data can have their transmission frequency reduced or be paused during high-level events.

[0147] Hierarchical data queues can maintain separate queue heads, expiration periods, retry counts, and channel candidates for different priorities. For critical data with expiration periods, its transmission weight can be increased when the remaining validity time decreases; for low-priority data that allows retransmission, the data index can be retained and transmission can resume after the event is resolved.

[0148] S802, determine the channel allocation strategy and flow control strategy of the hierarchical data queue based on the communication resource parameters in the target resource configuration.

[0149] Channel allocation policies specify the communication channels, transmission order, and backup channels corresponding to data of different priorities. Flow control policies specify queue bandwidth allocation, transmission frequency, packet size, retries, and pause conditions. Higher priority target events can be assigned higher transmission weights to critical data, while tightening the transmission conditions for low-priority data.

[0150] S803, according to the channel allocation strategy, extract key data and complete waveform data from the hierarchical data queue, send the key data through the first communication channel, send the complete waveform data through the second communication channel, and restrict or suspend the transmission of low-priority data according to the flow control strategy, and output the communication scheduling result; wherein, the key data includes at least one of protection action information and fault summary, the transmission delay of the first communication channel is lower than that of the second communication channel, and the transmission bandwidth of the second communication channel is higher than that of the first communication channel.

[0151] The first and second communication channels are upper-level channels defined according to transmission performance. The first communication channel can use CAN-FD, a deterministic channel in a time-sensitive network, or other low-latency links; the second communication channel can use Ethernet, a wireless broadband link, or other high-throughput links. In one implementation, protection action information and fault summaries are first transmitted via CAN-FD, and the complete waveform data is then transmitted in segments via Ethernet.

[0152] When the second communication channel is congested or interrupted, complete waveform data can be stored in a reliable transmission queue, recording the position of each transmitted segment. After the link is restored, the power terminal continues transmission according to priority and segment position. The communication scheduling result can include the transmission status, channel, queuing time, retry status, and retransmission position of each data item.

[0153] As can be seen, in this example, matching critical data and large-capacity data to communication channels with different performance levels, and allowing low-priority services to fall back according to event status, helps improve the determinism of critical alarm transmission and maintain the subsequent transmission capability of complete waveform data.

[0154] See Figure 13The resource recovery process after outputting the resource scheduling results can be achieved through the following steps S901 to S905.

[0155] S901, obtain the event release status and critical data preservation status.

[0156] The event resolution status indicates whether the valid event that triggered the current target event status has been resolved. To avoid the judgment value changing around the threshold, different judgment thresholds can be used for the event escalation condition and the event resolution condition, and a number of consecutive times the event resolution condition is met can be set. The critical data preservation status indicates whether the fault summary, waveform data, and switching records have been entered into non-volatile storage or a reliable upload queue with persistent guarantees.

[0157] The resolution of an event does not directly equate to an immediate reduction in resource levels. If waveform recording has not yet been completed after the fault, critical data is still in volatile buffers, or the target resource configuration is still occupied by protection tasks, the critical data preservation status remains incomplete, and the power terminal continues to maintain the current resource configuration.

[0158] S902, when the event release state indicates that the target event has been released and the key data preservation state indicates that the key data has entered the non-volatile memory or reliable upload queue, start the retention timer and obtain the retention result.

[0159] The hold timer starts counting when both the event termination and critical data preservation conditions are met simultaneously. If either condition fails during the timing period, the timer can be paused or reset. The hold duration can be extended as the current event level increases, allowing higher-level events more sufficient time for stable observation. Hold results include the timing status, cumulative stable time, and whether the preset hold duration has been reached.

[0160] S903, when the retention result representation reaches the preset retention time, determine the back-cut resource configuration corresponding to the adjacent low-level event state according to the association relationship.

[0161] The adjacent low-level event state is an event state that is one level lower than the current state in the normal direction. When a power terminal recovers from the emergency protection state, it can first enter the resource configuration corresponding to the abnormal fault state; when recovering from the abnormal fault state, it can first enter the resource configuration corresponding to the early warning enhancement state; and then enter the resource configuration corresponding to the normal monitoring state.

[0162] Resource rollback configurations can restore non-critical services in the reverse order of resource fallback. For example, during a high-level event, log frequency reduction, telemetry rate limiting, and remote upgrade suspension are executed sequentially. During rollback, telemetry can be restored first, followed by logs, and finally remote upgrades can be enabled to avoid sudden increases in processing load and communication traffic.

[0163] S904, generate a backswing transaction according to the backswing resource configuration and switch it level by level to obtain the backswing scheduling result.

[0164] The rollback transaction can adopt the same pending commit, rollback, boundary commit, and stability confirmation mechanisms as the configuration switchover transaction. After each rollback level is completed, the power terminal re-collects the operating status and determines whether to allow entry into the next lower-level state. The rollback scheduling result records the completed rollback level, the current configuration version, resources that have not yet been released, and the conditions for the next decision.

[0165] S905, when an event is detected to be more severe during the step-by-step handover, the back-off transaction is terminated, the target event status is redefined and the corresponding configuration handover transaction is executed, and the back-off scheduling result is updated.

[0166] Restoring the rollback state is not a locked state that prevents event escalation. During the rollback, the power terminal continues to perform event detection. When a valid event with a severity higher than the current rollback target appears in the event state set 520, the rollback action that has not yet been committed is immediately stopped. If the first-level rollback has been committed, the current effective configuration is used as the new current resource configuration, and a configuration switching transaction 550 corresponding to the new target event state is generated.

[0167] In one possible implementation of this application, the power terminal can maintain separate state generations for upgrades and rollbacks. When a rollback transaction is initiated, the current event generation is recorded, and the event generation is compared again before the rollback is committed. If the event generation has changed, the old rollback transaction is discarded, and a new transaction is generated according to the latest event state. This approach avoids the subdivision problem of earlier-generated rollback transactions continuing to be committed after new events occur.

[0168] As can be seen, in this example, event resolution, critical data preservation, and stability maintenance are the common conditions for step-by-step rollback, and the ability to quickly upgrade is retained during the rollback. This helps to suppress resource level fluctuations and avoids the rollback action from weakening the critical business assurance of newly occurring events.

[0169] See Figure 14 The power terminal event-driven dynamic resource scheduling system 1400 includes an operation status acquisition module 1410, an event status determination module 1420, a resource configuration determination module 1430, a configuration switching module 1440, and a stability confirmation module 1450. Each module can be implemented by a program function unit in the power terminal, or by a combination of software and configurable hardware.

[0170] The operating status acquisition module 1410 is used to acquire terminal operating status information, which includes electrical status, equipment status, communication status and service load status.

[0171] The runtime status acquisition module 1410 can receive status information from the device driver, event bus, task monitoring service, and communication monitoring service, and attach source, acquisition time, validity period, and quality identifier to each status. The terminal runtime status information output by the runtime status acquisition module 1410 is used for subsequent processing by the event status determination module 1420.

[0172] The event status determination module 1420 is used to determine the target event status based on the terminal running status information.

[0173] The event status determination module 1420 can perform status filtering, debouncing, hierarchical classification, comprehensive judgment, and mandatory rule judgment. For multiple concurrent events, the event status determination module 1420 can output the status of the main event, the target event, and related events that are still valid, enabling the resource configuration determination module 1430 to select the target resource configuration that meets the current business requirements.

[0174] The resource configuration determination module 1430 is used to determine the target resource configuration based on the target event state and the preset association between the event state and the resource configuration. The target resource configuration includes at least two types of resource parameters among sampling resources, cache resources, scheduling resources and communication resources.

[0175] The resource configuration determination module 1430 can manage multiple configuration versions and select the target resource configuration from candidate configurations based on terminal type, event type, and hardware capabilities. The resource configuration determination module 1430 can also perform source verification, version verification, and parameter validity verification on remotely distributed configurations, updating the association relationships only after the verifications pass.

[0176] The configuration switching module 1440 is used to generate a configuration switching transaction based on the target resource configuration, and to switch the current resource configuration to the target resource configuration through the configuration switching transaction to obtain the resource status after the switch.

[0177] The configuration switching module 1440 may include resource pre-configuration functionality, version resource configuration item association functionality, resource dependency determination functionality, and atomic commit control functionality. The configuration switching module 1440 commits the target resource configuration at the resource switching boundary and retains the rollback entry corresponding to the current resource configuration until stability confirmation is complete.

[0178] The stability confirmation module 1450 is used to acquire handover verification data, perform stability confirmation on the post-handover resource status based on the handover verification data, control terminal services according to the target resource configuration when the confirmation is successful, and restore the current resource configuration through the configuration handover transaction when the confirmation is unsuccessful, and output resource scheduling results.

[0179] The stability verification module 1450 can verify the sampling sequence number, timestamp, buffer read / write location, configuration version, critical task status, and communication queue status. Upon successful verification, the stability verification module 1450 enables the terminal services corresponding to the target resource configuration; upon unsuccessful verification, the stability verification module 1450 triggers a rollback and generates a resource scheduling result containing abnormal resource items and the failure phase.

[0180] The operation status acquisition module 1410, event status determination module 1420, resource configuration determination module 1430, configuration switching module 1440, and stability confirmation module 1450 are connected sequentially according to the processing results, so that the terminal operation status, event status, target resource configuration, post-switching resource status, and resource scheduling results form a closed loop, thereby realizing the power terminal event-driven dynamic resource scheduling method described in any of the aforementioned embodiments.

[0181] This application also provides a computer storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0182] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0184] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above 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 coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0185] The units described above 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.

[0186] Furthermore, the functional units in the various embodiments of this application 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.

[0187] If the aforementioned integrated units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0188] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0189] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A power terminal event-driven dynamic resource scheduling method, applied to power terminals, characterized in that, The method includes: Obtain terminal operating status information, which includes electrical status, equipment status, communication status, and service load status; The target event status is determined based on the terminal's operating status information; Obtain the association between preset event states and resource configurations, and determine the target resource configuration based on the target event state and the association. The target resource configuration includes at least two types of resource parameters among sampling resources, cache resources, scheduling resources, and communication resources. A configuration switching transaction is generated based on the target resource configuration. The current resource configuration is switched to the target resource configuration through the configuration switching transaction to obtain the resource status after the switch. Obtain switching verification data, and perform stability confirmation on the resource status after the switch based on the switching verification data. If the confirmation is successful, control the terminal service according to the target resource configuration. If the confirmation fails, restore the current resource configuration through the configuration switching transaction, and output the resource scheduling result.

2. The method according to claim 1, characterized in that, The step of generating a configuration switching transaction based on the target resource configuration, and switching the current resource configurations to the target resource configuration through the configuration switching transaction to obtain the resource status after the switch includes: Based on the target resource configuration, perform resource pre-configuration to obtain the configuration to be submitted; Record the current resource configuration to obtain the rollback configuration; The configuration to be committed and the configuration to be rolled back are encapsulated into the configuration switching transaction; In response to the resource switching boundary, the configuration to be submitted is submitted to the corresponding hardware resources and system services through the configuration switching transaction, and the rollback configuration is retained to obtain the resource status after the switch. The resource switching boundary includes the sampling frame boundary or the data transport block boundary.

3. The method according to claim 2, characterized in that, The step of pre-configuring resources based on the target resource configuration to obtain the configuration to be submitted includes: Extract the resource control parameter set from the target resource configuration; The validity of the resource control parameter group is verified based on the terminal hardware capabilities to obtain a valid parameter group; A target resource configuration item set is generated based on the effective parameter set, and the target resource configuration item set includes at least two of the following: target cache space, target data transport descriptor, target scheduling parameter table, and target communication queue policy. The configuration items in the target resource configuration item set are associated to obtain the configuration to be submitted.

4. The method according to claim 3, characterized in that, The process of associating configuration items in the target resource configuration item set to obtain the configuration to be submitted includes: Assign a target configuration version identifier to the target resource configuration; Write the configuration items in the target resource configuration item set into the configuration area corresponding to the target configuration version identifier to obtain the version resource configuration item set; Resource dependencies are determined based on the set of version resource configuration items; Generate an atomic commit sequence based on the resource dependencies; The configuration to be committed is obtained by associating the set of version resource configuration items, the target configuration version identifier, and the atomic commit sequence.

5. The method according to claim 4, characterized in that, The step of determining resource dependencies based on the set of version resource configuration items includes: Extract sampling trigger configuration items, data transfer configuration items, and cache configuration items from the set of version resource configuration items, and determine the collection dependency relationship according to the corresponding data generation and writing order; Extract scheduling configuration items and communication configuration items from the set of version resource configuration items, and determine service dependencies based on the data processing and transmission order of terminal services; The resource dependency is obtained by merging the data acquisition dependency and the business dependency.

6. The method according to claim 5, characterized in that, The step of generating the atomic commit sequence based on the resource dependency relationship includes: Based on the resource dependencies, the configuration items in the set of version resource configuration items are divided into at least two groups: the collection submission group, the scheduling submission group, and the communication submission group. Set the resource switching boundary as the commit trigger condition, arrange each commit group according to the resource dependency relationship, and obtain the commit sequence to be confirmed. The target configuration version identifier is set at the end of the commit sequence to be confirmed, thus obtaining the atomic commit sequence.

7. The method according to any one of claims 1 to 6, characterized in that, After determining the state of the target event, the method further includes: When the target event state meets the fault recording conditions, the event time and the recording window before the fault are determined. Based on the event time and the pre-fault waveform recording window, determine the pre-fault data interval in the circular buffer, set the pre-fault data interval to read-only to obtain the frozen data segment, and update the data transfer descriptor so that the write pointer avoids the pre-fault data interval and points to the double buffer. According to the target resource configuration, the post-fault sampling data is alternately written to the double buffer, and the data in the double buffer is segmented and written to the non-volatile memory to obtain the post-fault data segment. Combine the frozen data segment and the post-fault data segment in chronological order to output a fault waveform file.

8. The method according to any one of claims 1 to 6, characterized in that, Upon confirmation of success, the method further includes: Obtain the data to be sent, and mark the data to be sent according to the urgency of the business to obtain a hierarchical data queue; Based on the communication resource parameters in the target resource configuration, determine the channel allocation strategy and flow control strategy for the hierarchical data queue; According to the channel allocation strategy, key data and complete waveform data are extracted from the hierarchical data queue. The key data is sent through the first communication channel, and the complete waveform data is sent through the second communication channel. The transmission of low-priority data is restricted or suspended according to the flow control strategy, and the communication scheduling result is output. The key data includes at least one of protection action information and fault summary, wherein the transmission delay of the first communication channel is lower than that of the second communication channel, and the transmission bandwidth of the second communication channel is higher than that of the first communication channel.

9. The method according to any one of claims 1 to 6, characterized in that, After outputting the resource scheduling result, the method further includes: Get the event resolution status and critical data preservation status; When the event release state indicates that the target event has been released and the key data preservation state indicates that the key data has entered the non-volatile memory or reliable upload queue, the retention timer is started to obtain the retention result. When the retention result representation reaches the preset retention time, the back-cut resource configuration corresponding to the adjacent low-level event state is determined according to the correlation relationship; Based on the aforementioned rollback resource configuration, a rollback transaction is generated and switched step by step to obtain the rollback scheduling result; If an event is detected to be more severe during the step-by-step handover, the handover transaction is terminated, the target event state is redefined, the corresponding configuration handover transaction is executed, and the handover scheduling result is updated.

10. A power terminal event-driven dynamic resource scheduling system, characterized in that, include: The operation status acquisition module is used to acquire terminal operation status information, which includes electrical status, equipment status, communication status and service load status. An event status determination module is used to determine the target event status based on the terminal operating status information. The resource configuration determination module is used to determine the target resource configuration based on the target event state and the preset correlation between the event state and the resource configuration. The target resource configuration includes at least two types of resource parameters among sampling resources, cache resources, scheduling resources and communication resources. The configuration switching module is used to generate a configuration switching transaction based on the target resource configuration, and to switch the current resource configuration to the target resource configuration through the configuration switching transaction to obtain the resource status after the switch. The stability confirmation module is used to acquire handover verification data, perform stability confirmation on the post-handover resource status based on the handover verification data, control terminal services according to the target resource configuration when the confirmation is successful, and restore the current resource configuration through the configuration handover transaction when the confirmation fails, and output resource scheduling results.

Images