Progetto di tesi di Francesco Occhioni.

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA ED ARCHITETTURA
Tesi di laurea in
RETI DI CALCOLATORI
PREDIZIONE DI MALFUNZIONAMENTI IN
RETI DI TELECOMUNICAZIONI CON
TECNICHE DI MACHINE LEARNING
Relatore: prof. Alberto Bartoli
Correlatore: prof. Eric Medvet
Laureando: Francesco Occhioni
Anno accademico: 2015-2016

2. I
A Minerva

3. II
Indice
1. Introduzione .....................................................................................................................................1
2. Presentazione delle richieste............................................................................................................2
3. Analisi delle richieste.......................................................................................................................2
4. Strumenti necessari allo sviluppo del Progetto................................................................................3
4.1. Hardware...................................................................................................................................3
4.1.1. PC Notebook MSI GE-62 ..................................................................................................3
4.2. Software ....................................................................................................................................4
4.2.1. Mongo DB..........................................................................................................................4
4.2.2. R Studio..............................................................................................................................4
4.2.3. Software Java.....................................................................................................................4
4.2.4. NetBeans ............................................................................................................................4
5. Stato Attuale.....................................................................................................................................5
5.1. Descrizione del CPE .................................................................................................................5
5.1.1. Ciclo di vita di un CPE ......................................................................................................5
5.2. Sistemi di monitoraggio............................................................................................................6
5.2.1. HaWMo..............................................................................................................................7
5.2.1.1. LISTA KPI ......................................................................................................................8
5.2.2. SeQuMo ...........................................................................................................................10
5.2.2.1. LISTA KPI ....................................................................................................................10
5.2.3. CDSeQuMo......................................................................................................................12
5.2.3.1. LISTA KPI ....................................................................................................................12
5.3. Sistema di Ticketing................................................................................................................14
5.3.1. Workflow di un Ticket .....................................................................................................14
5.3.2. Chi può aprire un Ticket...................................................................................................14
5.3.3. Contenuto dei ticket .........................................................................................................15
5.3.4. Lavori Programmati.........................................................................................................15
6. Progettazione della macchina ad apprendimento automatico........................................................16
6.1. Scelta del classificatore...........................................................................................................17
6.1.1. Random Forest .................................................................................................................17
6.1.2. Valutazioni delle prestazioni ............................................................................................18
6.1.3. Curva ROC.......................................................................................................................20
6.2. Costruzione del Dataset ..........................................................................................................21
6.2.1. Riferimenti Temporali per il Dataset................................................................................21
6.2.2. Creazione delle Feature....................................................................................................22
6.2.3. Scelta dei Ticket...............................................................................................................23

4. III
6.2.3. Scelta dei Campioni .........................................................................................................23
6.2.4. Trattamento dei Missing Values.......................................................................................24
6.2.5. Trattamento dei dati sbilanciati........................................................................................24
6.3. Prestazioni del classificatore...................................................................................................25
6.3.1. CDSeQuMo......................................................................................................................25
6.3.1.1. True Positive Rate.........................................................................................................25
6.3.1.2. False Positive Rate........................................................................................................26
6.3.1.3. True Positive Rate @1%...............................................................................................27
6.3.1.4. True Positive Rate @0,15%..........................................................................................28
6.3.2. SeQuMo ...........................................................................................................................29
6.3.2.1. True Positive Rate.........................................................................................................29
6.3.2.2. False Positive Rate........................................................................................................30
6.3.2.3. True Positive Rate @1%...............................................................................................31
6.3.2.4. True Positive Rate @0.15%..........................................................................................32
6.3.3. Valutazione delle prestazioni in ambito di applicazione reale. ........................................33
7. Conclusioni ....................................................................................................................................34
Bibliografia ........................................................................................................................................35
Indice delle figure ..............................................................................................................................35
Appendice A – Risultati Numerici .....................................................................................................36
A.1 CDSeQuMo.............................................................................................................................36
A.2 SeQuMo ..................................................................................................................................39

5. 1
1. Introduzione
La tesi descritta all’interno di questo documento andrà a trattare e sviluppare l’analisi
di tecniche di Machine Learning per predire possibili guasti e disservizi in Reti di
Telecomunicazioni.
Si tratta di un progetto sviluppato in collaborazione con Emaze S.p.a e un’importante
azienda di telecomunicazioni (il committente) e vuole fornire strumenti di supporto
alla proactive assurance per migliorare il servizio di customer care offerto dal
committente del progetto.
Il primo obiettivo posto per lo sviluppo è quello di analizzare la struttura dei sistemi
informativi preesistenti atti al monitoraggio e al controllo delle infrastrutture di rete
fissa. Si è reso pertanto necessario lo studio approfondito dei sistemi database
preesistenti, la loro organizzazione e le informazioni utili che potessero contribuire
allo sviluppo del progetto. Successivamente ci si è occupato della manipolazione
delle informazioni per progettare e realizzare il sistema ad apprendimento automatico
come strumento utile per rilevare disservizi o guasti di linea.
Lo sviluppo è stato realizzato interamente in locale, ma tenendo in considerazione la
possibilità di migrare il sistema su macchina remota in un secondo momento.
I capitoli della tesi sono così organizzati:
• 2) e 3) presentano le specifiche richieste dal committente e la relativa analisi
del progetto;
• 4) descrive l’hardware e software utilizzato;
• 5) analizza lo stato attuale dei sistemi informativi preesistenti;
• 6) analizza e progetta la macchina ad apprendimento automatico;
• 7) propone sviluppi futuri del lavoro creato.

6. 2
2. Presentazione delle richieste
Il committente del progetto non ha presentato particolari richieste se non quelle di
uno sviluppo di uno studio di fattibilità riguardante la previsione dei guasti per
migliorare il servizio di proactive assurance e, di conseguenza, migliorare il grado di
soddisfazione della clientela nell’utilizzo dei servizi offerti. Il progetto descritto nel
presente elaborato di tesi è da considerare come un proof of concept per fornire una
valutazione oggettiva al committente riguardo l’applicazione di tecniche di machine
learning applicate al mondo delle telecomunicazioni.
Lo sviluppo del progetto dovrà inoltre occuparsi della sola clientela business in
quanto gode dei servizi aggiuntivi rispetto all’utenza non business quali il
monitoraggio dello stato della linea per ogni cliente.
3. Analisi delle richieste
Considerando lo sviluppo del progetto completamente libero, e non avendo richieste
specifiche da parte del committente, si è optato per realizzare una macchina ad
apprendimento automatico che possa prevedere apertura di ticket da parte della
clientela del committente. Un ticket, nel nostro caso specifico, rappresenta una
lamentela o un reclamo da parte della clientela in relazione ad un disservizio
sull’infrastruttura di rete fissa. Si è infatti ritenuto che la predizione di un ticket in
arrivo nel breve termine possa rappresentare un utile strumento di supporto ad un
reparto di customer relationship management per migliorarne il servizio offerto.
Il progetto, per la sua realizzazione, richiede uno studio approfondito di strutture dati
già sviluppate su motore Mongo DB.
Non meno importante sarà l’analisi delle informazioni fornite dal committente per
velocizzare lo sviluppo in quanto il sistema da realizzare dovrà potersi adattare
facilmente a una complessa infrastruttura già operativa.
Infine ci si occuperà dello studio degli algoritmi di machine learning più utili allo
scopo e di come manipolare i dati per ottenere una corretta previsione.
Ultimo passo del progetto sarà l’analisi dei risultati ottenuti sia per fornire al
committente eventuali sviluppi futuri sia per valutare altre applicazioni di tecniche di
machine learning relative al mondo delle telecomunicazioni.

7. 3
4. Strumenti necessari allo sviluppo del
Progetto
Il progetto necessita dell’utilizzo del seguente elenco di hardware e software.
Di seguito ne vengono descritte le caratteristiche.
4.1. Hardware
4.1.1. PC Notebook MSI GE-62
È il portatile a disposizione del laureando, montante un processore Intel core I7
octacore e 16 gigabyte di ram ddr3. Le prestazioni offerte dal calcolatore non sono
risultate per nulla superflue in quanto il progetto ha richiesto in prima battuta la
manipolazione di enormi quantità di dati (≈ 30 gigabyte) e, successivamente, una
buona potenza di calcolo a causa delle molteplici implementazioni relative
all’algoritmo di classificazione.

8. 4
4.2. Software
4.2.1. Mongo DB
È il database management system che consente la creazione, manipolazione e
interrogazione dei database presenti nei sistemi informativi in uso da parte del
committente e sviluppati da Emaze. Verrà principalmente utilizzato per recuperare le
informazioni utili riguardo lo stato delle linee.
4.2.2. R Studio
Ambiente di sviluppo basato su linguaggio R, un software statistico open source che
fornisce un insieme di macro e librerie utili per la gestione, l’analisi dei dati e la
produzione di grafici.
4.2.3. Software Java
Java è un linguaggio di programmazione e una piattaforma di elaborazione sviluppati
da Sun Microsystems nel 1995. È un linguaggio orientato agli oggetti
specificatamente progettato per essere il più possibile indipendente dalla piattaforma
di utilizzo. Dal download del software Java si ottiene Java Runtime Environment
(JRE). JRE è composto dalla Macchina virtuale Java (JVM), dalle classi core della
piattaforma Java e dalle librerie Java di supporto.
4.2.4. NetBeans
NetBeans è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma.
Nello specifico verrà utilizzato per la produzione di software applicativo in
linguaggio Java. La versione utilizzata è 8.1 rilasciata il 4 novembre 2015

