módulo ara::phm — Platform Health Management

Como daemon central, o Platform Health Management monitoriza a segurança funcional e a integridade em tempo de execução de aplicações e serviços de plataforma em conformidade com AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. As entidades monitorizadas reportam os seus pontos de controlo ao sistema de forma cíclica ou orientada a eventos, o qual avalia deadlines, ciclos de vida (alive) e fluxos de controlo lógicos. Em caso de erros detetados, o módulo notifica o State Management para iniciar ações de recuperação direcionadas através de [SWS_PHM_01142]. Se a recuperação falhar ou se instâncias centrais falharem, um acionamento por watchdog força o estado seguro da máquina.

mais ›

O Platform Health Management (PHM) constitui o serviço de fundo central da AUTOSAR Adaptive Platform para assegurar a segurança funcional e a integridade de software segundo a ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Monitoriza tanto processos de aplicação como de plataforma através de mensagens determinísticas de pontos de controlo e protege o hardware através de disparos cíclicos de watchdog AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Diagrama de contexto: integração arquitetural do daemon PHM em interação com aplicações monitorizadas, State Management, Execution Management, watchdog e IdsM. Fontes: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

A monitorização funcional baseia-se na interface ara::phm::SupervisedEntity, através da qual os processos reportam pontos de controlo via ReportCheckpoint() ([SWS_PHM_01123], [SWS_PHM_01127]). O PHM divide a verificação em três tipos de monitorização [SWS_PHM_01138]:

• Alive Supervision para controlo cíclico de frequência AUTOSAR_FO_ASWS_HealthMonitoring p. 22,
• Deadline Supervision para monitorização de prazos máximos de execução AUTOSAR_AP_SWS_PlatformHealthManagement p. 15,
• Logical Supervision para cumprimento de grafos de fluxo de controlo definidos AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Estes resultados elementares são condensados por Function Group num estado agregado GlobalSupervisionStatus ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39).

Em caso de violações detetadas, o PHM delega a correção do erro no State Management através do RecoveryHandler() da interface RecoveryAction, após este ter reportado a sua prontidão operacional via Offer() ([SWS_PHM_01142], [SWS_PHM_01143]). Se o State Management não conseguir sanar o erro ou se os próprios daemons centrais falharem, a escalada de segurança intervém: o PHM aciona um reset de hardware imediato através do WatchdogInterface nativo com FireWatchdogReaction() ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagrama de sequência: escalada de erros para o State Management através do RecoveryHandler com ramificação para acionamento de watchdog em caso de falha. Fontes: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

mais ›

Fronteiras do sistema e integração funcional do Health Management

Dentro da AUTOSAR Adaptive Platform, o Platform Health Management (PHM) constitui a instância funcional central para a monitorização da integridade de execução, disponibilidade de serviços e segurança funcional de acordo com a ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Como serviço de fundo autónomo (baseado em daemon), o módulo implementa a verificação determinística de fluxos de controlo temporais e lógicos em processos relevantes para a segurança AUTOSAR_AP_EXP_SWArchitecture p. 128. As fronteiras do sistema abrangem três eixos de interação essenciais: a receção de mensagens de pontos de controlo de unidades de software monitorizadas, a escalada de erros para o State Management, bem como o acionamento cíclico de mensagens de sinais de vida para um watchdog próximo do hardware AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

As obrigações de monitorização não se limitam exclusivamente a aplicações de utilizador regulares (Adaptive Applications). Pelo contrário, serviços de plataforma fundamentais como o Execution Management, o State Management, o Diagnostic Manager e a sincronização temporal também estão sujeitos à monitorização pelo PHM, atuando eles próprios como entidades monitorizadas e transmitindo checkpoints ao Health Management AUTOSAR_AP_EXP_SWArchitecture p. 130. Para funções auxiliares internas, o daemon PHM baseia-se em interfaces do Execution Management (ExecutionClient para reporte de estado de processos) e do subsistema de logging (Logger de Log and Trace) AUTOSAR_AP_EXP_SWArchitecture p. 131.

