Event-driven embedded software architecture implementation method and system

Abstract

The application relates to the technical field of industrial control automation, and discloses an event-driven embedded software architecture implementation method and system, which comprises the following steps: creating a resource object priority group and initializing a data structure for managing theme subscription states; allocating priorities to resource objects in a system and registering each resource object in a priority group corresponding to the priority; subscribing to a theme for a resource object and recording subscription information in the data structure for managing theme subscription states; creating an event object containing a theme identifier in response to an event trigger condition, determining priority group information of subscribing to the theme based on the data structure for managing theme subscription states, and adding the event object to a to-be-processed queue; polling each priority group according to priority sorting, retrieving event objects subscribed by each priority group, and calling an event processing function of a corresponding resource object for processing; and the architecture realized through the above method reduces the coupling between modules.

Description

Technical Field

[0001] This invention relates to the field of industrial control automation technology, and in particular to an event-driven embedded software architecture implementation method and system. Background Technology

[0002] Currently, embedded systems have deeply penetrated the fields of industrial control, IoT terminals, and smart devices. Especially in resource-constrained microcontroller (MCU) scenarios, their software architecture design directly determines the system's real-time performance, maintainability, and scalability. Traditional software architectures are increasingly struggling to cope with requirements such as multi-module collaboration and asynchronous event triggering. For example, in industrial automated production lines, tasks such as sensor data acquisition, motor control, and safety monitoring need to respond within milliseconds, while each module must evolve independently to adapt to production line upgrades. This poses a severe challenge to the decoupling capability and real-time scheduling of the software architecture.

[0003] In existing technologies, embedded software primarily relies on two architectural patterns: sequential execution architecture (superloop) and time-slice-based scheduling architecture. The former employs a linear task loop execution mechanism, where all functional modules are called sequentially within a single main loop. While simple to implement, this architecture suffers from strong coupling between modules—blockage or delay in any module leads to a lag in the entire system's response, and adding new features requires intrusive modifications to the main loop structure, significantly increasing later maintenance costs. The latter allocates CPU resources through fixed time slices, achieving multi-task concurrency to some extent, but its portability to bare-metal environments without an operating system is extremely difficult, and it cannot dynamically adjust scheduling strategies based on task importance. For example, critical safety interrupt events may fail to respond promptly due to waiting for time slices, while low-priority background tasks consume redundant computing resources. More significantly, both architectures lack flexible event response mechanisms: modules communicate via global variables or direct function calls, resulting in chaotic state management, complex interface dependencies, and the inability to distribute external inputs (such as sensor signals) to processing units as needed.

[0004] The inherent flaws of the aforementioned architecture are further exposed in resource-constrained scenarios. First, excessive module coupling makes functional expansion difficult: adding communication protocols or control algorithms to industrial equipment requires refactoring a large amount of interface code, and modifications may trigger unpredictable chain reactions of errors. Second, insufficient real-time performance guarantees: urgent tasks (such as equipment emergency stop commands) are delayed due to the inability to preempt lower-priority tasks, potentially causing safety accidents in high-speed production lines. Third, a conflict between resource consumption and portability: lightweight MCUs struggle to support real-time operating systems (RTOS), while in bare-metal environments, developers must manually implement task scheduling and communication mechanisms, significantly increasing development time and debugging risks. Although existing technologies attempt to introduce event-driven models, without a unified priority scheduling framework and efficient memory management support, event stacking and message passing are still prone to memory overflow or processing delays.

[0005] Therefore, the industry urgently needs an embedded software architecture that balances real-time performance, loose coupling, and resource efficiency, capable of decoupling module dependencies through an event-driven mechanism in an MCU environment without an operating system, and achieving dynamic priority scheduling based on task importance, thereby supporting highly reliable applications in key areas such as industrial control. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of the existing technology and provide an event-driven embedded software architecture implementation method and system. By studying the event publishing / subscription mechanism, priority allocation algorithm and memory heap management scheme, an event-driven mechanism framework is designed, providing an alternative solution that differs from traditional task scheduling for resource-constrained MCUs.

