Wiederverwendbare Komponenten sind aus der modernen Software-Entwicklung nicht mehr wegzudenken. Warum also wird dieser Ansatz im Embedded-Umfeld von vielen Entwicklungsabteilungen noch nicht konsequent verfolgt?

Die Gründe dafür dürften vielfältig sein. Bis vor wenigen Jahren wurden viele Embedded-Anwendungen noch mit Assembler realisiert, weil auf den eingesetzten Plattformen so wenig Speicher und Rechenleistung zur Verfügung stand, dass in einigen Anwendungen selbst der geringe Overhead nicht akzeptabel war, der durch den Einsatz einer Hochsprache entsteht. Die begrenzten Ressourcen zwangen außerdem dazu, die Anwendungsfunktionalitäten auf ein Minimum zu reduzieren.

Durch den Preisverfall von Mikrocontroller-Bauelementen der letzten Jahre haben sich die Rahmenbedingungen drastisch geändert. Mittlerweile stehen selbst in kostensensitiven Applikationen sehr leistungsfähige Mikrocontroller zur Verfügung. Dadurch ist einerseits eine aufwändig optimierte Implementierung in Assembler nicht mehr wirtschaftlich, andererseits wachsen die Anforderungen an Mikrocontroller-Anwendungen (z. B. In-System-Software-Update, Web-Konfigurationsschnittstelle, ...) ständig an. Dieser Trend gewinnt unter anderem durch preisgünstige 32-Bit-Controller wie dem ARM Cortex-M3 an Fahrt.

Damit stehen viele erfahrene Embedded-Entwickler, deren Schwerpunkt in der Vergangenheit eher auf der Realisierung und Integration von Hardwaretreibern lag, weil der Entwicklungsaufwand für die früher relativ einfache Applikationslogik vergleichsweise wenig aufwändig war, vor neuen Herausforderungen. Das Prinzip der konsequenten Software-Wiederverwendung ist deshalb für viele Embedded-Software-Entwickler Neuland. In diesem Zusammenhang ist nicht die Wiederverwendung von Software per Copy, Paste und anschließender Modifikation des kopierten Codes gemeint, sondern das Single-Source-Prinzip, wobei die einmal implementierten und sauber getesteten Software-Komponenten in möglichst vielen unterschiedlichen Kontexten (Applikationen) unverändert wiederverwendet werden, ihr Quellcode aber nur einmal existiert.

Software-Wiederverwendung erfordert eine sehr saubere Architektur: Die Applikationslogik muss sauber von den Hardwareabhängigen Teilen getrennt sein und die wiederverwendbaren Komponenten dürfen nicht mehrere Funktionalitäten miteinander vermischen. Hier den richtigen Ansatz zu finden erfordert viel Erfahrung und Weitblick beim Entwurf der Architektur.

Wie schon erläutert ist das Prinzip der Wiederverwendung von Software-Komponenten bereits weit verbreitet. Es existieren z. B. folgende standardisierte bzw. weit verbreitete Bibliotheken:

• C++ Standardbibliothek
• Boost

Umgekehrt sind diese Bibliotheken so allgemein gehalten, dass sie nicht genügend Hilfestellung bei der Umsetzung von Features bieten, die in sehr vielen Embedded-Anwendungen benötigt werden (Datenhaltung in Flash-Bausteinen, Software-Download, usw.). Hier bietet redBlocks Standardlösungen an, die ohne weitere Änderungen übernommen werden können.

In unserer langjährigen Tätigkeit als Dienstleister für die Entwicklung von Embedded Software sind wir immer wieder damit konfrontiert worden, für unterschiedliche Kunden ähnliche Funktionalität zu realisieren. Was liegt also näher als diese Funktionalität als wiederverwendbare Software-Komponenten zu entwickeln und als Embedded-Software-Baukasten anzubieten.

Die Komponenten sind unabhängig von der Plattform und den konkreten Anforderungen an die Applikation. Sie lassen sich gleichermaßen gut einsetzen, wenn ein (Echtzeit-) Betriebssystem eingesetzt wird, als auch beim klassischen Main-Loop-Ansatz. Einige Funktionen sind in verschiedenen Ausprägungen ausgeführt, so dass man für die konkrete Anwendung einfach die passendste Variante aussucht - nach dem Prinzip eines Baukastens eben. Ganz egal ob das Endprodukt eine Spülmaschinensteuerung, eine Industriesteuerung oder ein mobiles Datenerfassungsgerät ist.

>>> Lesen Sie hier mehr über die redBlocks-Philosophie...

Erfahren Sie hier...

redBlocks in der Praxis