Diagrama de contexto: integração arquitetural do daemon PHM em interação com aplicações monitorizadas, State Management, Execution Management, watchdog e IdsM. Fontes: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

Instrumentação e ciclo de vida de entidades monitorizadas

Uma unidade lógica de monitorização dentro de um processo é representada pela interface ara::phm::SupervisedEntity [SWS_PHM_01123]. A instanciação ocorre explicitamente mediante a especificação de um identificador tipificado do tipo ara::core::InstanceSpecifier, o qual referencia o caminho de porta configurado no manifesto de sistema AUTOSAR_TPS_ManifestSpecification p. 141. Para proteger a integridade da instância, o construtor de cópia e o operador de atribuição por cópia estão eliminados ([SWS_PHM_01212], [SWS_PHM_01213]); contudo, as instâncias podem ser movidas ([SWS_PHM_01214], [SWS_PHM_01215]). Na destruição, o destrutor liberta a entidade [SWS_PHM_01211].

O software instrumentado reporta que determinados pontos do programa foram alcançados através da chamada síncrona ReportCheckpoint() [SWS_PHM_01127]. Como parâmetro, é utilizada uma enumeração de checkpoints tipificada, gerada a partir do cabeçalho da interface ([SWS_PHM_00424], [SWS_PHM_00425]). O daemon PHM verifica a autorização do processo em cada mensagem; se um processo não modelado no manifesto chamar o método, é detetada uma violação de acesso [SWS_PHM_01127]. Em caso de anomalias críticas para a segurança, o PHM pode reencaminhar o erro de acesso para o Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture p. 236.

A monitorização de uma entidade pode ser controlada em tempo de execução em função do estado: através de Enable(), a monitorização é ativada, desde que o estado atual do Function Group associado o permita [SWS_PHM_01130]. Com Disable(), a monitorização pode ser suspensa novamente [SWS_PHM_01380]. Ambos os métodos retornam um ara::core::Future<void> e sinalizam erros assíncronos de disponibilização, por exemplo PhmErrc::kServiceNotReady [SWS_PHM_01130].

Diagrama de sequência: sequência de reporte de ponto de controlo através de SupervisedEntity com verificação de permissões e monitorização de segurança pelo IdsM. Fontes: [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture p. 236.

Tipos de monitorização e agregação de estado multinível

O Platform Health Management distingue três tipos primários de monitorização elementar ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture p. 128):

• Alive Supervision (kAliveSupervision): verifica se partes cíclicas do programa emitem um número mínimo e máximo configurado de mensagens de checkpoint dentro de janelas de tempo definidas AUTOSAR_FO_ASWS_HealthMonitoring p. 22.
• Deadline Supervision (kDeadlineSupervision): monitoriza o tempo de execução entre dois pontos de controlo quanto ao cumprimento de prazos mínimos e máximos configurados AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.
• Logical Supervision (kLogicalSupervision): valida a ordem de execução com base num grafo de transição modelado, a fim de identificar saltos inadvertidos ou ramificações de fluxo de controlo não permitidas AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Cada monitorização individual possui a sua própria máquina de estados para o seu estado elementar (ElementarySupervisionStatus) [SWS_PHM_01358]. No arranque do PHM, todas as máquinas de estados elementares são inicializadas no estado kDEACTIVATED e os contadores de erros são repostos a zero SWS_PlatformHealthManagement p. 31. Após a ativação, a monitorização transita para kOK enquanto todos os critérios de verificação forem cumpridos. Caso ocorra uma violação, o estado muda para kFailed [SWS_PHM_01358].

Diagrama de estados: transições de estado da monitorização elementar (ElementarySupervisionStatus) de kDEACTIVATED, passando por kOK, até kFailed. Fontes: [SWS_PHM_01358], SWS_PlatformHealthManagement p. 31.

Várias monitorizações elementares são agrupadas numa monitorização global de nível superior SWS_PlatformHealthManagement p. 24. De acordo com a especificação, existe exatamente um GlobalSupervisionStatus por Global Supervision configurada, o qual está estritamente vinculado a um único Function Group e não pode abranger múltiplos Function Groups ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39). O estado global agrega os resultados através dos estados kDEACTIVATED, kOK, kFAILED, kEXPIRED e kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement p. 39. O estado kOK pressupõe que pelo menos uma monitorização associada opere sem falhas e que nenhuma permaneça em estado de erro [SWS_PHM_01137].