9. 5
5. Stato Attuale
Questo capitolo si concentrerà sullo studio dei sistemi informativi esistenti e già
integrati nell’infrastruttura del committente.
I sistemi informativi che costituiscono le principali fonti di dati per il progetto sono
due: il primo relativo all’acquisizione dei ticket, il secondo relativo all’acquisizione
dei key performance indicator (KPI), ovvero indicatori dello stato della linea per ogni
cliente. L’acquisizione dei ticket è gestita da un gruppo interno del committente,
mentre l’acquisizione dei KPI è invece affidata a tre sistemi di monitoraggio
sviluppati da Emaze S.p.a.
5.1. Descrizione del CPE
Il Customer Premise Equipment (CPE) è il dispositivo elettronico assegnato ad ogni
cliente, che permette la connessione alla rete di comunicazione geografica (WAN) . I
principali attributi di un CPE sono vendor, modello e software version.
5.1.1. Ciclo di vita di un CPE
E’ composto, in prima approssimazione, da tre macro stati:
1. Preattivo
2. Attivo (o “in produzione”)
3. Dismesso
Quando il CPE è in stato Preattivo, sono
presenti molte fasi interne relative a opzioni
di configurazione, collaudi e test di linea.
Una volta effettuati e verificati con successo
lo stato del CPE passa in Attivo e si avvia,
se previsto, il monitoraggio del CPE e dello
stato della linea.
Un CPE attivo può essere sostituito in caso di guasto o dismesso in caso di
risoluzione di contratto. Il cliente è effettivamente pagante solo quando il CPE è
attivo.
Figura 1: Workflow CPE

10. 6
Ogni CPE è univocamente identificabile dal suo link reference e per ogni link
reference esistono diversi tipi di linea:
• ADSL
• SHDSL
• CDN
• FTTC_MAKE
• FTTC_NGA_VULA
• FTTH_GPON
• PONTE_RADIO
• MOBILE
e diversi tipi di servizi offerti:
• Voice-Data: linea VOCE e/o DATI - dedicata a piccoli uffici
• DataC: DATI per Corporate Data - linee con infrastruttura più complessa
• VoiceC-DataC: VOCE e DATI per Corporate Data - linee con infrastruttura più
complessa
5.2. Sistemi di monitoraggio
Sono attualmente in produzione tre sistemi di monitoraggio:
• HaWMo (Hardware Monitor)
• SeQuMo (Service Quality Monitor)
• CDSeQuMo (Corporate Data Service Quality Monitor)
SeQuMo e CDSeQuMo si occupano di monitorare lo stato della linea dei CPE allo
scopo di misurare la qualità dei servizi voce e dati tramite acquisizione di
misurazioni di KPI effettuate dagli apparati, mentre HaWMo si occupa di monitorare
le performance hardware dei CPE attraverso dati diagnostici generati dai CPE stessi.
Allo stato attuale la numerosità dei CPE monitorati è la seguente:
#HaWMo = 9782
#SeQuMo = 28133
#CDSeQuMo = 6610
#(CDSeQuMo∩HaWMo)= 3495
#(SeQuMo∩HaWMo)= 6184
#(CDSeQuMo∩SeQuMo) = 0Figura 2: Organizzazione
sistemi di monitoraggio

11. 7
In totale sono monitorati all’incirca 35000 CPE su una base totale di 40000. È bene
notare che il sistema di monitoraggio non sia statico, ma sia fortemente dinamico in
quanto giornalmente vengono aggiunti e dismessi nuovi CPE.
Vengono ora analizzati più in dettaglio le macchine di monitoraggio con i relativi
KPI.
Codici di Errore
I tre sistemi di monitoraggio hanno in comune la stessa rappresentazione dei codici
di errore:
• -1: errore generico durante l'esecuzione del test
• -2: OID SNMP non configurato sul dispositivo
• -3: timeout durante l'acquisizione
• -4: dati non disponibili sul dispositivo
• -5: formato dati ricevuti invalido
• -6: differenza negativa
• -7: calcolo non valido
• -66: interfaccia down
5.2.1. HaWMo
Il sistema è responsabile dell’acquisizione periodica dei KPI relativi allo stato
hardware dei CPE. Tale acquisizione avviene ad intervalli regolari di campionamento
di 15 minuti e viene mantenuto uno storico di 30 giorni (pari a 2880 campioni) per
CPE.
Prima di elencare i KPI acquisiti da HaWMo, è bene fare una precisazione sul
funzionamento del buffer di memoria di ogni CPE. La memoria di ogni CPE è
suddivisa staticamente in 6 pool, ognuno contenente un insieme di buffer di
dimensione fissa. Quando è necessario memorizzare un pacchetto e non ci sono
buffer disponibili, viene creato un nuovo buffer nel pool con dimensione minima
adeguata per il pacchetto (e viene incrementato il buffer miss counter). Quando tale
pool non ha più spazio disponibile, si usa il pool con buffer di dimensione
immediatamente superiore (e viene incrementato il buffer failure counter, vedi più
sotto). Se nessun pool ha un buffer disponibile, il pacchetto viene scartato.

12. 8
5.2.1.1. LISTA KPI
• Uso CPU ultimi 5 minuti (%)
Rappresenta il valore percentuale di utilizzo della CPU (relativo a un periodo pari a 5
minuti) del dispositivo CPE.
• Uso memoria (%)
Rappresenta il valore percentuale di utilizzo della memoria del dispositivo CPE.
Note: I dispositivi VendorB non supportano l’acquisizione di questo KPI.
• Buffer failure
Rappresenta il numero di buffer failures negli ultimi 15 minuti.
I dispositivi VendorA e VendorB non supportano l’acquisizione di questo KPI
(quindi solo VendorB).
• Misses totali sui buffer
Numero di buffer miss negli ultimi 15 minuti.
I dispositivi VendorA e VendorC non supportano l’acquisizione di questo KPI
(quindi solo dispositivi VendorB)
• Uptime
Rappresenta il l’intervallo di tempo trascorso dall’ultima accensione del CPE
• Lista delle Interfacce
HaWMo raccoglie, per ogni CPE, la lista delle interfacce valide. Per ognuna di tali
interfacce vengono acquisiti anche i KPI relativi allo stato operativo e
all’occupazione di banda in ingresso ed uscita (vedi KPI successivi).
• Stato Operativo dell’Interfaccia (di rete)
Presente per ognuna delle interfacce valide, questo KPI rappresenta lo stato operativo
dell’interfaccia in questione. Valori possibili sono:
• up
• down
• testing
• unknown
• dormant
• notPresent
• lowerLayerDown

13. 9
• In - per Interfaccia
Presente per ognuna delle interfacce valide, questo KPI rappresenta l’occupazione di
banda in ingresso relativa all’interfaccia in questione.
• Out - per Interfaccia
Presente per ognuna delle interfacce valide, questo KPI rappresenta l’occupazione di
banda in uscita relativa all’interfaccia in questione.
• Uptime - per Interfaccia
Presente solo nell’interfaccia cellular dati di un box 4G, rappresenta il l’intervallo di
tempo trascorso dall’ultima attivazione dell’interfaccia coinvolta.
• Raggiungibilità
Questo KPI è associato al CPE (non alla singola interfaccia). Non viene acquisito in
maniera diretta dai CPE, bensì calcolato indirettamente in base ai valori acquisiti per
gli altri KPI. Qualora durante l’acquisizione di uno o più KPI si verifichino situazioni
di timeout, la raggiungibilità viene determinata come KO. Qualora invece tutte le
acquisizioni siano andate a buon fine (ovvero sia stato possibile acquisire un valore
per ognuno degli altri KPI, sia esso un valido o meno) senza incorrere in alcun
timeout, la raggiungibilità viene determinata come OK.

14. 10
5.2.2. SeQuMo
A intervalli periodici di 15 minuti, il sistema SeQuMo si preoccupa di interrogare
tramite protocollo SNMP tutti i dispositivi coinvolti per la raccolta dei risultati dei
test eseguiti dai singoli CPE.
Ogni CPE viene interrogato in relazione ai seguenti messaggi:
• request http;
• query DNS;
• ICMP echo;
Ogni PROBE (dispositivo dedicato ai test relativi la sola parte voce) verrà
interrogata in relazione al KPI MOS, mean opinion score, per tutti i CPE abilitati.
5.2.2.1. LISTA KPI
• MOS
Le PROBE eseguono a intervalli regolari di 15 minuti i test di tipo Voce, simulando
una chiamata telefonica verso i CPE. Il valore del MOS (Mean Opinion Score) è una
misura della chiarezza di una trasmissione telefonica. Questa misurazione va da 0 a
5: 5 indica una qualità della voce eccellente, mentre 0 indica una qualità pessima.
Figura 3: Schema di funzionamento di SeQuMo
SeQuMo

