estrutura ara::diag::GenericUDSService::OperationOutput

A estrutura ara::diag::GenericUDSService::OperationOutput serve no módulo diag como estrutura de saída para os dados úteis de mensagens de resposta UDS positiva [SWS_DM_00632]. Uma aplicação preenche a variável de bytes responseData após a execução bem-sucedida de um serviço UDS genérico e entrega a instância ao Diagnostic Management. Nesse processo, o identificador de serviço UDS (SID) não pode estar contido em responseData, pois este é adicionado automaticamente pela plataforma [SWS_DM_00632]. A estrutura não é prevista para cenários de erro e respostas negativas.

mais ›

Contexto

A estrutura de dados ara::diag::GenericUDSService::OperationOutput serve dentro da AUTOSAR Adaptive Platform no módulo diag como canal de saída padronizado para serviços UDS genéricos [SWS_DM_00632]. Ela é definida no arquivo de cabeçalho #include "ara/diag/generic_uds_service.h" e atua como encapsulamento para os dados úteis de uma execução bem-sucedida de serviço UDS [SWS_DM_00632]. Os principais parceiros de interação são a implementação específica da aplicação do manipulador de serviços UDS genéricos e o Diagnostic Management superior da plataforma AUTOSAR_AP_SWS_Diagnostics p. 80. Enquanto o Diagnostic Management assume a coordenação com o testador de diagnóstico externo, a validação de protocolo e o framework, OperationOutput disponibiliza a carga útil isolada para a mensagem de resposta UDS positiva [SWS_DM_00632].

Ciclo de vida

Instâncias de ara::diag::GenericUDSService::OperationOutput apresentam um ciclo de vida fortemente focado e de curta duração. A estrutura é instanciada pela aplicação do serviço no contexto local de uma solicitação UDS recebida. Por meio da única variável de elemento pública responseData, do tipo ara::core::Vector<std::uint8_t>, a estrutura assume a propriedade total dos bytes de dados úteis [SWS_DM_00632].

Interpretação: o tempo de vida de OperationOutput é volátil e vinculado à duração do respectivo processamento da solicitação; a instância deve ser transferida para o Diagnostic Management após o seu preenchimento por meio de valor de retorno ou semântica de movimento, e destruída novamente após a serialização no quadro de resposta UDS. Pergunta Q-c736182a9518978a (aberta) Por se tratar de um puro objeto de transferência de dados (DTO) sem lógica de estado interna, não existem transições de estado. Em relação à simultaneidade, OperationOutput não oferece segurança de thread inerente; contudo, como a instanciação e o preenchimento ocorrem isoladamente por solicitação dentro do contexto de processamento, não é necessária nenhuma sincronização externa na aplicação regular do serviço.

Caminho de utilização

O fluxo regular durante o processamento de uma solicitação de diagnóstico divide-se nas seguintes etapas:

• Recepção: o Diagnostic Management recebe uma solicitação UDS de um testador de diagnóstico externo e a encaminha para a respectiva instância de GenericUDSService AUTOSAR_AP_SWS_Diagnostics p. 81.
• Execução do serviço: a aplicação interpreta os parâmetros recebidos e executa a função de diagnóstico interna.
• Disponibilização do resultado: em caso de processamento bem-sucedido, a aplicação instancia um objeto do tipo OperationOutput e atribui os dados úteis da resposta ao campo responseData [SWS_DM_00632]. Neste contexto, a especificação determina obrigatoriamente que responseData deve conter exclusivamente os bytes de dados sem o identificador de serviço (SID) [SWS_DM_00632].
• Entrega: a aplicação entrega OperationOutput ao Diagnostic Management. Interpretação: a entrega ocorre tipicamente como valor de retorno síncrono ou incorporada em um valor futuro assíncrono como ara::core::Future. Pergunta Q-2dcf40060cca29a1 (aberta)
• Envio da mensagem: o Diagnostic Management prefixa automaticamente o SID positivo, completa o telegrama UDS e transmite a resposta ao testador de diagnóstico.

Diagrama de sequência: fluxo de geração da resposta UDS e entrega via OperationOutput. Fontes: [SWS_DM_00632], AUTOSAR_AP_SWS_Diagnostics p. 81

Cenários de erro

Na utilização da estrutura, devem ser observadas condições de contorno essenciais e padrões de comportamento em caso de falha:

• Exclusão de respostas negativas: de acordo com a especificação, OperationOutput representa explícita e exclusivamente o conteúdo de mensagens de resposta positivas [SWS_DM_00632]. Interpretação: se uma solicitação de serviço não puder ser processada com sucesso (por exemplo, devido a parâmetros inadmissíveis ou pré-condições inválidas), não deve ser gerado nenhum OperationOutput; em vez disso, a aplicação sinaliza um Negative Response Code (NRC) para o Diagnostic Management. Pergunta Q-09abb9092c1dc167 (aberta)
• Inclusão incorreta de SID: se o identificador de serviço for inserido erroneamente em responseData, resulta um telegrama UDS formatado incorretamente, uma vez que o Diagnostic Management prefixa o SID de forma autônoma em respostas positivas [SWS_DM_00632].
• Alocação de memória: como responseData é declarado como vetor dinâmico (ara::core::Vector), possíveis gargalos de memória devem ser considerados na atribuição de quantidades muito grandes de dados úteis [SWS_DM_00632].