classe ara::tsync::ProviderTimeBaseValidationNotification

La classe abstraite ara::tsync::ProviderTimeBaseValidationNotification sert d'interface de rappel pour la mise à disposition de données de mesure enregistrées d'une base de temps à une application de validation. Les implémentations reçoivent via SetMasterTimingData des blocs de mesure du Time Master [SWS_TS_00421] ainsi que via SetPdelayResponderData des données de mesure du Pdelay Responder [SWS_TS_00423]. Les méthodes sont spécifiées comme noexcept, mais ne sont pas sûres au niveau des threads, raison pour laquelle les appels concurrents sur une même instance doivent être évités.

plus ›

Contexte

La classe ara::tsync::ProviderTimeBaseValidationNotification agit comme une interface de rappel abstraite pour la validation de bases de temps au sein du module de synchronisation. Via cette interface, une application de validation réceptrice est notifiée dès que de nouveaux blocs de données de mesure enregistrés sont disponibles pour une base de temps surveillée. L'interface définit des points de transmission pour des données de mesure spécifiques de l'horloge maîtresse (Time Master) selon [SWS_TS_00421] ainsi que pour des données de mesure du mécanisme de réponse au délai (Pdelay Responder) selon [SWS_TS_00423]. Les partenaires d'interaction sont typiquement ici le mécanisme fournisseur interne de la pile de synchronisation horaire en tant que source de données, ainsi qu'une instance de validation côté application qui évalue les données temporelles acquises.

Cycle de vie et concurrence

En tant qu'interface abstraite, ara::tsync::ProviderTimeBaseValidationNotification est dérivée et implémentée par l'application de validation concrète. La durée de vie de l'implémentation instanciée relève de la responsabilité de l'application. La classe possède un destructeur virtuel par défaut, déclaré comme sûr vis-à-vis des exceptions (noexcept) [SWS_TS_01301]. Cela garantit que les instances de classes dérivées peuvent être détruites de façon polymorphe et sûre du point de vue des ressources lors de leur démontage. Concernant la concurrence, les méthodes de notification sont explicitement classées comme non sûres pour les threads (non_threadsafe) [SWS_TS_00421], [SWS_TS_00423]. Cela signifie que les appels de SetMasterTimingData et SetPdelayResponderData pour la même instance ne doivent pas être effectués sans protection à partir de threads concurrents ; le fournisseur de base de temps appelant devrait émettre ces appels de manière séquentielle, ou l'application doit assurer une synchronisation. Question Q-8f59bb65825ead66 (ouverte)

Parcours d'utilisation

Le déroulement typique commence par la mise à disposition d'une classe dérivée de ara::tsync::ProviderTimeBaseValidationNotification par l'application de validation. L'instance devrait être enregistrée auprès du fournisseur de base de temps afin de s'abonner aux données de mesure correspondantes. Question Q-0ddb9ee8a3e8f381 (ouverte) Dès que la pile horaire a achevé de nouveaux cycles de mesure de la base de temps, elle délivre les blocs acquis via les méthodes purement virtuelles de l'interface. Pour l'analyse du Time Master, l'appel de SetMasterTimingData a lieu avec le paramètre measurementData de type TimeMasterMeasurementType [SWS_TS_00421]. Si des données de mesure relatives à la mesure du temps de propagation du signal sont disponibles pour la base de temps, le fournisseur les transmet via SetPdelayResponderData avec le paramètre measurementData de type PdelayResponderMeasurementType [SWS_TS_00423]. Une fois l'opération de surveillance terminée, l'application détruit l'instance de manière ordonnée via le destructeur virtuel [SWS_TS_01301].

Diagramme de séquence : notification typique d'une application de validation concernant de nouveaux blocs de données de mesure de base de temps. Sources : [SWS_TS_00421], [SWS_TS_00423], [SWS_TS_01301]

Scénarios d'erreur et conditions aux limites

SetMasterTimingData ainsi que SetPdelayResponderData sont tous deux spécifiés comme noexcept et possèdent la classification exception safe [SWS_TS_00421], [SWS_TS_00423]. Les implémentations de cette interface ne doivent donc propager aucune exception vers le fournisseur de synchronisation appelant. Les méthodes ne renvoient aucune valeur de retour (void) ; un retour d'information sur des données de mesure erronées ou non plausibles ne s'effectue donc pas directement via l'appel de méthode. Comme l'interface est déclarée comme non_threadsafe, un appel concurrent sans synchronisation externe mène à un comportement indéfini. Une précondition pour la réception des données est un objet intact, dont la durée de vie doit être maintenue pendant toute la période de mise à disposition du rappel jusqu'à la destruction via le destructeur [SWS_TS_01301].