Platform Types (Platform_Types)

Platform_Types.h disponibiliza os tipos básicos dependentes de plataforma da Classic Platform: tipos inteiros de largura fixa de uint8 a sint64, tipos *_least otimizados, float32/float64, boolean com TRUE/FALSE, bem como os ponteiros de buffer VoidPtr e ConstVoidPtr. Adicionalmente, CPU_TYPE, CPU_BIT_ORDER e CPU_BYTE_ORDER identificam a largura de registrador e o endianness do destino [SWS_Platform_00046]. boolean pode ser utilizado apenas com TRUE e FALSE e sem operadores aritméticos ou bit a bit [SWS_Platform_00034]. O cabeçalho não pode ser estendido, caso contrário perde-se a conformidade com o AUTOSAR.

mais ›

Platform_Types.h é a base de tipos dependente de plataforma da Classic Platform. O cabeçalho encapsula larguras de palavra e endianness do destino sob nomes padronizados e não pode ser estendido, pois qualquer extensão anula a conformidade com o AUTOSAR [SWS_Platform_00002]. Na visão de modelo, os tipos residem sob um caminho fixo como /AUTOSAR_Platform/ImplementationDatatypes/uint8 TPS StandardizationTemplate p. 77.

O cabeçalho disponibiliza os seguintes grupos de tipos:

• Tipos inteiros de largura fixa de uint8 a sint64 [SWS_Platform_00013] [SWS_Platform_00067]; para tipos com sinal, aplica-se exclusivamente o complemento de dois [SWS_Platform_00061].
• Tipos otimizados *_least com largura mínima, por exemplo para contadores de laço [SWS_Platform_00020].
• float32 e float64 conforme IEEE 754-2008 [SWS_Platform_00041].
• Os ponteiros de buffer VoidPtr para dados destinados ao chamador e ConstVoidPtr para dados destinados ao chamado [SWS_Platform_91001] [SWS_Platform_91002].

Diagrama de atividades: a escolha do tipo de plataforma adequado segue as perguntas ponteiro de buffer, valor booleano, ponto flutuante, largura mínima ou exata. Fontes: [SWS_Platform_91001], [SWS_Platform_00026], SWS PlatformTypes p. 17.

boolean é implementado em R20-11 como o tipo inteiro sem sinal suportado nativamente mais curto, em regra de 8 bits [SWS_Platform_00027]. Versões posteriores divergem disso e utilizam _Bool SWS PlatformTypes p. 18. O tipo precisa ser apto a ponteiros [SWS_Platform_00060] e só pode ser utilizado com TRUE e FALSE. Operadores aritméticos e bit a bit são proibidos [SWS_Platform_00034], e redefinições dos símbolos devem ser evitadas por meio de verificação condicional [SWS_Platform_00054].

Por plataforma, devem ser definidos adicionalmente três símbolos: CPU_TYPE para a largura de registrador [SWS_Platform_00045], CPU_BIT_ORDER com MSB_FIRST ou LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049] e CPU_BYTE_ORDER com HIGH_BYTE_FIRST ou LOW_BYTE_FIRST [SWS_Platform_00050] [SWS_Platform_00051]. Nomes de bits e significância não podem ser misturados, pois o MSB fica sempre à esquerda no acumulador SWS PlatformTypes p. 15. Interpretação: o módulo não conhece erros de tempo de execução; atribuições incorretas manifestam-se apenas na integração ou no teste de conformidade. Pergunta (aberta)

Diagrama de atividades: largura de registrador, ordem de bits e ordem de bytes do destino são mapeadas, cada uma, exatamente para um valor de símbolo. Fontes: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00050].

mais ›

Papel de Platform_Types.h: a base de tipos dependente de plataforma

