Multi-purpose Local Manager Interface Control Document MLM ICD

Transcript

1 Multi-purpose Local Manager Interface Control Document MLM ICD

2 INDICE DEGLI ARGOMENTI 1 SCOPO IDENTIFICAZIONE INTRODUZIONE DESCRIZIONE DEL DOCUMENTO LISTA DEGLI ACRONIMI DEFINIZIONE DELLE INTERFACCE INIZIALIZZAZIONE DATA BASE INTERFACCIAMENTO TRAMITE DATA BASE CONDIVISO UpdateStatus UpdateTime ReadOrder UpdateOrder GetNumberOfSupervisorStatus INTERFACCIAMENTO TRAMITE PROTOCOLLO SNMP Requisiti di interfacciamento... 21

3 1 SCOPO 1.1 IDENTIFICAZIONE Questo documento definisce la progettazione di dettaglio riguardante la realizzazione delle interfacce del CSCI MLM relativo al Software Applicativo del Sottosistema STN Proxy, sviluppato nell ambito del Sistema di Telegestione Nazionale (STN). 1.2 INTRODUZIONE Il Sistema di Telegestione Nazionale (in seguito STN), nel cui ambito rientra la realizzazione del CSCI Multi-purpose Local Manager (MLM), consiste in un sistema gerarchico per il controllo remoto, attivo e passivo degli Apparati di assistenza al volo. Scopo di STN è in primo luogo quello di ridurre i costi di conduzione tecnica, di aumentare l affidabilità e la disponibilità del servizio erogato, di omogeneizzare i sistemi di telegestione attualmente in uso, armonizzare le interfacce uomomacchina in un unico applicativo da cui gli operatori, debitamente addestrati, possano eseguire le procedure di conduzione ordinaria e le procedure d emergenza a fronte di problemi di malfunzionamento rilevati dal sistema. In secondo luogo, l infrastruttura creata da STN mette a disposizione a livello centrale una base dati storica delle prestazioni dei servizi erogati dai vari sistemi/apparati, nonché uno strumento di monitoraggio in tempo reale dei trend prestazionali. Attraverso STN sarà quindi possibile ottimizzare i servizi di manutenzione e di logistica. STN realizza quanto detto interfacciandosi direttamente ai sistemi presenti in sito, estendendo le capacità di monitoraggio e di controllo (almeno per le funzioni primarie di conduzione tecnica dei sistemi) presso i centri di controllo territoriali, secondo una architettura piramidale al cui vertice è presente il Centro Nazionale di Supervisione e Controllo presso la sede Centrale dell Enav S.p.A presente in Roma. In questo sito convergono tutte le informazioni provenienti dai vari Centri di Supervisione e Controllo presenti sul territorio nazionale. Ogni Centro di Supervisione e Controllo si occupa del monitoraggio dei siti ENAV di sua competenza. In ciascun sito dell ENAV sarà presente per ciascun apparato gestito, o per un insieme di essi, un sottosistema definito nodo Proxy, che ha il compito di interfacciarsi alle apparecchiature e ai sistemi presenti nel sito e di monitorarne il funzionamento.

4 Ciascun Proxy comunica le informazioni raccolte, opportunamente rielaborate, al Server del Centro di Supervisione e Controllo di competenza. Figure 1 - Architettura STN Per tale comunicazione, Techno Sky ha sviluppato un CSCI denominato Multi-purpose Local Manager (MLM), che espleta la funzione di proxy tra i sistemi di telegestione locale (STL) ed il sistema di monitoraggio. Il CSCI MLM residente sul nodo Proxy si interfaccia quindi con: i sistemi da monitorare e controllare (rappresentati in Figura:1 dai sottosistemi all ultimo livello) il sistema di monitoraggio per garantire l interfacciabilità ed interoperabilità con la rete STN. Il CSCI MLM ha il compito di inviare al sistema di monitoraggio i dati riguardanti lo stato e la diagnostica generati dal gestore locale oggetto del monitoraggio, inoltre invia gli ordini provenienti dalle workstation STN e ne riceve le relative risposte.

