Processi e Tecnologie dell’Informazione

SISTEMA TESS

D203
Gestione guasti pendenti
per

ACEA Distribuzione S.p.A.

Requisiti funzionali
Versione 1.0
23 maggio 2008

Pag. 1 di 7
 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

Indice dei Contenuti

1. PRESENTAZIONE ...........................................................................................................................................2
1.1 ACRONIMI 2
1.2 VERSIONI 2
2. SCOPO DEL DOCUMENTO............................................................................................................................3

3. DEFINIZIONI. PROCESSO AS IS....................................................................................................................3

4. OBIETTIVI ED AMBITO DELL’INTERVENTO ................................................................................................4

5. REQUISITI FUNZIONALI: PROCESSO TO BE ..............................................................................................4

5.1 PROCESSO: INDIVIDUAZIONE ED ACQUISIZIONE DEI GUASTI PENDENTI 4
5.2 APPLICATIVO W EB: ORIZZONTE DI BLOCCO DELLA MODIFICA DI UN GUASTO PENDENTE 5
5.3 APPLICATIVO W EB: FUNZIONALITÀ DI MODIFICA DI UN GUASTO PENDENTE 5
5.4 APPLICATIVO W EB: POSSIBILITÀ DI MODIFICARE GUASTI IN STATO APERTO PER UTENTI AGR 7

1. Presentazione

1.1 Acronimi

AGR Analisi e Gestione Rete

PTI Processi e Tecnologie dell’Informazione

TESS Trasferimento Eventi STM SIDE

SOE/SOD Sala Operativa Elettrica o Sala Operativa Distribuzione

AEEG Autorità per l’Energia Elettrica ed il Gas

CS Cabina Secondaria

VLSO Validato dalla Sala Operativa

VLGR Validato da AGR

1.2 Versioni
Num.
Data Origine versione Modifiche Approvazione
versione

1.0 23/05/2008 Stesura iniziale N/A

Vietata la riproduzione e la divulgazione Pag. 2 di 7

 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

2. Scopo del documento

Il presente documento espone i requisiti funzionali relativi ad una nuova modalità di acquisizione e gestione dei
guasti pendenti. L’esigenza della CR è maturata in seguito all’analisi di anomalie relative a guasti non acquisiti,
comunicate da A. Gastaldo fra il 10 ed il 16/04/2008.

3. Definizioni. Processo AS IS
Un guasto o evento che provoca interruzione del servizio sulla rete MT/AT si definisce “pendente” se i dati
caricati dal Protocollo di Servizio STM a seguito dell’ultimo lancio di acquisizione (programmato quotidianamente
alle ore 4:00) non consentono di chiudere il guasto rispettando la seguente regola stabilita da AEEG, valida per il
periodo regolatorio 2008 - 2011: Avvenuta rialimentazione di tutti gli elementi rete (quindi di tutti i clienti)
disalimentati con il primo scatto/manovra per almeno un’ora senza soluzione di continuità.

Allo stato attuale, se queste condizioni non si verificano, il processo automatico non acquisisce il guasto, che
quindi non viene registrato nella base dati di TESS, ed emette un log (memorizzato in forma di file testo), che
contiene l’avvertenza “Guasto pendente”, l’elenco di tutte le disalimentazioni/rialimentazioni e le manovre
associabili al guasto non concluso (con indicazione di data/ora, descrizione e CS coinvolta, per ciascun record),
e la motivazione all’origine della mancata chiusura.

Sono tre i casi in cui un guasto rimane “pendente” e non viene acquisito (in tutti i casi il log prodotto dal processo
riporta la motivazione esatta della mancata chiusura dell’elaborazione):

1. (Guasto a cavallo di più giorni) Nella porzione di Protocollo acquisita, non si verificano rialimentazioni di
tutti gli elementi rete inizialmente disalimentati, o si verificano ma sono seguite da nuove
disalimentazioni entro 1 ora (3.600 s). In questo caso, è possibile che il guasto si chiuda e sia acquisito
correttamente in automatico con il lancio del giorno successivo, quando gli eventi di chiusura sono
disponibili nella sezione di Protocollo acquisita.

