Log recording method and log recording device

Abstract

The present application provides a logging method and logging device for acquiring and recording abnormal information generated during the operation of an embedded system. The logging method includes the following steps: real-time monitoring of data of at least one key variable of the embedded system, and real-time monitoring of the operating status of the operating system of the embedded system; determining whether the key variable and / or the operating system are abnormal, and if so, recording the abnormal information of the key variable or the operating system in a log file. Through the technical solution of the present application, the information recorded in the log file can accurately and effectively reflect the status of each part of the embedded system during operation, providing favorable support for system development, debugging, and fault analysis and troubleshooting.

Description

Technical Field

[0001] The present application belongs to the field of computer data processing technology, and relates to embedded operating system log management technology. Specifically, a log recording method and a log recording device are provided. Background Art

[0002] An embedded system is an application-centric device that integrates chips, operating systems, peripherals, circuits and other hardware and software to control, monitor or assist in the operation of machines and equipment. It is a dedicated computer system that is currently widely used in industrial intelligent production and assembly, scientific research and daily life. It can assist people in performing various repetitive tasks. Some robots, drones and other equipment developed based on embedded systems can also perform specific tasks in places with certain safety requirements.

[0003] Since embedded systems generally work continuously without supervision, existing embedded systems generally have a logging system to ensure continuous and stable working conditions. The existence of logs can greatly help developers discover and solve various problems during the debugging and operation of embedded systems. The logging module contained in existing embedded systems usually runs on the CPU / MCU of the main control board as an independent software unit. Through the logging function of the operating system itself, it is designed to receive log information sets. Among them, log information is generally prioritized according to the degree of urgency. For example, the most common is the five-level classification: Debug Info, Warning, Error and Fatal, log output targets and log analysis, etc. The use of such a solution can improve the efficiency of information scheduling and make it easier for developers to develop.

[0004] By analyzing various fault problems that occur during the development and operation of embedded systems, it is found that abnormal operating status of various peripherals may cause faults and problems of varying severity during the operation of embedded systems. In particular, when the embedded system encounters accidents such as freezing, restarting, collision, and falling, the on-site status of its various components can greatly help developers analyze the cause of the fault and find reasonable countermeasures. However, the existing system's built-in logging system generally records the status information of general parts such as the operating system or chip during operation. It does not specifically record the operating status of various peripherals during the operation of the embedded system, resulting in the inability to record and save various valuable information in a timely manner when the above-mentioned problems occur. Summary of the Invention

[0005] In order to solve the problems existing in the above-mentioned prior art, the purpose of this application is to provide a log recording method and a log recording device for an embedded system.

[0006] A first aspect of the present application provides a logging method for obtaining and recording abnormal information generated during the operation of an embedded system, the logging method comprising the following steps:

[0007] monitoring data of at least one key variable of the embedded system in real time, and monitoring the running state of the operating system in the embedded system in real time;

[0008] Determine whether the key variable and / or the operating system has an abnormality. If so, record the abnormality information of the key variable or the operating system in a log file.

[0009] Preferably, the key variables include at least one of the following variables: sensor variables, controller variables, intermediate variables and communication status.

[0010] Specifically, the sensor variables are variables obtained by the sensor detecting the state of the environment and / or peripherals; the controller variables are used to set the state of the controller that drives the peripherals; the intermediate variables are determined based on processing the sensor variables and / or the controller variables; and the communication state is determined based on the state of CAN communication or board communication.

[0011] Furthermore, when the key variable has one or more of the following phenomena, it is determined that the key variable is abnormal: the update frequency of the key variable is abnormal, the frequency and / or number of key variable verification failures are abnormal, and the data value of the key variable is abnormal.

[0012] Preferably, the abnormal information of the key variable includes the abnormal phenomenon of the key variable and auxiliary information for judging the abnormality of the key variable.

[0013] Furthermore, when the operating system has one or more of the following phenomena, it is determined that the operating system has an abnormality: the operating system's memory or stack overflows, wild pointers appear during program execution, and the operating speed of the operating system decreases significantly and irreversibly.

[0014] Preferably, when the memory or stack of the operating system overflows and a wild pointer appears during program execution, the following operations are performed before the embedded system triggers a HardFault interrupt:

[0015] Interrupt the currently executing program;

