módulo ara::diag — Diagnostics

Na AUTOSAR Adaptive Platform, o cluster funcional Diagnostic Management fornece a infraestrutura central para o diagnóstico veicular clássico UDS e moderno SOVD (AUTOSAR_AP_EXP_SWArchitecture p. 150). Como daemon da plataforma, ele termina camadas de transporte como DoIP, controla manipuladores de protocolo e encaminha requisições de diagnóstico para Adaptive Applications por meio de interfaces de callback fortemente tipadas ([SWS_DM_00311]). Ao mesmo tempo, o módulo assume o monitoramento de falhas, a temporização e o debounce por contadores, além do gerenciamento da memória de falhas. As aplicações liberam funções de serviço por meio de um modelo declarativo de offer, mantendo a lógica da aplicação e o processamento de protocolo claramente separados entre si.

mais ›

O cluster funcional Diagnostic Management (ara::diag) fornece na AUTOSAR Adaptive Platform a infraestrutura central baseada em daemon para a execução da comunicação de diagnóstico veicular (AUTOSAR_AP_EXP_SWArchitecture p. 150). Ele desacopla manipuladores de protocolo específicos de transporte (como DoIP ou CAN-TP) do núcleo de diagnóstico propriamente dito (UdsTransportProtocolMgr), permitindo assim uma terminação e um encaminhamento uniformes das requisições de diagnóstico (AUTOSAR_AP_EXP_SWArchitecture p. 164).

Diagrama de contexto: Integração do daemon do Diagnostic Management entre manipuladores de transporte, Adaptive Applications e testadores externos. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

Para a execução de serviços, o módulo implementa um modelo declarativo de disponibilização: o daemon de diagnóstico realiza as port interfaces, enquanto as Adaptive Applications registram callbacks de serviço para DataIdentifier, rotinas ou transferências baseadas em blocos e controlam sua disponibilidade via Offer() ou StopOffer() ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture p. 156). Mensagens recebidas são processadas à prova de falhas por meio de mecanismos de indicação e entrega em duas etapas (IndicateMessage e HandleMessage) ([SWS_DM_00309], [SWS_DM_00311]).

Diagrama de sequência: Fluxo de controle de ponta a ponta de uma requisição UDS, desde a camada de transporte, passando pelo gerenciador de diagnóstico, até a aplicação utilizadora. Fontes: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

Além das funções clássicas de UDS, o cluster gerencia monitores de diagnóstico, realiza debounces configurados e persiste falhas qualificadas na memória primária de falhas (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics p. 225). Padrões estendidos como ISO 13400-2 (DoIP) e ASAM SOVD (Service-Oriented Vehicle Diagnostics) são integrados de forma transparente à plataforma por meio de interfaces especializadas para linhas de ativação, autenticações e payloads JSON hierárquicos ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170).

mais ›

Papel arquitetural e limites de sistema do Diagnostic Management

Na AUTOSAR Adaptive Platform (Release R25-11), o cluster funcional Diagnostic Management (ara::diag) constitui o ponto central de controle para o diagnóstico veicular interno e externo (AUTOSAR_AP_EXP_SWArchitecture p. 150). Do ponto de vista arquitetural, o módulo é projetado como um serviço de segundo plano baseado em daemon («aapFunctionalCluster» Diagnostic Management daemon-based). Ele termina protocolos de diagnóstico físicos e lógicos, gerencia o contexto global de diagnóstico e disponibiliza a infraestrutura de middleware por meio da qual Adaptive Applications individuais podem fornecer dados e rotinas relacionados ao diagnóstico (AUTOSAR_AP_EXP_SWArchitecture p. 156).

O panorama de interfaces divide-se primariamente em duas categorias: port interfaces modeladas, configuradas via manifesto AUTOSAR e vinculadas aos processos da aplicação, e interfaces de runtime em C++ nativo (AUTOSAR_AP_EXP_SWArchitecture p. 150). Entre as interfaces nativas destaca-se, em particular, a classe Conversation, por meio da qual as aplicações podem consultar estados de sessão atuais ([SWS_DM_00696]), determinar níveis de segurança ([SWS_DM_00698]) ou inspecionar conversas de diagnóstico ativas ([SWS_DM_00783]). Interpretação: A separação estrita entre o daemon central de diagnóstico e os processos utilizadores provavelmente foi escolhida para garantir tempos de resposta determinísticos em relação a testadores externos, mesmo durante reinicializações de processos de aplicações individuais. Pergunta Q-2e2ea8eb9d415fed (aberta)

