Concepts de configuration des métriques

Les configurations de métriques définissent les campagnes de télémétrie exécutées par le service de télémétrie. Une configuration de métriques est une instance d'un message de tampon de protocole (protobuf) MetricsConfig. Les configurations de métriques spécifient comment collecter, traiter et générer des rapports sur les données. Les OEM peuvent activer les configurations de métriques via l'API du service de télémétrie. Plusieurs configurations peuvent s'exécuter simultanément.

Avant de commencer, familiarisez-vous avec l'architecture SDV, qui est une architecture orientée services dans laquelle les services publient des données sous forme de messages protobuf. Ces messages communiquent à l'aide de la pile de communication SDV via RPC ou la publication/l'abonnement.

Termes clés

Une configuration des métriques orchestre la collecte de données en définissant les sources de données, les règles de traitement et les mécanismes de reporting. L'un des principaux avantages de ce traitement en périphérie est la réduction de la consommation de données mobiles. En traitant les données à haute fréquence sur l'appareil et en n'important que les agrégats ou les insights, vous réduisez considérablement la quantité de données transmises au cloud.

La définition d'une configuration de métriques commence par la liste des sources de données à utiliser dans la configuration. Il s'agit de services qui mettent des données à disposition via la pile de communication SDV. Lorsque vous activez une configuration, le service de télémétrie se connecte à ces sources pour diffuser ou extraire les données selon les besoins.

Le cœur d'une configuration est sa capacité de traitement des données en périphérie, gérée par des agrégateurs de données avec état. Chaque agrégateur utilise un générateur de messages qui conserve une instance de message proto avec état. Chaque champ de ce message est renseigné en évaluant une expression, en définissant les données à lire à partir d'autres sources de données ou agrégateurs, et en définissant les opérations mathématiques, logiques ou d'agrégation à appliquer aux données. Vous pouvez appliquer des agrégations supplémentaires au résultat d'une expression.

Les déclencheurs sont essentiels pour contrôler ce processus. Ils peuvent se déclencher périodiquement, en réponse à de nouvelles données ou lorsque des conditions basées sur des données sont remplies. Les déclencheurs déterminent le moment où les agrégateurs évaluent leur générateur de messages et où les rapports sur les métriques sont générés. Ils peuvent également influencer le cycle de vie de la configuration, par exemple en démarrant ou en arrêtant la collecte de données.

Les rapports sur les métriques sont le résultat final. Chaque rapport inclut la charge utile de données définie par un générateur de messages, ainsi que des métadonnées telles que les codes temporels et l'ID du rapport. Vous pouvez générer des rapports à des moments spécifiques du cycle de vie d'une configuration, par exemple lorsqu'elle est activée ou désactivée. Les rapports générés sont stockés en mémoire, et le client est averti de leur récupération via le canal de notification de l'état des rapports.

La figure suivante fournit un exemple conceptuel de la façon dont les composants peuvent interagir dans une configuration de métriques :

Figure 1. Sources de données, traitement et création de rapports dans une configuration de métriques.

Composants de la configuration des métriques

Vous pouvez utiliser des configurations de métriques pour définir des tâches de collecte de données et des pipelines de traitement complexes sur l'appareil. Cette section décrit en détail les composants principaux utilisés pour définir une campagne axée sur les métriques. Les composants sont présentés dans l'ordre dans lequel les données circulent dans le système, de l'entrée à la sortie. Vous pouvez définir ces composants dans n'importe quel ordre. Le traitement des données avec des agrégateurs et la gestion du cycle de vie sont facultatifs.

• Définir des sources de données
• Traiter des données avec des agrégateurs
• Contrôler le flux d'exécution avec des déclencheurs
• Générer des rapports sur les métriques
• Gérer le cycle de vie de la collecte de données

Définir des sources de données