[0007] On the one hand, an event-driven embedded software architecture implementation method is provided, including the following steps:

[0008] S1: Create multiple priority groups of resource objects with different priorities, and initialize the data structure used to manage the topic subscription state;

[0009] S2: Assign priorities to resource objects in the system, register each resource object to its corresponding priority group, and record the existence status of active resource objects;

[0010] S3: Subscribe to one or more topics for a resource object, and record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status;

[0011] S4: In response to the event triggering condition, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue;

[0012] S5: Poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask.

[0013] Further, in step S1, initializing the data structure used to manage the topic subscription state includes:

[0014] The topic pool is initialized based on macro definitions in the configuration file. The topic pool includes multiple topics, each with a unique topic identifier. The topic pool is used to record the subscription status of each topic. The topic pool is implemented through an array of integer types, where the array index corresponds to a unique topic identifier, each element of the array corresponds to a bitmap variable, and each bit of the bitmap variable corresponds to a priority group, used to indicate whether the priority group has subscribed to the topic at that index.

[0015] At the same time, the registration bitmap variable of the resource object priority group is initialized. Each bit of the registration bitmap variable corresponds to a priority group, and the bit value indicates whether the priority group contains an active resource object.

[0016] Further, in step S2, registering each resource object to its corresponding priority group includes:

[0017] Add the resource object to the resource object management list of its corresponding priority group, and update the global active object state bitmap variable, setting the bit of its corresponding priority group to the value representing the active state;

[0018] Once a resource object is registered, it is called an active object, and the state of an active object is maintained independently.

[0019] Further, in step S3, subscribing to one or more topics for the resource object includes:

[0020] The topic identifiers are stored sequentially in the topic management array of the resource object, recording all topics subscribed to by the object;

[0021] Based on the priority of the resource object and the subscribed topic identifier, update the bitmap of the array element corresponding to the topic identifier in the topic pool, and set the bit of the corresponding priority group to the value representing the subscription status.

[0022] Further, in step S4, creating an event object containing a topic identifier includes:

[0023] Allocate storage space from the pre-allocated memory heap for the event object and any additional data thereon; the event object contains at least a topic identifier and a subscription mask bitmap.

[0024] The subscription mask bitmap is set based on the subscription status bitmap corresponding to the topic identifier in the topic pool. Each bit corresponds to a priority group, which indicates whether the priority group has subscribed to the topic of this event. After the event object is created, its subscription mask bitmap is decoupled from the topic pool status and maintained independently.

[0025] Preferably, in step S4, the event triggering condition includes:

[0026] A hardware interrupt occurs, a timer times out, or a resource object actively publishes a new event while executing its business logic.

[0027] Furthermore, step S4 also includes timer management, specifically including:

[0028] Set up a timer object, and associate it with a topic identifier, timeout time, and timer type;

[0029] The system clock tick is updated in the timer interrupt handling. When the system clock tick is updated, the timer is checked for timeout. The timer objects are traversed. For timers that have timed out, an event is published based on their associated topic identifier. If the timer type is a loop type, its timeout time is reset. A relative time overlay mechanism is used to avoid time drift.

[0030] Furthermore, in step S5, the process of calling the event handling function of the corresponding resource object includes the following steps:

[0031] S51: Determine whether an active resource object currently exists based on the activity object state bitmap variable;

[0032] S52: Publish events to expired timers in the timer management module and store the events in the event object pool;

[0033] S53: For each priority group, determine whether an event needs to be processed based on the active object state bitmap and the global event state bitmap. Each bit of the global event state bitmap indicates whether a priority group has an event to be processed.

[0034] S54: Retrieve the event objects subscribed to by this priority group from the event object pool, update the subscription mask of the event objects, and clear the corresponding bits of the subscription mask to zero using atomic operations;

[0035] S55: Traverse the resource objects in the priority group, determine whether the resource object has subscribed to the event topic based on the topic management array, and if so, call the event handling function to handle the event;

