AUTOSAR RTE

The function Rte_Start allocates and initializes the system and communication resources used by the RTE [SWS_Rte_03015]. The API is always generated [SWS_Rte_01309], has the signature Std_ReturnType Rte_Start (void) [SWS_Rte_02569], and must unconditionally return within finite execution time without an infinite loop [SWS_Rte_02585].

The function may be called on each Core only exactly once by the EcuStateManager from a trusted OS context after all Basic Software modules required by the RTE have been initialized [SWS_Rte_CONSTR_09035]. The call is executed independently on each Core [SWS_Rte_07615] and executes the partition-specific startup activities for all partitions assigned to this Core [SWS_Rte_07616].

During the sequence, the RTE initializes the variables allocated for RAM blocks depending on the configured strategy [SWS_Rte_07632]. After variable initialization, but prior to the execution of runnables, the RTE calls the initialization functions Rte_Rips_Rte_Start of all participating RTE implementation plug-ins [SWS_Rte_80052]. Subsequently, the RTE activates all runnables triggered by InitEvent once [SWS_Rte_06761] and initiates the transition into the initial modes [SWS_Rte_06766]. If the API Rte_StartTiming does not exist, Rte_Start also starts the activation of runnables triggered by TimingEvent [SWS_Rte_07575] or BackgroundEvent [SWS_Rte_07178].

For error handling, if RteDevErrorDetectUninit is enabled, the RTE or SchM reports the error RTE_E_UNINIT (0x07) if Rte_Start is called before SchM_Init [SWS_Rte_07683]. Prior to the execution of Rte_Start, runtime APIs of the RTE must not be called, as this otherwise likewise leads to RTE_E_UNINIT [SWS_Rte_07682]; Rte_SetMirror, however, may already be called before Rte_Start [SWS_Rte_07319].

The function Rte_Stop ([SWS_Rte_02570]) is generated in every configuration ([SWS_Rte_01310]) and serves to finalize the RTE on the executing Core ([SWS_Rte_01262]). In doing so, all system and communication resources allocated by the RTE on this Core are released ([SWS_Rte_01262]). The synchronous call is guaranteed to return within a finite runtime ([SWS_Rte_02584]).

In the overall system, Rte_Stop must be called by the EcuStateManager before the Basic Software modules required by the RTE are shut down ([SWS_Rte_CONSTR_09038]). During the process, the RTE calls the stop functions Rte_Rips_Rte_Stop of all participating RTE implementation plug-ins ([SWS_Rte_80053]), which must provide these lifecycle interfaces ([SWS_Rte_70047]). Only after complete termination of Rte_Stop may SchM_Deinit be executed ([SWS_Rte_CONSTR_09056]).

After calling Rte_Stop on a Core, no further RunnableEntity instances are activated, started, or released there by the RTE ([SWS_Rte_02538]). Unaffected by this, Rte_GetMirror remains callable as long as the underlying operating system is active ([SWS_Rte_07350]).

In case of an error, the function returns RTE_E_LIMIT if an internal limit was exceeded or the allocation of a required resource fails ([SWS_Rte_01262]). If RteDevErrorDetectUninit is enabled, the RTE reports the error RTE_E_UNINIT (0x07) when illegal APIs are called after Rte_Stop ([SWS_Rte_07682]).

The function Rte_StartTiming serves to enable the activation of RunnableEntitys triggered by TimingEvents or BackgroundEvents after completion of the RTE initialization ([SWS_Rte_06753], [SWS_Rte_06756]). It is implemented as a function without parameters and without a return value ([SWS_Rte_06754], [SWS_Rte_06758]) and must return within a finite execution time ([SWS_Rte_06757]).

Regarding the call context and the sequence, the API is subject to strict constraints:

• The function may only be called after the RTE has been completely initialized, specifically after the call to Rte_Start has finished ([SWS_Rte_CONSTR_09061]).
• It is intended to be executed after the last call of an Rte_Init function ([SWS_Rte_06753]).
• The API is generated or provided as soon as at least one Rte_Init API is generated ([SWS_Rte_06755]).

