DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_CANInterface FIG-66e950abef78e4be 820 × 675 px 5 Release(s)

Figure 9.6: Trigger Transmit Request

SHA-256 Inhalts-Fingerabdruck: 66e950abef78e4be0440ff9cfe268ba35d10a4b01c3fed6ca4def833895e6a55

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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“.
  • <CanIfUser>_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 <CanIfUser>_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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R19-11 → R20-11 keine inhaltliche Änderung Vorgänger: FIG-79cef3b3d5f129d1

Keine inhaltlichen Änderungen erkennbar.

R23-11 → R24-11 normative Änderung Nachfolger: FIG-36f8799bd539ada7
  • Umbenennung und Spezialisierung der übergeordneten Komponente von CanIfUser (ohne Stereotyp) zu «module» LSduR.
  • Schnittstellenanpassung beim TriggerTransmit-Callback: Der generische Aufruf <CanIfUser>_CanIfTriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*) wurde durch den modulspezifischen Aufruf LSduR_CanIfTriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*) ersetzt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«peripheral» | CanController | CanIfUser «module» | CanIf | «module» | Can | alt Controller HW Status | [Controller HW object free] | [Controller HW object busy] |        |  |  |  |           | Can_Write(Std_ReturnType, Can_HwHandleType, const Can_PduType*) | CanIf_TriggerTransmit() | <CanIfUser>_CanIfTriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*) | CanIf_Transmit(Std_ReturnType, PduIdType, const PduInfoType*) | Copy L-Pdu into CAN hardware | Copy L-PDU into CAN hardware | Can_Write() | CanIf_TriggerTransmit(Std_ReturnType, PduIdType, PduInfoType*) | CanIf_Transmit() | Can_Write()

Vorkommen in AUTOSAR-Releases (5)

Release Dokument Seite Nr. Bildunterschrift im Dokument
EXTERN AUTOSAR_SWS_CANInterface S. 144 9.6 Figure 9.6: Trigger Transmit Request
R20-11 AUTOSAR_SWS_CANInterface S. 135 9.6 Figure 9.6: Trigger Transmit Request
R21-11 AUTOSAR_SWS_CANInterface S. 137 9.6 Figure 9.6: Trigger Transmit Request
R22-11 AUTOSAR_SWS_CANInterface S. 144 9.6 Figure 9.6: Trigger Transmit Request
R23-11 AUTOSAR_CP_SWS_CANInterface S. 144 9.6 Figure 9.6: Trigger Transmit Request