O módulo não é um componente executável, mas sim um cabeçalho. Todos os tipos e símbolos especificados estão «Available via Platform_Types.h», como uint8 [SWS_Platform_00013] ou CPU_TYPE [SWS_Platform_00064]. O cabeçalho oculta as características do microcontrolador de destino e do compilador sob nomes padronizados: larguras de palavra, ordem de bits e ordem de bytes. Com isso, ele pertence à abstração de microcontrolador com interface padronizada para camadas superiores exigida em SRS_BSW_00161 SRS BSWGeneral p. 88. É exatamente a esse requisito upstream que remetem também as regras sobre ordem de bytes SWS PlatformTypes p. 16.

O limite do sistema é estreitamente definido. O cabeçalho não pode ser estendido, pois qualquer extensão anula a conformidade com o AUTOSAR [SWS_Platform_00002]. Tipos de retorno para sucesso ou falha de uma chamada de API residem, por outro lado, em Std_Types.h SRS BSWGeneral p. 68. Na visão de modelo, os tipos de plataforma estão depositados como blueprints, por exemplo sob /AUTOSAR/Platform/ImplementationDatatypes_Blueprint/uint8. Eles são implementados sob /AUTOSAR_Platform/ImplementationDatatypes/uint8, de modo que fornecedores de componentes os alcancem através de um caminho previsível TPS StandardizationTemplate p. 77.

Diagrama de contexto: a plataforma de destino determina a definição de Platform_Types.h, cujos tipos residem sob um caminho fixo na visão de modelo e são utilizados por numerosos módulos BSW. Os exemplos de usuários provêm de releases posteriores. Fontes: [SWS_Platform_00038], TPS StandardizationTemplate p. 77, SWS BFXLibrary p. 19, SWS CRCLibrary p. 41, SWS BSWMulticoreLibrary p. 16, SWS KeyManager p. 111, SWS CANStateManager p. 83.

Tipos inteiros e de ponto flutuante com largura garantida

O núcleo do módulo são tipos sem sinal e com sinal de largura fixa de 8 a 64 bits, bem como dois tipos de ponto flutuante. Normativamente, os requisitos definem largura e faixa de valores, como «32 bit unsigned» para uint32 [SWS_Platform_00015]. Os typedefs em C no catálogo de APIs, por exemplo typedef unsigned long uint32;, devem ser interpretados como um mapeamento típico que pode variar conforme o compilador (interpretação). Pergunta Q-d0ca377fc1abd98a (aberta)

Tipo	Largura / Formato	Gama de valores	Referência
uint8	8 bits, sem sinal	0..255	[SWS_Platform_00013]
uint16	16 bits, sem sinal	0..65535	[SWS_Platform_00014]
uint32	32 bits, sem sinal	0..4294967295	[SWS_Platform_00015]
uint64	64 bits, sem sinal	0..18446744073709551615	[SWS_Platform_00066]
sint8	8 bits, com sinal	-128..+127	[SWS_Platform_00016]
sint16	16 bits, com sinal	-32768..+32767	[SWS_Platform_00017]
sint32	32 bits, com sinal	-2147483648..+2147483647	[SWS_Platform_00018]
sint64	64 bits, com sinal	-9223372036854775808..9223372036854775807	[SWS_Platform_00067]
float32	IEEE 754-2008 binary32	-3.4028235e+38..+3.4028235e+38	[SWS_Platform_00041]
float64	IEEE 754-2008 binary64	±1.7976931348623157e+308	[SWS_Platform_00042]

Para os tipos com sinal, o AUTOSAR suporta exclusivamente aritmética de complemento de dois no compilador e no destino. Disso decorrem as faixas de valores assimétricas da tabela [SWS_Platform_00061]. Outras especificações pressupõem esses tipos consistentemente. A biblioteca de CRC define, por exemplo, uint8 Crc_CalculateCRC8(const uint8*, uint32, uint8, boolean) SWS CRCLibrary p. 41. O COM precisa suportar a conversão de endianness para uint16 até float64 RS COM p. 14. Ambas as passagens provêm de releases posteriores e ilustram apenas o uso.

