Automatic testing method and system and electronic equipment

Abstract

The invention belongs to the technical field of power grid testing, and provides an automatic testing method and system and electronic device.In the automatic testing system, a testing control terminal is connected with a dispatching plan simulation server, a network time protocol server and a power conversion system; the control system is used for automatically starting the scheduling plan simulation server and the network time protocol server according to the test case, dynamically generating at least one scheduling plan table according to the test case, uploading the at least one scheduling plan table to the scheduling plan simulation server, and controlling the power conversion system and the network time protocol server to perform time synchronization at the same time; and the power conversion system is respectively connected with the scheduling plan simulation server and the network time protocol server, and is used for requesting a target scheduling plan table from the scheduling plan simulation server according to own operation requirements, and controlling output power according to the obtained target scheduling plan table on the premise of keeping time consistent with that of the network time protocol server.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of power grid testing, and more particularly to an automatic testing method and system and an electronic device. BACKGROUND

[0002] In related technologies, in remote power conversion system (PCS) output control function testing, multi-link operations in the testing mode rely on manual intervention to complete, for example but not limited to, manually starting a dispatch simulation server, writing a dispatch schedule table that conforms to a power company protocol, manually configuring a network time protocol (NTP) server address to achieve time synchronization, and manually triggering a dispatch request of the power conversion system.

[0003] However, manually generated dispatch schedule tables are prone to problems such as not conforming to protocol specifications in format and logical contradictions in parameters; time synchronization relies on manual modification of device time, affecting the testing accuracy of power control time nodes; the testing efficiency is low and the testing results are prone to distortion due to human operation errors; and manual adjustment has poor adaptability and is difficult to meet the testing needs of multiple scenarios. SUMMARY

[0004] The embodiments of the present application aim to provide an automatic testing method and system and an electronic device, and aim to solve the technical problems of poor adaptability, inaccurate time synchronization, and low testing efficiency of the testing mode in related technologies.

[0005] To achieve the above-mentioned purposes, according to a first aspect of the present application, an automatic testing system is provided, comprising a test control terminal, a dispatch plan simulation server, a network time protocol server, and a power conversion system; The test control terminal is connected to the dispatch plan simulation server, the network time protocol server, and the power conversion system respectively, and is configured to automatically start the dispatch plan simulation server and the network time protocol server according to a test case, dynamically generate at least one dispatch schedule table according to the test case, upload the at least one dispatch schedule table to the dispatch plan simulation server, and control the power conversion system to perform time synchronization with the network time protocol server; The power conversion system is connected to the dispatch plan simulation server and the network time protocol server respectively, and is configured to request a target dispatch schedule table from the dispatch plan simulation server according to its own operation requirements, and control output power according to the target dispatch schedule table obtained on the premise of keeping time consistent with the network time protocol server.

[0006] In some embodiments, the test control terminal dynamically generates at least one dispatch schedule table according to the test case, comprising: The test control terminal acquires the target time parameter, power control percentage parameter, and next access interval parameter from the test case. The test control terminal performs format conversion and logical integration of the target time parameter, the power control percentage parameter, and the next access interval parameter according to the dispatch plan protocol specifications stipulated by the power company, to obtain the processed target time parameter, the processed power control percentage parameter, and the processed next access interval parameter. Based on the scenario requirements of the test cases, the processed target time parameter, the processed power control percentage parameter, and the processed next access interval parameter, at least one scheduling plan table is generated, wherein the type of the scheduling plan table includes at least one of a yearly table, a monthly table, or an update table.

[0007] In some embodiments, the test control terminal controls the power conversion system to synchronize time with the network time protocol server, including: The test control terminal obtains its own Internet Protocol address; The test control terminal uses the Internet Protocol address as the communication address of the Network Time Protocol server to establish a communication connection with the power conversion system; The test control terminal sends an address configuration command to the power conversion system to set the network time protocol server address of the power conversion system as the communication address; The test control terminal sends a time synchronization trigger command to the power conversion system, causing the power conversion system to initiate a time synchronization request based on the communication address, so that the power conversion system can synchronize its time with the network time protocol server.

[0008] In some embodiments, the test control terminal is further configured to modify its own system time according to the requirements of the test case, so that the time of the network time protocol server changes synchronously with the system time of the test control terminal; and to cause the power conversion system to keep its time consistent with the network time protocol server after the time change by sending the time synchronization trigger command.

[0009] In some embodiments, the test control terminal is also used to collect actual output power data and actual response time data of the power conversion system during the process of the power conversion system controlling the output power according to the target scheduling plan. The actual output power data is compared with the expected output power data preset in the test case to determine the first deviation between the actual output power data and the expected output power data; The actual response time data is compared with the preset expected response time data in the test case to determine the second deviation between the actual response time data and the expected response time data; If both the first deviation and the second deviation are within their respective preset allowable ranges, then the power conversion system is determined to meet the target operating requirements. If the first deviation and / or the second deviation are not within the corresponding preset allowable range, the power conversion system is determined to not meet the target operating requirements.

[0010] In some embodiments, the test control terminal, the scheduling plan simulation server, and the network time protocol server are deployed in the same computer device; The test control terminal is pre-configured with a preset script containing server start instructions, stop instructions, and communication parameters. The test control terminal executes the start instruction to start the scheduling plan simulation server and the network time protocol server at the start of the test by calling the preset script, and executes the stop instruction to stop the scheduling plan simulation server and the network time protocol server after the test is completed.

[0011] In some embodiments, the scheduling plan simulation server is used to receive the scheduling plan table uploaded by the test control terminal; The scheduling plan simulation server is also used to, upon receiving a scheduling plan request sent by the power conversion system, return message information containing complete data of the scheduling plan and adapted to the power conversion system, in accordance with the scheduling plan protocol specifications stipulated by the power company.

[0012] In some embodiments, the test control terminal is further configured to perform data format verification on the at least one scheduling plan table in accordance with the scheduling plan protocol specifications stipulated by the power company when uploading the at least one scheduling plan table to the scheduling plan simulation server, so that the at least one scheduling plan table that is successfully uploaded meets the receiving standards of the scheduling plan simulation server.

[0013] According to a second aspect of this application, an automated testing method is provided, applied to a test control terminal, the method comprising: After automatically starting the scheduling plan simulation server and the network time protocol server, at least one scheduling plan table is dynamically generated based on the test cases; Upload the at least one scheduling plan table to the scheduling plan simulation server; The power conversion system is controlled to synchronize with the network time protocol server, so that the power conversion system and the network time protocol server keep their time consistent; Provided that the power conversion system and the network time protocol server maintain time consistency, the power conversion system is triggered to request the scheduling plan table from the scheduling plan simulation server according to its own operational needs, so that the power conversion system can control the output power according to the obtained scheduling plan table.

[0014] According to a third aspect of this application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the electronic device causes the electronic device to perform the method as described in any one of the claims.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, implements the method as described in any one of the claims.

[0016] According to a fifth aspect of this application, a computer program product is provided that, when run on an electronic device, causes the electronic device to perform the method described in any one of the first aspects above.

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

[0018] The beneficial effects of the embodiments in this application compared with the prior art are: This application provides an automated testing system, including a test control terminal, a scheduling plan simulation server, a network time protocol server, and a power conversion system. The test control terminal is connected to the scheduling plan simulation server, the network time protocol server, and the power conversion system. It automatically starts the scheduling plan simulation server and the network time protocol server based on test cases, dynamically generates at least one scheduling plan table based on the test cases, and uploads the at least one scheduling plan table to the scheduling plan simulation server. Simultaneously, it controls the power conversion system to synchronize its time with the network time protocol server. The power conversion system is connected to both the scheduling plan simulation server and the network time protocol server. It requests a target scheduling plan table from the scheduling plan simulation server based on its own operational needs, and, while maintaining time consistency with the network time protocol server, controls its output power based on the obtained target scheduling plan table.

