módulo ara::tsync — Time Synchronization

O cluster funcional Time Synchronization disponibiliza à AUTOSAR Adaptive Platform bases de tempo consistentes e sincronizadas em toda a rede (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Por meio de interfaces padronizadas, aplicações adaptativas consultam estados de tempo atômicos ou, como fontes de tempo ativas, injetam novas correções de tempo e taxa no sistema geral. Ao mesmo tempo, callbacks de notificação registrados monitoram continuamente mudanças de estado, bem como saltos temporais dos relógios subjacentes ([SWS_TS_01009]). Mecanismos avançados para validação de dados de medição e valores de frescor asseguram, assim, a integridade temporal contra erros de transmissão e manipulações.

mais ›

O cluster funcional Time Synchronization (tsync) disponibiliza bases de tempo consistentes e sincronizadas em toda a rede na AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Operando como um serviço de fundo baseado em daemon, ele abstrai mecanismos de sincronização específicos de hardware e barramento (como o IEEE 802.1AS gPTP) e atende a clusters centrais como Log and Trace, o Intrusion Detection System Manager (IdsM) e serviços de atualização por meio de interfaces padronizadas (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagrama de contexto: integração do cluster Time Synchronization baseado em daemon na AUTOSAR Adaptive Platform e suas relações de interface com clusters consumidores e aplicações. Fontes: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Para o acesso de leitura, as aplicações utilizam a interface SynchronizedTimeBaseConsumer ([SWS_TS_01001]). O método GetTimeWithStatus() retorna um snapshot atômico do tipo SynchronizedTimeBaseStatus, a partir do qual podem ser obtidos o tempo global, o tempo local contínuo de criação, o estado de sincronização e os UserData recebidos ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). Para evitar polling, as aplicações registram-se por meio de callbacks de notificação para mudanças de status e saltos temporais ([SWS_TS_01010], [SWS_TS_01014]).

Diagrama de sequência: fluxo de uma consulta síncrona de tempo por meio da interface de consumidor e leitura das propriedades atômicas do snapshot. Fontes: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Aplicações que atuam como fontes de tempo controlam o comportamento do sistema por meio de SynchronizedTimeBaseProvider: SetTime() aciona transmissões imediatas no barramento, enquanto UpdateTime() ajusta o relógio inicialmente apenas de forma local ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Mecanismos complementares como Time Validation ([SWS_TS_00420], [SWS_TS_00421]) e o Freshness Value Management nativo (FVM) protegem contra erros de desvio e repetição ([SWS_TS_14198]). Em caso de falha, códigos TsyncErrc (por exemplo, kDaemonConnectionLost) sinalizam interrupções de conexão, enquanto a ausência de mensagens de sincronização é indicada como kTimeOut no objeto de estado ([SWS_TS_00901], [SWS_TS_01050]).

mais ›

O cluster funcional Time Synchronization (tsync) disponibiliza bases de tempo coordenadas e sincronizadas em toda a rede na AUTOSAR Adaptive Platform e desacopla os processos das aplicações dos protocolos de sincronização de tempo específicos de hardware e barramento (AUTOSAR_AP_SWS_TimeSynchronization p. 16). O sistema forma a base de tecnologia da informação para sistemas distribuídos nos quais devem ser asseguradas sequências de eventos consistentes além dos limites das unidades de controle, protocolos de rastreamento reproduzíveis e ciclos de cálculo determinísticos (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagrama de contexto: integração do cluster Time Synchronization baseado em daemon na AUTOSAR Adaptive Platform e suas relações de interface com clusters consumidores e aplicações. Fontes: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Limites do sistema e papel do cluster Time Synchronization baseado em daemon

A arquitetura funcional do Time Synchronization é implementada como um cluster baseado em daemon (daemon-based), que opera em segundo plano como um serviço central da plataforma (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Esse daemon interage diretamente com as interfaces do sistema operacional subjacente e processa dados de sincronização de tempo baseados em rede, como gPTP (IEEE 802.1AS) ou sincronizações de tempo de barramento clássicas (AUTOSAR_FO_PRS_TimeSyncProtocol p. 68). Em relação ao contexto da aplicação, o cluster encapsula completamente a compensação matemática de desvio e deslocamento dos relógios de hardware.

Diversos clusters funcionais centrais da Adaptive Platform acessam tsync por meio de interfaces de serviço padronizadas (AUTOSAR_AP_EXP_SWArchitecture p. 83). Por exemplo, o Log and Trace baseia-se na base de tempo sincronizada para atribuir carimbos de data/hora globais confiáveis aos eventos de log e DLT de todo o sistema (AUTOSAR_AP_EXP_SWArchitecture p. 59; AUTOSAR_AP_SWS_LogAndTrace p. 15). Módulos relevantes para a segurança, como o Intrusion Detection System Manager (IdsM) e serviços de atualização (UCM e Vehicle UCM), também utilizam obrigatoriamente a interface C++ de SynchronizedTimeBaseConsumer para orientar relatórios forenses consistentes e transações de atualização homogêneas além dos limites das unidades de controle (AUTOSAR_AP_EXP_SWArchitecture p. 125; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 16; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 11).

Interfaces consumidoras e consultas de tempo com estado

Para o acesso de leitura a uma base de tempo sincronizada, as aplicações utilizam a classe de interface SynchronizedTimeBaseConsumer ([SWS_TS_01001]). A classe implementa a semântica de movimento ([SWS_TS_01003], [SWS_TS_01004]), mas exclui explicitamente qualquer cópia ([SWS_TS_01005], [SWS_TS_01006]). Em tempo de execução, GetRateDeviation() permite a leitura direta do desvio de frequência atual do relógio ([SWS_TS_01008]).

O elemento central de cada consulta síncrona é a operação GetTimeWithStatus() ([SWS_TS_01009]). Em vez de fornecer valores de tempo brutos isolados, o método gera um snapshot internamente consistente do tipo SynchronizedTimeBaseStatus (EXP_SWArchitecture p. 81). Esse snapshot congela o momento exato de criação no tempo global ([SWS_TS_01055]) e no tempo local contínuo por meio de GetCreationLocalTime() ([SWS_TS_14176]). Os instantes de tempo são mapeados no tipo padronizado C++-Chrono Timestamp com resolução em nanossegundos com base em std::int64_t ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

A partir do snapshot, além do tempo, também podem ser determinados o estado de comunicação e sincronização via GetSynchronizationStatus() ([SWS_TS_01053]), um eventual salto temporal ocorrido via GetLeapJump() ([SWS_TS_01054]), bem como dados de usuário específicos da aplicação por meio de GetUserData() ([SWS_TS_01056]). Não existe um construtor padrão para o objeto de estado ([SWS_TS_01061]), enquanto construtores de movimento e cópia asseguram sua passagem thread-safe para as rotinas chamadoras da aplicação ([SWS_TS_01057], [SWS_TS_01058]).

Diagrama de sequência: fluxo de uma consulta síncrona de tempo por meio da interface de consumidor e leitura das propriedades atômicas do snapshot. Fontes: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Notificações baseadas em eventos e monitoramento de sincronização

Para evitar laços de polling, SynchronizedTimeBaseConsumer disponibiliza um padrão observer orientado a eventos por meio de callbacks de notificação (AUTOSAR_AP_EXP_SWArchitecture p. 226). As aplicações registram-se com callbacks com segurança de tipos para mudanças de estado específicas ([SWS_TS_14221], [SWS_TS_14222]). A cada novo registro, o novo notificador sobrescreve o manipulador registrado anteriormente ([SWS_TS_01010]).

Para mudanças de estado agregadas, existe RegisterStatusChangeNotifier() ([SWS_TS_01010]), complementado por UnregisterStatusChangeNotifier() ([SWS_TS_01011]). Caso uma aplicação reaja primariamente à alteração do status de sincronização (por exemplo, perda da conexão com o grandmaster), utiliza-se RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]). Saltos temporais para o futuro (kTimeLeapFuture) ou para o passado (kTimeLeapPast) que ultrapassem um valor limite configurado são reportados via RegisterTimeLeapNotifier() ([SWS_TS_01014], [SWS_TS_01051]).

Para aplicações mecatrônicas de alta precisão, disponibiliza-se também RegisterTimePrecisionMeasurementNotifier() ([SWS_TS_01018]). O callback repassa uma estrutura TimePrecisionMeasurement que contém valores exatos de segundos e nanossegundos imediatamente antes (locSeconds, locNanoSeconds) e depois da sincronização (glbSeconds, glbNanoSeconds), o atraso de caminho calculado pathDelay e a máscara de bits timeBaseStatus ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). O cluster Time Synchronization não realiza gerenciamento de filas (queuing) nesse processo; armazenamentos em buffer devem ser implementados, se necessário, dentro do callback da aplicação ([SWS_TS_01018]).

