módulo ara::phm — Platform Health Management

Como demonio central, Platform Health Management supervisa la seguridad funcional y la integridad en tiempo de ejecución de las aplicaciones y los servicios de la plataforma de conformidad con AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Las entidades supervisadas notifican sus puntos de control al sistema de forma cíclica o controlada por eventos, el cual evalúa plazos (deadlines), ciclos alive y flujos de control lógicos. En caso de detectar errores, el módulo notifica a State Management a través de [SWS_PHM_01142] para iniciar acciones de recuperación selectivas. Si no se produce una recuperación o fallan instancias centrales, un disparador del watchdog fuerza el estado seguro de la máquina.

más ›

Platform Health Management (PHM) constituye el servicio en segundo plano central de AUTOSAR Adaptive Platform para salvaguardar la seguridad funcional y la integridad del software conforme a ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Supervisa procesos tanto de aplicación como de plataforma mediante notificaciones deterministas de puntos de control y asegura el hardware mediante disparos cíclicos de watchdog AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Diagrama de contexto: Integración arquitectónica del demonio PHM en interacción con las aplicaciones supervisadas, State Management, Execution Management, el watchdog y el IdsM. Fuentes: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

La supervisión funcional se basa en la interfaz ara::phm::SupervisedEntity, a través de la cual los procesos notifican puntos de control mediante ReportCheckpoint() ([SWS_PHM_01123], [SWS_PHM_01127]). PHM divide la verificación en tres tipos de supervisión [SWS_PHM_01138]:

• Alive Supervision para el control cíclico de frecuencia AUTOSAR_FO_ASWS_HealthMonitoring p. 22,
• Deadline Supervision para la supervisión de plazos máximos de ejecución AUTOSAR_AP_SWS_PlatformHealthManagement p. 15,
• Logical Supervision para el cumplimiento de grafos de flujo de control definidos AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Estos resultados elementales se consolidan por cada Function Group en un estado agregado GlobalSupervisionStatus ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39).

Al detectarse vulneraciones, PHM delega la resolución de fallos en State Management a través de RecoveryHandler() de la interfaz RecoveryAction, después de que este haya notificado su disponibilidad de servicio mediante Offer() ([SWS_PHM_01142], [SWS_PHM_01143]). Si State Management no puede subsanar el fallo o fallan los propios demonios centrales, interviene la escalada de seguridad: PHM activa a través del WatchdogInterface nativo con FireWatchdogReaction() un reinicio inmediato del hardware ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagrama de secuencia: Escalada de fallos a State Management a través del RecoveryHandler con ramificación para el disparo del watchdog en caso de fallo. Fuentes: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

más ›

Límites del sistema e integración funcional de Health Management

Dentro de AUTOSAR Adaptive Platform, Platform Health Management (PHM) constituye la entidad funcional central para supervisar la integridad de ejecución, la disponibilidad del servicio y la seguridad funcional conforme a ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Como servicio en segundo plano independiente (basado en demonios), el módulo implementa la verificación determinista de flujos de control temporales y lógicos en procesos relevantes para la seguridad AUTOSAR_AP_EXP_SWArchitecture p. 128. Los límites del sistema comprenden tres ejes esenciales de interacción: la recepción de notificaciones de puntos de control de unidades de software supervisadas, la escalada de fallos a State Management y el disparo cíclico de notificaciones de señales de vida dirigidas a un watchdog cercano al hardware AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Las obligaciones de supervisión no se limitan exclusivamente a las aplicaciones de usuario convencionales (Adaptive Applications). Más bien, también servicios fundamentales de plataforma como Execution Management, State Management, Diagnostic Manager y la sincronización horaria están sujetos a la supervisión por parte de PHM, actuando ellos mismos como entidades supervisadas y transmitiendo puntos de control a Health Management AUTOSAR_AP_EXP_SWArchitecture p. 130. Para funciones auxiliares internas, el demonio PHM se apoya en interfaces de Execution Management (ExecutionClient para la notificación del estado del proceso) y del subsistema de registro (Logger de Log and Trace) AUTOSAR_AP_EXP_SWArchitecture p. 131.

Diagrama de contexto: Integración arquitectónica del demonio PHM en interacción con las aplicaciones supervisadas, State Management, Execution Management, el watchdog y el IdsM. Fuentes: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