[0019] By testing the integrated control capabilities of the control terminal, the system automatically starts the scheduling plan simulation server and the network time protocol server without manual start-up or shutdown; it dynamically generates and automatically uploads scheduling plan tables, replacing manual writing and uploading operations; it automatically controls the time synchronization between the power conversion system and the network time protocol server without manual address configuration or time modification; and it automatically triggers the power conversion system to initiate scheduling plan table requests. The entire process of server start-up and shutdown, plan table generation and uploading, time synchronization, and request triggering is automated, eliminating the need for manual step-by-step operations, reducing operational errors and waiting time, and significantly improving the continuity of the testing process and the efficiency of test execution.

[0020] Furthermore, the test control terminal dynamically generates a dispatch plan table according to the dispatch plan protocol specifications stipulated by the power company, ensuring that the field format and parameter logic of the dispatch plan table conform to the protocol requirements, meeting diverse testing needs, and avoiding technical problems such as protocol incompatibility and poor adaptability caused by manually writing dispatch plan tables. A unified time reference is established through a network time protocol server, and the test control terminal automatically configures the communication address and triggers synchronization, prompting the power conversion system and the server to accurately calibrate time, ensuring that time deviations are within a reasonable range. Attached Figure Description

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

[0022] Figure 1 This is a schematic diagram of the structure of an automated testing system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating an automated testing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an automated testing device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

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

[0025] It should also be understood that, in the description of this application, unless otherwise stated, the " / " used in the specification and appended claims indicates that the related objects are in an "or" relationship. For example, A / B can mean A or B. The "and / or" in this application is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0026] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, but are only used for distinguishing descriptions, and the terms "first" and "second" do not necessarily imply that they are different, nor should they be construed as indicating or implying relative importance.

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

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

[0029] This application provides an example of an automated testing system; please refer to [link / reference]. Figure 1 As shown, Figure 1 A schematic structural diagram of an automated testing system provided in this application is shown. The automated testing system includes a test control terminal 101, a scheduling plan simulation server 102, a network time protocol server 103, and a power conversion system 104.

[0030] The test control terminal 101 is connected to the scheduling plan simulation server 102, the network time protocol server 103, and the power conversion system 104, respectively. It is used to automatically start the scheduling plan simulation server and the network time protocol server according to the test cases, dynamically generate at least one scheduling plan table according to the test cases, and upload at least one scheduling plan table to the scheduling plan simulation server. At the same time, it controls the power conversion system to synchronize time with the network time protocol server.

[0031] The power conversion system 104 is connected to the scheduling plan simulation server 102 and the network time protocol server 103 respectively. It is used to request the target scheduling plan table from the scheduling plan simulation server according to its own operation needs, and to control the output power according to the target scheduling plan table obtained while maintaining time consistency with the network time protocol server.

[0032] This embodiment details the specific implementation process of the automated testing system and the collaborative working logic of its various components, making the technical solution of the automated testing system easier to understand and implement. In this embodiment, the test control terminal, scheduling plan simulation server, and network time protocol server are deployed on the same computer. The three interact with each other through a preset communication interface. The power conversion system establishes a connection with the computer through the network, forming an automated testing environment and ensuring stable and reliable communication between the components.

[0033] In some embodiments, the automated testing system provided in this application can be applied to testing scenarios involving remote power control functions in power conversion systems (PCS), such as R&D testing and certification testing. Before testing begins, the automated testing system is initialized and configured. For example, the test control terminal pre-stores test cases adapted to the test scenario. The test cases include target time parameters, power control percentage parameters, next access interval parameters, and expected operating data, and specify the generation type requirements of the scheduling plan table (at least one of annual, monthly, or update tables). Simultaneously, the test control terminal has a built-in preset script containing start and stop instructions for the scheduling plan simulation server and the network time protocol server, as well as corresponding process identifiers, communication ports, and other parameters, ensuring that both the scheduling plan simulation server and the network time protocol server can be automatically invoked.

[0034] After the test is started, the test control terminal first executes the server startup operation. For example, by calling the built-in preset script, it triggers the automatic startup of the scheduling plan simulation server and the network time protocol server. After the two servers complete initialization and enter standby mode, the test control terminal obtains its own Internet Protocol address and sends the address configuration instructions for the scheduling plan simulation server and the network time protocol server to the power conversion system, respectively. It sets its own Internet Protocol address to the communication address of the scheduling plan simulation server and the network time protocol server of the power conversion system, respectively, to ensure that the power conversion system can establish a valid connection with the two servers.

[0035] Subsequently, the test control terminal dynamically generates a scheduling plan table based on the test cases. First, it extracts the target time parameter, power control percentage parameter, and next access interval parameter from the test cases. Then, according to the scheduling plan protocol specifications stipulated by the power company, it performs format conversion (such as converting the time parameter to the timestamp format required by the protocol and converting the power control percentage parameter to a standardized numerical range) and logical integration (such as associating time nodes with corresponding power control requirements and clarifying the triggering conditions for the next access). Combined with the type requirements specified by the test cases, at least one scheduling plan table is generated. For example, a single annual table, monthly table, or update table can be generated according to the scenario requirements, or multiple combined tables of different types can be generated.

[0036] Then, the test control terminal first verifies the data format of the dispatch plan table according to the dispatch plan protocol specification. After confirming the data integrity and format compliance, the qualified dispatch plan table is uploaded to the dispatch plan simulation server. The dispatch plan simulation server stores the received dispatch plan table in a preset directory and waits for the power conversion system to make a request.

[0037] Next, the test control terminal performs time synchronization control, that is, it sends a time synchronization trigger command to the power conversion system. The power conversion system, based on the configured network time protocol server address, initiates a time synchronization request to the network time protocol server. The network time protocol server returns its current time data (if the test case requires a fixed test time, the test control terminal has modified its own system time in advance, and the network time protocol server time changes synchronously with it). After receiving the data, the power conversion system calibrates its own system time to ensure that it is consistent with the network time protocol server time, laying the foundation for subsequent power control to be performed according to the scheduling schedule time nodes.

[0038] After time synchronization is complete, the power conversion system initiates a dispatch schedule request based on its operational needs. Based on the dispatch logic corresponding to the test cases (such as reaching a preset time node, updating dispatch instructions after completing the previous stage of power output, etc.), the power conversion system sends a target dispatch schedule request to the dispatch schedule simulation server, specifying the type or time range of the required schedule. Upon receiving the target dispatch schedule request, the dispatch schedule simulation server matches the corresponding target dispatch schedule from its storage directory. Following the dispatch schedule protocol specifications stipulated by the power company, it encapsulates the target dispatch schedule into message information adapted to the power conversion system and subsequently returns the complete message containing the target dispatch schedule to the power conversion system.

[0039] After receiving the message, the power conversion system parses out the core information of the target scheduling plan, such as each time node, the power control requirements of the corresponding node, and the trigger conditions for the next access. While maintaining time consistency with the network time protocol server, the system uses its internally integrated inverter module to strictly control the output power according to the requirements of the target scheduling plan. For example, at the time nodes specified in the target scheduling plan, the output power is adjusted to the corresponding power control percentage to ensure real-time matching between power output and scheduling requirements.