Diagrama de sequência: registro e fluxo de notificação assíncrona em alterações de sincronização e saltos temporais. Fontes: [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture p. 226

Diagrama de estados: ciclo de vida do status de sincronização de uma base de tempo conforme SWS_TS_01050. Fontes: [SWS_TS_01050], AUTOSAR_SWS_TimeSync p. 25

Disponibilização de bases de tempo e ajuste de frequência por provedores

Se uma Adaptive Application atuar como fonte de tempo ativa (Time Master) – por exemplo, por meio de conexão a um receptor GNSS ou a um relógio de referência externo –, ela utiliza a classe SynchronizedTimeBaseProvider ([SWS_TS_01101]). A interface permite a definição explícita de novos valores de tempo por meio de duas semânticas distintas: SetTime() e UpdateTime() (EXP_SWArchitecture p. 80).

A chamada de SetTime() não apenas redefine o estado interno do relógio, mas também força o envio imediato das mensagens de sincronização atualizadas no barramento do veículo ([SWS_TS_01107]). Por outro lado, UpdateTime() atualiza a hora inicialmente de forma exclusiva no nível local; a transmissão para o barramento ocorre de forma postergada no ciclo seguinte regular do protocolo de transmissão de tempo ([SWS_TS_01108]). Ambos os métodos recebem, além do carimbo de data/hora, UserData estruturados para distribuir informações adicionais que acompanham a sincronização por toda a rede ([SWS_TS_01112], [SWS_TS_01113]).

Para o ajuste fino de osciladores de quartzo e prevenção de saltos abruptos de fase, SetRateCorrection() possibilita a imposição de um fator de correção de frequência relativo ([SWS_TS_01110]). Adicionalmente, GetRateDeviation() fornece o desvio de clock atualmente presente ([SWS_TS_01111]), enquanto GetCurrentTime() lê o valor de tempo absoluto do relógio independentemente do status atual de sincronização ([SWS_TS_01109]).

Garantia de integridade por meio de Time Validation e Freshness Value Management

Em ambientes de condução altamente automatizados e críticos para a segurança, a mera adoção de valores de tempo não é suficiente; a exatidão e a inviolabilidade dos carimbos de data/hora devem ser continuamente validadas (AUTOSAR_AP_SWS_TimeSynchronization p. 38). Para isso, tsync oferece interfaces de callback para Time Validation: os consumidores registram-se por meio de RegisterTimeValidationNotification() ([SWS_TS_01016]), e os provedores, de forma análoga, pelo método específico de provedor ([SWS_TS_01114]).

As interfaces de validação ConsumerTimeBaseValidationNotification e ProviderTimeBaseValidationNotification repassam conjuntos detalhados de dados de medição para aplicações de monitoramento especializadas ([SWS_TS_01300], [SWS_TS_01301]). Na estação mestre, SetMasterTimingData() fornece o carimbo de data/hora de saída (egress) (syncEgressTimestamp) e o número de sequência (sequenceId) dos frames de sincronização transmitidos ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). No nível escravo, SetSlaveTimingData() repassa os carimbos de data/hora de entrada (ingress) correspondentes (syncIngressTimestamp), o campo de correção recebido (correctionField) e o atraso de caminho medido (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). Para medições de atraso ponto a ponto (peer-to-peer), SetPdelayInitiatorData() e SetPdelayResponderData() disponibilizam integralmente os momentos de entrada e saída dos pacotes de requisição e resposta ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

