Today, our everyday lives are naturally characterized by interconnected devices and systems. Whether you use your smartphone to find the fastest way to your destination, read the newspaper on the couch with your tablet or control the smart heating via an app on your smartphone, these systems make our lives more comfortable. However, the convenience gain also requires stricter safety and security requirements, which the developers of such systems must follow. This is especially true of autonomous driving – here, coherent safety concepts have top priority.
Know-how and skills that software architects should have
With increasing product complexity and increasingly powerful hardware, the scope and complexity of the software in embedded systems is also increasing. In many products, the software implements the essential part of the functionality. The departments that develop embedded software are constantly growing. This can be seen especially in the car industry and is also reflected in the current labor market. For example, Mercedes-Benz plans to generate the majority of its sales from software-based systems from 2030 onwards. It is no longer developed in a “one-man show”, but in large teams – distributed in different locations around the world.
The importance of embedded software has increased drastically in most companies in the embedded industry in recent years – also in the product area mechatronics. But this is only the beginning.
Agile software development methods are increasingly in the spotlight
In agile software projects, the software architecture is developed in an evolutionary way, among other things based on test-driven software development methods. There are two different development approaches:
- functional architecture: The software system is represented in features or functions and their dependencies.
- component architecture: Develops a rough draft and several fine drafts that contain a fine-grained structure of the software.
Software architecture plays a key role in the success of the project
In order for the software architect to be able to do justice to his responsible work, he needs in-depth know-how on the following key aspects:
1. Basic understanding of software architecture
At an abstract level, the software architecture represents a bridge between the requirements and the implementation of the software. In the software, the architecture describes the rough structure (only exceptionally also modules and classes), eg consisting of software components, software layers, software subsystems, interfaces and their dependencies. However, an interactive and an individual behavior for these architectural elements can also be described. An essential part of the software architecture is the runtime architecture.
2. The role of the software architect
Anyone with the necessary know-how can take on the role of software architect in a project in the company. In my opinion, however, in order to really pursue the subject professionally, one should prefer the person-related role. Depending on the size of the project, one or more software architects are involved in a project.
3. Chief Architects guide software architect teams
The software architect coordinates with several roles in the project and needs technical and non-technical knowledge for this – the more experience he has, the better. Ideally, the role of software architect should not be filled by a graduate directly from the university. There is a demand for outgoing, innovative, determined and experienced employees.
Design procedure – how to create a software architecture
The design procedure describes the development process of the software (architecture). Every business needs to find and implement the most appropriate approach for itself. The software architect is significantly involved in this definition.
Based on a V-model-like representation, the design process can be used to develop a complete embedded system, not just for software development.
Requirements (WHAT) and corresponding requirements (HOW)
In the analysis activities, the analysts (in fact, usually also the architects) identify and document the corresponding requirements (WHAT) at the individual levels. Based on this, the architectures are created (HOW). Based 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 (eg hardware development).
In parallel with the requirements, the test team develops the test cases to later prove the correct implementation. This is also done at different levels. “Design for Test” and now “Design for Safety” are basic software architecture topics.
Design basis and influencing factors
The software requirements (functional and non-functional) are the result of the X analysis shown in Figure 3 (here software analysis).
During an influence factor analysis, the software architect decides
- Relevance of the requirement for the software architecture
- Variability 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 features that the software must provide, such as
- portability
- maintenance
- reliability
- security
- resource consumption
- performance
- real-time capacity
Here is the view through the glasses of the relevant software quality features: SECURITY
Here based on the relevant software quality features: Reliability
When it comes to quality features, it should be noted that some are simultaneous while others are also upstream.
With this knowledge, let’s ask ourselves the following questions: What requirements affect architecture more – functional or non-functional?
Correct answer: the non-functional requirements!
The software requirements and the resulting influencing factors thus constitute the most important design basis for the software architecture in addition to the subsystem architecture.
communication and documentation
The software architect creates the basis for each project with an understandable documentation of the software architecture for all stakeholders and thus a complete traceability for all project participants. In this way, he ensures the continued existence of the company.
At the same time, the documentation forms the basis for communication, which must be continuously compared with the stakeholders.
The main stakeholder is the software developer, who refines the design of the software architecture and eventually implements it in the target programming language. In addition to the software developer, other roles, such as the software testing team, have a legitimate interest in the software architecture. Only when I know what is wanted can I check if it has really been implemented that way.
UML (Unified Modeling Language) is the notation that can be used to document a wide range of views and aspects of the software architecture and to refine the design – all the way down to automatic code generation. The different software layers are modeled with the package diagram in Figure 4.
Read more in part 2.