Werkzeuge für das Systemdesign
Gratwanderung zwischen Zeit und Funktionalität
Mit der Zunahme an Komplexität von Embedded-Systemen steigt meist auch die Komplexität traditioneller Softwarewerkzeuge. Zu den daraus resultierenden Herausforderungen zählen das Programmieren unterschiedlicher Arten von Verarbeitungstechnologien, die in einem komplexen System zusammenarbeiten müssen, das Abwägen zwischen Funktionsanforderungen und Markteinführungszeit sowie zwischen Validierungstests und Robustheit. Des Weiteren müssen Entwickler sicherstellen, dass die Teammitglieder das für das Projekt benötigte Know-how mitbringen. Systementwickler benötigen daher weniger, aber produktivere Werkzeuge, die erlauben, mehr Zeit für das Entwickeln von Algorithmen aufzuwenden als auf die Integration von Hard- und Software.
Bild: National Instruments Germany GmbHSoftware-Umgebungen für das Systemdesign dienen dem Entwurf und Test einer Bandbreite von Mess- und Steuersystemen. Sie bieten die Möglichkeiten der Integration mit vorhandener Software, IP und Hardware, während sie zugleich mit aktueller Technologie verwendet werden können. Diese Software-Umgebungen verfügen über die Werkzeuge, die zur Lösung der aktuell beim Systementwurf auftretenden Probleme benötigt werden. Diese Softwarewerkzeuge lassen sich in spezifische Hardwarearchitekturen und modulare Plattformen integrieren, sodass vom frühen Prototyp bis zum endgültigen Einsatz die Produktivität maximiert wird und Software wiederverwendet werden kann. Aufgrund der validierten Hard- und Softwareintegration entfällt die Notwendigkeit, spezialisierte Treiber und Middleware für alle Arten von I/O und Peripherien zu entwickeln. Auf diese Weise können Embedded-Designer schnell mit der Entwicklung ihrer spezifischen Anwendung beginnen. Folgende Funktionen und Funktionalität müssen Softwareumgebungen für das Systemdesign aufweisen:
- • 1. Unterstützung einer Vielzahl von Verarbeitungselementen, z.B. Mikroprozessoren, FPGAs und GPUs
- • 2. Bereitstellung eines vollständigen Satzes von Systembeschreibungsmethoden
- • 3. Simulationsfunktionen
- • 4. Werkzeuge für die Erstellung von Benutzeroberflächen
- • 5. Bewältigung von Systemeinsatz und -wartung
Während sich die Verwendung von Field-Programmable Gate Arrays (FPGA) gemeinsam mit Mikroprozessoren (MPUs) als ideal für viele anspruchsvolle Steuer-, Regel- und Überwachungssysteme erwies, erforderten FPGA und MPU unterschiedliche Sprachen und spezielle Kenntnisse für die Programmierung. Heutzutage ermöglicht der Einsatz einer Systemdesignsoftware wie LabView die Systementwicklung für beide Verarbeitungselemente in einer einzigen Umgebung.
Zeitfaktor versus korrekte Arbeitsweise
Der gesamte Entwicklungsprozess stellt eine Art Tauziehen zwischen Zeitfaktor und korrekter Arbeitsweise dar. In frühen Stadien, scheinen diese beiden Seiten besonders weit auseinanderzuliegen. Architekten erstellen aus diesem Grund anhand ihrer Konstruktionsmodelle u.a. dreidimensionale Gebäudemodelle. Ein Gebäudemodell kann einen vollständigen Überblick über das finale Design zu geringen Kosten geben und ermöglicht es so allen Interessengruppen, Beiträge zu dem kreativen Prozess beizusteuern. Im Embedded-Bereich entspricht das dreidimensionale Gebäudemodell dem funktionstüchtigen Prototyp. Dieser ist mit Hardware-I/O und Sensoren verbunden und führt die aktuelle Iteration des entwickelten Algorithmus aus. Ingenieure können mit diesem Prototypen realistischere Tests durchführen, um Probleme früher zu erkennen. Dass durch Softwaresimulation kritische Designfehler nicht erkannt wurden, erklärt u.a., warum die Erstellung funktionsfähiger Prototypen von Steuer- und Regelsystemen so wichtig ist, auch wenn das Aufspüren von Problemen bei Algorithmen noch immer mit der Markteinführungszeit vereinbar sein muss. Der Designprozess des klassischen Programmierers von Ablaufdiagrammen bis hin zu Pseudo-Code kommt, bezogen auf das Architekturbeispiel, eher einer Skizze gleich als einem Modell. Der Low-Level-Aufbau von C erfordert viel Organisation, bevor die eigentliche Algorithmenentwicklung beginnen kann. Sehr zeit- und kostenintensiv zeigt sich die Speicherverwaltung, das Erzeugen von Threads und die Kommunikation mit I/O-Elementen. Der Abstraktionsgrad, den Entwicklungswerkzeuge auf Systemebene bieten, unterstützt Anwender hingegen auf unterschiedliche Weise bei der Entwicklung neuer Ideen. Sie gestatten, mehr Zeit mit der Algorithmenerstellung als mit der Konfiguration einer Softwarearchitektur zu verbringen. Zum anderen bietet Systemdesignsoftware häufig vorgefertigtes IP für Funktionen, die dem Industriestandard entsprechen. Daher können sich Programmierer auf das neue Problem konzentrieren und müssen sich nicht um Probleme kümmern, denn der Markt stellt bereits Lösungen. Zusätzlich zur beschleunigten Markteinführung sind Entwickler in der Lage, ein finales Zielsystem auszuwählen, das sich von ihrer Prototypenplattform unterscheidet und nur minimale Softwareänderungen erfordert.
Bild: National Instruments Germany GmbHPlattform aus Hardwarekomponenten
Aus den bereits genannten Gründen entscheiden sich viele Entwickler von Embedded-Systemen für ein abstraktes Entwicklungswerkzeug auf Systemebene zur Prototypenerstellung. Anschließend verwerfen sie das Ergebnis und entwickeln das gesamte Projekt in C zur finalen Übertragung auf das Zielsystem neu. Könnten Ingenieure den als Prototyp erstellten Programmcode bereinigen und einsetzen, würde dies zu einer unglaublichen Zeitersparnis führen. Bei manchen Entwürfen kann dieser Wechsel erforderlich sein. Doch andere Programmierwerkzeuge zu verwenden, kostet zusätzlich zur Programmierung des Algorithmus mit einer neuen Programmiersprache Zeit. Einer der Vorteile der Programmiersprache C ist deren Eignung für eine große Bandbreite an Hardware. Es ist allerdings extrem aufwendig, den Programmcode an die entwickelte Hardware anzupassen. Zusätzlich umfassen heutzutage viele Entwürfe Verarbeitungs- und Logikgeräte, beispielsweise. FPGAs, CPLDs und DSPs, die zusätzliche Software-Compiler und Assembly-Pakete erfordern. Systemdesignsoftware steht häufig mit einer Plattform aus Hardwarekomponenten zur Verfügung. So kann schneller entwickelt werden, die Flexibilität bei der Entwurfsoptimierung bleibt jedoch erhalten. Labview z.B. ist eine Systemdesignsoftware, die eine große Vielfalt von Technologien von Intel, Freescale, ARM, TI und ADI mithilfe der Embedded-Hardware NI Compactrio unterstützt. Aufgrund von Labview und Compactrio besteht keine Notwendigkeit für das Low-Level-Management von DMA-Transfer, VHDL-Programmierung und Speicherverwaltung. Denn deren Implementierung ist zeitintensiver, jedoch sind sie selten Teil des 'neuen IP' auf dem Markt. Entwickler von Steuerungen und Regelungen, die die gleichen Entwicklungswerkzeuge auf Systemebene für die Prototypenerstellung und Implementierung nutzen, sind in der Lage, die Produktivitätsbarriere zu überwinden und die Markteinführung deutlich zu beschleunigen.
Zukunftssicher durch Software-Abstrahierung
Die zu Version 2.0 hinzuzufügenden Funktionen stehen schon fest, bevor Version 1.0 auf den Markt gebracht wurde. Daher sollten Entwickler von Embedded-Systemen Systemupgrades einplanen und bereits früh die Architektur entwerfen, um den Programmcode zu einem späteren Zeitpunkt zu ergänzen oder zu ändern. Die häufigste Methode, um Programmcodes zukunftssicher zu machen, ist die Software-Abstrahierung: Entwicklungswerkzeuge auf Systemebene sind inhärent abstrakt und daher bei richtigem Einsatz für zukünftige Upgrades förderlich. Nicht alle Änderungen, die an einem Entwurf vorgenommen werden, sind geplant. Im Verlauf eines Designprozesses sind individuelle Komponenten und Technologien von der Lebenszyklusplanung abhängig. Außerdem können Komponentenänderungen, je nach Technologie, den Bedarf an Softwareupgrades anstoßen. Systemdesignsoftware von nur einem Anbieter wird alle Softwarekomponenten verwalten. Ohne diese Verwaltung müssen traditionelle Entwickler die Kompatibilität von Compilern, Assemblern und anderen Low-Level-Softwarewerkzeugen verfolgen. Dies erhöht noch stärker das Risiko einer Neuentwicklung aufgrund eines End-of-Life-Problems.
Kosten-Nutzen-Rechnungen: mehr als Umsatz und Profit
Die Rendite stellt einen der wichtigsten Kalkulationsposten für ein Projekt dar. Durch den Einsatz der klassischen Programmiersprache C und firmeneigener Hardware für die Entwicklung von Embedded-Systemen lassen sich die Kosten senken, wenn man nach Megabyte im RAM, CPU-Auslastung oder benötigten Hardwarekomponenten geht. Doch das Designteam wird dennoch mehr Zeit benötigen und insgesamt höhere Gesamtkosten haben. Auch die Anzahl der Teammitglieder wird steigen, da für die VHDL-Programmierung, die DSP-Assemblersprache, die Integration des Echtzeitbetriebssystems und die Steuerungsalgorithmen verschiedene Experten benötigt werden. Abbildung 2 zeigt die unterschiedlich hohe Komplexität einer Systemdesignsoftware und eines für ein Zielsystem spezifisches Low-Level-Programmierwerkzeug. Doch die Kosten-Nutzen-Berechnungen bei der Markteinführungszeit umfassen mehr als nur Umsatz und Profit: Als Erster auf dem Markt kann man den größeren Marktanteil erhalten oder als Zweiter vielleicht das bessere Produkt bieten, aber zu spät als Marktführer erkannt werden und daher in die Me-too-Falle tappen. Fokussieren Entwickler sich auf vereinfachte Komplexität und den Entwurf von neuem IP anstatt auf die Optimierung allgemeiner Programmierkonstrukte, kann Systemdesignsoftware Anwender dabei unterstützen, als Erster auf dem Markt zu sein und das beste Produkt zu bieten.
Mit der Zunahme an Komplexität von Embedded-Systemen steigt meist auch die Komplexität traditioneller Softwarewerkzeuge. Zu den daraus resultierenden Herausforderungen zählen das Programmieren unterschiedlicher Arten von Verarbeitungstechnologien, die in einem komplexen System zusammenarbeiten müssen, das Abwägen zwischen Funktionsanforderungen und Markteinführungszeit sowie zwischen Validierungstests und Robustheit. Des Weiteren müssen Entwickler sicherstellen, dass die Teammitglieder das für das Projekt benötigte Know-how mitbringen. Systementwickler benötigen daher weniger, aber produktivere Werkzeuge, die erlauben, mehr Zeit für das Entwickeln von Algorithmen aufzuwenden als auf die Integration von Hard- und Software.
Bild: National Instruments Germany GmbHSoftware-Umgebungen für das Systemdesign dienen dem Entwurf und Test einer Bandbreite von Mess- und Steuersystemen. Sie bieten die Möglichkeiten der Integration mit vorhandener Software, IP und Hardware, während sie zugleich mit aktueller Technologie verwendet werden können. Diese Software-Umgebungen verfügen über die Werkzeuge, die zur Lösung der aktuell beim Systementwurf auftretenden Probleme benötigt werden. Diese Softwarewerkzeuge lassen sich in spezifische Hardwarearchitekturen und modulare Plattformen integrieren, sodass vom frühen Prototyp bis zum endgültigen Einsatz die Produktivität maximiert wird und Software wiederverwendet werden kann. Aufgrund der validierten Hard- und Softwareintegration entfällt die Notwendigkeit, spezialisierte Treiber und Middleware für alle Arten von I/O und Peripherien zu entwickeln. Auf diese Weise können Embedded-Designer schnell mit der Entwicklung ihrer spezifischen Anwendung beginnen. Folgende Funktionen und Funktionalität müssen Softwareumgebungen für das Systemdesign aufweisen:
- • 1. Unterstützung einer Vielzahl von Verarbeitungselementen, z.B. Mikroprozessoren, FPGAs und GPUs
- • 2. Bereitstellung eines vollständigen Satzes von Systembeschreibungsmethoden
- • 3. Simulationsfunktionen
- • 4. Werkzeuge für die Erstellung von Benutzeroberflächen
- • 5. Bewältigung von Systemeinsatz und -wartung
Während sich die Verwendung von Field-Programmable Gate Arrays (FPGA) gemeinsam mit Mikroprozessoren (MPUs) als ideal für viele anspruchsvolle Steuer-, Regel- und Überwachungssysteme erwies, erforderten FPGA und MPU unterschiedliche Sprachen und spezielle Kenntnisse für die Programmierung. Heutzutage ermöglicht der Einsatz einer Systemdesignsoftware wie LabView die Systementwicklung für beide Verarbeitungselemente in einer einzigen Umgebung.
National Instruments Germany GmbH
Dieser Artikel erschien in Embedded Design I 2015 - 19.01.15.Für weitere Artikel besuchen Sie www.embedded-design.net
