System, Software, Architecture and Design – What do all this terms mean?

Embedded System Overview

Introduction

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.

 

The system

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.”

Source: Wikipedia

 

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:

  1. The architecture of a system is built from a set of structures.
  2. These are the structures needed to be able to infer the system.
  3. 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”.

 

Summary

The most important terms and their definitions are summarized again in the following table:

 

Term Meaning, definition
Embedded system 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.
Design (activity) 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).
Architecture 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 design 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).
Table 1: Terms and their meaning/definition

Are you interested in reading further articles?

Leave your e-mail address here and we will inform you as soon as we publish new contributions.

DATAFLOW Software

Nutzen Sie unsere 30-Tage-Testversion

Voriger
Nächster


Gewerbestrasse 8  |  9470 Buchs  |  Schweiz  |  Tel. +41 81 750 06 40  |  Email dataflow@imt.ch

Thank you for subscribing!

From now on you will receive a newsletter with exiting embedded systems content and articles.

Gewerbestrasse 8  |  9470 Buchs  |  Schweiz  |  Phone +41 81 750 06 40  |  E-mail office@data-flow.ch

DATAFLOW IMPRESSUM

Kontakt-Adresse
DATAFLOW Software AG Gewerbestrasse 8 9470 Buchs Schweiz E-Mail: office@data-flow.ch
Vertretungsberechtigte Person(en)
Christian Büchel, CEO
Handelsregister-Eintrag
Eingetragener Firmenname: DATAFLOW Software AG Handelsregister Nr: CHE-190.688.043 Mehrwertsteuer-Nummer CHE-190.688.043
Haftungsausschluss
Der Autor übernimmt keinerlei Gewähr hinsichtlich der inhaltlichen Richtigkeit, Genauigkeit, Aktualität, Zuverlässigkeit und Vollständigkeit der Informationen. Haftungsansprüche gegen den Autor wegen Schäden materieller oder immaterieller Art, welche aus dem Zugriff oder der Nutzung bzw. Nichtnutzung der veröffentlichten Informationen, durch Missbrauch der Verbindung oder durch technische Störungen entstanden sind, werden ausgeschlossen. Alle Angebote sind unverbindlich. Der Autor behält es sich ausdrücklich vor, Teile der Seiten oder das gesamte Angebot ohne besondere Ankündigung zu verändern, zu ergänzen, zu löschen oder die Veröffentlichung zeitweise oder endgültig einzustellen.
Haftungsausschluss für Links
Verweise und Links auf Webseiten Dritter liegen ausserhalb unseres Verantwortungsbereichs. Es wird jegliche Verantwortung für solche Webseiten abgelehnt. Der Zugriff und die Nutzung solcher Webseiten erfolgen auf eigene Gefahr des jeweiligen Nutzers.
Urheberrechte
Die Urheber- und alle anderen Rechte an Inhalten, Bildern, Fotos oder anderen Dateien auf dieser Website, gehören ausschliesslich der Firma DATAFLOW Software AG oder den speziell genannten Rechteinhabern. Für die Reproduktion jeglicher Elemente ist die schriftliche Zustimmung des Urheberrechtsträgers im Voraus einzuholen.
Quelle: SwissAnwalt

Vielen Dank!

Wir wünschen Ihnen viel Spass mit DATAFLOW Software

Voriger
Nächster


Gewerbestrasse 8  |  9470 Buchs  |  Schweiz  |  Tel. +41 81 750 06 40  |  Email dataflow@imt.ch