When Rte_StartTiming is called, it immediately starts the periodic and background-based activations ([SWS_Rte_06759], [SWS_Rte_06760]). If, on the other hand, the API does not exist in the configuration, the call to Rte_Start instead already assumes the enablement of runnables triggered by TimingEvents and BackgroundEvents ([SWS_Rte_07178], [SWS_Rte_07575]). Specific error codes or return values are not defined for this call ([SWS_Rte_06754]).

Usage and Semantics

The function SchM_Init allocates and initializes the system resources used by the Basic Software Scheduler (SchM) of the RTE on the calling Core ([SWS_Rte_08060]). The interface is always generated ([SWS_Rte_07271]) and has the signature void SchM_Init(const SchM_ConfigType* ConfigPtr) ([SWS_Rte_07270]). It is executed synchronously and must mandatory return within a finite execution time without entering an infinite loop ([SWS_Rte_07273]).

During the initialization sequence, SchM_Init performs the following steps:

• It initiates the transition to the initial mode for every mode machine instance belonging to the Basic Software Scheduler ([SWS_Rte_07532]).
• It starts the activation of BswSchedulableEntity instances triggered by BswBackgroundEvent events ([SWS_Rte_07584]).
• It calls the initialization functions Rte_Rips_SchM_Init of all participating RTE Implementation Plug-Ins ([SWS_Rte_80051]).

Call Context and Ordering Requirements

SchM_Init may only be called exactly once on each Core by the EcuStateManager as soon as the BSW modules required by the Basic Software Scheduler have been initialized ([SWS_Rte_CONSTR_09055]). Subsequent APIs such as Rte_Start may only be called after complete termination of SchM_Init ([SWS_Rte_CONSTR_09036]).

Error handling

If SchM_Init is called with a NULL pointer as parameter, the Basic Software Scheduler reports the error RTE_E_DET_ILLEGAL_VARIANT_CRITERION_VALUE (0x02) ([SWS_Rte_07684]). If scheduler APIs (such as SchM_Switch, SchM_Mode, or SchM_Start) or Rte_Start are called before SchM_Init, the error RTE_E_UNINIT (0x07) is reported when RteDevErrorDetectUninit is activated ([SWS_Rte_07683]).

use

The function SchM_Start serves to start up the Basic Software Scheduler in the RTE module and is always provided as part of the interface generation [SWS_Rte_04547]. It has the parameterless C signature void SchM_Start(void) [SWS_Rte_04546] and returns no value. For execution, the binding requirement applies that the call must return within a finite runtime and must under no circumstances enter an infinite loop [SWS_Rte_04548]. In the absence of asynchronous callback mechanisms, it is likely to be a synchronously blocking initialization call. Question Q-b6ad9ed696841d7a (open)

Call Context and Concurrency

Strict restrictions apply to the call context and the interaction with other system components:

• Caller and frequency: The function may be called on each processor core exclusively by the EcuStateManager and only exactly once there [SWS_Rte_CONSTR_09055].
• Sequence conditions: The call may only take place after all Basic Software modules required by the Basic Software Scheduler part of the RTE have been completely initialized [SWS_Rte_CONSTR_09055].
• Interaction during system startup: After execution, the Basic Software Scheduler is operational; the call must unconditionally take place before the initialization of the BSW Manager via BswM_Init() [SWS_Rte_07273].

Error handling

Specific error codes, return values, or notifications to the DET or DEM are not defined in the payload for this function.

use

The function SchM_StartTiming has the parameterless signature void SchM_StartTiming(void) [SWS_Rte_04549] and is always generated by the RTE generator [SWS_Rte_04550]. Its call starts periodic events for BSW and SWCs [SWS_Rte_04548] by initiating the activation of BswSchedulableEntity instances triggered by BswTimingEvents [SWS_Rte_07574]. The function must return within a finite execution time and must not execute an infinite loop [SWS_Rte_04551].

Call Context and Restrictions