[0036] S56: Manage the lifecycle of event objects based on subscription masks, including:

[0037] After the event is processed, the memory of the event object is released based on whether the subscription mask of the event object is zero. If the subscription mask is zero, the memory space of the event object is released; otherwise, the event object is reserved for processing by other priority groups, and memory release operations are prohibited during this period.

[0038] Step S54 further includes:

[0039] Maintain a global event state bitmap variable, where each bit corresponds to a priority group, used to indicate whether there are any pending events in that priority group;

[0040] After retrieving the event objects, the total number of event objects in the priority group is decremented. When the total number of event objects is zero, the bit corresponding to the priority group in the global event state bitmap is cleared to zero, indicating that there are no events to be processed in that priority group.

[0041] Preferably, the method further includes:

[0042] The resource objects adopt the Actor concurrency model, and event objects are passed between resource objects as messages. Resource objects process messages through event handling functions to achieve inversion of control.

[0043] By locating the highest priority activity group through hardware instructions, instruction-level acceleration of scheduling decisions is achieved;

[0044] After the memory of an event object is released, its memory address is immediately reclaimed to a lightweight free list in the pre-allocated memory heap to avoid dynamic allocation fragmentation.

[0045] On the other hand, an event-driven embedded software architecture implementation system is provided, including:

[0046] The initialization module is used to create multiple priority groups of resource objects with different priorities and to initialize the data structures used to manage topic subscription status.

[0047] The resource object registration module is used to assign priorities to resource objects in the system, register each resource object to the priority group corresponding to its priority, and record the existence status of active resource objects.

[0048] The topic subscription module is used to subscribe to one or more topics for a resource object, and to record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status.

[0049] The event publishing module is used to respond to event triggering conditions, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue.

[0050] The event scheduling and processing module is used to poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask.

[0051] Compared with the prior art, the beneficial effects of the present invention are:

[0052] This invention utilizes an event publish / subscribe mechanism and an Actor model, allowing resource objects to interact solely through message passing. This eliminates dependencies on global variables and direct function calls. When adding new functional modules, it is only necessary to independently subscribe to the topic and register the resource object, without modifying the core framework or other module code, thus significantly reducing the iteration cost of embedded software.

[0053] This invention is based on a priority group scheduling strategy. The high-priority group where the emergency task is located polls the event first, and the bitmap state variable is used to detect the event to be processed in real time, so as to ensure that critical events such as interrupts and timers are processed in milliseconds, which meets the hard real-time requirements of industrial control scenarios.

[0054] This invention uses a lightweight bitmap to manage active objects and subscription states, replacing the task control block of the traditional OS. It manages the lifecycle of event objects through a unified memory heap, thus avoiding dynamic memory fragmentation.

[0055] The resource objects of this invention can be registered / unregistered at runtime, topic subscription relationships are dynamically updated, priority groups and topic pools are initialized through macro definitions in configuration files, and developers only need to adjust the configuration to reconstruct task priorities and event routing logic without redesigning the architecture.

[0056] This invention automatically tracks the valid subscription groups of event objects based on a subscription mask bitmap. When all subscription groups have been processed, the memory is released immediately. At the same time, combined with a timer-driven event timeout mechanism, invalid events are cleaned up in a timely manner, avoiding the risk of memory overflow in resource-constrained MCUs. Attached Figure Description

[0057] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0058] Figure 1 This is a flowchart of an event-driven embedded software architecture implementation method according to the present invention;

[0059] Figure 2 This invention provides an event subscription sequence diagram.

[0060] Figure 3 This is an event publishing sequence diagram of the present invention;

[0061] Figure 4 This is a sequence diagram for resource object registration according to the present invention;

[0062] Figure 5 This is a flowchart of an event-driven architecture according to the present invention. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0064] This invention manages resource objects in the system through priority groups, using the Actor pattern to represent resource objects. Based on the real-time nature and importance of each object, it is assigned to different priority groups, and a linked list is used to implement the addition and deletion of resource objects. Each type of event has a unique topic, and resource objects in different priority groups can subscribe to events on the same topic. For different resource objects subscribed to the same event, each object will handle the event in a diverse manner based on its own state. Finally, the system employs a feasible memory heap scheme to manage the entire lifecycle of events.

