Method, device and equipment for determining system restart and vehicle

Abstract

The embodiment of the invention discloses a system restart determination method and device, equipment and a vehicle, and belongs to the technical field of vehicles. According to the embodiment of the invention, under the condition that the first running duration is monitored to be 0 at the first time point within the preset time period after the operating system is powered on, the second running duration of the operating system at the second time point can be obtained again, and whether the operating system is restarted or not is judged based on the second running duration; therefore, the situation that operation system restart misjudgment is caused by operation complexity in the preset time period after the operation system is powered on can be effectively avoided, that is, the restart situation of the time points outside the preset time period after the operation system is powered on can be judged, and the accuracy of the operation system restart judgment result is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method, device, equipment and vehicle for determining a system restart. Background Art

[0002] With the development of vehicle technology, users have higher and higher requirements for vehicle performance. In order to meet user needs, it is necessary to effectively monitor and analyze vehicle performance during the vehicle testing phase. Among them, the stability monitoring of the operating system is of great significance in vehicle performance monitoring.

[0003] The stability of the operating system can be judged based on the number of times the operating system restarts within a preset time. Currently, the restart of the operating system is judged based on the operating time of the operating system. For example, when the operating time is 0, it is judged that the operating system has restarted. However, due to the complexity of the internal operation of the operating system, there are usually some other situations that cause the operating time of the operating system to become 0 during operation, which does not mean that the operating system has restarted. Therefore, the existing restart judgment method will lead to misjudgment in the judgment of the restart of the operating system. Summary of the invention

[0004] The embodiments of the present application provide a method, device, equipment and vehicle for determining a system restart, which can solve the problem of misjudgment in related technologies when determining an operating system restart.

[0005] In a first aspect, an embodiment of the present application provides a method for determining a system restart, including:

[0006] Acquire first monitoring information of the operating system, the first monitoring information including a first running time at a first time point after the operating system is powered on, the first time point being a time point within a preset time period after the operating system is powered on;

[0007] When the first running time is 0, obtaining a second running time of the operating system at a second time point, where the second time point is a time point outside a preset time period after the operating system is powered on;

[0008] A restart determination result of the operating system is generated based on the second running time, wherein when the second running time is 0, the restart determination result indicates that a system restart occurs at the second time point of the operating system.

[0009] In a second aspect, an embodiment of the present application provides a system restart determination device, including: an acquisition module and a generation module;

[0010] An acquisition module, configured to acquire first monitoring information of the operating system, the first monitoring information including a first running time at a first time point after the operating system is powered on, the first time point being a time point within a preset time period after the operating system is powered on;

[0011] The acquisition module is further used to acquire, when the first operation time is 0, a second operation time of the operating system at a second time point, where the second time point is a time point outside a preset time period after the operating system is powered on;

[0012] A generation module is used to generate a restart judgment result of the operating system based on the second running time, wherein when the second running time is 0, the restart judgment result indicates that the operating system restarts at a second time point.

[0013] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the method described in the first aspect is implemented.

[0014] In a fourth aspect, an embodiment of the present application provides a storage medium having a program or instruction stored thereon, and when the program or instruction is executed by a processor, the method described in the first aspect is implemented.

[0015] In a fifth aspect, an embodiment of the present application provides a vehicle, the vehicle comprising a system restart determination device as described in the second aspect; or, an electronic device as described in the third aspect; or, a storage medium as described in the fourth aspect.

[0016] The embodiment of the present application obtains first monitoring information of the operating system, where the first monitoring information includes a first running time at a first time point after the operating system is powered on. When the first running time is 0, the second running time of the operating system at a second time point is obtained, wherein the first time point is a time point within a preset time period after the operating system is powered on, and the second time point is a time point outside the preset time period after the operating system is powered on. When the second running time is 0, it is determined that a system restart occurs at the second time point in the operating system. That is, when the embodiment of the present application monitors that the first running time is 0 at a first time point within the preset time period after the operating system is powered on, the second running time of the operating system at the second time point is obtained again, and whether the operating system is restarted is determined based on the second running time, thereby effectively avoiding the situation where the operating system restart is misjudged due to the complexity of the operation within the preset time period after the operating system is powered on. That is, the embodiment of the present application can judge the restart situation at a time point outside the preset time period after the operating system is powered on, thereby improving the accuracy of the operating system restart judgment result. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A flowchart of a method for determining a system restart provided in an embodiment of the present application;

[0018] Figure 2 A flowchart of another method for determining system restart provided in an embodiment of the present application;

[0019] Figure 3 A schematic diagram of the interaction process between a vehicle system and a back-end server provided in an embodiment of the present application;