Para proteção contra ataques de repetição e segurança das mensagens de tempo transmitidas, a plataforma integra o Freshness Value Management (FVM) por meio de interfaces nativas no espaço de nomes apext::tsync ([SWS_TS_14198], EXP_SWArchitecture p. 83). Durante a inicialização do sistema, Initialize() inicializa o plugin FVM responsável ([SWS_TS_14200]). Antes do envio, a pilha chama GetTxFreshness() para obter valores de contagem recentes ([SWS_TS_14199]), enquanto na recepção GetRxFreshness() é empregado para verificação e autenticação ([SWS_TS_14198]). Os dados são transportados nesse processo por meio do FVContainer padronizado ([SWS_TS_14195], [SWS_TS_14196]).

Diagrama de sequência: fluxo de validação de dados de medição de temporização entre mestre, escravo e aplicação validadora externa. Fontes: [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization p. 38

Configuração, vinculação de processos e modelagem de manifestos

A alocação e a vinculação funcional do cluster ocorrem declarativamente nos manifestos de modelo do AUTOSAR (AUTOSAR_AP_TPS_ManifestSpecification p. 590). No Machine Manifest, o daemon da plataforma é instanciado em uma Machine concreta por meio do elemento do metamodelo TimeSyncModuleInstantiation, gerenciando ali os objetos físicos e virtuais de TimeBaseResource (AUTOSAR_AP_TPS_ManifestSpecification p. 590).

No nível da aplicação, os processos declaram suas necessidades de bases de tempo por meio de protótipos de porta (RPortPrototype para consumidores ou PPortPrototype para provedores) (AUTOSAR_AP_TPS_ManifestSpecification p. 599). O constructo do metamodelo TimeSyncPortPrototypeToTimeBaseMapping vincula essas portas, individualmente por processo, às bases de tempo definidas na máquina (TPS_ManifestSpecification p. 599; AUTOSAR_AP_TPS_ManifestSpecification p. 600). Em tempo de execução, a instanciação no código é realizada por meio do ara::core::InstanceSpecifier com segurança de tipos, pelo qual a pilha vincula a base de tempo configurada correta ([SWS_TS_01001], [SWS_TS_01101]).

Comportamento em caso de erro

Situações de erro no cluster Time Synchronization são sinalizadas por meio do modelo de erro padronizado da Adaptive Platform (ara::core::Result e ara::core::ErrorCode) ([SWS_TS_00910]). Para operações regulares da base de tempo, a enumeração TsyncErrc define os códigos de erro ([SWS_TS_00901]). Se, por exemplo, a comunicação entre processos com o daemon da plataforma for interrompida, o código de erro kDaemonConnectionLost é retornado ([SWS_TS_00901]).

Por meio do domínio de erro global TsyncErrorDomain, os códigos de erro podem ser inspecionados ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) ou, com exceções em C++ ativadas, lançados via ThrowAsException() como TsyncException ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). Para o Freshness Value Management existe um domínio de erro autônomo TsyncFvmErrorDomain com a enumeração TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). Se a inicialização falhar, Initialize() retorna o erro kFVInitializeFailed ([SWS_TS_14200]), enquanto em caso de contadores indisponíveis para verificações de autenticação é reportado kFVNotAvailable ([SWS_TS_14202]).

