Application function monitoring method, device and equipment and vehicle

Abstract

The embodiment of the invention discloses an application function monitoring method, device and equipment and a vehicle, and relates to the technical field of vehicle monitoring. According to the embodiment of the invention, at least one circulation relation external graph corresponding to a target application function is obtained in response to a function monitoring request, and circulation of the target application function between check points of physical cores is monitored based on an initial check point and a circulation relation under the condition that the initial check point of the target application function arrives. And obtaining a first arrival timestamp of the target check point, and based on a relationship between the first arrival timestamp and a second arrival timestamp, outputting first abnormality prompt information, the second arrival timestamp being an arrival timestamp of a previous check point of the target check point. According to the method, the target application function is deployed on the plurality of physical cores and is circulated on the plurality of physical cores without depending on Autosar regulations, and cross-core monitoring of the target application function is realized under the condition of ensuring the running performance of the vehicle.

Description

Technical Field

[0001] This application relates to the technical field of vehicle monitoring, and in particular, to a monitoring method, device, equipment, and vehicle for application functions. Background Art

[0002] With the development of technology, there are more and more application functions on vehicles to meet different usage needs of users.

[0003] During the development of application functions, in order to monitor the correctness of application functions, it is necessary to monitor the running time of application functions. For example, it is necessary to monitor the running time interval between two corresponding threads of the application function. To monitor this time interval, currently, checkpoints are set at the corresponding monitoring positions, and by recording the time when the program runs to the corresponding checkpoints, the running time interval between two threads is calculated, and then the correctness of the application function is judged.

[0004] According to the Automotive Open System Architecture (Autosar) regulations, these checkpoints can only belong to the same physical core. That is, it is not allowed to form a flow relationship between checkpoints on different physical cores, that is, it is impossible to monitor the running time interval between cross-core checkpoints.

[0005] If, in order to meet the Autosar regulations, threads that could originally run independently need to be deployed on the same physical core, in this way, the running performance of the vehicle will be affected; if multiple threads are deployed on multiple physical cores, it will cause the running time interval between checkpoints deployed on multiple physical cores to be unable to be monitored, and thus the correctness of the corresponding application function cannot be detected. Summary of the Invention

[0006] The embodiments of this application provide a monitoring method, device, equipment, and vehicle for application functions, which can effectively monitor the running time interval between threads deployed on multiple physical cores without affecting the running performance of the vehicle.

[0007] In a first aspect, the embodiments of this application provide a monitoring method for application functions, including:

[0008] Receiving a function monitoring request of a vehicle, where the function monitoring request includes a function identifier of a target application function;

[0009] Responding to the function monitoring request, and obtaining at least one external graph of flow relationships corresponding to the target application function. The external graph of flow relationships includes multiple physical cores and the flow relationships between the multiple physical cores, and each physical core includes at least one checkpoint;

[0010] When the initial checkpoint of the target application function arrives, based on the initial checkpoint and the flow relationship, monitor the flow of the target application function between the checkpoints of each physical core to obtain the first arrival timestamp of the target checkpoint, where the target checkpoint is any one of the checkpoints;

[0011] When the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, a first abnormal prompt message is output, and the second arrival timestamp is the arrival timestamp of a checkpoint before the target checkpoint.

[0012] In a second aspect, an embodiment of the present application provides a monitoring device for an application function, including:

[0013] A receiving module, used for receiving a function monitoring request of a vehicle, wherein the function monitoring request includes a function identifier of a target application function;

[0014] an acquisition module, configured to acquire, in response to a function monitoring request, at least one flow relationship external graph corresponding to a target application function, the flow relationship external graph comprising a plurality of physical cores and flow relationships between the plurality of physical cores, each physical core comprising at least one checkpoint;

[0015] A monitoring module is used to monitor the flow of the target application function between the checkpoints of each physical core based on the initial checkpoint and the flow relationship when the initial checkpoint of the target application function arrives, and obtain a first arrival timestamp of the target checkpoint, where the target checkpoint is any one of the checkpoints;

[0016] The output module is used to output a first abnormal prompt message when the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint.

[0017] 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.

[0018] 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.

[0019] In a fifth aspect, an embodiment of the present application provides a vehicle, the vehicle comprising a monitoring device for an application function 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.

[0020] The embodiment of the present application receives a function monitoring request of a vehicle, the function monitoring request includes a function identifier of a target application function; in response to the function monitoring request, obtains at least one flow relationship external graph corresponding to the target application function, the flow relationship external graph includes multiple physical cores and flow relationships between multiple physical cores, and each physical core includes at least one checkpoint; when the initial checkpoint of the target application function arrives, based on the initial checkpoint and the flow relationship, monitors the flow of the target application function between the checkpoints of each physical core, and obtains the first arrival timestamp of the target checkpoint, the target checkpoint is any one of the checkpoints; when the difference between the first arrival timestamp and the second arrival timestamp exceeds the preset time cutoff range, outputs the first abnormal prompt information, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint. That is, the embodiment of the present application can deploy the target application function on multiple physical cores and circulate on multiple physical cores without relying on Autosar regulations, and realizes cross-core monitoring of the target application function while ensuring the vehicle operation performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A schematic diagram of the flow relationship between various checkpoints provided for related technologies;

