DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_ARAComAPI FIG-339dfa51f77c8c63 876 × 624 px 11 Release(s)

Figure 7.3: Simple Multi-Binding intra AP example

SHA-256 Inhalts-Fingerabdruck: 339dfa51f77c8c6349044fbf4ede629870693be27f38eda3d7411359b07923a6
Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Architekturschaubild / Block- und Deployment-Diagramm für Prozesse und Instanzen mit Interaktions-Annotationen.
  • Kontext & Zweck: AUTOSAR_EXP_ARAComAPI (Adaptive Platform Communication API), Kapitel Multi-Binding.
  • Funktionale Einordnung: Das Diagramm demonstriert die Multi-Binding-Fähigkeit von ara::com innerhalb eines einzelnen POSIX-basierten Steuergeräts (ECU with AP product). Es veranschaulicht, wie ein einzelner Service-Consumer (Client Implementation) über denselben Service-Typ (ServiceType) transparent mit mehreren Service-Instanzen (Instance1, Instance2) kommuniziert, die über grundlegend unterschiedliche Transport-Bindings angebunden sind (Intra-Process vs. Inter-Process IPC), ohne dass sich die Anwendungsschnittstelle ändert.

2. Komponenten, Entitäten & Schnittstellen

  • ECU with AP product: Laufzeitumgebung der AUTOSAR Adaptive Platform auf einem gemeinsamen Host-Betriebssystem (POSIX OS).
  • ara::com App (Links / Dual-Role Process):
    • Client Implementation: Anwendungslogik des Service-Konsumenten.
    • Service Proxy: Typsichere, generierte C++-Client-Klasse (ara::com::Proxy), die Methoden, Events und Fields des Service-Interfaces abstrahiert.
    • Instance1:
      • Service Skeleton: Generierte Provider-Basisklasse (ara::com::Skeleton).
      • Service Implementation: Konkrete Geschäftslogik des Dienstes innerhalb desselben Prozesses.
  • ara::com App (Rechts / Remote Provider Process):
    • Eigenständiger POSIX-Prozess.
    • Instance2: Beherbergt eine zweite Instanz desselben Service-Interfaces (Service Skeleton + Service Implementation).
  • Service Registry / Discovery:
    • Lokaler Stack-Dienst zur Registrierung und Auflösung verfügbarer Service-Instanzen im AP-System.
  • Bindings / Kommunikationspfade:
    • Roter Pfad (Intra-App Binding): In-Process-Kommunikationskanal zwischen Proxy und Skeleton von Instance1. Direkter Methodenaufruf bzw. Zero-Copy-Datenübergabe innerhalb desselben virtuellen Adressraums.
    • Blauer Pfad (Inter-App Binding): Inter-Process-Communication (IPC) zwischen Proxy und Skeleton von Instance2 über Prozessgrenzen hinweg (z. B. via POSIX Shared Memory, UNIX Domain Sockets oder lokales SOME/IP-IPC).

3. Dynamisches Verhalten & Sequenzablauf

  1. Service Offering:
    • Instance1 und Instance2 initialisieren ihre Skeletons und registrieren sich über OfferService() bei der Service Registry / Discovery.
  2. Service Lookup (FindService):
    • Die Client Implementation initiiert die Suche: $FindService(ServiceType, AnyInstance)$ (synchron via FindService() oder asynchron via StartFindService()).
    • Das Suchkriterium AnyInstance adressiert alle am Knoten registrierten Instanzen dieses Service-Typs.
  3. Handle-Generierung & Rückgabe:
    • Die Service Registry / Discovery liefert einen ServiceHandleContainer zurück, der zwei getrennte Handles enthält: Handle1 (für Instance1) und Handle2 (für Instance2).
    • Die Handles kapseln die deployment-spezifischen Adress- und Routing-Informationen (Binding-Typ, Instance-ID, IPC-Kanal/Endpunkt).
  4. Proxy-Instanziierung & Binding-Dispatch:
    • Der Client instanziiert für die Interaktion jeweils ein Proxy-Objekt unter Übergabe des jeweiligen Handles (ServiceProxy(Handle)).
    • Pfad Instance1: Die Binding-Schicht wählt das In-Process-Binding (rot); IPC-Serialisierung und OS-Kontextwechsel entfallen.
    • Pfad Instance2: Die Binding-Schicht wählt das IPC-Binding (blau); Daten werden serialisiert oder über POSIX-Shared-Memory transportiert.

