Method and system for testing starting time of embedded operating system and upper computer

Abstract

The invention relates to the technical field of embedded operating system testing, and discloses an embedded operating system starting time testing method and system and an upper computer, the method is applied to the upper computer, the upper computer is in communication connection with a programmable power supply and a to-be-tested device, and the to-be-tested device is provided with a to-be-tested embedded operating system. A pre-installed auxiliary timing application is included in a to-be-tested embedded operating system, and the method comprises the steps that a programmable power supply is controlled to supply power to a to-be-tested device, a power-on event returned by the programmable power supply is received, and power-on time of the power supply is obtained according to the power-on event; receiving a user mode process starting event which is sent by the to-be-tested device and marked by the auxiliary timing application, and obtaining starting completion time according to the user mode process starting event; and determining the starting time of the to-be-tested embedded operating system according to the power-on time of the power supply and the starting completion time. According to the technical scheme, the upper computer, the programmable power supply and the auxiliary timing application are used for achieving test universality, and multiple repeated tests are supported.

Description

Technical Field

[0001] The present application relates to the technical field of embedded operating system testing, and in particular to an embedded operating system startup time testing method, system and host computer. Background Art

[0002] Among various time performance indicators of embedded operating systems, startup time is one of the important indicators for evaluating the performance of embedded operating systems.

[0003] Currently, manual timing, third-party performance testing tools, system internal software logs, and hardware timers are often used to test the startup time of embedded operating systems. However, manual timing is not convenient for repeated testing, and the other three testing methods are not universal and cannot be applied to various embedded operating systems.

[0004] In summary, how to achieve universality of testing and support multiple repeated tests is a technical problem that currently needs to be solved urgently by those skilled in the art. Summary of the invention

[0005] In view of this, the purpose of this application is to provide an embedded operating system startup time testing method, system and host computer, which are used to achieve the universality of the test and support multiple repeated tests.

[0006] In order to achieve the above objectives, this application provides the following technical solutions:

[0007] A method for testing the startup time of an embedded operating system is applied to a host computer, the host computer is communicatively connected with a programmable power supply and a device to be tested, the device to be tested is installed with the embedded operating system to be tested, the embedded operating system to be tested includes a pre-installed auxiliary timing application, and the method for testing the startup time of the embedded operating system comprises: controlling the programmable power supply to supply power to the device to be tested, receiving a power-on event returned by the programmable power supply, and obtaining a power-on time according to the power-on event; receiving a user state process start event sent by the device to be tested and marked by the auxiliary timing application, and obtaining a startup completion time according to the user state process start event; and determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time.

[0008] Optionally, pre-installing an auxiliary timing application includes: controlling the programmable power supply to supply power to the device under test, clearing the user state process in the embedded operation under test; installing the auxiliary timing application in the embedded operating system under test; controlling the programmable power supply to turn off to power off the device under test.

[0009] Optionally, controlling the programmable power supply to supply power to the device under test includes: after the embedded operating system under test is completely shut down or powered off, controlling the programmable power supply to supply power to the device under test;

[0010] Determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time includes: determining a single cold startup time of the embedded operating system to be tested according to the power-on time and the startup completion time.

[0011] Optionally, after determining a single cold start time of the embedded operating system to be tested based on the power-on time and the startup completion time, it also includes: controlling the programmable power supply to be turned off, waiting for a first preset time and then returning to execute the step of controlling the programmable power supply to supply power to the device to be tested until the number of tests reaches a first preset number of times; determining the cold start time of the embedded operating system to be tested based on the first preset number of single cold start times.

[0012] Optionally, the device under test does not include a power storage device.

[0013] Optionally, the device under test includes a power storage device, and before controlling the programmable power supply to supply power to the device under test, the method further includes: controlling the embedded operating system under test to enter a low power consumption mode;

[0014] Receiving a user state process start event sent by the device under test and marked by the auxiliary timing application, and acquiring a startup completion time according to the user state process start event, including: receiving a user state process resume event sent by the device under test and marked by the auxiliary timing application, and acquiring a process resume time according to the user state process resume event;

[0015] Determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time includes: determining a single low-power wake-up time of the embedded operating system to be tested according to the power-on time and the process recovery time.

[0016] Optionally, controlling the embedded operating system under test to enter a low power consumption mode includes: controlling the programmable power supply to supply power to the device under test; controlling the programmable power supply to turn off after the embedded operating system under test completes startup; and receiving a user mode process sleep event sent by the device under test and marked by the auxiliary timing application.

[0017] Optionally, after controlling the program-controlled power supply to be turned off, the method further includes: receiving a power-off event returned by the program-controlled power supply, and acquiring a power-off time according to the power-off event;

[0018] After receiving the user state process sleep event sent by the device under test and marked by the auxiliary timing application, the method further includes: acquiring the system sleep time according to the user state process sleep event;

[0019] A single low power consumption entry time of the embedded operating system to be tested is determined according to the power off time and the system sleep time.

[0020] Optionally, after determining the single low-power wake-up time of the embedded operating system to be tested based on the power-on time and the process recovery time, it also includes: waiting for a second preset time and then returning to execute the step of controlling the programmable power supply to be turned off until the number of tests reaches a second preset number of times; determining the low-power wake-up time of the embedded operating system to be tested based on the second preset number of single low-power wake-up times.

[0021] Optionally, the method further includes: determining the low power consumption entry time of the embedded operating system to be tested according to the second preset number of single low power consumption entry times.

[0022] Optionally, it also includes: controlling the programmable power supply to maintain a power supply state; sending a restart command to the device under test and obtaining a restart time; receiving a user state process start event sent by the device under test and marked by the auxiliary timing application, and obtaining a restart completion time according to the user state process start event; determining a single hot start time of the embedded operating system under test according to the restart time and the restart completion time.

[0023] Optionally, after determining the single hot start time of the embedded operating system to be tested according to the restart time and the restart completion time, it also includes: waiting for a third preset time and then returning to execute the step of sending a restart command to the device to be tested until the number of tests reaches a third preset number of times; determining the hot start time of the embedded operating system to be tested according to the third preset number of single hot start times.

[0024] Optionally, the host computer provides a unified time reference system to obtain corresponding time based on the unified time reference system.

[0025] An embedded operating system startup time test system comprises a host computer and a programmable power supply, wherein the host computer is communicatively connected to the programmable power supply, the host computer is also used to communicate with a device to be tested, the programmable power supply is also used to connect to the device to be tested, the device to be tested is installed with an embedded operating system to be tested, the embedded operating system to be tested includes a pre-installed auxiliary timing application, wherein: the host computer is used to implement the steps of the embedded operating system startup time test method as described in any one of the above items.

[0026] Optionally, the programmable power supply includes a programmable switch and a power supply, wherein: the programmable switch is connected between the power supply and the device under test, and the programmable switch is communicatively connected to the host computer; and the power supply is used to power the device under test when the programmable switch is turned off.

[0027] A host computer is used to communicate with a programmable power supply and a device to be tested, wherein the device to be tested is installed with an embedded operating system to be tested, and the embedded operating system to be tested includes a pre-installed auxiliary timing application; the host computer is used to implement the steps of the embedded operating system startup time test method as described in any one of the above items.

[0028] The present application provides a method, system and host computer for testing the startup time of an embedded operating system, wherein the method is applied to the host computer, the host computer is communicatively connected with a programmable power supply and a device to be tested, the device to be tested is installed with the embedded operating system to be tested, and the embedded operating system to be tested includes a pre-installed auxiliary timing application, and the method comprises: controlling the programmable power supply to supply power to the device to be tested, receiving a power-on event returned by the programmable power supply, and obtaining the power-on time of the power supply according to the power-on event; receiving a user-mode process start event sent by the device to be tested and marked by the auxiliary timing application, and obtaining the startup completion time according to the user-mode process start event; and determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time.

