Figure 4.64: CAN Transceiver Driver General Parameters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Metamodell-Ausschnitt der AUTOSAR BSW-ECU-Konfigurationsparameter (ParamConfContainerDef).
• Architektur-Kontext: Definition der statischen, modulweiten Vorkompilierungs- und Generierungsparameter für den CAN Transceiver Driver (CanTrcv) innerhalb des Communication Hardware Abstraction / MCAL-Layers (Classic Platform).
• Funktionaler Zweck: Festlegung der globalen Compile-Time-Switches (Code-Generierung) für Fehlerprüfung (DET), API-Umfang (GetVersionInfo) und Wake-Up-Strategie über alle vom Treiber verwalteten Transceiver-Kanäle hinweg.

2. Komponenten, Entitäten & Schnittstellen

• Container:
  • CanTrcvGeneral (: ParamConfContainerDef): Zentraler Konfigurationscontainer mit der Kardinalität 1..1 (lowerMultiplicity = 1, upperMultiplicity = 1), d. h. genau einmal pro BSW-Modulinstanz obligatorisch vorhanden.
• Parameter (Kompositionsbeziehung +parameter):
  • CanTrcvDevErrorDetect (: BooleanParamDef): Schaltet die Erkennung und Meldung von Entwicklungsfehlern (Development Error Tracer, DET) an bzw. ab.
  • CanTrcvGetVersionInfo (: BooleanParamDef): Steuert die Verfügbarkeit der Version-Info-API. Vordefinierter Standardwert: defaultValue = false.
  • CanTrcvWakeUpSupport (: EnumerationParamDef): Konfiguriert die hardware-/treiberseitige Wake-Up-Erkennungsstrategie.
• Enumeration-Literale (Kompositionsbeziehung +literal zu CanTrcvWakeUpSupport):
  • CanTrcvWakeUpByIsr: Wake-Up-Erkennung interrupt-getrieben (ICU / externe Interruptleitung angebunden).
  • CanTrcvWakeUpByPolling: Zyklisches Polling des Transceiver-Zustands über periodische Main-Functions (CanTrcv_MainFunction()).
  • CanTrcvWakeUpNotSupported: Kein Wake-Up-Support hardware- oder treiberseitig realisiert.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Da es sich um ein statisches Konfigurationsmetamodell handelt, existiert kein direkter Laufzeit-Kontrollfluss; das Metamodell induziert jedoch folgendes bedingtes BSW-Verhalten:

• DET-Pfad (CanTrcvDevErrorDetect == true):
  • Sämtliche öffentlichen Treiberschnittstellen (z. B. CanTrcv_SetOpMode, CanTrcv_GetOpMode) prüfen Parameter und Modulinitialisierungsstatus synchron vor Ausführung und melden Fehler via Det_ReportError().
• Wake-Up-Pfad (CanTrcvWakeUpSupport):
  • CanTrcvWakeUpByIsr: Ein Flankenwechsel am Wake-Up-Pin triggert eine ISR (z. B. via ICU-Modul), welche die Auswertung veranlasst und EcuM_SetWakeupEvent() meldet.
  • CanTrcvWakeUpByPolling: Die BSW-Main-Function fragt zyklisch Transceiver-Statusflags/Pins ab; bei detektiertem Wake-Up erfolgt ebenfalls der Callback an den EcuM.
  • CanTrcvWakeUpNotSupported: Code-Pfade für Wake-Up-Handling und Callbacks werden vollständig weggestrippt.

4. Normative Relevanz & Entwickler-Hinweise

• Präprozessor-Makros & Code-Größe (Footprint):
  • CanTrcvDevErrorDetect mappt auf das Präprozessor-Symbol CANTRCV_DEV_ERROR_DETECT. In Release-/Serien-Builds zur Laufzeitoptimierung auf STD_OFF zu konfigurieren; im Integrations-/Debug-Build auf STD_ON.
  • CanTrcvGetVersionInfo mappt auf CANTRCV_GET_VERSION_INFO. Bei false (STD_OFF) wird die Funktion CanTrcv_GetVersionInfo() nicht generiert bzw. als leeres Makro definiert, was Flash-Speicher spart.
• OS- & Schedule-Planung:
  • Bei Wahl von CanTrcvWakeUpByPolling ist zwingend eine periodische Task im OS für CanTrcv_MainFunction() bzw. CanTrcv_MainFunctionDiagnostics() einzuplanen.
  • Bei CanTrcvWakeUpByIsr muss die entsprechende Interrupt-Quelle im MCU/ICU-Treiber und OS konfiguriert und auf die Callback-Routinen des Transceiver-Treibers gemappt werden.
• ECU-Zustandsmanagement: Die Wake-Up-Konfiguration muss zwingend mit den konfigurierten EcuMWakeupSource-Elementen im EcuM (ECU State Manager) konsistent gehalten werden.