AUTOSAR RTE

Die Funktion Rte_Start allokiert und initialisiert die von der RTE genutzten System- und Kommunikationsressourcen [SWS_Rte_03015]. Die API wird stets generiert [SWS_Rte_01309], besitzt die Signatur Std_ReturnType Rte_Start (void) [SWS_Rte_02569] und muss zwingend innerhalb endlicher Ausführungszeit ohne Endlosschleife zurückkehren [SWS_Rte_02585].

Die Funktion darf auf jedem Core nur genau einmal durch den EcuStateManager aus einem vertrauenswürdigen OS-Kontext aufgerufen werden, nachdem alle von der RTE benötigten Basissoftware-Module initialisiert wurden [SWS_Rte_CONSTR_09035]. Der Aufruf wird auf jedem Core unabhängig ausgeführt [SWS_Rte_07615] und führt die partitionsspezifischen Startaktivitäten für alle diesem Core zugeordneten Partitionen aus [SWS_Rte_07616].

Während des Ablaufs initialisiert die RTE die für RAM-Blöcke allokierten Variablen abhängig von der konfigurierten Strategie [SWS_Rte_07632]. Nach den Variableninitialisierungen, jedoch noch vor der Ausführung von Runnables, ruft die RTE die Initialisierungsfunktionen Rte_Rips_Rte_Start aller beteiligten RTE Implementation Plug-Ins auf [SWS_Rte_80052]. Anschließend aktiviert die RTE einmalig alle durch InitEvent ausgelösten Runnables [SWS_Rte_06761] und leitet den Wechsel in die initialen Modi ein [SWS_Rte_06766]. Falls die API Rte_StartTiming nicht existiert, startet Rte_Start zudem die Aktivierung von Runnables, die durch TimingEvent [SWS_Rte_07575] oder BackgroundEvent [SWS_Rte_07178] ausgelöst werden.

Zur Fehlerbehandlung meldet die RTE bzw. der SchM bei aktiviertem RteDevErrorDetectUninit den Fehler RTE_E_UNINIT (0x07), wenn Rte_Start vor SchM_Init aufgerufen wird [SWS_Rte_07683]. Vor der Ausführung von Rte_Start dürfen Laufzeit-APIs der RTE nicht aufgerufen werden, da dies andernfalls ebenfalls zu RTE_E_UNINIT führt [SWS_Rte_07682]; Rte_SetMirror darf hingegen bereits vor Rte_Start aufgerufen werden [SWS_Rte_07319].

Die Funktion Rte_Stop ([SWS_Rte_02570]) wird in jeder Konfiguration generiert ([SWS_Rte_01310]) und dient dazu, die RTE auf dem ausführenden Core zu finalisieren ([SWS_Rte_01262]). Dabei werden sämtliche von der RTE auf diesem Core allokierten System- und Kommunikationsressourcen freigegeben ([SWS_Rte_01262]). Der synchrone Aufruf kehrt garantiert innerhalb einer endlichen Laufzeit zurück ([SWS_Rte_02584]).

Im Gesamtsystem muss Rte_Stop durch den EcuStateManager aufgerufen werden, bevor die von der RTE benötigten Basissoftware-Module heruntergefahren werden ([SWS_Rte_CONSTR_09038]). Während des Ablaufs ruft die RTE die Stopp-Funktionen Rte_Rips_Rte_Stop aller beteiligten RTE-Implementation-Plug-Ins auf ([SWS_Rte_80053]), welche diese Lifecycle-Schnittstellen bereitstellen müssen ([SWS_Rte_70047]). Erst nach vollständiger Beendigung von Rte_Stop darf SchM_Deinit ausgeführt werden ([SWS_Rte_CONSTR_09056]).

Nach dem Aufruf von Rte_Stop auf einem Core werden dort durch die RTE keine RunnableEntity-Instanzen mehr aktiviert, gestartet oder freigegeben ([SWS_Rte_02538]). Davon unberührt bleibt Rte_GetMirror weiterhin aufrufbar, sofern das zugrundeliegende Betriebssystem aktiv ist ([SWS_Rte_07350]).

Im Fehlerfall liefert die Funktion RTE_E_LIMIT zurück, sofern ein internes Limit überschritten wurde oder die Allokation einer benötigten Ressource fehlschlägt ([SWS_Rte_01262]). Ist RteDevErrorDetectUninit aktiviert, meldet die RTE den Fehler RTE_E_UNINIT (0x07), wenn unzulässige APIs nach Rte_Stop aufgerufen werden ([SWS_Rte_07682]).