[0016] The countdown data of the watchdog is reset periodically until the abnormal information of the operating system is recorded in the log file.

[0017] Preferably, whether the operating speed of the operating system has been significantly and irreversibly reduced is determined by a low-frequency-high priority interrupt controlled by a hardware timer, wherein the hardware timer runs independently of the operating system.

[0018] Preferably, the key variable has at least two storage addresses, and each key variable is accessed through a data packet bound thereto, wherein the access includes a read operation and a synchronous update operation on the key variable.

[0019] Preferably, the data packet includes:

[0020] The index of the key variable corresponding to the data packet;

[0021] The current value of the key variable corresponding to the data packet;

[0022] A list of storage addresses of key variables corresponding to the data packet, wherein the list of storage addresses includes at least two storage addresses of the key variables;

[0023] The semaphore of the key variable corresponding to this data packet.

[0024] Furthermore, the key variable is read by the following steps:

[0025] Determine the corresponding data packet based on the key variables that need to be read;

[0026] If the semaphore of the key variable is in the released state, the semaphore of the key variable is acquired; otherwise, the semaphore of the key variable is acquired after waiting for other previously executed reads or synchronous updates of the key variable to complete;

[0027] Obtain a list of storage addresses of the key variables from the data packet;

[0028] Determining a storage address for reading the key variable from the storage address list, and reading the key variable from the storage address, or reading the key variable from the data packet;

[0029] Release the semaphore of the key variable.

[0030] Furthermore, the synchronous update operation of the key variables is performed through the following steps:

[0031] Get the latest value of the key variables that need to be updated;

[0032] Determine the data package bound to the key variables that need to be updated;

[0033] If the semaphore of the key variable is in the released state, the semaphore of the key variable is acquired; otherwise, the semaphore of the key variable is acquired after waiting for other previously executed reads or synchronous updates of the key variable to complete;

[0034] Obtain the storage address list of the key variable from the data packet;

[0035] Using the latest value obtained to update the current value of the key variable;

[0036] Using the latest value obtained to update all storage addresses of the key variable;

[0037] Release the semaphore of the key variable.

[0038] Preferably, the key variables are synchronously updated through a callback function; the data packet also includes a pointer to the callback function for performing a synchronous update operation on the key variables corresponding to the data packet.

[0039] Preferably, the data packet further includes a pointer to a callback function for accessing key variables corresponding to the data packet.

[0040] Preferably, the logging method further comprises the step of periodically recording the key variables in the log file.

[0041] Preferably, the logging method further comprises the step of grading the severity of the information recorded in the log file, wherein the severity of the abnormal information of the operating system is higher than the severity of the abnormal information of the key variable.

[0042] Preferably, the logging method further comprises the step of encoding the log file and outputting the encoding to an external device.

[0043] A second aspect of the present application provides a logging device for acquiring and recording abnormal information generated during operation of an embedded system, the logging device comprising:

[0044] A monitoring module, configured to monitor data of at least one key variable of the embedded system in real time, and to monitor the running state of the operating system in the embedded system in real time;

[0045] The recording module is used to determine whether there is an abnormality in the key variable and / or the operating system. If so, the abnormality information of the key variable or the abnormality information of the operating system is recorded in a log file.

[0046] The embodiments of the present application provide a log recording method and a log recording device, which monitor and record the operating status of various types of peripherals of the embedded system and the operating status of the embedded operating system, and provide a targeted key variable synchronization update mechanism and an operating system abnormality response mechanism based on the characteristics and abnormal phenomena during the operation of different types of peripherals and the abnormal types during the operation of the embedded operating system itself, so as to ensure that the information recorded in the log file can accurately and effectively reflect the status of each part of the embedded system during operation, providing useful support for system development, debugging and fault analysis and troubleshooting. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 A schematic diagram of an implementation flow of a logging method according to some preferred embodiments of the present application;

[0048] Figure 2 A schematic diagram of an implementation flow of a logging method according to some preferred embodiments of the present application;

[0049] Figure 3 A schematic diagram of the system architecture of a logging device provided according to some preferred embodiments of the present application. DETAILED DESCRIPTION

[0050] Hereinafter, the present application will be further described based on preferred embodiments with reference to the accompanying drawings.