[0020] Figure 4 A structural diagram of a system restart determination device provided in an embodiment of the present application;

[0021] Figure 5 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to more clearly understand the above-mentioned purposes, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0023] In the following description, many specific details are set forth to facilitate a full understanding of the present application, but the present application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only part of the embodiments of the present application, rather than all of the embodiments.

[0024] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0025] The related technology determines whether the operating system has been restarted based on the running time uptime. For example, if the uptime is 0, it is considered that the operating system has been restarted. However, under normal circumstances, the operation of the operating system within 1 minute after power-on is relatively complicated. There are usually some other situations that cause the running time of the operating system to become 0 during operation. This does not mean that the operating system has been restarted. Therefore, judging whether the operating system has been restarted based on the uptime value is prone to misjudgment. Moreover, if multiple judgments are made within 1 minute, continuous misjudgment is more likely to occur.

[0026] To this end, the embodiments of the present application provide a method, device, equipment and vehicle for determining a system restart, which can solve the problem of misjudgment in related technologies when determining an operating system restart.

[0027] The following is a description of the system restart determination method, device, equipment and vehicle provided in the embodiments of the present application through specific embodiments. The system restart determination method can be applied to the vehicle's operating system, which can be, for example, a Linux system.

[0028] Figure 1 A flowchart of a method for determining a system restart provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the method for determining whether the system is restarted may include the following steps:

[0029] S110: Acquire first monitoring information of an operating system.

[0030] The first monitoring information includes a first operating time at a first time point after the operating system is powered on, and the first time point is a time point within a preset time period after the operating system is powered on.

[0031] S120: When the first running time is 0, obtain a second running time of the operating system at a second time point.

[0032] The second time point is a time point outside the preset time period after the operating system is powered on.

[0033] S130: Generate a restart determination result of the operating system based on the second running time.

[0034] When the second running time is 0, the restart determination result indicates that a system restart occurs at the second time point in the operating system.

[0035] The embodiment of the present application obtains first monitoring information of the operating system, where the first monitoring information includes a first running time at a first time point after the operating system is powered on. When the first running time is 0, the second running time of the operating system at a second time point is obtained, wherein the first time point is a time point within a preset time period after the operating system is powered on, and the second time point is a time point outside the preset time period after the operating system is powered on. When the second running time is 0, it is determined that a system restart occurs at the second time point in the operating system. That is, when the embodiment of the present application monitors that the first running time is 0 at a first time point within the preset time period after the operating system is powered on, the second running time of the operating system at the second time point is obtained again, and whether the operating system is restarted is determined based on the second running time, thereby effectively avoiding the situation where the operating system restart is misjudged due to the complexity of the operation within the preset time period after the operating system is powered on. That is, the embodiment of the present application can judge the restart situation at a time point outside the preset time period after the operating system is powered on, thereby improving the accuracy of the operating system restart judgment result.

[0036] The above steps are described in detail below:

[0037] In S110, for example, the first monitoring information of the operating system can be obtained through a monitoring program. The monitoring program is used to monitor the performance of the vehicle. The monitoring program can automatically monitor the operating system to obtain the first monitoring information without the need for manual monitoring combined with external equipment, thereby simplifying the monitoring steps and improving the monitoring efficiency.

[0038] The first monitoring information may include the first running time at the first time point after the operating system is powered on, and may also include the CPU usage rate of the operating system's central processing unit (CPU), the memory usage rate, the restart status of the first process corresponding to the operating system, etc. The above information can be automatically obtained through the monitoring program, thereby improving the monitoring efficiency. The first time point is the time point when the first running time is obtained.

[0039] The operating time of the operating system can be used to accurately determine whether the operating system has been restarted, providing a basis for subsequent determination of the stability of the operating system. The process of determining whether the operating system has been restarted by the operating time can be seen in the following embodiments.

[0040] The first process may be a process that runs after the operating system is started, or some processes may be selected as the first process according to actual needs. The restart status of the first process may include, for example, the number of restarts of the first process and the restart time point corresponding to each restart. The monitoring program in the embodiment of the present application may automatically monitor the restart status of the first process.

[0041] For example, the monitoring program can be executed according to the monitoring cycle to obtain the first monitoring information of the operating system, that is, the first monitoring information can be obtained once each time the monitoring program is executed, and the stability of the vehicle system can be evaluated by analyzing the first monitoring information within a certain period of time. The monitoring cycle can be, for example, 10 seconds.

[0042] The embodiment of the present application does not limit the language of the monitoring program. Taking the monitoring program written in Python development language as an example, the monitoring program can include subprocess.run(). Executing subprocess.run() is equivalent to entering a command in the terminal of the operating system. After executing subprocess.run(), the specific monitoring instructions can continue to be executed to obtain the first monitoring information of the operating system.

