1 / 28

Candidato: E.Venturi 1

In collaborazione con.

bethan
Télécharger la présentation

Candidato: E.Venturi 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. In collaborazione con Università degli Studi di FirenzeFacoltà di IngegneriaCorso di Laurea in Ingegneria ElettronicaProgetto per l’ottimizzazione della macchina a stati di gestione di un contaglobuli con campionatore automatico e sviluppo e implementazione delle procedure operative per il controllo dello strumento di Emiliano Venturi Relatori: Prof. Guido Valli Prof. Silvano Dubini Dott. Angelo Manzoni Dott. Igor Betti Candidato: E.Venturi 1

  2. In collaborazione con Anteprima a MEDICA 2004 23 - 27 Novembre 2004 Dusseldorf, Germania WWW.SEACFI.COM Commercializzazione prevista Estate 2005 Candidato: E.Venturi 2

  3. OBIETTIVO: Scrivere il protocollo di comunicazione high-level che governa tutti gli automatismi del modulo campionatore (Sampler) in atto durante il processo di campionamento automatico In collaborazione con Candidato: E.Venturi 2

  4. In collaborazione con RICHIESTE INIZIALI  Progettare un software robusto in grado di gestire correttamente tutte le fasi di cui si sarebbe composto il campionamento in modalità automatica dello strumento HeCoSampler  Forzatamente, e in contemporanea alla richiesta precedente, mantenere la massima integrazione del software sviluppato con la piattaforma già esistente ed utilizzata anche in altri strumenti (HeCo, HeCoVET, Genius)  Produrre un risultato operativo valido nel minor tempo possibile affinchè la commercializzazione del prodotto possa iniziare a breve termine Candidato: E.Venturi 3

  5. In collaborazione con FASI DI LAVORO ASPETTI CENTRALI ALLA MACCHINA A STATI C1 Conoscenza piattaforma esistente C2 Individuazione Kernelsequenza di dialogo fra moduli C3 Definizione stati occorrenti (stati Wait, stati Occupati) C4 Implementazione singoli stati e derivazione MaS finale ASPETTI PERIFERICI ALLA MACCHINA A STATI P1 Decodifica codici a barre di rack e provette P2 Gestione lista di lavoro nel campionamento automatico Candidato: E.Venturi 4

  6. E’ comandato in tutte le sue azioni da un calcolatore esterno PCGest che funziona pure da interfaccia utente. L’unità operativa e di calcolo è composta da due schede. In collaborazione con C1 Conoscenza piattaforma esistente HeCoSampler CONDIZIONI OPERATIVE SCHEDE : RUN - WAIT - STOP Una scheda accetta un comando solo quando è in WAIT, indipendentemente dalla condizione dell’altra scheda. LIVELLI DI COMUNICAZIONE (1) high level fra i differenti moduli del software HeCoSampler (2) low level PCGest  Schede HeCo / Sampler Candidato: E.Venturi 5

  7. segnale • ACK (codice 06h) • NAK (codice 16h) |STX|stringa dati ASCII|ETX|CHECHSUM| forma compatta senza ‘,’ e ‘.’ (ETX precede CHECKSUM) In collaborazione con C1 Conoscenza piattaforma esistente (LIVELLO 2) comunicazione PCGest  Schede HeCo / Sampler comunicazione PCGest  Schede HeCo / Sampler 1. Comprensione del COMANDO 1. Invio di un COMANDO 2. Richiesta (polling) informazioni DATI o STATO 2. Fornitura informazioni richieste (DATI o STATO) Sintassi unica |STX|stringa dati ASCII|CHECKSUM|ETX| - STX (codice ASCII 02h) è il carattere (1 byte) inizio trasmissione stringa - STRINGA campo caratteri (ciascuno 1 byte) di lunghezza arbitraria. La ‘,’ separa campi semanticamente diversi. Il ‘.’ separa STRINGA da CHECKSUM - CHECKSUM è la somma senza riporto su 1 byte di tutti i byte trasmessi (esclusi le ‘,’ ed i caratteri STX, ETX). Effettua un controllo errore in trasmissione - ETX (codice ASCII 03h) è il carattere (1 byte) fine trasmissione stringa Candidato: E.Venturi 6

  8. In collaborazione con C1 Conoscenza piattaforma esistente (LIVELLO 2) Tutti i comandi sono composti da almeno due byte Code1 e Code2 - Code1 (bit 7 - bit 4)  individuano scheda con cui comunicare (max. 15; 0h se HeCo, 1h se Sampler) - Code1 (bit 3 - bit 0)  determinano n° parametri del comando (max. 15) - Code2 (bit 7 - bit 0)  determinano il comando da inviare (fino a 256 possibili diversi) Formato con cui avviene la comunicazione via seriale comando immediato Code1 Code2 PCGest: <STX>!1,25,3.68<ETX> Caso POLLING CORTO scheda: ACK scheda: <STX>1.49<ETX> = stato WAIT Le funzioni SetMacro, PrepareComand, SendMessage richiamate nel modulo Dispatcher per scrivere le varie ProceduraCaricaRack, ProceduraBarcode, ProceduraMiscelazione, ProceduraPosizionaN ecc. ‘impacchettano’ e spediscono il dato in questo formato Candidato: E.Venturi 6

  9. In collaborazione con C1 Conoscenza piattaforma esistente (LIVELLO 1) CM spetta il potere decisionale. Ogni operazione (proveniente da DISP) passa da CM; non inizia finchè CM non le comunica di poterlo fare. Quando finisce deve comunicare a CM la propria fine DdS gestisce l’interfaccia utente (aggiornamento video e Lista di lavoro, inserimento dati negli archivi anagrafica pazienti e risultati) DISP comunica direttamente con lo strumento (in esso scritte tutte le procedure che inviano comandi, effettuano polling, ricevono informazioni dalle schede dello strumento) Ipc unica mansione è permettere la comunicazione fra moduli. Ha gli strumenti per poterlo fare (funzioni ReadMsg e SendMsg) Candidato: E.Venturi 7

  10. ProcessMessage PUNTO D’INGRESSO AL MODULO SONO LE FUNZIONI DI DECODIFICA DI IPC_MSG CheckMessageFromcontrol OnIpc In collaborazione con C1 Conoscenza piattaforma esistente (LIVELLO 1) messaggio di comunicazione fra moduli puntatore e dimensione eventuali parametri passati distingue il mittente (modulo) del messaggio; rimasto per compatibilità (infatti messo sempre a DID_ALL) IPC_MSG msg(long i, DeviceId e, Action c, const char *d, size_t s) identificatore del messaggio (es. ipcmsg_CaricaRack ecc.) Comando, specifica l’azione che si vuol fare (es. ACT_DOING, ACT_STOP ecc.) spedizione messaggio ricezione messaggio Ipc->SendMsg(msg, IPC_CONTROLLO) Ipc->ReadMsg(msg) mex costruito con i canoni IPC_MSG Modulo destinatario del mex. (es. CM) Candidato: E.Venturi 7

  11. ProcessMessage PUNTO D’INGRESSO AL MODULO SONO LE FUNZIONI DI DECODIFICA DI IPC_MSG CheckMessageFromcontrol OnIpc In collaborazione con C1 Conoscenza piattaforma esistente (LIVELLO 1) Due modi di intervento nel software HeCoSampler: 1) inserimento procedura all’interno di modulo già esistente (in DISP e DdS) 2) creazione nuova classe (in CM) Candidato: E.Venturi 7

  12. In collaborazione con C2 Individuazione Kernel sequenza di dialogo fra moduli Le azioni di HeCoSampler sono le più svariate. Tuttavia, in base alla logica della ripartizione dei compiti, emerge una sequenza tipica di dialogo fra moduli. Usando questo kernel non vi è possibilità di conflitto Candidato: E.Venturi 8

  13. In collaborazione con C3 Definizione stati occorrenti (stati Wait, stati Occupati) Stato Pronta (SP): già definito. WAIT generico in modalità manuale STATI WAIT Stato auto (SA): WAIT generico in modalità automatica Stato ReadyForAuto (RFA): WAIT con rack in pancia. Già aggiornata Lista di Lavoro (LdL) 3 stati per : - distribuire correttamente il set operazioni (fra manuale & automatica) - gestire eventi esterni (Stop prematuro / errore improvviso) - sopperire alla mancanza sensore sul carrello mobile (es. Già rack in pancia.Se decido di reiniziare, non devo caricare un altro rack) Candidato: E.Venturi 9

  14. Stato Pronta (SP): già definito. WAIT generico in modalità manuale STATI WAIT Stato auto (SA): WAIT generico in modalità automatica Stato ReadyForAuto (RFA): WAIT con rack in pancia. Già aggiornata Lista di Lavoro (LdL) 3 stati per : - distribuire correttamente il set operazioni (fra manuale & automatica) - gestire eventi esterni (Stop prematuro / errore improvviso) - sopperire alla mancanza sensore sul carrello mobile (es. Già rack in pancia.Se decido di reiniziare, non devo caricare un altro rack) In collaborazione con C3 Definizione stati occorrenti (stati Wait, stati Occupati) OccupatoCaricaRack OccupatoLeggiBarcode Miscelazione divisione per tipo operazione STATI OCCUPATI PosizionaN AspiraElabora OccupatoScaricaRack StatoFerma Candidato: E.Venturi 9

  15. In collaborazione con C4 Implementazione singoli stati e derivazione MaS PUNTATOREALLO STATO: Es. Cassetti con arnesi da lavoro (pag. 84- 85) Inserire un nuovo stato vuol dire scrivere una nuova classe contenente le funzioni (ovvero gli arnesi) necessarie allo stato Kernel sequenza di dialogo Concetto PUNTATORE ALLO STATO +  Candidato: E.Venturi 10

  16. In collaborazione con C4 Implementazione singoli stati e derivazione MaS PUNTATOREALLO STATO: Es. Cassetti con arnesi da lavoro (pag. 84- 85) Inserire un nuovo stato vuol dire scrivere una nuova classe contenente le funzioni (ovvero gli arnesi) necessarie allo stato Kernel sequenza di dialogo Concetto PUNTATORE ALLO STATO +  Lo stato macchina è un ‘foglio’ di lavoro La MaS è un insieme di ‘fogli’ di lavoro contigui: garantita max. flessibilità Candidato: E.Venturi 10

  17. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/COccupatoCaricaRack) - i due indici (1,2 e 3,4) per distinguere il caricamento rack in un operazione singola da quello in un campionamento automatico - CaseStop interviene quando CM riceve ACT_STOP da DISP (fine procedura corrente) e fa partire ACT_DOING (ipcmsg_stato_successivo) a DISP (casi 3,4) - CaseDoing interviene durante lo stato per indicare errore occorso (casi 1,2) oppure quando DISP indica che procederà con lo stato successivo e quindi c’è da aggiornare DdS e lo stato macchina (casi 3,4) - SamplerStartStopButton è la funzione che aggiorna la volontà di stoppare il campionamento automatico (variabile Proseguimento settata a false) Candidato: E.Venturi 11

  18. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/COccupatoLeggiBarcode) - gli indici (1,2) come nel caso precedente; (3) per un’operazione singola; (4,5) possibilità nel campionamento automatico; (6) Stop - CaseStop (3,4,5) interviene come prima per segnale fine operazione (ACT_STOP da DISP) e segnale fine aggior. LdL (ACT_STOP da DdS) - CaseDone (3,4,5) interviene per fine trasferimento dati (ACT_DONE da DISP) - PollingDone (3,4,5,6) interviene per chiudere lo stato e passare al successivo dopo richiesta stato lungo (ACT_POLLING da DISP) - VerificaPazientiSampler (4,5) interviene dopo aggiornamento LdL. Se non ci sono pazienti da fare saltare subito a OccupatoScaricaRack - CaseDoing (1,2,4) interviene durante lo stato per indicare errore occorso oppure quando DISP indica che procederà con lo stato successivo e quindi c’è da aggiornare DdS e lo stato macchina - SamplerStartStopButton aggiorna var. Proseguimento in modo che a fine PollingDone si passi in RFA Candidato: E.Venturi 12

  19. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/COccupatoLeggiBarcode) Candidato: E.Venturi 12

  20. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/CAspiraElabora) - uso le funzioni in modo del tutto simile allo stato OccupatoLeggiBarcode - particolarità in più è che la riga SendStopToDialog(ipcmsg_Aspiraelabora) presente in ::Pollingdone manda in RipartiSuProvettasuccessiva di DdS da cui si può uscire con due possibili ACT_START a CM (ipcmsg_PosizionaN oppure ipcmsg_ScaricaRackARegime) che faranno partire le relative procedure nello stato AspiraElabora: ecco giustificata la presenza di ProceduraPosizionaN e ProceduraScaricaRackARegime Candidato: E.Venturi 13

  21. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/MaS soluzione finale) Candidato: E.Venturi 14

  22. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/MaS soluzione finale) Candidato: E.Venturi 14

  23. In collaborazione con C4 Implementazione singoli stati e derivazione MaS (/MaS soluzione finale) Candidato: E.Venturi 14

  24. In collaborazione con P1 Decodifica codici a barre rack/provette  DispatcherHeCo:: CheckDataFromSampler Stringa ritorno dal lettore barcode DataRcvFromSampler = “ 31 52 64 64 b0 b0 b0 ……….” I posti pari pesano 16 I posti dispari pesano 1 32 coppie hex “attaccate” per i 7 codici a barre Es. |3|1|  (3*16) + (1*1) = 49 decimale  carattere ‘1’ Il carattere (barra o spazio) letto dal lettore barcode sarà quello corrispondente il cui codice ASCII vale 49 b0h = 176 decimale corrisponde al carattere riempitivo ‘ ο’ Alla fine, i dati convertiti sono passati a CM che li spedisce a DdS Passaggio a CM: IPC_MSG msg(msg.id, DID_ALL, ACT_DONE, (const char*)&Dati_barcode, sizeof(Dati_barcode); ipc->SendMsg(msg, IPC_CONTROLLO); Candidato: E.Venturi 15

  25. In collaborazione con P2 Gestione lista di lavoro nel campionamento automatico  dialogodistatoHeCo::AggiornaDatiBarcode In CStringArray ho i 7 codici a barre (rack + 6 provette) PROVETTA NUOVA (oppure non letta)  accodata in lista e messa presente PROVETTA GIA’ IN LISTA  aggiorno il flag stato nel corrispettivo stato presente POSTO PIENO AGGIORNO I CAMPI POSIZIONE N.M Annullo gli stessi N.M delle vecchie provette che stavano sul rack attualmente presente sul carrello Con questa gestione passo dalla modalità aut./man. E viceversa accodando fra loro le liste. All’utente ciò può non interessare, potendo lui monitorare, lo stato provette attraverso la simbologia flag adottata. Simbologia (Vuoto = Assente, Pieno = Presente) Candidato: E.Venturi 16

  26. In collaborazione con P2 Gestione lista di lavoro nel campionamento automatico LdL in continua evoluzione perché l’utente può interagire Dopo lo stato AspiraElabora devo sapere cosa fare  dialogodistatoHeCo::RipartiSuProvettaSuccessiva sancisce cosa fare cuore è dialogodistatoHeCo::RicercaFlagDB  FILTRO sui pazienti (fra i presenti) data odierna & mod. AUTO  RICERCO provette NUOVE (flag stato_provetta_presente)  RICERCO provette in RILETTURA (flag stato_rileggi_presente OPPURE stato_rileggi_analizzato_presente)  me ne esco col puntatore alla posizione appena trovata Candidato: E.Venturi 16

  27. In collaborazione con P2 Gestione lista di lavoro nel campionamento automatico LdL in continua evoluzione perché l’utente può interagire Dopo lo stato AspiraElabora devo sapere cosa fare  dialogodistatoHeCo::RipartiSuProvettaSuccessiva sancisce cosa fare Candidato: E.Venturi 16

  28. In collaborazione con CONCLUSIONI Dal PUNTO DI VISTA AZIENDA il sw MANTIENE Assoluta integrabilità con la piattaforma esistente Assoluta indipendenza con hw e fw a disposizione (ogni eventuale cambiamento può incidere solo sui file di testo .prp contenenti le istruzioni macchina, vedi fig. 4.3) Facilità d’intervento a distanza per l’assistenza tecnica (semplice apertura file HeCo.ini, vedi fig. 4.2) mentre RISULTA Estremamente pulito e quindi di facile lettura specialmente nei punti d’ingresso ai vari moduli dove si decodifica il ipcmsg (ProcessMessage, CheckMessageFromControl, OnIpc) Al max della modularità e flessibilità: stravolgimenti strutturali (hw) sullo strumento possono comunque permettere un riutilizzo del software attraverso operazioni routinarie di cancellazione/inserimento/aggancio di nuovi stati Occupati Dal PUNTO DI VISTA UTENTEil sw RISULTA Estremamente robusto ed affidabile grazie alla modularità vista come suddivisione all’interno di moduli caratterizzanti di compiti specifici ed esclusivi Candidato: E.Venturi 17

More Related