Figure 10.4: FlexRay Transceiver Dio Access configuration structure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR ECUC-Metamodell-Diagramm (UML-Klassendiagramm auf M2/Konfigurationsebene).
• Architektur-Kontext: AUTOSAR Classic Platform, BSW-Schicht Microcontroller Abstraction Layer / Device Drivers bzw. Communication Stack, Modul FrTrcv (FlexRay Transceiver Driver; Spezifikationsdokument: AUTOSAR_CP_SWS_FlexRayTransceiverDriver, Release R24-11).
• Funktionaler Zweck: Festlegung der Hardware-Zugriffsart (FrTrcvAccess) zur Steuerung und Statusabfrage des FlexRay-Transceiver-ICs. Das Modell entkoppelt die Transceiver-Statemaschine formal von der physikalischen Schnittstelle des Steuergeräts: Entweder direkte Pin-basierte Ansteuerung über das Modul Dio oder busbasierte Registersteuerung über das Modul Spi.

2. Komponenten, Entitäten & Schnittstellen

ECUC-Container & Parameter-Definitionen

• FrTrcvAccess: EcucChoiceContainerDef (Multiplizität: 1..1):
  • Root-Choice-Container zur exklusiven Selektion der Schnittstellenart pro Transceiver bzw. Kanal. Erzwingt genau eine der beiden Alternativen (+choice).
• FrTrcvDioAccess: EcucParamConfContainerDef (Multiplizität: 0..1, Rolle: +choice):
  • Konfigurationszweig für diskrete Pin-Steuerung via GPIO/DIO.
  • Aggregiert über +subContainer den Sub-Container:
    • FrTrcvDioChannelAccess: EcucParamConfContainerDef (Multiplizität: 1..*):
      • Modelliert jeden einzelnen Transceiver-Hardware-Pin (z. B. STBN, EN, ERRN, WAKE). Mindestens ein Pin muss konfiguriert sein.
      • Parameter FrTrcvHardwareInterfaceName: EcucStringParamDef (+parameter): Bezeichnet den Hardwaresignal-Namen am Transceiver-IC.
      • Referenz FrTrcvDioSymNameRef: EcucChoiceReferenceDef (+reference): Referenziert symbolisch den korrespondierenden Kanal (DioChannel oder DioChannelGroup) aus der Konfiguration des AUTOSAR-Dio-Treibers.
• FrTrcvSpiSequence: EcucParamConfContainerDef (Multiplizität: 0..1, Rolle: +choice):
  • Konfigurationszweig für serielle Transceiver-Ansteuerung via SPI-Bus.
  • Aggregiert über +reference die Referenz:
    • FrTrcvSpiSequenceName: EcucReferenceDef (Multiplizität: 1):
      • Spezifiziert mit requiresSymbolicNameValue = true die Referenz auf eine konkrete SpiSequence innerhalb des Spi-Treibers.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert eine statische Konfigurationsstruktur; aus der Wahl der Zugriffsart resultieren jedoch grundlegend unterschiedliche dynamische Treiberpfade zur Laufzeit:

• Pfad FrTrcvDioAccess (Synchron & latenzarm):
  • Treiberaufrufe zur Betriebsartenumschaltung (z. B. FrTrcv_SetTransceiverMode) oder Statusprüfung führen zu direkten, synchronen Aufrufen der BSW-APIs Dio_WriteChannel() bzw. Dio_ReadChannel().
  • Kein asynchroner Kommunikations-Overhead; Zustandswechsel erfolgen innerhalb des Funktionskontexts unmittelbar.
• Pfad FrTrcvSpiSequence (Asynchron/Sequenziell):
  • Treiberanforderungen stoßen eine SPI-Transaktion an (Aufruf von Spi_AsyncTransmit() mit der durch FrTrcvSpiSequenceName gebundenen Sequenz-ID).
  • Die Rückmeldung des Transceiver-Zustands erfolgt asynchron über den konfigurierten SPI-Sequenz-Ende-Callback (SpiSequenceEndNotification) oder synchron via Polling des SPI-Status (Spi_GetSequenceResult).

4. Normative Relevanz & Entwickler-Hinweise

• Exklusivität (ChoiceContainer): Eine Mischung von DIO- und SPI-Steuerung innerhalb desselben FrTrcvAccess-Containers ist metamodellseitig ausgeschlossen. Transceiver, die beispielsweise Modus-Steuerung per SPI und Interrupt/Wakeup-Signalisierung über DIO abwickeln, müssen gemäß SWS-Architektur über die spezifischen Wakeup-/Notification-Strukturen des Moduls gebunden werden.
• Strikte Pre-Compile-Bindung: Gemäß [ECUC_FrTrcv_00151] ist FrTrcvSpiSequenceName ausschließlich zur Pre-Compile-Zeit konfigurierbar. Post-Build-Varianten (z. B. PB-S oder PB-L) können die SPI-Sequenzzuordnung nicht zur Laufzeit austauschen. Generatoren dürfen die Sequenz-IDs als statische Konstanten oder Makros in den C-Code einbetten.
• Symbolic Name Value Contract: Durch requiresSymbolicNameValue = true muss der Konfigurations- und Codegenerator sicherstellen, dass das referenzierte SPI-Objekt über das standardisierte Präfix/Makro des Moduls Spi (z. B. SpiConf_SpiSequence_<Name>) aufgelöst wird.
• DIO-Kanal-Mapping (FrTrcvDioChannelAccess): Da die Multiplizität 1..* beträgt, muss der Integrator für jeden vom Transceiver-Hardwaretyp geforderten Steuerpin ein eigenes FrTrcvDioChannelAccess-Element anlegen und FrTrcvHardwareInterfaceName exakt nach Datenblatt/BSW-Treibervorgabe benennen, damit der Codegenerator die Zuordnung zwischen Treiber-Zustandslogik und den Dio_ChannelType-Handles generieren kann.