Diagrama de estados: modelo de estados do estado de monitorização global (GlobalSupervisionStatus) com kDEACTIVATED, kOK, kFAILED, kEXPIRED e kSTOPPED. Fontes: [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement p. 39, SWS_PlatformHealthManagement p. 39.

Operação cíclica de watchdog e proteção de hardware

Para proteger a capacidade de execução de toda a unidade computacional contra bloqueios ou falhas fatais do sistema, o PHM liga o subsistema de watchdog próximo do hardware através da interface apext::phm::WatchdogInterface [SWS_PHM_01255]. Esta extensão de plataforma nativa (Platform Extension) não é realizada através de middleware de serviços, mas executada como chamada de driver nativa e determinística AUTOSAR_AP_EXP_SWArchitecture p. 130.

Num ciclo configurável, o PHM verifica internamente todas as métricas de monitorização ativas e, em caso de estado geral positivo, emite uma mensagem de sinal de vida para o watchdog através de AliveNotification() ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233). Se esta mensagem não ocorrer dentro da janela temporal configurada — por exemplo, porque o daemon PHM está bloqueado ou uma monitorização crítica falha —, a interface de watchdog inicia autonomamente uma reação de segurança de hardware [SWS_PHM_01255].

Diagrama de sequência: avaliação periódica dos resultados de monitorização e sinalização de Alive para a interface de watchdog. Fontes: [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233, AUTOSAR_AP_EXP_SWArchitecture p. 130.

Coordenação de ações de recuperação com o State Management

Se o PHM detetar uma violação das condições de monitorização, não inicia a correção do erro arbitrariamente, mas delega a medida no State Management como instância reguladora central (AUTOSAR_AP_EXP_SWArchitecture p. 129, AUTOSAR_AP_EXP_SWArchitecture p. 220). Este desacoplamento preserva o princípio arquitetural de que as decisões sobre estados funcionais do sistema e reinicializações de processos permanecem no State Management AUTOSAR_AP_SWS_StateManagement p. 28.

O State Management regista a sua prontidão para assumir erros através da interface de porta ara::phm::RecoveryAction [SWS_PHM_01141]. Ao chamar Offer(), a receção de mensagens de erro é ativada [SWS_PHM_01143]; com StopOffer(), o State Management pode desativar novamente a prontidão de serviço [SWS_PHM_01144]. Para excluir condições de corrida fatais e comportamento indefinido devido a invocações prematuras de callbacks antes da construção completa de classes derivadas, as operações de cópia e movimentação para RecoveryAction estão explicitamente proibidas ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

Em caso de erro, o PHM chama a função de callback puramente virtual RecoveryHandler() do State Management, passando o evento de erro ara::exec::ExecutionErrorEvent, bem como o tipo de monitorização violada TypeOfSupervision [SWS_PHM_01142]. O State Management determina então o estado subsequente do Function Group e instrui o Execution Management a alterar o estado ou a reiniciar os processos afetados (AUTOSAR_AP_EXP_SWArchitecture p. 169, AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagrama de sequência: escalada de erros para o State Management através do RecoveryHandler com ramificação para acionamento de watchdog em caso de falha. Fontes: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

Comportamento em caso de erro e caminhos de escalada multinível

O Platform Health Management implementa uma estratégia de escalada graduada para o controlo de erros em tempo de execução AUTOSAR_AP_EXP_SWArchitecture p. 200. Se ocorrer um erro de monitorização, segue-se inicialmente o caminho primário: a monitorização reporta o erro ao State Management, o qual realiza uma reconfiguração controlada através de RecoveryHandler() [SWS_PHM_01142].

Se o State Management não conseguir executar a recuperação (por exemplo, confirmada com o código de erro PhmErrc::kSMCanNotHandleRecovery) ou se a resposta entrar em timeout, intervém o caminho de escalada secundário ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture p. 220). Neste caso, o PHM contorna o nível de software e força uma reação de emergência imediata próxima do hardware através de FireWatchdogReaction() (reset do sistema ou transição para o Safe State) ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 201).