Les données sont à la base de toute campagne axée sur les métriques. Dans une configuration de métriques, le mécanisme de réception des données est abstrait. Vous n'avez qu'à spécifier le nom permettant d'identifier une source de données et le mode de connexion (abonnement ou à la demande). Les sources de données peuvent être n'importe quel service qui met des données à disposition via la pile de communication SDV ou qui s'enregistre dans le registre des éditeurs configurables, ce qui permet de collecter des données à partir d'applications où le middleware SDV n'est pas disponible. Chaque source de données doit avoir un nom unique dans la configuration afin de pouvoir être référencée par d'autres composants de configuration de métriques tels que les déclencheurs ou les agrégateurs. Vous pouvez configurer la façon dont il se connecte, la fréquence à laquelle il reçoit des données et fournir un objet de configuration spécifique au service.

Configuration des sources de données

Le service de télémétrie peut se connecter à une source de données de deux manières :

• Getter : cette méthode récupère les données à la demande chaque fois qu'une expression définie dans la configuration des métriques doit lire des données à partir de cette source. Cela est utile pour les sources de données qui ne fournissent pas de flux continu ou lorsque vous avez besoin d'instantanés de données peu fréquents.
• Abonnement : il s'agit de la méthode par défaut. Il établit un flux de données continu à partir de la source. Ce type de connexion est requis si vous prévoyez d'utiliser un déclencheur de données qui se déclenche lorsque de nouveaux messages arrivent de cette source.

Lorsque vous utilisez un abonnement, vous pouvez configurer les éléments suivants :

• Sous-échantillonnage : pour éviter d'ingérer des données trop fréquemment, vous pouvez définir un intervalle de temps minimal entre les messages consécutifs provenant de la même source. Si la source publie des données plus rapidement que cet intervalle, le service de télémétrie limite les notifications, et les déclencheurs de données ne s'activent que pour les messages reçus après la limitation. Cela sous-échantillonne efficacement les données.
• Récupération initiale des messages : vous pouvez configurer le service pour qu'il récupère le message le plus récent de la source lorsqu'il établit l'abonnement. Par conséquent, la source de données est immédiatement renseignée avec une valeur, si elle est disponible, au lieu d'attendre la publication du premier nouveau message. Cela est utile dans les déclencheurs ou agrégateurs conditionnels qui nécessitent un état initial ou lorsque la source de données publie rarement.

Quel que soit le type, les messages sont mis en cache en interne. Si plusieurs expressions ou agrégateurs nécessitent des données provenant de la même source au cours d'un même cycle d'évaluation, le système récupère les données une seule fois, soit à partir du cache si un nouveau message est arrivé à l'aide d'un abonnement, soit à l'aide d'un seul appel à la demande.

Traiter des données avec des agrégateurs

Alors que les sources de données fournissent des données brutes, les agrégateurs effectuent un traitement des données de périphérie avec état. Ils consomment des données provenant de sources de données ou d'autres agrégateurs, les transforment et rendent le résultat disponible pour être lu par les rapports sur les métriques ou traité ultérieurement par d'autres agrégateurs. Cela permet de créer des pipelines de traitement à plusieurs étapes, par exemple en calculant des statistiques de vitesse dans un agrégateur et en utilisant ces statistiques dans un autre composant qui détecte les habitudes de conduite.

Les agrégateurs sont déclenchés pour effectuer leurs calculs par un ou plusieurs déclencheurs. Chaque fois que l'un de ses déclencheurs se déclenche, l'agrégateur évalue ses règles et met à jour son état interne.

Vous pouvez configurer un agrégateur pour qu'il réinitialise son état une fois que sa valeur a été lue par un autre composant. Cela est utile pour calculer des statistiques sur des périodes non chevauchantes.

Un compilateur de messages définit la structure et la logique d'un agrégateur. Un générateur de messages spécifie comment construire une instance de message proto en décrivant comment générer des données pour chacun de ses champs. Pour chaque champ, une expression définit comment lire les données des sources de données et des agrégateurs, et comment appliquer des opérations à ces données. Vous pouvez également appliquer une agrégation, qui est une opération de calcul ou de collecte appliquée aux résultats de l'expression au fil du temps.

Les types d'agrégation suivants sont acceptés :

