An embedded device event detection processing method

Abstract

The application provides an embedded device event detection processing method in the technical field of embedded device operation and maintenance, comprising the following steps: S10, setting EventManager class, Eventdb class, Flash class and Ringbuffer class; S20, event detection function API triggers the detection function of the event based on the enabling signal, performs fault recording and executes preset actions based on the event detection data structure, synchronously records event logs, caches the event logs through the Ringbuffer class, and updates the event flag; S30, event recovery API triggers the recovery function of the event based on the enabling signal, executes preset actions based on the event detection data structure, synchronously records event logs, caches the event logs through the Ringbuffer class, and updates the event flag; S40, the cached event logs are stored into a database through the Eventdb class and into a Flash through the Flash class. The application has the advantage that the accuracy and efficiency of the embedded device event detection processing are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of embedded device operation and maintenance technology, and in particular to an embedded device event detection and processing method. Background Technology

[0002] With the increasing prevalence of IoT applications in daily life, various embedded devices are emerging in large numbers. These embedded devices implement numerous protection and fault handling mechanisms for security and reliability, which are categorized as events. To determine whether an embedded device is faulty and whether certain protection measures have been triggered, it is necessary to detect and handle these events.

[0003] These events correspond to a variety of signal types, including digital signals (with only 0 and 1 states) and analog signals (triggered by being greater than or less than a certain range). Some signals have significant interference and require filtering, some signals have high real-time requirements and need to be processed immediately once they occur, and some signals have low real-time requirements and require a longer time to trigger. The actions performed after different signals (events) trigger a fault are also different.

[0004] However, there is no unified method for handling different types of events in the traditional way, which results in the MCU consuming a lot of memory resources, having poor portability, and being unable to process events corresponding to digital and analog signals at the same time. It is also impossible to record the time and cause of the current event, which is not convenient for subsequent analysis.

[0005] Therefore, how to provide an embedded device event detection and processing method to improve the accuracy and efficiency of embedded device event detection and processing has become an urgent technical problem to be solved. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide an embedded device event detection and processing method to improve the accuracy and efficiency of embedded device event detection and processing.

[0007] This invention is implemented as follows: an embedded device event detection and processing method, comprising the following steps:

[0008] Step S10: Set up an EventManager class for setting up event detection data structure and event flags, providing event detection function API and event recovery API, an Eventdb class for storing event logs, a Flash class for providing Flash read API, write API and erase API, and a Ringbuffer class for caching event logs;

[0009] Step S20: The event detection function API triggers the event detection function based on the enable signal, performs fault recording based on the event detection data structure and executes preset actions, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag;

[0010] Step S30: The event recovery API triggers the event recovery function based on the enable signal, executes preset actions based on the event detection data structure, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag;

[0011] Step S40: Store the cached event logs in the database using the Eventdb class and in Flash using the Flash class.

[0012] Furthermore, in step S10, the event detection data structure includes event storage configuration, trigger configuration, trigger threshold, trigger duration, fault sequence, event time, event status, and event callback function;

[0013] The event storage configuration includes the event type and Flash storage identifier; the trigger configuration includes a detection identifier, recovery identifier, record storage identifier, active upload identifier, fault waveform identifier, event level, message sending identifier, automatic clearing identifier, and callback function parameters; the trigger threshold is the event triggering threshold, in the format of a digital signal or an analog signal; the trigger duration is used to record the event duration, counted by number; the fault position is used to identify the position of the corresponding event flag when the event is triggered; the event time is used to record the time when the event is triggered; the event status is used to record the current state of the event, obtained through state machine scanning; the event callback function is used to execute a preset action.

[0014] Furthermore, in step S10, the Eventdb class provides the EventManager class with storage API, export API, and clear API to support the storage, export, and clearing of event logs.

[0015] Further, step S20 specifically includes:

[0016] Step S21: After event initialization, the MCU checks whether the detection flag in the event detection data structure is enabled through the event detection function API. If yes, proceed to step S22; otherwise, end the process.