Die Funktion Rte_StartTiming dient dazu, nach dem Abschluss der RTE-Initialisierung die Aktivierung von RunnableEntitys freizugeben, die durch TimingEvents oder BackgroundEvents ausgelöst werden ([SWS_Rte_06753], [SWS_Rte_06756]). Sie wird als Funktion ohne Parameter und ohne Rückgabewert implementiert ([SWS_Rte_06754], [SWS_Rte_06758]) und muss innerhalb einer endlichen Ausführungszeit zurückkehren ([SWS_Rte_06757]).

Hinsichtlich des Aufrufkontexts und der Reihenfolge unterliegt die API strengen Randbedingungen:

• Die Funktion darf erst aufgerufen werden, nachdem die RTE vollständig initialisiert wurde, konkret nach Beendigung des Aufrufs von Rte_Start ([SWS_Rte_CONSTR_09061]).
• Sie ist dafür vorgesehen, nach dem letzten Aufruf einer Rte_Init-Funktion ausgeführt zu werden ([SWS_Rte_06753]).
• Die API wird generiert bzw. bereitgestellt, sobald mindestens eine Rte_Init-API erzeugt wird ([SWS_Rte_06755]).

Wird Rte_StartTiming aufgerufen, startet sie unmittelbar die periodischen und hintergrundbasierten Aktivierungen ([SWS_Rte_06759], [SWS_Rte_06760]). Existiert die API in der Konfiguration hingegen nicht, übernimmt stattdessen bereits der Aufruf von Rte_Start die Freigabe der durch TimingEvents und BackgroundEvents getriggerten Runnables ([SWS_Rte_07178], [SWS_Rte_07575]). Spezifische Fehlercodes oder Rückgabewerte sind für diesen Aufruf nicht definiert ([SWS_Rte_06754]).

Verwendung und Semantik

Die Funktion SchM_Init allokiert und initialisiert die Systemressourcen, die vom Basic Software Scheduler (SchM) der RTE auf dem aufrufenden Core genutzt werden ([SWS_Rte_08060]). Die Schnittstelle wird stets generiert ([SWS_Rte_07271]) und besitzt die Signatur void SchM_Init(const SchM_ConfigType* ConfigPtr) ([SWS_Rte_07270]). Sie wird synchron ausgeführt und muss zwingend innerhalb einer endlichen Ausführungszeit zurückkehren, ohne in eine Endlosschleife einzutreten ([SWS_Rte_07273]).

Während des Initialisierungsablaufs führt SchM_Init folgende Schritte aus:

• Sie initiiert für jede zum Basic Software Scheduler gehörende Modus-Maschinen-Instanz den Übergang in den Initialmodus ([SWS_Rte_07532]).
• Sie startet die Aktivierung von BswSchedulableEntity-Instanzen, die durch BswBackgroundEvent-Ereignisse ausgelöst werden ([SWS_Rte_07584]).
• Sie ruft die Initialisierungsfunktionen Rte_Rips_SchM_Init aller beteiligten RTE Implementation Plug-Ins auf ([SWS_Rte_80051]).

Aufrufkontext und Reihenfolgebedingungen

SchM_Init darf auf jedem Core nur genau einmal durch den EcuStateManager aufgerufen werden, sobald die vom Basic Software Scheduler benötigten BSW-Module initialisiert wurden ([SWS_Rte_CONSTR_09055]). Nachfolgende APIs wie Rte_Start dürfen erst nach vollständiger Beendigung von SchM_Init aufgerufen werden ([SWS_Rte_CONSTR_09036]).

Fehlerbehandlung

Wird SchM_Init mit einem NULL-Zeiger als Parameter aufgerufen, meldet der Basic Software Scheduler den Fehler RTE_E_DET_ILLEGAL_VARIANT_CRITERION_VALUE (0x02) ([SWS_Rte_07684]). Werden Scheduler-APIs (wie SchM_Switch, SchM_Mode oder SchM_Start) oder Rte_Start vor SchM_Init aufgerufen, wird bei aktiviertem RteDevErrorDetectUninit der Fehler RTE_E_UNINIT (0x07) gemeldet ([SWS_Rte_07683]).

Verwendung

