Platform Types (Platform_Types)

Platform_Types.h provides the platform-dependent base types of the Classic Platform: fixed-width integer types from uint8 to sint64, optimized *_least types, float32/float64, boolean with TRUE/FALSE, and the buffer pointers VoidPtr and ConstVoidPtr. In addition, CPU_TYPE, CPU_BIT_ORDER, and CPU_BYTE_ORDER designate register width and endianness of the target [SWS_Platform_00046]. boolean may only be used with TRUE and FALSE and without arithmetic or bitwise operators [SWS_Platform_00034]. The header must not be extended, otherwise AUTOSAR conformance is lost.

more ›

Platform_Types.h is the platform-dependent type base of the Classic Platform. The header encapsulates word widths and endianness of the target behind uniform names and must not be extended, as any extension invalidates AUTOSAR conformance [SWS_Platform_00002]. In the model view, the types are located under a fixed path such as /AUTOSAR_Platform/ImplementationDatatypes/uint8 TPS StandardizationTemplate p. 77.

The header provides the following type groups:

• Fixed-width integer types from uint8 to sint64 [SWS_Platform_00013] [SWS_Platform_00067]; for signed types, only two's complement applies [SWS_Platform_00061].
• Optimized types *_least with minimum width, for example for loop counters [SWS_Platform_00020].
• float32 and float64 according to IEEE 754-2008 [SWS_Platform_00041].
• The buffer pointers VoidPtr for data to the caller and ConstVoidPtr for data to the callee [SWS_Platform_91001] [SWS_Platform_91002].

Activity diagram: The selection of the suitable platform type follows the questions buffer pointer, boolean value, floating-point number, minimum width, or exact width. Sources: [SWS_Platform_91001], [SWS_Platform_00026], SWS PlatformTypes p. 17

boolean is implemented in R20-11 as the shortest natively supported unsigned integer type, typically 8 bits [SWS_Platform_00027]. Later versions deviate from this and use _Bool SWS PlatformTypes p. 18. The type must be capable of being pointed to [SWS_Platform_00060] and may only be used with TRUE and FALSE. Arithmetic and bitwise operators are prohibited [SWS_Platform_00034], and redefinitions of the symbols must be avoided via conditional checks [SWS_Platform_00054].

In addition, three symbols must be defined per platform: CPU_TYPE for the register width [SWS_Platform_00045], CPU_BIT_ORDER with MSB_FIRST or LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049], and CPU_BYTE_ORDER with HIGH_BYTE_FIRST or LOW_BYTE_FIRST [SWS_Platform_00050] [SWS_Platform_00051]. Bit names and significance must not be confused here, because the MSB is always on the left in the accumulator SWS PlatformTypes p. 15. Interpretation: The module has no runtime errors; incorrect configurations only become apparent during integration or conformance testing. Question (open)

Activity diagram: Register width, bit order, and byte order of the target are each mapped to exactly one symbol value. Sources: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00050]

more ›

Role of Platform_Types.h: The Platform-Dependent Type Base

The module is not an executable building block, but a header. All specified types and symbols are "Available via Platform_Types.h", such as uint8 [SWS_Platform_00013] or CPU_TYPE [SWS_Platform_00064]. The header conceals the properties of the target microcontroller and compiler behind uniform names: word widths, bit order, and byte order. It is therefore part of the microcontroller abstraction with a standardized interface to higher layers required in SRS_BSW_00161 SRS BSWGeneral p. 88. The rules on byte order refer to precisely this upstream requirement SWS PlatformTypes p. 16.

The system boundary is drawn narrowly. The header must not be extended, as any extension voids AUTOSAR conformance [SWS_Platform_00002]. In contrast, return types for the success or failure of an API call are located in Std_Types.h SRS BSWGeneral p. 68. In the model view, the platform types are stored as blueprints, for example under /AUTOSAR/Platform/ImplementationDatatypes_Blueprint/uint8. They are implemented under /AUTOSAR_Platform/ImplementationDatatypes/uint8, so that component suppliers can access them via a predictable path TPS StandardizationTemplate p. 77.

Context diagram: The target platform determines the definition of Platform_Types.h, whose types are located under a fixed path in the model view and are used by numerous BSW modules. The user examples originate from later releases. Sources: [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

Integer and Floating-Point Types with Guaranteed Width

At the core of the module are unsigned and signed types with a fixed width of 8 to 64 bits as well as two floating-point types. Normatively, the requirements specify width and range of values, such as "32 bit unsigned" for uint32 [SWS_Platform_00015]. The C typedefs in the API catalog, for example typedef unsigned long uint32;, are likely to be read as a typical mapping that may vary depending on the compiler (interpretation). Question Q-d0ca377fc1abd98a (open)

type	Width / Format	Value Range	Reference
uint8	8 bit, unsigned	0..255	[SWS_Platform_00013]
uint16	16 bit, unsigned	0..65535	[SWS_Platform_00014]
uint32	32 bit, unsigned	0..4294967295	[SWS_Platform_00015]
uint64	64 bit, unsigned	0..18446744073709551615	[SWS_Platform_00066]
sint8	8 bit, signed	-128..+127	[SWS_Platform_00016]
sint16	16 bit, signed	-32768..+32767	[SWS_Platform_00017]
sint32	32 bit, signed	-2147483648..+2147483647	[SWS_Platform_00018]
sint64	64 bit, signed	-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]

