Installazione e setup del sistema di monitoring del Trigger Supervisor. Sabato Stefano Caiazza

Transcript

1 Installazione e setup del sistema di monitoring del Trigger Supervisor Sabato Stefano Caiazza 18 febbraio 2008

2 Struttura del Trigger Supervisor in funzione del monitoring Il Daemon XDAQD Nel suo setup definitivo tutte le applicazioni del Trigger Supervisor verranno invocate tramite un daemon che è usato anche per lanciare tutti i servizi di cui queste applicazioni fanno uso. Il daemon viene lanciato tramite il riferimento al file \etc\init.d\xdaqd. Questo file serve a definire le operazioni legate al servizio, in particolare le funzioni di start, stop e restart. Per ognuno dei servizi o applicazioni lanciati il daemon ricerca un file.conf dallo stesso nome in cui sono specificati i path per individuare i file di configurazione del servizio e la porta su cui aprirlo. Le applicazioni, oltre ai path specifici che determinano la posizione dei file di profilo, fanno riferimento anche ad un file, con estensione.configure che inizializza l applicazione prima della sua configurazione. Inizializzazione applicazioni Tutte le applicazioni (con il termine applicazione faccio riferimento a supervisor e workers) prima di essere configurate devono essere inizializzate. Questa inizializzazione viene effettuate all interno di un file con estensione.configure. A questo file va riferimento tanto lo shell script quanto il daemon al momento del lancio delle applicazioni desiderate. Per il funzionamento del monitoring, oltre alle celle, è necessario attivare l applicazione LAS, che gestisce tutte le operazioni di logging e alarming. I file di profilo Ognuno dei servizi lanciato dal daemon viene configurata attraverso un file di profilo. Tutti i file di profilo sono raccolti nella sottodirectory profile della directory di setup. Ognuno di questi file di profilo è chiamato servicename.profile in cui servicename è il nome dell applicazione lanciata nella startup list che deve essere configurata. Un file di profilo è una raccolta di plugin. Il primo di questi plugin è sempre chiamato Executive. Insieme a PeerTransportHTTP e PeerTransportFIFO costituisce l insieme dei plugin obbligatori. Oltre a questi plugin obbligatori ce ne sono altri di utilità chiamati XRelay, HyperDAQ, Xplore e Sentinel. I plugin importanti da personalizzare sono generalmente alla fine del file (per comodità, non per prescrizione). Nel caso della cella supervisor questa applicazione aggiuntiva da personalizzare è il sensore. Il sensore riceva dalla cella i valori delle variabili da monitorare e li reinvia al collector, chiamato ws-eventing. Un sensore può essere utilizzato tanto per pubblicare i dati monitorabili sui servizi ws-eventing quanto per raccogliere dati da più sensori e reinviarli ad un altro ws-eventing. I sensori I sensori sono i servizi del trigger supervisor che raccolgono dalle celle o da altri sensori i dati relativi alle variabili monitorate per ripubblicarli sui collector. Ogni cella può avere il suo specifico sensore. Il sensore, istanziato all interno del file di profilo della cella stessa viene configurato da un apposito file dall estensione.sensor. Oltre ai sensori definiti dalle varie applicazioni esiste un sensore generale che raccoglie i dati relativi all intero sistema. Questo sensore viene invocato nel daemon stesso, nella startup list, ed ha il proprio file.profile e il proprio file.sensor. In questo sensore il valore dell attributo group è dtsc,general. Ciò significa che fa capo contemporaneamente ai gruppi dtsc e general e può pubblicare o raccogliere dati da entrambi. Questo sensore funge da collector per il gruppo dtsc ripubblicando quei dati nel gruppo general in modo che gli stessi monitorabili di dtsc siano visibili a tutto il sistema (probabilmente permette ad altre celle di accedere a quei monitorabili). Flashlists Come abbiamo visto nella precedente sezione il file di configurazione del sensore fa riferimento ad un oggetto chiamato flashlist. La flashlist è una lista di oggetti monitorabili che serve a dichiararli a livello globale all interno del trigger supervisor. Per ogni sensore può essere definita una flashlist diversa a pato che i nomi delle variabili dichiarate siano univoci (è da controllare se due sensori possono accedere alla stessa flashlist dato che in questo caso dichiarerebbero due volte la stessa variabile. Forse è possibile se questi sensori sono in gruppi separati. Si potrebbe anche controllare se un sensore può accedere a più di una flashlist) 2

