Figure 12: Initialization of the ADC Driver

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des standardisierten Bootstrapping- bzw. Initialisierungsablaufs des ADC-Treibers (Adc) durch den ECU State Manager (EcuM).
• Architektur-Einordnung:
  • Ebene: Übergang von System Services (BSW / EcuM) zur hardwarenahen Treiber-Ebene (MCAL / Microcontroller Abstraction Layer).
  • AUTOSAR-Kontext: Ablauf findet in der frühen Startphase der BSW statt (typischerweise innerhalb von EcuM_AL_DriverInitListZero bzw. EcuM_AL_DriverInitListOne vor dem Start des OS und des Schicht-2/3-Betriebs).

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Entitäten (Lifelines):
  • «module» EcuM: Caller; System-Service-Modul zur Steuerung der ECU-Zustände (Startup, Shutdown, Sleep, Wakeup).
  • «module» Adc: Callee; MCAL-Treiber zur Kapselung der Analog-Digital-Wandler-Peripherie des Mikrocontrollers.
• Schnittstellen & Signaturen:
  • Synchroner C-Funktionsaufruf: void Adc_Init(const Adc_ConfigType* ConfigPtr).
  • Übergabeparameter: Pointer auf eine konstante, typisierte Konfigurationsstruktur (Adc_ConfigType), welche die Hardware-spezifischen Einstellungen enthält (Kanalzuweisungen, Gruppenkonfigurationen, Abtastzeiten, Clock-Prescaler, Trigger-Quellen).
• Kardinalität & Beziehung:
  • 1:1-Beziehung während der Initialisierungssequenz.
  • Statischer Funktionsaufruf ohne dynamische Port- oder RTE-Kommunikation (direktes C-API-Interface innerhalb der BSW).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: EcuM erreicht die Phase zur Initialisierung der MCAL-Treiber (EcuM_Init).
2. Aufruf (Synchroner Call):
   • EcuM ruft synchron Adc_Init(ConfigPtr) auf.
   • ConfigPtr übergibt die Adresse der Post-Build- bzw. Link-Time-Konfigurationsdatenstruktur (z. B. generiert aus Adc_PBCfg.c).
3. Treiber-interne Ausführung (Adc):
   • Prüfung der Vorbedingungen: Bei aktivem Default Error Tracer (DET) Validierung von ConfigPtr != NULL (sofern Post-Build verwendet) sowie Sicherstellung, dass der Treiber sich noch im Zustand ADC_UNINIT befindet.
   • Hardware-Konfiguration: Setup von Prescaler-Registern, Takteinstellungen, ADC-Wandlungsgruppen, Auflösung und Referenzspannungen.
   • Reset aller Gruppenstatusanzeigen auf ADC_IDLE.
   • Puffer- und Streaming-Zeiger werden initialisiert; Gruppen-Notifications/Interrupts bleiben initial deaktiviert.
   • Zustandsübergang des Treibers von ADC_UNINIT nach ADC_INIT.
4. Rückkehr (Return Message):
   • Synchroner Rücksprung (Adc_Init()) an den EcuM. Nach Rückkehr ist der ADC-Treiber betriebsbereit für SWC-/BSW-Trigger (Adc_StartGroupConversion, Adc_EnableHardwareTrigger).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (Adc_Init):
  • Reentrancy: Nicht reentrant. Darf nur einmalig während des BSW-Startup aufgerufen werden.
  • Aufrufkontext: Task-Ebene im privilegierten Modus (Supervisor Mode) vor Freigabe von Interrupts bzw. vor Start des Echtzeitbetriebssystems (OS).
• DET-Fehlercodes (SWS-Anforderungen):
  • ADC_E_ALREADY_INITIALIZED: Wird geworfen, wenn Adc_Init() in einem anderen Zustand als ADC_UNINIT aufgerufen wird (keine Re-Initialisierung ohne vorheriges Adc_DeInit).
  • ADC_E_PARAM_CONFIG: Wird geworfen, wenn die Konfigurationsstruktur ungültig ist oder bei Post-Build-Varianten ein Nullzeiger übergeben wird.
• Konfigurationsvarianten:
  • VARIANT-POST-BUILD: ConfigPtr muss auf eine gültige Struktur der Konfigurationsmenge zeigen.
  • VARIANT-PRE-COMPILE: ConfigPtr kann implementationsabhängig NULL_PTR sein, sofern alle Parameter zur Compile-Zeit fixiert sind.
• Einschränkung:
  • Keine ADC-API-Funktion (außer Adc_GetVersionInfo) darf vor dem erfolgreichen Abschluss von Adc_Init() ausgeführt werden; Zuwiderhandlung führt zu ADC_E_UNINIT.