[0051] Figure 1 The following is a schematic diagram of an implementation flow of a logging method provided in some preferred embodiments of the present application. The logging method is used to obtain and record abnormal information generated during the operation of an embedded system. As shown in the figure, the logging method includes the following steps:

[0052] Executing steps S100 and S200 respectively: monitoring data of at least one key variable of the embedded system in real time and monitoring the running state of the operating system in the embedded system in real time;

[0053] Execute steps S300 and S400 respectively: determine whether there are abnormalities in key variables and operating system;

[0054] If there is an exception, step S500 is executed: recording the exception information of the key variable or the exception information of the operating system in a log file.

[0055] In the above steps, the operating status of various types of peripherals of the embedded system and the operating status of the embedded operating system are monitored respectively. The monitoring of the peripherals is performed by obtaining implementation data of various key variables reflecting the operating status of the peripherals. Furthermore, during the monitoring process, the abnormalities of the above key variables and the embedded operating system are judged and recorded in the log file.

[0056] Specifically, in an embodiment of the present application, key variables include at least one of the following variables: sensor variables, controller variables, intermediate variables, and communication status, wherein sensor variables are variables obtained by detecting the status of the environment and / or peripherals by temperature sensors, attitude sensors, acceleration sensors, etc.; controller variables are used to set the status of controllers such as motors, servos, heating devices, etc. that drive peripherals; intermediate variables are determined based on processing sensor variables and / or controller variables, such as the results obtained by statistically analyzing the duration of temperature data above a certain threshold, or the frequency and fluctuation degree of low-frequency vibration of the motor obtained based on the acceleration curve, or the update frequency of a certain sensor variable; communication status is determined based on the status of CAN communication or board communication, such as the sending and receiving status of a key variable in inter-board communication. The above-mentioned various types of key variables reflect the working conditions of the embedded system from different aspects. During the operation of the embedded system, problems or failures in the operating conditions of different devices may cause the data of different key variables to present different abnormal behaviors.

[0057] Specifically, in an embodiment of the present application, when a key variable has one or more of the following phenomena: abnormal update frequency, abnormal frequency and / or number of verification failures, and abnormal data value, the key variable is judged to be abnormal, and the abnormal phenomenon of the key variable is recorded in a log file.

[0058] Different abnormal phenomena occurring in the above key variables are often caused by different reasons, reflecting different problems of various devices in the embedded system. The following is a detailed description with reference to specific embodiments.

[0059] (1) The update frequency of key variables is abnormal.

[0060] This anomaly is generally manifested as a slowdown in the update frequency of a sensor variable, controller variable, or intermediate variable. For different types of key variables, this anomaly may be caused by the following reasons:

[0061] If the update frequency of the sensor variables slows down, there may be a problem with the wiring, including loose interfaces, poor contact, overheating, wear and tear of the connection line, etc.

[0062] If the update frequency of the controller variables slows down, the program may skip a large number of parts during the calculation of the controller variables. You can check whether the control thread is running normally and whether certain trigger thresholds are triggered frequently.

[0063] If the update frequency of the intermediate variables slows down, it may be due to a problem with the hardware interface / thread operation of the sensor variables or controller variables corresponding to the data source, or an abnormal operation of the solution thread.

[0064] (2) The frequency and / or number of verification failures are abnormal.

[0065] This anomaly is generally manifested as an increase in the packet loss rate or error rate of a sensor variable, controller variable, or important variable in inter-board communication. This anomaly may be caused by the following reasons:

[0066] If the error occurs during sensor variable updates and board communication, it may indicate poor bus contact or excessive electromagnetic noise. In this case, check the corresponding hardware environment for any issues.

[0067] If it occurs during controller variable updates, it may be caused by problems with the controller variable-related solution and verification algorithms.

[0068] (3) The data values ​​of key variables are abnormal.

[0069] This abnormality has the following manifestations and possible causes:

[0070] If the data value of a key variable exceeds the preset threshold, it may be caused by an unexpected situation in the embedded system. For example, if the roll angle of a wheeled robot is too large, it is likely to have rolled over.

[0071] The data value of the key variable is always within a certain range. For example, the output of the motor is always high. This may be due to feedback failure or a problem with the motor control algorithm.

[0072] The frequency or amplitude of fluctuations in the data values ​​of key variables is too large. For some sensors and controllers, high-frequency and large-amplitude vibrations in certain situations are extremely harmful and may cause controller instability, motor overheating and demagnetization, and other consequences.

