Come visto nella sezione precedente, l’evoluzione del sistema simulato `e so- stanzialmente rappresentata da una sequenza di variazioni di stato. Dette variazioni sono rappresentate da eventi, consistenti in informazioni scam- biate tra i vari elementi del sistema simulati. Un evento veicola tutte le informazioni necessarie ad un dato elemento per assumere il successivo sta- to: la durata in termini di tempo (virtuale) della transizione riprodotta ed il nuovo stato dell’elemento coinvolto al termine della stessa. Quando l’evo- luzione del sistema simulato causa una transizione di stato in un elemento, questa viene incapsulata in un evento corrispondente. In questo modo il simulatore riproduce l’evoluzione del sistema come una sequenza di eventi che a loro volta riproducono le transizioni di stato.
Si adotta questa rappresentazione perch`e consente, in generale, di esprimere in maniera compatta l’evoluzione di un sistema ignorando i periodi tempo- rali in cui non si verificano eventi. La granularit`a scelta per le variazioni determina la fedelt`a della simulazione. In questo caso si `e cercato un com- promesso tra una ragionevole fedelt`a e una non eccessiva complicazione della simulazione.
Un evento `e caratterizzato da un certo numero di propriet`a:
• nuovo stato:
come precedentemente anticipato, l’informazione fornita da un evento comprende il nuovo stato che l’elemento interessato deve assumere al termine della transizione da esso rappresentato. Il nuovo stato `e in- capsulato nell’evento mantenendone isolata la rappresentazione; ai fini della gestione degli eventi, non `e infatti necessario conoscere la rap- presentazione dello stato, che viene gestita come informazione opaca. La scelta di precalcolare detto stato e incorporare l’informazione nel- l’evento non `e l’unica possibile. Per esempio, un’alternativa consiste nel calcolare il nuovo stato al termine della transizione. Ai fini della rappresentazione usata dal simulatore, non c’`e sostanziale differenza.
• sorgente e destinazione:
come anticipato precedentemente, le cause di una transizione di stato di un elemento possono essere dovute sia a fattori interni che esterni. Emerge dunque la necessit`a di distinguere i due aspetti, e si identifica la causa della transizione con la sorgente di un determinato evento.
`
E anche possibile che una causa determini pi`u transizioni, quindi pi`u eventi; la destinazione di un evento indica quale elemento deve subire una transizione.
Ad esempio, un guasto interno ad un elemento (come lo scadere del tempo al fallimento) determina un evento con sorgente e destinazione coincidenti con l’identificativo dell’elemento stesso. Invece, una ricon- figurazione della rete generer`a un certo numero di eventi che avran- no per sorgente il sistema di controllo e per destinazione gli elementi coinvolti.
• tipologia:
le possibili transizioni di stato si possono raggruppare in due cate- gorie principali: attivazione o disattivazione di un dato elemento del sistema, o aggiornamento dello stato dello stesso. `E infatti necessario distinguere tra un elemento non attivo, perch`e soggetto a guasto o de- liberatamente disabilitato, oppure attivo ma temporaneamente scarico (ad esempio una linea non utilizzata). Si possono dunque individuare tre tipologie di eventi: attivazioni, disattivazioni, aggiornamenti dello stato interno di un elemento simulato.
• durata:
ogni evento `e caratterizzato da una durata in termini di tempo virtua- le. Dato che durante la simulazione lo stato di un elemento non varia con continuit`a (si veda figura 5.2), la durata di un evento rappresenta il ritardo che avr`a l’adeguamento dello stato dell’elemento di destina- zione. Il ritardo `e calcolato considerando come tempo base il tempo di generazione dell’evento.
Anche il valore del tempo virtuale alla creazione dell’evento viene memorizzato per ragioni di gestione.
• fase:
la transizione di stato rappresentata da un dato evento pu`o essere divisa in fasi, per recuperare almeno parzialmente la risoluzione tem- porale persa nel considerare istantanea la transizione. Il tempo (vir- tuale) totale necessario per completare la transizioni sar`a scomposto in una somma di tempi necessaria a completare le relative fasi. Le fasi individuate saranno esposte in maggior dettaglio nella nella sezione 5.4.1.
5.4.1 Fasi di un evento
Si divide una transizione di stato in due fasi principali: la fase di riconosci- mento e la fase di adeguamento. Nella prima fase, si simula il rilevamento della transizione da parte de l’elemento interessato, mentre nel secondo caso l’elemento adegua effettivamente il proprio stato interno.
Ad esempio, si considera il caso di disabilitazione di una data linea. La transizione di stato consiste nell’aprire gli interruttori della linea stessa. La fase di riconoscimento consiste nell’inviare il comando di apertura degli in- terruttori, tipicamente da remoto mediante controllo automatizzato. La fase di adeguamento comprende l’effettiva apertura degli interruttori. La dura- ta complessiva della transizione di stato comprende la somma delle durate delle singole fasi. `E comunque possibile che la durata di una delle singole fasi di un dato evento sia trascurabile rispetto all’altra; si possono dunque considerare fasi di durata zero in termini di tempo virtuale.
5.4.2 Generazione, propagazione, ricezione degli eventi
In questa sezione si precisano i componenti del simulatore coinvolti nell’in- terscambio di eventi, con riferimento alla strutturazione rappresentata nella figura 5.3 precedente. Le possibili interazioni sono le seguenti:
• da un elemento a se stesso:
un possibile caso di questa interazione `e dato dallo scadere del tempo al fallimento di un dato elemento. In questo caso, essendo la causa inter- na, la sorgente e la destinazione dell’evento coincidono e corrispondono con l’elemento medesimo. Altre possibili cause riguardano comunque guasti interni, come il superamento dei limiti di funzionamento. • da un elemento ad un altro:
un guasto su un componente condiviso o che i meccanismi di prote- zione di un dato elemento non riescono ad arginare si propaga sugli elementi connessi. Si considera ad esempio il caso di un guasto su una sottostazione; nel caso pi`u grave si ha che l’indisponibilit`a della suddetta, a causa di un guasto sui componenti condivisi (barre) causa l’indisponibilit`a di tutte le linee ad essa connesse.
In questo tipo di interazioni si ha che un elemento diverso da quello di destinazione `e la causa, e quindi la sorgente, dell’evento.
• dal sistema di controllo ad uno o pi`u elementi :
l’intervento del sistema di controllo causa una riconfigurazione del si- stema e questo determina chiaramente cambiamenti di stato da parte degli elementi coinvolti. In questo caso la sorgente degli eventi sar`a il sistema di controllo.
• dal sistema di aggiornamento ad uno o pi`u elementi:
in modo simile all’operato del sistema di controllo, anche il sistema di aggiornamento determina un nuovo stato del sistema in seguito a perturbazioni del sistema.
5.4.3 Accodamento degli eventi
La gestione degli eventi all’interno del simulatore prevede la presenza di un componente che si occupa dell’ordinamento e della corretta propagazione degli stessi. In primo luogo, si richiede che gli eventi siano notificati ai ri- spettivi destinatari rispettando la sequenza temporale corretta. Per risolvere un problema si adotta una coda FIFO con priorit`a dove la priorit`a `e data dalla marcatura temporale corrispondente ad ogni evento. Si fa avanzare l’orologio che segna il tempo virtuale ad ogni estrazione dalla coda degli eventi. L’incremento non `e lineare, e corrisponde alla differenza tra il valore attuale del tempo virtuale e l’istante di tempo in cui `e stato creato l’even- to estratto. L’avanzare del tempo virtuale seguir`a quindi un andamento monotono crescente. Si hanno le seguenti propriet`a:
• gli eventi sono notificati nel corretto ordine:
un elemento ricever`a la notifica di un evento occorso al tempo virtuale t prima di uno occorso al tempo virtuale t + k.
• gli eventi possono essere sovrapposti temporalmente:
il simulatore processa effettivamente un solo evento alla volta, in modo sequenziale, ma si possono avere due o pi`u eventi che occorrono e che vengono quindi gestiti al medesimo istante temporale virtuale.
Mediante il campo destinazione di un evento, si pu`o notificare corret- tamente questo all’elemento che deve gestirlo. L’elemento adegua quindi il proprio stato nel modo rappresentato dall’evento stesso.