Prior to calling SchM_StartTiming, SchM_Init must have been called mandatorily [SWS_Rte_04548]. In addition, the mandatory restriction applies that SchM_StartTiming may be called on each Core only exactly once by EcuStateManager after all Basic Software modules required for the Basic Software Scheduler have been initialized [SWS_Rte_CONSTR_09055].

Error handling

If SchM_StartTiming is called before SchM_Init, the Basic Software Scheduler or the RTE reports error RTE_E_UNINIT (0x07), provided development error detection RteDevErrorDetectUninit is enabled [SWS_Rte_07683].

Usage and Functional Scope

The function SchM_Deinit serves to finalize the Basic Software Scheduler part of the RTE on the Core on which it is called [SWS_Rte_04551]. During this process, the service releases all system resources allocated by the BSW scheduler on this Core [SWS_Rte_04551]. The function has neither parameters nor a return value (void SchM_Deinit(void)) [SWS_Rte_07274] and is generally always generated by the RTE generator [SWS_Rte_07275]. Regarding timing behavior, the specification requires that SchM_Deinit must return within a finite execution time [SWS_Rte_07277].

Call Context and Ordering Requirements

Mandatory sequencing requirements apply for invocation during the ECU shutdown phase:

• The function SchM_Deinit may only be used after the RTE has been completely finalized, that is, after the termination of Rte_Stop [SWS_Rte_CONSTR_09056].
• The call must be made by EcuStateManager before the basic layers required for operating the Basic Software Scheduler are shut down [SWS_Rte_CONSTR_09057].
• After SchM_Deinit has been called on a Core, the BSW scheduler on this Core may no longer activate or start any instances of BswSchedulableEntity [SWS_Rte_07586].

Plug-In Cleanup

As part of deinitialization, the RTE mandatorily calls the functions Rte_Rips_SchM_Deinit of all participating RTE Implementation Plug-Ins within SchM_Deinit in order to complete their cleanup [SWS_Rte_80054].

In the Rte module, the handler function <name of the Invocation Handler> handles the synchronous invocation of various runnable types via a transformer [SWS_Rte_89015]. The supported entities include server runnables, hard error runnables, ASCR runnables, and triggered runnables [SWS_Rte_89015].

The interface has neither input, input/output, nor output parameters and returns no value (signature void (void)) [SWS_Rte_89015]. The call is handled synchronously and is identified by the service ID 0xEE [SWS_Rte_89015]. The declaration is provided via the header file Rte_Rips_<PlugIn>.h [SWS_Rte_89015].

Regarding concurrency, the function is declared as conditionally reentrant (Conditional Reentrant) [SWS_Rte_89015]. This likely means that a concurrent call is only permitted if different execution contexts or separate plug-in instances are present. Question Q-24aabb36a2be58f4 (open) The identifier <name of the Invocation Handler> as well as the header designation <PlugIn> represent placeholders; the actual name is presumably determined during plug-in configuration.

The function Rte_Rips_SchM_Deinit serves to deinitialize those components of an RTE Implementation Plug-In that are relevant to the operations of the Basic Software Scheduler (SchM) [SWS_Rte_89019]. It is one of the mandatory lifecycle interfaces that must be provided by every RTE Implementation Plug-In alongside Rte_Rips_SchM_Init, Rte_Rips_Rte_Start, and Rte_Rips_Rte_Stop [SWS_Rte_70047].

The following specifications apply to integration and usage:

• Call context and sequence: The interface has the signature void Rte_Rips_SchM_Deinit (void), takes no parameters, and provides no return value [SWS_Rte_89019]. It is executed synchronously [SWS_Rte_89019]. The call is not made by software components, but is coordinated by the RTE within SchM_Deinit for all participating plug-ins [SWS_Rte_80054].
• File inclusion and identifier: The declaration is available via the header Rte_Rips_<PlugIn>.h; the function has the service ID 0xF3 [SWS_Rte_89019].
• Concurrency and restrictions: The function is specified as non-reentrant (Non Reentrant) [SWS_Rte_89019]. From this it is likely to follow that during the call in SchM_Deinit, competing SchM activities may no longer access the plug-in. Question Q-60aec1abc9e891b2 (open)
• Error handling: The specification provides neither error codes nor return values for Rte_Rips_SchM_Deinit and defines no error messages to DET or DEM [SWS_Rte_89019].

