Default Error Tracer (DET)

O Default Error Tracer recebe centralizadamente mensagens de erro de módulos BSW e SW-Cs. Para isso, existem Det_ReportError para erros de desenvolvimento, Det_ReportRuntimeError para erros de tempo de execução e Det_ReportTransientFault para erros transientes, cada um com identificação de módulo, de instância, de API e de erro. O DET repassa cada mensagem a todos os hooks ou callouts configurados do integrador [SWS_Det_00501]. A operação é iniciada por Det_Init e Det_Start a partir do EcuM. A condição de contorno mais importante: em R20-11, Det_ReportError não retorna ao chamador, mas interrompe o fluxo do programa como uma asserção [SWS_Det_00009].

mais ›

O Default Error Tracer é o ponto central de coleta de mensagens de erro provenientes do software básico e de componentes de software. Ele oferece três serviços de notificação com estrutura idêntica e com os parâmetros ModuleId, InstanceId, ApiId e ErrorId ou FaultId: Det_ReportError para erros de desenvolvimento, Det_ReportRuntimeError para erros de tempo de execução e Det_ReportTransientFault para erros transientes ([SWS_Det_00009], [SWS_Det_01001], [SWS_Det_01003]). O EcuM coloca o DET em operação com Det_Init e, em seguida, Det_Start ([SWS_Det_00008], SWS DET Fig. 1 p. 34).

Diagrama de contexto: O DET recebe mensagens de módulos BSW e SW-Cs e as encaminha para hooks do integrador e, opcionalmente, para o Dlt. Fontes: SWS DET Fig. 2 p. 28, [SWS_Det_00202]

O DET não avalia as mensagens por conta própria. Cada serviço de notificação chama todos os hooks ou callouts configurados para ele (DetErrorHook, DetReportRuntimeErrorCallout, DetReportTransientFaultCallout), precisamente com os mesmos parâmetros da mensagem [SWS_Det_00501]. Por meio desse código do integrador, o DET também alcança o DEM ou a memória de erros. Ao fazer isso, os callouts devem se limitar a ações curtas e adequadas ErrorDescription p. 10.

As SW-Cs realizam notificações por meio da interface cliente-servidor DETService. A RTE complementa ModuleId e InstanceId como “port defined argument values” a partir da configuração do DET; a SW-C sempre recebe E_OK de volta ([SWS_Det_00203], [SWS_Det_00204]).

Para situações de erro, a forma como os três serviços retornam é decisiva. Det_ReportError não retorna em R20-11: após os hooks, o fluxo de controle é interrompido, como em uma asserção ([SWS_Det_00009], RS BSWGeneral p. 33). As notificações de tempo de execução, por sua vez, retornam com E_OK. As notificações transientes repassam o valor do callout; sem callout, E_OK SWS DET Fig. 6 p. 36. Os erros transientes são eliminados a partir de R24-11, e as chamadas ao Dlt a partir de R25-11 SWS DET p. 1.

Diagrama de sequência: Em caso de erro de desenvolvimento, o DET chama todos os hooks configurados e, em seguida, é interrompido, sem retornar ao emissor da notificação. Fontes: SWS DET Fig. 9.2 p. 34, [SWS_Det_00009]

mais ›

Papel do Default Error Tracer no limite do sistema

O Default Error Tracer (DET) é o ponto central de coleta para o qual módulos do software básico e componentes de software relatam erros detectados. Em R20-11, ele oferece três serviços de notificação com estrutura idêntica para essa finalidade: Det_ReportError para erros de desenvolvimento [SWS_Det_00009], Det_ReportRuntimeError para erros de tempo de execução [SWS_Det_01001] e Det_ReportTransientFault para erros transientes [SWS_Det_01003]. Somam-se a isso os serviços administrativos Det_Init, Det_Start e Det_GetVersionInfo ([SWS_Det_00008], [SWS_Det_00010], [SWS_Det_00011]). O DET não avalia o conteúdo das mensagens por conta própria. Ele notifica os error hooks configurados a cada mensagem recebida SWS DET p. 16.

