Standard Types (Std_Types)

O módulo std fornece, por meio de Std_Types.h, tipos e constantes padronizados para toda a plataforma, mas não contém código nem configuração. Central é Std_ReturnType (uint8) com E_OK e E_NOT_OK. Os módulos só podem definir valores próprios na faixa de 0x02–0x3F com prefixo de módulo, pois o bit 7 e o bit 8 são reservados para a RTE [SWS_Std_00011]. Além disso, o módulo fornece as constantes STD_HIGH/STD_LOW, STD_ON/STD_OFF e STD_ACTIVE/STD_IDLE, o tipo Std_VersionInfoType para consulta de versão, bem como tipos de transformer e de mensagem para a comunicação cliente-servidor. Na R20-11, o header também inclui Compiler.h SRS BSWGeneral p. 62.

mais ›

O módulo std é um header puramente de tipos. Por meio de Std_Types.h, ele disponibiliza tipos e símbolos, mas nenhuma função [SWS_Std_00005]. Na R20-11, o header inclui Platform_Types.h e Compiler.h e define Std_ReturnType, bem como os valores E_OK/E_NOT_OK e as constantes STD_*. Cada módulo que utiliza esses tipos o inclui SRS BSWGeneral p. 62. Configuração e tratamento de erros próprio não existem, segundo uma versão posterior da especificação; supõe-se que o mesmo se aplique à R20-11 (interpretação) SWS StandardTypes p. 27. Pergunta (aberta)

Diagrama de contexto: Std_Types.h como base de tipos comum para módulos BSW, CDDs, RTE e transformers. Fontes: SRS BSWGeneral p. 62, CDD Guideline p. 14

O núcleo do módulo é Std_ReturnType (uint8) com os valores E_OK (0) e E_NOT_OK (1). A faixa 0x02–0x3F está prevista para erros específicos de módulos com prefixo de módulo; o bit 7 e o bit 8 são definidos pela especificação da RTE [SWS_Std_00011]. Exemplos de tais extensões são CAN_BUSY e Csm_ReturnType BSWUML Guide p. 29. E_OK é protegido por STATUSTYPEDEFINED devido ao OSEK [SWS_Std_00006].

Diagrama de contexto (estrutura de tipos): valores padrão, faixa específica de módulos e bits reservados pela RTE de Std_ReturnType. Fontes: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15

Somam-se a isso três pares de constantes, cada um com 0x01u/0x00u: STD_HIGH/STD_LOW para níveis físicos, STD_ON/STD_OFF como chaves e STD_ACTIVE/STD_IDLE para estados lógicos ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType transporta o ID do fabricante, o ID do módulo e a versão de software para a função síncrona e reentrante <Ma>_GetVersionInfo [SWS_Std_00015].

Para a transformação de dados, std define dois tipos para erros de transformer: Std_TransformerError, uma estrutura composta por código de erro e classe de transformer, e Std_TransformerClass [SWS_Std_00021]. A RTE repassa esse erro por meio do parâmetro opcional transformerError SWS RTE p. 731. Para a comunicação cliente-servidor, Std_MessageTypeType e Std_MessageResultType codificam requisição/resposta e OK/ERROR. Um ponteiro de função do tipo Std_ExtractProtocolHeaderFieldsType lê ambos os valores a partir de um header de transformer [SWS_Std_91003]. Os tipos forward ainda são rascunho na R20-11 [SWS_Std_00029].

mais ›

Papel e limite do sistema: um header puramente de tipos sem comportamento em tempo de execução

O módulo std (Standard Types) não contém funções. Ele disponibiliza exclusivamente tipos e símbolos que estão disponíveis via Std_Types.h. Cada requisito do módulo menciona esse header como fonte de referência, como [SWS_Std_00005] e [SWS_Std_00015]. A especificação estabelece expressamente: o header não fornece código nem requer outros módulos BSW, não possui configuração e não possui tratamento de erros próprio SWS StandardTypes p. 27. Essas formulações originam-se da versão a partir da R23-11. Supõe-se que o mesmo se aplique à R20-11, pois os requisitos da R20-11 contêm exclusivamente definições de tipos e símbolos (interpretação). Pergunta Q-8e4c66ae80752d38 (aberta)

O objetivo é um acesso padronizado e em toda a plataforma a tipos padrão. O requisito de BSW para o header de tipos padrão exige, portanto: todo módulo que utiliza tipos inteiros AUTOSAR ou o tipo de retorno padrão inclui Std_Types.h SRS BSWGeneral p. 62. O tipo de retorno Std_ReturnType é expressamente compartilhado entre a RTE e módulos BSW [SWS_Std_00005]. Na metodologia, os tipos padrão são descritos adicionalmente como artefato ARXML «AUTOSAR Standard Types» Methodology p. 400.

