Equipment start-stop control method and device, equipment and storage medium
By using a device start-stop control method with customized test configuration parameters and verification rules, the problem of adapting device start-stop control to different protocols in traditional technologies has been solved, achieving efficient and accurate device status determination and anomaly handling.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-03-24
AI Technical Summary
Traditional equipment start-stop control technologies are difficult to adapt to devices with different communication protocols, making it difficult to coordinate equipment start-stop and unable to meet the needs of efficient management and control of complex production processes.
A device start-stop control method is provided, which obtains test configuration parameters input by the user, including the communication mode, controls the device under test to power on and establish communication, determines whether the device starts normally based on preset verification rules, and performs processing operations in abnormal situations.
It reduces the misjudgment rate of equipment status, adapts to different automated equipment, eliminates the need for repeated software development, and improves testing efficiency and accuracy.
Smart Images
Figure CN121728136A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of industrial automation control technology, and in particular to a method, apparatus, device and storage medium for equipment start-stop control. Background Technology
[0002] In the fields of automation control, such as industrial production and rail transportation, equipment start-stop control is a core component for ensuring stable system operation and improving production efficiency and operational safety. Traditional equipment start-stop control technologies have many shortcomings and are unable to meet the intelligent management and control needs of various industries, especially in terms of software.
[0003] In industrial production scenarios, production lines consist of numerous devices using various communication protocols. For example, robotic arms on automated production lines may use a dedicated industrial Ethernet protocol for communication, while material handling equipment may use the Modbus protocol. Traditional start-stop control software struggles to adapt to these different protocols simultaneously, leading to difficulties in coordinated start-stop between devices and failing to meet the efficient management requirements of complex production processes. Summary of the Invention
[0004] In view of this, this disclosure proposes a method, apparatus, device and storage medium for controlling the start and stop of equipment.
[0005] According to one aspect of this disclosure, a device start-stop control method is provided, comprising: Obtain test configuration parameters input by the user, including the communication mode; Based on the aforementioned test configuration parameters, the device under test is powered on and a timer is started. The test configuration parameters are used to establish communication with the device under test, and the response of the device under test is parsed based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time. In response to an abnormal startup of the device under test, an exception handling operation is performed.
[0006] In one possible implementation, the test configuration parameters further include at least one of device address information, communication protocol parameters, delay duration parameters, test mode, or TRDP simulation enable parameters; The communication modes include network mode and serial port mode.
[0007] In one possible implementation, the step of establishing communication with the device under test (DUT) according to the test configuration parameters and parsing the DUT's response based on preset verification rules to determine whether the DUT has started normally within a preset maximum allowable startup time includes: In response to the communication mode being the network mode and the communication protocol being TCP, a TCP connection request is initiated to the specified port of the device under test; If a connection success or connection rejection response is received within the maximum allowed startup time, the device under test is determined to have started normally. If no valid response or a connection failure response is received within the maximum allowed startup time, the device under test is determined to have started abnormally.
[0008] In one possible implementation, the step of establishing communication with the device under test (DUT) according to the test configuration parameters and parsing the DUT's response based on preset verification rules to determine whether the DUT has started normally within a preset maximum allowable startup time includes: In response to the communication mode being the network mode and the communication protocol being UDP, the system listens on a specified local port to receive UDP packets from the device under test. If a UDP packet that meets the preset conditions is received within the maximum allowed startup time, the device under test is determined to have started normally. The preset conditions include at least one of the following: the packet length matches the preset data width, the byte value of the specified offset in the packet matches the preset flag bit, and the sender address matches the preset address. If no UDP packet meeting the preset conditions is received within the maximum allowed startup time, the device under test is determined to have a startup abnormality.
[0009] In one possible implementation, the step of establishing communication with the device under test (DUT) according to the test configuration parameters and parsing the DUT's response based on preset verification rules to determine whether the DUT has started normally within a preset maximum allowable startup time includes: In response to the communication mode being the serial port mode, the specified serial port is listened to to receive string data from the device under test; If the string data received within the maximum allowed startup time contains a preset successful matching string, then the device under test is determined to have started normally. If the string data received within the maximum allowed startup time contains a preset failure matching string, or if no response containing the success matching string is received, the device under test is determined to have a startup abnormality.
[0010] In one possible implementation, the step of establishing communication with the device under test (DUT) according to the test configuration parameters and parsing the DUT's response based on preset verification rules to determine whether the DUT has started normally within a preset maximum allowable startup time includes: In response to the TRDP simulation enable parameter, simulated TRDP protocol data packets are periodically sent to the device under test.
[0011] In one possible implementation, the device start / stop control method further includes: Save the currently set test configuration parameters as a configuration file, and load the configuration file in subsequent tests to reuse the test configuration parameters.
[0012] According to another aspect of this disclosure, a device for starting and stopping equipment is provided, comprising: The configuration module is configured to acquire test configuration parameters input by the user, the test configuration parameters including the communication mode; The control module is configured to power on the device under test and start a timer based on the test configuration parameters. The verification module is configured to establish communication with the device under test according to the test configuration parameters, and to parse the response of the device under test based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time. The processing module is configured to perform exception handling operations in response to an abnormal startup of the device under test.
[0013] According to another aspect of this disclosure, a device start / stop control device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method described in any of the above embodiments when executing the executable instructions.
[0014] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is provided, on which computer program instructions are stored, characterized in that the computer program instructions, when executed by a processor, implement the method described in any of the above embodiments.
[0015] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: Users configure test parameters before testing through the graphical interface of the start-stop test tool corresponding to the device start-stop control method. These parameters determine subsequent control, verification, and processing behaviors. Compared to related technologies that rely solely on simple "on / off" feedback when judging device status, without considering key factors such as message integrity and timing rationality, resulting in a high false positive rate, the embodiments of this disclosure utilize configurable verification rules to determine the status of the device under test, thereby reducing the false positive rate. Therefore, the embodiments of this disclosure, through customizable test configuration parameters and verification rules, can adapt to different automated devices without requiring repeated software development for different automated devices.
[0016] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description
[0017] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.
[0018] Figure 1 This is a flowchart illustrating a device start-stop control method according to some embodiments of the present disclosure; Figure 2 This is a system architecture adapted to a device start-stop control method shown in some embodiments of this disclosure; Figure 3 This is a test flowchart illustrating the use of TCP as the communication protocol according to some embodiments of this disclosure; Figure 4 This is a test flowchart illustrating the communication protocol as UDP according to some embodiments of this disclosure; Figure 5 This is a flowchart illustrating a serial port mode test according to some embodiments of the present disclosure; Figure 6 This is a flowchart illustrating start-stop and stability tests according to some embodiments of this disclosure; Figure 7 This is a block diagram of a device start-stop control apparatus according to some embodiments of the present disclosure; Figure 8 This is a block diagram of a device start-stop control device according to some embodiments of the present disclosure. Detailed Implementation
[0019] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.
[0020] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.
[0021] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.
[0022] In the fields of automation control, such as industrial production and rail transportation, equipment start-stop control is a core element in ensuring stable system operation and improving production efficiency and operational safety. Traditional equipment start-stop control technologies have many shortcomings and struggle to meet the intelligent management and control needs of various industries, particularly at the software level. In industrial production scenarios, production lines contain numerous devices with different communication protocols. For example, robotic arms on automated production lines may use a dedicated industrial Ethernet protocol for communication, while material handling equipment may use the Modbus protocol. Traditional start-stop control software struggles to adapt to these different protocols simultaneously, leading to difficulties in coordinated start-stop between devices and failing to meet the efficient management and control requirements of complex production processes.
[0023] In view of this, the present disclosure provides a device, apparatus, equipment and storage medium for device start-stop control, wherein the device start-stop control method is deployed on a host that can communicate with the automated equipment, i.e., the device under test. Figure 1 This is a flowchart illustrating a device start-stop control method according to some embodiments of this disclosure, such as... Figure 1 As shown, the device start / stop control method includes the following steps: Step S1: Obtain the test configuration parameters input by the user, including the communication mode.
[0024] Users configure parameters before testing using the graphical interface of the start-stop test tool corresponding to the device start-stop control method. These parameters determine the subsequent control, verification, and processing behavior.
[0025] Step S2: Based on the test configuration parameters, power on the device under test and start the timer.
[0026] The programmable power supply powers the device under test and simultaneously starts the timing and statistics module.
[0027] Step S3: Establish communication with the device under test according to the test configuration parameters, and parse the response of the device under test based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time.
[0028] Compared to related technologies that rely solely on simple "on / off" feedback when judging device status without considering key factors such as message integrity and timing rationality, resulting in a high false judgment rate, the embodiments of this disclosure utilize configurable verification rules to determine the status of the device under test, thereby reducing the false judgment rate.
[0029] Step S4: In response to the abnormal startup of the device under test, perform the abnormal handling operation.
[0030] The abnormal handling operations include at least one of triggering an alarm, locking the output of the programmable power supply, pausing the test task, or saving the fault information log.
[0031] Therefore, the embodiments of this disclosure, through customizable test configuration parameters and verification rules, can be adapted to different automated devices without the need for repeated software development for different automated devices.
[0032] In some embodiments, in response to the normal startup of the device under test (DUT), i.e., under normal startup scenarios, the counter statistics are updated to count the number of task executions; key indicators, such as response latency, are recorded; and subsequent functional testing modules are triggered. The recorded data provides important information for subsequent evaluation of the network performance of the DUT and troubleshooting.
[0033] In response to abnormal startup of the device under test (DUT), the system provides immediate alarms: activating a buzzer and recording a fault in the results section of the start / stop test tool. Timely alarms quickly alert users to the test anomaly, allowing for prompt action. Information retention: The system automatically captures the current test interface and saves the error execution results to the log directory. Saved log information facilitates in-depth analysis and summarization of anomalies. Power lock: The power control interface is locked to prevent accidental power manipulation under abnormal conditions, ensuring the safety of the device and test environment. Task suspension: All test threads are suspended, awaiting manual intervention. This ensures the test process can be stopped promptly in case of anomalies, avoiding further errors and potential risks. Furthermore, after each task is completed, the start / stop test tool generates a table document summarizing the test results, including fault type, occurrence time, timeout duration, and cumulative number of occurrences, stored in the log directory. This facilitates rapid fault location and in-depth analysis by technical personnel.
[0034] Figure 2 This is a system architecture adapted to a device start / stop control method shown in some embodiments of this disclosure, such as... Figure 2 As shown, the system includes a PC (host), a device under test (DUT), and a programmable power supply. The device start-stop control method of this embodiment is installed on the PC as start-stop software, allowing users to customize parameter settings. The programmable power supply provides a stable power output, supporting precise voltage and current adjustment. The DUT, as the test object, interacts with the start-stop test tool. The PC is used for deploying the start-stop test tool, monitoring test progress, collecting error logs, and other functions. The start-stop test tool is responsible for the start-stop control, communication verification, data recording, and transmission of the DUT. The PC communicates with the DUT via network cable, serial port, etc., and connects to the programmable power supply via an RS232 serial port for remote control.
[0035] In some embodiments, the device start-stop control method further includes: actively detecting the programmable power supply via a communication serial port or network server.
[0036] For example, upon initial startup, the start-stop test tool actively detects the power supply device via a communication serial port (RS232) or a network server. Once a communication connection is successfully established, the user can control the start-stop of the programmable power supply and configure its output parameters through the start-stop test tool. This flexible connection method fully considers the interface characteristics of different power supply devices, ensuring the universality of power supply control. The start-stop test tool receives real-time feedback on the power supply status, including voltage, current values, and output status, and displays this information intuitively in the form of a time-domain waveform. In this way, users can clearly understand the power supply's operating status, promptly detect abnormal fluctuations in the power supply output, and ensure the stability of the test.
[0037] In some embodiments, the test configuration parameters may further include at least one of device address information, communication protocol parameters, delay duration parameters, test mode, or TRDP simulation enable parameters.
[0038] Users can configure device address information, including setting the local IP address, port, and IP address of the device under test; and communication protocol parameters, which explicitly specify the data communication method between the device under test and the start / stop test tool. These include TCP (Transmission Control Protocol), UDP (User Datagram Protocol), TRDP (Transit Real-Time Data Protocol), and serial communication.
[0039] The testing modes include single-test mode, loop execution mode, and error-stop mode. Users can select the appropriate testing mode based on the actual operating conditions of the device under test (DUT) and the testing objectives. Single-test mode is suitable for scenarios involving one-time functional verification or simple performance testing of the DUT, enabling quick acquisition of test results for a single task execution. Loop execution mode is used for long-term, continuous stability testing or performance monitoring of the DUT, comprehensively evaluating the device's performance at different operational stages through multiple loop executions of the test task. Error-stop mode immediately stops the test if an error or anomaly is detected in the DUT, allowing users to promptly troubleshoot and resolve issues; this mode is suitable for testing scenarios with high reliability requirements.
[0040] Furthermore, for the start-stop testing of equipment under test in the transportation industry, the tool supports issuing commands and data via the TRDP (Train Real-Time Data Protocol) to achieve effective control of the equipment under test. This function is only applicable to start-stop testing scenarios. Users can enable the TRDP simulation function by configuring the TRDP simulation enable parameters.
[0041] Specifically, in some embodiments, communication is established with the device under test according to the test configuration parameters, and the response of the device under test is parsed based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time, including periodically sending simulated TRDP protocol data packets to the device under test in response to the TRDP simulation enable parameters.
[0042] Based on the actual operating conditions of the device under test (DUT) and the testing objectives, set an appropriate TRDP protocol data message transmission period. For example, if the DUT needs to receive train status information in real time, the transmission period can be set to a shorter interval, such as 30 milliseconds; if real-time requirements are not high, the transmission period can be appropriately extended, such as 1 second. The TRDP protocol data message content can be simulated train status information, such as train speed, position, and operating status; or it can be control commands, such as start, stop, and acceleration commands. The TRDP protocol data message content can be set from preset data templates according to actual testing needs.
[0043] The user-configured test parameters include two communication modes: network mode and serial port mode. Users can manually switch between these modes based on the physical connection method of the device under test (WAN or serial port). In serial port mode, the test tool automatically invokes the serial communication protocol, focusing on handling data interaction between devices via the COM interface. In network mode, the tool automatically adapts to TCP / UDP protocols for network-level data transmission and interaction. Network mode is further divided into "ping" and "data reception" options, with "ping" corresponding to TCP communication and "data reception" corresponding to UDP communication. TCP communication is used by default; users can manually switch to UDP if needed. Users can select the appropriate communication mode based on the communication requirements of the device under test in different network environments to meet diverse testing scenarios.
[0044] Furthermore, after switching to network mode or serial port mode, the corresponding parameters need to be configured automatically or manually.
[0045] Specifically, after switching to network mode, the automatic configuration includes the following parameters: local IP address, which is automatically identified and displayed by the start / stop test tool. If the system has multiple network cards and corresponding addresses, the first identified address will be displayed by default, and the remaining addresses will be automatically updated to the drop-down options for users to select according to their actual needs; listening port, with a default value of 8000; authentication method, which defaults to TCP protocol, but provides a UDP protocol option for users to manually switch according to their testing needs. After switching to network mode, the manual configuration includes the following parameters: IP address of the device under test, which needs to be manually set by the user according to the device under test; multicast address, which needs to be manually enabled and configured according to the actual needs of the device.
[0046] After switching to serial port mode, the automatic configuration includes the following parameters: COM interface, which automatically identifies the connected COM interface. If multiple COM interfaces exist, the first identified result is displayed by default, simplifying the user operation process; Baud rate, with a default value of 115200, while also providing commonly used baud rate options such as 9600 and 1500000, which users can select according to the serial communication rate requirements of the device under test; Success string and fault string: the default values are set to "login" and "timeout" respectively, serving as the initial reference for judging the device's communication status. After switching to serial port mode, the manual configuration includes the following parameters: If multiple COM interfaces exist, the target interface must be manually selected by the user; the success string and fault string can be manually modified according to the actual information returned by the device.
[0047] In some embodiments, the test configuration parameters also include preset values, such as the power-on / power-off delay duration of the device under test, the communication timeout duration, and the TRDP simulated transmission duration. For example, the default value for the TRDP simulated enable duration is 30 seconds (disabled state), the default value for the communication timeout duration is 150 seconds, the default value for the power-off delay duration is 5 seconds, the default value for the power-on delay duration is 30 seconds, and the default value for the stability test duration is 60 minutes. These default parameters are optimized based on common industry scenarios and can be used directly when there are no special requirements. If the device under test has personalized requirements, all parameters can be manually adjusted. Through the configuration mechanism of "manual switching mode + automatic parameter adaptation by tools," the accuracy of communication method selection is ensured, and configuration efficiency is improved through preset default parameters, balancing the flexibility and versatility of the test scenario.
[0048] In some embodiments, the device start / stop control method further includes: saving the currently set test configuration parameters as a configuration file, and loading the configuration file in subsequent tests to reuse the test configuration parameters. The start / stop test tool supports saving the currently configured task configuration parameters and global configuration parameters (including IP address and port in network mode, COM interface and baud rate in serial mode, etc.) as INI format files. In subsequent tests, users can directly load the configuration file, avoiding repeated tedious configuration operations and significantly improving test efficiency, especially suitable for scenarios that require multiple identical or similar tests.
[0049] Figure 3 This is a test flowchart illustrating a TCP communication protocol according to some embodiments of this disclosure, such as... Figure 3 As shown, communication is established with the device under test (DUT) according to the test configuration parameters, and the response of the DUT is parsed based on preset verification rules to determine whether the DUT starts normally within the preset maximum allowable startup time. This includes the following steps: Step S01: In response to the communication mode being network mode and the communication protocol being TCP, initiate a TCP connection request to the specified port of the device under test.
[0050] Step S02: If a response indicating successful connection or connection rejection is received within the maximum allowed startup time, the device under test is determined to have started normally.
[0051] Step S03: If no valid response is received or a connection failure response is received within the maximum allowed startup time, the device under test is determined to have an abnormal startup.
[0052] The start-up and shutdown test tool initiates a TCP CONNECT connection request to the preset target port of the device under test, and verifies the communication status by analyzing the response messages, thereby determining whether the device under test has completed normal startup within the specified time limit.
[0053] For example, the device under test (DUT) is considered online and enters the normal startup scenario if the following conditions are met simultaneously: Connection successful: The CONNECT function returns 0, indicating that the TCP three-way handshake is complete and the target port of the DUT is listening and responding normally; Connection rejected: CONNECT returns a "connection rejected" error (e.g., ECONNREFUDED), indicating that the DUT is online but the target port is not open, and is still considered online; Timing verification: The response time from initiating the connection to a successful connection is ≤ the maximum allowed startup time set by the user. If any of the following abnormal responses occur, the DUT is immediately considered offline and the test is terminated, i.e., the DUT startup is considered abnormal: a) Connection failure: Includes connection timeout (no response received), network unreachable (e.g., ENETUNREACH), protocol error (e.g., EPROTO), etc.; Time limit exceeded: The total time from initiating the connection to the final status determination is > the maximum allowed startup time set by the user.
[0054] Figure 4 This is a test flowchart illustrating a communication protocol of UDP according to some embodiments of this disclosure, such as... Figure 4 As shown, communication is established with the device under test (DUT) according to the test configuration parameters, and the response of the DUT is parsed based on preset verification rules to determine whether the DUT starts normally within the preset maximum allowable startup time. This includes the following steps: Step S001: In response to the communication mode being network mode and the communication protocol being UDP, listen on the specified local port to receive UDP packets from the device under test.
[0055] Step S002: If a UDP packet that meets the preset conditions is received within the maximum allowed startup time, the device under test is determined to have started normally. The preset conditions include at least one of the following: the packet length matches the preset data width, the byte value of the specified offset in the packet matches the preset flag bit, and the sender address matches the preset address.
[0056] Step S003: If no UDP packet meeting the preset conditions is received within the maximum allowed startup time, the device under test is determined to have a startup abnormality.
[0057] The use of the UDP protocol for communication also enables this disclosure to perform device stability testing. Figure 6 This is a flowchart illustrating start-stop and stability tests according to some embodiments of this disclosure, such as... Figure 6 As shown, the start / stop test tool supports device stability monitoring without enabling power control. This feature fully considers the stability assessment needs of the device under test during long-term operation.
[0058] Specifically, the start / stop test tool is in a listening state, waiting for UDP packets to arrive. When a UDP packet is sent to the bound local IP address and listening port, the operating system passes the packet to the test tool. It also supports receiving UDP multicast and unicast packets. After receiving the data, the test tool parses it according to the set data offset, data width, and data mask. It processes UDP multicast and unicast packets through a unified data receiving interface, parses the packet content based on the preset data width, and verifies the device's online status through specific byte flags.
[0059] The device under test (DUT) is considered to have started normally if all of the following conditions are met: the sender's IP address and port match the preset values; a complete message is successfully received with a length matching the preset data width; and the byte value at the specified offset in the message equals the preset expected value. The DUT is considered to have started abnormally if any of the following conditions are met: no valid messages are received within the preset timeout period; the extracted flag value is inconsistent with the expected value; or the length of the received message is insufficient to include the flags or the sender's IP address and port do not match the preset values.
[0060] Figure 5 This is a flowchart illustrating a serial port mode test according to some embodiments of the present disclosure, such as... Figure 5 As shown, communication is established with the device under test (DUT) according to the test configuration parameters, and the response of the DUT is parsed based on preset verification rules to determine whether the DUT starts normally within the preset maximum allowable startup time. This includes the following steps: Step S0001: In response to the communication mode being serial port mode, listen to the specified serial port to receive string data from the device under test.
[0061] Step S0002: If the string data received within the maximum allowed startup time contains a preset successful matching string, then the device under test is determined to have started normally.
[0062] Step S0003: If the string data received within the maximum allowed startup time contains a preset failure matching string, or if no response containing a success matching string is received, then the device under test is determined to have a startup abnormality.
[0063] Specifically, a separate thread is started to read data from the serial port buffer in real time, splitting the response content line by line, for example, using "\r\n" or "\n" as the delimiter. If the line content contains a preset success string, such as "READY", it is marked as a valid response, i.e., a successful match. If the line content contains a preset failure string, such as "ERROR", it is marked as an invalid response, i.e., a failed match. If no preset string is matched, it continues to wait for subsequent data, and a timeout is determined, i.e., no match.
[0064] The device under test (DUT) is considered to have started normally if all of the following conditions are met: at least one complete response line is received within the maximum allowed startup time, and the content of this line exactly matches a preset success string, such as "READY"; and the effective response time is less than or equal to the maximum allowed startup time. The DUT is considered to have started abnormally if any of the following conditions are met: a response line is received but contains a preset failure string, such as "ERROR"; garbled or non-text data is received and cannot be parsed into a valid string; or the timer exceeds the maximum allowed startup time and no response matching the success string is received.
[0065] This disclosure provides a device start-stop control method that supports multiple protocols including TCP, UDP, TRDP, and serial communication. Combined with user-defined verification rules (such as UDP packet byte flags and serial port matching strings), it can be adapted to devices under test in various industries, including industrial equipment, rail transit terminals, and smart hardware. This eliminates the need for repetitive software development for different industries, significantly improving reusability. It supports fully customizable test parameters (power-on delay, communication timeout, etc.), requiring only protocol parameter configuration for adaptation without modifying the core software code, enhancing configuration flexibility and scalability. The fault determination logic is complex, supporting verification of data width and data flag value matching, improving the accuracy of device status judgment. It forms an automated processing flow of "parameter configuration - start-stop control - status monitoring - anomaly handling - data recording": in case of an anomaly, it automatically triggers a buzzer alarm, power lock, fault page screenshot, and log recording (including fault type, time, etc.), possessing a comprehensive anomaly handling mechanism, reducing manpower input, and improving testing efficiency.
[0066] According to another aspect of this disclosure, a device for starting and stopping equipment is provided. Figure 7 This is a block diagram of a device start / stop control apparatus according to some embodiments of the present disclosure, such as... Figure 7 As shown, the device start / stop control unit includes: a configuration module 110, a control module 120, a verification module 130, and a processing module 140.
[0067] The configuration module 110 is configured to acquire test configuration parameters input by the user, including the communication mode. The control module 120 is configured to power on the device under test (DUT) and start a timer based on the test configuration parameters. The verification module 130 is configured to establish communication with the DUT according to the test configuration parameters and parse the DUT's response based on preset verification rules to determine whether the DUT has started normally within the preset maximum allowable startup time. The processing module 140 is configured to perform exception handling operations in response to a startup exception of the DUT.
[0068] According to another aspect of this disclosure, a device start / stop control device 200 is also provided. Figure 8This is a block diagram of a device start / stop control device according to some embodiments of the present disclosure, such as... Figure 8 As shown, the device start / stop control device 200 of this embodiment includes a processor 210 and a memory 220 for storing executable instructions of the processor 210. The processor 210 is configured to implement any of the aforementioned device start / stop control methods when executing the executable instructions.
[0069] It should be noted here that the number of processors 210 can be one or more. Furthermore, the device start / stop control device 200 in this embodiment may also include an input device 230 and an output device 240. The processors 210, memory 220, input device 230, and output device 240 can be connected via a bus or other means, without specific limitations here.
[0070] The memory 220, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the device start-stop control method of this embodiment. The processor 210 executes various functional applications and data processing of the device start-stop control device 200 by running the software program or module stored in the memory 220.
[0071] Input device 230 can be used to receive input digital numbers or signals. These signals may include key signals related to user settings and function control of the device / terminal / server. Output device 240 may include a display device such as a screen.
[0072] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is also provided, on which computer program instructions are stored, which, when executed by processor 210, implement any of the aforementioned device start / stop control methods.
[0073] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A method for controlling the start and stop of equipment, characterized in that, include: Obtain test configuration parameters input by the user, including the communication mode; Based on the aforementioned test configuration parameters, the device under test is powered on and a timer is started. The test configuration parameters are used to establish communication with the device under test, and the response of the device under test is parsed based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time. In response to an abnormal startup of the device under test, an exception handling operation is performed.
2. The equipment start / stop control method according to claim 1, characterized in that, The test configuration parameters also include at least one of the following: device address information, communication protocol parameters, delay duration parameters, test mode or TRDP simulation enable parameters; The communication modes include network mode and serial port mode.
3. The equipment start-stop control method according to claim 2, characterized in that, The step of establishing communication with the device under test according to the test configuration parameters and parsing the response of the device under test based on preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time includes: In response to the communication mode being the network mode and the communication protocol being TCP, a TCP connection request is initiated to the specified port of the device under test; If a connection success or connection rejection response is received within the maximum allowed startup time, the device under test is determined to have started normally. If no valid response or a connection failure response is received within the maximum allowed startup time, the device under test is determined to have started abnormally.
4. The equipment start-stop control method according to claim 2, characterized in that, The step of establishing communication with the device under test according to the test configuration parameters and parsing the response of the device under test based on preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time includes: In response to the communication mode being the network mode and the communication protocol being UDP, the system listens on a specified local port to receive UDP packets from the device under test. If a UDP packet that meets the preset conditions is received within the maximum allowed startup time, the device under test is determined to have started normally. The preset conditions include at least one of the following: the packet length matches the preset data width, the byte value of the specified offset in the packet matches the preset flag bit, and the sender address matches the preset address. If no UDP packet meeting the preset conditions is received within the maximum allowed startup time, the device under test is determined to have a startup abnormality.
5. The equipment start-stop control method according to claim 2, characterized in that, The step of establishing communication with the device under test according to the test configuration parameters and parsing the response of the device under test based on preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time includes: In response to the communication mode being the serial port mode, the specified serial port is listened to to receive string data from the device under test; If the string data received within the maximum allowed startup time contains a preset successful matching string, then the device under test is determined to have started normally. If the string data received within the maximum allowed startup time contains a preset failure matching string, or if no response containing the success matching string is received, the device under test is determined to have a startup abnormality.
6. The equipment start-stop control method according to claim 2, characterized in that, The step of establishing communication with the device under test according to the test configuration parameters and parsing the response of the device under test based on preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time includes: In response to the TRDP simulation enable parameter, simulated TRDP protocol data packets are periodically sent to the device under test.
7. The equipment start-stop control method according to any one of claims 1 to 6, characterized in that, The equipment start / stop control method further includes: Save the currently set test configuration parameters as a configuration file, and load the configuration file in subsequent tests to reuse the test configuration parameters.
8. A device for starting and stopping equipment, characterized in that, include: The configuration module is configured to acquire test configuration parameters input by the user, the test configuration parameters including the communication mode; The control module is configured to power on the device under test and start a timer based on the test configuration parameters. The verification module is configured to establish communication with the device under test according to the test configuration parameters, and to parse the response of the device under test based on the preset verification rules to determine whether the device under test starts normally within the preset maximum allowable startup time. The processing module is configured to perform exception handling operations in response to an abnormal startup of the device under test.
9. A device for starting and stopping equipment, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1 to 7 when executing the executable instructions.
10. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.