[0043] The monitoring program of the embodiment of the present application may be pre-implanted into the operating system of the vehicle. For example, before S110, the method for determining whether the system is restarted may further include the following steps:

[0044] A first script is received in a preset manner, wherein the first script includes a monitoring program, and the monitoring program is used to monitor an operating system of the vehicle and / or a first process corresponding to the operating system. The preset manner includes a remote connection manner or a file transfer manner.

[0045] The first script may include a monitoring program, and may also include configuration information of the monitoring program and configuration information of startup items, etc., wherein the configuration information of the monitoring program mainly includes some maintainable monitoring information, such as the name of the monitored process, the monitoring period, the address of the backend server, the Uniform Resource Locator (URL), etc. The address and URL of the backend server are used to facilitate the subsequent operating system to send the monitoring results to the corresponding backend server.

[0046] For example, the configuration information of the monitoring program can be edited in a lightweight data exchange format (JavaScript Object Notation, JSON), a markup language (YAML Ain't Markup Language, referred to as YAML), an extensible markup language (Extensible Markup Language, XML), etc. In actual application, the configuration information of the monitoring program can be changed as needed.

[0047] The configuration information of the startup items is mainly used to configure which programs will run automatically when the operating system starts. In this way, when the vehicle is awakened from sleep or powered on, these programs can be automatically run when the operating system is started, without the need for manual operation. This simplifies the user's operation and improves monitoring efficiency.

[0048] For example, during the development and testing phase of a vehicle, a first script may be generated and implanted into the operating system in a preset manner, so that the operating system may automatically obtain monitoring information of the operating system based on the first script, thereby providing a basis for subsequent judgment of the stability of the operating system.

[0049] The preset method may include, for example, but is not limited to, a remote connection method and a file transfer method. The remote connection method may include, for example, a Secure Shell Protocol (SSH) method or a Secret File Transfer Protocol (SFTP) method.

[0050] The embodiment of the present application implants a first script containing a monitoring program into the operating system, so that the operating system can automatically obtain relevant information of the operating system based on the monitoring program, without the need for manual assistance from external equipment. This improves the efficiency of monitoring the performance of the actual vehicle system and can avoid misjudgments caused by human factors to a certain extent, thereby improving the accuracy of the monitoring results.

[0051] In S120, within the preset time period after the operating system is powered on, the first running time obtained at each time point is 0, that is, within the preset time period after the operating system is powered on, the first running time is 0 regardless of whether the operating system is restarted.

[0052] In order to prevent continuous misjudgment of operating system restarts within a preset time period, exemplarily, when the first running time is 0, the monitoring program can be executed at a time point outside the preset time period after power-on, that is, at a second time point, to obtain the second running time of the operating system at the second time point.

[0053] The size of the preset time period can be set as needed, for example, it can be set to 60s. Assuming that the first time point is the power-on time point, when the first running time is 0, the second running time of the operating system at the second time point after 60s can be obtained, and based on the second running time, it can be determined whether the operating system is restarted, thereby improving the accuracy of the restart result.

[0054] In S130, a restart determination result of the operating system may be obtained based on the second running time. For example, if the second running time is 0, it may be determined that the operating system has been restarted at the second time point, and if the second running time is greater than 0, it may be determined that the operating system has not been restarted at the second time point. In this way, a restart determination result of the operating system may be obtained.

[0055] The restart judgment result can be used to judge the stability of the operating system. For example, if the number of restarts of the operating system exceeds a set threshold within a set time period, it can be determined that the stability of the operating system is poor and the stability of the operating system needs to be further improved.

[0056] In the embodiment of the present application, when the first running duration at a first time point within a preset time period after the operating system is powered on is 0, the second running duration at a second time point outside the preset time period after the power-on can be obtained, and whether the operating system is restarted can be judged based on the second running duration. This can avoid the situation where the operating system is continuously misjudged to be restarted within the preset time period after the operating system is powered on, thereby improving the accuracy of the evaluation result when evaluating the stability of the operating system based on the restart judgment result of the operating system within a period of time.

[0057] The monitoring program of the embodiment of the present application can not only obtain the operating time after the operating system is powered on, but also obtain the process information of the first process such as the first process identifier, that is, the monitoring program can simultaneously obtain the operating time after the operating system is powered on and the first process identifier of the first process at this time. The first process identifier is used to uniquely identify the first process. Exemplarily, the first process identifier can be the identity document (ID) of the first process. The first process can include one or more processes, and different processes have different IDs. The ID of each process is randomly assigned to each process after the operating system is started.

[0058] In some embodiments, when obtaining the second running time of the operating system at the second time point, the method for determining the restart of the system may further include the following steps:

[0059] Get the second process ID of the first process;

[0060] Obtaining a correspondence between the first process and the second process identifier according to the second process identifier, and obtaining a first process dictionary;

[0061] The initial process dictionary is replaced with the first process dictionary, where the initial process dictionary is used to store the corresponding relationship between the first process and the first process identifier.

[0062] The second process identifier is used to uniquely identify the first process. The second process identifier may be the same as or different from the first process identifier. Usually, when the operating system is restarted, the process identifier of the first process will change. After waiting for a preset period of time, the embodiment of the present application can re-acquire the ID of each process to obtain the second process identifier.

[0063] Exemplarily, the second process identifier can be obtained based on the query command. It should be noted that, in addition to being represented by an ID, each process can also be represented by other identifiers at the same time. The identifier can be determined by the user, and the identifier remains unchanged when the operating system is restarted. That is, through the identifier and the query command, the ID of the corresponding first process can be obtained, providing a basis for subsequent determination of whether the process is restarted.

[0064] The first process dictionary is used to store the correspondence between the first process and the second process identifier, and the initial process dictionary is used to store the correspondence between the first process and the first process identifier. Each time the running time is obtained, the ID of each process can be obtained at the same time and compared with the ID of each process obtained last time. In this way, the restart status of each process can be determined, providing a basis for subsequent judgment of the stability of the process.

[0065] In the embodiment of the present application, when obtaining the second running time, the ID of the first process can be obtained at the same time to obtain the first process dictionary, and the initial process dictionary obtained before the second time point can be updated based on the first process dictionary, and the first process dictionary can be used as a reference dictionary for determining whether the process is restarted in the next monitoring cycle. In this way, it is possible to prevent misjudgment of process restart and improve the accuracy of the process restart judgment result, so that when the judgment result is stored in the database, it is possible to avoid inserting invalid data into the database.

[0066] Since the process ID is randomly assigned to each process, the process ID of each process may change when the process is restarted. Based on the change in the process ID, it can be determined whether the process is restarted, thereby more accurately judging whether the operating system is stable.

[0067] Exemplarily, the method for determining whether the system is restarted may further include the following steps:

[0068] When the second process identifier is different from the first process identifier, it is determined that the first process is restarted.

[0069] For example, process A is identified as ID1 in the initial process dictionary and as ID3 in the first process dictionary. Since ID1 is different from ID3, it can be determined that process A is restarted.

[0070] The embodiment of the present application can further accurately determine the restart status of each process by comparing the process dictionary obtained before the second time point with the process dictionary obtained at the second time point, while accurately determining the restart of the operating system.

[0071] In some embodiments, the first process dictionary may be compared with the initial process dictionary. If the first process dictionary is changed relative to the initial process dictionary, the initial process dictionary may be replaced with the first process dictionary.

[0072] In some embodiments, for the same first process, the first process identifier and the second process identifier corresponding to the first process may be compared. If the second process identifier is different from the first process identifier, the first process identifier is replaced with the second process identifier to obtain an updated initial process dictionary.

[0073] In some embodiments, the first monitoring information may also include at least one of a CPU usage rate, a memory usage rate, and a memory occupancy information of a first process corresponding to the operating system. The memory occupancy information of the first process may include the memory usage rate of the first process. Exemplarily, when the operating system is restarted, the CPU usage rate, the memory usage rate, and the memory occupancy information of the first process are all recorded as 0.

[0074] Accordingly, the method for determining whether the system is restarted may further include the following steps:

[0075] When the operating system restarts at the second time point, the number of times the CPU usage rate and the memory usage rate are 0 within a preset time period starting from the second time point is counted to obtain the number of restarts of the operating system within the preset time period, and the time point when the CPU usage rate and the memory usage rate are 0 is determined as the time point of the operating system restart;

[0076] Compare the first process dictionary with the initial process dictionary to obtain the number of times the process identifier of the first process changes within a preset time period and the time point of the change;

[0077] Count the number of restarts of the first process within a preset time and the time point of each restart.

[0078] The size of the preset duration can be set as needed. For example, the number of times the CPU and memory usage rates are both 0 within the preset duration can be counted, and the number can be determined as the number of times the operating system is restarted. For example, if the number of times the CPU and memory usage rates are both 0 within the preset duration is 3, it is considered that the operating system is restarted 3 times within the preset duration, and the time point of each restart of the operating system can be the time point when the CPU and memory usage rates are both recorded as 0.

[0079] The embodiment of the present application determines the restart of the operating system within a period of time outside the preset time period after power-on, which can more accurately determine the number of restarts of the operating system, and further more accurately evaluate the stability of the operating system.

[0080] The number of times the process identifier of the first process changes can be determined based on the process dictionary. Each time a process changes, the corresponding process dictionary is also updated. Therefore, the number of times the process identifier of each process changes and the time point of each change can be determined based on the update information of the process dictionary. For example, the number of times the process identifier of the first process changes within a preset time period and the time point of the change can be obtained by comparing the first process dictionary with the initial process dictionary.

[0081] When the process ID of a process changes, it can be determined that the process is restarted. Therefore, according to the number of times the process ID of each process changes within the preset time, the number of restarts of each process within the preset time and the time point of each restart can be determined.

[0082] In actual application, the operating system can simultaneously count the number of restarts of the operating system, the number of changes in the process identifier of the first process, and the number of restarts of the first process, or count them in order, which can be set according to actual conditions.

[0083] The embodiment of the present application can more accurately evaluate the stability of the operating system by counting the number of restarts of the operating system and the number of restarts of the corresponding process within a preset time period, which is of great significance to improving vehicle performance.

[0084] In some embodiments, Figure 2 As shown, the method for determining whether the system is restarted may include the following steps:

[0085] S210: Obtain first monitoring information of the operating system.

[0086] S220: When the first running time is 0, after waiting for a preset time, obtain a second running time of the operating system at a second time point.

[0087] S230: Generate a restart determination result of the operating system based on the second running time.

[0088] S240: Send the restart determination result of the operating system to the back-end server through the gateway, and the back-end server sends the restart determination result to the front-end server for display.

[0089] Among them, the process of S210-S230 is the same as the above-mentioned process of S110-S130. For details, please refer to the description of S110-S130. For the sake of brevity, it will not be repeated here.

[0090] The other steps above are described in detail below:

[0091] In S240, Figure 3As shown, the gateway 31 is used to connect the communication between the internal network and the external network, wherein the back-end server 32 and the database 33 are located in the internal network, for example, can be deployed in the company's intranet, and the related services of the back-end server 32 are registered to the gateway domain name, and the gateway domain name can generally be configured for public network access.

[0092] Because automobile networking generally uses cellular networking technology such as 5G, it is usually in a public network environment. Through the gateway, communication between the intranet and the public network can be established to avoid the situation where the vehicle is in a public network environment and cannot break through the company firewall to access related services in the back-end server 32.

[0093] The vehicle system 34, that is, the operating system in the above embodiment, can send the restart judgment result of the operating system to the backend server 32 through the gateway 31 after obtaining the restart judgment result of the operating system, and the backend server 32 stores it in the database 33. Exemplarily, the vehicle system 34 can send a request to the backend server 32 through the Hyper Text Transfer Protocol (HTTP), and the request can include the vehicle identification number (VIN) and the restart judgment result of the operating system. After receiving the request, the backend server 32 stores the restart judgment result of the operating system in the database 33 through a database operation model such as Object Relational Mapping (ORM), so as to facilitate subsequent search and use.

[0094] Exemplarily, the backend server 32 may also interact with the frontend server 35 to meet the needs of the frontend server 35. For example, a user may query the monitoring results of a vehicle through the frontend server 35. Specifically, after receiving the query operation of the user, the frontend server 35 may request the corresponding interface of the backend server 32. After receiving the request of the frontend server 35, the backend server 32 responds to the request and returns a response result to the frontend server 35. Exemplarily, the frontend server 35 may send a request to the corresponding interface of the backend server 32 based on the HTTP protocol.

[0095] In actual application, in addition to sending the restart judgment result of the operating system to the back-end server 32, the vehicle system 34 can also send the above-mentioned statistical results such as the number of restarts of the operating system within the preset time period and the time point of each restart, the number of changes in the process identifier of the first process within the preset time period and the time point of the change, and the number of restarts of the first process within the preset time period and the time point of each restart, etc. to the back-end server 32. This can provide more sufficient monitoring data for relevant personnel, so that relevant personnel can fully analyze and formulate optimization measures.

[0096] Exemplarily, the response result returned by the back-end server 32 to the front-end server 35 may be a list or an array, and each element may be data on a time point, total memory size, total memory occupancy, and memory occupancy of each process.

[0097] Exemplarily, after receiving the response result returned by the back-end server 32, the front-end server 35 can render it in the form of a visual chart, presenting the user with clear statistical charts such as broken lines, which is convenient for the user to watch. Exemplarily, the page where the statistical chart is located also supports functions such as filtering and deleting data by date.

[0098] For example, the page can also display the total memory and CPU of the operating system, and can also support multiple selections, and can also display the CPU and memory size of each process. In addition to the statistical chart, the page can also display the restart status of each process in the form of a table, for example, it can include but not be limited to the restart times, time points, and IDs of the processes before and after the restart.

[0099] The above display method is just one example. In actual application, there may be other display methods, which can be set by the user to meet the needs of the user.

[0100] After obtaining the restart judgment result of the operating system, the embodiment of the present application can send the restart judgment result of the operating system to the back-end server for storage, so as to facilitate the interaction between the back-end server and the front-end server and meet the query needs of the front-end users.

[0101] In some embodiments, the method for determining whether the system is restarted may further include the following steps:

[0102] When the operating system is restarted, the restart judgment result and the restart time of the operating system are sent to the target electronic device for warning.

[0103] The target electronic device may be an electronic device capable of receiving alarm information, such as a mobile phone, a computer, etc. For example, when it is determined that the operating system is restarted, the operating system may send the restart judgment result and the restart time to the target electronic device for alarm by accessing the relevant enterprise system or platform, such as email, text message, etc., so as to notify relevant personnel that the operating system is abnormal at a certain time point, so as to facilitate relevant personnel to record and troubleshoot the problem in time.

[0104] In some embodiments, the method for determining whether the system is restarted may further include the following steps:

[0105] Get the vehicle identification of the vehicle;

[0106] The vehicle identification is associated with the restart judgment result of the operating system, and the associated result is sent to the cloud server for storage.

[0107] The vehicle identification is used to uniquely identify the vehicle. For example, the vehicle identification can be a VIN. One vehicle can correspond to one VIN. After obtaining the restart judgment result, the operating system can associate the restart judgment result with the VIN and upload it to the cloud server for storage through the automobile network. In this way, relevant personnel can query and analyze the performance data of different vehicles, formulate and optimize countermeasures, improve the performance of the vehicle, and meet the needs of users.

[0108] After the embodiment of the present application deploys the first script containing the monitoring program to the vehicle system with one click, the monitoring program can be automatically executed to obtain the CPU usage, memory usage and restart status of the operating system, as well as the restart status of each process. There is no need to obtain it manually based on external devices, which improves the monitoring efficiency. At the same time, the restart of the operating system and the restart of each process can be accurately judged based on the running time of the monitored operating system, so as to quickly and accurately discover the stability problems of the system and avoid safety hazards.

[0109] Based on the same inventive concept, the embodiment of the present application also provides a system restart determination device. Figure 4 The system restart determination device provided in the embodiment of the present application is described in detail.

[0110] Figure 4 A structural diagram of a system restart determination device provided in an embodiment of the present application, such as Figure 4 As shown, the system restart determination device may include: an acquisition module 410 and a generation module 420;

[0111] An acquisition module 410 is used to acquire first monitoring information of the operating system, where the first monitoring information includes a first running time at a first time point after the operating system is powered on, where the first time point is a time point within a preset time period after the operating system is powered on;

[0112] The acquisition module 410 is further used to acquire, when the first operation time is 0, a second operation time of the operating system at a second time point, where the second time point is a time point outside a preset time period after the operating system is powered on;

[0113] The generating module 420 is used to generate a restart determination result of the operating system based on the second running time, wherein when the second running time is 0, the restart determination result indicates that the operating system restarts at a second time point.

[0114] The embodiment of the present application obtains first monitoring information of the operating system, where the first monitoring information includes a first running time at a first time point after the operating system is powered on. When the first running time is 0, the second running time of the operating system at a second time point is obtained, wherein the first time point is a time point within a preset time period after the operating system is powered on, and the second time point is a time point outside the preset time period after the operating system is powered on. When the second running time is 0, it is determined that a system restart occurs at the second time point in the operating system. That is, when the embodiment of the present application monitors that the first running time is 0 at a first time point within the preset time period after the operating system is powered on, the second running time of the operating system at the second time point is obtained again, and whether the operating system is restarted is determined based on the second running time, thereby effectively avoiding the situation where the operating system restart is misjudged due to the complexity of the operation within the preset time period after the operating system is powered on. That is, the embodiment of the present application can judge the restart situation at a time point outside the preset time period after the operating system is powered on, thereby improving the accuracy of the operating system restart judgment result.

[0115] In some embodiments, the first monitoring information further includes a first process identifier of a first process corresponding to the operating system; the acquisition module 410 is further used to acquire a second process identifier of the first process after waiting for a preset period of time;

[0116] The acquisition module 410 is further used to acquire the correspondence between the first process and the second process identifier according to the second process identifier, and obtain the first process dictionary;

[0117] The system restart determination device may also include:

[0118] The replacement module is used to replace the initial process dictionary with the first process dictionary, where the initial process dictionary is used to store the correspondence between the first process and the first process identifier.

[0119] In some embodiments, the system restart determination means may further include:

[0120] The determination module is used to determine that the first process is restarted when the second process identifier is different from the first process identifier.

[0121] In some embodiments, the first monitoring information further includes at least one of a CPU usage rate of the operating system, a memory usage rate, and memory occupancy information of a first process corresponding to the operating system;

[0122] The system restart determination device may also include:

[0123] a statistics module, for counting the number of times the CPU usage rate and the memory usage rate are 0 within a preset time period starting from the second time point when the operating system restarts at the second time point, obtaining the number of restarts of the operating system within the preset time period, and determining the time point when the CPU usage rate and the memory usage rate are 0 as the time point when the operating system restarts;

[0124] A comparison module, used to compare the first process dictionary with the initial process dictionary, and obtain the number of times the process identifier of the first process changes within a preset time period and the time point of the change;

[0125] The statistics module is also used to count the number of restarts of the first process within a preset time period and the time point of each restart.

[0126] In some embodiments, the system restart determination means may further include:

[0127] The sending module is used to send the restart judgment result of the operating system to the backend server through the gateway after the generation module 420 generates the restart judgment result of the operating system based on the second running time, and the backend server sends the restart judgment result to the front-end server for display.

[0128] In some embodiments, the sending module is further used to send the restart judgment result and restart time of the operating system to the target electronic device for warning when the operating system is restarted.

[0129] In some embodiments, the acquisition module 410 is further used to acquire a vehicle identification of the vehicle;

[0130] The system restart determination device may also include:

[0131] An association module, used to associate the vehicle identification with the restart judgment result of the operating system;

[0132] The sending module is also used to send the association results to the cloud server for storage.

[0133] Figure 4 Each module in the device shown has the function of realizing Figure 1-Figure 3 The functions of each step in the process can achieve the corresponding technical effects, so for the sake of brevity, they will not be described in detail here.

[0134] Based on the same inventive concept, the present application embodiment also provides an electronic device. Figure 5 The electronic device provided in the embodiments of the present application is described in detail.

[0135] like Figure 5 As shown, the electronic device may include a processor 510 and a memory 520 for storing computer program instructions.

[0136] The processor 510 may include a central processing unit (CPU) or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0137] The memory 520 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 520 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In one example, the memory 520 may include a removable or non-removable (or fixed) medium, or the memory 520 is a non-volatile solid-state memory. In one example, the memory 520 may be a read-only memory (ROM). In one example, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM) or a flash memory or a combination of two or more of these.