5 1.3 DESCRIZIONE DEL DOCUMENTO Questo documento definisce i requisiti di interfaccia per il CSCI MLM, sviluppato nell ambito del Sistema di Telegestione Nazionale (STN). La struttura del presente documento è la seguente: Capitolo 1: Scopo E il capitolo in corso ed identifica lo scopo ed il contenuto del documento. Capitolo 2: Definizione delle Interfacce Descrive le modalità di interfacciamento supportate dal CSCI MLM verso i Sistemi di Telegestione Locale. Il contenuto di questo documento potrà essere rivisitato ad intervalli regolari al verificarsi di uno dei seguenti eventi: Variazione dei requisiti di progetto. Modifiche dovute alle fasi di integrazione e test.

6 1.4 LISTA DEGLI ACRONIMI Sigla ANSP ATC ATM BIOS CI CM CSCI ENAV FAT FDP FTS GUI HR HW ICAO ICD IEEE ISO LAN MIB MLM NTP OS PMP PRX SAT SCM SDD SIMEC SNMP SoW SRS SSDD SSS STL Descrizione Air Navigation Service Provider Air Traffic Control Air Traffic Management Basic Input-Output System Configuration Item Configuration Management Computer Software Configuration Item Ente Nazionale Assistenza al Volo Factory Acceptance Test Flight Data Processing Functional and Technical Specification Graphical User Interface Hardware Requirements Hardware International Civil Aviation Organization Interface Control Document Institute of Electrical and Electronics Engineers International Standard Organization Local Area Network Management Information Base Multi-purpose Local Manager Network Time Protocol Operating System Project Management Plan Proxy Site Acceptance Test Software Configuration Management Software Design Description Sistema Monitoraggio e Controllo Simple Network Management Protocol Statement of Work Software Requirements Specification System/Segment Design Document System/Segment Specification Sistema di Telegestione Locale

7 STN STP STR SVN SVTD SW TCP/IP TMT UTC WP Sistema di Telegestione Nazionale Software Test Plan Software Test Report Subversion System Validation Test Description Software Transmission Control Protocol / Internet Protocol Test Management Tool Universal Time Constant Work Package

8 2 DEFINIZIONE DELLE INTERFACCE In questo paragrafo sono individuati, classificati e definiti i sistemi con cui il CSCI MLM si interfaccia. Nella seguente figura è illustrato il posizionamento architetturale del CSCI MLM all interno dell architettura STN. interfaccia Figure 2 - Interfacce MLM Dalla Figure 2 è evidente che il CSCI MLM si interfaccia direttamente con le seguenti entità: STL. Sistema di Telegestione Locale. Interfaccia. tale componente permette l invio delle le informazioni di gestione provenienti dal CSCI MLM rendendole disponibili al Server Regionale. Nei seguenti paragrafi sono descritte le diverse modalità di interfacciamento tra il Multi-purpose Local Manager ed il sistema di telegestione locale STL: 1. Via tabella su Data Base MySQL condiviso (v. 2.2) 2. Via protocollo SNMP (v. 2.3)

9 2.1 INIZIALIZZAZIONE DATA BASE Il database dell MLM proxy deve essere inizializzato con il set di dati che viene scambiato con il sistema di supervisione locale. In particolare, devono essere forniti l elenco dei servizi associati agli apparati monitorati e l elenco degli ordini applicabili su tali apparati. Queste informazioni devono essere notificate all amministratore di sistema preliminarmente all esecuzione dell MLM Proxy tramite un file XML che rispetti il seguente schema: <?xml version="1.0"?> <xs:schema xmlns:xs=" <xs:element name="configuration"> <xs:complextype> <xs:sequence> <xs:element name="site" type="xs:string"/> <xs:element name="supervisor_name" type="xs:string"/> <xs:element name="service_list"> <xs:complextype> <xs:sequence> <xs:element name="service" type="servicetype" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="servicetype"> <xs:sequence> <xs:element name="name" type="xs:string" maxoccurs="1"/> <xs:element name="description" type="xs:string" maxoccurs="1"/> <xs:element name="measure" type="measuretype" maxoccurs="1"/> <xs:element name="extended" type="xs:string" maxoccurs="1"/> <xs:element name="dynamic_label_number" type="xs:integer" maxoccurs="1"/> <xs:element name="service" type="servicetype" minoccurs="0" maxoccurs="unbounded"/> <xs:element name="order" type="ordertype" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:complextype name="ordertype"> <xs:sequence> <xs:element name="name" type="xs:string" maxoccurs="1"/> <xs:element name="description" type="xs:string" maxoccurs="1"/>

