Perdita di disponibilità del database e relative implicazioni
La soluzione DPM utilizza due database: il database DPM creato quando la soluzione viene inizialmente distribuita e il database ThingWorx. Un database può diventare non disponibile per molti motivi, ad esempio manutenzione regolare del database, perdita di connessione di rete o errore del disco. Se il database diventa non disponibile, si potrebbe verificare la perdita dei dati in entrata tramite automazione dei dati o la duplicazione di tali dati.
• Quando i dati persi o duplicati includono eventi di commessa, materiale principale o quantità target, è possibile registrare eventuali eventi e conteggi successivi rispetto alle commesse o ai materiali non corretti.
• Quando i dati persi o duplicati includono eventi di conteggio di produzione o scarti, il valore per i contatori di produzione e scarti può risultare errato. Per i contatori di rollover, si verifica un effetto a catena negativo. Per ulteriori informazioni sui contatori di rollover, vedere
Impostazione dell'automazione dei dati.
DPM e ThingWorx dispongono di processi per evitare la perdita o la duplicazione dei dati nella maggior parte degli scenari in cui un database diventa non disponibile.
• Se il database DPM diventa non disponibile in qualsiasi momento durante l'elaborazione in batch, l'elaborazione in batch viene interrotta in tale punto. La proprietà PTCLastProcessedEventTimestamp è impostata sulla data e l'ora dell'ultimo evento elaborato correttamente. Al successivo avvio del timer dell'evento di automazione, viene eseguita un'interrogazione dello stream di valori per i dati degli eventi non elaborati. Tutti gli eventi con data e ora successive al valore della proprietà PTCLastProcessedEventTimestamp corrente vengono elaborati, inclusi gli eventi non ancora elaborati al momento dell'interruzione dell'elaborazione in batch.
• Se il database ThingWorx diventa non disponibile, i dati degli eventi vengono scritti nella coda dello stream di valori. ThingWorx dispone di un meccanismo di ripetizione di tentativi per ristabilire la connessione al database. Quando il database diventa disponibile, le voci della coda dello stream di valori vengono aggiunte allo stream di valori.
In questo argomento vengono descritti gli
scenari non comuni in cui la mancata disponibilità del database può determinare la perdita o la duplicazione dei dati. L'argomento fornisce inoltre indicazioni sulle azioni che è possibile eseguire per
capire quando si sono verificati questi scenari e come
gestire i conseguenti problemi con i dati.
Flusso di automazione dei dati
Per capire meglio questi scenari, è utile comprendere il flusso di alto livello per l'elaborazione dei dati degli eventi derivanti dall'automazione dei dati. Il flusso riportato di seguito è seguito da ogni pacemaker configurato per l'automazione dei dati.
1. I dati degli eventi vengono ricevuti tramite l'automazione dei dati. I dati di buona qualità vengono scritti nella coda dello stream di valori. Le voci della coda vengono aggiunte allo stream di valori.
a. Viene eseguita un'interrogazione dello stream di valori per i dati degli eventi non elaborati. Gli eventi non elaborati sono quelli con data e ora successive al valore corrente della proprietà PTCLastProcessedEventTimestamp.
b. Gli eventi sottoposti a interrogazione vengono elaborati per ogni data e ora, in ordine.
c. I conteggi di produzione e scarti vengono
memorizzati nel buffer per consolidarli in gruppi per ogni contatore.
d. I conteggi raggruppati vengono inseriti nel database DPM.
3. La proprietà PTCLastProcessedEventTimestamp viene aggiornata dopo l'elaborazione di ogni evento. Per i conteggi di produzione e scarti, la proprietà PTCLastProcessedEventTimestamp non viene aggiornata finché tutti i conteggi raggruppati non sono stati inseriti nel database. La data e l'ora più recenti di tutti i gruppi memorizzati nel buffer sono impostate come valore della proprietà PTCLastProcessedEventTimestamp.
Scenari
La tabella riportata di seguito descrive scenari non comuni che possono causare la perdita o la duplicazione dei dati. Tenere presente che il flusso di automazione dei dati si verifica su ogni pacemaker configurato per l'automazione dei dati. A seconda della tempistica in cui si verifica uno scenario, può avere un impatto su alcuni pacemaker e non su altri.
|
Scenario
|
Descrizione
|
Risultato
|
|
Il database DPM diventa non disponibile durante l'elaborazione di più eventi con la stessa data e ora.
|
Ogni evento ricevuto tramite automazione dei dati presenta una data e ora. È possibile, sebbene non comune, che più eventi presentino la stessa data e ora. In questo caso, gli eventi con la stessa data e ora vengono elaborati nel seguente ordine: commessa, materiale principale, quantità target, disponibilità e, infine, conteggi di produzione e scarti.
Se sono presenti più eventi con la stessa data e ora, la proprietà PTCLastProcessedEventTimestamp viene aggiornata dopo l'elaborazione del primo evento con tale data e ora.
Se il database DPM diventa non disponibile prima che tutti gli eventi con la stessa data e ora siano stati elaborati correttamente, tutti gli eventi non elaborati con tale data e ora vengono persi, inclusi gli eventi di conteggio di produzione e scarti. Ciò si verifica perché alla successiva attivazione del timer dell'evento di automazione, l'elaborazione in batch esegue un'interrogazione per conoscere gli eventi con data e ora successive al valore corrente della proprietà PTCLastProcessedEventTimestamp.
|
Tutti gli eventi non elaborati con la stessa data e ora della proprietà PTCLastProcessedEventTimestamp vengono persi, inclusi gli eventi di conteggio di produzione e scarti.
|
|
Il database ThingWorx non è disponibile e la coda dello stream di valori diventa completa.
|
Quando il database ThingWorx diventa non disponibile, gli eventi provenienti dall'automazione dei dati continuano a essere aggiunti alla coda dello stream di valori fino a quando non viene raggiunta la dimensione della coda. Quando il database diventa nuovamente disponibile, la coda dello stream di valori viene elaborata per aggiungere voci allo stream di valori, dove vengono sottoposte a interrogazione durante l' elaborazione in batch alla successiva attivazione del timer dell'evento di automazione. Se la coda dello stream di valori diventa completa, tutti i nuovi eventi provenienti dall'automazione dei dati vengono rifiutati.
|
Gli eventi rifiutati vengono persi.
|
|
Il database ThingWorx non è disponibile e il server ThingWorx viene riavviato.
|
Quando il server ThingWorx viene riavviato, tutti i contenuti della coda dello stream di valori e della coda di persistenza vengono persi. Le voci aggiunte allo stream di valori, ma non ancora elaborate, vengono mantenute.
|
Tutti i dati nella coda dello stream di valori e nella coda di persistenza vengono persi.
|
|
Il database ThingWorx non è disponibile, il numero di tentativi di connessione è stato esaurito e ThingWorx viene arrestato.
|
Quando si esaurisce il numero di tentativi configurati per il meccanismo di ripetizione di tentativi del database ThingWorx, il server ThingWorx viene arrestato. Per ulteriori informazioni sul meccanismo di ripetizione di tentativi di ThingWorx, vedere Memorizzazione dei dati in ThingWorx in ThingWorx Help Center. |
Tutti i dati nella coda dello stream di valori e nella coda di persistenza vengono persi.
Tutti i nuovi eventi provenienti dall'automazione dei dati mentre ThingWorx non è attivo vengono persi.
|
|
Il database ThingWorx diventa non disponibile prima che la coda di persistenza venga elaborata per aggiornare la proprietà PTCLastProcessedEventTimestamp e che il server ThingWorx venga riavviato.
|
Se il database ThingWorx diventa non disponibile prima che la coda di persistenza venga elaborata per aggiornare la proprietà PTCLastProcessedEventTimestamp e che il server ThingWorx venga riavviato, il contenuto della coda di persistenza viene perso. Il valore della proprietà PTCLastProcessedEventTimestamp viene lasciato inalterato. Di conseguenza, gli eventi con data e ora successive al valore della proprietà PTCLastProcessedEventTimestamp, che sono già stati elaborati e aggiunti al database DPM, vengono rielaborati e aggiunti nuovamente al database.
|
Gli eventi rielaborati creano dati duplicati.
|
Identificazione degli incidenti di disponibilità del database
È possibile scoprire quando un evento di disponibilità del database ha provocato la perdita o la duplicazione dei dati in due modi.
• Monitorare il
Dashboard di produzione durante la produzione. Gli operatori dei pacemaker automatizzati possono rilevare quando vengono visualizzati dati non corretti, sia nei blocchi di produzione correnti sia nei log eventi espansi.
• Esaminare i log di ThingWorx per identificare gli errori di non disponibilità del database, in particolare quando si sa che è stata eseguita la manutenzione del database o altre azioni che possono influire sulla disponibilità del database. Identificare i pacemaker impattati e controllare i dati in Dashboard di produzione per verificare se mancano dati o se sono presenti dati duplicati.
Gestione dei problemi con i dati
Sebbene non esista una strategia garantita per evitare questi rari scenari, esistono alcune azioni da eseguire per gestire i risultati quando si verificano.
• Reimpostare i contatori di produzione e scarti non corretti per i singoli pacemaker.
1. Arrestare il server Kepware.
2. In ThingWorx Composer, passare all'oggetto pacemaker.
3. In Proprietà, aggiungere una riga alla infotable di proprietà PTCLastAutomationProcessedValues con le seguenti informazioni per ogni contatore da reimpostare:
▪ propertyName - Per i contatori di produzione, immettere PTCPoductionCount. Per i contatori di scarti, immettere il nome della proprietà degli scarti.
▪ value - Valore su cui si desidera reimpostare il contatore.
▪ jobOrderUid - Questo campo viene ignorato da DPM.
4. Avviare il server Kepware.
• Immettere manualmente i dati mancanti per i singoli pacemaker tramite
Dashboard di produzione. Per la produzione dalle ultime 24 ore, gli eventi di perdita, i conteggi di produzione e i conteggi di scarti che si sono verificati durante le ultime 24 ore possono essere immessi manualmente per ogni pacemaker. Inoltre, è possibile aggiungere eventi di scarto cronologici per massimo una settimana.
• Rimuovere manualmente il conteggio di produzione duplicato per i singoli pacemaker tramite
Dashboard di produzione. Per il blocco di produzione corrente, è possibile
rimuovere il conteggio di produzione dal riquadro
Immissione produzione di Dashboard di produzione. Per rimuovere il conteggio di produzione dalle ultime 24 ore, è possibile utilizzare la finestra
Amministrazione perdite di tempo.