ITTO940668A1

ITTO940668A1 - Sistema per sorvegliare ed analizzare il comportamento di un sistema di commutazione controllato da un programma memorizzato

Info

Publication number: ITTO940668A1
Application number: IT94TO000668A
Authority: IT
Inventors: Brian R Womble
Original assignee: Ericsson Telefon Ab L M
Priority date: 1993-08-17
Filing date: 1994-08-12
Publication date: 1996-02-12
Also published as: DK32895A; IT1266920B1; FI951699A0; ES2134685B1; NO951455D0; GB2286747B; CN1083666C; CA2143936A1; GB9504588D0; US5488648A; NO951455L; DE4496057T1; CN1113673A; WO1995005718A1; ES2134685A1; GB2286747A; ITTO940668A0; FI951699A

Abstract

Uno strumento di prova e di diagnostica per sistemi di commutazione per telecomunicazioni controllati da programma memorizzato cattura il verificarsi e la tempistica degli "eventi" che sono originati dalle azioni degli abbonati e dalle azioni che si verificano dentro i blocchi di software nel sistema di commutazione per telecomunicazioni. I dati relativi agli eventi catturati oltre che una indicazione della loro collocazione sono memorizzati in una grande memoria tampone. I dati memorizzati vengono poi utilizzati per analizzare gli eventi per la diagnosi e la correzione della causa del guasto oltre che per ricreare la stessa sequenza e temporizzazione degli eventi in un momento successivo al fine di effettuare la prova delle correzioni che sono state eseguite per assicurare che esse eliminano la causa della condizione di guasto.

Description

DESCRIZIONE dell’invenzione industriale dal titolo:

"SISTEMA PER SORVEGLIARE ED ANALIZZARE IL COMPORTAMENTO DI UN SISTEMA DI COMMUTAZIONE CONTROLLATO DA UN PROGRAM-MA MEMORIZZATO"

Una parte delle cose rese note di questo documento di brevetto contiene materiale che è soggetto a protezione di diritti d'autore. Il possessore dei diritti d’autore non ha alcuna obiezione alla riproduzione in facsimile da parte di chiunque del documento di brevetto o delle cose rese note del brevetto, come appare nell’ufficio marchi e brevetti, record o archivio brevetti, ma per il resto si riserva tutti i diritti d’autore.

SFONDO DELL’INVENZIONE

Campo dell'invenzione

L’invenzione è relativa a sistemi di commutazione per telecomunicazioni controllati da programma memorizzato e, più in particolare, ad uno strumento di diagnostica e progetto per tali sistemi.

Storia della tecnica relativa

Le centrali digitali di commutazione per telecomunicazioni controllate da programma memorizzato sono sistemi altamente complessi che contengono numerosi componenti fisici tutti controllati da un elaboratore che contiene molti differenti blocchi di software che interagiscono. Al fine di elaborare una chiamata telefonica dentro il sistema, è necessario che questi blocchi di software eseguano ognuno i loro compiti rispettivi di analisi e controllo in una modalità interattiva e virtualmente impeccabile. I dati vengono costantemente scambiati tra i differenti blocchi di software attraverso segnali software. Il risultato finale deve essere la elaborazione accurata e tempestiva di numerosi segnali per effettuare il controllo di vari componenti hardware ed instaurare le connessioni per la comunicazione.

Di tanto in tanto durante il funzionamento di una centrale di commutazione per telecomunicazioni, particolarmente durante il funzionamento iniziale di software nuovo oppure di miglioramento (upgrade), nel commutatore possono verificarsi vari guasti che portano ai cosiddetti elementi software o dispositivi "appesi" (hung). Tali guasti software si verificano a causa di una incapacità del software dentro uno o più dei blocchi di elaborare un particolare evento o sequenza di eventi dentro il sistema. Quando si verifica un guasto, è spesso necessario o fare ripartire il blocco software parzialmente o totalmente, oppure anche l’intero sistema, al fine di eliminare l’elemento appeso e fare ritornare il sistema ad uno stato che è riconoscibile dal software per l'elaborazione appropriata della chiamata.

Le centrali di commutazione per telecomunicazioni sono programmate per essere in grado di rispondere al verificarsi di vari "eventi" dentro il sistema come, per esempio, un abbonato che sgancia la cornetta, la composizione di cifre da parte di un abbonato, un breve impulso (flash) del gancio commutatore, oppure un abbonato che riaggancia. Il verificarsi di qualsiasi di questi, ed altri eventi possibili, risulta in un certo comportamento dentro il software del sistema di commutazione oltre che nell’assegnare e ne! togliere certi elementi fisici per effettuare il completamento di una chiamata. Quando si verifica un evento software e risulta in un dispositivo appeso oppure software appeso, è molto importante essere in grado di tracciare la sequenza di eventi che conduce gradatamente alla condizione di appeso al fine di diagnosticare ed eliminare la causa del guasto. Inoltre, dopo che sono state apportate le correzioni al software, è anche necessario essere in grado di ricreare l'ordine, la sequenza e la tempistica degli eventi specifici che hanno preceduto il guasto al fine di assicurare che le correzioni funzionino ed impedire il riverificarsi del guasto.

Ne! passato, un procedimento che è stato utilizzato per verificare il corretto funzionamento di una centrale per telecomunicazioni è di ottenere stampe di basso livello di tutte le istruzioni del programma che si sono verificate in una particolare sequenza di chiamata. Tali stampe o "tracciamenti" sono molto dettagliati e sono estremamente difficili da comprendere anche da parte di tecnici specializzati. I tracciamenti non sono una soluzione efficiente per la localizzazione e correzione dei guasti software.

Un altro procedimento per verificare il corretto funzionamento dentro un sistema di commutazione è di eseguire effettivamente la chiamata desiderata ed osservare le reazioni della centrale nel completamento della chiamata. Tuttavia, questo è principalmente una determinazione va/non-va e non fornisce all'operatore uno sguardo dettagliato della effettiva sequenza delle istruzioni dell’elaboratore eseguite dentro la centrale al fine di completare la chiamata.

Sarebbe altamente desiderabile avere un procedimento ed uno strumento mediante i quali i segnali software, i dati, l’ordine di esecuzione, la tempistica, le relazioni tra i parametri ed altre informazioni dall'interno del software del commutatore oppure altre situazioni dentro l'ambiente di telecomunicazioni possano essere selezionati e raccolti per monitorare la sequenza degli eventi che conducono gradatamente al verificarsi di una condizione di guasto, e poi utilizzati per ricostruire la stessa sequenza di eventi per effettuare la prova delle correzioni che sono state effettuate per impedire il riverificarsi del guasto. La presente invenzione fornisce un tale procedimento e sistema.

SINTESI DELL'INVENZIONE

In un aspetto, la presente invenzione include un sistema per monitorare in modo selettivo il verificarsi di certi eventi dentro il software e memorizzare quindi una indicazione di quegli eventi nella memoria. Gli eventi memorizzati sono utilizzati per controllare un generatore di traffico che ricrea gli stessi eventi ad una successiva occasione per effettuare la prova delle prestazioni del commutatore.

