

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Comprendre les données de télémétrie
<a name="telemetry.understanding-data"></a>

 Les données de télémétrie sont transmises sous forme d'enregistrements Base64-encoded JSON à votre flux Kinesis Data Streams. Chaque enregistrement contient des informations collectées lors de votre contact avec le satellite, y compris des métadonnées concernant le contact et les mesures de télémétrie échantillonnées. 

## Présentation du format de données
<a name="telemetry.understanding-data.format"></a>

 Chaque enregistrement de télémétrie contient les éléments suivants : 

Type et version de télémétrie  
 Identifie le type spécifique de données de télémétrie et la version de son schéma. Cela vous permet d'analyser les différents types de télémétrie de manière appropriée. Pour plus d'informations sur la gestion des versions des schémas, consultez[Versionnage et évolution des schémas](#telemetry.understanding-data.schema-evolution). 

Identifiant de l'étendue  
 Un identifiant unique pour l'étendue de la télémétrie. Cela vous permet de corréler les données de télémétrie avec des contacts spécifiques. 

Métadonnées  
 Informations contextuelles sur la télémétrie. 

Données  
 Les mesures de télémétrie échantillonnées spécifiques au type de télémétrie. 

 **Clé de partition** 

 Les enregistrements de télémétrie sont transmis à votre flux Kinesis Data Streams avec une clé de partition au format suivant : 

```
SCOPE#{{scopeId}}#TELEMETRY_ID#{{telemetryId}}#TELEMETRY_VERSION#{{telemetryVersion}}
```

 Cette clé de partition garantit que toutes les données télémétriques d'un type donné pour un contact unique sont transmises à la même partition au sein de votre flux Kinesis Data Streams, ce qui permet de classer au mieux le flux de télémétrie de ce contact. 

## Télémétrie de pointage
<a name="telemetry.understanding-data.pointing"></a>

 La télémétrie de pointage fournit des informations sur la direction de pointage de l'antenne lors des contacts avec les satellites. Ce type de télémétrie est toujours envoyé lors d'un contact. 

 **Champs de données ** 

Exemple d'horodatage  
 Heure à laquelle les données de télémétrie ont été échantillonnées, ISO-8601 au format UTC avec une précision de la milliseconde. 

azimut  
 Angle azimutal réel de l'antenne en degrés. 

élévation  
 Angle d'élévation réel de l'antenne en degrés. 

Azimut commandé  
 Angle azimutal commandé en degrés. Il s'agit de l'angle azimutal cible que l'antenne tente d'atteindre. 

Élévation commandée  
 Angle d'élévation commandé en degrés. Il s'agit de l'angle d'élévation cible que l'antenne tente d'atteindre. 

**Note**  
 La position réelle de l'antenne peut différer de la position commandée en raison de limitations physiques ou de retards mécaniques pendant le contact. 

 **Champs de métadonnées ** 

Station terrestre  
 Nom de la station au sol (par exemple, « Ohio 1 »). 

Identifiant du satellite  
 Identifiant de la ressource satellite dans AWS Ground Station. 

contactId  
 Identifiant du contact. 

 **Exemple JSON ** 

```
{
  "telemetryTypeAndVersion": "POINTING#1.0.0",
  "telemetryType": "POINTING",
  "telemetryVersion": "1.0.0",
  "scopeId": "12345678-1234-1234-1234-123456789012",
  "metadata": {
    "groundStation": "Ohio 1",
    "satelliteId": "87654321-4321-4321-4321-210987654321",
    "contactId": "12345678-1234-1234-1234-123456789012"
  },
  "data": {
    "sampleTimestamp": "2025-12-08T12:00:00.123Z",
    "azimuth": 180.5,
    "elevation": 45.2,
    "commandedAzimuth": 180.0,
    "commandedElevation": 45.0
  }
}
```

## Suivi de la télémétrie
<a name="telemetry.understanding-data.tracking"></a>

 La télémétrie de suivi fournit des informations sur l'état de suivi de l'antenne et les erreurs de suivi. Ce type de télémétrie est envoyé lorsque le suivi automatique est activé dans votre configuration de suivi et lorsque l'antenne utilise activement le suivi automatique. 

**Note**  
 Si le `autotrack` paramètre de votre choix TrackingConfig est défini sur`REMOVED`, aucune télémétrie de suivi ne sera fournie. Pour plus d'informations sur le suivi des configurations, consultez[Suivi de Config](how-it-works.config.md#how-it-works.config-tracking). 

 **Champs de données ** 

Exemple d'horodatage  
 Heure à laquelle les données de télémétrie ont été échantillonnées, ISO-8601 au format UTC avec une précision de la milliseconde. 

État du suivi  
 État de suivi actuel de l'antenne. Les valeurs possibles sont :   
+  `TRACKING`— L'antenne a réussi à capter un signal correspondant au profil de la mission et le suit activement dans le ciel. Il s'agit de l'état de fonctionnement nominal lors d'un contact. 
+  `ACQUIRING`— L'antenne est en train de localiser et de verrouiller le signal. Le système utilise actuellement un suivi programmatique, un pointage basé sur les données des éphémérides. 
+  `MASKED`— La position prévue du satellite se trouve derrière un masque de suivi automatique, ce qui signifie que l'antenne ne peut pas utiliser de manière fiable le suivi automatique dans cette direction de pointage spécifique. Cela se produit généralement dans les zones de fortes interférences RF, telles que les basses altitudes. 

suivi ErrorAzimuth  
 Erreur de suivi sur l'axe azimutal, mesurée en degrés. 

suivi ErrorElevation  
 Erreur de suivi sur l'axe d'élévation, mesurée en degrés. 

**Note**  
 Les valeurs d'erreur de suivi représentent des ajustements par rapport à la piste de programme basée sur les éphémérides qui AWS Ground Station s'applique pendant le suivi automatique afin de maximiser la puissance du signal. 

 **Champs de métadonnées ** 

 La télémétrie de suivi inclut les mêmes champs de métadonnées que la télémétrie de pointage :`groundStation`, et. `satelliteId` `contactId` 

 **Exemple JSON ** 

```
{
  "telemetryTypeAndVersion": "TRACKING#1.0.0",
  "telemetryType": "TRACKING",
  "telemetryVersion": "1.0.0",
  "scopeId": "12345678-1234-1234-1234-123456789012",
  "metadata": {
    "groundStation": "Ohio 1",
    "satelliteId": "87654321-4321-4321-4321-210987654321",
    "contactId": "12345678-1234-1234-1234-123456789012"
  },
  "data": {
    "sampleTimestamp": "2025-12-08T12:00:00.123Z",
    "trackingStatus": "TRACKING",
    "trackingErrorAzimuth": 0.2,
    "trackingErrorElevation": 0.1
  }
}
```

## Lecture de données depuis le flux Kinesis Data Streams
<a name="telemetry.understanding-data.reading"></a>

 Les données de télémétrie sont transmises à votre flux Kinesis Data Streams et peuvent être consommées selon des modèles de consommation de flux standard. Lorsque vous lisez les données de votre stream, tenez compte des points suivants. 

 **Décodage Base64 ** 

 Les données du flux Kinesis Data Streams sont Base64-encoded. Vous devez décoder les données avant de les analyser au format JSON. Pour plus d'informations, consultez la section [ Utilisation d'Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/working-with-streams.html). 

 **Utilisation de la visionneuse de données Kinesis ** 

 Pour accéder rapidement à vos données de télémétrie, la console de diffusion Kinesis Data Streams propose une fonction Data Viewer. Lorsque vous utilisez cette fonctionnalité : 
