Connected devices and systems have become an integral part of our everyday life and we take this for granted. Finding the fastest way to our destination with a smartphone, reading the news on a tablet while sitting on the sofa, or controlling our smart heating with a smartphone app—these systems make life more convenient. This gain in convenience, however, calls for more stringent security and safety requirements which must be managed by those developing such systems. This is especially true for autonomous driving where efficient safety concepts are a top priority (Figure 1).
Figure 1 The purpose of selecting a software architecture fit for a project.
The know-how and skills a software architect should have
Both an increasing product complexity and more powerful hardware have resulted in a growing scope of software in embedded systems. Software implements a major part of functionality in most systems. Embedded software development divisions are growing continuously. This becomes particularly obvious in the automotive sector and in the current labor market. Mercedes Benz, for example, plans to generate most of their revenue through software-based systems from 2030 onward. Software development is no longer a one-man-show but done in large teams distributed over multiple locations worldwide. Over the past few years, embedded software has gained in significance dramatically in most companies in the embedded industry—even in mechatronics. But this is only the beginning.
A stronger focus on agile software development methods
Agile software projects use an evolutionary software architecture development, amongst others, based on test-driven software development techniques. These are the two main approaches:
Software architecture is the key to project success
Software architects who want to meet the requirements of their responsible jobs need extensive know-how covering these key aspects:
Figure 2 The various roles of a software architect.
Design process—creating a software architecture
The design process describes the development process of the software (architecture). Every company has to identify and implement the process that is most suitable for them. The software architect plays a key role in defining this process. Based on a V-model type representation, the design process can be applied to the development of a complete embedded system, i.e., not only to the development of software.
Requirements (what) and the related architectures (how)
In analytic processes, analysts (in most cases also the architects) on the individual levels, identify and document the respective requirements (“what”). These requirements are the basis for creating the architectures (“how”) (Figure 3). Based on a subsystem architecture, the software architect develops the software architecture for a subsystem in coordination with other development domains at the same level (e.g., hardware development).
In line with the requirements, the test team develops test cases to prove the correct implementation later in the development process. This is also done at different levels. “Design for test” and “design for safety” are basic topics in the context of software architectures.
Figure 3 The 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. Software quality attributes based on safety and reliability are shown in Table 1 and Table 2 respectively.
By analyzing the influencing factors, the software architect determines:
Non-functional software requirements include software quality attributes of the software, such as:
Table 1 Safety from the perspective of relevant software quality attributes.
Table 2 Reliability from the perspective of relevant software quality attributes.
Some quality attributes are consistent, others can also have opposing effects. With this in mind, we can ask the following question: Which requirements have a stronger impact on the architecture, functional or non-functional? The correct answer is non-functional requirements. Consequently, the software requirements and the resulting influencing factors are the most essential design basis for the software architecture, besides the subsystem architecture.
With comprehensive software architecture documentation, the software architect provides the foundation for a project for all stakeholders and thus full traceability for everyone involved in the project, ensuring the continuity of the company. Documentation is also the basis of communication that shall be continuously coordinated with the stakeholders.
The most important stakeholder here is the software developer who refines the software architecture in detail and finally implements it in the target programming language. In addition to the software developer, other roles, like the test team, have a legitimate interest in the software architecture. You cannot verify whether the implementation is correct unless you know what is required.
Unified modeling language (UML) is the notation for documenting various views and aspects of the software architecture and refining them in design—up to automatic code generation. The package diagram shown in Figure 4 models the different software layers.
Figure 4 An example of a layered software architecture.
Software design principles enhance software quality
Our whole life is determined by rules—even if some people think they don’t have to stick to them. All of us have been confronted with the COVID pandemic and the related rules and regulations. You certainly played with Legos as a child, or you do so with your own kids today, there are rules on how to fit the bricks properly.
The software architect, with his continuously growing knowledge, draws the style guide for software development, describing the rules along which the software architecture shall be developed. Those rules cannot be applied to any architecture as they depend on specific requirements. Applying rules to a software architecture enhances the software quality in any case.
High cohesion is an architecture design principle. It aims at reducing redundancy by processing logically related tasks in one architecture element instead of distributing similar tasks across multiple architecture elements. Specific design principles have been published that can be applied to embedded software architectures. Software architects can implement the design principles in a real system by means of software architecture patterns.
Architecture development and architectural patterns have to meet safety requirements
Based on their technical knowledge, software architects develop the software architecture using their pattern catalog. In general, patterns are known, proven, rated and adjustable solutions to recurring issues (challenges). For example, aspects like functional safety and reliability must be considered and taken care of in safety-relevant systems. In systems that provide us with fully automated support (think of automated driving), safety and reliability are the key to the success of a product.
Using patterns can be a challenge in software architecture development (Table 3 and Table 4). For example, only square bricks are available, but one requirement might be a rounded outline. This could be solved by means of a graduated assembly of the bricks—according to the Lego principle—in one or several rows. As we are not the first generation to develop software, patterns have already been created for almost all areas of software development and even for the development of software architectures.
Table 3 Software architecture consequences for implementing safety and reliability.
Table 4 Software architecture consequences for implementing security.
One example is the layered pattern (strict or not strict). Figure 4 shows a non-strict software layer architecture. Non-strict means that it involves cross-layer accesses which is particularly helpful for embedded software to achieve the required performance. In this example, also contains vertical layers in addition to the classic horizontal layers.
Quality assurance and quality assessment
The software architect is responsible for the software quality and quality assurance. The quality attributes have to be defined before developing an architecture. The software architect knows the impact of these attributes on his software architecture and the software test team knows how to prove them. By the way, attributes cannot be “tested into” a product at the end of the development process.
In the context of quality, there is a differentiation between:
Process quality has a major impact on product quality. To get back to the Lego analogy once more—all bricks must be assembled such that they support the structure, otherwise, it will collapse as soon as additional expansions are made. This is also true for software architectures; they have to fulfill all quality requirements and provide all functions that were defined before (Figure 5).
Figure 5 Quality assurance and assessment for software architecture.
Software architectures were expected to remain functional for 20 years or longer in the past. Today, they are under continuous expansion and improvement due to emerging requirements, regulations, and laws. For this reason, the development process shall accommodate this aspect as it is key to the further development of a product.
The easiest way to assure quality
Reviews with other architects and stakeholders are the easiest way to assure the quality of the software architecture. They serve to assess whether the architecture complies with the required quality attributes. The software architecture documentation generated by means of an UML model is a suitable basis for a review.
In a scenario based review, participants go through pre-defined cases with the architecture. For example, if an architecture is required to be portable in terms of hardware, this process includes an exchange of hardware so as to prove that the software architecture can meet this requirement. The Software Engineering Institute (SEI) of Carnegie Mellon University has developed an extensive method to this end, called the architecture tradeoff analysis method (ATAM). Further quality assurance methods are, for example, prototypes or mathematical models, performing simulations or determining metrics.
Tools makes it easier to develop the software architecture
The software architect is responsible or at least co-responsible for the tool environment for software development. He or she knows the tool market, can identify the demand, develops tool requirements, evaluates, and finally selects the tools. In a company that does not have a tool group, he is also in charge of tool integration. The tools make work easier for everyone involved in software development, especially for the software architect.
Figure 6 Use of tools to make the work of the software architect simpler.
Tools make the work of the software architect easier:
Implementation of the software architecture
The software architect passes the entire architecture, or parts thereof, on to one or several software developers for further refinement (design and implementation). The coding style guide created by the software architect in collaboration with the software developers, shows how the software architecture is implemented in the target programming languages. Typical target languages for programming embedded systems are C and C++ (Figure 7).
Figure 7 A coding style guide.
In C++, the software architecture can be represented efficiently in the program code by means of namespaces. The software architect and software developer have to make sure that the defined software architecture is preserved over its entire lifecycle and not programmed “to death”—also referred to as software erosion.
If the software developer identifies a need to change the architecture, all related decisions and the changes to the architecture are coordinated by the software architect in charge. The higher the requirements on safety, security and modularity of a product, the more critical and significant the role of the software architect in the entire development process.
Thomas Batt studied communication engineering at the University of Applied Science in Offenburg, Germany. He developed hardware and software for embedded and real-time systems in various companies. Since 1999, he has been a certified Trainer and Coach at MicroConsult, responsible for systems engineering/ software engineering for embedded and real-time systems as well as process coaching.
Ingo Pohle is co-founder and Managing Director of MicroConsult. He is an internationally renowned specialist for embedded solutions, with a wide range of experience in the field of embedded microcontrollers, bus systems and RTOS.
You must Sign in or Register to post a comment.