2. (Scatto intermedio o finale inesistente o non riconosciuto) Nella porzione di Protocollo acquisita, la
sequenza di disalimentazioni e rialimentazioni risponde alle regole AEEG, ma almeno una di loro
(intermedia o finale) non può essere associata ad uno scatto definito come “Scatto iniziale“ o come
“Scatto finale”. Questo può accadere per due motivi: lo scatto in questione non è presente nel Protocollo
esaminato, oppure è presente, ma non è qualificato come “Scatto inizio” o “Scatto fine” nella apposita
tabella di TESS. In questo caso, il guasto non si può chiudere automaticamente, a meno che un
operatore PTI, su richiesta di AGR o dell’Unità Telecontrollo Rete, non introduca il nuovo scatto nella
suddetta tabella.

3. (Scatto iniziale inesistente o non riconosciuto) Nella porzione di Protocollo acquisita, il gruppo di
disalimentazioni iniziali non può essere associato ad uno scatto definito come “Scatto iniziale”, per gli
stessi motivi riportati nel punto precedente.

Nei casi 1 e 2, non è nota la data/ora di fine guasto. Inoltre, in tali casi, a seguito dell’ultimo intervento di
manutenzione correttiva del software, il processo non considera i successivi gruppi di disalimentazioni/
rialimentazioni come disponibili per essere inclusi in altri eventi, evitando così la creazione di guasti spuri.

Nel caso 3, non è nota neanche la data/ora di inizio guasto: infatti, per motivi tecnici di STM, il riferimento è
sempre la data/ora dello scatto/manovra che ha provocato la disalimentazione. Di conseguenza, non essendo
disponibile la data/ora di inizio della ricerca, e non essendo previsto un criterio alternativo per definirla in
assenza di scatto iniziale, l’elaborazione termina prima di cercare gli ulteriori gruppi di disalimentazioni/
rialimentazioni, i quali restano quindi disponibili per concorrere a produrre eventi non corretti.

Vietata la riproduzione e la divulgazione Pag. 3 di 7

 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

Allo stato attuale, un guasto pendente, per essere acquisito, deve essere autogenerato interamente
dall’operatore SOD o AGR in TESS, utilizzando le manovre di Protocollo appropriate o le manovre modello.
L’applicativo TESS ha comunque degli strumenti che consentono di monitorare il grado di completezza dei
guasti acquisiti rispetto al Protocollo STM: si pensi per esempio al report “Ricerca manovre cabine”, che
presenta una lista, per mese/anno, di tutte le disalimentazioni/rialimentazioni non associate a guasti.

4. Obiettivi ed ambito dell’intervento

L’intervento richiesto con la presente CR riguarda tutte le componenti applicative di TESS (processo automatico
ed applicativo Web), e comporta anche modifiche alla struttura della base dati.

Gli obiettivi sono i seguenti:

• Evitare il più possibile l’acquisizione di eventi spuri per effetto di precedenti guasti pendenti che non
hanno “vincolato” gruppi di disalimentazioni/rialimentazioni.

• Agevolare gli operatori nel riconoscimento e nel corretto completamento degli eventi pendenti.

5. Requisiti funzionali: processo TO BE

5.1 Processo: Individuazione ed acquisizione dei guasti pendenti

Il processo automatico dovrà acquisire e registrare nella banca dati di TESS anche gli eventi pendenti, ovvero
quelli incompleti secondo le casistiche sopra riportate (ivi compreso il caso di un guasto con rialimentazioni
complete che si sono verificate dopo le ore 23:00 dell’ultimo giorno elaborato). In particolare, nel caso 3 del
paragrafo precedente, non dovrà interrompere l’elaborazione, ma proseguirla utilizzando come orario di
riferimento provvisorio l’orario minimo del gruppo di disalimentazioni iniziali. In tal caso, anche se la chiusura
dovesse essere effettuata con esito positivo, il guasto sarà comunque considerato incompleto in quanto privo
dello scatto iniziale.

Gli eventi acquisiti avranno le seguenti caratteristiche:

• Nuovo stato “PENDENTE”.

• (Caso 1 par. prec.) Numero guasto (campo con numerazione distinta per brevi/lunghe), Data/ora fine
guasto, Durata guasto (convenzionale) vuoti.

• (Caso 2 par. prec.) Numero guasto (campo con numerazione distinta per brevi/lunghe), Data/ora fine
guasto, Durata guasto (convenzionale) valorizzati facendo riferimento alla data/ora massima del gruppo
di rialimentazioni finali. I campi saranno opportunamente evidenziati (con un colore diverso, ad esempio)
per il loro carattere provvisorio.

• (Caso 3 par. prec.) Data/ora inizio guasto pari alla data/ora minima del gruppo di disalimentazioni iniziali.

