Figure 5.1: Auto Updating of Proxy Instance

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Zeitdiskretes Phasendiagramm / Zustandssequenz (T0–T4) zur Illustration des dynamischen Lebenszyklusverhaltens einer Service-Verbindung.
• Architektur-Kontext: AUTOSAR Adaptive Platform, Funktionscluster ara::com (Communication Management).
• Funktionaler Zweck: Veranschaulichung des transparenten Wiederverbindungs- und Rekonfigurationsmechanismus (Auto-Updating) einer clientseitigen Proxy-Instanz bei temporärem Ausfall und Wiederverfügbarkeit (OfferService) einer Service-Instanz ohne expliziten Eingriff der Applikationsschicht.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Akteure:
  • ara::com App (Client): Adaptive Application (Process), die als Service-Konsument agiert und die Proxy-Instanz instanziiert hält.
  • Proxy: Generierte typsichere C++-Proxy-Klasse (<ServiceName>Proxy), Schnittstelle der Applikation zur Service-Kommunikation.
  • Service Binding / Endpunkt (Farbcodierung Blau/Orange): Interne Laufzeit-Ressource des Kommunikationsstacks (z. B. SOME/IP-Endpunkt, IPC-Socket/Shared-Memory-Deskriptor), die die logische Assoziation zwischen Proxy und physischer Service-Instanz kapselt.
  • Service Instance (Server/Provider): Bereitstellende Server-Komponente (Skeleton), die den Service im System anbietet.
• Schnittstellen & Interaktionen:
  • Methodenaufruf: callMethod() – synchrone oder zukunftsbasierte (ara::core::Future) Methodeninvokation.
  • Zustandssignalisierung: up (Service angeboten / aktiv) vs. down (Service gestoppt, abgestürzt oder Timeout bei Service Discovery).
  • Auto-Update-Mechanismus: Internes Event des Middleware-Laufzeitsystems zur Aktualisierung der internen Proxy-Deskriptoren auf die neu angekündigte Service-Instanz.

3. Dynamisches Verhalten & Sequenzablauf

• T0 (Nominalbetrieb):
  • Zustand: Service Instance signalisiert up.
  • Aktion: Applikation ruft callMethod() über Proxy auf.
  • Ergebnis: success – Transport über aktive Binding-Struktur (blau).
• T1 (Verbindungsverlust / Provider-Ausfall):
  • Zustand: Service Instance wechselt auf down (z. B. Prozessbeendigung, SOME/IP StopOfferService oder Link-Loss).
  • Proxy behält initial das bestehende (nun veraltete) Binding.
• T2 (Fehlgeschlagener Aufruf im Down-Zustand):
  • Aktion: Applikation setzt callMethod() ab.
  • Ergebnis: failed – Middleware detektiert fehlende Verbindung/Timeout und meldet Fehler (Exception bzw. fehlerhafter ara::core::Result / Future-State) an die Applikation.
• T3 (Auto-Update bei Re-Offer):
  • Trigger: Service Instance startet neu und sendet erneutes Service-Offer (up).
  • Aktion: Der ara::com-Stack führt im Hintergrund ein Auto Update Proxy Instance aus; der Proxy bindet transparent an den neuen Service-Endpunkt (orangefarbenes Binding).
• T4 (Re-Synchronisation & Wiederherstellung):
  • Zustand: Service ist up, Proxy intern rekonfiguriert.
  • Aktion: Erneuter Aufruf von callMethod() durch die Applikation.
  • Ergebnis: success – Aufruf wird ohne erneutes manuelles FindService oder Re-Instanziieren des Proxys über das neue Binding erfolgreich abgewickelt.

4. Normative Relevanz & Entwickler-Hinweise

• Applikationsdesign & Fehlerbehandlung:
  • Fehlgeschlagene Aufrufe (callMethod : failed in T2) müssen defensiv über Fehlercodes/Exceptions abgefangen werden; ein Fehlschlag bedeutet nicht zwangsläufig die Notwendigkeit, das Proxy-Objekt zu terminieren.
  • Vermeidung redundanter Re-Discovery-Logik: Die Applikation muss bei temporären Service-Ausfällen den Proxy nicht zwingend zerstören und neu über FindService anlegen, da die Middleware das Re-Binding intern auflösen kann.
• Zustandsbehaftung (Stateful Services):
  • Das automatische Update erneuert ausschließlich die Kommunikationsstrecke. Serverseitige Session-, Authentifizierungs- oder Konfigurationszustände gehen bei einem Neustart der Service-Instanz verloren und müssen von der Applikation nach T3 reinitialisiert werden.
• Einschränkung der Relevanz & Standard-Evolution:
  • Das dargestellte Auto-Update-Feature war spezifisch in frühen Adaptive-Releases (R17-03 bis R18-03) als Erklärungsmodell verankert. In späteren Releases (ab R18-10 / R19-11) wurde das explizite Find-Service- und Lifecycle-Management über HandleType und Subscription-Status-Handling verbindlicher geschärft, um Race Conditions und unkontrollierte Service-Rebinds in deterministischen sicherheitskritischen Umgebungen (ASIL) zu unterbinden.