+  La télémétrie peut être transmise à n'importe quel fragment de votre flux. 
+  La position de départ par défaut se lit à partir des derniers enregistrements de la partition. 
+  Vous devrez peut-être ajuster la partition sélectionnée et utiliser la position de départ « À l'horodatage » pour afficher les enregistrements reçus. 

 **Utilisation de la bibliothèque cliente Kinesis ** 

 La bibliothèque cliente Kinesis (KCL) gère de nombreuses complexités associées à la consommation de données provenant du flux Kinesis Data Streams, notamment la gestion des partitions, les points de contrôle et l'équilibrage de charge. Nous vous recommandons d'utiliser KCL pour les applications de consommation de télémétrie de production. 

 Pour plus d'informations, consultez la section [ Développement des consommateurs à l'aide de la bibliothèque ](https://docs.aws.amazon.com/streams/latest/dev/kcl.html) cliente Kinesis. 

 **Meilleures pratiques en matière de consommation ** 
+  **Minimiser la latence ** : utilisez la Fan-Out fonction Enhanced pour lire à partir du flux Kinesis Data Streams avec un débit dédié et une latence inférieure à celle du polling. Pour plus d'informations, voir [ Developing Enhanced Fan-Out Consumers](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html). 
+  **Stream dédié ** : utilisez un flux Kinesis Data Streams dédié pour votre intégration de AWS Ground Station télémétrie. Le partage d'un flux avec d'autres applications peut entraîner une saturation du débit d'écriture et des échecs de diffusion de la télémétrie. 
+  **On-demand capacité ** : déployez votre flux Kinesis Data Streams en mode de provisionnement à la demande pour permettre la mise à l'échelle automatique des partitions en fonction du débit. 
+  **Surveillez le débit ** : surveillez la limitation de votre flux à l'aide CloudWatch de métriques. Pour plus d'informations, consultez la section [ Surveillance des flux ](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) de données Amazon Kinesis. 

## Versionnage et évolution des schémas
<a name="telemetry.understanding-data.schema-evolution"></a>

 Les schémas de télémétrie sont versionnés pour prendre en charge leur évolution dans le temps. Le `telemetryVersion` champ de chaque enregistrement indique la version du schéma. 

 **Gestion des modifications de schéma ** 
+  De nouveaux types de télémétrie pourraient être introduits à l'avenir. 
+  Les types de télémétrie existants peuvent recevoir de nouvelles versions avec des modifications majeures. 
+  Vos applications doivent être tolérantes à l'égard de types et de versions de télémétrie inconnus. 
+  Analysez les `telemetryVersion` champs `telemetryTypeAndVersion``telemetryType`, et pour déterminer comment traiter chaque enregistrement. 

 Nous vous recommandons de mettre en œuvre une sérialisation des charges utiles tenant compte des versions, capable de gérer correctement plusieurs versions de schéma, afin de permettre à vos applications de continuer à fonctionner lorsque de nouvelles versions sont introduites. 