Figure 7.5: Transmit data flow

1. Diagrammtyp & Architektur-Kontext

UML-Aktivitätsdiagramm zur Darstellung des Sendedatenflusses (Transmit Data Flow) innerhalb des AUTOSAR Classic Platform Communication Stacks. Das Diagramm modelliert den Kontroll- und Datenfluss beim Sendeaufruf von überlagerten Kommunikationsschichten über das CAN Interface (CanIf) und den CAN Driver (Can) bis hin zum CAN Controller (Hardware).

2. Komponenten, Entitäten & Schnittstellen

• Upper Layers: Übergeordnete Software-Schichten (z. B. PduR, CanNm, CanTp), die den Sendeauftrag initiieren.
• CAN Interface (CanIf): Abstraktionsschicht und Koordinator des Sendevorgangs; stellt die Schnittstelle CanIf_Transmit() bereit und verwaltet softwareseitige Sendepuffer («datastore» transmit buffer).
• CAN Driver (Can): Hardwarenaher Treiber zur Ansteuerung des Controllers; stellt die Treiberschnittstelle Can_Write() bereit.
• CAN Controller: Hardware-Einheit mit hardwareseitigen Sende-Mailboxen/Registern («datastore» CAN hardware).
• Schnittstellen & Operationen:
  • CanIf_Transmit(): Eintrittsfunktionsaufruf der oberen Schichten in das CAN Interface.
  • Can_Write(): Aufruf des Treibers durch das CAN Interface zur direkten Übergabe an die Hardware.
  • «datastore» Copy data into CAN hardware: Datentransfer in die Hardware-Puffer des CAN Controllers.
  • Set transmit request in CAN controller: Setzen des Sendeanforderungsbits im CAN-Controller-Register.
  • «datastore» Copy data into transmit buffer: Pufferung der Sendedaten im internen Sendepuffer des CAN Interface bei belegter Hardware.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Eine überlagerte Schicht initiiert den Sendevorgang durch Aufruf von CanIf_Transmit() (Startknoten).
2. Treiberaufruf: Es erfolgt der Aufruf von Can_Write().
3. Verzweigung (CAN Hardware is free?):
   • Pfad [Yes] (Hardware frei):
     • Die Sendedaten werden direkt in die CAN-Hardware kopiert («datastore» Copy data into CAN hardware).
     • Anschließend wird die Sendeanforderung im CAN Controller aktiviert (Set transmit request in CAN controller).
   • Pfad [No] (Hardware belegt):
     • Sofern der interne Puffer verfügbar ist (Bedingung/Kommentar Buffer is free), werden die Nutzdaten im Software-Sendepuffer des CAN Interface abgelegt («datastore» Copy data into transmit buffer).
4. Zusammenführung und Abschluss: Beide Ausführungspfade werden über einen Synchronisationsbalken (Join Node) zusammengeführt und münden in den Endzustand (Activity Final Node).

4. Normative Relevanz & Entwickler-Hinweise

• Pufferungskonzept (Transmit Buffering): Zeigt das optionale Software-Buffering des CAN Interface: Ist kein Hardware-Sendeobjekt (HTH) unmittelbar frei ([No]), fängt das CAN Interface die PDU in einem Softwarepuffer ab, vorausgesetzt ein entsprechender Puffer ist konfiguriert und frei (Buffer is free).
• Rückgabewerte & Fehlerbehandlung: Wenn die Hardware belegt ist und kein Pufferplatz verfügbar ist, scheitert der Sendevorgang bzw. liefert E_NOT_OK (im Diagramm auf den Regelfall Buffer is free fokussiert).
• Synchroner Treiberpfad: Der Pfad über Can_Write() mit freier Hardware führt unmittelbar zum Triggern des Sende-Bits im Hardware-Controller durch den Treiberkontext.
• Hardware-Entkopplung: Verdeutlicht die funktionale Trennung zwischen PDU-Zwischenspeicherung auf BSW-Ebene (CanIf) und Hardware-Mailbox-Zuweisung auf MCAL/Hardware-Ebene.