o (Se le rialimentazioni finali non sono complete) Numero guasto (campo con numerazione
distinta per brevi/lunghe), Data/ora fine guasto, Durata guasto (convenzionale) vuoti.

o (Se le rialimentazioni finali non sono associate ad uno scatto) Data/ora fine guasto pari alla
data/ora massima del gruppo di rialimentazioni finali; Numero guasto (campo con numerazione
distinta per brevi/lunghe) e Durata guasto (convenzionale) valorizzati facendo riferimento alle

Vietata la riproduzione e la divulgazione Pag. 4 di 7

 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

date/ore a disposizione. I campi saranno opportunamente evidenziati (con un colore diverso, ad

esempio) per il loro carattere provvisorio.

o (Se le rialimentazioni finali sono associate ad uno scatto) Data/ora fine guasto trattata
normalmente; Numero guasto (campo con numerazione distinta per brevi/lunghe) e Durata
guasto (convenzionale) valorizzati facendo riferimento alle date/ore a disposizione. I campi
saranno opportunamente evidenziati (con un colore diverso, ad esempio) per il loro carattere
provvisorio.

• Disalimentazioni/rialimentazioni incluse nella struttura del guasto, ma visualizzate come manovre (colore
nero) se non sono collegate ad uno scatto.

• Disservizi puntuali non calcolati, in quanto la relativa procedura non può girare in presenza di una
struttura incompleta. Relativo indicatore posto a “No”. Di conseguenza non saranno disponibili la Durata
netta, l’indicatore “Interruzione prolungata/estesa” e le interruzioni brevi/lunghe interne all’evento, in
quanto alimentati dalla suddetta procedura.

Le disalimentazioni/rialimentazioni prese dal Protocollo STM e collegate ad un guasto pendente dovranno

essere etichettate in modo distinto rispetto a quelle associate ad eventi completi, e comunque tale da evitare che
il processo, in un lancio successivo, le consideri come disponibili per costruire un nuovo guasto. Esse saranno
quindi “congelate” fino al completamento (automatico o manuale) del guasto pendente, o al suo annullamento
da parte dell’operatore.

Il processo dovrà poi essere modificato in modo tale da elaborare prima i guasti in stato PENDENTE,
riprendendo le relative manovre e cercando di completarli in base alle regole AEEG, e poi le altre manovre
presenti nella porzione di Protocollo acquisita e non ancora associate a guasti.

5.2 Applicativo Web: orizzonte di blocco della modifica di un guasto pendente

Il guasto in stato PENDENTE, ormai caricato nella banca dati di TESS, sarà visibile ad utenti di qualsiasi profilo,
ma non modificabile (nemmeno da utenti con profilo di Amministratore) per un periodo di tempo che potrà
essere parametrizzato (attualmente si ipotizzano 4 giorni solari), e che rappresenta l’orizzonte teorico massimo
di chiusura di un guasto sulla rete MT.

In altre parole, si ipotizza che entro tale orizzonte il processo stesso, avvalendosi dei dati presenti sul Protocollo
STM, possa chiudere il guasto. Al di là di tale orizzonte, si suppone invece che i motivi di mancata chiusura
siano legati ad una carenza strutturale di dati sul Protocollo STM, e che quindi diventi necessaria un’attività di
completamento manuale.

Di seguito sono illustrati due esempi del comportamento atteso, con un orizzonte di 4 giorni solari:

1. un guasto PENDENTE del 10/04/2008, caricato in TESS il giorno 11/04/2008, potrà essere modificato
solo dopo il 14/04/2008, ovvero a partire dal 15/04/2008;

2. un guasto PENDENTE del 10/04/2008, caricato in TESS il giorno 29/04/2008, sarà subito modificabile,
in quanto l’orizzonte di possibile chiusura automatica è stato superato.

5.3 Applicativo Web: funzionalità di modifica di un guasto pendente

Una volta superato il suddetto orizzonte, il guasto potrà essere modificato da utenti di qualsiasi profilo. Le
modalità di modifica saranno analoghe a quelle in vigore con i guasti completi, con le seguenti eccezioni:

• Sarà inibito il pulsante “Report” (un guasto pendente non potrà essere stampato).

Vietata la riproduzione e la divulgazione Pag. 5 di 7

 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

• Non sarà possibile calcolare i disservizi puntuali: tutti i pulsanti del riquadro dedicato a queste
funzionalità (“Aggiorna”, “Lista disservizio” ecc.) saranno inibiti.