10 <xs:element name="command_type" type="xs:integer" maxoccurs="1"/> <xs:element name="input_parameter_number" type="xs:integer" maxoccurs="1"/> </xs:sequence> </xs:complextype> <xs:simpletype name="measuretype"> <xs:restriction base="xs:string"> <xs:enumeration value="alarm"/> <xs:enumeration value="switch"/> <xs:enumeration value="network"/> <xs:enumeration value="analogic_measure"/> <xs:enumeration value="custom"/> <xs:enumeration value="group"/> </xs:restriction> </xs:simpletype> </xs:schema> Lo schema prevede che ogni sistema di supervisione fornisca le seguenti informazioni: il sito d installazione (tag <site>); il nome del sistema di supervisione (tag <supervisor_name>); la lista dei servizi (tag <service_list>); Per ogni servizio (tag <service>) dovranno essere definite le seguenti informazioni: nome univoco identificativo del servizio (tag <name>); descrizione del servizio (tag <description>); tipo di misura (tag <measure>): ALARM SWITCH NETWORK ANALOGIC_MEASURE CUSTOM GROUP; un informazione aggiuntiva associata alla misura (tag <extended>): o in caso di tipo di misura SWITCH da compilare con i valori: LINEAR INVERTED; o in caso di tipo di misura ANALOGIC_MEASURE da compilare con l unità di misura associata (%, C, V); numero di label dinamiche associate al servizio da visualizzare sulla STN GUI (tag <dynamic_label_number>); elenco dei servizi figli (tag <service>); elenco degli ordini associati al servizio (tag <order>); Per ogni ordine dovranno essere definite le seguenti informazioni: nome univoco identificativo dell ordine (tag <name>); descrizione dell ordine (tag <description>); tipo di ordine (tag < command_type > default 0);

11 numero di parametri di input richiesti per l esecuzione dell ordine (tag <input_parameter_number>). Un esempio di file XML formattato seguendo lo schema precedentemente indicato è illustrato nel paragrafo seguente. <configuration xmlns:xsi=" xsi:nonamespaceschemalocation="schema.xsd"> <site>sito_name</site> <supervisor_name>supervisor_name</supervisor_name> <service_list> <service> <name>service1_name</name> <description>service1_description</description> <measure>alarm</measure> <extended/> <dynamic_label_number>1</dynamic_label_number> <service> <name>>service1_child1_name</name> <description> SERVICE1_CHILD1_DESCRIPTION </description> <measure>analogic_measure</measure> <extended>c</extended> <dynamic_label_number>1</dynamic_label_number> </service> <order> <name> SERVICE1_ORDER1_NAME</name> <description> SERVICE1_ORDER1_DESCRIPTION</description> <command_type>0</command_type> <input_parameter_number>0</input_parameter_number> </order> </service> </service_list> </configuration>

12 2.2 INTERFACCIAMENTO TRAMITE DATA BASE CONDIVISO In questo paragrafo è descritta l interfaccia, individuata nel Errore. L'origine riferimento non è stata trovata., tra il CSCI MLM ed il Sistema di Telegestione Locale, realizzata attraverso un DataBase open source condiviso (e.g. MySQL InnoDB), generalmente residente sul nodo Proxy. Il CSCI MLM si interfaccia con il Sistema STL per scambiare le seguenti tipologie di informazioni: Messaggi di stato Allarmi Messaggi diagnostici Notifiche Messaggi di Alive Ordini Al fine di velocizzare e ottimizzare le query di inserimento e update, il database metterà a disposizione delle stored procedures, di seguito specificate: In particolare sono state individuate le seguenti procedures: 1. UpdateStatus per aggiornare la tabella Status (delle Misure) 2. UpdateTime per fornire un messaggio di keepalive 3. ReadOrder per prelevare dalla tabella Orders i comandi in stato IACK 4. UpdateOrder per aggiornare la tabella Orders con gli output dei comandi eseguiti 5. GetNumberOfSupervisorStatus per fornire una vista dei monitorati dal sistema.