In un altro aspetto, la presente invenzione· è un procedimento per monitorare e registrare certe situazioni dentro un sistema di commutazione per telecomunicazioni avente blocchi funzionali di software. Il procedimento seleziona, attraverso comandi di console, i parametri associati con gii eventi che si desidera vengano monitorati. I blocchi funzionali di software dentro il sistema di commutazione per telecomunicazioni sono modificati per provvedere segnali software che riferiscono i parametri rivelati. Sono poi rivelati i parametri dentro il sistema di commutazione per telecomunicazioni che sono relativi agli eventi che causano guasti. I parametri rivelati vengono confrontati con i parametri selezionati per determinare se l’evento che causa i segnali è un evento che si desidera venga monitorato. Finalmente, i parametri rivelati vengono registrati in risposta ad una determinazione che l'evento è un evento che si desidera venga monitorato.

Il procedimento può anche includere di analizzare i parametri registrati marcando ognuno dei parametri registrati con una indicazione del tempo in cui esso si verifica, di scaricare (download) i parametri registrati dell’evento in un elaboratore avente un monitor, di ricostruire la sequenza degli eventi che conducono al verificarsi del guasto dentro il sistema di commutazione per telecomunicazioni utilizzando le indicazioni del tempo, e poi di visualizzare la sequenza degli eventi sul monitor dell'elaboratore per analizzare la sequenza.

In ancora un altro aspetto, la presente invenzione è un sistema per effettuare la prova di un sistema di commutazione per telecomunicazioni. Il sistema di esecuzione della prova include mezzi per rivelare i parametri dentro il sistema di commutazione per telecomunicazioni che sono relativi agli eventi che causano guasti ed un dispositivo di registrazione per registrare i parametri rivelati. Il sistema ha anche un generatore di segnali per generare segnali telefonici simulati che contengono i parametri registrati, e mezzi per trasmettere i segnali telefonici simulati attraverso il sistema di commutazione per telecomunicazioni al fine di effettuare la prova di quel sistema.

BREVE DESCRIZIONE DEI DISEGNI

Per una comprensione maggiormente completa della presente invenzione e per i suoi ulteriori scopi e vantaggi, si può fare ora riferimento alla seguente descrizione presa in unione con i disegni allegati, nei quali: la figura 1 è uno schema illustrativo che rappresenta l'utilizzo del sistema della presente invenzione;

la figura 2 è uno schema a blocchi che illustra certi componenti del sistema della presente invenzione;

la figura 3 è uno schema a blocchi che illustra la raccolta dei dati dentro il software del sistema di commutazione secondo la presente invenzione;

la figura 4 è uno schema a blocchi che illustra certi elementi del software dentro il sistema della presente invenzione;

la figura 5 è un diagramma di flusso che illustra certe procedure impiegate nel sistema della presente invenzione; e

la figura 6 è un diagramma di flusso che illustra le prestazioni di LOGE-VENT durante una tipica sequenza di chiamata nella forma realizzativa preferita della presente invenzione.

DESCRIZIONE DETTAGLIATA

In generale, il sistema della presente invenzione impiega la tecnica di catturare il verificarsi, e la tempistica degli "eventi" che hanno origine dalle azioni dell’abbonato e dalle azioni che si verificano dentro i blocchi di software nella centrale per telecomunicazioni. I dati relativi agli aventi catturati oltre che una indicazione della loro localizzazione sono memorizzati in una grande memoria tampone. I dati memorizzati vengono poi utilizzati per analizzare gli eventi per la diagnosi e la correzione' della causa del guasto oltre che per ricreare la stessa sequenza e tempistica degli eventi in un periodo successivo al fine di effettuare la prova delle correzioni che sono state fatte per assicurare che esse eliminano la causa della condizione di guasto.

Riferendosi prima alla figura 1 , c'è mostrato uno schema illustrativo che rappresenta una implementazione completa del sistema della presente invenzione dentro una rete di telecomunicazioni. Un primo sistema di commutazione per telecomunicazioni a programma memorizzato ("commutatore") 11 e connesso ad un secondo sistema dì commutazione 12 per mezzo di circuiti di collegamento tra centrali 13. Il commutatore 11 è soggetto ad una serie continua di eventi che possono essere o eventi esterni oppure eventi interni. Gli eventi esterni 14 possono includere quelli creati dalle azioni degli abbonati con i loro apparecchi telefonici 15 oppure altri eventi 16 basati su commutatori come chiamate da altre centrali. La centrale 11 è anche soggetta ad eventi interni che hanno origine come risultato dei segnali software che vengono scambiati tra i vari blocchi software oltre che dalla tempistica e dalla natura di quelle azioni interne del software. Il sistema della presente invenzione è accoppiato al commutatore 11 cosicché certi eventi da 17 a 19, come tutti gli eventi che si verificano dentro il commutatore e relativi ad un particolare abbonato oppure ad un particolare circuito di collegamento tra centrali, vengono diretti ad un filtro degli eventi 21 che esamina selettivamente ognuno degli eventi per determinare quali di loro sono di interesse. Il filtro degli eventi 21 è programmabile in modo selettivo dall’utente cosicché gli elementi di filtro da 22 a 24 eliminano quegli eventi che non sono di alcun interesse per analisi particolari e fanno passare quelli che sono di interesse ad una memoria 25 per la registrazione. Gli eventi registrati nella memoria 25 vengono passati in 26 ad un elaboratore personale (personal computer) 27 dentro il quale gli eventi possono anche essere memorizzati, analizzati, θ visti, per mezzo di interfacce grafiche allo scopo di diagnosticare e correggere gli errori dentro il software oppure l'hardware della centrale.

Una volta che sono state effettuate le correzioni nella forma, per esempio, di cambiamenti al software del commutatore 11 , al fine di correggere un errore software che ha prodotto un errore sotto certe condizioni, il PC 27 include la capacità di fare passare gli eventi memorizzati 28 attraverso software di scritto (script) del traffico per riassemblare quegli eventi in una forma che riassembla il traffico di chiamata. I segnali che simulano il traffico 31 vengono passati ad un generatore di traffico 32 che genera una sequenza di eventi, ed ì segnali del generatore 33 vengono accoppiati al commutatore 11 per simulare il verificarsi del traffico telefonico. Il generatore di traffico 32 rende possibile la simulazione delle chiamate telefoniche che contengono la stessa sequenza e tempistica degli eventi che sono risultati precedentemente nei guasti dentro il commutatore 11. Questo rende possibile all’operatore del sistema di controllare velocemente e semplicemente se oppure no le correzioni fatte al software/hardware hanno eliminato il possibile futuro verificarsi dello stesso guasto.