[0065] The specific embodiments of the present invention will be described below with reference to the accompanying drawings and examples.

[0066] Example 1

[0067] First, this embodiment will mention Actor, Event, Reactor, Inversion of Control (IoC), and Publish / Subscribe. An Actor is a concurrent programming model that enables communication between two objects through message passing. Each object has its own state and behavior, and they interact by sending messages without sharing memory, avoiding the complexity and performance overhead of locking. An Event is a combination of external signals, state changes, or specific conditions that occur in an embedded system. A Reactor is an event-driven programming model primarily used for handling I / O and timers, aiming to distribute ready events to the processor for processing. Inversion of Control (IoC) is a software design principle whose core idea is to invert the traditional program flow control, entrusting the parts originally controlled by the program itself to the framework for management. Publish / Subscribe is a commonly used message passing pattern that allows decoupling between message senders (publishers) and receivers (subscribers).

[0068] First, before starting application programming, platform porting must be performed, including: writing functions to enable and disable the global interrupt based on the actual environment of the MCU hardware; configuring a general hardware timer or a SysTick timer for the MCU, and calling the system clock tick update function in its interrupt handler function.

[0069] Then we proceed with application programming, specifically, such as... Figure 1As shown, this embodiment provides a technical solution for implementing an event-driven embedded software architecture, which includes the following steps:

[0070] S1: Create multiple priority groups of resource objects with different priorities, and initialize the data structure used to manage the topic subscription state;

[0071] S2: Assign priorities to resource objects in the system, register each resource object to its corresponding priority group, and record the existence status of active resource objects;

[0072] S3: Subscribe to one or more topics for a resource object, and record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status;

[0073] S4: In response to the event triggering condition, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue;

[0074] S5: Poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask.

[0075] Unlike traditional architectures that use sequential execution and time-slice rotation, this approach implements an event-driven architecture that reduces coupling between modules in a project and lowers the complexity of embedded software systems through inversion of control and event-driven mechanisms.

[0076] In step S1, initializing the data structure used to manage the topic subscription state includes:

[0077] The topic pool is initialized based on macro definitions in the configuration file. The topic pool includes multiple topics, each with a unique topic identifier. The topic pool is used to record the subscription status of each topic. The topic pool is implemented through an array of integer types, where the array index corresponds to a unique topic identifier, each element of the array corresponds to a bitmap variable, and each bit of the bitmap variable corresponds to a priority group, used to indicate whether the priority group has subscribed to the topic at that index.

[0078] At the same time, the registration bitmap variable of the resource object priority group is initialized. Each bit of the registration bitmap variable corresponds to a priority group, and the bit value indicates whether the priority group contains an active resource object.

[0079] Specifically, the system initializes various resources according to macro definitions in the configuration file, including resource objects, memory heap, timer resource management, and event management. For ease of management, resource objects are divided into groups, and each group is assigned a different priority. The architecture implemented by the method of this invention mainly consists of a control center, resource object management, memory heap management, event management, and timer management.

[0080] In this embodiment, the priority range is limited to 0-31, with lower values ​​indicating higher priority. A 4-byte integer variable, `actor_exist`, is used to register resource object groups. Each bit in `actor_exist` corresponds to a priority group, with lower bit-related object groups having higher priority than higher bit-related object groups. Each resource object group can hold multiple objects using a linked list. When a bit in this variable is 1, it indicates that a resource object in the corresponding priority group has already been registered and become active.

[0081] In addition, the topic pool is initialized according to the topic subscription capacity macro definition in the configuration file. The topic pool is a 4-byte integer array, where the array index is the topic identifier. Each element of the array records the different priority groups subscribing to this topic. Each bit in the element corresponds one-to-one with the priority of the resource object group. A bit value of 1 indicates that an active object in the corresponding priority group has subscribed to this topic. When a resource object subscribes to a topic, the maximum value of the topic identifier is the array length of the topic pool minus one.