Instrumentación y ciclo de vida de las entidades supervisadas

Una unidad de supervisión lógica dentro de un proceso se representa mediante la interfaz ara::phm::SupervisedEntity [SWS_PHM_01123]. La instanciación se lleva a cabo explícitamente indicando un identificador tipificado de tipo ara::core::InstanceSpecifier, el cual referencia la ruta de puerto configurada en el manifiesto del sistema AUTOSAR_TPS_ManifestSpecification p. 141. Para proteger la integridad de la instancia, el constructor de copia y el operador de asignación por copia están eliminados ([SWS_PHM_01212], [SWS_PHM_01213]); sin embargo, se permite mover las instancias ([SWS_PHM_01214], [SWS_PHM_01215]). Al destruirse, el destructor limpia la entidad [SWS_PHM_01211].

El software instrumentado notifica la llegada a puntos de programa definidos mediante la llamada síncrona ReportCheckpoint() [SWS_PHM_01127]. Como parámetro se utiliza una enumeración tipificada de puntos de control, generada a partir de la cabecera de la interfaz ([SWS_PHM_00424], [SWS_PHM_00425]). Con cada notificación, el demonio PHM verifica la autorización del proceso; si un proceso no modelado en el manifiesto invoca el método, se detecta una violación de acceso [SWS_PHM_01127]. En caso de anomalías críticas para la seguridad, PHM puede reenviar el fallo de acceso al Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture p. 236.

La supervisión de una entidad puede controlarse en tiempo de ejecución en función del estado: mediante Enable() se activa la supervisión, siempre que el estado actual del Function Group correspondiente lo permita [SWS_PHM_01130]. Mediante Disable() se puede suspender nuevamente la supervisión [SWS_PHM_01380]. Ambos métodos devuelven un ara::core::Future<void> y señalan errores asíncronos de provisión, por ejemplo PhmErrc::kServiceNotReady [SWS_PHM_01130].

Diagrama de secuencia: Proceso de notificación de puntos de control mediante SupervisedEntity con comprobación de permisos y supervisión de seguridad por parte del IdsM. Fuentes: [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture p. 236.

Tipos de supervisión y agregación de estado multietapa

Platform Health Management distingue tres tipos primarios de supervisión elemental ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture p. 128):

• Alive Supervision (kAliveSupervision): comprueba si las partes cíclicas del programa emiten una cantidad mínima y máxima configurada de notificaciones de puntos de control dentro de ventanas de tiempo definidas AUTOSAR_FO_ASWS_HealthMonitoring p. 22.
• Deadline Supervision (kDeadlineSupervision): supervisa el tiempo de ejecución entre dos puntos de control en cuanto al cumplimiento de plazos mínimos y máximos configurados AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.
• Logical Supervision (kLogicalSupervision): valida el orden de ejecución mediante un grafo de transiciones modelado para identificar saltos indebidos o ramificaciones del flujo de control AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Cada supervisión individual cuenta con una máquina de estados propia para su estado elemental (ElementarySupervisionStatus) [SWS_PHM_01358]. Al arrancar PHM, todas las máquinas de estados elementales se inicializan en el estado kDEACTIVATED y los contadores de fallos se ponen a cero SWS_PlatformHealthManagement p. 31. Tras la activación, la supervisión pasa a kOK mientras se cumplan todos los criterios de verificación. Si se produce una vulneración, el estado pasa a kFailed [SWS_PHM_01358].

Diagrama de estados: Transiciones de estado de la supervisión elemental (ElementarySupervisionStatus) desde kDEACTIVATED a través de kOK hasta kFailed. Fuentes: [SWS_PHM_01358], SWS_PlatformHealthManagement p. 31.

Varias supervisiones elementales se agrupan en una supervisión global superior SWS_PlatformHealthManagement p. 24. Conforme a la especificación, por cada Global Supervision configurada existe exactamente un GlobalSupervisionStatus, el cual está estrictamente vinculado a un único Function Group y no debe abarcar múltiples Function Groups ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39). El estado global agrega los resultados a través de los estados kDEACTIVATED, kOK, kFAILED, kEXPIRED y kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement p. 39. El estado kOK requiere como condición previa que al menos una supervisión asociada funcione correctamente y que ninguna de ellas permanezca en estado de fallo [SWS_PHM_01137].

