AUTOSAR RTE

La función Rte_Start asigna e inicializa los recursos del sistema y de comunicación utilizados por la RTE [SWS_Rte_03015]. La API se genera siempre [SWS_Rte_01309], tiene la firma Std_ReturnType Rte_Start (void) [SWS_Rte_02569] y debe retornar obligatoriamente dentro de un tiempo de ejecución finito sin entrar en un bucle infinito [SWS_Rte_02585].

La función solo debe ser llamada en cada Core exactamente una vez por el EcuStateManager desde un contexto de OS de confianza, después de que se hayan inicializado todos los módulos de Basic Software requeridos por la RTE [SWS_Rte_CONSTR_09035]. La llamada se ejecuta de forma independiente en cada Core [SWS_Rte_07615] y lleva a cabo las actividades de arranque específicas de partición para todas las particiones asignadas a ese Core [SWS_Rte_07616].

Durante el desarrollo, la RTE inicializa las variables asignadas para bloques de RAM en función de la estrategia configurada [SWS_Rte_07632]. Tras las inicializaciones de variables, pero aún antes de la ejecución de Runnables, la RTE llama a las funciones de inicialización Rte_Rips_Rte_Start de todos los RTE Implementation Plug-Ins involucrados [SWS_Rte_80052]. A continuación, la RTE activa por única vez todos los Runnables desencadenados por InitEvent [SWS_Rte_06761] e inicia el cambio a los modos iniciales [SWS_Rte_06766]. Si la API Rte_StartTiming no existe, Rte_Start inicia además la activación de Runnables que son desencadenados por TimingEvent [SWS_Rte_07575] o BackgroundEvent [SWS_Rte_07178].

Para el tratamiento de errores, la RTE o bien el SchM notifica el error RTE_E_UNINIT (0x07) con RteDevErrorDetectUninit activado si se llama a Rte_Start antes de SchM_Init [SWS_Rte_07683]. Antes de la ejecución de Rte_Start no deben llamarse APIs de tiempo de ejecución de la RTE, ya que de lo contrario esto conducirá asimismo a RTE_E_UNINIT [SWS_Rte_07682]; por el contrario, Rte_SetMirror sí puede llamarse ya antes de Rte_Start [SWS_Rte_07319].

La función Rte_Stop ([SWS_Rte_02570]) se genera en cada configuración ([SWS_Rte_01310]) y sirve para finalizar la RTE en el Core que la ejecuta ([SWS_Rte_01262]). Durante este proceso se liberan todos los recursos del sistema y de comunicación asignados por la RTE en este Core ([SWS_Rte_01262]). Se garantiza que la llamada síncrona retorna dentro de un tiempo de ejecución finito ([SWS_Rte_02584]).

En el sistema global, Rte_Stop debe ser llamada por el EcuStateManager antes de que se detengan los módulos de Basic Software requeridos por la RTE ([SWS_Rte_CONSTR_09038]). Durante el desarrollo, la RTE llama a las funciones de parada Rte_Rips_Rte_Stop de todos los RTE-Implementation-Plug-Ins involucrados ([SWS_Rte_80053]), los cuales deben proporcionar estas interfaces de ciclo de vida ([SWS_Rte_70047]). SchM_Deinit solo debe ejecutarse tras la finalización completa de Rte_Stop ([SWS_Rte_CONSTR_09056]).

Tras llamar a Rte_Stop en un Core, la RTE ya no activa, inicia ni libera instancias de RunnableEntity en él ([SWS_Rte_02538]). Sin verse afectado por ello, Rte_GetMirror sigue siendo invocable, siempre y cuando el sistema operativo subyacente esté activo ([SWS_Rte_07350]).

En caso de error, la función devuelve RTE_E_LIMIT siempre que se haya superado un límite interno o falle la asignación de un recurso necesario ([SWS_Rte_01262]). Si RteDevErrorDetectUninit está activado, la RTE notifica el error RTE_E_UNINIT (0x07) cuando se invocan APIs no admisibles después de Rte_Stop ([SWS_Rte_07682]).

