módulo ara::sm — State Management

El cluster adaptativo State Management controla los modos de funcionamiento de todo el sistema, los estados de grupos de funciones y las fases de actualización de software de una Adaptive Machine en coordinación con Execution Management y UCM EXP SWArchitecture p. 51. Procesa disparadores de transición de forma determinista mediante tablas y listas de acciones configuradas, notifica estados intermedios a través de StateMachineNotification y orquesta Suspend-to-RAM mediante un patrón hub-satellite [SWS_SM_91107], [SWS_SM_81110]. Condiciones límite como la verificación estricta de autorizaciones de actualización y rutas de contingencia de fallos ANY obligatorias aseguran un funcionamiento robusto de la plataforma [SWS_SM_91108].

más ›

El cluster funcional State Management (SM) actúa en la AUTOSAR Adaptive Platform como demonio de plataforma central para el control de estados de máquina y de grupos de funciones, así como de modos de ejecución EXP SWArchitecture p. 51. Separa estrictamente la lógica de decisión específica del vehículo en aplicaciones de control (SMControlApplication) de la gestión real de procesos mediante Execution Management (EM) EXP PlatformDesign p. 40. Junto a implementaciones propietarias de los fabricantes, AUTOSAR proporciona un enfoque StateMachine estandarizado en el que las transiciones se procesan mediante metamodelos tabulares y listas de acciones configuradas SWS StateManagement p. 42.

Las transiciones de estado se inician mediante el método RequestTransition de StateMachineService [SWS_SM_91107] y se validan frente a TransitionRequestTable SWS StateManagement p. 44. Durante el procesamiento de la ActionList correspondiente, el campo de notificación CurrentState señaliza el valor de transición "inTransition" a las aplicaciones consumidoras antes de que se publique el estado de destino tras la confirmación completa [SWS_SM_91109], SWS StateManagement p. 67.

Diagrama de secuencias: Secuencia de una transición de estado regular a través de StateMachineService y notificación mediante StateMachineNotification. Fuentes: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51

Para llevar a cabo actualizaciones de software, State Management proporciona la interfaz UpdateRequest para Update and Configuration Management (UCM) [SWS_SM_91102], EXP SWArchitecture p. 56. Tras verificar el campo aplicativo UpdateAllowed, el módulo coordina pasos de preparación (PrepareUpdate), verificación (VerifyUpdate) o rollback (PrepareRollback), así como reinicios de la máquina mediante ResetMachine [SWS_SM_91100], [SWS_SM_91103], [SWS_SM_91108]. Para modos de ahorro de energía como Suspend-to-RAM, S2RHub y S2RSatellite sincronizan la congelación y reanudación de aplicaciones y del sistema operativo [SWS_SM_81010], [SWS_SM_81110], [SWS_SM_71001].

En caso de error, SmErrorDomain [SWS_SM_81247] y una entrada de captura obligatoria ANY en ErrorRecoveryTable garantizan que los errores de ejecución imprevistos procedentes de Execution Management o Platform Health Management se capturen de forma determinista y que las acciones en curso pasen inmediatamente a estados de recuperación definidos SWS StateManagement p. 42.

más ›

Rol y límites funcionales del sistema en el entorno de la plataforma

El cluster funcional State Management (SM) constituye en la AUTOSAR Adaptive Platform la entidad central para la orquestación de los modos de funcionamiento de todo el sistema, grupos de funciones y ciclos de vida de procesos EXP SWArchitecture p. 51. Ejecutado como un demonio de plataforma autónomo, State Management desacopla la ejecución de estados interna de la plataforma de la lógica de control específica del vehículo y del fabricante, encapsulada habitualmente en una aplicación de control independiente (SMControlApplication) EXP PlatformDesign p. 40. Mientras que State Management toma y valida las decisiones lógicas de estado, delega el inicio, la terminación y la conmutación físicos de procesos a través de StateClient a Execution Management (EM) SWS StateManagement p. 40.

Desde el punto de vista arquitectónico, el módulo se basa en una filosofía de integración dual: los integradores pueden optar por emplear el enfoque StateMachine estandarizado basado en manifiestos de la pila de la plataforma o bien implementar una lógica de estados totalmente propietaria del fabricante, dado que las interfaces con State Management se mantienen públicas SWS StateManagement p. 42. En el enfoque estandarizado, State Management reacciona de forma determinista a disparadores externos procedentes de aplicaciones de control, mensajes de error de Platform Health Management (PHM) y cambios de estado de red de Network Management (NM) SWS StateManagement p. 45. Además, State Management constituye la instancia de control determinante para las actualizaciones de software realizadas por Update and Configuration Management (UCM) EXP SWArchitecture p. 56.

Diagrama de contexto: Integración del Functional Cluster State Management en el conjunto del sistema AUTOSAR Adaptive. Fuentes: EXP PlatformDesign p. 40, SWS StateManagement p. 28

