System- und Softwarearchitektur in Embedded Systems

Das System

Wir beschäftigen uns hier mit technischen Systemen. Noch etwas spezifischer mit Embedded-Systemen. Ein Embedded-System, auf Deutsch ein «eingebettetes System» ist wie folgt definiert:

«Ein eingebettetes System ist ein elektronischer Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.»

Quelle: Wikipedia

Ganz ähnlich diese Definition (Quelle https://www.embedded-software-engineering.de):

«Ein eingebettetes System ist ein binärwertiges digitales System (auch Computersystem genannt), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei übernimmt der Rechner meist Überwachungs-, Steuerungs- oder Regelungsfunktionen, ist oft aber auch für eine Form der Daten- bzw. Signalverarbeitung zuständig.»

Diese Definitionen können mit dem folgenden Diagramm verdeutlicht werden:

Abbildung 1: Allgemeines Embedded-System mit der gewünschten Funktion/Verantwortung, umgeben von externen Systemen und einem oder mehreren Benutzern.

Der Einfachheitshalber wird meist einfach von dem «System» gesprochen mit welchem man sich befasst. Auch im Rest dieses Artikels wird häufig nur noch von «System» gesprochen und damit ist das entsprechende technische oder eben das Embedded-System gemein.

Architektur und Design

Um die Begriffe zu erklären, muss aufgezeigt werden, wie ein solches System gebaut wird. Abbildung 1 stellt das Embedded-System als Blackbox dar. Der Aufbau des Systems ist noch nicht definiert. Es muss definiert werden, aus welchen Bestandteilen das System aufgebaut werden soll. Diese Tätigkeit nennt man «Design». Bei einem «Systemdesign» geht es also um die Definition und Festlegung des Systemaufbaus. Das Resultat einer solchen Designtätigkeit könnte dann, basierend auf dem Diagramm (Abbildung 2), wie folgt aussehen:

Abbildung 2: Resultat (Architektur) der ersten Design-Iteration zur Definition der Bestandteile (Architekturelemente).

Meist läuft eine solche Design-Tätigkeit iterativ ab. Das heisst die Bestandteile – man spricht hier von Architekturelementen – werden soweit zerlegt (engl. «decompose»), bis diese genügend definiert sind. Erst dann kann die Erstellung (Entwicklung) des Systems beginnen.

Das Resultat dieser Design-Aktivität nenn man «Architektur». Die Abbildung 2 ist also eine erste «Systemarchitektur» (genau genommen ist die Abbildung 2 eine Referenzarchitektur eines allgemeinen Embedded-Systems), wobei der Begriff Architektur in diesem Zusammenhang noch genauer definiert werden muss. Es gibt nicht eine einzige etablierte Definition des Architekturbegriffes. Eine Sammlung von Definitionen findet man hier: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513807. Dies sind zwar Definitionen für Softwarearchitektur, sie gelten jedoch auch für den Begriff der System-Architektur. Die Unterscheidung liegt im Anwendungsbereich (engl. Scope) – dazu aber weiter unten noch mehr.

Wir verwenden die folgende Definition des Architekturbegriffes (aus «Software Architecture in Practice – Third Edition»):

Definition (Software-) Architektur:

«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. »

Darin sind die folgenden 3 Sätze enthalten, hier in Übersetzung:

1. Die Architektur eines Systems ist aus einer Menge von Strukturen aufgebaut.
2. Es sind die Strukturen, welche benötigt werden, um auf das System schliessen zu können.
3. Die Strukturen umfassen die Elemente, deren Beziehungen und deren Eigenschaften.

Was bedeutet das nun?

Die Strukturen bestehen aus Elementen, deren Beziehungen und deren Eigenschaften. Architektur besteht aus den Strukturen, welche benötigt werden, um sicherzustellen, dass sich das System wie gefordert verhält. Wobei hier nicht nur die Erfüllung der funktionalen Anforderungen gemeint ist, sondern auch der ganze Bereich der nicht-funktionalen Anforderungen. Beispielsweise haben Forderungen bezüglich Weiterentwickelbarkeit meist Einfluss auf die Struktur des Systems. Es gehören jedoch nicht alle Strukturen eines Systems zur Architektur. Nicht alle Strukturen sind architekturrelevant. Man spricht bei diesen Strukturen dann nicht mehr von Architektur, sondern von Design.

«Design» ist einerseits die Tätigkeit, welche zu einer Architektur führt (siehe weiter oben), als auch der Begriff für sämtliche nicht architekturrelevanten Resultate aus der Designtätigkeit.

Viele Definitionen machen sich das einfacher, indem sie ausführen, dass die Grobstruktur oder die früh im Designprozess definierten Strukturen Architektur sind. Alle späteren oder detaillierteren Strukturen sind Design. Diese Definitionen sind allerdings unzureichend, da durchaus detailliertere Strukturen notwendig sein können, um die geforderten Anforderungen zu erfüllen. Auch wird in einer agilen Entwicklung nicht alles Relevante schon früh im Designprozess definiert.

System versus Software

Zuletzt noch die Unterscheidung zwischen «Systemarchitektur» und «Softwarearchitektur»: Wie bereits weiter oben aufgeführt, unterscheiden sich diese im Anwendungsbereich (Scope). Die Systemarchitektur umfasst die Strukturen von verschiedenen Systemelementen, wie Hardware, Software, Mechanik. Die Softwarearchitektur hingegen umfasst die Strukturen, welche den Aufbau eines Softwareelementes (ein Element aus der Systemarchitektur) definieren. Dies ist in den nachfolgenden Diagrammen ersichtlich:

Abbildung 3: Systemarchitektur-Diagramm mit Hard- und Softwareelementen.

Bei der weiterführenden Zerlegung eines Softwareelementes landen wir schlussendlich bei der Softwarearchitektur:

Abbildung 4: Softwarearchitektur-Diagramm des Softwareelementes «Control Software».