Why is an event-based software architecture preferred in embedded system development?

1. Why is it important to choose the right architectural style?

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.

2. Event-based software architecture

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 [1]. 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.

Reliability

• Advantages
  An event-based architecture uses a proven architecture style with a high degree of fault tolerance that has already proven successful in many software projects.  Responsibilities are clearly defined through “separation of concerns”. This is why event-based architectures are also very common in the high-level area (cloud architectures, enterprise computing) and are often known as microservice architectures. The big advantage are the parts of the software which can be developed separately. This this separation, it possible for a system to remain executable even if a service is faulty, which is advantageous in the area of large server applications, for example.

• Disadvantages
  Due to the complexity that arises from the asynchronous processing of events, software errors such as DeadLocks can occur. To avoid these, it is important that the code responsible for event handling is thoroughly tested and that the synchronization does not have to be solved in the functional part of the firmware. This is possible by using a scheduler that has already been proven in many projects, such as DATAFLOW Runtime.

Efficiency

• Advantages
  Due to the event-based approach, the system only works when events occur. There is no unnecessary waste of energy, which makes the whole system very energy efficient. The occurrence of an event immediately starts the processing and therefore allows real-time responses. The real-time capabilities of software systems with event-based architectures make them very attractive for embedded systems development.

• Disadvantages
  The creation, distribution, and handling of events in the system requires additional resources (computation time, memory) that can be used for software functionality in a monolithic architecture. However, we believe that the benefits of such an architecture outweighs the minor performance penalties of an optimized scheduler such as DATAFLOW Runtime.

Transferability

• Advantages
  An event-based architecture is inherently very loosely coupled since the event consumer does not need to know the event producer. The loose coupling allows the individual parts of the software to be implemented independently of each other, and it enables clean testing of the narrow interfaces. The software is also easily extensible thanks to the loose coupling and the simple interface. The decoupling of hardware specific code (producer) and the processing logic (consumer) makes it possible to port the software to another target platform with little effort.

• Disadvantages
  Maintenance of the software may become complex because the dependencies in the distributed system are not obvious. This increases the risk of undesired changes to the functionality. By using a model-based development and code generation you can ensure that the architecture always remains understandable and the risk for software maintenance becomes manageable. Such an approach is easily possible with DATAFLOW Designer and Code Generator.The event-based approach also requires an infrastructure for event handling. This must be provided if the created firmware or parts of it are to be reused on another target system. By using a proven event framework, such as DATAFLOW Runtime, this can be realized with minimal effort.

2.2 Why is the event-based approach particularly well suited for embedded systems?

The event-based architecture primarily addresses features such as:

• Efficiency
• Security
• Reliability
• Maintainability and
• Transferability

Embedded systems very often have special requirements and limitations. We have already touched on these in the introduction:

• Limited resources
• Real-time capability
• Security
• Reliability
• Maintainability

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.

3. Event-based architecture with DATAFLOW

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 [2] , 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 [3] 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.

Sources:
[1] https://en.wikipedia.org/wiki/Active_object
[2] https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
[3] https://en.wikipedia.org/wiki/Preemption_(computing)