• Non ci sono risultati.

3.3 Singola camera: sviluppo della parte software

3.3.3 Definizione delle sottofunzioni

Dato che il funzionamento del sistema complessivo prevede di gestire con- temporaneamente cinque unità diverse, si è deciso di sfruttare la possibilità di Labview di compattare interi ed estesi programmi in sottoprogrammi, detti subVI, facilmente inseribili in un unico programma VI. Per poter fare ciò occorre definire le variabili che il subVI riceve in ingresso e quelle che restituisce in uscita.

In particolare per la gestione del sistema totale si è ricorso a tre sottopro- grammi (o blocchi):

1. BLOCCO TARATURA: il primo blocco contiene al suo interno il codice per definire l’offset del sensore di pressione e le istruzioni per la gestione dei segnali di comando del motore, questo infatti implementa una comunicazione seriale per il controllo della posizione del motore tramite il comando “VISA resource name”. Questa procedura di setup preliminare è obbligatoria ai fini della simulazione; la procedura deve essere avviata prima di qualsiasi altra funzione: il motore parte dalla posizione di partenza e vi ritorna nel momento in cui la simulazione viene interrotta. L’icona mostrata in Figura 3.12, è il simbolo che si applica al subVI per il suo riconoscimento all’interno del programma.

Figura 3.12: L’icona del subVI ed i suoi collegamenti visibili nel Block Diagram di Labview.

2. BLOCCO SIMULAZIONE COMPLESSIVA: il secondo blocco è stato implementato per pilotare il motore sulla base delle caratteristiche del respiro autonomo e della pressione in arrivo dal ventilatore: prende in ingresso i valori di frequenza e tempo di inspirazione (espresso in termini di periodo e duty cycle), volume tidalico, CFR, compliance e posizione del motore. Il blocco riporta in uscita l’andamento del volume e del flusso rilevato. L’icona mostrata in Figura 3.13, è il simbolo che si applica al subVI per il suo riconoscimento all’interno del programma.

Figura 3.13: L’icona del subVI ed i suoi collegamenti visibili nel Block Diagram di Labview.

3. BLOCCO DI ESTRAZIONE PARAMETRI: l’ultimo blocco prende in ingresso la pressione dal ventilatore e dà in uscita i valori di PIP (cmH2O), PEEP (cmH2O), PIP-PEEP (cmH2O), MAP (cmH2O), fre-

quenza(rpm), tempo di inspirazione(s), tempo di espirazione(s), perio- do(s). La logica ed il codice utilizzato per tali estrapolazioni di dati sono quelli precedentemente descritti al termine del paragrafo 3.2.2. L’icona mostrata in Figura 3.14, è il simbolo che si applica al subVI per il suo riconoscimento all’interno del programma.

Figura 3.14: L’icona del subVI ed i suoi collegamenti visibili nel Block Diagram di Labview.

Capitolo 4

Sviluppo di un sistema

multicompartimentale a cinque

camere

4.1

Introduzione

Lo scopo della presente tesi, come già dichiarato, è quello di realizzare un simulatore respiratorio innovativo che replichi il sistema polmone neonatale sia dal punto di vista funzionale, che anatomico.

Come già descritto in dettaglio nel Capitolo 2, i polmoni sono percorsi da scissure, che li dividono in lobi; nel polmone destro abbiamo due scissure che lo dividono in tre lobi, superiore, medio e inferiore, mentre nel polmone sinistro abbiamo una sola scissura che lo divide in due lobi, superiore ed inferiore. Al fine di ottenere una rappresentazione ad alta fedeltà, nasce l’idea di estendere la struttura del primo prototipo ad una camera ad un prototipo a cinque camere, in grado quindi di simulare i tre lobi del polmone destro e i due lobi del polmone sinistro. Ogni camera è caratterizzata da una propria resistenza al flusso delle vie aeree ed una propria compliance che possono essere regolate in modo indipendente durante la simulazione. Grazie a questa soluzione il dispositivo risulta più accurato ed attendibile rispetto ai simulatori già esistenti, in quanto permette di delineare situazioni localizzate di barotrauma, ostruzioni e alterazioni.

I simulatori polmonari ad oggi disponibili permettono generalmente di effet- tuare solo un numero limitato di situazioni differenti, siano essi basati su modelli a singoli o doppi scomparti. Tuttavia, tali strutture non consentono una rappresentazione realistica di alcune condizioni fisiologiche e patologiche a cui il neonato può andare incontro, quali periodi di apnea, edemi localizzati

o barotrauma, ostruzioni di una particolare sezione della struttura delle vie aeree, ecc. Sia il simulatore neonatale attivo di Cappa (Cappa, 2002) sia altri simulatori disponibili in commercio, come il Ingmar modello polmonare adulto/pediatrico e il Ingmar ASL 5000 simulatore polmonare adulto/neonato, sono in grado di riprodurre i valori dei parametri della meccanica polmonare di neonati sani e patologici, consentono all’operatore di scegliere il modello respiratorio e continuamente regolare e controllare i parametri che caratteriz- zano il sistema polmonare. Tuttavia questi dispositivi considerano i polmoni come composti da due compartimenti omogenei, senza alcuna differenziazione in termini di compliance e di resistenza interna. Al contrario HALr S3010 di Gaumard è un modello di manichino realistico in grado di riprodurre sia la respirazione, sia le funzioni cardiovascolari e permette l’intubazione orale e nasale. Esso garantisce il controllo di frequenza e profondità della respirazione e permette di osservare le escursioni del torace, che sono sincronizzate con modelli di respirazione selezionabili, tuttavia la compliance non può essere regolata dall’operatore. Questo elemento di novità nel sistema, ovvero la progettazione di un sistema a cinque camere, ha comportato la replica dei componenti costituenti la parte hardware del sistema a singolo lobo e l’esten- sione del software ad essa connesso.

Nei paragrafi seguenti verranno affrontati gli aspetti relativi all’hardware e al software utilizzato, con una breve descrizione della sua struttura; il passo successivo è stato la stesura di un manuale con il quale guidare l’utente nella gestione del software per l’acquisizione e la visualizzazione dei dati, illustrando le problematiche che si possono riscontrare durante la simulazione. Il sistema segue lo schema generale delle architetture robotiche, come quello mostrato in Figura 4.1, in cui risulta chiaro che il simulatore non è qualcosa di isolato, ma è immerso in un ambiente col quale interagisce attraverso i suoi attuatori e dal quale riceve informazioni tramite i propri sensori. Tra sensori ed attuatori c’è un modulo molto importante che si occupa della pianificazione, la quale sostanzialmente modella il comportamento generale del sistema.

Figura 4.1: Schema tipico di un sistema robotico.