Calcolo della posizione di reti di stazioni permanenti

Con il trascorrere del tempo, le reti di stazioni permanenti GNSS (Global Navigation Satellite System) divengono sempre più un valido supporto alle tecniche di rilevamento satellitare. Esse sono al tempo stesso un’efficace materializzazione del sistema di riferimento e un utile ausilio ad applicazioni di rilevamento topografico e di monitoraggio per il controllo di deformazioni. Alle ormai classiche applicazioni statiche in post-processamento, si affiancano le misure in tempo reale sempre più utilizzate e richieste dall’utenza professionale. In tutti i casi risulta molto importante la determinazione di coordinate precise per le stazioni permanenti, al punto che si è deciso di effettuarla tramite differenti ambienti di calcolo. Sono stati confrontati il Bernese, il Gamit (che condividono l’approccio differenziato) e il Gipsy (che utilizza l’approccio indifferenziato). L’uso di tre software ha reso indispensabile l’individuazione di una strategia di calcolo comune in grado di garantire che, i dati ancillari e i parametri fisici adottati, non costituiscano fonte di diversificazione tra le soluzioni ottenute. L’analisi di reti di dimensioni nazionali oppure di reti locali per lunghi intervalli di tempo, comporta il processamento di migliaia se non decine di migliaia di file; a ciò si aggiunge che, talora a causa di banali errori, oppure al fine di elaborare test scientifici, spesso risulta necessario reiterare le elaborazioni. Molte risorse sono quindi state investite nella messa a punto di procedure automatiche finalizzate, da un lato alla preparazione degli archivi e dall’altro all’analisi dei risultati e al loro confronto qualora si sia in possesso di più soluzioni. Dette procedure sono state sviluppate elaborando i dataset più significativi messi a disposizione del DISTART (Dipartimento di Ingegneria delle Strutture, dei Trasporti, delle Acque, del Rilevamento del Territorio - Università di Bologna). E’ stato così possibile, al tempo stesso, calcolare la posizione delle stazioni permanenti di alcune importanti reti locali e nazionali e confrontare taluni fra i più importanti codici scientifici che assolvono a tale funzione. Per quanto attiene il confronto fra i diversi software si è verificato che: • le soluzioni ottenute dal Bernese e da Gamit (i due software differenziati) sono sempre in perfetto accordo; • le soluzioni Gipsy (che utilizza il metodo indifferenziato) risultano, quasi sempre, leggermente più disperse rispetto a quelle degli altri software e mostrano talvolta delle apprezzabili differenze numeriche rispetto alle altre soluzioni, soprattutto per quanto attiene la coordinata Est; le differenze sono però contenute in pochi millimetri e le rette che descrivono i trend sono comunque praticamente parallele a quelle degli altri due codici; • il citato bias in Est tra Gipsy e le soluzioni differenziate, è più evidente in presenza di determinate combinazioni Antenna/Radome e sembra essere legato all’uso delle calibrazioni assolute da parte dei diversi software. E’ necessario altresì considerare che Gipsy è sensibilmente più veloce dei codici differenziati e soprattutto che, con la procedura indifferenziata, il file di ciascuna stazione di ciascun giorno, viene elaborato indipendentemente dagli altri, con evidente maggior elasticità di gestione: se si individua un errore strumentale su di una singola stazione o se si decide di aggiungere o togliere una stazione dalla rete, non risulta necessario il ricalcolo dell’intera rete. Insieme alle altre reti è stato possibile analizzare la Rete Dinamica Nazionale (RDN), non solo i 28 giorni che hanno dato luogo alla sua prima definizione, bensì anche ulteriori quattro intervalli temporali di 28 giorni, intercalati di sei mesi e che coprono quindi un intervallo temporale complessivo pari a due anni. Si è così potuto verificare che la RDN può essere utilizzata per l’inserimento in ITRF05 (International Terrestrial Reference Frame) di una qualsiasi rete regionale italiana nonostante l’intervallo temporale ancora limitato. Da un lato sono state stimate le velocità ITRF (puramente indicative e non ufficiali) delle stazioni RDN e, dall’altro, è stata effettuata una prova di inquadramento di una rete regionale in ITRF, tramite RDN, e si è verificato che non si hanno differenze apprezzabili rispetto all’inquadramento in ITRF, tramite un congruo numero di stazioni IGS/EUREF (International GNSS Service / European REference Frame, SubCommission for Europe dello International Association of Geodesy).

Connessione di sitemi a microcontrollore con reti geografiche

