AUTOSAR Classic General & Standard Types

Das Modulcluster General & Standard Types stellt über die Header Platform_Types.h, Std_Types.h und ComStack_Types.h die hardwareunabhängige Basis für alle Datentypen, Statusrückmeldungen und Kommunikationspuffer der Classic Platform bereit (AUTOSAR_SRS_BSWGeneral S. 62). Es normiert grundlegende Architekturmerkmale wie Endianness-Modelle, standardisierte Rückgabewerte wie Std_ReturnType und Kommunikationsstrukturen wie PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Da es sich um reine Header-Definitionen ohne ausführbaren Code handelt, erfordert das Cluster weder eine Laufzeitkonfiguration noch besitzt es eigene Tasks oder eine aktive Fehlerbehandlung (SWS_StandardTypes S. 27).

mehr ›

Das Modulcluster General & Standard Types umfasst die drei Basis-Header platform (Platform_Types.h), std (Std_Types.h) und comstack (ComStack_Types.h). Als reine Typdefinitionen enthalten sie keinerlei ausführbaren Code und bedürfen keiner Konfiguration (SWS_StandardTypes S. 27). Sie bilden das plattformweite Fundament für eine hardwareunabhängige Typisierung, vereinheitlichen Compiler- und Hardware-Besonderheiten und versorgen alle BSW-Module und die RTE mit konsistenten Datenstrukturen (AUTOSAR_SRS_BSWGeneral S. 62).

Architekturdiagramm: Statische Schichten- und Inklusionsarchitektur des Modulclusters 'General & Standard Types' mit exportierten Typschnittstellen. Quellen: AUTOSAR_SRS_BSWGeneral S. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Die Inklusionshierarchie baut stufenweise aufeinander auf: Platform_Types.h kapselt plattformspezifische Eigenschaften wie den C99-Typ boolean ([SWS_Platform_00027]), universelle Pufferzeiger wie ConstVoidPtr ([SWS_Platform_91002]) sowie Symbole für die Register-Bit-Reihenfolge CPU_BIT_ORDER ([SWS_Platform_00038]) und die Speicher-Byte-Reihenfolge CPU_BYTE_ORDER ([SWS_Platform_00039]). Darauf aufbauend stellt Std_Types.h universelle Standardkonstanten wie STD_ON/STD_OFF ([SWS_Std_00010]), Modulversionsstrukturen über Std_VersionInfoType ([SWS_Std_00015]) sowie das fundamentale Statussystem Std_ReturnType mit E_OK und E_NOT_OK bereit ([SWS_Std_00005], [SWS_Std_00006]).

Für den AUTOSAR-Kommunikationsstack definiert ComStack_Types.h sämtliche protokollübergreifenden Schnittstellentypen wie PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) und die zentrale Pufferstruktur PduInfoType ([SWS_COMTYPE_00008]). In segmentierten Transportprotokollen (z. B. CanTp oder DoIP) steuert der Rückgabetyp BufReq_ReturnType gemeinsam mit RetryInfoType die synchrone Pufferreservierung und Datenkopie zwischen BSW-Schichten (SWS_DiagnosticCommunicationManager S. 291, [SWS_COMTYPE_00012]).

Sequenzdiagramm: Segmentierter Empfangs- und Pufferpfad eines Transportprotokolls unter Verwendung von ComStack_Types (PduInfoType, BufReq_ReturnType). Quellen: SWS_PDURouter S. 112, SWS_DiagnosticCommunicationManager S. 273, SWS_DiagnosticCommunicationManager S. 274

Obgleich das Cluster keine eigene Fehlerbehandlung oder DET-Meldungen besitzt (SWS_StandardTypes S. 27), strukturiert Std_ReturnType die Fehlerbehandlung des Gesamtsystems: Bits 0 bis 5 (0x00 bis 0x3F) sind für Standard- und Applikationsfehler reserviert, während Bits 6 und 7 exklusiv durch die RTE belegt werden ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes S. 15). Sämtliche Typdefinitionen sind für den reentranten Einsatz in Multitasking- und Interrupt-Kontexten spezifiziert (SWS_CANInterface S. 87).