3 Collectors Le informazioni sulle grandezze monitorabili raccolte dai sensori vengono inviati ad applicazioni di nome ws-eventing. Ogni sottosistema, ovvero ogni insieme di applicazioni con lo stesso valore dell attributo group invia i propri dati ad uno di questi collectors. Ad esempio, nel caso del gruppo dtsc, avremo un collector dedicato a nome dtsc-ws-eventing che viene avviato dal daemon xdaqd e che viene configurato tramite il suo file di profilo dedicato. Questo, come plugin finale ha proprio un applicazione di classe ws::service::eventing. Oltre ai singoli collector per i singoli sottosistemi esiste un collettore generale a cui tutti i collettori specifici inviano le proprie informazioni per la pubblicazioni di queste a livello globale. Anche questo collector viene lanciato attraberso il daemon con il nome di general-ws-eventing. La configurazione è simile a quella dei collector specifici di sottosistema ma il valore di group contiene la denominazione general che lo identifica come il collettore di tutte le variabili di sistema Pulser Per sincronizzare la raccolta dei dati su tutto il sistema distribuito un servizio specifico chiamato Pulser invia segnali periodici ai sensori perchè aggiornino il valore delle variabili monitorabili. Anche questo servizio è configurato attraverso un appropriato file di profilo alla cui fine abbiamo la definizione del plugin Pulser. Questo file punta ad un altro file di configurazione che ha estensione.pulser e si trova nella sottodirectory pulser della directory di setup. La configurazione del pulser prevede la definizione di un evento, collegato ad una determinata flashlist. Ogni evento è caratterizzato da una determinata frequenza, parametrizzata dal valore dell attributo period che identifica l intervallo tra due successivi refresh del monitorabile. Gli Oggetti Monitorabili Configurando correttamente i precedenti servizi si dichiarano a livello globale le variabili da monitorare in modo tale che tutte le applicazioni, tanto quelle locali che quelle remote vi possano accedere. Il funzionamento di queste variabili, in particolare le operazioni da effettuare sull hardware per generare i dati monitorabili, è programmato all interno del codice della cella. Le variabili monitorabili sono tutte dichiarate all interno di un oggetto derivato dal tipo DataSource, una classe definita all interno di XDAQ appositamente per gestire il monitoraggio. Nel nostro caso questa classe derivata si chiama MonitorSource. Questa classe derivata definisce un costruttore ed una serie di metodi di refresh, una per ogni variabile da monitorare. Nel costruttore vengono principalmente definite le variabili da monitorare e invocate le funzioni di refresh su queste variabili, le funzioni di refresh invece contengono l algoritmo da eseguire sull hardware, o su altre variabili interne per aggiornare le variabili monitorabili. Questo algoritmo viene eseguito ogni qual volta il pulser invia il proprio segnale, comunicando difatti alla classe MonitorSource di eseguire il proprio costruttore. 3