Tipos otimizados *_least para contadores e estados

Além dos tipos com largura exata, o módulo define seis tipos otimizados. Eles garantem apenas uma largura mínima e são derivados de uint e sint, respectivamente:

• uint8_least [SWS_Platform_00020]
• uint16_least [SWS_Platform_00021]
• uint32_least [SWS_Platform_00022]
• sint8_least [SWS_Platform_00023]
• sint16_least [SWS_Platform_00024]
• sint32_least [SWS_Platform_00025]

A implementação pode, portanto, escolher uma representação mais ampla. As assinaturas do catálogo mapeiam todos os seis tipos para unsigned int e signed int, respectivamente [SWS_Platform_00020].

Como exemplos de aplicação, a especificação cita contadores de laço (no máximo 124 iterações ⇒ uint8_least) e argumentos de switch (17 estados ⇒ uint8_least). Para detalhes, ela remete ao capítulo «AUTOSAR Integer Data Types» dos requisitos gerais de BSW SWS PlatformTypes p. 17.

Utilizar boolean, TRUE e FALSE em conformidade com as regras

boolean tem a faixa de valores FALSE = 0 e TRUE = 1 e só pode ser utilizado juntamente com essas definições [SWS_Platform_00026]. Para R20-11, aplica-se: boolean é implementado como um tipo inteiro sem sinal com o menor comprimento em bits suportado nativamente pela plataforma, em regra 8 bits [SWS_Platform_00027]. Uma passagem documental de R24-11/R25-11 formula o mesmo identificador de maneira diferente: nela, boolean é implementado através do tipo C99 _Bool, e o AUTOSAR não define mais o tamanho exato SWS PlatformTypes p. 18. Para R20-11, essa versão posterior não é normativa.

boolean precisa, além disso, ser mapeado para um tipo para o qual ponteiros possam apontar, a fim de permitir a passagem de parâmetros via API. Os tipos eficientes de bits de determinados hardwares não são aptos a ponteiros e, portanto, são desconsiderados [SWS_Platform_00060]. Para os símbolos TRUE e FALSE, aplicam-se três regras:

• Eles são definidos com proteção #ifndef como 1 e 0 [SWS_Platform_00056].
• Se o compilador já fornecer os símbolos, deve-se evitar uma redefinição por meio de uma verificação condicional [SWS_Platform_00054].
• Eles devem ser utilizados somente em conjunto com boolean [SWS_Platform_00055].

Nas atribuições a variáveis boolean, operadores aritméticos e bit a bit são proibidos: +, ++, -, --, *, /, %, <<, >>, ~ e &. É permitida apenas a atribuição de TRUE ou FALSE, bem como de resultados de relações, operações lógicas e verificações de (des)igualdade. A comparação é feita apenas com == ou != contra TRUE/FALSE ou através de if (var) ou if (!var) [SWS_Platform_00034]. Os módulos consumidores seguem este padrão. Assim, Bfx_GetBit retorna o resultado de um teste de bit expressamente como TRUE ou FALSE SWS BFXLibrary p. 19.

Diagrama de atividades: Para variáveis boolean, são permitidas apenas as formas de atribuição e comparação listadas; operadores aritméticos e de bits não são permitidos. Fontes: [SWS_Platform_00034], [SWS_Platform_00026]

Ponteiros de buffer não tipados: VoidPtr e ConstVoidPtr

Os dois tipos de ponteiro diferem na direção do fluxo de dados:

• VoidPtr é um void* para buffers que contêm dados retornados ao chamador [SWS_Platform_91001].
• ConstVoidPtr é um const void* para buffers que são passados ao chamado [SWS_Platform_91002].

A direção do fluxo de dados já está, portanto, implícita no nome do tipo SWS PlatformTypes p. 27 SWS PlatformTypes p. 28.