mehr ›

Systemarchitektur & Rolle des Modulclusters

Das Modulcluster General & Standard Types bildet das fundamentale typologische und hardwareabstrahierende Fundament der AUTOSAR Classic Platform im Release R20-11. Es setzt sich aus den drei reinen Header-Modulen platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) und comstack ([SWS_COMTYPE_00005]) zusammen. Gemäß der BSW-Architektur stellen diese Module weder eigenen ausführbaren C-Code bereit noch fordern sie andere BSW-Treiber an (SWS_StandardTypes S. 27). Ihre zentrale Aufgabe besteht darin, Compiler- und Prozessorabhängigkeiten zu kapseln, plattformweit einheitliche Basistypen bereitzustellen und standardisierte Datenstrukturen für die Kommunikationsschichten zu etablieren.

Die Schichtenhierarchie folgt einer strengen, unidirektionalen Inklusionsordnung: Die Datei Platform_Types.h abstrahiert die Eigenschaften der zugrundeliegenden Mikrocontroller-Architektur (wie Register- und Speicheranordnung sowie C99-Elementartypen), während Std_Types.h darauf aufsetzt und universelle Rückgabewerte sowie Statuskonstanten definiert (AUTOSAR_SRS_BSWGeneral S. 62). Darauf aufbauend deklariert ComStack_Types.h sämtliche Bus- und protokollübergreifenden Datentypen für Netzwerke wie CAN, FlexRay, LIN und Ethernet sowie für Transportprotokolle nach ISO 15765-2 und Diagnoseprotokolle nach ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Durch diese Entkopplung wird gewährleistet, dass höhere Schichten wie die Laufzeitumgebung (RTE) und Applikations-Software-Components (SWCs) vollständig portabel bleiben (SWS_RTE S. 818).

Architekturdiagramm: Statische Schichten- und Inklusionsarchitektur des Modulclusters 'General & Standard Types' mit exportierten Typschnittstellen. Quellen: AUTOSAR_SRS_BSWGeneral S. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Zusammenspiel & Interaktionspfade zwischen den Modulen

Das Zusammenwirken innerhalb des Clusters basiert auf einer statischen Inklusionskette: ComStack_Types.h inkludiert Std_Types.h, welches seinerseits Platform_Types.h einbindet (RS_BSWGeneral S. 60). Das Modul platform definiert fundamentale Größen wie boolean, das zwingend auf den C99-Basistyp _Bool abzubilden ist ([SWS_Platform_00027]), und regelt dessen strenge Wertzuweisung über die Literale TRUE und FALSE ([SWS_Platform_00034]). Ferner werden generische Pufferzeiger wie ConstVoidPtr spezifiziert, die für unveränderliche Übergabepuffer an aufgerufene Funktionsschnittstellen genutzt werden ([SWS_Platform_91002]).

Zusätzlich harmonisiert platform die Hardware-Endians über standardisierte Präprozessorsymbole: Für die Bit-Reihenfolge in Registern wird CPU_BIT_ORDER auf MSB_FIRST oder LSB_FIRST festgelegt ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). Die Bytereihenfolge im physikalischen Speicher wird über CPU_BYTE_ORDER gesteuert, wobei HIGH_BYTE_FIRST (Big Endian, MSB an niedrigerer Adresse) von LOW_BYTE_FIRST (Little Endian, LSB an niedrigerer Adresse) unterschieden wird ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Strukturdiagramm: Speicherabbildung skalarer Multi-Byte-Werte bei Big-Endian (HIGH_BYTE_FIRST) vs. Little-Endian (LOW_BYTE_FIRST). Quellen: AUTOSAR_CP_SWS_PlatformTypes S. 16, AUTOSAR_CP_SWS_PlatformTypes S. 15, [SWS_Platform_00050], [SWS_Platform_00051]