[0040] Furthermore, it should be noted that during the testing process, the test control terminal can simultaneously collect operational data of the power conversion system, such as actual output power data, power response time data, and operational status data at each time point. The actual collected operational data is then compared with the expected data preset in the test cases to verify the accuracy of the expected data. After the test is completed, the test control terminal calls the preset script again to execute the automatic stop commands of the scheduling plan simulation server and the network time protocol server, thus completing the entire automated testing process.

[0041] This implementation method clarifies the deployment method, interaction logic, and execution steps of each component in the automated testing system, achieving full automation of scheduling plan generation, server start-up and shutdown, time synchronization, and power control without manual intervention. It effectively solves the problems of low testing efficiency, error susceptibility, and poor scenario adaptability of traditional testing methods, and is especially suitable for various scenarios such as certification testing and R&D testing of remote output control functions of power conversion systems.

[0042] In some embodiments, the test control terminal dynamically generates at least one scheduling plan table based on test cases, including: obtaining the target time parameter, power control percentage parameter, and next access interval parameter from the test cases; converting and logically integrating the target time parameter, power control percentage parameter, and next access interval parameter according to the scheduling plan protocol specifications stipulated by the power company to obtain the processed target time parameter, processed power control percentage parameter, and processed next access interval parameter; and generating at least one scheduling plan table based on the scenario requirements of the test cases, the processed target time parameter, the processed power control percentage parameter, and the processed next access interval parameter.

[0043] The scheduling schedule table can be of at least one of the following types: annual table, monthly table, or update table.

[0044] In some embodiments, the process of the test control terminal dynamically generating at least one scheduling plan table based on test cases ensures that the scheduling plan table meets the power company's specifications and test scenario requirements through parameter extraction, protocol adaptation processing, and targeted generation steps.

[0045] In some embodiments, after starting the scheduling plan generation process, the test control terminal first accurately obtains the following parameters from the pre-stored test cases: target time parameters, power control percentage parameters, and access interval parameters.

[0046] The target time parameter includes the test start time, end time, and key control time nodes (such as the specific time of daily power adjustment). This target time parameter can be set to a specific date and time format or a fixed monthly time range according to the test scenario requirements. The power control percentage parameter is the power output control ratio corresponding to each time node preset in the test case, and its value range must be adapted to the power regulation capability of the power conversion system. The next access interval parameter specifies the time period (such as hours, days, etc.) for the power conversion system to request updates to the scheduling schedule again, ensuring the timeliness of scheduling instructions.

[0047] Subsequently, the test control terminal, based on the power company's publicly disclosed or agreed-upon dispatch plan protocol specifications, performs targeted format conversion and logical integration processing on the aforementioned target time parameters, power control percentage parameters, and next access interval parameters. For example, in the format conversion stage, the target time parameters are converted into the timestamp format or standardized date string required by the protocol; the power control percentage parameters are converted into a protocol-compatible numerical type (e.g., removing the percentage sign and retaining a specified number of decimal places); and the next access interval parameters are converted into the time unit code specified by the protocol. In the logical integration stage, according to the field order and data association rules required by the protocol, the processed target time parameters are bound to the corresponding power control percentage parameters, clarifying the power control instructions for each time node. At the same time, the next access interval parameters are associated with the time nodes to determine the specific conditions under which the power conversion system triggers the next dispatch plan request, ensuring that the generated dispatch plan data is logically consistent and meets the protocol interaction requirements.

[0048] After parameter processing, the test control terminal generates at least one scheduling plan table based on the scenario requirements of the test cases. For example, if the test cases target long-term scheduling scenarios (such as annual power optimization testing), a yearly scheduling plan table is generated, containing power control requirements for each key time node throughout the year and the next access interval plan within the year. If the test cases target medium-term scheduling scenarios (such as monthly grid connection testing), a monthly scheduling plan table is generated, focusing on refined power control for each time node of the month. If the test cases target temporary scheduling adjustment scenarios (such as sudden power adjustment response testing), an update table-type scheduling plan table is generated, containing only the power control parameters for the adjustment period and the immediate triggering conditions for the next access. If the test scenario needs to cover multi-dimensional scheduling requirements (such as annual basic scheduling + monthly dynamic adjustment), a combined scheduling plan table of yearly, monthly, and update tables is generated simultaneously. Each generated scheduling plan table includes a table type identifier, protocol version number, processed complete parameter data, and verification fields to ensure that the scheduling plan simulation server can accurately identify and parse it after receiving it.

[0049] Through the above embodiments, the test control terminal can flexibly generate scheduling plans that conform to the protocol specifications according to the needs of different test scenarios. This ensures the accuracy and adaptability of scheduling instructions and supports the generation of single-type or multi-type combination plans, effectively covering various test requirements for remote power control and providing a reliable scheduling basis for the power control of subsequent power conversion systems.

[0050] In some embodiments, the test control terminal controls the power conversion system to synchronize time with the network time protocol server, including: The test control terminal obtains its own Internet Protocol address; The test control terminal uses the Internet Protocol address as the communication address of the Network Time Protocol server to establish a communication connection with the power conversion system; The test control terminal sends an address configuration command to the power conversion system to set the network time protocol server address of the power conversion system as the communication address; The test control terminal sends a time synchronization trigger command to the power conversion system, prompting the power conversion system to initiate a time synchronization request based on the communication address, thereby enabling the power conversion system to synchronize its time with the network time protocol server.

[0051] In some embodiments, the test control terminal controls the power conversion system to synchronize time with the network time protocol server. Through the coherent operation of address configuration, connection establishment, and synchronization triggering, the accurate consistency of time between the two is ensured, providing a time reference for the effective execution of the scheduling schedule. The specific implementation process is as follows: After the test control terminal starts the scheduling plan simulation server and the network time protocol server, it first performs the Internet Protocol address acquisition operation: for example, by calling the network configuration query interface of its own operating system, it obtains the valid Internet Protocol address (such as IPv4 address) under the current network status, and verifies the reachability of the IPv4 address through the built-in network connectivity detection module (such as sending a ping command to confirm that the address is not occupied and the network link is unobstructed), ensuring that the IPv4 address can be used as a valid identifier for subsequent communication and avoiding communication failure due to invalid Internet Protocol addresses.

[0052] Subsequently, the test control terminal initiates the communication connection establishment process with the power conversion system based on the obtained Internet Protocol address. For example, using the TCP / IP communication protocol, it sends a connection request to the preset communication port of the power conversion system. After receiving the connection request, the power conversion system verifies its legitimacy through identity verification (such as verifying whether the device identifier of the test control terminal is in the preset whitelist) and returns a connection response command. After receiving the response command, the test control terminal completes the handshake process and establishes a stable two-way communication connection to ensure the integrity and real-time performance of subsequent command transmission.

[0053] After the connection between the test control terminal and the power conversion system is established, the test control terminal generates an address configuration command. This command includes the communication address of the Network Time Protocol (NTP) server (i.e., the previously obtained Internet Protocol address), the standard NTP communication port (such as port 123), and an address activation flag. The command format conforms to the command parsing specifications of the power conversion system, ensuring that the power conversion system can accurately identify key information. The test control terminal sends this address configuration command through the established communication connection. Upon receiving the command, the power conversion system parses the NTP server's communication address and port, automatically replaces its default NTP server address configuration, sets the NTP server corresponding to the test control terminal as the sole synchronization source, and returns a feedback message indicating successful address configuration. The test control terminal confirms the address configuration is complete upon receiving the feedback.

