DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_CommunicationManagement FIG-2f97f730eba7a635 639 × 101 px 1 Release(s)

Figure 7.38: Payload covered by SecOC and SOME/IP transport

SHA-256 Inhalts-Fingerabdruck: 2f97f730eba7a63545ba9b4b16677f6d91fccc9efae5a9adfcd57424bcd4ac68

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

Strukturdiagramm zum Paket- und Headeraufbau im AUTOSAR-Adaptive-Kommunikationsmanagement (ara::com / Communication Management). Es stellt die Anordnung der Header- und Payload-Felder eines SOME/IP-Pakets mit angehängter SecOC-Absicherung dar.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm zeigt eine lineare Paketstruktur bestehend aus folgenden Feldern:

  • SOME/IP Msg Header Part I: Erster Abschnitt des SOME/IP-Headers (Message ID und Length-Feld).
  • SOME/IP Msg Header Part II: Zweiter Abschnitt des SOME/IP-Headers (Request ID, Protocol Version, Interface Version, Message Type, Return Code).
  • SOME/IP Serialized Payload: Nutzdatenfeld, unterteilt in die Komponenten x, y und z.
  • SecOC (truncated) Freshness: Angehängter Frischewert zur Replay-Prävention.
  • SecOC (truncated) Authenticator: Angehängter Prüfwert (MAC) zur Authentifizierung.
  • Payload covered by SOME/IP Length: Oberhalb verlaufender Balken, der anzeigt, dass das SOME/IP-Längenfeld ab SOME/IP Msg Header Part II über die serialisierte Payload bis einschließlich des SecOC Authenticators reicht.

3. Dynamisches Verhalten & Sequenzablauf

Statisches Layout des fertigen Transportpakets: SOME/IP Msg Header Part I führt das Paket an, gefolgt von SOME/IP Msg Header Part II, der serialisierten Payload (x, y, z) und den abschließenden SecOC-Feldern (Freshness und Authenticator). Das Längenfeld in Part I deckt alle nachfolgenden Felder lückenlos ab.

4. Normative Relevanz & Entwickler-Hinweise

Normative Vorgabe für das Nachrichtenlayout und die SOME/IP-Längenberechnung bei Einsatz von SecOC:

  • Die Gesamttransportlänge im SOME/IP-Header (Part I) umfasst die verbleibenden Header-Felder (Part II), die Nutzdaten sowie die vollständigen SecOC-Zusatzfelder (Freshness und Authenticator).

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

R20-11 → R21-11 redaktionell Vorgänger: FIG-17387024b44d5d52
  • Die schrittweise Darstellung des Protokollaufbaus in drei übereinanderliegenden Paketschichten entfällt; nur die finale Gesamtstruktur des SOME/IP-Pakets mit SecOC-Anhängen bleibt erhalten.
  • Die Beschriftung und Kennzeichnungsklammer „Payload covered by SecOC“ über dem Zwischenschritt entfällt.
  • Die vorangegangenen isolierten Teildarstellungen („SOME/IP Msg Header Part II“ mit „SOME/IP Serialized Payload [x, y, z]“ sowie die Variante mit angehängter Freshness und Authenticator) entfallen.
  • Die Beschriftung „Payload covered by SOME/IP Length“ ist am oberen Bildrand beschnitten.
R21-11 → R22-11 keine inhaltliche Änderung Nachfolger: FIG-89503668ed01de1e

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

RS_SEC_04001 Wortlaut noch nicht übernommen SWS_CM_90108 SWS_CM_90115

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

SOME/IP Serialized Payload SOME/IP Msg Header | Part II | SOME/IP Msg Header | Part I x y z | SecOC (truncated) | Freshness | SecOC (truncated) Authenticator

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_SWS_CommunicationManagement S. 263 7.38 Figure 7.38: Payload covered by SecOC and SOME/IP transport
R21-11 AUTOSAR_SWS_CommunicationManagement S. 263 7.38 Figure 7.38: Payload covered by SecOC and SOME/IP transport