classe <ExtendedDataRecord-Namespace>::<ExtendedDataRecordElementInterface>

Utilização e contexto de chamada

A função <ExtendedDataRecordElementInterface> serve como construtor para a criação de um DataElement para uma interface de registro de dados estendidos com base em um ara::core::InstanceSpecifier [SWS_DM_02158]. A declaração localiza-se no escopo <ExtendedDataRecord-Namespace>::<ExtendedDataRecordElementInterface> e requer a inclusão do arquivo de cabeçalho #include "<ExtendedDataRecordElementShortname>.h" AUTOSAR_AP_SWS_Diagnostics §8.49.2.2.1.6.

A chamada síncrona requer dois parâmetros de entrada [SWS_DM_02158]:

• instanceSpec (ara::core::InstanceSpecifier): Identificador da instância de serviço concreta no modelo AUTOSAR.
• concurrencyType (ara::diag::ConcurrencyType): Determina se a interface é instanciada como thread-safe (kConcurrent) ou não thread-safe (kNotConcurrent).

Concorrência e segurança contra erros

A própria função construtora é declarada como noexcept e especificada como thread-safe bem como exception safe [SWS_DM_02158]. Interpretação: Como a função é definida como noexcept, erros de modelagem e inicialização não devem ser sinalizados via C++-Exceptions, mas sim através das violations definidas no framework Adaptive [SWS_DM_02158]. Pergunta Q-9ce91764c3e8364e (aberta)

Tratamento de erros e violações de modelo

Em caso de configuração incorreta do modelo ou identificadores inválidos, ocorrem violations específicas [SWS_DM_02158]:

• InstanceSpecifierMappingIntegrityViolation: O identificador não pode ser resolvido no contexto do processo ou não referencia um PortPrototype.
• PortInterfaceMappingViolation: Um PortPrototype tipificado por DiagnosticExtendedDataRecordInterface não é referenciado por um DiagnosticDataPortMapping.
• ProcessMappingViolation: Existe uma InstanceRef correspondente, mas não foi encontrado nenhum processo modelado correspondente para o processo de tempo de execução.
• InstanceSpecifierAlreadyInUseViolation: O construtor foi chamado com um InstanceSpecifier que já está em uso no processo.

A função Offer ativa o encaminhamento de requisições de diagnóstico pelo Diagnostic Management Daemon (DM) para a respectiva instância do handler [SWS_DM_02152]. Ela é chamada sem parâmetros e retorna sincronicamente um ara::core::Result<void>, declarado como noexcept e especificado como exception-safe [SWS_DM_02152].

Para a utilização correta e o tratamento de erros, aplicam-se as seguintes diretrizes:

• Valor de retorno e erros: Em caso de sucesso, o resultado contém um valor vazio. Se o serviço já tiver sido registrado anteriormente para esta instância de handler, a chamada falha e retorna o código de erro DiagOfferErrc::kAlreadyOffered com semântica de rollback [SWS_DM_02152]. Domínios de erro correlatos também definem o código de erro kAlreadyOffered para este estado [SWS_DM_00514] [SWS_DM_00560].
• Simultaneidade: Ao contrário de outros handlers de diagnóstico, frequentemente designados como não thread-safe (como em [SWS_DM_00557]), este método é explicitamente definido como thread-safe [SWS_DM_02152].
• Interação no sistema: Enquanto uma interface ainda não tiver sido disponibilizada pela aplicação por meio de Offer, o DM reage, conforme o contexto, com valores padrão ou substitutos definidos, como, por exemplo, com o status «Not ready» em consultas de DoIP-PowerMode [SWS_DM_01525] ou valores substitutos para identificadores de grupo [SWS_DM_01527]. Além disso, a especificação enfatiza que funções de offer de diagnóstico são específicas para ara::diag e não devem ser confundidas com ara::com::Offer AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors».

Interpretação: O comportamento de retorno síncrono de Offer deve garantir que o registro do handler seja completamente concluído antes da recepção de requisições UDS subsequentes. Pergunta Q-e6b2916cf4887164 (aberta)

Utilização e semântica