Fra le varie ragioni della crescente pervasività di Internet in molteplici settori di mercato del tutto estranei all’ICT, va senza dubbio evidenziata la possibilità di creare canali di comunicazione attraverso i quali poter comandare un sistema e ricevere da esso informazioni di qualsiasi genere, qualunque distanza separi controllato e controllore. Nel caso specifico, il contesto applicativo è l’automotive: in collaborazione col Dipartimento di Ingegneria Elettrica dell’Università di Bologna, ci si è occupati del problema di rendere disponibile a distanza la grande quantità di dati che i vari sotto-sistemi componenti una automobile elettrica si scambiano fra loro, sia legati al tipo di propulsione, elettrico appunto, come i livelli di carica delle batterie o la temperatura dell’inverter, sia di natura meccanica, come i giri motore. L’obiettivo è quello di permettere all’utente (sia esso il progettista, il tecnico riparatore o semplicemente il proprietario) il monitoraggio e la supervisione dello stato del mezzo da remoto nelle sue varie fasi di vita: dai test eseguiti su prototipo in laboratorio, alla messa in strada, alla manutenzione ordinaria e straordinaria. L’approccio individuato è stato quello di collezionare e memorizzare in un archivio centralizzato, raggiungibile via Internet, tutti i dati necessari. Il sistema di elaborazione a bordo richiede di essere facilmente integrabile, quindi di piccole dimensioni, e a basso costo, dovendo prevedere la produzione di molti veicoli; ha inoltre compiti ben definiti e noti a priori. Data la situazione, si è quindi scelto di usare un sistema embedded, cioè un sistema elettronico di elaborazione progettato per svolgere un limitato numero di funzionalità specifiche sottoposte a vincoli temporali e/o economici. Apparati di questo tipo sono denominati “special purpose”, in opposizione ai sistemi di utilità generica detti “general purpose” quali, ad esempio, i personal computer, proprio per la loro capacità di eseguire ripetutamente un’azione a costo contenuto, tramite un giusto compromesso fra hardware dedicato e software, chiamato in questo caso “firmware”. I sistemi embedded hanno subito nel corso del tempo una profonda evoluzione tecnologica, che li ha portati da semplici microcontrollori in grado di svolgere limitate operazioni di calcolo a strutture complesse in grado di interfacciarsi a un gran numero di sensori e attuatori esterni oltre che a molte tecnologie di comunicazione. Nel caso in esame, si è scelto di affidarsi alla piattaforma open-source Arduino; essa è composta da un circuito stampato che integra un microcontrollore Atmel da programmare attraverso interfaccia seriale, chiamata Arduino board, ed offre nativamente numerose funzionalità, quali ingressi e uscite digitali e analogici, supporto per SPI, I2C ed altro; inoltre, per aumentare le possibilità d’utilizzo, può essere posta in comunicazione con schede elettroniche esterne, dette shield, progettate per le più disparate applicazioni, quali controllo di motori elettrici, gps, interfacciamento con bus di campo quale ad esempio CAN, tecnologie di rete come Ethernet, Bluetooth, ZigBee, etc. L’hardware è open-source, ovvero gli schemi elettrici sono liberamente disponibili e utilizzabili così come gran parte del software e della documentazione; questo ha permesso una grande diffusione di questo frame work, portando a numerosi vantaggi: abbassamento del costo, ambienti di sviluppo multi-piattaforma, notevole quantità di documentazione e, soprattutto, continua evoluzione ed aggiornamento hardware e software. È stato quindi possibile interfacciarsi alla centralina del veicolo prelevando i messaggi necessari dal bus CAN e collezionare tutti i valori che dovevano essere archiviati. Data la notevole mole di dati da elaborare, si è scelto di dividere il sistema in due parti separate: un primo nodo, denominato Master, è incaricato di prelevare dall’autovettura i parametri, di associarvi i dati GPS (velocità, tempo e posizione) prelevati al momento della lettura e di inviare il tutto a un secondo nodo, denominato Slave, che si occupa di creare un canale di comunicazione attraverso la rete Internet per raggiungere il database. La denominazione scelta di Master e Slave riflette la scelta fatta per il protocollo di comunicazione fra i due nodi Arduino, ovvero l’I2C, che consente la comunicazione seriale fra dispositivi attraverso la designazione di un “master” e di un arbitrario numero di “slave”. La suddivisione dei compiti fra due nodi permette di distribuire il carico di lavoro con evidenti vantaggi in termini di affidabilità e prestazioni. Del progetto si sono occupate due Tesi di Laurea Magistrale; la presente si occupa del dispositivo Slave e del database. Avendo l’obiettivo di accedere al database da ovunque, si è scelto di appoggiarsi alla rete Internet, alla quale si ha oggi facile accesso da gran parte del mondo. Questo ha fatto sì che la scelta della tecnologia da usare per il database ricadesse su un web server che da un lato raccoglie i dati provenienti dall’autovettura e dall’altro ne permette un’agevole consultazione. Anch’esso è stato implementato con software open-source: si tratta, infatti, di una web application in linguaggio php che riceve, sotto forma di richieste HTTP di tipo GET oppure POST, i dati dal dispositivo Slave e provvede a salvarli, opportunamente formattati, in un database MySQL. Questo impone però che, per dialogare con il web server, il nodo Slave debba implementare tutti i livelli dello stack protocollare di Internet. Due differenti shield realizzano quindi il livello di collegamento, disponibile sia via cavo sia wireless, rispettivamente attraverso l’implementazione in un caso del protocollo Ethernet, nell’altro della connessione GPRS. A questo si appoggiano i protocolli TCP/IP che provvedono a trasportare al database i dati ricevuti dal dispositivo Master sotto forma di messaggi HTTP. Sono descritti approfonditamente il sistema veicolare da controllare e il sistema controllore; i firmware utilizzati per realizzare le funzioni dello Slave con tecnologia Ethernet e con tecnologia GPRS; la web application e il database; infine, sono presentati i risultati delle simulazioni e dei test svolti sul campo nel laboratorio DIE.