Particularmente crítica é a falha dos próprios daemons centrais da plataforma: se o Execution Management ou o State Management falharem, já não é possível uma recuperação coordenada ao nível do sistema operativo (AUTOSAR_AP_EXP_SWArchitecture p. 235, AUTOSAR_AP_EXP_SWArchitecture p. 235). O PHM deteta este estado através de checkpoints incorretos ou em falta destes daemons e dispara sem atraso a reação de watchdog [SWS_PHM_01256].

Todas as situações de erro na API C++ são tipificadas através do domínio de erro ara::phm::PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]). Os códigos de erro estão agrupados no enum PhmErrc ([SWS_PHM_01240], [SWS_PHM_01245]). Para interfaces síncronas e exceções, estão disponíveis funções auxiliares como MakeErrorCode() [SWS_PHM_01244], bem como o tipo de exceção PhmException ([SWS_PHM_01243], [SWS_PHM_01250]).

Modelação em manifesto, sincronização de ID e instanciação

A associação correta entre o código de aplicação e o daemon PHM baseia-se numa sincronização rigorosa de ID no manifesto AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 566. No desenho da aplicação, a entidade é modelada como PhmSupervisedEntityInterface com elementos PhmCheckpoint agregados AUTOSAR_AP_TPS_ManifestSpecification p. 208. Para o deployment ao nível da máquina, é gerado um SupervisionCheckpoint por instância de processo, o qual resolve a referência de instância para a porta e o contexto de execução (Process) TPS_ManifestSpecification p. 568.

Se o mesmo tipo de componente de software for instanciado múltiplas vezes — seja dentro do mesmo processo ou ao longo de vários processos —, a configuração do manifesto gera um InstanceSpecifier único para cada porta AUTOSAR_AP_SWS_PlatformHealthManagement p. 51. Desta forma, o daemon PHM pode associar de forma unívoca IDs de pontos de controlo idênticos do código-fonte à respetiva instância de componente e identidade de processo AUTOSAR_AP_TPS_ManifestSpecification p. 566. Interpretação: a comunicação interprocessos entre o user space da aplicação e o daemon PHM deverá ser otimizada especificamente para o sistema operativo (por exemplo, via memória partilhada ou sockets de domínio POSIX), uma vez que a classe C++ SupervisedEntity encapsula transparentemente os detalhes de transporte [SWS_PHM_01123]. Pergunta (aberta)

No lado do tratamento de erros, o manifesto modela elementos RecoveryNotification que estão atribuídos a um PPortPrototype do State Management AUTOSAR_AP_TPS_ManifestSpecification p. 587. Aqui é também definido um valor de timeout (recoveryNotificationTimeout), após cujo decurso o tratamento do erro é classificado como falhado AUTOSAR_AP_TPS_ManifestSpecification p. 587.

Evidências mais detalhadas

A definição normativa vinculativa do Platform Health Management na Release R25-11 baseia-se em particular nas seguintes âncoras de especificação:

• Elementos centrais da monitorização: [SWS_PHM_01123] e [SWS_PHM_01127] definem a classe C++ SupervisedEntity e o mecanismo de reporte ReportCheckpoint(); [SWS_PHM_01130], bem como [SWS_PHM_01380], regulam a ativação e desativação.
• Modelos de estados: [SWS_PHM_01358] especifica os estados elementares (kDEACTIVATED, kOK, kFailed); [SWS_PHM_01137] ancora a agregação de estado global por Function Group SWS_PlatformHealthManagement p. 39.
• Recuperação e escalonamento: [SWS_PHM_01141], [SWS_PHM_01142] e [SWS_PHM_01143] controlam a disponibilização e a execução do RecoveryHandler() no State Management; [SWS_PHM_01256] assegura o escalonamento de emergência via watchdog de hardware.
• Domínio de erros e exceções: [SWS_PHM_01240] introduz os códigos de erro (PhmErrc), que são transportados via PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) e PhmException [SWS_PHM_01243].