For signed types, AUTOSAR exclusively supports two's complement arithmetic for compiler and target. This results in the asymmetrical value ranges in Table [SWS_Platform_00061]. Other specifications consistently require these types. For example, the CRC library defines uint8 Crc_CalculateCRC8(const uint8*, uint32, uint8, boolean) SWS CRCLibrary p. 41. COM must support endianness conversion for uint16 to float64 RS COM p. 14. Both references originate from later releases and merely illustrate the usage.

Optimized Types *_least for Counters and States

In addition to the types with exact width, the module defines six optimized types. They only guarantee a minimum width and are derived from uint and sint, respectively:

• 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]

The implementation may therefore choose a wider representation. The catalog signatures map all six types to unsigned int and signed int, respectively [SWS_Platform_00020].

As examples of use, the specification cites loop counters (at most 124 iterations ⇒ uint8_least) and switch arguments (17 states ⇒ uint8_least). For details, it refers to the chapter "AUTOSAR Integer Data Types" of the general BSW requirements SWS PlatformTypes p. 17.

Using boolean, TRUE, and FALSE in Compliance with the Rules

boolean has the value range FALSE = 0 and TRUE = 1 and may only be used together with these definitions [SWS_Platform_00026]. For R20-11: boolean is implemented as an unsigned integer type with the shortest bit length natively supported by the platform, typically 8 bits [SWS_Platform_00027]. A document passage from R24-11/R25-11 phrases the same identifier differently: there, boolean is implemented via the C99 type _Bool, and AUTOSAR no longer specifies the exact size SWS PlatformTypes p. 18. For R20-11, this later version is not normative.

boolean must also be mapped to a type that pointers can point to, so that parameters can be passed via API. The efficient bit types of some hardware cannot be pointed to and are therefore excluded [SWS_Platform_00060]. Three rules apply to the symbols TRUE and FALSE:

• They are defined as 1 and 0 with #ifndef protection [SWS_Platform_00056].
• If the compiler already provides the symbols, a redefinition must be avoided by a conditional check [SWS_Platform_00054].
• They may only be used together with boolean [SWS_Platform_00055].

For assignments to boolean variables, arithmetic and bitwise operators are prohibited: +, ++, -, --, *, /, %, <<, >>, ~, and &. Only the assignment of TRUE or FALSE as well as results from relational expressions, logical operations, and (in)equality checks is permissible. Comparisons are only made with == or != against TRUE/FALSE or via if (var) or if (!var) [SWS_Platform_00034]. Consuming modules follow this pattern. For example, Bfx_GetBit explicitly returns the result of a bit test as TRUE or FALSE SWS BFXLibrary p. 19.

Activity diagram: For boolean variables, only the listed forms of assignment and comparison are permitted; arithmetic and bitwise operators are not. Sources: [SWS_Platform_00034], [SWS_Platform_00026]

Untyped Buffer Pointers: VoidPtr and ConstVoidPtr

The two pointer types differ in the direction of data flow:

• VoidPtr is a void* for buffers containing data returned to the caller [SWS_Platform_91001].
• ConstVoidPtr is a const void* for buffers passed to the callee [SWS_Platform_91002].

The data flow direction is thus already inherent in the type name SWS PlatformTypes p. 27 SWS PlatformTypes p. 28.

The Key Manager shows how this looks in interfaces. KeyMServiceCertificateByCertId passes RequestData as ConstVoidPtr together with a length of type uint32. The response is received by ResponseData of type VoidPtr; ResponseDataLength (INOUT) specifies the available buffer length SWS KeyManager p. 111. Further examples:

• KeyM_CertDataType references certificate data in the local data area of the caller via a VoidPtr SWS KeyManager p. 97.
• The Crypto Service Manager passes the seed as ConstVoidPtr SWS CryptoServiceManager p. 124.

In all three examples, the length is passed along as a separate uint32 parameter or as a dedicated structure element because an untyped pointer does not carry length information.

Sequence diagram: During a service call, the ConstVoidPtr carries the request to the callee, while the VoidPtr receives the response for the caller. Sources: SWS KeyManager p. 111, [SWS_Platform_91001], [SWS_Platform_91002]

Activity diagram: The choice of type follows the questions buffer pointer, boolean value, floating-point number, minimum width, or exact width. Sources: [SWS_Platform_91001], [SWS_Platform_91002], [SWS_Platform_00026], [SWS_Platform_00041], [SWS_Platform_00020], SWS PlatformTypes p. 17

Platform Identification: CPU_TYPE, CPU_BIT_ORDER, CPU_BYTE_ORDER

For each platform, three properties must be defined in the header:

• Register width via CPU_TYPE [SWS_Platform_00044], with one of the values CPU_TYPE_8, CPU_TYPE_16, CPU_TYPE_32, or CPU_TYPE_64 [SWS_Platform_00045] [SWS_Platform_00064].
• Bit order at the register level via CPU_BIT_ORDER [SWS_Platform_00043].
• Byte order in memory via CPU_BYTE_ORDER [SWS_Platform_00046].

