AUTOSAR Classic General & Standard Types
Die Standard- und Plattformtypen definieren die grundlegenden C-Typen, Rückgabewerte und Kommunikationsdatenstrukturen der AUTOSAR Classic Architektur. Sie stellen hardwareunabhängige Portabilität für Basissoftware und Applikations-SW-Cs sicher.
ClustergidsAI-GEGENEREERD
Stelt hardware-onafhankelijke basistypes, statusretourwaarden en communicatiebufferstructuren beschikbaar voor alle BSW-modules.
Stelt hardware-onafhankelijke basistypes, statusretourwaarden en communicatiebufferstructuren beschikbaar voor alle BSW-modules.
Het modulecluster General & Standard Types stelt via de headers Platform_Types.h, Std_Types.h en ComStack_Types.h de hardware-onafhankelijke basis voor alle datatypes, statusterugmeldingen en communicatiebuffers van het Classic Platform beschikbaar (AUTOSAR_SRS_BSWGeneral p. 62). Het normeert fundamentele architectuurkenmerken zoals endianness-modellen, gestandaardiseerde retourwaarden zoals Std_ReturnType en communicatiestructuren zoals PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Aangezien het louter headerdefinities zonder uitvoerbare code betreft, vereist het cluster geen runtimeconfiguratie en bezit het evenmin eigen taken of een actieve foutafhandeling (SWS_StandardTypes p. 27).
Het modulecluster General & Standard Types omvat de drie basisheaders platform (Platform_Types.h), std (Std_Types.h) en comstack (ComStack_Types.h). Als zuivere typedefinities bevatten ze geen enkele uitvoerbare code en behoeven ze geen configuratie (SWS_StandardTypes p. 27). Ze vormen het platformbrede fundament voor een hardware-onafhankelijke typering, verenigen compiler- en hardware-bijzonderheden en voorzien alle BSW-modules en de RTE van consistente datastructuren (AUTOSAR_SRS_BSWGeneral p. 62).
Architectuurdiagram: Statische lagen- en inclusie-architectuur van het modulecluster 'General & Standard Types' met geëxporteerde type-interfaces. Bronnen: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]
De inclusiehiërarchie bouwt trapsgewijs op elkaar voort: Platform_Types.h kapselt platformspecifieke eigenschappen in zoals het C99-type boolean ([SWS_Platform_00027]), universele bufferpointers zoals ConstVoidPtr ([SWS_Platform_91002]) evenals symbolen voor de registerbitvolgorde CPU_BIT_ORDER ([SWS_Platform_00038]) en de geheugenbytevolgorde CPU_BYTE_ORDER ([SWS_Platform_00039]). Daarop voortbouwend stelt Std_Types.h universele standaardconstanten zoals STD_ON/STD_OFF ([SWS_Std_00010]), moduleversiestructuren via Std_VersionInfoType ([SWS_Std_00015]) evenals het fundamentele statussysteem Std_ReturnType met E_OK en E_NOT_OK beschikbaar ([SWS_Std_00005], [SWS_Std_00006]).
Voor de AUTOSAR-communicatiestack definieert ComStack_Types.h alle protocoloverstijgende interfacetypes zoals PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) en de centrale bufferstructuur PduInfoType ([SWS_COMTYPE_00008]). In gesegmenteerde transportprotocollen (bijv. CanTp of DoIP) stuurt het retourtype BufReq_ReturnType samen met RetryInfoType de synchrone bufferreservering en gegevenskopie tussen BSW-lagen aan (SWS_DiagnosticCommunicationManager p. 291, [SWS_COMTYPE_00012]).
Sequentiediagram: Gesegmenteerd ontvangst- en bufferpad van een transportprotocol met gebruik van ComStack_Types (PduInfoType, BufReq_ReturnType). Bronnen: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274
Hoewel het cluster geen eigen foutafhandeling of DET-meldingen heeft (SWS_StandardTypes p. 27), structureert Std_ReturnType de foutafhandeling van het totale systeem: bits 0 tot 5 (0x00 tot 0x3F) zijn gereserveerd voor standaard- en applicatiefouten, terwijl bits 6 en 7 exclusief door de RTE worden ingenomen ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Alle typedefinities zijn gespecificeerd voor re-entrant gebruik in multitasking- en interruptcontexten (SWS_CANInterface p. 87).
Systeemarchitectuur & rol van het modulecluster
Het modulecluster General & Standard Types vormt het fundamentele typologische en hardware-abstraherende fundament van het AUTOSAR Classic Platform in release R20-11. Het is samengesteld uit de drie zuivere headermodules platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) en comstack ([SWS_COMTYPE_00005]). Conform de BSW-architectuur stellen deze modules noch eigen uitvoerbare C-code beschikbaar noch vragen zij andere BSW-drivers aan (SWS_StandardTypes p. 27). Hun centrale taak bestaat erin compiler- en processorafhankelijkheden in te kapselen, platformbreed uniforme basistypes beschikbaar te stellen en gestandaardiseerde datastructuren voor de communicatielagen te vestigen.
De lagenhiërarchie volgt een strikte, unidirectionele inclusievolgorde: het bestand Platform_Types.h abstraheert de eigenschappen van de onderliggende microcontrollerarchitectuur (zoals register- en geheugenindeling evenals C99-elementaire typen), terwijl Std_Types.h daarop voortbouwt en universele retourwaarden en statusconstanten definieert (AUTOSAR_SRS_BSWGeneral p. 62). Daarop voortbouwend declareert ComStack_Types.h alle bus- en protocoloverstijgende datatypen voor netwerken zoals CAN, FlexRay, LIN en Ethernet evenals voor transportprotocollen volgens ISO 15765-2 en diagnoseprotocollen volgens ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Door deze ontkoppeling wordt gewaarborgd dat hogere lagen zoals de runtime-omgeving (RTE) en applicatie-software-components (SWC's) volledig overdraagbaar blijven (SWS_RTE p. 818).
Architectuurdiagram: Statische lagen- en inclusie-architectuur van het modulecluster 'General & Standard Types' met geëxporteerde type-interfaces. Bronnen: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]
Samenspel & interactiepaden tussen de modules
De samenwerking binnen het cluster is gebaseerd op een statische inclusieketen: ComStack_Types.h includeert Std_Types.h, dat op zijn beurt Platform_Types.h includeert (RS_BSWGeneral p. 60). De module platform definieert fundamentele grootheden zoals boolean, dat verplicht op het C99-basistype _Bool moet worden afgebeeld ([SWS_Platform_00027]), en regelt de strikte waardetoekenning daarvan via de literals TRUE en FALSE ([SWS_Platform_00034]). Verder worden generieke bufferpointers zoals ConstVoidPtr gespecificeerd, die worden gebruikt voor onveranderlijke overdrachtsbuffers naar aangeroepen functie-interfaces ([SWS_Platform_91002]).
Bovendien harmoniseert platform de hardware-endianness via gestandaardiseerde preprocessorsymbolen: voor de bitvolgorde in registers wordt CPU_BIT_ORDER vastgelegd op MSB_FIRST of LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). De bytevolgorde in het fysieke geheugen wordt gestuurd via CPU_BYTE_ORDER, waarbij HIGH_BYTE_FIRST (big-endian, MSB op een lager adres) wordt onderscheiden van LOW_BYTE_FIRST (little-endian, LSB op een lager adres) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).
Structuurdiagram: geheugenafbeelding van scalaire multi-byte-waarden bij big-endian (HIGH_BYTE_FIRST) vs. little-endian (LOW_BYTE_FIRST). Bronnen: AUTOSAR_CP_SWS_PlatformTypes p. 16, AUTOSAR_CP_SWS_PlatformTypes p. 15, [SWS_Platform_00050], [SWS_Platform_00051]
Op het volgende abstractieniveau definieert de module std universele symbolen voor schakeltoestanden en logische niveaus: STD_HIGH (0x01u) en STD_LOW (0x00u) voor fysieke spanningsniveaus ([SWS_Std_00007]), STD_ON (0x01u) en STD_OFF (0x00u) voor activeringsmodi ([SWS_Std_00010]) evenals STD_ACTIVE (0x01u) en STD_IDLE (0x00u) voor logische uitvoeringstoestanden ([SWS_Std_00013]). Voor berichtenprotocollen en transformers stelt std bovendien Std_MessageTypeType met de literals STD_MESSAGETYPE_REQUEST (0x00) en STD_MESSAGETYPE_RESPONSE (0x01) beschikbaar ([SWS_Std_91001], [SWS_Std_00017]) evenals het functiepointertype Std_ExtractProtocolHeaderFieldsType voor de extractie van protocolheaders ([SWS_Std_91003]).
De module comstack gebruikt op haar beurt de basistypen van platform en std om de gehele buffer- en gegevensuitwisseling in de communicatiestack te structureren. De centrale interfacestructuur is PduInfoType, die de datapointer SduDataPtr (uint8*), de metadatapointer MetaDataPtr en de bufferlengte SduLength van het type PduLengthType bundelt ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). De I-PDU-identificatie vindt plaats via PduIdType ([SWS_COMTYPE_00005]). Voor het beheer van gehele communicatiekanalen en deelnetwerken definieert comstack de kanaalidentificator NetworkHandleType ([SWS_COMTYPE_00038]) en de deelnetwerkidentificator PNCHandleType ([SWS_COMTYPE_00036]), die bijvoorbeeld worden gebruikt in de Synchronized PNC Shutdown van ComM en Nm (SWS_COMManager p. 171).
Bij gesegmenteerde transportprotocoloverdrachten (TP) wordt de bufferonderhandeling afgehandeld via de retourtypen BufReq_ReturnType en de structuur RetryInfoType ([SWS_COMTYPE_00012]). Bij synchrone kopieeraanroepen zoals CopyTxData of CopyRxData tussen modules zoals CanTp, PduR, DCM, DoIP of SecOC signaleert BUFREQ_OK de succesvolle kopieerbewerking, terwijl BUFREQ_E_BUSY meldt dat er tijdelijk onvoldoende buffer beschikbaar is en een nieuwe poging mag plaatsvinden (SWS_DiagnosticCommunicationManager p. 291, SWS_SecureOnboardCommunication p. 76). Via RetryInfoType met parameters zoals TP_CONFPENDING of TP_DATACONF wordt gewaarborgd dat gegevens voor eventuele herhalingen in de buffer blijven of na bevestiging worden vrijgegeven (SWS_IntrusionDetectionSystemManager p. 49).
Sequentiediagram: Gesegmenteerd ontvangst- en bufferpad van een transportprotocol met gebruik van ComStack_Types (PduInfoType, BufReq_ReturnType). Bronnen: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274
Synchronisatie, re-entrantie en taakcontexten
Aangezien de modules platform, std en comstack zuivere headerbestanden zonder uitvoerbare objectbestanden zijn, implementeren ze van nature geen cyclische MainFunctions en hebben ze geen eigen taakcontexten (SWS_StandardTypes p. 27). Ze definiëren echter wel de signaturen en typeconventies voor functies die over laaggrenzen heen worden aangeroepen. Alle typedefinities zijn zo ontworpen dat ze onbeperkt re-entrant en toestandloos kunnen worden overgedragen (SWS_CANInterface p. 87).
Het praktische gebruik van de typen vindt plaats in in hoge mate asynchrone en gelijktijdige omgevingen. Gegevensontvangst-callbacks zoals CanIf_RxIndication of Dcm_CopyRxData, die PduInfoType en PduIdType gebruiken, mogen expliciet in de interruptcontext worden uitgevoerd (SWS_CANInterface p. 164, SWS_DiagnosticCommunicationManager p. 274). Daarentegen worden routingbeslissingen, bufferallocaties of cyclische overdrachten verwerkt in periodieke taken van de hogere lagen (bijv. SoAd_MainFunction) (SWS_SocketAdaptor p. 104). Aangezien pointerstructuren zoals PduInfoType kunnen worden gedeeld tussen interruptniveau en taakniveau, berust de thread-veilige synchronisatie door middel van exclusieve gebieden (bescherming tegen gelijktijdigheid) bij de aanroepende en implementerende BSW-modules.
Typische levenscycli en bedrijfsmodi
Zuivere typedefinities zijn niet onderhevig aan een runtime-levenscyclus en hebben noch initialisatie- noch shutdownfuncties (SWS_StandardTypes p. 27). Ze moeten tijdens compilatietijd vóór alle verwerkende modules statisch zijn geïncludeerd. Ze vormen echter het normatieve raamwerk voor het afbeelden en bewaken van de levenscyclus van andere BSW-modules: voor gestandaardiseerde versieopvraging specificeert std de structuur Std_VersionInfoType, die vendorID, moduleID en de softwareversiestanden (sw_major_version, sw_minor_version, sw_patch_version) bevat ([SWS_Std_00015]).
Bovendien ondersteunen typen zoals NetworkHandleType en PNCHandleType het overkoepelende netwerk- en modusbeheer tijdens wisselingen van bedrijfsmodi zoals startup, normale werking, sleep en wakeup ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). Zo stuurt ComM aan de hand van deze identificatoren gecoördineerde uitschakelingen en toestandswisselingen in het deelnetwerkverband (SWS_COMManager p. 171, SWS_NetworkManagementInterface p. 106).
Foutafhandeling, DET-tracing en statuscodering
Het modulecluster biedt geen eigen actieve foutafhandeling en meldt noch ontwikkelingsfouten aan DET noch productiefouten aan DEM (SWS_StandardTypes p. 27). In plaats daarvan normeert het het platformbrede terugkoppelingsformaat: het fundamentele type Std_ReturnType is gebaseerd op uint8 en dient over alle lagen heen als standaardresultaat van synchrone aanroepen ([SWS_Std_00005], BSWUMLModelModelingGuide p. 28). Standaard vertegenwoordigt E_OK (0x00u) de succesvolle uitvoering en E_NOT_OK (0x01u) een generieke fout ([SWS_Std_00006]). Wegens compatibiliteit met ISO 17356-3 (OSEK OS) wordt E_OK via een beveiligingscontrole (STATUSTYPEDEFINED) beschermd tegen meervoudige definities (AUTOSAR_SRS_BSWGeneral p. 62).
De bitlay-out van Std_ReturnType volgt een vast gedefinieerde partitionering: de bits 0 tot en met 5 (bereik 0x00 tot 0x3F) zijn gereserveerd voor gestandaardiseerde en modulespecifieke retourwaarden respectievelijk applicatiespecifieke ApplicationError-codes in client/server-operaties ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Modulespecifieke uitbreidingen worden in UML-modellen opgenomen als klasse met het stereotype «extra_literals» (BSWUMLModelModelingGuide p. 33). De bits 6 en 7 (waardebereik 0x40, 0x80, 0xC0) zijn strikt gereserveerd voor infrastructuur-fouttoestanden van de RTE (AUTOSAR_CP_SWS_StandardTypes p. 15). Voor datatransformaties in de RTE declareert std bovendien de structuur Std_TransformerError, bestaande uit errorCode ([SWS_Std_00022]) en transformerClass ([SWS_Std_00021]), waarmee foutenketens bij de serialisatie of E2E-beveiliging naadloos kunnen worden getraceerd.
Deze handleiding is gebaseerd op de normatieve specificaties van AUTOSAR Classic Platform Release R20-11 voor StandardTypes, PlatformTypes en CommunicationStackTypes.
Geen elementgegevens voor deze release
ComStack
Variables of this type shall be used to store the result of a buffer request.
typedef enum { BUFREQ_OK, BUFREQ_E_NOT_OK, BUFREQ_E_BUSY, BUFREQ_E_OVFL } BufReq_ReturnType;Variables of the type Network Handle Type shall be used to store the identifier of a communication channel.
typedef uint8 NetworkHandleType;Variables of this type shall be used to store the basic information about a PDU of any type, namely a pointer variable pointing to its SDU (payload), a pointer to Meta Data of the PDU, and the corresponding length of the SDU in byt es.
typedef struct { uint8* SduDataPtr; uint8* MetaDataPtr; PduLengthType SduLength; } PduInfoType;This type shall be used within the entire AUTOSAR Com Stack of an ECU except for bus drivers.
typedef uint16 PduLengthType;Used to store the identifier of a partial network cluster.
typedef uint8 PNCHandleType;Variables of this type shall be used to store the information about Tp buffer handling.
typedef struct { TpDataStateType TpDataState; PduLengthType TxTpDataCnt; } RetryInfoType;Variables of this type shall be used to store the state of TP buffer.
typedef enum { TP_DATACONF, TP_DATARETRY, TP_CONFPENDING } TpDataStateType;Specify the parameter to which the value has to be changed (BS or STmin).
typedef enum { TP_STMIN, TP_BS, TP_BC } TPParameterType;Platform
This standard AUTOSAR type shall only be used together with the definitions TRUE and FALSE.
typedef unsigned char boolean;This standard AUTOSAR type shall be a void pointer to const. Note: This type shall be used for buffers that are passed to the callee.
typedef const void* ConstVoidPtr;This symbol shall be defined as #define having one of the values MSB_FIRST or LSB_FIRST according to the platform.
This symbol shall be defined as #define having one of the values HIGH_BYTE_FIRST or LOW_ BYTE_FIRST according to the platform.
This symbol shall be defined as #define having one of the values CPU_TYPE_8, CPU_TYPE_16, CPU_TYPE_32 or CPU_TYPE_64 according to the platform.
This standard AUTOSAR type shall follow the 32-bit binary interchange format according to IEEE 754-2008 with encoding parameters specified in chapter 3.6, table 3.5, column "binary32".
typedef float float32;This standard AUTOSAR type shall follow the 64-bit binary interchange format according to IEEE 754-2008 with encoding parameters specified in chapter 3.6, table 3.5, column "binary64".
typedef double float64;This optimized AUTOSAR type shall be at least 16 bit signed.
typedef signed int sint16_least;This optimized AUTOSAR type shall be at least 32 bit signed.
typedef signed int sint32_least;This optimized AUTOSAR type shall be at least 8 bit signed.
typedef signed int sint8_least;The symbols TRUE and FALSE shall be defined as follows: #ifndef TRUE #define TRUE 1 #endif #ifndef FALSE #define FALSE 0 #endif
This optimized AUTOSAR type shall be at least 16 bit unsigned.
typedef unsigned int uint16_least;This optimized AUTOSAR type shall be at least 32 bit unsigned.
typedef unsigned int uint32_least;This optimized AUTOSAR type shall be at least 8 bit unsigned.
typedef unsigned int uint8_least;Std
Because E_ OK is already defined within OSEK, the symbol E_ OK has to be shared. To avoid name clashes and redefinition problems, the symbols have to be defined in the following way (approved within implementation): #ifndef STATUSTYPEDEFINED #define STATUSTYPEDEFINED #define E_ OK 0x00u typedef unsigned char Status Type; /* OSEK compliance */ #endif #define E_ NOT_ OK 0x01u
#define E_OK 0x00u #define E_NOT_OK 0x01uThe symbols STD_ ACTIVE and STD_ IDLE shall be defined as follows: #define STD_ ACTIVE 0x01u /* Logical state active */ #define STD_ IDLE 0x00u /* Logical state idle */
#define STD_ACTIVE 0x01u #define STD_IDLE 0x00uType for the function pointer to extract the relevant protocol header fields of the message and the type of the message result of a transformer. - At the time being, this is limited to the types used for C/ S communication (i.e., REQUE ST and RESPONSE and OK and ERROR).
typedef Std_ReturnType (* Std_ExtractProtocolHeaderFieldsType)(const uint8* buffer, uint32 bufferLength, Std_MessageTypeType* messageType, Std_MessageResultType* messageResult);The symbols STD_ HIGH and STD_ LOW shall be defined as follows: #define STD_ HIGH 0x01u /* Physical state 5V or 3.3V */ #define STD_ LOW 0x00u /* Physical state 0V */
#define STD_HIGH 0x01u #define STD_LOW 0x00uThis type is used to encode different types of results for response messages. - Currently this encoding is limited to the distinction between OK and ERROR responses.
typedef uint8 Std_MessageResultType;This type is used to encode the different type of messages. - Currently this encoding is limited to the distinction between requests and responses in C/ S c ommunication.
The symbols STD_ ON and STD_ OFF shall be defined as follows: #define STD_ ON 0x01u #define STD_ OFF 0x00u
#define STD_ON 0x01u #define STD_OFF 0x00uThis type can be used as standard API return type which is shared between the RTE and the BSW modules. It shall be defined as follows: typedef uint8 Std_ Return Type;
typedef uint8 Std_ReturnType;-
typedef uint8 Std_TransformerClass;-
typedef uint8 Std_TransformerError;- Tags: atp.Status=draft
typedef uint8 Std_TransformerForward;- Tags: atp.Status=draft
typedef uint8 Std_TransformerForwardCode;Module im Cluster
Compiler Abstraction (Compiler)
AUTOSAR Classic Special Files-Modul Compiler Abstraction (Compiler, Spezifikation: AUTOSAR_SWS_CompilerAbstraction.pdf).
Communication Stack Types (ComStack_Types)
Standardized types, PDU identifiers, lengths, and buffer request types (PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType) used across all communication layers.
Memory Mapping (MemMap)
AUTOSAR Classic Special Files-Modul Memory Mapping (MemMap, Spezifikation: AUTOSAR_CP_SWS_MemoryMapping.pdf, AUTOSAR_SWS_MemoryMapping.pdf).
Platform Types (Platform_Types)
Platform-specific fundamental data types (integers, booleans, floating-point numbers) mapped to CPU architecture primitives.
Standard Types (Std_Types)
Standard types, return codes (Std_ReturnType, E_OK, E_NOT_OK), version info structures, and error codes shared across the entire AUTOSAR architecture.
gemini-3.8-flash-low· 2026-10-13 · Duits origineel