Transiciones de estado y control a través de la interfaz StateMachineService

Para iniciar cambios de estado, State Management proporciona el servicio orientado a servicios StateMachineService para cada instancia configurada de una StateMachine SWS StateManagement p. 44. La aplicación solicita una transición a través del método de servicio RequestTransition [SWS_SM_91107]. State Management comprueba esta petición frente al estado actual de la máquina de estados basándose en una TransitionRequestTable definida de forma estática en el manifiesto SWS StateManagement p. 44. Si la transición está definida, se detiene la ejecución de la lista de acciones actual (ActionList) y se inicia el cambio al estado de destino SWS StateManagement p. 45.

Tan pronto como se inicia una transición de estado, State Management establece el valor del campo de servicio CurrentState de la interfaz StateMachineNotification en "inTransition" [SWS_SM_91109], SWS StateManagement p. 67. Este estado de transición señaliza a las Adaptive Applications dependientes a través de ara::com que hay una reconfiguración del sistema en curso EXP SWArchitecture p. 52. Dentro de las listas de acciones, los grupos de funciones pueden sincronizarse o conectarse en paralelo mediante elementos SYNC para reflejar dependencias con exactitud SWS StateManagement p. 56. Solo después de que todas las ActionListItems se hayan procesado por completo y se hayan recopilado los resultados, CurrentState adopta el nombre definitivo del nuevo estado SWS StateManagement p. 67.

Diagrama de secuencias: Secuencia de una transición de estado regular a través de StateMachineService y notificación mediante StateMachineNotification. Fuentes: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51, EXP SWArchitecture p. 219

Diagrama de estados: Ciclo de vida típico y lógica de transición de una StateMachine basada en la TransitionRequestTable. Fuentes: EXP InterfacesGuidelines p. 22, SWS StateManagement p. 44

Orquestación de actualizaciones de software en interacción con UCM

En el marco de las actualizaciones de software, State Management asume la función de interfaz entre Update and Configuration Management (UCM) y los estados de ejecución de la máquina EXP SWArchitecture p. 142. Para ello, State Management proporciona la interfaz UpdateRequest, que puede instanciarse como máximo una vez por máquina y está vinculada exclusivamente al proceso que gestiona la máquina de estados del controlador SWS StateManagement p. 79. Una actualización se inicia cuando UCM llama al método RequestUpdateSession [SWS_SM_91102]. State Management no toma la decisión sobre la admisibilidad de forma autónoma, sino que consulta el campo de servicio UpdateAllowed de UpdateAllowedService, que es establecido por la lógica de control aplicativa [SWS_SM_91108], SWS StateManagement p. 81.

Si la sesión se autoriza, el controlador marca las máquinas de estados afectadas como ImpactedByUpdate SWS StateManagement p. 81. Antes de la instalación propiamente dicha, UCM llama a PrepareUpdate con la lista de los grupos de funciones afectados, tras lo cual estos pasan a estados inactivos [SWS_SM_91103], PlatformDesign p. 58. En caso de que la actualización requiera un reinicio, UCM solicita un restablecimiento ordenado a través del método fire-and-forget ResetMachine, en el cual deben guardarse previamente todos los datos [SWS_SM_91100]. State Management informa a UCM sobre cambios de estado durante el restablecimiento a través del campo ResetMachineNotifier [SWS_SM_91106], SWS StateManagement p. 92. Tras el reinicio o la actualización, se realiza la verificación mediante VerifyUpdate [SWS_SM_91104], SWS StateManagement p. 87. Si la comprobación falla, PrepareRollback prepara el rollback [SWS_SM_91105], SWS StateManagement p. 88. La finalización de todo el ciclo se confirma con StopUpdateSession [SWS_SM_91101], SWS StateManagement p. 79.

Diagrama de secuencias: Secuencia de interacción de una sesión de actualización de software entre UCM, State Management y la lógica de control. Fuentes: [SWS_SM_91100], [SWS_SM_91102], [SWS_SM_91103], [SWS_SM_91104], SWS StateManagement p. 78

Gestión de energía y Suspend-to-RAM en el conjunto hub-satellite

Para funciones avanzadas de gestión de energía como Suspend-to-RAM (S2R), State Management implementa un patrón de arquitectura hub-satellite EXP SWArchitecture p. 54. La instancia de control central en el demonio de la plataforma utiliza la clase S2RHub [SWS_SM_81103], mientras que las Adaptive Applications participantes integran instancias de S2RSatellite en su propio espacio de procesos [SWS_SM_81003], [SWS_SM_81014], SWS StateManagement p. 35. Los satélites activan su disponibilidad para recibir cambios de modo mediante Offer [SWS_SM_81012] o la desactivan a través de StopOffer [SWS_SM_81013]. Implementan los métodos puramente virtuales EnterSuspendMode [SWS_SM_81010] y LeaveSuspendMode [SWS_SM_81011] como mecanismo de callback para la preparación y el posprocesamiento del estado de reposo.