[0073] In some preferred embodiments, the possible causes of various abnormal phenomena given above based on experience serve as auxiliary information for judging abnormalities of key variables, and are also recorded in the log file as abnormal information together with the corresponding abnormal phenomena of key variables.

[0074] Furthermore, for robots, unmanned vehicles and other equipment developed based on embedded systems, in some cases where various peripherals need to work together, key variables such as sensor variables and controller variables generally need to be synchronized in multiple modules / applications. In theory, the synchronization of key variables can be achieved using global variables (variables declared by extern). However, although most embedded systems have been layered into software application / driver / module / hardware kernel and other levels, in the final development (especially in the software application layer), it is still easy for global variables to be called in multiple files / applications, or even modified in multiple places at the same time, resulting in data asynchrony between modules, seriously affecting the stable operation of the system, and even causing the system to crash.

[0075] To solve the above problems, in a preferred embodiment of the present application, a new key variable synchronization mechanism with software and hardware isolation is proposed, wherein the key variable has at least two storage addresses, different storage addresses can be located in different modules running in the embedded system (modules can be programs or functions for controlling sensors, motors, etc.), and the number of storage addresses can change with the change of modules that have permission to access the key variable.

[0076] In order to ensure that the data stored in each storage address of the above-mentioned key variables that can be accessed by multiple modules can be strictly synchronized, in a preferred embodiment of the present application, each key variable is accessed through a data packet bound to it, wherein, in an embodiment of the present application, access to key variables with multiple storage addresses includes read operations and synchronous update operations on the key variables.

[0077] In some preferred embodiments, a data packet bound to a key variable may include the following parts:

[0078] 1) The index of the key variable corresponding to the data packet;

[0079] 2) The current value of the key variable corresponding to the data packet;

[0080] 3) a list of storage addresses of key variables corresponding to the data packet, wherein the list of storage addresses includes storage addresses of at least two key variables;

[0081] 4) The semaphore of the key variable corresponding to the data packet.

[0082] Among them, the index pair is used to uniquely identify the key variable, for example, it can be an int or long type number or a string type variable name, etc.; the current value is the value of the key variable after the most recent synchronization update, and its data structure is consistent with the data structure of the corresponding key variable, for example, it can be an int, long, float type variable, or a one-dimensional, multi-dimensional array type variable, or a pointer variable, or a struct (structure) type variable formed by combining the above various types of variables, etc.; the list of storage addresses can be an array type variable arranged in order of subscripts, and the value of each element in the array is a storage element of the key variable. Storage address; semaphores are generally used to coordinate synchronization between threads in embedded systems. In an embodiment of the present application, semaphores are used to lock and unlock the synchronization of multiple storage addresses of key variables. When the semaphore of a key variable is released, all programs or functions with access rights have the right to read or update it. When the semaphore of a key variable is acquired by a program or function, the key variable is in a locked state. At this time, except for the program / function that acquires the semaphore, other programs / functions that need to access the key variable need to wait for the release of the semaphore. The above waiting can be queued under the scheduling of the main thread or the synchronization management thread.

[0083] Furthermore, in some preferred embodiments, the reading operation of a key variable is performed by the following steps:

[0084] The first step is to determine the corresponding data packet based on the key variables that need to be read;

[0085] The second step is to obtain the semaphore of the key variable if it is in the released state, otherwise wait for the completion of other previously executed reads or synchronous updates of the key variable before obtaining the semaphore of the key variable;

[0086] The third step is to obtain a list of storage addresses of the key variables from the data packet;

[0087] Step 4: determining a storage address for reading the key variable from the storage address list, and reading the key variable from the storage address, or reading the key variable from the data packet;

[0088] Step 5: Release the semaphore of the key variable.

[0089] In the above steps, when a program or function needs to read a key variable, it first queries whether the semaphore of the key variable is in a released state. If the semaphore is obtained by other programs / functions, it means that other programs / functions are performing read or update operations on the key variable. At this time, it enters the queue for reading or updating the key variable until all read or update operations in front of the queue are completed (at this time the semaphore has been released and there are no programs / functions in front of the queue). The program / function obtains the semaphore to avoid other programs / functions entering the update operation during the read operation, and then obtains the current value of the key variable, or selects a storage address in its storage address list to read its latest value. Finally, after the read operation is completed, the semaphore is released to allow other programs / functions to have access to the multi-address variable.