Como isso se apresenta em interfaces é demonstrado pelo Key Manager. KeyMServiceCertificateByCertId passa RequestData como ConstVoidPtr juntamente com um comprimento do tipo uint32. A resposta é recebida por ResponseData do tipo VoidPtr; ResponseDataLength (INOUT) indica, nesse caso, o comprimento de buffer disponível SWS KeyManager p. 111. Outros exemplos:

• KeyM_CertDataType referencia dados de certificado na área de dados local do chamador através de um VoidPtr SWS KeyManager p. 97.
• O Crypto Service Manager passa o seed como ConstVoidPtr SWS CryptoServiceManager p. 124.

Em todos os três exemplos, o comprimento é transportado como um parâmetro uint32 próprio ou como um elemento de estrutura próprio, porque um ponteiro não tipado não carrega informações de comprimento.

Diagrama de sequência: Em uma chamada de serviço, o ConstVoidPtr transporta a requisição para o chamado; o VoidPtr recebe a resposta para o chamador. Fontes: SWS KeyManager p. 111, [SWS_Platform_91001], [SWS_Platform_91002]

Diagrama de atividades: A escolha do tipo segue as questões de ponteiro de buffer, valor booleano, número de ponto flutuante, largura mínima ou exata. Fontes: [SWS_Platform_91001], [SWS_Platform_91002], [SWS_Platform_00026], [SWS_Platform_00041], [SWS_Platform_00020], SWS PlatformTypes p. 17

Identificação da plataforma: CPU_TYPE, CPU_BIT_ORDER, CPU_BYTE_ORDER

Para cada plataforma, três propriedades devem ser definidas no header:

• Largura de registrador via CPU_TYPE [SWS_Platform_00044], com um dos valores CPU_TYPE_8, CPU_TYPE_16, CPU_TYPE_32 ou CPU_TYPE_64 [SWS_Platform_00045] [SWS_Platform_00064].
• Ordem dos bits no nível de registrador via CPU_BIT_ORDER [SWS_Platform_00043].
• Ordem dos bytes na memória via CPU_BYTE_ORDER [SWS_Platform_00046].

Ambos os símbolos de ordem são #defines que carregam exatamente um dos valores permitidos [SWS_Platform_00038] [SWS_Platform_00039].

Diagrama de atividades: Ao portar para um alvo, a largura de registrador, a ordem dos bits e a ordem dos bytes são determinadas e mapeadas, cada uma, para exatamente um valor de símbolo. Fontes: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00049], [SWS_Platform_00050], [SWS_Platform_00051]

Para a ordem de bits big-endian, aplica-se CPU_BIT_ORDER = MSB_FIRST; para little-endian, LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049]. Os nomes dos bits e o seu peso devem ser estritamente separados. O MSB fica no acumulador sempre na extremidade esquerda, independentemente do tipo de CPU. Em arquiteturas Motorola (Big Endian Bit Order), o Bit0 designa o bit mais significativo; em todas as outras, o menos significativo SWS PlatformTypes p. 15 SWS PlatformTypes Fig. 7.1 p. 14.

Diagrama estrutural conforme a Fig. 7.1: O peso dos bits do registrador é fixo; apenas a numeração de Bit0 depende de CPU_BIT_ORDER. Fontes: SWS PlatformTypes Fig. 7.1 p. 14, SWS PlatformTypes p. 15

Para a ordem de bytes big-endian, aplica-se CPU_BYTE_ORDER = HIGH_BYTE_FIRST: o byte mais significativo de um valor de 16 bits localiza-se no endereço n, e o menos significativo em n+1. Para little-endian, aplica-se LOW_BYTE_FIRST com ocupação inversa [SWS_Platform_00050] [SWS_Platform_00051]. As designações Byte0 e Byte1 servem apenas para ilustração e podem divergir na documentação de referência de um fabricante SWS PlatformTypes p. 16.