15. 11
• Stato Linea Primaria
Questo KPI viene derivato dal sistema SeQuMo dalla presenza degli altri KPI
acquisiti dal CPE e indica se la linea primaria è attiva.
• Http
Rappresenta il Round Trip Time (latenza) relativo all’acquisizione di una pagina web
via HTTP. Il CPE è configurato per l’esecuzione periodica dell’acquisizione di una
pagina HTTP, e il relativo RTT viene acquisito interrogando direttamente il CPE
sotto monitoraggio tramite l’uso del protocollo SNMP.
• Dns
Rappresenta il Round Trip Time (latenza) relativo alla risoluzione di un hostname
tramite interrogazione di un DNS server da parte del CPE. Questo test non è
supportato dai device VendorA. Per tali device viene sostituito dal test ICMP. Il CPE
deve essere configurato per l’esecuzione periodica della risoluzione di un hostname
sul DNS.
• Icmp Average e Icmp failure rate
Questo test viene usato in sostituzione al test DNS, in particolare a beneficio dei
device VendorA. Viene effettuato un ping continuo verso il server DNS; in base ai
risultati di tali ping il sistema ricava due KPI, uno relativo alla latenza (RTT) media
dei pacchetti ICMP, l’altro relativo alla percentuale di pacchetti persi nella
comunicazione fra il CPE e il server DNS. Vengono letti 30 valori, dei quali viene
fatta la media per estrarre la latenza in millisecondi e la valutazione del packet loss
percentuale.
• Reboot
Rappresenta il numero di reboot del device nell’intervallo di tempo considerato,
ovvero dall’acquisizione precedente.
• Ima Up
Rappresenta il numero di risalite di flussi IMA del device negli ultimi 15 minuti.
Ima (Inverse multiplexing over ATM) identifica una modalità di trasmissione nella
quale il flusso di dati viene suddiviso in pacchetti inviati sui collegamenti fisici
disponibili e ricomposti successivamente, una volta giunti a destinazione

16. 12
• Ima Down
Rappresenta il numero di cadute di flussi IMA del CPE nell’intervallo di tempo
considerato.
• Interface Up
Rappresenta il numero di risalita di portante del CPE nell’intervallo di tempo
considerato.
• Interface Down
Rappresenta il numero di cadute di portante del CPE nell’intervallo di tempo
considerato.
5.2.3. CDSeQuMo
Il suo funzionamento è analogo a quello di SeQuMo, ma è dedicato solo per la
clientela Corporate. A differenza di SeQuMo monitora ulteriori KPI come utilizzo
banda in download/upload e parametri di QoS, ovvero parametri di qualità del
servizio fissati al momento del contratto. Tale acquisizione avviene ad intervalli
regolari di campionamento di 15 minuti.
5.2.3.1. LISTA KPI
• Raggiungibilità
Questo KPI indica la raggiungibilità (in termini di packet loss) del CPE. Valori molto
bassi (idealmente 0%) sono indicativi di corretta raggiungibilità del dispositivo,
mentre valori molto alti (nel caso peggiore, 100%) sono indicativi di CPE spento o
non raggiungibile a causa di problematiche di rete.
CDSeQuMo effettua ping continui verso i CPE, secondo le seguenti modalità:
Ogni ping consiste di un messaggio ICMP, il quale viene dichiarato perso
dopo un’attesa di 3 secondi. Le sessioni di ping sono organizzate in slot
sequenziali di durata minima di 1 secondo:
– se l’esecuzione di uno slot richiede più di 1 secondo, il successivo
viene avviato appena il corrente finisce
– se l’esecuzione di uno slot termina in meno di 1 secondo, c’è un
periodo di attesa prima dell’esecuzione del successivo

17. 13
Durante ogni slot vengono contattati un massimo di 200 indirizzi ip, in
maniera sequenziale.
Viene comunque garantito che non vengano inviati pacchetti ICMP verso lo
stesso indirizzo IP con frequenza maggiore di 3 secondi.
– questo significa che qualora nel sistema siano registrati, per
esempio, meno di 200 indirizzi IP, la distanza minima fra l’invio di
pacchetti ICMP verso gli stessi CPE sarà di 3 secondi
Al termine di ogni ciclo di polling, ovvero ogni 15 minuti, per ogni CPE si effettua il
conteggio dei pacchetti ICMP inviati e ricevuti e si calcola la percentuale di packet
loss.
• Http
Analogo al test effettuato su SeQuMo.
• Dns
Analogo al test effettuato su SeQuMo.
• Icmp
Analogo al test effettuato su SeQuMo.
• Download rate
Rappresenta il Download rate complessivo della banda dati del CPE, non
differenziato per classe di servizio, negli ultimi 15 minuti.
A partire dal numero di byte acquisiti durante l’acquisizione n-esima, e dal valore
raccolto durante l’acquisizione precedente [n-1], si ricava l’occupazione di banda in
kbps secondo la formula:
[ ] = ( [ ] − [ − 1]) / 1024 ∗ 8 /
• Upload rate
Rappresenta l’Upload rate complessivo della banda dati del CPE, non differenziato
per classe di servizio, nell’arco degli ultimi 15 minuti.
A partire dal numero di byte acquisiti durante l’acquisizione n-esima, e dal valore
raccolto durante l’acquisizione precedente [n-1], si ricava l’occupazione di banda in
kbps secondo la formula:
[ ] = ( [ ] − [ − 1]) / 1024 ∗ 8 /

18. 14
5.3. Sistema di Ticketing
5.3.1. Workflow di un Ticket
Nel momento in cui il cliente percepisce un disservizio sulla sua linea, chiama il
CRM (customer relationship management). Il CRM si suddivide internamente in due
gruppi: il 1° Livello (frontline) che gestisce tutte le chiamate in entrata della clientela
e il 2° Livello (backoffice) che si occupa di sistemare problemi più “blandi” in
quanto ha a disposizione strumenti di visibilità e di troubleshooting da remoto. In
media il CRM risolve il 60% delle chiamate, il resto si tramuta in apertura di un
ticket.
Nel caso in cui il CRM non abbia gli strumenti necessari per risolvere il problema
entra in gioco Assurance, il gruppo di gestione di ticket che, arrivati a questo punto
del workflow, vengono considerati Ticket Tecnici. Assurance suddivide il ticket in 2
tipologie:
• Work Order (ticket interno)
• Terze Parti (ticket aperto a sua volta a operatori telefonici di terze parti)
e si occupa di identificare un gruppo interno per risoluzione del problema.
Una volta che il gruppo interno dichiara di aver terminato il troubleshooting, il ticket
ritorna ad Assurance che, o tramite un controllo diretto sul CPE o tramite una
telefonata al cliente (o delegando il controllo al CRM), verifica la risoluzione del
problema.
Se, al momento del contatto col cliente, si rileva che il problema persiste o non sia
stato sistemato viene riaperto un altro ticket, ex novo, non agganciato al precedente.
5.3.2. Chi può aprire un Ticket
Gli enti e le persone fisiche che possono aprire un ticket sono:
• Cliente, in qualsiasi momento; chiamando il CRM.
• PM (gestore dell’installazione e configurazione del CPE), nella fase di
preattivazione e nei primi 15 gg dell’attivazione;
• Il sistema CDSeQuMo, in qualsiasi momento; automaticamente in caso di lettura di
PacketLoss = 100% nell’arco di 30 minuti. Questi ticket sono considerati
automaticamente ticket tecnici

19. 15
5.3.3. Contenuto dei ticket
Un singolo ticket contiene:
• Data di Apertura
• Data di Chiusura
• Link Reference : per identificare il CPE e la relativa linea
• Tipologia Ticket
• Status: disposizione del progetto solo ticket con status Answered (problema risolto)
e Closed (verificato col cliente)
• Context: tipo di cliente e di gestione che deve avere (tempistiche, workflow di
lavorazione).
• Tripletta: costituito dai campi Service MacroArea, Service Name e Trouble
Description.
• Close_Code: campo compilato solo quando lo Status è Answered oppure Closed.
Rappresenta l'indicazione del problema rilevato una volta effettuato il
troubleshooting e rappresenta quindi quanto di più vicino a una descrizione del
problema. Non sempre infatti il ticket è indicatore di un degrado/disservizio, ma può
anche accadere che venga aperto per effettuare modifiche sui servizi, sulle classi di
servizio o modifiche di configurazione sul CPE.
5.3.4. Lavori Programmati
Un’informazione utile fornita dal committente è quella relativa ai lavori
programmati, ovvero una lista di Link Reference che giornalmente sono sottoposti a
potenziali problemi di linea in termini di rilevazione dei KPI in quanto è in corso un
lavoro fisico, come ad esempio una sostituzione di cablaggi o riconfigurazioni di
Broadband Network Gateway, sull’infrastruttura di rete. Questo tipo di informazione
si è rilevata molto utile in termini di riduzione del rumore in quanto ticket aperti
durante lavori programmati non sono stati presi in considerazione.

20. 16
6. Progettazione della macchina ad
apprendimento automatico
Con il termine classificazione si intende l’operazione di assegnare degli oggetti
chiamate istanze ad alcune categorie predefinite chiamate classi: si tratta di un
problema diffuso che riguarda molte applicazioni diverse. Tra gli esempi che si
possono citare c’è l’identificazione delle email di spam sulla base dell’oggetto e del
contenuto, la categorizzazione delle cellule come benigne o maligne oppure la
classificazione delle galassie secondo la loro forma.
Tipicamente l’input per un problema di classificazione è rappresentato da un insieme
di dati chiamato training set, l’obiettivo è quello di creare una descrizione generale
che permetta di catalogare dati futuri non ancora visti. Ogni istanza appartenente a un
training set è composta da attributi che descrivono lo stato della istanza e una o più
label che descrive una o più classi di appartenenza per quella istanza. Gli attributi
(chiamati anche feature) sono solitamente di due tipi: nominali oppure numerici.
Formalmente si definisce classificatore il task di apprendere una funzione F che
mappa un insieme di feature A in una delle classi di C.
Le feature usate per lo sviluppo del progetto sono di tipo numerico e la numerosità
delle classi è pari a due (apertura del ticket e non apertura del ticket): lo sviluppo del
progetto verterà quindi sull’addestramento e valutazione delle prestazioni di un
classificatore binario.