[0090] Furthermore, in some preferred embodiments, the synchronous update operation of a key variable is performed by the following steps:

[0091] The first step is to obtain the latest value of the key variables that need to be updated;

[0092] The second step is to determine the data package bound to the key variables that need to be updated;

[0093] The third step is to obtain the semaphore of the key variable if it is in the released state, otherwise wait for the completion of other previously executed reads or synchronous updates of the key variable before obtaining the semaphore of the key variable;

[0094] The fourth step is to obtain the storage address list of the key variable from the data packet;

[0095] Step 5: Use the latest value obtained to update the current value of the key variable;

[0096] Step 6: Use the latest value obtained to update all storage addresses of the key variable;

[0097] Step 7: Release the semaphore of the key variable.

[0098] In each of the above steps, when a key variable needs to be updated, the program or function executing the update first queries the status of the semaphore of the key variable. If the semaphore has not been released, it means that other programs / functions are reading or updating the key variable. At this time, the program or function enters the queue for reading or updating the key variable until all read or update operations in front of the queue are completed. The program / function then reacquires the semaphore to avoid other programs / functions entering the update operation during the update operation, and then executes the update of the current values ​​in each storage address and data packet. Finally, after the update is completed, the semaphore is released to allow other programs / functions to have access to the multi-address variable.

[0099] Through the above-mentioned key variable-data packet-semaphore synchronization management mechanism, the isolation of data storage and data operation is achieved, and the values ​​of key variables in multiple storage addresses can be strictly synchronized, avoiding the problem of data asynchrony caused by each module accessing the key variables independently.

[0100] In some preferred embodiments, the data packet also includes a pointer to a callback function for synchronously updating the multi-address variables corresponding to the data packet. After obtaining the latest value of a key variable that needs to be updated, each storage address is synchronously updated by calling the callback function.

[0101] Furthermore, in some preferred embodiments, the data packet also includes refresh frequency information for the current value of the multi-address variable corresponding to the data packet. This refresh frequency information can be a float variable to count the refresh frequency of the last update, or an array variable to sequentially retain the refresh frequency of each update. As described above, by analyzing the refresh frequency of key variables, the operating status of various components of the embedded system (such as peripherals) can be further diagnosed.

[0102] The above is an explanation of the monitoring and recording process of abnormalities of key variables during the operation of embedded systems. During the operation of embedded systems, in addition to the above-mentioned abnormalities related to peripherals and other parts, abnormalities in the operating status of the operating system itself may also occur. The severity of these abnormalities generally exceeds that of peripheral failures, often leading to system crashes and restarts. Obviously, timely recording of the scene when the operating system operation abnormalities occur will help to conduct in-depth analysis of various software, hardware problems and compatibility conflicts that exist during the development and operation of embedded operating systems.

[0103] Specifically, in an embodiment of the present application, when the operating system of the embedded system has one or more of the following phenomena, the operating system is judged to be abnormal: the memory or stack of the operating system overflows, wild pointers appear during program execution, and the operating speed of the operating system decreases significantly and irreversibly.

[0104] Among them, overflow of the operating system's memory or stack, and the appearance of wild pointers during program execution mean that a serious error has occurred in the system operation and will trigger a HardFault interrupt. Since the system begins to perform necessary operations before restarting after entering the HardFault interrupt.

[0105] Hardfault is essentially an interrupt with a priority second only to Reset. When a problem occurs, the kernel will enable this Hardfault interrupt and run a while(1) in it, thereby interrupting all other interrupts. Macroscopically, this manifests as all external modules failing and ceasing to function, and the system freezing. Furthermore, embedded systems such as RT-Thread have also implemented kernel optimizations for Hardfault. Their built-in operating system kernels can, before entering the Hardfault interrupt, send the scene (including the problematic thread and call stack analysis) through the system serial port through a series of processes. However, they can only provide fixed information through their built-in APIs, and cannot provide various real-time data at the scene of the fault, which is more valuable for fault analysis.

