AUTOSAR Classic Runtime Environment (RTE)

El clúster de módulos Runtime Environment (RTE) implementa el AUTOSAR Virtual Functional Bus en la ECU y proporciona API estandarizadas para la comunicación tipificada sender-receiver y client-server de componentes de software [SWS_Rte_01091], [SWS_Rte_01102]. Integra el Basic Software Scheduler (SchM) para la planificación cíclica de los módulos de Basic Software y se conecta a OS/IOC, así como a la pila de comunicación (COM, LdCom) [SWS_Rte_01376], [SWS_Rte_04546]. Al mismo tiempo, la RTE garantiza la consistencia de datos y transiciones de modo deterministas mediante áreas protegidas configurables, almacenamiento en búfer y secuencias de transición definidas en 10 etapas [SWS_Rte_02665], [SWS_Rte_03504].

más ›

El clúster de módulos Runtime Environment (RTE) constituye la realización del Virtual Functional Bus (VFB) a nivel de ECU. Desacopla por completo los componentes de software de AUTOSAR (SWCs) del Basic Software subyacente y coordina a través del Basic Software Scheduler (SchM) la planificación de los módulos BSW [SWS_Rte_04546], [SWS_Rte_05165]. El clúster gestiona tanto los accesos intrapartición como los flujos de datos interpartición a través del OS-IOC, así como el bus de la ECU a través de los módulos COM y LdCom [SWS_Rte_01376], [SWS_Rte_02736], SWS_RTE p. 106.

Diagrama de contexto: integración del clúster de RTE y SchM entre la capa de aplicación (SWCs), OS/IOC y los servicios de Basic Software. Fuentes: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

La comunicación se apoya en patrones sender-receiver y client-server: los datos S/R se transmiten de manera implícitamente consistente a través de copias en búfer (`Rte_IRead`/`Rte_IWrite`) o de forma explícita directa y en búfer (`Rte_Read`/`Rte_Write`/`Rte_Receive`) [SWS_Rte_01091], [SWS_Rte_02521], [SWS_Rte_06000]. En caso de caída o presencia de señales no válidas, se aplican mecanismos como la sustitución por `initValue` o estrategias de `handleInvalid` [SWS_Rte_05030], [SWS_Rte_06009]. En ejecuciones asíncronas, las llamadas client-server (`Rte_Call`, `Rte_Result`) se sincronizan a través de colas FIFO en el lado del servidor y del cliente, y se asignan unívocamente mediante identificadores de transacción [SWS_Rte_01102], [SWS_Rte_02527], [SWS_Rte_02649].

En la gestión de tareas y del ciclo de vida, la RTE garantiza la reentrancia mediante código compartido y protege las secciones críticas a través de mecanismos de bloqueo configurables como deshabilitación de interrupciones, recursos del OS o spinlocks del OS [SWS_Rte_03015], [SWS_Rte_03504]. Los cambios de modo pasan por una rigurosa secuencia de 10 etapas, desde activaciones OnExit y OnTransition hasta OnEntry, y concluyen de forma ordenada mediante eventos de confirmación [SWS_Rte_02665], [SWS_Rte_02679].

más ›

Arquitectura del sistema & rol del clúster de módulos

El clúster de módulos de la Runtime Environment (RTE) constituye la columna vertebral funcional y de comunicación de la AUTOSAR Classic Platform. Representa la realización concreta del Virtual Functional Bus (VFB) en una ECU y desacopla por completo los componentes de software (SWCs) del Basic Software (BSW) subyacente y del hardware del microcontrolador SWS_RTE p. 106. Dentro del clúster, la RTE propiamente dicha asume la intermediación de la comunicación de aplicaciones inter- e intra-ECU, mientras que el Basic Software Scheduler (SchM) integrado controla la secuenciación de ejecución, el aseguramiento de la consistencia y la planificación cíclica de los módulos BSW [SWS_Rte_04546], [SWS_Rte_05165].

La arquitectura despliega interfaces estandarizadas entre las SW-Cs de aplicación, los componentes de sensores/actuadores y las capas de BSW. Para la interconexión en todo el vehículo, el clúster de la RTE se apoya directamente en la pila de comunicación: los mensajes orientados a señales se transfieren al módulo COM, mientras que los grandes volúmenes de datos se tramitan a través del módulo LdCom (Large Data COM) [SWS_Rte_01376], [SWS_Rte_04527]. El aislamiento de procesos y de memoria a través de los límites de partición y de núcleo lo proporcionan el sistema operativo AUTOSAR (OS) y su mecanismo de comunicación entre aplicaciones del sistema operativo (IOC) [SWS_Rte_02736]. Los datos de calibración y los bloques de memoria se vinculan mediante descriptores estandarizados al NVRAM Manager (NvM) y a herramientas de calibración [SWS_Rte_03961], [SWS_Rte_05118].

Diagrama de contexto: integración del clúster de RTE y SchM entre la capa de aplicación (SWCs), OS/IOC y los servicios de Basic Software. Fuentes: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

Interacción y rutas de interacción entre los módulos

