ITMI942634A1 - Procedimento per il riallineamento automatico nel riporto di evento in un sistema di gestione e relativo sistema - Google Patents

Abstract

Viene descritto un procedimento per il riallineamento automatico dell'informazione di stato trasferita da un sottosistema gestito verso uno, o più Gestori mediante la tecnica del riporto di evento. Secondo il procedimento, gli eventi generati da variazioni nelle variabili di stato vengono scritti in una memoria degli eventi, gestita come una coda circolare per mezzo di puntatori. Più processi di lettura indipendenti, ciascuno riferito ad un rispettivo Gestore, leggono la coda in modo non deterministico ed asincrono rispetto alla scrittura. Durante ogni scrittura nella coda può verificarsi perdita di informazione, e quindi disallineamento, qualora le scritture procedano ad un ritmo superiore alle letture. In tal caso il sottosistema gestito se ne accorge, acquisisce una copia del proprio stato attuale, che invia a quei Gestori per cui la coda è in overflow, ed al termine esso invia inoltre gli eventi manifestatisi nel contempo (fig. 3).

Description

DESCRIZIONE

La presente invenzione si riferisce al campo dei sistemi di gestione e più precisamente ad un procedimento di riallineamento di una copia dell'informazione di stato, ricostruita da un Gestore sulla base di "eventi" trasferiti da un sottosistema gestito, con lo stato effettivo del sottosistema gestito; i suddetti eventi essendo costituiti da nuovi valori di variabili che definiscono lo stato.

Gestire un sistema significa innanzitutto svolgere tutte quelle attività che consentono di controllare il funzionamento del sistema stesso. In questo senso, la fig.1 può servire come base per ogni successiva considerazione in materia di sistemi di gestione. In fig.1 è mostrata una rete di telecomunicazioni composta da quattro nodi: NI, N2, N3 ed N4, tra loro interconnessi mediante linee di connessione rispettivamente indicate con: LP(l-2), LP(l-3), LP(l-4), LF(2-3), LP(2-4) e LP(3-4) . Per semplicità non sono state indicate frecce direzionali, sicché con la terminologia utilizzata per le linee LP si intendono le linee nei due sensi di trasmissione, ad esempio, con LP(l-2) si sottintende anche LP(2-1). Ciascun nodo è inoltre connesso a tre rispettivi punti terminali T mediante delle linee di connessione In. Lungo il percorso delle linee di connessione LP(l-2) ÷ LP(3-4) sono visibili alcuni rigeneratori di segnale indicati con R.

La rete di fig.1 può essere indifferentemente, o di tipo telefonico, o per il trasferimento di dati, o altro ancora. I nodi Ni ÷ N4 comprendono, di conseguenza, o delle centrali telefoniche, o dei calcolatori di nodo. In ambedue i casi esse includono anche gli apparati di multiplazlone/demultiplazione dei segnali uscenti/entranti nei nodi, nonché le interfacce verso le rispettive linee di connessione LP(l-2) ÷ LP(3-4). Queste ultime possono essere realizzate mediante tratte in ponte radio, o in fibra ottica, o in cavo. La topologia della rete di fig.1 è tale per cui il dialogo tra i punti terminali T avviene solo per il tramite di uno, o più, nodi NI N4, posti ad un ordine gerarchico superiore rispetto a T. Per quanto riguarda le operazioni inerenti alla gestione della rete, alcune attività, come ad esempio quelle che più riguardano il funzionamento dei singoli apparati ed il controllo della integrità delle linee di connessione, sono generalmente a carico di elaboratori posti entro i nodi, mentre quelle più propriamente di supervisione dell'intera rete sono preferibilmente a carico di un unico elaboratore di gestione, posto ad esempio nel nodo NI. Quest'ultimo nello svolgimento dei suoi compiti è in genere coadiuvato da elaboratori locali, formando con questi un sistema ad intelligenza distribuita.

Un'importante funzione gestionale, che ben esemplifica l'attività di supervisione svolta dal Gestore, consiste nella riconfigurazione della rete in caso di guasto di una, o più, linee, e nel conseguente reinstradaraento dei segnali in base alla nuova configurazione assunta.

Nel caso di fig.1, l'elaboratore di gestione è posto molto distante rispetto a gran parte degli apparati gestiti, mentre in altri casi questo può non essere vero; in pratica possono verificarsi diverse situazioni che vanno da una completa separazione sino ad una co-locazione. E' doveroso precisare che anche in caso di co-locazione non viene tolta generalità all'invenzione in seguito descritta.

Per quanto riguarda l'attività di gestione dal punto di vista sistemistico, si può dire che la rete di fig.1 è un sistema di gestione funzionalmente suddividibile in un sottosistema che esercita la gestione ed in un sottosistema gestito. Il sottosistema che esercita la gestione è costituito dal suddetto elaboratore posto nel nodo NI, eventualmente coadiuvato dagli elaboratori posti nei rimanenti nodi. Il sottosistema gestito è costituito dall'intera rete, ad esclusione dei suddetti elaboratori. Una premessa fondamentale per parecchie attività gestionali è l'acquisizione da parte del Gestore dello stato di funzionamento del sottosistema gestito. Il suddetto stato è definibile come un insieme di variabili che indicano, ad esempio: la presenza di allarmi per guasto degli apparati, i valori di particolari grandezze fisiche, quello di opportuni parametri di configurazione, la presenza, o assenza, di specifici segnali di sincronizzazione, eventuali interruzioni nelle linee di connessione, i valori di traffico, le misure di qualità del servizio, etc.

La precedente dizione: "stato di funzionamento" viene usualmente semplificata con il solo termine "stato", e le variabili che lo definiscono sono dette appunto "variabili di stato". Occorre anche precisare che, ai fini di una particolare funzione gestionale, lo stato preso in considerazione non coincide necessariamente con lo stato completo, di per sè difficilmente definibile, ma piuttosto con un sottoinsieme di variabili di stato che riguardano quella funzione. Queste ultime possono essere di tipo discreto, se assumono solo un numero limitato di valori, ad esempio se riguardano la presenza o assenza di allarmi; oppure di tipo analogico se assumono un intervallo continuo di valori, come ad esempio nel caso di misura di una tensione. Ovviamente le variabili analogiche devono essere discretizzate.

Nei sistemi di gestione è estremamente importante che ogni variazione di stato del sottosistema gestito giunga in tempo utile al Gestore di modo che, in caso di anomalie riscontrate, esso possa inviare a ritroso messaggi in grado di correggerne i malfunzionamenti.

Da quanto sopra si può già intuire che un grosso problema da risolvere nel progetto di un sistema di gestione è quello della ricerca delle migliori modalità nel trasferimento al Gestore delle informazioni sullo stato del sottosistema gestito. Infatti una scelta errata delle suddette modalità potrebbe comportare, specie durante i periodi di maggior sollecitazione, una perdita di informazioni dovuta alla congestione dei canali di comunicazione, o alla saturazione della capacità di elaborazione del Gestore, o ad entrambi gli inconvenienti. Ne deriva un peggioramento nelle operazioni di gestione con possibilità di messa fuori servizio di parti consistenti del sottosistema gestito.

Il problema di cui sopra è in sostanza un problema di segnalazione, ovvero di trasferimento ordinato di messaggi attraverso i nodi della rete servendosi per questo di opportuni protocolli di comunicazione che definiscono le modalità del suddetto trasferimento. Questi protocolli sono da tempo oggetto di standardizzazione da parte di organismi internazionali di standardizzazione nel campo delle comunicazioni (UIT, ISO, étc.), onde consentire la compatibilità tra sistemi ed apparati provenienti da costruttori diversi.

Un modello universalmente adottato per la definizione dei suddetti protocolli è quello proposto dall'Organizzazione Internazionale per la Standardizzazione (ISO), nel documento ISO 82, e conosciuto come modello OSI (Open System Interconnection) . Il modello OSI, per quanto riguarda l'attività di comunicazione, stabilisce un'architettura a cui ricondurre quella dei sistemi aperti, ovvero di quei sistemi che possono essere interconnessi con altri nel rispetto di standard prefissati. Il modello di riferimento OSI è una struttura organizzata in sette livelli funzionali di tipo gerarchico, il cui scopo congiunto è quello di facilitare il colloquio tra interlocutori del livello superiore (applicativo) . Ciascun livello N fornisce servizi al livello N+l avvalendosi dei servizi del livello N-l. Entro ciascun livello il dialogo tra interlocutori appartenenti a sistemi aperti differenti è regolato dal protocollo di livello. Il livello più basso è quello fisico e si occupa di problemi d'interfacciamento elettrico dei segnali con il mezzo trasmissivo. Il livello più alto è quello applicativo, esso fornisce agli interlocutori di questo livello, ad esempio i programmi applicativi, tutte le risorse di cui essi hanno bisogno per scambiarsi dei messaggi.

Lo svolgimento della funzionalità gestionale si avvale di un'attività di segnalazione costituita da messaggi scambiati tra gli interlocutori dei diversi livelli OSI. Tra questi messaggi, quelli che più interessano l'Invenzione in seguito descritta, sono quelli a livello applicativo il cui contenuto informativo comprende informazioni sullo stato del sottosistema gestito.

Per il trasferimento dei suddetti messaggi dal sottosistema gestito verso il Gestore, le raccomandazioni internazionali a riguardo, e ulteriori conoscenze nel settore, Indicano in particolare due tecniche, e precisamente: la tecnica del "polling" e quella del "riporto di evento", nonché le loro numerose varianti. Indipendentemente dalla tecnica prescelta, esiste comunque il problema di ridurre l'elevato numero di valori provenienti dalla conversione in digitale delle variabili analogiche, che caricherebbero inutilmente i canali di comunicazione. Quest'ultimo problema è risolto in modo noto applicando tecniche come quella del riporto per variazione, oppure quella del riporto per superamento di soglia.

La tecnica del polling prevede il campionamento periodico da parte del Gestore del valore di tutte le variabili di stato del sottosistema gestito. E' quindi una tecnica molto semplice da attuare e non risente dei sovraccarichi del sistema. Per contro essa genera verso l'elaboratore di gestione un carico di lavoro che cresce in proporzione al numero delle variabili da controllare, rendendola in pratica inapplicabile in sistemi di grandi dimensioni.

La tecnica del riporto di evento prevede che per ogni "evento" costituito da un nuovo valore di una variabile di stato, il sottosistema gestito invii spontaneamente al Gestore un messaggio comprendente il suddetto evento. Il Gestore, partendo dalla conoscenza di uno stato iniziale, aggiorna i valori delle variabili di stato con gli eventi ricevuti. Questa tecnica, come conseguenza dell'invio dei soli eventi piuttosto che dell'intero stato del sottosistema gestito, risulta molto vantaggiosa in sistemi di medie e grandi dimensioni, ovvero quando il numero delle variabili controllate è dell'ordine delle migliaia o delle decine di migliaia.

Il presupposto su cui la tecnica del riporto d'evento è basata è la perfetta corrispondenza tra gli eventi generati e gli eventi ricevuti dal Gestore. Se ciò è verificato, lo stato del sottosistema gestito, così come ricostruito dal Gestore, risulta una copia perfetta di quello reale. Se il presupposto non è invece verificato, e in mancanza di opportuni provvedimenti, l'informazione di stato ricostruita dal Gestore perde l'allineamento con lo stato effettivo del sottosistema gestito e diviene in tal modo inconsistente con lo stesso. Il che pone seri limiti alla corretta prosecuzione dell’attività di gestione. Le cause che vanificano il presupposto di cui sopra possono manifestarsi in modo particolare durante i picchi di attività del sistema, ove la velocità di generazione degli eventi può superare la capacità di trasporto dei canali di comunicazione, e/o la capacità elaborativa dell'elaboratore di gestione .

Per via delle due cause di cui sopra, il maggior inconveniente introdotto dalla tecnica del riporto di evento in un sistema di gestione che la utilizza, è quello della possibile inconsistenza dell'informazione di stato elaborata dal Gestore dopo l'insorgere di un picco di eventi.

Tra le due tecniche appena illustrate, verrà in seguito presa in considerazione la sola tecnica del riporto di evento, poiché lo scopo della presente invenzione è principalmente quello di rimediare al maggior inconveniente che la caratterizza. Allo stesso scopo sono noti alcuni provvedimenti già oggetto di Raccomandazioni Internazionali. Un primo di essi, descritto nella Raccomandazione CCITT X.740, consiste nell'attivazione da parte del Gestore di verifiche periodiche, dette anche Audit, circa il valore effettivo di tutte le variabili di stato del sottosistema gestito.

Il maggior inconveniente dovuto all'attivazione degli Audit, è che il Gestore non è messo in grado di sapere in quale istante l'informazione ad esso pervenuta inizia a perdere di consistenza e, fatto assai grave, non risulta più possibile ricuperare l'informazione relativa al periodo di inconsistenza.

Un secondo provvedimento, descritto nella Raccomandazione CCITT X.735, prevede l'utilizzo di un particolare registratore posto nel sottosistema gestito, e detto in seguito LOG, per memorizzare sequenzialmente tutti gli eventi generati durante un periodo di tempo prefissato. Allo scadere di prestabiliti intervalli di tempo, il Gestore legge il contenuto del LOG e, se ne è il caso, riallinea la sua conoscenza circa lo stato del sottosistema gestito con quella effettiva desunta dal LOG.

Il maggior inconveniente dovuto dall'utilizzo del LOG è quello che il Gestore può trovarsi in uno stato di inconsistenza per un tempo assai lungo, nel caso peggiore corrispondente all'intero periodo che intercorre tra due letture successive del LOG. Ne risulta che per tutta la durata dell'inconsistenza esso non corregge i malfunzionamenti del sottosistema gestito. Inoltre, essendo l'intervallo tra successive letture del LOG stabilito con criteri di compromesso tra diverse esigenze elaborative, la durata dello stato di inconsistenza non viene minimizzata, come invece desiderabile.

Un secondo inconveniente dovuto dall'utilizzo del LOG è costituito dallo spreco di risorse da parte dell'elaboratore di gestione nel rileggere il contenuto del LOG e nel confrontare i dati letti con quelli in proprio possesso per individuare l'inizio di una inconsistenza. Infatti la stragrande maggioranza di detto contenuto è già nota all'elaboratore di gestione, a meno degli eventi perduti durante i periodi di inconsistenza, che sono la sola informazione utile.

Pertanto scopo della presente invenzione è quello di superare gli inconvenienti suddetti e di indicare un procedimento di riallineamento di una copia dell'informazione di stato, ricostruita da un Gestore sulla base di uno stato iniziale e di eventi via via trasferiti da un sottosistema gestito, con lo stato effettivo del sottosistema gestito.

Per conseguire tali scopi la presente invenzione ha per oggetto un procedimento di riallineamento di una copia della informazione di stato di un sottosistema gestito ricostruita da un Gestore, con lo stato effettivo di detto sottosistema gestito; la ricostruzione dell'informazione di stato essendo effettuata sulla base di uno stato iniziale e di eventi, costituiti da nuovi valori delle variabili di stato, che il sottosistema gestito rileva e via via riporta al Gestore. Gli eventi essendo scritti in un buffer degli eventi, organizzato come una coda circolare, in cui il sottosistema gestito scrive gli eventi e li legge in modo asincrono rispetto alla scrittura, trasferendoli quindi al Gestore. La perdita di allineamento essendo segnalata da una condizione di traboccamento della coda circolare, verificata dopo ogni scrittura nella coda stessa. Il riallineamento essendo compiuto dal sottosistema gestito che invia al Gestore il proprio stato al momento della perdita di allineamento, a cui fa seguito l'invio di eventuali nuovi eventi scritti in coda nel contempo, come meglio è descritto nelle rivendicazioni da 1 a 13.

Altro oggetto della presente invenzione è una sistema di gestione che utilizza il procedimento descritto nella rivendicazione 1, come anche risulta dalle rivendicazioni da 14 a .. .

Per quanto detto, la sostanziale differenza tra i procedimenti di riallineamento noti ed il procedimento secondo l'invenzione è che nei primi era il Gestore che si accorgeva del disallineamento mediante lettura fuori linea del LOG, mentre nel secondo è il sottosistema gestito che se ne accorge in fase di memorizzazione degli eventi nella coda circolare e promuove tutte quelle attività che conducono al riallineamento del proprio Gestore.