Externamente, o DET possui conexões reduzidas. Como única interface esperada, a especificação menciona o encaminhamento opcional para o Dlt por meio de Dlt_DetForwardErrorTrace a partir de Dlt_Det.h ([SWS_Det_00211], SWS DET Fig. 2 p. 28). O DET só alcança o DEM e a RTE por meio de código específico do integrador nos callouts ErrorDescription p. 10.

Diagrama de contexto: O DET recebe mensagens de módulos BSW e, via RTE, de SW-Cs. Ele é inicializado pelo EcuM e repassa mensagens apenas para o código configurado do integrador e, opcionalmente, para o Dlt. Fontes: SWS DET Fig. 2 p. 28, [SWS_Det_00202], [SWS_Det_00211], ErrorDescription p. 10

Inicialização: Inicialização e partida pelo EcuM

O ECU State Manager inicializa o DET com Det_Init (Service ID 0x00). Ao fazer isso, ele passa um ponteiro para o conjunto de configuração selecionado do tipo Det_ConfigType, cujo conteúdo é específico da implementação ([SWS_Det_00008], [SWS_Det_00210]). Em seguida, Det_Start (Service ID 0x02) inicia o tracer [SWS_Det_00010]. Ambos os serviços são síncronos e não reentrantes. O diagrama de R20-11 mostra as duas chamadas sucessivas a partir do EcuM SWS DET Fig. 1 p. 34. O EcuM lista Det_Init e Det_ReportError correspondentemente como interfaces opcionais SWS EcuM p. 142.

A especificação não justifica por que a inicialização e a partida são separadas. Interpretação: a divisão em duas partes provavelmente permite inicializar o DET muito cedo na inicialização e liberar a operação regular apenas em uma etapa posterior [SWS_Det_00010]. Pergunta Q-fee4462bdf189dcf (aberta)

Diagrama de sequência: O EcuM chama primeiro de forma síncrona Det_Init com o ponteiro de configuração e, depois, Det_Start. Fontes: SWS DET Fig. 1 p. 34, [SWS_Det_00008], [SWS_Det_00010]

Três vias de notificação e seus identificadores

Todos os três serviços de notificação possuem a mesma estrutura de parâmetros:

• ModuleId (uint16);
• InstanceId (uint8), o valor 0 no caso de módulos de instância única;
• ApiId (uint8);
• ErrorId ou FaultId (uint8).

Os identificadores de API e de erro são definidos pela SWS do respectivo módulo emissor ([SWS_Det_00009], [SWS_Det_01001], [SWS_Det_01003]). O ID do módulo provém da lista de módulos do software básico. O software básico utiliza apenas a faixa de 0..255 disso EXP LSA p. 157.

Qual via é a correta decorre da classificação de erros. Pré-condições fundamentais violadas são erros de desenvolvimento e são tratadas como uma asserção; exemplos são erros de software, integração incorreta ou configuração inválida. Os erros restantes são erros de tempo de execução ou de produção EXP LSA p. 154. Se a detecção de erros de desenvolvimento estiver configurada, os módulos BSW relatam erros de desenvolvimento com seu ID de módulo atribuído via Det_ReportError SWS BSWGeneral p. 57. Uma chave de pré-processador como SPI_DEV_ERROR_DETECT habilita ou desabilita a chamada EXP LSA p. 113.

Diagrama de atividades: Se uma pré-condição fundamental for violada, um erro de desenvolvimento é relatado via Det_ReportError. Caso contrário, a relevância de diagnóstico decide entre erro de produção e erro de tempo de execução (Det_ReportRuntimeError). Fontes: EXP LSA p. 154, [SWS_Det_00009], [SWS_Det_01001]

Erros de tempo de execução são relatados, por exemplo, pelo driver ADC com ADC_E_BUSY ou pelo Dds no caso de mensagens descartadas, em cada caso via Det_ReportRuntimeError (SWS Adc p. 95, SWS Dds p. 53). Um módulo BSW descreve suas necessidades com o tipo de ServiceNeeds ErrorTracerNeeds. Ele reconhece as funções Det_ReportError, Det_ReportRuntimeError e Det_ReportTransientFault TPS BSWMDT p. 266.

