namespace ara::phm

O namespace ara::phm disponibiliza mecanismos para a monitorização em tempo de execução de entidades de software relativamente a sinais de vida, prazos e fluxo de controlo na Adaptive Platform [SWS_PHM_01138]. Anomalias detetadas passam por uma qualificação de erros em múltiplos níveis, desde o debouncing até à paragem do sistema [SWS_PHM_01137]. No caso de erros não solucionáveis pelo State Management, o módulo assume a reação ao erro e aciona o watchdog do sistema [SWS_PHM_01240].

mais ›

Contexto

O namespace ara::phm representa a interface C++ do Platform Health Management (PHM) no âmbito da AUTOSAR Adaptive Platform. A sua tarefa central é a monitorização funcional de unidades de software para garantia da integridade do sistema. Como entidades primárias funcionam SupervisedEntity, que representam fluxos funcionais monitorizados, bem como a classe abstrata RecoveryAction, através da qual podem ser definidas medidas de recuperação aplicativas. A monitorização é dividida através da enumeração TypeOfSupervision [SWS_PHM_01138] em três mecanismos fundamentais: a verificação cíclica de sinais de vida (kAliveSupervision), o cumprimento de limites temporais entre pontos de controlo (kDeadlineSupervision), bem como a verificação da ordem de execução correta (kLogicalSupervision).

No sistema global, ara::phm interage não apenas com os processos utilizadores, mas também comunica estreitamente com o PHM-Daemon e o State Management (SM). Se o State Management não conseguir executar uma recuperação necessária, o Platform Health Management escala a resolução de erros diretamente para o watchdog de hardware ou de sistema [SWS_PHM_01240].

Diagrama de contexto: interação entre SupervisedEntity, PHM-Daemon, State Management, RecoveryAction e Watchdog. Fontes: [SWS_PHM_01138], [SWS_PHM_01240]

Ciclo de vida

O modelo de ciclo de vida e de estados do Platform Health Management tem uma estrutura de dois níveis e distingue entre estados de monitoramento elementares e globais. Uma função de monitoramento individual assume estados de acordo com ElementarySupervisionStatus [SWS_PHM_01358]: no estado inativo, ela permanece em kDeactivated; após a ativação sem erros, em kOK. Se ocorrer uma anomalia, ela muda inicialmente para kFailed, desde que o erro ainda esteja dentro das tolerâncias ou dos tempos de desparasitação (debouncing) configurados. Apenas após decorrido o debouncing é que o erro é considerado qualificado e o status muda para kExpired [SWS_PHM_01358].

A avaliação global de múltiplos monitoramentos elementares é agregada em GlobalSupervisionStatus [SWS_PHM_01137]. Se todos os monitoramentos associados estiverem inativos, o estado global encontra-se em kDeactivated. Assim que pelo menos um monitoramento reportar kOK e nenhum apresentar falha, o status geral é kOK. Se pelo menos um monitoramento estiver em kFailed e nenhum em kExpired, isso reflete-se no estado global kFailed. Se um monitoramento atingir o estado de erro qualificado kExpired, o status global permanece em kExpired enquanto o tempo de tolerância definido não tiver decorrido. Após o término desse prazo de tolerância, o sistema transita para o estado final kStopped [SWS_PHM_01137].

Diagrama de estados: transições de estado do monitoramento global em função da detecção de erros e tempos de tolerância. Fontes: [SWS_PHM_01137], [SWS_PHM_01358]

Caminho de utilização

Numa sequência de integração típica, uma aplicação inclui as classes do namespace através de #include "ara/phm/supervised_entity.h" ou do cabeçalho de reencaminhamento #include "ara/phm/phm_fwd.h" [SWS_PHM_01358]. A aplicação instancia e gerencia um objeto de SupervisedEntity, que mapeia a execução da função a ser protegida. Interpretação: através desse objeto, a aplicação reporta, em operação regular, seus sinais de vida ou eventos de fluxo de controle ao Platform Health Management. Pergunta (aberta)

O daemon do PHM compara continuamente os eventos reportados com os critérios parametrizados para kAliveSupervision, kDeadlineSupervision ou kLogicalSupervision [SWS_PHM_01138]. Enquanto todos os sinais forem recebidos dentro dos prazos e das regras, a avaliação permanece no estado kOK [SWS_PHM_01358]. Se os valores-limite forem violados, o monitoramento passa pela qualificação de falhas e inicia a recuperação configurada ao atingir kExpired ou kStopped [SWS_PHM_01137]. Para isso, a interface RecoveryAction é utilizada, presumivelmente para executar contramedidas específicas da aplicação de forma estruturada antes de ocorrer uma escalada para o State Management. Pergunta (aberta)

Cenários de erro

Estados de erro específicos dentro do módulo são padronizados através do domínio de erro PhmErrorDomain e da enumeração PhmErrc [SWS_PHM_01240]. A enumeração define os seguintes códigos de erro:

• PhmErrc::kOfferFailed (= 2): não foi possível oferecer o serviço devido a falha na comunicação com o daemon do PHM [SWS_PHM_01240].
• PhmErrc::kSMCanNotHandleRecovery (= 3): o State Management não consegue lidar com a recuperação solicitada; o Platform Health Management assume então a recuperação e aciona o watchdog [SWS_PHM_01240].
• PhmErrc::kServiceNotReady (= 4): uma requisição não pode ser executada porque uma solicitação de ativação ou desativação (Enable/Disable) já está ativa [SWS_PHM_01240].

Para a criação de objetos de erro apropriados, o namespace disponibiliza a função auxiliar MakeErrorCode, que constrói um PhmErrc a partir de um ara::core::ErrorCode e de dados adicionais específicos do fabricante [SWS_PHM_01244]. A referência ao domínio de erro global pode ser obtida via GetPhmDomain [SWS_PHM_01251]. Ambas as funções são declaradas como constexpr e noexcept, garantindo segurança contra exceções e thread safety [SWS_PHM_01244], [SWS_PHM_01251]. Em caso de erro síncrono ou de exceções no módulo, o tipo de exceção PhmException também é utilizado.