La función Rte_StartTiming sirve para habilitar, tras finalizar la inicialización de la RTE, la activación de RunnableEntitys desencadenados por TimingEvents o BackgroundEvents ([SWS_Rte_06753], [SWS_Rte_06756]). Se implementa como una función sin parámetros y sin valor de retorno ([SWS_Rte_06754], [SWS_Rte_06758]), y debe retornar dentro de un tiempo de ejecución finito ([SWS_Rte_06757]).

En cuanto al contexto de llamada y al orden, la API está sujeta a restricciones estrictas:

• La función solo puede llamarse una vez que la RTE se haya inicializado por completo, concretamente tras finalizar la llamada de Rte_Start ([SWS_Rte_CONSTR_09061]).
• Está prevista para ejecutarse tras la última llamada de una función Rte_Init ([SWS_Rte_06753]).
• La API se genera o proporciona tan pronto como se genera al menos una API Rte_Init ([SWS_Rte_06755]).

Si se llama a Rte_StartTiming, esta inicia inmediatamente las activaciones periódicas y basadas en segundo plano ([SWS_Rte_06759], [SWS_Rte_06760]). En cambio, si la API no existe en la configuración, la propia llamada a Rte_Start asume la habilitación de los runnables desencadenados por TimingEvents y BackgroundEvents ([SWS_Rte_07178], [SWS_Rte_07575]). No se definen códigos de error o valores de retorno específicos para esta llamada ([SWS_Rte_06754]).

Uso y semántica

La función SchM_Init asigna e inicializa los recursos del sistema utilizados por el Basic Software Scheduler (SchM) del RTE en el Core llamador ([SWS_Rte_08060]). La interfaz siempre se genera ([SWS_Rte_07271]) y posee la firma void SchM_Init(const SchM_ConfigType* ConfigPtr) ([SWS_Rte_07270]). Se ejecuta de forma síncrona y debe retornar obligatoriamente dentro de un tiempo de ejecución finito, sin entrar en un bucle infinito ([SWS_Rte_07273]).

Durante la secuencia de inicialización, SchM_Init realiza los siguientes pasos:

• Inicia para cada instancia de máquina de modos perteneciente al Basic Software Scheduler la transición al modo inicial ([SWS_Rte_07532]).
• Inicia la activación de instancias de BswSchedulableEntity desencadenadas por eventos de BswBackgroundEvent ([SWS_Rte_07584]).
• Llama a las funciones de inicialización Rte_Rips_SchM_Init de todos los RTE Implementation Plug-Ins participantes ([SWS_Rte_80051]).

Contexto de llamada y condiciones de orden

SchM_Init solo puede ser llamada exactamente una vez en cada Core por el EcuStateManager, tan pronto como se hayan inicializado los módulos BSW requeridos por el Basic Software Scheduler ([SWS_Rte_CONSTR_09055]). Las API subsiguientes, como Rte_Start, solo pueden llamarse tras la finalización completa de SchM_Init ([SWS_Rte_CONSTR_09036]).

Manejo de errores

Si se llama a SchM_Init con un puntero NULL como parámetro, el Basic Software Scheduler notifica el error RTE_E_DET_ILLEGAL_VARIANT_CRITERION_VALUE (0x02) ([SWS_Rte_07684]). Si se llaman API del Scheduler (como SchM_Switch, SchM_Mode o SchM_Start) o Rte_Start antes de SchM_Init, con RteDevErrorDetectUninit activado se notifica el error RTE_E_UNINIT (0x07) ([SWS_Rte_07683]).

usar