Riferendosi poi alla figura 2, c'è mostrato uno schema a blocchi di un sistema di commutazione per telecomunicazioni dentro il quale è stato incorporato il sistema di diagnostica della presente invenzione. Un sistema di commutazione per telecomunicazioni 41 può essere del tipo fabbricato dal titolare della presente domanda sotto la designazione di AXE-10, una precedente versione del quale è stata descritta in un articolo di Mat Eklund et al. intitolato "Descrizione di Sistema di AXE-10", pubblicato in Ericsson Review, No. 2, 1976, che viene qui incorporato tramite citazione. Il sistema di commutazione 41 include una memoria di immagazzinamento dei dati 42 ed un blocco di accesso alla linea 43. La memoria dei dati 42 comprende un buffer di registrazione degli eventi ed una grandé area di memoria dentro la quale il sistema può memorizzare sia le informazioni permanenti che temporanee includendo certi dati utilizzati dal sistema della presente invenzione. L'accesso alla linea 43 del sistema 41 include hardware come la circuiteria di interfaccia di linea d’abbonato (SLIC) oltre che il software per controllare quella circuiteria ed abilitare i telefoni degli abbonati ad ottenere l'accesso al commutatore 41. Installato anche dentro il sistema di commutazione per telecomunicazioni 41 c’è un blocco software 44 che viene utilizzato nella implementazione del sistema della presente invenzione come verrà ulteriormente descritto sotto. Questo blocco è citato come il blocco software "LOGEVENT" 44. Il blocco LOGEVENT 44 dentro il sistema di commutazione 41 è connesso ad un blocco LOGEVENT 45 localizzato dentro un elaboratore personale 27 per mezzo di un collegamento di comunicazione di dati 46. L'elaboratore personale 27 include anche una memoria 47 oltre che tradizionale software operativo ed altro software grafico e di interfaccia tra uomo e macchina come verrà ulteriormente descritto sotto. L’elaboratore personale 27 è collegato da una linea dati ad un tradizionale generatore di traffico 48 controllato da PC. L’elaboratore personale 27 può formulare una serie di macro istruzioni che controllano il generatore di traffico 48 per generare traffico simulato di telecomunicazioni su una pluralità di linee 49 connesse al blocco di accesso alla linea 43 del commutatore per telecomuni" cazioni 41.

Il blocco LOGEVENT 44 è incluso dentro il software del sistema di controllo del sistema di commutazione per telecomunicazioni 41. La selezione di quali abbonati devono essere monitorati per il verificarsi di eventi viene predefinita attraverso comandi di linguaggio uomo-macchina al sistema di commutazione per telecomunicazioni per mezzo di un terminale di controllo 51. Il blocco LOGEVENT 44 è programmato per mezzo dell'elaboratore personale 27 come un terminale di ingresso/uscita (I/O) per specificare gli eventi particolari, relativi alle linee d’abbonato specificate, che devono venire raccolti e memorizzati dal sistema. Una funzione di mappatura nel software di LOGEVENT 44 memorizza i criteri che identificano un evento se esso corrisponde ad un puntatore di abbonato specificato in precedenza. Gli eventi sono memorizzati in una memoria tampone dentro la memoria dei dati 42 e possono venire stampati per mezzo di un comando attraverso il terminale 51. In aggiunta alla registrazione degli eventi dentro la memoria dei dati 42, ogni evento può venire inviato mentre si verifica all'elaboratore personale 27 attraverso il collegamento dati 46. Il blocco LOGEVENT 45 dell’elaboratore personale riceve le informazioni e registra gli eventi nella memoria 47 oltre a visualizzare in modo grafico le informazioni sul monitor dell'elaboratore personale 27. L’elaboratore personale 27 può anche venire utilizzato per replicare ed analizzare la sequenza di eventi per determinare la natura di quanto si è verificato e per diagnosticare i motivi per il verificarsi dei guasti.

In aggiunta, dentro il PC può anche venire creato un archivio (file) di eventi da parte di un tecnico interagente direttamente con gli oggetti grafici. Cosi, per il generatore di traffico 48 possono venire create le istruzioni di prova con velocità ed efficienza molto maggiore su una base di uno ad uno.

Riferendosi poi alla figura 3, c’è mostrato uno schema che illustra la maniera in cui le informazioni relative agli eventi che si verificano dentro il software del sistema di commutazione sono dirette al blocco LOGEVENT 44 della presente invenzione. Il software di elaborazione dei dati 61 del sistema di commutazione per telecomunicazioni 41 include numerosi blocchi di funzioni di elaborazione delle chiamate. Questi includono una pluralità di blocchi di interfaccia di linea (LI) 62, di blocchi giuntori di chiamata (CJ) 63, di blocchi di segnalazione a registro (RE) 64, di blocchi ricevitori di codice (KR) 65 e di blocchi di gestione di traffico di interfaccia di linea (LITH) 66. In aggiunta, circuiti di collegamento bidirezionali (BT1) 67 e circuiti di collegamento bidirezionali del sistema di segnalazione no. 7 (S7BTC) 68 oltre che numerosi altri blocchi forniscono segnali software per la comunicazione tra gli uni con gli altri oltre che segnali software 69 che sono diretti in modo selettivo verso il blocco LOGEVENT 44 per la raccolta dei dati relativi al verificarsi di eventi software dentro i blocchi del software di elaborazione dei dati 61. Tradizionali "pezze" (patches) software vengono aggiunte ad ogni modulo software nei sistema per dirigere i segnali relativi agli eventi al blocco LOGEVENT 44. Siccome questi dati vengono raccolti in modo selettivo, essi vengono* trasferiti in 71 sia alla memoria dei dati 42 dentro il sistema di commutazione per telecomunicazioni, come illustrato nella figura 2, sia al PC 27 attraverso la interfaccia di comunicazione dati 46.

Riferendosi poi alla figura 4, c'è mostrato uno schema a blocchi illustrativo dei componenti che comprendono i blocchi software LOGEVENT 44 e 45 rispettivamente dentro il sistema di commutazione per telecomunicazioni 41 e l’elaboratore personale 27. Alcuni di questi blocchi funzionano fuori linea mentre altri lavorano in linea in tempo reale. Dentro il commutatore per telecomunicazioni il blocco LOGEVENT 44 include un blocco di predisposizione dei dati 72 che viene utilizzato per l’ingresso dei comandi includendo l’informare il sistema della definizione degli eventi, oltre che le selezioni di registrazione dei dispositivi e simili al fine di stabilire inizialmente i parametri che verranno utilizzati nella raccolta dei dati dall’interno del sistema di commutazione per telecomunicazioni 41. Un blocco di visualizzazione del buffer 73 è utilizzato per comandare la stampa del buffer di registrazione degli eventi dentro la memoria dei dati 42 del sistema di commutazione per telecomunicazioni 41. Un blocco di visualizzazione dei dati 74 comanda la stampa delle definizioni degli eventi e delie selezioni di registrazione e di altri dati relativi ai parametri della raccolta utilizzati dal sistema. Dentro il blocco 44 c'è anche un componente di gestione del tempo 75 che crea segnali di temporizzazione e mantiene i relativi contatori di temporizzazione che vengono utilizzati nella stampa e riproduzione degli eventi per analizzare la sequenza e la tempistica dei vari eventi e per determinare la loro rilevanza per l’analisi dei dati relativi agli eventi. E' incluso un blocco di filtraggio degli eventi 76 in cui gli eventi vengono discriminati l'uno dall’altro in base alla predisposizione dei dati, alla allocazione dinamica o agli interruttori globali dentro il sistema. E’ il blocco di filtraggio degli eventi 76 che discrimina in modo selettivo tra il grande numero di eventi che si stanno verificando dentro il commutatore e quegli eventi che sono di interesse nella particolare analisi che viene eseguita dal sistema della presente invenzione. Un blocco di registrazione degli eventi 77 salva e memorizza il tempo relativo, il numero di evento, il numero di dispositivo, il numero di dispositivo associato, e fino a venti parole di dato rispetto ad ogni particolare evento selezionato per la registrazione e filtrato dal blocco di filtraggio degli eventi 76. Localizzato sia dentro il sistema di commutazione per telecomunicazioni 41 che dentro l'elaboratore personale 27 c’è un blocco di scaricamento degli eventi 78 che viene utilizzato per catturare i contenuti del buffer di registrazione degli eventi dentro la memoria dei dati 42 e per trasferirli alla memoria 47 associata al PC 27. Dentro l'elaboratore personale 27 c’è anche un blocco di conversione degli eventi 79 che include software per la conversione basata su regole di una annotazione (log) di eventi in macro che possono venire riprodotte atraverso il sistema generatore di traffico per generare chiamate simulate nell’accesso del sistema di commutazione per telecomunicazioni. Localizzato dentro il PC 27 c’è anche un blocco di riproduzione degli eventi 81 che contiene macro generate da registrazioni di eventi precedenti che abilitano la creazione di eventi simulati.