The data type Rte_Rips_SwitchNotificationStatusType ([SWS_Rte_91113]) is based on uint8 and is provided via Rte_Type.h. It serves to signal the status of enqueue and dequeue operations on a mode queue in the context of RTE Implementation Plug-Ins.

The value range comprises status codes for both directions of operation ([SWS_Rte_91113]):

• RTE_SWITCH_NOTIFICATION_SKIP (0x00): The mode switch notification cannot be dequeued.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_FIRST (0x01): The notification was enqueued into an empty queue.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_NOT_FIRST (0x02): The notification was enqueued into an already occupied queue.
• RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED (0x03): Enqueueing into a non-empty queue has failed.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_LAST (0x04): The last mode switch notification was dequeued from the queue.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_NOT_LAST (0x05): A notification was dequeued; further notifications remain in the queue.

In usage, the type appears in two synchronous, reentrant interfaces: The function Rte_Rips_<PlugIn>_Switch_<BswSwcI>_<MMI> ([SWS_Rte_91114]) receives the status as an input parameter switchNotificationStatus to notify the plug-in about enqueue operations. In contrast, the function Rte_Rips_<PlugIn>_DequeueModeSwitch_<MMI>_<OsTask> ([SWS_Rte_91115]) returns the type as a return value when a notification is dequeued from the queue after completion of the last on-entry ExecutableEntity.

Errors during enqueuing are reported functionally via the state value RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED ([SWS_Rte_91113]); separate DET or DEM entries are not indicated in the payload. Interpretation: The specification text "was enqueued from mode queue" for the dequeue constants is likely editorial and refers to the dequeue operation. Question Q-6e9e040dcd341f66 (open) The element and the associated interfaces are marked as draft ([SWS_Rte_91113]).

The data type Rte_DsmqStatusType is based on uint8 and is defined together with its literals in the header file Rte_Type.h in accordance with [SWS_Rte_80085] and [SWS_Rte_91102]. It serves to signal the status of enqueue and dequeue operations for mode switch notifications in a Distributed Shared Mode Queue (DSMQ) [SWS_Rte_91102].

The value range comprises the following literals [SWS_Rte_91102]:

• RTE_DSMQ_ENQUEUED_FIRST (0x01): The notification was enqueued into a previously empty DSMQ.
• RTE_DSMQ_ENQUEUED_NOT_FIRST (0x02): The enqueuing occurred into an already populated (non-empty) DSMQ.
• RTE_DSMQ_ENQUEUE_FAILED (0x03): Enqueuing into a non-empty DSMQ failed.
• RTE_DSMQ_DEQUEUED_LAST (0x04): The last mode switch notification was dequeued from the DSMQ.
• RTE_DSMQ_DEQUEUED_NOT_LAST (0x05): A notification was dequeued while further notifications remain in the queue.

For error handling, the literal RTE_DSMQ_ENQUEUE_FAILED signals a failure of the enqueuing operation when the queue is not empty [SWS_Rte_91102].

The type is used as a passing parameter dsmqstatus to interfaces of the RTE Implementation Plug-In (RIPS). The function Rte_Rips_<PlugIn>_DsmqSwitch_<BswSwcI>_<MMI> synchronously informs the plug-in about enqueuing into a DSMQ [SWS_Rte_91103]. In addition, Rte_Rips_<PlugIn>_DsmqTransitionEnd_<BswSwcI>_<MMI> synchronously reports the completion of a mode transition in a DSMQ transition OsTask to the RIPS [SWS_Rte_91106]. Both callback services are declared as synchronous and reentrant [SWS_Rte_91103], [SWS_Rte_91106].