[0017] Step S22: Clear the original trigger duration and event status, and record them again;

[0018] Step S23: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S24; otherwise, proceed to step S22.

[0019] Step S24: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S25; otherwise, continue the statistics.

[0020] Step S25: Perform fault recording based on the fault recording identifier of the event detection data structure, execute preset actions through the event callback function based on the priority corresponding to the event level, synchronously record event logs including event source, event trigger value and event time, cache event logs through the Ringbuffer class, and update the corresponding event flag based on the fault position.

[0021] Further, step S30 specifically includes:

[0022] Step S31: After event initialization, the MCU checks whether the recovery flag in the event detection data structure is enabled through the event recovery API. If yes, proceed to step S32; otherwise, end the process.

[0023] Step S32: Clear the original trigger duration and event status, and record them again;

[0024] Step S33: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S34; otherwise, proceed to step S32.

[0025] Step S34: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S35; otherwise, continue the statistics.

[0026] Step S35: Based on the priority corresponding to the event level of the event detection data structure, execute the preset action through the event callback function, synchronously record the event log including the event source, event trigger value and event time, cache the event log through the Ringbuffer class, and clear the corresponding event flag based on the fault position order.

[0027] Further, step S40 specifically includes:

[0028] The MCU periodically checks whether the Ringbuffer class caches event logs through the event detection function API, stores the detected event logs in the database through the storage API of the Eventdb class, and stores them in Flash through the write API of the Flash class.

[0029] The advantages of this invention are:

[0030] By defining the EventManager, Eventdb, Flash, and Ringbuffer classes, event detection and processing are divided into 3 layers and 4 categories. The EventManager class sets the event detection data structure to unify the processing methods for different types of events. The trigger threshold format of the event detection data structure can be either a digital signal or an analog signal, allowing simultaneous processing of events corresponding to both digital and analog signals. During event processing, event logs including the event source, event trigger value, and event time are recorded synchronously, facilitating subsequent analysis. This not only saves fault location time but also reduces operation and maintenance costs. Furthermore, the recorded event logs are first cached using the Ringbuffer class and then stored using the Eventdb and Flash classes, effectively reducing interruption time, improving MCU utilization, and ultimately greatly enhancing the accuracy and efficiency of event detection and processing in embedded devices. Attached Figure Description

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0032] Figure 1 This is a flowchart of an embedded device event detection and processing method according to the present invention.

[0033] Figure 2 This is a schematic diagram of the architecture of the present invention.

[0034] Figure 3 This is a flowchart of the event detection process of the present invention.

[0035] Figure 4 This is a flowchart of the event recovery process of this invention. Detailed Implementation

[0036] The overall idea of ​​the technical solution in this application embodiment is as follows: By setting an event detection data structure to unify the processing methods for different types of events, the accuracy of event detection and processing in embedded devices can be improved; Since the Flash writing speed is slow, if it is in an interrupt, the interrupt execution time will be prolonged, causing many important tasks to be unable to be executed. The recorded event logs are cached first through the Ringbuffer class, and this process is basically time-saving. Then, the cached event logs are retrieved and stored in the main process, which can effectively reduce interrupt occupation, improve MCU utilization, and thus improve the efficiency of event detection and processing in embedded devices.

[0037] Please refer to Figures 1 to 4 As shown, a preferred embodiment of the embedded device event detection and processing method of the present invention includes the following steps:

[0038] Step S10: Set up an EventManager class for setting up event detection data structure and event flags, providing event detection function API and event recovery API, an Eventdb class for storing event logs, a Flash class for providing Flash read API, write API and erase API, and a Ringbuffer class for caching event logs;

[0039] Step S20: The event detection function API triggers the event detection function based on the enable signal, performs fault recording based on the event detection data structure and executes preset actions, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag;

[0040] Step S30: The event recovery API triggers the event recovery function based on the enable signal, executes preset actions based on the event detection data structure, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag;