[0106] Therefore, in order to protect the on-site data when the system encounters the above-mentioned serious fault, in a preferred embodiment of the present application, when the memory or stack of the operating system overflows and a wild pointer appears during program execution, the following operations are performed before the embedded system triggers a HardFault interrupt:

[0107] Interrupt the currently executing program;

[0108] The countdown data of the watchdog is reset periodically until the abnormal information of the operating system is recorded in the log file.

[0109] Specifically, a hook function can be opened in one of the functions that sends error information, and the required custom data and the error information in the register are repackaged and sent in this function. The watchdog is fed in the function to prevent the watchdog from being triggered, and then the data is sent to the serial port connected to the log recording board through the serial port on the bare machine. In this way, the scene is saved and exited, and then the watchdog is reset or the developer's debug is waited for.

[0110] In addition to the serious problems mentioned above that can cause HardFault interrupts, a large number of problems that occur randomly and cannot be located are also found during the test and development process. For example, when the CPU usage is not high, there is no HardFault, no peripheral failure, normal power supply, no large number of repeated high-frequency interrupts, the clock is correct, and the peripherals are running normally, the update frequency of the systick will rapidly slow down and cannot be restored to normal. This situation will directly affect the operating frequency of various controllers in the embedded system, but will not trigger the watchdog. Even after switching the hardware platform, the problem is still not resolved.

[0111] In a preferred embodiment of the present application, in response to the above-mentioned abnormal phenomenon, a high-priority, low-frequency hardware timer interrupt is run on the bare metal, and the interval between each two interrupts is fixed. In each interrupt, the systick captured during the previous interrupt is subtracted from the current systick and converted into time in the same unit. When it is found that the systick has slowed down significantly, the abnormal phenomenon and on-site information are recorded in the log file, and then the software reset is directly initiated to restart the embedded system.

[0112] Figure 2 FIG. 4 shows a schematic diagram of the implementation flow of the log recording method in some preferred embodiments of the present application, such as Figure 2 As shown, this logging method is the same as Figure 1 Compared with the method in , the following steps are added:

[0113] S600, periodically recording the key variables in the log file;

[0114] S700, a step of grading the severity of the information recorded in the log file, wherein the severity of the abnormal information of the operating system is higher than the severity of the abnormal information of the key variable;

[0115] S800: Encode the log file and output it to an external device.

[0116] The embodiment of the present application also provides a log recording device for obtaining and recording abnormal information generated during the operation of the embedded system. Figure 3 The system architecture diagram of the logging device in some preferred embodiments is shown as follows: Figure 3 As shown, the logging device includes:

[0117] A monitoring module, configured to monitor data of at least one key variable of the embedded system in real time, and to monitor the running state of the operating system in the embedded system in real time;

[0118] The recording module is used to determine whether there is an abnormality in the key variable and / or the operating system. If so, the abnormality information of the key variable or the abnormality information of the operating system is recorded in a log file.

[0119] In some specific embodiments, the monitoring module and the recording module may be implemented as executable programs or functions, whose executable codes are called and executed by threads of the embedded operating system to implement their respective functions. The above implementation methods are well known to those skilled in the art and will not be described in detail here.

[0120] The above is a detailed introduction to the specific implementation methods of the present application. For those skilled in the art, several improvements and modifications can be made to the present application without departing from the principles of the present application. These improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A logging method for obtaining and recording abnormal information generated during the operation of an embedded system, characterized in that: The following steps are involved: monitoring data of at least one key variable of the embedded system in real time, and monitoring the running state of the operating system in the embedded system in real time; Determine whether the key variable and the operating system have any abnormalities, and if so, record the abnormal information of the key variable or the operating system in a log file; The operating system is judged to be abnormal when the following phenomena occur in the operating system: the operating speed of the operating system decreases significantly and irreversibly; Determining whether the operating speed of the operating system has significantly and irreversibly decreased by a low-frequency, high-priority interrupt controlled by a hardware timer, wherein the hardware timer operates independently of the operating system, Determine whether the operating speed of the operating system has significantly and irreversibly decreased by the following steps, and record the significant and irreversible decrease in the log file when the operating speed of the operating system has significantly and irreversibly decreased: Based on the bare metal running a high-priority low-frequency hardware timer interrupt, the interval between each interrupt is fixed. In each interrupt, the systick captured in the previous interrupt is subtracted from the current systick and converted to time in the same unit. If the systick is found to be significantly slower, the abnormal phenomenon and on-site information are recorded in the log file, and then a software reset is directly initiated to restart the embedded system. The key variables include at least one of the following variables: a sensor variable, a controller variable, an intermediate variable, and a communication state; the key variables have at least two storage addresses, and each key variable is accessed through a data packet bound thereto, and the access includes a read operation and a synchronous update operation on the key variable; When the key variable has one or more of the following phenomena, it is determined that the key variable is abnormal: the update frequency of the key variable is abnormal, the frequency and / or number of key variable verification failures are abnormal, and the data value of the key variable is abnormal.