[0022] Figure 2 A flowchart of a method for monitoring application functions provided in an embodiment of the present application;

[0023] Figure 3 A flowchart of another method for monitoring application functions provided in an embodiment of the present application;

[0024] Figure 4 A schematic diagram of the flow relationship between various checkpoints provided in an embodiment of the present application;

[0025] Figure 5 A schematic diagram of a correct flow sequence between various checkpoints provided in an embodiment of the present application;

[0026] Figure 6 A schematic diagram of memory allocation provided in an embodiment of the present application;

[0027] Figure 7 A structural diagram of a monitoring device for an application function provided in an embodiment of the present application;

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

[0029] 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.

[0030] 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.

[0031] 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.

[0032] When monitoring the correctness of application functions, the relevant technology configures checkpoints on the same physical core based on Autosar regulations, that is, no flow relationship is allowed between checkpoints on different physical cores.

[0033] like Figure 1 As shown, the checkpoints CP1-0, CP1-1 and CP1-2 in core 1 can only flow within core 1, and the checkpoints CP2-0, CP2-1 and CP2-2 in core 2 can only flow within core 2.

[0034] However, in actual applications, some application functions require coordination among multiple physical cores, that is, the threads of the application functions need to be deployed on different physical cores.

[0035] If, in order to meet the Autosar regulations, threads that could have run independently need to be deployed on the same physical core, the vehicle's operating performance will be affected; if multiple threads are deployed on multiple physical cores, it will make it impossible to monitor the running time intervals between checkpoints deployed on multiple physical cores, and thus it will be impossible to detect the correctness of the corresponding application functions.

[0036] To this end, the embodiments of the present application provide a method, device, equipment and vehicle for monitoring application functions, which can effectively monitor the running time intervals between threads deployed on multiple physical cores without affecting the running performance of the vehicle.

[0037] The method, device, equipment and vehicle for monitoring application functions provided by the embodiments of the present application will be described below through specific embodiments. The method for monitoring application functions can be applied to the Electronic Control Unit (ECU) of a vehicle.

[0038] Figure 2 It is a flowchart of a method for monitoring application functions provided by the embodiments of the present application. As Figure 2 shown, the method for monitoring application functions may include the following steps:

[0039] S210. Receive a function monitoring request of the vehicle.

[0040] The function monitoring request includes the function identifier of the target application function.

[0041] S220. In response to the function monitoring request, obtain at least one external graph of the flow relationship corresponding to the target application function.

[0042] The external graph of the flow relationship includes multiple physical cores and the flow relationship between the multiple physical cores, and each physical core includes at least one checkpoint.

[0043] S230. When the initial checkpoint of the target application function arrives, monitor the flow of the target application function between the checkpoints of each physical core based on the initial checkpoint and the flow relationship, and obtain the first arrival timestamp of the target checkpoint.

[0044] The target checkpoint is any one of the checkpoints.

[0045] S240. When the difference between the first arrival timestamp and the second arrival timestamp exceeds the preset time cutoff range, output a first exception prompt message.

[0046] The second arrival timestamp is the arrival timestamp of the checkpoint before the target checkpoint.

[0047] The embodiment of the present application receives a function monitoring request of a vehicle, the function monitoring request includes a function identifier of a target application function; in response to the function monitoring request, obtains at least one flow relationship external graph corresponding to the target application function, the flow relationship external graph includes multiple physical cores and flow relationships between multiple physical cores, and each physical core includes at least one checkpoint; when the initial checkpoint of the target application function arrives, based on the initial checkpoint and the flow relationship, monitors the flow of the target application function between the checkpoints of each physical core, and obtains the first arrival timestamp of the target checkpoint, the target checkpoint is any one of the checkpoints; when the difference between the first arrival timestamp and the second arrival timestamp exceeds the preset time cutoff range, outputs the first abnormal prompt information, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint. That is, the embodiment of the present application can deploy the target application function on multiple physical cores and circulate on multiple physical cores without relying on Autosar regulations, and realizes cross-core monitoring of the target application function while ensuring the vehicle operation performance.

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

[0049] In S210, the function monitoring request is used to request the ECU to monitor whether the target application function is running correctly. For example, the user can send the function monitoring request to the ECU of the vehicle through a control on the vehicle, or through an external device such as a mobile phone, a tablet, etc.

[0050] Taking sending a function monitoring request to the ECU of the vehicle through a control on the vehicle as an example, illustratively, the function monitoring request can be sent to the ECU by triggering a door opening control on the vehicle.

[0051] Taking sending a function monitoring request to the ECU of a vehicle through an external device as an example, illustratively, a user can trigger an application function related to the vehicle on the external device to send a function monitoring request to the ECU. Of course, the function monitoring request can also be received in other ways, which are not specifically limited in the embodiments of the present application.

[0052] The target application function is the application function to be monitored on the vehicle, such as the door opening function, the light turning on function, etc. The function identifier is used to uniquely identify the target application function. After the ECU receives the function monitoring request, it can obtain the target application function to be monitored by parsing the function monitoring request.

