module ara::tsync — Time Synchronization

Le cluster fonctionnel Time Synchronization met à disposition de l'AUTOSAR Adaptive Platform des bases de temps cohérentes et synchronisées à l'échelle du réseau (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Par le biais d'interfaces standardisées, les applications adaptatives interrogent des états temporels atomiques ou injectent, en tant qu'horloges maîtresses actives, de nouvelles corrections de temps et de dérive dans l'ensemble du système. Parallèlement, des callbacks de notification enregistrés surveillent en continu les changements d'état ainsi que les sauts temporels des horloges sous-jacentes ([SWS_TS_01009]). Des mécanismes avancés de validation des données de mesure et des valeurs de fraîcheur protègent en outre l'intégrité temporelle contre les erreurs de transmission et les manipulations.

plus ›

Le cluster fonctionnel Time Synchronization (tsync) met à disposition des bases de temps cohérentes et synchronisées à l'échelle du réseau sur l'AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_TimeSynchronization p. 16). En tant que service d'arrière-plan basé sur un démon, il fait abstraction des mécanismes de synchronisation spécifiques au matériel et aux bus (tels que le gPTP IEEE 802.1AS) et alimente les clusters centraux tels que Log and Trace, l'Intrusion Detection System Manager (IdsM) ainsi que les services de mise à jour via des interfaces standardisées (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagramme de contexte : intégration du cluster Time Synchronization basé sur un démon dans l'AUTOSAR Adaptive Platform et ses relations d'interface avec les clusters consommateurs et les applications. Sources : AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Pour l'accès en lecture, les applications utilisent l'interface SynchronizedTimeBaseConsumer ([SWS_TS_01001]). La méthode GetTimeWithStatus() renvoie un instantané atomique de type SynchronizedTimeBaseStatus, à partir duquel l'heure globale, l'heure locale continue de création, l'état de synchronisation ainsi que les UserData reçues peuvent être récupérés ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). Pour éviter l'attente active (polling), les applications s'enregistrent via des callbacks de notification pour les changements d'état et les sauts temporels ([SWS_TS_01010], [SWS_TS_01014]).

Diagramme de séquence : déroulement d'une interrogation temporelle synchrone via l'interface consommateur et lecture des propriétés atomiques de l'instantané. Sources : [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Les applications assurant la base de temps contrôlent le comportement du système via SynchronizedTimeBaseProvider : SetTime() déclenche des transmissions immédiates sur le bus, tandis que UpdateTime() ajuste d'abord l'horloge localement ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Des mécanismes d'accompagnement tels que Time Validation ([SWS_TS_00420], [SWS_TS_00421]) et la gestion native des valeurs de fraîcheur (FVM) protègent contre les erreurs de dérive et de rejeu ([SWS_TS_14198]). En cas d'erreur, des codes TsyncErrc (p. ex. kDaemonConnectionLost) signalent des pertes de connexion, tandis qu'une absence de messages de synchronisation est indiquée par kTimeOut dans l'objet d'état ([SWS_TS_00901], [SWS_TS_01050]).

plus ›

Le cluster fonctionnel Time Synchronization (tsync) met à disposition des bases de temps coordonnées et synchronisées à l'échelle du réseau sur l'AUTOSAR Adaptive Platform et découple les processus applicatifs des protocoles de synchronisation temporelle spécifiques au matériel et aux bus (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Le système constitue le fondement informatique des systèmes distribués, pour lesquels des séquences d'événements cohérentes, des journaux de trace reproductibles et des cycles de calcul déterministes doivent être garantis au-delà des frontières des calculateurs (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagramme de contexte : intégration du cluster Time Synchronization basé sur un démon dans l'AUTOSAR Adaptive Platform et ses relations d'interface avec les clusters consommateurs et les applications. Sources : AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Limites du système et rôle du cluster Time Synchronization basé sur un démon

L'architecture fonctionnelle de Time Synchronization est conçue sous la forme d'un cluster basé sur un démon (daemon-based), qui opère en arrière-plan en tant que service de plateforme central (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Ce démon interagit directement avec les interfaces du système d'exploitation sous-jacent et traite les données de synchronisation temporelle basées sur le réseau telles que gPTP (IEEE 802.1AS) ou les synchronisations temporelles de bus classiques (AUTOSAR_FO_PRS_TimeSyncProtocol p. 68). Vis-à-vis du contexte applicatif, le cluster encapsule complètement la compensation mathématique de dérive et d'offset des horloges matérielles.

De nombreux clusters fonctionnels centraux de l'Adaptive Platform accèdent à tsync via des interfaces de service standardisées (AUTOSAR_AP_EXP_SWArchitecture p. 83). Par exemple, Log and Trace s'appuie sur la base de temps synchronisée pour doter les événements de journalisation et DLT à l'échelle du système d'horodatages globaux fiables (AUTOSAR_AP_EXP_SWArchitecture p. 59 ; AUTOSAR_AP_SWS_LogAndTrace p. 15). De même, des modules critiques pour la sécurité tels que l'Intrusion Detection System Manager (IdsM) ainsi que les services de mise à jour (UCM et Vehicle UCM) s'appuient impérativement sur l'interface C++ de SynchronizedTimeBaseConsumer pour générer des rapports probants sur le plan médico-légal et piloter des transactions de mise à jour cohérentes par-delà les frontières des calculateurs (AUTOSAR_AP_EXP_SWArchitecture p. 125 ; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 16 ; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 11).

Interfaces consommatrices et interrogations temporelles avec état

Pour l'accès en lecture à une base de temps synchronisée, les applications utilisent la classe d'interface SynchronizedTimeBaseConsumer ([SWS_TS_01001]). La classe implémente la sémantique de déplacement ([SWS_TS_01003], [SWS_TS_01004]), mais exclut explicitement toute copie ([SWS_TS_01005], [SWS_TS_01006]). Au moment de l'exécution, GetRateDeviation() permet la lecture directe de l'écart de fréquence actuel de l'horloge ([SWS_TS_01008]).

L'élément central de chaque interrogation synchrone est l'opération GetTimeWithStatus() ([SWS_TS_01009]). Au lieu de renvoyer des valeurs de temps brutes isolées, la méthode génère un instantané intrinsèquement cohérent de type SynchronizedTimeBaseStatus (EXP_SWArchitecture p. 81). Cet instantané fige l'instant exact de création en heure globale ([SWS_TS_01055]) ainsi qu'en heure locale continue via GetCreationLocalTime() ([SWS_TS_14176]). Les points temporels sont ici représentés dans le type chrono C++ standardisé Timestamp avec une résolution en nanosecondes sur la base de std::int64_t ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

À partir de l'instantané, il est possible de déterminer, outre l'heure, l'état de communication et de synchronisation via GetSynchronizationStatus() ([SWS_TS_01053]), un éventuel saut temporel survenu via GetLeapJump() ([SWS_TS_01054]) ainsi que des données utilisateur spécifiques à l'application via GetUserData() ([SWS_TS_01056]). Il n'existe pas de constructeur par défaut pour l'objet d'état ([SWS_TS_01061]), tandis que les constructeurs de déplacement et de copie garantissent son transfert thread-safe aux routines applicatives appelantes ([SWS_TS_01057], [SWS_TS_01058]).

Diagramme de séquence : déroulement d'une interrogation temporelle synchrone via l'interface consommateur et lecture des propriétés atomiques de l'instantané. Sources : [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Notifications basées sur les événements et surveillance de la synchronisation

Pour éviter les boucles d'attente active (polling), SynchronizedTimeBaseConsumer met à disposition un patron observateur piloté par les événements via des callbacks de notification (AUTOSAR_AP_EXP_SWArchitecture p. 226). Les applications s'enregistrent avec des callbacks sécurisés du point de vue des types pour des changements d'état spécifiques ([SWS_TS_14221], [SWS_TS_14222]). À chaque nouvel enregistrement, le nouveau notificateur écrase le gestionnaire précédemment enregistré ([SWS_TS_01010]).

Pour les changements d'état agrégés, il existe RegisterStatusChangeNotifier() ([SWS_TS_01010]), complété par UnregisterStatusChangeNotifier() ([SWS_TS_01011]). Si une application réagit principalement au changement de l'état de synchronisation (p. ex. perte de la connexion au Grandmaster), RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]) est utilisé. Les sauts temporels vers le futur (kTimeLeapFuture) ou le passé (kTimeLeapPast) qui dépassent un seuil configuré sont signalés via RegisterTimeLeapNotifier() ([SWS_TS_01014], [SWS_TS_01051]).

Pour les applications mécatroniques de haute précision, RegisterTimePrecisionMeasurementNotifier() est en outre disponible ([SWS_TS_01018]). Le callback transmet une structure TimePrecisionMeasurement qui contient des valeurs exactes en secondes et en nanosecondes immédiatement avant (locSeconds, locNanoSeconds) et après la synchronisation (glbSeconds, glbNanoSeconds), le délai d'acheminement calculé pathDelay ainsi que le masque de bits timeBaseStatus ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). Le cluster Time Synchronization n'effectue ici aucune gestion de file d'attente (queuing) ; les mises en mémoire tampon doivent, le cas échéant, être réalisées au sein du callback de l'application ([SWS_TS_01018]).

Diagramme de séquence : enregistrement et flux de notification asynchrone lors de modifications de synchronisation et de sauts temporels. Sources : [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture p. 226

Diagramme d'état : cycle de vie de l'état de synchronisation d'une base de temps selon SWS_TS_01050. Sources : [SWS_TS_01050], AUTOSAR_SWS_TimeSync p. 25

Mise à disposition de bases de temps et ajustement de fréquence par les fournisseurs

Lorsqu'une Adaptive Application agit en tant qu'horloge maîtresse active (Time Master) – par exemple via une connexion à un récepteur GNSS ou à une horloge de référence externe –, elle utilise la classe SynchronizedTimeBaseProvider ([SWS_TS_01101]). L'interface permet la définition explicite de nouvelles valeurs de temps par le biais de deux sémantiques distinctes : SetTime() et UpdateTime() (EXP_SWArchitecture p. 80).

L'appel de SetTime() réinitialise non seulement l'heure interne de l'horloge, mais force également l'émission immédiate des messages de synchronisation mis à jour sur le bus du véhicule ([SWS_TS_01107]). En revanche, UpdateTime() met d'abord à jour l'heure exclusivement au niveau local ; la transmission sur le bus s'effectue de manière différée lors du cycle régulier suivant du protocole de transmission temporelle ([SWS_TS_01108]). Les deux méthodes acceptent, outre l'horodatage, des UserData structurées afin de distribuer des informations supplémentaires associées à la synchronisation à l'échelle du réseau ([SWS_TS_01112], [SWS_TS_01113]).

Pour l'ajustement fin des oscillateurs à quartz et l'évitement de sauts de phase brusques, SetRateCorrection() permet l'application d'un facteur relatif de correction de fréquence ([SWS_TS_01110]). En complément, GetRateDeviation() fournit l'écart d'horloge actuellement présent ([SWS_TS_01111]), tandis que GetCurrentTime() lit la valeur temporelle absolue de l'horloge indépendamment de l'état de synchronisation actuel ([SWS_TS_01109]).

Garantie de l'intégrité via Time Validation et Freshness Value Management

Dans les environnements de conduite hautement automatisés et critiques pour la sécurité, la simple reprise de valeurs de temps ne suffit pas ; l'exactitude et l'inviolabilité des horodatages doivent être validées en continu (AUTOSAR_AP_SWS_TimeSynchronization p. 38). À cette fin, tsync propose des interfaces de callback pour la Time Validation : les consommateurs s'enregistrent via RegisterTimeValidationNotification() ([SWS_TS_01016]), les fournisseurs de manière analogue via la méthode spécifique au fournisseur ([SWS_TS_01114]).

Les interfaces de validation ConsumerTimeBaseValidationNotification et ProviderTimeBaseValidationNotification transmettent des jeux de données de mesure détaillés à des applications de surveillance spécialisées ([SWS_TS_01300], [SWS_TS_01301]). Au niveau de la station maître, SetMasterTimingData() fournit l'horodatage d'égress (syncEgressTimestamp) et le numéro de séquence (sequenceId) des trames de synchronisation transmises ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). Au niveau de l'esclave, SetSlaveTimingData() transmet les horodatages d'ingress correspondants (syncIngressTimestamp), le champ de correction reçu (correctionField) ainsi que le délai de propagation mesuré (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). Pour les mesures de délai de pair à pair, SetPdelayInitiatorData() et SetPdelayResponderData() mettent intégralement à disposition les instants d'entrée et de sortie des paquets de requête et de réponse ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

Pour assurer une protection contre les attaques par rejeu et sécuriser les messages temporels transmis, la plateforme intègre le Freshness Value Management (FVM) via des interfaces natives dans l'espace de noms apext::tsync ([SWS_TS_14198], EXP_SWArchitecture p. 83). Lors du démarrage, Initialize() initialise le plugin FVM compétent ([SWS_TS_14200]). Avant l'émission, la pile appelle GetTxFreshness() pour récupérer des valeurs de compteur fraîches ([SWS_TS_14199]), tandis qu'à la réception, GetRxFreshness() est sollicité pour la vérification et l'authentification ([SWS_TS_14198]). Les données sont alors transportées via le FVContainer standardisé ([SWS_TS_14195], [SWS_TS_14196]).

Diagramme de séquence : flux de validation des données de mesure temporelles entre le maître, l'esclave et l'application de validation externe. Sources : [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization p. 38

Configuration, liaison de processus et modélisation de manifeste

L'allocation et la liaison fonctionnelle du cluster s'effectuent de manière déclarative dans les manifestes de modèle AUTOSAR (AUTOSAR_AP_TPS_ManifestSpecification p. 590). Dans le Machine Manifest, le démon de la plateforme est instancié sur une Machine concrète via l'élément de métamodèle TimeSyncModuleInstantiation et y gère les objets TimeBaseResource physiques et virtuels (AUTOSAR_AP_TPS_ManifestSpecification p. 590).

Au niveau applicatif, les processus déclarent leurs besoins en bases de temps via des prototypes de ports (RPortPrototype pour les consommateurs et PPortPrototype pour les fournisseurs) (AUTOSAR_AP_TPS_ManifestSpecification p. 599). La construction de métamodèle TimeSyncPortPrototypeToTimeBaseMapping associe ces ports, individuellement pour chaque processus, aux bases de temps définies sur la machine (TPS_ManifestSpecification p. 599 ; AUTOSAR_AP_TPS_ManifestSpecification p. 600). Au moment de l'exécution, l'instanciation dans le code s'effectue via le ara::core::InstanceSpecifier à sûreté de typage, ce qui permet à la pile de lier la base de temps configurée appropriée ([SWS_TS_01001], [SWS_TS_01101]).

Comportement en cas d'erreur

Les situations d'erreur dans le cluster de synchronisation temporelle sont signalées via le modèle d'erreur standardisé de l'Adaptive Platform (ara::core::Result et ara::core::ErrorCode) ([SWS_TS_00910]). Pour les opérations régulières sur les bases de temps, l'énumération TsyncErrc définit les codes d'erreur ([SWS_TS_00901]). Si, par exemple, la communication inter-processus avec le démon de plateforme s'interrompt, le code d'erreur kDaemonConnectionLost est renvoyé ([SWS_TS_00901]).

Le domaine d'erreur global TsyncErrorDomain permet d'inspecter les codes d'erreur ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) ou, lorsque les exceptions C++ sont activées, de les lever sous forme de TsyncException via ThrowAsException() ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). Pour le Freshness Value Management, il existe un domaine d'erreur autonome TsyncFvmErrorDomain associé à l'énumération TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). Si l'initialisation échoue, Initialize() renvoie l'erreur kFVInitializeFailed ([SWS_TS_14200]), tandis qu'en cas d'indisponibilité des compteurs pour les contrôles d'authentification, kFVNotAvailable est signalé ([SWS_TS_14202]).

Au niveau fonctionnel, le cluster ne signale pas nécessairement la perte de messages temporels par des erreurs d'API synchrones, mais marque la base de temps dans l'objet d'état avec l'état de communication kTimeOut ([SWS_TS_01050]) ou active le bit correspondant dans timeBaseStatus ([SWS_TS_01403]). Interprétation : il incomberait donc systématiquement à l'application de vérifier activement l'état de validité de l'instantané après GetTimeWithStatus() avant que les valeurs mesurées ne soient utilisées pour des boucles de régulation critiques pour la sécurité. Question Q-0cd9bb48452ae3db (ouverte)

Preuves détaillées supplémentaires

Les exigences clés et les points de spécification du module tsync peuvent être regroupés selon les axes principaux suivants :

• Interfaces d'exécution pour consommateurs et fournisseurs : les opérations de cycle de vie et d'interrogation reposent sur [SWS_TS_01001] à [SWS_TS_01019] ainsi que sur les fonctions de fournisseur [SWS_TS_01101] à [SWS_TS_01115] (EXP_SWArchitecture p. 80, EXP_SWArchitecture p. 81).
• Structures d'état et représentation temporelle : définition de SynchronizedTimeBaseStatus, SynchronizationStatus et LeapJump selon [SWS_TS_01050] à [SWS_TS_01062] ainsi que des types chrono standard selon [SWS_TS_01251] à [SWS_TS_01265].
• Validation temporelle et acquisition de données de mesure : définition des structures de mesure et des rappels de notification selon [SWS_TS_00420] à [SWS_TS_00423] ainsi que [SWS_TS_14140] à [SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization p. 38).
• Extension de sécurité FVM : authentification et contrôle de fraîcheur via les interfaces [SWS_TS_14195] à [SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture p. 83).
• Modélisation de manifeste : configuration déclarative et affectation des processus et des prototypes de ports aux bases de temps selon AUTOSAR_AP_TPS_ManifestSpecification p. 590 et AUTOSAR_AP_TPS_ManifestSpecification p. 599.