Platform Types (Platform_Types)

Platform_Types.h proporciona los tipos básicos dependientes de la plataforma de la Classic Platform: tipos enteros de ancho fijo desde uint8 hasta sint64, tipos *_least optimizados, float32/float64, boolean con TRUE/FALSE, así como los punteros de búfer VoidPtr y ConstVoidPtr. Además, CPU_TYPE, CPU_BIT_ORDER y CPU_BYTE_ORDER identifican el ancho de registro y la endianness del destino [SWS_Platform_00046]. boolean solo debe usarse con TRUE y FALSE y sin operadores aritméticos o de bits [SWS_Platform_00034]. La cabecera no debe ampliarse; de lo contrario, se pierde la conformidad con AUTOSAR.

más ›

Platform_Types.h es la base de tipos dependiente de la plataforma de la Classic Platform. La cabecera encapsula los anchos de palabra y la endianness del destino tras nombres uniformes y no debe ampliarse, ya que cualquier ampliación anula la conformidad con AUTOSAR [SWS_Platform_00002]. En la vista del modelo, los tipos se ubican bajo una ruta fija como /AUTOSAR_Platform/ImplementationDatatypes/uint8 TPS StandardizationTemplate p. 77.

La cabecera proporciona los siguientes grupos de tipos:

• Tipos enteros de ancho fijo desde uint8 hasta sint64 [SWS_Platform_00013] [SWS_Platform_00067]; para tipos con signo solo se aplica el complemento a dos [SWS_Platform_00061].
• Tipos optimizados *_least con ancho mínimo, por ejemplo para contadores de bucle [SWS_Platform_00020].
• float32 y float64 según IEEE 754-2008 [SWS_Platform_00041].
• Los punteros de búfer VoidPtr para datos al llamante y ConstVoidPtr para datos al llamado [SWS_Platform_91001] [SWS_Platform_91002].

Diagrama de actividades: La elección del tipo de plataforma adecuado sigue las preguntas sobre punteros de búfer, valor booleano, número de coma flotante, ancho mínimo o exacto. Fuentes: [SWS_Platform_91001], [SWS_Platform_00026], SWS PlatformTypes p. 17

boolean se implementa en R20-11 como el tipo entero sin signo más corto admitido de forma nativa, por lo general de 8 bits [SWS_Platform_00027]. Versiones posteriores difieren de ello y utilizan _Bool SWS PlatformTypes p. 18. El tipo debe admitir punteros [SWS_Platform_00060] y solo debe usarse con TRUE y FALSE. Los operadores aritméticos y de bits están prohibidos [SWS_Platform_00034], y las redefiniciones de los símbolos deben evitarse mediante comprobación condicional [SWS_Platform_00054].

Por cada plataforma deben definirse además tres símbolos: CPU_TYPE para el ancho de registro [SWS_Platform_00045], CPU_BIT_ORDER con MSB_FIRST o LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049] y CPU_BYTE_ORDER con HIGH_BYTE_FIRST o LOW_BYTE_FIRST [SWS_Platform_00050] [SWS_Platform_00051]. Los nombres de los bits y el peso no deben mezclarse, ya que el MSB se sitúa siempre a la izquierda en el acumulador SWS PlatformTypes p. 15. Interpretación: el módulo no conoce errores de tiempo de ejecución; las asignaciones incorrectas solo se manifiestan durante la integración o la comprobación de conformidad. Pregunta (abierta)

Diagrama de actividades: El ancho de registro, el orden de bits y el orden de bytes del destino se asignan, en cada caso, exactamente a un valor de símbolo. Fuentes: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00050]

más ›

Rol de Platform_Types.h: la base de tipos dependiente de la plataforma

El módulo no es un componente ejecutable, sino una cabecera. Todos los tipos y símbolos especificados están «Available via Platform_Types.h», por ejemplo uint8 [SWS_Platform_00013] o CPU_TYPE [SWS_Platform_00064]. La cabecera oculta las propiedades del microcontrolador de destino y del compilador tras nombres uniformes: anchos de palabra, orden de bits y orden de bytes. Con ello forma parte de la abstracción de microcontrolador exigida en SRS_BSW_00161 con interfaz estandarizada hacia las capas superiores SRS BSWGeneral p. 88. A este mismo requisito upstream hacen referencia también las reglas relativas al orden de bytes SWS PlatformTypes p. 16.

