class ara::rds::RawDataStreamServer

Die Klasse ara::rds::RawDataStreamServer ermöglicht Server-Anwendungen das Entgegennehmen einer Client-Verbindung sowie das Lesen und Schreiben binärer Datenströme über modellierte Ports SWS RawDataStream S. 1. Nach der Erzeugung über die statische Fabrikmethode Create wartet die Anwendung synchron oder zeitbeschränkt auf eine Verbindung, um anschließend Daten über ReadData und WriteData auszutauschen [SWS_RDS_11312]. Da die Klasse reine Move-Semantik besitzt und alle Operationen noexcept deklariert sind, erfolgt die Fehlerbehandlung ausschließlich über ara::core::Result.

mehr ›

Kontext

Die Klasse ara::rds::RawDataStreamServer stellt in der AUTOSAR Adaptive Platform (Modul rds) das serverseitige Gegenstück für stromorientierte Datenübertragungen dar SWS RawDataStream S. 1. Ihre Hauptaufgabe besteht darin, eingehende Client-Verbindungen an einem modellierten Kommunikationsport entgegenzunehmen und den anschließenden bidirektionalen Austausch unstrukturierter Rohdaten über binäre Datenströme abzuwickeln.

Zu den zentralen Interaktionspartnern gehören:

• die übergeordnete Server-Anwendung, welche die Instanz erzeugt, Verbindungen abwartet und die Datenübertragung initiiert,
• das AUTOSAR-Laufzeitsystem, an welches der Server über einen ara::core::InstanceSpecifier für einen modellierten Port gebunden wird [SWS_RDS_11312],
• der externe Client, der eine Verbindung zum Server aufbaut [SWS_RDS_11318] und Nutzdaten austauscht [SWS_RDS_11322], [SWS_RDS_11324].

Lebenszyklus

Die Instanziierung eines RawDataStreamServer erfolgt nicht über gewöhnliche Konstruktoren, sondern ausschließlich über die statische Fabrikmethode Create [SWS_RDS_11312]. Diese bindet den Server an den per ara::core::InstanceSpecifier angegebenen Port.

Hinsichtlich der Besitzverhältnisse erzwingt die Klasse eine strikte Move-Only-Semantik. Der Kopierkonstruktor [SWS_RDS_11316] und der Kopierzuweisungsoperator [SWS_RDS_11317] sind explizit gelöscht (delete). Eine Übergabe von Ressourcen an andere Gültigkeitsbereiche ist daher nur über den Move-Konstruktor [SWS_RDS_11314] oder den Move-Zuweisungsoperator [SWS_RDS_11315] möglich.

Interpretation: Nach erfolgreicher Erzeugung befindet sich die Server-Instanz in einem initialen Zustand der Bereitschaft, in dem noch keine aktive Verbindung besteht. Frage Q-5d536f7c10a62342 (offen) Über WaitForConnection [SWS_RDS_11318] oder die zeitüberwachte Variante WaitForConnection(timeout) [SWS_RDS_11319] wartet der Server auf einen Client und wechselt bei Erfolg in den Zustand einer aktiven Verbindung. Die Verbindung kann zur Laufzeit gezielt durch den Aufruf von Shutdown geschlossen werden [SWS_RDS_11320].

Beim Zerstören der Server-Instanz gewährleistet der Destruktor ~RawDataStreamServer, dass eine noch offene Verbindung automatisch ordnungsgemäß heruntergefahren und geschlossen wird [SWS_RDS_11313].

Bezüglich der Nebenläufigkeit ist die Erzeugungsmethode Create als threadsicher spezifiziert [SWS_RDS_11312]. Die Verschiebeoperationen [SWS_RDS_11314], [SWS_RDS_11315] sowie der Destruktor [SWS_RDS_11313] sind hingegen explizit als nicht threadsicher (not thread-safe) ausgewiesen und erfordern externen Synchronisationsschutz bei gleichzeitigem Zugriff aus mehreren Threads.

Zustandsdiagramm: Phasen einer Server-Instanz von der Erzeugung über die Verbindungsannahme bis zum Verbindungsabbau. Quellen: [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11320], [SWS_RDS_11313]

Nutzungspfad

Der typische Nutzungspfad einer Server-Anwendung umfasst die Schritte Initialisierung, Warten auf Verbindungen, bidirektionalen Datentransfer und Verbindungsabbau:

1. Server erzeugen: Die Anwendung instanziiert den Server über ara::rds::RawDataStreamServer::Create(instance) für den konfigurierten Port [SWS_RDS_11312].
2. Auf Verbindung warten: Die Anwendung blockiert mittels WaitForConnection() [SWS_RDS_11318] oder mit konfigurierter Maximaldauer via WaitForConnection(timeout) [SWS_RDS_11319], bis ein Client die Verbindung aufgebaut hat.
3. Daten empfangen und senden: Nach erfolgreicher Verbindung liest die Anwendung Binärdaten mittels ReadData(maxLength) [SWS_RDS_11322] oder zeitüberwacht via ReadData(maxLength, timeout) [SWS_RDS_11323] aus. Zum Senden von Binärdaten wird WriteData aufgerufen, wahlweise ohne Wartezeitbegrenzung [SWS_RDS_11324] oder mit Zeitüberwachung [SWS_RDS_11325]. Das Senden via WriteData überträgt vermutlich den Besitz des bereitgestellten Byte-Puffers (std::unique_ptr<ara::core::Byte[]>) an den Server. Frage Q-eec0fea4a5ffaf40 (offen)
4. Verbindung trennen: Ist die Datenübertragung abgeschlossen, beendet die Anwendung die Sitzung explizit über Shutdown() [SWS_RDS_11320].

Sequenzdiagramm: Ablauf von Erzeugung, Verbindungsannahme, Datenaustausch und Schließung der Verbindung. Quellen: [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322], [SWS_RDS_11324], [SWS_RDS_11320]

Fehlerszenarien

Die Fehlerbehandlung von RawDataStreamServer folgt den Grundsätzen der AUTOSAR Adaptive Platform für fehlersichere Schnittstellen:

Keine der Methoden wirft C++-Ausnahmen; alle Funktionen sind als noexcept deklariert SWS RawDataStream S. 1. Fehlerfälle werden stattdessen über den Rückgabetyp ara::core::Result an den Aufrufer kommuniziert.

Typische Fehlerszenarien umfassen:

• Zeitüberschreitungen: Bei den Methoden WaitForConnection [SWS_RDS_11319], ReadData [SWS_RDS_11323] und WriteData [SWS_RDS_11325] mit Timeout führt das Verstreichen der angegebenen Zeitspanne zu einem Fehlerzustand im zurückgegebenen ara::core::Result.
• Verbindungsfehler und ungültige Zustände: Die Methoden ReadData, WriteData und WaitForConnection dürften im Fehlerfall (etwa bei vorzeitig getrennter Verbindung oder internen Kommunikationsfehlern) entsprechende Fehlercodes im ara::core::Result zurückliefern. Frage Q-0c6815ddde412d81 (offen)
• Vor- und Nachbedingungen: Aufrufer müssen das zurückgegebene ara::core::Result vor dem Zugriff auf Datenwerte stets auf Gültigkeit prüfen, um den fehlerfreien Zustand der Operation sicherzustellen.