Diagrama de contexto: Integração do daemon do Diagnostic Management entre manipuladores de transporte, Adaptive Applications e testadores externos. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

Conexão da camada de transporte e controle do ciclo de vida dos manipuladores de protocolo

Para operar independentemente de tecnologias de rede específicas (como Ethernet/DoIP ou CAN/ISO-TP), o Diagnostic Management desacopla o núcleo do protocolo por meio de interfaces de transporte padronizadas (AUTOSAR_AP_EXP_SWArchitecture p. 164). O núcleo genérico implementa a interface UdsTransportProtocolMgr, enquanto adaptadores específicos de transporte são conectados como UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture p. 165). Cada manipulador é identificado por um identificador exclusivo, que pode ser consultado via GetHandlerID() ([SWS_DM_00325]).

O controle do ciclo de vida de um manipulador de transporte divide-se em fases operacionais determinísticas (AUTOSAR_SWS_Diagnostics p. 128): durante a inicialização, o Diagnostic Management inicializa o manipulador via Initialize() ([SWS_DM_00319]) e, em seguida, ativa o processamento de mensagens por meio de Start() ([SWS_DM_00322]). No encerramento controlado, o gerenciador solicita ao manipulador via Stop() o fechamento de conexões abertas ([SWS_DM_00323]), após o que o manipulador confirma a conclusão via HandlerStopped() ([SWS_DM_00314]).

Para sessões de diagnóstico de longa duração, a AUTOSAR também especifica um mecanismo de recuperação através dos ciclos de vida dos processos (AUTOSAR_SWS_Diagnostics p. 134). Se um canal previamente persistido puder ser restabelecido após uma reinicialização do gerenciador de diagnóstico, o manipulador de transporte reportará isso via NotifyReestablishment() ([SWS_DM_00326]). O gerenciador sincroniza o estado internamente e confirma essa ação chamando ChannelReestablished() ([SWS_DM_00313]).

Diagrama de sequência: Controle do ciclo de vida de um manipulador de transporte UDS pelo gerenciador genérico de diagnóstico. Fontes: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics p. 128

Execução de serviços UDS e tratamento de requisições específico da aplicação

Mensagens UDS recebidas são processadas passo a passo após a validação do protocolo (AUTOSAR_SWS_Diagnostics p. 130). Inicialmente, o manipulador de transporte anuncia uma mensagem iniciada junto ao gerenciador via IndicateMessage() para alocar recursos e buffers ([SWS_DM_00309]). A mensagem é encapsulada como UdsMessage, a qual disponibiliza endereço de origem ([SWS_DM_00297]), endereço de destino ([SWS_DM_00298]) e tipo de endereçamento ([SWS_DM_00299]). Após a recepção completa, o manipulador transfere o objeto de dados via HandleMessage() para o Diagnostic Management ([SWS_DM_00311]), sendo que metainformações específicas do canal são complementadas por meio de AddMetaInfo() ([SWS_DM_00302]).

No Release R25-11, a interação entre o daemon da plataforma e a aplicação segue um modelo invertido de disponibilização de serviços (AUTOSAR_AP_EXP_SWArchitecture p. 156): o daemon da plataforma realiza as portas de serviço, enquanto as Adaptive Applications implementam métodos de callback e ativam explicitamente sua prontidão para encaminhamento via Offer() ([SWS_DM_00557]) ou a suspendem via StopOffer() ([SWS_DM_00558]). Isso se aplica da mesma forma a rotinas genéricas (GenericRoutine [SWS_DM_00552]), rotinas tipadas (RoutineInterface [SWS_DM_00589] com Start [SWS_DM_00591]), identificadores de dados (GenericDataIdentifier [SWS_DM_00634] com Read [SWS_DM_00636] e Write [SWS_DM_00637]), bem como a serviços UDS genéricos (GenericUDSService [SWS_DM_00616] com HandleMessage [SWS_DM_00618]).

