Figure 8.4: Example of Configuration in the Manifest

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Objektdiagramm (Instanzendiagramm / InstanceSpecification im AUTOSAR-Metamodell).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_SWArchitecture (Kapitel 8: Architekturmuster & Erweiterbarkeit).
• Technischer Zweck: Exemplarische Darstellung der Deklaration und Parametrierung konkreter Plugin-Instanzen innerhalb des AUTOSAR-Manifests (ARXML). Es demonstriert das Entwurfsmuster zur Entkopplung generischer Plattform-Dienste (Functional Clusters) von austauschbaren, herstellerspezifischen Erweiterungsmodulen (Plugins) über Manifest-Einträge.

2. Komponenten, Entitäten & Schnittstellen

• Instanzen / Entitäten:
  • PluginA: XYPluginConfiguration
    • Typ: Ausprägung der Metaklasse XYPluginConfiguration (generischer Platzhalter für eine clusterspezifische Plugin-Konfigurationsklasse).
    • Attribute:
      • shortName = pluginA: Eindeutiger ARXML-Modellbezeichner gemäß AUTOSAR-Namensraumregeln (Identifier).
      • implementation = a::b::PluginA: Vollqualifizierter C++ Typ- bzw. Klassennamensraum (namespace a::b, Klasse PluginA).
  • PluginB: XYPluginConfiguration
    • Typ: Zweite, parallele Ausprägung derselben Metaklasse XYPluginConfiguration.
    • Attribute:
      • shortName = pluginB: Eindeutiger ARXML-Modellbezeichner.
      • implementation = c::d::PluginB: Vollqualifizierter C++ Typ- bzw. Klassennamensraum (namespace c::d, Klasse PluginB).
• Beziehungen & Kardinalitäten:
  • Beide Objekte existieren unabhängig nebeneinander als Geschwisterelemente innerhalb eines übergeordneten Konfigurationscontainers im Manifest (Kardinalität $0..\ast$ bezogen auf XYPluginConfiguration).
  • Keine direkte Assoziation oder Vererbung zwischen den beiden Instanzen; sie teilen sich denselben strukturellen Typvertrag (XYPluginConfiguration).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt eine rein statische Deklaration dar. Das daraus abgeleitete Laufzeitverhalten beim Prozess-Bootstrapping gestaltet sich wie folgt:

1. Manifest-Parsing: Beim Start des Prozesses bzw. des betreffenden Functional Clusters liest der Plattform-Stack das generierte Manifest (Execution-/Machine-Manifest) ein.
2. Factory-Instanziierung / Dynamic Binding:
   • Der Plattform-Core löst den String-Wert des Attributs implementation (a::b::PluginA bzw. c::d::PluginB) über eine interne Factory-Registry oder via Dynamic Symbol Resolution (dlopen/dlsym bei Shared Libraries) auf.
   • Alternativ: Bei kompilierzeitiger Bindung wird der Bezeichner zur Instanziierung über C++-Templates / Registrierungs-Makros herangezogen.
3. Lebenszyklus-Trigger: Initialisierungs-Callbacks der jeweiligen Plugin-Schnittstelle werden synchron während der Initialisierungsphase des Functional Clusters aufgerufen; Fehler beim Laden führen zum Fail-Safe-Abbruch des Cluster-Starts.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung: Entwickler müssen für jede Plugin-Variante eine eigene InstanceSpecification unter Beachtung der AUTOSAR-Namenskonventionen (shortName) definieren.
• C++ Code- & Namespace-Bindung: Der Wert von implementation muss exakt mit dem vollqualifizierten C++ Klassennamen übereinstimmen. Tippfehler oder fehlende Namespaces führen zu Laufzeitfehlern bei der dynamischen Bindung bzw. zu Linker-Fehlern bei Codegeneratoren.
• Schnittstellenvertrag: Sowohl a::b::PluginA als auch c::d::PluginB müssen dieselbe von XY vorgegebene abstrakte C++ Plugin-Basisschnittstelle implementieren (Polymorphie).
• Binary Deployment: Die referenzierten Symbole müssen entweder statisch in das Executable des Functional Clusters eingebunden sein oder als Shared Objects (.so) im Suchpfad des dynamischen Linkers liegen, abgesichert gegen ABI-Inkompatibilitäten.