4 Setup del sistema passo passo Il primo passo da fare al momento di configurare il sistema del Trigger Supervisor, in particolare per applicazioni quali il monitor e il database è decidere la posizione della directory di configurazione all interno della quale raccogliere tutti i file di configurazione che in seguito si andranno a modificare e al quale il daemon avrà accesso. Environment.sh Cambiare in questo file l alias della variabile d ambiente $XDAQ_SETUP_ROOT in modo tale che punti alla directory di setup desiderata. Nella versione di default questa directory è /opt/xdaq/share. Questa directory è accessibile normalmente solo a superusers. Cambiare l alias della variabile d ambiente XDAQ_ZONE in modo che punti alla sottodirectory della directory di setup in cui sono contenute le directory conf, profile.... Nella configurazione di default questa variabile è impostata su multicell o unicell. xdaqd Dopo aver definito a livello di variabili d ambiente la directory dove sono situati tutti i file di configurazione bisogna comunicare al daemon che lancerà i servizi la posizione di questi file. Per farli bisogna cambiare la variabile CONF_DIR all interno del file /etc/init.d/xdaqd. Questa variabil deve puntare alla sottodirectory conf della directory di setup dove si trova il file xdaqd.conf. Nella versione definitiva, dove il sistema sarà distribuito su varie macchine, su ognuna ci sarà un file analogo di nome hostname.conf dove hostname è il nome della macchina. xdaqd.conf Il file xdaqd.conf definisce la lista dei servizi da lanciare e la posizione dove individuare i loro file di configurazione. La posizione dei file di configurazione viene individuata attraverso la ridefinizione delle variabili $XDAQ_SETUP_ROOT e XDAQ_ZONE in modo tale che queste corrispondano al path definito nel file di ambiente. La lista dei servizi da lanciare è invece definita attraverso la variabile STARTUP_LIST. Un esempio di questo file, con una lista di servizi essenziali per poter attivare il monitoring del sistema è inclusa nel prossimo estratto di codice. XDAQ_SETUP_ROOT=/home/caiazza/DAQKit/TriDAS/trigger/setup/ XDAQ_DOCUMENT_ROOT=/opt/xdaq/htdocs XDAQ_EXTERN_LIBRARY_PATH=/opt/xdaq/lib PID_DIR=/var/run LOCK_DIR=/var/lock XDAQ_ZONE=multicell XDAQ_HOSTNAME= hostname -f XDAQ_USER=root XDAQ_ROOT=/opt/xdaq CORE_DIR=/tmp XDAQ_CONFIG= STARTUP_LIST="dtsc-ws-eventing general-ws-eventing general-dashboard general-las dtsc-pulser dtsc-sensor exception-ws-eventing exception-dashboard" xdaq.conf Per ognuno di questi servizi il daemon ricerca un file.conf dallo stesso nome in cui sono definiti alcuni parametri essenziali per avviare l applicazione. files.conf Nei file.conf sono definiti i path dei file di configurazione del sistema nonchè la porta su cui aprire i servizi e le applicazioni. Nel caso di un servizio, quale ad esempio dtsc-sensor, il file ha questo formato 4

