módulo ara::exec — Execution Management

El módulo Execution Management gestiona, como demonio central de la plataforma, el ciclo de vida determinista de los procesos POSIX en la AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement p. 18). Recibe estados de ejecución a través de ExecutionClient ([SWS_EM_02003]) e implementa de forma asíncrona transiciones de grupos de funciones ordenadas por State Management mediante el inicio y la finalización de procesos ([SWS_EM_02278]). Condiciones marco esenciales son la prohibición de dependencias de inicio entre grupos de funciones, así como la escalada estricta de errores ante infracciones de plazos (SWS ExecutionManagement p. 65).

más ›

El clúster funcional Execution Management (EM) constituye el demonio central de plataforma de la AUTOSAR Adaptive Platform para la gestión determinista de procesos y el control del ciclo de vida en el espacio de usuario POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). Separa estrictamente la toma de decisiones sobre políticas (Policy) de la ejecución técnica (Mechanism): mientras State Management define los estados objetivo, EM controla la creación de procesos, las secuencias y el tratamiento de señales (AUTOSAR AP EXP SWArchitecture p. 56). A través de [SWS_EM_02562] ExecutionClient, las aplicaciones y los servicios de plataforma notifican su estado [SWS_EM_02000] kRunning mediante [SWS_EM_02003] ReportExecutionState(), mientras que State Management solicita cambios de estado a través de [SWS_EM_02276] StateClient (AUTOSAR AP EXP SWArchitecture p. 48).

Diagrama de contexto: integración de Execution Management como demonio central entre State Management, el sistema operativo POSIX y los procesos cliente. Fuentes: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Tras el arranque por parte del sistema operativo, EM inicia State Management y lo sincroniza mediante [SWS_EM_02279] GetInitialMachineStateTransitionResult() con el estado de la máquina Startup (AUTOSAR AP SWS ExecutionManagement p. 52). Las transiciones posteriores de estados de [SWS_EM_02586] FunctionGroup se inician de forma asíncrona con [SWS_EM_02278] SetState(): EM finaliza de manera ordenada los procesos que ya no se necesitan mediante SIGTERM, inicia los procesos sucesores teniendo en cuenta las dependencias de inicio locales y resuelve el Future resultante tan pronto como todos los procesos están listos para operar (AUTOSAR AP SWS ExecutionManagement p. 53, SWS ExecutionManagement p. 71).

Diagrama de secuencias: cambio de estado exitoso de una Function Group con finalización ordenada y reinicio de procesos. Fuentes: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Para garantizar los requisitos de tiempo real, EM admite el premapeo determinista de procesos para evitar fallos de página (SWS ExecutionManagement p. 82), así como pools deterministas de workers y mecanismos de sincronización (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 92). Si un proceso incumple su ventana temporal de inicio, se activa el tratamiento de errores: EM finaliza el proceso, sitúa la Function Group en un Undefined State, invoca la devolución de llamada registrada ([SWS_EM_02276]) y proporciona detalles del error mediante [SWS_EM_02542] GetExecutionError() y el dominio de error del módulo [SWS_EM_02281] ExecErrc (AUTOSAR AP SWS ExecutionManagement p. 54).

más ›

Límites del sistema y rol funcional de Execution Management

El módulo exec (Execution Management, EM) constituye el servicio de plataforma central de la AUTOSAR Adaptive Platform para la gestión determinista de procesos y del ciclo de vida en el User Space basado en POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). El rasgo que define la arquitectura es la estricta separación entre la decisión de control (Policy) y la ejecución técnica (Mechanism): mientras el clúster funcional State Management adopta las decisiones sobre modos operativos de nivel superior y transiciones, Execution Management actúa como entidad ejecutora para la asignación de procesos, los órdenes de inicio, la supervisión y la terminación (AUTOSAR AP EXP SWArchitecture p. 56).