[0082] Next, in step S2, registering each resource object to its corresponding priority group includes:

[0083] Add the resource object to the resource object management list of its corresponding priority group, and update the global active object state bitmap variable, setting the bit of its corresponding priority group to the value representing the active state;

[0084] Once a resource object is registered, it is called an active object, and the state of an active object is maintained independently.

[0085] Detailed registration process as follows Figure 4 As shown, in this embodiment, various resource objects are initialized, and different priorities are assigned to each resource object. Resource objects are registered by attaching them to the linked list of the corresponding resource object priority group according to their priorities. The topic management array in the resource object is set to zero. The registered resource object is also called the active object. In the variable actor_exist, the priority group of the resource object is registered by setting the bit corresponding to the priority value to 1.

[0086] Next, step S3 is performed, wherein subscribing to one or more topics for the resource object includes:

[0087] The topic identifiers are stored sequentially in the topic management array of the resource object, recording all topics subscribed to by the object;

[0088] Based on the priority of the resource object and the subscribed topic identifier, update the bitmap of the array element corresponding to the topic identifier in the topic pool, and set the bit of the corresponding priority group to the value representing the subscription status.

[0089] like Figure 2 As shown, in this embodiment, a topic is a 2-byte integer identifier. Different topics can be subscribed to by resource objects, and the topics are stored in the topic management array of the resource object in ascending order. The total number of topics subscribed to by the resource object is also accumulated. Furthermore, the corresponding members in the topic pool are set according to the object priority value and the topic identifier, recording the subscription status of each topic by each resource priority group.

[0090] Next, proceed to step S4, where creating an event object containing a topic identifier includes:

[0091] Allocate storage space from the pre-allocated memory heap for the event object and any additional data thereon; the event object contains at least a topic identifier and a subscription mask bitmap.

[0092] The subscription mask bitmap is set based on the subscription status bitmap corresponding to the topic identifier in the topic pool. Each bit corresponds to a priority group, which is used to indicate whether the priority group has subscribed to the topic of this event.

[0093] Secondly, the event triggering conditions include:

[0094] A hardware interrupt occurs, a timer times out, or a resource object actively publishes a new event while executing its business logic.

[0095] Step S4 also includes timer management, specifically including:

[0096] Set up a timer object, and associate it with a topic identifier, timeout time, and timer type;

[0097] In the timer interrupt handling, update the system clock tick. When the system clock tick is updated, check if the timer has timed out. Traverse the timer objects. For timers that have timed out, publish an event based on their associated topic identifier. If the timer type is a loop type, reset its timeout.

[0098] Specifically, such as Figure 3As shown, in this embodiment, we associate an event handling function with each resource object. In the handling function, we execute the corresponding business processing flow according to the topic identifier of the function parameter. In the business processing flow, the resource object can publish topic events to the outside world as needed.

[0099] Then, events with topic identifiers and additional data are published in interrupt handling, timer timeout, and resource object Actor business processing. Space and additional data are allocated for the event object from the memory manager, the event object (topic identifier) ​​is initialized, and the member subscription mask bitmap variable `sub_mask` and the global event state bitmap variable `sub_general` are set according to the priority groups subscribed to this topic in the topic pool. Both variables are 4-byte integers. At the same time, the total number of event objects subscribed to each priority group of this topic is incremented by one.

[0100] Based on the subject identifier, timeout, and type (loop or single), set the timer object in the timer array; in the hardware timer interrupt handler, call the clock tick update function to update the system time tick.

[0101] Iterate through the timer array, publish events based on the subject identifiers of the timers that have expired, and reset the timeout for the loop-type timer objects.

[0102] Finally, proceed to step S5, where calling the event handling function of the corresponding resource object for processing includes the following steps:

[0103] S51: Determine whether an active resource object currently exists based on the activity object state bitmap variable;

[0104] S52: Publish events to expired timers in the timer management module and store the events in the event object pool;