Riferendosi alle figure da 1 a 4, il sistema della presente invenzione è implementato, in parte, per· mezzo del blocco LOGEVENT 44 localizzato dentro il sistema di commutazione per telecomunicazioni 41 , La comunicazione delle informazioni a! blocco 44 è compiuta aggiustando i blocchi di codice esistenti dentro il software 61 del sistema di commutazione per telecomunicazioni cosicché mentre si verificano gli eventi che sono di interesse, viene inviato un segnale software 69 (figura 3) al blocco LOGEVENT 44. Gli eventi possono venire aggiunti in modo dinamico al blocco LOGEVENT 44 cosicché un utente può creare gli eventi e definirli dentro il blocco per qualsiasi specifico scopo. Ognuno dei segnali software 69 contiene una etichetta di identificazione, o numero di evento, e certe informazioni predeterminate che devono essere memorizzate insieme con gli altri indizi dell'evento nel buffer di registrazione degli eventi dentro la memoria dei dati 42. In una forma realizzativa, il buffer dei dati è implementato come un "buffer circolare" che impedisce lo straripamento (overflow) dei dati poiché la memorizzazione parte di nuovo all’inizio del file di dati quando di norma una condizione di straripamento si starebbe verificando dentro la memoria. L’informazione aggiuntiva che è memorizzata con gli indizi che registrano l'evento è il numero di dispositivo o numero di identificazione dal blocco software che riferisce che invia il segnale. Utilizzando il numero di evento, il numero di dispositivo ed il numero di identificazione del blocco che riferisce, ogni evento che viene riferito al blocco LOGEVENT 44 viene vagliato per determinare se l’evento ed il dispositivo sono tra quelli messi nel "programma di lavoro" (scheduled) per la registrazione. Ossia, i segnali software inviati al blocco possono venire filtrati selettivamente in questo modo per assicurare che vengano registrati solo particolari eventi relativi a particolari dispositivi od abbonati. Il vaglio effettivo degli eventi viene compiuto, utilizzando un algoritmo di mescolamento (hashing) che marca gli indizi in una schiera o tabella di mescolamento (hash). Ogni evento che viene ricevuto viene elaborato con un tradizionale algoritmo di hashing, ed i risultati vengono poi confrontati con i dati contenuti nella tabella di hash. Solamente se il dato in ingresso viene trovato nella tabella di hash l'evento viene registrato.

Altri elementi dentro il sistema di commutazione per telecomunicazioni 41 sono allocati dinamicamente in una seconda tabella di hash. Per esempio, ogni abbonato è associato uno ad uno con un record software ed un blocco di interfaccia di linea (LI). Questa coppia può essere riferita come una "LI individuale”. Quando viene iniziata una chiamata, viene "preso" un giuntore di chiamata (CJ) individuale, tuttavia, questo dispositivo individuale non è associato uno ad uno con t’abbonato e viene in realtà selezionato da una lista di inattivi così la sua identità può essere uno qualsiasi di tutti i possibili valori per i giuntori di chiamata individuali.' Se l’utente del presente sistema desidera registrare ulteriori informazioni utilizzando i dati individuali del giuntore di chiamata, verrebbe creato un evento che riferisce la associazione dell’elemento giuntore di chiamata allocato recentemente con l’elemento di interfaccia di linea che ha originato la chiamata. In questo modo, una intera sequenza di chiamata può essere tracciata attraverso il sistema di commutazione 41. Questa tecnica limita efficacemente la quantità di informazione presentata quando una traccia di segnale viene messa su un blocco software dentro una centrale e rende possibile che quella informazione sia utilizzata in un senso pratico per analizzare il verificarsi di eventi dentro la centrale.

Con il sistema della presente invenzione, tutte le registrazioni degli eventi desiderati sono prima messe in programma (scheduled) per mezzo di un comando al blocco LOGEVENT 44 attraverso il terminale di interfaccia alla centrale 51 e solamente .quegli eventi che sono programmati in precedenza vengono posti nel buffer degli eventi dentro la memoria dei dati 42. L’abilità consiste, naturalmente, nel catturare tutti gli eventi utilizzando la interfaccia di comando dal terminale 51 per fissare i parametri dei dispositivi a "tutti" cosicché verranno registrati tutti gli eventi di un particolare tipo, ‘oppure verranno registrati dal sistema tutti gli eventi di qualunque tipo.

In una tipica sequenza di chiamata che impiega il sistema della presente invenzione, l’operatore del sistema di commutazione per telecomunicazioni inizializza le strutture dati dentro ii blocco software LOGEVENT 44 per mezzo del terminale 51. Questo comando predispone una combinazione bloccoevento-dispositivo che deve essere registrata dal sistema della presente invenzione. Quando un abbonato fa una chiamata come normale, ossia un abbonato A sgancia il telefono, questo evento viene trasmesso attraverso un segnale software al blocco software LOGEVENT 44. Il blocco LOGEVENT controlla la sua tabella di hash interna per vedere se questo evento è da registrare e, se così, è memorizzato nel buffer degli eventi nella memoria dei dati 42 per un successivo ricupero. Gli elementi memorizzati relativi ad un evento includono un numero di evento, un francobollo temporale (time stamp) e fino a venti elementi di dati che sono pertinenti all'evento.

Dopo che l'abbonato A ha sganciato, vengono composte (diai) le cifre, e per ogni cifra, viene trasmesso un evento al blocco software LOGEVENT 44 che risulta nella registrazione di ognuno dei numeri che sono stati composti insieme con il tempo relativo tra la composizione di ogni cifra indicato attraverso il time stamp. Dopo il completamento della composizione, successivi blocchi software dentro il sistema di commutazione 41 vengono identificati dai segnali che passano indietro al blocco software LOGEVENT 44 i numeri individuali dinamici come essi sono allocati. Quando la chiamata raggiunge l’abbonato chiamato (abbonato B), gli eventi di quell’abbonato, per esempio sganciato, flash, agganciato, ecc. vengono anche registrati per mezzo dei segnali software inviati dai blocchi software funzionali appropriati al blocco software LOGEVENT 44. Come ognuno dei componenti dì segnalazione a registro viene rilasciato, ossia, dopo che il percorso del parlato della chiamata è stato instaurato, non è più necessario il controllo di commutazione software, questa informazione viene anche trasmessa al blocco software LOGEVENT 44 cosicché quei componenti non verranno registrati se utilizzati in una successiva chiamata, li blocco LOGEVENT 44 rimuove le marcature dalle sue tabelle di hash interne immediatamente alla ricezione dei segnali di "rilascio''.