[0053] In S220, the flow relationship external graph is an external graph corresponding to the target application function. Based on the flow relationship external graph, whether the flow of the application program corresponding to the target application function is correct can be monitored to achieve monitoring of the target application function.

[0054] One target application function may correspond to one or more external graphs of flow relationships. The external graphs of flow relationships corresponding to each application function may be pre-constructed. For the specific construction process, please refer to the following embodiments.

[0055] After determining the target application function, the ECU may, illustratively, query a database to obtain an external graph of flow relationships corresponding to the target application function, so as to facilitate subsequent monitoring of the target application function.

[0056] Exemplarily, the external graph of the flow relationship may include multiple physical cores (also referred to as cores for short), and the flow relationship between the multiple physical cores, that is, the embodiment of the present application can monitor threads deployed on multiple physical cores, thereby realizing cross-core monitoring.

[0057] Each physical core includes at least one checkpoint, and the number and location of the checkpoints can be determined based on monitoring requirements. For example, if the running time interval between the first line of program code and the second line of program code corresponding to function 1 on core 1 needs to be monitored, the checkpoint can be set at the starting position of the first line of program code and the end position of the second line of program code. Function 1 is a sub-function of the target application function.

[0058] The flow relationship between multiple physical cores is also the flow relationship between each checkpoint on each physical core. The flow relationship between each checkpoint can be configured based on actual needs.

[0059] It should be noted that in order to promptly discover program running errors, when configuring the flow relationship of each checkpoint, it is necessary to ensure that there is only one checkpoint next to the current checkpoint, that is, it is necessary to ensure that the flow path between each checkpoint is a single path.

[0060] In S230, the initial checkpoint is the starting point of the flow between multiple physical cores. There are many ways to determine the initial checkpoint. For example, in some embodiments, the previous checkpoint and the next checkpoint connected to each checkpoint can be obtained based on the external graph of the flow relationship. When the number of previous checkpoints of a checkpoint is 0, the checkpoint can be used as the initial checkpoint.

[0061] In some embodiments, a checkpoint may be selected as an initial checkpoint based on user needs.

[0062] When the initial checkpoint is reached, the ECU can monitor the flow of each thread of the target application function between the checkpoints of each physical core based on the initial checkpoint and the flow relationship. For example, if the initial checkpoint is not reached and other checkpoints have been reached, it can be determined that the flow is wrong, that is, the target application function is running abnormally.

[0063] In actual application, each physical core is configured with a watchdog manager (WDGM), and the ECU can control the WDGM of each physical core to monitor its own circulation.

[0064] The target checkpoint is the checkpoint reached by the program, and the first arrival timestamp is the timestamp when the program runs to the target checkpoint. In actual application, every time the program runs to a checkpoint, the timestamp of reaching the checkpoint needs to be recorded to facilitate the subsequent judgment of whether the time interval between the two checkpoints meets the preset time deadline, thereby realizing the monitoring of the deadline between the two checkpoints.

[0065] In S240, the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint, and based on the arrival timestamps of the two checkpoints, it can be determined whether the running time interval of the program between the two checkpoints is within the preset time deadline. For example, in an embodiment of the present application, based on the first arrival timestamp and the second arrival timestamp, it can be determined whether the running time interval of the program between the previous checkpoint and the target checkpoint is within the preset time deadline, thereby realizing the monitoring of the deadline between the previous checkpoint and the target checkpoint.

[0066] Exemplarily, when the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, a first abnormality prompt message is output. The first abnormality prompt message is used to prompt that the program has an abnormal running time between the previous checkpoint and the target checkpoint. The first abnormality prompt message can be output in the form of text, voice, etc.

[0067] For example, when a runtime anomaly is detected, the ECU may be controlled to restart, or the target application function may be controlled to restart, or the anomaly may be recorded and the target checkpoint may be controlled to continue to flow to the next checkpoint. The specific execution strategy may be set based on the scenario and requirements.

[0068] In some embodiments, Figure 3 As shown, the monitoring method of the application function may include the following steps:

[0069] S310: Receive a vehicle function monitoring request.

[0070] S320. In response to the function monitoring request, obtain at least one flow relationship external graph corresponding to the target application function.

[0071] S330. When reaching the first checkpoint, determine whether the first checkpoint is the target checkpoint of the previous checkpoint based on the flow relationship.

[0072] The first checkpoint is any checkpoint after the initial checkpoint.

[0073] S340: When it is determined that the first checkpoint is the target checkpoint of the previous checkpoint, record a first arrival timestamp of the target checkpoint.

[0074] S350: When it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint, output second abnormal prompt information.

[0075] S360: When the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, output a first abnormal prompt message.

[0076] The processes of S310 - S320 and S360 may refer to the above embodiments, and will not be described again here for the sake of brevity.

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

[0078] In S330, the first checkpoint is any checkpoint after the initial checkpoint, that is, each time the program runs to a checkpoint, it is necessary to first determine whether the checkpoint is the target checkpoint of the previous checkpoint, that is, to determine whether the flow logic of the program is accurate.