21. 17
6.1. Scelta del classificatore
Per lo sviluppo del progetto si è optato per l’algoritmo di classificazione chiamato
Random Forest.
6.1.1. Random Forest
È basato su alberi decisionali. Un albero decisionale è un albero in cui ogni nodo
interno è associato un test su una delle feature e gli archi verso i figli sono etichettati
come i risultati distinti del test. Infine ogni foglia è associata a una classe che
permette così di creare una partizione del training set in classi distinte. Gli alberi
decisionali presentano diversi vantaggi tra cui:
• Facilità di interpretazione;
• Offrono una buona accuratezza generale;
• Robustezza al rumore;
Il classificatore Random Forest genera, durante la fase di addestramento, una foresta
di alberi decisionali. Al momento del test ogni albero genera la sua predizione
relativa a una stessa istanza e i risultati dei singoli test vengono aggregati, valutando
la classe di maggioranza e fornendo una classificazione per quella istanza. Si è optato
per un classificatore di tipo Random Forest in quanto è un tipo di classificazione
molto efficiente e resistente all’overfitting. Per overfitting si intende quando un
modello di classificazione si adatta eccessivamente ai dati osservati fornendo ottime
prestazioni sui dati di addestramento, mentre le prestazioni sui dati non visionati
saranno peggiori.

22. 18
6.1.2. Valutazioni delle prestazioni
Per quanto riguarda le prestazioni del classificatore sono fornite dalla fase di
validazione. Infatti non è significativo studiare le prestazioni del classificatore sulle
istanze del training set dato che la funzione di classificazione è stata costruita su di
essa. Si effettua perciò la validazione su dati mai analizzati dal classificatore. Per
dimostrare la bontà del classificatore creato si effettuerà una validazione di tipo K-
fold (con K = 10) funzionante nel seguente modo:
1. Si suddivide il dataset in K sottoinsiemi disgiunti garantendo la stessa proporzione
delle classi;
2. Ad ogni passo (in totale ci sono K passi), la parte 1/K-esima del dataset viene
utilizzata come validation set, mentre la restante parte costituisce il training set.
In ogni passo si ricavano le prestazioni del classificatore confrontando i dati di
predizione del validation set con i dati reali.
È prassi infatti raccogliere i risultati di classificazione in una tabella chiamata
Confusion Matrix la quale fornisce delle metriche significative relative alla bontà
della classificazione. La rappresentazione di una Confusion Matrix relativa a un
problema di classificazione binario è la seguente:
Classe Reale
+ -
Classe Predetta
+ TP FP
- FN TN
Dove:
• TP (True Positive): previsione positiva di istanza positiva
• FP (False Positive): previsione positiva di istanza negativa
• FN (False Negative): previsione negativa di istanza positiva
• TN (True Negative): previsione negativa di istanza negativa

23. 19
Le metriche significative di un problema di classificazione sono:
• TPR, True Positive Rate: rappresenta la frazione delle istanze positive classificate
correttamente e può essere vista come la capacità del classificatore di identificare
istanze positive. Viene calcolato come: =
!"
• FPR, False Positive Rate: rappresenta la frazione delle istanze negative classificate
come positive e possono essere interpretate, nel nostro caso specifico come la
capacità di generare falsi allarmi. Viene calcolato come: # =
!
! "
• FNR, False Negative Rate: rappresenta la frazione delle istanze positive classificate
come negative e viene calcolato come: #$ =
!"
!"

24. 20
6.1.3. Curva ROC
ROC sta per Receiver Operating Characteristics ed è una tecnica utilizzata nei
classificatori binari per visualizzare i classificatori in base alle loro performance. È
una curva bidimensionale dove il True Positive Rate è lungo l’asse Y e il False
Positive Rate lungo l’asse X. La curva ROC permette di studiare i rapporti tra allarmi
veri e i falsi allarmi e si ottiene, una volta addestrato il classificatore, studiando
l’andamento delle coppie (TPR, FPR) nello spazio ROC al variare della threshold
(soglia di votazione fornita dagli alberi decisionali che di default è il 50%+1 ) del
classificatore Random Forest. Una volta ottenuti i punti nello spazio ROC è possibile
ottenere una curva tramite tecniche di interpolazione.
I punti significativi in una curva ROC sono i seguenti:
• (0,0): Rappresenta un classificatore la cui predizione risulta, indipendentemente
dall’istanza valutata, sempre Negativa;
• (0,1): Rappresenta la classificazione perfetta, ovvero quanto il classificatore non
produce falsi allarmi e riesce a predire tutte le istanze Positive;
• (1,1): Rappresenta un classificatore la cui predizione risulta, indipendentemente
dall’istanza valutata, sempre Positiva.
La linea diagonale y = x rappresenta una strategia di classificazione random,
paragonabile cioè ad un lancio di una moneta per la predizione di eventi, mentre una
curva più è distante dalla diagonale e maggiore sarà la sua capacità di previsione.
Per comparare due classificatori attraverso la curva ROC viene introdotto il
Figura 4: Esempio di Curva ROC

25. 21
coefficiente AUC, Area Under Curve, che valuta l’area sottesa alla curva ROC:
maggiore è il coefficiente di AUC e maggiore sarà l’accuratezza del classificatore.
Infine le curve ROC vengono utilizzate anche in fase di ottimizzazione: possono
essere utili cioè per fissare un valore di cut-off per garantire valori di False Positive
Rate desiderati e studiare il classificatore in termini di True Positive Rate.
6.2. Costruzione del Dataset
Viene ora descritta la procedura relativa alla costruzione del Dataset usata per
addestrare e validare il classificatore.
6.2.1. Riferimenti Temporali per il Dataset
Poiché la tesi si propone di valutare la previsione di ticket in seguito a lettura dei
KPI, e non avendo indicazioni dal committente riguardanti la lunghezza della
previsione e il numero di previsioni da fare al giorno sono state fissate delle variabili
temporali per studiare dove si ottengono i migliori risultati e per valutare quale può
essere l’orizzonte di predizione utile per il committente.
Le variabili temporali fissate sono le seguenti:
• W (in ore): lunghezza della finestra temporale in cui si calcola una feature come
aggregato delle letture di KPI (per quanto tempo raccolgo i dati);
• G (in ore): gap (quanto tempo prima ho a disposizione la predizione);
• H (in ore): lunghezza dell’orizzonte di predizione (per quanto tempo vale la
predizione).
Se t è l’istante in cui genero una predizione, allora vengono raccolte osservazioni tra
t-W e t; all’istante t genero una predizione valida per l’intervallo tra t+G e t+G+H.
Figura 5: Finestre Temporali W, G e H

26. 22
Sono stati scelti diversi valori per le 3 variabili e combinati tra loro ottenendo così
Dataset diversi su cui si sono valutate le prestazioni:
• W=12 (h);
• H= 0.25, 1, 4, 8(h);
• G= da 0 a 24 (h) a intervalli di 1 ora.
6.2.2. Creazione delle Feature
Per ogni KPI preso in considerazione sono state realizzate 5 feature attraverso cinque
distinte funzioni di aggregazione relative alla finestra temporale W. Le funzioni
utilizzate sono le seguenti:
• Massimo: max(()) = * ( | ( > () ∀ = 1, … , }
• Minimo: min(()) = * ( | ( < () ∀ = 1, … , }
• Media: med(()) =
∑ 788
9
: = 1, … , }
• Conteggio degli errori: c_err(()) = ∑ >(())) : >(()) = ?
1 () = −3
0 AB C
• Conteggio dei dati non disponibili:
c_na(()) = D >(())
)
: >(()) = ?
1 () ∈ *−1, −2, −4, −5, −6}
0 AB C
I KPI considerati per lo sviluppo del progetto sono i seguenti:
Per CDSeQuMo:
• Raggiungibilità (s)
• Packet Loss (pl, tx, rx)
• Download Rate (ib)
• Upload Rate (ob)
• Latenza http (h)
• Latenza dns ( d oppure icmp in base al tipo di Vendor)
Per SeQuMo:
• Latenza http (h)
• Latenza dns ( d oppure icmp in base al tipo di Vendor)
• Reboot (dr)
• Interface Up (iu)
• Interface Down (id)
Mentre sono stati esclusi i seguenti KPI in quanto non sempre presenti su tutti i
dispositivi:
• QOS (qos)
• MOS (m)
• Flussi Ima

27. 23
6.2.3. Scelta dei Ticket
Per ridurre al minimo il rumore presente all’interno dei ticket si è effettuata una
selezione in quanto i ticket forniti dal committente erano relativi, oltre che a guasti e
disservizi sulla linea, anche a riconfigurazioni del dispositivo o a situazioni anomale
non predicibili in alcun modo dalla lettura dei KPI.
Sono stati pertanto filtrati così i ticket:
• rimossi i Ticket automatici del Portale di Monitoring
• rimossi i Ticket con CLOSE_CODE: No_Trouble_Found
• rimossi i Ticket aperti durante il periodo di lavori programmati
• tra i rimanenti, considerati solo i primi ticket aperti per ogni link reference
• tra i rimanenti, considerati solo quelli con una CLOSE_CODE che effettivamente
indicasse un guasto o disservizio sulla linea
Ottenendo così un sottoinsieme significativo di ticket relativi a problemi di linea.
6.2.3. Scelta dei Campioni
Per quanto riguarda la creazione dei campioni significativi per addestrare e validare
l’algoritmo di classificazione si è proceduto al seguente modo:
Sia LR l’insieme dei Link Reference:
1. Identifico l’insieme TT di ticket costruito come sopra;
2. Partiziono LA in due sottoinsiemi:
• LRsi
contenente i link reference che hanno generato un ticket di TT;
• LRno
contenente i link reference che non hanno generato nessun ticket di TT.
3. Costruisco il dataset D come unione di:
• Dsi
, n1 istanze per ogni elemento di LRsi
(n1=H*4);
• Dno
, n2 (n2 = 3) istanze per ogni elemento di LRno
; n3 (n3=3) istanze per ogni
elemento di LRsi
; ogni istanza corrisponde ad una finestra W;
• nessuna finestra W contiene una apertura di ticket
Numero di Istanze SI = |LRsi
|* H * 4
Numero di Istanze NO = 3*|LRsi
| + 3*|LRno
| = |LR|*3

