Figure 9.8: Com to LinIf I-PDU transmission (LIN sporadic non-frame)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Communication Stack (ComStack).
• Funktionale Einordnung: Darstellung des Pull-basierten Datenübertragungsmodells (TriggerTransmit) für LIN-I-PDUs (ausgenommen LIN Sporadic Frames). Das Diagramm spezifiziert die Weiterleitung der Abfrage von der unteren Schnittstellenschicht (LinIf) über den PDU Router (PduR) an die obere Schicht (Com) sowie die anschließende Übertragungsbestätigung (TxConfirmation).

2. Komponenten, Entitäten & Schnittstellen

• Module / Lifelines:
  • «module» LinIf (LIN Interface): Schnittstelle zum LIN-Treiber/Bus; kontrolliert zeitgesteuerte Abläufe anhand der LIN Schedule Table.
  • «module» PduR (PDU Router): Vermittlungsschicht für I-PDUs zwischen transportunabhängigen oberen Schichten und bus-spezifischen unteren Schnittstellen.
  • «module» Com (AUTOSAR COM): Signal- und I-PDU-Verwaltung der oberen Schicht; hält die aktuellen Sendedaten im internen Puffer.
• Schnittstellen & Service-APIs:
  • PduR_<User:Lo>TriggerTransmit(PduIdType, PduInfoType*): Untere Interface-Abfrage (hier konkret: PduR_LinIfTriggerTransmit), ausgelöst durch den LIN-Scheduler zur Abholung der I-PDU-Nutzdaten.
  • Com_TriggerTransmit(PduIdType, PduInfoType*): Obere Interface-Abfrage an das Modul Com zum synchronen Befüllen des übergebenen Puffers (PduInfoPtr->SduDataPtr) und Setzen der Länge (SduLength).
  • PduR_<User:Lo>TxConfirmation(PduIdType, Std_ReturnType): Asynchrone Sendebestätigung von LinIf an PduR nach erfolgreichem Frame-Transfer auf dem Bus.
  • Com_TxConfirmation(PduIdType, Std_ReturnType): Weiterleitung der Bestätigung an Com zur Quittierung und ggf. Signal-Ablaufüberwachung (Tx-Deadline-Monitoring).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggerung via Schedule Table (LinIf):
   • Zu einem im LIN-Schedule definierten Zeitschlitz initiiert LinIf synchron den Datenaustausch via PduR_<User:Lo>TriggerTransmit.
2. Weiterleitung & Pufferkopie (PduR -> Com):
   • PduR routet den Aufruf direkt und synchron via Com_TriggerTransmit an das Modul Com.
   • PduR führt keine Pufferung durch ("No buffering is made in PduR").
   • Com kopiert die aktuellen Nutzdaten atomar in den bereitgestellten Puffer (copy buffer()) und signalisiert Erfolg (E_OK) bzw. Fehler (E_NOT_OK).
3. Rückkehrpfad:
   • Rücksprung der synchronen Callbacks über PduR zurück an LinIf. LinIf übergibt die Daten an den LIN-Treiber (Lin) für den Frame-Header/Response-Zyklus auf dem Bus.
4. TxConfirmation (Asynchron):
   • Nach erfolgreichem Senden des LIN-Frames auf dem Bus ruft LinIf PduR_<User:Lo>TxConfirmation auf.
   • PduR delegiert den Aufruf synchron via Com_TxConfirmation an Com.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsaspekte (PduR & Com):
  • Für diese Routing-Pfade ist im PduR der PDU-Typ auf TriggerTransmit zu konfigurieren (PduRQueueDepth = 0; kein FIFO/Puffer-Support im PduR für diesen Pfad).
  • Im Com muss für die betroffene I-PDU ComIPduSignalProcessing beachtet werden (TriggerTransmit operiert typischerweise im Kontext der LinIf/Scheduler-Task oder ISR).
• Echtzeit- und Reentrancy-Anforderungen:
  • Com_TriggerTransmit wird im Interrupt- oder Scheduler-Task-Kontext des LIN-Stacks aufgerufen. Der Signalpuffer-Kopiervorgang (copy buffer()) muss extrem kurz und konsistent sein (Interrupt-Sperre / Locks gegen parallele Com_SendSignal-Updates).
• Abgrenzung zu LIN Sporadic Frames:
  • Bei LIN Sporadic Frames wird die Übertragung aktiv über PduR_ComTransmit bzw. LinIf_Transmit angefordert (Push-Prinzip), sobald Datenänderungen vorliegen.
  • Das hier gezeigte Pull-Muster gilt strikt für reguläre Frames (Unconditional Frames etc.), bei denen der Master-Schedule den Zeitpunkt der Abfrage autonom diktiert.