Ciò costituisce un grosso vantaggio in quanto il disallineamento viene rivelato già fin dal suo primo manifestarsi, il che consente di avviare automaticamente le operazioni di riallineamento. Dette operazioni consistono nell'inviare al Gestore l'informazione di stato che esso non è più in grado di ricostruire a causa della perdita degli eventi remoti per sovrascrittura nella coda circolare da parte degli eventi più recenti. Questi ultimi vengono anch'essi inviati al Gestore, completando l'informazione precedente, dopodiché riprendono le letture dei nuovi eventi in coda.

I vantaggi posseduti dal procedimento oggetto della presente invenzione, e le ulteriori innovazioni introdotte rispetto ai procedimenti noti, sono meglio compresi con l'ausilio delle figure 2 e 3 in cui:

in fig.2 è illustrato un insieme di blocchi funzionali che schematizzano le operazioni di riporto di evento e di riallineamento secondo l'arte nota, e

in fig.3 è illustrato un insieme di blocchi funzionali che schematizzano le operazioni di riporto di evento e di riallineamento secondo l'invenzione, di cui verranno forniti maggiori dettagli con l'illustrazione delle figg.6, 6.a, 7, 8, 9, 10 e 11.

La schematizzazione di fig.2 non è l'unica possibile in merito all'arte nota, tuttavia essa la rappresenta in modo esauriente e adatto ad un confronto immediato con la fig.3. Schematizzazioni più dettagliate possono essere ottenute dalle Raccomandazioni CCITT X.734 e X.735, e dal documento intitolato "Application Services: Event, Configuration, and Alarm Management" , Forum 002, edizione 1.3, Agosto 1991, pubblicato da OSI/Network Management Forum. Dai documenti citati risulta che i protocolli di comunicazione utilizzati nel dialogo tra il Gestore ed il sottosistema gestito includono degli applicativi che utilizzano una nuova tecnologia software, detta "Object Oriented" . Questa tecnologia è stata formalizzata per mezzo di una notazione astratta che va sotto il nome di Modello Informativo, e che si propone di descrivere i diversi elementi fisici di una rete per mezzo di attributi logici loro assegnati, allo scopo di facilitare e rendere uniforme la gestione di apparati provenienti da produttori diversi. La formalizzazione di cui sopra è contenuta nel documento ASN.1 (Abstract Syntax Notation One) o, in modo equivalente, nelle Raccomandazioni CCITT X.208 e X.722 "Guidelines to thè definition of thè managed objects" (GDMO). Complementare al paradigma degli "oggetti" è una strutturazione del software in moduli detti "MANAGER" e "AGENT", secondo cui il MANAGER non svolge autonomamente le sue funzioni gestionali, bensì fornisce delle direttive a uno, o più, AGENT per lo svolgimento di alcuni compiti parziali.

Fatte salve le premesse appena poste, in fig.2 notiamo dei blocchi indicati con: RILEVAZIONE DI EVENTO, RIPORTO DI EVENTO, LOG, RICUPERO DI EVENTO, STACK DI PROTOCOLLO e GESTORE. Le linee che congiungono i diversi blocchi indicano, tramite frecce, la direzione del principale flusso di informazioni tra i blocchi. Ciascun blocco rappresenta un modulo funzionale, realizzato da un apposito insieme di programmi, a parziale eccezione del blocco LOG che indica anche una memoria per la registrazione degli eventi. In fig.2, i blocchi RILEVAZIONE DI EVENTO, RIPORTO DI EVENTO, RICUPERO DI EVENTO e il blocco LOG sono operanti nel sottosistema gestito. Il blocco STACK DI PROTOCOLLO è idealmente scomponibile in due metà, di cui una appartenente al sottosistema gestito e l'altra al Gestore. Il blocco GESTORE rappresenta sia un elaboratore di gestione, quanto i moduli di programma che lo governano nello svolgimento di tutte le funzioni gestionali previste per la supervisione del sottosistema gestito, in particolare: il controllo dei malfunzionamenti e il monitoraggio delle prestazioni, e la memorizzazione "storica" dei relativi dati (LOG).

Nello svolgimento delle suddette funzioni il modulo GESTORE agisce come un MANAGER che invia delle direttive a degli AGENT. Nella fattispecie le direttive consistono nel richiedere un servizio di riporto di evento, o di ricupero e riporto di eventi registrati, da attuare secondo opportune modalità di svolgimento. In questo contesto i moduli RIPORTO DI EVENTO e RICUPERO DI EVENTO appartengono ad un unico AGENT che fornisce al modulo GESTORE gli omonimi servizi. Il colloquio tra il modulo GESTORE (MANAGER) e i moduli dell'AGENT avviene tramite il modulo STACK DI PROTOCOLLO che svolge tutte le funzioni previste nei protocolli standard di comunicazione ivi utilizzati. I moduli RIPORTO DI EVENTO e RICUPERO DI EVENTO richiedono a loro volta al modulo RILEVAZIONE DI EVENTO e al LOG gli eventi da trasferire al modulo GESTORE (MANAGER).

Il modulo RILEVAZIONE DI EVENTO, nella schematizzazione di fig.2, legge ciclicamente il valore di ciascuna variabile di stato (polling) e confronta la lettura appena fatta con il precedente valore della stessa variabile presente in una memoria degli stati, se nel confronto non c'è stata coincidenza il modulo stesso promuove le seguenti azioni: a) provvede ad aggiornare la memoria degli stati con il nuovo valore della variabile; b) genera un "evento" che è costituito dagli elementi d'informazione necessari al modulo GESTORE (MANAGER) per aggiornare la propria copia dello stato del sottosistema gestito, ovvero l'indicativo del tipo di variabile di stato che ha generato l'evento, ed il nuovo valore della stessa; c) mette a disposizione del modulo RIPORTO DI EVENTO (AGENT) l'evento appena rilevato per il trasferimento al modulo GESTORE (MANAGER) e per la sua contemporanea registrazione nel LOG.

Il modulo RIPORTO DI EVENTO (AGENT) viene preventivamente istruito dal modulo GESTORE (MANAGER) circa la modalità di riporto a cui attenersi e il tipo di eventi da riportare. Tra le diverse modalità di riporto possibili quella che maggiormente può causare disallineamenti, è senza dubbio quella del riporto autonomo, cioè spontaneo, di eventi di particolare rilevanza, ad esempio l'insorgere di allarmi, che devono essere riportati al Gestore il più rapidamente possibile immediatamente dopo il loro manifestarsi, onde evitare gravi disservizi del sistema. Altre modalità di riporto, come ad esempio il riporto automatico periodico, o il riporto su richiesta, non sono altrettanto pregiudizievoli ai fini dell 'allineamento.

Il modulo RIPORTO DI EVENTO (AGENT), una volta inizializzato , resta in attesa di ricevere un evento dal modulo RILEVAZIONE DI EVENTO, dopodiché provvede ad attivare la registrazione del nuovo evento nel LOG e contemporaneamente ad inviare l'evento al modulo GESTORE (MANAGER), utilizzando allo scopo uno specifico servizio del protocollo di comunicazione presente nel modulo STACK DI PROTOCOLLO. E' utile sottolineare che in questa fase può manifestarsi la perdita di allineamento menzionata nella introduzione. Infatti, indipendentemente dalla particolare sofisticazione dei possibili protocolli utilizzati, è pur sempre vero che durante i picchi di attività del sistema le risorse a disposizione dei servizi offerti da un qualsiasi protocollo noto non sono sempre sufficienti ad evitare la perdita di eventi da parte del Gestore, almeno per quanto riguarda la loro acquisizione in linea.

Il blocco LOG schematizza il registratore degli eventi citato nell'introduzione, esso è collocato all'interno del sottosistema gestito. In LOG gli eventi sono registrati rispettando l'ordine cronologico con cui sono rilevati dal modulo RILEVAZIONE DI EVENTO. L'ampiezza della zona di memoria del LOG dipende ovviamente dalle dimensioni del sottosistema gestito e dalla durata massima del periodo di osservazione. Allo scadere di tempi prestabiliti il contenuto del LOG viene letto dal modulo GESTORE (MANAGER) tramite i moduli RICUPERO DI EVENTO (AGENT) e STACK DI PROTOCOLLO. Il modulo GESTORE (MANAGER), elaborando fuori linea il contenuto del LOG, riesce a ricuperare gli eventi perduti durante l'elaborazione in linea ed a riallineare la copia in suo possesso circa l'informazione di stato del sottosistema gestito con lo stato effettivo dello stesso al momento della lettura del LOG.

La schematizzazione di fig.3 differisce da quella di fig.2 principalmente per il fatto che il flusso informativo di evento generato dal modulo RILEVAZIONE DI EVENTO raggiunge il modulo RIPORTO DI EVENTO (AGENT) non più direttamente, bensì attraverso un blocco COD-CIR. E' inoltre presente un modulo RICUPERO DI ALLINEAMENTO e manca invece il blocco LOG e il modulo RICUPERO DI EVENTO (AGENT). Cosa assai significativa è che il modulo RIPORTO DI EVENTO (AGENT) non si limita al solo riporto di evento, come accadeva invece per l'omonimo blocco di fig.2, bensì esso promuove tutte quelle azioni che portano il modulo GESTORE (MANAGER) al riallineamento. Con ciò esso conferisce grande novità e originalità al processo secondo l'invenzione, distinguendolo dall'arte nota in cui era il modulo GESTORE (MANAGER) che eseguiva la procedura di riallineainento.

In fig.3 si può notare che i blocchi GESTORE (MANAGER), STACK DI PROTOCOLLO e RIPORTO DI EVENTO (AGENT) sono multiplati, ciò corrisponde ad una possibile situazione in cui ci sono più MANAGER, ognuno servito da un rispettivo AGENT, che hanno necessità di acquisire gli eventi.

Nel funzionamento, rimandando per maggiori dettagli alla illustrazione delle figg.6, 6.a, 7, 8, 9, 10 e 11, il modulo RILEVAZIONE DI EVENTO rileva gli eventi come avveniva nel modulo omonimo di fig.2, differendo da questo per il fatto che esso non mette a disposizione del modulo RIPORTO DI EVENTO (AGENT) l'evento appena rilevato, bensì lo trasferisce direttamente al blocco COD-CIR.

Il blocco COD-CIR è un modulo di programma che gestisce sia la scrittura che la lettura degli eventi in un buffer d'evento presente nel sottosistema gestito. Detto buffer è indispensabile per ovviare alla perdita di informazione di stato che, in sua assenza, potrebbe manifestarsi quando non è possibile sincronizzare il consumo degli eventi rispetto alla loro produzione, similmente a come avveniva nei casi menzionati illustrando la fig.2. In questi casi il buffer d'evento diviene il luogo ove gli eventi accaduti si accumulano in attesa di essere prelevati. Il buffer di evento gestito sia in scrittura che in lettura da COD-CIR, a causa della limitata disponibilità di memoria, funziona come una coda circolare scritta da RILEVAZIONE DI EVENTO e letta da RIPORTO DI EVENTO (AGENT).

Come è noto, un metodo per gestire una memoria sequenziale di N dati come una coda circolare è quello di utilizzare sia in lettura che in scrittura dei rispettivi puntatori, e di incrementare di una unità, modulo N, un puntatore ad ogni singola operazione di lettura o scrittura. Cosi facendo, dopo la scrittura di N dati i successivi dati verranno sovrascritti ai più vecchi. Può succedere che in casi di particolare attività nella produzione di eventi, il picco dia luogo ad un traboccamento del buffer d'evento, specie se quest'ultimo non è stato ben dimensionato, con perdita degli eventi più remoti. I moduli COD-CIR, RIPORTO DI EVENTO (AGENT) e RICUPERO DI ALLINEAMENTO provvedono affinchè questo fatto non causi perdita definitiva della informazione di stato da parte del Gestore.

Il modulo COD-CIR comprende due sezioni indipendenti l'una dall'altra che si occupano rispettivamente della scrittura nel buffer d'evento e della lettura dello stesso.

La sezione che si occupa della scrittura è costantemente in attesa di ricevere un evento da RILEVAZIONE DI EVENTO, appena lo riceve provvede a scriverlo nel buffer d'evento, ed in questa fase essa si accorge se la scrittura produce un traboccamento del buffer (overflow) relativamente a ciascuno di (m) processi di lettura della coda attivi in altrettanti AGENT, con perdita dell'evento più remoto sovrascritto. Nei casi affermativi, ciascuna condizione di overflow viene memorizzata in un apposito vettore di overflow, tuttavia la scrittura in coda non può essere arrestata, pena la perdita di eventi per i processi di lettura per cui la coda non è in overflow. Ciò significa che, ad ogni nuova scrittura in coda, i processi di lettura per cui la coda è in overflow perdono l'evento più remoto residuo.

La sezione di COD-CIR che si occupa della lettura, legge il buffer di evento per conto degli (m) AGENT che ne fanno richiesta. Data la casualità temporale delle richieste di lettura, le letture in coda vengono eseguite da COD-CIR in modo indipendente l'una dall'altra, e in modo indipendente, ovvero asincrono e non deterministico, rispetto alle scritture nella coda stessa. Per quanto detto, la sezione di lettura di COD-CIR è costantemente in attesa di ricevere un ordine di leggere nella coda da parte di un AGENT (m), non appena l'ordine viene ricevuto essa compie le seguenti azioni:

a) verifica se era stata segnalata presenza di overflow per il processo di lettura dell'AGENT (m),

b) se in a) c'era assenza di overflow essa verifica se la coda è vuota,

c) se in b) la coda risulta vuota informa di questo l'AGENT (m),

d) se in b) la coda non risulta vuota essa legge, a seconda delle direttive ricevute, uno, o più, o tutti gli eventi in coda e li trasferisce all'AGENT (ra) che li aveva richiesti per l'utilizzo degli stessi nel modo che esso conosce ,

e) se in a) c'era presenza di overflow, la sezione di lettura di COD-CIR informa della presenza di overflow l'AGENT (m) che aveva chiesto di leggere, e si mette quindi in attesa di ricevere da questi un ordine di lettura. Non appena arriva l'ordine, la sezione di lettura annulla la condizione di overflow e riprende quindi a leggere, cominciando dagli eventuali eventi scritti in coda durante l'operazione di riallineamento, che trasferisce all'AGENT (m).

Uno dei principali AGENT che ha necessità di leggere la coda, e che è anche quello maggiormente coinvolto nella invenzione in oggetto, è il modulo RIPORTO DI EVENTO. In ciascuno dei moduli RIPORTO DI EVENTO (AGENT) multiplati in fig.3 è attivo un processo di lettura per cui potrebbe essere verificata la condizione di overflow. Nel caso di assenza di overflow, il generico modulo RIPORTO DI EVENTO (AGENT) preleva l'evento, o gli eventi, più vecchi in coda letti da COD-CIR e li trasferisce al modulo STACK DI PROTOCOLLO per l'inoltro al modulo GESTORE (MANAGER). In presenza di overflow, invece, esso ordina al modulo RICUPERO DI ALLINEAMENTO di effettuare una copia temporanea (fotografia) dello stato aggiornato del sottosistema gestito, e di inviargli detta copia, dopodiché esso la trasferisce al modulo STACK DI PROTOCOLLO per il suo inoltro al rispettivo modulo GESTORE (MANAGER). In tal modo si supplisce alla perdita di eventi con l'invio dello stato, e gli eventi residui scritti in coda prima della fotografia dello stato perdono di interesse. Al termine del trasferimento della copia di stato, il modulo RIPORTO DI EVENTO (AGENT) ordina al modulo COD-CIR di leggere tutti gli eventi eventualmente scritti nel contempo nel buffer di evento. Alla ricezione di tali eventi esso li trasferisce al modulo STACK DI PROTOCOLLO.

Il trasferimento della copia di stato al Gestore può essere studiato in modo da ottimizzare il canale trasmissivo. Un primo metodo è senz'altro quello di predeterminare per ogni variabile del sistema un valore prefissato, detto anche di default, ed inviare solo quei valori delle variabili di stato diversi da rispettivi valori di default, già conosciuti dal modulo GESTORE (MANAGER). Un secondo metodo, più oneroso del primo, è quello di mandare i valori di tutte le variabili di stato. Sia in un caso che nell'altro i valori da inviare possono essere inviati singolarmente, oppure diversamente raggruppati.