[0054] Finally, the test control terminal executes a time synchronization trigger operation, sending a time synchronization trigger command to the power conversion system. This command includes a synchronization priority identifier (set to the highest priority to ensure the power conversion system executes the synchronization operation first) and a synchronization timeout threshold (e.g., 3 seconds to avoid blocking the synchronization process). Upon receiving the trigger command, the power conversion system immediately initiates a time synchronization request to the network time protocol server based on the configured network time protocol server communication address and port. This time synchronization request includes the current system time data of the power conversion system and the synchronization accuracy requirements.

[0055] After receiving the time synchronization request, the Network Time Protocol (NTP) server extracts its current system time (if the test case requires a fixed test time, this time has been synchronized and modified with the test control terminal's system time), encapsulates the time data according to the NTP specification (including absolute timestamp, time precision parameters, server clock offset, etc.), and returns the encapsulated time response message to the power conversion system. Upon receiving the response message, the power conversion system parses the NTP server's standard time from the response message, compares the standard time with its own current system time, calculates the time deviation, and if the deviation exceeds a preset allowable range (e.g., ±10 milliseconds), automatically adjusts its clock to match the NTP server's time; otherwise, it maintains its current time, completing the time synchronization process. After synchronization, the power conversion system returns a confirmation message of successful time synchronization to the test control terminal, which can then proceed to the subsequent scheduling plan generation and uploading phase.

[0056] Through the above embodiments, the test control terminal can automatically synchronize the power conversion system with the network time protocol server without manual intervention, avoiding the tedious operation and errors of manually modifying the time in traditional testing, ensuring that the time nodes in the scheduling plan are accurately matched with the running time of the power conversion system, and providing a key guarantee for the accuracy of subsequent power control.

[0057] In some embodiments, the test control terminal is also used to modify its own system time according to the requirements of the test cases, so that the time of the network time protocol server changes synchronously with the system time of the test control terminal; and to make the power conversion system keep the time consistent with the network time protocol server after the time change by sending a time synchronization trigger command.

[0058] In this embodiment of the application, when the test case requires remote power control testing based on a fixed test time (such as a specific month or historical time node), the test control terminal needs to modify its own system time to drive the network time protocol server to synchronize the time, and then trigger the power conversion system to keep the time consistent with the updated network time protocol server, ensuring that the time nodes of the scheduling plan are accurately matched with the test scenario. The specific implementation process is as follows: For example, the test control terminal first extracts the target test time parameter from the test cases. This target test time parameter can be a specific date and time (e.g., 08:00 on June 15, 2024), a fixed monthly time range (e.g., the entire month of March each year), or a specific historical time node. Furthermore, this target test time parameter is determined by the test scenario requirements (e.g., verifying power scheduling response in a specific season, reproducing historical scheduling scenarios). After extracting the target test time parameter from the test cases, the test control terminal calls its own operating system's time modification interface to send a time configuration command to the operating system kernel, adjusting its own system time from the current real-time time to the target test time.

[0059] To ensure the time modification is effective, the test control terminal immediately calls the operating system's time query interface after sending the modification command to obtain the current system time and compare it with the target test time to determine whether the time deviation is within a preset error range (e.g., ±1 second). If the time deviation exceeds the preset error range, the time modification command is resent and the verification is repeated until the system time accurately matches the target test time; if the time deviation is within the preset error range, the system time modification is confirmed to be complete.

[0060] Since the test control terminal and the network time protocol server are deployed on the same computer, they share the computer's system clock resources. The network time protocol server monitors changes in the computer's system clock in real time. When the test control terminal's system time is changed to the target test time, the network time protocol server can automatically synchronize and update its own time base without additional configuration commands. This ensures that the network time protocol server's current output time is completely consistent with the test control terminal's system time, guaranteeing that the subsequent power conversion system synchronization time is the target test time.

[0061] Subsequently, the test control terminal executes the time synchronization triggering process: based on the previously established stable communication connection with the power conversion system (the address configuration stage has completed the setting of the Network Time Protocol server address), it sends a time synchronization triggering command with a time update flag to the power conversion system. In addition to the original synchronization priority flag (highest priority) and synchronization timeout threshold, this time synchronization triggering command adds a time update flag to inform the power conversion system that synchronization must be completed based on the new time benchmark, avoiding the use of historical synchronization caches.

[0062] Upon receiving the trigger command, the power conversion system identifies the time update marker and immediately initiates a new time synchronization request to the Network Time Protocol (NTP) server based on the configured NTP server communication address. At this time, the time data returned by the NTP server has been updated to the target test time (i.e., the system time modified by the test control terminal). After receiving this time data, the power conversion system compares it with its current system time and calculates the time deviation.

[0063] If the deviation exceeds the preset allowable range (e.g., ±10 milliseconds), the power conversion system automatically adjusts its own clock to calibrate the system time to the target test time; if the deviation is within the allowable range, the current time remains unchanged (ensuring time stability). After synchronization is complete, the power conversion system returns a confirmation message to the test control terminal indicating successful time update synchronization. This confirmation message includes the current calibrated time of the power conversion system. Upon receiving this message, the test control terminal compares this time with the target test time again. After confirming consistency, it can proceed to the scheduling schedule generation, uploading, and subsequent power control stages.

[0064] Through the above embodiments, the test control terminal can accurately modify its own system time, synchronize and update the network time protocol server time, and perform secondary time calibration of the power conversion system without manual intervention. This not only meets the needs of fixed-time test scenarios but also avoids the tedious operation and synchronization errors of manually modifying the time of multiple devices in traditional testing. It ensures the uniformity of the time base in the test process and provides a reliable guarantee for the scheduling plan to execute power control according to the target time node.

[0065] In some embodiments, the test control terminal is further configured to: collect actual output power data and actual response time data of the power conversion system during the process of the power conversion system controlling its output power according to the target scheduling plan; compare the actual output power data with the preset expected output power data in the test case to determine a first deviation between the actual output power data and the expected output power data; compare the actual response time data with the preset expected response time data in the test case to determine a second deviation between the actual response time data and the expected response time data; if both the first deviation and the second deviation are within the corresponding preset allowable range, then the power conversion system is determined to meet the target operating requirements; if the first deviation and / or the second deviation are not within the corresponding preset allowable range, then the power conversion system is determined to not meet the target operating requirements.

[0066] In some embodiments, to verify the accuracy and reliability of the power conversion system in executing power control according to the target scheduling schedule, the test control terminal collects key data in real time during the operation of the power conversion system and performs comparative analysis to ultimately determine whether the power conversion system meets the target operating requirements. The specific implementation process is as follows: After confirming that the power conversion system has completed time synchronization and obtained the target scheduling plan, the test control terminal initiates the data acquisition process. The acquisition process is synchronized in real time with the power control process of the power conversion system. The acquisition timing precisely corresponds to each time node in the target scheduling plan (such as the power adjustment trigger time, the stable operation time) and the preset time interval (such as acquiring data once every 100 milliseconds), ensuring the integrity and timeliness of the data.

[0067] In some embodiments, the data acquisition process specifically collects actual output power data and actual response time data. The actual output power data is the actual power output value of the power conversion system at each time point. After being acquired by the power detection module of the power conversion system, it is transmitted in real time to the test control terminal via an established bidirectional communication connection, with data accuracy to two decimal places (unit: kilowatt). The actual response time data refers to the time interval from when the power conversion system receives a power adjustment instruction from the target scheduling plan (e.g., adjusting the output power to 50% of the rated power at a certain moment) to when the actual output power reaches the instruction requirement. This time interval is calculated by the test control terminal, which records the instruction trigger time and the power attainment time, with accuracy down to the millisecond level.

[0068] After data acquisition is complete, the test control terminal extracts the corresponding preset data from the pre-stored test cases: namely, the expected output power data corresponding to each acquisition time node (set by the test cases according to certification standards and test scenario requirements, such as an expected output power of 100 kilowatts at a certain moment), and the preset expected response time data (such as a power adjustment response time of no more than 500 milliseconds). Subsequently, the test control terminal initiates data comparison and analysis: on the one hand, it compares the actual output power data of each time node with the corresponding expected output power data one by one, and calculates the first deviation by the absolute difference between the two (i.e., first deviation = |actual output power data - expected output power data|); on the other hand, it compares the calculated actual response time data with the preset expected response time data, and obtains the second deviation by the same absolute difference calculation method (i.e., second deviation = |actual response time data - expected response time data|).

[0069] During the comparison process, the test control terminal invokes the built-in deviation judgment rules, which preset allowable ranges corresponding to the two types of data: the preset allowable range for the first deviation is determined by the power regulation accuracy standard of the power conversion system (e.g., ±2 kW, which can be flexibly configured according to different test scenarios), and the preset allowable range for the second deviation is determined by the response speed requirements of remote power control (e.g., ±50 milliseconds, in accordance with the dispatch protocol specifications of the power company). The test control terminal compares the first deviation with the corresponding preset allowable range, and simultaneously compares the second deviation with the corresponding preset allowable range: if the first deviation is less than or equal to the upper limit of the preset allowable range, and the second deviation is also less than or equal to the upper limit of the corresponding preset allowable range, that is, both types of deviations are within their respective preset allowable ranges, then the operating status of the power conversion system is determined to meet the target operating requirements; if the first deviation exceeds its preset allowable range, or the second deviation exceeds its preset allowable range, or both types of deviations exceed their corresponding preset allowable ranges, then the operating status of the power conversion system is determined to not meet the target operating requirements.

[0070] After the judgment is completed, the test control terminal automatically records the judgment result, including the conclusion of compliance / non-compliance, the deviation value exceeding the allowable range, the corresponding time node and data details, and generates a preliminary test report fragment. If the judgment result is non-compliance, the test control terminal will also mark the key links where the deviation exceeds the standard (e.g., the actual output power deviation is 3 kilowatts at a certain moment, exceeding the allowable range), providing accurate basis for subsequent fault diagnosis and system optimization.

[0071] It should be understood that the entire data collection, comparison and judgment process is completed automatically by the test control terminal without human intervention. This ensures the objectivity and accuracy of the judgment results, greatly improves test efficiency, and further perfects the closed loop of the entire automated testing process.

[0072] In some embodiments, the test control terminal, the scheduling plan simulation server, and the network time protocol server are deployed in the same computer device. The test control terminal is pre-configured with a preset script containing server start instructions, stop instructions, and communication parameters. The test control terminal executes the start instruction to start the scheduling plan simulation server and the network time protocol server at the beginning of the test by calling the preset script, and executes the stop instruction to stop the scheduling plan simulation server and the network time protocol server after the test is completed.

[0073] In some embodiments, to simplify the system deployment architecture, reduce cross-device communication latency, and improve the convenience of the testing process, the test control terminal, scheduling plan simulation server, and network time protocol server are uniformly deployed in the same computer device. The computer device must meet the preset hardware configuration requirements (such as having a multi-core processor, sufficient memory, and stable network adaptability) and have an operating system that is compatible with the three components to ensure that each component can share system resources and work stably together.

[0074] The test control terminal is pre-configured with preset scripts, which are stored in a designated directory on the terminal and have undergone compatibility testing to ensure compatibility with the computer's operating system. The preset scripts contain two types of core instructions and associated parameters: first, server startup instructions, which specify the startup paths, process initialization parameters (such as memory allocation thresholds and thread counts), and communication configuration parameters (including the listening port of the scheduling simulation server, the standard communication port of the network time protocol server, and the data transmission protocol type); second, server shutdown instructions, which include process identification rules for both servers, resource release order (releasing network connection resources first, then terminating processes), and stop status verification conditions to ensure that the servers can be safely and completely stopped, preventing residual processes from consuming system resources.

[0075] During the test startup phase, after completing its own initialization, the test control terminal executes the server startup operation by calling a preset script. First, it parses the startup instructions and associated parameters in the script, and then sends a process startup request to the operating system in a preset order (starting the Network Time Protocol server first, then the scheduling simulation server to avoid time synchronization service lag). The operating system calls the corresponding server's running program according to the instruction path, initializes the process, and allocates specified resources. After both servers start, they automatically read the communication configuration parameters in the script, complete the listening port binding and service status initialization, and enter a standby ready state. The test control terminal monitors the server startup status in real time, verifies whether the processes of the two servers are running normally by querying the operating system's process list, and checks whether their listening ports are in a normal open state. If all preset conditions are met, the server startup is confirmed to be successful. If there is a startup failure or port occupancy, the test control terminal automatically retryes the startup operation (up to 3 times). If it still fails after retrying, a startup exception message is generated and the test process is terminated to ensure that subsequent test phases can be carried out normally.

[0076] After the test is completed (including normal test completion, data verification completion, or abnormal test termination), the test control terminal triggers the execution of a stop command from a preset script: It parses the stop command and process identification rules in the preset script, accurately identifies the running processes corresponding to the scheduling plan simulation server and the network time protocol server, and, according to the preset resource release order, first sends a network connection close command to both servers, causing them to disconnect from the power conversion system and release the occupied network port resources; after the network resources are released, it sends a process termination command to terminate the running processes of both servers. After the processes terminate, the test control terminal verifies the stop status: it queries the operating system process list to confirm that the processes of the two servers have completely disappeared, and simultaneously checks that the corresponding communication ports have been released. If the stop status verification conditions are met, the server is confirmed to have stopped successfully; if any residual processes exist, the test control terminal automatically executes a forced termination command to ensure that system resources are completely released.

[0077] With the same-machine deployment method and preset script calling logic provided in the above embodiments, the test control terminal can achieve automated and standardized management and control of two servers without manual deployment or server start-up and shutdown. This simplifies the preparation work before testing and the closing process after testing, and avoids problems such as incorrect start-up order and incomplete shutdown that may be caused by manual operation. It further enhances the unattended operation capability and operational stability of the automated testing system and reduces the maintenance cost of the testing environment.

[0078] In some embodiments, the scheduling plan simulation server is used to receive the scheduling plan table uploaded by the test control terminal; and after receiving the scheduling plan table request sent by the power conversion system, to return message information containing complete data of the scheduling plan table and adapted to the power conversion system in accordance with the scheduling plan protocol specifications stipulated by the power company.

[0079] In some embodiments, the scheduling plan simulation server serves as the storage carrier of the scheduling plan table and the core of request and response. Through standardized data reception, storage, and message generation processes, it ensures that the power conversion system can obtain scheduling data that conforms to the protocol specifications.

[0080] The scheduling simulation server, test control terminal, and network time protocol server are deployed on the same computer device. They establish a connection with the test control terminal via local process communication, significantly reducing data transmission latency and improving interaction efficiency compared to cross-device communication. After startup, the scheduling simulation server automatically initializes a preset communication listening port (configured in the test control terminal's preset script to ensure consistency with the power conversion system's request port). Simultaneously, it creates a dedicated data storage directory to categorize and store scheduling plan tables for different test scenarios and types. For example, the storage structure is named "Test Case Identifier - Plan Table Type - Generation Timestamp" for easy and rapid indexing and management.

[0081] After the test control terminal completes the generation and format verification of the scheduling plan table, it sends a data upload request to the scheduling plan simulation server. This request includes metadata such as test case identifier, plan table type, and data length. Upon receiving the upload request, the scheduling plan simulation server first verifies the validity of the aforementioned metadata contained in the request (such as verifying the existence of the test case identifier and whether the data length is within a preset threshold range). If the verification passes, it returns an upload permission response.

[0082] Based on the permission response, the test control terminal uploads the complete data of the scheduling plan table (including core content such as processed target time parameters, power control percentage parameters, and next access interval parameters) to the scheduling plan simulation server via streaming. During the reception process, the server verifies the data integrity in real time (by calculating the data checksum and comparing it with the checksum sent by the test control terminal) to ensure that no data is lost or tampered with during transmission. After receiving the data, the server saves the scheduling plan table to a dedicated directory according to the preset storage structure and returns a successful upload confirmation message for the test control terminal to record and archive.

[0083] After the power conversion system completes time synchronization and initiates a dispatch schedule request, the dispatch schedule simulation server receives the request through a listening port. This request contains key information such as the power conversion system's device identifier, the target schedule type (annual, monthly, or update schedule, or one or more), and the request timestamp. The request format conforms to the dispatch schedule protocol specifications stipulated by the power company. Upon receiving the request, the dispatch schedule simulation server first parses the core information carried in the request and queries the dedicated storage directory based on the "device identifier - schedule type" combination to match the complete data of the corresponding dispatch schedule. If no matching data is found (e.g., the test control terminal has not uploaded the corresponding type of schedule or the request parameters are incorrect), an error message containing the "data does not exist" flag is generated and returned to the power conversion system according to the protocol specifications. If matching data is found, the process proceeds to the message generation stage.

[0084] The message generation process strictly adheres to the dispatch plan protocol specifications stipulated by the power company. First, a message header is constructed, containing basic fields such as protocol version number, message type (data response type), data length, and generation timestamp. Then, the complete data from the matched dispatch plan table is used as the message body, encapsulated according to the field order and data format required by the protocol (e.g., time parameters use UTC timestamp format, power parameters use hexadecimal numerical format), ensuring complete consistency between the data fields and the protocol definition. Finally, a checksum (e.g., calculated based on the CRC32 algorithm) is added to the message tail for verification of message integrity by the power conversion system. Simultaneously, the message generation process adapts to the parsing capabilities of the power conversion system, such as splitting data according to the maximum message length supported by the power conversion system (if the data volume of a single plan table is too large), and adding a fragment identifier and the total number of fragments to the header to ensure that the power conversion system can correctly reassemble the data.

[0085] After the message is encapsulated, the scheduling plan simulation server returns the message information containing complete scheduling plan data to the power conversion system in real time through the established communication connection. Upon receiving the message, the power conversion system verifies the data integrity using the checksum at the end of the message, parses the protocol information in the message header and the scheduling parameters in the data body, and can then perform power control operations based on this information.

[0086] It should be noted that the scheduling plan simulation server automatically executes the above-mentioned data reception, storage, request processing, and message generation processes according to standardized procedures without manual intervention. This ensures the accuracy of scheduling data and protocol compatibility, and enables flexible responses to requests from multiple test scenarios and various types of schedules, providing core data support for the smooth implementation of automated testing.

[0087] In some embodiments, the test control terminal is also used to perform data format verification on at least one scheduling plan table in accordance with the scheduling plan protocol specifications stipulated by the power company when uploading at least one scheduling plan table to the scheduling plan simulation server, so that at least one successfully uploaded scheduling plan table meets the receiving standards of the scheduling plan simulation server.

[0088] In some embodiments, to ensure that the scheduling plan tables uploaded to the scheduling plan simulation server comply with the protocol specifications and server reception requirements, and to avoid subsequent request response failures due to abnormal data formats, the test control terminal will perform a data format verification process according to the scheduling plan protocol specifications stipulated by the power company before uploading at least one scheduling plan table to the scheduling plan simulation server, to ensure that all successfully uploaded scheduling plan tables meet the reception standards.

[0089] The test control terminal has a built-in protocol parsing module. This module pre-stores a complete verification rule base of the dispatch plan protocol specifications stipulated by the power company. The verification rule base covers the field integrity rules, data format rules, numerical validity rules and logical correlation rules required by the protocol, and can be dynamically adapted according to the protocol version update.

[0090] Among them, the field integrity rules specify the required fields that the scheduling plan table must include (such as table type identifier, protocol version number, target time node, power control parameters, next access interval, data checksum, etc.); the data format rules define the standard format of each field (such as the time field must use UTC timestamp format, the power control parameters must use decimal numerical format, and the identifier field must use fixed-length string format); the numerical validity rules limit the legal value range of each parameter (such as the power control percentage parameter must be between 0-100%, and the next access interval parameter must be greater than 0 seconds); and the logical correlation rules ensure the logical consistency between related fields (such as the next access time must be later than the current scheduling time node, and the data checksum must match the field content).

[0091] Once the test control terminal generates the scheduling plan, it immediately initiates the data format verification process: First, it calls the protocol parsing module to load the verification rule base. Then, for each scheduling plan, it performs item-by-item verification in the order of "field integrity verification → data format verification → numerical validity verification → logical correlation verification." In the field integrity verification stage, the test control terminal iterates through all fields of the scheduling plan and compares them with the list of required fields in the verification rule base to confirm whether there are any missing fields, incorrect field names, or duplicate fields. In the data format verification stage, it matches and verifies the actual format of each field against the standard format specified in the protocol (e.g., verifying whether the time field conforms to the timestamp encoding standard and whether the numerical field contains non-numerical characters). In the numerical validity verification stage, it extracts the actual values ​​of each parameter, determines whether they are within the legal range defined by the rules, and checks for issues such as numerical overflow and invalid default values. In the logical correlation verification stage, it verifies whether the logical relationship between related fields is valid (e.g., verifying whether the data check code is calculated from the content of other fields using the algorithm specified in the protocol and whether the arrangement of each time node conforms to the chronological order).

[0092] During the verification process, the test control terminal records the verification results in real time. If a scheduling plan table passes all verification stages, i.e., no fields are missing, the format is compliant, the values ​​are valid, and the logic is consistent, then the scheduling plan table is deemed to have passed the format verification and is marked as uploadable. If an anomaly is found in any verification stage, such as the missing table type identifier field required by the protocol, power control parameters exceeding the 0-100% range, the next access time being earlier than the current time node, etc., then the scheduling plan table is deemed to have failed the format verification, and the anomaly details are recorded, including, for example, the anomaly type, the fields involved, the current values ​​and compliance requirements, etc., and the anomaly handling mechanism is triggered.

[0093] For scheduling plans that fail verification, the test control terminal processes them according to a preset strategy. If the anomaly is due to missing fields or incorrect format, and can be automatically corrected through parameter completion or format conversion (e.g., converting the time format to a standard timestamp or completing the missing protocol version number field), the correction operation is automatically performed and the form is resubmitted for verification. If the anomaly is due to invalid values ​​or logical conflicts (e.g., power parameters exceeding the legal range or time logic contradictions), and cannot be automatically corrected, a verification anomaly message is generated, including anomaly details and correction suggestions. The upload process for the scheduling plan is then suspended, and the anomaly information is written to the test log for subsequent investigation by testers. If the automatic correction and re-verification still fail, the upload of the scheduling plan is terminated, and only valid scheduling plans are included in the upload queue.

[0094] After all scheduling plans have been verified and the upload queue has been determined, the test control terminal initiates an upload request to the scheduling plan simulation server, uploading the verified scheduling plans one by one in a streaming manner. Since the uploaded scheduling plans have all passed full-dimensional verification according to the protocol specifications, it ensures that their data integrity, format compliance, and logical consistency meet the receiving standards of the scheduling plan simulation server. This avoids upload failures and server parsing anomalies caused by data format issues, providing a reliable data foundation for subsequent power conversion systems to request scheduling data and execute power control, further ensuring the stability and smoothness of the automated testing process.

[0095] This application provides an example of an automated testing method; please refer to [link / reference]. Figure 2 As shown, Figure 2 A schematic flowchart of an automated testing method provided in this application is shown. This is an example and not a limitation; the method can be applied to or run on a test control terminal. The method includes: S201: After automatically starting the scheduling plan simulation server and the network time protocol server, at least one scheduling plan table is dynamically generated based on the test cases.

[0096] S202, upload at least one scheduling plan table to the scheduling plan simulation server.

[0097] S203 controls the power conversion system to synchronize time with the network time protocol server, ensuring that the power conversion system and the network time protocol server maintain time consistency.

[0098] S204, provided that the power conversion system and the network time protocol server maintain time consistency, the power conversion system is triggered to request a scheduling plan table from the scheduling plan simulation server according to its own operational needs, so that the power conversion system can control the output power according to the obtained scheduling plan table.

[0099] This embodiment discloses an automated testing method for test control terminals. By sequentially executing operations such as generating and uploading scheduling plans, synchronizing time, and triggering requests, it realizes automated testing of the remote output control function of power conversion systems, ensuring that the automated testing process is standardized, the data is accurate, and no manual intervention is required.

[0100] In some embodiments, the test control terminal first performs a server startup operation, which triggers the automatic startup of the two servers by calling a pre-configured preset script, in the order of starting the Network Time Protocol server first and then the scheduling plan simulation server.

[0101] It should be understood that the preset script includes the server startup path, process initialization parameters (such as memory allocation threshold and listening port), and communication protocol configuration. The test control terminal sends a startup request to the operating system by parsing the script instructions. After the operating system completes process initialization and sends back a server ready signal, it confirms that the scheduling plan simulation server and the network time protocol server have entered standby mode and can receive subsequent data interaction instructions.

[0102] After the two servers are started, the test control terminal dynamically generates at least one scheduling plan table based on the test cases. First, it extracts the target time parameters (including test start / end time and key power adjustment nodes), power control percentage parameters (adapting to the power adjustment range of the power conversion system), and next access interval parameters (clarifying the subsequent scheduling data update cycle) from the test cases. Then, it calls the built-in protocol adaptation module to perform format conversion and logical integration of the above parameters according to the scheduling plan protocol specifications stipulated by the power company. For example, it converts the target time parameters to UTC timestamps and the power control percentage parameters to standardized numerical formats. It also integrates time nodes with corresponding power control requirements and binds the next access trigger conditions. Finally, it generates at least one scheduling plan table based on the scenario requirements of the test cases. The plan table type can be flexibly selected as any of the annual table, monthly table, or update table, or a combination of multiple types (such as generating an annual table + monthly update table for long-term test scenarios). Each scheduling plan table includes a table type identifier, protocol version number, complete parameter data, and verification fields to ensure data integrity and protocol compatibility.

[0103] After generating the scheduling plan, the test control terminal initiates the upload process. First, it performs data format verification on each plan according to the power company's scheduling plan protocol specifications. Verification dimensions include field completeness (confirming no missing required fields), format compliance (each field matches the protocol standard format), numerical validity (parameter values ​​are within the legal range), and logical consistency (time nodes, power requirements, and access intervals are logically consistent). Plans that pass verification are marked as uploadable, while those that fail trigger automatic correction (e.g., filling in missing fields, converting formats) or error prompts (e.g., logging out of logs when values ​​are out of range). Once all qualified plans are included in the upload queue, the test control terminal sends an upload request to the scheduling plan simulation server via local process communication (since all three are deployed on the same computer device), attaching metadata such as test case identifiers and plan type. After server verification and permission, the complete plan data is uploaded to the server's dedicated storage directory via streaming. After the server receives the data and returns a successful upload confirmation, the test control terminal records the upload status and enters the time synchronization phase.

[0104] In the time synchronization phase, the test control terminal first calls the operating system's network configuration interface to obtain its own valid Internet Protocol (IP) address and verify its reachability. Then, it establishes a bidirectional communication connection with the power conversion system using the TCP / IP protocol, ensuring communication legitimacy through device identifier whitelist verification. After the connection is stable, it sends an address configuration command to the power conversion system, setting its own IP address to the network time protocol server's communication address and standard communication port (e.g., port 123) of the power conversion system. Once the power conversion system confirms the address configuration is effective, the test control terminal sends a time synchronization trigger command (including the highest synchronization priority and timeout threshold), prompting the power conversion system to initiate a time synchronization request to the network time protocol server based on the configured communication address. The network time protocol server returns its current time data (if the test case requires a fixed test time, this time has been modified according to the test control terminal's system time synchronization). After receiving this data, the power conversion system calibrates its own clock to ensure that the time deviation with the network time protocol server is within ±10 milliseconds. After completing time synchronization, it returns a confirmation message to the test control terminal.

[0105] After confirming that the power conversion system and the network time protocol server maintain time consistency, the test control terminal triggers a scheduling plan request operation from the power conversion system. For example, through an established communication connection, it sends a request trigger command to the power conversion system. This command specifies the logic for initiating the request based on its own operational needs, such as updating scheduling data upon reaching a preset time node or completing the previous stage of power output. Upon receiving the request trigger command, the power conversion system, considering its own operational status (such as the current power output stage and the time interval since the last request), sends a scheduling plan request to the scheduling plan simulation server, specifying the target scheduling plan type or time range. Upon receiving the scheduling plan request, the scheduling plan simulation server matches the corresponding target scheduling plan from its storage directory, encapsulates it into an adaptation message containing complete data according to the protocol specifications, and returns it to the power conversion system. After parsing the adaptation message and obtaining the scheduling data, the power conversion system strictly follows the time nodes and power control requirements in the target scheduling plan, adjusting the output power through its internal inverter module to achieve actual operational testing of remote power output control.

[0106] Through the above-described method embodiments, the test control terminal connects key links such as server management, data generation, synchronous calibration, and request triggering through standardized and automated operation logic. This not only ensures the consistency between the test scenario and the power company's dispatch protocol, but also avoids the errors and inefficiencies caused by manual operation. It is suitable for various application scenarios such as R&D testing and certification testing of power conversion systems, and can effectively verify the accuracy and reliability of its power control according to dispatch instructions.

[0107] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0108] Corresponding to the automated testing method described in the above embodiments, Figure 3 This is a schematic diagram of an automated testing device provided in an embodiment of this application. The device can be implemented as part or all of a computer device, which can be software, hardware, or a combination of both. Figure 4 The electronic device shown.

[0109] Reference Figure 3 This automated testing device is used in a test control terminal and includes: The generation unit 301 is used to dynamically generate at least one scheduling plan table based on test cases after the scheduling plan simulation server and the network time protocol server are automatically started.

[0110] Upload unit 302 is used to upload at least one scheduling plan table to the scheduling plan simulation server.

[0111] Control unit 303 is used to control the power conversion system to synchronize time with the network time protocol server, so that the power conversion system and the network time protocol server keep time consistent; under the premise that the power conversion system and the network time protocol server keep time consistent, the power conversion system is triggered to request a scheduling plan table from the scheduling plan simulation server according to its own operating needs, so that the power conversion system controls the output power according to the obtained scheduling plan table.

[0112] It is understood that the embodiments of the automated testing device and any implementation thereof correspond to the embodiments of the automated testing method and any implementation thereof. The technical effects corresponding to the embodiments of the automated testing device and any implementation thereof can be found in the technical effects corresponding to the aforementioned embodiments of the automated testing method and any implementation thereof, and will not be repeated here.

[0113] It should be noted that the automated testing device provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0114] The functional units and modules in the above embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of the embodiments of this application.

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

