Task exception processing method and device, and electronic equipment
By implementing a real-time detection and non-volatile storage-based abnormal data backup mechanism, the problem of difficult troubleshooting of task timeout anomalies in the AUTOSAR structure is solved, enabling rich data collection and efficient fault location, and improving the reliability and efficiency of anomaly handling and analysis.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FAW QI NEW POWER (CHANGCHUN) TECHNOLOGY CO LTD
- Filing Date
- 2026-04-28
- Publication Date
- 2026-07-24
AI Technical Summary
In the AUTOSAR architecture, it is difficult to effectively troubleshoot anomalies caused by mission timeouts. Existing technologies have limited information collection, resulting in unclear causes of failures and difficulty in quick resolution.
The system detects abnormal events in real time, triggers abnormal data backup, backs up core record fields for different task types, and saves them through non-volatile storage media. It also sets a lock flag to prevent data overwriting and supports DID diagnostics and CAN bus feedback for fault analysis.
It enables the collection of abundant raw data, improves the reliability and efficiency of anomaly cause analysis, ensures the security of backup data, and facilitates subsequent fault location and resolution.
Smart Images
Figure CN122450720A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive electronics technology, and in particular to methods, devices and electronic devices for handling task anomalies. Background Technology
[0002] In the AUTOSAR architecture, the operating system manages system resources, task scheduling, communication, and error handling. When the operating system detects an anomaly, it invokes Errorhook for processing, determining the appropriate action based on the severity of the problem. In actual development, the most troublesome system anomaly is task timeout. In embedded systems with preemptive task configurations, a timeout might be the result of multiple high-priority tasks vying for resources. Conventional handling involves storing a small amount of exception information related to the timeout and then performing a reset. This approach is simple and convenient, but it limits the amount of information that can be stored, and requires significant time and effort to reproduce the problem after it occurs. Summary of the Invention
[0003] The purpose of this invention is to provide a method, apparatus, and electronic device for handling task anomalies, which can solve the problem of difficulty in troubleshooting task timeouts, realize the recording and storage of required information, and greatly improve the reliability of problem analysis and resolution.
[0004] This invention provides the following solution:
[0005] According to one aspect of the present invention, a task exception handling method is provided, the task exception handling method comprising:
[0006] Real-time detection of abnormal events in running tasks within the system;
[0007] When an abnormal event is detected, an abnormal data backup is triggered;
[0008] After the abnormal data backup is triggered, the abnormal data backup is performed on the core record fields of the abnormal task.
[0009] After the abnormal data backup is completed, the lock flag corresponding to the task is set.
[0010] Optionally, upon detecting an abnormal event, an abnormal data backup is triggered, including:
[0011] If the maximum runtime of any periodic task or interrupted task exceeds a preset warning threshold, record the moment and trigger an abnormal data backup; or
[0012] If the number of activations of any periodic task exceeds the preset fault threshold, a multiple activation exception will be triggered, entering the Errorhook error handling program. This time will be recorded, an exception data backup will be triggered independently, and a reset will be performed after the backup is completed.
[0013] Optionally, after an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that resulted in the abnormality, including:
[0014] Back up a complete set of its own time-series records to the corresponding partition of non-volatile storage media, overwriting the old data;
[0015] If there is sufficient volatile storage space, old data will not be overwritten, and multiple backups of data from abnormal situations will be achieved.
[0016] Optionally, after an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that resulted in the abnormality, including:
[0017] Perform abnormal data backups on the core record fields of the periodic task;
[0018] Perform an abnormal data backup for the core record fields of the interrupted task; or
[0019] Perform abnormal data backup for the core record fields of the thread task.
[0020] Optionally, the core record fields for periodic tasks include: task ID, entry time, end time, running time, and number of activations per unit time.
[0021] The core record fields for interrupt tasks include: interrupt ID, entry time, end time, running time, and number of activations per unit time.
[0022] The core record fields for a thread task include: FromID, ToID, and time.
[0023] Optional, also includes:
[0024] The number of different types of tasks can be flexibly adjusted based on memory usage.
[0025] Optionally, after an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that resulted in the abnormality, including:
[0026] Perform abnormal data backup through hook functions.
[0027] Optional, also includes:
[0028] By using DID diagnostics, CAN calibration, and CAN bus feedback, abnormal backup information stored locally is read. Based on the timestamp of the time when the abnormality occurred, the historical operating data of the system is traced back and the root cause of the fault is analyzed.
[0029] According to a second aspect of the present invention, a task exception handling apparatus is provided, the task exception handling apparatus comprising:
[0030] The detection module is used to detect abnormal events of running tasks in the system in real time.
[0031] The trigger module is used to trigger abnormal data backup when an abnormal event is detected.
[0032] The backup module is used to perform abnormal data backup for the core record fields of the abnormal task after the abnormal data backup is triggered.
[0033] The setting module is used to set the lock flag corresponding to the task after the abnormal data backup is completed.
[0034] According to three aspects of the present invention, an electronic device is provided, the electronic device comprising:
[0035] Processor, communication interface, memory, and communication bus.
[0036] The processor, communication interface, and memory communicate with each other through a communication bus.
[0037] The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the task exception handling method described above.
[0038] The above solution achieves the following beneficial technical effects:
[0039] This invention, through a reasonable fault recording and processing mechanism, can save sufficient task operation information and other working condition data, ensuring that the first scene data when a problem occurs is correctly stored, which facilitates reading fault information and subsequent analysis and location through DID or calibrated CAN. Attached Figure Description
[0040] Figure 1 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention;
[0041] Figure 2 This is a flowchart of the triggering operation in the task exception handling method provided in one or more embodiments of the present invention;
[0042] Figure 3 This is a flowchart of the backup operation in the task exception handling method provided in one or more embodiments of the present invention;
[0043] Figure 4 This is a flowchart of the backup operation in the task exception handling method provided in one or more embodiments of the present invention;
[0044] Figure 5This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention;
[0045] Figure 6 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention;
[0046] Figure 7 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention;
[0047] Figure 8 This is a structural diagram of a task exception handling device provided in one or more embodiments of the present invention;
[0048] Figure 9 This is a structural diagram of an electronic device provided in one or more embodiments of the present invention. Detailed Implementation
[0049] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0050] Figure 1 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention. See also... Figure 1 The task exception handling method includes the following steps:
[0051] S11, Real-time detection of abnormal events in running tasks within the system.
[0052] S12, triggers abnormal data backup when an abnormal event is detected.
[0053] S13, after the abnormal data backup is triggered, perform abnormal data backup for the core record fields of the abnormal task.
[0054] S14. After the abnormal data backup is completed, the lock flag corresponding to the task is set.
[0055] In the AUTOSAR CP system architecture, exception handling has always been a focus of attention. Moreover, due to its wide scope and numerous factors, exception handling is often a challenging aspect of the system architecture.
[0056] In the existing AUTOSAR CP system architecture, the handling of anomalies often suffers from insufficient data collection at the time of anomaly occurrence, resulting in a lack of basic data for subsequent anomaly analysis. This leads to difficulties in troubleshooting and ultimately results in the cause of the anomaly being unclear, making it impossible to effectively address and resolve the issue.
[0057] This embodiment addresses the aforementioned problems in the prior art by proposing an exception handling process. Running the process provided in this embodiment can effectively solve the problem of troubleshooting the causes of exceptions.
[0058] At the beginning of the above process, abnormal events are detected first.
[0059] For abnormal event detection, it must be for abnormal events occurring within tasks that are currently running in the system. In other words, if the source of an abnormal event is not a task that is currently running in the system, then such an abnormal event will not be detected.
[0060] For detecting abnormal events in running tasks, the process can begin by capturing the events that have already occurred. Then, the source task of the captured event is compared to the list of running tasks in the system. If a task is found in the list, it indicates that the source task of the detected event is a running task in the system, and the event can proceed to subsequent steps in the process. If no corresponding task is found in the list, it indicates that the detected event does not originate from a running task in the system, and the event cannot proceed to subsequent steps in the process.
[0061] Once a qualified abnormal event is detected, the corresponding abnormal data backup can be triggered.
[0062] Once the abnormal data backup is triggered, the next step is to execute the abnormal data backup.
[0063] It should be understood that system tasks running within a system have different task types. For example, there are interrupt-driven tasks, periodic tasks, and thread-based tasks.
[0064] Interrupt-based tasks are tasks built upon an interrupt process. These tasks are very similar to the interrupt event handling process in microcomputer principles. Their triggering, or startup, has no clear time pattern. They are only invoked and executed when a specific type of event occurs. Once invoked and having completed the relevant processing operations, the execution of this type of task is finished.
[0065] Periodic tasks are another type of task. The start time of this type of task follows a clear pattern in its sequence. Generally, these tasks start at a set time frequency, complete the corresponding processing operations within a specified processing period, and then the execution process of this type of task is complete.
[0066] Threaded tasks are a type of task built upon threads that run within the system. Therefore, the characteristics of their creation, execution, and termination are similar to those of ordinary threads.
[0067] In this embodiment, the thread-type task is mainly responsible for switching between different periodic tasks and interruptible tasks.
[0068] During the abnormal data backup process, corresponding core record fields are set for different types of tasks. When performing abnormal data backup for a corresponding type of task, the backup task for the relevant abnormal data should be executed according to the core record fields set for that type.
[0069] Because each type of task has complete core record fields, the data items recorded in this embodiment are very complete during the abnormal data backup process. In the subsequent abnormal cause analysis process, the types and amounts of original data that can be provided for relevant analysis are relatively rich, making the abnormal cause analysis relatively easy. It will no longer cause difficulties in data analysis due to insufficient types and quantities of original collected data, thus making the subsequent abnormal cause analysis easier and making it easier to find the actual cause of the operation abnormality.
[0070] After completing the backup of abnormal data based on the core record fields, the backup data area backed up by this task is locked. Specifically, this involves setting a lock flag for the data area backed up by this task.
[0071] Once the lock flag of a data area is set, it means that the data area can no longer be accessed. This effectively prevents the data backed up by the task from being overwritten again, thus avoiding unreliable backup data.
[0072] If the task needs to access the same data area again after the lock flag is set, the task must first unlock the already set lock flag. This locking mechanism ensures the security of backup data, avoids the chaos caused by backup data being overwritten repeatedly, and improves the security and reliability of the entire abnormal data backup process.
[0073] Figure 2 This is a flowchart of the triggering operation in a task exception handling method provided by one or more embodiments of the present invention. See also Figure 2 When an abnormal event is detected, an abnormal data backup is triggered, including the following steps:
[0074] S21 If the maximum running time of any periodic task or interrupted task exceeds the preset warning threshold, record the moment and trigger abnormal data backup.
[0075] S22 If the number of activations of any periodic task exceeds the preset fault threshold, a multiple activation exception will be triggered, and the Errorhook error handling program will be entered. The moment will be recorded, the exception data backup will be triggered independently, and a reset will be performed after the backup is completed.
[0076] This embodiment is based on the foregoing embodiments of the present invention and provides a detailed description of the triggering process for abnormal data backup.
[0077] In this embodiment, there are two types of abnormal events detected: the first is timeout abnormality, and the second is activation count abnormality.
[0078] A timeout exception occurs when the actual execution time of a task exceeds the system's preset time limit. An activation count exception occurs when the number of times a task performs an activation operation within a set time period exceeds a preset threshold.
[0079] If either of the two types of anomalies is detected in the system, the corresponding abnormal data backup work needs to be triggered.
[0080] During the backup of abnormal data, the first step is to record the current moment, that is, the moment when the anomaly was detected. This is mainly to facilitate subsequent anomaly cause analysis, enabling the identification of the actual occurrence time of each anomaly during the analysis of candidate causes.
[0081] In most cases, the system has pre-defined functions for handling abnormal data backups. In other words, to trigger an abnormal data backup, simply calling the corresponding function completes the process.
[0082] In addition, the system has a built-in handler for handling abnormal activation counts, namely the Errorhook error handler. Once an abnormal activation count is detected, the Errorhook error handler must also be invoked.
[0083] Figure 3 This is a flowchart of the backup operation in a task exception handling method provided by one or more embodiments of the present invention. See also Figure 3 Once the abnormal data backup is triggered, the abnormal data backup is performed on the core record fields of the abnormal task, including the following steps:
[0084] S31 backs up its complete set of time-series records to the corresponding partition of a non-volatile storage medium, overwriting the old data.
[0085] S32, if there is sufficient volatile storage space, will not overwrite old data and will enable multiple backups of data in case of anomalies.
[0086] This embodiment is based on the foregoing embodiments of the present invention and further describes the process of backup of abnormal data.
[0087] By default, each task has its own corresponding partition. During each backup, data is backed up to a specified partition with limited capacity. This means that each time an abnormal data backup is performed, the previous backup data for the corresponding task will be overwritten. In other words, when performing anomaly analysis, only the most recent abnormal data backup for the same task can be seen within the system. Previous anomalies cannot be traced within the system.
[0088] Another implementation method, although each task has its own corresponding partition, allocates ample capacity to each task, allowing for sequential backups.
[0089] In such a situation, when performing an abnormal data backup, after the data backup operation is performed once, the next backup does not need to overwrite the previous backup data, and can still be backed up in the corresponding partition.
[0090] Figure 4 This is a flowchart of the backup operation in a task exception handling method provided by one or more embodiments of the present invention. See also Figure 4 Once the abnormal data backup is triggered, the abnormal data backup is performed on the core record fields of the abnormal task, including the following steps:
[0091] S41 performs abnormal data backup for the core record fields of periodic tasks.
[0092] S42 performs an exception data backup for the core record fields of the interrupted task.
[0093] S43 performs an exception data backup for the core record fields of the thread task.
[0094] This embodiment is based on the foregoing embodiments of the present invention and further explains the data backup process.
[0095] Among the tasks that require backup of abnormal data within the system, there are three most typical task types: periodic tasks, interruptible tasks, and threaded tasks.
[0096] Each of the three tasks described above has its own corresponding core record fields. When performing the corresponding abnormal data backup, the corresponding abnormal data backup operation needs to be performed based on the core record fields defined for each type.
[0097] Typically, the core record fields for a periodic task should include: task ID, entry time, end time, runtime, and number of activations per unit time.
[0098] The core record fields for interrupted tasks should include: interrupt ID, entry time, end time, running time, and number of activations per unit time.
[0099] The core record fields for a thread task should include: FromID, ToID, and time point.
[0100] When performing backups of abnormal data of the corresponding type, the backups should be performed strictly according to the core record fields specified for that type. Backups should not skip any specified data fields.
[0101] Figure 5 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention. See also... Figure 5 The task exception handling method includes the following steps:
[0102] S51 detects abnormal events in running tasks in the system in real time.
[0103] S52 triggers abnormal data backup when an abnormal event is detected.
[0104] S53, after the abnormal data backup is triggered, perform abnormal data backup for the core record fields of the abnormal task.
[0105] S54. After the abnormal data backup is completed, the lock flag corresponding to the task is set.
[0106] S55 can flexibly allocate the number of different types of tasks based on memory usage.
[0107] This embodiment is based on the foregoing embodiments of the present invention and further provides a process for allocating the number of tasks.
[0108] In a typical scenario, different types of tasks should be running concurrently within a system. That is, concurrently running tasks within a system can include periodic tasks, interruptible tasks, and threaded tasks.
[0109] It should be understood that when the number of different types of tasks running in the system is configured differently, the corresponding amount of system memory occupied will be different.
[0110] For example, compared to threaded tasks, periodic tasks and interrupted tasks occupy a relatively large amount of memory for their corresponding structures during execution. Therefore, when system memory is tight, fewer periodic and interrupted tasks should be run, while more threaded tasks should run to avoid excessive system memory consumption.
[0111] When system memory usage is not high, more system memory can be allocated to periodic tasks and interrupt tasks, while the number of thread tasks can be reduced.
[0112] In some typical implementations, the system maintains a task list categorized by type for each running task. Running tasks are categorized into periodic tasks, interrupted tasks, and threaded tasks. The task list stores key information about each running task. When an anomaly is detected in a running task, the real-time information stored in this task list can be referenced to perform subsequent backups and analysis.
[0113] The task list uses a dynamic scrolling maintenance mechanism, which updates in real time along with the creation, destruction, and status switching of tasks. The clock reflects the current actual task running status of the system.
[0114] Figure 6 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention. See also... Figure 6 The task exception handling method includes the following steps:
[0115] S61, real-time detection of abnormal events in running tasks within the system.
[0116] S62 triggers abnormal data backup when an abnormal event is detected.
[0117] S63 performs abnormal data backup through hook functions.
[0118] S64. After the abnormal data backup is completed, the lock flag corresponding to the task is set.
[0119] This embodiment is based on the foregoing embodiments of the present invention and further provides an implementation method for the abnormal data backup execution process.
[0120] In this embodiment, the abnormal data backup process is performed by calling the hook function to complete the backup of the corresponding abnormal data.
[0121] The system has pre-defined hook functions for the execution of abnormal data backups. Once the abnormal data backup process has been initiated, the system only needs to call the pre-defined hook functions to complete the entire abnormal data backup process.
[0122] Figure 7 This is a flowchart of a task exception handling method provided in one or more embodiments of the present invention. See also... Figure 7 The task exception handling method includes the following steps:
[0123] S71 detects abnormal events in running tasks in the system in real time.
[0124] S72 triggers abnormal data backup when an abnormal event is detected.
[0125] S73, after the abnormal data backup is triggered, performs abnormal data backup for the core record fields of the abnormal task.
[0126] S74. After the abnormal data backup is completed, the lock flag corresponding to the task is set.
[0127] The S75 uses DID diagnostics, CAN calibration, and CAN bus feedback to read locally stored abnormal backup information. Based on the timestamp of the time the abnormality occurred, it performs retrospective analysis and root cause analysis of the system's historical operating data.
[0128] This embodiment is based on the foregoing embodiments of the present invention and further describes the process of abnormal cause analysis.
[0129] After completing the backup operation for the abnormal data and setting the lock flag, the corresponding abnormal cause analysis can be performed based on the backed-up data.
[0130] In this embodiment, the analysis of the cause of the abnormal operation is performed in the cloud through DID diagnosis, CAN calibration, CAN bus feedback.
[0131] Specifically, by using DID diagnostics, CAN calibration, and CAN bus feedback, stored information is read, and the operating data of each core is analyzed based on the abnormal time value. For early warning issues, trends are analyzed to resolve problems in advance, and for fault issues, the source of abnormal faults is located.
[0132] Figure 8 This is a structural diagram of a task exception handling device provided in one or more embodiments of the present invention. See also... Figure 8 The task exception handling device includes:
[0133] The detection module 81 is used to detect abnormal events of running tasks in the system in real time.
[0134] Trigger module 82 is used to trigger abnormal data backup when an abnormal event is detected.
[0135] Backup module 83 is used to perform abnormal data backup for the core record fields of the abnormal task after the abnormal data backup is triggered.
[0136] The setting module 84 is used to set the lock flag corresponding to the task after the abnormal data backup is completed.
[0137] It is worth noting that although only some basic functional modules are disclosed in the embodiments of this invention, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be considered as the scope of protection of the claims of this invention being limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.
[0138] like Figure 9 As shown, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a task exception handling method.
[0139] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. For example... Figure 9 The structure shown in this embodiment of the invention includes an electronic device comprising one or more processors 910 and a memory 920; the processors 910 in this electronic device may be one or more. Figure 9 Taking a processor 910 as an example; memory 920 is used to store one or more programs; the one or more programs are executed by the one or more processors 910, so that the one or more processors 910 implement the task exception handling method as described in any one embodiment of the present invention.
[0140] The electronic device may also include an input device 930 and an output device 940.
[0141] The processor 910, memory 920, input device 930, and output device 940 in this electronic device can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.
[0142] The memory 920 in this electronic device serves as a computer-readable storage medium, capable of storing one or more programs. These programs can be software programs, computer-executable programs, or modules, such as the program instructions / modules corresponding to the task exception handling method provided in this embodiment of the invention. The processor 910 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 920, thereby implementing the task exception handling method described in the above embodiment.
[0143] The memory 920 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 920 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 920 may further include memory remotely located relative to the processor 910, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0144] Input device 930 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 940 may include display devices such as a display screen.
[0145] The present invention also provides a computer-readable storage medium, comprising: storing a computer program executable by a vehicle, wherein when the computer program is run on the vehicle, the vehicle performs the steps of the task exception handling method.
[0146] Specifically, the computer storage medium in this embodiment of the invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be—but is not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0147] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for handling task exceptions, characterized in that, The task exception handling method includes: Real-time detection of abnormal events in running tasks within the system; When an abnormal event is detected, an abnormal data backup is triggered; After the abnormal data backup is triggered, the abnormal data backup is performed on the core record fields of the abnormal task. After the abnormal data backup is completed, the lock flag corresponding to the task is set.
2. The method according to claim 1, characterized in that, When an abnormal event is detected, an abnormal data backup is triggered, including: If the maximum runtime of any periodic task or interrupted task exceeds a preset warning threshold, record the moment and trigger an abnormal data backup; or If the number of activations of any periodic task exceeds the preset fault threshold, a multiple activation exception will be triggered, and the Errorhook error handling program will be entered. The moment will be recorded, the exception data backup will be triggered independently, and a reset will be performed after the backup is completed.
3. The method according to claim 1, characterized in that, After an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that caused the abnormality, including: Back up a complete set of its own time-series records to the corresponding partition of non-volatile storage media, overwriting the old data; If there is sufficient volatile storage space, old data will not be overwritten, and multiple backups of data from abnormal situations will be achieved.
4. The method according to claim 1, characterized in that, After an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that caused the abnormality, including: Perform abnormal data backups on the core record fields of the periodic task; Perform an abnormal data backup for the core record fields of the interrupted task; or Perform abnormal data backup for the core record fields of the thread task.
5. The method according to claim 4, characterized in that, The core record fields for periodic tasks include: task ID, entry time, end time, runtime, and number of activations per unit time. The core record fields for interrupt tasks include: interrupt ID, entry time, end time, running time, and number of activations per unit time. The core record fields for a thread task include: FromID, ToID, and time.
6. The method according to claim 5, characterized in that, Also includes: The number of different types of tasks can be flexibly adjusted based on memory usage.
7. The method according to claim 1, characterized in that, After an abnormal data backup is triggered, an abnormal data backup is performed on the core record fields of the task that caused the abnormality, including: Perform abnormal data backup through hook functions.
8. The method according to claim 1, characterized in that, Also includes: By using DID diagnostics, CAN calibration, and CAN bus feedback, abnormal backup information stored locally is read. Based on the timestamp of the time when the abnormality occurred, the historical operating data of the system is traced back and the root cause of the fault is analyzed.
9. A task exception handling device, characterized in that, The task exception handling device includes: The detection module is used to detect abnormal events of running tasks in the system in real time. The trigger module is used to trigger abnormal data backup when an abnormal event is detected. The backup module is used to perform abnormal data backup for the core record fields of the abnormal task after the abnormal data backup is triggered. The setting module is used to set the lock flag corresponding to the task after the abnormal data backup is completed.
10. An electronic device, characterized in that, The electronic device includes: Processor, communication interface, memory, and communication bus. The processor, communication interface, and memory communicate with each other through a communication bus. The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the task exception handling method according to any one of claims 1 to 8.