EN 
DE 
Embedded projects usually start very small. And often, no thought is given to the software architecture in the initial stages. The application is supposed to work quickly – and the problems with the new hardware still need to be solved.
But such an approach quickly backfires. At the latest when the next customer request comes in, you realize that a little more structure in the application would have made the desired changes easier – but there's no time for that anymore, because the customer is waiting. This then repeats itself a few more times, and each time the effort increases.
The next project will be launched in a similar fashion, and no one will have learned anything. Yet it's really not difficult to incorporate a few solid cornerstones into an embedded project. You don't have to reinvent the wheel. Most problems aren't new and have already been solved by other developers.
Some clever people have even developed templates (patterns) that you only need to adapt to your own project. These templates are called patterns in modern parlance.
Patterns are widely used in programming, where they are called design patterns. Many embedded developers are unaware that such patterns also exist for software architecture. Below, we present three architectural patterns that are well-suited for embedded projects.
The blackboard as a central exchange platform (notice board)
The Blackboard architectural pattern is frequently used in expert systems. In a simplified form, it can be effectively used in embedded systems to avoid the chaos of countless global variables. The starting point: Many components of a program need access to the same data but are not in direct contact with each other.
Image 1: Principle of Blackboard Architecture
The bulletin board is established as a central exchange platform for shared data. This provides the application with a unified data repository. It also makes it possible to send change notifications to data users or to validate values, thus preventing unauthorized data modifications.
Advantages
- Unified mechanism for accessing central data
- Faulty access to the data is easy to detect.
- No direct, uncontrolled access to the data
- Changes are easier to implement.
Disadvantages
- Depending on the ease of use of the implementation, accessing a date takes longer.
Layered architecture
The layered architecture divides the application into layers of varying (ascending) abstraction. Only the upper layer is dependent on the lower one, and not vice versa. Data flows from bottom to top are implemented through callback mechanisms; this avoids circular dependencies.
Figure 2: Layered architecture
Advantages
- Reducing dependencies
- Defined interfaces between the layers
- Changes rarely affect other layers.
- Reusing and replacing a layer is possible
Disadvantages
- Potentially lower efficiency due to data transformations when passing data through to higher layers.
A well-known example of layered architecture is the OSI 7-layer model.
High flexibility thanks to pipes and filters
This pattern is suitable for systems where data needs to be prepared and processed, such as when processing sensor data. The data preparation is broken down into individual steps and linked together via pipes. A pipe serves only for data transport (possibly with intermediate buffering); a filter prepares the data and passes it to a pipe.
Image 3: Pipes and filters
Advantages
- High flexibility – filters can be replaced without much effort.
- Reusing individual filters
Disadvantages
- Potential efficiency losses due to data transformations into the data format of the pipeline
Event-driven system
Event-driven systems integrate well into applications where many events occur in an unpredictable order. All events are received by an event manager, which then forwards them to the components that have registered with it for that event.
Figure 4: Event-driven system
Advantages
- Strong decoupling of the components
- One component is easily replaceable.
Disadvantages
- No guarantee that an event will be processed.
- If multiple components have registered for an event, the execution order is unknown.
Conclusion
There's no reason to forgo a good software architecture. Depending on the project, an architecture template or a combination of several is selected and adapted. The (small) effort pays off very quickly. Changes become easier (the customer still has an idea shortly before delivery), and testing and debugging are also accelerated.
Further information
MicroConsult Training & Coaching on the topic of software quality
MicroConsult expertise on the topic of software quality
MicroConsult Training & Coaching on Embedded Programming
MicroConsult Expertise in Embedded Software Development
Sources
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, “A System of Patterns – Pattern Oriented Software Architecture“, Wiley
Bruce Powel Douglass, “Real Time Design Patterns: Robust Scalable Architecture for Real-time Systems,” Addison-Wesley
