Automatisierte Entwicklung zertifizierungsfähiger Software Der ECU-Zulieferer im Wettbewer

AUTOSAR bietet Vorteile durch Standardisierung und Modularität. Der Standard erweist sich jedoch für etablierte Tier-1-Zulieferer als problematisch, weil sich damit die Applikationsebene von Automotive-ECUs in effizienter Weise standardisieren lässt. Diese können ihre Wettbewerbsfähigkeit nur durch Investitionen in Software-Tools wie neueste Trace-Debugger und effiziente Compiler sichern.

AUTOSAR bietet Vorteile durch Standardisierung und Modularität. Der Standard erweist sich jedoch für etablierte Tier-1-Zulieferer als problematisch, weil sich damit die Applikationsebene von Automotive-ECUs in effizienter Weise standardisieren lässt. Diese können ihre Wettbewerbsfähigkeit nur durch Investitionen in Software-Tools wie neueste Trace-Debugger und effiziente Compiler sichern.

Die AUTomotive Open System ARchitecture (AUTOSAR) standardisiert die grundlegenden Funktionen und Schnittstellen in Electronic Control Units (ECUs) für den Einsatz in Automobilen (Bild 1). Die Automobilhersteller können damit schnell und anbieterunabhängig mehr und komplexere Funktionen in neue Fahrzeuge implementieren. Die Modularität der standardisierten AUTOSAR-Schnittstellen und -Datentypen ermöglicht ein Vermischen und Anpassen von ECUs verschiedener Anbieter, bietet die Freiheit, bestimmte ECUs über Second Source zu beziehen oder den Hardware- und Software-Anbieter ohne hohen Kostenaufwand zu wechseln.

Für die Entwickler von Automotive-Systemen bietet AUTOSAR Vor- und Nachteile: Einerseits ist es damit möglich, neue Fahrzeugfunktionen mit elektronischen Steuerungen zu realisieren, andererseits wird den Tier-1-Zulieferern die Entwicklung von Kern-Funktionen einer ECU genommen. Für die AUTOSAR-Laufzeitkomponenten sind nur noch einige Software-Spezialisten verantwortlich, während die Tier-1-Entwickler sich auf die Applikations-Software konzentrieren.

In einem Embedded-Umfeld würde diese Situation dazu führen, dass die Applikationsentwicklung versuchen wird, stark differenzierende Produkte mit einen klarem „Wertangebot“ zu konzipieren. Im Automotive-Bereich ergibt sich jedoch eine völlig andere Situation: Da die Funktionen auf Applikationsebene durch den Fahrzeughersteller festgelegt werden, ist die Differenzierung bei der Produktintegration eingeschränkt; es bleiben Aspekte wie Liefertermin, Stromaufnahme und Kosten. Um die im Automotive-Bereich vorgeschriebenen Software-Sicherheitsstandards einzuhalten, werden Verfahren zur automatischen Code-Generierung genutzt; nur so lässt sich heute ein zertifizierbarer Code wirtschaftlich und innerhalb des vorgegebenen Zeitrahmens erstellen. Bei der Applikationsentwicklung treten die „Architekten für den Use-Case“ dabei in Konkurrenz mit den Programmierern, die zertifizierten Code nach der Spezifikationen des Fahrzeugherstellers generieren.

Um den Wert ihrer Entwicklungstätigkeit zu erhöhen, müssen die Tier-1-Zulieferer also neue Techniken und Verfahren einzusetzen. Die Tools zur automatischen Code-Generierung erzeugen aber in der Regel nur eine Teilmenge von Befehlen und Funktionen und nicht unbedingt den effizientesten Code. Dies kann zu einem größeren „Footprint“ oder zu einer niedrigeren Systemleistung führen als bei manuell optimiertem Code. Dass damit ein höherer Speicherbedarf einhergeht und auch höhere Taktfrequenzen erforderlich sind, wird in der Regel dann toleriert, wenn gewährleistet ist, dass ein fehlerfreier, zertifizierbarer Code schnell und ohne aufwendiges Prüfen und Debuggen generiert wird. In einer gängigen AUTOSAR-Hardware-Implementierung belegt der Speicher mehr als 70 Prozent der Chip-Fläche eines IC. Lässt sich durch Code-Optimierung der Speicherbedarf reduzieren, dann sinken damit auch die Herstellungskosten. Wird darüber hinaus die Ausführung des Codes beschleunigt, werden entsprechend geringere Taktfrequenzen benötigt; auch dies bringt niedrigere IC-Kosten mit sich.

Die neuesten Trace-, Debugging- und Optimierungs-Tools erlauben die Generierung und das vollständige Debuggen eines großen Teils des Applikations-Codes innerhalb eines wettbewerbsfähigen Zeitrahmens.

zurück zur Übersicht

Bild 2 zeigt den gängigen Design-Flow, der heute von Entwicklern zur Herstellung einer Standard-ECU angewendet wird. Ausgehend von der Spezifikation des Kunden wird über ein automatisiertes „Modelling“ der zertifizierbare Code erstellt. Dabei werden jedoch nicht alle Möglichkeiten des Prozessors genutzt, mit denen sich der Code hinsichtlich der Systemleistung optimieren ließe. Bei ECU-Entwicklungsprojekten, die nur mit mittelmäßigen Tools compiliert werden, etwa mit kostenlosen C-Compilern aus dem Internet, ist die Systemleistung des Codes zusätzlich eingeschränkt und die Entwicklungskosten können noch höher ausfallen. Diese Compiler erzeugen oft einen schlecht optimierten und damit ineffizienten Objekt-Code — so führt z.B. eine unzureichende Behandlung von Schleifen zu längeren Ausführungszeiten.