O método puramente virtual Read é chamado pelo Diagnostic Management (DM) para obter os dados de um ExtendedDataRecordElement a partir da aplicação ([SWS_DM_02156]). Como o DM salva os dados obtidos de forma duradoura na memória não volátil, o método deve sempre fornecer um valor. Se os dados não estiverem disponíveis no momento da chamada, eles deverão ser preenchidos pela implementação com um padrão de preenchimento como 0xFF ([SWS_DM_02156]).

A execução ocorre de forma assíncrona e retorna um ara::core::Future, que encapsula a estrutura ReadOutput em caso de sucesso ([SWS_DM_02154]). A chamada passa os seguintes parâmetros ([SWS_DM_02156]):

• metaInfo: transmite metainformações da requisição de diagnóstico subjacente.
• cancellationHandler: permite a consulta de um cancelamento por meio de cancellationHandler.IsCanceled(), bem como o registro de uma função de notificação via cancellationHandler.SetNotifier().

Tratamento de erros

Em caso de erro, o Future disponibiliza um código de resposta negativa UDS (DiagUdsNrcErrc) ou um erro específico da aplicação (ApApplicationError) ([SWS_DM_02156], AUTOSAR_AP_SWS_Diagnostics §7.3.2.6.1 «NRCs created by application»). Caso a interface de serviço necessária ainda não seja ou não seja mais disponibilizada via offer(), o DM responde com NRC 0x94 (ResourceTemporarilyNotAvailable) ([SWS_DM_01257]). Além disso, DiagOfferErrc::kAlreadyOffered reporta se o serviço já estiver sendo oferecido ([SWS_DM_02156]).

Concorrência e interação

O método é especificado como seguro contra exceções (exception safe) ([SWS_DM_02156]). A segurança de threads é condicional e definida pela implementação (implementation defined) ([SWS_DM_02156]). Isso diferencia Read para Extended Data Records de operações de leitura em elementos de dados regulares ([SWS_DM_00596]) ou identificadores de dados ([SWS_DM_00640]), que são expressamente não thread-safe.

Utilização e contexto de chamada

A função StopOffer é chamada em uma instância da interface de Extended-Data-Record (<ExtendedDataRecord-Namespace>::<ExtendedDataRecordElementInterface>), a qual é incluída através do cabeçalho #include "<ExtendedDataRecordElementShortname>.h" [SWS_DM_02153]. A chamada ocorre de forma síncrona, não aceita parâmetros e não possui valor de retorno (void).

A finalidade do método é desativar o encaminhamento de mensagens de requisição recebidas do Diagnostic Management (DM) para o respectivo elemento de Extended-Data-Record [SWS_DM_02153]. Após a execução, o DM não encaminha mais novas requisições de diagnóstico para o handler associado.

Tratamento de erros e simultaneidade

A função é declarada com o identificador noexcept e especificada como segura contra exceções (exception safe) [SWS_DM_02153]. Códigos de erro específicos, valores de retorno ou notificações para monitoramentos de erro não são definidos no payload; em caso de erro, nenhuma exception é lançada.

Em relação à simultaneidade, o método é expressamente classificado como thread-safe (thread-safe) [SWS_DM_02153]. Isso representa uma particularidade, já que interfaces StopOffer correlatas em ara::diag – como, por exemplo, para rotinas [SWS_DM_00558], elementos de dados [SWS_DM_00617] ou monitores [SWS_DM_01089] – são especificadas como não thread-safe. Requisições que já estejam em processamento presumivelmente ainda serão concluídas ou descartadas antes da parada definitiva. Pergunta Q-82e9d44f8ac1969d (aberta)

Interação no Diagnostic Management

A nomenclatura segue o padrão uniforme de serviços no AUTOSAR Adaptive, no qual unidades funcionais controlam sua disponibilidade via Offer e StopOffer AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors». O elemento alinha-se, assim, a interfaces comparáveis do DM, como para serviços UDS genéricos [SWS_DM_00620], identificadores de dados [SWS_DM_00600], acessos de segurança [SWS_DM_00767] ou requisições de reset da ECU [SWS_DM_01017].