[0116] This application also provides an electronic device, which includes one or more processors and a memory; The memory is coupled to one or more processors. The memory is used to store computer program code, which includes computer instructions. One or more processors call the computer instructions to cause the electronic device to perform the automated testing method described above.

[0117] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 can be a mobile phone, smart screen, tablet computer, wearable electronic device, in-vehicle electronic device, augmented reality (AR) device, virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), projector, or a communication device such as a server, storage device, or base station, or a smart car, etc. This application embodiment does not impose any limitations on the specific type of electronic device.

[0118] The memory 401 can be used to store computer software programs 402 and modules. The processor 403 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 401. The memory 401 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device (such as audio data, telephone book, etc.). In addition, the memory 401 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0119] The processor 403 may include one or more processors such as a central processing unit (CPU), an application processor (AP), and a baseband processor. The processor can serve as the nerve center and command center of the wireless router. The processor 403 can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. The memory 401 can be used to store executable program code, including instructions. The processor 403 executes various functional applications and data processing of the network device by running the instructions stored in the memory. The memory 401 may include a program storage area and a data storage area, such as storing data for audio signals to be played. For example, the memory may be Double Data Rate Synchronous Dynamic Random Access Memory (DDR) or Flash memory.

[0120] This application also provides a computer-readable storage medium storing computer instructions; when the computer-readable storage medium is used on an electronic device, it causes the electronic device to perform the aforementioned automated testing method.