[0105] S53: For each priority group, determine whether an event needs to be processed based on the active object state bitmap and the global event state bitmap. Each bit of the global event state bitmap indicates whether a priority group has an event to be processed.

[0106] S54: Retrieve the event objects subscribed to by this priority group from the event object pool, update the subscription mask of the event objects, and clear the corresponding bits of the subscription mask to zero;

[0107] S55: Traverse the resource objects in the priority group, determine whether the resource object has subscribed to the event topic based on the topic management array, and if so, call the event handling function to handle the event;

[0108] S56: Manage the lifecycle of event objects based on subscription masks, including:

[0109] After the event processing is completed, the memory of the event object is released based on whether the subscription mask of the event object is zero. If the subscription mask is zero, the memory space of the event object is released; otherwise, the event object is reserved for processing by other priority groups.

[0110] Step S54 further includes:

[0111] Maintain a global event state bitmap variable, where each bit corresponds to a priority group, used to indicate whether there are any pending events in that priority group;

[0112] After retrieving the event objects, the total number of event objects in the priority group is decremented. When the total number of event objects is zero, the bit corresponding to the priority group in the global event state bitmap is cleared to zero, indicating that there are no events to be processed in that priority group.

[0113] Specifically, in this embodiment, events are processed for each object in each resource object group in a round-robin fashion, prioritizing them from high to low (0~31). The process is as follows:

[0114] ① Check if the variable actor_exist is 0 to determine if there is currently an active resource object. If it is 0, then there is currently no resource object registered in the system.

[0115] ② In timer management, for timers that have expired, publish an event with the timer topic identifier; store the event in the event object pool.

[0116] ③ Based on priority from high to low, determine whether there are active resource objects in the current priority group by checking if the bit corresponding to the core global state variable `actor_exist` is set to 1. If there are active objects in the current priority group, determine whether the resource objects in the current priority group need to handle events by checking if the bit corresponding to the global event state bitmap `sub_general` is set to 1. The resource object priority group is obtained through these two checks.

[0117] ④ Traverse the event object pool (event publishing is essentially stored in the event object pool) and find the event objects subscribed to by active objects in the above priority groups. In the event object member variable subscription mask bitmap sub_mask, set the bit corresponding to that priority group to zero. The total number of event objects in the priority group is decremented by one. When the total number of event objects in this priority group is zero, the bit corresponding to that priority group in the variable global event state bitmap sub_general is set to zero, indicating that there are currently no further events to process in the current priority group.

[0118] ⑤ Iterate through each active object in the resource priority group. Determine whether to subscribe to events for this topic from the object's topic management array. Then, call the object's event handler function to process this event object.

[0119] ⑥ Check if the event object's member variable sub_mask is zero; if it is not zero, it means that there are active objects in other resource object priority groups that have subscribed to the topic of this event; otherwise, the memory space allocated by the event object should be released.

[0120] ⑦ Execute each step in the process repeatedly.

[0121] Therefore, the above methods also include:

[0122] The resource objects adopt the Actor concurrency model, and event objects are passed between resource objects as messages. Resource objects process messages through event handling functions to achieve inversion of control.

[0123] By locating the highest priority activity group through hardware instructions, instruction-level acceleration of scheduling decisions is achieved;

[0124] After the memory of an event object is released, its memory address is immediately reclaimed to a lightweight free list in the pre-allocated memory heap to avoid dynamic allocation fragmentation.

[0125] In summary, the overall time-driven architecture process is as follows: Figure 5 As shown. Using the methods described above, we studied the event publish / subscribe mechanism, priority allocation algorithm, and memory heap management scheme, and designed a framework for an event-driven mechanism, providing an alternative to traditional task scheduling for resource-constrained MCUs.

[0126] On the other hand, an event-driven embedded software architecture implementation system is provided, including:

[0127] The initialization module is used to create multiple priority groups of resource objects with different priorities and to initialize the data structures used to manage topic subscription status.

