DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Firewall FIG-baff438035b6c18a 426 × 298 px 1 Release(s)

Figure 5.1: Interfaces required by Firewall from other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: baff438035b6c18ae605d680444392f50954b029990de87c0f61cb3fc6561c32

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Komponentendiagramm / Architektur-Abhängigkeitsdiagramm mit AUTOSAR-Adaptive-Stereotypen («aapFunctionalCluster», «aapPortInterface,aapAPI», «aapInternal»).
  • Funktionale Einordnung: Spezifikation der ausgehenden Abhängigkeiten (Required Interfaces) des Functional Clusters Firewall im AUTOSAR Adaptive Platform Standard (AP R23-11, Kap. 5.2).
  • Architektur-Kontext: Die Firewall operiert rein als Konsument (Consumer); sie stellt selbst keine Schnittstellen für andere Functional Clusters bereit (Table 5.1: No provided interfaces). Ihre Systemanbindung beschränkt sich auf das Melden von Sicherheitsvorfällen an den IdsM sowie die Interaktion mit dem netzwerksteuernden Betriebssystem-Stack.

2. Komponenten, Entitäten & Schnittstellen

  • Firewall («aapFunctionalCluster», daemon-based):
    • Autonomer Daemon-Prozess zur Überwachung und Filterung des IP-basierten Netzwerkverkehrs.
  • Intrusion Detection System Manager («aapFunctionalCluster», daemon-based):
    • Zentraler Sicherheits-Cluster der Plattform zur Erfassung, Aggregation und Weiterleitung fahrzeuginterner Security-Events.
  • EventReporter («aapPortInterface,aapAPI»):
    • Standardisierte funktionale Schnittstelle mit der Operation + ReportEvent().
    • Beziehung: Die Firewall konsumiert diese Schnittstelle via «use»-Abhängigkeit. Der IdsM realisiert sie (Interface Realization via gestrichelter Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
  • Operating System (Basiskomponente / Execution Environment):
    • Zugrundeliegendes POSIX-kompatibles Betriebssystem.
  • TCP/IP Stack («aapInternal»):
    • Plattforminterne Netzwerkschnittstelle unterhalb der AUTOSAR-Standard-API-Ebene.
    • Beziehung: Die Firewall greift via «use» auf den Stack zu; das Operating System stellt die Realisierung (Realization) des Netzwerk-Stacks bereit.

3. Dynamisches Verhalten & Sequenzablauf

Obgleich als statische Struktur modelliert, diktiert die Topologie folgenden Kontroll- und Datenfluss:

  1. Paketinspektion & Filterung (Synchron / Inline):
    • Netzwerkpakete durchlaufen den TCP/IP Stack des Operating System.
    • Die Firewall greift über die proprietäre «aapInternal»-Schnittstelle synchron in den Protokollstapel ein (Paketprüfung gegen Filterregeln: Ingress/Egress, L3/L4-Header, Stateful Tracking, Drop/Accept).
  2. Sicherheitsereignis-Trigger:
    • Bei Erkennung einer Anomalie (z. B. Port-Scan, ungültige Flags, Rate-Limit-Überschreitung, verworfene Pakete) instanziiert die Firewall ein standardisiertes Security Event.
  3. Event-Reporting (API-Aufruf):
    • Die Firewall ruft synchron oder entkoppelt ReportEvent() auf der EventReporter-Instanz auf.
    • Der IdsM übernimmt die Payload (inkl. Event-ID, Kontextdaten, Timestamp), filtert/puffert das Event und bereitet es für den Export via IdsR (Intrusion Detection System Reporter) vor.

4. Normative Relevanz & Entwickler-Hinweise

  • Fehlende Applikationsports: Die Firewall exportiert keine C++ APIs via ara::com für User-Applications. Anpassungen und Überwachungsregeln müssen deklarativ über das Execution Management bzw. Manifest-Deployment konfiguriert werden.
  • OS-Bindung («aapInternal»): Da der Zugriff auf den TCP/IP Stack mit «aapInternal» typisiert ist, existiert keine AUTOSAR-standardisierte C++-API für die Paketfilterung. Stack-Integratoren müssen plattformspezifische Kernel-Hooks (z. B. Linux netfilter/nftables/eBPF oder QNX io-pkt-Filter) über proprietäre Treiber-/OS-Mechanismen an den Firewall-Daemon anbinden.
  • Schnittstellenvertrag ReportEvent():
    • Aufrufer müssen sicherstellen, dass die im Firewall-Cluster genutzten Event-IDs exakt den im ARXML-Datenmodell des IdsM hinterlegten Definitionskatalogen entsprechen.
    • Das Reporting darf bei hohem Angriffs-/Paketvolumen (DoS) nicht blockieren; der IdsM-Treiber/Stack muss Puffer- und Drosselungsmechanismen (Traffic Shaping/Rate Limiting für Security Events) implementieren, um Denial-of-Service auf Plattformebene zu verhindern.
  • Berechtigungsstufe: Als daemon-based Cluster erfordert die Firewall zur Interaktion mit dem OS-Netzwerkstack erweiterte POSIX-Privilegien (z. B. CAP_NET_ADMIN unter Linux), wohingegen die Interaktion mit dem IdsM über plattformkonforme IPC (Inter-Process Communication) abgewickelt wird.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R23-11 → R24-11 keine inhaltliche Änderung Vorgänger: FIG-581fe21980f174e8

Keine inhaltlichen Änderungen erkennbar.

R24-11 → R25-11 normative Änderung Nachfolger: FIG-93b12a4921a5ef40
  • Execution Management («aapFunctionalCluster», daemon-based): Neuer Functional Cluster im Diagramm, der den Prozess- und Lebenszyklusdienst bereitstellt und ExecutionClient realisiert.
  • ExecutionClient («aapAPI,aapNativeInterface»): Neu hinzugefügte Schnittstelle mit den Methoden + Create() und + ReportExecutionState(ExecutionState).
  • Abhängigkeit Firewall zu ExecutionClient: Neue «use»-Beziehung von der Firewall zur ExecutionClient-Schnittstelle zur Meldung des Ausführungszustands.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | Firewall | daemon-based | «aapPortInterface,aapAPI» | EventReporter | + ReportEvent() | «aapFunctionalCluster» Intrusion Detection System Manager daemon-based | «aapInternal» | TCP/IP Stack | Operating System | «use» «use»

Begleitender Spezifikationstext:

Specification of Firewall for Adaptive Platform AUTOSAR AP R24-11 5 Dependencies to other Functional Clusters AUTOSAR decided not to standardize interfaces which are exclusively used between Functional Clusters (on platform-level only), to allow efficient implementations, which might depend e.g. on the used Operating System. This chapter provides an informative guideline of the interaction of Firewall with other Functional Clusters in the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the public interfaces provided by Firewall to other Functional Clusters. Section 5.2 “Required Interfaces” lists the public interfaces required by Firewall. The goal is to provide a clear understanding of Functional Cluster boundaries and interaction, without specifying syntactical details. This ensures compatibility between documents specifying different Functional Clusters and supports parallel implementation of different Functional Clusters. Details of internal interfaces are up to the platform provider. Additional internal interfaces, parameters and return values can be added. A detailed technical architecture documentation of the overall AUTOSAR Adaptive Platform is provided in [5]. 5.1 Provided Interfaces Interface Functional Cluster Purpose No provided interfaces Table 5.1: Interfaces provided to other Functional Clusters 5.2 Required Interfaces «aapFunctionalCluster» Firewall daemon-based «aapPortInterface,aapAPI» EventReporter + ReportEvent() «aapFunctionalCluster» I

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_Firewall S. 11 5.1 Figure 5.1: Interfaces required by Firewall from other Functional Clusters