module ara::rds — Raw Data Streams

Le cluster adaptatif Raw Data Stream (RDS) sert au transfert optimisé en latence et en débit de flux de données non structurés ainsi que de données de capteurs et multimédias critiques en temps, en contournant les surcoûts de sérialisation orientés services AUTOSAR_AP_EXP_SWArchitecture p. 74. Il fournit des API C++ pour les flux d'octets point à point basés sur IP (TCP/UDP) ainsi que pour le streaming de couche 2 selon la norme AVTP IEEE 1722 [SWS_RDS_10482], [SWS_RDS_90312]. Les deux formes de communication fonctionnent strictement via des méthodes factory statiques et signalent les erreurs de manière économe en ressources au moyen de la construction Result à l'échelle de la plateforme [SWS_RDS_12367].

plus ›

Le cluster fonctionnel Raw Data Stream (RDS) met à disposition des interfaces haute performance pour la transmission de flux d'octets non formatés et de données de capteurs critiques en temps pour l'AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_SWArchitecture p. 73. Grâce à l'abstraction directe des sockets réseau POSIX ainsi que des interfaces Ethernet de couche 2, RDS contourne la sérialisation lourde de la communication standard orientée services (ara::com) AUTOSAR_AP_EXP_SWArchitecture p. 74.

Pour les flux d'octets basés sur IP via TCP ou UDP, les applications utilisent les classes RawDataStreamClient et RawDataStreamServer, qui sont liées à des ports modélisés par le biais de méthodes statiques Create [SWS_RDS_10482], [SWS_RDS_11312]. Après l'établissement de la connexion via Connect ou WaitForConnection, les volumes de données sont échangés sans copies mémoire inutiles au moyen de std::unique_ptr<ara::core::Byte[]> via ReadData et WriteData [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11301].

Diagramme de séquence : établissement de connexion, échange de données et terminaison pour les flux Raw Data Stream basés sur IP. Sources : [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322]

Pour les flux de données temps réel déterministes provenant de caméras ou de sources audio, RDS implémente des classes conformes à l'IEEE 1722 (AVTP) telles que IEEE1722RawDataStreamProducer et IEEE1722RawDataStreamConsumer [SWS_RDS_90312], [SWS_RDS_90323]. Des classes de sous-types spécifiques telles que RVF (vidéo), AAF (audio) et CRF (référence d'horloge) encapsulent ici des en-têtes de trame et des données utiles conformes à la norme [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295].

Les erreurs sont signalées de manière conforme à la plateforme sans exceptions C++ via ara::core::Result et le domaine d'erreur RdsErrorDomain avec des codes d'erreur spécifiques (RdsErrc) [SWS_RDS_11298], [SWS_RDS_12367]. Dans le manifeste AUTOSAR, la définition d'interface est liée de manière transparente à des points de terminaison Ethernet via RawDataStreamClientMapping et RawDataStreamServerMapping AUTOSAR_AP_TPS_ManifestSpecification p. 851.

plus ›

Intégration architecturale et limites du système

Le cluster fonctionnel Raw Data Stream (RDS) de l'AUTOSAR Adaptive Platform fournit des interfaces de programmation (API) standardisées pour le transfert haute performance de flux de données non structurés ou critiques en temps réel AUTOSAR_AP_EXP_SWArchitecture p. 73. Contrairement à la communication fortement typée et orientée services via des ServiceInterfaces (telles que SOME/IP ou DDS), RDS contourne entièrement le surcoût de protocole et de sérialisation d'ara::com AUTOSAR_AP_EXP_SWArchitecture p. 74. Cela permet le raccordement en temps réel et optimisé en débit de capteurs à large bande tels que des caméras vidéo, des capteurs radar, LiDAR ou des systèmes audio directement aux Adaptive Applications AUTOSAR_AP_EXP_SWArchitecture p. 61.

Sur le plan architectural, le module se divise en deux piliers de communication fondamentaux : d'une part, la transmission de flux d'octets basée sur IP via des protocoles de transport tels que TCP ou UDP avec encapsulation des sockets POSIX et sécurisation optionnelle TLS/IPsec AUTOSAR_SWS_CommunicationManagement p. 58. D'autre part, le module offre un sous-système spécialisé pour le streaming de couche 2 selon l'IEEE 1722 (Audio Video Transport Protocol, AVTP) sur des réseaux Ethernet et Time-Sensitive Networking (TSN) AUTOSAR_AP_EXP_SWArchitecture p. 74. Les deux formes de communication abstrayent les structures de réseau et de tampon spécifiques au système derrière des classes C++ uniformes dans l'espace de noms ara::rds AUTOSAR_AP_SWS_RawDataStream p. 39.