Diagrama de contexto: Std_Types.h inclui headers de plataforma e de compilador e é utilizado por módulos BSW, CDDs, RTE e transformers como base de tipos comum. Fontes: SRS BSWGeneral p. 62, CDD Guideline p. 14, [SWS_Std_00005], [SWS_Std_00021]

Estrutura de Std_Types.h e integração na árvore de headers

Para a R20-11, o requisito de BSW estabelece o que Std_Types.h deve cumprir SRS BSWGeneral p. 62:

• incluir o header de tipos específico da plataforma Platform_Types.h,
• incluir o header específico do compilador Compiler.h,
• definir Std_ReturnType,
• estabelecer valores para E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE e STD_IDLE.

Na versão posterior do mesmo requisito, falta a inclusão de Compiler.h RS BSWGeneral p. 60. Isso condiz com o histórico de alterações: na R22-11, a abstração obsoleta de compilador foi removida de um requisito de Std, e NULL_PTR foi adicionado apenas com a R21-11 SWS StandardTypes p. 1. Para a R20-11, portanto, Compiler.h pertence à cadeia de inclusão, enquanto um NULL_PTR de Std_Types.h ainda não.

Uma particularidade diz respeito a E_OK. O símbolo já está definido no OSEK e deve, por isso, ser compartilhado. [SWS_Std_00006] prescreve uma proteção via STATUSTYPEDEFINED: dentro da proteção são definidos E_OK (0x00u) e StatusType; E_NOT_OK (0x01u) fica fora. O requisito de BSW contém a mesma nota de implementação com referência à ISO 17356-3 SRS BSWGeneral p. 62. A forma como um Complex Device Driver organiza o header em sua estrutura de includes é mostrada no diagrama da estrutura de headers de CDD CDD Guideline p. 14.

Std_ReturnType: faixa de valores, layout de bits e extensões específicas do módulo

Std_ReturnType é derivado de uint8. Os valores padrão são E_OK (0) e E_NOT_OK (1); a faixa 0x02–0x3F está disponível para erros específicos de usuário [SWS_Std_00005]. [SWS_Std_00011] detalha essa regra:

• Normalmente, o tipo é utilizado com E_OK ou E_NOT_OK.
• Se esses valores não forem suficientes, podem ser definidos valores próprios nos seis bits menos significativos, nomeados com o prefixo do módulo.
• O bit 7 e o bit 8 são reservados. Eles são definidos pela especificação da RTE, assim como o layout em geral.

O diagrama sobre o layout ilustra exatamente essa divisão SWS StandardTypes p. 15.

A especificação da RTE descreve Std_ReturnType como o tipo para valores de status e erro de funções de API; o valor 0 é reservado para «nenhum erro ocorrido» SWS RTE p. 675. Segundo o guia de modelagem BSW, ele é o único tipo de retorno permitido em operações cliente-servidor de Service-Interfaces BSWUML Guide p. 28. Um exemplo de extensão específica de módulo é CAN_BUSY (0x02) do driver CAN. Can_Write() fornece esse valor quando nenhum objeto de transmissão está livre SWS CANDriver p. 54.

Diagrama de contexto (estrutura de tipos): Std_ReturnType divide-se em valores padrão, uma faixa específica de módulo 0x02–0x3F e dois bits reservados pela RTE; extensões de módulo como Csm_ReturnType ou CAN_BUSY ocupam apenas a faixa livre. Fontes: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15, BSWUML Guide p. 29, SWS CANDriver p. 54

No modelo UML do BSW, tal extensão é modelada como a classe <Ma>_ReturnType com o estereótipo «extra_literals». Seus valores levam o prefixo do módulo e situam-se na faixa 0x02–0x3f BSWUML Guide p. 28. O exemplo Csm_ReturnType com CSM_E_BUSY, CSM_E_SMALL_BUFFER e CSM_E_ENTROPY_EXHAUSTION mostra o padrão BSWUML Guide p. 29. Se múltiplos módulos de uma pilha necessitarem da mesma extensão, ela não precisa ser definida separadamente para cada módulo BSWUML Guide p. 33. A versão R23-11 prevê para isso uma classe genérica com «generic_type», da qual as extensões específicas de módulo são derivadas TR BSWUML Guide p. 37.

Diagrama de atividades: decisão sobre se e como um módulo estende Std_ReturnType com valores próprios. Fontes: [SWS_Std_00011], BSWUML Guide p. 28, BSWUML Guide p. 33, TR BSWUML Guide p. 37

Constantes simbólicas para níveis, chaves e estados

