Standard Types (Std_Types)

Das Modul std stellt über Std_Types.h plattformweit einheitliche Typen und Konstanten bereit, enthält aber weder Code noch Konfiguration. Zentral ist Std_ReturnType (uint8) mit E_OK und E_NOT_OK. Module dürfen eigene Werte nur im Bereich 0x02–0x3F mit Modulpräfix definieren, denn Bit 7 und Bit 8 sind der RTE vorbehalten [SWS_Std_00011]. Daneben liefert das Modul die Konstanten STD_HIGH/STD_LOW, STD_ON/STD_OFF und STD_ACTIVE/STD_IDLE, den Typ Std_VersionInfoType für die Versionsabfrage sowie Transformer- und Nachrichtentypen für die Client-Server-Kommunikation. In R20-11 bindet der Header außerdem Compiler.h ein SRS BSWGeneral S. 62.

mehr ›

Das Modul std ist ein reiner Typ-Header. Über Std_Types.h stellt es Typen und Symbole bereit, aber keine Funktionen [SWS_Std_00005]. In R20-11 bindet der Header Platform_Types.h und Compiler.h ein und definiert Std_ReturnType sowie die Werte E_OK/E_NOT_OK und die STD_*-Konstanten. Jedes Modul, das diese Typen nutzt, bindet ihn ein SRS BSWGeneral S. 62. Konfiguration und eigene Fehlerbehandlung gibt es laut späterer Spezifikationsfassung nicht; für R20-11 dürfte das ebenso gelten (Interpretation) SWS StandardTypes S. 27. Frage (offen)

Kontextdiagramm: Std_Types.h als gemeinsame Typbasis für BSW-Module, CDDs, RTE und Transformer. Quellen: SRS BSWGeneral S. 62, CDD Guideline S. 14

Kern des Moduls ist Std_ReturnType (uint8) mit den Werten E_OK (0) und E_NOT_OK (1). Der Bereich 0x02–0x3F ist für modulspezifische Fehler mit Modulpräfix vorgesehen; Bit 7 und Bit 8 legt die RTE-Spezifikation fest [SWS_Std_00011]. Beispiele für solche Erweiterungen sind CAN_BUSY und Csm_ReturnType BSWUML Guide S. 29. E_OK wird wegen OSEK über STATUSTYPEDEFINED abgesichert [SWS_Std_00006].

Kontextdiagramm (Typstruktur): Standardwerte, modulspezifischer Bereich und RTE-reservierte Bits von Std_ReturnType. Quellen: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes S. 15

Hinzu kommen drei Konstantenpaare mit jeweils 0x01u/0x00u: STD_HIGH/STD_LOW für physikalische Pegel, STD_ON/STD_OFF als Schalter und STD_ACTIVE/STD_IDLE für logische Zustände ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType transportiert Hersteller-ID, Modul-ID und Softwareversion für die synchrone, reentrante Funktion <Ma>_GetVersionInfo [SWS_Std_00015].

Für die Datentransformation definiert std zwei Typen für Transformer-Fehler: Std_TransformerError, eine Struktur aus Fehlercode und Transformer-Klasse, und Std_TransformerClass [SWS_Std_00021]. Die RTE reicht diesen Fehler über den optionalen Parameter transformerError weiter SWS RTE S. 731. Für Client-Server-Kommunikation kodieren Std_MessageTypeType und Std_MessageResultType Anfrage/Antwort und OK/ERROR. Ein Funktionszeiger vom Typ Std_ExtractProtocolHeaderFieldsType liest beide Werte aus einem Transformer-Header [SWS_Std_91003]. Die Forward-Typen sind in R20-11 noch Entwurf [SWS_Std_00029].

mehr ›

Rolle und Systemgrenze: ein reiner Typ-Header ohne Laufzeitverhalten

