Figure 10.48: AdaptiveFirewallModuleInstantiation and the relationship to Application with a RPortPrototype typed by a FirewallStateSwitchInterface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Metamodell-Klassendiagramm (AUTOSAR Adaptive Platform, AUTOSAR_TPS_ManifestSpecification, Release R22-11).
• Technischer Zweck: Modellierung der Zuordnung zwischen der Instanziierung des Firewall Functional Cluster auf Maschinenebene (AdaptiveFirewallModuleInstantiation) und den konsumierenden Ports einer Adaptive Application (RPortPrototype).
• Funktionale Einordnung: Verankert im Manifest-Metamodell (Execution-/Machine-Manifest). Es stellt das sicherheitskritische Bindeglied dar, über das eine autorisierte Applikation (typischerweise State Management oder ein zentraler Security Manager) zur Laufzeit dynamische Zustandswechsel der Host-Firewall (z. B. Umschaltung von Regelsätzen zwischen Driving, Parking, Diagnostics) anfordern kann.

2. Komponenten, Entitäten & Schnittstellen

• AdaptiveFirewallModuleInstantiation
  • Basistyp: Spezialisiert die abstrakte Klasse NonOsModuleInstantiation.
  • Semantik: Repräsentiert die konkrete Plattform-Instanz des Firewall-Stacks auf einer spezifischen Maschine (ECU), inklusive der zugehörigen Regelsätze und zustandsabhängigen Filterkonfigurationen.
• AdaptiveFirewallToPortPrototypeMapping
  • Basistyp: Spezialisiert UploadablePackageElement.
  • Semantik: Verbindungsentität (Mapping), welche die Entkopplung von Plattform-Dienst und Software-Komponenten-Design auflöst.
  • Rollen & Assoziationen:
    • +firewall (Multiplizität 0..1): Unidirektionale Referenz auf die Ziel-Instanz AdaptiveFirewallModuleInstantiation.
    • +rPortPrototype (Multiplizität 0..1): Unidirektionale Referenz auf den anfordernden RPortPrototype.
• RPortPrototype
  • Basistyp: Spezialisiert AbstractRequiredPortPrototype.
  • Semantik: Required-Port einer Adaptive Application zur Nutzung von Plattform-Funktionalitäten.
  • Typisierung: Assoziation «isOfType» +requiredInterface (Multiplizität 0..1, tagged with {redefines atpType}) referenziert das typisierende PortInterface.
• PortInterface
  • Stereotypen/Metaklassen: ARElement, AtpBlueprint, AtpBlueprintable, AtpType.
  • Semantik: Abstrakte Basisklasse aller AUTOSAR-Port-Schnittstellen.
• FirewallStateSwitchInterface
  • Vererbung: Spezialisiert per Generalisierung (extends) die Klasse PortInterface.
  • Semantik: Standardisierte funktionale Schnittstelle des Firewall Functional Clusters zur Steuerung von Firewall-Modi/Zuständen (z. B. via standardisierter Operation SwitchFirewallState).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm beschreibt die statische Metamodell-Struktur für folgende Laufzeitinteraktion:

1. Trigger: Eine Adaptive Application initiiert über den generierten C++ Proxy ihres RPortPrototype einen Zustandswechsel über das FirewallStateSwitchInterface (z. B. Aufruf von SwitchFirewallState(newState)).
2. Autorisierungsprüfung & Binding: Das Adaptive-Laufzeitsystem validiert anhand des im Manifest deklarierten AdaptiveFirewallToPortPrototypeMapping, ob der anfordernde Prozess die Berechtigung besitzt, die referenzierte AdaptiveFirewallModuleInstantiation zu steuern (Principle of Least Privilege).
3. Zustandsübergang (Synchron/Asynchron):
   • Der Firewall-Dämon verarbeitet die Anfrage, wählt den Ziel-Regelsatz aus und wendet diesen atomar auf die Kernel-Paketfilter (z. B. nftables/iptables im POSIX-OS) an.
   • Rückmeldung erfolgt über ein typisiertes ara::core::Result<void> bzw. ein entsprechendes Future/Promise-Pattern.
4. Fehlerbehandlung:
   • Schlägt die Transition fehl (z. B. ungültiger Zielzustand oder Rechteverletzung), wird ein domänenspezifischer Fehlercode (FirewallErrc) zurückgegeben; sicherheitsrelevante Ereignisse werden synchron an das Intrusion Detection System Manager (IdsM) Functional Cluster eskaliert.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Anforderung [TPS_MANI_03296]: Verpflichtet den System-Integrator dazu, eine Instanz von AdaptiveFirewallToPortPrototypeMapping zu definieren, wenn eine Applikation den Firewall-Zustand über einen Port vom Typ FirewallStateSwitchInterface steuern soll.
• Manifest-Konfiguration:
  • Fehlt die Zuordnung AdaptiveFirewallToPortPrototypeMapping im ARXML-Manifest, schlägt der Plattform-Generator für die Service-Bindung fehl oder die Firewall-Laufzeitumgebung verweigert Anfragen der Applikation aufgrund fehlender Zugriffsdeklaration.
  • Multiplizitäten (0..1) erlauben Firewalls ohne Applikationssteuerung (rein statische Filter) sowie Anwendungen, deren Ports noch nicht fest an eine Maschinen-Instanz gebunden sind.
• Applikations- & Stack-Entwicklung:
  • Applikations-Entwickler: Müssen die Softwarekomponente mit einem RPortPrototype versehen, der explizit durch FirewallStateSwitchInterface typisiert ist. Direkter Systemzugriff auf OS-Paketfilter ohne diesen Plattform-Port verletzt die AUTOSAR-Sicherheitsarchitektur.
  • Plattform-/Stack-Integrator: Muss sicherstellen, dass die AdaptiveFirewallModuleInstantiation konsistent zu den Maschinen-Netzwerkschnittstellen konfiguriert ist und die IPC-Rechte (UID/GID bzw. SELinux/AppArmor-Policies) für den mapped Process entsprechend generiert werden.