Figure 4.60: Specification of the FirewallStateSwitchInterface

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Metamodell-Ausschnitt (AUTOSAR M2 Metamodel) aus der Spezifikation AUTOSAR_TPS_ManifestSpecification (Release R22-11).
• Architektur-Einordnung: AUTOSAR Adaptive Platform (AP), Teildomäne Security, Network Management und Mode Management.
• Technischer Zweck: Modellierung der Schnittstelle FirewallStateSwitchInterface im Software- und Manifest-Design. Sie dient der formalen Kapselung und Bereitstellung von Zustandsautomaten (State Machines) zur dynamischen Umschaltung von Firewall-Zuständen (z. B. Filterregeln, Sicherheitszonen, Betriebsmodi wie Default-Deny, Diagnostic, Operational) über standardisierte Port-basierte Interaktion.

2. Komponenten, Entitäten & Schnittstellen

• FirewallStateSwitchInterface:
  • Generalisierung / Basisklasse: PortInterface (im Diagrammkopf kursiv annotiert). Spezialisiertes Interface für die Service- und Prozesskommunikation im Adaptive-Manifest.
  • Rolle: Container für zustandsbehaftete Firewall-Steuerungen auf Software-Architekturebene.
• ModeDeclarationGroupPrototype:
  • Klassifikation / Stereotyp: «AtpPrototype» (AUTOSAR Template Profile Prototype Pattern).
  • Rolle: Instanziiert eine ModeDeclarationGroup, welche die diskreten Zustände/Modi (z. B. BLOCKED, RESTRICTED, FULL_ACCESS) eines Firewall-Zustandsautomaten deklariert.
• Beziehung & Kardinalität:
  • Komposition: Strenge Werteaggregation (ausgefüllte Raute an FirewallStateSwitchInterface). Die Lebensdauer der Prototypes ist an das Interface gebunden.
  • Rollenname: +firewallStateMachine (Sichtbarkeit: public).
  • Multiplizität: 0..*. Ein FirewallStateSwitchInterface kann keine, eine oder mehrere unabhängige Firewall-Zustandsautomaten aggregieren (z. B. getrennte Automaten für Interface-Zonen: Cellular, Ethernet-Backbone, Diagnostics).

3. Dynamisches Verhalten & Sequenzablauf

• Trigger: Zustandsänderungen werden durch autorisierte funktionale Einheiten initiiert (typischerweise State Management ara::sm / State Client oder ein Security Management Modul).
• Interaktionsmuster (AP-Moduswechsel):
  1. Mode Switch Request: Der Mode-Requester stößt einen Zustandswechsel über den typisierten Port an (SetState / Switch-Trigger).
  2. Asynchrone Abarbeitung: Der Moduswechsel wird asynchron über ara::core::Future/Promise-Muster oder Ereignisnotifikation vollzogen.
  3. Regel-Commit: Der zuständige Plattform-Service (z. B. Firewall Daemon, der Linux-Kernel-Netfilter/nftables/eBPF verwaltet) lädt und aktiviert das dem Zielmodus zugeordnete Regelsatz-Paket.
  4. Quittierung / Acknowledge: Nach erfolgreicher atomarer Aktivierung des Filtersatzes im Stack wechselt die Mode-Machine in den neuen Status.
• Fehlerpfade & Abbruch:
  • Schlägt das Laden eines Regelsatzes fehl (z. B. Inkonsistenz, Speicherengpass), verbleibt das System im definierten sicheren Zustand (Fail-Secure / Default-Block) und meldet eine Violation über Security Events / IdsM bzw. Platform Health Management (ara::phm).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung (ARXML):
  • Zuordnung im Execution- / Service-Instance-Manifest: Ein ProvidedPortPrototype oder RequiredPortPrototype eines Software-Komponenten-Typs muss FirewallStateSwitchInterface referenzieren.
  • Jeder ModeDeclarationGroupPrototype unter +firewallStateMachine muss zwingend auf eine gültige ModeDeclarationGroup zeigen (Konsistenzprüfung gem. TPS_MANI_03295 & TPS_MANI_03321).
• Multi-State-Machine-Design:
  • Bei Kardinalität > 1 (mehrere firewallStateMachine-Einträge) müssen Entwickler orthogonale Zustandsräume definieren, um Race Conditions oder widersprüchliche IP-Filterregeln zwischen den Sub-Automaten auszuschließen.
• IAM & Zugriffsbeschränkungen:
  • Ports, die auf FirewallStateSwitchInterface basieren, müssen per Identity and Access Management (IAM) strikt geschützt werden. Unprivilegierten Applikationen darf kein schreibender Port-Zugriff gewährt werden, da Manipulationen an der Firewall State Machine die Fahrzeug-Netzwerksicherheit kompromittieren.
• Generator-Vertrag:
  • Der Codegenerator leitet aus diesem Metamodell-Element die typisierten Port-Klassen bzw. Skeleton/Proxy-Strukturen ab, über welche die Mode-Deklarationen C++-seitig als Enums/Zustandstypen bereitgestellt werden.