Figure 7.12: SOME/IP header structure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Binäres Protokoll-Frame- / PDU-Header-Layout in RFC-Bitfeld-Notation (32-Bit-Raster, Big-Endian / Network Byte Order).
• Technischer Zweck: Spezifikation des normativen SOME/IP-Nachrichtenheaders (16 Bytes Basislänge) für die dienstorientierte Inter-ECU- und Intra-ECU-Kommunikation.
• Architektur-Kontext:
  • Adaptive Platform (ara::com): Bildet die Serialisierungs- und Framing-Grundlage für das SOME/IP-Binding von Service-Proxies und Service-Skeletons oberhalb des POSIX-IP-Stacks (UDP/TCP).
  • Classic Platform: Entspricht der PDU-Struktur des SomeIpXf (SOME/IP Transformer) bzw. des SOME/IP-Stacks (SoAd / PduR / SomeIpTp).

2. Komponenten, Entitäten & Schnittstellen

Strukturierung im 32-Bit-Wort-Raster (Offsets 0 bis 31 Bit):

• Word 0 (Bit 0–31) – Message ID [32 bit]:
  • Service ID [Bit 0–15 / 16 bit]: Eindeutige logische Bezeichnerkonstante des Dienstes (Manifest-Parameter / ARXML-Definition).
  • Method ID / Event ID [Bit 16–31 / 16 bit]: Selektor der Methode oder des Events. Das höchstwertige Bit dieses Teilbereichs (Bit 16 des Gesamtworts) fungiert als Diskriminator: 0 = Methode, 1 = Event/Notifier.
• Word 1 (Bit 32–63) – Length [32 bit]:
  • Enthält die Bytezahl des gesamten nachfolgenden Datenstroms ab Bit 64 bis zum PDU-Ende.
  • Formel: $\text{Length} = 8\,\text{Bytes (Rest-Header)} + \text{Payload-Länge in Bytes}$.
• Word 2 (Bit 64–95) – Request ID [32 bit]:
  • Client ID [Bit 0–15 / 16 bit]: Eindeutiger Identifikator des aufrufenden Clients/Knotens/Prozesses im System.
  • Session ID [Bit 16–31 / 16 bit]: Inkrementeller Transaktionszähler zur Request-Response-Korrelation oder zur Detektion von Paketverlusten bei zyklischen/asynchronen Events.
• Word 3 (Bit 96–127) – Protokoll- und Steuerbytes [je 8 bit]:
  • Protocol Version [8 bit]: Versionsstand des SOME/IP-Basisprotokolls (normativ auf 0x01 fixiert).
  • Interface Version [8 bit]: Major-Version der Serviceschnittstelle; dient der statischen Kompatibilitätsprüfung.
  • Message Type [8 bit]: Kodierung des Kommunikationsmusters und Framing-Flags:
    • 0x00: REQUEST (RPC mit Antwort)
    • 0x01: REQUEST_NO_RETURN (Fire & Forget)
    • 0x02: NOTIFICATION (Events, Field-Update)
    • 0x80: RESPONSE (Erfolgreiche Antwort auf Request)
    • 0x81: ERROR (Fehler-Antwort auf Request)
    • TP-Flag (Bit 5 / Maske 0x20): Kennzeichnet ein SOME/IP-TP-Segment (Transport Protocol für segmentierte Payloads).
  • Return Code [8 bit]: Fehlerklassifikation (in Requests/Notifications immer 0x00 / E_OK):
    • 0x00: E_OK
    • 0x01: E_NOT_OK (Generischer Fehler)
    • 0x02: E_UNKNOWN_SERVICE
    • 0x03: E_UNKNOWN_METHOD
    • 0x07: E_WRONG_PROTOCOL_VERSION
    • 0x08: E_WRONG_INTERFACE_VERSION
    • 0x09: E_MALFORMED_MESSAGE
• Word 4+ – Payload [variable size]:
  • Serialisierte Methodenargumente, Return-Werte oder Event-Nutzdaten gemäß AUTOSAR-Datentyp-Serialisierungsregeln.

3. Dynamisches Verhalten & Sequenzablauf

Eingehender Ingress-Deserialisierungs- und Dispatching-Pfad im SOME/IP-Daemon / Binding:

1. Header-Validierung (Integritätsprüfung):
   • Verifikation, ob empfangene Bytezahl ≥ 16 Bytes beträgt.
   • Konsistenzprüfung: Received_Bytes - 8 == Length-Feld. Andernfalls Verwerfen der PDU und optionaler Error-Response (E_MALFORMED_MESSAGE).
2. Versions-Check:
   • Abgleich Protocol Version == 0x01. Mismatch triggert Abbruch (E_WRONG_PROTOCOL_VERSION).
   • Abgleich Interface Version gegen die deployte Major-Version des Ziel-Skeletons. Mismatch triggert E_WRONG_INTERFACE_VERSION.
3. Dispatching & Demultiplexing:
   • Auflösung von Service ID und Method ID / Event ID zur Adressierung der registrierten Service-Instanz.
4. Session- & Korrelations-Handling:
   • Request/Response: Der Server übernimmt Client ID und Session ID unverändert in den Header der Antwort (Message Type = 0x80 oder 0x81), damit der aufrufende Client über den Pending-Request-Table das asynchrone Future auflösen kann.
   • Notification: Prüfung der Session ID auf Monotonie zur Erkennung von Frame-Drops über UDP.
5. Return-Code-Auswertung (Client-seitig):
   • Empfang von Message Type 0x81 mappt den Return Code auf einen applikativen Fehlercode bzw. auf ara::core::ErrorCode / Exception.

4. Normative Relevanz & Entwickler-Hinweise

• Endianness: Sämtliche Header-Felder liegen strikt in Big-Endian (Network Byte Order) vor. Dies gilt unabhängig von der Byte-Order der Payload (die per Konfiguration Little-Endian sein kann).
• Length-Feld-Offset-Falle: Length quantifiziert nicht die gesamte PDU-Größe, sondern schließt die ersten 8 Bytes (Message ID + Length selbst) aus. Ein Berechnungsfehler führt unweigerlich zu Deserialisierungsfehlern im Empfänger.
• TP-Segmentierung: Wenn Payload + 16 Bytes die MTU des Netzes (typisch 1400–1500 Bytes bei Automotive Ethernet) übersteigt und UDP verwendet wird, greift SOME/IP-TP:
  • Hinter Return Code wird ein zusätzlicher 32-Bit TP-Header (Offset [28 bit], Reserved [3 bit], More Segments [1 bit]) eingefügt.
  • Das TP-Flag im Message Type muss zwingend gesetzt werden.
• Alignment & Zero-Copy: Die feste Headergröße von exakt 16 Bytes (128 Bit) ist 32-Bit-aligned. Embedded-Treiber können den Header direkt auf struct-basierte Typen mappen, sofern Compiler-Packing (#pragma pack(1)) und Endianness-Konvertierungs-Makros (ntohl, ntohs) korrekt angewandt werden.