13 2.2.1 UpdateStatus La procedura updatestatus permetterà a STL di aggiornare la tabella delle misure Status con gli ultimi valori disponibili, restituendo conferma della regolare esecuzione della procedure. Sintassi La chiamata alla stored procedure prevede la seguente sintassi: CALL UpdateStatus(SERVICE_NAME, SEVERITY, MSG_GRP, MSG_TYPE, TEXT, LABELS) Input La procedura richiede in input i seguenti parametri (descritti in seguito nel dettaglio): SERVICE_NAME Text (MAX LENGHT 200) Identificativo della variabile controllata (Service Name) Il campo contiene l identificativo della variabile controllata ovvero, identifica la misura (servizio) di cui si vogliono aggiornare uno o più valori di riferimento. SEVERITY Text (MAX LENGHT 200) Severity Misura/Messaggio Il campo contiene l indicazione della severità della misura impostata da STL e intesa nella scala attesa da STN (normativa ISO 10164), che prevede i seguenti livelli: NORMAL, WARNING, MINOR, MAJOR, CRITICAL. MSG_GRP Integer (0..1) Identificativo del Message Group Il campo contiene il Message Group della misura impostata da STL, ovvero il gruppo a cui deve appartenere l opcmsg associato. Per gli impianti tecnologici sono previsti due gruppi: Nome_Sito-Alarms-IMP e Nome_Sito-Advices-IMP. A questa seconda tipologia appartengono messaggi contenenti segnalazioni di avviso importanti che, se non gestite tempestivamente, saranno poi causa di un danneggiamento al funzionamento normale di uno degli apparato degli Impianti Tecnologici. Il campo assumerà valore 0 nel primo caso (Alarms) e 1 nel secondo (Advices). MSG_TYPE Integer (0..2) Identificativo del Message Type

14 Output Il campo contiene il tipo di messaggio OPC associato che deve essere inviato (i.e. STATUS_MESSAGE, DIAGNOSTIC_MESSAGE, ALARM_MESSAGE) a STN per la notifica dell aggiornamento di stato della misura in esame. Il campo assumerà i seguenti valori: 0 per messaggi di Stato STATUS_MESSAGE; 1 per messaggi di Diagnostica DIAGNOSTIC_MESSAGE; 2 per messaggi di Allarme ALARM_MESSAGE. TEXT Text (MAX LENGHT 200) Testo dell opcmsg Il campo contiene la stringa che verrà inviata nel relativo opcmsg verso STN per la notifica dell aggiornamento di stato della misura in esame. In assenza di informazioni dettagliate aggiuntive, STL riporterà il solo nome del servizio (i.e. SERVICE_ID). La stringa dovrà essere comprensiva della/e unità di misura relativa/e, ove applicabile. LABELS Text (MAX LENGHT 5000) Label dinamiche Il campo contiene la lista delle label dinamiche associate alla misura (servizio) monitorata che saranno presentate sull interfaccia grafica delle workstation STN. Le diverse label sono separate le une dalle altre dal delimitatore (doppia pipe). Il testo di ciascuna label dinamica dovrà essere comprensivo dell unità di misura associata, ove applicabile. La procedura restituisce in output un valore numerico con il seguente significato: 0 La query è stata eseguita, ma non c è stato l aggiornamento dello stato. 1 La query è stata eseguita, e c è stato aggiornamento dello stato.

15 2.2.2 UpdateTime La funzione UpdateTime ha lo scopo di fornire un equivalente del messaggio keepalive, per permettere al proxy MLM di conoscere lo stato di comunicazione tra di esso e STL. La funzione verrà invocata ad intervalli di tempo configurabili e permetterà di aggiornare l ultimo tempo di accesso. Sintassi La chiamata alla funzione prevede la seguente sintassi: SELECT UpdateTime(SUPERVISOR_NAME) Input La funzione ha come parametro di input il campo: Output SUPERVISOR_NAME Text (MAX LENGHT 45) Identificativo del supervisore locale (Supervisor Name) Il campo contiene l identificativo del supervisore locale condiviso con l MLM Proxy. La funzione restituisce in output un valore numerico con il seguente significato: 0 La query è stata eseguita, ma non c è stato l aggiornamento del tempo. 1 La query è stata eseguita, e c è stato aggiornamento del tempo.