[0029] The above technical scheme disclosed in the present application, the host computer controls the program-controlled power supply to supply power to the device under test and receives the power-on event returned by the program-controlled power supply, and obtains the power-on time of the power supply according to the power-on event. After the program-controlled power supply supplies power to the device under test, the embedded operating system under test starts the startup process. When the user state process in the embedded operating system under test is started, the auxiliary timing application pre-installed in the embedded operating system under test can mark the user state process, and the device under test can send the marked user state process start event to the host computer, so that the host computer obtains the startup completion time according to the user state process start event, and then the host computer determines the startup time of the embedded operating system under test according to the power-on time and the startup completion time. By using the auxiliary timing application installed in the host computer, the program-controlled power supply and the device under test, various embedded operating systems can be tested for startup time, the universality of the test method can be achieved, and multiple repeated tests of the startup time can be supported. Moreover, the test process is simple and clear, easy to operate, so that even developers without professional testing background can easily get started. In addition, the testing process is non-invasive and does not require any modifications to the system hardware and driver layer to avoid introducing unstable factors, thereby ensuring the authenticity and reliability of the test results.

[0030] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a schematic diagram of the cold start process of an embedded operating system;

[0032] Figure 2 A schematic diagram of the structure of an embedded operating system startup time test system provided in an embodiment of the present application;

[0033] Figure 3 A flowchart of an embedded operating system startup time testing method provided in an embodiment of the present application;

[0034] Figure 4 A flow chart of the cold start time test of an embedded operating system provided in an embodiment of the present application;

[0035] Figure 5 A flow chart of low power consumption wake-up time test for an embedded operating system provided in an embodiment of the present application;

[0036] Figure 6 A hot start time test flow chart for an embedded operating system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] Among the various time performance indicators of embedded operating systems, boot time is one of the important indicators for evaluating the performance of embedded operating systems. It includes three types of indicators: cold start time, hot start time, and low-power wake-up time. The test of boot time plays the following roles in the performance, reliability, and optimization of embedded operating systems: (1) Through the test of boot time, we can understand the time required for the system to start up, and evaluate whether the system performance meets the real-time requirements. During the system kernel optimization process, we can find the bottlenecks and time-consuming operations in the system startup process, so as to optimize and improve the system kernel in a targeted manner and improve the system response speed and efficiency. (2) Boot time testing can be used to verify the rationality and feasibility of the system design. Through the system boot time test, the most appropriate boot strategy can be selected and the hardware and software architecture of the system can be adjusted. (3) It can help quickly identify problems or faults that may exist during the system startup process, such as initialization failure, resource competition, etc., which is conducive to early detection and resolution of potential risks. It can be seen that the boot time test of embedded operating systems is a very important test and verification process that can help evaluate system performance, optimize system design, ensure the real-time performance of the system, and promptly detect and solve problems, thereby improving the real-time performance, reliability, and stability of the overall system.

[0038] Currently, common methods for testing the boot time of embedded operating systems include: manual timing, third-party performance testing tools, system internal software logs, and hardware timers.

[0039] Among them, manual timing is to use a stopwatch or timer to manually record the time from the start of the boot process to the time when the embedded operating system is fully started and ready to accept user input. It is a simple and intuitive method of measuring time. It does not require complex equipment and only relies on human observation and reaction to perform timing. However, this method is susceptible to human factors, such as the observer's reaction speed, concentration, and subjective judgment during timing. Therefore, the statistical accuracy of this method is relatively poor. Moreover, manual timing is not convenient for repeated measurements, because each measurement may have differences due to human factors, which makes it difficult to ensure the consistency and reliability of the results.

[0040] Third-party performance testing tools use specialized performance analysis tools to measure the boot time, such as Perf (capable of hotspot search at the function and instruction levels) or SystemTap (a dynamic method for monitoring and tracking the operation of the running LINUX kernel) in the LINUX (a free to use and freely disseminated UNIX-like operating system), DTrace (dynamic tracing) or other tools. These advanced tools can accurately record every critical moment in the system startup process, including the specific execution time of each task or module, by writing scripts, thereby providing users with a detailed timeline analysis. In this way, developers and system administrators can gain an in-depth understanding of the performance bottlenecks in the system startup process and then optimize it. However, these performance analysis tools have certain restrictions on embedded operating systems. They may not work properly on all embedded operating systems, especially those that are highly customized and tailored. These embedded operating systems may lack the necessary support libraries or kernel modules, resulting in these tools being unable to be installed or run correctly. In addition, when using the above method for measurement, it is difficult to accurately obtain the power-on and power-off time points for the system's cold start process. Cold start refers to the process from a completely shut down state to a fully started state. For details, please refer to Figure 1 , which shows a schematic diagram of the cold start process of an embedded operating system. This process involves hardware initialization and firmware execution, and these stages are usually not captured by software performance analysis tools.

[0041] System internal software log analysis and recording. Embedded operating systems usually record the timestamps of key events in logs, such as the start and end of startup. The startup time can be determined by analyzing these log files. For example, in LINUX systems, you can use the systemd (system and service manager dedicated to LINUX systems) log or dmesg (used to display boot information) command to view relevant timestamps. This method embeds special logging code in the software to capture key events in the startup process and add timestamps to each step, thereby recording the time consumed by each link in detail. However, this method requires the embedding of special logging code and is not suitable for all embedded operating systems. In addition, for the cold start process directly triggered by hardware, software logging cannot accurately capture the exact time points of power on and off. Cold start usually involves hardware initialization and firmware execution, which occur before the operating system starts, so the software log cannot cover these key time points. In addition, this method is highly dependent on the system's logging strategy. If the system's logging strategy does not cover the key nodes that need to be recorded, then the system startup time cannot be accurately calculated.

[0042] Use hardware timers to measure the boot time. For example, a hardware event can be triggered when the system power is turned on, and then another event can be triggered when the operating system is fully started. The time difference between the two events is measured by the hardware timer. The core of this method is to use the timing ability of the hardware itself to measure time. The specific operation is to start the hardware timer at the key node in the system startup process, and then stop the timer after the system is fully started. In this way, the system startup time is obtained. This method usually calls the system underlying driver for implementation. However, this method still cannot accurately obtain the start event of the cold start. The cold start involves the initialization of the hardware and the execution of the firmware. These processes occur before the operating system starts, and the hardware timer cannot record these key time points. Secondly, this method requires calling the underlying driver, which means that the preliminary preparation work is complicated. The developer needs to have an in-depth understanding of the operation of the hardware timer, and may need to write a special driver to control the start and stop of the timer. This not only increases the development workload, but also reduces the versatility of the system, because this method may not be applicable to all types of embedded operating systems. In addition, since the use of hardware timers involves access to the underlying system, this may introduce new security risks, especially in systems with high security requirements. Therefore, when using hardware timers for boot time measurement, you need to carefully consider these potential risks and take corresponding measures to ensure the security and stability of the system.

[0043] To this end, the present application provides an embedded operating system startup time testing method, system and host computer for achieving the universality of the test and supporting multiple repeated tests. The testing process is simple and clear, easy to operate, and non-invasive. No modifications to the hardware and driver layers are required to avoid introducing unstable factors, thereby ensuring the authenticity and reliability of the test results.

[0044] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0045] See also Figure 2 and Figure 3 ,in, Figure 2 A schematic diagram of the structure of an embedded operating system startup time test system provided by an embodiment of the present application is shown. Figure 3 A flowchart of an embedded operating system startup time test method provided by an embodiment of the present application is shown. An embedded operating system startup time test method provided by an embodiment of the present application is applied to a host computer, the host computer is in communication connection with a programmable power supply and a device under test, the device under test is installed with an embedded operating system under test, and the embedded operating system under test includes a pre-installed auxiliary timing application. The embedded operating system startup time test method may include:

[0046] S11: Control the programmable power supply to supply power to the device under test, receive a power-on event returned by the programmable power supply, and obtain the power-on time of the power supply according to the power-on event.

