Figure 7.13: Multiple usage of the same service instance manifest for an abstract binding

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Architektur- und Deployment-Diagramm (Szenarien-Gegenüberstellung: Valid vs. Invalid Deployment Pattern).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Kommunikationsmanagement (ara::com).
• Technischer Zweck: Das Diagramm spezifiziert die semantischen Restriktionen bei der Mehrfachverwendung eines identischen Service Instance Manifests (InstanceSpecifier-zu-Binding-Mapping, hier am Beispiel SOME/IP) für Proxy- vs. Skeleton-Instanzen in OS-Prozessen.

2. Komponenten, Entitäten & Schnittstellen

• Manifest (ServiceInstanceDeployment):
  • Definiert das Mapping eines abstrakten Service-Ports („x/y/z/MyPort“, PortPrototype/InstanceSpecifier) auf konkrete Netzwerk- und Protokollparameter (SOME/IP:43, Instanz-ID 43).
• Proxy-Instanzen (P):
  • Client-seitige Dienst-Konsumenten (ara::com::Proxy), instanziiert in unabhängigen Betriebssystem-Prozessen (Process X).
• Skeleton-Instanzen (S):
  • Server-seitige Dienst-Provider (ara::com::Skeleton), instanziiert in Betriebssystem-Prozessen (Process Y).
• Beziehungen & Kardinalitäten:
  • **Szenario 1 (Proxies, OK):** N:1-Beziehung. Beliebig viele Proxy-Instanzen (N ≥ 1) dürfen dasselbe RequiredServiceInstance-Manifest referenzieren und auf dieselbe Skeleton-Instanz binden.
  • **Szenario 2 (Skeletons, Not OK):** 1:1-Restriktion. Ein ProvidedServiceInstance-Manifest mit identischer Dienstinstanz-ID (SOME/IP:43) darf nicht von mehr als einer Skeleton-Instanz verwendet werden.

3. Dynamisches Verhalten & Sequenzablauf

• Szenario 1 – Proxy-Multi-Instanziierung (Gültiger Pfad):
  1. Skeleton S in Process Y registriert sich und bietet den Dienst via OfferService() an (SOME/IP-SD Offer mit Instance-ID 43).
  2. Unabhängige Proxies P in Process X initiieren FindService() / StartFindService() über das identische Manifest.
  3. Beide Proxies lösen „x/y/z/MyPort“ deterministisch auf SOME/IP:43 auf und etablieren getrennte Kommunikationskanäle (Events, Methods, Fields) zum selben Skeleton.
• Szenario 2 – Skeleton-Kollision (Ungültiger Pfad):
  1. Mehrere Skeleton-Instanzen S versuchen, parallel OfferService() unter derselben Manifest-Konfiguration (SOME/IP:43) aufzurufen.
  2. Konflikt: In der SOME/IP-Service-Discovery kommt es zur Ambiguität. Der Kommunikations-Daemon bzw. das Netzwerk kann eingehende Client-Requests keinem eindeutigen Endpunkt/Prozess zuordnen.
  3. Abbruchbedingung: Verletzung der Eindeutigkeitsregel gemäß SWS_CM_10450. Der Aufruf von OfferService() schlägt fehl bzw. wird vom ara::com-Stack abgewiesen.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Vorgabe ([SWS_CM_10450]): Jedes Skeleton erfordert einen eindeutigen Instanznamen (InstanceSpecifier) bzw. eine eindeutige Dienstinstanz-Identifikation innerhalb der Kommunikationsdomäne.
• ARXML-Konfiguration & Deployment:
  • Consumer-Seite: Ein RequiredServiceInstance Deployment darf von mehreren Software-Komponenten/Prozessen wiederverwendet werden.
  • Provider-Seite: Für jede reale Skeleton-Instanz muss ein eigenes ProvidedServiceInstance Deployment mit distinkter serviceInstanceId (z. B. SOME/IP:43, SOME/IP:44) und eindeutigem PortPrototype-Pfad projektiert werden.
• Applikations-Entwicklung (ara::com):
  • Die Mehrfach-Instanziierung derselben Skeleton-Klasse mit identischem InstanceSpecifier führt zu Laufzeitfehlern bei der Dienstbereitstellung (ara::com::ComErrorDomain).
  • Statische Validierungswerkzeuge (ARXML Model Checker) müssen die Doppelbelegung identischer Service-Instance-Manifeste auf Skeleton-Ebene bereits zur Generierungszeit als fatalen Modellierungsfehler abweisen.