Além dos valores de retorno, Std_Types.h define três pares de constantes. Todos os três utilizam os valores numéricos 0x01u e 0x00u, mas são comentados de forma diferente ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]):

Par	Valores	Significado de acordo com a definição
STD_HIGH / STD_LOW	0x01u / 0x00u	estado físico 5 V ou 3,3 V / 0 V
STD_ON / STD_OFF	0x01u / 0x00u	Ligado/Desligado, sem comentários adicionais
STD_ACTIVE / STD_IDLE	0x01u / 0x00u	estado lógico ativo / idle

Um utilizador típico de STD_HIGH/STD_LOW é o controlador DIO: o seu serviço de leitura devolve exatamente um destes dois níveis SWS DIO p. 37. STD_ON/STD_OFF servem como chaves de pré-compilação. Um exemplo é EEP_21_LDEXT_VERSION_INFO_API STD_ON na especificação geral do BSW SWS BSWGeneral p. 76, outro são as chaves opcionais de API do controlador GPT SWS GPT p. 48.

Consulta de versão via Std_VersionInfoType

Std_VersionInfoType é uma estrutura com os seguintes elementos: vendorID e moduleID (cada um uint16), bem como sw_major_version, sw_minor_version e sw_patch_version (cada um uint8). Através de <Module name>_GetVersionInfo() consulta-se, assim, a versão de um módulo BSW [SWS_Std_00015]. A especificação geral do BSW define para esta função SWS BSWGeneral p. 76:

• Opera de forma síncrona e é reentrante.
• Tem exatamente um parâmetro deste tipo.
• A sua disponibilidade é configurada por módulo no tempo de pré-compilação através de <Ma>VersionInfoApi.

A regra de nomenclatura GetVersionInfo cita o requisito do BSW com o exemplo Eep_21_LDExt_GetVersionInfo SRS BSWGeneral p. 60.

Existem implementações concretas em muitos módulos. Com a deteção de erros de desenvolvimento ativada, Can_GetVersionInfo rejeita um ponteiro nulo com CAN_E_PARAM_POINTER SWS CANDriver p. 57. Adc_GetVersionInfo verifica em conformidade por ADC_E_PARAM_POINTER SWS ADCDriver p. 80. O gestor NVRAM apresenta a chamada como uma troca síncrona simples entre o utilizador e o módulo SWS NvM p. 158.

Diagrama de sequência: um utilizador consulta a versão de um módulo de forma síncrona; em caso de ponteiro nulo e deteção de erros de desenvolvimento ativa, o módulo reporta um erro, caso contrário preenche Std_VersionInfoType. Fontes: [SWS_Std_00015], SWS BSWGeneral p. 76, SWS CANDriver p. 57, SWS NvM p. 158

Tipos de transformer e de mensagem para a transformação de dados

Para cadeias de transformers, std disponibiliza vários tipos. No R20-11, Std_TransformerError é uma estrutura composta por errorCode (uint8) e transformerClass do tipo Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass é derivado de uint8 e reconhece cinco valores [SWS_Std_00024]: STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03) e STD_TRANSFORMER_CUSTOM (0xFF).

A assinatura abreviada no diretório da API lista Std_TransformerError como typedef uint8. Determinante é, contudo, a definição da estrutura do requisito. Versões posteriores tipificam errorCode como um tipo próprio Std_TransformerErrorCode, cujo significado é definido por cadeia de transformers SWS StandardTypes p. 17.

O RTE passa este tipo como parâmetro OUT opcional transformerError para as suas APIs, por exemplo em Rte_Call SWS RTE p. 731, Rte_Read SWS RTE p. 720 e Rte_Result SWS RTE p. 750. As interfaces de plug-in descrevem-no como o erro ocorrido durante a execução da cadeia de transformers SWS RTE p. 969.

Std_TransformerForward e Std_TransformerForwardCode estão marcados no R20-11 como rascunho (draft). O código de encaminhamento conhece E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ e E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). Em versões posteriores, Rte_Send aceita um forwardedCode opcional deste tipo SWS RTE p. 704. Presumivelmente, serve para remapear erros de segurança (safety) recebidos durante o encaminhamento, tal como descrevem as funções de encaminhamento E2E SWS E2ELibrary p. 107 (interpretação). Pergunta Q-f0d374b3b793c868 (aberta) De acordo com o histórico de alterações, a estrutura Std_TransformerForward foi removida no R22-11 SWS StandardTypes p. 1.

Diagrama de sequência: além de Std_ReturnType, um erro de transformer chega ao SW-C como Std_TransformerError com código de erro e classe de transformer. Fontes: [SWS_Std_00021], [SWS_Std_00024], SWS RTE p. 731, SwCluster Guideline p. 245, SWS RTE p. 774

