classe ara::tsync::ConsumerTimeBaseValidationNotification

A interface ara::tsync::ConsumerTimeBaseValidationNotification informa aplicações consumidoras sobre blocos de dados de medição recém-disponíveis de uma base de tempo. Por meio dos métodos de callback SetSlaveTimingData [SWS_TS_00420] e SetPdelayInitiatorData [SWS_TS_00422], o sistema transfere dados detalhados de temporização e validação para o Time Slave, bem como para o iniciador de pDelay. Desenvolvedores de aplicações derivam da classe, implementam o processamento de dados e devem garantir que nenhuma exceção seja lançada, já que todos os métodos são especificados como noexcept e seguros contra exceções. Além disso, a classificação como non_threadsafe exige sincronização por parte da aplicação no caso de acessos concorrentes.

mais ›

Contexto

A classe ara::tsync::ConsumerTimeBaseValidationNotification representa uma interface de callback no módulo tsync da AUTOSAR Adaptive Platform. A sua finalidade consiste em informar uma aplicação consumidora assim que novos blocos de dados gravados estiverem disponíveis para uma base de tempo monitorada.

Nesta interação participam essencialmente três componentes:

• Base de tempo do módulo tsync: registra continuamente medições de tempo e de sincronização na rede de comunicação.
• Interface ConsumerTimeBaseValidationNotification: define os pontos de transferência para blocos de dados de medição gravados por meio dos métodos SetSlaveTimingData [SWS_TS_00420] e SetPdelayInitiatorData [SWS_TS_00422].
• Aplicação consumidora: implementa os métodos de callback, recebe os valores de medição disponibilizados e realiza a validação técnica da base de tempo.

Por meio dessa estrutura, a lógica de validação específica da aplicação é desacoplada de forma limpa do registro dos dados de tempo interno à plataforma.

Ciclo de vida

Como classe de interface abstrata com métodos puramente virtuais, ara::tsync::ConsumerTimeBaseValidationNotification não pode ser instanciada diretamente. Uma aplicação consumidora deriva uma classe concreta e implementa os métodos necessários.

A criação e a posse são de inteira responsabilidade da aplicação consumidora. Supõe-se que a aplicação crie o objeto de callback durante a sua fase de inicialização e o vincule à base de tempo correspondente do serviço tsync. Pergunta Q-a423ce4cbd4eeaaa (aberta)

Para a destruição, a classe disponibiliza um destruidor virtual: virtual ~ConsumerTimeBaseValidationNotification() noexcept = default; [SWS_TS_01300]. A declaração como destruidor virtual garante que instâncias de classes derivadas possam ser liberadas via ponteiro de classe base com segurança de tipos e sem vazamentos de recursos.

Em termos de concorrência, os métodos de notificação SetSlaveTimingData [SWS_TS_00420] e SetPdelayInitiatorData [SWS_TS_00422] são especificados como non_threadsafe. Caso a chamada pelo serviço da plataforma ocorra no contexto de uma thread em segundo plano, a própria implementação da aplicação é responsável por proteger os acessos aos recursos compartilhados da aplicação. Pergunta Q-1b857df043504eec (aberta)

Caminho de utilização

O fluxo típico para o uso da notificação de validação compreende as seguintes etapas:

1. Implementação: a aplicação consumidora implementa uma classe derivada de ara::tsync::ConsumerTimeBaseValidationNotification.
2. Recepção de dados de medição do Time Slave: assim que um novo bloco de dados de medição for gravado para o Time Slave da base de tempo, o serviço de tempo chama o método SetSlaveTimingData [SWS_TS_00420] e passa os dados detalhados de validação por meio do parâmetro measurementData do tipo TimeSlaveMeasurementType.
3. Recepção de dados de medição do iniciador de pDelay: se houver novos dados de medição disponíveis para o iniciador de pDelay, ocorre a chamada de SetPdelayInitiatorData [SWS_TS_00422] com os dados detalhados de temporização em PdelayInitiatorMeasurementType.
4. Processamento: a aplicação consumidora avalia os blocos de dados transmitidos para detectar erros de sincronização ou desvios de tempo de execução.
5. Liberação do objeto: ao término do monitoramento, a instância é desalocada por meio do destruidor virtual [SWS_TS_01300].

Diagrama de sequência: transmissão de blocos de dados de medição registrados para Time Slave e iniciador de pDelay para a implementação consumidora. Fontes: [SWS_TS_00420], [SWS_TS_00422].

Cenários de erro

Os métodos da interface foram projetados para robustez máxima e chamadas determinísticas:

• Segurança contra exceções: todas as funções-membro – SetSlaveTimingData [SWS_TS_00420], SetPdelayInitiatorData [SWS_TS_00422] e o destruidor [SWS_TS_01300] – são declaradas com noexcept e especificadas como seguras contra exceções (exception safe). Os métodos de sobrescrita na aplicação consumidora não devem propagar nenhuma exceção para o exterior, pois isso levaria à terminação imediata do programa.
• Ausência de canais de retorno: como os métodos de callback possuem o tipo de retorno void, erros de processamento dentro da lógica da aplicação não podem ser reportados de volta ao módulo tsync. A aplicação deve tratar e registrar internamente e de forma autônoma quaisquer estados de erro.
• Riscos de concorrência: devido à propriedade non_threadsafe ([SWS_TS_00420], [SWS_TS_00422]), deve-se evitar que múltiplos blocos de dados sejam processados em paralelo sem bloqueio por parte da aplicação. Interpretação: além disso, o objeto de callback deve permanecer válido durante todo o período de registro na base de tempo, a fim de evitar acessos fatais à memória já liberada. Pergunta Q-934e451f6a0099c1 (aberta)