[0121] The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or can include one or more data storage devices such as servers or data centers that can be integrated with media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media, or semiconductor media (e.g., solid-state disks (SSDs)).

[0122] This application also provides a computer program product containing computer instructions, which, when run on an electronic device, enables the electronic device to execute the aforementioned automated testing method.

[0123] The computer storage medium and computer program product provided in the embodiments of this application are used to execute the methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects corresponding to the methods provided above, and will not be repeated here.

[0124] In the above embodiments, implementation can also be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc., and the storage medium can also include combinations of the above types of memory.

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

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

[0127] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the 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, mechanical, or other forms.

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

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

Claims

1. An automated test system, characterized by, The system comprises a test control terminal, a dispatch plan simulation server, a network time protocol server and a power conversion system; The test control terminal is connected with the dispatch plan simulation server, the network time protocol server and the power conversion system respectively, and is configured to automatically start the dispatch plan simulation server and the network time protocol server according to a test case, dynamically generate at least one dispatch plan table according to the test case, upload the at least one dispatch plan table to the dispatch plan simulation server, and control the power conversion system to perform time synchronization with the network time protocol server; The power conversion system is connected with the dispatch plan simulation server and the network time protocol server respectively, and is configured to request a target dispatch plan table from the dispatch plan simulation server according to its own operation requirement, and control output power according to the target dispatch plan table obtained on the premise of keeping time consistent with the network time protocol server.

