Figure 2.24: Std_ReturnType Extensions example

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Typmodellierungsprofil (AUTOSAR BSW UML Modeling Guide).
• Technischer Zweck: Formale Modellierung der typisierten Erweiterung des standardisierten Basistyps Std_ReturnType für Basic-Software-Module (BSW) am konkreten Beispiel des Crypto Service Manager (Csm). Das Modell definiert, wie modulspezifische Fehler- bzw. Statuscodes unter Wahrung der Typ- und Wertebereichskompatibilität zu Std_Types spezifiziert werden.

2. Komponenten, Entitäten & Schnittstellen

• Std_Types::Std_Types::Std_ReturnType [Stereotyp: «type»]:
  • AUTOSAR-Basistyp (abgebildet auf uint8).
  • Standard-Literale:
    • + E_OK = 0 (Erfolgreicher Aufruf)
    • + E_NOT_OK = 1 (Generischer Fehler)
  • Wertebereichseinschränkung [Stereotyp: «range»]:
    • + 0x02-0x3F (Dezimal 2–63; normativ reserviertes Wertefenster für modulspezifische Erweiterungen).
• Csm_Types::Csm_ReturnType [Stereotyp: «extra_literals»]:
  • Spezialisierter Rückgabetyp des CSM-Moduls innerhalb des Namespace Csm_Types.
  • Modulspezifische Literale (liegen vollständig im definierten Bereich 0x02-0x3F):
    • + CSM_E_BUSY = 2 (Kryptografischer Treiber/Job belegt)
    • + CSM_E_SMALL_BUFFER = 3 (Zielpuffer unzureichend)
    • + CSM_E_ENTROPY_EXHAUSTION = 4 (Entropiequelle erschöpft)
• Beziehungen:
  • Generalisierung (UML-Vererbung): Csm_ReturnType erbt von Std_ReturnType. Modellsemantisch bedeutet dies, dass Csm_ReturnType vollständig kompatibel zu Std_ReturnType ist und die Basis-Literale E_OK/E_NOT_OK einschließt, während «extra_literals» neue Aufzählungswerte im zulässigen «range»-Intervall deklariert.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammcharakter: Statische Typdefinition; kein eigenständiger Ablauf modelliert.
• Laufzeit-Interaktion:
  • Synchrone API-Rückgabe: CSM-Schnittstellen (z. B. Csm_Encrypt, Csm_KeyElementSet) liefern zur Laufzeit einen skalaren uint8-Wert zurück.
  • Fehlerpfade: Ein Aufrufer (z. B. Applikations-SW-C über RTE oder SecOC) verarbeitet E_OK (0) als Erfolgsbedingung. Weicht der Rückgabewert ab, kann der Aufrufer entweder generisch auf != E_OK prüfen oder selektiv auf Fehlerzustände wie CSM_E_BUSY (Re-Triggering/Queueing) bzw. CSM_E_SMALL_BUFFER (Pufferanpassung) verzweigen.

4. Normative Relevanz & Entwickler-Hinweise

• C-Header-Generierung (Std_Types.h & Csm_Types.h):
  • Da ANSI-C keine Vererbung unterstützt, bleibt Std_ReturnType global als typedef uint8 Std_ReturnType; definiert.
  • Die Literale aus «extra_literals» werden im Modul-Header (Csm_Types.h) als C-Präprozessor-Makros generiert:

    #define CSM_E_BUSY               ((Std_ReturnType)0x02U)
    #define CSM_E_SMALL_BUFFER       ((Std_ReturnType)0x03U)
    #define CSM_E_ENTROPY_EXHAUSTION ((Std_ReturnType)0x04U)

• Wertebereichs-Restriktion (0x02 bis 0x3F):
  • Modulspezifische Return-Werte müssen zwingend in diesem Fenster liegen.
  • Werte ab 0x40 (Bit 6 und Bit 7 gesetzt) sind für AUTOSAR-interne Protokolle, RTE-Infrastrukturfehler (RTE_E_...) oder Overlay-Flags reserviert. Die Überschreitung von 0x3F verletzt die Spezifikationskonformität des BSW-Moduls.
• API-Vertrag: Alle BSW-Module mit spezialisierten Fehlercodes müssen typkompatibel zu Std_ReturnType bleiben, um nahtlos über generische RTE-Ports und Standard-BSW-Schnittstellen ausgetauscht werden zu können.