Auf der nächsten Abstraktionsstufe definiert das Modul std universelle Symbole für Schaltzustände und logische Pegel: STD_HIGH (0x01u) und STD_LOW (0x00u) für physikalische Spannungspegel ([SWS_Std_00007]), STD_ON (0x01u) und STD_OFF (0x00u) für Aktivierungsmodi ([SWS_Std_00010]) sowie STD_ACTIVE (0x01u) und STD_IDLE (0x00u) für logische Ausführungszustände ([SWS_Std_00013]). Für Nachrichtenprotokolle und Transformer stellt std zudem Std_MessageTypeType mit den Literalen STD_MESSAGETYPE_REQUEST (0x00) und STD_MESSAGETYPE_RESPONSE (0x01) bereit ([SWS_Std_91001], [SWS_Std_00017]) sowie den Funktionszeigertyp Std_ExtractProtocolHeaderFieldsType zur Extraktion von Protokollheadern ([SWS_Std_91003]).

Das Modul comstack wiederum nutzt die Basistypen von platform und std, um den gesamten Puffer- und Datenaustausch im Kommunikationsstack zu strukturieren. Zentrale Schnittstellenstruktur ist PduInfoType, welche den Datenzeiger SduDataPtr (uint8*), den Metadatenzeiger MetaDataPtr sowie die Pufferlänge SduLength vom Typ PduLengthType bündelt ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Die I-PDU-Identifikation erfolgt über PduIdType ([SWS_COMTYPE_00005]). Für die Verwaltung ganzer Kommunikationskanäle und Teilnetze definiert comstack den Kanalkennzeichner NetworkHandleType ([SWS_COMTYPE_00038]) sowie den Teilnetzbezeichner PNCHandleType ([SWS_COMTYPE_00036]), die beispielsweise im Synchronized PNC Shutdown von ComM und Nm eingesetzt werden (SWS_COMManager S. 171).

In segmentierten Transportprotokollübertragungen (TP) wird die Pufferverhandlung über die Rückgabetypen BufReq_ReturnType und die Struktur RetryInfoType abgewickelt ([SWS_COMTYPE_00012]). Bei synchronen Kopieraufrufen wie CopyTxData oder CopyRxData zwischen Modulen wie CanTp, PduR, DCM, DoIP oder SecOC signalisiert BUFREQ_OK den erfolgreichen Kopiervorgang, während BUFREQ_E_BUSY mitteilt, dass temporär unzureichend Puffer bereitsteht und ein erneuter Versuch erfolgen darf (SWS_DiagnosticCommunicationManager S. 291, SWS_SecureOnboardCommunication S. 76). Über RetryInfoType mit Parametern wie TP_CONFPENDING oder TP_DATACONF wird sichergestellt, dass Daten für etwaige Wiederholungen im Puffer verbleiben oder nach Bestätigung freigegeben werden (SWS_IntrusionDetectionSystemManager S. 49).

Sequenzdiagramm: Segmentierter Empfangs- und Pufferpfad eines Transportprotokolls unter Verwendung von ComStack_Types (PduInfoType, BufReq_ReturnType). Quellen: SWS_PDURouter S. 112, SWS_DiagnosticCommunicationManager S. 273, SWS_DiagnosticCommunicationManager S. 274

Synchronisation, Reentranz und Task-Kontexte

Da die Module platform, std und comstack reine Header-Dateien ohne ausführbare Objektdateien sind, implementieren sie naturgemäß keine zyklischen MainFunctions und besitzen keine eigenen Task-Kontexte (SWS_StandardTypes S. 27). Sie definieren jedoch die Signaturen und Typenkonventionen für Funktionen, die über Schichtengrenzen hinweg aufgerufen werden. Sämtliche Typdefinitionen sind so ausgelegt, dass sie uneingeschränkt reentrant und zustandslos übergeben werden können (SWS_CANInterface S. 87).