Para a comunicação cliente-servidor existem dois tipos de codificação, nos quais 0x02–0x3F estão respetivamente reservados para valores futuros:

• Std_MessageTypeType distingue entre pedido (STD_MESSAGETYPE_REQUEST, 0x00) e resposta (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
• Std_MessageResultType codifica o resultado de uma resposta: STD_MESSAGERESULT_OK (0x00) ou STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

O tipo de ponteiro de função Std_ExtractProtocolHeaderFieldsType descreve uma função síncrona e reentrante. Esta extrai ambos os valores do cabeçalho de protocolo de um transformer num buffer e fornece um Std_ReturnType [SWS_Std_91003]. Os transformers recebem opcionalmente tal ponteiro como argumento da sua função inversa ASWS TransformerGeneral p. 40. O transformer SOME/IP disponibiliza uma implementação adequada com SomeIpXf_ExtractProtocolHeaderFields SWS SOMEIPTransformer p. 61. Os perfis E2E 4m, 7m, 8m e 44m avaliam os dois valores nas suas funções de verificação SWS E2ELibrary p. 108.

Diagrama de sequência: para perfis PXXm, o transformer E2E extrai o tipo e o resultado da mensagem através do ponteiro de função transmitido e só prossegue a verificação com E_OK. Fontes: [SWS_Std_91003], ASWS TransformerGeneral p. 40, SWS E2ETransformer p. 45, SWS SOMEIPTransformer p. 61, SWS E2ELibrary p. 108

Comportamento em caso de erro

O próprio módulo não deteta nem reporta erros. A versão a partir do R23-11 constata que os tipos padrão não preveem tratamento de erros e não suportam eventos de segurança (security) SWS StandardTypes p. 27; o mesmo deverá aplicar-se ao R20-11 (interpretação). Pergunta (aberta) O comportamento de erro surge, portanto, apenas nos módulos que utilizam os tipos. O sinal básico é E_NOT_OK [SWS_Std_00006]; o seu significado concreto é definido pela respetiva API. Em Adc_ReadGroup significa "nenhum resultado disponível ou erro de desenvolvimento" SWS ADCDriver p. 61, em CanIf_Transmit "pedido de envio não aceite" SWS CANInterface p. 87.

Padrões de erro mais detalhados são reportados através de valores específicos de módulo no intervalo 0x02–0x3F [SWS_Std_00011], por exemplo CAN_BUSY SWS CANDriver p. 54. Os chamadores devem, portanto, contar com a possibilidade de um Std_ReturnType assumir mais do que dois valores. Um caso especial são os callbacks que são encaminhados como serviços AUTOSAR através do RTE: embora o chamador possa assumir E_OK, tais callbacks podem falhar, por exemplo, em sistemas particionados SWS BSWGeneral p. 69.

Em cadeias de transformers, um erro é reportado adicionalmente ao valor de retorno através de Std_TransformerError com código de erro e classe de transformer [SWS_Std_00021]. O RTE só gera o parâmetro opcional transformerError se o tratamento de erros transformerErrorHandling estiver configurado para a porta SWS RTE p. 774. Se a extração dos campos de cabeçalho falhar, SomeIpXf_ExtractProtocolHeaderFields fornece E_NOT_OK, por exemplo no caso de versão de protocolo incorreta ou buffer demasiado curto SWS SOMEIPTransformer p. 61. A lógica do transformer E2E só prossegue a verificação em caso de E_OK SWS E2ETransformer p. 45.

Evidências mais detalhadas

• [SWS_Std_00005], [SWS_Std_00006], [SWS_Std_00011]: tipo de retorno, valores padrão com proteção OSEK, disposição de bits e regra de extensão.
• [SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]: os três pares de constantes para níveis físicos, interruptores e estados lógicos.
• [SWS_Std_00015] juntamente com SWS BSWGeneral p. 76: estrutura de versão e regras para GetVersionInfo.
• [SWS_Std_00021], [SWS_Std_00024], [SWS_Std_00027], [SWS_Std_00029]: tipos de erro e de encaminhamento de transformer; os dois últimos são draft.
• [SWS_Std_91001], [SWS_Std_91002], [SWS_Std_91003], [SWS_Std_00017], [SWS_Std_00019]: tipos de mensagem e extração de cabeçalho para comunicação C/S.
• SRS BSWGeneral p. 62: conteúdo e cadeia de include de Std_Types.h no R20-11.
• SWS StandardTypes p. 27 e SWS StandardTypes p. 1: ausência de configuração e de tratamento de erros, bem como histórico de alterações (versões posteriores).