La interacción en el clúster de la RTE distingue estrictamente entre comunicación sender-receiver (S/R) y client-server (C/S). En la comunicación S/R, la RTE admite semánticas de lectura y escritura tanto implícitas como explícitas: en el acceso implícito (`Rte_IRead`, `Rte_IWrite`), la RTE genera al inicio de la ejecución del runnable una copia local que se mantiene consistente durante todo el tiempo de ejecución [SWS_Rte_06000], [SWS_Rte_03744]. En el acceso explícito (`Rte_Read`, `Rte_Write`, `Rte_Send`, `Rte_Receive`), el intercambio de datos se realiza de forma directa síncrona o mediante colas [SWS_Rte_01091], [SWS_Rte_01092]. Para eventos con colas (`swImplPolicy = queued`), la RTE establece colas FIFO en el lado del receptor; si dicho búfer se desborda, el elemento se descarta y se establece un estado de error [SWS_Rte_02521], [SWS_Rte_02523].

Si la ruta de datos atraviesa los límites de las unidades de control de motor (inter-ECU), la RTE transforma y serializa las estructuras de datos compuestas y llama a `Com_SendSignal` o bien a `Com_SendSignalGroup` para garantizar la transmisión atómica de PDU en el módulo COM [SWS_Rte_04527]. En el caso de matrices de datos de gran tamaño, la RTE recurre alternativamente a `LdCom_Transmit` y, en protocolos de transporte (TP), bloquea el búfer asociado hasta la confirmación a través de callbacks [SWS_Rte_01377], [SWS_Rte_01379]. En el lado del receptor, la RTE recibe datos de forma asíncrona mediante callbacks de COM y deriva de ellos eventos de activación para runnables de aplicación [SWS_Rte_03530], [SWS_Rte_03531]. Si aún no han llegado datos de bus, la RTE entrega los valores iniciales configurados [SWS_Rte_06009], [SWS_Rte_06010].

Diagrama de secuencia: flujo de datos explícito sender-receiver a través de los límites de las unidades de control con almacenamiento en búfer y emisión de valores iniciales. Fuentes: [SWS_Rte_06010], [SWS_Rte_04527], [SWS_Rte_03530], AUTOSAR_SWS_RTE p. 148.

En la comunicación cliente-servidor, la RTE genera `Rte_Call` para llamadas síncronas y APIs separadas de llamada y consulta (`Rte_Call`, `Rte_Result`) para llamadas asíncronas [SWS_Rte_01102], [SWS_Rte_01111]. Siempre que las llamadas no puedan resolverse directamente como una función C en el mismo contexto, la RTE almacena en búfer las solicitudes a nivel de servidor en colas FIFO y las respuestas a nivel de cliente en una cola de profundidad 1 [SWS_Rte_02527], [SWS_Rte_02528]. Para llamadas C/S entre particiones o entre unidades de control, la RTE utiliza identificadores de transacción compuestos por ID de cliente y contador de secuencia a fin de asignar con precisión las respuestas al llamador original [SWS_Rte_02649], [SWS_Rte_03885].

Sincronización, reentrancia y contextos de tareas

La ejecución de código de programa en el cluster RTE se produce dentro de tareas de OS o contextos de ISR. La RTE distingue entre runnables simples (categoría 1 sin llamadas bloqueantes a OS) y runnables extendidos (categoría 2 con puntos de espera), que se reactivan desde el estado `WaitPoint` mediante eventos como `DataReceivedEvent` o callbacks de COM [SWS_Rte_03532], SWS_RTE p. 304. La activación concurrente de la misma instancia de una Runnable Entity está estrictamente prohibida, a menos que el atributo `canBeInvokedConcurrently` esté configurado explícitamente en `TRUE` [SWS_Rte_03523]. En SWC con múltiples instancias, AUTOSAR apuesta de manera consecuente por el uso compartido de código (code-sharing): varias instancias comparten el mismo código ejecutable, pero acceden a datos separados y a Per-Instance-Memory (PIM) a través de descriptores específicos de cada instancia [SWS_Rte_02002], [SWS_Rte_03015], [SWS_Rte_02301].

Para proteger las secciones críticas, la RTE genera las denominadas Exclusive Areas (`Rte_Enter`, `Rte_Exit`). El mecanismo de sincronización subyacente se configura a través del parámetro `RteExclusiveAreaImplMechanism` [SWS_Rte_03504]. En este contexto se dispone de cinco estrategias definidas:

• ALL_INTERRUPT_BLOCKING: bloqueo global de todas las interrupciones de hardware [SWS_Rte_03504].
• OS_INTERRUPT_BLOCKING: bloqueo selectivo de interrupciones específicas de OS (categoría 2) [SWS_Rte_03504].
• OS_RESOURCE: uso de recursos del sistema operativo OSEK/AUTOSAR con protocolo de techo de prioridad [SWS_Rte_03504].
• OS_SPINLOCK: sincronización multinúcleo mediante spinlocks de OS para la coordinación entre tareas e ISR de diferentes núcleos [SWS_Rte_03504].
• NONE: omisión de bloqueos internos, siempre que la consistencia de los datos ya esté garantizada mediante una estricta priorización o planificación de tareas [SWS_Rte_03504].