Diagrama estrutural conforme a Fig. 7.2/7.3: O mesmo uint16 é mapeado nos endereços n e n+1 com bytes invertidos, dependendo de CPU_BYTE_ORDER. Fontes: SWS PlatformTypes Fig. 7.2 p. 16, SWS PlatformTypes Fig. 7.3 p. 15, [SWS_Platform_00039]

O motivo pelo qual essas indicações são necessárias é fundamentado por outras especificações. A representação dos dados na memória depende fortemente da arquitetura do processador e das configurações do compilador. Por isso, o SOME/IP exige um algoritmo de serialização que realize a conversão para uma representação de rede comum RS SOMEIPProtocol p. 21. Presume-se que tais conversões em implementações se baseiem em CPU_BYTE_ORDER; no entanto, o payload não comprova isso expressamente. Pergunta Q-87e212e9eb2a2047 (aberta)

Comportamento em caso de erro

Interpretação: Como Platform_Types.h fornece apenas tipos e símbolos, o módulo não possui erros de tempo de execução nem códigos de erro. Pergunta Q-e504d08b84d7ff70 (aberta) Padrões de erro manifestam-se durante a compilação, integração ou teste de conformidade. Os requisitos nomeiam as causas típicas [SWS_Platform_00002]:

• Extensões do header são inadmissíveis; qualquer extensão anula a conformidade [SWS_Platform_00002].
• Definições duplicadas de TRUE/FALSE em caso de suporte existente pelo compilador devem ser evitadas por meio de uma verificação condicional [SWS_Platform_00054] [SWS_Platform_00056].
• Símbolos de ordem atribuídos incorretamente violam de [SWS_Platform_00048] a [SWS_Platform_00051]. A mistura dos nomes de bits da documentação do fabricante com o peso SWS PlatformTypes p. 15 é particularmente propensa a erros.
• Um boolean incapaz de atuar como ponteiro viola [SWS_Platform_00060], porque os parâmetros não podem então ser passados via API.
• Operações aritméticas ou de bits sobre boolean são inadmissíveis, assim como outras formas de comparação que não as listadas [SWS_Platform_00034].
• Código que pressupõe complemento de um ou faixas de valores simétricas não é coberto, uma vez que apenas o complemento de dois é suportado [SWS_Platform_00061].
• Na mudança de release, a especificação para boolean deve ser observada: o R20-11 [SWS_Platform_00027] e versões posteriores SWS PlatformTypes p. 18 diferem entre si. O código que pressupõe um tamanho fixo de boolean deve, portanto, ser verificado antes da mudança.

Evidências mais detalhadas

• Tipos inteiros de largura fixa: [SWS_Platform_00013] a [SWS_Platform_00018], bem como [SWS_Platform_00066] e [SWS_Platform_00067], definem a largura e a faixa de valores.
• Tipos otimizados: [SWS_Platform_00020] a [SWS_Platform_00025], com exemplos de uso em SWS PlatformTypes p. 17.
• Tipos de ponto flutuante conforme IEEE 754-2008: [SWS_Platform_00041], [SWS_Platform_00042].
• Valores booleanos: [SWS_Platform_00026], [SWS_Platform_00027], [SWS_Platform_00034], [SWS_Platform_00055], [SWS_Platform_00056], [SWS_Platform_00060].
• Ponteiros de buffer: [SWS_Platform_91001], [SWS_Platform_91002], com aplicação em SWS KeyManager p. 111.
• Símbolos de plataforma: [SWS_Platform_00043] a [SWS_Platform_00046], [SWS_Platform_00064], [SWS_Platform_00038], [SWS_Platform_00039]. A atribuição de endianness é regulada por [SWS_Platform_00048] a [SWS_Platform_00051], ilustrada em SWS PlatformTypes p. 16.
• Regras gerais: [SWS_Platform_00002] (sem extensões), [SWS_Platform_00054] (sem redefinições), [SWS_Platform_00061] (complemento de dois). [SWS_Platform_00063] declara um grupo de requisitos como não aplicável; quais são os referidos não fica evidente no texto abreviado.