[0138] The processor 510 reads and executes the computer program instructions stored in the memory 520 to implement Figure 1-Figure 3 The method in the embodiment shown in the figure is achieved Figure 1-Figure 3 The corresponding technical effects achieved by executing the method in the illustrated embodiment are not described in detail here for the sake of brevity.

[0139] In one example, the electronic device may further include a communication interface 530 and a bus 540. Figure 5 As shown, the processor 510, the memory 520, and the communication interface 530 are connected via a bus 540 and communicate with each other.

[0140] The communication interface 530 is mainly used to implement communication between various modules, devices and / or equipment in the embodiments of the present application.

[0141] Bus 540 includes hardware, software or both, and each component of electronic device is coupled to each other.For example, but not limitation, bus 540 may include accelerated graphics port (Accelerated Graphics Port, AGP) or other graphics bus, enhanced industry standard architecture (Extended Industry Standard Architecture, EISA) bus, front side bus (Front Side Bus, FSB), hypertransmission (Hyper Transport, HT) interconnection, industry standard architecture (IndustryStandard Architecture, ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 540 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the application considers any suitable bus or interconnection.

[0142] After the electronic device obtains the first monitoring information of the operating system, it can execute the method for determining the system restart in the embodiment of the present application, thereby realizing the combination Figure 1-Figure 3 The method for determining the system restart described and Figure 4 Describes the system restart determination means.

[0143] Based on the same inventive concept, an embodiment of the present application further provides a storage medium, on which a program or instruction is stored, and when the program or instruction is executed by a processor, the method for determining system restart as described in the above embodiment is implemented.

[0144] Based on the same inventive concept, an embodiment of the present application further provides a vehicle, the vehicle comprising a system restart determination device as described in the above embodiment; or, an electronic device as described in the above embodiment; or, a storage medium as described in the above embodiment.

[0145] It should be understood that the above specific embodiments of the present application are only used to illustrate or explain the principles of the present application, and do not constitute a limitation to the present application. Therefore, any modifications, equivalent substitutions, improvements, etc. made without departing from the spirit and scope of the present application should be included in the protection scope of the present application. In addition, the claims attached to the present application are intended to cover all changes and modifications that fall within the scope and boundaries of the attached claims, or the equivalent forms of such scope and boundaries.

[0146] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0147] The above reference is according to the method of the embodiment of the present application, the flow chart of the device (system) and the computer program product and / or the block diagram described various aspects of the present application.It should be understood that each square box in the flow chart and / or the block diagram and the combination of each square box in the flow chart and / or the block diagram can be realized by computer program instructions.These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the realization of the function / action specified in one or more square boxes of the flow chart and / or the block diagram.Such a processor can be but is not limited to a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit.It can also be understood that each square box in the block diagram and / or the flow chart and the combination of the square boxes in the block diagram and / or the flow chart can also be realized by the dedicated hardware that performs the specified function or action, or can be realized by the combination of dedicated hardware and computer instructions.

