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 Plan I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives

3 aujourd'hui hôpital

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 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 aujourd'hui données médicales grandes BD sensibles (sécurité, confidentialité) accès lecture seule traces à garder distribuées hôpital

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

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 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 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 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 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 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 ] -- 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 [ DCMTK [ PACS, et RIS.

15 1. Grilles de calcul Condor [Basney, HPCC99] Legion [Chapinand, JSSPP99] Globus [Foster et al, IJSAHPC97] LCG (DataGrid) [ 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 1. Grilles de calcul 2. Grilles d'internautes P2P: utilisé par la communité internaute [Buyya, GRID04] NAPSTER [ 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 Projet Grilles Médicales e-DIAMOND [ Mammogrid [McClatchey, CHEP03] 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 CORBA [ DCOM [ 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 I- Contexte et objectifs II- État de l'art III- Contributions IV- Conclusions et Perspectives Plan

20 Nos Travaux Datagrid MediGrid Ragtime

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

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 système distribué == {engines} U {machines} serveur application médicale app med client application médicale app med

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 Contributions

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 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 IPC messages réseau machines serveurs machines clientes

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

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}

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

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 )

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

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 DSE 0 DSE 2 DSE 1 - application - utilisateur 2- intergiciel - DSEM 3- applications -DM Architecture (couches d'application) DSE 3 {services} DSE 4 {interfaces}

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

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

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

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)

Intergiciel (DSEM) engine (serveur) engine (hôpital) execution time engine (hôpital)

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

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

Intergiciel (DSEM) MPK Multi-process QUD RQD

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}

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 }

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

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 DICOM SDR Métadonnées SDR MYSQL DCMTK DM 2 SDA DM 2 SDR Application (DM 2 - engine serveur - Hôpital) IRM

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

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

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

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

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 MYSQL DM 2 SDA Sécurité TOD DM 2 SDR DM Cas d'utilisation : 1- contrôle de sécurité Métadonnées SDR Métadonnées TDK

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

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

60 DICOM SDR GRILLE SDR MYSQL uGrid DM 2 SDA DM 2 SDR DM 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 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 DICOM SDR GRILLE SDR MYSQL uGrid DM 2 SDA GRILLE TKD DM 2 SDR DM Cas d'utilisation : 4-Calculs de similarité Métadonnées SDR Métadonnées TDK 60%

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

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 DM 2 SDR hôpital 5.1. Tests de performances (saturation des ressources) hôpital get image

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

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

Tests de performances (saturation)

Tests de performances (surcharge)

Tests de performances (charge aléatoire)

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 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 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 2D / 3D / 4D Data-centric ++ sécurité -- contraintes de puissance de calcul Modèle Processor-centric

75 Ce travail a bénéficié du soutien du : / projet IST European DataGrid / 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)