Die Funktion SchM_Start dient der Inbetriebnahme des Basic Software Schedulers im RTE-Modul und wird im Rahmen der Schnittstellengenerierung grundsätzlich immer bereitgestellt [SWS_Rte_04547]. Sie weist die parameterlose C-Signatur void SchM_Start(void) auf [SWS_Rte_04546] und liefert keinen Rückgabewert. Für die Ausführung gilt die verbindliche Vorgabe, dass der Aufruf innerhalb einer endlichen Laufzeit zurückkehren muss und keinesfalls in eine Endlosschleife geraten darf [SWS_Rte_04548]. Mangels asynchroner Callback-Mechanismen dürfte es sich um einen synchron blockierenden Initialisierungsaufruf handeln. Frage Q-b6ad9ed696841d7a (offen)

Aufrufkontext und Nebenläufigkeit

Für den Aufrufkontext und das Zusammenspiel mit anderen Systemkomponenten gelten strikte Einschränkungen:

• Aufrufer und Häufigkeit: Die Funktion darf auf jedem Prozessorkern exklusiv durch den EcuStateManager und dort jeweils nur genau einmal aufgerufen werden [SWS_Rte_CONSTR_09055].
• Reihenfolgebedingungen: Der Aufruf darf erst stattfinden, nachdem alle Basissoftwaremodule vollständig initialisiert wurden, die vom Basic-Software-Scheduler-Teil der RTE benötigt werden [SWS_Rte_CONSTR_09055].
• Zusammenspiel beim Systemstart: Nach der Ausführung ist der Basic Software Scheduler betriebsbereit; der Aufruf muss zwingend vor der Initialisierung des BSW-Managers über BswM_Init() erfolgen [SWS_Rte_07273].

Fehlerbehandlung

Spezifische Fehlercodes, Rückgabewerte oder Benachrichtigungen an das DET oder DEM sind für diese Funktion im Payload nicht definiert.

Verwendung

Die Funktion SchM_StartTiming besitzt die parameterlose Signatur void SchM_StartTiming(void) [SWS_Rte_04549] und wird durch den RTE-Generator stets erzeugt [SWS_Rte_04550]. Ihr Aufruf startet periodische Ereignisse für BSW und SWCs [SWS_Rte_04548], indem sie die Aktivierung von BswSchedulableEntity-Instanzen einleitet, die durch BswTimingEvents ausgelöst werden [SWS_Rte_07574]. Die Funktion muss innerhalb einer endlichen Ausführungszeit zurückkehren und darf keine Endlosschleife ausführen [SWS_Rte_04551].

Aufrufkontext und Einschränkungen

Vor dem Aufruf von SchM_StartTiming muss zwingend SchM_Init aufgerufen worden sein [SWS_Rte_04548]. Zudem gilt die verbindliche Einschränkung, dass SchM_StartTiming auf jedem Core nur genau einmal durch den EcuStateManager aufgerufen werden darf, nachdem alle für den Basic Software Scheduler erforderlichen Basissoftwaremodule initialisiert wurden [SWS_Rte_CONSTR_09055].

Fehlerbehandlung

Wird SchM_StartTiming vor SchM_Init aufgerufen, meldet der Basic Software Scheduler bzw. die RTE den Fehler RTE_E_UNINIT (0x07), vorausgesetzt, die Entwicklungsfehlererkennung RteDevErrorDetectUninit ist aktiviert [SWS_Rte_07683].

Verwendung und Funktionsumfang

Die Funktion SchM_Deinit dient dazu, den Basic Software Scheduler-Teil der RTE auf demjenigen Core zu finalisieren, auf dem sie aufgerufen wird [SWS_Rte_04551]. Bei diesem Vorgang gibt der Dienst sämtliche Systemressourcen frei, die durch den BSW-Scheduler auf diesem Core belegt wurden [SWS_Rte_04551]. Die Funktion besitzt weder Parameter noch einen Rückgabewert (void SchM_Deinit(void)) [SWS_Rte_07274] und wird vom RTE-Generator grundsätzlich immer erzeugt [SWS_Rte_07275]. In Bezug auf das Zeitverhalten fordert die Spezifikation, dass SchM_Deinit innerhalb einer finiten Ausführungszeit zurückkehren muss [SWS_Rte_07277].

Aufrufkontext und Reihenfolgebedingungen

Für den Aufruf während der Abschaltphase des Steuergeräts gelten verbindliche Reihenfolgevorgaben:

• Die Funktion SchM_Deinit darf erst verwendet werden, nachdem die RTE vollständig finalisiert wurde, das heißt nach der Beendigung von Rte_Stop [SWS_Rte_CONSTR_09056].
• Der Aufruf muss durch den EcuStateManager erfolgen, bevor die Basisschichten heruntergefahren werden, die für den Betrieb des Basic Software Schedulers erforderlich sind [SWS_Rte_CONSTR_09057].
• Nachdem SchM_Deinit auf einem Core aufgerufen wurde, darf der BSW-Scheduler auf diesem Core keinerlei Instanzen von BswSchedulableEntity mehr aktivieren oder starten [SWS_Rte_07586].

Plug-In-Bereinigung

Im Rahmen der Deinitialisierung ruft die RTE innerhalb von SchM_Deinit verbindlich die Funktionen Rte_Rips_SchM_Deinit aller teilnehmenden RTE Implementation Plug-Ins auf, um deren Bereinigung abzuschließen [SWS_Rte_80054].

Die Handler-Funktion <name of the Invocation Handler> übernimmt im Rte-Modul den synchronen Aufruf verschiedener Runnable-Typen über einen Transformer [SWS_Rte_89015]. Zu den unterstützten Einheiten zählen Server-Runnables, Hard-Error-Runnables, ASCR-Runnables sowie getriggerte Runnables [SWS_Rte_89015].

Die Schnittstelle besitzt weder Eingangs-, Ein-/Ausgangs- noch Ausgangsparameter und gibt keinen Wert zurück (Signatur void (void)) [SWS_Rte_89015]. Der Aufruf wird synchron abgewickelt und ist durch die Service-ID 0xEE gekennzeichnet [SWS_Rte_89015]. Die Deklaration wird über die Header-Datei Rte_Rips_<PlugIn>.h bereitgestellt [SWS_Rte_89015].

Bezüglich der Nebenläufigkeit ist die Funktion als bedingt reentrant (Conditional Reentrant) deklariert [SWS_Rte_89015]. Dies dürfte bedeuten, dass ein nebenläufiger Aufruf nur dann zulässig ist, wenn unterschiedliche Ausführungskontexte oder getrennte Plug-in-Instanzen vorliegen. Frage Q-24aabb36a2be58f4 (offen) Der Bezeichner <name of the Invocation Handler> sowie die Header-Bezeichnung <PlugIn> stellen Platzhalter dar; der tatsächliche Name wird vermutlich bei der Plug-in-Konfiguration festgelegt.

Die Funktion Rte_Rips_SchM_Deinit dient der Deinitialisierung derjenigen Bestandteile eines RTE Implementation Plug-Ins, die für die Operationen des Basic Software Schedulers (SchM) relevant sind [SWS_Rte_89019]. Sie gehört zu den verpflichtenden Lebenszyklus-Schnittstellen, die von jedem RTE Implementation Plug-In neben Rte_Rips_SchM_Init, Rte_Rips_Rte_Start und Rte_Rips_Rte_Stop bereitgestellt werden müssen [SWS_Rte_70047].

Für die Integration und Verwendung gelten die folgenden Festlegungen:

• Aufrufkontext und Ablauf: Die Schnittstelle besitzt die Signatur void Rte_Rips_SchM_Deinit (void), nimmt keine Parameter entgegen und liefert keinen Rückgabewert [SWS_Rte_89019]. Sie wird synchron ausgeführt [SWS_Rte_89019]. Der Aufruf erfolgt nicht durch Software-Komponenten, sondern wird durch die RTE innerhalb von SchM_Deinit für alle beteiligten Plug-Ins koordiniert [SWS_Rte_80054].
• Dateieinbindung und Kennung: Die Deklaration ist über den Header Rte_Rips_<PlugIn>.h verfügbar; die Funktion besitzt die Service-ID 0xF3 [SWS_Rte_89019].
• Nebenläufigkeit und Einschränkungen: Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Rte_89019]. Daraus dürfte folgen, dass während des Aufrufs in SchM_Deinit keine konkurrierenden SchM-Aktivitäten mehr auf das Plug-In zugreifen dürfen. Frage Q-60aec1abc9e891b2 (offen)
• Fehlerbehandlung: Die Spezifikation sieht für Rte_Rips_SchM_Deinit weder Fehlercodes noch Rückgabewerte vor und definiert keine Fehlermeldungen an DET oder DEM [SWS_Rte_89019].

Der Datentyp Rte_Rips_SwitchNotificationStatusType ([SWS_Rte_91113]) basiert auf uint8 und wird über Rte_Type.h bereitgestellt. Er dient der Signalisierung des Status von Enqueue- und Dequeue-Operationen an einer Modus-Warteschlange (Mode Queue) im Kontext von RTE Implementation Plug-Ins.