[0047] It should be noted that the embedded operating system startup time test method provided in the embodiment of the present application can be applied to a host computer, which is communicatively connected with a program-controlled power supply and a device under test, such as Figure 2 As shown, the program-controlled power supply is connected to the device under test, and the program-controlled power supply supplies power to or cuts off power to the device under test under the control of the host computer.

[0048] Among them, the startup time test software is installed inside the host computer, which mainly has the following functions: control and schedule other equipment and processes in the overall test process; monitor the startup and running status of the device under test; calculate the startup time and output the final test results, etc. In addition, the host computer can communicate with the programmable power supply and the device under test through serial port or network port communication. The startup time test software of the host computer controls the device under test and the programmable power supply through the serial port or Ethernet port, and records various key time points by recording identification events. The startup time test software supports batch testing to improve the accuracy of the test results.

[0049] The program-controlled power supply provides a serial port or network port communication method to receive the control instructions of the host computer, performs power supply or power-off control according to the control instructions of the host computer, and replies to the host computer with the event record identifier of the corresponding operation. That is, the program-controlled power supply supports program control, and can return power-on events, power-off events, etc. to the host computer through a communication connection. Among them, the program-controlled power supply can specifically include a program-controlled switch and a power supply (specifically, it can be a common power supply), the program-controlled switch is connected between the power supply and the device under test, and the program-controlled switch is connected to the host computer for communication, the program-controlled switch is closed or disconnected under the control of the host computer (specifically, it can be realized by the host computer sending instructions to the program-controlled switch), and the power supply is used to power the device under test when the program-controlled switch is closed, and disconnect the power supply to the device under test when the program-controlled switch is disconnected, so as to power off the device under test.

[0050] The device under test is installed with an embedded operating system under test. It should be noted that the embedded operating system under test mentioned in the embodiment of the present application may specifically be an embedded real-time operating system under test, but of course, it is not limited thereto.

[0051] Before the boot time test is performed, an auxiliary timing application can be pre-installed in the embedded operating system to be tested, wherein the auxiliary timing application is a general auxiliary timing application, which can be applied to various embedded operating systems. Specifically, the auxiliary timing application can be compiled using the standard C language to facilitate transplantation and application in various embedded operating systems. The auxiliary timing application is used to mark and record events related to the boot time test of the intrusive operating system, and the device to be tested sends the corresponding event identifier to the host computer so that the host computer can record the time. That is, the auxiliary timing application will mark the events that occur at key time points such as the start of the system user state process and the system sleep event, and then the device to be tested will feed back the corresponding event identifier to the host computer for time recording. That is, the embodiment of the present application designs an auxiliary timing application based on standard C that is general and applicable to various embedded operating systems. The auxiliary timing application will send event messages to the host computer at key time points of the system (such as entering the user state process, system sleep, etc.) to facilitate the host computer to record the time.

[0052] When performing a startup time test, the host computer can control the program-controlled power supply to supply power to the device under test, and receive the power-on event returned by the program-controlled power supply, and then obtain the power-on event according to the power-on event returned by the program-controlled power supply. Specifically, the host computer can send a power-on instruction to the program-controlled power supply, and the program-controlled power supply supplies power to the device under test according to the power-on instruction and returns the power-on event to the host computer at the same time. After receiving the power-on event, the host computer obtains the power-on time according to the power-on event, and the obtained power-on time can be accurate to the microsecond level (of course, it can also be accurate to the millisecond level). When the program-controlled power supply includes a program-controlled switch and a power supply, the aforementioned process is specifically: the host computer sends a power-on instruction to the program-controlled switch, the program-controlled switch is closed to turn on the power supply, so that the power supply supplies power to the device under test, the program-controlled switch returns the power-on event to the host computer while turning on the power supply, and the host computer obtains the power-on time according to the power-on event after receiving the power-on event.

[0053] Among them, for the host computer to obtain the power-on time according to the power-on event, the host computer can provide a unified time reference system. After receiving the power-on event, the host computer uses the time of receiving the power-on event as the power-on time based on the unified time reference system. Since this method uses the host computer as the only time reference system, there is no need to consider the clock synchronization problem of using multiple devices in the test. Of course, the program-controlled power supply can also include the power-on time in the returned power-on event while maintaining time synchronization between the host computer, the program-controlled power supply and the device to be tested, so that the host computer can obtain the power-on time from the power-on event. Among them, in order to reduce the complexity of the startup time test, etc., the host computer can provide a unified time reference system, and the host computer can obtain the power-on time based on the unified time reference system according to the power-on event.

[0054] Compared with the problem of being unable to obtain the power-on time of the external power supply in common solutions, the embodiment of the present application uses a programmable power supply to obtain the power-on time, that is, the power-on time can be obtained before the embedded operating system to be tested is started, thereby facilitating the accurate acquisition of the cold start time of the embedded operating system to be tested.

[0055] S12: receiving a user-mode process start event sent by the device under test and marked by the auxiliary timing application, and obtaining a startup completion time according to the user-mode process start event.

[0056] After the program-controlled power supply is controlled to supply power to the device under test, the embedded operating system under test in the device under test performs a startup process. When the corresponding user-mode process is started, the auxiliary timing application in the embedded operating system under test can mark and record the user-mode process start event, and the device under test can send the user-mode process start event to the host computer. Correspondingly, the host computer can receive the user-mode process start event sent by the device under test and marked by the auxiliary timing application. After the program-controlled power supply is controlled to supply power to the device under test, the host computer can monitor the communication with the device under test in real time, so as to receive the user-mode process start event sent by the device under test in a timely manner, thereby facilitating the accurate determination of the startup time of the embedded operating system under test.

[0057] After receiving the user state process start event sent by the device under test and marked by the auxiliary timing application, the host computer can obtain the startup completion time according to the user state process start event, and the accuracy level of the acquired startup completion time is consistent with the accuracy level of the acquired power-on time. Among them, the way in which the host computer obtains the startup completion time according to the user state process start event is consistent with the way in which the host computer obtains the power-on time according to the power-on event, so as to accurately obtain the startup time of the embedded operating system under test. Among them, if the power-on time and the startup completion time are obtained based on the unified time reference system provided by the host computer, the programmable power supply and the device under test can use the same transmission speed and the same number of bytes to send the power-on event and the user state process start event respectively, so that the transmission time used by the programmable power supply to send the power-on event to the host computer is the same as the transmission time used by the device under test to send the user state process start event to the host computer, so that the above two transmission times can offset each other when the startup time of the embedded operating system under test is determined according to the power-on time and the startup completion time, so as to accurately determine the startup time of the embedded operating system under test.

[0058] S13: Determine the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time.

[0059] After the host computer obtains the power-on time according to the power-on event and the startup completion time according to the user state process start event, the startup time of the embedded operating system to be tested can be calculated according to the power-on time and the startup completion time using the formula: startup time of the embedded operating system to be tested = startup completion time - power-on time.

[0060] Testing in the above manner can make the test have the following characteristics: (1) Intuitiveness. The test process is simple, clear, easy to understand and operate, so that even developers without professional testing background can easily get started. (2) High precision. The test results are highly accurate, with precision to milliseconds or even microseconds, to meet the strict standards of embedded operating systems with high real-time requirements. (3) Support for program control. The test system is controlled by program control to facilitate batch repetitive testing. Among them, batch repetitive testing is crucial to verify the stability and consistency of embedded operating systems under different conditions. (4) Universality. By using the host computer, programmable power supply and auxiliary timing application, the test method can be applied to various embedded operating systems without being restricted by specific hardware or software platforms, so that the test results have wide applicability and reference value. (5) Non-intrusiveness. The test process does not make any modifications to the hardware and driver layer, which can not only reduce the workload of the test, but also avoid introducing new unstable factors, ensuring the security, stability, authenticity and reliability of the test results. Moreover, relative to manual timing, the embodiment of the present application can realize automatic testing of the startup time through the host computer, program-controlled power supply and auxiliary timing application, without manual participation, therefore, it can be free from the influence of human factors, can improve the test accuracy, and can support multiple repeated measurements, and can ensure the consistency and reliability of the results. Relative to the use of third-party performance testing tools for startup time testing, the embodiment of the present application uses an auxiliary timing application written based on standard C, which is more adaptable to various embedded systems, is not affected by the system adaptability of third-party performance testing tools, and can obtain the time before the embedded operating system is started through the host computer and program-controlled power supply, so as to accurately obtain the cold start time. Relative to the use of system internal software logs for startup time testing, the embodiment of the present application does not need to embed a special log recording code, only a general auxiliary timing application needs to be pre-installed, and the embodiment of the present application does not rely on the timing time in the log and the log printing statistics method, nor does it rely on the clock of the embedded operating system, avoiding the test deviation caused by the clock problem of the embedded operating system. Compared with using a hardware timer to perform startup time testing, the embodiments of the present application do not require modification of the system boot program and driver, do not rely on the hardware level of the device under test to bring out specific IO (Input / Outout) ports for detection, do not require hardware modification, and do not require the use of underlying drivers and boot program source code for compilation, and are highly easy to use.

