Figure 9.5: Com to CanIf I-PDU transmission

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Classic Platform, Communication Stack (Com-Stack).
• Funktionale Einordnung: Modellierung des standardmäßigen, ungepufferten 1:1 I-PDU-Sendepfads (Direct Transmission / Non-buffered I-PDU Routing) von der oberen Schicht (Com) über den Vermittlungsknoten (PduR) an die CAN-Treiberschnittstelle (CanIf).
• Zweck: Trennung der Übertragung in einen synchronen Sendeanforderungs-Pfad (Request Phase) und einen entkoppelten, asynchronen Bestätigungspfad (Tx-Confirmation Phase) nach erfolgreichem Bustransfer.

2. Komponenten, Entitäten & Schnittstellen

• Module & Akteure («module»):
  • Com (AUTOSAR COM): Signal-Gateway, Signal-Packing, Steuerung von I-PDU-Übertragungsmodi (zyklisch, ereignisgesteuert) und Tx-Deadline-Monitoring. Gekennzeichnet mit Dekompositionssymbol (Sub-Prozesse).
  • PduR (PDU Router): Protokollunabhängiger Routing-Router; statisches Tabellen-Lookup zur PDU-ID-Translation ohne eigene Zwischenpufferung.
  • CanIf (CAN Interface): Hardware-Abstraktionsschicht; Zuordnung von I-PDUs zu Hardware-Transmit-Objekten (HTHs) und Frame-Konstruktion.
• Schnittstellen & Signaturen:
  • PduR_ComTransmit(Std_ReturnType, PduIdType, const PduInfoType*): Modulspezifische Instanziierung des oberen Sende-Entry-Points (<Up>_Transmit).
  • CanIf_Transmit(Std_ReturnType, PduIdType, const PduInfoType*): Unterer Sende-Aufruf (<Lo>_Transmit).
  • PduR_<User:lo>TxConfirmation(PduIdType, Std_ReturnType): Generischer Lower-Layer-Callback (hier konkret: PduR_CanIfTxConfirmation), signalisiert erfolgreiche Busübertragung.
  • Com_TxConfirmation(PduIdType, Std_ReturnType): Weiterleitung der Bestätigung an das Ursprungsmodul.
• Relevante Datenstrukturen:
  • PduInfoType: Containerstruktur mit SduDataPtr (Zeiger auf Payload) und SduLength (Länge in Bytes).
  • PduIdType: Konfigurierter Bezeichner zur Adressierung der jeweiligen PDU-Instanz.
  • Std_ReturnType: Statuscode (E_OK, E_NOT_OK).

3. Dynamisches Verhalten & Sequenzablauf

1. Sende-Trigger (Synchron): Com initiiert die Übertragung durch Aufruf von PduR_ComTransmit(ComTxPduId, &PduInfo).
2. Routing & Dispatching (Synchron): PduR identifiziert anhand seiner statischen Routing-Tabelle (PduRRoutingTable) die korrespondierende Ziel-PDU (CanIfTxPduId) und ruft direkt CanIf_Transmit(CanIfTxPduId, &PduInfo) auf. Es findet keine Pufferung im PduR statt ("PduR will not buffer IPDU").
3. Hardware-Pufferung (copy data()): CanIf kopiert die SDU-Payload synchron via copy data() in die Hardware-Mailbox des CAN-Controllers (oder den Software-Puffer des CAN-Treibers).
4. Synchrone Rückkehr: CanIf_Transmit liefert E_OK an PduR zurück, was unverzüglich als Return-Wert an Com durchgereicht wird. Der synchrone Sendevorgang ist damit abgeschlossen.
5. Asynchrone Tx-Confirmation: Nach erfolgreicher Arbitrierung und fehlerfreiem ACK auf dem CAN-Bus löst der CAN-Controller einen TX-Interrupt aus (oder Polling via Can_MainFunction_Write). CanIf setzt daraufhin den Callback PduR_<User:lo>TxConfirmation(CanIfTxPduId, E_OK) ab.
6. Confirmation-Routing: PduR mappt die CanIfTxPduId zurück auf die ursprüngliche ComTxPduId und delegiert via Com_TxConfirmation(ComTxPduId, E_OK).
7. Abschluss: Com setzt Überwachungs-Timer zurück (z. B. Tx-Confirmation-Timeout) und quittiert den Callback synchron an PduR und CanIf.

4. Normative Relevanz & Entwickler-Hinweise

• Speicher- und Zeiger-Gültigkeit (Zero-Buffer Constraint): Da PduR die Daten nicht puffert, muss der Speicherbereich hinter PduInfoType.SduDataPtr exklusiv im Besitz von Com bleiben und unverändert gültig sein, bis CanIf_Transmit synchron zurückkehrt. Erst nach Abschluss des synchronen Aufrufs (Rückkehr von PduR_ComTransmit) darf Com den Sendepuffer überschreiben.
• PDU-ID-Entkopplung (Konfiguration): Die ComTxPduId und die CanIfTxPduId sind disjunkte Wertebereiche. Sie müssen über PduRRoutingPath (PduRSrcPdu zu PduRDestPdu) im PduR-Konfigurationsmodell (PduR_PBcfg.c / Link-Time) deterministisch aufeinander abgebildet werden.
• Fehlerpfade & Abbruchbedingungen:
  • Gibt CanIf_Transmit den Status E_NOT_OK zurück (z. B. Busy, Hardware-Fehler, PDU-Kanal gestoppt), wird E_NOT_OK unmittelbar an Com durchgereicht. In diesem Fall unterbleibt die asynchrone TxConfirmation zwingend.
  • Schlägt der Bus-Transfer fehl oder greift ein Bus-Off, darf kein E_OK via PduR_<User:lo>TxConfirmation gemeldet werden.
• Ausführungskontext / ISR-Sicherheit:
  • Der Sendeaufruf (PduR_ComTransmit) erfolgt in der Regel im Task-Kontext (z. B. Com_MainFunctionTx oder OS-Task).
  • Der Bestätigungspfad (CanIf_TxConfirmation → PduR_<User:lo>TxConfirmation → Com_TxConfirmation) wird häufig direkt aus dem CAN-Tx-Interrupt-Kontext aufgerufen. Die Implementierung von Com_TxConfirmation muss daher kurz, unterbrechungsfest und reentrant gegenüber konkurrierenden Sendeanforderungen sein.