[0041] Step S40: Store the cached event logs in the database using the Eventdb class and in Flash using the Flash class.

[0042] Through the above steps, this invention provides a configurable event detection and processing method that supports multiple event types, has reentrant functions, consumes minimal MCU resources, generates event logs, and supports automatic event recovery.

[0043] In step S10, the event detection data structure includes event storage configuration (savecfg), trigger configuration (config), trigger threshold (valueThreshold), trigger duration (timeThreshold), fault order (faultOrder), event time (cntTick), event state (state), and event callback function ((*callBack)(uint16_t data)).

[0044] The event storage configuration includes an event type and a Flash storage identifier, which indicates whether the event is stored in Flash memory. The trigger configuration includes a detection identifier, a recovery identifier, a record storage identifier, an active upload identifier, a fault waveform identifier, an event level, a message sending identifier, an automatic clearing identifier, and callback function parameters. The trigger threshold is an event trigger threshold, in the format of a digital or analog signal. When the event signal value is higher or lower than the trigger threshold, the corresponding event detection or event recovery is triggered. The trigger duration is used to record the event duration, counted by frequency. The fault position is used to identify the position of the corresponding event flag when the event is triggered. The event time is used to record the time when the event is triggered. The event status is used to record the current state of the event, obtained through state machine scanning. The event callback function is used to execute a preset action, i.e., the action executed when the event is triggered.

[0045] In step S10, the Eventdb class provides the EventManager class with storage API, export API, and clear API, supporting the storage, export, and clearing of event logs.

[0046] Step S20 specifically includes:

[0047] Step S21: After event initialization, the MCU checks whether the detection flag in the event detection data structure is enabled through the event detection function API. If yes, proceed to step S22; otherwise, end the process.

[0048] Step S22: Clear the original trigger duration and event status, and record them again;

[0049] Step S23: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S24; otherwise, proceed to step S22.

[0050] Step S24: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S25; otherwise, continue the statistics.

[0051] Step S25: Perform fault recording based on the fault recording identifier of the event detection data structure. Based on the priority corresponding to the event level, execute the preset action through the event callback function, synchronously record the event log including the event source, event trigger value and event time, cache the event log through the Ringbuffer class, and update the corresponding event flag based on the fault position, that is, set the corresponding event flag.

[0052] Step S30 specifically includes:

[0053] Step S31: After event initialization, the MCU checks whether the recovery flag in the event detection data structure is enabled through the event recovery API. If yes, proceed to step S32; otherwise, end the process.

[0054] Step S32: Clear the original trigger duration and event status, and record them again;

[0055] Step S33: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S34; otherwise, proceed to step S32.

[0056] Step S34: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S35; otherwise, continue the statistics.

[0057] Step S35: Based on the priority corresponding to the event level of the event detection data structure, execute the preset action through the event callback function, synchronously record the event log including the event source, event trigger value and event time, cache the event log through the Ringbuffer class, and clear the corresponding event flag based on the fault position order.

[0058] Step S40 specifically involves:

[0059] The MCU periodically checks whether the Ringbuffer class caches event logs through the event detection function API, stores the detected event logs in the database through the storage API of the Eventdb class, and stores them in Flash through the write API of the Flash class.

[0060] This invention takes into account both digital and analog signals, and flexibly configures the number of detections based on the trigger duration to achieve filtering. Different operations can be performed for different events, and the event callback function enables event diversification. Event logging further enhances subsequent analysis and processing, improves efficiency, and reduces MCU usage. Event recovery can also make events run automatically, reducing unnecessary subsequent redundant operations.

[0061] In summary, the advantages of this invention are:

[0062] By defining the EventManager, Eventdb, Flash, and Ringbuffer classes, event detection and processing are divided into 3 layers and 4 categories. The EventManager class sets the event detection data structure to unify the processing methods for different types of events. The trigger threshold format of the event detection data structure can be either a digital signal or an analog signal, allowing simultaneous processing of events corresponding to both digital and analog signals. During event processing, event logs including the event source, event trigger value, and event time are recorded synchronously, facilitating subsequent analysis. This not only saves fault location time but also reduces operation and maintenance costs. Furthermore, the recorded event logs are first cached using the Ringbuffer class and then stored using the Eventdb and Flash classes, effectively reducing interruption time, improving MCU utilization, and ultimately greatly enhancing the accuracy and efficiency of event detection and processing in embedded devices.

[0063] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An embedded device event detection and processing method, characterized in that: Includes the following steps: Step S10: Set up an EventManager class for setting up event detection data structure and event flags, providing event detection function API and event recovery API, an Eventdb class for storing event logs, a Flash class for providing Flash read API, write API and erase API, and a Ringbuffer class for caching event logs; The event detection data structure includes event storage configuration, trigger configuration, trigger threshold, trigger duration, fault sequence, event time, event status, and event callback function; The event storage configuration includes the event type and Flash storage identifier; the trigger configuration includes a detection identifier, recovery identifier, record storage identifier, active upload identifier, fault waveform identifier, event level, message sending identifier, automatic clearing identifier, and callback function parameters; the trigger threshold is the event trigger threshold, in digital or analog signal format; the trigger duration is used to record the event duration, counted by frequency; the fault position is used to identify the position of the corresponding event flag when the event is triggered; the event time is used to record the moment the event is triggered; the event status is used to record the current state of the event, obtained through state machine scanning; the event callback function is used to execute a preset action. Step S20: The event detection function API triggers the event detection function based on the enable signal, performs fault recording based on the event detection data structure and executes preset actions, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag; Step S30: The event recovery API triggers the event recovery function based on the enable signal, executes preset actions based on the event detection data structure, synchronously records the event log, caches the event log through the Ringbuffer class, and updates the event flag; Step S40: Store the cached event logs in the database using the Eventdb class and in Flash using the Flash class.

2. The embedded device event detection and processing method as described in claim 1, characterized in that: In step S10, the Eventdb class provides the EventManager class with storage API, export API, and clear API, supporting the storage, export, and clearing of event logs.

3. The embedded device event detection and processing method as described in claim 1, characterized in that: Step S20 specifically includes: Step S21: After event initialization, the MCU checks whether the detection flag in the event detection data structure is enabled through the event detection function API. If yes, proceed to step S22; otherwise, end the process. Step S22: Clear the original trigger duration and event status, and record them again; Step S23: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S24; otherwise, proceed to step S22. Step S24: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S25; otherwise, continue the statistics. Step S25: Perform fault recording based on the fault recording identifier of the event detection data structure, execute preset actions through the event callback function based on the priority corresponding to the event level, synchronously record event logs including event source, event trigger value and event time, cache event logs through the Ringbuffer class, and update the corresponding event flag based on the fault position.

4. The embedded device event detection and processing method as described in claim 1, characterized in that: Step S30 specifically includes: Step S31: After event initialization, the MCU checks whether the recovery flag in the event detection data structure is enabled through the event recovery API. If yes, proceed to step S32; otherwise, end the process. Step S32: Clear the original trigger duration and event status, and record them again; Step S33: Determine whether the current event meets the triggering conditions based on the triggering threshold. If yes, proceed to step S34; otherwise, proceed to step S32. Step S34: Based on the event duration statistics, determine whether the event duration has reached the trigger duration. If yes, proceed to step S35; otherwise, continue the statistics. Step S35: Based on the priority corresponding to the event level of the event detection data structure, execute the preset action through the event callback function, synchronously record the event log including the event source, event trigger value and event time, cache the event log through the Ringbuffer class, and clear the corresponding event flag based on the fault position order.

5. The embedded device event detection and processing method as described in claim 1, characterized in that: Step S40 specifically involves: The MCU periodically checks whether the Ringbuffer class caches event logs through the event detection function API, stores the detected event logs in the database through the storage API of the Eventdb class, and stores them in Flash through the write API of the Flash class.

Images