E' teoricamente possibile, per quanto molto improbabile, che il buffer di evento trabocchi nuovamente durante una operazione di riallineamento, tuttavia il procedimento appena illustrato può essere reiterato per ricuperare l'allineamento anche in questa situazione.

Il modulo RICUPERO DI ALLINEAMENTO, da parte sua, è sempre in attesa di ricevere dal modulo RIPORTO DI EVENTO (AGENT) un comando di abilitazione. Non appena questi giunge, e prima di fotografare la memoria di stato, esso avverte il modulo COD-CIR di bloccare ogni scrittura nel buffer di evento fino a che è in corso la fotografia. Questo blocco è di breve durata, in quanto la fotografia viene eseguita molto rapidamente, e pertanto esso molto difficilmente causa la perdita di eventi da parte dei processi di lettura per cui la coda non è in overflow.

Per quanto riguarda il modulo STACK DI PROTOCOLLO, a differenza degli altri moduli di fig.3, non si rendono necessarie ulteriori figure per meglio dettagliare quando detto finora, poiché per dare supporto alle innovazioni introdotte con i moduli di fig.3 è sufficiente utilizzare in modo opportuno, e se si vuole innovativo, i servizi di riporto già previsti nei protocolli di comunicazione delle specifiche citate. Queste considerazioni sono molto importanti perchè mettono in chiaro il fatto che il procedimento di rialllneamento oggetto dell'invenzione può essere, a tutt'oggi, realizzato rimanendo compatibili con gli standard esistenti. Infatti, è sufficiente includere nei dati inviati ad un Gestore mediante RIPORTO DI EVENTO (AGENT) l'informazione aggiuntiva per dire che il dato inviato corrisponde ad un valore di una variabile di stato individuata da un proprio identificativo. Ciò è in regola con i protocolli previsti, che peraltro già prevedono il trasferimento al Gestore del valore iniziale delle variabili di stato, quale presupposto di ogni successiva attività di riporto di evento. L'innovazione introdotta, limitatamente a quanto riguarda l'utilizzo dei servizi di riporto forniti dai protocolli, consiste nel fatto che l'informazione di stato viene riportata, non solo in fase di inizializzazione del sistema di gestione, ma anche immediatamente dopo ogni perdita di allineamento della informazione di stato in possesso del Gestore.

Il modulo STACK DI PROTOCOLLO di fig.3 non deve perturbare il procedimento di riallineamento oggetto dell'invenzione, pertanto esso deve obbligatoriamente garantire l'ordinamento sequenziale dei messaggi trasferiti e la consegna di tutti i messaggi ricevuti, ovvero esso non deve ammettere la possibilità di perdere alcun messaggio ricevuto, per cui dovrebbe richiedere una ritrasmissione.

L'utilizzo di una coda circolare per svincolare il produttore di eventi dal consumatore in linea, introduce l'ulteriore vantaggio dovuto al fatto che, dimensionando opportunamente la coda, è possibile assorbire picchi di attività del sistema senza quasi dover ricorrere ad un riallineamento .

Un secondo vantaggio consiste nella possibilità di utilizzare una sola area di memorizzazione con un solo produttore di eventi e molti consumatori. Ciò si rivela utile in quei casi in cui la stessa informazione deve essere instradata ad utenti diversi, ad esempio: personal computers, stampanti, altre periferiche, etc. In questo modo si realizza una economia di spazio occupato dalla coda circolare, poiché tutti gli utenti utilizzano la stessa informazione e la processano secondo le temporizzazioni loro proprie.

Per ragioni di convenienza, il blocco COD-CIR potrebbe anche includere le prestazioni di memorizzazione storica tipiche del blocco LOG di fig.2. In effetti tra i due blocchi esiste una certa somiglianza, nel senso che il LOG può essere realizzato come una coda circolare. Nel caso ipotizzato il modulo RIPORTO DI EVENTO (AGENT) deve assumere anche le funzioni del modulo RICUPERO DI EVENTO (AGENT) di fig,2. Le modalità realizzative appena accennate consentirebbero al Gestore di rimanere inattivo per un certo tempo senza per questo perdere l'allineamento. In alternativa, il LOG potrebbe ancora essere previsto e realizzato in modo autonomo rispetto al buffer di evento, però in questo caso esso verrebbe utilizzato in operazioni diverse dal riallineamento, ad esempio per la generazione di stampe periodiche.

Ulteriori scopi e vantaggi della presente invenzione risulteranno chiari dalla descrizione particolareggiata che segue di un esempio di realizzazione della stessa e dai disegni annessi dati a puro titolo esplicativo e non limitativo, in cui :

in fig.4 è indicata una rappresentazione a blocchi che schematizza una realizzazione del nodo NI di fig.1, nel caso in cui la rete ivi raffigurata sia una rete telefonica;

in fig.5 è indicata una rappresentazione a blocchi che schematizza una realizzazione di un blocco R di fig.1 posto lungo la linea di connessione LP(l-2);

in figg.6.a e 6 sono rispettivamente indicati, una struttura di dati organizzati come una coda circolare ed i mezzi che consentono la gestione della stessa; e

in figg.7, 8, 9, 10 e 11 sono indicati dei diagrammi di flusso relativi ai moduli di programma di fig.3.

Con riferimento alla fig.4, in cui gli elementi comuni alla fig.1 sono indicati con gli stessi simboli, notiamo un blocco APP che rappresenta una centrale telefonica, connessa ai punti terminali T (fig.1), mediante le linee di connessione In. Nel caso illustrato i punti terminali T sono, ad esempio, delle centrali urbane, le linee In doppini telefonici, e la centrale telefonica APP una centrale di rilevanza distrettuale,

La centrale APP è inoltre connessa ad un blocco di multiplazione/demultiplazione sincrona a divisione di tempo SDH-MX/DX, per mezzo di rispettivi fasci di linee seriali indicati con Fsc(l-2), Fsc(l-3) e Fsc(l-4). Il blocco SDH-MX/DX è a sua volta connesso, tramite rispettive pluralità di linee seriali STM-N(l-2), STM-N(l-3) e STM-N(l-4), a rispettivi blocchi MPI(l-2), MPI(l-3) e MPI(l-4) di interfaccia verso il mezzo trasmissivo costituito dalle linee LP(l-2), LP(l-3) e LP(l-4) , che connettono il nodo NI rispettivamente ai nodi N2, N3 e N4 (fig.1).

In fig.4 è inoltre visibile un blocco SDH-ECF che include un blocco SEMF ed un blocco MCF. Il blocco SEMF è connesso al blocco MCF mediante un bus indicato con V-bus, ed ai blocchi: SDH-MX/DX, MPI(l-2) , MPI(l-3) e MPI(l-4) mediante un bus indicato con S-bus, che nei blocchi indicati è connesso ad altrettanti sottoblocchi H/S. Il blocco MCF è inoltre connesso: al blocco SDH-MX/DX, per mezzo di linee di connessione seriale indicate con DCC-LS; al blocco GESTORE, mediante un bus Q-bus; e ad un personal computer PC, mediante un bus F-bus.

La schematizzazione circuitale di fig.4 relativa al nodo NI è identica, salvo congruenti modifiche nel simboli che indicano i diversi elementi, a quella dei nodi N2, N3 e N4 (fig.1), essendo nelle sole funzioni svolte dai blocchi SEMF e MCF le uniche differenze eventualmente ravvisabili.

La schematizzazione circuitale di fig.5 è riferita ad uno qualunque dei tre rigeneratori R di fig.1 posti lungo la linea di connessione LP(l-2). Anche in questo caso la suddetta schematizzazione è identica, salvo congruenti modifiche nei simboli che indicano i diversi elementi, a quella degli altri rigeneratori R della rete.

Con riferimento alla fig.5, in cui gli elementi comuni alle figg.1 e 4 sono indicati con gli stessi simboli, si notano: il blocco SDH-ECF, due identici blocchi MPI(l-2), ed un blocco SDH-RIG. Il blocco SDH-ECF è connesso ai restanti blocchi mediante il bus S-bus, ed ancora al blocco SDH-RIG mediante le linee di connessione seriale DCC-LS. Il blocco SDH-RIG è inoltre connesso ai blocchi MPI(l-2) mediante rispettive pluralità di linee seriali STM-N(l-2) della stessa natura di quelle di fig.4. A loro volta i blocchi MPI(l-2) sono connessi, mediante le linee di connessione LP(l-2) che rappresentano il mezzo trasmissivo, o a due rigeneratori R (fig.1), o a un rigeneratore R e all'uno o all'altro dei nodi NI e N2,

Conviene puntualizzare che le doppie frecce utilizzate in figg.4 e 5 per indicare la bidirezionalità dei segnali sulle linee In, LP, STM-N e su quelle dei fasci FSC, sono valide solo per i doppini telefonici In, negli altri casi è sottinteso che i segnali di trasmissione e di ricezione viaggiano su linee distinte. Inoltre, come già era stato detto per le linee LP, la terminologia utilizzata per indicare i fasci FSC e le linee STM-N indica, per semplicità, fasci e linee nei due sensi del collegamento. Lo stesso discorso vale per S-bus, Q-bus e F-bus, che sono bus seriali per trasmissione dati full-duplex, ma non vale altrettanto per V-bus che è un bus di microprocessore la cui direzionalità dipende dal fatto che l'operazione in corso sia di lettura o di scrittura. A riguardo della terminologia utilizzata per indicare i blocchi MPI, in realtà suddividibili in due parti ciascuna connessa alle linee LP e STM-N di ricezione o di trasmissione, vale la stessa semplificazione utilizzata per indicare le linee LP e STM-N.

Per quanto concerne il funzionamento dei blocchi di figg.4 e 5, giova premettere che l'invenzione in oggetto è essenzialmente contenuta nel blocco SEMF (fig.4) e più precisamente nel programma che governa il funzionamento di un microprocessore ivi incluso. Tutti gli altri blocchi di figg.4 e 5, come pure la circuiteria e gran parte delle funzioni del blocco SEMF stesso, sono riferiti ad arte nota già ampiamente descritta nelle Raccomandazioni CCITT, in seguito citate con riferimento ad una realizzazione non limitativa della invenzione secondo i dettami delle cosiddette Gerarchie Digitali Sincrone, conosciute con la sigla SDH (Synchronous Digital Hierarchy).

Risulta pertanto superflua una descrizione dettagliata dei blocchi di cui sopra, che verrà comunque svolta in termini essenzialmente funzionali dopo aver brevemente introdotto i sistemi SDH. Questi ultimi vengono considerati nell'ambito degli standard internazionali che riguardano le reti di gestione delle telecomunicazioni, note sotto la sigla TMN (Telecommunications Management Network) ed essenzialmente descritte nella Raccomandazione CCITT "Principles for a telecommunlcations management network (TMN)", Voi. IV, Ree. M.3Q. Una rete TMN è una rete di gestione che controlla una rete di telecomunicazioni, spesso servendosi di quest'ultima per poter scambiare messaggi di gestione tra i diversi punti della rete in modo coerente alla filosofia "Object Oriented".

I sistemi SDH assumono un grosso rilievo nell'ambito delle reti TMN in quanto forniscono alla rete di telecomunicazioni di cui pure fanno parte un insieme standard di strutture di trasporto digitali in grado di trasportare una grande quantità di informazione "pagante", a cui viene associata l'ulteriore informazione per una gestione dettagliata della rete di telecomunicazioni stessa. Di fondamentale importanza è inoltre il fatto che i sistemi SDH consentono la gestione dinamica della struttura interna dei flussi informativi, rendendo con ciò flessibile l'instradamento del carico pagante entro la rete. L'informazione da trasportare viene resa idonea alla trasmissione seriale sul mezzo trasmissivo prescelto e viene sincronizzata all'orologio di rete. Per quanto riguarda il carico pagante esso è usualmente costituito da segnali generati dai multiplex digitali appartenenti a quelli specificati nella Raccomandazione CCITT G.702, oppure da moduli di trasporto asincrono, noti anche con la sigla ATM (Asynchronous Transport Module) , ... o altro ancora.

I sistemi SDH sono basati sull'utilizzo di moduli di trasporto sincrono, detti STM (Synchronous Transport Modules). Un STM è composto da campi relativi al carico pagante e da campi relativi ad una intestazione di sezione SOH (Section Overhead) , gerarchicamente organizzati in una struttura di trama a blocchi di bit che si ripete ogni 125 ps. Fisicamente un modulo STM di base si presenta come una stringa di bit a 155.520 Kbit/s, e viene detto STM-1. Moduli STM-N di maggior capacità informativa sono ottenuti sfruttando frequenze di bit multiple di un valore N rispetto a quella di STM-1. I valori di N ammessi dalle specifiche SDH sono N-4 e N=16, dando luogo a stringhe di bit rispettivamente di 622.080 Kbit/s e 2.488.320 Kbit/s.

In un modulo STM-N il carico pagante viene incluso in strutture informative, denominate contenitori virtuali VC, usati come supporto per l'instradamento del carico entro la rete. I contenitori virtuali comprendono campi relativi al carico pagante e campi relativi ad una intestazione di percorso POH (Path Overhead), organizzati in una struttura di trama a blocchi che si ripete ogni 125 o 500 με. L'intestazione POH provvede all'integrità della comunicazione tra il punto di assemblaggio di un contenitore virtuale e il suo punto di disassemblaggio. Gli elementi di base per l'assemblaggio dei VC, e quelli che risultano dal completo disasserablaggio, sono detti contenitori C-n, con n = 1÷4. Un contenitore è una struttura che costituisce l'informazione sincrona di rete relativa al carico pagante di un contenitore virtuale. Allo scopo di facilitare la sincronizzazione del carico pagante alla rete, il CCITT ha definito delle apposite funzioni di adattamento dei principali flussi standardizzati, alle più comuni frequenze di rete, entro un numero limitato di contenitori standard.

In una trama STM-N, la posizione Iniziale di ogni singolo blocco componente viene individuata per mezzo di un sistema di puntatori in cui, il valore del puntatore associato ad un generico blocco indica lo scostamento del punto di inizio di quel blocco rispetto al riferimento di trama della sua struttura di trasporto.

Dall'insieme delle precedenti considerazioni si può comprendere come il meccanismo d'instradamento del carico pagante entro una rete SDH consiste nel fatto che nei punti d'interfaccia verso i nodi di rete è possibile disassemblare i moduli STM-N in blocchi componenti da cui vengono estratti flussi diretti verso direzioni volute e, dualmente, è possibile inserire un carico pagante entro un modulo STM-N diretto verso una direzione piuttosto che un'altra. E' ulteriormente possibile instradare un carico multiplando due moduli STM-N in un unico modulo STM-M di maggior capacità, oppure trasferendo il carico stesso da un primo STM-N ad un secondo della stessa capacità. Le operazioni di assemblaggio/disassemblaggio di cui sopra comportano generalmente conseguenti operazioni di multiplazione/demultiplazione a divisione di tempo dei vari blocchi componenti i moduli STM-N.

L'informazione necessaria per il controllo dinamico delle operazioni d'instradamento di cui sopra, come pure quella necessaria per lo svolgimento delle principali funzioni di gestione di rete, viaggia su canali di comunicazione per i dati ricavati dall'intestazione SOH dei moduli STM-N, che inoltre comprende l'informazione relativa al mantenimento del sincronismo delle trame STM-N nei vari punti della rete. Dal punto di vista funzionale l'intestazione SOH è suddividibile in due sottointestazioni, indicate con RSOH (Regenerator Section Overhead) e MSOH (Multiplex Section Overhead), distinguendo tra le due tipologie di connessione possibili entro la rete di fig.1. L'informazione contenuta in RSOH è accessibile sia ai rigeneratori che ai multiplex SDH, mentre quella contenuta in MSOH è invece accessibile solo ai multiplex, e pertanto essa passa inalterata dai rigeneratori. Le sottointestazioni RSOH e MSOH sono suddividibili in bytes diversamente nominati, a cui vengono associate ben precise funzioni, tra cui quella della comunicazione dati. Per quest'ultimo scopo nella RSOH vengono utilizzati 3xN bytes per fornire N canali dati bidirezionali a 192 Kbit/s orientati ai messaggi di allarme, maintenance, controllo, monitoraggio, amministrazione e ulteriori necessità di comunicazione tra due sezioni che processano l'intestazione RSOH. Nella MSOH vengono utilizzati 9xN bytes per fornire N canali dati bidirezionali a 576 Kbit/s, non accessibili ai rigeneratori, per scopi simili a quelli della sezione RSOH. I canali di cui sopra vengono indicati con la sigla DCC (Data Communication Channel) ed in particolare DCCR o DCCM, se provenienti rispettivamente da RSOH o MSOH; essi costituiscono il livello fisico per il supporto di canali logici di controllo detti ECC (Embedded Control Channel) per la comunicazione dati entro la rete SDH.

