Configurations d'inférence avancées - AWS IoT SiteWise

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.

Configurations d'inférence avancées

AWS IoT SiteWise permet aux clients de configurer des programmes d'inférence de modèles adaptés à leurs besoins opérationnels.

La planification des inférences est généralement classée en trois modes :

Inférence à haute fréquence (5 minutes — 1 heure)

Ce mode est idéal pour les processus qui fonctionnent en continu ou dont le taux de variation des valeurs des capteurs est élevé. Dans cette configuration, l'inférence est exécutée fréquemment, jusqu'à toutes les 5 minutes.

Cas d'utilisation :

  • Il est utilisé pour surveiller les équipements en évolution rapide tels que les compresseurs ou les convoyeurs.

  • Il est utile pour détecter les anomalies de courte durée qui nécessitent une réponse immédiate.

  • Il s'agit d'une opération permanente au cours de laquelle les données circulent de manière constante.

Support de compensation conditionnel :

Vous pouvez définir un décalage conditionnel (0 à 60 minutes) pour retarder l'inférence après l'ingestion des données. Cela garantit que les données arrivées en retard sont toujours incluses dans la fenêtre d'analyse.

Pour configurer l'inférence haute fréquence :

  • Configurez la valeur de la charge utile de l'AWS/ANOMALY_DETECTION_INFERENCEaction DataUploadFrequency avec des valeurs : PT5M, PT10M, PT15M, PT30M, PT1H lors du démarrage de l'inférence.

  • (Facultatif) Configurez DataDelayOffsetInMinutes avec le décalage du délai en minutes. Définissez cette valeur entre 0 et 60 minutes.

{ "inferenceMode": "START", "dataDelayOffsetInMinutes": "DataDelayOffsetInMinutes", "dataUploadFrequency": "DataUploadFrequency" }
Exemple de configuration d'inférence haute fréquence :
{ "inferenceMode": "START", "dataDelayOffsetInMinutes": "2", "dataUploadFrequency": "PT5M" }

Inférence à basse fréquence (2 heures — 1 jour)

Ce mode convient aux processus plus lents ou aux cas d'utilisation où les évaluations quotidiennes sont suffisantes. Les clients configurent l'inférence pour qu'elle soit exécutée toutes les heures ou une fois par jour.

Heure de début prise en charge pour un intervalle d'un jour :

Pour une inférence quotidienne, spécifiez éventuellement un startTime(8 h tous les jours), ainsi que la connaissance du fuseau horaire.

Support du fuseau horaire :

Lorsqu'un startTime est fourni, AWS IoT SiteWise utilise la base de données des fuseaux horaires, gérée par l'Internet Assigned Numbers Authority (IANA). Cela garantit que votre inférence correspond aux heures de travail locales, même dans toutes les régions.

Support de compensation conditionnel :

Comme pour les autres modes, un décalage conditionnel de 0 à 60 minutes est configuré.

Cas d'utilisation :

  • Contrôles de santé quotidiens pour les processus par lots ou les opérations basées sur des équipes.

  • Évite les inférences lors de la maintenance ou des temps d'arrêt.

  • C'est utile dans les environnements aux ressources limitées, où l'utilisation du calcul doit être minimisée.

Pour configurer l'inférence à basse fréquence :

  • Configurez la valeur de la charge utile de l'AWS/ANOMALY_DETECTION_INFERENCEaction DataUploadFrequency avec les valeurs suivantes :PT2H..PT12H.

    • Dans le cas d'un jour, DataUploadFrequency c'estP1D.

  • (Facultatif) Configurez DataDelayOffsetInMinutes avec le décalage du délai en minutes. Définissez cette valeur entre 0 et 60 minutes.

Exemple de configuration d'inférence basse fréquence :
{ "inferenceMode": "START", "dataUploadFrequency": "P1D", "inferenceStartTime": "13:00", "inferenceTimeZone": "America/Chicago" }

Planification flexible

La planification flexible permet aux clients de définir des jours et des plages horaires spécifiques, pendant lesquels l'inférence est exécutée. Cela donne aux clients un contrôle total sur la planification en fonction des heures de production, des horaires de travail et des temps d'arrêt planifiés.

weeklyOperatingWindowCela aide lorsque :

  • L'équipement ne fonctionne que pendant des heures spécifiques (8 h 00 à 16 h 00).

  • Il n'y a pas de production le week-end.

  • La maintenance quotidienne est planifiée pendant des plages horaires connues.

Support du fuseau horaire :

Lorsqu'un startTime est fourni, AWS IoT SiteWise utilise la base de données des fuseaux horaires, gérée par l'Internet Assigned Numbers Authority (IANA). Cela garantit que l'inférence correspond aux heures de travail locales, même dans toutes les régions.

