AUTOSAR-Konfigurationen

Unsauberes Konfigurieren führt zu instabilen Systemen

13. April 2016, 9:59 Uhr | Stefanie Eckardt

Durch unvollständige AUTOSAR-Konfigurationen oder Umgehung der Konfiguration durch die Software-Entwickler können instabile Systeme oder sporadisch inkonsistente Daten entstehen. Wie sich das vermeiden lässt, erklärt der nachfolgende Beitrag.

Diesen Artikel anhören
Software-Komponenten bestehen aus Runnables, die während der Integration den Tasks zugewiesen werden
Bild 1. Software-Kompo- nenten bestehen aus Runnables, die während der Integration den Tasks zugewiesen werden. Dabei können auch Runnables derselben Software-Komponente in verschiedenen Tasks ausgeführt werden.
© Scheid Automotive

Software für Steuergeräte (ECUs) wird zunehmend komplexer. Um diese Komplexität im Griff zu behalten, kommt in praktisch allen umfangreicheren ECUs AUTOSAR zum Einsatz. Ein solches System bietet eine Vielzahl an Konfigurationsmöglichkeiten und Optionen, die von den Software-Architekten richtig und vollständig konfiguriert werden müssen. Wesentliche Bestandteile von AUTOSAR-Systemen sind dabei Software-Komponenten (SWC) und deren Ports. SWCs wiederum können aus mehreren ausführbaren Teilen bestehen, den sogenannten Runnable Entities, kurz Runnables, welche schließlich während der Integration den Tasks zugewiesen werden. Dabei können auch Runnables derselben Software-Komponente in verschiedenen Tasks ausgeführt werden. Diese Zusammenhänge veranschaulicht Bild 1.

Damit Runnables auch Daten aus Ports auslesen oder in Ports schreiben können, müssen Access Points definiert werden. Aus diesen Zugriffspunkten generiert der RTE-Generator die APIs, die im eigentlichen Code schließlich verwendet werden. Aus dem obigen Beispiel mit den Access Points dataReceivePointByArgument (für Re1) und dataSendPoint (für ReZ) entstehen so für die Runnables die APIs im Listing 1.

Listings 1-4

Listing 1
© Scheid Automotive
Listing 2
© Scheid Automotive
Listing 3
© Scheid Automotive

Alle Bilder anzeigen (4)

Stellt der Entwickler nun fest, dass er in Re2 ebenfalls die Daten aus Port RpRx auslesen muss, so könnte er die für Re1 generierte API Rte_Read_RpRx_speed dafür benutzen, ohne dass eine Fehlermeldung oder eine Warnung ausgegeben würde. Tatsächlich ist das jedoch keine gute Idee, denn die konfigurierten Access Points dienen dem RTE-Generator beispielsweise dazu, festzulegen, ob und wie die Zugriffe auf die RTE geschützt werden müssen.


  1. Unsauberes Konfigurieren führt zu instabilen Systemen
  2. Das generierte Code für RTE und die Task

Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!