• Mathématiques : calcule les statistiques (moyenne, minimum, maximum, somme, écart-type et delta) sur les valeurs renvoyées par une expression sur chaque déclencheur. Le delta correspond à la différence entre la valeur numérique actuelle et la valeur numérique précédente renvoyée par une expression.
• Liste : collecte les valeurs renvoyées par une expression dans une liste. Vous pouvez limiter la taille de la liste pour créer une fenêtre glissante (tampon en anneau) des valeurs récentes.
• Nombre : cas particulier où aucune expression n'est spécifiée. Comptabilise le nombre de fois où le champ est évalué (c'est-à-dire le nombre de fois où l'agrégateur ou le rapport sont déclenchés).
• Transfert : utilise directement le résultat d'une expression, sans appliquer d'agrégation. Cela s'avère utile dans les configurations de rapports pour accéder aux valeurs finales des agrégateurs.

La figure suivante est un schéma conceptuel illustrant l'évaluation des agrégateurs :

Figure 2. Évaluation des agrégateurs.

Effectuer des calculs ou définir des conditions à l'aide d'expressions

Les expressions sont utilisées dans les générateurs de messages et les déclencheurs conditionnels pour effectuer des calculs ou définir des conditions. Lorsque vous utilisez le générateur de configuration des métriques (MCG) pour créer des objets JSON de configuration des métriques, les expressions sont écrites sous forme de chaînes lisibles par l'homme qui utilisent la notation par points pour accéder aux champs de la source de données (par exemple, vehicle_speed.speed_value) et appliquer un large éventail d'opérations. MCG traduit ces chaînes en une structure arborescente optimisée, analogue à un arbre de syntaxe abstraite (AST), pour une évaluation efficace sur l'appareil dans le message protobuf MetricsConfig final.

Opérateurs et fonctions

Les expressions sont compatibles avec l'ensemble d'opérateurs et de fonctions suivant :

• Arithmétique : prend en charge l'addition, la soustraction (binaire et unaire), la multiplication, la division, le modulo et la puissance.
• Logique : compatible avec AND, OR, NOT et XOR.
• Relationnel : permet de vérifier l'égalité et de comparer les valeurs (supérieur à/inférieur à).
• Liste : vérifie si une liste contient ou non une valeur spécifique.
• Timestamp : renvoie le code temporel au moment de l'évaluation en microsecondes. Le type d'horloge peut être une horloge en temps réel, une heure monotone depuis le démarrage (y compris le temps de suspension) ou une heure monotone depuis le démarrage ou la dernière reprise.
• Valeur absolue : renvoie la valeur absolue d'un nombre.
• Arrondi : arrondit à l'entier le plus proche (round), renvoie le plus grand entier inférieur ou égal à un nombre (floor) ou renvoie le plus petit entier supérieur ou égal à un nombre (ceil).

Voici un exemple d'expression qui lit deux sources de données et renvoie true si la vitesse du véhicule dépasse 100 km/h et qu'aucun avertissement de pression des pneus n'est affiché :

