1 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.

Présentation au sujet: "1 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."— Transcription de la présentation:

1 1 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).

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

3 3 aujourd'hui hôpital

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

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

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

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

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

9 9 2D / 3D / 4D Grille 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 » haute performance traitement intensif des données grande capacité de stockage haut « throughput »

10 10 2D / 3D / 4D Grille 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 » haute performance traitement intensif des données grande capacité de stockage haut « throughput »

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

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

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

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

15 15 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]... ++ environnement contrôlé ++ authentification ++ support 24/7 II. État de l'art -- 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

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

17 17 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 II. État de l'art -- pas de grande échelle -- pas de séquences (3D/4D) d'images -- pas de requêtes hybrides distribuées

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

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

20 20 Nos Travaux Datagrid MediGrid Ragtime

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

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

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

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

25 25 Contributions

26 26 DSE 0 DSE 4 DSE 3 DSE 2 DSE 1 - échange de messages - distribution - application - transaction - utilisateur 2- intergiciel - DSEM 3- applications -DM 2 Niveau sémantique 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 Définition Verticale Définition Horizontale

27 27 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 Contributions

28 28 IPC messages réseau machines serveurs machines clientes

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

30 30 1.2 -Architecture (DSE 1 ) TOD TKD RQD QUD échange des transactions une query est un ensemble de tasks une task est un ensemble de requests une request est un ensemble de messages DSE 1 == {drivers}

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

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

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

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

35 35 DSE 0 DSE 2 DSE 1 - application - utilisateur 2- intergiciel - DSEM 3- applications -DM 2 1.4 -Architecture (couches d'application) DSE 3 {services} DSE 4 {interfaces}

36 36 1.5 -Architecture: Extensibilité: 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.) - 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 37 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 Contributions

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

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

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

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

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

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

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

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

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

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

48 48 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 Contributions

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

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

51 51 DICOM SDR MYSQL DCMTK DM 2 SDA DM 2 SDR 3.3 - Application (DM 2 - engine serveur - Hôpital) IRM segmentation interpolation calcul de fraction d’éjection Fraction d’éjection Métadonnées SDR

52 52 3.4 - Application (DM 2 - engine serveur) DICOM SDR GRILLE SDR MYSQL Spitfire uGrid CTN DCMTK DM 2 SDA BD hôpital DM 2 SDR Métadonnées SDR

53 53 3.4 - Application (DM 2 - server engine) DICOM SDR MYSQL Spitfire uGrid CTN DCMTK DM 2 SDA BD DM 2 SDR similarité 1 similarité 2 hôpital Métadonnées SDR GRILLE SDR

54 54 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 Contributions

55 55 4.1- DM 2 engine (Hôpital Cardiologique de Lyon) fraction d’éjection segmentation interpolation calcul

56 56 médecin 4.2- Cas d'utilisation : Un médecin demande au DM 2 de lui trouver toutes les images similaires à une image de référence, avec une F.E > 50%

57 57 MYSQL DM 2 SDA Sécurité TOD DM 2 SDR DM 2 4.2. Cas d'utilisation : 1- contrôle de sécurité Métadonnées SDR Métadonnées TDK

58 58 MYSQL DM 2 SDA Sécurité TOD DM 2 SDR DM 2 4.2. Cas d'utilisation : 1- contrôle de sécurité, 2- consultation du cache Cache TOD Métadonnées SDR Métadonnées TDK

59 59 EF>0.5 4.3. Cas d'utilisation : 3-Requête distribuée pour récupérer des images comparables (FE > 50%) métadonnées précalculées

60 60 DICOM SDR GRILLE SDR MYSQL uGrid DM 2 SDA DM 2 SDR DM 2 4.3. Cas d'utilisation : 3-Requête distribuée pour récupérer des images comparables (FE>0.5) - localisation - transfert Métadonnées SDR Métadonnées TDK

61 61 Grille scores de similarité = {1, 0.5, 0.1} image de référence calcul FE>50% métadonnées précalculées 4.4- Cas d'utilisation : 4-Calculs de similarité comparaison

62 62 DICOM SDR GRILLE SDR MYSQL uGrid DM 2 SDA GRILLE TKD DM 2 SDR DM 2 4.5. Cas d'utilisation : 4-Calculs de similarité Métadonnées SDR Métadonnées TDK 60%

63 63 DICOM SDR GRILLE SDR MYSQL uGrid DM 2 SDA GRILLE TKD DM 2 SDR DM 2 4.5. Cas d'utilisation : 4-Calculs de similarité Métadonnées SDR Métadonnées TDK

64 64 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 Contributions

65 65 DM 2 SDR hôpital 5.1. Tests de performances (saturation des ressources) hôpital get image

66 66 DM 2 SDR hôpital 5.2. Tests de performances (surcharge des ressources) hôpital get image

67 67 DM 2 SDR hôpital 5.3. Tests de performances (charge aléatoire) hôpital t=0 t=1 t=n

68 68 5.4. Tests de performances (saturation)

69 69 5.5. Tests de performances (surcharge)

70 70 5.6. Tests de performances (charge aléatoire)

71 71 Conclusion " Nous avons proposé une architecture multicouche (DSE) pour concevoir des systèmes distribués. " Nous avons développé un système complet, depuis les couches systèmes les plus basses (intergiciel DSEM) jusqu'à l'utilisateur (application DM 2 ). " Les engines constituent une brique fonctionnelle permettant de concevoir des applications réparties

72 72 Perspectives " Adaptation du système DSEM/DM 2 à un environnement réel d'utilisation pour les hôpitaux " Intégration avec EGEE, et systèmes de cache et de sécurité " Adaptation de l'architecture aux grilles basées sur les données (datacentric [skillicorn, Queens Univ, 2001]).

73 73 2D / 3D / 4D Datacentric Par conséquent, conduire le logiciel vers les données au lieu de conduire les données vers le logiciel “ D. Skillicorn”. Grilles pour le traitement intensif des données. Inverse de point de vue traditionnel selon lequel les processeurs sont les ressources critiques, et donc, que les données doivent être transmises aux processeurs.

74 74 2D / 3D / 4D Data-centric ++ sécurité -- contraintes de puissance de calcul Modèle Processor-centric

75 75 Ce travail a bénéficié du soutien du : / projet IST European DataGrid www.edg.org / Ministère Français de la Recherche à travers le projet ACI-GRID (MEDIGRID) www-sop.inria.fr/aci/grid/public / Région Rhône-Alpes projet RAGTIME / Comité ECOS-Nord (action C03S02)