[0061] The above technical scheme disclosed in the embodiment of the present application, the host computer controls the program-controlled power supply to supply power to the device under test and receives the power-on event returned by the program-controlled power supply, and obtains the power-on time of the power supply according to the power-on event. After the program-controlled power supply supplies power to the device under test, the embedded operating system under test starts the startup process. When the user state process in the embedded operating system under test is started, the auxiliary timing application pre-installed in the embedded operating system under test can mark the user state process, and the device under test can send the marked user state start event to the host computer, so that the host computer obtains the startup completion time according to the user state process start event, and then the host computer determines the startup time of the embedded operating system under test according to the power-on time and the startup completion time. By using the auxiliary timing application installed in the host computer, the program-controlled power supply and the device under test, various embedded operating systems can be tested for startup time, the universality of the test method can be achieved, and multiple repeated tests of the startup time can be supported. Moreover, the test process is simple and clear, easy to operate, so that even developers without professional testing background can easily get started. In addition, the testing process is non-invasive and does not require any modifications to the system hardware and driver layer to avoid introducing unstable factors, thereby ensuring the authenticity and reliability of the test results.

[0062] An embedded operating system startup time test method provided by an embodiment of the present application, pre-installing an auxiliary timing application, may include:

[0063] Control the programmable power supply to supply power to the device under test and clear the user mode process in the embedded operation under test;

[0064] Install auxiliary timing application in the embedded operating system under test;

[0065] Control the programmable power supply to turn off to power off the device under test.

[0066] In the embodiment of the present application, the auxiliary timing application can be pre-installed in the embedded operating system to be tested by the host computer.

[0067] Specifically, after the relevant personnel connect the host computer, the device to be tested and the program-controlled power supply, the host computer can control the program-controlled power supply to supply power to the device to be tested, wherein the implementation method of controlling the program-controlled power supply to supply power to the device to be tested is the same as the implementation method of controlling the program-controlled power supply to supply power to the device to be tested in step S11, which will not be repeated here. After the device to be tested is started, the host computer can clear the user state process in the embedded operation to be tested to ensure that there are no other user state processes when the embedded operating system to be tested is started, so as to avoid these user state processes from affecting the startup time test of the embedded operating system and improve the accuracy of the startup time test of the embedded operating system.

[0068] After clearing the user-mode process in the embedded operating system to be tested, the host computer can install an auxiliary timing application in the embedded operating system to be tested, so as to use the auxiliary timing application to mark and record events related to the embedded operating system startup time test. Then, the host computer can control the program-controlled power supply to be turned off to power off the device to be tested. Specifically, the host computer can send a power-off instruction to the program-controlled power supply, and the program-controlled power supply turns off the power supply to the device to be tested after receiving the power-off instruction, so as to power off the device to be tested. Among them, when the program-controlled power supply includes a program-controlled switch and a power supply, the aforementioned process is that the host computer sends a power-off instruction to the program-controlled switch, and the program-controlled switch is turned off after receiving the power-off instruction, so as to power off the device to be tested.

[0069] That is, before the host computer starts the actual test process, the above preparations can be done. After the device under test is powered off, the host computer can enter the actual test process.

[0070] See also Figure 4 , which shows a flow chart of the cold start time test of an embedded operating system provided by an embodiment of the present application. An embedded operating system startup time test method provided by an embodiment of the present application controls a program-controlled power supply to supply power to a device under test, which may include:

[0071] After the embedded operating system to be tested is completely shut down or powered off, control the program-controlled power supply to supply power to the device to be tested;

[0072] Determine the startup time of the embedded operating system to be tested based on the power-on time and startup completion time, which may include:

[0073] According to the power-on time and the startup completion time, the single cold startup time of the embedded operating system to be tested is determined.

[0074] In the embodiment of the present application, the host computer and the programmable power supply can be used to test the cold start time of the embedded operating system to be tested. The cold start time test refers to the time from the first startup of the embedded operating system to the startup of the first user mode process after the embedded operating system to be tested is completely shut down or powered off.

[0075] When the host computer tests the cold start time of the embedded operating system to be tested, the host computer controls the program-controlled power supply to supply power to the device to be tested, which can be specifically after the embedded operating system to be tested is completely shut down or powered off, to control the program-controlled power supply to supply power to the device to be tested. Moreover, the user-mode process start event received by the host computer can be specifically the first user-mode process start event, that is, receiving the user-mode process start event sent by the device to be tested and marked by the auxiliary timing application, and obtaining the startup completion time according to the user-mode process start event. Specifically, it can be receiving the first user-mode process start event sent by the device to be tested and marked by the auxiliary timing application, and obtaining the startup completion time according to the first user-mode process start event. On the basis of the above, the host computer determines the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time, that is, determines the single cold start time of the embedded operating system to be tested according to the power-on time and the startup completion time. After determining the single cold start time of the embedded operating system to be tested, the host computer can save the single cold start time.

[0076] That is, the process of the host computer performing the cold start time can be as follows: after the embedded operating system to be tested is completely shut down or powered off, the programmable power supply is controlled to supply power to the device to be tested, a power-on event returned by the programmable power supply is received, and the power-on time Tcs1 (specifically, the host computer time can be taken, with an accuracy of μs) is obtained according to the power-on event. The host computer monitors the user process start event printed in the auxiliary timing application returned by the device to be tested, and the startup completion time Tcs2 (specifically, the host computer time can be taken, with an accuracy of μs) is recorded according to the user state process start event. The time is calculated and saved, and the single cold start time is Δtcs=Tcs2-Tcs1.

[0077] Through the above process, the single cold start time of the embedded operating system to be tested can be automatically and accurately obtained.

[0078] An embedded operating system startup time test method provided by an embodiment of the present application may further include: after determining a single cold startup time of the embedded operating system to be tested according to a power-on time and a startup completion time:

[0079] Control the program-controlled power supply to turn off, and after waiting for a first preset time, return to the step of controlling the program-controlled power supply to supply power to the device under test until the number of tests reaches the first preset number;

[0080] The cold start time of the embedded operating system to be tested is determined according to a first preset number of single cold start times.

[0081] In an embodiment of the present application, after determining the single cold start time of the embedded operating system to be tested according to the power-on time and the startup completion time, the program-controlled power supply can be controlled to be turned off, and the program-controlled power supply can be specifically controlled to be turned off by sending a power-off command to the program-controlled power supply. Then, the host computer can wait for the first preset duration to completely shut down or power off the embedded operating system to be tested, wherein the size of the first preset duration can be determined by relevant personnel based on experience or preliminary tests, for example, it can be 5 seconds. After the host computer waits for the first preset duration, it can return to the step of controlling the program-controlled power supply to supply power to the device to be tested, that is, a new round of cold start time test can be started until the number of tests reaches the first preset number (N1), wherein the first preset number is an integer greater than 1, and the specific size of the first preset number can be set by relevant personnel based on experience, etc.

