Synchronisation de l'heure

La plate-forme AAOS Software Defined Vehicle (SDV) définit des mécanismes standards pour le reporting des sources de temps à partir des unités de contrôle électronique (ECU) et des surfaces standards pour exposer les informations temporelles dans les instances SDV. Cette page fournit des informations et des conseils sur la norme SDV.

Architecture de l'horloge

La plate-forme SDV comporte deux horloges standards :

  • Horloge UTC : il s'agit de l'horloge standard du temps universel coordonné. SOME/IP fournit généralement ces informations des ECU à l'exécution de la plate-forme. Les cas d'utilisation incluent la fraîcheur des certificats, les diagnostics et le V2X.

  • Horloge monotone du réseau : il s'agit d'un signal d'horloge non décroissant et très précis fourni par les ECU que l'architecture globale du véhicule utilise pour s'assurer que les événements sont coordonnés. Les ECU fournissent cette information à la plate-forme SDV via gPTP. Cette horloge est également appelée horloge stable.

Les horloges de la plate-forme SDV doivent répondre à des exigences architecturales spécifiques :

  • Distribution de l'horloge : chaque instance de VM a accès au même signal d'horloge monotone fourni par les ECU.

  • Intégrité de l'horloge : l'entrée d'horloge monotone du réseau est censée être une source fiable pour coordonner les événements entre les services. La protection contre les éventuelles failles du système, comme les attaques par relecture ou l'inversion temporelle, repose sur l'intégrité de l'horloge monotone.

  • Utilisation des alarmes : les API d'horloge de la plate-forme SDV ne doivent pas être utilisées pour les événements à haute fréquence (> 100 Hz) ou à faible latence (< 10 ms) entre la planification et l'heure de l'événement. Les API à haute fréquence ou à faible latence doivent utiliser un pilote de noyau.

API Clock

L'horloge monotone du réseau est exposée via l'API clock_gettime(3) standard :

// Network monotonic clock uses standard Linux API.
// This is represented as a dynamic clock in clock_gettime(3)
clock_gettime(clockid_t id, &timespec)

Cette horloge est fournie à toutes les VM via un mécanisme de réseau PTP et est enregistrée en tant qu'horloge dynamique à des fins clock_gettime(3).

L'horloge UTC est représentée par CLOCK_REALTIME dans clock_gettime(3).

Pilote d'appareil facultatif

Les OEM ont la possibilité d'exposer un bloc d'appareils Linux pour des propriétés de temps supplémentaires. Exposez-le avec la gestion des autorisations via sepolicy :

# in device/OEM/target/sepolicy/time/file_contexts
/dev/sdvtime u:object_r:time_device:s0

Les OEM sont responsables du développement et des capacités du pilote de périphérique Linux personnalisé qui expose les API au bloc d'appareil.

Notifications et rappels

Les notifications et les rappels pour les composants temporels dans SDV sont des fonctionnalités utilisateur fournies par l'OEM. La plate-forme SDV ne fournit pas d'API spécifiques pour ces fonctions.

Il doit y avoir un service OEM maximum par VM nécessitant une fonctionnalité de synchronisation de l'heure qui gère toutes les modifications d'heure pertinentes à surveiller. Par exemple, lorsque l'état approuvé de la source de temps actuelle change :

  • Les changements d'état de la source de temps sont des événements de basse fréquence. Un service OEM peut donc vérifier les changements par interrogation, par exemple une fois par minute.

  • Les ECU communiquent l'état de confiance de l'horloge UTC sur le réseau, par exemple via SOME/IP.

  • Un service OEM publie des sujets Data Tunnel spécifiques pour informer les abonnés de ces modifications.

  • Les OEM personnalisent la règle d'autorisation pour les services afin de déterminer lesquels peuvent s'abonner à ces thèmes Data Tunnel pour écouter les changements d'état temporel fiables.

État et gestion des erreurs

Les codes d'erreur suivent les conventions des API Linux standards concernées, par exemple :

  • Si clock_gettime() échoue, -1 est renvoyé et errno est défini. Cela implique que l'opération d'horloge n'est pas prise en charge ou que la source d'horloge sous-jacente n'est pas prête.

  • Si fopen() échoue, un pointeur nul est renvoyé et errno est défini, ce qui implique que le périphérique de bloc n'est pas disponible.

  • Si un appel ioctl() échoue, -1 est renvoyé et errno est défini. Cela implique que le code de requête spécifié n'a pas de réponse correspondante du pilote sous-jacent.