Diagrama de estados: Modelo de estados del estado de supervisión global (GlobalSupervisionStatus) con kDEACTIVATED, kOK, kFAILED, kEXPIRED y kSTOPPED. Fuentes: [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement p. 39, SWS_PlatformHealthManagement p. 39.

Atención cíclica del watchdog y protección del hardware

Para proteger la operatividad de toda la unidad de computación frente a bloqueos o caídas fatales del sistema, PHM conecta el subsistema de watchdog cercano al hardware a través de la interfaz apext::phm::WatchdogInterface [SWS_PHM_01255]. Esta extensión nativa de la plataforma (Platform Extension) no se implementa mediante middleware de servicios, sino que se ejecuta como una llamada a controlador nativa y determinista AUTOSAR_AP_EXP_SWArchitecture p. 130.

En un ciclo configurable, PHM comprueba internamente todas las métricas de supervisión activas y, si el estado global es positivo, envía una notificación de señal de vida al watchdog a través de AliveNotification() ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233). Si esta notificación no se produce dentro de la ventana de tiempo configurada —por ejemplo, debido a que el demonio PHM está bloqueado o a que falla una supervisión crítica—, la interfaz de watchdog inicia de forma autónoma una reacción de seguridad de hardware [SWS_PHM_01255].

Diagrama de secuencia: Evaluación periódica de los resultados de supervisión y señalización Alive a la interfaz de watchdog. Fuentes: [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233, AUTOSAR_AP_EXP_SWArchitecture p. 130.

Coordinación de acciones de recuperación con State Management

Si PHM detecta una vulneración de las condiciones de supervisión, no inicia la subsanación de fallos de forma arbitraria, sino que delega la medida en State Management como instancia central de regulación (AUTOSAR_AP_EXP_SWArchitecture p. 129, AUTOSAR_AP_EXP_SWArchitecture p. 220). Este desacoplamiento preserva el principio arquitectónico de que las decisiones sobre estados funcionales del sistema y reinicios de procesos permanezcan en State Management AUTOSAR_AP_SWS_StateManagement p. 28.

State Management registra su disposición para asumir fallos mediante la interfaz de puerto ara::phm::RecoveryAction [SWS_PHM_01141]. Mediante la llamada a Offer(), se activa la recepción de notificaciones de fallo [SWS_PHM_01143]; con StopOffer(), State Management puede volver a desactivar la disponibilidad de servicio [SWS_PHM_01144]. Para descartar condiciones de carrera fatales y comportamientos no definidos debidos a llamadas anticipadas de retrollamada antes de la construcción completa de clases derivadas, las operaciones de copia y de movimiento están explícitamente prohibidas para RecoveryAction ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

En caso de fallo, PHM invoca la función de retrollamada puramente virtual RecoveryHandler() de State Management, pasando el evento de fallo ara::exec::ExecutionErrorEvent así como el tipo de supervisión vulnerada TypeOfSupervision [SWS_PHM_01142]. Seguidamente, State Management determina el estado resultante del Function Group y ordena a Execution Management el cambio de estado o el reinicio de los procesos afectados (AUTOSAR_AP_EXP_SWArchitecture p. 169, AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagrama de secuencia: Escalada de fallos a State Management a través del RecoveryHandler con ramificación para el disparo del watchdog en caso de fallo. Fuentes: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

Comportamiento en caso de fallo y vías de escalada multietapa

Platform Health Management implementa una estrategia de escalada escalonada para controlar los fallos en tiempo de ejecución AUTOSAR_AP_EXP_SWArchitecture p. 200. Si se produce un fallo de supervisión, se sigue inicialmente la vía primaria: la supervisión notifica el fallo a State Management, el cual ejecuta una reconfiguración controlada mediante RecoveryHandler() [SWS_PHM_01142].

Si State Management no puede ejecutar la recuperación (por ejemplo, acusando con el código de error PhmErrc::kSMCanNotHandleRecovery) o si la respuesta incurre en un timeout, interviene la vía de escalada secundaria ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture p. 220). En este caso, PHM elude el nivel de software y fuerza mediante FireWatchdogReaction() una reacción de emergencia inmediata cercana al hardware (reinicio del sistema o transición al Safe State) ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 201).