Execution Management implementa interfaces de tiempo de ejecución nativas de C++ para dos roles complementarios: a través de la clase [SWS_EM_02562] ara::exec::ExecutionClient, los procesos de aplicación y los demonios internos de la plataforma (como Diagnostic Management, Platform Health Management o Communication Management) notifican su estado de ejecución al demonio (AUTOSAR AP EXP SWArchitecture p. 48, AUTOSAR AP SWS CommunicationManagement p. 34). A través de la interfaz [SWS_EM_02276] ara::exec::StateClient, State Management interactúa con el demonio para solicitar transiciones de máquinas y de grupos de funciones, así como para consultar mensajes de estado (AUTOSAR AP SWS ExecutionManagement p. 17).

Diagrama de contexto: integración de Execution Management como demonio central entre State Management, el sistema operativo POSIX y los procesos cliente. Fuentes: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Arquitectura de estados y modelo de ciclo de vida multinivel

La gestión de estados en Execution Management opera en tres niveles jerárquicos correlacionados entre sí: los estados de grupos de funciones de nivel superior (Function Group States), los estados externos del ciclo de vida del sistema operativo desde la perspectiva del demonio (Process States), así como los estados internos del proceso (Execution States) (AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 62). En el nivel del demonio, un proceso configurado suele recorrer la cadena Idle, Starting, Running, Terminating y Terminated (AUTOSAR AP SWS StateManagement p. 32).

Para la perspectiva interna del proceso, el módulo define la enumeración [SWS_EM_02000] ara::exec::ExecutionState. En este caso, el estado kRunning se puede notificar normativamente a Execution Management a través de la función miembro [SWS_EM_02003] ReportExecutionState(). Las fases previas, como Initializing, son estados implícitos para Execution Management que comienzan inmediatamente con la primera planificación del proceso POSIX antes de la ejecución de código de usuario ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines p. 11). Los modos operativos y energéticos de la aplicación (PowerModes) no constituyen estados del sistema operativo, sino que están acoplados lógicamente a la fase activa del ciclo de vida Running (AUTOSAR AP SWS StateManagement p. 32).

Diagrama de estados: correlación de los estados de grupos de funciones con las fases del ciclo de vida en Execution Management y los estados internos del proceso. Fuentes: AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 32, [SWS_EM_02000].

Arranque determinista de la plataforma e inicialización

El arranque de la AUTOSAR Adaptive Platform se produce en una secuencia estrictamente coordinada a partir del kernel del sistema operativo (AUTOSAR EXP SWArchitecture p. 148). El sistema operativo inicia Execution Management a través de su punto de entrada de programa main() (AUTOSAR AP SWS ExecutionManagement p. 52). Inmediatamente después de la autoinicialización, Execution Management crea el proceso de State Management (AUTOSAR AP SWS StateManagement p. 25).

Tan pronto como State Management está inicializado, notifica su disponibilidad operativa a Execution Management con [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) mediante ExecutionClient (AUTOSAR AP SWS ExecutionManagement p. 52). A continuación, State Management se sincroniza mediante [SWS_EM_02279] GetInitialMachineStateTransitionResult() con la finalización de la transición inicial de la máquina al estado Startup; este método devuelve un ara::core::Future<void> ([SWS_EM_02279], AUTOSAR EXP SWArchitecture p. 151). Solo tras la resolución satisfactoria de este future, State Management solicita el cambio a los estados subsiguientes de Function Group (AUTOSAR AP SWS StateManagement p. 24).

Diagrama de secuencia: arranque de la plataforma desde la iniciación del sistema operativo, pasando por el inicio de State Management, hasta la liberación del estado subsiguiente. Fuentes: AUTOSAR AP SWS ExecutionManagement p. 52, AUTOSAR AP SWS StateManagement p. 25, [SWS_EM_02279], [SWS_EM_02003].

Control de grupos de funciones y transiciones de estado asíncronas

Los cambios de estado se modelan a nivel de aplicación mediante representantes de las clases [SWS_EM_02586] ara::exec::FunctionGroup y [SWS_EM_02324] ara::exec::FunctionGroupState. Para garantizar una gestión determinista de recursos, FunctionGroup no es copiable ([SWS_EM_02322], [SWS_EM_02327]), sino exclusivamente desplazable ([SWS_EM_02328], [SWS_EM_02329]) y evaluable mediante comparaciones de instancias ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState vincula un Function Group con un estado de destino ([SWS_EM_02324]) y admite tanto la semántica de copia como la de movimiento ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

