AUTOSAR Classic Runtime Environment (RTE)

Das Modulcluster Runtime Environment (RTE) realisiert den AUTOSAR Virtual Functional Bus auf dem Steuergerät und stellt standardisierte APIs für die typisierte Sender-Receiver- und Client-Server-Kommunikation von Software-Komponenten bereit [SWS_Rte_01091], [SWS_Rte_01102]. Es integriert den Basic Software Scheduler (SchM) zur zyklischen Einplanung der Basissoftware-Module und koppelt an OS/IOC sowie den Kommunikationsstack (COM, LdCom) an [SWS_Rte_01376], [SWS_Rte_04546]. Dabei garantiert die RTE Datenkonsistenz und deterministische Modusübergänge durch konfigurierbare Schutzbereiche, Pufferung und definierte 10-Stufen-Transitionsabläufe [SWS_Rte_02665], [SWS_Rte_03504].

mehr ›

Das Modulcluster Runtime Environment (RTE) bildet die Realisierung des Virtual Functional Bus (VFB) auf Steuergeräteebene. Es entkoppelt AUTOSAR Software-Komponenten (SWCs) vollständig von der zugrunde liegenden Basissoftware und koordiniert über den Basic Software Scheduler (SchM) die Einplanung von BSW-Modulen [SWS_Rte_04546], [SWS_Rte_05165]. Das Cluster wickelt sowohl partitionsinterne Zugriffe als auch partitionsübergreifende Datenflüsse über das OS-IOC sowie den Steuergerätebus über die Module COM und LdCom ab [SWS_Rte_01376], [SWS_Rte_02736], SWS_RTE S. 106.

Kontextdiagramm: Einbettung des RTE- und SchM-Clusters zwischen Applikationsschicht (SWCs), OS/IOC und Basissoftware-Diensten. Quellen: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE S. 106.

Die Kommunikation stützt sich auf Sender-Receiver- und Client-Server-Muster: S/R-Daten werden implizit konsistent über Pufferkopien (`Rte_IRead`/`Rte_IWrite`) oder explizit direkt und gepuffert (`Rte_Read`/`Rte_Write`/`Rte_Receive`) übertragen [SWS_Rte_01091], [SWS_Rte_02521], [SWS_Rte_06000]. Bei Ausfall oder Vorliegen ungültiger Signale greifen Mechanismen wie `initValue`-Substitution oder `handleInvalid`-Strategien [SWS_Rte_05030], [SWS_Rte_06009]. Client-Server-Aufrufe (`Rte_Call`, `Rte_Result`) werden bei asynchroner Ausführung über FIFO-Warteschlangen auf Server- und Clientseite synchronisiert und mittels Transaktions-Handles eindeutig zugeordnet [SWS_Rte_01102], [SWS_Rte_02527], [SWS_Rte_02649].

Im Task- und Lebenszyklusmanagement stellt die RTE Reentranz durch Code-Sharing sicher und schützt kritische Bereiche über konfigurierbare Sperrmechanismen wie Interrupt-Sperren, OS-Ressourcen oder OS-Spinlocks [SWS_Rte_03015], [SWS_Rte_03504]. Moduswechsel durchlaufen eine strikte 10-stufige Sequenz von OnExit-, OnTransition- bis OnEntry-Aktivierungen und werden geordnet über Bestätigungs-Events abgeschlossen [SWS_Rte_02665], [SWS_Rte_02679].

mehr ›

Systemarchitektur & Rolle des Modulclusters

Das Modulcluster der Runtime Environment (RTE) bildet das funktionale und kommunikative Rückgrat der AUTOSAR Classic Platform. Es stellt die konkrete Realisierung des Virtual Functional Bus (VFB) auf einem Steuergerät dar und entkoppelt Software-Komponenten (SWCs) vollständig von der zugrunde liegenden Basissoftware (BSW) sowie der Mikrocontroller-Hardware SWS_RTE S. 106. Innerhalb des Clusters übernimmt die eigentliche RTE die Vermittlung der anwendungsbezogenen Inter- und Intra-ECU-Kommunikation, während der integrierte Basic Software Scheduler (SchM) die Ablaufsteuerung, Konsistenzsicherung und zyklische Einplanung der BSW-Module steuert [SWS_Rte_04546], [SWS_Rte_05165].

