Eine Grundbedingung für die Wiederverwendung von Software-Komponenten in unterschiedlichen, an verschiedene Bussysteme angeschlossenen ECUs ist eine klare Abgenzung zwischen Funktion und Kommunikation, denn die Funktionen sollten unverändert bleiben, während die Kommunikation von einem System zum anderen unterschiedlich sein kann. Diese Abgrenzung wird durch das Konzept des Virtual Function Bus (VFB) und seine technische Umsetzung, der Runtime Environment (RTE), erreicht.
In AUTOSAR werden zahlreiche Informationen über Software-Komponenten, ihre Schnittstellen, die Hardware-Topologie und die Verteilung der Software-Komponenten auf die ECUs in einem Modell zusammengefasst. Die verschiedenen Aspekte des Systems werden dabei in unterschiedliche Vorlagen (Templates) aufgeteilt. Damit stellt dieses Modell ausreichend Informationen zur Verfügung, um festlegen zu können, welche Komponente Informationen mit welchen anderen Komponenten austauscht und über welchen Informationskanal dies geschieht. Bei der RTE handelt es sich um eine Kommunikationsschicht, die sich um die Kommunikation zwischen den verschiedenen Software-Komponenten über unterschiedliche Bussysteme kümmert. Da sämtliche Informationen über diese Kommunikation im Modell enthalten sind, kann die RTE für diesen speziellen Zweck generiert werden. Als Konsequenz hieraus ist die RTE überaus schlank und enthält nur die tatsächlich benötigten Kommunikationsparadigmen. Damit wird die für Embedded-Systemen bestehende Forderung erfüllt, jegliche Vergeudung von Zeit und Speicherplatz zu vermeiden.
Als zweites Konzept von AUTOSAR ist der Systemgenerator anzusprechen (Bild 2). Dieser nutzt die in den AUTOSAR-Templates enthaltenen Informationen zur Verbesserung des Systemdesign-Prozesses. Er ist in der Lage, die vorgefundenen Systemdetails zu verarbeiten und kann die Konfiguration sowohl der verschiedenen ECUs als auch der systemweiten Konfiguration übernehmen (z.B. des Bus-Schedulings).
Die Verfügbarkeit all dieser Systeminformationen im Modell kann dazu beitragen, den Systemdesign-Prozess aufzuwerten. In einem ersten Schritt ließe sich beispielsweise verifizieren, ob ein bestimmtes Systemdesign sämtliche Anforderungen in Bezug auf Platzbedarf und Kommunikation erfüllt. Noch visionärer wäre eine Lösung, in der ein Systemgenerator einen Vorschlag für das Design eines Systems vorlegt. Dies kann zunächst in halbautomatischer Form erfolgen, doch wenn im Modell sämtliche Informationen über das jeweilige System enthalten sind, wäre theoretisch auch ein vollautomatischer Ablauf denkbar. Zu den Aspekten, die von einem Systemgenerator vorgeschlagen werden könnten, gehört die Zuordnung der Software-Komponenten zu den ECUs (Deployment), die Definition eines Bus-Schedules, die Zuordnung der Bussignale zu den Busnachrichten oder die Definition eines Task-Schedules in einer ECU.
Erweiterung des AUTOSAR-Metamodells
Wie erwähnt, theoretisch ist ein halbautomatischer Systemdesign-Prozess denkbar. Obwohl AUTOSAR bereits einen großen Teil der hierfür erforderlichen Informationen bereithält, ist es noch lange nicht vollständig. Zu den zentralen Informationen, die gegenwärtig noch außen vor bleiben, gehören die Timing-Anforderungen.
Für die Entscheidung, ob eine bestimmte Software-Komponente auf einer bestimmten ECU untergebracht werden kann, muss nicht nur geprüft werden, ob das betreffende Steuergerät genügend Speicherressourcen hat. Vielmehr ist zu gewährleisten, dass die Software genügend schnell ausgeführt werden kann, um ihre Funktionalität korrekt zu erbringen, und dass die Kommunikation mit den anderen Komponenten im vorgegebenen Zeitrahmen erfolgen kann. In einem Echtzeitsystem nämlich kann eine an sich korrekte Antwort allein dadurch falsch oder zumindest nutzlos sein, dass sie nicht rechtzeitig eintrifft.
Von der Zielvorstellung eines Systemgenerators einmal ganz abgesehen, kann bereits die Bündelung der Timing-Anforderungen in einem formellen Modell eine deutliche Verbesserung gegenüber der heutigen Situation bedeuten. Das Wissen der Entwickler und Systemarchitekten wird erfasst und an einem zentralen Ort niedergeschrieben, um später wiederverwendet werden zu können. Daraus resultiert ein besseres Wissens-Management.
Sobald die Timing-Informationen zum Bestandteil des Metamodells werden, können sie für eine präzisere Beschreibung der Funktionen und ihrer Timing-Anforderungen dienen. Somit können und werden diese Informationen bewirken, dem Ziel des Systemgenerators einen Schritt näher zu kommen.