Définit les champs d'en-tête AVTPDU communs pour les datagrammes IEEE 1722 dans le module Raw Data Stream.
Contexte
Dans l'AUTOSAR Adaptive Platform, le module Raw Data Stream (RDS) met à disposition des mécanismes pour l'échange efficace de flux de données non structurés et de protocoles de streaming standardisés. La classe ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields sert, au sein de ce module, de représentation fondamentale des champs d'en-tête communs (Common Header Fields) des Audio/Video Transport Protocol Data Units (AVTPDUs) selon IEEE 1722, comme spécifié dans SWS RawDataStream §1 « IEEE 1722 Datagram ».
La structure encapsule les champs de protocole essentiels définis pour les datagrammes AVTPDU dans la norme IEEE 1722. En fait partie l'attribut version de type std::uint8_t ([SWS_RDS_90232]), qui représente la version de protocole de la norme AVTP. De plus, le champ de données avtpStreamDataSubtype de type std::uint16_t ([SWS_RDS_90230]) accueille le sous-type de la charge utile de streaming AVTP afin d'identifier le format spécifique des flux de données transportés. En complément, l'élément headerSpecific stocke, en tant que std::uint8_t ([SWS_RDS_90231]), les bits de commande et indicateurs d'en-tête de l'AVTPDU spécifiques au protocole et au format.
Tous les champs de données utiles de la classe sont déclarés sous le modificateur d'accès protected. Il en ressort l'interprétation selon laquelle ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields a vraisemblablement été conçue avant tout comme une classe de base fondamentale pour des classes de datagrammes IEEE 1722 spécialisées au sein du module RDS, plutôt que pour être directement instanciée par les utilisateurs en tant qu'objet-valeur autonome. Question Q-674fc96343869829 (ouverte)
Cycle de vie
Le cycle de vie de ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields s'aligne sur son rôle de structure d'en-tête fondamentale. L'instanciation s'effectue conjointement avec une spécialisation concrète qui hérite de cette classe de base. L'affectation et l'initialisation des attributs protégés version ([SWS_RDS_90232]), avtpStreamDataSubtype ([SWS_RDS_90230]) et headerSpecific ([SWS_RDS_90231]) sont généralement effectuées dans le constructeur de la classe dérivée.
Pour la destruction des instances, la spécification fournit explicitement un destructeur virtuel : ~IEEE1722DatagramAVTPDUCommonHeaderFields() noexcept ([SWS_RDS_90233]). La présence de ce destructeur virtuel garantit que les objets de datagramme dérivés peuvent être détruits en toute sécurité de manière polymorphique via des pointeurs ou des références vers la classe de base, sans entraîner de comportement indéfini ni de fuites de ressources. Grâce au spécificateur noexcept, il est contractuellement garanti qu'aucune exception ne peut être levée pendant le processus de destruction.
En ce qui concerne la propriété et la gestion de la mémoire, la classe est soumise aux conventions générales applicables aux objets de transfert de données dans le module RDS : les instances sont typiquement soit conservées sur la pile d'une fonction de traitement, soit gérées par des tampons de données et gestionnaires de flux de niveau supérieur. Concernant la concurrence, la structure de données n'offre aucun mécanisme de synchronisation interne. Interprétation : l'accès simultané de plusieurs threads à la même instance nécessite donc vraisemblablement une synchronisation externe par l'application appelante ou le système d'exécution environnant. Question (ouverte)
Parcours d'utilisation
Le chemin d'utilisation typique se décompose en création, remplissage et évaluation de datagrammes dans le cadre de connexions de streaming. Les champs étant protégés, les développeurs accèdent aux champs de base par l'intermédiaire de sous-classes spécialisées.
Lors de l'envoi d'un flux de données IEEE 1722, l'application ou un pipeline interne du module RDS instancie une classe de datagramme dérivée. Ensuite, les champs d'en-tête AVTPDU communs sont renseignés : le champ version ([SWS_RDS_90232]) est défini sur la version de protocole prise en charge. Le champ avtpStreamDataSubtype ([SWS_RDS_90230]) reçoit la valeur caractéristique du type de charge utile spécifique afin de permettre au récepteur de décoder le flux de données. Enfin, l'implémentation dérivée configure le champ headerSpecific ([SWS_RDS_90231]) avec les bits de contrôle directeurs requis conformément à la spécification IEEE 1722.
Lors de la réception de paquets réseau via le Raw Data Stream, le déroulement inverse s'applique : les données brutes entrantes sont désérialisées et transférées dans les attributs correspondants de la classe de datagramme dérivée. Les composants de niveau supérieur peuvent ensuite vérifier les informations d'en-tête via des interfaces polymorphiques ou des méthodes d'accès typées de la sous-classe. Après un traitement réussi et le transfert de la charge utile de l'AVTPDU vers le récepteur de destination, le datagramme est libéré, le destructeur virtuel ([SWS_RDS_90233]) garantissant la libération propre de toutes les ressources. Interprétation : la transmission sérialisée sur le réseau s'effectue vraisemblablement via des sérialiseurs en aval de la pile RDS, qui disposent l'en-tête dans le flux d'octets de manière conforme à IEEE 1722. Question Q-7f31ac02b5e4facf (ouverte)
Scénarios d'erreur
Les scénarios d'erreur lors de l'utilisation de ara::rds::IEEE1722DatagramAVTPDUCommonHeaderFields résultent principalement de valeurs erronées dans les champs d'en-tête ou d'une mauvaise gestion du cycle de vie.
Au niveau des éléments de données, des valeurs non valides peuvent entraîner des violations de protocole. Si, par exemple, une valeur de version non prise en charge par l'interlocuteur est transmise pour version ([SWS_RDS_90232]), cela peut conduire au rejet de l'ensemble de l'AVTPDU par le partenaire de communication. De même, un champ avtpStreamDataSubtype ([SWS_RDS_90230]) incorrectement défini fait que le récepteur ne peut pas affecter correctement le flux de données au décodeur adéquat. Une affectation incohérente de headerSpecific ([SWS_RDS_90231]) peut à son tour entraîner des erreurs d'interprétation concernant les indicateurs de synchronisation ou les longueurs de données.
Au niveau de C++, le destructeur virtuel ~IEEE1722DatagramAVTPDUCommonHeaderFields() noexcept ([SWS_RDS_90233]) exclut les exceptions pendant le processus de destruction. Si une classe dérivée exécute sa propre logique de traitement des erreurs pendant la libération des ressources, il convient de veiller à ce qu'aucune exception n'y soit levée non plus, afin d'éviter un arrêt immédiat du programme via std::terminate.
Ce guide est basé sur la spécification AUTOSAR Adaptive R25-11 et a été généré automatiquement.
gemini-3.8-flash-low· 2026-10-13 · Original allemand