Instanciation et gestion des connexions

La création de points de terminaison de communication s'effectue dans RDS strictement via des méthodes factory statiques qui sont liées à des instances de port modélisées [SWS_RDS_10482]. Pour les flux d'octets basés sur IP, les classes ara::rds::RawDataStreamClient et ara::rds::RawDataStreamServer encapsulent les rôles d'initiateur et d'écouteur AUTOSAR_AP_EXP_SWArchitecture p. 73. La factory RawDataStreamClient::Create instancie un point de terminaison client pour un port défini dans le manifeste de manière thread-safe via un ara::core::InstanceSpecifier [SWS_RDS_10482]. De manière analogue, RawDataStreamServer::Create crée l'instance correspondante de point de terminaison serveur [SWS_RDS_11312]. Les deux classes interdisent les constructeurs de copie et les affectations par copie, mais prennent explicitement en charge les sémantiques de déplacement pour une propriété univoque des ressources [SWS_RDS_11303], [SWS_RDS_11305], [SWS_RDS_11316], [SWS_RDS_11314].

Après une initialisation réussie, le serveur attend des connexions entrantes via WaitForConnection de manière bloquante ou avec un délai d'attente spécifié [SWS_RDS_11318], [SWS_RDS_11319]. De son côté, le client établit activement la connexion au moyen de Connect, au choix sans limite ou dans un laps de temps exprimé en millisecondes [SWS_RDS_10484], [SWS_RDS_11307]. La terminaison d'une session active s'effectue soit de manière déterministe par l'appel de Shutdown [SWS_RDS_10485], [SWS_RDS_11320], soit implicitement dans le cadre de l'appel du destructeur, qui ferme et libère automatiquement une connexion encore ouverte [SWS_RDS_10483], [SWS_RDS_11313].

Diagramme de séquence : établissement de connexion, échange bidirectionnel de données et terminaison entre RawDataStreamClient et RawDataStreamServer. Sources : [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322], [SWS_RDS_11324], AUTOSAR_AP_SWS_RawDataStream p. 10, AUTOSAR_AP_EXP_SWArchitecture p. 204, AUTOSAR_AP_EXP_SWArchitecture p. 222

Diagramme d'états : cycle de vie d'une connexion Raw Data Stream. Sources : [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_10485], [SWS_RDS_10486], [SWS_RDS_10487], [SWS_RDS_11318], [SWS_RDS_11320]

Échange de données IP non structuré via des sockets

Le transfert de données pour les connexions IP est conçu pour être bidirectionnel et s'effectue via des opérations pouvant être traitées de manière synchrone avec surveillance optionnelle du délai d'attente [SWS_RDS_10486], [SWS_RDS_11309]. Du côté récepteur, l'opération ReadData renvoie une structure de données de type ara::rds::ReadDataResult [SWS_RDS_10486], [SWS_RDS_11322]. Cette structure encapsule les données binaires lues sous la forme d'un pointeur intelligent data (std::unique_ptr<ara::core::Byte[]>) et indique via le champ numberOfBytes le nombre réel d'octets reçus [SWS_RDS_11301], [SWS_RDS_11302]. Grâce à ce transfert de propriété du tampon, les copies mémoire inutiles sont évitées.

Pour l'envoi de données binaires, les applications transmettent également le tampon d'octets au moyen de la sémantique de déplacement via un std::unique_ptr<ara::core::Byte[]> et spécifient la longueur maximale maxLength dans WriteData [SWS_RDS_10487], [SWS_RDS_11324]. Pour les chemins réseau critiques en termes de latence ou soumis à un risque de blocage, des variantes surchargées de ReadData et WriteData avec indication explicite du délai d'attente en millisecondes sont disponibles [SWS_RDS_11310], [SWS_RDS_11323], [SWS_RDS_11325]. Cela permet d'intercepter de manière déterministe les entités distantes non réactives ou les engorgements de tampons réseau AUTOSAR_AP_EXP_InterfacesGuidelines p. 41.

Streaming quasi temps réel avec l'IEEE 1722 (AVTP)