16 2.2.3 ReadOrder Questa procedura permette a STL di prelevare dalla tabella Orders gli ordini in stato IACK (inseriti) che devono ancora essere eseguiti. La procedura verrà eseguita ad intervalli di tempo configurabili, o alternativamente a seguito di un trigger del Proxy MLM, anch esso gestibile tramite stored procedure, da definire. Sintassi La chiamata alla procedura prevede la seguente sintassi: CALL ReadOrder(SUPERVISOR_NAME) Input La procedura ha come parametro di input il campo: Output SUPERVISOR_NAME Text (MAX LENGHT 45) Identificativo del supervisore locale (Supervisor Name) Il campo contiene l identificativo del supervisore locale condiviso con l MLM Proxy. La procedura restituisce una vista della tabella Orders contenente i seguenti campi: id Integer Identificativo record Ordine Questo campo viene impostato automaticamente dal database ad ogni inserimento di un nuovo ordine da eseguire e rappresenta una chiave univoca per identificare ogni ordine da gestire o gestito. L identificativo sarà composto da un prefisso MASSERIA\ seguito dall identificativo dell ordine. input Text Sintassi comando Ordine Il campo contiene la sintassi completa dell ordine da eseguire, formattata secondo le specifiche del gestore STL. parameters Text

17 Elenco parametri dell ordine Il campo contiene la lista dei parametri di input associati agli ordini,ove previsti, separati dal delimitatore (doppia pipe). commandtype Integer Identificativo del tipo di comando Il campo contiene un intero che può essere utilizzato, se previsto dallo specifico STL, per identificare il tipo di comando gestito. Un esempio di vista restituita dalla procedura in esame è illustrata in seguito id input parameters commandtype 3 SITO\\OrderName1 Param1 Param2 1 5 SITO\\OrderName2 1

18 2.2.4 UpdateOrder La procedura UpdateOrder ha lo scopo di permettere al supervisore STL l aggiornamento della tabella Orders alla conclusione dell esecuzione degli ordini presi in carico. Sintassi La chiamata alla procedura prevede la seguente sintassi: CALL UpdateOrder(ID, OUTPUT, ACKN) Input ID Integer Identificativo record Ordine Questo campo, ottenuto come risultato della stored procedure ReadOrder, permette di identificare l ordine gestito. OUTPUT Text (MAX LENGHT 200) Risposta all esecuzione Ordine Il campo contiene quanto restituito dall esecuzione dell ordine, stati, valori numerici (comprensivi dell eventuale unità di misura associata), messaggi diagnostici o di errore. Esempi di messaggi sono riportati di seguito: - CMD_COMPLETED (il comando è stato eseguito correttamente); - BAD_USER (l utente non è abilitato all esecuzione del comando); - CMD_ERROR (il comando è stato rigirato all apparato di competenza ma questo ha restituito un errore nell esecuzione dell operazione); - BAD_PLANT (il comando non è di pertinenza del sistema cui è stato rigirato); - TIMEOUT (timeout nell operazione di esecuzione del comando); - CMD_ALREADY_IN_PROGRESS (lo stesso comando è già in esecuzione a seguito della richiesta di un altro client. La stringa sarà completata con l identificativo del client concorrente WID o ID client STL). ACKN Text (4 CHAR) Acknowledgement

19 Il campo contiene un quadri-letterale avente lo scopo di identificare lo stato di esecuzione dell ordine. Il campo potrà assumere i seguenti valori: ACKN: NACK: ordine eseguito, l eventuale risposta all ordine sarà scritta nel campo OUTPUT; ordine non eseguito, l eventuale messaggio di errore sarà scritto nel campo OUTPUT. Output La procedura restituisce in output un valore numerico con il seguente significato: 0 l esecuzione della query non è andata a buon fine 1 l esecuzione della query è andata a buon fine

20 2.2.5 GetNumberOfSupervisorStatus La procedura GetNumberOfSupervisorStatus restituisce l elenco dei servizi monitorati dal sistema di supervisione locale concordati con l MLM proxy, ovvero i servizi dei quali si ricevono gli aggiornamenti di stato dal gestore il cui identificativo è passato in input alla procedura. Sintassi La chiamata alla procedura prevede la seguente sintassi: CALL GetNumberOfSupervisorStatus(SUPERVISOR_NAME) Input La procedura ha come parametro di input il campo: Output SUPERVISOR_NAME Text (MAX LENGHT 45) Identificativo del supervisore locale (Supervisor Name) Il campo contiene l identificativo del supervisore locale condiviso con l MLM Proxy. La procedura restituisce una vista della tabella status contenente i seguenti campi: service_id Text (MAX LENGHT 200) Il campo contiene l identificativo del servizio gestito dal sistema di supervisione locale condiviso con l MLM Proxy. Un esempio di vista restituita dalla procedura in esame è illustrata in seguito service_id servicename1 (eg:.ups_status) servicename2 (eg:. TemperaturaAmbiente)

