Figure 9.31: Interfaces required by Raw Data Stream

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (statische architektonische Abhängigkeitsansicht nach dem AUTOSAR Adaptive Platform Metamodell für Functional Clusters).
• Technischer Zweck: Spezifikation der externen Schnittstellenabhängigkeiten des Functional Clusters Raw Data Stream (RDS) in der AUTOSAR Adaptive Platform (Release R24-11).
• Funktionale Einordnung: Raw Data Stream dient dem performanten Transport unstrukturierter oder vorformatierter Massendaten (z. B. Sensor-Rohdatenströme). In dieser Fassung wird die Anbindung an die Zeitsynchronisation (zur hochpräzisen Zeitstempelung und Statusüberwachung von Sensorströmen) explizit als Port-Schnittstelle modelliert, während interne Betriebssystem- und Manifest-Abhängigkeiten aus der Cluster-Schnittstellenansicht abstrahiert wurden.

2. Komponenten, Entitäten & Schnittstellen

Konsumierende Komponente

• «aapFunctionalCluster» Raw Data Stream: Der primäre Plattform-Cluster, welcher die Rohdatenstrom-Dienste implementiert und über ausgehende «use»-Abhängigkeiten an drei Schnittstellen gekoppelt ist.

Ziel-Schnittstellen (Interfaces) & deren Realisierungen

1. «aapAPI, aapNativeInterface» Logger
   • Methoden:
     • + IsEnabled(): bool
     • + Log(MsgId, Params)
     • + LogDebug(): LogStream
     • + LogError(): LogStream
     • + LogFatal(): LogStream
     • + LogInfo(): LogStream
     • + LogVerbose(): LogStream
     • + LogWarn(): LogStream
     • + WithLevel(): LogStream
   • Realisierung: Realisiert via Interface Realization durch «aapFunctionalCluster» Log and Trace (ara::log). Bietet standardisiertes Tracing und Logging; IsEnabled() besitzt nun den expliziten Rückgabetyp bool.
2. «aapAPI, aapNativeInterface» CryptoStack
   • Semantik: Standardisierte C++-API (ara::crypto) für kryptografische Primitiven, Zertifikatsverwaltung und sichere Kanaletablierung (z. B. TLS/DTLS).
   • Realisierung: Realisiert via Interface Realization durch «aapFunctionalCluster» Cryptography daemon-based.
3. «aapAPI, aapPortInterface» SynchronizedTimeBaseConsumer
   • Semantik: Port-basierte Dienstschnittstelle der Plattform (ara::tsync) zur Abfrage synchronisierter Zeitbasen, Ratenabweichungen sowie zur Registrierung von Callback-Notifizierungen bezüglich des Synchronisationsstatus und Zeitsprüngen.
   • Methoden:
     • + GetRateDeviation()
     • + GetTimeWithStatus(): SynchronizedTimeBaseStatus
     • + RegisterStatusChangeNotifier()
     • + RegisterSynchronizationStateChangeNotifier()
     • + RegisterTimeLeapNotifier()
     • + RegisterTimePrecisionMeasurementNotifier()
     • + RegisterTimeValidationNotification()
     • + UnregisterStatusChangeNotifier()
     • + UnregisterSynchronizationStateChangeNotifier()
     • + UnregisterTimeLeapNotifier()
     • + UnregisterTimePrecisionMeasurementNotifier()
     • + UnregisterTimeValidationNotification()
   • Realisierung: Realisiert via Interface Realization durch «aapFunctionalCluster» Time Synchronization daemon-based.

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Schnittstellendiagramm zeigt die Abbildung keine Zeitlinien; der funktionale Ablauf im Stream-Lifecycle leitet sich aus den Schnittstellenbeziehungen ab:

1. Initialisierungsphase & Zeitsynchronisations-Setup:
   • RDS bindet die Port-Schnittstelle SynchronizedTimeBaseConsumer an den Daemon von Time Synchronization an.
   • Registrierung von Notifiern für Statusänderungen, Synchronisationszustände, Zeitsprünge (TimeLeapNotifier) und Präzisionsmessungen zur Sicherstellung verlässlicher Zeitbezüge.
2. Kanalaufbau & Absicherung:
   • Bei geforderter Stream-Sicherheit: Initialisierung und Schlüsselaushandlung über die Schnittstelle CryptoStack mit Cryptography daemon-based.
3. Streaming & präzise Zeitstempelung:
   • Während der Datenstromübertragung kontinuierliche Abfrage synchronisierter Zeitstempel via GetTimeWithStatus() sowie Überwachung von Ratenabweichungen via GetRateDeviation().
4. Laufzeit-Protokollierung:
   • Abfrage des Logging-Status via IsEnabled(): bool und kontinuierliche Ausgabe diagnostischer Meldungen über Logger an Log and Trace.

4. Normative Relevanz & Entwickler-Hinweise

• Kapselung und Entkopplung: Die vormals modellierten internen Plattform- und Betriebssystem-Schnittstellen (ManifestAccessor/Registry und TCP/IP Stack/Operating System) wurden aus der Schnittstellenansicht entfernt; interne OS- und Manifest-Details werden auf Cluster-Ebene abstrahiert.
• Normative Integration von Time Synchronization (ara::tsync): Die Einführung von SynchronizedTimeBaseConsumer als formale Port-Schnittstelle («aapPortInterface») ist normativ zentral für sicherheits- und zeitkritische Sensor-Rohdaten (z. B. Kamera, LiDAR), die eine exakte Korrelation mit einer synchronisierten globalen Zeitbasis und Beachtung von Zeitsprüngen erfordern.
• Typisierungs-Präzisierung: Die Operation IsEnabled() an der Logger-Schnittstelle spezifiziert verbindlich den Rückgabetyp bool.
• Konsistente Plattformdienste: Unverändert bleibt die obligatorische Nutzung der standardisierten Daemons für Cryptography (ara::crypto) und Log and Trace (ara::log).