Support de compensation conditionnel :

Comme pour les autres modes, un décalage conditionnel de 0 à 60 minutes peut être configuré.

Avantages de weeklyOperatingWindow :

  • Il évite les inférences pendant les périodes d'inactivité ou de maintenance, réduisant ainsi le nombre de faux positifs.

  • Il aligne la détection des anomalies sur les priorités opérationnelles et les flux de travail basés sur les équipes.

Pour configurer la planification flexible, procédez comme suit :

  • Configurez la valeur de la charge utile de l'AWS/ANOMALY_DETECTION_INFERENCEaction avecDataUploadFrequency.

  • (Facultatif) DataDelayOffsetInMinutes avec le décalage du délai en minutes. Définissez cette valeur entre 0 et 60 minutes.

  • Configurez weeklyOperatingWindow avec une configuration Shift :

    • Les clés weeklyOperatingWindow sont les jours de la semaine :monday|tuesday|wednesday|thursday|friday|saturday|sunday.

    • Chaque plage horaire doit être au format 24 heures sous la forme "HH:MM-HH:MM" ("08:00-16:00").

    • Plusieurs plages peuvent être spécifiées par jour.

Exemple de configuration de planification flexible :
{ "inferenceMode": "START", "dataUploadFrequency": "PT5M", "weeklyOperatingWindow": { "tuesday": ["11:00-13:00"], "monday": ["10:00-11:00", "13:00-15:00"] } }

Activation de la version du modèle

Lorsque vous démarrez l'inférence, vous pouvez éventuellement activer une version de modèle spécifique à utiliser pour la détection des anomalies. Cette fonctionnalité vous permet de sélectionner une version de modèle entraînée en particulier, de revenir aux versions précédentes ou d'annuler les décisions de promotion automatique du modèle.

Cas d'utilisation :

  • Annulation de la production : revenez rapidement à une version stable du modèle lorsque la version actuelle présente des performances dégradées ou un comportement inattendu.

  • Tests A/B : comparez les performances entre les différentes versions du modèle en passant de l'une à l'autre pendant des périodes contrôlées.

  • Sélection manuelle du modèle : annulez les décisions de promotion automatiques et sélectionnez manuellement la version de votre modèle préférée en fonction des besoins de l'entreprise.

  • Déploiement par étapes : testez les nouvelles versions du modèle dans des fenêtres temporelles non critiques avant de les promouvoir pour une utilisation en production complète.

  • Optimisation des performances : sélectionnez les versions de modèle les plus performantes pour des conditions opérationnelles spécifiques ou des modèles saisonniers.

  • Annulation pendant la maintenance : utilisez des versions de modèles plus anciennes et bien testées lors de la maintenance du système, ou des mises à niveau pour garantir la stabilité.

Comportement de sélection des versions du modèle

Quand targetModelVersion est spécifié :

  • Le système active la version de modèle demandée à des fins d'inférence.

  • Valide que la version du modèle spécifiée existe.

  • Remplace tous les paramètres de promotion automatique.

Quand n'targetModelVersionest pas précisé :

  • Active la dernière version active du modèle si l'inférence a déjà été lancée.

  • Si l'inférence n'a jamais été activée, utilise la dernière version du modèle entraîné.

Pour activer une version de modèle spécifique :

  • Configurez la charge utile de l'action d'inférence, en la targetModelVersion définissant sur le numéro de version du modèle souhaité.

  • La version du modèle spécifiée est validée et activée si elle existe.

Exemple de l'activation de la version du modèle :
{ "inferenceMode": "START", "dataUploadFrequency": "PT15M", "targetModelVersion": 2 }

Vérification des versions des modèles

Pour vérifier la version du modèle actuellement active, procédez comme suit :

Pour voir toutes les versions de modèles disponibles :

  • Utilisez l' ListExecutionsAPI pour récupérer la liste complète des versions historiques des modèles.

  • Utilisez l' DescribeExecutionAPI pour récupérer des informations sur le modèle entraîné, notamment la plage de temps des données d'exportation, la version du modèle de calcul et la durée facturable en minutes.

Caractéristiques de la version du modèle

  • Les numéros de version des modèles sont attribués de manière séquentielle à partir de 1.

  • Vous pouvez activer toutes les versions de modèles déjà entraînées.

  • La version du modèle activée est conservée jusqu'à ce qu'elle soit explicitement modifiée.

  • L'activation de la version du modèle fonctionne avec tous les modes de planification d'inférence (haute fréquence, basse fréquence et flexible).

  • Si la version du modèle spécifiée n'existe pas, l'action d'inférence échoue avec une erreur.