Un outil d`aide au dimensionnement et à la planification des

Transcription

Institut
Supérieur d’
Informatique de
Modélisation et de leurs
Applications
Complexe des Cézeaux
BP 125
63173 Aubière CEDEX
Rapport de projet de troisième année
Filière Calcul et Modélisation Scientifiques
Un outil d’aide au dimensionnement
et à la planification des blocs opératoires
du Nouvel Hôpital d’Estaing
Présenté par
: Rudi Helfenstein, Julien Schueller jeudi, 19 mars 2009
Responsables ISIMA : Michel Gourgand, Sophie Rodier durée : 120h
Institut
Supérieur d’
Informatique de
Modélisation et de leurs
Applications
Complexe des Cézeaux
BP 125
63173 Aubière CEDEX
Rapport de projet de troisième année
Filière Calcul et Modélisation Scientifiques
Un outil d’aide au dimensionnement
et à la planification des blocs opératoires
du Nouvel Hôpital d’Estaing
Présenté par
: Rudi Helfenstein, Julien Schueller jeudi, 19 mars 2009
Responsables ISIMA : Michel Gourgand, Sophie Rodier durée : 120h
Un outil d’aide au dimensionnement et à la planification des blocs opératoires du N.H.E.
Remerciements
Nous tenons à remercier nos responsables de projet Michel Gourgand et Sophie Rodier pour leurs conseils
prodigués au fur et à mesure de l’avancement du projet.
Table des figures
1
2
3
4
5
6
7
Diagramme de classes du problème de planification . .
Planification hebdomadaire de 59 opérations . . . . . .
Planification hebdomadaire de 100 opérations . . . . .
Planification hebdomadaire de 198 opérations . . . . .
Planification hebdomadaire dans des salles spécialisées
Planification hebdomadaire dans un mélange de salles .
Planification hebdomadaire dans des salles polyvalentes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
11
12
13
14
15
16
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Planification sur 12 opérations, en 600 secondes . . . . . . . . . . . . . . . . . . . . .
Planification de 20 opérations, en 600 secondes . . . . . . . . . . . . . . . . . . . . .
Planification de 39 opérations en 600 secondes . . . . . . . . . . . . . . . . . . . . .
Planification de 39 opérations en 600 secondes, avec prise en compte des chirurgiens .
Planification de 39 opérations en 600 secondes, salles spécialisées . . . . . . . . . . .
Planification de 39 opérations en 600 secondes, mélange de salles . . . . . . . . . . .
Planification de 39 opérations en 600 secondes, salles polyvalentes . . . . . . . . . . .
Planification de 39 opérations en 7200 secondes, salles spécialisées . . . . . . . . . . .
Planification de 39 opérations en 7200 secondes, mélange de salles . . . . . . . . . . .
Planification de 39 opérations en 7200 secondes, salles polyvalentes . . . . . . . . . .
Tableau de résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
25
26
27
28
29
30
Codage des données d’entrée. . . . . . . . . .
Codage des niveaux de contraintes du modèle.
Structure des paramètres du solveur. . . . . .
Structure des résultas. . . . . . . . . . . . . .
Structure de statistiques du solveur. . . . . . .
Exemple de fichier de bloc . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
42
43
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Résumé
Ces travaux s’intéressent au dimensionnement d’un bloc opératoire ainsi qu’à la planification des opérations dans ce bloc au moyen de programmes linéaires utilisant le solveur Cplex. Les problèmes de planification en milieu hospitalier sont soumis à plus de contraintes que les générations d’emploi du temps habituels.
Le domaine est en effet très particulier, et nécessite une gestion du personnel très lourde qui se traduit par
un trop grand nombre de contraintes pour un programme linéaire. Des simplifications ont été nécessaires et
deux modèles ont été développés, chacun traitant d’une petite partie du problème initial. Le premier permet
de faire la planification sur toute la semaine, sans tenir compte des disponibilités du personnel hospitalier. Le
second effectue la planification sur une seule journée, mais en tenant compte des disponibilités des chirurgiens.
Plusieurs fonctions objectifs ont été testées pour chaque programme linéaire, chacune prenant en compte un
certain nombre de critères différents. Le dimensionnement du bloc opératoire a été inclus dans les programmes
linéaires, en ajoutant dans la fonction objectif la minimisation du nombre de salles.
mots-clés : dimensionnement, planification, bloc opératoire, Cplex, programmation linéaire
Abstract
This work is about dimensionning an operating block and scheduling the operations in this same block,
using linear programming and Cplex solver. Scheduling problems in hospitals are very specific : there are
more constrained than the usual scheduling problems. This domain is indeed very special, because it is difficult
to include all the hospital workers in the model. Simplifications were made, and two differents models were
created, each one dealing with a small part of the whole scheduling problem. The first one schedules the operations for the whole week, without taking care of hospital workers. The second one schedules the operations
for only one day, and surgeon’s management has been included in the model. Several objectives functions have
been tested for each program, all of them dealing with different criteria. The operating block dimensionning
have been included in the linear programs, by adding in the objective function the minimisation of the rooms’
number.
keywords : dimensionning, scheduling, operating block, Cplex, linear programming
Table des matières
Remerciements
Résumé / Abstract
Introduction
1
I
Présentation du problème
2
1
But et contraintes
1.1 But du projet . . . . . . . . . . . . .
1.2 Contraintes classiques de planification
1.3 Contraintes liées aux personnels . . .
1.4 Contraintes liées aux opérations . . .
1.5 Contraintes liées aux coûts . . . . . .
1.6 Contraintes logistiques . . . . . . . .
1.7 Problème de dimensionnement . . . .
.
.
.
.
.
.
.
2
2
2
3
3
4
4
5
.
.
.
.
.
5
5
5
5
6
6
2
II
1
Modélisation des différents éléments
2.1 Les opérations . . . . . . . . . .
2.2 Les salles d’opération . . . . . .
2.3 Les chirurgiens . . . . . . . . .
2.4 Modélisation UML . . . . . . .
2.5 Les spécialités . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Planification hebdomadaire
Le programme linéaire
1.1 Description . . . . . . . . . . . . . . . . . .
1.2 Les variables . . . . . . . . . . . . . . . . .
1.3 Les fonctions objectifs . . . . . . . . . . . .
1.3.1 La première fonction objectif . . . . .
1.3.2 Prise en compte du dimensionnement
1.4 Les contraintes . . . . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
8
9
2
III
1
2
Résultats
2.1 Paramètres du programme . . . . . .
2.1.1 Paramètres généraux . . . . .
2.1.2 Types de salles . . . . . . . .
2.1.3 Nombre d’opérations . . . . .
2.2 Résultats . . . . . . . . . . . . . . . .
2.2.1 Variation de la taille du fichier
2.2.2 Variation des types de salles .
2.3 Analyse des résultats . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Planification avec gestion des chirurgiens
1.1 Définition des variables . . . . . . . . .
1.2 Les fonctions objectifs . . . . . . . . .
1.2.1 Fonction objectif liée aux salles
1.2.2 Deuxième fonction objectif . . .
1.2.3 Fonction objectif complète . . .
1.3 Les contraintes . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
10
11
11
13
16
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Résultats
2.1 Paramètres du programme . . . . . . . . . . . . . .
2.2 Méthodologie des tests . . . . . . . . . . . . . . . .
2.2.1 Tests sur des problèmes de différentes tailles
2.2.2 Tests sur différents types de salles . . . . . .
2.2.3 Différents temps d’exécution . . . . . . . . .
2.3 Variation de la taille du fichier d’entrée . . . . . . . .
2.3.1 12 opérations . . . . . . . . . . . . . . . . .
2.3.2 20 opérations . . . . . . . . . . . . . . . . .
2.3.3 39 opérations . . . . . . . . . . . . . . . . .
2.4 Variation de la fonction objectif . . . . . . . . . . .
2.4.1 Fonction objectif la plus simple . . . . . . .
2.4.2 Deuxième fonction objectif . . . . . . . . . .
2.4.3 Prise en compte des chirurgiens . . . . . . .
2.5 Variation des types de salles . . . . . . . . . . . . .
2.5.1 Résolution de 600 secondes . . . . . . . . .
2.5.2 Résolution de 1800 secondes . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
18
18
19
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
21
21
22
22
22
23
24
27
27
28
29
32
33
35
2.5.3
2.5.4
IV
1
2
Résolution de 7200 secondes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
38
Résolution avec Cplex
40
Structure du programme
1.1 Fichiers sources . . . . .
1.1.1 data.c / data.h . .
1.1.2 solver.c / solver.h
1.1.3 result.c / result.h
1.1.4 stat.c / stat.h . .
1.2 Scripts . . . . . . . . . .
1.2.1 Makefile . . . .
1.2.2 run.sh . . . . . .
1.2.3 nohup_run.sh . .
.
.
.
.
.
.
.
.
.
40
40
40
42
42
43
43
43
43
44
Problèmes rencontrés
2.1 Limites de Cplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Problème de rappatriement des données depuis Cplex . . . . . . . . . . . . . . . . . . . . . .
44
44
45
Conclusion
Références bibliographiques
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
Introduction
Ce travail s’inscrit dans le cadre de la construction du Nouvel Hôpital d’Estaing (N.H.E.) à Clermont-Ferrand.
Il a pour but de dimensionner la taille du bloc opératoire de ce nouvel hôpital, ainsi que d’effectuer la planification de l’emploi du temps des salles d’opérations du bloc. Cette planification sera effectuée au moyen d’un
programme linéaire résolu par Cplex. Les résultats obtenus font l’objet d’une simulation QNAP effectuée par
deux élèves de deuxième année dans le cadre de leur projet.
La génération d’un emploi du temps est un problème classique de recherche opérationnelle. Cependant, le
domaine hospitalier amène une complexité beaucoup plus grande que les problèmes de planification habituels,
que ce soit au niveau du personnel ou de la logistique. En effet, une opération est effectuée par un ensemble
de personnes de métiers différents : chirurgiens, anesthésistes, internes, infirmières spécialisées ou non. Les
équipements nécessaires à une opération sont nombreux et coûteux, et il est donc nécessaire d’en minimiser
le nombre. De plus, les patients ne peuvent être traités comme une quelconque marchandise, ce qui impose
des contraintes supplémentaires. Le nombre de contraintes à respecter pour générer l’emploi du temps est donc
beaucoup plus grand que la normale. À cela s’ajoute le problème de dimensionnement du bloc opératoire,
c’est-à-dire qu’il faut déterminer en fonction de la charge de travail à effectuer quelle est le nombre de salles
nécessaires. Le grand nombre de contraintes existant nous a conduit à effectuer des simplifications afin d’obtenir une bonne solution dans un temps acceptable.
Dans la première partie seront détaillées les contraintes, qui font de ce problème un problème si particulier,
ainsi que les simplifications et choix opérés. Les deux parties suivantes seront chacune consacrées à un modèle linéaire construit pour répondre à deux facettes du problèmes, ainsi qu’aux tests qui nous ont permis d’en
vérifier la validité. Finalement sera expliquée dans une dernière partie la structure du programme mis en place.
page 1 sur 46
Première partie
Présentation du problème
1
1.1
But et contraintes
But du projet
Ce projet est effectué en parallèle avec un projet de deuxième année en filière 3, travaillant sur un modèle
de simulation avec le logiciel QNAP. Il a pour but de planifier l’emploi du temps des salles d’opération du
N.H.E., Nouvel Hôpital d’Estaing. Pour cela, en plus de répartir les actes chirurgicaux à effectuer dans les
différentes salles d’opérations, il faut choisir le nombre de salles d’opérations nécessaires à la réalisation des
opérations dans le temps imparti. Il faut également choisir le type de salles. En effet, les salles ne seront pas
forcément équipées du matériel nécessaire à toutes les opérations. Il en résulte une spécialisation des salles. Il
y a quatre spécialités en tout, et les salles peuvent être :
– "spécialisées", c’est-à-dire qu’elles ne peuvent accueillir des opérations que d’une seule spécialité
– "partagées", c’est-à-dire qu’elles peuvent accueillir des opérations de plusieurs spécialités
– "polyvalentes", c’est-à-dire qu’elles peuvent accueillir des opérations de toutes les spécialités.
L’idéal serait d’être capable de générer un emploi du temps pour la semaine entière, afin que les patients
soient prévenus assez tôt du jour exact de leur opération, ainsi que de leur jour d’entrée à l’hôpital.
La création de cet emploi du temps est soumise à de nombreuses contraintes, tant humaines, que logistiques
ou pécuniaires. Ces contraintes sont détaillées dans les parties suivantes, en même temps que les hypothèses de
simplification émises à leur sujet.
1.2
Contraintes classiques de planification
Il existe un certain nombre de contraintes communes à tout problème de planification :
– deux tâches ne peuvent se chevaucher : ici, deux actes chirurgicaux ont au moins lieu soit dans des salles
différentes, soit à un moment différent, soit à un jour différent.
– les personnels ne peuvent effectuer deux tâches à la fois, les tâches étant ici des opérations.
– il existe des horaires d’utilisation des ressources, ici les salles d’opérations et le personnel hospitalier.
– un temps d’exécution est affecté à chaque tâche
Beaucoup de contraintes sont spécifiques au domaine hospitalier et contribuent à complexifier le problème.
page 2 sur 46
1.3
Contraintes liées aux personnels
Le problème posé par la gestion du personnel en salle d’opération est complexe. En effet, plusieurs types de
personnels cohabitent dans une salle d’opération :
– les chirurgiens
– les internes
– les anesthésistes
– les Aide Soignants
– les infirmiers, qui peuvent posséder des diplômes et donc des qualifications différentes ; il y a :
– les IDE (Infirmiers Diplômés d’Etat)
– les IBODE (Infirmiers de Bloc Opératoire Diplômé d’Etat)
– les IADE (Infirmiers Anesthésistes Diplômés d’Etat)
Pour planifier une opération donnée, il faut donc affecter une équipe composée de plusieurs types de personnels, ce qui rend l’affectation complexe. De plus, plusieurs structures d’équipes sont possibles. Par exemple,
un IADE (Infirmier Anesthésiste Diplômés d’Etat) peut très bien remplacer l’anesthésiste dans certains cas, et
l’interne peut faire le travail d’une infirmière. Il en résulte un surplus de paramètres, trop pour que ces derniers
soient tous considérés efficacement dans un programme linéaire.
Les programmes mis en place ne considèrent au maximum que les chirurgiens. Chaque chirurgien ne peut
effectuer que des opérations dans son domaine de compétences. Le reste du personnel opérant ne sera donc pas
pris en compte lors de la planification, il le sera uniquement lors de la simulation QNAP effectuée dans le cadre
du projet de deuxième année.
1.4
Contraintes liées aux opérations
Il existe également un épineux problème au sujet des actes chirurgicaux. En effet, le temps de chaque opération est donné, en entrée du problème, mais ces temps ne sont jamais que des estimations. En effet, chaque
patient est différent, chaque chirurgien est différent, et les temps d’opération d’un même acte sur deux patients
différents peuvent être très inégaux. Il peut arriver qu’une complication survienne, qui fasse durer l’opération
une heure de plus que prévu. Que faire alors si une autre opération a été prévue dans la même salle juste après
la fin théorique de la première ? L’utilisation de lois probabilistes est possible, mais le temps a manqué pour se
pencher sur le problème.
Par ailleurs, un intervalle de temps de 15 minutes est laissé entre la fin d’une opération et le début de la
suivante. Cette durée, paramètrable, correspond au temps de décontamination de la salle après l’opération.
De plus, certaines opérations doivent être terminées avant une certaine heure de la journée, principalement
les opérations effectuées en ambulatoire, c’est-à-dire lorsque le patient sort le jour de son opération. Pour gérer
page 3 sur 46
cela il a été mis en place un système de date au plus tard. Chaque opération, en plus de sa durée, aura une date
au plus tard qui correspondra à l’heure à laquelle l’opération doit obligatoirement être achevée.
Un patient ne peut pas être considéré comme un produit habituel ; en effet, on ne peut par exemple pas arrêter
une opération un soir pour la terminer le lendemain, ce qui rajoute encore une fois une contrainte.
Une opération peut être découpée en plusieurs phases : avant l’acte chirurgical en lui-même, il y a le temps
de préparation du patient ainsi que le temps d’anesthésie. Après l’acte se déroule le temps du pansement, puis
la décontamination de la salle d’opération. Affiner ainsi le déroulement d’une opération permettrait d’affiner la
gestion du personnel. En effet, un chirurgien n’a besoin d’être présent qu’au moment de l’acte chirurgical, pas
avant ni après. De même, une infirmière peut s’en aller après avoir effectuer le pansement, avant la décontamination, mais elle doit être là avant l’acte pour préparer le patient.
Malheureusement, le modèle qui tiendrait compte de ces paramètres serait bien trop gros pour pouvoir être
résolu en un temps raisonnable ; une opération sera donc considérée comme étant un seul et même évènement
auquel doivent prendre part tout le personnel qui y est affecté. Seul sera séparé de l’opération le temps de
décontamination, fixé provisoirement à 15 minutes, comme décrit plus haut.
1.5
Contraintes liées aux coûts
Les coûts engendrés par la construction d’une salle d’opération sont grands. Lors du dimensionnement, il
faut donc essayer de minimiser le nombre de salles, afin que le moins possible soient construites.
L’équipement d’une salle est également très coûteux. En plus de minimiser le nombre de salles, il faut aussi
privilégier les salles spécialisées aux salles partagées ou polyvalentes.
1.6
Contraintes logistiques
Dans un bloc opératoire ne se trouvent pas uniquement des salles d’opérations, il y a également des salles de
réveil, où les patients sont placés juste après leur opération. Ces salles de réveil comportent un certain nombre
de lits, qui doit être suffisant pour ne pas être obligé de bloquer une salle d’opération en attendant le réveil du
patient, ce qui engendrerait des retards dans le planning.
De la même manière, il existe du personnel en dehors des salles d’opération : des brancardiers emmènent
les patients de leur chambre à la salle d’opération. Il faut veiller à ce que les brancardiers n’aient pas trop de
patients à acheminer au même moment, ce qui créerait un goulot d’étranglement, retardant encore une fois le
planning.
Tous ces problèmes hors de la salle d’opération ne seront pas traités dans le programme linéaire, car ils le
complexifieraient beaucoup trop. La gestion en sera laissée à la simulation QNAP du projet parallèle.
page 4 sur 46
1.7
Problème de dimensionnement
Le dimensionnement du bloc opératoire a été inclus de manière détournée dans le programme linéaire, en
rajoutant dans les critères de la fonction objectif la minimisation du nombre de salles utilisées.
L’un des problèmes induits par cette méthode est qu’il a fallu calibrer le poids de ce critère dans la fonction
objectif, pour que le résultat obtenu ne soit pas une seule salle avec un dépassement astronomique de son
horaire. L’autre problème est que cela nous oblige à déclarer un grand nombre de salles dans le programme
linéaire initial, afin que ce dernier ait assez de choix dans les types de salles pour pouvoir optimiser correctement
ce dimensionnement, le problème étant que plus le nombre de salles est important dans le programme, plus le
nombre de contraintes et donc la taille du programme, augmente, ce qu’il aurait été bien d’éviter vu la taille
initiale du problème.
2
2.1
Modélisation des différents éléments
Les opérations
Les opérations sont caractérisées par une spécialité unique, une date au plus tard, et par le jour auquel elles
ont lieu.
2.2
Les salles d’opération
Une salle d’opération a, pour chaque jour, une horaire d’ouverture et une horaire de fermeture. Une salle
d’opération peut accueillir des opérations de spécialités différentes. Toutefois le coût de telles salles est élevé
en raison du matériel qui l’équipe.
2.3
Les chirurgiens
Le codage des chirurgiens est très semblable au codage des salles : un chirurgien a une horaire de début de
service et une horaire de fin de service. Il a également une ou plusieurs spécialités.
page 5 sur 46
2.4
Modélisation UML
La modélisation des objets mis en jeu par le problème de planification peut être résumée par le diagramme
de classes suivant :
F IG . 1 – Diagramme de classes du problème de planification
On affecte à chaque opération une date de début (et donc intrinsèquement une date de fin), une salle compatible avec la spécialité de l’opération, ainsi qu’un chirurgien compatible.
2.5
Les spécialités
Opérations, chirurgiens et salles ont leur propre spécialité. Chaque opération a une spécialité unique. À
l’opposé, chirurgiens et salles peuvent accueillir des opérations de spécialités différentes. Ils sont dits polyvalents.
Une spécialité est représentée par un nombre entier positif. Nous utilisons la représentation binaire. La spécialité 1 est associée au bit de poids le plus faible. Plus généralement, la spécialité unique numéro i est associée
au nombre 2i . Pour une spécialité multiple représentant la spécialité j et la spécialité j, le nombre associé est
2i + 2j . Il en va de même s’il y a encore plus de spécialités. Donc pour tester si la salle m de spécialité éventuellemnt multiple spem est compatible avec l’opération i de spécialité unique spei , il suffit de faire un ET bit à
bit des deux nombres. Si le nombre spei ET spem obtenu est positif, l’opération i peut avoir lieu dans la salle
m.
page 6 sur 46
Deuxième partie
Planification hebdomadaire
1
Un programme est constitué de variables mises en relation par des contraintes exprimées par des relations
algébriques. Notre programme est dit linéaire, car les relations entre les variables sont linéaires.
1.1
Description
Ce programme linéaire effectue, en plus du dimensionnement du bloc opératoire, une planification hebdomadaire des opérations chirurgicales. Il ne prend pas en compte la gestion du personnel et les affectations
des employés aux opérations. Il lui faut en revanche gérer le planning des salles, de manière à ce qu’aucunes
opérations ne se chevauchent un même jour dans une même salle.
1.2
Les variables
Nous allons définir les variables mises en jeu par le programme. Il s’agit essentiellement de variables
entières positives, dont des variables booléennes, à valeur dans {0, 1}. Les notations sont en bonne partie issues
de [1].
– N op le nombre d’opérations
– S le nombre de salles
– xi,m booléen à valeur 1 l’opération i a lieu dans la salle m, 0 sinon
– wm booléen à valeur 1 si la salle m est utilisée
– ti la date de début de l’opération i
– di la durée de l’opération i
– dayi jour de l’opération i
– θi,j booléen à valeur 1 si l’opération i commence avant l’opération j, 0 sinon
– sri,m booléen indiquant si la salle m est compatible avec l’opération i
– N spem le nombre de spécialité de la salle m
– spek la spécialité de l’opération k
– Li retard par rapport à la date prévue pour l’opération i
– ddi la date de fin au plus tard de l’opération i
– Hm la durée effective d’ouverture de la salle m
– Cm la durée d’ouverture de la salle m prévue initialement
– Ym le retard de la salle m
– M constante à valeur élevée 10000
page 7 sur 46
1.3
Les fonctions objectifs
Le programme comprend une fonction objectif, qui représente le critère de qualité à optimiser. Dans notre
cas, il s’agit d’une minimisation. Le programme comprend plusieurs fonctions objectifs possibles, qui prennent
en compte différents critères.
1.3.1
La première fonction objectif
Elle ne prend pas en compte le problème du dimensionnement. Trois critères sont minimisés dans cette fonction objectif :
– la somme des retards à la fermeture des salles d’opérations
– la somme des retards de la fin des opérations par rapport à leur date au plus tard
– la somme des dates de début d’opérations
Voici l’expression de cette fonction objectif :
Minimiser z =
S
X
100Ym +
m=1
N
op
X
100Li +
i=1
N
op
X
ti
i=1
Des coefficients ont été affectés aux critères en fonction de leur importance. Les sommes des retards sont
les critères principaux, et sont donc affectés du plus grand coefficient. La somme des dates de début n’est
qu’un critère d’affinement du résultat qui permet de fixer les opérations le plus proche possible de la fin de la
précédente. En effet, sans ce critère, des opérations peuvent être placées n’importe quand dans une salle tant
qu’elles ne dépassent ni l’horaire de fermeture de la salle ni leur date au plus tard. Par exemple, une opération
durant 100 minutes prévue dans une salle fermant au bout de 500 minutes peut commencer à la date t = 100
ou t = 400 sans que cela affecte la fonction objectif. Comme ce critère a une valeur beaucoup plus grande que
la valeur des autres critères, un coefficient beaucoup plus faible lui est affecté.
1.3.2
Prise en compte du dimensionnement
La deuxième fonction objectif prend en compte le problème de dimensionnement du bloc opératoire. Pour
cela, un critère est ajouté à la fonction objectif précédente : la minimisation du nombre de salles utilisées. Voici
l’expression de cette nouvelle fonction objectif :
Minimiser z =
S
X
m=1
100Ym +
N
op
X
i=1
100Li +
N
op
X
i=1
ti +
S
X
10000wm
m=1
page 8 sur 46
Un coefficient 10000 est affecté à ce dernier critère, car le dimensionnement devient alors le problème principal lorsqu’il est pris en compte dans le modèle. Le rapport de 100 entre les coefficients affectés à wm et Ym
permet de faire en sorte qu’une nouvelle salle soit ouverte lorsqu’il y a au moins 100 minutes de dépassement
des salles actuelles au total.
1.4
Les contraintes
Certaines contraintes ont été inspirées de [2].
ti + di − M (3 − θi,j − xi,m − xj,m ) ≤ tj , ∀i, j ∈ J1, N opK si dayi = dayj , ∀m ∈ J1, SK
(1)
θi,j + θj,i = 1, ∀i, j ∈ J1, N opK si dayi = dayj
(2)
S
X
m=1
xi,m = 1, ∀i ∈ J1, N opK
(3)
ti − M (1 − xi,m ) ≤ Hm , ∀i ∈ J1, N opK, ∀m ∈ J1, SK
(4)
Hm − Cm ≤ Ym , ∀m ∈ J1, SK
(5)
xi,m (1 − sri,m ) = 0, ∀i ∈ J1, N opK, ∀m ∈ J1, SK
(6)
Li ≥ ti + di − ddi , ∀i ∈ J1, N opK
(7)
N op ∗ wm ≥
N
op
X
i=1
xi,m , ∀m ∈ J1, SK
(8)
Nous allons donner ci-après la correspondance entre les expressions algébriques des contraintes et leur sémantique.
La contrainte (1) assure que dans chaque salle, deux opérations ne se chevauchent pas (S∗N op2 contraintes).
La contrainte n’est active seulement dans le cas où les deux opérations sont prévues le même jour.
La contrainte (2) valide les contraintes de précédence : soit l’opération i commence avant l’opération j, soit
c’est l’inverse (N op2 contraintes). La contrainte n’est active seulement dans le cas où les deux opérations sont
prévues le même jour.
La contrainte (3) assure qu’une opération a lieu une seule fois (N op contraintes).
La contrainte (4) permet de trouver l’horaire effectif de fermeture d’une salle m (N op ∗ S contraintes).
La contrainte (5) exprime le retard de d’une salle m par rapport à l’horaire de fermeture (S contraintes).
La contrainte (6) assure que l’opération i aura lieu dans une salle ou les équipements nécessaires sont présents (N op∗S contraintes). Une salle peut être polyvalente ; elle acueille des opérations de plusieurs spécialités
notées srm,k .
La contrainte (7) permet de s’assurer qu’une opération i se terminera avant sa date de fin au plus tard (N op
page 9 sur 46
contraintes).
La contrainte (8) crée la salle m si elle contient au moins une opération (S contraintes). Elle est active
uniquement dans le cas du dimensionnement.
Ce programme linéaire génère donc S ∗ N op ∗ N op + N op ∗ N op + 2N op + 2N op ∗ S + 2S contraintes. Cela
fait, pour 100 opérations et 20 salles, un total de 214240. Mais le nombre de contraintes effectives du fichier .lp
généré est d’environ 40000, à cause des simplifications dues au test dayi = dayj dans les contraintes (1) et (2).
2
Résultats
2.1
Paramètres du programme
On considère donc pour cette planification que le jour de chaque opération a déjà été choisi au préalable.
Dans la pratique, cela peut être réalisé par une heuristique, qui répartirait équitablement sur les 5 jours le
nombre (ou encore mieux la somme des durées) d’opérations de spécialité identique, en prenant éventuellement
en compte que certaines opérations ont des dates au plus tard.
2.1.1
Paramètres généraux
Tous les tests ont été effectués avec les paramètres suivants :
– 20 salles d’opérations (avant dimensionnement)
– 15 minutes d’intervalles entre la fin d’une opération et le début de la suivante
– le temps d’ouverture normale des salles est de 540 minutes (9 heures)
– il y a 4 spécialités différentes
– les dates au plus tard pour chaque opération sont fixées à 1000 minutes.
2.1.2
Types de salles
Le programme a été testé sur 3 types d’ensemble de salles différents :
– uniquement des salles spécialisées
– uniquement des salles polyvalentes
– un mélange de salles spécialisées, partagées et polyvalentes.
2.1.3
Nombre d’opérations
Le programme a été testé sur des ensembles de 59 opérations, 100 opérations, et 198 opérations. Ce dernier
ensemble est le plus réaliste quant au nombre d’opérations hebdomadaires. Il a été tiré de la base de données
page 10 sur 46
de l’hôpital.
2.2
2.2.1
Résultats
Variation de la taille du fichier
Dans toute cette partie, l’ensemble de salles utilisées sera un mélange des types de salles, et la fonction objectif minimisera le nombre de salles utilisées ainsi que la somme des retards de fermeture de ces salles :
Minimiser z =
S
X
m=1
Ym +
S
X
100wm
m=1
Pour un fichier de 59 opérations, l’optimalité n’est pas atteinte au bout de deux heures de résolution, mais la
planification obtenue est acceptable (z = 52500) :
F IG . 2 – Planification hebdomadaire de 59 opérations
page 11 sur 46
La solution obtenue utilise seulement 5 salles d’opérations, et ces salles sont toutes au minimum partagées,
voire polyvalentes.
Pour un fichier de 100 opérations, le résultat est bon (z = 102200), comme le montre le diagramme de Gantt
associé :
On voit que 9 salles ont été nécessaires pour cette planification, et, comme aucune horaire de fermeture ne
dépasse trop de l’horaire prévu, on peut considérer que dimensionnement et planification sont acceptables.
Pour un fichier de 198 opérations, qui correspond plus à la réalité du terrain, l’optimalité n’est bien sûr pas
atteinte, et la solution obtenue est assez moyenne (pour le seul test effectué, z = 249700). Voici le diagramme
de Gantt associé :
page 12 sur 46
Seulement 10 salles sont utilisées, mais le dépassement d’horaire dans certaines d’entre elles est beaucoup
trop grand pour que la solution soit considérée comme acceptable.
2.2.2
Variation des types de salles
Dans cette partie, les tests sont effectués sur le fichier de 198 opérations, avec la fonction objectif minimisant
le nombre de salle, la somme des dépassements d’horaires des salles et des dates au plus tard, et la somme des
dates de début d’opérations :
Minimiser z =
S
X
m=1
100Ym +
S
X
m=1
10000wm +
N
op
X
i=1
100Li +
N
op
X
ti
i=1
Lorsqu’on considère que l’hôpital n’est constitué que de salles spécialisées, le résultat obtenu est très bon
(z = 98221), comme le montre le diagramme de Gantt retranscrivant les résultats :
page 13 sur 46
F IG . 5 – Planification hebdomadaire dans des salles spécialisées
Seulement 9 salles sont nécessaires à la planification des opérations.
Lorsqu’on considère un mélange de types de salles, le résultat obtenu est moyen (z = 152033).
page 14 sur 46
F IG . 6 – Planification hebdomadaire dans un mélange de salles
Comme le montre le diagramme de Gantt associé, 7 salles sont nécessaires à la planification des opérations
mais certaines dépassent largement leur horaire prévue, ce qui fait penser qu’il serait utile de rajouter une ou
deux salles.
Lorsqu’on considère uniquement des salles polyvalentes, le résultat obtenu est là encore moyen (z = 125521).
page 15 sur 46
F IG . 7 – Planification hebdomadaire dans des salles polyvalentes
Comme pour le jeu de salles précédent, 7 salles ont été utilisées pour planifier les opérations mais l’une
d’entre elles dépasse largement l’horaire prévue, ce qui fait penser qu’il serait utile de rajouter une salle.
2.3
Analyse des résultats
Tous les résultats obtenus ici sont à prendre avec précaution, car tous ces tests n’ont été effectués qu’une
seule fois. Les résultats pourraient donc être faussés. On peut néanmoins en déduire que le modèle permet une
planification hebdomadaire efficace dans la plupart des cas, même si une solution vraiment bonne soit parfois
difficile à atteindre.
page 16 sur 46
Troisième partie
Planification avec gestion des chirurgiens
Par rapport au programme précédent, deux choses ont principalement été rajoutées. Tout d’abord a été rajoutée la gestion des chirurgiens. Le principe est le suivant : on affecte à chaque opération un chirurgien disponible
et compatible, sans tenir compte du fait qu’il n’a pas réellement besoin d’être présent durant toute l’opération,
mais seulement durant l’acte chirurgical. Pour compenser cette complexification du problème, la planification
s’effectuera maintenant sur une seule journée.
1
1.1
Définition des variables
Nous allons définir les variables mises en jeu par le programme. Il s’agit essentiellement de variables
entières positives, dont des variables booléennes, à valeur dans {0, 1}.
– N op le nombre d’opérations
– N surg le nombre de chirurgiens
– S le nombre de salles
– xi,m booléen à valeur 1 l’opération i a lieu dans la salle m, 0 sinon
– wm booléen à valeur 1 si la salle m est utilisée
– ti la date de début de l’opération i
– di la durée de l’opération i
– θi,j booléen à valeur 1 si l’opération i commence avant l’opération j, 0 sinon
– srm,i booléen indiquant si la salle m est compatible avec l’opération i
– N spem le nombre de spécialités de la salle m
– sgi,p booléen indiquant si le chirurgien p est compatible avec l’opération i
– spek la spécialité de l’opération i
– Li retard par rapport à la date prévue pour l’opération i
– ddi la date de fin au plus tard de l’opération i
– Hm la durée effective d’ouverture de la salle m
– Cm la durée d’ouverture de la salle m prévue initialement
– Ym le retard de la salle m
– M constante à valeur élevée 10000
– νi,p booléen à valeur 1 si l’opération i est pratiquée par le chirugien p, 0 sinon
– [Ap ; Bp ] la période de travail du chirurgien p
– Kp le dépassement par valeur supérieure d’horaire de fin du chirurgien p
page 17 sur 46
–
–
–
–
1.2
Jp le dépassement par valeur inférieure de l’horaire de début du chirurgien p
αp date de début de la première opération du chirurgien p
βp date de fin de la dernière opération du chirurgien p
N spep le nombre de spécialités du chirurgien p
Les fonctions objectifs
Le programme comprend une fonction objectif, qui représente le critère de qualité à optimiser. Dans notre cas,
il s’agit d’une minimisation. Un choix était cependant nécessaire pour établir la fonction objectif, car beaucoup
de valeurs pouvaient être minimisées : la somme des retards de fermeture des salles, la somme des retards
des opérations par rapport à leur date au plus tard, la somme des heures supplémentaires des chirurgiens, sans
oublier la minimisation du nombre de salles d’opérations inhérente au dimensionnement du bloc opératoire.
Ce problème de choix nous a conduit à tester plusieurs fonctions objectifs successives, pour en comparer les
résultats et le temps d’exécution.
1.2.1
Fonction objectif liée aux salles
La première fonction objectif ne minimise que le nombre de salles (et donc réalise le dimensionnement),
ainsi que la somme des retards de fermeture des salles. Il a fallu pondérer ces deux paramètres. En effet, il est
plus important de minimiser le nombre de salles que leur retard. Il serait stupide de créer une salle supplémentaire parce qu’une des salles ferme 10 minutes plus tard. Un coefficient 100 a été placé devant le nombre de
salles. Ainsi, une salle est créee lorsqu’une des autres salles ferme 100 minutes plus tard que la normale. Voici
cette fonction objectif :
Minimiser z =
S
X
m=1
1.2.2
Ym +
S
X
100wm
m=1
Deuxième fonction objectif
La deuxième fonction objectif minimise non seulement le nombre de salles et leur retard de fermeture, mais
aussi le retard des opérations par rapport à leur date au plus tard, ainsi que la somme des dates de débuts.
Cette dernière partie de la fonction objectif a été rajoutée pour qu’il y ait moins de solutions équivalentes. En
effet, sans cela les opérations peuvent être placées n’importe quand dans une salle tant qu’elles ne dépassent ni
l’horaire de fermeture de la salle ni leur date au plus tard. Le rajout de la minimisation de la somme des dates
de début d’opération permet à la fois d’obtenir moins de solutions équivalentes qui ralentissent Cplex, et de
faire commencer les opérations le plus tôt possible. Cela permet d’obtenir un emploi du temps plus compact, et
d’éventuellement fermer certaines salles plus tôt que prévu.
page 18 sur 46
Encore une fois, des coefficients ont été nécessaires pour pondérer la fonction objectif. La somme des retards des opérations par rapport à leur date au plus tard est de même ordre que le retard de fermeture des salles.
Elle a le même poids dans la fonction objectif. La somme de date de début étant très grande et n’ayant que
peu d’importance, par rapport au nombre de salles par exemple puisqu’il s’agit d’un affinement, nous avons
multiplié par 100 tous les autres critères à minimiser. On obtient la fonction objectif suivante :
Minimiser z =
S
X
100Ym +
m=1
1.2.3
S
X
10000wm +
N
op
X
m=1
100Li +
i=1
N
op
X
ti
i=1
Fonction objectif complète
La troisième fonction objectif minimise également les heures supplémentaires des chirurgiens, en minimisant à la fois la somme des dépassements d’horaire en fin de journée et la somme des dépassements d’horaire
avant leur prise théorique de service.
Ces deux critères étant clairement équivalents aux sommes des dépassements pour les salles et les opérations,
le même coefficient leur sera affecté dans la fonction objectif.
La fonction objectif obtenue est la suivante :
Minimiser z =
S
X
m=1
1.3
100Ym +
S
X
10000wm +
m=1
N
op
X
i=1
100Li +
N
op
X
ti +
NX
surg
i=1
100Kp +
NX
surg
p=1
100Jp
p=1
Les contraintes
ti + di − M (3 − θi,j − xi,m − xj,m ) ≤ tj , ∀i, j ∈ J1, N opK, ∀m ∈ J1, SK
(1)
θi,j + θj,i = 1, ∀i, j ∈ J1, N opK
(2)
S
X
m=1
xi,m = 1, ∀i ∈ J1, N opK
(3)
ti − M (1 − xi,m ) ≤ Hm , ∀i ∈ J1, N opK, ∀m ∈ J1, SK
(4)
Hm − Cm ≤ Ym , ∀m ∈ J1, SK
(5)
xi,m sri,m = 0, ∀i ∈ J1, N opK, ∀m ∈ J1, SK
(6)
Li ≥ ti + di − ddi , ∀i ∈ J1, N opK
(7)
page 19 sur 46
NX
surg
p=1
νi,p = 1, ∀i ∈ J1, N opK
(8)
ti ≥ νi,p αp , ∀i ∈ J1, N opK, ∀p ∈ J1, N surgK
(9)
Ap − αp ≤ Jp , ∀p ∈ J1, N surgK
(10)
ti + di − M (1 − νi,p ) ≤ βp , ∀i ∈ J1, N opK, ∀p ∈ J1, N surgK
(11)
βp − Bp ≤ Kp , ∀p ∈ J1, N surgK
(12)
ti + di − M (3 − νi,p − νj,p − θi,j ) ≤ tj , ∀i, j ∈ J1, N opK, ∀p ∈ J1, N surgK
(13)
νi,p (1 − sgi,p ) = 0, ∀i ∈ J1, N opK, ∀p ∈ J1, N surgK
(14)
Nous allons donner ci-après la correspondance entre les expressions algébriques des contraintes et leur sémantique.
La contrainte (1) assure que dans chaque salle, deux opérations ne se chevauchent pas ((N op2 )S contraintes).
La contrainte n’est active seulement dans le cas où les deux opérations sont prévues le même jour.
La contrainte (2) valide les contraintes de précédence : soit l’opération i commence avant l’opération j, soit
c’est l’inverse (N op2 /2 contraintes). La contrainte n’est active seulement dans le cas où les deux opérations
sont prévues le même jour.
La contrainte (3) assure qu’une opération a lieu une seule fois (N op contraintes).
La contrainte (4) permet de trouver l’horaire effectif de fermeture d’une salle m (N op ∗ S contraintes).
La contrainte (5) exprime le retard de d’une salle m par rapport à l’horaire de fermeture (S contraintes).
La contrainte (6) assure que l’opération i aura lieu dans une salle où les équipements nécessaires sont présents (N op ∗ S contraintes). Une salle peut être polyvalente ; c’est à dire qu’elle peut acueillir des opérations
de plusieurs spécialités notées srm,k .
La contrainte (7) permet de s’assurer qu’une opération i se terminera avant sa date de fin au plus tard (N op
contraintes).
La contrainte (8) assure qu’une opération est traitée par un et un seul chirurgien (N op contraintes).
La contrainte (9) fixe une limite de temps de travail inférieure pour les chirurgiens (N op∗N surg contraintes).
La contrainte (10) définit le dépassement par valeur inférieure du temps de travail des chirurgiens (N surg
contraintes).
La contrainte (11) fixe une limite de temps de travail supérieure pour les chirurgiens (N op ∗ N surg
contraintes).
La contrainte (12) définit le dépassement par valeur supérieure du temps de travail des chirurgiens (N surg
contraintes).
La contrainte (13) assure qu’un chirurgien n’effectue qu’une opération à la fois ((N op2 )∗N surg contraintes).
page 20 sur 46
La contrainte (14) assure qu’une opération est réalisée par un chirurgien compatible (N op∗N surg contraintes).
Ce programme linéaire génère donc (N op2 ) ∗ S + (N op2 ) ∗ N surg + N op ∗ N op/22 ∗ N op ∗ S + 3 ∗
N op ∗ N surg + 3N op + 2N surg + S contraintes. Cela fait, pour 40 opérations, 15 salles et 15 chirurgiens, un
nombre de 51965 contraintes, dont 24000 uniquement pour les contraintes (1) et (13). Rajouter la gestion des
différents jours de la semaine rendrait insolvable un programme linéaire déjà très long à résoudre.
2
Résultats
2.1
Paramètres du programme
Tous les tests ont été effectués avec les paramètres suivants :
– 20 salles d’opérations (avant dimensionnement)
– 15 minutes d’intervalle entre la fin d’une opération et le début de la suivante
– le temps d’ouverture normal des salles est de 540 minutes (9 heures)
– il y a 4 spécialités différentes
– les dates au plus tard pour chaque opération sont fixées à 1000 minutes
– 17 chirurgiens de disponibilités et spécialités différentes.
2.2
Méthodologie des tests
2.2.1
Tests sur des problèmes de différentes tailles
Ce programme linéaire a été testé sur 3 fichiers d’entrée différents :
– un fichier de 12 opérations
– un fichier de 20 opérations
– un fichier de 39 opérations.
Les tests se concentrent majoritairement sur le fichier à 39 opérations, qui correspond le plus au nombre
d’opérations à planifier dans une journée.
2.2.2
Tests sur différents types de salles
Le programme linéaire a également été testé sur trois ensembles de salles différents :
– uniquement des salles spécialisées
– uniquement des salles entièrement polyvalentes
– un mélange de salles spécialisées, polyvalentes et partagées.
page 21 sur 46
Le nombre de ces salles varie en fonction de la taille du fichier d’entrée : 10 pour le fichier de 12 opérations,
15 pour celui de 20 opérations, et 20 pour celui de 39 opérations.
2.2.3
Différents temps d’exécution
Lorsque le programme linéaire est trop gros pour être résolu de manière exacte (c’est-à-dire pour les problèmes à 20 et 39 opérations), des résultats au bout de 600, 1800 et 7200 secondes ont été calculés, afin de voir
à quelle vitesse Cplex trouvait une bonne solution.
Enfin, tous ces tests ont été effectués avec les trois fonctions objectifs différentes.
2.3
Variation de la taille du fichier d’entrée
La comparaison des tests s’effectueront ici uniquement avec un mélange de salles spécialisées, partagées et
polyvalentes et pour la fonction objectif la plus simple :
Minimiser
S
X
m=1
2.3.1
Ym +
S
X
100wm
m=1
12 opérations
Un problème à 12 opérations ne pose aucun souci de taille à Cplex. La résolution s’effectue en 160 secondes
environ, pour le résultat suivant :
page 22 sur 46
F IG . 8 – Planification sur 12 opérations, en 600 secondes
On constate que seules 4 salles sont nécessaires pour effectuer ces opérations. Mais ce jeu de données est
bien trop petit et ne correspond pas à la quantité réelle d’opérations traitée par l’hôpital.
2.3.2
20 opérations
Avec 20 opérations, le problème est déjà trop gros pour que Cplex puisse nous garantir l’optimalité. Une très
bonne solution est cependant obtenue en peu de temps (70 secondes). Voici le diagramme de Gantt associé à
cette solution :
page 23 sur 46
F IG . 9 – Planification de 20 opérations, en 600 secondes
7 salles sont ici nécessaires, mais là encore le jeu de données est plus petit que la réalité.
2.3.3
39 opérations
Avec 39 opérations, le problème est encore plus grand ; au bout de 600 secondes de résolution, le diagramme
de Gantt associé à la solution montre que cette dernière est loin d’être optimale :
page 24 sur 46
F IG . 10 – Planification de 39 opérations en 600 secondes
Le diagramme montre que 10 salles ont été utilisées, dont deux salles polyvalentes (19 et 20) et deux salles
partagées (13 et 15).
Même au bout de 1800 secondes, la solution peut nettement être améliorée :
page 25 sur 46
Le nombre de salles a augmenté puisque 11 sont maintenant utilisées, mais les salles partagées ne sont plus
nécessaires avec cette solution.
C’est seulement après 7200 secondes (2 heures) que la solution obtenue est bonne :
page 26 sur 46
2.4
Variation de la fonction objectif
Tous les tests de cette partie seront des tests sur 39 opérations, et avec un mélange de salles.
2.4.1
Fonction objectif la plus simple
C’est la fonction qui minimise le nombre de salles utilisées et la somme des retards à la fermeture de ces
salles. Cette fonction, relativement simple, donne déjà des résultats corrects au bout de 600 secondes (z =
131000), et dès 1800 secondes de résolution, la solution est très bonne (z = 123000), et n’est que très peu
améliorée après 7200 secondes (z = 122500). Les diagrammes de Gantt associés à ces tests sont à voir cidessus.
page 27 sur 46
2.4.2
Deuxième fonction objectif
On rajoute à la fonction objectif précédente les critères de la somme des dates de début et la somme des
retards aux dates au plus tard. Cette fonction objectif est un peu moins souple, et la résolution est donc plus
longue. La solution obtenue au bout de 600 secondes est déjà bonne (z = 117343) :
Le diagramme de Gantt montre que 11 salles sont utilisées, mais surtout que parmi elles, 4 sont polyvalentes.
La solution au bout de 7200 secondes est à peine améliorée (z = 115639) :
page 28 sur 46
Même si la valeur de la fonction objectif est similaire, certaines différences sont à remarquer. Une salle de
moins est utilisée dans ce résultat, et seulement 3 salles polyvalentes sont utilisées.
2.4.3
Prise en compte des chirurgiens
On rajoute à la fonction objectif précédente la minimisation des dépassements d’horaires des chirurgiens. Au
bout de 600 secondes de résolution, la solution obtenue est franchement mauvaise (z = 252456) :
page 29 sur 46
F IG . 15 – Planification de 39 opérations en 600 secondes, avec prise en compte des chirurgiens
On voit clairement que la planification de la salle (7) montrée sur le diagramme est inacceptable. Il faut donc
faire durer la résolution plus longtemps.
La solution obtenue après 1800 secondes est là encore visiblement très loin de l’optimal (z = 247817) :
page 30 sur 46
Cette fois, c’est la salle (18) qui prouve que l’optimalité est loin d’être atteinte.
En revanche, au bout de 7200 secondes, la planification obtenue est nettement meilleure (z = 133648) :
page 31 sur 46
Ce résultat est exploitable. 12 salles d’opérations sont utilisées, dont 3 salles polyvalentes (17, 19 et 20) et
2 partagées (13 et 16). On s’aperçoit cependant que certaines salles contiennent peu d’opérations, on peut en
déduire que la solution obtenue est améliorable, peut-être en réduisant le nombre de salles nécessaires.
On peut facilement voir que plus la fonction objectif contient de critères, plus l’optimisation est difficile.
L’ajout des critères liés aux horaires des chirurgiens dégrade particulièrement la vitesse de convergence du
programme, qui n’obtient même pas une solution satisfaisante au bout d’une demi-heure.
2.5
Variation des types de salles
On considérera des tests sur le fichier de 39 opérations, avec la fonction objectif la plus complexe, celle qui
minimise aussi les dépassements des chirurgiens :
page 32 sur 46
Minimiser
S
X
m=1
2.5.1
100Ym +
S
X
m=1
10000wm +
N
op
X
i=1
100Li +
N
op
X
i=1
ti +
NX
surg
p=1
100Km +
NX
surg
100Jp
p=1
Résolution de 600 secondes
Au bout de 600 secondes, la convergence la plus rapide s’effectue lorsque l’ensemble de salles initiales
est fait uniquement de salles spécialisées. En effet la fonction objectif a pour valeur z = 196661. Voici le
diagramme de Gantt associé à cette solution :
F IG . 18 – Planification de 39 opérations en 600 secondes, salles spécialisées
On voit tout de même que, sur les 12 salles utilisées, certaines sont partiellement inoccupées, ce qui laisse
penser qu’il est possible de réduire le nombre de salles.
Le résultat obtenu est un peu moins bon lorsqu’on considère un mélange de salles (z = 252456) :
page 33 sur 46
F IG . 19 – Planification de 39 opérations en 600 secondes, mélange de salles
Il est par contre très mauvais lorsqu’on n’utilise que des salles polyvalentes (z = 665628). Le diagramme de
Gantt associé montre clairement que la convergence est difficile pour ce dernier type de salle :
page 34 sur 46
F IG . 20 – Planification de 39 opérations en 600 secondes, salles polyvalentes
2.5.2
La tendance est la même après 1800 secondes de résolution ; les valeurs des fonctions objectifs n’ont pas
beaucoup évoluées que ce soit pour les salles spécialisées (z1800 = 188632 contre z600 = 196661), les salles
mélangées (z1800 = 247548 contre z600 = 252456) où les salles polyvalentes (z1800 = 615677 contre z600 =
665628).
2.5.3
La tendance change un petit peu après 7200 secondes de résolution. La valeur de la fonction objectif avec les
salles spécialisées est maintenant supérieure aux deux autres (z = 156482 contre z = 133648 et z = 136857).
Le diagramme de Gantt associé aux salles spécialisées montre une solution correcte :
page 35 sur 46
F IG . 21 – Planification de 39 opérations en 7200 secondes, salles spécialisées
12 salles sont utilisées, mais certaines d’entre elles (5 et 7) sont presque vides, tandis qu’une autre (15) dépasse de beaucoup sa date de fermeture théorique. La solution est donc nettement améliorable.
page 36 sur 46
Les deux autres ensembles de salles donnent d’ailleurs une bien meilleure planification :
F IG . 22 – Planification de 39 opérations en 7200 secondes, mélange de salles
page 37 sur 46
F IG . 23 – Planification de 39 opérations en 7200 secondes, salles polyvalentes
À chaque fois, 12 salles sont utilisées, mais aucune ne dépasse de beaucoup son horaire théorique de
fermeture. Cependant, certaines salles sont toujours faiblement occupées, ce qui laisse penser que diminuer
le nombre de salles est possible, particulièrement pour l’ensemble de salles polyvalentes, où la compatibilité
entre opération et salle n’est pas un problème.
2.5.4
Analyse des résultats
Ce modèle présente certains avantages, dans la mesure où il donne de bons résultats au bout d’une demi-heure
dans la plupart des cas. Il permet également de gérer l’affectation des chirurgiens, ce qui rallonge toutefois un
peu le délai d’obtention d’une planification correcte.
La convergence est nettement plus lente lorsqu’on ne considère que des salles polyvalentes, ce qui s’explique par le fait que le nombre de degrés de liberté dans ce cas est augmenté, puisque chaque opération peut
se dérouler dans n’importe quelle salle.
Si on s’intéresse au dimensionnement, on peut voir que l’ensemble des salles utilisées au départ influe sur
le nombre de salles utilisées. En effet, avec uniquement des salles spécialisées, le nombre de salles utilisées, en
page 38 sur 46
moyenne sur les 3 fonctions objectifs différentes, est de 11,3. Elle descend à 11 lorsqu’on considère un mélange
de salles, et atteint 10,3 avec uniquement des salles polyvalentes.
On constate également que le programme a tendance, lorsqu’il en a la possibilité, à affecter des opérations
dans les salles polyvalentes ou partagées, ce qui révèle leur utilité pour diminuer le nombre de salles nécessaires. Cependant, on pourrait affiner le programme en utilisant les coûts de construction de chaque type de
salle pour pondérer les variables associées aux salles dans le dimensionnement. Cela permettrait de vérifier que
la construction d’une salle polyvalente réduirait effectivement les coûts par rapport à deux salles spécialisées.
Les résultats sont résumés dans le tableau suivant :
fonctions objectifs
salles
spécialisées
mélangées
polyvalentes
simple
z
nombre de salles
113500
11
115900
11
114000
10
intermédiaire
z
nombre de salles
120431
11
115639
10
137441
9
avec chirurgiens
z
nombre de salles
156482
12
133648
12
136857
12
F IG . 24 – Tableau de résultats
page 39 sur 46
Quatrième partie
Résolution avec Cplex
Pour résoudre nos programmes linéaires, nous avons à notre disposition le logiciel Cplex en version 11.0.
Ce dernier s’exécute sur le serveur ’etud’ avec le système d’exploitation GNU/Linux CentOs 5.2. La machine
est équipée de 4 processeurs AMD Opteron à 4 x 2.0 Ghz.
1
Structure du programme
Nous utilisons le solveur Cplex au moyen de sa librairie en language C. Elle nous permet de résoudre de
façon automatisée des programmes linéaires, au lieu de lancer la résolution depuis l’interface textuelle. L’utilisation du language C a aussi l’avantage de permettre facilement les manipulations de fichiers. De plus le C est
idéal pour développer rapidement une petite application comme celle-ci.
Nous allons énumérer ci-après les fichiers sources constituant le programme en lui-même, et les scripts permettant son utilisation.
D’abord les fichiers sources constituant le programme C :
– data.h / data.c : les données d’entrée
– solver.h / solver.c : le solveur
– result.h / result.c : résultats du solveur
– stat.h / stat.c : les statistiques sur la résolution
– main.c : le programme principal
Enfin les scripts shell pour lancer le programme :
– Makefile : génère le programme exécutable
– run.sh : lance le programme solveur
– nohup_run.sh : lance run.sh en arrière-plan
1.1
Fichiers sources
1.1.1
data.c / data.h
Cet élément regroupe les données d’entrée fournis au programme de résolution.
page 40 sur 46
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/* data storage structure */
typedef struct data {
/* general parameters */
int n_op;/*number of operations*/
int n_day;/*number of days*/
int n_room;/*number of rooms*/
int n_spe_op;/*number of speciaties*/
int n_surg;
int od;/*opening duration of rooms*/
int in_time;/*minimum time between two operations*/
/* for each operation */
int* day;/*day*/
int* duration;/*duration*/
int* duedate;/*due date*/
int* spe_op;/*speciality*/
/* for each room */
int* spe_room;/*speciality of each room*/
/* for each surgeon */
int* spe_surg;/*specialty of surgeon*/
int* begin_surg;/*begining time of work*/
int* end_surg;/*ending time of work*/
char* f;/*file from which the data has been created*/
} data_t;
F IG . 25 – Codage des données d’entrée.
Le programme linéaire est établi à partir des données d’entrée. Nous avons la possibilité de paramétrer le
niveau de contraintes du modèle grâce au type level_t.
1 /* model constraint level */
2 typedef enum {
3
NullLevel = 0,/*no specific constraints*/
4
SurgeonLevel = 1,/*surgeon-specific constraints*/
5
DimensionLevel = 2,/*dimension constraints*/
6
AllLevel = 255/*all constraints*/
7 } level_t;
F IG . 26 – Codage des niveaux de contraintes du modèle.
page 41 sur 46
1.1.2
solver.c / solver.h
Cette partie constitue le solveur. C’est ici qu’est réalisé l’interfaçage avec le logiciel Cplex via la librairie
Cplex. Le solveur est caractérisé par ses paramètres. Les paramètres sont regroupés au sein de la structure
solver_param_t :
1 /* parameters of the solver */
2 typedef struct solver_param {
3
4
double max_run_time;/*maximum run time in seconds*/
5
int verbose;/*whether to display output or not*/
6
7 } solver_param_t;
F IG . 27 – Structure des paramètres du solveur.
Cette structure stocke le temps d’exécution maximal que l’on souhaite allouer au programme, ainsi qu’un
paramètre booléen décidant de l’affichage ou non de certaines sorties du solveur. Ce dernier paramètre est utile
pour supprimer l’affichage des valeurs des variables, qui devient lent avec le nombre croissant de variables.
1.1.3
result.c / result.h
Cette structure stocke les résultats fournis par le solveur. Cela concerne entre autres les dates de début
des opérations, la salle attribuée à l’opération, le chirurgien affecté. C’est ici que sont regroupées les routines
concernant les diagrammmes de Gantt et diagrammes de charge. Le programme écrit des scripts destinés à
Gnuplot [3] qui les interprète et les convertit en images. Gnuplot est appelé par le script run.sh.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* result storage structure */
typedef struct result {
int n_op;/*number of operations scheduled*/
int n_surg;/*number of surgeons*/
/*for each operation*/
int* start;/*start times*/
int* end;/*end time*/
int* room;/*room of operation*/
int* surg;/*surgeon of operation*/
int* duedate_late;/*lateness from duedate*/
/*for each surgeon*/
int* surg_early;/*amount of time before normal hours*/
int* surg_late;/*amount of time after normal hours*/
} result_t;
F IG . 28 – Structure des résultas.
page 42 sur 46
1.1.4
stat.c / stat.h
Cette structure concerne certaines statistiques obtenues lors de la résolution, telle que la valeur de la fonction
objectif, le temps d’exécution, le nombre de noeuds visités par Cplex.
1 /* solver statistic storage structure */
2 typedef struct stat {
3
int z;/*objective value*/
4
double zc;/*continuous objective value*/
5
int node;/*node count*/
6
double time;/*computation time in seconds
*/
7
8
char* name;/*the name of the original
instance file*/
9
10 } stat_t;
F IG . 29 – Structure de statistiques du solveur.
1.2
Scripts
Des scripts shell facilitent le lancement de notre programme.
1.2.1
Makefile
Ce script réalise la génération du programme exécutable. Il est destiné au moteur de production make [4]. Le
programme C est compilé avec GCC [5], le compilateur C libre. Le script fournit au compilateur l’emplacement
de la librairie Cplex. Cet emplacement varie selon le type de système d’exploitation et la version de Cplex ; il
est probable de devoir le modifier légèrement pour faire fonctionner le logiciel sur une autre machine. Les
conditions pour pouvoir compiler le programme sont donc d’avoir les logiciels installés : make, gcc, et la
libraire Cplex 11.0.
1.2.2
run.sh
Ce script permet de choisir un cahier de bloc, de lancer le solveur sur ces données et de optionellement de
visualiser les diagrammes de Gantt et de charge produit. Les cahiers de bloc sont au format suivant :
– le nombre d’opérations n_op sur la première ligne
– le nombre de spécialités sur la deuxième ligne
– n_op lignes contenant : la durée de l’opération en minutes, le numéro du jour, le numéro de la spécialité
page 43 sur 46
5
1
345
100
280
75
55
1
1
1
1
1
1
1
1
2
3
F IG . 30 – Exemple de fichier de bloc
Le nom du fichier de bloc à utiliser doit être entré dans le script en premier argument de notre programme
en C. Le programme est appelé solve, et ici le cahier de bloc est le fichier bloc10T_R_SEM07.txt :
# run solver
./solve bloc10T_R_SEM07.txt $RANK && \
1.2.3
nohup_run.sh
Le script lance la résolution en tâche de fond, c’est-à-dire que l’utilisateur a la possibilité de se déconnecter
sans interrompre l’exécution du programme. Il permet surtout de séparer les données lors du lancement de
résolutions concurrentes. L’utilisateur doit spécifier un numéro qui distingue chaque jeu de données d’entrée et
de sortie.
2
Problèmes rencontrés
Nous détaillerons ici certains problèmes techniques rencontrés.
2.1
Limites de Cplex
Effectuer un test avec une bonne qualité de la solution nécessite de lancer le programme pendant 2 heures.
C’est long. L’exécution de plusieurs tests simultanés représente un gain de temps non-négligable. Par défault,
le solveur Cplex essaie de tirer partie d’une architecture multiprocesseur comme celle de la machine que nous
utilisons. Malheureusement la license de Cplex de l’isima ne permet pas l’exécution parallèle, et le solveur
lance un seul thread d’exécution. Par contre, on peut tout à fait lancer deux instances de notre programme. Mais
il faut séparer les données d’entrée et de sortie pour chaque programme lancé. C’est là qu’intervient le script
shell nohup_run.sh présenté un peu plus haut.
page 44 sur 46
2.2
Problème de rappatriement des données depuis Cplex
Cplex stocke les variables en nombres réels. Certaines des variables booléennes étaient fixées par Cplex à
des valeurs non entières, commme 10−13 par exemple. La valeur convertie en nombre entier ne correspondait
pas. Ceci avait un impact sur les variables xi,j . En conséquence, certaines opérations se chevauchaient et cela se
voyait sur les diagrammes de Gantt. Nous avons dû écrire une fonction d’arrondi. Les valeurs réelles supposées
booléennes sont désormais seuillées à la valeur 0.5.
page 45 sur 46
Conclusion
Les contraintes inhérentes au milieu hospitalier ont rendu ce problème de planification beaucoup plus compliqué que la plupart des problèmes similaires. Ces contraintes supplémentaires sont dues à des facteurs aussi
divers et variés que la gestion du personnel, les problèmes de logistique, ou le caractère aléatoire de la durée
d’une opération, auxquels s’est ajouté le dimensionnement du bloc opératoire à effectuer. Durant ce projet, deux
modèles ont été crées, qui répondaient chacun à une facette du problème. Outre le fait qu’ils effectuent tous
deux le dimensionnement, le premier modèle effectue une planification hebdomadaire des opérations, tandis
que le second n’effectue qu’une planification journalière, tout en affectant les chirurgiens aux opérations. Les
programmes linéaires associés à ces modèles sont modulables, puisqu’ils peuvent prendre en compte plusieurs
fonctions objectifs possibles. Ils sont résolus à l’aide du solveur Cplex. Plus de tests auraient été utiles pour en
avoir la certitude, mais ces deux modèles semblent donner de bons résultats quels que soient les paramètres,
malgré le fait que ces programmes sont trop gros pour être résolus de manière exacte avec des jeux de données
réalistes. Le meilleur moyen de vérifier la réalisabilité de ces modèles est de les faire valider par le modèle de
simulation QNAP développé dans le cadre d’un projet de deuxième année.
page 46 sur 46
Références bibliographiques
[1] Operating rooms scheduling
A. Jebali, A. B. H. Alouane, P. Ladet
Int. J. Production Economics 99 (2006) 52-62.
[2] Blocs opératoires publics : application de la stratégie block scheduling
S. Kharraja, F. Albert, S. Chaabane
MOSIM ’06 du 3 au 5 avril 2006.
[3] Gnuplot, un logiciel de tracé de courbes
http ://www.gnuplot.info, 1986.
[4] Make, le moteur de production
http ://www.gnu.org/software/make, 1977.
[5] GCC, le compilateur C
http ://gcc.gnu.org, 1985.

Un outil d`aide au dimensionnement et à la planification des

Transcription

Documents pareils

Zone-Orange 2-26-202 ArtiShow 6-31-102

VP236 Rue Aïn Oulmes, Casablanca, Maroc 2 200 000 Dhs Classe

Télécharger

Fonds de commerce à vendre Salles 3340 immo

Sur un site d`exception et aux portes d`Angers, le Domaine de

Cap Saint Jacques Location de salles à Guyancourt DEVIS n°679

ADP POITIERS - ADP Immobilier

Consulter les tarifs de location de salle

L A VILLE DE JUVISY-SUR