Standardisierte Architekturen und Schnittstellen sollen komplexe Systeme beherrschbar machen
Status Quo AUTOSAR
Fortsetzung des Artikels von Teil 3
Status Quo AUTOSAR
In der Übergangsphase wird die Anwendungssoftware sowohl bisherige als auch neue Standardkomponenten unterstützen. Verschiedene Mischformen sind je nach OEM denkbar: So möchte OEM A möglichst wenig Änderung, aber eine Kompatibilität zu AUTOSAR auf dem Bus herstellen. OEM B hingegen behält Komponenten mit sehr viel Interaktion auf dem Bus im ersten Schritt bei, um die Kompatibilität zu bestehenden Steuergeräten zu erhalten. Auch für Zulieferer sind verschiedene Szenarios denkbar, um auf die zukünftigen Anforderungen ihrer Kunden zu reagieren oder ihnen sogar zuvor kommen.
Jobangebote+ passend zum Thema
Eine Möglichkeit ist der frühe Umstieg auf die RTE. Dadurch wird die Anwendung weitgehend unabhängig von den darunter liegenden Schichten. Allerdings verlagert sich der Aufwand in Richtung RTE. Diese muss die darunter liegenden Varianten unterstützen, sofern die Varianten nicht bereits ein AUTOSAR-konformes API zur RTE zur Verfügung stellen. Die Applikationsentwicklung mit einer RTE bietet sich für den Zulieferer bereits heute an. Er kann sich unabhängig vom Fahrzeughersteller dafür entscheiden und auf ein standardisiertes API aufbauen, noch bevor der OEM dies fordert. Damit ist er frühzeitig unabhängig von weiteren Migrationsschritten (Bild 4). Für die Konfigurationsdaten sind ebenfalls Migrationsschritte notwendig. So müssen heutige Standardformate wie DBC, LDF oder FIBEX in einheitliche AUTOSAR-XML-Formate überführt werden.
Die erste, im Frühjahr 2006 abgeschlossene AUTOSAR-Spezifikationsphase hat gezeigt, dass an den konzeptionellen Überlegungen kaum Veränderungen notwendig sind. Die derzeitige Validierungsphase 2 wird unter anderem Aufschluss geben, wie der Mehraufwand bei Speicher und Rechenlast der CPU im Steuergerät zu bewerten ist.
Entwicklungsumgebung für Ausführung und Simulation
Da sich der Standard als umfassender Entwicklungsansatz versteht, ist die Verwendung einer integrierten Entwicklungsumgebung (IDE) wie Visual Studio oder Eclipse als Basis für den gesamten Prozess nur konsequent. Als AUTOSAR-Entwicklungsumgebung sollte sie idealerweise eine Ausführungsplattform für einzelne Softwarekomponenten und eine Simulationsplattform für das Gesamtsystem bieten, ergänzt durch eine Steuer-, Test- und Visualisierungsumgebung (Bild 5).
Vorteile ergeben sich insbesondere durch die Möglichkeit, frühzeitig Tests durchzuführen. Anwender können schon während der Entwicklung komfortabel Testszenarios erstellen und müssen nicht erst die vollständige Implementierung der Softwarekomponenten abwarten. Testfälle lassen sich einzeln abarbeiten und Software wird sowohl einzeln als auch integriert aus der IDE kontrolliert ausgeführt. Durch die Fähigkeit, dies langsamer oder schneller als in Realzeit auszuführen, ist ein effektives Debugging möglich; eine Vielzahl automatisierter Tests ist in kurzer Zeit durchführbar. Mit der Anbindung von CANoe an die IDE können die gleichen Testfälle mit Teilsystemen auch unter Einbeziehung realer Netzwerke ausgeführt werden.
Die Kernidee von AUTOSAR ist es, durch Standardisierung die wachsende Komplexität der Software in modernen Fahrzeugen zu beherrschen. Das Ziel, eine offene Referenzarchitektur für Steuergeräte-Software zu definieren, wird mit dem ersten vollständigen Release 2.1 Ende 2006 erreicht. Durch Standardisierung und eindeutig spezifizierte Schnittstellen zwischen den Basissoftwaremodulen und zur Applikationssoftware ergeben sich viele Möglichkeiten wie etwa die Wiederverwendbarkeit der gleichen Software für verschiedene Mikrocontroller und Applikationen bei gleichzeitig steigender Qualität.
Für alle bei der AUTOSAR-konformen Software-Entwicklung notwendigen Entwurfsschritte bietet Vector die entsprechende Lösung, vom strukturierten Entwurf der AUTOSAR-Softwarekomponenten und deren Verteilung auf Steuergeräte, über die Definition der Kommunikation bis hin zur Konfiguration der effizienten Basissoftware. Der Migrationsaspekt ist dabei ein wichtiger Schwerpunkt. So kann der Anwender vorhandene Entwurfsdaten in Formaten wie z.B. DBC oder FIBEX mit AUTOSAR-Entwurfsdaten kombinieren und existierende Basissoftware in AUTOSAR BSW überführen. Die offene Lösung begünstigt nicht nur die Integration weiterer Werkzeuge in die Toolkette, sondern ermöglicht auch eine konsequente Weiterentwicklung der Tools gemäß der aktuellen AUTOSAR-Spezifikationen, an denen Vector durch aktive Mitarbeit im Konsortium richtungweisend beteiligt ist.
 | Dipl.-Ing. (FH) Matthias Wernicke studierte Industrieelektronik an der FH Ulm. Seit Anfang 2000 arbeitet er bei Vector Informatik und ist heute für das Produktmanagement der DaVinci Tool Suite verantwortlich. |
 | Dipl.-Ing. (FH) Jochen Rein studierte Technische Informatik an der Fachhochschule Esslingen und ist seit 1997 bei Vector tätig. Er ist Teamleiter in der Abteilung „Software Components“ und verantwortlich für den Bereich Produktmanagement AUTOSAR BSW und CANbedded. |
- Status Quo AUTOSAR
- Tool-Unterstützung für den Entwurf verteilter Funktionen
- AUTOSAR vereint Hardware, Basis- und Anwendungssoftware
- Status Quo AUTOSAR
