AUTOSAR Classic General & Standard Types

Via the headers Platform_Types.h, Std_Types.h, and ComStack_Types.h, the General & Standard Types module cluster provides the hardware-independent basis for all data types, status reports, and communication buffers of the Classic Platform (AUTOSAR_SRS_BSWGeneral p. 62). It standardizes fundamental architectural features such as endianness models, standardized return values like Std_ReturnType, and communication structures like PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Since these are pure header definitions without executable code, the cluster requires no runtime configuration, nor does it have its own tasks or active error handling (SWS_StandardTypes p. 27).

more ›

The General & Standard Types module cluster comprises the three basic headers platform (Platform_Types.h), std (Std_Types.h), and comstack (ComStack_Types.h). As pure type definitions, they contain no executable code whatsoever and require no configuration (SWS_StandardTypes p. 27). They form the platform-wide foundation for hardware-independent typing, standardize compiler and hardware specifics, and provide all BSW modules and the RTE with consistent data structures (AUTOSAR_SRS_BSWGeneral p. 62).

Architecture diagram: Static layering and inclusion architecture of the 'General & Standard Types' module cluster with exported type interfaces. Sources: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

The inclusion hierarchy builds up stepwise: Platform_Types.h encapsulates platform-specific properties such as the C99 type boolean ([SWS_Platform_00027]), universal buffer pointers such as ConstVoidPtr ([SWS_Platform_91002]), and symbols for register bit order CPU_BIT_ORDER ([SWS_Platform_00038]) and memory byte order CPU_BYTE_ORDER ([SWS_Platform_00039]). Building on this, Std_Types.h provides universal standard constants such as STD_ON/STD_OFF ([SWS_Std_00010]), module version structures via Std_VersionInfoType ([SWS_Std_00015]), and the fundamental status system Std_ReturnType with E_OK and E_NOT_OK ([SWS_Std_00005], [SWS_Std_00006]).

For the AUTOSAR communication stack, ComStack_Types.h defines all cross-protocol interface types such as PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]), and the central buffer structure PduInfoType ([SWS_COMTYPE_00008]). In segmented transport protocols (e.g. CanTp or DoIP), the return type BufReq_ReturnType, together with RetryInfoType, controls synchronous buffer reservation and data copying between BSW layers (SWS_DiagnosticCommunicationManager p. 291, [SWS_COMTYPE_00012]).

Sequence diagram: Segmented reception and buffer path of a transport protocol using ComStack_Types (PduInfoType, BufReq_ReturnType). Sources: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Although the cluster has no error handling of its own or DET reporting (SWS_StandardTypes p. 27), Std_ReturnType structures the error handling of the overall system: bits 0 to 5 (0x00 to 0x3F) are reserved for standard and application errors, while bits 6 and 7 are occupied exclusively by the RTE ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). All type definitions are specified for reentrant use in multitasking and interrupt contexts (SWS_CANInterface p. 87).

more ›

System Architecture & Role of the Module Cluster

The General & Standard Types module cluster forms the fundamental typological and hardware-abstracting foundation of the AUTOSAR Classic Platform in release R20-11. It is composed of the three header-only modules platform ([SWS_Platform_00038]), std ([SWS_Std_00005]), and comstack ([SWS_COMTYPE_00005]). According to the BSW architecture, these modules neither provide their own executable C code nor request other BSW drivers (SWS_StandardTypes p. 27). Their central task is to encapsulate compiler and processor dependencies, provide platform-wide uniform basic types, and establish standardized data structures for the communication layers.

The layer hierarchy follows a strict, unidirectional inclusion order: the file Platform_Types.h abstracts the properties of the underlying microcontroller architecture (such as register and memory layout and C99 elementary types), while Std_Types.h builds on it and defines universal return values and status constants (AUTOSAR_SRS_BSWGeneral p. 62). Building upon that, ComStack_Types.h declares all bus- and cross-protocol data types for networks such as CAN, FlexRay, LIN, and Ethernet, as well as for transport protocols according to ISO 15765-2 and diagnostic protocols according to ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). This decoupling ensures that higher layers such as the runtime environment (RTE) and application Software Components (SWCs) remain fully portable (SWS_RTE p. 818).

