Event-based software architecture in embedded system development

In this article, the event-based software architecture is presented in more detail. This architectural style is one of many different styles, which have developed since the beginnings of software architecture in the 1960s, for example

• Object-oriented
• Layered
• Client-Server
• Master-Slave
• Pipe-filter
• Peer-to-peer
• Model-view-controller

 

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:

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

 

This is the question we will address in this article. If you would like to learn more about embedded systems, please click here.

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 architectural styles. However, the requirements can often not be met with some architectural 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 layered 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 (Source). This central piece of software can be called, for example, an «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.

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.

The event-based architecture mainly influences the characteristics of 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 high-level areas (cloud architectures, enterprise computing) and are often known as microservice architectures. The big advantage is the parts of the software which can be developed separately. 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 require 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 outweigh 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 architectural 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 (Source), where the objects in DATAFLOW are called Active Parts.

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 (Source) 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.

• Efficiency
• Reliability
• Maintainability
• Security
• Transferability

 

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 automatic code generation, coherent system designs, and 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.