1 / 75

Hector DUQUE

Conception et mise en œuvre d'un environnement logiciel de manipulation et d'accès à des données réparties. (Application aux grilles d'images médicales: Le système DSEM/DM2). Hector DUQUE. Plan. I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives.

carol
Download Presentation

Hector DUQUE

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. Conception et mise en œuvre d'un environnement logiciel de manipulation et d'accès à des données réparties. (Application aux grilles d'images médicales: Le système DSEM/DM2). Hector DUQUE

  2. Plan I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives

  3. aujourd'hui hôpital hôpital hôpital

  4. nom, sexe, région N IRM (Imagerie par Résonance Magnétique) 1 fichier DICOM = métadonnées + image Séquence d'images 3D / temporelles

  5. DICOM DICOM DICOM hôpital nom, sexe, région N DICOM Raid 5 serveur DICOM(CTN / DCMTK) 1 client DICOM DICOM IRM fichier DICOM = métadonnées + image Séquence d'images 3D / temporelles

  6. aujourd'hui données médicales distribuées hôpital grandes BD sensibles (sécurité,confidentialité) hôpital traces à garder hôpital accès lecture seule

  7. haute performance traitement intensif des données demain grande capacité de stockage haut « throughput » distribution, grande échelle 2D / 3D / 4D

  8. haute performance traitement intensif des données demain grande capacité de stockage haut « throughput » distribution, grande échelle 2D / 3D / 4D service de requêtes basées sur le contenu calcul

  9. haute performance Grille traitement intensif des données grande capacité de stockage haut « throughput » 2D / 3D / 4D Grille : un type de système réparti et parallèle qui permet le partage, la sélection et l'aggrégation de ressources géographiquement distribuées « R. Buyya »

  10. haute performance Grille traitement intensif des données grande capacité de stockage haut « throughput » 2D / 3D / 4D Grille : un type de système réparti et parallèle qui permet le partage, la sélection et l'aggrégation de ressources géographiquement distribuées « R. Buyya »

  11. haute performance Grille traitement intensif des données grande capacité de stockage haut « throughput » image de référence (utilisateur) Fraction d’éjection FE > 50% métadonnéesprécalculées comparaison calcul scores de similarité = {1, 0.5, 0.1}

  12. objectif: haute performance Grille traitement intensif des données grande capacité de stockage haut « throughput » accès au données distantes grandes BD externes sensibles (sécurité,confidentialité) trace à garder requête hybride calcul scores de similarité = {1, 0.5, 0.1}

  13. Plan I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives

  14. II. État de l'art Hôpital: DICOM [National Electric M. Asoc, 2001] • CTN [www.erl.wustl.edu] • DCMTK [www.offis.uni-oldenburg.de] • PACS, et RIS. ++ bien intégré dans la pratique clinique -- pas interopérable -- limité à l'intérieur de l'hôpital -- pas interconnecté aux ressources de calcul

  15. II. État de l'art 1. Grilles de calcul • Condor [Basney, HPCC99] • Legion [Chapinand, JSSPP99] • Globus [Foster et al, IJSAHPC97] • LCG (DataGrid) [http://lcg.web.cern.ch/LCG/] • SRB (stockage) [Rajasekar, CSIJ03] ... -- pas adapté aux spécificités des applications médicales -- pas d'interface avec les serveurs de données médicales -- gestion de fichiers, mais pas de structures de données plus complexes ++ environnement contrôlé ++ authentification ++ support 24/7

  16. II. État de l'art 1. Grilles de calcul 2. Grilles d'internautes P2P: utilisé par la communité internaute [Buyya, GRID04] • NAPSTER [www.napster.com] • CHORD [Stoika, MIT02] -- environnement non contrôlé -- très volatile -- faible sécurité ++ très grande échelle ++ gestion de fichiers distribués

  17. II. État de l'art Projet Grilles Médicales • e-DIAMOND [www.ediamond.ox.ac.uk] • Mammogrid [McClatchey, CHEP03] • DISMEDI [www.medicaltech.org/dismedi] ++ utilise BD distribuées, traitement des images, technologie DICOM, interaction avec les grilles de calcul -- pas de grande échelle -- pas de séquences (3D/4D) d'images -- pas de requêtes hybrides distribuées

  18. II. État de l'art Architectures • CORBA [www.omg.org] • DCOM [www.microsoft.com/com] ++ définition standard d'interopérabilité ++ définition conceptuelle des systèmes distribués -- pas de définition architecturale de chaque élément du système distribué -- pas de haute performance et de traitement intensif des données.

  19. Plan I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives

  20. Nos Travaux • Datagrid • MediGrid • Ragtime

  21. système distribué == {engines} U {machines} machine engine engine machine engine engine engine engine machine machine

  22. engine - Composant complexe constitué d'un ensemble de processus locaux indépendants - « Brique » fonctionnelle pour construire des systèmes distribués (SD) machine engine engine machine engine engine engine engine machine machine

  23. système distribué == {engines} U {machines} client application médicale app med app med serveur application médicale app med

  24. système distribué == {engines} U {machines} Grille client application médicale serveur DICOM app med app med serveur application médicale app med IRM serveur Base de Données

  25. Contributions

  26. 1-DSE Distributed Systems Engines (architecture multicouche) 1- définition d'une architecture multicouche 2- implémentation de la couche intergicielle 3- implémentation de la couche d'application DSE4 - utilisateur 3- applications -DM2 DSE3 -application DSE2 Définition Verticale -distribution 2-intergiciel -DSEM Niveau sémantique DSE1 -transaction - échange de messages DSE0 Définition Horizontale

  27. Contributions 1- définition d'une architecture multicouche 2- implémentation de la couche intergicielle 3- implémentation de la couche d'application 4- cas d'utilisation médicale 5- tests de performances

  28. machines clientes messages réseau IPC IPC messages réseau machines serveurs

  29. 1.1 -Architecture (DSE0) NIIO IIO noyau d’échange des messages (MPK) IIIO IINO DSE0 == {processus} U MPK

  30. 1.2 -Architecture (DSE1) QUD TOD échange des transactions TKD RQD une query est un ensemble de tasks une taskest un ensemble de requests une request est un ensemble demessages DSE1 == {drivers}

  31. 1.2 -Architecture (DSE1) Grille QUD TOD Grille échange des transactions Proc Images TKD RQD DICOM DICOM Engine Grille

  32. 1.2 -Architecture (DSE1) qu: Compare (img1, imag2) tk: get (img1, img2) localize (img) check cache (img1, imag2) rq tk get (img1, imag2) rq rq tk pull (img1) pull (img2) msg: DICOM

  33. ORACLE 1.3 -Architecture (DSE2) SDA TOOLS Cache SDR MYSQL DSE2 == {Tools} U {service daemons} U {service drivers}

  34. ORACLE 1.3 -Architecture (DSE2) SDA TOOLS Requêtes Hybrides Cache Bases de Données SDR MYSQL DSE2 == {Tools} U {service daemons} U {service drivers}

  35. 1.4 -Architecture (couches d'application) - utilisateur DSE4 <==> {interfaces} 3- applications -DM2 - application DSE3 <==> {services} DSE2 2- intergiciel -DSEM DSE1 DSE0

  36. 1.5 -Architecture: Modularité : - définition de nouveaux QUD ==> services plus complets (i.e. différents protocoles d'accès) - définition de nouveaux SDA ==> plus de services (i.e. stockage de métadonnées, requêtes par le contenu, etc.) - définition de nouveaux RQD et SDR ==> permettent d'avoir accès à des services externes (i.e. Grille, DICOM, DB, etc.) Extensibilité: - plus de SDR concurrents permettent d'accéder à PLUS de ressources externes - plus d'instances de « drivers » permettent de gérer plus de transactions concurrentes

  37. Contributions 1- définition d'une architecture multicouche 2- implémentation de la couche intergicielle 3- implémentation de la couche d'application 4- cas d'utilisation médicale 5- tests de performances

  38. Dispatcher 2.2 - Intergiciel (DSEM) Engine Dispatcher conf file1: = {list QUD, TKD, RQD, TOD}

  39. Dispatcher Dispatcher 2.2 - Intergiciel (DSEM) conf file1: = {list QUD, TKD, RQD, TOD} conf file2: = {list QUD, TKD, RQD, TOD}

  40. Dispatcher Dispatcher 2.2 - Intergiciel (DSEM) conf file1: = {list QUD, TKD, RQD, TOD} conf file2: = {list QUD, TKD, RQD, TOD} engine (serveur) engine (hôpital) engine (hôpital)

  41. 2.2 - Intergiciel (DSEM) execution time engine (serveur) engine (hôpital) engine (hôpital)

  42. 2.2 - Intergiciel (DSEM) execution time engine (serveur) Grille DICOM BD engine (hôpital) engine (hôpital) IRM IRM IRM

  43. engine (serveur) engine (serveur) Grille DICOM BD engine (hôpital) engine (hôpital) IRM IRM IRM

  44. 2.2 - Intergiciel (DSEM) Multi-process QUD MPK RQD

  45. {query A: if <cond 1>; then exec task1 elseif <cond2>; then exec task2 fi exec task3} 2.2 - Intergiciel (DSEM) Traitement des transactions Driver générique RQD Application = {transactions}

  46. 2.2 - Intergiciel (DSEM) qu: Compare (img1, imag2) { check cache (img1, img2) get (img1, img2) } tk: get (img1, imag2) { localize (img) pull (img1) // pull (img2) } QUD Driver générique TKD RQD rq: pull (img) { DICOM messages }

  47. 2.2 - Intergiciel (DSEM) qu: Compare (img1, imag2) { check cache (img1, img2) get (img1, img2) } tk: get (img1, imag2) { localize (img) pull (img1) // pull (img2) } QUD Driver générique Application = qu: compare, tk: check cache, tk: get, rq: localize, rq: pull, TKD RQD rq: pull (img) { DICOM messages }

  48. Contributions 1- définition d'une architecture multicouche 2- implémentation de la couche intergicielle 3- implémentation de la couche d'application 4- cas d'utilisation médicale 5- tests de performances

  49. 3.2 -Distributed Medical Data Manager (DM2) « permet d'offrir un service de requêtes hybrides sur des images médicales » DM2 = { transactions( DICOM, Grille, Cache, Bases de Données, Manipulation des images, Application des algorithmes de traitement des images ) }

  50. 3.3 - Application (DM2 - engine serveur - Hôpital) DM2 SDA DICOM SDR Métadonnées SDR DM2 SDR MYSQL DCMTK IRM

More Related