[0082] After the number of tests reaches the first preset number of times, the host computer can determine the cold start time of the embedded operating system to be tested according to the first preset number of single cold start times of the embedded operating system to be tested, so as to obtain accurate cold start time test data. Specifically, the first preset number of single cold start times can be averaged to obtain the average value of the cold start time, and the average value of the cold start time can be determined as the cold start time of the embedded operating system to be tested. Alternatively, after eliminating abnormal single cold start times, the remaining single cold start times can be averaged to determine the cold start time of the embedded operating system to be tested, etc.

[0083] After determining the cold start time of the embedded operating system to be tested, the host computer can save the determined cold start time. In addition, the host computer can also output the single cold start time obtained in each cold start time test and the finally determined cold start time as needed.

[0084] The batch test of the cold start time is realized by the above method, and the cold start time of the embedded operating system to be tested is determined according to the batch test results, so as to improve the accuracy of obtaining the cold start time of the embedded operating system to be tested.

[0085] An embodiment of the present application provides a method for testing the startup time of an embedded operating system, wherein the device to be tested does not include a power storage device.

[0086] In the embodiment of the present application, when the cold start time test is performed, the device under test does not include a power storage device such as a super capacitor. Specifically, before the host computer starts the cold start test, relevant personnel can determine whether there is a power storage device in the device under test, and if so, remove the power storage device in the device under test. If not, the host computer can be turned on or notified (for example, voice input, keyboard input, or touch input, etc.) to notify the host computer, so that the host computer starts the cold start time test.

[0087] By making the device under test not include a power storage device, the device under test can be quickly discharged after each cold start time test, thereby shortening the time spent on multiple repeated cold start time tests and improving the efficiency of multiple repeated cold start time tests.

[0088] Combination Figure 4 The specific process of repeatedly testing the cold start time of the embedded operating system to be tested can be shown as follows, where: Figure 4 Take the programmable power supply including programmable switch and power supply as an example to explain:

[0089] (1) Relevant personnel confirm whether there are supercapacitors or other power storage devices in the device under test, and if so, remove them.

[0090] (2) The host computer sends a power-on command through the serial port to control the programmable switch. The programmable switch returns a power-on event when the power is turned on. The host computer records the power-on time Tcs1 (that is, the start time, which can be the host computer time with an accuracy of μs) according to the power-on event.

[0091] Among them, after the programmable switch turns on the power supply, the power supply supplies power to the device under test, and the embedded operating system under test in the device under test performs a cold start process. When the user state process is started, the auxiliary timing application in the embedded operating system under test will mark, record and print the user state process start event, and the device under test returns the user state process start event to the host computer.

[0092] (3) The host computer monitors the user process start event printed in the auxiliary timing application returned by the device under test (or the embedded operating system under test) through the serial port, and records the startup completion time Tcs2 (specifically, the host computer time can be taken, with an accuracy of μs) according to the user process start event.

[0093] (4) Calculate and save the single cold start time as Δtcs=Tcs2-Tcs1.

[0094] (5) The host computer sends a power-off command through the serial port to control the programmable switch to turn off the power supply. After a delay of 5 seconds, it is determined whether the number of tests reaches N1. If not, the process (2)-(4) is repeated again until the number of tests reaches N1, and N1 Δtcs results are saved. The cold start time of the embedded operating system to be tested is determined based on the N1 Δtcs results. For example, the arithmetic mean of the N1 Δtcs results can be calculated, and the arithmetic mean is determined as the cold start time of the embedded operating system to be tested.

[0095] Among them, the upper computer in step (4) and step (5) sends a power-off command through the serial port to control the program-controlled switch, turns off the power, waits for a delay of 5 seconds, and determines whether the number of tests reaches N1. The execution order can be changed. In addition, it should be noted that the above process is described by taking serial communication as an example, and other communication methods are the same as the above process.

[0096] See also Figure 5 , which shows a low-power wake-up time test flow chart of an embedded operating system provided by an embodiment of the present application. An embedded operating system startup time test method provided by an embodiment of the present application, wherein the device under test includes a power storage device, and before controlling the program-controlled power supply to supply power to the device under test, it may also include:

[0097] Control the embedded operating system to be tested to enter low power consumption mode;

[0098] Receiving a user state process start event sent by the device under test and marked by an auxiliary timing application, and obtaining a startup completion time according to the user state process start event, may include:

[0099] Receive a user-mode process recovery event sent by the device under test and marked by an auxiliary timing application, and obtain a process recovery time according to the user-mode process recovery event;

[0100] Determine the startup time of the embedded operating system to be tested based on the power-on time and startup completion time, which may include:

[0101] According to the power-on time and process recovery time, the single low-power wake-up time of the embedded operating system to be tested is determined.

[0102] In the embodiment of the present application, the host computer and the program-controlled power supply can be used to perform a low-power wake-up time test on the embedded operating system to be tested. The low-power wake-up time refers to the time it takes for the embedded operating system to be tested to enter a low-power mode (also called a sleep mode, a standby mode, or a hibernation mode) and then be reactivated by powering on to restore it to a normal working state.

[0103] In order to make the low-power wake-up time test of the embedded operating system to be tested proceed normally, the device to be tested needs to include a power storage device. Specifically, before performing a low-power wake-up time test on the embedded operating system to be tested, relevant personnel can confirm whether the device to be tested has been installed with a supercapacitor or other power storage device. If it is confirmed that the device to be tested has been installed with a power storage device, the host computer can be turned on or notified so that the host computer can start the low-power wake-up time test. If it is confirmed that the device to be tested has not been installed with a power storage device, the power storage device can be installed in the device to be tested, and then the host computer can be turned on or notified so that the host computer can start the low-power wake-up time test.

[0104] When the host computer starts the low-power wake-up time test, it can first control the embedded operating system to be tested to enter the low-power mode, that is, turn off the program-controlled power supply, use the power storage device to supply power, and put the user-mode process in the embedded operating system to be tested into sleep mode. After the host computer controls the embedded operating system to be tested to enter the low-power mode, it can delay waiting for a fourth preset time length, wherein the size of the fourth preset time length can be set by relevant personnel based on experience, etc. Then, the host computer can control the program-controlled power supply to supply power to the device under test, receive the power-on event returned by the program-controlled power supply, and obtain the power-on time Tlp2 (specifically, the host computer time can be taken, with an accuracy of μs) according to the power-on event; monitor the user state process recovery event marked by the auxiliary timing application returned by the device under test (the user state process recovery event is the event that the user state process recovers from hibernation, and the user state process recovery means that the embedded operating system under test recovers from hibernation to a normal working state), and obtain the process recovery event Tlp3 (specifically, the host computer time can be taken, with an accuracy of μs) according to the user state process recovery event; according to the power-on time Tlp2 and the process recovery event Tlp3, use Δtlp=Tlp3-Tlp2 to determine the single low-power wake-up time Δtlp of the embedded operating system under test. After determining the single low-power wake-up time of the embedded operating system under test, the host computer can save the single low-power wake-up time.

[0105] Through the above process, the single low-power wake-up time of the embedded operating system to be tested can be automatically and accurately obtained.

[0106] An embedded operating system startup time test method provided in an embodiment of the present application controls the embedded operating system to be tested to enter a low power consumption mode, which may include:

[0107] Control the programmable power supply to supply power to the device under test;

[0108] After the embedded operating system to be tested is started up, the program-controlled power supply is controlled to be turned off;

[0109] Receive a user-mode process sleep event sent by the device under test and marked by an auxiliary timing application.

[0110] In an embodiment of the present application, the process of the host computer controlling the embedded operating system to be tested to enter the low power consumption mode can be specifically as follows: first, the program-controlled power supply is controlled to supply power to the device to be tested so that the embedded operating system to be tested can be started normally. Specifically, the host computer controls the program-controlled power supply to supply power to the device to be tested, and the user state process in the embedded operating system to be tested is started. The host computer receives the user state process start event sent by the device to be tested and marked by the auxiliary timing application, and delays and waits for the embedded operating system to be tested to complete the startup. After the embedded operating system to be tested is started, the program-controlled power supply is controlled to be turned off. Specifically, the host computer can send a power-off instruction to the program-controlled power supply to turn off the program-controlled power supply. After the program-controlled power supply is turned off, the system is triggered to sleep (not powered by power supply), the auxiliary timing application can mark, record and print the user state process sleep event, and the host computer can monitor the user state process sleep event printed by the auxiliary timing application returned by the device to be tested. At this time, it is determined that the embedded operating system to be tested enters the low power consumption mode.

