Figure 7.7: Interaction of components during E2E protection of the Method request at the client side

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP, Release R20-11), Spezifikation AUTOSAR_SWS_CommunicationManagement ([SWS_CM_90458]).
• Funktionale Einordnung: Detaillierung des clientseitigen Methodenaufrufs (Remote Procedure Call, RPC) über die serviceorientierte Middleware ara::com. Es definiert die normative Verarbeitungs- und Kapselungsreihenfolge zur funktionalen Sicherheit (End-to-End / E2E-Protection, typischerweise gem. SOME/IP-Transformator- bzw. E2E-Profilspezifikation) vor der Übergabe an den Netzwerk-Stack.

2. Komponenten, Entitäten & Schnittstellen

Akteure / Lifelines

• Client application: Adaptive Application (Software Component als Service Consumer).
• ara::com: Adaptive Platform Kommunikations-Middleware (konkret: instanziierte generierte Proxy-Methodenklasse).
• Transmission: Netzwerk- und Protokoll-Bindungsschicht (z. B. SOME/IP-Binding, Socket-Layer/IPC).

Datenstrukturen & Parameter

• Methodenargumente: arg1, ..., argN (In- und Inout-Parameter der Methodensignatur).
• serializedData: Bytestrom/Payload-Array im Speicher.
• E2E-Protected Header: SOME/IP-Headerfelder, die in die E2E-Prüfsummenberechnung einfließen (Client ID, Session ID, Protocol Version, Interface Version, Message Type, Return Code).
• E2E-Header: E2E-Prüfdaten gemäß zugewiesenem E2E-Profil (enthält u. a. CRC/Checksumme und Sequence Counter).
• Non-Protected Header: Routing-/Transport-Headerfelder, die außerhalb der E2E-Prüfsumme liegen (Service ID, Method ID, Length).
• E2E-Metadaten: dataID (eindeutige Daten-ID zur Maskierung), sourceID, messageType, messageResult.
• Return-Typ: ara::core::Future (Template-Instanz für asynchrone Rückgabewerte / Exceptions).

Schnittstellen & Aufrufe

• Applikationsgrenze: proxyMethod.<method name>(arg1, ..., argN) : ara::core::Future (C++ API-Aufruf auf generiertem Proxy-Objekt).
• Interne ara::com-Subroutinen:
  • Serialize(...)
  • AddE2EProtectedHeader(...)
  • E2E_protect(...)
  • AddNonProtectedHeader(...)
  • store message counter
• Transportschnittstelle: SendMessage(serializedData) (Übergabe an den Platform-Transportstack).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & API-Einsprung: Die Client application stößt den RPC synchron an: Aufruf von proxyMethod.<method name>(arg1, ..., argN). (Hinweis: Der Kommentarblock im Diagramm spricht fälschlich von „skeleton method class“; architektonisch handelt es sich auf Client-Seite zwingend um die generierte Proxy-Klasse).
2. Payload-Serialisierung: ara::com transformiert die Argumente (arg1, ..., argN) in eine flache Byte-Repräsentation (Serialize(...) : serializedData).
3. Erzeugung des geschützten Headers: AddE2EProtectedHeader(serializedData) fügt die invarianten Header-Informationen (Client-ID, Session-ID, Versionen, Message-Typ) ein.
4. E2E-Prüfdatenberechnung: E2E_protect(...) generiert die E2E-Signatur (CRC und Sequence Counter) über dataID, sourceID, messageType, messageResult und serializedData und bettet den E2E-Header ein.
5. Erzeugung des ungeschützten Headers: AddNonProtectedHeader(serializedData) komplettiert das Gesamtpaket um Routing-relevante Attribute (Service ID, Method ID, Gesamtlänge Length).
6. Zustandsaktualisierung: store message counter: Der interne E2E-Zähler wird für die nächste Sequenzzustandsprüfung persistent inkrementiert.
7. Netzwerkübergabe: SendMessage(serializedData) übergibt die finale PDU an die Transmission-Schicht.
8. Rückkehrpfad (asynchron): Transmission bestätigt die Annahme des Puffers an ara::com; ara::com gibt die Kontrolle unmittelbar an die Client application zurück, indem das ara::core::Future-Objekt ausgeliefert wird. Die spätere Antwortübertragung (Response) des Servers erfolgt entkoppelt.

4. Normative Relevanz & Entwickler-Hinweise

• PDU-Assemblierungsreihenfolge (Stack-Entwickler): Die Sequenz erzwingt eine dreigeteilte Paketkonstruktion:
  1. Payload,
  2. E2E-geschützter SOME/IP-Header-Teil,
  3. E2E-Header-Injektion via E2E-Bibliothek,
  4. Ungeschützter SOME/IP-Header-Teil (Bytes 0–7: Service ID, Method ID, Length). Das Length-Feld kann erst nach der E2E-Kapselung berechnet und geschrieben werden, da der E2E-Header die Gesamtnutzlast vergrößert.
• Zustandsverwaltung / Thread-Sicherheit: Der Schritt store message counter erfordert ein thread-sicheres Management des Sequence Counters pro Proxy-Instanz/Methoden-Kanal, um E2E-Zählerüberläufe und Desynchronisation bei parallelen Aufrufen zu verhindern.
• Applikations-API & Asynchronität (Applikations-Entwickler): Der Aufruf blockiert nicht auf die Netzwerkantwort des Servers, sondern lediglich für die Dauer der lokalen Serialisierung, Absicherung und Pufferübergabe. Das erhaltene ara::core::Future kapselt das spätere Methoden-Ergebnis oder aufgetretene Middleware-/E2E-Fehler.
• Spezifikationskorrektur: Die Textannotation „calls the dedicated generated skeleton method class“ im AUTOSAR-Diagramm ist ein redaktioneller Fehler der Spezifikation (Skeleton = Server/Service Provider; Proxy = Client/Service Consumer). Im Implementierungscode gilt verbindlich das Proxy-Muster.