Fahrzeuge entwickeln sich immer stärker zu Computernetzwerken, um zukünftig Autonomes Fahren zu ermöglichen. Mit Adaptive AUTOSAR kommen jetzt auch moderne Service-orientierte Software-Architekturen ins Fahrzeug.
Grundsätzlich soll mit Service-orientierten Architekturen (SOA) die Strukturierung und Nutzung verteilter Funktionalitäten im Fahrzeug ermöglicht und erleichtert werden. Statt der bisherigen statischen Bindung von Funktionen in einer Applikation (Apps) werden in Zukunft viele Funktionen der Apps erst beim Start miteinander verknüpft. Diese Service-orientierten Architekturen sind in der IT-Welt nichts Neues, aber wie funktionieren sie in Embedded-Systemen im Fahrzeug?
Find Service
Nach dem Einschalten des Fahrzeugs fahren die angeschlossenen Steuergeräte hoch und die dabei startenden Applikationen bieten ihre Services den Clients zur Nutzung an. Diese Services besitzen eine Versionsnummer, um hier die Kompatibilität zwischen verschieden Version sicherzustellen. Mit „Find Service“ können auch die Clients gezielt nach einem Service suchen, wenn der aktuelle Zustand nicht bekannt ist. Dadurch können sich die Kommunikationspartner zur Laufzeit in einem Netzwerk finden, ohne dass hier eine statische Konfiguration vorhanden sein muss. Weitere Applikationen, die neue Services anbieten oder Vorhandene benutzen, können auch nach der Produktion des Fahrzeugs einfach ergänzt werden. Letztlich erreicht man in Fahrzeugen ähnliche Möglichkeiten, wie sie Apps schon heute z. B. bei Smartphones bieten. Die Services selbst können auf drei Arten benutzt werden:
- „Fire und Forget“ – hier sendet der Client Daten an den Server und wartet nicht auf das Ergebnis. Das kann zum Beispiel eine neue Stellgröße für einen Temperaturregler sein.
- „Request und Response“ – hier sendet der Client Daten an den Server und erhält dann das Ergebnis als Antwort zurück. Ein Beispiel wäre das schrittweise Inkrementieren eines Stellwerts und das Zurücksenden des sich dadurch ergebenden
neuen Stellwertes.
- „Event“ – hier sendet der Server selbständig Informationen an einen Client, der sich zuvor registriert hat. Ein Beispiel wäre das zyklische Senden des aktuellen Messwertes der Temperatur an eine Anzeige. Beendet sich ein Server, auch während des laufenden Betriebs, so teilt er dieses den Clients durch das Senden eines Broadcast „Stop Offer Service“ mit. Die Clients können daraufhin ihrerseits entsprechend reagieren.
Fazit
Die Ziele der Service-orientierten Software-Architekturen entsprechen denen in der IT: So soll damit die langfristige Senkung von Kosten in der Entwicklung von Fahrzeugapplikationen erreicht werden. Die höhere Flexibilität dieser Fahrzeugapplikation ermöglicht die Wiederverwendung bestehender Services in verschiedenen Steuergeräten und unterschiedlichen Fahrzeugen. Dies ist notwendig, um die komplexere Software, welche für Autonomes Fahren entwickelt wird, in die Fahrzeuge integrieren und später warten zu können. www.kpit.com
Grundsätzlich soll mit Service-orientierten Architekturen (SOA) die Strukturierung und Nutzung verteilter Funktionalitäten im Fahrzeug ermöglicht und erleichtert werden. Statt der bisherigen statischen Bindung von Funktionen in einer Applikation (Apps) werden in Zukunft viele Funktionen der Apps erst beim Start miteinander verknüpft. Diese Service-orientierten Architekturen sind in der IT-Welt nichts Neues, aber wie funktionieren sie in Embedded-Systemen im Fahrzeug?
Find Service
Nach dem Einschalten des Fahrzeugs fahren die angeschlossenen Steuergeräte hoch und die dabei startenden Applikationen bieten ihre Services den Clients zur Nutzung an. Diese Services besitzen eine Versionsnummer, um hier die Kompatibilität zwischen verschieden Version sicherzustellen. Mit „Find Service“ können auch die Clients gezielt nach einem Service suchen, wenn der aktuelle Zustand nicht bekannt ist. Dadurch können sich die Kommunikationspartner zur Laufzeit in einem Netzwerk finden, ohne dass hier eine statische Konfiguration vorhanden sein muss. Weitere Applikationen, die neue Services anbieten oder Vorhandene benutzen, können auch nach der Produktion des Fahrzeugs einfach ergänzt werden. Letztlich erreicht man in Fahrzeugen ähnliche Möglichkeiten, wie sie Apps schon heute z. B. bei Smartphones bieten. Die Services selbst können auf drei Arten benutzt werden:
- „Fire und Forget“ – hier sendet der Client Daten an den Server und wartet nicht auf das Ergebnis. Das kann zum Beispiel eine neue Stellgröße für einen Temperaturregler sein.
- „Request und Response“ – hier sendet der Client Daten an den Server und erhält dann das Ergebnis als Antwort zurück. Ein Beispiel wäre das schrittweise Inkrementieren eines Stellwerts und das Zurücksenden des sich dadurch ergebenden
neuen Stellwertes.
- „Event“ – hier sendet der Server selbständig Informationen an einen Client, der sich zuvor registriert hat. Ein Beispiel wäre das zyklische Senden des aktuellen Messwertes der Temperatur an eine Anzeige. Beendet sich ein Server, auch während des laufenden Betriebs, so teilt er dieses den Clients durch das Senden eines Broadcast „Stop Offer Service“ mit. Die Clients können daraufhin ihrerseits entsprechend reagieren.
Fazit
Die Ziele der Service-orientierten Software-Architekturen entsprechen denen in der IT: So soll damit die langfristige Senkung von Kosten in der Entwicklung von Fahrzeugapplikationen erreicht werden. Die höhere Flexibilität dieser Fahrzeugapplikation ermöglicht die Wiederverwendung bestehender Services in verschiedenen Steuergeräten und unterschiedlichen Fahrzeugen. Dies ist notwendig, um die komplexere Software, welche für Autonomes Fahren entwickelt wird, in die Fahrzeuge integrieren und später warten zu können. www.kpit.com