La función SchM_Start sirve para la puesta en servicio del Basic Software Scheduler en el módulo RTE y se proporciona básicamente siempre en el marco de la generación de interfaces [SWS_Rte_04547]. Presenta la firma de C sin parámetros void SchM_Start(void) [SWS_Rte_04546] y no devuelve ningún valor de retorno. Para la ejecución rige la prescripción vinculante de que la llamada debe retornar en un tiempo de ejecución finito y en ningún caso debe caer en un bucle infinito [SWS_Rte_04548]. A falta de mecanismos de callback asíncronos, cabe presumir que se trata de una llamada de inicialización síncrona bloqueante. Pregunta Q-b6ad9ed696841d7a (abierta)

Contexto de llamada y concurrencia

Para el contexto de llamada y la interacción con otros componentes del sistema rigen restricciones estrictas:

• Llamador y frecuencia: en cada núcleo de procesador, la función solo debe llamarse de manera exclusiva por el EcuStateManager y allí únicamente una sola vez [SWS_Rte_CONSTR_09055].
• Condiciones de secuencia: la llamada solo puede tener lugar después de que se hayan inicializado por completo todos los módulos de Basic Software que requiere la parte del Basic Software Scheduler de la RTE [SWS_Rte_CONSTR_09055].
• Interacción en el arranque del sistema: tras la ejecución, el Basic Software Scheduler está operativo; la llamada debe realizarse obligatoriamente antes de la inicialización del BSW-Manager a través de BswM_Init() [SWS_Rte_07273].

Manejo de errores

En la carga útil no se definen para esta función códigos de error específicos, valores de retorno ni notificaciones al DET o DEM.

usar

La función SchM_StartTiming tiene la signatura sin parámetros void SchM_StartTiming(void) [SWS_Rte_04549] y siempre es generada por el generador de la RTE [SWS_Rte_04550]. Su invocación inicia eventos periódicos para BSW y SWCs [SWS_Rte_04548] al dar inicio a la activación de instancias de BswSchedulableEntity desencadenadas por BswTimingEvents [SWS_Rte_07574]. La función debe retornar dentro de un tiempo de ejecución finito y no debe ejecutar un bucle infinito [SWS_Rte_04551].

Contexto de llamada y restricciones

Antes de invocar SchM_StartTiming debe haberse invocado obligatoriamente SchM_Init [SWS_Rte_04548]. Además, se aplica la restricción vinculante de que SchM_StartTiming solo debe ser invocada en cada Core exactamente una vez por el EcuStateManager después de que se hayan inicializado todos los módulos de software básico requeridos para el Basic Software Scheduler [SWS_Rte_CONSTR_09055].

Manejo de errores

Si se invoca SchM_StartTiming antes de SchM_Init, el Basic Software Scheduler o la RTE notifica el error RTE_E_UNINIT (0x07), siempre que la detección de errores de desarrollo RteDevErrorDetectUninit esté activada [SWS_Rte_07683].

Uso y alcance de funciones

La función SchM_Deinit sirve para finalizar la parte del Basic Software Scheduler de la RTE en aquel Core en el que se invoca [SWS_Rte_04551]. En este proceso, el servicio libera todos los recursos del sistema ocupados por el BSW Scheduler en dicho Core [SWS_Rte_04551]. La función no tiene parámetros ni valor de retorno (void SchM_Deinit(void)) [SWS_Rte_07274] y, por principio, el generador de la RTE siempre la genera [SWS_Rte_07275]. Con respecto al comportamiento temporal, la especificación exige que SchM_Deinit deba retornar dentro de un tiempo de ejecución finito [SWS_Rte_07277].

Contexto de llamada y condiciones de orden

Para la invocación durante la fase de desconexión de la ECU se aplican prescripciones de orden vinculantes:

• La función SchM_Deinit solo debe utilizarse después de que la RTE se haya finalizado por completo, es decir, tras la finalización de Rte_Stop [SWS_Rte_CONSTR_09056].
• La invocación debe realizarse por parte del EcuStateManager antes de que se apaguen las capas básicas requeridas para el funcionamiento del Basic Software Scheduler [SWS_Rte_CONSTR_09057].
• Una vez que SchM_Deinit ha sido invocada en un Core, el BSW Scheduler no debe activar ni iniciar ninguna instancia más de BswSchedulableEntity en ese Core [SWS_Rte_07586].