State Management inicia una transición llamando a [SWS_EM_02278] StateClient::SetState(), lo que devuelve de forma síncrona un ara::core::Future<void> (AUTOSAR AP SWS StateManagement p. 31). Execution Management ejecuta a continuación la cadena de transición: los procesos en ejecución que ya no están configurados en el estado de destino reciben una señal SIGTERM (AUTOSAR AP SWS ExecutionManagement p. 53). Tras su terminación, EM inicia los procesos previstos para el estado de destino y espera su notificación de estado mediante [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement p. 26, AUTOSAR SWS ExecutionManagement p. 49). Solo cuando todos los procesos involucrados se han iniciado correctamente, el future de SetState() se resuelve positivamente (AUTOSAR AP SWS ExecutionManagement p. 53).

Las dependencias de inicio (Execution Dependencies) nunca deben definirse más allá de los límites de un único Function Group ni a través de diferentes estados (SWS ExecutionManagement p. 65). En caso de cambios de estado, Execution Management lleva a cabo la resolución de las dependencias de inicio estrictamente para los procesos del estado de destino solicitado (RequestedState) (SWS ExecutionManagement p. 71). Si las configuraciones de inicio de un proceso difieren entre el estado de origen y el de destino, Execution Management fuerza su reinicio (SWS ExecutionManagement p. 65).

Diagrama de secuencias: cambio de estado exitoso de una Function Group con finalización ordenada y reinicio de procesos. Fuentes: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Configuración de procesos, asignación de memoria y mapeo previo

En sistemas reales existen, además de las aplicaciones estándar, procesos sin notificación de estado integrada (Non-reporting Processes). Dichos procesos pasan automáticamente al estado de ejecución Running tras el inicio (SWS ExecutionManagement p. 44). Para proteger aun así las cadenas de dependencias, se puede anteponer un proceso complementario específico del proyecto (Companion Process) que evalúe la disponibilidad operativa funcional del Non-reporting Process y notifique [SWS_EM_02003] kRunning de forma representativa antes de que se inicien los procesos sucesores dependientes (SWS ExecutionManagement p. 44, SWS ExecutionManagement p. 48).

En cuanto a los requisitos de recursos, el parámetro resourceConsumption.memoryUsage limita la memoria principal asignable por el propio proceso, lo que en sistemas POSIX se implementa típicamente mediante RLIMIT_AS (SWS ExecutionManagement p. 82, SWS ExecutionManagement p. 104). Para garantizar el determinismo temporal y la seguridad funcional, Execution Management admite el mapeo previo (Pre-mapping): si Process.preMapping está activado en el manifiesto, EM mapea previamente el código y las áreas de datos del proceso por completo en la memoria física (SWS ExecutionManagement p. 82). Esto evita retrasos por carga bajo demanda (demand-loading) en el primer acceso, garantiza la disponibilidad constante de rutinas de tratamiento de errores críticas para la seguridad y protege contra fallos posteriores debidos a sistemas de archivos dañados (SWS ExecutionManagement p. 82).

Tiempo de ejecución determinista y modelos de sincronización

Para aplicaciones de tiempo real crítico, Execution Management proporciona mecanismos de ejecución determinista (SWS ExecutionManagement p. 79). Los procesos cíclicos interactúan con el cliente a través de una API de puntos de espera que controla modos tales como el descubrimiento de servicios, la inicialización, la ejecución y la terminación (SWS ExecutionManagement p. 79). El procesamiento paralelo de datos se abstrae mediante worker pools: para garantizar el determinismo de los datos, queda prohibido el intercambio de datos entre instancias concurrentes de WorkerRunnable (SWS ExecutionManagement p. 86).

