Figure 6.2: Service Instance to Port Prototype Mapping

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / formaler Metamodell-Ausschnitt des AUTOSAR Adaptive Platform M2-Metamodells (Package- und Instanz-Mapping).
• Technischer Zweck: Definition der strukturellen Bindung zwischen der softwarearchitektonischen Entwurfsebene (Port-Ebene der Adaptive Application) und der konkreten Middleware-/Netzwerk-Konfiguration (ara::com-Deployment). Es bildet die Brücke zwischen der logischen Schnittstellen-Spezifikation (PortPrototype, ProcessDesign) und den prozessualen bzw. netzwerktechnischen Kommunikationsendpunkten (Process, AdaptivePlatformServiceInstance, ServiceInterfaceDeployment).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Klassenhierarchie

• ServiceInstanceToPortPrototypeMapping (Spezialisierung von UploadableDesignElement):
  • Zentrales Mapping-Element. Verbindet einen spezifischen Service-Port eines Prozesses mit einer konkreten Service-Instanz.
• PortPrototype (Stereotypen: «AtpBlueprintable», «AtpPrototype»):
  • Repräsentiert den logischen Software-Port (P-Port oder R-Port) an einer Adaptive Application.
  • Referenziert via +portPrototype [0..1] mit Stereotyp «instanceRef, atpUriDef» (kontextualisierter Pfad durch die Instanzhierarchie der Softwarekomponente).
• ProcessDesign (Spezialisierung von ARElement):
  • Modelliert den Entwurf eines Prozesses auf VFB-/Software-Architektur-Ebene vor der konkreten Deployment-Allokation.
  • Referenziert via +processDesign [0..1] mit Stereotyp «atpUriDef».
• Process (Spezialisierung von AbstractExecutionContext):
  • Konkrete Instanz eines Executables, das auf einer Machine ausgeführt wird.
  • Referenziert via +process [0..1] mit Stereotyp «atpSplitable».
  • Attribute:
    • + functionClusterAffiliation: String [0..1]: Zuordnung zu einem AUTOSAR Functional Cluster.
    • + numberOfRestartAttempts: PositiveInteger [0..1]: Maximal zulässige Neustartversuche durch den Execution Manager.
    • + preMapping: Boolean [0..1]: Flag zur Kennzeichnung von Vormappings vor der finalen Prozess-Bindung.
  • Beziehung zu ProcessDesign: Assoziation +design [0..1] (bindet den Laufzeitprozess an sein Architekturentwurfselement).
• AdaptivePlatformServiceInstance (Spezialisierung von UploadableDesignElement):
  • Konkrete Instanziierung eines Dienstes (Provided oder Required Service Instance) im Adaptive-System.
  • Referenziert via +serviceInstance [0..1].
• ServiceInterfaceDeployment (Spezialisierung von UploadableDesignElement):
  • Protokoll- und middleware-spezifische Konfiguration (z. B. SOME/IP, IPC, DDS) des Service Interface.
  • Referenziert via +serviceInterfaceDeployment [0..1] ausgehend von AdaptivePlatformServiceInstance.

Metamodell-Stereotypen & Modellierungssemantik

• «atpSplitable»: Das Mapping und die zugehörigen ARXML-Fragmente dürfen auf mehrere Teilbäume/Dateien verteilt vorliegen und werden durch den Tooling-Merger zusammengeführt.
• «atpUriDef»: Das Ziel-Element ist über einen eindeutigen Metamodell-URI referenzierbar.
• «instanceRef»: Kontextualisierte Instanzreferenz; erlaubt die präzise Auflösung des Ports innerhalb einer tief verschachtelten Komponenten- und Subkomponenten-Struktur.
• UploadableDesignElement: Markiert Entwurfs- und Konfigurationsartefakte, die modular paketiert und im Rahmen von Software-Packages über Update and Configuration Management (UCM) aktualisiert werden können.

3. Dynamisches Verhalten & Sequenzablauf

Als rein deklarativer Metamodell-Ausschnitt existiert kein dynamischer Kontrollfluss im Diagramm. Das Metamodell steuert jedoch die Phasen der Systemintegration und Runtime-Initialisierung:

1. Generierungs-/Build-Zeit:
   • Der ara::com-Code-Generator konsumiert das ServiceInstanceToPortPrototypeMapping.
   • Aus dem PortPrototype und dem AdaptivePlatformServiceInstance-Mapping wird die Zuordnung von ara::core::InstanceSpecifier zur eindeutigen Transport-Instanz-ID (z. B. SOME/IP Service ID / Instance ID) generiert und in das Execution/Service Instance Manifest serialisiert.
2. Initialisierungsphase (ara::com Runtime):
   • Beim Start des Process instanziiert die Applikation ein Proxy- oder Skeleton-Objekt unter Angabe des InstanceSpecifier.
   • Der ara::com-Binding-Layer liest das Manifest aus, schlägt die gemappte AdaptivePlatformServiceInstance nach und ermittelt über ServiceInterfaceDeployment die Netzwerkparameter (Port-Nummern, Event-IDs, Method-IDs, Multicast-Gruppen).
3. Service Discovery & Kommunikation:
   • Skeleton: OfferService() publiziert die konfigurierte Service-Instanz über das spezifizierte Transportprotokoll (z. B. SOME/IP-SD).
   • Proxy: FindService() / StartFindService() sucht exakt nach derjenigen Instanz-ID, die über dieses Mapping an den R-Port gebunden wurde.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung Applikation vs. Deployment: C++-Entwickler referenzieren im Quellcode ausschließlich den abstrakten ara::core::InstanceSpecifier (abgeleitet vom PortPrototype). Es dürfen keine hardcodierten Transport-IDs (SOME/IP Service-IDs, IPC-Channels) im Quellcode verwendet werden.
• Konfigurationsvarianten (Design vs. Deployment):
  • Entwurfsebene: Verlinkung über +processDesign ermöglicht frühe Schnittstellenvalidierung und Typbindung, bevor die konkrete Machine/Prozess-Zuweisung feststeht.
  • Systemintegrations-Ebene: Verlinkung über +process komplettiert die Ausführungs- und Kommunikationskonfiguration im Execution Manifest. Ist preMapping: true, erfolgt eine Vorab-Allokation.
• Deployment-Bindung:
  • Jede Service-Instanz benötigt zwingend ein passendes ServiceInterfaceDeployment (z. B. SomeipServiceInterfaceDeployment), um Kommunikationsparameter (Serialisierung, E2E-Schutz, Übertragungsmodi wie Event-getriggert oder zyklisch) festzulegen. Fehlt dieses Deployment, kann der Kommunikations-Stack den Port nicht aktivieren.
• Multi-Process / Multi-Instance Semantik:
  • Da Kardinalitäten [0..1] vorliegen, kann ein PortPrototype innerhalb eines Prozesskontexts genau einer Service-Instanz zugewiesen werden. Sollen mehrere Instanzen desselben Interface an verschiedenen Ports bedient werden, sind separate ServiceInstanceToPortPrototypeMapping-Elemente mit eindeutigen PortPrototypes erforderlich.