Restano ora da considerare gli aspetti che riguardano più propriamente il controllo degli apparati e l'accesso alla rete di fig.1 da parte di un Gestore appartenente alla rete SDH o, più in generale, appartenente ad una rete TMN che include quella SDH.

A rigor di logica, il controllo e l'accesso sono due aspetti non completamente scindibili l'uno dall'altro. Per quanto riguarda il controllo, occorre distinguere tra apparati che nel loro insieme costituiscono la gerarchia SDH, come ad esempio i blocchi SDH-MX/DX e MPI di fig.4, ed apparati non strettamente SDH, come ad esempio la centrale telefonica APP. Nel primo caso il controllo viene esplicato dal Gestore per il tramite di una funzionalità che va sotto il nome di SEMF (Synchronous Equipment Management Function); nel secondo caso il Gestore non si avvale della funzionalità SEMF. In ambedue i casi tuttavia il Gestore accede agli apparati servendosi di una funzionalità che va sotto il nome MCF (Message Comraunication Function) . Le due funzionalità sono schematizzate nelle specifiche CCITT con degli omonimi blocchi, corrispondenti ai rispettivi blocchi indicati in fig.4 dell'esempio non limitativo. La funzionalità MCF prevede l'utilizzo di differenti tipi di interfaccia, di cui: una prima, verso i multiplex SDH, è fornita dai canali DCC; una seconda, verso la rete TMN, è illustrata nelle Raccomandazioni CCITT che riguardano l'interfaccia Q; una terza, verso un personal computer locale, denominata interfaccia F nell'insieme delle Raccomandazioni CCITT per le gerarchie SDH, non risulta a tuttora specificata; una quarta, verso il blocco SEMF, in seguito detta interfaccia V.

Per l'esplicazione della funzionalità di controllo da parte del blocco SEMF, sono previsti dei punti di riferimento Sn in ciascun blocco funzionale dell'insieme che in fig. 2-1 G.783 della Raccomandazione CCITT G.783 descrive funzionalmente un sistema SDH. Ai punti di riferimento Sn pervengono i comandi, opportunamente rielaborati, che il Gestore invia agli apparati SDH; oppure l'informazione sullo stato di funzionamento che gli apparati SDH rendono ivi disponibile in forma molto sintetica. Questa informazione riguarda, ad esempio: la configurazione circuitale degli apparati, le anomalie di funzionamento, gli eventuali guasti, la presenza di allarmi, o altre specifiche informazioni richieste dal Gestore.

Per quanto detto, i punti di riferimento Sn possono essere visti come punti d'interfaccia tra l'hardware e il software, mantenendo una certa qual si voglia analogia con i "sense e control points" universalmente utilizzati nel controllo dell 'hardware per mezzo di microprocessori. Le informazioni, e i comandi, viaggiano su un bus seriale detto S-bus che collega il blocco SEMF a rispettive interfacce con i punti di riferimento Sn nei vari apparati, realizzando una connessione di tipo punto/multipunto.

Ciò posto, il blocco SEMF converte le informazioni ricevute dagli apparati, tramite S-bus, in messaggi di tipo "object oriented" che invia al blocco MCF per la loro trasmissione al Gestore attraverso le opportune interfacce. Esso anche converte messaggi di tipo "object oriented", provenienti dal Gestore tramite MCF, in una forma adatta ad essere trasferita agli apparati attraverso i punti di riferimento Sn.

11 blocco MCF riceve e accoda messaggi provenienti dal blocco SEMF e dalle interfacce DCC, Q e F. I messaggi non indirizzati localmente vengono trasferiti a uno o più canali di comunicazione DCC uscenti, in accordo con le procedure locali d'instradamento , e/o a quelle delle interfacce Q. Concludendo, il blocco MCF rende compatibili i protocolli di livello fisico alle varie interfacce, offrendo con ciò ad una rete TMN una via di connessione "logica" con qualunque apparato SDH, attraverso una sola interfaccia Q e dei canali DCC di interconnessione. Un insieme di Raccomandazioni CCITT che ampliano le nozioni precedenti e descrivono molto in dettaglio le gerarchie SDH, per quanto riguarda: la loro organizzazione circuitale, le funzioni svolte dai singoli circuiti, l'interfacciamento, gli aspetti gestionali, o altro ancora, é la seguente:

(a) G.707, G.708 e G.709 forma un insieme coerente di specifiche per le gerarchie digitali sincrone (SDH) e l'interfaccia verso il nodo di rete (NNI);

(b) G.781 fornisce la struttura delle Raccomandazioni sugli apparati di multiplazione per le gerarchie SDH;

(c) G.782 descrive i tipi e le caratteristiche generali degli apparati SDH;

(d) G.783 specifica le caratteristiche dei blocchi funzionali degli apparati di multiplazione SDH;

(e) G.958 specifica i sistemi di linea digitali basati su SDH per utilizzo con cavi in fibra ottica;

(f) G.773 definisce il protocollo seguito per le interfacce Q; (g) G.784 definisce gli aspetti di gestione delle gerarchie SDH;

(h) G.774 definisce il Modello Informativo che riguarda le gerarchie SDH.

Gli argomenti esposti sopra a riguardo delle gerarchie SDH, unitamente al contenuto delle Raccomandazioni citate, rendono ora più facilmente comprensibile il funzionamento dei blocchi di figg.4 e 5, che schematizzano rispettivamente un nodo di rete Ni e un rigeneratore R basati appunto su SDH.

Ciò posto, e con riferimento alla fig.4, la centrale APP è un autocommutatore che compie l'instradamento dei segnali fonici in chiamata originata o terminata. Per chiamate diverse da quelle originate e nel contempo terminate in centrali urbane T connesse al nodo Ni (fig.1), la centrale APP include dei multiplatori/demultiplatori a divisione di tempo (non visibili in fig.4) che multiplano gruppi di canali telefonici uscenti da APP entro trame seriali di linee uscenti facenti parte di rispettivi fasci Fsc(l-2), Fsc(l-3) e Fsc(l-4), e demultiplano trame seriali di linee entranti appartenenti agli stessi fasci, ottenendo canali telefonici che la centrale APP instrada verso le linee In.

1 multiplatori/demultiplatori di APP risultano tributari rispetto al blocco SDH-MX/DX, che svolge tutte le funzioni degli apparati di multiplexing/demultiplexing di un sistema SDH. I segnali pertinenti ai suddetti tributari sono stringhe di bit con, ad esempio, le seguenti possibili frequenze di bit: 1.544, 2.048, 6.312, 8.448, 34.368, 44.736 e 139.246 Kbit/s e comprendono gruppi di canali PCM (Pulse Code Modulation) a 64 Kbit/s disposti entro trame primarie plesiocrone, a loro volta multiplate entro trame appartenenti a livelli gerarchici via via crescenti, secondo il dettato delle Raccomandazioni CCITT G.702. Per quanto concerne le caratteristiche elettriche dei segnali G.702 presenti all'interfaccia NNI di fig.4, esse sono definite nelle Raccomandazioni CCITT G.703. Ricordando quanto era stato detto in precedenza sui sistemi SDH, il blocco SDH-MX/DX sincronizza all'orologio di rete i flussi plesiocroni provenienti dalle linee dei fasci Fsc(l-2), Fsc(l-3) e Fsc(l-4), e quindi assembla i moduli STM appartenenti alle pluralità di linee seriali STM-N(l-2), STM-N(l-3) e STM-N(l-4) uscenti dal nodo NI. Lo stesso blocco disassembla i moduli STM appartenenti alle pluralità di linee seriali STM-N(l-2), STM-N(l-3) e STM-N(l-4) entranti nel nodo NI, desincronizza i flussi inclusi nei contenitori C-n e li invia alle linee dei fasci Fsc(l-2), Fsc(l-3) e Fsc(l-4). Il blocco SDH-MX/DX opera in modo tale per cui, in caso di traffico normale lungo tutte le direzioni che si diramano dal nodo Ni, c'è corrispondenza tra il traffico presente sul fascio Fsc(l-2) e quello presente sulla pluralità STM-N(l-2), lo stesso vale per Fsc(l-3) con STM-N(l-3) e per Fsc(l-4) con STM-N(l-4), mentre in caso di traffico eccessivo lungo una particolare direzione, parte del traffico presente su un fascio può essere deviato lungo una direzione diversa da quella precedentemente indicata.

Entro ciascuna pluralità di linee seriali STM-N(l-2), STM-N(l-3) e STM-N(l-à) sono previste, per ragioni di sicurezza, una, o più, linee di riserva sulle quali viene commutato il traffico di una, o più, linee in esercizio che presentano interruzioni dovute a guasti o ad eccessivo affievoliraento del segnale.

Il blocco SDH-MX/DX include tutti i circuiti necessari per compiere sui segnali le operazioni di interfacciamento di linea, scrambling/descrambling e multiplexing/demultiplexing tipiche delle gerarchie SDH, come ben specificate nelle Raccomandazioni CCITT precedentemente citate. Esso include inoltre un generatore di un segnale di orologio e di opportuni segnali di sincronismo che forniscono le temporizzazioni richieste per un corretto funzionamento dei diversi blocchi.

I blocchi MPI(l-2), MPI(l-3) e MPI(l-4) ricevono i segnali presenti sulle linee appartenenti rispettivamente alle pluralità STM-N(l-2), STM-N(l-3) e STM-N(l-4) uscenti dal blocco SDH-MX/DX, e compiono tutte quelle operazioni usualmente richieste per la trasmissione di detti segnali sfruttando il mezzo trasmissivo rappresentato dalle linee LP(l-2), LP(l-3) e LP(l-4) . I suddetti blocchi compiono anche le operazioni duali che partono dalla ricezione dei segnali presenti sulle linee LP(l-2) , LP(l-3) e LP(l-4) e conducono all'ottenimento dei moduli STM-N da accomodare su rispettive linee delle pluralità STM-N(l-2), STM-N(l-3) e STM-N(l-4) entranti nel blocco SDH-MX/DX.

Nel caso dell'esempio illustrato, le linee LP(l-2), LP(l-3) e LP(l-4) rappresentano tratte di un collegamento in ponte radio a microonde in cui i canali radio sono assegnati in conformità ad un piano internazionale di ripartizione delle frequenze, che prevede una spaziatura di 28, o 30, o 40 MHz tra portanti modulate trasmesse a polarizzazione incrociata alternata, come meglio risulta dalle Raccomandazioni CCIR in merito. Un problema che si pone nel rispetto di questo piano è quello di individuare un opportuno schema di modulazione del segnale digitale che consenta di accomodare al meglio i moduli digitali STM-N entro le bande assegnate ai canali. Nei blocchi MPI di figg.4 e 5 è stato utilizzato uno schema di modulazione di tipo Trellis Coding, abbinando un decodificatore di Viterbi in ricezione. L'elevata efficienza spettrale in tal modo raggiunta ha reso possibile convogliare ben due moduli STM-1 da 155.520 Kbit/s, in un canale con larghezza di banda di 40 MHz.

Le restrizioni poste sulla larghezza di banda dei canali radio dal piano CCIR di ripartizione delle frquenze, non esiste ovviamente per le trasmissioni in fibra ottica, ove viene utilizzata per intero la banda base del segnale digitale. Poiché l'esempio illustrato è dato in senso non limitativo, è possibile anche realizzare le linee LP(l-2), LP(l-3) e LP(l-4) in fibra ottica, riuscendo cosi a trasmettere moduli STM-4 a 622 Mbit/s e moduli STM-16 a 2,5 Gbit/s. In tal caso il funzionamento dei blocchi MPI deve essere in accordo alla Raccomandazione CCITT G.958 che specifica i sistemi di linea digitali basati su SDH utilizzanti cavi in fibra ottica.

Ciò posto, e considerando solo il caso dei collegamenti in ponte radio, le operazioni compiute in trasmissione sui segnali digitali lxSTM-1, o 2xSTM-1, sono essenzialmente le seguenti: codifica dei segnali, modulazione digitale M-QAM o ad essa riconducibile (nel caso del Trellis Coding le due fasi non sono ben distinguibili) , conversione in salita delle bande di frequenze dei segnali modulati, nel rispetto della spaziatura prevista tra i canali, amplificazione di potenza a radiofrequenza, filtraggio passa banda nella banda di ciascun canale ed accoppiamento dei segnali filtrati all'antenna per la loro trasmissione. In ricezione vengono compiute le seguenti operazioni duali: accoppiamento del segnale di ricezione ai filtri di canale, amplificazione a radiofrequenza dei segnali filtrati, conversione in discesa delle bande di ciascun canale entro la banda a frequenza intermedia, demodulazione di ciascun canale, equalizzazione in banda base, decodifica ed eventuale correzione degli errori.

Dopo aver brevemente illustrato il funzionamento dei blocchi SDH-MX/DX e MPI, rimane ora da illustrare quello del blocco SDH-ECF, ovvero dei blocchi MCF e SEMF componenti, al fine di chiarire le opportunità offerte dalla rete SDH alla funzionalità gestionale del blocco GESTORE. Gran parte di queste opportunità sono fornite dalle molteplici e sofisticate possibilità di collegamento che la rete SDH mette a disposizione del blocco GESTORE per comunicare con gli "oggetti" gestiti, questi ultimi collocati in un punto qualsiasi della rete TMN. Di conseguenza, prima di procedere, sembra utile meglio dettagliare le funzioni del blocco SDH-MX/DX per quanto riguarda il supporto fisico che i canali di comunicazione DCC forniscono alle vie di connessione entro la rete.

Consideriamo dapprima le pluralità STM-N(l-2), STM-N(l-3) e STM-N(l-4) uscenti da NI (fig.1), tramite i blocchi MP1, e rispettivamente dirette verso N2, N3 ed N4. Come era già stato detto, il blocco SDH-MX/DX genera i bytes delle sottointestazioni RSOH e MSOH dei moduli STM-N posti sulle linee appartenenti a ciascuna pluralità uscente. Per ciascun modulo STM-N, esso immette nei 3xN bytes seriali che costituiscono N canali DCCR di trasmissione, e nei 9xN bytes seriali che costituiscono N canali DCCM di trasmissione, altrettanti bytes seriali ricevuti dal blocco MCF tramite le linee seriali DCC-LS.

Consideriamo ora le pluralità STM-N(l-2), STM-N(l-3) e STM-N(l-4) entranti in NI (fig.1), attraverso i blocchi MPI, e provenienti rispettivamente da N2, N3 e N4. Il blocco SDH-MX/DX ricerca il sincronismo di trama dei moduli STM-N provenienti dalle linee appartenenti a ciascuna pluralità, dopodiché per ciascun modulo STM-N processa i bytes significativi delle sottointestazioni RSOH e MSOH ed invia serialmente al blocco MCF i 3xN bytes seriali che costituiscono N canali DCCR di ricezione e i 9xN bytes seriali che costituiscono N canali DCCM di ricezione, utilizzando per questo le linee seriali DCC-LS.

Per quanto riguarda il funzionamento del rigeneratore schematizzato in fig.5 occorre premettere che, poiché le linee di connessione LP(l-2) sono tratte di un ponte radio, il rigeneratore è in realtà un ripetitore. Nel ripetitore il blocco SDH-RIG svolge tutte le funzioni previste nelle citate Raccomandazioni CCITT come a carico dei rigeneratori, ad esclusione di quelle di controllo e di comunicazione che sono svolte dal blocco SDH-ECF del ripetitore, secondo modalità analoghe a quelle dell'omonimo blocco di fig.4.