Die praktische Nutzung der Typen findet in hochgradig asynchronen und nebenläufigen Umgebungen statt. Datenempfangs-Callbacks wie CanIf_RxIndication oder Dcm_CopyRxData, welche PduInfoType und PduIdType nutzen, dürfen explizit im Interrupt-Kontext ausgeführt werden (SWS_CANInterface S. 164, SWS_DiagnosticCommunicationManager S. 274). Im Gegensatz dazu werden Routing-Entscheidungen, Pufferallokationen oder zyklische Übertragungen in periodischen Tasks der oberen Schichten (z. B. SoAd_MainFunction) abgearbeitet (SWS_SocketAdaptor S. 104). Da Zeigerstrukturen wie PduInfoType zwischen Interrupt-Ebene und Task-Ebene geteilt werden können, obliegt die thread-sichere Synchronisation mittels Exklusiver Bereiche (Schutz vor Nebenläufigkeit) den aufrufenden und implementierenden BSW-Modulen.

Typische Lebenszyklen und Betriebsmodi

Reine Typdefinitionen unterliegen keinem Laufzeit-Lebenszyklus und besitzen weder Initialisierungs- noch Shutdown-Funktionen (SWS_StandardTypes S. 27). Sie müssen zur Übersetzungszeit vor allen verarbeitenden Modulen statisch inkludiert sein. Sie bilden jedoch das normative Gerüst zur Abbildung und Überwachung des Lebenszyklus anderer BSW-Module: Zur standardisierten Versionsabfrage spezifiziert std die Struktur Std_VersionInfoType, welche vendorID, moduleID sowie die Software-Versionsstände (sw_major_version, sw_minor_version, sw_patch_version) enthält ([SWS_Std_00015]).

Darüber hinaus unterstützen Typen wie NetworkHandleType und PNCHandleType das übergeordnete Netzwerk- und Modemanagement während Betriebsmodi-Wechseln wie Startup, Normalbetrieb, Sleep und Wakeup ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). So steuert der ComM anhand dieser Bezeichner koordinierte Abschaltungen und Zustandswechsel im Teilnetzwerkverbund (SWS_COMManager S. 171, SWS_NetworkManagementInterface S. 106).

Fehlerbehandlung, DET-Tracing und Statuskodierung

Das Modulcluster stellt keine eigene aktive Fehlerbehandlung bereit und meldet weder Entwicklungsfehler an das DET noch Produktionsfehler an das DEM (SWS_StandardTypes S. 27). Stattdessen normiert es das plattformweite Rückmeldeformat: Der fundamentale Typ Std_ReturnType basiert auf uint8 und dient über alle Schichten hinweg als Standardergebnis synchroner Aufrufe ([SWS_Std_00005], BSWUMLModelModelingGuide S. 28). Standardmäßig repräsentiert E_OK (0x00u) die erfolgreiche Ausführung und E_NOT_OK (0x01u) einen generischen Fehler ([SWS_Std_00006]). Aus Kompatibilitätsgründen mit ISO 17356-3 (OSEK OS) wird E_OK über eine Schutzprüfung (STATUSTYPEDEFINED) vor Mehrfachdefinitionen geschützt (AUTOSAR_SRS_BSWGeneral S. 62).

Das Bitlayout von Std_ReturnType folgt einer fest definierten Partitionierung: Die Bits 0 bis 5 (Bereich 0x00 bis 0x3F) sind für standardisierte und modulspezifische Rückgabewerte bzw. anwendungsspezifische ApplicationError-Codes in Client/Server-Operationen reserviert ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes S. 15). Modulspezifische Erweiterungen werden in UML-Modellen als Klasse mit dem Stereotyp «extra_literals» geführt (BSWUMLModelModelingGuide S. 33). Die Bits 6 und 7 (Wertebereich 0x40, 0x80, 0xC0) sind strikt für Infrastruktur-Fehlerzustände der RTE reserviert (AUTOSAR_CP_SWS_StandardTypes S. 15). Für Datentransformationen in der RTE deklariert std zusätzlich die Struktur Std_TransformerError, bestehend aus errorCode ([SWS_Std_00022]) und transformerClass ([SWS_Std_00021]), womit Fehlerketten bei der Serialisierung oder E2E-Absicherung lückenlos zurückverfolgt werden können.