Die Architektur spannt standardisierte Schnittstellen zwischen Anwendungs-SWCs, Sensor-/Aktor-Komponenten und den BSW-Schichten auf. Für die fahrzeugweite Vernetzung stützt sich das RTE-Cluster unmittelbar auf den Kommunikationsstack ab: Signalorientierte Botschaften werden an das Modul COM übergeben, während große Datenmengen über das LdCom-Modul (Large Data COM) abgewickelt werden [SWS_Rte_01376], [SWS_Rte_04527]. Die Prozess- und Speicherisolation über Partitions- und Core-Grenzen hinweg wird durch das AUTOSAR Betriebssystem (OS) und dessen Inter-OS-Application-Communication-Mechanismus (IOC) bereitgestellt [SWS_Rte_02736]. Kalibrierdaten und Speicherblöcke koppeln über standardisierte Deskriptoren an NVRAM Manager (NvM) und Kalibriertools an [SWS_Rte_03961], [SWS_Rte_05118].

Kontextdiagramm: Einbettung des RTE- und SchM-Clusters zwischen Applikationsschicht (SWCs), OS/IOC und Basissoftware-Diensten. Quellen: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE S. 106.

Zusammenspiel & Interaktionspfade zwischen den Modulen

Das Zusammenspiel im RTE-Cluster unterscheidet strikt zwischen Sender-Receiver- (S/R) und Client-Server-Kommunikation (C/S). Bei der S/R-Kommunikation unterstützt die RTE sowohl implizite als auch explizite Lese- und Schreibsemantiken: Bei implizitem Zugriff (`Rte_IRead`, `Rte_IWrite`) erstellt die RTE zu Beginn der Runnable-Ausführung eine lokale Kopie, die über die gesamte Laufzeit konsistent gehalten wird [SWS_Rte_06000], [SWS_Rte_03744]. Bei explizitem Zugriff (`Rte_Read`, `Rte_Write`, `Rte_Send`, `Rte_Receive`) erfolgt der Datenaustausch direkt synchron oder über Warteschlangen [SWS_Rte_01091], [SWS_Rte_01092]. Für Ereignisse mit Warteschlangen (`swImplPolicy = queued`) richtet die RTE empfängerseitig FIFO-Warteschlangen ein; läuft ein solcher Puffer über, wird das Element verworfen und ein Fehlerzustand gesetzt [SWS_Rte_02521], [SWS_Rte_02523].

Führt der Datenpfad über Steuergerätegrenzen (Inter-ECU), transformiert und serialisiert die RTE zusammengesetzte Datenstrukturen und ruft `Com_SendSignal` beziehungsweise `Com_SendSignalGroup` auf, um die atomare PDU-Übertragung im COM-Modul sicherzustellen [SWS_Rte_04527]. Bei großen Datenarrays greift die RTE alternativ auf `LdCom_Transmit` zurück und sperrt bei Transportprotokollen (TP) den zugehörigen Puffer bis zur Bestätigung über Callbacks [SWS_Rte_01377], [SWS_Rte_01379]. Auf Empfängerseite empfängt die RTE Daten asynchron über COM-Callbacks und leitet daraus Aktivierungsereignisse für Applikations-Runnables ab [SWS_Rte_03530], [SWS_Rte_03531]. Sind noch keine Busdaten eingetroffen, liefert die RTE konfigurierte Initialwerte aus [SWS_Rte_06009], [SWS_Rte_06010].

Sequenzdiagramm: Expliziter Sender-Receiver-Datenfluss über Steuergerätegrenzen mit Pufferung und Initialwertausgabe. Quellen: [SWS_Rte_06010], [SWS_Rte_04527], [SWS_Rte_03530], AUTOSAR_SWS_RTE S. 148.

Bei der Client-Server-Kommunikation generiert die RTE für synchrone Aufrufe `Rte_Call` und für asynchrone Aufrufe getrennte Aufruf- und Abfrage-APIs (`Rte_Call`, `Rte_Result`) [SWS_Rte_01102], [SWS_Rte_01111]. Sofern Aufrufe nicht direkt als C-Funktion im selben Kontext auflösbar sind, puffert die RTE Anforderungen auf Serverebene in FIFO-Schlangen und Antworten auf Clientebene in einer Warteschlange der Tiefe 1 [SWS_Rte_02527], [SWS_Rte_02528]. Für partitions- oder steuergeräteübergreifende C/S-Aufrufe nutzt die RTE Transaktions-Handles aus Client-ID und Sequenzzähler, um Antworten präzise dem ursprünglichen Aufrufer zuzuordnen [SWS_Rte_02649], [SWS_Rte_03885].