Architecture diagram: Static layering and inclusion architecture of the 'General & Standard Types' module cluster with exported type interfaces. Sources: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Interplay & Interaction Paths Between the Modules

Interaction within the cluster is based on a static inclusion chain: ComStack_Types.h includes Std_Types.h, which in turn includes Platform_Types.h (RS_BSWGeneral p. 60). The module platform defines fundamental quantities such as boolean, which must strictly be mapped to the C99 basic type _Bool ([SWS_Platform_00027]), and governs its strict value assignment via the literals TRUE and FALSE ([SWS_Platform_00034]). Furthermore, generic buffer pointers such as ConstVoidPtr are specified, which are used for immutable transfer buffers passed to called function interfaces ([SWS_Platform_91002]).

In addition, platform harmonizes hardware endians via standardized preprocessor symbols: for the bit order in registers, CPU_BIT_ORDER is defined as MSB_FIRST or LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). The byte order in physical memory is controlled via CPU_BYTE_ORDER, distinguishing HIGH_BYTE_FIRST (big-endian, MSB at lower address) from LOW_BYTE_FIRST (little-endian, LSB at lower address) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Structure diagram: Memory layout of scalar multi-byte values in big-endian (HIGH_BYTE_FIRST) vs. little-endian (LOW_BYTE_FIRST). Sources: AUTOSAR_CP_SWS_PlatformTypes p. 16, AUTOSAR_CP_SWS_PlatformTypes p. 15, [SWS_Platform_00050], [SWS_Platform_00051]

At the next abstraction level, the module std defines universal symbols for switching states and logical levels: STD_HIGH (0x01u) and STD_LOW (0x00u) for physical voltage levels ([SWS_Std_00007]), STD_ON (0x01u) and STD_OFF (0x00u) for activation modes ([SWS_Std_00010]), and STD_ACTIVE (0x01u) and STD_IDLE (0x00u) for logical execution states ([SWS_Std_00013]). For message protocols and transformers, std additionally provides Std_MessageTypeType with the literals STD_MESSAGETYPE_REQUEST (0x00) and STD_MESSAGETYPE_RESPONSE (0x01) ([SWS_Std_91001], [SWS_Std_00017]), as well as the function pointer type Std_ExtractProtocolHeaderFieldsType for extracting protocol headers ([SWS_Std_91003]).

The module comstack in turn uses the basic types of platform and std to structure the entire buffer and data exchange in the communication stack. The central interface structure is PduInfoType, which bundles the data pointer SduDataPtr (uint8*), the metadata pointer MetaDataPtr, and the buffer length SduLength of type PduLengthType ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). The I-PDU identification is carried out via PduIdType ([SWS_COMTYPE_00005]). For managing entire communication channels and partial networks, comstack defines the channel identifier NetworkHandleType ([SWS_COMTYPE_00038]) and the partial network identifier PNCHandleType ([SWS_COMTYPE_00036]), which are used, for instance, in the Synchronized PNC Shutdown of ComM and Nm (SWS_COMManager p. 171).

In segmented transport protocol (TP) transmissions, buffer negotiation is handled via the return types BufReq_ReturnType and the structure RetryInfoType ([SWS_COMTYPE_00012]). During synchronous copy calls such as CopyTxData or CopyRxData between modules such as CanTp, PduR, DCM, DoIP, or SecOC, BUFREQ_OK signals a successful copy operation, while BUFREQ_E_BUSY communicates that insufficient buffer is temporarily available and that a retry is permitted (SWS_DiagnosticCommunicationManager p. 291, SWS_SecureOnboardCommunication p. 76). Via RetryInfoType with parameters such as TP_CONFPENDING or TP_DATACONF, it is ensured that data remains in the buffer for possible retransmissions or is released after confirmation (SWS_IntrusionDetectionSystemManager p. 49).