[0128] The resource object registration module is used to assign priorities to resource objects in the system, register each resource object to the priority group corresponding to its priority, and record the existence status of active resource objects.

[0129] The topic subscription module is used to subscribe to one or more topics for a resource object, and to record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status.

[0130] The event publishing module is used to respond to event triggering conditions, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue.

[0131] The event scheduling and processing module is used to poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask.

[0132] It should be noted that the steps in the event-driven embedded software architecture implementation method provided in this embodiment can be implemented based on the corresponding modules in the event-driven embedded software architecture implementation system. Those skilled in the art can refer to the technical solution of the system to implement the steps of the method. That is, the embodiment in the system can be understood as a preferred example of implementing the method, and will not be elaborated here.

[0133] Besides implementing the system and its various devices provided by this invention in purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the system and its various devices of this invention appear as logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices provided by this invention can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0134] Finally, it should be noted that the above description is only a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be pointed out that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A method for implementing an event-driven embedded software architecture, characterized in that, Includes the following steps: S1: Create multiple priority groups of resource objects with different priorities, and initialize the data structure used to manage the topic subscription state; S2: Assign priorities to resource objects in the system, register each resource object to its corresponding priority group, and record the existence status of active resource objects; S3: Subscribe to one or more topics for a resource object, and record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status; S4: In response to the event triggering condition, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue; S5: Poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask; In step S5, the process of calling the event handling function of the corresponding resource object includes the following steps: S51: Determine whether an active resource object currently exists based on the active object state bitmap variables; S52: Publish events to expired timers in the timer management module and store the events in the event object pool; S53: For each priority group, determine whether an event needs to be processed based on the active object state bitmap and the global event state bitmap. Each bit of the global event state bitmap indicates whether a priority group has an event to be processed. S54: Retrieve the event objects subscribed to by this priority group from the event object pool, update the subscription mask of the event objects, and clear the corresponding bits of the subscription mask to zero using atomic operations; S55: Traverse the resource objects in the priority group, determine whether the resource object has subscribed to the event topic based on the topic management array, and if so, call the event handling function to handle the event; S56: Manage the lifecycle of event objects based on subscription masks, including: After the event is processed, the memory of the event object is released based on whether the subscription mask of the event object is zero. If the subscription mask is zero, the memory space of the event object is released; otherwise, the event object is reserved for processing by other priority groups, and memory release operations are prohibited during this period.

2. The event-driven embedded software architecture implementation method according to claim 1, characterized in that, In step S1, initializing the data structure used to manage the topic subscription state includes: The topic pool is initialized based on macro definitions in the configuration file. The topic pool includes multiple topics, each with a unique topic identifier. The topic pool is used to record the subscription status of each topic. The topic pool is implemented through an array of integer types, where the array index corresponds to a unique topic identifier, each element of the array corresponds to a bitmap variable, and each bit of the bitmap variable corresponds to a priority group, used to indicate whether the priority group has subscribed to the topic at that index. At the same time, the registration bitmap variable of the resource object priority group is initialized. Each bit of the registration bitmap variable corresponds to a priority group, and the bit value indicates whether the priority group contains an active resource object.

3. The event-driven embedded software architecture implementation method according to claim 2, characterized in that, In step S2, registering each resource object to its corresponding priority group includes: Add the resource object to the resource object management list of its corresponding priority group, and update the global active object state bitmap variable, setting the bit of its corresponding priority group to the value representing the active state; Once a resource object is registered, it is called an active object, and the state of an active object is maintained independently.

4. The event-driven embedded software architecture implementation method according to claim 1, characterized in that, In step S3, subscribing to one or more topics for a resource object includes: The topic identifiers are stored sequentially in the topic management array of the resource object, recording all topics subscribed to by the object; Based on the priority of the resource object and the subscribed topic identifier, update the bitmap of the array element corresponding to the topic identifier in the topic pool, and set the bit of the corresponding priority group to the value representing the subscription status.