2. The logging method according to claim 1, wherein: The sensor variables are variables obtained by the sensor detecting the state of the environment and / or peripherals; The controller variable is used to set the state of the controller driving the peripheral device; The intermediate variable is determined based on processing the sensor variable and / or the controller variable; and The communication status is determined based on a status of CAN communication or board communication.

3. The logging method according to claim 1, wherein: The abnormal information of the key variables includes the abnormal phenomenon of the key variables and auxiliary information for judging the abnormality of the key variables.

4. The logging method according to claim 1, wherein: When the operating system has one or more of the following phenomena, it is also determined that the operating system has an abnormality: The operating system's memory or stack overflows, and a wild pointer appears during program execution.

5. The log recording method according to claim 4, characterized in that: When the memory or stack of the operating system overflows and a wild pointer appears during program execution, the following operations are performed before the embedded system triggers a HardFault interrupt: Interrupt the currently executing program; The countdown data of the watchdog is reset periodically until the abnormal information of the operating system is recorded in the log file.

6. The logging method according to claim 1, wherein: The data packet includes: The index of the key variable corresponding to the data packet; The current value of the key variable corresponding to the data packet; A list of storage addresses of key variables corresponding to the data packet, wherein the list of storage addresses includes at least two storage addresses of the key variables; The semaphore of the key variable corresponding to this data packet.

7. The log recording method according to claim 6, characterized in that: The key variables are read by the following steps: Determine the corresponding data packet based on the key variables that need to be read; If the semaphore of the key variable is in the released state, the semaphore of the key variable is acquired; otherwise, the semaphore of the key variable is acquired after waiting for other previously executed reads or synchronous updates of the key variable to complete; Obtain a list of storage addresses of the key variables from the data packet; Determining a storage address for reading the key variable from the storage address list, and reading the key variable from the storage address, or reading the key variable from the data packet; Release the semaphore of the key variable.

8. The log recording method according to claim 6, characterized in that: The synchronous update operation of the key variables is performed through the following steps: Get the latest value of the key variables that need to be updated; Determine the data package bound to the key variables that need to be updated; If the semaphore of the key variable is in the released state, the semaphore of the key variable is acquired; otherwise, the semaphore of the key variable is acquired after waiting for other previously executed reads or synchronous updates of the key variable to complete; Obtain the storage address list of the key variable from the data packet; Using the latest value obtained to update the current value of the key variable; Using the latest value obtained to update all storage addresses of the key variable; Release the semaphore of the key variable.

9. The log recording method according to claim 6, wherein: Synchronous update of key variables through callback functions; The data packet also includes a pointer to a callback function for performing a synchronous update operation on the key variables corresponding to the data packet.

10. The log recording method according to claim 6, wherein: The data packet also includes refresh frequency information of the current value of the key variable corresponding to the data packet.

11. The log recording method according to claim 1, wherein: The method further includes the step of periodically recording the key variables in the log file.

12. The log recording method according to claim 1, wherein: The method further includes a step of grading the severity of the information recorded in the log file, wherein the severity of the abnormal information of the operating system is higher than the severity of the abnormal information of the key variable.

13. The log recording method according to claim 1, wherein: The method also includes the steps of encoding the log file and outputting the encoding to an external device.

14. A log recording device, characterized in that: Acquiring and recording abnormal information generated during operation of the embedded system by executing the method of claim 1 includes: A monitoring module, configured to monitor data of at least one key variable of the embedded system in real time, and to monitor the running state of the operating system in the embedded system in real time; The recording module is used to determine whether there are any abnormalities in the key variables and the operating system, and if so, record the abnormal information of the key variables or the abnormal information of the operating system in a log file.

Images