Pour les flux multimédias et de capteurs isochrones et déterministes, RDS met à disposition des classes modèles spécialisées pour consommateurs et producteurs selon l'IEEE 1722 [SWS_RDS_90312], [SWS_RDS_90323]. La classe ara::rds::IEEE1722RawDataStreamConsumer<T> agit en tant que collecteur de données et est instanciée via Create [SWS_RDS_90312]. Au moyen de Connect, elle se lie au flux associé (avec filtrage de la MAC multicast, du VLAN et du Stream-ID) AUTOSAR_AP_EXP_SWArchitecture p. 203, afin de lire ensuite via ReadData jusqu'à maxNumberOfDatagrams datagrammes structurés sous la forme de std::vector<T> [SWS_RDS_90319], [SWS_RDS_90321]. De manière analogue, ara::rds::IEEE1722RawDataStreamProducer<T> prend en charge la génération et l'envoi de trames AVTP via WriteData(std::vector<T>) [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90332].

Les types de datagrammes forment une hiérarchie d'héritage orientée objet standardisée AUTOSAR_AP_SWS_RawDataStream p. 39. La base de toutes les trames est IEEE1722Datagram avec champ de données utiles data et indication de longueur stream_data_length [SWS_RDS_90226], [SWS_RDS_90227], [SWS_RDS_90228]. Dérivée de celle-ci, IEEE1722DatagramAVTPDUCommonHeaderFields encapsule des informations d'en-tête générales telles que avtpStreamDataSubtype, headerSpecific et le protocole version [SWS_RDS_90230], [SWS_RDS_90231], [SWS_RDS_90232], suivie de IEEE1722DatagramAVTPDUCommonStreamHeaderFields avec horodatages (avtp_timestamp), identification de flux (unique_id, mac_address) et numéros de séquence de paquets (sequenceNum) [SWS_RDS_90235], [SWS_RDS_90237], [SWS_RDS_90240].

Des spécialisations concrètes de sous-types reposent sur cette base commune : IEEE1722DatagramRVF pour les données vidéo brutes avec paramètres de pixels, taux de rafraîchissement d'images et informations de lignes (pixel_format, pixel_depth, frame_rate, colorspace, total_lines) [SWS_RDS_90276], [SWS_RDS_90278], [SWS_RDS_90285], [SWS_RDS_90286], [SWS_RDS_90287] ; IEEE1722DatagramAAF pour les formats audio tels que PCM ou AES3 (channels_per_frame, bit_depth, aes3_data_type_h) [SWS_RDS_90262], [SWS_RDS_90266], [SWS_RDS_90267], [SWS_RDS_90270] ; IEEE1722DatagramCRF pour la synchronisation et la transmission d'horloge sur TSN (base_frequency, timestamp_interval, pull) [SWS_RDS_90295], [SWS_RDS_90297], [SWS_RDS_90302], [SWS_RDS_90303] ; ainsi que IEEE1722Datagram61883_IIDC pour les transports de caméras industrielles [SWS_RDS_90245], [SWS_RDS_90260] et IEEE1722DatagramNTSCF pour les formats de commande non critiques en temps [SWS_RDS_90306], [SWS_RDS_90310].

Diagramme de séquence : cycle d'interaction pour le streaming audio/vidéo IEEE 1722 (producteur et consommateur). Sources : [SWS_RDS_90312], [SWS_RDS_90319], [SWS_RDS_90320], [SWS_RDS_90321], [SWS_RDS_90323], [SWS_RDS_90330], [SWS_RDS_90331], [SWS_RDS_90332], AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221

Diagramme de classes : hiérarchie d'héritage des datagrammes IEEE 1722 dans le sous-système ara::rds. Sources : [SWS_RDS_90226], [SWS_RDS_90230], [SWS_RDS_90235], [SWS_RDS_90245], [SWS_RDS_90262], [SWS_RDS_90276], [SWS_RDS_90295], [SWS_RDS_90306], AUTOSAR_AP_SWS_RawDataStream p. 39

Métamodélisation et déploiement de manifeste

Dans le métamodèle de manifeste AUTOSAR, la séparation entre la conception de l'application et le déploiement spécifique à la plateforme est préservée AUTOSAR_AP_TPS_ManifestSpecification p. 254. L'élément de base abstrait AbstractRawDataStreamInterface spécialise PortInterface et se ramifie en interfaces concrètes RawDataStreamClientInterface et RawDataStreamServerInterface AUTOSAR_AP_TPS_ManifestSpecification p. 254. Au niveau du déploiement, un EthernetRawDataStreamClientMapping ou EthernetRawDataStreamServerMapping associe les ports logiciels à des points de terminaison de communication physiques tels que ApApplicationEndpoint, des adresses IP et des numéros de port AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850.