21 2.3 INTERFACCIAMENTO TRAMITE PROTOCOLLO SNMP La modalità di interfacciamento di seguito descritto sarà sviluppata nelle prossime versioni del CSCI MLM. Essa prevede l utilizzo del protocollo SNMP (Simple Network Managment Protocol), che permette il monitoraggio (statistiche sullo stato dei sistemi) ed il controllo (modifica delle impostazioni) di dispositivi connessi in rete. SNMP è passato attraverso alcune revisioni fino all'attuale versione 3: SNMPv1: descritto nelle RFC rappresenta la prima versione, utilizza l'invio dei nomi di community (utilizzati come password) in chiaro; SNMPv2: descritto nelle RFC in cui sono state aggiunte nuove funzionalità tra cui la crittografia tramite MD5; SNMPv3: descritto nelle RFC è lo standard finale, ma al momento raramente utilizzato. Sostanzialmente un framework SNMP è composto da una o più Stazioni di Gestione (Management Station) e dagli agenti SNMP (SNMP Agent) in funzione sui device in rete. Le Management Station interrogano gli agent i quali inviano le informazioni richieste sul device. Gli oggetti gestiti dagli agent, sono raccolti, in ogni device, in un database chiamato MIB (Management Information Base) secondo la struttura definita nella SMI (Structure Management Information). Questa architettura permette una separazione fra il protocollo di gestione e la struttura dell'oggetto gestito. Come anticipato, nell'architettura SNMP, per ogni sottosistema è definita una base dati detta MIB (Management Information Base), gestita dal corrispondente agent, la quale rappresenta lo stato del sottosistema gestito, o meglio, una proiezione di tale stato limitata agli aspetti di cui si vuole consentire la gestione. Si tratta di una base dati "causalmente connessa" in quanto ogni modifica alla MIB causa un corrispondente mutamento nello stato del sottosistema rappresentato, e viceversa. Garantire questa proprietà della MIB è la funzione principale dell agent che la gestisce. L'accesso alla MIB (in lettura e scrittura) rappresenta l'interfaccia fornita al manager per gestire il sistema. Ogni MIB, pur variando nei contenuti specifici, ha la medesima struttura generale e i medesimi meccanismi generali di accesso da parte del manager (lettura e scrittura dei dati). Grazie alla connessione causale della MIB, è quindi possibile al manager agire sullo stato del sottosistema in un modo che è largamente indipendente dalle procedure concrete che devono essere messe in atto (dall agent) per estrarre le informazioni di stato rappresentate nella MIB, o attuare le modifiche di stato a seguito di cambiamenti dei contenuti della MIB. Gli oggetti di un MIB vengono definiti utilizzando un sottoinsieme della notazione Abstract Syntax Notation One (ASN.1) chiamato "Structure of Management Information Version 2 (SMIv2)" (RFC 2578). Il software che ne effettua il parsing viene chiamato compilatore MIB. Il database è di tipo gerarchico (ovvero strutturato ad albero) ed ogni entry viene indirizzata attraverso un identificatore di oggetto (object identifier - OID) Requisiti di interfacciamento

22 Come descritto nel paragrafo precedente, al fine di consentire la telegestione tramite protocollo SNMP è necessario che su ogni apparato: 1. sia installato un Agent SNMP; 2. sia definita una struttura MIB che contenga le informazioni rilevanti per il sistema STN. Nel paragrafo Errore. L'origine riferimento non è stata trovata. è riportata la MIB massimale prevista per gli impianti tecnologici, definita nei documenti di riferimento Errore. L'origine riferimento non è stata trovata. e Errore. L'origine riferimento non è stata trovata.. La definizione della MIB dovrà essere specifica per il singolo sito per soddisfare le necessità particolari legate alla configurazione ed alle esigenze operative. L Agent SNMP dovrà provvedere all invio di Trap (personalizzando il campo variable bindings) ad ogni variazione di stato dei parametri inclusi nella MIB. Inoltre le informazioni contenute nella MIB dovranno essere aggiornate ad intervalli regolari (parametro di sistema configurabile), in modo da consentire al CSCI MLM la lettura delle stesse tramite GetRequest, ad esempio in fase di riallineamento (automatico o manuale).

23 FINE DEL DOCUMENTO