[0148] The above is only a specific implementation of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A method for determining a system restart, characterized in that: include: Acquire first monitoring information of the operating system, the first monitoring information including a first running time at a first time point after the operating system is powered on, the first time point being a time point within a preset time period after the operating system is powered on; When the first running time is 0, obtaining a second running time of the operating system at a second time point, where the second time point is a time point outside a preset time period after the operating system is powered on; A restart determination result of the operating system is generated based on the second running time, wherein, when the second running time is 0, the restart determination result indicates that a system restart occurs to the operating system at the second time point.

2. The method according to claim 1, characterized in that The first monitoring information also includes a first process identifier of a first process corresponding to the operating system; and the method further includes: Obtaining a second process identifier of the first process; Acquire a correspondence between the first process and the second process identifier according to the second process identifier to obtain a first process dictionary; An initial process dictionary is replaced with the first process dictionary, where the initial process dictionary is used to store a correspondence between the first process and the first process identifier.

3. The method according to claim 2, characterized in that The method further comprises: When the second process identifier is different from the first process identifier, it is determined that the first process is restarted.

4. The method according to claim 3, characterized in that The first monitoring information also includes at least one of the CPU usage rate and memory usage rate of the operating system and the memory occupancy information of the first process corresponding to the operating system; the method also includes: In the case where the operating system restarts at the second time point, counting the number of times the CPU usage rate and the memory usage rate are 0 within a preset time period starting from the second time point, obtaining the number of restarts of the operating system within the preset time period, and determining the time point when the CPU usage rate and the memory usage rate are 0 as the time point of the restart of the operating system; Comparing the first process dictionary with the initial process dictionary, obtaining the number of times the process identifier of the first process changes within the preset time period and the time point of the change; The number of restarts of the first process within the preset time period and the time point of each restart are counted.