Nel seguito, vengono dettagliati gli aggiornamenti e le azioni che l’applicativo dovrà effettuare a seguito di
operazioni condotte su un guasto pendente.

1. Salvataggio (tasto “Salva guasto”)

• saranno effettuati tutti i controlli già attivi in questa fase (in particolare quelli di completezza);

• una volta superati i controlli con esito positivo, lo stato del guasto passerà da PENDENTE ad
APERTO, a meno che non sia stato esplicitamente indicato uno stato diverso (azione possibile solo
per utenti con profilo di Amministratore); il passaggio di stato dovrà essere storicizzato (data/ora e
matricola utente);

• il Numero guasto (campo con numerazione distinta per brevi/lunghe) sarà valorizzato sulla base della
durata convenzionale;

• le disalimentazioni/rialimentazioni acquisite da Protocollo STM ed associate al guasto saranno

etichettate come “Elaborate”, in modo analogo ai guasti completi di oggi (così non saranno più prese
in considerazione dal processo);

• si dovranno sbloccare il pulsante “Report” e le funzionalità di calcolo dei disservizi puntuali.

2. Annullamento (tasto “Annulla guasto”)

• non saranno effettuati i controlli di completezza;

• lo stato del guasto passerà da PENDENTE ad ANNULLA, con storicizzazione del cambiamento
avvenuto;

• le disalimentazioni/rialimentazioni acquisite da Protocollo STM ed associate al guasto saranno

etichettate come “Elaborate”, in modo analogo ai guasti annullati di oggi (così non saranno più prese
in considerazione dal processo).

3. Rilascio (tasto “Rilascio guasto”) senza salvataggi precedenti

• saranno effettuati tutti i controlli attivi al salvataggio (in particolare quelli di completezza);

• superati i suddetti controlli con esito positivo, le disalimentazioni/rialimentazioni acquisite da Protocollo

STM ed associate al guasto saranno etichettate come “Elaborate”, in modo analogo ai guasti completi
di oggi (così non saranno più prese in considerazione dal processo);

• sempre in caso di esito positivo dei controlli del salvataggio, sarà lanciata in background la procedura
di calcolo dei disservizi puntuali (come avviene oggi per i guasti normalmente completati);

• terminata con esito positivo la procedura, lo stato del guasto passerà da PENDENTE a VLSO se
l’autore del rilascio è un utente con profilo Operatore SOD o Amministratore SOD, da PENDENTE a
VLGR se invece è un utente con profilo Operatore AGR; per gli utenti con profilo Amministratore, il
rilascio comporterà il passaggio nello stato indicato nella maschera (se è rimasta l’indicazione
PENDENTE, sarà effettuato comunque il passaggio in APERTO); il passaggio di stato dovrà essere
storicizzato (data/ora e matricola utente);

• in caso di esito negativo della procedura (in base agli stessi criteri validi oggi), il rilascio non sarà
effettuato; lo stato del guasto passerà da PENDENTE in APERTO, con storicizzazione del
cambiamento avvenuto;
Vietata la riproduzione e la divulgazione Pag. 6 di 7
 SISTEMA TESS Redatto da: F. Croce, M. Tullio

D203 Rivisto da: M. Tullio

Gestione guasti pendenti Approvato da:

Processi e Tecnologie Versione 1.0 del 23/05/2008

Requisiti funzionali
dell’Informazione

• il Numero guasto (campo con numerazione distinta per brevi/lunghe) sarà valorizzato sulla base della
durata netta se la procedura di calcolo dei disservizi puntuali si è conclusa con esito positivo, sulla
base della durata convenzionale in caso contrario;

• si dovranno sbloccare il pulsante “Report” e le funzionalità di calcolo dei disservizi puntuali.

Non deve essere possibile, neanche per un utente con profilo Amministratore, far passare un guasto nello stato
PENDENTE. Inoltre, un guasto autogenerato in TESS non potrà essere salvato in stato PENDENTE.

5.4 Applicativo Web: possibilità di modificare guasti in stato APERTO per utenti AGR

Si richiede infine di abilitare il profilo Operatore AGR alla visualizzazione e alla modifica dei guasti in stato
APERTO. In questo caso, se viene utilizzata la funzionalità di rilascio, il guasto dovrà passare da questo stato
direttamente allo stato VLGR, previa esito positivo di tutti i controlli previsti (anche a livello di calcolo dei
disservizi).

Vietata la riproduzione e la divulgazione Pag. 7 di 7