Prendendo ora in considerazione il senso di propagazione dei segnali sulle linee LP(l-2) dal nodo Ni al nodo N2, il blocco MPI(l-2) opposto al nodo Ni riceve il segnale a radiofrequenza e svolge le già menzionate funzioni che portano all'ottenimento dei moduli STM-N applicati alle linee della pluralità STM-N(l-2) entrante nel blocco SDH-RIG. Il blocco SDH-RIG ricerca il sincronismo di trama dei moduli STM-N entranti, dopodiché, per ciascun modulo STM-N, processa i bytes della sottointestazione RSOH ed invia serialmente al blocco SDH-ECF i 3xN bytes che costituiscono gli N canali DCCR di ricezione, utilizzando per questo le linee seriali DCC-LS. Il blocco SDH-ECF, a sua volta, pone il contenuto di messaggi da inviare verso il nodo N2 entro canali DCCR di trasmissione, che raggiungono il blocco SDH-RIG mediante le linee seriali DCC-LS. Il blocco SDH-RIG immette i suddetti canali DCCR entro i corrispondenti 3xN bytes seriali delle sottointestazioni RSOH di moduli STM-N uscenti, questi ultimi ottenuti sincronizzando i moduli STM-N entranti con l'orologio di rete. I moduli STM-N sincroni sono quindi applicati ad altrettante linee di una pluralità STM-N(l-2) uscente dal blocco SDH-RIG ed entrante nel blocco MPI(l-2) opposto al nodo N2. Il blocco MFI(l-2) compie sui segnali entranti tutte le operazioni già menzionate per l'ottenimento di un segnale a radiofrequenza, che viene trasmesso sulle linee LP(l-2) dirette verso il nodo N2. Considerazioni duali valgono per il senso di propagazione dei segnali dal nodo N2 al nodo NI.

I canali DCCM e/o DCCR che nella precedente descrizione dei blocchi SDH-MX/DX e SDH-RIG facevano capo ai blocchi MCF, non sono da questi blocchi originati o terminati. L'origine e/o la terminazione dei messaggi che attraversano il blocco MCF di fig.4 sono da ricondursi ai blocchi APP, SDH-MX/DX, MPI, GESTORE, PC ed infine ad eventuali ulteriori entità gestionali comprese nei nodi della rete di fig.1 che utilizzano per comunicare, direttamente o indirettamente, i mezzi di trasporto della rete SDH, costituiti dai canali DCC. Come già era stato detto nella parte introduttiva sulle gerarchie SDH, il blocco MCF è una funzionalità che agevola il trasporto dei messaggi TMN tra i processi applicativi che partecipano alla gestione, senza per questo originare e terminare messaggi di tipo applicativo. Le nozioni della precedente parte introduttiva verranno ora ampliate illustrando il funzionamento di questo blocco, e le caratteristiche delle interfacce DCC, V, F e Q previste tra il blocco MCF e i blocchi SDH-MX/DX, SEMF, PC e GESTORE rispettivamente.

Ciò premesso, il blocco MCF opera come segue:

riceve e accoda messaggi provenienti dai blocchi SDH-MX/DX, SEMF, PC e GESTORE rispettivamente per il tramite delle linee DCC-LS e dei bus V-bus, F-bus e Q-bus; analizza il campo indirizzi dei vari messaggi per compiere l'opportuno instradamento degli stessi;

converte il protocollo attinente al livello fisico (1) di un messaggio ricevuto ad una interfaccia, nel protocollo attinente al livello fisico dello stesso messaggio inviato ad una interfaccia di destinazione, qualora detti protocolli differiscano tra loro.

Per quanto riguarda le interfacce DCC, V, F e Q, esse sono qui di seguito brevemente illustrate, precisando che l'invenzione in oggetto, che riguarda essenzialmente il funzionamento del blocco SEMF, non viene influenzata dai protocolli presenti alle suddette interfacce.

All'interfaccia DCC opera un protocollo di comunicazione OSI a 7 livelli particolarmente adatto a soddisfare i requisiti necessari per il trasferimento di messaggi di gestione, detti di OAM&P, (Operations, Administration, Maintenance and Provisioning) mediante i canali DCC. Lo stack di protocollo è visibile in figura 6-1/G.784, pagina 19, della Raccomandazione CCITT G.784. Nello stack, il protocollo del livello più basso (fisico) è fornito dai canali DCCR e DCCM che viaggiano sulle line seriali DCC-LS, mentre il livello più alto (applicativo) comprende le seguenti applicazioni:

a) ASE (Application Service Element) per OAM&P;

b) CMISE (Common Management Information Service Element), è un protocollo basato sul paradigma "object oriented" che rappresenta le entità di rete, le funzioni di gestione della rete, e le informazioni in genere, come oggetti caratterizzati da un insieme di attributi e di operazioni che possono essere effettuate sugli stessi. I servizi CMISE possono abilitare il Gestore di rete a: creare o cancellare gli oggetti (CREATE/DELETE) ; definire o ridefinire valori agli attributi degli oggetti (SET e GET); invocare operazioni sugli oggetti (ACTION); ricevere dei resoconti dagli oggetti (EVENT REPORTS).

c) ROSE (Remote Operation Service Element) consente ad un sistema di richiedere una operazione ad un altro sistema e di essere informato dei risultati di quella operazione. d) ACSE (Association Control Service Element) fornisce servizi per iniziare e terminare una associazione (connessione) tra due applicazioni, associazione che viene poi usata per convogliare i messaggi di gestione corrispondenti ai servizi forniti da CMISE.

L'interfaccia Q utilizza dei protocolli particolarmente adatti per il dialogo sistemi/apparati, visto nell'ottica della Raccomandazione M.30 per le reti TMN. Esempi particolarmente esplicativi circa i possibili utilizzi dell'interfaccia Q sono visibili nelle figure da 3-1/G.784 a 3-9/G.784 della Raccomandazione CCITT G.784.

All'interfaccia Q sono previsti due diverse tipologie di protocollo, di cui una prima utilizza uno stack più corto rispetto a quello OSI a 7 livelli utilizzato dalla seconda. Lo stack di protocollo corto è più adatto alle comunicazioni entro reti locali, e viene a sua volta specificato secondo due diverse modalità realizzative chiamate Al e A2. Lo stack completo è più adatto per soddisfare alle richieste dei più complessi elementi della rete SDH e viene specificato secondo tre possibili modalità chiamate B1, B2 e B3. La definizione funzionale del termine "elemento di rete SDH", detto anche NE (Network Element), è riportata a pag.4 della Raccomandazione CCITT G.784. I cinque possibili stacks di protocollo della interfaccia Q sono visibili in figura 1/G.773, pagina 5, della Raccomandazione CCITT G.773. Nei suddetti stacks, i protocolli del livello più basso sono in accordo con le Raccomandazioni CCITT che riguardano la trasmissione dati, ad esempio la X.25, o la V.24, o la EIA IRS 485. Le velocità possibili per i dati sul bus seriale full-duplex Q-bus vanno da 1.200 a 64.000 Kbit/s. Il livello più alto comprende l'applicazione NM-ASE (Network Management-Application Service Element) e le già citate applicazioni CMISE, ROSE e ACSE.

L'interfaccia F, non essendo specificata, può essere liberamente realizzata dal costruttore. Nel caso dell'esempio è stato utilizzato uno stack di protocollo simile a quello Al dell'interfaccia Q. Per quanto riguarda l'interfaccia V, essa viene indicata nelle Raccomandazioni CCITT solo come punto di riferimento V, infatti il collegamento in questo punto è realizzato mediante un bus di microprocessore che trasporta soltanto i messaggi dell'applicativo CMISE, nessuna operazione di protocollo viene compiuta ai capi del collegamento, ciò che avviene sono semplici operazioni di lettura e scrittura effettuate dal blocco SEMF entro un buffer in carico al blocco MCF.

Prendiamo ora in considerazione il funzionamento del blocco SEMF di fig.4, meglio dettagliando quanto già detto al riguardo nella parte introduttiva sulle gerarchie SDH, ove si era pure detto della presenza di interfacce tra il bus seriale S-bus ed i punti di riferimento Sn appartenenti ai blocchi funzionali (non visibili in fig.4) nei quali i blocchi SDH-MX/DX e MPI sono funzionalmente scomponibili. Viene qui precisato che le suddette interfacce corrispondono ai sottoblocchi H/S di figg.4 e 5, la cui funzione è quella di serializzare opportunamente l'informazione posta nei punti Sn associati ai suddetti blocchi funzionali, e deserializzare l'informazione proveniente dal blocco SEMF diretta verso gli stessi blocchi, facendola quindi pervenire ai punti di riferimento Sn.

L'informazione che raggiunge il blocco SEMF attraverso S-bus riguarda principalmente, ma non esclusivamente, la segnalazione di guasti circuitali e di anomalie e difetti di funzionamento da parte dei blocchi SDH-MX/DX e MPI. La suddetta informazione è riportata per esteso nelle tabelle da 5-1/G.783 a 5-11/G.783 della Raccomandazione CCITT G.783. Queste tabelle indicano inoltre le conseguenti azioni da intraprendre entro i blocchi funzionali, quali esse risultano nelle rispettive sezioni della stessa Raccomandazione. Queste azioni consistono principalmente nell'inserzione di indicazioni di allarme (AIS, FERF, FEBE) in alcuni bytes (K2, Gl) della intestazione SOH delle trame STM-N interessate, come risulta nei paragrafi intitolati: "Section maintenance signals" e "Path raaintenance signals", a pag.10 e 11 della Raccomandazione CCITT G.709. Le azioni indicate nelle tabelle avvengono sulla base di comandi inviati dal blocco GESTORE.

Il blocco SEMF attua dei meccanismi di filtraggio dei dati provenienti da S-bus, riducendo in tal modo la quantità di dati da elaborare e rendendo maggiormente persistente l'informazione acquisita. Allo scopo sono utilizzati i seguenti filtri: un integratore delle anomalie nell'intervallo di un secondo, un rivelatore di persisteza dei difetti, ed infine un filtro che processa le uscite dei due precedenti e fornisce più stringenti Indicazioni di errore. Come già era stato detto, il blocco SEMF opera secondo la metodologia "object oriented", che viene utilizzata in modo uniforme entro la rete di fig.1 sia negli applicativi di gestione che nei protocolli di comunicazione. Una indicazione molto generale della struttura interna del blocco SEMF è riportata in fig. 5-1/G.783 della Raccomandazione CCITT G.783, ove sono visibili, oltre ai filtri, tre ulteriori blocchi funzionali rispettivamente chiamati: OGGETTI GESTITI, AGENTE DI APPARATO, e OROLOGIO DEL TEMPO REALE, non visibili in fig.4. Il blocco OGGETTI GESTITI elabora l'informazione presente all'uscita dei filtri per renderla conforme al paradigma degli "oggetti" e in tal forma la rende disponibile al blocco AGENTE DI APPARATO. Il blocco AGENTE DI APPARATO converte l'informazione ricevuta dal blocco OGGETTI GESTITI in messaggi del protocollo OMISE, che trasferisce al blocco GESTORE tramite V-bus e MCF. Inoltre detto blocco risponde ai messaggi CMISE provenienti dal blocco GESTORE, per la stessa via, e compie sugli oggetti le operazioni richieste dal Gestore, eventualmente per il tramite del blocco OGGETTI GESTITI.

Il tipo di informazione trattata dal blocco OGGETTI GESTITI, e quindi da AGENTE DI APPARATO, dipende dalle particolari funzioni gestionali previste nel blocco GESTORE per il controllo degli apparati SDH.

Consideriamo quindi molto brevemente il funzionamento del blocco GESTORE (MANAGER) di fig.4, coadiuvato in questo dal personal computer PC che può rivelarsi particolarmente utile nella fase di installazione e inizializzazione degli apparati, come pure durante la ricerca guasti e nelle operazioni di maintenance . Il personal computer PC potrebbe anche svolgere funzioni più complesse rispetto a quanto appena detto, diventando un Gestore completamente indipendente dal blocco GESTORE (MANAGER) (MANAGER), e altri Gestori potrebbero ancora aggiungersi a questi due. In tal caso, il sistema verrebbe parallelamente gestito da una pluralità di Gestori tra loro coordinati, come anche risulta dalla schematizzazione di fig.3 che evidenzia più blocchi MANAGER e più blocchi AGENT.

Il blocco GESTORE (MANAGER) di fig.4, fisicamente è un elaboratore di gestione posto, per convenzione, nel nodo NI (fig.1); funzionalmente esso è una complessa entità gestionale dedicata al governo e alla manutenzione di risorse sia interne che esterne al nodo NI, che nel loro complesso costituiscono il sottosistema gestito. Queste risorse sono gli elementi di rete NE, e più in generale TMN, inclusi nei nodi NI, N2, N3 e N4.

Per quanto riguarda le funzionalità gestionali per il governo di elementi non strettamente SDH, come ad esempio la centrale telefonica APP di fig.4, è in genere previsto l'utilizzo nella rete SDH di elementi GNE (Gateway Network Elements) aventi funzione di adattatori di protocollo. Le funzionalità gestionali del blocco GESTORE (MANAGER) riferite, ad esempio, alla centrale APP e similari, possono riguardare più che altro gli aspetti connessi all'inserimento in rete delle stesse, come potrebbe essere il bilanciamento del traffico telefonico sulle linee LP, in quanto dette centrali già possiedono dei propri elaboratori che ne governano il funzionamento e amministrano e mantengono le rispettive risorse .

Prima di poter svolgere le altre funzionalità gestionali, il blocco GESTORE (MANAGER) deve svolgere quella che concerne la creazione e la gestione di tanti canali di controllo ECC quanti ne servono per poter colloquiare con gli elementi gestiti .

Nel caso dell'esempio non limitativo vengono considerate, per semplicità, le sole funzionalità gestionali che riguardano le gerarchie SDH. Tra queste, particolare rilevanza ai fini dell'invenzione assumono quelle di verifica dei guasti, in particolare la sorveglianza degli allarmi, e quella di monitoraggio delle prestazioni di funzionamento, poiché esse danno luogo a riporto di evento. Un'altra funzione che deve essere menzionata, qualora prevista, è quella di memorizzazione storica nel LOG degli eventi provenienti dalle attività di cui sopra. Nel caso dell'esempio, come già era stato detto commentando la fig.3, il blocco GESTORE (MANAGER) di fig.4 non utilizza il contenuto del LOG per ricuperare il proprio allineamento, esso può tuttavia utilizzarlo per generare delle stampe periodiche, o per altri scopi similari.

Per un dettaglio delle funzionalità gestionali SDH appena accennate si rimanda al capitolo 5 "Management functions" della Raccomandazione CCITT G.784. E' utile nuovamente puntualizzare che il blocco GESTORE (MANAGER) di fig,4, utilizzando i canali di controllo ECC, è in grado di gestire il riporto di evento in elementi di rete NE posti in qualunque nodo e/o rigeneratore della rete di fig.1. I blocchi MCF e SEMF di fig.4 realizzano le loro molteplici funzionalità utilizzando dei rispettivi microprocessori .

Il tecnico del ramo, alla luce dì quanto finora detto, dell'insegnamento contenuto nei documenti di specificazione citati, ed esercitando comuni conoscenze nel settore delle trasmissioni di segnali digitali, unitamente a comuni conoscenze nel campo dei microprocessori e del trattamento della segnalazione nelle reti di telecomunicazioni, può realizzare circuitalmente e rendere operanti i diversi blocchi di figg.4 e 5, ad esclusione di quelle funzioni del blocco SEMF che riguardano più propriamente l'invenzione in oggetto, per cui vale quanto già è stato detto illustrando la fig.3 e quanto verrà detto ulteriormente a riguardo illustrando le figg.6, 6.a, 7, 8, 9, 10 e 11.

A questo punto ci sono tutti gli elementi per poter assegnare i diversi moduli di fig.3 a rispettivi blocchi funzionali di figg.4 e 5. Con riferimento alle figg.3 e 4, al blocco GESTORE (MANAGER) viene evidentemente assegnato il modulo GESTORE; al blocco MCF viene assegnato il modulo STACK DI PROTOCOLLO; al blocco SEMF vengono assegnati i rimanenti moduli, e cioè: RILEVAZIONE DI EVENTO, COD-CIR, RIPORTO DI EVENTO (AGENT) e RICUPERO DI ALLINEAMENTO, a questo blocco viene pure assegnato il buffer d'evento che realizza la coda circolare. Per quanto riguarda il rigeneratore di fig.5, i moduli di fig.3, ad eccezione del modulo GESTORE che qui non è previsto, vengono tutti assegnati al blocco SDH-ECF e da qui ripartiti agli inclusi blocchi MCF e SEMF (non visibili), con le stesse modalità di assegnazione valide per gli omonimi blocchi di fig.4.

