• Non ci sono risultati.

3.3.2 Analisi per i sensori ridondat

3.3.2.2 Analisi per l’addestramento al test diagnostico

Abbiamo, poi, definito con il nome di “Train_DiagTest” una seconda analisi di tipo ‘Expression’. Questa ha il compito di addestrare il sistema al test di diagnostica. Riportiamo tale analisi in Figura 3.17 e vediamo nel dettaglio come funziona.

Figura 3.17 Sono rappresentate tutte le espressioni dell’analisi che serve per addestrare il sistema al test di diagnostica.

La routine di addestramento è innescata da uno specifico attributo-PI, chiamato “TobeTrainedIn”. Quest’ultimo svolge appunto il ruolo di ‘trigger’ per l’analisi ed esiste come child-attribute di un’altra variabile, di nome “TobeTrained”. In particolare, esso è un attributo figlio con la proprietà aggiuntiva di apparire nascosto (‘hidden-attribute’) rispetto al genitore. Si può osservare tale legame nella Figura 3.18, dove il simbolo per riconoscere l’attributo nascosto è .

Figura 3.18 Nell’immagine si nota che l’attributo “TobeTrainedIn” è figlio dell’attributo “TobeTrained”, con la proprietà aggiuntiva di essere non visibile (‘hidden’).

Se si assegna ad un attributo la proprietà ‘hidden’, questo non potrà più essere recuperato durante una ricerca, proprio perché non visibile. La nostra scelta di tale configurazione, deriva dall’esigenza di arginare il problema della circolarità, ovvero il rischio che una routine si richiami all’infinito. Infatti, per poter stabilire con ‘Asset Analytics’ un’analisi che abbia come punto di partenza della routine il cambiamento di una variabile che, poi, a sua volta si modifica (si noti la forte dinamicità dell’attributo “TobeTrained”), è necessario distinguere due modi diversi con cui chiamare l’attributo di trigger (ecco il motivo della creazione di “TobeTrainedIn”). Così facendo, il sistema non vede più il riferimento circolare e ci consente di utilizzare il cambiamento del child-attribute “TobeTrainedIn” come parametro di input di una funzione, anche se questo parametro varierà a sua volta. Il risultato è che l’attributo figlio non visibile punta allo stesso PI point dell’attributo padre, con la differenza, però, che solo sul genitore è possibile scrivere i nuovi dati, perché il figlio è impostato nella modalità di sola lettura dei valori (detta ‘Read only’). Allora, quello che accade nell’analisi, è che nel momento in cui “TobeTrainedIn” cambia valore, esso chiama il suo attributo padre che alternativamente può essere vero o falso. Solo nel caso in cui questo risulti vero, viene valutata la prima espressione che compare in Figura 3.17 e inserito il risultato all’interno della variabile “TobeTrainedNow”, a significare che l’addestramento deve essere fatto ora. Si passa, perciò, a

calcolare il limite superiore (UCL) da usare per il test sulle varie coppie di differenze. Come visto durante la spiegazione del metodo (paragrafo 2.5.1 -), il range di controllo deve riferirsi ad un periodo di funzionamento a regime dell’impianto. Perciò, si creano anche due attributi variabili, rispettivamente “FromDateTrain” e “ToDateTrain”, che indicano l’uno la prima data in cui è stato svolto il test di diagnosi, l’altro l’ultima data dell’intervallo utilizzato per valutare l’espressione. E si salvano entrambi come PI point. L’ UCL verrà, appunto, determinato entro il periodo tra le due date. Esso, a sua volta, si ottiene dalla somma tra la media delle differenze tra i sensori e la moltiplicazione della deviazione standard della differenza per un opportuno scalare. Quest’ultimo è un valore costante, che poniamo pari a 3 e inseriamo in un attributo chiamato “L”, che indica appunto il leveraggio del sensore. Poi, in sequenza vengono calcolati e salvati in PI point:

• La media della differenza per ogni coppia di sensori→ DIFF_AVG_AB/DIFF_AVG_AC/ DIFF_AVG_BC

• La deviazione standard della differenza→ DIFF_DEV_AB / DIFF_DEV_AC / DIFF_DEV_BC • Il limite superiore per ogni coppia (che usiamo nella tecnica di monitoraggio)→ UCL_AB /

UCL_AC / UCL_BC

• Il limite inferiore per ogni coppia (che, invece, non viene usato nella tecnica)→ LCL_AB / LCL_AC/ LCL_BC

A questo punto, grazie alle ultime 5 espressioni dell’analisi, si riassumono in attributi-PI le informazioni relative all’addestramento effettuato. La prima memorizza la data attuale dell’addestramento all’interno del cosiddetto “DateTrained”. La seconda espressione, invece, si occupa di segnalare che la routine è stata svolta. Quindi, pone uguale a ‘True’ un ulteriore attributo, chiamato “Trained”. Poi, dato che il sistema è stato ormai addestrato, la routine può essere interrotta e, dunque, si assegna a “TobeTrained” il valore di ‘False’ (terza espressione). La quarta funzione, che valuta se il sistema ha bisogno di ricevere un training (“NeedsTraining” è il valore di output), ha a che fare con un aspetto che noi non abbiamo considerato, ma che in futuro dovrebbe essere aggiunto alla diagnostica. Infatti, quando le coppie di differenze osservate scendono al di sotto del limite di controllo inferiore (LCL), significa che il processo stocastico alla base ha subito un cambiamento. O meglio, si può dire che il processo sta lavorando su un altro livello, che non è uguale a quello che incrementa la differenza (e che, quindi, giustamente genera un allarme), ma comunque degno da segnalare. Ciò perché, trovandoci sotto il limite di controllo, se la differenza dovesse riaumentare, è probabile che il sistema non se ne accorga e, quindi, che valga la pena riaddestrarlo. Per questo motivo, il calcolo del limite di controllo è già stato previsto nell’analisi, anche se esso non viene direttamente utilizzato nel nostro test. Infine, l’ultima espressione serve per informare l’utente sulla quantità di volte in cui storicamente il sistema ha subito un addestramento. Ad ogni nuovo training, l’output “NTrainingRqst” viene incrementato di un’unità.

Si osservi dalla Figura 3.18 Nell’immagine si nota che l’attributo “TobeTrainedIn” è figlio dell’attributo “TobeTrained”, con la proprietà aggiuntiva di essere non visibile (‘hidden’)., che anche gli attributi “NeedsTraining”, “NTrainingRqst” e “Trained” sono genitori di child-attribute posti nella modalità ‘hidden’. Ciò, infatti, ci lascia la possibilità di usare le variabili a sinistra e a destra della stessa espressione, senza far nascere un riferimento circolare.