(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false

Contrôler le flux d'exécution avec des déclencheurs

Les déclencheurs sont les orchestrateurs d'une configuration de métriques. Ils contrôlent le moment où les données sont traitées et les rapports générés. Chaque déclencheur doit avoir un nom unique.

Il existe trois types de déclencheurs :

• Déclencheurs de données : ils se déclenchent lorsqu'une source de données avec une connexion par abonnement publie un nouveau message (après sous-échantillonnage, le cas échéant).
• Déclencheurs périodiques : ils se déclenchent à un intervalle de temps fixe.
• Déclencheurs conditionnels : ils se déclenchent lorsqu'une condition logique spécifiée est remplie.

Déclencheurs conditionnels

Les déclencheurs conditionnels écoutent d'autres déclencheurs (déclencheurs de données, périodiques ou conditionnels) et, lorsqu'un de ces déclencheurs se déclenche, ils évaluent une expression. Le déclencheur conditionnel ne se déclenche que si le résultat de l'expression répond à une condition spécifique.

Vous pouvez configurer un déclencheur conditionnel pour qu'il se déclenche en fonction de plusieurs types de conditions :

• Valeur : lorsque l'expression renvoie true (ou une valeur non nulle) ou false (ou zéro).
• Front montant : lorsqu'une expression booléenne passe de false à true ou qu'une valeur numérique augmente.
• Front descendant : lorsqu'une expression booléenne passe de true à false ou qu'une valeur numérique diminue.
• Au changement : chaque fois que le résultat de l'expression est différent de sa valeur précédente.

Filtrer les changements d'état bruyants

Pour les déclencheurs basés sur les limites ou les changements d'état, vous pouvez filtrer les changements d'état brefs ou bruyants (glitches) en exigeant que la condition reste dans le nouvel état pendant une durée minimale avant que le déclencheur ne se déclenche.

Par exemple, vous pouvez configurer un déclencheur pour qu'il se déclenche uniquement si vehicle_speed > 100 devient true et le reste pendant au moins cinq secondes.true Cela empêche le déclencheur de se déclencher en raison d'un pic momentané de la vitesse. Vous pouvez également exiger que toutes les valeurs observées pendant cette période de suspension soient exactement égales.

Générer des rapports sur les métriques

Une fois les données traitées, vous définissez comment et quand elles sont regroupées dans des rapports.

Les rapports sont définis à l'aide de configurations de rapports sur les métriques, qui utilisent des générateurs de messages pour définir la structure et le contenu de leur sortie. Lorsqu'un des déclencheurs du rapport se déclenche, le générateur de messages évalue ses affectations de champs pour construire la charge utile de données du rapport.

Chaque rapport généré est une instance d'un message Protobuf MetricsReport, qui encapsule la sortie du générateur de messages dans un champ payload et ajoute des métadonnées. Le service de télémétrie ajoute automatiquement les métadonnées suivantes à chaque MetricsReport :

• Identifiant unique universel (UUID) du rapport
• Numéro séquentiel du rapport, qui augmente pour chaque rapport généré par cette configuration de rapport
• Code temporel de la génération du rapport
• Motif de la génération (par exemple, déclenchée par une règle ou générée à l'arrêt)
• UUID et version de la configuration des métriques qui a généré le rapport
• Nom de la configuration du rapport sur les métriques

Contrôle de la génération de rapports

Bien que les rapports soient généralement générés en réponse à des déclencheurs, vous pouvez également les configurer pour qu'ils soient générés à des moments spécifiques du cycle de vie de la configuration des métriques :

• Rapport sur l'activation : si cette option est activée, le système génère un rapport initial immédiatement lorsque la configuration des métriques est activée.
• Rapport final : si cette option est activée, le système génère un rapport final lorsque la collecte de données est mise en veille ou arrêtée, ou lorsque le service de télémétrie est arrêté. Ce rapport contient les données agrégées jusqu'à ce point, ce qui permet de s'assurer qu'aucune donnée n'est perdue à la fin d'une session.

Gérer le cycle de vie de la collecte de données

Par défaut, une configuration de métriques commence à collecter et à traiter les données dès qu'elle est activée par un client, et se poursuit jusqu'à ce qu'elle soit désactivée par le client. Toutefois, vous pouvez contrôler ce cycle de vie de manière plus précise en définissant des déclencheurs qui démarrent ou arrêtent la collecte de données ou la configuration des métriques :

• Déclencheur de début : si un déclencheur de début est défini, la collecte de données ne commence que lorsqu'il se déclenche. Si la collecte a été suspendue par un déclencheur d'arrêt, le déclencheur de démarrage la reprend.
• Déclencheur d'arrêt : si ce déclencheur est défini, il met en pause la collecte de données. Les agrégations et la génération de rapports s'arrêtent jusqu'à ce que le déclencheur de début se déclenche à nouveau.
• Désactiver le déclencheur : ce déclencheur désactive la configuration des métriques de la même manière qu'un appel deactivate_metrics_config du client.

Par exemple, vous pouvez définir un déclencheur conditionnel qui se déclenche lorsque vehicle_state passe à DRIVING comme déclencheur de début, et un autre qui se déclenche lorsque vehicle_state passe à PARKED comme déclencheur d'arrêt. Cela permet de s'assurer que les données ne sont collectées que lorsque le véhicule est en mouvement.