DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_PDURouter FIG-235d5512eb77db88 751 × 382 px 1 Release(s)

Figure 9.1: CanIf to COM I-PDU reception

SHA-256 Inhalts-Fingerabdruck: 235d5512eb77db88e53a08e78bb32db89238bc348dbc1ef4a546d50805898ce2

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

  • Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
  • Technischer Zweck: Spezifikation des synchronen 1:1-Empfangspfads einer unfragmentierten Kommunikations-PDU (I-PDU) von der unteren Abstraktionsschicht (Communication Interface) zur oberen Kommunikationsschicht (COM).
  • Architektur-Einordnung: AUTOSAR Classic Platform (CP), Schichtenmodell der Basissoftware (BSW). Veranschaulicht die Rolle des PDU Routers (PduR) als zustandsloser Dispatcher bei direkter Routing-Beziehung ohne Gateway-Kopplung und ohne Zwischenpufferung (PduRBuffer = 0).

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / BSW-Module (Stereotyp «module»):
    • CanIf (CAN Interface, Lower Layer / <User:Lo>): Treiberabstraktion für CAN-Controller/Transceiver, Initiator des Empfangsevents.
    • PduR (PDU Router): Zentraler BSW-Router im Service Layer zur Entkopplung und Weiterleitung von PDUs.
    • Com (AUTOSAR COM, Upper Layer / <User:Up>): Signalorientierte Verarbeitungsschicht (Signal-Extraktion, Filterung, Benachrichtigung der Applikation via RTE).
  • Schnittstellen & Signaturen:
    • PduR_<User:Lo>RxIndication(PduIdType RxPduId, const PduInfoType* PduInfoPtr):
      • Konkrete Instanz: PduR_CanIfRxIndication(...).
      • Parameter: RxPduId (Quell-ID aus Sicht des CanIf), PduInfoPtr (Zeiger auf SduDataPtr, MetaDataPtr, SduLength).
    • Com_RxIndication(PduIdType RxPduId, const PduInfoType* PduInfoPtr):
      • Ziel-API des COM-Moduls, aufgerufen mit der konfigurierten Ziel-PDU-ID (ComRxPduId).
  • Interne Aktionen & Notizen:
    • copy buffer(): Lokale Pufferoperation innerhalb des Com-Moduls (Kopieren der Nutzdaten aus dem temporären RX-Treiberpuffer in interne COM-Signalpuffer).
    • Annotation: "Reception of IPDU going directly to COM. No buffering in PduR is needed."

3. Dynamisches Verhalten & Sequenzablauf

  1. Trigger: CanIf detektiert den erfolgreichen Empfang eines CAN-Frames (entweder via RX-Interrupt des CAN-Controllers oder zyklisch im Kontext von Can_MainFunction_Read() / CanIf_MainFunction_RxIndication()).
  2. Aufruf PduR: CanIf ruft synchron PduR_<User:Lo>RxIndication(CanIfRxPduId, PduInfoPtr) auf.
  3. PduR-Routing:
    • PduR führt ein O(1)-Tabellen-Lookup (Array-Indexierung anhand CanIfRxPduId) durch.
    • PduR validiert den PDU-Zustand (sofern Initialisierung und Det aktiviert sind; Det-Prüfungen auf PDUR_E_UNINIT, PDUR_E_PDU_ID_INVALID, PDUR_E_PARAM_POINTER).
    • Da es sich um Direktrouting zu Com handelt, allokiert PduR keinen Speicher und blockiert nicht.
  4. Weiterleitung an Com: PduR ruft synchron Com_RxIndication(TargetComRxPduId, PduInfoPtr) auf.
  5. Verarbeitung in Com (copy buffer()):
    • Das COM-Modul kopiert die Nutzdaten (PduInfoPtr->SduDataPtr) sofort synchron in seinen eigenen internen Puffer, um Signalinkonsistenzen bei nachfolgenden Re-Entrancies oder dem Überschreiben der Hardware-/Treiber-Mailbox zu verhindern.
    • Aktualisierung der Empfangs-Deadline-Überwachung (Reception Deadline Monitoring) und Auswertung von Rx-Filtern.
  6. Rückkehr: Synchroner Stack-Unwind (return void) von Com über PduR zurück zu CanIf.