Das Modul std (Standard Types) enthält keine Funktionen. Es stellt ausschließlich Typen und Symbole bereit, die über Std_Types.h verfügbar sind. Jedes Requirement des Moduls nennt diesen Header als Bezugsquelle, etwa [SWS_Std_00005] und [SWS_Std_00015]. Die Spezifikation hält ausdrücklich fest: Der Header liefert weder Code noch benötigt er andere BSW-Module, er hat keine Konfiguration und keine eigene Fehlerbehandlung SWS StandardTypes S. 27. Diese Formulierungen stammen aus der Fassung ab R23-11. Für R20-11 dürfte dasselbe gelten, weil die R20-11-Requirements ausschließlich Typ- und Symboldefinitionen enthalten (Interpretation). Frage Q-8e4c66ae80752d38 (offen)

Der Zweck ist ein einheitlicher, plattformweiter Zugriff auf Standardtypen. Die BSW-Anforderung an den Standard-Typ-Header verlangt deshalb: Jedes Modul, das AUTOSAR-Ganzzahltypen oder den Standard-Rückgabetyp verwendet, bindet Std_Types.h ein SRS BSWGeneral S. 62. Der Rückgabetyp Std_ReturnType wird ausdrücklich zwischen RTE und BSW-Modulen geteilt [SWS_Std_00005]. In der Methodik sind die Standardtypen zusätzlich als ARXML-Artefakt „AUTOSAR Standard Types“ beschrieben Methodology S. 400.

Kontextdiagramm: Std_Types.h bindet Plattform- und Compiler-Header ein und wird von BSW-Modulen, CDDs, RTE und Transformern als gemeinsame Typbasis genutzt. Quellen: SRS BSWGeneral S. 62, CDD Guideline S. 14, [SWS_Std_00005], [SWS_Std_00021]

Aufbau von Std_Types.h und Einbindung in den Header-Baum

Für R20-11 legt die BSW-Anforderung fest, was Std_Types.h leisten muss SRS BSWGeneral S. 62:

• den plattformspezifischen Typ-Header Platform_Types.h einbinden,
• den compilerspezifischen Header Compiler.h einbinden,
• Std_ReturnType definieren,
• Werte für E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE und STD_IDLE festlegen.

In der späteren Fassung derselben Anforderung fehlt die Einbindung von Compiler.h RS BSWGeneral S. 60. Das passt zur Änderungshistorie: In R22-11 wurde die veraltete Compiler-Abstraktion aus einem Std-Requirement entfernt, und NULL_PTR kam erst mit R21-11 hinzu SWS StandardTypes S. 1. Für R20-11 gehört Compiler.h also zur Include-Kette, ein NULL_PTR aus Std_Types.h dagegen noch nicht.

Eine Besonderheit betrifft E_OK. Das Symbol ist bereits in OSEK definiert und muss deshalb gemeinsam genutzt werden. [SWS_Std_00006] schreibt einen Schutz über STATUSTYPEDEFINED vor: Innerhalb des Schutzes werden E_OK (0x00u) und StatusType definiert, E_NOT_OK (0x01u) steht außerhalb. Die BSW-Anforderung enthält dieselbe Implementierungsnotiz mit Verweis auf ISO 17356-3 SRS BSWGeneral S. 62. Wie ein Complex Device Driver den Header in seine Include-Struktur einordnet, zeigt das Schaubild zur CDD-Header-Struktur CDD Guideline S. 14.

Std_ReturnType: Wertebereich, Bitlayout und modulspezifische Erweiterungen

Std_ReturnType ist von uint8 abgeleitet. Die Standardwerte sind E_OK (0) und E_NOT_OK (1); der Bereich 0x02–0x3F steht für anwenderspezifische Fehler zur Verfügung [SWS_Std_00005]. [SWS_Std_00011] präzisiert diese Regel:

• Normalerweise wird der Typ mit E_OK oder E_NOT_OK verwendet.
• Reichen diese Werte nicht, dürfen eigene Werte in den sechs niederwertigen Bits definiert werden, benannt mit dem Modulpräfix.
• Bit 7 und Bit 8 sind reserviert. Sie werden, wie das Layout insgesamt, durch die RTE-Spezifikation festgelegt.

Das Schaubild zum Layout stellt genau diese Aufteilung dar SWS StandardTypes S. 15.