5 XDAQ_SETUP_ROOT=/home/caiazza/DAQKit/TriDAS/trigger/setup XDAQ_DOCUMENT_ROOT=/opt/xdaq/htdocs XDAQ_PORT=5004 XDAQ_LOG=/var/log/${CONFIGURATION}.log XDAQ_PROFILE=${XDAQ_SETUP_ROOT}/${XDAQ_ZONE}/profile/${CONFIGURATION}.profile dtsc-sensor.conf Nel caso di un applicazione invece, oltre ai parametri definiti nel precedente estratto di codice abbiamo anche il riferimento al file.configure che inizializza l applicazione e alla directory BUILD_HOME nelle cui subdirectory è contenuto il codice dell applicazione stessa. XDAQ_SETUP_ROOT=/home/caiazza/DAQKit/TriDAS/trigger/setup XDAQ_DOCUMENT_ROOT=/opt/xdaq/htdocs XDAQ_PORT=2974 BUILD_HOME=/home/caiazza/DAQKit/TriDAS XDAQ_CONFIG=${XDAQ_SETUP_ROOT}/${XDAQ_ZONE}/profile/dtsc.configure XDAQ_LOG=/var/log/${CONFIGURATION}.log XDAQ_PROFILE=${XDAQ_SETUP_ROOT}/${XDAQ_ZONE}/profile/${CONFIGURATION}.profile dtsc-supervisor.conf Ogni qualvolta si personalizza un servizio o un applicazione è opportuno controllare che il corrispondente file.conf faccia capo al path appropriato. dtsc.configure Dopo aver configurato il daemon, che lancia i servizi, si passa a configurare le applicazioni, attraverso il file dtsc.configure. A questo file va fatto riferimento tanto quando si lanciano le applicazioni via shell script, tanto quando queste verranno lanciate tramite il daemon. In questo file, per ogni applicazione da lanciare, è contenuto del codice di configurazione. Per esempio inserisco quello relativo alla cella supervisor del dtsc. <!-- SUPERVISOR CELL --> <xc:context url=" <xc:application class="cell" id="13" instance="2" network="local" service="dtsc-supervisor" group="dtsc"> <properties xmlns="urn:xdaq-application:cell" xsi:type="soapenc:struct"> <name xsi:type="xsd:string">dtsc</name> <xhannellisturl xsi:type="xsd:string">file://$xdaq_setup_root/$xdaq_zone /profile/dtsc-supervisor.xhannel</xhannellisturl> </properties> </xc:application> <xc:module>file://${build_home}/trigger/dtsc/ts/parsers/lib/ ${XDAQ_OS}/x86_slc4/libParsers.so</xc:Module> <xc:module>file://${build_home}/trigger/dtsc/ts/boardprocedures/lib/ ${XDAQ_OS}/x86_slc4/libBoardProcedures.so</xc:Module> <xc:module>file://${build_home}/trigger/dtsc/ts/cell/lib/ ${XDAQ_OS}/x86_slc4/libdtsc.so</xc:Module> </xc:context> dtsc.configure Per poter correttamente attivare il monitor è necessario prender nota dei valori degli attributi service e group all interno del tag xc:application. É inoltre opportuno verificare che il tag 5

6 xhannellisturl faccia capo al file corretto in cui è inserita la lista degli xhannel dell applicazione. Infine è anche opportuno verificare che i tag xc:module facciano riferimento alle librerie corrette. Oltre alle applicazioni Supervisor e Worker è necessario, in questo file, dichiarare una applicazione supplementare, il LAS, che gestisce tutto il sistema di monitor. Questa dichiarazione è effettuata tramite la seguente struttura XML: <!-- LAS --> <xc:context url=" <xc:application class="xmas::las::application" id="10" instance="0" network="local" group="general" service="las"> </xc:application> </xc:context> dtsc.configure Si può notare come il valore degli attributi service e group siano diversi dal caso della cella supervisor. Questa struttira che di default è già presente nel file.configure installato non va modificata ulteriormente dtsc-supervisor.profile Dopo aver definito quali saranno le applicazioni (con il.configure) e i servizi (tramite la STARTUP_LIST del daemon) è necessario configurale. Per effettuare questa configurazione è opportuno partire dalle applicazioni. In seguito il testo farà sempre riferimento all applicazione supervisor del dtsc, ma lo stesso procedimento può essere eseguito sui worker o su qualsiasi altro sottosistema, avendo cura di modificare opportunamente le stringhe inserite nei file di configurazione. Per effettuare questa configurazione partiamo dalla personalizzazione del file di profilo della nostra applicazione.il primo plugin presente nel file di profilo è sempre quello chiamato executive. La personalizzazione che può essere opportuno effettuare in questo plugin è la modifica del tag logurl che indica la posizione dove registrare il log dell applicazione. Nel caso in cui si voglia inviare il log direttamente su console basta inserire come contenuto del tag la stringa console come mostrato nel prossimo estratto di codice <xp:application class="executive::application" id="0" group="profile" service="executive" network="local"> <properties xmlns="urn:xdaq-application:executive" xsi:type="soapenc:struct"> <logurl xsi:type="xsd:string">console</logurl> <loglevel xsi:type="xsd:string">info</loglevel> </properties> </xp:application> dtsc-supervisor.profile Le personalizzazioni più importanti vanno generalmente effettuate sull ultimo plugin della serie. Nel caso del monitoring di un applicazione questo plugin definisce il sensore dell applicazione stessa. I valori da modificare in questo plugin sono il valore dell attributo group del tag xp:application ed il contenuto del tag group. Entrambi devono corrispondere al valore dell attributo group dell applicazione così come definito all interno del file.configure. Nel prossimo estratto di codice mostro la configurazione del sensore della nostra applicazione di esempio. <!-- xmas::sensor::application --> <xp:application class="xmas::sensor::application" id="11" service="sensor" group="dtsc" network="local"> <properties xmlns="urn:xdaq-application:xmas::sensor::application" xsi:type="soapenc:struct"> <usediscovery xsi:type="xsd:boolean" >true</usediscovery> 6

