classe ara::tsync::ConsumerTimeBaseValidationNotification

L’interface ara::tsync::ConsumerTimeBaseValidationNotification informe les applications consommatrices de nouveaux blocs de données de mesure disponibles d’une base de temps. Via les méthodes de rappel SetSlaveTimingData [SWS_TS_00420] et SetPdelayInitiatorData [SWS_TS_00422], le système transmet des données détaillées de synchronisation et de validation pour le Time Slave ainsi que l’initiateur pDelay. Les développeurs d’applications dérivent de la classe, implémentent le traitement des données et doivent veiller à ne lever aucune exception, car toutes les méthodes sont spécifiées comme noexcept et sûres face aux exceptions. En outre, la classification en tant que non_threadsafe requiert une synchronisation côté application lors des accès concurrents.

plus ›

Contexte

La classe ara::tsync::ConsumerTimeBaseValidationNotification constitue une interface de rappel dans le module tsync de l’AUTOSAR Adaptive Platform. Son rôle consiste à informer une application consommatrice dès que de nouveaux blocs de données enregistrés sont disponibles pour une base de temps surveillée.

Trois composants principaux participent à cette interaction :

• Base de temps du module tsync : acquiert en continu des mesures de temps et de synchronisation dans le réseau de communication.
• Interface ConsumerTimeBaseValidationNotification : définit les points de transfert pour les blocs de données de mesure enregistrés via les méthodes SetSlaveTimingData [SWS_TS_00420] et SetPdelayInitiatorData [SWS_TS_00422].
• Application consommatrice : implémente les méthodes de rappel, prend en charge les valeurs de mesure fournies et effectue la validation fonctionnelle de la base de temps.

Cette structure permet de découpler proprement la logique de validation spécifique à l'application de l'enregistrement interne à la plateforme des données temporelles.

Cycle de vie

En tant que classe d'interface abstraite comportant des méthodes purement virtuelles, ara::tsync::ConsumerTimeBaseValidationNotification ne peut pas être instanciée directement. Une application consommatrice dérive une classe concrète et implémente les méthodes requises.

La création et la propriété relèvent entièrement de la responsabilité de l'application consommatrice. Vraisemblablement, l'application crée l'objet de rappel durant sa phase d'initialisation et le lie à la base de temps correspondante du service tsync. Question Q-a423ce4cbd4eeaaa (ouverte)

Pour la destruction, la classe fournit un destructeur virtuel : virtual ~ConsumerTimeBaseValidationNotification() noexcept = default; [SWS_TS_01300]. La déclaration en tant que destructeur virtuel garantit que les instances de classes dérivées peuvent être libérées via des pointeurs de classe de base de manière sûre du point de vue des types et sans fuite de ressources.

En ce qui concerne la concurrence, les méthodes de notification SetSlaveTimingData [SWS_TS_00420] et SetPdelayInitiatorData [SWS_TS_00422] sont spécifiées comme non_threadsafe. Dans la mesure où l'appel par le service de plateforme devrait avoir lieu dans le contexte d'un thread d'arrière-plan, il incombe à l'implémentation côté application de sécuriser elle-même les accès aux ressources applicatives partagées. Question Q-1b857df043504eec (ouverte)

Parcours d'utilisation

Le déroulement typique pour l'utilisation de la notification de validation comprend les étapes suivantes :

1. Implémentation : l'application consommatrice implémente une classe dérivée de ara::tsync::ConsumerTimeBaseValidationNotification.
2. Réception des données de mesure de l'esclave temporel : dès qu'un nouveau bloc de données de mesure a été enregistré pour l'esclave temporel de la base de temps, le service horaire appelle la méthode SetSlaveTimingData [SWS_TS_00420] et transmet les données de validation détaillées via le paramètre measurementData de type TimeSlaveMeasurementType.
3. Réception des données de mesure de l'initiateur pDelay : si de nouvelles données de mesure sont disponibles pour l'initiateur pDelay, l'appel de SetPdelayInitiatorData [SWS_TS_00422] a lieu avec les données de temporisation détaillées dans PdelayInitiatorMeasurementType.
4. Traitement : l'application consommatrice évalue les blocs de données transmis afin de détecter des erreurs de synchronisation ou des écarts de temps d'exécution.
5. Libération de l'objet : lors de la fin de la surveillance, l'instance est détruite via le destructeur virtuel [SWS_TS_01300].

Diagramme de séquence : transmission de blocs de données de mesure acquis pour l'esclave temporel et l'initiateur pDelay à l'implémentation consommatrice. Sources : [SWS_TS_00420], [SWS_TS_00422].

Scénarios d'erreur

Les méthodes d'interface sont conçues pour une robustesse maximale et des appels déterministes :

• Sécurité vis-à-vis des exceptions : toutes les fonctions membres – SetSlaveTimingData [SWS_TS_00420], SetPdelayInitiatorData [SWS_TS_00422] et le destructeur [SWS_TS_01300] – sont déclarées avec noexcept et spécifiées comme sûres vis-à-vis des exceptions (exception safe). Les méthodes de substitution dans l'application consommatrice ne doivent propager aucune exception vers l'extérieur, car cela entraîne l'arrêt immédiat du programme.
• Absence de canaux de retour : étant donné que les méthodes de rappel possèdent le type de retour void, les erreurs de traitement au sein de la logique applicative ne peuvent pas être signalées au module tsync. L'application doit gérer et journaliser de manière autonome ses éventuels états d'erreur en interne.
• Risques de concurrence : en raison de la propriété non_threadsafe ([SWS_TS_00420], [SWS_TS_00422]), il convient d'éviter que plusieurs blocs de données ne soient traités en parallèle sans verrouillage côté application. Interprétation : l'objet de rappel doit en outre rester valide pendant toute la durée de l'enregistrement auprès de la base de temps afin d'empêcher tout accès fatal à une mémoire déjà libérée. Question Q-934e451f6a0099c1 (ouverte)