El límite del sistema está trazado de forma estricta. La cabecera no debe ampliarse, ya que cualquier ampliación anula la conformidad con AUTOSAR [SWS_Platform_00002]. En cambio, los tipos de retorno para el éxito o el fracaso de una llamada a la API residen en Std_Types.h SRS BSWGeneral p. 68. En la vista del modelo, los tipos de plataforma se definen como Blueprints, por ejemplo bajo /AUTOSAR/Platform/ImplementationDatatypes_Blueprint/uint8. Se implementan bajo /AUTOSAR_Platform/ImplementationDatatypes/uint8, de modo que los proveedores de componentes puedan acceder a ellos a través de una ruta predecible TPS StandardizationTemplate p. 77.

Diagrama de contexto: La plataforma de destino determina la asignación de Platform_Types.h, cuyos tipos se encuentran en la vista del modelo bajo una ruta fija y son utilizados por numerosos módulos BSW. Los ejemplos de usuarios proceden de releases posteriores. Fuentes: [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 enteros y de coma flotante con ancho garantizado

El núcleo del módulo son tipos sin signo y con signo de ancho fijo de 8 a 64 bits, así como dos tipos de coma flotante. De forma normativa, los requisitos establecen el ancho y el rango de valores, por ejemplo «32 bit unsigned» para uint32 [SWS_Platform_00015]. Los typedefs de C en el catálogo de API, por ejemplo typedef unsigned long uint32;, deberían entenderse como una correspondencia típica que puede variar en función del compilador (interpretación). Pregunta Q-d0ca377fc1abd98a (abierta)

tipo	Ancho / formato	Rango de valores	Referencia
uint8	8 bits, sin signo	0..255	[SWS_Platform_00013]
uint16	16 bits, sin signo	0..65535	[SWS_Platform_00014]
uint32	32 bits, sin signo	0..4294967295	[SWS_Platform_00015]
uint64	64 bits, sin signo	0..18446744073709551615	[SWS_Platform_00066]
sint8	8 bits, con signo	-128..+127	[SWS_Platform_00016]
sint16	16 bits, con signo	-32768..+32767	[SWS_Platform_00017]
sint32	32 bits, con signo	-2147483648..+2147483647	[SWS_Platform_00018]
sint64	64 bits, con signo	-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 los tipos con signo, AUTOSAR solo admite en el compilador y en el destino aritmética de complemento a dos. De ello resultan los rangos de valores asimétricos de la tabla [SWS_Platform_00061]. Otras especificaciones asumen estos tipos de manera coherente en todo momento. La biblioteca CRC define por ejemplo uint8 Crc_CalculateCRC8(const uint8*, uint32, uint8, boolean) SWS CRCLibrary p. 41. COM debe admitir la conversión de endianness para uint16 a float64 RS COM p. 14. Ambos pasajes proceden de releases posteriores y solo ilustran el uso.

Tipos optimizados *_least para contadores y estados

Además de los tipos con ancho exacto, el módulo define seis tipos optimizados. Solo garantizan un ancho mínimo y se derivan de uint y 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]

Por lo tanto, la implementación puede elegir una representación más amplia. Las firmas del catálogo mapean los seis tipos a unsigned int o bien a signed int [SWS_Platform_00020].

Como ejemplos de uso, la especificación menciona contadores de bucle (como máximo 124 iteraciones ⇒ uint8_least) y argumentos de switch (17 estados ⇒ uint8_least). Para más detalles, remite al capítulo «AUTOSAR Integer Data Types» de los requisitos generales de BSW SWS PlatformTypes p. 17.

Uso conforme a las reglas de boolean, TRUE y FALSE

boolean tiene el rango de valores FALSE = 0 y TRUE = 1 y solo debe utilizarse junto con estas definiciones [SWS_Platform_00026]. Para R20-11 se aplica: boolean se implementa como un tipo entero sin signo con la longitud de bits más corta admitida de forma nativa por la plataforma, por lo general 8 bits [SWS_Platform_00027]. Un pasaje del documento de R24-11/R25-11 formula el mismo identificador de forma diferente: allí boolean se implementa mediante el tipo C99 _Bool, y AUTOSAR ya no define el tamaño exacto SWS PlatformTypes p. 18. Para R20-11, esta versión posterior no es normativa.

boolean debe asignarse además a un tipo al que puedan apuntar punteros, de modo que los parámetros puedan pasarse por API. Los tipos de bits eficientes de algunos tipos de hardware no admiten punteros y, por tanto, quedan descartados [SWS_Platform_00060]. Para los símbolos TRUE y FALSE se aplican tres reglas:

• Se definen con protección #ifndef como 1 y 0 [SWS_Platform_00056].
• Si el compilador ya incluye los símbolos, debe evitarse una nueva definición mediante una comprobación condicional [SWS_Platform_00054].
• Solo deben utilizarse junto con boolean [SWS_Platform_00055].