7 <autoconfigure xsi:type="xsd:boolean" >true</autoconfigure> <autoconfsearchpath xsi:type="xsd:string">${xdaq_setup_root}/ ${XDAQ_ZONE}/sensor</autoConfSearchPath> <publish xsi:type="soapenc:array" soapenc:arraytype="xsd:ur-type[1]"> <item xsi:type="soapenc:struct" soapenc:position="[0]"> <tag xsi:type="xsd:string"></tag> <group xsi:type="xsd:string">dtsc</group> </item> </publish> </properties> </xp:application> dtsc-supervisor.profile Si può notare come in questo sensore sia definito il tag publish che istruisce il servizio a che invii i dati monitorabili al servizio ws-eventing che fa capo al gruppo dtsc oppure ad altri sensori che effettuano il collecting dei dati del gruppo dtsc. dtsc-supervisor.sensor Tutti i sensori vengono configurati tramite degli specifici file di configurazione che generalmente hanno l estensione.sensor e si trovano nella subdirectory sensor della directory di setup. Nel caso di un applicazione questo file di configurazione si chiama servicename.sensor dove servicename è il valore dell attributo service dell applicazione, così come definito nel file.configure. Nel nostro caso quindi il file si chiama dtsc-supervisor.sensor <xmas:sensor xmlns:xmas=" <xmas:monitor xmlns:xlink=" <xmas:flash xlink:type="locator" xlink:href="${xdaq_setup_root}/ ${XDAQ_ZONE}/flash/dtsc-supervisor.flash #urn:xdaq-flashlist:dtsc-supervisor"/> <xmas:sampler tag="dtsc" type="urn:xmas-sampler:instant"> </xmas:sampler> </xmas:monitor> </xmas:sensor> dtsc-supervisor.sensor Gli elementi da personalizzare in questo file sono il tag xmas:flash e il valore dell attributo tag del tagxmas:sampler. Il primo di questi elementi definisce il nome e la posizione della flashlist a cui fa capo questo sensore. É fondamentale che la stringa che segue il carattere # sia uguale al valore dell attributo id della flashlist. Il secondo elemento deve invece corrispondere al valore dell attributo group dell applicazione. dtsc-supervisor.flash Come abbiamo visto precedentemente il sensore fa riferimento ad un oggetto chiamato flashlist. Un esempio di flashlist è contenuto nell estratto di codice che segue: <xmas:flash xmlns:xmas=" id="urn:xdaq-flashlist:dtsc-supervisor" version="1.0.0"> <xmas:item name="item1" infospace="dtsc-supervisor" type="string" /> <xmas:item name="item2" infospace="dtsc-supervisor" type="int" /> <xmas:item name="table" infospace="dtsc-supervisor" type="table" /> </xmas:flash> dtsc-supervisor.flash La prima riga di codice definisce l oggetto flashlist assegnandole un nome, il valore dell attributo id, che deve corrispondere a quello inserito nel file di sensore che fa riferimento a tale flashlist 7