[0079] by Figure 4 Taking the external flow relationship diagram shown as an example, the program in core 0 needs to run in the order of CP0-0, CP0-1, CP0-2, CP1-0, CP1-1 and CP1-2, and the program in core 1 needs to run in the order of CP2-0, CP2-1, CP2-2. After the program runs to CP1-2, the next checkpoint is CP2-1. CP0-0 to CP0-2, CP1-0 to CP1-2, and CP2-0 to CP2-2 are all checkpoints. There is a deadline limit between every two checkpoints. Among them, when checkpoint CP1-2 arrives, core 0 no longer monitors whether the next checkpoint of checkpoint CP1-2 arrives at the specified time, because the next checkpoint CP2-1 is in core 1. At this time, only core 1 needs to determine whether the running time of checkpoint CP2-1 is correct.

[0080] For example, when the program runs to checkpoint CP1-0, it is necessary to determine whether checkpoint CP1-0 is the next checkpoint of the previous checkpoint CP0-2, that is, the target checkpoint. If checkpoint CP1-0 is the next checkpoint of checkpoint CP0-2, it means the flow is correct, otherwise, the flow is wrong.

[0081] The correct flow timing can be found in Figure 5When the program runs to checkpoint CP0-0, it marks the start of the multi-core deadline flow. Next, the program is only allowed to run to checkpoint CP0-1. Only when it reaches CP0-1 within the specified time and no other checkpoint arrives first, the program is allowed to continue running to the next checkpoint, for example, it is allowed to run to checkpoint CP0-2. The judgment process of other timings is similar.

[0082] Exemplarily, whether the first checkpoint is the target checkpoint of the previous checkpoint may be determined in the following manner:

[0083] Search the checkpoint memory to determine the transfer target address of the previous checkpoint. The checkpoint memory is used to store the transfer information of each checkpoint. The transfer information includes the transfer target address of the checkpoint.

[0084] In the case where the transfer target address of the previous checkpoint is the same as the address of the first checkpoint, determining that the first checkpoint is the target checkpoint of the previous checkpoint;

[0085] In the case where the transfer target address of the previous checkpoint is different from the address of the first checkpoint, it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint.

[0086] The checkpoint memory is used to store the flow information of each checkpoint, which may include the flow target address, flow source address, and whether it is the flow end point of the checkpoint. For example, for checkpoint CP0-2, the flow source address of CP0-2, that is, the number of the previous checkpoint, and the flow target address of CP0-2, that is, the number of the next checkpoint, may be stored.

[0087] By searching the checkpoint memory, it can be further determined whether the next checkpoint of checkpoint CP0-2 is CP1-0. For example, if the transfer target address of checkpoint CP0-2 recorded in the checkpoint memory is checkpoint CP1-0, it can be determined that the transfer is correct. If the transfer target address of checkpoint CP0-2 recorded in the checkpoint memory is not checkpoint CP1-0, it can be determined that the transfer is abnormal.

[0088] The embodiment of the present application first determines whether the flow is normal before determining whether the deadline between two checkpoints is normal, which can improve the accuracy of the deadline monitoring result.

[0089] In S340, when it is determined that the current flow is normal, that is, the first checkpoint is the target checkpoint of the previous checkpoint, the arrival timestamp of the target checkpoint, that is, the first arrival timestamp, is recorded. Exemplarily, the arrival timestamp of the target checkpoint can be stored in the memory corresponding to the checkpoint, that is, the checkpoint memory.

[0090] It should be noted that the timestamps between multiple cores are synchronized. There are many ways to achieve synchronization, such as using a timer, or periodically synchronizing the clocks of each core.

[0091] In S350, when it is determined that the current flow is abnormal, that is, the first checkpoint is not the target checkpoint of the previous checkpoint, second abnormal prompt information can be output, and the second abnormal prompt information is used to prompt the flow error.

[0092] When a flow error is determined, for example, the ECU can be controlled to restart, or the target application function can be controlled to restart, or the exception can be recorded, and the target checkpoint can be controlled to continue to flow to the next checkpoint. The specific execution strategy can be set based on the scenario and requirements.

[0093] When determining the arrival timestamp of the target checkpoint, the embodiment of the present application first determines whether the arrived checkpoint is the checkpoint that the current core should run to. If so, it further determines whether the running time is within the time allowed. If not, it outputs an abnormal prompt message, thereby improving the accuracy of the monitoring results when cross-core monitoring is implemented.

[0094] In some embodiments, before S210, the flow relationship external graph may be constructed in the following manner:

[0095] S200, determining function information of a target application function;

[0096] S201, based on the function information, determining multiple physical cores corresponding to the target application function, monitored entities corresponding to each physical core, and checkpoints corresponding to each monitored entity;

[0097] S202, configuring the flow information of each checkpoint, and storing the flow information in the checkpoint memory; wherein each checkpoint has a one-to-one relationship with the next checkpoint;

[0098] S203. Construct an external graph of flow relationships based on the flow information of each checkpoint.

[0099] Specifically, in S200, the function information may be information that can characterize the functional characteristics of the target application. For example, the function information may include information of at least one application sub-function included in the target application function and priority information of each application sub-function.

