Figure 7.8: Instantiation of Adaptive Applications in Deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Struktur- und Metamodell-Mapping-Diagramm (Abstraktion der AUTOSAR Adaptive Platform Methodik).
• Technischer Zweck: Visualisierung der Entkopplung zwischen der Code-/Kompilierebene (Implementation level) und der Laufzeit-/Betriebssystemebene (Deployment level). Es demonstriert die Kardinalitäten bei der Verpackung von Software-Komponenten in Binärdateien (Executable) sowie deren anschließende Instanziierung als eigenständige POSIX-Adressräume (Process) unter Berücksichtigung von ara::com.

2. Komponenten, Entitäten & Schnittstellen

• Implementation Level (Artefakt- & Typebene):
  • Software Component (A, B): Atomare Softwarekomponenten (AdaptiveApplicationSwComponentType), definiert durch Port-Schnittstellen (Provided/Required Ports).
  • Composite Component: Hierarchisches Aggregat zur logischen Gruppierung mehrerer Sub-Komponenten (hier Komponente A und B in Executable 2).
  • Executable (Executable1, Executable 2): Kompiliertes und gelinktes Binärartefakt (ELF-Binary). Ein Executable kann mehrere Komponenten-Instanzen desselben Typs enthalten (z. B. Executable1 mit zweimal Typ A und einmal Typ B).
• Deployment Level (Laufzeitebene):
  • Process (Process 1, Process 2, Process 3): Laufzeitinstanz eines Executables im OS (eigener virtueller Adressraum, Zugriffsrechte, Scheduling-Konfiguration).
• Beziehungen & Kardinalitäten:
  • Component → Executable (n:1): Mehrere Komponenten und Sub-Komponenten werden zu einem gemeinsamen Executable zusammengebunden. Identische Komponententypen können im selben Executable mehrfach instanziiert werden (1:n).
  • Executable → Process (1:n): Ein Executable kann mehrfach als separater Process instanziiert werden (Executable1 wird durch Process 1 und Process 2 instanziiert).
  • Process → Executable (n:1): Jeder Process referenziert exakt ein Executable (ProcessToMachineMapping via Execution Manifest).

3. Dynamisches Verhalten & Sequenzablauf

• Laufzeit-Instanziierung: Das Execution Management (EM) instanziiert und überwacht Process 1, Process 2 und Process 3 unabhängig voneinander anhand des State Managements (Function Groups / States).
• Kommunikationspfade via ara::com:
  • Intra-Process: Kommunikation zwischen Komponenten innerhalb desselben Prozesses (z. B. A und B in Process 1) erfolgt speicherlokal; bindingspezifisch sind Optimierungen (Zero-Copy, Pointer-Passing) ohne Netzwerkserialisierung möglich.
  • Inter-Process Communication (IPC): Kommunikation zwischen Process 1 und Process 2 (obwohl identisches Executable1) oder zu Process 3 überschreitet Prozess- und Speichergrenzen. Sie erzwingt den Durchlauf des ara::com-IPC-Bindings (z. B. via Shared Memory Queues, Unix Domain Sockets oder SOME/IP-Node-Local) inklusive Marshalling/Demarshalling.
• Dienstauflösung: Zur Laufzeit wird die Kommunikation über ara::core::InstanceSpecifier aufgelöst, die pro Process im Deployment-Manifest auf konkrete Service-Instanz-IDs gemappt sind.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • Die Mehrfachinstanziierung eines Executables (Process 1 & Process 2) erfordert getrennte Execution Manifests (Definition von UID/GID, Resource Groups, Startup-Parametern) und getrennte Service Instance Deployment Manifests.
  • Port-Prototypen identischer Komponenten müssen über die Metamodell-Hierarchie (RootSwComponentPrototype / InstanceSpecifier) eindeutig adressierbar sein, um Fehlzuordnungen bei FindService() / OfferService() zu verhindern.
• Reentranz & Thread-Safety:
  • Werden mehrere Instanzen derselben Komponente (A) in dasselbe Executable gelinkt, teilen sie sich statische Variablen (static), Heap-Allocators und Singletons. C++-Applikationscode muss strikt reentrant und zustandsisoliert pro Komponenteninstanz implementiert sein.
• Kommunikationstransparenz:
  • Softwarekomponenten dürfen keine Annahmen über die Lokation ihrer Kommunikationspartner treffen. Ob ein Service-Partner im selben Prozess, in einem parallelen Prozess desselben Binaries oder auf einem entfernten Rechner läuft, wird ausschließlich deklarativ über das Deployment-Modell determiniert.