Figure 9.7: Trigger Transmit Request

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm zur Darstellung des Ablaufs einer Trigger-Transmit-Sendeanforderung in der AUTOSAR Classic Platform (Communication Stack / CAN Interface). Der Kontext umfasst die Interaktion zwischen der oberen Schicht (CanIfUser), dem CAN-Interface (CanIf), dem CAN-Treiber (Can) und dem CAN-Controller (CanController).

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Entitäten:

• CanIfUser: Obere Softwareschicht / Modulnutzer des CAN Interfaces.
• «module» CanIf: AUTOSAR CAN-Interface-Modul.
• «module» Can: AUTOSAR CAN-Treiber-Modul (gekennzeichnet mit Interface-Symbol).
• «peripheral» CanController: CAN-Hardware-Controller.

Aufgerufene Schnittstellen und Signaturen:

• CanIf_Transmit(Std_ReturnType, PduIdType, const PduInfoType*): Aufruf durch CanIfUser an CanIf.
• Can_Write(Std_ReturnType, Can_HwHandleType, const Can_PduType*): Aufruf durch CanIf an Can.
• CanIf_TriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*): Rückruf durch Can an CanIf mit Kommentar „Pass pointer to HW object“.
• <CainIfUser>_CanIfTriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*): Weiterleitung des Trigger-Transmit-Aufrufs von CanIf an CanIfUser.
• Copy L-Pdu into CAN hardware: Datenübertragung von CanIfUser in den CanController.
• Copy L-PDU into CAN hardware: Quittierung/Rückkehr der Datenübertragung.
• Rückgabewerte / Returns: CanIf_TriggerTransmit(), Can_Write(), CanIf_Transmit().

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf startet mit dem synchronen Aufruf CanIf_Transmit(...) durch CanIfUser an CanIf. CanIf leitet die Sendeanforderung über Can_Write(...) an das Treiber-Modul Can weiter. Innerhalb eines alt-Blocks („alt Controller HW Status“) wird nach dem Zustand des Hardware-Objekts unterschieden:

• Fall [Controller HW object free]: Das Treiber-Modul Can ruft CanIf_TriggerTransmit(...) auf und übergibt einen Zeiger auf das Hardware-Objekt. CanIf ruft daraufhin <CainIfUser>_CanIfTriggerTransmit(...) auf. Der CanIfUser kopiert die Nutzdaten direkt in den Controller (Copy L-Pdu into CAN hardware), woraufhin die Rückkehr erfolgt. Anschließend kehren CanIf_TriggerTransmit(), Can_Write() und schließlich CanIf_Transmit() nacheinander synchron zu ihren jeweiligen Aufrufern zurück.
• Fall [Controller HW object busy]: Can meldet den Besetztzustand via Rückkehr von Can_Write() an CanIf. CanIf reiht die Sendeanforderung intern in eine Warteschlange ein (Self-Message / Notiz „Queue transmit request“) und kehrt mit CanIf_Transmit() zum CanIfUser zurück.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm spezifiziert normativ das synchrone Entkopplungs- und Abrufverhalten bei Trigger-Transmit-fähigen PDUs im CAN-Stack. Besondere Relevanz für Treiber- und Stack-Implementierer:

• Bei freiem Hardware-Objekt fordert der CAN-Treiber die PDU-Daten synchron via TriggerTransmit-Rückruf an, sodass der Anwender die Daten direkt in den CAN-Hardware-Puffer kopiert.
• Bei belegtem Hardware-Objekt (busy) puffert CanIf die Anforderung (sofern Transmit Buffering konfiguriert ist), ohne zu diesem Zeitpunkt einen TriggerTransmit-Aufruf an die obere Schicht auszulösen.
• Die Schnittstelle Can_Write verwendet normativ Std_ReturnType als Rückgabetyp.