[0100] Different application functions correspond to different functional information. For example, when turning on headlight A, the functional information includes the headlight status, battery status and other functional information. These functional information can be executed by different physical cores. Therefore, multiple physical cores can be determined based on the functional information, and the monitored entity (Supervised Entity, SE) corresponding to each physical core and the checkpoint corresponding to each monitored entity SE can be determined.

[0101] Among them, SE is a software entity included in the monitoring of the watchdog manager, and each SE has only one identifier. SE represents a set of checkpoints in a software component or a basic software module. In an embodiment of the present application, a physical core may include one or more SEs, and each SE is managed by a watchdog manager deployed on its own core. An SE may include one or more checkpoints.

[0102] The number of checkpoints and SEs contained in each physical core and the correspondence between SEs and checkpoints can be set based on actual needs. For ease of management, the checkpoints on the same physical core can be divided and managed by different SEs.

[0103] like Figure 4 As shown, core 0 includes two SEs, namely SE0 and SE1, and core 1 includes one SE, namely SE2. SE0 manages checkpoints CP0-0, CP0-1, and CP0-2, SE1 manages checkpoints CP1-0, CP1-1, and CP1-2, and SE2 manages CP2-0, CP2-1, and CP2-2. Among them, the checkpoints on the same SE can only be located in the same physical core.

[0104] After the physical core, checkpoint and SE are determined, the flow information of each checkpoint can be configured according to the needs, that is, the flow source address, flow target address and whether it is the flow end point of each checkpoint can be configured, and the flow information can be stored in the checkpoint memory.

[0105] Among them, when configuring the flow information of each checkpoint, it is necessary to ensure that each checkpoint has a one-to-one relationship with the next checkpoint, that is, when the program runs to the current checkpoint, there can only be one checkpoint next to the current checkpoint, so as to ensure that the path between the current checkpoint and the next checkpoint is unique. Therefore, when the program runs abnormally between the current checkpoint and the next checkpoint, the abnormality can be discovered in time.

[0106] Based on the flow information of each checkpoint, an external graph of flow relationships can be constructed.

[0107] Exemplarily, in addition to storing the flow information of each checkpoint, the information of each SE on each physical core can also be stored, where the SE information may include but is not limited to the ID of the last checkpoint reached, the timestamp of the last checkpoint reached, the ID of the initial checkpoint of this SE, and the checkpoint memory managed by this SE. By occupying a small amount of memory to store the information of each SE and each checkpoint, it is helpful to monitor the flow of the target application function and whether the running time is abnormal, thereby improving the monitoring efficiency. At the same time, it can also prevent each core from needing to poll the status of the checkpoints on all cores during multi-core processing. The allocation of each memory can be seen in Figure 6 . Figure 6 SE0 and the checkpoint memory managed by SE0 are used as an example for explanation. The storage of other SEs and corresponding checkpoints is similar.

[0108] For example, each time the program runs to a checkpoint, the watchdog manager will record the ID and arrival timestamp of the checkpoint reached by the current SE in the SE memory where the checkpoint is located. When the program runs to the next checkpoint, the current SE knows the checkpoint reached last time and the checkpoint that should be reached next time, so it can further determine whether the flow and running time are normal.

[0109] by Figure 4 For example, when the program of core 0 runs to checkpoint CP0-0, the corresponding watchdog manager will record the ID and arrival timestamp of the checkpoint currently reached by SE0 in the memory of SE0 where checkpoint CP0-0 is located. When the program runs to checkpoint CP0-1, SE0 knows that the last checkpoint reached is CP0-0, and SE0 also knows that the next checkpoint of CP0-0 should be CP0-1. Therefore, when CP0-1 arrives, it meets the flow relationship of SE0, and based on the timestamp of the last arrival and the timestamp of the current arrival, it can be calculated whether the deadline time relationship is met.

[0110] The embodiment of the present application can determine the functional information of the target application function, and can further determine the monitored entities corresponding to the corresponding physical cores and the checkpoints corresponding to the monitored entities based on the functional information, and obtain the external graph of the flow relationship corresponding to the target application function by configuring the flow information of each checkpoint, so that the monitoring of the target application function can be performed in an orderly manner, thereby improving the monitoring efficiency and the accuracy of the monitoring results.

[0111] In some embodiments, the above S201 may include the following steps:

[0112] Analyze the function information to obtain at least one application sub-function included in the target application function and execution priority information of each application sub-function;

[0113] Based on the execution priority information of each application sub-function, multiple physical cores are obtained;

[0114] For each physical core, a corresponding checkpoint is configured for the physical core based on the execution information of the application sub-function on the physical core;

[0115] The checkpoints are divided based on the number of checkpoints to obtain at least one group, and a corresponding monitored entity is configured for each group.

[0116] Exemplarily, by analyzing the function information of the target application function, at least one application sub-function included in the target application function and execution priority information of each application sub-function can be obtained.

[0117] Taking the target application function of turning on the headlight A as an example, the function information is the headlight status. By analyzing the headlight status, multiple application sub-functions can be obtained, such as the headlight switch sub-function, the headlight brightness sub-function, etc. The execution priority information of each application sub-function can be set based on actual needs. For example, the priority of the headlight switch sub-function is higher than that of the headlight brightness sub-function.