Die RTE-Spezifikation beschreibt Std_ReturnType als Typ für Status- und Fehlerwerte von API-Funktionen; der Wert 0 ist für „kein Fehler aufgetreten“ reserviert SWS RTE S. 675. Laut BSW-Modellierungsleitfaden ist er der einzige Rückgabetyp, der in Client-Server-Operationen von Service-Interfaces erlaubt ist BSWUML Guide S. 28. Ein Beispiel für eine modulspezifische Erweiterung ist CAN_BUSY (0x02) des CAN-Treibers. Can_Write() liefert diesen Wert, wenn kein Sendeobjekt frei ist SWS CANDriver S. 54.

Kontextdiagramm (Typstruktur): Std_ReturnType teilt sich in Standardwerte, einen modulspezifischen Bereich 0x02–0x3F und zwei durch die RTE reservierte Bits; Modulerweiterungen wie Csm_ReturnType oder CAN_BUSY belegen nur den freien Bereich. Quellen: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes S. 15, BSWUML Guide S. 29, SWS CANDriver S. 54

Im UML-Modell der BSW wird eine solche Erweiterung als Klasse <Ma>_ReturnType mit Stereotyp «extra_literals» modelliert. Ihre Werte tragen das Modulpräfix und liegen im Bereich 0x02–0x3f BSWUML Guide S. 28. Das Beispiel Csm_ReturnType mit CSM_E_BUSY, CSM_E_SMALL_BUFFER und CSM_E_ENTROPY_EXHAUSTION zeigt das Muster BSWUML Guide S. 29. Brauchen mehrere Module eines Stacks dieselbe Erweiterung, muss sie nicht für jedes Modul getrennt definiert werden BSWUML Guide S. 33. Die R23-11-Fassung sieht dafür eine generische Klasse mit «generic_type» vor, von der die modulspezifischen Erweiterungen abgeleitet werden TR BSWUML Guide S. 37.

Aktivitätsdiagramm: Entscheidung, ob und wie ein Modul Std_ReturnType um eigene Werte erweitert. Quellen: [SWS_Std_00011], BSWUML Guide S. 28, BSWUML Guide S. 33, TR BSWUML Guide S. 37

Symbolische Konstanten für Pegel, Schalter und Zustände

Neben den Rückgabewerten definiert Std_Types.h drei Konstantenpaare. Alle drei verwenden die Zahlenwerte 0x01u und 0x00u, sind aber unterschiedlich kommentiert ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]):

Paar	Werte	Bedeutung laut Definition
STD_HIGH / STD_LOW	0x01u / 0x00u	physikalischer Zustand 5 V oder 3,3 V / 0 V
STD_ON / STD_OFF	0x01u / 0x00u	Ein/Aus, ohne weiteren Kommentar
STD_ACTIVE / STD_IDLE	0x01u / 0x00u	logischer Zustand aktiv / idle

Ein typischer Nutzer von STD_HIGH/STD_LOW ist der DIO-Treiber: Sein Lesedienst meldet genau einen dieser beiden Pegel zurück SWS DIO S. 37. STD_ON/STD_OFF dienen als Pre-compile-Schalter. Ein Beispiel ist EEP_21_LDEXT_VERSION_INFO_API STD_ON in der allgemeinen BSW-Spezifikation SWS BSWGeneral S. 76, ein weiteres sind die optionalen API-Schalter des GPT-Treibers SWS GPT S. 48.

Versionsabfrage über Std_VersionInfoType

Std_VersionInfoType ist eine Struktur mit folgenden Elementen: vendorID und moduleID (je uint16) sowie sw_major_version, sw_minor_version und sw_patch_version (je uint8). Über <Module name>_GetVersionInfo() wird damit die Version eines BSW-Moduls abgefragt [SWS_Std_00015]. Die allgemeine BSW-Spezifikation legt für diese Funktion fest SWS BSWGeneral S. 76:

• Sie arbeitet synchron und ist reentrant.
• Sie hat genau einen Parameter dieses Typs.
• Ihre Verfügbarkeit wird pro Modul zur Pre-compile-Zeit über <Ma>VersionInfoApi konfiguriert.