28. 24
6.2.4. Trattamento dei Missing Values
Quando si ha a che fare con dati provenienti dal mondo reale è impossibile non
imbattersi nel problema dei dati mancanti. Molto spesso i record presentano alcune
variabili per le quali non è noto il valore. In generale un numero di Missing Values
inferiore al 5% sul totale del dataset viene considerato solitamente gestibile, valori
dal 5% al 15% richiedono metodi ad hoc, mentre valori superiori al 15% sono
difficilmente gestibili. Per quanto riguarda lo sviluppo del progetto si è optato per
sostituire i valori mancanti con la media dei valori della feature su tutto il Dataset.
6.2.5. Trattamento dei dati sbilanciati
Nel caso trattato ci si è trovati difronte alla creazione di Dataset sbilanciati, ovvero
Dataset in cui una classe è presente in numero molto maggiore rispetto ad un’altra.
Nel nostro caso specifico la classe relativa alle istanze NO ha il rapporto con la
classe delle istanze SI di 1000:1. Ovviamente lo sbilanciamento dei dati in questione
è intrinseco al problema stesso e non causato da una raccolta sbilanciata dei dati. La
soluzione proposta per ovviare allo sbilanciamento dei dati è quella di adottare un
approccio Cost-Sensitive ovvero associando, durante la fase di training, un diverso
costo dell’errore per classe; il costo è stato assegnato in modo da essere inversamente
proporzionale alla cardinalità della classe stessa assegnando pertanto un peso
maggiore alla classe di minoranza.

29. 25
6.3. Prestazioni del classificatore
Vengono ora valutati i risultati forniti fornendo un approfondimento relativo alle
prestazione del classificatore creato in relazione ai parametri temporali G e H.
6.3.1. CDSeQuMo
Relativamente al sistema CDSeQuMo si possono fare le seguenti considerazioni:
6.3.1.1. True Positive Rate
Per quanto riguarda le prestazioni in termini di True Positive Rate si può notare come
i risultati migliori si ottengano all’aumentare della finestra di previsione H.
Per quanto riguarda la previsione con H pari a 15 minuti (0,25 ore) si segnala come
all’aumentare del Gap G ci sia un calo si prestazioni in termini di TPR passando da
un massimo di 0,8 a un minimo di 0,6 , mentre considerando una finestra di
previsione maggiore non c’è un calo significativo delle performance.
Figura 6: TPR per CDSeQuMo
CDSeQuMo

30. 26
6.3.1.2. False Positive Rate
Nonostante l’aumentare di H porti dei miglioramenti in termini di TPR, la situazione
invece si ribalta nella valutazione dei False Positive Rate (o FPR). Come si evince
dal grafico sottostante il tasso dei falsi positivi aumenta, fino addirittura a triplicare
rispetto al caso migliore, all’aumentare della finestra di previsione H.
Nonostante siano valori molto bassi questi ultimi non vanno sottovalutati in relazione
al problema considerato: infatti considerando che l’apparato CDSeQuMo monitora
7000 dispositivi diversi e supponendo un numero di previsioni al giorno pari a 10 per
ogni linea, ciò comporta potenzialmente un numero di falsi positivi pari a 700 nel
caso migliore (H = 1) e 2100 nel caso peggiore (H=8).
A tal proposito si è scelto di valutare le prestazioni del classificatore agendo sulla
soglia del classificatore stesso per migliorare le prestazioni in termini di False
Positive Rate e analizzare come una variazione in tal senso modifica le prestazioni in
Figura 7: FPR per CDSeQuMo
CDSeQuMo

31. 27
termini di True Positive Rate. Sono stati pertanto fissati due indici di False Positive
Rate e letto il corrispettivo valore di True Positive per ogni curva ROC creata. Per
quanto riguarda gli indici fissati si è optato per un valore di False Positive pari a 0,01
e 0,0015 ottenendo rispettivamente gli indici TPR@1% e TPR@0,15%.
6.3.1.3. True Positive Rate @1%
Analizzando il grafico è chiaro come impostando cut-off di FPR pari a 0,01 le
prestazioni non cambino in maniera significativa rispetto all’indice di TPR con una
soglia del classificatore di default.
Figura 8: TPR@1% per CDSeQuMo
CDSeQuMo

32. 28
6.3.1.4. True Positive Rate @0,15%
Situazione ben diversa la si ha andando a impostare un cut-off sul FPR pari a 0,015.
Per quanto riguarda le previsioni con finestra temporale pari a 15 minuti le
performance in termini di TPR si aggirano sul 20% cioè si riuscirebbe a prevedere
solo un quinto dei ticket totali. D’altra parte per valori di H maggiori di un’ora si può
notare come le prestazioni calino, ma si assestino su valori molto buoni.
Considerando una finestra di previsione maggiore di un’ora e su un totale di 7000
linee e 10 misurazioni al giorno si ha, a fronte di 105 falsi positivi giornalieri, una
previsione dei ticket che si aggira al 75% rispetto alla totalità dei ticket.
Si ritiene pertanto che questi ultimi rappresentino dei risultati più interessanti per il
committente in quanto una diminuzione di un ordine di grandezza dei falsi positivi
comporta un calo delle prestazioni in termini di TPR in media del solo 20%.
Figura 9: TPR@0,15% per CDSeQuMo
CDSeQuMo

33. 29
6.3.2. SeQuMo
Relativamente alla macchina SeQuMo si possono fare le seguenti considerazioni:
6.3.2.1. True Positive Rate
Analogamente al classificatore applicato alla macchina CDSeQuMo, per quanto
riguarda le prestazioni in termini di True Positive Rate si può apprezzare come i
risultati migliori si ottengano all’aumentare della finestra di previsione H.
Per quanto riguarda nello specifico la previsione con H pari a 15 minuti (0,25 ore) si
segnala come all’aumentare del Gap G ci sia un calo si prestazioni in termini di TPR
soprattutto dopo le 12 ore passando da un massimo di 0,8 a un minimo di 0,6 ,
mentre considerando una finestra di previsione maggiore non c’è un calo così
significativo delle performance.
Figura 10: TPR per SeQuMo
SeQuMo

34. 30
6.3.2.2. False Positive Rate
Nonostante l’aumentare di H porti dei miglioramenti in termini di TPR, la situazione
invece si ribalta nella valutazione dei False Positive Rate (o FPR). Come si evince
dal grafico sottostante il valore relativo dei falsi positivi aumenta , fino addirittura a
triplicare rispetto al caso migliore, all’aumentare della finestra di previsione H.
Si può notare come il False Positive Rate sia di gran lunga più elevato rispetto al
False Positive Rate ottenuto con il classificatore relativo a CDSeQuMo. Tenendo in
considerazione che è stato applicato lo stesso processo per entrambe le
macchine di monitoraggio si può fare una considerazioni su come le feature (e
pertanto i relativi KPI ) di CDSeQuMo abbiano una maggior correlazione con
l’apertura dei ticket rispetto alle feature di SeQuMo.
Analogamente a quanto fatto per CDSeQuMo vengono ora valutate le prestazioni del
classificatore andando a fissare un valore di cut-off sul FPR per analizzarne il TPR.
Figura 11: FPR per SeQuMo
SeQuMo

35. 31
6.3.2.3. True Positive Rate @1%
Impostando un cut-off sul FPR pari a 0,1 e indipendentemente dalla finestra di
previsione si può sostenere che il TPR cali all’aumentare del gap G e assuma
globalmente valori tra compresi tra il 50% e il 90%.
È da notare, e a tal proposito ci si propone di svolgere un’analisi più approfondita, un
andamento anomalo della curva per Gap compreso tra le 10 e le 20 ore. Questo
potrebbe essere sinonimo di una scelta errata dei campioni significativi oppure indice
di una certa stagionalità oraria nell’apertura dei ticket da parte della clientela del
committente.
Figura 12: TPR@1% per SeQuMo
SeQuMo

36. 32
6.3.2.4. True Positive Rate @0.15%
Impostando un cut-off sul FPR pari a 0,015 e indipendentemente dalla finestra di
previsione si può sostenere che il TPR cali all’aumentare del gap G e assuma
globalmente valori tra compresi tra il 30% e il 70%.
In questo caso si sottolinea come si possano ottenere risultati con un True Positive
Rate pari al 60% solo per valori di gap molto bassi e inferiori alle 5 ore. D’altra
parte va considerato che SeQuMo monitora all’incirca 30000 dispositivi e,
supponendo un numero di previsioni pari a 10 per linea, si ottengono giornalmente
all’incirca 450 falsi positivi al giorno.
Figura 13: TPR@0,15% per SeQuMo
SeQuMo

