Task running timeout monitoring method, device and equipment, vehicle and storage medium
By constructing a high-priority monitoring interruption task, the runtime of the task in the vehicle controller is monitored in real time and key information is recorded when the timeout occurs. This solves the problem that the existing technology cannot perform task timeout monitoring without external hardware, realizes millisecond-level monitoring and persistent storage of fault information, and simplifies the diagnosis of real vehicle faults.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU AUTOMOBILE GROUP CO LTD
- Filing Date
- 2026-01-13
- Publication Date
- 2026-04-21
AI Technical Summary
Existing technologies cannot monitor the timeout of tasks in the vehicle controller without relying on external hardware, and cannot cover non-periodic tasks, locate internal problems of tasks, easily lose monitoring information, and make troubleshooting of real vehicle faults cumbersome.
Construct a high-priority target monitoring interrupt task, monitor the runtime of the monitored task in real time, record key information after timeout and store it in non-volatile storage medium, and notify external devices through the external bus.
It enables millisecond-level timeout monitoring for all types of tasks, ensures persistent storage of fault information, simplifies real-vehicle fault diagnosis, and improves the independence and efficiency of monitoring.
Smart Images
Figure CN121901014A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of task monitoring technology, and in particular to a method, apparatus, equipment, vehicle, and storage medium for monitoring task execution timeout. Background Technology
[0002] As automotive electronic and electrical architectures gradually move towards centralization, the software functions integrated in domain controllers are becoming increasingly complex, and the number of tasks is increasing significantly.
[0003] In related technologies, external debugging equipment is usually used to detect abnormalities in task operation. However, this type of method is limited by hardware connection conditions and external dependencies, and cannot be implemented in the vehicle controller, so it is urgent to solve this problem. Summary of the Invention
[0004] This application provides a method, apparatus, device, vehicle, and storage medium for monitoring task execution timeouts, in order to solve the problem that related technologies cannot monitor task execution timeouts without relying on external hardware. It enables millisecond-level timeout monitoring of all types of tasks without relying on external controllers or affecting the vehicle wiring harness.
[0005] The first aspect of this application provides a method for monitoring task execution timeout, including the following steps: Construct a target monitoring interruption task, which is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of the at least one monitored task. For any monitored task, determine the runtime of the monitored task; if the runtime of the monitored task exceeds the runtime threshold, determine the monitored task as a timeout task.
[0006] By using the above technical means, and by setting up a dedicated interrupt task with higher priority to monitor other tasks, the independent and proactive detection of the running status of the monitored task is achieved. This is unaffected by the abnormalities of the monitored task itself (such as infinite loops or blocking). It enables millisecond-level timeout monitoring of all types of tasks without the need for external devices or affecting the vehicle wiring harness.
[0007] According to one embodiment of this application, after determining that the monitored task is a timeout task, the method further includes: Obtain the task name, stack variable information, runtime, and system time of the timed-out task; The task name, stack variable information, runtime, and system time of the timed-out task are stored in a preset non-volatile storage medium. The timeout flag of the timeout task is sent to a preset external bus.
[0008] Through the above technical means, the fault scene is persistently preserved, so that developers can still obtain accurate diagnostic information after the fault disappears or the system is reset, which greatly facilitates the offline analysis and localization of occasional and non-reproducible problems.
[0009] According to one embodiment of this application, determining the runtime of any monitored task includes: Get the start time and current system time for each monitored task; The difference between the current system time and the task start time of each monitored task is calculated to obtain the runtime of each monitored task.
[0010] The above-mentioned technical means provide accurate and reliable timing judgment basis, ensure the accuracy of timeout judgment, and provide key time reference data for subsequent fault analysis.
[0011] According to one embodiment of this application, after determining the runtime of any monitored task, the method further includes: If there is no monitored task whose runtime exceeds the runtime threshold, then the step of determining the runtime of any monitored task is re-executed.
[0012] By employing the aforementioned technical means and cyclically executing the monitoring process, continuous and periodic monitoring of multiple tasks in the system is achieved, avoiding the omission of abnormal situations in a single monitoring session and enhancing the long-term monitoring capability and real-time performance of task operation status.
[0013] According to one embodiment of this application, before determining the runtime of any monitored task, the method further includes: Obtain the current task start flag of at least one monitored task, and filter out monitored tasks whose current task start flag is at a preset flag.
[0014] By employing the aforementioned technical means, and filtering currently running tasks based on task initiation flags, ineffective monitoring of unexecuted tasks is avoided, thereby improving the operational efficiency of the monitoring mechanism, reducing system resource consumption, and ensuring that monitoring objectives are clear and effective.
[0015] According to the task execution timeout monitoring method provided in the embodiments of this application, a target monitoring interruption task is constructed. This target monitoring interruption task is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of at least one monitored task. For any monitored task, the runtime of the monitored task is determined. If the runtime of the monitored task exceeds a runtime threshold, the monitored task is determined to be a timeout task. This solves the problem that related technologies cannot perform task execution timeout monitoring without relying on external hardware, and achieves millisecond-level timeout monitoring for all types of tasks without requiring external devices or affecting the vehicle wiring harness.
[0016] A second aspect of this application provides a task execution timeout monitoring device, comprising: A construction module is used to construct a target monitoring interruption task, wherein the target monitoring interruption task is used to monitor at least one monitored task, and the priority of the target monitoring interruption task is higher than the priority of the at least one monitored task. The determination module is used to determine the runtime of any monitored task; if the runtime of the monitored task exceeds a runtime threshold, the monitored task is determined to be a timeout task.
[0017] According to one embodiment of this application, after determining that the monitored task is a timeout task, the determining module is further configured to: Obtain the task name, stack variable information, runtime, and system time of the timed-out task; The task name, stack variable information, runtime, and system time of the timed-out task are stored in a preset non-volatile storage medium. The timeout flag of the timeout task is sent to a preset external bus.
[0018] According to one embodiment of this application, the determining module is configured to: Get the start time and current system time for each monitored task; The difference between the current system time and the task start time of each monitored task is calculated to obtain the runtime of each monitored task.
[0019] According to one embodiment of this application, after determining the runtime of any monitored task, the determining module is further configured to: If there is no monitored task whose runtime exceeds the runtime threshold, then the step of determining the runtime of any monitored task is re-executed.
[0020] According to one embodiment of this application, before determining the runtime of any monitored task, the determining module is further configured to: Obtain the current task start flag of at least one monitored task, and filter out monitored tasks whose current task start flag is at a preset flag.
[0021] According to the task execution timeout monitoring device provided in the embodiments of this application, a target monitoring interruption task is constructed. The target monitoring interruption task is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of at least one monitored task. For any monitored task, the runtime of the monitored task is determined. If the runtime of the monitored task exceeds the runtime threshold, the monitored task is determined to be a timeout task. This solves the problem that related technologies cannot perform task execution timeout monitoring without relying on external hardware, and achieves millisecond-level timeout monitoring of all types of tasks without the need for external devices or affecting the vehicle wiring harness.
[0022] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the task execution timeout monitoring method as described in the above embodiments.
[0023] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to execute the task timeout monitoring method described in the above embodiments.
[0024] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0025] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a task execution timeout monitoring method provided according to an embodiment of this application; Figure 2 A schematic diagram illustrating the monitoring time principle of a monitoring task according to an embodiment of this application; Figure 3 A flowchart of a task execution timeout monitoring method according to an embodiment of this application; Figure 4 A block diagram of a task execution timeout monitoring device according to an embodiment of this application; Figure 5The present application provides a schematic diagram of the structure of an electronic device. Detailed Implementation
[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0027] In the current centralized electronic and electrical architecture, domain controllers integrate a large number of application modules, resulting in a significant increase in the number of tasks and functions. However, in the actual vehicle operating environment, it is not possible to continuously connect to a debugger for real-time monitoring, and some operational failures are sporadic and unreproducible, making it particularly important to obtain internal operating information of the controller when problems occur.
[0028] Existing technical solutions typically involve configuring the runtime threshold for scheduled tasks on the management side, with the monitoring module determining whether a task has timed out and issuing an alert based on its runtime. However, this method has the following limitations: First, it can only monitor periodic scheduled tasks and cannot cover non-periodic tasks; second, it can only identify tasks that have timed out and cannot pinpoint the specific problematic function within the task; third, the monitoring module relies on an external controller and cannot be implemented within the vehicle controller; fourth, the monitoring information uses a real-time reporting mechanism, and if data is not captured when a fault occurs, the relevant information will be lost after the system is reset; fifth, troubleshooting in actual vehicles requires disassembling the controller and connecting a debugger, which is cumbersome, and some sealed controllers cannot be operated in this way.
[0029] To address the problems caused by excessively long task execution times and the aforementioned shortcomings of existing technologies, this invention proposes a method for monitoring and recording task execution time. This method can continuously monitor the execution time of various tasks in the controller. Once a task's execution time is detected to exceed a warning threshold, the corresponding monitoring module will automatically record the key information of the timed-out task and store it in non-volatile memory. The data in this non-volatile memory location can then be read via the communication bus for developers to analyze and diagnose.
[0030] The following description, with reference to the accompanying drawings, describes a method, apparatus, device, vehicle, and storage medium for monitoring task execution timeouts according to embodiments of this application.
[0031] Specifically, Figure 1 This is a flowchart illustrating a task execution timeout monitoring method provided in an embodiment of this application.
[0032] like Figure 1 As shown, the method for monitoring task timeout includes the following steps: In step S101, a target monitoring interruption task is constructed. The target monitoring interruption task is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of at least one monitored task.
[0033] Specifically, a dedicated monitoring interrupt task, the target monitoring interrupt task, is first built in the controller. This task is triggered at a preset period (e.g., 1ms), and its running state is managed by the system. When the system determines that the target monitoring interrupt task has entered the preset running state, it indicates that the monitoring mechanism has been activated and has begun executing its monitoring logic.
[0034] Furthermore, in some embodiments, before determining the runtime of any monitored task, the method further includes: obtaining the current task start flag of at least one monitored task, and filtering out monitored tasks whose current task start flag is at a preset flag.
[0035] It should be noted that the target monitoring interrupt task is configured in the system scheduler to have a higher priority than any monitored task. This ensures that the monitoring interrupt task can preempt and monitor the low-priority monitored task under any circumstances, thereby guaranteeing the real-time and deterministic nature of the monitoring behavior. It effectively avoids monitoring blind spots or delays caused by the inability to schedule monitoring tasks in a timely manner, and ensures the reliable execution of the monitoring mechanism and the immediate capture of faults.
[0036] Furthermore, the monitoring interruption task will sequentially traverse all monitored tasks within the control to read and collect the current task start flag for each monitored task. This flag can be a Boolean value or a status word, indicating whether the corresponding task is currently in the execution queue or has been scheduled for execution. Through this traversal operation, a snapshot of the running status of all monitored tasks at this moment can be obtained.
[0037] It should be noted that, in this embodiment of the application, in all monitored tasks of the controller, the task start flag is set at the task entry point and the time of task entry is recorded, and the task start flag is reset at the task exit point, setting a threshold for the maximum running time of each monitored task. The task start flag is set when the monitored task starts running and reset when the monitored task ends.
[0038] Specifically, after collecting the start flag of the monitored task, the current task start flag of each monitored task will be traversed and compared with the preset flag state, which represents the logical state of "task has started" or "running" (e.g., logical value "1").
[0039] All tasks whose current task start flag matches the preset state will be filtered and categorized as monitored tasks with preset flags. This will precisely focus the monitoring on tasks that are consuming processor resources, providing a clear scope for subsequent runtime calculations and timeout determinations. This effectively avoids unnecessary monitoring operations from consuming resources, improving monitoring efficiency and targeting.
[0040] In step S102, for any monitored task, the runtime of the monitored task is determined; if the runtime of the monitored task exceeds the runtime threshold, the monitored task is determined to be a timeout task.
[0041] Furthermore, in some embodiments, determining the runtime of any monitored task includes: obtaining the task start time and current system time of each monitored task; calculating the difference between the current system time and the task start time of each monitored task to obtain the runtime of each monitored task.
[0042] Specifically, when the monitoring interruption task is running, it iterates through all monitored tasks to see if the task start flag is set. If the corresponding task start flag is set, the target monitored task is obtained, and the runtime of the target monitored task is calculated by calculating the difference between the current time and the entry time of the target monitored task.
[0043] In detail, after identifying the target tasks that are currently running, the current runtime of each target task is precisely calculated. First, the start time of each monitored task and the current system time are obtained. The system time can be derived from a high-precision timer or system clock within the controller, and this time base remains continuous and monotonically increasing during system operation.
[0044] Furthermore, for each monitored task, a time difference calculation is performed: that is, the current system time is subtracted from the task start time of the monitored task to obtain the runtime of the monitored task.
[0045] like Figure 2As shown, a high-priority monitoring interrupt task with a period of 1ms is constructed. The monitored task sets its "task start flag" at its entry point and resets it at its exit point. During task execution, it may be paused or terminated for various reasons (such as being preempted by a higher-priority task, being actively suspended, or stopping normally). The monitoring interrupt is triggered every 1ms. When the monitoring interrupt task runs, it checks the start flags of each monitored task. If a monitored task's flag is set, it indicates that the monitored task is currently running, and the monitoring logic begins to accumulate its running time. By comparing the current time with the monitored task's start time, the running time of the task since its start can be calculated. This principle ensures accurate and real-time capture of the execution time of each monitored task, providing a basis for subsequent timeout judgment and fault logging.
[0046] Furthermore, after obtaining the current runtime of each monitored task, the current runtime of each monitored task is first compared with its own preset maximum runtime threshold. The maximum runtime threshold is set independently in advance based on the task's functional characteristics, real-time requirements, and system resource constraints; it defines the maximum allowed time for a single run of the task.
[0047] The system checks if at least one monitored task has exceeded its corresponding maximum runtime threshold. If the detection result indicates the existence of such a monitored task, all monitored tasks meeting this condition are marked as timeout tasks, indicating that these tasks have been determined to have experienced execution timeout exceptions, thus triggering the system's fault monitoring mechanism.
[0048] Furthermore, in some embodiments, after determining the runtime of a monitored task for any monitored task, the method further includes: if there is no monitored task whose runtime exceeds the runtime threshold, then the step of determining the runtime of a monitored task for any monitored task is re-executed.
[0049] Specifically, if, after this round of traversal and judgment, the current runtime of all monitored tasks has not exceeded their respective thresholds, it indicates that no timeout anomalies have been detected in the current monitoring cycle. Therefore, no fault handling logic is executed, and the initial steps for determining the runtime of any monitored task are restarted, thereby starting the next monitoring cycle.
[0050] Furthermore, in some embodiments, after determining that the monitored task is a timeout task, the method further includes: obtaining the task name, stack variable information, runtime, and system time of the timeout task; storing the task name, stack variable information, runtime, and system time of the timeout task to a preset non-volatile storage medium; and sending the task execution timeout flag of the timeout task to a preset external bus.
[0051] Specifically, after a timeout task is identified, the stack pointer of the timeout task is obtained, and the information of the stack variable corresponding to the stack pointer is recorded. The relative running time and system time of the monitored task timeout are also recorded, along with the name of the task that timed out. The stack variable records the currently running function.
[0052] Furthermore, the information obtained above is written into a preset non-volatile storage medium (such as Flash memory) for storage, ensuring that all critical fault information can still be completely retained after the controller is powered off or the fault disappears or the system is reset, thereby overcoming the problem of data loss in volatile memory and providing a durable and reliable data foundation for subsequent offline diagnosis.
[0053] After information storage is complete, an asynchronous alarm is proactively sent to external diagnostic devices or upper-level management systems by sending a task timeout flag to a preset external bus (such as CAN or Ethernet). This allows developers to be aware of the fault in a timely manner and to read detailed fault data from the non-volatile memory via bus commands. Specifically, when developers receive the task timeout flag, they can directly read the corresponding non-volatile memory address using the external communication bus to retrieve the stack information, relative time of the fault, system time, and the name of the timed-out task. This facilitates task analysis and ultimately achieves convenient and efficient fault diagnosis without disassembling the controller or connecting a debugger.
[0054] Therefore, the task execution timeout monitoring method proposed in this application has the following combined advantages: First, its monitoring mechanism is universal, capable of comprehensively monitoring the execution time of all tasks in the system, including periodic tasks and event-triggered tasks. Second, when an abnormal task execution is detected (i.e., the task execution time is too long), it can automatically capture and record key fault scene information, such as task stack data, function call information of the timed-out task stack, controller relative execution time, and system timestamp, facilitating subsequent troubleshooting. Furthermore, this solution adopts a lightweight design, relying solely on the controller's own resources to achieve all monitoring and recording functions, without the need for external controller support, thus improving the system's independence and deployment flexibility. Regarding data persistence, by storing the recorded key information in non-volatile storage media, it ensures that fault data can still be completely read and analyzed after system reset, power failure restart, or fault disappearance. Finally, when reproducing and diagnosing problems in a real vehicle environment, it eliminates the need for cumbersome operations such as relying on debuggers or disassembling the controller, simplifying operation and significantly improving the efficiency and convenience of fault diagnosis, and is applicable to various vehicle controllers.
[0055] To facilitate a more intuitive understanding of the task execution timeout monitoring method of this application by those skilled in the art, the following is combined with... Figure 3 Please provide a detailed explanation.
[0056] like Figure 3 As shown, the method for monitoring task timeout includes the following steps: S1, monitoring interruption task construction.
[0057] S2, Setting the Start Flag of Monitored Tasks: In all monitored tasks in the controller, set the start flag at the task entry point and record the time of the task entry point. Reset the start flag at the task exit point and set the threshold for the maximum running time of each monitored task.
[0058] S3, Determine if the task start flag is set: If the corresponding task start flag is set, then execute S4; otherwise, return to step S3.
[0059] S4, Calculate the running time of the monitored task: Calculate the running time of the task by calculating the difference between the current time and the entry time of the task.
[0060] S5, Determine if the task execution time has exceeded: Determine if the task execution time exceeds the maximum execution time threshold of the monitored task. If yes, execute S6; otherwise, execute S3.
[0061] S6, retrieve key information for timeout tasks.
[0062] S7, external storage and notification of critical information.
[0063] S8, Timeout Task Information Acquisition.
[0064] According to the task execution timeout monitoring method proposed in this application, a target monitoring interruption task is constructed. This target monitoring interruption task is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of at least one monitored task. For any monitored task, the runtime of the monitored task is determined. If the runtime of the monitored task exceeds a runtime threshold, the monitored task is determined to be a timeout task. This solves the problem that related technologies cannot perform task execution timeout monitoring without relying on external hardware, and achieves millisecond-level timeout monitoring for all types of tasks without the need for external devices or affecting the vehicle wiring harness.
[0065] Next, the task execution timeout monitoring device proposed according to the embodiments of this application is described with reference to the accompanying drawings.
[0066] Figure 4 This is a block diagram of a task execution timeout monitoring device according to an embodiment of this application.
[0067] like Figure 4 As shown, the task execution timeout monitoring device 10 includes: a construction module 100 and a determination module 200.
[0068] The construction module 100 is used to construct a target monitoring interruption task, which is used to monitor at least one monitored task. The target monitoring interruption task has a higher priority than the priority of at least one monitored task. The determination module 200 is used to determine the runtime of any monitored task. If the runtime of the monitored task exceeds the runtime threshold, the monitored task is determined to be a timeout task.
[0069] Furthermore, in some embodiments, after determining that the monitored task is a timeout task, the determining module 200 is further configured to: obtain the task name, stack variable information, runtime and system time of the timeout task; store the task name, stack variable information, runtime and system time of the timeout task to a preset non-volatile storage medium; and send the task execution timeout flag of the timeout task to a preset external bus.
[0070] Furthermore, in some embodiments, the determining module 200 is configured to: obtain the task start time and current system time of each monitored task; calculate the difference between the current system time and the task start time of each monitored task to obtain the runtime of each monitored task.
[0071] Furthermore, in some embodiments, after determining the runtime of a monitored task for any monitored task, the determining module 200 is further configured to: if there is no monitored task whose runtime exceeds the runtime threshold, then re-execute the step of determining the runtime of a monitored task for any monitored task.
[0072] Furthermore, in some embodiments, before determining the runtime of any monitored task, the determining module 200 is further configured to: obtain the current task start flag of at least one monitored task, and filter out monitored tasks whose current task start flag is at a preset flag.
[0073] It should be noted that the foregoing explanation of the task execution timeout monitoring method embodiment also applies to the task execution timeout monitoring device of this embodiment, and will not be repeated here.
[0074] According to the task execution timeout monitoring device proposed in the embodiments of this application, a target monitoring interruption task is constructed. The target monitoring interruption task is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of at least one monitored task. For any monitored task, the runtime of the monitored task is determined. If the runtime of the monitored task exceeds the runtime threshold, the monitored task is determined to be a timeout task. This solves the problem that related technologies cannot perform task execution timeout monitoring without relying on external hardware, and achieves millisecond-level timeout monitoring of all types of tasks without the need for external devices or affecting the vehicle wiring harness.
[0075] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.
[0076] When the processor 502 executes the program, it implements the task execution timeout monitoring method provided in the above embodiments.
[0077] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.
[0078] The memory 501 is used to store computer programs that can run on the processor 502.
[0079] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0080] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0081] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.
[0082] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.
[0083] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described task timeout monitoring method.
[0084] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0085] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0086] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0087] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0088] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0089] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.
[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.
[0091] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.
Claims
1. A method for monitoring task execution, characterized in that, Includes the following steps: Construct a target monitoring interruption task, which is used to monitor at least one monitored task, wherein the priority of the target monitoring interruption task is higher than the priority of the at least one monitored task. For any monitored task, determine the runtime of the monitored task; if the runtime of the monitored task exceeds the runtime threshold, determine the monitored task as a timeout task.
2. The method according to claim 1, characterized in that, After determining that the monitored task is a timeout task, the process also includes: Obtain the task name, stack variable information, runtime, and system time of the timed-out task; The task name, stack variable information, runtime, and system time of the timed-out task are stored in a preset non-volatile storage medium. The timeout flag of the timeout task is sent to a preset external bus.
3. The method according to claim 1, characterized in that, Determining the runtime of any monitored task includes: Get the start time and current system time for each monitored task; The difference between the current system time and the task start time of each monitored task is calculated to obtain the runtime of each monitored task.
4. The method according to claim 1, characterized in that, After determining the runtime of any monitored task, the process further includes: If there is no monitored task whose runtime exceeds the runtime threshold, then the step of determining the runtime of any monitored task is re-executed.
5. The method according to claim 1, characterized in that, Before determining the runtime of any monitored task, the process further includes: Obtain the current task start flag of at least one monitored task, and filter out monitored tasks whose current task start flag is at a preset flag.
6. A task execution timeout monitoring device, characterized in that, include: A construction module is used to construct a target monitoring interruption task, wherein the target monitoring interruption task is used to monitor at least one monitored task, and the priority of the target monitoring interruption task is higher than the priority of the at least one monitored task. The determination module is used to determine the runtime of any monitored task; if the runtime of the monitored task exceeds a runtime threshold, the monitored task is determined to be a timeout task.
7. The apparatus according to claim 6, characterized in that, After determining that the monitored task is a timeout task, the determining module is further configured to: Obtain the task name, stack variable information, runtime, and system time of the timed-out task; The task name, stack variable information, runtime, and system time of the timed-out task are stored in a preset non-volatile storage medium. The timeout flag of the timeout task is sent to a preset external bus.
8. An electronic device, characterized in that, Including processor and memory, among which Memory, used to store computer programs; A processor is used to execute a program stored in memory to implement the task execution timeout monitoring method according to any one of claims 1-5.
9. A vehicle, characterized in that, It includes the electronic device as described in claim 8.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the task execution timeout monitoring method according to any one of claims 1-5.