8 (Bisognerebbe controllare se nello stesso file.flash si possono inserire flashlist multiple con id differente). Nei contenuti del tag xmas:flash ciascuna delle variabili da monitorare viene dichiarata con un nome, un tipo ed un infospace un identificativo che serve a raggruppare insiemi di variabili. dtsc-ws-eventing.profile Dopo aver configurato i plugin dell applicazione che stiamo aggiungendo bisogna modificare in maniera appropriata alcuni altri servizi che si rapportano a questa applicazione, invocati attraverso la startup list del daemon. Questi servizi da modificare sono il collector, il sensore e il pulser relativi al gruppo di cui questa applicazione fa parte. Iniziamo a personalizzare il collector, il cui file di profilo ha nome dtsc-ws-eventing.profile. In particolare va personalizzato l ultimo plugin presente in questo file in modo tale che il valore dell attributo group sia identico a quello dell applicazione da monitorare. Nel nostro caso questo valore è "dtsc". <xp:application class="ws::service::eventing" id="400" network="local" group="dtsc" service="ws-eventing"> <properties xmlns="urn:xdaq-application:ws::service::eventing" xsi:type="soapenc:struct"> </properties> </xp:application> dtsc-ws-eventing.profile dtsc-sensor.profile Il successivo servizio da configurare è il sensore relativo all intero sottosistema. Questo servizio è chiamato dtsc-sensor e quindi il suo file di configurazione è chiamato dtsc-sensor.profile. Questo file è identico al file di profilo della cella, in tutto tranne che nella definizione del plugin che definisce il sensore. In questo caso il sensore fa capo ad entrambi i gruppi dtsc e general. Le operazioni sono però diverse ripetto ai due gruppi. Il sensore infatti colleziona gli elementi dal gruppo dtsc e li ripubblica sul gruppo general laddove il sensore dell applicazione si limitava a pubblicare i dati nel gruppo dtsc. In effetti questo servizio opera una copia delle varibili dal gruppo dtsc a quello general. <xp:application class="xmas::sensor::application" id="15" service="sensor" group="dtsc,general" network="local"> <properties xmlns="urn:xdaq-application:xmas::sensor::application" xsi:type="soapenc:struct"> <usediscovery xsi:type="xsd:boolean">true</usediscovery> <url xsi:type="soapenc:array" soapenc:arraytype="xsd:ur-type[2]"> <item xsi:type="xsd:string" soapenc:position="[0]">${xdaq_setup_root}/ ${XDAQ_ZONE}/sensor/dtsc-sensor.sensor</item> </url> <collect xsi:type="soapenc:array" soapenc:arraytype="xsd:ur-type[1]"> <item xsi:type="soapenc:struct" soapenc:position="[0]"> <tag xsi:type="xsd:string"></tag> <group xsi:type="xsd:string">dtsc</group> </item> </collect> <publish xsi:type="soapenc:array" soapenc:arraytype="xsd:ur-type[1]"> <item xsi:type="soapenc:struct" soapenc:position="[0]"> <tag xsi:type="xsd:string"></tag> <group xsi:type="xsd:string">general</group> </item> </publish> </properties> 8

