This article explains the event-based software architecture, its advantages, and possible disadvantages for the development of embedded systems.
IMT has successfully used the event-based software architecture approach in many development projects. Since this architecture style has proven to be very successful, in recent years we have also implemented an event-based runtime – “DATAFLOW Runtime” and an event-based software design tool “DATAFLOW Designer” to be even more efficient in device development. This now also enables our customers to easily apply the event-based approach to their own software projects.
In this article, the event-based software architecture is presented in more detail. This architecture style is one of many different styles, which have developed since the beginnings of software architecture in the 1960s, besides for example
The event-based architecture style is particularly strong in embedded development. This may be due to the following special requirements and limitations of embedded systems:
Many important decisions about an embedded project are already made when an ideal software architecture is selected. They shape the project over its entire lifetime and often determine its success or failure. Of course, any application can be implemented with most of the currently popular architecture styles. However, the requirements can often not be met with some architecture styles. This means that the quality of the resulting software is therefore significantly influenced by the choice of architecture or the ideal architecture style.
This can be illustrated very well with the following example.
If an application needs to be able to react to external events, then this can be done with any architectural style. When the requirement is that the application must react to events in a timely and time-critical manner, then a layer architecture based on the layering architecture style is probably the wrong choice. This is because in a layered architecture, events can be received on a hardware-related layer – but the reaction to the event then usually happens on one of the higher (application) layers. This passing through different layers is time-consuming. An event-based architecture is certainly the better choice for any time-critical applications.
An event-based or event-driven architecture responds to events in the software system and differs from ordinary architectures that respond to requests. An event is any significant occurrence or change in the state of the system hardware or software. The source of an event can be internal or external. Events can be generated by a user (e.g., mouse click or key press), by an external source (e.g., sensor output), or by the system (e.g., loading a program). They are reported to the software by hardware interrupts. Furthermore, the software can also generate events itself. For example, to signal an important time event (by a timer).
An event-based software consists of the «event producer» and the «event consumer». The event producer creates an event and registers it in the system. He knows neither the reaction to this event nor the event consumer. The event consumer processes one or more events and runs a reaction. The interface between Event-Producer and Event-Consumer can be realized by an implementation of the Publish/Subscribe Pattern . This central piece of software can be called, for example, «event channel». The event channel knows the events in the system and enables the event consumer to register for certain events. An event is thus detected by an event producer and then reported to the event channel. The event channel informs all event consumers about events to which the respective consumer is registered.
The approach of an event-based system can be implemented with various programming languages and is mostly independent of the technology.
Figure 1: Example class diagram of an event-based architecture
2.1 What quality characteristics can be ensured by using the event-based architecture style?
As described above, the selected architecture style is responsible for the quality of the software. According to ISO 25010, the software quality characteristics are defined as follows.
Figure 2: ISO 25010 software quality features
The event-based architecture mainly influences the characteristics reliability, security, efficiency, maintainability, and portability. The usability of a software system (also referred to as usability) is largely determined by the user interface design. The specified functionality can be implemented with different architecture styles and must be ensured independently of the architecture by verification and validation.
2.2 Why is the event-based approach particularly well suited for embedded systems?
The event-based architecture primarily addresses features such as:
Embedded systems very often have special requirements and limitations. We have already touched on these in the introduction:
The high correlation between the special characteristics of the event-based architecture and the requirements of embedded systems thus supports the thesis established at the beginning. The event-based architecture style is therefore particularly often represented in embedded development because it can excel in the special requirements of embedded systems, especially the efficiency in event-based systems.
Where does the event-based architectural style have its limitations?
An event-based architecture style can reach its limits, especially with large and complex systems. In such cases, complicated event structures can arise, which could generate non-obvious or cyclical dependencies. In addition, large numbers of events can be generated by such systems, the processing of which must be ensured – without running into a “denial of service”.
Remedy for the simplification with complex systems could supply the combination of several architecture styles. For example, a component-oriented architecture style could therefore be used together with an event-based architecture style. As a result, a better structuring of the software is obtained, without having to sacrifice the advantages of the event-based architecture. This means that the communication between the components continues to run via events.
At IMT we have been successfully using an event-based architecture for the implementation of firmware for embedded systems for over 20 years. During this time, we have made our know-how available to our customers in the form of our DATAFLOW Runtime and DATAFLOW Designer products.
The DATAFLOW Runtime is an event-based embedded scheduler that can be executed on embedded processors (such as ARM Cortex-M) without the need for an additional operating system (bare metal). The functionality of the firmware is implemented using the Active Object Design Pattern  , where the objects in DATAFLOW are called Active Parts.
Figure 3: Screenshot of DATAFLOW example
An Active Part can generate an event as an Event Producer. The Active Parts are connected via channels, so that the Consumer is informed about the event and can react accordingly. Furthermore, it is also possible to generate events via software or hardware timers. Hardware interrupts are also integrated into this event system. This allows the software developer to implement and test the complete functionality of the firmware event-based.
By assigning priorities in the Active Parts, the temporary behavior can be precisely defined. Preemptive multitasking  is supported by the bare metal scheduler. When using an RTOS scheduler, the Active Part priorities are seamlessly integrated into the RTOS priorities. Time slice scheduling is also possible if supported by the RTOS used.
With the help of DATAFLOW Designer the breaking down of firmware into active parts, the definition of events as well as the definition of channels can be done graphically on a PC. A code generator ensures that the graphical representation always matches the created software and the developer can focus on implementing the functionality.
For more details on DATAFLOW, please visit our website.
It is no longer possible to imagine software development without event-based architecture. The popular IoT devices, which usually have to be very energy-efficient and real-time capable, are often implemented with an event-based architecture. As the event-based approach is well suited to real-time requirements and can also ideally cover the following quality features, the event-based architecture style is particularly popular in the embedded area.
Of course, the event-based architecture style is also used frequently and successfully at IMT. IMT AG even goes one step further and has developed an event-based real-time operating system “DATAFLOW Runtime” and a design tool for event-based architectures paired with component-oriented architectures.
With this tool suite, systems can be modeled and implemented using event-based architecture. The user is optimally supported in the graphical user interface and appropriate measures ensure that certain rules of event-based architectures are maintained. For example, the user is warned if inputs or outputs have not been connected, protocols for messages have not been defined, outgoing ports have been connected to multiple inputs, and much more. Thanks to these tools, not only the quality of the application software was additionally increased. The development process was also further optimized thanks to the automatic code generation, coherent system designs and an efficient maintainability. The high development effort that went into the DATAFLOW software is paying off, as new projects can be implemented more efficiently and hence more cost-effectively thanks to DATAFLOW.
Do you have further questions, or would you like to benefit from the advantages of DATAFLOW software? Then contact us for a presentation or test our 30-day demo version.
Leave your e-mail address here and we will inform you as soon as we publish new contributions.