Die Namensregel GetVersionInfo nennt die BSW-Anforderung mit dem Beispiel Eep_21_LDExt_GetVersionInfo SRS BSWGeneral S. 60.

Konkrete Umsetzungen gibt es in vielen Modulen. Can_GetVersionInfo weist bei aktivierter Entwicklungsfehlererkennung einen Nullzeiger mit CAN_E_PARAM_POINTER zurück SWS CANDriver S. 57. Adc_GetVersionInfo prüft entsprechend auf ADC_E_PARAM_POINTER SWS ADCDriver S. 80. Der NVRAM-Manager zeigt den Aufruf als einfachen synchronen Austausch zwischen Nutzer und Modul SWS NvM S. 158.

Sequenzdiagramm: Ein Nutzer fragt die Version eines Moduls synchron ab; bei Nullzeiger und aktiver Entwicklungsfehlererkennung meldet das Modul einen Fehler, sonst füllt es Std_VersionInfoType. Quellen: [SWS_Std_00015], SWS BSWGeneral S. 76, SWS CANDriver S. 57, SWS NvM S. 158

Transformer- und Nachrichtentypen für die Datentransformation

Für Transformer-Ketten stellt std mehrere Typen bereit. Std_TransformerError ist in R20-11 eine Struktur aus errorCode (uint8) und transformerClass vom Typ Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass ist von uint8 abgeleitet und kennt fünf Werte [SWS_Std_00024]: STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03) und STD_TRANSFORMER_CUSTOM (0xFF).

Die Kurzsignatur im API-Verzeichnis führt Std_TransformerError als typedef uint8. Maßgeblich ist jedoch die Strukturdefinition des Requirements. Spätere Fassungen typisieren errorCode als eigenen Typ Std_TransformerErrorCode, dessen Bedeutung je Transformer-Kette festgelegt wird SWS StandardTypes S. 17.

Die RTE übergibt diesen Typ als optionalen OUT-Parameter transformerError an ihre APIs, etwa bei Rte_Call SWS RTE S. 731, Rte_Read SWS RTE S. 720 und Rte_Result SWS RTE S. 750. Die Plug-in-Schnittstellen beschreiben ihn als den Fehler, der bei der Ausführung der Transformer-Kette aufgetreten ist SWS RTE S. 969.

Std_TransformerForward und Std_TransformerForwardCode sind in R20-11 als Entwurf (draft) markiert. Der Forward-Code kennt E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ und E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). In späteren Fassungen nimmt Rte_Send einen optionalen forwardedCode dieses Typs entgegen SWS RTE S. 704. Vermutlich dient er dazu, empfangene Safety-Fehler beim Weiterleiten erneut abzubilden, wie es die E2E-Forward-Funktionen beschreiben SWS E2ELibrary S. 107 (Interpretation). Frage Q-f0d374b3b793c868 (offen) Laut Änderungshistorie wurde die Struktur Std_TransformerForward in R22-11 entfernt SWS StandardTypes S. 1.

Sequenzdiagramm: Ein Transformer-Fehler gelangt neben dem Std_ReturnType als Std_TransformerError mit Fehlercode und Transformer-Klasse zur SW-C. Quellen: [SWS_Std_00021], [SWS_Std_00024], SWS RTE S. 731, SwCluster Guideline S. 245, SWS RTE S. 774

Für die Client-Server-Kommunikation gibt es zwei Kodierungstypen, bei denen 0x02–0x3F jeweils für künftige Werte reserviert sind:

• Std_MessageTypeType unterscheidet Anfrage (STD_MESSAGETYPE_REQUEST, 0x00) und Antwort (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
• Std_MessageResultType kodiert das Ergebnis einer Antwort: STD_MESSAGERESULT_OK (0x00) oder STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

Der Funktionszeigertyp Std_ExtractProtocolHeaderFieldsType beschreibt eine synchrone, reentrante Funktion. Sie extrahiert beide Werte aus dem Protokoll-Header eines Transformers in einem Puffer und liefert ein Std_ReturnType [SWS_Std_91003]. Transformer erhalten einen solchen Zeiger optional als Argument ihrer inversen Funktion ASWS TransformerGeneral S. 40. Der SOME/IP-Transformer stellt mit SomeIpXf_ExtractProtocolHeaderFields eine passende Implementierung bereit SWS SOMEIPTransformer S. 61. Die E2E-Profile 4m, 7m, 8m und 44m werten die beiden Werte in ihren Prüffunktionen aus SWS E2ELibrary S. 108.

Sequenzdiagramm: Der E2E-Transformer extrahiert für PXXm-Profile über den übergebenen Funktionszeiger Nachrichtentyp und -ergebnis und prüft nur bei E_OK weiter. Quellen: [SWS_Std_91003], ASWS TransformerGeneral S. 40, SWS E2ETransformer S. 45, SWS SOMEIPTransformer S. 61, SWS E2ELibrary S. 108

Verhalten im Fehlerfall

Das Modul selbst erkennt und meldet keine Fehler. Die Fassung ab R23-11 stellt fest, dass die Standardtypen keine Fehlerbehandlung vorsehen und keine Security-Events unterstützen SWS StandardTypes S. 27; für R20-11 dürfte dasselbe gelten (Interpretation). Frage (offen) Fehlerverhalten entsteht daher nur in den Modulen, die die Typen verwenden. Das Grundsignal ist E_NOT_OK [SWS_Std_00006]; seine konkrete Bedeutung legt das jeweilige API fest. Bei Adc_ReadGroup heißt es „keine Ergebnisse verfügbar oder Entwicklungsfehler“ SWS ADCDriver S. 61, bei CanIf_Transmit „Sendeanforderung nicht angenommen“ SWS CANInterface S. 87.

Feinere Fehlerbilder werden über modulspezifische Werte im Bereich 0x02–0x3F gemeldet [SWS_Std_00011], zum Beispiel CAN_BUSY SWS CANDriver S. 54. Aufrufer müssen also damit rechnen, dass ein Std_ReturnType mehr als zwei Werte annimmt. Ein Sonderfall sind Callbacks, die als AUTOSAR-Services über die RTE geroutet werden: Der Aufrufer darf zwar E_OK annehmen, doch können solche Callbacks etwa in partitionierten Systemen fehlschlagen SWS BSWGeneral S. 69.

In Transformer-Ketten wird ein Fehler zusätzlich zum Rückgabewert über Std_TransformerError mit Fehlercode und Transformer-Klasse gemeldet [SWS_Std_00021]. Die RTE erzeugt den optionalen Parameter transformerError nur, wenn für den Port die Fehlerbehandlung transformerErrorHandling konfiguriert ist SWS RTE S. 774. Scheitert das Extrahieren der Header-Felder, liefert SomeIpXf_ExtractProtocolHeaderFields E_NOT_OK, etwa bei falscher Protokollversion oder zu kurzem Puffer SWS SOMEIPTransformer S. 61. Die E2E-Transformatorlogik setzt die Prüfung nur bei E_OK fort SWS E2ETransformer S. 45.

Weiterführende Detailbelege

• [SWS_Std_00005], [SWS_Std_00006], [SWS_Std_00011]: Rückgabetyp, Standardwerte mit OSEK-Schutz, Bitlayout und Erweiterungsregel.
• [SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]: die drei Konstantenpaare für physikalische Pegel, Schalter und logische Zustände.
• [SWS_Std_00015] zusammen mit SWS BSWGeneral S. 76: Versionsstruktur und Regeln für GetVersionInfo.
• [SWS_Std_00021], [SWS_Std_00024], [SWS_Std_00027], [SWS_Std_00029]: Transformer-Fehler- und Forward-Typen; die beiden letzten sind draft.
• [SWS_Std_91001], [SWS_Std_91002], [SWS_Std_91003], [SWS_Std_00017], [SWS_Std_00019]: Nachrichtentypen und Header-Extraktion für C/S-Kommunikation.
• SRS BSWGeneral S. 62: Inhalt und Include-Kette von Std_Types.h in R20-11.
• SWS StandardTypes S. 27 und SWS StandardTypes S. 1: fehlende Konfiguration und Fehlerbehandlung sowie Änderungshistorie (spätere Releases).