2. The system of claim 1, wherein, The test control terminal dynamically generates at least one dispatch plan table according to the test case, including: The test control terminal obtains a target time parameter, a power control percentage parameter and a next access interval parameter in the test case; The test control terminal converts the target time parameter, the power control percentage parameter and the next access interval parameter into a processed target time parameter, a processed power control percentage parameter and a processed next access interval parameter in format and logic according to a dispatch plan protocol specification of a power company; At least one dispatch plan table is generated according to a scene requirement of the test case, the processed target time parameter, the processed power control percentage parameter and the processed next access interval parameter, wherein the type of the dispatch plan table includes at least one of an annual table, a monthly table or an update table.

3. The system of claim 1, wherein, The test control terminal controls the power conversion system to perform time synchronization with the network time protocol server, including: The test control terminal obtains its own Internet protocol address; The test control terminal establishes a communication connection with the power conversion system by taking the Internet protocol address as a communication address of the network time protocol server; The test control terminal sends an address configuration instruction to the power conversion system to set a network time protocol server address of the power conversion system as the communication address; The test control terminal sends a time synchronization trigger instruction to the power conversion system to prompt the power conversion system to initiate a time synchronization request based on the communication address, so that the power conversion system performs time synchronization with the network time protocol server.

4. The system of claim 1, wherein The test control terminal is further configured to modify its system time according to a requirement of the test case, so that the time of the network time protocol server changes synchronously with the system time of the test control terminal, and to send the time synchronization trigger instruction to prompt the power conversion system to keep time consistent with the network time protocol server after the time changes.

