Wie man trotz immer komplexerer Produkteigenschaften die Entwicklungskosten senken kann
Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
Die Lastenhefte für neue Produkte werden immer umfangreicher. Viele Entwickler nutzen daher Computer-on-Modules mit geeigneten Betriebssystemen als Basis. Ein entsprechendes Trägerboard mit Netzteil, speziellen I/Os und mechanischen Anpassungen sowie die anwendungsbezogene Software...
Wie man trotz immer komplexerer Produkteigenschaften die Entwicklungskosten senken kann
Die Lastenhefte für neue Produkte werden immer umfangreicher. Viele Entwickler nutzen daher Computer-on-Modules mit geeigneten Betriebssystemen als Basis. Ein entsprechendes Trägerboard mit Netzteil, speziellen I/Os und mechanischen Anpassungen sowie die anwendungsbezogene Software bilden den zu entwickelnden Eigenanteil. Mit entsprechenden Konzepten und Werkzeugen sind aber auch komplexe Anforderungen sicher beherrschbar.
Jobangebote+ passend zum Thema
Durch die immer anspruchsvolleren Anforderungen an das Endprodukt steigt besonders der Software-Anteil in Embedded-Projekten seit Jahren deutlich an. Ein Ende dieser Aufwärtsspirale ist zurzeit nicht in Sicht. Besonders bei Embedded-Systemen, die in IP-Netzwerke integriert werden und eine anspruchsvolle Benutzerschnittstelle benötigen, ist der Software-Entwicklungsanteil inzwischen im Vorfeld kaum noch überschaubar. Aus diesem Grund werden wohl auch die meisten Projekte nicht mehr termingerecht abgeschlossen. Nach Schätzungen verschiedener Marktteilnehmer werden über 50 % aller Embedded-Projekte mit erheblichen Zeitverzögerungen beendet. Zum Teil wird die Software sogar schon mit Hilfe iterativer Vorgehensweisen entwickelt. Das senkt in manchen Fällen zwar die Kosten, bereitet aber erhebliche Probleme bei der Terminplanung und der Synchronisation von Hardware- und Software-Entwicklung.
Eine Ursache für viele Probleme im Bereich der Software-Entwicklung ist die sehr weit verbreitete C/C++-Programmierung. Diese Sprache kommt – in der Regel allerdings ohne die objektorientierten Ideen von C++ – nach wie vor in den meisten Embedded-Projekten für sämtliche Aufgabenstellungen zum Einsatz. Die Gründe dafür sind vielfältig. Zum einen kann man aus C/C++ heraus problemlos direkt auf Hardware-Ressourcen zugreifen. Zum anderen liefern die meisten Mikrocontroller-Anbieter nahezu sämtliche Beispiele in C/C++. Gleiches gilt für unzählige Code-Beispiele im Internet. Hinzu kommt, dass die Software-Entwickler in der Embedded-Welt in der Regel keine Informatiker, sondern Ingenieure sind, zu deren Ausbildung die C/C++-Programmierung gehörte. Und darüber hinaus gilt in vielen Firmen: Das haben wir schon immer so gemacht.
„Gehen Sie auf LOS zurück“
Durch den Einsatz von C/C++ und die dadurch typischen Hardware-Abhängigkeiten fangen die meisten Entwickler bei jedem Projekt oder nach einem Hardware-Redesign praktisch wieder von vorne an. Größere Code-Bausteine lassen sich in der Regel nicht direkt wiederverwenden, sondern bestenfalls portieren. Zu beachten ist auch, dass die Halbleiterhersteller laufend neue Mikrocontroller- und Peripheriebausteine präsentieren, deren durchschnittliche Lebensdauer zum Teil gerade einmal drei bis fünf Jahre beträgt. Der Lebenszyklus von Embedded-Systemen in der Automatisierung liegt aber oft oberhalb von zehn Jahren. Da kann es sogar vorkommen, dass im gleichen Gerät über die Produktlebensdauer mehrere unterschiedliche Mikrocontroller und I/O-Bausteine zum Einsatz kommen. Es ist daher nicht weiter verwunderlich, dass für einige Produkte die Embedded-Software innerhalb von zehn Jahren mehr als einmal entwickelt wurde.
Neuere Computermodule (COMs) bieten zusammen mit Betriebssystem und zusätzlichen Laufzeitumgebungen auch gleich ein entsprechendes Schichtenmodell für größere Projekte. Dabei werden allerdings völlig unterschiedliche Ansätze verfolgt. Sie reichen vom einfachen Embedded-Betriebssystem mit integriertem Spezialinterpreter bis zur virtualisierten Hardware mit mehreren Betriebssystemen für unterschiedliche Aufgaben. Bild 3 zeigt als Beispiel eine Modellvariante, die mit dem neu entwickelten eSOM/2586 aus der eSOM-200-Familie [5] zur Verfügung gestellt wird. Durch dieses Beispielmodell lassen sich auch sehr umfangreiche Projekte, die auf 32-bit-COM-Plattformen aufsetzen, effizient strukturieren und schnell realisieren. Auch die spätere Erweiterbarkeit um zusätzliche Funktionen wird berücksichtigt. Die unterste Ebene des Schichtenmodells wird durch die COM-Hardware – inklusive der Steckverbinder zur Integration auf ein Trägerboard – gebildet. Direkt darüber befindet sich ein Debian-Linux, das in einem 1-Gbyte-NAND-Flash gespeichert ist.
Der Einsatz moderner Programmiersprachen wie Java und C# erfordert in der Regel eine entsprechende Laufzeitumgebung innerhalb des Betriebssystems (JRE für Java, .NET für C#). Gleiches gilt für den Einsatz einer Soft-SPS oder eines integrierten Echtzeit-Kernels. Bei der Auswahl eines 32-bit-COM als Hardware-Plattform ist daher zu prüfen, ob die erforderlichen Laufzeitumgebungen als Zubehör zur Verfügung stehen. Ist das nicht der Fall, müsste man diese selbst integrieren oder integrieren lassen, was in vielen Fällen wirtschaftlich nicht sinnvoll ist.
Mit anderen Worten: Dem Anwendungsentwickler sollte ein COM mit Embedded-Betriebssystem, sämtlichen Treibern und den entsprechenden Laufzeitumgebungen zur Verfügung stehen. Darüber hinaus sollten vor der Entwicklung klare Regeln formuliert werden. Zum Beispiel:
- Keine direkten Hardware-Zugriffe aus der Anwendungsschicht.
- Sämtliche anwendungsbezogenen Treiber kommunizieren per RAM-Disk mit der Anwendung.
- Alle Anwendungkomponenten werden in einer separaten Umgebung sofort hinsichtlich Hardware- und Plattform-Unabhängigkeit getestet.
Wiederverwendbare Software verbessert die Qualität
Jede Entwicklungsaufgabe lässt sich in unterschiedliche Teilaufgaben zerlegen. Größere Teilaufgaben können je nach Vorgehensweise weiter untergliedert werden. Das Ergebnis ist in der Regel eine umfangreiche To-do-Liste, die durch einen oder mehrere Entwickler bearbeitet wird. In dieser frühen Phase einer Entwicklung ist bereits eine Prüfung erforderlich, was wiederverwendet werden kann und was nicht. Typische wiederverwendbare Funktionsbausteine eines Embedded-Systems, die sich mit Hilfe von Java, C#, HTML, JavaScript, Java Servlets, AJAX, PHP, Python, Lua usw. implementieren lassen, sind:
Benutzerschnittstellen: Praktisch jedes Embedded-System muss mindestens ein Interface für den Dialog mit dem Benutzer aufweisen. Je nach Aufgabenstellung kann es sich hier um eine webbasierte Schnittstelle, einen speziellen Kommandozeilen-Interperter (CLI = Command Line Interface), ein binäres Kommando-API (Application Programming Interface, das per USB-, UART- oder LAN-Schnittstelle mit einer weiteren Software-Komponente auf einem anderen Rechner kommuniziert) oder um eine Bildschirmoberfläche (Human Machine Interface) mit LCD und ein paar Tasten oder mit einem Touchscreen handeln.
- Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
- Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
- Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