37. 33
6.3.3. Valutazione delle prestazioni in ambito di
applicazione reale.
Vengono ora contestualizzati i risultati ottenuti fornendo un possibile scenario di
gestione dei ticket con il classificatore.
Supponiamo di voler fornire al CRM uno strumento di supporto durante l’orario
d’ufficio (9-17) relativamente alla possibile apertura di ticket da parte dell’utenza
CDSeQuMo. Viene suggerita pertanto questa strategia: fornire al CRM due
previsioni al giorno, una relativa alla mattina e una relativa al pomeriggio in modo
tale da allertare gli addetti ai lavori fornendo indicazioni sul possibile carico di
lavoro in arrivo e in modo da permettere una migliore gestione della forza lavoro in
termini di risorse umane nell’arco della giornata.
Lo specifico ambito applicativo richiede una finestra di previsione H pari a 4 ore e un
gap G di 1 ora per fornire al CRM il tempo necessario ad allocare le risorse. I dati
relativi a CDSeQuMo con H=4h e G=1h sono a tal proposito molto promettenti:
infatti in questo caso si ha una predizione dei ticket pari al 78% con un False Positive
Rate dello 0,15%. Contestualizzando le percentuali si può supporre che, a fronte di
100 ticket reali nell’arco della giornata, ne vengano predetti correttamente 78 e
vengano generati 18 falsi allarmi.
In alternativa è possibile fornire indicazioni utili coprendo l’intero della giornata
generando predizioni per 24 volte in un giorno (con H =1h) o per 3 volte in un giorno
(con H=8h). In entrambi i casi si possono prevedere ticket con una precisione del
75%, e un False Positive Rate dello 0,15%. È tuttavia da tenere in considerazione che
il numero di Falsi Positivi che genera la macchina è direttamente proporzionale al
numero di previsioni fatte, pertanto con 24 previsioni al giorno si generano
all’incirca 200 falsi positivi e con 3 previsioni al giorno se ne generano appena 27
pur mantenendo la stessa percentuale di previsione dei True Positive.

38. 34
7. Conclusioni
Lo sviluppo del progetto commissionato è risultato di grosso interesse anche a livello
formativo. L’utilizzo di un software come R Studio mi ha dato la possibilità di
studiare e analizzare oltre che un nuovo tool, un nuovo linguaggio di manipolazione
e rappresentazione di dati.
Lo sviluppo del progetto è stato inizialmente lento a causa dello studio e dell’analisi
dei sistemi preesistenti, ma una volta compreso il sistema nel suo complesso si è
impiegato del tempo utile nella comprensione del linguaggio utilizzato e delle
rispettive librerie velocizzando l’intero sviluppo.
È curioso da segnalare come la libertà fornita dal committente si sia rivelata un’arma
a doppio taglio: non avendo chiari gli obbiettivi da sviluppare si è optato per un
problema che comprendesse il maggior numero di utenza monitorata senza entrare
troppo nel dettaglio delle linee e delle loro eventuali criticità.
Mi ritengo piuttosto soddisfatto della possibilità fornitami, poiché l’apprendimento di
un tool a me sconosciuto all’inizio del progetto, e la possibilità di toccare con mano
metodologie e tecniche di Machine Learning rappresentano una branca del computer
science che dovrebbero far parte del bagaglio culturale di ogni Ingegnere
Informatico.
Possibili sviluppi futuri del progetto sono:
• Presentazione delle prestazioni al committente;
• Inserimento in produzione del classificatore con taratura dello stesso e valutazione
delle performance nell’ambiente reale;
• Suddividere il classificatore in base a differenti tipologie di linee;
• Progettazione e sviluppo di un classificatore per la previsione di guasti di linea;
• Estensione del classificatore creato attraverso l’aggiunta di feature provenienti da
altri sistemi di monitoraggio.

39. 35
Bibliografia
Phil Spector. Data Manipulation with R.
Peter Dalgaard. Introductory Statistics with R
Shai Shalev-Shwartz. Understanding Machine Learning: From Theory to Algorithms
Jason Bell. Machine Learning: Hands-On for Developers and Technical
Professionals
J. Ross Quinlan. Induction of decision trees
Peter Harrington. Machine Learning in Action
Documentazione JAVA
· http://docs.oracle.com/javase/6/docs/api/
Documentazione R
- http://www.r-project.org/
Indice delle figure
Figura 1: Workflow CPE…………………………………………………………………………………..…pag 5
Figura 2: Organizzazione Macchine di monitoraggio………………………………………….pag 6
Figura 3: Schema di funzionamento di SeQuMo…………………………………………….pag 10
Figura 4: Esempio di Curva ROC………………………………………………………………………pag 20
Figura 5: Finestre Temporali W, G e H……………………………………………………………..pag 21
Figura 6: TPR per CDSeQuMo………………………………………………………………………..pag 25
Figura 7: FPR per CDSeQuMo………………………………………………………………………..pag 26
Figura 8: TPR@1% per CDSeQuMo………………………………………………………………..pag 27
Figura 9: TPR@0,15% per CDSeQuMo……………………………………………………………pag 28
Figura 10: TPR per SeQuMo…………………………………………………………………………..pag 29
Figura 11: FPR per SeQuMo…………………………………………………………………………..pag 30
Figura 12: TPR@1% per SeQuMo…………………………………………………………………..pag 31
Figura 13: TPR@0,15% per SeQuMo……………………………………………………………..pag 32

40. 36
Appendice A – Risultati Numerici
A.1 CDSeQuMo
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 0 0.25 0.0089 0.7960 0.9899 0.8935 0.9086 0.1467 0.3249 0.6258
12 1 0.25 0.0101 0.7163 0.9886 0.8531 0.8885 0.1749 0.2755 0.6085
12 2 0.25 0.0104 0.7128 0.9881 0.8512 0.8805 0.1841 0.1716 0.5361
12 3 0.25 0.0104 0.6707 0.9881 0.8301 0.8798 0.1878 0.1366 0.6219
12 4 0.25 0.0106 0.6081 0.9876 0.7988 0.8803 0.1893 0.2485 0.5371
12 5 0.25 0.0107 0.6998 0.9878 0.8445 0.8888 0.1650 0.1745 0.5829
12 6 0.25 0.0106 0.6388 0.9878 0.8141 0.8848 0.1779 0.2656 0.5611
12 7 0.25 0.0108 0.5544 0.9870 0.7718 0.8934 0.1603 0.2249 0.6052
12 8 0.25 0.0097 0.5987 0.9879 0.7945 0.8808 0.1835 0.1750 0.6043
12 9 0.25 0.0098 0.6124 0.9877 0.8013 0.8828 0.1822 0.2281 0.6416
12 10 0.25 0.0095 0.6345 0.9882 0.8125 0.8852 0.1767 0.1396 0.5885
12 11 0.25 0.0093 0.6277 0.9883 0.8092 0.8768 0.1875 0.3504 0.6260
12 12 0.25 0.0094 0.6161 0.9880 0.8033 0.8769 0.1857 0.1325 0.5907
12 13 0.25 0.0094 0.5915 0.9877 0.7910 0.8858 0.1756 0.1247 0.5293
12 14 0.25 0.0097 0.5772 0.9877 0.7838 0.8845 0.1748 0.2301 0.5830
12 15 0.25 0.0101 0.5189 0.9870 0.7544 0.8815 0.1769 0.1580 0.5550
12 16 0.25 0.0101 0.5025 0.9869 0.7462 0.8704 0.1915 0.1417 0.5875
12 17 0.25 0.0098 0.5477 0.9875 0.7689 0.8788 0.1821 0.1284 0.5271
12 18 0.25 0.0096 0.5849 0.9877 0.7877 0.8805 0.1795 0.1923 0.6137
12 19 0.25 0.0099 0.5676 0.9874 0.7788 0.8760 0.1890 0.1811 0.5834
12 20 0.25 0.0107 0.6098 0.9876 0.7996 0.8726 0.1915 0.1545 0.5402
12 21 0.25 0.0110 0.5328 0.9871 0.7609 0.8745 0.1887 0.1153 0.6296
12 22 0.25 0.0110 0.5321 0.9869 0.7605 0.8749 0.1861 0.1378 0.5507
12 23 0.25 0.0110 0.5519 0.9868 0.7704 0.8651 0.2068 0.1305 0.5451
12 24 0.25 0.0109 0.6465 0.9876 0.8178 0.8782 0.1886 0.1799 0.6452
12 0 1 0.0102 0.9085 0.9861 0.9492 0.9391 0.0957 0.7219 0.8752
12 1 1 0.0087 0.9290 0.9884 0.9602 0.9438 0.0888 0.8322 0.8776
12 2 1 0.0072 0.9222 0.9893 0.9575 0.9466 0.0814 0.7286 0.9113
12 3 1 0.0072 0.9129 0.9888 0.9529 0.9469 0.0811 0.7880 0.9116
12 4 1 0.0071 0.9081 0.9887 0.9505 0.9559 0.0731 0.8154 0.9140
12 5 1 0.0074 0.9240 0.9892 0.9583 0.9525 0.0737 0.8123 0.9015
12 6 1 0.0078 0.9112 0.9882 0.9517 0.9446 0.0885 0.7038 0.9045
12 7 1 0.0076 0.9129 0.9886 0.9526 0.9556 0.0719 0.7468 0.9068
12 8 1 0.0071 0.9080 0.9887 0.9504 0.9569 0.0668 0.7185 0.9134
12 9 1 0.0073 0.9003 0.9881 0.9465 0.9520 0.0823 0.7065 0.9166
12 10 1 0.0072 0.9095 0.9888 0.9511 0.9556 0.0706 0.7115 0.9034
12 11 1 0.0070 0.9023 0.9885 0.9476 0.9545 0.0726 0.7076 0.8905

