estrutura ara::diag::CommunicationControl::ComCtrlRequestParamsType

A estrutura de dados agrupa todos os parâmetros de entrada de uma requisição de serviço UDS 0x28 para o controle de comunicação adaptativo de acordo com [SWS_DM_00805]. Ao receber tal mensagem de diagnóstico, a plataforma desserializa os tipos de controle e de comunicação, bem como a identificação do nó, e passa a estrutura preenchida para o respectivo service handler. O software de aplicação avalia os valores contidos para influenciar de forma direcionada o comportamento de envio e recepção de segmentos de rede definidos (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»). Como container de dados sem estado, a estrutura não possui sincronização de concorrência própria, razão pela qual os acessos devem permanecer no contexto de execução do handler.

mais ›

Contexto

A estrutura ara::diag::CommunicationControl::ComCtrlRequestParamsType é um tipo central de transferência de dados dentro da interface de diagnóstico funcional do AUTOSAR Adaptive [SWS_DM_00805]. Ela é declarada no arquivo de cabeçalho ara/diag/communication_control.h e serve como container de parâmetros padronizado, o qual encapsula todos os parâmetros de entrada de uma requisição de diagnóstico do serviço UDS 0x28 (CommunicationControl) (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»).

No sistema global, a estrutura atua como intermediária entre o Diagnostic Management do AUTOSAR e o software de aplicação adaptativo, responsável pelo controle de comunicação específico do veículo. Comandos de diagnóstico recebidos de testadores externos são desserializados no nível da plataforma e repassados à aplicação através desta estrutura. A estrutura compreende três variáveis-membro públicas (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 «Public Member Variables»):

• controlType ([SWS_DM_01562], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.2 «controlType»): definido como std::uint8_t, este campo transporta a subfunção extraída da requisição UDS para especificação do processo de controle a ser executado.
• communicationType ([SWS_DM_01563], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.1 «communicationType»): igualmente do tipo std::uint8_t, este campo representa o tipo de comunicação indicado na requisição UDS (como, por ex., comunicação normal ou de gerenciamento de rede).
• nodeIdentificationNumber ([SWS_DM_01564], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.3 «nodeIdentificationNumber»): definida como std::uint16_t, esta variável identifica o nó de destino concreto ou a sub-rede a que a instrução de controle se destina.

Ciclo de vida

Como estrutura C++ elementar (struct) [SWS_DM_00805], ComCtrlRequestParamsType apresenta as características de um tipo de valor simples (Plain Old Data / POD). Ela não possui máquina de estados interna, ponteiros de função virtual nem áreas de memória alocadas dinamicamente (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 «Public Member Variables»).

A criação de uma instância ocorre tipicamente de forma volátil pelo framework de Diagnostic Management: assim que uma mensagem UDS 0x28 é recebida e formalmente validada, a pilha instancia a estrutura e inicializa as variáveis-membro com a carga útil decodificada (interpretação: a instanciação do objeto cabe inteiramente ao middleware no âmbito do acolhimento da requisição). Pergunta Q-1abe8049ce5759f2 (aberta) As relações de posse são estritamente limitadas ao contexto da chamada de método. A plataforma repassa a instância habitualmente por valor ou referência constante ao service handler da aplicação; a aplicação receptora não assume a posse duradoura da instância.

Em conformidade, não existem fases de ciclo de vida nem transições complexas de estado. A destruição da instância ocorre automaticamente ao sair do escopo da respectiva chamada de callback. No que diz respeito à concorrência, ComCtrlRequestParamsType não implementa mecanismos próprios de sincronização. Como os membros, após a inicialização pela plataforma, são avaliados pelo software de aplicação em regra apenas para leitura, o acesso deve ser thread-safe, desde que a instância seja passada localmente por thread ao contexto de processamento (interpretação: não são necessários bloqueios externos para a avaliação). Pergunta Q-d654753d06273bca (aberta)

Caminho de utilização

O caminho de uso típico no âmbito do processamento de diagnóstico realiza-se em uma sequência fixa de etapas, desde a mensagem de rede até a reação da aplicação (AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»):

1. Recepção da mensagem de diagnóstico: um testador de diagnóstico externo envia uma requisição UDS 0x28 para a unidade de controle. O Adaptive Diagnostic Management recebe o pacote de dados no nível de transporte.
2. Desserialização e instanciação: a pilha de diagnóstico analisa a carga útil, cria uma instância de ComCtrlRequestParamsType [SWS_DM_00805] e atribui aos campos controlType [SWS_DM_01562], communicationType [SWS_DM_01563], bem como nodeIdentificationNumber [SWS_DM_01564] os valores transmitidos.
3. Encaminhamento para o service handler: o middleware encaminha a instância para o método de callback implementado da interface CommunicationControl na aplicação adaptativa.
4. Avaliação de parâmetros e execução: a aplicação adaptativa lê a estrutura. Com base no nodeIdentificationNumber [SWS_DM_01564], determina-se se o próprio nó ou uma sub-rede está endereçada. Em seguida, através de controlType [SWS_DM_01562] e communicationType [SWS_DM_01563], os modos de envio e recepção correspondentes são ativados ou desativados.
5. Retorno: após a execução bem-sucedida, a aplicação confirma o processo ao Diagnostic Management, que transmite a resposta UDS positiva em conformidade com o padrão para o testador de diagnóstico.

Diagrama de sequência: fluxo típico de processamento de requisição, desde a mensagem UDS 0x28 até a avaliação de parâmetros na aplicação. Fontes: [SWS_DM_00805], AUTOSAR_AP_SWS_Diagnostics §8.7.2 «Struct: ComCtrlRequestParamsType»