Both order symbols are #defines that carry exactly one of the permissible values [SWS_Platform_00038] [SWS_Platform_00039].

Activity diagram: When porting to a target, register width, bit order, and byte order are determined and each mapped to exactly one symbol value. Sources: [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00049], [SWS_Platform_00050], [SWS_Platform_00051]

For big-endian bit order, CPU_BIT_ORDER = MSB_FIRST applies; for little-endian, LSB_FIRST applies [SWS_Platform_00048] [SWS_Platform_00049]. Bit names and significance must be strictly separated here. The MSB is always located on the far left in the accumulator, regardless of the CPU type. In Motorola architectures (Big Endian Bit Order), Bit0 designates the most significant bit; in all others, it designates the least significant bit SWS PlatformTypes p. 15 SWS PlatformTypes Fig. 7.1 p. 14.

Structure diagram according to Fig. 7.1: The significance of the register bits is fixed; only the numbering of Bit0 depends on CPU_BIT_ORDER. Sources: SWS PlatformTypes Fig. 7.1 p. 14, SWS PlatformTypes p. 15

For big-endian byte order, CPU_BYTE_ORDER = HIGH_BYTE_FIRST applies: the most significant byte of a 16-bit value is located at address n, the least significant at n+1. For little-endian, LOW_BYTE_FIRST applies with reversed allocation [SWS_Platform_00050] [SWS_Platform_00051]. The designations Byte0 and Byte1 serve only for illustration and may differ in a manufacturer's reference documentation SWS PlatformTypes p. 16.

Structure diagram according to Fig. 7.2/7.3: The same uint16 is mapped to addresses n and n+1 with swapped bytes depending on CPU_BYTE_ORDER. Sources: SWS PlatformTypes Fig. 7.2 p. 16, SWS PlatformTypes Fig. 7.3 p. 15, [SWS_Platform_00039]

Other specifications justify why these details are necessary. The memory representation of data strongly depends on processor architecture and compiler settings. For this reason, SOME/IP requires a serialization algorithm that converts into a common network representation RS SOMEIPProtocol p. 21. Presumably, such conversions in implementations rely on CPU_BYTE_ORDER; however, the payload does not explicitly verify this. Question Q-87e212e9eb2a2047 (open)

Behavior in the event of an error

Interpretation: Because Platform_Types.h only provides types and symbols, the module has no runtime errors and no error codes. Question Q-e504d08b84d7ff70 (open) Error patterns manifest during compilation, integration, or conformance testing. The requirements state the typical causes [SWS_Platform_00002]:

• Extensions to the header are inadmissible; any extension voids conformance [SWS_Platform_00002].
• Duplicate definitions of TRUE/FALSE when compiler support is present must be prevented by a conditional check [SWS_Platform_00054] [SWS_Platform_00056].
• Incorrectly assigned order symbols violate [SWS_Platform_00048] to [SWS_Platform_00051]. Mixing the bit names from the manufacturer documentation with significance is particularly prone to errors SWS PlatformTypes p. 15.
• A boolean that cannot be pointed to violates [SWS_Platform_00060] because parameters cannot then be passed via API.
• Arithmetic or bitwise operations on boolean are inadmissible, as are forms of comparison other than those listed [SWS_Platform_00034].
• Code that assumes one's complement or symmetrical value ranges is not covered, since only two's complement is supported [SWS_Platform_00061].
• When changing releases, the specification for boolean must be observed: R20-11 [SWS_Platform_00027] and later versions SWS PlatformTypes p. 18 differ. Code that assumes a fixed size of boolean must therefore be checked prior to the transition.

Further detailed evidence

• Fixed-width integer types: [SWS_Platform_00013] to [SWS_Platform_00018] as well as [SWS_Platform_00066] and [SWS_Platform_00067] specify width and value range.
• Optimized types: [SWS_Platform_00020] to [SWS_Platform_00025], with usage examples in SWS PlatformTypes p. 17.
• Floating-point types according to IEEE 754-2008: [SWS_Platform_00041], [SWS_Platform_00042].
• Boolean values: [SWS_Platform_00026], [SWS_Platform_00027], [SWS_Platform_00034], [SWS_Platform_00055], [SWS_Platform_00056], [SWS_Platform_00060].
• Buffer pointers: [SWS_Platform_91001], [SWS_Platform_91002], with application in SWS KeyManager p. 111.
• Platform symbols: [SWS_Platform_00043] to [SWS_Platform_00046], [SWS_Platform_00064], [SWS_Platform_00038], [SWS_Platform_00039]. Endianness assignment is governed by [SWS_Platform_00048] to [SWS_Platform_00051], illustrated in SWS PlatformTypes p. 16.
• Framework rules: [SWS_Platform_00002] (no extensions), [SWS_Platform_00054] (no redefinitions), [SWS_Platform_00061] (two's complement). [SWS_Platform_00063] declares a group of requirements as not applicable; which ones are meant is not evident from the abbreviated text.