Si se transfieren datos entre diferentes particiones de protección de memoria, la RTE comprueba los parámetros de puntero para impedir accesos a memoria no autorizados desde particiones no confiables [SWS_Rte_02752], [SWS_Rte_02753].

Ciclos de vida típicos y modos de funcionamiento

El ciclo de vida del sistema está sujeto a una estricta división en fases entre inicialización, funcionamiento normal y apagado controlado. Al iniciarse el sistema, primero se inicializa la parte SchM: el EcuM llama a `SchM_Start` en cada núcleo de procesador antes de iniciar módulos BSW como el BswM [SWS_Rte_04546], [SWS_Rte_04548]. A continuación, `SchM_StartTiming` activa los eventos periódicos de BSW y MainFunctions [SWS_Rte_04549], [SWS_Rte_04551]. Conforme a la restricción de diseño, `SchM_Start` y `SchM_StartTiming` deben llamarse exactamente una vez por núcleo SWS_RTE p. 928. Después, `Rte_Start` habilita la RTE de aplicación; si falla la asignación interna de recursos, la inicialización se interrumpe con `RTE_E_LIMIT` [SWS_Rte_01261], [SWS_Rte_01262].

Los modos de operación se representan mediante Mode-Declaration-Groups. Si un Mode Manager desencadena un cambio de modo a través de `Rte_Switch`, este se deposita en una cola FIFO [SWS_Rte_02631], [SWS_Rte_02718], [SWS_Rte_02719]. Durante la conmutación, cada máquina de modos pasa por una secuencia vinculante de 10 etapas [SWS_Rte_02665]: primero se activan las desactivaciones de modo para el modo de destino y se espera a las entidades en ejecución (pasos 1–2). Sigue la ejecución secuencial y terminación de Executable Entities OnExit (pasos 3–4), OnTransition (pasos 5–6) y OnEntry (pasos 7–8). Finalmente, se anula la desactivación del modo anterior y se activa el nuevo modo (paso 9), antes de acusar el cambio de modo a través de `ModeSwitchedAckEvent` o `Rte_SwitchAck` (paso 10) [SWS_Rte_02665], [SWS_Rte_02679], [SWS_Rte_02725]. A través de `RteModeToScheduleTableMapping`, los modos de operación también pueden vincularse directamente a OS-Schedule-Tables [SWS_Rte_05146].

Diagrama de secuencia: secuencia estandarizada de 10 etapas de un cambio de modo AUTOSAR con acuse de recibo. Fuentes: [SWS_Rte_02665], [SWS_Rte_02679], EXP_ModeManagementGuide p. 16.

La desinicialización se realiza al inicio de la fase de shutdown a través de `Rte_Stop`. Tras esta llamada, la RTE bloquea la activación, inicio o habilitación de más runnables en el núcleo correspondiente [SWS_Rte_02538]. Los datos S/R entrantes, así como las solicitudes C/S, se descartan e ignoran en el estado detenido de la RTE [SWS_Rte_02535], [SWS_Rte_02536].

Tratamiento de errores, monitorización de estado y validación de datos

Los estados de error y el estado de las interfaces se transmiten uniformemente al llamador en la RTE a través del tipo escalar `Std_ReturnType` [SWS_Rte_01034], SWS_RTE p. 586. La RTE diferencia entre errores de aplicación (valores de error 1–63), errores directos de infraestructura (valores 128–255), así como bits de estado superpuestos como pérdida de datos (`RTE_E_LOST_DATA = 64`) o caducidad (`RTE_E_MAX_AGE_EXCEEDED = 64`) SWS_RTE p. 586. Los valores de retorno típicos de infraestructura comprenden comunicación detenida (`RTE_E_COM_STOPPED = 128`), timeouts de comunicación y de respuesta (`RTE_E_TIMEOUT = 129`), falta de datos (`RTE_E_NO_DATA = 131`) y desbordamientos de recursos (`RTE_E_LIMIT = 130`) [SWS_Rte_01060], [SWS_Rte_01061], [SWS_Rte_01064]. Si la comprobación de rango de valores está activa, la RTE acusa los desbordamientos de rango con `RTE_E_OUT_OF_RANGE` [SWS_Rte_03845], [SWS_Rte_03846].

Para el tratamiento de señales no plausibles o erróneas, la RTE proporciona mecanismos de invalidación de datos. En el lado del transmisor, `Rte_Invalidate` marca la señal con un valor de sustitución definido [SWS_Rte_01206], [SWS_Rte_05024]. En el lado del receptor, el atributo `handleInvalid` controla la estrategia de sustitución: con `keep` se conserva el valor anterior y se desencadena un `DataReceiveErrorEvent`, mientras que con `replace` se realiza una sustitución automática por el `initValue` [SWS_Rte_05030], [SWS_Rte_05049]. Los fallos de comunicación en el nivel de red se monitorizan a través de `aliveTimeout`; si expira el tiempo de supervisión, el módulo COM notifica un timeout de recepción a la RTE a través de `Rte_COMCbkRxTOut`, tras lo cual se informa a los componentes dependientes o se activan valores de fallback [SWS_Rte_08061].