Limpieza de complementos

En el marco de la desinicialización, la RTE invoca de forma vinculante dentro de SchM_Deinit las funciones Rte_Rips_SchM_Deinit de todos los RTE Implementation Plug-Ins participantes para completar su limpieza [SWS_Rte_80054].

La función manejadora <name of the Invocation Handler> asume en el módulo Rte la llamada síncrona de diversos tipos de runnables a través de un transformer [SWS_Rte_89015]. Entre las entidades admitidas se encuentran server runnables, hard error runnables, ASCR runnables y runnables desencadenados [SWS_Rte_89015].

La interfaz no tiene parámetros de entrada, de entrada/salida ni de salida, y no devuelve ningún valor (firma void (void)) [SWS_Rte_89015]. La llamada se procesa de forma síncrona y está identificada mediante el Service ID 0xEE [SWS_Rte_89015]. La declaración se proporciona a través del archivo de cabecera Rte_Rips_<PlugIn>.h [SWS_Rte_89015].

En cuanto a la concurrencia, la función está declarada como condicionalmente reentrante (Conditional Reentrant) [SWS_Rte_89015]. Es probable que esto signifique que una llamada concurrente solo está permitida si existen diferentes contextos de ejecución o instancias de plug-in separadas. Pregunta Q-24aabb36a2be58f4 (abierta) El identificador <name of the Invocation Handler> así como la denominación de cabecera <PlugIn> representan marcadores de posición; el nombre real probablemente se determine durante la configuración del plug-in.

La función Rte_Rips_SchM_Deinit sirve para desinicializar aquellos componentes de un RTE Implementation Plug-In que son relevantes para las operaciones del Basic Software Scheduler (SchM) [SWS_Rte_89019]. Pertenece a las interfaces obligatorias del ciclo de vida que todo RTE Implementation Plug-In debe proporcionar junto con Rte_Rips_SchM_Init, Rte_Rips_Rte_Start y Rte_Rips_Rte_Stop [SWS_Rte_70047].

Para la integración y el uso se aplican las siguientes disposiciones:

• Contexto de llamada y secuencia: La interfaz posee la firma void Rte_Rips_SchM_Deinit (void), no acepta parámetros y no devuelve ningún valor de retorno [SWS_Rte_89019]. Se ejecuta de forma síncrona [SWS_Rte_89019]. La llamada no la realizan los componentes de software, sino que la coordina el RTE dentro de SchM_Deinit para todos los complementos (plug-ins) participantes [SWS_Rte_80054].
• Inclusión de archivos e identificador: La declaración está disponible a través de la cabecera Rte_Rips_<PlugIn>.h; la función posee el Service-ID 0xF3 [SWS_Rte_89019].
• Concurrencia y restricciones: La función está especificada como no reentrante (Non Reentrant) [SWS_Rte_89019]. De ello es probable que se deduzca que, durante la llamada en SchM_Deinit, ninguna actividad concurrente del SchM puede acceder ya al complemento. Pregunta Q-60aec1abc9e891b2 (abierta)
• Tratamiento de errores: La especificación no prevé para Rte_Rips_SchM_Deinit códigos de error ni valores de retorno, y no define mensajes de error para DET o DEM [SWS_Rte_89019].

El tipo de datos Rte_Rips_SwitchNotificationStatusType ([SWS_Rte_91113]) se basa en uint8 y se proporciona a través de Rte_Type.h. Sirve para señalizar el estado de las operaciones de Enqueue y Dequeue en una cola de modos (Mode Queue) en el contexto de RTE Implementation Plug-Ins.

El rango de valores comprende códigos de estado para ambas direcciones de operación ([SWS_Rte_91113]):

