Figure 7.9: InstanceIds in Deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Architektur- und Deployment-Mapping-Diagramm (Gegenüberstellung von SW-Design-/Implementierungsebene und OS-/Deployment-Ebene).
• Technischer Zweck: Veranschaulichung der Bindungs- und Adressierungsambiguität bei Mehrfachinstanziierung von Software-Komponenten (SWCs) innerhalb eines Executables auf der AUTOSAR Adaptive Platform (AP, Release R18-03 / v1.4.0, AUTOSAR_EXP_ARAComAPI).
• Funktionale Einordnung: Dient als Rationale für die Trennung zwischen quellcode-lokaler Identifikation (InstanceIdentifier) und modellbasiertem Deployment-Mapping via Port-Hierarchie (InstanceSpecifier) innerhalb des Process-specific Service Instance Manifest.

2. Komponenten, Entitäten & Schnittstellen

• Implementierungsebene (Implementation level):
  • Executable 2: Statische Binäreinheit (ELF-Executable), die den kompilierten Applikationscode kapselt.
  • Component B: Atomarer Software-Komponententyp, der innerhalb des Executables dreifach instanziiert ist:
    • B_Inst_1: Erste Top-Level-Instanz von B.
    • B_Inst_2: Zweite Top-Level-Instanz von B.
  • Composite Component (Comp_Inst_1): Zusammengesetzte Software-Komponente, fungiert als hierarchischer Instanz-Container:
    • Component A: Erste Subkomponente.
    • B_Inst_1: Dritte Instanz von B (hierarchisch gekapselt unter Comp_Inst_1/B_Inst_1).
  • InstanceId: Radar: Im Quellcode der Komponente B hartkodierter oder lokaler logischer Bezeichner (ara::com::InstanceIdentifier("Radar")). Alle drei Instanzen von B nutzen denselben unqualifizierten String.
• Deployment-Ebene (Deployment level):
  • Process 2: OS-Laufzeitinstanz (POSIX-Prozess), die durch Instanziierung von Executable 2 auf der Ziel-Maschine entsteht (1:1-Beziehung Executable 2 → Process 2).
  • Process specific Service Instance Manifest: Maschinen-/Prozess-spezifische ARXML-Konfiguration, die Service-Instanzen auf konkrete Kommunikations-Bindings abbildet:
    • Radar -> SOME/IP InstanceId 1: Zuweisung an SOME/IP-Netzwerk-Binding (Off-Board / Inter-ECU Kommunikation mit Service-Instance-ID 1).
    • Radar -> UnixDomainSocket /tmp/Radar/3: Zuweisung an IPC-Binding (Intra-Machine via POSIX Unix Domain Socket).
    • Radar -> UnixDomainSocket /tmp/Radar/4: Zuweisung an separaten lokalen IPC-Kanal.
• Beziehungen und Mapping-Konflikt:
  • Die roten Pfeile markieren die vom System-Integrator beabsichtigte 1:1-Zuordnung jeder Komponenteninstanz zu einem dedizierten Kommunikations-Endpunkt.
  • Da die Zuordnung im Manifest jedoch flach über den Schlüssel Radar erfolgt, entsteht eine 1:n-Ambiguität: Das Deployment-Manifest kann anhand des unqualifizierten Namens "Radar" zur Laufzeit nicht unterscheiden, welche der drei B-Instanzen an SOME/IP und welche an die jeweiligen IPC-Sockets gebunden werden soll.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessinitialisierung: Das Betriebssystem bzw. der Execution Management (EM) Stack startet Process 2. Die ara::com-Laufzeitumgebung initialisiert den Binding-Dispatcher und parst das prozessspezifische Service-Instance-Manifest.
2. Service Discovery / Instanziierung:
   • Die drei Instanzen von B (B_Inst_1, B_Inst_2, Comp_Inst_1/B_Inst_1) rufen parallel oder sequenziell Service-APIs auf (z. B. Konstruktion von RadarProxy / RadarSkeleton oder StartFindService / OfferService) und übergeben den logischen Bezeichner "Radar".
3. Auflösungs-Konflikt (Resolution Failure):
   • Die Binding-Engine versucht, "Radar" gegen das Manifest aufzulösen.
   • Mangels Pfadqualifikation kommt es zur Fehlzuordnung (nicht-deterministische Bindung der Socket-Pfade und des SOME/IP-Endpunkts) oder zum Scheitern der Initialisierung, da drei widersprüchliche Ziel-Bindings für denselben Bezeichner innerhalb desselben Prozesses registriert sind.

4. Normative Relevanz & Entwickler-Hinweise

• Ablösung von InstanceIdentifier durch InstanceSpecifier:
  • Der Standard löst die im Schaubild dargestellte Ambiguität normativ dadurch, dass in C++-Konstruktoren von Proxies und Skeletons ara::core::InstanceSpecifier anstelle reiner InstanceIdentifier verwendet werden.
  • Ein InstanceSpecifier kapselt den vollqualifizierten Meta-Modellpfad des jeweiligen Ports (z. B. Executable2/Comp_Inst_1/B_Inst_1/RPort_Radar).
• Konfigurationsanforderungen (Manifest & ARXML):
  • Entwickler und Integratoren müssen im ARXML-Deployment ein eindeutiges ServiceInstanceToPortPrototypeMapping definieren.
  • Die Bindung an Transport-Protokolle (SOME/IP vs. IPC) erfolgt port-spezifisch über ProvidedServiceInstance bzw. RequiredServiceInstance und nicht über generische String-Schlüssel.
• Applikations- und Stack-Implementierung:
  • Komponenten dürfen Kommunikationsinstanzen nicht hart auf lokale String-Literale kodieren, wenn eine Wiederverwendbarkeit im Kontext von Composite Components oder Multi-Instanziierung gefordert ist.
  • Werden Unix Domain Sockets für Intra-Node-IPC genutzt, müssen die Socket-Pfade im Manifest (z. B. /tmp/Radar/3) vom Build-/Generierungswerkzeug kollisionsfrei und mit entsprechenden POSIX-Dateirechten pro Prozess instanziiert werden.