Vielfältige Entwicklungschancen
Wohin geht der Trend in der Entwicklungssystem-Branche?
Fortsetzung des Artikels von Teil 1
Wohin geht der Trend in der Entwicklungssystem-Branche?
Connectivity
Auch die Entwicklungssystem-Spezialisten von iSystem sind überzeugt, dass intensives Testen zum Auffinden von Softwarefehlern immer mehr Raum im Gesamtentwicklungsprozess einnehmen wird. Getrieben werde dies u.a. durch die vielen unterschiedlichen Normen, die immer wieder neu aufgelegt bzw. angepasst werden, um Systeme einschließlich Software sicherer zu machen. »Diese Normen haben erheblichen Einfluss auf den eigentlichen Entwicklungsprozess und besonders auf den vorgeschriebenen Umfang des Testens - und damit auch darauf, wie ein Entwicklungswerkzeug der Zukunft aussehen wird«, erklärt Erol Simsek. »Entwicklungstools im klassischen Sinne müssen deshalb heute vielseitiger einsetzbar sein denn je. Ein gutes Beispiel hierfür sind In-Circuit-Emulatoren (ICE) und On-Chip-Debugger (OCD) wie wir sie herstellen und vertreiben: Früher ausschließlich von Mikrocontroller-Experten als hardware-nahes Entwicklungswerkzeug eingesetzt, findet man diese Tools heutzutage zunehmend in den unterschiedlichsten Situationen einer Softwareentwicklung wieder.« Dabei sei der ICE bzw. OCD nach wie vor die Verbindung zur eigentlichen Zielhardware über Standard-Debug-Schnittstellen mit dem Zweck, Embedded-Software so nah wie möglich auf der eigentlichen Hardware zu simulieren, zu implementieren und zu testen.
»Neben der einfachen Schnittstellenfunktion zur Zielhardware stellen ICE und OCD schon lange Funktionen zur professionellen Fehlersuche und damit zum Testen einer Software zur Verfügung«, verdeutlicht Simsek. »Dabei kann der Entwickler die Ausführung der laufenden Software nachverfolgen. Dazu kann der Programmzustand inspiziert, sowie die Ausführung des Programms unter bestimmten Bedingungen angehalten werden. Dies geschieht ohne bzw. mit nur minimaler Beeinflussung der untersuchten Software.« Professionelle Debug-Lösungen, wie iSystem sie anbietet, ermöglichen Kunden zudem die Aufzeichnung von Abläufen in der Software in Echtzeit (Tracing), das Protokollieren von Ausführungszeiten im Bereich von Taktzyklen, sowie die für das Testen relevante Beurteilung der abgearbeiteten Teile der Software (Code Coverage).
Jobangebote+ passend zum Thema
»Damit ein Kunde all diese Funktionen flexibel nutzen kann, müssen Toolhersteller generische Schnittstellen zur Verfügung stellen, die die Integration dieser Werkzeuge in den Entwicklungs- und Testprozess des Kunden ermöglichen«, so Simsek. »Diese Schnittstellen müssen sich zur Lösung verschiedenster Aufgaben wie etwa entwickeln, testen, verifizieren und validieren von Software und Hardware eignen. Hierbei geht der Trend hin zur Unterstützung einer Vielzahl von Programmier- bzw. Scriptsprachen zur ‚Fernsteuerung’ des Entwicklungstools aus einer anderen, auch kundenspezifischen Anwendung. Im Prinzip lassen sich dann Prozessteile sowohl während der Entwicklung, als auch während des Tests automatisieren.«
- Beispiel: Connectivity für Softwaretest
Ein Testprozess dient dem Aufspüren von Anomalien in der getesteten Software und lässt sich grob unterteilen in Testerstellung (Design) und Testausführung (Deployment). Zur Testerstellung kommen meist grafische Modellierungssprachen wie etwa UML zum Einsatz. Sie ermöglichen eine direkte grafische Beschreibung von Testfällen oder die Erstellung eines Testmodells. »Der Trend ist, das klassische Entwicklungssystem ICE oder OCD in eine Test-Execution-Engine auszubauen, die aus einem solchen Testmodell zum Teil automatisiert erstellte Testvektoren entgegennehmen, ausführen und das Ergebnis wieder zurückführen kann«, so Simsek. »Dabei werden diese Tests ohne Instrumentierung des Programmcodes - wie sonst bei Testwerkzeugen üblich - ausgeführt.«
- Beispiel: Connectivity für Hardware-Komponententest in der Produktion
»Um den Herausforderungen des zukünftigen Testens von Hardware-Baugruppen gerecht zu werden, geht der Trend dahin, Boundary-Scan und JTAG-Emulation - also die Nutzung des Mikrocontrollers für dynamische Tests von z.B. Flash - zu kombinieren«, erklärt der Experte. »Für diese Verschmelzung ist umfassendes Mikrocontroller-Know-how nötig. Emulator- und Debuggerhersteller wie iSystem haben dieses Know-how über viele Jahre aufgebaut. Es kommt deshalb zunehmend zu Technologie-Partnerschaften auf diesem Gebiet, wie z.B. der zwischen der Göpel Electronic in Jena und iSystem.«
Vernetzung über das Internet
Ein weiteres aktuelles Thema ist die Vernetzung von Embedded-Systemen über das Internet, wobei sich hier inzwischen Embedded Linux als Quasi-Standard etabliert hat. »Eines der Hauptprobleme bei vernetzten Systemen ist jedoch nach wie vor die Fehlersuche im Grenzbereich zwischen Kernel und Applikation«, führt Riessland aus. »Deshalb fokussieren wir uns nicht nur auf Lösungen für die Kernel- und Kernel-Treiber-Entwicklung, sondern beziehen auch das Applikations-Debugging mit ein.« Bei pls kommt hierfür ein modifizierter gdb-Server zum Einsatz. Auf diesem Weg können Kernel-Module dynamisch zur Laufzeit nachgeladen und getestet werden. Zudem steht Anwendern der pls Universal Debug Engine auch die konventionelle Linux-Konsole zur Verfügung. Die Verbindung zum Kernel erfolgt über JTAG, wodurch die sonst dafür übliche serielle Schnittstelle nicht belegt werden muss. Auch die unterschiedlichen Tools von pls sind vernetzt nutzbar: Die Debug-Geräte Universal Access Device UAD2+ und UAD3+ können z.B. auch via Ethernet mit dem Host-PC verbunden werden, was den Einsatz etwa in Prüffeldern erleichtert.
Standardisierte Entwicklungsumgebungen
»Im High-End-Bereich sind Entwickler aus Effizienz- und Qualitätsgründen immer öfter gezwungen, mit mehreren verschiedenen Prozessorarchitekturen zu arbeiten«, merkt Riessland an. »Das hat zur Folge, dass der Ruf nach standardisierten, Architektur- und Toolanbieter-unabhängigen Entwicklungsumgebungen immer lauter wird.« Nach Riesslands Überzeugung lässt sich dieser Aspekt mit der modularen und nahezu uneingeschränkt erweiterbaren Eclipse-Plattform nachhaltig in den Griff bekommen. Ein speziell für die UDE Universal Debug Engine entwickeltes und als Feature-Installation-Package angebotenes Eclipse-Plug-in sorgt dafür, dass die kompletten Funktionen der UDE als Cross Debugger auch unter Eclipse ohne Abstriche erhalten bleiben. Dieses Plug-in ist für alle von der UDE Version 2.6 unterstützten Mikrocontroller-Architekturen und -Familien verfügbar, wobei sogar die Verwaltung mehrerer Debugger-Instanzen für Multicore-Debugging ohne Einschränkungen unterstützt wird. Darüber hinaus ist das Tool sowohl in vorkonfigurierten Installationen, die auf der Eclipse-Platform 3.4 (Ganymede) und Eclipse C/C++ Development Tools (CDT) 5.0 basieren, als auch auf selbst konfigurierten Eclipse-CDT-Plattformen erhältlich.
Es kommt nicht nur auf die Technik an
Dass es vor allem die enge Partnerschaft zwischen Toolhersteller und
Halbleiterhersteller ist, die dem Entwicklungssystem-Anbieter zum Erfolg verhilft, darin ist sich die Branche einig. Zudem gilt es aber, die über die technischen Aspekte hinaus gehenden Faktoren abzudecken. »Als wir vor einigen Jahren unseren Webshop eröffnet haben, wollten wir eigentlich nur einen weiteren Vertriebsweg bieten«, erklärt Frank Grobe. »Heute haben wir gelernt, dass gerade der schnelle und unkomplizierte Bestellprozess zu jeder Tages- oder Nachtzeit wichtig ist. So wird z.B. ein Applikationskit zur Antriebssteuerung heutzutage schon von vielen Kunden genauso schnell geordert wie ein Fachbuch im Online-Buchshop.«
Es bleibt also spannend in der Entwicklungssystembranche. Die Hersteller haben das große Potential erkannt und arbeiten weiterhin eng mit ihren Partnern zusammen, so dass rechtzeitig zur Vorstellung neuer Mikroprozessoren auch die passenden Entwicklungstools zur Verfügung stehen.
- Wohin geht der Trend in der Entwicklungssystem-Branche?
- Wohin geht der Trend in der Entwicklungssystem-Branche?
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
