Figure 7.7: Multiple Instantiation in Implementation Contexts

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Metamodell-basiertes Architektur- und Deployment-Strukturdiagramm (Instanziierungs- und Komponenten-Mapping-Modell).
• Technischer Zweck: Das Diagramm illustriert das Problem und die Modellierung der Mehrfachinstanziierung (Multiple Instantiation) von Softwarekomponenten-Typen (SoftwareComponentType) und deren Dienstschnittstellen (ara::com Service Proxies und Skeletons) über Prozess- und Ausführungsgrenzen hinweg.
• Architektur-Einordnung: In der AUTOSAR Adaptive Platform (Release R18-03 / 1.4.0) werden Komponenten als C++-Klassen implementiert und in POSIX-Prozessen (Executable) deployt. Das Schaubild visualisiert die Divergenz zwischen Entwurfs-/Implementierungsartefakten (statische Typ-Ebene) und den konkreten Laufzeit-Instanzen auf Executable- und Composite-Ebene sowie die Herausforderung der eindeutigen Bindung über Instanz-Identifikatoren (InstanceIdentifier vs. InstanceSpecifier).

2. Komponenten, Entitäten & Schnittstellen

• Entwurfsebene (Klassentyp- / Implementierungs-Kontext, oben):
  • Implementation of SoftwareComponentType A: Repräsentiert die statische Implementierung des Dienst-Konsumenten (Client).
    • RadarService Proxy instance: ara::com-Client-Endpunkt (ProxyClass), zuständig für Konsumierung von Events, Fields und Methodenaufrufen des Radar-Dienstes.
    • InstanceId: radarservice: Konfigurierter bzw. logisch assoziierter Instanzbezeichner für den konsumierten Dienst.
  • Implementation of SoftwareComponentType B: Repräsentiert die statische Implementierung des Dienst-Anbieters (Server).
    • RadarService Skeleton instance: ara::com-Server-Endpunkt (SkeletonClass), zuständig für das Bereitstellen der Service-Methoden, Field-Getter/Setter und Event-Emissionen.
    • InstanceId: Radar: Konfigurierter bzw. assoziierter Instanzbezeichner des angebotenen Dienstes.
• Laufzeitebene (Deployment- / Prozess-Kontext, unten):
  • Executable 1 (Eigenständiger OS-Prozess / Adressraum):
    • Beherbergt zwei separate Laufzeitinstanzen von Typ A (A, A).
    • Beherbergt eine Laufzeitinstanz von Typ B (B).
  • Executable 2 (Zweiter eigenständiger OS-Prozess / Adressraum):
    • Beherbergt eine Laufzeitinstanz von Typ B (B) auf oberster Ebene.
    • Beherbergt eine Composite Component (hierarchische Kapselung), welche wiederum:
      • eine Laufzeitinstanz von Typ A (A) und
      • eine Laufzeitinstanz von Typ B (B) enthält.
• Beziehungen & Multiplizitäten:
  • Instance of (N:1-Beziehung): Insgesamt 3 Instanzen von Komponente A (2 in Executable 1, 1 in Executable 2/Composite) referenzieren dieselbe Implementierung von Typ A.
  • Instance of (N:1-Beziehung): Insgesamt 3 Instanzen von Komponente B (1 in Executable 1, 1 in Executable 2, 1 in Executable 2/Composite) referenzieren dieselbe Implementierung von Typ B.
  • Composite Component (Aggregation/Komposition): Strukturiert Subkomponenten logisch innerhalb des Adressraums von Executable 2.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm selbst ist statisch-strukturell, induziert jedoch folgende deterministische Laufzeitabläufe bei der Dienstbindung:

1. Skeleton-Initialisierung & Service Offer (OfferService):
   • Jede B-Instanz erzeugt zur Laufzeit eine eigene C++-Instanz der generierten Skeleton-Klasse.
   • OfferService() publiziert das Service-Angebot über den Kommunikations-Stack (SOME/IP-Daemon oder prozessinternes IPC-Binding).
   • Problemstellung bei Mehrfachinstanz: Würden alle drei B-Instanzen denselben statischen Bezeichner InstanceId: Radar registrieren, entstünde ein Konflikt im Service Discovery (Kollision identischer Service-Instanz-IDs im selben Netzwerk/Host).
2. Proxy-Auflösung & Service Discovery (FindService):
   • Jede A-Instanz initiiert ein FindService() nach dem RadarService.
   • Bei intra-prozessualer Ausführung (Executable 1 enthält sowohl A als auch B) optimiert die ara::com-Laufzeitumgebung Methodenaufrufe und Events typischerweise auf direkte Pointer- bzw. Shared-Memory-/Zero-Copy-Mechanismen.
   • Zwischen A in Executable 1 und B in Executable 2 (oder Inter-ECU) greift das IPC-/Netzwerk-Binding (SOME/IP-Routing).

4. Normative Relevanz & Entwickler-Hinweise

• Notwendigkeit von InstanceSpecifier (Port-to-Service-Instance Mapping):
  • Entwickler dürfen InstanceIdentifier (Strings/IDs wie "Radar") niemals hardcodiert im Quellcode der Komponenten-Klassen übergeben.
  • Der C++-Konstruktor von Proxies und Skeletons muss mit einem ara::core::InstanceSpecifier parametrisiert werden (z. B. InstanceSpecifier{"Executable1/RootSwc/RPort_Radar"}). Erst über das Execution Manifest und Service Instance Manifest erfolgt die Bindung des konkreten Modell-Ports auf die tatsächliche InstanceIdentifier (z. B. SOME/IP service_instance_id).
• Zustandslosigkeit & Reentrancy der Komponenten-Implementierung:
  • Da derselbe SoftwareComponentType A mehrfach innerhalb desselben Prozesses (Executable 1) instanziiert wird, dürfen in der Implementierung keine globalen oder statischen Variablen (static) für instanzspezifische Daten (z. B. Event-Puffer, Handler, Konfigurationswerte) verwendet werden.
  • Jede Instanz muss ihren eigenen Zustand strikt über Member-Attribute kapseln.
• Callback- & Event-Handling (SetReceiveHandler):
  • Bei mehrfacher Proxy-Instanziierung im selben Prozess müssen Callback-Registrierungen thread-sicher und isoliert je Instanz registriert werden; Event-Queues müssen pro Proxy-Instanz dimensioniert sein.
• Hierarchieauflösung bei Composite Component:
  • Auf POSIX-OS-Ebene existiert kein nativer "Composite-Container": Die Sub-Instanzen A und B in der Composite Component teilen sich denselben OS-Thread-Pool, Scheduling-Kontext und Adressraum wie die umgebende Executable 2. Die Composite-Struktur dient rein dem Modellierungsentwurf (ARXML) und wird beim Build/Deployment auf flache C++-Instanzen abgebildet.