Embedded „system design“, „system architecture“, „software architecture“, what exactly is behind these terms? What do they mean? What are the definitions? Why is it important to differentiate between these two terms?
This article deals with the answers to these questions.
Here, we are dealing with technical systems, Or more specifically, with embedded systems. An embedded system is defined as follows:
“An embedded system is an electronic computer that is integrated (embedded) in a technical context. In this context, the computer either performs monitoring, control or regulating functions or is responsible for some form of data or signal processing, for example in locking or unlocking, encoding or decoding or filtering.”
Very similar to this definition (source https://www.embedded-software-engineering.de):
“An embedded system is a binary-valued digital system (also called a computer system) that is embedded in and interacts with a surrounding technical system. Here, the computer usually takes over monitoring, control or regulation functions, but is often also responsible for some form of data or signal processing.”
These definitions can be clarified with the following diagram:
Figure 1: General embedded system with the desired function/responsibility, surrounded by external systems and one or more users.
For the sake of simplicity, we usually simply refer to the “system” we are dealing with. Throughout the remainder of this article, we will often only refer to the „system“, which means the corresponding technical or embedded system.
Architecture and design
In order to explain the terms, we must demonstrate how such a system is built. Figure 1 presents the embedded system as a black box. The structure of the system has not yet been defined. The components from which the system is to be built must be defined. This activity is known as “design”. A “system design” is therefore about defining and determining the system structure. Based on the diagram (Figure 2), the result of this design activity could look as follows:
Figure 2: Result (architecture) the first design iteration to define the components (architecture elements).
Design activities tend to be repetitive. This means that the components—referred to here as architectural elements—are decomposed until they are sufficiently defined. Only then can the creation (development) of the system begin.
The result of this design activity is called “architecture”. Figure 2 is therefore a first “system architecture” (strictly speaking, Figure 2 is a reference architecture of a general embedded system), although the term architecture still needs to be defined more precisely in this context. There is no single established definition of the term architecture. You can find a list of definitions here: Definition Software Architecture. While these are definitions of software architecture, they also apply to the term system architecture. The distinction lies in the scope—more on this below.
We use the following definition of architecture (from „Software Architecture in Practice – Third Edition“):
Definition of (software) architecture:
“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”
It contains the following 3 sentences:
- The architecture of a system is built from a set of structures.
- These are the structures needed to be able to infer the system.
- The structures include the elements, their relationships and their properties.
So, what does that mean?
The structures consist of the elements, their relationships and their properties. Architecture consists of structures, which are needed to ensure that the system behaves as required. The whole area of non-functional requirements is also meant here, in addition to the fulfillment of functional requirements. For example, requirements regarding further development usually influence the structure of the system. However, not all structures in a system belong to architecture. Not all structures are architecture-relevant. These structures are then no longer referred to as architecture, but as design.
“Design” is on the one hand the activity that leads to an architecture (see above), and on the other hand the term for all non-architectural results of the design activity.
Many definitions simplify things by stating that the rough structure or the structures defined early in the design process are architecture. All later or more detailed structures are design. However, these definitions are insufficient, as more detailed structures may well be necessary to meet the required demands. Also, in agile development, not everything relevant is defined early in the design process.
System versus software
Finally, the distinction between “system architecture” and “software architecture”: As already mentioned above, they differ in scope. The system architecture includes the structures of various system elements, such as hardware, software and mechanics. The software architecture, on the other hand, comprises the structures that define the structure of a software element (an element from the system architecture). This can be seen in the diagrams below:
Figure 3: System architecture diagram with hardware and software elements.
In the further decomposition of a software element, we eventually end up with the software architecture:
Figure 4: Software architecture diagram of software elements “Control Software”.
The most important terms and their definitions are summarized again in the following table:
|An embedded system is an electronic calculator or computer, which carries out a defined function and is embedded in a physical environment, is optionally surrounded by other subsystems and has an optional user interface.
|The activity that defines how a system is built from several components (architecture elements).
|System design (activity)
|See “Design”— with the specification that it is the design of a system, i.e. various elements such as hardware, software, mechanics.
|Software design (activity)
|See “Design”— with the specification that it is the design of a software (software elements).
|The architecture of a system is the set of structures needed to infer the system, or to ensure that the system satisfies the required properties. The structures include the elements, their relationships and their properties.
|The structures which, in addition to the architecture-relevant structures (see „Architecture“), also define the structure of the system, but which are not relevant for the required system properties.
|The system architecture
|See “Architecture”— with the specification that it is the design of a system, i.e. various elements such as hardware, software, mechanics.
|The software architecture
|See “Architecture”— with the specification that it is the design of a software (software elements).