41. 37
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 12 1 0.0071 0.9064 0.9886 0.9496 0.9482 0.0857 0.7049 0.9167
12 13 1 0.0065 0.8996 0.9889 0.9466 0.9560 0.0740 0.6823 0.9124
12 14 1 0.0080 0.8978 0.9874 0.9449 0.9531 0.0750 0.7502 0.8897
12 15 1 0.0075 0.8991 0.9880 0.9458 0.9469 0.0852 0.6526 0.9173
12 16 1 0.0067 0.9060 0.9890 0.9496 0.9526 0.0750 0.6562 0.9152
12 17 1 0.0082 0.9017 0.9874 0.9467 0.9522 0.0776 0.6681 0.9005
12 18 1 0.0064 0.9016 0.9890 0.9476 0.9506 0.0771 0.6833 0.9297
12 19 1 0.0071 0.9104 0.9888 0.9517 0.9531 0.0740 0.7153 0.9118
12 20 1 0.0074 0.9083 0.9885 0.9505 0.9494 0.0786 0.7097 0.8846
12 21 1 0.0065 0.9005 0.9888 0.9470 0.9491 0.0773 0.7163 0.9117
12 22 1 0.0067 0.9057 0.9889 0.9495 0.9496 0.0751 0.7227 0.8898
12 23 1 0.0070 0.9089 0.9888 0.9509 0.9441 0.0843 0.6976 0.8928
12 24 1 0.0065 0.9060 0.9890 0.9497 0.9498 0.0744 0.7000 0.9125
12 0 4 0.0233 0.9660 0.9750 0.9714 0.9682 0.0555 0.8112 0.9035
12 1 4 0.0233 0.9715 0.9758 0.9741 0.9685 0.0513 0.8314 0.9052
12 2 4 0.0228 0.9708 0.9762 0.9740 0.9624 0.0681 0.8366 0.9044
12 3 4 0.0220 0.9694 0.9766 0.9737 0.9658 0.0655 0.8234 0.8855
12 4 4 0.0216 0.9684 0.9768 0.9734 0.9668 0.0615 0.8227 0.9011
12 5 4 0.0207 0.9692 0.9776 0.9742 0.9637 0.0673 0.8193 0.9170
12 6 4 0.0207 0.9678 0.9774 0.9735 0.9641 0.0695 0.8925 0.9118
12 7 4 0.0207 0.9697 0.9777 0.9745 0.9636 0.0697 0.8335 0.9209
12 8 4 0.0192 0.9651 0.9782 0.9730 0.9627 0.0698 0.7970 0.9307
12 9 4 0.0191 0.9651 0.9783 0.9730 0.9591 0.0703 0.7996 0.9130
12 10 4 0.0185 0.9667 0.9791 0.9741 0.9623 0.0687 0.8164 0.9325
12 11 4 0.0184 0.9642 0.9786 0.9729 0.9605 0.0697 0.8146 0.9215
12 12 4 0.0187 0.9676 0.9790 0.9745 0.9570 0.0704 0.7993 0.9148
12 13 4 0.0185 0.9681 0.9793 0.9748 0.9567 0.0672 0.8024 0.9193
12 14 4 0.0193 0.9678 0.9786 0.9743 0.9572 0.0688 0.7775 0.9160
12 15 4 0.0187 0.9683 0.9792 0.9748 0.9519 0.0779 0.8008 0.9230
12 16 4 0.0176 0.9692 0.9802 0.9758 0.9563 0.0673 0.7894 0.9182
12 17 4 0.0183 0.9693 0.9796 0.9755 0.9566 0.0689 0.7825 0.9233
12 18 4 0.0179 0.9686 0.9798 0.9754 0.9585 0.0751 0.8014 0.9177
12 19 4 0.0183 0.9684 0.9794 0.9751 0.9580 0.0698 0.8115 0.9224
12 20 4 0.0201 0.9683 0.9780 0.9741 0.9565 0.0708 0.8051 0.9259
12 21 4 0.0199 0.9679 0.9781 0.9740 0.9506 0.0769 0.8216 0.9143
12 22 4 0.0203 0.9679 0.9777 0.9738 0.9527 0.0753 0.7921 0.9243
12 23 4 0.0204 0.9690 0.9778 0.9743 0.9543 0.0766 0.7916 0.9247
12 24 4 0.0196 0.9702 0.9787 0.9753 0.9498 0.0796 0.8053 0.9234
12 0 8 0.0278 0.9594 0.9684 0.9658 0.9750 0.0453 0.8161 0.8941
12 1 8 0.0278 0.9604 0.9687 0.9663 0.9750 0.0446 0.7980 0.9021
12 2 8 0.0284 0.9607 0.9684 0.9661 0.9753 0.0484 0.8467 0.9015
12 3 8 0.0295 0.9606 0.9676 0.9655 0.9745 0.0474 0.8390 0.9080

42. 38
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 4 8 0.0284 0.9592 0.9680 0.9654 0.9745 0.0452 0.8355 0.8987
12 5 8 0.0274 0.9605 0.9690 0.9665 0.9744 0.0480 0.8297 0.9078
12 6 8 0.0276 0.9615 0.9692 0.9669 0.9743 0.0471 0.8399 0.9078
12 7 8 0.0269 0.9592 0.9690 0.9662 0.9742 0.0451 0.8326 0.9130
12 8 8 0.0253 0.9614 0.9708 0.9681 0.9741 0.0485 0.8122 0.9084
12 9 8 0.0273 0.9609 0.9693 0.9668 0.9742 0.0486 0.8377 0.9168
12 10 8 0.0275 0.9636 0.9698 0.9680 0.9749 0.0454 0.8189 0.9191
12 11 8 0.0260 0.9652 0.9714 0.9696 0.9739 0.0490 0.8295 0.9220
12 12 8 0.0290 0.9655 0.9694 0.9682 0.9732 0.0501 0.8227 0.9150
12 13 8 0.0301 0.9731 0.9708 0.9715 0.9724 0.0483 0.8166 0.9219
12 14 8 0.0305 0.9685 0.9690 0.9690 0.9728 0.0503 0.7897 0.9262
12 15 8 0.0295 0.9656 0.9690 0.9680 0.9725 0.0560 0.8190 0.9161
12 16 8 0.0306 0.9710 0.9698 0.9702 0.9717 0.0501 0.7864 0.9193
12 17 8 0.0270 0.9638 0.9703 0.9684 0.9741 0.0500 0.7775 0.9265
12 18 8 0.0273 0.9650 0.9704 0.9688 0.9719 0.0523 0.8050 0.9238
12 19 8 0.0304 0.9684 0.9691 0.9690 0.9711 0.0512 0.8099 0.9241
12 20 8 0.0289 0.9607 0.9680 0.9659 0.9707 0.0512 0.8144 0.9119
12 21 8 0.0307 0.9663 0.9684 0.9678 0.9680 0.0588 0.8129 0.9185
12 22 8 0.0295 0.9626 0.9681 0.9665 0.9714 0.0534 0.8075 0.9166
12 23 8 0.0317 0.9699 0.9687 0.9691 0.9716 0.0518 0.7992 0.9250
12 24 8 0.0312 0.9693 0.9689 0.9691 0.9692 0.0615 0.8206 0.9203

