EN 
DE What are the key considerations when developing architectures for embedded software? This is a question we cover in detail in our seminars. In this article, we've briefly summarized the most important aspects for you. Even if you're not a software architect yourself, it's crucial to understand the significance of this role within a project. The software architect plays a vital role in ensuring that developers, project managers, executives, and many other stakeholders achieve their project goals.
Requirements are the basis of the architecture.
As in all areas of development, the principle for software architecture development is: first focus on the WHAT, then the HOW. The WHAT refers to the requirements placed on the software. The HOW is the concrete implementation of these requirements. Developing the architecture represents an important first step in transforming the WHAT into the HOW. But without requirements, there is no architecture.
Let's best understand this connection through an analogy: house construction. For example, someone who doesn't know which rooms of what size are needed for which purpose will find it difficult to plan a house. Anyone considering building a house quickly realizes how much the users' requirements influence the architecture of the house.
Requirements can generally be divided into functional and non-functional categories. Functional requirements describe the functions the user expects. A bathroom, for example, must offer the user the opportunity to shower, bathe, and wash their hands. Non-functional requirements determine which properties are expected beyond pure functionality—for example, if a low-energy house is desired. It quickly becomes clear that these non-functional requirements will have a significant influence on the architecture of the house.
In software development, functional requirements describe, for example, all possible applications by the users, while portability to specific hardware or compliance with a security standard represents a non-functional requirement. Here, too, the non-functional requirement of portability will significantly influence the software architecture. Architectures, whether physical or software, are determined by functional and non-functional requirements.
Unlike most buildings, flexibility and modifiability play a crucial role in software, because software typically requires constant and often significant adaptation throughout its lifecycle. Therefore, the non-functional requirements for high flexibility to accommodate future features may have a greater impact on the architectural design than the currently known specific functions.
Conclusion
For a robust software architecture, it is crucial that the software architect carefully analyzes both functional and non-functional requirements. Particular attention should be paid to non-functional requirements with regard to extensibility and modifiability. The result is a software architecture that achieves a high degree of decoupling between low-level software and the rest of the software. The software architect achieves this, for example, by introducing software layers.
For the sustainable development of a software architecture, we recommend six further measures, which we will briefly explain below:
- Establish the role of the software architect.
- Develop and utilize architectural principles.
- Develop and use architectural patterns.
- Verify the architecture using application scenarios.
- Ensure consistency between architecture and implementation.
- Document your architecture.
We will first focus on the person in charge.
Software Architect (m/f)
Project experience shows that important tasks are implemented most effectively when responsibility is clearly defined. Therefore, we recommend introducing the role of a software architect, who initiates and manages all measures for developing a software architecture. In smaller companies and project teams, the software architect role is often filled by different individuals who may combine it with other roles, such as project manager or developer. In larger companies and project teams, the software architect role is permanently assigned to one or more employees.
Since their work often involves integrating diverse interests and disciplines, successful software architects need social skills in addition to technical expertise. Soft skills such as communication, conflict management, and team building are crucial.
Image 1: From developer to software architect: Engineering experience and people skills are in demand!
The demands on qualifications and experience, as well as the significant responsibility, make the role of software architect not only interesting and challenging, but also very attractive in terms of salary. In some cases, software architect is one of the best-paid roles in development.
A very important task of the software architect is to establish architectural principles.
Develop and use software architecture principles
It is advisable to establish a style guide for software architecture and to develop it evolutionarily. This could include, among other things, fundamental rules (principles) that should be followed and verified during software architecture development. Many published principles already exist that are applicable to embedded and real-time software architectures. Other principles are company- or product-specific and are not published.
One example is the principle of loose coupling between software architecture elements. This principle facilitates the interchangeability and reusability of software architecture elements. This principle can be implemented through abstraction via interface creation.
To make specific drivers for different microcontrollers interchangeable, a number of generic interfaces (I_GPIO, I_PWM, I_ExternalInterrupt) and callback interfaces (ICB_ExternalInterrupt) are required. These generic interfaces are implemented individually for each microcontroller. This ensures easy interchangeability of the microcontroller from a software perspective. Following this principle, Arm has standardized driver and operating system calls for Arm®-based microcontrollers with the CMSIS standard (Cortex® Microcontroller Software Interface Standard).
The implementation of principles is facilitated by the development and application of patterns.
Apply software architecture patterns
Especially in embedded and real-time development, the wheel (software architecture) is constantly being reinvented in every company, and sometimes even for every new project. This is also due to the lack of sufficiently high-quality and stable standards for embedded and real-time software architectures. Nevertheless, it is possible to use published solutions for recurring challenges in software development in the form of patterns. These can be adapted to individual circumstances. In the field of software architecture, these are known as software architecture patterns.
An example of a software architecture pattern is the so-called layer pattern. It describes strict and non-strict layered architectures. In a non-strict architecture, layers can be skipped during access; this is not permitted in a strict layered architecture. To meet the performance quality criterion, software architects in the embedded software field usually opt for a non-strict layered architecture.
In addition to the classic horizontal layers, vertical layers are also conceivable. If, for example, a software layer requires access to all other layers, or vice versa, then this layer can be arranged vertically to simplify representation and documentation.
Image 2: Example layer pattern – not strict, with horizontal layers and one vertical layer
To meet the requirement of portability to different microcontrollers, the software layer architecture shown in Figure 2 could be used. The hardware driver layer contains one part for the STM32xx microcontroller and another for the LPC17xx microcontroller.
Before we implement the architecture developed using principles and patterns, it is advisable to check whether the architecture meets the requirements.
Verifying software architecture through scenarios
The software architecture forms the basis for distributing tasks within the project team and, consequently, for software implementation. Changes to the software architecture become increasingly complex the later they are made in the project. Therefore, the software architecture should be as stable as possible from a very early stage of development. This can be achieved through quality assurance measures such as reviews, and especially through scenario-based verification. For this purpose, architecture-relevant scenarios are developed based on the functional and non-functional requirements and tested against the architecture (manually or with tool support through execution or simulation of the software architecture).
For the software to be portable to different microcontrollers, the software architecture must withstand a scenario in which microcontrollers are interchangeable.
Ensure consistency between architecture and implementation
Even when changes and extensions are made, the program code must reflect the software architecture one-to-one. If this consistency is not maintained, the phenomenon of software erosion occurs. In this case, unpredictable and difficult-to-trace or impossible-to-understand events increasingly occur in the software.
To maintain consistency, it is particularly advantageous if the program code can be automatically generated from the software architecture and the underlying software design (for example, based on a UML model). Depending on the tool, additional manual coding may be necessary. If changes are made directly to the program code, it is essential to check how this alters the architecture. If necessary, the architecture must be adapted to the new circumstances. This decision is made by the software architect. They either incorporate the changes into the model before regenerating the program code, or they synchronize the modified program code back into the model.
Figure 3: Alignment of architecture and source code – model-based program code generation and back-synchronization
However the architecture is created and changes, it must not only be consistent with the program code, but the current state must also be documented.
Document the software architecture
Documenting software architecture is crucial for preserving and communicating knowledge. The UML (Unified Modeling Language) standard is currently well-suited for this purpose. It describes graphical notations for visualizing software, among other things, and is divided into several diagrams.
For visualizing and documenting software layers, a package diagram (or alternatively a component diagram) can be used. That the package represents a software layer is indicated by a < > possible with a unique name.
The dependencies between the layers can be represented by the dependency relation. Implementations of software interfaces across software layers can be represented by the interface or implementation relation.
Using UML offers numerous advantages. Firstly, the notation is largely standardized. Secondly, powerful tools from several vendors are available on the market, some offering very affordable entry-level solutions. The use of simple, graphically oriented drawing tools is not recommended, as they lack the helpful validation mechanisms and automation features offered by professional UML tools.
Figure 4: Documentation of the software architecture – package diagram to represent software layers
Summary
If you want to develop a software architecture that provides a solid foundation for long-term, maintainable, and extensible software, you should consider the following points:
Ensure clear accountability by establishing the role of a software architect. This person ensures that appropriate principles, such as patterns, are incorporated into the architectural design. Before implementation, the architecture should be tested for its likely practicality using relevant use cases. During implementation, it is crucial to ensure that the architecture and code remain consistent throughout.
The architecture is best developed using a tool that allows for largely standardized modeling and ensures consistency with the program code through automated code generation.
As with house construction, good architecture based on clear requirements saves a lot of money, time and nerves during construction, renovation and use.
MicroConsult supports you with training and coaching on embedded software architectures:
Software architectures for embedded systems and real-time systems
Embedded software design and patterns with C
Design patterns (not only) for embedded systems
Training & coaching on the other topics in our portfolio can be found here. here.
Furthermore, there is the possibility to explore the topic area Embedded software architectures also in tailor-made workshops to address. They are tailored to the specific needs of tasks, projects, teams, and roles.
Send us your questions, requests and requirements! Go to the contact form
author
Dipl.-Ing. (FH) Thomas Batt Thomas Batt is a native of Freiburg. After training as a radio and television technician, he studied communications engineering in Offenburg. Since 1994, he has worked continuously in various industries in the field of embedded and real-time system development. In 1999, Thomas Batt joined MicroConsult GmbH. There, as a certified trainer and coach, he is currently responsible for the areas of systems/software engineering for embedded/real-time systems as well as development process consulting.