Entrando maggiormente in dettaglio rispetto al blocco SEMF, si possono assegnare al blocco OGGETTI GESTITI i moduli RILEVAZIONE DI EVENTO, COD-CIR e RICUPERO DI ALLINEAMENTO, ed anche il buffer d'evento, mentre il modulo RIPORTO DI EVENTO (AGENT) viene assegnato al blocco AGENTE DI APPARATO. Nel caso di utilizzo del LOG questo è anch'esso incluso nel blocco OGGETTI GESTITI.

Il buffer di evento posto nel blocco SEMF di fig.4, come pure i mezzi che ne consentono la lettura e scrittura, vengono visualizzati in figg.6 e 6.a. Con riferimento alla fig.6 si nota un vettore Q di n elementi che corrisponde appunto al suddetto buffer di evento. Il vettore Q viene scritto per mezzo di un puntatore di scrittura, corrispondente al valore di una variabile W che può assumere valori interi compresi tra 1 e n. Per convenzione, il puntatore di scrittura indica l'indirizzo della prossima scrittura nel vettore Q. Detto vettore può essere letto da k processi di lettura contemporaneamente attivi, che allo scopo utilizzano altrettanti puntatori di lettura. Ciascun puntatore di lettura corrisponde ad un elemento di un vettore R di k elementi, i quali possono assumere valori interi compresi tra 1 e n. Un puntatore di lettura associato ad un generico processo indica, per convenzione, l'indirizzo della prossima lettura nel vettore Q che verrà effettuata da quel processo.

In figura sono inoltre visibili un vettore 0 di k elementi, detto in seguito vettore di overflow, ove ciascun elemento è una variabile logica che può assumere solo i valori "Vero'<1 >o "Falso". Un elemento del vettore Q è visibile a sè stante con la dicitura Evento. Illustrando le successive figure riferite ai moduli software dell'esempio non limitativo verranno considerati, per semplicità, eventi che possono essere descritti da un solo elemento del vettore Q; ciò non toglie generalità all'invenzione per i casi in cui gli eventi siano costituiti da più elementi e possano avere lunghezza fissa o variabile. La trattazione di questi casi è alla comune portata del programmatore. Nel seguito i singoli puntatori di lettura verranno indicati con R(ra), ove m è un indice che può variare in modo unitario da 1 a k; similmente ciascun elemento del vettore 0 verrà indicato con 0(m) e verrà associato ad un rispettivo elemento R(m) del vettore R.

In fig.6.a è visibile una rappresentazione del vettore Q a guisa di coda circolare, ottenuta tramite l'incremento unitario modulo n del puntatore di scrittura W e dei puntatori di lettura appartenenti al vettore R. Nella figura la coda circolare è rappresentata da una corona circolare suddivisa in Q settori, corrispondenti agli n elementi di Q. I puntatori sono rappresentati come vettori che partono dal centro e sono diretti verso un rispettivo elemento, ogni incremento unitario di un puntatore produce una rotazione dello stesso di 360°/n. Una freccia semicircolare indica il senso di rotazione comune a tutti i vettori. Di questi, uno rappresenta il puntatore W e tre altri indicati con R(l), R(2) e R(k) rappresentano tre puntatori di lettura diversamente posizionati nella coda. Il puntatore W viene incrementato in istanti di tempo casuali, poiché casuale è la generazione degli eventi. I puntatori di lettura subiscono incrementi temporalmente indipendenti l'uno dall'altro, che si verificano in istanti di tempo casuali ed asincroni rispetto a quelli di incremento di W. Gli incrementi dei puntatori R(m) sono legati all'attività di altrettanti AGENT, in relazione alle disponibilità dei rispettivi MANAGER. Quale conseguenza delle suddette casualità, partendo da una situazione iniziale in cui sia W che gli R(m) hanno valore unitario, l'evoluzione degli stessi può risultare del tutto arbitraria e dare luogo a diverse situazioni, di cui una è rappresentata in fig.6.a. E' fondamentale ai fini della progettazione del software che gestisce la coda e opera il riallinearaento, ottenere dei criteri per diagnosticare le diverse situazioni in cui la coda può venire a trovarsi, perchè in base ad esse verranno prese differenti decisioni. Queste situazioni, valutate rispetto ad un generico processo di lettura, sono essenzialmente le seguenti: coda vuota, coda parzialmente piena, coda completamente piena, e overflow della coda rispetto ad un generico processo di lettura. Tra queste, l'overflow e la coda vuota sono le uniche che possono causare inconvenienti; l'inconveniente dell'overflow è la perdita di eventi remoti per sovrascrittura, mentre quello di coda vuota è la lettura di eventi nulli, oppure già letti.

Sotto opportune limitazioni, i criteri per stabilire le situazioni di overflow e di coda vuota sono costituiti dalla uguaglianza tra il puntatore di scrittura W e quelli di lettura R(m) , rispettivamente verificate in fase di scrittura e di lettura. Per comprendere e discutere questa affermazione è opportuno mantenere la definizione già fornita sul significato del termine puntatore, ed inoltre stabilire che il confronto tra il valore dei puntatori W e R(m) viene eseguito prima della rispettiva scrittura, o lettura, in coda e prima dello incremento degli stessi. Questo non costituisce limitazione alcuna, è solo una convenzione che serve come base per i futuri ragionamenti .

Ciò posto, la semplice condizione W ><» >R(m) non è sufficiente per individuare un'unica situazione della coda. Infatti, la condizione verificata prima di una scrittura potrebbe significare coda in overflow (a scrittura effettuata), se la coda è già piena, o primo evento in coda, se invece la coda è vuota. La condizione W - R(m) verificata prima di una lettura potrebbe significare coda vuota, oppure coda completamente piena.

Si è trovato che imponendo il vincolo costituito dal fatto che il puntatore di scrittura W preceda sempre i puntatori di lettura R(m), è possibile diagnosticare in modo univoco la situazione di overflow e di coda vuota.

Il suddetto vincolo di precedenza del puntatore W viene imposto agendo come segue: al termine della fase di inizializzazione , in cui W e tutti gli R(m) sono posti al valore unitario, bisogna evitare il confronto W - R(m) prima della prima scrittura in coda, poiché esso è sicuramente vero, segnalando overflow pur essendo la coda vuota. Inoltre, prima di ogni lettura in coda se risulta W — R(m) bisogna arrestare la lettura fino a quando almeno una scrittura non sia stata compiuta, cioè fino a quando non risulti W ≠ R(m). Così facendo resta ancora una possibile ambiguità da risolvere, che nasce dal fatto che la scrittura in coda non può essere arrestata in caso di overflow relativo a un processo di lettura m, pena la perdita di eventi per i processi per cui la coda non è in overflow. La suddetta ambiguità si presenta quando, prima di una lettura, risulta W = R(m); infatti questa condizione potrebbe derivare sia da coda vuota come pure da coda completamente riempita dopo un overflow. L'ambiguità viene eliminata semplicemente verificando, prima della lettura, se è tuttora presente una condizione di overflow della coda Q per il suddetto processo di lettura jn; se non c’è overflow ne consegue che la condizione W - R(m) significa sicuramente coda vuota. La presenza di overflow è segnalata dal valore Vero dell'elemento 0(m) del vettore 0.

Per quanto concerne il dimensionamento della coda Q, occorre considerare i seguenti fattori che ne condizionano la lunghezza:

- fattori direttamente riconducibili alle dimensioni del sottosistema gestito, come ad esempio, il numero di variabili di stato considerate e la relativa lunghezza della informazione di evento;

- fattori che dipendono in modo statistico dall'attività del sottosistema gestito, come ad esempio, la probabilità che un dato evento abbia di manifestarsi entro un certo tempo. L'impatto che questi secondi fattori hanno sulla determinazione della lunghezza della coda Q può essere valutato conoscendo il tasso medio, e di picco, della emissione di evento valutato nel sottosistema gestito dal blocco GESTORE di fig.4. La lunghezza della coda deve essere tale da consentire alla coda di poter assorbire i picchi di evento per tutta la durata dei picchi stessi, specie nei casi più sfavorevoli;

fattori che dipendono dalla capacità di uno, o più, GESTORI di elaborare l'informazione ricevuta. Per questi fattori, occorre considerare che, pur essendo l'attività di un GESTORE 21 indipendente dalle letture della coda promosse dal proprio AGENT m, gli effetti negativi dovuti ad una saturazione del tempo reale di elaborazione del GESTORE m si ripercuotono a monte fino a condizionare i tempi di esecuzione delle letture in coda. Infatti, se il GESTORE m risultasse sovraccarico, esso non potrebbe più accedere alle informazioni di evento provenienti dall'AGENT m e dopo qualche tempo il modulo STACK DI PROTOCOLLO fermerebbe l'arrivo di nuovi eventi attraverso un opportuno meccanismo di controllo di flusso. Ovviamente ciò avrebbe come conseguenza per l'AGENT m il divieto temporaneo di attivare una nuova lettura della coda circolare Q, ove può intanto accumularsi un picco di eventi che, come si può notare, è dovuto a cause differenti da quelle probabilistiche che generano i picchi nell'emissione di evento. Nel caso appena considerato il dimensionamento della coda deve essere fatto tenendo conto di due esigenze tra loro contrastanti e di cui, una prima è quella di poter ospitare un cospicuo numero di eventi quando l'AGENT si attarda nello svuotamento della coda, mentre una seconda è quella di non occupare memoria più di quanto necessario. La prima esigenza è dettata dalla volontà di non perdere informazioni di evento durante i picchi, e propende più per un allungamento della coda rispetto ad una lunghezza in grado di far fronte ad attività del GESTORE considerate normali, mentre la seconda esigenza fa propendere più per un accorciamento della coda. Ovviamente la lunghezza ottimale nasce da un compromesso tra le due esigenze;

- fattori che dipendono dalla capacità dei canali di comunicazione utilizzati per trasferire gli eventi dalla coda al Gestore. Detti fattori, ai fini del dimensionamento della coda, conducono a ragionamenti simili a quelli trattati al punto precedente.

Dall'insieme delle considerazioni appena fatte si può comprendere come un dimensionamento della coda condotto su basi puramente teoriche, per quanto in linea di massima possibile, risulterebbe troppo oneroso, specie per via della complessità dei modelli matematici che descrivono i diversi fattori implicati. Ad esempio, può risultare difficile determinare i tassi di emissione di evento, in quanto fortemente dipendenti da condizioni non facilmente prevedibili, quali le propagazioni radio anomale caratterizzate da fading e interferenze da cammini multipli. In ogni caso la lunghezza della coda calcolata per via teorica necessiterebbe comunque di una verifica sperimentale. Risulta allora più pratico integrare le nozioni teoriche con un approccio empirico che valuta la lunghezza ottimale della coda mediante approssimazioni successive, e che comporta:

a) una stima iniziale di una lunghezza della coda;

b) la valutazione del grado di riempimento medio della coda nel lungo periodo;

c) la valutazione dei tassi di overflow entro un periodo di osservazione prefissato;

d) la variazione della lunghezza stimata di una quantità tale per cui il grado di riempimento e/o i tassi di overflow diminuiscano;

e) l'iterazione delle fasi b), c) e d) fino al raggiungimento di una lunghezza ottimale tale per cui la coda si mantiene mediamente vuota nel lungo periodo di osservazione e nel contempo assorbe bene i picchi d'evento senza andare in overflow, o almeno andandovi molto raramente;

f) l'aumento della lunghezza ottimale di un opportuno margine che tenga conto di ulteriori cause non facilmente prevedibili, oltre a quelle già menzionate, in grado di influenzare significativamente i fattori da cui dipende la lunghezza della coda.

Le precedenti considerazioni sulla coda Q evidenziano un ulteriore vantaggio del procedimento di riallineamento oggetto dell'invenzione, che non era stato ancora evidenziato, e che consiste nella forte attenuazione delle conseguenze negative per il sottosisteraa gestito quando la coda circolare non è stata correttamente dimensionata. Infatti, sotto l'ipotesi precedente, la condizione di overflow può scattare assai frequentemente, ma automaticamente essa innesca anche il riallineamento della informazione di stato, pertanto il gestore è messo costantemente in grado di conoscere lo stato effettivo del sottosistema gestito.

Le precedenti considerazioni sulla coda Q, hanno reso inoltre più semplice l'illustrazione dei moduli COD-CIR che leggono la coda e la scrivono, i cui diagrammi di flusso semplificati sono visibili in figg.8 e 9. I suddetti moduli verranno ora illustrati insieme ai rimanenti moduli che si occupano: della rilevazione di evento, del riporto di evento e del riallineamento, i cui diagrammi di flusso semplificati sono rispettivamente visibili in figg.7, 10 e 11. Tutti i moduli di programma in seguito illustrati sono interdipendenti, ovvero il processore che li ha in carico li esegue in multiprogrammazione . Questo fatto comporta una difficoltà intrinseca nella rappresentazione degli stessi. Allo scopo sono note diverse possibili modalità di rappresentazione di cui, ad esempio: una prima è una descrizione formale basata sull'utilizzo di pseudocodice, ovvero di un programma simulato; una seconda passa attraverso l'utilizzo di reti di Petri; una terza è una rapprentazione in SDL (Specification Description Language, descritta nelle Raccomandazione CCITT Z.100; ed infine una quarta è fornita per intero da diagrammi di flusso che comprendono cicli di attesa in cui vengono ripetitivamente interrogate opportune flag, attivate per richiedere un servizio e disattivate a servizio compiuto. Quest'ultima modalità sembra la più immediata per la comprensione della coordinazione esistente tra i diversi moduli, e pertanto essa è stata utilizzata nelle figure che verranno illustrate. Nella realizzazione pratica, i cicli di attesa sono realizzati diversamente da come raffigurati, perchè altrimenti essi costituirebbero un'inutile spreco di tempo reale. In pratica è il sistema operativo stesso che governa le attività del microprocessore, che coordina tutte le attività dei diversi moduli di programma e che permette la loro sincronizzazione.

Preliminare all'esecuzione dei suddetti moduli di programma è una fase di inizializzazione generale, non indicata nelle figure per motivi di semplicità, a cui di volta in volta si farà riferimento con la spiegazione delle relative operazioni.

Con riferimento alla fig.7, viene illustrato il diagramma di flusso del modulo RILEVAZIONE DI EVENTO che presenta le seguenti fasi, o passi di programma, indicate da E1 ad Eli ed elencate per quanto possibile in ordine sequenziale:

- nella fase E1 viene posto a 1 un indice i utilizzato per individuare le variabili di stato, e gli eventi;

- in E2 viene letto il valore corrente V(i) di una variabile di stato individuata dall'indice i, il valore letto è quello opportunamente filtrato dai filtri software presenti nel blocco SEMF. In gran parte dei casi, V(i) è un valore logico che significa, ad esempio, presenza o assenza di un allarme, superamento o meno di una soglia, ma non è escluso che esso possa anche essere una valore analogico digitalizzato. Il numero di variabili di stato che partecipano al riporto di evento, e che quindi potenzialmente possono generare eventi rilevabili, è indicato con imax. Ovviamente, nella fase di inizializzazione verrà allocata una tabella di corrispondenza tra i valori di i e il tipo di variabile prescelta, in tal senso l'indice i può fungere anche da indicativo di variabile, e quindi di evento;

- in E3 ed Eà il valore V(i) viene confrontato con un valore VM(i) della stessa variabile i, presente in una memoria di stato, azzerata in fase di inizializzazione;

- si giunge in E5 se in E4 risulta V(i) diverso da VM(i), il che equivale alla rilevazione di un EVENTO(i) per la variabile di stato V(i), fatta in E5; la rilevazione consiste nello scoprire che il nuovo valore di V(i) non era noto;

- nella successiva fase E6 viene eseguito un ciclo di attesa che ritarda l'aggiornamento della memoria di stato VM, e di conseguenza la scrittura nella coda Q, fino a quando una "FLAG FOTO" non risulti disattivata. Durante questo tempo, della durata di alcuni microsecondi, l'attività di rilevazione svolta dal presente modulo risulta sospesa, per consentire al modulo RICUPERO DI ALLINEAMENTO di fig.1l di eseguire una copia della memoria di stato. La durata dell'interruzione dell'attività di rilevazione è di parecchi ordini di grandezza inferiore rispetto alle altre attività considerate, come ad esempio, rispetto ai tempi di trasferimento degli eventi attraverso il modulo STACK DI PROTOCOLLO, pertanto l'attività di svuotamento della coda Q da parte dei moduli RIPORTO DI EVENTO (AGENT(m)) (fig.10) non viene minimamente perturbata, e neppure la rilevazione di nuovi eventi;