4. Normative Relevanz & Entwickler-Hinweise

  • Ausführungskontext & Latenz:
    • Der gesamte Calltree läuft synchron im Ausführungskontext des Aufrufers (CanIf).
    • Achtung bei Interrupt-Kontext: Ist CanIfRxIndication in einem ISR-Kontext konfiguriert (CANIF_RX_INDICATION_INTERRUPT), blockiert Com_RxIndication samt Signal-Entpackung und Pufferkopie den Interrupt-Service. Bei komplexen PDUs sollte im CanIf/CAN-Treiber Polling (CanIf_MainFunction_Read) gewählt oder in Com eine signalbasierte Deferred-Verarbeitung (COM_DEFERRED) parametriert werden.
  • PduR-Konfiguration:
    • Erfordert eine PduRRoutingPath-Konfiguration mit PduRSrcPdu (Referenz auf CanIf-PDU) und genau einem PduRDestPdu (Referenz auf Com-PDU).
    • PduRDestPduDataProvision muss auf DIRECT (nicht GATEWAY) konfiguriert sein; PduRQueueDepth bleibt unkonfiguriert (0), da kein TP- oder Gateway-FIFO-Puffer erforderlich ist.
  • Puffer-Lebenszyklus:
    • Der Speicherbereich hinter PduInfoPtr->SduDataPtr ist nur für die Dauer des Funktionsaufrufs gültig. Der Upper-Layer (Com) muss die Daten zwingend synchron abziehen (copy buffer()); ein Speichern des Zeigers ist nach AUTOSAR-SWS unzulässig.

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

R22-11 → R23-11 keine inhaltliche Änderung Vorgänger: FIG-1c39ae55a06d7dc0

Keine inhaltlichen Änderungen erkennbar.

R24-11 → R25-11 keine inhaltliche Änderung Nachfolger: FIG-8c8dd4bce73608c8

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«module» | PduR | «module» | Com | «module» | CanIf |                         |    |  |  |   |         |  |   |  |      | copy buffer() | PduR_<User:Lo>RxIndication(PduIdType, const PduInfoType*) | Com_RxIndication(PduIdType, const PduInfoType*)

Begleitender Spezifikationstext:

Specification of PDU Router AUTOSAR CP R23-11 9 Sequence diagrams The goal of this chapter is to make the understanding of the PDU Router easier. For this purpose sequence diagrams which show different communication scenarios are used. Please consider that the sequence diagrams are not exhaustive and are only used to support the functional specification (Chapter 7) and API specification (Chapter 8). Focus of the sequence diagrams is the PDU Router and therefore interactions between other modules (e.g. between an interface and its driver) are not shown. Note: The sequence diagrams of the I-PDU Multiplexer are shown in [4]. Depending on the interaction scenario the IpduM has to be considered as an upper layer or a lower layer module of the PDU Router. Note: The diagrams in this chapter are to show specific use-cases. They are not requirements for an implementation of the PDU Router module. 9.1 I-PDU Reception The reception of an I-PDU received from a Communication Interface module or from Transport Protocol module and forwarded to the COM module. Note that the PDU Router is not the only customer for the Communication Interface modules and I-PDUs. Other modules such as NM and TP modules receive PDUs directly from the Communication Interface modules. 9.1.1 CanIf module I-PDU reception Following Figure 9.1 shows reception of I-PDU from the CanIf module to the COM module. «module» PduR «module» Com «module» CanIf        

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_CP_SWS_PDURouter S. 82 9.1 Figure 9.1: CanIf to COM I-PDU reception