No nível funcional, o cluster não sinaliza necessariamente a perda de mensagens de tempo por meio de erros síncronos da API, mas marca a base de tempo no objeto de status com o status de comunicação kTimeOut ([SWS_TS_01050]) ou define o bit correspondente em timeBaseStatus ([SWS_TS_01403]). Interpretação: a aplicação deverá, portanto, ter sempre a obrigação de verificar ativamente o status de validade do snapshot após GetTimeWithStatus(), antes de utilizar valores de medição para malhas de controle críticas para a segurança. Pergunta Q-0cd9bb48452ae3db (aberta)

Evidências mais detalhadas

Os requisitos centrais e os pontos de especificação do módulo tsync podem ser atribuídos aos seguintes tópicos principais:

• Interfaces de tempo de execução para consumers e providers: As operações de ciclo de vida e de consulta baseiam-se em [SWS_TS_01001] a [SWS_TS_01019], bem como nas funções de provider [SWS_TS_01101] a [SWS_TS_01115] (EXP_SWArchitecture p. 80, EXP_SWArchitecture p. 81).
• Estruturas de status e representação de tempo: Definição de SynchronizedTimeBaseStatus, SynchronizationStatus e LeapJump conforme [SWS_TS_01050] a [SWS_TS_01062], bem como tipos chrono padrão de acordo com [SWS_TS_01251] a [SWS_TS_01265].
• Time Validation e aquisição de dados de medição: Definição das estruturas de medição e dos callbacks de notificação de acordo com [SWS_TS_00420] a [SWS_TS_00423], bem como [SWS_TS_14140] a [SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization p. 38).
• Extensão de segurança FVM: Autenticação e verificação de frescor por meio das interfaces [SWS_TS_14195] a [SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture p. 83).
• Modelagem de manifesto: Configuração declarativa e mapeamento de processos e protótipos de portas para bases de tempo de acordo com AUTOSAR_AP_TPS_ManifestSpecification p. 590 e AUTOSAR_AP_TPS_ManifestSpecification p. 599.