43. 39
A.2 SeQuMo
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 0 0.25 0.0044 0.8293 0.9926 0.9124 0.9720 0.0492 0.5862 0.9060
12 1 0.25 0.0061 0.8290 0.9913 0.9115 0.9585 0.0716 0.5327 0.8564
12 2 0.25 0.0071 0.8292 0.9904 0.9111 0.9480 0.0894 0.5157 0.8260
12 3 0.25 0.0077 0.8192 0.9898 0.9057 0.9407 0.1007 0.4273 0.8036
12 4 0.25 0.0088 0.7949 0.9885 0.8931 0.9333 0.1112 0.3973 0.7623
12 5 0.25 0.0090 0.7776 0.9881 0.8843 0.9311 0.1138 0.4156 0.7497
12 6 0.25 0.0090 0.7870 0.9883 0.8890 0.9244 0.1244 0.4003 0.7369
12 7 0.25 0.0093 0.7820 0.9880 0.8864 0.9255 0.1213 0.4057 0.7147
12 8 0.25 0.0094 0.7884 0.9882 0.8895 0.9346 0.1049 0.4290 0.7037
12 9 0.25 0.0090 0.8106 0.9889 0.9008 0.9487 0.0880 0.4225 0.6985
12 10 0.25 0.0092 0.8148 0.9887 0.9028 0.9474 0.0911 0.4077 0.6950
12 11 0.25 0.0097 0.8052 0.9882 0.8978 0.9405 0.1012 0.4465 0.6520
12 12 0.25 0.0108 0.7928 0.9871 0.8910 0.9262 0.1182 0.3425 0.6224
12 13 0.25 0.0130 0.7458 0.9850 0.8664 0.9032 0.1441 0.2491 0.5252
12 14 0.25 0.0140 0.7196 0.9840 0.8528 0.8880 0.1600 0.2010 0.4925
12 15 0.25 0.0154 0.6798 0.9829 0.8322 0.8713 0.1838 0.1512 0.4540
12 16 0.25 0.0161 0.6464 0.9823 0.8152 0.8606 0.1968 0.1637 0.4261
12 17 0.25 0.0159 0.6427 0.9823 0.8134 0.8484 0.2145 0.1355 0.4354
12 18 0.25 0.0155 0.6758 0.9827 0.8302 0.8397 0.2272 0.1721 0.4622
12 19 0.25 0.0151 0.6591 0.9827 0.8220 0.8392 0.2314 0.1639 0.4898
12 20 0.25 0.0141 0.6499 0.9830 0.8179 0.8542 0.2149 0.1816 0.5343
12 21 0.25 0.0136 0.6560 0.9834 0.8212 0.8910 0.1668 0.2029 0.5784
12 22 0.25 0.0130 0.6762 0.9840 0.8316 0.9340 0.1036 0.2024 0.6252
12 23 0.25 0.4600 0.6292 0.5707 0.5846 0.5968 0.4244 0.0020 0.0183
12 24 0.25 0.0127 0.6615 0.9839 0.8244 0.9437 0.0880 0.1929 0.6371
12 0 1 0.0108 0.9372 0.9857 0.9632 0.9954 0.0231 0.6326 0.9207
12 1 1 0.0126 0.9351 0.9840 0.9612 0.9941 0.0300 0.6262 0.8789
12 2 1 0.0131 0.9289 0.9831 0.9579 0.9924 0.0352 0.5743 0.8596
12 3 1 0.0140 0.9133 0.9812 0.9496 0.9875 0.0420 0.5487 0.8416
12 4 1 0.0157 0.8912 0.9781 0.9377 0.9853 0.0485 0.6042 0.8200
12 5 1 0.0155 0.8901 0.9783 0.9373 0.9861 0.0499 0.6102 0.8136
12 6 1 0.0165 0.8906 0.9775 0.9371 0.9862 0.0493 0.5791 0.8000
12 7 1 0.0180 0.8970 0.9768 0.9395 0.9847 0.0513 0.5407 0.7833
12 8 1 0.0202 0.9037 0.9755 0.9418 0.9875 0.0472 0.5274 0.7629
12 9 1 0.0225 0.9150 0.9742 0.9463 0.9895 0.0436 0.4944 0.7756
12 10 1 0.0245 0.9134 0.9723 0.9445 0.9894 0.0443 0.4912 0.7657
12 11 1 0.0268 0.9138 0.9702 0.9435 0.9891 0.0450 0.4533 0.7467
12 12 1 0.0310 0.8981 0.9656 0.9335 0.9845 0.0552 0.3512 0.6671
12 13 1 0.0366 0.8849 0.9601 0.9241 0.9796 0.0633 0.2153 0.6005
12 14 1 0.0389 0.8770 0.9578 0.9191 0.9793 0.0649 0.1689 0.5651

44. 40
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 15 1 0.0414 0.8614 0.9550 0.9100 0.9750 0.0697 0.1892 0.5130
12 16 1 0.0431 0.8631 0.9536 0.9100 0.9673 0.0801 0.2026 0.4837
12 17 1 0.0421 0.8746 0.9548 0.9163 0.9664 0.0819 0.2177 0.5015
12 18 1 0.0411 0.8761 0.9556 0.9175 0.9670 0.0814 0.2005 0.5324
12 19 1 0.0389 0.8791 0.9577 0.9201 0.9600 0.0855 0.2061 0.5548
12 20 1 0.0365 0.8761 0.9597 0.9198 0.9722 0.0680 0.1924 0.5893
12 21 1 0.0347 0.8733 0.9611 0.9193 0.9814 0.0543 0.2457 0.6436
12 22 1 0.0293 0.8661 0.9651 0.9184 0.9870 0.0457 0.2591 0.7007
12 23 1 0.0000 0.8141 0.8146 0.9070 0.8045 0.2351 0.0026 0.0173
12 24 1 0.0277 0.8631 0.9663 0.9177 0.9876 0.0438 0.2756 0.7097
12 0 4 0.0342 0.9698 0.9667 0.9678 0.9957 0.0327 0.6959 0.9011
12 1 4 0.0435 0.9693 0.9592 0.9629 0.9931 0.0436 0.6802 0.8682
12 2 4 0.0484 0.9556 0.9525 0.9536 0.9891 0.0504 0.6737 0.8261
12 3 4 0.0531 0.9491 0.9474 0.9480 0.9843 0.0598 0.6242 0.7710
12 4 4 0.0576 0.9477 0.9434 0.9450 0.9818 0.0676 0.6171 0.7644
12 5 4 0.0625 0.9480 0.9396 0.9428 0.9834 0.0677 0.5890 0.7639
12 6 4 0.0683 0.9513 0.9355 0.9415 0.9845 0.0612 0.5928 0.7562
12 7 4 0.0745 0.9552 0.9309 0.9403 0.9861 0.0567 0.5568 0.7362
12 8 4 0.0792 0.9593 0.9276 0.9401 0.9868 0.0570 0.5236 0.7295
12 9 4 0.0804 0.9592 0.9266 0.9394 0.9868 0.0587 0.4926 0.7272
12 10 4 0.0873 0.9562 0.9201 0.9344 0.9853 0.0630 0.4257 0.6961
12 11 4 0.0899 0.9511 0.9171 0.9306 0.9833 0.0668 0.3630 0.6694
12 12 4 0.1037 0.9455 0.9042 0.9209 0.9800 0.0739 0.3118 0.6147
12 13 4 0.1164 0.9407 0.8920 0.9122 0.9756 0.0822 0.2545 0.5655
12 14 4 0.1265 0.9377 0.8823 0.9056 0.9696 0.0938 0.2641 0.5270
12 15 4 0.1330 0.9347 0.8759 0.9009 0.9633 0.1022 0.2706 0.5052
12 16 4 0.1320 0.9430 0.8780 0.9055 0.9614 0.1052 0.3203 0.5235
12 17 4 0.1305 0.9479 0.8801 0.9087 0.9600 0.1086 0.2905 0.5371
12 18 4 0.1261 0.9540 0.8851 0.9140 0.9604 0.1075 0.3125 0.5631
12 19 4 0.1177 0.9555 0.8931 0.9189 0.9620 0.1076 0.3173 0.5962
12 20 4 0.1048 0.9492 0.9040 0.9222 0.9697 0.1003 0.3248 0.6319
12 21 4 0.0856 0.9409 0.9193 0.9277 0.9756 0.0948 0.3667 0.6767
12 22 4 0.0599 0.9324 0.9385 0.9362 0.9832 0.0767 0.3841 0.7369
12 23 4 0.0599 0.9455 0.9455 0.9362 0.8624 0.1974 0.0061 0.0408
12 24 4 0.0596 0.9308 0.9384 0.9356 0.9832 0.0767 0.4032 0.7289
12 0 8 0.0692 0.9771 0.9470 0.9539 0.9903 0.0523 0.6574 0.8662
12 1 8 0.0926 0.9718 0.9290 0.9396 0.9809 0.0711 0.6352 0.7896
12 2 8 0.1079 0.9668 0.9162 0.9294 0.9743 0.0817 0.6063 0.7340
12 3 8 0.1203 0.9648 0.9063 0.9223 0.9720 0.0891 0.5750 0.7081
12 4 8 0.1301 0.9649 0.8987 0.9174 0.9737 0.0910 0.5541 0.7172
12 5 8 0.1348 0.9649 0.8950 0.9151 0.9764 0.0859 0.5158 0.7061
12 6 8 0.1374 0.9644 0.8928 0.9135 0.9768 0.0842 0.5172 0.6873

45. 41
W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%
12 7 8 0.1370 0.9625 0.8926 0.9128 0.9767 0.0850 0.4604 0.6755
12 8 8 0.1266 0.9539 0.8982 0.9136 0.9760 0.0865 0.4009 0.6676
12 9 8 0.1143 0.9400 0.9033 0.9128 0.9745 0.0894 0.4089 0.6526
12 10 8 0.1021 0.9155 0.9040 0.9067 0.9717 0.0947 0.3614 0.6399
12 11 8 0.0984 0.8983 0.9005 0.9000 0.9685 0.1023 0.3277 0.6183
12 12 8 0.1122 0.8954 0.8904 0.8916 0.9629 0.1131 0.3152 0.5881
12 13 8 0.1392 0.9140 0.8778 0.8874 0.9587 0.1185 0.2894 0.5600
12 14 8 0.1637 0.9225 0.8616 0.8794 0.9528 0.1276 0.2935 0.5188
12 15 8 0.1826 0.9223 0.8464 0.8699 0.9478 0.1405 0.3267 0.5386
12 16 8 0.1837 0.9068 0.8419 0.8616 0.9431 0.1462 0.3929 0.5448
12 17 8 0.1793 0.9044 0.8449 0.8626 0.9437 0.1495 0.3701 0.5496
12 18 8 0.1697 0.9076 0.8533 0.8690 0.9467 0.1511 0.3668 0.5765
12 19 8 0.1548 0.9088 0.8649 0.8770 0.9512 0.1486 0.3600 0.6076
12 20 8 0.1331 0.9030 0.8789 0.8850 0.9584 0.1358 0.3804 0.6359
12 21 8 0.1157 0.9130 0.8941 0.8986 0.9665 0.1162 0.3994 0.6666
12 22 8 0.0859 0.9358 0.9218 0.9249 0.9781 0.0910 0.4063 0.7091
12 23 8 0.0859 0.9719 0.9719 0.9249 0.8542 0.2054 0.0058 0.0387
12 24 8 0.1024 0.9238 0.9067 0.9107 0.9703 0.1039 0.3741 0.6700