Automatic script-based power supply mode switching system and method
By using an automated script-based power mode switching system, combined with dual-mode verification and a time-driven workflow, the system solves the problem of low efficiency in traditional power mode switching, achieving efficient and reliable power mode switching and stability monitoring, and reducing operation and maintenance costs.
Patent Information
- Application Number
- CN202511046834.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-29
- Publication Date
- 2025-11-11
AI Technical Summary
Traditional power mode switching is inefficient and lacks automated verification mechanisms, resulting in high labor costs, delayed fault response, and increased operational error rates.
An automated script-based power mode switching system is adopted, including a loop control module, an API operation encapsulation module, an SSH security monitoring module, and a time-driven engine, to realize a dual-mode verification and time-driven workflow. Combined with a log tracing system, it enables precise switching and stability monitoring.
It achieves efficient and reliable power mode switching, reduces operation and maintenance costs, improves fault response speed and fault location efficiency, and ensures the stability and reliability of power modes.
Smart Images
Figure CN120929332A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of power mode switching technology, specifically to a power mode switching system and method based on automated scripts. Background Technology
[0002] Traditional power mode switching faces numerous challenges in practical applications. First, manual operation is inefficient, requiring on-site technicians for mechanical parameter adjustments and failing to support stability testing demands lasting hours or even days. Second, the industry generally lacks effective automated verification mechanisms; each mode switch necessitates manual verification of equipment status, parameter configurations, and functional performance, increasing labor costs due to this offline approach. Finally, maintenance personnel must frequently switch between monitoring platforms and operating interfaces, hindering real-time linkage between status data and control commands, leading to delayed fault response and increased operational error rates. Summary of the Invention
[0003] To help solve the above-mentioned technical problems, this application provides a power mode switching system and method based on automated scripts.
[0004] In the first aspect, this application provides a power mode switching system based on automated scripts, which adopts the following technical solution; A power mode switching system based on automated scripts, comprising: The loop control module is configured to execute a test loop N times, where N is a positive integer. The API operation encapsulation module is used to encapsulate power switching requests to switch power modes and verify the power mode switching results. The SSH security monitoring module is connected to the API operation encapsulation module and is used to monitor the device process status after API verification is successful. The time-driven engine is configured to schedule the test process using a segmented time strategy: After the mode switch, a first time period is set for verifying the API mode switch result. After confirming the mode, a second time period is set up for monitoring the stability of the SSH process. When the API status query is successful and the SSH process status remains normal, a power mode switching success signal is output. When the API status query fails, SSH verification is skipped and the loop test is marked as failed. When the API status query is successful but the SSH process monitoring is abnormal, the current power mode is determined to be unstable.
[0005] Preferably, the loop control module generates an independent log file for each loop, and the power mode switching system based on automated scripts further includes an error handling module for adding timestamps to all operation steps and redirecting error output to the independent log file.
[0006] Preferably, the time-driven engine is further configured with a third time period, which is set between two adjacent cycles for system hibernation.
[0007] Preferably, the API operation encapsulation module includes: The unified request processing unit is configured to initiate power switching requests via GET / POST methods and automatically generate HTTP messages for power mode switching instructions. The response parsing unit is configured to extract the JSON data body of the API response and verify whether the status code is a preset success value; When the status code is abnormal, the error handling module is triggered to record the API verification failure event.
[0008] Preferably, the SSH security monitoring module includes: The passwordless login pre-check unit is configured to check the key pair configuration status before SSH connection. If the key is missing, the current loop is terminated and the SSH pre-check is marked as failed. The process status capture unit is configured to detect the liveness status of the target process and parse the list of process IDs returned by the command. When the list is empty, the process is determined to be abnormal. The connection timeout control unit is configured to force a timeout interruption of the SSH session for a preset timeout period.
[0009] Secondly, this application provides a power mode switching method based on automated scripts, employing the following technical solution: A power mode switching method based on automated scripts, wherein a power mode switching system based on automated scripts as described in any of the first aspects is employed, comprising the following steps: S1: The loop control module executes the test loop N times, where N is a positive integer; S2: Encapsulate the power switching request (RESTful API) through the API operation encapsulation module to switch the power mode and verify the power mode switching result; S3: Monitor the device process status through the SSH security monitoring module after API verification is successful; S4: The scheduling process is carried out according to the segmented time strategy through the time-driven engine: After the mode switch, set the first time period to perform API mode switch result verification; After API verification is successful, a second time period is set to perform SSH process stability monitoring. S5: When the API status query is successful and the SSH process status remains normal, output a power mode switching success signal; when the API status query fails, skip SSH verification and mark the loop test as failed; when the API status query is successful but the SSH process monitoring is abnormal, determine that the current power mode is unstable.
[0010] Preferably, in step S1, an independent log file is generated in each loop. The power mode switching method based on automated scripts further includes step S6: adding timestamps to all operation steps through the error handling module and redirecting error output to the independent log file.
[0011] Preferably, S4 further includes setting a third time period for system hibernation between two adjacent cycles.
[0012] Preferably, S2 includes: Initiate a power switching request using the GET / POST method and generate an HTTP message containing the power mode switching instruction; Extract the JSON data body of the API response and verify whether the status code is the preset success value; When the status code is abnormal, an error handling step is triggered to record the API verification failure event.
[0013] Preferably, S3 includes: Before connecting to the SSH connection, check the key pair configuration status. If the key is missing, terminate the current loop and mark the SSH preflight as failed. Detect the liveness status of the target process and parse the returned list of process IDs; If the list is empty, the process is considered abnormal, and the SSH session is forced to be interrupted after a preset timeout period.
[0014] In summary, compared with the prior art, this application has the following beneficial effects: 1. Dual-mode authentication mechanism: Simultaneously authenticates the API return status and the SSH remote process status to avoid failure of single authentication.
[0015] 2. Time-driven workflow engine: Precisely controls the rhythm of mode switching, simulating real-world usage scenarios.
[0016] 3. Log traceability system: a three-level recording system consisting of main log, circular log, and timestamp. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating an embodiment of a power mode switching method based on automated scripts according to this application. Detailed Implementation
[0018] The present application will be further described below with reference to the accompanying drawings. The structure and principle of the present application are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
[0019] This application is mainly implemented through a three-tier architecture: 1. Control Layer: Encapsulates RESTful API operations to enable precise switching of power modes. 2. Authentication Layer: Integrates a dual authentication mechanism (API status query + SSH process monitoring) 3. Scheduling Layer: A time-driven workflow engine that controls the rhythm of cyclical testing. The log traceability system records the timestamp and result of each operation node, forming a complete chain of test evidence.
[0020] The specific implementation includes five key technical modules: 1. Circulation control system Precise control of 100 test cycles Each loop generates a separate log file, making it easier to pinpoint a specific loop test process. The main log, power_mode_7200_logs, aggregates key operation records. 2. Time-Driven Engine Segmented time control: 1 minute (mode switch confirmation) + 5 minutes (stable operation) + 5 minutes (stable operation after mode switch) + 5 minutes (cycle interval). A visual progress bar is implemented to intuitively display the test progress. 3. API operation encapsulation The unified request handling function supports GET / POST methods. Automatic JSON parsing and status validation 4. SSH security monitoring Password-free login pre-screening mechanism pgrep process detection 5. Error handling system Operation steps timestamp identifier Error output redirected to log SSH connection 10-second timeout control Specifically, the power mode switching system based on automated scripts of this application includes: The loop control module is configured to execute a test loop N times, where N is a positive integer. The API operation encapsulation module is used to encapsulate power switching requests to switch power modes and verify the power mode switching results. The SSH security monitoring module and the API operation encapsulation module are used to monitor the device process status after API authentication is successful. The time-driven engine is configured to schedule the test process using a segmented time strategy: After the mode switch, a first time period is set for verifying the API mode switch result. After confirming the mode, a second time period is set up for monitoring the stability of the SSH process. When the API status query is successful and the SSH process status remains normal, a power mode switching success signal is output. When the API status query fails, SSH verification is skipped and the loop test is marked as failed. When the API status query is successful but the SSH process monitoring is abnormal, the current power mode is determined to be unstable.
[0021] The loop control module generates an independent log file for each loop. The power mode switching system based on automated scripts also includes an error handling module, which adds timestamps to all operation steps and redirects error output to an independent log file.
[0022] The time-driven engine is also equipped with a third time period, which is set between two adjacent cycles for system hibernation.
[0023] The API operation encapsulation module includes: The unified request processing unit is configured to initiate power switching requests via GET / POST methods and automatically generate HTTP messages for power mode switching instructions. The response parsing unit is configured to extract the JSON data body of the API response and verify whether the status code is a preset success value; When the status code is abnormal, the error handling module is triggered to record the API verification failure event.
[0024] The SSH security monitoring module includes: The passwordless login pre-check unit is configured to check the key pair configuration status before SSH connection. If the key is missing, the current loop is terminated and the SSH pre-check is marked as failed. The process status capture unit is configured to detect the liveness status of the target process and parse the list of process IDs returned by the command. When the list is empty, the process is determined to be abnormal. The connection timeout control unit is configured to force a timeout interruption of the SSH session for a preset timeout period.
[0025] If SSH process monitoring is performed first, the process may be incorrectly judged as abnormal (false negative) because the mode switch is not completed. Relying solely on API verification cannot detect the actual running status of system processes after mode switching (false positives). A strict timing requirement dictates that API status verification be completed first (to confirm successful mode switching), followed by SSH process monitoring (to confirm stable system operation), to avoid misjudgments caused by incorrect verification order.
[0026] In traditional solutions, API verification and SSH monitoring operate independently, which may lead to contradictory results (such as the API returning success but the process crashing). A collaborative judgment mechanism requires that the results of the two levels of verification be analyzed together (API success + SSH normal = stability confirmation) to plug the vulnerability of passing only one verification.
[0027] During separation verification, manual comparison of API logs and SSH logs is required to pinpoint the time consumed by the fault. Timestamp synchronization records: API results and SSH results are associated with the same operation node, enabling precise fault tracing.
[0028] This application also proposes a power mode switching method based on automated scripts, which employs the aforementioned power mode switching system based on automated scripts. Figure 1 This is a flowchart illustrating an embodiment of a power mode switching method based on automated scripts according to this application.
[0029] The method includes the following steps: S1: Execute the test loop N times through the loop control module, where N is a positive integer; S2: Encapsulate the power switching request through the API operation encapsulation module to switch the power mode and verify the power mode switching result; S3: Monitor device process status via the SSH security monitoring module after API verification is successful; S4: Scheduling process using a time-driven engine and a segmented time strategy: After the mode switch, set the first time period to perform API mode switch result verification; After API verification is successful, a second time period is set to perform SSH process stability monitoring. S5: When the API status query is successful and the SSH process status remains normal, output a power mode switching success signal; when the API status query fails, skip SSH verification and mark the loop test as failed; when the API status query is successful but the SSH process monitoring is abnormal, determine that the current power mode is unstable.
[0030] In S1, an independent log file is generated for each loop. The power mode switching method based on automated scripts also includes S6: adding timestamps to all operation steps through the error handling module and redirecting error output to an independent log file.
[0031] S4 also includes: setting a third time period for system hibernation between two adjacent cycles.
[0032] S2 includes: initiating a power switching request via GET / POST methods and generating an HTTP message for power mode switching instructions; extracting the JSON data body of the API response and verifying whether the status code is a preset success value; and triggering error handling steps to record API verification failure events when the status code is abnormal.
[0033] S3 includes: checking the key pair configuration status before SSH connection; if the key is missing, terminating the current loop and marking SSH preflight failure; detecting the target process's liveness status and parsing the returned process ID list; determining the process is abnormal when the list is empty and forcibly executing a timeout interruption with a preset timeout period on the SSH session.
[0034] Specifically, the method includes: 1. Start-up and Pre-inspection Phase The process begins with environment initialization, first performing a pre-check for SSH passwordless login configuration. If passwordless login fails, the process terminates immediately with an error message; otherwise, it enters the main loop structure.
[0035] 2. Automated Cyclic Testing Phase The system enters 100 (N) loop tests, each loop containing: Status query and switching: After obtaining the initial status via the GET API, the POST API switches to the specified mode (such as powersave). Verification and stabilization period switch: After waiting for 1 minute, the system will switch the verification mode via API, and then enter a 5-minute (first period) stable operation period. Mode reversal and secondary verification: Switch back to performance mode via API, wait 5 minutes (second period) and then perform final status verification.
[0036] 3. Remote monitoring and verification phase At the end of each loop, SSH remote operations are performed, including process status query, system information collection and CLI command execution, followed by a 5-minute interval waiting period (the third period).
[0037] 4. Cycle control and closing phase After completing a single loop, check the number of iterations. If the number of iterations is less than 100, the loop will automatically restart. Once all iterations are complete, output the total time statistics.
[0038] This process achieves unattended long-term stress testing through closed-loop control, effectively solving problems such as low efficiency and delayed verification in traditional manual operations, and forming a complete automated verification chain from mode switching to status confirmation.
[0039] In summary, this application has the following advantages: 1. Verification of a leap in reliability Improved dual authentication pass rate: Timing control ensures that SSH monitoring starts after mode switching is stable (avoiding interference during the transition period); The false negative rate approaches zero: the collaborative judgment mechanism requires both levels of verification to pass simultaneously (as defined in claim 5), making it impossible for anomalies to hide.
[0040] 2. Qualitative change in testing efficiency Unattended long-term testing: Automatically handles over 100,000 verification operations in 100 loop tests (100 times × (API + SSH) × 100 loops). Fault response speed: When API verification fails, the current loop is terminated immediately (skipping the SSH step), reducing unnecessary waiting time.
[0041] 3. Enhanced system robustness Error isolation: SSH connection timeout control (10 seconds) prevents a single authentication attempt from freezing the entire test process; Self-healing capability: Failure in a single loop does not affect subsequent tests, and the logging system automatically records the error context.
[0042] 4. Significantly reduced operation and maintenance costs Saves 90% of manual review time: Stability reports are automatically generated from dual verification results; Improved fault location efficiency: Quickly locate specific failure nodes in the Nth cycle by using timestamp-linked logs (such as power_mode_7200_logs).
[0043] The aforementioned "automation script" is not an abstract concept, but rather refers to something achieved through: Automated counting in the loop control module; Time-driven engine scheduling automation; Automating the operation of API / SSH modules; Automation of error handling system logging; This constitutes a complete closed loop of unattended execution. The core technology is to transform manual operation into a pre-set instruction sequence plus autonomous decision-making logic, ultimately achieving unattended testing.
Claims
1. A power mode switching system based on automated scripts, characterized in that, include: The loop control module is configured to execute a test loop N times, where N is a positive integer. The API operation encapsulation module is used to encapsulate power switching requests to switch power modes and verify the power mode switching results. The SSH security monitoring module is connected to the API operation encapsulation module and is used to monitor the device process status after API verification is successful. The time-driven engine is configured to schedule the test process using a segmented time strategy: After the mode switch, a first time period is set for verifying the API mode switch result. After confirming the mode, a second time period is set up for monitoring the stability of the SSH process. When the API status query is successful and the SSH process status remains normal, a power mode switching success signal is output. When the API status query fails, SSH verification is skipped and the loop test is marked as failed. When the API status query is successful but the SSH process monitoring is abnormal, the current power mode is determined to be unstable.
2. The power mode switching system based on automated scripts according to claim 1, characterized in that, The loop control module generates an independent log file for each loop. The power mode switching system based on automated scripts also includes an error handling module, which adds timestamps to all operation steps and redirects error output to the independent log file.
3. The power mode switching system based on automated scripts according to claim 1, characterized in that, The time-driven engine is also configured with a third time period, which is set between two adjacent cycles for system hibernation.
4. The power mode switching system based on automated scripts according to claim 1, characterized in that, The API operation encapsulation module includes: The unified request processing unit is configured to initiate power switching requests via GET / POST methods and automatically generate HTTP messages for power mode switching instructions. The response parsing unit is configured to extract the JSON data body of the API response and verify whether the status code is a preset success value; When the status code is abnormal, the error handling module is triggered to record the API verification failure event.
5. The power mode switching system based on automated scripts according to claim 1, characterized in that, The SSH security monitoring module includes: The passwordless login pre-check unit is configured to check the key pair configuration status before SSH connection. If the key is missing, the current loop is terminated and the SSH pre-check is marked as failed. The process status capture unit is configured to detect the liveness status of the target process and parse the list of process IDs returned by the command. When the list is empty, the process is determined to be abnormal. The connection timeout control unit is configured to force a timeout interruption of the SSH session for a preset timeout period.
6. A power mode switching method based on automated scripts, characterized in that, The power mode switching system based on automated scripts as described in any one of claims 1 to 5 includes the following steps: S1: The loop control module executes the test loop N times, where N is a positive integer; S2: Encapsulate the power switching request through the API operation encapsulation module to switch the power mode, and verify the power mode switching result; S3: Monitor the device process status through the SSH security monitoring module after API verification is successful; S4: The scheduling process is carried out according to the segmented time strategy through the time-driven engine: After the mode switch, set the first time period to perform API mode switch result verification; After API verification is successful, a second time period is set to perform SSH process stability monitoring. S5: When the API status query is successful and the SSH process status remains normal, output a power mode switching success signal; when the API status query fails, skip SSH verification and mark the loop test as failed; when the API status query is successful but the SSH process monitoring is abnormal, determine that the current power mode is unstable.
7. The power mode switching method based on automated scripts according to claim 6, characterized in that, In step S1, an independent log file is generated in each loop. The power mode switching method based on automated scripts also includes step S6: adding timestamps to all operation steps through the error handling module and redirecting error output to the independent log file.
8. The power mode switching method based on automated scripts according to claim 6, characterized in that, The S4 also includes setting a third time period for system hibernation between two adjacent cycles.
9. The power mode switching method based on automated scripts according to claim 6, characterized in that, S2 includes: Initiate a power switching request using the GET / POST method and generate an HTTP message containing the power mode switching instruction; Extract the JSON data body of the API response and verify whether the status code is the preset success value; When the status code is abnormal, an error handling step is triggered to record the API verification failure event.
10. The power mode switching method based on automated scripts according to claim 6, characterized in that, S3 includes: Before connecting to the SSH connection, check the key pair configuration status. If the key is missing, terminate the current loop and mark the SSH preflight as failed. Detect the liveness status of the target process and parse the returned list of process IDs; If the list is empty, the process is considered abnormal, and the SSH session is forced to be interrupted after a preset timeout period.