Figure 7.12: Skeleton creation using abstract network bindings

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Technisches Architektur- und Mapping-Schema mit C++-Codesequenzen und zugehörigen Manifest-Projektionen (Design-to-Deployment-Mapping).
• Architektur-Kontext: AUTOSAR Adaptive Platform, Service-Oriented Architecture (SOA), Subsystem ara::com (Communication Management).
• Funktionaler Zweck: Veranschaulichung der protocol-agnostic Skeleton-Instanziierung. Das Schema demonstriert, wie die C++-Applikationslogik über ara::core::InstanceSpecifier vollständig von konkreten Netzwerk- und Transport-Bindings (SOME/IP, lokales IPC) entkoppelt wird und wie ein unveränderter Applikations-Quellcode sowohl für Single-Binding- als auch für Multi-Binding-Szenarien eingesetzt wird.

2. Komponenten, Entitäten & Schnittstellen

• Applikations-Entitäten (C++ Component Code):
  • ara::core::InstanceSpecifier: Stark typisierter Identifikator, der die logische Instanz eines PortPrototype (konkret PPortPrototype) aus dem AUTOSAR-Software-Modell kapselt (context + "MyPort" → modellierter Pfad "/x/y/z/MyPort").
  • RadarService serviceImpl(portName): Konkrete Service-Implementierungsklasse, abgeleitet vom generierten Skeleton-Interface (RadarServiceSkeleton). Der Konstruktor akzeptiert den InstanceSpecifier als Referenzanker.
• Konfigurations-Entitäten (Deployment / Execution Manifest):
  • Single Binding: 1:1-Zuordnung des InstanceSpecifier zu genau einer Service-Instanzkonfiguration (z. B. Protokoll SOME/IP mit Service-Instance-ID 43).
  • Multiple Binding: 1:n-Zuordnung des identischen InstanceSpecifier auf mehrere heterogene oder redundante Bindings parallel:
    • SOME/IP:43 (externes Netzwerk, z. B. Gateway/Head-Unit)
    • SOME/IP:16 (parallele / alternative SOME/IP-Instanz)
    • UserDefined:/tmp/33 (ECU-internes IPC / UNIX Domain Socket / Shared Memory Endpoint)
• Stereotypen & Kardinalitäten:
  • Der PPortPrototype (InstanceSpecifier) referenziert deklarativ 1 … n ProvidedServiceInstance-Deployments (SOME/IP, IPC, proprietäre Bindings).
  • Quellcode-Kardinalität: Exakt eine Skeleton-C++-Instanz bedient alle zugewiesenen Transport-Bindings simultan.

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung des Bezeichners: Erzeugung des ara::core::InstanceSpecifier zur Laufzeit unter Verwendung des vollqualifizierten Port-Pfades ("x/y/z/MyPort").
2. Skeleton-Konstruktion: Übergabe des portName an den Konstruktor der Service-Implementierung (RadarService serviceImpl(portName)).
3. Manifest-Lookup & Binding-Auflösung: Die zugrundeliegende ara::com-Laufzeitumgebung liest zur Konstruktionszeit die Deployment-Deskriptoren des Service-Instance-Manifests für den angegebenen InstanceSpecifier aus.
4. Transport-Endpoint-Initialisierung:
   • Single-Binding-Pfad: Initialisierung des SOME/IP-Serializers und Registrierung des Sockets auf Instance-ID 43.
   • Multi-Binding-Pfad: Parallele Initialisierung aller konfigurierten Binding-Adapter (SOME/IP:43, SOME/IP:16 und lokales IPC /tmp/33).
5. Dienst-Bereitstellung: Nach der Konstruktion (und dem Aufruf von OfferService()) nimmt der Skeleton Methodenaufrufe, Feldabfragen und Event-Subscriptions synchron oder asynchron über sämtliche gebundenen Kanäle entgegen.

4. Normative Relevanz & Entwickler-Hinweise

• Code-Portabilität & Binding-Agnozismus: Applikations-Entwickler dürfen keinerlei Netzwerk-Parameter (IP-Adressen, SOME/IP-IDs, Socket-Pfade) im C++-Code verankern. Die Bindung erfolgt ausschließlich deklarativ im Manifest.
• Zero-Code-Change bei Multi-Binding: Der Wechsel von Single-Binding (z. B. reines SOME/IP über Ethernet) zu Multi-Binding (z. B. simultan SOME/IP und POSIX-IPC für Hochgeschwindigkeitsdaten) erfordert keine Re-Kompilierung oder Anpassung des C++-Quellcodes, sondern rein die Anpassung des Deployment-Manifests.
• Laufzeit-Fehlerbehandlung: Schlägt das Mapping des InstanceSpecifier fehl (z. B. Port im Manifest nicht konfiguriert oder Endpunkt blockiert), bricht der Konstruktor ab (je nach Plattformversion via ara::core::Result / Exception oder führt zu einem fatalen Initialisierungsfehler).
• Thread-Safety & Nebenläufigkeit: Bei Multi-Binding können Methodenaufrufe simultan aus verschiedenen Binding-Stacks (z. B. gleichzeitig über SOME/IP und IPC) im selben Skeleton-Objekt eintreffen. Die Implementierung der Service-Methoden muss zwingend reentrant bzw. thread-safe ausgelegt sein.