Wie man trotz immer komplexerer Produkteigenschaften die Entwicklungskosten senken kann
Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
Fortsetzung des Artikels von Teil 2
Hardware-Unabhängigkeit – Der Schlüssel zur guten Software
Die Rechenleistung eines 32-bit-COM hat in vielen Fällen einen nicht ganz so großen Stellenwert, wie man auf Grund der vielen am Markt verfügbaren Hochleistungs-COMs vermuten könnte. Die meisten Module sind deutlich schneller als erforderlich. In diesem Zusammenhang ist der für den Betrieb erforderliche Energiebedarf viel bedeutender (siehe hierzu auch die EuP-Richtline 2005/32/EG der EU [7], EuP = Energy using Products). Schließlich bestimmt die Rechenleistung auch den Aufwand zur Wärmeabfuhr und den Betriebstemperaturbereich.
Jobangebote+ passend zum Thema
Nach dem Projekt ist vor dem Projekt
Die Auswahl eines geeigneten Computer-on-Modules, das Vermeiden iterativer Vorgehensweisen, eine solide vorrausschauende Planung, die klassische To-do-Liste, strukturierte Aufgabenstellungen (nicht alle zu lösenden Probleme in einen Topf werfen), der Einsatz leistungsfähiger Programmiersprachen, die intensive Nutzung eines gut gepflegten firmeninternen Funktionsbaukastens und das hier vorgestellte Schichtenmodell führen zu wiederverwendbaren Software-Bausteinen. Der Vorteil eines solchen Modells und des Funktionsbaukastens: Die Software für das nächste Projekt muss nicht komplett neu entwickelt werden. Schließlich gilt am Ende der meisten Embedded-Entwicklungsprojekte: „Nach dem Projekt ist vor dem Projekt“. jk
Literatur
[1] Wörn, H.; Brinkschulte, U.: Echtzeitsysteme. Springer-Verlag, Berlin, Heidelberg 2005.
[2] Zeltwanger, H.: CANopen: Das standardisierte, eingebettete Netzwerk. VDE-Verlag 2008.
[3] Von Aspern, J.: SPS-Softwareentwicklung mit IEC 61131. Hüthig, Heidelberg 2000.
[4] Ullenboom, C.: Java ist auch eine Insel. Galilieo Press, Bonn 2007.
[5] Infos zur eSOM-200-COM-Familie: www.ssv-comm.de
[6] Walter, K.-D.: Embedded Internet in der Industrieautomation. Hüthig, Heidelberg 2004.
[7] EuP-Richtline der EU: www.elektroniknet.de/home/termine/foren/ecomise-it/
[8] Informationen zu JNI: html>http://java.sun.com/javase/6/docs/technotes/guides/jni/index.html
 | Klaus-Dieter Walter ist als Business Development Manager und Mitglied der Geschäftsleitung für die SSV Software Systems GmbH in Hannover im Produktbereich „Embedded Systems“ tätig. Er hat mehr als 20 Jahre Berufserfahrung im Bereich der Embedded-Systeme. kdw@ist1.de |
Nahezu jede Software-Aufgabe lässt sich in komplizierte und einfache Teilaufgaben zerlegen. Darüber hinaus kann Embedded-Software weiter in hardware-abhängig bzw. hardwarenah und hardware-unabhängig sowie zeitkritisch und zeitunkritisch (Echtzeit-Fähigkeit erforderlich oder nicht? [1]) unterteilt werden. Eine solche Strukturierung (Bild 1) ist für jedes Projekt sinnvoll und hilfreich. In der Regel entsteht dabei eine grobe Zweiteilung in
- zeitkritische und hardware-nahe Software-Komponenten (HWD-Layer) und
- zeitunkritische und hardware-unabhängige Funktionseinheiten (HWI-Layer).
Bei einem Embedded-System, das beispielsweise in einer Bedieneinheit mit CAN-Feldbus- und Ethernet-Schnittstellen zum Einsatz kommt, entfallen ca. 20 % des Software-Entwicklungsaufwands auf die erste (HWD-Layer) und die restlichen 80 % auf die zweite Kategorie (HWI-Layer).
Zu den zeitkritischen Aufgaben mit direktem Hardware-Bezug im HWDLayer (Zugriffe auf CAN-Controller, Reaktion auf Interrupts usw.) gehört beispielsweise die CAN-Kommunikation [2]. Diese Teilaufgabe sollte mit Hilfe von C/C++ bearbeitet werden, oder – falls anspruchsvollere Steuerungsprobleme zu lösen sind – mit Hilfe einer eingebetteten SPS (Software-SPS) und IEC 61131 [3]. Auch ein eigenständiger RTOS-Kernel (RTOS = Real-Time Operating System) als Laufzeitumgebung für die in C/C++ geschriebenen zeitkritischen Komponenten ist denkbar.
Die Realisierung sämtlicher Benutzerschnittstellen (Konfiguration, Betrieb) sowie die Integration in LANs und WANs (IT-Integration) sind vom Zeitverhalten her unkritisch und auch nicht direkt an eine bestimmte Hardware gebunden. Für diesen Funktionskomplex – also den HWI-Layer – eignen sich Java und C# sowie bei webbasierten Benutzerschnittstellen HTML, JavaScript, Java Servlets, AJAX, PHP, Python, Lua usw.
Die bidirektionale Kommunikation zwischen den in Java oder C# geschriebenen IT- und Benutzerschnittstellen im HWI-Layer sowie einer in C/C++ entwickelten CAN-Kommunikation im HWD-Layer kann zum Beispiel mit Hilfe einer RAM-Disk erfolgen (Bild 2). Sie ist in fast jedem Embedded-Betriebssystem über das Dateisystem verfügbar. Durch ein solches Bindeglied lässt sich die Entwicklung der Teilaufgaben recht einfach parallelisieren, da die Strukturen und Daten einer RAM-Diskdatei sehr einfach simulier- bzw. emulierbar sind. Um per Java auf die Hardware zuzugreifen, wird mittels „Java Stream I/O“ [4] in eine Datei auf der RAM-Disk geschrieben oder aus dieser Datei gelesen. Im HWD-Layer läuft eine in C/C++ geschriebene Komponente als Gegenstück. Diese liest ein Datum aus der Datei und schreibt die entsprechenden Werte zur jeweiligen Hardware-Ressource und umgekehrt.
- 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