Der Wertebereich umfasst Statuscodes für beide Operationsrichtungen ([SWS_Rte_91113]):

• RTE_SWITCH_NOTIFICATION_SKIP (0x00): Die Moduswechsel-Benachrichtigung kann nicht entnommen werden.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_FIRST (0x01): Die Benachrichtigung wurde in eine leere Warteschlange eingereiht.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_NOT_FIRST (0x02): Die Benachrichtigung wurde in eine bereits belegte Warteschlange eingereiht.
• RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED (0x03): Das Einreihen in eine nicht-leere Warteschlange ist fehlgeschlagen.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_LAST (0x04): Die letzte Moduswechsel-Benachrichtigung wurde aus der Warteschlange entnommen.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_NOT_LAST (0x05): Eine Benachrichtigung wurde entnommen; weitere Benachrichtigungen verbleiben in der Warteschlange.

In der Verwendung tritt der Typ in zwei synchronen, reentranten Schnittstellen auf: Die Funktion Rte_Rips_<PlugIn>_Switch_<BswSwcI>_<MMI> ([SWS_Rte_91114]) erhält den Status als Eingabeparameter switchNotificationStatus, um das Plug-In über Enqueue-Vorgänge zu benachrichtigen. Demgegenüber liefert die Funktion Rte_Rips_<PlugIn>_DequeueModeSwitch_<MMI>_<OsTask> ([SWS_Rte_91115]) den Typ als Rückgabewert, wenn nach Beendigung der letzten On-Entry ExecutableEntity eine Benachrichtigung aus der Warteschlange entnommen wird.

Fehler beim Einreihen werden funktional über den Zustandswert RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED gemeldet ([SWS_Rte_91113]); gesonderte DET- oder DEM-Einträge sind im Payload nicht ausgewiesen. Interpretation: Der Spezifikationstext „was enqueued from mode queue“ bei den Dequeue-Konstanten dürfte redaktionell bedingt sein und meint die Entnahmeoperation. Frage Q-6e9e040dcd341f66 (offen) Das Element sowie die zugehörigen Schnittstellen sind als Entwurf (Draft) markiert ([SWS_Rte_91113]).

Der Datentyp Rte_DsmqStatusType basiert auf uint8 und wird gemäß [SWS_Rte_80085] sowie [SWS_Rte_91102] zusammen mit seinen Literalen in der Header-Datei Rte_Type.h definiert. Er dient der Signalisierung des Status von Enqueue- und Dequeue-Operationen für Moduswechsel-Benachrichtigungen in einer Distributed Shared Mode Queue (DSMQ) [SWS_Rte_91102].

Der Wertebereich umfasst folgende Literale [SWS_Rte_91102]:

• RTE_DSMQ_ENQUEUED_FIRST (0x01): Die Benachrichtigung wurde in eine zuvor leere DSMQ eingereiht.
• RTE_DSMQ_ENQUEUED_NOT_FIRST (0x02): Das Einreihen erfolgte in eine bereits befüllte (nicht leere) DSMQ.
• RTE_DSMQ_ENQUEUE_FAILED (0x03): Das Einreihen in eine nicht leere DSMQ ist fehlgeschlagen.
• RTE_DSMQ_DEQUEUED_LAST (0x04): Die letzte Moduswechsel-Benachrichtigung wurde aus der DSMQ entnommen.
• RTE_DSMQ_DEQUEUED_NOT_LAST (0x05): Eine Benachrichtigung wurde entnommen, während weitere Benachrichtigungen in der Queue verbleiben.

Zur Fehlerbehandlung signalisiert das Literal RTE_DSMQ_ENQUEUE_FAILED ein Scheitern des Einreihvorgangs bei nicht leerer Warteschlange [SWS_Rte_91102].

Verwendet wird der Typ als Übergabeparameter dsmqstatus an Schnittstellen des RTE Implementation Plug-Ins (RIPS). Die Funktion Rte_Rips_<PlugIn>_DsmqSwitch_<BswSwcI>_<MMI> informiert das Plug-In synchron über das Einreihen in eine DSMQ [SWS_Rte_91103]. Zudem meldet Rte_Rips_<PlugIn>_DsmqTransitionEnd_<BswSwcI>_<MMI> synchron den Abschluss eines Modusübergangs in einem DSMQ-Transition-OsTask an das RIPS [SWS_Rte_91106]. Beide Callback-Dienste sind als synchron und reentrant deklariert [SWS_Rte_91103], [SWS_Rte_91106].