Sviluppo e validazione sperimentale di strategie di previsione e controllo del fenomeno della preaccensione (Mega-Knock)

L’algoritmo per la previsione del Mega-Knock si inserisce all’interno di uno dei temi cardine dell’attuale ricerca nel campo motoristico: la minimizzazione del consumo di combustibile nei motori ad alto grado di sovralimentazione, sviluppati nell’ottica del downsizing. La possibilità di prevedere l’innescarsi del Mega-Knock consente di ottimizzare la definizione dell’obiettivo di titolo, evitando arricchimenti non necessari in un range di funzionamento del motore che frequentemente viene esplorato nella normale guida su strada. Si tratterà la possibilità di utilizzare una relazione empirica per cercare di arrivare alla previsione dell’insorgere della preaccensione, per poi ricorrere ad opportune strategie motore per evitare il verificarsi del fenomeno; il tutto tramite lo sviluppo di un algoritmo in ambiente MatLab-Simulink

I risultati italiani e ticinesi nelle prove di Matematica Ocse-Pisa a confronto

Perchè, nelle competenze di matematica, i risultati riportati dagli studenti della Svizzera Italiana sono migliori di quelli dell'Italia? Domanda interessante in quanto nei due Paesi confinanti si utilizza la stessa lingua e in più molti italiani, lasciano l'Italia per trasferirsi in Ticino, una realtà quindi con cui l'Italia si confronta. Vengono presi in considerazione vari aspetti per cercare di dare una risposta.

Innovazione e governance delle reti di assistenza integrate: il caso delle cure palliative

In ambito oncologico il dolore affligge la maggior parte dei pazienti (incidenza riportata dal 53 al 90%), in tutte le fasi della malattia: nonostante l’esistenza di Linee Guida (OMS), l’attuale “undertreatment” del sintomo dolore oncologico, legato a un inappropriato uso degli oppioidi, in Italia raggiunge stime fino al 40% dei casi. Segnalazioni recenti sul consumo degli oppioidi in Italia riportano un aumento imputabile a un solo farmaco (fentanil TTS), il che suggerisce un comportamento prescrittivo inappropriato. Letteratura in merito alle valutazioni di efficacia delle terapie di controllo del dolore sia in fase iniziale – quando la terapia medica oncologica è attiva- sia in fase avanzata di malattia – quando il controllo del dolore si configura come una delle principali terapie di supporto- è ormai disponibile , con un buon livello di affidabilità. Quello che è necessario è aumentare la capacità del Servizio Sanitario di trasferire nella pratica clinica e assistenziale i risultati della ricerca sulla efficacia delle cure. Questi i quesiti ai quali la ricerca ha inteso rispondere: a. Le competenze globalmente espresse dal servizio sanitario dell’Emilia Romagna sono adeguate per consentire un tempestivo, globale, appropriato ed efficace controllo del dolore oncologico, in tutte le fasi della malattia e lungo tutto il percorso di assistenza si a domiciliare che ospedaliero, per tutti i malati che ne hanno bisogno? b. Quali raccomandazioni possiamo fornire, basate sulle evidenze di efficacia, a clinici e gestori per migliorare l’identificazione del bisogno, la scelta del trattamento, il suo monitoraggio, la possibilità di garantirne l’accesso e la disponibilità non solo in ospedale ma anche a domicilio? c. Quale efficacia hanno dimostrato i percorsi di formazione relativi al riconoscimento e al controllo del dolore messi in atto finora? d. Quali percorsi possono essere raccomandati per mettere a disposizione dei cittadini le conoscenze scientifiche sul controllo del dolore oncologico?

Analisi dei difetti in getti di GJS400 come supporto al controllo qualità

Analisi dell'incidenza di porosità interne sul limite di fatica di particolari getti di ghisa. Studio sviluppato grazie alla tecnica probabilistica "extreme value analysis".