• RTE_SWITCH_NOTIFICATION_SKIP (0x00): La notificación de cambio de modo no se puede desencolar.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_FIRST (0x01): La notificación se insertó en una cola vacía.
• RTE_SWITCH_NOTIFICATION_ENQUEUED_NOT_FIRST (0x02): La notificación se insertó en una cola ya ocupada.
• RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED (0x03): El encolado en una cola no vacía ha fallado.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_LAST (0x04): Se ha extraído de la cola la última notificación de cambio de modo.
• RTE_SWITCH_NOTIFICATION_DEQUEUED_NOT_LAST (0x05): Se ha extraído una notificación; permanecen más notificaciones en la cola.

En su uso, el tipo interviene en dos interfaces síncronas y reentrantes: la función Rte_Rips_<PlugIn>_Switch_<BswSwcI>_<MMI> ([SWS_Rte_91114]) recibe el estado como parámetro de entrada switchNotificationStatus para notificar al complemento sobre procesos de Enqueue. En cambio, la función Rte_Rips_<PlugIn>_DequeueModeSwitch_<MMI>_<OsTask> ([SWS_Rte_91115]) entrega el tipo como valor de retorno cuando, tras finalizar la última On-Entry ExecutableEntity, se extrae una notificación de la cola.

Los errores durante la inserción en la cola se notifican funcionalmente a través del valor de estado RTE_SWITCH_NOTIFICATION_ENQUEUE_FAILED ([SWS_Rte_91113]); en el payload no se indican entradas DET o DEM independientes. Interpretación: Es probable que el texto de la especificación «was enqueued from mode queue» en las constantes de Dequeue se deba a razones editoriales y se refiera a la operación de extracción. Pregunta Q-6e9e040dcd341f66 (abierta) El elemento, así como las interfaces asociadas, están marcados como borrador (Draft) ([SWS_Rte_91113]).

El tipo de datos Rte_DsmqStatusType se basa en uint8 y se define, según [SWS_Rte_80085] y [SWS_Rte_91102], junto con sus literales en el archivo de cabecera Rte_Type.h. Sirve para señalizar el estado de operaciones de Enqueue y Dequeue para notificaciones de cambio de modo en una Distributed Shared Mode Queue (DSMQ) [SWS_Rte_91102].

El rango de valores comprende los siguientes literales [SWS_Rte_91102]:

• RTE_DSMQ_ENQUEUED_FIRST (0x01): La notificación se insertó en una DSMQ previamente vacía.
• RTE_DSMQ_ENQUEUED_NOT_FIRST (0x02): La inserción se realizó en una DSMQ ya ocupada (no vacía).
• RTE_DSMQ_ENQUEUE_FAILED (0x03): La inserción en una DSMQ no vacía ha fallado.
• RTE_DSMQ_DEQUEUED_LAST (0x04): La última notificación de cambio de modo se ha desencolado de la DSMQ.
• RTE_DSMQ_DEQUEUED_NOT_LAST (0x05): Se ha extraído una notificación, mientras que permanecen más notificaciones en la cola.

Para el tratamiento de errores, el literal RTE_DSMQ_ENQUEUE_FAILED señaliza un fallo en la operación de inserción en la cola cuando la cola no está vacía [SWS_Rte_91102].

El tipo se utiliza como parámetro de transferencia dsmqstatus en interfaces del RTE Implementation Plug-In (RIPS). La función Rte_Rips_<PlugIn>_DsmqSwitch_<BswSwcI>_<MMI> informa al complemento de forma síncrona sobre la inserción en una DSMQ [SWS_Rte_91103]. Además, Rte_Rips_<PlugIn>_DsmqTransitionEnd_<BswSwcI>_<MMI> notifica de forma síncrona la finalización de una transición de modo en un DSMQ-Transition-OsTask al RIPS [SWS_Rte_91106]. Ambos servicios de callback están declarados como síncronos y reentrantes [SWS_Rte_91103], [SWS_Rte_91106].