En las asignaciones a variables boolean están prohibidos los operadores aritméticos y bit a bit: +, ++, -, --, *, /, %, <<, >>, ~ y &. Solo se permite la asignación de TRUE o FALSE, así como de resultados de relaciones, operaciones lógicas y comprobaciones de (des)igualdad. Las comparaciones solo se realizan con == o != frente a TRUE/FALSE o mediante if (var) o bien if (!var) [SWS_Platform_00034]. Los módulos consumidores siguen este patrón. Así, Bfx_GetBit devuelve el resultado de una prueba de bits expresamente como TRUE o FALSE SWS BFXLibrary p. 19.

Diagrama de actividad: Para variables boolean solo se permiten las formas de asignación y comparación enumeradas, no los operadores aritméticos ni de bits. Fuentes: [SWS_Platform_00034], [SWS_Platform_00026]

Punteros a búfer sin tipo: VoidPtr y ConstVoidPtr

Ambos tipos de puntero difieren en la dirección del flujo de datos:

• VoidPtr es un void* para búferes que contienen datos devueltos al llamador [SWS_Platform_91001].
• ConstVoidPtr es un const void* para búferes que se pasan a la entidad llamada [SWS_Platform_91002].

Por tanto, la dirección del flujo de datos ya está implícita en el nombre del tipo SWS PlatformTypes p. 27 SWS PlatformTypes p. 28.

El Key Manager muestra cómo se refleja esto en las interfaces. KeyMServiceCertificateByCertId pasa RequestData como ConstVoidPtr junto con una longitud de tipo uint32. La respuesta la recibe ResponseData de tipo VoidPtr; en este caso, ResponseDataLength (INOUT) indica la longitud de búfer disponible SWS KeyManager p. 111. Otros ejemplos:

• KeyM_CertDataType hace referencia a datos de certificado en el área de datos local del llamador a través de un VoidPtr SWS KeyManager p. 97.
• El Crypto Service Manager pasa la semilla como ConstVoidPtr SWS CryptoServiceManager p. 124.

En los tres ejemplos, la longitud se transmite como un parámetro uint32 propio o como un elemento de estructura propio, ya que un puntero sin tipo no lleva información de longitud.

Diagrama de secuencia: En una llamada a un servicio, el ConstVoidPtr lleva la solicitud a la entidad llamada y el VoidPtr recibe la respuesta para el llamador. Fuentes: SWS KeyManager p. 111, [SWS_Platform_91001], [SWS_Platform_91002]

Diagrama de actividad: La selección del tipo sigue las cuestiones de puntero a búfer, valor booleano, número de coma flotante, ancho mínimo o exacto. Fuentes: [SWS_Platform_91001], [SWS_Platform_91002], [SWS_Platform_00026], [SWS_Platform_00041], [SWS_Platform_00020], SWS PlatformTypes p. 17

Identificación de la plataforma: CPU_TYPE, CPU_BIT_ORDER, CPU_BYTE_ORDER

Para cada plataforma deben definirse tres propiedades en la cabecera:

• Ancho de registro mediante CPU_TYPE [SWS_Platform_00044], con uno de los valores CPU_TYPE_8, CPU_TYPE_16, CPU_TYPE_32 o CPU_TYPE_64 [SWS_Platform_00045] [SWS_Platform_00064].
• Orden de bits a nivel de registro mediante CPU_BIT_ORDER [SWS_Platform_00043].
• Orden de bytes en memoria mediante CPU_BYTE_ORDER [SWS_Platform_00046].

Ambos símbolos de orden son #define que toman exactamente uno de los valores admisibles [SWS_Platform_00038] [SWS_Platform_00039].

Diagrama de actividad: Al portar a un destino, se determinan el ancho de registro, el orden de bits y el orden de bytes y se asignan, en cada caso, a exactamente un valor de símbolo. Fuentes: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00049], [SWS_Platform_00050], [SWS_Platform_00051]

Con orden de bits big-endian se aplica CPU_BIT_ORDER = MSB_FIRST; con little-endian, LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049]. Es fundamental separar estrictamente los nombres de los bits de su significancia. En el acumulador, el MSB siempre se encuentra en el extremo izquierdo, independientemente del tipo de CPU. En arquitecturas Motorola (Big Endian Bit Order), Bit0 designa el bit más significativo; en todas las demás, el menos significativo SWS PlatformTypes p. 15 SWS PlatformTypes Fig. 7.1 p. 14.