Synchronisation, Reentranz und Task-Kontexte

Die Ausführung von Programmcode im RTE-Cluster erfolgt innerhalb von OS-Tasks oder ISR-Kontexten. Die RTE unterscheidet zwischen einfachen Runnables (Kategorie 1 ohne blockierende OS-Aufrufe) und erweiterten Runnables (Kategorie 2 mit Wartepunkten), die durch Events wie `DataReceivedEvent` oder COM-Callbacks aus dem Zustand `WaitPoint` geweckt werden [SWS_Rte_03532], SWS_RTE S. 304. Die nebenläufige Aktivierung derselben Instanz einer Runnable Entity ist strikt verboten, es sei denn, das Attribut `canBeInvokedConcurrently` ist explizit auf `TRUE` gesetzt [SWS_Rte_03523]. Bei multi-instanziierten SWCs setzt AUTOSAR konsequent auf Code-Sharing: Mehrere Instanzen teilen sich denselben ausführbaren Code, greifen jedoch über instanzspezifische Deskriptoren auf getrennte Daten und Per-Instance-Memory (PIM) zu [SWS_Rte_02002], [SWS_Rte_03015], [SWS_Rte_02301].

Zur Absicherung kritischer Abschnitte generiert die RTE sogenannte Exclusive Areas (`Rte_Enter`, `Rte_Exit`). Der zugrunde liegende Synchronisationsmechanismus wird über den Parameter `RteExclusiveAreaImplMechanism` konfiguriert [SWS_Rte_03504]. Hierbei stehen fünf definierte Strategien zur Verfügung:

• ALL_INTERRUPT_BLOCKING: Globales Sperren aller Hardware-Interrupts [SWS_Rte_03504].
• OS_INTERRUPT_BLOCKING: Selektives Sperren von OS-spezifischen Interrupts (Kategorie 2) [SWS_Rte_03504].
• OS_RESOURCE: Nutzung von OSEK-/AUTOSAR-Betriebssystem-Ressourcen mit Prioritäts-Decken-Protokoll [SWS_Rte_03504].
• OS_SPINLOCK: Mehrkernfähige Synchronisation über OS-Spinlocks zur Koordination zwischen Tasks und ISRs unterschiedlicher Kerne [SWS_Rte_03504].
• NONE: Verzicht auf interne Sperren, sofern die Datenkonsistenz bereits durch strikte Task-Priorisierung oder Einplanung sichergestellt ist [SWS_Rte_03504].

Werden Daten zwischen verschiedenen Speicherschutz-Partitionen übergeben, prüft die RTE Pointer-Parameter, um unberechtigte Speicherzugriffe aus nicht vertrauenswürdigen Partitionen zu unterbinden [SWS_Rte_02752], [SWS_Rte_02753].

Typische Lebenszyklen und Betriebsmodi

Der Lebenszyklus des Systems unterliegt einer strikten Phaseneinteilung zwischen Initialisierung, regulärem Betrieb und kontrolliertem Herunterfahren. Beim Systemstart wird zunächst der SchM-Teil initialisiert: Das EcuM ruft auf jedem Prozessorkern `SchM_Start` auf, bevor BSW-Module wie das BswM gestartet werden [SWS_Rte_04546], [SWS_Rte_04548]. Anschließend aktiviert `SchM_StartTiming` die periodischen BSW-Events und MainFunctions [SWS_Rte_04549], [SWS_Rte_04551]. Gemäß Design-Constraint dürfen `SchM_Start` und `SchM_StartTiming` pro Kern genau einmal aufgerufen werden SWS_RTE S. 928. Danach schaltet `Rte_Start` die Anwendungs-RTE frei; scheitert die interne Ressourcenallokation, bricht die Initialisierung mit `RTE_E_LIMIT` ab [SWS_Rte_01261], [SWS_Rte_01262].