Quando un segnale di evento di agganciato finale viene ricevuto dall’abbonato B, il blocco LOGEVENT 44 registra questo evento e rimuove dalle tabelle di hash le marcature che causerebbero l’ulteriore registrazione degli eventi relativi all'abbonato B. L'operatore del sistema di commutazione determina se oppure no tutti gli eventi di interesse sono stati completati e ferma la registrazione ed ordina una stampa per osservare la sequenza, la tempistica, ecc. di tutti gli eventi che sono stati registrati. Se la sequenza di eventi mostrata nella stampa esibisce un comportamento anormale sulla parte del sistema di commutazione, oppure se l’operatore desidera proprio replicare la chiamata esattamente come esse si è verificata originariamente, gli eventi vengono quindi scaricati al PC 27 e convertiti in scritto di prova (test) che viene riprodotto sul dispositivo generatore di traffico 48 per risimulare il verificarsi degli stessi eventi e determinare se oppure no viene esibito lo stesso comportamento nel commutatore.

Il sistema della presente invenzione include anche la capacità di riferire ogni evento su una base di tempo reale ad una interfaccia grafica dentro l’elaboratore personale 27 cosicché mentre si verifica ogni evento, il visualizzatore viene aggiornato con lo stato più attuale di ogni abbonato in una chiamata. Tali eventi vengono visualizzati per mezzo di icone che formano parte di una interfaccia grafica di utente che convoglia efficientemente ad un osservatore le informazioni relative agli eventi che si stanno verificando dentro la centrale di commutazione per telecomunicazioni 41. Per esempio, se un abbonato solleva la cornetta da un telefono che è messo in programma per la registrazione da parte del presente sistema, la interfaccia grafica può cambiare da una icona che illustra un telefono con una cornetta in una posizione normale di agganciato ad un telefono con una cornetta sospesa sopra il telefono indicante che l’abbonato ha davvero appena sganciato. Tali icone possono venire create dall’utente utilizzando tradizionali strumenti software ben conosciuti sull'elaboratore personale 27 e verranno associate dinamicamente con gli eventi mediante l’utilizzo di un file di configurazione.

La capacità di catturare gli eventi da dentro la centrale di commutazione per telecomunicazioni 41 risulta nella abilità di replicare gli eventi che sono stati catturati e di simulare la sequenza di chiamata catturata in un modo molto accurato. L’elaboratore personale 27 traduce la annotazione (log) degli eventi catturati in istruzioni di prova automatizzate per mezzo di macro di prova che sono dirette al generatore di traffico 48 per ricreare una chiamata simulata al sistema.

I dati dentro le porzioni del blocco LOGEVENT della presente invenzione sono gestiti come esposto sotto. Un componente importante del presente sistema è il "RECORDING BUFFER FILE" che è implementato come un buffer circolare dentro la memoria dei dati 42 del sistema di commutazione per telecomunicazioni 41. Viene riprodotto e registrato come un file di dati first-in, first-out (FIFO) per assicurare affidabilità e completezza dei dati registrati in esso. La sua struttura viene esposta come segue in una forma modificata di linguaggio di programmazione per linguaggio di centrali (PLEX):

RECORD REPORTBUFFER;

VARIABLE INFOR (32) 16 DS;

END RECORD;

POINTER RPOINTER(REPORTBUFFER);

Un altro file che è utilizzato ogni volta che l'evento viene registrato e riprodoto è il file della lista di eventi. I dati contenuti in questo file sono fissati dal comando ed una descrizione e funzione per ogni variabile è esposta sotto:

Ognuna delle variabili nel precedente file è definita come segue:

EVENTBREF - Event Block Reference. Questo è il numero di riferimento del blocco relativo al blocco dal quale è originato l’evento che viene registrato. Il numero di riferimento del blocco è il numero relativo allo smistamento del software di commutazione per telecomunicazioni.

ALLFLAG - Questo indicatore viene controllato quando la registrazione è attiva, ma non è partita. Se si verifica questo evento, e ALLFLAG è posto a VERO, questo evento viene registrato.

ASSOCIATEDEVENT - Questa viene fissata in modo opzionale ad un evento che verrà "annotato" nella tabella di hash se questo evento viene ricevuto. Questo fornisce lo strumento e l’abilità di aggiungere dinamicamente nuove coppie evento-dispositivo alla tabella di hash di registrazione.

STARTTRIG - Questo indicatore viene controllato quando la registrazione è attiva, ma non è partita. Se questo evento si verifica, STARTTRIG è posto a VERO, viene fatta partire la registrazione regolare.

STOPTRIG - Questo indicatore viene controllato quando la registrazione è attiva ed è partita. Se si verifica questo evento, e STOPTRIG. è posto a VERO, tutta la registrazione viene fermata.

TOTALDATA - Utilizzato per registrazione e stampa, dice quanti dati sono utilizzati dal segnale di evento entrante, oppure quanti dati sono memorizzati nel buffer di registrazione degli eventi.

BLOCKNAME - Il nome del blocco software che viene registrato.

STRINGOUT - Stringa descrittiva utilizzata per la stampa dell'evento registrato.

Il sistema della presente invenzione include come parte del blocco LOGEVENT dentro il PC, uno strumento basato su PC che utilizza stampe, consistenti di eventi, dal blocco LOGEVENT nel sistema di commutazione per creare la Istruzione di Prova (TI) AUTOS1S eseguibile. Gli eventi sono convertiti in macro o primitive PCSLI. La TI viene eseguita da AUTOSIS per riprodurre gli eventi registrati dal blocco LOGEVENT.

Questo strumento è implementato cosicché l'ingresso al programma è una Specifica di Prova (TS) ed un insieme di file di annotazione FIOL II programma richiede anche un file di REGOLE, ed un file contenente macro PCSLI. File di ingresso e di uscita sono specificati o in un sistema a menu oppure alla linea di comando DOS. Una caratteristica della specifica di prova è che ogni prova è identificata con una etichetta (label) "LOGEVENT1. La sintassi della etichetta LOGEVENT è come segue:

Tutti i dati pertinenti al programma (case) di prova devono avere una etichetta LOGEVENT affinché il programma la trovi durante la creazione della istruzione di prova. La etichetta deve essere unica nella specifica di prova, e deve essere posizionata nella linea immediatamente successiva che segue fa intestazione. La specifica di prova viene verificata grammaticalmente dopo che sono stati verificati grammaticalmente tutti i file di annotazione FIOL, o annotazioni degli eventi. I file di annotazione degli eventi contengono le stampe degli eventi. Gli eventi vengono iniziati, per esempio, con il comando "ELLLI ID=x;\ I comandi del sistema di commutazione inviati tra il comando "ELLLI" ed il comando "ELLLP" sono semplicemente copiati al file di uscita, ossia all'istruzione di prova.

END

Gli eventi sono poi convertiti in primitive PCSLI oppure macro secondo le regole nel File di Regole. I file di annotazione vengono verificati grammaticalmente prima che sia verificata grammaticalmente la specifica di prova. Ogni caso di prova convertito viene posto in un file temporaneo, che viene utilizzato più tardi quando viene verificata grammaticalmente la specifica di prova.

