Figure 6.1: Header File Structure for CDD

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Datei-Inklusionsstruktur (File Dependency Diagram) mit Dateisterotypen (« source ») und gerichteten Abhängigkeiten (« Include »).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Dokument AUTOSAR_CP_EXP_CDDDesignAndIntegrationGuideline (Kapitel 6, Header File Structure for CDD).
• Technischer Zweck: Definition der normativen Include-Hierarchie und Kapselungsgrenzen für Complex Device Driver (CDD). Es regelt die Trennung von öffentlichen APIs, Konfigurationsheadern, plattformspezifischen Typdefinitionen, Memory-Mapping-Mechanismen sowie BSW-Kernschnittstellen (RTE, Det, Dem).

2. Komponenten, Entitäten & Schnittstellen

Alle Entitäten sind als C-Quell- oder Headerdateien mit dem Stereotyp « source » modelliert:

• Zentrale Implementierungseinheit:
  • CDD_<MODULENAME>.c: Eine oder mehrere (mehrschichtige Box-Darstellung) C-Implementierungsdateien des Treibers. Enthält Funktionsdefinitionen, lokale Zustände und ISR-Handler.
• Öffentliche Schnittstellen & Typdefinitionen:
  • CDD_<MODULENAME>.h: Primärer externer API-Header des CDDs. Deklariert öffentliche Funktionen, Typen und Modul-Versions-IDs.
  • CDD_<MODULENAME>_Cfg.h: Konfigurationsheader (mehrschichtig dargestellt für Pre-Compile- und generierte Link-Time/Post-Build-Strukturen). Enthält Makros, Funktionsschalter (STD_ON/STD_OFF) und statische Konfigurationskonstanten.
  • Std_Types.h: Basis-Standarddatentypen von AUTOSAR (Std_ReturnType, E_OK, E_NOT_OK etc.).
  • Platform_Types.h: Hardware- und compilerspezifische Basisdatentypen (uint8, uint16, boolean etc.).
• System- & Integrationsschnittstellen:
  • <Mip>_MemMap.h: Modul-spezifisches Memory-Mapping-Header (<Mip> = Module Implementation Prefix) für Compiler-Pragmas (START_SEC_... / STOP_SEC_...).
  • Det.h: Schnittstelle zum Default Error Tracer für die Meldung von Entwicklungsfehlern (Det_ReportError).
  • Dem.h: Schnittstelle zum Diagnostic Event Manager für produktionsrelevante Diagnoseereignisse (Dem_SetEventStatus).
  • Rte_CDD_<MODULENAME>.h: Vom RTE-Generator erzeugter Header für Runnable-Prototypen, Applikations-Ports (Rte_Read, Rte_Write) und Inter-Runnable-Variables.
  • <MODULENAME>.h: Untergeordneter/proprietärer Treiber- oder Register-Header (z. B. Vendor-HAL, Microcontroller-Peripherie oder legacy hardwarenahe Treiber).
  • CDD_<MODULENAME>_Cbk.h: Callback-Header für Benachrichtigungen und Callbacks, die vom CDD implementiert und von anderen BSW-Modulen (z. B. CanIf, PduR, Spi) aufgerufen werden.
• Beziehungsstruktur & Kardinalitäten:
  • Gerichtete Abhängigkeiten (« Include », gestrichelter Pfeil vom Inkludierenden zum Inkludierten):
    • CDD_<MODULENAME>.c → CDD_<MODULENAME>.h
    • CDD_<MODULENAME>.c → <Mip>_MemMap.h (zyklisch wiederholt über Makro-Umschaltung)
    • CDD_<MODULENAME>.c → Det.h
    • CDD_<MODULENAME>.c → Dem.h
    • CDD_<MODULENAME>.c → Rte_CDD_<MODULENAME>.h
    • CDD_<MODULENAME>.c → <MODULENAME>.h
    • CDD_<MODULENAME>.h → CDD_<MODULENAME>_Cfg.h
    • CDD_<MODULENAME>.h → Std_Types.h
    • Std_Types.h → Platform_Types.h
  • CDD_<MODULENAME>_Cbk.h steht isoliert ohne eingehende Inklusion durch CDD_<MODULENAME>.h, um zyklische Abhängigkeiten bei der Einbindung durch rufende BSW-Module zu vermeiden.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um eine statische Kompilier- und Inklusionsarchitektur handelt, existiert kein Laufzeit-Sequenzdiagramm. Der funktionale Aufruf- und Initialisierungsfluss bildet sich wie folgt ab:

1. Präprozessor- & Build-Reihenfolge:
   • Bei Kompilierung von CDD_<MODULENAME>.c wird zuerst CDD_<MODULENAME>.h expandiert.
   • CDD_<MODULENAME>.h zieht zwingend CDD_<MODULENAME>_Cfg.h und Std_Types.h (inkl. Platform_Types.h) an, sodass alle Modultypen auf definierten Plattformbreiten aufsetzen.
2. Laufzeit-Interaktionen (statisch vorbereitet):
   • RTE-Interaktion: Aufrufe von Rte_Read_* / Rte_Write_* sowie Bereitstellung der Runnable-Entities laufen synchron über die in Rte_CDD_<MODULENAME>.h deklarierten APIs.
   • Fehlerpfade:
     • Synchrone Entwicklungsfehler-Meldung via Det_ReportError() über Inklusion von Det.h.
     • Asynchrone/synchrone Diagnose- und Fehlermeldungen an den Fehlerspeicher via Dem_SetEventStatus() über Dem.h.
   • Speichersektionierung: Mehrfaches Inkludieren von <Mip>_MemMap.h vor und nach Code-/Variablen-Blöcken zur Adressraumallokation im Linkerskript.

4. Normative Relevanz & Entwickler-Hinweise

• Kapselung des Modulheaders (CDD_<MODULENAME>.h):
  • CDD_<MODULENAME>.h darf weder Det.h, Dem.h noch Rte_CDD_<MODULENAME>.h inkludieren. Diese BSW-Abhängigkeiten müssen strikt in der .c-Datei verbleiben, um Leckagen interner BSW-Typen in externe Aufrufer zu verhindern.
• Callback-Entkopplung (CDD_<MODULENAME>_Cbk.h):
  • Callbacks, die von anderen BSW-Modulen gerufen werden, müssen in CDD_<MODULENAME>_Cbk.h deklariert werden. Dieser Header darf keine zyklischen Includes zum rufenden BSW-Modul aufbauen.
• Isolierung hardwarenaher Register (<MODULENAME>.h):
  • Propriäterer hardwarenaher Code bzw. Registerdeklarationen verbleiben hinter <MODULENAME>.h und dürfen ausschließlich von CDD_<MODULENAME>.c konsumiert werden; kein Durchgriff in den AUTOSAR-weiten Modulheader.
• AUTOSAR-MemMap-Konformität:
  • Jede Deklaration/Definition in .c und ggf. generierten Konfigurationsdateien muss zwingend über Präprozessor-Symbole in <Mip>_MemMap.h geklammert sein (#define CDD_<MODULENAME>_START_SEC_CODE, #include "<Mip>_MemMap.h", etc.).
• Konfigurationskonsistenz:
  • Schalter für Pre-Compile-Varianten müssen vollständig in CDD_<MODULENAME>_Cfg.h liegen; Link-Time/Post-Build-Datenstrukturen dürfen die Inklusionshierarchie von Std_Types.h nicht verletzen.