Betriebsmodi werden über Mode-Declaration-Groups abgebildet. Löst ein Mode Manager über `Rte_Switch` einen Moduswechsel aus, wird dieser in einer FIFO-Warteschlange abgelegt [SWS_Rte_02631], [SWS_Rte_02718], [SWS_Rte_02719]. Jede Modusmaschine durchläuft während der Umschaltung eine verbindliche 10-stufige Sequenz [SWS_Rte_02665]: Zuerst werden Modus-Deaktivierungen für den Zielmodus wirksam geschaltet und laufende Entitäten abgewartet (Schritte 1–2). Es folgt die sequenzielle Ausführung und Terminierung von OnExit- (Schritte 3–4), OnTransition- (Schritte 5–6) und OnEntry-Executable-Entities (Schritte 7–8). Abschließend wird die Deaktivierung des vorherigen Modus aufgehoben und der neue Modus aktiviert (Schritt 9), bevor der Moduswechsel über `ModeSwitchedAckEvent` bzw. `Rte_SwitchAck` quittiert wird (Schritt 10) [SWS_Rte_02665], [SWS_Rte_02679], [SWS_Rte_02725]. Über `RteModeToScheduleTableMapping` können Betriebsmodi zudem direkt an OS-Schedule-Tables gekoppelt werden [SWS_Rte_05146].

Sequenzdiagramm: Standardisierter 10-Stufen-Ablauf eines AUTOSAR-Moduswechsels mit Quittierung. Quellen: [SWS_Rte_02665], [SWS_Rte_02679], EXP_ModeManagementGuide S. 16.

Die Deinitialisierung erfolgt zu Beginn der Shutdown-Phase über `Rte_Stop`. Nach diesem Aufruf blockiert die RTE das Aktivieren, Starten oder Freigeben weiterer Runnables auf dem jeweiligen Kern [SWS_Rte_02538]. Eintreffende S/R-Daten sowie C/S-Anfragen werden im gestoppten Zustand der RTE verworfen und ignoriert [SWS_Rte_02535], [SWS_Rte_02536].

Fehlerbehandlung, Statusüberwachung und Datenvalidierung

Fehlerzustände und Schnittstellenstatus werden in der RTE einheitlich über den skalaren Typ `Std_ReturnType` an den Aufrufer übermittelt [SWS_Rte_01034], SWS_RTE S. 586. Die RTE differenziert zwischen Applikationsfehlern (Fehlerwerte 1–63), unmittelbaren Infrastrukturfehlern (Werte 128–255) sowie überlagerten Statusbits wie Datenverlust (`RTE_E_LOST_DATA = 64`) oder Veralterung (`RTE_E_MAX_AGE_EXCEEDED = 64`) SWS_RTE S. 586. Typische Infrastruktur-Rückgabewerte umfassen gestoppte Kommunikation (`RTE_E_COM_STOPPED = 128`), Kommunikations- und Antwort-Timeouts (`RTE_E_TIMEOUT = 129`), fehlende Daten (`RTE_E_NO_DATA = 131`) und Ressourcenüberläufe (`RTE_E_LIMIT = 130`) [SWS_Rte_01060], [SWS_Rte_01061], [SWS_Rte_01064]. Bei aktiver Wertebereichsprüfung quittiert die RTE Bereichsüberschreitungen mit `RTE_E_OUT_OF_RANGE` [SWS_Rte_03845], [SWS_Rte_03846].

Zur Behandlung unplausibler oder fehlerhafter Signale stellt die RTE Mechanismen zur Dateninvalidation bereit. Sendeseitig markiert `Rte_Invalidate` das Signal mit einem definierten Ersatzwert [SWS_Rte_01206], [SWS_Rte_05024]. Empfängerseitig steuert das Attribut `handleInvalid` die Ersatzstrategie: Bei `keep` wird der bisherige Wert beibehalten und ein `DataReceiveErrorEvent` ausgelöst, während bei `replace` eine automatische Substitution durch den `initValue` erfolgt [SWS_Rte_05030], [SWS_Rte_05049]. Kommunikationsausfälle auf Netzwerkebene werden über `aliveTimeout` überwacht; läuft die Überwachungszeit ab, meldet das COM-Modul via `Rte_COMCbkRxTOut` einen Empfangstimeout an die RTE, woraufhin abhängige Komponenten informiert oder Fallback-Werte aktiviert werden [SWS_Rte_08061].