[0111] The above method can be used to automatically control the embedded operating system to enter a low power consumption mode.

[0112] An embedded operating system startup time test method provided by an embodiment of the present application may further include, after controlling the program-controlled power supply to be turned off:

[0113] Receive the power-off event returned by the programmable power supply, and obtain the power-off time according to the power-off event;

[0114] After receiving the user-mode process sleep event sent by the device under test and marked by the auxiliary timing application, the method may further include:

[0115] Get the system sleep time based on the user-mode process sleep event;

[0116] According to the power off time and the system sleep time, the single entry low power consumption time of the embedded operating system to be tested is determined.

[0117] In the embodiment of the present application, after the host computer controls the program-controlled power supply to be turned off, the program-controlled power supply can return a power-off event to the host computer. Specifically, after the host computer sends a power-off instruction to the program-controlled power supply, the program-controlled power supply is turned off on the one hand, and the power-off event is returned to the host computer on the other hand. When the program-controlled power supply includes a program-controlled switch and a power supply, the host computer sends a power-off instruction to the program-controlled switch. At this time, the program-controlled switch controls the power supply to be turned off on the one hand, and returns a power-off event to the host computer on the other hand. After receiving the power-off event, the host computer can obtain the power-off time Tlp1 according to the power-off event, wherein the implementation method of the host computer obtaining the power-off time according to the power-off event is consistent with the method of the host computer obtaining the power-on time according to the power-on event. In addition, after receiving the user-mode process sleep event sent by the device under test and marked by the auxiliary timing application, the host computer can also obtain the system sleep time Teh according to the user-mode process sleep event, wherein the method of obtaining the system sleep time Teh here is consistent with the above-mentioned method of obtaining the corresponding time according to other events. Then, the host computer can determine the single low power consumption time Δteh of the embedded operating system to be tested according to the power off time Tlp1 and the system sleep time Teh by using Δteh=Teh-Tlp1.

[0118] By means of the above, it is possible to determine the single low power consumption wake-up time of the embedded operating system to be tested and the single low power consumption entry time of the embedded operating system to be tested at the same time.

[0119] An embedded operating system startup time test method provided by an embodiment of the present application may further include: after determining a single low-power wake-up time of the embedded operating system to be tested according to the power-on time and the process recovery time:

[0120] After waiting for a second preset time, the step of returning to the step of controlling the program-controlled power supply to be turned off is performed until the number of tests reaches a second preset number of times;

[0121] The low power consumption wake-up time of the embedded operating system to be tested is determined according to a second preset number of single low power consumption wake-up times.

[0122] In the embodiment of the present application, after determining the single low-power wake-up time of the embedded operating system to be tested according to the power-on time and the process recovery time, it can be determined whether the number of tests of the low-power wake-up time test reaches the second preset number (N2, N2 is an integer greater than 1, and the size of the second preset number can be the same as the size of the first preset number). If the number of tests does not reach the second preset number, it can wait for the second preset time (the specific size can be set by relevant personnel based on experience) and then return to the step of controlling the program-controlled power supply, that is, it can return to the steps of notifying the program-controlled power supply to turn off, receiving the user-mode process sleep event marked by the auxiliary timing application sent by the device to be tested, and so on, that is, the next round of low-power wake-up time test can be performed until the number of tests reaches the second preset number. If the number of tests reaches the second preset number, the program-controlled power supply can be controlled to turn off. In the aforementioned process, it is also possible to wait for the second preset time after determining the single low-power wake-up time of the embedded operating system to be tested according to the power-on time and the process recovery time, and determine whether the number of tests of the low-power wake-up time test reaches the second preset number. If the number of tests does not reach the second preset number, it is possible to return to the step of controlling the program-controlled power supply.

[0123] After the number of tests reaches the second preset number of times, the host computer can determine the low-power wake-up time of the embedded operating system to be tested based on the second predicted number of single low-power wake-up times of the embedded operating system to be tested, so as to obtain accurate low-power wake-up time test data. Specifically, the second preset number of single low-power wake-up times can be averaged to obtain the low-power wake-up time average value, and the low-power wake-up time average value can be determined as the low-power wake-up time of the embedded operating system to be tested. Or after eliminating abnormal single low-power wake-up times, the remaining single low-power wake-up times can be averaged to determine the low-power wake-up time of the embedded operating system to be tested.

[0124] After determining the low power wake-up time of the embedded operating system to be tested, the host computer can save the determined low power wake-up time. In addition, the host computer can also output the single low power wake-up time obtained in each low power wake-up time test and the finally determined low power wake-up time as needed.

[0125] The method described above realizes batch testing of low-power wake-up time, and determines the low-power wake-up time of the embedded operating system to be tested according to the batch test results, so as to improve the accuracy of determining the low-power wake-up time of the embedded operating system to be tested.

[0126] An embedded operating system startup time testing method provided in an embodiment of the present application may also include:

[0127] The low power consumption entry time of the embedded operating system to be tested is determined according to the second preset number of single low power consumption entry times.

[0128] In an embodiment of the present application, after performing a second preset number of low-power wake-up time tests and determining a single low-power entry time of the embedded operating system to be tested each time, the low-power entry time of the embedded operating system to be tested can also be determined based on the second preset number of single low-power entry times. Wherein, determining the low-power entry time of the embedded operating system to be tested is consistent with the method of determining the cold start time of the embedded operating system to be tested. In addition, after determining the low-power entry time of the embedded operating system to be tested, the host computer can also save the time, and can also output the single low-power entry time obtained in each test and the finally determined low-power entry time as needed.

[0129] The above method can improve the accuracy of determining the time when the embedded operating system to be tested enters low power consumption.

[0130] Combination Figure 5 The specific process of repeatedly testing the low power consumption wake-up time of the embedded operating system to be tested can be shown as follows, where: Figure 5 Take the programmable power supply including the programmable switch and the power supply as an example, and relevant personnel have confirmed that the device under test is equipped with a storage device:

[0131] (1) The host computer sets the program-controlled power supply to on to control the normal startup of the device under test. Specifically, the host computer sends a power-on command to the program-controlled switch, and the program-controlled switch turns on the power supply to supply power to the device under test. Then the user state process in the embedded operating system under test is started, the auxiliary timing application marks the user state process start event, and the device under test returns the user state process start event to the host computer, and the host computer delays and waits for the startup to complete.

[0132] (2) The host computer sends a power-off command to the program-controlled switch through the serial port. After receiving the power-off command, the program-controlled switch returns a power-off event while turning off the power. The host computer records the power-off time Tlp1 (specifically, the host computer time can be taken, with an accuracy of μs) according to the power-off event.

[0133] (3) After the power is turned off, the system is triggered to sleep (not powered by the power supply, that is, powered by the power storage device). The auxiliary timing application can mark and print the user state process sleep event (or system sleep event), and the device under test sends the user state process sleep event to the host computer. The host computer monitors the user process sleep event printed in the auxiliary timing application returned by the device under test through the serial port, and records the system sleep time Teh according to the user process sleep event (specifically, the host computer time can be taken, with an accuracy of μs).

[0134] (4) After a delay, the host computer sends a power-on command to control the program-controlled switch (specifically, a serial port command can be sent to control the program-controlled switch). The program-controlled switch returns the power-on event while turning on the power. The host computer records the power-on time Tlp2 according to the power-on event (specifically, the host computer time can be taken, with an accuracy of μs).