Transações de diagnóstico de maior duração (como transferências de bloco via UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] ou FileTransferService [SWS_DM_01325] de acordo com AUTOSAR_AP_EXP_SWArchitecture p. 163) são processadas de forma assíncrona via ara::core::Future. Para evitar bloqueios de recursos, os manipuladores específicos da aplicação recebem uma instância de CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture p. 152). Por meio de IsCanceled(), a aplicação pode verificar se houve um cancelamento ([SWS_DM_00614]) ou registrar uma função de notificação via SetNotifier() ([SWS_DM_00615]). Para reinicializações coordenadas, é disponibilizada a interface EcuResetRequest ([SWS_DM_01010]), que delega requisições de reset ao State Management (AUTOSAR_AP_EXP_SWArchitecture p. 162).

Diagrama de sequência: Fluxo de controle de ponta a ponta de uma requisição UDS, desde a camada de transporte, passando pelo gerenciador de diagnóstico, até a aplicação utilizadora. Fontes: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

Monitoramento de eventos, debounce e gerenciamento da memória de falhas

Para a detecção e qualificação de falhas de sistema, o Diagnostic Management implementa um modelo hierárquico composto por monitores e eventos de diagnóstico (SWS_Diagnostics p. 225). Uma aplicação instancia um objeto Monitor ([SWS_DM_00548]) e reporta resultados de testes continuamente via ReportMonitorAction() ([SWS_DM_00543]). O módulo suporta algoritmos de debounce tanto baseados em contadores quanto baseados em tempo ([SWS_DM_00549], [SWS_DM_00550]). Por meio da interface Event, as aplicações podem determinar o byte de status UDS atual ([SWS_DM_00649]), verificar o status de debounce ([SWS_DM_00654]) ou registrar callbacks para alterações de status ([SWS_DM_00650]).

Para manter reduzido o footprint de portas em sistemas complexos, a plataforma fornece interfaces agregadas (AUTOSAR_AP_EXP_SWArchitecture p. 153): por meio de MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) e MultipleCondition ([SWS_DM_01727]), múltiplos canais de monitoramento podem ser endereçados por meio de uma port interface compartilhada. O gerenciamento de liberação para monitores é realizado por meio de objetos Condition ([SWS_DM_00712]), enquanto OperationCycle ([SWS_DM_00752]) e Indicator ([SWS_DM_00742], SWS_Diagnostics p. 633) controlam ciclos de operação e sinalizam solicitações de lâmpada de advertência.

Os eventos agregados convergem para o gerenciamento da memória de falhas, exposto via DTCInformation ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture p. 144). Esta interface permite a leitura de registros armazenados ([SWS_DM_00669]), a limpeza seletiva ou global de DTCs ([SWS_DM_00671]) e a ativação da gravação de DTCs ([SWS_DM_00674]). Se ocorrer um estouro de capacidade da memória primária, a aplicação será notificada via SetEventMemoryOverflowNotifier() ([SWS_DM_00918], [SWS_DM_00919]).

Diagrama de estados/atividades: Fluxo desde a ação do monitor, passando pelo debounce, até a qualificação do DTC na memória de falhas. Fontes: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics p. 225

Protocolos de diagnóstico estendidos: Integração de DoIP e serviços SOVD

Para redes veiculares baseadas em Ethernet, o módulo integra funções dedicadas de DoIP (Diagnostic communication over Internet Protocol conforme a ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture p. 166, AUTOSAR_AP_EXP_SWArchitecture p. 167). Extensões da plataforma reportam o estado de linhas de ativação física via DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification p. 338). Com base nisso, mensagens de anúncio do veículo (Vehicle Announcement Messages) podem ser disparadas via DoIPTriggerVehicleAnnouncement ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics p. 108). A identificação de grupo e de entidade é consultada dinamicamente via DoIPGroupIdentification ([SWS_DM_00722]) e DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]).

Diagrama de sequência: interação entre aplicação, linha de ativação e disparo de anúncios de veículo DoIP. Fontes: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics p. 108