Le manifeste permet des scénarios d'intégration flexibles pour la topologie du système : aussi bien des modèles AUTOSAR entièrement formalisés, dans lesquels le client et le serveur sont reliés au sein de la même conception ARXML AUTOSAR_TPS_ManifestSpecification p. 656, que des configurations asymétriques. Dans ces scénarios asymétriques, seul le client ou seul le serveur est modélisé dans le modèle, tandis que l'entité distante respective est connectée par le biais d'identifiants statiques tels que remoteServerConfig ou remoteClientConfig AUTOSAR_TPS_ManifestSpecification p. 660, AUTOSAR_TPS_ManifestSpecification p. 661. Pour les flux AVTP, le EthernetMacRawDataStreamMapping associe directement les ports et les processus aux points de terminaison MAC et aux priorisations VLAN AUTOSAR_AP_TPS_ManifestSpecification p. 854, conformément aux définitions du modèle de système IEEE1722TpConnection, IEEE1722TpAvConnection, IEEE1722TpAafConnection et IEEE1722TpRvfConnection AUTOSAR_CP_TPS_SystemTemplate p. 705, AUTOSAR_CP_TPS_SystemTemplate p. 708, AUTOSAR_CP_TPS_SystemTemplate p. 716.

Diagramme de contexte : relations du métamodèle AUTOSAR entre interface de port, mappage et déploiement de transport. Sources : [SWS_RDS_10482], [SWS_RDS_11312], AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851, TPS_ManifestSpecification p. 850

Comportement en cas d'erreur

Le traitement des erreurs dans RDS suit l'approche d'évaluation des erreurs de l'AUTOSAR Adaptive Platform via ara::core::Result et ara::core::ErrorCode [SWS_RDS_10484], [SWS_RDS_11299]. Toutes les méthodes d'API susceptibles d'échouer – notamment Create, Connect, WaitForConnection, ReadData et WriteData – sont déclarées en tant que noexcept et renvoient des codes d'erreur via le type de retour ara::core::Result [SWS_RDS_10482], [SWS_RDS_10484], [SWS_RDS_11318]. Les états d'erreur spécifiques au module sont gérés dans l'énumération ara::rds::RdsErrc [SWS_RDS_12367], laquelle peut être référencée via l'alias de type ara::rds::RdsErrorDomain::Errc [SWS_RDS_11326].

Le module définit à cet effet le domaine d'erreur RdsErrorDomain, dont l'instance est obtenue via GetRdsErrorDomain() [SWS_RDS_11298]. La construction par défaut de RdsErrorDomain est explicitement supprimée [SWS_RDS_11294]. Les descriptions d'erreur et le nom de domaine peuvent être lus via les méthodes virtuelles Message(CodeType) et Name() [SWS_RDS_11295], [SWS_RDS_11296]. La fonction de fabrique MakeErrorCode permet de créer des objets d'erreur typés à partir d'un code RdsErrc et de données supplémentaires [SWS_RDS_11299]. Pour les environnements dans lesquels les exceptions C++ sont activées, le module fournit l'exception ara::rds::RdsException [SWS_RDS_11292], [SWS_RDS_11327], qui peut être levée via RdsErrorDomain::ThrowAsException [SWS_RDS_11297].

Preuves détaillées supplémentaires

L'architecture et les interfaces de RDS sont ancrées dans les documents de spécification centraux d'AUTOSAR. La définition fonctionnelle des interfaces C++ pour les flux basés sur IP et les mécanismes d'erreur repose sur AUTOSAR_AP_SWS_RawDataStream [SWS_RDS_10482], [SWS_RDS_11312], [SWS_RDS_12367]. Les modèles d'architecture, les conceptions de classes et les scénarios de séquence pour le streaming IEEE 1722 sont documentés dans AUTOSAR_AP_EXP_SWArchitecture AUTOSAR_AP_EXP_SWArchitecture p. 74, AUTOSAR_AP_EXP_SWArchitecture p. 203, AUTOSAR_AP_EXP_SWArchitecture p. 221. La modélisation formelle des interfaces et du déploiement s'effectue via AUTOSAR_AP_TPS_ManifestSpecification AUTOSAR_AP_TPS_ManifestSpecification p. 254, AUTOSAR_AP_TPS_ManifestSpecification p. 851 ainsi que les modèles de système sous-jacents pour les connexions de transport Ethernet dans AUTOSAR_CP_TPS_SystemTemplate AUTOSAR_CP_TPS_SystemTemplate p. 705.