5. The event-driven embedded software architecture implementation method according to claim 3, characterized in that, In step S4, creating an event object containing a topic identifier includes: Allocate storage space from the pre-allocated memory heap for the event object and any additional data thereon; the event object contains at least a topic identifier and a subscription mask bitmap. The subscription mask bitmap is set based on the subscription status bitmap corresponding to the topic identifier in the topic pool. Each bit corresponds to a priority group, which indicates whether the priority group has subscribed to the topic of this event. After the event object is created, its subscription mask bitmap is decoupled from the topic pool status and maintained independently.

6. The event-driven embedded software architecture implementation method according to claim 5, characterized in that, In step S4, the event triggering conditions include: A hardware interrupt occurs, a timer times out, or a resource object actively publishes a new event while executing its business logic.

7. The event-driven embedded software architecture implementation method according to claim 6, characterized in that, Step S4 also includes timer management, specifically including: Set up a timer object, and associate it with a topic identifier, timeout time, and timer type; The system clock tick is updated in the timer interrupt handling. When the system clock tick is updated, the timer is checked for timeout. The timer objects are traversed. For timers that have timed out, an event is published based on their associated topic identifier. If the timer type is a loop type, its timeout time is reset. A relative time overlay mechanism is used to avoid time drift.

8. The event-driven embedded software architecture implementation method according to claim 1, characterized in that, Step S54 also includes: Maintain a global event state bitmap variable, where each bit corresponds to a priority group, used to indicate whether there are any pending events in that priority group; After retrieving the event objects, the total number of event objects in the priority group is decremented. When the total number of event objects is zero, the bit corresponding to the priority group in the global event state bitmap is cleared to zero, indicating that there are no events to be processed in that priority group.

9. The event-driven embedded software architecture implementation method according to claim 3, characterized in that, The method further includes: The resource objects adopt the Actor concurrency model, and event objects are passed between resource objects as messages. Resource objects process messages through event handling functions to achieve inversion of control. By locating the highest priority activity group through hardware instructions, instruction-level acceleration of scheduling decisions is achieved; After the memory of an event object is released, its memory address is immediately reclaimed to a lightweight free list in the pre-allocated memory heap to avoid dynamic allocation fragmentation.

10. A system implementing an event-driven embedded software architecture, characterized in that, include: The initialization module is used to create multiple priority groups of resource objects with different priorities and to initialize the data structures used to manage topic subscription status. The resource object registration module is used to assign priorities to resource objects in the system, register each resource object to the priority group corresponding to its priority, and record the existence status of active resource objects. The topic subscription module is used to subscribe to one or more topics for a resource object, and to record information about each topic being subscribed to by different priority groups in the data structure that manages the topic subscription status. The event publishing module is used to respond to event triggering conditions, create an event object containing a topic identifier, determine the priority group information for subscribing to the topic based on the data structure for managing the topic subscription status, and add the event object to the pending queue. The event scheduling and processing module is used to poll each priority group in descending order of priority, retrieve the event objects subscribed to by each priority group, call the event handling function of the corresponding resource object for processing, and manage the lifecycle of the event objects based on the subscription mask. The process of calling the event handler function of the corresponding resource object includes the following steps: S51: Determine whether an active resource object currently exists based on the active object state bitmap variables; S52: Publish events to expired timers in the timer management module and store the events in the event object pool; S53: For each priority group, determine whether an event needs to be processed based on the active object state bitmap and the global event state bitmap. Each bit of the global event state bitmap indicates whether a priority group has an event to be processed. S54: Retrieve the event objects subscribed to by this priority group from the event object pool, update the subscription mask of the event objects, and clear the corresponding bits of the subscription mask to zero using atomic operations; S55: Traverse the resource objects in the priority group, determine whether the resource object has subscribed to the event topic based on the topic management array, and if so, call the event handling function to handle the event; S56: Manage the lifecycle of event objects based on subscription masks, including: After the event is processed, the memory of the event object is released based on whether the subscription mask of the event object is zero. If the subscription mask is zero, the memory space of the event object is released; otherwise, the event object is reserved for processing by other priority groups, and memory release operations are prohibited during this period.

Images