[0118] Based on the execution priority information of each application sub-function, multiple physical cores can be obtained. Exemplarily, the execution priority information of each application sub-function can be matched with the processing priority information of each physical core to obtain the physical core corresponding to each application sub-function.

[0119] For example, the processing priority of physical core 1 is higher than that of physical core 2. At this time, the headlight switch sub-function can be run on physical core 1, and the headlight brightness sub-function can be run on physical core 2, thereby ensuring the operating efficiency of the target application function.

[0120] The execution information of the application sub-function may include, for example, the number of execution programs of the application sub-function and the importance of each execution program. For each physical core, a certain number of checkpoints may be configured based on the execution information of the application sub-function on the physical core.

[0121] After the checkpoints are determined, for example, the checkpoints can be divided based on the number of checkpoints to obtain different groups, and the SE corresponding to each group can be managed. For example, when the checkpoints are divided based on the number of checkpoints, the importance of the program corresponding to the checkpoint can be further considered. For example, the checkpoints corresponding to programs with the same or similar importance can be managed by the same SE. Of course, the relationship between the checkpoint and the SE can also be configured based on other requirements, which is not limited in the embodiments of the present application.

[0122] The embodiment of the present application can determine the information such as the application sub-functions contained in the target application function by analyzing the functional information of the target application function, thereby determining the corresponding physical core, and further deploying checkpoints and SE for each physical core based on the execution information of the application sub-functions, so that cross-SE and cross-core monitoring of the target application function can be achieved subsequently.

[0123] In some embodiments, the application function monitoring method may further include the following steps:

[0124] Get the global status of each physical core;

[0125] The global status of each physical core is matched with the preset monitoring conditions to obtain the monitoring results of the target application function.

[0126] The global state of the physical core may include, for example, the correct state, the error state, etc. of the physical core. There are many ways to obtain the global state of each physical core. For example, after each checkpoint is transferred, the transfer result of the checkpoint is analyzed to obtain the state information of the SE to which the checkpoint belongs. Each physical core can determine the global state of each physical core according to the state information of the SE included; for another example, each physical core determines the global state of each physical core according to the transfer results of each checkpoint included.

[0127] For example, for the same physical core, if the status information of one or more SEs included in the physical core is in an error state, it can be determined that the global state of the physical core is in an error state. For another example, for the same physical core, if the status information of more than half of the SEs included in the physical core is in an error state, it can be determined that the global state of the physical core is in an error state. Of course, other judgment methods can also be used for judgment.

[0128] The preset monitoring condition is used to determine the monitoring result of the target application function. For example, the preset monitoring condition may be that the global status of each physical core is in a correct state, and the monitoring result of the target application function is that the target application function is realized, or the target application function is normal. For another example, the preset monitoring condition may also be that the global status of at least one physical core is in a correct state, and the monitoring result of the target application function is that the target application function is realized.

[0129] By matching the global status of each physical core with the preset monitoring conditions, the monitoring results of the target application function can be obtained.

[0130] The embodiment of the present application obtains the global status of each physical core, and can determine the monitoring result of the target application function based on the global status of each physical core, thereby realizing global monitoring of the target application function.

[0131] In some embodiments, the application function monitoring method may further include the following steps:

[0132] When the difference between the first arrival timestamp and the second arrival timestamp does not exceed a preset time deadline, the target checkpoint is controlled to transfer to the next checkpoint.

[0133] Exemplarily, when the program reaches the target checkpoint within the specified time, the program can be controlled to continue to flow to the next checkpoint. Each time a checkpoint is reached, it is first determined whether the checkpoint reached is the specified checkpoint. When it is determined that the flow is normal, it is further determined whether the running time is normal. Only when the flow is normal and the running time is normal is it allowed to continue to run to the next checkpoint. Otherwise, an abnormal prompt message may be output, for example, an error may be reported to the physical core where the program is located and the subsequent physical cores associated with the physical core.

[0134] For example, when the checkpoints of core 0 have not been fully executed, the checkpoint CP2-1 of core 1 has arrived. At this time, checkpoint CP2-1 finds that the arrival and arrival timestamp of checkpoint CP1-2 are not recorded in the memory of the SE where it is located. At this time, it can be determined that an error has occurred in the current flow, and the error is reported to core 0 and core 1. Among them, the processing methods of different check errors are independent of each other, that is, the processing methods of different check errors can be the same or different.

[0135] The embodiment of the present application monitors the flow relationship and the running time at the same time, thereby improving the accuracy of the monitoring results and ensuring the safety of the vehicle application functions.

[0136] The embodiment of the present application allows a complete application function to be split into multiple cores, and corresponding SEs and checkpoints are deployed for each core. By configuring the flow relationship, cross-SE and cross-core monitoring of the application function is achieved, thereby improving the security level of the application function.

[0137] Based on the same inventive concept, the present application embodiment also provides a monitoring device for application functions. Figure 7 The monitoring device for application functions provided in the embodiment of the present application is described in detail.

[0138] like Figure 7 As shown, the monitoring device of the application function may include:

[0139] A receiving module 701 is used to receive a function monitoring request of a vehicle, where the function monitoring request includes a function identifier of a target application function;

