AUTOSAR-Konfigurationen
Unsauberes Konfigurieren führt zu instabilen Systemen
Fortsetzung des Artikels von Teil 1
Das generierte Code für RTE und die Task
In dem in Bild 2 abgebildeten Beispiel wäre kein konkurrierender Zugriff auf die Daten möglich, weil sowohl das Schreiben in ReZ als auch das Lesen in Re1 in derselben Task stattfinden und dadurch eben nicht gleichzeitig erfolgen können.
Jobangebote+ passend zum Thema
Die generierte RTE wird in diesem Fall also vermutlich keinen Schutzmechanismus, beispielsweise durch Interrupt-Sperren oder OS-Resources, einfügen. Im einfachsten Fall wird der in Listing 2 abgebildete Code für die RTE generiert. Liest nun aber auch das Runnable Re2 die Daten aus dem Port und hat die Task B eine höhere Priorität als Task A, kann ein Schreibvorgang aus ReZ durch Re2 unterbrochen werden und die in Re2 ausgelesenen Daten wären inkonsistent - vorausgesetzt es handelt sich bei DtSpd1 nicht um ein "atomares" Datum.
Listings 1-4
Probleme ergeben sich für ähnliche Szenarien, zum Beispiel für den Fall, dass ReZ in Task C läuft. In diesem Fall müsste der RTE-Generator zwar einen Schutzmechanismus zwischen Re1 aus Task A und ReZ (aus Task C) vorsehen. Auf diesen Schutzmechanismus, wie OS-Resources, hat jedoch Re2 aus Task B keinen Zugriff, was im besten Fall mit einem OS_Error signalisiert wird. Für andere Zugriffsarten, beispielsweise dataReadAccess oder auch Client-Server-Kommunikation, ergeben sich ähnliche Situationen. Die Konfiguration müsste also korrekterweise um einen Zugriff von Re2 auf Port RpRx ergänzt werden, wie in Bild 3 veranschaulicht ist.
Alle drei abgebildeten Runnables könnten damit auf die Ports über die generierten APIs nach Listing 3 zugreifen. Im Vergleich zu vorangegangenem Beispiel wird keine neue API erzeugt. Der generierte Code für die APIs wird damit - je nach RTE-Generator und weiteren Konfigurationsparametern - komplexer, s. Listing 4.
Durch Umgehen der Konfiguration durch das Verwenden generierter APIs für andere Runnables können sporadisch inkonsistente Daten entstehen. Die Fehlersuche zu einem solchen Problem kann sehr viel vermeidbare Zeit kosten. Deshalb ist es wichtig, das System vollständig zu konfigurieren und sich bei der Implementierung strikt an die Konfiguration zu halten. Das bedeutet, nur die APIs zu verwenden, welche auch für das entsprechende Runnable generiert wurden.
- Unsauberes Konfigurieren führt zu instabilen Systemen
- Das generierte Code für RTE und die Task
Das könnte Sie auch interessieren
Automotive Software
Elektrobit baut AUTOSAR-Entwicklung aus
Personalie
AUTOSAR ernennt Stefan Rathgeber zum Sprecher
Entwickler-Konferenz »Build 2016«
Microsoft kündigt »Geburtstags-Update« für Windows 10 an
Fraunhofer ESK demonstriert…
Ausfallsicheres Bordnetz für das Auto der Zukunft
Interview mit Simon Fürst, Sprecher der…
AUTOSAR – Der Weg in die Zukunft