9 </xp:application> dtsc-sensor.profile dtsc-sensor.sensor Come nel caso del sensore dell applicazione supervisor anche quello del servizio dtsc-sensor va configurato attraverso l apposito file.sensor che introduce il riferimento alle flashlist. Questo sensore però deve fare riferimento a tutte le flashlist delle applicazioni del gruppo. Come esempio inserisco un estratto di codice in cui, oltre alla flashlist vista prima per l applicazione supervisor si fa riferimento anche alla flashlist si un altra applicazoione chiamata dtsc-worker. Anche in questo caso vanno personalizzati i valori degli attributi xlink:href e tag. <xmas:sensor xmlns:xmas=" <xmas:monitor xmlns:xlink=" <xmas:flash xlink:type="locator" xlink:href=" /home/caiazza/daqkit/tridas/trigger/setup/multicell/ flash/dtsc-supervisor.flash#urn:xdaq-flashlist:dtsc-supervisor"/> <xmas:sampler tag="dtsc" type="urn:xmas-sampler:history" output="merge" format="standard" range="pt50s"/> </xmas:monitor> <xmas:monitor xmlns:xlink=" <xmas:flash xlink:type="locator" xlink:href="${xdaq_setup_root}/ ${XDAQ_ZONE}/flash/dtsc-worker.flash#urn:xdaq-flashlist:dtsc-worker"/> <xmas:sampler tag="dtsc" type="urn:xmas-sampler:history" output="merge" format="standard" range="pt50s"/> </xmas:monitor> </xmas:sensor> dtsc-sensor.sensor dtsc-pulser.profile Per configurare il pulser del nostro sottosistema dobbiamo prima di tutto personalizzare il file di profilo di servizio dtsc-pulser.profile. L ultimo plugin di questo file crea l oggetto pulser. Ancora una volta la personalizzazione prevede che il valore dell attributo group corrisponda al nome del gruppo a cui il servizio fa capo. Oltre a questo è necessario che il tag item punti ad un file di configurazione, di estensione.pulser, che nel nostro caso ha nome dtsc.pulser <xp:application class="xmas::pulser::application" id="10" network="local" group="dtsc" service="pulser"> <properties xmlns="urn:xdaq-application:xmas::pulser::application" xsi:type="soapenc:struct"> <url xsi:type="soapenc:array" soapenc:arraytype="xsd:ur-type[1]"> <item xsi:type="xsd:string" soapenc:position="[0]">${xdaq_setup_root}/ ${XDAQ_ZONE}/pulser/dtsc.pulser</item> </url> <usediscovery xsi:type="xsd:boolean">true</usediscovery> </properties> </xp:application> dtsc-pulser.profile dtsc-pulser.pulser Il servizio pulser è configurato attraverso uno specifico file. I parametri da personalizzare in questo file sono gli attributi tag e xlink:href perchè i loro valori puntino al gruppo e alle flashlists appropriate. Può essere inoltre necessario personalizzare il valore degli attributi period e delay per gestire la frequenza delle richieste di aggiornamento inviate dal pulser. (Il delay non so ancora bene a cosa possa servire) 9

10 <xmas:pulser xmlns:xmas=" <xmas:event delay="pt1s" period="pt10s" xmlns:xlink=" <xmas:flash xlink:type="locator" tag="dtsc" xlink:href="#urn:xdaq-flashlist:dtsc-supervisor"/> </xmas:event> </xmas:pulser> dtsc.pulser MonitorSource.h Terminata la configurazione dei servizi che gestiscono il monitoring, l ultimo passo da effettuare è l aggiornamento del codice della cella che deve pubblicare i dati da monitorare. Per farlo bisogna creare una classe, derivata dalla classe di XDAQ DataSource, che esegua effettivamente il lavoro di aggiornamento di queste variabili. Nel nostro caso d esempio la classe derivata è stata chiamata MonitorSource. Nell header della classe va definito, oltre al costruttore e al distruttore, una funzione di refresh per ciascuna delle variabili da monitorare. class MonitorSource: public DataSource { public: MonitorSource(const std::string& infospacename, CellContext* context, log4cplus::logger& logger); private: void refreshitem1(const std::string& name, xdata::string& item); void refreshitem2(const std::string& name, xdata::integer& item); void refreshtable(const std::string& name, xdata::table& item); }; MonitorSource.h Ciò che è fondamentale è che il secondo argomento sia del tipo xdata::serializable corrispondente al tipo dichiarato nella flashlist. La lista di tali corrispondenze si può trovare nella tabella 3 del manuale di installazione del Trigger Supervisor. MonitorSource.cc Nel file sorgente andremo quindi a definire le funzioni dichiarate all interno dell header. Nel costruttore le operazioni fondamentali da effettuare sono la creazione delle variabili da monitorare tramite la funzione add e il refresh di queste variabili tramite la funzione autorefresh. E necessario che il tipo dichiarato nella funzione add sia del tipo xdata::serializable corrispondente al tipo dichiarato nella flashlist. É altresì necessario che la funzione invocata da autorefresh corrisponda alla opportuna funzione di refresh, dichiarata nell header. MonitorSource::MonitorSource(const std::string& infospacename, CellContext* context, log4cplus::logger& logger) :DataSource(infospaceName,context,logger) {//Monitoring example code add<xdata::string>("item1"); autorefresh("item1",this,&monitorsource::refreshitem1); add<xdata::integer>("item2"); autorefresh("item2",this,&monitorsource::refreshitem2); add<xdata::table>("table"); 10

11 autorefresh("table",this,&monitorsource::refreshtable); } MonitorSource.cc Completata la personalizzazione del costruttore dobbiamo personalizzare le varie funzioni di refresh che aggiornano la variabile da monitorare ogni qualvolta che il pulser invia il proprio segnale. In queste funzioni sarà inserito l algoritmo personalizzato che esegue sull hardware o su altre variabili le operazioni necessarie. CellContext.h Perchè questa classe venga effettivamente istanziata deve essere invocata all interno del Context dell applicazione. Per farlo dobbiamo innanzitutto modificare l header della classe CellContext. In questo file dobbiamo includere una dipendenza dal file MonitorSource.h, quindi creare un oggetto di tipo MonitorSource ed inserire una funzione che restituisca un handle dll oggetto di tipo MonitorSource. public: MonitorSource& getdatasource() {return *datasource_;}; private: MonitorSource* datasource_; CellContext.h CellContext.cc Per finire completeremo il setup del monitor aggiungendo nel codice sorgente della classe CellContext una chiamata nel costruttore che crei l oggetto di tipo MonitorSource con i parametri appropriati. Il parametro più importante, da personalizzare, è il nome della variabile infospace che deve corrispondere al valore dell attributo infospace presente nella flashlist datasource_ = new MonitorSource(" dtsc-supervisor", this, getlogger()); CellContext.cc 11