[0140] An acquisition module 702 is configured to acquire, in response to a function monitoring request, at least one flow relationship external graph corresponding to a target application function, the flow relationship external graph including a plurality of physical cores and flow relationships between the plurality of physical cores, each physical core including at least one checkpoint;

[0141] The monitoring module 703 is used to monitor the flow of the target application function between the checkpoints of each physical core based on the initial checkpoint and the flow relationship when the initial checkpoint of the target application function arrives, and obtain a first arrival timestamp of the target checkpoint, where the target checkpoint is any one of the checkpoints;

[0142] The output module 704 is used to output a first abnormal prompt message when the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint.

[0143] The embodiment of the present application receives a function monitoring request of a vehicle, the function monitoring request includes a function identifier of a target application function; in response to the function monitoring request, obtains at least one flow relationship external graph corresponding to the target application function, the flow relationship external graph includes multiple physical cores and flow relationships between multiple physical cores, and each physical core includes at least one checkpoint; when the initial checkpoint of the target application function arrives, based on the initial checkpoint and the flow relationship, monitors the flow of the target application function between the checkpoints of each physical core, and obtains the first arrival timestamp of the target checkpoint, the target checkpoint is any one of the checkpoints; when the difference between the first arrival timestamp and the second arrival timestamp exceeds the preset time cutoff range, outputs the first abnormal prompt information, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint. That is, the embodiment of the present application can deploy the target application function on multiple physical cores and circulate on multiple physical cores without relying on Autosar regulations, and realizes cross-core monitoring of the target application function while ensuring the vehicle operation performance.

[0144] In some embodiments, the monitoring module 703 is specifically used to:

[0145] In case of reaching the first checkpoint, determining whether the first checkpoint is a target checkpoint of a previous checkpoint based on the flow relationship, the first checkpoint being any checkpoint after the initial checkpoint;

[0146] In the case where it is determined that the first checkpoint is a target checkpoint of a previous checkpoint, recording a first arrival timestamp of the target checkpoint;

[0147] When it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint, a second abnormal prompt information is output.

[0148] In some embodiments, the monitoring module 703 is specifically used to:

[0149] Search the checkpoint memory to determine the transfer target address of the previous checkpoint. The checkpoint memory is used to store the transfer information of each checkpoint. The transfer information includes the transfer target address of the checkpoint.

[0150] In the case where the transfer target address of the previous checkpoint is the same as the address of the first checkpoint, determining that the first checkpoint is the target checkpoint of the previous checkpoint;

[0151] In the case where the transfer target address of the previous checkpoint is different from the address of the first checkpoint, it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint.

[0152] In some embodiments, the monitoring device for application functions may further include: a determination module, a configuration module, and a construction module;

[0153] A determination module, used to determine the function information of the target application function;

[0154] The determination module is further used to determine, based on the function information, a plurality of physical cores corresponding to the target application function, a monitored entity corresponding to each physical core, and a checkpoint corresponding to each monitored entity;

[0155] A configuration module, used to configure the flow information of each checkpoint and store the flow information in the checkpoint memory; wherein each checkpoint has a one-to-one relationship with the next checkpoint;

[0156] The construction module is used to construct an external graph of flow relations based on the flow information of each checkpoint.

[0157] In some embodiments, the determination module is specifically configured to:

[0158] Analyze the function information to obtain at least one application sub-function included in the target application function and execution priority information of each application sub-function;

[0159] Based on the execution priority information of each application sub-function, multiple physical cores are obtained;

[0160] For each physical core, a corresponding checkpoint is configured for the physical core based on the execution information of the application sub-function on the physical core;

[0161] The checkpoints are divided based on the number of checkpoints to obtain at least one group, and a corresponding monitored entity is configured for each group.

[0162] In some embodiments, the acquisition module 702 is further used to acquire the global state of each physical core;

[0163] The monitoring device of the application function may also include:

[0164] The matching module is used to match the global status of each physical core with the preset monitoring conditions to obtain the monitoring results of the target application function.

[0165] In some embodiments, the monitoring module 703 is further configured to control the target checkpoint to transfer to the next checkpoint when the difference between the first arrival timestamp and the second arrival timestamp does not exceed a preset time deadline.

[0166] Figure 7 Each module in the device shown has the function of realizing Figure 2-Figure 6 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.

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

[0168] like Figure 8 As shown, the electronic device may include a processor 810 and a memory 820 for storing computer program instructions.

[0169] The processor 810 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.

[0170] The memory 820 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 820 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 820 may include a removable or non-removable (or fixed) medium, or the memory 820 is a non-volatile solid-state memory. In one example, the memory 820 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.

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

[0172] In one example, the electronic device may further include a communication interface 830 and a bus 840. Figure 8 As shown, the processor 810, the memory 820, and the communication interface 830 are connected via a bus 840 and communicate with each other.

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

[0174] Bus 840 includes hardware, software or both, and each component of electronic device is coupled to each other.For example, but not limitation, bus 840 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 840 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.

[0175] After receiving the vehicle function monitoring request, the electronic device can execute the monitoring method of the application function in the embodiment of the present application, thereby realizing the combination Figure 2-Figure 6 Describes the monitoring methods of application functions and Figure 7 Describe the application functionality of the monitoring device.