5. The system of claim 1, wherein, the test control terminal is further configured to collect actual output power data and actual response time data of the power conversion system during the process in which the power conversion system controls output power according to the target dispatch schedule; compare the actual output power data with expected output power data preset in the test case to determine a first deviation between the actual output power data and the expected output power data; compare the actual response time data with expected response time data preset in the test case to determine a second deviation between the actual response time data and the expected response time data; if both the first deviation and the second deviation are within corresponding preset allowable ranges, determine that the power conversion system meets target operation requirements; if the first deviation and / or the second deviation is not within the corresponding preset allowable range, determine that the power conversion system does not meet target operation requirements.

6. The system of any one of claims 1 to 5, wherein, the test control terminal, the dispatch schedule simulation server, and the network time protocol server are disposed in the same computer device; the test control terminal is preconfigured with a preset script containing server start and stop instructions and communication parameters, and the test control terminal executes the start instruction to start the dispatch schedule simulation server and the network time protocol server at the beginning of the test and executes the stop instruction to stop the dispatch schedule simulation server and the network time protocol server after the test is completed by calling the preset script.

7. The system of any one of claims 1 to 5, wherein, the dispatch schedule simulation server is configured to receive the dispatch schedule uploaded by the test control terminal; the dispatch schedule simulation server is further configured to return a message containing complete data of the dispatch schedule and adapted to the power conversion system according to a dispatch schedule protocol specification of a power company after receiving a dispatch schedule table request sent by the power conversion system.

8. The system of any one of claims 1 to 5, wherein, the test control terminal is further configured to perform data format verification on the at least one dispatch schedule according to a dispatch schedule protocol specification of a power company when uploading the at least one dispatch schedule to the dispatch schedule simulation server, so that the at least one dispatch schedule successfully uploaded all meet the receiving standards of the dispatch schedule simulation server.

9. An automated testing method, characterized by, The method is applied to a test control terminal and includes: after automatically starting a dispatch schedule simulation server and a network time protocol server, dynamically generating at least one dispatch schedule according to a test case; uploading the at least one dispatch schedule to the dispatch schedule simulation server; controlling a power conversion system to perform time synchronization with the network time protocol server, so that the power conversion system and the network time protocol server keep time consistent; Under the premise that the power conversion system keeps time consistent with the network time protocol server, the power conversion system triggers to request the dispatching plan table from the dispatching plan simulation server according to its own operation requirement, so that the power conversion system controls output power according to the obtained dispatching plan table.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program, so that the electronic device implements the method in claim 9.

Images