[0135] (5) After the device under test is powered by the power supply, the embedded operating system under test is restored, the dormant user-mode process is restored, and the auxiliary timing application marks and prints the user-mode process restoration event. The host computer monitors the user-mode process restoration event printed in the auxiliary timing application returned by the device under test through the serial port, and records the process restoration time Tlp3 (specifically, the host computer time can be taken, with an accuracy of μs) according to the user-mode process restoration event.

[0136] (6) Calculate and save the single low power consumption time as Δteh=Teh-Tlp1.

[0137] (7) Calculate and save the single low-power wake-up time as Δtlp=Tlp3-Tlp2.

[0138] (8) The host computer waits for 5 seconds and determines whether the number of tests reaches N2. If not, steps (2) to (7) are repeated until the number of tests reaches N2. The N2 times Δteh and Δtlp results are saved, and a power-off command can be sent to the program-controlled switch to control the power supply to be turned off.

[0139] (9) Calculate the arithmetic mean of N2 times Δteh and Δtlp respectively to obtain the low power consumption time and low power consumption wake-up time of the embedded operating system to be tested.

[0140] It should be noted that the above process is described using serial communication as an example, and other communication methods are the same as the above process.

[0141] See also Figure 6 , which shows a hot start time test flow chart of an embedded operating system provided in an embodiment of the present application. An embedded operating system startup time test method provided in an embodiment of the present application may also include:

[0142] Control the programmable power supply to maintain the power supply status;

[0143] Send a restart command to the device under test and obtain the restart time;

[0144] Receive a user state process start event sent by the device under test and marked by the auxiliary timing application, and obtain the restart completion time according to the user state process start event;

[0145] According to the restart time and the restart completion time, the single hot start time of the embedded operating system to be tested is determined.

[0146] In the embodiment of the present application, the host computer and the program-controlled power supply can also be used to test the hot start time of the embedded operating system to be tested. The hot start time refers to the time from issuing a restart command to starting the first user mode process.

[0147] When performing a hot start time test, the host computer can control the program-controlled power supply to maintain a power supply state, that is, keep the program-controlled power supply connected. When the program-controlled power supply includes a program-controlled switch and a power supply, the program-controlled switch is controlled to be in a normally closed state to keep the power supply connected. Specifically, the host computer can send a power-on instruction to the program-controlled switch, and the program-controlled switch is closed to turn on the power supply, so that the power supply supplies power to the device under test. At this time, the user state process in the embedded operating system under test is started, and the user state process start event sent by the device under test and marked and printed by the auxiliary timing application can be received. Then, the host computer can delay and wait for the startup to be completed, and keep the program-controlled switch closed to keep the power supply connected.

[0148] Afterwards, the host computer sends a restart command to the device under test, and at the same time, the host computer can obtain the restart time Ths1. After receiving the restart command, the embedded operating system under test starts the hot start process, and the user state process starts. At this time, the auxiliary timing application can mark and print the user state process start event, and the device under test sends the user state process start event to the host computer. Correspondingly, the host computer receives the user state process start event sent by the device under test and marked by the auxiliary timing application, and can obtain the restart completion time Ths2 according to the user state process start event. Among them, the method of obtaining the restart time Ths1 and the restart completion time Ths2 is similar to the method of obtaining other times mentioned above.

[0149] After obtaining the restart time Ths1 and the restart completion time Ths2, the host computer calculates the single hot start time of the embedded operating system to be tested by using Δths=Ths2-Ths1 according to the restart time Ths1 and the restart completion time Ths2. In addition, the host computer can also save the calculated Δths.

[0150] The above method can be used to test the hot start time of the embedded operating system to be tested by using the host computer and the program-controlled power supply to obtain the hot start time of the embedded operating system to be tested.

[0151] An embedded operating system startup time test method provided by an embodiment of the present application may further include: after determining a single hot start time of the embedded operating system to be tested according to the restart time and the restart completion time:

[0152] After waiting for a third preset time, return to the step of sending a restart command to the device under test until the number of tests reaches a third preset number;

[0153] The hot start time of the embedded operating system to be tested is determined according to a third preset number of single hot start times.

[0154] In the embodiment of the present application, the host computer and the program-controlled power supply can be used to perform repeated hot start time tests on the embedded operating system to be tested. Specifically, after the host computer determines the single hot start time of the embedded operating system to be tested according to the restart time and the restart completion time, it can delay waiting for the third preset duration (the specific size can be set by relevant personnel according to experience, etc., for example, it can be 5 seconds), and judge whether the number of tests of the hot start time test reaches the third preset number (N3, N3 is an integer greater than 1, and the size of the third preset number can be the same as the size of the first preset number), if the number of tests does not reach the third preset number, it can return to execute the step of sending a restart command to the device to be tested, until the number of tests reaches the third preset number. After the number of tests reaches the third preset number, the host computer can control the program-controlled power supply to be turned off to power off the device to be tested.

[0155] Among them, a single hot start time can be obtained for each test. After the number of tests reaches N3, the host computer can determine the hot start time of the embedded operating system to be tested based on the N3 single hot start times. Specifically, the N3 single hot start times can be averaged to obtain the hot start time average value, and the hot start time average value is determined as the hot start time of the embedded operating system to be tested. Alternatively, after eliminating the abnormal single hot start time, the remaining single hot start times can be averaged to determine the hot start time of the embedded operating system to be tested.

[0156] After determining the hot start time of the embedded operating system to be tested, the host computer can save the determined hot start time. In addition, the host computer can also output the single hot start time obtained during each hot start time test and the finally determined hot start time as needed.

[0157] The batch test of the hot start time is realized by the above method, and the hot start time of the embedded operating system to be tested is determined according to the batch test results, so as to improve the accuracy of determining the hot start time of the embedded operating system to be tested.

[0158] Combination Figure 6 The specific process of repeatedly testing the hot start time of the embedded operating system to be tested can be shown as follows, where: Figure 6 Take the programmable power supply including programmable switch and power supply as an example to explain:

[0159] (1) The program-controlled switch is set to the normally closed state to keep the power on. Specifically, the host computer sends a power-on command to the program-controlled switch, and the program-controlled switch turns on the power to supply power to the device under test. Then the user state process in the embedded operating system under test is started, the auxiliary timing application marks the user state process start event, and the device under test returns the user state process start event to the host computer, and the host computer delays and waits for the startup to complete.

[0160] (2) The host computer sends a restart command to the device under test through the serial port and records the restart time Ths1 (specifically, the host computer time can be taken, with an accuracy of μs).

[0161] After receiving the restart command, the embedded operating system under test starts the hot start process and the user state process starts. At this time, the auxiliary timing application can mark and print the user state process start event, and the device under test sends the user state process start event to the host computer.

[0162] (3) The host computer monitors the user state process start event printed in the auxiliary timing application returned by the device under test through the serial port, and records the restart completion time Ths2 (specifically, the host computer time can be taken, with an accuracy of μs) according to the user state process start event.

[0163] (4) Calculate and save the single hot start time as Δths=Ths2-Ths1.

[0164] (5) Wait for a delay of 5 seconds and determine whether the number of tests has reached N3. If not, repeat steps (2) to (4) until the number of tests reaches N3. Send a power-off command to the program-controlled switch, and the program-controlled switch is disconnected to power off the device under test. Save the N3 times Δths results.

[0165] (6) Calculate the arithmetic mean of the N3 times Δths results to obtain the hot start time of the embedded operating system to be tested.

[0166] It should be noted that the above process is described using serial communication as an example, and other communication methods are the same as the above process.

[0167] An embedded operating system startup time testing method provided by an embodiment of the present application, wherein a host computer provides a unified time reference system to obtain corresponding time based on the unified time reference system.

[0168] In an embodiment of the present application, the upper computer can provide a unified time reference system so that when the upper computer obtains the corresponding time according to the corresponding event, it can obtain the corresponding time based on the unified time reference system according to the corresponding event, that is, the events returned by the device under test and the programmable switch in the test system are used to calculate the corresponding time node based on the unified time reference system, so that each part in the test system does not need to consider the problem of clock synchronization, reduces the complexity of the startup time test, and improves the accuracy of the startup time determination.

