Entwicklung von Kfz-Software
Wechsel von OSEK zu AUTOSAR
Fortsetzung des Artikels von Teil 2
Auf die Autobahn
So wichtig das Protokoll-Gateway auch ist, um eine transparente Interaktion zwischen den diversen Protokollen zu gewährleisten, wird ein zweites Element benötigt. Selbstverständlich braucht jede NM-Instanz ihre eigene spezifische Schnittstelle zur Kommunikationsschicht. Es muss jedoch einen Weg geben, um Informationen zwischen diesen Schnittstellen und der Kommunikationsschicht verständlich auszutauschen. Die Lösung ist ein Übersetzer oder »Wrapper«, der zwischen den beiden vermittelt. Bild 3 zeigt dieses Konzept.
Jobangebote+ passend zum Thema
Der Wrapper betrachtet eingehende Frame-ID-Bits und leitet NM-Frames gemäß ihrem Inhalt an die entsprechende Netzwerk-Manager-Instantiierung. Bild 3 zeigt ein Beispiel, bei dem die Kommunikationsschicht in der Gateway-ECU für den OSEK-NM entwickelt ist. Von einem AUTOSAR-NM stammende API-Aufrufe zur Übertragung von CAN-Frames werden vom Wrapper in Aufrufe übersetzt, welche die Kommunikationsschicht versteht. Der Prozess ermöglicht es den verschiedenen AUTOSAR- und OSEK-Protokollen, so zu agieren und zu reagieren, als ob sie identisch wären. Zu beachten ist, dass Rückrufe für beide NM-Arten – AUTOSAR und OSEK – den Wrapper passieren. Das Routing-Template der Wrapper sieht so aus:
- Jede Frame-ID, die mit 0x5 beginnt, wird zum OSEK-NM geleitet.
- Die Frame-IDs 0x120, 0x121 und 0x122 werden zum AUTOSAR-NM geleitet.
Einrückfahrt
Bild 4 zeigt die Ergebnisse eines Dialogs durch das Protokoll-Gateway und den Wrapper, wenn OSEK- und AUTOSAR-Netzwerk-Manager den Bus gemeinsam nutzen. Das Protokoll-Gateway-Modul startet die Synchronisierungsroutine, nachdem die Anwendung auf dem PGW-Netzwerkknoten angezeigt hat, dass das Netzwerk nicht angefordert wurde und die NM-Protokolle Nachricht geben, dass ihre »Peers« bereit zum Schlafen sind. Eigentlich ist das die erste »Call for Shutdown«-Nachricht in Bild 4. Da die Mitteilung aber kurz nach der Ring-Message 1 eintrifft, kann der OSEK-NM nicht sofort reagieren. Er registriert bis Ring-Message 2 keine Antwort.
Dem »Call for Sleep from Gateway« folgt ein wohlgeordneter Prozess, der einen kontrollierten, synchronisierten Übergang in den Sleep-Modus ermöglicht, das heißt, er gibt den Bus für das nächste Protokoll frei:
- Die Anwendung auf dem PGW gibt das Netzwerk auf dem betroffenen Kanal frei.
- Der PGW-Knoten identifiziert alle NM-Protokolle, die auf diesem Kanal laufen.
- Das PGW überwacht jedes NM-Protokoll-Bit und sendet einen Rückruf, bis alle Module, die dieses NM-Protokoll ablaufen lassen, auf diesem Bus bereit für den Sleep-Modus sind.
Wenn alle NM-Protokolle auf dem Bus bereit für den Sleep-Modus sind, startet das PGW die Synchronisation auf eine von zwei Arten. Wenn die für den Shutdown der Protokolle erforderliche Zeit identisch ist, wird der Bus sofort freigegeben. Wenn jedoch ein Konfigurations-Flag anzeigt, dass ein verzögerter oder »relativer« Shutdown erforderlich ist, wird eine Timer-Funktion verwendet. Diese ist für jeden NM-Opponent in der PGW-Konfiguration definiert und wird in der NM-Protokoll-Bibliothek verwaltet. Sobald der PGW-Knoten eine Freigabeanforderung für den NM-Opponent stellt, kennt er die genaue Zeit, die bleibt, bis alle ECUs, die dieses NM-Protokoll ablaufen lassen, in den Sleep-Modus wechseln. Die Gleichungen für das Shutdown-Timing lauten:
TOSEK-Shutdown = tRemain – ttyp – tMainProcessing
TAUTOSAR-Shutdown = tRemain – tNM_TIMEOUT_TIME
In Bild 4 gleicht ein Timer die Zeitdifferenzen aus.
- Wechsel von OSEK zu AUTOSAR
- Umsteigen bitte!
- Auf die Autobahn
- Netzwerkmanagement unter OSEK und AUTOSAR
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 1)
AUTOSAR
Load Balancing in AUTOSAR-Multicore-Systemen (Teil 2)
AUTOSAR
Dr. Stefan Bunzel neuer AUTOSAR-Sprecher
AUTOSAR-konformes Entwickeln in und für Linux
Aus »MATLAB/Simulink-Modellen« automatisch AUTOSAR-kompatiblen Code generieren
Skalierbare AUTOSAR-3.1-Software für R32C-MCUs