I file di configurazione vengono utilizzati per predisporre il programma di LOGEVENT per adattarsi alle necessità dell'utente. Preferibilmente, esso è ripartito in 3 sezioni, la sezione di abbonato, la sezione di eventi-regole e la sezione di macro PCSLI. Queste sezioni sono descritte in ulteriore dettaglio sotto. Le sezioni sono consentite in qualsiasi ordine. Il file di configurazione. consiste di parole chiave, per esempio SUB, e stringhe, per esempio "Ll-1, e commenti. I commenti iniziano con un punto esclamativo e terminano alla fine della linea.

Questa sezione di abbonato descrive tutti gli abbonati conosciuti dal programma LOGEVENT. Il massimo numero di abbonati è 8. Ogni abbonato ha quattro attributi. Questi sono:

IND Individuale, dispositivo (per esempio, "LI-1")

SUB Identità dell’abbonato (da "A" fino ad Ή")

SNB Numero di telefono dell’abbonato (per esempio, "2149970000")

CIN Individuo di Controllo (PCSLI)

Un abbonato deve avere tutti i quattro attributi specificati (IND, SUB, SNB e CIN) e non c’è alcun valore di default. Un attributo mancante darà come risultato un errore durante la verifica grammaticale del file di configurazione. Ogni abbonato in questa sezione parte con la parola chiave SUBSCRIBER (ABBONATO) e termina con ENDSUBSCRIBER (FINEABBONATO), come esposto sotto nella TABELLA II.

Tutti gli attributi (NO, TITLE, ICONFILE, DURATION, DATA, RULE e DESCR) devono essere specificati. Se un evento non produce alcun dato, specificare DATA "0". Se un evento non necessita una descrizione allora specificare DESCR Ogni evento in questa sezione di eventi-regole inizia con la parola chiave EVENT e termina con ENDEVENT.

La quantità degli eventi è assunta essere abbastanza piccola (<100), perciò il file di regole viene letto una volta, e viene tenuto in memoria durante la esecuzione del programma.

La sezione di macro PCSLI del file di configurazione contiene le macro PCSLI da utilizzare con la istruzione di prova creata. Queste macro sono posizionate in una procedura chiamata "macro" ed è chiamata dal settore di preparazione globale nella istruzione di prova. Utilizzando le macro, è possibile rendere le regole, come illustrato nella TABELLA III, più corte e più leggibili.

La sezione di macro PCSLI inizia con la parola chiave PCSLI e termina con ENDPCSLI. Questa sezione , non ha alcuna parola chiave. Tutte le stringhe tra PCSLI ed ENDPCSLI sono semplicemente copiate alla istruzione di prova come mostrato nella TABELLA IV. Si veda l’esempio sotto.

Una istruzione di prova AUTOSIS è creata come il file di uscita come segue. I file di annotazione (annotazioni degli eventi) vengono prima verificati grammaticalmente e vengono creati file temporanei per ogni case di prova, Viene quindi verificata grammaticalmente la specifica di prova. La maggior parte delle linee sono proprio copiate al file di uscita (la istruzione di prova). Certe tag EDML sono cambiate, per esempio "docno". Quando viene incontrata una etichetta LGEVENT, la descrizione del case di prova viene prima copiata nella istruzione di prova, e quindi il suo file temporaneo associato contenente le istruzioni PCSLI (creato quando i file di annotazione sono stati verificati grammaticalmente) viene apposto dopo la descrizione del case di prova. Se una etichetta LGEVENT non ha un corrispondente case di prova nei file di annotazione, viene asserito un messaggio di errore. Questo programma tenta anche di riprodurre la corretta tempistica degli eventi leggendo la colonna TIMER nel rapporto di annotazione degli eventi illustrato nella TABELLA I, ed asserisce delle PAUSE prima di ogni macro PCSLI. Tuttavia, è impossibile ricostruire la esatta tempistica poiché non è conosciuto l’esatto tempo di esecuzione delle istruzioni AUTOSIS e PCSLI. Perciò possono essere tenute in conto solamente differenze di tempistica maggiori di un valore appropriato, per esempio 500 ms. Tutti i case di prova creati sono case di prova automatici (TCAUTO).

Questa porzione del programma LOGEVENT è invocata dal prompt DOS. Se non viene fornito alcun parametro, un sistema a menu fornirà un prompt all’utente per l’ingresso al programma. Gli interruttori dei parametri della linea di comando possono apparire dovunque sulla linea di comandò fintantoché essi sono separati da spazi. Gli interruttori consistono di un trattino, una lettera ed un segno più oppure meno per accendere· oppure spegnere l’interruttore (alcuni interruttori sono seguiti da una stringa invece del segno più oppure meno) e gran parte degli interruttori hanno una predisposizione di default. E’ solamente necessario fornire un interruttore se la predisposizione di default non è soddisfacente. Esempi vengono esposti sotto:

-Ipath Specìfica il percorso ed il nome del file per la istruzione di prova creata. Se l'interruttore viene omesso, la istruzione di prova prenderà lo stesso nome di file della specifica di prova e la estensione ".ΤΓ, come segue:

-le: sus500.ti

-Spath Specifica il percorso ed il nome del file della specifica di prova da utilizzare, per esempio:

-Se: sus500.ts

in modalità batch non è necessaria alcuna attenzione alla tastiera. Questo interruttore richiede che gli interruttori I, S e L siano forniti al fine di saltare il menu di dati di ingresso. Se uno qualsiasi di quegli interruttori è mancante, viene visualizzato il menu di ingresso, ma viene soppresso ogni altro intervento della tastiera.

Un sistema a menu fornirà all'utente un prompt per i file di ingresso (se essi non fossero stati tutti specificati come parametri dalla linea di comando), e visualizzarà quindi alcune finestre che informano l’utente dei progresso della conversione.

Riferendosi poi alla figura 5, c’è mostrato un diagramma di flusso per il condizionamento iniziale ed utilizza del sistema in un aspetto della presente invenzione. Primo, il sistema inizia in 101 e si muove a 102 nel quale momento l'operatore del sistema identifica la azione dell'abbonato o gli eventi da registrare, ossia viene fatto un piano per l'utilizzo del sistema. In 103, l'operatore inserisce in ingresso qualsiasi evento nel blocco software attraverso i -comandi se quegli eventi non esistono già. In 104, vengono preparate le "pezze" software che sono caricate nei blocchi software del sistema di commutazione per telecomunicazioni e sono utilizzate per riferire i particolari eventi inviando un segnale al blocco LOGEVENT al verificarsi di qualunque degli eventi preselezionati dentro i blocchi software del sistema. In 105, vengono marcati specifici dispositivi per la registrazione attraverso il comando. La registrazione viene cominciata per mezzo, di un particolare comando, per esempio ELLi. In 106, il sistema di commutazione per telecomunicazioni viene fatto funzionare o per la ricezione delle effettive chiamate o per l’utilizzo di un generatore di traffico telefonico e gli eventi sono forzati ad avvenire dentro il commutatore. In 107, dopo il completamento della prova desiderata, la registrazione viene fermata per mezzo di un comando come ELLE. Successivamente, in 108, viene determinato se oppure no la registrazione è da utilizzare per creare uno scritto di riproduzione e se così, il sistema si muove in 109 in cui viene inizializzato il programma di cattura sul PC e gli eventi registrati vengono scaricati nel PC in 110. Poi, in 111 , viene eseguito un programma di conversione per convertire gli eventi registrati allo scritto di riproduzione e, in 112, il sistema finisce. Se, in 108, non si è desiderato creare uno scritto di riproduzione, il sistema si muove a 113 dove gli eventi registrati vengono fatti vedere per mezzo di un particolare comando, come ELLT e, in 114, viene effettuata una analisi sugli eventi registrati. Il sistema si ferma in 112.

il diagramma di flusso delia figura 6 viene fornito come una illustrazione delle prestazioni di LOGEVENT durante una tipica sequenza di chiamata. Lì si può vedere in 121 che l'operatore del sistema di commutazione inizializza. le strutture dati dentro il blocco software LOGEVENT dando un comando che predispone le combinazioni blocco-evento-dispositivo da registrare. In 122 l’abbonato effettua una chiamata come di norma, ossia l'abbonato A sgancia il telefono. Questo evento viene trasmesso attraverso un segnale software al blocco software di LOGEVENT, e LOGEVENT controlla la sua tabella di hash interna per vedere se questo evento è da registrare. Se così, esso viene memorizzato nel buffer di eventi e salvato per un successivo ricupero. Gli elementi di dati memorizzati includono un numero di evento, un time stamp e fino a 20 dati che sono pertinenti all’evento. Poi, mentre l’abbonato A compone le cifre in 123, per ogni cifra premuta, viene trasmesso un evento al blocco software di LOGEVENT. L'informazione viene registrata per quanto riguarda esattamente quali numeri sono stati composti, ed oltre al tempo relativo tra la composizione di ogni cifra attraverso il time stamp.

Dopo il completamento della composizione del numero, i successivi blocchi software coinvolti nella chiamata sono identificati dai segnali che passano indietro a LOGEVENT i numeri individuali dinamici come essi sono allocati. Quando la chiamata raggiunge l’abbonato B in 124, gli eventi di quell’abbonato, ossia sganciato, flash, agganciato, ecc. vengono anche registrati in 125. Siccome ognuno dei componenti di segnalazione a registro della chiamata è rilasciato in 126, ossia il percorso del parlato della chiamata è instaurato ed il controllo di commutazione software non è più necessario, questa informazione viene anche trasmessa a LOGEVENT cosicché quei compqnenti non verranno registrati se utilizzati in una successiva chiamata. LOGEVENT rimuove le marcature dalle sue tabelle di hash interne immediatamente alla ricezione dei segnali di "rilascio". Quando viene ricevuto il segnale finale di agganciato dall'abbonato B, LOGEVENT registra l'evento Θ rimuove dalle tabelle di hash le marcature che farebbero sì che B venga registrato ulteriormente. Una volta che l'operatore del sistema ha determinato che gli eventi di interesse sono completi; la registrazione viene fermata in 127 e viene ordinata una stampa per osservare in 128 la sequenza, tempistica, ecc. degli eventi. Se la sequenza stampata mostra un comportamento anormale sulla parte del sistema di commutazione, oppure se l’operatore desidera replicare la chiamata in modo esatto come essa si è verificata originalmente, gli eventi vengono scaricati in un PC e convertiti in uno scritto di prova che viene riprodotto su un generatore di traffico come descritto sopra.

Come si può vedere, il sistema della presente invenzione abilita il filtraggio selettivo e la registrazione degli eventi che si verificano dentro it commutatore per telecomunicazioni cosicché quegli eventi, includendo la loro sequenza e temporizzazione, possono essere prontamente analizzati da un operatore. Se gli eventi memorizzati hanno condotto in modo caratteristico al verificarsi di un guasto dentro il commutatore, l’analisi degli eventi registrati può essere molto costruttiva nello scrivere le modifiche del software necessarie per impedire il verificarsi di tali guasti nel futuro. Una volta che sono state fatte le correzioni al software/hardware per evitare in modo promettente il riverificarsi di un guasto in risposta a certi eventi, gli eventi registrati possono essere replicati attraverso un generatore di chiamata per simulare il verificarsi della stessa sequenza e tempistica degli eventi che erano precedentemente risultati nel guasto per determinare se oppure no le correzioni al software hanno avuto l’effetto di rimedio desiderato.

Si crede che il funzionamento e la costruzione della presente invenzione sarà evidente dalla precedente descrizione e, mentre il procedimento e l’apparecchiatura mostrati e descritti sono stati caratterizzati come essere preferiti, ovvi cambiamenti e modifiche possono esservi fatti senza allontanarsi dallo spirito e dallo scopo dell’invenzione come definito nelle seguenti rivendicazioni.

Claims

RIVENDICAZIONI 1. Procedimento per monitorare e registrare certe situazioni dentro un sistema di commutazione per telecomunicazioni avente blocchi funzionali di software, detto procedimento comprendente le fasi di: definire parametri selezionati associati con gli eventi che si desidera vengano monitorati; rivelare i parametri dentro detto software funzionale di detto sistema di commutazione per telecomunicazioni relativi a detti certi eventi; provvedere segnali software che riferiscono detti parametri rivelati; confrontare detti parametri rivelati riferiti da detti segnali software con detti parametri definiti per determinare se l’evento associato con i segnali è un evento che si desidera venga monitorato; e registrare detti parametri rivelati in risposta ad una determinazione che l’evento è un evento che si desidera venga monitorato.
2. Procedimento come esposto nella rivendicazione 1 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare abbonato.
3. Procedimento come esposto nella rivendicazione 1 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare componente dentro detto sistema di commutazione per telecomunicazioni.
4. Procedimento come esposto nella rivendicazione 1 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare tipo di evento di interesse.
5. Procedimento come esposto nella rivendicazione 1 inoltre comprendente la fase di analizzare detti parametri registrati, detta fase di analisi comprendendo: di marcare ognuno di detti parametri registrati con una indicazione del tempo del verificarsi dell’evento con cui essi sono associati; di scaricare (download) detti parametri di evento registrati in un elaboratore avente un monitor; e di visualizzare detta sequenza di eventi su detto monitor di detto elaboratore per analizzare detta sequenza.
6. Procedimento come esposto nella rivendicazione 5 in cui detta fase di analisi inoltre comprende: di ricostruire dentro detto sistema di commutazione per telecomunicazioni la sequenza degli eventi per quanto riguarda quali detti parametri rivelati sono stati registrati rigenerando detti parametri rivelati in detti blocchi software funzionali utilizzanti dette indicazioni di tempo.
7. Procedimento come esposto nella rivendicazione 5 inoltre comprendente le fasi di: definire in detto elaboratore intervalli di valori per ognuno di detti parametri registrati, detti intervalli di valori essendo associati con operazioni normali di detto sistema di commutazione per telecomunicazioni; e visualizzare detti intervalli di valori normali su detto monitor di detto elaboratore insieme con detti parametri misurati.
8. Procedimento per effettuare la prova di un sistema di commutazione per telecomunicazioni comprendente le fasi di: rivelare i parametri dentro detto sistema di commutazione per telecomunicazioni relativi ad eventi associati a guasti; registrare detti parametri rivelati; generare segnali telefonici simulati contenenti detti parametri registrati; e trasmettere detti segnali telefonici simulati attraverso detto sistema di commutazione per telecomunicazioni per effettuare la prova di detto sistema.
9. Procedimento per effettuare la prova di un sistema di commutazione per telecomunicazioni come esposto nella rivendicazione 8 in cui detta fase di rivelazione inoltre comprende: di definire per ogni evento i parametri selezionati che sono da registrare, detti parametri includendo l’abbonato associato con l’evento.
10. Procedimento per effettuare la prova di un sistema di commutazione per telecomunicazioni come esposto nella rivendicazione 9 in cui detta fase di rivelazione inoltre comprende: di definire abbonati selezionati per quanto riguarda quali eventi devono essere associati affinché i parametri relativi agli eventi vengano registrati; e di filtrare detti eventi prima di registrare confrontando l'abbonato identificato entro i parametri relativi ad ogni evento e di registrare solamente detti parametri se l'abbonato identificato è tra gli abbonati selezionati definiti.
11. Procedimento per analizzare le prestazioni dentro un commutatore per telecomunicazioni avente blocchi di software, detto procedimento comprendente le fasi di: selezionare una pluralità di eventi di abbonato che possono verificarsi dentro i blocchi software di detto commutatore per telecomunicazioni da rivelare; modificare i blocchi software dentro detto commutatore per telecomunicazioni per riferire i parametri specificati associati con detti eventi selezionati da rivelare; selezionare specifici dispositivi dentro detto commutatore per telecomunicazioni per quanto riguarda quali della pluralità selezionata dì eventi di abbonato sono di interesse; elaborare le chiamate attraverso il commutatore per telecomunicazioni, in tal modo facendo sì che si verifichino gli eventi di abbonato; e registrare i parametri riferiti per gli eventi di abbonato selezionati associati con gli specifici dispositivi selezionati.
12. Procedimento come esposto nella rivendicazione 11 inoltre comprendente le fasi di; selezionare specifici abbonati dentro deto commutatore per telecomunicazioni per quanto riguarda quali della pluralità selezionata dì eventi di abbonato sono di interesse; filtrare i parametri riferiti per gli eventi di abbonato selezionati associati con gli specifici dispositivi selezionati e registrare solamente detti parametri che sono relativi a detti specifici abbonati selezionati.
13. Procedimento come esposto nella rivendicazione 11 inoltre comprendente le fasi di; scaricare in un elaboratore detti parametri registrati associati a detti eventi di abbonato; convertire dentro detto elaboratore i parametri registrati associati con detti eventi in uno scritto di riproduzione; e generare chiamate simulate con un generatore di chiamata da deto scritto di riproduzione; e dirigere dette chiamate simulate attraverso detto commutatore per telecomunicazioni per effettuare la prova del verificarsi di guasti dentro i suoi blocchi software.
14. Sistema per monitorare e registrare certe situazioni dentro un sistema di commutazione per telecomunicazioni avente blocchi funzionali di software, detto sistema comprendendo: mezzi per definire parametri selezionati associati con eventi che si desidera vengano monitorati; mezzi per rivelare i parametri dentro detto software funzionale di detto sistema di commutazione per telecomunicazioni relativi a detti certi eventi; mezzi per provvedere segnali software che riferiscono detti parametri rivelati; mezzi per confrontare detti parametri rivelati riferiti da detti segnali software con detti parametri definiti per determinare se l’evento associato con i segnali è un evento che si desidera venga monitorato; e mezzi per registrare detti parametri rivelati in risposta ad una determinazione che l'evento è un evento che si desidera venga monitorato.
15. Sistema esposto nella rivendicazione 14 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare abbonato.
16. Sistema esposto nella rivendicazione 14 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare componente dentro detto sistema di commutazione per telecomunicazioni.
17. Sistema esposto nella rivendicazione 14 in cui almeno alcuni dei parametri selezionati definiti sono relativi ad un particolare tipo di evento di interesse.
18. Sistema esposto nella rivendicazione 14 inoltre comprendente: mezzi per analizzare detti parametri registrati, detti mezzi di analisi includendo mezzi per marcare ognuno di detti parametri registrati con una indicazione del tempo del verificarsi dell’evento con cui essi sono associati; mezzi per scaricare (download) detti parametri di evento registrati in un elaboratore avente un monitor; e mezzi per visualizzare detta sequenza di eventi su detto monitor di detto elaboratore per analizzare detta sequenza.
19. Sistema esposto nella rivendicazione 18 in cui detti mezzi di analisi inoltre comprendono: mezzi per ricostruire dentro detto sistema di commutazione per telecomunicazióni la sequenza degli eventi per quanto riguarda quali detti parametri rivelati sono stati registrati includendo mezzi per rigenerare detti parametri rivelati in detti blocchi software funzionali utilizzanti dette indicazioni di tempo.
20. Sistema esposto nella rivendicazione 18 inoltre comprendente: mezzi per definire in detto elaboratore intervalli di valori per ognuno di detti parametri registrati, detti intervalli di valori essendo associati con operazioni normali di detto sistema di commutazione per telecomunicazioni; e mezzi per visualizzare detti intervalli di valori normali su detto monitor di detto elaboratore insieme con detti parametri misurati.
21. Sistema per effettuare la prova di un sistema di commutazione per telecomunicazioni comprendente: mezzi per rivelare i parametri dentro detto sistema di commutazione per telecomunicazioni relativi ad eventi associati a guasti; mezzi per registrare detti parametri rivelati; mezzi per generare segnali telefonici simulati contenenti detti parametri registrati; e mezzi per trasmettere detti segnali telefonici simulati attraverso detto sistema di commutazione per telecomunicazioni per effettuare la prova di detto sistema.
22. Sistema per effettuare la prova di un sistema di commutazione per telecomunicazioni come esposto nella rivendicazione 21 in cui detti mezzi di rivelazione inoltre comprendono: mezzi per definire per ogni evento i parametri selezionati che sono da registrare, detti parametri includendo l'abbonato associato con l’evento.
23. Sistema per effettuare la prova di un sistema di commutazione per telecomunicazioni come esposto nella rivendicazione 22 in cui detti mezzi di rivelazione inoltre comprendono: mezzi per definire abbonati selezionati per quanto riguarda quali eventi devono essere associati affinché i parametri relativi agli eventi vengano registrati; e mezzi per filtrare detti eventi prima di registrare includendo mezzi per confrontare l’abbonato identificato entro i parametri relativi ad ogni evento e di registrare solamente detti parametri se l'abbonato identificato è tra gli abbonati selezionati definiti.
24. Sistema per analizzare le prestazioni dentro un commutatore per telecomunicazioni avente blocchi di software, detto sistema comprendente: mezzi per selezionare una pluralità di eventi di abbonato che possono verificarsi dentro i blocchi software di detto commutatore per telecomunicamezzi per generare chiamate simulate con un generatore di chiamata da detto scritto di riproduzione; e mezzi per dirigere dette chiamate simulate attraverso detto commutatore per telecomunicazioni per effettuare la prova del verificarsi di guasti dentro i suoi blocchi software.