Sequence diagram: Segmented reception and buffer path of a transport protocol using ComStack_Types (PduInfoType, BufReq_ReturnType). Sources: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Synchronization, reentrancy and task contexts

Since the modules platform, std, and comstack are header-only files without executable object files, they naturally do not implement any cyclic MainFunctions and do not possess their own task contexts (SWS_StandardTypes p. 27). However, they define the signatures and type conventions for functions called across layer boundaries. All type definitions are designed so that they can be passed in a fully reentrant and stateless manner (SWS_CANInterface p. 87).

The practical use of the types occurs in highly asynchronous and concurrent environments. Data reception callbacks such as CanIf_RxIndication or Dcm_CopyRxData that use PduInfoType and PduIdType are explicitly allowed to be executed in interrupt context (SWS_CANInterface p. 164, SWS_DiagnosticCommunicationManager p. 274). In contrast, routing decisions, buffer allocations, or cyclic transmissions are processed in periodic tasks of the upper layers (e.g. SoAd_MainFunction) (SWS_SocketAdaptor p. 104). Since pointer structures such as PduInfoType can be shared between interrupt level and task level, thread-safe synchronization by means of exclusive areas (protection against concurrency) is the responsibility of the calling and implementing BSW modules.

Typical lifecycles and operating modes

Pure type definitions are not subject to a runtime lifecycle and possess neither initialization nor shutdown functions (SWS_StandardTypes p. 27). They must be statically included at compile time before all processing modules. However, they form the normative framework for mapping and monitoring the lifecycle of other BSW modules: for standardized version queries, std specifies the structure Std_VersionInfoType, which contains vendorID, moduleID, and the software version states (sw_major_version, sw_minor_version, sw_patch_version) ([SWS_Std_00015]).

In addition, types such as NetworkHandleType and PNCHandleType support higher-level network and mode management during operating mode transitions such as startup, normal operation, sleep, and wakeup ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). ComM, for instance, uses these identifiers to control coordinated shutdowns and state transitions within the partial network cluster (SWS_COMManager p. 171, SWS_NetworkManagementInterface p. 106).

Error Handling, DET Tracing, and Status Encoding

The module cluster provides no active error handling of its own and reports neither development errors to the DET nor production errors to the DEM (SWS_StandardTypes p. 27). Instead, it standardizes the platform-wide feedback format: the fundamental type Std_ReturnType is based on uint8 and serves across all layers as the standard result of synchronous calls ([SWS_Std_00005], BSWUMLModelModelingGuide p. 28). By default, E_OK (0x00u) represents successful execution and E_NOT_OK (0x01u) a generic error ([SWS_Std_00006]). For reasons of compatibility with ISO 17356-3 (OSEK OS), E_OK is protected against multiple definitions via a guard check (STATUSTYPEDEFINED) (AUTOSAR_SRS_BSWGeneral p. 62).

The bit layout of Std_ReturnType follows a fixed partitioning: bits 0 to 5 (range 0x00 to 0x3F) are reserved for standardized and module-specific return values or application-specific ApplicationError codes in client/server operations ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Module-specific extensions are maintained in UML models as a class with the stereotype «extra_literals» (BSWUMLModelModelingGuide p. 33). Bits 6 and 7 (value range 0x40, 0x80, 0xC0) are strictly reserved for infrastructure error states of the RTE (AUTOSAR_CP_SWS_StandardTypes p. 15). For data transformations in the RTE, std additionally declares the structure Std_TransformerError, consisting of errorCode ([SWS_Std_00022]) and transformerClass ([SWS_Std_00021]), enabling seamless tracking of error chains during serialization or E2E protection.