Figure 8.3: Excerpt of Meta-Model

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Metamodell-Ausschnitt der AUTOSAR Adaptive Platform).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_SWArchitecture (Kapitel 8: Architecture / Generic Design Patterns, Spezifikation des Plugin-Musters).
• Funktionaler Zweck: Modellierung des Entwurfsmusters für konfigurierbare Framework-Erweiterungen (Plugins) im Adaptive-Manifest. XYPluginConfiguration fungiert als generisches Template-Metamodellelement für domänenspezifische Erweiterungen (z. B. UDS-Transport-Plugins im Diagnostic Management, kryptografische Treiber/Treiber-Plugins im Crypto Stack oder State-Management-Plugins). Es entkoppelt die Manifest-Konfiguration von herstellerspezifischen Implementierungsdetails.

2. Komponenten, Entitäten & Schnittstellen

• Referrable (abstrakte Metaklasse):
  • Basisklasse des AUTOSAR-Kernmetamodells zur eindeutigen Identifikation von Modellelementen.
  • Attribute: + shortName: Identifier (eindeutiger lokaler Bezeichner im Manifest-Namensraum zur Adressierung per AUTOSAR-Pfad).
• XYPluginConfiguration (konkrete Metaklasse / Template):
  • Repräsentiert die Manifest-Konfiguration eines konkreten Plugin-Typs „XY“.
  • Attribute: + implementation: ClassNameString (vollqualifizierter C++-Klassenname inklusive Namensräumen, der die Plugin-Schnittstelle realisiert).
• Beziehungen & Vererbung:
  • Generalisierung: XYPluginConfiguration spezialisiert Referrable (gekennzeichnet durch die durchgezogene Linie mit geschlossener, nicht ausgefüllter Dreieckspfeilspitze). Alle Plugin-Konfigurationen erben die Referenzierbarkeit über shortName.
  • Kardinalität der Attribute: Implizit jeweils 1..1 (Pflichtangabe von Bezeichner und Implementierungsstring im ARXML-Modell).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm selbst definiert eine statische Metamodell-Struktur. Das daraus resultierende Laufzeit- und Toolchain-Verhalten gliedert sich wie folgt:

1. Design-/Generierungsphase:
   • Der AUTOSAR-Codegenerator parst die Manifest-Instanz von XYPluginConfiguration.
   • Anhand des Attributs implementation wird der statische Registrierungscode bzw. die Factory-Map generiert, die die Instanziierung der spezifizierten C++-Klasse anbindet.
2. Plattform-Initialisierung (Boot-Phase):
   • Das übergeordnete Framework (z. B. Diagnostic- oder Crypto-Cluster) initialisiert die Plugin-Registry.
   • Das Plugin wird anhand seines shortName (oder einer daraus abgeleiteten ID) in der internen Instanz-Tabelle registriert.
3. Runtime Dispatch:
   • Eingehende Funktionsanforderungen werden über die vom Plugin implementierte Schnittstelle (C++ Abstract Base Class) synchron oder asynchron an die registrierte Instanz delegiert.

4. Normative Relevanz & Entwickler-Hinweise

• Deterministisches Deployment: Die Manifest-Deklaration erzwingt ein geschlossenes System („Closed World Assumption“). Das unkontrollierte Nachladen beliebiger Shared Objects zur Laufzeit wird unterbunden; sämtliche Plugins müssen zur Deploy-Zeit über das Manifest deklariert sein (essenziell für Safety- und Security-Freigaben nach ISO 26262 / ISO 21434).
• Vertrag für C++-Entwickler:
  • Der unter implementation angegebene Bezeichner muss exakt mit dem linkbaren Symbol bzw. der C++-Klassendeklaration übereinstimmen (ClassNameString).
  • Die referenzierte Klasse muss das plattformspezifische Plugin-Interface vollständig implementieren und die Lebenszyklus-Methoden (Init, Deinit, Execution Contexts) fehlerfrei bereitstellen.
• Bibliotheksbindung: Abhängig von der weiteren Konfigurationsausprägung im Cluster wird das Plugin entweder statisch gegen den Platform-Daemon gelinkt oder als dynamische Bibliothek (DynamicLibrary) innerhalb des entsprechenden SoftwareCluster bereitgestellt und geladen.