ICD Proxy ENAV Interface Control Document

Transcript

1 ICD Proxy ENAV Interface Control Document

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 FILE DI LOG Sistemi Operativi WINDOWS Sistemi Operativi di tipo UNIX/LINUX INTERFACCIAMENTO TRAMITE PROTOCOLLO SNMP INDICE DELLE FIGURE Figura 1 Architettura STN... 4 Figura 2 Interfacce CSCI MLM... 8

3 1 SCOPO 1.1 IDENTIFICAZIONE Questo documento definisce la progettazione di dettaglio riguardante la realizzazione delle interfacce del software 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 software Proxy denominato 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 uomo-macchina 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. Ciascun Proxy comunica le informazioni raccolte attraverso i diversi Sistemi STL ed opportunamente rielaborate, al Server del Centro di Supervisione e Controllo di competenza; questa fase viene gestita utilizzando il software HP Openview che sfrutta un Agent attivo sul Proxy ed in comunicazione con un Manager presente sul Server.

4 Centro Nazionale Centro Regionale Centro Regionale Centro Regionale Proxy #1 Proxy #N Sistema di Telegestione Locale #1 Sistema di Telegestione Locale #2 Sistema di Telegestione Locale #n Figura 1 Architettura STN Il software CSCI MLM residente sul nodo Proxy si interfaccia quindi con: i Sistemi di Telegestione Locale (rappresentati in Figura:1 dai sistemi STL all ultimo livello) con l architettura HP OVO attraverso il componente Agent HP installato, (anch esso residente sul nodo Proxy) garantendo l interfacciabilità ed interoperabilità con la rete STN. Il software CSCI MLM ha il compito di inviare all Agent HP i dati riguardanti lo stato e la diagnostica generati dal gestore locale oggetto del monitoraggio, inoltre invia la risposte agli ordini provenienti dalle workstation STN. 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.

5 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 Nella seguente figura è illustrato il posizionamento architetturale del CSCI MLM all interno dell architettura STN. Sistema di Telegestione Locale Sottosistema Proxy ENAV CSCI MLM OVO Agent Server Regionale STN Figura 2 Interfacce CSCI MLM Dalla figura 2 è evidente che il CSCI MLM si interfaccia direttamente con le seguenti entità: STL. Sistema di Telegestione Locale a cura della società fornitrice. OVO Agent. OVO Agent è parte dell architettura OVO. Tale architettura, sinteticamente, realizza il monitoraggio, il controllo e la valutazione della qualità dei servizi. OVOAgent invia le informazioni di gestione provenienti dal CSCI MLM rendendole disponibili al Server Regionale OVO. Nei seguenti paragrafi sono descritte le diverse modalità di interfacciamento tra il Multi-purpose Local Manager ed il sistema di telegestione locale STL. Il fornitore degli apparati dovrà garantire che il proprio STL sia compatibile con una delle tre interfacce proposte: 1. Via tabella su Data Base MySQL condiviso (v. 2.2) 2. Via protocollo SNMP (v. 2.4) 3. Via File di Log (v. 2.3) Delle tre interfacce, elencate in ordine di preferenza, è favorito l utilizzo del Data Base MySQL condiviso.

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 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..3) 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. I Message Group previsti sono: Nome_Sito-Alarms- Apparato (0), Nome_Sito-Advices-Apparato (1), Nome_Sito-Notification-Apparato (2), e Nome_Sito-Diagnostic-Apparato (3). Ad esempio per gli Impianti Tecnologici e le RRAA di Napoli avremo: Napoli-Alarms-IMP Napoli-Alarms-RRAA MSG_TYPE Integer (0..3)

14 Output Identificativo del Message Type Il campo contiene il tipo di messaggio OPC associato che deve essere inviato (i.e. STATUS_MESSAGE, DIAGNOSTIC_MESSAGE, ALARM_MESSAGE, REPLY_ORDER) 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. 3 per messaggi di Risposta REPLY_ORDER. 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 CSCI 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 CSCI 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 Nome Sito\ 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 FILE DI LOG La modalità di interfacciamento di seguito descritto sarà sviluppata nelle prossime versioni del CSCI MLM. Essa prevede che su ciascun sistema da monitorare deve essere presente un file di log formato testo, in cui si andranno ad indicare sia lo stato del sistema che quello degli applicativi in modo da rendere tali informazioni disponibili verso il CSCI MLM e quindi STN. Nei paragrafi seguenti è illustrata la procedura per la corretta creazione, e relativo aggiornamento, del file di log in funzione del tipo di Sistema Operativo adottato. Per consentire il corretto interfacciamento tra MLM e STL tramite file di log si dovrà assicurare la perfetta sincronizzazione tra gli apparati Sistemi Operativi WINDOWS La procedura da seguire per la corretta creazione del file di LOG sulle Workstation che adottano il Sistema Operativo WINDOWS è la seguente: 1. Creare la cartella stn nella directory root: (es: c:\stn). 2. Condividere la cartella precedentemente creata (es: c:\stn), impostando come nome della condivisione $STN e autorizzando l accesso alla cartella alla classe di utenti Everyone sia in lettura che in scrittura. 3. Sviluppare un applicativo ad hoc per la gestione automatica del file di log; l applicazione deve effettuare le seguenti operazioni: a. Creare un file di nome utime.log nella directory precedente, dove per <utime> si intende lo Unix time nel momento in cui il file viene creato. b. Scrivere nel file le informazioni richieste. c. Attendere una nuova variazione dei parametri monitorati e ripartire dal passo a. d. Qualora non ci siano variazioni di parametri entro un tempo parametrico, dovrà comunque essere creato un file secondo quanto specificato nel punto a. contenente la sola stringa ALIVE. e. Allo start up del sistema STL, dovrà essere creato un file di log secondo quanto specificato al punto a. contenente lo stato di tutte le variabili monitorate.

22 2.3.2 Sistemi Operativi di tipo UNIX/LINUX La procedura da seguire per la corretta creazione del file di LOG sulle Workstation che adottano un Sistema Operativo di tipo UNIX è la seguente: 1. Installare un software che fornisca servizi di condivisione di file. Creare la directory stn: (es: /stn). 2. Configurare opportunamente il servizio di condivisione file per consentire al CSCI MLM l accesso in lettura e scrittura a tutti i file presenti nella cartella /stn. 3. Sviluppare un applicativo ad hoc per la gestione automatica del file di log; l applicazione deve effettuare le seguenti operazioni: a. Creare un file di nome utime.log nella directory precedente, dove per <utime> si intende lo Unix time nel momento in cui il file viene creato. b. Scrivere nel file le informazioni richieste. c. Attendere una variazione dei parametri monitorati e ripartire dal passo a. d. Qualora non ci siano variazioni di parametri entro un tempo parametrico, dovrà comunque essere creato un file secondo quanto specificato nel punto a. contenente la sola stringa ALIVE. e. Allo start up del sistema STL, dovrà essere creato un file di log secondo quanto specificato al punto a. contenente lo stato di tutte le variabili monitorate.

23 2.4 INTERFACCIAMENTO TRAMITE PROTOCOLLO SNMP La modalità di interfacciamento di seguito descritto 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).

24 FINE DEL DOCUMENTO