[0169] The present application also provides an embedded operating system startup time test system. Figure 2 , may include a host computer and a program-controlled power supply, the host computer is connected to the program-controlled power supply for communication, the host computer is also used to communicate with the device under test, the program-controlled power supply is also used to connect to the device under test, the device under test is installed with an embedded operating system to be tested, and the embedded operating system to be tested includes a pre-installed auxiliary timing application, wherein:

[0170] The host computer is used to implement the steps of any of the above-mentioned embedded operating system startup time testing methods.

[0171] An embedded operating system startup time test system provided by an embodiment of the present application, wherein the programmable power supply may include a programmable switch and a power supply, wherein:

[0172] The program-controlled switch is connected between the power supply and the device under test, and the program-controlled switch is connected to the host computer for communication;

[0173] Power supply, used to power the device under test when the program-controlled switch is closed.

[0174] The embodiment of the present application further provides a host computer, which is used to communicate with the programmable power supply and the device under test, the device under test is installed with an embedded operating system under test, and the embedded operating system under test includes a pre-installed auxiliary timing application;

[0175] The host computer is used to implement the steps of any of the above-mentioned embedded operating system startup time testing methods.

[0176] The description of an embedded operating system startup time test system and related parts in the host computer provided in the embodiment of the present application can refer to the detailed description of the corresponding parts in an embedded operating system startup time test method provided in the embodiment of the present application, which will not be repeated here.

[0177] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection portion with one or more wirings (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0178] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0179] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0180] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0181] In this application, unless otherwise clearly specified and limited, the terms "installed", "connected", "connected", "fixed" and the like should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, it can be the internal connection of two elements or the interaction relationship between two elements, unless otherwise clearly defined. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0182] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for testing the startup time of an embedded operating system, characterized in that: The method is applied to a host computer, the host computer is in communication connection with a program-controlled power supply and a device under test, the device under test is installed with an embedded operating system under test, the embedded operating system under test includes a pre-installed auxiliary timing application, and the embedded operating system startup time test method includes: Controlling the programmable power supply to supply power to the device under test, receiving a power-on event returned by the programmable power supply, and obtaining a power-on time of the power supply according to the power-on event; Receiving a user state process start event sent by the device under test and marked by the auxiliary timing application, and acquiring a startup completion time according to the user state process start event; The startup time of the embedded operating system to be tested is determined according to the power-on time and the startup completion time.

2. The embedded operating system startup time testing method according to claim 1, characterized in that: Pre-installed timing assistance apps, including: Controlling the program-controlled power supply to supply power to the device under test, and clearing the user-mode process in the embedded operation under test; Installing the auxiliary timing application in the embedded operating system to be tested; The program-controlled power supply is controlled to be turned off so as to cut off the power supply of the device under test.

3. The embedded operating system startup time testing method according to claim 1, characterized in that: Controlling the programmable power supply to supply power to the device under test includes: After the embedded operating system to be tested is completely shut down or powered off, controlling the programmable power supply to supply power to the device to be tested; Determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time includes: A single cold start time of the embedded operating system to be tested is determined according to the power-on time and the startup completion time.

4. The embedded operating system startup time testing method according to claim 3, characterized in that: After determining a single cold start time of the embedded operating system to be tested according to the power-on time and the startup completion time, the method further includes: Controlling the program-controlled power supply to be turned off, and returning to the step of controlling the program-controlled power supply to supply power to the device under test after waiting for a first preset time, until the number of tests reaches a first preset number; The cold start time of the embedded operating system to be tested is determined according to the first preset number of single cold start times.

5. The embedded operating system startup time testing method according to claim 4, characterized in that: The device under test does not include a power storage device.

6. The embedded operating system startup time testing method according to claim 1, characterized in that: The device under test includes a power storage device, and before controlling the programmable power supply to supply power to the device under test, further includes: Controlling the embedded operating system to be tested to enter a low power consumption mode; Receiving a user state process start event sent by the device under test and marked by the auxiliary timing application, and acquiring a startup completion time according to the user state process start event, including: receiving a user state process recovery event sent by the device under test and marked by the auxiliary timing application, and acquiring a process recovery time according to the user state process recovery event; Determining the startup time of the embedded operating system to be tested according to the power-on time and the startup completion time includes: A single low-power wake-up time of the embedded operating system to be tested is determined according to the power-on time and the process recovery time.

7. The embedded operating system startup time testing method according to claim 6, characterized in that: Controlling the embedded operating system to be tested to enter a low power consumption mode, comprising: Controlling the programmable power supply to supply power to the device under test; After the embedded operating system to be tested is started up, controlling the program-controlled power supply to be turned off; Receive a user-mode process sleep event sent by the device under test and marked by the auxiliary timing application.

8. The embedded operating system startup time testing method according to claim 7, characterized in that: After controlling the program-controlled power supply to be turned off, the method further comprises: Receiving a power-off event returned by the programmable power supply, and obtaining a power-off time according to the power-off event; After receiving the user state process sleep event sent by the device under test and marked by the auxiliary timing application, the method further includes: Acquire the system sleep time according to the user state process sleep event; A single low power consumption entry time of the embedded operating system to be tested is determined according to the power off time and the system sleep time.

9. The embedded operating system startup time testing method according to claim 8, characterized in that: After determining a single low-power wake-up time of the embedded operating system to be tested according to the power-on time and the process recovery time, the method further includes: After waiting for a second preset time, returning to the step of controlling the program-controlled power supply to be turned off until the number of tests reaches a second preset number; The low power consumption wake-up time of the embedded operating system to be tested is determined according to the second preset number of single low power consumption wake-up times.

10. The embedded operating system startup time testing method according to claim 9, characterized in that: Also includes: The low power consumption entry time of the embedded operating system to be tested is determined according to the second preset number of single low power consumption entry times.

11. The embedded operating system startup time testing method according to claim 1, characterized in that: Also includes: Controlling the programmable power supply to maintain a power supply state; Sending a restart command to the device under test and obtaining a restart time; receiving a user state process start event sent by the device under test and marked by the auxiliary timing application, and acquiring a restart completion time according to the user state process start event; A single hot start time of the embedded operating system to be tested is determined according to the restart time and the restart completion time.

12. The embedded operating system startup time testing method according to claim 11, characterized in that: After determining the single hot start time of the embedded operating system to be tested according to the restart time and the restart completion time, the method further includes: After waiting for a third preset time, return to the step of sending a restart command to the device under test until the number of tests reaches a third preset number; The hot start time of the embedded operating system to be tested is determined according to the third preset number of single hot start times.

13. The embedded operating system startup time testing method according to any one of claims 1 to 12, characterized in that: The host computer provides a unified time reference system to obtain corresponding time based on the unified time reference system.

14. An embedded operating system startup time test system, characterized in that: It includes a host computer and a program-controlled power supply, the host computer is connected to the program-controlled power supply in communication, the host computer is also used to communicate with the device under test, the program-controlled power supply is also used to connect to the device under test, the device under test is installed with an embedded operating system to be tested, and the embedded operating system to be tested includes a pre-installed auxiliary timing application, wherein: The host computer is used to implement the steps of the embedded operating system startup time testing method as described in any one of claims 1 to 13.

15. The embedded operating system startup time test system according to claim 14, characterized in that: The program-controlled power supply comprises a program-controlled switch and a power supply, wherein: The program-controlled switch is connected between the power supply and the device under test, and the program-controlled switch is in communication connection with the host computer; The power supply is used to supply power to the device under test when the program-controlled switch is turned off.

16. A host computer, characterized in that: The host computer is used to communicate with the program-controlled power supply and the device under test, the device under test is installed with an embedded operating system under test, and the embedded operating system under test includes a pre-installed auxiliary timing application; The host computer is used to implement the steps of the embedded operating system startup time testing method as described in any one of claims 1 to 13.

Images