4. Normative Relevanz & Entwickler-Hinweise

  • Orts- und Transporttransparenz:
    • Der Applikationscode der Client Implementation ist vollständig entkoppelt von der Prozess- und Core-Platzierung des Providers. C++-Aufrufe (ara::core::Future, ara::com::SamplePointer, Events) sind syntaktisch und semantisch identisch.
  • Binding-Konfiguration (AUTOSAR Deployment Manifest):
    • Multi-Binding setzt voraus, dass das ServiceInterface in den ARXML-Modellen auf mehrere ProvidedServiceInstance-Konfigurationen gemappt ist. Der ara::com-Code-Generator erzeugt die entsprechenden Dispatch-Mechanismen, um je nach HandleType zur Laufzeit das korrekte Transport-Plugin zu binden.
  • Performance- und Speichereffizienz:
    • Intra-Process (Rot): Entwickler müssen beachten, dass bei In-Process-Kommunikation Pointer/Referenzen direkt übergeben werden können. Deadlocks durch synchrone Re-Entrancy und Thread-Safety müssen applikativ abgesichert werden.
    • Inter-Process (Blau): Es fallen Serialisierungs-, Deserialisierungs- oder Shared-Memory-Allokationskosten an. Große Nutzlasten sollten über typisierte Shared-Memory-Puffer (E2E/Zero-Copy via POSIX Shm) statt via Socket-Payloads ausgetauscht werden.
  • Instanz-Differenzierung:
    • Bei AnyInstance-Suchen muss die Client-Logik implementieren, welcher Handle (Handle1 vs. Handle2) ausgewählt wird (Auswertung der InstanceIdentifier im Handle), da beide dieselbe Schnittstellensignatur bedienen.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

ara::com App | Client Implementation | Service | Proxy | Service Skeleton | Service Implementation | ara::com App | Service Skeleton | Service Implementation | Service Registry/ Discovery | FindService(ServiceType, AnyInstance) returns Handle1, Handle2 | Instance1 Instance2

Vorkommen in AUTOSAR-Releases (16)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-03_R1.4.0 AUTOSAR_EXP_ARAComAPI S. 79 7.3 Figure 7.3: Simple Multi-Binding intra AP example
R18-10_R4.4.0_R1.5.0 AUTOSAR_EXP_ARAComAPI S. 99 8.3 Figure 8.3: Simple Multi-Binding intra AP example
R18-10_R4.4.0_R1.5.0 AUTOSAR_EXP_ARAComAPI S. 99 8.3 Figure 8.3: Simple Multi-Binding intra AP example
R18-10-1 AUTOSAR_EXP_ARAComAPI S. 99 8.3 Figure 8.3: Simple Multi-Binding intra AP example
R19-03 AUTOSAR_EXP_ARAComAPI S. 99 8.3 Figure 8.3: Simple Multi-Binding intra AP example
R19-03 AUTOSAR_EXP_ARAComAPI S. 99 8.3 Figure 8.3: Simple Multi-Binding intra AP example
R19-11 AUTOSAR_EXP_ARAComAPI S. 101 9.3 Figure 9.3: Simple Multi-Binding intra AP example
R20-11 AUTOSAR_EXP_ARAComAPI S. 107 9.3 Figure 9.3: Simple Multi-Binding intra AP example
R20-11 AUTOSAR_EXP_ARAComAPI S. 107 9.3 Figure 9.3: Simple Multi-Binding intra AP example
R21-11 AUTOSAR_EXP_ARAComAPI S. 107 9.3 Figure 9.3: Simple Multi-Binding intra AP example
R21-11 AUTOSAR_EXP_ARAComAPI S. 107 9.3 Figure 9.3: Simple Multi-Binding intra AP example
R22-11 AUTOSAR_EXP_ARAComAPI S. 131 7.3 Figure 7.3: Simple Multi-Binding intra AP example
R23-11 AUTOSAR_AP_EXP_ARAComAPI S. 123 7.3 Figure 7.3: Simple Multi-Binding intra AP example
R23-11 AUTOSAR_AP_EXP_ARAComAPI S. 123 7.3 Figure 7.3: Simple Multi-Binding intra AP example
R24-11 AUTOSAR_AP_EXP_ARAComAPI S. 127 7.3 Figure 7.3: Simple Multi-Binding intra AP example
R25-11 AUTOSAR_AP_EXP_ARAComAPI S. 111 7.3 Figure 7.3: Simple Multi-Binding intra AP example