[0176] 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. When the program or instruction is executed by a processor, a monitoring method for the application function as described in the above embodiment is implemented.

[0177] Based on the same inventive concept, an embodiment of the present application also provides a vehicle, which includes a monitoring device for the application function 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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 monitoring application functions, It is characterized in that include: Receiving a function monitoring request of a vehicle, wherein the function monitoring request includes a function identifier of a target application function; In response to the function monitoring request, obtaining at least one flow relationship external graph corresponding to the target application function, the flow relationship external graph comprising a plurality of physical cores and flow relationships between the plurality of physical cores, each physical core comprising at least one checkpoint; When the initial checkpoint of the target application function arrives, based on the initial checkpoint and the flow relationship, monitoring the flow of the target application function between the checkpoints of each of the physical cores to obtain a first arrival timestamp of a target checkpoint, the target checkpoint being any one of the checkpoints; When the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, a first abnormal prompt message is output, and the second arrival timestamp is the arrival timestamp of a previous checkpoint of the target checkpoint.

2. The method according to claim 1, It is characterized in that The step of monitoring the flow of the target application function between the checkpoints of each of the physical cores based on the initial checkpoint and the flow relationship to obtain a first arrival timestamp of the target checkpoint includes: In case of reaching a first checkpoint, determining whether the first checkpoint is a target checkpoint of a previous checkpoint based on the flow relationship, the first checkpoint being any checkpoint after the initial checkpoint; In the case where it is determined that the first checkpoint is the target checkpoint of the previous checkpoint, recording a first arrival timestamp of the target checkpoint; When it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint, second abnormal prompt information is output.

3. The method according to claim 2, It is characterized in that The determining, based on the flow relationship, whether the first checkpoint is a target checkpoint of a previous checkpoint includes: Searching a checkpoint memory to determine a transfer target address of the previous checkpoint, wherein the checkpoint memory is used to store transfer information of each of the checkpoints, and the transfer information includes the transfer target address of the checkpoint; In the case where the transfer target address of the previous checkpoint is the same as the address of the first checkpoint, determining that the first checkpoint is the target checkpoint of the previous checkpoint; In a case where the transfer target address of the previous checkpoint is different from the address of the first checkpoint, it is determined that the first checkpoint is not the target checkpoint of the previous checkpoint.

4. The method according to claim 1, It is characterized in that Before receiving the function monitoring request of the vehicle, the method further includes: Determining functional information of the target application function; Based on the function information, determining a plurality of physical cores corresponding to the target application function, monitored entities corresponding to each of the physical cores, and checkpoints corresponding to each of the monitored entities; Configuring the flow information of each of the checkpoints, and storing the flow information in the checkpoint memory; wherein each checkpoint has a one-to-one relationship with the next checkpoint; Based on the flow information of each of the checkpoints, an external graph of flow relationships is constructed.

5. The method according to claim 4, It is characterized in that The determining, based on the function information, a plurality of physical cores corresponding to the target application function, monitored entities corresponding to each of the physical cores, and checkpoints corresponding to each of the monitored entities comprises: Analyze the function information to obtain at least one application sub-function included in the target application function and execution priority information of each of the application sub-functions; Based on the execution priority information of each application sub-function, acquiring the plurality of physical cores; For each physical core, based on the execution information of the application sub-function on the physical core, configure a corresponding checkpoint for the physical core; The checkpoints are divided based on the number of the checkpoints to obtain at least one group, and a corresponding monitored entity is configured for each group.

6. The method according to any one of claims 1 to 5, It is characterized in that The method further comprises: Obtaining the global status of each of the physical cores; The global status of each of the physical cores is matched with a preset monitoring condition to obtain a monitoring result of the target application function.

7. The method according to claim 1, It is characterized in that The method further comprises: When the difference between the first arrival timestamp and the second arrival timestamp does not exceed a preset time deadline, the target checkpoint is controlled to transfer to the next checkpoint.

8. A monitoring device for application functions, It is characterized in that include: A receiving module, configured to receive a function monitoring request of a vehicle, wherein the function monitoring request includes a function identifier of a target application function; an acquisition module, configured to acquire, in response to the function monitoring request, at least one flow relationship external graph corresponding to the target application function, the flow relationship external graph comprising a plurality of physical cores and flow relationships between the plurality of physical cores, each physical core comprising at least one checkpoint; A monitoring module, configured to monitor the flow of the target application function between the checkpoints of each of the physical cores based on the initial checkpoint and the flow relationship when the initial checkpoint of the target application function arrives, and obtain a first arrival timestamp of a target checkpoint, wherein the target checkpoint is any one of the checkpoints; The output module is used to output a first abnormal prompt message when the difference between the first arrival timestamp and the second arrival timestamp exceeds a preset time cutoff range, and the second arrival timestamp is the arrival timestamp of the previous checkpoint of the target checkpoint.

9. An electronic device, It is 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 7 is implemented.

10. A vehicle, It is characterized in that The vehicle includes a monitoring device for applying the function as claimed in claim 8; Or, the electronic device as claimed in claim 9.

Images