- in E7 viene scritto il valore V(i) al posto di VM(i), aggiornando la memoria di stato;

- in E8 viene attivata una "FLAG DI SCRITTURA EVENTO" il cui significato è quello di avvertire la sezione di scrittura del modulo COD-CIR di fig.8 che un nuovo evento è stato rilevato ed è disponibile per la scrittura nella coda Q; quando l'evento viene scritto in coda l'indice i.viene incrementato nella successiva fase E9 e in E10 viene confrontato con imax per la ripetizione del ciclo compreso tra le fasi E2 ed E10 relativamente ad un’altro valore V(i);

- se dal precedente confronto in E4 risulta V(i) — VM(i), nessun evento viene rilevato e il programma salta alla fase E9 per la ripetizione del ciclo;

- se in E10 i supera imax, significa che è terminato un ciclo completo di aggiornamento dell'intero stato e di rilevazione dei relativi eventi; in tal caso il programma entra nella fase Eli in cui attende fino allo scadere del tempo di campionamento dell'intero stato assegnato nella fase di inizializzazione . Per quanto riguarda la determinazione del tempo di campionamento occorre ricordare che gli eventi presi in considerazione nel riporto di evento sono quelli all'uscita dei filtri presenti nel blocco SEMF. Vengono quindi esclusi quegli eventi di brevissima durata e poco persistenti, come ad esempio i fading di Rayleigh, che necessitano tempi di intervento rapidissimi, dell'ordine di una decina di millisecondi. L'ampiezza dell'intervallo di campionamento consente di osservare un numero cospicuo di variabili di stato con la tecnica della multiplazione nel tempo (polling).

Con riferimento alla fig.8, viene illustrato il diagramma di flusso del modulo COD-CIR (SEZIONE DI SCRITTURA) che presenta le seguenti fasi, o passi di programma, indicate da CI a C9 ed elencate per quanto possibile in ordine sequenziale: - nella fase CI viene eseguito un ciclo di attesa sulla "FLAG DI SCRITTURA EVENTO", quando essa risulta attiva, in C2 viene posto a 1 l'indice m che identifica un elemento del vettore R dei puntatori di lettura e del vettore 0 di overflow, o ancora del generico lettore (AGENT);

- in C3 si verifica l'equaglianza tra il puntatore di scrittura W ed un generico puntatore di lettura R(ra), se essi risultano di uguale valore significa che c'è overflow della coda per l'AGENT (ni) e nella successiva fase C4 viene posto a vero il valore dell'elemento 0(m), altrimenti quest'ultima fase viene saltata. In fase di inizializzazione si era posto W *= 1 e R(m) = 1, per ogni m; inoltre limitatamente alla prima volta che in CI la flag risultava attiva, le fasi da C2 a C6 non venivano eseguite, per consentire al puntatore di scrittura di precedere quelli di lettura, in base a quanto era già stato detto su questo argomento parlando della coda Q;

- le fasi C5 e C6 consentono di completare il ciclo di verifica dell 'overflow per tutti gli elementi di R(m);

- nella successiva fase C7 viene eseguita la scrittura dell 'EVENTO(i) nella coda Q, alla posizione indicata dal puntatore di scrittura W;

- in C8 viene incrementato il valore di W di una unità, modulo n, dove Q è la lunghezza della coda Q;

- in C9 viene disabilitata la "FLAG DI SCRITTURA EVENTO”, ed il controllo torna alla fase CI per l'attesa di un nuovo evento da scrivere in coda.

Con riferimento alla fig.9, viene illustrato il diagramma di flusso del modulo COD-CIR (SEZIONE DI LETTURA) che presenta le seguenti fasi, o passi di programma, indicate da LI a L12 ed elencate per quanto possibile in ordine sequenziale:

- nella fase LI viene eseguito un ciclo di attesa sulla "FLAG DI LETTURA IN CODA", quando essa risulta attiva il modulo acquisisce in L2 l'identificativo m dall'AGENT(m) di fig.10 che ha richiesto di leggere;

- in L2 viene letto il valore 0(m) per verificare la condizione di overflow della coda Q per l'AGENT(m), se essa risulta verificata, nella fase LA viene inviata una informazione di presenza di overflow all'AGENT(m) che attiverà il riallineamento;

- nella successiva fase L5 il valore logico dell'elemento 0(m) del vettore di overflow viene posto a Falso, per consentire la verifica dell'overflow anche durante il riallineamento e rendere possibile la reiterazione del ciclo di riallineamento in seguito descritto;

- in L6 il valore del puntatore di lettura R(m) viene posto uguale a quello di scrittura W decrementato di una unità modulo n, il che consentirà la ripresa delle letture in coda a partire dall'evento che ha determinato l'overflow per il processo di lettura associato all'AGENT(m). In realtà non sarebbe necessario leggere il suddetto evento in quanto la variabile di stato da cui esso deriva è già stata aggiornata e il suo valore aggiornato verrà inviato al Gestore durante il riallineamento, tuttavia è necessario evitare la coincidenza tra R(m) e W, che eviterebbe questa lettura superflua, perchè altrimenti nella fase C3 di fig.8 la condizione di overflow sarebbe sempre verificata, vanificando una interrogazione su questa condizione durante il ciclo di riall ineamento;

nella successiva fase L7 la "FlAG DI LETTURA IN CODA" viene disattivata. Le fasi L5, L6 ed L7 consentono di riprendere nel modo appropriato le letture in coda per l'AGENT(m) al termine del riallineamento, che esso completerà prima di riattivare la "FIAG DI LETTURA IN CODA". Quando detta flag verrà riattivata, le letture inizieranno dall'evento che ha causato l'overflow a cui seguiranno gli eventi accodati durante il ciclo di riallineamento. Dopo la fase L7 il controllo torna alla fase LI in cui il modulo attende l'abilitazione ad una nuova lettura in coda;

ritornando alla fase L3, se in questa fase non risulta presenza di overflow per l'AGENT(m), il programma verifica in L8 la condizione di coda vuota per lo stesso AGENT, data da R(m) - W. Se la coda risulta vuota, in L9 viene inviata all'AGENT(m) un'informazione di coda vuota, il controllo passa quindi alla fase L7 in cui la "FLAG DI LETTURA IN CODA" viene disattivata, e successivamente al ciclo di attesa incluso nella fase LI. Come si può notare, se la coda risulta vuota nessuna lettura in coda viene effettuata, per consentire al puntatore di scrittura di precedere quelli di lettura, ovvero di non essere mai scavalcato, in base a quanto era già stato detto su questo argomento parlando della coda circolare Q;

- se in L8 la coda non risulta vuota, vengono eseguite ciclicamente le fasi LIO, Lll ed L12 per la lettura di tutti gli eventi in coda per l'AGENT(m), che in LIO gli vengono consegnati, il controllo torna quindi al ciclo di attesa della fase LI.

Con riferimento alla fig.10, viene illustrato il diagramma di flusso del modulo RIPORTO DI EVENTO, corrispondente ad un AGENT(m). Il modulo presenta le seguenti fasi, o passi di programma, indicate da RI a R8 ed elencate per quanto possibile in ordine sequenziale:

- nella fase RI l'AGENT(m) attiva la "FLAG DI LETTURA IN CODA" per dire al modulo COD-CIR di fig.9 di eseguire una lettura nella coda Q;

- nella fase R2 viene compiuto un ciclo di attesa per consentire al modulo COD-CIR di fig.9 di leggere in coda; - nella fase R3 l'informazione conseguente alla lettura della coda viene ricevuta ed analizzata, dando luogo a tre diverse diramazioni nel diagramma di flusso;

- una prima diramazione conduce direttamente in RI quando l'informazione ricevuta è quella di coda vuota;

- una seconda diramazione conduce in R4 quando l'informazione ricevuta è costituita dagli eventi letti in coda. In questo caso il compito dell'AGENT(m) è quello di riportare gli eventi ricevuti al proprio Gestore. Allo scopo esso consegna detti eventi al modulo STACK DI PROTOCOLLO che provvede esso stesso al trasferimento al Gestore attraverso un canale di comunicazione precedentemente predisposto. Dopodiché il controllo passa nuovamente alla fase RI, per consentire al modulo RIPORTO DI EVENTO di acquisire nuovi eventi dalla coda;

una terza ed ultima diramazione conduce in R5 quando l'informazione ricevuta in R3 è quella di overflow della coda per l'AGENT(m). Le successive fasi R6, R7 ed R8 costituiscono un ciclo di riallineamento che coinvolge il modulo RICUPERO DI ALLINEAMENTO di fig.1l. Più precisamente, in R5 viene attivata una "FLAG DI RIALLINEAMENTO" per l'abilitazione delle operazioni del modulo RICUPERO DI ALLINEAMENTO;

in R6 viene ricevuto un valore di una variabile di stato, individuata dall'indice i., dal modulo RICUPERO DI ALLINEAMENTO ;

in R7 il valore ricevuto in R6 viene consegnato al modulo STACK DI PROTOCOLLO per il suo trasferimento al Gestore; in R8 viene interrogata la "FLAG DI RIALLINEAMENTO", se essa risulta ancora attiva significa che il riallineamento non è ancora concluso, cioè non tutti i valori delle variabili di stato ricevute dal modulo RICUPERO DI ALLINEAMENTO sono state fornite al modulo STACK DI PROTOCOLLO, in tal caso il ciclo prosegue. Se è vero il contrario, il riallineamento può considerarsi terminato, ed il controllo passa nuovamente alla fase RI;

- dopo la fase R8 è conveniente inserire una ulteriore interrogazione 0(m) = Vero (non mostrata in fig.10), lungo la diramazione della risposta "no", che consente di reiterare il ciclo di riallineamento R7, R8 e R9 in caso di overflow durante lo stesso. Più precisamente, se l'esito della suddetta interrogazione è "no", il ciclo non viene interrotto; se invece la risposta è "si" vengono introdotte due fasi (anch'esse non mostrate in fig.10) identiche a quelle indicate con L5 e L6 in fig.9, dopodiché il controllo ritorna alla fase R5 per la reiterazione del ciclo di riallineamento. Questa aggiunta comporta l'inserzione di una interrogazione della "FLAG DI RIALLINEAMENTO" nel modulo RICUPERO DI ALLINEAMNETO di fig.1l ad ogni valore VMBF(i) inviato al presente modulo.

Con riferimento alla fig.11, viene illustrato il diagramma di flusso del modulo RICUPERO DI ALLINEAMNETO, attivato nella fase R6 dell'AGENT(m) di fig.10. Il modulo presenta le seguenti fasi, o passi di programma, indicate da Al ad A12, ed elencate per quanto possibile in ordine sequenziale:

- nella fase A1, il programma resta in attesa dell'attivazione della "FLAG DI RIALLINEAMENTO", all'attivazione entra in A2; - nella fase A2 viene predisposto un buffer temporaneo VMBF per ospitare una copia della memoria di stato;

- in A3 viene abilitata una "FLAG DI FOTOGRAFIA DELLO STATO", corrispondente alla "FtAG FOTO" interrogata dal modulo COD-CIR di fig.8;

- in A4 viene ricopiato il contenuto della memoria di stato entro il buffer VMBF, sospendendo l'attività di rilevazione di evento per i pochi mlcrosecondi necessari al compimento di questa operazione. Lo stato ricopiato corrisponde a quello aggiornato dal modulo RILEVAZIONE DI EVENTO fino al momento in cui è stata trovata vera, la condizione di overflow della coda per l’AGENT(m); pertanto lo stato comprende anche il nuovo valore della variabile che ha generato l'evento causante l'overflow. La scrittura del buffer VMBF viene anche detta fotografia, perchè come questa riproduce esattamente un soggetto e richiede un tempo di esecuzione molto breve;

- in A5 viene disabilitata la "FLAG DI FOTOGRAFIA DELLO STATO", poiché la copiatura della memoria di stato è terminata;

- in A6 viene posto a 1 l'indice 1 per l'inizio di un ciclo, costituito dalle fasi A7, A8, A9 e AIO, in cui opportuni valori VMBF(i) del buffer temporaneo VMBF vengono inviati al modulo RIPORTO DI EVENTO di fig.10. Più precisamente:

- in A7 ciascun valore VMBF(i) viene confrontato con un corrispondente valore DF(i), detto di default, presente in una memoria DF dei valori di default, riempita con i suddetti valori in fase di inizializzazione, oppure con valori convenzionali concordati tra AGENT e MANAGER;

- in A8 si giunge solo se nella fase A7 il valore VMBF(i) risulta diverso dal corrispondente valore di default DF(i). In questa fase il valore VMBF(i) diverso da default viene inviato al modulo RIPORTO DI EVENTO di fig.10, ciò consente di ottimizzare il riallineamento;

- nelle fasi A9 e AIO viene rispettivamente incrementato l'indice i. e confrontato con il valore massimo imax, per la ripetizione del ciclo di confronto fino ad esaurimento di tutte le variabili presenti nel buffer temporaneo VMBF, dopodiché il controllo passa alla fase All. Ricordando quanto era stato detto al termine dell'illustrazione di fig.10 circa l'utilità di inserire una interrogazione della "FLAG DI RIALLINEAMENTO" nel modulo RICUPERO DI ALLINEAMNETO, orbene questa interrogazione potrà corrispondere ad una ripetizione della fase Al dopo la fase AIO.

- in All viene disattivata la "FLAG DI RIALLINEAMENTO" in quanto l'operazione di riallineamento può considerarsi terminata ;

- in A12 il buffer temporaneo VMBF viene rilasciato ed il controllo passa nuovamente alla fase Al in cui si attende il via per un eventuale nuovo ciclo di riallineamento.

Come già era stato detto, l'invio dei soli valori delle variabili di stato diversi da quelli di default, è una modalità d'invio che consente di economizzare l’informazione di stato che occorre inviare ad un Gestore perchè questi possa ricuperare il proprio allineamento. L'economia realizzata è particolarmente vantaggiosa quando lo stato del sottosistema gestito è definito da un numero rilevante di variabili.

Un'altra modalità d'invio, che tuttavia non possiede i vantaggi della precedente, è quella di inviare tutti i valori delle variabili di stato presenti nel buffer temporaneo VMBF.

In questa fase conclusiva della descrizione occorre indagare più a fondo sui concetti di novità e di originalità che il procedimento di riallineamento oggetto della presente invenzione possiede rispetto all'arte nota; novità e originalità che, come più volte è stato affermato, consistono principalmente nel fatto che il riallineamento viene compiuto dal sottosistema gestito. Ma come giustificare la precedente affermazione per dissipare il legittimo dubbio circa l'effettiva possibilità da parte di un sottosistema gestito di riallineare il proprio Gestore? Una posizione che sembra ragionevole è quella di analizzare in dettaglio ogni fase di questo procedimento, operare quindi una distinzione tra le operazioni svolte dal sottosistema gestito e quelle svolte dal Gestore, quantificare le due attività cosi ripartite e trarre le debite conclusioni. Seguendo questa impostazione, nel procedimento in oggetto, è il sottosistema gestito che compie le seguenti azioni:

- si accorge della perdita di allineamento del proprio Gestore, - provvede a procurarsi la corretta informazione di stato al momento della perdita di allineamento,

- invia spontaneamente al Gestore la suddetta informazione di stato senza perdere memoria dei nuovi eventi che nel contempo esso stesso ha rilevato,

- riconosce che il riallineamento è concluso e riprende l'invio degli eventi a partire da quelli rilevati immediatamente dopo la perdita di allineamento.

Per quanto riguarda l'attività svolta dal Gestore concernente il proprio riallineamento, è importante evidenziare che se il riallineamento viene fatto inviando tutti i valori delle variabili di stato, piuttosto che i soli valori diversi da default, il Gestore si troverà automaticamente riallineato durante la normale gestione del riporto di evento senza la necessità di compiere alcuna particolare attività al riguardo. Si può spiegare questa affermazione ricordando che il riallineamento consiste nell'invio al Gestore dei valori delle variabili di stato, il che non differisce dall'invio di eventi, essendo gli eventi nient'altro che nuovi valori delle variabili di stato.