12 0.1 Creazione di variabili monitorabili In quest ultima sezione illustrerò il metodo, passo passo, per l aggiunta di una variabile monitorabile al sistema. Inseriremo, come esempio una variabile di tipo int, di nome Test, appartenente all infospace Test che ad ogni aggiornamento aumenterà di 1 il proprio valore. Modifica della Flashlist Il primo passo per effettuare l aggiunta di una variabile monitorabile al sistema del Trigger Supervisor è la modifica della flashlist con l aggiunta di un tag xmas:item che definisca la variabile globalmente all interno del tag xmas:flash. É importante accertarsi che non ci siano altre variabili con lo stesso nome già dichiarate all interno del gruppo. Nel caso della nostra variabile di prova questa riga sarà: <xmas:item name="test" infospace="test" type="int" /> Modifica di MonitorSource.h Completato l aggiornamento della flashlist è necessario aggiornare l header della classe MonitorSource aggiungendo la dichiarazione della funzione di refresh per la variabile aggiunta. Nel nostro esempio abbiamo: void refreshtest(const std::string& name, xdata::integer& item); Modifica di MonitorSource.cc Una volta aggiunta la dichiarazione nell header bisogna modificare il codice sorgente. Questa è la parte più importante e delicata dlel intero processo. Per prima cosa è necessario aggiungere nel costruttore due righe di codice: 1. Una chiamata alla funzione add perchè aggiunga la variabile da monitorare, avendo cura che il tipo della variabile aggiunta, derivato da xdata::serializable, corrisponda al tipo di quella dichiarata all interno della flashlist, secondo la tabella 3 del manuale di installazione del Trigger Supervisor 2. Una chiamata alla funzione autorefresh che faccia riferimento alla funzione il cui prototipo è stato inserito nell header nel passo precedente Nel nostro caso di test abbiamo: add<xdata::integer>("test"); autorefresh("test",this,&monitorsource::refreshtest); Bisogna poi definire la funzione di refresh il cui prototipo è stato dichiarato nell header. Nel nostro esempio la funzione aggiunge semplicemente 1 al valore contenuto precedentemente nella variabile void MonitorSource::refreshTest(const std::string& name, xdata::integer& item) { int actual = item; actual += 1; item = actual; } Compilazione e avvio Dopo aver completato questi passaggi è necessario ricompilare il codice della cella perchè venga aggiunta la variante della classe MonitorSource e riavviare tutti i servizi in modo che questi possano far capo alla nuova flashlist modificata. 12