Especialmente crítico resulta el fallo de los propios demonios centrales de plataforma: si falla Execution Management o State Management, ya no es posible una recuperación coordinada a nivel de sistema operativo (AUTOSAR_AP_EXP_SWArchitecture p. 235, AUTOSAR_AP_EXP_SWArchitecture p. 235). PHM detecta este estado mediante puntos de control erróneos o ausentes de dichos demonios y activa sin demora la reacción de watchdog [SWS_PHM_01256].

Todas las situaciones de error en la API de C++ se tipifican a través del dominio de error ara::phm::PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]). Los códigos de error están agrupados en el enum PhmErrc ([SWS_PHM_01240], [SWS_PHM_01245]). Para interfaces síncronas y excepciones están disponibles funciones auxiliares como MakeErrorCode() [SWS_PHM_01244], así como el tipo de excepción PhmException ([SWS_PHM_01243], [SWS_PHM_01250]).

Modelado de manifiestos, sincronización de ID e instanciación

La vinculación correcta entre el código de aplicación y el demonio PHM se fundamenta en una estricta sincronización de ID en el manifiesto AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 566. En el diseño de la aplicación, la entidad se modela como PhmSupervisedEntityInterface con elementos PhmCheckpoint agregados AUTOSAR_AP_TPS_ManifestSpecification p. 208. Para el despliegue a nivel de máquina, se genera por cada instancia de proceso un SupervisionCheckpoint que resuelve la referencia de instancia al puerto y al contexto de ejecución (Process) TPS_ManifestSpecification p. 568.

Si el mismo tipo de componente de software se instancia varias veces —ya sea dentro del mismo proceso o a lo largo de varios procesos—, la configuración del manifiesto genera para cada puerto un InstanceSpecifier unívoco AUTOSAR_AP_SWS_PlatformHealthManagement p. 51. Gracias a ello, el demonio PHM puede asignar de forma unívoca IDs de puntos de control idénticos procedentes del código fuente a la respectiva instancia de componente e identidad de proceso AUTOSAR_AP_TPS_ManifestSpecification p. 566. Interpretación: Es de presumir que la comunicación interprocesos entre el espacio de usuario de la aplicación y el demonio PHM esté optimizada de forma específica para el sistema operativo (por ejemplo, mediante memoria compartida o sockets de dominio POSIX), ya que la clase de C++ SupervisedEntity encapsula de manera transparente los detalles de transporte [SWS_PHM_01123]. Pregunta (abierta)

En lo que respecta al tratamiento de fallos, el manifiesto modela elementos RecoveryNotification asignados a un PPortPrototype de State Management AUTOSAR_AP_TPS_ManifestSpecification p. 587. En este contexto también se define un valor de timeout (recoveryNotificationTimeout), tras cuyo vencimiento el tratamiento de fallos se clasifica como fallido AUTOSAR_AP_TPS_ManifestSpecification p. 587.

Más evidencia detallada

La plasmación normativa vinculante de Platform Health Management en la versión R25-11 se fundamenta en particular en los siguientes anclajes de especificación:

• Elementos nucleares de la supervisión: [SWS_PHM_01123] y [SWS_PHM_01127] definen la clase de C++ SupervisedEntity y el mecanismo de notificación ReportCheckpoint(); [SWS_PHM_01130] así como [SWS_PHM_01380] regulan la activación y la desactivación.
• Modelos de estados: [SWS_PHM_01358] especifica los estados elementales (kDEACTIVATED, kOK, kFailed); [SWS_PHM_01137] asienta la agregación global de estado por cada Function Group SWS_PlatformHealthManagement p. 39.
• Recuperación y escalada: [SWS_PHM_01141], [SWS_PHM_01142] y [SWS_PHM_01143] controlan la provisión y ejecución del RecoveryHandler() en State Management; [SWS_PHM_01256] salvaguarda la escalada de emergencia a través del watchdog de hardware.
• Dominio de error y excepciones: [SWS_PHM_01240] introduce los códigos de error (PhmErrc), los cuales se transportan mediante PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) y PhmException [SWS_PHM_01243].