Hooks e callouts como ponte para o código do integrador

Cada chamada de Det_ReportError chama todas as funções configuradas em DetErrorHook. Da mesma forma, Det_ReportRuntimeError e Det_ReportTransientFault chamam todos os callouts de DetReportRuntimeErrorCallout ou DetReportTransientFaultCallout, respectivamente [SWS_Det_00501]. Hooks e callouts possuem a assinatura do serviço acionador e recebem os mesmos parâmetros ([SWS_Det_00181], [SWS_Det_00184], [SWS_Det_00187], SWS DET p. 16). A interface de hook <User_Error_Hooks> possui o Service ID 0x10. Ela é síncrona e reentrante e sempre retorna E_OK SWS DET p. 25.

O que os callouts fazem é decisão do integrador. No caso de erros de tempo de execução e transientes, eles devem se limitar a poucas ações: armazenar o evento, chamar o DEM ou executar outra ação curta e adequada ErrorDescription p. 10. Após uma chamada de Det_ReportRuntimeError, o DET sempre retorna com E_OK, estejam os callouts configurados ou não (SWS DET Fig. 4 p. 35, SWS DET Fig. 5 p. 35).

Diagrama de sequência: Det_ReportRuntimeError chama todos os callouts configurados e retorna, em qualquer caso, com E_OK ao emissor da notificação. Fontes: SWS DET Fig. 4 p. 35, SWS DET Fig. 5 p. 35, [SWS_Det_00501]

No caso de Det_ReportTransientFault, por outro lado, o DET repassa diretamente o valor de retorno do callout ao emissor da notificação. Sem callout, ele retorna E_OK (SWS DET Fig. 6 p. 36, SWS DET Fig. 7 p. 36). Para múltiplos callouts, uma versão posterior descreve uma operação lógica OU dos valores de retorno: E_OK só é retornado se todos os callouts fornecerem E_OK. Presume-se que essa regra já se aplique a R20-11 SWS DET p. 24. Pergunta (aberta)

Diagrama de sequência: Det_ReportTransientFault repassa os valores de retorno dos callouts ao emissor da notificação; sem callout, retorna E_OK. A operação OU no caso de múltiplos callouts é indicada como uma suposição. Fontes: SWS DET Fig. 6 p. 36, SWS DET Fig. 7 p. 36, SWS DET p. 24

Conexão de componentes de software por meio de portas de serviço

As SW-Cs acessam o DET por meio da interface cliente-servidor DETService. Suas operações chamam Det_ReportError ou a notificação de tempo de execução com o ID de módulo da porta [SWS_Det_00202]. ModuleId e InstanceId não são passados pela própria SW-C. A RTE os complementa como “port defined argument values”, cujos valores provêm de DetModuleId e DetInstanceId da configuração do DET ([SWS_Det_00204], [SWS_Det_00205], [SWS_Det_00206]). Para SW-Cs, ApiId e ErrorId não são padronizados e podem ser atribuídos livremente na faixa de 0x00..0xFF. O valor de retorno é sempre E_OK [SWS_Det_00203]. A interface de porta utiliza os tipos de dados AUTOSAR uint8 e uint16 [SWS_Det_00200].

Diagrama de sequência: A SW-C passa apenas ApiId e ErrorId. A RTE complementa ModuleId e InstanceId a partir da configuração; o retorno é E_OK. Fontes: [SWS_Det_00202], [SWS_Det_00203], [SWS_Det_00204], SWS DET Fig. 3 p. 33

Configuração das notificações