5. The method according to claim 1, characterized in that After generating the restart determination result of the operating system based on the second running time, the method further includes: The restart determination result of the operating system is sent to a back-end server through a gateway, and the back-end server sends the restart determination result to a front-end server for display.

6. The method according to claim 1, characterized in that The method further comprises: When the operating system is restarted, the restart determination result and the restart time of the operating system are sent to the target electronic device for warning.

7. The method according to claim 1, characterized in that The method further comprises: Get the vehicle identification of the vehicle; The vehicle identification is associated with the restart determination result of the operating system, and the associated result is sent to a cloud server for storage.

8. The method according to any one of claims 1 to 7, characterized in that: Before obtaining the first monitoring information of the operating system, the method further includes: A first script is received in a preset manner, wherein the first script includes a monitoring program, and the monitoring program is used to monitor an operating system of a vehicle and / or a first process corresponding to the operating system. The preset manner includes a remote connection manner or a file transfer manner.

9. A system restart determination device, characterized in that: include: Get modules and generate modules; The acquisition module is used to acquire first monitoring information of the operating system, wherein the first monitoring information includes a first running time at a first time point after the operating system is powered on, and the first time point is a time point within a preset time period after the operating system is powered on; The acquisition module is further configured to acquire, when the first running time is 0, a second running time of the operating system at a second time point, where the second time point is a time point outside a preset time period after the operating system is powered on; The generating module is used to generate a restart determination result of the operating system based on the second running time, wherein when the second running time is 0, the restart determination result indicates that a system restart occurs to the operating system at the second time point.

10. An electronic device, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the method according to any one of claims 1 to 8 is implemented.

11. A vehicle, characterized in that: The vehicle comprises the system restart determination device as claimed in claim 9; or, the electronic device as claimed in claim 10.

Images