Figure 9.27: Interfaces for freshness value management

1. Diagrammtyp & Architektur-Kontext

UML-Komponenten- und Klassendiagramm im Kontext der AUTOSAR Adaptive Platform (AUTOSAR_EXP_SWArchitecture, Figure 9.25). Es dokumentiert die statische Architekturbeziehung zwischen dem Functional Cluster Communication Management und der Schnittstelle für das Freshness Value Management (FVM) zur Absicherung der bordnetzweiten Kommunikation (z. B. SecOC).

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Communication Management: Functional Cluster der Adaptive Platform in daemon-basierter Ausprägung (daemon-based), dargestellt als UML-Komponente mit Komponenten-Icon.
• «aapNativeInterface, aapPlatformExtension» FVM: C++-basierte native Schnittstelle und Plattform-Erweiterung mit drei öffentlichen Operationen:
  • + GetRxFreshness(): Ermittlung des Freshness-Werts für den Empfangspfad zur Verifikation empfangener Nachrichten.
  • + GetTxFreshness(): Abfrage des aktuellen Freshness-Werts für den Sendepfad zur Authentisierung ausgehender PDUs.
  • + Initialize(): Initialisierung des internen Zustands des Freshness Value Managements.
• Beziehung: Gerichtete Verwendungsabhängigkeit («use», gestrichelte Pfeillinie) ausgehend von Communication Management zur Schnittstelle FVM.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierung: Beim Start des Communication-Management-Daemons wird Initialize() aufgerufen, um Zähler, Synchronisationszustände und Schlüssel-/Epochenstrukturen des FVM aufzusetzen.
• Sendepfad: Vor dem Übertragen einer gesicherten PDU fordert der Daemon über GetTxFreshness() den aktuellen Sende-Freshness-Wert an, um diesen in den Authentifizierungs-Tag (z. B. MAC-Berechnung) einzubringen und ggf. anteilig in der Nachricht zu übertragen.
• Empfangspfad: Bei Empfang einer gesicherten PDU ruft der Daemon GetRxFreshness() auf, um anhand der übermittelten Teilinformationen den vollständigen Freshness-Wert für die Verifikation der Nachricht und die Abwehr von Replay-Angriffen zu rekonstruieren.

4. Normative Relevanz & Entwickler-Hinweise

• «aapPlatformExtension»: Kennzeichnet die FVM-Schnittstelle als Plattform-Erweiterung außerhalb des Kerns anwendungsspezifischer ARA-Schnittstellen; die Implementierung erfolgt plattformspezifisch bzw. OEM-spezifisch.
• «aapNativeInterface»: Definiert die Schnittstelle als native C++-API (Direct Call / Library Linkage) innerhalb des Prozesses ohne Overhead durch Service-Proxies oder IPC-Serialisierung.
• daemon-based: Communication Management läuft als POSIX-Hintergrunddienst (Daemon); der Zugriff auf FVM erfolgt aus dem Kontext dieses zentralen Kommunikationsprozesses.