Além dos serviços UDS clássicos, o release R25-11 estabelece interfaces nativas para SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture p. 168). Dados de diagnóstico estruturados são modelados por meio de DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170). Para a manipulação de payloads complexos análogos a JSON, estão disponíveis classes type-safe semelhantes à STL, como DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture p. 172) e DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture p. 174).

Para transações SOVD avançadas e proteções, o módulo define papéis padronizados: grandes volumes de dados (como traces ou crash dumps) são transferidos via SovdBulkData ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification p. 321). O controle de acesso é realizado por meio de verificações de token e proximidade via SovdAuthorization ([SWS_DM_01489]) e SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), enquanto as verificações de serviço são autorizadas por meio de SovdServiceValidation ([SWS_DM_01823], [SWS_DM_01827]).

Comportamento em caso de erro

O gerenciamento de erros do módulo diag baseia-se no padrão AUTOSAR ara::core::Result<T, ErrorCode> e exclui totalmente estados de erro silenciosos. Os erros são divididos, de acordo com suas causas funcionais, em cinco domínios de erro especializados (ErrorDomain), os quais definem tanto códigos de erro quanto classes de exceção correspondentes:

• Erros gerais de diagnóstico: A DiagErrorDomain ([SWS_DM_00520], [SWS_DM_00524]) e a respectiva DiagException ([SWS_DM_00516]) sinalizam erros fundamentais de plataforma ou de configuração, tais como argumentos inválidos ou instâncias não inicializadas.
• UDS Negative Response Codes (NRC): Rejeições de protocolo UDS específicas de acordo com a ISO 14229 são mapeadas por meio da DiagUdsNrcErrorDomain ([SWS_DM_00532], [SWS_DM_00536]) e da DiagUdsNrcException ([SWS_DM_00528]).
• Erros de disponibilização de serviço: Caso a ativação ou desativação de interfaces de porta falhe, atua a DiagOfferErrorDomain ([SWS_DM_00992], [SWS_DM_01003]) com a DiagOfferException ([SWS_DM_00986]).
• Erros de notificação de eventos e monitores: Erros durante a notificação de status de monitores são indicados pela DiagReportingErrorDomain ([SWS_DM_00999], [SWS_DM_01004]) e DiagReportingException ([SWS_DM_00988]).
• Erros de protocolo SOVD: Erros em endpoints REST, conteúdos JSON ou no controle de acesso são reportados por meio da DiagSovdErrorDomain ([SWS_DM_01812], [SWS_DM_01816]) e da DiagSovdException ([SWS_DM_01808]).

No nível da camada de transporte, interrupções de transmissão, estouros de buffer ou quedas de conexão são reportados ao Diagnostic Management por meio do callback NotifyMessageFailure() ([SWS_DM_00310]). Isso permite que o módulo libere imediatamente os recursos alocados e, se aplicável, providencie mensagens de resposta negativa para o testador.

Diagrama de classes: arquitetura de domínios de erro e mapeamento dos códigos de erro e exceção padronizados no Diagnostic Management. Fontes: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]

Evidências mais detalhadas

A base normativa do módulo diag apoia-se em três documentos de especificação centrais da AUTOSAR Adaptive Platform:

• Arquitetura de interfaces e componentes: As interfaces de sistema, o modelo de daemon, bem como a separação entre as camadas de transporte e de aplicação estão estabelecidos em AUTOSAR_AP_EXP_SWArchitecture (AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168).
• Especificação do Diagnostic Management: As assinaturas de API detalhadas, os fluxos de sequência para tratamento de requisições, os ciclos de vida dos handlers de transporte e as regras de debouncing são definidos por AUTOSAR_SWS_Diagnostics (AUTOSAR_SWS_Diagnostics p. 128, AUTOSAR_SWS_Diagnostics p. 130, SWS_Diagnostics p. 225).
• Definições de manifesto e metamodelo: A vinculação declarativa de interfaces de porta, lógicas de validação e mapeamentos de serviço a componentes de software é regulamentada por AUTOSAR_AP_TPS_ManifestSpecification (AUTOSAR_AP_TPS_ManifestSpecification p. 311, AUTOSAR_AP_TPS_ManifestSpecification p. 321, AUTOSAR_AP_TPS_ManifestSpecification p. 341).