Figure 9.1: Sequence diagram - ADC conversion

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des end-to-end Signalflusses einer asynchronen Analog-Digital-Wandlung (ADC) im AUTOSAR Classic Platform Schichtenmodell.
• Architektur-Einordnung: Zeigt das Zusammenspiel zwischen Application Layer (Sensor / Actuator Component), ECU Abstraction Layer (IoHwAb), Microcontroller Abstraction Layer (Adc), System Services (EcuM) und der Mikrocontroller-Peripherie (ADC Conversion Unit). Die IoHwAb kapselt dabei MCAL-Kanalgruppen, wandelt Rohwerte in physikalische/elektrische Größen (mV/V) und entkoppelt den ISR-Kontext von der Applikation via RTE-Events.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Lebenslinien

• «SensorActuatorHW» Sensor / Actuator Component: AUTOSAR Software-Component (SWC) im Application Layer; konsumiert Sensordaten.
• «module» EcuM: ECU State Manager (System Services); steuert die BSW-Startsequenz (Init-Phasen).
• «module» IoHwAb: I/O Hardware Abstraction; vermittelt zwischen applikativen Signalbezeichnern (af_pressure) und MCAL-Kanalgruppen.
• «module» Adc: MCAL-Treiber zur Konfiguration und Ansteuerung der Analog-Digital-Wandlerperipherie.
• «Peripheral» ADC Conversion Unit: Hardware-Modul auf dem Mikrocontroller (Wandlerkern, Sample & Hold, SAR/Delta-Sigma).

Datenstrukturen & Parameter (gemäß Notizbox & Signaturen)

• Gruppe & Kanäle: Group 1 umfasst Channel 1 und Channel 2; Gruppenbenachrichtigung (Notification mechanism) ist aktiv.
• Signale & Typen:
  • af_pressure: Logischer Signalbezeichner für den Drucksensor.
  • Adc_ConfigType, IoHwAb<Init_Id>_ConfigType: Post-Build- bzw. Pre-Compile-Konfigurationsstrukturen.
  • Adc_GroupType, Adc_ChannelType, Adc_ValueType: AUTOSAR MCAL-Standard-Datentypen für Gruppen-ID, Kanal-ID und Rohwert.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Initialisierung (Bootstrapping)

1. EcuM initialisiert den MCAL-Treiber synchron via Adc_Init(const Adc_ConfigType*).
2. EcuM initialisiert die Abstraktionsschicht partitions-/phasenabhängig via IoHwAb_Init<Init_Id>(const IoHwAb<Init_Id>_ConfigType*).
3. IoHwAb aktiviert die Interrupt-Callback-Delegation des Treibers für die Zielgruppe: Adc_EnableGroupNotification(Adc_GroupType).

Phase 2: Asynchroner Wandlungstrigger

1. Die SWC stößt die Erfassung an: IoHwAb_GetVoltage(af_pressure).
2. IoHwAb mappt das Signal af_pressure auf die entsprechende ADC-Gruppe und triggert die Konvertierung: Adc_StartGroupConversion(Adc_GroupType).
3. Adc weist die Hardware an: start conversion().
4. Der Aufruf kehrt unverzüglich nicht-blockierend über IoHwAb_GetVoltage() an die SWC zurück.

Phase 3: Hardware-Konvertierung, ISR & Callback

1. Nach Abschluss der Wandlung feuert die Peripherie einen Hardware-Interrupt: Interrupt().
2. Die ISR im Adc-MCAL ruft die konfigurierte Benachrichtigungsfunktion auf: IoHwAb_Adc_Notification_Group1().
3. Im Callback-Kontext liest IoHwAb das Wandlungsergebnis des Kanals: Adc_OnDemandReadChannel(Adc_ChannelType): Adc_ValueType.
4. IoHwAb signalisiert die Datenverfügbarkeit an die RTE / SWC: SetRTEEvent().

Phase 4: Synchrones Auslesen des Pufferwerts

1. Die durch das RTE-Event aktivierte SWC ruft IoHwAb_ReadVoltage(af_pressure, &buffer) auf.
2. IoHwAb skaliert den gepufferten Rohwert ggf. in eine physikalische Spannung und liefert ihn synchron in den übergebenen Speicherbereich (buffer) zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Kontextwechsel & ISR-Restriktionen: IoHwAb_Adc_Notification_Group1() wird im ISR-Kontext (CAT2) ausgeführt. Zeitaufwändige Berechnungen, blockierende Operationen oder komplexe Filteralgorithmen sind im Callback zwingend zu vermeiden. Die Entkopplung in den Task-Kontext erfolgt standardkonform über SetRTEEvent() (Rte_SetEvent_<Event>()).
• Zweistufiger Signalzugriff (Trigger-Read-Pattern): Das Diagramm implementiert ein klassisches Split-Phase-Muster: Initiierung via IoHwAb_GetVoltage() und spätere Abholung via IoHwAb_ReadVoltage(). Treiberentwickler müssen sicherstellen, dass Pufferdaten gegen Race Conditions geschützt sind (z. B. atomare Pufferaktualisierung oder exklusiver Bereich via Schattenspeicher / Ringpuffer).
• API-Spezifika:
  • IoHwAb_Init<Init_Id>: Erlaubt multiple Init-Blöcke (z. B. für frühe I/O-Initialisierung vor OS-Start vs. vollständige Initialisierung nach OS-Start).
  • Adc_OnDemandReadChannel: Zeigt das selektive Auslesen einzelner Kanäle innerhalb einer Gruppe, alternativ zum klassischen Blocktransfer via Adc_ReadGroup().
• BSW-Konfiguration: Die Zuordnung von Signalnamen (af_pressure) zu Hardware-Ressourcen (AdcGroup, AdcChannel) wird statisch im Ecuc-Modell der IoHwAb konfiguriert und zur Generierungszeit validiert.