Figure 14: Verification with upper layer TP

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (loop, opt) und Task-Kontext-Annotation (scheduled main task).
• Funktionale Einordnung: Veranschaulicht den Empfangs- und Verifikationspfad von segmentierten bzw. großvolumigen I-PDUs über Transportprotokoll-Schnittstellen (TP) im AUTOSAR Classic Communication Stack (AUTOSAR_SWS_SecureOnboardCommunication).
• Technischer Zweck: Spezifikation der Entkopplung zwischen dem physikalischen TP-Empfang (durch CanTp), der Zwischenpufferung und kryptografischen Verifikation (durch SecOC) sowie der verzögerten Weitergabe der verifizierten Nutzdaten an die Applikations-/Signalschicht (Com). Es wird sichergestellt, dass unvollständige oder manipulierte TP-Nachrichten die oberen Schichten niemals erreichen.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Module («module»):
  • CanTp: Untere TP-Schicht (Transport Layer), zuständig für Segmentierung, Flusssteuerung und Reassemblierung auf dem CAN-Bus.
  • PduR: PDU-Router; leitet TP-API-Aufrufe zwischen Quell- und Zielmodulen über konfigurierte Routing-Pfade weiter.
  • SecOC: Secure Onboard Communication Modul; implementiert Verifikation (MAC/Signaturprüfung via CSM/Crypto Stack) und Pufferung.
  • Com: AUTOSAR Communication Modul; Signalverarbeitung und Bereitstellung für die RTE/SW-Cs.
• Verwendete TP-Datentypen & Schnittstellen:
  • BufReq_ReturnType: Rückgabestatus für Pufferabfragen (BUFREQ_OK, BUFREQ_E_NOT_OK, BUFREQ_E_BUSY, BUFREQ_E_OVFL).
  • PduIdType: Kennung der empfangenen TP-PDU.
  • PduInfoType*: Zeiger auf Puffer-Metadaten (SduDataPtr, SduLength).
  • PduLengthType, PduLengthType*: Größenangaben und verbleibender freier Pufferplatz.
  • Std_ReturnType: Statusrückmeldung der Indication (E_OK, E_NOT_OK).

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Initialisierung des TP-Empfangs (Synchroner Pfad)

1. CanTp signalisiert den Empfang des ersten Segments / Start-Frames via PduR_CanTpStartOfReception(...).
2. PduR routet synchron auf SecOC_StartOfReception(...).
3. SecOC führt intern prepare() aus (Prüfung und Allokation von internem Puffer/Kontext für die gesicherte PDU).
4. SecOC initiiert über PduR_SecOCTpStartOfReception() den Empfangspfad zu Com_StartOfReception().
5. Nach Bestätigung durch Com (BUFREQ_OK) quittiert SecOC gegenüber CanTp mit BUFREQ_OK (inklusive Puffergrößenverhandlung via PduLengthType*).

Phase 2: Segmentierter Datentransfer (loop)

1. Für jedes eintreffende TP-Segment ruft CanTp PduR_CanTpCopyRxData(...) auf.
2. Weiterleitung via PduR an SecOC_CopyRxData(...).
3. SecOC kopiert das Segment in den internen Puffer (copyData()) und antwortet synchron mit BUFREQ_OK.
4. Der Pufferfortschritt wird über PduR an CanTp zurückgemeldet, bis alle Segmente übertragen sind.

Phase 3: Abschluss des TP-Empfangs (opt)

1. Nach Eingang des letzten Segments meldet CanTp den vollständigen Empfang via PduR_CanTpRxIndication(..., E_OK).
2. Weiterleitung an SecOC_TpRxIndication(...).
3. Zu diesem Zeitpunkt sind die Rohdaten vollständig in SecOC gepuffert, aber noch nicht an Com übergeben.

Phase 4: Asynchrone Verifikation (scheduled main task)

1. Im zyklischen Kontext (SecOC_MainFunctionRx) prüft SecOC, ob zu verarbeitende Nachrichten anstehen (Polling-Bedingung: „Checks first if messages need to be processed: if yes it does the processing, if not it returns“).
2. Ausführung von verify(): Kryptografische Validierung der Authenticator-/Freshness-Daten (z. B. CMAC über SDU + Freshness Value via CSM).

Phase 5: Weiterleitung der authentifizierten Daten an Com (opt [successful verification])

1. Loop [while all data copied]: SecOC triggert PduR_SecOCTpCopyRxData() → Com_CopyRxData(). Com führt copyData() in die Signalpuffer aus und quittiert mit BUFREQ_OK.
2. Opt [all data copied]: Nach vollständiger Übergabe signalisiert SecOC den erfolgreichen Abschluss via PduR_SecOCTpRxIndication() → Com_TpRxIndication().

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Allokation & Dimensionierung: SecOC benötigt vollständigen Puffer-Speicher für die größte konfigurierte Secured I-PDU im TP-Pfad (SecOCTpRxPduBufferRef / konfigurierte Puffergröße). Da die Verifikation erst nach vollständigem Empfang erfolgen kann, ist ein Streaming direkt in Com normativ ausgeschlossen.
• Routing-Konfiguration (PduR): Für eine gesicherte TP-Verbindung existieren zwei getrennte PduR-Routen:
  1. Lower TP zu SecOC: CanTp → PduR → SecOC (PduR-Routing-Path für Secured PDU).
  2. SecOC zu Upper Layer: SecOC → PduR → Com (PduR-Routing-Path für Authentic PDU).
• Latenz & Task-Scheduling: Die Latenzzeit bis zur Signalverfügbarkeit in Com hängt direkt von der Zykluszeit der SecOC_MainFunctionRx sowie der Rechenzeit der Verifikation (verify(), synchron oder asynchron via Crypto Stack/CSM) ab. Dies muss im Worst-Case-Execution-Time-Budget (WCET) berücksichtigt werden.
• Fehlerbehandlung: Schlägt die Verifikation fehl (verify() fehlerhaft) oder bricht CanTp vorzeitig mit E_NOT_OK ab, unterbleibt der Aufruf von PduR_SecOCTpRxIndication in Richtung Com. Der interne Puffer in SecOC wird verworfen; Com erhält keinerlei Datenreste.