Program monitoring method and device, vehicle and storage medium
By setting up the main real-time core and independent real-time core in the hardware domain, and installing monitoring modules in the independent real-time core to detect and handle abnormal applications, the problem of program monitoring software failure in the existing technology is solved, and the application stability is achieved Automatic reset of the operation and system.
Patent Information
- Application Number
- CN202411216155.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-30
- Publication Date
- 2025-01-10
AI Technical Summary
Existing program monitoring software may lose monitoring capabilities when detecting application exceptions, resulting in failure to operate normally, which will affect the stability of the system.
Set up the main real-time core and independent real-time core in the hardware domain, and install the monitoring module in the independent real-time core. The monitoring module obtains the application running status information in the main real-time core. If an abnormal application is detected, send it to the dog feeding module. Fault notification, stop feeding the dog signal, and make the power module send a reset signal to the main real-time core, thereby realizing automatic reset of the application.
It effectively avoids the risk of failure of the monitoring module itself, ensures the stable operation of the application and the normal reset of the system, and improves the reliability of program monitoring.
Smart Images

Figure CN119292862A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the automotive field, and specifically relates to a program monitoring method, device, vehicle and readable storage medium. Background Art
[0002] When the car is driving, the user may enable various applications. In order to ensure the normal use of the application, a program monitoring software is generally developed in the real-time core where the application is located to monitor each application. When the monitored application is abnormal, the monitoring program will kill the abnormal application or reset the system to prevent the software from running in an unexpected manner. However, since the program monitoring software is actually an application, when the monitored application has problems such as stack overflow, logical error, and program dead loop, the program monitoring software will not run normally and lose its monitoring ability. Summary of the invention
[0003] In view of the above problems, the present application proposes a program monitoring method, device, vehicle and storage medium to improve the above problems.
[0004] In a first aspect, an embodiment of the present application provides a program monitoring method, which is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes: obtaining the running status information of each of multiple applications running in a main real-time core, and the main real-time core is deployed in the hardware domain; based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, sending a fault notification to a dog feeding module, and the fault notification is used to instruct the dog feeding module to stop sending a dog feeding signal to a power supply module, so that the power supply module sends a reset signal to the main real-time core.
[0005] In a second aspect, an embodiment of the present application provides a program monitoring method, which is applied to a program monitoring system, wherein the program monitoring system includes a main real-time core, a power module and an independent real-time core, wherein the independent real-time core includes a monitoring module and a dog feeding module; the method includes: the main real-time core sends the running status information of multiple applications to the monitoring module, the monitoring module is deployed in the independent real-time core, and the independent real-time core and the main real-time core are both deployed in the hardware domain; the monitoring module sends a fault notification to the dog feeding module if it determines that there is an abnormal application among the multiple applications based on the running status information of the multiple applications; the power module sends a reset signal to the main real-time core based on the dog feeding signal, and the reset signal is a signal sent by the power module when the dog feeding module stops sending the dog feeding signal to the power module based on the fault notification; the main real-time core performs a reset operation in response to the reset signal.
[0006] In the third aspect, an embodiment of the present application provides a program monitoring device, which runs in a monitoring module, and the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The device includes: an information acquisition unit, used to obtain the running status information of each of the multiple applications running in the main real-time core, and the main real-time core is deployed in the hardware domain; a notification sending unit, used to send a fault notification to the dog feeding module based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power supply module, so that the power supply module sends a reset signal to the main real-time core.
[0007] In a fourth aspect, an embodiment of the present application provides a program monitoring system, which includes a main real-time core, a power module and an independent real-time core, wherein the independent real-time core includes a monitoring module and a dog feeding module; the main real-time core is used to send the running status information of each of the multiple applications to the monitoring module, and the monitoring module is deployed in the independent real-time core, and the independent real-time core and the main real-time core are both deployed in the hardware domain; the monitoring module is used to send a fault notification to the dog feeding module based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications; the power module is used to send a reset signal to the main real-time core based on the dog feeding signal, and the reset signal is a signal sent by the power module when the dog feeding module stops sending the dog feeding signal to the power module based on the fault notification; the main real-time core is also used to perform a reset operation in response to the reset signal.
[0008] In a fifth aspect, the present application provides a vehicle comprising a power supply, a hardware domain, one or more processors and a memory, wherein the hardware domain comprises a main real-time core and an independent real-time core; one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the above-mentioned method.
[0009] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a program code is stored, wherein the above method is executed when the program code is run.
[0010] The embodiment of the present application provides a program monitoring method, device, vehicle and storage medium. The method includes: setting a main real-time core and an independent real-time core in a hardware domain, installing a monitoring module in the independent real-time core, and monitoring multiple applications in the main real-time core by the monitoring module. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of the monitoring module also failing when the application fails. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.
[0012] Figure 1 An application scenario diagram of a program monitoring method proposed in an embodiment of the present application is shown;
[0013] Figure 2 An application scenario diagram of a program monitoring method proposed in an embodiment of the present application is shown;
[0014] Figure 3 An application scenario diagram of a program monitoring method proposed in an embodiment of the present application is shown;
[0015] Figure 4 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0016] Figure 5 A structural diagram of an independent real-time core of a program monitoring method proposed in another embodiment of the present application is shown;
[0017] Figure 6 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0018] Figure 7 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0019] Figure 8 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0020] Fig. 9 A schematic diagram showing the structure of a program monitoring method proposed in another embodiment of the present application is shown;
[0021] Fig.10 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0022] Fig.11 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0023] Fig.12 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0024] Fig.13 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0025] Fig.14 A flowchart of a program monitoring method proposed in another embodiment of the present application is shown;
[0026] Fig.15 A structural block diagram of a program monitoring method proposed in another embodiment of the present application is shown;
[0027] Fig.16 A structural block diagram of a program monitoring method proposed in another embodiment of the present application is shown;
[0028] Fig.17 A structural block diagram of a program monitoring method proposed in another embodiment of the present application is shown;
[0029] Fig.18 A structural block diagram of a program monitoring system proposed in an embodiment of the present application is shown;
[0030] Fig.19 A structural block diagram of a vehicle for executing a program monitoring method according to an embodiment of the present application is shown;
[0031] Fig. 20 A storage unit in an embodiment of the present application is shown for storing or carrying program codes for implementing a program monitoring method according to an embodiment of the present application. DETAILED DESCRIPTION
[0032] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or server comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, and may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.
[0034] In the embodiments of the present application, the inventor proposes a program monitoring method, device, vehicle and storage medium. The program monitoring method includes: obtaining the running status information of each of the multiple applications running in the main real-time core, and the main real-time core is deployed in the hardware domain; based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, a fault notification is sent to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core. The main real-time core and the independent real-time core are set in the hardware domain, and the monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain where only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of the monitoring module also failing when the application fails.
[0035] See also Figure 1 , the program monitoring method provided in the embodiment of the present application can be applied to a program monitoring system 100, wherein the program monitoring system 100 includes a power module 110 and a hardware domain 120, and the power module 110 is connected to the hardware domain 120. Among them, the power module 110 is used to supply power to the hardware domain 120, and to send a reset signal to the hardware domain 120 when the dog-feeding signal sent by the hardware domain 120 is not received; the hardware domain 1120 is used to continuously send the dog-feeding signal to the power module 110 when multiple applications are normal, stop sending the dog-feeding signal to the power module 110 when there is an application abnormality, and receive the reset signal sent by the power module 110, and perform a reset operation on the main real-time core in response to the received reset signal.
[0036] See also Figure 2, the hardware domain 120 includes a main real-time core 121 and an independent real-time core 122, and the main real-time core 121 is in communication connection with the independent real-time core 122. The main real-time core 121 includes multiple applications, and is used to continuously send the running status information of the multiple applications to the independent real-time core 122, and receive the reset signal sent by the power module 110, and reset the multiple applications in response to the received reset signal; the independent real-time core 122 is used to receive the running status information of the multiple applications sent by the main real-time core 121, and judge whether there is an abnormal application among the multiple applications based on the received running status information, and send a dog feeding signal to the power module 110 when it is determined that there is no abnormal application; when it is determined that there is an abnormal application, stop sending the dog feeding signal to the power module 110, and store the running status information of the abnormal application, and store the running status information of the abnormal application in the main real-time core 121 when it is determined that the main real-time core 121 is reset successfully.
[0037] See also Figure 3 The independent real-time core 122 includes a dog feeding module 1221 , a monitoring module 1222 and a log module 1223 , wherein the dog feeding module 1221 is communicatively connected to the monitoring module 1222 , and the monitoring module 1222 is communicatively connected to the log module 1223 . The monitoring module 1222 is used to receive the running status information of each of the multiple applications sent by the main real-time core 121, and determine whether there is an abnormal application among the multiple applications based on the received running status information. When there is no abnormal application, a running maintenance signal is sent to the dog feeding module 1221; when there is an abnormal application, a fault notification is sent to the dog feeding module 1221, and the running status information corresponding to the abnormal application is sent to the log module 1223 for storage; the dog feeding module 1221 is used to obtain the running maintenance signal sent by the monitoring module 1222 when the multiple applications are normal, and send the dog feeding signal to the power module 110; when there is an abnormal application among the multiple applications, the fault notification is obtained from the monitoring module 1222, and the dog feeding signal is stopped to the power module 110; the log module 1223 is used to store the running status information of the abnormal application sent by the received monitoring module 1222 when there is an abnormal application among the multiple applications, and send the running status information of the abnormal application to the main real-time core 121 after determining that the main real-time core 121 has completed the reset.
[0038] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.
[0039] See also Figure 4 The embodiment of the present application provides a program monitoring method, which is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes:
[0040] Step S110: acquiring the running status information of each of the plurality of application programs running in the main real-time core deployed in the hardware domain.
[0041] In an embodiment of the present application, the running status information is information indicating the state of the application when it is running. The main real-time core is an MCU, and there are multiple applications and the main real-time core operating system in the MCU. The hardware domain is an area that supports the operation of the main real-time core and the independent real-time core. When multiple applications are running in the main real-time core, running status information will be generated at all times, and the running status information generated by each of the multiple applications is obtained by the monitoring module in the independent real-time core. Among them, the monitoring module is a module that monitors multiple applications according to the running status information of each of the multiple applications. Among them, the running status information of the application includes three running status sub-information, namely Logic, Alive and Deadline. Among them, Logic represents the logical state of the application; Alive represents the normal operating state of the application; Deadline represents the state of the running time of the application.
[0042] Step S120: Based on the respective running status information of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, a fault notification is sent to the dog feeding module, and the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core.
[0043] In an embodiment of the present application, the dog feeding module is a module that sends a dog feeding signal to the power module when the applications are all normal. The dog feeding signal is essentially a pulse signal, and the fault notification is a notification sent by the monitoring module to the dog feeding module when an abnormal application exists. After the monitoring module receives the running status information of multiple applications, since the running status information includes three running status sub-information, the monitoring module needs to verify the running status sub-information included in each running status information. If it is determined that there is an abnormal running status sub-information among the three running status sub-information included in the running status information, it is determined that the application corresponding to the running status to which the abnormal running status sub-information belongs is an abnormal application. After determining that there is an abnormal application, a fault notification is sent to the dog feeding module. When the dog feeding module receives the fault notification, it is determined that there is an abnormal application at this time, and stops sending the dog feeding signal to the watchdog module in the power module, so that the watchdog module in the power module sends a reset signal to the main real-time core.
[0044] Among them, in the independent real-time core, in addition to the monitoring module and the dog feeding module, there is only a log module, which has a simple structure, simple and reliable communication, and has a very low probability of problems itself and a very low probability of common mode failure.
[0045] As a method, in addition to receiving the running status information of multiple applications uploaded by the main real-time core, the monitoring module also receives the running status information of the main real-time core operating system uploaded by the main real-time core and the running status information of the memory, etc., which are not specifically limited here. Taking the main real-time core operating system as an example, when the monitoring module receives the running status information corresponding to the main real-time core operating system, the running status information is verified. If the verification of the running status information fails, it is considered that there is an abnormality in the main real-time core operating system, and a fault notification is sent to the dog feeding module. When the dog feeding module receives the fault notification, it stops sending the dog feeding signal to the power supply module. After determining that the dog feeding signal is not received, the power supply module sends a reset signal to the main real-time core, so that the main real-time core resets the main real-time core operating system according to the reset signal. The processing of the memory can also refer to the above process.
[0046] As a way, although the probability of abnormality in the monitoring module in this solution is extremely low, in order to avoid the losses caused by abnormality in the monitoring module, this solution can deploy two monitoring modules in an independent real-time core, one as the main monitoring module and the other as the backup monitoring module. There is a communication connection between the main monitoring module and the backup monitoring module, and the main monitoring module always sends a heartbeat signal to the backup monitoring module. After receiving the heartbeat signal, the backup monitoring module can determine that the main monitoring module is still running normally, and the main monitoring module and the backup monitoring module simultaneously obtain the respective running status information of multiple applications. The specific structure can be as follows Figure 5 As shown. When the main monitoring module fails, the main monitoring module stops sending heartbeat signals to the backup monitoring module. When the backup monitoring module determines that it has not received the heartbeat signal, it determines that the main monitoring module has failed. At this time, the backup monitoring module acts as the main monitoring module and continues to verify the operating status information corresponding to the received multiple applications. When it is determined that there is an abnormal application, it sends a fault notification to the dog feeding module, so that the dog feeding module stops sending dog feeding signals to the power module, so that the power module sends a reset signal to the main real-time core. Of course, this solution can also deploy more monitoring modules in the independent real-time core, but deploying more monitoring modules will increase costs, and integrating too many modules will also reduce the anti-interference ability of the independent real-time core. Therefore, generally two monitoring modules are deployed in the independent real-time core.
[0047] A monitoring method provided in an embodiment of the present application is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain, and the monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications, and this solution avoids the risk of the monitoring module also failing when an application fails.
[0048] See also Figure 6 The embodiment of the present application provides a program monitoring method, which is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes:
[0049] Step S210: acquiring the running status information of each of the plurality of application programs running in the main real-time core deployed in the hardware domain.
[0050] For details of step S210, reference may be made to the detailed explanation in the above embodiment, so it will not be described in detail in this embodiment.
[0051] Step S220: Acquire abnormal running status information from the running status information of each of the plurality of application programs.
[0052] In the embodiment of the present application, the abnormal operation status information is the operation status information generated by the abnormal application. After the monitoring module obtains the operation status information of each of the multiple applications sent by the main real-time core, it is necessary to determine whether there is abnormal operation status information in the obtained operation status information. If it is determined that the obtained operation status information is all normal operation status information, the obtained operation status information is discarded; if there is abnormal operation status information in the operation status information of each of the multiple applications obtained, the abnormal operation status information is obtained and the normal operation status information is discarded.
[0053] The method for determining the abnormal operation status information may be as described in step S221 and step S222.
[0054] Step S221: verifying the integrity of the running status information of each of the multiple application programs.
[0055] In an embodiment of the present application, as described in step S110, the running status information includes three running status sub-information, each running status sub-information is composed of a state variable string, and a state variable string includes multiple state variables. The state variables can be represented by 0 and 1, and are not specifically limited here. Among the multiple state variables included in the state variable string corresponding to each running status sub-information, if the state variable is 1, it indicates normal; if the state variable is 0, it indicates abnormal. The first state variable indicates whether the corresponding running status sub-information is abnormal, and the remaining state variables indicate the possible reasons that cause the running status sub-information to be abnormal. Therefore, after receiving the running status information, the monitoring module can determine whether the running status sub-information is abnormal and determine the reason for the abnormality by querying the first state variable in the state variable string corresponding to each running status sub-information. For example, the running state sub-information is information indicating the Logic state, and the state variable string corresponding to the running state sub-information includes five state variables. If the state variable string included in the running state sub-information corresponding to the Logic state obtained by the monitoring module is 11111, it can be determined that the running state sub-information corresponding to the Logic state is the normal running state sub-information; if the state variable string corresponding to the running state sub-information corresponding to the Logic state obtained by the monitoring module is 01001, by determining that the first state variable is 0, it can be determined that the running state sub-information corresponding to the Logic state is abnormal running state sub-information, and the cause of the abnormal running state sub-information can be determined by the state variable with the character 0 in the subsequent four-bit state variable. Among them, the abnormal running state sub-information indicates the abnormal running state sub-information. Of course, there are also unknown reasons that cause the running state sub-information to be abnormal, and at this time, the state variable string corresponding to the running state sub-information received by the monitoring module is 01111; it is also possible that the first state variable of the state variable string corresponding to the received running state sub-information is 1, but there are 0s in the subsequent state variables, and the monitoring module still considers that the running state sub-information is normal.
[0056] Step S222: using the operation status information of each of the plurality of application programs that fails to be verified as the abnormal operation status information.
[0057] In the embodiment of the present application, when the monitoring module determines that among the state variable strings corresponding to the multiple operation status sub-information included in the received operation status information, the first state variable of the state variable string is 0, it is determined that the verification of the operation status sub-information corresponding to the state variable string has failed, and the operation status sub-information corresponding to the state variable string is determined to be abnormal operation status sub-information. When the monitoring module determines that among the multiple operation status sub-information included in the operation status information, there is abnormal operation status sub-information, it is determined that the operation status information is abnormal operation status information.
[0058] Step S230: If the abnormal operation status information is continuously obtained within a preset time period, it is determined that the application corresponding to the abnormal operation status information is an abnormal application.
[0059] In an embodiment of the present application, in order to prevent the occurrence of false alarms of applications, after determining that the running status information of a certain application is abnormal running status information, the monitoring module needs to verify the abnormal running status information multiple times. After determining the abnormal running status information, the monitoring module determines the application corresponding to the abnormal running status information and uses the application as a candidate application. The subsequent monitoring module continues to obtain the running status information of each of the multiple applications within a preset time period, and continues to determine the running status information corresponding to the candidate application from it, and continues to verify the integrity of the running status information. The verification process can refer to step S221. If after each verification, it is determined that the running status information is abnormal running status information, and the abnormal running status sub-information in the abnormal running status information is the same as the abnormal running status information in the previous verification process, and the state variable string corresponding to the abnormal running status sub-information is the same as the state variable corresponding to the abnormal running status sub-information in the previous verification process, then it is determined that the candidate application corresponding to the abnormal running status information is an abnormal application.
[0060] Exemplarily, if the monitoring module first obtains the abnormal running status including the abnormal running status sub-information as the information corresponding to the Logic status, and the state variable string corresponding to the abnormal running status sub-information is 01101, and it is determined that the application corresponding to the abnormal running status is application 1, then the running status information corresponding to application 1 that the monitoring module subsequently obtains continuously within the preset time period must include the running status sub-information corresponding to the Logic status as the abnormal running status sub-information, and the state variable string corresponding to the abnormal running status sub-information must be 01101, otherwise the monitoring module deems it to be a false alarm of the application.
[0061] Step S240: Sending a fault notification to the dog feeding module, wherein the fault notification is used to instruct the dog feeding module to stop sending a dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core.
[0062] A monitoring method provided in an embodiment of the present application is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain, and the monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications, and this solution avoids the risk of the monitoring module also failing when an application fails.
[0063] See also Figure 7 The embodiment of the present application provides a program monitoring method, which is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes:
[0064] Step S310: acquiring the running status information of each of the plurality of application programs running in the main real-time core deployed in the hardware domain.
[0065] For details of step S310, reference may be made to the detailed description in the above embodiment, and thus no specific limitation is made in this embodiment.
[0066] Step S320: Based on the respective running status information of the multiple applications, if it is determined that the multiple applications are all normal applications, a normal notification is sent to the dog feeding module, so that the dog feeding module sends a dog feeding signal to the power module.
[0067] As a method, the monitoring module can also be set to send a fault notification to the dog feeding module when there is an abnormal application; when there is no abnormal application, nothing is done to the dog feeding module. Based on the setting method of the monitoring module, the dog feeding module can also be set to send a dog feeding signal to the power module normally when no fault notification is received; when a fault notification is received, stop sending the dog feeding signal to the power module.
[0068] A program monitoring method provided in an embodiment of the present application is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain, and the monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications, and this solution avoids the risk of the monitoring module also failing when an application fails.
[0069] See also Figure 8 The embodiment of the present application provides a program monitoring method, which is applied to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes:
[0070] Step S410: acquiring the running status information of each of the plurality of application programs running in the main real-time core deployed in the hardware domain.
[0071] The details of step S410 may refer to the detailed description in the above embodiment, so it is not specifically limited in this embodiment.
[0072] Step S420: Based on the respective running status information of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, the running status information of the abnormal application is stored in the log module, so that the log module stores the running status information in the main real-time core after the main real-time core is reset successfully.
[0073] In the embodiment of the present application, the log module is a module for storing the running state information of abnormal applications. Different applications have their own identity codes, and the corresponding application codes are also present in the running state information, so that the application that generates the running state information can be determined by querying the running state information. Different storage areas are pre-divided for different applications in the log module, and the corresponding storage area in the log module can be queried by the identity code of the application. After the monitoring module determines that there is an abnormal application, the running state information corresponding to the abnormal application is sent to the log module, and the log module determines the corresponding storage area by querying the identity code included in the running state information, and stores the running state information corresponding to the abnormal application in the storage area. After the main real-time core completes the reset, the main real-time core sends a reset success signal to the log module. When the log module receives the reset success signal, it is determined that the main real-time core is reset successfully, and the running state information corresponding to the abnormal application is reported from the storage area to the main real-time core, and the main real-time core checks the received running state information for storage. Among them, the identity code is a code that uniquely identifies the application, and the storage area is an area in the log module that stores the running state information of the abnormal application. Of course, it is also possible not to divide the storage area in the log module, and directly store the running status information corresponding to the abnormal application program in the log module.
[0074] Among them, steps S110-S120, steps S210-S240, steps S310-S320 and steps S410-S420 can be as follows: Fig. 9As shown. This solution includes a power module and a hardware domain. The hardware domain includes a main real-time core and an independent real-time core. Multiple applications are running in the main real-time core. A monitoring module, a dog feeding module and a log module are set in the independent real-time core. The power module provides power for the operation of the main real-time core and the independent real-time core. The independent real-time core obtains the running status information of multiple applications sent by the main real-time core through the monitoring module, and verifies the running status information. If the verification determines that there is an abnormal application among the multiple applications, a fault notification is sent to the dog feeding module, and the running status information of the abnormal application is stored in the log module. When the dog feeding module receives the fault notification, it stops sending the dog feeding signal to the power module. When the power module determines that the dog feeding signal is not received, it sends a reset signal to the main real-time core. When the main real-time core receives the reset signal, it resets multiple applications. When the reset is successful, the log module sends the running status information corresponding to the abnormal application to the main real-time core for storage.
[0075] A program monitoring method provided in an embodiment of the present application is applied to a monitoring module. The monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain, and the monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, multiple applications are monitored by the monitoring module in the main real-time core. This solution avoids the risk of the monitoring module also failing when an application fails.
[0076] See also Fig.10 , an embodiment of the present application provides a program monitoring method, which is applied to a power module, wherein the power module is a module deployed outside a hardware domain, and the method includes:
[0077] Step S510: Send a reset signal to the main real-time core so that the main real-time core performs a reset operation in response to the reset signal. The reset signal is a signal generated when the monitoring module in the independent real-time core obtains the running status information of each of the multiple applications running in the main real-time core, and after determining that there is an abnormal application among the multiple applications based on the running status information of each of the multiple applications, sends a fault notification to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power module. The independent real-time core and the main real-time core are both deployed in the hardware domain.
[0078] This solution sets the watchdog module in the power module, that is, the power module is used as a reset source, which is independent of the hardware domain. There is no large-scale integrated circuit in the power module, the logic is simple, and the anti-electromagnetic interference ability is strong. Therefore, generally, as long as it is determined that the dog feeding signal sent by the dog feeding module in the independent real-time core is not received, a reset signal can be generated, which is more reliable.
[0079] As a method, in addition to sending a reset signal to the main real-time core, the power module is also responsible for providing power to the main real-time core and the independent real-time core, and the power supply is maintained regardless of whether there are abnormal applications among the multiple applications included in the main real-time core.
[0080] A program monitoring method provided in an embodiment of the present application is applied to a power module. The power module is a module deployed outside a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain. The monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of a monitoring module failure when an application fails.
[0081] See also Fig.11 , an embodiment of the present application provides a program monitoring method, which is applied to a power module, wherein the power module is a module deployed outside a hardware domain, and the method includes:
[0082] Step S610: Sending a reset signal to the main real-time core through the dog feeding module, so that the main real-time core performs a reset operation on the multiple application programs in response to the reset signal.
[0083] In an embodiment of the present application, a watchdog module is deployed in the power module. When the monitoring module in the independent real-time core detects that there is an abnormal application in multiple applications in the main real-time core, the monitoring module sends a fault notification to the dog feeding module, and when the dog feeding module receives the dog feeding notification, it stops sending the dog feeding signal to the watchdog module in the power module, and when the watchdog module determines that the dog feeding signal is not received, it sends a reset signal to the main real-time core, and when the main real-time core receives the reset signal, it performs a reset operation on the multiple applications in response to the reset signal.
[0084] A program monitoring method provided in an embodiment of the present application is applied to a power module. The power module is a module deployed outside a hardware domain. A main real-time core and an independent real-time core are set in the hardware domain. The monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of a monitoring module failure when an application fails.
[0085] See also Fig.12 The embodiment of the present application provides a program monitoring method, which is applied to a main real-time core, and the main real-time core is deployed in a hardware domain. The method includes:
[0086] Step S710: Sending the running status information of each of the multiple application programs to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in the hardware domain.
[0087] In the embodiment of the present application, multiple applications are running in the main real-time core, and each application periodically sends its own running status information to the monitoring module for verification.
[0088] Step S720: Perform a reset operation in response to the received reset signal, wherein the reset signal is a signal sent by the power module to the main real-time core when the monitoring module determines that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications, and sends a fault notification to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power module.
[0089] In an embodiment of the present application, after receiving a reset signal sent by a power module, a reset operation is performed on multiple application programs.
[0090] As a method, in addition to running multiple applications, the main real-time core also runs the main real-time core operating system and memory, etc., which are not specifically limited here. In addition to sending the running status information of each of the multiple applications to the monitoring module in the independent real-time core, the main real-time core also sends the running status information of the main real-time core operating system and the running status information of the memory to the monitoring module. The monitoring module will also determine whether there are abnormalities in the main real-time core operating system and the memory based on the running status information of the main real-time core operating system and the running status information of the memory. If there is an abnormality in the main real-time core operating system or the memory, a fault notification is sent to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power module, and then the power module sends a reset signal to the main real-time core. When the main real-time core receives the reset signal, the main real-time core operating system or memory with the abnormality is reset.
[0091] A program monitoring method provided in an embodiment of the present application is applied to a main real-time core. The main real-time core is deployed in a hardware domain. The main real-time core and an independent real-time core are set in the hardware domain. A monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of a monitoring module failure when an application fails.
[0092] See also Fig.13 The embodiment of the present application provides a program monitoring method, which is applied to a main real-time core, and the main real-time core is deployed in a hardware domain. The method includes:
[0093] Step S810: Sending the running status information of each of the multiple application programs to a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in the hardware domain.
[0094] For details of step S810, reference may be made to the detailed description in the above embodiment, so it will not be described in detail in this embodiment.
[0095] Step S820: receiving a reset signal sent by the watchdog module in the power module.
[0096] In an embodiment of the present application, when the monitoring module in the independent real-time core determines that there is an abnormal application among the multiple applications in the main real-time core, it sends a fault notification to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the watchdog module in the power supply module. When the watchdog module determines that the dog feeding signal is not received, the watchdog module sends a reset signal to the main real-time core, and the main real-time core receives the reset signal sent by the watchdog module.
[0097] Step S830: Responding to the reset signal, resetting the multiple application programs.
[0098] Step S840: If the multiple applications are reset successfully, receive the running status information of the abnormal application sent by the log module, and the log module is deployed in an independent real-time core.
[0099] In an embodiment of the present application, when multiple applications are reset successfully, a reset success signal is sent to the log module in the independent real-time core. When the log module receives the reset success signal, the main real-time core receives the running status information of the abnormal application sent by the log module.
[0100] Step S850: Store the running status information in a status storage area.
[0101] In the embodiment of the present application, the status storage area is an area in the main real-time core that stores the running status information of abnormal applications.
[0102] Different storage areas are pre-divided for different applications in the status storage area. When the main real-time core receives the running status information of the abnormal application sent by the log module, the main real-time core determines the corresponding storage area by querying the identity code included in the running status information, and stores the running status information in the determined storage area.
[0103] As a way, in order to locate the cause of the abnormal application, the engineer needs to analyze the running status information of the abnormal application. The engineer searches for the corresponding storage area in the status storage area according to the abnormal application that he wants to analyze, and exports the running status information corresponding to the abnormal application that he wants to query from the storage area.
[0104] As a method, the state storage area may not be divided into different storage areas according to the type of application. Since each running state information has a corresponding application identity code, when an engineer needs to use the running state information of an abnormal application for analysis, he can directly retrieve the abnormal application to be analyzed in the state storage area by the identity code.
[0105] A program monitoring method provided in an embodiment of the present application is applied to a main real-time core. The main real-time core is deployed in a hardware domain. The main real-time core and an independent real-time core are set in the hardware domain. A monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of a monitoring module failure when an application fails.
[0106] See also Fig.14 The embodiment of the present application provides a program monitoring method, which is applied to a program monitoring system, wherein the program monitoring system includes a main real-time core, a power module, and an independent real-time core, wherein the independent real-time core includes a monitoring module and a dog feeding module; the method includes:
[0107] Step S910: the main real-time core sends the running status information of the multiple applications to the monitoring module, the monitoring module is deployed in the independent real-time core, and the independent real-time core and the main real-time core are both deployed in the hardware domain.
[0108] Step S920: The monitoring module sends a fault notification to the dog feeding module if it is determined that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications.
[0109] Step S930: the power module sends a reset signal to the main real-time core based on the dog feeding signal, where the reset signal is a signal sent by the power module when the dog feeding module stops sending the dog feeding signal to the power module based on the fault notification.
[0110] Step S940: the main real-time core performs a reset operation in response to the reset signal.
[0111] A program monitoring method provided by an embodiment of the present application installs a monitoring module in an independent real-time core, and the monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain in which only one main real-time core is set up, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of the monitoring module also failing when the application fails.
[0112] See also Fig.15 The embodiment of the present application provides a program monitoring device 900, which runs in a monitoring module, wherein the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The device 900 includes:
[0113] The information acquisition unit 910 is used to obtain the operation status information of each of the multiple applications running in the main real-time core, and the main real-time core is deployed in the hardware domain.
[0114] The notification sending unit 920 is used to send a fault notification to the dog feeding module based on the running status information of each of the multiple applications. If it is determined that there is an abnormal application among the multiple applications, the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core.
[0115] As a method, the notification sending unit 920 is also used to obtain abnormal operating status information from the operating status information of each of the multiple applications; if the abnormal operating status information is continuously obtained within a preset time period, it is determined that the application corresponding to the abnormal operating status information is an abnormal application; a fault notification is sent to the dog feeding module, and the fault notification is used to instruct the dog feeding module to stop sending a dog feeding signal to the dog feeding module, so that the dog feeding module sends a reset signal to the main real-time core.
[0116] Optionally, the notification sending unit 920 is further configured to verify the integrity of the respective running status information of the multiple applications; and to use the running status information of the respective running status information of the multiple applications that fails to be verified as the abnormal running status information.
[0117] Optionally, the notification sending unit 920 is also used to send a normal notification to the dog feeding module based on the respective running status information of the multiple applications. If it is determined that the multiple applications are all normal applications, the fault notification is used to instruct the dog feeding module to send a dog feeding signal to the power module.
[0118] Optionally, the notification sending unit 920 is also used to store the running status information of the abnormal application in the log module based on the running status information of each of the multiple applications. If it is determined that there is an abnormal application among the multiple applications, the log module stores the running status information of the abnormal application in the main real-time core after the main real-time core is reset successfully.
[0119] See also Fig.16 The embodiment of the present application provides a program monitoring device 1000, which runs on a power module, and the power module is a module deployed outside the hardware domain. The device 1000 includes:
[0120] The signal sending module 1010 is used to send a reset signal to the main real-time core so that the main real-time core performs a reset operation in response to the reset signal. The reset signal is a signal generated when the monitoring module in the independent real-time core obtains the running status information of each of the multiple applications running in the main real-time core, and after determining that there is an abnormal application among the multiple applications based on the running status information of each of the multiple applications, sends a fault notification to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power supply module. The independent real-time core and the main real-time core are both deployed in the hardware domain.
[0121] As a method, the signal sending module 1010 is also used to send a reset signal to the main real-time core through the dog feeding module, so that the main real-time core performs a reset operation on the multiple application programs in response to the reset signal.
[0122] See also Fig.17 The embodiment of the present application provides a program monitoring device 1100, which runs on a main real-time core, and the main real-time core is deployed in a hardware domain. The device 1100 includes:
[0123] The information sending module 1110 is used to send the running status information of each of the multiple application programs to the monitoring module, where the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in the hardware domain.
[0124] The reset module 1120 is used to perform a reset operation in response to a received reset signal, wherein the reset signal is a signal sent by the power module to the main real-time core when the monitoring module determines that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications, and sends a fault notification to the dog feeding module, so that the dog feeding module stops sending the dog feeding signal to the power module.
[0125] As a method, the reset module 1120 is also used to receive a reset signal sent by the watchdog module in the power module; in response to the reset signal, the multiple application programs are reset.
[0126] Optionally, the reset module 1120 is also used to receive the running status information of the abnormal application sent by the log module if the multiple applications are reset successfully, and the log module is deployed in an independent real-time core; and store the running status information in a status storage area.
[0127] See also Fig.18 The embodiment of the present application provides a program monitoring system 100, the system 100 includes a main real-time core 121, a power module 110 and an independent real-time core 122, the independent real-time core 122 includes a monitoring module 1222 and a dog feeding module 1221.
[0128] The main real-time core 121 is used to send the running status information of each of the multiple application programs to the monitoring module 1222. The monitoring module is deployed in an independent real-time core. Both the independent real-time core and the main real-time core are deployed in the hardware domain.
[0129] The monitoring module 1222 is configured to send a fault notification to the dog feeding module if it is determined that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications.
[0130] The power supply module 110 is used to send a reset signal to the main real-time core based on the dog feeding signal, and the reset signal is a signal sent by the power supply module when the dog feeding module stops sending the dog feeding signal to the power supply module based on the fault notification.
[0131] The main real-time core 121 is further configured to perform a reset operation in response to the reset signal.
[0132] It should be noted that the device embodiment in the present application corresponds to the aforementioned method embodiment. The specific principles in the device embodiment can be found in the contents of the aforementioned method embodiment and will not be repeated here.
[0133] The following will be combined Fig.19 A vehicle provided in the present application is described.
[0134] See also Fig.19Based on the above data processing method and device, the embodiment of the present application also provides another vehicle 1200 that can execute the above data processing method. The vehicle 1200 includes one or more (only one is shown in the figure) processors 1202, a memory 1204 and a network module 1206 that are coupled to each other. Among them, the memory 1204 stores a program that can execute the content of the above embodiment, and the processor 1202 can execute the program stored in the memory 1204.
[0135] The processor 1202 may include one or more processing cores. The processor 1202 uses various interfaces and lines to connect various parts of the entire vehicle 1200, and executes various functions and processes data of the server 1200 by running or executing instructions, programs, code sets or instruction sets stored in the memory 1204, and calling data stored in the memory 1204. Optionally, the processor 1202 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 1202 can integrate one or a combination of a central processing unit (CPU), a graphics processor (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It is understandable that the above-mentioned modem may not be integrated into the processor 1202, but may be implemented separately through a communication chip.
[0136] The memory 1204 may include a random access memory (RAM) or a read-only memory (ROM). The memory 1204 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 1204 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data (such as a phone book, audio and video data, chat record data) created by the electronic device 1200 during use.
[0137] The network module 1206 is used to receive and send electromagnetic waves, realize the mutual conversion between electromagnetic waves and electrical signals, so as to communicate with a communication network or other devices, such as communicating with an audio playback device. The network module 1206 may include various existing circuit elements for performing these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, user identity modules (SIM) cards, memories, etc. The network module 1206 may communicate with various networks such as the Internet, corporate intranets, wireless networks, or communicate with other devices via wireless networks. The above-mentioned wireless networks may include cellular telephone networks, wireless local area networks, or metropolitan area networks. For example, the network module 1206 may exchange information with a base station.
[0138] Please refer to Fig. 20 , which shows a structural block diagram of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable storage medium 1300 stores program codes, which can be called by a processor to execute the method described in the above method embodiment.
[0139] Computer readable storage medium 1300 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, hard disk or ROM. Optionally, computer readable storage medium 1300 includes non-volatile computer readable medium (non-transitory computer-readable storage medium). Computer readable storage medium 1300 has storage space for program code 1310 that performs any method steps in the above method. These program codes can be read from one or more computer program products or written into one or more computer program products. Program code 1310 can be compressed, for example, in an appropriate form.
[0140] The embodiments of the present application provide a program monitoring method, device, vehicle and storage medium. The method includes: obtaining the running status information of each of the multiple applications running in the main real-time core, and the main real-time core is deployed in the hardware domain; based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, a fault notification is sent to the dog feeding module, and the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core. A main real-time core and an independent real-time core are set in the hardware domain, and a monitoring module is installed in the independent real-time core. The monitoring module monitors multiple applications in the main real-time core. Compared with the existing hardware domain where only one main real-time core is set, the monitoring module in the main real-time core monitors multiple applications. This solution avoids the risk of the monitoring module also failing when an application fails.
[0141] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation modes, which are merely illustrative rather than restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are within the protection of the present invention.
Claims
1. A program monitoring method, characterized in that: Applied to a monitoring module, the monitoring module is deployed in an independent real-time core, and the independent real-time core is deployed in a hardware domain. The method includes: Acquire running status information of each of a plurality of application programs running in a main real-time core, wherein the main real-time core is deployed in the hardware domain; Based on the respective running status information of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, a fault notification is sent to the dog feeding module, and the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core.
2. The method according to claim 1, characterized in that The power supply module includes a watchdog module; the sending of a fault notification to the watchdog module if it is determined that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications, comprises: Acquire abnormal operation status information from the operation status information of each of the plurality of applications; If the abnormal operation status information is continuously obtained within a preset time period, determining that the application corresponding to the abnormal operation status information is an abnormal application; Send a fault notification to the dog feeding module.
3. The method according to claim 2, characterized in that The acquiring abnormal operation status information from the operation status information of each of the plurality of application programs comprises: Verifying the integrity of the running status information of each of the plurality of applications; The operation status information of each of the plurality of application programs that fails to be verified is used as the abnormal operation status information.
4. The method according to claim 1, characterized in that: The method further comprises: Based on the respective running status information of the multiple applications, if it is determined that the multiple applications are all normal applications, a normal notification is sent to the dog feeding module, and the fault notification is used to instruct the dog feeding module to send a dog feeding signal to the power module.
5. The method according to claim 1, characterized in that The method further comprises: Based on the respective running status information of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, the running status information of the abnormal application is stored in the log module, so that the log module stores the running status information in the main real-time core after the main real-time core is reset successfully.
6. A program monitoring method, characterized in that: Applied to a program monitoring system, the program monitoring system includes a main real-time core, a power module and an independent real-time core, the independent real-time core includes a monitoring module and a dog feeding module; the method includes: The main real-time core sends the running status information of the multiple application programs to the monitoring module, the monitoring module is deployed in the independent real-time core, and the independent real-time core and the main real-time core are both deployed in the hardware domain; The monitoring module sends a fault notification to the dog feeding module if it is determined that there is an abnormal application among the multiple applications based on the respective running status information of the multiple applications; The power module sends a reset signal to the main real-time core, where the reset signal is a signal sent by the power module when the dog feeding module stops sending the dog feeding signal to the power module based on the fault notification; The main real-time core performs a reset operation in response to the reset signal.
7. A program monitoring device, characterized in that: Running in a monitoring module, the monitoring module is deployed in an independent real-time core, the independent real-time core is deployed in a hardware domain, and the device includes: an information acquisition unit, configured to acquire operation status information of each of a plurality of application programs running in a main real-time core, wherein the main real-time core is deployed in the hardware domain; A notification sending unit is used to send a fault notification to the dog feeding module based on the running status information of each of the multiple applications, if it is determined that there is an abnormal application among the multiple applications, wherein the fault notification is used to instruct the dog feeding module to stop sending the dog feeding signal to the power module, so that the power module sends a reset signal to the main real-time core.
8. A program monitoring system, characterized in that: The program monitoring system includes a main real-time core, a power module and an independent real-time core, wherein the independent real-time core includes a monitoring module and a dog feeding module; The main real-time core is used to send the running status information of the multiple application programs to the monitoring module, the monitoring module is deployed in the independent real-time core, and the independent real-time core and the main real-time core are both deployed in the hardware domain; The monitoring module is configured to send a fault notification to the dog feeding module if it is determined that there is an abnormal application program among the multiple applications based on the respective running status information of the multiple applications; The power supply module is used to send a reset signal to the main real-time core based on the dog feeding signal, wherein the reset signal is a signal sent by the power supply module when the dog feeding module stops sending the dog feeding signal to the power supply module based on the fault notification; The main real-time core is further configured to perform a reset operation in response to the reset signal.
9. A vehicle, characterized in that: The method comprises a power supply, a hardware domain, one or more processors and a memory, wherein the hardware domain comprises a main real-time core and an independent real-time core, and one or more programs are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 10.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program codes, wherein the program codes include instructions for executing the method according to any one of claims 1 to 10.