Diagrama de estructura según la Fig. 7.1: La significancia de los bits de registro es fija; solo la numeración de Bit0 depende de CPU_BIT_ORDER. Fuentes: SWS PlatformTypes Fig. 7.1 p. 14, SWS PlatformTypes p. 15

Con orden de bytes big-endian se aplica CPU_BYTE_ORDER = HIGH_BYTE_FIRST: el byte más significativo de un valor de 16 bits se ubica en la dirección n, el menos significativo en n+1. Con little-endian se aplica LOW_BYTE_FIRST con la disposición inversa [SWS_Platform_00050] [SWS_Platform_00051]. Las designaciones Byte0 y Byte1 solo sirven para ilustrar y pueden diferir en la documentación de referencia de un fabricante SWS PlatformTypes p. 16.

Diagrama de estructura según las Figs. 7.2/7.3: El mismo uint16 se asigna a las direcciones n y n+1 con los bytes invertidos según CPU_BYTE_ORDER. Fuentes: SWS PlatformTypes Fig. 7.2 p. 16, SWS PlatformTypes Fig. 7.3 p. 15, [SWS_Platform_00039]

Otras especificaciones justifican por qué son necesarios estos datos. La representación en memoria de los datos depende en gran medida de la arquitectura del procesador y de la configuración del compilador. Por ello, SOME/IP exige un algoritmo de serialización que realice la conversión a una representación de red común RS SOMEIPProtocol p. 21. Presumiblemente, tales conversiones en las implementaciones se basan en CPU_BYTE_ORDER; no obstante, el payload no lo demuestra de forma expresa. Pregunta Q-87e212e9eb2a2047 (abierta)

Comportamiento en caso de error

Interpretación: Dado que Platform_Types.h solo proporciona tipos y símbolos, el módulo no conoce errores de tiempo de ejecución ni códigos de error. Pregunta Q-e504d08b84d7ff70 (abierta) Los patrones de error se manifiestan durante la compilación, la integración o la verificación de conformidad. Los requisitos nombran las causas típicas [SWS_Platform_00002]:

• No se permiten extensiones de la cabecera; cualquier extensión anula la conformidad [SWS_Platform_00002].
• Las definiciones duplicadas de TRUE/FALSE cuando ya existe soporte del compilador deben evitarse mediante una comprobación condicional [SWS_Platform_00054] [SWS_Platform_00056].
• Los símbolos de orden con valores incorrectos infringen desde [SWS_Platform_00048] hasta [SWS_Platform_00051]. Mezclar los nombres de bits de la documentación del fabricante con la significancia resulta especialmente propenso a errores SWS PlatformTypes p. 15.
• Un boolean que no admita punteros infringe [SWS_Platform_00060], ya que los parámetros no podrían pasarse por API.
• Las operaciones aritméticas o de bits sobre boolean son inadmisibles, al igual que cualquier forma de comparación distinta de las enumeradas [SWS_Platform_00034].
• El código que asuma complemento a uno o rangos de valores simétricos no está respaldado, ya que solo se admite el complemento a dos [SWS_Platform_00061].
• Al cambiar de versión debe tenerse en cuenta la especificación para boolean: R20-11 [SWS_Platform_00027] y las versiones posteriores SWS PlatformTypes p. 18 difieren. Por lo tanto, el código que presuponga un tamaño fijo de boolean debe verificarse antes de realizar el cambio.

Más evidencia detallada

• Tipos enteros de ancho fijo: de [SWS_Platform_00013] a [SWS_Platform_00018], así como [SWS_Platform_00066] y [SWS_Platform_00067] establecen el ancho y el rango de valores.
• Tipos optimizados: de [SWS_Platform_00020] a [SWS_Platform_00025], con ejemplos de uso en SWS PlatformTypes p. 17.
• Tipos de coma flotante según 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].
• Punteros a búfer: [SWS_Platform_91001], [SWS_Platform_91002], con aplicación en SWS KeyManager p. 111.
• Símbolos de plataforma: de [SWS_Platform_00043] a [SWS_Platform_00046], [SWS_Platform_00064], [SWS_Platform_00038], [SWS_Platform_00039]. La asignación de endianness la regulan de [SWS_Platform_00048] a [SWS_Platform_00051], ilustrado en SWS PlatformTypes p. 16.
• Reglas marco: [SWS_Platform_00002] (sin extensiones), [SWS_Platform_00054] (sin nuevas definiciones), [SWS_Platform_00061] (complemento a dos). [SWS_Platform_00063] declara no aplicable un grupo de requisitos; a cuáles se refiere no se desprende del texto abreviado.