SW Architektur & RTOS

Wachsender Komplexität wird effektiv mit Teile & Herrsche begegnet. Bei jeder Teilung entstehen jedoch multidimensionale Schnittstellen. (Zeit, Daten, Varianten, Betriebsmodi ...) Das führt dazu, dass sich die Komplexität zunehmend im Beziehungsgeflecht widerspiegelt.

Wächst das Beziehungsgeflecht ohne Struktur bildet es den Engpass für die Qualitätsattribute Wartbarkeit, Änderbarkeit, Robustheit ... Das ist die aktuelle Situation vieler Systeme. Architektur sorgt dafür, dass Beziehungen strukturiert und beherrschbar bleiben. Das ist die elementare Voraussetzung, um bei wachsender Komplexität die Qualitätsattribute stabil zu halten.

Grafik SW Architktur Zahnrader

SW Architektur & RTOS

Häufig wird im Software Engineering nicht zwischen Design und Architektur unterschieden. Das ist ungünstig, da Qualitätsattribute (Wartbarkeit, Robustheit, Erweiterbarkeit ...) im Wesentlichen auf Architektur-Mustern aufbauen, und weniger auf Design Maßnahmen. Wo nicht unterschieden wird, kann auch nicht zielgerichtet gehandelt werden. So werden in der Praxis zwar Architektur-Muster eingesetzt, jedoch ohne sich deren genauer Bedeutung aus architektonischer Sicht bewusst zu sein. Das führt nicht unbedingt zu wartbaren, erweiterbaren, robusten ... Software Architekturen.

Wird die Architektur der Komplexität eines Systems nicht gerecht, dann helfen Maßnahmen, wie die Einführung von Modellierung oder Dokumentation mit UML oder Automatisierung von Tests ... nicht wirklich weiter, sondern zielen im besten Fall auf die Symptome.

Das ist ungünstig, da Qualitätsattributen im Wesentlichen mit Architektur-Mustern begegnet wird, und weniger mit Design Maßnahmen. Wo nicht unterschieden wird kann auch nicht zielgerichtet gehandelt werden. So führt es in der Praxis regelmäßig dazu, dass Architektur-Muster eingesetzt werden, ohne sich deren genauer Bedeutung aus architektonischer Sicht bewusst zu sein. Das führt nicht unbedingt zu wartbaren, erweiterbaren, robusten ... Software Architekturen.

Wir sehen heute die Architektur als eine der grundlegendsten Säulen im Software Engineering. Sie ist die Basis für Effizienz in den Disziplinen Design, Implementation und Test von Software. Auffällig häufig werden die Symptome, die durch eine unzureichende Architektur entstehen, nicht in der Architektur angegangen, sondern in der Disziplin, in der sie sich zeigen. Leidet zum Beispiel die Qualität wird der Hebel im Test angesetzt. Ist jedoch die Architektur die Ursache wird man das Problem nicht im Test lösen können.

Architekturstil & Muster

Architektur ist immer auch mit dem Einsatz von Mustern (Pattern) verbunden. Echtzeitbetriebssysteme (RTOS) beinhalten die am häufigsten eingesetzten Architektur-Muster. (Scheduling Pattern, Kommunikations Pattern, Speicher und Ressourcen Pattern ....)

Sie bilden die Basis für eine saubere und stabile Architektur, wenn die main() Loop nicht mehr ausreichend ist, und das ist heute bei den meisten Applikationen der Fall.

Echtzeitbetriebssysteme gehören heute, ähnlich wie Compiler, zum Stand der Praxis. Alle von uns angebotenen Produkte sind stabile und ausgereifte. Ein großer Innovationsschub ist nicht mehr zu erwarten.

Eine der wichtigsten Auswahlkriterien zielt auf die Ressourcen, die ein Betriebssystem (z.B. hinsichtlich Speicher und CPU Laufzeit) benötigt. Das beste Betriebssystem der Welt bringt keine Vorteile, wenn die Latency des Scheduling so groß ist, dass der große Teil der Applikation am Betriebssystem vorbei implementiert werden muss oder die dadurch notwendige Rechenleistung zu einer HW-Plattform zwingt, die nicht nur teurer, sondern auch komplexer in der Handhabung ist.

Immer wieder treffen wir auf Projekte, in denen LINUX eingesetzt wird, was zu einer Performanten und damit häufig Komplexen HW Plattform zwingt. Für die Anforderungen wäre ev. ein kompaktes schnelles RTOS sehr viel besser geeignet gewesen und hätte nicht zum Oversizing der Hardware Architektur geführt. (Z.B. die Kombination embOS mit einem ARM Cortex M3) Im Gegenzug kommen die eigentlichen Vorteile eines LINUX ev. gar nicht zum Tragen. Kosten, Komplexität und Einarbeitung werden unnütz aufgebläht.

Ein weiteres Kriterium  zur Auswahl eines Betriebssystems liegt darin, dass es sich harmonisch in die weitere Toollandschaft integrieren lässt und die Hardware-Plattform effizient unterstützt wird.

Noch wichtiger aber ist die Anwendung der Betriebssystem Dienste im sinn einer Wartbaren, Erweiterbaren, Robusten Software Architektur.

Darin hat Willert Software Tools seit 1992 Erfahrung. Neben den eigentlichen Kenntnissen der Betriebssysteme an sich zeichnen uns unser Software Architektur Know-How für Embedded Echtzeit-Systeme aus. Das ist die Grundlage für eine fachgerechte Anwendung von Echtzeitbetriebssystemen, unabhängig von den Features und vom Hersteller.

Architektur-Muster und Outsourcing

Der Einsatz von Architektur-Mustern in Form von Bibliotheken und Betriebssystemen ist im Übrigen die preiswerteste und zugleich risikoloseste Form von Outsourcing.

Häufig werden genau diese Muster selber programmiert und Software Anteile, die Kernkompetenzen wiederspiegeln außer Haus beauftragt. Genau umgekehrt sollte es sein.

 

Managements Interest

'Teile und Herrsche' ist der wichtigste und meist genutzte Mechanismus, um Komplexität zu begegnen. Was häufig vergessen wird, am Ende müssen alle Komponenten wieder zu einem ganzen reibungslos funktionierenden System zusammengefügt (Aggregiert) werden. Wurde nur häufig genug geteilt, droht die Aggregation an den entstandenen Komplexen Beziehungen und Schnittstellen zu scheitern.

Die System Integrationsphase ist dann eine der kritischsten Phasen in Projekten. Häufig äußert sich dieser Effekt auch schleichend in der Verschlechterung der Qualitätsattribute.

Die System Architektur ist an erster Stelle verantwortlich für die Qualität und Struktur der Schnittstellen. Sie legt damit den Grundstein für nahezu alle wachsenden Systeme und steigende Komplexität in Bezug auf Wartbarkeit, Integrierbarkeit, Erweiterbarkeit, Robustheit ...

In den meisten Projekten, die wir betreuen wurde der Architektur in dieser Hinsicht wenig Beachtung geschenkt. Sie ist ,historisch gewachsen‘ und das bedeutet in der Regel nichts gutes.

Wenn Sie die Haupt Qualitätsattribute im Software Engineering verbessern möchten lohnt es sich Grundsätzlich einen Blick auf die Architektur zu werfen. Aber Vorsicht, gute Architekten sind im Embedded Software Engineering rar. Und Fehlbeurteilungen die Regel.