Para sincronizar varios procesos redundantes o distribuidos se utiliza el DeterministicSyncMaster (SWS ExecutionManagement p. 92). Con activación guiada por eventos, una política configurable (como una decisión mayoritaria M de N) decide cuándo se envían las respuestas de sincronización (SWS ExecutionManagement p. 92). Con activación periódica, se realiza una sincronización única al principio, tras lo cual un búfer global de marcas de tiempo determina el ciclo de inicio y los ciclos subsiguientes se controlan de forma autónoma mediante contadores locales y supervisión de plazos (SWS ExecutionManagement p. 92). El sync master puede desplegarse como un proceso independiente o integrarse como biblioteca en el marco de un framework de software lockstep (SWS ExecutionManagement p. 94, SWS ExecutionManagement p. 95).

Comportamiento en caso de error

En caso de error, la arquitectura se estructura según el esquema general de tolerancia a fallos en detección de errores (Error Detection) y posterior recuperación de errores (Error Recovery) (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 107). Si se produce un tiempo de espera de inicio (start-up timeout) durante un cambio de estado de Function Group —por ejemplo, porque un proceso que se está iniciando no emite [SWS_EM_02003] ReportExecutionState(kRunning) dentro del plazo parametrizado—, Execution Management interrumpe la secuencia regular (AUTOSAR AP SWS ExecutionManagement p. 54).

Es de suponer que el escalado interno en este caso incluya la terminación forzada del proceso defectuoso mediante SIGKILL; tras agotar los reintentos de inicio configurados, el Function Group afectado pasa a un estado indeterminado (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02542]). Pregunta Q-5a8b6ad2e9e22eb4 (abierta) Al entrar en un estado indeterminado, Execution Management activa la devolución de llamada undefinedStateCallback pasada durante la instanciación de StateClient ([SWS_EM_02276], [SWS_EM_02561]). State Management puede entonces consultar mediante [SWS_EM_02542] GetExecutionError() el evento correspondiente ara::exec::ExecutionErrorEvent, el cual proporciona el Function Group defectuoso ([SWS_EM_02546]) y el código de error [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) ([SWS_EM_02542]). Si el Function Group vuelve a encontrarse en un estado definido, GetExecutionError() falla ([SWS_EM_02542]).

Diagrama de secuencia: tratamiento de errores ante un start-up timeout de un proceso durante una transición de estado. Fuentes: AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

Para un tratamiento uniforme de errores, el módulo dispone del dominio de errores [SWS_EM_02286] ara::exec::ExecErrorDomain (consultable a través de [SWS_EM_02290] GetExecErrorDomain(), nombre identificador a través de [SWS_EM_02287] Name(), mensajes de texto a través de [SWS_EM_02288] Message()). Los errores de ejecución específicos se representan mediante el código de enumeración [SWS_EM_02281] ExecErrc (como kNoCommunication) y se construyen mediante [SWS_EM_02291] MakeErrorCode(). Con el tratamiento de excepciones activado, los errores pueden lanzarse mediante [SWS_EM_02289] ThrowAsException() como [SWS_EM_02283] ExecException. Además, el destructor [SWS_EM_02002] ~ExecutionClient() garantiza que los manejadores previamente asumidos para SIGTERM se restablezcan a su valor original, mientras que las devoluciones de llamada de cancelación transferidas durante la creación del proceso surten efecto al recibir una señal de terminación ([SWS_EM_02560], [SWS_EM_02562]). Las acciones de recuperación adicionales (recovery actions, tales como el reinicio de procesos o la transición a funcionamiento de emergencia) se orquestan en cooperación con Platform Health Management (AUTOSAR SWS ExecutionManagement p. 54).

Más evidencia detallada

La siguiente vista general asigna los requisitos y referencias determinantes de la especificación a las áreas temáticas tratadas:

Área temática	Referencias principales	Significado funcional
Notificación de estado del proceso	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Define ExecutionState, creación de ExecutionClient y notificación de kRunning.
Control de grupos de funciones	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Transición de estado asíncrona mediante SetState(), instanciación de FunctionGroup y FunctionGroupState.
Arranque de la plataforma	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Sincronización de State Management con el estado inicial de la máquina Startup.
Tratamiento de errores & callbacks	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Registro de undefinedStateCallback, consulta de ExecutionErrorEvent, dominio de errores ExecErrc.
Determinismo de memoria	SWS ExecutionManagement S. 82	Pre-mapping completo de procesos para evitar latencias debidas a demand-loading.