Se invece il riallineamento è condotto in forma ottimizzata, ovvero inviano al Gestore solo i valori diversi da default, il Gestore dovrà essere informato di questo, poiché nella copia dell'informazione di stato in proprio possesso dovrà sostituire con i valori di default i valori che non risultano aggiornati ad invio completato. Ciò comporta per il Gestore la conoscenza di quando inizia e termina il riallineamento. In questo caso, le poche informazioni necessarie al Gestore perchè esso possa completare il proprio riallineamento sono anch'esse fornite dal sottosistema gestito, ad esempio, come messaggi abbinati in testa e in coda ai valori di default che esso invia. Più precisamente, il messaggio in testa informa il Gestore che i prossimi valori che riceverà sono valori di variabili di stato diversi da default, mentre il messaggio di coda informa che la ricezione di detti valori diversi da default è terminata.

Per quanto detto, anche ottimizzando il riallineamento, si può ragionevolmente affermare che lo stesso viene sostanzialmente compiuto dal sottosistema gestito, infatti l'attività compiuta dal Gestore si riduce a ben poca cosa se confrontata con quella compiuta dal sottosistema gestito.

Si può inoltre notare come il procedimento di riallineamento venga avviato automaticamente già all'istante in cui si genera il disallineamento, e come non esistano mai periodi di inconsistenza, al di fuori del periodo durante il quale avviene il riallineamento.

Claims (22)

1. RIVENDICAZIONI 1. Procedimento di riallineamento di una copia della informazione di stato di un sottosistema gestito (SDH-ECF, SDH-MX/DX, LP(1-2), LP(l-3), LP(l-4), SDH-RIG) ricostruita da uno o più Gestori indipendenti (GESTORE, PC), con lo stato effettivo di detto sottosistema gestito, la ricostruzione essendo effettuata sulla base di uno stato iniziale e di eventi, costituiti da nuovi valori di variabili di stato, che il sottosistema gestito rileva e riporta a detti Gestori, caratterizzato dal fatto che esso viene svolto dal sottosistema gestito .
2. 2. Procedimento di riallineamento secondo la rivendicazione 1, caratterizzato dal fatto che esso viene avviato automaticamente da detto sottosistema gestito (SDH-ECF, SDH-MX/DX, LP(1-2), LP(l-3), LP(l-4), SDH-RIG) all'istante in cui si genera un disallineamento tra una rispettiva detta copia della informazione di stato in possesso di detti Gestori (GESTORE, PC) e il detto stato effettivo del sottosistema gestito.
3. 3. Procedimento di riallineamento secondo le rivendicazioni 1 o 2, caratterizzato dal fatto che esso viene svolto come nei seguenti passi: a) campionando i valori delle variabili di stato (V(I)) e confrontando i valori campionati con dei valori delle variabili di stato precedentemente campionati (VM(i)) e memorizzati in una memoria di stato, rilevando un evento (EVENTO(i)) ogni volta che i valori confrontati differiscono tra loro; b) aggiornando il contenuto di detta memoria di stato ad ogni evento rilevato, ottenendo il detto stato effettivo; c) scrivendo sequenzialmente detti eventi in una memoria di evento (Q), organizzata come una coda circolare; d) leggendo detta coda circolare sequenzialmente in modo asincrono e indipendente rispetto alla scrittura, per conto di indipendenti processi di lettura (AGENT(m)) che riportano a rispettivi detti Gestori (GESTORE, PC) gli eventi ricevuti; f) controllando, ad ogni scrittura nella coda, la presenza di una condizione di overflow della coda per per ciascuno di detti processi di lettura, la condizione essendo vera quando un evento recente viene sovrascritto ad uno remoto non ancora letto; g) aggiornando un vettore di overflow (0) i cui elementi (0(m)) contengono i valori logici delle condizioni di overflow di altrettanti detti processi di lettura (AGENT(m)) ; h) leggendo il contenuto (VMBF(i)) di detta memoria di stato per conto di detti processi di lettura che presentano overflow nella coda (Q), e ripristinando ad un valore logico Falso detti elementi (0(m)) di detto vettore di overflow (0), con ciò riallineando detta rispettiva copia della informazione di stato posseduta da detti Gestori (GESTORE, PC).
4. 4. Procedimento di riallineamento secondo la rivendicazione 3, caratterizzato dal fatto che detti elementi (Q(m)) di detto vettore di overflow (0) ripristinati ad un valore logico Falso, sono ripristinati fin dall'inizio di detto passo h), consentendo con ciò la reiterazione di detto passo h) di riallineamento anche durante l'esecuzione dello stesso.
5. 5. Procedimento di riallineamento secondo le rivendicazione 3 o 4, caratterizzato dal fatto che detto contenuto (VMBF(i)) di detta memoria di stato letto per conto di detti processi di lettura (AGENT(m)), è un sottoinsieme di valori di dette variabili di stato (VMBF(i)) che risultano diversi rispetto a dei rispettivi valori, predeterminati per tutte le variabili di stato, detti anche di di default, e già noti a detti Gestori (GESTORE, PC).
6. 6 . Procedimento di riallineamento secondo la rivendicazione 5, caratterizzato dal fatto che in testa a detti valori diversi da default (VMBF(i)), viene posto un messaggio che informa i detti Gestori (GESTORE, PC) sul fatto che i prossimi eventi che essi riceveranno da detti processi di lettura (AGENT(m)) sono valori di dette variabili di stato (VMBF(i)) diversi da default; e dal fatto che in coda ai detti valori diversi da default viene posto un messaggio di fine ricezione di detti valori diversi da default.
7. 7. Procedimento di riallineamento secondo una qualunque delle rivendicazioni precedenti, caratterizzato dal fatto che detti processi di lettura (AGENT(m)) che riportano ai detti rispettivi Gestori (GESTORE, PC) gli eventi ricevuti, affidano i suddetti eventi a dei protocolli di comunicazione (STACK DI PROTOCOLLO) che consegnano a detti Gestori gli eventi a loro volta ricevuti garantendo l'ordinamento sequenziale dei messaggi trasferiti (EVENTO(i), VMBF(i)), e garantendo inoltre la consegna di tutti i messaggi ricevuti.
8. 8. Procedimento di riallineamento secondo una qualunque delle rivendicazioni da 1 a 4, caratterizzato dal fatto che detta coda circolare (Q) viene scritta per il tramite di un puntatore di scrittura (W) che indirizza nella coda una posizione di inizio scrittura di un prossimo evento da scrivere in coda (EVENTO(i)); e dal fatto che ciascun processo di lettura (AGENT(m)) legge la coda (Q) per il tramite di un rispettivo puntatore di lettura (R(m)) che indirizza nella coda una posizione di inizio lettura di un prossimo evento da leggere in coda (EVENTO(i)); detto puntatore di scrittura (W) e i detti puntatori di lettura (R(m)) essendo incrementati di una unità modulo n dopo ogni operazioni riferita alla coda (Q) in cui essi sono coinvolti, essendo n un numero di elementi che definisce la lunghezza della coda.
9. 9. Procedimento di riallineamento secondo la rivendicazione 8, caratterizzato dal fatto che detta posizione nella coda (Q) indirizzata da detto puntatore di scrittura (W) precede sempre, o al più coincide, con detta posizione nella coda (Q) indirizzata da un detto rispettivo puntatore di lettura (R(m)).
10. 10. Procedimento di riallineamento secondo le rivendicazioni 3 e 9, caratterizzato dal fatto che una condizione di overflow è considerata vera per un processo di lettura (AGENT(m)) quando il rispettivo puntatore di lettura (R(m)) coincide con detto puntatore di scrittura (W).
11. 11. Procedimento di riallineamento secondo le rivendicazioni 3, 9 e 10, caratterizzato dal fatto che quando un elemento (0(m)) di detto vettore di overflow (0) ha un valore logico Falso, e contemporaneamente il valore di un detto puntatore di lettura (R(m)) di un processo di lettura (AGENT(m)) abbinato a detto elemento (0(m)) coincide con il valore di detto puntatore di scrittura (W) , detta coda circolare (Q) risulta vuota per quel processo di lettura.
12. 12. Procedimento di riallineamento secondo la rivendicazione 9, caratterizzato dal fatto che il vincolo di precedenza, o al più di coincidenza, di detta posizione di scrittura entro la coda circolare (Q) rispetto a detta posizione di lettura, è ottenuto imponendo una scrittura come prima operazione fatta in assoluto nella coda circolare (Q), e non effettuando alcuna lettura della coda circolare (Q) quando il valore di un puntatore di lettura (R(m)) coincide con il valore di detto puntatore di scrittura (W).
13. 13 . Procedimento di riallineamento secondo la rivendicazione 3, caratterizzato dal fatto che la lunghezza di detta coda circolare (Q) viene ottimizzata per approssimazioni successive, nel modo seguente: a) stimando una lunghezza iniziale; b) valutando un grado di riempimento medio della coda entro un lungo periodo di osservazione; c) valutando dei tassi di overflow della coda entro un periodo di osservazione prefissato; d) variando la lunghezza stimata di una quantità tale per cui il detto grado di riempimento medio e/o i detti tassi di overflow diminuiscono; e) iterando le fasi b), c) e d) fino al raggiungimento di una lunghezza ottimale tale per cui detta coda circolare (Q) si mantiene mediamente vuota nel detto lungo periodo di osservazione e i detti tassi di overflow si riducono a valori nulli, o almeno molto piccoli; f) incrementando detta lunghezza ottimale di un opportuno margine che tiene conto di cause non facilmente prevedibili, in grado di scatenare dei picchi di detti eventi scritti entro detta coda circolare (Q).
14. 14. Sistema di gestione comprendente uno o più Gestori indipendenti (GESTORE, PC) di uno stesso sottosistema gestito (SDH-ECF, SDH-MX/DX, LP(l-2), LP(l-3), LP(l-4), SDH-RIG), detti Gestori ricostruendo rispettive copie della informazione di stato di detto sottosistema gestito sulla base di uno stato iniziale e di eventi, costituiti da nuovi valori di variabili di stato, che il sottosistema gestito rileva e riporta a detti Gestori, la ricostruzione potendo risultare imperfetta e causare una perdita di allineamento di dette rispettive copie della informazione di stato in possesso di detti Gestore con lo stato effettivo del sottosistema gestito, rendendosi quindi necessario un riallineamento, caratterizzato dal fatto che il riallineamento è compiuto dal sottosistema gestito.
15. 15. Sistema di gestione secondo la rivendicazione 14, caratterizzato dal fatto che detto riallineamento viene avviato automaticamente da detto sottosistema gestito (SDH-ECF, SDH-MX/DX, LP(1-2), LP(l-3), LP(l-4), SDH-RIG) all'istante in cui si genera un disallineamento di una detta copia della informazione di stato in possesso di un detto Gestore (GESTORE, PC) con il detto stato effettivo del sottosistema gestito.
16. 16. Sistema di gestione secondo le rivendicazioni 14 o 15, caratterizzato dal fatto che esso comprende: a) mezzi di campionamento dei valori delle variabili di stato (V(i)); b) una memoria di stato in cui sono scritti detti valori campionati delle variabili di stato (V(i)), il contenuto di detta memoria corrispondendo a detto stato effettivo; c) primi mezzi di comparazione che confrontano valori di dette variabili di stato attualmente campionati con dei valori delle variabili di stato precedentemente campionati (VM(i)) e memorizzati in detta memoria di stato, rilevando un evento (EVENTO(i)) ogni volta che i valori confrontati differiscono tra loro; d) un buffer di evento (Q) lungo n in cui vengono scritti sequenzialmente detti eventi, e letti sequenzialmente in modo asincrono e indipendente rispetto alla scrittura, per conto di indipendenti processi di lettura (AGENT(m)) che riportano a rispettivi detti Gestori (GESTORE, PC) gli eventi ricevuti; f) un puntatore di scrittura (W) e tanti puntatori di lettura (R(m)) quanti sono i detti processi di lettura (AGENT(m)), detti puntatori indirizzando una rispettiva posizione di prossima scrittura o lettura entro detto buffer (Q) ed essendo incrementati unitariamente modulo n ad ogni rispettiva operazione di scrittura o di lettura in detto buffer di evento (Q) e il puntatore di scrittura (W) precedendo sempre i detti puntatori di lettura (R(m)), o al più sovrapponendosi; g) secondi mezzi di comparazione che confrontano il valore di detto puntatore di scrittura (W) con i valori di detti puntatori di lettura (R(m)), ad ogni scrittura nel buffer di evento (Q), risultati di uguaglianza nelle comparazioni corrispondendo alla verità di condizioni di overflow di detto buffer per altrettanti processi di lettura (AGENT(m)); h) un vettore di overflow (0) i cui elementi (0(m)) sono abbinati ai rispettivi processi di lettura (AGENT(m)) e vengono aggiornati con valori logici Vero o Falso di dette condizioni di overflow; inoltre caratterizzato dal fatto che detto riallineamento viene compiuto leggendo il contenuto (VMBF(i)) di detta memoria di stato per conto di detti processi di lettura (AGENT(m)) per cui è Vera una rispettiva condizione di overflow, e che detti elementi (0(m)) di detto vettore di overflow (0) sono ripristinati ad un valore logico Falso.
17. 17. Sistema di gestione secondo la rivendicazioni 16, caratterizzato dal fatto che detti elementi (0(m)) di detto vettore di overflow (0) ripristinati ad un valore logico Falso, sono ripristinati fin dall'inizio di detto riallineamento consentendo con ciò la reiterazione di detto riallineamento anche durante l'esecuzione dello stesso.
18. 18. Sistema di gestione secondo le rivendicazione 16 o 17, caratterizzato dal fatto che detto contenuto (VMBF(i)) di detta memoria di stato letto per conto di detti processi di lettura (AGENT(m)), è un sottoinsieme di valori di dette variabili di stato (VMBF(i)) che risultano diversi rispetto a dei rispettivi valori, predeterminati per tutte le variabili di stato, detti anche di di default, e già noti a detti Gestori (GESTORE, PC).
19. 19. Sistema di gestione secondo la rivendicazione 18, caratterizzato dal fatto che in testa a detti valori diversi da default (VMBF(i)), viene posto un messaggio che informa i detti Gestori (GESTORE, PC) sul fatto che i prossimi eventi che essi riceverranno da detti processi di lettura (AGENT(m)) sono valori di dette variabili di stato (VMBF(i)) diversi da default; e dal fatto che in coda ai detti valori diversi da default viene posto un messaggio di fine ricezione di detti valori diversi da default.
20. 20. Sistema di gestione secondo una qualunque delle rivendicazioni da 14 a 19, caratterizzato dal fatto che detti processi di lettura (AGENT(m)) che riportano ai detti rispettivi Gestori (GESTORE, PC) gli eventi ricevuti, affidano i suddetti eventi a dei mezzi di comunicazione (MCF) che elaborano opportuni protocolli di comunicazione (STACK DI PROTOCOLLO) , detti mezzi di comunicazione (MCF) consegnando a detti Gestori gli eventi a loro volta ricevuti, e detti protocolli garantendo l'ordinamento sequenziale dei messaggi trasferiti (EVENTO(i), VMBF(i)) e la consegna di tutti i messaggi ricevuti.
21. 21. Sistema di gestione secondo la rivendicazione 16, caratterizzato dal fatto che quando un elemento (0(m)) di detto vettore di overflow (0) ha un valore logico Falso, e contemporaneamente il valore di un detto puntatore di lettura (R(m)) di un processo di lettura (AGENT(m)) abbinato a detto elemento (0(m)) coincide con il valore di detto puntatore di scrittura (W), detto buffer di evento (Q) risulta vuoto per quel processo di lettura.
22. 22. Sistema di gestione secondo la rivendicazione 16, caratterizzato dal fatto che il vincolo di precedenza, o al più di coincidenza, di detto puntatore di scrittura (W) rispetto a detti puntatori di lettura (R(m)), è ottenuto imponendo una scrittura come prima operazione fatta in assoluto entro detto buffer di evento (Q), e non effettuando alcuna lettura di detto buffer (Q) quando il valore di un puntatore di lettura (R(m)) coincide con il valore di detto puntatore di scrittura (W).