Perte de disponibilité de la base de données et ses implications
La solution DPM utilise deux bases de données : la base de données DPM qui est créée lors du déploiement initial de la solution et la base de données ThingWorx. Une base de données peut être indisponible pour de nombreuses raisons, telles que la maintenance régulière de la base de données, la perte de connexion réseau ou la défaillance du disque. Dans le cas où l'une ou l'autre base de données devient indisponible, il est possible que survienne soit une perte des données qui arrivent via l'automatisation des données, soit une duplication de ces données.
• Lorsque des données perdues ou dupliquées comportent des événements des ordres de travail, des données de base matière ou des quantités cibles, tous les événements et décomptes suivants peuvent être enregistrés dans des ordres de travail ou des matières incorrects.
• Lorsque des données perdues ou dupliquées comportent des événements de décompte de production ou du rebut, la valeur des compteurs de production et de rebut peut devenir incorrecte. Pour les compteurs de substitution, cette action a un effet d'ondulation négatif. Pour plus d'informations sur les compteurs de substitution, consultez la rubrique
Configuration de l'automatisation des données.
DPM et ThingWorx ont des processus en place afin d'éviter la perte ou la duplication de données dans la plupart des scénarios lorsqu'une base de données devient indisponible :
• Si la base de données DPM devient indisponible à un moment quelconque pendant le traitement par lots, ce dernier s'arrête à ce stade. La propriété PTCLastProcessedEventTimestamp est définie sur l'horodatage du dernier événement traité avec succès. Lors du déclenchement suivant de la minuterie de l'événement d'automatisation, le flux de valeurs est interrogé pour obtenir les données d'événement non traitées. Tous les événements avec un horodatage survenant après la valeur actuelle de la propriété PTCLastProcessedEventTimestamp sont traités, y compris les événements qui n'avaient pas encore été traités lors de l'arrêt précédent du traitement par lots.
• Si la base de données ThingWorx devient indisponible, les données d'événement sont écrites dans la file d'attente de flux de valeurs. ThingWorx dispose d'un mécanisme de nouvelle tentative pour rétablir la connexion à la base de données. Lorsque la base de données devient disponible, les entrées de la file d'attente du flux de valeurs sont ajoutées au flux de valeurs.
Cette rubrique décrit les
scénarios peu courants dans lesquels l'indisponibilité des bases de données peut entraîner une perte ou une duplication des données, fournit des informations sur les opérations pouvant être effectuées pour
identifier le moment où ces scénarios se sont produits et indique comment
résoudre les problèmes de données résultants.
Flux d'automatisation des données
Pour mieux comprendre ces scénarios, il est utile de comprendre dans les grandes lignes le flux de traitement des données d'événement à partir de l'automatisation des données. Le flux suivant est suivi par chaque cadenceur configuré pour l'automatisation des données :
1. Les données d'événement sont reçues via l'automatisation des données. Les données de bonne qualité sont écrites dans la file d'attente du flux de valeurs. Les entrées de la file d'attente sont ajoutées au flux de valeurs.
2. La minuterie des événements d'automatisation est déclenchée et le
traitement par lots commence :
a. Le flux de valeurs est interrogé pour obtenir les données d'événement non traitées. Les événements non traités sont ceux dont l'horodatage est postérieur à la valeur actuelle de la propriété PTCLastProcessedEventTimestamp.
b. Les événements interrogés sont traités pour chaque horodatage, dans l'ordre.
c. Les décomptes de production et du rebut sont
mis en mémoire tampon pour consolider les décomptes dans des groupes pour chaque compteur.
d. Les décomptes groupés sont insérés dans la base de données DPM.
3. La propriété PTCLastProcessedEventTimestamp est mise à jour une fois chaque événement traité avec succès. Pour les décomptes de production et les décomptes du rebut, la propriété PTCLastProcessedEventTimestamp n'est pas mise à jour tant que tous les décomptes groupés n'ont pas été insérés dans la base de données. L'horodatage le plus récent de tous les groupes mis en mémoire tampon est défini comme valeur de la propriété PTCLastProcessedEventTimestamp.
Scénarios
Le tableau ci-après décrit les scénarios peu courants qui peuvent entraîner la perte ou la duplication de données. N'oubliez pas que le flux d'automatisation des données se produit sur chaque cadenceur configuré pour l'automatisation des données. Selon le minutage d'un scénario, il peut avoir un impact sur certains cadenceurs et pas sur d'autres.
|
Scénario
|
Description
|
Résultat
|
|
La base de données DPM n'est plus disponible lors du traitement de plusieurs événements qui ont tous le même horodatage.
|
Chaque événement reçu via l'automatisation des données a un horodatage. Il est possible, bien que rare, que plusieurs événements aient le même horodatage. Dans ce cas, les événements ayant le même horodatage sont traités dans l'ordre suivant : ordre de travail, données de base matière, quantité cible, disponibilité et finalement décomptes de production et du rebut.
S'il existe plusieurs événements avec le même horodatage, la propriété PTCLastProcessedEventTimestamp est mise à jour après le traitement du premier événement avec cet horodatage.
Dans le cas où la base de données DPM devient indisponible avant que tous les événements ayant le même horodatage n'aient été correctement traités, tous les événements ayant cet horodatage qui n'ont pas été traités sont perdus, y compris les événements de décompte de production et du rebut. Cela s'explique par le fait que la prochaine fois que le minuteur de l'événement d'automatisation est déclenché, le traitement par lots interroge les événements avec les horodatages qui se produisent après la valeur actuelle de la propriété PTCLastProcessedEventTimestamp.
|
Tous les événements non traités ayant le même horodatage que la propriété PTCLastProcessedEventTimestamp sont perdus, y compris les événements de décompte de production et du rebut.
|
|
La base de données ThingWorx n'est pas disponible et la file d'attente des flux de valeurs est saturée.
|
Lorsque la base de données ThingWorx n'est plus disponible, les événements provenant de l'automatisation des données continuent d'être ajoutés à la file d'attente du flux de valeurs jusqu'à ce que sa taille maximale soit atteinte. Lorsque la base de données redevient disponible, la file d'attente de flux de valeurs est traitée pour ajouter des entrées au flux de valeurs, où elles sont interrogées pendant le traitement par lots lors du déclenchement suivant du minuteur de l'événement d'automatisation. Si la file d'attente de flux de valeurs est saturée, tous les nouveaux événements provenant de l'automatisation des données sont rejetés.
|
Les événements rejetés sont perdus.
|
|
La base de données ThingWorx n'est pas disponible et le serveur ThingWorx est redémarré.
|
Lorsque le serveur ThingWorx est redémarré, tous les contenus de la file d'attente de flux de valeurs et de la file d'attente de persistance sont perdus. Les entrées qui ont été ajoutées au flux de valeurs, mais qui n'ont pas encore été traitées, sont conservées.
|
Toutes les données de la file d'attente de flux de valeurs et de la file d'attente de persistance sont perdues.
|
|
La base de données ThingWorx n'est pas disponible, le nombre de tentatives de connexion est épuisé et ThingWorx est arrêté.
|
Lorsque le nombre de tentatives configuré pour le mécanisme de nouvelle tentative de la base de données ThingWorx est épuisé, le serveur ThingWorx est arrêté. Pour plus d'informations sur le mécanisme de nouvelle tentative de ThingWorx, consultez la rubrique Stockage des données dans ThingWorx du Centre d'aide ThingWorx. |
Toutes les données de la file d'attente de flux de valeurs et de la file d'attente de persistance sont perdues.
Tous les nouveaux événements provenant de l'automatisation des données pendant l'arrêt de ThingWorx sont perdus.
|
|
La base de données ThingWorx devient indisponible avant que la file d'attente de persistance ne soit traitée pour mettre à jour la propriété PTCLastProcessedEventTimestamp et le serveur ThingWorx est redémarré.
|
Si la base de données ThingWorx n'est pas disponible avant que la file d'attente de persistance ne soit traitée pour mettre à jour la propriété PTCLastProcessedEventTimestamp et que le serveur ThingWorx est redémarré, le contenu de la file d'attente de persistance est perdu. La valeur de la propriété PTCLastProcessedEventTimestamp est laissée à la valeur précédente. Cela signifie que les événements comportant des horodatages qui se produisent après la valeur de la propriété PTCLastProcessedEventTimestamp, qui ont déjà été traités et ajoutés à la base de données DPM, seront retraités et ajoutés à nouveau à la base de données.
|
Les événements retraités créent des données en double.
|
Identification des incidents de disponibilité des bases de données
Vous pouvez identifier à quel moment un événement de disponibilité de la base de données a entraîné une perte ou une duplication de données de deux manières :
• Surveillez le
Tableau de bord de production pendant la production. Les opérateurs des cadenceurs automatisés peuvent identifier le moment où des données incorrectes apparaissent dans les blocs de production courants et dans les journaux des événements développés.
• Consultez les journaux ThingWorx pour connaître les erreurs d'indisponibilité de la base de données, notamment lorsque vous êtes informé de la maintenance des bases de données ou d'autres actions susceptibles d'affecter la disponibilité de la base de données. Identifiez les cadenceurs impactés et vérifiez les données dans le Tableau de bord de production pour voir s'il y a des données manquantes ou dupliquées.
Résolution des problèmes de données
Bien qu'il n'existe aucune stratégie garantie pour éviter ces scénarios rares, vous pouvez prendre des mesures pour traiter les résultats lorsqu'ils se sont produits.
• Réinitialisez les compteurs de production et de rebut incorrects pour les cadenceurs individuels :
1. Arrêtez le serveur Kepware.
2. Dans ThingWorx Composer, accédez à l'objet de cadenceur.
3. Sous Propriétés, ajoutez une ligne à la table d'informations de la propriété PTCLastAutomationProcessedValues avec les informations suivantes pour chaque compteur que vous réinitialisez :
▪ propertyName : pour les compteurs de production, saisissez PTCPoductionCount. Pour les compteurs de rebut, entrez le nom de la propriété de rebut.
▪ value : valeur à laquelle vous souhaitez réinitialiser le compteur.
▪ jobOrderUid : ce champ est ignoré par DPM.
4. Démarrez le serveur Kepware.
• Saisissez manuellement les données manquantes pour les cadenceurs individuels à l'aide du
Tableau de bord de production. Pour la production des dernières 24 heures, les événements de perte, les décomptes de production et les décomptes du rebut qui se sont produits au cours des dernières 24 heures peuvent être entrés manuellement pour chaque cadenceur. En outre, les événements de rebut historiques peuvent être ajoutés pour une semaine au maximum.
• Supprimez manuellement les décomptes de production en double pour les cadenceurs individuels à l'aide du
Tableau de bord de production. Pour le bloc de production actuel, vous pouvez
supprimer le décompte de production dans le volet
Entrée de production du Tableau de bord de production. Pour supprimer le décompte de production des dernières 24 heures, vous pouvez utiliser la fenêtre
Comptabilisation des pertes de temps.