EN 
DE 
Our everyday lives are now seamlessly integrated with interconnected devices and systems. Whether using a smartphone to find the fastest route, reading the newspaper on a tablet while relaxing on the sofa, or controlling smart heating via a smartphone app, these systems make our lives more comfortable. However, this increased comfort also necessitates stricter security and safety requirements, which the developers of such systems must meet. This is especially true for autonomous driving – where sound safety concepts are of paramount importance.
Image 1: The software architecture – fit for the project
Know-how and skills that software architects should possess
With increasing product complexity and ever more powerful hardware, the scope and complexity of embedded systems software also increase. In many products, the software implements the essential part of the functionality. The departments that develop embedded software are growing continuously. This is particularly evident in the automotive industry and is also reflected in the current job market. For example, Mercedes-Benz plans to generate the majority of its revenue from software-based systems by 2030. Development is no longer a "one-person show," but rather takes place in large teams distributed across different locations worldwide.
The importance of embedded software has increased dramatically in recent years in most companies in the embedded industry – even in the mechatronics product area. But this is just the beginning.
Agile software development methods are increasingly in the spotlight.
In agile software projects, the software architecture is developed evolutionarily, based, among other things, on test-driven software development methods. Two different development approaches prevail:
- Functional architectureThe software system is represented in terms of functions or features and their dependencies.
- Component architecture: Develops a rough draft as well as several detailed drafts that contain a fine-grained structure of the software.
Software architecture plays a crucial role in project success.
In order for the software architect to fulfill his responsible role, he needs sound knowledge of the following key aspects:
- Basic understanding of software architecture
At an abstract level, software architecture represents a bridge between the requirements and the implementation of the software. Within the software itself, the architecture describes the overall structure (only in exceptional cases also modules and classes), for example, consisting of software components, software layers, software subsystems, interfaces, and their dependencies. Interactive and individual behavior can also be described for these architectural elements. A crucial component of software architecture is also... Runtime architecture.
- The role of the software architect
Anyone with the necessary expertise can take on the role of software architect in a company project. However, to truly approach the role professionally, I believe it's best to have a dedicated individual. Depending on the project size, one or more software architects are involved.
- The chief architect leads software architecture teams.
The software architect coordinates with various roles within the project and therefore requires both technical and non-technical knowledge – the more experience they have, the better. Ideally, the role of software architect should not be filled by a recent graduate. Extroverted, innovative, decisive, and experienced individuals are needed.
Figure 2: The most important context for the software architect
Design process – how a software architecture is created
The design process describes the development process of the software (architecture). Every company must find and implement the most suitable process for its needs. The software architect plays a crucial role in this definition.
Based on a V-model-like representation, the design approach can be used for the development of a complete embedded system, not just for software development.
Requirements (WHAT) and corresponding architectures (HOW)
In the analysis activities, the analysts (in reality, usually also the architects) at each level identify and document the corresponding requirements (the WHAT). Based on this, the architectures are created (the HOW). Building on the subsystem architectures, the software architect develops the software architecture for a subsystem – in coordination with the other development domains at the same level (e.g., hardware development).
In parallel with defining the requirements, the test team develops the test cases to later demonstrate correct implementation. This also takes place at different levels. "Design for Test" and, more recently, "Design for Safety" are fundamental software architecture topics in this context.
Figure 3: Design process for embedded systems
Design basis and influencing factors
The software requirements (functional and non-functional) are derived from the X-analysis (here software analysis) shown in Figure 3.
During a Analysis of influencing factors The software architect decides on the
- Relevance of the requirement for the software architecture
- Changeability of the requirement in the future
- Derivation of the consequences for the software architecture
Part of the non-functional software requirements are the Software quality characteristics, which the software must provide, such as.
- Portability
- maintainability
- reliability
- Security
- Resource consumption
- performance
- Real-time capability
Table 1: View through the lens of relevant software quality characteristics – Safety
Table 2: From the perspective of relevant software quality characteristics – Reliability
Regarding the quality characteristics, it should be noted that some are synchronous, while others are contradictory.
With this knowledge, let us ask the following question: Which requirements influence the architecture more – functional or non-functional ones?
Correct answer: the non-functional requirements!
Thus, the software requirements and the resulting influencing factors, alongside the subsystem architecture, form the most important design basis for the software architecture.
Communication and documentation
The software architect creates a clear and understandable documentation of the software architecture for all stakeholders, thus laying the foundation for every project and ensuring complete traceability for everyone involved. This, in turn, secures the company's continued existence.
The documentation simultaneously forms the basis for communication, which must be continuously coordinated with the stakeholders.
The most important stakeholder is the software developer, who refines the software architecture during the design phase and ultimately implements it in the target programming language. Besides the software developer, other roles, such as the software testing team, have a legitimate interest in the software architecture. Only by understanding the intended outcome can I verify that it has been implemented correctly.
Figure 4: Example of a software layered architecture
UML (Unified Modeling Language) is the notation used to document and refine various views and aspects of software architecture during the design process – right up to automatic code generation. The package diagram in Figure 4 models the different software layers.
Software design principles improve software quality
Our entire lives are governed by rules, even if some people think they don't have to follow them. Everyone has surely had their own experiences with the topic of Corona and "adhering" to regulations and rules. You probably played with Lego yourself as a child, or you do it with your children today. There are rules for how the bricks fit together, too.
The software architect continuously develops the software development style guide based on new knowledge. This guide describes the rules according to which software architectures should be developed. Not all rules can be applied to all architectures, nor are all rules applicable to them. Their application depends on the specific requirements. Applying these rules to a software architecture always improves software quality.
One architectural design principle, for example, is that of... high cohesion. The goal here is to avoid redundancies by handling logically related tasks within a single architectural element and not distributing similar tasks across multiple architectural elements. Publications now exist on specific design principles applicable to embedded software architectures. Software architecture patterns The software architect can implement the design principles in practice.
Architectural development and architectural patterns must meet safety requirements.
Based on his professional knowledge, the software architect develops the software architecture. In doing so, the architect draws on his Pattern catalog Back. In general, patterns are known, proven, evaluated and adaptable solutions to recurring problems (challenges).
For safety-relevant systems, aspects such as functional safety and reliability must be considered and fulfilled.
For systems that are intended to support us fully automatically (think of automated driving), the aspects are Safety and Reliability Key to the product's success:
Table 3: View through the safety goggles
Table 4: And not to forget – the view through the security glasses
The use of patterns can be a challenge in software architecture development:
For example, a problem might require curved contours even if only rectangular building blocks are available. One solution would be to place the blocks – following the Lego principle – in staggered rows or rows. Since we are not the first generation to develop software, patterns now exist for almost all areas of software development, including software architecture development.
One example is the Software Layer Pattern (strict or non-strict). Figure 4 shows a non-strict software layer architecture. "Non-strict" means that it includes cross-layer access. This is particularly useful for embedded software to maintain the required performance. In this example, vertical layers are included in addition to the classic horizontal layers.
Quality assurance and quality assessment
The software architect is responsible for software quality and also shares responsibility for quality assurance. Before the software architect develops an architecture, the quality characteristics must be defined. The architect understands the influence of these characteristics on their software architecture, and the software testing team knows how to verify them. Incidentally, quality cannot simply be tested into a product at the end of development!
Regarding quality, a distinction must be made between...
- internal quality (e.g., software architecture) and
- external quality (the customer sees this).
The Process quality This also significantly influences product quality. To use the Lego analogy again – all Lego bricks must be assembled in such a way that they support the structure; otherwise, it will collapse, at the latest when additional extensions are made. This also applies, by analogy, to software architecture. It must fulfill all previously defined quality criteria and functionalities.
In the past, software architectures often had to remain viable for 20 years or more. Today, they are constantly being expanded and improved. This is due to ever-changing requirements, regulations, and laws. A development process that allows for this is therefore extremely important for the continued development of products.
Figure 5: Quality assurance and evaluation
The simplest quality assurance measure
Reviews with other architects and stakeholders represent the simplest quality assurance measure in software architecture development. These reviews assess whether the architecture meets the required quality criteria. Software architecture documentation based on a UML model serves as a suitable basis for such a review.
In the scenario-based review The participants use the architecture to simulate predefined scenarios. For example, if an architecture needs to be hardware-portable, the hardware is swapped in a thought experiment to demonstrate that the software architecture can accommodate this. A very comprehensive method for this is developed by... BE (Software Engineering Institute of Carnegie Mellon University). It is called ATAM (Architecture Tradeoff Analysis Method).
Other quality assurance measures include, for example, creating prototypes or mathematical models, performing a simulation, and determining metrics.
Using this tool facilitates the development of the software architecture.
The software architect is responsible, or at least partly responsible, for the world of tools used in software development.
Figure 6: Use of tools
He knows the tool market, identifies the needs, develops tool requirements, evaluates tools, and ultimately selects them based on his expertise. If there is no dedicated tool team within the company, he is also responsible for tool integration. The tools should make the work of everyone involved in software development easier. A little self-interest doesn't hurt; the software architect benefits (primarily) from it.
Tool topics that make the work of the software architect easier:
- Requirements management
- Version and configuration management
- Modeling
- Generation of documentation and program code
- Build systems
- Static analysis
- Dynamic analysis
Implementation of the software architecture
The software architect hands over parts or all of the architecture to one or more software developers for further refinement (design and implementation). The coding style guide, which the software architect writes together with the software developers, shows, among other things, how the software architecture is reflected in the target programming language. Typical target programming languages for programming embedded systems are currently C and C++.
With C++, the software architecture can be very well represented using namespaces in the program code.
Image 7: Coding Style Guide
Software architects and software developers must ensure that the specified software architecture is maintained throughout its entire life cycle and is not "broken" by programming – a process also known as software erosion.
If the software developer identifies a need for changes to the architecture, all change decisions and the architecture change itself must be handled by the responsible software architect.
The higher the demands on safety, security and modularity of the products become, the more important and crucial to success the function of the software architect becomes in the entire development process.
Further information
-
- Software Engineering Institute, Carnegie Mellon University: ATAM/Architecture Tradeoff Analysis Method
- V-model
- Object Management Group (OMG)
-
- MicroConsult Download: Principles for embedded software architectures
MicroConsult training & coaching:
Software architectures for embedded and real-time systems
RTOS mechanisms and their applications in embedded and real-time software
Design patterns (not only) for embedded systems
Security foundations for embedded systems
Embedded software testing: Best practices for unit/module/component testing
Agile testing and test-driven development (TDD) of embedded systems
Overview of all training courses
The English version of this article was published by electronic specifier:
https://www.electronicspecifier.com/design-automation/design-for-test-and-design-for-safety