As funções de notificação localizam-se no contêiner opcional DetNotification (multiplicidade 0..1). Ele contém as listas DetErrorHook e DetReportRuntimeErrorCallout (0..* cada). DetErrorHook é configurado em tempo de pré-compilação e requer o tipo de função Std_ReturnType (*f)(uint16, uint8, uint8, uint8) SWS DET p. 37. Em R20-11, acrescenta-se DetReportTransientFaultCallout [SWS_Det_00501]. O diagrama de parâmetros mostra ainda o contêiner obrigatório DetGeneral com DetVersionInfoApi e DetForwardToDlt SWS DET (alt) Fig. 6 p. 43. A partir de DetConfigSet/DetModule e DetModuleInstance, a configuração forma as portas Det_{Name} juntamente com a identificação de módulo e de instância [SWS_Det_00205].

Comportamento em caso de erro

Erros de desenvolvimento são tratados como assertions. Após a chamada dos hooks configurados, o fluxo de controle normal não é continuado, e o DET interrompe a execução, por exemplo, por meio de um loop infinito ou de uma instrução de parada RS BSWGeneral p. 33. A isso corresponde a entrada para Det_ReportError em R20-11 sob Sync/Async: «Not Applicable: The function never returns» [SWS_Det_00009]. Os diagramas mostram este HALT com e sem hook configurado (SWS DET Fig. 9.2 p. 34, SWS DET Fig. 9.3 p. 35).

Diagrama de sequência: um módulo BSW detecta um erro de desenvolvimento e chama Det_ReportError. O DET chama todos os hooks configurados e para em seguida, sem retornar ao emissor da notificação. Fontes: SWS DET Fig. 9.2 p. 34, SWS DET Fig. 9.3 p. 35, [SWS_Det_00009], [SWS_Det_00501]

Alguns diagramas divergem disso. Um diagrama de sequência observa que o comportamento síncrono ou assíncrono depende da implementação e desenha um retorno ao chamador SWS DET Fig. 5 p. 36. O diagrama de Dio também mostra um retorno após Det_ReportError SWS Dio Fig. 5 p. 41. Normativo para R20-11 é [SWS_Det_00009]. Um esclarecimento da indicação Sync/Async seguiu apenas com R21-11 SWS DET p. 1.

Erros de tempo de execução e transitórios não interrompem o fluxo do programa: o DET retorna ao emissor da notificação com um valor de retorno ([SWS_Det_01001], [SWS_Det_01003]). O próprio DET conhece apenas um erro de desenvolvimento próprio. DET_E_PARAM_POINTER (0x01) ocorre quando Det_GetVersionInfo é chamado com um ponteiro nulo [SWS_Det_00301]. Uma versão posterior estabelece que esse erro é reportado a todos os callouts configurados. Presumivelmente, isso também se aplica a R20-11 SWS DET p. 18. Pergunta Q-3a7f5865d61186d4 (aberta)

Evidências mais detalhadas

• [SWS_Det_00009]: assinatura de Det_ReportError, ID de serviço 0x01, não retorna.
• [SWS_Det_01001], [SWS_Det_01003]: mensagens de tempo de execução e transitórias com os IDs de serviço 0x04 e 0x05.
• [SWS_Det_00501]: obrigação de chamar todos os hooks e callouts configurados.
• [SWS_Det_00181], [SWS_Det_00184], [SWS_Det_00187]: assinaturas dos hooks e callouts com os IDs de serviço 0x10, 0x11 e 0x12.
• [SWS_Det_00202] a [SWS_Det_00206]: modelo de service port para SW-Cs.
• [SWS_Det_00008], [SWS_Det_00010], [SWS_Det_00210]: inicialização e tipo de configuração.
• [SWS_Det_00211], [SWS_Det_00301]: encaminhamento Dlt e erro de desenvolvimento próprio.

Releases posteriores alteram o escopo funcional. Uma versão de R23-11/R24-11 marca Det_ReportTransientFault como OBSOLETE SWS DET p. 24. De acordo com o histórico de alterações, erros transitórios são eliminados com R24-11 e as chamadas Dlt com R25-11 SWS DET p. 1. Em R20-11, ambas as funções ainda fazem parte da especificação ([SWS_Det_01003], [SWS_Det_00211]).