Figure 7.9: Example serialization settings

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturschichtenmodell (Block- und Datenflussdiagramm) mit exemplarischer Konfigurations- und API-Zuordnung.
• Technischer Zweck: Visualisierung der Serialisierungsmechanismen im AUTOSAR Adaptive Platform Communication Management (ara::com) gemäß R19-11. Das Diagramm demonstriert die koexistierende Abwicklung von:
  1. nativer SOME/IP-Serialisierung (serialization=someip),
  2. signalbasierter Übersetzung (serialization=signalBased / Signal-to-Service-Translation) für klassische AUTOSAR-Interoperabilität (Signal-PDU-Mapping) innerhalb desselben Service-Interface-Deployments über SOME/IP.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application & Service-Instanz:
  • Applikationsschicht, die Instanzen eines generierten Skeleton-Interfaces hält.
  • Nutzdaten-Payloads: dataX (für Standard-SOME/IP-Event) und dataY (für Signal-basiertes Event).
• API & Language Binding:
  • ara::com API: Standardisierte Schnittstelle (ara::com::Skeleton).
  • C++ Language Binding: Typsichere Schnittstellenaufrufe x.Send(dataX) und y.Send(dataY) sowie Lebenszyklussteuerung OfferService().
• Communication Binding & Serialisierung:
  • SOME/IP serializer: Transformiert C++-Typen strukturiert nach AUTOSAR SOME/IP-Serialisierungsregeln in ein Bytestrom-Format ([H][SOME/IP Serialized Bytes], wobei H = SOME/IP Header).
  • signal-service-translation: Mappt strukturierte Applikationsdaten gemäß Signal-PDU-Layout in Bit-/Bytefelder einer PDU und kapselt diese in eine SOME/IP-Nachricht ([H][PDU]).
• Deployment-Modell-Entitäten (ARXML-Metamodell):
  • SomeIpEventDeployment x: Konfiguriert Event-ID 98 mit Attribut serialization = someip.
  • SomeIpEventDeployment y: Konfiguriert Event-ID 79 mit Attribut serialization = signalBased.
• Communication Management (Plattform-Kern):
  • Dispatching and Discovery: Zentrale Routing-Instanz für Service Discovery (SOME/IP-SD) und Event-Dispatching an die Ziel-Transportschichten.
  • SOME/IP Transport: Paketiert SOME/IP-Nachrichten über UDP/TCP.
  • IPC Transport / IPC: Alternativer Inter-Prozess-Transportpfad für Node-interne Kommunikation.
• Foundation & Hardware:
  • TCP/IP-Stack und Ethernet Driver auf Betriebssystem-/Plattformebene über der (Virtual) Machine / Hardware.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung:
   • Die Applikation initialisiert das Service-Skeleton und ruft synchron OfferService() auf.
   • Dispatching and Discovery propagiert das Service-Angebot (z. B. via SOME/IP-SD Offer-Message über das Netzwerk).
2. Event-Triggering (Sendeaufrufe):
   • Pfad A (x.Send(dataX)):
     • Sprachebene übergibt dataX an das SOME/IP-Binding.
     • Serialisierer erzeugt die Nutzlast anhand der SOME/IP-Transformationsregeln.
     • Ein valider SOME/IP-Header (inkl. Service ID, Method/Event ID 98, Client/Session ID, Interface Version, Message Type 0x02 für Notification) wird vorangestellt.
   • Pfad B (y.Send(dataY)):
     • Sprachebene übergibt dataY an das Signal-Service-Translations-Modul.
     • Die Daten werden bitgenau in das konfigurierte PDU-Layout serialisiert/kopiert (Signal-Mapping analog zu Classic AUTOSAR Com/PduR).
     • Der SOME/IP-Header mit Event ID 79 wird der serialisierten PDU als Container vorangestellt.
3. Dispatch & Transport:
   • Beide Serialisierungsströme werden in Dispatching and Discovery nach Routingregeln ausgewertet.
   • Weitergabe an SOME/IP Transport → Socket-API / TCP/IP → Ethernet Driver → physikalisches Medium (bzw. bei Node-internen Empfängern alternativ an den IPC-Pfad).

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Konfigurationsvertrag (SWS_CM_10174):
  • In SomeIpEventDeployment entscheidet das Pflicht-Enum serialization (someip vs. signalBased) über den vom Codegenerator implementierten Serialisierungspfad des Skeletons.
  • Bei signalBased müssen zwingend Signal-to-PDU-Mappings (ISignalIPdu, ISignal) hinterlegt sein; es findet keine SOME/IP-spezifische Typ-Serialisierung (wie Length-Fields, Dynamic Array Flags) statt, sondern Byte-Packs gemäß PDU-Definition.
• Transparenz der Applikations-API (RS_CM_00204):
  • Die API-Signatur von x.Send() und y.Send() bleibt auf C++11-Ebene identisch. Die Applikationslogik ist vollständig entkoppelt von der Netzwerk-Repräsentation (SOME/IP-Payload vs. gekapselte PDU).
• Interoperabilität (Classic ↔ Adaptive):
  • serialization=signalBased über SOME/IP ermöglicht die direkte Gateway-freie Kommunikation mit Classic Platform Steuergeräten, die SOME/IP-Events direkt als PDU über den PduR/Com-Stack empfangen oder Signal-PDUs über SOME/IP tunneln.
• Stack- & Laufzeit-Einschränkungen:
  • Zero-Copy / Pufferverwaltung: Bei signalBased fallen zusätzliche Packing- und Layout-Translationsschritte an; Treiber- und Stack-Implementierer müssen das Alignment von PDUs innerhalb der SOME/IP-Payload sicherstellen.
  • Event-ID-Eindeutigkeit: Die Zuordnung von eventId zu serialization erfolgt pro Event-Deployment statisch zur Modellierungszeit und ist zur Laufzeit unveränderlich.