Figure 9.13: Gateway of I-PDU from CAN to LIN

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit bedingtem Ausführungsrahmen / alt-Kombinationsfragment).
• Technischer Zweck: Spezifikation des Gateway-Mechanismus für I-PDUs zwischen ereignisgesteuerten Kommunikationsschnittstellen (hier: CanIf) und zeitgesteuerten bzw. abfragebasierten Schnittstellen (hier: LinIf, übertragbar auf FrIf / FlexRay) im AUTOSAR Classic Platform Communication Stack (PduR, SWS PDU Router).
• Funktionale Einordnung: Entkopplung von Empfang und Weitersenden über PDU-Pufferung (FIFO/Single-Buffer) im PduR unter Verwendung des AUTOSAR TriggerTransmit-Prinzips (Pull-Mechanismus durch den LIN-Master-Scheduler anstelle von direktem Push bei Übertragung).

2. Komponenten, Entitäten & Schnittstellen

Beteiligte BSW-Module (Akteure mit Stereotyp «module»):

• PduR (PDU Router): Zentraler Vermittlungsknoten; übernimmt PDU-Identifikation, Routing-Tabellen-Auflösung, Pufferverwaltung (FIFO/Queue) und Datenduplikation/-bereitstellung.
• CanIf (CAN Interface): Untere Schicht der Quellseite (Lower Layer Producer); meldet asynchron eingegangene CAN-I-PDUs.
• LinIf (LIN Interface): Untere Schicht der Zielseite (Lower Layer Consumer); agiert im LIN-Cluster als Master und fordert Daten gemäß Schedule-Table an.

Schnittstellen & Datentypen (API-Signaturen):

• PduR_<User:Lo>RxIndication(PduIdType RxPduId, const PduInfoType* PduInfoPtr):
  • Callback von CanIf an PduR zur Übergabe der empfangenen I-PDU.
• LinIf_Transmit(PduIdType TxPduId, const PduInfoType* PduInfoPtr) (im Diagramm inkl. Return-Typ dargestellt):
  • Steueraufruf zur Vormerkung eines sporadischen LIN-Frames.
• PduR_<User:Lo>TriggerTransmit(PduIdType TxPduId, PduInfoType* PduInfoPtr):
  • Abruf-Callback von LinIf an PduR, um Nutzdaten synchron in den LIN-Treiberpuffer bereitzustellen.
• PduR_<User:Lo>TxConfirmation(PduIdType TxPduId, Std_ReturnType result):
  • Bestätigungs-Callback nach erfolgreichem/fehlerhaftem Sendevorgang auf dem LIN-Bus.
• Datenstrukturen:
  • PduInfoType: Enthält Zeiger auf SDU-Daten (SduDataPtr), Metadaten (MetaDataPtr) und SDU-Länge (SduLength).
  • PduIdType: Ganzzahlige ID zur Identifikation der Quell-/Ziel-I-PDU.

3. Dynamisches Verhalten & Sequenzablauf

1. Empfang & Pufferung (Asynchroner Empfangspfad):
   • CanIf signalisiert den Empfang via PduR_<User:Lo>RxIndication(...).
   • PduR speichert die I-PDU intern (buffer IPDU()). Die Pufferung kann als FIFO für mehrere I-PDUs konfiguriert sein (PduRQueueDepth > 1).
2. Bedingte Signalisierung (alt-Block):
   • Zweig [if LIN sporadic frame]: PduR triggert LinIf_Transmit(...). LinIf setzt intern ein Sendeflag (flag frame for transmission()), damit der LIN-Master den Frame im nächsten passenden Slot der Schedule-Table einplant. Synchroner Rücksprung.
   • Zweig [otherwise] (Unconditional / Event-triggered Frames): Keine explizite Benachrichtigung von LinIf erforderlich; der Schedule-Ablauf im LIN-Master ist rein deterministisch vorgegeben.
   • PduR schließt die Bearbeitung von RxIndication ab und kehrt zu CanIf zurück.
3. Datenauslese via Pull-Prinzip (Zeitgesteuerter Sendepfad):
   • Erreicht der LIN-Scheduler den entsprechenden Frame-Slot, fordert LinIf die aktuellen Nutzdaten via PduR_<User:Lo>TriggerTransmit(...) an.
   • PduR kopiert die älteste gepufferte I-PDU (copy data(), FIFO-Prinzip: „Get the oldest IPDU“) in den bereitgestellten Puffer von PduInfoPtr.
4. Sendeabschluss:
   • Nach physischem Bus-Versand meldet LinIf den Status synchron oder asynchron via PduR_<User:Lo>TxConfirmation(...) an den PduR.
   • PduR quittiert und gibt den entsprechenden Pufferplatz frei.

4. Normative Relevanz & Entwickler-Hinweise

• PduR-Pufferkonfiguration (PduRBuffer / PduRQueueDepth):
  • Für das Gatewaying CAN → LIN ist im PduR zwingend ein Puffer erforderlich, da LinIf_Transmit die Nutzdaten nicht kopiert, sondern das Versenden erst im späteren TriggerTransmit-Kontext stattfindet.
  • Bei PduRQueueDepth = 1 überschreiben neu eintreffende CAN-Nachrichten ältere Daten (Data Overwrite), sofern diese bis dahin nicht vom LIN-Scheduler abgerufen wurden.
  • Bei FIFO-Nutzung (PduRQueueDepth > 1) muss auf Pufferüberlauf (BUFREQ_E_OVFL) geachtet und eine Overflow-Strategie konfiguriert werden.
• Reentrant- & Task-Kontext-Anforderungen:
  • PduR_<User:Lo>RxIndication läuft im Kontext des CAN-Interrupts bzw. der Can_MainFunction_Read / CanIf-Task.
  • PduR_<User:Lo>TriggerTransmit wird im Schedule-Kontext der LinIf_MainFunction aufgerufen.
  • Kritischer Bereich (Exclusive Area): Der PduR-Puffer muss threadsicher vor konkurrierendem Zugriff zwischen RxIndication (Write/Enqueue) und TriggerTransmit (Read/Dequeue) geschützt werden.
• Return-Werte & Fehlerbehandlung bei TriggerTransmit:
  • Ist der PduR-Puffer leer (keine Daten empfangen), gibt PduR_<User:Lo>TriggerTransmit normativ E_NOT_OK zurück; LinIf bricht den Sendevorgang für diesen Slot ab oder sendet Null-Bytes (gemäß LIN-Spezifikation).
• Portabilität des Musters:
  • Das dargestellte Interaktionsmuster gilt identisch für Gateways in Richtung FlexRay Interface (FrIf), sofern dort I-PDUs ebenfalls über FrIf_TriggerTransmit bedient werden.