Si se inicia un proceso de suspensión, el S2RHub se dirige a todos los satélites registrados de forma asíncrona a través de RequestToEnterSuspendMode con un timeout configurable [SWS_SM_81110]. Una vez que todos los satélites han concluido con éxito sus preparativos para el estado de reposo, el hub ordena a través de EnterSuspendToRamOs la entrada del sistema operativo en el estado de conservación de RAM [SWS_SM_81112], SWS StateManagement p. 101. En el nivel de wrapper de OS cercano al hardware, State Management recurre a apext::sm::PowerStateInterface: esta permite establecer estados operativos cercanos al hardware mediante SetPowerState [SWS_SM_71001] basándose en la enumeración PowerState [SWS_SM_71002], así como registrar y cancelar el registro de gestores autónomos de reactivación mediante RegisterWakeUpHandler [SWS_SM_71003] y UnregisterWakeUpHandler [SWS_SM_71005] con el tipo de función WakeUpHandler [SWS_SM_71004], SWS StateManagement p. 105. Tras el despertar, el hub solicita a través de RequestToLeaveSuspendMode la reanudación coordinada de todos los satélites [SWS_SM_81111].

Diagrama de secuencias: Secuencia bifásica al poner el sistema en Suspend-to-RAM y posterior reactivación. Fuentes: [SWS_SM_71001], [SWS_SM_81110], [SWS_SM_81112], SWS StateManagement p. 101

Comportamiento en caso de error

Para los errores operativos propios, el módulo define la SmErrorDomain [SWS_SM_81247], que se consulta a través de GetSmDomain [SWS_SM_81251] y lleva el identificador "Sm" [SWS_SM_81248]. Proporciona descripciones de error [SWS_SM_81249] y, en casos excepcionales, convierte códigos en una ThrowAsException a través de SmException [SWS_SM_81243], [SWS_SM_81250]. Mediante la enumeración SmErrc se tipifican causas de fallo específicas, entre ellas kOfferFailed para pérdidas de conexión con el demonio de la plataforma y kCommunicationFailed para comunicaciones fallidas con satélites [SWS_SM_81240], generables mediante MakeErrorCode [SWS_SM_81244].

En el ámbito de las máquinas de estados lógicas, State Management impone un tratamiento de errores exhaustivo a través de la ErrorRecoveryTable SWS StateManagement p. 69. Cada tabla debe incluir obligatoriamente exactamente una entrada con el valor ANY, que actúa como ruta de contingencia determinista para todos los errores de ejecución que no estén mapeados explícitamente SWS StateManagement p. 42, SWS StateManagement p. 69. Si Platform Health Management o Execution Management notifican un error y la máquina de estados afectada no está marcada como ImpactedByUpdate, esta establece un flag interno de recuperación de errores en curso, cancela inmediatamente la lista de acciones actual y conmuta de inmediato al estado de recuperación parametrizado SWS StateManagement p. 42. En caso de errores críticos de Execution Management como kIntegrityOrAuthenticityCheckFailed, State Management asume que la confiabilidad de la plataforma está comprometida y que las peticiones posteriores fallarán, por lo que las medidas correctoras quedan fuera del cluster SWS StateManagement p. 40.

Diagrama de actividades: Secuencia de decisión y procesamiento ante errores de ejecución entrantes y evaluación de la ErrorRecoveryTable. Fuentes: SWS StateManagement p. 42, SWS StateManagement p. 69

Más evidencia detallada

La arquitectura y las rutas de interacción de State Management están respaldadas por los siguientes requisitos normativos y definiciones de diseño:

• Control del sistema y transiciones: [SWS_SM_91107] define la solicitud de transición orientada a servicios, mientras que [SWS_SM_91109] regula el campo de notificación para el desacoplamiento de aplicaciones. El control basado en tablas está respaldado por SWS StateManagement p. 44.
• Integración de la actualización de software: Los métodos para la gestión de sesiones [SWS_SM_91102], preparación [SWS_SM_91103], verificación [SWS_SM_91104], preparación de rollback [SWS_SM_91105] y finalización [SWS_SM_91101], así como los reinicios de máquina [SWS_SM_91100] y los campos de habilitación [SWS_SM_91106], [SWS_SM_91108] fijan la interacción con UCM según EXP SWArchitecture p. 56.
• Suspend-to-RAM y gestión de energía: La jerarquía nativa de clases e interfaces en torno a S2RHub [SWS_SM_81103], [SWS_SM_81110], S2RSatellite [SWS_SM_81003], [SWS_SM_81010] y la interfaz del sistema operativo [SWS_SM_71001], [SWS_SM_71003] constituyen el fundamento normativo del ahorro de energía EXP SWArchitecture p. 54.
• Espacio de errores: El diseño del dominio de errores estandarizado con generadores de excepciones y de ErrorCode se basa en [SWS_SM_81240], [SWS_SM_81244] y [SWS_SM_81247].