Schwerpunkte

Seit 25 Jahren erfolgreich

Den Code-Fehlern auf der Spur

26. Oktober 2015, 10:24 Uhr   |  Manne Kreuzer


Fortsetzung des Artikels von Teil 1 .

Andere Wege

Hat PLS neben dem modularen Tool-Ansatz auch nach anderen Wegen gesucht, Entwicklern ihre Arbeit zu erleichtern?

Dr. Stefan Weiße: Ja, wir waren beispielsweise 1991 das erste Unternehmen, das einen unter DOS laufenden HLL-Fullscreen-Debugger auf dem Markt brachte, bereits zwei Jahre später folgte der ersten Windows-basierte Debugger für die legendären C166/ST10-Mikrocontroller. Wir waren auch mit die ersten Debugger-Anbieter, die schon 1997/98 damit begannen, sich intensiv mit den Herausforderungen künftiger Multicore-Architekturen zu beschäftigen. Infineon hatte bereits sehr frühzeitig erkannt, wohin die Reise einmal führen wird, und PLS war das erste externe Unternehmen, das die damals bahnbrechende Raptor- und spätere Tricore-Architektur unterstützte. Das wir heute im Bereich der High-End-Multicore-Architekturen international anerkannt zu den Technologieführern unter den Tool-Anbietern zählen, hängt sicherlich auch damit zusammen, dass wir uns in enger Zusammenarbeit mit der Technischen Universität Dresden, der Brandenburgischen Technischen Universität, anderen wissenschaftlichen Institutionen und führenden Mikrocontroller-Herstellern nach wie vor noch immer sehr stark mit den neuesten Erkenntnissen der Halbleiterpyhsik auseinander setzen und daher ein gutes Gefühl dafür haben, wie die nächsten und übernächsten SoC-Generation in etwa aussehen werden. Vorsprung durch Wissen, mit dieser Philosophie sind wir bisher erfreulicherweise sehr erfolgreich gewesen, und wir hoffen natürlich, dass das weiterhin so bleibt.

Welche Paradigmenwechsel haben die vergangenen 25 Jahre am meisten geprägt?

Thomas Bauch: Den vielleicht grundlegendsten Paradigmenwechsel haben definitiv die ersten Windows-basierten Betriebssysteme eingeläutet. Stark prägend und bis heute nachwirkend waren natürlich auch das für Debug-Zwecke benutzte JTAG-Protokoll und der sich ab dem Jahr 2000 verstärkt abzeichnende Trend hin zu Multicore-Architekturen. PLS über all die Jahre am meisten beeinflusst hat allerdings die in den neunziger Jahren getroffene grundlegende Entscheidung, Entwicklern Werkzeuge anzubieten, die ausschließlich auf den Debug-und-Trace-Funktionen auf dem Chip basieren. Vorläufer war das Monitor basierte Debugging als leistungsfähige Alternative zu den klassischen Bondout-Chip-Emulatoren. Uns war klar, dass wir durch die Fokussierung auf den gezielten und qualifizierten Support von On-Chip-Debug-Funktionalität vermutlich erst einmal Markteinteile einbüßen würden, aber wir waren damals 100-prozentig überzeugt, dass dies die richtige Entscheidung zu richtigen Zeitpunkt ist. Heute wissen wir, dass wir mit dieser Einschätzung goldrichtig lagen.

Alles in ein Produkt zu packen und damit alles auf eine Karte zu setzen, ist das nicht riskant?

Thomas Bauch: Nein, im Gegenteil. Das strikt modulare Konzept von Universal Debug Engine erleichtert natürlich die Implementierung neuer Architekturen und Funktionen. Zudem ist Universal Debug Engine ja auch kein Einzelprodukt, sondern der Markenname für ein umfangreiches Framework, unter dem wiederum eine ganze Reihe von Produkten oder Produkterweiterungen zusammengefasst sind. Ein Beispiel ist das UDE-MemTool, ein sehr erfolgreiches, auch völlig autark einsetzbares Produkt, das weltweit in großen Stückzahlen zum Einsatz kommt und eine schnelle und zuverlässige Flash-Programmierung von fertiggestellten Produktbaugruppen ermöglicht. Wir haben also viele verschiedene Produktfacetten mit einem modularen, standardisierten Kern, die sich je nach Anforderung des Kunden zur Systembeobachtung, zum Testen und zum Debuggen in den verschiedenen Lebenszyklen des Zielsystems eignen.

Gilt dies auch für automatisierte Softwaretests?

Dr. Stefan Weiße: Ja, natürlich. Wir beobachten schon seit geraumer Zeit, dass dieser Aspekt angesichts immer komplexer Applikationen vor allem für international agiernde Unternehmen, bei denen sich die Entwicklung auf mehrere Standorte verteilt, eine immer wichtigere Rolle spielt und haben mit entsprechenden Tool-Optimierungen auch längst auf diesen Trend reagiert. So wurden unter anderem Schnittstellen für die Fernsteuerung der UDE implementiert, um auch in Kombination mit Third-Party-Tools verschiedenster Hersteller automatisierte Tests komplexer Software-Funktionsmodule durchführen zu können. Damit lassen sich beispielsweise bei der komplexen Verifikation der Programmstände von Steuergerätesoftware mit Hilfe von UDE nach jedem Testbild automatisierte Testläufe durchführen, die überprüfen, ob die geforderten Funktionsparameter der Software auch wirklich kontinuierlich eingehalten werden. Dem Thema automatisierte Software-Tests messen wir große Bedeutung bei, da wird die nächsten Jahre noch vieles passieren.

 

©

Thomas Bauch, PLS:» Das strikt modulare Konzept von Universal Debug Engine erleichtert die Implementierung neuer Architekturen und Funktionen.«

Seite 2 von 3

1. Den Code-Fehlern auf der Spur
2. Andere Wege
3. Auswirkungen von IoT und Industrie 4.0

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Das könnte Sie auch interessieren

Infineon eines der nachhaltigsten Halbleiterunternehmen
Industrie 4.0: Harmonie oder Dissonanz?
IoT: Erst an das Geschäft denken

Verwandte Artikel

pls Programmierbare Logik & Systeme GmbH, Infineon Technologies AG, Cadence Design Systems GmbH, Mentor Graphics (Deutschland) GmbH Mechanical Analysis Div.